Re: creating kernel udebs from kernel-source
On Mon, Nov 29, 2004 at 02:55:20PM +0100, Fabio Massimo Di Nitto wrote: > Sven Luther wrote: > |Fabio Massimo di Nitto wrote: > |> - - the second one is slightly more dynamic and it involves the > |> addition ~ of the udebs to the control file at build time, but > |> they are still arch specific. > |> > |> So at the end you get nothing more than what you had before, just > |> from the same source. > | > | Which i was led to believe that the packaging tools could not cope > | with 6 month or so ago. Maybe i am wrong though ? > > I am not really sure what you are talking about, but we have packages > in the archive generating way more binaries that what this solution does. Fabio, the point is that all the packages that *might* be generated on any architecture (not just the current build architecture) have to go into the .dsc's Binary: line. Some time back this broke a hard-coded limit in woody's apt, and thereby broke upgrades from woody to sarge for anyone who tried to use deb-src lines referencing sarge before they'd got apt upgraded. That's one of the reasons we decided to split out the various linux-kernel-di-$ARCH packages. Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: creating kernel udebs from kernel-source
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tuesday 30 November 2004 17:35, Joey Hess wrote: > - It can take a long time to update d-i to a new kernel version on all >arches. (Granted, part of this time is spent updating the udebs.) >So we often find ourselves updated to 2.4.28 on i386, while hppa is >still at 2.4.27, and so on. It's useful to be able to remove the i386 >2.4.27 udebs at this point, to avoid them shipping on the CD images >and increasing the installer's memory and bandwidth requirements >(from Packages file entries). If i386 and hppa or other arches had >udebs built from the same kernel-source then we'd not be able to >remove them until all arches were updated. Hmm. Could we not be a little bit smarter and include only those udebs on a CD for which we have kernels on the CD? I would guess we should be able to automate that in some way. IMHO it would be good if we could leave the 'old' version of udebs on the mirrors a bit longer than currently. That would also reduce the amount of installation failures by people who use a installer version that uses the previous version of the kernel. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBrMx/gm/Kwh6ICoQRAn1NAKCx8WpJkgCS8EGyavwN0831tZjKvACfRVYZ RatwUvpBYWsMOjdWFzPN0e0= =nFCL -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: creating kernel udebs from kernel-source
Steve Langasek wrote: > Taking all archs together, the number of kernel udebs across all > architectures and flavours seems to be 464. If there is a limit on how many > binary packages per source the archive can handle, that probably does blow > out the limit. I thought the limit was only on the number of binaries in a > changes file, but I could be wrong. There are several limits, IIRC these include the number of packages and also the length of the binaries field that lists all the package names in the source. AFAIK they're all fixed in sarge, but that won't be useful until ftp-master is upgraded to sarge. It can also potentially break client systems that use apt-get, so we should be ok for such large sets of binary packages after sarge is released. We've bounced back and forth several times now between generating udebs as part of the kernel-image builds and as a separate step. It's more work, but I prefer doing it as a separate step. Some of the things that seem to work better this way: - d-i development frequently requires adding new modules to a udeb, or adding a new udeb, or moving modules around to free up space on an image. These changes have been frequent (one or more uploads per day) in the past. If we had to build a new kernel each time, it would be much more painful. If it had to autobuild on all arches each time, that would be excruciating. - It's sometimes been useful in transitions to make a given linux-kernel-di-arch package build udebs for two separate kernel versions. Of course we'd not release like this, but it makes it easy to test the new version while keeping the old version used for the daily builds. Once we switch an arch to the new version the udebs for the old can easily be dropped. - It can take a long time to update d-i to a new kernel version on all arches. (Granted, part of this time is spent updating the udebs.) So we often find ourselves updated to 2.4.28 on i386, while hppa is still at 2.4.27, and so on. It's useful to be able to remove the i386 2.4.27 udebs at this point, to avoid them shipping on the CD images and increasing the installer's memory and bandwidth requirements (from Packages file entries). If i386 and hppa or other arches had udebs built from the same kernel-source then we'd not be able to remove them until all arches were updated. - d-i contains a document on using a custom kernel. A user building a custom kernel may not want to base it on the kernel-source package, so having the linux-kernel-di-i386 as a separate package that they can use to split up a kernel-image.deb they created by their preferred means adds flexability. -- see shy jo signature.asc Description: Digital signature
Re: creating kernel udebs from kernel-source
On Tue, Nov 30, 2004 at 02:36:30AM -0800, Steve Langasek wrote: > On Tue, Nov 30, 2004 at 11:21:33AM +0100, Sven Luther wrote: > > > other way. This still doesn't mean that it is d-i task to workaround this > > > kind of problems introducing extra sets of udebs > > > Well, how do you install on that box then, provided we can't fix the above > > bug, if it is a bug ? > > > Me thinking that maybe we should use -smp variants for the power3 and power4 > > d-i kernels. > > Why not (post-sarge)? The ia64 d-i kernels are already based on an smp > flavor. Well, given the limited amount of testing we got on power3, i think it would be safe to do this pre-sarge, since a majority of installs i had direct access to worked with the -smp kernel and not with the -up one (but then it was 1 of 1, i think, and current d-i doesn'y work anyway on leighbb's power3 machine). post-sarge, we will drop 32bit power3 and power4/g5 kernels anyway in favor of 64bit iseries-legacy, generic and generic-power4 kernels anyway. I tried to by myself a power3 chrp box, but at >750 Euro, it was well over my budget for this kind of things. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: creating kernel udebs from kernel-source
On Tue, Nov 30, 2004 at 02:31:41AM -0800, Steve Langasek wrote: > On Tue, Nov 30, 2004 at 10:40:24AM +0100, Sven Luther wrote: > > > You don't generate udebs for each flavour because there > > > is not necessarely the need for it. In the i386 example there is only > > > one set of udebs coming from the -386- flavour. > > > Well, maybe, i am no expert on x86, but on powerpc, you need one set of > > modules for each flavour, since they are using incompatible instruction set > > optimization : powerpc (everything from 601 to the G4, passing by some > > embedded processors), power3 (used in ibm rs6k, 64bit and more of a power > > than > > powerpc processor), and power4/g4. > > > > | Like waldi said, it was around 200 packages 6 month ago, and > > > | probably over 400 today, > > > > > > My request of being in CC has been ignored and I lost part of the > > > messages. > > > Ah, missed that also. like said a current calulation brings a total of 739 > > .udebs in all the debian kernel packages. Maybe some of it is overkill given > > the small number of .udebs ubuntu has. Maybe you can have some insight here > > ? > > > > Or for example you don't need k7 udebs, since the 386 will do. > > > Sure, but this is because on x86 the flavours are mostly only different > > optimization, but on other arches this is not the case. I believe that on > > powerpc, m68k, mips/mipsel and arm at least, the different kernels are there > > because of real incompatibilities, maybe for other this is the case also. We > > speak more of subarches than flavours here really. > > > > There are clearly exceptions like ppc that needs more.. i don't disagree > > > and i did never questioned this situation. > > > I believe that x86 is the exception here, while the other arches situation > > is > > the norm, and even on x86, if you think about pure64, and 386/486 situation, > > you would reconsider this, but then ubuntu probably don't care about such > > old > > x86 hardware, and rightly so. > > alpha -- 1 subarch -- 29 kernel udebs => 28 udebs / subarch > arm -- 5 subarchs -- 28 udebs => 5-6 udebs / subarch > hppa -- 1 subarch -- 8 udebs => 8 udebs / subarch > i386 -- 2 subarchs -- 81 udebs => 40-41 udebs /subarch > ia64 -- 1 subarch -- 24 udebs => 24 udebs / subarch > m68k -- 7 subarchs -- 67 udebs => 9-10 udebs / subarch > mips -- 3 subarchs -- 29 udebs => 9-10 udebs / subarch > mipsel -- 4 subarchs -- 37 udebs => 9-10 udebs / subarch > powerpc -- 5 subarchs -- 127 udebs => 25-26 udebs / subarch counting apus, and around 39 udebs / subarch for 2.6 kernels > s390 -- 1 subarch -- 7 udebs => 7 udebs / subarch > sparc -- 2 subarchs -- 27 udebs => 13-14 udebs / subarch you can see a trend there, with the hardware that has the most hardware support (i386, ia64, powerpc, alpha), having the most .udeb modules per given subarch, so there is not really a chance to disminish this magically without rethinking the way module .udebs work. > At least of the kernel images that currently build-depend on > kernel-tree-2.4.27-* (alpha, hppa, i386, ia64, s390, sparc -- I assume these > would be the first to be integrated if the patch were accepted), i386 is > actually on the high end of both flavors and total udebs. Well, forget 2.4 about this, this is most assuredly post-sarge stuff, and it makes much more sense to think about 2.6 kernels in that way, and since there is very little chance of huge patches going into 2.4 at this late stage of 2.4 development, the 2.4 patches are usually huge monolithic patches, and upstream kernel development mostly concerns itself with 2.6 right now, it makes more sense to think in term of 2.6/2.8 kernels here. > Taking all archs together, the number of kernel udebs across all > architectures and flavours seems to be 464. If there is a limit on how many My count was at 303 for 2.6 kernels and 436 for 2.4 ones. > binary packages per source the archive can handle, that probably does blow > out the limit. I thought the limit was only on the number of binaries in a > changes file, but I could be wrong. > > It would also be nice if the number of flavors required for d-i would go > down over time, but that remains to be seen. As far as powerpc is concerned, this can't happen unless we want to do some huge amount of upstream kernel work to code for a common subset of the powerpc/power instruction set, or decide to drop support for some hardware. And we don't even have started to add the ppc64 kernels, which will come in 2 subarches, one of them having an extra flavour/optimization. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: creating kernel udebs from kernel-source
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Sven Luther wrote: |> |> 20 sets of udebs, but just the common ones that can manage to |> |> boot everything since the installer will make the proper |> decision |> later. | | | No. This works for the -up against -smp |> ones, and maybe for the | upcoming ppc64/generic and |> ppc64/generic-power4, but for the rest | of it, they are trully |> separate kernel which will not run on boxes | they are not meant |> to. |> |> ok.. let's try another example: |> |> Arch foo has 20 different kind of subarches and each of them has |> 4 different flavours. For simplicity we will call them |> subarchN-flavM. where M can be: 0 = no optimizations of any kind. |> 1= optimization1 2 = ... 3 = ... | | | No, i don't believe this is the reality out there apart on x86. | each arch has a number of subarches, but not really significant | amount of optimizations. See Steve Langasek post with proper numbers: http://lists.debian.org/debian-kernel/2004/11/msg00684.html |> due to the fact that flav0 is common to the entire subarch. | | | I also have some doubt that you can without risk reuse the modules | of a given subarch flavour with another flavour in most cases out | there. I did never mixed them Sven. see again the numbers and what i wrote in the thread. The patch generates all the required udebs. All of them from the kernel to the modules. | |> This kind of "optimization" can apply to all the arch. You |> maintain the subarch (otherwise it doesn't boot). You kill the |> unrequired flavours. This reduces a lot the amount of udebs that |> you need. | | | Yes, but i don't think your reasoning applies outside of x86. At | least it doesn't on powerpc right now, so there is not much you can | do. see the same post as above... i386 is one arch with 2 subarch and generates more udebs than arm with 5 subarch and yes.. i can see myself that ppc is the one with biggest amount.. tought.. it could have been any other arch like s390 or m68k or Fabio - -- Self-Service law: The last available dish of the food you have decided to eat, will be inevitably taken from the person in front of you. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQIVAwUBQaxc+1A6oBJjVJ+OAQKEnQ//SD2KNb/7v07aJvh24mI9waAF1ZfQ68HU 5O+NUc1F4WwPPeyHNxnDG/F6VU+NRQgudW7nofoNpi7+0zEIa56yJO2bYBUs7Nsm 7W/KpuOlC4Q8ADDYQ0yrSQYGbF8eTfzbCrOnQbVfEaWXuFMCwBKDcJkDPXoBrRbJ nmRuN9nWqDZi2Ku1YBVGoN0yBvSf3J+egefR+47pefggNoIqLnjFH8AXxzfrnFfy F71Oln5HKAFL7tiw4kzKscjcJnc62/NUyLCxOAgM+hwjgud4qY/AOpMyQd4SZYGU eD5UZXmcL+h0fFDdhwxVOBZpRxk8WdAz5It8l2S7tjgv5242wOE/4ts4Yxk4IKzr ZoRjwFlEbJLFHxnIVUa/MZ5RRj0qcM/iup0CisERHZbPHZWGC+77Vgl2HRRmjZ5O XEKJxCfHemVHRc99UGT06cju6xiVVTszsM9gvOvryh1RaVZlSfyk0NrX2f0bUnMT zNvyYI1G0sTYQKprGcXq4Fx2i4e+SIP9CO5ntOriXIcKfBdlO9NVpuPm2TG57bki CYPgPq9WgJwotT7/YfshTC/0h/ou8qX/wmdQ4u+YlFBxAEKxn66n65S+TRPH4Lnd HBANl40AB5pL1t8xNRJkGiTvrfTpSRAQlvlOCdu+5D2BgwndzvnCjLKdwc9z5Vs8 5OBCUt+gRD8= =hqev -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: creating kernel udebs from kernel-source
On Tue, Nov 30, 2004 at 12:44:04PM +0100, Fabio Massimo Di Nitto wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Sven Luther wrote: > > |> |> 20 sets of udebs, but just the common ones that can manage to > |> |> boot everything since the installer will make the proper > |> decision |> later. | | | No. This works for the -up against -smp > |> ones, and maybe for the | upcoming ppc64/generic and > |> ppc64/generic-power4, but for the rest | of it, they are trully > |> separate kernel which will not run on boxes | they are not meant > |> to. > |> > |> ok.. let's try another example: > |> > |> Arch foo has 20 different kind of subarches and each of them has > |> 4 different flavours. For simplicity we will call them > |> subarchN-flavM. where M can be: 0 = no optimizations of any kind. > |> 1= optimization1 2 = ... 3 = ... > | > | > | No, i don't believe this is the reality out there apart on x86. > | each arch has a number of subarches, but not really significant > | amount of optimizations. > > See Steve Langasek post with proper numbers: > http://lists.debian.org/debian-kernel/2004/11/msg00684.html Yeah, well, i see no significant contradiction there to what i say. > |> due to the fact that flav0 is common to the entire subarch. > | > | > | I also have some doubt that you can without risk reuse the modules > | of a given subarch flavour with another flavour in most cases out > | there. > > I did never mixed them Sven. see again the numbers and what i wrote > in the thread. The patch generates all the required udebs. All of them > from the kernel to the modules. Ok. Because you can run kernels optimized differently, my misunderstanding there. > |> This kind of "optimization" can apply to all the arch. You > |> maintain the subarch (otherwise it doesn't boot). You kill the > |> unrequired flavours. This reduces a lot the amount of udebs that > |> you need. > | > | > | Yes, but i don't think your reasoning applies outside of x86. At > | least it doesn't on powerpc right now, so there is not much you can > | do. > > see the same post as above... i386 is one arch with 2 subarch > and generates more udebs than arm with 5 subarch and > yes.. i can see myself that ppc is the one with biggest amount.. > tought.. it could have been any other arch like s390 or m68k > or Exact, so what ? The problem on i386 is that you have a .udeb for different optimizations, right ? I guess the reason why powerpc has the biggest amount (altough powerpc uses 2.6 kernels per default, and the 2.4 ones are only there for backward compatibility in some obscure cases, like some oldworld pmac or obscure prep boxes), is that it is the arch which has the most chance of using a wide variety of hardware, and thus needs the most variety of module .udebs, the same as x86 in some way, compared to m68k or s390, where the hardware you can use is well known, and finite in number, thus giving you a relative small .udebs per subarch ratio (67/7 -> a bit under 10), while powerpc, with its 3 2.6 subarches has 117 .udebs, which would be around 40 per subarch. You can't really trust 2.4 powerpc numbers, since they include apus, which is mostly in the m68k/amiga category as far as hardware support is concerned. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: creating kernel udebs from kernel-source
On Tue, Nov 30, 2004 at 11:55:06AM +0100, Fabio Massimo Di Nitto wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Sven Luther wrote: > > | > | On these, there is a separate kernel because it is needed, not > | because you want some random optimizations. Try to install on a > | m68k/pmac with a m68k/amiga kernel to take one example i am > | familiar with, and you will see whta i mean. > > Sven, as i wrote before, i didn't say anywhere that you must kill > subarches and i don't understand why you keep remarking this > bits of which i am perfectly aware of. Because we are having a misunderstanding, see below. > |> 20 sets of udebs, but just the common ones that can manage to > |> boot everything since the installer will make the proper decision > |> later. > | > | > | No. This works for the -up against -smp ones, and maybe for the > | upcoming ppc64/generic and ppc64/generic-power4, but for the rest > | of it, they are trully separate kernel which will not run on boxes > | they are not meant to. > > ok.. let's try another example: > > Arch foo has 20 different kind of subarches and each of them has > 4 different flavours. For simplicity we will call them subarchN-flavM. > where M can be: > 0 = no optimizations of any kind. > 1= optimization1 > 2 = ... > 3 = ... No, i don't believe this is the reality out there apart on x86. each arch has a number of subarches, but not really significant amount of optimizations. The optimization stuff is only present on x86 in a significant way, altough one could argue that the -smp kernels are optimizations of the -up ones. I doubt that -smp modules would play well with -up kernels though, or vice versa. On powerpc, the sole exception to this would be the power4 optimization in the ppc64/generic subarch, but we don't yet build this kind of kernels anyway. > This will generate 80 kernels as a result of 20 subarch * 4 flavours. > > Now.. if you look at it from an installer point of view, you don't need > 80 udebs set to boot the 20 subarches. you only need 20 udebs sets: > subarch1-flav0 > subarch2-flav0 > . > subarch20-flav0 > > due to the fact that flav0 is common to the entire subarch. I also have some doubt that you can without risk reuse the modules of a given subarch flavour with another flavour in most cases out there. > This kind of "optimization" can apply to all the arch. You maintain > the subarch (otherwise it doesn't boot). You kill the unrequired flavours. > This reduces a lot the amount of udebs that you need. Yes, but i don't think your reasoning applies outside of x86. At least it doesn't on powerpc right now, so there is not much you can do. > |> other way. This still doesn't mean that it is d-i task to > |> workaround this kind of problems introducing extra sets of udebs > | > | > | Well, how do you install on that box then, provided we can't fix > | the above bug, if it is a bug ? > > You get to cooperate with upstream to get the bug fixed? Yeah, well, not enough time for this right now, but yes, this would be the best way. Also availability of power3 boxes to test this kind of stuff is rather scant, and working with third party people who have sporadic access to said hardware (because it has later to go on production, and ends up running aix), is not optimal too. But in principle you are right, obviously. > | Me thinking that maybe we should use -smp variants for the power3 > | and power4 d-i kernels. > > That's something you don't need to discuss with me, but with > the relevant people in the installer team. Indeed. Or just go ahead and implement it. I doubt anyone else in the team has had real experience qith power3 machines. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: creating kernel udebs from kernel-source
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Sven Luther wrote: | | On these, there is a separate kernel because it is needed, not | because you want some random optimizations. Try to install on a | m68k/pmac with a m68k/amiga kernel to take one example i am | familiar with, and you will see whta i mean. Sven, as i wrote before, i didn't say anywhere that you must kill subarches and i don't understand why you keep remarking this bits of which i am perfectly aware of. |> 20 sets of udebs, but just the common ones that can manage to |> boot everything since the installer will make the proper decision |> later. | | | No. This works for the -up against -smp ones, and maybe for the | upcoming ppc64/generic and ppc64/generic-power4, but for the rest | of it, they are trully separate kernel which will not run on boxes | they are not meant to. ok.. let's try another example: Arch foo has 20 different kind of subarches and each of them has 4 different flavours. For simplicity we will call them subarchN-flavM. where M can be: 0 = no optimizations of any kind. 1= optimization1 2 = ... 3 = ... This will generate 80 kernels as a result of 20 subarch * 4 flavours. Now.. if you look at it from an installer point of view, you don't need 80 udebs set to boot the 20 subarches. you only need 20 udebs sets: subarch1-flav0 subarch2-flav0 . subarch20-flav0 due to the fact that flav0 is common to the entire subarch. This kind of "optimization" can apply to all the arch. You maintain the subarch (otherwise it doesn't boot). You kill the unrequired flavours. This reduces a lot the amount of udebs that you need. |> other way. This still doesn't mean that it is d-i task to |> workaround this kind of problems introducing extra sets of udebs | | | Well, how do you install on that box then, provided we can't fix | the above bug, if it is a bug ? You get to cooperate with upstream to get the bug fixed? | | Me thinking that maybe we should use -smp variants for the power3 | and power4 d-i kernels. That's something you don't need to discuss with me, but with the relevant people in the installer team. Fabio - -- Self-Service law: The last available dish of the food you have decided to eat, will be inevitably taken from the person in front of you. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQIVAwUBQaxRJ1A6oBJjVJ+OAQIkGg/8CEwu1A9hIRCNgSy2ETJKKUiTYSvFcQjX M1quJro1iXHVprBpVRm+g3nEK3mHB90MFqe+upctypusT60Tz7AsFz/5Ysw+WLYA zj8q+Y2h6jYhVu2twg10mgO6sV9y4R2MmtxQYlegZ9KA5rPnQiKtsi3PXT9F35E+ xFbWLHt+VQIwYkE1senOC9/9XkC/OJiu8FwNEFJb7XJ7tYyHgx2EuVBehQJcaBc3 P+7PvaDA1szvLe2cJTCAKdZCL+8y1bCzCxIYvRy5kDn0d7lj+P45UfInz6ps++gf R4HlRWVTZAXqEDatc76678YuGeXIlbD7G0mdilr+KLGCEZCjUexTY7qLBtziL9j4 er1uWUmHCgNGWgl9CGlQHGu7qjBxVSElH7lZwNrGTN4Trkgi9qnYM74pC9AjVC1z ONy5K+sgSUVTzWnexJdWRAlNiel+84yv21rN9X53hhDvAI+PSRYpOvA9W4bZ5pG8 D0HlEi9XX+1p1wSvLHkGfurXNh3GhE2D2qOfc5XIuRQonRaqJFgAwPESdQndsAFt jyT7z2AAHZ4ZKuXEoSKJlHBvZTkwR8pJKJhPr8xHiNzskDV/hGJDJT9bYDI/D2Nf i7HIDhtmQ5cZs/TIUFo50xKmp5waNeCMz8CHeUtPID4isOdKSl3WH4ZTfR/gwvJ0 Bz2ugv0rRdE= =7Y7T -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: creating kernel udebs from kernel-source
On Tue, Nov 30, 2004 at 11:21:33AM +0100, Sven Luther wrote: > > other way. This still doesn't mean that it is d-i task to workaround this > > kind of problems introducing extra sets of udebs > Well, how do you install on that box then, provided we can't fix the above > bug, if it is a bug ? > Me thinking that maybe we should use -smp variants for the power3 and power4 > d-i kernels. Why not (post-sarge)? The ia64 d-i kernels are already based on an smp flavor. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: creating kernel udebs from kernel-source
On Tue, Nov 30, 2004 at 10:40:24AM +0100, Sven Luther wrote: > > You don't generate udebs for each flavour because there > > is not necessarely the need for it. In the i386 example there is only > > one set of udebs coming from the -386- flavour. > Well, maybe, i am no expert on x86, but on powerpc, you need one set of > modules for each flavour, since they are using incompatible instruction set > optimization : powerpc (everything from 601 to the G4, passing by some > embedded processors), power3 (used in ibm rs6k, 64bit and more of a power than > powerpc processor), and power4/g4. > > | Like waldi said, it was around 200 packages 6 month ago, and > > | probably over 400 today, > > > > My request of being in CC has been ignored and I lost part of the > > messages. > Ah, missed that also. like said a current calulation brings a total of 739 > .udebs in all the debian kernel packages. Maybe some of it is overkill given > the small number of .udebs ubuntu has. Maybe you can have some insight here ? > > Or for example you don't need k7 udebs, since the 386 will do. > Sure, but this is because on x86 the flavours are mostly only different > optimization, but on other arches this is not the case. I believe that on > powerpc, m68k, mips/mipsel and arm at least, the different kernels are there > because of real incompatibilities, maybe for other this is the case also. We > speak more of subarches than flavours here really. > > There are clearly exceptions like ppc that needs more.. i don't disagree > > and i did never questioned this situation. > I believe that x86 is the exception here, while the other arches situation is > the norm, and even on x86, if you think about pure64, and 386/486 situation, > you would reconsider this, but then ubuntu probably don't care about such old > x86 hardware, and rightly so. alpha -- 1 subarch -- 29 kernel udebs arm -- 5 subarchs -- 28 udebs hppa -- 1 subarch -- 8 udebs i386 -- 2 subarchs -- 81 udebs ia64 -- 1 subarch -- 24 udebs m68k -- 7 subarchs -- 67 udebs mips -- 3 subarchs -- 29 udebs mipsel -- 4 subarchs -- 37 udebs powerpc -- 5 subarchs -- 127 udebs s390 -- 1 subarch -- 7 udebs sparc -- 2 subarchs -- 27 udebs At least of the kernel images that currently build-depend on kernel-tree-2.4.27-* (alpha, hppa, i386, ia64, s390, sparc -- I assume these would be the first to be integrated if the patch were accepted), i386 is actually on the high end of both flavors and total udebs. Taking all archs together, the number of kernel udebs across all architectures and flavours seems to be 464. If there is a limit on how many binary packages per source the archive can handle, that probably does blow out the limit. I thought the limit was only on the number of binaries in a changes file, but I could be wrong. It would also be nice if the number of flavors required for d-i would go down over time, but that remains to be seen. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: creating kernel udebs from kernel-source
On Tue, Nov 30, 2004 at 10:55:23AM +0100, Fabio Massimo Di Nitto wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Sven Luther wrote: > > | > | > |> |> | multiplied by the number of architectures plus the number of > |> | |> architectures having 2.6 kernels. |> |> ??? this makes no > |> sence to me at all. and we are only talking |> about one kernel. > |> |> |> You only multiply once by the number of arch. | | | Nope. > |> you have the 2.4 kernels and the 2.6 kernel, so you add the | > |> total number of kernels which is between the number of arches and > |> | two time the number of arches. > |> > |> The patch doesn't merge kernel-source-* into one big kernel > |> source that includes ver 1.0 to 2.8. It applies to only one > |> kernel source (let say 2.6.9) and from that one generate propers > |> udebs for the arch where it is building. > | > | > | Ok, my fault, so we still have all the 2.4 and all the 2.6 kernels, > | That still means 303 .udebs for the 2.6 kernels and 436 for the 2.4 > | ones. Not counting the .debs that needs to be generated too, which > | should amount to 10-20 packages, if i am not mistaken (powerpc 2.6 > | has 20, and 2.4 has 37, while i386 2.4 has 23). > > Yes but the control file that is generated doesn't include all of them > at the same time. That's the whole point of it. You still get control > files x arch. That reduces the amount of binary packages processed > in the run only to the ones that are actually generated. You will > never get 30 udebs together. Ok, i will let those familiar with this problem (Kamion, joeyh, waldi i think) take over here, since i don't know the details of the problem. > |> | Actually, you have to take every available flavours as you | > |> mentioned above. On powerpc this is 5 for 2.4 kernels and 3 for > |> 2.6 | ones for a total of 8. (2.4 : powerpc, powerpc-small, > |> power3, | power4, apus, 2.6: powerpc, power3, power4, soon to > |> come ppc64 | iserie-legacy, generic and generic-power4 > |> additionally, and i have | had at least one case where the UP > |> kernel failed and a SMP kernel | is needed, so maybe we should > |> double some of these). > |> > |> You don't build udes for all the possible flavours simply because > |> there is no need to. You build udebs only for the minimal amount > |> that you need. > | > | > | Sure you do, since these kernels are *incompatible* on the > | instruction level set. And i wish you much luck trying to modprobe > | a powerpc module into a power4 kernel. Or in an apus kernel for > | that matter. > > We are saying the same thing Sven, if on ppc you need 3 or 4 > flavours it is ok, but there is no need to generate udebs for > the -smp versions (as example). There is really no point since later > the installer > will take care of installing the proper kernel for the machine. Except on the said power3 box, where the -smp kernel worked, but there somehow was a bug or something in the -up one which failed to boot. > I am not into ppc as you are but let's make a netrual example: > > arch foo has 20 kernel flavours, like foo32 foo64 + their -smp variants > and whatever you want to add to it, but all of them can boot and install > from a subset of them, like foo32 and foo64, you don't need to build This is only the x86 exception. on other arches, this is not the case. Not on powerpc, not on mips, not on m68k, probably not on the rest of them too. On these, there is a separate kernel because it is needed, not because you want some random optimizations. Try to install on a m68k/pmac with a m68k/amiga kernel to take one example i am familiar with, and you will see whta i mean. > 20 sets of udebs, but just the common ones that can manage to boot > everything since the installer will make the proper decision later. No. This works for the -up against -smp ones, and maybe for the upcoming ppc64/generic and ppc64/generic-power4, but for the rest of it, they are trully separate kernel which will not run on boxes they are not meant to. I suppose a common installer kernel could be made on those arches, but it would amount to a *huge* amount of work, that is better spent elsewhere. > |> I doubt anybody will ever require -smp udebs, right? > | > | I was not counting those in the above, we don't build them yet, but > | i know of at least one power3 machine which worked fine with the > | -smp kernel, but failed with the -up one. So i would be cautious > | about this. > > That might easily bug in the kernel, because i can bring example in the Sure, probably a bug in the sym53cxxx driver or something, not sure though. > other way. This still doesn't mean that it is d-i task to workaround this > kind of problems introducing extra sets of udebs Well, how do you install on that box then, provided we can't fix the above bug, if it is a bug ? Me thinking that maybe we should use -smp variants for the power3 and power4 d-i kernels. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED]
Re: creating kernel udebs from kernel-source
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Sven Luther wrote: | | |> |> | multiplied by the number of architectures plus the number of |> | |> architectures having 2.6 kernels. |> |> ??? this makes no |> sence to me at all. and we are only talking |> about one kernel. |> |> |> You only multiply once by the number of arch. | | | Nope. |> you have the 2.4 kernels and the 2.6 kernel, so you add the | |> total number of kernels which is between the number of arches and |> | two time the number of arches. |> |> The patch doesn't merge kernel-source-* into one big kernel |> source that includes ver 1.0 to 2.8. It applies to only one |> kernel source (let say 2.6.9) and from that one generate propers |> udebs for the arch where it is building. | | | Ok, my fault, so we still have all the 2.4 and all the 2.6 kernels, | That still means 303 .udebs for the 2.6 kernels and 436 for the 2.4 | ones. Not counting the .debs that needs to be generated too, which | should amount to 10-20 packages, if i am not mistaken (powerpc 2.6 | has 20, and 2.4 has 37, while i386 2.4 has 23). Yes but the control file that is generated doesn't include all of them at the same time. That's the whole point of it. You still get control files x arch. That reduces the amount of binary packages processed in the run only to the ones that are actually generated. You will never get 30 udebs together. | |> | Actually, you have to take every available flavours as you | |> mentioned above. On powerpc this is 5 for 2.4 kernels and 3 for |> 2.6 | ones for a total of 8. (2.4 : powerpc, powerpc-small, |> power3, | power4, apus, 2.6: powerpc, power3, power4, soon to |> come ppc64 | iserie-legacy, generic and generic-power4 |> additionally, and i have | had at least one case where the UP |> kernel failed and a SMP kernel | is needed, so maybe we should |> double some of these). |> |> You don't build udes for all the possible flavours simply because |> there is no need to. You build udebs only for the minimal amount |> that you need. | | | Sure you do, since these kernels are *incompatible* on the | instruction level set. And i wish you much luck trying to modprobe | a powerpc module into a power4 kernel. Or in an apus kernel for | that matter. We are saying the same thing Sven, if on ppc you need 3 or 4 flavours it is ok, but there is no need to generate udebs for the -smp versions (as example). There is really no point since later the installer will take care of installing the proper kernel for the machine. I am not into ppc as you are but let's make a netrual example: arch foo has 20 kernel flavours, like foo32 foo64 + their -smp variants and whatever you want to add to it, but all of them can boot and install from a subset of them, like foo32 and foo64, you don't need to build 20 sets of udebs, but just the common ones that can manage to boot everything since the installer will make the proper decision later. |> I doubt anybody will ever require -smp udebs, right? | | | I was not counting those in the above, we don't build them yet, but | i know of at least one power3 machine which worked fine with the | -smp kernel, but failed with the -up one. So i would be cautious | about this. That might easily bug in the kernel, because i can bring example in the other way. This still doesn't mean that it is d-i task to workaround this kind of problems introducing extra sets of udebs Fabio - -- Self-Service law: The last available dish of the food you have decided to eat, will be inevitably taken from the person in front of you. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQIVAwUBQaxDiFA6oBJjVJ+OAQIQ+xAAiTl9VOIxut8zA2aDsvdjwN7TZgp8e0QW bCOBqYd+rE0duZG3iYJ5BFZrcFkrf7OOyNjqHsxqfAsn4csnq7XWIOpcq2aZ9qjw 5GUFXzNEKzYQEz7j/jLfWO7DyacOA6t0C/3f1lrY+rZ2cDbqZdDnkNp0y9U+4lQn w1VYfBp1DGe6q3bQJY0vMgmTxFRefNdED4q26YJm357pglton238qEjz28StJ2u2 xFXiuxBrHAiQs1UQ9gdrhfqJBAykt7SlrLEGFghy5WKtqKabjSVFyFnDKrVmFN18 bmTNPB1kMplZDR8Yj4cSpkqEoTOnScpISumIf0ipTY3vftz5gdndshyVniwXSPwL MRLssa7V0a8fXznk5Vjp/Jec5r6U3eAFPJOIqpgGslThggcCmhPOZOrGD8uUJZ7d 779+J6delelRJQujsE+nx3h819OFyNeH9uD/cFRd3dD65YDKfowDdeOZy5GScl9K ZQCrSV0JGb0FHzZNCDbgiUa4ZCpmReRnyOSbFYAerstyGCvfQ7ZYdHTGFCGckpSG 1hIc8b6GkBK6QTy2zIChz5CPttM89qZJlwg8G2H/ZjQ8YPFfTByqb+Ij5of3ROMD K4WFBC1kKJKSQyv8CufqUmtPaTUfy/zHOCw6auVMSOB5EeNiY3EbAvNmB+CHBYlY ZJZWwHI4PHU= =aMVy -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: creating kernel udebs from kernel-source
On Tue, Nov 30, 2004 at 10:14:27AM +0100, Fabio Massimo Di Nitto wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Sven Luther wrote: > > | On Tue, Nov 30, 2004 at 09:17:45AM +0100, Fabio Massimo Di Nitto > | wrote: > | > |> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > |> > |> Hi Sven, > |> > |> Sven Luther wrote: > |> > |> | | Imagine all the .udebs for all the modules plus the kernel, > |> > |> Let say for example that i386 builds 14 debs (386, 686, 686-smp, > |> k7 and k7-smp flavours) + 1 _all.deb (the docs). linux-kernel-di > |> generates approx 40 udebs. > |> > |> That means 55 binary packages (and i would say in the worst case > |> since i386 is one of the arch that generates more modules than > |> any other iirc) > | > | > | Oh, no, you are oh so wrong. you forgot all the modules .udeb, and > | they are loads of them. > > Sven chill down before accounsing people to be so wrong.. Come on, it was not meant so, if i have offended you, i apologize about it, the language barrier or something. > the numbers above includes kernel udebs and modules udebs for i386 > in the flavours (from the ubuntu archive that builds what i wrote > above and before). debian i386 package has 81 .udebs for 2.4 kernels and 41 for 2.6 ones, for a total of 122 .udebs. > You don't generate udebs for each flavour because there > is not necessarely the need for it. In the i386 example there is only > one set of udebs coming from the -386- flavour. Well, maybe, i am no expert on x86, but on powerpc, you need one set of modules for each flavour, since they are using incompatible instruction set optimization : powerpc (everything from 601 to the G4, passing by some embedded processors), power3 (used in ibm rs6k, 64bit and more of a power than powerpc processor), and power4/g4. > | Like waldi said, it was around 200 packages 6 month ago, and > | probably over 400 today, > > My request of being in CC has been ignored and I lost part of the > messages. Ah, missed that also. like said a current calulation brings a total of 739 .udebs in all the debian kernel packages. Maybe some of it is overkill given the small number of .udebs ubuntu has. Maybe you can have some insight here ? > |> | multiplied by the number of architectures plus the number of | > |> architectures having 2.6 kernels. > |> > |> ??? this makes no sence to me at all. and we are only talking > |> about one kernel. > |> > |> You only multiply once by the number of arch. > | > | > | Nope. you have the 2.4 kernels and the 2.6 kernel, so you add the > | total number of kernels which is between the number of arches and > | two time the number of arches. > > The patch doesn't merge kernel-source-* into one big kernel source > that includes ver 1.0 to 2.8. > It applies to only one kernel source (let say 2.6.9) and from that one > generate propers udebs for the arch where it is building. Ok, my fault, so we still have all the 2.4 and all the 2.6 kernels, That still means 303 .udebs for the 2.6 kernels and 436 for the 2.4 ones. Not counting the .debs that needs to be generated too, which should amount to 10-20 packages, if i am not mistaken (powerpc 2.6 has 20, and 2.4 has 37, while i386 2.4 has 23). > | Actually, you have to take every available flavours as you > | mentioned above. On powerpc this is 5 for 2.4 kernels and 3 for 2.6 > | ones for a total of 8. (2.4 : powerpc, powerpc-small, power3, > | power4, apus, 2.6: powerpc, power3, power4, soon to come ppc64 > | iserie-legacy, generic and generic-power4 additionally, and i have > | had at least one case where the UP kernel failed and a SMP kernel > | is needed, so maybe we should double some of these). > > You don't build udes for all the possible flavours simply because > there is > no need to. You build udebs only for the minimal amount that you need. Sure you do, since these kernels are *incompatible* on the instruction level set. And i wish you much luck trying to modprobe a powerpc module into a power4 kernel. Or in an apus kernel for that matter. > I doubt anybody will ever require -smp udebs, right? I was not counting those in the above, we don't build them yet, but i know of at least one power3 machine which worked fine with the -smp kernel, but failed with the -up one. So i would be cautious about this. > Or for example you don't need k7 udebs, since the 386 will do. Sure, but this is because on x86 the flavours are mostly only different optimization, but on other arches this is not the case. I believe that on powerpc, m68k, mips/mipsel and arm at least, the different kernels are there because of real incompatibilities, maybe for other this is the case also. We speak more of subarches than flavours here really. > There are clearly exceptions like ppc that needs more.. i don't disagree > and i did never questioned this situation. I believe that x86 is the exception here, while the other arches situation is the norm, and even on x86, if you think about pure64, and 386/486 situation
Re: creating kernel udebs from kernel-source
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Sven Luther wrote: | On Tue, Nov 30, 2004 at 09:17:45AM +0100, Fabio Massimo Di Nitto | wrote: | |> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 |> |> Hi Sven, |> |> Sven Luther wrote: |> |> | | Imagine all the .udebs for all the modules plus the kernel, |> |> Let say for example that i386 builds 14 debs (386, 686, 686-smp, |> k7 and k7-smp flavours) + 1 _all.deb (the docs). linux-kernel-di |> generates approx 40 udebs. |> |> That means 55 binary packages (and i would say in the worst case |> since i386 is one of the arch that generates more modules than |> any other iirc) | | | Oh, no, you are oh so wrong. you forgot all the modules .udeb, and | they are loads of them. Sven chill down before accounsing people to be so wrong.. the numbers above includes kernel udebs and modules udebs for i386 in the flavours (from the ubuntu archive that builds what i wrote above and before). You don't generate udebs for each flavour because there is not necessarely the need for it. In the i386 example there is only one set of udebs coming from the -386- flavour. | Like waldi said, it was around 200 packages 6 month ago, and | probably over 400 today, My request of being in CC has been ignored and I lost part of the messages. |> | multiplied by the number of architectures plus the number of | |> architectures having 2.6 kernels. |> |> ??? this makes no sence to me at all. and we are only talking |> about one kernel. |> |> You only multiply once by the number of arch. | | | Nope. you have the 2.4 kernels and the 2.6 kernel, so you add the | total number of kernels which is between the number of arches and | two time the number of arches. The patch doesn't merge kernel-source-* into one big kernel source that includes ver 1.0 to 2.8. It applies to only one kernel source (let say 2.6.9) and from that one generate propers udebs for the arch where it is building. | Actually, you have to take every available flavours as you | mentioned above. On powerpc this is 5 for 2.4 kernels and 3 for 2.6 | ones for a total of 8. (2.4 : powerpc, powerpc-small, power3, | power4, apus, 2.6: powerpc, power3, power4, soon to come ppc64 | iserie-legacy, generic and generic-power4 additionally, and i have | had at least one case where the UP kernel failed and a SMP kernel | is needed, so maybe we should double some of these). You don't build udes for all the possible flavours simply because there is no need to. You build udebs only for the minimal amount that you need. I doubt anybody will ever require -smp udebs, right? Or for example you don't need k7 udebs, since the 386 will do. There are clearly exceptions like ppc that needs more.. i don't disagree and i did never questioned this situation. |> | | That was by far the most .udebs any package could hold, and |> it did | break. |> |> eh? how? what is difference of having 40 udebs from package foo |> or 40 udebs + 15 debs from package bar? | | | The difference is between having (in the powerpc case) 114 .udebs | in one package and 127 in another, over having 241 in the conjunct | package, which breaks the packaging tool if i am not wrong. Are you mixing 2.4 and 2.6? Fabio - -- Self-Service law: The last available dish of the food you have decided to eat, will be inevitably taken from the person in front of you. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQIVAwUBQaw58FA6oBJjVJ+OAQKM5A/+NNYY5wO4EwgKMBFBReDzf1r0YYpcl4Ky JpNjuxSUNKVcIrrOL3WuhjZi56Q2w6Du7U2iAMSxs3AJCr1eJAd6By0ECotmBjvi nisseOg0dHGsuvEE4rDQix0HSkxRO7zsfMawOvETcTTnsol+kODNDwTCbTS6OhM/ ZuB2YY6sf0p86FNFUGYnmWDzsQWgMotxgAucfn/0tiQnCerfDHZOwKHoEQ/Jcs/C nXMKosk6sX4ZnMbKxq/h5r2AsNf7cGqmca86R44+GzSDPkb5Zt++LFuXkH+iaF7M OhYy8uJrKHfeananuD/dyHh9niVJhL1idYd+xkXQgWvG/OtJdll+/qhuIUdvH9PO rr3yAeVQyD1Te1q5Wjl4d0fah9iHpo760nT4HCKdCPpmAuIloAe8KPf9yTYYkuUM z80XVFx2cOeZXLez2nU24/iHxixY8wr2gDlQDwh7Y2S7NrhvN2HL357jSgsu1OJo om4I2C6cBlUIQ9cIWUz6PltktkHf30bX7ujZ6ZsbUNasRpYqJWO+ePkzrt4y3/6D p1shxnclUI3IhyHcYyd2YAR5ge7j4+wEU3/bDiZi2/k04a9yzLJIDG55jX70tnEa r5L/2tQMoH+kyS1+edmz1oknXn4vOjxABknEE/FEQNnMlQRDWpqqQFLcMCtAdzk6 aGbTNfcw9m4= =+O+f -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: creating kernel udebs from kernel-source
On Mon, Nov 29, 2004 at 05:51:56PM +0100, Bastian Blank wrote: > On Mon, Nov 29, 2004 at 02:55:20PM +0100, Fabio Massimo Di Nitto wrote: > > I am not really sure what you are talking about, but we have packages > > in the archive generating way more binaries that what this solution does. > > No, we don't. We had this with linux-kernel-di. This package produced > about 200 binary packages. The current state will be about 400. A quick calculation from : http://qa.debian.org/[EMAIL PROTECTED] gives me a sum of 739 packages for all 11 architectures, counting both 2.4 and 2.6 kernels. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: creating kernel udebs from kernel-source
On Tue, Nov 30, 2004 at 09:17:45AM +0100, Fabio Massimo Di Nitto wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hi Sven, > > Sven Luther wrote: > > | > | Imagine all the .udebs for all the modules plus the kernel, > > Let say for example that i386 builds 14 debs (386, 686, 686-smp, > k7 and k7-smp flavours) + 1 _all.deb (the docs). > linux-kernel-di generates approx 40 udebs. > > That means 55 binary packages (and i would say in the worst case > since i386 is one of the arch that generates more modules than > any other iirc) Oh, no, you are oh so wrong. you forgot all the modules .udeb, and they are loads of them. Like waldi said, it was around 200 packages 6 month ago, and probably over 400 today, > | multiplied by the number of architectures plus the number of > | architectures having 2.6 kernels. > > ??? this makes no sence to me at all. and we are only talking about one > kernel. > > You only multiply once by the number of arch. Nope. you have the 2.4 kernels and the 2.6 kernel, so you add the total number of kernels which is between the number of arches and two time the number of arches. Actually, you have to take every available flavours as you mentioned above. On powerpc this is 5 for 2.4 kernels and 3 for 2.6 ones for a total of 8. (2.4 : powerpc, powerpc-small, power3, power4, apus, 2.6: powerpc, power3, power4, soon to come ppc64 iserie-legacy, generic and generic-power4 additionally, and i have had at least one case where the UP kernel failed and a SMP kernel is needed, so maybe we should double some of these). This makes 8 powerpc flavours, And a quick look at : http://packages.qa.debian.org/l/linux-kernel-di-powerpc-2.6.html Will show you that powerpc has 114 .udebs, and the 2.4 kernels have 127. Mmm, easier to get an idea on : http://qa.debian.org/[EMAIL PROTECTED] So, for powerpc, this is already 241 .udeb packages, and it is only one arch out of 11. Do think become clearer now ? Or maybe i am missing something ? > | > | That was by far the most .udebs any package could hold, and it did > | break. > > eh? how? what is difference of having 40 udebs from package foo or > 40 udebs + 15 debs from package bar? The difference is between having (in the powerpc case) 114 .udebs in one package and 127 in another, over having 241 in the conjunct package, which breaks the packaging tool if i am not wrong. > | Ask Colin, he knows about that. > > No please Sven, don't start bouncing people around. Give me a reference > or dig one for me. It is working here and nothing is broken. You are welcome to look over the debian-boot archive though, but i belive Colin, Joeyh and Waldi implemented the thing, so they would be the best to ask about this, and since Colin works on ubuntu with you, he is the natural person to ask, also see above about the problems in your calculation. Given the powerpc packages, i believe even Waldi's 400 .udebs is grossly understated. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: creating kernel udebs from kernel-source
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Sven, Sven Luther wrote: | | Imagine all the .udebs for all the modules plus the kernel, Let say for example that i386 builds 14 debs (386, 686, 686-smp, k7 and k7-smp flavours) + 1 _all.deb (the docs). linux-kernel-di generates approx 40 udebs. That means 55 binary packages (and i would say in the worst case since i386 is one of the arch that generates more modules than any other iirc) | multiplied by the number of architectures plus the number of | architectures having 2.6 kernels. ??? this makes no sence to me at all. and we are only talking about one kernel. You only multiply once by the number of arch. | | That was by far the most .udebs any package could hold, and it did | break. eh? how? what is difference of having 40 udebs from package foo or 40 udebs + 15 debs from package bar? | Ask Colin, he knows about that. No please Sven, don't start bouncing people around. Give me a reference or dig one for me. It is working here and nothing is broken. Regards, Fabio - -- Self-Service law: The last available dish of the food you have decided to eat, will be inevitably taken from the person in front of you. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQIVAwUBQawsp1A6oBJjVJ+OAQL0DhAAt549pMe+5HDG3lQv4bK/AGJYkJm0gPqk GNSWZE+H/HhIZZ7VDs0+SMxW+QO5Lm7nW7S+Z3oOslgGUYvI9ziK2qmseOk6s4rz NNOjZq4vez55R8oJD/mpUv6oqlJYLFuAxDLossGPrF9Sh3E+wc+buk7W5sy606r+ G2nu+Nm+dl75cPuaZ23DjD1/P3dNeema31kZNuNJsvUep5YOafIvRhIzOVMVgDhI mmfZkIpbuGM9WXOjlj5QM+d2ckJvkUauYDMcPuC9wvOEwz1FVmkPvDug/CtPr/Xp gUVZ/fPcx0O/DPpeQVV4C03KlRmavQOpX+QsYLOlm0pxRrmodlduMLZ0lF2nBay+ Ukbv08tlHsN3r/3DcWd8jQV7nijt41HKwH0IUWeZJAsyv1ajO5tCqrq9VmHUy9xH P0Ht/bmrGt5G/tHSsGq0n4U24DtfVnLpnAGUoKg+RKWJjE4f+/6lZBmeOK2Ue4Z5 SOAAB34RvgEEtvz319c5h9DaVSrKOmr/eVboJlqO8+Wd9eXmkLjgwrnSur53Yj97 8V7UVQd0m5NfwiP1j5++Wdq0wfK1ZAzTDx3XPFFU9MUVUN+JNqzocpMcESnsVq3i axYjoPSd9MaaJt8ScR6+m613fNHjje6Sl5eNnR8q01VQ3zeC4IUer55Kk+6h6S3o LtyBdJAa2Xo= =JGDL -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: creating kernel udebs from kernel-source
On Mon, Nov 29, 2004 at 06:23:32PM -0500, Andres Salomon wrote: > - Having all kernel-images generated from k-s is a goal; I realize it's > not immediately obtainable, given the current state of some of the kernel > archs. > While hppa is improving... 3.4M off 2.4.27 fuzzy 636K off 2.6.9 > - I'm not forcing this upon anyone; port maintainers can maintain images > however they see fit, because no one has any intentions of stepping in if > they throw their hands up and quit. However, I do believe this will make > everyones lives easier. k-s contains split up patches (in many cases w/ > bk changeset references and other such comments) that make forward porting > to new kernels much easier. I've no objection to working (it would be more work) out of the kernel-source tree. hppa's diff to the non-arch code are not particularly intrusive, if I remember correctly (and at a cursory glance of lsdiff). Cheers, Kyle -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: creating kernel udebs from kernel-source
Andres Salomon wrote: [snip] > > This "Hooray, it compiles!" approach is unlikly to ever produce an > > useful kenrel for architectures not maintained in mainline. > > > > I fail to see why not. How is it we can keep patches in arch-specific > k-i packages, but keeping them in k-s won't work? As already mentioned on IRC, I misunderstood some parts of your mail an thought the idea was to abolish the kernel-source Package as well. > You mentioned the fact > that mips upstream is essentially a fork of Linus' tree; I suspect this is > the case simply because they wait so long before resynchs, The situation improved significantly for 2.6, however, there's still need to mips-specific patches not in mainline. > and when they > do attempt to synch, they send large patches that Linus rejects. Rather: They send large patches and Linus accepts. :-) > If we're > going to be maintaining and dealing w/ these patches anyway, why not just > feed split out changes to Linus? The easy ones are probably already sent, the hard ones have usually a reason why they shouldn't go upstream as is. The stuff in the middle needs some polishing like updates to more modern kernel interfaces. Of course, I don't oppose to send patches to kernel.org from k-s, but I think it is more efficient to do this between linux-mips.org and kernel.org. > It makes everyone's life easier; for the > next kernel revision, the patch has been merged; mips upstream has less of > a diff between Linus' tree and theirs; and Linus and co. aren't being > bombarded w/ 2 meg patches. 2 MB is the overall diff size, sending it as a single patch would clearly be insane. :-) > As I mentioned above, that's just a goal to work towards. It may work, it > may not. However, a bunch of k-i packages consist mostly of > debian packaging and config files. There's no reason to have those as > separate. For some architectures it clearly makes sense to drop those packages. I just want to keep them for architectures where they are more useful. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: creating kernel udebs from kernel-source
Andres Salomon wrote: [snip] > b) Get archs autobuilt, so that they don't lag behind. They may not boot, > but they'll at least compile. Given the way that kernel development > upstream is happening, the development process will look something like > this: 1) release k-s 2.6.10-1, upload i386 images, 2) autobuilders for all > other archs attempt to build arch-specific images, 3) many fail; the > kernel is therefore kept out of etch, 4) k-s 2.6.10-3 is uploaded (after > -2 fixes some build failures as well), 5) autobuilders successfully build > for all archs, 6) testers report bugs for archs that don't work; > obviously, an arch-specific RC bug will keep a kernel out of etch, 7) > after developers fix arch-specific bugs, k-s 2.6.10-4 is uploaded and > autobuilt, 8) k-s 2.6.10, now that it builds and runs on all (used) archs, > flows into etch. > Of course, there's a good chance there may be some arch breakage on a > rarely used arch, and the package gets into etch w/ the breakage; however, > I'd rather see that than the arch sticking w/ a kernel version that's a > year old, has known security holes, but boots. This "Hooray, it compiles!" approach is unlikly to ever produce an useful kenrel for architectures not maintained in mainline. > 3) Simplify packaging. Dump the kernel-tree-X crap, etc. The cons of > this are that one will no longer be allowed to build against an older, > known-working k-s. Which means those architectures will still need a source package they can build-depend on, generated from the -image source. This is a minimal workload reduction for the kernel team but an increase for the security team. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: creating kernel udebs from kernel-source
Hi Fabio, Thanks for feeding changes back to d-k. No one else in Ubuntu has bothered to do that thus far... On Mon, 29 Nov 2004 08:35:03 +0100, Fabio Massimo Di Nitto wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hi everybody, > ~right last week i have been asked to merge the linux-kernel-di-* > packages > directly into the kernel-source (that in Ubuntu we call linux-source) > so that > all the different binary packages are built from one and only one source. > Basically killing kernel-image packages (that was done a few months back) > and now linux-kernel-di-* > Killing kernel-image packages is something that we've been planning post-sarge (if I hadn't gotten caught up doing other stuff, I would've started w/ 2.6.9 last week). The goals are: a) Kill all the separate image packages, so that instead of requiring a psuedo-package in the BTS (w/ no versioning support), we can view all bugs for a specific kernel version (since they all come from the same source package). b) Get archs autobuilt, so that they don't lag behind. They may not boot, but they'll at least compile. Given the way that kernel development upstream is happening, the development process will look something like this: 1) release k-s 2.6.10-1, upload i386 images, 2) autobuilders for all other archs attempt to build arch-specific images, 3) many fail; the kernel is therefore kept out of etch, 4) k-s 2.6.10-3 is uploaded (after -2 fixes some build failures as well), 5) autobuilders successfully build for all archs, 6) testers report bugs for archs that don't work; obviously, an arch-specific RC bug will keep a kernel out of etch, 7) after developers fix arch-specific bugs, k-s 2.6.10-4 is uploaded and autobuilt, 8) k-s 2.6.10, now that it builds and runs on all (used) archs, flows into etch. Of course, there's a good chance there may be some arch breakage on a rarely used arch, and the package gets into etch w/ the breakage; however, I'd rather see that than the arch sticking w/ a kernel version that's a year old, has known security holes, but boots. 3) Simplify packaging. Dump the kernel-tree-X crap, etc. The cons of this are that one will no longer be allowed to build against an older, known-working k-s. Kernel config handling will be unified (probably something similar to what the powerpc images do), so that there's not a bunch of out-of-sync config options between different archs. I would eventually like to use a cdbs-like build system for the kernel stuff, but that's highly dependent upon cdbs gaining some necessary functionality that it doesn't currently have (and allowing this to be implemented in a clean fashion). > The resulting diff of the merge (based on our linux-source) can be found > here: > > http://people.ubuntulinux.org/patches/kernel_udebs_from_kernel_source.diff > Patch saved on my hard drive for posterity. :) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: creating kernel udebs from kernel-source
Fabio Massimo Di Nitto wrote: [snip] > | You can do this in ubuntu only because you have only 2-3 arches to > | worry about, > > The model can be adapted. I am not pushing a patch to force our > solution, but to give back the code that has been done and tested. > It is up to the 2 teams to decide what to do with it. > Clearly applying it to 11 arch is technically possible, it of course > require more coordinations between people, and that is something > nobody can give you with a patch ;) It also requires a mostly common upstream for all architectures. Historically, this assumption broke down, and was the reason to introduce separate kernel-source/kernel-tree .debs. Kernel 2.6 has improved the situation, but not enough to go back to a single source package. > | and are thus not limited by the number of packages the packaging > | tools can handle, right ? > > Nope.. the list of binaries that are generated per each arch is > still relatively small. This suggests those udebs can't be cross-built easily. linux-kernel-di can (at least it is supposed to support this), which pushed the limit of the packaging tools. This in turn triggered the split in several linux-kernel-di- packages. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: creating kernel udebs from kernel-source
On Mon, Nov 29, 2004 at 02:55:20PM +0100, Fabio Massimo Di Nitto wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Sven Luther wrote: > > |> > |> The model can be adapted. I am not pushing a patch to force our > |> solution, but to give back the code that has been done and > |> tested. It is up to the 2 teams to decide what to do with it. > |> Clearly applying it to 11 arch is technically possible, it of > |> course require more coordinations between people, and that is > |> something nobody can give you with a patch ;) > | > | > | Well, sure, i was wondering about two things though : > | > | > | 2) a little change to the powerpc or x86 kernel will mean a full > | rebuild for m68k or arm too, right ? Maybe not an issue for pure > | udebs things though. > > > That is correct. As everything in this world you win on something and > lose on something else. > > The cons is that, clearly, each time you upload the kernel it will build > everywhere, even if the change is unrelated to the arch you are building > on. > > On the otherside, you might want to think to security or bug fixes > that needs to spread across all archs. One upload the fix is > "automagically" > redistributed everywhere. From the source to the last udeb. > > As it is now, someone needs to upload kernel-source, someone needs > to wait for it on the mirror and upload kernel-image and upload > kernel-image. > The d-i team, at the end of the wheel, needs to wait kernel-image and > then upload linux-kernel-di... > The last 2 bits repeated for N archs. > But i guess you already know this :-) > > |> - - the second one is slightly more dynamic and it involves the > |> addition ~ of the udebs to the control file at build time, but > |> they are still arch specific. > |> > |> So at the end you get nothing more than what you had before, just > |> from the same source. > | > | > | Which i was led to believe that the packaging tools could not cope > | with 6 month or so ago. Maybe i am wrong though ? > > I am not really sure what you are talking about, but we have packages > in the archive generating way more binaries that what this solution does. Imagine all the .udebs for all the modules plus the kernel, multiplied by the number of architectures plus the number of architectures having 2.6 kernels. That was by far the most .udebs any package could hold, and it did break. Ask Colin, he knows about that. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: creating kernel udebs from kernel-source
On Mon, Nov 29, 2004 at 02:55:20PM +0100, Fabio Massimo Di Nitto wrote: > I am not really sure what you are talking about, but we have packages > in the archive generating way more binaries that what this solution does. No, we don't. We had this with linux-kernel-di. This package produced about 200 binary packages. The current state will be about 400. Bastian -- If some day we are defeated, well, war has its fortunes, good and bad. -- Commander Kor, "Errand of Mercy", stardate 3201.7
Re: creating kernel udebs from kernel-source
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Sven Luther wrote: |> |> The model can be adapted. I am not pushing a patch to force our |> solution, but to give back the code that has been done and |> tested. It is up to the 2 teams to decide what to do with it. |> Clearly applying it to 11 arch is technically possible, it of |> course require more coordinations between people, and that is |> something nobody can give you with a patch ;) | | | Well, sure, i was wondering about two things though : | | | 2) a little change to the powerpc or x86 kernel will mean a full | rebuild for m68k or arm too, right ? Maybe not an issue for pure | udebs things though. That is correct. As everything in this world you win on something and lose on something else. The cons is that, clearly, each time you upload the kernel it will build everywhere, even if the change is unrelated to the arch you are building on. On the otherside, you might want to think to security or bug fixes that needs to spread across all archs. One upload the fix is "automagically" redistributed everywhere. From the source to the last udeb. As it is now, someone needs to upload kernel-source, someone needs to wait for it on the mirror and upload kernel-image and upload kernel-image. The d-i team, at the end of the wheel, needs to wait kernel-image and then upload linux-kernel-di... The last 2 bits repeated for N archs. But i guess you already know this :-) |> - - the second one is slightly more dynamic and it involves the |> addition ~ of the udebs to the control file at build time, but |> they are still arch specific. |> |> So at the end you get nothing more than what you had before, just |> from the same source. | | | Which i was led to believe that the packaging tools could not cope | with 6 month or so ago. Maybe i am wrong though ? I am not really sure what you are talking about, but we have packages in the archive generating way more binaries that what this solution does. Fabio - -- Self-Service law: The last available dish of the food you have decided to eat, will be inevitably taken from the person in front of you. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQIVAwUBQasqRVA6oBJjVJ+OAQLqgBAAgdyAl6Vyhl2xWXUM3eqwSkaqaS2YIsGV YlP3z+dlrBpUzhMyF0JIkT8VNnIKX2Pky6jpfSYq5BFEqQcZJEAqZwwuJKW3Gmvj xdU8oHggCC+5pFJK/2gV/8OmaplgwclndBTw4JUihfI1sGTMGjOT6eNj+i8WeKvL PLrW5DI317Cn3mXfb8Sge8lxGXXuaXJgQnrLahXTEdNgSB6QYX1kWnDvNk/T8NCw Y/nacNGiXpWxx0j/dAsmANfGzLq9bEC3nhiiH/qcfXUiKU52XjZyx2oIzEKB8PAZ httmQOK8qz8k69jsF6is83yKJk6an84z4vL+U/bHDrBxjoWUyWQlJNh8T6n/wQo5 hvrjlB63nU1p9GWygQsAl9bLQEuKHxMQM3HLrNRe1qB/HclzygY4Lxc6xa0c6lbC zX+9pdyUBDDauw984qoI8KfOPd8nVLjFIsrR6RRn1+a1Kl7Yd0ZuUWniknjJSO0t APlx8BHPiFJV5/n5Ra43m+JYzuhAq11IaaHGARS+3bIp9aHxatHwv2En8qqKYovm 2fBhBWvGeQidIAr0zYTgEDOX02s0x7DvvoJ/SKFIPdBnRULEHJFaPaz/l2BTPF0R ycZFNA26VvhE7+gcmdsXQQbl1a8ZE9MK5eZ5dgpL8It31uoM9Q0xrrEYNRoT6FmB qV+nfB/wLoU= =jbqj -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: creating kernel udebs from kernel-source
On Mon, Nov 29, 2004 at 01:46:24PM +0100, Fabio Massimo Di Nitto wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Sven Luther wrote: > > | On Mon, Nov 29, 2004 at 08:35:03AM +0100, Fabio Massimo Di Nitto > | wrote: > | > |> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > |> > |> Hi everybody, ~right last week i have been asked to merge the > |> linux-kernel-di-* packages directly into the kernel-source (that > |> in Ubuntu we call linux-source) so that all the different binary > |> packages are built from one and only one source. Basically > |> killing kernel-image packages (that was done a few months back) > |> and now linux-kernel-di-* > |> > |> The resulting diff of the merge (based on our linux-source) can > |> be found here: > | > | > | You can do this in ubuntu only because you have only 2-3 arches to > | worry about, > > The model can be adapted. I am not pushing a patch to force our > solution, but to give back the code that has been done and tested. > It is up to the 2 teams to decide what to do with it. > Clearly applying it to 11 arch is technically possible, it of course > require more coordinations between people, and that is something > nobody can give you with a patch ;) Well, sure, i was wondering about two things though : 1) the below mentioned technical problems, but you may have worked around this, not sure though. 2) a little change to the powerpc or x86 kernel will mean a full rebuild for m68k or arm too, right ? Maybe not an issue for pure udebs things though. > | and are thus not limited by the number of packages the packaging > | tools can handle, right ? > > Nope.. the list of binaries that are generated per each arch is > still relatively small. > > The control files grows in 2 directions: > > - - the first one is static due to merging the different kernel-image-* > ~ into one source, but you still generate the arch specific packages > ~ so the others are simply ignored. Which may be a hindrance to keep kernels in sync in the debian case. > - - the second one is slightly more dynamic and it involves the addition > ~ of the udebs to the control file at build time, but they are still > arch specific. > > So at the end you get nothing more than what you had before, just from the > same source. Which i was led to believe that the packaging tools could not cope with 6 month or so ago. Maybe i am wrong though ? > If you look at our pool for linux-source, you will see that the > binaries are nothing > more than what was before in the 3 splitted once. 3 is way less than 12 + the bunch of 2.6 kernels though. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: creating kernel udebs from kernel-source
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Sven Luther wrote: | On Mon, Nov 29, 2004 at 08:35:03AM +0100, Fabio Massimo Di Nitto | wrote: | |> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 |> |> Hi everybody, ~right last week i have been asked to merge the |> linux-kernel-di-* packages directly into the kernel-source (that |> in Ubuntu we call linux-source) so that all the different binary |> packages are built from one and only one source. Basically |> killing kernel-image packages (that was done a few months back) |> and now linux-kernel-di-* |> |> The resulting diff of the merge (based on our linux-source) can |> be found here: | | | You can do this in ubuntu only because you have only 2-3 arches to | worry about, The model can be adapted. I am not pushing a patch to force our solution, but to give back the code that has been done and tested. It is up to the 2 teams to decide what to do with it. Clearly applying it to 11 arch is technically possible, it of course require more coordinations between people, and that is something nobody can give you with a patch ;) | and are thus not limited by the number of packages the packaging | tools can handle, right ? Nope.. the list of binaries that are generated per each arch is still relatively small. The control files grows in 2 directions: - - the first one is static due to merging the different kernel-image-* ~ into one source, but you still generate the arch specific packages ~ so the others are simply ignored. - - the second one is slightly more dynamic and it involves the addition ~ of the udebs to the control file at build time, but they are still arch specific. So at the end you get nothing more than what you had before, just from the same source. If you look at our pool for linux-source, you will see that the binaries are nothing more than what was before in the 3 splitted once. Regards Fabio PS if any of the team as a proference for the followup, we can perhaps avoid to cross post. - -- Self-Service law: The last available dish of the food you have decided to eat, will be inevitably taken from the person in front of you. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQIVAwUBQasaHlA6oBJjVJ+OAQJa6w//b3vCl8ln6JSJwahD+T9xAcFDw3FUxbxU 2aTfQuQMy6k3tf8R38OVSQZsxZwC78gcXfnWlxX+dQTXbASkgkFYy3SvyQLDWUR9 6t1EU+Ms7xMXkoXjxV+nDjbFwF876QnsX5dyvEKP3KjQ4b6i2Tq/Oa5nlJ7v9bcv 3BOcUg8R21KetY6GJV+NOKgHpb96rECE6EaikreMfQA5jeRjDZiwcDKo74r07/Ur U/FFr0AkVHaFEPPrqyrKz7BkEStVKRwSjDAykqe0NCBXVQqKPkO6MVNmxOENmOai seKFCjHhA0tRHBkuCJtOybvGVnGi5EZ4QrxbHTLhJuODuZKgkWTRYKSGxXH14qrr fiSv/2lVA8Tm0OcILAdrI/UGjmOZWkslhIxyKBhzNT6c+32cHsM/CSds+RAR6TZ9 +33mYFR+62n4drE5hJQDo+SsLHKM1by9KuAh0tx9Z9eNTozO9QeGb6JHxWoVqE61 C15i+gxFsnD/YXzqSn7vbJNQGUaaixlNQtjWtI9V8kCIT3Jnf1Ag3gZ7EWXtkisf JK4CfKEPh5ofnUJblw/Wb1I6ysKm8NbIMArUdHRCxhicSoemQu6t9zoKjo1BqZgn yZg/fdFLh4BTEo7iaDjI7vg2Iavv37p1veahDajU5ySqs/gVq3v9w1OfFqKQHjqL 3pbD7YAUlPI= =RdmH -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: creating kernel udebs from kernel-source
On Mon, Nov 29, 2004 at 08:35:03AM +0100, Fabio Massimo Di Nitto wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hi everybody, > ~right last week i have been asked to merge the linux-kernel-di-* > packages > directly into the kernel-source (that in Ubuntu we call linux-source) > so that > all the different binary packages are built from one and only one source. > Basically killing kernel-image packages (that was done a few months back) > and now linux-kernel-di-* > > The resulting diff of the merge (based on our linux-source) can be > found here: You can do this in ubuntu only because you have only 2-3 arches to worry about, and are thus not limited by the number of packages the packaging tools can handle, right ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
creating kernel udebs from kernel-source
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi everybody, ~right last week i have been asked to merge the linux-kernel-di-* packages directly into the kernel-source (that in Ubuntu we call linux-source) so that all the different binary packages are built from one and only one source. Basically killing kernel-image packages (that was done a few months back) and now linux-kernel-di-* The resulting diff of the merge (based on our linux-source) can be found here: http://people.ubuntulinux.org/patches/kernel_udebs_from_kernel_source.diff There are 2 or 3 hackish bits around, mainly to workaround the way kernel-wedge thinks (we didn't want to fork it), but the general implementation works fine and it has been tested on 4 archs (3 Ubuntu official and one unofficial that has been merged after this patch). If you need any explanation on the different bits, please feel free to ask, and CC me on reply, since i am not subscribed to any of these 2 mailing lists. Regards, Fabio ps clearly i am crossposting since it involves both the team. - -- Self-Service law: The last available dish of the food you have decided to eat, will be inevitably taken from the person in front of you. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQIVAwUBQarRJVA6oBJjVJ+OAQLDFhAAiy0FzZCykmsTWykbwRQWCzdYaoHBFPrU VtSRnns5MIGmlexZ/+6z2kkmU/E9sM9tYVOuc2yRS2BM9p5ZBWEZMz4LpnkrJgnW y3tdVB8kISGWJjjSf+9IA/pPGZ9DCDy9Ww1YiDrqfUpO9o2QvPrEZdIt1oXeK+t6 tMxqciQnPemqt1u74SUhWz+uXTBA/FdRKlb99nkh2n2Ou+VNeMtJKY8QJ05hGeNo Pm1yzsy72Pha9qPfKV4jOqwX20ignUmMblqVb0zfecn0JZcjMbiEMB6DbLaal5qT uycVEuLr7Z3YepICKkIr+Z4kPZybSti20pG8UZDdTTnhBeAW+bGZHz9H2iJ/f10P ZOLi5IG9aWXxdy8aWSa3Na8Ly4ebwDi+GyuoK7eOjBlAY9Eg9veoq1KGbYe4OWlC sVIPuiW43B3k5YIsCE2XvNSVx5YvtYd7baSLAbpI9OQHOkYt5Jsw3ZKfQIBGdTqb 5oQq3UaYyFNSdSo7j67UTghadoLGh+SYLDsa4l0Q1W4Ma4wJAeyZpEN3pqZA2udI 6ABVsBe4/Ipg3UT1SPqh4D7Oo/oGmwnQeY4Q+X2hSNMvINNYYCq/U0yEML3z4klJ k7971+TagN63NEDYu3bT+6TOxGwcJAXr6tIuVOTY6h9gUKTytO90ckqziQQG0MfB YMc4dcw8Ojg= =lu/l -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
