Mike Frysinger wrote:
how about a local USE flag like all-the-junk-in-the-trunk ?
Why? Just makes more work for us, for no apparent reason. I'd rather be
able to pull unused stuff from the tree after a while than add a new
option to install stuff nobody will ever run.
Thanks,
Donnie
Curtis Napier wrote:
Giving ad space to our sponsors is legal for us to do as a Not For
Profit because they are donating goods and/or services to us.
Technically we are not giving them ads, we are acknowledging the
donated goods and/or services. Just like PBS does at the beginning of
it's
Doug Goldstein wrote:
The following global USE flags have been deleted from the tree because
no ebuild uses them.
dba
dio
ingres
msession
nhc98
oggvorbis
zeo
Have you looked in eclass/ ? A quick grep for those sees a lot popping
up in php eclasses.
Thanks,
Donnie
signature.asc
Mike Doty wrote:
What vote? I don't remember one.
5 nominees, 5 positions. Did you want a popularity contest among them?
Thanks,
Donnie
signature.asc
Description: OpenPGP digital signature
Robin H. Johnson wrote:
On Sat, Sep 02, 2006 at 08:55:33AM -0500, Mike Doty wrote:
If that's not good enough for you, please find a distribution that you
have to pay for like RHEL. Their testing is no better than ours, but
at least paying something entitles you to bitch at them.
Or consider
Chris Gianelloni wrote:
On Thu, 2006-08-24 at 22:36 -0700, Donnie Berkholz wrote:
From what I see, projects are pretty free to govern themselves. How do
you see it differently?
How do you kick someone out of a project? Currently, I know of no way
to do so.
What process is required
Sune Kloppenborg Jeppesen wrote:
On Thursday 24 August 2006 02:17, Donnie Berkholz wrote:
All in all, the vocal minority has done a splendid job of becoming more
influential, crippling Gentoo's ability to do anything at all about its
members, their flames, their outstanding work at ruining
Sune Kloppenborg Jeppesen wrote:
On Thursday 24 August 2006 09:52, Donnie Berkholz wrote:
Sune Kloppenborg Jeppesen wrote:
What? This doesn't make any sense. People bitching and moaning and
screaming all over -dev until no one else has any interest in pursuing
anything has nothing to do
Stuart Herbert wrote:
On 8/24/06, Donnie Berkholz [EMAIL PROTECTED] wrote:
When I think about where Gentoo was when we turned into a democracy
years ago, and where Gentoo is now, I don't see much of a difference on
the large scale. We lack any global vision for where Gentoo is going, we
can't
Marius Mauch wrote:
Donnie isn't much clearer either (it's mostly observations mixed with
personal feelings, not much in real problem anlysis).
Yeah, later I'll probably boil that down into something more bullet-pointy.
Thanks,
Donnie
--
gentoo-dev@gentoo.org mailing list
Chris Gianelloni wrote:
On Thu, 2006-08-24 at 14:00 -0700, Donnie Berkholz wrote:
Oh, gimme a break. Screaming about it on -dev for hundreds of posts
isn't just equivalent to a vote, it's better. It makes people think
there's more than 2 developers opposed to it.
Really? Even you didn't
Chris Gianelloni wrote:
On Thu, 2006-08-24 at 14:54 +0100, Ciaran McCreesh wrote:
Most of these problems could be solved if we had a council that was far
less spineless, a council that's prepared to address the *real* issues
rather than doing nothing, a council that shows leadership and
Herbie Hopkins wrote:
I'm not sure why /emul was originally chosen though it's a choice I've
just gone along with whilst maintaining these packages. I've always
viewed the emul libs as a temporary measure until we had full multilib
fuctionality in portage. Afaik the only person working on this
Simon Toth wrote:
Hi,
I posted this to the bugzilla, but was redirected here, so:
INTRO:
I have just a small proposal. There are many theme packages in portage,
but many good are still missing, the problem I actually noticed when
creating my own ebuild for comix cursors, is that there is
Donnie Berkholz wrote:
For ebuilds that use USE_EXPAND to pull in other dependencies rather
than just internally building drivers (I suspect xorg is the only one),
I've been thinking of a way to make the whole setup cleaner.
agaffney suggested this in the first place, and every time I think
Alec Warner wrote:
I think both our points are that there is a middle ground between
screwing the user outright and holding their hand. If you want to
trumpet the change on forums, on www, on -announce, get the message out
there; then I'd be more for a change like that. The problem is last
Olivier Crete wrote:
It was chosen by brad_mssw to match the way it is done on ia64. And I
think we should continue to put the binary
app-emulation/emul-linux-x86-* in /emul/ and that lib32 should be
reserved for properly installed packages using portage whenever we
manage to get portage to
Mike Frysinger wrote:
On Thursday 10 August 2006 15:42, Kevin F. Quinn wrote:
More generally we have varying approaches to pre-built packages;
app-office/openoffice-bin installs to /usr for example, while
mail-client/mozilla-thunderbird-bin and www-client/mozilla-firefox-bin
install to /opt.
Jason Wever wrote:
This could allow for us to get rid of the nofoo use flag nomenclature
that folks have been doing for functionality that is highly suggested to
be on by default.
So would just adding it to make.defaults ... people using -* deserve
what they get, if they don't pay attention.
Ciaran McCreesh wrote:
Uh, no it wouldn't. Part of the reason we have no* flags is to avoid
dep problems. Consider:
USE=!foo? ( some_unavailable_on_x86_package )
versus:
USE=nofoo? ( some_unavailable_on_x86_package )
The nofoo flag can be use masked. The foo flag can't. This patch
Wolfram Schlich wrote:
Any comments or thoughts about this?
Read the comments here: http://lwn.net/Articles/193107/
In the future, please don't double-post to subscriber-only lists, very
few people can reply to both.
Thanks,
Donnie
signature.asc
Description: OpenPGP digital signature
W.Kenworthy wrote:
My personal opinion is that whilst things like modular X are good for
developers, they are not so good for users - particularly gentoo users.
Definitely not true. The X.Org 7.1 release shared the vast majority of
packages with 7.0, so there were very few upgrades -- just a
Zac Medico wrote:
I've written a patch [1] that implements support for use.force and package.use.force as originally
described by Sven Wegener [2] over a year ago. Basically, this feature is the exact opposite of
use.mask and package.use.mask. It forces USE flags to be enabled. The only way
For ebuilds that use USE_EXPAND to pull in other dependencies rather
than just internally building drivers (I suspect xorg is the only one),
I've been thinking of a way to make the whole setup cleaner.
agaffney suggested this in the first place, and every time I think about
it, it seems like a
Roy Marples wrote:
Seeing as this requires discussion according to make.defaults
The rt2x00 cvs driver supports various RT wireless chipsets and the user
should be able to control which one gets installed. This is also important as
the cvs portion of a specific driver may break over time.
Kevin F. Quinn wrote:
On Wed, 02 Aug 2006 12:00:56 +0200
Thierry Carrez [EMAIL PROTECTED] wrote:
Excerpt from the metastructure model, chosen by the majority of devs
last year (and not my model):
[...]
* It may have one or many leads, and the leads are selected by the
members of the
Enrico Weigelt wrote:
BTW: could be introduce an separate (optional) masking method
for such proprietary stuff ?
I personally don't want to have such stuff on my system, but I'm
really too lazy for check each package I intend to install by
its own.
Would also be cool to have database
Lance Albertson wrote:
I think the point a lot of people are concerned about are packages that
contain libraries or other dependencies that reside in the sunrise tree.
There's a good chance that a package in the regular tree will link
against a package from sunrise, the user will have no idea or
I've masked net-im/aim, AOL's proprietary offering. It hasn't seen a
release in years, it's binary-only, and it's far less capable than any
other client out there.
I'll remove it in 30 days, or whenever I remember it's still there.
Thanks,
Donnie
signature.asc
Description: OpenPGP digital
Robert Cernansky wrote:
If I have some application that is not included in portage why
I decide to make an ebuild? Because I hope that then it will be
accepted and included to portage, so maintained by developers (big
thanks for this). If I have to take care of package + ebuild +
Henrik Brix Andersen wrote:
On Wed, Jul 12, 2006 at 11:11:01PM +0200, Jakub Moc wrote:
Uh... Sorry but it's pretty hard to imagine something more annoying than
an ebuild that dies after a couple of hours compile just because
upstream decided to rename Changelog.txt to ChangeLog.txt and noone
Donnie Berkholz wrote:
With the help of Brian Harring, we've now got a check for unported
packages. It indicates 207 unported packages, of which 93 can
potentially be fixed by stabilizing newer versions and pulling unported
ebuilds from the tree.
Having fun again here ... I've made a list
Richard Fish wrote:
I have to say I dislike allowing this backdoor method to set CFLAGS,
as they won't show up in emerge --info or emerge -pv pkg. You'd
have to see the actual build output to see the nasty flags, which you
might not even think to ask for if a package builds fine but crashes
With the help of Brian Harring, we've now got a check for unported
packages. It indicates 207 unported packages, of which 93 can
potentially be fixed by stabilizing newer versions and pulling unported
ebuilds from the tree.
I've uploaded the list [1]. Run `grep potentially
Molle Bestefich wrote:
Ok, so status is that I have xorg-x11-7.0, I don't have 6.9,
no packages actually wants xorg-x11-6.9, but whenever I use
emerge -D world, Portage sees it as a blocker anyway.
Is there a piece missing in this puzzle, in particular the one that
will tell me why on earth
Diego 'Flameeyes' Pettenò wrote:
On Thursday 06 July 2006 13:40, Donnie Berkholz wrote:
How will you handle non-gcc compilers?
We don't support any, to start with.
But ICC I'm pretty sure behaves like GCC, and whatever else we'd go by
supporting should likely do the same.
But again, we
Ned Ludd wrote:
On Thu, 2006-07-06 at 04:40 -0700, Donnie Berkholz wrote:
Diego 'Flameeyes' Pettenò wrote:
echo | $(tc-getCC) ${CFLAGS} -dM -E - 2/dev/null
Thoughts? Comments?
How will you handle non-gcc compilers?
Non gcc compilers have never been supported and probably never
Mike Frysinger wrote:
can someone remind me why our arch USE flags are in an opt-out system
rather
than opt-in ? instead of adding things like:
dmi
icc
mmx
svga
...
to every non-x86 profile, why dont we mask these things in base/use.mask and
then un-mask them in default-linux/x86 ?
Curtis Napier wrote:
Two names I see missing from this (otherwise very good) list are Chris
Gianelloni (wolf31o2) and Donnie Berkholz (spyderous aka dberkholz). I
think everyone knows exactly how much work these two put into Gentoo and
how valuable that contribution is. Their knowledge would
Mike Frysinger wrote:
well it's about that time of the year ... time for nominating people
for the next Gentoo Council
for the quick low down:
- nominations are from July 1 through July 31
- anyone can nominate
- only Gentoo devs may be nominated
so get with the nominating
Robin H. Johnson wrote:
When FEATURES=mirror, and you try to fetch, it does indeed contain unevaluated
USE flags. However for FEATURES=-mirror, the content of it is correct - no USE
flags at all.
Maybe a two-part solution is in order here then:
1. Change portage behavior regarding the value
Enrico Weigelt wrote:
Hi folks,
maybe I've found a problem in the init.d stuff:
It seems that /var/lib/init.d/started/* is blindly trusted,
instead of actually checking if some service is running.
For example, ntpd cannot be restarted via its init.d script
if it died for some reason -
Robin H. Johnson wrote:
If you have an ebuild with a non-standard pkg_nofetch, please ensure
that you use $SRC_URI instead of $A!
This is because if you have FEATURES=mirror or FEATURES=cvs, attempts to
download all of the source files for digesting or verification will hit
pkg_nofetch and
Ryan Hill wrote:
Donnie Berkholz wrote:
My options are either missing important announcements or creating this
list. I would prefer the list.
What important announcements are you expecting to find at the bottom 50-100
posts of random relevance? The announcements are at the top, being
Luis Medinas wrote:
There's a problem with this. A few packages i listed could be part of
sci-crystallography too. If we start this new category we should had a
few more related packages otherwise we will have this category empty.
Another thing is who is really insterested in creating this
Donnie Berkholz wrote:
I encourage other architectures to stabilize modular X. AMD64, you will
want to go with 7.0 because you also have binary drivers. All other
archs will want to go with 7.1. The modular X package list [2] will help
with this.
- I'm offering to stable any interested arch
Donnie Berkholz wrote:
- If you stable your own arch, please also keyword xev and luit in
addition to the various deps of virtual/x11, xorg-x11 and xorg-server.
One other thing I forgot to mention -- stable xproto 7.0.5, not 7.0.7.
stable: libX11 1.0.1 = xproto 7.0.5
~arch: libX11 1.0.3
Wernfried Haas wrote:
earlier today i updated my box (without reading the guide because i
haven't gotten this mail yet), and apart from one problem because of
not deleting some files as mentioned in the guide, all went fine.
I also noticed (and someone correct me if i'm wrong here) the smart
Thomas Cort wrote:
On Fri, 30 Jun 2006 12:28:30 -0700
Donnie Berkholz [EMAIL PROTECTED] wrote:
- I'm offering to stable any interested arch for 7.1. PPC, SPARC and
MIPS have already taken me up on this. I will be starting this very soon
(within 2 hours at most), so respond ASAP if you would
Stuart Herbert wrote:
On 6/25/06, Donnie Berkholz [EMAIL PROTECTED] wrote:
This topic has come up in the past, and I'd like to revive it once
again. The gentoo-dev list has gotten a lower and lower signal to noise
ratio over the past year or two, and it's difficult to dig out the stuff
that's
Chris Gianelloni wrote:
- Create a new list (gentoo-core-announce ?)
Reading: dev-only
Posting: dev-only, reply-to set to gentoo-core
This is the reference list of things (policy, decisions and discussions
in progress) all developers must know about.
Agree with -(core|dev)-announce.
- Keep
Simon Stelling wrote:
Right. So you agree with the intention, but not with the wording. This
is exactly what I'm after. At least here in Europe, judges have to
'interprete' the law. They judge whether somebody is guilty or not based
on the _intentions_ that are behind the law. If the law has
Lars Weiler wrote:
Another upgrade for 2006.1 might be Xorg-7.1. ppc does not
rely on any binary-driver which is affected by the
ABI-change. This version of X has been tested by several
developers and found to be stable. But we need to check
Donnie's opinion about that move.
A
Luca Barbato wrote:
Edward Catmur wrote:
Critic 4
* Conflicts between contributors (social): Alice adds an ebuild; Bob
makes a (maybe obvious) change; Alice thinks the change is incorrect,
and, feeling that the ebuild is her property, reverts the change. A
revert war erupts. Many casualties.
This topic has come up in the past, and I'd like to revive it once
again. The gentoo-dev list has gotten a lower and lower signal to noise
ratio over the past year or two, and it's difficult to dig out the stuff
that's truly required reading.
I propose that all need-to-know announcements and
Ned Ludd wrote:
I would be in favor of a gentoo-dev-announce list if it allowed me
to unsubscribe from this list.
Sure, if you want to just accept any decisions rather than participate
in making them. The -dev-announce list should be for finalized
decisions. It should be too late to dispute
Mike Doty wrote:
It is devrels place to attempt to stop the fighting. This is what I
did. I clearly indicate that this is temporary and when the council is
willing to clear this nonsense up, it will supersede anything I put
forth yesterday.
I agree that it is devrel's place to help people
Joshua Nichols wrote:
Umm maybe it's just to early in the morning, but I don't see
anything in the logs regarding using bugzilla for overlays not on
overlays.gentoo.org. I only see references to sunrise specifically, not
a blanket statement for all non-overlays.gentoo.org overlays
Or
Alec Warner wrote:
I believe that jakub finds this devrel decision a step out of bounds
(not sure if anyone else detected the that in his statement) and saying
that to the java folks is moreso a way of pointing out just how silly it
is :) I mean if he was serious, he would have addressed the
Mike Frysinger wrote:
On Thursday 22 June 2006 00:54, Alec Warner wrote:
Specifically net-misc/vnc
i'll fix this up if no one else does since it is a pretty friggin critical
package for too many people (myself included), but i'd really really prefer
someone else to do it
Not really,
Mike Doty wrote:
All-
We've had a discussion about sunrise and have reached a compromise.
Someone will summarize it later, I've attached the raw logs for now.
Until the council makes a firm decision about non-gentoo hosted
overlays, this will be the defining method of dealing with them.
Kevin F. Quinn wrote:
On Tue, 20 Jun 2006 16:14:08 -0700
Donnie Berkholz [EMAIL PROTECTED] wrote:
Mike Owen wrote:
From this user's perspective, simple is better. qt3 and qt4 as use
flags are completely and utterly obvious as to what they mean, and
there is no confusion about them. Adding
George Shapovalov wrote:
середа, 21. червень 2006 03:46, Diego 'Flameeyes' Pettenò Ви написали:
On Wednesday 21 June 2006 03:34, Donnie Berkholz wrote:
OK, so we can add qt3 to make.defaults.
-* says nothing to you? :)
Now I am confused:
My understanding of that proposal was that qt3
Kevin F. Quinn wrote:
The goal is to avoid a double-flag combo to do a single thing. qt
always and only affects the _best_ available qt interface for that
package. qt# affects only _older_ available qt interfaces for that
package.
OK; so with this we're not providing a way to get an only
Stefan Schweizer wrote:
Why you ask? Because a user does not care if packageX uses qt3 or qt4, he
just wants to use it.
But why do we have two useflags then?
Because the user should be able to disable optional support for either qt3
or qt4 or both for every package.
There's a significant
Josh Saddler wrote:
With all the talk about forums and comments, that got me thinking: Heck, why
not
just have it posted to the forums? That way it and the comments can be viewed
by
the general public, but if you want to comment, you can just use your existing
forum account. No additional
Henrik Brix Andersen wrote:
On Tue, Jun 20, 2006 at 03:11:38PM -0400, Caleb Tennis wrote:
I would personally like to stay with just the qt use flag. The use flag
will be for support of whichever version of Qt is supported (v3 or v4) for
the particular emerge.
I would like a single 'qt' USE
Kevin F. Quinn wrote:
Problems with having 'qt' to mean latest and 'qt3' as specifically
version 3 include:
1) Target package depends on build system (assuming 'qt' is interpreted
as 'qt3' if only that is installed, rather than pulling in qt4 if not
already present).
What? There will still
Mike Owen wrote:
From this user's perspective, simple is better. qt3 and qt4 as use
flags are completely and utterly obvious as to what they mean, and
there is no confusion about them. Adding a plain qt flag in there
brings back the gtk/gtk2 mess that we've presumably been trying to
avoid in
Diego 'Flameeyes' Pettenò wrote:
On Wednesday 21 June 2006 00:52, Donnie Berkholz wrote:
Yes, you will need to introduce a qt4 flag as upstreams
port packages to qt5, if they choose to also retain a qt4 frontend.
You're trying to compare gtk to qt directly. They are not the same.
gtk regards
Diego 'Flameeyes' Pettenò wrote:
On Wednesday 21 June 2006 02:12, Donnie Berkholz wrote:
I disagree with this and agree with Caleb's earlier suggestion.
Presumably he has some clue what he's talking about when it comes to qt.
I suppose he has, that does not mean that I don't have any at all
Diego 'Flameeyes' Pettenò wrote:
I am talking about qt. Maybe I wasn't clear enough, I was thinking of KDE
users, that are, casually, the main users of Qt-related stuff.
In this particular issue, KDE (3) users are the main part, they need poppler
and other stuff built for Qt 3. There are
Diego 'Flameeyes' Pettenò wrote:
On Wednesday 21 June 2006 03:34, Donnie Berkholz wrote:
OK, so we can add qt3 to make.defaults.
Firulì Firulà (sounds of whistling in Italy at least)
-* says nothing to you? :)
Sure it does, but -* has always been unsupported and users are on their
own
Thomas Cort wrote:
What is the proper quoting style for using epatch? In the tree there
are about 3 different styles...
epatch ${FILESDIR}/some-fix.patch # used by 7326 ebuilds
epatch ${FILESDIR}/some-fix.patch# used by 3092 ebuilds
epatch
Dan Meltzer wrote:
According to the devmanual [1]
A herd is a collection of developers who maintain a collection of
related packages
are you sure you are using the correct term?
[1]
http://devmanual.gentoo.org/general-concepts/herds-and-projects/index.html
I guess it needs to get fixed,
Henrik Brix Andersen wrote:
As I've said all along - I do not have any problems with Project
Sunrise. I have a problem with it being an official project hosted on
*.gentoo.org, as I fear most users will think hey, it's official,
it's hosted on *.gentoo.org - it can't be that bad. Judging from
Last year right after LWE August, Corey set up a 1-day Gentoo developer
conference. Is anyone who's attending LWE going to pick up the ball, now
that he's gone?
Much of the information is supposedly on the devwiki [1], but it's
somewhat broken right now. The infra folks are working on fixing that
Jakub Moc wrote:
Donnie, pingy! ;) Just a friendly reminder to run the script again, so
that we can do a last attempt on fixing the remaining stuff before
resorting to more drastic solutions...
Yeah, it's on my list, but I've got family here all weekend so no time
to work on stuff.
Thanks,
Henrik Brix Andersen wrote:
While I do think this proposal is much better than the previous
non-existing proposal, it still doesn't address the problem of having
the sunrise overlay hosted on a non *.gentoo.org address to make it
100% clear to the public that it is unsupported.
It's no more
Henrik Brix Andersen wrote:
On Sat, Jun 10, 2006 at 01:13:36PM +0100, Christel Dahlskjaer wrote:
To take an example, there were made up quotes in my GWN interview,
however, nothing of great harm. I believe that time it was a case of
attempting to make it more fun, it is however a worrying
Chris Gianelloni wrote:
With an overlay: search sunrice.gentoo.org for the package (no, I don't
know category/name), sync that directory (no, I'm not syncing the whole
sunrice tree), check it over, note some mistakes, compile it if I feel
OK with it, it fails, I fix it - and what then? Where
Chris Gianelloni wrote:
The truth is that we don't ever want to become like the binary
distributions. We don't want to have to have separate
client/server/common/devel as it removes many of the advantages that
Gentoo has. The default should *always* be to install the package as it
was
Chris Gianelloni wrote:
Not policy (I don't think) but current accepted practice.
Should this become a policy?
I'd say so, since this discussion regularly comes up again, and how we
do it is really an expression of the Gentoo philosophy and our
differences from a typical binary distribution.
Chris Gianelloni wrote:
Initially, yes. What happens once the user gets complete access to the
repository, though? Are we going to be keeping people from adding
packages without bugs?
Absolutely. This is for maintainer-wanted stuff, so it should be
documented in Bugzilla and assigned to
Chris Gianelloni wrote:
Since when was overlays.gentoo.org supposed to even be a service to our
users? As I understand it, the goal was to ease development, not to
provide an easy method for half-working ebuilds to make it to our user's
machines.
Our users are our biggest base of testers,
Ned Ludd wrote:
-for conf in ${PN}-${PV}-${PR} ${PN}-${PV} ${PN}; do
+for conf in default ${PN}-${PV}-${PR} ${PN}-${PV} ${PN}; do
Call it 'default' ?
Switch the order around so it's 'default PN PN-PV PN-PV-PR' -- that way
you can have a package-specific setting, and override it for specific
Ned Ludd wrote:
On Thu, 2006-06-08 at 07:49 -0700, Donnie Berkholz wrote:
Ned Ludd wrote:
-for conf in ${PN}-${PV}-${PR} ${PN}-${PV} ${PN}; do
+for conf in default ${PN}-${PV}-${PR} ${PN}-${PV} ${PN}; do
Call it 'default' ?
Switch the order around so it's 'default PN PN-PV PN-PV-PR
Jeremy Huddleston wrote:
I finally had a few free cycles, so I fixed up the eselect-compiler
ebuild to better handle the transition from gcc-config and updated
toolchain.eclass to better work with multilib. I've had a bunch of help
from the amd64 devs/testers/users this past week testing it
Donnie Berkholz wrote:
This aliases g77 to gfortran and gfortran to g77. They are entirely
different compilers and do not accept all the same options. This is
incredibly broken behavior, it masks issues in a number of packages and
creates new issues in many others. Please fix it.
It also
Chris Gianelloni wrote:
No, but the ebuilds are also checked by the team in question, that
actually knows the packages, versus a couple of developers that will be
overworked, dealing with packages that they are completely unfamiliar
with and have no experience with. I just don't see the two
Jakub Moc wrote:
=virtual/x11-7 is hiding breakage in ebuilds that are not ported for
modular X.
I couldn't agree more, but I was forced to add this rather than allow
unported ebuilds to break.
Thanks,
Donnie
signature.asc
Description: OpenPGP digital signature
Jakub Moc wrote:
Olivier Crete wrote:
Is there a recent list of non-ported packages ? Maybe we should do a
last effort to port everything for a week or two and then package.mask
the packages that no one cares enough about to port them.
Hmmm, not a up2date one, AFAIK... There's a tracker bug
Jeremy Huddleston wrote:
I finally had a few free cycles, so I fixed up the eselect-compiler
ebuild to better handle the transition from gcc-config and updated
toolchain.eclass to better work with multilib. I've had a bunch of help
from the amd64 devs/testers/users this past week testing it
Andrew Gaffney wrote:
Rakotomandimby Mihamina wrote:
Hi,
I am trying to install qemu and kqemu, and I run into a problem:
This is a question for the gentoo-user mailing list.
Didn't you notice, he cross-posted to there as well as personally
emailing me. Not something likely to make anybody
Christel Dahlskjaer wrote:
The worry there was whether it would create controversy if they were
hosted with other developer blogs, so we figured we'd host the actual
blogs off-site (should irk less people, although presumably most will
already have external blogs already) and just aggregate
With great pleasure, I announce the testing release of new eselect
modules for BLAS, CBLAS and LAPACK implementations. You may say, But we
already have 'eselect blas' and 'eselect lapack,' Donnie! What are you
thinking? In reply, I would say, The current eselect modules have many
limitations.
One
Ned Ludd wrote:
On Tue, 2006-05-23 at 12:38 +0200, Diego 'Flameeyes' Pettenò wrote:
So, right now virtual/eject is the old-style virtual that gets listed in
virtuals file in the profiles, defaulting to sys-apps/eject that is Linux
only.
Please refrain from adding any new(bad) style
Harald van Dijk wrote:
How does it help? New-style virtuals have several disadvantages, and the
usual advantages of new-style virtuals don't apply here. If it actually
provides real benefits, then no objections from me, but how is this
easier to maintain than a virtual/eject sys-block/unieject
Harald van Dijk wrote:
can't block themselves when only one may be
installed at a time,
This is the one that really annoys me. New-style virtuals are supposed
to make things so easy, but you end up having a ton of crap added to
each provider to block all the others.
Thanks,
Donnie
Mike Frysinger wrote:
On Thursday 18 May 2006 06:41, Paul de Vrieze wrote:
The package sys-apps/paludis is in the wrong category. It is a package
manager on par with rpm, dpkg, etc. Those live in app-arch.
app-arch is for things that manage archives
paludis is much more than an archive
801 - 900 of 1258 matches
Mail list logo
