Re: [gentoo-dev] Dropping ia64/ppc/sparc profiles to dev/exp
07.05.2017 22:23, David Seifert пишет: > TL;DR > ia64/ppc/sparc teams are pretty much dead. They have been for a long > time and this won't change any time soon. Gentoo should focus its > resources on archs that are important and has the manpower to support. > Let us please drop these 3 archs to dev profiles to ease maintenance. > > Dear all, > I'd like to request Council to consider my motion to drop the > ia64/ppc/sparc profiles to dev (or exp). These arches are pretty much > dead, minus the automated workflows of ago. Two months ago I have > written to these 3 archs, and only received one reply from ppc agreeing > with my sentiment, with no response from ia64 or sparc, which in itself > is pretty telling. > > Currently, architecture projects think adding their keywords is a > right, which I strongly disagree with. I believe being able to add (and > stable) your keywords is a privilege - namely it carries with it the > duty to react to keywording and stabilization requests in a timely > manner. Let's compare the state of ia64/ppc/sparc to, say alpha: > > https://bugs.gentoo.org/show_bug.cgi?id=605278 > > alpha was keyworded within 6 hours. To date ia64/ppc/sparc are still > not keyworded (the bot had some breakages due to jer again shifting > around all the bugs). Within 4 months these arches have not managed to > keyword those 4 packages. This is I believe the most striking example > of how the only work done for these archs are ago's automated stablereq > scripts. Why do I saw that keywording+stabling your arch is a > privilege? Maintenance of packages is hampered by archs not stabling, > because we cannot clean up broken packages. Adding keywords is a two- > way street - if you don't act speedily, you're breaking part of the > maintainer-arch social contract. > > Please don't turn this into a massive bikeshedding contest and just > admit that it is extremely unlikely that these archs will see more > activity in the near future. We should focus our resources on more > important archs (arm64 maybe?) instead of these. I know you have that > old Mac G4 or UltraSPARC sitting in your closet that you're 2 days away > from installing Gentoo on, but the pain for maintainers and the rest of > the community is just too great. If someone steps up to do the work, we > can then move archs back to a stable profile, but so long as they > linger in their present state, let's call a spade a spade. > > Anyhow, I formally request the Council to vote on dropping these archs > to unstable/exp profiles for the next Council meeting, explicitly > overriding any arch concerns that are likely to awake now and going to > be running around like headless chicken. > > David > Against. Do not touch things you are not working on, council has already dropped m68k s390 and sh to exp few years ago. Now we have a big mess there and only, while ia64 sparc and co have slow but progress and mature enough stable profiles.
Re: [gentoo-dev] Dropping ia64/ppc/sparc profiles to dev/exp
08.05.2017 21:55, Andreas K. Huettel пишет: > Am Montag, 8. Mai 2017, 12:49:32 CEST schrieb Mikle Kolyada: >> Against. Do not touch things you are not working on, council has already >> dropped m68k s390 and sh to exp few years ago. Now we have a big mess >> there and only, while ia64 sparc and co have slow but progress and >> mature enough stable profiles. > No objections against having many arches, but: > > If an arch is keyworded / stable on more packages than that team can > reasonably take care of, that needs to be corrected somehow. > > The easiest solution is for the arch team to remove keywords until they have > a > reasonable response time again. And if the arch team doesn't do that by > itself, well, ... > > Having one-man teams block everybody else hurts Gentoo as a whole. > We have appropriate hardware if people wanna do the work, jut go & make things better :), I do not think someone from existing arch teams has something against that
Re: [gentoo-dev] Dropping ia64/ppc/sparc profiles to dev/exp
08.05.2017 22:21, David Seifert пишет: > On Mon, 2017-05-08 at 22:08 +0300, Mikle Kolyada wrote: >> We have appropriate hardware if people wanna do the work, jut go & >> make >> things better :), I do not think someone from existing arch teams has >> something against that > Ok so let me get the logic right: > > 1) Arch teams can add their keywords to ebuilds in general, without the > maintainer having a say in that. > 2) Arch team goes MIA because . > 3) Now the maintainer has to chase down machines and do KEYWORDREQ > testing on other arches because we cannot admit that some archs are not > maintained. > > Please confirm the above logic. If that logic is about right, I am > sorry, but I disagree. I will rather dekeyword unmaintained archs. I am > not going to babysit arch teams in doing their work for them. > To clarify: I have not seen the draft of proper reverting these arches to exp or dev, if it will be like sh or s390, better kill the horse like debian did to alpha and hppa, without riding it.
[gentoo-dev] Last rites:sys-apps/more
# Mikle Kolyada (26 Aug 2017) # Masked for removal in 30 days. # No major keywords, old EAPI, no maintainer. # Use sys-apps/less instead. sys-apps/more signature.asc Description: Digital signature
Re: [gentoo-dev] Deleting old news items
+1 There is also https://www.gentoo.org/support/news-items/ if needed signature.asc Description: Digital signature
[gentoo-dev] Last rites: app-emulation/armv8-fast-model
# Mikle Kolyada (27 Apr 2018) # Upstream is dead, the site with the sources is down. # There's no chance to get the sources (fetch restricted) # Removal in 30 days (bug #642866) app-emulation/armv8-fast-model signature.asc Description: OpenPGP digital signature
[gentoo-dev] Last rites: sys-fs/yaffs-utils
# Mikle Kolyada (9 June 2018) # Fails to buil, dead upstream, EAPI=2 # Only the live enuild in the tree. # Masked for removal in 30 days sys-fs/yaffs-utils signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Idea for a new project: gentoo-libs
On 23.06.2018 05:50, Marty E. Plummer wrote: > So, as you may be aware I've been doing some work on moving bzip2 to an > autotools based build. Recently I've ran into app-crypt/mhash, which is > in a semi-abandoned state (talking with the maintainer on twitter atm), > and I was thinking it may be a good idea to set up a project for keeping > these semi-abandoned and really-abandoned libraries and projects up to > date and such. But how would it serve gentoo itself? Lots of packages in the distro have dead upstream but still work. Why would you want to make gentoo an upstream area rather than moving a dead project itself, say, to github and do the job there? > > Basically, an upstream for packages who's upstream is either > uncontactable or is otherwise not accepting bug fixes and patches. So > far I can only think of app-crypt/mhash and app-arch/bzip2 but I'm sure > there are others in this state. > signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] 'Gentoo Linux' bugzilla component reorganization
15.06.2016 22:11, Michał Górny пишет:
Hello, everyone.
On bug #577398, Pacho has requested removing the 'Development'
component that's rarely used according to its description. However, I'd
rather not remove a single component when it fits the component split
currently used there.
Right now we have the following components:
- Applications,
- baselayout,
- Core system,
- Development,
- Eclasses and Profiles,
- Games,
- GCC Porting,
- GNOME,
- Hardened,
- Java,
- KDE,
- Keywording & Stabilization,
- Library,
- New packages ('New ebuilds' previously),
- Printing,
- SELinux,
- Server,
- Unspecified.
[snip]
I would personally go for the following layout:
- All packages,
- Core system [includes baselayout],
- Eclasses and Profiles,
- GCC Porting,
- Hardened,
- Keywording & Stabilization,
- New packages ('New ebuilds' previously),
- SELinux.
[snip]
I'd drop keywording & stabilization at all, using bug filtering based on
keywords field. (STABLEREQ/KEYWORDREQ ones).
Re: [gentoo-dev] Looking for a new mentor...
21.07.2016 02:41, Manuel Rüger пишет: Hey, have you tried contacting recruit...@gentoo.org? https://wiki.gentoo.org/wiki/Project:Recruiters Cheers, Manuel On 20.07.2016 21:13, alexmcwhir...@triadic.us wrote: I've been working towards becomming a gentoo developer for while now in order to bring the sparc port up to speed with the rest of the gentoo project. In short there appear to be no active gentoo developers working on sparc. I had a mentor earlier this year, but i can no longer get in touch with him. I have both quizzes nearly complete, i just need someone to look over them and answer a question or two. Any help would be greatly appreciated. Recruiters take care of recruitment process, not about mentors:)
Re: [gentoo-dev] Looking for a new mentor...
21.07.2016 03:58, Manuel Rüger пишет: On 21.07.2016 02:46, Mikle Kolyada wrote: 21.07.2016 02:41, Manuel Rüger пишет: Hey, have you tried contacting recruit...@gentoo.org? https://wiki.gentoo.org/wiki/Project:Recruiters Cheers, Manuel On 20.07.2016 21:13, alexmcwhir...@triadic.us wrote: I've been working towards becomming a gentoo developer for while now in order to bring the sparc port up to speed with the rest of the gentoo project. In short there appear to be no active gentoo developers working on sparc. I had a mentor earlier this year, but i can no longer get in touch with him. I have both quizzes nearly complete, i just need someone to look over them and answer a question or two. Any help would be greatly appreciated. Recruiters take care of recruitment process, not about mentors:) They do. But they usually are aware of possible and active mentors and can recommend some. Cheers, Manuel. Well, I have been recruiting people for more than a year, we can only recommend, but usually it is not our work.
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-
[gentoo-dev] About src_test() in perl-modules
Lately, i saw many bugs like =dev-perl/
${packagename}: fails test. Me just interested proper way to fix those
bugs? Sure, it's good when we have clear version for bump w/o problem. But
this is not always What common ways to fix those bugs? (I know that we
can disable bad tests)
[gentoo-dev] Last rites: dev-perl/Class-MOP
# Torsten Veller (08 Jan 2013) # Mask dev-perl/Class-MOP. It was merge with dev-perl/Moose-2. # Now as the last arch stabilized Moose-2, dev-perl/Class-MOP will be removed. # bug #350612 dev-perl/Class-MOP -- Best reagrds, Mikle Kolyada. Gentoo Linux Developer
[gentoo-dev] About m68k arch status in perl packages
Hi all. We have very long delay with m68k arch in many stabilization bugs, especially in perl-related. I think this is not ok. The only one mk68k developer is vapier, so i want say: if we'll have no progress in stabilization for m68k for a two weeks, i'll close all bugs, that have m68k as last arch (i have no hardware to test it) and drop related keyword in package to unstable. -- Best reagrds, Mikle Kolyada. Gentoo Linux Developer
[gentoo-dev] Last rites: dev-perl/Date-ISO
# Mikle Kolyada (16 Jul 2013) # Upstream dead. # No license info (bug #381283). # Removal in 30 days. dev-perl/Date-ISO -- Best regards, Mikle Kolyada. Gentoo Linux Developer.
[gentoo-dev] Last rites: dev-perl/Date-ISO
# Mikle Kolyada (16 Jul 2013) # Upstream dead. # No license info (bug #381283). # Removal in 30 days. dev-perl/Date-ISO -- Best regards, Mikle Kolyada. Gentoo Linux Developer.
[gentoo-dev] perl herd needs your help
Hi folks! We need new active devs. Now we have ~200 bugs assigned to perl, but we have new tracker too. (https://bugs.gentoo.org/show_bug.cgi?id=478714). 469 packages to update to EAPI >= 4. We have no enough time/resources to do it singly. Please help us! -- Best regards, Mikle Kolyada. Gentoo Linux Developer.
Re: [gentoo-dev] Moving more arches to dev profiles
21.08.2013 15:04, Markos Chandras пишет: > Hi, > > It's time of year again to consider moving a few arches to dev-only status. > > I propose the following arches to lose their stable keywords > > - s390 > - sh > - ia64 > - alpha > - m68k > - sparc +1 for that. Perl herd has *really* many work with stabilization, it's difficult because it's taking over a month in some cases.
[gentoo-dev] About perl-5.18 unmasking
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi guys! Few days ago i was surprised, when i saw perl-5.18 unhardmasked. So, i want ask here. @Patrick, why you unmask it? You even not ack perl herd about it. It was in the tree about two weeks, too early for unmasking, furthermore, you added not all modules need for perl-5.18 in the tree. Now many users ask us "why perl 5.18 broke our modules?" Its not good. Testing on three boxes w/o problems, no major reason for unmasking. And also, many CPAN guys still no fix own modules for compile with-5.18 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) iJwEAQECAAYFAlIsdO0ACgkQG9wOWsQutdat/QQAsLcbqEn6NZGFAoipWZuBCxMM Q5BPj7a43vLEuI08aCbOeiihVWqEEVqPOWJyXAoSohkOL5DhmRfv1e6z4JPX2BGv dH/HFBkFtWH3gVOg7BV+rvecSb/ds6M2zufjnSHfBxomAuSKiFru1lQGYoVbPOrZ Gwpy66uY2LZ9kBNkM/Q= =USUZ -END PGP SIGNATURE-
[gentoo-dev] Perl 5.18.2 unmasking
Hello. We are willing to unmask perl-5.18.2 in a couple of days. It seems that most fatal issues are fixed now, and we, perl herd, are using perl 5.18 in daily life for quite a some time. So if there is no objections, we will unmask it soon. As usual, if you find any issues, please file a bug about it and block tracker[1]. [1] - https://bugs.gentoo.org/show_bug.cgi?id=perl-5.18 -- Mikle Kolyada Gentoo Linux Developer
[gentoo-dev] Last rites: app-misc/bins
# Mikle Kolyada (19 Mar 2014) # Dead upstream (no releases since 2006), # GUI no longer supported (bug #250971). # Removal in 30 days. app-misc/bins -- Mikle Kolyada Gentoo Linux Developer
Re: [gentoo-dev] Perl 5.18.2 unmasking
16.03.2014 23:51, Mikle Kolyada пишет: > Hello. > > We are willing to unmask perl-5.18.2 in a couple of days. It seems that > most fatal issues are fixed now, and we, perl herd, are using perl 5.18 > in daily life for quite a some time. So if there is no objections, we > will unmask it soon. As usual, if you find any issues, please file a bug > about it and block tracker[1]. > > [1] - https://bugs.gentoo.org/show_bug.cgi?id=perl-5.18 > unmasked. -- Mikle Kolyada Gentoo Linux Developer
Re: [gentoo-dev] Change or revert the "30 days maintainer timeout" stabilization policy
02.04.2014 20:52, Samuli Suominen пишет: > The "30 days maintainer time out" stabilization policy isn't working > when package has multiple SLOTs, because > the bugs are filed for only latest SLOT, where as some packages require > stabilization in sync at both SLOTs > > Option 1: > > Either revert the whole policy, and never CC arches on unanswered bugs > when the package has a maintainer, > and let him do it when he finds the time himself, and if that doesn't > happen, wait until it's dropped to maintainer-needed@ > > Option 2: > > Or, the person who is CCing the arches in 30 days timeout, needs to make > sure the bug covers all SLOT at the same time > > > The status quo no longer allows me to maintain stable version of > dev-libs/girara, app-text/zathura*, and the issue needs > to be addressed, see http://bugs.gentoo.org/502714 for what inspired > this mail > > - Samuli Agreed. If package have active maintainer(s), i think they can file stablereq when they wants (i think all maintainers have stabilization scheme at least). As arch teams developer i'm annoyed when i see 80 (or even more) messages like *maintainer timeout, go ahead* Moreover last time i'm noticed, that this script CC s390/sh/m68k automatically, and we need remove it manually. Seems script stil has no fix at all. -- Mikle Kolyada Gentoo Linux Developer
Re: [gentoo-dev] ARM64 stable keyword
22.04.2014 21:40, Mike Gilbert пишет: > I see that vapier has been adding arm64 as a stable keyword to lots of > packages. > > When I am requesting stabilization for newer versions these packages, > is there an arm64 arch team I should copy? If not, these stable > keywords are just going to get lost as old ebuilds get dropped. > > For an example, see my last commit to dev-util/scons. I moved the > stable keyword forward from scons-2.2.0 to scons-2.3.0 myself, but I > am not sure if this was the right thing to do. > > You should not add this, only vapier and probably armin76 have arm64 hardware (hardware?). Mike stabilize for minor arches if needed. (like sh/s390/m68k).
Re: [gentoo-dev] ARM64 stable keyword
22.04.2014 21:59, Mike Gilbert пишет: > On Tue, Apr 22, 2014 at 2:01 PM, Mikle Kolyada wrote: >> 22.04.2014 21:40, Mike Gilbert пишет: >>> I see that vapier has been adding arm64 as a stable keyword to lots of >>> packages. >>> >>> When I am requesting stabilization for newer versions these packages, >>> is there an arm64 arch team I should copy? If not, these stable >>> keywords are just going to get lost as old ebuilds get dropped. >>> >>> For an example, see my last commit to dev-util/scons. I moved the >>> stable keyword forward from scons-2.2.0 to scons-2.3.0 myself, but I >>> am not sure if this was the right thing to do. >>> >>> >> You should not add this, only vapier and probably armin76 have arm64 >> hardware (hardware?). Mike stabilize for minor arches if needed. (like >> sh/s390/m68k). >> > Ok, then the stable keyword is going to get lost when I drop old versions. > Vapier can restore stable keywords for newest version if needed, i think
Re: [gentoo-dev] alpha, ia64, ppc, ppc64, sparc developers, need your attention
01.06.2014 15:18, Samuli Suominen пишет: > http://bugs.gentoo.org/show_bug.cgi?id=505962#c6 is blocking stabilizing > the new virtuals, > and thus, converting the tree, and also blocking stabilization of the > already converted packages (gnome seems to have some) > pending for 3 months already > > thanks, > samuli > Is compile only test enough for you? If so, i can take care about it right now.
Re: [gentoo-dev] Packages up for grabs
08.06.2014 16:25, Fabio Erculiani пишет: > Due to permanent lack of time, I'm unable to properly maintain the > packages below. > Feel free to take them over. I'll remove myself from metadata.xml in 14 days. > > app-admin/389-admin-console > app-admin/389-console > app-admin/389-ds-console > app-admin/aws-as-tools > app-admin/aws-elb-tools > app-admin/aws-iam-tools > app-admin/aws-rds-tools > app-emulation/edumips64 > dev-java/idm-console-framework > dev-libs/389-adminutil > dev-libs/mozldap > dev-libs/svrcore > dev-perl/perl-mozldap > net-nds/389-admin > net-nds/389-ds-base > net-libs/libgrss > www-apache/mod_nss > www-apps/389-dsgw > x11-apps/ardesia > x11-apps/spotlighter > x11-apps/python-whiteboard > x11-apps/whyteboard > x11-drivers/cwiid > > dev-perl/perl-mozldap perl herd will take care.
Re: [gentoo-dev] Packages up for grabs
09.06.2014 21:47, Jeroen Roovers пишет: > On Mon, 09 Jun 2014 21:34:06 +0400 > Mikle Kolyada wrote: > >>> app-admin/389-admin-console >>> app-admin/389-console >>> app-admin/389-ds-console >>> app-admin/aws-as-tools >>> app-admin/aws-elb-tools >>> app-admin/aws-iam-tools >>> app-admin/aws-rds-tools >>> app-emulation/edumips64 >>> dev-java/idm-console-framework >>> dev-libs/389-adminutil >>> dev-libs/mozldap >>> dev-libs/svrcore >>> dev-perl/perl-mozldap >>> net-nds/389-admin >>> net-nds/389-ds-base >>> net-libs/libgrss >>> www-apache/mod_nss >>> www-apps/389-dsgw >>> x11-apps/ardesia >>> x11-apps/spotlighter >>> x11-apps/python-whiteboard >>> x11-apps/whyteboard >>> x11-drivers/cwiid >>> >>> dev-perl/perl-mozldap >> perl herd will take care. > It looks like you mean perl@ will take care of all of them. > > > jer > no, only dev-perl/perl-mozldap. I just use wrong quotes:/
Re: [gentoo-dev] splitting out arm keywords
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
09.07.2014 20:10, Manuel Rüger ?:
> On 07/09/2014 01:40 PM, Anthony G. Basile wrote:
>> On 07/09/14 05:09, Joshua Kinard wrote:
>>> On 07/08/2014 21:48, Matthew Thode wrote:
arm has a historical problem with stabilization, while keywording
doesn't require access to all arm sub-arches the problem with the
stabilization slowness causes running a full ~arm to become hard. By
that I mean that if someone keywords something for arm because it works
on armv7 and I run ~arm because stabilization takes forever then my
system may break because of both non-stabilized packages and because I
could be running armv6.
In any case I propose splitting out arm into armv4, armv5, armv6 and
armv7. armv8 seems to be here already as arm64.
>>> Couldn't this be better handled with some profile work? These sound
like
>>> versions of Instruction Set Architectures. In the MIPS world, you
>>> have your
>>> original ISAs, mips1 through mips4, then you have the newer variants of
>>> mips32r* (branches from mips2) and mips64r* (branches from mips4).
>>> Anything
>>> supporting mips4 could also support earlier ISAs. Throw in our three
>>> supported ABIs (o32, n32, n64), and machine-specific curiosities (SGI,
>>> Cobalt, Yeelong/Loongson, etc), and life can be quite fun. But we can
>>> cover
>>> all of this with just a single 'mips' keyword in the tree.
>>
>> Yes, this should be done via the profiles. Code requiring later ISAs
>> and/or with extensions like thumb and neon will probably break on lower
>> ISAs. These should be masked on the profiles.
>>
>>> Is that similar to how these ARM variants work? Can an armv7 run code
>>> for
>>> armv6 and earlier?
>>
>> Its a bit more complicated that MIPS. You can test for yourself. I did
>> this via a chromebook (cortex-a15) using my hardened stages
>> (march=armv7a) available at /experimental/arm/hardened, so you
>> can test too:
>>
>> chrome ~ # echo "int main() { return 0; }" > test.c
>> chrome ~ # gcc -march=armv7-a -o test test.c
>> chrome ~ # gcc -march=armv6 -o test test.c
>> chrome ~ # gcc -march=armv5 -o test test.c
>> chrome ~ # gcc -march=armv4 -o test test.c
>> chrome ~ # gcc -march=armv3 -o test test.c
>> /tmp/ccZjsI2O.s: Assembler messages:
>> /tmp/ccZjsI2O.s:45: Error: selected processor does not support ARM mode
>> `bx lr'
>> chrome ~ # gcc -march=armv3m -o test test.c
>> /tmp/cc1o59kQ.s: Assembler messages:
>> /tmp/cc1o59kQ.s:45: Error: selected processor does not support ARM mode
>> `bx lr'
>> chrome ~ # gcc -march=armv2 -o test test.c
>> /tmp/ccmTNSyh.s: Assembler messages:
>> /tmp/ccmTNSyh.s:45: Error: selected processor does not support ARM mode
>> `bx lr'
>> chrome ~ # gcc -march=armv2a -o test test.c
>> /tmp/ccTIXZ46.s: Assembler messages:
>> /tmp/ccTIXZ46.s:45: Error: selected processor does not support ARM mode
>> `bx lr'
>> chrome ~ # gcc --version
>> gcc (Gentoo Hardened 4.7.3-r1 p1.4, pie-0.5.5) 4.7.3
>> Copyright (C) 2012 Free Software Foundation, Inc.
>> This is free software; see the source for copying conditions. There
is NO
>> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.
>>
>>
>> So it looks like gcc can emit compat code back to armv4. This doesn't
>> necessarily mean that armv2 code won't run on an armv7a, but that
>> gcc-4.7.3-r1 can't produce such code, which is sufficient for our
>> purposes of masking.
>>
>>
>>>
>>> Splitting 'arm' into four new keywords, on top of 'arm64' is just
>>> going to
>>> give you guys major headaches later. You might even consider
>>> dedicated USE
>>> flags for the arm subvariants and use those to control things in an
>>> ebuild
>>> where applicable.
>>
>> arm64 might as well be a totally different arch. There is no
>> compatibility between 32-bit and 64-bit arm variants --- at least not
>> that I know of, its a new arch that I'm just now getting familiar with.
>> On the other hand ppc and ppc64 should never have been split, but that's
>> another story.
>>
>> We do not want keywords for every subarch otherwise we'll go crazy
>> stabilizing. We could adopt a policy of stabilizing on armv7a and when
>> a package doesn't build on a lower ISA, just mask it in the profiles.
>>
>>>
I think this would be beneficial because of not all developers that
want
to help with arm have or what all the sub-arches necessary. It also
allows us to move faster on stabilization because most of us have
access
to armv7 a bit easier. This would take some pressure off of the people
doing stabilization for older sub-arches, but not much.
>>> What's the support status of Gentoo on the older variants, such as
>>> armv4 and
>>> armv5 stuff? How fast is the CPU clock on those? Do they include L2/L3
>>> cache? Lots of memory? Generally, anything that could be a
>>> bottleneck or
>>> severely increase the build time should be weighed against the potential
>>> number of users and
RE: [gentoo-dev] PowerPC status
Исходное сообщение От Jack Morgan Дата: 18.09.2014 3:31 (GMT+04:00) Кому gentoo-dev@lists.gentoo.org Тема [gentoo-dev] PowerPC status Hello, The PowerPC development team has had our 2nd monthly meeting and I wanted to provide an update on where we are. 1) Active Developers The following are activly working on PPC/PPC64 as far as I know. If I've listed you in error, please let me know. Agostino Sarubbo (ago) - stablereq Anthony G. Basile (blueness) - keywordreq, profiles Jeroen Roovers (jer) - developer Jack Morgan (jmorgan) - lead, keywordreq Joseph Jezak (josejx) - docs, keywordreq Luca Barbato (lu_zero) - keywordreq Mikle Kolyada (zlongene) - developer -- I could not visit our meetings for some personal reasons + I am in Barcelona for about last two weeks. But I think I can do some work for 2 ways (I will try to keep these 2 ways at least) keywordreqs and stablereqs together.
Re: [gentoo-dev] Make 'vaapi' USE flag global
28.11.2014 15:20, Sergey Popov пишет: > Packages that uses 'vaapi' local USE-flag: > > media-libs/avidemux-core > media-libs/xine-lib > media-tv/mythtv > media-tv/xbmc > media-video/avidemux > media-video/ffmpeg > media-video/hwdecode-demos > media-video/libav. > media-video/mpv > media-video/vlc > virtual/ffmpeg > www-plugins/gnash > > Descriptions for that flag are pretty the same and we already have > 'vdpau' USE flag, which is for someway similar technology. > > So, how about making this flag global too? > works for me.
Re: [gentoo-dev] Packages up for grabs: app-backup/fsarchiver, app-cdr/daa2iso...
On 19.07.2018 11:10, Michał Górny wrote: > Hello, > > Due to Markos Chandras' prolonged absence, the following packages are up > for grabs now: [snip] > sys-auth/sssd > > Will take this one, someone else is welcome to help :) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: What means bup?
On 18.07.2018 19:57, Matthew Thode wrote: > On 18-07-18 11:28:16, Mike Gilbert wrote: >> On Wed, Jul 18, 2018 at 3:26 AM, Matthew Thode >> wrote: >>> On 18-07-18 09:16:07, Johannes Huber wrote: Hi all, english is not my mother language, so please clarify what bup means, just seen here: https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ee0e0401478cf30b3ced0405f6b89391e05d2397 Just checked if it was a typo, but can't be: git log --oneline --grep bup | count -l Expected 0 lines, got 1248. >>> It's similiar to a sound you make when you touch something's nose. >>> *boop* >>> >>> I just prefer bup instead. I generally only use it when doing simple >>> bumps of packages (copy ebuilds with only keyword edits). >> My preference is to mention the version being added when committing a >> version bump. eg. "cat/pkg: bump to x.y.z". >> >> Yes, it does take a few more seconds, but I think it is worth the effort. >> > I think more recently I've been following this format. > > cat/pkg: x.y.z bup > But can you please *stop* doing this as well? It is neither clear language *nor* useful reduction. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Adding USE=udev to linux profiles
On 20.07.2018 04:42, Andrew Savchenko wrote: > On Thu, 19 Jul 2018 16:51:17 -0500 Ben Kohler wrote: >> Hello, >> >> I'd like to propose adding USE=udev to our linux profiles (in >> profiles/default/linux/make.defaults probably). This flag is already >> enabled on desktop profiles but it also affects quite a few packages >> used on non-desktop linux systems. >> >> This flag provides useful functionality that most linux users will want. >> I'm a bit surprised that we still don't have it in all linux profiles, >> but I think we've worked around this in the past by adding IUSE=+udev to >> quite a few of those packages (33 packages, 116 ebuilds, by my count). >> >> This missing flag came to my attention again on bug 661584 where lvm2 >> has IUSE=+udev but cryptsetup has only IUSE=udev, so non-desktop users >> have a bit of a mismatch between the 2 and get ugly errors on cryptsetup. >> >> Since this flag only affects linux, I think it makes more sense to set >> it in linux profiles than to use IUSE defaults. >> >> Any objections to this idea? > I have server setups with udev disabled for most packages. So udev > enabled by default will create maintenance problems. While I'm > perfectly fine with udev enabled by default on desktops, it should > not be forced on minimalistic setups like servers or containers. > > Best regards, > Andrew Savchenko +1. widely used profiles should have as least flags enabled by default as possible, I would not be happy with +udev on my servers. signature.asc Description: OpenPGP digital signature
[gentoo-dev] rfc: [QA] Ban policy introduction
Hello, The Gentoo QA team would like to introduce the following policy that would be applied to individuals breaking the state and quality of the main gentoo.git tree ( as we do not have this strictly documented yet): If recommended Gentoo workflow policies are not followed by an individual developer (e.g make major changes to the widely used eclasses without prior discussion on the mailing list or commit changes that lead to multiple CI checks failure), the standard QA procedure is: 1.) Two warnings granted by QA team, after two independent breakages 2.) Revoking the commit access for 14 days These violations will be evaluated individually by all QA team members. Warnings can be revoked, if during 6 months period a developer makes at least 20 non trivial changes not producing more breakages. signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: rfc: [QA] Ban policy introduction
On 29.07.2018 00:40, Mikle Kolyada wrote: > Hello, > > The Gentoo QA team would like to introduce the following policy that > would be applied to individuals breaking the state and quality of the > main gentoo.git tree > > ( as we do not have this strictly documented yet): > > > > If recommended Gentoo workflow policies are not followed by an > individual developer > (e.g make major changes to the widely used eclasses without prior > discussion on the mailing list or > commit changes that lead to multiple CI checks failure), the standard QA > procedure is: > > 1.) Two warnings granted by QA team, after two independent breakages > 2.) Revoking the commit access for 14 days > > These violations will be evaluated individually by all QA team members. > Warnings can be revoked, if during 6 months period a developer makes at > least 20 non trivial changes not producing more breakages. > > > > > > Meh, I sent this one a bit prematurely, sorry for the spam, we will work on it a bit more before it reaches an official point signature.asc Description: OpenPGP digital signature
[gentoo-dev] Last rites: sys-boot/winusb
# Mikle Kolyada (30 Aug 2018) # Dead upstream, does not work properly. # Unmaintained. # Use sys-boot/woeusb instead. sys-boot/winusb signature.asc Description: OpenPGP digital signature
[gentoo-dev] Last rites: sys-process/vixie-cron
# Mikle Kolyada (20 Sep 2018) # Dead upstream and unmaintained for a long time, # has multiple bugs open, use sys-process/cronie # instead (the fork). Removal in 30 days. sys-process/vixie-cron signature.asc Description: OpenPGP digital signature
[gentoo-dev] New project: Gentoo Proctors
Good evening community! It is my pleasure to announce, that after almost 1,5 years of the hard work, the Gentoo Proctors project [1] starts working as was discussed and approved by the Council at their last meeting [2]. The main purpose of the project is to create the disciplinary body handling direct Code of Conduct violations (this allows the Comrel team to focus on the most serious violations). The Code of Conduct page was updated accordingly [3]. I also want to give a shout out to dilfridge for his patience during making it fly! [1] - https://wiki.gentoo.org/wiki/Project:Proctors [2] - https://projects.gentoo.org/council/meeting-logs/20180909-summary.txt [3] - https://wiki.gentoo.org/wiki/Project:Council/Code_of_conduct signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] [PATCH] appimage.eclass: new eclass
On 06.10.2018 14:17, Mykyta Holubakha wrote: > Signed-off-by: Mykyta Holubakha > > I'm proposing to add a new eclass: appimage.eclass, to facilitate > extraction off AppImage bundles. The rationale is that some upstreams > have migrated to distributing their proprietary software exclusively as > AppImage bundles. Why making the separate eclass? Merge it with the unpacker one. signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: net-dns/dnssec-root: Blind stable on arm, critical bug 667774
On 11.10.2018 18:10, Thomas Deutschmann wrote: > Let me quote > https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=f6f6bb91b7f134a121ef9fa1dd504b9ca52c5aa8: > >> net-dns/dnssec-root: Blind stable on arm, critical bug 667774 >> >> Note that this is a major fail for a stable architecture. >> In addition, all arm devboxes are currently offline. >> >> Bug: https://bugs.gentoo.org/667774 >> Signed-off-by: Andreas K. Hüttel >> Package-Manager: Portage-2.3.49, Repoman-2.3.11 > ...and now let's all sit down and enjoy how stable ARM users lose access > to the Internet and have to figure out how to deactivate DNSSEC to get > back online. ;] > > Maybe it is time to destabilize ARM on Gentoo to stop the impression > that we really support ARM. > > Your statement is totally inappropriate, to stabilize a package on arm you have to test the package on all gentoo supported arm varieties what usually takes a lot of time signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Is there any way I can help with pull requests?
On 13.10.2018 15:59, James Le Cuirot wrote: [snip] > Such contributions also frequently have issues as the authors have not done > the developer quizzes. We try to guide contributors through the > necessary changes but this can lead to fatigue on both sides. Quizzes are irrelevant, a person does the quizzes when he/she is ready to be the dev, doing quizzes for quizzes or quizzes to become a developer is the best way to get rejected by the recruiters team. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Is there any way I can help with pull requests?
On 20.10.2018 03:33, Michael Orlitzky wrote: > On 10/13/2018 02:32 PM, Mikle Kolyada wrote: >> Quizzes are irrelevant, a person does the quizzes when he/she is >> ready to be the dev, doing quizzes for quizzes or quizzes to become a >> developer is the best way to get rejected by the recruiters team. > I thought this was kind of a strange thing to say, but just ignored > it... not realizing that you were the recruiters lead. Well, people know that recruiters have the opinion about quizzes, so they think it is pointless to discuss :) > > Why do you say that working on the quizzes will get you rejected? I had > a very positive experience while taking them and learned a lot. The main problem is that lots of (not all) people think, if they have quizzes done, they are ready to be developers, some of them even think if they copy-pasted the answer and give us the quote it is ok and they will pass. The answer for both statements is no. > I've > recommended them to potential contributors in the past as a way to > highlight the areas where they might need to improve, and to generally > improve their knowledge of the devmanual. Quzzes are being treated as an obstacle to be a dev, like "wow, I have to answer so much questions to be the dev, I have no time for this". The short answer is: "if you have no time to fill quizzes you are not ready to be the dev", people who are ready spend very little amount of time filling them with zero difficulty. > > Once the new developer finds a mentor, I would think it saves everyone > valuable time if he has a first draft of the quiz prepared. > signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] net-dns/dnssec-root: Blind stable on arm, critical bug 667774
On 20.10.2018 15:19, Andreas Sturmlechner wrote: > On Freitag, 12. Oktober 2018 14:50:55 CEST Rich Freeman wrote: >> ARM is not a Gentoo security supported arch. >> >> If the ARM maintainers feel that stable keywords make the lives of >> their users better, and it isn't causing problems for anybody else, >> I'm not sure why we should be interfering with this. > That's interesting. If it's not security supported, does that mean we can > simply clean up vulnerable versions and drop every arm revdep to ~arm? > > Or are we supposed to keep vulnerable versions around and drop every keyword > except arm? > > Either way means extra care for this arch. > > > > No, keywords status is irrelevant, it is for the security team meaning that they can release a glsa w/o waiting for the stabilization of the security unsupported arches signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] net-dns/dnssec-root: Blind stable on arm, critical bug 667774
On 20.10.2018 15:26, Andreas Sturmlechner wrote: > On Samstag, 20. Oktober 2018 14:22:04 CEST Mikle Kolyada wrote: >> No, keywords status is irrelevant, it is for the security team meaning >> that they can >> release a glsa w/o waiting for the stabilization of the security >> unsupported arches > In my experience glsa only happens after cleanup, and cleanup only happens > after every arch was done. > > > that's not mandatory, that is what security support means
Re: [gentoo-dev] [PATCH] app-emulation/libvirt-snmp: version bump to 0.0.4
On 25.10.2018 18:31, Michal Privoznik wrote:
> Signed-off-by: Michal Privoznik
> ---
> app-emulation/libvirt-snmp/Manifest | 1 +
> .../libvirt-snmp/libvirt-snmp-0.0.4.ebuild| 40 +++
> 2 files changed, 41 insertions(+)
> create mode 100644 app-emulation/libvirt-snmp/libvirt-snmp-0.0.4.ebuild
>
> diff --git a/app-emulation/libvirt-snmp/Manifest
> b/app-emulation/libvirt-snmp/Manifest
> index ea3d956712a..b7eb38bce37 100644
> --- a/app-emulation/libvirt-snmp/Manifest
> +++ b/app-emulation/libvirt-snmp/Manifest
> @@ -1,2 +1,3 @@
> DIST libvirt-snmp-0.0.2.tar.gz 152790 BLAKE2B
> b2e5eee2d67283112556c52921b14029a90d5cedf0c4575e056475191470a4b6bf5d837f1ca942b848f6509da4aa12daa508bbfc5272e1435e73fbfc290e1967
> SHA512
> 13a522c765d278d3b8f8ab9f32f97c8531f6d131afcb0ce62ae397631db92ed3b585ad221a1f2b3bc17907cc4d61adca4a2071b0458a05f2bff5ca06191e1478
> DIST libvirt-snmp-0.0.3.tar.gz 161186 BLAKE2B
> 1b43e7e81a43d4e969e2e30d7d62776743b3c5fb19929fb1606850946c665ad1ca662bee88743f60f202cd92fc42be1cc2cc94e99bf1d137df61bec09850de93
> SHA512
> 6ffda3594ddc513e05e31e7d347a12e371dca3cc698ca790a70e2d01b2ceac6acb5dd6e3cd19723817b41aa62e0c0a49c01c47cb9ce379ac491856a7e88e5a08
> +DIST libvirt-snmp-0.0.4.tar.gz 157859 BLAKE2B
> e2c8fcdd97ba9b55bd4d318c63f7738024c1360ee10aa4e685c2ea6ca02478206febff30f3e1a82eb1a2dadaa52a377cfbce538e12e33f4ea2fe10b1a089945d
> SHA512
> dbf47e7983f9bd6fcff205fffd1f6006268cca774cf427d39dec84dc7de37b545c0dfcbb2c6f171f55d73487cdec13341097137e24de2dea58ce90494d281162
> diff --git a/app-emulation/libvirt-snmp/libvirt-snmp-0.0.4.ebuild
> b/app-emulation/libvirt-snmp/libvirt-snmp-0.0.4.ebuild
> new file mode 100644
> index 000..f0eb657001f
> --- /dev/null
> +++ b/app-emulation/libvirt-snmp/libvirt-snmp-0.0.4.ebuild
> @@ -0,0 +1,40 @@
> +# Copyright 1999-2018 Gentoo Foundation
> +# Distributed under the terms of the GNU General Public License v2
> +
> +EAPI=7
> +
> +inherit eutils
> +
> +DESCRIPTION="Provides SNMP functionality for libvirt"
> +HOMEPAGE="http://libvirt.org";
> +SRC_URI="http://www.libvirt.org/sources/snmp/${P}.tar.gz";
> +
> +LICENSE="GPL-2"
> +SLOT="0"
> +KEYWORDS="~amd64 ~x86"
> +IUSE=""
> +
> +DEPEND=""
> +RDEPEND="${DEPEND}
> + app-emulation/libvirt
> + net-analyzer/net-snmp"
> +BDEPEND="
> + virtual/pkgconfig"
> +
> +src_install() {
> + default
> + newinitd "${FILESDIR}/libvirt-snmp.initd-r1" "${PN}"
> + newconfd "${FILESDIR}/libvirt-snmp.confd" "${PN}"
> +}
> +
> +pkg_postinst() {
> + elog "This daemon runs as an AgentX sub-daemon for snmpd. You should
> therefore"
> + elog "enable the AgentX functionality in snmpd by specifying the
> following"
> + elog "in /etc/snmp/snmpd.conf:"
> + elog " master agentx"
> + elog "It is further recommended to send traps to the localhost as well
> using"
> + elog "this option:"
> + elog " trap2sink localhost"
> + elog "More information is available here:"
> + elog " http://wiki.libvirt.org/page/Libvirt-snmp";
> +}
could you please stop sending project related stuff to the -dev mailing
list? It is irrelevant place to provide bump patches
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] app-emulation/libvirt-snmp: version bump to 0.0.4
On 26.10.2018 04:04, Matthias Maier wrote: >> could you please stop sending project related stuff to the -dev mailing >> list? It is irrelevant place to provide bump patches > Why? What's the purpose of a developer mailing list then? Because we have github/project alias for that purpose signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Packages up for grabs from xmw@g.o
On 25.11.2018 13:04, Michał Górny wrote: > Hello, everyone. > > Due to long-time inactivity, the following packages are now up for > grabs. Given the length of the list, please forgive me for any > mistakes. [snip] > app-text/zathura-cb > app-text/zathura-djvu > app-text/zathura-meta > app-text/zathura-pdf-mupdf > app-text/zathura-pdf-poppler > app-text/zathura-ps > app-text/zathura > dev-libs/girara I will take zathura and co (already on this) > > sys-auth/pam_fprint > pam team added here signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] adding more entries to profiles/info_pkgs
On 15.12.2018 5:00, Georgy Yakovlev wrote: > Hi, > > while lurking on bugzilla lately I noticed that package part of > "emerge --info" output may be lacking in some cases. > > Good candidates for adding to that file are: > > virtual/rust > llvm ? > dev-util/meson > dev-util/ninja > > that should be enough to provide a bit more to initial information without > going crazy and clobbering output too much. > > Thoughts? > > Regards, > Georgy Yakovlev > Gentoo Linux Developer They all are not way too much spread, especially rust. Do not think it worth to include them. meson can be reconsidered later, as more and more people are using this one. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] glep-0063: Allow a single primary/signing key for smartcards
On 25.04.2019 14:32, Rich Freeman wrote: > [snip] > Patch follows: > > > diff --git a/glep-0063-v3.rst b/glep-0063-v3.rst > index 5895873..86e5fd9 100644 > --- a/glep-0063-v3.rst > +++ b/glep-0063-v3.rst > @@ -12,6 +12,12 @@ OpenPGP key management policies for the Gentoo > Linux distribution. > Changes > === > > +v3 > + The requirement to have a separate signing and primary key was removed > + in the case of keys generated/stored on smartcards, to encourage the use > + of these keys, and acknowledging that the main use case for a separate > + primary key is largely fulfilled by having all the keys stay offline. > + > v2 >The distinct minimal and recommended expirations have been replaced >by a single requirement. The rules have been simplified to use > @@ -69,7 +75,8 @@ not be used to commit. > at least 256-bit. All subkey self-signatures must use this digest. > > 2. Signing subkey that is different from the primary key, and does not > - have any other capabilities enabled. > + have any other capabilities enabled. This requirement does not apply > + if the primary key was generated on a smartcard. > > 3. Primary key and the signing subkey are both of type EITHER: > > > I strongly disagree with this change. If you generated your keys straight on the device you are not able to make a backup later. The best practice here is to have a separate USB stick that is never used for purposes other than private keys storing. Also paperkey backups should serve as the last resort. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Packages up for grabs due to nimiux's retirement
On 20.05.2019 18:53, Michał Górny wrote: > Hello, > > The following packages are now up for grabs: > > app-portage/conf-update > app-admin/logrotate > app-admin/mktwpol > app-admin/swatchdog > app-admin/tripwire > app-emulation/free42 > app-emulation/libdsk > app-emulation/x48 > app-emulation/xcpc > app-misc/linux-logo > app-misc/muttprint > app-misc/vifm > x11-wm/stumpwm-contrib > x11-wm/stumpwm > I will rake logrotate
[gentoo-dev] Last rites: app-text/winefish, dev-tex/oesch
# Mikle Kolyada (2019-08-05) # dead upstream, does not work and compile #(bug #688006, bug #686630) # masked for removal in 14 days app-text/winefish dev-tex/oesch signature.asc Description: OpenPGP digital signature
[gentoo-dev] [PATCH] glep-0081: prohibit KEYWORDS altering
Signed-off-by: Mikle Kolyada --- As discussed with mgorny at #gentoo-qa glep-0081.rst | 3 +++ 1 file changed, 3 insertions(+) diff --git a/glep-0081.rst b/glep-0081.rst index 082e705..e5a4db2 100644 --- a/glep-0081.rst +++ b/glep-0081.rst @@ -107,6 +107,9 @@ a build time dependency (``DEPEND``) must be used. If the user is needed at install and/or run time, a run time dependency (``RDEPEND``) must be used. +Both ``acct-group`` and ``acct-user`` eclasses have the ``KEYWORDS`` +variable predefined, keywords must not be altered locally via ebuilds. + Maintaining users/groups -- 2.21.0
Re: [gentoo-dev] [PATCH] glep-0081: prohibit KEYWORDS altering
On 07.08.2019 18:32, Brian Evans wrote: > On 8/7/2019 11:20 AM, Mikle Kolyada wrote: >> Signed-off-by: Mikle Kolyada >> --- >> As discussed with mgorny at #gentoo-qa >> glep-0081.rst | 3 +++ >> 1 file changed, 3 insertions(+) >> >> diff --git a/glep-0081.rst b/glep-0081.rst >> index 082e705..e5a4db2 100644 >> --- a/glep-0081.rst >> +++ b/glep-0081.rst >> @@ -107,6 +107,9 @@ a build time dependency (``DEPEND``) must be used. If >> the user is >> needed at install and/or run time, a run time dependency (``RDEPEND``) >> must be used. >> >> +Both ``acct-group`` and ``acct-user`` eclasses have the ``KEYWORDS`` >> +variable predefined, keywords must not be altered locally via ebuilds. >> + >> >> Maintaining users/groups >> >> > I object to this as I feel they can incorrect such as on prefix. > > Also, this goes against the established practice of committing directly > to stable. These are exactly the same as virtuals as "they install > nothing" and "just run a script" (to verify dependencies). > > Brian They are not exactly the same as virtuals, ~arch keywords in virtuals make sense because they may have dependency providers that are also in ~arch status. These eclasses pull nothing, therefore keywords altering here meaningless by definition. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] glep-0081: prohibit KEYWORDS altering
On 07.08.2019 18:49, Michał Górny wrote: > On Wed, 2019-08-07 at 18:20 +0300, Mikle Kolyada wrote: >> Signed-off-by: Mikle Kolyada >> --- >> As discussed with mgorny at #gentoo-qa >> glep-0081.rst | 3 +++ >> 1 file changed, 3 insertions(+) >> >> diff --git a/glep-0081.rst b/glep-0081.rst >> index 082e705..e5a4db2 100644 >> --- a/glep-0081.rst >> +++ b/glep-0081.rst >> @@ -107,6 +107,9 @@ a build time dependency (``DEPEND``) must be used. If >> the user is >> needed at install and/or run time, a run time dependency (``RDEPEND``) >> must be used. >> >> +Both ``acct-group`` and ``acct-user`` eclasses have the ``KEYWORDS`` >> +variable predefined, keywords must not be altered locally via ebuilds. >> + >> >> Maintaining users/groups >> > I've told you I don't believe this belongs in the GLEP. It's > implementation detail, and if at all, it should go through tree policy. > We did not come to a conclusion about where this should be written down if you remember, in any way I am concerned about the fact, not about a place where we write it down, the main intention here is that all the developers must follow the same rules. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Packages up for grabs:
I will take a look at mpv and add myself there 25 сентября 2019 г. 20:19:50 GMT+03:00, "Michał Górny" пишет: >On Wed, 2019-09-25 at 12:47 +0200, Michał Górny wrote: >> Hi, >> >> Due to the proxied maintainer retiring, the following packages are >now >> up for grabs: > >I should've probably mentioned: > >[b ] media-video/mpv > >as well since it falls back to media-video@, and has multiple bugs >open. > >> Packages marked with [b] have bugs reported, packages marked with [v] >> need a version bump, [?] means repology doesn't know the package. >> > >-- >Best regards, >Michał Górny -- Простите за краткость, создано в K-9 Mail.
Re: [gentoo-dev] [PATCH 1/1] kernel-2.eclass: Support move of genpatches tarballs from /space/distfiles-local to devspace
On 10.10.2019 13:04, Mike Pagano wrote: > On Wed, Oct 09, 2019 at 06:23:06PM -0700, Alec Warner wrote: >>On Wed, Oct 9, 2019 at 10:01 AM Mike Pagano <[1]mpag...@gentoo.org> >>wrote: >> >> This change will support moving the genpatches tarballs from >> /space/distfiles-local to >> the devspace ~developer/public_html/dist/genpatches >> >>I think it would help if you discussed why we were making this change. >>(I mean I can guess why, but it's not obvious.) >>-A >>Â > I was informed that use of /space/distfiles-local is deprecated in favor > of devspace. > > > https://devmanual.gentoo.org/general-concepts/mirrors/index.html > > This is not really true, (otherwise we would have to upload literally 8500 tarballs for texlive to my devspace). I'd say narrowing an eclass' URIs to the selected group of people is even worse for long-term usage. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] New distfile mirror layout
On 21.10.2019 3:05, Joshua Kinard wrote:
> So looking at texlive-latexextra-2019-r2.ebuild, it defines three variables:
>
> - TEXLIVE_MODULE_CONTENTS, with 1,241 space-delimited module names
> - TEXLIVE_MODULE_DOC_CONTENTS, with 1,227 space-delimited doc names
> - TEXLIVE_MODULE_SRC_CONTENTS, with 745 space-delimited src names
>
> Then, in texlive-module.eclass, there's these loops:
>
> for i in ${TEXLIVE_MODULE_CONTENTS}; do
> SRC_URI="${SRC_URI}
> mirror://gentoo/texlive-module-${i}-${PV}.${PKGEXT}"
> done
>
> # Forge doc SRC_URI
> [ -n "${TEXLIVE_MODULE_DOC_CONTENTS}" ] && SRC_URI="${SRC_URI} doc? ("
> for i in ${TEXLIVE_MODULE_DOC_CONTENTS}; do
> SRC_URI="${SRC_URI}
> mirror://gentoo/texlive-module-${i}-${PV}.${PKGEXT}"
> done
> [ -n "${TEXLIVE_MODULE_DOC_CONTENTS}" ] && SRC_URI="${SRC_URI} )"
>
> # Forge source SRC_URI
> if [ -n "${TEXLIVE_MODULE_SRC_CONTENTS}" ] ; then
> SRC_URI="${SRC_URI} source? ("
> for i in ${TEXLIVE_MODULE_SRC_CONTENTS}; do
> SRC_URI="${SRC_URI}
> mirror://gentoo/texlive-module-${i}-${PV}.${PKGEXT}"
> done
> SRC_URI="${SRC_URI} )"
> fi
>
> I think this is definitely an issue with how this package is laying out its
> needed distfiles. It really should be leveraging CTAN system at a minimum
> to fetch all of the needed distfiles so we can get them off of our
> distfiles mirror. Then it would be interesting to re-run the math on
> the distfiles distribution using the different schemes highlighted in the
> GLEP-75 paper.
TexLive distributes collections of macros, not packages separately,
they make their packaging based on CTAN. In the meantime CTAN packages
are not versioned, they only have internal release number, no tags,
releases and so on, see [1].
I also fail to see what problem you try to solve when suggest fetching
macros from CTAN, you are going to have the same amount of data mirrored
as a result.
[1] - https://ctan.org/tex-archive/systems/texlive/tlnet/archive
signature.asc
Description: OpenPGP digital signature
[gentoo-dev] packages up for grabs net-fs/{mc,minio}
net-fs/mc net-fs/minio are for grabs now. Upstream is _very_ active (to say least), be ready for frequent version bumps. Also they often changes dependencies as well. signature.asc Description: OpenPGP digital signature
[gentoo-dev] acct-user/mpd request for ID
It will be 45 as this one was not taken. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] packages up for grabs
I will take app-misc/ranger 19 ноября 2019 г. 3:47:22 GMT+03:00, Tim Harder пишет: >The following list of packages are up for grabs that I dropped myself >as >as a direct maintainer from. There are probably a significantly larger >number that I've indirectly maintained hiding under the guise of older >projects that mostly act likes herds (e.g. graphics, sound, and vim to >name a few) so interested parties should feel free to directly add >themselves as maintainers for such packages. > >Note that some of the packages in this list already have maintainers, >but I'm sure most of them wouldn't mind co-maintainers. > >app-admin/gopass >app-admin/lnav >app-arch/atool >app-arch/libpar2 >app-arch/par2cmdline >app-arch/pigz >app-backup/bup >app-backup/duplicity >app-doc/zsh-lovers >app-editors/hteditor >app-forensics/libewf >app-misc/binwalk >app-misc/dateutils >app-misc/evemu >app-misc/fslurp >app-misc/jq >app-misc/ltunify >app-misc/ranger >app-misc/rq >app-misc/skim >app-misc/task >app-misc/terminal-colors >app-shells/gentoo-zsh-completions >app-shells/zsh >app-text/cpdf >app-text/csvfix >app-text/docx2txt >app-text/extract_url >app-text/restview >app-text/txt2man >app-text/xlsx2csv >app-text/yodl >dev-lang/swig >dev-libs/libyaml >dev-libs/rremove >dev-libs/stfl >dev-ml/camlpdf >dev-util/archdiff >dev-util/coccigrep >dev-util/coccinelle >dev-util/cpputest >dev-util/icmake >dev-vcs/bfg >dev-vcs/hgview >dev-vcs/tig >games-util/wit >net-dialup/neocon >net-fs/btfs >net-fs/sshfs >net-im/bitlbee >net-irc/weechat >net-mail/t-prot >net-misc/autossh >net-misc/proxychains >net-news/newsboat >net-print/sshlpr >net-proxy/mitmproxy >net-proxy/sshuttle >sys-apps/ack >sys-apps/moreutils >sys-apps/pick >sys-apps/ripgrep >sys-apps/the_silver_searcher >sys-fs/archivemount >sys-fs/avfs >sys-fs/bindfs >sys-fs/fuse >sys-fs/fuse-common >sys-fs/rar2fs >sys-process/cronutils >sys-process/parallel >sys-process/procenv >www-client/lynx >www-client/qutebrowser >x11-misc/sxhkd >x11-misc/unclutter-xfixes >x11-misc/urxvt-font-size >x11-misc/urxvt-perls >x11-misc/xdo >x11-terms/kitty >x11-wm/bspwm >x11-wm/herbstluftwm >x11-wm/qtile >x11-wm/subtle -- Простите за краткость, создано в K-9 Mail.
Re: [gentoo-dev] [PATCH] package.deprecated: Create initial template
+1 5 декабря 2019 г. 19:09:57 GMT+03:00, "Michał Górny" пишет: >Signed-off-by: Michał Górny >--- > profiles/package.deprecated | 17 + > 1 file changed, 17 insertions(+) > create mode 100644 profiles/package.deprecated > >diff --git a/profiles/package.deprecated b/profiles/package.deprecated >new file mode 100644 >index ..b4803a4ce68f >--- /dev/null >+++ b/profiles/package.deprecated >@@ -0,0 +1,17 @@ >+ >+# >+# This file specifies packages that are considered deprecated (but not >+# masked yet). It will trigger pkgcheck warnings whenever other >+# packages depend on them. >+# >+# When you add an entry to the top of this file, add your name, the >date >+# in the UTC timezone, and an explanation of why something is getting >+# deprecated. >+# >+## Example: >+## >+## # Dev E. Loper (2019-07-01) >+## # This is no longer supported upstream, please switch to >dev-foo/bar. >+## dev-foo/foo >+ >+#--- END OF EXAMPLES --- >-- >2.24.0 -- Простите за краткость, создано в K-9 Mail.
[gentoo-dev] crypto@ packages up for grabs
These are up for grabs due to the crypto@ project being disbanded. app-admin/ranpwd app-crypt/aescrypt app-crypt/aespipe app-crypt/asedriveiiie-serial app-crypt/asedriveiiie-usb app-crypt/asekey app-crypt/bcwipe app-crypt/bsign app-crypt/cardpeek app-crypt/ccrypt app-crypt/chntpw app-crypt/coolkey app-crypt/dieharder app-crypt/fcrackzip app-crypt/gnupg-pkcs11-scd app-crypt/gpa app-crypt/gpgme app-crypt/hmaccalc app-crypt/libykneomgr app-crypt/loop-aes-losetup app-crypt/mcrypt app-crypt/md6sum app-crypt/mhash app-crypt/nasty app-crypt/nwipe app-crypt/onak app-crypt/pdfcrack app-crypt/pius app-crypt/pkcrack app-crypt/pkcs11-data app-crypt/pkcs11-dump app-crypt/quickcrypt app-crypt/rainbowcrack app-crypt/scrypt app-crypt/ssdeep app-crypt/stan app-crypt/tc-play app-crypt/tpm-emulator app-crypt/tpm-tools app-crypt/tpm2-abrmd app-crypt/tpm2-tools app-crypt/tpm2-totp app-crypt/tpm2-tss-engine app-crypt/tpm2-tss app-crypt/trousers app-crypt/xca app-eselect/eselect-pinentry dev-libs/libassuan dev-libs/libgpg-error dev-libs/libksba dev-libs/libmcrypt dev-libs/libp11 dev-libs/libtasn1 dev-libs/nettle dev-libs/npth dev-libs/opencryptoki dev-libs/openct dev-libs/opensc dev-libs/pakchois dev-libs/pkcs11-helper dev-libs/softhsm dev-libs/xmlsec net-wireless/wepdecrypt sys-apps/ifd-gempc sys-apps/pcsc-slb-rf72-drv sys-auth/pam_p11 sys-fs/ecryptfs-utils sys-fs/loop-aes signature.asc Description: OpenPGP digital signature
[gentoo-dev] Last rites: media-gfx/cropgui
# Mikle Kolyada (2020-02-21) # Tiny package with semi-dead upstream. Unlikely useful. # Blocks pygtk removal. # Removal in 30 days. media-gfx/cropgui signature.asc Description: OpenPGP digital signature
[gentoo-dev] Last rites: sys-apps/hardened-shadow virtual/shadow
# Mikle Kolyada (2020-03-07) # virtual/shadow has the only alive provider. # sys-apps/hardened-shadow is unmaintained for the past # five years (at least). Upstream is dead. # Removal in 30 days. sys-apps/hardened-shadow virtual/shadow signature.asc Description: OpenPGP digital signature
[gentoo-dev] [ GLSA 201412-50 ] getmail: Information disclosure
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Gentoo Linux Security Advisory GLSA 201412-50 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - http://security.gentoo.org/ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Severity: Normal Title: getmail: Information disclosure Date: December 28, 2014 Bugs: #524684 ID: 201412-50 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Synopsis Multiple vulnerabilities have been discovered in getmail, allowing remote attackers to obtain sensitive information. Background == getmail is a POP3 mail retriever with reliable Maildir and mbox delivery. Affected packages = --- Package / Vulnerable /Unaffected --- 1 net-mail/getmail < 4.46.0 >= 4.46.0 Description === Multiple vulnerabilities have been discovered in getmail. Please review the CVE identifiers referenced below for details. Impact == A remote attacker could cause a man-in-the-middle attack via multiple vectors to obtain sensitive information. Workaround == There is no known workaround at this time. Resolution == All getmail users should upgrade to the latest version: # emerge --sync # emerge --ask --oneshot --verbose ">=net-mail/getmail-4.46.0" References == [ 1 ] CVE-2014-7273 http://nvd.nist.gov/nvd.cfm?cvename=CVE-2014-7273 [ 2 ] CVE-2014-7274 http://nvd.nist.gov/nvd.cfm?cvename=CVE-2014-7274 [ 3 ] CVE-2014-7275 http://nvd.nist.gov/nvd.cfm?cvename=CVE-2014-7275 Availability This GLSA and any updates to it are available for viewing at the Gentoo Security Website: http://security.gentoo.org/glsa/glsa-201412-50.xml Concerns? = Security is a primary focus of Gentoo Linux and ensuring the confidentiality and security of our users' machines is of utmost importance to us. Any security concerns should be addressed to secur...@gentoo.org or alternatively, you may file a bug at https://bugs.gentoo.org. License === Copyright 2014 Gentoo Foundation, Inc; referenced text belongs to its owner(s). The contents of this document are licensed under the Creative Commons - Attribution / Share Alike license. http://creativecommons.org/licenses/by-sa/2.5 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [ GLSA 201412-50 ] getmail: Information disclosure
28.12.2014 20:38, Mikle Kolyada пишет: > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > Gentoo Linux Security Advisory GLSA 201412-50 > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > http://security.gentoo.org/ > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > > Severity: Normal > Title: getmail: Information disclosure > Date: December 28, 2014 > Bugs: #524684 >ID: 201412-50 > > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > > Synopsis > > > Multiple vulnerabilities have been discovered in getmail, allowing > remote attackers to obtain sensitive information. > > Background > == > > getmail is a POP3 mail retriever with reliable Maildir and mbox > delivery. > > Affected packages > = > > --- > Package / Vulnerable /Unaffected > --- > 1 net-mail/getmail < 4.46.0 >= 4.46.0 > > Description > === > > Multiple vulnerabilities have been discovered in getmail. Please review > the CVE identifiers referenced below for details. > > Impact > == > > A remote attacker could cause a man-in-the-middle attack via multiple > vectors to obtain sensitive information. > > Workaround > == > > There is no known workaround at this time. > > Resolution > == > > All getmail users should upgrade to the latest version: > > # emerge --sync > # emerge --ask --oneshot --verbose ">=net-mail/getmail-4.46.0" > > References > == > > [ 1 ] CVE-2014-7273 > http://nvd.nist.gov/nvd.cfm?cvename=CVE-2014-7273 > [ 2 ] CVE-2014-7274 > http://nvd.nist.gov/nvd.cfm?cvename=CVE-2014-7274 > [ 3 ] CVE-2014-7275 > http://nvd.nist.gov/nvd.cfm?cvename=CVE-2014-7275 > > Availability > > > This GLSA and any updates to it are available for viewing at > the Gentoo Security Website: > > http://security.gentoo.org/glsa/glsa-201412-50.xml > > Concerns? > = > > Security is a primary focus of Gentoo Linux and ensuring the > confidentiality and security of our users' machines is of utmost > importance to us. Any security concerns should be addressed to > secur...@gentoo.org or alternatively, you may file a bug at > https://bugs.gentoo.org. > > License > === > > Copyright 2014 Gentoo Foundation, Inc; referenced text > belongs to its owner(s). > > The contents of this document are licensed under the > Creative Commons - Attribution / Share Alike license. > > http://creativecommons.org/licenses/by-sa/2.5 > > Sorry for mailspam, wrong list :/
Re: [gentoo-dev] Gentoo-sources - should we stable?
02.01.2015 20:25, Mike Pagano пишет: > This is in no way complaining about how long it takes to stabilize a kernel. As for this fact. The main problem is that: we only can test sources on machine we can reboot. For example me and Agostino have access to the rest hardware like alpha, ia64 and so on. But we can't reboot it for clear reason i think. Another side is that: not all hardware i have around can use gentoo-sources, so it works with custom kernels.
Re: [gentoo-dev] Nominate global USE-flag harfbuzz
07.01.2015 22:00, Mart Raudsepp пишет: > On K, 2015-01-07 at 07:29 +0100, Peter Stuge wrote: >> $ grep :harfbuzz profiles/use*desc >> profiles/use.local.desc:dev-libs/efl:harfbuzz - Enable complex text shaping >> and layout support. >> profiles/use.local.desc:dev-qt/qtgui:harfbuzz - Use media-libs/harfbuzz for >> text shaping (experimental in Qt 5.3.x, default in Qt 5.4.0 and later). If >> enabled, it can still be disabled at runtime by setting QT_HARFBUZZ >> environment variable to "old". >> profiles/use.local.desc:media-libs/freetype:harfbuzz - Use >> media-libs/harfbuzz for auto-hinting OpenType fonts. WARNING: may trigger >> circular dependencies! >> profiles/use.local.desc:media-libs/libass:harfbuzz - Enables OpenType >> shaping via media-libs/harfbuzz. >> >> Or isn't 4 enough? > I don't know about that, but I would say at least half of them should > continue to carry on a specific description of what the USE flag does in > its metadata.xml. > I guess consider this just a friendly slightly unrelated reminder that > when making USE flags global, please don't end up losing information by > deleting the specific description. And consider adding a local > description to a packages global USE flag usage if you can describe its > effect more specifically. > And if some tooling doesn't support that, well, bad luck. My tool does > (less metadata.xml) > > > Mart It must be at least 5 packages, as per our policy.
Re: [gentoo-dev] Maintainer stabilizations
08.01.2015 20:15, Michael Orlitzky пишет: > I vaguely remember a discussion about maintainers stabilizing their own > packages -- maybe just on x86 and amd64 -- to take the load off of the > arch teams. > > Did that really happen or am I making it up? Is it written down anywhere? > amd64/x86 are major arches. They can be stabilized if package maintainer has appropriate hardware. Even without arch teams membership.
Re: [gentoo-dev] Maintainer stabilizations
08.01.2015 21:12, Michael Orlitzky пишет: > On 01/08/2015 12:57 PM, Mikle Kolyada wrote: >> 08.01.2015 20:15, Michael Orlitzky пишет: >>> I vaguely remember a discussion about maintainers stabilizing their own >>> packages -- maybe just on x86 and amd64 -- to take the load off of the >>> arch teams. >>> >>> Did that really happen or am I making it up? Is it written down anywhere? >>> >> amd64/x86 are major arches. They can be stabilized if package maintainer >> has appropriate hardware. Even without arch teams membership. >> > What's a major arch? The devmanual still says[0], > > Moving a package from ~arch to arch is done only by the relevant arch > teams. > > According to [1] that section is no longer correct, but only x86 and > amd64 are exceptions to the rule that used to be exceptions but then > weren't anymore. > > I'm going to write a devmanual patch but don't want to sound like a lunatic. > > > [0] http://devmanual.gentoo.org/keywording/index.html > [1] http://article.gmane.org/gmane.linux.gentoo.devel/89711 > > Major arches are amd64 and x86, nothing more. There is a bug for it already [1] [1] - https://bugs.gentoo.org/show_bug.cgi?id=510198
Re: [gentoo-dev] Hey arch teams, we need your input!
11.04.2015 23:51, Pacho Ramos пишет: > El sáb, 11-04-2015 a las 21:50 +0200, Andreas K. Huettel escribió: >> Hi all, >> >> the debate about arches, keywording and stabilization procedures is >> coming up again. >> >> People have told me that the whole debate seems to turn into some sort >> of arch-team bashing. That is definitely not the plan. Also, >> supporting many different types of hardware is actually one of the >> strong points of Gentoo. >> >> So, it would be absolutely great to have more feedback from the arch >> teams, especially suggestions >> * how to improve procedures, >> * where you see the main problems, and >> * where you don't see problems... >> >> Please make your voice heard. Noone wants to overrule an active team. >> >> Cheers, >> Andreas >> >> PS. I've ommitted amd64, hppa, and arm from the manual CC list because >> these are the stable arches I'm definitely not worried about. >> Obviously feedback is appreciated anyway. >> > I think we need a common place to share all the scripts we are needing > to use to: > - Stabilize a bunch of packages from different bug reports > - Stabilize big lists from *one* bug report > - All the bug handling (unCC arches when needed, close the bug when it's > the last arch) > - The scripts running "repoman full" on the stable candidates to report > if they are not ok due to missing deps. > - ... > > And, ideally, that multiple script should be unified if possible once we > can see them all in that repo and take the best from them :) > > Ok. Here is my small input. I've been around arch teams and testing for a long time. And i'm mainly taking care of system-important packages. In my opinion the main problem is.. people. Now we have lack of manpower as usual. So i think, we have to drop stable packages for some so-called "fun packages". I've noticed for example, that gimp has stable alpha keyword. Have you ever run gimp on alpha servers? I am sure, there are more stable-unneeded packages like games, maybe some programming languages, and so on for others non-mainstream arches.
Re: [gentoo-dev] Sparc and Ia64 keyword clean up
15.05.2015 02:33, Jack Morgan пишет: > I'm actively working on stablereq for sparc and ia64. It took some > weeks to get my systems and process working. I hope to reduce the open > bugzilla in the next several weeks. Please don't just drop stable > keywords, even though the bugzilla has been open for a long time. I'd > appreciate it if you could send me a quick email asking to do your > package first, instead of just dropping the keyword. I'll put your > request at the top of my queue. > > Once I’m done with stablereq queue, I'll look to keywordreq queue. My > over plan is to reduce the total number of keyworded packages to a > more maintainable level. I'll send out more specific details for each > arch this week. Any help is greatly appreciated > > > Thanks, > ++ I went through some sparc STABLEREQs too.
Re: [gentoo-dev] RFC: ban EAPI 1
10.06.2015 23:43, Ulrich Mueller пишет: > Hi, > The number of EAPI 1 ebuilds in the Portage tree has decreased to > a total of 60, corresponding to 0.16 %. > > We briefly discussed in the QA team if we should demote EAPI 1 in > layout.conf from "eapis-deprecated" to "eapis-banned". This would > have the consequence that repoman would refuse to commit packages > containing such ebuilds. AFAICS there would be no impact on users. > > What do you think? > > Ulrich lets do it quick. :)
Re: [gentoo-dev] Git Migration: launch plan & schedule (2015/Aug/08-09)
03.07.2015 00:39, Robin H. Johnson пишет: > Hi all, > > The Git migration is moving forward, and I'd like to announce a > tentative schedule for that end. > https://wiki.gentoo.org/wiki/Project:Infrastructure/Git_migration#Status > > 2015/08/08 15:00 UTC - Freeze > 2015/08/08 19:00 UTC - Git commits open for developers > 2015/08/09 01:00 UTC - Rsync live again (with lagged changelog) > 2015/08/11 - History repo available to graft > 2015/08/12 - rsync mirrors carry up-to-date changelogs again > > I've allocated time for an 8 hour freeze, but hope to be completed much > sooner than that. > Thanks Robbin and whole the Infrastructure team! Great and i'd even say historical news!
Re: [gentoo-dev] Git Migration: launch plan & schedule (2015/Aug/08-09)
08.08.2015 20:47, Robin H. Johnson пишет: > On Thu, Jul 02, 2015 at 09:39:52PM +, Robin H. Johnson wrote: >> 2015/08/08 15:00 UTC - Freeze >> 2015/08/08 19:00 UTC - Git commits open for developers >> 2015/08/09 01:00 UTC - Rsync live again (with lagged changelog) >> 2015/08/11 - History repo available to graft >> 2015/08/12 - rsync mirrors carry up-to-date changelogs again >> >> I've allocated time for an 8 hour freeze, but hope to be completed much >> sooner than that. > Starting late due to $reasons, freeze is now at 18:00 UTC (14 minutes > from now). > Where and how should we add new developers these days to grant them access to the portage tree?
Re: [gentoo-dev] Summary line
11.08.2015 17:36, hasufell пишет: > On 08/11/2015 04:28 PM, Ian Stakenvicius wrote: >> On 11/08/15 04:57 AM, Tobias Klausmann wrote: >>> The more we stuff into the summary line, the harder it will be to >>> write meaningful summaries. And thus, people will write crappy ones >>> or ignore the length limit. I recommend against any more >>> prescription over "Add the the cat/pn if meaningful, don't use more >>> than 75 characters". >>> The cat/pn rule is tricky anyway: what if one commit touches 100 >>> packages? Or should that be split into 100 commits for easier >>> partial rollback? >>> Regards, Tobias >> >> >> The summary line limit is going to be a real issue, tbh. I think it >> would probably be best to adopt the convention of putting a few >> choice, perhaps even canned, phrases in the summary line, and ensure >> any and all details (effectively what the summary line used to be for >> when it had practically no limit) within the commit message body instead >> . >> >> Stuff like 'cat/pn: version bumps', 'cat/pn: new features', 'cat/pn: >> adjusted dependencies' are generic (and short) enough yet descriptive >> enough to see what went on while scanning the log. 'Fix bug' IMO in >> the summary doesn't work at all because, although its accurate, that >> bug could literally be anything at all. >> >> Multi-package commits are going to be more of an issue of course.. I >> did one last night, fortunately I think I can get away with using >> "mozilla packages" in place of cat/pn since it is a very specific set >> of packages. Perhaps for sweeping changes like that we can use the >> herdname or projectname or the category name (if its a particular >> category only)? >> >> >> > The "CATEGORY:" prefix is already in the wiki. Interesting idea about > projectname/herdname prefix. > > I've already seen someone (I think ulm) prefixing with [QA]. > > I don't feel strong about this. IMO, if there is no useful prefix... > just don't use any. The lack of prefix will make it obvious that this is > a larger change. But project/herd specific prefixes could still make sense. > Mgorny has commited a fix to live portage https://github.com/gentoo/portage/commit/46dafadff58da0220511f20480b73ad09f913430 I think it will be in the tree soon.
Re: [gentoo-dev] Mirroring Gentoo project/team members on GitHub
11.08.2015 17:32, Michał Górny пишет: > Hello, everyone. > > Now that we're officially on git and can officially use pull requests > to provide rapid community interaction, it'd be convenient to have > a little better framework for pinging package maintainers. > > With the unofficial mirror/pull request project, I was either looking > for project member GitHub accounts and pinging found project members by > name, or talking to them directly on IRC. However, with the growth in > number of pull requests this will become more and more inconvenient. > Therefore, I think it's time to be able to mirror teams willing to work > with GitHub community there for easier 'pings'. > > I have two ideas right now: > > 1. creating GitHub Gentoo project teams corresponding to willing Gentoo > teams, > > 2. preparing lists of GitHub usernames on project wiki pages. > > Solution 1. is cleaner. In this case, we create GitHub teams under > the Gentoo projects, and add appropriate Gentoo developers having > GitHub accounts to the teams. Then, in PRs we can just ping the whole > team like @Gentoo/Qt or like. > > Solution 2. avoids adding any GitHub teams. In this case, in team wiki > page we collect team member usernames like "@Pesa, @kensington, ..." so > we could copy-paste it to pull requests. We still require extra effort > when 'assigning' PRs but at least I don't have to lookup the same > people over and over again. > > With some Wiki people help, we could even implement updating GitHub > teams automatically following Wiki member changes. > > Your thoughts? > First one more clear. Jut don't forget update it, when someone new join the team, as usual.
Re: [gentoo-dev] Is the $Id$ line in our ebuilds still useful?
13.08.2015 18:36, William Hubbs пишет: > All, > > I understood the usefulness of this line to some when we were using CVS > since it expanded into the ebuild revision, date, etc. > > This expansion doesn't take place under git, so now I don't understand > the usefulness of this line. If I have missed something, can someone > fill me in, or if it isn't useful any more can we consider removing it? > > Thanks, > > William > Hmm, the same question here. As far as i remember git does not depend on any ebuild's header.
Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: dev-python/intelhex/
21.10.2015 02:25, hasufell пишет:
> On 10/20/2015 04:02 PM, Mike Frysinger wrote:
>> commit: a68f2479fba9422913cb760166316bf489d72ca8
>> Author: Vincent Palatin chromium org>
>> AuthorDate: Tue Oct 20 14:01:34 2015 +
>> Commit: Mike Frysinger gentoo org>
>> CommitDate: Tue Oct 20 14:01:50 2015 +
>> URL:https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=a68f2479
>>
>> dev-python/intelhex: new package from Chromium OS
>>
>> dev-python/intelhex/Manifest| 1 +
>> dev-python/intelhex/intelhex-2.0.ebuild | 18 ++
>> dev-python/intelhex/metadata.xml| 9 +
>> 3 files changed, 28 insertions(+)
>>
> [...]
>
>> +
>> +EAPI="5"
>> +
>> +PYTHON_COMPAT=( python{2_7,3_3,3_4,3_5} )
>> +
>> +inherit distutils-r1
>> +
>> +DESCRIPTION="Python library for Intel HEX files manipulations"
>> +HOMEPAGE="http://pypi.python.org/pypi/IntelHex/
>> https://github.com/bialix/intelhex";
>> +SRC_URI="mirror://pypi/I/IntelHex/${P}.tar.gz"
>> +
>> +LICENSE="BSD"
>> +SLOT="0"
>> +KEYWORDS="*"
> What does that KEYWORDS mean? Unless I read PMS wrong [0][1], this isn't
> even allowed. And I don't see a single ebuild in the tree with that syntax.
>
> Also, my package manager chokes on it. Repoman not, so that looks like a
> bug.
>
>
> [0] https://dev.gentoo.org/~ulm/pms/head/pms.html#x1-260003.1.6
> [1] https://dev.gentoo.org/~ulm/pms/head/pms.html#x1-690007.3.2
>
As per commit message, it was imported from chromium os, AFAIR, they
have their own rules about how to write ebuilds, and of course our PMS
doesn't allow such things.
[gentoo-dev] Last rites: app-text/xindy dev-tex/tex4ht
# Mikle Kolyada (2020-06-13) # Multiple forks. # Merged into the app-text/texlive-core package. # Removal in 30 days. app-text/xindy # Mikle Kolyada (2020-06-13) # have been shipped with dev-texlive/texlive-plaingeneric # for the very long time. Removal in 14 days. dev-tex/tex4ht signature.asc Description: OpenPGP digital signature
[gentoo-dev] News Item: sys-libs/pam-1.4.0 upgrade
Attached itle: sys-libs/pam-1.4.0 upgrade Author: Mikle Kolyada Content-Type: text/plain Posted: 2020-06-?? Revision: 1 News-Item-Format: 2.0 Display-If-Installed: >=sys-libs/pam-1.4.0 Display-If-Installed: >=sys-auth/pambase-20200618 Starting with the 1.4.0 release [1], we don't offer these modules anymore: * pam_tally and pam_tally2 have been deprecated and replaced by the pam_faillock module * pam_cracklib has been deprecated and replaced by the pam_passwdqc module These changes affected our basic PAM stack configuration. You only need to take action if: * you made manual changes to the PAM stack, or * you use FEATURES="-config-protect-if-modified" option If this applies to you, please make sure to either run the etc-update or dispatch-conf command in order to sync your configuration. Failure to do this may result in your system becoming inaccessible. [1] - https://github.com/linux-pam/linux-pam/releases/tag/v1.4.0 signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: News Item: sys-libs/pam-1.4.0 upgrade
On 20.06.2020 16:55, Mikle Kolyada wrote: > Attached A bit fixed, wanted another version to show. Title: sys-libs/pam-1.4.0 upgrade Author: Mikle Kolyada Content-Type: text/plain Posted: 2020-06-?? Revision: 1 News-Item-Format: 2.0 Display-If-Installed: sys-libs/pam Display-If-Installed: sys-auth/pambase Starting with the 1.4.0 release [1], we don't offer these modules anymore: * pam_tally and pam_tally2 have been deprecated and replaced by the pam_faillock module * pam_cracklib has been deprecated and replaced by the pam_passwdqc module These changes affected our basic PAM stack configuration. You only need to take action if: * you made manual changes to the PAM stack, or * you use FEATURES="-config-protect-if-modified" option If this applies to you, please make sure to either run the etc-update or dispatch-conf command in order to sync your configuration. Failure to do this may result in your system becoming inaccessible. [1] - https://github.com/linux-pam/linux-pam/releases/tag/v1.4.0 signature.asc Description: OpenPGP digital signature
[gentoo-dev] Last rites: dev-tex/circuit_macros
# Mikle Kolyada (2020-06-26) # Has been a part of dev-texlive/texlive-pictures # for a lonmg time. Removal in 30 days. dev-tex/circuit_macros signature.asc Description: OpenPGP digital signature
[gentoo-dev] Last rites: app-misc/scope
# Mikle Kolyada (2020-06-28) # Obsolete package. # Does not build. # Dead upstream and only gentoo ships it. # Removal in 30 days. app-misc/scope signature.asc Description: OpenPGP digital signature
[gentoo-dev] Last rites: dev-tex/cjk-latex
# Mikle Kolyada (2020-07-03) # Merged into dev-texlive/texlive-langcjk. # Removal in 30 days. dev-tex/cjk-latex signature.asc Description: OpenPGP digital signature
[gentoo-dev] Last rites: dev-tex/xmltex
# Mikle Kolyada (2020-07-10) # Last major release in 2001. Was added into texlive # long ago. # Use dev-texlive/texlive-formatsextra instead. # Removal in 30 days. dev-tex/xmltex signature.asc Description: OpenPGP digital signature
[gentoo-dev] app-laptop/thinkfan is for grabs
I do not have an old thinkpad anymore. On modern ones this package is irrelevant. There is a pending version bump and 3 open bugs: - musl compatibility problem - 2 bugs are due to problems in upstream unit/init.d files. signature.asc Description: OpenPGP digital signature
[gentoo-dev] Last rites: app-text/{jadetex,passivetex}
# Mikle Kolyada (2020-07-24) # Both packages is a part of the texlive-formatsextra.collection # (or dev-texlive/texlive-formatsextra package). # jadetex abuses kpathsea configuration. # Both were last released in 2002. # Removal in 30 days. app-text/jadetex app-text/passivetex signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Last rites: sys-auth/consolekit and co
# Mikle Kolyada (2020-08-02) # consolekit is abandoned upstream. # People are encouraged to switch to any logind # implementation (systemd/elogind). # Removal in 60 days (bug #727730) sys-auth/consolekit sec-policy/selinux-consolekit signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Packages are up for grabs: zathura and co
dev-libs/girara app-text/zathura-ps app-text/zathura-pdf-poppler app-text/zathura-pdf-mupdf app-text/zathura-djvu app-text/zathura-cb app-text/zathura Are for grabs now, I do not use them daily anymore. A separate active maintainer needed.
Re: [gentoo-dev] Crypto/GPG-related packages up for grabs
On 07.09.2020 20:44, Michał Górny wrote: Hi, The following packages are up for grabs due to their maintainer being MIA. acct-group/monkeysphere acct-user/monkeysphere app-crypt/ekeyd app-crypt/monkeysphere app-crypt/nasty app-crypt/pinentry app-eselect/eselect-pinentry dev-libs/libgcrypt dev-libs/npth net-misc/sks www-apps/ampache I will take pinentry as I took gnupg in anyway.
[gentoo-dev] www-servers/lighttpd is up for grabs
I have switched to nginx for the most of my services. There are no critical bugs open, but some may require additional investigation.
[gentoo-dev] [PATCH] profiles/targets/desktop: Do not enable ldap USE flag by default
Closes: https://bugs.gentoo.org/741380 Signed-off-by: Mikle Kolyada --- profiles/targets/desktop/make.defaults | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/profiles/targets/desktop/make.defaults b/profiles/targets/desktop/make.defaults index da96e7830..d7eab4cd0 100644 --- a/profiles/targets/desktop/make.defaults +++ b/profiles/targets/desktop/make.defaults @@ -1,4 +1,4 @@ # Copyright 1999-2020 Gentoo Authors # Distributed under the terms of the GNU General Public License v2 -USE="a52 aac acpi alsa bluetooth branding cairo cdda cdr cups dbus dri dts dvd dvdr elogind emboss encode exif flac gif gpm gtk gui icu jpeg lcms ldap libnotify mad mng mp3 mp4 mpeg ogg opengl pango pdf png policykit ppds qt5 sdl spell startup-notification svg tiff truetype vorbis udev udisks unicode upower usb wxwidgets X xcb x264 xml xv xvid" +USE="a52 aac acpi alsa bluetooth branding cairo cdda cdr cups dbus dri dts dvd dvdr elogind emboss encode exif flac gif gpm gtk gui icu jpeg lcms libnotify mad mng mp3 mp4 mpeg ogg opengl pango pdf png policykit ppds qt5 sdl spell startup-notification svg tiff truetype vorbis udev udisks unicode upower usb wxwidgets X xcb x264 xml xv xvid" -- 2.26.2
Re: [gentoo-dev] [PATCH] profiles/targets/desktop: Do not enable ldap USE flag by default
On 10.09.2020 08:35, Hans de Graaff wrote: On Wed, 2020-09-09 at 13:35 +0300, Mikle Kolyada wrote: Closes: https://bugs.gentoo.org/741380 Could you provide a rationale for removing this? The bug only has a single anecdotal report of a user who can run a desktop without it. I'm not sure if that is reason enough to remove this. I guess we won't be able to figure out easily how many of our desktop profile users are actually using LDAP, but changing this may cause surprises and I'm not sure if that's warranted. Hans Hi. It is dictated by common sense. I barely can imagine a case where you need ldap support in each and every package you install. This should rather be per-package enabled as something non-trivial.
[gentoo-dev] Last rites: dev-tex/dvi2tty
# Mikle Kolyada (2020-09-10) # Merged into the app-text/texlive-core package. # Removal in 30 days dev-tex/dvi2tty signature.asc Description: OpenPGP digital signature
[gentoo-dev] Last rites: dev-tex/dvipost
# Mikle Kolyada (2020-09-12) # Dead upstream and does not build. # Removal in 30 days dev-tex/dvipost signature.asc Description: OpenPGP digital signature
[gentoo-dev] Last rites: dev-tex/csindex
# Mikle Kolyada (2020-09-12) # Has been a part of a cstex macro for a long time. # The cstex macro is provided by the # dev-texlive/texlive-langczechslovak package. # Removal in 30 days dev-tex/csindex signature.asc Description: OpenPGP digital signature
[gentoo-dev] Last rites: dev-tex/detex
# Mikle Kolyada (2020-09-12) # Merged into the texlive-core package. # Removal in 30 days dev-tex/detex signature.asc Description: OpenPGP digital signature
