Re: [gentoo-dev] rfc: trimming the @system set [was: adding sys-apps/iproute2 to the @system set]

[J. Roeleveld]

On Sunday, September 07, 2014 05:57:57 PM Joshua Kinard wrote:
 On 09/07/2014 17:04, Rich Freeman wrote:
  On Sun, Sep 7, 2014 at 4:33 PM, Joshua Kinard ku...@gentoo.org 
wrote:

snipped

  As for Parallel builds, do you make make -jX?  Or running concurrent
  emerges in different shells?  I wasn't commenting at all on parallel
  builds. 
  I was referring to --jobs.  The issue with @system is that you can't
  build packages in @system in parallel, or their dependencies.  Now,
  I'm not sure if that extends to dependencies of virtual packages - if
  not then an editor isn't as much of a problem.  However, you're still
  stuck with lots of whining by portage if you unmerge your last editor.
  I think we really need to reserve that for situations where you're
  actually likely to break something.  You can unmerge and re-merge an
  editor without any issues at all, and there are probably lots of
  useful substitutes for editors that aren't in the editor virtual.
 
 Well, I believe a stage2 in catalyst is just a remerge of @system, and
 that's only ~12 hours on my Octane, which is perfectly fine for me.  So 
the
 parallelization isn't a real concern.  Stage3 takes ~30hrs, though, so I'd
 be curious to see if that parallelizes well once I get SMP working on that
 machine.
 
 Then again, those of us who work with slower hardware probably have a 
much
 higher level of patience than others.  So while the inability to parallelize
 the @system merge isn't a concern for me, it is for others.

With faster hardware, I don't need as much patience.
But on slower machines, as I am used to fast ones, I tend to notice the 
lack of parallellism during the emerge-phase.

  I'm not suggesting that we rip out editor just now either.  It makes
  more sense to just try to hold the line on @system until we have
  something better actually implemented (like mix-ins), and then it
  won't be a big deal if we trim it down further.
 
 The editor is a total non-issue to me.  I simply raised it as part of my
 reply to branch the thread off.  I am perfectly fine keeping virtual/editor
 in @system and letting nano be the primary satisfier.

Personally, I would not have an issue with the stage3 not having an editor, 
but it would make installing Gentoo more difficult considering there are 
some files that need to be edited. And the handbook actually references 
nano.

  To cut down on replies - the reason nano is preferred is that it is
  the first package in the virtual, which is the usual rule.  Of course,
  it was placed there deliberately since it is a simple editor with few
  dependencies and both the vi and emacs camps can agree that it is
  lousy.
 
 The vi and emacs camps agreeing on something?  Impossible!

I think both camps do the following:
emerge preferred editor
emerge -C nano
as one of the first steps.

The first thing I do on a new install as soon as a portage tree is available is 
run the above.

--
Joost

[gentoo-dev] Re: rfc: trimming the @system set [was: adding sys-apps/iproute2 to the @system set]

[Duncan]

J. Roeleveld posted on Wed, 10 Sep 2014 10:08:56 +0200 as excerpted:

 The vi and emacs camps agreeing on something?  Impossible!
 
 I think both camps do the following:
 emerge preferred editor
 emerge -C nano as one of the first steps.
 
 The first thing I do on a new install as soon as a portage tree is
 available is run the above.

FWIW I keep both my preferred editor (MC, FWIW) and nano installed.

That way I have a backup if my preferred fails to start (as it does from 
time to time if I'm rebuilding deps), and I don't end up having to use a 
pager and sed in place of a proper interactive editor, as I did at one 
point many years ago on a different distro.  (It probably had vim-minimal 
or some such, but I was still young on Linux at that point and didn't 
know what to look for.  Fortunately I had a dead-tree copy of Linux in a 
Nutshell around, with an appendix on sed that I could refer to...)


-- 
Duncan - List replies preferred.   No HTML msgs.
Every nonfree program has a lord, a master --
and if you use the program, he is your master.  Richard Stallman

Re: [gentoo-dev] RFC: Deprecating and killing the concept of herds

[Pacho Ramos]

El mar, 09-09-2014 a las 21:45 +0200, Michał Górny escribió:
[...]
 I believe it would be benfiicial to just deprecate and eventually drop
 herd/ in favor of explicit maintainer/ using the alias. I don't know
 if someone has other use of herds.xml but it the contents are either
 outdated or redundant. Therefore, I would suggest eventually getting
 rid of that file as well.
 
 What do you think?
 

I agree with this but we would need to cover the case of people being in
a determined mail alias but don't really wanted to be considered a
maintainers of the involved packages as they are in the alias to keep
track on that issues. This problem has usually raised when a herd starts
to become inactive as no one is really maintaining that packages. We can
erroneously think that the herd is still active because there are people
in the alias... but they are really not taking care of them at all. We
discussed this in the past (I think it was a gentoo-dev ML thread
related with media-optical herd being empty) and we agreed on only
considering people listed in herds.xml as maintainers, not people in
mail alias.

Personally I would vote for simply have a maintainer tag pointing to
the alias but we would still need to keep a list of real maintainers for
that alias as usually not all people listed in the alias are willing to
maintain the packages.

Re: [gentoo-dev] RFC: Deprecating and killing the concept of herds

[Rich Freeman]

On Tue, Sep 9, 2014 at 6:54 PM, Kent Fredric kentfred...@gmail.com wrote:

 On 10 September 2014 10:23, Michał Górny mgo...@gentoo.org wrote:

 I don't understand your concern. I'm only saying we should stop relying
 on that stupid out-of-repository herds.xml file and put the e-mail
 address directly in metadata.xml. Bugzilla and bug assignment would
 work pretty much the same -- except that you wouldn't have to scan one
 more file to get the e-mail you're looking for.


 That sounds less like you're trying to deprecate the use of herds, and more
 like you're trying to deprecate the use of herds /in metadata.xml/.

 The latter strikes me as an easier sell, just the markup is more effort.

 If it was possible to write herdperl/herd  and have some process that
 automatically upscaled that to a maintainer tag, that'd be cool.

If the only thing we're using herds for is as a way to populate the
maintainer field, then they really should go away.

I'd think that the whole point of having herds is so that you could
group packages together in a way OTHER than by maintainer.  We already
have the maintainer attribute to track who maintains a package. Herds
were supposed to be about grouping related packages together (like a
herd), and not keeping track of who the cattle rustlers were.

IMHO herds aren't working because:
1.  They're basically being used as another form of project, so in
addition to mail alias members and project pages it is yet another
version of who is working on what which differs from the other ways of
finding out who is working on what.

2.  They're supposed to be used to group related packages together,
but we already have categories, and there isn't just one true way to
group packages together anyway.  It sounds like they're a 1:many form
of tagging.

--
Rich

Re: [gentoo-dev] RFC: Deprecating and killing the concept of herds

[Rich Freeman]

On Wed, Sep 10, 2014 at 7:33 AM, Pacho Ramos pa...@gentoo.org wrote:

 Personally I would vote for simply have a maintainer tag pointing to
 the alias but we would still need to keep a list of real maintainers for
 that alias as usually not all people listed in the alias are willing to
 maintain the packages.


I think the solution to this is that maintainers can be either:
1.  Devs - identified by their email address.  (simple enough)
or
2.  Projects - identified by their email alias.
or
3.  A proxy maintainer identified by email address (in which case
either a dev or project must also be listed, potentially including the
proxy maintainer project).

A project must have:
1.  A mail alias.  Anybody can monitor if the project is OK with it,
but it isn't the definitive member list.
2.  A project page on the wiki with a member list.  This is the
definitive list of who is a member.
3.  An annually-elected lead.

The lead should clean up the member list from time to time.  An
inactive project should be treated the same as an inactive dev as far
as maintainership goes - target for cleanup.  Special projects like
archs/infra/comrel/etc should probably be escalated to council if they
appear dead.

Herds are just collections of packages - a package being in a herd
says nothing about whether it is maintained, just as a package being
in a category says nothing about it being maintained.

--
Rich

Re: [gentoo-dev] Does the scm ebuild masking policy make sense for git?

[Tom Wijsman]

On Tue, 09 Sep 2014 19:12:28 +
hasufell hasuf...@gentoo.org wrote:

 Jauhien Piatlicki:
  
  When I accept ~arch I expect that no live ebuilds will be built. I
  think other gentoo users expect the same.
 
 Just because users are used to it doesn't make it better.

How does it make it better for users that are used to what works well?

  Emerging live ebuild usually is quite a risky thing, so hiding such
  stuff behind dropped keywords is quite reasonable.
 
 That's why you can mask them.

Masking is for packages that are known to be broken, not for risks.

 Hiding useful information from users is not reasonable.

Eh? Jauhien talks about hiding the visibility from the package manager.

 The same flawed logic of empty KEYWORDS could actually be applied to
 any ebuild variable.
 You say we can't test if it works for all these architectures
 reliably and for every single commit.
 Yeah, same goes for dependencies, license and even the description.
 Because it's a live ebuild, all of them can change. KEYWORDS is no
 special exception.

KEYWORDS is a special exception because it involves arch testing.

Re: [gentoo-dev] Does the scm ebuild masking policy make sense for git?

[hasufell]

Tom Wijsman:
 On Tue, 09 Sep 2014 19:12:28 +
 hasufell hasuf...@gentoo.org wrote:
 
 Jauhien Piatlicki:

 When I accept ~arch I expect that no live ebuilds will be built. I
 think other gentoo users expect the same.

 Just because users are used to it doesn't make it better.
 
 How does it make it better for users that are used to what works well?
 

It improves usability by providing additional information.

 Emerging live ebuild usually is quite a risky thing, so hiding such
 stuff behind dropped keywords is quite reasonable.

 That's why you can mask them.
 
 Masking is for packages that are known to be broken, not for risks.
 

PMS doesn't specify what exactly package.mask is for, so scm ebuilds is
a perfectly valid use case, unless you can come up with an alternative
that is not wrong like empty KEYWORDS.


 The same flawed logic of empty KEYWORDS could actually be applied to
 any ebuild variable.
 You say we can't test if it works for all these architectures
 reliably and for every single commit.
 Yeah, same goes for dependencies, license and even the description.
 Because it's a live ebuild, all of them can change. KEYWORDS is no
 special exception.
 
 KEYWORDS is a special exception because it involves arch testing.
 

Yes, and you hide this information from the user.

Re: [gentoo-dev] RFC: Deprecating and killing the concept of herds

[Tom Wijsman]

On Tue, 9 Sep 2014 21:45:49 +0200
Michał Górny mgo...@gentoo.org 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.

Re: [gentoo-dev] RFC: Deprecating and killing the concept of herds

[Michał Górny]

Dnia 2014-09-10, o godz. 07:53:31
Rich Freeman ri...@gentoo.org napisał(a):

 On Wed, Sep 10, 2014 at 7:33 AM, Pacho Ramos pa...@gentoo.org wrote:
 
  Personally I would vote for simply have a maintainer tag pointing to
  the alias but we would still need to keep a list of real maintainers for
  that alias as usually not all people listed in the alias are willing to
  maintain the packages.
 
 
 I think the solution to this is that maintainers can be either:
 1.  Devs - identified by their email address.  (simple enough)
 or
 2.  Projects - identified by their email alias.
 or
 3.  A proxy maintainer identified by email address (in which case
 either a dev or project must also be listed, potentially including the
 proxy maintainer project).

4. A mail alias that is not project :). For example, we have clang@ for
easily aggregating all clang-related build failures and other bugs but
it isn't a formal team.

It's hard if such a thing has proper member list. But in any case, is
there a reason for needing to have definitive member list?

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

Re: OT - My last one to this thread - Skype + Tox - Re: [gentoo-dev] Re: maintainer-needed@ packages need you!

[Andrew Savchenko]

Hi,

On Wed, 10 Sep 2014 07:50:05 +0200 J. Roeleveld wrote:
  I'm talking about the following research:
  https://www.google.com/url?sa=trct=jq=esrc=ssource=webcd=1cad=rjauact
  =8ved=0CB4QFjAAurl=https%3A%2F%2Fwww.blackhat.com%2Fpresentations%2Fbh-eur
  ope-06%2Fbh-eu-06-biondi%2Fbh-eu-06-biondi-up.pdfei=9jAPVJH1AafnygOOiIHgDg
  usg=AFQjCNHeILDYY4k-nUUw8vPmUCJ86Eywbgbvm=bv.74649129,d.bGQ
  
  Of course, skype protocol was likely changed since that time, but I
  really doubt that functionality for remote execution of arbitrary
  code was removed.
 
 That research was from 2006. Over 8 years ago.
 Do you avoid using Bind because of all the security bugs it had in 2006?
 What about OpenSSL, that one had a big one not too long ago.
 And I'm sure I can find plenty of exploits for the Linux kernel based on the 
 versions in use in 2006.
 
 The Skype protocol has changed a lot over the years and older versions of the 
 protocol have been deprecated and removed.

There is a large difference between mistake, bug and deliberately
added functionality. As research shows, remote code execution was
deliberately added. What was a bug is a mistake that allowed
third-party to use this feature without proper keys.
 
 If it is still in there, I'm certain it would be known, considering the 
 amount 
 of people using Skype these days.

Ablosute majority of these people are not IT specialists and even
for those that are, skype is extremely hard to decrypt, diassemble
and study, as one can see from the work above. Most probably that
nobody cares to spend several months of full-time employment to
analyze modern skype versions again.


Best regards,
Andrew Savchenko


pgpX4weNr1fq4.pgp
Description: PGP signature

Re: [gentoo-dev] Does the scm ebuild masking policy make sense for git?

[Tom Wijsman]

On Wed, 10 Sep 2014 13:56:04 +
hasufell hasuf...@gentoo.org wrote:

 Tom Wijsman:
  On Tue, 09 Sep 2014 19:12:28 +
  hasufell hasuf...@gentoo.org wrote:
  
  Jauhien Piatlicki:
 
  When I accept ~arch I expect that no live ebuilds will be built. I
  think other gentoo users expect the same.
 
  Just because users are used to it doesn't make it better.
  
  How does it make it better for users that are used to what works
  well?
 
 It improves usability by providing additional information.

Usability is not to be found in information that is subject to change.

  Emerging live ebuild usually is quite a risky thing, so hiding
  such stuff behind dropped keywords is quite reasonable.
 
  That's why you can mask them.
  
  Masking is for packages that are known to be broken, not for risks.
 
 PMS doesn't specify what exactly package.mask is for, so scm ebuilds
 is a perfectly valid use case, unless you can come up with an
 alternative that is not wrong like empty KEYWORDS.

That something is not in PMS does not make it a valid use case; the
Portage tree is subject to more specifications, like for example that
the devmanual has a very specific paragraph on this case:

CVS ebuilds must be either with empty KEYWORDS or package.masked (but
not both). Empty KEYWORDS are strongly preferred. This applies to
live ebuilds (-) and to ebuilds that extract a static revision
but still use CVS for fetching.

http://devmanual.gentoo.org/ebuild-writing/functions/src_unpack/cvs-sources

We can also find more about empty keywords:

No keyword: If a package has no keyword for a given arch, it means it
is not known whether the package will work, or that insufficient
testing has occurred for ~arch.

http://devmanual.gentoo.org/keywording

So, both quotes reveal that empty keywords fit very well; package.mask
rather fits when there is a good reason to it, especially since the
idea of QA is to keep package.mask maintainable by limiting its length.

In doing so, QA can keep an eye on what is broken; which allows either
fixing or removing ebuilds that stay there too long. In this context, a
masked live ebuild would be interpreted as a live ebuild that fails to
fetch, compile or run for a prolonged time; eg. due to an inactive or
dead upstream, or an upstream that refuses to support that broken part.

  The same flawed logic of empty KEYWORDS could actually be applied
  to any ebuild variable.
  You say we can't test if it works for all these architectures
  reliably and for every single commit.
  Yeah, same goes for dependencies, license and even the description.
  Because it's a live ebuild, all of them can change. KEYWORDS is no
  special exception.
  
  KEYWORDS is a special exception because it involves arch testing.
 
 Yes, and you hide this information from the user.

Information that is a given; as known, live ebuilds miss arch testing.

Re: [gentoo-dev] Does the scm ebuild masking policy make sense for git?

[hasufell]

Tom Wijsman:
 It improves usability by providing additional information.
 
 Usability is not to be found in information that is subject to change.
 

Please also set DEPEND, RDEPEND, EGIT_REPO_URI, DESCRIPTION and the rest
of them to , because they are all subject to change.

 So, both quotes reveal that empty keywords fit very well;

No, they just reveal that people didn't think carefully enough before
establishing that policy.

 by limiting its length.
 

Welcome to 2014. We have tools that can aid you with dealing with big files.

 
 Information that is a given; as known, live ebuilds miss arch testing.
 

If an ebuild hasn't been tested on _any_ arch, then it shouldn't be in
the tree at all.

In addition, it is obviously wrong, since most people will at least test
their own live ebuilds on major arches and they are allowed to add those
keywords without involving arch teams.

[gentoo-dev] Re: RFC: Deprecating and killing the concept of herds

[Steven J. Long]

On Wed, Sep 10, 2014 at 07:53:31AM -0400, Rich Freeman wrote:
 On Wed, Sep 10, 2014 at 7:33 AM, Pacho Ramos pa...@gentoo.org wrote:
 
  Personally I would vote for simply have a maintainer tag pointing to
  the alias but we would still need to keep a list of real maintainers for
  that alias as usually not all people listed in the alias are willing to
  maintain the packages.
 
 
 I think the solution to this is that maintainers can be either:
 1.  Devs - identified by their email address.  (simple enough)
 or
 2.  Projects - identified by their email alias.
 or
 3.  A proxy maintainer identified by email address (in which case
 either a dev or project must also be listed, potentially including the
 proxy maintainer project).
 
 A project must have:
 1.  A mail alias.  Anybody can monitor if the project is OK with it,
 but it isn't the definitive member list.
 2.  A project page on the wiki with a member list.  This is the
 definitive list of who is a member.
 3.  An annually-elected lead.
 
 The lead should clean up the member list from time to time.  An
 inactive project should be treated the same as an inactive dev as far
 as maintainership goes - target for cleanup.  Special projects like
 archs/infra/comrel/etc should probably be escalated to council if they
 appear dead.
 
 Herds are just collections of packages - a package being in a herd
 says nothing about whether it is maintained, just as a package being
 in a category says nothing about it being maintained.
 

Thanks for that lucid explanation. It's clear the metadata is useful,
for keeping track of apps cross-tree, but it's being confused with a
project, as you outlined in your other mail. Perhaps this is because
people are considered members of herds, when really they should just
be on the mail alias. Additionally, herd metadata should be seen as
*strictly* about cross-tree categorisation, and cleaned up on that
basis (whether there are still any packages, or the grouping is
still relevant), reviewed by tree-cleaners.

(If they're not already; idk your procedures, ofc.)

I think the confusion is understandable though, as people are
constantly checking who's on the alias for a herd with willikins.
That leads to the conception that a herd is a group of devs/proxy,
not a group of packages. It's hard to shake when you're constantly
looking up a group of devs based on !herd[1], or reading it (with
the list of _people_) in channel after channel.

It would be better if people were checking projects, from what you
wrote above. I would recommend reworking that to !project, with
!herd supplying a link to the listing of _packages_ belonging to
the herd on the website, instead. Since as you say, a herd is a
group of packages, whereas a project is a group of developers.

Either that, or give up and let a herd of cats, be a herd of cats ;)

Regards,
steveL

[1] eg: /msg willikins herd kde
-- 
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)

[gentoo-dev] Re: Does the scm ebuild masking policy make sense for git?

[Steven J. Long]

On Sun, Sep 07, 2014 at 09:03:00PM -0400, Rich Freeman wrote:
 Right now the general policy is that we don't allow unmasked (hard or
 via keywords) ebuilds in the tree if they use an scm to fetch their
 sources.  There are a bunch of reasons for this, and for the most part
 they make sense.
 
 I was wondering if this policy still made sense in the case of scm
 ebuilds that pull a particular git commit.  While portage can't check
 the Manifest, the fact is that git will in this case, and since we're
 pointed at a content-hashed commit we can ensure that the package
 never changes.  We of course can't mirror it with the current setup
 (there is no real reason we couldn't mirror git, but this is a
 different problem).
 
 Tying ebuilds to a git commit has pros and cons, but I'm hard-pressed
 to think of any actual QA issues.  That is, something that would make
 our tree inconsistent, or create a security vulnerability.
 
 Am I just not thinking of something?  It would probably be most useful
 for packages that track a backport branch or something along those
 lines - where upstream does not regularly update their tarballs so
 we're constant creating patchsets.  In this case all we'd have to do
 is bump the commit ID in the ebuild.
 

What you're saying makes perfect sense at the developer-infra side,
but as you've conceded, not so much at the infra-mirror side.

Clearly instead of every user downloading a git clone, it's better to
pin to that commit and have the push script hook with infra to automate
a tarball, since the dev-infra channel is secure, and the SHA1 is
current at that point. That would enable you to submit a pinned ebuild
with the relevant keywords, users to download standard tarballs and
verify if needed (since the commit id is in the ebuild, and that has
a strong manifest); the saving in bandwidth is something sponsors
might go for.

I'm sure many users would be happy to contribute in various fashions,
too; though I'd ask patrick to consult and perhaps provide backend if
infra is stretched. He runs hosts for quite a lot of gentoo people
already, as well as git and trac machines, and the tinderbox, on
gentooexperimental.org.

Regards
steveL.
-- 
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)

Re: [gentoo-dev] RFC: Deprecating and killing the concept of herds

[Rich Freeman]

On Wed, Sep 10, 2014 at 10:18 AM, Michał Górny mgo...@gentoo.org wrote:
 Dnia 2014-09-10, o godz. 07:53:31
 Rich Freeman ri...@gentoo.org napisał(a):

 On Wed, Sep 10, 2014 at 7:33 AM, Pacho Ramos pa...@gentoo.org wrote:
 
  Personally I would vote for simply have a maintainer tag pointing to
  the alias but we would still need to keep a list of real maintainers for
  that alias as usually not all people listed in the alias are willing to
  maintain the packages.
 

 I think the solution to this is that maintainers can be either:
 1.  Devs - identified by their email address.  (simple enough)
 or
 2.  Projects - identified by their email alias.
 or
 3.  A proxy maintainer identified by email address (in which case
 either a dev or project must also be listed, potentially including the
 proxy maintainer project).

 4. A mail alias that is not project :). For example, we have clang@ for
 easily aggregating all clang-related build failures and other bugs but
 it isn't a formal team.

 It's hard if such a thing has proper member list. But in any case, is
 there a reason for needing to have definitive member list?

I don't think we should allow #4 in the absence of #1-2, because mail
aliases shouldn't be maintainers.  What #4 says is I'd like to know
what is going on with a package, but don't look at me if it breaks.

The challenge is that people are going to fail to distinguish between
these aliases and ones that belong to projects, because they look the
same.  Why should we have a clang email alias if there isn't a clang
project?  Why not just make it into a project?  It sounds like you
have a bunch of devs who want to stay on top of clang so that it is
well-supported in the tree, and that is basically the definition of a
project.  You don't need to have meetings, agendas, minutes, and
bylaws to be a project - just a common purpose.

I'm not opposed to finding better ways to keep people informed.  I
just don't want to equate a desire to be informed with a commitment to
maintain something - which we've already identified as a problem.

Also, you spoke about clang-related build failures.  You probably
wouldn't be tagging packages with that alias in that case - you'd just
have it as a CC alias on bugs.  You're more interested in specific
bugs than specific packages.

--
Rich

[gentoo-dev] Last rites: app-emulation/emul-linux-x86-compat

[Ulrich Mueller]

# Ulrich Müller u...@gentoo.org (10 Sep 2014)
# Multiple security vulnerabilities, bug #510960.
# Masked for removal in 30 days, bug #517932.
app-emulation/emul-linux-x86-compat


pgpLYsx1bHQzD.pgp
Description: PGP signature

Re: [gentoo-dev] RFC: Deprecating and killing the concept of herds

[Markos Chandras]

-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 mgo...@gentoo.org
 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-

[gentoo-dev] Re: RFC: Deprecating and killing the concept of herds

[Duncan]

Markos Chandras posted on Wed, 10 Sep 2014 21:21:24 +0100 as excerpted:

 -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 mgo...@gentoo.org
 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?

You fell into the same initial trap as I did, thus demonstrating the 
point. =:^\

The above is a PROJECT page, not a HERD page.  Herds are groups of 
packages, not people, and shouldn't, at least directly, be in need of 
more people.

And if herds are groups of packages, shouldn't it be tree-cleaners, not 
undertakers, removing dead herds?

Of course that confusion is the point of the thread.  Why not simply 
deprecate and eventually kill herds and assign packages directly to 
projects, instead of assigning them to herds which must then cross-
checked against an entirely different file in ordered to find the 
responsible project.

-- 
Duncan - List replies preferred.   No HTML msgs.
Every nonfree program has a lord, a master --
and if you use the program, he is your master.  Richard Stallman

[gentoo-portage-dev] [PATCH] Split install_qa_check() into install-qa-check.d scripts

[Michał Górny]

Convert the horrendous install_qa_check() function into a plug-in system
that calls separate QA checking scripts from install-qa-check.d.
---
 bin/install-qa-check.d/05double-D   |  17 +
 bin/install-qa-check.d/05prefix | 117 +++
 bin/install-qa-check.d/10executable-issues  | 140 
 bin/install-qa-check.d/10ignored-flags  |  99 +++
 bin/install-qa-check.d/20deprecated-directories |  18 +
 bin/install-qa-check.d/20runtime-directories|  26 +
 bin/install-qa-check.d/60bash-completion| 130 
 bin/install-qa-check.d/60openrc |  41 ++
 bin/install-qa-check.d/60pkgconfig  |  15 +
 bin/install-qa-check.d/60pngfix |  35 +
 bin/install-qa-check.d/60systemd|  25 +
 bin/install-qa-check.d/60udev   |  21 +
 bin/install-qa-check.d/80libraries  | 158 
 bin/install-qa-check.d/80multilib-strict|  50 ++
 bin/install-qa-check.d/90gcc-warnings   | 145 
 bin/install-qa-check.d/90world-writable |  25 +
 bin/misc-functions.sh   | 939 +---
 17 files changed, 1073 insertions(+), 928 deletions(-)
 create mode 100644 bin/install-qa-check.d/05double-D
 create mode 100644 bin/install-qa-check.d/05prefix
 create mode 100644 bin/install-qa-check.d/10executable-issues
 create mode 100644 bin/install-qa-check.d/10ignored-flags
 create mode 100644 bin/install-qa-check.d/20deprecated-directories
 create mode 100644 bin/install-qa-check.d/20runtime-directories
 create mode 100644 bin/install-qa-check.d/60bash-completion
 create mode 100644 bin/install-qa-check.d/60openrc
 create mode 100644 bin/install-qa-check.d/60pkgconfig
 create mode 100644 bin/install-qa-check.d/60pngfix
 create mode 100644 bin/install-qa-check.d/60systemd
 create mode 100644 bin/install-qa-check.d/60udev
 create mode 100644 bin/install-qa-check.d/80libraries
 create mode 100644 bin/install-qa-check.d/80multilib-strict
 create mode 100644 bin/install-qa-check.d/90gcc-warnings
 create mode 100644 bin/install-qa-check.d/90world-writable

diff --git a/bin/install-qa-check.d/05double-D 
b/bin/install-qa-check.d/05double-D
new file mode 100644
index 000..1634afd
--- /dev/null
+++ b/bin/install-qa-check.d/05double-D
@@ -0,0 +1,17 @@
+# Check for accidential install into ${D}/${D}
+
+DD_check() {
+   if [[ -d ${D%/}${D} ]] ; then
+   local -i INSTALLTOD=0
+   while read -r -d $'\0' i ; do
+   eqawarn QA Notice: /${i##${D%/}${D}} installed in 
\${D}/\${D}
+   ((INSTALLTOD++))
+   done  (find ${D%/}${D} -print0)
+   die Aborting due to QA concerns: ${INSTALLTOD} files installed 
in ${D%/}${D}
+   fi
+}
+
+DD_check
+: # guarantee successful exit
+
+# vim:ft=sh
diff --git a/bin/install-qa-check.d/05prefix b/bin/install-qa-check.d/05prefix
new file mode 100644
index 000..e1fc2bd
--- /dev/null
+++ b/bin/install-qa-check.d/05prefix
@@ -0,0 +1,117 @@
+# Prefix specific QA checks
+
+install_qa_check_prefix() {
+   [[ ${ED} == ${D} ]]  return
+
+   if [[ -d ${ED}/${D} ]] ; then
+   find ${ED}/${D} | \
+   while read i ; do
+   eqawarn QA Notice: /${i##${ED}/${D}} installed in 
\${ED}/\${D}
+   done
+   die Aborting due to QA concerns: files installed in ${ED}/${D}
+   fi
+
+   if [[ -d ${ED}/${EPREFIX} ]] ; then
+   find ${ED}/${EPREFIX}/ | \
+   while read i ; do
+   eqawarn QA Notice: ${i#${D}} double prefix
+   done
+   die Aborting due to QA concerns: double prefix files installed
+   fi
+
+   if [[ -d ${D} ]] ; then
+   INSTALLTOD=$(find ${D%/} | egrep -v ^${ED} | sed -e 
s|^${D%/}|| | awk '{if (length($0) = length('${EPREFIX}')) { if 
(substr('${EPREFIX}', 1, length($0)) != $0) {print $0;} } else if 
(substr($0, 1, length('${EPREFIX}')) != '${EPREFIX}') {print $0;} }')
+   if [[ -n ${INSTALLTOD} ]] ; then
+   eqawarn QA Notice: the following files are outside of 
the prefix:
+   eqawarn ${INSTALLTOD}
+   die Aborting due to QA concerns: there are files 
installed outside the prefix
+   fi
+   fi
+
+   # all further checks rely on ${ED} existing
+   [[ -d ${ED} ]] || return
+
+   # check shebangs, bug #282539
+   rm -f ${T}/non-prefix-shebangs-errs
+   local WHITELIST= /usr/bin/env 
+   # this is hell expensive, but how else?
+   find ${ED} -executable \! -type d -print0 \
+   | xargs -0 grep -H -n -m1 ^#! \
+   | while read f ;
+   do
+   local fn=${f%%:*}
+   local pos=${f#*:} ; pos=${pos%:*}
+   local line=${f##*:}
+   # shebang always appears on the first line ;)
+   [[