Denis Dupeyron wrote:
On Tue, Feb 3, 2009 at 11:47 AM, George Shapovalov geo...@gentoo.org
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
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 figured out why,
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
Fabian Groffen wrote:
On 20-12-2008 05:35:25 +, 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 on mips as
against 2.1.1-r2
Nirbheek Chauhan wrote:
On Wed, Dec 24, 2008 at 9:50 PM, Doug Goldstein car...@gentoo.org 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
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 there are
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 getting things
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, a bit)
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 the
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 packages (like
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,
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 confirms that
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.
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.
I'm aware of the prior discussion.
Re-read it, and tell me what it breaks, if you can
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 of the prior discussion.
Re-read it, and tell me what it breaks
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. I
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
interpreted
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 any ebuilds, so let's all
stick an EAPI extension
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 look at, for example, [1], where Mike already gave you an
answer one of the previous times we
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, as it's simply
a boolean; PROPERTIES is well-defined and I'm hoping
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 what I remember of the awk that generates those manpages
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 same
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.
Besides being faster (quote the whole
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_bug.cgi?id=221311
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.
Yes, almost as important
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 $(run)
#!/bin/bash
P='some-crap/god-i-hate-asshats'
I do hope that that isn't
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?
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 to package
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:
snip
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
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
before that phase executes (there is a reason
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 declare that it no longer has a
homepage, or we need to allow the empty HOMEPAGE.
HOMEPAGE
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 only one.
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
homepage, or we need to allow
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 to
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 have a pm
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 following
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
gnome completely. Do you have any specific use cases (maybe coming
from
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 your
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
referenced in and of itself. (Unless
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 never said - of course, then it is
easy for you to prove
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;
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 unnecessarily
at least twice (see also
[RFC] Ability to pass arguments
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 it can and does
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 specifically include a file with spaces, and
ignore all the other
[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_ clever. Try: /msg greybot eval
..or check http://wooledge.org:8000/BashFAQ/048
This is not at all related with my
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} install ||
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 like what you suggest
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
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. This
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 sensible action to get
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' differently is a no go from my POV.
One of the main reasons to implement them
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 If
you can
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 follow from installs nothing. Or would you disagree?
No, they're
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 having zero cost
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
for ebuild writer if they don't have to customize the output file
name
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
for ebuild writer if they don't have to customize the output file
name
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
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 syntax - it
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 Trac which
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
simply reads it
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 there imo; 'virtual' is a well understood terms
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
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:
The benefit is that it's a logically separate action, and will
avoid all the silliness
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
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_unpack, to
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 much
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 do the
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
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
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
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
concepts. It
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
some
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 confirmation
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 enough.
Shouldn't that just be scripted via pybugz? A GUI
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
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 thru
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's
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 my
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. So perhaps
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.18r2=1.19
Please use the appropriate mailing list. Nothing technical
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 RDEPEND except where this will
create circular dependency chains
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 of thing not be considered out of band data
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 else.
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.
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 eclass. But yeah,
the fun is what attracts me
Brian Harring wrote:
On Thu, Mar 20, 2008 at 06:51:13AM +, 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 doesn't reload bash for every phase
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 trying
to achieve, then I'd say
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 read
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
use, (although I accept I might
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
Iain Buchanan wrote:
On Thu, 2008-02-28 at 14:28 +0200, Petteri Räty wrote:
He has been breaking the tree for a while now but as Calchan has been
having availability problems I get to insult him a little bit later than
usual. Bo hails from Aalborg, Denmark. He studies to become a control
Fabian Groffen wrote:
Ben de Groot wrote:
Bernd Steinhauser wrote:
| Wouldn't it be more clean if it is amd64 just like the Linux one?
| Because the arch basically is the same. I think that
| amd64(-linux) -- x86_64-fbsd
| x86(-linux) -- x86-fbsd
|
| would be more confusing than
|
Felipe Contreras wrote:
On Sat, Feb 23, 2008 at 10:45 PM, Alec Warner [EMAIL PROTECTED] wrote:
On 2/20/08, Felipe Contreras [EMAIL PROTECTED] wrote:
b) Error are difficult to handle since bash doesn't have exceptions
I disagree here: most errors are fatal anyway any non fatal errors can
1 - 100 of 485 matches
Mail list logo
