Re: [gentoo-user] GnuPG depends on gentoo-sources?
On Fri February 10 2006 02:59, Boyd Stephen Smith Jr. wrote: I just checked the .ebuild in my portage tree does not list gentoo-sources as direct dependency of gunpg-1.4.2.r3. Please do a emerge -pvt =app-crypt/gnupg-1.4.2-r3 and give us the output (you might have to unmask gentoo-sources for a bit to give us good output). # emerge -pvt =app-crypt/gnupg-1.4.2-r3 These are the packages that I would merge, in reverse order: Calculating dependencies ...done! [ebuild R ] app-crypt/gnupg-1.4.2-r3 -X +bzip2 -caps +curl -ecc -idea +ldap +nls +readline (-selinux) -smartcard -static -usb +zlib 0 kB [ebuild N] sys-kernel/gentoo-sources-2.6.15-r1 -build -doc -symlink (-ultra1) 0 kB Total size of downloads: 0 kB You are probably trying to use your own, possibly custom-patched, kernel instead of any of the *-sources packages. I'm using gentoo-sources, but I'm compiling kernels on a single machine and installing them manually on their target machines, thus I don't have gentoo-sources installed on the machine in question. There is a note in the gnupg ebuild that points to a bug talking about the need for (or not) kernel sources. I didn't quite follow the arguments and solution, but it had something to do with installing gpg suid root. At any rate, it doesn't make sense (to me) for gnupg to require kernel sources to build or install. -- Ron -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] GnuPG depends on gentoo-sources?
On Sat, 2006-02-11 at 03:52 -0500, Ron Bickers wrote: On Fri February 10 2006 02:59, Boyd Stephen Smith Jr. wrote: I just checked the .ebuild in my portage tree does not list gentoo-sources as direct dependency of gunpg-1.4.2.r3. Please do a emerge -pvt =app-crypt/gnupg-1.4.2-r3 and give us the output (you might have to unmask gentoo-sources for a bit to give us good output). # emerge -pvt =app-crypt/gnupg-1.4.2-r3 These are the packages that I would merge, in reverse order: Calculating dependencies ...done! [ebuild R ] app-crypt/gnupg-1.4.2-r3 -X +bzip2 -caps +curl -ecc -idea +ldap +nls +readline (-selinux) -smartcard -static -usb +zlib 0 kB [ebuild N] sys-kernel/gentoo-sources-2.6.15-r1 -build -doc -symlink (-ultra1) 0 kB Total size of downloads: 0 kB You are probably trying to use your own, possibly custom-patched, kernel instead of any of the *-sources packages. I'm using gentoo-sources, but I'm compiling kernels on a single machine and installing them manually on their target machines, thus I don't have gentoo-sources installed on the machine in question. There is a note in the gnupg ebuild that points to a bug talking about the need for (or not) kernel sources. I didn't quite follow the arguments and solution, but it had something to do with installing gpg suid root. At any rate, it doesn't make sense (to me) for gnupg to require kernel sources to build or install. -- Ron Hi, Here's the output of: dep -l gnupg (listing GnuPG's dependencies): $ sudo dep -l gnupg app-crypt/gnupg-1.4.2-r3: !static? bzip2? app-arch/bzip2 app-arch/bzip2-1.0.3-r6 bzip2? app-arch/bzip2 app-arch/bzip2-1.0.3-r6 dev-lang/perldev-lang/perl-5.8.8 !static? usb? dev-libs/libusb dev-libs/libusb-0.1.11 usb?dev-libs/libusb dev-libs/libusb-0.1.11 !static? curl? net-misc/curlnet-misc/curl-7.15.1 curl? net-misc/curlnet-misc/curl-7.15.1 !static? nls? sys-devel/gettextsys-devel/gettext-0.14.5 nls?sys-devel/gettextsys-devel/gettext-0.14.5 !bootstrap? sys-devel/patch sys-devel/patch-2.5.9-r1 !static? readline? sys-libs/readline sys-libs/readline-5.1_p2 readline? sys-libs/readlinesys-libs/readline-5.1_p2 !static? zlib? sys-libs/zlibsys-libs/zlib-1.2.3 zlib? sys-libs/zlibsys-libs/zlib-1.2.3 virtual/libc sys-libs/glibc-2.3.6-r2 !static?virtual/libc sys-libs/glibc-2.3.6-r2 virtual/linux-sources sys-kernel/gentoo-sources-2.6.15-r4 virtual/mta mail-mta/netqmail-1.05 !static?virtual/mta mail-mta/netqmail-1.05 ...END... So you can see 'gnupg' depends on 'virtual/linux-sources' not specifically 'gentoo-sources'. Any *-sources package will suffice, as it will provide virtual/linux-sources (PROVIDE in ebuilds,sorry being moved to /usr/portage/eclass/kernel-2.eclass). IMO you have to 'lie' to portage that you have some sources (gentoo for example) by running: #echo sys-kernel/gentoo-sources /etc/portage/profile/packages.provided (create if it doesn't exist). Check again the syntax. HTH.Rumen smime.p7s Description: S/MIME cryptographic signature
Re: [gentoo-user] GnuPG depends on gentoo-sources?
On Saturday 11 February 2006 02:52, Ron Bickers [EMAIL PROTECTED] wrote about 'Re: [gentoo-user] GnuPG depends on gentoo-sources?': # emerge -pvt =app-crypt/gnupg-1.4.2-r3 These are the packages that I would merge, in reverse order: Calculating dependencies ...done! [ebuild R ] app-crypt/gnupg-1.4.2-r3 -X +bzip2 -caps +curl -ecc -idea +ldap +nls +readline (-selinux) -smartcard -static -usb +zlib 0 kB [ebuild N] sys-kernel/gentoo-sources-2.6.15-r1 -build -doc -symlink (-ultra1) 0 kB Huh. Weird, it's not listed in the ebuild. Oh, I found it, it was added in one of the inherited eclasses. :/ You can use /etc/portage/package.provided (IIRC) to tell gentoo you will provide this package, rather than have portage install it. You may need to specify the virtual package (virtual/linux-sources) and not the actual package portage is trying to use, but I'm not sure... There is a note in the gnupg ebuild that points to a bug talking about the need for (or not) kernel sources. I didn't quite follow the arguments and solution, but it had something to do with installing gpg suid root. At any rate, it doesn't make sense (to me) for gnupg to require kernel sources to build or install. Well, I /sort of/ understand what is going on in the mind of the ebuild maintainer. The suid bit is only required for kernel versions less than 2.6.9, and the maintainer wants to avoid (for security reasons, I suppose) setting the suid bit for kernels at or above this version. Now, instead of using parsing uname and and getting the version of the *running* kernel, the ebuild checks files in the current /usr/src/linux directory/symlink to determine what version to build against. Either approach seems acceptable, but flawed in some way. Using /usr/src/linux causes problems for you and may yield a gnupg that doesn't work (or at least, doesn't get the protected memory features) in the running kernel; using uname may be a security risk (to what degree is a matter of opinion) if you're in a chroot or otherwise preparing a gentoo system but not running within it. Of course, this means that the package.provided method probably won't work since it won't actually provide a /usr/src/linux directory/symlink with the right files. :/ It only seems to affect the suid bit, and gnupg is one of those applications that you can probably trust with suid permissions anyway -- if it were my ebuild, I probably would have just set the suid bit and not checked the kernel version at all, but maybe that's why I'm not an ebuild maintainer. There is a bugfix for 113474 in my version (--sync'd today) that says it removes the requirement for a compiled kernel, but I don't see it removing the dependency so I'd wager that bug might not actually be fixed. :P It might allow you to use the package.provided technique though. Rechecking the eclass makes me fairly sure you can use package.provided, but that could cause problems down the road -- nevertheless I'd try it if I were you. If package.provides doesn't work, I think your best bet at this point might actually be getting hold of the ebuild maintainer or another gentoo dev and trying to convince them to drop the dependency. That may not be the easiest task though, since the DEPEND is needed, at least the way I read the ebuild. You can also use an overlay with the extra dependency factored out in the meantime. Sorry I couldn't be of more help. -- Boyd Stephen Smith Jr. [EMAIL PROTECTED] ICQ: 514984 YM/AIM: DaTwinkDaddy -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] GnuPG depends on gentoo-sources?
On Sat February 11 2006 05:09, Boyd Stephen Smith Jr. wrote: in one of the inherited eclasses. :/ You can use /etc/portage/package.provided (IIRC) to tell gentoo you will provide this package, rather than have portage install it. You may need to specify the virtual package (virtual/linux-sources) and not the actual package portage is trying to use, but I'm not sure... Ok. I was able to put sys-kernel/gentoo-sources-2.6 in /etc/portage/profile/package.provided and that works. It wouldn't work without some version number attached, though. I don't know if this will work when I have to rebuild gnupg. If not, perhaps I can build it on a machine with sources and install the binary package. Well, I /sort of/ understand what is going on in the mind of the ebuild maintainer. The suid bit is only required for kernel versions less than 2.6.9, and the maintainer wants to avoid (for security reasons, I suppose) setting the suid bit for kernels at or above this version. [snip ebuild troubles] With all the trouble, perhaps a local 'suid' USE flag for gnupg is in order? Either way, GnuPG was already installed. Isn't there a difference in runtime dependencies and buildtime dependencies? Once GnuPG is installed, the kernel sources are certainly *not* needed. Sorry I couldn't be of more help. You helped plenty. Thank you Boyd and Rumen. -- Ron -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] GnuPG depends on gentoo-sources?
On Thursday 09 February 2006 16:40, Ron Bickers [EMAIL PROTECTED] wrote about '[gentoo-user] GnuPG depends on gentoo-sources?': I haven't had gentoo-sources installed on one of my machines for a while, but all of sudden today it wants to install it. I masked it and emerge -u world complains that it's required by app-crypt/gnupg-1.4.2-r3, which is already installed. I just checked the .ebuild in my portage tree does not list gentoo-sources as direct dependency of gunpg-1.4.2.r3. Please do a emerge -pvt =app-crypt/gnupg-1.4.2-r3 and give us the output (you might have to unmask gentoo-sources for a bit to give us good output). The --tree option is very useful for determining why a package is being brought in, esp. in conjunction with --verbose which shows the use flags in effect for the merge. So why does it need gentoo-sources all of a sudden for a package that's already installed? Wild, unfounded guessing follows: - I'm betting that something actually depends on virtual/os-sources or somesuch, you don't have any *other* package installed that provides that virtual, and your profile lists gentoo-sources as the default provider of the virtual. You are probably trying to use your own, possibly custom-patched, kernel instead of any of the *-sources packages. You should either write and ebuild for your sources, indicating that they provide that virtual, and put it in your overlay OR use package.provided to state that you will manually satisfy virtual/os-sources. The first is more labor-intensive right now, but will keep allowing portage to track the virtual, in case your switch to using one of the provided *-sources in the future. -- Boyd Stephen Smith Jr. [EMAIL PROTECTED] ICQ: 514984 YM/AIM: DaTwinkDaddy -- gentoo-user@gentoo.org mailing list
