Re: [gentoo-dev] Re: renaming gentoo-oldnet
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Mon, 5 Aug 2013 05:20:32 + (UTC) Duncan <1i5t5.dun...@cox.net> wrote: > Exactly. That's why I like it. netrc is generic enough to be used > elsewhere, yet descriptive enough of what it actually does, that from > my perspective anyway, it's perfect. =:^) Probably not a big deal, but there is a “~/.netrc” file which holds usernames and password for various services (some FTP clients use it, maybe others). Chris -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) iF4EAREIAAYFAlH/OSYACgkQnfE3lq0v9IzItAEAh2t+7HZKTthl0im5aMtIp3AQ nDfQkCOetZMyXEqvRGAA/05+NalxmSIn5FkkNK5+MeVrMydToxFfctROFy8FeS4U =cPcz -END PGP SIGNATURE-
[gentoo-dev] Re: renaming gentoo-oldnet
Michael Orlitzky posted on Sun, 04 Aug 2013 18:30:33 -0400 as excerpted: > On 08/04/2013 06:20 PM, William Hubbs wrote: >> On Sun, Aug 04, 2013 at 10:15:35PM +, Duncan wrote: >>> Michael Orlitzky posted on Sun, 04 Aug 2013 18:01:40 -0400 as >>> excerpted: >>> Since it was pulled out of openrc, the name "netrc" also suggests itself. >>> >>> I like it, if it's not taken elsewhere and will thus cause problems. >> >> Maybe, but then when it is ported to other init systems (someone was >> even talking about adding functionality so it would work under systemd) >> a name that ties it to OpenRc doesn't make sense. >> > It's not tied to openrc, any more than e.g. openvpn is tied to badvpn. > That's what they are, network rc scripts. Exactly. That's why I like it. netrc is generic enough to be used elsewhere, yet descriptive enough of what it actually does, that from my perspective anyway, it's perfect. =:^) -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
Re: [gentoo-dev] renaming gentoo-oldnet
On Sun, Aug 04, 2013 at 06:54:33PM -0700, Brian Dolbec wrote: > On Sun, 2013-08-04 at 15:37 -0500, William Hubbs wrote: > > Doug and Brian, I'm going to reply in a little more detail. > > > > On Sat, Aug 03, 2013 at 07:38:04PM -0700, Brian Dolbec wrote: > > > On Sat, 2013-08-03 at 21:03 -0500, Doug Goldstein wrote: > > > > On Sat, Aug 3, 2013 at 7:30 PM, William Hubbs > > > > wrote: > > > > > On Sun, Aug 04, 2013 at 01:49:46AM +0300, Alon Bar-Lev wrote: > > > > >> On Sun, Aug 4, 2013 at 1:38 AM, William Hubbs > > > > >> wrote: > > > > > > > >> OK... so gentoo-networking? or just come up with own name? > > > > >> best-networking? > > > > > > > > > > > How about gen-net? It's nice, short and the name is more flexible if > > > the pkg is picked up by other distros (something bantied about during > > > previous discussions). > > > > Hmm, that is a little too cryptic maybe... Is gen "Gentoo? General? > > Generic?" > > > OK. that was the point like mgorny said. To keep Gentoo out of the name > so it is more likely to be picked up by other distros due to it's ease > of use and flexibility. > > Since it is so flexible and handle so many configurations... > > How about Multi-net? ;) (just one more for the fray...) :p I'm actually thinking netrc if Robin is ok with it. William signature.asc Description: Digital signature
Re: [gentoo-dev] renaming gentoo-oldnet
On Sun, 2013-08-04 at 15:37 -0500, William Hubbs wrote: > Doug and Brian, I'm going to reply in a little more detail. > > On Sat, Aug 03, 2013 at 07:38:04PM -0700, Brian Dolbec wrote: > > On Sat, 2013-08-03 at 21:03 -0500, Doug Goldstein wrote: > > > On Sat, Aug 3, 2013 at 7:30 PM, William Hubbs wrote: > > > > On Sun, Aug 04, 2013 at 01:49:46AM +0300, Alon Bar-Lev wrote: > > > >> On Sun, Aug 4, 2013 at 1:38 AM, William Hubbs > > > >> wrote: > > > > > >> OK... so gentoo-networking? or just come up with own name? > > > >> best-networking? > > > > > > > > How about gen-net? It's nice, short and the name is more flexible if > > the pkg is picked up by other distros (something bantied about during > > previous discussions). > > Hmm, that is a little too cryptic maybe... Is gen "Gentoo? General? > Generic?" OK. that was the point like mgorny said. To keep Gentoo out of the name so it is more likely to be picked up by other distros due to it's ease of use and flexibility. Since it is so flexible and handle so many configurations... How about Multi-net? ;) (just one more for the fray...) And yes, as dilfridge said, William, Robin, PLEASE end the bikeshed and pick a decent name. Almost anything is better than having "old" in it. > > > > If we lose that flexibility and configurability then just give up on > > > OpenRC right now cause its dead because all interesting features are > > > gone and it'll just become an inferior init system that needs to be > > > replaced. > > > > > > > ++ > > As I have said before, none of this is an attempt to kill or deprecate > anything. It is just re-arranging things by moving the old gentoo > network stack into its own package. There are no plans to stop you from > using it if you want to use it. There is definitely nothing being said > here about the state of OpenRc in general. > > William hmm, re-reading that, I was off the way I ++'d it. I know there are no plans to drop support for it. What I was plus-ing was more the fact that with the oldnet naming, it is more and more likely for users to migrate away from it. After all, it's the old way as it's name suggests. With that happening, there will be less and less need for openrc. And openrc dieing a slow death. P.S. no need to expand further on this. It was just a clarification Long Live OpenRC!!! :D -- Brian Dolbec signature.asc Description: This is a digitally signed message part
Maintainer decides (was: Re: [gentoo-dev] renaming gentoo-oldnet)
Am Sonntag, 4. August 2013, 22:37:50 schrieb William Hubbs: (...) Dear William, I think we have come to the point where we all realize that * any other name is better than oldnet * there are several possible new names * and (as frequently) decision by discussion does not really work. (This is now about the umpteenth discussion of the same annoyingly trivial topic.) So how about *you* as the primary maintainer just pick a name which you think is best and we then go with it? Cheers, Andreas -- Andreas K. Huettel Gentoo Linux developer (council, kde) dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2013-08-04 23h59 UTC
The attached list notes all of the packages that were added or removed from the tree, for the week ending 2013-08-04 23h59 UTC. Removals: media-tv/tvtime 2013-08-02 19:17:51 ssuominen dev-python/twisted 2013-08-03 09:50:21 mgorny Additions: app-text/discount 2013-07-29 04:55:01 binki dev-perl/Tie-Hash-Method2013-07-29 14:47:02 zlogene app-crypt/codecrypt 2013-07-29 14:48:48 yac app-emacs/d-mode2013-07-29 21:19:15 ulm sys-apps/gentoo-systemd-integration 2013-07-29 21:43:10 mgorny dev-python/pyutil 2013-08-01 01:37:06 hasufell dev-python/zbase32 2013-08-01 01:40:51 hasufell dev-python/zfec 2013-08-01 01:54:43 hasufell net-fs/tahoe-lafs 2013-08-01 13:02:05 hasufell dev-libs/libuv 2013-08-01 16:06:11 hasufell games-board/gnome-mahjongg 2013-08-01 18:31:05 pacho dev-ruby/launchy2013-08-02 06:15:15 mrueg net-misc/rancid-git 2013-08-02 22:45:58 xmw dev-python/twisted-core 2013-08-03 09:34:50 mgorny dev-perl/Unicode-LineBreak 2013-08-03 17:59:39 mrueg dev-perl/Config-AutoConf2013-08-03 18:11:34 mrueg dev-perl/ExtUtils-LibBuilder2013-08-03 20:05:40 mrueg dev-perl/Text-BibTeX2013-08-03 20:46:54 mrueg net-p2p/retroshare 2013-08-03 23:20:51 hasufell dev-perl/Encode-EUCJPASCII 2013-08-04 01:11:35 mrueg dev-perl/Encode-JIS2K 2013-08-04 01:20:31 mrueg net-im/dianara 2013-08-04 16:53:28 hasufell sci-mathematics/bertini 2013-08-04 20:03:02 tomka -- Robin Hugh Johnson Gentoo Linux Developer E-Mail : robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 Removed Packages: media-tv/tvtime,removed,ssuominen,2013-08-02 19:17:51 dev-python/twisted,removed,mgorny,2013-08-03 09:50:21 Added Packages: app-text/discount,added,binki,2013-07-29 04:55:01 dev-perl/Tie-Hash-Method,added,zlogene,2013-07-29 14:47:02 app-crypt/codecrypt,added,yac,2013-07-29 14:48:48 app-emacs/d-mode,added,ulm,2013-07-29 21:19:15 sys-apps/gentoo-systemd-integration,added,mgorny,2013-07-29 21:43:10 dev-python/pyutil,added,hasufell,2013-08-01 01:37:06 dev-python/zbase32,added,hasufell,2013-08-01 01:40:51 dev-python/zfec,added,hasufell,2013-08-01 01:54:43 net-fs/tahoe-lafs,added,hasufell,2013-08-01 13:02:05 dev-libs/libuv,added,hasufell,2013-08-01 16:06:11 games-board/gnome-mahjongg,added,pacho,2013-08-01 18:31:05 dev-ruby/launchy,added,mrueg,2013-08-02 06:15:15 net-misc/rancid-git,added,xmw,2013-08-02 22:45:58 dev-python/twisted-core,added,mgorny,2013-08-03 09:34:50 dev-perl/Unicode-LineBreak,added,mrueg,2013-08-03 17:59:39 dev-perl/Config-AutoConf,added,mrueg,2013-08-03 18:11:34 dev-perl/ExtUtils-LibBuilder,added,mrueg,2013-08-03 20:05:40 dev-perl/Text-BibTeX,added,mrueg,2013-08-03 20:46:54 net-p2p/retroshare,added,hasufell,2013-08-03 23:20:51 dev-perl/Encode-EUCJPASCII,added,mrueg,2013-08-04 01:11:35 dev-perl/Encode-JIS2K,added,mrueg,2013-08-04 01:20:31 net-im/dianara,added,hasufell,2013-08-04 16:53:28 sci-mathematics/bertini,added,tomka,2013-08-04 20:03:02 Done.
Re: [gentoo-dev] newsitem: Kernel Team vanilla-sources policy
On 04/08/13 11:29 PM, Mike Pagano wrote: > On Sunday, August 04, 2013 07:24:23 PM Alex Xu wrote: > >> wat. Possibly intended: >>> For the latest upstream kernel unpatched by Gentoo > > Not intended > --- > > > Title: vanilla-sources stabilization policy > Author: Mike Pagano > Content-Type: text/plain > Posted: 2013-08-07 > Revision: 1 > News-Item-Format: 1.0 > Display-If-Installed: sys-kernel/vanilla-sources > > The Gentoo Kernel Team will no longer be providing stable > vanilla-sources kernels. All currently stabilized vanilla-sources > versions will be dropped to ~arch. The Arch teams, via normal requests > of the Kernel Team, will continue to stabilize gentoo-sources kernels > upon request. This decision is based on the facts that upstream is now > releasing approximately 1-2 vanilla-sources kernels a week. Arch teams, > understandably, are unable to keep up with this rate of release. As > most vanilla releases contain security fixes, the user who only runs > stable vanilla-sources will consistently be behind and potentially at > risk. For the latest "upstream kernel unpatched by Gentoo", we still not sure that the quotes are really needed here, but it's not a big issue > recommend users add 'sys-kernel/vanilla-sources' to their > package.accept_keywords file. gentoo-sources will continue to be a > tested and supported version for Gentoo users. > > > Note: This news item only applies to gentoo-sources and vanilla-sources. > Other kernels currently maintained in portage have their own policies > and procedures in place today. > > > LGTM otherwise. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] newsitem: Kernel Team vanilla-sources policy
On Sunday, August 04, 2013 07:24:23 PM Alex Xu wrote: > wat. Possibly intended: > > For the latest upstream kernel unpatched by Gentoo Not intended --- Title: vanilla-sources stabilization policy Author: Mike Pagano Content-Type: text/plain Posted: 2013-08-07 Revision: 1 News-Item-Format: 1.0 Display-If-Installed: sys-kernel/vanilla-sources The Gentoo Kernel Team will no longer be providing stable vanilla-sources kernels. All currently stabilized vanilla-sources versions will be dropped to ~arch. The Arch teams, via normal requests of the Kernel Team, will continue to stabilize gentoo-sources kernels upon request. This decision is based on the facts that upstream is now releasing approximately 1-2 vanilla-sources kernels a week. Arch teams, understandably, are unable to keep up with this rate of release. As most vanilla releases contain security fixes, the user who only runs stable vanilla-sources will consistently be behind and potentially at risk. For the latest "upstream kernel unpatched by Gentoo", we recommend users add 'sys-kernel/vanilla-sources' to their package.accept_keywords file. gentoo-sources will continue to be a tested and supported version for Gentoo users. Note: This news item only applies to gentoo-sources and vanilla-sources. Other kernels currently maintained in portage have their own policies and procedures in place today. -- Mike Pagano Gentoo Developer - Kernel Project E-Mail : mpag...@gentoo.org GnuPG FP : EEE2 601D 0763 B60F 848C 9E14 3C33 C650 B576 E4E3 Public Key : http://pgp.mit.edu:11371/pks/lookup?search=0xB576E4E3&op=index
Re: [gentoo-dev] newsitem: Kernel Team vanilla-sources policy
Further minor grammar/typographical errata: On 04/08/13 11:16 PM, Mike Pagano wrote: > Title: vanilla-sources stabilization policy > Author: Mike Pagano > Content-Type: text/plain > Posted: 2013-08-07 > Revision: 1 > News-Item-Format: 1.0 > Display-If-Installed: sys-kernel/vanilla-sources > > The Gentoo Kernel Team will no longer be providing stable > vanilla-sources kernels. All currently stabilized vanilla-sources > versions will be dropped to ~arch. The Arch teams, via normal requests > of the Kernel Team, will continue to stabilize gentoo-sources kernels > upon request. This decision is based on the facts that upstream is now > releasing approximately 1-2 vanilla-sources kernels a week. Arch teams, > understandably, are unable to keep up with this rate of release. As > most vanilla releases contain security fixes, the user who only runs > stable vanilla-sources will consistently be behind and potentially at > risk. For the latest "upstream kernel unpatched by Gentoo" kernel, we > "upstream kernel unpatched by Gentoo" kernel wat. Possibly intended: > For the latest upstream kernel unpatched by Gentoo > recommend users add 'sys-kernel/vanilla-sources' to their > package.accept_keywords file. gentoo-sources will continue to be a > tested and supported version for Gentoo users. > > > Note: This news item only applies to gentoo-sources and vanilla-sources. > Other kernels currently maintained in portage have their own policies > and procedures in place toda toda? derp. "today" or just remove it. s/\. /. /g or s/\. ([^ ])/. \1/g (consistently use one space between sentences or two) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] newsitem: Kernel Team vanilla-sources policy
On Sunday, August 04, 2013 07:45:47 AM Rich Freeman wrote: > On Sun, Aug 4, 2013 at 7:16 AM, Ben de Groot wrote: > > On 4 August 2013 09:56, Alex Xu wrote: > >> Minor grammar/typographical errata: > >> snip Thanks, everyone for helping out. Here is the latest with some of the requested changes: Title: vanilla-sources stabilization policy Author: Mike Pagano Content-Type: text/plain Posted: 2013-08-07 Revision: 1 News-Item-Format: 1.0 Display-If-Installed: sys-kernel/vanilla-sources The Gentoo Kernel Team will no longer be providing stable vanilla-sources kernels. All currently stabilized vanilla-sources versions will be dropped to ~arch. The Arch teams, via normal requests of the Kernel Team, will continue to stabilize gentoo-sources kernels upon request. This decision is based on the facts that upstream is now releasing approximately 1-2 vanilla-sources kernels a week. Arch teams, understandably, are unable to keep up with this rate of release. As most vanilla releases contain security fixes, the user who only runs stable vanilla-sources will consistently be behind and potentially at risk. For the latest "upstream kernel unpatched by Gentoo" kernel, we recommend users add 'sys-kernel/vanilla-sources' to their package.accept_keywords file. gentoo-sources will continue to be a tested and supported version for Gentoo users. Note: This news item only applies to gentoo-sources and vanilla-sources. Other kernels currently maintained in portage have their own policies and procedures in place toda -- Mike Pagano Gentoo Developer - Kernel Project E-Mail : mpag...@gentoo.org GnuPG FP : EEE2 601D 0763 B60F 848C 9E14 3C33 C650 B576 E4E3 Public Key : http://pgp.mit.edu:11371/pks/lookup?search=0xB576E4E3&op=index
Re: [gentoo-dev] renaming gentoo-oldnet
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/04/2013 06:36 PM, Michał Górny wrote: > >> Since it was pulled out of openrc, the name "netrc" also suggests >> itself. > > 'net run control'? > Sounds about right. We can say it's "net run configuration" if that's better politically. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) iQIcBAEBAgAGBQJR/toJAAoJEBxJck0inpOib+IP/jY21p4k4FGB3PvV8l2x+seX RJRii0riobrN+Mg2ex1YsQxhJcFIPMlsmM0lUpxeb6paqJPgXXryNz4ACEh9BAnk qMOzdVO8U2Bdm5Tlaq+m0uzxsNrpRnmfu7E6V0duDaclTGwIX8g8fVAZDx0nwbeO lpcabi8eus2UKgtufn92MLAQB8eD7Wimv84pyPVOqDlriDuaqpmoHmRypanz63I2 iCvbsXOFF65z4bJByt1+pg5SOwx+KJox7AN/uptqyoK58NhpxB+AtTyT9A7+efYz saadV29FECjB8TBP87upbvZZ9J9OlxZ6uC+RoIxxpWPA+zyZao+exlsTPAcjA9bd vSWSBU78YWDuv6qXOkEfh6qW+DSz3/J67bjCfW60VtfrHOXw5/M5ttnta3uzDzdL DyPvNDo2d+Kj8blZwmYxhCzq+k91NyTz+10MJU0tIXFdK14OlRwothzgcojaXOfb ILeYpZnZTARk/pZtoZhbzRPoXLuBVzEFF1Uh1bcaAdAKS9FRfa+VJXhoHQpBkb4K GoP1I2y3JB0kTy4J0O9phKNGSeyvmUqD2S6R3AV3bYYbovr04IumMUVEppEMJ+ko EQxE2UuLFT8zxdwiNLw+DV7cjgbvRhI7DdKnUhb6Srpo0KDF/BylxAPVggKVwo8O q8pLLEDgjAz532vOy3yE =/j3g -END PGP SIGNATURE-
Re: [gentoo-dev] renaming gentoo-oldnet
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Dnia 2013-08-04, o godz. 18:01:40 Michael Orlitzky napisał(a): > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 08/04/2013 04:37 PM, William Hubbs wrote: > > > > I thought about gentoo-networking, but that sucks in a way too > > because it implies that everyone on gentoo should be using it. > > > > ... > > > >> How about gen-net? It's nice, short and the name is more > >> flexible if the pkg is picked up by other distros (something > >> bantied about during previous discussions). > > > > Hmm, that is a little too cryptic maybe... Is gen "Gentoo? > > General? Generic?" > > > > Since it was pulled out of openrc, the name "netrc" also suggests itself. 'net run control'? - -- Best regards, Michał Górny -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) iQJ8BAEBCgBmBQJR/teDXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ1RUJGMjBGOTk2RkIzQzIyQ0M2RkNBNDBC QUJGMUQ1RkY4QzgxMTBBAAoJELq/HV/4yBEKrxoQAN91GDdW5NkSGnckg3Roh8pc 0fD2061Lj0RgKQntKvhV/Tx/LkTv52oHSXHTlEAakzjkeFi6cNEKJOC0APNNmeco IOBqBaSbqAcjVfpk/BbMsQ/zkk0eRuxBCvnF+0IqE9pjNNn8DPe19IDLABuErHG3 bSWm8dsyCvwmNvXvlkVKD1PYnLyJxhYvoEOHUIodLGueDd0b/s8FQf4IMccOe2lq mwOcqflHCjpCyVLt77oniuhUWqkXpEm9XHPUQufZ0xmCY30Vmv9trZsIFTJ1RN07 qaFD4cP5BlHpWNrqqjx8+3R0jckabVP34eQogmO1s5NSdAWKOXuP41Lb7y5TQlBE oHDcWcEY/qnoF6KB+4kXoejVltcVHho3u3XV1g4fc6xULuGN9cRRj6EjLUifaUdV gkX7NvO2h6wPYFb7I1N0q9MkN8FHp9JimFvHnxlPikKwM62xxs68dK0XRa5QZ+4V upacGKloSigltOmubbfggs0GQdZRxdtNAnIyCsKk/0t7ZEg+qqUOeUePMWdZpnzI bHpgpVLmK8ZGsxTfXsEiN76+O0fjW7uRt2kkA4c0UnGaztsZSg187Br/5ZuuQ1SC 0sTWalHwnM8sTyHyVuArux9E+NlqzOj1YFSUDJD7w1xdiG6Vxv4wuLEzPGxJTX2P NEk6ADQUDW7gmClQrHQO =tnpg -END PGP SIGNATURE-
Re: [gentoo-dev] Re: renaming gentoo-oldnet
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/04/2013 06:20 PM, William Hubbs wrote: > On Sun, Aug 04, 2013 at 10:15:35PM +, Duncan wrote: >> Michael Orlitzky posted on Sun, 04 Aug 2013 18:01:40 -0400 as >> excerpted: >> >>> Since it was pulled out of openrc, the name "netrc" also >>> suggests itself. >> >> I like it, if it's not taken elsewhere and will thus cause >> problems. > > Maybe, but then when it is ported to other init systems (someone > was even talking about adding functionality so it would work under > systemd) a name that ties it to OpenRc doesn't make sense. > It's not tied to openrc, any more than e.g. openvpn is tied to badvpn. That's what they are, network rc scripts. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) iQIcBAEBAgAGBQJR/tYJAAoJEBxJck0inpOiVlMP/RCLt5lOHCoiHQ0k/0OZK0Vo NgHZCqUN/pfx52jCofrQNHBu/S0AP0pkgMa7H6CeWOxM75Qx9GUNyQwqnI8lzEdu mKdziH/frHUYV6ze+Ue417lxXkqxp3X472zAdbv1cPZslaik09NBxAJdeQOCs23Y 5VKYPoJvmpyQo144BchfZzpX/jpoAuVEE52j7474Wfe6RxPP8mXxiujWl/lk7ZOU k2vzhXNWKB2tt8NHREszEgdEMb3QUe3V1zy5csWCquNg63QP98S8SU0uu6hjqv9r /N7U/yf0VMvOM+BVoVO1VdTigGVDAwPNav7Tm2ztSlCWcpUdSna0Q1PMtpXkRpiQ YimlcVE60Z/e2uqLQ2wqlhX7veZKuvgR2idZ679mA/pVpqBRYMQ0xkQsVebZPlb1 8ug7MNgmcjJzdBb3hFp6L62abFqcQungK1k6WOjlIvxxR70VG/PeEluEgv/WU4/U m151Rz6s0MicalmwfE/sqzHpCIRumU03C9y3vX+goZnVpVt04gpQDfW4Q7yakFh+ s543EvQWgu5VpSOxDhYC394WwLBIqelNwvvr1E4mNNRDLsBJxbaDYLBsTRTUtdR1 H3L8XbBDr+PbglH+2R+N8A/hnnONEbfthniGmCyn02tl92WhkUClFt05S4iBP9nS //2jZfo8oF0GhsDmRP0X =vQmC -END PGP SIGNATURE-
Re: [gentoo-dev] Re: renaming gentoo-oldnet
On Sun, Aug 04, 2013 at 10:15:35PM +, Duncan wrote: > Michael Orlitzky posted on Sun, 04 Aug 2013 18:01:40 -0400 as excerpted: > > > Since it was pulled out of openrc, the name "netrc" also suggests > > itself. > > I like it, if it's not taken elsewhere and will thus cause problems. Maybe, but then when it is ported to other init systems (someone was even talking about adding functionality so it would work under systemd) a name that ties it to OpenRc doesn't make sense. William signature.asc Description: Digital signature
[gentoo-dev] Re: renaming gentoo-oldnet
Michael Orlitzky posted on Sun, 04 Aug 2013 18:01:40 -0400 as excerpted: > Since it was pulled out of openrc, the name "netrc" also suggests > itself. I like it, if it's not taken elsewhere and will thus cause problems. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
Re: [gentoo-dev] renaming gentoo-oldnet
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/04/2013 04:37 PM, William Hubbs wrote: > > I thought about gentoo-networking, but that sucks in a way too > because it implies that everyone on gentoo should be using it. > > ... > >> How about gen-net? It's nice, short and the name is more >> flexible if the pkg is picked up by other distros (something >> bantied about during previous discussions). > > Hmm, that is a little too cryptic maybe... Is gen "Gentoo? > General? Generic?" > Since it was pulled out of openrc, the name "netrc" also suggests itself. > As I have said before, none of this is an attempt to kill or > deprecate anything. It is just re-arranging things by moving the > old gentoo network stack into its own package. There are no plans > to stop you from using it if you want to use it. There is > definitely nothing being said here about the state of OpenRc in > general. I admit when I first saw the name a few weeks ago I thought "oh shit they're going to make me redo all of my network configs." Google cleared it up, but still. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) iQIcBAEBAgAGBQJR/s9EAAoJEBxJck0inpOiCqIP/0b5+yJgrEsk3jLsaceiypdF 94fj1Kq+tFMSctI6Jw8N/2gECTuk8pcTZHLWR++9Co4I37OpxZ4IKAiI7gaznU4e aPNVKd24dXy5ajnnSjTlD0m/S1ppMPZk8g4vmK3beod10KVdNCSuEEMNMq4c5pO7 uBWb8kww8YrCU1VaoGo90YHD+LY+hTaBgQDa5hr/TEZforRc5KP3BuMZCB3ONAwm Nw+uOiCB8dM+B54qmAfx+AsBNbPRrDGZzFIat0eCAiTix6scGY6m5/h7j7ZkNRoK YkMRCDfS1z/UQgHw9YOdLqr3TyM8Lq7jmqiEL+mb+iM4JNHKCtNo2q3JXHIT/1Wi qF1vD4TjC8Qom6Fyxm6InyKREqt4GVFw2eUS+V7+SxumgPsqGZ9Utx5SGVL2/+4h qwc+xp9tD5OJ02dK6eCWF+Q3sS1RdgprZu0h05rmMw6vGNZ7AokbOymyuo5Xoxu1 M+PlFHTrg8ETjetI+dRe3FQ5nTLdqmUw0mPqcbtPfEe5KzVbyJHlz2L7PTYGhtug tapJz1RjrPBwDJRtn/JIULvbUQHKg1sZwOv6K0FmJzLchticAUfaF7Puk6MOQvno yufIpNHjt/IfGyYNlELSmuWPHaAbGBCR/IbW1hwnFBf+NRXS1SIpjye8Fx2Y/cxh wK1JnALTBINNyvwoCfJj =M2rV -END PGP SIGNATURE-
Re: [gentoo-dev] renaming gentoo-oldnet
On Sun, Aug 4, 2013 at 11:37 PM, William Hubbs wrote: > > Doug and Brian, I'm going to reply in a little more detail. > > On Sat, Aug 03, 2013 at 07:38:04PM -0700, Brian Dolbec wrote: > > On Sat, 2013-08-03 at 21:03 -0500, Doug Goldstein wrote: > > > On Sat, Aug 3, 2013 at 7:30 PM, William Hubbs wrote: > > > > On Sun, Aug 04, 2013 at 01:49:46AM +0300, Alon Bar-Lev wrote: > > > >> On Sun, Aug 4, 2013 at 1:38 AM, William Hubbs > > > >> wrote: > > > > > >> OK... so gentoo-networking? or just come up with own name? > > > >> best-networking? > > > > > > > > > You and I have had this talk more times than I can remember at this > > > point. Using the name "oldnet" sucks and was one of the worst choices > > > possible. Looking through our IRC chats, I had also suggested > > > gentoo-networking. > > I thought about gentoo-networking, but that sucks in a way too because > it implies that everyone on gentoo should be using it. > > That's not quite right because we have at least five network stacks I > can think of off the top of my head, and OpenRc upstream supports > another. > > - OpenRc upstream supports newnet, which I have played with, and I > believe people on Gentoo are using successfully. > - what we have been calling the oldnet stack, which most gentoo users > have been using. > - dhcpcd in standalone mode. > - wicd > - NetworkManager > - badvpn I do not understand... the 'old net' which is actually gentoo networking for years, are fully functional script to manage and create a lot of configurations, and one of the advantages we have at Gentoo over other distributions. The only reason why this is called old net is because Roy switched to *BSD. What you call new net requires vast knowledge in network tools usage and interaction, which makes life very difficult. Some examples I managed to document: http://alonbl.tropicalwikis.com/wiki/Gentoo/Firewall_Using_Firehol http://alonbl.tropicalwikis.com/wiki/Gentoo/OpenVPN_Server http://alonbl.tropicalwikis.com/wiki/Gentoo/OpenVPN_Non_Root http://alonbl.tropicalwikis.com/wiki/Gentoo/Vpnc_Non_Root http://alonbl.tropicalwikis.com/wiki/Gentoo/VM_Tap_Networking http://alonbl.tropicalwikis.com/wiki/Gentoo/PPP_Client http://alonbl.tropicalwikis.com/wiki/Gentoo/PPPoE_Client > As I have said before, none of this is an attempt to kill or deprecate > anything. It is just re-arranging things by moving the old gentoo > network stack into its own package. There are no plans to stop you from > using it if you want to use it. There is definitely nothing being said > here about the state of OpenRc in general. >From behind the words it indeed looks like there is a change coming. Alon
Re: [gentoo-dev] renaming gentoo-oldnet
Dnia 2013-08-04, o godz. 15:37:50 William Hubbs napisał(a): > Doug and Brian, I'm going to reply in a little more detail. > > > How about gen-net? It's nice, short and the name is more flexible if > > the pkg is picked up by other distros (something bantied about during > > previous discussions). > > Hmm, that is a little too cryptic maybe... Is gen "Gentoo? General? > Generic?" I think that's the goal. Like 'we know it's for Gentoo, but sounds like generic'. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] renaming gentoo-oldnet
Doug and Brian, I'm going to reply in a little more detail. On Sat, Aug 03, 2013 at 07:38:04PM -0700, Brian Dolbec wrote: > On Sat, 2013-08-03 at 21:03 -0500, Doug Goldstein wrote: > > On Sat, Aug 3, 2013 at 7:30 PM, William Hubbs wrote: > > > On Sun, Aug 04, 2013 at 01:49:46AM +0300, Alon Bar-Lev wrote: > > >> On Sun, Aug 4, 2013 at 1:38 AM, William Hubbs > > >> wrote: > > > >> OK... so gentoo-networking? or just come up with own name? > > >> best-networking? > > > > > > You and I have had this talk more times than I can remember at this > > point. Using the name "oldnet" sucks and was one of the worst choices > > possible. Looking through our IRC chats, I had also suggested > > gentoo-networking. I thought about gentoo-networking, but that sucks in a way too because it implies that everyone on gentoo should be using it. That's not quite right because we have at least five network stacks I can think of off the top of my head, and OpenRc upstream supports another. - OpenRc upstream supports newnet, which I have played with, and I believe people on Gentoo are using successfully. - what we have been calling the oldnet stack, which most gentoo users have been using. - dhcpcd in standalone mode. - wicd - NetworkManager - badvpn > How about gen-net? It's nice, short and the name is more flexible if > the pkg is picked up by other distros (something bantied about during > previous discussions). Hmm, that is a little too cryptic maybe... Is gen "Gentoo? General? Generic?" > > If we lose that flexibility and configurability then just give up on > > OpenRC right now cause its dead because all interesting features are > > gone and it'll just become an inferior init system that needs to be > > replaced. > > > > ++ As I have said before, none of this is an attempt to kill or deprecate anything. It is just re-arranging things by moving the old gentoo network stack into its own package. There are no plans to stop you from using it if you want to use it. There is definitely nothing being said here about the state of OpenRc in general. William signature.asc Description: Digital signature
Re: [gentoo-dev] bertini license
On 07/29/2013 02:58 PM, Thomas Kahle wrote: > Hi, > > I just added the license 'bertini' to the non-free group. Bertini is a > math software distributed in source form but with restriction on > redistribution (no fee is allowed, no modifications may be > redisitributed). The way I read clause 2, I think we are allowed to > distribute the source code on the mirrors. The ebuild is > sci-mathematics/bertini which I'll add soon. I just added sci-mathematics/bertini to the tree. I talked to the upstream developers the other day and their main concern is somebody taking the code and making money with it. Another concern is that changed versions of the source code may give incorrect results and ruin their reputation. I personally would say that the GPL would protect them, but in the end it is their choice. They assured me that the relation to distributions is a friendly one and they welcome bug reports and patches upstream. Cheers, Thomas -- Thomas Kahle signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [New eclass] twisted-r1.eclass
Dnia 2013-08-03, o godz. 17:13:03
Michał Górny napisał(a):
> We've been working with yac for a while to get the old twisted.eclass
> converted to be compliant with distutils-r1 both in design
> and in spirit. This is the first version we'd like to submit for review.
Following comments from marienz:
1. Restored the other subshell obtaining TWISTED_PN from
_twisted_camelcase,
2. Fixed handling empty TWISTED_PLUGINS,
3. Added integrity check for TEST_DIR consistency,
4. Made TWISTED_P* & HTML_DOCS overridable,
5. Added TWISTED_RELEASE that contains major+minor version as it's used
to build SRC_URI and often in dependencies,
6. Improved docs.
--
Best regards,
Michał Górny
# Copyright 1999-2013 Gentoo Foundation
# Distributed under the terms of the GNU General Public License, v2 or later
# $Header: /var/cvsroot/gentoo-x86/eclass/twisted.eclass,v 1.10 2011/12/27
06:54:23 floppym Exp $
# @ECLASS: twisted-r1.eclass
# @MAINTAINER:
# Gentoo Python Project
# @AUTHOR:
# Author: MichaŠGórny
# Author: Jan Matejka
# @BLURB: Eclass for Twisted packages
# @DESCRIPTION:
# The twisted eclass defines phase functions for Twisted packages.
case "${EAPI:-0}" in
0|1|2|3)
die "Unsupported EAPI=${EAPI:-0} (too old) for ${ECLASS}"
;;
4|5)
;;
*)
die "Unsupported EAPI=${EAPI} (unknown) for ${ECLASS}"
;;
esac
if [[ ! ${_TWISTED_R1} ]]; then
inherit distutils-r1 versionator
fi # ! ${_TWISTED_R1}
EXPORT_FUNCTIONS src_install pkg_postinst pkg_postrm
if [[ ! ${_TWISTED_R1} ]]; then
# @FUNCTION: _twisted-r1_camelcase
# @USAGE:
# @DESCRIPTION:
# Convert dash-separated to CamelCase name suitable for Twisted.
# In pure bash, therefore safe for global scope execution.
_twisted-r1_camelcase() {
local IFS=-
# IFS=- splits words by -.
local words=( ${1} )
# we can't keep '-' as it collides with [a-z] check
# and '' is used by bash-4 words[*], so let's just set globally
IFS=
if [[ ${BASH_VERSINFO[0]} -ge 4 ]]; then
echo "${words[*]^}"
return
fi
local w LC_COLLATE=C uc='ABCDEFGHIJKLMNOPQRSTUVWXYZ'
local out
for w in "${words[@]}"; do
local fl=${w:0:1}
# Danger: magic starts here. Please close your eyes.
# In base 36, a..z represents digits 10..35. We substract 10
# and get array subscripts for uc.
[[ ${fl} == [a-z] ]] && fl=${uc:36#${fl} - 10:1}
out+=${fl}${w:1}
done
echo "${out}"
}
# @ECLASS-VARIABLE: TWISTED_PN
# @DESCRIPTION:
# The real package name. Default to camel-case conversion of ${PN}.
#
# Example: TwistedCore
: ${TWISTED_PN:=$(_twisted-r1_camelcase ${PN})}
# @ECLASS-VARIABLE: TWISTED_P
# @DESCRIPTION:
# The real package name with version appended.
#
# It is used to build the default SRC_URI and S values.
#
# Example: TwistedCore-1.2.3
: ${TWISTED_P:=${TWISTED_PN}-${PV}}
# @ECLASS-VARIABLE: TWISTED_RELEASE
# @DESCRIPTION:
# The 'release' of Twisted. Defaults to the major & minor version
# number from ${PV}.
#
# It is used to build the default SRC_URI. It may be also used
# in dependencies against other Twisted packages.
#
# Example: 1.2
: ${TWISTED_RELEASE:=$(get_version_component_range 1-2 ${PV})}
HOMEPAGE="http://www.twistedmatrix.com/";
SRC_URI="http://twistedmatrix.com/Releases/${TWISTED_PN}";
SRC_URI="${SRC_URI}/${TWISTED_RELEASE}/${TWISTED_P}.tar.bz2"
LICENSE="MIT"
SLOT="0"
IUSE=""
S=${WORKDIR}/${TWISTED_P}
# @ECLASS-VARIABLE: TWISTED_PLUGINS
# @DESCRIPTION:
# An array of Twisted plugins, whose cache is regenerated
# in pkg_postinst() and pkg_postrm() phases.
#
# If no plugins are installed, set to empty array.
declare -p TWISTED_PLUGINS &>/dev/null || TWISTED_PLUGINS=( twisted.plugins )
# @FUNCTION: twisted-r1_python_test
# @DESCRIPTION:
# The common python_test() implementation that suffices for Twisted
# packages.
twisted-r1_python_test() {
local sitedir=$(python_get_sitedir)
# Copy modules of other Twisted packages from site-packages
# directory to the temporary directory.
local libdir=${BUILD_DIR}/test/lib
mkdir -p "${libdir}" || die
cp -r "${ROOT}${sitedir}"/twisted "${libdir}" || die
# Drop the installed module in case previous version conflicts with
# the new one somehow.
rm -fr "${libdir}/${PN/-//}" || die
distutils_install_for_testing || die
if [[ ${TEST_DIR} != ${BUILD_DIR}/test ]]; then
eqawarn "twisted-r1 integrity check failed."
eqawarn "TEST_DIR: ${TEST_DIR}"
eqawarn "expected: ${BUILD_DIR}/test"
fi
cd "${TEST_DIR}"/lib || die
trial ${PN/-/.} || die "Tests fail with ${EPYTHON}"
}
# @FUNCTION: python_test
# @DESCRIPTION:
# Default python_test() for Twisted packages. If you need to ove
Re: [gentoo-dev] newsitem: Kernel Team vanilla-sources policy
On Sun, Aug 4, 2013 at 7:16 AM, Ben de Groot wrote: > On 4 August 2013 09:56, Alex Xu wrote: >> Minor grammar/typographical errata: >> >> On 04/08/13 12:53 AM, Mike Pagano wrote: >>> kernel, we recommend user add 'sys-kernel/vanilla-sources' to their >> s/user add/adding/;s/their/the/ or similar; "recommend user add" is not >> grammatically correct > > Make that: we recommend the user to add 'sys-kernel/vanilla-sources' to > their package.accept_keywords file. > > (Note: "their" is perfectly correct usage as a gender-neutral reference to a > singular person.) > > Alternatively: we recommend users to add I'd drop the "to": we recommend users add... or we recommend that users add... or we recommend adding ... to your ... file. http://english.stackexchange.com/questions/56993/recommend-you-do-something-or-recommend-you-to-do-something Rich
Re: [gentoo-dev] newsitem: Kernel Team vanilla-sources policy
On 4 August 2013 09:56, Alex Xu wrote: > Minor grammar/typographical errata: > > On 04/08/13 12:53 AM, Mike Pagano wrote: >> The Gentoo Kernel Team will no longer be providing stable vanilla-sources >> kernels. All currently stabilized vanilla-sources versions will be dropped >> to ~arch. The Arch teams, via normal requests of the Kernel Team, will >> continue to stabilize gentoo-sources kernels upon request. This decision is >> based on the facts that upstream is now releasing approximately 1-2 vanilla- > try not to wrap vanilla-sources on the hyphen if possible >> sources kernels a week. Arch teams, understandable, are unable to keep up >> with > s/understandable/understandably/ >> this rate of release. As most vanilla releases contain security fixes, the >> user who only runs stable vanilla-sources will consistently be behind and >> potentially at risk. For the latest upstream non Gentoo patched vanilla > s/non Gentoo patched/non-Gentoo-patched/ or "upstream kernel unpatched > by Gentoo" >> kernel, we recommend user add 'sys-kernel/vanilla-sources' to their > s/user add/adding/;s/their/the/ or similar; "recommend user add" is not > grammatically correct Make that: we recommend the user to add 'sys-kernel/vanilla-sources' to their package.accept_keywords file. (Note: "their" is perfectly correct usage as a gender-neutral reference to a singular person.) Alternatively: we recommend users to add >> package.accept_keywords file. Gentoo-sources will continue to be a tested >> and > s/Gentoo-sources/gentoo-sources/ >> supported version for Gentoo users. > > s/\. /. /g > > (or vice versa) > -- Cheers, Ben | yngwin Gentoo developer
Re: [gentoo-dev] renaming gentoo-oldnet
On 4 August 2013 10:38, Brian Dolbec wrote: > On Sat, 2013-08-03 at 21:03 -0500, Doug Goldstein wrote: >> On Sat, Aug 3, 2013 at 7:30 PM, William Hubbs wrote: >> > On Sun, Aug 04, 2013 at 01:49:46AM +0300, Alon Bar-Lev wrote: >> >> On Sun, Aug 4, 2013 at 1:38 AM, William Hubbs wrote: > >> >> OK... so gentoo-networking? or just come up with own name? >> >> best-networking? >> > > >> You and I have had this talk more times than I can remember at this >> point. Using the name "oldnet" sucks and was one of the worst choices >> possible. Looking through our IRC chats, I had also suggested >> gentoo-networking. > > > How about gen-net? It's nice, short and the name is more flexible if > the pkg is picked up by other distros (something bantied about during > previous discussions). ++ -- Cheers, Ben | yngwin Gentoo developer
Re: [gentoo-dev] newsitem: Kernel Team vanilla-sources policy
On Sun, Aug 04, 2013 at 12:53:35AM -0400, Mike Pagano wrote: > > All, > Here is the vanilla-sources non stablizing policy news item. > If all goes well, this will be committed to the tree on 08/07 UTC. Thanks for writing this all up, much appreciated. greg k-h
Re: [gentoo-dev] newsitem: Kernel Team vanilla-sources policy
> On Sun, 04 Aug 2013, Mike Pagano wrote: > All, Here is the vanilla-sources non stablizing policy news item. If > all goes well, this will be committed to the tree on 08/07 UTC. Mike "The text body should be wrapped at 72 characters." http://www.gentoo.org/proj/en/glep/glep-0042.html#news-item-body
Re: [gentoo-dev] Re: [New eclass] twisted-r1.eclass
Dnia 2013-08-04, o godz. 15:15:12
Marien Zwart napisał(a):
> On Sun, Aug 4, 2013 at 1:13 AM, Michał Górny wrote:
> > 2. The eclass comes with a pure bash-3.2 CamelCase converter
> > for changing PNs like 'twisted-foo' into 'TwistedFoo'. The relevant
> > code can be moved to eutils as portable replacements for bash-4 ${foo^}
> > and friends.
>
> That was considered when the original was committed but rejected as
> getting too messy. Two questions: have you tested this contraption
> with the oldest version of bash we still care about, and have you
> considered making it take the input as an argument and echoing the
> result (making it work the way versionator.eclass functions do)? If
> you want this to be usable as a portable utility function you'd have
> to write it that way, might as well do that from the start.
Yes, it's compliant with bash-3.2. That's why it has conditional
on bash-4. And the original version worked that way but subshells
impact performance, and that's not something we'd like to do
in the global scope. However, if it was to be reused, then it will
probably work that way.
> I'm only ok with this code because we'll eventually end up requiring
> bash 4 at which point this can be written sanely.
>
> > 3. The eclass provides a reusable twisted-r1_python_test and sets it as
> > default python_test. If someone needs to override it, he can still call
> > it using the former name.
>
> Kind of a shame EXPORT_FUNCTIONS only works on actual phase functions.
I had an eclass creating framework for custom phase functions but it
was rejected by the ml as introducing too much abstraction.
> The rm -rf in there is slightly hacky: its target will legitimately
> not exist if this is the initial install or if we're not in a
> twisted-* package (in which case the package should probably not be
> hitting this function, but it will if not overridden).
Hmm, considering the specifics of the function, I think we could make
the cp/rm hack conditional to package name. Non-twisted packages could
still reuse plain 'trial' call.
> There's potential for confusion there if an upgrade drops or renames a
> twisted/plugins/twisted_blah.py file, but that seems like enough of an
> edge case it's not worth worrying about.
True.
> I was going to recommend adding variables that control what gets
> copied and removed, but I can't think of any current users of such
> variables. So it's probably not worth the hassle.
During the tests? Sounds like overkill.
> If I read this right it'll break if distutils_install_for_testing ever
> changes its mind on where to install (and its docstring says to use
> TEST_DIR, not which path that'll be). So I'd add a check for
> ${TEST_DIR}/lib being equal to $libdir after the call to
> distutils_install_for_testing, and print a noisy QA message about
> updating the eclass if they're different.
Sounds reasonable. I was wondering about moving TEST_DIR earlier
in distutils-r1 but this is probably cleaner.
> > 4. Cache updating hack is based off twisted.eclass. Sadly, it's not
> > something we can do without postrm/postinst. Similarly to the old
> > eclass, TWISTED_PLUGINS needs to list the plugin locations. Since most
> > ebuilds install to twisted.plugins, it defaults to that. If an ebuild
> > does not install plugins at all, it needs to set empty TWISTED_PLUGINS.
>
> If I read that right you can just __import__(module), you don't need
> __import__(module, globals()). Also, maybe do the loop over plugin
> locations in bash. I think if you do that you don't need __import__
> and sys.modules anymore, you can just generate "import $module" and
> "list(getPlugins(IPlugin, $module))".
But you'll call Python a few times. Looping in Python is less
expensive. Plus inlining variables into Python code is really ugly.
> I wouldn't worry too much about using pkg_post* for this. It's what
> they're there for (twisted's isn't the only plugin system with a file
> like this, see for example gdk-pixbuf).
>
> It seems that if TWISTED_PLUGINS is set to the empty array, "[[
> ${TWISTED_PLUGINS[@]} ]] || TWISTED_PLUGINS=( twisted.plugins )" will
> set it to twisted.plugins. Is that intentional? It's not necessarily a
> problem (you can just set TWISTED_PLUGINS back to the empty array
> after the inherit) but it's a bit confusing and I don't think it's
> what you intended (why bother with that conditional at all?)
It's all yac's fault :P. I didn't even think about that line.
Well, in fact TWISTED_PLUGINS will usually be set after the inherit.
But indeed we should use some kind of 'declare' to check if it was
declared instead.
> I was going to claim importing from twisted.plugin should never fail,
> but then I realized dev-python/twisted might want to use these
> functions too.
And yes, it does. It's responsible for dropping the plugin cache too.
> I might add a comment to the functions operating on that array to
> remind people it might be the empty array. It wasn't immediately
> obvious to me up
