Re: [gentoo-dev] Pending Removal of $KV

2006-07-11 Thread Chris Gianelloni
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

2006-07-10 Thread Georgi Georgiev
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

2006-07-09 Thread John Mylchreest
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

2006-06-20 Thread Georgi Georgiev
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

2006-06-20 Thread Robin H. Johnson
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

2006-06-20 Thread Mike Frysinger
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


[gentoo-dev] Pending Removal of $KV

2006-06-19 Thread Alec Warner
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



Re: [gentoo-dev] Pending Removal of $KV

2006-06-19 Thread Georgi Georgiev
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



Re: [gentoo-dev] Pending Removal of $KV

2006-06-19 Thread Alec Warner

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

2006-06-19 Thread Arek (James Potts)

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

2006-06-19 Thread Ryan Tandy

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

2006-06-19 Thread Robin H. Johnson
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