[gentoo-dev] Dropping keywords, again
*octave-3.6.2-r1 (11 Jun 2012) 11 Jun 2012; Sébastien Fabbro bicat...@gentoo.org +octave-3.6.2-r1.ebuild: Re-add hdf5, some octave packages might need it. Do in source configuring for preventing more bugs. Drop hppa (needs hdf5) You are supposed to[1] tell the arch team when you drop their keyword. jer [1] http://devmanual.gentoo.org/keywording/index.html
Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information
El mar, 01-01-2013 a las 16:01 -0800, Zac Medico escribió:
On 01/01/2013 05:39 AM, Pacho Ramos wrote:
El mar, 01-01-2013 a las 14:32 +0100, Pacho Ramos escribió:
pkg_postinst() {
@@ -48,6 +56,8 @@
elog
fi
+ echo ${CONFIGURATION_INSTRUCTIONS} | fmt | while read -s ELINE; do
elog ${ELINE}; done
+
# files/systemd/acpid.socket - ListenStream=/run/acpid.socket
mkdir -p ${ROOT}/run
This could probably be moved to eutils.eclass to use it on this kind of
ebuilds
Well, elog part should be behind:
if ! has_version ${CATEGORY}/${PN}; then
echo ${CONFIGURATION_INSTRUCTIONS} | fmt | while read -s ELINE; do elog
${ELINE}; done
fi
Not that `has_version ${CATEGORY}/${PN}` is always true in
pkg_postinst, since the package is already installed. So, you should
choose one of these alternatives for it to work as intended:
1) call has_version in pkg_preinst
2) use [[ ${REPLACING_VERSIONS} ]] instead
Yeah, that is true (and looks like current acpid ebuild is buggy in
this). I wouldn't have any problem on either solution, but using first
one would work in all eapis, is there any reason for printing this kind
of messages in pkg_postinst?
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] Dropping keywords, again
On Wed, 2 Jan 2013 12:36:36 +0100 Jeroen Roovers j...@gentoo.org wrote: You are supposed to[1] tell the arch team when you drop their keyword. *PDL-2.4.11 (16 Jun 2012) 16 Jun 2012; Sébastien Fabbro bicat...@gentoo.org +PDL-2.4.11.ebuild, +files/PDL-2.4.11-fortran.patch, +files/PDL-2.4.11-shared-hdf.patch, metadata.xml: Version bump. Added many use flags, previously assumed automagic'ed. Respect user fortran compiler and flags. Added a port_rm to remove generated files. Added sci as maintainer and a long description. USe the newer PDL homepage There as well, I guess. jer [1] http://devmanual.gentoo.org/keywording/index.html
Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information
On 01/02/2013 03:48 AM, Pacho Ramos wrote:
El mar, 01-01-2013 a las 16:01 -0800, Zac Medico escribió:
On 01/01/2013 05:39 AM, Pacho Ramos wrote:
El mar, 01-01-2013 a las 14:32 +0100, Pacho Ramos escribió:
pkg_postinst() {
@@ -48,6 +56,8 @@
elog
fi
+ echo ${CONFIGURATION_INSTRUCTIONS} | fmt | while read -s ELINE; do
elog ${ELINE}; done
+
# files/systemd/acpid.socket - ListenStream=/run/acpid.socket
mkdir -p ${ROOT}/run
This could probably be moved to eutils.eclass to use it on this kind of
ebuilds
Well, elog part should be behind:
if ! has_version ${CATEGORY}/${PN}; then
echo ${CONFIGURATION_INSTRUCTIONS} | fmt | while read -s ELINE; do elog
${ELINE}; done
fi
Not that `has_version ${CATEGORY}/${PN}` is always true in
pkg_postinst, since the package is already installed. So, you should
choose one of these alternatives for it to work as intended:
1) call has_version in pkg_preinst
2) use [[ ${REPLACING_VERSIONS} ]] instead
Yeah, that is true (and looks like current acpid ebuild is buggy in
this). I wouldn't have any problem on either solution, but using first
one would work in all eapis, is there any reason for printing this kind
of messages in pkg_postinst?
If you need to use pkg_postinst for any reason, you can still call
has_version in pkg_preinst and use a variable to store the result, like
this:
pkg_preinst() {
has_version ${CATEGORY}/${PN}
has_version_result=$?
}
pkg_postinst() {
if [ ${has_version_result} -eq 0 ] ; then
elog ${CONFIGURATION_INSTRUCTIONS}
fi
}
--
Thanks,
Zac
Re: [gentoo-dev] Switching order of packages in virtual/pkgconfig
On 01/01/13 23:01, Jeff Horelick wrote: I would like to propose a switch of the order of DEPENDs in virtual/pkgconfig to make dev-util/pkgconf[pkg-config] the default choice for new installations. dev-util/pkgconf has less external dependencies, is lighter and is faster than dev-util/pkgconfig while being now 100% compatible This switch has already been made by Funtoo, Alpine Linux and FreeBSD with very little in the way of ill effects recently from any of those 3 camps. There are no more pending bugs against pkgconf (and Diego did a tinderbox run with it a while back) in Gentoo. pkgconf also has a upstream that is more than happy to work with us specifically (or anyone for that matter) and I (a Gentoo developer) am one of the upstream developers. If this is approved, I will make the change in ~2 weeks. I'm not planning on making a news item because users should notice little difference. Thanks Jeff i'd say never. there is no benefit in switching. pkg-config is the default implementation from freedesktop.org. pkg-config is now lighter and has less dependencies than before as the switch from bundled glib1 to glib2 allowed dropping of the popt library. and since pkgconf upstream doesn't properly follow pkg-config upstream git and do necessary changes, like for bug 445796 it would mean pkg-config related bugs would have to be reported to double upstream and thus, not be maintainable last I checked prefix didn't have issues with the pkg-config bootstrap either. there is no circular deps either. lose-lose situation for the switch, so over my commit access ;-)
Re: [gentoo-dev] Switching order of packages in virtual/pkgconfig
On 02/01/13 13:11, Samuli Suominen wrote: On 01/01/13 23:01, Jeff Horelick wrote: I would like to propose a switch of the order of DEPENDs in virtual/pkgconfig to make dev-util/pkgconf[pkg-config] the default choice for new installations. dev-util/pkgconf has less external dependencies, is lighter and is faster than dev-util/pkgconfig while being now 100% compatible This switch has already been made by Funtoo, Alpine Linux and FreeBSD with very little in the way of ill effects recently from any of those 3 camps. There are no more pending bugs against pkgconf (and Diego did a tinderbox run with it a while back) in Gentoo. pkgconf also has a upstream that is more than happy to work with us specifically (or anyone for that matter) and I (a Gentoo developer) am one of the upstream developers. If this is approved, I will make the change in ~2 weeks. I'm not planning on making a news item because users should notice little difference. Thanks Jeff i'd say never. there is no benefit in switching. pkg-config is the default implementation from freedesktop.org. And has its share of issues. pkg-config is now lighter and has less dependencies than before as the switch from bundled glib1 to glib2 allowed dropping of the popt library. As if glib-2 is any lighter... and since pkgconf upstream doesn't properly follow pkg-config upstream git and do necessary changes, like for bug 445796 it would mean pkg-config related bugs would have to be reported to double upstream and thus, not be maintainable Non sequitur at best. My interaction with both upstreams had been decent though. last I checked prefix didn't have issues with the pkg-config bootstrap either. there is no circular deps either. check glib deps iirc some non-glibc platforms have few problems with it. lu
Re: [gentoo-dev] Switching order of packages in virtual/pkgconfig
On Wed, Jan 2, 2013 at 10:11 AM, Samuli Suominen ssuomi...@gentoo.org wrote: On 01/01/13 23:01, Jeff Horelick wrote: I would like to propose a switch of the order of DEPENDs in virtual/pkgconfig to make dev-util/pkgconf[pkg-config] the default choice for new installations. dev-util/pkgconf has less external dependencies, is lighter and is faster than dev-util/pkgconfig while being now 100% compatible This switch has already been made by Funtoo, Alpine Linux and FreeBSD with very little in the way of ill effects recently from any of those 3 camps. There are no more pending bugs against pkgconf (and Diego did a tinderbox run with it a while back) in Gentoo. pkgconf also has a upstream that is more than happy to work with us specifically (or anyone for that matter) and I (a Gentoo developer) am one of the upstream developers. If this is approved, I will make the change in ~2 weeks. I'm not planning on making a news item because users should notice little difference. Thanks Jeff i'd say never. there is no benefit in switching. pkg-config is the default implementation from freedesktop.org. pkg-config is now lighter and has less dependencies than before as the switch from bundled glib1 to glib2 allowed dropping of the popt library. and since pkgconf upstream doesn't properly follow pkg-config upstream git and do necessary changes, like for bug 445796 it would mean pkg-config related bugs would have to be reported to double upstream and thus, not be maintainable last I checked prefix didn't have issues with the pkg-config bootstrap either. there is no circular deps either. lose-lose situation for the switch, so over my commit access ;-) I agree with you. The original implementation should be our default. People interested in get rid of the glib dependency should be able to replace pkg-config with pkgconf manually. No need to make an unofficial implementation the default. Regards, -- Rafael Goncalves Martins Gentoo Linux developer http://rafaelmartins.eng.br/
Re: [gentoo-dev] Switching order of packages in virtual/pkgconfig
On Wed, Jan 2, 2013 at 4:11 AM, Samuli Suominen ssuomi...@gentoo.org wrote: i'd say never. there is no benefit in switching. pkg-config is the default implementation from freedesktop.org. pkg-config is now lighter and has less dependencies than before as the switch from bundled glib1 to glib2 allowed dropping of the popt library. As a data point: pkgconfig and glib:2 are built during stage3 and removed during --depclean. Switching to pkgconf avoids glib:2 entirely and saves some stage3 building time.
Re: [gentoo-dev] Switching order of packages in virtual/pkgconfig
Samuli Suominen wrote: i'd say never. there is no benefit in switching. pkg-config is the default implementation from freedesktop.org. That's one awful double standard. :\ dev-libs/libusb is the default implementation from libusb.org, yet you are astonishingly eager to *avoid* that it is the default in virtual/libusb-1, even if ~keywords make it apply only to ~ systems. and since pkgconf upstream doesn't properly follow pkg-config upstream git and do necessary changes, like for bug 445796 it would mean pkg-config related bugs would have to be reported to double upstream and thus, not be maintainable In the case of libusb and libusbx, libusbx have consistently communicated that they are eager to *break* the API, and they have indeed made at least one release with an outright change of existing API, which broke things for library users. They released another version with that change reverted a day or so later, but still. I even asked you if you would consider swapping the default, but no. lose-lose situation for the switch Funny that you should write that. I think it applies also when you prefer libusbx over the default implementation from libusb.org. Kind regards //Peter
[gentoo-dev] Last rites: dev-python/pypy:1.8
# Mike Gilbert flop...@gentoo.org (03 Jan 2013) # No longer maintained upstream. # Please upgrade to PyPy 1.9 or 2.0. # Removal in 30 days. dev-python/pypy:1.8 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Switching order of packages in virtual/pkgconfig
On Wed, Jan 2, 2013 at 10:44 AM, Peter Stuge pe...@stuge.se wrote: Samuli Suominen wrote: i'd say never. there is no benefit in switching. pkg-config is the default implementation from freedesktop.org. That's one awful double standard. :\ Double-standards aside, I don't think the original implementation is what matters, so much as what works best for our users (and ourselves) in practice. Others have pointed out that we don't have enough data to safely switch the default, and I think that alone is sufficient reason to hold off for now, but once that data is collected if it makes sense to switch we should do so. We don't use XFree86 or LILO, and quite a few are eager to drop udev. The important thing is to offer users meaningful choices, and make the default whatever makes the most sense at the time we set it. Rich
Re: [gentoo-dev] Switching order of packages in virtual/pkgconfig
Rich Freeman wrote: i'd say never. there is no benefit in switching. pkg-config is the default implementation from freedesktop.org. That's one awful double standard. :\ Double-standards aside, I don't think the original implementation is what matters, so much as what works best for our users (and ourselves) in practice. Sure thing! I agree with that, that is a pragmatic approach. Others have pointed out that we don't have enough data to safely switch the default A good point. once that data is collected if it makes sense to switch we should do so. I think that is fair, along with.. We don't use XFree86 or LILO, and quite a few are eager to drop udev. The important thing is to offer users meaningful choices, and make the default whatever makes the most sense at the time we set it. ..always being open to re-evaluate and change the default again, if that makes the most sense at a later time. //Peter PS. I for one would actually prefer LILO to be the Gentoo default. :)
Re: [gentoo-dev] Switching order of packages in virtual/pkgconfig
On 1 January 2013 16:46, Diego Elio Pettenò flamee...@flameeyes.eu wrote: On 01/01/2013 22:29, Tony Chainsaw Vroon wrote: That sounds like a clear win. If it has survived the tinderboxing there likely isn't much to hold you back. As non-contentious topics sometimes end up with no replies at all... consider 48 hours of radio silence an implicit yes. It didn't survive. I'm not sure if all the bugs have been fixed now but at some point I had to stop the tinderboxing because it was hitting package failures, and then it was fixed for next version — which was difficult to test. So I would veto this _for the moment_. (I'd be happy to run another test _after_ the glibc-2.17 one.) -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/ I was unaware that the tinderbox run hadn't finished. I definetly think it should be fully run through with pkgconf before we fully consider switching the virtual. All the bugs that have been found were fixed, last i checked, only 2 were not verified fixed, but I could not reproduce and after ~2 months of asking people to verify whether the bugs still existed on pkgconf-0.8.9, no one had replied with the results of a test, so i closed them. If you could run it through the tinderbox again Diego, that would be great and we can finish evaluating based on those results.
Re: [gentoo-dev] Switching order of packages in virtual/pkgconfig
Rich Freeman schrieb: Double-standards aside, I don't think the original implementation is what matters, so much as what works best for our users (and ourselves) in practice. I don't think the original matters either. But I wouldn't mind having libusb over libusbx, jpeg over libjpeg-turbo (did you notice any speed increase on your computer?), openoffice(-bin) over libreoffice. Only if one implementation is vastly better than the alternative, then I would expect the distro to make the sane choice. Else it can be choosen randomly during each install for what I care. Others have pointed out that we don't have enough data to safely switch the default, and I think that alone is sufficient reason to hold off for now, but once that data is collected if it makes sense to switch we should do so. We don't use XFree86 or LILO, Using LILO is still documented as an alternative to GRUB: http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=1chap=10#doc_chap3 Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] emerge --depclean vs missing IUSE in older ebuild.. what exactly is right?
Ok my conclusion is then that gdm-3.4.1.ebuild should be patched for [systemd?-], considering it seems otherwise fully compatible with current stable pambase. Opinions? -- Sent from my Nokia N9On 31.12.12 17:34 Michał Górny wrote: On Mon, 31 Dec 2012 17:22:16 +0200 Leho Kraav l...@kraav.com wrote: Just bumped into something I haven't encountered before. Running amd64. Already had sys-auth/pambase-20101024-r2 (stable) installed. Then installed gnome-base/gdm-3.4.1-r3 binpkg, binhost had newer pambase, which is why this didn't surface before. Everything is fine for runtime, but emerge --depclean pukes with sys-auth/pambase[consolekit] is not installed. Looking at this from all angles, this condition *is* most certainly fulfilled. Trying to re-emerge gdm from source revealed that only =pambase-20120417 seems to fulfill its requirements. Initially I couldn't figure out why. Poking around in gdm-3.4.1-r3.ebuild L56 reveals [1]: sys-auth/pambase[consolekit?,systemd?] This lead me to check the pambase-2010 ebuild and sure enough there is no IUSE=systemd flag. Adding systemd to /var/db/pkg/sys-auth/pambase-20101024-r2/IUSE made emerge --depclean work just fine. Now, my question is: why does portage-2.1.11.31 not calculate a missing IUSE=systemd in ebuild for being the same as just USE=-systemd? It feels like pambase-20101024-r2.ebuild [2] should fulfill gdm-3.4.1 requirements just fine, but it doesn't, at least not for this portage version. Am I missing anything known and obvious? http://dev.gentoo.org/~ulm/pms/5/pms.html#x1-870008.2.6.4 «Unless a 4-style default is specified, it is an error for a use dependency to be applied to an ebuild which does not have the flag in question in IUSE_REFERENCEABLE.» which in understandable language means that without USE defaults, even [-foo] matches only packages which have 'foo' in IUSE. -- Best regards, Michał Górny
Re: [gentoo-dev] Local bindist descriptions
Alexis Ballier wrote: It's probably too idealistic but I tend to consider that global flags should be enabled/disabled globally while local flags on a per-package basis. bindist is really something you want to enable globally. On the other hand, doc is a global flag you don't want to enable globally. -- Cyprien (Fulax)
Re: [gentoo-dev] Local bindist descriptions
On Wednesday 02 January 2013 12:58:01 Cyprien Nicolas wrote: Alexis Ballier wrote: It's probably too idealistic but I tend to consider that global flags should be enabled/disabled globally while local flags on a per-package basis. bindist is really something you want to enable globally. On the other hand, doc is a global flag you don't want to enable globally. or vanilla or debug or examples ... i'm sure there are others too -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Proposal to end-of-life tree-clean old profiles/updates/ files
On Mon, 2012-12-10 at 08:59 +0100, Ulrich Mueller wrote: On Mon, 10 Dec 2012, Sergei Trofimovich wrote: gentoo-x86/profiles/updates $ LANG=C ls -1 --sort=time [long list omitted] old entries are done in different context (comparing to 2012): - some packages change names 2 or 3 times - slots have different meaning moreover: - if you set your PORTDIR to different directory you'll get all that full update. And will break the system. Old profile entries used to break eclass-manpages and latex-base (due to double renaming) It's worse: Bad entries in the old files may go unnoticed for a long time. But if such a file is updated for whatever reason, it will be reprocessed on users' systems, including any bad entries contained in it. Thus the reason for removal is simple: old entries are potentially buggy as nobody verifies them. I wouldn't even know how to verify them. Let's remove that cruft. We can be extra conservative and keep five years of backlog (i.e. everything from before 2008 would be removed now). Ulrich OK, that seems to be some very good reasons to tree-clean them. What's our next step? Tree-cleaners, does this fall into your department? Or should I prepare a list of files and/or updates to clean? -- Brian Dolbec dol...@gentoo.org signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Packages up for grabs
On 22:52 Thu 20 Dec , Pacho Ramos wrote: Due araujo no longer taking care of them: dev-lang/gnu-smalltalk ... I'm taking this one. -- Panagiotis Christopoulos ( pchrist ) ( Gentoo Lisp Project ) pgpJt1_yi2GXq.pgp Description: PGP signature
Re: [gentoo-dev] Packages up for grabs
On Thu, Jan 3, 2013 at 12:57 AM, Panagiotis Christopoulos pchr...@gentoo.org wrote: On 22:52 Thu 20 Dec , Pacho Ramos wrote: Due araujo no longer taking care of them: dev-lang/gnu-smalltalk ... I'm taking this one. -- Panagiotis Christopoulos ( pchrist ) ( Gentoo Lisp Project ) o_O xD -- Alex http://www.linuxized.com
Re: [gentoo-dev] app-text/dbacl is up for grabs
El jue, 27-12-2012 a las 21:40 +0100, Amadeusz Żołnowski escribió: Quoting Pacho Ramos (2012-12-27 12:20:11) Steev contacted me few hours ago to tell me he won't maintain dbacl anymore and, then, it's now up for grabs. Thanks for taking care of it If nobody is interested I can take it. I guess nobody will take it in the near future, feel free to edit its metadata (I fixed some days ago his opened bugs, it's now clean then ;) signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] ship app-arch/pbzip2 instead of app-arch/bzip2
El lun, 29-10-2012 a las 10:39 -0400, Rich Freeman escribió: On Mon, Oct 29, 2012 at 10:13 AM, Rick Zero_Chaos Farina zeroch...@gentoo.org wrote: I'm confident no one would attempt to block my adding eselect-bzip2 to the tree (aside from my poor coding skills), ++ but would anyone be interested in blocking using lbzip2 by default? It seems pretty safe and I've done dozens of full system builds etc. Why not just make it an option to start, advertise it by all means, and then see how it turns out with volunteers before we make it the default. Going from nobody-has-heard-of-it to default overnight seems a bit much. Rich How this ended finally? :/ Thanks for the info! signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: About unresolved bugs assigned to voip for ages
El jue, 11-10-2012 a las 08:13 +0200, Pacho Ramos escribió: El mié, 10-10-2012 a las 20:11 -0400, Jesus Rivero (Neurogeek) escribió: On Wed, Oct 10, 2012 at 5:53 PM, Chí-Thanh Christopher Nguyễn chith...@gentoo.org wrote: Pacho Ramos schrieb: I am noticing for a long time that bugs related with ekiga, opal, yate... are completely unattended by voip team for years. If nobody from that team is willing to maintain them, please move them to maintainer-needed to, at least, reflect reality. Any news here? I can move that packages to maintainer-needed if you send me the list of packages you don't want to maintain. Also, maybe telepathy stuff could be moved to its own herd (that is basically gnome team + tester... or maybe tester could join gnome team ;)) There is now one proxy maintainer for a couple of packages, he is currently waiting for voip overlay access in bug 437538. He will take care of linphone and related packages (see bug 399735 and its dependencies). Regarding the packages that can be moved to maintainer-needed: I think a good heuristic is if the package has several open bugs with no maintainer reaction, and hasn't been touched by anyone from voip herd in over a year. This would include the ekiga, opal and yate packages mentioned above. I'd gladly take maintainership of opal and ekiga, if nobody wants them. Cheers, Would be nice as they need a lot of bumps and pending work Looks like finally you added yourself to metadata but with instructions to bug-wranglers to CC you and assign to herd. I would like to confirm this way of assigning things with both as voip herd people didn't touch ekiga related packages and, also, would be better to clarify things before me going to their bugs and assigning them properly to comply current metadatas (as I have seen some ekiga bugs still only assigned to voip herd without you CCed) Thanks signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.
El mar, 25-09-2012 a las 10:21 -0300, Alexis Ballier escribió: On Sun, 23 Sep 2012 16:49:13 +0200 Thomas Sachau to...@gentoo.org wrote: It is not hard by itself to inherit an eclass. There is just the limitation, that occurs with an eclass, e.g.: -the one from mgorny only does it for autotools based ebuilds only and even there only for libraries, headers and binaries are not done. While one may create the same for cmake based ones, those are still only for a subset of packages, since not all do use autotools/cmake or are satisfied with a libs only solution -the multilib-native eclass does extend it way more, but still has its limitations, e.g. what happens with a new target ABI (like x32 on the amd64 profile) or how are dependencies handled? multilib-portage is the answer to those limitations, since it does work for any target with multilib cross-compile support, can handle things like the dependencies internally and can even work on not prepared/modified ebuilds. So before i invest even more time in getting this official, we should better get to some conclusion, if we either go the route with eclass based multilib cross-compile support with its limitations or if we move this up to the package manager level. Can't we get something in between ? Unless I'm mistaken, portage-multilib has its limitations also: - I have package foo and package bar, both depending on ffmpeg and canditates for a multilib build. However, package foo does not link to ffmpeg but simply spawns the 'ffmpeg' binary to process some files, package bar links to libavcodec. You need ffmpeg[multilib] for a multilib build of bar but not for foo. How do you distinguish between the two ? - When an out-of-tree build is possible, it is more efficient to do it that way while multilib-portage will probably run the full src_* phases twice. mgorny's eclass is a solution to this for autotools-utils based ebuilds. I have added basic support for this in freebsd-lib some time ago also. However, it is clear that USE=multilib is limited too. What we probably need, as I read in the draft you posted some time ago, is a MULTILIB_ABI use-expand. Keep a list of all the MULTILIB_ABIs in an eclass, add them to IUSE of multilib-enabled packages and then you can use the USE-deps. When a new ABI gets added, add it to the list in the eclass and be done. You already have PM support for this :) You can leverage the generic multilib building code you have to an eclass, so that you don't need to spec it; spec-ing it has its problems too: what happens if next year pkg-config is deprecated and now we shall all use foo-config ? your spec adjusts PKG_CONFIG_PATH but not FOO_CONFIG_PATH. You probably need a small EAPI change to be able to implement sanely a generic solution into an eclass though. My question to you would be: what are we missing from current EAPIs to be able to perfectly support multilib builds ? A. What finally occurred with this? What would be the problem of opting by this mixed solution (eclass for some packages and PM features requiring newer eapi for others)? Thanks signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Make connman a global USE flag
El sáb, 21-07-2012 a las 13:51 +0200, Pacho Ramos escribió: Several packages are using it with the same sense (support connman), maybe we should move it from local to global USEs, what do you think? Will proceed then ;) signature.asc Description: This is a digitally signed message part
[gentoo-dev] About *ECLASS_ONCE_* stuff at top of some eclasses but not others
What is the purpose of this stuff:
if [[ ${___ECLASS_ONCE_EUTILS} != recur -_+^+_- spank ]] ; then
___ECLASS_ONCE_EUTILS=recur -_+^+_- spank
and similar in some eclasses (like eutils, multilib) but not others
(like python-single-r1 that I was looking some days ago for learning how
to use it)?
Thanks a lot for the info
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] Re: About unresolved bugs assigned to voip for ages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Pacho Ramos schrieb: Looks like finally you added yourself to metadata but with instructions to bug-wranglers to CC you and assign to herd. I would like to confirm this way of assigning things The difference is almost inconsequential in practice. Bugmail will be sent to both assignee and CC:. Only for maintainers without bugzilla privileges they need to ping their proxy to make certain updates to the bug. x11 team has similar instructions in the metadata for their proxy maintained package. Best regards, Chí-Thanh Christopher Nguyễn -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlDkxhkACgkQ+gvH2voEPRAQZgCbBnoIB6/peK8UWwuz/dxJitLk 4NQAnirKXvPLW+mfnAWMuAiGGZGXNbl6 =Jkiy -END PGP SIGNATURE-
Re: [gentoo-dev] About *ECLASS_ONCE_* stuff at top of some eclasses but not others
On 1/2/2013 6:41 PM, Pacho Ramos wrote:
What is the purpose of this stuff:
if [[ ${___ECLASS_ONCE_EUTILS} != recur -_+^+_- spank ]] ; then
___ECLASS_ONCE_EUTILS=recur -_+^+_- spank
and similar in some eclasses (like eutils, multilib) but not others
(like python-single-r1 that I was looking some days ago for learning how
to use it)?
Thanks a lot for the info
It prevents eclasses from being sourced more than once. It is meant as a
performance enhancement for when eclasses inherit other eclasses. vapier
posted some stats on this list a while back.
We have a similar thing in python-single-r1. We call it
_PYTHON_SINGLE_R1 and assign a value of 1 at the bottom of the eclass.
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] About *ECLASS_ONCE_* stuff at top of some eclasses but not others
On 1/2/2013 6:54 PM, Mike Gilbert wrote:
On 1/2/2013 6:41 PM, Pacho Ramos wrote:
What is the purpose of this stuff:
if [[ ${___ECLASS_ONCE_EUTILS} != recur -_+^+_- spank ]] ; then
___ECLASS_ONCE_EUTILS=recur -_+^+_- spank
and similar in some eclasses (like eutils, multilib) but not others
(like python-single-r1 that I was looking some days ago for learning how
to use it)?
Thanks a lot for the info
It prevents eclasses from being sourced more than once. It is meant as a
performance enhancement for when eclasses inherit other eclasses. vapier
posted some stats on this list a while back.
We have a similar thing in python-single-r1. We call it
_PYTHON_SINGLE_R1 and assign a value of 1 at the bottom of the eclass.
Here's the thread.
http://archives.gentoo.org/gentoo-dev/msg_18dab542c1c59873f8cb68c96cdf6619.xml
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.
Alexis Ballier wrote: - I have package foo and package bar, both depending on ffmpeg and canditates for a multilib build. However, package foo does not link to ffmpeg but simply spawns the 'ffmpeg' binary to process some files, package bar links to libavcodec. You need ffmpeg[multilib] for a multilib build of bar but not for foo. How do you distinguish between the two ? foo.ebuild has RDEPEND=ffmpeg bar.ebuild has DEPEND=ffmpeg[multilib?] Right? - When an out-of-tree build is possible, it is more efficient to do it that way while multilib-portage will probably run the full src_* phases twice. Certainly. //Peter
Re: [gentoo-dev] Proposal to end-of-life tree-clean old profiles/updates/ files
On 01/02/2013 02:46 PM, Brian Dolbec wrote: On Mon, 2012-12-10 at 08:59 +0100, Ulrich Mueller wrote: On Mon, 10 Dec 2012, Sergei Trofimovich wrote: gentoo-x86/profiles/updates $ LANG=C ls -1 --sort=time [long list omitted] old entries are done in different context (comparing to 2012): - some packages change names 2 or 3 times - slots have different meaning moreover: - if you set your PORTDIR to different directory you'll get all that full update. And will break the system. Old profile entries used to break eclass-manpages and latex-base (due to double renaming) It's worse: Bad entries in the old files may go unnoticed for a long time. But if such a file is updated for whatever reason, it will be reprocessed on users' systems, including any bad entries contained in it. Thus the reason for removal is simple: old entries are potentially buggy as nobody verifies them. I wouldn't even know how to verify them. Let's remove that cruft. We can be extra conservative and keep five years of backlog (i.e. everything from before 2008 would be removed now). Ulrich OK, that seems to be some very good reasons to tree-clean them. What's our next step? It might be nice to document the removal policy in the developer handbook, devmanual, or something. Tree-cleaners, does this fall into your department? That seems fitting. Or should I prepare a list of files and/or updates to clean? This command seems to do the trick: $ ls -1 /usr/portage/profiles/updates/ | grep -Ev '(08|09|10|11|12|13)$' 1Q-2004 1Q-2005 1Q-2006 1Q-2007 2Q-2004 2Q-2005 2Q-2006 2Q-2007 3Q-2004 3Q-2005 3Q-2006 3Q-2007 4Q-2004 4Q-2005 4Q-2006 4Q-2007 -- Thanks, Zac
Re: [gentoo-dev] ship app-arch/pbzip2 instead of app-arch/bzip2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/02/2013 06:11 PM, Pacho Ramos wrote: El lun, 29-10-2012 a las 10:39 -0400, Rich Freeman escribió: On Mon, Oct 29, 2012 at 10:13 AM, Rick Zero_Chaos Farina zeroch...@gentoo.org wrote: I'm confident no one would attempt to block my adding eselect-bzip2 to the tree (aside from my poor coding skills), ++ but would anyone be interested in blocking using lbzip2 by default? It seems pretty safe and I've done dozens of full system builds etc. Why not just make it an option to start, advertise it by all means, and then see how it turns out with volunteers before we make it the default. Going from nobody-has-heard-of-it to default overnight seems a bit much. Rich How this ended finally? :/ It ended with my setting PORTAGE_BZIP2_COMMAND=lbzip2 in my profile and moving on with my life. I am very not good at eselect scripts and I've not had the time to dig at it. You are welcome to work on the eselect script if you like. Thanks for the info! - -Zero -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQIcBAEBAgAGBQJQ5N63AAoJEKXdFCfdEflKdn0P/R9W6idHgpd+n7y5nyKQM9si noHmFC6KHJSZJnjO8BlrhsN2HZrgZyPqPIlWLn5VwK+KcDTh0s1y4UGGh22a93qD JodVbmmSJlnWA+EkzNloG+nTk1FxJYnmoL7o6/dhqv5x1Q/FD/xf0rAGCgTvDPSb RuoMbCfkgSwZZlSSJtHr7Xd3w1psAgVemXNcG1C49AmnNrrmEkvawk5SNzg5Ruyn UVMKSbLt1zEkRmUZHWS+lizN+GjFMVlaPEb6KK7ELbYWEMIjBihZ0WqdSWQ5Yxcn yaZN9RTM2xel9tS+PEZjxwCBwb4ndXxuj51zK91WeTeWL+1wvwRXQ0nL+jFi3WfA 9nIHe26Cop5btYnCw2/5wlmKYReAxasql0ZVS8mrob5IgiptMIrxCAhCq8raJVZn VD3+GiWzHYQRBUEkwQq/Qq7n7d5hgyd8l2/CCSgNUxmNbtFLoNWxPK5aVvEeb5EH zyLH0eOQp4JA2ViZtnYgkviFRaEr9pa+Kc2S4BbvPTqYOX7Q7Ah2LMOw8uXQMefB cNlVBa6ar5feAybWkmKH+c9n6mjAU9iCWyuoATSUMpSQ1dPmDnmKmxst4kARgMVK Ou1F4mREQk7N23AqAnREF3b4RNLQqv6ff5GuxG4COjXZpIynFcm4o/x4nnzan6xr ALCXZ5LIRk5D5K//oYJU =yYs4 -END PGP SIGNATURE-
Re: [gentoo-dev] emerge --depclean vs missing IUSE in older ebuild.. what exactly is right?
On 01/02/2013 08:49 AM, Leho Kraav wrote: Ok my conclusion is then that gdm-3.4.1.ebuild should be patched for [systemd?-], considering it seems otherwise fully compatible with current stable pambase. Opinions? Since gdm is using EAPI 4, sys-auth/pambase[consolekit?,systemd(-)?] seems doable. You can file a bug at http://bugs.gentoo.org to have the maintainers fix it (if they agree). -- Thanks, Zac
Re: [gentoo-dev] About *ECLASS_ONCE_* stuff at top of some eclasses but not others
On Wednesday 02 January 2013 18:41:26 Pacho Ramos wrote: and similar in some eclasses (like eutils, multilib) but not others i added it to the most popular eclasses and the ones i maintained. i left the rest up to other people to add it and make sure things still worked. -mike signature.asc Description: This is a digitally signed message part.
[gentoo-dev] collision-protect - protect-owned ?
It came up again with https://bugs.gentoo.org/show_bug.cgi?id=449918, and I think it's worth to think about a better fix. I still keep hitting mysterious collisions with orphaned files from time to time. How about switching the developer profile from collision-protect to protect-owned, and proceeding with enabling protect-owned by default for all profiles? (not all developers are using the developer profile) Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] collision-protect - protect-owned ?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/02/2013 10:49 PM, Paweł Hajdan, Jr. wrote: It came up again with https://bugs.gentoo.org/show_bug.cgi?id=449918, and I think it's worth to think about a better fix. I still keep hitting mysterious collisions with orphaned files from time to time. How about switching the developer profile from collision-protect to protect-owned, and proceeding with enabling protect-owned by default for all profiles? (not all developers are using the developer profile) Paweł I've been using protect-owned for months if not years with no issues at all. collision-protect is a broken implementation, the way it always should have been was as protect-owned is. Protecting unowned files is silly, it only matters when two packages collide. - -Zero -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQIcBAEBAgAGBQJQ5QKIAAoJEKXdFCfdEflKB+8P/3IG6e2yuDH/zGp+PXqRI0YH cUEFw/L1hw8wvOp/rGgLDC0l8JSZTF8gzsiK5IG6ur3JR0+K/dLejR71ug1uPxo0 Vh5Rbq4QrWDWjw/KMhq2pvdVnCY7aK1y0er82vSx49k7bXXuNV3UMnDHP3GnZ/fT w2cji4GT1cO96Ut2tjDRmUebcqcC0rd2eH2MnvewYvOnTuti14P4/1Z4Ur5p+tkf +1yQTp+8ZNjSStAnxsuR5UjNE1b9Exr2+O8wPg5sC2H6fFqjVJjJ+BPA/KlKTVZw mEoSq0+DjGH9ETsPj4/tLUztXf5H6DomT8BBEAPHuZF/WNBShmhyfv4R6iiQjD5v bElSzjjbn5HfViprW9BmZ96xZCOw8FMWb2kuquVefWybGj+F4mI4LN4viBVXdNvf y5vx3/fF9sPuu7wcyWCaHUjV2Nn3fa6CZebxOVXXr5KOMI6OpapIwasRZw+YZehD pz5+FRCPAHixTixZL+AZIxzwuJuTA7EQlolwZ4EiW3jEVmbLQ+vClTFgxDNmDfAz GqL5LsUY5wMcBKjusWoTJO4bx1A5Jnhz9p5xWQgfsvO4j8SycIq855jVTQ9TKpWF rcDMFUyyCDRraLpplm6EWssCiscPrVXjxRlkdbIKMgSf4msMM6h1fVKg5WTeJwbN q5QL1VtGtGccPS/7khtC =Ljgj -END PGP SIGNATURE-
Re: [gentoo-dev] collision-protect - protect-owned ?
On Wed, 02 Jan 2013 19:49:02 -0800 Paweł Hajdan, Jr. phajdan...@gentoo.org wrote: It came up again with https://bugs.gentoo.org/show_bug.cgi?id=449918, and I think it's worth to think about a better fix. I still keep hitting mysterious collisions with orphaned files from time to time. How about switching the developer profile from collision-protect to protect-owned, and proceeding with enabling protect-owned by default for all profiles? (not all developers are using the developer profile) Well, it all depends. protect-owned is easy and lazy. You just get errors on package collisions, care about nothing else. collision-protect cares about every collision. It can help you notice that *your* package lefts orphaned files for some reason or writes where it is not supposed to write. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] collision-protect - protect-owned ?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/03/2013 12:06 AM, Michał Górny wrote: On Wed, 02 Jan 2013 19:49:02 -0800 Paweł Hajdan, Jr. phajdan...@gentoo.org wrote: It came up again with https://bugs.gentoo.org/show_bug.cgi?id=449918, and I think it's worth to think about a better fix. I still keep hitting mysterious collisions with orphaned files from time to time. How about switching the developer profile from collision-protect to protect-owned, and proceeding with enabling protect-owned by default for all profiles? (not all developers are using the developer profile) Well, it all depends. protect-owned is easy and lazy. You just get errors on package collisions, care about nothing else. collision-protect cares about every collision. It can help you notice that *your* package lefts orphaned files for some reason or writes where it is not supposed to write. In the years I ran collision-protect I can say it prevented hundreds of merges of linux-firmware (because the kernel also installs firmware) and not much else. Would you be able to share more specific insight on how collision-protect helped protect files that need to be protected where protect-owned would have been inferior? - -Zero -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQIcBAEBAgAGBQJQ5RZIAAoJEKXdFCfdEflKUxIP/1OApovsseVqUhIPPCQB1Z08 Yua5b2ripFwh/190eqNqvRFStp+K8ZChMMbfhjdjr3kzrqhpvOYHoM6/fdyz8yeC BqOXfTg+wrHkPl5ql1YMv8ZHs8VrGF7ZIRMcwiylS0GaftPwIh1i0nD2ZYEEKhyz FlIY9ZzX4dnKtNXeEahDTu38aLIwF0XWCcPcIOEtFEnaNjgmxVR1ZRmXk1ynB/VQ XYaHNTL6irxA/YkImQR4JCBOAZKyjLZzy6vbLqsjic+MAzpfklmgVebnBY6hWkxK FKfz13Gt9EWno3b0tTDa+OYrVMw0Z84GpMWPILCfChI3YcSj+ODi5ql2yM4avAiU t7lQCTzOYfKCSZOXwAiN65DJL+ssq3DX3kJfA5/uyRmsJfGYMd2M9/F3lbmxhquN lbzhzaJQyyPMCXmsKcKiAAioOL8FhP5jYjuYsH2b6XlCkNC7BB1TaY2FOlvoyZPF 50z31AguddD7ylofVKojU2BPJKF4pKPub5qy+hb0wyCmjEuNjp0W6t20azOZMNM/ LxPLLd7s6+YbgbS1pIbEWPwe2U1bHpkvb2RHZ8tPzCAvtlkT5LcUzV3OdHgZ3kxh Z1hHPTCZJx+7y4aQFJAXvUx0RpnXQ92MsPPMeFGl/j4oIjNvphRlYR9wctDskWst ECOuGbPwMI+PCq1K3DWk =DY2e -END PGP SIGNATURE-
Re: [gentoo-dev] collision-protect - protect-owned ?
On Thu, 2013-01-03 at 00:25 -0500, Rick Zero_Chaos Farina wrote: On 01/03/2013 12:06 AM, Michał Górny wrote: On Wed, 02 Jan 2013 19:49:02 -0800 Paweł Hajdan, Jr. phajdan...@gentoo.org wrote: It came up again with https://bugs.gentoo.org/show_bug.cgi?id=449918, and I think it's worth to think about a better fix. I still keep hitting mysterious collisions with orphaned files from time to time. How about switching the developer profile from collision-protect to protect-owned, and proceeding with enabling protect-owned by default for all profiles? (not all developers are using the developer profile) Well, it all depends. protect-owned is easy and lazy. You just get errors on package collisions, care about nothing else. collision-protect cares about every collision. It can help you notice that *your* package lefts orphaned files for some reason or writes where it is not supposed to write. In the years I ran collision-protect I can say it prevented hundreds of merges of linux-firmware (because the kernel also installs firmware) and not much else. Would you be able to share more specific insight on how collision-protect helped protect files that need to be protected where protect-owned would have been inferior? It protects files that cannot be owned by any one package, but must still be protected, for example /usr/share/glib-2.0/schemas/gschemas.compiled This file contains the compiled database of all your gsettings schemas. It needs to be updated by running glib-compile-schemas every time you install or remove a gsettings schemas xml file. Ebuilds for glib-based stuff have to run glib-compile-schemas in pkg_postinst(), and the gschemas.compiled must remain outside package manager control. However, some packages' build systems have make or make install call glib-compile-schemas by default. A careless developer who doesn't use collision-protect *and* doesn't pay attention to protect-owned's warning messages might accidentally allow his ebuild to compile and install /usr/share/glib-2.0/schemas/gschemas.compiled in src_install(), marking the file as owned by his ebuild. When his ebuild is uninstalled, the gschemas.compiled file would be removed, breaking the system.
Re: [gentoo-dev] Switching order of packages in virtual/pkgconfig
On 02/01/13 15:29, Luca Barbato wrote: last I checked prefix didn't have issues with the pkg-config bootstrap either. there is no circular deps either. check glib deps iirc some non-glibc platforms have few problems with it. not if you enable USE=internal-glib. i've added the USE flag on request from vapier mostly, so we could punt pkg-config-lite from Portage. it should not depend on any of the stuff embedded (uclibc) has problems with anymore. as for anything other than uclibc, glibc, i'd like to see an bug, there isn't one
