On Tuesday 03 March 2009 12:13:34 Peter Volkov wrote:
> > > > Could you just use dosed here?
> >
> > dosed needs to die.
>
> Why?
Because it's utterly pointless and exists only for legacy reasons. Few
packages use it anyway.
--
Bo Andresen
On Monday 02 March 2009 08:24:35 Torsten Veller wrote:
> > > find "${D}/${VENDOR_LIB}" -type f -a \( -name .packlist \
> > > -o \( -name '*.bs' -a -empty \) \) -delete
> > > find "${D}/${VENDOR_LIB}" -depth -mindepth 1 -type d -empty -delete
> >
> > I'm curious how portable the find (
On Thursday 16 October 2008 23:54:32 Donnie Berkholz wrote:
> I'm not sure whether this would work, but one idea would be to handle
> dependencies depending on what's in IUSE of the ebuild inheriting.
That would require ebuilds to set IUSE before inheriting the eclass.
--
Bo Andresen
signature
> --- gentoo-x86/eclass/fox.eclass 2008-10-12 14:31:36.0 +0200
> +++ fox-proposed.eclass 2008-10-13 20:27:05.0 +0200
> [...]
> -inherit eutils libtool versionator
>
> +inherit autotools eutils libtool versionator
You should probably be setting WANT_AUTO* before inheriti
On Monday 13 October 2008 04:43:48 Steve Long wrote:
> EBZR_OPTIONS="${EBZR_OPTIONS:-}" (and similar variants)
> doesn't do anything (beyond waste lex and yacc time.)
It gets listed in the generated man page.
[...]
> The same consideration applies to all those "constant values" 'and indeed'
> ${f
On Monday 29 September 2008 10:27:51 Alexis Ballier wrote:
> Maybe it would be worth adding repoman warnings/errors for econf calls in
> eapi2 src_compile.
Or make econf warn when run outside src_configure/src_compile depending upon
EAPI.
--
Bo Andresen
signature.asc
Description: This is a d
On Monday 29 September 2008 01:37:03 Zac Medico wrote:
> > Why the need for multiple solutions at all? PROPERTIES=set is too weird
> > and involves too much nonsensical behaviour to be useful.
>
> I don't see the PROPERTIES=set approach as being worse than any
> other approach for package set defin
On Wednesday 24 September 2008 07:28:07 Alec Warner wrote:
> > Now figure out the four flaws in the above code.
>
> Why not be helpful and point them out?
>
> I would call your comment 'UnGentooey', if I may use a work term. I
> don't think saying there are flaws in a given piece of code is really
On Tuesday 23 September 2008 21:39:52 Thomas Sachau wrote:
> default_src_install() {
> if [ -f Makefile -o -f GNUmakefile -o -f makefile ]; then
> if emake DESTDIR="${D} install || einstall ; then
> die "install failed"
> else
>
On Tuesday 23 September 2008 22:44:35 Alexis Ballier wrote:
> > > False. If for instance coolfeature was made optional in >=pv you
> > > can use logic like:
> > >
> > > if has_version '>=cat/foo-pv' && ! has_version
> > > 'cat/foo[coolfeature]'; then ewarn '...'
> > > fi
> >
> > I think this should
On Monday 22 September 2008 22:25:20 Petteri Räty wrote:
> > If you mean something like
> >
> > built_with_use cat/foo coolfeature || ewarn "bar will be more useful if
> > you rebuild cat/foo with USE=coolfeature"
> >
> > then you can use
> >
> > has_version 'cat/foo[coolfeature]' || ...
On Thursday 11 September 2008 17:42:25 Zac Medico wrote:
> Ebuilds that used this approach were easily fixed by moving the has_version
> calls to pkg_preinst and storing the results in environment variables.
Which breaks with any portage old enough to not properly support storing
environment var
On Friday 05 September 2008 00:58:05 Zac Medico wrote:
> * Default phase function implementations for older EAPIs are
> accessible via functions having names that start with 'eapi',
> followed by the EAPI value.
Based on the lack of use cases or further responses to [1] I would suggest
remo
My retirement is probably long overdue as I haven't really been active for
several months. It is now clear to me that Gentoo is not moving in the
direction I had wished for and the last council election indicates that most
current Gentoo developers appear to be satisfied with this current direct
On Thursday 03 July 2008 01:06:17 Diego 'Flameeyes' Pettenò wrote:
> -r1 has this values:
>
> P=quassel-
> PN=quassel
> PV=
> PF=quassel--r1
> PVR=-r1 (was this the right variable name? I sincerely forgot)
PVR is right. You only forgot PR=r1.
http://devmanual.gentoo.org/ebuild
On Saturday 28 June 2008 17:03:13 Marijn Schouten (hkBst) wrote:
> PV=${PV/0./}
>
> to that new ebuild. This is the cleanest way to do it and doesn't require
> any variable name changes or any other changes to the ebuild regardless of
> what it does. Unfortunately it is also illegal per current PMS
On Wednesday 11 June 2008 01:03:47 Marius Mauch wrote:
> > I would like the portage devs to comment upon which of the following
> > features they think could easily be implemented before portage 2.2
> > goes stable. There's still some time since it hasn't left
> > package.mask yet, so I'd rather th
On Tuesday 10 June 2008 18:26:55 Doug Goldstein wrote:
> Let's try to aim to do an EAPI=2 sometime soonish since Portage now has
> USE flag depends in version 2.2 which is looming on the horizon. It'd be
> nice to hit the ground running with supporting these. I know it'll be
> trivial for the Palud
On Thursday 05 June 2008 02:00:21 Łukasz Damentko wrote:
> Nominations for the Gentoo Council 2008/2009 are open now and will be
> open for the next two weeks (until 23:59 UTC, 18/06/2008).
I would like to nominate Piotr Jaroszyński (peper).
--
Bo Andresen
signature.asc
Description: This is a
On Thursday 05 June 2008 20:26:03 Alex Howells wrote:
> 2008/6/5 Ali Polatel <[EMAIL PROTECTED]>:
> > I want to nominate:
> >
> > Fernando J. Pereda -- "ferdy"
> > Bo Ørsted Andresen -- "zlin"
I accept.
> Is there a method for objecting to
On Saturday 24 May 2008 00:01:20 Arun Raghavan wrote:
> http://gitorious.org/projects/g-py-split/repos/mainline/blobs/g-py-split/eclass/gnome-python-common.eclass
Comments to quoted parts of the eclass below...
> G_PY_BINDINGS=${G_PY_BINDINGS:-${PN%-*}}
From the comments above it I get the impre
On Wednesday 16 April 2008 10:15:16 Mateusz A. Mierzwiński wrote:
> So why not to send on screen info about what to do rather then "ERROR"?
Please reread this entire thread. That's exactly what is being proposed.
[...]
> I think this is good idea.
I think this is a terrible idea.
--
Bo Andres
On Wednesday 16 April 2008 09:56:04 Mateusz A. Mierzwiński wrote:
> My Prof from US used to say - if something is working good why we should
> replace it? When we do that we can be "sent to the tree with bananas
> straighting proposition" by OS.
I think it has been made quite clear in this thread
On Monday 31 March 2008 02:29:10 Brian Harring wrote:
> Going to reiterate this one more time; the proposal is simple enough;
> if it's an implicit 0 via cpv parsing, it should *not* be explicitly
> specified on disk. 'diffball-1.0_alpha0.ebuild' can just as easily be
> specified as 'diffball-1.0_
On Thursday 03 April 2008 14:55:43 Patrick Lauer wrote:
> >> But if you don't trust anyone there is no reason why you would even
> >> try to interact with Gentoo. So at some point you will have to decide
> >> to arbitrarily trust a few entities, be it devs or servers or
> >> cryptographic keys ...
On Tuesday 18 March 2008 00:42:02 Gilles Dartiguelongue wrote:
> > Now, basically, if the portage metadata or QA people could tell me a way
> > to figure *all* the ebuilds that inherit gnome2 *and* have a
> > pkg_preinst() function somewhere (either in the ebuild or in an eclass
> > somewhere) I'd
On Friday 14 March 2008 18:16:15 Fabio Erculiani wrote:
> Then, we'll see how long it will stay open, just one evidence here:
> http://bugs.gentoo.org/show_bug.cgi?id=125728 :)
Uhh.. We can do better than that...
http://bugs.gentoo.org/show_bug.cgi?id=1343
Seriously though.. if someone had a pro
On Friday 14 March 2008 03:29:26 Petteri Räty wrote:
> solar reported that he had ebuild submissions blindly using EAPI=1 so we
> hopefully made the text better reflect that it should not be used unless
> absolutely needed.
'Absolutely' is far too strong a word. A better wording would be 'unless
On Thursday 13 March 2008 14:34:50 Natanael Copa wrote:
> On Thu, 2008-03-13 at 00:35 +0100, Fabio Erculiani wrote:
> > I offer my help to fix DEPEND/RDEPEND split issues which is causing me
> > a lot of headaches (along with localizations).
> > For reference, please have a look here:
> > http://pl
On Saturday 16 February 2008 00:40:31 Doug Klima wrote:
> > For quite a while the KDE herd has had a modified version of
> > subversion.eclass in the kde overlay. During that time we have added the
> > following features to the eclass which we would like to put back in
> > gentoo-x86 soon. Since th
For quite a while the KDE herd has had a modified version of subversion.eclass
in the kde overlay. During that time we have added the following features to
the eclass which we would like to put back in gentoo-x86 soon. Since the
changes are fairly extensive we decided to send it to this list for
On Wednesday 13 February 2008 20:30:30 Petteri Räty wrote:
> > How can I use PATCHES without quoting issues?
>
> Attached is a patch that fixes this.
So is someone going to fix epatch too? Otherwise it is rather moot.
--
Bo Andresen
signature.asc
Description: This is a digitally signed messag
On Thursday 20 December 2007 20:01:55 Zhang Le wrote:
> IMO, we can not have more than two EAPI's simultaneously.
That defeats the whole purpose of having EAPIs. Which is to keep a sane
upgrade path...
--
Bo Andresen
signature.asc
Description: This is a digitally signed message part.
On Friday 21 December 2007 05:46:35 Josh Saddler wrote:
> Who cares? Gentoo uses the ebuild/bash-with-shebang format. If you're
> trying to shove in something outside of that, that would be a package
> manager-specific format. Like XML-stuff (that can't include the shebang
> or EAPI="foo" at the to
On Friday 21 December 2007 03:41:04 Luca Barbato wrote:
> > * We have to wait a year before we can use it.
>
> We have to wait till we got a new release and I hope it isn't 12months.
And then we have to wait till noone use a version of portage that sources the
ebuild to get the EAPI. Unless we ch
On Thursday 20 December 2007 22:33:25 Joe Peterson wrote:
> Technical reasons to avoid the filename are:
>
> 2) Having the same info in more than one place is bad (requiring extra
> repoman checks and the potential for ambiguity).
As opposed to adding checks to make sure that obtaining the EAPI fr
On Thursday 20 December 2007 17:14:52 Thomas Pani wrote:
> > Are we Debian now? A new feature gets implemented (obviously because we
> > *need* it) and we can make use of it in a *year*?
>
> No, we're not Debian, thank god. I thought the "wait 1+ year" policy
> changed? Again citing Ciaran: "That w
On Friday 21 December 2007 05:25:00 Zhang Le wrote:
> The question is really simple.
> Whether we should have two different place to define EAPI?
We need two places because it wasn't implemented properly in the first place
and we want to retain backwards compatibility for people who use old versi
On Thursday 20 December 2007 13:48:31 Steve Long wrote:
> >> (optimising early here seems silly tbh, given that paludis now
> >> requires ruby.)
> >
> > Eh? Now what're you on about?
>
> http://bugs.gentoo.org/show_bug.cgi?id=198864
So here you're showing that you don't know what a USE flag is?
-
On Thursday 20 December 2007 11:09:44 Donnie Berkholz wrote:
> > > Looking at my kernel config, ext3 and reiser explicitly support
> > > xattrs, and I see jfs and xfs have acls and security labels, which
> > > might be usable.
[...]
> The idea of the sqlite-based fallback is what's interesting here
On Tuesday 18 December 2007 01:36:51 Thomas de Grenier de Latour wrote:
> Why can't it be in the file but readable without sourcing? For instance,
> it could be mandatory that EAPI=X, if present, must be the first
> non-blank and non-comment line of the ebuild (and it would then be
> checked after
On Monday 17 December 2007 00:48:12 Duncan wrote:
> > I think it's valuable to show the flags that actually need to be changed
> > rather than a full list of all required flags.
>
> ++
>
> I had a USE blocker give me a list, recently, and it was mildly
> irritating to have to sort out which of the
On Sunday 16 December 2007 08:13:49 Donnie Berkholz wrote:
> On 17:46 Fri 14 Dec , Greg Kroah-Hartman (gregkh) wrote:
> > pkg_setup() {
> > einfo "Checking mplayer for USE flags we need..."
> > for f in "encode dvd x264 mp3"; do
> > if ! built_with_use media-video/mplayer $f
On Sunday 16 December 2007 08:03:37 Donnie Berkholz wrote:
> > chmod 755 "${S}/configure"
>
> fperms means you don't need S or quotes.
fperms works on D. Not S.
--
Bo Andresen
signature.asc
Description: This is a digitally signed message part.
On Wednesday 14 November 2007 21:37:46 Jan Kundrát wrote:
> Bo Ørsted Andresen wrote:
> > So on estonian locales those letters won't be included in [a-z] but
> > they will be included in [:alpha:].
>
> Actually that was exactly my point. If user had some funny locale th
On Wednesday 14 November 2007 01:33:54 Jan Kundrát wrote:
> Steve Long wrote:
> >> Is [[:alpha:]] locale-safe?
> >
> > Yes, all POSIX character classes listed here are:
> > http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap07.html
>
> Thanks for a nice link. If I read section 7.3.1 cor
On Sat, Nov 10, 2007 at 11:51:37AM +0100, Krzysiek Pawlik wrote:
> It's purpose is to remove the ${D} from makefile, additionally ${D} is in
> single
> quotes, so it will not be expanded - is it a bug in repoman check?
What ${D} ? I see none in that makefile. Which is why I think a patch would be
On Friday 02 November 2007 17:52:13 Roy Marples wrote:
> On Fri, 2007-11-02 at 17:30 +0100, Bo Ørsted Andresen wrote:
> > Please explain why you hijack this thread to discuss POSIX vs. bash when
> > it's supposed to be about the API for ebuilds.
>
> I dislike the gratuito
On Friday 02 November 2007 17:10:29 Roy Marples wrote:
> > and the answer is still the same. POSIX conversions are irrelevant until
> > you can propose solutions for the things bash can do but POSIX cannot.
> > you can only provide workarounds or hacks, so any further attempt on the
> > topic is
On Monday 15 October 2007 09:42:50 Donnie Berkholz wrote:
> On 07:40 Mon 15 Oct , Christian Faulhammer (opfer) wrote:
> > 1.1 app-misc/note/note-1.3.3.ebuild
> >
> > file :
> > http://sources.gentoo.org/viewcvs.py/gentoo-x86/app-misc/note/note-1.3.3.ebuild?rev=1.1&view=markup
On Sunday 14 October 2007 10:39:53 Donnie Berkholz wrote:
> On 14:25 Sat 13 Oct , Stefaan De Roeck (stefaan) wrote:
> > 1.1 net-fs/openafs/openafs-1.4.5_pre1.ebuild
> >
> > file :
> > http://sources.gentoo.org/viewcvs.py/gentoo-x86/net-fs/openafs/openafs-1.4.5_pre1.ebuild?rev=
On Monday 08 October 2007 06:47:05 Donnie Berkholz wrote:
> > src_unpack() {
[SNIP]
> Shouldn't this respect ROOT != / ? I can see how that would be a bit of
> an unusual use case for games, though.
Use of $ROOT in src_* would be illegal (which is why there a bunch of bug
reports with "abusing RO
On Friday 05 October 2007 04:26:50 Marius Mauch wrote:
> Problem is that nobody feels responsible for eselect anymore, so nobody
> takes care of bug #179064 (and I'm not going to play catchup games
> with externally hosted code).
eselect isn't externally hosted. The code is available from svn at:
On Friday 05 October 2007 01:14:32 Marius Mauch wrote:
> (btw, the /etc/portage/env trick only works because the default src_test in
> ebuild.sh has the otherwise redundant FEATURES check which was discussed a
> few days ago in one of the commit reviews)
src_test() is not called in dyn_test() unle
On Tuesday 25 September 2007 12:47:35 Marijn Schouten (hkBst) wrote:
> > > # "make test" does something weird so default src_test() in
> > > /usr/lib/portage/bin/ebuild.sh fails the following test
> > > # elif emake -j1 test -n &> /dev/null; then
> > > # so copy straight from default src_test() al
On Monday 24 September 2007 21:53:14 Donnie Berkholz wrote:
> > - use video_cards_mga || myconf="${myconf} --disable-mga"
> > - ( use X && use video_cards_mga ) || myconf="${myconf} --disable-xmga"
> > + use video_cards_mga && myconf="${myconf} --enable-mga"
> > + ( use X && use video_cards
On Monday 24 September 2007 21:56:49 Donnie Berkholz wrote:
> > if [[ "$(gcc-major-version)" -gt "3" ]] || \
> >( [[ "$(gcc-major-version)" -eq "3" ]] && [[ "$(gcc-minor-version)"
> > -gt "3" ]] )
>
> Code block { } might be good here instead of a subshell, or perhaps it
> could use lo
On Thursday 20 September 2007 19:54:16 Donnie Berkholz wrote:
> > econf has default "econf failed" die message.
> > The following would be sufficient:
> > econf \
> > --localstatedir=/var \
> > --sysconfdir=/etc/csync2
>
> Is that so ... when did that appear? Does
On Tuesday 18 September 2007 01:33:33 Mike Frysinger wrote:
> ive been sending private e-mails as i didnt want to make a lot of noise,
> but many of the comments i make i imagine would be applicable to a lot of
> people ... i also see others doing reviews and such
>
> how do people feel about respo
On Thursday 10 May 2007 19:38:13 Thilo Bangert wrote:
> /me goes back to reading up on some history:
missing metadata.xml - 2006-11-22
http://thread.gmane.org/gmane.linux.gentoo.devel/44407
--
Bo Andresen
signature.asc
Description: This is a digitally signed message part.
On Friday 12 January 2007 05:43, Richard Fish wrote:
> My idea would be to extend emaint to check package.keywords and
> package.use for obsolete flags, unnecessary atoms (like foo-1.2 in
> keywords when foo-1.3 is stable), atoms that don't match any current
> ebuild, and so on.
app-portage/eix al
On Thursday 21 December 2006 15:32, Alexander Zubkov wrote:
> I have some idea on extending portage building system (ebuild?).
> Sometimes I'm (for example) want to apply custom patch to some package.
> This patch can do something unusual, that can not be accepted by
> maintainers and I know this.
On Wednesday 29 November 2006 18:11, Stuart Herbert wrote:
> > Except it was announced before we even made the snapshot,
>
> Sorry, I've looked, but the only announcement I found on gentoo-dev
> was posted two days before gcc-4.1 was stabilised [1]. I must have
> missed the earlier announcement?
On Wednesday 29 November 2006 09:37, Stuart Herbert wrote:
> > Gcc 4.1.1 wasn't a last minute change.
>
> I can't agree with you there. It doesn't matter how many months of
> planning and work you guys put into getting gcc-4.1 fit for stable.
> If you're doing it off in your own little corner of t
On Monday 21 August 2006 14:59, Abhay Kedia wrote:
> I use alsaplayer to play KDE sounds as it works well with dmix and I
> can keep aRts disabled. All KDE sounds are ogg files and when I play
> them with mpg321, it just exits without producing any sound. I guess
> the only thing left for me to use
On Wednesday 28 June 2006 16:28, Mivz wrote:
> How free is free software if you need a lawyer and a expensive server
> just to be able to publish your addition under your own name?
There is nothing preventing you from just publishing a patch with your name.
The problem arises only if you distribu
On Wednesday 14 June 2006 18:40, Alec Warner wrote:
> There is no comparison, use.defaults IS the file. Look at it.
>
[SNIP]
>
> and so on. If package is installed, the corresponding flag is turned on
> "automatically" hence autouse. This no longer occurs in 2.1.
Ah, now I get it. I didn't real
On Wednesday 14 June 2006 14:42, Alec Warner wrote:
> * autouse (use.defaults) has been deprecated by specifying USE_ORDER in
> make.defaults. Users may still turn this back on by specifying
> USE_ORDER="env:pkg:conf:auto:defaults" in make.conf. Interested in
> figuring out what use flags were tu
On Monday 12 June 2006 12:57, Bo Ørsted Andresen wrote:
> On Monday 12 June 2006 12:42, Peter wrote:
> > All of a sudden, emerge -uD --newuse world is showing dozens of ebuild
> > that are replaced due to removed use flags. Did someone change the
> > default use flags?
On Monday 12 June 2006 12:42, Peter wrote:
> All of a sudden, emerge -uD --newuse world is showing dozens of ebuild
> that are replaced due to removed use flags. Did someone change the default
> use flags? Upgraded yesterday to portage 2.1.
Look at the first section of [1]. Just so you know it thi
70 matches
Mail list logo
