On 1 May 2013 02:52, Ryan Hill dirtye...@gentoo.org wrote:
Then the person implementing the code for Paludis is either a monkey or a
robot*.
*or both (?!)
Alternative possibilities include ninja, zombie and wizard.
On Sunday 08 March 2009 05:22:03 Donnie Berkholz wrote:
FYI, using EXPORT_FUNCTIONS before inherit, as this patch caused
x-modular.eclass to do, is broken in current portage releases. Zac said
he would change this to be consistent with the lack of any ordering
restriction in the PMS. Thanks to
2009/4/1 Mike Frysinger vap...@gentoo.org:
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.
I would like the Council to discuss the matter of Portage repeatedly
changing behaviour in
On Thursday 09 April 2009 19:06:16 Nirbheek Chauhan wrote:
dev-lang/python
So, wait, you want to depend on specific slots of python and keep them
around, and manage all their related bugs? Isn't that exactly the
opposite of what python upstream suggests, and *ALL* distros do?
If you install
On Sunday 10 May 2009 04:23:25 Nirbheek Chauhan wrote:
1. It was a paludis bug, of course paludis --info came in handy (are
you trying to jest? ;p)
It's most likely not a Paludis bug; do you really think that no-one's ever
tried to compile Qt4 on amd64 with Paludis until now? I'm guessing a
On Sunday 10 May 2009 09:58:22 Ryan Hill wrote:
On Sun, 10 May 2009 02:00:17 -0600
Ryan Hill dirtye...@gentoo.org wrote:
You can't test FEATURES in an ebuild. It's portage-specific.
Actually, am I right?
Yes. (http://bugs.gentoo.org/show_bug.cgi?id=239671#c10 gives a better
approach for
On Sunday 10 May 2009 13:47:45 Ben de Groot wrote:
What do you expect? He's an exherbo dev, only here to criticize Gentoo
and gloat over its perceived failings.
It's pretty hilarious that you think you know anything about me.
On Sunday 10 May 2009 14:02:48 Nirbheek Chauhan wrote:
It's even more hilarious that you expect to fix Gentoo's problems by
bitching about them.
Same to you as I said to yngwin.
On Sunday 10 May 2009 14:02:57 Ben de Groot wrote:
Just your activity on Gentoo channels (IRC, ML, etc), which is what my
assessment is based on.
Nothing I've ever done anywhere, in Gentoo channels or elsewhere, in any way
implies that I'm only here to criticize Gentoo and gloat over its
On Thursday 14 May 2009 19:06:51 Patrick Lauer wrote:
For quite some time (over a year, actually) we've been discussing the
mysterious and often misunderstood GLEP55.
[http://www.gentoo.org/proj/en/glep/glep-0055.html]
We agree on the latter adjective, if nothing else.
The proposed solution
On Friday 15 May 2009 02:42:33 George Prowse wrote:
Having countered those four points I guess you agree with the other five
then. Over 50% success rate (by your definition) is hardly being
ignorant or trolling
In that case we can assume that Patrick agrees with all my counterpoints,
since he
On Friday 15 May 2009 21:06:13 Steven J Long wrote:
In practical terms, this is a useless proposal. It rightly got trashed
last year.
No, it did not get trashed, despite some people's attempts to make their
side sound more popular than it really is. Some people like the idea, some
don't, and
On Saturday 16 May 2009 10:27:51 Marijn Schouten (hkBst) wrote:
How is it possible to do these things encoded in the filename?
For the export example, it's just a matter of using a different bash syntax
from what the magic regex expects, which is completely irrelevant if it goes
in the
On Saturday 16 May 2009 13:14:23 Duncan wrote:
I mean, for the longest time, the main (among many) boosting claim seemed
to be that the speed difference between in-file and in-filename made the
former prohibitive in practice.
No, performance was never the point of GLEP 55. People like to talk
On Sunday 17 May 2009 08:29:31 Patrick Lauer wrote:
I thought we had agreed that (1) with GLEP55 you have to source the ebuild
anyway (whereas the other proposal allows to just parse it to get at the
EAPI value) and (2) you can cache it sanely so that performance isn't the
issue?
You don't
2009/5/17 Ben de Groot yng...@gentoo.org:
Ciaran McCreesh wrote:
On Sun, 17 May 2009 23:17:57 +0200
Ben de Groot yng...@gentoo.org wrote:
2. Add new global scope functions in any sane way
This is a valid use case, as seen by the eapi-2 update. But the way
this is currently handled by portage
2009/5/18 Steven J Long sl...@rathaus.eclipse.co.uk:
David Leverton wrote:
2009/5/17 Ben de Groot yng...@gentoo.org:
I think the way eapi-2 was introduced into the tree wasn't particularly
problematic.
I think there might be a misunderstanding here. Ciaran means functions
provided
On Sunday 24 May 2009 21:40:57 Steven J Long wrote:
Hmm way to go putting thoughts in my head that aren't there.
Yes, that sums you up quite nicely.
On Monday 01 June 2009 05:25:06 Jorge Manuel B. S. Vicetto wrote:
Hello fellow developers and users.
Nominations for the Gentoo Council 2009/2010 are now open for the next
two weeks (until 23:59 UTC, 14/06/2009).
I would like to nominate dirtyepic, as he has repeatedly shown himself to be
On Sunday 05 July 2009 03:33:54 Arfrever Frehtes Taifersar Arahesis wrote:
I would like to suggest that values of IUSE_* variables (whose names end
with values of USE_EXPAND variable), after prefixing with lower-cased names
of appropriate variables included in USE_EXPAND, should be
2009/8/21 Arfrever Frehtes Taifersar Arahesis arfre...@gentoo.org:
Portage documentation has been properly fixed (and the fix will be released
in next version) and this feature can now be used in 10.0 profiles.
No. Changing the documentation does not retroactively change existing EAPIs.
In EAPI 3, most commands and functions provided by the package
manager automatically call die if they fail. There's also a
new nonfatal function that can be used to suppress this
behaviour: by prefixing a function/command call with nonfatal,
the automatic die behaviour is suppressed during the
On Friday 21 August 2009 21:56:41 David Leverton wrote:
A potential advantage of this over the previous solution is that if
the force option is implemented with an environment variable,
it can be used regardless of EAPI
...except that the previous solution could use an environment variable too
On Sunday 23 August 2009 01:26:24 Chip Parker wrote:
So, Ciaran, if your personal reference implementation of PMS fails
miserably when using this methodology, your argument that I won't be
or am not affected by your attempt at changing portage is invalid.
If you'd like to test for yourself,
On Sunday 23 August 2009 02:10:36 Chip Parker wrote:
They're the same thing. It doesn't matter if the profiles directory is
in located in /tmp or in /usr/local/portage, the behavior of paludis
*still* doesn't support the feature that these profiles depend on and
portage still *HAS* since
On Sunday 23 August 2009 03:39:52 Arfrever Frehtes Taifersar Arahesis wrote:
/etc/make.profile is by default a symlink to appropriate profile directory
in ${PORTDIR}/profiles.
Again, a detail of how Portage is configured. PMS only covers profiles that
are in repositories - it's up to the
On Sunday 23 August 2009 18:28:46 Ulrich Mueller wrote:
... still contains the following entries:
app-admin/eselect-compiler
dev-util/confcache
Both packages were punted about two years ago, so maybe it's time to
clean up?
Ulrich
confcache is still available in masterdriverz's
On Friday 04 September 2009 16:01:41 Rémi Cardona wrote:
For instance, I'm still working on migrating all the X11 packages to the
MIT license (mainly for cleaning purposes), but in fact, each and
every package should have its own license file (like today) because the
MIT license requires that
On Monday 05 October 2009 23:20:10 Ciaran McCreesh wrote:
You probably will see some remarks about commit it, and let
everyone else deal with the mess for years to come being the
long-established Gentoo tradition, however.
Not to mention accuse anyone who disagrees with you of being a troll.
On Tuesday 03 November 2009 15:48:03 Patrick Lauer wrote:
To quote:
FEATURES is a portage specific package manager configuration variable not
specified in PMS and cannot reliably be used in ebuilds or eclasses.
This has been the Portage team's position for years, since long before there
were
2009/11/26 Brian Harring ferri...@gmail.com:
This discussion in generall is daft. No package can rely on
nanonsecond resolution for installation because the most common FS out
there (ext3) does *second* level resolution only. As such, I can
pretty much gurantee there is *zero* packages out
2009/11/26 Brian Harring ferri...@gmail.com:
Why is this one special? Two out of three do this already, and it
works.
You mean two out of three blatently ignored long-standing behaviour
and added a new feature without discussion or an EAPI bump.
Paludis doesn't preserve mtime
You mean
On Thursday 26 November 2009 13:21:43 Brian Harring wrote:
It was always on the todo to convert portage over to preserving mtime-
this long predates PMS and even EAPI.
Like, for example, use deps? Yet somehow we managed to introduce those in a
new EAPI, instead of retroactively adding them to
On Monday 28 December 2009 20:50:17 Fabio Erculiani wrote:
What all this has to do with the fact that they are just build
dependencies? Just wondering.
They're not just build dependencies. They're required to use the library in a
certain way, namely to compile other programs against it. As
On Monday 28 December 2009 21:04:01 Fabio Erculiani wrote:
To me you are saying that DEPEND would work just fine. No?
Setting the proto as DEPEND for the library wouldn't work because a user could
install the library, remove every DEPEND-only package and legitimately expect
the library to
On Sunday 17 January 2010 20:38:48 Petteri Räty wrote:
With GLEP 42 and proper logging of e* messages I think we shouldn't
annoy users any more with ebeep or epause so attached is a patch only
defines these functions for EAPIs 0, 1 and 2. Anyone have a reason to
keep these around for EAPI 3?
On Thursday 18 February 2010 22:33:42 Tomáš Chvátal wrote:
[[ ${PN} == util-macros ]] || DEPEND+= =x11-misc/util-macros-1.3.0
[[ ${PN} == font-util ]] || DEPEND+= =media-fonts/font-util-1.1.1-r1
Do non-fonts really need font-util there? Looks like that sets up a nice
circular
On Thursday 18 February 2010 23:16:54 Tomáš Chvátal wrote:
That || die is not for eautoreconf
[[ -e something ]] somethingexists || somethingisnotexisting
For your behaviour it would have to look like this
[[ -e something ]] { somethingexists || die if the commands failed ; }
Do you mean
On Saturday 06 March 2010 15:26:10 Ioannis Aslanidis wrote:
Well, I personally would prefer to have two keywords at least, one for
candidates and another for confirmed bugs.
This sounds like the sort of thing Bugzilla's flags mechanism is for.
On Sunday 07 March 2010 04:30:55 Sebastian Pipping wrote:
What I wonder now is:
- Will it work with our very instance of Bugzilla?
The security team uses (or at least has used in the past) flags on Gentoo
Bugzilla.
- Can certain flag states be required when searching?
It looks like you need
On Thursday 01 April 2010 19:39:43 Dror Levin wrote:
Here's another suggestion: how about we don't impose any ridiculous
constraints on development and keep this discussion on the technological
side of the original proposal?
It's not ridiculous to expect to have a new EAPI in a reasonable
On Saturday 19 June 2010 22:03:31 Ben de Groot wrote:
It is about whether Gentoo wants to keep around people [...] who
continually attack others
Considering the number of attacks directed towards Paludis developers (and
sometimes users), and lack of corresponding punishment, I can only assume
On Saturday 19 June 2010 23:01:33 Patrick Lauer wrote:
you're actively stepping in the way of moving fists to complain that
people punch you. Stop doing that.
You mean banning trolls is an invitation for you to snip the trolling and
publicly accusing me of banning them on a whim? (excerpt
On Saturday 19 June 2010 23:05:25 Domen Kožar wrote:
http://xkcd.com/386/
s/wrong/attacking me in public/ and it might be closer.
On Monday 28 June 2010 02:09:44 Nirbheek Chauhan wrote:
Hello everyone,
I'm sure at least half of you are thinking Oh no, not this again...,
and I agree. However, I'm /also/ thinking Why the heck haven't we
done this yet?
[...]
/If/ you're¹ going to insist on doing this, could you please
On Tuesday 29 June 2010 09:46:52 Alex Alexander wrote:
If the community feels their choice, albeit not perfect, will help the
project, you have to respect that. That is, if you want to be part of the
community :)
I see your point to some extent, but the concern is that such decisions might
On 5 July 2010 14:01, Peter Hjalmarsson x...@rymdraket.net wrote:
1. (A t-shirt saying 2 + 2 = 5. For this joke to work you have to know
how to round numbers, and that 2 can be rounded from everything between
1,5 and 2,4, and that 4,8 rounds to 5. And it is still correct math.)
You said
On Friday 14 March 2008 07:14:23 Rémi Cardona wrote:
- the gnome2 eclass now has a pkg_preinst, if you do multiple
inherits, make sure that gnome2_pkg_preinst is called too. The
_games_eclass_ is one of those.
Maybe worth adding a dummy to the current version of the eclass so that
ebuilds
On Friday 14 March 2008 12:14:39 Petteri Räty wrote:
David Leverton kirjoitti:
Maybe worth adding a dummy to the current version of the eclass so that
ebuilds can be updated now, instead of suddenly all at once as soon as
the new eclass is committed?
And break a bunch of ebuilds to stable
On Friday 14 March 2008 12:20:15 Rémi Cardona wrote:
David Leverton a écrit :
Maybe worth adding a dummy to the current version of the eclass so that
ebuilds can be updated now, instead of suddenly all at once as soon as the
new eclass is committed?
Good idea, I'll see what I can do
On Tuesday 15 April 2008 12:14:57 Marijn Schouten (hkBst) wrote:
There are several option to handle this. I could use a less common
delimiter or I could escape it: ${D//_/\_} instead of ${D}. I could use a
sed expression that doesn't suffer from this problem (thanks to dleverton):
sed -ne
On Friday 30 May 2008 13:22:15 Diego 'Flameeyes' Pettenò wrote:
The only thing that can be broken by using --as-needed is code that
assumes the order in calling the .init sections of a set of shared
objects. Such an order is not only changed by --as-needed usage but by
any other change in the
On Friday 30 May 2008 17:29:49 Diego 'Flameeyes' Pettenò wrote:
This really is backward, solution-wise: you expect the core
application to know enough of the plugins to link them together, but
not enough to call their init functions...
Why should it call their init functions, when a static
On Saturday 31 May 2008 11:14:33 Luca Barbato wrote:
Ciaran McCreesh wrote:
Fact: the underlying issue is a libtool bug.
Wrong, it isn't just that, --as-needed and libtool are unrelated.
The issue that as-needed tries to solve is libraries being linked to binaries
or other libraries that
On Thursday 05 June 2008 19:21:24 Albert Zeyer wrote:
Are you sure that Squeak really depends on libffi?
I just compiled it (squeak-3.9.7) fine without having libffi on my
system and with disabled libffi USE-flag.
According to my reading of the code, it doesn't use libffi on x86-linux,
On Monday 09 June 2008 11:28:03 Josh Saddler wrote:
Let's change all that hideous, barely readable multiple brace/bracket
abuse into something more human-readable, shall we?
Please explain why angle brackets are readable but braces aren't.
pre caption=Environment state between functions
On Wednesday 11 June 2008 12:11:33 Brian Harring wrote:
Effectively, we've watched it essentially progress into a standard
that effectively only the paludis folk are adherent to (if in doubt,
ask portage folk, my sending this mail is indicative of the pkgcore
standpoint)- it's about time the
On Thursday 12 June 2008 02:46:03 Jim Ramsay wrote:
David Leverton [EMAIL PROTECTED] wrote:
Since at least one ebuild has already been modified specifically to
work around the bug, I'd say it's pretty real.
For those of us trying to play along at home, which one is this?
http://tinyurl.com
On Thursday 12 June 2008 08:36:18 Markus Ullmann wrote:
After investing more than two hours to just read the Mails that popped
up yesterday regarding this stuff, I'd say we can't really take this
serious. The PMS maintainers were withholding information on
compatibility issues they've seen.
On Thursday 12 June 2008 18:14:21 Mike Frysinger wrote:
he was told to remove kdebuild-1 from the repo and this has yet to happen
I just checked the April meeting log, and while I admit I didn't read every
word from start to finish, all I could see was that kdebuild couldn't be in
the final,
On Thursday 12 June 2008 22:21:48 Wernfried Haas wrote:
Agreed, if this is the way PMS is done, we should either get rid of it
or do it differently.
The current status as presented here is inacceptable.
Could someone please explain what's wrong with PMS, other than needs moar
XML and I hate
2008/6/13 Duncan [EMAIL PROTECTED]:
In this instance, it's the pulling teeth to get info on a claimed known
bug from PMS folks on pkgcore, while at the same time, complaints about
the non-clarity of PMS is met with remarks (by the same group of people)
of (paraphrased) filed a patch yet?
In
On Friday 13 June 2008 03:20:23 Brian Harring wrote:
1) http://bugs.gentoo.org/show_bug.cgi?id=171291
metadata/cache (hence labeled flat_list cache format) mtime
requirements.
The current spec attempts to handle things as well as possible on the package
manager side. If you'd like it to be
On Friday 13 June 2008 11:10:46 Nirbheek Chauhan wrote:
Interesting to note, however, that Paludis doesn't accept inline
comments, and this behaviour predates PMS.
There's a reason for Paludis not accepting them, and the same reason applies
to the question of allowing them in PMS or not,
On Friday 13 June 2008 11:18:53 Nirbheek Chauhan wrote:
Wait, what?
Where possible ?
You'd prefer us to do impossible things too?
PMS is supposed to be a specification which is as close to Gentoo's
Official Package manager's behaviour as possible while (preferably)
leaving out deprecated
On Friday 13 June 2008 11:23:29 Nirbheek Chauhan wrote:
On Fri, Jun 13, 2008 at 3:49 PM, David Leverton
There's a reason for Paludis not accepting them, and the same reason
applies to the question of allowing them in PMS or not, therefore PMS
doesn't allow them. There's no evil conspiracy
On Sunday 15 June 2008 15:42:28 Peter Volkov wrote:
For example, currently, PMS team does not include anybody from portage
team - official PM team and thus this team can't represent Gentoo
interests.
The Portage team is perfectly welcome to contribute if they wish. zmedico is
on the alias,
On Thursday 19 June 2008 04:09:26 George Prowse wrote:
In the end, PMS is just a way for them to spread their own agenda
Lies and FUD.
maybe it would be best for all if paludis and it's developers were to
concentrate on making paludis for a different distro. Trollix may be a
good place to
On Thursday 19 June 2008 01:23:33 Chris Gianelloni wrote:
Considering that the most recent official release is 2008.0_beta2, I
don't see where you have a point, at all.
http://www.gentoo.org/proj/en/releng/#doc_chap5
The latest release of Gentoo Linux is:
Gentoo Linux 2007.0 for Alpha, AMD64,
On Thursday 19 June 2008 02:21:24 Chris Gianelloni wrote:
It seems that everything these days is an EAPI scope change.
Everything change that has the potential to break existing packages, or to
make new packages incompatible with existing package managers, is an EAPI
scope change. That is the
On Thursday 19 June 2008 08:41:34 Luca Barbato wrote:
The point is to avoid breaking Portage versions that users might
reasonably be using, even if only briefly. Do you really expect /all/
users doing a new installation to choose the scary beta instead of the
nice safe release?
What
On Thursday 19 June 2008 08:44:41 Luca Barbato wrote:
Chris Gianelloni wrote:
On Fri, 2008-06-13 at 12:22 +0200, Luca Barbato wrote:
Care to share the logic and wise reasoning ?
[ ${IDEA_ORIGIN} != Ciaran ] die
I tend to agree.
The reason has already been explained multiple times,
On Thursday 19 June 2008 08:46:02 Luca Barbato wrote:
David Leverton wrote:
On Thursday 19 June 2008 04:09:26 George Prowse wrote:
In the end, PMS is just a way for them to spread their own agenda
Lies and FUD.
No
Yes.
...are you issuing a press release for exherbo?
What the hell
On Thursday 19 June 2008 08:51:15 Luca Barbato wrote:
We could either pick a week and do a major ebuild update to remove .la
files when unnecessary or just append a notice about revdep rebuild.
How do you decide when they're unnecessary?
--
gentoo-dev@lists.gentoo.org mailing list
On Thursday 19 June 2008 10:36:12 Luca Barbato wrote:
1 getting static libraries (pkg-config replaces this use)
Not for library consumers that use libtool but not pkgconfig.
2 load plugins using libtool support
Why only plugins? What's to stop an application from loading a normal
library
On Thursday 19 June 2008 11:39:44 Luca Barbato wrote:
Corner cases as usual...
What's that supposed to mean?
--
gentoo-dev@lists.gentoo.org mailing list
On Thursday 19 June 2008 13:08:09 Rémi Cardona wrote:
David Leverton a écrit :
Not for library consumers that use libtool but not pkgconfig.
I'd be in favor of having a _default_ configuration for Gentoo where
static binaries are never built except for some key packages (mainly for
rescue
On Thursday 19 June 2008 14:02:13 Nirbheek Chauhan wrote:
The point is that their replies to the mailing list waste a lot of
time and energy since people will *always* reply to them.
Replies? On a mailing list? Whatever is the world coming to?
I completely agree. They should stop pushing it
On Thursday 19 June 2008 14:19:32 Nirbheek Chauhan wrote:
On Thu, Jun 19, 2008 at 6:40 PM, David Leverton
[EMAIL PROTECTED] wrote:
On Thursday 19 June 2008 14:02:13 Nirbheek Chauhan wrote:
The point is that their replies to the mailing list waste a lot of
time and energy since people
On Thursday 19 June 2008 14:52:01 Nirbheek Chauhan wrote:
oh noes, too many posts with the same 3 people replying everywhere
and spreading their minority irrelevant opinion as though it really
mattered! What a gargantuan waste of time and energy11!~
If you disagree with people's opinions,
On Thursday 19 June 2008 18:06:17 Jeroen Roovers wrote:
In this case the attacks seem to be targeting a person who has been
attacking an entire ~300 person project for a few years now.
Is it considered acceptable to attack someone as long as the attacker thinks
they deserve it?
I honestly
On Tuesday 05 August 2008 16:16:25 Alec Warner wrote:
That being said you are free to chat to Zac about the changes
We've already spoken to him about the changes several times, and it's quite
clear that he either can't or won't understand why it's bad to make
incompatible changes without
On Tuesday 05 August 2008 20:45:33 Ben de Groot wrote:
It really baffles me that some developers are forcefully retired for
anti-social behavior, but are not consequently banned from the places
where they display this behavior, such as our MLs and IRC channels.
I'm not aware of any
On Wednesday 06 August 2008 07:37:26 Joe Peterson wrote:
You are trying to say it's a 'live' ebuild (i.e. it gets the sources from a
live source) - that's all. The locking issues are a technical detail
No, the locking issues are the whole point. There are other reasons to want
the package
2008/8/11 Alec Warner [EMAIL PROTECTED]:
Many folks are happy at the current pace of development. I imagine
these two folks were frustrated at the lack
of new features in the ebuild spec that were readily available in
kdebuild-1 and decided to move on. More power to them I say.
I'm pretty
2008/8/14 Donnie Berkholz [EMAIL PROTECTED]:
Why aren't fired developers banned from the channels where they
displayed this behavior?
Isn't this one effectively withdrawn? I asked yngwin which devs he
was referring to, and he said there weren't any, so is there anything
left to discuss?
On Monday 25 August 2008 20:36:34 Zac Medico wrote:
Zac Medico [EMAIL PROTECTED] wrote:
Looking at the dependencies of kde-base/kde, it seems like it would
be eligible to exhibit the virtual property.
I'm inclined toward virtual since it's more brief and I think it
might strike a chord
2008/9/4 Zac Medico [EMAIL PROTECTED]:
* The 'unpack' helper function recognizes ;sf=tbz2 and ;sf=tgz
extensions, for interoperability with gitweb.
* SRC_URI supports a syntax extension which allows customization
of output file names by using a - operator.
Is it useful to have both of
2008/9/5 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.
But is it so much simpler as to justify adding a special
gitweb-specific hack to the package managers?
On Monday 08 September 2008 08:48:23 Vaeth wrote:
But it doesn't do this well
Those of us who have actually been using it say it does.
On Thursday 11 September 2008 21:06:48 Doug Goldstein wrote:
Tobias Scherbaum wrote:
Luca Barbato wrote:
I don't see any problems with it.
+1
Tobias
+1
Since this latest version hasn't generated any noticeable disagreement, could
the Council please formally vote on it at the
On Saturday 20 September 2008 18:15:27 Alexis Ballier wrote:
I can think of checks like:
- foo is a dep/rdep of bar
- foo has a plugin like architecture
- bar will work with minimal foo
- most people will expect some features in bar that come with foo's
plugins
- we might want to display
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 directed at anyone in
On Saturday 01 November 2008 02:44:50 Josh Saddler wrote:
emboss - Seriously. Who needs the European Biology Open Software Suite
on a *desktop* oriented system?
That flag is only used by a few sci-biology packages, so if you don't have any
of those installed, it doesn't matter whether the flag
On Saturday 01 November 2008 20:57:17 Gordon Malm wrote:
I'd like to get distcc added as one of the FEATURES we are able to
RESTRICT.
Regardless of whether it's a good idea or not, does it fix all the known
issues if the ebuild sets DISTCC_HOSTS=localhost in the environment?
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, though, just making sure
people
On Sunday 04 January 2009 16:48:38 Nirbheek Chauhan wrote:
On the contrary, the reverse of what you say is true. A simple grep of
the tree showed that:
In how many of those ebuilds would the long form be
use1? ( cat/pkg[use2] )
rather than
use1? ( cat/pkg[use2] ) !use1? ( cat/pkg )
?
On 7 March 2012 21:07, Alexis Ballier aball...@gentoo.org wrote:
As i understand it, $PM will need to try the regexp tingy on any ebuild
anyway, guess the EAPI then source the ebuild with the right sourcer
to get the real EAPI and compare it.
Not exactly... the idea with proposal 2) is that
On Mar 8, 2012 3:29 PM, Zac Medico zmed...@gentoo.org wrote:
Something like DEPEND=foo bar is also valid bash, and yet we don't
allow that either because foo bar does not contain valid dependency
atoms.
There's a bit of a difference between caring about the value of a
variable and caring about
On 14 March 2012 18:56, Zac Medico zmed...@gentoo.org wrote:
Whatever the arguments may be, the whole discussion boils down to the
fact that the only people who seem to have a problem are those that
have a separate /usr partition and simultaneously refuse to use an
initramfs.
I wonder if it
1 - 100 of 146 matches
Mail list logo
