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: [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: [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[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] [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
[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
[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: 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
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
Re[2]: [gentoo-dev] [RFC] QA Team's role
27.2.2006, 22:33:21, Ciaran McCreesh wrote: On Mon, 27 Feb 2006 21:49:23 +0100 Jakub Moc [EMAIL PROTECTED] wrote: | rhetorical question | May I ask how is that related to webapp-config? | /rhetorical question It is related to Stuart, and hence utterly relevant to the conversation. Ah, sure - so the topic is that you have personal issues with Stuart and are washing your dirty laundry in a public ML? You still haven't posted posted a *single example* of webapp-config brokeness. You, I'd say you should either back up claims about all the ways in which webapp-config is broken or apologize to the concerned developers for false claims. Still waiting. -- 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 ;) pgp56jdp76Pag.pgp Description: PGP signature
Re[2]: [gentoo-dev] [RFC] QA Team's role
27.2.2006, 22:32:39, Ciaran McCreesh wrote: I quote the official policy: http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2chap=1 Occasionally, ebuilds will have conflicting USE flags for functionality. Checking for them and returning an error is not a viable solution. Instead, you must pick one of the USE flags in conflict to favour. One example comes from the msmtp ebuilds. The package can use either SSL with GnuTLS, SSL with OpenSSL, or no SSL at all. Because GnuTLS is more featureful than OpenSSL, it is favoured: It's a QA violation, and not a feature as you claim. I find it particularly worrying that you try to pass of blatant policy violations as a feature. The first step in QA is detecting that there is a problem. 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 Moreover, the cited howto is wrong, since it will break built_with_use checks, as explained on the relevant bug and as explained here on mailing list before. The howto also doesn't apply to cases like recode vs. mysql, because that's a completely different functionality, you can't exactly choose which one is better on behalf of the user. So, to sum it up - you can't make up for portage's lack of features by inventing a policy that doesn't work. Once again - until portage can handle USE-based dependencies and until portage can handle conflicting use flags, there's nothing that could be done here. -- 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 ;) pgprwDQAkXsrs.pgp Description: PGP signature
Re[2]: [gentoo-dev] [RFC] QA Team's role
27.2.2006, 22:32:39, Ciaran McCreesh wrote: I quote the official policy: http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2chap=1 Occasionally, ebuilds will have conflicting USE flags for functionality. Checking for them and returning an error is not a viable solution. Instead, you must pick one of the USE flags in conflict to favour. One example comes from the msmtp ebuilds. The package can use either SSL with GnuTLS, SSL with OpenSSL, or no SSL at all. Because GnuTLS is more featureful than OpenSSL, it is favoured: And - one more note - 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 -- 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 ;) pgpAWJJBeYTVG.pgp Description: PGP signature
Re[2]: [gentoo-dev] [RFC] QA Team's role
28.2.2006, 13:54:36, Stephen P. Becker wrote:
You still haven't posted posted a *single example* of webapp-config
brokeness. You, I'd say you should either back up claims about all the ways
in which webapp-config is broken or apologize to the concerned developers
for false claims.
Still waiting.
OK, here is one. It seems that webapp-config silently assumes your
webserver is apache by default. If a user uses lighttpd for example,
this is totally incorrect.
Why don't you voice your solutions on Bug 11007? The whole underlying stuff
is hell broader than what webapp-config assumes or doesn't assume.
Now, this doesn't cause webapp-config to fail to emerge, but the first
time you emerge any webapp, you get a big nasty error about no Apache
group available, which further requires the end user to dig around the
webapp-config manpage to figure out the correct file to edit *just* to
get a silly php script to install in the correct location.
The above is a direct result of purging all kind of useful predefined
users/groups from /etc/{passwd,group} without considering any wider
consequences. It has already caused circular deps and broke a couple of
things, included but non-limited to installing Gentoo itself (search
bugzilla for related bugs). Where is the whole benefit from this, I still
have to see.
webapp-config should be updated to handle such situation more gracefully, so
why don't you file a bug about this? Is that all you have wrt all the ways
in which webapp-config is broken? If so, that's not really much of a
justification of the broad claim ciaranm has made as a QA project member.
And please, don't tell me this is a feature. It breaks noninteractivity
for every webapp in the entire tree.
What kind of non-interactivity? What's this universal non-interactivity
blurb of yours and ciaranm's about? There's no such thing when it comes to
configuration. If you want automated configuration, then please use
Windows and stop moaning. If you don't want to read manpages or at least
--help, then please use Windows as well. If you want to use non-default
setup, then you need to change default values, that's what common sense
dictates at least. And don't use the (non)-interactivity magical formular in
a context where it has zero sense.
--
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 ;)
pgpFxviIqcbv0.pgp
Description: PGP signature
Re[2]: [gentoo-dev] [RFC] QA Team's role
28.2.2006, 15:00:49, Stephen P. Becker wrote: What kind of non-interactivity? What's this universal non-interactivity blurb of yours and ciaranm's about? There's no such thing when it comes to configuration. If you want automated configuration, then please use Windows and stop moaning. If you don't want to read manpages or at least --help, then please use Windows as well. If you want to use non-default setup, then you need to change default values, that's what common sense dictates at least. And don't use the (non)-interactivity magical formular in a context where it has zero sense. No! You are completely missing the point. The non-interactivity of which we speak is the idea that when you emerge some package, it is perfectly reasonable (and in fact should be required) to expect that package to install to your userland with no further prodding. There should be no USE collisions which cause the emerge to die. There should be no default configuration which will break other packages in the tree by default. Note that in no way am I talking about auto-configuration, as that would be silly. The example problem with webapp-config which I have described here forces a user to intervene to get packages to install to the proper location. This is not desirable. Selecting a webserver to use with a webapp package is a part of configuration. So again, the whole non-interactive idea is irrelevant wrt webapp-config and non-default setups. No defaults in default config won't work/won't improve anything either, since some webapps need to have their config files server-owned. Running a server and webapps is not a no-brainer which should just automagically work; to the contrary - users should think about what they are doing or they just should run a server app. Basically, I really don't see why webapp-config can't have some logic built in which makes it smart enough to figure out which webserver somebody is using. Sure, you can make webapp-config depend on virtual/magic where RDEPEND=|| ( app-admin/artificial-intelligence app-admin/mind-reader ) and then emerge lighttpd apache a couple of servers here some random webapps here I think it's pretty much obvious that this just won't work since such virtual doesn't and won't exist. -- 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 ;) pgpZk7zF5dP7K.pgp Description: PGP signature
Re[2]: [gentoo-dev] [RFC] QA Team's role
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. And silently sticking parts of unofficial gentoo devmanual into official Gentoo docs, and then silently turning them into a policy enforced under QA disguise is a bad very practice, and pretending that this has been in the mentioned _howto_ (not policy) for a long time as just plain silly. Since you haven't answered the question in one of my previous emails at all, let me ask again: 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 | 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). | The howto also doesn't apply to cases like | recode vs. mysql, because that's a completely different | functionality, you can't exactly choose which one is better on behalf | of the user. No, it does apply. 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!) | So, to sum it up - you can't make up for portage's lack of features by | inventing a policy that doesn't work. Once again - until portage can | handle USE-based dependencies and until portage can handle | conflicting use flags, there's nothing that could be done here. Until Portage can handle conflicting USE flags, one should take the policy-mandated solution that has been sufficient for everyone else for four years or more. Sure, it's not perfect, but it's a hell of a lot better than repeatedly exploding in the user's face midway through an install. No, noone should enforce a policy that - doesn't exist (see above) - hasn't been discussed properly and approved (see above) - it's consequences haven't been considered wrt whether its benefits overweight the negatives and whether is useful at all. -- 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 ;) pgpj5iahK5mPv.pgp Description: PGP signature
Re[2]: [gentoo-dev] [RFC] QA Team's role
28.2.2006, 16:29:07, Stephen Bennett wrote: On Tue, 28 Feb 2006 16:08:05 +0100 Jakub Moc [EMAIL PROTECTED] wrote: 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 According to my recollection, it was discussed between members of QA and devrel. According to the CVS logs, it was committed by a member of devrel, at QA's request. You can't pass it off as a QA project conspiracy, since they didn't make the change. I'm sorry, but discussing such stuff affecting pretty much everyone who writes ebuilds among a couple of people simply isn't enough to make this a policy. And then silently applying this and starting to scream QA violation, look, what a nasty QA violation!!! is plain ridiculous. Punting every single piece of broken sh*t from the tree requires notifying everyone on -dev ml and allowing a period of time before it's actually done, so silently changing/stating policies is a very broken practice. -- 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 ;) pgpOpdcyaXkH8.pgp Description: PGP signature
Re[2]: [gentoo-dev] [RFC] QA Team's role
28.2.2006, 16:42:46, Ciaran McCreesh wrote:
On Tue, 28 Feb 2006 16:26:37 +0100 Jakub Moc [EMAIL PROTECTED] wrote:
| If you can't do any better, then please apologize for your conduct
| and false claims and shut up... TIA.
Sure I can do better. But you didn't originally ask for better, you
asked for anything. If better's what you're after:
SLOT=${PVR}
Eh? Seen kernel2.eclass? Going to file a bug about that as well? Seen
gst/gstreamer eclasses? Going to file QA bugs about them as well? And -
what's exactly the QA violation there, if you could enlighten us?
Maybe I could point you to
http://dev.gentoo.org/~plasmaroo/devmanual//general-concepts/slotting/ ?
Now, please apologise for insinuating that I don't have any real claims
to make. I find it extremely offensive that you're questioning my
technical ability.
No, I won't apologize, I don't see any reason to do it after all the baloney
you've shown here. I have to agree w/ rl03 that your benefits for this whole
project are net negative.
--
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 ;)
pgpEIQRV01qb0.pgp
Description: PGP signature
Re: [gentoo-dev] Policies (was: [RFC] QA Team's role)
28.2.2006, 17:24:21, Danny van Dyk wrote: Hi Jakub, If you don't agree with the contents, why didn't you raise your opposition earlier? I don't feel any need to raise opposition against some unofficial manual, what would be the point in that? I'm raising my hand against silently incorporating parts of it (that affect a lot of stuff in the tree) into official docs without a proper discussion, even more so that they are being claimed as an official QA policy now. Documents located in private devspace of some devs are non-official and noone checks their contents for correctness, they are private activity of those devs. If you agree with the contents, please ask yourself if the current discussion is necessary. See above. -- 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 ;) pgpCnRIPUEj5F.pgp Description: PGP signature
Re[2]: [gentoo-dev] [RFC] QA Team's role
28.2.2006, 17:35:32, Ciaran McCreesh wrote: On Tue, 28 Feb 2006 17:11:58 +0100 Patrick Lauer [EMAIL PROTECTED] wrote: | Ok, sorry for being dumb :-) | What exactly is the issue there? I don't see the issue in setting SLOT | depending on ... uhm ... some variable. Looks kinda logical at first | glance, but I'm not aware of the issues it causes. PVR includes the revision of an ebuild. This means that if a revbump is made on a webapp package to fix a critical flaw, users will still have the old broken package installed too. This is especially relevant for security issues, but also applies to other kinds of fix. Not including the revision into the SLOT can break the apps by removing the needed files from a live site... I still can't see any *QA* violation there. Ebuilds can't override this either. Read on in the eclass and you'll notice that it checks that SLOT hasn't been changed to something sane. Yeah, it checks for that since that's the way the eclass is designed. You can't declare a slot in a kernel ebuild either. Well, starts to be boring - so, either come with something valid from QA standpoint or stop now. -- jakub pgpdnAxBRtsYS.pgp Description: PGP signature
Re[2]: [gentoo-dev] [RFC] QA Team's role
28.2.2006, 18:09:54, Ciaran McCreesh wrote: On Tue, 28 Feb 2006 18:00:03 +0100 Jakub Moc [EMAIL PROTECTED] wrote: | PVR includes the revision of an ebuild. This means that if a | revbump is made on a webapp package to fix a critical flaw, users | will still have the old broken package installed too. This is | especially relevant for security issues, but also applies to other | kinds of fix. | | Not including the revision into the SLOT can break the apps by | removing the needed files from a live site... I still can't see any | *QA* violation there. Again, that's a design flaw. It's an eclass that's abusing SLOT, thus it's a QA issue. OK, so kernel-2.eclass is abusing the slot as well, go scream on kernel devs. | Yeah, it checks for that since that's the way the eclass is designed. | You can't declare a slot in a kernel ebuild either. One is a design flaw. The other is not. Ah, tell me about the dual standards :P | Well, starts to be boring - so, either come with something valid from | QA standpoint or stop now. This is a valid issue from a QA standpoint. This is also why I'm not going to waste my time doing a proper list -- rather than addressing issues, they are being passed off as irrelevant or even features. Next time, rather think a couple of times up before claiming something very broken on a public mailing list where you have no proof for such claims. Will be immensely helpful for everyone involved. Thanks. -- jakub pgpxuk46qcDZF.pgp Description: PGP signature
Re[2]: [gentoo-dev] [RFC] QA Team's role
28.2.2006, 18:11:57, Ciaran McCreesh wrote: On Tue, 28 Feb 2006 17:02:11 + Renat Lumpau [EMAIL PROTECTED] wrote: | On Tue, Feb 28, 2006 at 04:35:32PM +, Ciaran McCreesh wrote: | Ebuilds can't override this either. Read on in the eclass and you'll | notice that it checks that SLOT hasn't been changed to something | sane. | | Excepting that you can set WEBAPP_MANUAL_SLOT=yes and set SLOT to | whatever the hell you want. But don't let my facts get in the way of | your nonsense. And it sticks out a nasty ewarn and says that the ebuild is probably broken. Again, you're dismissing QA issues as nonsense, and you wonder why I don't waste my time doing a full audit. Ah, so this is the horrible and nasty ewarn? 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? Go file bugs about those nasty QA notices portage spits out every now and then as well, if you are so concerned about warnings. Indeed, please don't waste your time and first of all don't waste ours. Go audit whatever you want, but please keep this off-list. Or maybe don't stare on the screen if ewarns scare you that much. ;) -- jakub pgp9R7YoX0YoI.pgp Description: PGP signature
Re[2]: [gentoo-dev] [RFC] QA Team's role
28.2.2006, 18:38:10, Ciaran McCreesh wrote:
Sheesh, you'll probably claim that this isn't broken next too:
if [ ${IS_UPGRADE} = 1 ] ; then
einfo Removing old version ${REMOVE_PKG}
emerge -C ${REMOVE_PKG}
fi
No, I won't claim that... I'd rather love to know why didn't you point out
to an obvious eclass flaw about 30 emails and many hours ago, saving us from
all the eclass formating, slotting and ewarn blurb. The above needs to be
fixed, period.
To return to the original topic - focus your QA efforts on real issues. Same
goes for that non-interactivity stuff. QA that serves no other purpose than
inventing problems to enforce an inevitably hackish solution (there's no
good one because the needed tools are not available) is not useful at all.
There's nothing useful in inventing policies that create more problems than
they solve and that are forcing shitty bash code into the tree to work
around missing features.
Portage is a tool to install and manage packages, and serves no good purpose
on its own. Crippling installed packages and their available features for
the sole purpose of having nice ebuild tree with clean bash code is not what
QA is for. Improving the whole process is fine and welcome, as long as it
doesn't unnecessarily interfere with the desired outcome. Users need to
install some software they want to use and need its features, portage and
ebuids are only the means to do that, not a holy cow.
--
jakub
pgpbyDVjG5w40.pgp
Description: PGP signature
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] [RFC] QA Team's role
1.3.2006, 11:29:47, Danny van Dyk wrote: | 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. Hmm, you never used repoman, right? repoman checks for whitespace and tab oddities and warns you, if you want to commit them. Sure I did... that's not the breakage of a QA tool ciaranm has been talking about, though. If some tool stops to work b/c of spacing/indenting issues, then it's broken. Meanwhile, if you can't bear formating/whitespace issues, then either fix it yourself or file a bug and wait until someone gets to it or fixes it when next revbump/another bunch of more important fixes is due. Expecting that someone will fix a cosmetic issue within five minutes from the time when a bug is filed and ranting about it on #gentoo-qa and mailing lists isn't useful but rather plain annoying. -- jakub pgpR49V6Zhcqz.pgp Description: PGP signature
Re[2]: [gentoo-dev] [RFC] QA Team's role
1.3.2006, 13:09:55, Paul de Vrieze wrote:
On Tuesday 28 February 2006 21:20, Ciaran McCreesh wrote:
| if [ ${IS_UPGRADE} = 1 ] ; then
| einfo Removing old version ${REMOVE_PKG}
|
| emerge -C ${REMOVE_PKG}
| fi
This code (or an equivalent kludge/hack) does however allow features that are
of great value to our users. While I agree that such hacks should be avoided
if possible, I think in this case it is not. As such the appropriate response
is to isolate the hack in a central place, where it is clear to be seen and
can easilly be fixed. This allows the quality of the hack to be ensured,
relieving many webapps from doing hacks themselves.
While this hack is being used, some effort should be put into
constructively creating a proper solution for the problems that were
hacked around. Saying this is not allowed because of X policy is not
helpful as the costs of disallowing it greatly outweigh the costs of
overlooking it in a controlled manner.
Well yeah, but the problem here is that portage doesn't allow such stuff to
be used safely (locking issues, race conditions). And yeah, it's kinda
lacking sort of feature that would have its use in a couple of places.
--
jakub
pgpaEP0jPlTm4.pgp
Description: PGP signature
Re[2]: [gentoo-dev] QA Roles v2
3.3.2006, 6:31:17, Mark Loeser wrote: Mike Frysinger [EMAIL PROTECTED] said: one thing i dont think we give enough emphasis to is that our tools arent perfect ... sometimes we utilize QA violations to work around portage limitations ... if you want to see some really sweet hacks, review any of the toolchain related ebuilds and the hacks ive had to add to get cross-compiling to the usuable state that it is today. a handful of them would fall under the 'severe' category i'm sure. and if we want to use the lovely php example, personally i think that given portage's current limitations, the latest dev-lang/php ebuild is probably one of the best solutions that could have been developed, thanks Stuart for all the flak you've had to take over this. also, many games ebuilds break the 'non-interactive' policy by displaying licensing and making the user hit Y because portage lacks checks where the user explicitly states what licenses they accept. This somewhat touchs on what pauldv mentioned earlier, that we will acknowledge when no better possible solution is available, and some workaround is needed. As he also suggested, we should keep a list of these in the form of open bugs so that we can get a better solution somewhere in the long-term. Please, until something is clarified/some consent reached, avoid changing the docs w/ funny stuff like just flip a coin... http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/proj/en/devrel/handbook/hb-guide-ebuild.xml?root=gentoor1=1.31r2=1.32 What's the above again? QA policy? How does user benefit from flipping a coin wrt choosing a functionality? Sigh... :/ -- 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 ;) pgp9VCpGMLVmo.pgp Description: PGP signature
Re[2]: [gentoo-dev] QA Roles v2
3.3.2006, 22:19:33, Stephen Bennett wrote: On Fri, 3 Mar 2006 21:47:22 +0100 Jakub Moc [EMAIL PROTECTED] wrote: Please, until something is clarified/some consent reached, avoid changing the docs w/ funny stuff like just flip a coin... http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/proj/en/devrel/handbook/hb-guide-ebuild.xml?root=gentoor1=1.31r2=1.32 What's the above again? QA policy? How does user benefit from flipping a coin wrt choosing a functionality? Sigh... :/ It gets the point across effectively. I don't see your problem. What kind of point does it get across, exactly? That flipping a coin or forcing your personal preference is a better solution than letting users decide what kind of functionality they prefer? Don't you think users do know better? What's the point of such policy? You call forcing random feature on users instead of letting them decide QA? I don't. -- 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 ;) pgpfRMpGO6qDi.pgp Description: PGP signature
Re[2]: [gentoo-dev] QA Roles v2
3.3.2006, 22:51:39, Mike Frysinger wrote: On Friday 03 March 2006 15:47, Jakub Moc wrote: Please, until something is clarified/some consent reached, avoid changing the docs w/ funny stuff like just flip a coin... please, get a sense of humor, kthxbye -mike Sorry, I don't find anything particularly humorous w/ such suggestions finding their path into documents that you are trying to enforce as a QA policy. -- jakub pgpXKbPmW8sgG.pgp Description: PGP signature
Re[2]: [gentoo-dev] QA Roles v2
3.3.2006, 22:54:25, Grant Goodyear wrote: http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/proj/en/devrel/handbook/hb-guide-ebuild.xml?root=gentoor1=1.31r2=1.32 What's the above again? QA policy? How does user benefit from flipping a coin wrt choosing a functionality? Sigh... :/ It prevents emerge from crashing out in the middle of what could be a quite extensive build. Personally, I would rather rebuild one package to get desired functionality _after_ the emerge completes than have to fix the flags for that one package to be able to build everything else. Erm, how exactly will you find out that you need to recompile that package after such extensive build? You'll spend a couple of hours debugging when your server app stops working? Yay! :P Oh please, stop making up artificial policies doing no good to users just to hack around lacking features in portage. -- jakub pgpHQqMRqRxGb.pgp Description: PGP signature
Re[2]: [gentoo-dev] QA Roles v2
3.3.2006, 23:25:13, Stephen Bennett wrote: On Fri, 3 Mar 2006 22:27:45 +0100 Jakub Moc [EMAIL PROTECTED] wrote: What kind of point does it get across, exactly? That you must choose one flag, or set of flags, to take precedence in such situations, but that how you choose is quite immaterial. If there is an obvious choice then use it, else pick one some other way. Yeah, that's a wonderful message. Let users choose, they are not idiots and such policy does more harm than good. Period. -- jakub pgp3Eck3S3o3U.pgp Description: PGP signature
Re[2]: [gentoo-dev] QA Roles v2
3.3.2006, 23:32:36, Grant Goodyear wrote: Jakub Moc wrote: Erm, how exactly will you find out that you need to recompile that package after such extensive build? You'll spend a couple of hours debugging when your server app stops working? Yay! :P I had assumed that in such a case the ebuild would output a scary-looking ewarn that notified the user of such a problem. The whole argument here is that bailing out with conflicting use flags breaks some extensive compiles. So you suppose users will be sitting in front of their monitor and stare on the screen waiting for a scary warning? No, they won't. And even if they were, how exactly is that warning better than bailing out and asking them to change the use flags? The only thing that can happen here is that users will get unexpected results and will be debugging their broken apps once that extensive compile that must not be interrupted under any circumstances is finished. Oh please, stop making up artificial policies doing no good to users just to hack around lacking features in portage. Was I so impolite that you felt the need to be rude in turn? If so, I certainly apologize, as it was not my intention. No, sorry. That comment was aimed generally at whomever is making up such policies. I'm really getting tired of this debate. Lets drop the damned paragraph that has been added recently and lets do some more important job. This simply cannot be fixed now in a reasonable way that would improve user experience, so why don't we focus on something that is doable? I don't believe that I made up this policy, although it's been around as an unofficial policy for so long that I couldn't really say one way or the other. In any event, I certainly agree that fixing portage would be preferable to policies that work around portage's warts. On the other hand, until those warts get fixed it seems useful to have a set of best practices in the meantime. I'm arguing that sudden, difficult to predict package build breakages are a bigger sin than having a package build deterministic functionality that may be unexpected by the user. You (I think) believe the opposite. Fair enough. Well, selecting features randomly is not what I believe could be a best practice. -- jakub pgplAlVlbQEm0.pgp Description: PGP signature
Re: [gentoo-dev] Official overlay support
Chris Gianelloni wrote: On Wed, 2006-03-22 at 22:03 +, Stuart Herbert wrote: To answer Daniel's other question, about bugs.g.o ... trac on overlays.g.o will have its bug tracking system disabled. We already have one bug tracking system - bugs.g.o - and that's sufficient. Umm... no? If some random developer goes out there and creates his own fork of catalyst in his overlay, I sure don't want to receive a *single* bug on it. Ever. If you're already using Trac, you should keep the bug tracking enabled, so the bugs stay with the overlay. Once something moves into the official tree, then it can use bugs.gentoo.org for its bug tracking. This means developers that don't wish to participate in the overlays are not forced to waste their time troubleshooting problems in these overlays and can focus on our *core* product, the portage tree. Well, I don't care much, as long as: - there's a separate Overlays product in bugzilla for this - each such overlay has its own component under Overlay product with default assignees set up (no, I won't check out all those overlays to find out the maintainer, also, almost none of them uses metadata.xml) - users are *vigorously* :P instructed to file the bugs under that product/component and/or (?) mark them with something like [overlay-xxx] so that I don't have to ponder who's maintaining that thing. If they don't, the bugs end up as invalid b/c the ebuild is not in portage. Easy enough. While keeping those bugs in trac bug trackers seemed as a good idea to me originally, most users are simply unable to do that anyway. We tried w/ php overlay, didn't work much. -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=getsearch=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Official overlay support
Ciaran McCreesh wrote: On Thu, 23 Mar 2006 19:31:24 +0100 Stefan Schweizer [EMAIL PROTECTED] wrote: | What about if we just skip your policies and let the overlays be a | free place where people can handle issues how they think it is right | for the specific case and not how $super_dev said somewhere. That is | what overlays are about, not? Sounds like a perfect way to break lots and lots of systems. Those policies are mostly there for good reason. You want to apply policies on overlays? Well no - sorry, overlays are none of QA's or any other policy business. They are overlays, not official tree. If user installs ebuilds from overlay and breaks his system, then well - not a Gentoo problem. Why should any policies apply? -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=getsearch=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Official overlay support
Duncan Coutts wrote: The way the Haskell team manages this is that we don't tell our end users about our testing overlay. So we don't get bug reports from them. We have three outside contributers with write access to the overlay repo. They make changes in consultation with the team. So we're not giving complete access without accountability. Hmmm, that kinda defeats the whole point of having an overlay at all, IMHO. Of course you can have an overlay strictly for internal development between a couple of people, but that's not quite what this debate is about I'd say. I find overlays really useful for testing stuff before it gets into portage - that's completely pointless if the overlay is secret. Also, you are able to find potential future devs among the overlay users, people who actually submit fixes etc. How are you going to get that if noone knows about the overlay? We have a couple other users who use the overlay but they know what they're doing. We don't make the overlay that easy to use on purpose because we don't want inexperienced users using it. So apart from not advertising it, we don't keep digests in the repo. Oh well, seems like you have a very specific use for this, probably not what most users are interested in. I think the point is that these overlays should be a useful way of getting contributers more closely involved. However we should not encourage end users to use these overlays without thinking. For example using more than one at once seems like a really bad idea. Perhaps if we make them sufficiently hard to use then end users will not use them and we'll just get the contributers we want. As said above, how are you going to get new contributors without people that are actually using/testing that stuff? -- jakub signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Official overlay support
Ciaran McCreesh wrote: On Thu, 23 Mar 2006 19:57:07 +0100 Jakub Moc [EMAIL PROTECTED] wrote: | Sounds like a perfect way to break lots and lots of systems. Those | policies are mostly there for good reason. | | You want to apply policies on overlays? Well no - sorry, overlays are | none of QA's or any other policy business. They are overlays, not | official tree. If user installs ebuilds from overlay and breaks his | system, then well - not a Gentoo problem. Why should any policies | apply? It is a Gentoo problem, because Gentoo gets innundated with bogus bug reports when users screw up their systems in weird ways and don't realise the cause. We get innundated with tons of bogus bug reports every day, overlays or not - see the number of invalid/duplicate bugs flowing every days. We got a couple of bugs in last two a three days basically stating ZOMG, glibc downgrade broke my system, t3h Gentoo bug!!11!! - so what? They get marked as invalid, live goes on. This argument really doesn't stand. As this should be a separate thread, just one reason or example - I'm really uncomfortable e.g. w/ QA intervening in overlays stuff, considering the current way QA is being done in Gentoo... Current non-interactivity policy has clearly influenced multiple ebuilds in portage to the extent that forced me to read the ebuilds very carefully multiple times to be sure what the outcome will be with my particular USE flags. This is a bad thing (TM) for me and I clearly oppose to having such stuff forced in overlays. I could see a place for QA volunteers in this overlay stuff, but that would require a fundamentally different approach from what QA takes now. (If you wish to discuss this further, move it to a separate thread, please). Common sense always applies, but generally - overlays are not a place for bureaucracy... -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=getsearch=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Official overlay support
Chris Gianelloni wrote: On Fri, 2006-03-24 at 12:46 +0100, Andres Loeh wrote: As I've said, my only request is a single policy that before an overlay can become publicly readable on overlays.gentoo.org (which is Gentoo infrastructure) that it does not break packages in the main tree that are not in the overlay. If this single policy were in place, then I would fully support overlays.gentoo.org being created. How are you going to enforce that policy? Heh, you can't do that preemptively even in the main tree. :) Every day there are bugs about package A upgrade breaking packages B, C and D. I can also create an overlay with two completely innocent ebuilds, get it opened and then keep filing it w/ ricer food like patched-to-hell toolchain stuff? How are you going to verify that ebuild X in overlay doesn't break anything in the tree? And that its next revision won't do it. You volunteer for such job? Great. Or not? Well, then there's no point in suggesting a policy that can just never work... So - what you are telling us is that you *assume* that people are going to publish ebuilds *known* to break in-portage stuff on overlays.g.o.? Weird assumption 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 ;) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Official overlay support
Ciaran McCreesh wrote: On Fri, 24 Mar 2006 10:16:15 +0100 Jakub Moc [EMAIL PROTECTED] wrote: | We get innundated with tons of bogus bug reports every day, overlays | or not - see the number of invalid/duplicate bugs flowing every days. | We got a couple of bugs in last two a three days basically stating | ZOMG, glibc downgrade broke my system, t3h Gentoo bug!!11!! - so | what? They get marked as invalid, live goes on. This argument really | doesn't stand. They get marked as invalid after how long? There're some really subtle ways in which libraries can screw things up. I've dealt with far too many bug reports where it took a heck of a lot of debugging before it became clear that the cause was some dodgy external stuff. And that was with me understanding the packages in question -- there's no way bug wranglers could've figured it out. Yeah, and the point is? It happens every day, there are already tons of third-party overlays used by Gentoo users, but once this thread about official overlays started, you came here to tell us wow, this all will cause terrible borkage and flood developers w/ tons of stupid invalid bugs, we need policies? I really don't see how overlays run mostly by Gentoo devs would cause any more borkage than totally uncontrolled third-party overlays run by whomever creates and publishes them, sorry. -- jakub signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Session/.desktop WM compatibility, DM unification
Dan Armak wrote: GDM has had just its own Xsession for a long time iirc. I think most functionality provided by these other X* files are login manager (xdm?) specific. The one real issue is Xsession. Can anyone comment regarding entrance or any other DMs? Yeah, I can comment - using e17 here. entrance (the CVS version) is broken :P and doesn't read/use any of them, you need to point it manually via ecore_config to the session file where you put all the commands you want to start. Also, its default config is broken for e17 because it points to /usr/bin/enlightenment while the actual binary is called enlightenment-0.17. Oh well, that's what you get with live cvs ebuilds. ;) The desktop files are a real mess: e17genmenu reads a couple of predefined locations automatically, otherwise you have to point it to an unexpected location manually if you want those desktop items added. Right now I have .desktop files scattered in: /usr/share/applications /usr/share/applnk/category /usr/kde/version/share/applications/kde (The last one is something I'd really like to get rid of completely.) I'm avoiding gnome apps as much as possible, but there's definitely a gnome-specific location for those as well. Benefit from this mess? Negative for me, captain. Please, standardize this. The same goes for icons locations - openoffice-bin installs png icons to /usr/share/pixmaps (?!), firefox-bin installs icons to /opt/firefox/icons, thunderbird-bin installs icons to /opt/thunderbird/icons which might seem right but allas nothing can find the icons in there and .desktop files are in /usr/share/applications anyway. There are issues w/ mime-types etc. as well, but this mail is getting long as it is, so leaving that for another one, perhaps. -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=getsearch=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: who renamed adsl-start to pppoe-start and why
Sven Köhler wrote: I don't when the init.d-script disappeared from the ebuilds, but well: i still used it and didn't know about the baselayout-support for pppoe. May I suggest reading the fine handbook? http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=4chap=3#doc_chap4 -- jakub signature.asc Description: OpenPGP digital signature
[gentoo-dev] xml2 use flag deprecation - ping (Bug 116346)
This is just a friendly reminder that Bug 116346 doesn't seem to be moving much. :P The two months old list seems still almost fully valid. http://bugs.gentoo.org/attachment.cgi?id=79178action=view Do we manage to kill the flag? Always good to have one redundant flag less... ;) Thanks. -- jakub signature.asc Description: OpenPGP digital signature
[gentoo-dev] gtk2 use flag must die
This is a (not-so happy) reminder that the agony of gtk2 use flag will have been lasting for half a year soon. It *really* needs to die. For affected ebuilds, please see the attached list and Bug 106560. Thanks. -- jakub app-crypt/pinentry-0.7.2 app-editors/mp-3.3.12 app-editors/mp-3.3.14 app-emulation/fuse-0.6.2.1 app-emulation/fuse-0.7.0 app-i18n/poedit-1.2.3 app-i18n/poedit-1.2.4 app-i18n/poedit-1.2.5 app-i18n/poedit-1.3.0 app-i18n/poedit-1.3.1 app-i18n/poedit-1.3.2 app-pda/jpilot-0.99.7-r1 app-pda/jpilot-0.99.8 app-pda/jpilot-0.99.8_pre9 app-pda/jpilot-backup-0.50 app-pda/jpilot-plucker-0.01 app-pda/jpilot-syncmal-0.72.1 dev-python/wxpython-2.4.2.4 dev-python/wxpython-2.4.2.4-r3 dev-python/wxpython-2.6.0.0-r1 dev-python/wxpython-2.6.1.0 dev-ruby/wxruby-0.6-r1 dev-scheme/bigloo-lib-0.17 media-gfx/xsane-0.97 media-gfx/zphoto-1.2-r1 media-libs/blib-1.1.7 media-sound/audacity-1.2.3-r1 media-sound/aumix-2.8-r2 media-sound/gamix-1.99_p14-r1 media-sound/timidity++-2.13.2-r2 media-video/blinkensim-2.7 media-video/ogle-gui-0.9.2 media-video/vlc-0.8.1-r1 net-ftp/gftp-2.0.18-r1 net-p2p/xmule-1.10.0 net-p2p/xmule-1.10.1 net-p2p/xmule-1.8.4-r1 sci-chemistry/chemtool-1.6.4 sci-chemistry/chemtool-1.6.6 sci-chemistry/chemtool-1.6.7 x11-libs/gtk-server-2.0.5 x11-libs/wxGTK-2.4.2-r2 x11-libs/wxGTK-2.4.2-r3 x11-libs/wxGTK-2.4.2-r4 x11-libs/wxGTK-2.5.3 x11-libs/wxGTK-2.6.0-r1 x11-libs/wxGTK-2.6.1 x11-libs/wxGTK-2.6.1-r1 x11-misc/linuxwacom-0.6.7 x11-misc/linuxwacom-0.6.8 x11-misc/linuxwacom-0.6.9 x11-misc/linuxwacom-0.7.2 x11-misc/macopix-1.0.4 x11-misc/macopix-1.2.1 x11-plugins/i8krellm-2.3 x11-plugins/i8krellm-2.5 x11-themes/gtk-engines-qtpixmap-0.28-r1 x11-wm/aewm-1.2.3 x11-wm/fvwm-2.5.12 x11-wm/fvwm-2.5.13-r1 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] gtk2 use flag must die
Mike Frysinger wrote: and if there are no bugs filed ? this sort of stance is like the lets remove packages from portage because upstream is dead ... it benefits no one No bugs filed? Well, just search the archives of this ML, and search bugzilla for all those bugs about portage pulling in gtk2 when users had USE=-gtk2 set, or for all bugs about the confusion what USE=gtk -gtk2 or USE=-gtk gtk2 actually means... Please, remove the gtk2 flag from ebuilds you maintain. Thanks. no -mike Shrug... Maybe speak up sooner next time, this debate has been over for a long time and the decision was clearly to deprecate gtk2 use flag. Not going to do that? Shrug, oh well, perhaps QA will then, or not - I don't care if you are going to confuse users. That bug is set as a blocker for Gnome 2.14 release. My email was intended to speed up closing that bug, not to start such debate again. So - that's all from me. -- jakub signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] gtk2 use flag must die
Mike Frysinger wrote: On Sunday 02 April 2006 15:34, Jakub Moc wrote: Mike Frysinger wrote: and if there are no bugs filed ? this sort of stance is like the lets remove packages from portage because upstream is dead ... it benefits no one No bugs filed? Well, just search the archives of this ML, and search bugzilla for all those bugs about portage pulling in gtk2 when users had USE=-gtk2 set, or for all bugs about the confusion what USE=gtk -gtk2 or USE=-gtk gtk2 actually means... unrelated i'm talking about buts in the packages themselves, not end user confusion -mike Not really, since the retarded handling of those use flags combos in ebuilds has been one of the key reasons to deprecate this. Also, this is rather funny why xml2 use flags needs to be removed (it was you who suggested that) - yet you resist to get rid of gtk2 use flag, which is *way* more confusing (heck, look at that old wxGTK stuff, it's nasty and confusing like hell). I'd like to note that all bugs complaining about gtk2 getting pulled in with USE=-gtk2 as being marked as dupe of that deprecation bug, not really sure how are you going to explain to the users that there are exceptions to this rule. -- jakub signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [last rites] media-gfx/sodipodi
Carsten Lohrke wrote: I don't see the necessity for devs and users would have to look at the package.mask file regularly to get the information that a package is masked. If Portage would be that smart to spit out the relevant information on emerge --sync, a longer period would probably make sense. Not that I'd care so much whether it's a week or a month (IMO individual depending on ebuild in question) - so just a technical note. Portage 2.1 *does* spit out the relevant info. # emerge -uDpv world These are the packages that would be merged, in order: Calculating world dependencies / !!! Packages for the following atoms are either all !!! masked or don't exist: net-ftp/glftpd ... done! # esearch glftpd [ Results for search key : glftpd ] [ Applications found : 1 ] * net-ftp/glftpd [ Masked ] Latest version available: 2.01 Latest version installed: 1.32 -- jakub signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Improving Gentoo User Relations
Donnie Berkholz wrote: Christopher O'Neill wrote: . I notice certain other popular distros are now running GCC4 (and have been for some time), yet we are still running 3.4.6 (on ~x86). I know it's a lot of work ensuring that all packages compile properly with GCC4 and that there are no introduced bugs, but I have no idea how we are progressing on this - and wouldn't even like to ask for fear of asking in the wrong place.. Toolchain updates in particular take longer than with most distros, because of the nature of ours -- we need every user to be able to compile every keyworded package from source, and we have an extremely large package database. I bet there's a bug open for it. http://bugs.gentoo.org/show_bug.cgi?id=117482 . How's portage 2.1 getting along? I notice it gets frequent updates. The gentoo-portage-dev list is the place to follow this. Also, http://bugs.gentoo.org/show_bug.cgi?id=115839 -- jakub signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Gentoo theming during bootup
Carsten Lohrke wrote: On Saturday 08 April 2006 00:52, Mike Frysinger wrote: highly suspect statements these states are all quite common ... trying to make some kind of supposition as to which is the most common is a waste of time No. It's my opinion. Respect it, please. You don't have to agree. My opinion is that *must* be the default theme everywhere in Gentoo: http://gentoo-wiki.com/images/6/63/Gnome-jamapii.2006-04.jpg If not, I'll get pretty angry, so you'd better start fixing KDE/Gnome/boosplash/grub etc. soon! :P -- jakub signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: automatically killing invalid CFLAGS/warning about bad CFLAGS
Harald van Dijk wrote: On Thu, Apr 13, 2006 at 09:39:28PM -0600, R Hill wrote: Donnie Berkholz wrote: R Hill wrote: There's an endless number of CFLAGS that could be warned about, and just as many situations where they're actually useful. Aside, I've yet to hear of _anything_ that's broken because of -fvisibility-inlines-hidden. (course someone will undoubtedly point one out now ;)) How about kde? Close, that's -fvisibility=hidden. :) http://gcc.gnu.org/gcc-4.0/changes.html#visibility --de. kdevelop used to not compile with -fvisibility-inlines-hidden, not sure if that's changed now. Sure enough it's changed - kde.eclass now filters all this visibility crap (-fvisibility=hidden *and* -fvisibility-inlines-hidden) by default because it bombs out really badly... :) http://groups.google.de/group/linux.gentoo.dev/browse_frm/thread/f43fac917352bb51/5093e84871f08de6?lnk=st More fun: https://bugs.kde.org/show_bug.cgi?id=109386 http://planet.gentoo.org/developers/flameeyes/2005/11/16/happy_the_visibility_stuff_goes_away http://planet.gentoo.org/developers/flameeyes/2005/10/06/ehi_i_m_invisible -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=getsearch=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) signature.asc Description: OpenPGP digital signature
[gentoo-dev] Purpose of USE=doc
Hello here, I'd like to see some clarification of intended doc use flag usage, so that we wouldn't force users to download/install 40+ megs of docs for a ~3 meg package, with the only reason being that USE=doc is for developer documentation only. [1] And no, I don't think we need yet another use flag. ;) FEATURES=nodoc is also not exactly useful as it's forcing users to download stuff they are not interested in at all. (To make it more clear, I'm talking about ebuilds that download docs in a separate tarball here.) TIA for ideas. [1] http://bugs.gentoo.org/show_bug.cgi?id=122265 -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=getsearch=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] coldplug and hotplug
Roy Marples wrote:
RC_HOTPLUG=yes|no
RC_COLDPLUG=yes|no
RC_PLUG_SERVICES=net.wlan !net.*
or
RC_HOTPLUG=yes|no|net.wlan !net.*
RC_COLDPLUG=yes|no|net.wlan !net.*
I'm afraid I don't get the exact difference :P, but what about honoring
both yes|no and list of services.
Anyway, what we really need is ability to turn off that coldplug thing
*completely* on *udev* level and restore some sanity. I really don't
need to have my TV card coldplugged at the point when /dev is being
populated by devices (e.g., Bug 130766 or Bug 128962).
Also I'd like to note that coldplugging network devices in such way may
be a security risk as well, as firewall gets started much later than net
gets started. There's Bug 119613 about this. There was also Bug 78495
about this, got solved on hotplug level, but the latest udev versions
moved the problem to coldplug level instead (even worse IMHO).
Last point - there's also that hotplug_$iface=no thing in
/etc/conf.d/net - wouldn't it be better to all keep network-related
settings in one place? I.e., adding coldplug_$iface=yes|no there
instead, and use RC_{HOTPLUG,COLDPLUG} in /etc/conf.d/rc for other
services only?
--
Best regards,
Jakub Moc
mailto:[EMAIL PROTECTED]
GPG signature:
http://subkeys.pgp.net:11371/pks/lookup?op=getsearch=0xCEBA3D9E
Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E
... still no signature ;)
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] coldplug and hotplug
Roy Marples wrote:
Anyway, what we really need is ability to turn off that coldplug thing
*completely* on *udev* level and restore some sanity. I really don't
need to have my TV card coldplugged at the point when /dev is being
populated by devices (e.g., Bug 130766 or Bug 128962).
Not going to help 128962 as the firewire module is already loaded and has
taken eth0
Well, it should not be loaded first of all... Hence why I want to have
an ability to turn off the coldplug thing *completely* on udev level. I
don't have any use for such automagic stuff, it just complicates things
instead of making them easier. Blacklisting every single module that
gets coldplugged for whatever weird reason is not a sane way to work
around a problem that doesn't need to exist in the first place. Also,
it's not really clear what determines whether something gets coldplugged
or not. As said, the devices range from TV cards over NICs to USB
sticks... Uh. :/
Also I'd like to note that coldplugging network devices in such way may
be a security risk as well, as firewall gets started much later than net
gets started. There's Bug 119613 about this. There was also Bug 78495
about this, got solved on hotplug level, but the latest udev versions
moved the problem to coldplug level instead (even worse IMHO).
Add your firewall script to the boot runlevel and depend like so
depend() {
before net
}
Solved!
iptables already has before net, doesn't exactly help. Well, I don't
need net on boot level first of all and I didn't set it to be launched
at that runlevel. The runlevel setting gets ignored, however.
hotplug_$iface was a fudge, a very bad idea that has been removed baelayout.
If baselayout is to have any hotplug/coldplug control it should be on a
service level and not just a network level.
Well yeah, as noted above, we are just probably solving the thing in a
wrong place to work around udev problem.
--
jakub
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] coldplug and hotplug
Roy Marples wrote: iptables already has before net, doesn't exactly help. Well, I don't need net on boot level first of all and I didn't set it to be launched at that runlevel. The runlevel setting gets ignored, however. Hmmm, maybe you don't understand then :) If coldplug adds net services to the boot runlevel then the firewall script needs to be in the boot runlevel. I do understand, however ignoring runlevels settings is in itself a coldplug bug. :) -- jakub signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Re: When will KDE 3.5 be marked as stable?
Philip Webb wrote: But yeah, you know better, no problems whatsoever. :P Yes, I know better: I haven't had any problems with any of the KDE packages which I have installed with versions 3.5.0 3.5.1 3.5.2 . It's time the developers started listening to users in this area: we really do appreciate your volunteer work, but without users that work would all be pointless. It's been explained many times that the fact that *you* didn't have any problems whatsoever is completely *irrelevant*, at least until *you* are the only Gentoo KDE user. Please, read what other people have said and don't waste our time with completely invalid arguments. -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=getsearch=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Re: Re: When will KDE 3.5 be marked as stable?
Philip Webb wrote: Any stable version of KDE will need kdelibs kdebase , but otherwise why can't the packages be made stable at least as each big downloadable file becomes ready, if not individually ? Because they have to be stable at once. Period. Can't go stable piece by piece. Period. Can't. Period. Again, you're simply repeating yourself without any attempt to explain. Can anyone else offer an explanation for the claim that all KDE packages (for one version) have to be stabilised together ? Look - every such mail defers stabilizing KDE, it's getting really annoying. No, they can't and won't be stabilized on a piece-by-piece basis, that would result in failed dependencies and compilation failures. Period, no need to discuss this. This has never been done, can't be done now and won't be done in future. The whole KDE shebang needs to go stable at once, together with many other non-KDE ebuilds that it depends on. So please, stop wasting limited time of limited number of Gentoo KDE maintainers by beating a dead horse. 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 ;) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] et_EE locale and language of error messages
Harald van Dijk wrote: is a feature, not a bug. It can indeed be a problem in bugreports, but it's a much milder one, since it's trivial to look up what any particular message is translated from. Well no, I completely disagree. Error output in $random language makes searching for duplicate bugs very difficult/impossible, also doesn't make fixing the bugs any easier When people report bugs, they need to report the errors in English. We also don't allow bugs to be filed in $random language, I don't see why error messages should be an exception. Feel free to write a translation tool for error messages, until then this is a no go... ;) -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=getsearch=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Re: Gentoo Devmanual
Stephen Bennett wrote: Two names are credited on the front page. One is conspicuously absent, despite having done the vast majority of the original work. snip Large portions of the handbook were originally written by Ciaran McCreesh. /snip Maybe you need to read more carefully, or need better spectacles? Ah, we just didn't have a pointless flamewar for a long time, right... :S -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=getsearch=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) signature.asc Description: OpenPGP digital signature
[gentoo-dev] no need to CONFIG_PROTECT /usr/kde/2/share/config
Please, finally kill this thing from CONFIG_PROTECT in base/make.defaults, we are not Debian... :P 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 ;) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC Maintainer-Wanted Bugs/Cleaning]
Mark Loeser wrote: Yea, the current situation has quickly turned into a mess. I definately think that QA should definately be watching maintainer-wanted/maintainer-needed and helping clean up new ebuilds, or removing old unmaintained packages that no one cares about anymore. A bugzilla feature to automatically close bugs these bugs after a set period of inactivity would certainly help. Dunno if it's possible, though. :) Otherwise, some review used to be done, but there's been a negative opinion about closing bugs w/ sucky broken ebuilds as WONTFIX/CANTFIX expressed by some of the devs; as it stands now - it's basically impossible to reasonably track the bugs unless it can be sorted by status and users reopen the bugs when they think they've fixed the outstanding issues... Finally - I'd suggest marking all ebuild *requests* as CANTFIX or NEEDINFO or whatever you think would be best resolution, there's tons of bugs w/ ebuilds submitted that can't find a maintainer. If you want something in portage, do you homework at least and attempt an ebuild. Just my $0.02... -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=getsearch=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC Maintainer-Wanted Bugs/Cleaning]
Robin H. Johnson wrote: Could we establish policies for closing them or leaving them to sit open? - Upstream dead, previously submitted URLs no longer functional (yes, there are actually some like this!). - No ebuild included. - Upstream says obsolete in favour of another package. - Dev notes obsolete in favour of another package - suggest it to the submitter, and see what they say. - Major unresolved security issues. - Excessive complexity / unsuitable for ebuild installs (eg apps that are meant to be built and run from the same directory). More or less what I've been doing for past few months... Today, I've also closed all ebuild requests 1+ year old w/ zero activity as CANTFIX, asking the reporter to attach an ebuild. Bugs like I'd like to see foo/bar in portage, ktnxbye don't need to sit in bugzilla for ages if noone is interested, not really useful. (And - as mentioned before, some automation of the process would be nice ;) At the same time, existing developers and teams should be encouraged to look at those under maintainer-wanted, and consider stuff there. I try to keep an eye out for app-backup and other fields that I'm involved in. Also, please really close useless cruft when you come across it (see above). -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=getsearch=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) signature.asc Description: OpenPGP digital signature
[gentoo-dev] [useflag] firefox : build against firefox instead of mozilla
While at it: 16 apps w/ firefox local use flag: local use flags (searching: firefox) [+ C ] firefox (app-office/openoffice): Build against Firefox instead of Mozilla [+ C ] firefox (dev-haskell/gtk2hs): Build the Mozilla Embeded Component against firefox rather than mozilla [+ C ] firefox (dev-java/swt): Build the Mozilla Embeded Component against firefox rather than mozilla [+ C ] firefox (dev-python/gnome-python-extras): allow building against firefox libs [+ C ] firefox (dev-ruby/ruby-gtkmozembed): compile against Firefox instead of Mozilla [+ C ] firefox (dev-util/devhelp): Build against firefox rather than mozilla [+ C ] firefox (dev-util/eclipse-sdk): Build against firefox rather than mozilla [+ C ] firefox (gnome-extra/evolution-data-server): Use Firefox's NSS/NSPR libraries if SSL is enabled [+ C ] firefox (gnome-extra/yelp): Build against firefox instead of mozilla [+ C ] firefox (mail-client/evolution): Use Firefox's NSS/NSPR libraries if SSL is enabled [+ C ] firefox (net-news/liferea): Build against Firefox instead of Mozilla [+ C ] firefox (www-client/epiphany-extensions): build against firefox instead of mozilla [+ C ] firefox (www-client/epiphany): build against firefox instead of mozilla [+ C ] firefox (www-client/galeon): build against firefox instead of mozilla [+ C ] firefox (www-client/kazehakase-cvs): Use firefox's Gecko engine. [+ C ] firefox (www-client/kazehakase): Use firefox's Gecko engine. See http://bugs.gentoo.org/show_bug.cgi?id=96473 as well. -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=getsearch=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Need a use-expanded TV_GRAB variable for xmltv
Simon Stelling wrote: You forgot to mention which package uses the variable. Re: [gentoo-dev] Need a use-expanded TV_GRAB variable for xmltv ;) -- jakub signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Need a use-expanded TV_GRAB variable for xmltv
Matteo Azzali wrote: Repoman considers lots of local variables as an error, I was pointed to expanded vars as a solution. If no developers has something against I'll be happy to use 28 local flags mattepiu Well uh, no please Don't create 28 local use flags for one ebuild, use.local.desc is cluttered enough as it is... :) Otherwise, I'd say you've misunderstood the repoman output, you probably didn't put them into use.local.desc when testing your local stuff. -- jakub signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] virtual/x11-7* hides real bugs and breaks good ebuilds
@4u wrote: After posting and closing the bug report: http://bugs.gentoo.org/show_bug.cgi?id=135870 Jakub Moc noticed that the current =virtual/x11-7.0 ebuild misses its task and creates trouble. Indeed. To re-iterate here, I'll basically re-paste what I've said on the bug, so that people don't have to jump to bugs.g.o.: =virtual/x11-7 is hiding breakage in ebuilds that are not ported for modular X. The side effect is that dependencies like X? ( || ( foo bar baz ) virtual/x11 ) fail once virtual/x11 gets emerged by one of those broken ebuilds, because the dependency is already satisfied by virtual/x11. If that virtual doesn't depend on either of foo bar baz, then the dependency doesn't get emerged and a perfectly valid ebuild without any missing dependencies fails. For example: This ebuild behaves partly like a ordinary meta build and installs imake. You need imake (more correctly xmfmk) to install tightvnc. Yeah, as it is now, it's essentially a dumpspace for redundant dependencies that are already stated in ebuilds fixed for modular X, but that frequently don't get installed b/c of the problem described above. We are mis-using a 'new style' virtual to produce yet another metabuild that serves the only purpose - to hide borkage. For that reason I want to request the deletion of virtual/x11-7.0 and that at least some dependencies of virtual/x11 are moved to =x11-base/xorg-x11-7.0 where these dependencies belong to IMHO. xorg-x11 is a meta ebuild. Each ebuild should state its own dependencies. x11-base/xorg-x11 is a metabuild for users' convenience, which should produce a pretty full-featured X server install, but nothing more. It's not a dumpspace for whatever redundant dependencies either. So - IMHO we should stop shoving the real breakage under the carpet, if ebuilds are not ported for modular X, they are broken and should be fixed. If noone cares to fix them enough for some time, they'll probably need to be package.masked and subsequently removed from the tree. Until then, they'll bomb out, because they are broken, that's a perfectly expected behaviour... What we are instead doing now, is hiding the breakage by misusing virtual/x11-7 to emerge most frequently missing deps, which is bloating more and more, as more and more not broken ebuilds are hit by the redundant virtual. Not good, really. Some examples of needless borkage include: http://bugs.gentoo.org/show_bug.cgi?id=123071 http://bugs.gentoo.org/show_bug.cgi?id=127617 http://bugs.gentoo.org/show_bug.cgi?id=128163 http://bugs.gentoo.org/show_bug.cgi?id=128353 http://bugs.gentoo.org/show_bug.cgi?id=128354 (plus numerous duplicates). While the above bugs are marked fixed, they won't be really fixed until =virtual/x11-7 goes to /dev/null and stops causing more harm than good. Sorry for a long post, but this problem really needs to be addressed. -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=getsearch=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] virtual/x11-7* hides real bugs and breaks good ebuilds
Arek (James Potts) wrote: Donnie Berkholz wrote: =virtual/x11-7 is hiding breakage in ebuilds that are not ported for modular X. I couldn't agree more, but I was forced to add this rather than allow unported ebuilds to break. Hmmm...Looks to me like it would be a great idea to fix the unported ebuilds. Would it be possible to mark virtual/x11-7 as deprecated (using enotice/ewarn or similar), in order to get people to port any build relying on it to modular X? The way I see it, once virtual/x11-7 has been deprecated for a while (6 months to a year) and most popular packages have been ported to modular X, virtual/x11-7 and any packages still relying on it could be given Last Rites. Hmm, I don't think so... There's been a plenty of time to do this when modular X has been package.masked, the remaining unported stuff didn't get much further even after it's been unmasked. There's been a (debatable) repoman check, which has been too annoying so devs nuked it for themselves, now it's non-fatal warning again (which is mostly being ignored). S - I'd pretty much say until the real breakage is *visible* and users start to scream - not much will change. Making it visible could also help us differentiate between used and used stuff. If there's something unported and you get no bug, then probably noone uses the thing, nothing depends on it and it can be punted from the tree. On a side note, this virtual also hides potential bugs in ebuilds that already have been ported, you can miss dependencies there if you have already them emerged b/c of the virtual. -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=getsearch=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] virtual/x11-7* hides real bugs and breaks good ebuilds
Olivier Crete wrote: Is there a recent list of non-ported packages ? Maybe we should do a last effort to port everything for a week or two and then package.mask the packages that no one cares enough about to port them. Hmmm, not a up2date one, AFAIK... There's a tracker bug http://bugs.gentoo.org/show_bug.cgi?id=112675 and below is the most recent list from spyderous I was able to find (no idea how much relevant it still is). http://dev.gentoo.org/~spyderous/broken_modular/broken_modular.txt.20060315 -- jakub signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Project Sunrise thread -- a try of clarification
Patrick Lauer wrote: On Thu, 2006-06-08 at 20:06 -0400, Chris Gianelloni wrote: Again, read what I wrote. I said that the developer would see sunrise in the PORTDIR_OVERLAY of the user's emerge --info, which you reiterated without considering. This is a login bug. At no point did they make mention of having installed pam_skey from this overlay. This means that I, as the developer getting this bug, am now responsible for looking at *every package* in the sunrise overlay to determine if *any* of them could *possibly* be affecting this package or causing this bug, then asking the user if they have any of them installed. This differs from a manually patched ebuild in /usr/portage by virtue of showing you that an overlay is used ... Wouldn't this process be *infinitely* easier if instead of sunrise there was a pam overlay with *only* the pam stuff? Ooooh, cool. Now I need about 75 overlays to get things done, and of course there will be no bad interaction between them ;-) Please, leave pam_skey alone. ;) It's a thing I'm using daily and the default system-auth config file installed by this ebuild allows for both system and S/KEY passwords to be used at the same time, you can pick whichever one you want. There's no way to get yourself locked out of system unless you've already forgotten your normal password and didn't yet set up OTP, in which case, it's not pam_skey problem at all. The thing has been sitting in bugzilla for ages, I've asked Flameeyes to commit it and he said he's not going to put any mode pam stuff into the tree unless he's using the modules himself. Nothing wrong w/ that. So, I can either keep on maintaining it in my local overlay or let other people use it if they find it useful. I prefer the latter. pam_abl and pam_mount is also stuff that I'm testing/using myself. The only thing I haven't tested beyond it compiles and installs is pam_pgsql, that one doesn't touch system-auth at all, comes w/ commented-out .conf and so has no effect until the user has configured it. There are about 3 other bugs requesting pam stuff, but since that stuff is essentially dead upstream, it won't be in the overlay. So, are you asking to have a separate overlay project for 4 pam ebuilds? Heh, really an overkill. Could be part of the policy to not touch existing ebuilds. IMHO the sunrice project is a good place for maintainer-wanted/needed bugs. Shouldn't be a dumpspace for whatever experimental patches for stuff that's actually being maintained in the main tree. This is a prime example of totally glossing over any discussion to make it sound promising for you. If bugzilla wasn't so sucky people wouldn't try to use other methods of communication ;-) Erm, look at the vmware-server bug (http://bugs.gentoo.org/show_bug.cgi?id=122500) . It's vastly useless for grabbing any ebuilds, there are ~350 comments and tons of obsolete, yet not marked as such ebuilds, that's why you switched to subversion, right? And it boosted the effectivity by a huge margin. Also comes w/ a nice side-effect of not bugspamming another 200 folks CCed on the bug when someone screws w/ attachments for a couple of times. -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=getsearch=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Project Sunrise thread -- a try of clarification
Edward Catmur wrote: On Fri, 2006-06-09 at 10:28 +0200, Patrick Lauer wrote: Instead of a simple cvs up; cd /usr/local/portage/category/package I need to search for ALL bugs with $name in it, look which one it is, curse bugzilla for falling asleep again, see which attachments are relevant, download them, curse bugzilla for falling asleep again, copy them to my overlay, read the bugcomments to see if any special renaming or directory structure is needed ... Hmmm. I think an overlay does have some advantages there ... Advantages? With bugzilla I: search for the bug, cc myself on it, download the relevant files, look over them, note a style error, try to merge it, fix a compilation bug, re-upload the fixed ebuild and patch to bugzilla with a comment to the ebuild author on their mistake. When an update hits my inbox I can go directly to the bug... Hmmm, I mostly notice a different scenario: - search for the bug, and file a dupe because you didn't find it :P - bug gets marked as a dupe - the guy who filed the dupe comments on how much bugzilla search sucks - download one of obsolete broken ebuilds attached to the bug - moan that it doesn't work - download another ebuild - moan that it doesn't work either - someone points to comment #27 that says you need to edit lines XX and YY for the ebuild to work - do it, post yet another redundant yay, that finally worked! comment - attach a fixed ebuild tarball - you get scream upon to not attach tarballs - you attach a plaintext ebuild now - notice that its MIME type is application/octet-stream - change the mime type - look at the ebuild in the browser now that you can and notice bunch of stupid typos you've done that ruin the whole fix (hello, Mr. Murphy) - try to edit the attachment in bugzilla, which produces one huge nonsense comment instead of actually editing the ebuild - attach a new one - oh noes, it's octet-stream again! argh! - fix it... - forgot to mark previous one as obsolete, do it now - produce sorry for the noise comment - someone notices that you've still left two typos there and attaches yet another ebuild By now, about 15 bugspams times the number of people CCed on the bug got sent, containing mostly useless crap. With an overlay: search sunrice.gentoo.org for the package (no, I don't know category/name), sync that directory (no, I'm not syncing the whole sunrice tree), check it over, note some mistakes, compile it if I feel OK with it, it fails, I fix it - and what then? Where do I discuss the problems? How do I get my fixes to other users, considering the package is devless and the b.g.o bug is out of date? If I open a b.g.o bug, will it be read? This seems like *raising* the barrier to entry to me... Yes, with an overlay you can prevent all the attachment screwups noted above and once you are really satisfied that it works, you post a link to bugzilla. You can fix your typos in VCS, even multiple times, without bugspamming the hell out of people, and you still have the history to go back if you screw up. Bugs with tens of attachments are essentially useless for most of newcomers and suck for effective development as well. A couple of examples: http://bugs.gentoo.org/show_bug.cgi?id=24247 http://bugs.gentoo.org/show_bug.cgi?id=70161 http://bugs.gentoo.org/show_bug.cgi?id=122500 -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=getsearch=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Project Sunrise thread -- a try of clarification
Peper wrote: well. A couple of examples: http://bugs.gentoo.org/show_bug.cgi?id=122500 And again, you use my project of an example. Perhaps you should try looking at something that actually supports your argument? I think it's an example of how user-friendly is bugzilla... Yeah, exactly... I don't understand where did this idea of me using someone else's own project against himself came from in the first place. *confused* I've merely posted a few examples illustrating that bugzilla and attachments suck big time for new ebuilds' development. Or, why did you switch vmware-server work to SVN if bugzilla is *the* place for all this? Apparently it's not all that great, otherwise you wouldn't have done that. -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=getsearch=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Dealing with /var/cache on unmerge
Daniel Drake wrote: Mike Frysinger wrote: maybe give ebuilds a way to maintain a list of files that portage should nuke when unmerging the package ... Something similar to this would be useful for kernel ebuilds, as simply unmerging kernel source will leave a load of temporary and object files on the filesystem. Daniel Already been there and got removed, because it broke emerge -e world for ebuilds that need configured kernel to compile. -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=getsearch=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] virtual/x11-7* hides real bugs and breaks good ebuilds
Donnie Berkholz wrote: Jakub Moc wrote: Olivier Crete wrote: Is there a recent list of non-ported packages ? Maybe we should do a last effort to port everything for a week or two and then package.mask the packages that no one cares enough about to port them. Hmmm, not a up2date one, AFAIK... There's a tracker bug http://bugs.gentoo.org/show_bug.cgi?id=112675 and below is the most recent list from spyderous I was able to find (no idea how much relevant it still is). http://dev.gentoo.org/~spyderous/broken_modular/broken_modular.txt.20060315 I can probably generate one tonight. Need to dig up the scripts, and I've got an emerge -e world running in the background. Thanks, Donnie Donnie, pingy! ;) Just a friendly reminder to run the script again, so that we can do a last attempt on fixing the remaining stuff before resorting to more drastic solutions... 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 ;) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Project Sunrise -- Proposal
Henrik Brix Andersen wrote: On Sat, Jun 10, 2006 at 01:37:15PM +0200, Markus Ullmann wrote: Okay, so after figuring out open problems (thanks to kloeri and various other people for help here), we now have a resolution that should satisfy all involved parties here. This should adress dostrow's demands as well. While I do think this proposal is much better than the previous non-existing proposal, it still doesn't address the problem of having the sunrise overlay hosted on a non *.gentoo.org address to make it 100% clear to the public that it is unsupported. Regards, Brix So, move it to this.is.unsupported.and.will.blow.your.box.gentoo.org if you feel it will help anybody. I feel it's completely irrelevant, but that's just me. -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=getsearch=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] A heretical thought? Blessing project sunrise as an almost-fork.
Ned Ludd wrote: On Tue, 2006-06-13 at 18:26 +0200, Henrik Brix Andersen wrote: I have a problem with it being an official project hosted on *.gentoo.org, as I fear most users will think hey, it's official, it's hosted on *.gentoo.org - it can't be that bad. Judging from the few users who have posted to the previous threads on this subject, my fear seems to be reasonable. If the project was to be hosted on a non *.gentoo.org domain (I'll let infra comment on whether or not non *.gentoo.org domains can be hosted on infra hardware) my current issues with this project would be gone. Would moving it from overlays.g.o to overlays.dev.g.o, overlays.experimental.dev.g.o help ? It could then be viewed officially unofficial as the tinderboxing repository's I've been working on. I like the idea, helps to differentiate a bit. Though - frankly said I don't really understand what's this paranoia about. You don't have control over users' systems. There are tons of overlays users are using daily [1] - but obviously according to some people the one like Sunrise must definitely be the worst overlay ever, which will just make users boxes massively explode in smoke, kill Gentoo, all its reputation and half of the near universe. The main reason being that it's been hosted on overlays.gentoo.org and hence it's obviously official and we must guarantee that it will be 130% working and won't bring a single bad byte on users' boxes, otherwise - whee kabm, the end of the world! [1] http://gentoo-wiki.com/TIP_Overlays Personally I know I would like to have a place to park pic, iconv, nls patches in testing, and embedded-kernels that are say vital for some devices but for one reason or another should not be in the official tree. Erm, better host it somewhere else, you'll save yourself trouble and it will be more effective. If the project proves to be healthy and not affect the reputation of Gentoo in a bad way, we could consider adopting it as an official project after a period of time. Or not? Shrug... The question is whether the maintainers will be interested in becoming an official project or if they'll just choose to save themselves the trouble. Getting tired of this thread, really. Talk about too much ado for nothing. So, how about we stop wasting time, let people who are interested to do something do it, and the rest of us can focus on more important stuff than endless debates on mailing list and bothering Gentoo Council - such as fixing current bugs and cleaning the dead cruft in the tree, or fixing things not yet ported for modular X, or unported for gcc-4.x, or whatever else? Mailing list threads that don't fix one screen resolution suck, you can expect another funding request from blubb any time soon, it seems. :P -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=getsearch=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: A heretical thought? Blessing project sunrise as an almost-fork.
Chris Gianelloni wrote: Again, you are confusing herds and projects. Here's another example of it done correctly. If you add a game to the tree, the herd should be listed as games. Period. Even if you are going to be the sole maintainer of the package, games should be the herd. Why? Because it is a game, silly. There are quite a few packages under games-* that are completely maintained by someone not on the games team, which means it is not maintained by the games project. That doesn't change the fact that it is a game, and belongs in the games herd. Herd == grouping of packages Project == team of people This new terminology plain sucks. If you are sticking games into herd in metadata.xml, you are just confusing me and other people who are assigning bugs. You'll get mis-assigned bugs. Either don't do it or find another tag and get the DTD updated. herd is being used for assigning bugs, you are using it as a placeholder for something else. Category already tells us that it's a game, don't stick games into herd unless you actually maintain it. 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 ;) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: A heretical thought? Blessing project sunrise as an almost-fork.
Stephen Bennett wrote: On Wed, 14 Jun 2006 20:01:04 +0200 Jakub Moc [EMAIL PROTECTED] wrote: This new terminology plain sucks. If you are sticking games into herd in metadata.xml, you are just confusing me and other people who are assigning bugs. It's not new. If it confuses you, perhaps you should learn the terminology used in metadata before you try to assign bugs based upon it. Sure... so, perhaps you have some suggestion how I can read assign bugs otherwise than using the metadata.xml; perhaps I could learn to read minds of the developers who dump irrelevant stuff into metadata.xml and expect someone to know what they meant. Meanwhile, I can just tell you that quite a bunch of people will actually get pretty angry once you start to apply this new on not-so-new terminology on stuff placed under their herd/project/whatever and will be dumping stuff on them... Like, perl, apache or php for starters. Because, they will get the bugs assigned, and they won't like it. And, we yet lack another method of assigning bugs other than using metadata.xml for this. -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=getsearch=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: A heretical thought? Blessing project sunrise as an almost-fork.
Stephen Bennett wrote: On Wed, 14 Jun 2006 20:21:42 +0200 Jakub Moc [EMAIL PROTECTED] wrote: Sure... so, perhaps you have some suggestion how I can read assign bugs otherwise than using the metadata.xml; perhaps I could learn to read minds of the developers who dump irrelevant stuff into metadata.xml and expect someone to know what they meant. It's not irrelevant; you're just not reading it properly. You might notice that metadata.xml contains tags other than herd, like, say, maintainer. In the example that sparked this, herd is games and maintainer the individual dev who maintains it. Simple enough, no? Please, go through the tree and see at least so many metadata.xml files as I have seen, before claiming something that simply doesn't reflect current practice. There are many ebuilds with no maintainer tag and herd only. Are you claiming that they are unmaintained? Well, that obviously doesn't match the reality. So, if they actually _are_ maintained by the relevant herd, then you shouldn't dump stuff on that herd without discussing it w/ them first. I'm pretty sure mcummings will gladly explain to you what will happen if you do, as well as a bunch of other devs... :P To make it pretty clear and explicit - bugs gets assigned to maintainer (if there's any in metadata.xml), and get CCed to herd (if there's any in metadata.xml). If there's no maintainer, whoever is in herd will get that bug assigned and can happily smack you butt once they've find out you've dumped the package on them without their knowledge... That's how the large part of current ~600 dev-perl/* ebuilds has made it into the tree and that mistake doesn't need to be repeated. -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=getsearch=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Herds suck, fix them
Mike Frysinger wrote: On Thursday 15 June 2006 02:33, Kevin F. Quinn wrote: We could require that a herd mail alias be maintained for every herd, with the same name as the herd, such that the herd alias lists the maintainers of all packages in the herd. this would be useful regardless -mike Two notes here: - same name as herd requirement doesn't work for stuff like cron/mysql/postgresql/apache... i.e., system accounts. - needs to be done tree-wide (for packages that have metadata.xml at least :P - ebuilds w/o metadata is topic for another thread). Until it's completed, it's not useful - you still cannot rely upon the assumption that if herd alias ain't in maintainer, they don't maintain the thing. Otherwise yeah, +1 - and it's already done this way in many ebuilds, i.e., the herd alias is in maintainer as well. -- jakub signature.asc Description: OpenPGP digital signature
[gentoo-dev] eclasses maintainers - raise your hands please
While talking about herds etc... Please, stick your addy into the relevant eclass if you are actually a maintainer or at least a person to contact about the given eclass. Examples of eclasses that just let me clueless and digging in the logs when a bug/problem arrives: cvs.eclass - ??? db-use.eclass - pauldv? db.eclass - pauldv? eutils.eclass - ??? flag-o-matic.eclass - ??? gems.eclass - ruby, are you taking bugs for this? pythonhead's been MIA for ages, not much useful as a maintainer contact gnat.eclass - ??? gnatbuild.eclass - ??? gnuconfig.eclass - ??? latex-package.eclass - ??? mercurial.eclass - agriffis, mind sticking your addy there? :) mount-boot.eclass - ??? myspell.eclass - app-dicts? subversion.eclass - pretty popular wrt bugs, anyone but hattya touching this one? tla.eclass - meh, does anyone use it? versionator.eclass - anyone to take over after ciaranm? Thanks. -- jakub signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Herds suck, fix them
Marcus D. Hanwell wrote: I don't know if this is a really unpopular viewpoint, but for a lot of stuff I maintain I put myself as maintainer and the herd I am acting as part of in herd. My intention there is to say primarily I am taking care of this and have taken responsibility but if I disappear, am slow or someone else just wants to bump it etc in that herd then they are also free to do so. Well yeah, that's how I read the metadata.xml in such cases... but since some people are suggesting that herd is not relevant info wrt maintainership, this attempt for clarification has been proposed. May be it would be more correct for me to add the herd alias as a second maintainer? I think it is good for people to take responsibility for what they add to the tree and that is my intention there... :=) If a general consent is (games left apart ;) that herd is a backup for cases when maintainer is unavailable/goes MIA, and a primary maintainer if there's no maintainer tag in metadata.xml, let's just leave it at that, be done with it and save ourselves the hassle... If we can't agree upon this, then we probably should stick herd alias into maintainer tag when that herd _is_ actually willing to act as a maintainer. More clear now? :) -- jakub signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Herds suck, fix them
Kevin F. Quinn wrote: - same name as herd requirement doesn't work for stuff like cron/mysql/postgresql/apache... i.e., system accounts. Herd aliases could be named herd-name, perhaps. Current practice for these aliases is herd-bugs in most of the cases. Examples - apache-bugs, php-bugs, cron-bugs, mysql-bugs, pgsql-bugs (grrr, this one's inconsistent :P)... Probably best to stick w/ that, I'd say. -- jakub signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Herds suck, fix them
Chris Gianelloni wrote: *sigh* Indeed... No. You've gone and changed the practices we have in place now to make it more complicated. No, I didn't. If games herd wants any game dumped onto games herd, then do it. Most other people probably don't want unknown stuff dumped on them. Say it with me. Herd == packages Team == people There's no such thing like team in metadata.xml, that's what we've been talking about for ~1 day now. Good. Now say This requires me to make no changes to how I operate. Very good. No, this requires that people don't dump packages on others without their consent. That what we've been talking about for ~1day now. Somebody give this man a cookie! I prefer beer, thanks. ;) -- jakub signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Herds suck, fix them
Chris Gianelloni wrote: On Thu, 2006-06-15 at 17:43 +0200, Jakub Moc wrote: Say it with me. Herd == packages Team == people There's no such thing like team in metadata.xml, that's what we've been talking about for ~1 day now. Maybe it's what you erroneously have been trying to say that I've been saying, but it definitely isn't what we have been talking about. The team is *implied* by the herd. If you email the alias for the herd, you get the team. It really is that simple. Once again - the team is *only* implied by the herd if the team does _agree_ that the particular package in question should belong to the herd. If they don't, they it implies nothing. So, what we have been talking about is that you shouldn't encourage people to stick something into herd, like herdperl/herd just because it's perl app (or to restate what you've mentioned, to stick herdgames/herd there just because it's a game. People won't like it, so don't force you games team practice on others, it's not how that mostly works outside of games herd/team. To quote ciaranm, since I obviously can't express myself the way you could understand: quote The issue is the old metastructure definition, which a) encourages dumping packages upon herds that don't want them and b) means you can't say assign it to the vim herd. Which is rather annoying, because in practice the people that maintain a particular herd call themselves a herd, and the team / herd distinction is not usually made. /quote Let's look at this another way. There are a few packages which belong to the livecd herd. There is no livecd team, there is just me. The only person on the herd alias for livecd is me. That doesn't make *me* the livecd herd. It makes the *packages* the livecd herd and *me* the *maintainer*. And again, what's this distinction good for? Well, it's useless unless you are trying to enforce something like what you've suggested here before, i.e. quote I see nothing wrong with listing perl as the herd, *only* if they have themselves as the maintainer. /quote Well of course it's wrong b/c people that don't give a damn about the thing you've just dumped on them will get the bugs! And will need to either remove themselves from metadata.xml or if they don't do it, will finally end up maintaining the thing once the guy who's kindly dumped it on them went MIA/retired. -- jakub signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Bugzilla usage for overlays' projects [was: sunrise, a temporary compromise]
Anders Hellgren wrote: On Fri, 23 Jun 2006, Stuart Herbert wrote: On 6/23/06, Donnie Berkholz [EMAIL PROTECTED] wrote: I'm amazingly confused about why technical policy decisions (and even discussions about them) are being made by devrel in a devrel-specific channel. Could someone clear me up on this? Thanks, Donnie Sorry, but I must second this, especially as discussions have also been continuing that (unlike Mike's discussion) actually included council members. I'm all for folks trying to help resolve the Sunrise issues, but I feel that it's not devrel's place to be deciding this particular policy issue, especially when the issue has already been referred to the council. Best regards, Stu FWIW, there was almost an hour's worth of discussion before the start of the log KingTaco posted. As a bystander, my guess is that the discussion took place in the devrel channel because a complaint about the use of the bugzilla whiteboard by the sunrise folks was brought up in that channel. The compromise was made to defuse further escalation to a formal complaint to devrel. /Anders -- Anders Hellgren (kallamej) Gentoo Forums Administrator OK, so - java folks, please, take your java migration overlay bugs somewhere else from bugzilla. You know very well I had no problem w/ assigning them, I just requested them to be clearly marked as such (which the users have been doing, thank you for that). Since some developers consider such use of bugzilla as misuse of Gentoo infrastructure and have gone so far that they involved devrel in this discussion, I'm not going to assign those bugs any more. Your 'thank you' goes especially to brix, your complaints go to devrel as a body that proclaimed themselves empowered to decide on acceptable bugzilla usage. There's no technical difference between using bugzilla for unofficial java migration overlay hosted on gentooexperimental.org and using it for unofficial overlay hosted on gentoo-sunrise.org (and even usage of keywords and status whiteboard for unofficial overlays counts as a misuse of bugzilla here). Devrel's current policy clearly is that bugzilla may only be used for official overlays hosted on overlays.gentoo.org, Sorry for the inconvenience, not my fault. -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=getsearch=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Bugzilla usage for overlays' projects [was: sunrise, a temporary compromise]
Seemant Kulleen wrote: First of all, I'm not sure why devrel was involved in a technical decision without actually having all the interested parties there, but aside from that, when Gentoo developers become a bunch of 5 year olds? Not sure either, maybe brix will be able to answer your question better. What is this absolute nonsense of you don't like my toy, you can't have your toy going on around here? Jakub, if you will disrupt others because you can't have your way, then please reconsider exactly what your role is in this project, and maybe even how you might better serve some other project. Uhm, what I am saying here is that we can either have a *general* policy on acceptable bugzilla usage, or no policy at all. Inventing ad-hoc policies for a single project just because a couple of folks dislike that project does not do any good and does not make any sense either. The whole concept of status whiteboard and keywords usage constituting a misuse of Gentoo infrastructure is pretty new to me. That stuff is there to make searching for bugs and their grouping easier, and as such has been used. Then someone comes to #-devrel with the above complaint, and devrel (or some its member) within an hour decides that all such keywords and status whiteboard records need to be nuked from bugzilla? What are the grounds for such decision, and why it's OK for one unofficial project to use bugzilla for their bugs, and why it's so horribly wrong for another unofficial project to even pollute those fields, without actually creating new bugs? That's what this thread is about, and that's why I have brought this up. Not to harm java migration and java folks. As I have stated already, I have no problem with their bugs, I've even talked to nichoj some weeks ago to arrange it in the best possible way. This childishness from *all* sides is getting really old, really fast. People need to grow the hell up, and quit with the melodrama. Seemant There would not be any issue if devrel didn't act the way they did, the matter has not been urgent at all. -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=getsearch=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Bugzilla usage by gentoo-java's doing migration work
Stephen P. Becker wrote: Patrick Lauer wrote: No, it just shows that two different standards are applied and jakub (as well as some others) do not wish for any discrimination. If sunrise gets blocked with the argument it's an overlay then, by logic, the Java overlay should get the same treatment, even if this is stupid, unfair and stupid. Wow, you are incredibly good at dismissing the actual argument that many folks have raised against sunrise, and instead inserting the waaahh!!! they aren't treating us the same!!! argument. In fact, there is no reason to be treated the same in this case. The council decided that sunrise was to be suspended, which in my mind constitutes a total scorched earth policy with respect to the use of any sort of Gentoo infra in any way. The council did not decide that the java overlay was to be suspended, ergo the java overlay can use Gentoo infra as a resource. Frankly said, neither council nor devrel have any say in suspending projects hosted outside of gentoo, be it sunrise, gentopia, java-migration, java-experimental, BMG, or whatever else. You just can't dictate unpaid people what are they going to do in their free time (though some people would probably like to...) - so, please don't move this debate off-topic. I'm sorry if the sunrise-related decisions have negative influence on other projects and I hope that these issues get sorted out soon. Personally I find this debate silly, jokey and genstef have done whatever they could to reach a compromise for sunrise without castrating the project. If that isn't enough it starts to look to me like an attack on the persons and not on the technical structure. Please, cut the bullshit and stop deflecting these arguments as a personal attack, which you *always* seem to do once an argument reaches a point that you have nothing meaningful to say. So... sunrise has been suspended, moved to it's own domain, moved to non-gentoo hardware - and some people still are not satisfied and need to find something to annoy the bunch of people working on it. And, as there's not much left, they take something really childish and ridiculous, such as bugzilla keywords and status whiteboard, and run to devrel to ask for an urgent decision? What's this, if not a personal thing? -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=getsearch=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Bugzilla usage by gentoo-java's doing migration work
Chris Gianelloni wrote: On Fri, 2006-06-23 at 15:50 +0200, Jakub Moc wrote: Perhaps it is a few developers trying to actually enforce the council's decision and make sure that the 100% unofficial project doesn't *look* official. Using InOverlay as if Sunrise is some sort of Gentoo official overlay is a prime example of this. Let's look at it this way. If someone from Sunrise were to say this ebuild is available in our overlay in a comment, nobody would really have a problem. Having someone with an @gentoo.org address setting InOverlay makes it look like Gentoo is endorsing the overlay. Remember that when you use your @gentoo.org address, you're speaking for Gentoo in the user's eyes. Using InOverlay would be the same as someone from BMG (that happened to be a developer) doing it because it is in the BMG overlay. It's simply not accurate. It's exactly as accurate as the keyword description [1] is, i.e.: snip A case where someone is working on this maintained-needed ebuild in an overlay to test their fixes before including it in an ebuild in the tree. /snip So, be it BMG or sunrise or whatever else, it's an appropriate use of that keyword, and there's nothing there suggesting that the overlay is an official one. [1] http://bugs.gentoo.org/describekeywords.cgi -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=getsearch=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Re: Re: GPL and Source code providing
Curtis Napier wrote: If it's decided to go with this idea I think we should mark it up a little, even if it's only a dollar or two. People actually don't mind paying a little if it's going to go towards helping Gentoo. We get tons of threads asking about donating in the forums so this would be a good way to help with that (even if the DVD isn't purchased very often). --Curtis You can't do that according to GPL-2, see esp. the part: 3. b) Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution , a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or, -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=getsearch=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: [gentoo-core] IMPORTANT: bugs performance issues
Curtis Napier wrote: Lance Albertson wrote: Please thank GNI for helping us out! They really deserve a lot for helping us :). Thanks- [1] http://www.gni.com/ Thank you GNI! droolmmm blade cluster/drool Yay, *plop* !!! (And no, tsunam - no compiling there :P) -- jakub signature.asc Description: OpenPGP digital signature
