Re: [gentoo-dev] Pending Removal of $KV
On Tue, 2006-07-11 at 07:24 +0900, Georgi Georgiev wrote: > - 23 only make .config checks (should be non-fatal anyway) I couldn't agree more. This bites us in the ass every single release. People who make .config checks fatal should be forced to maintain mozilla-* for a month... ;] > - 4 use linux-info to modify runtime behavior Hopefully, these will go away soon, too. Again, this is something that constantly bites us when it comes to releases. -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Pending Removal of $KV
maillog: 09/07/2006-17:17:59(+0100): John Mylchreest types > I've tried to clarify my point fairly well above, but the dependancy > is fairly strict by design. What in linux-mod except for my specific > example above would continue to work if there were no kernel sources > present? (I do of course know the answer but its rhetorical) > > To that end is the reason why the dependancy still exists. That said, > I'm open to persuasion. I'm having trouble putting my thoughts in order, so I'll just throw them out, hoping it would make some sense. - if linux-sources is a dependency, then the package usually would need to be rebuilt if the kernel configuration/sources change (linux-mod already faciliates that for a good reason) - even if an ebuild is being smart and is only using linux-info to throw informational messages, the sources dependency is still there - an ebuild should specify the linux-sources dependency on its own if it really needs the sources Having said that, out of the 62 packages that inherit linux-info and do not inherit linux-mod: - 23 only make .config checks (should be non-fatal anyway) - 9 install kernel modules (so they should rather inherit linux-mod) - 8 need the kernel sources to build, so they should probably inherit linux-mod as well - 6 have a DEPEND=virtual/linux-sources already - 4 use linux-info to modify runtime behavior - 2 are obsolete This is only the easily classifiable stuff, but it certainly does seem that the linux-sources dependency can be pulled out of the eclass. -- /\ Georgi Georgiev /\ You have a truly strong individuality. /\ \/[EMAIL PROTECTED]\/\/ /\ http://www.gg3.net/ /\/\ pgpd6vB3yLpHY.pgp Description: PGP signature
Re: [gentoo-dev] Pending Removal of $KV
On Tue, Jun 20, 2006 at 02:32:36PM +0200, "Kevin F. Quinn" <[EMAIL PROTECTED]> wrote: > > >>This is duplicating the superb efforts of the kernel team and of > > >>linux-info eclass. As such I would like to deprecate $KV in favor > > >>of using linux-info eclass. I don't see the need for portage to > > >>export $KV into the environment for all packages. > > Yes please. linux-info.eclass is great; does (almost) exactly what > should be done, i.e. depend on user-supplied kernel source & object > locations. Firstly, thanks for using it :) If you have any suggections (speculating based off the "Almost" part please feel free to talk to me about them and I'll see what I can do :) > > >>There are a few packages left that use this. There will be a > > >>tracker bug shortly. Mostly this mail is just a heads up ;) > > > But any kind of checks against something in $KERNEL_DIR are just > > > wrong, wrong, wrong. The only exception being when the ebuild is > > > building something *against* those sources (kernel modules, and > > > that's it). > > > > > > It's annoying to have virtual/linux-sources pulled as a dep of > > > gnupg, iptables or any other package that can do fine without them. > > I do agree virtual/linux-sources shouldn't be a dependency. The > ebuilds should depend on the existence of the kernel sources or > objects against which the package will be built, which can only be > detected in pkg_setup. To this end I think DEPEND should not be set in > linux-info.eclass. Additional to this linux-info is close to useless outside of an available linux-source tree. We do provide an interface which should very very rarely be used for running kernels get_running_version() and in this case I can see why the source-tree can be dropped, but I dont plan on doing so any time soon. Really this all stems back to gentoo policy regarding building/testing against kernel srctree/objtree which is as simple as anything requiring or depending on kernel sources should always use those which are pointed to by the "/usr/src/linux" symlink. This enabls us to build packages against a target, rather than current. Cross-compiling would be a nice example here. > > In many cases those packages are looking for a specific kernel > > feature to make sure support is enabled for it. > > > > You could argue that in the case where you aren't compiling against > > the kernel that support being enabled isn't critical, but that is a > > discussion you need to have with the package maintainers. > > I think it's wrong for ebuilds to refuse to build if support is missing > from the build system kernel. ebuilds should not be using the > configuration of the build system to decide whether to build pieces for > the target system (such decisions should be made via USE), and > certainly shouldn't die if run-time support isn't built on the build > system (unless the support is actually needed for the build process > itself, such that the build would fail). With linux-info.eclass you can They can optionally be non-fatal, and you can also call the API directly and handle it as required. > specify the location of the kernel tree to build against > (KBUILD_OUTPUT) and thus build for different kernel configurations as > appropriate (the default being the build system kernel, which makes > things simple for the common case where the target is the build system). > > In summary, I agree that $KV should disappear from portage, and that > anything that depends on kernel configuration should use > linux-info.eclass. Also I'd like to see the dependency on > virtual/linux-sources removed from linux-info.eclass. I've tried to clarify my point fairly well above, but the dependancy is fairly strict by design. What in linux-mod except for my specific example above would continue to work if there were no kernel sources present? (I do of course know the answer but its rhetorical) To that end is the reason why the dependancy still exists. That said, I'm open to persuasion. - John -- Role:Gentoo Linux Kernel Lead Gentoo Linux:http://www.gentoo.org Public Key: gpg --recv-keys 9C745515 Key fingerprint: A0AF F3C8 D699 A05A EC5C 24F7 95AA 241D 9C74 5515 pgpoFe9vpVj0r.pgp Description: PGP signature
Re: [gentoo-dev] Pending Removal of $KV
On Mon, Jun 19, 2006 at 11:13:33AM +, Alec Warner <[EMAIL PROTECTED]> wrote: > Portage currently exports $KV as the current kernel version. We detect > this by attempting to mess around with the things in /usr/src/linux > (.config, make files, etc...) > > This is duplicating the superb efforts of the kernel team and of > linux-info eclass. As such I would like to deprecate $KV in favor of > using linux-info eclass. I don't see the need for portage to export $KV > into the environment for all packages. > > There are a few packages left that use this. There will be a tracker > bug shortly. Mostly this mail is just a heads up ;) I've been after this for quite a long time (I opened a bug but cant seem to find it) as not only is it horrifically broken, it also should never have been the job of portage internals anyways. $KV is currently being exported by linux-info purely for legacy support and as such I would like to suggest that if these ebuilds inherit linux-info as well as use $KV, then it should not require any maintainer changes. Anything I can do to encourage this move please let me know, and many thanks for raising this again. Best Regards, John -- Role:Gentoo Linux Kernel Lead Gentoo Linux:http://www.gentoo.org Public Key: gpg --recv-keys 9C745515 Key fingerprint: A0AF F3C8 D699 A05A EC5C 24F7 95AA 241D 9C74 5515 pgppBTaSFSiXx.pgp Description: PGP signature
Re: [gentoo-dev] Pending Removal of $KV
On Tuesday 20 June 2006 20:18, Robin H. Johnson wrote: > By handling it better, I mean that the code should at runtime try both > interfaces, rather than pick one to compile into the binary. yeah, this differentiates good packages and mediocre packages ;) -mike pgpp6T4cBLu01.pgp Description: PGP signature
Re: [gentoo-dev] Pending Removal of $KV
On Tue, Jun 20, 2006 at 08:49:41PM +0900, Georgi Georgiev wrote: > > Could upstream have handled it better? Yes, most definitely. Did they? > > No, not yet. We're stuck picking up the pieces. > What does upstream have to do with the decision to "chmod u+s,go-r > /usr/bin/gpg" or not? If using a kernel older than 2.6.9, and capabilities support is in the kernel, using capabilities is only way to avoid needing to grant full setuid to the binary. For kernels newer than 2.6.9, there is another API as well. By handling it better, I mean that the code should at runtime try both interfaces, rather than pick one to compile into the binary. -- Robin Hugh Johnson E-Mail : [EMAIL PROTECTED] GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 pgpjNJVZuaUar.pgp Description: PGP signature
Re: [gentoo-dev] Pending Removal of $KV
On Tue, 2006-06-20 at 14:32 +0200, Kevin F. Quinn wrote: > In summary, I agree that $KV should disappear from portage, and that > anything that depends on kernel configuration should use > linux-info.eclass. Also I'd like to see the dependency on > virtual/linux-sources removed from linux-info.eclass. I couldn't agree more. If you're not building a kernel module, there shouldn't ever be a reason why the package should die in pkg_setup. We hit this *every* release with at least one package that completely breaks GRP building, since the GRP target doesn't have a configured kernel. We always have to use hacks and workarounds to resolve the issue. With a new release coming soon, now would be an excellent time to start fixing all of these that aren't fixed. Release Engineering will send jforman over to love you long time if you don't. *grin* -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Pending Removal of $KV
On Mon, 19 Jun 2006 13:38:49 + Alec Warner <[EMAIL PROTECTED]> wrote: > Georgi Georgiev wrote: > > maillog: 19/06/2006-11:13:33(+): Alec Warner types > > > >>Portage currently exports $KV as the current kernel version. We > >>detect this by attempting to mess around with the things > >>in /usr/src/linux (.config, make files, etc...) Which is broken, since there's no guarantee that's where the built kernel is. > >>This is duplicating the superb efforts of the kernel team and of > >>linux-info eclass. As such I would like to deprecate $KV in favor > >>of using linux-info eclass. I don't see the need for portage to > >>export $KV into the environment for all packages. Yes please. linux-info.eclass is great; does (almost) exactly what should be done, i.e. depend on user-supplied kernel source & object locations. > >>There are a few packages left that use this. There will be a > >>tracker bug shortly. Mostly this mail is just a heads up ;) > > > > > > But any kind of checks against something in $KERNEL_DIR are just > > wrong, wrong, wrong. The only exception being when the ebuild is > > building something *against* those sources (kernel modules, and > > that's it). > > > > It's annoying to have virtual/linux-sources pulled as a dep of > > gnupg, iptables or any other package that can do fine without them. I do agree virtual/linux-sources shouldn't be a dependency. The ebuilds should depend on the existence of the kernel sources or objects against which the package will be built, which can only be detected in pkg_setup. To this end I think DEPEND should not be set in linux-info.eclass. > In many cases those packages are looking for a specific kernel > feature to make sure support is enabled for it. > > You could argue that in the case where you aren't compiling against > the kernel that support being enabled isn't critical, but that is a > discussion you need to have with the package maintainers. I think it's wrong for ebuilds to refuse to build if support is missing from the build system kernel. ebuilds should not be using the configuration of the build system to decide whether to build pieces for the target system (such decisions should be made via USE), and certainly shouldn't die if run-time support isn't built on the build system (unless the support is actually needed for the build process itself, such that the build would fail). With linux-info.eclass you can specify the location of the kernel tree to build against (KBUILD_OUTPUT) and thus build for different kernel configurations as appropriate (the default being the build system kernel, which makes things simple for the common case where the target is the build system). In summary, I agree that $KV should disappear from portage, and that anything that depends on kernel configuration should use linux-info.eclass. Also I'd like to see the dependency on virtual/linux-sources removed from linux-info.eclass. -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] Pending Removal of $KV
maillog: 19/06/2006-17:15:37(-0700): Robin H. Johnson types > On Mon, Jun 19, 2006 at 05:00:41PM -0700, infowolfe wrote: > > >Kernel headers being the virtual/linux-headers dependency that Georgi > > >mentioned. `uname -r` works, but is annoying because you can't build > > >for a kernel other than the one you're running. > > Which only applies to kernel modules, not things like gnupg that don't > > REALLY need kernel sources in order to function. > Gnupg builds it's secure memory functionality differently based on what > is available from the kernel. All of the possible APIs are available in > the headers, but depending on what the kernel is configured as, affects > which of the APIs provide secure memory blocks. > > With GnuPG, it happens that on older LiveCDs, the kernel that is running > from the LiveCD doesn't offer what it wants, but the one that you would > be rebooting to does. > > Could upstream have handled it better? Yes, most definitely. Did they? > No, not yet. We're stuck picking up the pieces. What does upstream have to do with the decision to "chmod u+s,go-r /usr/bin/gpg" or not? -- (* Georgi Georgiev (* YAAH! DEATH TO OATMEAL! -- Calvin (* *)[EMAIL PROTECTED]*)*) (* http://www.gg3.net/ (*(* pgpGx9Z2FvrDL.pgp Description: PGP signature
Re: [gentoo-dev] Pending Removal of $KV
maillog: 19/06/2006-16:34:55(-0700): Ryan Tandy types > Arek (James Potts) wrote: > >If they don't actually build against the kernel, > >couldn't/shouldn't they look at either kernel-headers or the output of > >`uname -r`? > > Kernel headers being the virtual/linux-headers dependency that Georgi > mentioned. `uname -r` works, but is annoying because you can't build > for a kernel other than the one you're running. Just to make sure we're talking about the same thing, I did not mention any headers (refer to my original post below). maillog: 20/06/2006-00:34:42(+0900): Георги Георгиев types > maillog: 19/06/2006-11:13:33(+): Alec Warner types > > Portage currently exports $KV as the current kernel version. We detect > > this by attempting to mess around with the things in /usr/src/linux > > (.config, make files, etc...) > > > > This is duplicating the superb efforts of the kernel team and of > > linux-info eclass. As such I would like to deprecate $KV in favor of > > using linux-info eclass. I don't see the need for portage to export $KV > > into the environment for all packages. > > > > There are a few packages left that use this. There will be a tracker > > bug shortly. Mostly this mail is just a heads up ;) > > But any kind of checks against something in $KERNEL_DIR are just wrong, > wrong, wrong. The only exception being when the ebuild is building > something *against* those sources (kernel modules, and that's it). > > It's annoying to have virtual/linux-sources pulled as a dep of gnupg, > iptables or any other package that can do fine without them. -- (Georgi Georgiev ( Like all young men, you greatly exaggerate ( )[EMAIL PROTECTED] ) the difference between one young woman and ) ( http://www.gg3.net/ ( another. -- George Bernard Shaw, "Major( ) --- ) Barbara") -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Pending Removal of $KV
On Mon, Jun 19, 2006 at 05:00:41PM -0700, infowolfe wrote: > >Kernel headers being the virtual/linux-headers dependency that Georgi > >mentioned. `uname -r` works, but is annoying because you can't build > >for a kernel other than the one you're running. > Which only applies to kernel modules, not things like gnupg that don't > REALLY need kernel sources in order to function. Gnupg builds it's secure memory functionality differently based on what is available from the kernel. All of the possible APIs are available in the headers, but depending on what the kernel is configured as, affects which of the APIs provide secure memory blocks. With GnuPG, it happens that on older LiveCDs, the kernel that is running from the LiveCD doesn't offer what it wants, but the one that you would be rebooting to does. Could upstream have handled it better? Yes, most definitely. Did they? No, not yet. We're stuck picking up the pieces. -- Robin Hugh Johnson E-Mail : [EMAIL PROTECTED] GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 pgpEyOqdURUEi.pgp Description: PGP signature
Re: [gentoo-dev] Pending Removal of $KV
On 6/19/06, Ryan Tandy <[EMAIL PROTECTED]> wrote: Arek (James Potts) wrote: > If they don't actually build against the kernel, > couldn't/shouldn't they look at either kernel-headers or the output of > `uname -r`? Kernel headers being the virtual/linux-headers dependency that Georgi mentioned. `uname -r` works, but is annoying because you can't build for a kernel other than the one you're running. Which only applies to kernel modules, not things like gnupg that don't REALLY need kernel sources in order to function. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Pending Removal of $KV
Arek (James Potts) wrote: If they don't actually build against the kernel, couldn't/shouldn't they look at either kernel-headers or the output of `uname -r`? Kernel headers being the virtual/linux-headers dependency that Georgi mentioned. `uname -r` works, but is annoying because you can't build for a kernel other than the one you're running. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Pending Removal of $KV
Alec Warner wrote: Georgi Georgiev wrote: maillog: 19/06/2006-11:13:33(+): Alec Warner types Portage currently exports $KV as the current kernel version. We detect this by attempting to mess around with the things in /usr/src/linux (.config, make files, etc...) This is duplicating the superb efforts of the kernel team and of linux-info eclass. As such I would like to deprecate $KV in favor of using linux-info eclass. I don't see the need for portage to export $KV into the environment for all packages. There are a few packages left that use this. There will be a tracker bug shortly. Mostly this mail is just a heads up ;) But any kind of checks against something in $KERNEL_DIR are just wrong, wrong, wrong. The only exception being when the ebuild is building something *against* those sources (kernel modules, and that's it). It's annoying to have virtual/linux-sources pulled as a dep of gnupg, iptables or any other package that can do fine without them. In many cases those packages are looking for a specific kernel feature to make sure support is enabled for it. You could argue that in the case where you aren't compiling against the kernel that support being enabled isn't critical, but that is a discussion you need to have with the package maintainers. HmmmI don't know about this, since I'm jusr a user without much programming experience, and haven't developed anything that makes use of kernel features, but If they don't actually build against the kernel, couldn't/shouldn't they look at either kernel-headers or the output of `uname -r` (possibly with a way to force the feature on if the user knows it's available but the build system isn't detecting it)? --Arek -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Pending Removal of $KV
Georgi Georgiev wrote: maillog: 19/06/2006-11:13:33(+): Alec Warner types Portage currently exports $KV as the current kernel version. We detect this by attempting to mess around with the things in /usr/src/linux (.config, make files, etc...) This is duplicating the superb efforts of the kernel team and of linux-info eclass. As such I would like to deprecate $KV in favor of using linux-info eclass. I don't see the need for portage to export $KV into the environment for all packages. There are a few packages left that use this. There will be a tracker bug shortly. Mostly this mail is just a heads up ;) But any kind of checks against something in $KERNEL_DIR are just wrong, wrong, wrong. The only exception being when the ebuild is building something *against* those sources (kernel modules, and that's it). It's annoying to have virtual/linux-sources pulled as a dep of gnupg, iptables or any other package that can do fine without them. In many cases those packages are looking for a specific kernel feature to make sure support is enabled for it. You could argue that in the case where you aren't compiling against the kernel that support being enabled isn't critical, but that is a discussion you need to have with the package maintainers. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Pending Removal of $KV
maillog: 19/06/2006-11:13:33(+): Alec Warner types > Portage currently exports $KV as the current kernel version. We detect > this by attempting to mess around with the things in /usr/src/linux > (.config, make files, etc...) > > This is duplicating the superb efforts of the kernel team and of > linux-info eclass. As such I would like to deprecate $KV in favor of > using linux-info eclass. I don't see the need for portage to export $KV > into the environment for all packages. > > There are a few packages left that use this. There will be a tracker > bug shortly. Mostly this mail is just a heads up ;) But any kind of checks against something in $KERNEL_DIR are just wrong, wrong, wrong. The only exception being when the ebuild is building something *against* those sources (kernel modules, and that's it). It's annoying to have virtual/linux-sources pulled as a dep of gnupg, iptables or any other package that can do fine without them. -- / Georgi Georgiev/ Don't quit now, we might just as well lock / \ [EMAIL PROTECTED]\ the door and throw away the key. \ / http://www.gg3.net/ / / -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Pending Removal of $KV
Portage currently exports $KV as the current kernel version. We detect this by attempting to mess around with the things in /usr/src/linux (.config, make files, etc...) This is duplicating the superb efforts of the kernel team and of linux-info eclass. As such I would like to deprecate $KV in favor of using linux-info eclass. I don't see the need for portage to export $KV into the environment for all packages. There are a few packages left that use this. There will be a tracker bug shortly. Mostly this mail is just a heads up ;) -- gentoo-dev@gentoo.org mailing list