Re: [gentoo-dev] Attracting developers (Re: Packages up for grabs...)
On 12/26/2012 05:39 PM, Kent Fredric wrote: > I know, it should be easy, and I'm probably making excuses, but it boils > down to Well, it boils down to you needing an excuse ;) > 1. People in Gentoo have asked me to/encouraged me to do the quizzes > 2. I've tried several times > 3. Still not there. > 4. This problem is not so prevalent in the dozens of other projects I've > contributed to. If you tried several times you should have the notes from then, after a few tries I expect you to reach full coverage of all questions at some point ... > As soon as Git migration is done, then I can just > > 1. Fork > 2. Hack > 3. Somebody can watch/review/cherry-pick commits I make if they like > them, if not, I'm not worried. > > But the git part aside, back to the quiz. > Right now you can: 1) publish overlay 2) profit I don't see how this is in any way related to the technology used - as a maintainer I'd still have to review the changes, and the difference between some git magic and some shell magic eludes me. The more difficult part imo is finding someone to review, provide feedback etc. - once you have that figured out the rest pretty much happens by itself
Re: [gentoo-dev] Drop the Perl Modules Guideline?
I can't vote, but I think we need to soften the policy. 2012/12/26 Sergey Popov > 25.12.2012 18:30, Mike Gilbert wrote: > > On Tue, Dec 25, 2012 at 7:09 AM, Torsten Veller wrote: > >> Let's discuss the "specific guideline" for Perl modules. It's as > follows: > >> > >> ,- > http://devrel.gentoo.org/handbook/handbook.xml?part=2&chap=1#doc_chap2_sect2 > >> | Perl > >> | > >> | New Perl modules are to be added to portage only when one of the > following > >> | conditions is met: > >> | > >> | a) The module(s) fulfill a dependency > >> | b) The module(s) cannot be handled by g-cpan > >> | c) The module(s) add functionality to existing ebuilds > >> | d) The module(s) provide tools, applications or other features (i.e. > more > >> |than what their .PM offers) > >> | > >> | Please make sure that at least one member of the perl herders approves > >> | your addition. > >> `- > >> > >> Recently the proxy-maintainer project is repeatedly adding packages > >> which aren't following these guideline AFAIK. So maybe we should change > >> it. > >> > >> 444974 a) dev-perl/Text-Format - Various subroutines to format text > 2012-12-07 > >> 444976 a) dev-perl/Roman - Perl module for conversion between Roman and > Arabic numerals.2012-12-03 > >> 446710 ?) dev-perl/FLV-AudioExtractor - Extract audio from Flash Videos > 2012-12-12 > >> 447724 ?) dev-perl/Email-Send-Gmail - Send Messages using Gmail Mon > 10:12 > >> > >> Ad a): This requirement is a little problematic: > >> Sometimes perl modules are needed for maintainer-wanted packages. > >> Sometimes the perl modules are added to the tree while the > >> maintainer-wanted package never are or will be. Sometimes the maintainer > >> are waiting for the perl team to do their work. > >> > >> Ad b): (Judging from bugreports) g-cpan doesn't seem to be really > >> reliable these days. I always wanted to test/verify it. But ... (random > >> excuse: time, motivation,...) > >> > >> I guess I don't have no problem with modifying or dropping the > >> requirements. The perl overlay contains hundreds of packages which > >> should be added to the main tree. > >> > >> The dev-perl category currently already contains the most packages > >> (1140 per packages.g.o). > >> > >> -- > >> Best regards > >> Torsten > >> > > > > I'm sure I skimmed that section of the handbook at some point for the > > quizzes, but I don't remember it. I think it is possible that the > > proxy commiter (pinkbyte) forgot about it too. > > No, i do not, i have read this guideline, and yes - it is not mentioned > directly in Handbook or Devmanual. > Some of these modules was added cause they are dependencies for other > packages(which are still waiting for adding in tree, cause they have no > maintainer yet), others - cause g-cpan generate very ugly ebuilds for them. > > > I think that all of those requirements make sense. We might want to > > formalize a similar guideline for the python herd. > > > > Perhaps the requirements list could be copied somewhere more visible? > > The perl project page might get more traffic for people looking to > > write perl ebuilds. > > > > Truly, i do not really understand such hard policy for NOT including > perl modules in tree. I know that perl herd is understaffed, but i do > not think that this is generally a problem, cause they do not maintain > recently added packages, but proxy maintainers do. > > So, basically, yes, i vote for easing policy a bit. > > P.S. CCing maintainer of modules, that i have commited as a proxy, maybe > he also wants to say something regarding this. > > -- > Best regards, Sergey Popov > Gentoo Linux Developer > Desktop-effects project lead > > -- -BEGIN PGP PUBLIC KEY BLOCK- Version: GnuPG v2.0.17 (GNU/Linux) mI0ETyui1AEEALmZQeAzZVPBtw3IJ3NC3w1SdhrNFN7DnEmnrw0UrjfZ1ubxGq58 2nmOOrb0TxAx4hQ5DPiWzIK0D4EAYAPbkApJsYUB7jhocV7d1O09iu+Ip8lT5wV3 ZviMJ0r3itP8yOU93v7WKygR9T4AljMuMoP7v2qz+VCyeVplfsYHo/qbABEBAAG0 Pk1pa2xlIEtvbHlhZGEgKFRoZSBSZWFsIE1pa2xlIEtvbHlhZGEpIDx6bG9nLmdl bnRvb0BnbWFpbC5jb20+iLgEEwECACIFAk8rotQCGwMGCwkIBwMCBhUIAgkKCwQW AgMBAh4BAheAAAoJEDRdeYLl90M6N2cD/jFx/0p+dT67Dgq8wQGRE6VMjHsP6rZl uM2B2NvIuaJAKx6CESUJzxHSVHsu9xVrSm8g1/+rtryf/NxbtEsscUuWY62yVDVj F+sLOPNztj2K7ms2aHAgZxwbAG/yjGt+KTcgga2CYxwPvKEvU+suEL4c+ScSrRSl /vdll08JVo0yuI0ETyui1AEEAMbrOCNzTvLfsb4whOo+pk+y9YU9PXzI5u+Zao3v qmLkyViqwh+z9O3r8IIFWF5ASVPHwBIMWDWn0KamA7QsKKFD87Q3wMN524oCvVds FnbtqZhlntE0AbQzt4bkpGpIbmAw1nL6B2BE7xiPrEMqcNPyXLYp6i60ddRDHrcB ZlQJABEBAAGInwQYAQIACQUCTyui1AIbDAAKCRA0XXmC5fdDOhBwA/wLTcQgIm76 bG0a9t551U5YnQBD2H+nlBzwrPREY5P40pwRt6ur1eN9Xobs9IsimmRQGwlfwLuv PKFD4KWCmjyoMxMuF1b0VycbuETz31T4KxF0CGAQoiRxGurlhbxmmjrauqqUAYft 1mGFbulta/hLx0Ez0JNEDw0Z6dw4Jny15Q== =sNcj -END PGP PUBLIC KEY BLOCK-
Re: [gentoo-dev] Re: [gentoo-project] Call for agenda items -- Council meeting 2013-01-08
On Fri, 28 Dec 2012 19:06:02 +0100 "Andreas K. Huettel" wrote: > Am Freitag, 28. Dezember 2012, 11:19:23 schrieb Michał Górny: > > > > I don't think we can really avoid having the current 'base' profile, > > and I don't think that we should even try doing that. As far as I can > > see, the idea would be to mask the flags completely in base profile, > > and unmask in *stable.mask files. Do I get it correctly? > > [see also attached modified graphs] > > The idea would be *for the transition period*: have an additional directory > base5, which contains eapi=5, the stable mask files and nothing else. > > After the transition period, these files are merged into the main profile > directory, the base5 directory is removed from inheritance and deleted. > > During the transition period, an old installation using deprecated 10.0 > profile will "not see the stable mask files", which means the additional > useflag restrictions are just not enforced. Repoman will check against non- > deprecated profiles, which means it uses the 13.0 path. Well, I guess it's acceptable. I think it's fine assuming that stable users don't enable flags relevant to packages not being stable. > [Given the position in the depgraph, maybe a different name instead of base5 > would make sense. I just wanted to stick to the description from the last e- > mail.] I agree. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-project] Call for agenda items -- Council meeting 2013-01-08
Am Freitag, 28. Dezember 2012, 20:03:49 schrieben Sie: > > The idea would be *for the transition period*: have an additional > > directory > > base5, which contains eapi=5, the stable mask files and nothing else. > > > > After the transition period, these files are merged into the main profile > > directory, the base5 directory is removed from inheritance and deleted. > > > > During the transition period, an old installation using deprecated 10.0 > > profile will "not see the stable mask files", which means the additional > > useflag restrictions are just not enforced. Repoman will check against > > non- > > deprecated profiles, which means it uses the 13.0 path. > > Well, I guess it's acceptable. I think it's fine assuming that stable > users don't enable flags relevant to packages not being stable. OK then unless someone brings up valid points against this, let's suggest for the upcoming meeting that Council decides * whether to implement solution a) as discussed in preceeding e-mails * and if yes, how long the waiting time between deprecation of 10.0 and removal of 10.0 shall be. [Alternative name for the eapi-5 directory: eapi5-base instead of base5 ?] -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Bad GPG key
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Why is your signature suddenly bad? It verifies in your 19:06 (GMT+1) submission to gentoo-dev, but not in the most recent one -- 20:24 (GMT+1). - -- Alexander alexan...@plaimi.net http://plaimi.net/~alexander -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAlDd8xUACgkQRtClrXBQc7VnPgD/dW6G8dEnSL5n8S+z/3k4PlTl k3XmuGy+ACbwR7mxdg4A/32aKt/8qFeRlaQls4gTrIZ6yXNSbzoFFrdx0z1HAjtO =WP4X -END PGP SIGNATURE-
Re: [gentoo-dev] Bad GPG key
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 28/12/12 20:29, Alexander Berntsen wrote: > Why is your signature suddenly bad? It verifies in your 19:06 > (GMT+1) submission to gentoo-dev, but not in the most recent one -- > 20:24 (GMT+1). > > Sorry. this was for Andreas, and should be to him directly not the list... so feel free to answer me directly. - -- Alexander alexan...@plaimi.net http://plaimi.net/~alexander -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAlDd83IACgkQRtClrXBQc7WojAD/esfB4mvw2xFiEJrPnaMNs6Fk pCX8iEVW23wTo50lgLIBAJyAPzlKLb8b+He3jeot0v8iJSP0+T7iLz+J3ve/J2Cv =qfkp -END PGP SIGNATURE-
Re: [gentoo-dev] Bad GPG key
Known kmail bug imho. :( https://bugs.kde.org/show_bug.cgi?id=306005 Am Freitag, 28. Dezember 2012, 20:29:25 schrieb Alexander Berntsen: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Why is your signature suddenly bad? It verifies in your 19:06 (GMT+1) > submission to gentoo-dev, but not in the most recent one -- 20:24 (GMT+1). > > - -- > Alexander > alexan...@plaimi.net > http://plaimi.net/~alexander > -BEGIN PGP SIGNATURE- > Version: GnuPG v2.0.19 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iF4EAREIAAYFAlDd8xUACgkQRtClrXBQc7VnPgD/dW6G8dEnSL5n8S+z/3k4PlTl > k3XmuGy+ACbwR7mxdg4A/32aKt/8qFeRlaQls4gTrIZ6yXNSbzoFFrdx0z1HAjtO > =WP4X > -END PGP SIGNATURE- -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] gen_usr_ldscript & --libdir=/lib
On 2012.12.27 22:13, William Hubbs wrote: > On Thu, Dec 27, 2012 at 03:14:37PM -0500, Rich Freeman wrote: > > Something I don't like about this whole debate is that it tends to > > come off as "I've never run an initramfs and darn it I want to keep > it > > that way." Gentoo has always been a cutting-edge/innovative > distro. > > We have prefix, hardened, x32, and we were among the first to > support > > amd64. Sure, that flexibility also lets you get away without an > > initramfs where other distros simply cannot. However, the lack of > an > > initramfs should not be a crutch. > > Rich, > > you just hit my concern about this debate right on the head. I feel > like > the nay-sayers are opposed to it because of the FHS, and the idea of > critical software going in / and everything else in /usr. The > attitude > seems to be that has always worked, so it must continue to work into > the > future, with no regard to the advantages that moving everything to > /usr > would give us. > > Another concern I've heard says that we shouldn't do this on linux > because gentoo *bsd doesn't do it. I don't see that as relevant > because ebuilds can be smart enough to test whether they are being > emerged on Linux or *BSD. > > William > > I don't think the 'luddites' have quite so black and white a view as that but if I expand on it much more, I'll reignite a flamewar we have already had. -- Regards, Roy Bamford (Neddyseagoon) a member of elections gentoo-ops forum-mods trustees pgpM7U4Uf69D8.pgp Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-project] Call for agenda items -- Council meeting 2013-01-08
On Thu, Dec 27, 2012 at 5:40 PM, Andreas K. Huettel wrote:
> 2) Deprecate the 10.0 profiles NOW by removing them from profiles.desc and
> putting the new 13.0 profiles there. This has absolutely no effect on
> running
> installations.
>
> 3) Make a news item about removal of 10.0 profiles in a year /
> ${TIMESCALE}.
>
> 4) One ${TIMESCALE} later, remove 10.0 profiles. This is the ugly part, and
> users need to be warned and prepared properly - here everyone needs an
> EAPI5
> capable portage.
>
This seems like a great time to deprecate & remove the unmaintained server
profile target, as has been previously discussed. Is this doable or is
that another issue to be tackled another day?
-Ben Kohler
Re: [gentoo-dev] gen_usr_ldscript & --libdir=/lib
On Thursday 27 December 2012 17:13:56 William Hubbs wrote: > Another concern I've heard says that we shouldn't do this on linux > because gentoo *bsd doesn't do it. I don't see that as relevant > because ebuilds can be smart enough to test whether they are being > emerged on Linux or *BSD. +1 -mike signature.asc Description: This is a digitally signed message part.
