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?
>
> A
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?
>
>
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 t
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 tha
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,
pp
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.
>
> bunch o'neat code
>
Wow, you mean we just type
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 th
On Wednesday 11 June 2008 14:20:55 Luca Barbato wrote:
> Bernd Steinhauser wrote:
> > And that wasn't the point. He pointed out, that there is an issue, that
> > hasn't been caught because of missing tests.
>
> That may or may not exist
Since at least one ebuild has already been modified specifica
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 al
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, o
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 h
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 ye
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, ther
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 depre
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'
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, A
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?
>
>
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 mu
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
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 k
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
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
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 opinio
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 think
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 ex-develo
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 m
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 pre
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 s
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
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 o
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
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/god-i-hate-asshats'
I do hope that that isn't directed at anyone in particular.
2008/10/15 Steve Long <[EMAIL PROTECTED]>:
> Though, given your tone, I don't think you are feeling harrassed; perhaps
> you're just feeling defensive about your trap boo-boo?
Er, I'm not aware of anyone even trying to tell me that I'm wrong with
anything I've ever said about trap. If you mean no
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 fla
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 Friday 14 November 2008 14:25:30 Alexis Ballier wrote:
> Moreover .la files are good when you want to link statically to some
> library because they carry the needed information; they should be
> punted only when said library provides a good alternative (like a .pc
> file with correct libs.priva
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 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
2009/4/1 Mike Frysinger :
> 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 ebuild-visible ways
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 in
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 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 this particul
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 per
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 soluti
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
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,
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 filenam
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 ta
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 :
> Ciaran McCreesh wrote:
>> On Sun, 17 May 2009 23:17:57 +0200
>> Ben de Groot 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 (advising to upgra
2009/5/18 Steven J Long :
> David Leverton wrote:
>
>> 2009/5/17 Ben de Groot :
>>> 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
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 automatica
On 7 March 2012 21:07, Alexis Ballier 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 the header comment
On Mar 8, 2012 3:29 PM, "Zac Medico" 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 what synt
On 14 March 2012 18:56, Zac Medico 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 might help to
On 14 March 2012 21:04, Greg KH wrote:
> Haveing a separate /usr is wonderful, and once we finish moving /sbin/
> and /bin/ into /usr/ it makes even more sense. See the /usr page at
> fedora for all of the great reasons why this is good.
My point was examine, in detail, whether separate-/usr-wit
On 14 March 2012 22:51, Greg KH wrote:
> Oh, that's simple, separate-/usr-without-initramfs will not work and
> will not be supported :)
See, it's this "we're doing it this way because we know best and we
say so" that upsets people. I'm trying to encourage everyone to get
to the core reasons for
On 14 March 2012 23:44, Greg KH wrote:
> Oh, and somehow "consensus" will work? No, sorry, it will not.
No, logical analysis will, as I said in the rest of my post which you
conveniently ignored - either we conclude with evidence that there are
no issues, which should settle the matter for reaso
On 14 March 2012 23:47, Zac Medico wrote:
> It's more about what we're _not_ doing that what we're doing.
Clearly something must have changed in udev 181 to make
/usr-without-initramfs not work anymore, and someone must have done
something to make that change happen, unless udev has aquired the
a
On 15 March 2012 00:45, Zac Medico wrote:
> You're pointing your finger at udev, but the udev change is just a
> symptom of a more general shift away from supporting the "/ is a
> self-contained boot disk that is independent of /usr" use case.
OK, so there are multiple instances of people not not
On 19 March 2012 06:05, Samuli Suominen wrote:
> dev-cpp/cppserv would need working dev-cpp/sptk and we have none:
>
> http://bugs.gentoo.org/show_bug.cgi?id=402149#c9
>
> the only working versions got marked as "obsolete" by upstream due to
> "undisclosed reasons" whatever that means
>
Not that
On 30 March 2012 14:25, Samuli Suominen wrote:
> Back to year 2009?
>
> http://www.gentoo.org/news/20091004-gentoo-10-years.xml
That never stopped anyone before
http://en.wikipedia.org/wiki/Final_Fantasy_X-2
Zac Medico wrote:
Also, maybe apply_user_patches_here should have a special return value
if there are no patches to be applied? That way, src_prepare can avoid
an eautoreconf call if there are no patches.
Does that imply that every ebuild for an autotools-based package would
be expected to hav
Zac Medico wrote:
Isn't that just a consequence of how autotools works? Do you have a
better alternative?
Maaaybe letting the package manager know how to run autotools if
necessary? There's already built-in autotools knowledge in that econf
is in practice autotools-specific. On the other ha
Zac Medico wrote:
So, here's a description of the whole algorithm that I'd use:
> [snip]
I think the following is equivalent, but simpler and more general since
it doesn't have to mention details like ** and friends that aren't
currently in PMS, and doesn't assume that the rule for handling K
Luca Barbato wrote:
On 03/05/12 16:18, Mike Frysinger wrote:
you need to think bigger. Chromium supports joystick inputs (which come and
go) for playing games in the browser, so udev makes sense.
So is it using libudev to get that information? I guess would be
possible to patch it out, probab
Mike Frysinger wrote:
On Friday 04 May 2012 15:25:58 David Leverton wrote:
If it really is just for joysticks etc it might be worth seeing if it
can be made to use XInput instead. Maybe upstream had a specific reason
not do it that way in the first place, but in general, X apps really
Greg KH wrote:
No one forces you to use any of this software if you do not want to.
There are lots of other operating systems out there, feel free to switch
to them if you do not like the way this one is working out, no one is
stopping you.
Or alternatively, the people who hate Unix could move
Zac Medico wrote:
Isn't it presumptuous to say that they hate Unix? Maybe their vision of
how they'd like Unix to be is just different from yours?
If "how they'd like Unix to be" goes so blatantly against its
fundamental design principles then I think it's reasonable to say that
they hate it.
Mike Frysinger wrote:
exec {mj_control_fd}<>${mj_control_pipe}
I'll have to remember that feature, but unfortunately it's new in bash
4.1, so unless we're giving up 3.2 as the minimum for the tree
: $(( ++mj_num_jobs ))
Any reason not to do just
(( ++mj_num_jo
Michał Górny wrote:
Hello,
A simple solution to a program long-unsolved. In GLEP form.
Just a couple of minor points/nitpicks:
1) If an installed package has both IUSE_RUNTIME and REQUIRED_USE,
should REQUIRED_USE be re-verified:
a) for every dep resolution
b) when the package is involved
Michał Górny wrote:
On Thu, 21 Jun 2012 20:05:46 +0100
David Leverton wrote:
1) If an installed package has both IUSE_RUNTIME and REQUIRED_USE,
should REQUIRED_USE be re-verified:
a) for every dep resolution
b) when the package is involved in the resolution for some other
reason (not
Michał Górny wrote:
No, of course not. Otherwise, every package manager run would
practically require it to re-validate all packages in the tree
(possibly not only installed ones).
Package manager must ensure the flags are valid when package is
in the graph. I would think of IUSE_RUNTIME as a la
Ian Stakenvicius wrote:
Technically it could, but the issue here would be what you are going
to do with a has_version check on an IUSE_RUNTIME dep -- the package
should do filesystem-identical installs no matter what status of
IUSE_RUNTIME flags, so whatever one would do with a has_version check
Marien Zwart wrote:
Possible solutions:
a) automatically rewrite the dep as
postscript? ( app-text/ghostscript )
!postscript? ( !app-text/ghostscript )
There may be more than one version of docmangler, with a postscript flag
with different effects (IUSE_RUNTIME or full IUSE, differ
On 10 September 2012 15:48, William Hubbs wrote:
> All,
>
> I have a regression in OpenRc wrt netplugd [1].
>
> In researching this program, I have found that it and ifplugd, which is
> the alternative, have been unmaintained for years. Also Debian has
> declared netplugd to be obsolete in favor o
On 13 September 2012 06:48, Ulrich Mueller wrote:
>> On Thu, 13 Sep 2012, Brian Harring wrote:
>> For SANDBOX_*, while that's a PM internal, that's a bit of a grey
>> zone; regardless, we can actually address that via extending the
>> sandbox functions a bit:
>>
>> addwrite [-r|--remove] pathw
On 1 May 2013 02:52, Ryan Hill 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.
Rich Freeman wrote:
[...] and the point that many things
break in namespaces without the symlink, since /etc/mtab does not
reflect the state of the namespace. The latter in particular seems
like a pretty fundamental limitation - the very concept of /etc/mtab
is that mounts are global, and the de
Rich Freeman wrote:
However, FWIW, linux namespaces cannot be used to have only a single
file appear differently to different processes. Mount namespaces can
only operate at the directory level.
So to work around that limitation we insist that everyone change how
their systems are set up, and
1 - 100 of 154 matches
Mail list logo
