William Hubbs wrote:
And I would argue that the maintenance cost of having separate /usr in a
general sense is much higher than the benefit it provides.
That's a legitimate point (not that I necessarily agree or disagree as
I'm not the one who's tried to make it work) - perhaps I should have
William Hubbs wrote:
The reason the split happened is pretty straight forward, and every other
"justification" for continuing it was come up with after the fact.
I keep hearing this, but I really don't see how it's relevant. I'm sure
you'll find lots of things in your life that you use for so
Patrick McLean wrote:
This is not true. Bind mounts can be performed on a single file, and
bind mounts are part of mount namespaces. Granted the target file _must_
exist (it could be a dead symlink, or a symlink to /dev/null) before
performing the bind mount.
Well that's even better then. :-)
Mike Gilbert wrote:
This is a horrible example. /etc/resolv.conf is a configuration file
for code that lives entirely in userspace. Of course it makes no sense
to shove that into the kernel.
My point is that it's silly to have a hard-coded special case in the
kernel for mtab, especially if it
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
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
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.
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 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
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
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
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
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:
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
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
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.
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
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
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
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
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:
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
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
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 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 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 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 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 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 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 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 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 Aug 8, 2011 12:22 AM, "Mike Frysinger" wrote:
> virtual/yacc which has "|| ( sys-devel/bison dev-util/yacc )".
No dev-util/byacc?
On Saturday 30 July 2011 18:38:55 Rich Freeman wrote:
> On Sat, Jul 30, 2011 at 1:20 PM, David Leverton
> > From /etc/conf.d/fsck, seems like a reason to keep the / FS as small as
> > possible to reduce the amount of time spent waiting during boot:
> Well, that only really ha
On Saturday 30 July 2011 14:55:23 Samuli Suominen wrote:
> Someone mentioned NFS mount on /usr. Do we have other reasons? How
> many users that might be?
From /etc/conf.d/fsck, seems like a reason to keep the / FS as small as
possible to reduce the amount of time spent waiting during boot:
# f
On 6 October 2010 10:20, Luca Barbato wrote:
> We discussed that to death, you are wrong abusing overlinking in your pet
> project and what you were asking for is exactly the as-needed behaviour.
Clearly you have no clue what you're talking about here.
On 5 October 2010 23:38, Enrico Weigelt wrote:
> And for Distros, it doesnt make sense to try to support anything imaginable.
Not breaking things that already work would be a decent compromise.
> I'm now working in embedded area (where static linking is quite common)
> for about 10yrs, and pkg-c
On 5 October 2010 02:55, Diego Elio Pettenò wrote:
> USE flags add complexity, and in real use cases there are near to no
> good reasons at all to keep .la files around.
That's why I initially suggested a variable rather than a USE flag, as
if it was implemented in a centralised function it would
On 3 October 2010 15:29, Luca Barbato wrote:
> I think the simpler solution is that if it needs .la, before reaching the
> tree it has to be fixed...
What I'm not keen about that is that using the .la files isn't really
"broken" - if libfoo uses libtool, and some other software uses
libfoo's .la
On 3 October 2010 14:20, Richard Freeman wrote:
> Such a solution would also have the virtue of allowing the use of USE
> dependencies. So, you would only install the .la files from a
> particular library if another package actually needed them. Packages
> could also have USE defaults as seems l
On 2 October 2010 20:54, Jorge Manuel B. S. Vicetto
wrote:
> Given the recent activity around .la files and conflict about how to
> deal with them, I propose we discuss this issue in this mailing list,
> and take this issue to the council.
> That way, we can make a global decision, taking into acc
2010/8/22 Michał Górny :
> src_compile() {
> scons \
> $(scons-use unicode) \
> $(scons-use gnutls ssl gnutls openssl) \
> ${MAKEOPTS} || die
> # expands into:
> # scons unicode={1|0} ssl={gnutls|openssl} -jN || die
> }
It might be
On 12 August 2010 08:51, Ben de Groot wrote:
> Exactly. This is Gentoo. Let Exherbo devs go develop their own distro
> and stop trying to interfere with Gentoo. It is time the council puts
> a definite stop to GLEP 55.
I've already discussed this with you, but it seems you still don't get
it. Pe
On 5 August 2010 04:27, Brian Harring wrote:
> If an EAPI adds a new global function that cannot set/influence EAPI,
> PM's that don't support that EAPI will spit complaints about 'missing
> command' during sourcing- however the PM will still see the EAPI value
> is one it knows it doesn't support
On 2 August 2010 22:40, Matti Bickel wrote:
> On 08/02/2010 08:16 PM, David Leverton wrote:
>> If so, it sounds like what you really want is per-package eclasses
>> (maybe with elibs as well to hold the non-metadata code), which
>> aren't covered by GLEP33 but ough
On 2 August 2010 12:11, Brian Harring wrote:
> On Mon, Aug 02, 2010 at 11:56:08AM +0200, Matti Bickel wrote:
>> Hi folks,
>>
>> I've been told that my use of eblits in dev-lang/php is something I
>> should get rid of as soon as possible. Suggested alternative by ferring:
>> use elibs.
There's a c
On 19 July 2010 22:11, Mike Frysinger wrote:
> you mean the people who want to use get_all_version_components would have to
> change their invocation to go through eshops_need ? otherwise i dont follow
> what you mean.
You define the function, then call eshopts_need immediately
afterwards, and i
On 19 July 2010 21:30, Mike Frysinger wrote:
> i imagine this might be useful in some scenarios, but i think the more common
> usage is to enable things inline. otherwise, the exported API would need to
> be wrapped internally like:
> get_all_version_components() {
> eshopts_need _get_all_
On 19 July 2010 20:43, Mike Frysinger wrote:
> On Monday, July 19, 2010 03:38:39 Ciaran McCreesh wrote:
>> On Sun, 18 Jul 2010 20:17:45 -0700 Alec Warner wrote:
>> > Can we do away with all the extra foo && return bullshit and just set
>> > a trap?
>> >
>> > trap "eshopts pop" RETURN
>> >
>> > ?
On 5 July 2010 14:01, Peter Hjalmarsson 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 yourself that it's a j
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 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 yo
On 28 June 2010 12:09, Duncan <1i5t5.dun...@cox.net> wrote:
> [...]
The only one playing politics here is you. Adding --as-needed changes
the semantics of the toolchain so as to violate the relevant
standards. In some specific cases it might be OK or even beneficial,
but doing it by default is w
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 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 fr
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 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 am
On Thursday 01 April 2010 12:18:27 Brian Harring wrote:
> It's a bit brief and likely left out an insult or two
If anyone's been personal and insulting in this discussion, it isn't Ciaran.
I've seen this attitude on IRC too. Funnily enough, you don't speak for other
people, you don't decide wha
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 ne
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.
http://www.bugzilla.org/docs/2.22/html/flags-ov
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 ;
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
circul
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 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 cont
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 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 t
2009/11/26 Brian Harring :
> 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 "Paludis carefully
2009/11/26 Brian Harring :
> 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 there that requi
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
w
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 tro
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
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 masterdriver
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 pac
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 be
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 yoursel
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
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 e
2009/8/21 Arfrever Frehtes Taifersar Arahesis :
> 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.
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 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 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.
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
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
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
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 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 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 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 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 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 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 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 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 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 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
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 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
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 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 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
1 - 100 of 154 matches
Mail list logo
