Re: linux-image-*-dbg for squeeze?
[ Adding ftpmasters to To: ] On 05/03/10 at 19:34 +0100, Bastian Blank wrote: On Fri, Mar 05, 2010 at 09:07:50AM +0100, Lucas Nussbaum wrote: I wonder what we (as Debian) could do about it. Would it make sense to sponsor a very fast machine that the kernel team could use to build the kernels and upload from, replacing kernel-archive.buildserver.net ? The easiest fix is the official blessing by the ftp team to upload only the architecture independant packages and build all architectures on the buildds. Ftpmasters, would it be acceptable for the kernel team to upload only the architecture independant packages ? It would allow to provide debug packages on fast architectures without forcing the developers to upload them using their slow internet connections, solving #365349. -- | Lucas Nussbaum | lu...@lucas-nussbaum.net http://www.lucas-nussbaum.net/ | | jabber: lu...@nussbaum.fr GPG: 1024D/023B3F4F | -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100306180621.ga21...@xanadu.blop.info
Re: linux-image-*-dbg for squeeze?
On 04/03/10 at 16:40 -0700, John Wright wrote: Hi kernel team, (Cc-ing -devel to get more eyes on the subject, since I'm soliciting ideas here... See [1] for some context.) What would it take to get kernel debuginfo into squeeze? As I understand it, the main blockers were [2]: Hi John, I raised the same question a few weeks ago. See the thread starting at http://lists.debian.org/debian-devel/2010/02/msg00403.html Summary: - Some buildds for slow arches are hosted on DSL lines, making it unpractical to upload very large kernel images (my -dbg .deb takes 424 MB on amd64). = Support could be limited to fast arches with well-connected buildds: i386, amd64, powerpc, s390 and ia64 - Archive space problem = Support could be limited to some flavours (like, only the standard one, for a start) - Buildd disk space: not a problem on the fast arches So, the major blockers seem to be network bandwidth (to upload the packages) and increased build time for the kernel maintainers. See http://lists.debian.org/debian-devel/2010/02/msg00472.html http://lists.debian.org/debian-devel/2010/02/msg00478.html I wonder what we (as Debian) could do about it. Would it make sense to sponsor a very fast machine that the kernel team could use to build the kernels and upload from, replacing kernel-archive.buildserver.net ? Another alternative would be to turn on the CONFIG_DEBUG_INFO and CONFIG_KPROBES options, but strip the kernel and modules, but at least provide some script a user could run to rebuild the kernel with the same options and compiler to get the debug symbols. Or maybe upload the debuginfo packages to a separate archive? There was some discussion about a large data archive a few years ago, and Joerg mentioned in May 2008 that such an archive setup was only a couple weeks out [3]. But I haven't heard anything since then... It isn't that complicated to build your own kernel image with debuginfo, and it takes 30 mins on a fast 8-cores system. My notes: apt-get install linux-image-2.6.32-3-amd64 linux-source-2.6.32 kernel-package tar xf /usr/src/linux-source-2.6.32.tar.bz2 cd linux-source-2.6.32 cp /boot/config-2.6.32-3-amd64 .config edit .config: CONFIG_KPROBES=y CONFIG_DEBUG_INFO=y make oldconfig export PATH=/usr/lib/ccache:$PATH make-kpkg -j 16 --append-to-version +kprobes --revision=1 --initrd binary-arch -- | Lucas Nussbaum | lu...@lucas-nussbaum.net http://www.lucas-nussbaum.net/ | | jabber: lu...@nussbaum.fr GPG: 1024D/023B3F4F | -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100305080750.gb14...@xanadu.blop.info
Re: linux-image-*-dbg for squeeze?
Hi Lucas, On Fri, Mar 05, 2010 at 09:07:50AM +0100, Lucas Nussbaum wrote: On 04/03/10 at 16:40 -0700, John Wright wrote: Hi kernel team, (Cc-ing -devel to get more eyes on the subject, since I'm soliciting ideas here... See [1] for some context.) What would it take to get kernel debuginfo into squeeze? As I understand it, the main blockers were [2]: Hi John, I raised the same question a few weeks ago. See the thread starting at http://lists.debian.org/debian-devel/2010/02/msg00403.html Agh, I totally missed that discussion. Sorry to bring it back up in a new thread... Summary: - Some buildds for slow arches are hosted on DSL lines, making it unpractical to upload very large kernel images (my -dbg .deb takes 424 MB on amd64). = Support could be limited to fast arches with well-connected buildds: i386, amd64, powerpc, s390 and ia64 - Archive space problem = Support could be limited to some flavours (like, only the standard one, for a start) I think we could live with those compromises. :) - Buildd disk space: not a problem on the fast arches So, the major blockers seem to be network bandwidth (to upload the packages) and increased build time for the kernel maintainers. See http://lists.debian.org/debian-devel/2010/02/msg00472.html http://lists.debian.org/debian-devel/2010/02/msg00478.html I wonder what we (as Debian) could do about it. Would it make sense to sponsor a very fast machine that the kernel team could use to build the kernels and upload from, replacing kernel-archive.buildserver.net ? Makes sense to me, especially if it had good connectivity to ftp-master. What would it take to make this happen? And would it make building debug info more palatable to the kernel team? Another alternative would be to turn on the CONFIG_DEBUG_INFO and CONFIG_KPROBES options, but strip the kernel and modules, but at least provide some script a user could run to rebuild the kernel with the same options and compiler to get the debug symbols. Or maybe upload the debuginfo packages to a separate archive? There was some discussion about a large data archive a few years ago, and Joerg mentioned in May 2008 that such an archive setup was only a couple weeks out [3]. But I haven't heard anything since then... It isn't that complicated to build your own kernel image with debuginfo, and it takes 30 mins on a fast 8-cores system. My notes: apt-get install linux-image-2.6.32-3-amd64 linux-source-2.6.32 kernel-package tar xf /usr/src/linux-source-2.6.32.tar.bz2 cd linux-source-2.6.32 cp /boot/config-2.6.32-3-amd64 .config edit .config: CONFIG_KPROBES=y CONFIG_DEBUG_INFO=y make oldconfig export PATH=/usr/lib/ccache:$PATH make-kpkg -j 16 --append-to-version +kprobes --revision=1 --initrd binary-arch True, but it doesn't give you debug data you can use with the kernel Debian actually ships (although it might if CONFIG_KPROBES=y and CONFIG_DEBUG_INFO=y in the real kernel, but it were stripped...). Part of the appeal is being able to use systemtap and crash without also basically having to be your own kernel maintainer. -- John Wright j...@debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100305112702.gb15...@supernova.localdomain
Re: linux-image-*-dbg for squeeze?
On Fri, Mar 05, 2010 at 09:07:50AM +0100, Lucas Nussbaum wrote: I wonder what we (as Debian) could do about it. Would it make sense to sponsor a very fast machine that the kernel team could use to build the kernels and upload from, replacing kernel-archive.buildserver.net ? The easiest fix is the official blessing by the ftp team to upload only the architecture independant packages and build all architectures on the buildds. Bastian -- Time is fluid ... like a river with currents, eddies, backwash. -- Spock, The City on the Edge of Forever, stardate 3134.0 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100305183417.ga6...@wavehammer.waldi.eu.org
Re: linux-image-*-dbg for squeeze?
My 2 cents being that I'm far from part of the kernel team: Am Freitag 05 März 2010 00:40:27 schrieb John Wright: Hi kernel team, What would it take to get kernel debuginfo into squeeze? As I understand it, the main blockers were [2]: 1) It would blow up the archive by ~10 GB - This is a lot of space, but I believe it's worth it for crash dump and systemtap support. Having these supported would be dead handy. 2) It would increase the buildd disk requirements as well. Bastion gave a 30 GB figure, given 8 flavors in a particular architecture. I would say even more than 30 GB since you neeed for each arch so many kernel flavours + matching modules to them afaik. - Do we have that many flavors for any arch now?) Yes, I can remember 4 : VServer- , OpenVz- , Xen- , Standard- Kernel-Images. For these you need the drivers, the modules all build seperately and against them. Then there are the whole bunch of different modules and packages that have to hookinto a particular part of the Kernel(libnetfilter?). Then there is the whole lot of patch sets, modules, source-packages. All in all ~30GB is a good rough estimate. - Do we have buildd's that are this low on disk space? Couldn't we upgrade them? You could donate disks if you want but I doubt that this solves the overall problem. FTPMasters sure have a reason why they dont want so many flavours in their repos. I haven't tried to see if my patch still applies against the current linux-2.6 packaging. If I made sure it still worked (submitting a new patch if necessary, of course), would you consider accepting it? IMHO If your patch still works you could package it as a deb and let people apply it to their kernel and recompile if they want to. In this case can you tell how big the package would be when you would make that for your patch? Cheers, Andreas Marschke. PS: Just my 2 Cents... -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201003050307.50555.xxtj...@gmail.com
