[gentoo-dev] Re: Masking
Il giorno gio, 02/12/2010 alle 19.36 +0100, Ulrich Mueller ha scritto: > Fixed in -r11. Can you add a placeholder stablereq (not CCing arches) and make it block automake-pruning, please? -- Diego Elio Pettenò — “Flameeyes” http://blog.flameeyes.eu/ If you found a .asc file in this mail and know not what it is, it's a GnuPG digital signature: http://www.gnupg.org/
[gentoo-dev] Re: Masking
> On Thu, 02 Dec 2010, Diego Elio Pettenò wrote: > x11-libs/openmotif-2.2.3-r10 =sys-devel/automake-1.6* Fixed in -r11. > x11-libs/openmotif-compat-2.2.3 =sys-devel/automake-1.6* > x11-libs/openmotif-compat-2.2.3-r1=sys-devel/automake-1.6* openmotif-compat has been last-rited already and will be removed in about two weeks. Ulrich
[gentoo-dev] Re: Masking
Updated list with Zac's script after my changes from today app-misc/gpsdrive-2.09-r1 =sys-devel/automake-1.7* dev-db/mysql-super-smack-1.2=sys-devel/automake-1.4* dev-db/mysql-super-smack-1.3=sys-devel/automake-1.4* dev-db/mysql-super-smack-1.3-r1 =sys-devel/automake-1.4* dev-db/mysql-super-smack-1.3-r2 =sys-devel/automake-1.4* dev-libs/cyrus-sasl-2.1.22-r2 =sys-devel/automake-1.7* dev-libs/cyrus-sasl-2.1.23 =sys-devel/automake-1.7* dev-libs/libsigc++-1.2.7=sys-devel/automake-1.7* media-libs/aubio-0.3.2-r1 =sys-devel/automake-1.8* media-sound/oggtst-0.0 =sys-devel/automake-1.4* media-sound/orpheus-1.6-r1 =sys-devel/automake-1.8* media-sound/takcd-0.10 =sys-devel/automake-1.4* media-video/transcode-1.0.7 =sys-devel/automake-1.8* net-analyzer/barnyard-0.2.0-r2 =sys-devel/automake-1.4* net-analyzer/barnyard-0.2.0-r3 =sys-devel/automake-1.4* net-analyzer/ettercap-0.7.3-r2 =sys-devel/automake-1.8* net-analyzer/ettercap-0.7.3-r3 =sys-devel/automake-1.8* net-analyzer/flow-tools-0.68-r5 =sys-devel/automake-1.6* net-analyzer/flow-tools-0.68-r7 =sys-devel/automake-1.6* net-analyzer/flow-tools-0.68-r8 =sys-devel/automake-1.6* net-irc/bobotpp-2.2.2 =sys-devel/automake-1.7* net-misc/portfwd-0.28 =sys-devel/automake-1.4* net-nds/adtool-1.3.2=sys-devel/automake-1.7* net-p2p/dchub-0.5.2 =sys-devel/automake-1.4* sci-chemistry/mopac7-1.10-r1=sys-devel/automake-1.8* sys-fs/gnomevfs-mount-0.2.0 =sys-devel/automake-1.7* www-client/downman-0.0.5-r1 =sys-devel/automake-1.7* x11-libs/openmotif-2.2.3-r10=sys-devel/automake-1.6* x11-libs/openmotif-compat-2.2.3 =sys-devel/automake-1.6* x11-libs/openmotif-compat-2.2.3-r1 =sys-devel/automake-1.6* -- Diego Elio Pettenò — “Flameeyes” http://blog.flameeyes.eu/ If you found a .asc file in this mail and know not what it is, it's a GnuPG digital signature: http://www.gnupg.org/
[gentoo-dev] Re: Masking
> app-office/mdbtools-0.6_pre1-r1 =sys-devel/automake-1.7* > app-office/mdbtools-0.6_pre2-r2 =sys-devel/automake-1.7* pre2 fixed as part of libtool-2.4 fixes; pre1 removed > media-libs/gle-3.1.0-r1 =sys-devel/automake-1.4* > www-apache/mod_nss-1.0.8-r1 =sys-devel/automake-1.6* > x11-libs/libdockapp-0.6.1 =sys-devel/automake-1.5* Fixed as part of libtool-2.4 fixes > net-analyzer/ettercap-0.7.3-r2 =sys-devel/automake-1.8* > net-analyzer/ettercap-0.7.3-r3 =sys-devel/automake-1.8* -r4 was fixed as part of libtool-2.4 fixes, should be marked stable by now I guess. > x11-plugins/wmnetload-1.3-r3~sys-devel/automake-1.4_p6 > x11-plugins/wmwifi-0.6 =sys-devel/automake-1.4* Fixed separately. I'll be checking other ebuilds on a case-by-case basis for now, so to at least tackle those that won't require any work at all. -- Diego Elio Pettenò — “Flameeyes” http://blog.flameeyes.eu/ If you found a .asc file in this mail and know not what it is, it's a GnuPG digital signature: http://www.gnupg.org/
[gentoo-dev] Re: Re: Re: Masking
Il giorno gio, 02/12/2010 alle 17.41 +0200, Petteri Räty ha scritto: > > In my mind I associate masking with eventual removal. > We have precedents of masking things not to be removed; even though that usually happens with proprietary things that can't be fixed. There is no reason for us to forcefully remove the older versions for now, we have had stuff masked for years, pending fix, it should be okay to simply say "This won't work for general case". -- Diego Elio Pettenò — “Flameeyes” http://blog.flameeyes.eu/ If you found a .asc file in this mail and know not what it is, it's a GnuPG digital signature: http://www.gnupg.org/
Re: [gentoo-dev] Re: Re: Masking
On 2.12.2010 17.31, Diego Elio Pettenò wrote: > Il giorno gio, 02/12/2010 alle 17.24 +0200, Petteri Räty ha scritto: >> >> Ok thanks for clarifying the last point. Doesn't this go against your >> original wish to mask it though? > > If you read my first mail, I said I want them masked, and not removed > because they are still useful for upstream work. > In my mind I associate masking with eventual removal. > Being useful for upstream work, I don't want them being unavailable or > unusable, which would happen if you were to block them on newer libtool > just as much as it would happen by removing them. > > The mask might be something along the lines of > > # Obsolete automake packages, only useful for upstream work. > # Do not depend on them, and don't install them unless you really > # need to use them. > > (And having them masked, repoman will complain if somebody was to use > WANT_AUTOMAKE=1.4). > Sounds like an ok compromise. Regards, Petteri
[gentoo-dev] Re: Re: Masking
Il giorno gio, 02/12/2010 alle 17.24 +0200, Petteri Räty ha scritto: > > Ok thanks for clarifying the last point. Doesn't this go against your > original wish to mask it though? If you read my first mail, I said I want them masked, and not removed because they are still useful for upstream work. Being useful for upstream work, I don't want them being unavailable or unusable, which would happen if you were to block them on newer libtool just as much as it would happen by removing them. The mask might be something along the lines of # Obsolete automake packages, only useful for upstream work. # Do not depend on them, and don't install them unless you really # need to use them. (And having them masked, repoman will complain if somebody was to use WANT_AUTOMAKE=1.4). -- Diego Elio Pettenò — “Flameeyes” http://blog.flameeyes.eu/ If you found a .asc file in this mail and know not what it is, it's a GnuPG digital signature: http://www.gnupg.org/
Re: [gentoo-dev] Re: Masking
On 2.12.2010 15.38, Diego Elio Pettenò wrote: > Il giorno gio, 02/12/2010 alle 10.19 +0200, Petteri Räty ha scritto: >> >> Maybe we should start with !=2.4 ebuilds? >> This would force action but people could still keep installing stuff >> needing older automake version by masking latest libtool. > > As Mike said it makes no sense because automake is slotted, and in > particular it makes even less sense because you can still use automake > 1.6 just fine, as long as you don't use libtool _with_ it. > Ok thanks for clarifying the last point. Doesn't this go against your original wish to mask it though? Regards, Petteri
[gentoo-dev] Re: Masking
Il giorno gio, 02/12/2010 alle 10.19 +0200, Petteri Räty ha scritto: > > Maybe we should start with !=2.4 ebuilds? > This would force action but people could still keep installing stuff > needing older automake version by masking latest libtool. As Mike said it makes no sense because automake is slotted, and in particular it makes even less sense because you can still use automake 1.6 just fine, as long as you don't use libtool _with_ it. -- Diego Elio Pettenò — “Flameeyes” http://blog.flameeyes.eu/ If you found a .asc file in this mail and know not what it is, it's a GnuPG digital signature: http://www.gnupg.org/
Re: [gentoo-dev] MULTI_ABI support addition to main tree portage
El mié, 01-12-2010 a las 19:57 +0100, Thomas Sachau escribió: > Hi, > > i have already written about this some months ago and updated the code in > relation to the comments > especially from vapier. > > Basicly, it does now first set abi-specific vars (like CC, CFLAGS and others > (setup_abi_env function > in bin/auto-multilib.sh contains the full list), then does build the package > as usual. If additional > ABIs are requested, it checks after src_install, if there are possible > ABI-specific files (libs, > headers or, if requested for every ABI, also binaries). If those are found, > the image dir is moved > away and a new run is started, where again at start abic-specific vars are > set and then the complete > src* phases are run. Once all requested ABIs are done, the image dirs are > merged into the final > image dir. The following pkg_* phases are each running for every ABI. > Currently, only different libs and headers are installed by default, binaries > will be the ones from > the default ABI, unless you tell portage to install binaries for all > requested ABIs, in which case a > wrapper will select the ABI-specific binary depending on the environment. > The current implementation uses a USE-dep like way internally to satisfy the > needed dependencies, so > that e.g. 32bit libs on a 64bit platform get their required dependencies > built with 32bit libs > installed. For the rare case, where the crosscompile does fail and there is > only a need for the > binary and no linking against the libs, i have also a var, which disables > this auto-dependency > calculation for specified packages. > > For the user interface, portage shows a USE_EXPANDed var, which contains the > avaidable ABIs, as an > example for "emerge -pv media-libs/jpeg": > > [ebuild R ] media-libs/jpeg-8b USE="-static-libs" MULTILIB_ABI="amd64 > x86" > > Those ABIs can be handled like USE flags, in this case, they are > "multilib_abi_amd64" and > "multilib_abi_x86", so you can use those USE flags to enable/disable specific > possible ABIs either > globally or per package. > > The basic implementation can be used without changing main tree ebuilds or > eclasses, but e.g. for > the replacement of emul-* libs, this will require EAPI-support for > ABI-specific USE-deps for > binary-only packages or packages like wine. > > I would first like to see, if there are any bigger concerns especially with > the implementation and > how it is supposed to work. > > If there are no such concerns or if they have been resolved, i would like to > request some help for > the documentation and PMS-patch related work. > > For install instructions, please have a look at [1], the code can be found in > the multilib branch of > portage git repo at [2]. > > While i did not yet get to the implementation of it, i would also like to > propose something similiar > for languages (like python, ruby or others), so that the basic parts are > inside the PM and we can > drop the different ways of implementation and allow users a much more > fine-grained control on a per > package base (in relation to the current way python eclass based very complex > implementation works). > > [1]: http://github.com/sjnewbury/multilib-overlay/tree/portage-multilib/doc > [2]: > http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=shortlog;h=refs/heads/multilib > Nice to see progress on this, it's a headache to have to make emul packages grow forever when any application (usually wine) requires it :-S, and this would allow much more flexibility Thanks a lot :-D signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Masking
On Thursday, December 02, 2010 03:19:48 Petteri Räty wrote: > On 2.12.2010 3.03, Diego Elio Pettenò wrote: > > Not sure if you know but we're currently experiencing a spur of build > > failures related to eautoreconf (in particular, eaclocal) and > > libtool-2.4 The new libtool release only works with automake 1.9 and > > later. [1] > > Maybe we should start with !=2.4 ebuilds? > This would force action but people could still keep installing stuff > needing older automake version by masking latest libtool. that dep makes no sense since automake is SLOTed -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Masking
On 2.12.2010 3.03, Diego Elio Pettenò wrote: > Hi all, > > Not sure if you know but we're currently experiencing a spur of build > failures related to eautoreconf (in particular, eaclocal) and > libtool-2.4 The new libtool release only works with automake 1.9 and > later. [1] > Maybe we should start with !=2.4 ebuilds? This would force action but people could still keep installing stuff needing older automake version by masking latest libtool. Regards, Petteri
