On Saturday 19 November 2005 12:00, Thierry Carrez wrote:
> The intermediary decision (during the October meeting, one month ago)
> was that the GLEP would be approved, pending a list of changes. During
> last month, nobody raised his voice to say this list of changes was
> fundamentally flawed. Wh
On Monday 21 November 2005 21:50, Donnie Berkholz wrote:
> Here's the change:
> "virtual/x11" -> "<=x11-base/xorg-x11-6.99"
virtual/x11 isn't xorg for all profiles.
Carsten
pgpKJHUHNPisT.pgp
Description: PGP signature
I have to say I'm somewhat disappointed by what I see compared to Aarons
proposed look¹.
a) Regarding the space below the two horizontal menus: A continuous image
looks much better than these "cells" with a lot of useless and redundant
links above them. If you think the space is wasted - well
On Monday 21 November 2005 13:36, Jakub Moc wrote:
> Well, I would like to see them on the left (and really could live without
> those illustrative pics accompanying them, but that's just me. ;)
I don't think they're very useful at the bottom either, but one (imho)
important improvement of the de
When you are interested in sim and willing to fix all bugs¹ and takeover
maintainership) speak now. Christmas morning I'll crucify it.
Carsten
[1] https://bugs.gentoo.org/show_bug.cgi?id=110241
pgplrITLoIEF7.pgp
Description: PGP signature
use.local.desc:app-text/ghostscript-afpl:jasper - Enable support for jpeg2k
(jasper)
use.local.desc:kde-base/kdegraphics:jpeg2k - Enable support for jpeg2k
(jasper)
use.local.desc:kde-base/kdelibs:jpeg2k - Enable support for jpeg2k (jasper)
use.local.desc:net-proxy/ziproxy:jpeg2k - Enable support
On Thursday 22 December 2005 20:14, Drake Wyrm wrote:
> Query: Which would be more appropriate in this case? "jasper" for the
> library it pulls in as a depend, or "jpeg2k" for the functionality that
> library provides? There's nothing else in the tree (as far as I can
> tell) which provides JPEG-2
On Friday 23 December 2005 21:45, Spider (DmD Lj) wrote:
> Erm.. No, I don't think he is. We've been asking / waiting for the
> [use] syntax to appear since before you joined the project. It's been on
> "the list" for so long that many of us have given up... ; )
He - and I thought I just missed t
On Saturday 24 December 2005 12:34, Peter wrote:
> THAT is a very reasonable comment!
Not at all. "Meta ebuilds" are a provisional and fugly workaround as long as
we have to wait for proper sets and only to be used for a larger set of
packages. Wrapping three or four ebuilds with another one, ju
On Saturday 24 December 2005 13:50, Peter wrote:
> Would you please add the comments to the bug report? Or, may I copy them?
> Please advise.
Feel free to do so.
> Also, I find it absolutely fascinating that the only people against this
> concept are devs, and the only people for it are users. Re
This isn't politics, but copyright infringement on top of a ridiculous license
(when you want to see it as one) we had a short discussion¹ about several
months ago.
Carsten
[1] http://tinyurl.com/9oxgc
pgpHcVb3ubq0c.pgp
Description: PGP signature
On Monday 26 December 2005 14:57, Drake Wyrm wrote:
> You're going to be hard-pressed to get any kind of consensus on this
> issue. Many dev seems to feel that the license belongs there. In some
> cases the COPYING, LICENSE, and/or INSTALL files contain, not boilerplate
> drivel, but actually uniqu
On Monday 26 December 2005 19:36, Joe McCann wrote:
> This whole thread seems to have come from a
> misunderstanding of how use.defaults work and 20 min of boredom.
use.defaults are based on the idea that having an ebuild installed should
activate the relevant use flag(s) behind the users back.
On Monday 26 December 2005 18:07, Ciaran McCreesh wrote:
> Because it makes sense. For any application which has IUSE="emboss",
> chances are emboss should be enabled. There was a long discussion about
> this on the -user list a while back where I ended up posting a
> newbie-friendly explanation of
On Saturday 24 December 2005 02:04, Brian Harring wrote:
> dev-lang/python[tcltk]
> ^^^ need that atom resolved with use flag tcltk enabled
I think that's exactly what someone told me months ago. :)
> >=sys-apps/portage-2.0[sandbox,!build]
>
> ^^^ need >=portage-2.0 merged with sandbox on, build
On Monday 26 December 2005 21:28, Ciaran McCreesh wrote:
> If they're purely in DEPEND, that one isn't even an incompatability.
Right. But it's not that unlikely to see such a corner case sooner or later
and it would be good if Portage catches it, instead spitting out a weird
message, leaving th
On Tuesday 27 December 2005 01:46, Ciaran McCreesh wrote:
> You solve this either by SLOTting bar and making each bar SLOT use a
> SLOT dep upon KDE, or by using USE flags and [use]:slot deps.
It's not a that uncommon case and would lead to dozens, very likely (depending
on the future development
On Tuesday 27 December 2005 02:29, Brian Harring wrote:
> So... basically, your concern is with the resolver, not use/slot deps
> syntax.
I did not say that this would have anything to do with the syntax. Am I right
to extract from your words that we get rid of ~arch users complains about
up/do
On Tuesday 27 December 2005 02:23, Ciaran McCreesh wrote:
> Nooo! That's exactly the point I was making. Carsten is assuming that
> by using [slot:bar] syntax, no backwards incompatibility will be
> introduced by adding a new [fish:] key.
Nooo! ;) I said it would look more consistent, than always
On Tuesday 27 December 2005 02:42, Brian Harring wrote:
> Well, we all seem to be missing the issue, so please spell it out
> clearly (rather then "it's going to get bad"). Didn't grok it from
> the previous email, so spell it out please :)
Just did so in the answer on your other email.
Carsten
On Tuesday 27 December 2005 03:11, Brian Harring wrote:
> Either way, still not totally following your complaint, thus an actual
> example would help (easiest to assume I'm a moron, and start at that
> level of explanation).
O.k.
1. You have KDE 3.4 and Digikam (version doesn't matter) installed
On Tuesday 27 December 2005 03:11, Brian Harring wrote:
> Never said anything about 2.1 + resolver enhancements (no clue where
> that one came from). Merely commenting on your raised issues about
> use/slot deps.
From your words. Thanks for destroying my hope in two sentences. ;p
So we add this d
On Tuesday 27 December 2005 03:40, Brian Harring wrote:
> The version of digikam being merged requires slot=3.5- it should be
> depending on libk* slot=3.5, also, no?
No! It (and also its dependencies) can be built against each 3.x slot.
> As long as the information is represented dependency wise
On Tuesday 27 December 2005 04:08, Brian Harring wrote:
> So note the comment in the email you are responding to about locking
> down the used dep/rdeps for an install.
That would be a maintenance nightmare. Every time a new KDE versions comes out
a new ebuild revision for every package depending
On Tuesday 27 December 2005 04:07, Ciaran McCreesh wrote:
> But it's not binary compatible between KDE slots. So, once we
> have :slot dependencies, you should link to a specific :slot (possibly
> controlled via USE). It's like packages that can use either gtk or gtk2
> -- this has to be handled vi
On Tuesday 27 December 2005 08:08, Mike Frysinger wrote:
> anyone who installs a program in portage already has a copy of the license
> on their system ... $PORTDIR/licenses/
My point was that it is often not the license of the copyright holder, because
the copyright notice included in many licen
On Tuesday 27 December 2005 14:00, Jason Stubbs wrote:
> If all three of those packages were first built against kdelibs:3.4 and
> then kdelibs:3.5 became available then rebuilding any one of them without
> rebuilding the others will break digikam. I can't see how it's directly
> represented in the
On Tuesday 27 December 2005 14:59, Jason Stubbs wrote:
> Do you mind reading and replying to the second paragraph (which happens to
> be the only new information I brought to this thread). Underlining words to
> emphasize a point to me that I've opened by agreeing is really not
> necessary.
I did
On Tuesday 27 December 2005 18:07, Ciaran McCreesh wrote:
> It's worse than O(n^n) if you try to do USE dep conflict resolution
> too...
Theoretically yes, practically the worst number of dependency levels we speak
of to walk up/down is not infinite ;). Of course there's no chance to get
this li
On Tuesday 27 December 2005 18:10, Ciaran McCreesh wrote:
> eclass, and no -r bump.
Then it would not be possible to build the Application against different KDE
versions and those who want to stay with a previous KDE version wouldn't be
able to install any application. And conditional dependenci
On Tuesday 27 December 2005 18:44, Ciaran McCreesh wrote:
> Can you prove it, for the "allow USE and version cycling" case? (Hint:
O.k, let m treat you as a the hot potato that you're Ciaran:
- We speak about ebuilds, which are installed and need to be reinstalled.
There is no version cycling (o
On Tuesday 27 December 2005 18:59, Ciaran McCreesh wrote:
> Nnnope. If you modify an eclass it forces a cache regen for packages
> using said eclass (except possibly if you're using an overlay, but
> that's a separate issue...).
You're trying to solve something which is already solved, but this ha
Hi Daniel,
what you've done breaks runtime dependencies, if not for other packages so at
least for KDE. Such a change should be announced on the gentoo-dev mailing
list before you do it. Also a tracking bug to coordinate stabilization of new
ebuild revisions will be needed, once the changed eb
On Wednesday 28 December 2005 17:32, you wrote:
> It's not supposed to break runtime dependencies. Everything that was
> installed before is installed now, in the same location.
But installed by another package. Of course it breaks dependencies when you
depend on xpdf, because you expect it inst
It's
- broken
- dead upstream
- unmaintained
- and no other ebuild relies on it
Carsten
pgpL4YGZ6RNAY.pgp
Description: PGP signature
On Monday 02 January 2006 10:35, Alexandre Buisse wrote:
> Isn't there any way to make xpdf and poppler live together on the same
> system?
This is not about not being able to run both xpdf and poppler on one system.
The blocker exists, because one ebuild of one package installs now files
previo
On Tuesday 03 January 2006 20:25, Luis F. Araujo wrote:
> >Portage does not resolve block correctly, look at bugzilla there are tons
> > of bugs open.
>
> So i suppose we should avoid using this kind of notation whenever possible.
See, it's not possible to avoid that with the current Portage vers
On Thursday 05 January 2006 11:26, Duncan wrote:
> This man speaks my mind. That's one of the things I'm worried about with
> the Enterprise Gentoo thing, and why I think it will make a better
> separate project than part of Gentoo itself.
I agree mostly, too. Just that QA has more aspects than "
On Thursday 05 January 2006 16:46, Diego 'Flameeyes' Pettenò wrote:
> Yeah ok, let me end up these holidays, and I'll prepare a written request
> to change the Linux part in something else
You should also contact the folks working on the gentoo.org redesign. While
there was a bit of fuss about th
On Thursday 05 January 2006 23:04, Curtis Napier wrote:
> > No, that's censored to only display what certain people want it to say
> > rather than the truth of what's going on.
>
> Censored? Please expand on this, how is it censored? I thought we were
> allowed to put anything Gentoo related we wan
On Friday 06 January 2006 16:27, Lance Albertson wrote:
> As seen from the discussion earlier this week, I don't think Gentoo has
> the proper open-mindness to create a proper enterprise distro.
This has nothing to with open-mindness, but having enough people doing the
general maintenance of a cl
On Sunday 01 January 2006 06:30, Mike Frysinger wrote:
> Keep in mind that every resubmission to the council for review must
> first be sent to the gentoo-dev mailing list 7 days (minimum) before
> being submitted as an agenda item which itself occurs 7 days before the
> meeting. Simply put, the g
You don't have to care, Alin. Mips is not among the security-wise supported¹
architectures.
Then only problem I see in general is, that every single subproject defines
what is supported and the information is scattered on the different
gentoo.org documentation pages (release, security, kernel,.
On Sunday 08 January 2006 01:38, Brian Harring wrote:
> Asking people to focus on cleaning the tree? Sure. Generate a list
> of candidates would help. Blocking new packages? No...
I can't say I did not expect negative replies and "generating a list of
candidates" is at least a suggestion. But
On Sunday 08 January 2006 01:35, Stuart Herbert wrote:
> I agree that some cleaning is needed (and some of my packages are
> desperate for it!), but I'm totally opposed to this idea. I think the
> idea of shutting up shop for three months (presumably with a "closed
> for refurbishment" sign on the
On Sunday 08 January 2006 15:01, Brian Harring wrote:
> Guessing you missed the previous flame war about how trying to force
> people to do something doesn't actually work?
When it's not common sense, that every dev is supposed to do a minimal on
general QA, Gentoo has a problem.
> You're assumi
On Saturday 21 January 2006 09:08, Ciaran McCreesh wrote:
> Were that the case, we'd do as Debian do and distribute a licence with
> every single package.
I bet there're more than a few ebuilds where this isn't the case. You can't
even blame anyone, since there's no proper licence section in the
On Monday 13 February 2006 20:29, Grobian wrote:
> Maybe that has to change then? Like getting more bug wranglers that
> also handle canned responses as a first-line helpdesk?
Wrangle bugs a few months and you'll see how hard it can be to stay friendly
sometimes... And no, bugzilla is not a help
On Sunday 19 February 2006 10:20, Ciaran McCreesh wrote:
> It gets worse still. It looks like many our mirrors have broken copies
> of certain Berlios-hosted tarballs.
Shouldn't that be a general problem with our mirrors - unless Berlios got
hacked and modified tarballs injected, of course?!
> D
On Sunday 19 February 2006 11:32, Ciaran McCreesh wrote:
> As I understand it, our mirror scripts rely upon wget being able to
> fetch the correct tarball from the original location.
Well, I'd expect them to fail gracefully when the tarball is clearly invalid
and not to inject the junk. But I don
Got a positive answer. Any remaining issues?
Carsten
pgpNZUjiYYIkb.pgp
Description: PGP signature
On Monday 20 February 2006 19:51, Ciaran McCreesh wrote:
> Positive as in "yes, we'll fix it", or positive as in "yes, we're
> mangling the tarballs and we hate you"?
Positive as in already fixed.
Carsten
pgpBBuf9e1rQs.pgp
Description: PGP signature
On Saturday 04 March 2006 16:43, Dan Armak wrote:
> If you're concerned about diskspace you can filter out /usr/share/doc
> entirely, so users do have the choice. The problem here is that the docs
> USE flag is off by default. Making more packages use the flag would install
> less docs. Has anyone
On Saturday 04 March 2006 02:04, Ciaran McCreesh wrote:
> This is undocumented and unofficial, so feel free to utterly ignore it
> and commit whatever the heck you want.
>
> The 'doc' and 'examples' (yay for consistency!)
Don't now, if I guess right what you want to say, but there's no plural of
On Monday 06 March 2006 17:39, Paul de Vrieze wrote:
> I guess some advanced /etc/portage/bashrc magic isn't enough for you?
> There are some neat tricks you can play with that.
I consider this sort of ugly hack. And I don't see the point why everyone
should do this, while a maintainer, even when
On Monday 06 March 2006 17:49, Paul de Vrieze wrote:
> Documentation is uncountable. So no singular or plural ;-)
Uh, that was meant ironic, considering Ciaran's remarks to others, that they
should know about this or that, leading to the one or the other inflaming
thread. But thanks for the expl
Hi,
a short list of packages, which can be buried imho:
x11-misc/kpasman - unmaintained upstream for years, alternatives e.g.
kde-misc/pwmanager
media-libs/libdbmusic - exclusive dependency of media-sound/kmusicdb, which
has been removed a while ago
net-misc/knetmonapplet - unmaintained upstr
On Saturday 25 March 2006 12:49, Diego 'Flameeyes' Pettenò wrote:
> NetBSD, OpenBSD, GNU/kFreeBSD, GNU/Hurd, Solaris?
It's great that you and others are working on alternative platforms, but
regarding decisions which tools we use, our main platforms are of interest.
Everyone else should/has to m
On Saturday 25 March 2006 19:50, Diego 'Flameeyes' Pettenò wrote:
> This is the same line of thinking that makes people use flash or wmv
> "because it's the silly Linux users that has to adapt, Windows works fine"
> and similar.
It's not. Darcs is not proprietary, so you can make it work if you wa
Got a request¹ providing them, but I don't see any sense in it at all. The
only package using it is app-office/lyx. Imho the dependency should be
removed, since it is a optional runtime dependency the user has to configure
anyways, so it'll never work out of the box. This sort of virtual is only
Given that most of the world not necessarily knows who the Amish are, it
should be added, that they form the heart and soul of the north american
technology elite¹.
Carsten
[1] http://en.wikipedia.org/wiki/Amish
pgpDbje8gW1U8.pgp
Description: PGP signature
On Thursday 30 March 2006 01:55, Mark Loeser wrote:
> Not directed specifically at you, but it seems a lot of people are
> masking stuff and removing it very quickly, and I'd really like to see
> everyone wait the 30 days to remove something from the tree. That way
> anyone using this package in s
On Sunday 02 April 2006 20:41, Mike Frysinger wrote:
> nothing personal, but who are you to say whether it's legit ?
It's really not a question what's legit (heck, you started using this term, so
blaming Olivier for using it is a bit odd), but what we (can and want to)
support. Wouldn't it have
On Sunday 02 April 2006 04:48, Daniel Goller wrote:
> exactly, what's the point of removing it so fast? give people a chance
> to miss it, it does not matter if it's removed or masked only as far as
> going "woah, what?" and if masked it is a matter of unmasking rather
> than recommitting
We haven
On Sunday 02 April 2006 21:51, Harald van Dijk wrote:
> Others did speak up at that time. The result:
>
> http://article.gmane.org/gmane.linux.gentoo.devel/31641
Yeah, that was the one and only single voice.
Carsten
pgplFkefqq6Ma.pgp
Description: PGP signature
On Sunday 02 April 2006 21:28, Mike Frysinger wrote:
> last time i recall following the gtk/gtk2 stuff, the idea was that in the
> future to move to a gtk/gtk1 situation ... but this was back when Spider
> was The Man, so i guess people forgot about that
No, see the whole thread Harald references
On Sunday 02 April 2006 21:31, Ciaran McCreesh wrote:
> The usual period is thirty days.
Grep this mailing list, most often a one week period was used.
> Once it's in p.mask it's effectively gone, to the extent that ignoring
> it for a month is fine.
Who said a package gets masked before it gets
On Sunday 02 April 2006 22:33, Ciaran McCreesh wrote:
> This is a recent change, and usually someone replies with "why not a
> month?".
This is simply not true or we have very different ideas of the meaning of
recent. The vast majority of "last rites" emails from 2005 had slated
removals of one
On Sunday 02 April 2006 22:29, Simon Stelling wrote:
> Come on. Is this a 'policy doesn't say I have to be sane' war? It's
> absolutely reasonable to p.mask a package that is pending for removal. That
> way you give the users a timeframe which they can search for alternative
> tools in.
This is n
On Sunday 02 April 2006 22:40, Mike Frysinger wrote:
> lets apply the same logic to all things unmaintained !
Yes, that's one reason I am so annoyed of the unmaintained parts of the tree.
> besides, you're talking about removing GTK1 completely ... this thread is
> talking about deprecating the g
On Sunday 02 April 2006 23:26, Jakub Moc wrote:
> Not that I'd care so much whether it's a week or a month (IMO individual
> depending on ebuild in question) - so just a technical note. Portage 2.1
> *does* spit out the relevant info.
I'm aware of this, but that doesn't help anyone running running
On Monday 03 April 2006 00:29, foser wrote:
> Already security related issues have been dropped by upstream for the
> simple reason that it hasn't been maintained since the day gtk went
> 2.0 .
Why didn't you file (Gentoo) security bugs? Perfect reason to drop Gtk1
support, if no one steps up to
On Monday 03 April 2006 01:54, Daniel Goller wrote:
> you are really trying hard to get gtk(1)
Everyone as s/he likes. I favor the deprecation of the gtk2 flag and start
dancing on my chair, once we have a Portage version with slot/use depends in
arch. But this is a completely different topic: K
On Tuesday 04 April 2006 11:12, Chris Bainbridge wrote:
> Surely the question isn't whether the upgrade is perfect, but whether
> it's better than the current stable release?
Exactly.
> (I realise that isn't a perfect patch count...)
Exactly.
> I think at this point it does more harm than good
On Tuesday 04 April 2006 04:37, Grant Goodyear wrote:
> Although I agree with the overall spirit of the comment, I disagree that
> RTFM is never the right answer. It helps if somebody points out _which_
> fine manual to read, but ":help hardcopy" is a much better answer to
> "How do I print from w
On Tuesday 04 April 2006 06:52, Mike Frysinger wrote:
> sorry, those last two paragraphs are covered elsewhere between infra and
> evrel ... so the document should be considered without those last two
> paragraphs
> -mike
This is what I'd like to see clarified. To me, only a decision of the Counci
On Tuesday 04 April 2006 01:44, Jon Portnoy wrote:
> Well, quite frankly devrel has never fallen down on the job quite so
> often & so hard before handling this particular incident. I don't think
> it's so unreasonable to have backup plans for preserving Gentoo when
> devrel cannot respond in a tim
On Tuesday 04 April 2006 21:53, Donnie Berkholz wrote:
> This is absurd. The council shouldn't need to make every decision in
> Gentoo itself. It should be able to delegate power to any group it chooses.
Such a decision is not like /every/ decision and should happen only very
seldom, so I don't s
On Friday 07 April 2006 04:26, Donnie Berkholz wrote:
> I also share the opinion that we shouldn't go against upstream wishes
> IRT branding, but if upstream encourages some fairly subtle branding
> along with keeping their name visible, I'm for it.
There's a thread in gentoo-core from 2004 with r
On Friday 07 April 2006 15:28, Simon Stelling wrote:
> He said he wanted to make it easy, not forcing it. Or am I mistaken?
How do you want not to enforce it? The last time¹ someone came up with
a "branding" use flag, some were in favor of, some against it.
Still, the basic question is: Why!? Th
On Saturday 08 April 2006 00:52, Mike Frysinger wrote:
> highly suspect statements
>
> these states are all quite common ... trying to make some kind of
> supposition as to which is the most common is a waste of time
No. It's my opinion. Respect it, please. You don't have to agree.
> in my experi
I dislike the idea to create lots of symlinks for that reason. But I'm having
a bug¹ open at mozilla.org with the goal to create rss feeds from the
documentation.
Carsten
[¹] https://bugzilla.mozilla.org/show_bug.cgi?id=332095
pgpBhuQuKgGb2.pgp
Description: PGP signature
On Friday 28 April 2006 21:57, A. Khattri wrote:
> Does it make sense to make the value of RDEPEND in an ebuild depend on USE
> flags? Example: Im writing an ebuild that use either cvs or svn at
> runtime. I want to allow users to choose which one they want but make cvs
> the default. What's the be
On Saturday 29 April 2006 00:02, Tuan Van wrote:
> and I also saw something like below without cvs USE flag:
>
> RDEPEND="svn? ( dev-util/subversion ) !svn? ( dev-util/cvs )"
Does obviously not work, if you want to have both available. Also enabling cvs
support by disabling svn is not transparent
On Saturday 29 April 2006 09:08, Alin Nastac wrote:
> Huh? How about:
> RDEPEND="|| ( dev-util/cvs dev-util/subversion )"
Similar problem as with Tuan's version: It's intransparent to the user and he
has no choice, unless he looks into the ebuild. || ( foo bar ) is only an
option, if you have t
On Tuesday 25 April 2006 08:53, Alin Nastac wrote:
> Lets say a package foo depends on bar, both at compile time and run time.
> Shouldn't DEPEND _and_ RDEPEND of the foo package reflect that
> dependency? I usually set DEPEND="$RDEPEND ..." or vice-versa (depending
> on which is the most demanding
On Friday 05 May 2006 09:20, Bart Braem wrote:
> Firefox 1.5: 5 months (the entire world uses it now, in stable)
Still has open at least one open vulnerability I know of, still has memory
management problems afaik. Despite that it's stable on some architectures. We
have exactly one active dev wo
On Friday 05 May 2006 08:32, Kevin F. Quinn (Gentoo) wrote:
> If you use specific versions in the package.keywords file (i.e. do
> "=category/package-version-revision ~arch" instead of
> "category/package ~arch", this doesn't happen.
Hardcoding specific ~arch versions or revisions unless absolutel
On Friday 05 May 2006 15:23, Kevin F. Quinn (Gentoo) wrote:
> I disagree. Your argument is for not using ~arch at all, rather
> than an argument against keeping control of what you have from ~arch.
No. My argument is that category/ebuild is much better than
=category/ebuild-x*. If and only if th
On Friday 05 May 2006 20:37, Kevin F. Quinn (Gentoo) wrote:
> First, I'll get the security updates when (1) the relevant updated
> package goes stable, which is usually pretty quickly, or (2)
> notification is made in gentoo-announce (which must be the correct
> place to get such notifications).
T
On Wednesday 17 May 2006 00:22, Stephen Bennett wrote:
> > Does the Gentoo Project not support the
> > entire tree all of a sudden?
>
> There are plenty of ebuilds in the tree marked as unsupported by
> gentoo. Probably some profiles too, though I can't name them for
> certain off the top of my hea
On Wednesday 17 May 2006 15:50, Ciaran McCreesh wrote:
> On Wed, 17 May 2006 01:58:02 +0200 Carsten Lohrke <[EMAIL PROTECTED]>
>
> wrote:
> | I haven't had a look at Paludis (the name sucks as much as the name
> | eselect had, before it was named eselect, btw.) yet, so I
On Thursday 18 May 2006 20:02, Ciaran McCreesh wrote:
>It's kinda like this:
Stop making such odd and wrong comparisons. The package manager is part of
what defines a distribution, choosing a shell is the users choice. If you
want to make the package manager matter of choice, start your own
dis
On Thursday 18 May 2006 20:43, Roy Marples wrote:
> Yes, part of it. baselayout is another part - and yet it's possible to run
> Gentoo on other variants like initng, daemontools and no doubt others.
Sure baselayout is. An there're others in the tree, But that doesn't mean
these variants are supp
On Thursday 18 May 2006 22:15, Ciaran McCreesh wrote:
> | Sure baselayout is. An there're others in the tree, But that doesn't
> | mean these variants are supported (special cases like embedded aside).
>
> Sure, some of them are supported.
By supported I mean all relevant packages in the tree inst
On Friday 19 May 2006 09:33, Roy Marples wrote:
> Maybe you haven't noticed, but baselayout is a virtual - which does make
> things harder as the main "forks" (vserver and fbsd) sometimes break when
> we add new things and they haven't synced up yet.
I have nothing against a virtual. I just don't
On Friday 19 May 2006 15:24, Harald van Dijk wrote:
> grep through gcc/po/*, which doesn't require installation of the
> locales
Providing the error messages in english is part of what I consider the users
job when filing a bug report. Having to grep for the strings is wasted time.
I'm not so sur
On Friday 19 May 2006 16:17, Roy Marples wrote:
> I can show you bugs where existing packages have invalid init scripts that
> just don't work with any baselayout version in portage. You could argue
> that they shouldn't be in the tree - if so then our imap server is
> foo-bared as it uses courier
Don't repeat a failure of the past. Do
NEED_CMAKE x.y
inherit foo
...
instead this ugly toplevel function call.
Carsten
pgpkzcuaeL675.pgp
Description: PGP signature
On Thursday 25 May 2006 16:37, Diego 'Flameeyes' Pettenò wrote:
> Probably he meant
>
> NEED_CMAKE="x.y"
Exactly. Sorry for the typo.
Carsten
pgp0EvhAdBnkq.pgp
Description: PGP signature
1 - 100 of 233 matches
Mail list logo
