Re: [gentoo-dev] Re: last rite of dev-python/elixir
On Thu, Jun 6, 2013 at 12:32 PM, Duncan 1i5t5.dun...@cox.net wrote: IAN DELANEY posted on Thu, 06 Jun 2013 17:55:16 +0800 as excerpted: # Ian Delaney idel...@gentoo.org (06 Jun 2013) # Masked for removal in ~ 30 days. Upstream inactive dev-python/elixir Where's the bug reference one would normally expect to see with such an announcement? http://elixir.ematia.de/trac/report/1?asc=0sort=ticketUSER=anonymous I'm sure Ian would welcome anyone who's willing to maintain an ever-expanding patchset as new maintainer. HTH. HAND. :-) /Peter
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-gfx/nvidia-cg-toolkit/files: 80cgc-opt-2
On Fri, Nov 16, 2012 at 10:43 AM, justin j...@gentoo.org wrote: On 16/11/12 09:48, Samuli Suominen wrote: does this mean it puts the binary-only package, nvidia-cg-toolkit, to the default search path when you call the linker (compiler)? please don't do that, it is counterproductive with the purpose of putting libraries to /opt. binary only packages should be isolated. it was already once reverted for the package... it is up the the ebuilds using nvidia-cg-toolkit to append-ldflags -L/opt/... or similar. thanks +*nvidia-cg-toolkit-3.1.0013-r1 (16 Nov 2012) + + 16 Nov 2012; Justin Lecher j...@gentoo.org +files/80cgc-opt-3, + +nvidia-cg-toolkit-3.1.0013-r1.ebuild, +files/nvidia-cg-toolkit.pc.in, + +files/nvidia-cg-toolkit-gl.pc.in: + Don't add binary packages to global linker search path; instead using + pkg-config. Thanks ssuominen pointing this out + This is a shared library, used by the plugin google-talkplugin. If there is no LDPATH set, browsers using that plugin will crash mysteriously and unpredictably. You can't use chrpath to change the rpath because lengthof(/opt/nvidia-cg-toolkit/lib64)lengthof(/opt/google/talkplugin/lib) and we don't have the sources, so we can't really recompile. And it's being dl-opened so LD_LIBRARY_PATH is a no-go, unless we want to add magic to all browser that sets it to the correct path before starting them. So please re-add the LDPATH to the env.d file. Pretty please. Just cause it's binary doesn't mean it has to be cordoned off and isolated like it's got the spanish flu. /Peter PS pkgconfig is irrelevant if it's only gentoo that's shipping them. HTH. HAND.
Re: [gentoo-dev] RFC: virtual/libudev
This outcome was just super. Systemd was bumped to -188 today. Udev is still at -187. Instead of actually listening to upstream[1], which would be easy with a virtual, we're now stuck with one part of the duo being at one version and the other part of the duo another. And when I login to X with this combo, my display is /upside-down/. And I don't know if it's because our hackery on the tarball has left out some vital part, because disabling stuff in the one ebuild (gudev in systemd) and enabling it in the other is going to cause some non-trivial problem, or if it's simply a bug upstream. But that's okay, because gentooers are powerusers and we're supposed to have the time to debug this stuff, right? This is disgusting. Really. Virtuals are simple. This stuff is freaking *hard*. Whoever it was that forced this on systemd in gentoo should have a big *object* stuck in *place* and be forced to *action* as penance for the time I'll have to waste fixing this. [1] And what we will certainly not do is compromise the uniform integration into systemd for some cosmetic improvements for non-systemd systems. (Yes, udev on non-systemd systems is in our eyes a dead end, in case you haven't noticed it yet. I am looking forward to the day when we can drop that support entirely.) http://lists.freedesktop.org/archives/systemd-devel/2012-August/006066.html Meaning: For now, you're allowed to have udev without systemd but mixing-and-matching udev versions and systemd versions will be unsupported and patching udev will probably break systemd at some point. TL;DR: This is a sucky situation you've put all users of udev in.
Re: [gentoo-dev] RFC: virtual/libudev
On Sat, Aug 11, 2012 at 8:29 PM, Michał Górny mgo...@gentoo.org wrote: On Sat, 11 Aug 2012 20:11:18 +0200 Peter Alfredsen peter.alfred...@gmail.com wrote: This outcome was just super. Systemd was bumped to -188 today. Udev is still at -187. Instead of actually listening to upstream[1], which would be easy with a virtual, we're now stuck with one part of the duo being at one version and the other part of the duo another. And when I login to X with this combo, my display is /upside-down/. What was your previous state? Were you using older systemd with newer udev? No, I was using the integrated package -187. Downgrading fixed the problem. /Peter
Re: [gentoo-dev] RFC: virtual/libudev
On Wed, Jul 11, 2012 at 11:04 PM, Michał Górny mgo...@gentoo.org wrote: On Wed, 11 Jul 2012 15:27:41 -0400 Mike Gilbert flop...@gentoo.org wrote: Personally, I think a consolidated systemd/udev package is the best way to go here. A consolidated package means that: - every change made by udev developers would have to be reviewed by systemd team to make sure it doesn't break systemd. udev developers don't use systemd; - every change made by systemd developers would have to be reviewed by udev team to make sure it doesn't break openrc. systemd developers usually don't run openrc; - udev developers will force me to use eclasses they like and force their coding style on me; - i will force eclasses I like and my coding style on udev developers; - new udev wouldn't be able to be stabilized without systemd being stabilized at the same time (and I don't really think systemd is in any condition to go stable), - there will be a few random flags which will either work or not, depending on a state of magical switch flag, - and after all, the ebuild will be basically one big use-conditional. So, since this is blocking up development and people actually solving things, could we just have virtual/udev and be done with it? Upstream obviously reneged on their promise to make the component parts buildable separately, so the virtual seems like the only sane choice right now. /Peter
Re: [gentoo-dev] openswan compile issue with glibc-2.10
On Mon, 01 Jun 2009 23:10:47 +0300 Timur Aydin t...@taydin.org wrote: Today I have tried to merge openswan-2.4-14 into my ~x86 system. The compilation failed because of a name clash: Please attach your patch here: https://bugs.gentoo.org/show_bug.cgi?id=271987 We use bugzilla for bug reports. /loki_val
Re: [gentoo-dev] GLEP 55 updated
On Sun, 17 May 2009 17:56:06 +0200 Piotr Jaroszyński pe...@gentoo.org wrote: I know gentoo has other problems too, but it's the new and innovative stuff that makes working on Gentoo fun. YES ! /loki_val
Re: [gentoo-dev] GLEP 55 updated
On Sun, 17 May 2009 22:54:38 +0530 Nirbheek Chauhan nirbh...@gentoo.org wrote: On Sun, May 17, 2009 at 9:36 PM, Peter Alfredsen loki_...@gentoo.org wrote: On Sun, 17 May 2009 17:56:06 +0200 Piotr Jaroszyński pe...@gentoo.org wrote: I know gentoo has other problems too, but it's the new and innovative stuff that makes working on Gentoo fun. YES ! I sincerely hope that was sarcasm. I don't want us to get to a place where every single new feature has to be delayed by the objection We've got basic bugs we need to fix first. That's just unreasonable and a straw man. I get my kicks from improving things, not from fixing broken things. You may object and say they're one and the same, and you would not be wrong, but the emphasis *is* different. People seem to not see that in the case of GLEP 55 and some call for a moratorium on new features till we've fixed the bugs that already exist. Not gonna happen. The human spirit is what's driving Gentoo, giving it life. Our aspirations to improve the world around us lives and breathes with every ebuild we churn out. World domination is our goal and we won't get there by letting the maintainer-needed queue bog us down. I think that it's obvious to everybody that the problem GLEP 55 is solving is real. To me, .ebuild-$eapi/.eapi-$eapi.eb looks like the best solution, all things considered. From a purely unixy point-of-view, I see the cleanliness of a shebang EAPI definition, and that would be my second choice, but we need a solution we can use now. Not a year from now. Time really does matter. My dislike for the GLEP 55 process is my main reason for supporting GLEP 55 as-is. If we can skip just one more 50-mail thread because of GLEP55, it will be worth the extra work of typing -$eapi every now and then. Because seriously, if ever there was a mailing list topic whose only effect has been to act like a succubus, GLEP 55 is it. ( In other words: No sarcasm intended ) /loki_val
Re: [gentoo-dev] The fallacies of GLEP55
On Thu, 14 May 2009 22:03:22 +0200 Ben de Groot yng...@gentoo.org wrote: I concur that speaking for myself, I don't understand the issue. And it looks like many others don't either. So if anyone wants to promote this GLEP, their job is clear: make people understand what the issue is here, and convince them it is actually an issue. (Examples, scenarios usually work well, indeed a lot better than calling people names.) We need a mechanism to be able to use newer bash-features in ebuilds. Preferably one that doesn't go Wait a couple of years, hope everyone did X then Just Do it. We want one that goes like Get a new EAPI approved with new minimum bash-version attached, start using cool stuff like ( Bash-4.0 ): shopt -s globstar for i in /usr/share/man/**/*remote* do stuff done Built-in find in bash, how do you like them bananas? :-) find equivalent would be, if you wanted the same level of space-safety: while read -r line do stuff done (find /usr/share/man -name '*remote*') Personally, I like the first version better. It would be cool if we could start using it sooner. GLEP-55 provides the clean solution, by just making the file name indicate what's inside. No need to parse, no nothing. Portage is currently testing a first line with EAPI= determines EAPI method. That's slightly less clean, but has the added benefit of not breaking anything that relies on .ebuild extension for ebuilds and I think it's not an unreasonable limitation on ebuilds to require EAPI= to be parseable by !bash. /loki_val
Re: [gentoo-dev] Project summaries
On Wed, 6 May 2009 08:49:53 +0200 Christian Faulhammer fa...@gentoo.org wrote: Hi, any project lead/member can post an answer to this mail for a status report: Gentoo .NET progress Currently doing good. Nothing much to report. Everything is shiny and well-oiled. SVN ebuilds of trunk and branches were recently committed to the main tree, which will help when people report bugs. Generally trying to maintain as little distance between the main tree and the overlay as possible, so user feedback can be utilized most efficiently. ~arch is really the testing branch for Mono packages, IOW, but I try to fix bugs real quick when they're reported so most of you never notice they were there. Cool new apps which everyone should be using: Tasque for managing your everyday scheduling needs. Monsoon shiny bittorrent client Bareftp easy and accessible ftp client Cool old apps which everyone should be using: Tomboy notetaking application Banshee the best media-player out there Beagle desktop search Gnome-DoLOOK! SHINY! And of course mod_mono, for your ASP.NET needs. What we need: People who care about portable.NET enough to make it great. People who use the ASP.NET features. I can probably debug it for you, but if there's a bug in mod_mono, I won't discover it before you do. Notable successes: Bumping Mono-2.4 before Novell :-) Shaving bugs assigned to dot...@gentoo.org down to a reasonable level. Attracting users to Gentoo through our .NET offering. Future projects: revdep-rebuild support for mono! AOT support Getting Mono tests to not fail in Sandbox. Reducing the bus-factor. I have too much of this stuff in my head. I should write docs... Later.
Re: [gentoo-dev] Gentoo Council Reminder for April 23
On Fri, 17 Apr 2009 15:17:15 -0700 Donnie Berkholz dberkh...@gentoo.org wrote: If you have something you'd wish for us to chat about, maybe even vote on, let us know! Simply reply to this e-mail for the whole Gentoo dev list to see. Up or down vote on USE=static-libs. It seems it wasn't actually voted on last time it was brought up. We now have EAPI=2 use-deps and I just committed dev-util/lafilefixer for the .la file problems. I see no more obstacles for getting this adopted. /loki_val
Re: [gentoo-dev] Gentoo Council Reminder for April 23
On Sun, 19 Apr 2009 12:21:55 -0400 Thomas Anderson gentoofa...@gentoo.org wrote: Why are we trying to get rid of static libraries again? I have not seen any compelling reason to remove libraries that may be useful to our users. Perhaps I've missed some discussion(in which case, I'd love to read it), but this seems like an unnecessary complexity. I am a user. I don't want them. The current situation where q...@g.o requires .a files to be installed is just ghastly. A policy with no good reason whatsoever, other than the ancients did it this way, so shall we. TBH, i see more reasons for splitdebug and -ggdb being defaults than I do for static libs. And even then, I'd want a way to turn it off. A reasonable default would be --disable-static. Then libs that have in-tree consumers of their static libs could then make a use-flag, users who need them could use EXTRA_ECONF=--enable-static. But that's not what I'm after. For now I just want a way to turn .a generation off. At the moment 500MB of prime space on /usr/lib64 is being used by .a files. That's about 450MB more than is needed (last I checked). /loki_val
Re: [gentoo-dev] Gentoo Council Reminder for April 23
On Sun, 19 Apr 2009 18:14:36 +0100 Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Sun, 19 Apr 2009 19:10:50 +0200 Peter Alfredsen loki_...@gentoo.org wrote: A reasonable default would be --disable-static. Then libs that have in-tree consumers of their static libs could then make a use-flag, users who need them could use EXTRA_ECONF=--enable-static. If you're going to do that, why not do it as an EAPI thing? This has the added bonus that there's a clean migration path... If we ever decide to do that, eapi would be a sane way to do it. Right now, we're only discussing making static libs configurable. The other bits we can deal with when we come to them. /loki_val
Re: [gentoo-dev] EAPI-3 draft: slot operator support
On Thu, 09 Apr 2009 12:03:03 +0200 Rémi Cardona r...@gentoo.org wrote: Could anyone actually give a good reason for slot operators? What packages would have a _clear_ benefit from using them? I'm asking for an actual list of packages, not just some package that may exist in a parallel universe. All package depending on dev-dotnet/gtk-sharp. Although these won't be parallel-installable slots, it will really easy the transition between versions and allow us to ease the currently quite strict interdependencies between the various packages that make up the gtk-sharp, gnome-sharp and gnome-desktop-sharp tarballs, where all versions of all packages are bound to a single gtk-sharp major version (2.12 at the moment). Currently we handle bumps in api by bumping every package in this trifecta from hell. That way, users only have to rebuild their apps, portage will take care of rebuilding the -sharp libs.
Re: [gentoo-dev] EAPI-3 draft: slot operator support
On Thu, 9 Apr 2009 16:29:53 +0530 Nirbheek Chauhan nirbh...@gentoo.org wrote: I think the current way is the most easily-supportable way for us. Complex interdependencies b/w packages and slots = O(n^k) times bugs, where k = no. of slots for a library. If we don't get all those bugs, it means people are running the latest package and latest slot. So slot operators would be m00t in that case. I wouldn't be using slotdeps as actual slotdeps, more like ABI deps. Each slot would soft-block all other slots, so upgrades would be handled normally by portage. Only, all other packages could use slotdeps to be rebuilt when a new version of gtk-sharp is released. It would probably take a bit of eclass fudgery, but it could be made to work. Also, it would allow people to mix ~arch and arch for -sharp stuff. Which would be good. As I said, I would be using slot-deps as ABI-deps. I would find actual ABI deps to be vastly more useful since I wouldn't have to keep track of earlier slots to block. Imagine a world with no revdep-rebuild? /loki_val
Re: [gentoo-dev] EAPI-3 draft: slot operator support
On Thu, 9 Apr 2009 17:06:47 +0530 Nirbheek Chauhan nirbh...@gentoo.org wrote: So you're looking for ABI deps? @preserved-libs is the answer (C-sharp support for that?). Suggested rebuilds upon upgrade? Separate issue, separate solution (pkg_pretend maybe?) @preserved-libs is a horrible hack that is used in place of ABI deps. It requires a seperate implementation for each language/subset of packages and does not take into account silent ABI breakage. *DO*NOT*WANT* In other words. :-)
Re: [gentoo-dev] Real multilib support for Gentoo
On Sun, 05 Apr 2009 14:07:37 +0200 Thomas Sachau to...@gentoo.org wrote: Tiziano Müller schrieb: With this, i would also like to see any changes that need an EAPI to get into EAPI-3. No. Won't happen. Can you also explain your statement? EAPI-3 is closed for new features. We want it implemented and in-tree ASAP. /loki_val
Re: [gentoo-dev] `paludis --info' is not like `emerge --info'
Paludis --info does not work for me. Plz2fix. In particular, have a look at http://bugs.gentoo.org/show_bug.cgi?id=262277#c4 Where both emerge --info and paludis --info is posted. Sometimes, more is less. While it may be useful to post all the information about the package-manager for *you*, it's not helping us (bug-wranglers) any. We need one screenfull of text that concisely shows us the state of your system. We really can guess a lot from the emerge --info output. We don't really want to care which package manager you're using, apart from a discrete text. Also, we still get people who just post their paludis --info. Could you please put in *bold letters* at the top of that output that it's not the info they'll need when reporting bugs. Thanks, loki_val
Re: [gentoo-dev] Preserving mtimes for EAPI3
On Mon, 30 Mar 2009 15:40:14 +0100 Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: No, an EAPI bump is necessary. Older (post-EAPI) Portage versions do something different, so any ebuild relying upon particular behaviour is already broken. For an example of this, see http://bugs.gentoo.org/264308
[gentoo-dev] Please review: poppler.eclass
Hi,
This is an eclass that provides functionality needed to further split
poppler into its constituent libraries and utilities. The current way
of doing this, where we have poppler with utils in app-text/poppler and
the bindings for qt3, qt4 and glib in app-text/poppler-bindings is
suboptimal.
1) it requires us to either enable by default a useflag that will pull
in a major toolkit or die when all use-flags are unset.
2) The cairo use-flag is a subset of the gtk use-flag (which is in
itself misnamed) and thus enabling [cairo] will enable [gtk] but
without this being reflected in the metadata.
Also, as part of the restructuring, I will be able to move packages
around a bit so the libs are put in dev-libs/poppler{,-glib,-qt3,-qt4}
and the utils are put in app-text/poppler-utils.
Without further ado, the eclass:
inherit base multilib
has 2 ${EAPI} || DEPEND=EAPI-TOO-OLD
EXPORT_FUNCTIONS src_unpack src_prepare src_configure src_compile src_install
# @ECLASS-VARIABLE: HOMEPAGE
# @DESCRIPTION:
# HOMEPAGE is set to http://poppler.freedesktop.org
HOMEPAGE=http://poppler.freedesktop.org/;
# @ECLASS-VARIABLE: SRC_URI
# @DESCRIPTION:
# SRC_URI is set to http://poppler.freedesktop.org/poppler-${PV}.tar.gz
SRC_URI=http://poppler.freedesktop.org/poppler-${PV}.tar.gz;
# @ECLASS-VARIABLE: S
# @DESCRIPTION:
# S is set to ${WORKDIR}/poppler-${PV}
S=${WORKDIR}/poppler-${PV}
# @ECLASS-VARIABLE: POPPLER_MODULE
# @DESCRIPTION:
# The name of the poppler module. Must be set by the ebuild before inheriting
# the poppler eclass.
POPPLER_MODULE=${POPPLER_MODULE}
# @ECLASS-VARIABLE: POPPLER_MODULE_S
# @DESCRIPTION:
# The working directory of the poppler module. Set by default to
# ${S}/${POPPLER_MODULE}
POPPLER_MODULE_S=${S}/${POPPLER_MODULE}
# @FUNCTION: pkg_check_modules_override
# @USAGE: GROUP [package1] [package2]
# @DESCRIPTION:
# Will export the appropriate variables to override PKG_CHECK_MODULES autoconf
# macros, with the string by default. If packages are specified, they will
# be looked up with pkg-config and the appropriate LIBS and CFLAGS substituted.
# LIBS and CFLAGS can also be specified per-package with the following syntax:
# @CODE
# package=LIBS%CFLAGS
# @CODE
# = and % have no effect unless both are specified.
# Here is an example:
# @CODE
# pkg_check_modules_override GASH gtk+-2.0=-jule% gobject-2.0
# @CODE
# The above example will do:
# export GASH_CFLAGS+= -jule
# export GASH_LIBS+=
# export GASH_CFLAGS+= $(pkg-config --cflags gobject-2.0)
# export GASH_LIBS+= $(pkg-config --libs gobject-2.0)
#
# NOTE: If a package is not found, the string will be inserted in place of
# GROUP_CFLAGS and GROUP_LIBS
pkg_check_modules_override() {
local package
local group=${1}
local packages=${*:2}
export ${group}_CFLAGS=
export ${group}_LIBS=
if [[ $...@} -lt 1 ]]
then
eerror ${FUNCNAME[0]} requires at least one parameter: GROUP
eerror PKG_CHECK_MODULES(GROUP, package1 package2 etc)
die ${FUNCNAME[0]} requires at least one parameter: GROUP
fi
for package in $packages
do
if [[ ${package/=} != ${package} ${package/\%} != ${package}
]]
then
package_cflag_libs=${package##*=}
export ${group}_CFLAGS+= ${package_cflag_libs%%\%*}
export ${group}_LIBS+= ${package_cflag_libs##*\%}
else
if pkg-config --exists $package
then
export ${group}_CFLAGS+= $(pkg-config --cflags
$package)
export ${group}_LIBS+= $(pkg-config --libs
$package)
else
export ${group}_CFLAGS+=
export ${group}_LIBS+=
fi
fi
done
}
# @FUNCTION: poppler_src_unpack
# @DESCRIPTION:
# Runs unpack ${A}
poppler_src_unpack() {
unpack ${A}
}
# @FUNCTION: poppler_src_prepare
# @DESCRIPTION:
# Runs autopatch from base.eclass.
# Uses sed to replace libpoppler.la references with -lpoppler
poppler_src_prepare() {
base_src_util autopatch
sed -i \
-e 's#$(top_builddir)/poppler/libpoppler.la#-lpoppler#' \
$(find . -type f -name 'Makefile.in') || die Failed to sed
proper lib into Makefile.am
}
# @FUNCTION: poppler_src_configure
# @DESCRIPTION:
# Makes sure we get a uniform Makefile environment by using
pkg_check_modules_override to
# fill out some blanks that configure wants filled. Probably not really needed,
but
# insures against future breakage.
# Calls econf with some defaults.
poppler_src_configure() {
pkg_check_modules_override CAIRO cairo
pkg_check_modules_override POPPLER_GLIB glib-2.0
pkg_check_modules_override POPPLER_QT4 QtCore QtGui QtXml
pkg_check_modules_override
Re: [gentoo-dev] Please review: poppler.eclass
On Wed, 25 Mar 2009 19:34:01 +0100
Tomáš Chvátal scarab...@gentoo.org wrote:
Dne středa 25 Březen 2009 19:25:02 Peter Alfredsen napsal(a):
I will just pick parts with notes. Some of them apply on more
places :]
# @ECLASS-VARIABLE: HOMEPAGE
# @DESCRIPTION:
# HOMEPAGE is set to http://poppler.freedesktop.org
HOMEPAGE=http://poppler.freedesktop.org/;
Why you describe the variable with default value? it shows up default
value in the eclassdoc based on the real HOMEPAGE value, so it is
just duplicating :]
Fixed. Thanks. Also added @ECLASS and generally made eclass-manpages
like it.
's#$(top_builddir)/poppler/libpoppler.la#-lpoppler#' \
$(find . -type f -name 'Makefile.in') || die Failed to sed proper lib into
Makefile.am
Are you sure that the find is safe with something like space in the
path? ;]
Not a problem in this case. Known working-environment.
econf --disable-static\
[...]
${POPPLER_CONF} \
|| die configuration failed
No need for die, it dies itself.
Fixed.
(The reason why I don't use inherited functions is that I want
everything to be explicit, available in one eclass, so I don't have to
hunt through all the inherited eclasses to see which function is
actually being used. It doesn't hurt to do it dumb-but-simple in
eclasses.)
/loki_val
Re: [gentoo-dev] Packages up for grabs
On Mon, 23 Mar 2009 11:26:06 -0100 Jorge Manuel B. S. Vicetto jmbsvice...@gentoo.org wrote: [...] Saleem Abdulrasool (compnerd) [...] dev-dotnet/dbus-glib-sharp dev-dotnet/dbus-sharp [...] Snatched
[gentoo-dev] Packages up for grabs: genstef gems special edition
Since genstef has been .away for some time, I arranged with him that I'd send a list of his ebuilds that need maintenance to be put up for grabs. This list contains all ebuilds that have no herd, at least one open bug and where genstef is the maintainer. media-video/linux-uvc media-video/isight-firmware-tools media-video/kavi2svcd sys-fs/dmraid dev-libs/liblazy net-misc/vde sys-apps/ivman media-gfx/picasa app-portage/getdelta x11-themes/gtk-engines-qt x11-misc/googleearth And the grand prize: x11-libs/agg net-www/gnash Which go together. I think gnash is agg's only consumer. Please also note that genstef's .away is currently set to: Feel free to fix or take over any of my packages @ 2009/03/23 21:21Z So any other packages of genstef's are also up for the taking. /loki_val
Re: [gentoo-dev] RFC: Deprecating EAPI0
On Sat, 21 Mar 2009 18:37:12 +0100 Patrick Lauer patr...@gentoo.org wrote: To make our lives easier I would suggest deprecating EAPI0 and migrating existing ebuilds over some time to EAPI1 or higher until EAPI0 can be obsoleted at some point in the future. I would set the start of deprecation warnings about 3 months from now and the obsoletion quite a time later, maybe 12 months from now, when a sufficient amount of ebuilds has been migrated. As always, wording is important. I think having too many EAPIs in active use unnecessarily complicates things, such as remembering which features are offered by which EAPIs, etc. I think we should start deprecating EAPI=0 usage *now* with a repoman warning whenever a new ebuild is committed that does not use EAPI=1 or EAPI=2. This warning should encourage use of the newest EAPI, EAPI=2. Obsoleting EAPI=0 should occur when the decision to do so merely codifies the state of the tree (at 90% EAPI0, to pick a number ), at which point the warning would be changed to an error. We could then use a couple of bugdays to convert the remainder of the ebuilds or hand them over to treecleaners if it's just unmaintained cruft. In a year or so, we could change the repoman warning to trigger with EAPI=1 also and make it point to EAPI=3 as the EAPI-of-choice. Deprecating EAPI1 at the same time would reduce the amount of EAPIs we have to think about, but since it has some changes like adding src_prepare migration would not be as trivial. So I'd prefer keeping it around a bit longer. Comments? We need to make this a part of the EAPI-upgrade process that whenever a new EAPI is added, we consider including another EAPI in the repoman warning. My hope is that at some point in the future (4 years?), we'll be able to cut out some of the ugly phase hacks we have in many eclasses that had EAPI=2 grafted onto them. /loki_val
Re: [gentoo-dev] Ideas for a (fast) EAPI=3
On Mon, 9 Mar 2009 20:26:24 + Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: * src_test run unless RESTRICTed or explicitly disabled by the user (bug 184812) This one is not uncontroversial and will not go in a 'quick' EAPI I think. /loki_val
Re: [gentoo-dev] Developer Retirements
On Mon, 9 Mar 2009 13:44:55 -0500 Doug Goldstein car...@gentoo.org wrote: I'm wondering what exactly is the harm in letting developers idle for a while? Nothing, as long as they don't pretend to be maintaining packages while they idle. See compnerd and his tonne of system-packages for reference. It unnecessarily complicates things if people just step out for half a year and don't leave an .away or re-assign their packages. The fact that someone only does one commit a year does not marginalize their contribution. While it may be small it is improving the overall quality of the distro. I'm constantly seeing developers getting upset over getting pushed out. They are not being pushed out. One commit a month is not much to ask. That's one speeling fix per month to be considered an active dev. If they can't be bothered to do that, well, I really feel for them, but they should just hand over their keys and submit their yearly commit as a patch instead. They're even welcome to CC me, citing this thread and my promise to commit their patch and I shall do it. Problem solved. /loki_val
Re: [gentoo-dev] How to speed up maintenance and other Gentoo work?
On Wed, 04 Mar 2009 04:01:36 +0200
Mart Raudsepp l...@gentoo.org wrote:
I'm collecting ideas from the wider development and contributing
community on how to help maintainers and contributors get work done
quicker, or rephrased - how to get more done in the limited time we
have.
Something like what Debian does where a central service monitors
upstream ftp and notifies you when a bump is available.
Per-package eclasses - eblits standardized.
Crazy idea: Not-quite-eclasses. Some way to share small bits of code
between packages, though the code may not be eclass-worthy. We all know
the use-cases:
[[ -f ChangeLog ]] \
{ dodoc ChangeLog || die ChangeLog exists but cannot be dodoc'ed ; }
And bits of code of that ilk.
Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives
On Wed, 25 Feb 2009 00:21:23 +0200 Petteri Räty betelge...@gentoo.org wrote: Let's try something new. I would like to get opinions from as many people as possible about GLEP 55 and alternatives listed here in order to get some idea what the general developer pool thinks. [...] I dislike GLEP 55 aesthetically, but I see no other way to move out of this deadlock where we can't use new bash-features till years have passed. So unless someone suggests a solution that allows us to have EAPI as part of the ebuild without having to wait till hell freezes over, I'm behind GLEP 55 as the least-bad solution. /loki_val
Re: [gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)
On Mon, 23 Feb 2009 08:43:09 -0700 Steve Dibb bean...@gentoo.org wrote: Plus, I don't really grasp the whole we have to source the whole ebuild to know the EAPI version argument. It's one variable, in one line. Can't a simple parser get that and go from there? The problem is that its technically allowed for the value of $EAPI to be dependent on other bits and pieces. For instance: if [[ $PV = 2.6 ]] then EAPI=2 else EAPI=1 fi The quick-n-dirty solution to that is to just say that EAPI is not just a bash variable, it's also a magic string, so manipulating it in bash is forbidden. And please place it in line 5 of your ebuild, kthxbye. To be honest I see no good reason for allowing manipulation of it, but I'm sure other people will tell me why adding this requirement at this point is wrong even though no ebuilds in the tree to the best of my knowledge use EAPI as anything more than a declaration that's placed Just before inherit, right after the header. /loki_val
[gentoo-dev] Last rites: media-video/gephex
+# Peter Alfredsen loki_...@gentoo.org (15 Feb 2009) +# Masking for removal in 30 days. +# Fails to build with gcc-4.3, bug 250712 +media-video/gephex +
Re: [gentoo-dev] Packages up for grabs
On Wed, 11 Feb 2009 19:02:12 +0100 Santiago M. Mola coldw...@gentoo.org wrote: media-sound/last-exit *snatched*
[gentoo-dev] Last rites: media-sound/monopod
+# Peter Alfredsen loki_...@gentoo.org (1 Feb 2009) +# Masked for removal in 30 days. Old and unmaintained. Upstream is gone. +# Does not work with current ipod-sharp versions, see 195746. This +# removes half of its functionality. +# Is faily, see bug 256473. +media-sound/monopod +
[gentoo-dev] Last rites: dev-dotnet/gtkgl-sharp
# Peter Alfredsen loki_...@gentoo.org (30 Jan 2009) +# Nothing uses this anymore, depends on gtk-sharp:1 +# Masked for removal in 30 days. +dev-dotnet/gtkgl-sharp +
[gentoo-dev] Last rites: dev-dotnet/mcatalog
+# Peter Alfredsen loki_...@gentoo.org (30 Jan 2009) +# No longer maintained upstream, depends on gtk-sharp:1 +# Masked for removal in 30 days. +dev-dotnet/mcatalog +
Re: [gentoo-dev]
[Mike: This looks like your field of expertise] On Tue, 27 Jan 2009 16:47:50 +0100 Tobias Klausmann klaus...@gentoo.org wrote: Hi, glibc 2.9 uses a different way to implement getaddrinfo() which triggers a race condition in most (if not all) Netfilter firewalls that use connection tracking. glibc does nothing wrong per se, it just triggers the condition. (technical details here: http://marc.info/?l=linux-netdevm=123304473331445) [...] I don't have any experience with glibc upstream but pestering them about this out of the blue might only cause a flame war between kernel and glibc folks. Thus, I'm asking you, my fellow devs (and the glibc and kernel teams specifically), what you think is the best idea/course of action. The connection with IPv6 leads me to believe that this is http://bugs.gentoo.org/250468 http://sourceware.org/bugzilla/show_bug.cgi?id=7060 Mike has added a patch to Gentoo's patchset but hasn't bumped the revision yet. It does look spectacularly hacky, though :-) Anyway, if this is your problem, it looks like upstream is already working on it and that we just need to *prod* Mike a bit to get a fix into the tarball. /PA
Re: [gentoo-dev] New eclass: go-mono.eclass
On Sat, 17 Jan 2009 14:04:28 +0200
Petteri Räty betelge...@gentoo.org wrote:
# @FUNCTION: go-mono_src_unpack
# @DESCRIPTION: Runs default()
go-mono_src_unpack() {
default
}
What's the point? The ones from base.eclass should be doing the same
thing as the default ones any way.
The same goes for src_compile.
To make sure we know what we are getting and don't have to go searching
through more than one eclass to see exactly what a function does.
local COMMONDOC=( AUTHORS ChangeLog README TODO )
I wouldn't write local variables with capital letters.
Sure, we can paint the bikeshed green :-)
/PA
Re: [gentoo-dev] New eclass: go-mono.eclass
On Sat, 17 Jan 2009 16:31:30 +0300
Peter Volkov p...@gentoo.org wrote:
Hi Peter.
NO_MONO_DEPEND=(
dev-lang/mono
dev-dotnet/libgdiplus
dev-dotnet/gluezilla
)
Just curious. What are the reasons to use array here?
I try to use arrays as often as possible, so I don't have to worry
about the shortcomings of variables. In the above example, you're
correct that there's no reason to use them over variables.
go-mono_src_install () {
emake -j1 DESTDIR=${D} install || die install failed
Is parallel make broken everywhere? :O This is real pain since smp
systems became much more common these days.
It's only the install phase, and yes, it's generally broken. But that's
not really newsworthy, is it?
/PA
BTW
--jobs combined with --load-average rocks for smp systems. Total system
rebuild of 1200 packages in 12 hours.
[gentoo-dev] New eclass: go-mono.eclass
Below is a copy of the eclass I intend to use for all apps from
go-mono.com (AKA mono-project.com). Pretty standard fare. The affected
ebuilds are:
www-apache/mod_mono
dev-dotnet/xsp
dev-dotnet/libgdiplus
dev-dotnet/gluezilla
dev-lang/mono
dev-lang/mono-basic
dev-util/mono-debugger
dev-util/mono-tools
I'll be committing it tomorrow together with version 2.2 of the mono
stack unless anybody has a good reason not to.
--
/PA
# Copyright 1999-2008 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: /var/cvsroot/gentoo-x86/eclass/mono.eclass,v 1.9 2008/12/13 13:59:02
loki_val Exp $
# @ECLASS: go-mono.eclass
# @MAINTAINER:
# dot...@gentoo.org
# @BLURB: Common functionality for go-mono.org apps
# @DESCRIPTION:
# Common functionality needed by all go-mono.org apps.
inherit base versionator mono
NO_MONO_DEPEND=(
dev-lang/mono
dev-dotnet/libgdiplus
dev-dotnet/gluezilla
)
GO_MONO_REL_PV=$(get_version_component_range 1-2)
if ! has ${CATEGORY}/${PN} ${no_mono_depe...@]}
then
RDEPEND==dev-lang/mono-${GO_MONO_REL_PV}*
DEPEND=${RDEPEND}
fi
# @ECLASS-VARIABLE: PRE_URI
# @DESCRIPTION: If installing a preview, set this variable to the base
# path on ximians's servers from which to install.
DEPEND=${DEPEND}
=dev-util/pkgconfig-0.23
if [[ ${GO_MONO_REL_PV} = 2.2 ]]
then
PRE_URI=http://mono.ximian.com/monobuild/preview/sources;
fi
if [[ ${PV%_rc*} != ${PV} ]]
then
GO_MONO_P=${P%_rc*}
SRC_URI=${PRE_URI}/${PN}/${GO_MONO_P} - ${P}.tar.bz2
S=${WORKDIR}/${GO_MONO_P}
elif [[ ${PV%_pre*} != ${PV} ]]
then
GO_MONO_P=${P%_pre*}
SRC_URI=${PRE_URI}/${PN}/${GO_MONO_P} - ${P}.tar.bz2
S=${WORKDIR}/${GO_MONO_P}
else
GO_MONO_P=${P}
SRC_URI=http://ftp.novell.com/pub/mono/sources/${PN}/${P}.tar.bz2;
fi
# @FUNCTION: go-mono_src_unpack
# @DESCRIPTION: Runs default()
go-mono_src_unpack() {
default
}
# @FUNCTION: go-mono_src_prepare
# @DESCRIPTION: Runs autopatch from base.eclass, if PATCHES is set.
go-mono_src_prepare() {
base_src_util autopatch
}
# @FUNCTION: go-mono_src_configure
# @DESCRIPTION: Runs econf, disabling static libraries and dependency-tracking.
go-mono_src_configure() {
econf --disable-dependency-tracking \
--disable-static\
$@
}
# @FUNCTION: go-mono_src_configure
# @DESCRIPTION: Runs default()
go-mono_src_compile() {
default
}
# @ECLASS-VARIABLE: DOCS
# @DESCRIPTION: Insert path of docs you want installed. If more than one,
# consider using an array.
# @FUNCTION: go-mono_src_install
# @DESCRIPTION: Rune emake, installs common doc files, if DOCS is
# set, installs those. Gets rid of .la files.
go-mono_src_install () {
emake -j1 DESTDIR=${D} install || die install failed
mono_multilib_comply
local COMMONDOC=( AUTHORS ChangeLog README TODO )
for docfile in ${commond...@]}
do
[[ -e ${docfile} ]] dodoc ${docfile}
done
if [[ ${do...@]} ]]
then
dodoc ${do...@]} || die dodoc DOCS failed
fi
find ${D} -name '*.la' -exec rm -rf '{}' '+' || die la removal
failed
}
EXPORT_FUNCTIONS src_unpack src_prepare src_configure src_compile src_install
[gentoo-dev] Last rites: app-editors/katoob
+# Peter Alfredsen loki_...@gentoo.org (20 Dec 2008) +# Masked for removal in 30 days. Version that compiles with gcc-4.3 +# is not ready for stable ( bug 251566 ). +# Upstream has abandoned it, alternatives such as gedit exist. +app-editors/katoob + -- /PA signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: gtk-sharp-module.eclass
On Wednesday 26 November 2008, Donnie Berkholz wrote:
On 23:52 Tue 25 Nov , Peter Alfredsen (loki_val) wrote:
loki_val08/11/25 23:52:04
Added:gtk-sharp-module.eclass
Log:
eclass required for gnome-sharp and gnome-desktop-sharp packages
Did I miss this on gentoo-dev? All eclasses must be sent there for
review before addition to the tree.
*loki_val bumps his head into the wall.
See, what happened was...
I have been doing nothing else but testing and bumping dotnet packages
for the last 3 days when not at work, so I kind of forgot that step.
Fortunately all packages using this eclass are still in package.mask.
Anyway, the eclass is derived from the gtk-sharp-component eclass (which
is a real bitrot mess that has to support 3 or 4 different naming
schemes) and is basically a simplification of that.
if [[ ${gtk_sharp_module_list} == * ${GTK_SHARP_MODULE} * ]]
; then my_module_list=${gtk_sharp_module_list}
my_tarball=gtk-sharp
elif [[ ${gnome_sharp_module_list} == * ${GTK_SHARP_MODULE} *
]] ; then
This seems like a really strange strategy for checking whether a
certain item is in a list.
I disagree.
# Make selecting components configurable.
epatch ${WORKDIR}/${MY_P}-configurable.diff
This seems like something you might want optional, depending on some
variable.
It really isn't. That patch adds AC_ARG_ENABLEs to configure so we can
split up the gnome-sharp and gnome-desktop-sharp tarballs into smaller
pieces.
# Fixes support with pkgconfig-0.17, #92503.
sed -i -e 's/\PKG_PATH\/GTK_SHARP_PKG_PATH/g' \
-e ':^CFLAGS=:d' \
${S}/configure.in
It would be nice to quote all instances of $S, $D etc.
CanDo.
LANG=C emake -j1 || die emake failed
Worth a comment about parallel make being broken, with a reference to
the upstream bug.
This is inherited from the old eclass. Upstream does not care and
there's only work enough for one make job anyway.
Attached is a diff from the old eclass to the new eclass, generated
thusly:
diff -wU5 gtk-sharp-component.eclass gtk-sharp-module.eclass
--
/PA
--- gtk-sharp-component.eclass 2008-11-25 22:05:58.0 +0100
+++ gtk-sharp-module.eclass 2008-11-26 02:06:17.0 +0100
@@ -1,192 +1,180 @@
-# Copyright 1999-2004 Gentoo Foundation
+# Copyright 1999-2008 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
-# $Header: /var/cvsroot/gentoo-x86/eclass/gtk-sharp-component.eclass,v 1.29 2008/11/25 20:44:25 loki_val Exp $
+# $Header: /var/cvsroot/gentoo-x86/eclass/gtk-sharp-module.eclass,v 1.2 2008/11/26 00:54:41 loki_val Exp $
-# Author : Peter Johanson [EMAIL PROTECTED]
+# Author : Peter Johanson [EMAIL PROTECTED], butchered by ikelos, then loki_val.
# Based off of original work in gst-plugins.eclass by [EMAIL PROTECTED]
+# Note that this breaks compatibility with the original gtk-sharp-component
+# eclass.
+
inherit eutils mono multilib autotools
-LICENSE=LGPL-2
+# Get the name of the component to build and the build dir; by default,
+# extract it from the ebuild's name.
+GTK_SHARP_MODULE=${GTK_SHARP_MODULE:=${PN/-sharp/}}
+GTK_SHARP_MODULE_DIR=${GTK_SHARP_MODULE_DIR:=${PN/-sharp/}}
+
+# In some cases the desired module cannot be configured to be built on its own.
+# This variable allows for the setting of additional configure-deps.
+GTK_SHARP_MODULE_DEPS=${GTK_SHARP_MODULE_DEPS}
+
+# Allow ebuilds to set a value for the required GtkSharp version; default to
+# ${PV}.
+GTK_SHARP_REQUIRED_VERSION=${GTK_SHARP_REQUIRED_VERSION:=${PV%.*}}
+
+# Version number used to differentiate between unversioned 1.0 series and the
+# versioned 2.0 series (2.0 series has 2 or 2.0 appended to various paths and
+# scripts). Default to ${SLOT}.
+GTK_SHARP_SLOT=${GTK_SHARP_SLOT:=${SLOT}}
+GTK_SHARP_SLOT_DEC=${GTK_SHARP_SLOT_DEC:=-${GTK_SHARP_SLOT}.0}
+
+# Set some defaults.
+DESCRIPTION=GtkSharp's ${GTK_SHARP_MODULE} module
+HOMEPAGE=http://www.mono-project.com/GtkSharp;
-HOMEPAGE=http://gtk-sharp.sourceforge.net/;
LICENSE=LGPL-2.1
-RESTRICT=test
-
-: GTK_SHARP_TARBALL_PREFIX=${GTK_SHARP_TARBALL_PREFIX:=gtk-sharp}
-
-: GTK_SHARP_REQUIRED_VERSION=${GTK_SHARP_REQUIRED_VERSION:=${PV%.*}}
-
-[ ${PV:0:1} == 2 ] \
- SOURCE_SERVER=http://www.go-mono.com/sources/gtk-sharp-2.0/;
-
-# Can be switched to [ ${PV:0:3} == 2.8 ] when 2.8.0 is out of the tree.
-[ ${PV} == 2.8.2 ] \
- SOURCE_SERVER=http://www.go-mono.com/sources/gtk-sharp-2.8/;
-
-[ ${PV%.*} == 2.10 ] || [ ${PV%.*} == 2.16 ] \
- SOURCE_SERVER=mirror://gnome/sources/${GTK_SHARP_TARBALL_PREFIX}/${PV%.*}/
-
-[ ${PV} == 1.0.10 ] \
- SOURCE_SERVER=http://www.go-mono.com/sources/gtk-sharp/;
-
-[ -z ${SOURCE_SERVER} ] \
- SOURCE_SERVER=mirror://sourceforge/gtk-sharp/
-
-###
-# variable declarations
-###
-MY_P=${GTK_SHARP_TARBALL_PREFIX}-${PV}
-
-# From gtk-sharp-1.0 series
-my_gtk_sharp_components=art gda glade gnome gnomedb gtkhtml rsvg vte
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: gtk-sharp-module.eclass
On Wednesday 26 November 2008, Ciaran McCreesh wrote: On Wed, 26 Nov 2008 09:42:07 +0100 Peter Alfredsen [EMAIL PROTECTED] wrote: This seems like a really strange strategy for checking whether a certain item is in a list. I disagree. You do? Why do you think it's better than 'has'? Did I say that? I said that I disagree that it's a really strange strategy. -- /PA signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: gtk-sharp-module.eclass
On Wednesday 26 November 2008, Donnie Berkholz wrote:
On 09:42 Wed 26 Nov , Peter Alfredsen wrote:
On Wednesday 26 November 2008, Donnie Berkholz wrote:
# Make selecting components configurable.
epatch ${WORKDIR}/${MY_P}-configurable.diff
This seems like something you might want optional, depending on
some variable.
It really isn't. That patch adds AC_ARG_ENABLEs to configure so we
can split up the gnome-sharp and gnome-desktop-sharp tarballs into
smaller pieces.
I'm thinking of what happens when you don't need the patch anymore
for a newer release but still do for an older one.
Then I add in the $PATCH_ACCEPTED_UPSTREAM var.
Or maybe you
update the patch and want to test it on ~arch revisions for a while
before hitting stable users with it.
I could add another var into the mix.
This isn't a catch-all eclass. It's designed for a very narrow group of
ebuilds which will only get smaller as I transition the packages to
eapi-2 and use depends.
--
/PA
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: gtk-sharp-module.eclass
On Thursday 27 November 2008, Duncan wrote: In that case, it may be better to do the limited code duplication, given the relative permanence of eclasses. So, what is it we're short of? Developer time or harddrive space? Is our problem that our packages start to bitrot or that we have huge number of bitrotting eclasses? Just saying. -- /PA signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: Please review: function epunt_la_files for eutils.eclass
On Friday 14 November 2008, Ryan Hill wrote: [Snip more pie-in-the-sky] Show me the code, please. If you weren't interested in hearing differing opinions, then why did you ask in the first place? :P I just thought it sounded like a tall order, saying that fixing libtool .la files would take some weekends to do, when this problem has existed for so long, yet noone has been able to fix it in a way that causes less pain than removal of all .la files does. IOW, I will believe promises of code when I see it. I won't be touching libtool. You can break that thing by just looking at it the wrong way. It'll eval your buttocks off and expr your behind, it's .3 MB of all posix-sh and it will make you regret you ever tried to wrap your head around it. [in re pulseaudio, I believed the news for 0.9.1 http://www.pulseaudio.org/wiki/OldNews] [Responding to the rest of the thread] I've given this some thought and I think I've been convinced that dberkholz' position is probably the most tenable. If this is to be done, we should do it in a documented Gentooish way. The problem with going down the FEATURES road are two-fold: 1) What should the behavior of the FEATURES flag be? I think it should act like an INSTALL_MASK=*.la and EXTRA_ECONF=--disable-static There should also be a function, let's call it exemptthis.la that would exempt a .la file from being punted, so the RESTRICT could be made on a per-la file basis. 2) Who implements in portage? [...I know nothing of portage internals...] 3) Grunt work? This should be rather easy. Just assign the bugs to me and I shall add RESTRICTs as-needed. But the problem is that we've known about this for aeons and nothing has been done about it. Diego tried to do something with popt and another package some time ago (bug 218286) but he was mostly shouted down and nobody touched it since. On .so bumps I've silently dropped .la files, which I think is the more gradualistic approach and it also has the advantage of causing only little or no (extra) breakage, but for the whole tree it could take decades, since some libs don't do .so bumps. Anyway, we really need to start punting .la files one way or the other. For desktop users of our distro, they do a lot more harm than good. For embedded, perhaps static linking serves some purpose, but really, if you can't afford dynamic linking, what are you going to run on your board? -- /PA signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Please review: function epunt_la_files for eutils.eclass
On Wednesday 12 November 2008, Mart Raudsepp wrote: I heavily object to having any such function introduced or used or equivalent .la removals conducted without a good rationale and explanation of why this is the approach taken. I see no such explanation anywhere, you are just blatantly removing .la files that the package itself installs, with no good way to ensure they aren't actually needed by libltdl and breaking revdep-rebuild heavily when used unwisely. It's a utility function. I've done all I can to ensure it'll be used wisely. Whether it is used wisely is between you and ( $ROOT or $666 ). But let me point out that in most leaf-packages, removing la files will cause no pain, but will ensure that they do not have to be rebuilt if a .la-listed dependency loses its .la file. If such a function is introduced, I'm quite sure it will get used by some maintainers in revbumps or version bumps, when the library soname has not changed at all compared to the previous version. What that means is that the user will get absolutely all packages suggested to revdep-rebuild that directly OR _indirectly_ rdepend on the library in question. Therefore to have any relatively safe way to add this, you can only add the call when the library introduced ABI breaks. Some libraries are backwards compatible forever, in effect you can't ever add epunt_la_files to those without causing some serious one-time pain for users. Therefore this is not a proper solution, and I don't see why this should be used for just a small set of packages that do have an unstable ABI while not having a solution for all the rest. Because having la files will automagically provide the equivalent amount of pain such as in http://bugs.gentoo.org/245889 . We talked about this on #gentoo-dev the other day. 200 packages out of 1000 on my system had to be rebuilt because of this. If libxcb didn't use la files, that wouldn't have been necessary for the majority of those. If the packages themselves didn't use la files, it wouldn't have been necessary either. fix_libtool_files.sh also doesn't play nice with .la files and will leave orphan .la files around. In other words, it's no a question of IF .la files will break stuff but WHEN they will break stuff. And how BIG the breakage will be. We can remedy the last part by having leaf packages not install .la files and by punting library .la files when a .so bump occurs or (as in the case of libxcb) when other .la-related breakage occurs. (Who doesn't remember The Day the Build Servers were Silenced... ) http://bugs.debian.org/354674 Additionally, I am quite unconvinced on the coverage of the removal or non-removal of the files. Not removing it on all platforms (because you can't) also doesn't solve the problem for those non-ELF platforms - you still will get all the pain you are trying to solve here on those platforms. As those platforms are still not supported by Gentoo as such, but by the Gentoo/Alt project, that is not really a problem we should be worrying about. That part of the function is a good-faith effort to not unnecessarily break stuff for Gentoo/Alt users, nothing more. If they later discover that some of their non-ELF platforms can do without .la files, they can just wiggle the code and make it so. Also, this would be a local Gentoo specific hack to reduce pain on ELF systems, while I'm sure there are upstream or better solutions available that have not been explored. Here are two different ideas of mine for libtool upstream work to perhaps solve this: [Snip good ideas] Plz2implent. Kthxbye. But you've still not given a good reason why this function in itself is bad. I do however think that it would be a good idea to tweak revdep-rebuild to not take indirect dependencies listed in .la files too seriously, and mostly just go by DT_NEEDED entries in ELF files on ELF systems instead of all of the listed ones in .la ones, as even if a solution for upstream libtool is figured out, we'd still have old installed .la files around that include indirect libraries. That would cause breakage. There's a reason why revdep-rebuild rebuilds. Libtool will look for those la files and fail the compile. -- /PA signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Please review: function epunt_la_files for eutils.eclass
On Wednesday 12 November 2008, Donnie Berkholz wrote: On 18:34 Sun 09 Nov , Peter Alfredsen wrote: I've been told that .la files are really only needed on non-ELF systems and with plugin systems that use dlopen. And for people who want to build things statically. That's true, but we generally don't want to do that, so that's fine. If needed for a package, we just don't punt la files for it and its dependencies. But generally, we should really only be building .so files and they just don't need .la files. If someone really wants .la files, we could introduce a variable: IWANTTHECRAPPYLAFILESANDIKNOWWHATIMDOING=yes to be placed in make.conf. But the great thing about having a utility function is that you can make general exceptions to the rule with tweaks like that. -- /PA signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Please review: function epunt_la_files for eutils.eclass
On Wednesday 12 November 2008, Rémi Cardona wrote: Le 12/11/2008 15:40, Peter Alfredsen a écrit : But let me point out that in most leaf-packages, removing la files will cause no pain, but will ensure that they do not have to be rebuilt if a .la-listed dependency loses its .la file. Mart, others and myself have already tried removing .la files to see what would break. And it breaks a whole lot more than we anticipated. Among others, it breaks KDE3 (all of it), pulseaudio, the current version of app-office/dia, and many more which I can't remember. That's known. So we just don't remove .la files from those. (I think pulseaudio is fixed, actually.) In a perfect world, there would be no need for .la files. But we're far from that perfect world. I think it's best we provide a better solution. The problem is that in the world where we do live, .la files are needed some places and a pain in the ass other places, so blanket solutions will not work. Mart had already proposed a static-lib USE flag. Donnie just suggested on IRC we turn this use flag into a FEATURES flag. That's problematic. You can't turn off a FEATURES flag for individual packages. See above. I think those are much better options than just using this function in some ebuilds. I think it would make sense to have a static-libs USE flag and couple it with use of epunt_la_files where it's appropriate. FEATURES flag, no. The package maintainer decides which files get installed, noone else. With a FEATURES flag, we would break the whole tree and then need to fix it up with RESTRICT=no-static-libs for every individual ebuild where it fails. Tedious and not really worth our time. By selectively doing this, we can do it intelligently and over time, minimizing the inconvenience to users. -- /PA signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Please review: function epunt_la_files for eutils.eclass
On Wednesday 12 November 2008, Mart Raudsepp wrote: On K, 2008-11-12 at 15:40 +0100, Peter Alfredsen wrote: It's a utility function. I've done all I can to ensure it'll be used wisely. Whether it is used wisely is between you and ( $ROOT or $666 ). But let me point out that in most leaf-packages, removing la files will cause no pain, but will ensure that they do not have to be rebuilt if a .la-listed dependency loses its .la file. Unless a system happens to have USE=static used for a few lower level indirect dependencies (and those very low level libraries having such an option is sometimes, albeit rarely, quite cool for embedded use cases). It just breaks then according to other subthreads, and you have no way to really check for that in your utility function. My English fails me here. To me it's not clear which cases of breakage we're speaking of here (subthreads in that context?). An example perhaps? There is still no solution for things that do not break ABI, but get rebuilt with different USE flags, for example the USE=esd fiasco where to get rid of esound you had to remove USE=esd and rebuild many packages with revdep-rebuild for no reason other than libtool being stupid. This stupidity should be fixed, not delayed with workarounds to a small subset of cases. I disagree. Just because you can have a feast tomorrow doesn't mean that you should abstain from eating today. We talked about this on #gentoo-dev the other day. 200 packages out of 1000 on my system had to be rebuilt because of this. If libxcb didn't use la files, that wouldn't have been necessary for the majority of those. If the packages themselves didn't use la files, it wouldn't have been necessary either. Or if libtool would be fixed to not cause that pain in the first place.. That would indeed be nice. Please convince me that you can implement an upstreamable solution within 2 months time and I won't be needing this function. [Snip more pie-in-the-sky] Show me the code, please. -- /PA signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Proposed change to base.eclass: EAPI-2 support
On Sunday 02 November 2008, Peter Alfredsen wrote: The attached patch for bug 238753 makes base.eclass support EAPI 2 functions. Applied -- /PA signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Please review: function epunt_la_files for eutils.eclass
I attach here a proposed new function for eutils.eclass. Review
requested. Thanks to zlin and igli for initial review and suggestions
on #gentoo-dev-help.
--
/PA
--- /usr/portage/eclass/eutils.eclass 2008-09-28 07:06:15.0 +0200
+++ eutils1.eclass 2008-11-06 22:22:51.0 +0100
@@ -1805,5 +1805,37 @@
) || die
else
newbin ${tmpwrapper} ${wrapper} || die
fi
}
+
+# @FUNCTION: epunt_la_files
+# @USAGE: [dir to scan]
+# @DESCRIPTION:
+# .la files can cause many unpleasantries when they disappear,
+# forcing rebuilds of seemingly unrelated packages.
+# This function removes the .la files from [dir to scan], ${D} if not set.
+# A good time to start punting .la files may be when a .so bump happens,
+# so dependent packages do not have to be rebuilt twice.
+#
+# See also:
+# bug 245889
+# http://blog.flameeyes.eu/2008/07/02/again-about-la-files-or-why-should-they-be-killed-off-sooner-rather-than-later
+
+epunt_la_files() {
+ debug-print-function $FUNCNAME $@
+ local TARGET=$1
+ [ -z ${TARGET} ] TARGET=${D}
+
+ # If this is a non-ELF system, chances are good that the .la files will be needed.
+ if type -P scanelf /dev/null
+ then
+ debug-print Scanelf found, proceeding...
+ ebegin Removing useless .la files
+ find ${TARGET} -name '*.la' '(' -type l -o -type f ')' -exec rm -f '{}' '+'
+ eend 0
+ else
+ debug-print scanelf not found, this appears to be a non-ELF system.
+ debug-print non-ELF systems are likely to need .la files.
+ debug-print .la files not removed from ${TARGET}
+ fi
+}
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] Please review: function epunt_la_files for eutils.eclass
On Sunday 09 November 2008, Fabian Groffen wrote:
On 09-11-2008 18:04:05 +0200, Peter Alfredsen wrote:
+ # If this is a non-ELF system, chances are good that the .la
files will be needed. + if type -P scanelf /dev/null
I think this is a not so cool way to check for an ELF system.
Indeed, I think it's a horrid way. Please find a better one.
+ then
+ debug-print Scanelf found, proceeding...
+ ebegin Removing useless .la files
+ find ${TARGET} -name '*.la' '(' -type l -o -type f ')' -exec
rm -f '{}' '+' +eend 0
+ else
+ debug-print scanelf not found, this appears to be a non-ELF
system. + debug-print non-ELF systems are likely to need .la
files. + debug-print .la files not removed from ${TARGET}
rationale?
I've been told that .la files are really only needed on non-ELF
systems and with plugin systems that use dlopen. I actually have no way
of knowing that the .la files are needed on those arches, but I had
your archs in mind when doing the patch.
--
/PA
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] Please review: function epunt_la_files for eutils.eclass
On Sunday 09 November 2008, Fabian Groffen wrote:
You could identify ELF a bit more reliable by running file on e.g.
${ROOT}/bin/bash, or just by building a list of CHOSTs that you
know are ELF systems.
D'oh, should have thought of that. See attached patch.
+ debug-print scanelf not found, this appears to be a
non-ELF
system. + debug-print non-ELF systems are likely to need
.la
files. + debug-print .la files not removed from
${TARGET}
rationale?
I've been told that .la files are really only needed on non-ELF
systems and with plugin systems that use dlopen. I actually have no
way of knowing that the .la files are needed on those arches, but I
had your archs in mind when doing the patch.
Ok. What worries me though is that this would result in some systems
having libtool files whereas the majority does not. E.g. removing
them apparently fixes a problem that then crops up on those systems
or something. Can't think of any atm.
I can. If you have .la files, you will need to revdep-rebuild a lot
more. But c'est la vie.
--
/PA
--- /usr/portage/eclass/eutils.eclass 2008-09-28 07:06:15.0 +0200
+++ eutils1.eclass 2008-11-09 18:26:44.0 +0100
@@ -1805,5 +1805,37 @@
) || die
else
newbin ${tmpwrapper} ${wrapper} || die
fi
}
+
+# @FUNCTION: epunt_la_files
+# @USAGE: [dir to scan]
+# @DESCRIPTION:
+# .la files can cause many unpleasantries when they disappear,
+# forcing rebuilds of seemingly unrelated packages.
+# This function removes the .la files from [dir to scan], ${D} if not set.
+# A good time to start punting .la files may be when a .so bump happens,
+# so dependent packages do not have to be rebuilt twice.
+#
+# See also:
+# bug 245889
+# http://blog.flameeyes.eu/2008/07/02/again-about-la-files-or-why-should-they-be-killed-off-sooner-rather-than-later
+
+epunt_la_files() {
+ debug-print-function $FUNCNAME $@
+ local TARGET=$1
+ [ -z ${TARGET} ] TARGET=${D}
+
+ # If this is a non-ELF system, chances are good that the .la files will be needed.
+ if [[ $(file ${ROOT}/bin/bash) =~ ELF ]]
+ then
+ debug-print ELF system found, proceeding...
+ ebegin Removing useless .la files
+ find ${TARGET} -name '*.la' '(' -type l -o -type f ')' -exec rm -f '{}' '+'
+ eend 0
+ else
+ debug-print This appears to be a non-ELF system.
+ debug-print non-ELF systems are likely to need .la files.
+ debug-print .la files not removed from ${TARGET}
+ fi
+}
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: Proposed change to base.eclass: EAPI-2 support
On Wednesday 05 November 2008, Thomas Sachau wrote:
You should at least use emake instead of make in src_install. And i
would suggest to use something like this instead of the make install
line (maybe add some other default docs, if they are common):
if [ -f Makefile ] || [ -f GNUmakefile ] || [ -f makefile ]; then
emake DESTDIR=${D} install || die emake install failed
fi
if [ -n ${DOCS} ]; then
dodoc ${DOCS} || die dodoc failed
else
for x in AUTHORS ChangeLog NEWS README; do
if [ -e ${x} ]; then
dodoc ${x} || die dodoc ${x} failed
fi
done
fi
I only propose changes to update the base.eclass to using EAPI-2
functions, IOW the above is outside the scope of what I propose.
Besides, using emake instead of make is not a good change to make to an
eclass unless you know for a fact that all ebuilds using the eclass
have parallel make friendly makefiles. And even then...
--
/PA
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: Proposed change to base.eclass: EAPI-2 support
On Monday 03 November 2008, Steve Long wrote:
Peter Alfredsen wrote:
debug-print-function $FUNCNAME $*
You should be using $@ not unquoted $*.
Fixed. Also fixed base_src_unpack and base_src_compile calling their
grunt functions with $1, when clearly it should have been [EMAIL PROTECTED]
Seems like the FUNCNAME bit should just be rolled into the function
with ${FUNCNAME[1]} which could be done tree-wide quite easily.
I guess that function was written before bash-3 when FUNCNAME was turned
into an array.
--
/PA
--- /usr/portage/eclass/base.eclass 2008-07-17 12:06:27.0 +0200
+++ base.eclass 2008-11-03 20:45:44.0 +0100
@@ -2,32 +2,78 @@
# Distributed under the terms of the GNU General Public License v2
# $Header: /var/cvsroot/gentoo-x86/eclass/base.eclass,v 1.34 2008/07/17 09:49:14 pva Exp $
# @ECLASS: base.eclass
# @MAINTAINER:
-# ???
+# Peter Alfredsen [EMAIL PROTECTED]
#
# Original author Dan Armak [EMAIL PROTECTED]
# @BLURB: The base eclass defines some default functions and variables.
# @DESCRIPTION:
# The base eclass defines some default functions and variables. Nearly
# everything else inherits from here.
+#
+# NOTE: You must define EAPI before inheriting from base, or the wrong functions
+# may be exported.
inherit eutils
+case ${EAPI:-0} in
+ 2)
+ EXPORT_FUNCTIONS src_unpack src_prepare src_configure src_compile src_install
+ ;;
+ *)
+ EXPORT_FUNCTIONS src_unpack src_compile src_install
+ ;;
+esac
+
DESCRIPTION=Based on the $ECLASS eclass
# @FUNCTION: base_src_unpack
# @USAGE: [ unpack ] [ patch ] [ autopatch ] [ all ]
# @DESCRIPTION:
# The base src_unpack function, which is exported. If no argument is given,
-# all is assumed.
+# all is assumed if EAPI!=2, unpack if EAPI=2.
base_src_unpack() {
- debug-print-function $FUNCNAME $*
- [ -z $1 ] base_src_unpack all
+ debug-print-function $FUNCNAME $@
+
+ if [ -z $1 ]
+ then
+ case ${EAPI:-0} in
+ 2)
+base_src_util unpack
+;;
+ *)
+base_src_util all
+;;
+ esac
+ else
+ base_src_util $@
+ fi
+}
+
+# @FUNCTION: base_src_prepare
+# @DESCRIPTION:
+# The base src_prepare function, which is exported when EAPI=2. Performs
+# base_src_util autopatch.
+base_src_prepare() {
+
+ debug-print-function $FUNCNAME $@
+
+ base_src_util autopatch
+}
+
+# @FUNCTION: base_src_util
+# @USAGE: [ unpack ] [ patch ] [ autopatch ] [ all ]
+# @DESCRIPTION:
+# The base_src_util function is the grunt function for base src_unpack
+# and base src_prepare.
+base_src_util() {
+
+ debug-print-function $FUNCNAME $@
cd ${WORKDIR}
while [ $1 ]; do
@@ -57,28 +103,62 @@
done
fi
;;
all)
debug-print-section all
- base_src_unpack unpack autopatch
+ base_src_util unpack autopatch
;;
esac
shift
done
}
+# @FUNCTION: base_src_configure
+# @DESCRIPTION:
+# The base src_prepare function, which is exported when EAPI=2. Performs
+# base_src_work configure.
+base_src_configure() {
+
+ debug-print-function $FUNCNAME $@
+
+ base_src_work configure
+}
+
# @FUNCTION: base_src_compile
# @USAGE: [ configure ] [ make ] [ all ]
# @DESCRIPTION:
# The base src_compile function, which is exported. If no argument is given,
-# all is asasumed.
+# all is assumed if EAPI!=2, make if EAPI=2.
base_src_compile() {
- debug-print-function $FUNCNAME $*
- [ -z $1 ] base_src_compile all
+ debug-print-function $FUNCNAME $@
+
+ if [ -z $1 ]
+ then
+ case ${EAPI:-0} in
+ 2)
+base_src_work make
+;;
+ *)
+base_src_work all
+;;
+ esac
+ else
+ base_src_work $@
+ fi
+}
+
+# @FUNCTION: base_src_work
+# @USAGE: [ configure ] [ make ] [ all ]
+# @DESCRIPTION:
+# The base_src_work function is the grunt function for base src_configure
+# and base src_compile.
+base_src_work() {
+
+ debug-print-function $FUNCNAME $@
cd ${S}
while [ $1 ]; do
@@ -91,11 +171,11 @@
debug-print-section make
emake || die died running emake, $FUNCNAME:make
;;
all)
debug-print-section all
- base_src_compile configure make
+ base_src_work configure make
;;
esac
shift
done
@@ -107,11 +187,11 @@
# @DESCRIPTION:
# The base src_install function, which is exported. If no argument is given,
# all is assumed.
base_src_install() {
- debug-print-function $FUNCNAME $*
+ debug-print-function $FUNCNAME $@
[ -z $1 ] base_src_install all
cd ${S}
while [ $1 ]; do
@@ -129,7 +209,5 @@
shift
done
}
-
-EXPORT_FUNCTIONS src_unpack src_compile src_install
signature.asc
Description: This is a digitally signed message part.
[gentoo-dev] Proposed change to base.eclass: EAPI-2 support
The attached patch for bug 238753 makes base.eclass support EAPI 2
functions. None of the previous functionality of exported functions is
changed, so you can still do base_src_unpack autopatch. It's only the
default actions of base_src_compile and base_src_unpack that's affected
and only if EAPI=2. The case..esac for EXPORT_FUNCTIONS is borrowed
from kde4-base. I've not done tree-rebuilds with this, so please give
it a thorough review. I'm not entirely happy about the base_src_work
and base_src_util function names, so suggestions are welcome.
--
/PA
--- /usr/portage/eclass/base.eclass 2008-07-17 12:06:27.0 +0200
+++ base.eclass 2008-11-02 22:52:10.0 +0100
@@ -2,32 +2,78 @@
# Distributed under the terms of the GNU General Public License v2
# $Header: /var/cvsroot/gentoo-x86/eclass/base.eclass,v 1.34 2008/07/17 09:49:14 pva Exp $
# @ECLASS: base.eclass
# @MAINTAINER:
-# ???
+# Peter Alfredsen [EMAIL PROTECTED]
#
# Original author Dan Armak [EMAIL PROTECTED]
# @BLURB: The base eclass defines some default functions and variables.
# @DESCRIPTION:
# The base eclass defines some default functions and variables. Nearly
# everything else inherits from here.
+#
+# NOTE: You must define EAPI before inheriting from base, or the wrong functions
+# may be exported.
inherit eutils
+case ${EAPI} in
+ 2)
+ EXPORT_FUNCTIONS src_unpack src_prepare src_configure src_compile src_install
+ ;;
+ *)
+ EXPORT_FUNCTIONS src_unpack src_compile src_install
+ ;;
+esac
+
DESCRIPTION=Based on the $ECLASS eclass
# @FUNCTION: base_src_unpack
# @USAGE: [ unpack ] [ patch ] [ autopatch ] [ all ]
# @DESCRIPTION:
# The base src_unpack function, which is exported. If no argument is given,
-# all is assumed.
+# all is assumed if EAPI!=2, unpack if EAPI=2.
base_src_unpack() {
debug-print-function $FUNCNAME $*
- [ -z $1 ] base_src_unpack all
+
+ if [ -z $1 ]
+ then
+ case ${EAPI} in
+ 2)
+base_src_util unpack
+;;
+ *)
+base_src_util all
+;;
+ esac
+ else
+ base_src_util $1
+ fi
+}
+
+# @FUNCTION: base_src_prepare
+# @DESCRIPTION:
+# The base src_prepare function, which is exported when EAPI=2. Performs
+# base_src_util autopatch.
+base_src_prepare() {
+
+ debug-print-function $FUNCNAME $*
+
+ base_src_util autopatch
+}
+
+# @FUNCTION: base_src_util
+# @USAGE: [ unpack ] [ patch ] [ autopatch ] [ all ]
+# @DESCRIPTION:
+# The base_src_util function is the grunt function for base src_unpack
+# and base src_prepare.
+base_src_util() {
+
+ debug-print-function $FUNCNAME $*
cd ${WORKDIR}
while [ $1 ]; do
@@ -57,28 +103,62 @@
done
fi
;;
all)
debug-print-section all
- base_src_unpack unpack autopatch
+ base_src_util unpack autopatch
;;
esac
shift
done
}
+# @FUNCTION: base_src_configure
+# @DESCRIPTION:
+# The base src_prepare function, which is exported when EAPI=2. Performs
+# base_src_work configure.
+base_src_configure() {
+
+ debug-print-function $FUNCNAME $*
+
+ base_src_work configure
+}
+
# @FUNCTION: base_src_compile
# @USAGE: [ configure ] [ make ] [ all ]
# @DESCRIPTION:
# The base src_compile function, which is exported. If no argument is given,
-# all is asasumed.
+# all is assumed if EAPI!=2, compile if EAPI=2.
base_src_compile() {
debug-print-function $FUNCNAME $*
- [ -z $1 ] base_src_compile all
+
+ if [ -z $1 ]
+ then
+ case ${EAPI} in
+ 2)
+base_src_work make
+;;
+ *)
+base_src_work all
+;;
+ esac
+ else
+ base_src_work $1
+ fi
+}
+
+# @FUNCTION: base_src_work
+# @USAGE: [ configure ] [ make ] [ all ]
+# @DESCRIPTION:
+# The base_src_work function is the grunt function for base src_configure
+# and base src_compile.
+base_src_work() {
+
+ debug-print-function $FUNCNAME $*
cd ${S}
while [ $1 ]; do
@@ -91,11 +171,11 @@
debug-print-section make
emake || die died running emake, $FUNCNAME:make
;;
all)
debug-print-section all
- base_src_compile configure make
+ base_src_work configure make
;;
esac
shift
done
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] Proposed change to base.eclass: EAPI-2 support
On Sunday 02 November 2008, Peter Alfredsen wrote: [...] Please just imagine that this is added to the end of the patch: - -EXPORT_FUNCTIONS src_unpack src_compile src_install /me had started hacking on this in-tree, and the first change was removing that line. -- /PA signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Proposed change to base.eclass: EAPI-2 support
On Monday 03 November 2008, Donnie Berkholz wrote:
This eclass needs to do the same thing as the other eclasses that got
EAPI=2 patches and default EAPI to 0 when it's not defined,
everywhere where it tests the value of EAPI.
Yes, that makes sense, though grepping for EAPI in eclass/ shows me that
not all chose that approach.
Updated patch attached.
--
/PA
--- /usr/portage/eclass/base.eclass 2008-07-17 12:06:27.0 +0200
+++ base.eclass 2008-11-03 06:57:10.0 +0100
@@ -2,32 +2,78 @@
# Distributed under the terms of the GNU General Public License v2
# $Header: /var/cvsroot/gentoo-x86/eclass/base.eclass,v 1.34 2008/07/17 09:49:14 pva Exp $
# @ECLASS: base.eclass
# @MAINTAINER:
-# ???
+# Peter Alfredsen [EMAIL PROTECTED]
#
# Original author Dan Armak [EMAIL PROTECTED]
# @BLURB: The base eclass defines some default functions and variables.
# @DESCRIPTION:
# The base eclass defines some default functions and variables. Nearly
# everything else inherits from here.
+#
+# NOTE: You must define EAPI before inheriting from base, or the wrong functions
+# may be exported.
inherit eutils
+case ${EAPI:-0} in
+ 2)
+ EXPORT_FUNCTIONS src_unpack src_prepare src_configure src_compile src_install
+ ;;
+ *)
+ EXPORT_FUNCTIONS src_unpack src_compile src_install
+ ;;
+esac
+
DESCRIPTION=Based on the $ECLASS eclass
# @FUNCTION: base_src_unpack
# @USAGE: [ unpack ] [ patch ] [ autopatch ] [ all ]
# @DESCRIPTION:
# The base src_unpack function, which is exported. If no argument is given,
-# all is assumed.
+# all is assumed if EAPI!=2, unpack if EAPI=2.
base_src_unpack() {
debug-print-function $FUNCNAME $*
- [ -z $1 ] base_src_unpack all
+
+ if [ -z $1 ]
+ then
+ case ${EAPI:-0} in
+ 2)
+base_src_util unpack
+;;
+ *)
+base_src_util all
+;;
+ esac
+ else
+ base_src_util $1
+ fi
+}
+
+# @FUNCTION: base_src_prepare
+# @DESCRIPTION:
+# The base src_prepare function, which is exported when EAPI=2. Performs
+# base_src_util autopatch.
+base_src_prepare() {
+
+ debug-print-function $FUNCNAME $*
+
+ base_src_util autopatch
+}
+
+# @FUNCTION: base_src_util
+# @USAGE: [ unpack ] [ patch ] [ autopatch ] [ all ]
+# @DESCRIPTION:
+# The base_src_util function is the grunt function for base src_unpack
+# and base src_prepare.
+base_src_util() {
+
+ debug-print-function $FUNCNAME $*
cd ${WORKDIR}
while [ $1 ]; do
@@ -57,28 +103,62 @@
done
fi
;;
all)
debug-print-section all
- base_src_unpack unpack autopatch
+ base_src_util unpack autopatch
;;
esac
shift
done
}
+# @FUNCTION: base_src_configure
+# @DESCRIPTION:
+# The base src_prepare function, which is exported when EAPI=2. Performs
+# base_src_work configure.
+base_src_configure() {
+
+ debug-print-function $FUNCNAME $*
+
+ base_src_work configure
+}
+
# @FUNCTION: base_src_compile
# @USAGE: [ configure ] [ make ] [ all ]
# @DESCRIPTION:
# The base src_compile function, which is exported. If no argument is given,
-# all is asasumed.
+# all is assumed if EAPI!=2, make if EAPI=2.
base_src_compile() {
debug-print-function $FUNCNAME $*
- [ -z $1 ] base_src_compile all
+
+ if [ -z $1 ]
+ then
+ case ${EAPI:-0} in
+ 2)
+base_src_work make
+;;
+ *)
+base_src_work all
+;;
+ esac
+ else
+ base_src_work $1
+ fi
+}
+
+# @FUNCTION: base_src_work
+# @USAGE: [ configure ] [ make ] [ all ]
+# @DESCRIPTION:
+# The base_src_work function is the grunt function for base src_configure
+# and base src_compile.
+base_src_work() {
+
+ debug-print-function $FUNCNAME $*
cd ${S}
while [ $1 ]; do
@@ -91,11 +171,11 @@
debug-print-section make
emake || die died running emake, $FUNCNAME:make
;;
all)
debug-print-section all
- base_src_compile configure make
+ base_src_work configure make
;;
esac
shift
done
@@ -129,7 +209,5 @@
shift
done
}
-
-EXPORT_FUNCTIONS src_unpack src_compile src_install
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] Stabilization of poppler-0.8
On Thursday 28 August 2008, Petteri Räty wrote: [poppler-0.8 stabilization] Is 0.8 needed by something? We could also wait for Portage-2.2 and preserved-libs. It's all-round better than 0.6.3, which is from December 2007. epdfviewer, evince and a bunch of other stuff uses it to render pdfs and a bunch of rendering bugs have been fixed since then. So, it's not needed, but it would be a major improvement. And it's ripe for stabilization. -- /PA signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Stabilization of poppler-0.8
Hi, It won't be long before I ask for poppler-0.8 and -bindings to be stabilized. This will bump the soname for poppler and force a rebuild of all packages depending on it. I've opened a tracker bug at http://bugs.gentoo.org/235897 where you can add a comment or place a blocker bug if you want your app which depends on poppler to go stable with it, so we won't force people to rebuild the same packages twice. -- /PA signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-nds/openldap: openldap-2.4.7.ebuild openldap-2.4.10.ebuild openldap-2.3.41.ebuild
On Sunday 20 July 2008, Robin H. Johnson wrote: On Sun, Jul 20, 2008 at 10:19:10AM +, Peter Alfredsen (loki_val) wrote: loki_val08/07/20 10:19:10 Modified: openldap-2.4.7.ebuild openldap-2.4.10.ebuild openldap-2.3.41.ebuild Log: Propagate fix for glibc-2.8 to more versions, including masked ones. (Portage version: 2.2_rc1/cvs/Linux 2.6.25.8 i686) Why didn't you touch ChangeLog? Please remember to do so in future? Because the commit just did what the latest entry in the changelog said I would do. I of course now, having done it, realize that it won't state which files I changed. Mea maxima culpa. Sincerely, Peter Alfredsen signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Assigning bugs back to bug-wranglers@
On Monday 30 June 2008, Michael Hammer wrote: * Jeremy Olexa [EMAIL PROTECTED] [080630 19:53]: [...] IMO, b-w'ing is something that anyone can do. s/can/should ? I mean bug wrangling is a very important thing especially in the sight of users. I'm really willing to help on b-w'ing if it makes sense and is possible. It always makes sense, especially when both carlo and jer are away. The back log can become long at times. Your best friend is a couple of bugs.gentoo.org tabs open (for searching) and an IRC client with a chat window with jeeves or wilikins on freenode. -- /PA signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] profile shift for arm/s390/sh from stable to dev
On Saturday 31 May 2008, Mike Frysinger wrote: On Saturday 31 May 2008, Mike Frysinger wrote: ive made this shift in profiles.desc: sed -ir '/^(arm|s390|sh)/s:stable:dev:' profiles.desc if/when we get dedicated arch maintainers, they can think about shifting back for the confused ... you should still be adding these arches for stable requests and you should not be dropping their keywords -mike Just for the extra dense among us, does this mean that when a security bug such as 216850[1] gets closed with no response from those arches, that in such cases we are allowed punt the affected ebuild, even though it will break your stable? [1] http://bugs.gentoo.org/216850 -- /PA signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] gcc-4.2 / gcc-4.3 plans
On Thursday 10 April 2008, Mike Frysinger wrote: Also, you'll have to provide a URL to said change. i havent seen a patch for it in my random driftings on the interweb. -mike I was just researching the issue, so had this handy: http://gcc.gnu.org/ml/gcc-patches/2008-03/msg00417.html -- /PA -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-p2p/btg: btg-0.9.6.ebuild Manifest metadata.xml ChangeLog
On Monday 15 October 2007, Donnie Berkholz wrote: einfo einfo Compile dev-libs/boost with USE=threads or USE=threads-only einfo if you want threading support for btg einfo Shouldn't that be threadsonly ? -- /PA -- [EMAIL PROTECTED] mailing list
