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

2006-07-10 Thread Kevin F. Quinn
On Sun, 9 Jul 2006 23:30:40 +0200
Molle Bestefich [EMAIL PROTECTED] wrote:

 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.

It's conveyed by the fact that when updating, you see a new compiler
version being installed.  If you have done a world update, you already
have the later compilers installed.

  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.

As has been explained before, as far as the gcc ebuilds are concerned
their job is finished when the new compiler version is installed.  It
is up to the user to decide to change their system compiler.  The
gcc ebuild will switch between minor versions if USE=multislot isn't
specified, and in that case will warn the user about ABI breakage if
relevant, as it requires the user to rebuild lots of stuff.

  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.

Portage and the ebuilds handle it fine.  All that needs to happen is
for users to accept the advice to read the gcc upgrading guide when
they trip over problems that arise from issues with gcc versions.

   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.

Don't take the bug marking as a personal attack - it's a marking for
devs to understand what was the impact of the bug.  Focus on the advice
given, which from what I can see was succinct and correct.

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

What exactly do you expect to happen?  GCC updates don't switch major
versions automatically, because in general it means changing ABI which
means rebuilding everything.  Where ABI breakage occurs between minor
versions and the compiler is switched automatically, the ebuild issues
a warning when ABI breakage occurs and advises what to do to rebuild
affected packages.

 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.

If two bugs describe the same issue, regardless of the summary field
one will get marked as a duplicate of the other.  Again, this is not a
personal attack but information for devs to understand whether
different work is needed for the different bugs.

  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.

The problem with having the xine ebuild check gcc version and aborting
if a certain version is found active, is that if the gcc version is
modified in the future such that xine would then build with it, that
handling would have to come out again.  Since the ebuild dies either
way, the only difference is that some users may not realise that
upgrading gcc will work - in which case they file a bug and they get
told to upgrade gcc - job done.

 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.

Another way of looking at it, is that there are a lot of people out
there who are coping 

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

2006-07-10 Thread Kevin F. Quinn
On Sun, 09 Jul 2006 15:27:14 -0700
Josh Saddler [EMAIL PROTECTED] wrote:

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

I don't believe retro-actively modifying the 2006.0 profile is a good
idea in general. The profile currently says that for x86, gcc
must be =sys-devel/gcc-3.3.4-r1 - if you do

# emerge =sys-devel/gcc-3.3.4-r1

on a current tree you'll get a much higher version.  Still, it's up to
releng if they wish to change it.

-- 
Kevin F. Quinn


signature.asc
Description: PGP signature


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

2006-07-10 Thread Andrew Gaffney

Kevin F. Quinn wrote:

I don't believe retro-actively modifying the 2006.0 profile is a good
idea in general. The profile currently says that for x86, gcc
must be =sys-devel/gcc-3.3.4-r1 - if you do

# emerge =sys-devel/gcc-3.3.4-r1

on a current tree you'll get a much higher version.  Still, it's up to
releng if they wish to change it.


Even if you modify the profile to mask gcc-3.3.x, it won't force people to 
unmerge their existing gcc-3.3.x since it's slotted and they would already have 
gcc-3.4.x emerged, correct? And if we can't force them to unmerge it, we can't 
force them to switch which gcc version is active. Masking in the profile would 
have no effect if this is true.


--
Andrew Gaffneyhttp://dev.gentoo.org/~agaffney/
Gentoo Linux Developer   Installer Project
--
gentoo-dev@gentoo.org mailing list



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

2006-07-10 Thread Kevin F. Quinn
On Sun, 9 Jul 2006 19:17:09 +0200
Matthias Schwarzott [EMAIL PROTECTED] wrote:

 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.

A package can belong to more than one herd.  So you could create a
media-vdr herd, and have two herd tags in the metadata.xml for the vdr
packages; media-tv and media-vdr (I suggest the media- prefix as it's
not necessarily obvious what vdr means on its own).  If you do this,
make sure there's a maintainer tag.

However (c) seems to be the most sensible approach.

 
 
 What do you think of that?
 
 Zzam
 


-- 
Kevin F. Quinn


signature.asc
Description: PGP signature


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

2006-07-10 Thread Ioannis Aslanidis

On 7/10/06, Robin H. Johnson [EMAIL PROTECTED] wrote:

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.


My idea would actually be the contrary: that the package is assigned
to its maintainer (who could not be in the herd) and the herd(s) are
CCed. Uven if the maintainer is in the herd, this procedure should be
followed, as it is easier for the maintainer to track down the
package.

--
Ioannis Aslanidis

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



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

2006-07-10 Thread Jakub Moc
Robin H. Johnson wrote:
 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.
 

Well, that reminds me - just stick [EMAIL PROTECTED] (or whatever else) to
maintainer field then and put it first, enough of a hint for me :)



-- 

jakub




signature.asc
Description: OpenPGP digital signature


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] Re: Portage: missing pieces

2006-07-10 Thread Jakub Moc
Richard Fish wrote:
 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

Well yeah, there's nothing broken w/ the ebuild. And xine-lib is _not_
the only thing that just bombs out on sucky compiler version, see fex.
http://bugs.gentoo.org/show_bug.cgi?id=121501

There's no sane way to force users to switch their gcc version, so
messing w/ ebuild deps, profiles or keywords of outdated gcc versions
won't help...



-- 

jakub




signature.asc
Description: OpenPGP digital signature


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

2006-07-10 Thread Ned Ludd
On Mon, 2006-07-10 at 01:34 -0700, Richard Fish wrote:
 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.

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


-- 
Ned Ludd [EMAIL PROTECTED]
Gentoo Linux

-- 
gentoo-dev@gentoo.org mailing list



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

2006-07-10 Thread Duncan
Denis Dupeyron [EMAIL PROTECTED] posted
[EMAIL PROTECTED], excerpted
below, on  Sun, 09 Jul 2006 23:24:24 +0200:

 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.

As a user active on the lists/groups (and the same would go for forums),
and opposing both Ryan Hill's and Richard Fish's opinions, I absolutely
agree with Paul on this!

My reason for doing so is that I've seen users say they use it with no ill
effects they can see on their system.  Of course, we know that's because
where it has caused problems enough to bug, it has been filtered, but
obviously the users don't know that, or are *relying* on it, *not* a good
idea IMO.

If ebuilds start dying on it, those users will soon see how many things it
/does/ break, and should quickly change their minds.

 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 ?

I'd say yes -- provided there's documentation (say a bug where removing it
cured the bug) that it's an actual problem with that package.  If a
maintainer has put the filterflag in simply peremptorily, as I'd argue
this particular flag might warrant, that's a different question.  IMO,
that would be counterproductive, since a user simply removing the die,
redigesting, and continuing, would have likely convinced himself of the
safety of that flag.

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

I'd say very few, keeping in mind portage's non-interactive philosophy (as
Ryan mentioned).  Very few are /that/ profoundly stupid, and require
someone hit the practitioner upside the head with a cluebat.

 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.

Given the rarity of a flag as extreme as -ffast-math, I'd say that
shouldn't normally be the case.  Do note that -ffast-math is itself a
meta-flag, enabling several others.  I'd /not/ recommend dying on the
individual flags, thereby giving those that would use -ffast-math /that/
way to do so if they /insist/ on it -- and have read the documentation
well enough to know about it.

 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.

I'd favor a USE_EXPAND type flag that could take several I'm broken so
don't file bugs type strings, which could be individually tested for in
the various ebuilds (and/or profiles), while at the same time grouping
them automatically for purposes of emerge --info and therefore bug
reports.

amd64 tests for such IM_BROKEN type vars in their development profiles
(would be 2006.1 for example ATM), and I believe gcc tested for (and may
still) a similar var during part of the 4.0 process, where users agreed
not to file bugs unless they came with patches. Having these all in the
same place, perhaps as individual values of a
PORTAGE_I_DELIBERATELY_CHOOSE_TO_BE_BROKEN var or the like, where emerge
--info would report it yet ebuilds/profiles could test for the presence of
individual strings, would be a very good thing IMO.  A function or two
could then be added to eutils to aid in standardizing the testing for such
strings and encourage use of the standard grouping.

If that or a similar solution is chosen, then one such string could be
created for -ffast-math.  Once that was done, a test for that string could
be set in profiles/base or the like, setting up the test for -ffast-math
system-wide, whereupon it could be eliminated from the individual ebuilds.
That would also provide a suitable single-shot environment based solution
for the user, as well, in the case they wanted to override the system test
for an individual ebuild.

-- 
Duncan - List replies preferred.   No HTML msgs.
Every nonfree program has a lord, a master --
and if you use the program, he is your master.  Richard Stallman

-- 
gentoo-dev@gentoo.org mailing list



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

2006-07-10 Thread Denis Dupeyron

On 7/10/06, Ryan Hill [EMAIL PROTECTED] wrote:


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


Correct me if I'm wrong, but this has nothing to do with being
interactive or not. To me, an ebuild that dies (intentionally or due
to a build error) isn't interactive at all.


 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.


If a package is known not to work with a certain flag, being able to
emerge it won't change the fact that it doesn't run. Plus, if the
solution is considered good for python, I don't understand why it
wouldn't be good for any other package. Are you saying that Paul's
proposition of having the python ebuild die on use of --fast-math
isn't good ? If yes, why ? And what is your better idea ?


 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.


Which is exactly the reason why we could benefit of something that
enables us to manage this in a clean and safe way. I'm not saying I
have a candidate for that something, but I wanted to discuss if
there was an interest in it.

Let's take again the example of -ftracer which can be enabled by the
-fprofile-use meta-flag. Imagine we have a mechanism somewhere (again,
the reason I'm being vague is that my point isn't to discuss
implementation just yet) that adds -fno-tracer to CFLAGS. In this
case, you're covered wether -ftracer was added directly on indirectly
by fprofile-use, which actually simplifies the number of flags that
you need to blacklist. Thus ebuilds don't have to take care of it,
bugs don't pour into bugzie, and Jakub can avoid overheating.


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


I'm one of those devs who care for our users. I think it's dangerous
to try and categorize users in, for example, dummies and non-dummies,
as you say. Who are we to judge this or that user is a dummy ? Plus,
we all are the dummy of somebody else.

Anyway, I was thinking more in terms of making the job of developers,
bug wranglers, and poor old bugzilla easier, cleaner, safer. How many
bugs do we have that are due to dangerous flags ? How much time and
effort could we save if we didn't have those ? Also, I was thinking
that if a good solution was found to deal with a dangerous flag in a
certain package, maybe it was a good idea to extend this solution to
other packages. And finally, if said solution becomes common, maybe
it's a good idea to make it system-wide with a possibility to override
the setting by the user or the ebuild. It seems we already have
per-package CFLAGS, so part of this, at least, is already implemented.


On 7/10/06, Richard Fish [EMAIL PROTECTED] wrote:


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


Why ? Stating your opinion without any justification isn't really
constructive. And same as above : being able to emerge a package that
won't run doesn't help you more.


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!


Same as above again, replace 'dummy' with 'crazy'.

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



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

2006-07-10 Thread Patrick McLean
Denis Dupeyron wrote:
 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 ?

I don't think we should die on anything, if a user wants a particular
CFLAG, generally the default should be to let them use it. A warning
with a pause may also suffice.

Currently the amd64 profiles do some testing for broken USE flags. If
the user has flags that gcc will not accept (ie errors out with invalid
command line option), our profile.bashrc will filter them out
completely. If they have a flag that is on a list of pre-defined bad
flags it will warn the user about the flag and sleep for 5 seconds.
-- 
gentoo-dev@gentoo.org mailing list



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

2006-07-10 Thread Ciaran McCreesh
[ resending this, the original appears to have been eaten. ]

On Sun, 9 Jul 2006 23:24:24 +0200 Denis Dupeyron [EMAIL PROTECTED]
wrote:
| 1) Should all ebuilds that currently filter --fast-math die on its
| presence instead of filtering it ?

http://devmanual.gentoo.org/ebuild-writing/functions/src_compile/build-environment/index.html

Basically, if you're using daft CFLAGS you're on your own. Some ebuilds
might filter them, some ebuilds might die and some ebuilds might let
them through. Developers are under no obligation to add code to save
users from their own stupidity, but they might do so if you ask nicely.

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


-- 
gentoo-dev@gentoo.org mailing list



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

2006-07-10 Thread Ciaran McCreesh
On Sun, 9 Jul 2006 23:24:24 +0200 Denis Dupeyron [EMAIL PROTECTED]
wrote:
| 1) Should all ebuilds that currently filter --fast-math die on its
| presence instead of filtering it ?

http://devmanual.gentoo.org/ebuild-writing/functions/src_compile/build-environment/index.html

Basically, if you're using daft CFLAGS you're on your own. Some ebuilds
might filter them, some ebuilds might die and some ebuilds might let
them through. Developers are under no obligation to add code to save
users from their own stupidity, but they might do so if you ask nicely.

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


-- 
gentoo-dev@gentoo.org mailing list



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

2006-07-10 Thread Ciaran McCreesh
On Mon, 10 Jul 2006 10:41:25 +0200 Jakub Moc [EMAIL PROTECTED] wrote:
| There's no sane way to force users to switch their gcc version, so
| messing w/ ebuild deps, profiles or keywords of outdated gcc versions
| won't help...

Messing with profiles will, however, give you grounds to close bugs as
INVALID.

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


-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] 2.6.17 kernel stabilisation plan

2006-07-10 Thread Daniel Drake

Daniel Drake wrote:

Hi,

I'm hoping to be able to mark 2.6.17 stable on or around July 11th. I'll 
give around a weeks notice here when that is to happen. Hopefully we'll 
use this for the 2006.1 release too.


It will be a little later than planned, but this is your 1 week notice 
that 2.6.17 will go stable on July 17th. There are a couple of packages 
to fix in the stable tree which I will do my best to see fixed before 
this happens.


Daniel
--
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] Dying on some CFLAGS instead of filtering them.

2006-07-10 Thread Zac Medico
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

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. :)

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

iD8DBQFEsolv/ejvha5XGaMRAkeoAJ95/lUC/pSZHeo09JOp/PCOx0HkxwCgoBVl
zJW3/SnRt48YXixrIFxt+zo=
=mg/P
-END PGP SIGNATURE-
-- 
gentoo-dev@gentoo.org mailing list



[gentoo-dev] Re: Portage: missing pieces

2006-07-10 Thread Molle Bestefich

Kevin F. Quinn 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.

It's conveyed by the fact that when updating, you see a new compiler
version being installed.  If you have done a world update, you
already have the later compilers installed.


No, that's not true.  It's not conveyed at all.
It might install a new GCC, but it doesn't switch to it.
It doesn't tell the user to switch to it, either.


As has been explained before, as far as the gcc ebuilds are
concerned their job is finished when the new compiler version
is installed.  It is up to the user to decide to change their
system compiler.


You seem to have missed the issue.


 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.

Portage and the ebuilds handle it fine.


Same.


All that needs to happen is for users to accept the advice to read
the gcc upgrading guide when they trip over problems that arise
from issues with gcc versions.


There's no advice, instead Portage crashes during a system update.


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

Don't take the bug marking as a personal attack


I don't, it's not my bug ;-).


it's a marking for devs to understand what was the impact of the bug.


It's marked INVALID, while the issue is clearly valid.


Focus on the advice given, which from what I can see was succinct
and correct.


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


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

What exactly do you expect to happen?  GCC updates don't switch major
versions automatically, because in general it means changing ABI which
means rebuilding everything.


Ah, that's a good question.

I think the proper reaction from Portage would be (both):
a) Alert the user that the newest version of package XYZ cannot be
   merged because it needs a newer compiler than the currently
   selected one.
b) Skip package XYZ, but continue updating the rest of the system.

Package XYZ could also block the update, that would be OK.


Again, this is not a personal attack but information for devs
to understand whether different work is needed for the different bugs.


Noone has mentioned personal attacks, so drop that train of thought.

You misread my point.  I was trying to say that bugs describing problems
(with fx. Portage) in abstract will often get closed as a duplicate of a
bug where someone has experienced a particular incarnation of the
larger problem described.

That's a good way to make sure that relevant end user issues never
come into contact with the devs, which I'm sure is not what the
devs want.


  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.

The problem with having the xine ebuild check gcc version and aborting
if a certain version is found active,


I don't think anyone would implement it that way, since that's braindead ;-).
Instead of checking a particular version, checking for a minimum
version would be the default available functionality.


is that if the gcc version is modified in the future such that xine would
then build with it, that handling would have to come out again.


In the (hysterically abstract) situation where someone revisits an old
version of GCC and adds GCC-4 features, nothing would break.

Users would still be told to upgrade to a newer version, and all would
be well, despite the fact that the old GCC with the backported feature
could now theoretically be used.

(But it's just trolling anyway, you're really describing a non-issue, IMHO.)


Another way of looking at it, is that there are a lot of people out
there who are coping just fine with GCC upgrades as they are currently
managed.


Uh.  What's your point?
That you're one of those people who hates change just because it's
change, or do you have something more relevant to say that I'm not
catching?


See https://bugs.gentoo.org/page.cgi?id=fields.html - as far as devs
are concerned, The problem described is not a bug so INVALID is the
correct resolution marking.


Not a bug does not translate to Not an issue.
You're practicing an extremely narrow view of what's a bug, and 

[gentoo-dev] Removing dev-perl/Test-Builder-Tester

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

This package was absorbed back into perl-core/Test-Simple as of the 0.62
release (which you have either via dev-lang/perl-5.8.8 or as the ebuild
at this point). I'm package.mask'ing it and will be removing it from the
tree in 30 days. Anything that used to dep Test-Builder-Tester has been
updated to dep virtual/perl-Test-Simple-0.62, which is available on more
arch's stable than T::B::T ever was. (incidently, this also resolves an
upgrade/downgrade loop some folks face when emerge -De and emerge -Du
are used, I can supply the relevant bug number if you are really super
curious).

~mcummings

- --

- -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.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEso2oq1ztTp5/Ti4RAu7vAJ0QuTAHlUuIeXGxobZPVtgaOrqJrwCgok0x
2vNpQGvQ9EO20ACjpDw3uL8=
=AubO
-END PGP SIGNATURE-
-- 
gentoo-dev@gentoo.org mailing list



[gentoo-dev] Re: Portage: missing pieces

2006-07-10 Thread Molle Bestefich

Richard Fish wrote:

Having dozens (hundreds?  all?) ebuilds check for a minimum version


Probably just the ebuilds that happen to use new GCC features before
the mass of the general public has changed to that version.  But yes,
a minimum version constraint could theoretically end up in a lot of
packages.


of gcc doesn't seem very effecient.


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


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.


Obviously any solution implemented should work for all ebuilds, not
just 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?


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


Really?
How do you gather?
I'd think that most users hadn't even run into this problem (yet),
because many source code maintainers strive to be able to compile with
as old a version of GCC as possible..
--
gentoo-dev@gentoo.org mailing list



[gentoo-dev] Removing www-servers/resin-ee

2006-07-10 Thread Krzysiek Pawlik

I've masked www-servers/resin-ee on 1 July, it will be removed from tree
 around friday (14 July) - it's old, binary and there's no version 3 of
it. Please use www-servers/resin.

-- 
Krzysiek Pawlik   nelchael at gentoo.org   key id: 0xBC51
desktop-misc, desktop-dock, desktop-wm, x86, java, apache...



signature.asc
Description: OpenPGP digital signature


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

2006-07-10 Thread Jakub Moc
Molle Bestefich wrote:
 Kevin F. Quinn 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.

 It's conveyed by the fact that when updating, you see a new compiler
 version being installed.  If you have done a world update, you
 already have the later compilers installed.
 
 No, that's not true.  It's not conveyed at all.
 It might install a new GCC, but it doesn't switch to it.

Sigh. Because it would break your system!

 It doesn't tell the user to switch to it, either.

You really need to research better if you insist on beating a dead horse
over and over again. Kindly read the toolchain.eclass:

snip
einfo You should make sure to rebuild all your C++ packages when
einfo upgrading between different versions of gcc.  For example,
einfo when moving to gcc-3.4 from gcc-3.3, emerge gentoolkit and run:
einfo   # revdep-rebuild --library libstdc++.so.5
echo
einfo For more information on the steps to take when upgrading 
einfo from gcc-3.3 please refer to: 
einfo http://www.gentoo.org/doc/en/gcc-upgrading.xml;
echo
/snip


-- 
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


[gentoo-dev] Re: Portage: missing pieces

2006-07-10 Thread Molle Bestefich

Jakub Moc wrote:

Sigh. Because it would break your system!

You really need to research better if you insist on beating a dead
horse over and over again. Kindly read the toolchain.eclass:


You're misreading me.

I was merely counter-arguing Kevin, who said that Portage provides
plenty of information to the end user about GCC switches being
necessary.

I was not trying to convince anyone to make Portage switch GCC
version automatically.  That would probably be rather insane.
--
gentoo-dev@gentoo.org mailing list



[gentoo-dev] Linux World Expo

2006-07-10 Thread Joshua Jackson
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

So who's planning on going? Basically  I'd like to know who's planning
on going. I'm still undecided about it honestly, and if I go it'd only
be for a few days. Its also probably a good way to find a roomate to
make the cost of rooms a bit less. We don't have enough dev's close
enough to san fran to allow a whole bunch of us a floor to crash on as
far as I know. If however you are, give us a shout with floor space ;)
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEsp6zSENan+PfizARAubpAJ9/NtTBUuB2XRkfz0kb6vHoD5zDKgCfRVah
WHNtV25i/a5VJnvc80EpmZc=
=fUaW
-END PGP SIGNATURE-

-- 
gentoo-dev@gentoo.org mailing list



[gentoo-dev] mail-mta/courier needs a new maintainer

2006-07-10 Thread Sune Kloppenborg Jeppesen
mail-mta/courier is without an active ebuild maintainer and has an open 
security bug [1].

Anyone willing to take care of this package in the future, please update 
metadata.xml and CC yourself on the bug.

[1] https://bugs.gentoo.org/show_bug.cgi?id=135005

-- 
Sune Kloppenborg Jeppesen
Gentoo Linux Security Team


pgpz2aB6m6vjr.pgp
Description: PGP signature


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

2006-07-10 Thread Kevin F. Quinn
On Mon, 10 Jul 2006 19:23:54 +0200
Molle Bestefich [EMAIL PROTECTED] wrote:

 Kevin F. Quinn 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.
 
  It's conveyed by the fact that when updating, you see a new compiler
  version being installed.  If you have done a world update, you
  already have the later compilers installed.
 
 No, that's not true.  It's not conveyed at all.

It is clear that a new version of GCC is installed.  It is also clear
that it is not switched to (otherwise the upgrade would have to trundle
off and rebuild everything - we'd be swamped with complaints if we did
that!).

 It might install a new GCC, but it doesn't switch to it.

By design.

 It doesn't tell the user to switch to it, either.

Again by design.

It's up to the user to switch to a different compiler, should they wish
to.  In other words, it's a user choice which compiler version they use.

  As has been explained before, as far as the gcc ebuilds are
  concerned their job is finished when the new compiler version
  is installed.  It is up to the user to decide to change their
  system compiler.
 
 You seem to have missed the issue.

Maybe, that wasn't my point.  I'm telling you what the situation re.
compiler installation actually is, and how it is designed to be.


   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.
 
  Portage and the ebuilds handle it fine.
 
 Same.
 
  All that needs to happen is for users to accept the advice to read
  the gcc upgrading guide when they trip over problems that arise
  from issues with gcc versions.
 
 There's no advice, instead Portage crashes during a system update.

The advice is to switch to a more recent compiler.  Jakub has made that
clear on the bug, and we've said it several times here.  As a result,
there is no change to be done to any ebuilds etc.


   Nothing?
   I find it unacceptable that the bug is marked INVALID when it
   clearly describes a relevant issue.
 
  Don't take the bug marking as a personal attack
 
 I don't, it's not my bug ;-).
 
  it's a marking for devs to understand what was the impact of the
  bug.
 
 It's marked INVALID, while the issue is clearly valid.

OK; one more time.  The bug does not lead to any change to anything in
the tree.  Therefore it is marked INVALID, in that it is not a valid
issue with respect to the Gentoo tree.  INVALID has the meaning
ascribed to it on the bugzilla help page, not the meaning from an
English dictionary.  When a bug is fixed, something has to change for
that fix to happen - if there's no change, either there's a
bug that we won't fix (WONTFIX) or there's no bug.  In this case
there's no bug, in my opinion.

  Focus on the advice given, which from what I can see was succinct
  and correct.
 
 It shouldn't even be _necessary_ to create bugs and receive advice
 from a living, breathing human being just to perform a system update.

You have to realise that being a constantly moving source distribution,
it is impossible to ensure that all packages in all stable versions
interoperate in all possible combinations.  We don't guarantee that.
We do go to some effort to ensure all latest stable versions
interoperate when built sensibly, when it comes to a release - that's as
far as we can go, realistically.


   As far as I can tell, the complaints are about Portage being
   unable to handle GCC upgrades gracefully for end users.
 
  What exactly do you expect to happen?  GCC updates don't switch
  major versions automatically, because in general it means changing
  ABI which means rebuilding everything.
 
 Ah, that's a good question.
 
 I think the proper reaction from Portage would be (both):
  a) Alert the user that the newest version of package XYZ cannot be
 merged because it needs a newer compiler than the currently
 selected one.

I explained above why this wouldn't be a good idea.

  b) Skip package XYZ, but continue updating the rest of the system.

emerge --resume --skipfirst

 Package XYZ could also block the update, that would be OK.

The problem with this is the same as with (a).

  Again, this is not a personal attack but information for devs
  to understand whether different work is needed for the different
  bugs.
 
 Noone has mentioned personal attacks, so drop that train of thought.
 
 You misread my point.  I was trying to say that bugs describing
 problems (with fx. Portage) in abstract will often get closed as a
 duplicate of a bug where someone has experienced a particular
 incarnation of the larger problem described.


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

2006-07-10 Thread Kevin F. Quinn
On Mon, 10 Jul 2006 19:32:00 +0200
Molle Bestefich [EMAIL PROTECTED] wrote:

 Richard Fish wrote:
  Having dozens (hundreds?  all?) ebuilds check for a minimum version
 
 Probably just the ebuilds that happen to use new GCC features before
 the mass of the general public has changed to that version.  But yes,
 a minimum version constraint could theoretically end up in a lot of
 packages.
 
  of gcc doesn't seem very effecient.
 
 I can't see why it would not be efficient?

Imagine checking over 11,000 packages (over 24,000 ebuilds) against all
stable compiler versions in the tree, working out which versions of the
compiler currently don't allow each package to build successfully and
then adding the relevant code to the ebuild to handle that information.

Now imagine updating a compiler version to fix an issue, then having to
go through the whole tree looking for ebuilds that restrict against
that compiler version, and checking them to see if the restriction can
be lifted.

It may be efficient for the user, but it creates mountains of work for
the volunteer devs whose time is better spent focusing on latest stable
versions.

 
  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.
 
 Obviously any solution implemented should work for all ebuilds, not
 just 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?

It wouldn't work in that it's just not maintainable.  There's more to a
process working than just whether a particular piece of code functions
correctly or not.

  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
 
 Really?
 How do you gather?

Suffice to say that many users track the latest stable versions of
everything on their system.  We don't know how many people stick to old
versions or for how long they do so.  However if many people remained
on old versions of the compiler, I suspect we'd be seeing a lot of bugs
related to that - and we're not seeing them.

 I'd think that most users hadn't even run into this problem (yet),
 because many source code maintainers strive to be able to compile with
 as old a version of GCC as possible..

That's unlikely to be true.  Some upstream developers do maintain
compatibility with a range of compiler versions.  Some upstream
developers only recommend one specific version.  Many will be somewhere
in between.

-- 
Kevin F. Quinn


signature.asc
Description: PGP signature


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

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

-- 
Kind Regards,

Simon Stelling
Gentoo/AMD64 Developer
-- 
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] Dying on some CFLAGS instead of filtering them.

2006-07-10 Thread Donnie Berkholz
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
 randomly later.

How about `cat /var/db/pkg/$category/$package-$version/CFLAGS`? You
can't rely on emerge --info anyway, because it shows _current_ flags
rather than flags the package was built with.

Thanks,
Donnie



signature.asc
Description: OpenPGP digital signature


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

2006-07-10 Thread Georgi Georgiev
maillog: 09/07/2006-17:17:59(+0100): John Mylchreest types
 I've tried to clarify my point fairly well above, but the dependancy
 is fairly strict by design. What in linux-mod except for my specific
 example above would continue to work if there were no kernel sources
 present? (I do of course know the answer but its rhetorical)
 
 To that end is the reason why the dependancy still exists. That said,
 I'm open to persuasion.

I'm having trouble putting my thoughts in order, so I'll just throw them
out, hoping it would make some sense.

- if linux-sources is a dependency, then the package usually would need
  to be rebuilt if the kernel configuration/sources change (linux-mod
  already faciliates that for a good reason)
- even if an ebuild is being smart and is only using linux-info to throw
  informational messages, the sources dependency is still there
- an ebuild should specify the linux-sources dependency on its own if it
  really needs the sources

Having said that, out of the 62 packages that inherit linux-info and do
not inherit linux-mod:

- 23 only make .config checks (should be non-fatal anyway)
- 9 install kernel modules (so they should rather inherit linux-mod)
- 8 need the kernel sources to build, so they should probably inherit
  linux-mod as well
- 6 have a DEPEND=virtual/linux-sources already
- 4 use linux-info to modify runtime behavior
- 2 are obsolete

This is only the easily classifiable stuff, but it certainly does seem
that the linux-sources dependency can be pulled out of the eclass.

-- 
/\   Georgi Georgiev   /\ You have a truly strong individuality. /\
\/[EMAIL PROTECTED]\/\/
/\ http://www.gg3.net/ /\/\


pgpd6vB3yLpHY.pgp
Description: PGP signature


[gentoo-dev] Modular X unported packages

2006-07-10 Thread Donnie Berkholz
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
unported-notinc-nonstable-arches.log  | cut -d: -f1 | sed -e
s:-[0-9].*:: | uniq | wc -l` to get the number of packages that can be
stabilized, or `cut -d: -f1 unported-notinc-nonstable-arches.log | sed
-e s:-[0-9].*:: | uniq | wc -l` to get the total unported packages. If
you want a list, remove the `wc -l` from the end.

Thanks,
Donnie

1.
http://dev.gentoo.org/~dberkholz/broken_modular/unported-notinc-nonstable-arches.log



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] New virtuals: virtual/jre and virtual/jdk

2006-07-10 Thread Joshua Nichols
Krzysiek Pawlik wrote:
 Two new new-style virtuals have been added today to the tree:

  - virtual/jdk
  - virtual/jre

 This allows migration to generation 2 of Java build system to advance.
 All virtual/{jdk,jre} have been removed from profiles. The bug for this
 was #138747.

   
Something worth mentioning... If you have problems where dependencies
fail to resolve, like dev-java/blackdown-1.5, or dev-java/kaffe-1.4, it
means you have some stale PROVIDE files kicking around. You will likely
want to run the following to find them:

find /var/db/pkg -name PROVIDE | xargs egrep -l 'virtual/jdk|virtual/jre'

This should give you a list of files to you'll want to delete.

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