Re: [gentoo-dev] Re: Gentoo activity graphs

2006-07-09 Thread Philip Webb
060709 Diego 'Flameeyes' Petten? wrote:
 On Sunday 09 July 2006 01:10, Duncan wrote:
 An interesting observation was that of all the FLOSS projects,
 perhaps only Debian had successfully crossed the line
 from medium to large.
 but they have maintainers that often does not know what their work is
 and screw things up very bad: unstable and experimental they call them.

It's a badly neglected aspect of business studies
that there is an optimal size for any organisation, some bigger than others.

In the area of public transport, our own local TTC performs well
only because it has a tradition of very good management  democratic control.
One reason so much of the British railway system was closed 1955-70
was that the unified nationalised (1948) organisation BR was too big
for its management to keep up with, so they dumped all the local bits.
There have been any number of corporate mergers which went too far.

This is an underlying principle of human behaviour which Gentoo should accept
 never measure success by how big it's getting.  Also it sb very careful
how it integrates new devs: mentoring is much more important than tests.

Another basic human need is to take breaks.  Some recent sudden departures
might have been avoided, if devs took regular vacations as an accepted norm.

The average age for Gentoo devs seems to be about 25 ,
which means there's lots of energy, but a bit too little experience.
As someone who's been around longer than that (smile),
I haven't seen anything seriously wrong with the way Gentoo does things.
Open debate, democratic votes  some basic tolerance solve most problems
 the occasional guy who doesn't fit in can be bidden a friendly goodbye.

-- 
,,
SUPPORT ___//___,  Philip Webb : [EMAIL PROTECTED]
ELECTRIC   /] [] [] [] [] []|  Centre for Urban  Community Studies
TRANSIT`-O--O---'  University of Toronto
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Pending Removal of $KV

2006-07-09 Thread John Mylchreest
On Mon, Jun 19, 2006 at 11:13:33AM +, Alec Warner [EMAIL PROTECTED] wrote:
 Portage currently exports $KV as the current kernel version.  We detect 
 this by attempting to mess around with the things in /usr/src/linux 
 (.config, make files, etc...)
 
 This is duplicating the superb efforts of the kernel team and of 
 linux-info eclass.  As such I would like to deprecate $KV in favor of 
 using linux-info eclass.  I don't see the need for portage to export $KV 
 into the environment for all packages.
 
 There are a few packages left that use this.  There will be a tracker 
 bug shortly.  Mostly this mail is just a heads up ;)

I've been after this for quite a long time (I opened a bug but cant seem
to find it) as not only is it horrifically broken, it also should never
have been the job of portage internals anyways.

$KV is currently being exported by linux-info purely for legacy support
and as such I would like to suggest that if these ebuilds inherit
linux-info as well as use $KV, then it should not require any maintainer
changes.

Anything I can do to encourage this move please let me know, and many
thanks for raising this again.

Best Regards,
John

-- 
Role:Gentoo Linux Kernel Lead
Gentoo Linux:http://www.gentoo.org
Public Key:  gpg --recv-keys 9C745515
Key fingerprint: A0AF F3C8 D699 A05A EC5C  24F7 95AA 241D 9C74 5515



pgppBTaSFSiXx.pgp
Description: PGP signature


Re: [gentoo-dev] Re: [gentoo-core] Resignation

2006-07-09 Thread John Mylchreest
On Tue, Jun 27, 2006 at 03:21:49PM +0200, Andrej Kacian [EMAIL PROTECTED] 
wrote:
 On Tue, 27 Jun 2006 13:07:45 +0200
 Enrico Weigelt [EMAIL PROTECTED] wrote:
 
   As I have been swamped with emails, private messages and phone calls
   from certain people, I will retract my resignation for the final time.
  
  I'm fairly new to Gentoo, but I'd like to help.
  So, what shall I do ?
 
 You can start by not hijacking mailing list threads. Or am I the only one
 failing to see how is this connected to Jory's (retracted) resignation ?

Having not yet read the rest of this thread I'm sorry if this is going to 
repeat anything else thats being said, however...

This is a prime example of one of the reasons which is making people
leave gentoo, either as a developer or as a user. Having someone email
to show their appreciation for peoples work and equally as important to
also be willing to commit their own time to help as well being shot down
with such an ignorant comment is upsetting to say the least.

I suggest the next time someone wants to offer their help you think
twice before you flame for off-topic. However, on that note...

Enrico, 

Please find some reading on the subject here:
http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=1chap=2

If you need any further help please feel free to join IRC and ask in
#gentoo-userrel

Best Regards,
John

-- 
Role:Gentoo Linux Kernel Lead
Gentoo Linux:http://www.gentoo.org
Public Key:  gpg --recv-keys 9C745515
Key fingerprint: A0AF F3C8 D699 A05A EC5C  24F7 95AA 241D 9C74 5515



pgpdrA1OgQFtA.pgp
Description: PGP signature


Re: [gentoo-dev] new herd: vdr - topic reanimated

2006-07-09 Thread Matthias Schwarzott
Hi!

As the situation now has changed I would like to discuss this one more.
Since one week we (hd_brummy and me) have changed our Gentoo VDR Project 
(http://www.gentoo.org/proj/en/desktop/video/vdr/index.xml) to an official 
subproject of desktop/video.

Now the situation is as follows:
Most packages have historically either 
a) one of us or
b) both as a maintainer
and the herd media-tv as fallback.
c) The newest ebuilds have herd media-tv and [EMAIL PROTECTED] (projects 
mail-address) as maintainer.


We now think that this should be unified. Our ideal would be having the 
concept of a sub-herd.
The best realizable alternatives we can think of are:
c) herd media-tv and [EMAIL PROTECTED] (projects mail-address) as maintainer.
d) create an own herd vdr.


What do you think of that?

Zzam

-- 
Matthias Schwarzott
Gentoo Developer
http://www.gentoo.org


pgpA9Hp26uXpb.pgp
Description: PGP signature


Re: [gentoo-dev] Off with your heads!

2006-07-09 Thread Daniel Gryniewicz
On Thu, 2006-07-06 at 20:46 -0600, Steve Dibb wrote:
 @devs,
 
 If your blog is being aggregated on Planet Gentoo / Universe, it's time to 
 send 
 us a copy of your smiling face.  I'm putting out a request for some 
 hackergotchis.  Really, you don't want just a few of us to have all the fun, 
 do you?
 

Here's mine.

Daniel


dang.png
Description: PNG image


signature.asc
Description: This is a digitally signed message part


[gentoo-dev] Re: Portage: missing pieces

2006-07-09 Thread Molle Bestefich

Molle Bestefich wrote:

The current situation is very annoying for users that update often,
and also makes Portage mostly unusable for automatic server upgrades


After unmerging mono-tools so Portage could finally run a whole
update, it stopped halfway through because of this bug:
http://bugs.gentoo.org/show_bug.cgi?id=132122

I noticed that several users have commented with a relevant complaint:
GCC-4.x is required by the ebuild, but no information is ever conveyed
to the end user about this fact.  The ebuild does not have a
dependency on GCC-4.x.

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

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'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?
--
gentoo-dev@gentoo.org mailing list



[gentoo-dev] helping out - how?

2006-07-09 Thread Molle Bestefich

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?

(I was thinking that I'd conjure up a patch and submit it here so
someone with commit access can put it in.)
--
gentoo-dev@gentoo.org mailing list



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

2006-07-09 Thread Jakub Moc
Molle Bestefich wrote:
 I noticed that several users have commented with a relevant complaint:
 GCC-4.x is required by the ebuild, but no information is ever conveyed
 to the end user about this fact.  The ebuild does not have a
 dependency on GCC-4.x.

No, it's not. gcc-3.4.x *is* required. That versions (or later) is
*stable* everywhere where xine-lib is stable.


 Try reading the bug - users are basically being shoved off with an
 arrogant silence and a stamp on their forehead saying INVALID.
 
 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.

Dependency on a particular gcc version will solve exactly nothing.
Having that version installed doesn't mean you are really *using* it.
You won't be automagically switched to 3.4.x when upgrading from 3.3.x,
you won't be automatically switched to gcc 4.x when upgrading from 3.4.x

http://www.gentoo.org/doc/en/gcc-upgrading.xml

 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?

How about the you finally upgrade your outdated gcc, as asked over and
over again? gcc-3.3.x is dead, unsupported upstream, we won't be fixing
any bugs there. Hard to understand? Apparently, I guess...

Thanks for your rant.

-- 
Best regards,

 Jakub Moc
 mailto:[EMAIL PROTECTED]
 GPG signature:
 http://subkeys.pgp.net:11371/pks/lookup?op=getsearch=0xCEBA3D9E
 Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95  B30F 8717 D5FD CEBA 3D9E

 ... still no signature   ;)



signature.asc
Description: OpenPGP digital signature


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

2006-07-09 Thread Ciaran McCreesh
On Sun, 09 Jul 2006 21:37:47 +0200 Jakub Moc [EMAIL PROTECTED] wrote:
| Molle Bestefich wrote:
|  I noticed that several users have commented with a relevant
|  complaint: GCC-4.x is required by the ebuild, but no information is
|  ever conveyed to the end user about this fact.  The ebuild does not
|  have a dependency on GCC-4.x.
| 
| No, it's not. gcc-3.4.x *is* required. That versions (or later) is
| *stable* everywhere where xine-lib is stable.

Not true. According to the 2006.0 x86 profile, for example, you're
required to have =sys-devel/gcc-3.3.4-r1. There is no requirement
that 3.4 be installed.

-- 
Ciaran McCreesh
Mail: ciaran dot mccreesh at blueyonder.co.uk


-- 
gentoo-dev@gentoo.org mailing list



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

2006-07-09 Thread Ioannis Aslanidis

You'd rather fill in a bug report and submit the patch in the bug. Not
in this list, definitely.

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?

(I was thinking that I'd conjure up a patch and submit it here so
someone with commit access can put it in.)
--
gentoo-dev@gentoo.org mailing list





--
Ioannis Aslanidis

deathwing00[at]gentoo.org 0xB9B11F4E
--
gentoo-dev@gentoo.org mailing list



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

2006-07-09 Thread Ciaran McCreesh
On Sun, 09 Jul 2006 22:10:48 +0200 Jakub Moc [EMAIL PROTECTED] wrote:
|  Not true. According to the 2006.0 x86 profile, for example, you're
|  required to have =sys-devel/gcc-3.3.4-r1. There is no requirement
|  that 3.4 be installed.
| 
| Yeah, that's not what I've been talking about at all, what's your
| point? I was saying that gcc-3.4 and better is stable everywhere
| where it's needed. How does it change that 3.3 is dead as a nail in a
| lamproom door and users should switch to something that we actually
| can support?

Tradition for toolchain stuff has always been that anything allowed by
the profile is considered acceptable for general use. So, if users
shouldn't be using 3.3, the profile should be changed to say so. Until
then there's no obligation to upgrade.

-- 
Ciaran McCreesh
Mail: ciaran dot mccreesh at blueyonder.co.uk


-- 
gentoo-dev@gentoo.org mailing list



[gentoo-dev] Re: Portage: missing pieces

2006-07-09 Thread Molle Bestefich

Jakub Moc wrote:

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

 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.

Dependency on a particular gcc version will solve exactly nothing.
Having that version installed doesn't mean you are really *using* it.
You won't be automagically switched to 3.4.x when upgrading from 3.3.x,
you won't be automatically switched to gcc 4.x when upgrading from 3.4.x


Yes ok.  So the user has to both merge the new version, and switch to it.

Either way, the end user is not getting told what should be done,
instead Portage just breaks, which is exactly what all the complaints
are about.


How about the you finally upgrade your outdated gcc, as asked over and
over again? gcc-3.3.x is dead, unsupported upstream, we won't be fixing
any bugs there. Hard to understand? Apparently, I guess...


I've never been told so, I have no clue what you are talking about.


Thanks for your rant.


What kind of reply do you expect to get from such crap?
Thanks for being an asshole?
--
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



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

2006-07-09 Thread Molle Bestefich

Ioannis Aslanidis wrote:

You'd rather fill in a bug report and submit the patch in the bug.
Not in this list, definitely.


Oh, ok.  Never mind then, I fear I'd be spending way too much time
fighting with Jakub trying to get the ebuild in the tree.  I'll just
drop it.

(Nothing personal, I just don't think it would work out, heh.)
--
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



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

2006-07-09 Thread Denis Dupeyron

Dear devs,

In bug #139412, I ask Paul de Vriese why he thinks python should die
on --fast-math instead of just filtering it. Here's his answer :

Denis, quite simple. -ffast-math is broken and short-sighted for a global flag.
Filtering gives the shortsighted message that it works globally, while it is
not suited for any package not specifically tested for it. As it breaks python,
dieing makes people understand that it does not work on python. It is better
than the alternative of not looking for it at all.

This, for me, triggers 3 questions that are gentoo-dev@ material :

1) Should all ebuilds that currently filter --fast-math die on its
presence instead of filtering it ?

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

3) Suppose that -ftracer, for example, is one of those, and knowing
that enabling -fprofile-use enables -ftracer, shouldn't ebuilds also
die on use of -fprofile-use ? It's only an example, this situation
will exist for other pairs of flags.

The hidden question behind these three is : shouldn't we have a
something that enables us to safely handle this kind of situations ?
Like some kind of system- and/or architecture-wide flag mask that
could be overriden by the ebuild and/or the user (at his own risk) ?
This could potentialy reduce the number of bugs that poor old bugzie
has to cope with, and simplify ebuild writing and maintenance.

If we already have such a thing, I'm sure you guys know where the
cluebat is... But in any case, questions 1), 2) and 3) still need to
be answered.

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



[gentoo-dev] Re: Portage: missing pieces

2006-07-09 Thread Molle Bestefich

Richard Fish wrote:

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.


I don't see how that information is conveyed to the user.  Portage
shouts about upgrading to a new profile from time to time, but it
never tells anyone to upgrade GCC.  Perhaps it should, if that's what
the devs expect people to do.


The devs can *not* be expected to verify that all software in portage
builds with all versions of gcc in portage.


Of course not.


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.


Yes, ok.  That's a bad alternative.  Thus it seems that there's no
appropriate mechanism to handle new GCC versions in Portage, which
again makes sense wrt. the complaints.


 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?


Nothing?
I find it unacceptable that the bug is marked INVALID when it clearly
describes a relevant issue.

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

You could perhaps argue that the issue started out as why do I get
this error message and ended up being why doesn't Portage handle GCC
upgrades gracefully, which is of course a slightly different thing.
But it should be clear to anyone reading the bug what the real issue
is.  I'm even willing to bet that if I create a new bug describing the
Portage issue, with no mention of the specific xine ebuild, it will
get closed as a duplicate of this bug anyway.  I've got case studies
proving that this is what happens, heh.


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


If that would enable ebuild maintainers to flag xine as requiring 3.4
for compilation, then that would definitely solve the issue described
in the bug.  I'd say that's _very useful_ to the end user.

You could argue that only a couple of people has spent the time to
create a bugzilla login and lodge a complaint in the bug, but there's
probably more out there.  We can count the duplicates in a couple of
months and see ;-).  And as newer GCC features are used throughout,
the situation will probably happen more in the future.


 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.


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.
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Last rites for some CD/DVD-recording applications

2006-07-09 Thread Daniel Drake

Lars Weiler wrote:

app-cdr/dvdrtools: Same reason.  No need to use this fork of
  cdrtools-1.11...


This is a lot more more than a add DVD writing support fork - they 
have changed much more than that, and they have an interesting list of 
objectives. It's a much saner version of cdrtools.


Please don't remove it unless you have confirmed with upstream that they 
have lost interest and nobody is developing it.


Daniel



--
gentoo-dev@gentoo.org mailing list



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

2006-07-09 Thread Michael Cummings
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Molle Bestefich wrote:
 Ioannis Aslanidis wrote:
 You'd rather fill in a bug report and submit the patch in the bug.
 Not in this list, definitely.
 
 Oh, ok.  Never mind then, I fear I'd be spending way too much time
 fighting with Jakub trying to get the ebuild in the tree.  I'll just
 drop it.
 
 (Nothing personal, I just don't think it would work out, heh.)
Nonsense. Jacub's a big pussy cat who gets stressed out a bit and needs
a vacation ;) Does the package your thinking of have a specific category
set (for instance, maybe unmaintained specifically, but falls under a
broad category that the bug could go to?).

As others have (and will) comment, posting patches on this is flamebait
of the worst kind. Hope to see you on bugzie, I know I for one welcome
bugs that come with their own patch solutions :)

- --

- -o()o--
Michael Cummings   |#gentoo-dev, #gentoo-perl
Gentoo Perl Dev|on irc.freenode.net
Gentoo/SPARC
Gentoo/AMD64
GPG: 0543 6FA3 5F82 3A76 3BF7  8323 AB5C ED4E 9E7F 4E2E
- -o()o--
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.4 (GNU/Linux)

iD8DBQFEsYFjq1ztTp5/Ti4RAkrvAJ9P0fEqHkyLszQ1w+SB/5NM2iD2VACffyjs
7fPxvNbvDql3O8VyOBkOwJw=
=yGyY
-END PGP SIGNATURE-
-- 
gentoo-dev@gentoo.org mailing list



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

2006-07-09 Thread Josh Saddler
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Ciaran McCreesh wrote:
 On Sun, 09 Jul 2006 22:10:48 +0200 Jakub Moc [EMAIL PROTECTED] wrote:
 |  Not true. According to the 2006.0 x86 profile, for example, you're
 |  required to have =sys-devel/gcc-3.3.4-r1. There is no requirement
 |  that 3.4 be installed.
 | 
 | Yeah, that's not what I've been talking about at all, what's your
 | point? I was saying that gcc-3.4 and better is stable everywhere
 | where it's needed. How does it change that 3.3 is dead as a nail in a
 | lamproom door and users should switch to something that we actually
 | can support?
 
 Tradition for toolchain stuff has always been that anything allowed by
 the profile is considered acceptable for general use. So, if users
 shouldn't be using 3.3, the profile should be changed to say so. Until
 then there's no obligation to upgrade.
 

Then it seems like that 2006.0 x86 profile should be updated (without waiting
for 2006.1 to be released). Dunno if other arches have to run such legacy gcc
versions, but the logical thing is to point to 3.4.x instead on x86.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2.2 (GNU/Linux)

iD8DBQFEsYLBrsJQqN81j74RAidcAKCGdhpAiObclSZuwR8Heod1wqK9yQCgmI16
ax6u8GA7z9GQEkdqErq8xD4=
=0VzK
-END PGP SIGNATURE-
-- 
gentoo-dev@gentoo.org mailing list



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

2006-07-09 Thread Molle Bestefich

 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.


There's already an existing but unmaintained ebuild.
That's what I wanted to check out, so I could modify it and submit a diff -u.
--
gentoo-dev@gentoo.org mailing list



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

2006-07-09 Thread Michael Cummings
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Molle Bestefich wrote:
  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.
 
 There's already an existing but unmaintained ebuild.
 That's what I wanted to check out, so I could modify it and submit a
 diff -u.

What's in cvs is what you --sync to your desktop. You just need to
submit the patch on bugs.g.o - there is nothing more in cvs than what
you get when you emerge sync ('cept maybe timeliness of your mirror)

- --

- -o()o--
Michael Cummings   |#gentoo-dev, #gentoo-perl
Gentoo Perl Dev|on irc.freenode.net
Gentoo/SPARC
Gentoo/AMD64
GPG: 0543 6FA3 5F82 3A76 3BF7  8323 AB5C ED4E 9E7F 4E2E
- -o()o--
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.4 (GNU/Linux)

iD8DBQFEsYgzq1ztTp5/Ti4RAp01AJ9i12x6rWQ1ENUHvBE7T4nKKhzUMQCggQ5M
oSCqQEhtOsXAKPO1IyBTOjI=
=9EeP
-END PGP SIGNATURE-
-- 
gentoo-dev@gentoo.org mailing list



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

2006-07-09 Thread Ryan Hill
Denis Dupeyron wrote:

 In bug #139412, I ask Paul de Vriese why he thinks python should die
 on --fast-math instead of just filtering it. Here's his answer :
 
 Denis, quite simple. -ffast-math is broken and short-sighted for a
 global flag.
 Filtering gives the shortsighted message that it works globally, while
 it is
 not suited for any package not specifically tested for it. As it breaks
 python,
 dieing makes people understand that it does not work on python. It is
 better
 than the alternative of not looking for it at all.

Ebuilds shouldn't die on anything according to the non-interactive portage
philosophy.  I don't know how official that philosophy is though.

 This, for me, triggers 3 questions that are gentoo-dev@ material :
 
 1) Should all ebuilds that currently filter --fast-math die on its
 presence instead of filtering it ?

No, that would be a major pain in the ass for anyone wanting to use -fast-math,
which does have legitimate uses.

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

There's a million, and they're constantly changing.  For example,
-frename-registers is generally safe on GCC 3.4, broken in 4.0, and enabled by
default on 4.1.

 3) Suppose that -ftracer, for example, is one of those, and knowing
 that enabling -fprofile-use enables -ftracer, shouldn't ebuilds also
 die on use of -fprofile-use ? It's only an example, this situation
 will exist for other pairs of flags.
 
 The hidden question behind these three is : shouldn't we have a
 something that enables us to safely handle this kind of situations ?
 Like some kind of system- and/or architecture-wide flag mask that
 could be overriden by the ebuild and/or the user (at his own risk) ?
 This could potentialy reduce the number of bugs that poor old bugzie
 has to cope with, and simplify ebuild writing and maintenance.

Users playing with CFLAGS get to keep the pieces.  Trying to dummy-proof the
system doesn't help anyone but the dummies. ;)

--de.



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] new herd: vdr - topic reanimated

2006-07-09 Thread Luca Barbato
Matthias Schwarzott wrote:
 What do you think of that?

c is simpler. I like it.

lu

-- 

Luca Barbato

Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero

-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Off with your heads!

2006-07-09 Thread George Prowse

On 09/07/06, Daniel Gryniewicz [EMAIL PROTECTED] wrote:

On Thu, 2006-07-06 at 20:46 -0600, Steve Dibb wrote:
 @devs,

 If your blog is being aggregated on Planet Gentoo / Universe, it's time to 
send
 us a copy of your smiling face.  I'm putting out a request for some
 hackergotchis.  Really, you don't want just a few of us to have all the fun, 
do you?


Here's mine.

Daniel


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.4-ecc0.1.6 (GNU/Linux)

iD8DBQBEsUpeomPajV0RnrERAua3AJsEph/EP9EWa977KpeZVnkrz/wYeQCdFajI
l2+K9sqkqkMkzTifNf4D4EU=
=nIE2
-END PGP SIGNATURE-



Could we have a localised one like Gnome as well?

http://www.uk.gnome.org/planet/
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] new herd: vdr - topic reanimated

2006-07-09 Thread Diego 'Flameeyes' Pettenò
On Monday 10 July 2006 02:25, Luca Barbato wrote:
 c is simpler. I like it.
Yes, of course if _all wranglers_ respected metadata, instead of stopping to 
herd tag and assigning to that even when a particular maintainer is listed.

-- 
Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/
Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE


pgpe2GF5WZw0k.pgp
Description: PGP signature


Re: [gentoo-dev] new herd: vdr - topic reanimated

2006-07-09 Thread Robin H. Johnson
On Mon, Jul 10, 2006 at 04:36:55AM +0200, Diego 'Flameeyes' Petten?? wrote:
 On Monday 10 July 2006 02:25, Luca Barbato wrote:
  c is simpler. I like it.
 Yes, of course if _all wranglers_ respected metadata, instead of stopping to 
 herd tag and assigning to that even when a particular maintainer is listed.
Actually, this isn't that simple at the moment. There are packages that
directly list me as the maintainer, but I want bugs for them assigned to
the herd by default - so that the other folk in the herd can find them
quickly.

Perhaps this could be alleviated with an explicit assign-to field in
package metadata? At the same time, it should have an explicit cc-to
field, for cases where the maintainer is not in the herd.

-- 
Robin Hugh Johnson
E-Mail : [EMAIL PROTECTED]
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85


pgpgAFtIKpWNk.pgp
Description: PGP signature


[gentoo-portage-dev] glsa-check wrong

2006-07-09 Thread Radoslaw Stachowiak

glsa-check returns  errorlevels 255 which results in shell being
unable to parse it (anything greater 255 is 0).


--- /usr/bin/glsa-check.orig2006-06-03 15:29:37.0 +0200
+++ /usr/bin/glsa-check 2006-07-09 19:29:36.0 +0200
@@ -223,6 +223,8 @@
   if verbose:
   sys.stderr.write(emergecmd+\n)
   exitcode = os.system(emergecmd)
+   if exitcode  255:
+   exitcode = exitcode  8
   if exitcode:
   sys.exit(exitcode)
   myglsa.inject()


--
radoslaw.
--
gentoo-portage-dev@gentoo.org mailing list



Re: [gentoo-portage-dev] glsa-check wrong

2006-07-09 Thread Paul Varner
On Sun, 2006-07-09 at 19:34 +0200, Radoslaw Stachowiak wrote:
 glsa-check returns  errorlevels 255 which results in shell being
 unable to parse it (anything greater 255 is 0).

I've opened Bug #139804 to track this.

Regards,
Paul

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