Re: [gentoo-dev] Building custom package for multi-arch/system
D'ar yaou 28 a viz Genver 2010 e 23 eur 31, « Robin H. Johnson » he deus skrivet : On Thu, Jan 28, 2010 at 04:17:41PM +0100, Beber wrote: So, I did a wrapper to emerge --buildpkg to create tbz2 with SHA1 in names function of USE, like : CHOST=x86_64-pc-linux-gnu ACCEPT_KEYWORDS=amd64 tcpdump USE=+chroot +ipv6 -ssl -test -samba -smi is placed under /data/pkg/amd64/x86_64-pc-linux-gnu/net-analyzer/tcpdump-4.0.1_pre20090709+2bf4bfffad82d4ae519f76770b4f7db7b4416738.tbz2 USE=+chroot +ipv6 +ssl -test +samba -smi is placed under /data/pkg/amd64/x86_64-pc-linux-gnu/net-analyzer/tcpdump-4.0.1_pre20090709+5e099e8337e4cadfceda6ccf4c881fbb495980bd.tbz2 A word of warning on this. Simply capturing the USE flags is not enough, the libraries that a binary is linked against can cause problems as well, as the dependency imposed by linking is much stricter than the RDEPEND in the ebuild. tcpdump for example has: RDEPEND=... ssl? ( =dev-libs/openssl-0.9.6m ) Of course, but real *DEPEND could be added in the xpak part of tbz2 and resolv depedencies by the way. But if you built and linked against openssl-0.9.7*, then upgraded to openssl-0.9.8, you can expect breakage. Similar things happened with binaries linked against libmysqlclient in the past. As to my own take on a solution to the problem for work stuff, we simply maintain one chroot per unique environment (we only have 5 envs), and build in the chroot, then use those binpkgs on the boxes. I did that already, but it's a bit heavy to maintain and do much repetitive (maybe it's not the good word) as many packages would be build with the same USE (in the case of same arch, chost etc). -- Beber pgppYr2q0aw1b.pgp Description: PGP signature
Re: [gentoo-dev] Building custom package for multi-arch/system
D'ar gwener 29 a viz Genver 2010 e 00 eur 23, « Philipp Riegger » he deus skrivet : On Thu, 28 Jan 2010 16:17:41 +0100 Beber be...@meleeweb.net wrote: So, I did a wrapper to emerge --buildpkg to create tbz2 with SHA1 in names function of USE, like : CHOST=x86_64-pc-linux-gnu ACCEPT_KEYWORDS=amd64 tcpdump USE=+chroot +ipv6 -ssl -test -samba -smi is placed under /data/pkg/amd64/x86_64-pc-linux-gnu/net-analyzer/tcpdump-4.0.1_pre20090709+2bf4bfffad82d4ae519f76770b4f7db7b4416738.tbz2 USE=+chroot +ipv6 +ssl -test +samba -smi is placed under /data/pkg/amd64/x86_64-pc-linux-gnu/net-analyzer/tcpdump-4.0.1_pre20090709+5e099e8337e4cadfceda6ccf4c881fbb495980bd.tbz2 So these are the SHA1 sums of the packages? Nice. No, the SHA1 is USE var SHA1. sha1sum $USE -- Beber pgpBKVzwhXru8.pgp Description: PGP signature
Re: [gentoo-dev] Building custom package for multi-arch/system
On 01/28/2010 09:24 PM, Max Arnold wrote: On Thu, Jan 28, 2010 at 04:17:41PM +0100, Beber wrote: So, do you guys plan to implement a such thing ? That's one of the features that is mostly missing imho. The principal miss in on client side as I have tools to manage packages but would like to not have too much specific scripts on client side. I like the way it done in OpenEmbedded. You have the tree of recipes (think of portage tree) and bunch of targets. For each target BitBake can generate binary release and package feed. Client package management is lightweight and does not require BitBake, recipes tree and even python. At least this is my lame interpretation of how it works :) You can do something similar using the emerge --config-root option. You'd just use a different --config-root for each target, and each of those would have a separate $PKGDIR. Maybe this metadistribution approach is cleaner than binary package support in emerge. If user wants to compile packages on the client, he uses portage. If not - he can setup build server for multiple targets and completely drop portage from client machines. The only thing client should know is feed url with full list of binary packages. And I do not think client should deal with USE flags - for large installations unification is the only sane way to scale. The clients need sys-apps/portage installed, but not the whole portage tree (although the profiles directory can be useful for the profile and package moves). The clients should set PORTAGE_BINHOST in make.conf, so that binary packages are automatically downloaded with the emerge -g option. -- Thanks, Zac
[gentoo-dev] openssl 1.0.0 quick test
Hi, I recently installed the masked openssl 1.0.0_beta5 and tried to rebuild everything against the new version of openssl. I know it's probably not very urgend to get on that, but I thought others might be interested in the status. - php fails, fix is trivial. I've sent it upstream and it got already applied to upstream svn: http://bugs.php.net/bug.php?id=50859 - wvstreams fails, fix also trivial and sent upstream, no reply yet: http://code.google.com/p/wvstreams/issues/detail?id=27 - ruby fails (both the 1.8/1.9 versions from the tree and the latest from the ruby-overlay), fix seems to be non-trivial. There is some upstream work on it I haven't tested: http://redmine.ruby-lang.org/issues/show/2022 So all in all it's not that much. I'll leave it up to the maintainers of php and wvstreams if they want to patch their packages or wait till upstream fixes arrive. cu, -- Hanno Böck Blog: http://www.hboeck.de/ GPG: 3DBD3B20 Jabber/Mail:ha...@hboeck.de signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Building custom package for multi-arch/system
On Sat, Jan 30, 2010 at 03:59:27AM -0800, Zac Medico wrote: On 01/28/2010 09:24 PM, Max Arnold wrote: On Thu, Jan 28, 2010 at 04:17:41PM +0100, Beber wrote: So, do you guys plan to implement a such thing ? That's one of the features that is mostly missing imho. The principal miss in on client side as I have tools to manage packages but would like to not have too much specific scripts on client side. I like the way it done in OpenEmbedded. You have the tree of recipes (think of portage tree) and bunch of targets. For each target BitBake can generate binary release and package feed. Client package management is lightweight and does not require BitBake, recipes tree and even python. At least this is my lame interpretation of how it works :) You can do something similar using the emerge --config-root option. You'd just use a different --config-root for each target, and each of those would have a separate $PKGDIR. Can someone share his experience of using Catalyst or Metro as generator of binary package updates for precompiled client machines? How smooth it is in the long run?
Re: [gentoo-dev] Building custom package for multi-arch/system
On Sat, Jan 30, 2010 at 10:13, Max Arnold lwa...@gmail.com wrote: Can someone share his experience of using Catalyst or Metro as generator of binary package updates for precompiled client machines? How smooth it is in the long run? I use metro (wrote a little HOWTO on it: http://neuvoo.org/wiki/index.php?title=Create_Image/Building ) and it asks emerge to --buildpkg at every stage. It keeps binaries separate per stage. The end result, as long as you told it not to clean, is three folders with a binary repo in each. It will re-use these binaries in future stage builds, if you don't clean it out. If you don't want it building stages, it's very easy to configure metro to do exactly what you want. It still has to be figured out to some extent, but the format is much simpler than catalyst and takes less time to customize properly. I'm not sure what long run looks like as I have yet to enter the long run. As far as I can tell, metro will always build and update binary repositories when you ask it to. ;) -- Jacob For then there will be great distress, unequaled from the beginning of the world until now — and never to be equaled again. If those days had not been cut short, no one would survive, but for the sake of the elect those days will be shortened. Are you ready?
[gentoo-dev] Re: Building custom package for multi-arch/system
Zac Medico posted on Sat, 30 Jan 2010 03:59:27 -0800 as excerpted: The clients need sys-apps/portage installed, but not the whole portage tree (although the profiles directory can be useful for the profile and package moves). The clients should set PORTAGE_BINHOST in make.conf, so that binary packages are automatically downloaded with the emerge -g option. Thanks. I knew the PORTAGE_BINHOST and --config-root bits, but hadn't thought about the tree not being needed, save for the profiles. I recently setup a netbook based on a Gentoo image compiled elsewhere, and while it's now functional, I'm still tweaking stuff, including the portage arrangement. That I don't need the entire gentoo tree for emerging binpkgs is thus quite interesting new information at this point. =:^) Does that happen to be documented anywhere? I'd not seen it before. -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
Re: [gentoo-dev] Re: Building custom package for multi-arch/system
On 01/30/2010 10:11 AM, Duncan wrote: Thanks. I knew the PORTAGE_BINHOST and --config-root bits, but hadn't thought about the tree not being needed, save for the profiles. I recently setup a netbook based on a Gentoo image compiled elsewhere, and while it's now functional, I'm still tweaking stuff, including the portage arrangement. That I don't need the entire gentoo tree for emerging binpkgs is thus quite interesting new information at this point. =:^) Does that happen to be documented anywhere? I'd not seen it before. No, not really. The binhost support was updated in portage-2.1.6, with support for the $PKGDIR/Packages file. Since then it's a lot more appealing. -- Thanks, Zac
