Re: [gentoo-dev] Building custom package for multi-arch/system

2010-01-30 Thread Bertrand Jacquin
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

2010-01-30 Thread Bertrand Jacquin
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

2010-01-30 Thread Zac Medico
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

2010-01-30 Thread Hanno Böck
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

2010-01-30 Thread Max Arnold
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

2010-01-30 Thread Jacob Godserv
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

2010-01-30 Thread Duncan
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

2010-01-30 Thread Zac Medico
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