Re: [gentoo-dev] [RFC] Ideas for projects...

2007-01-11 Thread Richard Fish

On 1/11/07, Chris Gianelloni [EMAIL PROTECTED] wrote:

The Gentoo Council is looking for some ideas for some small projects
that we could initiate that would help Gentoo.


My idea would be to extend emaint to check package.keywords and
package.use for obsolete flags, unnecessary atoms (like foo-1.2 in
keywords when foo-1.3 is stable), atoms that don't match any current
ebuild, and so on.

-Richard
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] [RFC] Ideas for projects...

2007-01-11 Thread Richard Fish

On 1/11/07, Bo Ørsted Andresen [EMAIL PROTECTED] wrote:

On Friday 12 January 2007 05:43, Richard Fish wrote:
 My idea would be to extend emaint to check package.keywords and
 package.use for obsolete flags, unnecessary atoms (like foo-1.2 in
 keywords when foo-1.3 is stable), atoms that don't match any current
 ebuild, and so on.

app-portage/eix already does a lot of this...


Sigh.  I can't keep up with these changesnevermind :-(

-Richard

--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Re: udev coldplugging and /etc/init.d/modules

2006-12-01 Thread Richard Fish

On 12/1/06, Sven Köhler [EMAIL PROTECTED] wrote:

Will udev rename the card eth1 to eth0 and the card eth0 to eth1?


Yes.

For this, I'd recommend running /lib/udev/write_net_rules
all_interfaces and then edit
/etc/udev/rules.d/70-persistent-net.rules to set the names like you
want.

I'd also recommend moving this thread to gentoo-user, since this
really doesn't have much to do with gentoo development AFAICS.

-Richard

--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Re: Versioning the tree

2006-11-29 Thread Richard Fish

On 11/29/06, Stuart Herbert [EMAIL PROTECTED] wrote:

Hi,

On 11/29/06, Bo Ørsted Andresen [EMAIL PROTECTED] wrote:
 Maybe you should read the replies you got the first time you made this claim
 on this list [1].

Many thanks for these links.  I didn't see your original email.


Wanna add a comment here: :-)

http://bugs.gentoo.org/show_bug.cgi?id=141904

-Richard

--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] The (lack of) use of herds

2006-10-29 Thread Richard Fish

On 10/28/06, Marius Mauch [EMAIL PROTECTED] wrote:

Well, I'd go further and question the whole herd concept.


It also gives users the impression that there is an entire team of
people maintaining a package,when in fact it might be just one or two
people.

-Richard
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] RC_STRICT_NET_CHECKING or the net dependency

2006-10-21 Thread Richard Fish

On 10/21/06, Roy Marples [EMAIL PROTECTED] wrote:

RC_STRICT_NET_CHECKING is used in the init script depdency process, and quite
frankly I'd like to punt it and replace it with ... rc-update! Yes,
just put the init scripts that net should provide in your runlevel. boot
contains net.lo by default and we also coldplug any net devices by default
too.

So can anyone think of any reasons why I cannot punt it?


What becomes the equivalency of the none or no settings?  In
particular, if I have both wlan and eth0, but rarely at the same time,
and I want net to be satisfied by either of them,
RC_STRICT_NET_CHECKING=no accomplishes this.

-Richard
--
gentoo-dev@gentoo.org mailing list



[gentoo-dev] Need guidance for updating CHOST

2006-09-12 Thread Richard Fish

With the stabilization of the nptl-only glibc-2.4, many users are
finding out that they installed their systems with
CHOST=i386-pc-linux-gnu, and now need to either mask the new glibc, or
figure out how to change their CHOST.

I am not able to find any official guide on changing CHOST, and the
information on the wiki and forums is, well, confusing at best.

What I've basically been telling people is to:

1. update chost
2. run /usr/portage/scripts/bootstrap.sh
3. emerge -e system
4. emerge -e world

But I don't have any great confidence that these instructions will
work, and that someone won't end up needing to boot from their live CD
to fix or re-install their systems, as I've never had to change CHOST
myself.

http://article.gmane.org/gmane.linux.gentoo.user/169894

So I really want to know what the official position is on CHOST
changes, and whether the above instructions are reasonable.  Obviously
I'm looking specifically at i386-i686, and not i*86-x86_64.

If we could get something in to GWN on this, that would be great.

-Richard
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Need guidance for updating CHOST

2006-09-12 Thread Richard Fish

On 9/12/06, Mike Frysinger [EMAIL PROTECTED] wrote:

On Tuesday 12 September 2006 22:23, Richard Fish wrote:
 What I've basically been telling people is to:

please god stop telling people that

ive given Wernfried Haas proper instructions, he just needs to write them up


Is there a Readers Digest version you can give the userreps so we
can at least answer the question properly when it comes up?

-Richard
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Re: Democracy: No silver bullet

2006-09-04 Thread Richard Fish

On 9/3/06, Luis Francisco Araujo [EMAIL PROTECTED] wrote:

Richard Fish wrote:
 The problem I see is that for Gentoo the releases are not really
 useful milestones for most projects.  A release is really significant

That is not a problem. That is a feature.


A small clarification may be necessary here.  I wasn't pointing to a
problem with the way Gentoo evolves, but with the idea that releases
could be useful milestones for project roadmaps.

-Richard
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Re: Democracy: No silver bullet

2006-09-04 Thread Richard Fish

On 9/3/06, Chris Gianelloni [EMAIL PROTECTED] wrote:

I really wish people would take the time to either ask the Release
Engineering team, or learn how we work before they go off making
accusations against us.


There was no accusation there.  I picked on X only for its popularity
and relative ease of upgrading.  But it is fair to say that I have no
clue how releng actually works, and how you choose what to put in the
snapshot, although I expect that there is much more to it than picking
a random date on the calendar.

-Richard
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Re: Democracy: No silver bullet

2006-09-02 Thread Richard Fish

On 9/2/06, Wiktor Wandachowicz [EMAIL PROTECTED] wrote:

I suppose that there is a way that Gentoo can follow, only that its leaders,
developers and users need to see it clearly. Is there a publicly visible
page that contains current goals for new releases? Where all sub-project
leaders could add their own goals, coherent with the general vision?
I couldn't find it, but maybe I haven't looked in the right places?


The problem I see is that for Gentoo the releases are not really
useful milestones for most projects.  A release is really significant
for a few core packages, but what is the real downside for users if
Xorg 7.2 is stabilized one week after a release?  Outside of the fact
that they have to compile it themselves instead of using the GRP
package...not much that I see.

For a distro like Ubuntu, a release is very significant, as it is the
platform that users will be running for the next 6-18 months.

Do you think Ubuntu roadmaps would be useful without being tied to a
release?  Or could project status reports (as discussed here recently)
fit the same bill?


Maybe I should raise such concerns to the User Representatives first


No, definitely not.  The point of user reps (of which I am one) is not
to filter communications between devs and users, but to improve the
communications between the two camps, among other things.  If you want
to bring an idea up here directly, nobody should respond with talk to
your userrep.

-Richard
--
gentoo-dev@gentoo.org mailing list



[gentoo-dev] Why can't I re-open this bug??

2006-08-12 Thread Richard Fish

http://bugs.gentoo.org/show_bug.cgi?id=67179 is marked
RESOLVED/WORKSFORME, which according to the descriptions means that I
should be able to re-open the bug.  But there is no option to do so.
Why?

-Richard
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] use.force as a complement to use.mask in profiles

2006-08-10 Thread Richard Fish

On 8/9/06, Brian Harring [EMAIL PROTECTED] wrote:

General problem with use deps; *could* still implement it via
seperating out use specific restrictions and generating the second
logic statement above, but that's bit magic imo.


Is it really magic?  Admittedly I know exactly nothing about portage
internals, but it seems to me that use-specific restrictions and
version-specific restrictions are two completely separate concepts,
and that you have to deal with them separately, regardless of whether
you put the directives all in the same file or not.

I see the normal case for gcc being something like:

sys-devel/gcc[-cxx]

=sys-devel/gcc-5.0


The above is very clear and obvious to me...all versions of gcc should
be built with USE=cxx, and you should not try = version 5.0.  If you
tried to combine those two concepts into a single directive, you would
end up with:


=sys-devel/gcc-5.0[-cxx]


and I can think of at least 3 useful and logical interpretations of
that single statement.  This is quite different than the same token in
an [R]DEPEND, where only one sane interpretation exists.

So in fact I think that in the context of masking/unmasking packages,
you must deal with the version and use flag masking separately.  You
should not even allow the combined syntax form, since it is so
ambiguous.

And if you do that, then the unmasking of use-specific or
version-specific masks becomes quite obvious.  Placing
sys-devel/gcc[-cxx] in package.unmask has no effect on the
_versions_ of gcc that are masked, as it isn't a version-specific
directive.

-Richard
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Re: mulltiib cruft: /emul

2006-08-09 Thread Richard Fish

On 8/9/06, Mike Frysinger [EMAIL PROTECTED] wrote:

i asked some others and they didnt get the e-mail either ... looks like our
gentoo mail server is really starting to crash here ...


http://bugs.gentoo.org/show_bug.cgi?id=141904

-Richard
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] use.force as a complement to use.mask in profiles

2006-08-08 Thread Richard Fish

On 8/8/06, Jason Wever [EMAIL PROTECTED] 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.


Which would be fantastic IMO.

-Richard
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] gtk1 vs. gtk2

2006-08-08 Thread Richard Fish

On 8/7/06, Simon Stelling [EMAIL PROTECTED] wrote:

What sort of problems? An example backing up your claims would be very nice.


While I don't agree with Enrico that splitting up slotted packages is
the right thing to do, there  are some corner cases involving slots
that portage (more specifically, depclean) doesn't deal with very
well.

http://thread.gmane.org/gmane.linux.gentoo.user/166809/focus=166809
http://bugs.gentoo.org/show_bug.cgi?id=67179

-Richard
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Proposal for advanced useflag-syntax

2006-08-08 Thread Richard Fish

On 8/8/06, Enrico Weigelt [EMAIL PROTECTED] wrote:

I think, modularized Xorg, as we have today, is far much better
than the old monolithic thing.


I think you are failing to realize that this isn't something that
Gentoo did on it's own.  Upstream went to separate packages, and
Gentoo followed.  Again, this is perfectly in line with build what
$upstream expects philosophy.

-Richard
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Re: Re: Re: Masking practics

2006-08-07 Thread Richard Fish

On 8/7/06, Enrico Weigelt [EMAIL PROTECTED] wrote:

To be fair, do *you* actually look through *all* the emerge
output if there's any D flag, without the risk of overlooking
it someday ?


Um, sorry, but users *should* be looking at the output of --pretend to
get an idea of what portage wants to do to their systems.  And not
just for the 'D' either.


Why can't emerge shout out some more verbose text ? Something
really eye-catching ?


Please don't.  Portage already has enough messages that try to be eye
catching.  I've only got two eyes after all...

-Richard
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] gtk1 vs. gtk2

2006-08-07 Thread Richard Fish

On 8/7/06, Enrico Weigelt [EMAIL PROTECTED] wrote:

The assumption is wrong, gtk1 and gtk2 are incompatible versions
of one library. They are completely different libraries, where
one originally had been forked off the other one. Now they look
similar, but are in no ways equal.


Have you actually visited http://www.gtk.org??!  The 2.0 release
announcement, the migration guide, the download page, pretty much
everything makes it clear that gtk2 is the newer version of the _same_
library, not a completely different project.  Indeed, even their CVS
repository only has a gtk directory, not gtk1 and gtk2.

-Richard
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Resignation

2006-08-01 Thread Richard Fish

On 8/1/06, Carsten Lohrke [EMAIL PROTECTED] wrote:

And that's why it has been announced as the best since sliced bred - urging
all users to give it a try, but with the option to point with the finger on
them, laughing Ha, ha, you should have known dumb nuts., later. Brett is
absolutely right with his previous emails.


Nothing that I have read about sunrise, either in GWN, their project
pages, or the FAQ, has given me the impression that they are urging
all users to give it a try.  There is certainly some advertising
about it, as would be appropriate for any new Gentoo project.  But
nothing that I would say gives the slightest hint of pushiness.

-Richard
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Re: aging ebuilds with unstable keywords - how can we help?

2006-07-27 Thread Richard Fish

On 7/27/06, Chris Gianelloni [EMAIL PROTECTED] wrote:

Honestly, they shouldn't be stable.  In fact, likely, many shouldn't be
in the tree.  We have way too many packages that are used solely by a
small group of people sitting around the tree.  These would be better
served in official overlays, where they can be maintained by the
interested parties (including users), rather than in the tree.


This might be a good idea.  I think some additional tools support
would be useful, so that things like esearch could find things in the
official overlays that are not actually present on the user's system.


The majority of packages are also the ones that need more extensive
testing.  Sure, we could probably stabilize a bunch of the fringe
packages that hardly anyone uses and it wouldn't affect anything.


The majority of Aliz's database seems to be made up of these fringe
packages.  Many of which are stable on at least one arch already, or
have only a single version in the tree anyway.  Stabilizing these on
the remaining archs that they support should not have any significant
impact on the perceived overall quality of Gentoo.


Another problem is that we don't *know* what is being run by our users.
This is something that the Summer of Code project for a Gentoo Stats
project should at least help with, as it will give us an insight into
what is actually being used and what isn't.


I hope that all users subscribe to this, it will only be useful with a
large enough pool of people submitting their stats.  It would also be
great if Aliz's database incorporated this information when it becomes
available.


Seriously, folks.  If you think that packages should be available
faster, run ~arch.  Test the packages.  Report successes/failures to the
maintainers.  File stabilization bugs if your favorite package hasn't
had another bug in 30 days and you've been using it.  Basically, help
out, rather than sitting back and complaining.  Complaining helps
nobody.


Please don't interpret my original message as a complaint.  It isn't.
It is mostly a question of the process.  My understanding of
stabilization bugs was that they should be the exception, not the
rule...


that you might not be able to make a commitment, or even want to do so.
However, every single bug report that you file *is* helping out... and
every little bit helps.


...and I was wrong.

Regards,
-Richard
--
gentoo-dev@gentoo.org mailing list



[gentoo-dev] aging ebuilds with unstable keywords - how can we help?

2006-07-26 Thread Richard Fish

On 7/2/06, Daniel Ahlberg [EMAIL PROTECTED] wrote:

Hi,

This is an automatically created email message.
http://gentoo.tamperd.net/stable has just been updated with 15968 ebuilds.


A question [1] has come up on -user about why some ebuilds take so
long to become stable for an arch.  This isn't the old when will we
have KDE yesterday.3am type question.  In reviewing the above
database, and the OP, it looks like a fair number of ebuilds that
could/should be stable are not.

Of particular concern to me are packages that:

a) have no open bugs.
b) are marked stable on some archs, but not others.
c) may have only a single version available in portage.

As an example, consider net-analyzer/etherape, which is ~amd64 ppc
sparc x86, and has no open bugs (other than a version bump request),
and only a single version available in portage to begin with.

So my question is: is there anything that interested users can do to
help here?  I know we can file stabilization bugs, but I agree with
Robert [1] that this should not be necessary in the normal case.
Besides, do you _really_ want 16,000 new bug reports that say nothing
more than blah/foo works for me, please stabilize!  Is the problem a
lack of time, devs, arch testers, or interested users?

Regards,
-Richard

[1] http://thread.gmane.org/gmane.linux.gentoo.user/166565/focus=166565
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Re: Portage: missing pieces

2006-07-10 Thread Richard Fish

On 7/9/06, Molle Bestefich [EMAIL PROTECTED] wrote:

As far as I can tell, the complaints are about Portage being unable to
handle GCC upgrades gracefully for end users.


The thing is, that portage doesn't technically handle gcc upgrades.
The user really needs to do that, and they (should) know to do that
when they see the new version show up in an emerge -Duv world.  Or
on GWN.

Ok, so some users are not getting that message.  To be honest, I have
no idea what to do about that.  Having dozens (hundreds?  all?)
ebuilds check for a minimum version of gcc doesn't seem very
effecient.  I guess portage could check and warn about an unsupported
version of gcc being selected for the system compiler, but then I we
have to figure out exactly what the supported versions are, and
exactly when a version becomes unsupported, as a matter of policy.

But that won't even fix the problem.  The version of xine-lib that
this bug refers to is a ~x86 version.  Should that be expected to
compile with the stable gcc?  Or only with the ~x86 gcc.  What if the
maintainer doesn't intend to stabilize the package until the ~x86
version of gcc goes stable?

So I don't think the issue is as simple as either having xine-lib put
out a warning about a particular gcc version, as that doesn't work in
the general case.  And putting the checks in portage doesn't seem to
work very well either.

The system as it is now actually seems to work about right...the vast
majority of stable users upgrade to new versions of gcc as they come
out, hopefully following the upgrade guide, and never see anything
fail to build due to the gcc version.  Others get informed via other
means, and hopefully remember for the future.


That won't be necessary.  Things mostly works, and when they don't,
users file a bug like the aforementioned one, which should result in
that particular ebuild getting fixed, instead of the bug being marked
INVALID.


The thing is, this particular ebuild isn't actually broken.  Or I
guess if it is, then so are some_potentially_large_number other
ebuilds in the tree, since they probably won't build with old gcc
versions either.  Ok, most would probably build with gcc 3.3.  And
maybe even gcc 3.1.  But 2.95??  Handling this at the ebuild level is
just not a good solution for the general case.

-Richard
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Dying on some CFLAGS instead of filtering them.

2006-07-10 Thread Richard Fish

On 7/9/06, Denis Dupeyron [EMAIL PROTECTED] wrote:

2) If yes, are there any other flags that ebuilds should die on ?


My (user) opinion is that ebuilds should not die on CFLAGS, at least
not until per-package CFLAGS are implemented.

Now if someone is crazy enough to enable -ffast-math globally or
specifically for python in that situation, well, die, spin the cpu fan
backwards, melt the hard disk down and sell it for scrap, whatever you
want!

-Richard
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Dying on some CFLAGS instead of filtering them.

2006-07-10 Thread Richard Fish

On 7/10/06, Ned Ludd [EMAIL PROTECTED] wrote:

per pkg cflags are here already it would fall under the per
pkg env variables.


Please forgive my stupidity, but the only place I could see to set a
env var per package was /etc/portage/bashrc.  Is that what you are
referring to?

-Richard
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Re: Portage: missing pieces

2006-07-10 Thread Richard Fish

On 7/10/06, Molle Bestefich [EMAIL PROTECTED] wrote:

Richard Fish wrote:
 of gcc doesn't seem very effecient.

I can't see why it would not be efficient?


I think it is an inefficient use of developer time.  Do we really want
gentoo devs spending their time figuring out what the minimum gcc
version is for their packages, and then having very similar code
duplicated in every ebuild in the tree?  Is the problem really so
serious that it requires that much effort?

I am not saying that there should never be a check for a minimum gcc
version...maybe if a large enough population of users is having a
problem with a particular package because of gcc, then that package
_should_ have a check with an appropriate stop using obsolete gcc
versions message.  But it should only be done in response to bug
filings, and at the discretion of the package maintainer.

And let's remember that this is a ~arch package.  The expectations of
people using ~arch is higher than for the stable tree.  Indeed, you
would probably see a completely different response if this was a
problem using the ~x86 gcc to build the ~x86 xine-lib.


 And putting the checks in portage doesn't seem to work very well
 either.

I fail to see how a test in the ebuild for the active
GCC compiler version wouldn't work?


But that isn't putting a check in portage, it is adding it to the ebuilds.


 The system as it is now actually seems to work about right... the
 vast majority of stable users upgrade to new versions of gcc as they
 come out

I'd think that most users hadn't even run into this problem (yet),


Agreed...


because many source code maintainers strive to be able to compile with
as old a version of GCC as possible..


or alternatively, because most users upgrade gcc to the current
version before running into such problems.

-Richard
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Re: Portage: missing pieces

2006-07-10 Thread Richard Fish

On 7/10/06, Molle Bestefich [EMAIL PROTECTED] wrote:

It shouldn't even be _necessary_ to create bugs and receive advice
from a living, breathing human being just to perform a system update.


It isn't necessary.  -user, the forums, IRC, all are monitored by
living, breathing human beings.

-Richard
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Dying on some CFLAGS instead of filtering them.

2006-07-10 Thread Richard Fish

On 7/10/06, Zac Medico [EMAIL PROTECTED] wrote:

Richard Fish wrote:
 On 7/10/06, Ned Ludd [EMAIL PROTECTED] wrote:
 per pkg cflags are here already it would fall under the per
 pkg env variables.

 Please forgive my stupidity, but the only place I could see to set a
 env var per package was /etc/portage/bashrc.  Is that what you are
 referring to?

You're close.  There is now a per-package bashrc implementation included in 
$PORTDIR/profiles/base/profile.bashrc.  It's kind of silly imo, when the user 
can simply put that same code in /etc/portage/bashrc, but this is how it is. :)


Ah, thanks, I see it now.

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
randomly later.

-Richard
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Dying on some CFLAGS instead of filtering them.

2006-07-10 Thread Richard Fish

On 7/10/06, Simon Stelling [EMAIL PROTECTED] wrote:

Sounds like your after bug 95741:
http://bugs.gentoo.org/show_bug.cgi?id=95741


Yeah, that would be nice! :-)

-Richard
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Re: Portage: missing pieces

2006-07-09 Thread Richard Fish

On 7/9/06, Molle Bestefich [EMAIL PROTECTED] wrote:


Try reading the bug - users are basically being shoved off with an
arrogant silence and a stamp on their forehead saying INVALID.


*Sigh*.  You really should post to -user first.

The expectation here is that when a new version of gcc is stabilized,
that users will upgrade to that in a reasonable amount of time, and
use that (by selecting it with gcc-config) for compiling all new
updates.  FYI, gcc-3.4.4-r1 was stabilized on 2-Dec-2005, and the
current stable is 3.4.6-r1 since May 29th.

The devs can *not* be expected to verify that all software in portage
builds with all versions of gcc in portage.  For example, there is
still an ebuild for gcc-2.95.3!  But that is _not_ to be used for
compiling new updates.

The alternative here is that old versions of gcc disappear from
portage, but that causes a problem for those who need those versions
for some reason, such as compiling non-gentoo software.


Nothing personal against Jakub Moc who probably has a lot to do, but
the handling of relevant issues raised in the bugzilla is just
unacceptable.


What, exactly, do you find unacceptable in Your gcc version is
outdated and unsupported?

I suppose portage could be enhanced to have a
is_gcc_version_supported() check, but I'm not sure how useful that
would be.


What's the state of Portage and Gentoo in general?  Is there not
enough hands to do a proper job?  Or is it just that none of the devs
see what's wrong because bugs are wrongly being closed marked
INVALID such as the above when they're in fact not?


If you want to test compiling every version of every package in
portage with all 21 versions (16 if you assume all -rX versions are
compatible, or /only 9/ if you only consider stable x86 versions) of
gcc that are currently in portage, and submit patches when things
fail, go ahead.  BTW, your patches cannot remove the ability to use
improvements that are only available in newer stable versions of gcc,
such as -fvisibility=hidden.

-Richard
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] helping out - how?

2006-07-09 Thread Richard Fish

On 7/9/06, Molle Bestefich [EMAIL PROTECTED] wrote:

I'd like to take a stab at maintainership (or at least fixing) an
unmaintained ebuild.

What versioning system do you guys use (CVS?), and what's the URL for
checking out ebuilds?


bugs.gentoo.org is where this kind of work is done.

-Richard
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Replacing cpu-feature USE flags

2006-07-07 Thread Richard Fish

On 7/7/06, Simon Stelling [EMAIL PROTECTED] wrote:

That's because CFLAGS=-msse currently doesn't do what the user would think it
does. Which is the real problem, which we're solving with the change Diego
suggested.


Well I certainly do *not* expect it to run configure with --enable-sse.

-Richard
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Re: Portage: missing pieces

2006-07-07 Thread Richard Fish

On 7/7/06, Molle Bestefich [EMAIL PROTECTED] wrote:

 Are you using an portage overlay?  If so, what is in it?

No.  No idea what that is.  Sounds interesting, though.


It is a local portage tree with ebuilds that you have either written
yourself or downloaded from others.  Since the overlay will override
what is in portage, you can easily get yourself into trouble this way.
So it is not really recommended unless you *really* know what you are
doing!


[nomerge  ] dev-util/mono-tools-1.1.11
[ebuild  N]  dev-dotnet/gecko-sharp-0.6
[nomerge  ]   www-client/mozilla-1.7.13


*Sigh*.  What a mess.  Unfortunately the Gentoo dev's have taken the
rather unusual step of _breaking the tree_ due to a security problem.
And from what I understand [1], mozilla is going to be package masked
today (if it hasn't already), so the block messages should go away,
but you'll get even worse no package to satisify messages.

At this point your choices are fairly limited, and neither one is very good.

1. Unmerge both mono-tools and gecko-sharp.  Mono-tools requires
gecko-sharp, and that requires mozilla.  You can use equery files
mono-tools to see what you will lose by going this route.

2. Manually unmask mozilla (and probably mono-tools and gecko-sharp)
to keep them around.  This might work, but I think you're going to be
jumping through a lot of hoops to try and avoid seamonkey.

-Richard

[1] http://bugs.gentoo.org/show_bug.cgi?id=137665
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Replacing cpu-feature USE flags

2006-07-06 Thread Richard Fish

On 7/6/06, Diego 'Flameeyes' Pettenò [EMAIL PROTECTED] wrote:

Right now we have mmx, 3dnow, 3dnowex, sse, sse2 and so on useflags present in
the tree, almost never used to get new dependencies, but usually used to
supply econf switches.


Hoping the S/N ratio here hasn't gotten too high...

IMO the main purpose of USE flags should be econf switches.  Pulling
in dependancies should be viewed as more of a side-effect, even if a
common one.  If the user wants ./configure ... --enable-gtk, then
they need gtk on their box.

Similarly, the mmx,sse,3dnow,etc useflags should be there for econf
switches, not additions to CFLAGS.  If the autoconf script has an
--enable-mmx option, then the proper way to control that is through a
useflag.

I don't object to ebuilds adding CFLAGS/CXXFLAGS based on the result
of your has_cpuset (for example, --fpmath= could be useful), but I
don't believe has_cpuset should be used to set econf switches.

And users should absolutely not have to muck with bashrc to disable
this.  Add a FEATURE, or something, to enable/disable it if necessary.

-Richard

--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Re: Portage: missing pieces

2006-07-06 Thread Richard Fish

On 7/6/06, Molle Bestefich [EMAIL PROTECTED] wrote:

Evolution depends on Mozilla and Mono depends on SeaMonkey.


I don't think this is right, at least not for what is currently in
portage.  When I do a

USE=mono emerge -Devp evolution

No mozilla comes in.  So evolution does not depend on mozilla, at
least not directly.

In fact, in the current portage tree, mozilla is going away, and being
replaced by seamonkey.  Very few (and hard masked) packages like
gecko-sdk still depend on mozilla.  So what you should eventually end
up with is no mozilla but seamonkey.


So I'm stuck here.
Is it impossible to have Mono and Evolution installed at the same time?


No, it is certainly possible, as I have both on my system.

Are you using an portage overlay?  If so, what is in it?

When was the last time you did an emerge --sync?

Also, the full output of emerge -Duvpt world would still be useful
for us to see.

-Richard
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] bugzilla 2.22 masked ~x86

2006-07-05 Thread Richard Fish

On 7/5/06, Enrico Weigelt [EMAIL PROTECTED] wrote:

Okay, if this short question cannot be anwered with an short help
or an direct pointer to some help, it seems my contribution obviously
isn't wanted. So I won't waste anymore of your and my time on this
topic and don't file a bug. Just forget about it.


He did give you a pointer to some help: just click on the hyperlinks
to see a description.  All the help/documentation you need should be
on the bug entry form.  Click on Component (the link, not the list),
and the help indicates it should be set to Applications.  Platform is
x86 (duh!).Priority, Severity, OS, etc are all explained right
there.  Assign to will be [EMAIL PROTECTED] (based on metadata.xml
and Joshua's mail).

If you still aren't sure what a stabilization bug looks like, you
could search bugzilla for stabilize and get lots of examples.  Or
ask on -user.

-Richard
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Re: Re: Re: Re: [ANNOUNCE] Project Sunrise - Gentoo User Overlay

2006-06-10 Thread Richard Fish

On 6/9/06, Peter [EMAIL PROTECTED] wrote:


Firstly, I think it is very clear that anything in sunrise is experimental
or not supported in the main gentoo tree. That's fine! I don't think any
user who goes through the trouble to set up an overlay would miss that
point. You can't go to o.g.o and not see the disclaimers. And, anyone who
goes through the trouble to svn the overlay, edit make.conf, etc., would
not be an ignorant newbie (no disrespect to newbies intended). Anyone who
fetches the sunrise overlay would know exactly what he/she intends to do
and why. Much different than emerge --sync with keyword x86.


Recently on -user there was someone who couldn't build any gnome apps,
because they had an obsolete gnome2.eclass in their overlay.  This
user certainly didn't know enough about portage or ebuilds to be using
an overlay like that.

Besides, users frequently do imprudent things to their systems.  They
will break their systems by unmasking p.masked stuff (I've done this,
so I am in this group), add dangerous CFLAGS based on random forum or
wiki pages, and use ~arch packages and then rant about any bugs that
show up.

As you've already said, having it on a *.gentoo.org domain gives some
people a higher level of comfort with it, regardless of any
dislaimers.

I have no idea what the quality of the sunrise overlay will be, but it
seems likely to be worse than the currently p.masked stuff.  If
getting sunrise is easy enough, and a substantial number of users
start using it, supporting those users could become very difficult.

-Richard
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Re: Re: When will KDE 3.5 be marked as stable?

2006-05-06 Thread Richard Fish

On 5/4/06, Bart Braem [EMAIL PROTECTED] wrote:

What makes us think we can not trust the KDE devs?


1. bugs.gentoo.org
2. bugs.kde.org

I personally have been running KDE 3.5 since the RC days...when you
actually had to add it to package.unmask.  And *yes*, it has had more
than it's share of problems.  Even 3.5.1 had an annoying bug that
caused a kicker segfault every time I logged out.  3.5.2 is the first
3.5 that  seems completely stable.

Honestly, if you want it so badly, add the necessary entries to
package.keywords, merge it, and be happy.  What is this obsession with
pushing the Gentoo devs to mark things stable before they feel it is
right to do so??  Is it just some pointless quest to have a completely
stable system??

-Richard

--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Re: Re: When will KDE 3.5 be marked as stable?

2006-05-06 Thread Richard Fish

On 5/5/06, Philip Webb [EMAIL PROTECTED] wrote:

060504 Chris Gianelloni wrote:
 If we followed others blindly, as so many users suggest,
 then we would have stabilized KDE 3.5 ages ago,
 and every single one of you KDE users would be complaining
 about how our QA sucks because KDE doesn't compile
 or breaks badly in so many places.

This is rubbish: I'm now using 3.5.2  have had no problems whatsoever;
nor did I have problems earlier with 3.5.0  3.5.1 .


Not rubbish.  I had problems.  So did many others.  Fortunately mine
were of the just annoying variety, not of the crap, did I make a
backup last night? kind.  If you don't believe me, take a walk
through bugs.kde.org.  The Gentoo devs have done the right thing by
holding back on stabilizing KDE.

-Richard

--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Re: Re: Re: When will KDE 3.5 be marked as stable?

2006-05-06 Thread Richard Fish

On 5/5/06, Carsten Lohrke [EMAIL PROTECTED] wrote:

All the whining leaves me with the feeling that I'm less interested to work
for you. The question What can I do? I do never hear. Stop whining, but
decide to help or give another distro a try. These are your choices.


Just to try to counter some of the whining, I am sure that most users
do appreciate the work that you do for little glory and even less pay.
And I think you did the right thing by holding off on stabilization
this long.  Yeah, I know, not as good as a how can I help?, but my
day job is keeping me busy with 60 hour weeks atm

Cheers,
-Richard

--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Re: Wishlist: an automated package upgrade system with fine-tunable sysadmin control

2006-04-27 Thread Richard Fish
On 4/27/06, Duncan [EMAIL PROTECTED] wrote:
 In any case, once you get your list and weed out the stuff you /don't/
 want on it, rather than doing that copy trickery, try this:

Yeah, much smarter than my cp tricks.  Although using emerge to
generate the package list will have a problem in that it contains the
versions, which is not what you want for this.  But we seem to have
going completely off-topic for -dev now...

-Richard

-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Wishlist: an automated package upgrade system with fine-tunable sysadmin control

2006-04-26 Thread Richard Fish
On 4/26/06, Kevin [EMAIL PROTECTED] wrote:
 I'd like to have the capability of being able to list some packages that 
 should
 never be upgraded automatically (I realize I can do this to some degree 
 already
 with portage), some others that are very unlikely to break from an automated
 upgrade and thus should always be upgraded automatically, and some packages

So maybe this could be satisified by allowing user-defined categories
of packages beyond system and world?  Something like world, system,
fragile, non-fragile?

I think you could probably implement something like this yourself with
a bit of trickery with the /var/lib/portage/world list.  You could
copy world to non-fragile, remove anything that you consider fragile
from it, and then do an automatic update with:

cp /var/lib/portage/world /var/lib/portage/world.bak
cp /var/lib/portage/non-fragile /var/lib/portage/world
emerge -DNuv world
cp /var/lib/portage/world.bak /var/lib/portage/world

A similar script for the fragile packages would let you update those
as a group, obviously using the -p and/or --ask options as you like.

Going back to -user now...

-Richard

-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] missing ide discs mapping is udev's fault?

2006-02-21 Thread Richard Fish
On 2/21/06, Christian Bricart [EMAIL PROTECTED] wrote:
 Hi,
 So I have /dev/hda through /dev/hdl which are ok. But the mappings to
 /dev/discs/discX with X  7 are missing.

snip


 I wanted to file a bug report, but I'm not certain if it's actually
 udev's fault.

Yes, it is udev's fault, but it is not a bug.  The /dev/discs nodes
were a convention of devfs, and _never_ standard.

From the ChangeLog (there are many other entries BTW):

*udev-064-r1 (31 Jul 2005)

  31 Jul 2005; Greg Kroah-Hartman [EMAIL PROTECTED]
  +files/udev.rules-064-r1, +udev-064-r1.ebuild:
  Start moving to a sane /dev naming scheme.
  This release removes the devfs names for the tty and consolde devices, and the
  symlinks that were implementing the LSB standard names.  We only implement the
  LSB names now, which saves over 3Mb of RAM on /dev.

-Richard

-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] missing ide discs mapping is udev's fault?

2006-02-21 Thread Richard Fish
On 2/21/06, Christian Bricart [EMAIL PROTECTED] wrote:
 And hdparm iterates through /dev/ide/* if found...

I assume you are talking about the init script?  Because my hdparm
binary requires one to specify a device node, there is no iteration...

If so, AFAIK that exists only for those still running devfs.  If
/dev/ide does not exist, it iterates over all devices found by
dev/hd?.

-Richard

-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Re: Bugzilla etiquette suggestions

2006-02-13 Thread Richard Fish
On 2/13/06, Ciaran McCreesh [EMAIL PROTECTED] wrote:
 But... If INVALID is renamed, could we get a new GOAWAY resolution for
 people who really deserve it?

I would tend to agree with this.  I myself was the 'victim' of an
aggressively worded INVALID resolution to a bug report I filed due to
my screwing up an upgrade to java 1.5.  Even though I didn't
particularly /like/ the response, I did learn that:

1. It was my own fault.
2. I needed to be really damn sure about future bug reports,
particularly when I unmask things!

So even if INVALID is watered down to be gentle to new (or easily
offended) users, you do occasionally need to smack abusers or people
who should know better (like me).

-Richard

-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] fix binary debug support, part elevenity billion

2006-01-17 Thread Richard Fish
On 1/15/06, Olivier Crête [EMAIL PROTECTED] wrote:
 Why not use the splitdebug instead of nostrip? And make building with -g
 the default, then tell small HD users how to disable it in the docs. And
 it needs to disable -fomit-frame-pointer at least on x86. I've been
 building my whole system with splitdebug and yes it does take a lot of
 space, but its really useful.

No argument against splitdebug, but my guess is that it would be
useless for 99.97% of users, and would lead to complaints on -user
about how much disk space gentoo consumes compared to insert least
favorite distribution here, so it should not be the default.

-Richard

-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] /sbin /usr/sbin security hole

2006-01-17 Thread Richard Fish
On 1/17/06, Paweł Madej [EMAIL PROTECTED] wrote:
 [EMAIL PROTECTED] ~ $ ls -al /sbin/

Please don't bother the devs with this anymore.  We will be happy to
explain the intricacies of unix permissions on gentoo-user.

-Richard

-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Bug 80905

2005-09-13 Thread Richard Fish

Frank Schafer wrote:


I'm still on the kernel from the life-cd. The self compiled kernel has
the highmem option set to off (I have only 1GB). I'm on x86 Intel
Celeron M and have CHOST set to i686-pc-linux-gnu and CFLAGS=-O2
-march=pentium2
 



Um, why pentium2?  The Celeron-M is the same core as a Pentium-M with 
less cache and lower clock speeds, so it seems to me that your -march 
should really be pentium-m.


Anyway, I'll be back on gentoo-user if you want to discuss this thread 
more there.


-Richard

--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] devfs is dead, let's move on

2005-07-13 Thread Richard Fish
Mike Frysinger wrote:

On Monday 11 July 2005 03:47 am, Martin Schlemmer wrote:
  

On Sat, 2005-07-09 at 20:34 +0200, Richard Fish wrote:


for d in 0 1 2 3; do
/sbin/mdadm --assemble --config=partitions --auto=md
--super-minor=$d /dev/md$d /dev/null 21
done

Maybe something similar will be required in /sbin/rc, like you currently
do for LVM and the device mapper?  It isn't a critical problem
though...I am pretty sure there are only a few Gentoo users who will
ever see this...maybe as few as 1!!!
  

Mike, what do you think?  This viable?  We could maybe add an init addon
for md, and move the lvm/whatever stuff to that as well?



i dont see the point ... ive already fixed raidtools / mdadm to generate 
device nodes before running since udev doesnt do it correctly/at all
-mike
  


Oh, yes, I see that now.  Sorry for the noise.

-Richard


-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] newb question about emerge ...

2005-06-15 Thread Richard Fish
Andrew Muraco wrote:

first of all (some people will disagree with me on this)
  


I will ;-

# emerge -avuDN world
does a much more through job, because it not only checks the packages
you have installed, 


...but only to correct this statement.  It is more accurate to say that
it checks all packages and dependancies of packages in world.  That is
frequently a subset of all installed packages.  Most users won't
understand the distinction though...

Ian, consider this an invitation to come over to gentoo-user and ask us
any questions you have about using Gentoo.

-Richard

-- 
gentoo-dev@gentoo.org mailing list