Re: [gentoo-dev] [PATCH 3/3] app-admin/kube-bench: convert to go-module go.sum

2020-02-14 Thread Sam Jorna (wraeth)
On Saturday, 15 February 2020 3:14:55 AM AEDT Matt Turner wrote:
> On Fri, Feb 14, 2020 at 12:31 AM Sam Jorna (wraeth)  
wrote:
> > In this instance, at least two people (myself included) have drawn an
> > impression that led them to voice their concern in some way (I'm unsure if
> > mpagano was voicing concern or just agreeing with the general concept).
> > Maybe we're the only ones. Maybe not.
> 
> What do you think the threshold should be? If one person objects,
> should ComRel cease and desist? Two? Should we have a Gentoo-wide
> vote?
> 
> I don't have the highest opinion of ComRel and I'm a member, but maybe
> you could let us do our jobs?

I didn't say ComRel shouldn't do their job, nor offered any opinion on ComRel 
whatsoever. I said people shouldn't be called out on what looks like a 
legitimate question, and that quote was illustrating one of the reasons why. 
The threshold I'm talking about would be "is this question, however it's 
worded, relevant to the subject."

Having said that, if this is you wearing a ComRel hat telling me to mind my 
own business, so be it.

-- 
Sam Jorna (wraeth)
GnuPG ID: 0xD6180C26



signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] [PATCH 3/3] app-admin/kube-bench: convert to go-module go.sum

2020-02-14 Thread Sam Jorna (wraeth)
On Friday, 14 February 2020 2:21:32 PM AEDT Matt Turner wrote:
> On Thu, Feb 13, 2020 at 4:12 AM Mike Pagano  wrote:
> > On Thu, Feb 13, 2020 at 06:46:43PM +1100, Sam Jorna (wraeth) wrote:
> > > On Thursday, 13 February 2020 5:40:46 AM AEDT Matt Turner wrote:
> > > > On Wed, Feb 12, 2020 at 9:59 AM William Hubbs  
wrote:
> > > > > On Wed, Feb 12, 2020 at 06:54:19PM +1100, Sam Jorna (wraeth) wrote:
> > > > > > On Monday, 10 February 2020 7:55:01 AM AEDT Michał Górny wrote:
> > > > > > > On Sun, 2020-02-09 at 20:38 +, Michael 'veremitz' Everitt 
wrote:
> > > > > > > > Hrm, pardon my ignorance, but do 'we' really need to review
> > > > > > > > 232
> > > > > > > > lines of
> > > > > > > > Manifest?!
> > > > > > > 
> > > > > > > Pardon mine but do 'we' really need to read your useless
> > > > > > > comments
> > > > > > > everywhere, all the time and just get irritated for no benefit
> > > > > > > to
> > > > > > > Gentoo?
> > > > > > 
> > > > > > Perhaps I'm the one being ignorant here, but why are we lambasting
> > > > > > someone for seeking clarification about an unusual inclusion on a
> > > > > > review thread?>
> > > > > 
> > > > > I wasn't going to say anything, but I can't let this go by without
> > > > > commenting.
> > > > > 
> > > > > Sam is correct. Maybe the tone is a bit off, (and that is
> > > > > debatable),
> > > > > but this definitely can be seen as a legit question, regardless of
> > > > > other
> > > > > things Michael has posted.
> > > > 
> > > > Unfortunately it's not about a single issue or email. It's a
> > > > consistent pattern that multiple people have asked him to rein in over
> > > > a long period. :(
> > > 
> > > Without going into specifics, veremit and I have certainly had our
> > > 'differences of opinion' in the past; but I don't believe this is one
> > > of those occasions.
> > > 
> > > Calling out bad actors (not saying veremit is one, I just mean in the
> > > general sense) is an unfortunate but important task, but call them out
> > > on bad behaviour, not for what appears to be an impassioned but
> > > otherwise unremarkable query.
> > 
> > I agree with this 100 percent.  Not judging solely on the content of the
> > specific email in the thread does not allow people to grow and improve.
> > Are we all to be judged on our past behavior forever with no chance to
> > overcome past transgressions ?
> 
> That's not what's going on.

Maybe not; but that's what appears is going on.

mpagano is absolutely correct that people need an opportunity to engage 
positively if they're expected to change their behaviour in a positive way. At 
the same time, however, chastising someone without an apparent transgression 
both reinforces negative behaviour (such as the subsequent mails on that sub-
thread) *and* gives anyone not intimately familiar with that particular case 
the impression that people are ridiculed because they asked a relevant 
question (since there's no other context).

In this instance, at least two people (myself included) have drawn an 
impression that led them to voice their concern in some way (I'm unsure if 
mpagano was voicing concern or just agreeing with the general concept). Maybe 
we're the only ones. Maybe not.

I understand that you or others may have had a history of issues dealing with 
someone, perhaps to the point where even seeing their name puts a damper on 
your day. I'm sure there are people who feel the same about me. But let bad 
actors dig their own hole to fall in, even if you're certain beyond the shadow 
of a doubt that they're sitting in a darkened lair, twirling their moustache 
and saying things like "my evil plan is coming to fruition!"; because lashing 
out at an unrelated list post just looks like you're being an asshole.

-- 
Sam Jorna (wraeth)
GnuPG ID: 0xD6180C26



signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] [PATCH 3/3] app-admin/kube-bench: convert to go-module go.sum

2020-02-12 Thread Sam Jorna (wraeth)
On Thursday, 13 February 2020 5:40:46 AM AEDT Matt Turner wrote:
> On Wed, Feb 12, 2020 at 9:59 AM William Hubbs  wrote:
> > On Wed, Feb 12, 2020 at 06:54:19PM +1100, Sam Jorna (wraeth) wrote:
> > > On Monday, 10 February 2020 7:55:01 AM AEDT Michał Górny wrote:
> > > > On Sun, 2020-02-09 at 20:38 +, Michael 'veremitz' Everitt wrote:
> > > > > Hrm, pardon my ignorance, but do 'we' really need to review 232
> > > > > lines of
> > > > > Manifest?!
> > > > 
> > > > Pardon mine but do 'we' really need to read your useless comments
> > > > everywhere, all the time and just get irritated for no benefit to
> > > > Gentoo?
> > > 
> > > Perhaps I'm the one being ignorant here, but why are we lambasting
> > > someone for seeking clarification about an unusual inclusion on a
> > > review thread?> 
> > I wasn't going to say anything, but I can't let this go by without
> > commenting.
> > 
> > Sam is correct. Maybe the tone is a bit off, (and that is debatable),
> > but this definitely can be seen as a legit question, regardless of other
> > things Michael has posted.
> 
> Unfortunately it's not about a single issue or email. It's a
> consistent pattern that multiple people have asked him to rein in over
> a long period. :(

Without going into specifics, veremit and I have certainly had our 'differences 
of opinion' in the past; but I don't believe this is one of those occasions.

Calling out bad actors (not saying veremit is one, I just mean in the general 
sense) is an unfortunate but important task, but call them out on bad 
behaviour, not for what appears to be an impassioned but otherwise 
unremarkable query.

-- 
Sam Jorna (wraeth)
GnuPG ID: 0xD6180C26



signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] [PATCH 3/3] app-admin/kube-bench: convert to go-module go.sum

2020-02-11 Thread Sam Jorna (wraeth)
On Monday, 10 February 2020 7:55:01 AM AEDT Michał Górny wrote:
> On Sun, 2020-02-09 at 20:38 +, Michael 'veremitz' Everitt wrote:
> > Hrm, pardon my ignorance, but do 'we' really need to review 232 lines of
> > Manifest?!
> 
> Pardon mine but do 'we' really need to read your useless comments
> everywhere, all the time and just get irritated for no benefit to
> Gentoo?

Perhaps I'm the one being ignorant here, but why are we lambasting someone for 
seeking clarification about an unusual inclusion on a review thread?

-- 
Sam Jorna (wraeth)
GnuPG ID: 0xD6180C26







Re: [gentoo-dev] Gentoo-dev whitelisting

2018-05-14 Thread Sam Jorna
On Sun, May 13, 2018 at 02:57:19PM -0400, Alec Warner wrote:
>The whitelist automatically whitelists all @[2]gentoo.org addresses.

I think those who have editbugs would also be good candidates for
implicit whitelisting as well.

-- 
Sam Jorna
GnuPG Key: D6180C26


signature.asc
Description: PGP signature


Re: [gentoo-dev] Regarding the State of PaX in the tree

2018-04-15 Thread Sam Jorna
On Sun, Apr 15, 2018 at 08:04:43PM -0400, Anthony G. Basile wrote:
> The question then is, do we remove all this code?  As thing stands, its
> just lint that serves no current purpose, so removing it would clean
> things up.  The disadvantage is it would be a pita to ever restore it if
> we ever wanted it back.  While upstream doesn't provide their patch for
> free, some users/companies can purchase the grsecurity patches and still
> use a custom hardened-sources kernel with Gentoo.  But since we haven't
> been able to test the pax markings/custom patches in about a year, its
> hard to say how useful that code might still be.

Aside from potential breakage of pax-enabled systems due to lack of
(ability to perform) testing, is there any burden to keeping it?

Unless there's specific benefit to be had by removing the code, I'd be
inclined to keep it in-place to facilitate Gentoo users who do subscribe
to GRSecurity and use their patchset, granted with the disclaimer that
we can't test. Removing the machinery to support it would just drive
users to different platforms.

Alternatively, perhaps someone from GRSec could help maintain it, since
they would obviously be in a position to actually test. Though, I'm not
sure how viable it is to have someone maintaining functionality to
support a patchset that the majority of us cannot access...

-- 
Sam Jorna (wraeth)
GnuPG Key: D6180C26


signature.asc
Description: Digital signature


[gentoo-dev] Package up for grabs: media-tv/tvheadend

2018-04-09 Thread Sam Jorna
Hi All;

Due to not having as much time as I'd hoped, media-tv/tvheadend is being
dropped to maintainer-needed.

It has two open bugs[0,1], both of which have been reassigned.

[0]: https://bugs.gentoo.org/show_bug.cgi?id=633774
[1]: https://bugs.gentoo.org/show_bug.cgi?id=639958

Thanks;
-- 
Sam Jorna (wraeth)
GnuPG Key: D6180C26


signature.asc
Description: Digital signature


Re: [gentoo-dev] Prevent binary/non-compiled packages from binary package creation

2017-08-10 Thread Sam Jorna (wraeth)
On 11/08/17 03:08, William L. Thomson Jr. wrote:
> Lets go down this rabbit hole.

Let's not.

-- 
Sam Jorna (wraeth)
GnuPG ID: D6180C26



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Prevent binary/non-compiled packages from binary package creation

2017-08-09 Thread Sam Jorna (wraeth)
On 10/08/17 11:42, William L. Thomson Jr. wrote:
> On Thu, 10 Aug 2017 10:50:45 +1000
> "Sam Jorna (wraeth)" <wra...@gentoo.org> wrote:
> 
>> On 10/08/17 06:35, William L. Thomson Jr. wrote:
>>> FYI binpkgs have no hash. If someone did something malicious within
>>> the binhost to the binpkgs. You have no way of knowing. Yes the
>>> same can happen with ebuilds and manifest. But easy to sync portage
>>> and see if a manifest has changed.  
>>
>> This isn't exactly true - see ${PKGDIR}/Packages on the binhost, which
>> is a manifest of built packages and related metadata. Granted this is
>> created by the binhost, it does exist and contains SHA1 and MD5
>> hashes, as well as package size. In that sense it's no different to
>> how a package Manifest file works within a repository.
> 
> You are correct. I meant to say no verifiable hash. You can hash
> anything locally and claim it to be trustworthy. Thus mentioning
> syncing portage to compare manifest of ebuild/SRC_URI
> IMHO SRI_URI is more trustworthy than binhost, in the sense of
> verification. If  you have means to verify the binhost stuff it maybe
> more trustworthy. That is left to the admin.

This is no greater risk than syncing from a potentially compromised
mirror. You would use a mirror you trust and, similarly (perhaps even
more so) you would use a binhost you trust.

It does raise the idea of some form of signing of the Packages file,
similar to gpg-signed portage snapshots, but that's moving well beyond
the scope of this thread.

-- 
Sam Jorna (wraeth)
GnuPG ID: D6180C26



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Prevent binary/non-compiled packages from binary package creation

2017-08-09 Thread Sam Jorna (wraeth)
On 10/08/17 11:47, William L. Thomson Jr. wrote:
> On Thu, 10 Aug 2017 11:25:34 +1000
> "Sam Jorna (wraeth)" <wra...@gentoo.org> wrote:
> 
>> On 09/08/17 10:43, William L. Thomson Jr. wrote:
>>> Also your redistributing another's package
>>> in binary format which may not be legally allowed.  
>>
>> Just to clarify, I wasn't suggesting redistributing license-encumbered
>> packages. Since binary packages are managed by the system
>> administrator, not Gentoo (as a distro), it remains with the
>> administrator to adhere to any relevant license restrictions. Plus
>> the package manager can't tell if you're distributing binaries or not.
> 
> Sure, I was just pointing out that there maybe legal needs to prevent
> such. Unless someone wants to circumvent. Their call but not default.
> 
> The package manager knows about fetch restricted ebuilds. It should
> not to re-package that stuff. IMHO

Packaging a binary is not redistributing. Building binpkgs does not mean
you're going to redistribute them, and even if you were, the package
manager has no way of determining that aside from an
--im-going-to-redist-this-package option.

-- 
Sam Jorna (wraeth)
GnuPG ID: D6180C26



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Prevent binary/non-compiled packages from binary package creation

2017-08-09 Thread Sam Jorna (wraeth)
On 09/08/17 10:43, William L. Thomson Jr. wrote:
> Also your redistributing another's package
> in binary format which may not be legally allowed.

Just to clarify, I wasn't suggesting redistributing license-encumbered
packages. Since binary packages are managed by the system administrator,
not Gentoo (as a distro), it remains with the administrator to adhere to
any relevant license restrictions. Plus the package manager can't tell
if you're distributing binaries or not.

-- 
Sam Jorna (wraeth)
GnuPG ID: D6180C26



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Prevent binary/non-compiled packages from binary package creation

2017-08-09 Thread Sam Jorna (wraeth)
On 10/08/17 06:35, William L. Thomson Jr. wrote:
> FYI binpkgs have no hash. If someone did something malicious within the
> binhost to the binpkgs. You have no way of knowing. Yes the same can
> happen with ebuilds and manifest. But easy to sync portage and see if a
> manifest has changed.

This isn't exactly true - see ${PKGDIR}/Packages on the binhost, which
is a manifest of built packages and related metadata. Granted this is
created by the binhost, it does exist and contains SHA1 and MD5 hashes,
as well as package size. In that sense it's no different to how a
package Manifest file works within a repository.

-- 
Sam Jorna (wraeth)
GnuPG ID: D6180C26



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Prevent binary/non-compiled packages from binary package creation

2017-08-08 Thread Sam Jorna (wraeth)
On 09/08/17 10:43, William L. Thomson Jr. wrote:
> On Wed, 9 Aug 2017 10:29:40 +1000
> "Sam Jorna (wraeth)" <wra...@gentoo.org> wrote:
> 
>> On 09/08/17 04:20, William L. Thomson Jr. wrote:
>>> On Tue, 8 Aug 2017 19:32:48 +0200
>>> Kristian Fiskerstrand <k...@gentoo.org> wrote:  
>>>>  - You might be applying local patches through /etc/portage/patches
>>>> that are distributed to all clients  
>>>
>>> This might be the strongest reason. Though would only apply to stuff
>>> like say kernel sources. Not sure what patches could be applied to a
>>> binary ebuild, -bin. A patch would not effect src_install per my
>>> understanding.  
>>
>> There's also the fact that binpkgs may be manually installed exactly
>> as the package manager would have installed it, rather than extracting
>> whatever upstream supplies verbatim. 
> 
> What then is the benefit? If what is installed is the same from
> package manager or binpkg. Also your redistributing another's package
> in binary format which may not be legally allowed.

The difference is that how the package manager/ebuild installs the
package may be better suited to the environment than what upstream
expects (such as upstreams that install through a .run file)

>> This includes things like any wrappers, desktop files or symlinks
>> created by the ebuild, or other such downstream-isms.
> 
> If it was made via package manager. If it was made via quickpkg, it
> maybe different than if made by package manager.

Using quickpkg can create different binaries depending on your options,
but otherwise it should package any installed files as recorded by the
package manager - provided you use inclusive options, there should be no
appreciable difference as far as I'm aware.

-- 
Sam Jorna (wraeth)
GnuPG ID: D6180C26



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Prevent binary/non-compiled packages from binary package creation

2017-08-08 Thread Sam Jorna (wraeth)
On 09/08/17 04:20, William L. Thomson Jr. wrote:
> On Tue, 8 Aug 2017 19:32:48 +0200
> Kristian Fiskerstrand <k...@gentoo.org> wrote:
>>  - You might be applying local patches through /etc/portage/patches
>> that are distributed to all clients
> 
> This might be the strongest reason. Though would only apply to stuff
> like say kernel sources. Not sure what patches could be applied to a
> binary ebuild, -bin. A patch would not effect src_install per my
> understanding.

There's also the fact that binpkgs may be manually installed exactly as
the package manager would have installed it, rather than extracting
whatever upstream supplies verbatim. This includes things like any
wrappers, desktop files or symlinks created by the ebuild, or other such
downstream-isms.

-- 
Sam Jorna (wraeth)
GnuPG ID: D6180C26



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Allow variable refs in HOMEPAGE

2017-08-03 Thread Sam Jorna
On Thu, Aug 03, 2017 at 05:54:17PM +0200, Michał Górny wrote:
> d. no random ${PN} all over the install phase.

I think some qualification of "random ${PN} all over the install phase"
needs to be made - how random is random, are there any allowed
instances?

AFAIK with the exception of some system-wide resources (eg. themes,
icons, fonts) packages installing to locations such as /usr/share and
/usr/share/doc should install to directories named after the package (as
in after ${PN} or ${PF}). This means, when writing src_install(), that
use of those variables would be necessary. Should we always use ${PF}
instead, or are some instances of ${PN} reasonable?

-- 
Sam Jorna (wraeth)
GnuPG Key: D6180C26


signature.asc
Description: Digital signature


Re: [gentoo-dev] Changing PMS to Portage Manager Specification

2017-08-01 Thread Sam Jorna
On Tue, Aug 01, 2017 at 06:05:00PM -0400, William L. Thomson Jr. wrote:
> I think Gentoo council, developers, and portage developers should
> consider changing the PMS, to something like Portage Manager
> Specification, or Gentoo Portage Specification. Make it Gentoo
> and portage specific, and others adhere to that standard.

If you have a look at the Package Manager Specification project page[1]
it notes that this is how it worked previously and was decided against.

Personally, given that Gentoo is a meta-distribution, it makes more
sense to me to have an independent specification for things like this
and have the "default" package manager essentially be the reference
implementation of the specification. If there's a better way to do
something than what is defined in PMS, then perhaps suggest an update to
it.

[1] https://wiki.gentoo.org/wiki/Project:Package_Manager_Specification

-- 
Sam Jorna (wraeth)
GnuPG Key: D6180C26


signature.asc
Description: Digital signature


Re: [gentoo-dev] [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

2017-07-30 Thread Sam Jorna
On Sun, Jul 30, 2017 at 10:44:58PM -0400, William L. Thomson Jr. wrote:
> On Mon, 31 Jul 2017 10:28:31 +1000
> Sam Jorna <wra...@gentoo.org> wrote:
> >
> > Wouldn't it make more sense to make Gentoo *more* attractive to run in
> > corporate environments, rather than simply saying "We're not RHEL so
> > why bother"?
> 
> No disagreement. That has always been my interest. Though has not been
> others. It was in part why I became a trustee. For things like vendor
> certified hardware, looking into certifications,  events, and a whole
> lot more. But people rather lambast, insult, and stand in the way rather
> than either get out of the way or work with me.
> 
> It surely could happen without me but has not. I am definitely not
> against such happening. But it would require tremendous change and
> leadership. Which I do not see ever changing. I wish things were
> otherwise.
>  
> > People do use Gentoo in production environments, both personally and
> > professionally, even if it is those that have more investment in doing
> > so than the average IT Joe. By removing stable, we would be reducing
> > the potential arguments for the few who do want to use Gentoo in that
> > sort of environment. We would be becoming more of a niche distro.
> 
> Preaching to the choir. That is not why companies I know who ran Gentoo
> are leaving or left. One told me they did not want to be in the
> operating system business. Stable or not, there are fewer companies
> running Gentoo that were before. Due to other reasons that are not
> changing, culture, etc.
> 
> Companies that run it today I doubt would change if stable went away.
> If they left Gentoo, they have many reasons far beyond lack of a stable
> branch/tree.
> 
> > "Hey, lets try Gentoo - it's really configurable."
> > "What's their stable policy? How often does it break?"
> > "Stable? What's that?"
> 
> How about no foundation. Not even a legal entity. No certifications
> from vendors, nor for employees. No one to hire for official support.
> There are so many things far beyond anything having to do with a stable
> tree or not.

Sorry, I thought this thread was about whether to keep or discontinue
the separation between stable and testing branches.

-- 
Sam Jorna (wraeth)
GnuPG Key: D6180C26


signature.asc
Description: Digital signature


Re: [gentoo-dev] [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

2017-07-30 Thread Sam Jorna
On Fri, Jul 28, 2017 at 03:59:36PM -0400, William L. Thomson Jr. wrote:
> On Fri, 28 Jul 2017 23:10:35 +1000
> "Sam Jorna (wraeth)" <wra...@gentoo.org> wrote:
> 
> > On 28 July 2017 8:44:20 PM AEST, "Andreas K. Huettel"
> > <dilfri...@gentoo.org> wrote:
> >
> > >That's not feasible. It would kill off any semi-professional or
> > >professional 
> > >Gentoo use, where a minimum of stability is required. 
> > >
> > >(Try keeping ~10 machines on stable running without automation.
> > >That's already 
> > >quite some work. Now try the same with ~arch. Now imagine you're
> > >talking about 
> > >100 or 1000 machines.)  
> > 
> > And further, try proposing that to management - that you'll be
> > managing hosts on a platform that has no "stable" to speak of.
> 
> The professional/management argument is silly. Most avoid Gentoo.
> Most companies, want to be able to pay for support. Not to mention
> certifications and such for those they hire. None of which Gentoo has
> regardless of stability. Not to mention reputation...
> 
> Those that tend to run Gentoo have their own interest in such.  I have
> seen many migrate from rather than to Gentoo. Large companies, who's
> names we would all know. One of the few left is Meetup.com. They run
> Gentoo as do some others. Seems Tivo does stuff with Gentoo, Google,
> Sony, etc. Some tend to hire Gentoo devs...

Wouldn't it make more sense to make Gentoo *more* attractive to run in
corporate environments, rather than simply saying "We're not RHEL so why
bother"?

People do use Gentoo in production environments, both personally and
professionally, even if it is those that have more investment in doing
so than the average IT Joe. By removing stable, we would be reducing the
potential arguments for the few who do want to use Gentoo in that sort
of environment. We would be becoming more of a niche distro.

"Hey, lets try Gentoo - it's really configurable."
"What's their stable policy? How often does it break?"
"Stable? What's that?"

-- 
Sam Jorna (wraeth)
GnuPG Key: D6180C26


signature.asc
Description: Digital signature


Re: [gentoo-dev] [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

2017-07-28 Thread Sam Jorna (wraeth)


On 28 July 2017 8:44:20 PM AEST, "Andreas K. Huettel"  
wrote:
>Am Dienstag, 25. Juli 2017, 01:22:44 CEST schrieb Peter Stuge:
>> 
>> I hold a perhaps radical view: I would like to simply remove stable.
>> 
>> I continue to feel that maintaining two worlds (stable+unstable)
>> carries with it an unneccessary cost.
>> 
>
>That's not feasible. It would kill off any semi-professional or
>professional 
>Gentoo use, where a minimum of stability is required. 
>
>(Try keeping ~10 machines on stable running without automation. That's
>already 
>quite some work. Now try the same with ~arch. Now imagine you're
>talking about 
>100 or 1000 machines.)

And further, try proposing that to management - that you'll be managing hosts 
on a platform that has no "stable" to speak of.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.



Re: [gentoo-dev] Re: [RFC pre-GLEP] Gentoo Git Workflow

2017-07-26 Thread Sam Jorna
On Wed, Jul 26, 2017 at 07:05:47PM +0200, Kristian Fiskerstrand wrote:
> On 07/25/2017 02:28 PM, Michael Palimaka wrote:
> > Does a bug # really need to always be in the summary line? It can eat
> > valuable characters and tags which are pretty popular are equally valid IMO.
> 
> I would prefer the summary to be informative without having bug ID at
> all. Summary should describe the change  ,not only "fixes XXX", the bug
> reference belongs in body (tags)
> 
> -- 
> Kristian Fiskerstrand
> OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
> fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3

+1

Given the length restriction and the requirement to include
category/package, adding a bug reference doesn't leave much space for a
useful description.

-- 
Sam Jorna (wraeth)
GnuPG Key: D6180C26


signature.asc
Description: Digital signature


Re: [gentoo-dev] News item: systemd rootprefix migration

2017-07-13 Thread Sam Jorna (wraeth)
On 14/07/17 11:32, Mike Gilbert wrote:
> Please share your comments/questions on the proposed news item below.
> There is no immediate action required for most users, but it seems
> like a significant enough change to warrant a broadcast.
> 
> --
> 
> Title: systemd rootprefix migration
> Author: Mike Gilbert <flop...@gentoo.org>
> Posted: 2017-07-14
> Revision: 1
> News-Item-Format: 2.0
> Display-If-Installed: >=sys-apps/systemd-234
> 
> Starting with the 234 release, Gentoo's sys-apps/systemd package will
> be built with rootprefix=/. This means most of the included programs
> and system units will be installed under /lib/systemd instead of
> /usr/lib/systemd.
> 
> This change brings Gentoo into alignment with most other distros which
> still maintain a distiction between boot-critical programs in /, and
> less critical programs in /usr. This also means that users with a
> separate /usr filesystem will have an easier time booting if their
> initramfs should become corrupt or fail.
> 
> Symlinks are provided for /usr/lib/systemd/systemd and
> /usr/lib/systemd/systemd-shutdown to avoid breaking bootloader configs
> and to allow the system to be shutdown/rebooted without issue.

Will these symlinks be maintained indefinitely? Would it be worth
suggesting updating cmdline's to point to the new location rather than
the symlink?

> This change will be mostly transparent to typical users. You may notice
> that system units move from /usr/lib/system/system to
> /lib/system/system as you upgrade/re-install packages; this is normal.
> Units will function properly from both locations.

s:/lib/system::

> As always, if you run into problems, please report a bug.

Otherwise, lgtm.

-- 
Sam Jorna (wraeth)
GnuPG ID: D6180C26



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Auto adding packages to world was -> Sets vs Meta ebuilds

2017-07-12 Thread Sam Jorna
On 13/07/17 00:19, William L. Thomson Jr. wrote:
> It is YOUR comments that are funny, and going in a circular argument
> just to be argumentative and bringing nothing useful to the discussion.
> Which should be over now that bugs are filed

I'm not trying to be argumentative or antagonistic, I'm trying to
understand how your replacement warning differs from what's already
available and adds value.

>> '--depclean foo' is the user removing something they /are/ aware of
>> *if it's not a dependency*.
> 
> That does not work the same. It will not remove a package from world.

$ grep apg /var/lib/portage/world
app-admin/apg

$ emerge -C apg
 * This action can remove important packages! In order to be safer, use
 * `emerge -pv --depclean ` to check for reverse dependencies before
 * removing packages.

>>> Unmerging in: 5 4 3 2 1
>>> Unmerging (1 of 1) app-admin/apg-2.3.0b-r5...

...

$ grep apg /var/lib/portage/world
app-admin/apg

$ emerge -c apg

Calculating dependencies... done!
>>> Calculating removal order...

>>> Unmerging in: 5 4 3 2 1
>>> Unmerging (1 of 1) app-admin/apg-2.3.0b-r5...

> Clearly you are having a hard time grasping this very simple concept.
> I am done, reply if you like, but this thread is serious noise now...

Clearly, hence why I was trying to understand what difference your
proposal offered. But since we're moving on to serious things now, I
guess I /am/ done with this thread.

-- 
Sam Jorna (wraeth) <wra...@gentoo.org>
GnuPG Key: D6180C26



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Auto adding packages to world was -> Sets vs Meta ebuilds

2017-07-12 Thread Sam Jorna (wraeth)
On 12/07/17 16:06, William L. Thomson Jr. wrote:
> On Wed, 12 Jul 2017 15:49:14 +1000
> "Sam Jorna (wraeth)" <wra...@gentoo.org> wrote:
>>
>> I have trouble remembering what I ate for dinner last night, let alone
>> what I may or may not have merged a week, month or year ago, or what
>> options I used when merging it.
> 
> And if you used --oneshot, it is also saying you are not maintaining
> your system or ever running --depclean. Since anything you installed
> via --oneshot would be removed with --depclean.

If my concern in removing a package was whether it was a dependency, it
would make more sense to use --depclean in the first place. If I'm using
--unmerge, it's because I want the package unmerged regardless.

>>> What harm does a warning do?  
>>
>> Depends on the user, which can't really be avoided, but means that
>> warnings should be clear and meaningful, otherwise they become
>> background noise.
> 
> The example in the bug is as clear is it can get.
> 
> !!! 'sys-devel/gcc' is a dependency of another package on your system
> or
> !!! 'sys-devel/gcc' is a package not found in system profile or world
> or
> !!! 'sys-devel/gcc' may not have been installed by you
> or
> some other message
> 
>> Such as:
>>
>> emerge --unmerge dev-python/keyring
>>  * This action can remove important packages! In order to be safer,
>> use
>>  * `emerge -pv --depclean ` to check for reverse dependencies
>> before
>>  * removing packages.
> 
> Didn't you just say something about meaningful output vs noise? That is
> always outputted and ends up becoming what you are saying. Funny!

And your suggesting adding more noise to it... Funny, I know.

>>>> or may have been installed as an orphan but is now a
>>>> dependency.   
>>>
>>> Now being a dependency the warning would be valid.  
>>
>> "Sometimes being accurate" is not the most noble of goals.
> 
> What?
> 
>> So the idea is to duplicate the functionality of '--depclean
>> 
> 
> NO!!!
> 
> emerge --depclean gcc 
> 
> is not the same as 
> 
> emerge --umerge gcc
> 
> Depclean the user is cleaning things they are not aware of. Unmerge the
> user is removing something directly. They may think they do not need it.

No.

'--depclean' is the user removing things they are not aware of.

'--depclean foo' is the user removing something they /are/ aware of *if
it's not a dependency*.

'--unmerge foo' is the user explicitly removing something regardless of
whether it's a dependency.

Therefore, '--depclean foo' can be seen as a safe '--unmerge foo' which,
from what I understand, is what you're aiming for.

>> ' without actually checking to see if the package is a
>> dependency,
> 
> Word it how ever. If the user did not install, they should be warned on
> removal of a package they did not install.

That's what the current warning to --unmerge says - removing packages
can break things, so please make sure this isn't a dependency and you
really want to remove this.

>> only whether it is listed in a set; or to check if it's a
>> dependency of /something/ and, if so, redirect the user to the
>> command they should be using anyway?
> 
> You mean like emerge --unmerge does already that you pointed out
> above. After mentioning useful messages vs noise.  Again funny!

How does replacing one warning with another warning that may or may not
be meaningful ("maybe it's a dep, maybe it isn't" as opposed to "this
can be dangerous, please make sure you know what you're doing") make it
any better?

-- 
Sam Jorna (wraeth)
GnuPG ID: D6180C26



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Auto adding packages to world was -> Sets vs Meta ebuilds

2017-07-11 Thread Sam Jorna (wraeth)
On 12/07/17 15:14, William L. Thomson Jr. wrote:
> Is it in system?
> Is it in a set?
> Is it in world?
> If no to all, its a dep, warn!

All this says is whether the package was explicitly installed and
recorded in world, or is a member of @system. The target package may or
may not be a dependency, may or may not have been --oneshot'd.

It may have been installed as a dependency but the requiring package was
removed, or may have been installed as an orphan but is now a
dependency. Assuming that if it's not in a set it must be a dependency
is incorrect and misleading.

-- 
Sam Jorna (wraeth)
GnuPG ID: D6180C26



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Auto adding packages to world was -> Sets vs Meta ebuilds

2017-07-11 Thread Sam Jorna (wraeth)
On 12/07/17 14:43, William L. Thomson Jr. wrote:
>>> It is not the same as -C, which is remove a package directly.
>>>
>>>  --unmerge (-C)  
>> Correct, --unmerge will remove a package without considering
>> dependencies (give or take a few special cases). It is usually (or, at
>> least, should generally be) reserved for those taking a hammer to a
>> problem or with a particular desire to recover a broken system.
>>
>> Again, it's doing exactly what it's supposed to - removing a package
>> you've told it to remove (unless it's one of the few
>> almost-always-critical packages).
> Yes and if you see bug. All I am saying is adding warnings when someone
> goes to remove a dependency. Since a dependency IS a critical package :)
> 
> Add warning message when -C/--unmerge a dependency like system,
> profile, and set files.
> https://bugs.gentoo.org/show_bug.cgi?id=624630

My point was that --unmerge is not intended to be dependency-aware.
--depclean is. As far as I can tell, that is the point others have been
trying to make as well, when pointing out the differences between -c and -C.

-- 
Sam Jorna (wraeth)
GnuPG ID: D6180C26



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Auto adding packages to world was -> Sets vs Meta ebuilds

2017-07-11 Thread Sam Jorna (wraeth)
On 12/07/17 10:05, William L. Thomson Jr. wrote:
> I should have caught that sooner. -c does not remove a package, it just
> removes its deps.
> 
> -c == --depclean.

--depclean is doing exactly what it is supposed to. If called with no
arguments, it searches for any unneeded dependencies and removes them,
however if called with a package as an argument, it will remove that
package *if it is not a dependency of another package*. Reporting
"nothing to remove" is precisely what it's supposed to do, and using
--verbose will tell you what is depending on the package.

To be clear, running '--depclean foo' does not remove dependencies of
foo, it removes foo provided it is not a dependency. It can be seen as a
dependency-aware (and thus, generally safe) --unmerge.

Making --depclean _always_ give you more information should just be a
case of adding --verbose to EMERGE_DEFAULT_OPTS.

> It is not the same as -C, which is remove a package directly.
> 
>  --unmerge (-C)

Correct, --unmerge will remove a package without considering
dependencies (give or take a few special cases). It is usually (or, at
least, should generally be) reserved for those taking a hammer to a
problem or with a particular desire to recover a broken system.

Again, it's doing exactly what it's supposed to - removing a package
you've told it to remove (unless it's one of the few
almost-always-critical packages).

-- 
Sam Jorna (wraeth)
GnuPG ID: D6180C26



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Re: taking a break from arches stabilization

2017-07-11 Thread Sam Jorna (wraeth)
On 12/07/17 03:16, William Hubbs wrote:
> On Tue, Jul 11, 2017 at 11:47:32PM +1000, Michael Palimaka wrote:
>> On 07/11/2017 11:06 PM, Rich Freeman wrote:
>>> On Tue, Jul 11, 2017 at 8:59 AM, Michael Palimaka <kensing...@gentoo.org> 
>>> wrote:
>>>> On 07/11/2017 09:29 AM, Andrew Savchenko wrote:
>>>>>
>>>>> Even if such stabilization is allowed, there are unanswered
>>>>> questions here:
>>>>> - is following seciton 4.1 from wg recommendations is sufficient?
>>>>> - should developer test each stabilization candidate on an
>>>>> up-to-date stable setup?
>>>>
>>>> The guidelines from that document are ripped straight out of the
>>>> devmanual and are a good starting point but rather generic. You can find
>>>> some more detailed suggestions on things to consider while testing on
>>>> the wiki: https://wiki.gentoo.org/wiki/Package_testing
>>>>
>>>
>>> I think that in practice arch teams don't do have the stuff on that
>>> wiki page.  Maybe some people do, but back when I was an amd64 AT I
>>> don't think anybody went testing multiple USE combinations for a
>>> typical package.
>>
>> Everything on that page is deliberately a suggestion only, and not
>> necessarily specific to stabilisation testing.
>>
>> In the end, we've never been able to reach any consensus on what exactly
>> an arch tester should do. Personally, I think we should just switch to
>> fully-automated, build-only testing for stabilistions unless the
>> maintainer opts otherwise (something that largely happens in practice
>> already). The main risk of breakage of a package moving from testing to
>> stable is always at build time anyway.
> 
> I would not be opposed to this. As a maintainer, I am as guilty as the
> next guy of not filing stable requests or not stabilizing packages.

As the next guy, I also +1 this.

As is often explained in #gentoo, "stable" and "testing" for upstream
have a different meaning to "stable" and "testing" for Gentoo - in fact,
beyond ensuring it builds, any testing performed by a downstream distro
is additional testing to what upstream have already released.

I can understand the concern with automatically stabilising a package
that has some flaw affecting users, but the two things i see are that
upstream have already released said flawed package, and Gentoo simply
doesn't have the manpower to perform comprehensive runtime testing of
all packages.

If a maintainer is aware of a significant issue with a package that
should prevent it from being marked as stable, then a bug should be
filed acting as a block to the automated stabilisation. Users aware of
an issue are just as likely to file a bug as well, also preventing
stabilisation of packages with some known issue. Therefore packages with
known issues don't get stabilised automatically.

Similarly, if the maintainer believes more comprehensive testing should
be done (eg. for critical base-system packages) a note could be made
somewhere of that requirement (metadata.xml?), meaning significantly
reduced workload for people like ago (if the maintainer doesn't
stabilise it beforehand).
-- 
Sam Jorna (wraeth)
GnuPG ID: D6180C26



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Fixing elasticsearch maintainer

2017-05-21 Thread Sam Jorna
On Mon, May 22, 2017 at 07:47:19AM +0200, Michał Górny wrote:
> On pon, 2017-05-22 at 11:52 +1000, Sam Jorna wrote:
> > On 18/05/17 02:38, Patrick Lauer wrote:
> > > Since proxy-maint refuses to be removed from packages (especially since 
> > > they
> > > were unconditionally added to all packages with a non-gentoo-dev 
> > > maintainer in
> > > metadata) they are the de facto maintainers, and overrule everything else.
> > 
> > Just to clarify, the Proxy Maintainers project is not required to be 
> > added to all packages maintained by non-Gentoo maintainers. If a Gentoo 
> > developer is willing to work with and proxy commits for maintainer(s) 
> > without commit access, Proxy Maintainers are happy to be removed. There 
> > are several metadata.xml's in the tree with examples, including a few 
> > for which you are one of the maintainers.
> > 
> 
> Just to clarify, this works only if the developer and proxied maintainer
> agree on the terms. It's not 'I remove proxy-maint, and now force you to
> work on my terms that do not fit you because reasons'.

That's why I used the phrase "work with".

-- 
Sam Jorna (wraeth)
GnuPG Key: D6180C26


signature.asc
Description: Digital signature


Re: [gentoo-dev] Fixing elasticsearch maintainer

2017-05-21 Thread Sam Jorna
On Mon, May 22, 2017 at 06:12:54AM +0200, Patrick Lauer wrote:
> On 05/22/2017 03:52 AM, Sam Jorna wrote:
> > On 18/05/17 02:38, Patrick Lauer wrote:
> >> Since proxy-maint refuses to be removed from packages (especially since 
> >> they
> >> were unconditionally added to all packages with a non-gentoo-dev 
> >> maintainer in
> >> metadata) they are the de facto maintainers, and overrule everything else.
> >
> > Just to clarify, the Proxy Maintainers project is not required to be
> > added to all packages maintained by non-Gentoo maintainers. If a Gentoo
> > developer is willing to work with and proxy commits for maintainer(s)
> > without commit access, Proxy Maintainers are happy to be removed. There
> > are several metadata.xml's in the tree with examples, including a few
> > for which you are one of the maintainers.
> >
> That's nice.
> 
> Could proxy-maint as a team maybe try to agree on such things so that 
> everyone is on the same page? It's a tiny bit annoying when the actions 
> of some contradict the suggested rules of others, while appearing as a 
> single team to the outside ...

I suspect it's likely a misunderstanding - without notification, all 
anyone from Proxy Maint sees is proxy-maint being removed. An E-Mail to 
proxy-maint@g.o explaining that you've spoken to and are taking over 
proxying of the package would make sure we know what's happening.

-- 
Sam Jorna (wraeth)
GnuPG Key: D6180C26


signature.asc
Description: Digital signature


Re: [gentoo-dev] Fixing elasticsearch maintainer

2017-05-21 Thread Sam Jorna
On 18/05/17 02:38, Patrick Lauer wrote:
> Since proxy-maint refuses to be removed from packages (especially since they
> were unconditionally added to all packages with a non-gentoo-dev maintainer in
> metadata) they are the de facto maintainers, and overrule everything else.

Just to clarify, the Proxy Maintainers project is not required to be 
added to all packages maintained by non-Gentoo maintainers. If a Gentoo 
developer is willing to work with and proxy commits for maintainer(s) 
without commit access, Proxy Maintainers are happy to be removed. There 
are several metadata.xml's in the tree with examples, including a few 
for which you are one of the maintainers.

-- 
Sam Jorna (wraeth)
GnuPG Key: D6180C26


signature.asc
Description: Digital signature


Re: [gentoo-dev] Guidelines for IUSE defaults

2017-02-07 Thread Sam Jorna
On Tue, Feb 07, 2017 at 09:11:20PM -0500, Rich Freeman wrote:
> On Tue, Feb 7, 2017 at 8:24 PM, Sam Jorna <wra...@gentoo.org> wrote:
> > On Tue, Feb 07, 2017 at 12:00:51PM -0500, Rich Freeman wrote:
> >
> >> On Tue, Feb 7, 2017 at 10:14 AM, Ian Stakenvicius <a...@gentoo.org> wrote:
> >
> >> > OK, can we all decide out of this thread, that if any package is
> >> > enabling critical functionality via IUSE-defaults (or rather, IUSE
> >> > defaults alone), that this be addressed through package.use.force in
> >> > profiles OR through removal of the flag?
> >>
> >> No.
> >
> > Can this be justified a little more?
> >
> > If a package is broken when a given flag is disabled, why is it not
> > acceptable to not provide the flag?
> 
> Perhaps the issue is the definition of "critical functionality."
> 
> I may have interpreted it differently than intended.
> 
> If setting a flag one way or the other results in a package that has
> no useful purpose then I certainly agree that this shouldn't be a flag
> in the first place.  When certain combinations result in
> non-functional packages these should be caught as well (via
> REQUIRED_USE), though in really complex packages with many flags this
> may sometimes be difficult to spot.
> 
> On the other hand, I believe it should be acceptable to use IUSE
> defaults to configure a package to provide an ideal experience for the
> typical user of the package, or align with upstream.  Non-upstream
> patches that aren't related to integration are pushing it, but merely
> providing an upstream-like default experience should be the goal for
> anybody who doesn't override this one way or the other.
> 
> My brevity wasn't intended to be rude.  I've just posted extensively
> enough in this thread and didn't want to just re-iterate my previous
> emails, and so so above for clarity.

Ah, this makes sense to me - IUSE defaults being a kind of soft "new to 
Gentoo" or "minimal effort for common usage" setup, REQUIRED_USE to 
prevent bad combinations, and package.use.force for known breakages with 
individual flags.

Thanks for the clarification.

-- 
Sam Jorna (wraeth)
GnuPG Key: D6180C26


signature.asc
Description: Digital signature


Re: [gentoo-dev] Guidelines for IUSE defaults

2017-02-07 Thread Sam Jorna
On Tue, Feb 07, 2017 at 12:00:51PM -0500, Rich Freeman wrote:
> On Tue, Feb 7, 2017 at 10:14 AM, Ian Stakenvicius <a...@gentoo.org> wrote:
> > On 07/02/17 08:27 AM, Michael Orlitzky wrote:
> >>
> >> The thread wasn't about discouraging IUSE defaults, rather to decide
> >> when they are appropriate. You cannot omit "pkginternal" from USE_ORDER,
> >> because you will break all of the packages whose defaults are either
> >> critical to the package, or prevent a REQUIRED_USE conflict.
> >>
> >
> > OK, can we all decide out of this thread, that if any package is
> > enabling critical functionality via IUSE-defaults (or rather, IUSE
> > defaults alone), that this be addressed through package.use.force in
> > profiles OR through removal of the flag?
> 
> No.

Can this be justified a little more?

If a package is broken when a given flag is disabled, why is it not 
acceptable to not provide the flag?

If the flag is still provided for the sake of user choice, why is it 
unacceptable to force it through package.use.force allowing the majority 
of users to not need to worry, and letting advanced users break their 
egg in their quest for an omelette?

How is this different (for example, not pointing fingers) from 
dev-lang/python[threads] being forced because it's broken without it 
(therefore critical functionality)?

Disclaimer: not trying to be argumentative, just trying understand the 
arguments. :)

-- 
Sam Jorna (wraeth)
GnuPG Key: D6180C26


signature.asc
Description: Digital signature


Re: [gentoo-dev] Guidelines for IUSE defaults

2017-02-02 Thread Sam Jorna
On Thu, Feb 02, 2017 at 09:26:20PM -0500, Michael Orlitzky wrote:
> On 02/02/2017 09:22 PM, Sam Jorna wrote:
> > 
> > Also, how would this work with local USE flags as opposed to global 
> > flags? Would they be acceptable to have IUSE defaults?
> > 
> 
> Exactly the same way as global flags: drop an entry in the desktop
> profile's package.use.

I can understand the reasoning behind using this, but it seems 
unnecessarily laborious to do so - as I said, it would mean playing 
around with profiles whenever changing a package for which flags are 
defaulted.

Perhaps some standardisation of what warrants an IUSE default could 
help, otherwise you might end up with the same situation, just relocated 
into the profiles namespace instead of the package.

Having said that, I'm not strongly opposed, just trying to sound out 
pros/cons/gotcha's.

-- 
Sam Jorna (wraeth)
GnuPG Key: D6180C26


signature.asc
Description: Digital signature


Re: [gentoo-dev] Guidelines for IUSE defaults

2017-02-02 Thread Sam Jorna
On Thu, Feb 02, 2017 at 09:06:33PM -0500, Michael Orlitzky wrote:
> On 02/02/2017 09:00 PM, Sam Jorna wrote:
> >
> > Consider: a new user, coming from Ubuntu or Fedora or Windows, starts 
> > building their system. They start installing packages they want, only to 
> > find that half of the package isn't there because no USE flags were 
> > enabled. They have to enable these flags for almost every package they 
> > want because there's no defaults, you must manually specify anything 
> > that's not a direct dependency or forced by profile.
> 
> Desktop profile!! We have a desktop profile!!! Why is the base
> profile a better location for new-user-with-a-desktop defaults than the
> **desktop** profile?
> 
> I'm going crazy. I give up.

That would also mean two commits when adding or removing a package with 
any defaults - one for profiles/, one for the package itself - as well 
as when flags change for a given package.

Also, how would this work with local USE flags as opposed to global 
flags? Would they be acceptable to have IUSE defaults?

-- 
Sam Jorna (wraeth)
GnuPG Key: D6180C26


signature.asc
Description: Digital signature


Re: [gentoo-dev] Guidelines for IUSE defaults

2017-02-02 Thread Sam Jorna
On Thu, Feb 02, 2017 at 09:11:26AM -0500, Michael Orlitzky wrote:
> IUSE defaults are used in a few different ways:
> 
>   1 To ensure that critical functionality is enabled.
> 
> * Example: force the "unix" module for apache.

Why provide a flag for something that is required anyway? And if it's a 
case of "you *really* should have this, but if you want to break it, 
here's how", then why not put it in package.use.force instead? An IUSE 
default for this doesn't make sense.

>   2 To avoid an unsatisfied REQUIRED_USE by default.
> 
> * Example: having a non-empty RUBY_TARGETS by default.

This seems reasonable - two mutually exclusive options, of which one is 
preferred. That being said, I do see it as akin to 3 and 4.

>   3 To make Gentoo defaults the upstream defaults.
> 
> * Example: right now the defaults for dev-lang/php build
>   you a "normal" PHP installation.
> 
>   4 To make the default build agree with the maintainer's personal
> preferences.
> 

The way I see it, IUSE defaults are provided by the maintainer as a way 
to offer a package with "what you probably would want enabled" to 
facilitate users who either aren't interested in ricing their system or 
aren't experienced enough with Gentoo to tweak all the flags.

Consider: a new user, coming from Ubuntu or Fedora or Windows, starts 
building their system. They start installing packages they want, only to 
find that half of the package isn't there because no USE flags were 
enabled. They have to enable these flags for almost every package they 
want because there's no defaults, you must manually specify anything 
that's not a direct dependency or forced by profile.

Conversely, users who want a minimal system are ones who are much more 
likely to inspect emerge's output before committing to a build. They are 
likely more willing to tweak the flags to have the system provide only 
the things they want. Often they'll have USE="-*", accepting that 
they'll probably have to enabled a bunch of things to get their desired 
functionality.

IUSE defaults are a convenience for those either inexperienced with 
Gentoo or uncaring of cruft. Certainly maintainers should put some 
forethought into which flags they default to enabled, but I see the end 
goal as helping the users who need the help most (not to discount more 
advanced users, but they are more likely to *want* to tweak than one for 
whom this is their first CLI).

That's my two cents, at least.

-- 
Sam Jorna (wraeth)
GnuPG Key: D6180C26


signature.asc
Description: Digital signature


Re: Why lastrite when it works? (Was: Re: [gentoo-dev] Packages up for grabs due to retirement)

2017-01-17 Thread Sam Jorna
On Tue, Jan 17, 2017 at 04:45:39AM -0800, Daniel Campbell wrote:
> On 01/06/2017 12:46 PM, William L. Thomson Jr. wrote:
> > On Friday, January 6, 2017 9:14:54 AM EST Alec Warner wrote:
> >>
> >> The nice thing about ::graveyard or similar is that its a clear demarcation
> >> between maintained (in tree) and unmaintained (graveyard.) It also means
> >> that people doing actual maintenance work can basically ignore the
> >> graveyard as a matter of policy. The ebuilds are archived there (for users)
> >> but since they are unmaintained they may not work correctly.
> > 
> > This is what the Java team used to do. There was a java-graveyard-overlay. 
> > I 
> > do not believe any package ever moved there came back into the tree. It did 
> > result in a pretty messed up overlay, but makes it a user problem.
> > 
> > At the same time, something could always be restored from VC. Not like 
> > removal 
> > is removing all history and traces. Thus not sure such overlay is really 
> > even 
> > beneficial. Using it could cause lots of problems if they just care about 1 
> > package or a few.
> > 
> 
> There's a nice trick around that, actually: let's assume the overlay is
> called "foo-overlay".
> 
> In package.mask:
> 
> */*::foo-overlay
> 
> will mask all packages in the overlay. You can then add packages to
> package.unmask:
> 
> pkg-cat/foobar::foo-overlay
> 
> That should alleviate most issues, though it can make dependencies a
> PITA if those deps are also in the overlay. In that case, emerge should
> yell at you and suggest adding lines to package.unmask.

Another option would be to set the priority of the overlay to -1001 (one
less than gentoo.git) and explicitly emerge the package from the
overlay:

emerge -a pkg-cat/foobar::foo-overlay

Dependencies will by default be drawn from gentoo.git (if it has equal
or better version(s)), and overlay-only dependencies won't need to be
explicitly unmasked.

You may end up with gentoo.git-provided packages coming from the overlay
if they have newer versions, though when talking about graveyard, that
shouldn't be an issue.

-- 
Sam Jorna (wraeth)
GPG ID: 0xD6180C26



signature.asc
Description: Digital signature


Re: [gentoo-dev] Stats: Gentoo developer commit timeline

2017-01-16 Thread Sam Jorna
On Mon, Jan 16, 2017 at 10:35:30AM +0100, Michał Górny wrote:
> Just a quick side project we've done a while ago. It's a timeline of
> developer commit activity [1]. Code for data processing in [2]. I did
> the data, Amynka prepared a nice JS to graph it.

Nice work! Thanks, both mgorny and Amynka!

-- 
Sam Jorna (wraeth)
GnuPG Key: D6180C26


signature.asc
Description: Digital signature


Re: [gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2016-12-18 23:59 UTC

2016-12-18 Thread Sam Jorna
On Sun, Dec 18, 2016 at 07:23:25PM -0500, Michael Orlitzky wrote:
> On 12/18/2016 07:05 PM, Robin H. Johnson wrote:
> > 
> > Additions:
> > ...
> > dev-php/ca-bundle 20161124-07:43 mjo 7597666
> > dev-php/cli-prompt20161124-07:21 mjo d3bd351
> > dev-php/composer  20161124-08:09 mjo d273046
> > dev-php/fedora-autoloader 20161123-15:49 mjo 38e69d1
> > dev-php/jsonlint  20161124-07:29 mjo 033f5d3
> > dev-php/json-schema   20161124-07:24 mjo 79a2aeb
> > dev-php/phar-utils20161124-07:18 mjo ea07d00
> > dev-php/psr-log   20161123-15:55 mjo 6c369a5
> > dev-php/semver20161124-07:40 mjo 0bccd72
> > dev-php/spdx-licenses 20161124-07:33 mjo a780206
> > dev-php/symfony-config20161124-07:50 mjo d10d7e2
> > dev-php/symfony-console   20161124-08:03 mjo bc36d09
> > dev-php/symfony-dependency-injection  20161124-07:57 mjo 9963181
> > dev-php/symfony-event-dispatcher  20161124-07:59 mjo 2283ea2
> > dev-php/symfony-filesystem20161123-18:29 mjo bdc6673
> > dev-php/symfony-finder20161123-18:53 mjo 57de338
> > dev-php/symfony-process   20161123-18:15 mjo a7733e1
> > dev-php/symfony-yaml  20161124-07:54 mjo e751ace
> 
> 
> These were all added by a user, Guillaume Seren. I only merged the pull
> request. We recently had a thread, "Please retain authorship of
> contributed patches," in light of which it might be cool if we could get
> the author's name listed above rather than the committer (when the
> author is not a developer).

+1

I imagine it shouldn't be too hard to get the Author attribute of a 
given commit rather than Committer.

-- 
Sam Jorna (wraeth)
GnuPG Key: D6180C26


signature.asc
Description: Digital signature


Re: [gentoo-dev] gpg: signing failed: Inappropriate ioctl for device

2016-12-13 Thread Sam Jorna
On Mon, Dec 12, 2016 at 02:35:28PM +1100, Sam Jorna wrote:
> On Mon, Dec 12, 2016 at 09:34:21AM +0700, gro...@gentoo.org wrote:
> > On Sun, 11 Dec 2016, Kristian Fiskerstrand wrote:
> > > On 12/11/2016 03:13 PM, gro...@gentoo.org wrote:
> > >> gpg: signing failed: Inappropriate ioctl for device
> > > this might indicate a want for export GPG_TTY=$(tty)
> > I don't understand what has really happened. I removed my last commit, an 
> > attempt to commit it again failed with gpg: signing failed. Then I logged 
> > out of the box on which I have the git tree (I log in this box via ssh), 
> > and logged in again. After that the commit succeeded.
> 
> I was also getting some odd issues with commit signing, though it seemed 
> to settle for me when I switched to pinentry-curses (since I use 
> awesome), so I figured it was probably a local issue. Perhaps there's a 
> wider problem here?

If anyone else is getting this, it seems to be resolved by exporting 
GPG_TTY=$(tty) either immediately before attempting to sign or in your 
shell ~/.*rc file.

-- 
Sam Jorna (wraeth)
GnuPG Key: D6180C26


signature.asc
Description: Digital signature


Re: [gentoo-dev] gpg: signing failed: Inappropriate ioctl for device

2016-12-11 Thread Sam Jorna
On Mon, Dec 12, 2016 at 09:34:21AM +0700, gro...@gentoo.org wrote:
> On Sun, 11 Dec 2016, Kristian Fiskerstrand wrote:
> > On 12/11/2016 03:13 PM, gro...@gentoo.org wrote:
> >> gpg: signing failed: Inappropriate ioctl for device
> > this might indicate a want for export GPG_TTY=$(tty)
> I don't understand what has really happened. I removed my last commit, an 
> attempt to commit it again failed with gpg: signing failed. Then I logged 
> out of the box on which I have the git tree (I log in this box via ssh), 
> and logged in again. After that the commit succeeded.

I was also getting some odd issues with commit signing, though it seemed 
to settle for me when I switched to pinentry-curses (since I use 
awesome), so I figured it was probably a local issue. Perhaps there's a 
wider problem here?

-- 
Sam Jorna (wraeth)
GnuPG Key: D6180C26


signature.asc
Description: Digital signature


Re: [gentoo-dev] Cross Post due to technical component - Thanks for all the fish

2016-12-06 Thread Sam Jorna
On Tue, Dec 06, 2016 at 09:37:55PM -0500, james wrote:
> >> I subscribe on 6/23/2016::
> >>
> >> From:: gentoo-proxy-maint+h...@lists.gentoo.org
> >>
> >
> > This is the correct address and as it noted, you should get a
> > confirmation/welcome email when you've successfully subscribed. Did you
> > get this?
> 
> YES, back on 6/23/2016 It never functioned correctly for me.
> I think everyone switched to the new list, which I never heard about.
> 
> 
> And here is the reply::
> 
> gentoo-proxy-maint+confsub-nomail-75dc5ad5188e6314-garftd=verizon@lists.gentoo.org
> 
> on 6/23/2016 10:21am
> 
> 
> 
> So do I need to apply again, or an I on the list? I went (nomail) cause 
> at the time reading via gmane.org was working. Perhaps I should just 
> change the status to receive the mails?   I can test post, if that is 
> helpful?

I can see you've posted something to the list just now.

If you need to reconfigure your settings so it mails you, send a mail to 
gentoo-proxy-maint+h...@lists.gentoo.org to see [0]options.

[0] https://www.gentoo.org/get-involved/mailing-lists/instructions.html

-- 
Sam Jorna (wraeth)
GnuPG Key: D6180C26


signature.asc
Description: Digital signature


Re: [gentoo-dev] Cross Post due to technical component - Thanks for all the fish

2016-12-06 Thread Sam Jorna
On Tue, Dec 06, 2016 at 09:44:12PM -0500, james wrote:
> On 12/06/2016 09:09 PM, M. J. Everitt wrote:
> 
> >> James
> >>
> > With the creation of the Mentors project
> > (https://wiki.gentoo.org/wiki/Project:Mentors) a bit of clarification
> > has occurred to help prospective developers outside the IRC and/or
> > proxy-maintainers project).
> 
> Am I to understand that the 'Mentors' are a pathway to gaining 
> gentoo-dev status (still the same requirements) but I do not have to use
> IRC to communicate with whomever?

In order to become a Gentoo developer you do need a mentor[0]. If 
instead you're only looking to proxy-maintain a package(s), you can work 
either through the Proxy Maintainers project or directly with a 
developer (if they're the maintainer).

> If so; Halaluyah! and count me in. I hate irc, with a passion, just so 
> you know.

How you communicate with your mentor is up to you and your mentor. Going 
through the recruitment [0]process does require a review session which, 
as far as I know, is only held on IRC, but otherwise it's up to you to 
organise what medium you use.

> > The Recruiters project page contains links
> > to the current quizzes (linked therein).
> >
> > hth.
> 
> 
> 
> On this page, the string 'quiz' occurs (3) times. I find no links to the 
> current quizes?
> 
> Did I miss something?

The links to the quizzes are [1]here.

[0] 
https://wiki.gentoo.org/wiki/Project:Recruiters#What_does_the_recruitment_process_involve.3F
[1] https://wiki.gentoo.org/wiki/Project:Recruiters#Current_quizzes

-- 
Sam Jorna (wraeth)
GnuPG Key: D6180C26


signature.asc
Description: Digital signature


Re: [gentoo-dev] Cross Post due to technical component - Thanks for all the fish

2016-12-06 Thread Sam Jorna
On Wed, Dec 07, 2016 at 01:17:54PM +1100, Sam Jorna wrote:
> have a look at the new [0]Mentors project, or even send a mail to -dev 

I forgot the link, sorry:

[0] https://wiki.gentoo.org/wiki/Project:Mentors

-- 
Sam Jorna (wraeth)
GnuPG Key: D6180C26


signature.asc
Description: Digital signature


Re: [gentoo-dev] Cross Post due to technical component - Thanks for all the fish

2016-12-06 Thread Sam Jorna
On Tue, Dec 06, 2016 at 08:59:11PM -0500, james wrote:
> On 12/06/2016 07:29 PM, Robin H. Johnson wrote:
> > On Tue, Dec 06, 2016 at 01:13:12PM -0500, james wrote:
> >> A while back, we we were promised an email channel for gentoo-proxy
> >> folks that did not get on well with IRC. It never materialized,
> > The mail alias proxy-ma...@gentoo.org (same alias as proxy-maintainers@)
> > has 22 people on it. It was created 2013/09/26.
> >
> > The list gentoo-proxy-ma...@lists.gentoo.org was created 2016/05/29.
> > I don't see much usage of it, nobody has emailed since August.
> > https://archives.gentoo.org/gentoo-proxy-maint/
> >
> > The request for it was filed and tracked here:
> > https://bugs.gentoo.org/show_bug.cgi?id=581370
> >
> > How exactly is that never materialized?
> >
> 
> 
> I subscribe on 6/23/2016::
> 
> From:: gentoo-proxy-maint+h...@lists.gentoo.org
> 

This is the correct address and as it noted, you should get a 
confirmation/welcome email when you've successfully subscribed. Did you 
get this?

Keep in mind, also, that as Robin noted above, the list has been very 
quiet and will remain that way until people start using it.

> So I just now sent email to :
> proxy-maint+subscr...@gentoo.org

This is not the mailing list address, but the alias for the Proxy 
Maintainers project - you can't subscribe to this. That being said, I 
couldn't see this email in my client.

> NO answer on this attempt. ON this page::
> https://www.gentoo.org/get-involved/mailing-lists/all-lists.html

The gentoo-proxy-maint mailing list was indeed missing from that list 
and has just been added thanks to Robin.

> Oh yea, I emailed those quizes timely to one of the devs I was working 
> with, and got no answer. (sorry, not going to identify that dev). So I 
> prefer to answer the latest quizes; you guys can figure out who I 
> should send those to.

It's unfortunate that this happened.

As for whom to send your quizzes to, they would go to your mentor. If 
you don't have a mentor, try approaching a developer with whom you've 
been working and see if they will be able to. Alternatively, you can 
have a look at the new [0]Mentors project, or even send a mail to -dev 
asking for one.

I look forward to having another contributor among the ranks. :)

-- 
Sam Jorna (wraeth)
GnuPG Key: D6180C26


signature.asc
Description: Digital signature


Re: [gentoo-dev] RFC: Proposal for addition of distribution variables

2016-12-04 Thread Sam Jorna
On Sun, Dec 04, 2016 at 09:13:23PM -0600, A. Wilcox wrote:
> to read over it.  (Would it be more desirable to have all changes in a
> single large commit, or one commit per package?)

I'd think this is one of those cases best suited to a branch and merge 
commit - best of both worlds.

But that's just my two cents. :)

-- 
Sam Jorna (wraeth)
GnuPG Key: D6180C26


signature.asc
Description: Digital signature


Re: [gentoo-dev] Please retain authorship of contributed patches

2016-11-30 Thread Sam Jorna
On Wed, Nov 30, 2016 at 09:23:56PM +, Andrey Utkin wrote:
> The difference between my submission and final variant by Matthew is big
> in number of lines, but is trivial in content as you can see below, so I
> don't believe that Matthew has written his variant from scratch on his
> own (he hasn't given any note on tickets on bugs.g.o or github), it
> seems more like intentional swapping and amending original lines
> retaining identical outcome.
> 
> Not that authorship of one or two commits is so crucial for me, or that
> I'm the most ambitious wannabe-contributor. Hell, there's not much of
> code at all in the ebuild - it's trivial; but also not much is needed
> here to give credit. I have contributed to quite some FOSS projects, and
> have run into theft of my patches a couple of times, and it never was by
> pure accident.

Though I wasn't involved in these commits, I have seen how easy and
accidental it is to lose authorship information on a commit. That being
said, finding where to draw the line on authorship can be difficult.

I'm not sure how many others are aware of this, but I'll mention it just
in case: provided it's done before pushing commits, the commit metadata
and message can be amended locally with

  git commit --amend --author="Joe Smith <jsm...@nowhere.blah>"

This will update the Author tag but leave the Committer tag untouched
(and will allow fixing any problems with the commit message itself).
Amending commits that are not the tip of your local clone will probably
need an interactive rebase though (but I could be wrong about that).

-- 
Sam Jorna (wraeth)
GPG ID: 0xD6180C26


signature.asc
Description: Digital signature


Re: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)

2016-06-08 Thread Sam Jorna
On 09/06/16 15:31, NP-Hardass wrote:
> On 06/09/2016 01:03 AM, Daniel Campbell wrote:
> [...]
>> Proxy-maint team: do you guys feel that your project and/or process are
>> a suitable starting point to becoming a proper Gentoo developer?
> As with everything, it depends on the individual.  One can certainly cut
> their teeth and learn/contribute a lot through proxy maint, but at the
> same time, they could just do the bare minimum to keep their package
> updated.  The idea behind the project is to facility user contributions.
>  Part of that includes ensuring proper QA and writing good, well formed
> ebuilds.  This certainly provides the opportunity to get an individual
> moving toward developership, but obviously, once again, depends on the
> individual.

I'd also like to expand on this a little further to point out that we
have recently enacted a policy to help track/list what a given
contributor actually contributes to through the use of bugs[0,1] which
could be beneficial to someone's application to the recruiters. Note
that this isn't intended as a replacement for the recruitment process.


That being said, there are still a lot of bugs and PR's to be done, so
we would welcome any new members wishing to help facilitate user
contributions!


[0] https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers/Managing_Requests
[1]
https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers/Maintainer_Bugs_and_Maintainership_Requests

Cheers;
-- 
Sam Jorna (wraeth) <wra...@gentoo.org>
GnuPG Key: D6180C26



signature.asc
Description: OpenPGP digital signature


Re: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)

2016-06-08 Thread Sam Jorna
On 09/06/16 09:08, Andreas K. Huettel wrote:
> 
>> This could lead to a future where the Gentoo tree is largely
>> superseded. Every user would just have their own repository, where
>> they could pick and choose packages from other users. The Gentoo tree
>> would just focus on a high-quality repository of the basic/core things
>> that everybody needs. Gentoo devs would spend most of their time
>> maintaining curated small and useful repositories.
> 
> [...]
> 
>> The final step is the most difficult (but then again we might never
>> get so far). It is two-fold. First we make the core/base repository.
>> Then we identify important subsets that can be logically separated
>> into repositories, and do this.
> 
> 
> Sigh. Every 2 years somebody else comes up with the same silly idea.
> 
> 1) Who defines what everybody needs?
> 2) How do you enforce security and/or qa requirements on the rest?
> 3) Will you allow non-core dependencies? What guarantees are made there?
> 4) How do you make sure that different split-out repos actually work together?
> 5) "logically separated subsets" means either "loss of functionality" or 
> "impossible to do"
> 
> Independent of how many magic tools you whip up this will be a significant 
> step down in functionality and quality, and a big step towards a big 
> unmanageable steaming pile of cr...

Even excepting the significant technical issues such as dependencies and
security issues, even something as simple as versioning, if interpreted
differently between users, could prove difficult to overcome.

Not to mention SLOTting...

-- 
Sam Jorna (wraeth) <wra...@gentoo.org>
GnuPG Key: D6180C26



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] The future of the Sunrise project

2016-06-07 Thread Sam Jorna
On 07/06/16 19:29, Anthony G. Basile wrote:
> Its time to retire the project.  Put out a last call for anyone to adopt
> it.  If not, then freeze commits but leave the repo open as an archive.
> Anyone who wants to scavenge ebuilds from it can do so.

This seems reasonable - it allows packages that people want actively
maintained to be picked up, and still leaves the rest available in the
overlay outside of gentoo.git so they don't cause any major dramas.

-- 
Sam Jorna (wraeth) <wra...@gentoo.org>
GnuPG Key: D6180C26



signature.asc
Description: OpenPGP digital signature


[gentoo-dev] Lastrites: sci-geosciences/qlandkartegt{,-garmindev}

2016-05-23 Thread Sam Jorna
# Sam Jorna <wra...@gentoo.org> (24 May 2016)
# Deprecated in favour of sci-geosciences/qmapshack.
# See bugs 561788 and 582262
# Masked for removal in 30 days.
sci-geosciences/qlandkartegt
sci-geosciences/qlandkartegt-garmindev

-- 
Sam Jorna
GnuPG Key: D6180C26


signature.asc
Description: Digital signature


Re: [gentoo-dev] new developers' keyword requests

2016-05-20 Thread Sam Jorna
On Sat, May 21, 2016 at 10:09:04AM +0800, Ian Delaney wrote:
> On Fri, 20 May 2016 16:00:02 +0200
> Jeroen Roovers <j...@gentoo.org> wrote:
> 
> > On Thu, 19 May 2016 18:36:22 -0700
> > Daniel Campbell <z...@gentoo.org> wrote:
> > 
> > > To make sure I understand what you're getting at, are you saying
> > > some devs get on board and then request to add keywords to packages
> > > that they already maintain? If said arches are already supported in
> > > Gentoo I see little problem with that, especially if they intend on
> > > being part of the arch testing team for that arch or have access to
> > > the hardware.  
> > 
> > I am not talking about adding architecture keywords to profiles/.
> > I am talking about adding architecture keywords to ebuilds.
> > 
> > 
> > Regards,
> >  jer
> > 
> 
> Firstly I think previous replies have been de-railed on talking about
> new alternate arches, which personally I think is the last thing we
> need. If there is any confusion it is because the term keyword, like
> most terms in I.T. gets pushed and pulled and stretched until it breaks.
> To my understanding, KEYWORDS are arches.  But being told to 'keyword' a
> package could mean perhaps, well, Hu knows. 

I don't know of any other usages of "KEYWORDS" within Gentoo - to my
knowledge the only definition is a list of which architectures a package
is known to work or not work on, and an indication of the level of
testing and expected usability on that architecture.

Is there some other definition that I'm missing?

> Supporting users doing just this lately, I have come across this a few
> times.  Users and new devs are expected to be very ignorant of minor
> arches, and despite having docs already informing them that they are
> short staffed and have enough to do, the practicalities of how and why
> to keyword request or not are still veiled in mystery. Users want to
> keyword according to what they see supported upstream just because
> they can. They appear to need it made manually clear to them that there
> are qualifiers and conditions for putting something up for keywording.
> These also I believe are as much as mystery to users as they are to
> devs.  

Appropriate use of KEYWORDS is actually covered in the Developer
quizzes, so I would have instead expected new developers to be more
acutely aware of the fact that keywording on minor arches should be
generally reserved for an as-needed basis.

> How to establish a level of desire form userland to have gentoo
> support the arch in the package??
> How to establish sane rationale for it being put up for stable??
> The last I heard was along the lines of, well, only put it up if it has
> already been put up in the past.(someone in the past had a check list?)
> 
> If anyone, the members of the arch teams might have some insights based
> upon first hand dealing with packages and their categories. Frankly,
> how you can expect or achieve users and new devs to assess these is
> more the issue, and I do not see there is any obvious path of becoming
> informed of the interest of an invisible audience; userland

As far as I know, users (as in non-maintainers - those out "in the wild")
can file keyword request bugs and it's up to the maintainer to then
determine relevancy and CC appropriate arch teams; and Bugzilla has a
voting feature[0] allowing users to indicate the strength of community
demand by voting on those bugs (which I have seen done previously).

[0] https://bugs.gentoo.org/page.cgi?id=fields.html#votes

-- 
Sam Jorna
GnuPG Key: D6180C26


signature.asc
Description: Digital signature


Re: [gentoo-dev] Proposal for enhancement to PMS/EAPI7+

2016-05-17 Thread Sam Jorna
On Wed, May 18, 2016 at 05:44:28PM +1200, Kent Fredric wrote:
> On 18 May 2016 at 17:40, Ulrich Mueller <u...@gentoo.org> wrote:
> > Only two lines. Do you think this is untidy?
> 
> 
> It only becomes untidy where you don't already have a src_install.
> 
> Then it becomes 4 lines.
> 
> 4 lines of which 3 are redundant and simply re-codify existing behaviour.

Unless you define DOCS and include the default documents, which is an additional
78 characters on one line (excluding any potential globbing, and assuming all
default files are wanted).

-- 
Sam Jorna
GnuPG Key: D6180C26


signature.asc
Description: Digital signature


Re: [gentoo-dev] NEW: split portage/repoman releases now in the tree

2016-05-16 Thread Sam Jorna
On Sun, May 15, 2016 at 06:39:22PM -0700, Brian Dolbec wrote:
> 
> portage-2.3.0_rc1 and repoman-2.3.0_rc1 are now in the tree.
 
> I want to thank the following people for their help and contributions
> to make these releases:
> 
>   Zac Medico 
>   Alexander Bernsten 
>   Dirkjan Ochtman  for the base xml re-write code
>   Michal Gorny  for the metadata.xsd changes
>   Göktürk Yüksek  for the metadata.xml test ebuilds
>   patches.
>   Mike Gilbert  for all the testing on the rewite code,
>   and a number of gen-b0rk repo test ebuilds.
>   
>   Coacher for the recent testing, bug reports and patches.
>   And anyone else I missed ;)

Thank you to everyone involved! :)

-- 
Sam Jorna
GnuPG Key: D6180C26


signature.asc
Description: Digital signature


Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: dev-games/mygui/

2016-04-20 Thread Sam Jorna
On Wed, Apr 20, 2016 at 08:57:52AM +0200, Michał Górny wrote:
> Just FYI, we're talking about upstream maintainer elements which do not take 
> part in bug assignment.

Ah, yes, I missed that; though it may have been done as something related to
that - just putting it out there.

Cheers;
-- 
Sam Jorna (wraeth)
GnuPG Key: D6180C26


signature.asc
Description: Digital signature


Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: dev-games/mygui/

2016-04-19 Thread Sam Jorna
On Wed, Apr 20, 2016 at 02:52:24PM +1000, Sam Jorna wrote:
> On Mon, Apr 18, 2016 at 05:47:43PM +0200, Michał Górny wrote:
> > On Mon, 18 Apr 2016 08:13:34 + (UTC)
> > "Patrice Clement" <monsie...@gentoo.org> wrote:
> > 
> > > commit: 4f2477ca1ab07969bae57e7b47e8b7a5ba9a6050
> > > Author: Patrice Clement  gentoo  org>
> > > AuthorDate: Mon Apr 18 06:35:31 2016 +
> > > Commit: Patrice Clement  gentoo  org>
> > > CommitDate: Mon Apr 18 07:58:13 2016 +
> > > URL:https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=4f2477ca
> 
> ...
> 
> > > - CC on bugs
> > 
> > You're discarding important information here. This also has been
> > covered in the GLEP. The suggested solution is to copy the person into
> > downstream maintainers with appropriate explanatory description (like
> > 'upstream developer wishing to be CC-ed on bugs').
> 
> Just an FYI:
> Members of the Proxy Maintainers project decided that the inclusion of the
>  element was superfluous and that the ordering of  />
> elements was sufficient for determining bug assignment/CC'ing based on the
> bug-wranglers policy[0] (which does not explicitly mention ).

Forgot the reference (which I probably don't need anyway) but:

0: https://wiki.gentoo.org/wiki/Project:Bug-wranglers#Assigning_bug_reports

-- 
Sam Jorna
GnuPG Key: D6180C26


signature.asc
Description: Digital signature


Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: dev-games/mygui/

2016-04-19 Thread Sam Jorna
On Mon, Apr 18, 2016 at 05:47:43PM +0200, Michał Górny wrote:
> On Mon, 18 Apr 2016 08:13:34 + (UTC)
> "Patrice Clement" <monsie...@gentoo.org> wrote:
> 
> > commit: 4f2477ca1ab07969bae57e7b47e8b7a5ba9a6050
> > Author: Patrice Clement  gentoo  org>
> > AuthorDate: Mon Apr 18 06:35:31 2016 +
> > Commit: Patrice Clement  gentoo  org>
> > CommitDate: Mon Apr 18 07:58:13 2016 +
> > URL:https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=4f2477ca

...

> > -   CC on bugs
> 
> You're discarding important information here. This also has been
> covered in the GLEP. The suggested solution is to copy the person into
> downstream maintainers with appropriate explanatory description (like
> 'upstream developer wishing to be CC-ed on bugs').

Just an FYI:
Members of the Proxy Maintainers project decided that the inclusion of the
 element was superfluous and that the ordering of 
elements was sufficient for determining bug assignment/CC'ing based on the
bug-wranglers policy[0] (which does not explicitly mention ).

-- 
Sam Jorna (wraeth)
GnuPG Key: D6180C26


signature.asc
Description: Digital signature