Re: [gentoo-dev] colon separated variables in /etc/env.d/
Zac Medico wrote: What is the best way to propagate information about these two variable types? For example, we can have a list of variable names stored in a new variable called COLON_SEPARATED that will reside in either the profiles or /etc/env.d/ itself. Variable names not listed in COLON_SEPARATED can be assumed to be space separated. Does anyone have any ideas to share about how this information should be propagated? Considering that some pretty critical variables (like PATH) are amongst these I would prefer them to be in /etc/env.d. I wouldn't like it when my box is totally screwed just because PORTDIR doesn't point at my portage tree for the moment. -- Kind Regards, Simon Stelling Gentoo/AMD64 developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New git.eclass (Take #2)
On Thu, Sep 07, 2006 at 08:32:50PM +0200, Fernando J. Pereda wrote: Hi guys, We are planning to add git.eclass as presented in bug #132383 (as attachment 96300). I also attach it here in case someone wants to comment parts of it. git.eclass is now in the tree - ferdy -- Fernando J. Pereda Garcimartín Gentoo Developer (Alpha,net-mail,mutt,git) 20BB BDC3 761A 4781 E6ED ED0B 0A48 5B0C 60BD 28D4 pgplSVpvKPfQQ.pgp Description: PGP signature
Re: [gentoo-dev] colon separated variables in /etc/env.d/
Am Montag, 11. September 2006 03:44 schrieb Zac Medico: Hi everyone, Portage currently has two hard-coded lists of variables that control the behavior of env-update. The same applies to eselect env. I'd like to make these variables configurable so that package maintainers have direct control over them. The variables break down into two basic types: colon separated and space separated. Wrong, there is another type of var, namely those which are not cummultative(sp?). What is the best way to propagate information about these two variable types? For example, we can have a list of variable names stored in a new variable called COLON_SEPARATED that will reside in either the profiles or /etc/env.d/ itself. Variable names not listed in COLON_SEPARATED can be assumed to be space separated. Does anyone have any ideas to share about how this information should be propagated? a) You'd need two variables to store that info, as we have 3 classes of envvars. b) This is in no way related to the package tree. Those vars don't magically change their class from colon separated to non cummultative. I'd like to keep it hardcoded, as loading of such variables can go wrong and you'd end up without a working env tool. Danny -- Danny van Dyk [EMAIL PROTECTED] Gentoo/AMD64 Project, Gentoo Scientific Project -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Last rites for www-apps/drupal
On 9/9/06, Christel Dahlskjaer [EMAIL PROTECTED] wrote: Drupal has had QA bug #98542 open for over a year now, and has seen no progress in resolving it. It has now been package.masked, and unless someone jumps up to fix the outstanding issues will be removed in 30 days. Why didn't you escalate this to either of the webapps herd leads first? You've certainly had the opportunity to do so before now. We're all meant to be working _together_. This is _not_ a shining example of how to do so. Best regards, Stu -- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Last rites for www-apps/drupal
Stuart Herbert wrote: On 9/9/06, Christel Dahlskjaer [EMAIL PROTECTED] wrote: Drupal has had QA bug #98542 open for over a year now, and has seen no progress in resolving it. It has now been package.masked, and unless someone jumps up to fix the outstanding issues will be removed in 30 days. Why didn't you escalate this to either of the webapps herd leads first? You've certainly had the opportunity to do so before now. We're all meant to be working _together_. This is _not_ a shining example of how to do so. Uhm, web-apps has been CCed on the bug since the beginning. Last time I asked, noone wanted to touch the FUBARed ebuild, IIRC. :) -- 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] Last rites for www-apps/drupal
On 9/11/06, Jakub Moc [EMAIL PROTECTED] wrote: Uhm, web-apps has been CCed on the bug since the beginning. Last time I asked, noone wanted to touch the FUBARed ebuild, IIRC. :) The package was masked without Christel (on behalf of QA) posting an advance warning of their actions. That's not trying to work together. It's not trying to work with existing teams. Best regards, Stu -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Last rites for www-apps/drupal
On 9/10/06, Luca Barbato [EMAIL PROTECTED] wrote: Alec Warner wrote: upstream for that reason Upstream sucks badly here. us because we haven't a tool like the one BaSS wrote for the ebooks. Such a tool would deal with many modules, but not all of them. Some modules require additional dependencies, which a tool just isn't going to know about. Last count, there were 187 modules for Drupal upstream; there are probably more now. I have new ebuilds for drupal, and a number of modules (I think I got up to 'f') locally. I'll get them into the webapps overlay, so that folks can test them, and help out. Drupal's such a beast that it probably needs its own herd to keep on top of things. Best regards, Stu -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Council election master ballot
Here's the master ballot for the election. Confirmation e-mails will follow. -g2boojum- -- Grant Goodyear Gentoo Developer [EMAIL PROTECTED] http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76 - confirmation 2b94 - vapier kloeri wolf31o2 robbat2 spb Kugelfang jaervosz KingTaco Ramereth `Kumba pauldv lu_zero jakub UberLord dostrow Flameeyes Pylon nattfodd rl03 CHTEKK patrick - confirmation 2e5d - Flameeyes KingTaco vapier patrick lu_zero Pylon dostrow UberLord `Kumba robbat2 spb rl03 Kugelfang jakub CHTEKK wolf31o2 pauldv Ramereth kloeri jaervosz nattfodd - confirmation 2f69 - vapier UberLord wolf31o2 Kugelfang Flameeyes kloeri KingTaco `Kumba robbat2 lu_zero CHTEKK pauldv nattfodd rl03 Ramereth Pylon jaervosz jakub patrick dostrow spb - confirmation 3396 - jaervosz vapier pauldv Kugelfang Flameeyes kloeri robbat2 lu_zero jakub UberLord rl03 CHTEKK KingTaco `Kumba spb nattfodd dostrow patrick Pylon Ramereth wolf31o2 - confirmation 3652 - vapier Flameeyes kloeri wolf31o2 Pylon lu_zero Kugelfang CHTEKK KingTaco Ramereth jaervosz robbat2 UberLord `Kumba pauldv dostrow nattfodd rl03 jakub patrick spb - confirmation 0571 - vapier wolf31o2 kloeri robbat2 Kugelfang Ramereth `Kumba KingTaco dostrow Flameeyes UberLord jakub pauldv jaervosz rl03 lu_zero Pylon CHTEKK nattfodd spb patrick - confirmation 3845 - pauldv robbat2 Flameeyes vapier Pylon lu_zero wolf31o2 `Kumba Ramereth Kugelfang jakub dostrow KingTaco kloeri jaervosz patrick UberLord nattfodd CHTEKK rl03 spb - confirmation 38f6 - pauldv kloeri lu_zero wolf31o2 robbat2 vapier jakub Flameeyes dostrow CHTEKK Ramereth patrick `Kumba rl03 UberLord Pylon jaervosz KingTaco nattfodd Kugelfang spb - confirmation 3cea - KingTaco Kugelfang wolf31o2 vapier UberLord Flameeyes dostrow rl03 Ramereth `Kumba spb nattfodd kloeri pauldv lu_zero patrick jaervosz robbat2 Pylon CHTEKK jakub - confirmation 3d6c - kloeri Flameeyes - confirmation 4196 - vapier pauldv kloeri Flameeyes lu_zero KingTaco Kugelfang Pylon rl03 dostrow `Kumba CHTEKK Ramereth robbat2 jaervosz nattfodd UberLord jakub patrick wolf31o2 spb - confirmation 4211 - dostrow wolf31o2 vapier Ramereth Flameeyes kloeri rl03 KingTaco Kugelfang `Kumba UberLord nattfodd lu_zero jaervosz pauldv Pylon spb robbat2 CHTEKK patrick jakub - confirmation 42c9 - spb wolf31o2 nattfodd vapier Ramereth robbat2 KingTaco pauldv jaervosz `Kumba kloeri rl03 UberLord - confirmation 46fc - vapier kloeri Flameeyes wolf31o2 pauldv lu_zero patrick UberLord Kugelfang jakub nattfodd KingTaco robbat2 spb Pylon rl03 `Kumba jaervosz dostrow CHTEKK Ramereth - confirmation 4903 - vapier UberLord wolf31o2 CHTEKK Flameeyes rl03 jakub dostrow Ramereth robbat2 patrick pauldv lu_zero nattfodd jaervosz KingTaco `Kumba kloeri Kugelfang Pylon spb - confirmation 4d6e - vapier pauldv kloeri UberLord wolf31o2 robbat2 lu_zero jaervosz Flameeyes Kugelfang CHTEKK `Kumba rl03 Pylon nattfodd Ramereth jakub dostrow patrick KingTaco spb - confirmation 4f4e - Flameeyes jaervosz kloeri jakub Kugelfang Pylon spb vapier pauldv robbat2 wolf31o2 UberLord dostrow KingTaco rl03 lu_zero nattfodd `Kumba CHTEKK Ramereth patrick - confirmation 52ad - vapier KingTaco lu_zero pauldv kloeri Kugelfang UberLord jaervosz wolf31o2 Flameeyes robbat2 patrick jakub `Kumba CHTEKK nattfodd Pylon rl03 Ramereth dostrow spb - confirmation 549c - jaervosz kloeri wolf31o2 Ramereth spb - confirmation 565d - kloeri vapier KingTaco Ramereth robbat2 wolf31o2 UberLord dostrow nattfodd jaervosz Pylon rl03 lu_zero Flameeyes patrick `Kumba Kugelfang pauldv CHTEKK jakub spb - confirmation 579d - dostrow vapier wolf31o2 KingTaco Ramereth lu_zero kloeri Flameeyes Kugelfang UberLord `Kumba robbat2 Pylon nattfodd jaervosz pauldv rl03 spb CHTEKK jakub patrick - confirmation 594b - CHTEKK vapier Flameeyes jaervosz kloeri KingTaco Ramereth jakub rl03 UberLord robbat2 wolf31o2 patrick pauldv lu_zero `Kumba spb - confirmation 095c - vapier jaervosz Flameeyes Kugelfang robbat2 jakub kloeri KingTaco wolf31o2 Pylon dostrow Ramereth UberLord CHTEKK `Kumba rl03 nattfodd lu_zero spb pauldv patrick - confirmation 5f84 - vapier wolf31o2 Flameeyes pauldv lu_zero Ramereth patrick dostrow KingTaco robbat2 Pylon Kugelfang jakub `Kumba UberLord spb kloeri jaervosz nattfodd rl03 CHTEKK - confirmation 5fa5 - robbat2 wolf31o2 vapier jaervosz Flameeyes nattfodd `Kumba KingTaco UberLord kloeri Kugelfang spb patrick lu_zero dostrow CHTEKK pauldv rl03 Pylon Ramereth jakub - confirmation 6338 - UberLord wolf31o2 Ramereth Flameeyes pauldv CHTEKK robbat2 KingTaco lu_zero
[gentoo-dev] unofficial council election results
Running countify on the master ballot yields the following results for the new council: vapier kloeri wolf31o2 Flameeyes KingTaco robbat2 Kugelfang These results are unofficial because under some circumstances countify has been known to fail. The signature of such failures in the past has been an iterative Condorcet ranking that ends up missing some of the names on the ballot, which did not happen here, but nonetheless I've asked fmccor to run his counting scripts on the master ballot to provide confirmation. (Incidentally, he'll be using the same master ballot that I just mailed out, as that's all that is needed, so if anybody else wants to provide an independent count, feel free.) -- Grant Goodyear Gentoo Developer [EMAIL PROTECTED] http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76 pgpMM8Lxio6vo.pgp Description: PGP signature
[gentoo-dev] unofficial results -- full ranking
I'd best give the full ranking for completeness (and for independent verifications): result: option vapier wins result: option kloeri wins result: option wolf31o2 wins result: option Flameeyes wins result: option KingTaco wins result: option robbat2 wins result: option Kugelfang wins result: option UberLord wins result: option jaervosz wins result: option lu_zero wins result: option dostrow wins result: option Ramereth wins result: option `Kumba wins result: option Pylon wins result: option pauldv wins result: option CHTEKK wins result: option nattfodd wins result: option rl03 wins result: option jakub wins result: option spb wins result: option patrick wins -g2boojum- -- Grant Goodyear Gentoo Developer [EMAIL PROTECTED] http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76 pgpYOj1W4APDT.pgp Description: PGP signature
Re: [gentoo-dev] Last rites for www-apps/drupal
On Mon, 2006-09-11 at 11:01 -0400, Alec Warner wrote:
Stuart Herbert wrote:
On 9/11/06, Jakub Moc [EMAIL PROTECTED] wrote:
Uhm, web-apps has been CCed on the bug since the beginning. Last time I
asked, noone wanted to touch the FUBARed ebuild, IIRC. :)
The package was masked without Christel (on behalf of QA) posting an
advance warning of their actions. That's not trying to work together.
It's not trying to work with existing teams.
So file a complaint; once again the -dev list shouldn't be for
complaining about how people {suck,don't follow policy}
I actually second Stuart on this one, I should have contacted web-apps
and believe that we should make it procedure to do so in the future.
That was my mistake entirely.
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Last rites for www-apps/drupal
On Sat, 2006-09-09 at 21:25 +0100, Christel Dahlskjaer wrote: Drupal has had QA bug #98542 open for over a year now, and has seen no progress in resolving it. It has now been package.masked, and unless someone jumps up to fix the outstanding issues will be removed in 30 days. Er, as someone just pointed out on IRC, the bug is http://bugs.gentoo.org/show_bug.cgi?id=98524 not 98542 as I first said. Sorry! -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Last rites for www-apps/drupal
On Mon, 11 Sep 2006 11:01:02 -0400 Alec Warner [EMAIL PROTECTED]
wrote:
| Stuart Herbert wrote:
| On 9/11/06, Jakub Moc [EMAIL PROTECTED] wrote:
| Uhm, web-apps has been CCed on the bug since the beginning. Last
| time I asked, noone wanted to touch the FUBARed ebuild, IIRC. :)
|
| The package was masked without Christel (on behalf of QA) posting an
| advance warning of their actions. That's not trying to work
| together. It's not trying to work with existing teams.
|
| So file a complaint; once again the -dev list shouldn't be for
| complaining about how people {suck,don't follow policy}
Now why does it not surprise me that you of all people are encouraging
people to complain about Christel? Is there something you'd like to get
out in the open?
--
Ciaran McCreesh
Mail: ciaranm at ciaranm.org
signature.asc
Description: PGP signature
Re: [gentoo-dev] unofficial council election results
I'd like to send my unofficial congratulations to the new council then. Also thanks to the folks who did the technical stuff behind the vote. Btw, how many people actually voted? cheers, Wernfried -- Wernfried Haas (amne) - amne at gentoo dot org Gentoo Forums: http://forums.gentoo.org IRC: #gentoo-forums on freenode - email: forum-mods at gentoo dot org pgpEAilrAfn1w.pgp Description: PGP signature
Re: [gentoo-dev] Last rites for www-apps/drupal
On 11/09/06, Ciaran McCreesh [EMAIL PROTECTED] wrote:
On Mon, 11 Sep 2006 11:01:02 -0400 Alec Warner [EMAIL PROTECTED]
wrote:
| Stuart Herbert wrote:
| On 9/11/06, Jakub Moc [EMAIL PROTECTED] wrote:
| Uhm, web-apps has been CCed on the bug since the beginning. Last
| time I asked, noone wanted to touch the FUBARed ebuild, IIRC. :)
|
| The package was masked without Christel (on behalf of QA) posting an
| advance warning of their actions. That's not trying to work
| together. It's not trying to work with existing teams.
|
| So file a complaint; once again the -dev list shouldn't be for
| complaining about how people {suck,don't follow policy}
Now why does it not surprise me that you of all people are encouraging
people to complain about Christel? Is there something you'd like to get
out in the open?
--
Ciaran McCreesh
Mail: ciaranm at ciaranm.org
+1 troll point ciaranm
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] colon separated variables in /etc/env.d/
Zac Medico wrote: We can store them in /etc/env.d/ itself. The env-update tool could be hare coded to consider COLON_SEPARATED and SPACE_SEPARATED as being implicitly within the SPACE_SEPARATED class. The tool would make one pass to accumulate those two variables, and then another pass to process the rest of the variables. How badly will this break someone's system when they accidentally rm -rf /etc/env.d and try to reinstall all the apps that put something there? Thanks, Donnie signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] unofficial council election results
Wernfried Haas wrote: [Mon Sep 11 2006, 11:23:03AM CDT] I'd like to send my unofficial congratulations to the new council then. Also thanks to the folks who did the technical stuff behind the vote. Btw, how many people actually voted? 121 -g2boojum- -- Grant Goodyear Gentoo Developer [EMAIL PROTECTED] http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76 pgpzQdoNFQZi8.pgp Description: PGP signature
Re: [gentoo-dev] Council election master ballot
On Mon, 11 Sep 2006 10:27:39 -0500 Grant Goodyear [EMAIL PROTECTED] wrote: | Here's the master ballot for the election. Confirmation e-mails | will follow. And here're the graphs that you've all come to know and love, showing once again that Condorcet is a brilliant system for picking out people who aren't unpopular rather than people who are popular. vapier (1) kloeri (2) wolf31o2 (3) |# || |# || |# || |# |# |# |# |# |# |# |# |# |# |### |## |### | ## |# # # |## |## |## +-- +-- +-- Flameeyes (4)KingTaco (5) robbat2 (6) ||| ||| ||| ||| ||| |# || # |# | ## # # | # ## |## # |### # |### # |## |## |# +-- +-- +-- Kugelfang (7)UberLord (8) jaervosz (9) ||| ||| ||| ||| ||| ||| | ## # | ## # |### # | ## # |# |# ## |## |## |## +-- +-- +-- lu_zero (10) dostrow (11) Ramereth (12) ||| ||| ||| ||| ||| || # # | # # | # # # | ## # | ## # | |# # |### # |## |## |## +-- +-- +-- `Kumba (13) Pylon (14) pauldv (15) ||| ||| ||| ||| ||| ||# | | ## # | ## # | ## # |# ## |# ## |# ### |## |## |## +-- +-- +-- CHTEKK (16) nattfodd (17)rl03 (18) ||| ||| ||| ||| |# |# |# |# |# | # # | ## # | | ### | # # |# | |## |## |## +-- +-- +-- jakub (19) spb (20) patrick (21) ||| ||| |||# ||# |# |# |# |# |# |# |## | # # | # ## | # ## | ### |## | # |## |## |## +-- +-- +-- -- Ciaran McCreesh Mail: ciaranm at ciaranm.org signature.asc Description: PGP signature
Re: [gentoo-dev] Last rites for www-apps/drupal
Ciaran McCreesh wrote:
On Mon, 11 Sep 2006 11:01:02 -0400 Alec Warner [EMAIL PROTECTED]
wrote:
| Stuart Herbert wrote:
| On 9/11/06, Jakub Moc [EMAIL PROTECTED] wrote:
| Uhm, web-apps has been CCed on the bug since the beginning. Last
| time I asked, noone wanted to touch the FUBARed ebuild, IIRC. :)
|
| The package was masked without Christel (on behalf of QA) posting an
| advance warning of their actions. That's not trying to work
| together. It's not trying to work with existing teams.
|
| So file a complaint; once again the -dev list shouldn't be for
| complaining about how people {suck,don't follow policy}
Now why does it not surprise me that you of all people are encouraging
people to complain about Christel? Is there something you'd like to get
out in the open?
ROFL :)
--
gentoo-dev@gentoo.org mailing list
[gentoo-dev] Results now more official
Thanks to fmccor, we now have additional confirmation of the results using STV, with a minor wrinkle: My results agree. I showed a difference in the 7th position (jaervosz for Kugelelfang), but on closer examination, I see that this comes about because of a tie vote. I.e., I show a several-way tie for 7th, and STV makes a random choice. So, sometimes I get Kugelfang, sometimes jaervosz. Regards, Ferris We're using a different (non-random) tie-breaking scheme in countify, namely the Schulze method, so the countify results appear to be definitive. -g2boojum- -- Grant Goodyear Gentoo Developer [EMAIL PROTECTED] http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76 pgpUBNQWaNjZP.pgp Description: PGP signature
Re: [gentoo-dev] colon separated variables in /etc/env.d/
On Sun, 10 Sep 2006 18:44:23 -0700 Zac Medico [EMAIL PROTECTED] wrote: | Portage currently has two hard-coded lists of variables that control | the behavior of env-update. I realise GLEP 24 is considered not going very far, but in the interests of what *has* been done on it... Is it worth continuing development on env-update? -- Ciaran McCreesh Mail: ciaranm at ciaranm.org signature.asc Description: PGP signature
Re: [gentoo-dev] colon separated variables in /etc/env.d/
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Donnie Berkholz wrote: Zac Medico wrote: We can store them in /etc/env.d/ itself. The env-update tool could be hare coded to consider COLON_SEPARATED and SPACE_SEPARATED as being implicitly within the SPACE_SEPARATED class. The tool would make one pass to accumulate those two variables, and then another pass to process the rest of the variables. How badly will this break someone's system when they accidentally rm -rf /etc/env.d and try to reinstall all the apps that put something there? It shouldn't behave any differently than it already does. The old values will have to remain hard-coded, at least for a while. Moving forward, packages that install files in /etc/env.d/ should include COLON_SEPARATED and SPACE_SEPARATED definitions as necessary for the other variables that they define. Zac -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFBaAE/ejvha5XGaMRAnt3AJ4p/EvxIMAhJnuFqeyBljRc6BcJRACfbahC zg0M3OBw6orQVoOrSkd7uJA= =oZdG -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] colon separated variables in /etc/env.d/
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ciaran McCreesh wrote: On Sun, 10 Sep 2006 18:44:23 -0700 Zac Medico [EMAIL PROTECTED] wrote: | Portage currently has two hard-coded lists of variables that control | the behavior of env-update. I realise GLEP 24 is considered not going very far, but in the interests of what *has* been done on it... Is it worth continuing development on env-update? Regardless of whether or not we keep the actual env-update tool around, I think that making these variables configurable would be a good idea. It removes any lag between the time that a package maintainer needs to add a new special variable and the time that it is supported. Zac -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFBaOP/ejvha5XGaMRAqR9AKC0F+Ra3Qxh8pAfdYP8h0BFv2IvtgCdHbbn I6Z1YX6yXX8SdfIreN8rbJM= =DPbS -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Last rites for www-apps/drupal
On Monday 11 September 2006 14:07, Stuart Herbert wrote: I have new ebuilds for drupal, and a number of modules (I think I got up to 'f') locally. I'll get them into the webapps overlay, so that folks can test them, and help out. I'm more than happy for you to take Drupal instead of me :) However, is there any reason that the main drupal ebuild cannot stay in portage? Thanks -- Roy Marples [EMAIL PROTECTED] Gentoo/Linux Developer (baselayout, networking) -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] colon separated variables in /etc/env.d/
On Monday 11 September 2006 03:44, Zac Medico wrote: Hi everyone, Portage currently has two hard-coded lists of variables that control the behavior of env-update. I'd like to make these variables configurable so that package maintainers have direct control over them. The variables break down into two basic types: colon separated and space separated. What is the best way to propagate information about these two variable types? For example, we can have a list of variable names stored in a new variable called COLON_SEPARATED that will reside in either the profiles or /etc/env.d/ itself. Variable names not listed in COLON_SEPARATED can be assumed to be space separated. Does anyone have any ideas to share about how this information should be propagated? There should also be a third list (or the absense of inclusion in the above). That is those variables that can only have one value and are overridden instead of appended. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpNjh6gLevKm.pgp Description: PGP signature
Re: [gentoo-dev] colon separated variables in /etc/env.d/
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Paul de Vrieze wrote: On Monday 11 September 2006 03:44, Zac Medico wrote: What is the best way to propagate information about these two variable types? For example, we can have a list of variable names stored in a new variable called COLON_SEPARATED that will reside in either the profiles or /etc/env.d/ itself. Variable names not listed in COLON_SEPARATED can be assumed to be space separated. Does anyone have any ideas to share about how this information should be propagated? There should also be a third list (or the absense of inclusion in the above). That is those variables that can only have one value and are overridden instead of appended. I think it will be sufficient to have COLON_SEPARATED and SPACE_SEPARATED lists, with all other variables assumed to be overridden instead of appended. To sumarize what I've said in my other replies, COLON_SEPARATED and SPACE_SEPARATED will be stored in /etc/env.d/ itself. The env-update tool (or whatever tool will process /etc/env.d/) will be hard coded to consider COLON_SEPARATED and SPACE_SEPARATED as being implicitly within the SPACE_SEPARATED class. The tool will make one pass to accumulate those two variables, and then another pass to process the rest of the variables. The COLON_SEPARATED and SPACE_SEPARATED variables will automatically be initialized with the old hard coded values. Moving forward, packages that install files in /etc/env.d/ should include COLON_SEPARATED and SPACE_SEPARATED definitions as necessary for the other variables that they define. Zac -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFBdf1/ejvha5XGaMRAtzkAKDupzkoiuD5LxyklTr5odvBMoiHxwCfYKYx h3jGTEn6YQhqau17fFhNkKQ= =OUrp -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Last rites for www-apps/drupal
On 9/11/06, Roy Marples [EMAIL PROTECTED] wrote: I'm more than happy for you to take Drupal instead of me :) However, is there any reason that the main drupal ebuild cannot stay in portage? No reason at all, that I know of. Drupal's a package I can't really work on; I work for a company that writes and sells a very successful (and proprietry) CMS. Looking after the main ebuild isn't that much work for someone; it's sorting out all the modules that's a full-time job. Best regards, Stu -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] RFC: Package Manager Specification: configuration protection
A while back it was agreed that it would be a good idea to standardise certain aspects of package manager behaviour. We thought it'd be a good idea to start with something easy so that we can iron out any kinks in the process... So... Attached is a first draft of an attempt at standardising how configuration protection is handled. Although it's not strictly speaking a core part of the ebuild API, it's none the less something that should probably be handled consistently. Comments both on the nature and the specifics of the specification would be welcomed. In particular, I'd like to know if people think we're mandating the appropriate degree of specificity and whether we're providing sufficient generality to avoid overly restricting innovation. Yours lovingly, -- Ciaran McCreesh Mail: ciaranm at ciaranm.org == Package Manager Standard: Configuration Protection == Abstract This document defines how a Package Manager should handle the filesystem aspect of configuration protection. Overview Configuration protection is used by a Package Manager to avoid overwriting or removing important configuration files (e.g. ``/etc/fstab``) when updating or uninstalling a package. Rather than overwriting these files in the merge phase, the file to be installed is renamed according to a defined set of rules; when unmerging a package, these files are not removed. File Merging Rules == When merging a file to a protected location: * If no existing file with the intended target name exists, or if the existing file has identical content to the file to be installed, the file to be installed is installed as normal. * Otherwise, pretend that the filename of the file to be installed is ``._cfg_name``, where ``name`` is the real name. If no file with this name exists, or if the existing file with this name has identical content to the file to be installed, the file to be installed is merged with this new name. * Otherwise, try again with ``._cfg0001_name``, then ``._cfg0002_name`` and so on (base ten is used for the number part) until a usable filename is found. * Behaviour is undefined in the highly unlikely circumstance that ```` is reached. Configuration protection does not apply to non-files. File Unmerging Rules Files in a protected location should not be unmerged. Protected Locations === Protected locations are determined by the ``CONFIG_PROTECT`` environment variable, which is defined in the profiles and which may be augmented or overridden by the current environment and user configuration files. This variable contains a space separated list of values which are matched against the beginning of a full file path and name of files to be installed. Any item inside ``CONFIG_PROTECT`` that starts with a minus symbol instead removes any previous item with the value following the minus from the list. The special value ``-*`` can be used to remove *all* previous values. The behaviour of special wildcard characters inside items (e.g. ``/foo?bar/*monkey*/baz``) is undefined. The ``CONFIG_PROTECT_MASK`` environment variable, which has the same format and origin as ``CONFIG_PROTECT``, can be used to unprotect locations. If any of its items match the beginning of the full file path and name of a file to be installed, that file is *not* considered protected. For example, if ``CONFIG_PROTECT`` is ``/etc /usr/share/X11/xkb`` and ``CONFIG_PROTECT_MASK`` is ``/etc/init.d``, files to be installed to these locations are considered protected: * ``/etc/fstab`` * ``/etc/vim/vimrc`` * ``/etcetera`` * ``/usr/share/X11/xkb/keycodes/ibm`` And these are considered not protected: * ``/usr/share/foo/foo.txt`` * ``/etc/init.d/sshd`` * ``/etc/init.donkey`` * ``/usr/local/etc/fstab`` If ``ROOT`` is in use, configuration protection should be applied to the ``ROOT`` directory rather than the normal filesystem root. For example, if ``ROOT`` is ``/image`` and ``CONFIG_PROTECT`` is ``/etc``, then ``/image/etc`` should be protected. Integration with External Tools === The package manager should provide a way for external tools to obtain a list of locations where protected files requiring action may be found. .. vim: set tw=80 ft=glep spell spelllang=en : .. signature.asc Description: PGP signature
Re: [gentoo-dev] Last rites for www-apps/drupal
On Mon, 2006-09-11 at 17:10 +0100, Ciaran McCreesh wrote: Now why does it not surprise me that you of all people are encouraging people to complain about Christel? Is there something you'd like to get out in the open? I've been watching you spew for a while. When are you going to get over it? All he did was try and redirect where complaints should go. Stop being such a drama queen, jeez. -- Seemant Kulleen Trustee, Gentoo Foundation Developer, Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Results now more official
Congratulations to the new council. I hope for a lot of progress this year outta you guys :) Thanks, -- Seemant Kulleen Trustee, Gentoo Foundation Developer, Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC: Package Manager Specification: configuration protection
On Mon, 11 Sep 2006 16:02:53 -0700 Chris White [EMAIL PROTECTED] wrote: | On Monday 11 September 2006 15:22, Ciaran McCreesh wrote: | * Otherwise, try again with ``._cfg0001_name``, then | ``._cfg0002_name`` and so on (base ten is used for the number part) | until a usable filename is found. | | For what purpose are the older cfg[number]_name files kept around? I | ask because I would anticipate the default behavior for replacing | configuration files with their pending updates to be picking the | newest update. That said, the previous versions would not serve a | purpose, or is there something I don't see? Existing tools ask the user which file they want to use when there's more than one. It's possible that this is more useful behaviour, especially if, say, someone is upgrading and downgrading the same package repeatedly for testing purposes. The purpose of these specifications isn't to change behaviour, except for small things where obvious and clear bugs or deficiencies are found (which I don't think is the case here). Rather, they're to document and clarify what current behaviour should be considered reliable rather than merely a coincidence of how Portage happens to work. -- Ciaran McCreesh Mail: ciaranm at ciaranm.org signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: Package Manager Specification: configuration protection
On Mon, Sep 11, 2006 at 04:02:53PM -0700, Chris White wrote: On Monday 11 September 2006 15:22, Ciaran McCreesh wrote: * Otherwise, try again with ``._cfg0001_name``, then ``._cfg0002_name`` and so on (base ten is used for the number part) until a usable filename is found. For what purpose are the older cfg[number]_name files kept around? I ask because I would anticipate the default behavior for replacing configuration files with their pending updates to be picking the newest update. That said, the previous versions would not serve a purpose, or is there something I don't see? Consider a case as follows: 1. package foo provides /etc/bar - the contents of the file differ depending on the USE flags. 2. an old version of foo is already installed, with USE='a' 3. user does USE='a b' emerge foo - /etc/._cfg_bar is created. 4. user then realizes he actually wanted USE=c as well, so does USE='a b c' emerge foo - this provides /etc/._cfg0001_bar. You now have 3 files, non-identical: /etc/bar /etc/._cfg_bar /etc/._cfg0001_bar The user now runs etc-update or dispatch-conf or whatever tool they use to manage their configurations. The 'try again rule to find a usable filename' is specifically intended for these cases where the configuration management is NOT used between more than two changes of a configuration file (Ideally it should be, but that's a different discussion). -- Robin Hugh Johnson E-Mail : [EMAIL PROTECTED] GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 pgpJDzBNDGPzq.pgp Description: PGP signature
[gentoo-dev] GIMP 1.2 has gotta die
Hi, Just had an irc-talk with allanonjl and I'm now co-maintaining gimp. I want to remove old gimp 1.2 soon (a bunch of bugs could be closed and we could get rid of that symlink-hack for the bins). If you have any objections, cry now (but expect that I want you to maintain that stuff if you cry). cu, Hanno pgp04IqJ0L34X.pgp Description: PGP signature
Re: [gentoo-dev] RFC: Package Manager Specification: configuration protection
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ciaran McCreesh wrote: * If no existing file with the intended target name exists, or if the existing file has identical content to the file to be installed, the file to be installed is installed as normal. Just one poor dev's opinion, but I prefer it when these files are created as .sample's or examples. Invariably there is some tweaking that needs to be done to the file, even when it's the initial version of the file. This also forces the user to get acquainted with the config file in question (samba and make.conf files come to mind). Of course, tweaking something like etc-update (or equiv tool) to be able to compare the sample/example file to the live one would be nice, but then I've just talked myself in a circle renaming the ._cfg* files, haven't I? - -- - -o()o-- Michael Cummings |#gentoo-dev, #gentoo-perl Gentoo Perl Dev|on irc.freenode.net Gentoo/SPARC Gentoo/AMD64 GPG: 0543 6FA3 5F82 3A76 3BF7 8323 AB5C ED4E 9E7F 4E2E - -o()o-- -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.4 (GNU/Linux) iD8DBQFFBf+kq1ztTp5/Ti4RAp0mAKCzpZGqnF6cl/hm+kklR4PxNj28AQCfT45Q yfPdoOSEqMvKkhEkGFTJWmY= =qoX4 -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GIMP 1.2 has gotta die
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hanno Böck wrote: Hi, Just had an irc-talk with allanonjl and I'm now co-maintaining gimp. I want to remove old gimp 1.2 soon (a bunch of bugs could be closed and we could get rid of that symlink-hack for the bins). If you have any objections, cry now (but expect that I want you to maintain that stuff if you cry). cu, Hanno Looks like that will break media-gfx/frontline (=media-gfx/gimp-1.2*) and gimp-freetype-0.2-r3 (also =media-gfx/gimp-1.2*). /me has no vested interest, was just checking reverse deps in case it impacted any of the gimp perl deps - -- - -o()o-- Michael Cummings |#gentoo-dev, #gentoo-perl Gentoo Perl Dev|on irc.freenode.net Gentoo/SPARC Gentoo/AMD64 GPG: 0543 6FA3 5F82 3A76 3BF7 8323 AB5C ED4E 9E7F 4E2E - -o()o-- -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.4 (GNU/Linux) iD8DBQFFBgNqq1ztTp5/Ti4RAshnAJ9zAboKz8R5L2EfoQL1wAKGQOQw9QCgnef5 1j15b04Cd6zwyWYsR8AmDC4= =pkVF -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GIMP 1.2 has gotta die
Am Dienstag, 12. September 2006 02:46 schrieb Michael Cummings: Looks like that will break media-gfx/frontline (=media-gfx/gimp-1.2*) and gimp-freetype-0.2-r3 (also =media-gfx/gimp-1.2*). frontline is dead upstream, has no metadata and last changelog-entry is about a year old, so I suspect there's not much interest in it. gimp-freetype has newer versions stable on all archs, so removal of old versions shouldn't hurt. pgpPJ4zkyXWse.pgp Description: PGP signature
[gentoo-dev] [adopt-a-dev] New Resource Offers and Requests
Below are all of the community member offers and developer requests made in the last 7 days. As always, the full list of offers and requests can be found on our project page http://gentoo.org/proj/en/userrel/adopt-a-dev/index.xml -Thomas Community Member Offers === None this week. New Developer Requests == Resource: A PCI-E SCSI controller (needs to be U160 or better and not wider than PCI-E x4; must have an external connector to use with tape drives) or a SCSI-iSCSI converter Purpose: To maintain iSCSI packages and to maintain a lot of the backup packages dealing with tape drives. Name: Robin Johnson // Location: Burnaby, BC, Canada pgpXZbMjUvYDe.pgp Description: PGP signature
Re: [gentoo-dev] Last rites for www-apps/drupal
Alec Warner wrote:
Stuart Herbert wrote:
On 9/11/06, Jakub Moc [EMAIL PROTECTED] wrote:
Uhm, web-apps has been CCed on the bug since the beginning. Last time I
asked, noone wanted to touch the FUBARed ebuild, IIRC. :)
The package was masked without Christel (on behalf of QA) posting an
advance warning of their actions. That's not trying to work together.
It's not trying to work with existing teams.
So file a complaint; once again the -dev list shouldn't be for
complaining about how people {suck,don't follow policy}
Why are you so file a complaint happy lately? Isn't it the general
idea (and maybe even documented on our site) that people are supposed to
work out the issues before you go to the complaint phase? I really don't
like the idea of us opting for filing a compliant rather than work with
the person individually first.
You can always revert the mask also; most developers have cvs commit
access (I know you do).
--
Lance Albertson [EMAIL PROTECTED]
Gentoo Infrastructure | Operations Manager
---
GPG Public Key: http://www.ramereth.net/lance.asc
Key fingerprint: 0423 92F3 544A 1282 5AB1 4D07 416F A15D 27F4 B742
ramereth/irc.freenode.net
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] Last rites for www-apps/drupal
Lance Albertson wrote:
Alec Warner wrote:
Stuart Herbert wrote:
On 9/11/06, Jakub Moc [EMAIL PROTECTED] wrote:
Uhm, web-apps has been CCed on the bug since the beginning. Last time I
asked, noone wanted to touch the FUBARed ebuild, IIRC. :)
The package was masked without Christel (on behalf of QA) posting an
advance warning of their actions. That's not trying to work together.
It's not trying to work with existing teams.
So file a complaint; once again the -dev list shouldn't be for
complaining about how people {suck,don't follow policy}
Why are you so file a complaint happy lately? Isn't it the general
idea (and maybe even documented on our site) that people are supposed to
work out the issues before you go to the complaint phase? I really don't
like the idea of us opting for filing a compliant rather than work with
the person individually first.
I should perhaps change my wording; I don't want to see 'bitching' on
this list; declaring to the entire community that person X broke
policy or that person Y sucks at life is pointless in most cases. If
they did something wrong, inform them about it. If they repeatedly
break policy, inform their lead. I just don't want to see it on list.
So if it shows up, that will be my response.
Sorry if it seemed like I'm trying to make devrel have too many cases,
I'm just tired of seeing the bickering here.
-Alec Warner
--
gentoo-dev@gentoo.org mailing list
