Re: [gentoo-dev] Suggestion for next bugday: Mass use deps migration

2009-02-22 Thread Carsten Lohrke
On Freitag, 20. Februar 2009, Petteri Räty wrote:
 Suggestions/objections?

If you mean by mass migration doing that more or less blindly, I do object. 
When an ebuild directly or indirectly inherits an eclass, which is EAPI 2 
enabled, like base.eclass, while another isn't, you have to expect 
side-effects. See for example media-tv/kdetv-0.8.9-r1, which features an 
empty src_prepare to prevent the attempt to apply patches twice, temporarily.

So the first step is to get all eclasses EAPI 2 ready and even then I wouldn't 
rule out odd cases, so changes should happen in testing and revised ebuilds 
exclusively to assure odd cases get caught.


Carsten


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


Re: [gentoo-dev] Fwd: News item: Generation 1 deprecation

2009-02-22 Thread Carsten Lohrke
On Sonntag, 22. Februar 2009, Petteri Räty wrote:
 java-check-environment

Running it, I got the message everything would be fine, but after uninstalling 
Sun's 1.4 JDK, Portage told me it'll be still needed. So after a bit package 
masking and uninstalling

dev-java/sun-jdk:1.4
=dev-java/java-sdk-docs-1.4*
virtual/jdk:1.4
virtual/jre:1.4

I got 

For more information, see the MASKED PACKAGES section in the emerge
man page or refer to the Gentoo Handbook.
(dependency required by dev-java/tomcat-servlet-api-5.5.27 [installed])
(dependency required by dev-util/eclipse-sdk-3.4-r2 [installed])
(dependency required by @world [argument])

and after looking at the tomcat-servlet-api ebuild I finally found that 
setting a java5 use flag and re-emerging the ebuild would be required, et 
voila...


It's really great that the Java team managed to convert all packages, but I do 
not call the above procedure user friendly. ;)


Carsten


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


Re: [gentoo-dev] Suggestion for next bugday: Mass use deps migration

2009-02-22 Thread Carsten Lohrke
On Sonntag, 22. Februar 2009, Petteri Räty wrote:
 Even if the eclasses are not EAPI 2 ready you can work
 around it in the ebuild by for example those empty functions.

This is fine with me, when you care for said packages and their eclasses and 
know for sure such hacks have a very limited lifetime. Otherwise it's likely 
to rot in the repository for ages.


Carsten


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


Re: [gentoo-dev] Suggestion for next bugday: Mass use deps migration

2009-02-22 Thread Carsten Lohrke
On Sonntag, 22. Februar 2009, Tomáš Chvátal wrote:
 Well that is the reason why i am first eapi2ing the kde eclass. I was
 really suprised when i saw kde3 ebuilds with eapi2 :(

I value users suffering from package manager issues higher and fix issues as I 
see them, walking through the tree. Only a handful of ebuilds are affected. 
Identifying and adjusting them, when the modified eclasses hits the tree is a 
quick operation.


Carsten


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


Re: [gentoo-dev] EAPI-2

2008-09-14 Thread Carsten Lohrke
On Dienstag, 9. September 2008, Jorge Manuel B. S. Vicetto wrote:
 ~ * The meaning of the !atom blocker syntax now implies that
 ~   temporary simultaneous installation of conflicting packages is
 ~   allowed [3].

 ~ * A new !!atom blocker syntax is now supported, for use in special
 ~   cases in which temporary simultaneous installation of conflicting
 ~   packages should not be allowed.

I didn't really look into the issues, intended to be resolved with this, but 
I'm somewhat suspecious that this is merely a hack around inaccurate 
dependency listing in ebuilds on the one side and Portage's dependency 
resolver issues on the other. 

What I do strongly oppose is changing the meaning of the '!' symbol, as 
blockers, which should remain real blockers will not be adjusted by us, when 
changing an ebuild to EAPI 2++ in every case, since we're humans after all. 
So, if you implement this, keep '!' as is and find another symbol for 
these soft blockers.

 ~ * A new src_prepare phase function is called after src_unpack.

 ~ * The old src_compile phase function is split into separate
 ~   src_configure and src_compile fuctions.

All I do see is more complexity, but no real benefit.


Carsten


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


Re: [gentoo-dev] EAPI-2

2008-09-14 Thread Carsten Lohrke
On Sonntag, 14. September 2008, Zac Medico wrote:
 Well, I'm open to alternative suggestions. Please see the previous
 email in which I've attempted to explain the reasoning for the given
 approach [1]. It seems to me that this approach is well suited for
 solving cases in which temporary simultaneous installation of
 blocking packages is needed.

Thanks for pointing me to it, Zac. I do not pretend to be able to pull the 
white bunny out of the black hat, presenting you the perfect alternative, 
especially since you've thought about it a lot more than me. I just feel 
uncomfortable, having ebuilds overwrite each others files. According to the 
referenced data, it'll work around a number of issues. The time will show, If 
real hard blocker issues remain a problem, I guess.


 Again, please see my previous email on this subject [1]. The reason
 that I think we should change the meaning of the '!' symbol is that
 the majority of existing EAPI 0 or 1 blockers appear to fit the new
 meaning already. So, we'll only have to use the new !!atom syntax
 for special cases in which temporary simultaneous installation of
 blocking packages must be explicitly forbidden.

Just the majority or pretty much all and the others are easily to find out and 
moved to EAPI 2, so the point I raised ceases to exist!?


I want to share another thought regarding this proposed addtion:

!! has the double meaning a) unmerge the following ebuilds later and 
b) overwriting files of the following ebuilds while merging changes makes 
them owned by the freshly merged ebuild

so we have one symbol denoting two different commands, which could find use 
independently. Moreso, if we add more of these symbols to express something 
different, our syntax may look almost like Lisp in the end:

 use? ( ! ( X ( Y ( || ( ( foo bar ) baz ) ) ) ) ) )

Looks ugly, doesnt it? 

How about using two symbols for !! and having the possibility to aggreagate 
them, e.g.

use? ( !XY||: ( ( foo bar ) baz ) )

instead?!


Carsten


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


[gentoo-dev] split Qt 4.4 dependencies

2008-07-26 Thread Carsten Lohrke
Since it is time to get Qt 4.4 into testing, here some information how to get 
the dependencies in the ebuilds you maintain, right.

Beforehand: Relying on best_version() or the broken qt4_min_version() stuff 
from qt4.eclass is not fine.


- Migrating existing ebuilds requires a dependency like 

|| ( ( splitQt1 .. splitQtN )  x11-libs/qt-4.4:4 )

For x11-libs/qt any dependency atom _not_ including version 4.4 is fine. It is 
a requirement¹ to list the split Qt ebuilds first.

- When Qt 4.4 is in testing, new ebuilds to be added to the tree may not 
include x11-libs/qt. Depend on the split ebuilds only.

- For all ebuilds which are not tested or supposed to work with split Qt 4.4 
ebuilds change the dependency to x11-libs/qt-4.4:4 or a comparable 
dependency atom, please.
 

The split Qt ebuilds are:

x11-libs/qt-assistant
x11-libs/qt-core
x11-libs/qt-dbus
x11-libs/qt-demo
x11-libs/qt-embedded
x11-libs/qt-gui
x11-libs/qt-opengl
x11-libs/qt-phonon
x11-libs/qt-qt3support
x11-libs/qt-script
x11-libs/qt-sql
x11-libs/qt-svg
x11-libs/qt-test
x11-libs/qt-webkit
x11-libs/qt-xmlpatterns


Carsten


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


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


Re: [gentoo-dev] Re: [RFC] New policy: LDFLAGS should be respected

2008-07-26 Thread Carsten Lohrke
On Samstag, 26. Juli 2008, Donnie Berkholz wrote:
 Why are you asking us? He's the QA lead, you should be talking with the
 QA team about this.

Such issues are not up to a self chosen group, but are topic for this list.


Carsten



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


Re: [gentoo-dev] Re: [RFC] New policy: LDFLAGS should be respected

2008-07-26 Thread Carsten Lohrke
On Samstag, 26. Juli 2008, Arfrever Frehtes Taifersar Arahesis wrote:
  Um, this already is the policy.  We've always fixed bug reports about
  LDFLAGS being ignored.

 Mark Loeser (Halcy0n) (QA project leader) said on 2008-07-24 that this
 policy doesn't exist. I understand that bug reports about LDFLAGS being
 ignored are usually fixed, so I ask for the formal enacting of this policy.

Afaik it has always been the way that *sane* LDFLAGS are to be respected, but 
exceptions exist of course and it's up to the maintainer to mangle or clear 
your LDFLAGS, if deemed necessary. I'd like to know, why Mark asked to bring 
this question up here. Shouldn't this be common sense!?


Carsten


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


Re: [gentoo-dev] Re: PostgreSQL Status

2008-04-17 Thread Carsten Lohrke
On Mittwoch, 16. April 2008, Tiziano Müller wrote:
 While the dump command can read clusters created by an older version it is
 still necessary to dump and reload your data on version bumps between major
 versions [...

Of course. I didn't question the dump and reload cycle. Just saying you have 
to use the dump utility of the old version is not correct and goes against 
the recommendations of the PostgreSQL developers. Also the annoying 
pkg_setup() error  die stuff in the existing ebuilds has always been 
superfluous.


Carsten


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


Re: [gentoo-dev] Projects and subproject status: KDE

2008-01-09 Thread Carsten Lohrke
 KDE 4.0.0 will be released on January, 11th 2008, and if things keep
 going like they do now we might be able to put all the stuff into
 ~arch on the release day.
 I'm going to mail about this again in -core soon.

Unless you mean hard masked, I do object. The code base has too many issues 
and is incomplete compared to KDE 3.5, so it's not ready to push it to the 
regular ~arch user, yet.


Carsten


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


Re: [gentoo-dev] EAPI placement

2007-12-22 Thread Carsten Lohrke
On Mittwoch, 12. Dezember 2007, Ciaran McCreesh wrote:
 On Wed, 12 Dec 2007 23:14:24 +0100
 There is no way for an eclass to throw an error. Nor, with the current
 way Portage implements EAPI, is there a way to add such a way.

It's not perfect, but 

eclass_pkg_setup() {
 something_wrong  die 
}

should work reasonably well.


 It's in PMS. svn co http://svn.repogirl.net/pms for a copy.

Right. But when you think every dev will read the PMS to find out what's fine 
to do and what not for N++ EAPIs again and again, while he wants only a short 
list of do's and don'ts, your bathing temperature is far above average.

What I do think - and no, I won't read this rediculous large 
category/ebuild-x.y-rN-my.local.version-too-much-coffein-drinks.ebuild-epaiN-anyone-else-with-a-stupid-idea
 
thread - is, that EPAI changes and there implications apparently have not 
been well thought out and the best we can do is to ensure there are as few 
eclass/ebuild-relating differing EAPIs as possible.


Carsten


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


Re: [gentoo-dev] EAPI placement

2007-12-12 Thread Carsten Lohrke
On Mittwoch, 12. Dezember 2007, Ciaran McCreesh wrote:
 * Eclasses may not set EAPI.

 * Eclasses may not assume a particular EAPI.

I disagree here. It would be annoying and possibly even hindering in future 
not being able to use higher EAPI features in eclasses. Point is the eclass 
has to check, if the author of an ebuild sets another EAPI and throw an 
error, in this case.


The most basic issue, which we didn't even discuss yet, afaik, is how to make 
every developer aware which feature belongs to which EAPI. I freely admit, I 
do not know that. Is there a list somewhere? 

EAPI issues may lead to a lot of confusion and eclass bloat, especially since 
we still can't remove stale eclasses afaik.


Carsten


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


Re: [gentoo-dev] Re: packages.gentoo.org lives!

2007-11-14 Thread Carsten Lohrke
On Mittwoch, 14. November 2007, Josh Saddler wrote:
 Robin H. Johnson wrote:
  There isn't meant to be the big black area at the top like, the main
  gentoo.org site.

 But shouldn't there be some sort of area at the top with links to the
 other parts of the site, as the other pages do (the navstrip across the
 top)?

Yeah, I think so, too. It's also looking ugly the way it is know.


Nevertheless, nice to have p.g.o back. Thanks.


Carsten




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


Re: [gentoo-dev] RFC: Place of EAPI variable in ebuild

2007-11-11 Thread Carsten Lohrke
On Sonntag, 11. November 2007, Ciaran McCreesh wrote:
 I suspect that for existing eclasses, the safest way to proceed is to
 make a new eclass and move common code into a third eclass. So you'd
 have foo.eclass doing EAPI 0 specific stuff and inheriting foo-common,
 and foo-eapi1.eclass doing EAPI 1 specific stuff and inheriting
 foo-common.

And this is where it gets ugly - maybe finally a good reason for versioned 
eclasses (though I fear the misuse).

That it is not possible today to let an ebuild die in global scope is not a 
big issue, as you can in pkg_setup(), just as with missing use dependencies, 
just that the developer in question /should/ stumble about it, so in the best 
of all worlds the user base wouldn't ever notice. The only problem is the 
weakest link: One of us missing to care to invoke eclass_pkg_setup(), when 
necessary. 

Maybe it would in general not be bad to require eclass phase functions to be 
called, when the inheriting ebuild/eclass writes a custom phase function and 
having Portage to complain about it, unless some override_eclass-phase 
variable is set.


Carsten


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


Re: [gentoo-dev] RFC: Place of EAPI variable in ebuild

2007-11-09 Thread Carsten Lohrke
On Freitag, 9. November 2007, Petteri Räty wrote:
 What if I want to use EAPI=1 features in an eclass? So if we for example
 we have an ebuild using EAPI=2 and then it inherits and eclass that sets
 EAPI=1 for slot deps.

You check which EAPI the ebuild sets, then either continue or die. Handling 
depends a bit upon, if EAPI should always be downwards compatible. Ideally 
only unset EAPI (for trivial ebuilds) and same EAPI would be allowed 
combinations, as this would simplify doing incompatible upgrades.


Carsten


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


Re: [gentoo-dev] new old eclass - wxwidgets.eclass

2007-10-07 Thread Carsten Lohrke
 work fine with conditional wx usage? need-wxwidgets for that, I guess?

No, please. These need-foo()'s are crap, because too often people people do

need-foo 
DEPEND=another-dep

resetting the to be stored dependencies to just another-dep...


Also top level function calls in ebuilds are dead ugly per se. Use 
NEED_WX=x.y to be set before inheriting the eclass instead.


Carsten


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


Re: [gentoo-dev] why? pciutils with zlib use-flag went stable on x86

2007-07-29 Thread Carsten Lohrke
Don Sonntag, 29. Juli 2007, Sven Köhler wrote:
 Why did you provocate this breakage?

Which breakage? It didn't install a gzipped pci.ids here.


On the other hand, reading the utterly ridiculous bug 180554, I haven't read a 
valid argument why it should at all. Bizarre.


Carsten


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


Re: [gentoo-dev] why? pciutils with zlib use-flag went stable on x86

2007-07-29 Thread Carsten Lohrke
On Sonntag, 29. Juli 2007, Carsten Lohrke wrote:
 Don Sonntag, 29. Juli 2007, Sven Köhler wrote:
  Why did you provocate this breakage?

 Which breakage? It didn't install a gzipped pci.ids here.

That is with USE=hal. Crap...


Carsten


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


Re: [gentoo-dev] New PDEPEND behaviour.

2007-07-25 Thread Carsten Lohrke
On Mittwoch, 25. Juli 2007, Piotr Jaroszyński wrote:
 As a result of bug #180045 PDEPENDs can be now merged even before the
 package that pulls them. Zmedico says that's intended behaviour

Well, then what our Portage devs think the intended behaviour should be is a 
bug. E.g. in the case the bug refers to, we rely on Portage building  
kdnssd-avahi after kdelibs (otherwise it simply would fail), but before any 
other ebuild that might need kdnssd-avahi. And I'm pretty sure nearly 
everyone using PDEPEND in his ebuilds relies on Portage building the PDEPEND 
not before the ebuild, which lists it.

 We need to update docs or harass zmedico to force PDEPEND to be pulled as
 soon as possible but not before the pkg that pulls it.

The latter.


Carsten


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


Re: [gentoo-dev] New PDEPEND behaviour.

2007-07-25 Thread Carsten Lohrke
On Mittwoch, 25. Juli 2007, Brian Harring wrote:
 I suggest you in the future check out what actually was changed, and
 do some testing- both the original poster, and yourself are missing
 what is occuring here

Uh, thanks, I never was fond of reading the code of Portage, so I took Piotr's 
point as given.

 Note I said 'shift'.  It tries to place it earlier in the graph, while
 *still* maintaining the constraints of kdnssd-avahi- namely the
 kdelibs dependency.

 Via that dep, kdnssd-avahi *requires* kdelibs to be installed first,
 and portage honors that- it just now tries to get kdnssd-avahi merged
 as soon as possible after kdelibs due to their PDEPEND relationship
 (try it if in doubt, it lineralizes it properly).

 The cases where it doesn't, are when the constraints are already
 satisfied- kdelibs already is merged, basically.  There is a change in
 placement there, but considering the data involved, wouldn't label it
 a regression- same issue can, and does occur in multiple other ways.

That's fine.

  The latter.

 Former.  The ebuild manpage is a bit loose in it's description of what
 PDEPEND does.

Well, I should point out where I come from. There is no need to install a pure 
runtime dependency before the ebuild pulling it in. If pure runtime 
dependencies would be handled this way, there would be no need for PDEPEND at 
all. I consider the current way Portage handles pure runtime dependencies 
(causing the need for the artificial PDEPEND in the first place) as 
conceptually broken.


Carsten


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


Re: [gentoo-dev] New PDEPEND behaviour.

2007-07-25 Thread Carsten Lohrke
On Mittwoch, 25. Juli 2007, Vlastimil Babka wrote:
 A: PDEPEND=B
 B: DEPEND=A

 If this is what you call RDEPEND conceptually broken, then sorry for
 useles try to explain it :) Maybe package manager could be smart enough
 and relax the RDEPEND in such cases itself, maybe it's better to say
 that via PDEPEND explicitly...

Of course a valid example - and yes, that's something the package manager 
should care about. Admitted, conceptually broken was a bit harsh, still 
both, that a pure runtime dependency gets built before the ebuild needing it 
by default and the need for PDEPEND seem ugly to me.


Carsten


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


Re: [gentoo-dev] [PMS] Version Naming Clarification

2007-06-07 Thread Carsten Lohrke
On Donnerstag, 7. Juni 2007, Doug Goldstein wrote:
 That's exactly what I'm saying. CPV (Category/Package/Version) requires
 =, =, , = to begin it.

So you'd like to change every foo/bar occurrence (and that's the common case) 
to =foo/bar-0 !? Completely out of line, imho. I don't understand what the 
fuzz is about. sys-fs/ntfs3g is absolutely fine. Fighting for the little - 
is nonsense.


Carsten




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


Re: [gentoo-dev] [PMS] Version Naming Clarification

2007-06-07 Thread Carsten Lohrke
On Donnerstag, 7. Juni 2007, Doug Goldstein wrote:
 Carsten, no offense but I think you totally misunderstood the scope of
 what I was trying to convey

Yeah, sorry, should have had read your initial email carefully. Taking 
anything before the last - as version information is indeed a Portage bug.


Carsten


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


Re: [gentoo-dev] stabilizing expat 2.0.0

2007-05-16 Thread Carsten Lohrke
Christian, Raúl - you guys rock!


Carsten


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


Re: [gentoo-dev] Packages with same name was - Conversion of Emacs virtual packages

2007-05-16 Thread Carsten Lohrke
While I always was for uniq package names, tree-wide, renaming doesn't solve 
anything. Gentoo's binary packages are fundamentally broken. You can't have 
two binary packages of the same ebuild differing e.g. in use flags, 
architecture, toolchain, etc. pp. either.


Carsten


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


Re: [gentoo-dev] stabilizing expat 2.0.0

2007-05-15 Thread Carsten Lohrke
On Dienstag, 15. Mai 2007, Caleb Tennis wrote:
 I just read the bug, but I don't see any compelling reason against using
 the preserve_old stuff.

The big problem with it is that we do not store information about retained 
libraries and let portage throw warnings. When people miss such a post 
install message, the library potentially remains forever in the system, not 
unlikely with seldom updated stuff linking against it. As soon as a 
vulnerability is popping up, the system is vulnerable, remains vulnerable and 
its owner assumes everything is fine.


Carsten


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


Re: [gentoo-dev] stabilizing expat 2.0.0

2007-05-15 Thread Carsten Lohrke
On Dienstag, 15. Mai 2007, Ciaran McCreesh wrote:
 preserve_old_lib is a horrible hack that shouldn't be being used at all.
 Don't push it as an alternative for proper slotting.

In it's current state it's indeed a horrible hack. But slotting is in many 
cases no solution either. When you have to move headers and other files to 
avoid file collisions and have to adjust every single dependending package 
accordingly, it's quickly getting a ridiculous maintenance nightmare.


Carsten


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


Re: [gentoo-dev] stabilizing expat 2.0.0

2007-05-15 Thread Carsten Lohrke
On Dienstag, 15. Mai 2007, Mart Raudsepp wrote:
 Ok, I can't wait with GNOME-2.16.3 that long. I'm already late a month.
 I wonder how much packages KDE needs rebuilt with the expat bump
 (revdep-rebuild --library expat.so or something like that). Maybe
 including it in the GNOME bumps is a good idea if that has it for more
 packages than KDE.

If we want to take this to measure, it' a bigger problem for KDE users (unless 
built with --as-needed). The list of packages is unfortunately 
quite impressive. What was your plan wrt. stabilisation of Gnome? I can 
look at the remaining issues this evening, so maybe we can speed up the 
process a bit. The bigger problem I see on the side of the arch teams. I got 
used to (nah, not really) mips and alpha lagging behind for several months, 
but the amd64 team is unresponsive on even trivial stabilisation request form 
the KDE team as well, lately.


Carsten


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


Re: [gentoo-dev] trial software in portage?

2007-05-14 Thread Carsten Lohrke
On Montag, 14. Mai 2007, Jakub Moc wrote:
 As the name unrar suggests, it doesn't *pack* stuff, in only unpacks it.

Why do you come with unrar-gpl then. I'd assume the same for it.

 So, thanks and leave the thing alone in the tree; and yeah, there are
 really people who work w/ .rar stuff still, tar.{gz,bz2} hasn't
 dominated the world yet.

If there were an issue with distributing the rar package, the usual answer 
were to use another archiver, no matter how many people complained.


Cratsen



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


[gentoo-dev] last rites: app-office/{k,q}hacc

2007-05-14 Thread Carsten Lohrke
These packages are lingering around for a long time and no one of the KDE team 
seems interested fixing them, so they're up for adoption for a while, before 
they I'll remove them from the repository.

Bug 177782 is yours, if you're interested.


Carsten


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


Re: [gentoo-dev] Eigen and GPL-2 exception - is a new licence required?

2007-05-12 Thread Carsten Lohrke
Err, every single _GPL_licensed_ software needs an OpenSSL exception of 
course.


Carsten


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


Re: [gentoo-dev] Suitable USE flag name for stuff that requires non volatile memory

2007-05-12 Thread Carsten Lohrke
Does it matter that the DUID-LLT isn't stored when starting from a Live-CD? I 
don't see why there is the need for a use flag for this functionality, when 
it doesn't imply a new dependency.


Carsten


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


Re: [gentoo-dev] Eigen and GPL-2 exception - is a new licence required?

2007-05-12 Thread Carsten Lohrke
No. LICENSE=GPL-2 some-exception suffices. That said, we suck at our 
licensing information badly. E.g. every single ebuild linking against OpenSSL 
has (or at least needs to have) a linking exeption. We don't flag this 
anywhere. More important, what's with optional dependencies!? We don't 
support 

LICENSE=GPL-2 ssl? ( openssl-exception)

style LICENSE content at all iirc. Similar for all the patent-encumbered 
multimedia libs, which can't be distributed as binaries, but are not blocked 
by some bindist feature flag or so.


Carsten


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


Re: [gentoo-dev] Eigen and GPL-2 exception - is a new licence required?

2007-05-12 Thread Carsten Lohrke
On Samstag, 12. Mai 2007, Harald van Dijk wrote:
 On Sat, May 12, 2007 at 02:27:20PM +0200, Carsten Lohrke wrote:
  No. LICENSE=GPL-2 some-exception suffices.

 No, that means something completely different. It means that you should
 install the software only if you find both the GPL-2 and the exception
 acceptable, rather than if you find the combination of the GPL-2 with
 the exception acceptable.

And that's why it's not different. Such exceptions usually don't stand for 
themselves, but relate to the license they're bound to. Can be matter of the 
wording, though. 

I consider it quite stupid adding extra licenses for such exceptions.


Carsten


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


Re: [gentoo-dev] Eigen and GPL-2 exception - is a new licence required?

2007-05-12 Thread Carsten Lohrke
On Samstag, 12. Mai 2007, Harald van Dijk wrote:
 Do you need to accept the unmodified GPL-2 for software licensed under
 the GPL-2 plus exception? No? Then GPL-2 does not belong in LICENSE,
 unless in a || group.

Of course you accept the GPL plus the added exception. Just because an 
exception exists, it does not become a completely different license.


Carsten 


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


Re: [gentoo-dev] Switch to libchipcard3

2007-04-05 Thread Carsten Lohrke
Asking here and hoping everyone reads it may result in stable tree breakage. 
Open a bug and cc all maintainers of packages which depend on it, to get a 
definitive answer, please.


Carsten


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


Re: [gentoo-dev] RFC Package name additions

2007-03-17 Thread Carsten Lohrke
On Samstag, 17. März 2007, Jakub Moc wrote:
 Actually stuff like cat/pkg-1.2_alpha3_pre4 is valid now and honored by
 portage; dunno how does that fit the netbeans upstream scheme, though.

The additional postfix is reserved exclusively for user local ebuilds, not for 
the ones provided by us.


Carsten


pgpGn5BppX9RK.pgp
Description: PGP signature


Re: [gentoo-dev] RFC Package name additions

2007-03-17 Thread Carsten Lohrke
This is a valid argument for a single postfix with a lower order than alpha, 
but not a reason to add everything what's out there. I don't see the need to 
match upstream's versioning bit by bit. Honestly said I've never understood 
why our order is alpha, beta, pre and not pre, alpha, beta, which would fix 
the issue and match more closely what happens in the tree. Changing this 
might break the one or the other dependency, though. Last but not least to 
add that I consider adding snapshots of regular releasing upstream projects 
as a waste of ressources.


Carsten


pgp1NJc2BVkzW.pgp
Description: PGP signature


Re: [gentoo-dev] RFC Package name additions

2007-03-17 Thread Carsten Lohrke
On Samstag, 17. März 2007, William L. Thomson Jr. wrote:
 IMHO I think it should be up to the package maintainer how close they
 want to follow upstream. With regard to development, progress, testing,
 qa, feedback. I think it's a very good thing, since it allows things to
 be caught before actual releases, during development.

Doing this locally or in some development overlay is fine, but polluting the 
tree with every single development build is a bad idea, imho.


Carsten


pgp1uJsUyuQ6N.pgp
Description: PGP signature


Re: [gentoo-dev] RFC Package name additions

2007-03-17 Thread Carsten Lohrke
 Well that's the problem. When I use say _pre instead of _dev it gives
 off the wrong impression to users judging package by it's name. Since
 it's not a pre-release. A user may go upstream looking for some sort of
 pre-release. Which they won't find.

We have stable, testing and masked ebuilds. Nothing else the user should care 
about. If he does, he can more closely looking what's up himself.


Carsten


pgpxB7QSMPAm9.pgp
Description: PGP signature


Re: [gentoo-dev] RFC Package name additions

2007-03-17 Thread Carsten Lohrke
On Samstag, 17. März 2007, Petteri Räty wrote:
 It's already used by alsa-driver.

Then either me or the one doing so missed something on the discussion, why it 
was requested in the first place. Something to clarify in our ebuild policy.


Carsten


pgpUkMku2iZHo.pgp
Description: PGP signature


Re: [gentoo-dev] RFC Package name additions

2007-03-16 Thread Carsten Lohrke
There's absolutely no reason to absorb every single version naming scheme on 
earth. Gentoo's does work nicely and more than we have would only be 
irritating to the user. Simply use _predatecode  or whatever fits, but 
extending our naming scheme is unneeded and pointless.


Carsten


pgpcLcObgCmuK.pgp
Description: PGP signature


Re: [gentoo-dev] [RFC] custom-cflags global USE

2007-02-23 Thread Carsten Lohrke
On Freitag, 23. Februar 2007, Chris Gianelloni wrote:
 Except some things really do not compile with it enabled.  Now, if
 you're meaning you'd prefer patch every compilation failure using
 -ffast-math instead, then I'd say go for it.  Patches are always a
 better solution than workarounds.

I mean that having this flag set globally is plain stupid and everyone doing 
so deserves to deal with the consequences. Mike pointed out why.


Carsten




pgpRxcg0bw0RC.pgp
Description: PGP signature


Re: [gentoo-dev] Re: EAPI spec (was Re: Re: let's clear things up (was Slacker archs))

2007-02-22 Thread Carsten Lohrke
If that, what you stated in your last three paragraphs - and I do agree with 
it - will be the case, this proposed PMS will be dismissed and Paludis 
remains with a more or less accurate description, of what isn't a Gentoo 
package manager.


Carsten


pgpf4jh4lkHfG.pgp
Description: PGP signature


Re: [gentoo-dev] Reliance upon || ( use? ( ) ) behaviour

2007-02-22 Thread Carsten Lohrke
On Donnerstag, 22. Februar 2007, Ciaran McCreesh wrote:
 Inside || ( ) blocks, the package manager first removes any use? ( )
 blocks that are *immediate* (that is to say, not inside ( ) themselves)
 children if the use flag is not enabled (or disabled for !use?). Then,
 if the || ( ) block is empty, it is discarded.

[...]

 So, is there a legitimate reason for this complication to exist? Or
 should use? blocks being direct children of || ( ) be forbidden?


There's no other chance, than either fixing the package manager or forbidding 
it, I suppose.


What about the use  has_version double check!? Apart from being ugly and 
still needed in some cases, it isn't slot safe. Why don't we let the package 
manager unset the use flags corresponding to stripped optional depedencies, 
so the use check is valid again?


Carsten


pgpZXOCudepGp.pgp
Description: PGP signature


Re: [gentoo-dev] [RFC] custom-cflags global USE

2007-02-22 Thread Carsten Lohrke
On Mittwoch, 21. Februar 2007, Timothy Redaelli wrote:
 What do you think about custom-cflags global USE?

I'd be pleased to see the flag removed. I think it's up to the maintainers, if 
they accept bug reports due to custom cflags, even though upstream doesn't or 
restrict them for other reasons. If people care so much about it, there's 
always your local overlay.


And I'd be fond of having all the -ffast-math filtering ripped out of the tree 
as well.


Carsten


pgpdsxB8mPYMU.pgp
Description: PGP signature


Re: [gentoo-dev] Reliance upon || ( use? ( ) ) behaviour

2007-02-22 Thread Carsten Lohrke
On Freitag, 23. Februar 2007, Ciaran McCreesh wrote:
 Because the solution doesn't generalise. Consider:
   || ( a? ( a ) b ) a? ( a2 )

I didn't imply it to be a solution to the || ( use? ) problem you started the 
thread with.

 And because it makes things more rather than less complicated...

Sure, but either we need to touch the env, change useq() to look up additional 
information, provided by the package manager or has_version needs to become 
slot safe - well, it may need to anyways.


Carsten


pgpyLBGsDHjMw.pgp
Description: PGP signature


Re: [gentoo-dev] Only you can prevent broken portage trees

2006-10-30 Thread Carsten Lohrke
On Monday 30 October 2006 14:23, Ferris McCormick wrote:
 I might be mistaken, but I believe sparc responds pretty quickly to
 security bugs, either by taking the requested action or by explaining
 why the requested action is impossible (i.e., build problems).

Yes, the Sparc team is rather quick - even among security-wise supported 
architectures. None of the archs cc'ed to the bug in question is 
security-wise supported. We communicate this is our vulnerability policy¹ 
page - a bit too hidden for my taste.


Carsten


[1] http://www.gentoo.org/security/en/vulnerability-policy.xml


pgpuk28mu5vmO.pgp
Description: PGP signature


Re: [gentoo-dev] SPF at g.o

2006-10-26 Thread Carsten Lohrke
On Thursday 26 October 2006 22:41, Jakub Moc wrote:
 +1 ... SPF is broken by design.

Right¹. Don't understand why it gets used either.


Carsten


[1] http://homepages.tesco.net/J.deBoynePollard/FGA/smtp-spf-is-harmful.html


pgp9zuYplnFtJ.pgp
Description: PGP signature


Re: [gentoo-dev] New project: Gentoo Seeds

2006-09-19 Thread Carsten Lohrke
First step should imho be, that you work with the Portage team on having 
proper set support implemented. Current meta ebuilds do suck, really.


Carsten


pgpY3uwbpcikw.pgp
Description: PGP signature


Re: [gentoo-dev] Re: Re: Re: packages going into the tree with non-gentoo maintainers

2006-09-07 Thread Carsten Lohrke
On Thursday 07 September 2006 07:58, Stefan Schweizer wrote:
 I am part of the kde herd, thanks.

To my knowledge you have never asked to join the KDE team, nor did I see you 
helping tracking down KDE bug reports ever. Just adding yourself doesn't 
work.


Carsten








pgp7tjbj1KWLV.pgp
Description: PGP signature


Re: [gentoo-dev] Re: Re: packages going into the tree with non-gentoo maintainers

2006-09-07 Thread Carsten Lohrke
On Thursday 07 September 2006 13:25, Diego 'Flameeyes' Pettenò wrote:
 I'll try to overlook the reverted changes in kdelibs for bug fixes, the
 improper ${ROOT} injected in my changes where it wasn't supposed to be, the
 broken opengl on kdelibs checks that appeared last month, unhelpful
 comments when trying to achieve something from the users, a bug lingering
 for an year and a half because my solution wasn't good enough, and that was
 the solution that now kde 3.5.4 implements, decisions against the interest
 and request of all the users and developers, QA bugs opened without
 checking facts, GWN articles sent without notes on [EMAIL PROTECTED] alias 
 for what I
 can see ...

I do make mistakes too, yes. That I did revert your changes was a problem with 
a local script - still - my mistake. No idea what you're referring to with 
your unhelpful comments stanza as well as the bug lingering around. There 
are a lot of bugs lingering around and I do not have a todo list tracking 
them in a specific time frame. QA bug_s_? Regarding the GWN, you should have 
gotten the email, in  which I pointed out that it's time to remove KDE 3.4 
from the tree.


Carsten




pgpiZ8MyhPkOO.pgp
Description: PGP signature


Re: [gentoo-dev] Re: Re: packages going into the tree with non-gentoo maintainers

2006-09-07 Thread Carsten Lohrke
On Thursday 07 September 2006 13:48, Jakub Moc wrote:
 I wonder how exactly genstef broke mips, 'cos mind you, he just reverted
 to what the ebuild was doing before Bug 114161 was fixed by
 hard-disabling of hspell [1]. Since mips doesn't have hspell keyworded,
 it wasn't affected by that bug before it's been fixed and it wasn't
 affected after the bug has been reintroduced now [2] (Additionally there
 shouldn't be any problem now except for one called automagic
 dependencies since the blocker for incompatible versions was there).

You're right. It was very early in the morning, I saw the dependency not 
matching architectures, but wasn't aware that blocker dependencies are not 
taken into account with regards to tree breakage. So:


Dear Stefan,

I was wrong, you didn't break the tree. Please excuse that I did accuse you 
doing this. I regret not having verfied my position, before i filed the bug. 
Furthermore I'd like to add that, as blubb put it in an private email, my 
intention wasn't to put you down, but to shed light on the issue - apparently 
making myself a fool.



One question remains: Is it needed/correct that Portage doesn't take blockers 
for architecture breakages into account? Such a line/prefix is easily changed 
and when someone - whatever the bad reason is - uses cvs commit, a real tree 
breakage is the cause.


Carsten


pgpLpkRTXiwfL.pgp
Description: PGP signature


Re: [gentoo-dev] Re: Re: packages going into the tree with non-gentoo maintainers

2006-09-07 Thread Carsten Lohrke
What have we learnt now, Jakub? Keep it in the bug report. ;)


Carsten


pgpxG13G6keIP.pgp
Description: PGP signature


Re: [gentoo-dev] Re: Re: packages going into the tree with non-gentoo maintainers

2006-09-06 Thread Carsten Lohrke
On Sunday 03 September 2006 16:36, Stefan Schweizer wrote:
 I am not adding stuff. I am fixing existing packages. And I am taking
 responsibility.

How wonderful this sort of maintenance is you can read here:

https://bugs.gentoo.org/show_bug.cgi?id=146626

Am I the only one who has a problem with this?


Carsten


pgpSw3egf3SKv.pgp
Description: PGP signature


Re: [gentoo-dev] packages going into the tree with non-gentoo maintainers

2006-09-03 Thread Carsten Lohrke
On Sunday 03 September 2006 11:20, Kevin F. Quinn wrote:
 triggered by bug #77751: hspell lists a non-gentoo.org address for
 the maintainer email, the herd as maintainer-needed, and no other
 addresses.

 Is this sort of thing now ok?

No.


Carsten


pgpLh7ZV4WbmG.pgp
Description: PGP signature


Re: [gentoo-dev] Re: The Age of the Universe

2006-09-03 Thread Carsten Lohrke
Either MTA or MUA brokeness. Another email I have to send a second time. :(

On Sunday 03 September 2006 00:42, Diego 'Flameeyes' Pettenò wrote:
 And waiting other 2, 3, 4, 5, 6 months won't change the thing. Why? Because
 we have _no_ accessibility team right now. 

Well, the bug is assigned to williamh, who is not /completely/ inactive. I 
wonder, if only 37 commits in more than two years suffices for cvs access, 
though.

 If we had one, the problem would 
 have been solved. Unfortunately that software is doomed to lag behind the
 rest of Gentoo unless someone maintain it. If it wasn't for the need of
 that software by some users, probably treecleaners would have removed that
 already.

 In _this_ particular case, the notice interval is not important.

You're wrong here. What I'm inclined about is that we had (leastwise) a 
fourteen day short notice to when the releaase snapshot would be taken. To 
the end of this time frame there was another one that we'd release with GCC 
4.x. Even if we had enough people to deal with everything thrown at us,it 
would have been impossible to fix and stabilize the relevant packages on all 
architectures. 

If I had known this as estimated goal two months earlier, I'd had switched to 
GCC 4.x a while before and noticed the bug, instead when it is too late. I 
consider this part of what is broken within Gentoo communication-wise.


Carsten


pgp7FXmWvXFt3.pgp
Description: PGP signature


Re: [gentoo-dev] Re: The Age of the Universe

2006-09-03 Thread Carsten Lohrke
On Sunday 03 September 2006 00:42, Diego 'Flameeyes' Pettenò wrote:
 And waiting other 2, 3, 4, 5, 6 months won't change the thing. Why? Because
 we have _no_ accessibility team right now. 

Well, the bug is assigned to williamh, who is not /completely/ inactive. I 
wonder, if only 37 commits in more than two years suffices for cvs access, 
though.

 If we had one, the problem would 
 have been solved. Unfortunately that software is doomed to lag behind the
 rest of Gentoo unless someone maintain it. If it wasn't for the need of
 that software by some users, probably treecleaners would have removed that
 already.

 In _this_ particular case, the notice interval is not important.

You're wrong here. What I'm inclined about is that we had (leastwise) a 
fourteen day short notice to when the releaase snapshot would be taken. To 
the end of this time frame there was another one that we'd release with GCC 
4.x. Even if we had enough people to deal with everything thrown at us,it 
would have been impossible to fix and stabilize the relevant packages on all 
architectures. 

If I had known this as estimated goal two months earlier, I'd had switched to 
GCC 4.x a while before and noticed the bug, instead when it is too late. I 
consider this part of what is broken within Gentoo communication-wise.


Carsten



pgpakM3TID5rc.pgp
Description: PGP signature


Re: [gentoo-dev] Re: The Age of the Universe

2006-09-02 Thread Carsten Lohrke
Seems my message got swallowed...

On Saturday 02 September 2006 15:36, Edgar Hucek wrote:
 Just a side hint. Try to enable all flags at the first cimpile time would
 reduce trys drasticaly ;)

There are lots of use flag combinations incompatible with each other within a 
package as well as packages relying on other ones to be build with or without 
use flags of other packages. The number of pssoble combinations would is too 
high, even if we had build servers running around the clock.

In case of point two, you're right, that it doesn't let Gentoo look good. 
Neither Gnome nor KDE (no use flag in this case) accessibiliy stuff builds 
now - and bug 116030 is open since nine months. Partly the problem is that 
we're understaffed, partly - and this is my very personal opinion - the 
problem is that releasing with GCC 4.x has been rushed - speak the notice 
came one or two months too late.


Carsten



pgprBvF4mMjmx.pgp
Description: PGP signature


[gentoo-dev] cdrtools license issues

2006-09-01 Thread Carsten Lohrke
As discussed here¹, the author of cdrtools, Jörg Schilling, violates the GPL 
in his application, by building GPL software with CDDL licensed makefiles as 
well as linking mkisofs to libscg, which he relicensed to CDDL lately. Debian 
seems to fork² cdrtools therefore.

Imho we have to remove the partly and incompatible relicensed cdrtools-2.01.01 
alpha ebuilds from the tree.


Carsten


[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=377109
[2] http://svn.debian.org/wsvn/debburn

-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Re: cdrtools license issues

2006-09-01 Thread Carsten Lohrke
On Friday 01 September 2006 14:51, Lars Weiler wrote:
 We have a lot of other applications in the tree, which is
 not free.

The problem is not that it's not free*, but that linking GPL and CDDL code 
violates the GPL. If the whole cdrtools code were CDDL, there were no 
problem. 

*The OSI considers the CDDL as free.


Carsten


pgpDWotc8Gwww.pgp
Description: PGP signature


Re: [gentoo-dev] repoman: check for deprecated eclasses

2006-09-01 Thread Carsten Lohrke
The file listing the derecated overlays is fine. What about revdep-rebuild and 
emerge regarding installed stuff and overlays?


Carsten


pgpMpDspMcPVc.pgp
Description: PGP signature


Re: [gentoo-dev] Re: cdrtools license issues

2006-09-01 Thread Carsten Lohrke
On Friday 01 September 2006 15:45, Luis Medinas wrote:
 I'm sure that situation will be fixed by the upstream (Jörg) since it
 violates GPL license. About the debian fork we will take a look at it
 and see where's going.

Read the Debian bug. Jörg Schilling is badmouthing Debian developers and tells 
everyone that they should _believe_him_ that the CDDL is compatible with the 
GPL, while no one else thinks so. It is unlikely that the overly 
self-convinced Jörg Schilling will change his mind. I'd be surprised, if the 
situation will be fixed upstream.


Carsten


pgpI0iLWWx8Lz.pgp
Description: PGP signature


Re: [gentoo-dev] Suggestion: Globalness of some USE flags

2006-08-31 Thread Carsten Lohrke
On Thursday 31 August 2006 16:58, Simon Stelling wrote:
 I think we agreed at least 3 times on that the logrotate use flag
 shouldn't exist at all because those files add 4kb to the package.

Right. Open a bug and cc involved maintainers. This is the way it works - 
maybe slowly, but it does. We see people come and go and no one has the time 
to assure to have read all threads in this list. A bug stays open as long as 
it is relevant.

 About the udev, there's one package that doesn't share the effect:

 sys-apps/pcmciautils:udev - Install as an udev helper instead of a
 hotplug helper

 Which is different from the other 5 Enable udev rules file installation.

Two packages. Question is, if there is an argument not to install udev rules.


Carsten


pgpaC0DvVf3xu.pgp
Description: PGP signature


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

2006-08-24 Thread Carsten Lohrke
On Thursday 24 August 2006 09:54, Donnie Berkholz wrote:
 The council doesn't actually do anything AFAICT, it just approves GLEP
 decisions that have already been made. So in effect we have no leadership.

Well, to quote the council project page:

The elected Gentoo Council decides on global issues and policies that affect 
multiple projects in Gentoo.

and from GLEP 19

Global issues will be decided by an elected Gentoo council.

So yes, the council is not elected to rule into decisions of single Gentoo 
project decisions, unless it affects Gentoo globally. What global issues 
are can be argued about, though. Personally I see the council as our body to 
make decisions and wouldn't disagree to reword the base on which the council 
acts to give them explicitly the power to decide on whatever they feel they 
have to, if necessary - except being bound to have to be re-elected.


I'm not as long on board as you Donnie, but I don't think you're right with 
your implicit call that we need a benevolant dictator. There's simply no 
evidence, that this model would have done better with Gentoo's growth. I have 
at least one big point I could list, what went wrong, while Daniel Robbins 
was the lead. Ask me privately, if you're interested what I mean. I don't 
want to let others look bad or be the source of flaming.


Carsten


pgp03mRELPhBR.pgp
Description: PGP signature


Re: [gentoo-dev] Re: User support system [WAS: Sunrise contemplations]

2006-08-17 Thread Carsten Lohrke
On Thursday 17 August 2006 21:42, James Potts wrote:
 hmmmdoesn't the GNU ClassPath implement enough of Java's runtimes
 to handle a command-line app like this

When it is at 100% 1.4 compatibility (and that does not mean nearly as bug 
free, stable, fast, etc. as Sun's Java is), the latter will be at 1.6 and the 
apps follow. Just forget about Java, when it comes to software that needs to 
be available on multiple architectures. Period.


Carsten


pgpNeN7opJior.pgp
Description: PGP signature


Re: [gentoo-dev] SearchSecurity.com: Linux patch problems: Your distro may vary

2006-08-07 Thread Carsten Lohrke
As far as I'm aware the problem isn't the security team, but the reasons are:

1. slow/understaffed arch teams - and I suppose this is the biggest problem, 
as we need all security-wise supported¹ architectures stable, before a GLSA 
can be send out.

2. the amount of unmaintained stuff in the tree, no one cares for - see Sune's 
libwmf email

3. maintainer on vacation or for another reason inactive and didn't 
communicate that - no co-maintainer, no herd backing up, leaving everyone 
waiting.


This ranking of course does neither say anything about the quality of the 
fixes, nor does the severity Secunia applies to an issue necessarily match 
the our's or other distribution security teams.



Carsten


[1] http://www.gentoo.org/security/en/vulnerability-policy.xml


pgp03USjwtQMx.pgp
Description: PGP signature


Re: [gentoo-dev] implicit RDEPEND

2006-08-07 Thread Carsten Lohrke
On Sunday 06 August 2006 00:26, Mike Frysinger wrote:
 and i'm on the opposite side where implicit RDEPEND should be clean:

Why? I for one consider explicit dependencies much more clean. If Portage at 
some point should distinct between dependencies defined in ebuilds and 
eclasses, we'd need a defined way to set eclass dependencies in ebuilds, so 
Portage actually can do the distiction, not breaking the tree. 

 - eclass and ebuilds have their own sets of DEPEND/RDEPEND which do not in
 any way affect each other

That's not true. We use and need the functionality to set dependencies in the 
ebuild which take effect in the eclass. Be it by setting a variable before 
inherit or by an eclass function called from within the ebuild - need-kde(), 
need-apache(), ...

We can't source the eclass and have all its dependencies.


Carsten


pgp5cqj7dHWL2.pgp
Description: PGP signature


Re: [gentoo-portage-dev] has_version and built_with_use ignore package.provided

2006-08-07 Thread Carsten Lohrke
Checking for a package that isn't either a direct or indirect dependency is 
plain wrong. package.provided is not supported - it's the users fault, if he 
insists to sidestep Portage. There is no valid case for your construct. With 
regards to QA, it wouldn't be wrong to have a better solution, but given that 
built_with_use() is itself only a workaroud for still not having use 
dependencies, it's a bit pointless.


Carsten


pgpIcKouSDHXT.pgp
Description: PGP signature


Re: [gentoo-portage-dev] has_version and built_with_use ignore package.provided

2006-08-07 Thread Carsten Lohrke
On Monday 07 August 2006 23:39, Paul Bredbury wrote:
 That's what SpanKY said. Then he fixed quake2-data in bug #139693 to
 include has_version, simply to hide the broken behaviour of
 built_with_use.

 So, would you have fixed the bug differently, or are you using the word
 plain in the hope that you're right without having looked at the bug?

Well, I don't have the time to read all the discussions and read only the last 
few replies of this one. Looking at the ebuild, I'd argue quake2-demodata and 
quake2-data should block each other, but I might be wrong, since I don't know 
the package. 

The word plain - drop it, it's still wrong. :)


Carsten


pgpjrPSsrRMf6.pgp
Description: PGP signature


Re: [gentoo-dev] Project Sunrise resumed again (was Resignation)

2006-08-03 Thread Carsten Lohrke
On Thursday 03 August 2006 04:56, Brian Harring wrote:
 *cough*.  bit hypocritical for you to lecture me about viewing
 your statements as 'flaming', and in the same breath label
 my own as 'flaming' ;)

 Why am I pointing this out?  My initial points were that of why the
 double standard, with you providing an apt example (while that's
 barbed, you did provide a perfect refresher of the definition).

The difference is that I argue, while you accuse me to play false. I consider 
this as ad hominem and together with all this FUD and BS calling, in 
contrary to my email, inflammatory.


  I'd appreciate, if you would try to have a controversial
  discussion, without starting to loose your manners.

 And I'd appreciate a less condescending tone.

This wasn't meant condescending, but a true request. Because it's not the 
first time you react this way, when you dislike another ones opinion. It is 
as annoying as Ciaran's habit to make statements without backing them up - 
even when asked to do so.


 You wrote 'no security'.  That's pretty fricking vague, can cover
 everything from no verification of sync'd contents, to their vcs
 security, to their screening processes, to vulns in their packages.

I wrote that you should read my replies in the initial thread.


 If you wanted to home in vulns in the source (which isn't security as
 much as 'vulnerabilities in the source'), be explicit.

I was.


 Now on to the real points (yay)...

  My point isn't that
  people add malicious ebuilds to the overlay. There're more subtle methods
  anyway, given that the tree still isn't signed. I wrote about
  vulnerablities in the upstream software, neither having a security team
  backing them up nor GLSA's to be written.

 1) same issue with the ebuilds sitting in bugzilla, going to hunt
 through bugzie marking each submitted ebuild when a security bug hits?

 2) Response to that is that there is no claim of support- which is
 the same for sunrise.  Why are the rules different for sunrise then?

The difference is that people are using them in their local overlay and 
therefore - in contrary to the Sunrise overlay - a) are only exposed to the 
packges they _really_ want to use and b) are responsible for it themselves.

Aside of this I might add that I do add comments to bug reports, when I 
stumble about vulnerability notices and find relevant bug reports.


 3) Assumption that sunrise will just be a dumping ground, without any
 form of maintainance is implicit here- if it becomes as such, already
 was stated it would get wedgied by the council.  So that leaves the
 angle of they don't have a security team, which implies to actually
 handle nuking vulnerable ebuilds, one has to have a security team
 (obviously false).

Dumping ground or not. It's easy to miss vulnerability notices. Especially, if 
you don't have guys who expclicitly care for it. And you need a security team 
to announce issue to the user base. I wouldn't use Gentoo, if we not had such 
a hard and good working security team.


 Besides... frankly it's kind of BS to push the vuln angle onto sunrise
 when gentoo can't even clean out years old vulnerable packages from
 gentoo-x86 (that doesn't absolve sunrise from having to watch it, nor
 a potshot at the understaffed security team, merely that double
 standards suck).

Interesting to see you state this. Because this is a far more serious problem, 
than supporting everything possible; And Sunrise won't fix this either - if 
not the opposite. One of the goals of Sunrise is to recruit new devs. But we 
don't need new devs to add new packages primarily, we more to maintain 
existing and not so fancy stuff and to clean out the tree.


 You want to set a standard for 'em, fine, lets use the standard of the
 existing tree when compared to existing glsas- note that there may be
 vulns that gentoo doesn't have glsas for, or vulns that are in the
 security pipeline and haven't yet been issued as a glsa (since gentoo
 issues it after porting).

 285 versions out of 24637 vulnerable (~1 out of every 86 vuln)
 115 packages out of 11251 vulnreable (~1 out of every 98 vuln)

 http://gentooexperimental.org/~ferringb/vuln.log

 So... if that's the standard you want to hold them to, fine, state
 so- they may agree to it (although admittedly such a standard is
 stupid, there should be _no_ vuln packages).

Your list is rubbish. There're stable versions for all security wise supported 
architectures and the relevant GLSA's. If users don't use them, it's their 
local problem.


   And... just cause I'm mildly sick of this bullshit,
 
  And I'm sick of people, who miss the point.

 As stated above, be concise then.  Your points came out of pretty
 much nowhere, poorly communicated, and rather vague in actually
 backing them up.  Which... at least from the backing up the
 complaints, has been the theme for the screaming folk thus far.

Do I have to learn you to read? See above.


  We can change eclasses all the time, assuming all 

Re: [gentoo-dev] Resignation

2006-08-02 Thread Carsten Lohrke
On Wednesday 02 August 2006 05:50, Richard Fish wrote:
 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.

Well, as long as there's no big fat warning that there's not support, no 
security team backing it up - and that the overlay is not meant for general 
consumption, it's very problematic. On the contrary, it's written down that 
the overlay is meant to make a wide range of ebuilds easily available - 
without any measures to secure its consumers.


Carsten


pgphw9JvVbUt5.pgp
Description: PGP signature


Re: [gentoo-dev] Project Sunrise resumed again (was Resignation)

2006-08-02 Thread Carsten Lohrke
First I'd like to state that I do offer my opinion. You don't have to like it, 
but disqualifying it as flaming, while exactly doing this yourself, 
disqualifies you. I'd appreciate, if you would try to have a controversial 
discussion, without starting to loose your manners.


On Wednesday 02 August 2006 03:39, Brian Harring wrote:
 1) no security,

 Suggest you read their responses, and look into some of their material
 (in particular their faq).

 Two levels.

 One, holding area (essentially).
 Second level (what users get), is the reviewed branch.

 So... if you're arguing people can stick malicious shit into the first
 level, yes, they could.
 [...] 

You haven't read what I wrote, as I asked you to do. My point isn't that 
people add malicious ebuilds to the overlay. There're more subtle methods 
anyway, given that the tree still isn't signed. I wrote about vulnerablities 
in the upstream software, neither having a security team backing them up nor 
GLSA's to be written.


 And... just cause I'm mildly sick of this bullshit,

And I'm sick of people, who miss the point.


  2) issues with eclass changes which will result in bug spam

 You're not supposed to change the exposed api of eclasses in the tree
 (something y'all do violate I might add, which is a seperate QA
 matter).  Same issue applies to the 'official' overlays offered by
 devs also, and to the tree in general.

We can change eclasses all the time, assuming all relevant ebuilds in the tree 
get adjusted - just that no one cares for any overlay.

 It's a reaching statement, bluntly.  Using such an arguement has the
 side affect of stating that no overlays should ever exist, because
 they suffer the same potentials.

Local overlays are fine as the user exactly knows what he does in his private 
overlay (and hopefully follows eclass changes), development overlays are fine 
(assuming the group of people controls the releavant overlays as well), 
overlays like Sunrise are problematic, not to use such anal words as you do.

  3) the fact that sunrise is a bunch of arbitrary packages, instead close
  related ones managed by one team, that does exactly maintain relevant
  packages.

 What the hell do you think the tree is?  It's a bunch of arbitrary
 packages maintained loosely by subgroups of people; you're stating
 that sunrise is too loose yet gentoo-x86 is fundamentally no
 different.

 Sunrise is pretty much the same damn thing.

Exactly that isn't right. No one cares for compatibility of the main tree 
(eclasses, conflicts between ebuilds with regards to installed files) and 
Sunrise ebuilds.


Carsten


pgppgHR1KggPH.pgp
Description: PGP signature


Re: [gentoo-dev] Resignation (was: Project Sunrise resumed)

2006-08-01 Thread Carsten Lohrke
On Monday 31 July 2006 04:52, Mike Frysinger wrote:
 On Sunday 30 July 2006 22:28, Dan Meltzer wrote:
  1) Users can submit patches/ideas to bugs.g.o at whatever frequency
  they desire, contributing to gentoo casually.

 load up your browser and check out how many bugs are assigned
 to '[EMAIL PROTECTED]'

This isn't the problem. We'll never can maintain all this stuff - given the 
number of people we're. We need more devs - just to clean up the current tree 
and maintain it properly at it's current size one- or two hundred (having 
fluctuation in mind) more guys wouldn't harm. The problem is more that we 
have devs who constantly add (arbitrary) stuff to the tree, instead cleaning 
out and caring for unmaintained stuff, before adding something new.

 opening a bug, putting together an ebuild/patches/etc..., and then watching
 it sit there and bitrot for weeks, months, and in the extreme case years
 certainly is anything but encouraging

 especially considering that by the time a developer gets an interest in the
 posted ebuild, the ebuild/patches/etc... are now bitrotted and need just as
 much work to get them up and working with the latest release

This is still a community distro. That means we need people who want to become 
become devs to maintain more. That simple. Surise won't help in this regard. 
It's just an extended repository for lazy people, who don't care for security 
with the side effect of increased bug spam.

 plus the timeframe from saying hey i'd like to develop to actually
 getting your own commit access is heftier than many would like to undertake
 ...

Is it? I got new devs on board within a few weeks. It could always be better, 
but I think that's reasonable. Do you have numbers? Has devrel a statistic? 
In my experience it's more that a lot of people moan, but don't want to 
become active.


Carsten


pgp3cv7QN61Oo.pgp
Description: PGP signature


Re: [gentoo-dev] Project Sunrise resumed again (was Resignation)

2006-08-01 Thread Carsten Lohrke
On Monday 31 July 2006 07:05, Seemant Kulleen wrote:
 OK, let's start with: what exactly is the problem?

Please reread my replies in the first sunrise thread. Points are: no security, 
issues with eclass changes which will result in bug spam, the fact that 
sunrise is a bunch of arbitrary packages, instead close related ones managed 
by one team, that does exactly maintain relevant packages. These issues are 
fundamental, pointed out multiple times. You can't believe how ridiculous 
Mike's question in the other thread, if there were any remaining issues, 
sound to me and obviously others.

From your other email:
People actually quit over this issue, which is pretty unfathomable to me.
Um, thought about it as well. One of the reasons I'm less active the last 
weeks.


Carsten


pgpM9mIuIzqma.pgp
Description: PGP signature


Re: [gentoo-dev] Resignation

2006-08-01 Thread Carsten Lohrke
On Monday 31 July 2006 13:01, Christian Andreetta wrote:
 Seemant Kulleen wrote:
  On Sun, 2006-07-30 at 23:50 -0400, Brett I. Holcomb wrote:
  My concern is beyond me.  As I  stated I know enough about what to
  expect IF I use sunrise.  But many do not and with it becoming official
  people figure it's gentoo and when it breaks Gentoo suffers.  Gentoo has
  a reputation as a good solid, stable distro.  As user and big fan of
  Gentoo I'm concerned - why couldn't sunrise have stayed unoffical like
  BMG.  Why does it have to be official?  Gentoo can choose to do what it
  feels is right and I will do the same.

 It has just to be put clear that in this case official doesn't mean
 solid, right, tested by our best QA, but simply preferred. That
 is, I think we're not speaking of official, but _basically_ revised
 and encouraged.

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.


Carsten


pgpskfhmux16K.pgp
Description: PGP signature


Re: [gentoo-dev] Project Sunrise resumed again (was Resignation)

2006-08-01 Thread Carsten Lohrke
On Thursday 01 January 1970 01:00, Alec Warner wrote:
 eclass changes?  You can't even commit eclasses to it...

Eclass changes in the main tree, including all relevant ebuilds updated, but 
breaking the ebuilds in the Surise overlay, having whining users or borked 
systems in the worst case.


Carsten


pgpbBODt0RBXc.pgp
Description: PGP signature


Re: [gentoo-dev] Re: [RFC] Useflags: qt, qt3, qt4?

2006-06-21 Thread Carsten Lohrke
On Wednesday 21 June 2006 15:44, Stefan Schweizer wrote:
 qt3 and qt4 is being used there already and it is obvious

It's nice to invent new use flags affecting Qt stuff without contacting 
those who care for Qt.

  2) A package requires either Qt3 or Qt4 (both not both?...such as
  x11-libs/qwt-5).

 qt3 - enable optional qt3 support
 qt4 - enable optional qt4 support

That will be a mess to support in the long run. Let's go with that what works 
better, prefer the latest version and be fine with it. I do agree with Caleb 
to use the qt use flag for the latest supported version and in cases it is 
really necessary to have an additional qt3 use flag.


Carsten




pgpK1ne4gh5sC.pgp
Description: PGP signature


Re: [gentoo-dev] variable quoting, setting optional variables to , and depending on virtual/libc

2006-06-17 Thread Carsten Lohrke
On Saturday 17 June 2006 14:39, Michael Cummings wrote:
 Kevin F. Quinn wrote:

  If RDEPEND is not set, it is defaulted to $DEPEND by portage.

 Alas, if only. If you inherit an eclass with deps this carry over won't
 happen. (And I have the bugs to prove it ;)

Well, has been the job of the eclass the ensure that, of course. But since 
Portage 2.1 this is deprecated anyways and every developer is expected to set 
RDEPEND explicitly, including RDEPEND=$DEPEND, if necessary. Unfortunately 
the ebuild policy has still not been updated.

See also https://bugs.gentoo.org/show_bug.cgi?id=135945


Carsten



pgpdjW6YaQV7L.pgp
Description: PGP signature


Re: [gentoo-dev] Herds suck, fix them

2006-06-17 Thread Carsten Lohrke
On Saturday 17 June 2006 04:51, Christel Dahlskjaer wrote:
 How exactly does one go about maintaining our developers? ;)

It's devrel's cursed job. Ask them. :)


Carsten


pgpDHDEmEDUMI.pgp
Description: PGP signature


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

2006-06-09 Thread Carsten Lohrke
On Friday 09 June 2006 12:12, Chris Bainbridge wrote:
 This larger group of users are the ones that would benefit
 from an overlay.

And this larger group of people is exactly the same one, that doesn't know to 
help itself, if necessary and will suffer the most, when something goes 
wrong. This group of people shouldn't use any overlay.

I think the basic misconception is that some think we are supposed to provide 
a package just because it's requested. We need maintainers for every package. 
Without maintainers: Sorry, no. Period.


Carsten


pgpmveiBPApcq.pgp
Description: PGP signature


Re: [gentoo-dev] What is official?

2006-06-09 Thread Carsten Lohrke
In my eyes only the main tree is official. The overlays are development niches 
(and as such perfectly fine), to speed up development without causing much 
trouble in the main tree. The problem is that overlay.g.o is seemingly 
official, because we host it. It should be made more clear that this isn't 
the case.


Carsten


pgp3UHsgOxWZ5.pgp
Description: PGP signature


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

2006-06-09 Thread Carsten Lohrke
On Friday 09 June 2006 02:53, Stefan Schweizer wrote:
  It also doesn't answer the questions of security and maintenance.  Are
  genstef and jokey going to be responsible for the security of every
  single package in the overlay?

 Yes, we will be acting upon all issues that we hear about.

...

  that is neither supported security wise, nor is
  ensured that the ebuilds have a minimal quality (do not fubar a users
  system).

 we do support it security wise, we will be reacting upon security issues.
 We do have package.mask support in the overlay and we are going to use it.
 The ebuilds have a quality, repoman is required to be run. Also
 contributors should be knowing what they are doing - they are submitting an
 ebuild to the sunrise overlay, it needs to follow certain standards.

See, I don't go over this bridge, that an overlay of arbitrary packages, with 
varying skills and knowledge needed, can be decently controlled with very few 
people caring and not having a security team backing you up.


Carsten


pgpjJeyxOwK7k.pgp
Description: PGP signature


Re: [gentoo-dev] Project Sunrise thread -- a try of clarification

2006-06-09 Thread Carsten Lohrke
This may work for Apache or PHP, but an overlay with arbitrary maintainer 
wanted ebuilds would need an extra bugzilla account. The problem is that 
this won't really help, since (some) users will see oh, an kde app crashed 
and file a bug at [EMAIL PROTECTED] Then /me looks at the tree, doesn't see the 
package and marks the bug as invalid. Even worse it is for bug wranglers. You 
hardly can expect that they look up every single overlay. 

You should at least make it visible in bold letters on the overlay.g.o front 
page, what the conditions of each overlay are and which [EMAIL PROTECTED] 
address bugs 
have to be assigned to. Also some warning that an overlay may break the tree 
or fubar the users system and that only the one who uses it, is responsible 
for using it, wouldn't be wrong.


Carsten


pgpbOuaBdZ6Hq.pgp
Description: PGP signature


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

2006-06-09 Thread Carsten Lohrke
On Friday 09 June 2006 13:44, Peter wrote:
 Secondly, my bias against a third party repository is perhaps unwarranted.
 I am sure the bmg site is excellent and the people running it are
 well-intentioned and experienced. However, that said, as a user, I have a
 higher comfort level staying in the gentoo.realm.

It's not. The problem is, that the assumption an overlays.g.o overlay of the 
sort we speak about would be better, is false.


Carsten


pgpbAFzd7YMoI.pgp
Description: PGP signature


Re: [gentoo-dev] Re: Project Sunrise thread -- a try of clarification

2006-06-09 Thread Carsten Lohrke
On Friday 09 June 2006 14:04, Stefan Schweizer wrote:
 Please, do not assume our users being stupid. They know that they are using
 an ebuild from the sunrise overlay with zero support. They deliberately
 typed

You have said stupid, not me. Some won't care enough, I'm quite sure about 
that. We had such invalid bug reports occasionally in the past and I expect 
this to happen more often, the easier and more common dealing with overlays 
becomes. Regarding zero support: Making this abslutely clear is what I miss 
looking at overlays.g.o.

 svn co http://overlays.gentoo.org/svn/proj/sunrise/category/application;
 emerge application

 And also there are only applications from maintainer-wanted or
 maintainer-needed allowed in the overlay. Because packages are not supposed
 to overwrite files from other ebuilds it is unlikely that they can cause
 any damage to applications that have not been directly installed from the
 overlay.

maintainer-needed is imho not acceptable at all, as any dev trying to clean up 
bugs, won't know if a bug report comes from a user of the main tree ebuild or  
from your overlay.

  Also some warning that an overlay may
  break the tree or fubar the users system

 That is not the intention of the overlay.

If it were intended, it would be malicious. Even if not intended, it doesn't 
mean tree breakages won't happen. Some dev may change an eclass, without 
taking overlay ebuilds into account (and he doesn't have to), but the change 
may break all ebuilds inheriting the eclass in an overlay, leaving all the 
users of the overlay with a broken tree. And to make that clear: Eclasses in 
overlays are only sort of acceptable, when the same team handles the eclass 
in the the main tree, as eclasses in overlays hide the main tree eclasses.


Carsten



pgpU7l3V10Wea.pgp
Description: PGP signature


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

2006-06-08 Thread Carsten Lohrke
On Thursday 08 June 2006 02:42, Stefan Schweizer wrote:
 Initially jokey and myself will be working on this. The current focus is to
 migrate ebuilds from bugzilla into the overlay and to get contributors to
 commit their changes to the overlay instead of updating the bugzilla every
 time.

Can't agree with that. Users should a) post their ebuilds at bugzilla, since 
it is the place, we track request and b) get them from there, forced to 
maintain their own overlay (and actually look at each ebuild), than trust 
some arbitrary overlay, that is neither supported security wise, nor is 
ensured that the ebuilds have a minimal quality (do not fubar a users 
system).

Overlays make sense to perform changes how a whole range of packages are 
handled, to be merged with the official Portage tree, later. 

What you intend to do is just broken. Don't!


Carsten


pgpxYMIpJj0pw.pgp
Description: PGP signature


Re: [gentoo-dev] Default useflag cleanups: -apm -foomaticdb -fortran -imlib -motif -oss -xmms

2006-06-06 Thread Carsten Lohrke
On Tuesday 06 June 2006 04:45, Andrew Muraco wrote:
 Sorry for the offtopic of this, but what would a user set as the
 useflags to have GTK-2 used by default, and GTK-1 for apps that only
 support it? (but not build GTK-2-capable apps with GTK-1)

Just the gtk use flag.


Carsten


pgp2dKgmdERfv.pgp
Description: PGP signature


Re: [gentoo-dev] Default useflag cleanups: -apm -foomaticdb -fortran -imlib -motif -oss -xmms

2006-06-06 Thread Carsten Lohrke
On Tuesday 06 June 2006 06:07, Mike Frysinger wrote:
 mikmod is the only one i'd keep ... people generally want mikmod whether or
 not they know it ;)

I'd say 99,9% don't want mikmod. Arguments please, not vague assertions. :)


Carsten 


pgpMnmHuAbjLA.pgp
Description: PGP signature


Re: [gentoo-dev] Re: Default useflag cleanups: -apm -foomaticdb -fortran -imlib -motif -oss -xmms

2006-06-06 Thread Carsten Lohrke
On Tuesday 06 June 2006 04:11, Michael Sterrett -Mr. Bones.- wrote:
 Some games fail in pkg_setup if sdl-mixer isn't built
 with mikmod but I'm not sure if we've added the built_with_use check to
 all of the games that need it yet.

Time to fix this. And removing the flag would help, as bugs would be filed.


Carsten




pgpTLPShOXpNw.pgp
Description: PGP signature


Re: [gentoo-dev] Default useflag cleanups: -apm -foomaticdb -fortran -imlib -motif -oss -xmms

2006-06-06 Thread Carsten Lohrke
On Tuesday 06 June 2006 11:25, Diego 'Flameeyes' Pettenò wrote:
 SDL based games requires mikmod quite often. I suppose Mike knows what he's
 saying.

It's a difference to know that, compared to share ones thoughts, which Mike 
missed to do.


Carsten


pgp1iJ8Y6QlGG.pgp
Description: PGP signature


Re: [gentoo-dev] Default useflag cleanups: -apm -foomaticdb -fortran -imlib -motif -oss -xmms

2006-06-05 Thread Carsten Lohrke
On Monday 05 June 2006 18:03, Stefan Schweizer wrote:
 I would like to make the changes in a new 2006.1 profile, how do I go about
 that? I think the current profiles should not be touched, since some users
 may still be using the flags.

Yes, 2006.1.

 Any comments/objections - any outdated useflags I forgot?
 Have a look at /usr/portage/profiles/default-linux/x86/2006.0/make.defaults
 for the list of current default use flags.

I think gtk2 should be finally removed¹ from all packages and from 
make.defaults as well, before the 2006.1 release. Maintainers, who explicitly 
want to allow building against using Gtk 1, should default their ebuilds to 
Gtk 2 and add a (local) gtk1 use flag instead.

Is there a good reason, why mikmod is a enabled by default?


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


Carsten


pgp87dCwsaOKF.pgp
Description: PGP signature


Re: [gentoo-dev] Default useflag cleanups: -apm -foomaticdb -fortran -imlib -motif -oss -xmms

2006-06-05 Thread Carsten Lohrke
On Monday 05 June 2006 20:08, Harald van Dijk wrote:
 No, the decision with the gtk/gtk2 USE flag mess was to have package
 maintainers decide for each ebuild whether to support only gtk1 or only
 gtk2, but not have support for both in a single ebuild.

I know about the decision of the Gnome team, but there also was a thread with 
maintainers refusing to remove optional gtk1|2 support, if I recall 
correctly. Personally I couldn't care less, as long as the gtk2 flag is 
history.


Carsten


pgpE5mi6hfQyp.pgp
Description: PGP signature


Re: [gentoo-dev] Default useflag cleanups: -apm -foomaticdb -fortran -imlib -motif -oss -xmms

2006-06-05 Thread Carsten Lohrke
On Monday 05 June 2006 20:52, Chris Gianelloni wrote:
  Have a look at
  /usr/portage/profiles/default-linux/x86/2006.0/make.defaults for the list
  of current default use flags.

I think it's a bad idea to have win32codecs in make.defaults. There's quite a 
number of codecs in the package and I'm not so sure, that we even notice, 
when there are any vulnerable ones. Also the licensening and distribution 
question is everything else than clear.


btw.: We don't even have a avi use flag in the tree anymore.


Carsten


pgpFldGsBUj3v.pgp
Description: PGP signature


Re: [gentoo-dev] Default useflag cleanups: -apm -foomaticdb -fortran -imlib -motif -oss -xmms

2006-06-05 Thread Carsten Lohrke
On Monday 05 June 2006 23:25, Chris Gianelloni wrote:
 Well, it doesn't affect stages, and GRP stuff is done w/ USE=bindist, so
 again, this is a non-issue.

Well, I didn't mean our binary releases, but being held liable for making 
property of others available by default, without the permission to do so. 
Probably not the point, though, since if this argument would be tested, it 
would already suffice, that the ebuilds are in Portage. My main point is the 
security status anyways. I don't think we can ensure, that we'll catch known 
vulnerabilitis for these codecs. I strongly suggest to remove the use flag.


 Again, I haven't been in the habit of removing anything I haven't seen a
 bug about.  I'll remove avi now.

Wasn't a reproach (in case you took it for that). Just noticed it.


Carsten


pgp2I4M9mOFw6.pgp
Description: PGP signature


Re: [gentoo-dev] Please add net-wireless/rtl818x

2006-06-05 Thread Carsten Lohrke
This list is for development discussions. Please file a request at 
http://bugs.gentoo.org


Carsten


pgppRNCcOVLoi.pgp
Description: PGP signature


Re: [gentoo-dev] cmake.eclass

2006-05-25 Thread Carsten Lohrke
Don't repeat a failure of the past. Do


NEED_CMAKE x.y

inherit foo

...


instead this ugly toplevel function call.


Carsten


pgpkzcuaeL675.pgp
Description: PGP signature


Re: [gentoo-dev] Paludis and Profiles

2006-05-19 Thread Carsten Lohrke
On Thursday 18 May 2006 22:15, Ciaran McCreesh wrote:
 | Sure baselayout is. An there're others in the tree, But that doesn't
 | mean these variants are supported (special cases like embedded aside).

 Sure, some of them are supported.

By supported I mean all relevant packages in the tree install matching init 
scripts. That means officially supported, compared to such a package being 
maintained.


Carsten


pgpSIhWLAeOpc.pgp
Description: PGP signature


Re: [gentoo-dev] Paludis and Profiles

2006-05-19 Thread Carsten Lohrke
On Friday 19 May 2006 09:33, Roy Marples wrote:
 Maybe you haven't noticed, but baselayout is a virtual - which does make
 things harder as the main forks (vserver and fbsd) sometimes break when
 we add new things and they haven't synced up yet.

I have nothing against a virtual. I just don't think polluting the profile 
subtree with alternative package mananger stuff is good idea.

 But that's OK as they're supported I guess.

 Or are you saying that spb, other devs and people outside of Gentoo who has
 submitted SoC applications about Paludis (or what that qaludis?) are just
 going to wack it into the tree and then say we're not going to support
 it?

 Of course not!

No, I'm saying it's not the Gentoo package manager. Work on it, make it a 
viable contender for replacing Portage, but as long it isn't, keep it in an 
overlay.


Carsten


pgpAKM1VE6DjN.pgp
Description: PGP signature


  1   2   3   >