Re: [gentoo-dev] Suggestion for next bugday: Mass use deps migration
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
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
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
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
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
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
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
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
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
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
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
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
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!
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
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
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
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
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
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.
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.
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.
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
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
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
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
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
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
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
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?
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
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?
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
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?
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?
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?
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
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
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
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
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
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
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
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
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))
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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]
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
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
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
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-dev] Project Sunrise resumed again (was Resignation)
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
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)
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)
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)
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
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)
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?
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
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
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
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?
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
Re: [gentoo-dev] Paludis and Profiles
On Friday 19 May 2006 16:17, Roy Marples wrote: I can show you bugs where existing packages have invalid init scripts that just don't work with any baselayout version in portage. You could argue that they shouldn't be in the tree - if so then our imap server is foo-bared as it uses courier-imap. I suggest you check out bug #98745 for a clear definition of support. Bugs exist and should be fixed, but this is by no means an argument. I can also show you Gentoo scripts used by ifplugd and netplug with init-ng support in the tree right now. I guess that means that init-ng has some level of support right? There will be always someone who goes ahead. Fact is that every dev who maintains a package installing an init script is expecteted to do so for baselayout, but is free to say no, when someone requests an initng one, as long as it isn't the Gentoo default. Carsten pgpJ1JcWmUR3g.pgp Description: PGP signature
