Re[2]: [gentoo-dev] [RFC] QA Team's role
28.2.2006, 19:39:15, Mike Frysinger wrote: snip ewarn This ebuild overrides the default SLOT behaviour for webapps ewarn If this package installs files into the htdocs dir, this is ewarn probably a bug in the ebuild. /snip Sigh... what kind of QA issue is that? which part dont you understand ? the user sets a variable and then is told that the package probably contains a bug ... seems pretty confusing to me -mike rl03 already replied to that. I don't see any QA issues there, and if someone from QA team does, then he probably has too much time to ponder over the tree and invent issues where they don't exist. I don't see any point fixing this, at least until FEATURES=mindreader is implemented. Portage QA notices may be equally confusing to the users, with this kind of logic, yet they stay there - and number of people complaining about USE_EXPAND notices is much higher than the number of people who complained about confusing ewarn from webapps slot (exactly zero is far as I could find). Once again, don't invent problems, please. -- jakub pgpdQ4EP3Mcai.pgp Description: PGP signature
Re[2]: [gentoo-dev] [RFC] QA Team's role
28.2.2006, 20:59:42, Mike Frysinger wrote: On Tuesday 28 February 2006 12:51, Renat Lumpau wrote: On Tue, Feb 28, 2006 at 05:11:57PM +, Ciaran McCreesh wrote: And it sticks out a nasty ewarn and says that the ebuild is probably broken. Which it _probably_ is. See, this is a numbers game. In most cases, if you use the webapp eclass, setting SLOT=0 is incorrect. There are some cases in which it's just fine. Until FEATURES=mindreader is implemented, how is the eclass to know what you're trying to do? So it prints a warning and doesn't die. Number of angry users storming bugs.g.o - 0. why do you need to be a mindreader ? the user requested they control the package, thus it isnt a bug, so dont issue a warning -mike Sure, and when *ebuild* requested it instead, then portage will be automagically informed. So yeah, we can implement yet another variable into the eclass, and we can do tons of other magic voodoo about three lines of eclass that noone has ever noticed until today, and the whole thing can be a lot more complex for sure. Sorry, I call this a complete waste of time. -- jakub pgpzxcCYEJMz9.pgp Description: PGP signature
Re[2]: [gentoo-dev] [RFC] QA Team's role
28.2.2006, 21:39:43, Mike Frysinger wrote: whats your point ? if an ebuild author wants to control the SLOT, then they should be able to without having an invalid warning issued on the subject considering the nature of the warning, it should be trivial to make it into a proper QA check by having the class see where files were installed and then warn/abort if certain conditions are met there's no reason for the user to see this crap -mike Yeah, and there's no reason for user to see USE_EXPAND QA notice crap, eclass inherited illegally crap and a couple of others - this isn't going anywhere. You are trying to solve something that noone ever complained about. Why not rather solve stuff like ebuilds that depend unconditionally on arts, but because they inherit kde eclass they get bogus arts use flag from the eclass. This is an issue that's truly confusing and that people are filing bugs about. There's the difference between doing something useful and wasting time on an artificially invented issue. -- jakub pgpE24KYMB5NY.pgp Description: PGP signature
Re[2]: [gentoo-dev] [RFC] QA Team's role
1.3.2006, 1:40:53, Mike Frysinger wrote: On Tuesday 28 February 2006 19:28, Ciaran McCreesh wrote: On Tue, 28 Feb 2006 18:13:57 -0600 Lance Albertson [EMAIL PROTECTED] wrote: | I should note that if are a Gentoo Developer and have | problems/concerns/issues with Ciaran's attitude/actions, please | comment on bug #114944. (this bug is only open to Gentoo developers). | Its better if you say it yourself in this bug rather than letting | other people quoting what you say. I should note that if you are a Gentoo developer who has found my advice helpful, you should comment on bug #114944 since certain people are trying to turn Gentoo development into a popularity contest. there's a lot more to the issue, but it's sad if that's all you see in the bug -mike Indeed. Ciaran, that bug is not about technical competence; it's about your civil communication skills, that are as lacking as penguins on the Sahara desert in your case. Technical skills themselves are not useful for a project the requires you to communicate w/ other people in a civilized manner. As someone else noted, certains skills might be fit for a car salesmen but not for developers of a Linux distro. If a company hires a technically brilliant QA guy only to find out later on that this brilliant guy has killed the whole team while communicating his finding to others in such style you have shown on this thread and on many other occasions before, it'll be the QA guy who gets booted out, not the whole team. If that doesn't happen soon enough, the rest of the team can leave meanwhile and the whole business is doomed. -- jakub pgp4mO9BF1jel.pgp Description: PGP signature
Re[2]: [gentoo-dev] [RFC] QA Team's role
28.2.2006, 16:31:26, Ciaran McCreesh wrote: On Tue, 28 Feb 2006 16:17:20 +0100 Paul de Vrieze [EMAIL PROTECTED] wrote: | On Tuesday 28 February 2006 15:52, Ciaran McCreesh wrote: | Yes, it's an utterly trivial problem, but it is a QA violation. | Getting a complete list is something that takes a heck of a lot | longer, and I have yet to be convinced that my time would not be | better spent elsewhere. | | Where is a coding style problem related to quality of code in general | and assurance in particular? It's more relevant than you might think. Screwing up layout like that breaks various QA checking tools that assume that things are in the standard format. A tool that chokes on coding style (like tabs and whitespaces) should be ifself fixed. -- jakub pgpwjkHXYNH9r.pgp Description: PGP signature
Re[2]: [gentoo-dev] [RFC] QA Team's role
28.2.2006, 16:29:10, Ciaran McCreesh wrote: On Tue, 28 Feb 2006 16:08:05 +0100 Jakub Moc [EMAIL PROTECTED] wrote: | 28.2.2006, 15:39:40, Ciaran McCreesh wrote: | On Tue, 28 Feb 2006 10:49:13 +0100 Jakub Moc [EMAIL PROTECTED] | wrote: | | No, that's not a policy document, ebuild policy is documented | | here: | | | http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?style=printablepart=3chap=1 | | No, the whole thing is policy. | | No, it isn't. 'Fraid it is. Everything in the devrel handbook that isn't explicitly marked as a guideline is policy. Sorry, such procedure is not acceptable until you change the whole metastructure of the project so that a bunch of people is allowed to dictate to others whatever they think is fit. (Another question is how many people will want to work on such project.) Until that's done, things should be discussed and some form of consent reached. | When and where has been the following change discussed and who | approved that? | | http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/proj/en/devrel/handbook/hb-guide-ebuild.xml?r1=1.25r2=1.26root=gentoo Wouldn't know. That was nothing to do with me. I just wrote the original text (or actually, that might not even have been me). It finding its way into the policy docs was devrel's doing. Again, see above. | | Moreover, the cited howto is wrong, since it will break | | built_with_use checks | | No, that's a separate issue. | | No, it isn't. If you want something to have as a policy, it needs to | be error-free, reasonably applicable and not doing more harm than if | it isn't applied at all. And implementing such stuff requires a | proper discussion, considering the consequences and some sort of | consent among affected developers. (Also, that howto example is less | than fortunate/clear, like some user noted in Bug 124401). built_with_use isn't a question of conflicting USE flags. It's a separate question of dependency resolution, and in this situation it *can't* be solved using the method that's been standard for four years or more. Sure it is. You can't silently enable/disable some feature if other ebuilds are checking for that feature using those very use flags that you have ignored/overriden/bypassed. Such checks are useless then and more stuff gets broken than gets fixed. | No, it doesn't, you can't reasonably favour one of two completely | different functionalities based on some automagic | assumption/developer discretion. That doesn't benefit users in any | way and just produces unexpected results (hey, I explicitely enabled | recode use flag and php compiled without, the ebuild is broken, | fix0r it!) By all means warn the user. There's nothing in policy disallowing that. That doesn't work, it breaks other things as explained above. Please, don't use a hammer where watchmaker's screwdriver is a proper tool, otherwise you'll severely damage the whole thing. One minute spent on tweaking use flags is much less important than a bunch of useful features missing just because you've hammered the whole stuff together. | No, noone should enforce a policy that | | - doesn't exist (see above) The whole devrel handbook is policy, except where otherwise noted. See Mike's reply. Then any significant change there requires a sane procedure. -- jakub pgp3XISjAzxvT.pgp Description: PGP signature
Re[2]: [gentoo-dev] bug #20201 and bbapm
27.2.2006, 18:23:09, Ciaran McCreesh wrote: On Mon, 27 Feb 2006 12:15:13 -0500 Alec Warner [EMAIL PROTECTED] wrote: | bbapm has been masked due to no one responding with anything useful to | last rites e-mail. It will be punted in 30 days. No no no. Do this properly. Clean up *all* the broken blackbox applets, not just the one that has someone whining on a bug report. There are at least two in the tree that're more broken than this. *Please*, be so kind and look at metadata.xml for those ebuild, then just either do it *yourself* or ask someone from your fellow-devs in commonbox herd to do it for the other ebuilds that you failed to mention above... Don't move broken stuff on other people's shoulders, as you've already done once. I fail to see why are you claiming here that there's even more broken stuff in the tree, yet as a member of maintainer herd haven't dealt with that properly for quite an extensive period of time - and then you are asking *other* people to do something properly. The fact that there are other ebuilds broken as well isn't any valid reason for keeping this particular broken thing on portage. That way, nothing would be punted from portage, ever. TIA. -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=getsearch=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) pgpJ6oWCjQowX.pgp Description: PGP signature
Re[2]: [gentoo-dev] [RFC] QA Team's role
27.2.2006, 21:37:09, Ciaran McCreesh wrote: On Mon, 27 Feb 2006 20:26:10 + Stuart Herbert [EMAIL PROTECTED] wrote: | On Mon, 2006-02-27 at 17:08 +, Ciaran McCreesh wrote: | Abuse from people like you whenever someone finally gets brave | enough to document all the ways in which webapp-config is broken. | | This isn't the first time we've heard this tune from you, and alas I | fear it won't be the last. | | You know where bugzilla is. You know how to contact any of the | webapp-config maintainers via email, or via IRC. We're ready to | listen to your input, and to work with you (or anyone else) on fixing | any genuine problems that webapp-config has. The more feedback we | get, the better we can make this package for everyone's enjoyment. Then please start with bug 120088. Once that one's fixed we'll go from there. rhetorical question May I ask how is that related to webapp-config? /rhetorical question You can't escape this way... so don't even try. You've been talking about broken webapp-config, then go ahead and show us the breakage. If there's nothing you have to say in that respect, then just rather stick foot in your mouth next time you are going to assault someone. Thanks. -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=getsearch=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) pgpm1h2ln0Bno.pgp Description: PGP signature
[gentoo-dev] Last rites: app-editors/gnotepad+
app-editors/gnotepad+ is a simple HTML and text editor. It lacks a maintainer, doesn't compile and last release upstream was 5+ years ago. Unless someone picks this up, it should be package.masked and removed from portage. There are tons of better and working alternatives. https://bugs.gentoo.org/show_bug.cgi?id=122993 -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=getsearch=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) pgpCqeLfgkccp.pgp Description: PGP signature
Re[2]: [gentoo-dev] Last rites: app-editors/gnotepad+
16.2.2006, 22:05:54, Ciaran McCreesh wrote: On Thu, 16 Feb 2006 21:51:40 +0100 Jakub Moc [EMAIL PROTECTED] wrote: | Unless someone picks this up, it should be package.masked and | removed from portage. There are tons of better and working | alternatives. Uh, it's not a last rites unless someone actually does the masking pending removal. Uh, was this reply really needed? BTW, x11-misc/bbapm is about one month overdue (http://bugs.gentoo.org/show_bug.cgi?id=20201) -- jakub pgpe3g3pwY5Bw.pgp Description: PGP signature
Re[2]: [gentoo-dev] Last rites: app-editors/gnotepad+
16.2.2006, 22:47:49, Ciaran McCreesh wrote: On Thu, 16 Feb 2006 22:32:13 +0100 Jakub Moc [EMAIL PROTECTED] wrote: | BTW, x11-misc/bbapm is about one month | overdue (http://bugs.gentoo.org/show_bug.cgi?id=20201) It's not overdue. It hasn't had a proper last rites email sent out yet and probably won't get one either, given the flamefest that occurred last time someone tried to tidy up commonbox... Uhm... you need to refresh your memory, it seems: From: Jakub Moc [EMAIL PROTECTED] To: gentoo-dev@lists.gentoo.org Subject: last rites - x11-misc/bbapm Date: 6.1.2006, 15:13 === Start of original message == Try #2, following the suggestion in http://bugs.gentoo.org/show_bug.cgi?id=20201#c11 x11-misc/bbapm: Bug 20201, segfaults, last release 6 years ago (a.k.a. dead as a nail in the lamp-room door) Unless someone steps up, it'll be package masked in two weeks and removed from portage. -- jakub pgp6Xsi3KUMsH.pgp Description: PGP signature
Re[2]: [gentoo-dev] Last rites: app-editors/gnotepad+
16.2.2006, 23:08:51, Ciaran McCreesh wrote: On Thu, 16 Feb 2006 22:55:33 +0100 Jakub Moc [EMAIL PROTECTED] wrote: | 16.2.2006, 22:47:49, Ciaran McCreesh wrote: | On Thu, 16 Feb 2006 22:32:13 +0100 Jakub Moc [EMAIL PROTECTED] | wrote: | | BTW, x11-misc/bbapm is about one month | | overdue (http://bugs.gentoo.org/show_bug.cgi?id=20201) | | It's not overdue. It hasn't had a proper last rites email sent out | yet and probably won't get one either, given the flamefest that | occurred last time someone tried to tidy up commonbox... | | Uhm... you need to refresh your memory, it seems: It's not a proper last rites email unless it's sent by someone who's actually going to follow through with it. OMG, stop this crap and don't waste our time. You specifically asked me to do it - http://bugs.gentoo.org/show_bug.cgi?id=20201#c11 Also, there wasn't exactly any flamefest so I don't know what you are referring to above. You sent out a mail and noone gave a damn about that stuff, should have been removed from from the tree 1 1/2 year ago. http://marc.theaimsgroup.com/?l=gentoo-devm=109233643723408w=2 Punt the broken thing from portage. -- jakub pgpmc9Aqil4fP.pgp Description: PGP signature
Re[2]: [gentoo-dev] Last rites: app-editors/gnotepad+
16.2.2006, 23:58:41, Ciaran McCreesh wrote: On Thu, 16 Feb 2006 23:45:45 +0100 Jakub Moc [EMAIL PROTECTED] wrote: | OMG, stop this crap and don't waste our time. You specifically asked | me to do it - http://bugs.gentoo.org/show_bug.cgi?id=20201#c11 No, I asked you to do it properly, not to send out one last rites email for something you're not going to remove. What are you talking about? commonbox is listed as maintainer of that stuff, it's been broken for years, you neither fixed it or bothered to remove it from portage, nor did you at least re-assign that to maintainer-needed and remove yourself from metadata.xml. You asked me to send last rites, I did, noone cares about that stuff - so will you finally punt the broken thing, instead of this pointless trolling?? Or should I CC QA on that bug, so that someone else will do it if you don't want to? | Also, there wasn't exactly any flamefest so I don't know what you are | referring to above. You sent out a mail and noone gave a damn about | that stuff, should have been removed from from the tree 1 1/2 year | ago. Try looking harder next time. That's exactly the link you provided in http://bugs.gentoo.org/show_bug.cgi?id=20201#c7 so why on earth should I try to look harder? -- jakub pgpYbmvKjrYEc.pgp Description: PGP signature
Re[2]: [gentoo-dev] Last rites: app-editors/gnotepad+
17.2.2006, 0:23:49, Ciaran McCreesh wrote: On Fri, 17 Feb 2006 00:14:42 +0100 Jakub Moc [EMAIL PROTECTED] wrote: | 16.2.2006, 23:58:41, Ciaran McCreesh wrote: | | What are you talking about? commonbox is listed as maintainer of that | stuff, it's been broken for years, you neither fixed it or bothered | to remove it from portage, nor did you at least re-assign that to | maintainer-needed and remove yourself from metadata.xml. You should probably go and read herds.xml sometime. Or maybe you should, rather... $ herdstat commonbox Herd:commonbox Email: [EMAIL PROTECTED] Description: Blackbox and derivative works Developers(5): ciaranm gothgirl ka0ttic pyrania superlag http://www.gentoo.org/proj/en/metastructure/herds/herds.xml#doc_chap21 | You asked me to send last rites, I did, noone cares about that stuff | - so will you finally punt the broken thing, instead of this | pointless trolling?? Or should I CC QA on that bug, so that someone | else will do it if you don't want to? bbapm is only a small part of the problem. If you're going to do something, do it properly. Stop wasting other people's time by doing it piecemeal and getting it wrong. It's exactly your job, TBH. So far you've done nothing in this regard, except for wasting other people's time and keeping broken POS in portage. | | That's exactly the link you provided in | http://bugs.gentoo.org/show_bug.cgi?id=20201#c7 so why on earth | should I try to look harder? Well, I *was* expecting you to use a bit of common sense when handling the issue. Blah blah blah will you post the link referring to that flamefest you've been mentioning over and over again? Apparently not. So - this has nothing to do with common sense and everything to do with your trolling. -- jakub pgpEelg4Xtewv.pgp Description: PGP signature
Re[2]: [gentoo-dev] Last rites: app-editors/gnotepad+
17.2.2006, 0:42:13, Ciaran McCreesh wrote: (ommited) http://upload.wikimedia.org/wikipedia/commons/9/9e/DoNotFeedTroll.jpg Everyone else, sorry that you had to read this debate... :/ -- jakub pgpDXBRuHXpDD.pgp Description: PGP signature
[gentoo-dev] gtk2 use flag deprecation = bashing my head against the wall
Reading the last two comments (Bug 106560) from devs who removed them from CC again makes my cry out loud in desperation. People, *please* read the two attachments I've posted there, and think again before stating something about fixed months ago etc. etc. :-( http://bugs.gentoo.org/show_bug.cgi?id=106560 -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=getsearch=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) pgpnufdngyRGw.pgp Description: PGP signature
[gentoo-dev] Last rites: dev-db/dybase
For those who wonder wth is that... Description: DyBASE is very simple object oriented embedded database for languages with dynamic type checking. The ebuild lacks a maintainer, is completely bogus and fubar, a.k.a. doesn't work at all and needs complete rewrite to work with dev-lang/php. The same is true for python and ruby APIs. Will be package.masked today and removed from portage in two weeks unless someone has a very good reason to keep it and want to rewrite it from scratch. See Bug 60472. -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=getsearch=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) pgprIqEZw2TTi.pgp Description: PGP signature
Re[2]: [gentoo-dev] Last rites: net-nds/gq
10.2.2006, 14:56:58, Olivier Crete wrote: On Fri, 2006-10-02 at 10:33 +0100, Jakub Moc wrote: Otherwise, I suggest to p.mask this in two weeks and then remove from portage. Is there any other useful gtk ldap browser in the tree ? Not that I would know... Anyway, nls can be fixed by using sys-devel/gettext instead of the crappy bundled implementation it seems, you can work around the distcc issue using CC=$(tc-getCC) or something like that, the deps are a trivial thing to fix. However, kerberos issues seem non-trivial, and there's also a problem that this thing refuses to save preferences completely (Bug 76057), which is kinda annoying. :P Honestly, not worth wasting time IMO, this stuff is really abandonware with non-existent upstream. -- jakub pgpwlyjqp37TD.pgp Description: PGP signature
Re[2]: [gentoo-dev] Last rites: net-nds/gq
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 10.2.2006, 20:03:45, Donnie Berkholz wrote: Olivier Crete wrote: Is there any other useful gtk ldap browser in the tree ? There's a bug for LAT -- http://bugs.gentoo.org/show_bug.cgi?id=86854 -- but the current assignee apparently doesn't want it. Well, that looks like .Net - /me runs :) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (MingW32) iD8DBQFD7OaKhxfV/c66PZ4RAs2IAJ4i5t4m1/J5AVC1aLvwionQgSw6XwCgq7kG mKR+ztnqHiJxflj+0o9HaVk= =jyFx -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] multislot mysql
Honestly, I don't see why is this needed. It works the same way like apache slots or php slots or whatever other slots. If users emerge an ebuild explicitely, they get the highest version available, if they want something else, they can do echo =dev-db/mysql-5* /etc/portage/package.mask That's exactly the same amount of user intervention required as if they should enable multislot use flag in package.keywords instead (considering that users definitely don't want to enable such flag globally for things like binutils or gcc). Also, the current behaviour doen not take away the possibility for other ebuilds to depend on a specific slotted mysql version, e.g. if something doesn't work with 5.x but works just fine with 4.1. That won't be possible once multislot use flag is required for slotted install. -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=getsearch=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) pgpfEOpvV3PGc.pgp Description: PGP signature
Re[2]: [gentoo-dev] IUSE and LINGUAS?
30.1.2006, 12:46:28, Jason Stubbs wrote: On Monday 30 January 2006 16:43, Ciaran McCreesh wrote: On Mon, 30 Jan 2006 06:17:36 +0100 Diego 'Flameeyes' Petteno [EMAIL PROTECTED] wrote: | Also, as repoman complain about linguas_blabla not being a valid | useflags, all the linguas_* useflags should be listed in use.desc No, part of the point of USE_EXPAND is that they shouldn't. This is a repoman bug. Not only repoman - see Bug 70648 I have yet to be enlightened on any merit of USE_EXPAND is so perhaps you could explain as to why there should be user-configured-yet-undocumented options for ebuilds? More precisely, how should they be documented if not via use.desc? Pretty much exhaustively flam^W discussed in Bug 70648 as well. LINGUAS are not use flags, otherwise they wouldn't have to exist. Sticking this stuff into IUSE just bloats it like hell, and as ciaranm pointed in another mail, maintaining lists of honored LINGUAS in each ebuild it just huge maintenance overhead with no gain... -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=getsearch=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) pgp0nwD5keLq8.pgp Description: PGP signature
Re: [gentoo-dev] Re: Re: Re: Re: Re: bootstrapping since gcc 3.4 is stable
26.1.2006, 23:02:28, MIkey wrote: You can purge the old gcc immediately after it upgrades instead of after the entire system completes. How the fsck does it matter? What's your obsession here??? So purge it and stop this finally, you have a freedom to purge it and you have a freedom to not use stage1 and you have a freedom to not use Gentoo at all, ktnxbye. Take your pick: http://bugs.gentoo.org/buglist.cgi?bug_status=UNCONFIRMEDbug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDfield0-0-0=producttype0-0-0=substringvalue0-0-0=revdepfield0-0-1=componenttype0-0-1=substringvalue0-0-1=revdepfield0-0-2=short_desctype0-0-2=substringvalue0-0-2=revdepfield0-0-3=status_whiteboardtype0-0-3=substringvalue0-0-3=revdep Eh??? -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=getsearch=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) pgpcj9z9V3tLh.pgp Description: PGP signature
Re: [gentoo-dev] Re: ca-certificates PDEPEND
9.1.2006, 17:12:31, Andrea Barisani wrote: On Mon, Jan 09, 2006 at 11:08:38AM -0500, solar wrote: Do you think the PDEPEND of the ca-certs should be tied to a USE= flag? If so should it be a 'no*certs' flag or a USE=cacerts ? USE=cacerts sounds the proper course of action to me. NOT until use-based deps are in place, plzktnxbye!!! Don't break the damned realplayer thing again. -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=getsearch=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) pgpsEZgc6Hws7.pgp Description: PGP signature
Re[2]: [gentoo-dev] ChangeLogs and rsync time
3.1.2006, 12:47:27, Chris Gianelloni wrote: So you have now taken what was described as an automatic solution to reduce size into a manual process, reducing usability of the ChangeLog and increasing workload for every ebuild developer. I'm sorry, but I still think the idea of simply RSYNC_EXCLUDEing the ChangeLog by default would be a much better solution. +1; I frequently find even pretty old changelog entries useful (even the 'stable on foo' ones are useful, if you need to find out who keyworded the thing stable despite the fact that it's severely broken). As for RSYNC_EXCLUDE by default, that's not something that should be considered until GLEP 42 or an equivalent solution gets implemented. -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=getsearch=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) pgpv20IbxGk5B.pgp Description: PGP signature
Re[2]: [gentoo-dev] Changing description for the xml global use flag
29.12.2005, 12:52:09, Mike Frysinger wrote: [rant omitted] Maybe you could rather have used those 5 minutes you had spent writing your mail to fix horde ebuilds/eclass instead. They have been broken with dev-lang/php ever since it came into portage. :P Have a nice day... -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=getsearch=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) pgpcIGWOQtg0m.pgp Description: PGP signature
Re[2]: [gentoo-dev] Changing description for the xml global use flag
29.12.2005, 14:20:37, Mike Frysinger wrote: On Thursday 29 December 2005 08:06, Jakub Moc wrote: Maybe you could rather have used those 5 minutes you had spent writing your mail to fix horde ebuilds/eclass instead. They have been broken with dev-lang/php ever since it came into portage. :P speaking of dicks, i knew i hadnt heard from you in a while i dont recall ever seeing a bug report about this issue ... oh, thats because no one said anything about it or filed one, funny how that works -mike For your reference, I even cared to attach a patch for horde (among tens of other bugs filed for dev-lang/php compitibility) - but that patch never made it to portage, despite the bug has been marked as fixed. https://bugs.gentoo.org/show_bug.cgi?id=105395 Should I reopen the bug or will you do so yourself? -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=getsearch=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) pgpfAV8SbOqHB.pgp Description: PGP signature
Re: [gentoo-dev] making dodoc and dohtml die when they fail and stricter is on
Currently there are quite a few ebuilds in the tree that execute dodoc or dohtml for files that do not exist. I think it would be nice to have ebuilds die if this is the case. To not break current ebuilds this would only happen with FEATURES=stricter. Sigh... There are already bugs flowing in for TEXTRELs/executable stacks checks implemented in recent portage versions. Some of these bugs are completely INVALID or CANTFIX - emulation stuff, binary-only ebuilds, etc. etc. What's the point of this breakage? Why are these QA checks fatal, causing ebuilds to bail out? How can you disable such checks per-ebuild (AFAIK - you can't) to not annoy users with QA notices and breakage one can do nothing about anyway? As Flameeyes pointed out, dodoc/dohtml is also used in eclasses. This can break many ebuilds. Users will report duplicate bugs because they will not realize that it's the eclass causing the failure, not the ebuild. Again, what's the point? How will it work with FEATURES=nodoc? Why should an ebuild ever fail just because some doc file is missing or got renamed or whatever? -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=getsearch=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) pgpPOJRY0EZSR.pgp Description: PGP signature
Re[2]: [gentoo-dev] making dodoc and dohtml die when they fail and stricter is on
26.12.2005, 14:28:12, Jason Stubbs wrote: On Monday 26 December 2005 20:01, Jakub Moc wrote: Currently there are quite a few ebuilds in the tree that execute dodoc or dohtml for files that do not exist. I think it would be nice to have ebuilds die if this is the case. To not break current ebuilds this would only happen with FEATURES=stricter. Sigh... There are already bugs flowing in for TEXTRELs/executable stacks checks implemented in recent portage versions. Some of these bugs are completely INVALID or CANTFIX - emulation stuff, binary-only ebuilds, etc. etc. Sigh... None of these issues have made there way to dev-portage. -- Jason Stubbs Well, then assign Bug 116499 or Bug 116602 to yourself (qemu), there're textrels in openoffice-bin, mozilla-firefox-bin (upstream, don't hold your breath to get this fixed), acroread (cantfix really), this for sure will be an issue for many games binaries, etc. While it's often upstream/cantfix, I don't see much sense in making these QA checks fatal really. -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=getsearch=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) pgpmuHTx23Adq.pgp Description: PGP signature
Re[2]: [gentoo-dev] Stupid USE defaults that need cleaning
26.12.2005, 16:35:33, Ciaran McCreesh wrote: On Mon, 26 Dec 2005 00:09:57 -0500 Doug Goldstein [EMAIL PROTECTED] wrote: | the USE defaults are a bit INSANE... We need to get rid of some of | this crap... No, you just don't understand how they work. It's not an issue of is foo important. It's an issue of for packages with optional foo support, does it make most sense for foo to be enabled by default?. OK, then: alsa - this does not make most sense definitely, this horrible thing needs to die. emboss - Adds support for the European Molecular Biology Open Software Suite. WTF? Why are we abusing make.defaults for such stuff? eds - please, fix the ebuilds properly instead of throwing the thing on everyone. This has already caused numerous invalid bugs with people wondering why the heck portage wants to emerge gnome with USE=-gtk -gnome motif - no need to repeat Cardoe's description... and this has caused tons of cups depends on X bugs. -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=getsearch=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) pgp2215uzTW7p.pgp Description: PGP signature
Re[2]: [gentoo-dev] Stupid USE defaults that need cleaning
26.12.2005, 18:07:45, Ciaran McCreesh wrote: On Mon, 26 Dec 2005 17:57:17 +0100 Jakub Moc [EMAIL PROTECTED] wrote: | alsa - this does not make most sense definitely, this horrible thing | needs to die. Why? On x86, alsa is the least broken sound system, and on x86, the target for the default profiles is desktops, and most desktops have soundcards. Uh eh... I meant *arts*, no clue how I wrote alsa. -- jakub pgp54Gtoj1uG5.pgp Description: PGP signature
Re[4]: [gentoo-dev] Stupid USE defaults that need cleaning
26.12.2005, 19:36:23, Joe McCann wrote: On Mon, 2005-12-26 at 17:57 +0100, Jakub Moc wrote: eds - please, fix the ebuilds properly instead of throwing the thing on everyone. This has already caused numerous invalid bugs with people wondering why the heck portage wants to emerge gnome with USE=-gtk -gnome For the record, the eds flag was added as a default flag because every 3rd gnome user would file bugs or complain via forums because they installed gnome, found no evolution-data-server integration, and then be bummed when they had to recompile packages again. This whole thread seems to have come from a misunderstanding of how use.defaults work and 20 min of boredom. OK, so because every 3rd gnome user is not able to add the proper use flag to make.conf, every non-gnome user is stuck with investigating and putting -eds into make.conf to avoid pulling in gnome crap. Wonderful. Yes, I am ranting, because this kind of use flags basically pulls in huge number or unwanted dependencies; exactly the same thing with motif - would someone explain why the heck do do we need this thing in make.defaults? I don't think that this discussion will lead somewhere, so - anyone cares to add a non-bloated x86 profile (basically, something like profiles/hardened/x86/2.6 minus the hardened stuff) so that people who don't want all this bloat can have a sane starting point? -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=getsearch=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) pgp7yuTYcnogo.pgp Description: PGP signature
Re[2]: [gentoo-dev] Stupid USE defaults that need cleaning
26.12.2005, 22:21:14, Diego 'Flameeyes' Petteno wrote: On Monday 26 December 2005 20:24, Jakub Moc wrote: exactly the same thing with motif - would someone explain why the heck do do we need this thing in make.defaults? Because people emerges xpdf waiting for xpdf binary and they won't find it with -motif, as it requires motif integration Eeek?! This is totally broken behaviour... , but I think more people would just have xpdf installed because of cups or older kpdf/gpdf versions. Now that poppler is there, the problem might be mitigated, in the future, tho, as cups still uses xpdf and not poppler yet. That would be really nice... -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=getsearch=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) pgpXbJO9BVhi7.pgp Description: PGP signature
Re: [gentoo-dev] mac/xmms-mac licence issue
25.12.2005, 3:11:53, Bret Towe wrote: i can understand putting proper warning in the ebuild if the dev thinks that its worth the user really noting the issues surrounding it, not forcing their ideals onto the user if i wanted that i would run debian Erm, we are not forcing our ideal on users, we simple refuse to commit an ebuild for code which has no valid license. For those unfamiliar with the whole thing (Bug 52882, Bug 94477 and tons of dupes): Someone has forked a proprietary code with a sucky license, relicensed it under fake LGPL for the sole purpose of being able to host the project on SF, and even explicitely acknowledges that what he's doing is illegal: --- COPYING -- Due to the license License.htm, so I can't make it public, Last November, I decided to register mac-port at SourceForge, so I had to choose an open source license, so I chosen LGPL for this mac-port. It is close to the original license, but doesn't get the permission from the original author, Matt. This license would be changed when the author asks in the future. -- What the heck kind of license and behaviour is the above? And why should Gentoo ship such crap? -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=getsearch=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) pgpLILkpRpuBF.pgp Description: PGP signature
Re[2]: [gentoo-dev] mac/xmms-mac licence issue
25.12.2005, 3:51:15, Brian Harring wrote: Jakub responded in this thread about shipping a crap license... imo, that's not the issue. The issue is that we would be knowingly violating a license (however horrid the license is). Two routes out of this- clean room reimplementation of the codec, or someone manages to track down the original author and gets the code converted to a different license. Latter still is tricky, since any contributions to the project, you would need all authors to sign off on the new license- this is assuming the project doesn't do centralized copyright, and assuming people have actually contributed to it beyond original author. Not exactly what I meant. There's actually no (clear) license, the original one would apply to the original code, not to the patches submitted after it's been re-licensed under LGPL. Since upstream is dead, we can't ship the original code (leaving the question why we should do it at all aside), also we can't exactly find all the people who contributed the patches under LGPL, and there's no way to contribute the code back to upstream as the original license requires. Such code is a real bargain to commit :P Rewrite from scratch, that's what left here. So much you get if you start with a bullshit license originally and then go MIA. :/ -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=getsearch=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) pgp5tbo6BzPB3.pgp Description: PGP signature
Re[2]: [gentoo-dev] mac/xmms-mac licence issue
25.12.2005, 4:17:05, Bret Towe wrote: On 12/24/05, Carsten Lohrke [EMAIL PROTECTED] wrote: This isn't politics, but copyright infringement on top of a ridiculous license (when you want to see it as one) we had a short discussion1 about several months ago. im sorry i fail to see how copyright infringement or a ridiculous licence matters when commiting a ebuild to portage just pick a licence if thats the issue warn the user and leave it at that Yuck. I'm sorry, but arguments like copyright does not matter, just go ship it won't fare too well, leaving further debate pretty much pointless. Copyright *does* matter, if you want to see an example how a ridiculous license kills the job, go see qmail ebuilds. -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=getsearch=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) pgpaNFE9KAryN.pgp Description: PGP signature
[gentoo-dev] Commiting of ~arch virtual/* ebuilds causes deptree issues
Hello here, the virtual/ thingy broke the deptree again with virtual/libstdc++ (see Bug 116253), essentially the same issue like with virtual/x11. These virtuals need to go straight stable if any of their RDEPEND atoms is stable for a particular arch. Betelgeuse is working on a repoman check for this issue, meanwhile, if there are more virtuals planned, please bear this in mind. :) Thanks. -- jakub pgpcdJ0bugkrI.pgp Description: PGP signature
Re[2]: [gentoo-dev] UPGRADE ANNOUNCEMENT bugs.gentoo.org
14.12.2005, 18:12:05, Georgi Georgiev wrote: And for the network challenged, output in local time: And for the bandwidth/time-challenged, who do not wish to waste their time reading useless emails: :0: * ^From:[EMAIL PROTECTED] /dev/null -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=getsearch=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) pgpV6fMOpMxt2.pgp Description: PGP signature
Re: [gentoo-dev] New x86 developer: Joshua Jackson
10.12.2005, 11:09:50, Bryan �stergaard wrote: Added to the menagerie are 3 fish, 2 bird and a hamster. Hey, so that was you who stole jforman's hamsters during bugzie upgrade and broke the thing? :P Welcome... ;) -- jakub pgp3AC7XoWZMa.pgp Description: PGP signature
Re[2]: [gentoo-dev] Moving GCC-3.4 to stable on x86
30.11.2005, 22:19:27, Peter Ruskin wrote: On Wednesday 30 November 2005 20:12, Mark Loeser wrote: gcc-3.4.* will not be selected as your system compiler after merging it. The old gcc profile is still valid, therefore it is kept. Users have to consciously go and change their profile to change their gcc, so nothing is going to just magically break. But we should not yet be encouraged to switch to 3.4. I upgraded to i686-pc-linux-gnu-3.4.4 a long time ago but my gcc profile is still firmly fixed at 3.3.5-20050130 because of bug #101471. This bug was opened 2005-08-05 and it's still not fixed. Whenever I try 3.4.4 I can't rebuild glibc because of this bug. Sure. So remove USE=vanilla from your use flags and it will work. That bug won't be fixed, because it's not a bug. -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=getsearch=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) pgpkKIpnkGEFu.pgp Description: PGP signature
Re[2]: [gentoo-dev] Moving GCC-3.4 to stable on x86
1.12.2005, 0:29:48, Chris Gianelloni wrote: On Wed, 2005-11-30 at 17:34 -0500, Philip Webb wrote: Ordinarily, I upgrade packages individually when it seems appropriate never do 'emerge world' with or without '-e' or other flags; I do 'esync' every weekend look at what is marked as having changed. Technically, you don't need to rebuild world. You only need to rebuild stuff that uses C++ and links to libstdc++. revdep-rebuild --library=libstdc++.so.5 is all that's needed here to avoid things like Bug 64615. -- jakub pgpgEl2aFDbjP.pgp Description: PGP signature
Re[2]: [gentoo-dev] Moving GCC-3.4 to stable on x86
1.12.2005, 1:30:41, Marien Zwart wrote: Not sure if everyone is aware of this, but most installed pythons link to libstdc++.so. This is not a problem if you run the above revdep-rebuild (it should catch it just fine). It is a problem if you get rid of gcc 3.3 before installing libstdc++-v3 or running the revdep-rebuild, as it will leave you with a broken python and therefore unable to emerge. Which returns us to the question why don't we build python with nocxx so that we could avoid this major PITA. -- jakub pgpQpg8uVxpUk.pgp Description: PGP signature
Re[2]: [gentoo-dev] manpages that requires dependencies
27.11.2005, 15:39:48, Jason Stubbs wrote:
On Sunday 27 November 2005 22:09, Ned Ludd wrote:
On Sun, 2005-11-27 at 07:58 -0500, Ned Ludd wrote:
On Fri, 2005-11-25 at 12:46 +0200, Marius Mauch wrote:
Except that no{man,info,doc} are on the to-die list anyway.
They are very valuable features and quite easy to use without mucking
with INSTALL_MASK. I'm against this change without some justification.
further investigation shows that you can't simply get rid of these as
several core ebuilds use the feature to control the creation of
packages. A quick grep shows that several ebuilds do stuff like.
has noman FEATURES do_stuff
openssl/glibc/gcc/dhcp/boa/gdb to name a few that take advantage of the
no{man,info,doc} FEATURES= already.
Core packages or not, they are all broken. When the requirement came up, the
respective maintainers should have spoken up so that a proper solution could
be found. When are the quick hacks going to stop? :|
I can't see why exactly do we need to get rid of useful features? :-(
--
jakub
pgpdTiupJuCiA.pgp
Description: PGP signature
Re[2]: [gentoo-dev] manpages that requires dependencies
25.11.2005, 0:58:28, Ciaran McCreesh wrote: On Fri, 25 Nov 2005 00:49:23 +0100 Diego 'Flameeyes' Petteno [EMAIL PROTECTED] wrote: | Hi everybody, a little question that I'd like to be answered (so that | we can make it a sort of rule). | How should manpages that are generated be managed? | | The common sense and looking to other ebuilds would say to always | build man pages, but when it asks me to install something like | docbook-sgml-utils, I'm tempted not to do that ;) man pages can't be considered optional (despite what RMS says). They're not fancy extra HTML API documentation, they're core, so they don't get a USE flag. Of course, if FEATURES were in the USE expand list, you could use ! features_noman ? ( ) ... That is all fine and dandy, but if you search bugzilla for USE=doc related bugs, you might think twice before adding yet another inevitably broken thing to portage. docbook-sgml-utils co. is extremely fragile and buggy thing. -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) pgpZ9CTbskDFd.pgp Description: PGP signature
Re[2]: [gentoo-dev] Update of http://wwwredesign.gentoo.org
25.11.2005, 8:06:51, Flammie Pirinen wrote: 2005-11-25, Curtis Napier sanoi, jotta: So on that note, I've gone over the design and gotten it closer to Aarons's reference. [...] Check out what I did change in the meantime. Uh-oh. The usability regression from what the site was yesterday is unbelievable. Almost all of the texts are too small to read again, and the color combinations are also unreadable again. I hope that you and Aaron are still going to take into account at least all the usability related requests from the feedback you asked, because I'd be pretty annoyed to see yet another web site redesign that manages to make original website even more unusable than it was. Ouch, what happened again?!... I can't agree more. I object to any redesign if the whole thing was arranged so badly that all the accessibility flaws are to be considered an unchangeable part of the design. Better stick w/ the current one in that case. :-( -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) pgpd4hgTLeSpP.pgp Description: PGP signature
Re[8]: [gentoo-dev] Decision to remove stage1/2 from installation documentation
23.11.2005, 11:25:58, Paul de Vrieze wrote: On Wednesday 23 November 2005 01:55, Jakub Moc wrote: emerge -e world emerge -e world emerge depclean You've missed revdep-rebuild to fix the borkage that emerge depclean produced. ;) After double rebuilding of the complete world I would seriously doubt it that any stray dependencies were still around. If there were, it would be because of broken ebuilds. That should be reported as bugs and fixed instead of relying on revdep-rebuild. You've probably missed the point. It's emerge depclean that's broken; again - we are lacking any reliable way to punt unneded packages. BTW, I'd still like to know how I'll get nptl(only) hardened install once stage1 is gone. i386 does not have nptl, and I've done change CHOST emerge -e system emerge -e world job a couple of times and it never went smoothly. -- jakub pgpqyAFKp9Nmd.pgp Description: PGP signature
Re[2]: [gentoo-dev] Re: Possible solution: email subdomain
23.11.2005, 20:07:15, Dan Meltzer wrote: Can we get all current developers renamed to nick.developer then? just to alleiviate any confusion someone may have... [snip a buttload or two] NO (I sincerely hope at least), and please let's finally stop messing w/ email addresses causing further confusion and administrative overhead for no good reason. :=( *sigh* -- jakub pgpVcDtneAbEB.pgp Description: PGP signature
Re: [gentoo-dev] Re: Re: enewuser/enewgroup getting their own eclass
23.11.2005, 22:14:31, Duncan wrote: [irrelevant twaddle omitted] It may be possible to automate code creation, but it's not possible to automate a community, and humans in such a community /don't/ tend to stay strictly on topic. That's just the way humans are, and have been for far longer than either you or I have been around. I can't speak for others, but personally I'm not interested in receiving such crap in my mailbox. There's enough traffic here as it is. Please, keep on topic or go chat elsewhere. -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) pgpPaxpB7jwvO.pgp Description: PGP signature
Re[2]: [gentoo-dev] Decision to remove stage1/2 from installation documentation
22.11.2005, 17:30:50, Chris Gianelloni wrote: On Tue, 2005-11-22 at 09:54 -0600, Lance Albertson wrote: Also, the problem is not so much needing manpower for testing as far as Release Engineering is concerned. It is instead having some method in place where devs actually perform QA on their own packages. A prime example of this is bug #110383. I was always under the impression that if you were adding a flag to a package that affected system that it was your responsibility to ensure that system still works, rather than passing it off onto the Release Engineering team. Now, I don't know what package it is that is pulling in hal for this user, so it most likely is not hal's fault, but it illustrates the point perfectly. Blame vapier for that one ;p (Bug 99533 half-fixed for ~arch only); alternatively, you can blame usata for adding emacs support to gpm in the first place (Bug 80217). -- jakub pgprFm6K2qXMG.pgp Description: PGP signature
Re[2]: [gentoo-dev] Re: Decision to remove stage1/2 from installation documentation
22.11.2005, 18:51:12, Simon Stelling wrote: Harald van D?k wrote: (Note that I'm not going to argue either way whether this is a good thing; I'm merely pointing out that the docs do say we're about choice.) You still can choose between stage3 and stage3+GRP without having to do anything but following the handbook :) Ah, that's a nice choice... ;p Seriously, I suppose noone plans to remove stage1 from the mirrors; then it would be nice to have it properly documented (probably outside of handbook and with warning that it's an unsupported install method if releng wish so). It's still useful for people and I guess complete removal of docs will just lead to some half-baked howtos published in forums.g.o. and people complaining on IRC that it does not work. -- jakub pgpPPzyNO76WZ.pgp Description: PGP signature
Re[2]: [gentoo-dev] Decision to remove stage1/2 from installation documentation
22.11.2005, 19:03:49, Grant Goodyear wrote: I keep hearing this, isn't there a real difference between a stage 1 and a stage 3 install inasmuch as somebody who needs (or wants) to dramatically tailor what's in the system profile can choose to do so from a stage 1 or 2, but would have to remove packages after the fact if starting from a stage 3? I wouldn't have a problem with that, as long as we document it, but it just seems that the claim that the old and new methods produce _exactly_ the same results seems to be stretching things a bit. -g2boojum- Uhm, which reliable tools do we have for removing no-longer needed packages? emerge --depclean producing the huge red I'm broken warning? Or emerge --prune with similar warning in man page? Hmmm... -- jakub pgpiPdhkPJTAa.pgp Description: PGP signature
Re[2]: [gentoo-dev] Re: Decision to remove stage1/2 from installation documentation
22.11.2005, 19:13:36, Danny van Dyk wrote: Thomas Kirchner schrieb: | I'm against this change, personally. Stage1 has *always* been for | advanced users. If someone screws up their own system (which is possible | in any number of other ways, as well) then it's their fault. Gentoo | isn't about babying users. It is about choice. And if changing that is | the only way to reduce your workload, well... In which way do we take away your ability to choose by moving documentation from one place to another one? It's just the aim to not include this documentation into the handbook (which ends up on the installcds) and to move it out of the scope of ricers. If you look at http://www.gentoo.org/doc/en/faq.xml (How do I Install Gentoo Using a Stage1 or Stage2 Tarball?) I'd not exactly say that the documentations has been *moved*. Compare that with the original handbook. -- jakub pgpwo0tJZp6yl.pgp Description: PGP signature
Re[2]: [gentoo-dev] Decision to remove stage1/2 from installation documentation
22.11.2005, 20:57:15, Chris Gianelloni wrote: The idea was to move out the stage1/stage2 docs to somewhere else. Then create some sort of Advanced Installation Topics guide or something, to list out the replacement procedures for customizing a system from a stage3 tarball, then, eventually, drop the stage1 and stage2 tarballs. Erm, did you read what solar wrote about hardened stages and why should stage1 still stay? I was working on the idea of doing it all in stages. The problem occurred from people freaking out because they didn't bother reading the entire news blurb that tells exactly where the instructions moved to, plus links to the bug # and discussion. There's also this nice section in the Handbook. A stage3 tarball is an archive containing a minimal Gentoo environment, suitable to continue the Gentoo installation using the instructions in this manual. Previously, the Gentoo Handbook described the installation using one of three stage tarballs. While Gentoo still offers stage1 and stage2 tarballs, the official installation method uses the stage3 tarball. If you are interested in performing a Gentoo installation using a stage1 or stage2 tarball, please read the Gentoo FAQ on How do I Install Gentoo Using a Stage1 or Stage2 Tarball? That FAQ section has nothing in common with the original stage1 docs. Sorry, installing stage3 to remove all the use flags cruft subsequently, bootstrap and re-emerge the system and then ponder which packages are not needed any more (again, there's no reliable tool to remove unneeded stuff from system, I've already mentioned this once) - hmmm... :/ And - once stages 1+2 are removed (as you are suggesting above), then I'll install the system only to build my own stage1 w/ catalyst, then reformat and start over with my own stage? Ah, that makes live sooo much easier ;p Really, everybody is just up in arms over a knee-jerk reaction to not reading carefully. What it boils down to is either not knowing the facts, or trolling/flaming. Why exactly is evaporating stage1 an ultimate goal here (as it seems to me?). So don't support it, but why it should not exist? -- jakub pgp2A35Wx1G0J.pgp Description: PGP signature
Re[4]: [gentoo-dev] Decision to remove stage1/2 from installation documentation
22.11.2005, 21:58:50, Chris Gianelloni wrote: That FAQ section has nothing in common with the original stage1 docs. Sorry, installing stage3 to remove all the use flags cruft subsequently, bootstrap and re-emerge the system and then ponder which packages are not needed any more (again, there's no reliable tool to remove unneeded stuff from system, I've already mentioned this once) - hmmm... :/ No. That FAQ section is there to describe how to install from a stage1 or stage2 tarball and has nothing to do with a stage3 tarball, nor did I ever say that it would. I'm not sure I understand what you're getting at here. Uhm, do I really need to quote it here? snip How do I Install Gentoo Using a Stage1 or Stage2 Tarball? ... However, Gentoo still provides stage1 and stage2 tarballs. This is for development purposes (the Release Engineering team starts from a stage1 tarball to obtain a stage3) but shouldn't be used by users: a stage3 tarball can very well be used to bootstrap the system. /snip Sorry, but that does not answer the original FAQ question at all... The above does not describe a stage1 install, but a workaround procedure you've invented because of your strong dislike of stage1 install. However much you say the result is the same, it's not. E.g. - how exactly I get rid of those unneeded packages once I've changed the use flags, bootstrapped and rebuilt the system? Honestly, stage3 is something I don't find useful for a server install because the default use flags are aimed at desktop systems. Sure, I can use hardened stage3, compiled for i386 and enjoy the Debian feeling. ;p The whole point here is in what we want to support. So don't support it, but let it exist! Why exactly is evaporating stage1 an ultimate goal here (as it seems to me?). It's usefulness is far outweighed by the problems it causes, and it is really no longer necessary, nor has it been for over a year now. Uhm, I've seen quite a couple of examples in this debate why it is still necessary and useful. So don't support it, but why it should not exist? I'll explain this just once. If we release it, we are expected to support it. There are *tons* of examples of things we won't do because we don't want the headache of supporting it. Why should this be any different? sigh... You are not required to support it - exactly like you are not expected or required to support gcc-4 and gcc-4.1 and you can mark any bugs about it as INVALID (happens every day, quite frankly). -- jakub pgpJVJFKWnV1D.pgp Description: PGP signature
Re[6]: [gentoo-dev] Decision to remove stage1/2 from installation documentation
23.11.2005, 0:26:03, Chris Gianelloni wrote: However, Gentoo still provides stage1 and stage2 tarballs. This is for development purposes (the Release Engineering team starts from a stage1 tarball to obtain a stage3) but shouldn't be used by users: a stage3 tarball can very well be used to bootstrap the system. /snip Sorry, but that does not answer the original FAQ question at all... Umm... yeah. So you snip it RIGHT BEFORE THE INSTALL INSTRUCTIONS... Good show... *rolleyes* I can summarize those ommited instructions for you, looks pretty much like this: How do I make a cup of coffee? Uhm, you first make a cup of tea, then pour it out into the kitchen sink, and then make your coffee. emerge -e world emerge -e world emerge depclean You've missed revdep-rebuild to fix the borkage that emerge depclean produced. ;) Sure, I can use hardened stage3, compiled for i386 and enjoy the Debian feeling. ;p You can do whatever you like. Nobody is forcing you to do anything. That being said, you are not going to force *me* to do anything, either. Hmm, have I missed an argument here? Actually, the above is incorrect. You *are* forcing me to use stage3, but whatever... after all I still have the nice choice to not use GRP, as already mentioned previously, so no need to complain. Look. I don't care what you think I should do. I really don't. You can argue this point until you're blue in the face, but until I see you volunteering to do THE WORK you really have no say. This really is something that is an internal decision to Release Engineering. We have discussed it and we're in agreement here. Now, the one thing that I've not seen *anyone* here do is step up to help with any of this. Instead, all I see is flames, name calling, and other useless arguments. We decided that we do not want to put out unsupported, known broken, crap. Do you really not understand the fact that we are making an attempt to improve the quality of our distribution. We are trying to improve the end user experience. We have already seen that users are not following the documentation, as it is. The Handbook keeps growing in size and complexity, and there's no end in sight. All the while, the quality is going to shit because we crossed the line where we can feasibly test what we're producing a long, LONG time ago. You're more than welcome to argue this for as long as you want, but I am done. sarcasm class=strong Yeah, as I see it, this will only reach the acceptable quality when it goes GLI click click click way, of course also additionally hiding the dangerous use flags from users so that they cannot possibly break anything when installing, since they don't read the instruction properly. By that time, most of the people who cared will have switched to LFS, and the rest won't mind really. And additionally, this might attract a considerable Manra^^Wiva user base, so everyone will benefit. ;p /sarcasm *Now* I hope I've finally been sarcastic enough to justify the incredibly pissed-off tone you've shown in your previous reply. I've not exactly seen any flames or name calling here, and I'm not the one to blame for the fact that you're feeling overloaded. Jump back in when you are in more constructive mood. With this level of irritation caused by anyone who does not jump happily on stage1 grave, the debate lacks any sense. Bleh... -- jakub pgp8NgfK6PDnA.pgp Description: PGP signature
Re[2]: [gentoo-dev] status of http://wwwredesign.gentoo.org
21.11.2005, 13:23:29, Herbert G. Fischer wrote: Good job! - The bottom menus are very nice but I think they are in the wrong place. The natural human being will search for all the site menu items on the top or first page (without scrolling). The rule in this case is to put all menu items in one place, or, if this items need to be separated, so organize and group related items. Docs in the top then documentation right bellow and Documentation on the bottom again is a waist of space, don't you think? Well, I would like to see them on the left (and really could live without those illustrative pics accompanying them, but that's just me. ;) -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) pgpmAujfzog05.pgp Description: PGP signature
Re: [gentoo-dev] Frozen Bacula??
21.11.2005, 14:22:39, Herbert G. Fischer wrote: Hi, I'm looking forward to use Bacula 1.38.1 that was released last week but not even 1.38.0 that was released 31 october 2005 has an ebuild yet. There is some problem with it? It's abandoned? Please let me know if you need help on this ebuild. I don't know how to create an ebuild and include it on the Gentoo Portage but I'm interested in using Bacula 1.38.1 because of it's newest aditions. http://bugs.gentoo.org/show_bug.cgi?id=111677 -- jakub pgpYc8OswYHKK.pgp Description: PGP signature
Re[2]: [gentoo-dev] status of http://wwwredesign.gentoo.org
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 21.11.2005, 20:16:47, Renat Golubchyk wrote: On Mon, 21 Nov 2005 01:37:00 -0600 Lance Albertson [EMAIL PROTECTED] wrote: Variable names and commands are bright blue in the old docs. The new color is darker and that does not improve readability since the contrast is not optimal. I think a brighter tint would make it easier to distinguish the text color from the (highlighted) parts. Cheers, Renat Was like that originally, looked pretty bad and distracting. - -- jakub -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (MingW32) iD8DBQFDgjknhxfV/c66PZ4RAg/gAJ0c30PyYH49Hjt8XionDC+a3JAGZgCfUaE1 IKq3wzs1zG+UcgwNA7ypYQ4= =Dxaf -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re[2]: [gentoo-dev] Request for changes to GLEP 41
20.11.2005, 12:10:35, Mike Frysinger wrote: On Sat, Nov 19, 2005 at 04:26:20PM +, Kurt Lieber wrote: * Drop the idea of giving the arch testers an email alias altogether works for me but i think makes the GLEP less meaningful Unless we are able to move to some important things instead of flexing muscles and ego in endless debates on importance of subdomains creating pointless administrative overhead, someone *please* with sugar on top drop that idea from the GLEP. This debate starts to be pretty much ridiculous. -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) pgpWu0qWCJkCy.pgp Description: PGP signature
Re[2]: [gentoo-dev] Email subdomain
19.11.2005, 5:30:35, Stephen P. Becker wrote: Testing ebuilds when keywording/marking stable is supposed to be mandatory and such stuff does not belong into changelogs. Sorry, but that's a big no. People that add/remove keywords without making note in the Changelog deserve a massive kick in the nuts. I'm not sure if you have been paying attention to Changelogs, but all of the sane arches have and will continue to make such entries. -Steve Grrrmhhh, was it so much unclear? I mean: stable on x86 definitely belongs to changelogs, while stable on x86, thanks Jim for opening a keywording bug, Jack and Jim for testing and Joe for reminding me five times to mark it finally stable when I forgot about it does NOT. It's the responsibility of the developer who keyworded the thing anyway, ATs are not allowed to keyword stuff and don't have RW CVS access, so what is the purpose of tracking such stuff in changelogs and cluttering them? Use CVS commit messages to track such things if you think you need it. -- jakub pgpjq8z3F08C9.pgp Description: PGP signature
Re[2]: [gentoo-dev] Email subdomain
19.11.2005, 10:31:23, Thierry Carrez wrote: Corey Shields wrote: Before deciding on such proposals, it might be also wise to consult infra people who'll have to implement and maintain such things, IMHO. And, how exactly will be people having multiple roles handled here - still missing a clear answer... Jakub++ Nobody in infra is on board with this idea, so you will be hard pressed to find someone willing to implement it. What I find disturbing here is that nobody found the issue interesting enough to read the October Council decisions as to what was needed to be changed for the GLEP to be approved. But when, one month later, those requirements have been met and the GLEP approved, lots of people discover that the issue is interesting and complain about it (when it's a little too late to be changed). Erm, what exactly could have been discussed, the revised GLEP being submitted about a day before the council meeting? Are you expecting people to hang on email 24/7? I'm losing faith in Gentoo. When the GLEP was first discussed, the general mood was that we shouldn't give ATs the same powers than we give to devs (in particular, no right to vote for the Council), and in consequence a need to tell them apart. The Council rejected the proposed GLEP in that sense. Now, the mood is like the Council want to yellowstar some part of our contributors... and the discussion happen on the same list. You can't just ignore the discussion and the iterim decisions and complain afterwards when the decision is taken. I've already mentioned that I don't oppose to AT concept and making them official Gentoo stuff (and a couple of people did that as well), but drawing the distinction around an email address, resulting in troubles for infrastructure and hassle for users/other devs has not been properly considered apparently; still waiting for someone to show a single benefit of such an arrangement. Email address is a means of communication with people, not a *power*. If anyone's interested in/does care for what's the exact role of that particular person in Gentoo, that's what roll-call is for. AT or not, any person w/ @gentoo.org email address is representing Gentoo, users don't care what's the difference between ATs, forums staff and full devs and I don't see why exactly they should even care. Users also don't care if someone has CVS commit privs or voting rights. These are internal Gentoo things, email address is not playing any role in that. Now, we might we perhaps move the focus to more important issues jstubbs mentioned in his last email, expecting that any implementation of the now approved GLEP wrt the email addresses won't be pushed in a similar way the whole revised GLEP has been, until infra issues and usefulness of this are sorted out/reconsidered at least. -- jakub pgpO0DycdKZ4m.pgp Description: PGP signature
[gentoo-dev] use.defaults and pointless commits
Hello everyone, would someone more competent explain to me, why - this feature even exists - why has a mass of things been commited in there recently ? It's - confusing users - rendering /etc/portage/package.keywords useless (install a dep for one particular ebuild and enjoy the USE flag enabled globally) - causing unwanted results (I did not really install app-text/recode for the purpose of enabling USE=recode globally and make it clash with half of php USE flags e.g.) - causing pointless breakage/bailing out in current ebuilds for users that have not touched USE flags on their system at all Related links: http://viewcvstest.gentoo.org/viewcvs.py/gentoo-x86/profiles/base/use.defaults?r1=1.22r2=1.23 http://bugs.gentoo.org/show_bug.cgi?id=112074 http://bugs.gentoo.org/show_bug.cgi?id=86687#c7 Suggested solution: remove use.defaults feature from portage; meanwhile, stop adding stuff in there. It gains nothing, just confuses people and breaks things. Thanks. -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) pgphqmjgbN1UP.pgp Description: PGP signature
[gentoo-dev] Re: use.defaults and pointless commits
18.11.2005, 16:33:08, Jakub Moc wrote: - rendering /etc/portage/package.keywords useless (install a dep for one particular ebuild and enjoy the USE flag enabled globally) - causing unwanted results (I did not really install app-text/recode for the purpose of enabling Err, /etc/portage/package.use of course... -- jakub pgpq8cGF1iFA5.pgp Description: PGP signature
Re[2]: [gentoo-dev] punting the use.defaults feature
18.11.2005, 16:43:12, Mike Frysinger wrote: i see no reason to keep use.defaults around anymore, i think the rest of our config/profile system covers for it adequately and in a manner that doesnt confused people Also, IIRC, saner alternatives have been suggested, like IUSE=+bleh to enable a use flag by default on a per-ebuild basis; use.defaults is something well hidden from users, and USE flags automagically appearing/disappering after emerge sync/installing an ebuild cause a lot of confusion. - why has a mass of things been commited in there recently because they belong there and break things/confuse people? What exactly is the benefit from this? Sorry, I've apparently missed something, since I can't see much sense in committing something just because it belongs there... Did not notice any call for adding all that stuff either; actually - it's been done after someone requested to remove one particular thing from use.defaults. - confusing users the file has always confused people, whether they be user or dev One more reason to get rid of it... :) - rendering /etc/portage/package.keywords useless (install a dep for one particular ebuild and enjoy the USE flag enabled globally) unrelated Well, I don't think so... If I want to enable a feature for one specific ebuild and a USE flag in /etc/portage/package.use pulls in a dep, that in turn enables that use flag globally, it's obviously not what I intended and forces me to add yet another -flag into make.conf - causing unwanted results (I did not really install app-text/recode for the purpose of enabling USE=recode globally and make it clash with half of php USE flags e.g.) - causing pointless breakage/bailing out in current ebuilds for users that have not touched USE flags on their system at all you're confusing feature with bug ;) I actually consider this feature to be a bug... :=) -- jakub pgpQWIIF3naSh.pgp Description: PGP signature
Re[2]: [gentoo-dev] punting the use.defaults feature
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 18.11.2005, 20:18:58, Drake Wyrm wrote: Jakub Moc [EMAIL PROTECTED] wrote: Well, I don't think so... If I want to enable a feature for one specific ebuild and a USE flag in /etc/portage/package.use pulls in a dep, that in turn enables that use flag globally, it's obviously not what I intended and forces me to add yet another -flag into make.conf If you don't want portage to employ dark magic in guessing which use flags you want enabled, don't let it. Specify your use flags explicitly. Put USE=-* oneuse twouse reduse blueuse in make.conf to set the globals, and _then_ start tweaking in package.use. No. That just does not make any sense. We are enabling default flags in profiles only to force users to do -* and reinvent the wheel? - -- jakub -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (MingW32) iD8DBQFDfjTXhxfV/c66PZ4RAoxCAJwMBc3jqUoelsFRiIe0ptbwe9NWqgCeMyLw WSWg09q/ZdiRfqVqqjFQBlI= =ZE+p -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re[2]: [gentoo-dev] Email subdomain
19.11.2005, 0:29:24, Kurt Lieber wrote: What purpose does this serve? This would create all sorts of confusion. Right now, you can meet someone in IRC and make a reasonable assumption that their email address is irc nick@gentoo.org. This would confuse things horribly imo. What about people like me that span multiple roles? What happens when someone (again, like me) starts out in one area, moves to another, then still a third and finally a fourth? We're going to be updating aliases all over the place and for what? How does any of this make Gentoo Linux a better distro? Does it reduce bugs? Improve QA? Can I add -staff.gentoo.org to my CFLAGS and get a 0.1% speed increase? There is no technical reason why any of this is necessary and it doesn't provide any tangible benefits that I can see. If a user really wants to know someone's role within the project, they can go look it up on the web site. +1 on this, and please don't touch bugzie aliases, there's enough mess as it is (postgresl herd - [EMAIL PROTECTED]; apache herd - [EMAIL PROTECTED] - [EMAIL PROTECTED]) If you want to do something useful, then please check that you have existing alias in metadata.xml for the ebuilds that you are maintaining (to name a few: qt, secure-tunneling or comm-fax is NOT an existing alias on bugzilla). -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) pgpxJBU5c01Jv.pgp Description: PGP signature
Re[2]: [gentoo-dev] Email subdomain
19.11.2005, 0:58:29, Grant Goodyear wrote: My preference is that the subdomain chosen should succinctly reflect the role that arch testers serve. My personal preference would be to choose something like aide, helper, assistant, or something similar. (Indeed, I'd have preferred volunteer if it weren't for the niggling fact that we're all volunteers.) -g2boojum- Once again - I don't know if it's not been clear enough so far, from the replies on this topic: I don't have time nor desire to dig out somewhere on the web what's the correct email I should use to contact someone... there are about 200 more or less active Gentoo devs around and the last thing I need is to ponder upon what project/role that particular person is on. What's the benefit? :/ Please, don't introduce such PITA. -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) pgpsnSiumXLQP.pgp Description: PGP signature
Re[2]: [gentoo-dev] Email subdomain
19.11.2005, 1:07:40, Homer Parker wrote: On Fri, 2005-11-18 at 23:29 +, Kurt Lieber wrote: There is no technical reason why any of this is necessary and it doesn't provide any tangible benefits that I can see. If a user really wants to know someone's role within the project, they can go look it up on the web site. I'm guessing you didn't read the logs from the council meeting where it got stipulated that this be done. [1] I also apologize (again) for it hitting the list the day before it was to be voted on, and stated that it could wait if need be. Council seemed to be pleased with it enough to allow it to pass. [1] http://www.gentoo.org/proj/en/council/meeting-logs/20051013.txt /me wanders off in search of his flameproof suit Sorry, but the above does not make the thing any better than an *officially approved* PITA. Does not really answer klieber's question at all, nor does it answer the objections of other people expressed in this thread. -- jakub pgp8uBACEGwUH.pgp Description: PGP signature
Re[2]: [gentoo-dev] Email subdomain
19.11.2005, 1:38:03, Grant Goodyear wrote: Incidentally, the benefit is to make users who are actively helping Gentoo feel like they're part of the family. It was decided that a straight @gentoo.org address would be confusing, though, since most people associate those addresses with developers. I'm fairly agnostic on the whole thing, myself, but since the Council voted to approve the GLEP, I was simply trying to do my best to put forth a proposal that fit within that framework. -g2boojum- Uhm, no? Most people associate those addresses with people associated with Gentoo, perhaps? And, most people are not interested in internal Gentoo structure and workings, as well? Before deciding on such proposals, it might be also wise to consult infra people who'll have to implement and maintain such things, IMHO. And, how exactly will be people having multiple roles handled here - still missing a clear answer... I'm *not* against the concept of arch testers at all, in fact I find this idea pretty beneficial, but why do we need to complicate things and why do we need to create third-level domain emails for that? -- jakub pgpMA7vL46NrY.pgp Description: PGP signature
Re[2]: [gentoo-dev] Email subdomain
19.11.2005, 3:07:41, Ciaran McCreesh wrote: Sure, recognise their contributions, by giving them credit in ChangeLogs. How exactly does testing stuff fit into *changelogs*, have I missed something? -- jakub pgpd4At0gxKS4.pgp Description: PGP signature
Re[2]: [gentoo-dev] Email subdomain
19.11.2005, 3:49:46, Ciaran McCreesh wrote: On Sat, 19 Nov 2005 03:27:13 +0100 Jakub Moc [EMAIL PROTECTED] wrote: | 19.11.2005, 3:07:41, Ciaran McCreesh wrote: | Sure, recognise their contributions, by giving them credit in | ChangeLogs. | | How exactly does testing stuff fit into *changelogs*, have I missed | something? Stable on $arch, thanks to $at1 and $at2 for testing and hunting down build issues. Thanks, no... Reminds ne of the debates on forums.g.o, why emerge --changelog feature is useless and why people file pointless bugs: too much irrelevant stuff. Testing ebuilds when keywording/marking stable is supposed to be mandatory and such stuff does not belong into changelogs. (Submitting patches is naturally completely different thing, but that's not what ATs do 99% of the time they spend testing stuff). -- jakub pgpQVYcgsQSLw.pgp Description: PGP signature
Re[2]: [gentoo-dev] Re: Re: GLEP 42 Critical News Reporting Round Two
7.11.2005, 20:11:23, Grobian wrote: Ciaran McCreesh wrote: On Mon, 07 Nov 2005 19:32:38 +0100 Grobian [EMAIL PROTECTED] wrote: | So, what list should the user that wants to receive those | **important** messages sign up to? That's your first misconception right there. Most users don't sign up for things. Doesn't matter. If the important messages aren't posted or you have to extract them yourself the effect is the same. Besides that, I see no arguments why users don't. No proof either. OK, I'd really suggest you join #gentoo-apache for a week, if you want some proof. Browsing forums.g.o. rants wrt the Apache layout changes is also helpful in this respect. ;p -- Jakub pgpZ3qNIGXwpw.pgp Description: PGP signature
Re[2]: [gentoo-dev] GLEP ??: Critical News Reporting
1.11.2005, 11:00:22, Thierry Carrez wrote: Aren't those messages displayed after the damage is done ? Typical use : - emerge --sync run as a daily cron job - emerge -a mysql - great, a new version is there. Typing Yes - system gets borken - emerge spits out message saying 14 files need updating and there is 1 unread news item I'm probably missing something here. Please elaborate on how this GLEP meets the Preemptive design goal... I'm probably missing something obvious here, because I can't see why *existing* emerge --changelog code cannot be recycled for this feature to display upgrade messages when running emerge -uDav world... -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) pgpGyWAZW9tWL.pgp Description: PGP signature
Re[2]: [gentoo-dev] GLEP ??: Critical News Reporting
1.11.2005, 13:26:57, Ciaran McCreesh wrote: On Tue, 01 Nov 2005 13:16:03 +0100 Thierry Carrez [EMAIL PROTECTED] wrote: | For them to know about it, they need to be warned when they do their | emerge -p world or emerge -a mysql that the upgrade is not as easy | as it seems. People using a cron job to sync are probably a | significant part of our user base... Have Portage give a red flashy before emerge if there're unread news items? Although, a better solution for users who cron sync would be to have said cron mail them all the relevant news files... Uhm... emerge sync is a *bad* time to display upgrade messages, it's simply irrelevant at that time, I'm not upgrading anything at the moment and might not be upgrading for next week or so. The messages should be displayed when I'm about to upgrade an ebuild which has an upgrade note associated with the new version. Sending mail via cron might be a nice optional feature for those who want to use it. -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) pgpt93NCyWMev.pgp Description: PGP signature
Re[2]: [gentoo-dev] GLEP ??: Critical News Reporting
1.11.2005, 13:48:06, Ciaran McCreesh wrote: | The messages should be displayed when I'm about to upgrade an ebuild | which has an upgrade note associated with the new version. Sending | mail via cron might be a nice optional feature for those who want to | use it. Not really a good idea, a) because news items aren't tied directly to ebuilds, and b) because people like advance warning of when you upgrade Apache, all hell will break loose! rather than having it sprung on them suddenly when they're trying to do a quick update. Getting the news item in advance allows for planning. What do you mean they aren't tied to ebuilds? I don't really understand what this feature should do then, it seems. Once again, what's wrong with reusing emerge --changelog mechanism for displaying this kind of information? I'm not particularly happy with idea of emerge as a newsreader really, IMHO we should display relevant, vital upgrading information *when relevant*, not to inform users about upgrades that they are not interested in in the least. Example: Don't bother me with mysql-4.1 upgrade instructions, I don't plan to upgrade to that version and did put it into package.mask. Another example: Don't bother me with upgrade instructions for ~arch ebuilds, I'm running stable. I want to read them when I decide to upgrade, put them into package.keywords and run emerge -uav someebuild/world or when it goes stable. And please, keep the thing simple so that I can be done in reasonable amount of time and does not follow the destiny of einfo/ewarn logging (3 years and counting). -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) pgpLvp5ixQ5zP.pgp Description: PGP signature
Re[2]: [gentoo-dev] quixote currently unmaintained
1.11.2005, 18:04:08, Carsten Lohrke wrote: On Monday 31 October 2005 22:44, Petteri Räty wrote: Checked the bugzilla and the two open bugs seem to be version bumps. I think the policy is not to remove working ebuilds from the tree although they are not maintained by anyone. It's not policy to keep unmaintained stuff in the repository either. I really welcome it, when someone takes the stance to clean out the tree a bit. There's too much unmaintained or even broken stuff in it. I think Grant should go for it, unless you or someone else takes over maintainership. OK, lets remove perl. -- Jakub pgpXOUoCqvmmX.pgp Description: PGP signature
Re[2]: [gentoo-dev] Re: ${PORTDIR}/profiles/package.use
21.10.2005, 13:51:17, Ciaran McCreesh wrote: On Fri, 21 Oct 2005 04:37:16 -0700 Duncan [EMAIL PROTECTED] wrote: | Also consider the case of media-libs/libsdl. It uses novideo, | noaudio, and nojoystick, for the simple reason that for the vast | majority of folks who'd have reason to merge the package, turning OFF | that functionality makes entirely NO sense and having it OFF by | default, if the USE flags weren't enabled for some reason, would be | entirely unintuitive. Not a problem. Just turn on the video, audio and joystick USE flags in the base profile. Or don't make them USE flags at all... These three no* flags should have been killed ages ago. They've never been useful for anything else than causing tons of PEBKAC bugs. :-( This stuff is not optional, period. -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) pgp6K318NXoTl.pgp Description: PGP signature
Re[2]: [gentoo-dev] Tomcat 5.5 in portage
12.10.2005, 19:36:41, Petteri Räty wrote: RUMI Szabolcs wrote: Hello! Tomcat 5.5 is out since a year now and still didn't make it into portage. It doesn't even depend on JDK 1.5.0 in a sense that there is a compat tarball which makes it work with JDK 1.4 so why isn't there a tomcat-5.5 ebuild in portage? Is there some reason for this? The java herd is heavily understaffed. You can find an ebuild in our experimental tree in: http://gentooexperimental.org/svn/java/gentoo-java-experimental/ Regards, Petteri Räty (Betelgeuse) That's what I've been getting for a couple of days: svn: PROPFIND request failed on '/svn/java/gentoo-java-experimental' svn: PROPFIND of '/svn/java/gentoo-java-experimental': SSL negotiation failed: SSL error: unknown protocol (https://gentooexperimental.org) H? -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) pgpy9ZrBqSkZZ.pgp Description: PGP signature
Re[2]: [gentoo-dev] Council meeting Thursday October 13th
11.10.2005, 10:39:56, Jan Kundrát wrote: On Monday 10 of October 2005 23:36 Marcin Kryczek wrote: council could decide if it's worth to try and put some herd (GDP?) to be responsible for it. Uh, and what *exactly* do you mean by be responsible for it? I mean, are we supposed to watch every possible communication channel or would the people involved submit bugs to us about newly made decisions? Anyway, what about some weekly message to -core? Cheers, -jkt Bleh, what's wrong w/ the idea to create gentoo-dev-annouce or whatever it would be called? Many people gave up on reading -core due to the constant flames... -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) pgp6BGNdGDmp5.pgp Description: PGP signature
Re[2]: [gentoo-dev] Council meeting Thursday October 13th
11.10.2005, 10:52:35, Jan Kundrát wrote: On Tuesday 11 of October 2005 10:47 Jakub Moc wrote: Bleh, what's wrong w/ the idea to create gentoo-dev-annouce or whatever it would be called? Many people gave up on reading -core due to the constant flames... Nothing, of course. But how would you prevent flames from happening on a new list? :-) Cheers, -jkt Hint: read-only ml? :=) -- Best regards, Jakub Moc pgpVNyY7bkUBI.pgp Description: PGP signature
Re[2]: [gentoo-dev] Interactive emerge
2.10.2005, 20:13:52, Fernando J. Pereda wrote: On Sun, Oct 02, 2005 at 08:01:08PM +0200, Maurice van der Pot wrote: | On Sun, Oct 02, 2005 at 07:50:53PM +0200, Fernando J. Pereda wrote: | Also when FEATURES=test ? In such case the mod_php and php packages | are broken. They ask you to save, reject or send the result of the | tests if I'm not mistaken | | Even if they succeed? The point of test is to get some additional | confidence that the package actually works. It doesn't mean you want to | be bothered for nothing. I can't remember if they failed or not, but if the test failed then the ebuild should just die, no? I just don't feel like recompiling it again :) Cheers, Ferdy No, the ebuild does not die, there are things known to be broken in those tests. About 10-15 tests always fail, IIRC. Otherwise, it's Bug 59337. -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) pgp367NYmDQ9x.pgp Description: PGP signature
Re[2]: [gentoo-dev] default logger
28.9.2005, 2:50:20, Alec Warner wrote: I think syslog-ng is a better logger, except the default configuration is pretty icky. I would shoot for something better, even if it's in /usr/share. I heard hardened's config is quite nice :) At least provide an example of a config that sorts logging out into seperate files like most distro's do. What about this one? http://www.gentoo.org/doc/en/security/security-handbook.xml?part=1chap=3#doc_chap4 -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) pgpkHVcYhc3mf.pgp Description: PGP signature
Re[2]: [gentoo-dev] maintainer-wanted ebuilds which are tagged REVIEWED
13.9.2005, 13:39:10, Chris Gianelloni wrote: I know that this is automatically generated, but can we either change the bug subjects or figure out some way to add proposed categories to these? I think changing the summary should suffice. For the ones with categories, I can pretty much figure out what they are. For the ones without, I have no clue and have to look at the bug to determine if I would even be interested in it. Uhm, if the ebuild submitter does not choose a category, then we'd have to change the subject ourselves (and sometimes I'm not even remotely sure into which category would the particular ebuild fit). *shrug* -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) pgp0H6YHz6s0M.pgp Description: PGP signature
Re[2]: [gentoo-dev] maintainer-wanted ebuilds which are tagged REVIEWED
13.9.2005, 20:31:30, Ciaran McCreesh wrote: On Tue, 13 Sep 2005 10:52:33 -0400 Chris Gianelloni [EMAIL PROTECTED] wrote: | Uhm, if the ebuild submitter does not choose a category, then we'd | have to change the subject ourselves (and sometimes I'm not even | remotely sure into which category would the particular ebuild fit). | | Try asking the submitter? *grin* Yeah, I reckon we could stick a rough category in the title before we tag stuff as REVIEWED. Sometimes it might end up as games-?/whatever rather than a full category though. Jakub -- this okay with you? Sure, I've already managed to delete all the bugspam this caused... *g* But yeah, it's good for some rough orientation, at least blah-?/ebuild if unsure. -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) pgpVH6QNbkLgR.pgp Description: PGP signature
Re[2]: [gentoo-dev] maintainer-wanted ebuilds which are tagged REVIEWED
13.9.2005, 21:08:43, Ciaran McCreesh wrote: On Tue, 13 Sep 2005 20:57:24 +0200 Jakub Moc [EMAIL PROTECTED] wrote: | Sure, I've already managed to delete all the bugspam this caused... | *g* Yeah, maintainer-wanted bug emails are a pain in the ass. How about we turn off email sending for: * I'm added to or removed from this capacity * Priority, status, severity, and/or milestone changes * Keywords field changes * CC field changes Anyone know the maintainer-wanted bugzilla password? :) Not entirely sure about the keywords thing, other than that - kplznowtnx ;) Someone who has the privs to do it? -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) pgp7GhHD4DVWf.pgp Description: PGP signature
Re[2]: [gentoo-dev] ROX: maintainer-wanted and apps out of date
12.9.2005, 16:03:17, Chris Gianelloni wrote: Many users seem to think that a WONTFIX is non-negotiable. I tend to agree with them, for the most part. Rather than WONTFIX them, simply tell them that they won't be included as-is. WONTFIX gives the user the impression that we are not interested in their work or the package, when this is not the case. http://dev.gentoo.org/~ciaranm/docs/mw-faq/wontfix.txt Telling them that the ebuild won't be included as-is pretty much equals WONTFIX, except for the major disadvantage that is can't be tracked via Bugzilla at all... not so much fun really, considering there are over 600 new ebuild bugs there. -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) pgpkIXtUJqkVy.pgp Description: PGP signature
Re[2]: [gentoo-dev] ROX: maintainer-wanted and apps out of date
12.9.2005, 19:32:32, Carsten Lohrke wrote: To have even more unmaintained packages in the tree. The tree it is that needs QA. If maintainer-wanted bugs stay open forever - who cares. [left for later reference] Thanks for the pointer. :p So from the user point of view it's better to file a request without attaching an ebuild, because it wouldn't directly resolved WONTFIX?! (Before you answer that: From the user point of view, not your's.) I mean I'm often giving a pointer on an formal issue or a very wrong attempt, but being that strict is not neecessary, discouraging and probably some even take the chance to molest about Gentoo, imho. Not at all. There are *lots* of people that actually fix their ebuilds very quickly and appreciate the comments. And - as everywhere - there's also a bunch of people that start bitching instead of taking 5 minutes to fix the thing. Since you said above, that you really don't care if those user-submitted ebuilds will ever get into portage or will stay in maintainer-wanted queue forever and that's the stuff in portage that actually matters QA-wise, I'm missing why are you worried about people not submitting their ebuilds any more. At the very least, reviewing user-submitted ebuilds and marking things WONTFIX/CANTFIX/REVIEWED makes it possible to filter out the outdated and dead-upstream crap, as well as things about which those people who filed the bugs don't care any more. And, if someone picks those ebuilds up and decides to maintain them, he can focus more on testing the actual app then fixing a broken ebuild (or even committing a broken ebuild into the tree). -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) pgphWXw2v8ZMb.pgp Description: PGP signature
Re: [gentoo-dev] metadata revised - removal of packages
9.9.2005, 11:58:21, Torsten Veller wrote: Well, i was told that adding the maintainer-needed herd is not a good idea and it is best to remove metadata.xml if no valuable information remains. I couldn't find information on that. Can somebody explain? I don't understand this idea on removing metadata.xml. There are lots of packages with [EMAIL PROTECTED] as herd in metadata. Removing metadata.xml is IMHO a really bad idea. Just will make me look at the ChangeLog, assign to maintainer-needed and CC someone who has touched the ebuild most often. 2) What is the next step after the last maintainer is removed from metadata.xml? Well i announced these packages on -dev. Now i can wait some time (how long?) and then? Put maintainer-needed in herd seems a logical solution to me. Hmmm. Maybe I missed something? -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) pgpiyjlxnau7G.pgp Description: PGP signature
Re[2]: [gentoo-dev] tentative x86 arch team glep
5.9.2005, 22:09:28, Stuart Herbert wrote: I kept PHP5 masked for those 14 months, and (as Jakub and others can confirm) most of the feedback has been limited to unmask that puppy (sometimes put in stronger terms ;-) There were some bugs from users who had found issues, but not many. Well, yeah - and the same goes for e.g. MySQL-4.1; the only thing you get from p.masking popular packages is a be-weekly bug like WTH is this still masked, upstream says it's stable and best version released yet which everyone should upgrade to ;p Real testing from users comes when it goes to ~arch, then they start screaming hell, it broke my box, why isn't this p.masked, it's so buggy! :) So, unless we have a *lot more* devs to do thorough testing of p.masked ebuilds (totally unfeasible to test all the PHP5 features e.g., if you have some 3 people in php herd), then it's largely up to users to do the testing in ~arch. p.mask ebuilds will be tested by really *few* users, so most of the bugs will stay unnoticed until this is moved to ~arch. Rather than unmask the packages before they were read, I changed to another approach. I moved the work out of Portage into an overlay instead. This worked well. It has attracted a bunch of regulars to #gentoo-apache who have spent the last few months finding the bugs that existed, and making sure that they're fixed and stay fixed. It looks likely that we'll get some new devs out of that too :) Absolutely. The overlay made the whole thing get into portage *much* faster then all those months in p.mask. -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) pgpceAwPvJyPK.pgp Description: PGP signature
Re[2]: [gentoo-dev] Re: app-portage/genlop: 9 open bugs, dead upstream
25.7.2005, 10:41:09, Ivan Yosifov wrote: If we all like it that much, perhaps someone will want to take over it, make a homepage ( or just set www.gentoo.org as the homepage ) and go through the open bugs. If not - it can be either dropped or left as it is currently. If no one cares maybe the user base is not that large. I don't know why this ebuild should be dropped, I have much better candidates for removal - such as y-windows ;p All the bugs are trivial and half of them is solved in 0.30.3 which could be marked stable. -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) pgpZuP5xIFCk6.pgp Description: PGP signature
Re[2]: [gentoo-dev] emerge -e system stage2
7.7.2005, 19:42:56, Chris Gianelloni wrote: On Thu, 2005-07-07 at 12:15 -0500, Jory A. Pratt wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 every single install has an issue with python-fchksum and gcc this needs to be merged after python otherwise python calls the wrong compiler. Hope we can get this fixed before our 2005.1 release. I'm sorry, but could you actually explain that a little? I'm building stages and testing them over here quite comfortably without seeing any issues. http://bugs.gentoo.org/show_bug.cgi?id=88777#c9 has some explanation... -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) pgpVunBjgQcyH.pgp Description: PGP signature
Re: [gentoo-dev] emerging a library with debugging symbols
3.7.2005, 18:04:38, Nelson Benítez wrote: the sources are still around after emerging. But for some strange reason the so file in the work directory has debugging symbols (not stripped) but the so file installed hasn't debugging symbols (stripped), as you can see here: What about FEATURES=nostrip ? :) -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) pgp1U3v1QCSuL.pgp Description: PGP signature
