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
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
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
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,
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
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. :-)
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 13 September 2012 06:48, Ulrich Mueller u...@gentoo.org 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]
On 10 September 2012 15:48, William Hubbs willi...@gentoo.org 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
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,
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 levert...@googlemail.com 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
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
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
((
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.
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,
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
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
On 30 March 2012 14:25, Samuli Suominen ssuomi...@gentoo.org 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 ssuomi...@gentoo.org 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
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
On 14 March 2012 21:04, Greg KH gre...@gentoo.org 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
On 14 March 2012 22:51, Greg KH gre...@gentoo.org 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
On 14 March 2012 23:44, Greg KH gre...@gentoo.org 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
On 14 March 2012 23:47, Zac Medico zmed...@gentoo.org 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
On 15 March 2012 00:45, Zac Medico zmed...@gentoo.org 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
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 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 Aug 8, 2011 12:22 AM, Mike Frysinger vap...@gentoo.org wrote:
virtual/yacc which has || ( sys-devel/bison dev-util/yacc ).
No dev-util/byacc?
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:
#
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 has a benefit if the system
On 6 October 2010 10:20, Luca Barbato lu_z...@gentoo.org 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 weig...@metux.de 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
On 2 October 2010 20:54, Jorge Manuel B. S. Vicetto
jmbsvice...@gentoo.org 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
On 3 October 2010 14:20, Richard Freeman ri...@gentoo.org 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
On 3 October 2010 15:29, Luca Barbato lu_z...@gentoo.org 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
2010/8/22 Michał Górny gen...@mgorny.alt.pl:
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
}
On 12 August 2010 08:51, Ben de Groot yng...@gentoo.org 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
On 5 August 2010 04:27, Brian Harring ferri...@gmail.com 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
On 2 August 2010 12:11, Brian Harring ferri...@gmail.com 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.
On 2 August 2010 22:40, Matti Bickel m...@gentoo.org 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 ought to be easy enough
On 19 July 2010 20:43, Mike Frysinger vap...@gentoo.org 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
?
That
On 19 July 2010 21:30, Mike Frysinger vap...@gentoo.org 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() {
On 19 July 2010 22:11, Mike Frysinger vap...@gentoo.org 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
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 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 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 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 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 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 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 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 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
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 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
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 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 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 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
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 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
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 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 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
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 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 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 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 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
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 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
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 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 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 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 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 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 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.
1 - 100 of 146 matches
Mail list logo
