Re: [gentoo-dev] Re: Cross Post due to technical component - Thanks for all the fish
On 12/11/2016 10:49 AM, Daniel Campbell wrote: > On 12/11/2016 02:00 AM, Markos Chandras wrote: >> On 12/11/2016 08:05 AM, Daniel Campbell wrote: >>> On 12/07/2016 07:36 AM, Jorge Manuel B. S. Vicetto wrote: >>>> On Wed, 7 Dec 2016, Jorge Manuel B. S. Vicetto wrote: >>>> >>>> >>>> >>>>> I'm asking recuiters directly, but unless someone changed the rules >>>>> and I was distracted, irc is not mandatory. >>>> >>>> I've got confirmation that nothing has changed, so irc is not mandatory. >>>> I hope this clears any misunderstandings and puts an end to any >>>> speculation. >>>> >>>> Best regards, >>>> Jorge Manuel B. S. Vicetto >>>> Gentoo Developer >>>> >>> Would you mind telling us who told you that? I don't disagree or >>> anything, but if others have further questions, we should route them to >>> the person you spoke with. >>> >> >> I did. No, do not redirect them to me. If the wiki does not clarify >> that, then fix the wiki. >> >> But seriously, are we arguing here about connecting to IRC for a few >> hours in your entire dev-hood? Is this really *that* hard? Or is it just >> another excuse to complain about the whole process? >> >> Anyway, nobody (to my knowledge) ever got rejected because he/she did >> not have IRC access so please stop speculating and throwing flamebaits >> here and there. We have more than enough already. >> > I think maybe you're mixing me up with someone else. That said, editing > the wiki sounds good since it'll save developer time. > It was merely a "call for some fact checking" to the original reporter who claimed that IRC is mandatory or whatever. -- Regards, Markos Chandras
[gentoo-dev] Last rites: sys-power/powerman
# Markos Chandras (11 Dec 2016) # Dead upstream, no maintainer and it hasn't been bumped # since 2013. Masking for removal in 30 days (wrt bug #489878) sys-power/powerman -- Regards, Markos Chandras
Re: [gentoo-dev] Re: Cross Post due to technical component - Thanks for all the fish
On 12/11/2016 08:05 AM, Daniel Campbell wrote: > On 12/07/2016 07:36 AM, Jorge Manuel B. S. Vicetto wrote: >> On Wed, 7 Dec 2016, Jorge Manuel B. S. Vicetto wrote: >> >> >> >>> I'm asking recuiters directly, but unless someone changed the rules >>> and I was distracted, irc is not mandatory. >> >> I've got confirmation that nothing has changed, so irc is not mandatory. >> I hope this clears any misunderstandings and puts an end to any >> speculation. >> >> Best regards, >> Jorge Manuel B. S. Vicetto >> Gentoo Developer >> > Would you mind telling us who told you that? I don't disagree or > anything, but if others have further questions, we should route them to > the person you spoke with. > I did. No, do not redirect them to me. If the wiki does not clarify that, then fix the wiki. But seriously, are we arguing here about connecting to IRC for a few hours in your entire dev-hood? Is this really *that* hard? Or is it just another excuse to complain about the whole process? Anyway, nobody (to my knowledge) ever got rejected because he/she did not have IRC access so please stop speculating and throwing flamebaits here and there. We have more than enough already. -- Regards, Markos Chandras
Re: [gentoo-dev] Tinderboxing efforts in Gentoo
On 12/04/2016 05:47 PM, Michał Górny wrote: > On Sun, 4 Dec 2016 16:58:26 + > Markos Chandras wrote: > >> On 12/03/2016 05:31 PM, Michał Górny wrote: >>> On Sat, 3 Dec 2016 13:13:36 + >>> Markos Chandras wrote: >>> >>>> On 12/03/2016 10:41 AM, Michał Górny wrote: >>>>> On Sat, 3 Dec 2016 10:35:32 +0100 >>>>> Patrice Clement wrote: >>>>> >>>>>> Friday 02 Dec 2016 14:10:27, Michał Górny wrote : >>>>>>> Hi, everyone. >>>>>>> >>>>>>> I've heard multiple times about various tinderbox projects being >>>>>>> started by individuals in Gentoo. In fact, so many different projects >>>>>>> that I've forgotten who was working on most of them. >>>>>>> >>>>>>> I know that Toralf is doing tinderboxing for most of the stuff. >>>>>>> What other projects do we have there? What is their status? >>>>>>> >>>>>>> Is there anything we could try to integrate with pull requests to get >>>>>>> a better testing? >>>>>>> >>>>>>> -- >>>>>>> Best regards, >>>>>>> Michał Górny >>>>>>> <http://dev.gentoo.org/~mgorny/> >>>>>> >>>>>> Continuous integration is all the rage these days and tinderboxing is the >>>>>> obvious way to go concerning Gentoo. AFAIK, Toralf is the only >>>>>> contributor >>>>>> doing tinderboxing out of his own will. In reality, we should have a >>>>>> team of >>>>>> devs looking after our own tinderboxes instead of relying on the >>>>>> community. >>>>>> >>>>>> I'm wondering if we could start a donation campain for this project and >>>>>> ask >>>>>> people if they've got spare machines laying around. I know a lot of >>>>>> folks are >>>>>> reading this mailing list so maybe asking on gentoo-dev first for a >>>>>> start would >>>>>> be appropriate. >>>>> >>>>> Hardware is not the problem. Lack of software is. >>>>> >>>> >>>> Have you considered using openQA[1] like openSUSE[2] and Fedora[3] do >>>> instead of reinventing the wheel? >>>> >>>> [1] http://open.qa/ >>>> [2] https://openqa.opensuse.org/ >>>> [3] https://openqa.fedoraproject.org/ >>> >>> Do you by any chance happen to know how it maps to our needs? >>> At a first glance it seems quite tangential. >>> >> >> Depends on what you want to test. I guess openQA would be a very good >> solution if you want to test a snapshot of the tree against the most >> common scenarios for example >> >> - todays snapshot with plasma5 >> - todays snapshot with gnome3 >> - todays snapsnot with lxqt >> - ... >> - todays snapshot with a few tests against popular console packages >> * can gcc build small C test files? >> * does bash work? >> * does coreutils popular tools work as expected? >> >> >> Having such scenarios in place is probably a more realistic testing >> approach than simply build everything with random USE flags just for the >> sake of build coverage. > > I'm looking for something I could tell 'build this package on this > commit (pull request)', optionally with some USE flags adjustment. > And I'd like it to be fast, i.e. don't bother rebuilding whole KDE > libraries every time a pull request requiring them is updated. > I think that both approaches are valuable then. We may need different set of software solutions though. Wouldn't, for example, Jenkins or buildbot do what you want on the per-package PR testing? And then you could use openQA to test the entire tree as a whole. -- Regards, Markos Chandras
Re: [gentoo-dev] Tinderboxing efforts in Gentoo
On 12/03/2016 05:31 PM, Michał Górny wrote: > On Sat, 3 Dec 2016 13:13:36 + > Markos Chandras wrote: > >> On 12/03/2016 10:41 AM, Michał Górny wrote: >>> On Sat, 3 Dec 2016 10:35:32 +0100 >>> Patrice Clement wrote: >>> >>>> Friday 02 Dec 2016 14:10:27, Michał Górny wrote : >>>>> Hi, everyone. >>>>> >>>>> I've heard multiple times about various tinderbox projects being >>>>> started by individuals in Gentoo. In fact, so many different projects >>>>> that I've forgotten who was working on most of them. >>>>> >>>>> I know that Toralf is doing tinderboxing for most of the stuff. >>>>> What other projects do we have there? What is their status? >>>>> >>>>> Is there anything we could try to integrate with pull requests to get >>>>> a better testing? >>>>> >>>>> -- >>>>> Best regards, >>>>> Michał Górny >>>>> <http://dev.gentoo.org/~mgorny/> >>>> >>>> Continuous integration is all the rage these days and tinderboxing is the >>>> obvious way to go concerning Gentoo. AFAIK, Toralf is the only contributor >>>> doing tinderboxing out of his own will. In reality, we should have a team >>>> of >>>> devs looking after our own tinderboxes instead of relying on the community. >>>> >>>> I'm wondering if we could start a donation campain for this project and ask >>>> people if they've got spare machines laying around. I know a lot of folks >>>> are >>>> reading this mailing list so maybe asking on gentoo-dev first for a start >>>> would >>>> be appropriate. >>> >>> Hardware is not the problem. Lack of software is. >>> >> >> Have you considered using openQA[1] like openSUSE[2] and Fedora[3] do >> instead of reinventing the wheel? >> >> [1] http://open.qa/ >> [2] https://openqa.opensuse.org/ >> [3] https://openqa.fedoraproject.org/ > > Do you by any chance happen to know how it maps to our needs? > At a first glance it seems quite tangential. > Depends on what you want to test. I guess openQA would be a very good solution if you want to test a snapshot of the tree against the most common scenarios for example - todays snapshot with plasma5 - todays snapshot with gnome3 - todays snapsnot with lxqt - ... - todays snapshot with a few tests against popular console packages * can gcc build small C test files? * does bash work? * does coreutils popular tools work as expected? Having such scenarios in place is probably a more realistic testing approach than simply build everything with random USE flags just for the sake of build coverage. -- Regards, Markos Chandras
Re: [gentoo-dev] Revision bumps vs git commits atomicity
On 12/02/2016 03:14 PM, Andrew Savchenko wrote: > > What about the following forkflow: > - version bump first with minimal changes required, but without > pushing commit to the tree; > - make each logical change as a separate commit without revision > bumps and without pushing stuff to the tree (of course repoman > scan/full is required as usual for each commit); > - well test package after the last commit (that it builds with > various USE flag combinations, old and new functionality works fine > and so on); > - fix any problems found and only afterwards push changes to the > tree. > > This way users will see only foo-1.0 -> foo-1.1 change in the tree, > while git will still retain each logical change as a separate > commit, which will make future maintenance and debugging much > easier. That's reasonable but I also think that bumping and fixing an ebuild at the same time can be considered an atomic change since it's effectively a _new_ ebuild -- Regards, Markos Chandras
Re: [gentoo-dev] Tinderboxing efforts in Gentoo
On 12/03/2016 10:41 AM, Michał Górny wrote: > On Sat, 3 Dec 2016 10:35:32 +0100 > Patrice Clement wrote: > >> Friday 02 Dec 2016 14:10:27, Michał Górny wrote : >>> Hi, everyone. >>> >>> I've heard multiple times about various tinderbox projects being >>> started by individuals in Gentoo. In fact, so many different projects >>> that I've forgotten who was working on most of them. >>> >>> I know that Toralf is doing tinderboxing for most of the stuff. >>> What other projects do we have there? What is their status? >>> >>> Is there anything we could try to integrate with pull requests to get >>> a better testing? >>> >>> -- >>> Best regards, >>> Michał Górny >>> <http://dev.gentoo.org/~mgorny/> >> >> Continuous integration is all the rage these days and tinderboxing is the >> obvious way to go concerning Gentoo. AFAIK, Toralf is the only contributor >> doing tinderboxing out of his own will. In reality, we should have a team of >> devs looking after our own tinderboxes instead of relying on the community. >> >> I'm wondering if we could start a donation campain for this project and ask >> people if they've got spare machines laying around. I know a lot of folks are >> reading this mailing list so maybe asking on gentoo-dev first for a start >> would >> be appropriate. > > Hardware is not the problem. Lack of software is. > Have you considered using openQA[1] like openSUSE[2] and Fedora[3] do instead of reinventing the wheel? [1] http://open.qa/ [2] https://openqa.opensuse.org/ [3] https://openqa.fedoraproject.org/ -- Regards, Markos Chandras
[gentoo-dev] www-servers/lighttpd needs new maintainers
Hi, Alex and I have no time to take care of this package so if any of you wants to help please feel free to add yourself to metadata and start fixing things ;) There are a few outstanding bugs and a pending version bump from a few days ago. Thanks -- markos
Re: [gentoo-dev] ChangeLog - Infra Response
On 11/05/2015 12:39 PM, Ulrich Mueller wrote: >>>>>> On Thu, 5 Nov 2015, Alexis Ballier wrote: > >> On Mon, 2 Nov 2015 20:18:07 + >> "Robin H. Johnson" wrote: > >>> On Mon, Nov 02, 2015 at 08:05:56AM +0100, Ulrich Mueller wrote: >>>> What would be the problem with renaming? IMHO it would be nicer to >>>> keep the ChangeLog name for the autogenerated files and rename the >>>> ones from CVS. We already have files renamed to ChangeLog- >>>> when they became to large, so we could just use ChangeLog-2015 to >>>> stay within that scheme. > >>> If we rename the old ChangeLog files from CVS to ChangeLog-2015, then >>> we'll have both 'ChangeLog-2015' and 'ChangeLog' (generated from Git) >>> containing 2015 entries. Worse, what happens when we hit 2016? Do we >>> merge the old files? > >> It's not perfectly clean but I don't see any problem here: >> ChangeLog-2015 : all ChangeLog from CVS >> ChangeLog: autogenerated from git > >> if/when there is a need to split git changelogs, autogenerated >> changelogs will start from say, Jan. 1st 2016, and previous changes >> will now be static. Merging CVS2015 and git2015 changelogs is just a >> matter of running a script. Or just skip splitting them for 2016, and >> start splitting in 2017, so that ChangeLog-2015 is CVS ones, >> ChangeLog-2016 is git logs from Aug. 8. 2015 to Dec. 31 2016. > >> IMHO this is still better than having ChangeLog stopping in 2015 and >> ChangeLog.git starting from this date: Having ChangeLog-2015 from CVS >> still carries partial information on the timeline. > > +1 > > You said it better than I could have. > > Ulrich > yeah, +1 on that too. I am not too bothered with the name to be honest. However, using 'ChangeLog' for git logs sounds like something most of us and users are familiar with already so that should work. -- Regards, Markos Chandras
Re: [gentoo-dev] Globally masking the sssd USE-flag on sudo and enabling it on supported architectures only
On 11/04/2015 05:37 PM, Markos Chandras wrote: > On 11/04/2015 11:34 AM, lejonet wrote: >> Hi gentoo-dev, >> >> I recently had a bout with sudo and sssd, and found that the problem was that >> sudo wasn't sssd aware and the reason we don't have a USE-flag for that is >> due >> to some lingering bugs. >> >> To partially solve this I propose that we mask the sssd USE-flag, >> globally and only unmask it on supported architectures that we have already >> confirmed it working on (like amd64 and x86). >> This prevents us from having to withdraw keywords on a rather important >> package on minor arches on which sssd and sudo haven't been tested yet. >> >> Dropping keywords on sudo seems unnecessary and very disruptive but allowing >> sssd bugs to linger isn't a great solution either[1], as in this particular >> issue, a sudo bug is depending on the lingering sssd bug.[2] >> >> [1] https://bugs.gentoo.org/show_bug.cgi?id=540540 >> [2] https://bugs.gentoo.org/show_bug.cgi?id=525674 >> > > fwiw, it sounds good to me > so are you going to do it or should I? -- Regards, Markos Chandras
Re: [gentoo-dev] Globally masking the sssd USE-flag on sudo and enabling it on supported architectures only
On 11/04/2015 11:34 AM, lejonet wrote: > Hi gentoo-dev, > > I recently had a bout with sudo and sssd, and found that the problem was that > sudo wasn't sssd aware and the reason we don't have a USE-flag for that is due > to some lingering bugs. > > To partially solve this I propose that we mask the sssd USE-flag, > globally and only unmask it on supported architectures that we have already > confirmed it working on (like amd64 and x86). > This prevents us from having to withdraw keywords on a rather important > package on minor arches on which sssd and sudo haven't been tested yet. > > Dropping keywords on sudo seems unnecessary and very disruptive but allowing > sssd bugs to linger isn't a great solution either[1], as in this particular > issue, a sudo bug is depending on the lingering sssd bug.[2] > > [1] https://bugs.gentoo.org/show_bug.cgi?id=540540 > [2] https://bugs.gentoo.org/show_bug.cgi?id=525674 > fwiw, it sounds good to me -- Regards, Markos Chandras
Re: [gentoo-dev] Make 'audit' a global useflag?
On 10/06/2015 10:29 PM, Andrew Savchenko wrote: > On Tue, 6 Oct 2015 19:39:42 +0100 Markos Chandras wrote: >> On 10/06/2015 06:58 PM, Andrew Savchenko wrote: >>> Hi, >>> >>> On Tue, 6 Oct 2015 17:32:07 +0100 Markos Chandras wrote: >>>> Hi, >>>> >>>> The following packages currently use the 'audit' local useflag >>>> >>>> ~$ qgrep -N -s -l -e "^IUSE.*audit" | sed "s@-[0-9].*@@" | sort -n | uniq >>>> >>>> app-emulation/libvirt >>>> app-forensics/aide >>>> dev-util/perf >>>> gnome-base/gdm >>>> net-dns/opendnssec >>>> sys-apps/openrc >>>> sys-apps/policycoreutils >>>> sys-apps/shadow >>>> sys-apps/systemd >>>> sys-freebsd/freebsd-ubin >>>> sys-freebsd/freebsd-usbin >>>> sys-libs/pam >>>> >>>> (+ lightdm which I just committed) >>>> >>>> How about making it global with the following description? >>> >>> Audit support != sys-process/audit support. >>> >>> 1) sys-freebsd/us?bin packages does not depend on the audit >>> package. This flag controls their own auditing tools. >>> >>> 2) net-dns/opendnssec uses this flag to build auditing tools (and >>> doesn't depend on the audit package). >>> >>> 3) sys-apps/policycoreutils implies more than dependency on the >>> audit package: >>> Enable support for sys-process/audit and use the audit_* >>> functions (like audit_getuid instead of getuid()) >>> >>>> "Enable support for sys-process/audit" >>>> >>>> which is similar to what most packages use? >>> >>> Best regards, >>> Andrew Savchenko >>> >> >> Yeah I obviously didn't check all packages. How about those that really >> use sys-process/audit? They seem to be more than 5 anyway. > > Looks fine, though it will be good to make use flag description > more informative, like: > > Enable support for Linux audit subsystem using > sys-process/audit > I am fine with this wording so I will check the packages it applies to and commit the result. -- Regards, Markos Chandras
Re: [gentoo-dev] Make 'audit' a global useflag?
On 10/06/2015 06:58 PM, Andrew Savchenko wrote: > Hi, > > On Tue, 6 Oct 2015 17:32:07 +0100 Markos Chandras wrote: >> Hi, >> >> The following packages currently use the 'audit' local useflag >> >> ~$ qgrep -N -s -l -e "^IUSE.*audit" | sed "s@-[0-9].*@@" | sort -n | uniq >> >> app-emulation/libvirt >> app-forensics/aide >> dev-util/perf >> gnome-base/gdm >> net-dns/opendnssec >> sys-apps/openrc >> sys-apps/policycoreutils >> sys-apps/shadow >> sys-apps/systemd >> sys-freebsd/freebsd-ubin >> sys-freebsd/freebsd-usbin >> sys-libs/pam >> >> (+ lightdm which I just committed) >> >> How about making it global with the following description? > > Audit support != sys-process/audit support. > > 1) sys-freebsd/us?bin packages does not depend on the audit > package. This flag controls their own auditing tools. > > 2) net-dns/opendnssec uses this flag to build auditing tools (and > doesn't depend on the audit package). > > 3) sys-apps/policycoreutils implies more than dependency on the > audit package: > Enable support for sys-process/audit and use the audit_* > functions (like audit_getuid instead of getuid()) > >> "Enable support for sys-process/audit" >> >> which is similar to what most packages use? > > Best regards, > Andrew Savchenko > Yeah I obviously didn't check all packages. How about those that really use sys-process/audit? They seem to be more than 5 anyway. -- Regards, Markos Chandras
[gentoo-dev] Make 'audit' a global useflag?
Hi, The following packages currently use the 'audit' local useflag ~$ qgrep -N -s -l -e "^IUSE.*audit" | sed "s@-[0-9].*@@" | sort -n | uniq app-emulation/libvirt app-forensics/aide dev-util/perf gnome-base/gdm net-dns/opendnssec sys-apps/openrc sys-apps/policycoreutils sys-apps/shadow sys-apps/systemd sys-freebsd/freebsd-ubin sys-freebsd/freebsd-usbin sys-libs/pam (+ lightdm which I just committed) How about making it global with the following description? "Enable support for sys-process/audit" which is similar to what most packages use? -- Regards, Markos Chandras
Re: [gentoo-dev] Github PR commenting policy
On 09/20/2015 10:33 AM, Michał Górny wrote: > > > Dnia 20 września 2015 11:26:04 CEST, Jeroen Roovers > napisał(a): >> On Fri, 18 Sep 2015 20:09:16 -0400 >> Fernando Rodriguez wrote: >> >>> Github allows editting of comments in pull requests. Is there a >>> policy regarding that? I've noticed a comment disappear which makes >>> the rest of the conversation seem out of place. >> >> My personal policy is to completely ignore anything Gentoo related that >> gets posted on Github. I am also actively contemplating leaving the >> Gentoo organisation on Github altogether since it's basically useless >> (for reasons such as the one you mentioned) and since we have our own >> bug tracker already. > > Well, that shouldn't really hurt as most of our users already know that > Gentoo developers don't care about them at all. > can we please calm down once again? -- Regards, Markos Chandras
Re: [gentoo-dev] Inconsistent and messy layout of team maintainership in Gentoo
On 09/17/2015 12:05 PM, James Le Cuirot wrote: > On Thu, 17 Sep 2015 06:57:08 -0400 > "Anthony G. Basile" wrote: > >> Totally rethink the idea of emails aliases as something that is >> created on the fly. We just need to know who should get emails for a >> package when it comes to bug reports. Why can't that be calculated >> on the fly from the metadata.xml? > > I've not read every last part of this thread but I think I like where > this is going. I just want to be sure that people besides those in the > Java herd/project/whatever can continue to receive emails for > j...@gentoo.org. For instance, gnu_andrew is not a dev and does not > intend to be but he still likes to be CC'd on all Java mail. I would > not like to have to add his address to the metadata.xml of every Java > package. > i might not understand 100% what you are trying to say but why not add gnu_andrew to the java mail alias on pecker? how is metadata.xml going to solve this problem? -- Regards, Markos Chandras
Re: [gentoo-dev] Dynamic dependencies
On 09/16/2015 04:49 PM, Andreas K. Huettel wrote:
> Hi all,
>
> here's a quote from the Council 20140826 summary:
>
>> Dynamic dependencies in Portage
>> ===
>> During discussion, is was remarked that some changes, e.g. to
>> dependencies in eclasses, could require mass rebuilds of packages.
>>
>> Vote:
>> - "The council asks the Portage team to first outline their long-term
>> plan regarding removal or replacement of dynamic dependencies,
>> before they remove this feature. In particular, tree policies and
>> the handling of eclasses and virtuals need to be clarified."
>> Accepted unanimously.
>
> Since there seems to be interest in the Portage team to go ahead with that
> plan, I'd like to ask about the tree policies and the handling of eclasses
> and
> virtuals.
>
> I guess we'd appreciate this as a prerequisite for being able to give the
> plan
> future council support.
>
> Cheers,
> Andreas
>
could someone explain what the dynamic dependencies are in the context
of portage and ebuilds? because that does seem to be something
portage-internal specific in the way it handles changes in {,R}DEPEND
without revbumps. Where is this thing documented in the first place?
--
Regards,
Markos Chandras
Re: [gentoo-dev] what's the correct format for bugs containing package name and version?
On 03/06/2015 07:27 PM, Rich Freeman wrote: > On Fri, Mar 6, 2015 at 1:14 PM, Sven Vermeulen wrote: >> >> It doesn't hurt to have a recommendation, and personally I really appreciate >> when people (yes, that includes developers and wranglers ;-) update the line >> to be more informative. There already is a recommendation on the wiki, part >> of the Bug Wranglers project [1]. >> > > Sure, beautiful bug reports are nice, but if people are suffering > burnout over editing the line it this doesn't seem like the biggest > value-add to me. > > By all means have a standard. But, don't discourage but reporters by > asking them to rework reports if they don't conform, and don't > discourage maintainers or bug wranglers by yelling at them if they > don't clean these up. People can of course can still make things as > pretty as they want to. > > The only reason I could see for rigid adherence to a standard is if > we're using the field as input to some kind of program, and if we're > doing that then the data should really be broken down into appropriate > fields like atom, desc, etc. > > So, have a best practice, but let's not get carried away with this > sort of thing to the point where people feel like it is getting in the > way. > I too feel that whatever gets decided here will soon be forgotten and people will revert back to whatever makes more sense to them. Would it be terribly difficult to set a template in the "Summary" field whenever the "Keywording and Stabilization" component is selected when filing a bug? -- Regards, Markos Chandras
Re: [gentoo-dev] Re: [gentoo-dev-announce] Service relaunch: gitweb.gentoo.org; anon git:// moving soon
On 03/04/2015 02:56 AM, Robin H. Johnson wrote: > On Tue, Mar 03, 2015 at 11:57:40PM +0200, Markos Chandras wrote: >> One that that I miss though is the git (+ssh) links for rw access >> to the repositories. It's not obvious what url to use to clone a >> repository for rw access. Is there a way to generate such urls on >> the web interface? > It does clearly say them, in the bottom area of each repo: > > http://gitweb.gentoo.org/proj/elections.git/ Clone > git://anongit.gentoo.org/proj/elections.git > http://anongit.gentoo.org/git/proj/elections.git > git+ssh://g...@git.gentoo.org/proj/elections.git > Hmm true.. I am pretty sure this was not there when I posted this message but I could be wrong :) I was also looking at the http://gitweb.gentoo.org/proj/gmn.git/ (which is empty as it should be) which still doesn't list any links to clone the repo. I realize it's empty but you still need some urls to push data to it so it can stop being empty :) Anyway it's easy to figure the correct url to use. -- Regards, Markos Chandras
[gentoo-dev] Re: [gentoo-dev-announce] Service relaunch: gitweb.gentoo.org; anon git:// moving soon
On 03/03/2015 04:14 AM, Robin H. Johnson wrote: > Another week, another service... > > The Gentoo Infra team now presents the relaunched Git web interface, now > hosted at: gitweb.gentoo.org. > > It's cgit-based, but has working redirects for all prior gitweb > locations: > http://git.gentoo.org/gitweb/ > http://sources.gentoo.org/gitweb/ > http://overlays.gentoo.org/gitweb/ > http://git.overlays.gentoo.org/gitweb/ > (https is also supported on all of these) > > Thanks to a3li for his work on the new theming! > Hi, Thanks for that. Looks pretty good One that that I miss though is the git (+ssh) links for rw access to the repositories. It's not obvious what url to use to clone a repository for rw access. Is there a way to generate such urls on the web interface? -- Regards, Markos Chandras
[gentoo-dev] Re: [gentoo-dev-announce] Service relaunch: archives.gentoo.org
On 02/26/2015 10:23 AM, Robin H. Johnson wrote: > The Gentoo Infrastructure team is proud to announce that we have > re-engineered the mailing list archives, and re-launched it, back > at archives.gentoo.org. The prior Mhonarc-based system had numerous > problems, and a complete revamp was deemed the best forward > solution to move forward with. The new system is powered by > ElasticSearch (more features to come). > > All existing URLs should either work directly, or redirect you to > the new location for that content. > > Major thanks to a3li, for his development of this project. > > Note that we're still doing some catchup on newer messages, but > delays will drop to under 2 hours soon, with an eventual goal of > under 30 minutes. > > Please report problems to Bugzilla: Product Websites, Component > Archives [1][2] > > Source available at: git://git.gentoo.org/proj/ag.git (backend) > git://git.gentoo.org/proj/ag-web.git (frontend) > > [1] https://tinyurl.com/mybyjq6 which is really [2] [2] > https://bugs.gentoo.org/enter_bug.cgi?alias=&assigned_to=infra-bugs%40gentoo.org&attach_text=&blocked=&bug_file_loc=http%3A%2F%2F&bug_severity=normal&bug_status=CONFIRMED&comment=&component=Archives&contenttypeentry=&contenttypemethod=autodetect&contenttypeselection=text%2Fplain&data=&deadline=&defined_groups=1&dependson=&description=&estimated_time=&flag_type-4=X&form_name=enter_bug&keywords=&maketemplate=Remember%20values%20as%20bookmarkable%20template&op_sys=Linux&priority=Normal&product=Websites&rep_platform=All&requestee_type-4=&short_desc=archives.gentoo.org%3A%20FILL%20IN%20HERE&version=n%2Fa > > Excellent! Looks great. Thank you very much for your hard work -- Regards, Markos Chandras
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-fonts/libertine: libertine-4.7.5.ebuild libertine-5.1.3.20110615.ebuild metadata.xml ChangeLog libertine-5.3.0.20120702.ebuild
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 02/22/2015 08:41 AM, Ben de Groot (yngwin) wrote:
> yngwin 15/02/22 06:41:41
>
> Added:libertine-4.7.5.ebuild
> libertine-5.1.3.20110615.ebuild metadata.xml ChangeLog
> libertine-5.3.0.20120702.ebuild Log: Move from libertine-ttf to
> libertine. Install OpenType fonts as well (bug #406301). Version
> bump (bug #431430).
>
> (Portage version: 2.2.17/cvs/Linux x86_64, RepoMan options:
> --force, signed Manifest commit with key 0x4FDF9CFD2FAC514E!)
>
After this change I am getting this problem on world update
emerge: there are no ebuilds to satisfy "media-fonts/libertine-ttf".
(dependency required by "app-office/libreoffice-4.4.0.3::gentoo"
[installed])
(dependency required by "@selected" [set])
(dependency required by "@world" [argument])
Did you forget to fix reverse dependencies?
I synced my cvs tree and libreoffice stills needs the old package
RDEPEND="${COMMON_DEPEND}
!app-office/libreoffice-bin
!app-office/libreoffice-bin-debug
!
Re: [gentoo-dev] [rfc] enable USE=seccomp in default/linux/ profiles
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 02/19/15 21:14, Mike Frysinger wrote: > pro: improved security in daemons (often network) con: some > packages might pull in libseccomp (~250KB) > > there shouldn't be measurable runtime overhead here as the > filtering is done by a JIT in the kernel itself. if the kernel > lacks support for seccomp, daemons generally should fallback at > runtime. if they don't, people should file bugs to get them > fixed. -mike > Yes please - -- Regards, Markos Chandras -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCgAGBQJU5mvTAAoJEPqDWhW0r/LClXUQALYh28hSxoeVXRncPhECQ6P6 Hojd6B4o0Gm1fRPJR5COB7OHJesn3395lMALID106cXRlDp4YXj6na/WQ8JY05wJ hArQKxeEZOhOiXqWQPHFPNTXYk/92Xnkn+PWek0mmePn6hrRF8yv56v6KkvsFjr5 gZgWMG3ZOsuxUkf0fjPhZpwQMNvAbioQBxA2LXF3wD3qW5NNXdglLxKvd9yRBe5D C5eqnKy90Y/f5l3x00k4UImDAOyn3nnCR4BXZD+LoCwTGLQOuLWE1/2I8O50lf2I zbtgW3r5HSey5FP57gyGoVQynH21f2w5QcyXogmqvO0LXEoUmJ3GXzTKik1G0jXt WXn/ta+T3ILU9ogJGrbCcaGlSryRM9Wc5j7r8AY+Q6gkzwEwOmWe2lSlqR0ppQfu amCTKtAx31RJhnhhJFec3CN/D8mqteEvKcrPUIk1ManVhAqbzZhSgwPF/dQWsjqe JVDYhCt0VH1c2ckAeAxtDu0Nr914/ayFFx/k5WDWkE7SfTkQBa9K3zCs74arTq6r dczN8WJmG6wpVK65EiF5UbjuIaS+bQiOKpsODbgx/2uBMp82O+ISc+hUNZfFqu5Y khIgLP9P0Mq/VmHHfzN+ptmd5DNAFBBsZg5F3YKiVbIOq/ThTAos4i9Aq28ocFMH B0aRyvwyhCyJmv3kRYze =OIhP -END PGP SIGNATURE-
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: fcaps.eclass
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 02/19/15 13:38, Alexis Ballier wrote: > On Thu, 19 Feb 2015 19:34:28 +0800 Patrick Lauer > wrote: > >> On Thursday 19 February 2015 12:31:27 Alexis Ballier wrote: >>> On Wed, 18 Feb 2015 22:48:27 +0100 >>> >>> Michał Górny wrote: >>>> Dnia 2015-02-18, o godz. 16:11:53 >>>> >>>> "Mike Frysinger (vapier)" napisał(a): >>>>> vapier 15/02/18 16:11:53 >>>>> >>>>> Modified: fcaps.eclass Log: clarify >>>>> USE=filecaps intention #540430 >>>>> >>>>> Revision ChangesPath 1.11 >>>>> eclass/fcaps.eclass >>>> >>>> Please commit the missing ChangeLog update and remember to >>>> update the ChangeLog after changing any eclass in any way. >>>> This is an official policy for any commits to the Gentoo >>>> repository [1] and a lack of consistency in entries to the >>>> ChangeLog is confusing to our developers and users. >>>> >>>> [1]:http://devmanual.gentoo.org/ebuild-writing/misc-files/changelog/index. >>>> >>>> html >>> this policy is about packages; cvs log is *mch* better than >>> any global changelog for eclasses: who will dig into a >>> thousand changelog entries to find what changed in fcaps.eclass >>> ? >>> >>> if you want changelogs in eclass/, make it per-eclass, like it >>> is already per-package. >>> >> >> We've had this discussion before ... so ... > > > what i remember of it is someone adding a ChangeLog file to eclass/ > and sending an email to ask people to fill it. Mind sharing a link > ? > > I think I'll add ChangeLog to every category and ask people to fill > it whenever they make changes to a package in that category. This > would have the same level of usefulness as a ChangeLog in eclass/. > > Alexis. > We had the same discussion again in the past http://archives.gentoo.org/gentoo-dev/msg_51d268a7757fd90fbda77d373a2664f8.xml and again http://www.gossamer-threads.com/lists/gentoo/dev/262085 we can't keep having the same discussion. The original changelog discussion is here http://archives.gentoo.org/gentoo-dev/msg_c3436497e445eaf86deea08772e5.xml There were no objections so we started using it http://archives.gentoo.org/gentoo-dev/msg_72fafb93225c9f5559415356eb093f44.xml Can we please bookmark them for future reference? Do we really need to make every single bit of development a formal policy? Do we really need to discuss every single bit of development in the mailing lists? When did we stop being developers because it was a fun thing to do and turned into a bunch of mean people pointing fingers at each other? - -- Regards, Markos Chandras -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCgAGBQJU5dmAAAoJEPqDWhW0r/LCNwQP/3pffbifLk24zHVDh7nlHOxv 2dqggYIro4SxmhaRI2/2gRa/ozdwsu6JjH0+f5taMThvX5OAiJWmQL8u53A/RlO+ xSIN4yPtaDsVbGEzGawvkI4abgFbLx8zNJdOnb2W/hF5JNLAoSZR8RFPeXjbtzw/ sUu1vwL9IilT3jTG8fAutRcdnrYrkFtxO0QkRm11sdYcvgYB1ZBHlepsTmDkFt1v 5DOfm6+iI+ZZsx1K0Avjosl3YmLWu3kyyQeFdaaZN+wgFdk1j+4cZ9qqCeoHJaki ms2F2QwR3mC009aoSgiR8IbSz3UfK/zQ4zLpX2r+7jdO/Fa2ek3IQl7qrLsP8eAJ D2LCPGVi8IKJkpTyFX+YqPsL4/c1Jw0KjnEUIXqYcqxi9G2FP0yZSqsAQHdkEW12 qnDlss5E5rCAltQs53yaJBvpGm0Ziu+OYHY8uSfBIRe3JNolD95FXjp32EhoXGpD N/gaZxhlGgqAasszG3L1XEq9S8uxUU9c1cfCPvzH8Br664cAyHtM5tZnQjbP+e/S jO9caZC3Ummodj/RFU9MIFdBAuLUqZw9bTGkuN8KwqUcbXl+LeFsuHf9Ys4NYMlh EouE/+avI1y3WqO7M/kBFVJhS7pqoyCQym3NOzyj3IbsaMG6y3T2iC6XOc3SL1NU hFswjFA038/x+xnogfvk =qdEX -END PGP SIGNATURE-
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/watchdog: watchdog-0.8.3.ebuild ChangeLog
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 02/19/15 06:10, Mike Gilbert wrote: > On Wed, Feb 18, 2015 at 7:08 PM, Patrick Lauer > wrote: >> On Wednesday 18 February 2015 18:43:59 hasufell wrote: >>> Is there a communication problem? >>> >>> I don't remember getting either: * a bug report * a ping * a >>> review request >>> >>> Did I miss something? >> >> Yes. >> >> Why is this package metadata missing the python herd for no >> reason? >> > > Speaking as the current python lead, we don't claim "ownership" of > everything in dev-python. > > As a Gentoo developer, I find it silly to raise a stink on a > mailing list over what appears to be a very simple version bump of > a very simple ebuild. This is not going to convince anyone that a > peer review workflow is a desirable thing; I don't want to have > someone rubber stamp every trivial version bump. > What saddens me the most is that these pointless threads are becoming sort of a habit not because the reporter is really offended by the original action, but because he/she uses that to prove that QA is dying, Gentoo is a zombie, cvs sucks and elephants could fly. So how about we stop replying to such flamebaits for a change? That would really improve the quality of our lists and people wanting to start a flame will see that this is no longer the place to do so. - -- Regards, Markos Chandras -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCgAGBQJU5aVfAAoJEPqDWhW0r/LCNZYQAJ5iu0JKGWsPoEMXwTfSiHNy UmCiEn11Hoh2Y+1HO1s9MW0PHuTsIY+I1YRqQYbmxk4wJatyzitLN1wLIkM6kA9f qszK7a+cjW6MQSkgcCtboZZZ2YTppSaYocElmUu0FR6gfhBrEkS+Xd0LaXE0D2V+ PppjodQMPVMtY25hIiiPPmwmQOfdAMFx5Sf87EpMNkWv2kirpuc0h7TNuL3fds9X koPQkM0nGz4vBbQVjHfUZt6rDDIYzDZQ9KInuLGgS3X3ey/p+hCXnxYot7HaWFGi y+Lcu6bJc6nwDSfUv962KkmMFX5NqZvMDKmKmSseTtqbh48DPCyYOFTvphXgJTaV 16jeQ6NUc47N8NpDwQiTvqwZ5K8GBh2D3PT0M5cuEFP/Gvz+bRMZsaUf/YWNctOt wNi+eB84v4CrYnECadzsoXB6XojoofYVuizLCxxXDOZLZsFDAKua+PpmkHG6PEvP xNYuLGHNUwbFYjJo9ZzaIg2C/UwPpuFOvwIqo9c56L/w+9F4BCYIT9OoSSJ3UkLX OkRZMeN3091aN8q2mEVHbAEPxw6YAhD4qDTSIQvEkfuWMx7Vi3b4+zedYpkjwzDN ZaTAN+NksSvLIlBEot9E6lDpqazq0l53iVgXWp2V+o5rM3COfsTnZzfuPCOmZ+n7 Tas+Qzny0XXvbxKSqP8f =AwVF -END PGP SIGNATURE-
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-libs/libusbhp: ChangeLog Manifest libusbhp-1.0.2.ebuild metadata.xml
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 02/16/15 13:53, Kristian Fiskerstrand wrote: > On 02/16/2015 12:44 PM, Markos Chandras wrote: > > >> I too believe that if you are reverting someone's commit you >> should at least drop him an email to let him know. How else do >> you expect him to know he did something wrong? I am a bit worried >> QA is taking such actions without communicating that with the >> developer. If you don't let people know they do mistakes, it's >> likely they will do them again. > > > I very much agree with this statement > > https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Policies#Communication_When_Making_Fixes So QA has a policy for that and it was not followed... I am sorry but I think Mike is right complaining about the lack of communication. - -- Regards, Markos Chandras -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCgAGBQJU4d6NAAoJEPqDWhW0r/LCMg8QAK+sWgGECTBxI9zLL5xOGtJ7 frGCP9dFQWWdSwuK7sc8JE47zMayCdrHVegRehwsZtrfuho/nufH2Rmp0PCbHAoe Mx8VknGIEKXAiG/udmxFoH8WnLij1MCB+CJhr+R0qtjeyiZb68U051e7eE2NWOt9 KfFcywvhHM4k7ue/2BO4CX+EZIfi29L3lQGp9VjqTHuc4sY670MB2yS0k6P08UOA Lhf9xm1cf/oI6dZWW8FuIfnDDuVp+kssZlYonfLbQrC9nc1yPpsdkvvV9OIj85sJ IiML/xETB4L+AJqaVPrjdGaynza2UsnOtbfsE3P9AvR/Eq/tlb6MDo5hmxCVkuaM 97p/puCMu+NkwpFjkHI6ayX69DIs6N9+LLthTYHg3V2qOvlPXmXQOJbnV+QlWVjr dlzt6Q2sgHoPjeaL5EfZ3q1d6b2VeegWggZLG8dKtSmNsRQwziRyFoND0JgHX1zY dS26MKEbO67kQFdWWV7oNZINNlY0zWYettBk24gmnqUzdPA6kFrnBZ9CaxEPkeYP 3LJZl+QFc23pm6XfoEYuZ1zTmVh1yZICc8hiBLz70fOegodblG+TCUjZ+BfR72bP fkvlBKfEmrrnpFu3wSsUleZm1VbWa1gIa7cQHY0BbK/W7eMI1ZgvJ1M5k1CaSTrM gBFRI9+w3nMl4WN/ADfv =C9Tp -END PGP SIGNATURE-
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-libs/libusbhp: ChangeLog Manifest libusbhp-1.0.2.ebuild metadata.xml
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 02/16/15 13:31, Andreas K. Huettel wrote: > Am Montag 16 Februar 2015, 06:13:10 schrieb Mike Frysinger: > >> even then, deleting an ebuild purely due to different copyright >> is complete bs. > > The requirement for Gentoo copyright in the main tree is not > optional, but has been policy for a very long time. > > Just because you've been around forever doesnt mean you can break > the rules that everyone else is supposed to follow. > I too believe that if you are reverting someone's commit you should at least drop him an email to let him know. How else do you expect him to know he did something wrong? I am a bit worried QA is taking such actions without communicating that with the developer. If you don't let people know they do mistakes, it's likely they will do them again. - -- Regards, Markos Chandras -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCgAGBQJU4dgfAAoJEPqDWhW0r/LCos4P/0PSu6PhS/jJ7md8BN9rcUVZ PUEidEq3RsIBLyN1aaA+Hdexc9D5W8X5qmDqyOvg5L0rY2cT3Xrb+dMOucFQg0SU ODsq3AhIsnkEbZbH+WM89ri8sCCY8xWzhL5dTXlkCb3Hi9VGeC7YTvW8xHyC6xiC Suj33zqM13c2vuYiXDon6MSuMMa7u03AV4ZQSDtU+13cn2jpSR8l9b09phFjyDIZ 2fxPdaWcVW0iNOe94Vf3uavp4LxagMi4/9svxgayjfkqWwDh9uX9ibYNTQUnFsLV FE2xnJki17NhY2+s1A3CPqztuDFtfAinX6JJrNB8AT4VtDM4JvaixVSZ82u00/h3 QP2XvARmriyXUYMSbDrsnHxF0tf21fXOIEXXBFwsLRPRg43MAL1T3A2XtmiUK2sZ R7lA6uq+yPzs16OzAPiEC4PUSY/qXRGu9cUj+z41J49GtckkoL2GlFc3sjo5MhmV C8la6Q0JUKNm6r8joO5IUO0z6HsKjfsWNYDo8pOAZDlFa2Ca+1cox4IxDfTrDEJP B1xs3g9uHPft5Nb4inY3iGsIX/rqKgsR0zIPi475NBOvb/yFFMwpIwp220OwRjLh bfLg0psEYg2guSFYzDTZ5Ocd8p0kSjpuRbSLWozunWilKxR8/3H4CQUHnuInMs/s Mm8xc2USeMGAXktIgsPa =YU+G -END PGP SIGNATURE-
Re: [gentoo-dev] Re: vmware team needs help
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 02/15/15 01:55, Michael Orlitzky wrote: > On 02/14/2015 06:38 PM, Christopher Head wrote: >> On Sat, 14 Feb 2015 21:49:56 +0200 Markos Chandras >> wrote: >> >>> You don't have to participate to the discussions in the mailing >>> lists :) You can just contribute code! Even a single patch a >>> month or so is better than nothing >> >> Forgive me for hijacking the thread, but, the “or so” in the >> above isn’t all that flexible. >> >> See section 3.k of >> <http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=1&chap=3>. >> > >> > No one is going to boot you for inactivity if you have nothing to > do. You might get an "are you alive?" email, but assuming you > answer within a few weeks, "all my work is done" is the best reason > to be doing nothing. > > That is true yes. There is a difference between "I have nothing to do" and "I am not interested in doing anything anymore". If you only maintain one package and you commit once a year so be it :) It's a volunteering project so nobody can actually force you to maintain a certain rate of commits per $time. In case you appear inactive, people will send you a fair amount of emails over a significant period of time before they start the retirement process - -- Regards, Markos Chandras -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCgAGBQJU4GiyAAoJEPqDWhW0r/LCOxIQAIULbBbIys7eY41a4IwyKjOS LeuMXTAhiNbnB0/NAnjo+l9gxTxgCE3XRT42qjyIR3ChaoBZAcntOKfgLJ4EVuON jdGdCryUQd6Mii2tCgyvrw83gCVLvLMXdHdVKr7J5kE+NFdiQnDYNNaPnOmOhGWA Xr2ybAIJui+KayJbxFDHDPQVEflibrdezHI2WOhRqUgOQS3yCZhUI8q560YNh0dD P8EeVe6M16rJUNXzWzwXKS2Mf577/mZUoShzQOkD3f4O+5HwvNR8Bzl6qTpH4id9 7TeFdc7/8+QVIHOMZHctNSJu4f/tavLJp+5qH1t6XmLauqN2uZGJF8/7L+hdf2/N /5nP7MZn2/oh3AEEqp9guBUQY/QiWMC8rpwih0nP3agKGstoNJFPybFM0xVB7cdh 9f/dXBrgC8ZKh7LwXn+se+NAz2TMynigpzMdBvnvodBPEQaaCTC0yLiTxW1KmfkB FHyA6GKDocRhpNqpzARyqFOcQHSgWPfXATeos+g3ZVyyr4iaMNtS3n/lukkpmxM4 tOthWwEeaocNn8D/S2DRyq0otSFv2SNhStatNXbXZxO1QpCNxlhSxZMFQ8tpmm0o eqcDXWiDcQ3B7XagjvftO+RDY3CYbpsUQLUSKwprA6lBzs5UuFcezlE+NRO++myN Bo1Q+RDmdGfUaalpvkZt =CTYj -END PGP SIGNATURE-
Re: [gentoo-dev] Re: vmware team needs help
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 02/14/15 20:42, Nikos Chantziaras wrote: > On 14/02/15 20:30, Andreas K. Huettel wrote: >> Am Samstag, 14. Februar 2015, 15:38:12 schrieb Nikos >> Chantziaras: >>> On 13/02/15 00:03, Andreas K. Huettel wrote: >>>> We have an overlay that can be used and is used for user >>>> contributions. >>> >>> Any plans to move it to github so we can fork and send pull >>> requests? >> >> Any plans to take the quizzes and take responsibility yourself? >> :) > > I've been around long enough (2005-ish or so) to know that I don't > want the Gentoo dev-community drama :-P But perhaps more > importantly, I tend to disappear for whole months at a time. > > Should user-submitted patches/pull requests be sent to the vmware > herd email, or directly to you? > > You don't have to participate to the discussions in the mailing lists :) You can just contribute code! Even a single patch a month or so is better than nothing - -- Regards, Markos Chandras -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCgAGBQJU36bkAAoJEPqDWhW0r/LCbHgP/RrqhwyRFUxjBZhRnCRhRWeR o/FEX/JMSY3zXMfeJE47O3InqMewfxcREZxEI50W4g0mJGKy/Z+fOXbyo9efWRBE jNOZoRDh3ZXOIQL6lO7beQpJTzC7l2uI9/iqAe27IF0RV4KtufnIaOQA/IYuAd3f BN2hntL+roSzb2JZkU+MkvB3M63CvDeORz9vVJDKGXE1JbrzGHHOpRzhXO5nSDt8 td0qvpBrbyy2nipYbtOpbtJowVWuGoLFlw5L3FlnjvReMsPTshHXyAzwb8DDqszR VTux2KYKpjRvKC+jDPRuy0TQPQYeInLdO7uvpoXknmKey1UdRO3NU1V8PQ4llET4 k/WoX3ONlkOGyxkW0yRGLF9wwGJRfjqvKCfbW6Kc/VinhaNj6jzGahPZ1YZdu33X hBegfJgyDDivYoA56rHprjFdOKtGv7zpy3fbaP6RjN8MfP7wHPlw7CiJVX5aXRGx kTGYF2dYdekfmVIrLaPx6UGGBZcaoiqnpY3HiBo5jNFQTRSZWIxwAbyS7wdbvt32 YEZ8RUvBqJlJVNCzQpEaT8KO4YKRKjxRf5c2MQ7kXUAVjr1vpSutA7Gwcx1xsnEO m8Pi66V8h7Qno3egDFFydR3x2aESYE4q3ZxJX7zkWkleKBRVdLHjIsR8CFwg9J5J 39C695DOhcko0t+l/qnb =0B8P -END PGP SIGNATURE-
Re: [gentoo-dev] vmware team needs help
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 13/02/2015 12:03 ??, Andreas K. Huettel wrote: > > Hi all, > > I'm the only dev left in the vmware team who is taking care of > VMware Workstation and friends. Or more precisely, not taking care > of it these days, since my non-Gentoo workload is increasing and > since VMware Workstation is not really the highest thing on my > Gentoo priority list either (though I use it regularly). > > We could really need some help here... Things to do are e.g. * > vmware-workstation, vmware-player, vmware-modules major version > bump * tracking and applying patches to vmware-modules for newer > kernels * sorting out the screwed-up bundled library situation ... > :( > > We have an overlay that can be used and is used for user > contributions. > > The only real alternative is to treeclean and tell people to use > the bundled installer. No idea how well this works. > > Talk to me if interested... > > Best, Andreas > If you write a small item we can add it to the next GMN to reach a wider audience. I see we already have a vmware entry at http://wiki.gentoo.org/wiki/Project:Gentoo/Staffing_Needs/Vmware_developer which is nice :) - -- Regards, Markos Chandras -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCgAGBQJU32TmAAoJEPqDWhW0r/LCElQP/AyxKrLPXFFAxf81V5dB5SIB PItGeMu0FQrmQcKJ+0Phsr1UJTlkWqLghNOyEYU7sfcstfMKVmXPdOFpvBYyScnD R5DIgW8JAzoCuo54h1dJHdt4eS1DQiXMYjj+CfHk7SHmjVpG3CW4xkt1R5/DievG ZfLBYgmZYDuSBWmg4Ti9gnhASRTpG5H8N6/vlOV9Hw+f/B4yjbUt0XwEZ6ysxjkL Un88Ls+Jz0OKu5NseLuWuoS09/sZgEAQecQmmOaalfQkamAqewyYvU+YvZiwZt/I 1gW9zwc+8vnSPSlwpfqyQeT79omwS5+fUOAvyqwNzlFt+klnH/AgzP5dNOM+GZ4x eF7INgyqHV+nLWVB38rvq8DWF2XcT9ekcyYSrEybPXajLCRJZ9tY0K7FSyGkvstt u6zuGbJJx6HKqxPWFMwxPCToSoU22eGVcHxm46vNSdNmMTzJEm/vNjOEzkRo3OhQ T8tDA+ehQw/BybUDAcpTbtWRgIJyTBO727q/Spyu2db9clJuPZVUhIi7pokzyvcO 30iAo9++GGqGJR1TOlJJlfhBRb1eiaq0Hk3rR0J2y1MLBlNcVqhjss3gjF3Xoe6n ee+cSNHhMntxs6vWsgUcYSQ4daapUQCdE0A9TRvdjwVuQ4B4IkTtjsIctd0TzULj DG5VmYx9WuHXsYZt5bvS =dJ92 -END PGP SIGNATURE-
Re: [gentoo-dev] Quick RFC: USE=libav vs FFMPEG_IMPL=libav|ffmpeg
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 02/03/2015 02:04 PM, Michał Górny wrote: > Dnia 2015-02-02, o godz. 15:06:40 Michał Górny > napisał(a): > >> Hi, everyone. >> >> Just after the news item got published, user Wes mailed me with a >> suggestion. While I think someone mentioned it earlier in the >> bikesheds over ffmpeg, I have completely forgotten about it and >> now I'd like to reconsider it. For this reason, I've reverted the >> news item while it's still fresh and p.masked the revbumps. >> >> The idea is that instead of having USE=libav (that's tangential >> to USE=ffmpeg and confusing) to use a USE_EXPAND like FFMPEG_IMPL >> taking either ffmpeg or libav. Now, why... > > Oh, in case we go this way as the forums poll suggests [1], I'm > attaching the updated news item for review. > > [1]:http://forums.gentoo.org/viewtopic-t-1009988.html > I think this is getting too complicated in the sense that we bloat the make.conf file with new variables every now and then for no good reason. As a result, the time spent to maintain make.conf has been increased over time leading to more headaches on world updates etc. make.conf is there for a good reason, and that is to help you make your system highly configurable, but this should not get too complicated otherwise people will just lose interest and use a "good-default" one instead of spending half an hour tweaking it. imho, in this particular case, the old behavior is fine by me and it's what has been around for a long time. If that's not clear, or causes confusing, perhaps it would be best to document the use flags in a better way and deal with it. - -- Regards, Markos Chandras -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQF8BAEBCgBmBQJU0UaIXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGRDlGMzA4MUI2MzBDODQ4RDBGOEYxMjQx RjEwRUQ0QjgxREVCRjE5AAoJEB8Q7UuB3r8ZNlQIAI0ZmTxUkNj2Food8yoH7pO8 jT1kJEPObHDdnjegLzkytISqBLHsGK12fsyKQlQTrwn3cEtiCnZV/PFgP/Afz3o4 iapGa6zKSSLJA3wyQhHuSw8rnqxyV22H2sh5aqmnbxnh6ENamQ1XSVjLgsLq3/K7 gjG5MQG09KEKpjvZPCpHs0CvznfWJAuRa3mprHGiTdtOm8ooztTH76er/KWjndOV pyFneHABL7devZuJvPqSwz+mqJ5SDcc72P4tdGRhw1fF/v0cnrlL6pnYiOmlGREy TNJB7udrZnp/poZkArCC0eiIWBXRKirdM8NfozF/jVgUjOb+A9sb9fquSFO8z2E= =U+v7 -END PGP SIGNATURE-
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-libs/libuv: libuv-1.2.1.ebuild ChangeLog
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 01/17/2015 05:09 AM, Andrew Savchenko wrote: > On Sat, 17 Jan 2015 08:56:01 +0800 Patrick Lauer wrote: >> On Friday 16 January 2015 18:29:08 hasufell wrote: >>> Patrick Lauer: >>>> On 01/16/15 23:26, hasufell wrote: >>>>> Patrick Lauer (patrick): >>>>>> patrick 15/01/16 04:16:55 >>>>>> >>>>>> Modified: ChangeLog Added: >>>>>> libuv-1.2.1.ebuild Log: Bump >>>>> >>>>> I expect people to ask me for review if they bump any of my >>>>> packages. That includes QA team members. >>>> >>>> Are you always in such a bad mood? >>> >>> Do you, as QA team member, think that a review workflow >>> improves quality? >> >> No. >> >> Bureaucracy does not improve quality by itself. > > This is not a formal bureaucracy, there are some rules to behave > in community and these rules are supposed to be equal for > everyone: > http://devmanual.gentoo.org/ebuild-writing/ebuild-maintenance/index.html > > "Touching other developers ebuilds". > > The fact that developer with QA team member mandate (even if it > was not used in this case) intentionally violates this policy > without even considering this action as something abnormal is very > disturbing. > > Best regards, Andrew Savchenko > we are having the same discussion every couple of months. It should have been a clue that such issues are not meant to be solved in the list since we tend to drive everything off-topic in the end. It might be best to report such issues to the designated teams. At least then, if there is no solution, at least you followed the normal procedure - -- Regards, Markos Chandras -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQF8BAEBCgBmBQJUujN7XxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGRDlGMzA4MUI2MzBDODQ4RDBGOEYxMjQx RjEwRUQ0QjgxREVCRjE5AAoJEB8Q7UuB3r8ZWegH/jaswVnHB14ozVO54TWwiThf VWMoFlvE093jYIU/pxWK+4+petQX5ikAONagcnR4zPKIQybtUEnLGTH70A/lFvyU oDjyroJg2Mq2auRD7s1pETEVXWhroh+gDLmR7SBcHXCAcJSyOlu4rhPRDlZPkBJV BaeMMUE+0dcHQYypKGizSt20ov0LT396smGWgFZFxjSJsEs8H6iDuxzJm5JdB+AZ S6AFbIlwsXi4gTWIk2fxbGg2pRUUDwykhoWfu3pv2iIwuOLbGGrct6xRm/vlzLrB HFdnqVqVEzd/LcjW4cYmTkFbup6L0qCfUKu2cxkRI/EJfIIsJLmN9O557r47Gm8= =JH6B -END PGP SIGNATURE-
[gentoo-dev] Last rites: app-misc/fixdos
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 # Markos Chandras (23 Dec 2014) # Homepage returns 404 which probably suggests upstream has vanished. # Superseded by app-text/dos2unix. Bug #533222 app-misc/fixdos - -- Regards, Markos Chandras -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQF8BAEBCgBmBQJUmcxQXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGRDlGMzA4MUI2MzBDODQ4RDBGOEYxMjQx RjEwRUQ0QjgxREVCRjE5AAoJEB8Q7UuB3r8ZRr0H/iYLi80GraQ9QoHujNJcl7hq 7jdNdAXuHfOgnNUgHAhIAoAeBEEjjQgTbzbtHYv7HiSzBoi3ygpKMnuNzUWI8x3L uRMZU404JHWHOcBFYQ8zcoiVyc16kLewBvIYArYQ+mB87kkLNAElDPszE18N4I9f rojetCbMGyN52WyxPrYY+n572snca+rU8ZlKFw+i96DGcK/kS6KTXNCJKjb8qEeH 6Nuj4K2n2aUHpswag4em1ennDsV96kfSQ1FNpjL/u3B7/m614JrKq6Pt9NGqNvnw 6ptmqK0crQJxqdsG/U7WxF9AFmqIfR1D0ZNJRo4y60S3yU+Fw7a1aAmYCF+p9QU= =SBs6 -END PGP SIGNATURE-
Re: [gentoo-dev] rfc: glibc versions prior to 2.19-r1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 12/21/2014 03:28 PM, William Hubbs wrote: > All, > > the following is a comment Mike made about the status of glibc in > an earlier thread on this list: > > On Sun, Aug 03, 2014 at 09:16:52AM -0400, Mike Frysinger wrote: >> upstream glibc has dropped support for older Linux kernels. your >> choices: - upgrade your kernel - switch to a different C library >> - stick with glibc-2.19 for a while >> >> be warned though there are no plans atm to backport things to >> glibc-2.19. this includes security fixes, but more importantly as >> time moves on, making newer gcc versions sanely compile glibc. >> we've kept older glibc versions around to be nice, and on a part >> time basis for cross-compiling, but none of those are given >> priority. i.e. fixes come as people feel like doing them. >> >> certainly once glibc-2.20+ goes stable, there is no expectation >> let alone requirement that packages in the tree be kept working >> with older glibc versions. the maintenance cost there is >> unreasonable. >> >> i guess if you're stuck on old crap, now would be a good time to >> start preparing to unstick your crap. glibc-2.20 will most >> likely be in ~arch in the next 6 months. -mike > > Since glibc-2.19-r1 is stable everywhere, what I want to know is > whether we can remove versions *prior* to 2.19-r1 at this point. > > If we do, that makes it easy to fix bug 478764 [1], because there > would only be three versions of glibc we have to worry about. > > thoughts? > > William > > [1] https://bugs.gentoo.org/show_bug.cgi?id=478764 > I suppose it makes sense to drop old glibc ebuilds. - -- Regards, Markos Chandras -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQF8BAEBCgBmBQJUlx7ZXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGRDlGMzA4MUI2MzBDODQ4RDBGOEYxMjQx RjEwRUQ0QjgxREVCRjE5AAoJEB8Q7UuB3r8ZCJ4H/0coofEKcsika34IaHI609gR Q2ZOhmcgV82wu6zwpIRVQaIDFCfo170c1g6OfffaaVLpu6VrvlN0lOxA0s2fPVuk pyf3ZjmElVyhncPtfCBIlygfvdabEv5UCEi8dgOe59tz6SyXarvRdKdQOsWy8yRx 38LGDH/vcmlcTbVKXfKuNPZ52hhfTspw7/QDxIqwufDqXaFV/sP+nLRTWKlK293I twO6biE3m60ggwaEyL5+LT4ZQZTQ2MnfDpBD8Rr1+xPwIj7rvgbJCVul1B1NZq6m gxYS078K8SeSEroum4wrZKj6OI8oIAic7Apa9wpp+tDXPOMYYn7SxvNtOBVpa/w= =rlNJ -END PGP SIGNATURE-
Re: [gentoo-dev] Dropping GCC maintainership
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 10/17/2014 09:43 PM, Anthony G. Basile wrote: > On 10/17/14 14:55, Markos Chandras wrote: >> -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 >> >> On 10/07/2014 01:00 AM, Patrick McLean wrote: >>> On Mon, 06 Oct 2014 19:25:53 -0400 "Anthony G. Basile" >>> wrote: >>> >>>> On 10/06/14 13:13, Markos Chandras wrote: Let's face it, this >>>> is not a job just anyone can do. I asked a few people I >>>> thought could handle it and they said they're too busy. So >>>> I'm a bit worried. >>>> >>> If someone with the appropriate skills is interested, but >>> currently has no time. We have some open positions at my >>> employer where Gentoo work is part of the job. >>> >>> Work locations are available in Orange County, CA/USA, San >>> Mateo, CA/USA and Berlin, Germany. >>> >>> Contact me off-list if you are interested. >>> >>> >> Well I think this haven't been addressed yet (or has it?). Shall >> we start a discussion about this problem since Gentoo is not >> really functional without an active GCC maintainer. > > I'm trying to clear blockers to gcc-4.8 and then I'll start working > on 4.9. I'm going to formally ask to be part of the > toolchain/gcc-porting team and I'll try to help, but this does take > lots of skill. > Perhaps it makes sense to write something here as well? https://wiki.gentoo.org/wiki/Project:Gentoo/Staffing_Needs - -- Regards, Markos Chandras -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQF7BAEBCgBmBQJUZlDCXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGRDlGMzA4MUI2MzBDODQ4RDBGOEYxMjQx RjEwRUQ0QjgxREVCRjE5AAoJEB8Q7UuB3r8ZpvYH9iVzRPgJuEHHt4oZ9wBibawP N8x5Dillzd8K1Ypq8RNvNEhlT1uPUQE/RDcKxH6mTvbpxTJwNy6F7MSxkjDU56F9 YRAyXppPdKecHBvi1F5qyrfV2s9idmSWGLCAhhwjvYSo5NbikYdsWW8syVuKg+Wx vMMhnkP4MuFPSFexI/5s7rB6JAtXhNsMsmNNV1SlIkgKBpLPQjx3jWAaEA/Brmrd nkmFzWEJy1oOg0MmUI9XXDG9DfLO7JEKGpZGlHp2lD464W0QWoZWCJa9w84Kawu4 jKFLRoXRp1e0DxUlZV0tpvBVNux9FxJ29ZVaL+5Lqxrw4C8Go0ZWisaanBKwjg== =i7bP -END PGP SIGNATURE-
Re: [gentoo-dev] Dropping GCC maintainership
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 10/07/2014 01:00 AM, Patrick McLean wrote: > On Mon, 06 Oct 2014 19:25:53 -0400 "Anthony G. Basile" > wrote: > >> On 10/06/14 13:13, Markos Chandras wrote: Let's face it, this is >> not a job just anyone can do. I asked a few people I thought >> could handle it and they said they're too busy. So I'm a bit >> worried. >> > > If someone with the appropriate skills is interested, but currently > has no time. We have some open positions at my employer where > Gentoo work is part of the job. > > Work locations are available in Orange County, CA/USA, San Mateo, > CA/USA and Berlin, Germany. > > Contact me off-list if you are interested. > > Well I think this haven't been addressed yet (or has it?). Shall we start a discussion about this problem since Gentoo is not really functional without an active GCC maintainer. - -- Regards, Markos Chandras -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQF8BAEBCgBmBQJUQWY+XxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGRDlGMzA4MUI2MzBDODQ4RDBGOEYxMjQx RjEwRUQ0QjgxREVCRjE5AAoJEB8Q7UuB3r8ZqN4IAMEwl9FG31THw628gKNgzMUv oOz8KaNfSwnXiDMfukTABh7+cv3enhhNmOf1No4KgezyaPpMkIjmSlTp5FYjnSjt fmM2KcSF+fosO0VKlOrpdidSq2N92mIn3i9vjWUsWdsrqNq0oXIEiG0L5NBIGHNB Y5UC51Psx38nQAKE9NPb7wx43pdjRz4YKP+axVDK2U4GxHClZB0E7QDzsIDTiuhL M1Q9x1ILK8a6tIzksB0xuUghG6/9W2JaTNOF1nVI2tcXfxcFdTnXVHsuEh0VaBR3 Cl9fmff7Y0jEtynfKYIzbuqnU9VUH/9kXNAO5A4mY+0wwT05kDC/ecV0Xun8C+w= =6tyN -END PGP SIGNATURE-
Re: [gentoo-dev] Dropping GCC maintainership
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 10/05/2014 11:44 PM, Ryan Hill wrote: > Hey all, I'm stepping down as GCC maintainer. I haven't been > reading toolchain bugmail since June, and keep telling myself I'll > tackle it next weekend, which never happens. To be frank, I'm > kinda sick of Gentoo. I'm hoping it's temporary but we'll see. In > the meantime I don't want to be responsible for holding up any work > while I figure things out. > > Thanks, > Thanks for letting us know Ryan. Does anybody know if there is someone from the toolchain@ team who is going to take care of gcc from now on? - -- Regards, Markos Chandras -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQF8BAEBCgBmBQJUMs2tXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGRDlGMzA4MUI2MzBDODQ4RDBGOEYxMjQx RjEwRUQ0QjgxREVCRjE5AAoJEB8Q7UuB3r8ZFwkH/0lpV0/ph88gKCOJznflrtgN ixi0s8HRWWDJ8LYMERTHl3s0Lq+T85RWx437y2rMZZ7oRo0GB6ng6rBsvqe9ECqk wfu3vcuDSyj7MGLlIrshzM9QpRtYJKwP0aHKnM0A7M56/cSMZyR9znxosgpWWXwE vgUJ7pErItnPGjMT1cTr0BJMACB4qk/OkEfKdKlXePle+LGcCjHi9kc17KdhwArm mwgg+aUmrfBrdQi2ad5XeYNLLebKAymwwkMzGzrqTuPATyJ0ChUP6uuSouar+Uuc ITDE7DzeTwVA0S4DokfQ7l2KslYykWFC10+a4kUTi9bfq0PjVR6UTR1wgPU2NGs= =C0dB -END PGP SIGNATURE-
Re: [gentoo-dev] RFC: Deprecating and killing the concept of herds
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 09/11/2014 07:30 PM, Tom Wijsman wrote: > On Wed, 10 Sep 2014 21:21:24 +0100 Markos Chandras > wrote: > >> On 09/10/2014 03:01 PM, Tom Wijsman wrote: >>> >>> +1; to summarize my thoughts: Herds misrepresent manpower. >>> >> true and false. > > More true than false. > >> undertakers often remove dead herds. > > How often? What is considered dead? How about semi-dead? How about > the misrepresented ones? Are metrics like commit and bug ratios > considered? > > Relevant: http://www.gossamer-threads.com/lists/gentoo/dev/258463 > >> And herds in need for more people should really make use of this >> wiki page >> >> https://wiki.gentoo.org/wiki/Project:Gentoo/Staffing_Needs > > They do and don't. > > Those that do, are drowned in a long list that rarely attracts new > devs; those that don't, don't have time for it as they are drowned > in work. > > The recruitment process is too lengthy compared to the amount of > people that can actively recruit new developers; as a result, this > contributes to the rarity of attracting new developers to that > list. > > This lengthy process is also unattractive to new recruiters; whom > are not kept in the loop when showing interest, eg. I've watched a > few sessions and then heard nothing (because there barely are > recruiters?). > > If we want to thrive, both the student and recruiter recruitment > processes need to be revised; at this moment, 13 students are in > the queue. Some of them have been waiting for weeks or months... > >> how do you expect to get more people on board if you don't make >> it known where help is actually needed? > > This acknowledges that the herds concept hides where help is > needed; but as revealed in the last paragraphs, that's not the only > problem. > please do not go offtopic discussing the recruitment process. I simply mentioned one of the designated ways we have to ask for help. If you don't like it, propose a better method. - -- Regards, Markos Chandras -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQF8BAEBCgBmBQJUEf9QXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGRDlGMzA4MUI2MzBDODQ4RDBGOEYxMjQx RjEwRUQ0QjgxREVCRjE5AAoJEB8Q7UuB3r8Z5S4H/RzX++Z/slhMjpYwGqu4zA1P DgByLHnINhQPFpNYIxfgvAFCjVp+drCllRvzvE3IdCdfR1HsLUYeLNMDby8SQlAr axHklrtQGeSXK9rd9leYvfa/lCzNahFj5PWbPeJFco1j7V7BDJCYKS1FxQpQhAyg H5MiBFDRZK403qt8U4JsOCGEpI5Uy+US+xTAXHTV0u0YKW0u8S/znju6TM2WVWy2 qFTTQvH4vNf38zj6+UVzFa16xw5wYeIajMHLm7cTg98pDU4UcVEbeeZ0vEUX6DS8 XSlGO93haF9E4v4giMaQXXHtRmJzhHXdx78mnir4u1tdIfqG3Q8bjGnNVmu7GWU= =UyIv -END PGP SIGNATURE-
Re: [gentoo-dev] RFC: Deprecating and killing the concept of herds
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 09/10/2014 03:01 PM, Tom Wijsman wrote: > On Tue, 9 Sep 2014 21:45:49 +0200 Michał Górny > wrote: > >> Let's keep it short: I think herds don't serve any special >> purpose nowadays. Their existence is mostly resulting in lack of >> consistency and inconveniences. > > +1; to summarize my thoughts: Herds misrepresent manpower. > true and false. undertakers often remove dead herds. And herds in need for more people should really make use of this wiki page https://wiki.gentoo.org/wiki/Project:Gentoo/Staffing_Needs how do you expect to get more people on board if you don't make it known where help is actually needed? - -- Regards, Markos Chandras -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQF8BAEBCgBmBQJUELLEXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGRDlGMzA4MUI2MzBDODQ4RDBGOEYxMjQx RjEwRUQ0QjgxREVCRjE5AAoJEB8Q7UuB3r8Z1WAIAKW0Q1KipbiIGsOZ/R9vjgIQ fA7gJx5D+YcFyJdqPQUm5qt9WqxQv8p8TD5tacihxIF13WCS8BnMxDUf3BbErWJF 8RBPR2/T2L303YJ3xq/hTsdI2MoEiaKaOSUSDIbT18pNyLLNRabIBDLpM8jRPl0i cLK70yUwkht70y8tI8NiCQCtSk6dMZpzgvq9JFNyDO+jPlSt3NMMIO6KsCg7ZfH1 8pqiAUW9T3BwrX0nWGWgnUguuZ6+Q5UJXVvELWtHDeyuVq02MNdJqPLfTEeo9U+6 SMCquUU7/Owg2cXLCVG0arrEeJEgoWR7qtPMZqkxmIH1c1OlS81WEHoH/29uqAQ= =Dijl -END PGP SIGNATURE-
Re: [gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2014-08-17 23h59 UTC
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 09/06/2014 09:16 AM, Markos Chandras wrote: > On 09/05/2014 11:42 PM, Robin H. Johnson wrote: >> Oldschool python broke on the new CVS box, fixed now. > > > Hi Robin, > > Ok thanks. Is there a way to generate some stats for August so we > can put them on the GMN? otherwise we will skip that section. > > apologies I just noticed you have already sent these emails. - -- Regards, Markos Chandras -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQF8BAEBCgBmBQJUCuhyXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGRDlGMzA4MUI2MzBDODQ4RDBGOEYxMjQx RjEwRUQ0QjgxREVCRjE5AAoJEB8Q7UuB3r8ZkekH/RNxkWC2hbozov75rLcEvT2+ 602BaurICC1TBv2utPNz73B0TGMz3X4txeMCfBSV4+vL091ZzcXdRT8WbyEJWVEC TZPNb2Tb8g99j7r1EW8ELF2yd3FgmqRljWyJVJYx94TC1z4oBZb3YgWWhM6t+5Gj URYvOSYIb8xrJOQR+aMWJDFVqx3FMNufsXLtSF27+rxt9igUvKhhBaO3lJFi+2g3 hoqpP6nZxp/w+daw/fAwvB5HUQwYG/pcSCrfwoG7F0iS2rS4mO6Hh785ZmVu3LTz EkskcroEDUSwQ96K6yoB9bAZelnXoodet4EjWbDexk3WMeG2XWUOuF01K00RSQQ= =g1xK -END PGP SIGNATURE-
Re: [gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2014-08-17 23h59 UTC
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 09/05/2014 11:42 PM, Robin H. Johnson wrote: > Oldschool python broke on the new CVS box, fixed now. > Hi Robin, Ok thanks. Is there a way to generate some stats for August so we can put them on the GMN? otherwise we will skip that section. - -- Regards, Markos Chandras -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQF8BAEBCgBmBQJUCsLeXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGRDlGMzA4MUI2MzBDODQ4RDBGOEYxMjQx RjEwRUQ0QjgxREVCRjE5AAoJEB8Q7UuB3r8ZQR8H/22hdfZfk1TZiR2bxR5pPEwW 1zViksO3cuw43zXpfsu81LPA90N1hrlI5n/qPokDUz6EE/Hg08NcVL6DSZ96PIO9 YUUgoIpKVq/LVfIuMs8RzdZn02hGzGerJquqLb6wUKFOnCjSEwZzZaq0YbO2kPzz K1ocxK+5R5J7q/KWAJ2fafbkPd5vSTNZPhtcmyjsa3QkaHhFDHVWqHyI+xAXxka0 VCCbwG+h6yNcORwGuAfkW2nlf3A1yfsRJCaCOOZbzNTHPQ7yNTavYph4o6EdDOoX /LQjJO78J0CXwo9apQBsnixEqdFTZ0eBylTzt3ctGhhKVx0Ubzm2NR38iUqLs7Q= =ewYk -END PGP SIGNATURE-
[gentoo-dev] Last rites: net-im/kmess, net-im/amsn, x11-themes/amsn-skins
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi, They were already masked, but because of http://www.forbes.com/sites/amitchowdhry/2014/08/31/msn-messenger-is-completely-shutting-down-on-october-31st/ , I see no point having these packages in the tree anymore. I will remove them in 30 days # Markos Chandras (02 Sep 2014) # MSN service terminated. # You can still use your MSN account in net-im/skype # or switch to an open protocol instead # Masked for removal in 30 days net-im/kmess net-im/amsn x11-themes/amsn-skins - -- Regards, Markos Chandras -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQF8BAEBCgBmBQJUBiyzXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGRDlGMzA4MUI2MzBDODQ4RDBGOEYxMjQx RjEwRUQ0QjgxREVCRjE5AAoJEB8Q7UuB3r8ZiNcH/iIL0+JYyuii+twmCsqh85qp UduFljf8oJaj41n70oVBwxKqGRJ3x6Jhwpmugcje3HwE4rQFGBbdGVvj84xHZJb8 p6GWvi/pNhTIeXxazGsWUJddj8T0OpSd5NcmNVACKF4xdNYtzk47QjO+d1UsGVWC 4PpAqQ0XXsTLCMf5dR6XNjK4OOw/PKH99ndV7/KhVDs2madOYjaux0s25mKPW1jH ZNJT76C6ChMrjzetiugShMFddwj2R8DWf2m27QbcfUQByU+tDEhTONweQs9pZuFK 1ZxBnx9qKMPk117jO77jVmtESXjRMRXBWViUYJ8rV2NC9SAcvXI79Ga938X2ssE= =Kj7X -END PGP SIGNATURE-
Re: [gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2014-08-17 23h59 UTC
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 08/18/2014 01:25 AM, Robin H. Johnson wrote: > The attached list notes all of the packages that were added or > removed from the tree, for the week ending 2014-08-17 23h59 UTC. Hi, (cc'ing infra) I noticed he haven't received these weekly emails for two weeks. Is there a problem? Maybe you turned them off during the migration but never turned them back on? Is there another problem? Is there a way to get some stats for August so I can use them for the upcoming GMN? - -- Regards, Markos Chandras -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQF8BAEBCgBmBQJUBg8KXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGRDlGMzA4MUI2MzBDODQ4RDBGOEYxMjQx RjEwRUQ0QjgxREVCRjE5AAoJEB8Q7UuB3r8ZO50H/RN3/SQUn1j8KQeJzgr+d2lY iN04B4NtXpKmwhLNa/2i9XV8kXqWOiKPi1s9cUpNXOMj3P6MsO4vxUGvgyV26UVM LP2tyRtFbZSpYWGT1ymtoSg4mvYaGEbPxesPyH9kwwxZ2+MFlpg+KFBVEmxzW8ho 8IA9kTQ8g+Ru8gu/qFT3ZfMEx/AVD27D57mX8RVhvO3iYXISZEtcZ7veZV9rNX4z PsX++iF+keNXNYWAIVy832Mrmzfo40utQTp3B31JlRHhZun9MBpEK45FPSRNtyPy gZocH2F6JIqokCeFbm0+gWS/fSF/JK6RMQaO2gGacJXiZvEEXto8g1T6z5cRLKI= =xI+p -END PGP SIGNATURE-
Re: [gentoo-dev] Re: maintainer-needed@ packages need you!
On 09/01/2014 12:15 AM, Patrick Lauer wrote: > On Sunday 31 August 2014 11:39:22 hasufell wrote: >> Martin Vaeth: >>> hasufell wrote: >>>> On 08/30/2014 02:35 PM, J. Roeleveld wrote: >>>>> For net-im/skype, >>>> >>>> Screw skype. >>> >>> Please don't. Not all communication partners are linux users. >> >> Tox is multiplatform. >> >>>> We have tox [1] on the way. >>> >>> This is far from being ready, especially for non-specialists. >>> It is not even foreseeable whether the Android client will ever >>> be able to do at least audio. (So far, I was not even able to >>> exchange any messages at all. It may be my mistakes, but >>> if I am not able to do it, how could I expect this from casual >>> computer users?) >> >> This has nothing to do with specialists. Tox is configuration-free. >> >> And sure, it's pre-alpha as indicated in my previous mail. > > So it doesn't work, but you feel the need to feel superior by telling > everyone > else that they are doing it wrong. > > Sigh. > > Can you please troll somewhere else? > (picking random email to reply) can we please move this off-list? -- Regards, Markos Chandras
Re: [gentoo-dev] maintainer-needed@ packages need you!
On 08/30/2014 12:46 PM, Michał Górny wrote: > Hello, > > Right now, we have 1262 packages assigned to maintainer-needed@. Only > a few of them have a large number of bugs, many have just version bump > requests. 953 packages have no bug open. > > Please consider adopting some of the packages, or at least fixing some > of the relevant bugs. For package - bug count list, take a look at [1]. > Please note that this list is not autogenerated, so it will soon be > outdated, I hope :). > > We should also consider removing some of the packages listed there. > > [1]:http://dev.gentoo.org/~mgorny/maintainer-needed.txt > We already maintain such a list (along with instructions how to get involved) here https://www.gentoo.org/proj/en/qa/treecleaners/maintainer-needed.xml -- Regards, Markos Chandras
Re: [gentoo-dev] Docker 1.0.0 masked for no known reason?
On 06/29/2014 10:23 AM, Patrick Lauer wrote: > On Sunday 29 June 2014 17:03:52 Patrick Lauer wrote: >> On Sunday 29 June 2014 10:12:22 Tom Wijsman wrote: >>> On Sun, 29 Jun 2014 09:09:36 +0100 >>> >>> Markos Chandras wrote: >>>> It's been a long time. To be honest I don't remember masking docker >>>> but I most likely did it because I was asked to mask >=lxc-1.0.0 by >>>> the virtualization team (and Diego (flameeyes). And docker depends on >>>> lxc-1.0.0 according to the ebuild. But now that you have unmasked >>>> docker, i think the deptree will be broken since lxc is still masked. >>> >>> Repoman is monitored; therefore, someone from the QA team or so has >>> probably masked Docker. Given that broken dependency tree again it is >>> likely to happen again. So, please set it up a satisfiable state. :) >> >> AutoRepoman :) >> >> So that was me fixing the depgraph, taking the easy way out of adding an >> unsatisfiable package to an existing related package.mask. >> >> If people can't be bothered to even run repoman full or commit without >> --force they'll get annoyed by my corrections - maybe it has an educational >> effect ;) >> >> Have fun, >> >> Patrick > > Tadaah: > > dependency.bad22 >app-emulation/docker/docker-1.0.0.ebuild: RDEPEND: > ~amd64(default/linux/amd64/13.0) ['>=app-emulation/lxc-1.0'] >app-emulation/docker/docker-1.0.0.ebuild: RDEPEND: > ~amd64(default/linux/amd64/13.0/desktop) ['>=app-emulation/lxc-1.0'] >app-emulation/docker/docker-1.0.0.ebuild: RDEPEND: > ~amd64(default/linux/amd64/13.0/desktop/gnome) ['>=app-emulation/lxc-1.0'] >app-emulation/docker/docker-1.0.0.ebuild: RDEPEND: > ~amd64(default/linux/amd64/13.0/desktop/gnome/systemd) ['>=app- > emulation/lxc-1.0'] >app-emulation/docker/docker-1.0.0.ebuild: RDEPEND: > ~amd64(default/linux/amd64/13.0/desktop/kde) ['>=app-emulation/lxc-1.0'] >app-emulation/docker/docker-1.0.0.ebuild: RDEPEND: > ~amd64(default/linux/amd64/13.0/desktop/kde/systemd) ['>=app- > emulation/lxc-1.0'] >app-emulation/docker/docker-1.0.0.ebuild: RDEPEND: > ~amd64(default/linux/amd64/13.0/developer) ['>=app-emulation/lxc-1.0'] >app-emulation/docker/docker-1.0.0.ebuild: RDEPEND: > ~amd64(hardened/linux/amd64) ['>=app-emulation/lxc-1.0'] >app-emulation/docker/docker-1.0.0.ebuild: RDEPEND: > ~amd64(hardened/linux/amd64/no-multilib) ['>=app-emulation/lxc-1.0'] >app-emulation/docker/docker-1.0.0.ebuild: RDEPEND: > ~amd64(hardened/linux/amd64/no-multilib/selinux) ['>=app-emulation/lxc-1.0'] >app-emulation/docker/docker-1.0.0.ebuild: RDEPEND: > ~amd64(hardened/linux/amd64/selinux) ['>=app-emulation/lxc-1.0'] >app-emulation/docker/docker-1.0.1.ebuild: RDEPEND: > ~amd64(default/linux/amd64/13.0) ['>=app-emulation/lxc-1.0'] >app-emulation/docker/docker-1.0.1.ebuild: RDEPEND: > ~amd64(default/linux/amd64/13.0/desktop) ['>=app-emulation/lxc-1.0'] >app-emulation/docker/docker-1.0.1.ebuild: RDEPEND: > ~amd64(default/linux/amd64/13.0/desktop/gnome) ['>=app-emulation/lxc-1.0'] >app-emulation/docker/docker-1.0.1.ebuild: RDEPEND: > ~amd64(default/linux/amd64/13.0/desktop/gnome/systemd) ['>=app- > emulation/lxc-1.0'] >app-emulation/docker/docker-1.0.1.ebuild: RDEPEND: > ~amd64(default/linux/amd64/13.0/desktop/kde) ['>=app-emulation/lxc-1.0'] >app-emulation/docker/docker-1.0.1.ebuild: RDEPEND: > ~amd64(default/linux/amd64/13.0/desktop/kde/systemd) ['>=app- > emulation/lxc-1.0'] >app-emulation/docker/docker-1.0.1.ebuild: RDEPEND: > ~amd64(default/linux/amd64/13.0/developer) ['>=app-emulation/lxc-1.0'] >app-emulation/docker/docker-1.0.1.ebuild: RDEPEND: > ~amd64(hardened/linux/amd64) ['>=app-emulation/lxc-1.0'] >app-emulation/docker/docker-1.0.1.ebuild: RDEPEND: > ~amd64(hardened/linux/amd64/no-multilib) ['>=app-emulation/lxc-1.0'] >app-emulation/docker/docker-1.0.1.ebuild: RDEPEND: > ~amd64(hardened/linux/amd64/no-multilib/selinux) ['>=app-emulation/lxc-1.0'] >app-emulation/docker/docker-1.0.1.ebuild: RDEPEND: > ~amd64(hardened/linux/amd64/selinux) ['>=app-emulation/lxc-1.0'] > > Yeah, lets wait for Greg or Tianon to reply and if docker+lxc works for them we can unmask lxc. -- Regards, Markos Chandras
Re: [gentoo-dev] Docker 1.0.0 masked for no known reason?
On 06/29/2014 10:03 AM, Patrick Lauer wrote: > On Sunday 29 June 2014 10:12:22 Tom Wijsman wrote: >> On Sun, 29 Jun 2014 09:09:36 +0100 >> >> Markos Chandras wrote: >>> It's been a long time. To be honest I don't remember masking docker >>> but I most likely did it because I was asked to mask >=lxc-1.0.0 by >>> the virtualization team (and Diego (flameeyes). And docker depends on >>> lxc-1.0.0 according to the ebuild. But now that you have unmasked >>> docker, i think the deptree will be broken since lxc is still masked. >> >> Repoman is monitored; therefore, someone from the QA team or so has >> probably masked Docker. Given that broken dependency tree again it is >> likely to happen again. So, please set it up a satisfiable state. :) > > AutoRepoman :) > > So that was me fixing the depgraph, taking the easy way out of adding an > unsatisfiable package to an existing related package.mask. > > If people can't be bothered to even run repoman full or commit without > --force > they'll get annoyed by my corrections - maybe it has an educational effect ;) > > Have fun, > > Patrick > Thanks for the explanation Patrick -- Regards, Markos Chandras
Re: [gentoo-dev] Docker 1.0.0 masked for no known reason?
On 06/29/2014 09:12 AM, Tom Wijsman wrote: > On Sun, 29 Jun 2014 09:09:36 +0100 > Markos Chandras wrote: > >> It's been a long time. To be honest I don't remember masking docker >> but I most likely did it because I was asked to mask >=lxc-1.0.0 by >> the virtualization team (and Diego (flameeyes). And docker depends on >> lxc-1.0.0 according to the ebuild. But now that you have unmasked >> docker, i think the deptree will be broken since lxc is still masked. > > Repoman is monitored; therefore, someone from the QA team or so has > probably masked Docker. Given that broken dependency tree again it is > likely to happen again. So, please set it up a satisfiable state. :) > It's been a long time and sources.g.o is down so i can't check the history of that file. I think docker-1.0 was not present when i first committed >=lxc-1.0.0 in the tree. So, when docker-1.0 was committed, maybe repoman full was not checked, leading to a docker with broken deps and maybe QA team masked it because of that. Anyway apologies for the inconvenience. It was certainly not intentional -- Regards, Markos Chandras
Re: [gentoo-dev] Docker 1.0.0 masked for no known reason?
On 06/29/2014 03:58 AM, Greg Kroah-Hartman wrote: > Hi Markos, > > I was wondering why docker 1.0.0 wasn't seeming to get updated on my > boxes recently, despite me commiting the update to the cvs tree, and > Tianon noticed that it was masked at the moment: > > # Markos Chandras (03 May 2014) > # Masked for further testing >> =app-emulation/lxc-1.0.0 >> =app-emulation/docker-1.0.0 > > Which is odd, given that I never saw a bug report, nor did Tianon, and I > thought we were the ones working on maintaining this package in the > tree. > > So, what's up with keeping docker from being updated? Is it just an lxc > bug? This works just fine on my other boxes with other distros :) > > And why mask without at least dropping me an email? > > thanks, > > greg k-h > Hi Greg, It's been a long time. To be honest I don't remember masking docker but I most likely did it because I was asked to mask >=lxc-1.0.0 by the virtualization team (and Diego (flameeyes). And docker depends on lxc-1.0.0 according to the ebuild. But now that you have unmasked docker, i think the deptree will be broken since lxc is still masked. -- Regards, Markos Chandras
Re: [gentoo-dev] Packages up for grabs
On 06/02/2014 02:03 PM, Jeroen Roovers wrote: > On Fri, 30 May 2014 23:07:55 +0100 > Markos Chandras wrote: > >> On 05/28/2014 09:32 PM, Dirkjan Ochtman wrote: >>> Perhaps it makes more sense to disband the herd and put all packages >>> except the ones you use up for grabs? > >> I suppose so. Let me have a look and see how many packages belong to >> that herd and then I will see what to do. > > You should maybe wait a few weeks. It wouldn't make sense to first > call on developers to join an existing structure, and to then > immediately tear it down leaving them to pick up the pieces. > > > jer > Yes definitely. I wasn't planning on doing this overnight. -- Regards, Markos Chandras
Re: [gentoo-dev] alpha, ia64, ppc, ppc64, sparc developers, need your attention
On 06/01/2014 01:07 PM, Pacho Ramos wrote: > El dom, 01-06-2014 a las 13:00 +0100, Markos Chandras escribió: >> On 06/01/2014 12:33 PM, Pacho Ramos wrote: >>> El dom, 01-06-2014 a las 14:18 +0300, Samuli Suominen escribió: >>>> 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 >>>> >>> >>> This makes me wonder about the real status of some of this arches. >>> I know that now we will probably see how Agostino goes ahead and >>> does all the work (that is nice and I really welcome his work >>> trying to keep this arches in shape), but also makes me thing if >>> makes sense to keep this agostino-dependency for this arches more >>> and more time. What will occur if he is not around sometime? :/ >>> >>> >> >> We have been through the same discussion not so long ago and the >> result was to start dropping the ~m68k, s390 and sh to ~testing[1]. In >> the thread that started it all[2] there has been no resistance about >> dropping the keywords of these arches on $subject and here we are >> again discussing the problem. Here[3] you can see council's decision. >> I quote here just for fyi: >> >> "In summary: >> - m68k, s390, sh: will be dropped to unstable keywords globally. >> - alpha, ia64: Maintainers can remove older stable versions according >> to the "package-by-package" proposal. >> - sparc: No action. >> " >> So unless I make a mistake, you are free to start dropping alpha, ia64 >> to ~arch. For ppc,ppc64 and sparc it's probably best to resurrect the >> old thread and possible have add it to the agenda for the next meeting. >> >> [1] http://permalink.gmane.org/gmane.linux.gentoo.devel/88183 >> [2] http://www.gossamer-threads.com/lists/gentoo/dev/277054 >> [3] >> http://www.gentoo.org/proj/en/council/meeting-logs/20130917-summary.txt >> > > The problem arrives when even core components like udev takes so long to > be handled :/ (and situation would be much worse if Agostino doesn't > have time to make his mass stabilizations... well, each time I report a > stabilization bug that affects me I cross my fingers expecting ago has > enough time to handle them ;)) > > Relying on a single developer handling all architectures clearly does not scale and it is dangerous. We really need to be realistic and consider how many stable alpha/sparc/ia64/ppc* users are out there. In my mind the number is rather small, so does it really worth the effort trying to keep them stable hurting the remaining stable architectures and causing significant delays in publishing GLSAs? The reason I suggested to move the discussion back to the old thread is that some of these things have already been discussed in the past so I would like to avoid restarting the discussion from scratch. -- Regards, Markos Chandras
Re: [gentoo-dev] alpha, ia64, ppc, ppc64, sparc developers, need your attention
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 06/01/2014 12:33 PM, Pacho Ramos wrote: > El dom, 01-06-2014 a las 14:18 +0300, Samuli Suominen escribió: >> 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 >> > > This makes me wonder about the real status of some of this arches. > I know that now we will probably see how Agostino goes ahead and > does all the work (that is nice and I really welcome his work > trying to keep this arches in shape), but also makes me thing if > makes sense to keep this agostino-dependency for this arches more > and more time. What will occur if he is not around sometime? :/ > > We have been through the same discussion not so long ago and the result was to start dropping the ~m68k, s390 and sh to ~testing[1]. In the thread that started it all[2] there has been no resistance about dropping the keywords of these arches on $subject and here we are again discussing the problem. Here[3] you can see council's decision. I quote here just for fyi: "In summary: - - m68k, s390, sh: will be dropped to unstable keywords globally. - - alpha, ia64: Maintainers can remove older stable versions according to the "package-by-package" proposal. - - sparc: No action. " So unless I make a mistake, you are free to start dropping alpha, ia64 to ~arch. For ppc,ppc64 and sparc it's probably best to resurrect the old thread and possible have add it to the agenda for the next meeting. [1] http://permalink.gmane.org/gmane.linux.gentoo.devel/88183 [2] http://www.gossamer-threads.com/lists/gentoo/dev/277054 [3] http://www.gentoo.org/proj/en/council/meeting-logs/20130917-summary.txt - -- Regards, Markos Chandras -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQF8BAEBCgBmBQJTixXHXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGRDlGMzA4MUI2MzBDODQ4RDBGOEYxMjQx RjEwRUQ0QjgxREVCRjE5AAoJEB8Q7UuB3r8ZpzgH/04Mzd2eu24PG6Rk6pdzn0vE RT2FatinkXfan8r0zrEUf9jAGDdEWlpMxUlK2+10EBmBaNIDx3C66vdr1sK8mq61 TgKZkyUPuAkIAfOx4B8epJj1CSwx7DRnSuZTI1MWkd6sBdjqvGw4EN+QlzwfOzN9 UJ93OxGMvYHC9J6YQzq3kbJW9j4FoDTdQAIDPcKt+nppBTTHw5Qb1/Fum/ZjxpaI drgMtxLbzKpIPm9teUVtu0vYdgxVGmPezV1vJ5GWqQ42O9OqKq/tA1uvvOHYigDD GpL8Ze0hLGEEEp+16prISB/PKvZUjVb/WFblQeKoscq68YQneV8m7jLaJf+94C4= =uPfn -END PGP SIGNATURE-
Re: [gentoo-dev] Packages up for grabs
On 05/28/2014 09:32 PM, Dirkjan Ochtman wrote: > On Wed, May 28, 2014 at 10:28 PM, Markos Chandras wrote: >> Indeed. I only use a subset of the dev-tools packages so those that I >> don't use will be unmaintained in practice. I will add something to the >> Staffing Needs wiki page but feel free to join the herd if you have any >> interest in these packages. > > Perhaps it makes more sense to disband the herd and put all packages > except the ones you use up for grabs? > > Cheers, > > Dirkjan > I suppose so. Let me have a look and see how many packages belong to that herd and then I will see what to do. -- Regards, Markos Chandras
Re: [gentoo-dev] Packages up for grabs
On 03/17/2014 07:10 AM, Kacper Kowalik wrote: > > I'll also cease to watch over dev-tools herd. Hwoarang is all alone > there so I guess he'll appreciate all help that he can get. > Indeed. I only use a subset of the dev-tools packages so those that I don't use will be unmaintained in practice. I will add something to the Staffing Needs wiki page but feel free to join the herd if you have any interest in these packages. -- Regards, Markos Chandras
Re: [gentoo-dev] New category lxqt-base
Hi Ben, On 05/12/2014 07:06 AM, Ben de Groot wrote: > On 12 May 2014 03:28, Jauhien Piatlicki wrote: >> Hi all, >> >> LXQt 0.7.0 has been released [1]. >> >> As it is project different from LXDE > > That is debatable. LXQt is released by the merged LXDE and Razor-Qt > upstreams. One could say there are simply two expressions of LXDE now: > one in GTK+ and one in Qt. > >> and will be supported in parallel >> with it, it seems like a good idea add a new category lxqt-base. > > Personally I don't see a need for this. All the Qt-specific packages > are named accordingly, and should not confuse anyone installing > anything from the lxde-base category. I would like to see that latter > category re-used for this. > > But I know the maintainers of LXDE herd do not support this view, and > since at this point I don't have the time to maintain LXQt, I will > leave the decision up to you guys. It's only me who spoke on behalf of LXDE so far :( gtk2 is still alive, and lxde said that while it's still alive, the GTK lxde will still be supported. After all, lxde-base, as the name implies, is for lxde-related packages (maintained by lxde@). The new project is lxqt, which makes the lxde category slightly irrelevant. Since the lxde team has nothing to do with it, this will add more confusion. That's my opinion. Same thing for razor-qt apparently. Fortunately/unfortunately there is this tendency to use a distinct category (and set of maintainers/herd) for each DE. > >> compton-conf >> libqtxdg >> qt-gtk-engine >> libfm >> libsysstat >> obconf-qt >> pcmanfm-qt > > I think these packages could be placed in the relevant x11-* > categories, as they are perfectly usable in other environments as > well, tho for ease of maintenance you could stick them with the LXQt > packages. > +1 (pcmanfm-qt is already in the tree in x11-misc/, libfm too etc) Maybe it's possible to merge obconf and obconf-qt with a new 'qt' use flag. The less duplication we do, the less time we will need to spend maintaining the packages. -- Regards, Markos Chandras
Re: [gentoo-dev] Re: Banning modification of pkg-config files
On 05/12/2014 06:47 PM, Peter Stuge wrote: > Rich Freeman wrote: >>> Longterm, this makes it year after year more difficult to develop >>> software for "Linux". >> >> I'm with you here, but what is the solution? >> >> If we say we stick to upstream then we don't provide pkg-config files >> at all (in these cases). > > I think this is a sane default. > > >> Then when Debian does the other upstreams use them and then those >> packages break on Gentoo. > > I like Gentoo to stay very close to upstream. Gentoo should be close to upstream as much as possible and developers are actively encouraged during recruitment sessions to always try to upstream their patches. If you think a maintainer deviated from upstream for no good reason, well, I would like to think this is an exception instead of common practice. -- Regards, Markos Chandras
Re: [gentoo-dev] Re: Banning modification of pkg-config files
On 05/10/2014 07:31 AM, Alexandre Rostovtsev wrote: > On Sat, 2014-05-10 at 13:50 +0800, Ben de Groot wrote: >> On 10 May 2014 04:34, Markos Chandras wrote: >>> On 05/09/2014 09:32 PM, Tom Wijsman wrote: >>>> On Fri, 9 May 2014 16:15:58 -0400 >>>> Rich Freeman wrote: >>>> >>>>> I think fixing upstream is a no-brainer. >>>> >>>> It indeed is, this is the goal; you can force them in multiple ways, >>>> some of which can be found on the Lua bug and previous discussion(s). >>>> >>>>> The controversy only exists when upstream refuses to cooperate (which >>>>> seems to be the case when we're one of six distros patching it). If >>>>> there are other situations where we supply our own files please speak >>>>> up. >>>> >>>> Not that I know of; the refusal to cooperate is what this is all about, >>>> see my last response to hwoarang before this mail for a short summary. >>>> Though, I think that the Lua maintainers can explain all the details... >>>> >>>>> When the only issue is maintainer laziness I could see fixing that in >>>>> a different way... >>>> >>>> It has always been an issue; we could always use more manpower, ... >>>> >>>> https://wiki.gentoo.org/wiki/Contributing_to_Gentoo >>>> >>> >>> Well to me it feels that gentoo specific .pc files is a similar problem >>> to any other patch that affects upstream code in order to make the >>> package compatible with gentoo. Some people may consider downstream pc >>> files more dangerous because reverse deps are affected. But really, if >>> there is no other alternative, we shouldn't be treating this as a >>> special case. We patch upstream packages all the time after all >> >> Exactly. I don't understand why this is an issue at all. Obviously, >> if upstream does not ship a .pc file or ships a broken one, we try >> to work with upstream to get it fixed on their end. If they are >> uncooperative, we fix it on our end. > > Adding a pkgconfig file is a bit of a special case. Some distros have a > habit of renaming and creating .pc files for various libraries. Isn't this the same thing? If Debian creates/renames upstream pc files, and you use Debian as a development box, you have the same problem: Develop software which is not portable across distros. I have done very limited upstream development myself, but my opinion has always been that upstream developers who use Debian/Gentoo/Fedora/$FOOlinux as their dev environment shouldn't care about distro peculiarities. That's packagers' job, who are responsible to make the upstream software compatible with each distribution. But in > Gentoo, almost all pkgconfig files come from upstream with minimal > modification. So a .pc file that is specific to Gentoo is a rare > exception, and it could cause confusion for users who installed Gentoo > on their development machine and who wish to develop new portable > software. I don't see how this is a bad thing. This actually makes us look good in the sense that we stick to upstream code as much as possible. In an ideal world, all distros would be compatible :) -- Regards, Markos Chandras
Re: [gentoo-dev] Re: Banning modification of pkg-config files
On 05/09/2014 09:32 PM, Tom Wijsman wrote: > On Fri, 9 May 2014 16:15:58 -0400 > Rich Freeman wrote: > >> I think fixing upstream is a no-brainer. > > It indeed is, this is the goal; you can force them in multiple ways, > some of which can be found on the Lua bug and previous discussion(s). > >> The controversy only exists when upstream refuses to cooperate (which >> seems to be the case when we're one of six distros patching it). If >> there are other situations where we supply our own files please speak >> up. > > Not that I know of; the refusal to cooperate is what this is all about, > see my last response to hwoarang before this mail for a short summary. > Though, I think that the Lua maintainers can explain all the details... > >> When the only issue is maintainer laziness I could see fixing that in >> a different way... > > It has always been an issue; we could always use more manpower, ... > > https://wiki.gentoo.org/wiki/Contributing_to_Gentoo > Well to me it feels that gentoo specific .pc files is a similar problem to any other patch that affects upstream code in order to make the package compatible with gentoo. Some people may consider downstream pc files more dangerous because reverse deps are affected. But really, if there is no other alternative, we shouldn't be treating this as a special case. We patch upstream packages all the time after all -- Regards, Markos Chandras
Re: [gentoo-dev] Re: Banning modification of pkg-config files
On 05/09/2014 09:08 PM, Tom Wijsman wrote: > On Fri, 09 May 2014 20:57:29 +0100 > Markos Chandras wrote: > >> I was wondering, is there a good reason we keep our own pkgconfig >> files instead of communicating that to upstream and resolve that >> properly? > > Yes, when your "instead of ..." is not an option. Why not? If the package does not work out of the box then something is broken upstream? If it works for Debian but not for us then maybe we do something wrong? Otherwise, if having our own pc files (assuming there is no abuse here and we touch reverse deps only when really necessary) why is that a problem? I fail to understand the problem here. > >> What other distributions do? Or are we a special case and >> we need our own pc files? > > No, see https://bugs.gentoo.org/show_bug.cgi?id=509392#c23 which reads: > > "You do realize that out of five distros (Fedora, Debian, > Slackware, SuSe, Mandriva) I checked five ship a .pc file?" by mabi. > I am not talking about Lua here. It's a more general question. -- Regards, Markos Chandras
[gentoo-dev] Re: Banning modification of pkg-config files
Hi, (please avoid cross-list e-mails in the future if possible. Makes threading horrible) On 05/09/2014 07:21 PM, Matti Bickel wrote: > On 05/09/2014 04:07 PM, hasufell wrote: >> I ask the council to vote on banning pkg-config files that would >> be added or renamed downstream (at least this will prevent new >> violations). > > I want to repeat my stance from the linked bug that making this a > policy or calling on council to add more weight to existing devmanual > bits is adding red tape that from my point of view decreases the > quality of Gentoo. Asking me to remove the pkg-config file for lua-5.2 > or removing the modifications to 5.1 will kill support for packages > depending on these files existing. > [...] I was wondering, is there a good reason we keep our own pkgconfig files instead of communicating that to upstream and resolve that properly? What other distributions do? Or are we a special case and we need our own pc files? -- Regards, Markos Chandras
Re: [gentoo-dev] Drop net-analyzer/nagios-* to maintainer-needed
On 01/26/2014 01:57 AM, Chris Reffett wrote: > On 01/25/2014 12:22 PM, Andrew Hamilton wrote: >> On 1/25/2014 9:24 AM, Markos Chandras wrote: >>> On 11/10/2013 06:12 AM, Johann Schmitz wrote: >>>> - gpg control packet >>>>>> I already have too many packages to take care of but my company >>>>>> is using nagion on Gentoo so I take care of it. Although I >>>>>> wouldn't mind if somebody else helps with the packages as well. >>>> >>>> We use Nagios on many servers at work, so i can help out with these >>>> packages too. >>>> >>>>> ... git overlay for easier nondev contributions? :) >>>> >>>> A git repo would be useful if there are many changes to the code (e.g. >>>> plugins). From what i see in the buglist, most of the bugs are ebuild >>>> related (bumps, compile and installation issues). >>>> >>>> >>> (picking a random email from the thread) >>> >>> ping again. 3 months later, the list of bugs remain the same. Shall we >>> consider dropping it to maintainer-needed? >>> >> I would be happy to proxy-maintain these packages. >> >> Andrew Hamilton >> > I will proxy for him, will update metadata shortly. > > Chris Reffett > Thanks everyone! Please add proxy-maint and I will make sure Andrew's change will find their way in the tree whenever I have the time. -- Regards, Markos Chandras
Re: [gentoo-dev] Drop net-analyzer/nagios-* to maintainer-needed
On 11/10/2013 06:12 AM, Johann Schmitz wrote: > - gpg control packet >>> I already have too many packages to take care of but my company >>> is using nagion on Gentoo so I take care of it. Although I >>> wouldn't mind if somebody else helps with the packages as well. > > We use Nagios on many servers at work, so i can help out with these > packages too. > >> ... git overlay for easier nondev contributions? :) > > A git repo would be useful if there are many changes to the code (e.g. > plugins). From what i see in the buglist, most of the bugs are ebuild > related (bumps, compile and installation issues). > > (picking a random email from the thread) ping again. 3 months later, the list of bugs remain the same. Shall we consider dropping it to maintainer-needed? -- Regards, Markos Chandras
Re: [gentoo-dev] new profiles.desc header documenting profile/keyword policy
On 01/22/2014 06:58 AM, Mike Frysinger wrote: > On Monday 20 January 2014 12:26:13 William Hubbs wrote: >> On Mon, Jan 20, 2014 at 02:23:24AM -0500, Mike Frysinger wrote: >>> this has all been fairly ad-hoc in the past, so formalize it in the one >>> place that impacts everyone -- profiles.desc. >> >> If it is policy, shouldn't it go in the dev manual rather than in this >> file? > > maybe. devmanual doesn't talk about this file at all atm. > > or maybe i still have it in my head that devmanual.g.o is the ad-hoc > documentation and not a policy manual -- policy lives in the Gentoo Developer > Handbook. The handbook has not been updated for a good number of years therefore I am moving bits from it to devmanual whenever I have the time. -- Regards, Markos Chandras
Re: [gentoo-dev] [PATCH] eutils.eclass: add optfeature() function
On 01/25/2014 01:09 PM, Chris Reffett wrote: > On 01/25/2014 05:12 AM, Markos Chandras wrote: >> On 01/23/2014 04:48 PM, Michał Górny wrote: >>> Dnia 2014-01-23, o godz. 11:36:06 Chris Reffett >>> napisał(a): >>> >>>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 >>>> >>>> On 01/23/2014 11:28 AM, Michał Górny wrote: >>>>> Dnia 2014-01-23, o godz. 11:24:41 Chris Reffett >>>>> napisał(a): >>>>> >>>>>> After some discussion on good ways to communicate optional >>>>>> dependencies to users, I was shown the optfeature() >>>>>> function in net-misc/netctl. Gentoo contributor Andrew >>>>>> Hamilton and I came up with a cleaned up and expanded >>>>>> version of it, and I would like to add it to eutils.eclass >>>>>> to provide a standard way of notifying users of optional >>>>>> dependencies. The patch to eutils.eclass is attached. >>>>> >>>>> This was discussed already: >>>>> >>>>> http://thread.gmane.org/gmane.linux.gentoo.devel/72162 >>>>> >>>> First of all, this is a short patch for a function, not a full >>>> eclass. >>> >>> Ah, sorry, this changes *a lot*. Let's start the bikeshed again >>> then, whatever. >>> >> I haven't looked at the implementation, but I wonder if we need a >> function for such trivial stuff. Most maintainers deal with this >> problem using pkg_postinst() einfo/elog messages. Why do we need a >> dedicated function for that? Just for consistency reasons...? > > Consistency, and because it removes the need for a bunch of "if > has_version" lines, instead only displaying if you don't satisfy the > deps (and supports both "and" and "or" groupings for packages > satisfying the dep). This also stems from a complaint I've seen a lot > about how optional dep messages should only display if the requisite > package isn't installed, this makes that job a little simpler. But > mostly consistency, this gives us one nice function that we can > standardize on. > > Chris Reffett > I am fine with that especially given it's an opt-in feature. -- Regards, Markos Chandras
Re: [gentoo-dev] [PATCH] eutils.eclass: add optfeature() function
On 01/23/2014 04:48 PM, Michał Górny wrote: > Dnia 2014-01-23, o godz. 11:36:06 > Chris Reffett napisał(a): > >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> On 01/23/2014 11:28 AM, Michał Górny wrote: >>> Dnia 2014-01-23, o godz. 11:24:41 Chris Reffett >>> napisał(a): >>> >>>> After some discussion on good ways to communicate optional >>>> dependencies to users, I was shown the optfeature() function in >>>> net-misc/netctl. Gentoo contributor Andrew Hamilton and I came up >>>> with a cleaned up and expanded version of it, and I would like to >>>> add it to eutils.eclass to provide a standard way of notifying >>>> users of optional dependencies. The patch to eutils.eclass is >>>> attached. >>> >>> This was discussed already: >>> >>> http://thread.gmane.org/gmane.linux.gentoo.devel/72162 >>> >> First of all, this is a short patch for a function, not a full eclass. > > Ah, sorry, this changes *a lot*. Let's start the bikeshed again then, > whatever. > I haven't looked at the implementation, but I wonder if we need a function for such trivial stuff. Most maintainers deal with this problem using pkg_postinst() einfo/elog messages. Why do we need a dedicated function for that? Just for consistency reasons...? -- Regards, Markos Chandras
Re: [gentoo-dev] new profiles.desc header documenting profile/keyword policy
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 01/20/2014 06:54 PM, William Hubbs wrote: > On Mon, Jan 20, 2014 at 07:18:46PM +0100, Alexander Berntsen > wrote: >> -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 >> >> On 20/01/14 18:26, William Hubbs wrote: >>> On Mon, Jan 20, 2014 at 02:23:24AM -0500, Mike Frysinger >>> wrote: >>>> this has all been fairly ad-hoc in the past, so formalize it >>>> in the one place that impacts everyone -- profiles.desc. >>> If it is policy, shouldn't it go in the dev manual rather than >>> in this file? >> profiles.desc is installed on a user's system. Users don't read >> the dev manual. > > All policies are being documented in the dev manual, so I was just > saying that I think this should go there if it is going to be > official. > > Whether or not it is in a local file (on the users' system) isn't > relevant, developers should be familiar with the dev manual. > > William > There is no profiles.desc documentation in devmanual http://devmanual.gentoo.org/profiles/profiles.desc/index.html Discussing this in gentoo-dev makes no sense. Whoever wants the profiles.desc to be part of the devmanual document, please submit a patch. - -- Regards, Markos Chandras -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQJ8BAEBCgBmBQJS3XuZXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQzNTVDNDczOUYzRjJEMTRGNDRGMzU2RkMw OUJGNEY1NEMyQkE3RjNDAAoJEAm/T1TCun88kzUP/iWTI2ee92duV80WfQh3O9Lj Mkl4jFuTNmWqrMQfcO5Z3k+cSwTcxP5BI3IkmeD38obeGK+08hHBO16X/+6YQfWi MDgmx3LOJPxxPo9Bi/LJ7DnBI2dLF8TbSWNTa/xuvHjfFC554BlesgY/tbsulVT+ cKMujknXvt4WbkyWSkddHeCcgsVYS9iR+zp7JkKLuJyx+D4Kj3xIXkaaVt+V0fS9 5FsRI+dWRCTAtyUU7hJ2T7R0o8opcO850xai/921lwIwSmD+uN9vVovKBKUPtiqH SOEZkcpnCl9mLtdrmlUjsJFtosLHLAHDA9CADcnmCDxPFx4HEhSFWP35qGu17evk YPyE5hQXKIFsgXPJm8GCVKWJfw5IgZH9WCF+Go+nHgxcnNEGQJKp81N5g3JAVeFu Q2OjxEjqjy/LKdBDUUmOhiUs7yGL2YYVIzRnDy9O92Zb77PJqmlner+AWwHS9Oso w0+1S8Q9n0SmJ641Md6FboqSfhQbm1IUB7GoGm9iuF5KDzglpZdiB6jhr82ApOKt 61opKYQSBeaSeognYt7pK45Nwp1C3UUmgEDQtoxukegV+OlB/ocCFN8nLWgLj0Dw X/Me1iLUFXR/KF7TG+KQLSxJt6ftsAXmCXWQYKdfTEIEUmLsMpEjQWLhPYmZEMm4 6YdOvzo2V4Br8oo82pOQ =UwDV -END PGP SIGNATURE-
Re: [gentoo-dev] overlays.gentoo.org restoration & post-mortem
On 01/18/2014 12:59 PM, Alex Legler wrote: > On 18.01.2014 06:23, Kent Fredric wrote: >> >> On 18 January 2014 18:02, Robin H. Johnson > <mailto:robb...@gentoo.org>> wrote: >> >> - More people need to use the infra-status page to learn about the state >> of Gentoo services. >> >> >> >> A service middle layer like fastly or cloudflare which could link to the >> infra page would be good here perhaps, so when an outage occurred ( at >> least on the web side ) appropriate links to infra could be given. >> >> And the infra status page is not exactly obvious. Its not listed on the >> "gentoo sites" list on the top right, and perhaps it aught to be. >> > > Ironically, the only site that was already using the Tyrian theme (i.e. > the one with a top-right menu) was infra-status. > Now with overlays using the new theme too, I've updated the list. > > (NB: During the outage, I added a link to the site from the g.o frontpage.) > >> I haven't noticed there was a http://overlays.gentoo.org webpage. Looks awesome :) Thank you for the post-mortem analysis and for restoring the data -- Regards, Markos Chandras
Re: [gentoo-dev] RFC: Hosting daily gx86 squashfs images and deltas
On 01/17/2014 04:27 PM, Michał Górny wrote: > Hello, all. > > I'm using squashfs to hold my Gentoo repositories on all of my systems > for some time. As you probably know, this allows me to save space while > keeping portage fast. However, it makes updating the tree quite > burdensome and time-consuming. > > We're already hosting daily gx86 tarballs on our mirrors, and deltas > made using diffball. Those can be used with Zac's emerge-delta-webrsync > to get daily updates done with minimal network overhead. Sadly, it > takes the whole process even more time consuming :). > > Therefore, I'd like to suggest an alternative solution that could help > out Gentoo users that use squashfs for gx86 and would like to be able > to get daily updates fast and easy. > > The idea is to host -- along with the tarballs -- daily squashfs images > of gx86 in a chosen format. Additionally, the images would come with > deltas made using xdelta3 or a similar tool. Those deltas -- with > a slight download overhead -- would allow very fast updates > of the squashfs. > > Now some numbers. I did some tests 'converting' late gx86 daily > tarballs to squashfs. I've used squashfs 4.2 with LZO compression > since it's quite good and very fast. > > 96M portage-20140108.sqfs > 96M portage-20140109.sqfs > 96M portage-20140110.sqfs > 96M portage-20140111.sqfs > 96M portage-20140112.sqfs > 96M portage-20140113.sqfs > 97M portage-20140114.sqfs > 97M portage-20140115.sqfs > > For deltas, I've used xdelta3 with max compression (-9) and djw > secondary compression (it gave ~0.1M smaller files than fgk > and ~0.5M gain than with no secondary compression). > > 4,9M portage-20140108.sqfs-portage-20140109.sqfs.vcdiff.djw > 6,3M portage-20140109.sqfs-portage-20140110.sqfs.vcdiff.djw > 5,6M portage-20140110.sqfs-portage-20140111.sqfs.vcdiff.djw > 8,9M portage-20140111.sqfs-portage-20140112.sqfs.vcdiff.djw > 6,3M portage-20140112.sqfs-portage-20140113.sqfs.vcdiff.djw > 7,8M portage-20140113.sqfs-portage-20140114.sqfs.vcdiff.djw > 8,5M portage-20140114.sqfs-portage-20140115.sqfs.vcdiff.djw > > As you can see, the deltas are quite large compared to the actual > changes. However, we could have expected that since we're diffing > a compressed filesystem. What's important, however, is that applying > it takes ~2.5 second on my 2 GHz Athlon64. > > So, even with the extra download time, the update is much faster > than recreating the squashfs. And unlike some types of unionfs, > it doesn't come with extra runtime slowdown. > > What do you think? > +1 I like the idea -- Regards, Markos Chandras
Re: [gentoo-dev] Re: About pam herd status
On 01/11/2014 11:07 AM, Diego Elio Pettenò wrote: > If we limit it to the virtual, pam and pambase, I'm happy to stick > maintaining them, the others I don't use, which is why I don't care about > them as much. > > Diego Elio Pettenò — Flameeyes > flamee...@flameeyes.eu — http://blog.flameeyes.eu/ > Fine by me. We will drop the rest to m-n -- Regards, Markos Chandras
Re: [gentoo-dev] Re: About pam herd status
On 01/10/2014 11:14 PM, Diego Elio Pettenò wrote: > On 10 January 2014 22:20, Mike Frysinger wrote: > >> how would moving it to base-system make any difference ? people doing it >> wrong >> wouldn't really care which herd pam itself is owned by. >> > > I'm not saying it makes a difference, sorry I didn't make it clear. > > > Diego Elio Pettenò — Flameeyes > flamee...@flameeyes.eu — http://blog.flameeyes.eu/ > I only suggested that as part of our usual 'drop-dead-teams' process in the retirement team. So in this case, either a 'parent' herd needs to inherit the packages or simply drop them to maintainer-needed -- Regards, Markos Chandras
Re: [gentoo-dev] Re: About pam herd status
On 01/09/2014 08:20 PM, Mike Frysinger wrote: > On Monday 09 December 2013 16:32:09 Markos Chandras wrote: >> On 12/09/2013 02:21 PM, Diego Elio Pettenò wrote: >>> On Mon, Dec 9, 2013 at 2:20 PM, Pacho Ramos wrote: >>>> Hello >>>> >>>> Is pam team still active? I wonder about this as, recently, we have >>>> needed to go ahead and fix some bugs related, for example, with pambase >>>> and pam_ssh >>>> >>>> Thanks for the info :) >> >> So I guess it's time to call for maintainers or we should consider >> merging this herd with another one (base?) to avoid unattended bugs for >> a long time. > > well, the sep herd was kind of by design ... i didn't want it cluttering up > base-system@ and it is super convenient to abdicate all PAM decisions to a > single herd. > -mike > I understand that but if nobody is tracking pam@ then what's the point? -- Regards, Markos Chandras
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-sound/umurmur: metadata.xml ChangeLog
On 12/28/2013 03:44 PM, Andreas K. Huettel wrote: > >>>> That's what I call "ignoring the rest". You do not communicate, >>>> you do not file bugs, you just go and do stuff. >>> >>> That kind of behaviour is what the QA team is supposed to be able >>> to address. You should raise this issue with them rather than >>> accusing each other on the lists. >> >> I completely agree with this. I feel that this thread is a sign that >> there is a problem on how the new QA communicates problems with the >> developers that cause them. I read the entire thread and I still don't >> think there is an agreement on who broke the tree and why. Would a >> private discussion be better before going publicly with accusations? > > Introducing repoman warnings deliberately is wrong. Point. > QA can do trivial fixes. Point. > > None of these two points needs any discussion. > Certainly, but look at the size and contents of this thread and now tell me if what you said is clear to everyone. It certainly isn't to the person who caused the problem so what I am saying is that maybe it's better first to communicate the problem with him before starting a public heated discussion. -- Regards, Markos Chandras
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-sound/umurmur: metadata.xml ChangeLog
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 12/26/2013 01:27 PM, Ciaran McCreesh wrote: > On Thu, 26 Dec 2013 14:25:04 +0100 hasufell > wrote: >> That is funny that you mention "cleaning up". I remember last >> time when you broke 8 ebuilds at once because you just trusted >> your outdated repoman warning to be correct. You didn't even file >> a BUG for me, you did not contact me and after I told you that it >> was wrong and that you should revert it, you didn't. >> >> That's what I call "ignoring the rest". You do not communicate, >> you do not file bugs, you just go and do stuff. > > That kind of behaviour is what the QA team is supposed to be able > to address. You should raise this issue with them rather than > accusing each other on the lists. > I completely agree with this. I feel that this thread is a sign that there is a problem on how the new QA communicates problems with the developers that cause them. I read the entire thread and I still don't think there is an agreement on who broke the tree and why. Would a private discussion be better before going publicly with accusations? - -- Regards, Markos Chandras -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQJ8BAEBCgBmBQJSvuotXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQzNTVDNDczOUYzRjJEMTRGNDRGMzU2RkMw OUJGNEY1NEMyQkE3RjNDAAoJEAm/T1TCun88qckQAL1Xur8yfYQ76jV2vqp47KYv mxE9sEOdew7yOBXkesrw3mU5q3/kVJg9QS4CqR/epWp6t/6LrOZkGPEB2vzE46Eo cIoC+K0U/3eQQVCHsazVM2mMMLt7d0om8l35msN6rQD33lbLe+gT05aYG+u0lpW4 k/PPnXpf9EnNiXUx/zolBYM5d0KLppeXNPhqigWQCnfxu6pOyR8STVH96zUMR5f3 buQvnBTYGwaG9h2JBeIN5ZCz6B+0jLPJH91yBxCVo66ejm01DCkVuJLLO2UPYeQY P0nE31XtpUMQrgxrpoQPQ7JJIDjELCUjHEKRd8YwRpzh1ltDEMM64tBkg+Edz6/w zMT7+tG0e1qbnafA7lXCXOb2F8DpUMgvveCvfHN2zcTlg2GWvKDWvvaDzkLOyaSH EcDen1yq9t+EyBksdLyhbM2+YF4oFq0ne8ofh2cqS1HjYFh7JLForS1EdSQReC/S 0H6yrHNd4FjqLqzFJ812iLzHOyQJ2AAQRGDqPF9kwV7riXYy5VcMlMffHW1OZv8L gMr25OZtnJv9iOIW6VzCYpv6QoDzpPInqMRE33r4sNJR2/urb6w3G66Yvyt+zSax qwkL5eLUOB1awO/XxoihTN3NQNCqFZix7CTfKd3n7OvxEXFJHCtwVEYTUb9updWc O44aMMoxNz2Vl2LTCOYo =VsAA -END PGP SIGNATURE-
Re: [gentoo-dev] Commit into profiles fails
On 12/20/2013 07:50 PM, Johannes Huber wrote: > Am Freitag, 20. Dezember 2013, 20:19:08 schrieb Alon Bar-Lev: >> Hi, >> >> Long time since I done this... maybe something had been changed. >> >> $ cvs commit -m "thirdpartymirrors: fixup gnupg mirros, bug#494842, thanks >> to Ben Kohler" >> cvs commit: cannot exec /var/cvsroot/CVSROOT/cvslogdate: Permission denied >> cvs commit: cannot exec /var/cvsroot/CVSROOT/checkgroup.pl: Permission >> denied >> cvs commit: Pre-commit check failed >> cvs [commit aborted]: correct above errors first! >> >> It looks like something is wrong in remote, but I see people succeed in >> committing today... >> >> What's wrong? >> >> Thanks, >> Alon > > Hi Alon, > > its not only you. Seems something is broken on infra side or its the pre- > christmas present, the git migration. > > Greetings > maybe worth opening a bug (assuming there is no one already) or talk to #gentoo-infra? -- Regards, Markos Chandras
Re: [gentoo-dev] Recommend cronie instead of vixie-cron in handbook?
On 12/13/2013 04:53 PM, Brian Dolbec wrote: > On Fri, 2013-12-13 at 17:08 +0100, Peter Stuge wrote: >> Sergey Popov wrote: >>>>>> Last time I checked, vixie-cron upstream was died >>>>> >>>>> If vixie-cron upstream is dead as you say >>>> >>>> Define dead? >>> >>> Bugs are not fixed for a very long time, no answers on private >>> e-mails or in maillists. >> >> Define very long time? >> >> >> //Peter > > Please,... just look at the Changelog! > > quote, first added to the tree: *vixie-cron-4.1 (27 Aug 2004) > > and it has been patched ever since, picking up patches from other > distros, etc., fixing bugs,... > > Currently at revision 14. > > Plus I don't recall that it be tree-cleaned in this thread, just to > change the default in the install manual to one that is being developed. > Can we please stop this derailed part of this thread? Please do not let Peter render another thread useless. -- Regards, Markos Chandras
Re: [gentoo-dev] rfc: renaming "rc" binary in OpenRC
On 12/11/2013 08:56 PM, Paul Tagliamonte wrote: > > [I'm not the OpenRC maintainer, I'm only on gentoo-devel because I'm > generally interested, and I saw this, I'm not speaking for zigo or > anything here.] > > On Wed, Dec 11, 2013 at 03:47:57PM -0500, Chris Reffett wrote: >>The idea of running a sed on inittab in an ebuild, no matter what the >>context, terrifies me. Perhaps we can ease this in slowly by renaming rc >>-> openrc and symlinking rc -> openrc and making a release with that >>change concurrent with a news item? Or even just do that in the ebuild >>rather than in the actual sources. I don't think Debian will keel over and >>die if it takes a little extra time for the change to go through, and it >>beats a ton of broken systems. >> >>Chris Reffett > > Hi, Gentoo (and hello world), > > I'm breaking my streak of lurking to comment generally on the Debian > procedure here. > > I'm sure the Debian folks would be happy to strip the symlink from the > deb over having to patch OpenRC's rc binary => openrc against the > upstream source. > > Shipping /usr/bin/rc => /usr/bin/openrc would be totally cool for > Debian, I believe. Hopefully the OpenRC team will come in and correct me > if I'm wrong :) > > Fondly, > Paul > If that's the case then I see no reason to go through the migration path for users :) The symlink thing can be done immediately. I am wondering, wouldn't Debian be able to rename "rc" to "openrc" in their openrc package just before merging it to the read filesystem (I assume Debian also builds and installs in sandbox first?)? In this case we will not have to touch openrc (or the ebuild) at all. -- Regards, Markos Chandras
Re: [gentoo-dev] rfc: renaming "rc" binary in OpenRC
On 12/11/2013 08:47 PM, Chris Reffett wrote: > On 12/11/2013 3:41 PM, William Hubbs wrote: >> All, >> >> We got a request from Debian to rename the "rc" binary of OpenRC due to >> a naming conflict they have. They have a port of the at&t plan 9 shell, >> which has a binary named "rc" as well[1]. >> >> My thought is to rename our "rc" to "openrc", since that would be >> unique. >> >> I know at least one thing that will break is everyone's inittab, so >> should I sed their inittab in our live ebuild or expect them to fix it >> and give a warning? I know that once OpenRC with this change is >> released, it will need to probably be p.masked until there is a new >> release of sysvinit that updates the inittab. >> >> I'm not sure what else will break. >> >> Does anyone have any ideas wrt other things to look for, or should I >> make the changes upstream and have people let us know what >> else breaks? >> >> William >> >> [1] https://bugs.gentoo.org/show_bug.cgi?id=493958 > The idea of running a sed on inittab in an ebuild, no matter what the > context, terrifies me. Perhaps we can ease this in slowly by renaming rc > -> openrc and symlinking rc -> openrc and making a release with that > change concurrent with a news item? Or even just do that in the ebuild > rather than in the actual sources. I don't think Debian will keel over > and die if it takes a little extra time for the change to go through, > and it beats a ton of broken systems. > > Chris Reffett > > +1 The ebuild can grep the inittab and it if finds an "rc" there, just print a huge warning telling the user to migrate || die. -- Regards, Markos Chandras
Re: [gentoo-dev] Recommend cronie instead of vixie-cron in handbook?
On 12/10/2013 08:55 PM, Pacho Ramos wrote: > https://bugs.gentoo.org/show_bug.cgi?id=197625#c14 > > This has reminded me that maybe we should switch to cronie from > vixie-cron as default and recommended cron provider in Handbook. Last > time I checked, vixie-cron upstream was died while cronie forked it > fixing some bugs :/ > > What do you think? > > > > If vixie-cron upstream is dead as you say, then I agree we should move away from it. -- Regards, Markos Chandras
Re: [gentoo-dev] Re: About pam herd status
On 12/09/2013 02:21 PM, Diego Elio Pettenò wrote: > I stopped caring about pambase when people decided to break it. > > I'm still officially pam herd as maintainer of Linux-PAM, pam_ssh I don't > use and care very little about. > > > Diego Elio Pettenò — Flameeyes > flamee...@flameeyes.eu — http://blog.flameeyes.eu/ > > > On Mon, Dec 9, 2013 at 2:20 PM, Pacho Ramos wrote: > >> Hello >> >> Is pam team still active? I wonder about this as, recently, we have >> needed to go ahead and fix some bugs related, for example, with pambase >> and pam_ssh >> >> Thanks for the info :) >> >> > So I guess it's time to call for maintainers or we should consider merging this herd with another one (base?) to avoid unattended bugs for a long time. -- Regards, Markos Chandras
Re: [gentoo-dev] Drop net-analyzer/nagios-* to maintainer-needed
On 11/10/2013 10:27 PM, Matthew Thode wrote: > On 11/09/2013 09:20 AM, Diego Elio Pettenò wrote: >> Seems like I forgot to select reply all earlier. >> >> I'm going to look into that next week. I failed to resetup my monitoring >> after I left my previous customer and I've reinstalled icinga just this >> week. >> >> I don't understand people's insistence with a single product herd given we >> don't have enough manpower yet and I don't want to have an explosion of >> aliases I need to subscribe to, the spam is enough as it is. >> > If you are interested in co-maintaining with me I'd be interested in > helping with the plugins (nrpe/nsca agent/plugins and pnp4nagios). I > already do the icinga packages but I feel like I am starting to spread > myself thing with openstack and everything :( > (picking up a random e-mail from the thread) 2 weeks later and the number bugs is pretty much the same. I suggest whoever is interested in helping out to add himself to metadata given no coordination has happened so far. -- Regards, Markos Chandras
[gentoo-dev] Re: [gentoo-commits] gentoo commit in xml/htdocs/proj/en/bug-cleaners: index.xml
On 11/16/2013 10:27 AM, Tom Wijsman (tomwij) wrote: > tomwij 13/11/16 10:27:43 > > Added:index.xml > Log: > Initial project directory for the Bug Cleaners project. > > Revision ChangesPath > 1.1 xml/htdocs/proj/en/bug-cleaners/index.xml > > file : > http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/bug-cleaners/index.xml?rev=1.1&view=markup > plain: > http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/bug-cleaners/index.xml?rev=1.1&content-type=text/plain > > Index: index.xml > === > > > > > > redirect="http://wiki.gentoo.org/wiki/Project:Bug_Cleaners";> > Bug Cleaners > Gentoo Bug Cleaners > The Gentoo Bug Cleaners project aims to clean up the oldest bugs > in Bugzilla. > Our goal is twofold, the main purpose of this project is > to close bugs on Bugzilla that do no longer apply due to versions and/or > packages that are no longer present in the Portage tree; as a side effect, it > also tries to look for solutions to the oldest bugs. For those that still > have use, it attempts to inform the persons involved in the bug that the bug > is still open if the bug is important; inviting them to take a decision on > it. > > > > > I think this is unnecessary. Infra requested all new projects to be in the Wiki so I don't think that you are supposed to add a proj/en page anymore just so you can redirect it to the Wiki -- Regards, Markos Chandras
[gentoo-dev] Drop net-analyzer/nagios-* to maintainer-needed
Hi, I see nobody seems to take care of nagios packages anymore. There are numerous bugs (and many of them are pending version bumps). Is the sysadmin@ herd still interested in this package? If not, could you please consider moving it to maintainer-needed@? Maybe users are interested in working with proxy-maintainers to bring this package up to date. https://bugs.gentoo.org/buglist.cgi?quicksearch=net-analyzer%2Fnagios -- Regards, Markos Chandras - Gentoo Linux Developer http://dev.gentoo.org/~hwoarang
Re: [gentoo-dev] Suggestion: support the Dev team with system resources
On 11/07/2013 02:48 PM, Matthew Thode wrote: > Rackspace (where I work) currently has a developer discount program. I > think we also host some open source stuff for various projects. Right > now you can try to use http://developer.rackspace.com/ but if we want to > make this more official I can ask around. Let me know if we want this > as a more official thing (rackspace donating compute resources), no > guarantees though :D. > To be honest, I would like Gentoo infra to come up with a solution sometime... Last time (a year ago) i asked them about this, they said they have a cluster/big box for this purpose but they just didn't have the time to deploy it properly or something. Not everyone can afford paid solutions when it comes to contributing to free software -- Regards, Markos Chandras
Re: [gentoo-dev] Last rites: app-arch/xarchiver
On 11/02/2013 07:12 PM, yac wrote: > On Sat, 02 Nov 2013 17:57:34 + > Markos Chandras wrote: > >> On 11/02/2013 05:55 PM, yac wrote: >>> Hi, >>> >>> I don't think that upstream deciding to rewrite a package is good >>> enough reason to tree clean the package. Have you done this >>> with eg. bind package which is constantly rewritten and constantly >>> have security issues? >>> >>> The same goes for closing bugs until the versions are >>> removed from portage (either because version deprecation or >>> treeclean with proper reason) as users may find those informational. >>> >> >> Ok let me clarify this again >> >> 1) The original code of the package is gone since upstream started >> from scratch. > > What do you mean by gone? I still can `ebuild xarchiver* fetch` the > sources. > > Otherwise this is not a reason to treeclean the package. > >> 2) It has no maintainer. > > Not a reason for treecleaning. > >> 3) It has open bugs and upstream will never fix them and there is no >> maintainer to patch the code to fix it properly. > > In bgo[1] there are two bugs open. Upstream [2] seems to have more bugs > but they also seem to be mostly new features or corner cases. > > There already was discussion on treecleaning bug[3] where you claim the > package is "broken" while several users explain it is broken > *partialy*. Eg. c30 says only 2 formats doesn't work. > > c21 claims it always crashes on passwords, however upstream bug reports > indicates it's also true for only some formats. > > c6 indicates xarchiver will break on unrar-5 when it will go stable but > it still is not stable, is it? Given the way this issue is > communicated, I have to ask - Is it even true? The rar major version > seems to be related to rar format version rather then ABI/API. > > Even if xarchiver breaks on unrar-5, I see many other packages > depending on unrar, do you know these will not break and possibility of > having both unrar4 and 5 will not be just due xarchiver? > >> So per treecleaner policy the package will be removed. >> >> Or have you just volunteered to become maintainer and fix the bugs? >> > > [1] > https://bugs.gentoo.org/buglist.cgi?quicksearch=xarchiver > [2] https://bugzilla.xfce.org/buglist.cgi?quicksearch=xarchiver > [3] https://bugs.gentoo.org/show_bug.cgi?id=483588 > I will not discuss this further. If you want to save it, step up and maintain it. -- Regards, Markos Chandras
Re: [gentoo-dev] Last rites: app-arch/xarchiver
On 11/02/2013 05:55 PM, yac wrote: > Hi, > > I don't think that upstream deciding to rewrite a package is good > enough reason to tree clean the package. Have you done this > with eg. bind package which is constantly rewritten and constantly have > security issues? > > The same goes for closing bugs until the versions are > removed from portage (either because version deprecation or treeclean > with proper reason) as users may find those informational. > Ok let me clarify this again 1) The original code of the package is gone since upstream started from scratch. 2) It has no maintainer. 3) It has open bugs and upstream will never fix them and there is no maintainer to patch the code to fix it properly. So per treecleaner policy the package will be removed. Or have you just volunteered to become maintainer and fix the bugs? -- Regards, Markos Chandras
[gentoo-dev] Last rites: app-arch/xarchiver
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 # Markos Chandras (02 Nov 2013) # On behalf of Treecleaners # Upstream started a complete rewrite of the package # meaning that existing bugs will not be fixed by future # version bumps of the existing code. # It is unclear when/if the new code will be released any time # soon so masked for removal in 30 days. # The package can be re-introduced later on if the new # maintainer feels it is stable enough. # See #483588 and #473692 app-arch/xarchiver - -- Regards, Markos Chandras -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQJ8BAEBCgBmBQJSdSV1XxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQzNTVDNDczOUYzRjJEMTRGNDRGMzU2RkMw OUJGNEY1NEMyQkE3RjNDAAoJEAm/T1TCun88t6UP/RnVftEt5nvWMGTAZeiTVBy+ rc/KdpW4tT7xNlkfoQvtmcBjx7UPXePOUcmRVODaOK/F5R5gCijnwqoENP2r0xVV KX8kmZL2R1oX98p9hRssiZ3a6wiZbvGsy8P/voOvQhKJCu0i1xl/Iio/5ZfyTaQT zFtcMC8nn0LIFH20lQft5ukFQTQdoktb8XL70dfjSU8iCu/lrBrIU19cdOH5psev IEzu39t732aqNiEoXJb6r8l9kpBeeunRQ7pDP3GC8RunME/MxHuNELJPqCUFC4F7 iRJZd6fFyY3pSObhXA6FtEtLPx0xSX+FEOKE/OGOaDnrQ3IMm9nwk5/zLjGZCXhi spW7z970Kv6f9VzUEQmLGBDA8pgRkZo2bfvd4hMjeK/Szzr/v+FU0RjKrYwV0Wxo ncXWFmL/MwWhXo6Nc8LjN+4BDUlZKDNMgf30R+g3LxhCLmX98fHFbVjGvL4nrGkF z/zqVtnk4led1ipGQFQweseaNYbQrkq4nJbgATjLAOcQwsrpZEj3PGs89uI/Eo3f 830YGeleoIZkd1pf1QwVoHdLxbBlIKlVua/PgXtfQLTEqdgxrY5Se9Mqf25xqwfx KejCOHDWWWYFTlfkodKkiM3qsvzwORM0+b6JA2jxw047yeXoDTb1y2q0X0oA+kjT Ri+2zibvoDZJksjRz4xR =Xd15 -END PGP SIGNATURE-
Re: [gentoo-dev] official games repository
On 10/22/2013 09:48 AM, Sergey Popov wrote: > 20.10.2013 18:31, hasufell пишет: >> Gamerlay is not related to the games team > > I am sorry, but it is games team not related to gamerlay. No offense, > but gamerlay guys sometims just do their job. > > So, MAKE it related to Games team and fix stuff, considered broken. > >> gamerlay which is a project that has failed. > > Please, do not throw such sentences without objective clarification, thanks. > >> I have zero interest to work on gamerlay. > > So, this is your personal attitude to be against of gamerlay. We have > got this, thanks. > Again, lets stop here please. I think we proved that the Gentoo dev community as a whole is not hostile to user community overlays/projects. -- Regards, Markos Chandras
Re: [gentoo-dev] official games repository
On 10/22/2013 09:54 AM, Sergey Popov wrote: > 20.10.2013 20:12, hasufell пишет: >> This thread is derailed and I have no further interest in discussing here. >> > > And again, no offense, but it is not the first time when you are jumped, > said, "Everything in X is wrong!" and then said "I have lost interest". > It is very "mature" position to propose enhancement and then - hides, do > not you think? > > Sorry if i am saying harsh words, just talking how it looks like from > side view. > No need to escallate this further. People can form their own opinions on the subject. -- Regards, Markos Chandras
Re: [gentoo-dev] Re: [Bug 488318] media-video/mpv[luajit] - Keyword request on alpha, arm, ppc, ppc64, sparc
On 10/21/2013 02:32 PM, Jeroen Roovers wrote: > On Sun, 20 Oct 2013 12:41:02 +0100 > Markos Chandras wrote: > >> No I never meant broken depgraphs. Well for broken deps, repoman does >> not let you commit. If you use --force to workaround broken deps, >> well, then you get what you deserve. > > No, apparently tomwij can get not only away with this (and apparently > others as well on a regular basis). Not just that: he gets to write a > lengthy "apology" that merely blames others / documentation / common > sense, and then proceeds to call me "unprofessional" for pointing out > in public the several mistakes he made. I feel very much that he's not > getting it (what he deserves). > > > jer > Lets calm down a little bit. Our documentation is nowhere near perfect and common sense is not always obvious (we have hundreds of people claiming that the opposite). Instead of arguing in public how about we contribute some patches in devmanual to avoid similar problems in the future? -- Regards, Markos Chandras
Re: [gentoo-dev] official games repository
On 10/20/2013 05:04 PM, Mike Gilbert wrote: > On Sun, Oct 20, 2013 at 11:40 AM, hasufell wrote: >> On 10/20/2013 05:26 PM, Markos Chandras wrote: >>> On 10/20/2013 04:22 PM, hasufell wrote: >>>> On 10/20/2013 04:40 PM, Markos Chandras wrote: >>>>> On 10/20/2013 03:31 PM, hasufell wrote: >>>>>> On 10/20/2013 04:13 PM, Markos Chandras wrote: >>>>>>> On 10/20/2013 01:26 PM, Мисбах-Соловьёв Вадим wrote: >>>>>>>>> * not related to the games team * no review whatsoever >>>>>>>>> from any dev on ebuilds that get pushed there >>>>>>>> >>>>>>>> It is easy-fixable. It is enough to gentoo-games team to >>>>>>>> back to work on it together with community. >>>>>>>> >>>>>>>>> * low quality >>>>>>>> low quality of what? ebuilds? I bet, it is many >>>>>>>> lower-quality ebuilds in the tree. Or do you mean low >>>>>>>> quality of something else? Anyway, it is fixable too. >>>>>>>> Just let's start work on it. >>>>>>>> >>>>>>> I agree. >>>>>> >>>>>>> It's better to work with the user community and join >>>>>>> efforts than having yet-another-shiny overlay. >>>>>> >>>>>> >>>>>> Gamerlay is not related to the games team and this thread is >>>>>> not about gamerlay which is a project that has failed. I have >>>>>> zero interest to work on gamerlay. It would have to start >>>>>> with removing direct commit access of users. >>>> >>>>> This is not a great way to invite more users to participate. >>>>> If you intend to make the game overlay and team a >>>>> developer-only thing you are doing a great work. >>>> >>>> >>>> I am not sure if you have read my list of arguments in the first >>>> post. Sunrise is based on that very concept. No user has direct >>>> commit access to the reviewed repository, for good reason (not >>>> sure what you mean with "developer-only"). >>>> >>> >>> I was mainly referring to your way to exluding this community which >>> is already working on the gaming side of Gentoo. You shouldn't >>> ignore active contributors because their ebuilds happen to be of >>> lower quality. >> >> >> Thanks for your opinion on this. It's nice to see that my efforts of >> (unrequested) reviews on bugzilla, overlays, forums and sunrise makes >> you say that I ignore contributors. Especially those contributors who >> respond to or even request reviews (many don't even respond to >> unrequested reviews). >> >> Some people from gamerlay have made clear that they are not really >> interested in reviews, yet you want me to waste time on that? >> >> I don't think this discussion leads anywhere. > > He's just warning you not to ignore the existing community in your > attempt to create a new community project. It is good advice; take it > that way instead of responding to it as negative criticism. > > I think it might be a tough sell to get existing gamerlay contributors > to switch to this new "official" contribution process. If you started > working within that community, you may have better luck persuading > people to get on board. If you have no interest in doing that, just be > aware that you are excluding a significant base of contributors. > Thanks for explaining what I was trying to say :) Seems like there are people who understand what I am saying and I am not talking nonsense :) -- Regards, Markos Chandras
Re: [gentoo-dev] official games repository
On 10/20/2013 04:40 PM, hasufell wrote: > > Some people from gamerlay have made clear that they are not really > interested in reviews, yet you want me to waste time on that? A guy asked you why you don't work in the gamerlay. All you said was that gamerlay was a failed attemp and that you have zero interest in working in it. No futher explanations. And now, finally, after 4 e-mails you decided to tell us that you have actually talked to them and they are not interested in ebuild reviewing. Ok then... > > I don't think this discussion leads anywhere. > I am not sure why you even open that thread. Your e-mail basically requests the games@ team opinion. Again, if you didn't want others to comment on this, you shouldn't have CC'd gentoo-dev. -- Regards, Markos Chandras
Re: [gentoo-dev] official games repository
On 10/20/2013 04:22 PM, hasufell wrote: > On 10/20/2013 04:40 PM, Markos Chandras wrote: >> On 10/20/2013 03:31 PM, hasufell wrote: >>> On 10/20/2013 04:13 PM, Markos Chandras wrote: >>>> On 10/20/2013 01:26 PM, Мисбах-Соловьёв Вадим wrote: >>>>>> * not related to the games team * no review whatsoever from >>>>>> any dev on ebuilds that get pushed there >>>>> >>>>> It is easy-fixable. It is enough to gentoo-games team to back >>>>> to work on it together with community. >>>>> >>>>>> * low quality >>>>> low quality of what? ebuilds? I bet, it is many >>>>> lower-quality ebuilds in the tree. Or do you mean low quality >>>>> of something else? Anyway, it is fixable too. Just let's >>>>> start work on it. >>>>> >>>> I agree. >>> >>>> It's better to work with the user community and join efforts >>>> than having yet-another-shiny overlay. >>> >>> >>> Gamerlay is not related to the games team and this thread is not >>> about gamerlay which is a project that has failed. I have zero >>> interest to work on gamerlay. It would have to start with >>> removing direct commit access of users. > >> This is not a great way to invite more users to participate. If >> you intend to make the game overlay and team a developer-only thing >> you are doing a great work. > > > I am not sure if you have read my list of arguments in the first post. > Sunrise is based on that very concept. No user has direct commit > access to the reviewed repository, for good reason (not sure what you > mean with "developer-only"). > I was mainly referring to your way to exluding this community which is already working on the gaming side of Gentoo. You shouldn't ignore active contributors because their ebuilds happen to be of lower quality. It would be nice if you could try to actually talk to them and find a way to make them contribute to your new overlay otherwise you may end up actually be the only maintainer of it. -- Regards, Markos Chandras
Re: [gentoo-dev] Packages up for grabs
On 10/01/2013 04:52 PM, Chí-Thanh Christopher Nguyễn wrote: > Due to voip lack of active maintainers: > > Not co-maintained with anyone else: > > dev-libs/jrtplib > media-libs/libj2k > media-libs/libmimic > net-libs/iax > net-libs/sofia-sip > net-misc/asterisk-rate_engine > net-misc/asterisk-spandsp_codec_g726 > net-misc/astmanproxy > net-misc/ser > net-misc/sipsak > net-misc/sjphone > net-voip/gnugk > net-voip/openmcu > > Co-maintained with neurogeek: > > net-libs/opal > net-libs/ptlib > net-voip/ekiga > > > Co-maintained with pinkbyte: > > dev-libs/jthread > > > Co-maintained with tgurr: > > media-sound/mumble > media-sound/murmur > > > Co-maintained with hasufell and polynomial-c: > > media-sound/umurmur > > > Co-maintained with gnome and/or gstreamer herds: > > dev-python/telepathy-python > media-plugins/gst-plugins-libnice > net-im/telepathy-connection-managers > net-libs/farsight2 > net-libs/farstream > net-libs/libnice > net-libs/telepathy-farsight > net-libs/telepathy-farstream > net-libs/telepathy-glib > net-voip/telepathy-gabble > net-voip/telepathy-haze > net-voip/telepathy-rakia > > The retirement team will likely proceed with removal and reassigning of the packages and bugs in a week. If anyone disagrees and is willing to join the herd and handle all that packages please do so ASAP. Tony (Chainsaw) will take care of the following asterisk-related packages: dev-libs/ilbc-rfc3951 media-libs/spandsp net-libs/iax net-libs/libpri net-libs/libsrtp net-libs/ortp net-libs/osptoolkit net-misc/asterisk-core-sounds net-misc/asterisk-extra-sounds net-misc/asterisk-g729 net-misc/asterisk-moh-opsound net-misc/asterisk-rate_engine net-misc/asterisk-spandsp_codec_g726 net-misc/asterisk net-misc/astmanproxy net-misc/dahdi-tools net-misc/dahdi net-misc/libss7 net-misc/openr2 net-misc/sipsak The rest will end up maintainer-needed, so first comes first served :) -- Regards, Markos Chandras - Gentoo Linux Developer http://dev.gentoo.org/~hwoarang
Re: [gentoo-dev] multilib-minimal.eclass: change in behavior
On 10/20/2013 02:45 PM, hasufell wrote: > - gpg control packet > After doing some tests we will probably apply this patch from bug 483304. "probably"? Then this does not belong to the announcement list if no final decisions have been made yet -- Regards, Markos Chandras - Gentoo Linux Developer http://dev.gentoo.org/~hwoarang
Re: [gentoo-dev] official games repository
On 10/20/2013 03:31 PM, hasufell wrote: > On 10/20/2013 04:13 PM, Markos Chandras wrote: >> On 10/20/2013 01:26 PM, Мисбах-Соловьёв Вадим wrote: >>>> * not related to the games team * no review whatsoever from any >>>> dev on ebuilds that get pushed there >>> >>> It is easy-fixable. It is enough to gentoo-games team to back to >>> work on it together with community. >>> >>>> * low quality >>> low quality of what? ebuilds? I bet, it is many lower-quality >>> ebuilds in the tree. Or do you mean low quality of something >>> else? Anyway, it is fixable too. Just let's start work on it. >>> >> I agree. > >> It's better to work with the user community and join efforts than >> having yet-another-shiny overlay. > > > Gamerlay is not related to the games team and this thread is not about > gamerlay which is a project that has failed. > I have zero interest to work on gamerlay. It would have to start with > removing direct commit access of users. This is not a great way to invite more users to participate. If you intend to make the game overlay and team a developer-only thing you are doing a great work. > > This is a question directed to the games team to revive their overlay > and improve workflow (e.g. I have some games ebuilds myself which are > still very experimental/alpha in my personal overlay... I'd migrate > them there). Then you shouldn't have CC'd the gentoo-dev if you are not interested in oppinion of the community -- Regards, Markos Chandras - Gentoo Linux Developer http://dev.gentoo.org/~hwoarang
Re: [gentoo-dev] official games repository
On 10/20/2013 01:26 PM, Мисбах-Соловьёв Вадим wrote: >> * not related to the games team >> * no review whatsoever from any dev on ebuilds that get pushed there > > It is easy-fixable. It is enough to gentoo-games team to back to work on it > together with community. > >> * low quality > low quality of what? ebuilds? I bet, it is many lower-quality ebuilds in the > tree. Or do you mean low quality of something else? > Anyway, it is fixable too. Just let's start work on it. > I agree. It's better to work with the user community and join efforts than having yet-another-shiny overlay. -- Regards, Markos Chandras - Gentoo Linux Developer http://dev.gentoo.org/~hwoarang
Re: [gentoo-dev] Re: [Bug 488318] media-video/mpv[luajit] - Keyword request on alpha, arm, ppc, ppc64, sparc
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 10/20/2013 11:40 AM, Patrick Lauer wrote: > >> The affected packages can slowly be fixed. It's not like they are >> totally broken but it's more like of another way to tell you that >> a few QA problems exist and that it would be nice to fix them >> whenever you find some time. > > You mean situations where there is user-visible breakage in the > dependency graphs? > > If I were a member of the QA team (which for various reasons I've > never been allowed to be, which is quite hilarious) I'd ask you to > remember the "repoman || die" motto we beat into every new recruit > and/or ask you to honourably disable your commit privileges. > No I never meant broken depgraphs. Well for broken deps, repoman does not let you commit. If you use --force to workaround broken deps, well, then you get what you deserve. I was mostly referring to whitespaces, too long descriptions and other non-fatal warnings that a few devs may ignore. - -- Regards, Markos Chandras - Gentoo Linux Developer http://dev.gentoo.org/~hwoarang -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQJ8BAEBCgBmBQJSY8FOXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQzNTVDNDczOUYzRjJEMTRGNDRGMzU2RkMw OUJGNEY1NEMyQkE3RjNDAAoJEAm/T1TCun88fwkP/2fAxRXcL0xnc8mpYJkePdLJ A9H31frBhC7braP9Vhev+JadoVKYXYqZUGE6V5RTs49gc75iIZscysRYlRWWTzuZ E7hQmLKuoXUcm8QlpXlK506MvJQ2KbiA7B+z3MYXQfldynFGr4xG1a/y+SyT5+Cg QfN+m1KInY/+b9TO4G0EG2gxEa4H9L4ZrVGBgBTlnw3w1i62MwSVQVyTaGJZdOi0 fGbnjtw3weUhapxqw8d/yQwwpa5Zcp7zbeCsPR/1TEwBrCBYeT8lebAQ2d7n56Tz bemTvBegxCfqeg2ODMI/ZdxrZHre7wDL5VL28VOZycDB2ukhsNJ0ZfVa9r61czCY L0+yXUv1Qcu4nf+NQBgwHnN6FJHrhZD3WamL9sNpJ+io2nDO+hi/BKJAF2UC2Ilq 2XZlQrHAO28NyTTx1hRce+hDqOQeoNjWkkiyvNjzMapcbE1BGebOOY1XQYPKxZwS VszF4wBsuDS79Ccbw3XZLZMJ/RztTh8dEkCq2Zu5MnhRyKTJy1lKyRD9jVY6gRQB Q5txomsA/bOnl5WRnyvISoatZmys0oAhz8VxZkjeI1BFPhPAP3/Ptcf60mgnPP9C LgxgNWmRauiGZPCmRAaoaBhShNdBMPDPL/B8GT6pIuQVR4afWGLyt7kOTEkGGAkq nTaPUOLkdxYwztioeJq9 =8+LQ -END PGP SIGNATURE-
Re: [gentoo-dev] Re: [Bug 488318] media-video/mpv[luajit] - Keyword request on alpha, arm, ppc, ppc64, sparc
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 10/19/2013 06:43 PM, Tom Wijsman wrote: > On Sat, 19 Oct 2013 19:01:44 +0200 Jeroen Roovers > wrote: >> >> As it has been discussed on this mailing list endlessly, there >> already is a consensus: >> >> 1a) you drop the affected keywords, unless 1b) this causes you to >> drop (many) more keywords on revdeps, in which case you can >> package.(use.)mask the relevant bits 2) you inform the affected >> arch teams > > Please provide a reference to this consensus. It's probably best to document it somewhere then... > > P.S.: It is interesting to see the effects of AutoRepoman beating > people to filing bugs, maybe I should write AutoNotifyman as a > response to not having the chance to file the bug in a reasonable > time frame. > The AutoRepoman script is there just for convenience. You shouldn't take it too seriously and go filing bugs like crazy. The affected packages can slowly be fixed. It's not like they are totally broken but it's more like of another way to tell you that a few QA problems exist and that it would be nice to fix them whenever you find some time. - -- Regards, Markos Chandras - Gentoo Linux Developer http://dev.gentoo.org/~hwoarang -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQJ8BAEBCgBmBQJSY63sXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQzNTVDNDczOUYzRjJEMTRGNDRGMzU2RkMw OUJGNEY1NEMyQkE3RjNDAAoJEAm/T1TCun88Mv0P/31GkGTmWbtJy11g1bA+Xtdp 8g5eRP9S3Xj9kXjkKMczCqP5U2T5lgavMqnIDytLJehK9BxkbyDfUHqWkFmTvLAa hGrD/ioVG3pw5ugdJmTNkhrj8bBshYIDCZiU6137nRmX7sR6k0KENPpfDndkZ2Wc Tp8/Kb/M7gPhFy5g4NFKg4ovbYOwwGcFdkt/2VRSQtlycW1gx+U744C+T5CYO/+J 9U91d8mm12TdzOKGbvUllBTuPut8PCSg/Y/3SWCCt9+pTRhDTt7uK+ChuR11Cy6F TBs5hLT0X1dc5WD6GBXLwRJcK8yEue1uOnZ5NqKwb9G9EH28Ud/uaVe80HKY27+d /3IjHAUZ128vRXgMW+RlEhf3Jd5XUCy6xTzzgW8dhmttYfmfdPpNe6KP6LyKSi5E VZiff82haP78vWoYil+4RgTEnqNRTzmcWAMxSZQpsW1FolI5P3s/l3+ltrEpo8iC Kkn9s3M9Zv085PL0e5aTVn0Bz8PXP3KhxzsoUPwt+yT4mIIF/2QU9n+6ywx9RQoP ijeKj2rkbsy4XLDIZbFogpU1oRi59dUag38nhuguGQZ2dBR108z/H5+IFHDfDMjt 3kVLfBunRJ4VlYY7s608NVabAQtXrJP4huHz+NvViu0K/nbRE4RgihxC03l/RDcy UTeRGFTNJ/qXa/I1/753 =0WvP -END PGP SIGNATURE-
Re: [gentoo-dev] Packages up for grabs
On 10/19/2013 04:43 PM, Daniel Campbell wrote: >> x11-wm/fluxbox >> >> > > I'm not a developer (but have a completed dev test that doesn't know > where to go...). I'm interested in nabbing x11-wm/fluxbox (and any > related projects that are still alive). I use Fluxbox daily and keep an > eye on upstream. It'd be nice to be able to contribute something > worthwhile to Gentoo, even if it's just one package (for now). > Hi Daniel, That's fine. Please contact the proxy-maintainers[1] team to discuss this further. [1] https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers -- Regards, Markos Chandras - Gentoo Linux Developer http://dev.gentoo.org/~hwoarang
Re: [gentoo-dev] about inactive project members/leaders
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 10/15/2013 09:53 PM, hasufell wrote: > On 10/15/2013 10:46 PM, Markos Chandras wrote: >> On 10/15/2013 09:40 PM, hasufell wrote: >>> On 10/15/2013 10:28 PM, Markos Chandras wrote: >>>> On 10/15/2013 09:16 PM, hasufell wrote: >>>>> I wonder if undertakers should also check for inactive >>>>> project leaders/members and remove them from the projects >>>>> in case there has not been any activity for a while, >>>>> regardless of the internal project structure. >>>> >>>>> Authority does not only come with knowledge, but also with >>>>> commitment. >>>> >>>>> If no one disagrees, then we should add this to the list of >>>>> undertakers competence. >>>> >>>> >>>> We already check for inactive members (developers and >>>> leaders are the same for us) >>>> >>>> What's is this thread for? >>>> >>>> > >>> You probably misunderstood. I didn't mean inactive in general, >>> but inactive in a _project_. > > >> Err no. That's not our job. If the project has an inactive >> leader or member it's the leaders job (or team's job if the >> leader is inactive) to sort this out internally. If that fails, >> then they should seek help. undertakers do not have (and neither >> want) the authority to remove active developers from certain >> projects. If a project appears to be dead even though it's >> members (and/or leader) are active in other Gentoo areas, and >> they refuse to fix the situation, you may want to take this to >> the Council. Seem like you need to re-read > >> http://www.gentoo.org/proj/en/glep/glep-0039.html > > > > I have read that and that is why I propose that undertakers do > also check projects for their internal activity patterns. > > I don't really think that is a job for the council. > Sorry it's not going to happen. We can't just go ahead asking all the projects for a list of active/inactive people every couple of months or so. This does not scale, and we do not want to become annoying to other developers. Like I said, if a project is completely dead someone will notice. If you have found such a project, and you talked to them, and they refuce to fix it, then taking this to the Council is the right way to solve this problem. If the project has a few inactive people then the team or the lead can sort this out themselves. - -- Regards, Markos Chandras - Gentoo Linux Developer http://dev.gentoo.org/~hwoarang -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQJ8BAEBCgBmBQJSXa0HXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQzNTVDNDczOUYzRjJEMTRGNDRGMzU2RkMw OUJGNEY1NEMyQkE3RjNDAAoJEAm/T1TCun88cFkQAMaU6/+PUhp8M7qFhCAiq2qG FEm+hwqZO27YAFdRH7vuTJRUYSFr6Iq5WRw+A2qXOuRt6jGahGWTBr23u+40/Jeq MqgUVFaTY7EFfPWea6KXicqJgZEWUMCx31H2T6Y6bgq0M8jsRjDwTIMo5JkVBFX0 I8LKJslYadRAW+BWci7W/AYBaVC45kebAdktv8a1diwzvC+5S5vl8/Rcw4mWXLFA jmQlXZOVk/hlyLVSU2x7xo9IcNradkEMRIWh87IQzr6UGO6sWoR1wtA2Kux/lWIw nOjyDk9ARaYq2WDxaR899Lt9yvUCJ04gi3SqMpimaOEYoaMc26RHM7q3awxtR6LW YcDmphFKNRAxES7j6e0tPt78wKff/FDckAz8Q2W0mSJ7Y+erJ2T6Eb4KBKjiGa7Q 9iA8vJy5PfaF6/VINwEN3CWZQDS2I5pu5Bwwo/PS7SSR/dlYYKiriDYxEGt9fJeM YlXr+jF50Gd64b4zGoY16bw5XKgnops7uo+pu/1EcO3DYyvtujZmpSVNIb5n/H82 0kuXn2kkL5U4Gq2WouVGrV8Rjh9fGE3vUzdVvyCHdMFtdjB/RLu0exz520rmGK/+ 4p6WgR7MQYDoIlTWPRpluZ2WAVfnY/zEg7tE8YeVqBpN2NY5uWd50SEUVY6rZjIW hZTyWWyKqElh1I6Y8vZD =ueym -END PGP SIGNATURE-
