Wulf C. Krueger wrote:
> For quite some time now, our progress has been impaired by the absence of
> features like USE dependencies, ranged dependencies and suggested
> dependencies.
>
How do suggested dependencies help in your work?
> Most of us who are working on the overlay have been using alt
Something that's been discussed on IRC is the idea of a .pbuild file,
written in Python. I can also think of .cbuild (C) .Cbuild (C++) .sbuild
(Scheme) .hbuild (Haskell) and .jbuild (guess;) as being of immediate use,
(although I accept I might be the only one interested in the first ;)
The basic
Rémi Cardona wrote:
> What would be the point of such a change? What problem are you trying to
> solve or to improve?
>
First and foremost to give an environment wherein people can write their
installation scripts using the language they are most comfortable with.
Secondly efficiency; in the case
Luca Barbato wrote:
> Steve Long wrote:
>> Something that's been discussed on IRC is the idea of a .pbuild file,
>> written in Python. I can also think of .cbuild (C) .Cbuild (C++) .sbuild
>> (Scheme) .hbuild (Haskell) and .jbuild (guess;) as being of immediate
>>
Rémi Cardona wrote:
> Steve Long a écrit :
>> First and foremost to give an environment wherein people can write their
>> installation scripts using the language they are most comfortable with.
>
> If bash is not "easy" or straightforward enough for what you are tr
Rémi Cardona 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 really appreciate it, as I really don't want to re
Petteri Räty wrote:
> Steve Long kirjoitti:
>>>
>> I don't see how it would wreak more havoc than a novice using, eg ANT
>> from Java which s/he is comfortable with, and then further having to
>> learn BASH peculiarities when things don't fit with the eclas
Brian Harring wrote:
> On Thu, Mar 20, 2008 at 06:51:13AM +0000, Steve Long wrote:
>> I don't have figures, but my understanding is that one of the major
>> factors in pkgcore's speed (which *is* impressive, even if the UI isn't
>> quite there yet) is that it
Jeroen Roovers wrote:
> On Sun, 20 Apr 2008 18:06:07 +0200
> Tiziano Müller <[EMAIL PROTECTED]> wrote:
>
>> I'd say we should convert it to a global use flag now with a good
>> description and change it to gnome-keyring later in case we really
>> have a package which needs 'keyring' for something
Ciaran McCreesh wrote:
> Nor do most Unix apps, since they tend to be written in C using all
> those C library functions that work on null terminated strings.
>
> Null introduces far more problems than it solves, character-wise...
>
..but it's fine as a terminator, if you know what you're doing.
Jeroen Roovers wrote:
> On Mon, 21 Apr 2008 15:02:29 +0100
> Steve Long <[EMAIL PROTECTED]> wrote:
>
>> Sorry to get technical but how difficult is it really to change USE
>> flag names? I appreciate that users are out of sync yadda yadda, but
>> could this kind
Ciaran McCreesh wrote:
> On Sat, 19 Apr 2008 18:38:06 +0200
> "Marijn Schouten (hkBst)" <[EMAIL PROTECTED]> wrote:
>> I don't know what the general use of pkg_preinst is, but in
>> pkg_postinst the package itself should be runnable, so its RDEPENDS
>> should be installed and usable at this point.
Petteri Räty wrote:
> Wulf C. Krueger kirjoitti:
>> How to gain power the easy way and obsolete conflict resolution in just
>> one commit:
>>
>>
http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/proj/en/devrel/policy.xml?r1=1.18&r2=1.19
>>
>
> Please use the appropriate mailing list. Nothi
Denis Dupeyron wrote:
> Please everybody, give a very warm welcome to bunder.
>
Yay bunder! Well done, man. :-)
--
gentoo-dev@lists.gentoo.org mailing list
Ciaran McCreesh wrote:
> On Sun, 27 Apr 2008 10:41:57 +0100
> Steve Long <[EMAIL PROTECTED]> wrote:
>> Use PDEPEND.
>
> PDEPEND has a different meaning, and isn't suitable for runtime
> dependencies.
>
"PDEPEND should be avoided in favour of RDEPEN
Matthias Schwarzott wrote:
> Code may look like this:
>
> # get last one of sorted list
> for t in $(ls -1 /usr/bin/gcc-3*|sort); do
use teh globs, luke ;)
for t in /usr/bin/gcc-3*; do # will already do this, sorting according to
LC_COLLATE order (set to C or POSIX [same thing] for ebuild.) There'
Zac Medico wrote:
> It's currently possible for ebuilds to call the insopts, diropts,
> exeopts, and libopts functions to modify these variables. If they
> add the -p option, then timestamps will be preserved. I suppose we
> can add -p to the default options if that's what everybody wants.
>
Gets
Mark Loeser wrote:
> Making an actual bug wrangling team (subproject of QA) is something
> I've been toying around with in my head. I'd love to get an actual team
> set up so we can encourage users to help us get the information we need
> in bugs so it is less work for us. Several other distribut
Matthias Schwarzott wrote:
> Well, you want it compact, without loops.
> Here is it:
>
> set -- /usr/bin/gcc-3*
> Get first entry: CC="$1"
> Get last entry: eval CC="\${$#}"
>
Nice one, yeah I thought : splitting was posix silly me ;)
I still shy clear of eval for general use and you have to go t
Diego 'Flameeyes' Pettenò wrote:
> Donnie Berkholz <[EMAIL PROTECTED]> writes:
>
>> Would it be possible to add the tree categories as products and the
>> packages as components thereof?
>
> It makes moving a bug from one package to another quite a complex task
> though, as it requires two confi
server -- never did get a rational explanation of what it breaks. and now
USE defaults work there's simply no excuse imo.
I note openldap in 2008.0 profile uses minimal which has *always* been
acknowledged as the wrong way to build a client installation, despite its
long-standing use in mysql.
--
Diego 'Flameeyes' Pettenò wrote:
> Steve Long <[EMAIL PROTECTED]> writes:
>
>>> It makes moving a bug from one package to another quite a complex task
>>> though, as it requires two confirmation screens... and trust me that
>>> happens often e
Zac Medico wrote:
> As a substitute for the previously discussed RESTRICT=live value[1],
> I'd now like you to consider an equivalent PROPERTIES=live-sources
> setting. By specifying PROPERTIES=live-sources, an ebuild will be
> able to indicate that it uses src_unpack() to download sources from
>
Zac Medico wrote:
> Given the vast number of possible choices to consider when defining
> new PROPERTIES values [1], perhaps we should create a ballot and
> hold a vote on definitions that people have submitted. I suppose
> that voters would be able to vote yes or no on each proposed
> property de
Bo Ørsted Andresen wrote:
> 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 sa
Zac Medico wrote:
> Ciaran McCreesh wrote:
>> On Tue, 05 Aug 2008 22:15:11 -0700
>> Zac Medico <[EMAIL PROTECTED]> wrote:
>>> Does this seem like a desirable way to represent the "virtual"
>>> attribute? Any suggestions?
>>
>> Again, I'm not so sure that this doesn't represent multiple separable
Andrew D Kirch wrote:
> Here's the script that I used to generate this.
Just some bash hints. In a nutshell: please don't use ls in scripts.
> I have not manually
> reviewed all of thousands of patches to determine the unique situation
> of each patch, however I would like a suggestion on how to
Duncan wrote:
>every time I try to emerge -NuD system
I think there's a good case for system and world without the set specifier
working the way they always have. I for one am very aware if I type in
@world (ie not system, useful for -e) vs world. I don't see any benefit to
the user in jettisonin
Ciaran McCreesh wrote:
> On Wed, 13 Aug 2008 01:18:33 -0700
> Zac Medico <[EMAIL PROTECTED]> wrote:
>> * The old src_compile phase function is split into separate
>>src_configure and src_compile fuctions.
>
> If you're doing new phases... Exheres has been using src_prepare, after
> src_unpac
Joe Peterson wrote:
> Duncan wrote:
>> That's an interesting idea. I don't personally care either way, as long
>> as @world continues to /not/ include system/@system, but having world
>> (without the @) continue to include system /would/ be useful for backward
>> compatibility. I think it'd be m
Ciaran McCreesh wrote:
> On Tue, 19 Aug 2008 23:31:17 +0530
> Arun Raghavan <[EMAIL PROTECTED]> wrote:
>> Ciaran McCreesh wrote:
>> > The benefit is that it's a logically separate action, and will avoid
>> > all the silliness of people repeatedly changing their minds about
>> > which phase should
Ciaran McCreesh wrote:
> On Tue, 19 Aug 2008 21:27:03 +0100
> Steve Long <[EMAIL PROTECTED]> wrote:
>> > On Tue, 19 Aug 2008 23:31:17 +0530
>> > Arun Raghavan <[EMAIL PROTECTED]> wrote:
>> >> Ciaran McCreesh wrote:
>> >> >
Alec Warner wrote:
> At least one has...do you want to vote for each feature? What will it
> take to convince you?
>
It's not up to me, and I've already conceded on IRC that the consensus is
against me (just letting others know); that's life *shrug*
>>> (The one missing is a src_fetch_extra or
Duncan wrote:
> Ciaran McCreesh <[EMAIL PROTECTED]> posted
> [EMAIL PROTECTED], excerpted below, on Tue, 26 Aug
> 2008 14:20:44 +0100:
>
>> On Tue, 26 Aug 2008 06:39:38 + (UTC) Duncan <[EMAIL PROTECTED]>
>> wrote:
>>> But I think virtual works just fine for kde-base/kde, too, if one
>>> simp
Ciaran McCreesh wrote:
> On Sat, 30 Aug 2008 10:59:41 +0100
> Steve Long <[EMAIL PROTECTED]> wrote:
>> I concur that it makes a lot of sense, fitting in exactly with the
>> meaning originally given. That it means 'zero-install-cost' is
>> neither here nor t
Christian Faulhammer wrote:
> Zac Medico <[EMAIL PROTECTED]>:
>> Both approaches are essentially equivalent but it's a little simpler
>> for ebuild writer if they don't have to customize the output file
>> name.
>
> One needs exceptions for all kind of systems, for example I had to
> workaround
Joe Peterson wrote:
> Ciaran McCreesh wrote:
>> Except it doesn't. A virtual ebuild:
>>
>> * installs nothing
>> * does nothing
>
> I'd say that virtual does indeed do something: it pulls in other packages.
>
>> * should be treated as being very quickly installable
>> * should be treated as hav
Alec Warner wrote:
> On Sat, Sep 6, 2008 at 4:43 AM, Steve Long <[EMAIL PROTECTED]>
> wrote:
>> Christian Faulhammer wrote:
>>
>>> Zac Medico <[EMAIL PROTECTED]>:
>>>> Both approaches are essentially equivalent but it's a little simpler
&g
Thomas Anderson wrote:
> On Sat, Sep 06, 2008 at 12:43:12PM +0100, Steve Long wrote:
>> Christian Faulhammer wrote:
>>
>> > Zac Medico <[EMAIL PROTECTED]>:
>> >> Both approaches are essentially equivalent but it's a little simpler
>> >
Ben de Groot wrote:
> It may be 2 lines less, but it is 42 characters more.
> Plus, I dislike caps. :-p
Well the original patch used DEFAULT_CONFIG_ENABLE and DEFAULT_CONFIG_WITH
and didn't invoke any subshells. I'm not sure what the thinking behind
changing it was, unless it was a straight lift
Jorge Manuel B. S. Vicetto wrote:
> The next step was to use a kdeprefix use flag[2]. This flag no longer
> touches the SLOT that is set to "4" for all kde-4.X versions. It only
> determines if the package will be installed under the FHS compliant
> location (/usr) or under the old location (/usr/
Vaeth wrote:
> The point is that in contrast to shell code you need additional
> pre-knowledge to read or write it.
>
True.
>> the syntax looks fine and the syntax is in fact still bash.
>
> I do not want to start a discussion now whether this is
> implicit semantic or sort of an extended synta
Marius Mauch wrote:
> Second for the suggestions on how to handle the transition:
> - treating 'world' and '@world' differently is a no go from my POV. One
> of the main reasons to implement them as sets was to remove special
> case code in emerge, so I'm quite opposed to adding new special cases
Duncan wrote:
> Ciaran McCreesh <[EMAIL PROTECTED]> posted
>> Having to write an ebuild just to install something in a package manager
>> friendly way and be able to uninstall it cleanly later is a defect, not
>> a feature.
>
I've always rather liked that I can tell someone in -dev-help or -chat "
Ciaran McCreesh wrote:
> On Mon, 08 Sep 2008 22:40:37 +0100
> Steve Long <[EMAIL PROTECTED]> wrote:
>> >> * should be treated as being very quickly installable
>> >> * should be treated as having zero cost for installs
>> >>
>> Both of which
Marius Mauch wrote:
> On Wed, 10 Sep 2008 01:43:45 +0100
> Steve Long <[EMAIL PROTECTED]> wrote:
>
>> Marius Mauch wrote:
>>
>> > Second for the suggestions on how to handle the transition:
>> > - treating 'world' and '@world' di
Dale wrote:
> Holger Hoffstaette wrote:
>> On Wed, 10 Sep 2008 11:38:56 +0100, Mike Auty wrote:
>>> Marius Mauch wrote:
>>>
Maybe the best solution is to drop the non-prefixed versions of 'world'
and 'system' completely
>>> Deprecating the old syntax sounds like a s
Petteri Räty wrote:
> Icedtea has two release tracks. One for the 1.7 OpenJDK code base and
> one for the 1.6 code base. They have independent version numbering so
> they can have collisions. By moving the slot to the file name we could
> have icedtea-1.2:1.6.ebuildN and icedtea-1.2:1.7.ebuildN. T
Fabian Groffen wrote:
> On 17-09-2008 10:21:17 +0200, Santiago M. Mola wrote:
>> >> Why not simply alias patch=gpatch in profile.bashrc?
>> >> See the FreeBSD profile for an example.
>> >>
>> >
>> > I'd like to package portage for OpenSolaris and have it just drop-in
>> > work so modifications lik
Just wondered what's going on with this one; is it waiting for impl of GLEP
27 or something?
Would it be wise to update the documentation as requested, in the meantime?
http://bugs.gentoo.org/show_bug.cgi?id=217042
Thomas Sachau wrote:
> I see, we have a default src_unpack and a default src_compile but a
> default src_install is still missing. Here is my suggestion (taken and
> modified from bug 33544):
>
> src_install() {
> if [ -f Makefile -o -f GNUmakefile -o -f makefile ]; then
> emake DESTDIR=${D} inst
Vaeth wrote:
> Steve Long wrote:
>
>> Thomas Sachau wrote: [...]
>>
>> > [[ -n ${DOCS} ]] && dodoc ${DOCS}
> [...]
>>
>> It might be wise to use an array for DOCS there
>
> Since I have now seen suggestions for using arrays unnecessar
Ulrich Mueller wrote:
>> On Mon, 22 Sep 2008, Kent Fredric wrote:
>
>> find /usr/share/doc/ -wholename "* *"
>> /usr/share/doc/gpac-0.4.4-r1/ISO 639-2 codes.txt.bz2
>
> Yes, and if you look into src_install of the ebuild, it does:
> dodoc doc/*.txt
>
Well at least we've established that
Petteri Räty wrote:
> When EAPI 2 goes live built_with_use should probably die for most cases.
> Are there valid use cases for built_with_use that are not covered by the
> use deps in EAPI 2? If there are we could add a switch like --noeapi2die
> to it.
>
It would be nicer imo if we just added --
Ulrich Mueller wrote:
>>>>>> On Sun, 21 Sep 2008, Steve Long wrote:
>
>> That works for that specific case, yes, but it's still not a general
>> solution, which is what BASH arrays were invented for. For instance,
>> an ebuild author cannot specifical
[Sorry for length]
Vaeth wrote:
> Steve Long wrote:
>
>> Vaeth wrote:
>>
>> > let me remark that the more clever way to this is
>> >
>> > [ -n "${DOCS}" ] && eval "dodoc ${DOCS}"
>> >
>> eval is _not_ cle
Duncan wrote:
> Steve Long <[EMAIL PROTECTED]> posted
> [EMAIL PROTECTED], excerpted below, on Mon, 22 Sep 2008 01:35:57
> +0100:
>
>>> This is an old rhetorical trick (I don't know its name in English): You
>>> impute that I claimed things which I ne
Thomas Sachau wrote:
> Ulrich Mueller schrieb:
>> And I still don't see why we would need the most general solution for
>> a *default* function. There's always the possibility to write your own
>> src_install() for the few ebuilds that need it.
>>
> I aggree with Ulrich in this case.
As I said;
Ulrich Mueller wrote:
>> As I said; generality in lib functions seems like a useful thing.
>
> Other ebuild variables are space separated lists, so why should DOCS
> be an exception?
>
Because we're doing it right this time, while allowing existing usage. IOW
you can quite happily continue to use
Steve Long wrote:
> In summary that's why for
> instance no filenames with spaces (leave alone all the other characters
> you can't deal with atm) can be safely handled by any of your ebuild
> structure, unless it comes from a glob, and is never manipulated or
> re
Zac Medico wrote:
> Rémi Cardona wrote:
>> Zac Medico a écrit :
>>> Please consider a PROPERTIES=set value that allows an ebuild to
>>> indicate that it should behave like a package set when selected on
>>> the command line. This is behavior is somewhat difficult to describe
>>> in words but the f
Zac Medico wrote:
> Steve Long wrote:
>> Zac Medico wrote:
>>> Rémi Cardona wrote:
>>>> As one of the maintainers of the gnome-base/gnome meta, I fail to see
>>>> the usefulness of such a change. We have yet to ask users to rebuild
>>>>
Duncan wrote:
> Thomas Sachau <[EMAIL PROTECTED]> posted [EMAIL PROTECTED],
> excerpted below, on Sun, 05 Oct 2008 14:24:55 +0200:
>
>> I just had a user in bugzilla who thought, the developer profile would
>> be for software developers, not just for gentoo developers. Probably he
>> is not the
Robert Buchholz wrote:
> On Sunday 05 October 2008, Thilo Bangert wrote:
>> Ciaran McCreesh <[EMAIL PROTECTED]> said:
>> > On Sun, 5 Oct 2008 03:44:20 -0700
>> >
>> > "Robin H. Johnson" <[EMAIL PROTECTED]> wrote:
>> > > Either we need special cases to declare that it no longer has a
>> > > homepag
Alexis Ballier wrote:
> Indeed; different names could be given to different implementations of
> the same thing, but that might completely kill the point of abstracting
> it.
> Maybe eclasses should die on unknown eapi; the fact is I really hate the
> current way it's done when switching an ebuild
Ciaran McCreesh wrote:
> On Sun, 5 Oct 2008 17:38:11 +0200
> Ulrich Mueller <[EMAIL PROTECTED]> wrote:
>> > By the way, do we really want to special case eapi-2 in every
>> > eclass ? That's lot of code duplication and will get even worse
>> > when we'll reach eapi-42. That would have been cool to
Ciaran McCreesh wrote:
> On Tue, 07 Oct 2008 17:07:21 +0100
> Steve Long <[EMAIL PROTECTED]> wrote:
>> > It's illegal, according to PMS. It also won't work with Paludis,
>> > since phase function definitions aren't made available until just
>>
Brian Harring wrote:
> Steve Long wrote:
>> Robert Buchholz wrote:
>> >> Ciaran McCreesh <[EMAIL PROTECTED]> said:
>> >> > "Robin H. Johnson" <[EMAIL PROTECTED]> wrote:
>> >> > > Either we need special cases to decla
Peter Volkov wrote:
> Robert Buchholz ?:
>> Thilo Bangert wrote:
>> > HOMEPAGE="http://this-package-has-no-homepage.gentoo.org/";
>>
>> Why not use our package site for this, i.e.
>> HOMEPAGE="http://packages.gentoo.org/package/${CAT}/${PN}";
>
> This is not homepage. HOMEPAGE should point t
Ryan Hill wrote:
> Zac Medico <[EMAIL PROTECTED]> wrote:
>> Ryan Hill wrote:
>> > Though I'm still not sure what happens when a package is in two
>> > unrelated sets..
>> >
>> > @gnome:
>> >RDEPEND=">=gnome-extra/gnome-screensaver-2.22.2"
>> >
>> > @xfce4:
>> >RDEPEND="gnome-extra/gnome-
Ulrich Mueller wrote:
>> On Mon, 06 Oct 2008, Jorge Manuel B S Vicetto wrote:
>
>> No objections here, just a question. Do you know if the issue with the
>> lp:// sources has been fixed in bzr?
>
No objections, a minor point wrt bash:
EBZR_OPTIONS="${EBZR_OPTIONS:-}" (and similar variants)
d
Thomas Sachau wrote:
> what about this:
> insinto /usr/share/doc/${P}/examples
Is there any chance we can start using correctly quoted filenames across the
board?
[EMAIL PROTECTED] NB: I'm raising this as a talking-point, not pushing it as an
agenda,
so please don't reply if discussion doesn't
Jeremy Olexa wrote:
> Fabian Groffen wrote:
>
>> Most notably, in Prefix all keywords are full GLEP53 style, which
>> results in e.g. amd64-linux. We did this on purpose, because in Prefix
>> we don't necessarily are on Gentoo Linux. We also chose to expand fbsd,
>> nbsd and obsd to their long
Michael Haubenwallner wrote:
> Fabian Groffen wrote:
>> Ciaran McCreesh wrote:
>> > Steve Long wrote:
>> > > Unless someone can say what using PROPERTIES=prefix would break, I'd
>> > > go with that. It's a /classic/ usage of that variable,
Bo Ørsted Andresen wrote:
> 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.
>
>From
Alec Warner wrote:
> Petteri Räty wrote:
>> There's no need to commit straight to stable. Just make two different
>> new revisions for each EAPI. Then the arch teams can test it like usual.
>
> Aha a perfect canidate use case for GLEP 55[1] that fends off 'why are
> there multiple versions of the
Jan Kundrát wrote:
> Steve Long wrote:
>>> insinto /usr/share/doc/${P}/examples
>> Is there any chance we can start using correctly quoted filenames across
>> the board?
>
> Since when is ${P} allowed to have spaces?
>
I believe I answered this in my prior post.
Peter Volkov wrote:
> Jeremy Olexa ?:
>> Thomas Sachau wrote:
>> > Should we depend on all system packages? Should we depend on some
>> > packages, because they could be removed? If yes, which ones? Or should
>> > we leave the system packages out completly?
>>
>> https://bugs.gentoo.org/show_bu
Fernando J. Pereda wrote:
> On Wed, Oct 15, 2008 at 10:33:22AM +0100, Steve Long wrote:
>> Here you go (this is on an old machine, so you'll get much quicker times
>> if you try this at home):
>
> A big gain in the context of ebuilds and source packages. Well done.
>
David Leverton wrote:
> On Wednesday 15 October 2008 10:33:22 Steve Long wrote:
>> Here you go (this is on an old machine, so you'll get much quicker times
>> if you try this at home):
>> [EMAIL PROTECTED] ~]$ echo "$(> #!/bin/bash
>> P='some-crap
Ciaran McCreesh wrote:
> On Wed, 15 Oct 2008 18:36:32 +0200
> Markus Meier <[EMAIL PROTECTED]> wrote:
>> server16
>
> Already been discussed, can't be done.
>
What does it break?
Arun Raghavan wrote:
> I've not really got an opinion on the topic, per se, but fwiw, this is
> really not a meaningful statistic. *If* parsing strings in the ebuild is
> not a trivial part of the overall ebuild parsing process, then yes, this
> is a significant gain and should be treated as such.
Peter Volkov wrote:
> Steve, your example only tests how much time bash takes to parse string.
> It's obvious that in quoted strings some expansions could be avoided and
> thus bash works faster.
Yeah that's all I wanted to get across.
> But although ebuilds use bash syntax they are
> interprete
Ciaran McCreesh wrote:
> On Wed, 15 Oct 2008 20:28:43 +0100
> Steve Long <[EMAIL PROTECTED]> wrote:
>> Fernando J. Pereda wrote:
>> > A big gain in the context of ebuilds and source packages. Well done.
>> >
>> Yes, almost as important as not sourcing
Ciaran McCreesh wrote:
> Steve Long wrote:
>> Ciaran McCreesh wrote:
>> > Markus Meier wrote:
>> >> server16
>> >
>> > Already been discussed, can't be done.
>> >
>> What does it break?
>
> Have a
Ciaran McCreesh wrote:
> On Thu, 16 Oct 2008 22:06:40 +0100
> Steve Long <[EMAIL PROTECTED]> wrote:
>> > Have a look at, for example, [1], where Mike already gave you an
>> > answer one of the previous times we discussed it.
>> >
>> I'm aware o
Ryan Hill wrote:
> Steve Long wrote:
>> Ciaran McCreesh wrote:
>> > Steve Long wrote:
>> >> > Have a look at, for example, [1], where Mike already gave you an
>> >> > answer one of the previous times we discussed it.
>> >> >
>>
Ciaran McCreesh wrote:
> On Sun, 2 Nov 2008 12:11:10 -0700
> Gordon Malm <[EMAIL PROTECTED]> wrote:
>> > Have you conclusively established that they do build fine in
>> > parallel? If so, how?
>> Yes it builds in parallel. By compiling it in parallel.
> If you think compiling it in parallel con
Peter Alfredsen wrote:
> debug-print-function $FUNCNAME $*
You should be using "$@" not unquoted $*.
Seems like the FUNCNAME bit should just be rolled into the function
with "${FUNCNAME[1]}" which could be done tree-wide quite easily.
Duncan wrote:
> Joe Peterson wrote:
>> In general, it makes sense to me to have an unversioned one if there is
>> no version dependency - i.e. if xfce.eclass would likely work for future
>> ones (like "xfce5"). I'm not sure why, other than to emphasize that a
>> new version is out, upstream packa
David Leverton wrote:
> On Monday 03 November 2008 04:29:34 Nirbheek Chauhan wrote:
>> Why not use EAPI=1 for those ebuilds and turn the flag on by default?
>
> Well, as I said, it seems more sensible to me to set the default once,
> instead
> of once for each ebuild. I don't particularly care,
Peter Alfredsen wrote:
> 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 th
Maciej Mrozowski wrote:
> On Monday 01 of December 2008 09:36:12 Diego 'Flameeyes' Pettenò wrote:
>> > - USE=debug is useless when CFLAGS/LDFLAGS or FEATURES are not
>> > appropriate
>> What are you saying here? I'm afraid you're mistaken here.
>
> The point is to look at this from users' (well,
Donnie Berkholz wrote:
> Ciaran McCreesh wrote:
>> Donnie Berkholz wrote:
>> > I hadn't heard of it before, thanks for the ref. What was the reason
>> > for forking the codebase? It gets pretty annoying to copy across
>> > useful changes, especially while eselect is stuck in svn.
>>
>> Ease of get
Jeremy Olexa wrote:
> This causes me pain on my hosts that don't have >=bash-3.1[0] for
> /bin/bash. Because I can't install portage with an old bash until I
> get a new python installed which uses python.eclass which isn't
> supported with my /bin/bash (quite circular indeed)
>
> Technically the
Fabian Groffen wrote:
> On 20-12-2008 05:35:25 +0000, Steve Long wrote:
>> I note that bash-3.2_p17-r1 is stable on all the architectures that
>> 3.0-r12 lists (it just adds the two -fbsd archs as unstable.)
>> portage-2.1.4.5 requires at least that version (only unstable
Nirbheek Chauhan wrote:
> On Wed, Dec 24, 2008 at 9:50 PM, Doug Goldstein wrote:
>> Nirbheek Chauhan wrote:
> [snip]
>>> commands that die:
>>> everything that is implemented as a function (ebuild.sh, eclasses, etc)
> [snip]
>>
>> Technically the rule is that eclasses shouldn't die. At least that
Peter Volkov wrote:
> ? ???, 04/01/2009 ? 18:57 +0100, Robert Buchholz ?:
>> Accepting the fact that different teams have different preferences, we
>> need to find a solution for them to set theirs individually. This could
>> either be the order of elements in metadata.xml (and would set the
>
Ben de Groot wrote:
> Jeremy Olexa wrote:
>> Andrey Grozin wrote:
>>> It was discussed (don't have a reference to the thread at
>>> hand) that it would be useful to have a table which shows which
>>> functions die by themselves, and which not.
>>>
>> I see this asked every X months and never quite
Denis Dupeyron wrote:
> On Tue, Feb 3, 2009 at 11:47 AM, George Shapovalov
> wrote:
>> Besides, in my opinion, the ability to see "what's there" in at least
>> minimally categorized way without having to resort to using some special
>> tools or going to some website is worht something. In this va
1 - 100 of 518 matches
Mail list logo
