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

[Kristian Fiskerstrand]

On 08/08/2017 06:37 PM, William L. Thomson Jr. wrote:
> I make a lot of binaries for use on other systems, to expedite updates.
> It does not make sense for some packages to ever be a binary package.

Any particular reason this decision shouldn't be left to the operator of
the binhost rather than the package maintainer? it can already be
controlled through env files.

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

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

[Kristian Fiskerstrand]

On 07/27/2017 04:11 PM, Michał Górny wrote:
>> Right, so github automatically closes pull requests when encountering
>> Closes, that doesn't indicate that Closes can't be used for other
>> platforms to do similar things, or closing things manually if provided
>> through other channels. The current wording indicates it is only for
>> Github use "to automatically close a GitHub pull request,"
> ...which is the only purpose it's being used for right now, and I
> seriously doubt there will be any other use in the near future.

That doesn't mean we shouldn't prepare for it in our specification, why
shouldn't I be able to use it for closing a pull request provided
through bitbucket or a git request-pull from my private gitolite? There
is absolutely no reason to mention github in the GLEP versus making it a
generic tag for closing a pull request.

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

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

[Kristian Fiskerstrand]

On 07/27/2017 03:58 PM, Michał Górny wrote:
>>>>> ** Closes: https://github.com/gentoo/gentoo/pull/>>>> ki>; — to automatically close a GitHub pull request,
>>>> Is this a generic tag for any pull request of any platform?
>>> No. As I've told multiple times already, there are *no* generic tags. It
>>> just happens to be used by some random platforms. Some others use e.g.
>>> 'Fixes' which you forbade.
>>>
>> Isn't that the point of having a GLEP to begin with? Trying to
>> standardize the use of e.g the tags so that it has a consistent meaning
>> and can be useful?
>>
> Tags are mentioned merely for convenience, and as examples. If you want
> to request GitHub support to add support for special Gentoo tags you've
> just invented, be my guest. But don't bother forwarding their reply to
> me because I know their answer.

Right, so github automatically closes pull requests when encountering
Closes, that doesn't indicate that Closes can't be used for other
platforms to do similar things, or closing things manually if provided
through other channels. The current wording indicates it is only for
Github use "to automatically close a GitHub pull request,"

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

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

[Kristian Fiskerstrand]

On 07/27/2017 03:52 PM, Michał Górny wrote:
> On śro, 2017-07-26 at 19:17 +0200, Kristian Fiskerstrand wrote:
>> On 07/25/2017 10:05 AM, Michał Górny wrote:
>>> ** Fixes: https://bugs.gentoo.org/NN;; —
>>> to indicate a fixed bug,
>>
>> At this point fixes is overloading
>>> ** Fixes: commit-id (commit message) — to indicate fixing a
>>> previous commit
>>
>> This use should be forbidden.
> 
> ...because? But sure, you don't like it, let's remove it. Not that
> anyone will actually prefer the things from the GLEP over anything else.
> 

Because it overloads the tag for multiple meanings and as such should be
different tags, we already have a tag that specifies the bug (namely
Bug, presuming we use Reference: for URL specification of relevant
upstream information or other discussions)

>>> ** Bug: https://bugs.gentoo.org/NN;; — to
>>> reference a bug,
>>
>> See other comments in thread wrt Gentoo-Bug.
>>
>>> ** Closes: https://github.com/gentoo/gentoo/pull/>> ki>; — to automatically close a GitHub pull request,
>>
>> Is this a generic tag for any pull request of any platform?
> 
> No. As I've told multiple times already, there are *no* generic tags. It
> just happens to be used by some random platforms. Some others use e.g.
> 'Fixes' which you forbade.
> 

Isn't that the point of having a GLEP to begin with? Trying to
standardize the use of e.g the tags so that it has a consistent meaning
and can be useful?

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

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

[Kristian Fiskerstrand]

On 07/26/2017 07:20 PM, Rich Freeman wrote:
> I was thinking that it would make far more sense to use "Bug" for
> Gentoo bugs, and use something like "Reference" or "Remote-Bug" for
> non-Gentoo bugs.  99% of the time commits will reference a Gentoo bug.

I like the idea of Reference for URL specification . This can be used as
a general property for other relevant discussion points as well, and
indeed frees up Bug to be used for Gentoo with numeric identifiers only.

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

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

[Kristian Fiskerstrand]

On 07/26/2017 07:20 PM, Rich Freeman wrote:
> Also, I suggest using either URLs or bug numbers, but not both.
> Otherwise you end up having to copy the URL over, then copy the ID
> only and paste it in the summary.  That is an extra step.

I wouldn't have bug ID in summary at all unless it provides external
value, it should be self-describing

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

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

[Kristian Fiskerstrand]

On 07/25/2017 10:05 AM, Michał Górny wrote:
> ** Fixes: https://bugs.gentoo.org/NN; —
> to indicate a fixed bug,

At this point fixes is overloading
> ** Fixes: commit-id (commit message) — to indicate fixing a
> previous commit

This use should be forbidden.

> ** Bug: https://bugs.gentoo.org/NN; — to
> reference a bug,

See other comments in thread wrt Gentoo-Bug.

> ** Closes: https://github.com/gentoo/gentoo/pull/ ki>; — to automatically close a GitHub pull request,

Is this a generic tag for any pull request of any platform?

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

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

[Kristian Fiskerstrand]

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



signature.asc
Description: OpenPGP digital signature

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

[Kristian Fiskerstrand]

On 07/26/2017 11:21 AM, Ulrich Mueller wrote:
> The same applies to #123456 in the summary line, though. I don't see a
> good reason for using a URL after the "Bug:" keyword as long as bare
> numbers are used elsewhere.

For Bug you'd often refer to upstream reports or other distros, so you
need it in a generic form which url provides, having a separate
Gentoo-Bug properly defined to ID only solves the ambiguity.

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

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

[Kristian Fiskerstrand]

On 07/25/2017 01:25 PM, Michael Orlitzky wrote:
> There are two main advantages over having the bug number in the summary.
> Space is at a premium in the summary, as Tobias pointed out, and the
> 
>   Gentoo-Bug: whatever
> 
> format is trivially machine-readable, whereas sticking it somewhere else
> is less so.

Indeed, I'm in favor of keeping bug information in this format, whereby
Bug:  is fine as a generic reference it will mostly be for upstream
issues or other distributions, whereby Gentoo-Bug: #nn is explicit
reference to our own tracker. An issue to consider is definition of this
label in terms of whether it takes a single value or a list and how to
do wrapping.. I'd likely expect possibility for multiple occurrences for
it but allowing multiple bug numbers specified comma separated

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] can't gpg sign with repoman, but can with git

[Kristian Fiskerstrand]

On 07/20/2017 10:16 AM, Kristian Fiskerstrand wrote:
> What I have noticed with regards to git though, but not had time to
> debug is that it seems to do something odd with regards to communicating
> with the agent to begin with, and possibly spawns an own agent, at least
> sufficiently confusing that for smartcard use it fail to access the card
> due to locking and needing to re-insert the card.. with similar
> mechanism to use it outside of git context again afterwards.

And looking into this, the issue is actually a lack of sanitation of the
--homedir parameter for gpg-agent, so "$HOME/.gnupg" and "$HOME/.gnupg/"
is treated as separate directories and as such two separate agents are
started... reported upstream... will be nice to get rid of _that_ annoyance.

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] can't gpg sign with repoman, but can with git

[Kristian Fiskerstrand]

On 07/19/2017 09:24 PM, Paweł Hajdan, Jr. wrote:
> * 4 files being committed...
> error: gpg failed to sign the data
> fatal: failed to write commit object
> !!! Exiting on git (shell) error code: 128

you can increase gpg-agent logging verbosity in gpg-agent.conf:
log-file /home/user/my.log
debug-level guru
... don't share the file outright, as it can contain sensitive info at
that debug level.. but it should give you a hint as to what is going on
if the request hits gpg-agent (and if not that is a point of info in itself)

fwiw, debugging this in #gentoo-crypto might be easier :)

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] can't gpg sign with repoman, but can with git

[Kristian Fiskerstrand]

On 07/20/2017 07:49 AM, Andrew Savchenko wrote:
> Some pinentry issues imho if GPG_TTY makes it work, at least it was
> when I hit that half a year ago with this suggested as a solution. It's
> not a solution, it's a workaround, as users need to do something.

This is a documented feature from upstream, mainly on secure systems you
want pinentry to be directed to a specific terminal and not whichever an
application calling gpg is called from, as this can also result in
information leak if a fake pinentry is used etc.

So by default, pinentry is started with the tty that gpg-agent is
started in, which can be a protected environment (even more so with the
possibility of remote gpg-agent, allowing it to run in a protected
sandbox and communicating solely over IPC)

With the graphical pinentries this is a bit different (they are less
secure by design, since they are running on a system with a GUI to begin
with..) , gnome3 one will use some DBUS funkery, whereby gtk+ and qt
ones will be easier to debug as they rely mostly on DISPLAY variable to
trigger. By default a curses pinentry is used as fallback (but that
requires proper GPG_TTY, of which the proper very much can be the
initial tty from the agent)

What I have noticed with regards to git though, but not had time to
debug is that it seems to do something odd with regards to communicating
with the agent to begin with, and possibly spawns an own agent, at least
sufficiently confusing that for smartcard use it fail to access the card
due to locking and needing to re-insert the card.. with similar
mechanism to use it outside of git context again afterwards.

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] newsitem: openrc-0.28 mounts efivars read only

[Kristian Fiskerstrand]

On 07/12/2017 05:42 PM, William Hubbs wrote:
> OpenRC 0.28 will mount efivars read only by default due to concerns
> about users bricking systems by writing to this filesystem unexpectedly.
> 
> Here is the newsitem covering this change.

Although the changes seems sensible, I'm wondering if a news item is
necessary for this case versus other documentation and script updates to
reflect this change. For one thing it seems it will have minimal effect
on a running system and not needing a migration path / configuration
updates except in cases where bootloader installs are done; how
intuitive is the feedback in this process when it is read-only?

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

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

[Kristian Fiskerstrand]

On 07/12/2017 01:59 PM, Michael Palimaka wrote:
> If it's not a stable candidate then why do you use this as an example
> against build testing-based stabilisations? If there are known issues it
> should never reach the arch teams in the first place.

This might be the crux of things, as long as automatic stabilization is
not triggered by some set of rules (e.g 30 days in ~arch) , and still
requires manual trigger by, preferably, the maintainer there is likely
no issue.

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

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

[Kristian Fiskerstrand]

On 07/12/2017 12:13 AM, Thomas Deutschmann wrote:
> Question is what's more a problem: Having an outdated stable package
> because nobody cared about stabilizing a new version (in most cases this
> will end with a rushed stabilization once a security bug was fixed in
> the package) or move a package in time from ~ARCH to ARCH and deal with
> the fallout sometimes.

Easy, keep the working package any time

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

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

[Kristian Fiskerstrand]

On 07/11/2017 04:21 PM, Michael Palimaka wrote:
> On 07/12/2017 12:15 AM, Kristian Fiskerstrand wrote:
>> On 07/11/2017 04:13 PM, Kristian Fiskerstrand wrote:
>>> On 07/11/2017 03:47 PM, Michael Palimaka wrote:
>>>> The main risk of breakage of a package moving from testing to
>>>> stable is always at build time anyway.
>>>
>>> citation needed
>>>
>>
>> Anecdotal evidence against, currently gnupg 2.1.21 scdaemon bug will
>> happily sign a third party public keyblock's UID using signature subkey
>> on smartcard, which results in useless signature that doesn't have any
>> effect, but the application builds fine.
>>
>> This means gnupg 2.1.21 is not a candidate for stabilization, but it
>> certainly builds fine.
>>
> 
> Stop trolling - you know perfectly well that this sort of issue would
> never ever be caught during arch testing. Nor should it be - it's called
> *arch* testing for a reason.

That presumes that the maintainer is the one calling for the
stabilization, and it is not an automated procedure simply due to 30
days in ~arch. In this particular case, look for the number of bug
reports filed in Gentoo for the issue.

But the main risk is certainly not built testing, it is breaking
operational live stable systems. Nowhere was it claimed that the arch
testers are responsible for it, but it certainly doesn't coincide, at
any point, with "The main risk of breakage of a package moving from
testing to stable is always at build time anyway."

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

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

[Kristian Fiskerstrand]

On 07/11/2017 04:13 PM, Kristian Fiskerstrand wrote:
> On 07/11/2017 03:47 PM, Michael Palimaka wrote:
>> The main risk of breakage of a package moving from testing to
>> stable is always at build time anyway.
> 
> citation needed
> 

Anecdotal evidence against, currently gnupg 2.1.21 scdaemon bug will
happily sign a third party public keyblock's UID using signature subkey
on smartcard, which results in useless signature that doesn't have any
effect, but the application builds fine.

This means gnupg 2.1.21 is not a candidate for stabilization, but it
certainly builds fine.

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

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

[Kristian Fiskerstrand]

On 07/11/2017 03:47 PM, Michael Palimaka wrote:
> The main risk of breakage of a package moving from testing to
> stable is always at build time anyway.

citation needed

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

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

[Kristian Fiskerstrand]

On 07/10/2017 10:02 PM, Rich Freeman wrote:
> On Mon, Jul 10, 2017 at 3:57 PM, Andrew Savchenko <birc...@gentoo.org> wrote:
>>
>> On Mon, 10 Jul 2017 13:49:40 -0400 Rich Freeman wrote:
>>
>>> In the case of amd64 we already
>>> encourage individual package maintainers to stabilize their own
>>> packages
>>
>> Huh? Have our rules changed? As per devmanual[1] and GLEP 40[2]
>> stabilization must be carried out by arch teams, unless a special
>> arrangement is done between a developer and a team.
>>
> 
> The docs are probably out of date - I'm not sure if the policy is
> documented anywhere.  However it has been a fairly longstanding policy
> at this point that amd64 allows individual maintainers to stabilize
> their own packages.
> 

We looked after it for wg-stable (which died out as a result of rather
low participation, maybe it should be rebooted if people feel like
discussing this again), there isn't any authoritative policy allowing
it, GLEP:40 explicitly removes the possibility to do it for x86. That
said, for a number of packages maintainer stabilization can likely make
sense, the opposite view is four-eyes principle, it is always good to
have someone else build-test etc, but this is greatly helped by
tinderboxing efforts (thanks toralf) etc. So one likely output if
wg-stable is to come up with something would be a replacement GLEP for
40 that matches the current state, and also kernel auto-stabiliation (as
discussed in [section 3.2 (Kernel)]

References:
[section 3.2 (Kernel)]
https://download.sumptuouscapital.com/gentoo/wg-stable/main.pdf

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] About adding a *warning* to remind maintainers to check for new PYTHON_COMPAT values

[Kristian Fiskerstrand]

On 07/10/2017 03:35 PM, Kent Fredric wrote:
> On Mon, 10 Jul 2017 13:43:43 +0200
> Pacho Ramos <pa...@gentoo.org> wrote:
> 
>> Yes, but it's similar as the cases when we need to fix our packages
>> to work with a newer library they depend on. In this case it would be
>> even easier as we can have multiple python versions and switch to the
>> newer one for testing while going back to the stable one (if
>> preferred) later.
>>
> 
> I'm starting to think we need a collection of QA scripts in a repo
> somewhere, optimized for symlinking into /etc/portage/hooks/install/
> 

I might've read things too quickly, we're not talking a repoman check here?

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] About adding a *warning* to remind maintainers to check for new PYTHON_COMPAT values

[Kristian Fiskerstrand]

On 07/10/2017 01:04 PM, Pacho Ramos wrote:
> Any issues on trying to go further into implementing this warning? 

Not an issue per se, but it should be pointed out that python 3.5 only
has a testing visibility, so this at the very least requires maintainers
to potentially have a separate testing chroot/VM to test when adding the
compat.

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Pre-GLEP RFC: Automated enforcing of REQUIRED_USE constraints

[Kristian Fiskerstrand]

On 07/08/2017 11:31 PM, Michał Górny wrote:
> Nobody said anything about the next EAPI. The GLEP doesn't say a word
> about introducing it in a future EAPI.
> 
> We're adding this as an optional (default off) FEATURE into Portage
> and we'll see how it works. As far as I'm concerned, we can enable it
> for all EAPIs without touching PMS at all.

With that in mind, does it really need a GLEP? Isn't this something that
can be done within the package manager as a feature anyways without
mandating changes?

If anything it seems like it'd be an informational GLEP and not a
standards track if going down that route.

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] rfc: new category, app-containers

[Kristian Fiskerstrand]

On 06/14/2017 06:11 PM, William Hubbs wrote:
> Is it time to start thinking about an app-containers category?
> If so, is it ok for me to start an app-containers category with these
> packages then we can look into moving other packages to it?

Personally I don't see much value in introducing a new category at this
point. Package moves always introduce a certain degree of complexity
(e.g requiring maintainers in main tree and other repositories to update
dependency specifications), is there really value from introducing this
category vs the existing one? in the general case I'd like to see less
categories rather than more.

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] autotools.eclass: automatically move configure.in to configure.ac

[Kristian Fiskerstrand]

On 06/11/2017 05:24 PM, David Seifert wrote:
>> We can always patch the eclass at that point if that is still a big
>> concern, but I fundamentally agree with William on this, starting
>> point
>> should be fixing it upstream, so can start with a tracking bug on
>> affected packages.
>>
> Here's a deal: you can start filing + fixing them.
> 

The [tracker] is already started, it was determined to add QA warning
with info on filing upstream bugs in [bug 426262] and the proper
solution is again iterated in [bug 546614], so its not like this is a
new approach that is being suggested, but sure, we should all file bugs
when we encounter them.

References:
[tracker] https://bugs.gentoo.org/show_bug.cgi?id=530632

[bug 426262]
https://bugs.gentoo.org/show_bug.cgi?id=426262

[bug 546614]
https://bugs.gentoo.org/show_bug.cgi?id=546614

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] autotools.eclass: automatically move configure.in to configure.ac

[Kristian Fiskerstrand]

On 06/11/2017 05:17 PM, Mart Raudsepp wrote:
>> We can always patch the eclass at that point if that is still a big
>> concern, but I fundamentally agree with William on this, starting
>> point
>> should be fixing it upstream, so can start with a tracking bug on
>> affected packages.
> That's a complete useless waste of time, to track some ancient packages
> that don't get any upstream update anyway. The active ones have updated
> it long ago. And it'd be a joke to propose last riting for the reason
> of a file being named configure.in instead of configure.ac.
> 
> 

That determination can be made on a package-by-package basis and fixed
in ebuild if needed.

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] autotools.eclass: automatically move configure.in to configure.ac

[Kristian Fiskerstrand]

On 06/11/2017 05:07 PM, Mart Raudsepp wrote:
> Ühel kenal päeval, P, 11.06.2017 kell 10:00, kirjutas William Hubbs:
>> On Sat, Jun 10, 2017 at 01:04:06PM +0100, Sergei Trofimovich wrote:
>>> On Sat, 10 Jun 2017 13:28:19 +0200
>>> Jeroen Roovers <j...@gentoo.org> wrote:
>>>
>>>> https://bugs.gentoo.org/show_bug.cgi?id=426262
>>>> +  mv configure.{in,ac} || die
>>>
>>> Looks good.
>>>
>>> -- 
>>>
>>>   Sergei
>>
>> -1
>>
>> I think this should be handled by the packages, not at the eclass
>> level.
>>
>> https://bugs.gentoo.org/show_bug.cgi?id=426262#c3
>>
>> The packages should either mv the configure.in to configure.ac
>> internally, or better yet, the maintainers should ask upstream for
>> their
>> packages to fix it.
> 
> +1, otherwise we will never be able to add/unmask a newer autoconf that
> doesn't look at configure.in anymore, once such a version eventually
> happens.
> 

We can always patch the eclass at that point if that is still a big
concern, but I fundamentally agree with William on this, starting point
should be fixing it upstream, so can start with a tracking bug on
affected packages.

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] toolchain meeting agenda for today 19:00 UTC #gentoo-toolchain

[Kristian Fiskerstrand]

On 05/30/2017 12:05 AM, Andreas K. Huettel wrote:
> -- So all packages that a) use gcc-4 or gcc-5, and b) do not in the ebuild 
> "manually" add something like -std=c++11 or -std=c++14 or -std=gnu14 will 
> fail 
> to *build*.

This isn't really different from [Qt 5.7 requirements] and is
fundamentally an upstream bug if not checked for during configure and
automake using e.g [ax_cxx_compile_stdcxx_11].

References:
[Qt 5.7 requirements]
https://bugs.gentoo.org/589412

[ax_cxx_compile_stdcxx_11]
https://www.gnu.org/software/autoconf-archive/ax_cxx_compile_stdcxx_11.html

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] toolchain meeting agenda for today 19:00 UTC #gentoo-toolchain

[Kristian Fiskerstrand]

On 05/26/2017 08:07 PM, Alexis Ballier wrote:
> A bit late to the party, but what was the outcome of the meeting, esp.
> this part ?

Unofficial log from meeting:
https://download.sumptuouscapital.com/gentoo/tmp/gentoo-toolchain.log.txt

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] Restricted version of gentoo-dev mailing list

[Kristian Fiskerstrand]

On 05/24/2017 08:41 AM, Michał Górny wrote:
> Next time such a thing happens, the discussion will happen on a
> completely private media or not happen at all because of the state of
> this mailing list. Is this what you really want?

I wouldn't agree with it being an axiom of sorts that discussion will
happen elsewhere. The noise level of the discussion of a new list or
moderation of the current dev list is greather than the noise that
spurred the discussion to begin with.

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Fixing elasticsearch maintainer

[Kristian Fiskerstrand]

On 05/20/2017 11:06 PM, Michał Górny wrote:
> On sob, 2017-05-20 at 22:51 +0200, Kristian Fiskerstrand wrote:
>> On 05/20/2017 10:46 PM, Michał Górny wrote:
>>> Tomas, please don't go this road. We all know Patrick does a shitty job
>>> as Gentoo developer, both technically and socially but you do not have
>>> to try to match him.
>>
>> Was this comment really necessary?
>>
> 
> Yes, it was. It's enough that Patrick does public lashing here, I don't
> want Tomas to do the counter-lashing. Show's over, move along, etc.
> 

I'm more concerned about the tone of the message, we really should
strive to be more collegial in our commenting in official Gentoo channels.

In this case it seems to be a matter of communication between various
maintainers of a package that likely should belong in private before
being aired on a public mailing list. Given the number of maintainers,
I'm wondering if it shouldn't be a project handling it to begin with,
but certain parts of the history looks odd from the outside.

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Fixing elasticsearch maintainer

[Kristian Fiskerstrand]

On 05/20/2017 10:46 PM, Michał Górny wrote:
> Tomas, please don't go this road. We all know Patrick does a shitty job
> as Gentoo developer, both technically and socially but you do not have
> to try to match him.

Was this comment really necessary?

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Fixing elasticsearch maintainer

[Kristian Fiskerstrand]

On 05/20/2017 12:43 AM, Kent Fredric wrote:
> ef2b2458815ba4e4694e0d5f3bbce239505ffbc8 - 2015-12-20
> 
> Idella4's last commit on this package.
> 
> 3d70356565d3213c370e1f64a85b55c3ded259f5 - 2016-01-06
> 
> Patricks first direct commit to this package.
> 
> <>
> 
> e6175815b5792f09acd90627af5fe23f616ad245 - 2016-09-02
> 
> Patrick adds himself and Tomas, and removes Proxy Maint.
> 
> ^^^ 
> 
> This last commit is, as I understand, where most this conflict comes
> from.

fwiw, Thomas explicitly requested proxy-maint to stay on as maintainer
at this point. "Given this information, I'd
like to return the proxy maintainers team to the metadata so I'm able to
open PR via github and manage changes even without Patrick."


> 
> But it makes more sense to realise who the primary proxied maintainer
> was at this time, who can be considered "owning" the package, and has
> the right to dictate which gentoo dev's maintain their packages for
> them.

At some point they likely should establish a project and discuss things
internally before making changes. But on a post-hoc-basis the
determination will need to be based on documented history.

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Fixing elasticsearch maintainer

[Kristian Fiskerstrand]

On 05/19/2017 06:50 PM, Patrick Lauer wrote:
> 
> I have no idea how I could have fixed this without the QA+Comrel
> banhammer combo, which is a totally insane "fix" to a problem that
> shouldn't even exist. But I see no other options how to make people
> understand that "No means no".
> 
> Is this the new normal?

As far as I can see you were never the maintainer of at least
app-misc/elasticsearch (I didn't check other possibly related packages),
it was first proxied maintained through chainsaw, then later through
proxy-maintainers herd (since 2015) which was converted to the project
once herds were deprecated. I don't notice you showing up in the git log
(with cvs history grafted) until 2016 in a commit that removed proxy
maint seemingly without corrabolation, and as such got reverted.

I'm really struggling to understand what you're trying to say here, if
it is "can I take any package I want without consulting with existing
maintainers", then yes, its the normal (its not new)

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] 17.0 profile update

[Kristian Fiskerstrand]

On 05/12/2017 05:50 PM, Ulrich Mueller wrote:
>>>>>> On Fri, 12 May 2017, Matthias Maier wrote:
> 
>> I will post an RFC for a profile update (and a news item) for 17.0
> 
> We used to count from 1999 (namely, 10.0 introducing the counting
> appeared on our 10th anniversary).
> 
> So shouldn't the above be 18.0?

Interesting historical tidbit, but, 13.0 was done in 2013, I believe it
makes sense to sticking to year and make it 17.0


-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Bugzilla package list editing

[Kristian Fiskerstrand]

On 05/10/2017 05:33 PM, David Seifert wrote:
> On Wed, 2017-05-10 at 18:22 +0300, Mart Raudsepp wrote:


>>
> 
> He doesn't stop: https://bugs.gentoo.org/show_bug.cgi?id=617694
> Please drop editbugs privileges for some time. Everyone agrees that
> this maintainer-specific metadata is not to be touched.
> 

I've actually spent some time looking into this and haven't actually
found any authoritative documentation that makes it maintainer-specific,
so I welcome some references to documentation that it is.

There is the bug wrangler project page, but that is project-specific and
not global.

Although it is certainly a good practice that maintainer acks
stabilizations; other projects routinely files stabilization requests,
in particular the security project.

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Re: New profiles for default-pie transition

[Kristian Fiskerstrand]

On 05/10/2017 03:29 PM, Andreas K. Huettel wrote:
> Am Mittwoch, 10. Mai 2017, 13:58:56 CEST schrieb Dirkjan Ochtman:
>> On Wed, May 10, 2017 at 11:19 AM, Kristian Fiskerstrand <k...@gentoo.org> 
> wrote:
>>> Sounds like a reasonable action plan. The consequences of such a change
>>> definitely seems to be sufficiently high to merit a proper migration
>>> plan which doesn't seem to have been established at this point. Whether
>>> that can be added to a later point with gcc6 (e.g by adding a new
>>> profile, or a later point release) I don't have strong opinions on, but
>>> there should be a plan and proper overview of the consequences.
>>
>> Yeah, I think I agree. From the discussions so far, I think that we
>> should definitely aim for making pie the default for everyone (on
>> arches where it makes sense), but doing it in the gcc-6 now which has
>> seen only a short period of testing so far seems a bit hasty based on
>> data from the messages that I've seen in these threads so far.
> 
> Actually the idea I like best so far is Jason's profile suggestion. 
> 
> * package.use.mask gcc[pie] in the 13.0 profiles
> 
> * generate a new set of profiles 17.0 where it's package.use.forced
> * tell people they may have to rebuild world when they switch
> 
> -> This would also give us some time to discuss what other changes we might 
> make with the transition to the new profiles. 
> 
> -> Also, this means the transition is independent of gcc release timing.
> 
> (We just need to be careful since hardened also inherits 13.0, so the setting 
> must be overridden there. As far as I can see that's already done there 
> though.)
> 

+1

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: [RFC] News item: GCC 6 defaults to USE="pie ssp"

[Kristian Fiskerstrand]

On 05/10/2017 03:35 PM, Andreas K. Huettel wrote:
> I'm wondering a bit if we're not trying to make ~arch stable again. Then 
> again 
> nobody of us knows all use cases of Gentoo everywhere, so listening to the 
> list makes sense.

Well, it'd affect stable users at _some_ point, and as you say; it seems
a good starting point for discussing which other profile changes we'd
make with a new 17.0.

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] News item: GCC 6 defaults to USE="pie ssp", v2

[Kristian Fiskerstrand]

On 05/10/2017 09:52 AM, Alexis Ballier wrote:
> On Tue, 09 May 2017 18:58:42 -0500
> Matthias Maier <tam...@gentoo.org> wrote:
> 
>> This is a reworded news item (assuming we proceed with the plan to
>> default-enable USE=pie). Suggestions for improving the emerge command
>> to fix static archives is highly welcomed.
>>
> 
> Really, I think the slot to have pie for gcc 6 has been missed by
> default-enabling it only recently. We should aim for gcc 7 at least and
> have proper testing.
> 
> And add a few safety nets: A portage warning when installing non-pie
> binaries, something that dies with FEATURES=strict or stricter, like
> the textrel one we have. That is to avoid the quick n dirty
> 'append-ldflags -no-pie' that makes the whole thing about forcing pie
> questionable. If possible, detect static archives that have relocations
> too.
> 
> Ideally provide a system scanning tool for the above too.
> 
> 
> After a few months of masked gcc7 like that we'll have enough data to
> decide on a proper plan. It'll probably be good to get QA in the loop
> and make this a QA goal too.
> 

Sounds like a reasonable action plan. The consequences of such a change
definitely seems to be sufficiently high to merit a proper migration
plan which doesn't seem to have been established at this point. Whether
that can be added to a later point with gcc6 (e.g by adding a new
profile, or a later point release) I don't have strong opinions on, but
there should be a plan and proper overview of the consequences.

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [PATCH dtd] glsa.dtd: Allow slot="" attribute for vulnerable

[Kristian Fiskerstrand]

On 04/12/2017 09:10 AM, Michał Górny wrote:
>>  Though not the "*" stuff, that feels wrong and should be just
>> omitted attribute for that.
> Not convinced about that. '*' is already used explicitly in arch='', so
> I don't see a reason to not allow the same syntax here. This is also
> what the Paludis implementation assumes, and it fits into slot operators
> nicely.
> 
> Maybe I should just change the default from #IMPLIED to "*"? (i.e. make
> omitted attribute equivalent to "*" DTD-wise)

I agree, mgorny, the explicit '*' is used already and should stay,
changing the default value for no attribute to interpret as '*' also
makes sense in this context.

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] No Java Team, Java neglect was -> Reverse use of Python/Ruby versions

[Kristian Fiskerstrand]

On 04/12/2017 12:23 AM, Viktar Patotski wrote:
> Hi All,

Hi Viktar,

> 
> My name is Viktar and I'm an experienced Java developer. I'm using
> Gentoo as my primary system for a past 5-6 years, so I do know a little
> bit about it. I even tried to become a Gentoo Dev, but due to lack of
> time haven't completed training course. That's it for introduction.
> 
> I feel really sorry for Gentoo Java project not having appropriate
> attention and I'm volunteering to help solving most important and
> critical issues as a proxy maintainer. Please let me know who I should
> coordinate with.

You'll find some more information on Proxy Maintenance at
https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers , including the
Getting Started section.

Communication with the project can happen through various channels
depending on preference, there is;
 - the gentoo-proxy-ma...@lists.gentoo.org mailing list for ebuild help
and discussions
 - Project alias <proxy-ma...@gentoo.org> for reaching out to project
members
 - IRC channel #gentoo-proxy-maint on Freenode

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] OT Getting to know others in Gentoo was -> No Java Team, Java neglect was -> Reverse use of Python/Ruby versions

[Kristian Fiskerstrand]

On 04/11/2017 05:22 PM, William L. Thomson Jr. wrote:
> When people make assumptions about others based on posts to a mailing
> list etc. It seems they may have a limited view of the world and lack
> of world experience. The more you travel, learn other cultures, etc.
> You learn not to assume about others. Cultures alone can be very
> different. You also learn respect is a VERY big thing. In the US in my
> area and others. Lack of showing respect can result in violence. In
> business lack of respect can really be costly just the same. In Asian
> cultures, respect is HUGE.

[finding a place in block of text to break in with a relative context]

Doesn't this argument go both ways? We have participants from a number
of cultures on the mailing list, and what you feel insulted for I
wouldn't even shrug about here in Norway. In certain other European
countries (or northern Norway), you'd be considered prude for not having
some expletives involved in the everyday discussion.

And doesn't the extension of that argument mean that we should all try
to consider the feedback from others in how we present ourselves? Given
that most of our discussions within this project happens via email, and
on IRC, but email would be the more dominant channel in terms of
substantive discussions, shouldn't we make an effort to increase the
signal to noise ratio and give it serious thought when multiple people
state that a specific behavior is unwanted?

I believe most of us want a more fruitful community within Gentoo, but I
do not believe the way to go ahead to get it is running around
complaining, adding to the negativity. If you really want change, try to
contribute code through the established channels, try to contribute
documentation patches, contributing with resourced bug reports, and say
thank you to developers once in a while instead of expecting some sense
of entitlement because others are contributing pro bono[i].

All I can say is, spending the amount of time reading the dominant
mailing lists is time I could've spent on other aspects of Gentoo, and
I'd much prefer the participants respecting the use of my time when
posting to one of the lists that'd be expected I read to begin with.

So if you know, and receive indication of, a misrepresentation of
persona in such information channels -- might I suggest considering
contributing through different channels and/or limiting the
communication to objective contributions (such as patches)?

Notes:
[i] granted I should quantify that with saying that pro bono argument
only goes so far, if picking up a responsibility it should be followed
up or dropped, the voluntary basis is whether to pick up the ball or not

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] No Java Team, Java neglect was -> Reverse use of Python/Ruby versions

[Kristian Fiskerstrand]

On 04/10/2017 11:54 PM, William L. Thomson Jr. wrote:
> Sadly a vocal minority surely does. If most get past others perception
> of me, insults, and all around the way I am seen. Then most would
> realize what ever they think about me, is horribly incorrect. I am very
> different than I may seem. Almost no one around here knows me. There
> are  a few who have met me. 

I've mostly stayed out of this discussion, but it seems to be reaching
more on personal discussions than topical matters now so I suggest that
everyone takes a step back, a breath of fresh air and keep the topics to
matters that can actually benefit Gentoo.

William; We've all heard what you're saying ad nauseam, and although the
current thread is really within the pure boundries of allowed
discussions, several people have complained about spamming of the lists.

You're saying that nobody really knows you, have you considered spending
some time to reflect on how you present yourself on this mailing list
and other communication channels? Maybe taking another few minutes
writing an email can get your message across in a way that seems more
constructive? Pure volume and repetition of issues surely doesn't
benefit anyone, and quickly becomes boring.

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Reverse use of Python/Ruby versions

[Kristian Fiskerstrand]

On 04/09/2017 06:15 PM, William L. Thomson Jr. wrote:
> Not sure if this is practical, it may be less work if the use of
> Python and Ruby versions ( maybe others ) is reversed. Rather than
> adding all the versions that the ebuild supports. What if it only
> included versions it did not support?

It would only work if upstream provide a strong assurance for forward
compatibility. Explicit testing and marking working seems the only
practical way to ensure stability.

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Tree signing and verification on the user side - status?

[Kristian Fiskerstrand]

[Sent from my iPad, as it is not a secured device there are no cryptographic 
keys on this device, meaning this message is sent without an OpenPGP signature. 
In general you should *not* rely on any information sent over such an unsecure 
channel, if you find any information controversial or un-expected send a 
response and request a signed confirmation]

> On 4 Apr 2017, at 12:10, Dirkjan Ochtman  wrote:
> 
> On Tue, Apr 4, 2017 at 12:03 PM, Andreas K. Huettel
>  wrote:
>>> while we're discussing super-strength hash algos, it would be cool to know
>>> what's still missing for
>>> * rsync-side manifest signing in whatever way
>>> * verification of such signatures in portage / emerge
>>> 
>> 
>> (and just to put it in a reference frame, I'm these days reading mailing list
>> discussions how cryptographic signing of our rsync tree is urgently needed...
>> ... in the council agenda threads
>> ... of the very first council
>> ... i.e., 2005
>> ... i.e., roughly 12 years ago.)
> 
> Was thinking exactly the same thing yesterday. How do we make it
> happen? Do we have any ideas on feasible paths forward?

After having been through two GSoCs , the meta-manifest code is written, gkeys 
is in testing stage for key management etc

iirc (taken from memory, can include faulty info) waiting on (i) infra 
generation of key material on airgapped system with appropriate signing subkey 
to use for online server (ii) code to do signing on rsync staging area (which 
is mostly written) on aforementioned subkey (ii) testing of the aforementioned 
code before rollout

it is coordinated by Gentoo Keys project so questions should really be directed 
there (gkeys@) 

Re: [gentoo-dev] [RFC] New Manifest hashes and how to enable them

[Kristian Fiskerstrand]

[Sent from my iPad, as it is not a secured device there are no cryptographic 
keys on this device, meaning this message is sent without an OpenPGP signature. 
In general you should *not* rely on any information sent over such an unsecure 
channel, if you find any information controversial or un-expected send a 
response and request a signed confirmation]

> On 3 Apr 2017, at 18:09, Michał Górny  wrote:
> 

> Therefore, my proposal would be to use the following set once their
> support reaches the stable version of Portage:
> 
>  manifest-hashes = SHA512 SHA3-512 WHIRLPOOL
> 
> 
> Your thoughts?
> 

SHA256 is perfectly fine to use from a security perspective, so no need to do 
anything from that point of view. The big difference between SHA256 and SHA512 
is performance, you have significant gains of using sha256 on 32 bit 
architectures, whereby SHA512 is quite fine when having 64 bit registers. 
SHA512 is well-tested and already part of package managers etc, so I dont 
really have too strong opinions on making it mandatory and allow for sha256 to 
be replaced, as long as it is clear that it isn't required from a strict 
security view.

As for SHA3 introduction, how well tested is the implementation used by the 
package managers, what are performance metrics etc? We don't really need this 
atm, but nice to have it in the package managers as a backup if that was to 
change, but should not be required digest algo

(and yes, we really need to give Gentoo Keys all the help that we can in 
getting the OpenPGP signing ready, everything else is just bikeshedding until 
that is in place and it is a making me rather sad that we haven't managed to do 
this already)

Re: [gentoo-dev] linux/dma-buf.h mysteriously missing

[Kristian Fiskerstrand]

On 03/30/2017 04:44 PM, Mike Gilbert wrote:
> On Wed, Mar 29, 2017 at 1:51 PM, Matt Turner <matts...@gentoo.org> wrote:
>> It's a bug that has since been fixed by kernel commit
>> 2220fc1ab363e6fab1f321430d69be17a8b92bd7 ("uapi: add missing install
>> of dma-buf.h"). The header was originally added in 4.10, and the fix
>> commit is in 4.11-rc1.
>>
>> I guess we just need to hack around it in sys-kernel/linux-headers-4.10.
>>
> 
> git says the file was added in 4.6, not 4.10.
> 

That seems more consistent with the original posting, containing
#if LINUX_VERSION_CODE < KERNEL_VERSION(4, 6, 0) clause for definitions

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [PATCH] sys-libs/ncurses: Use --cache-file to speedup subsequent econf runs

[Kristian Fiskerstrand]

On 03/21/2017 07:33 PM, Michał Górny wrote:

>>
>>
>> yes you're right, but that still doesn't justify pushing straight to
>> stable for a package in @system
>> (the same applies to the other patches)
> 
> If you really believe users should suffer a 30-minute rebuild for
> a build-time fix, sure.
> 

sounds like the prudent thing to do to let it live a while in ~arch a
while still.

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: [PATCH] sys-devel/autoconf: Convert from eblits into an eclass, #586424

[Kristian Fiskerstrand]

On 03/21/2017 11:00 AM, Alexis Ballier wrote:
> On Tue, 21 Mar 2017 10:41:58 +0100
> Kristian Fiskerstrand <k...@gentoo.org> wrote:
> 


> yes, that's the naming i suggested in the part you cut :)

Indeed

> 
> but then you'd need boilerplate duplicated code to ensure nothing but
> the dedicated package can use that, and still, this doesn't rule out

Or just a policy, technical solutions isn't needed for everything, and
it'd make it explicit that should not be depended on by others so can't
complain about breakages etc.

> overlays: you can atomically change cat/pkg/*.ebuild, cat-pkg.eclass,
> but then an overlay with cat/pkg and ::gentoo as master will break if
> it didn't copy cat-pkg.eclass.
> 
> with eblits in e.g. $FILESDIR, $FILESDIR points to the overlay's
> location so it is clear that changing it in ::gentoo wont affect the
> overlay.
> (that's probably something to add to the 'pros' section too actually)
> 

Interesting..

> I'm one of those that believe "if you exposed an API, then it becomes
> public and you have to maintain that properly; no matter if there are
> obvious consumers or not, since the possibility exists you have to
> account for that", which is what happens with every eclass wrt overlays.
> 

Depends on the stated policies, but in general I agree it is a good
approach to plan like it is (and quite useful to ensure planning a bit
instead of just rolling something out).

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: [PATCH] sys-devel/autoconf: Convert from eblits into an eclass, #586424

[Kristian Fiskerstrand]

On 03/21/2017 10:17 AM, Alexis Ballier wrote:
> On Tue, 21 Mar 2017 09:43:37 +0100
> Kristian Fiskerstrand <k...@gentoo.org> wrote:


> (up to discussion ofc)
> 
> Pros for eblits vs the above eclasses:
> - Let eclass/, which is a toplevel directory, be a place for code
>   useful to several packages, not a random dump of whatever people want
>   to share between ebuilds of the same package (yes, I'm looking at
>   you toolchain or apache2.eclass :) ).
> - Eblits being in package directory, repoman checks can be extended to
>   look there.
> - Have a guarantee that eblits are specific to a single package and
>   cannot "leak" to others by mistake: It greatly simplifies changing
>   and updating them.
> - Eblits can be versionned, just the same as ebuilds or eclasses, but
>   old versions have a life expectancy more of the order of an ebuild
>   than that of an eclass. "Newborn" eblits would be expected to be
>   much more frequent than eclasses but less frequent than ebuilds.
> - Eblits being per-package they'd obey to package rules, not eclass
>   rules wrt additions, removals, api-preservation, etc.

This would be a policy question more than a technical one; we could
decide e.g on a package-namespace[a] for eclasses following similar
laxer rules[b].

> 
> Cons:
> - Need a new, somewhat redundant, mechanism.
> - Can be done without new EAPI but is then restricted to src_* phases.
> - Very few consumers at the moment (though, considering the current
>   crusade that's not really a relevant metric to me).
> 

Endnotes:
[a] without changing any PMS (since review requirement is gentoo
specific) it could be done by namespacing using hyphen or whatnot
instead of separate directory.

[b] to the extent more review isn't becoming the de-facto way forwards
for all ebuilds anyways (we'd need better tooling)

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: [PATCH] sys-devel/autoconf: Convert from eblits into an eclass, #586424

[Kristian Fiskerstrand]

On 03/21/2017 09:28 AM, Joshua Kinard wrote:
> In general, the concept of code-sharing common blocks of logic between 
> multiple
> ebuilds in a specific package directory that is not a top-level eclass is not
> entirely without merit.  But the only way this idea can be realized in a
> suitable manner and be used by far more consumers than today's eblits are, is
> to either find and finish the old elibs GLEP or start one over from scratch,
> submit whatever needs submitting via patches to at least PMS and Portage, work
> through whatever processes are required for approval, and then deploy it in 
> the
> next EAPI.
> 
> If anyone is game for working something up or discussing further, let me know.

I personally fail to see good reasons to have a separate approach for
this instead of putting it in the eclass framework. However this might
simply mean I'm missing something in the discussion.

Before restarting such a GLEP process; maybe a simple pros and cons list
of comparison of the future eblit use and existing eclass structure
could be helpful? (along with more description of the differences)

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: new package category: net-vpn

[Kristian Fiskerstrand]

On 03/17/2017 02:57 PM, Jason A. Donenfeld wrote:
> Done.
> 
> https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=7f68c86d93d5f69d775bceb3941b3a3b46672eb1
> 

... That was quick...

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] RFC: Pre-GLEP: Security Project

[Kristian Fiskerstrand]

On 03/15/2017 08:12 AM, Alexis Ballier wrote:
> On Tue, 14 Mar 2017 19:55:44 -0400


> 
> 
> Agreed, but I was under the impression that sometimes sec. team was
> waiting for cleanup to close a bug. If you've just done the analysis
> that it is the only thing left, just do it and close the bug, instead
> of pinging on the bug and re-do that analysis in a later pass. This
> reduces context switches and makes everything more efficient :)
> 


Indeed, although it should be noted that the amount of context switches
is reduced by using whiteboards to tag status along with version
information in summary, which is why it is important they follow
security team policies for security bugs.

In particular the whiteboard status allows for effective filtering when
creating work-lists to reduce context switching (so if you're a
maintainer starting a stablereq, feel free to update whiteboard from
ebuild to stable!)

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] RFC: Pre-GLEP: Security Project

[Kristian Fiskerstrand]

On 03/13/2017 08:38 PM, Thomas Deutschmann wrote:
> On 2017-03-12 19:35, Kristian Fiskerstrand wrote:
>>> Why do Security Project members need to be ebuild devs?
>>> Non ebuild developers can contribute by producing GLSAs, 
>>> for example.
>>
>> Where is that requirement stated?
> 
> I agree with Roy. That's also my reading of
> 
>>  * The applicant must have successfully completed the Gentoo Developer quiz.
> 
> I agree with that requirement for a full membership (nobody would share
> not yet disclosed vulnerabilities with us if he/she can't be sure that

now I'm even more lost. Gentoo Developer quiz does not imply ebuild
repository access, we have current developers in the project without
tree access and they are doing an outstanding job, so depending on the
definition of "full membership" 


-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] RFC: Pre-GLEP: Security Project

[Kristian Fiskerstrand]

On 03/11/2017 11:23 PM, Andrew Savchenko wrote:
> While the Deputy may be assigned, this still gives all power to
> single hands. Maybe it will be better to establish something like
> the Security Project Council (SPC)? E.g. three project members may
> be elected to this SPC, so that all serious decisions will require
> some team agreement from at least 2 SPC members. This way the
> Deputy will not be needed as well.

Something like this has been discussed. I personally don't like the
approach too much given that it adds a certain degree of bureaucracy and
can remove responsibility. An important part of the GLEP is that the
project lead is responsible to the council for the changes that is made.
Having possibility to overrule that by members would mean that the lead
is not able to control the action, and as such, can't be responsible for
it. If the members disagree with the lead they can call for re-election
as per GLEP:39 already.

As discussed in another sub-thread, however, will try to incorporate
more of the procedure in the vulnerability treatment policy etc into the
GLEP such that procedures are more in focus.

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] RFC: Pre-GLEP: Security Project

[Kristian Fiskerstrand]

On 03/12/2017 11:05 PM, Alexis Ballier wrote:
>> The severity levels and timelines are already defined in the
>> referenced vulnerability treatment policy. We might be able to
>> incorporate this suggestion by stronger reference to that for
>> timeline, but in the end that should be the internal policy anyways.
> 
> To me, this is the only thing that is *not* internal here.
> 
> You have a target delay X. What happens after X expires ? After 2X ?
> 10X ? When is it right for sec. team to intervene ? When is it right
> for sec. team to intervene after maintainer has asked for a delay ? When
> is it right for sec. team to intervene against maintainer wishes ?
> 
> I'm pretty sure you have a good idea of when sec. team should act, and
> you're right in the sense that severity analysis does not belong to the
> GLEP, but something referencing your treatment policy and explicitly
> stating in the GLEP that (any member of) sec. team is allowed to take
> action after some multiple (possibly one) of the target delay would be
> more clear and avoid entirely having the lead to take a decision every
> time.

makes sense, will try to write up some more info on this in GLEP, while
still referencing the vulnerability treatment policy for the actual
information as that needs to be possible to update from time to time.

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] RFC: Pre-GLEP: Security Project

[Kristian Fiskerstrand]

On 03/12/2017 09:14 AM, Alexis Ballier wrote:
> Most of it seems more appropriate for a project page to me and up to
> the sec. team, so I'll comment on the global parts only.
> 
> The only global part I see is the "Security package version/revision
> bumps and package masks". This one would benefit from a proper
> definition of the rules here: If severity is X then inactive is defined
> to be Y days. After that, sec. team can fix themselves. It should also
> be the same for masking: If severity is X and no fix is known after Y
> days/months then sec. team should mask it (but not last rite it, this
> should still be maintainer/treecleaners).

The severity levels and timelines are already defined in the referenced
vulnerability treatment policy. We might be able to incorporate this
suggestion by stronger reference to that for timeline, but in the end
that should be the internal policy anyways. In general I would prefer
the GLSA to be more higher level as we know things are going to need to
be updated from time to time on these matters.

> 
> I think the delay should be clearly stated in the bug with something
> like: Please keep in mind that since this is a remote code execution
> vulnerability, security team will take action if nothing happens within
> one week. If you have tools filling the severity fields then a proper
> definition allows to automate this too.
> 
> My point here is to avoid having all the responsibility falling under
> the lead but focus more on getting things done and educating fellow
> developers: Lower delays for more serious bugs will make people
> understand and prioritize better the issues at hand and their
> implications.

The lead sets policies and is responsible for keeping vulnerability
treatment policy and other documentation up to date c.f Documentation of
process

The Project shall have procedures in place to document its process and
regularly update the documentation including the Vulnerability Treatment
Policies[3].

^^ which was intended to cover some of these concerns

> 
> 
> Also, it'd be nice to have something more formal for sec. cleanup:
> "After 30 days a sec. issue has been fixed, sec. team is free to
> cleanup old vulnerable versions.". I've seen too much pings by sec.
> team members on old bugs for this and they could have spent the same
> amount of time simply doing it instead.

This presumes all security members are gentoo developers with tree
access and can do it themselves, but I'm not convinced cleanups are
vital enough for security to interact as it requires quite a bit of work
for an unfamiliar package to know which files to remove in files/ for
specific versions and/or other package-specific quirks. The package
maintainers really should be able to handle this or hand off the package
to someone else.

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] RFC: Pre-GLEP: Security Project

[Kristian Fiskerstrand]

On 03/12/2017 07:19 AM, Walter Dnes wrote:
> - Typo...
> Additional Security Project bugzilla notes
> * The Security Project is except (should that read "exempt"?)

Thanks, fixed

> 
> 
> 
> - An intermediate level before masking might be issuing a warning if
>   some simple, specific remediation measure can protect against a
>   vulnerability.  E.g. forcing cups to only listen to 127.0.0.1 or :1

Mitigations like these are mentioned in the GLSA

> 
> - If you want to absolutely ensure that people are warned of a severe,
>   but remediable vulnerability, is it acceptable to "break the build"
>   by requiring a new local USE flag for the ebuild?  I'm thinking of
>   something like "glep_0001234", "glep_0001235", "glep_0001236", etc,
>   and have the ebuild die if the flag is not set, and print out a URL
>   for a security problem.  This could be abstracted to make.conf with
>   a new variable...
> 
>   GLEP="0001234 0001235 0001236 etc etc"

Sounds like a lot of complexity for limited value.

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] RFC: Pre-GLEP: Security Project

[Kristian Fiskerstrand]

On 03/12/2017 03:55 AM, Rich Freeman wrote:
> On Sat, Mar 11, 2017 at 6:54 PM, Kristian Fiskerstrand <k...@gentoo.org> 
> wrote:
>> On 03/11/2017 11:23 PM, Andrew Savchenko wrote:
>>>
>>> My point is that users must be informed about security problem, but
>>> they still should have a choice. So it should be either a rule
>>> "mask without removal" or clear guidelines when to remove a
>>> package and when to not.
>>
>> At some point, of a package does not belong in the main tree due to
>> security vulnerabilities, they can still be kept in an overlay by a
>> respective project without it impacting other users. I'm not convinced
>> that impacts the overall user experience of other Gentoo users.
>>
> 
> Is there any reason that this can't be left to maintainer discretion?
> The package is masked and clearly advertises its security issue.  The
> user can make an informed choice.  Do we really need to force the
> issue further?  What is the benefit to Gentoo in doing so?
> 

In most cases lack of maintainer participation is likely the issue to
begin with. The primary issue with a package mask of this nature is that
it is more permanent than temporary in nature. To what extent would
other package maintainers need to take it into consideration e.g wrt
depgraph breakages (say this is a lower slotted version or last version
that supports a specific arch).

Granted that isn't much of an issue from the security point of view, but
goes more over on QA - the primary reason it isn't explicit in the draft
GLEP is that specific rules are difficult to write to cover all
situations and as such needs either a lot of preparation to write or
will cause issues down the line. The accountability aspects of things is
therefore more important than the rules themselves.

Quite frankly I thought I left enough of maintainer discretion when
stating:
* The Security Project does not want to override the maintainer's
autonomy, but
  if inactive might be required to fix a security vulnerability by means of
  version bump or application of a patch in a revision bump.
* If a vulnerability is unlikely to be fixed by upstream or the
package's maintainer
  it might require a package mask. Such mask should never break the
stable dependency tree.

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] RFC: Pre-GLEP: Security Project

[Kristian Fiskerstrand]

On 03/12/2017 07:11 PM, Roy Bamford wrote:


> 
> Why do Security Project members need to be ebuild devs?
> Non ebuild developers can contribute by producing GLSAs, 
> for example. 

Where is that requirement stated?

> 
> Who manages the Security Project (from outside).  It appears from
> the draft GLEP, nobody.  That means that the project could become 
> moribund and nobody would notice.  Its not like Gentoo enforces 
> or even checks for leadership elections. That's an anual event 
> anyway, so its not a measure of a projects continued well being. 
> 

Imposing too much bureaucracy and reporting might not be worthwhile, the
security project's work is relatively easy to monitor in bugzilla
activity and GLSA publication to begin with, less so for auditing, but
that has always been specific to available resources.

> 
> This isn't really a Security Project issue. If its ever needed, the 
> Security Project isn't active. It affects other projects too, like
> comrel, QA and others. Perhaps there is a common solution
> to taking a proqcts pulse and reacting when there is none.  
> 

Talking with the lead of respective projects should be a good start
without need for specific procedures. One could imagine participation
from various special projects in council meetings or just email
exchanges, but it'd likely just end up with a bunch of "nothing new from
the western front" that can more easily just be updated informally
anyways if anyone is concerned.

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] RFC: Pre-GLEP: Security Project

[Kristian Fiskerstrand]

On 03/11/2017 11:23 PM, Andrew Savchenko wrote:
> Hi Kristian,
> 
> On Sat, 11 Mar 2017 21:50:51 +0100 Kristian Fiskerstrand wrote:
>> A draft of a Pre-GLEP for the Security project is available for reading
>> at https://wiki.gentoo.org/wiki/User:K_f/GLEP:Security
>>
>> The GLEP follows a line of GLEPs for special projects that have
>> tree-wide access in order to ensure proper accountability (c.f GLEP 48
>> for QA and still non-produced GLEP for ComRel (I've started working on
>> this and will be presenting this one later as current ComRel Lead))
>>
>> Comments, patches, threats, etc welcome
> 
> First of all, thank you for this Pre-GLEP, since we really need some
> public and established policy for the Security project.
> 
> 1. From this proposal it looks like the Security Project Lead
> obtains a lot of power and a lot of responsibility, maybe too much
> for a single person to handle.
> 
> While the Deputy may be assigned, this still gives all power to
> single hands. Maybe it will be better to establish something like
> the Security Project Council (SPC)? E.g. three project members may
> be elected to this SPC, so that all serious decisions will require
> some team agreement from at least 2 SPC members. This way the
> Deputy will not be needed as well.
> 

The thinking here is that the project lead is the responsible party. Any
ambiguity can still be escalated to the Gentoo Council, but someone
needs to be responsible from the side of the Gentoo Security Project.

> 2. "If a vulnerability is unlikely to be fixed by upstream or the
> package's maintainer it might require a package mask." — I'd like
> to see this expanded to more detail, because it is possible to mask
> for removal and to simply mask without scheduled removal.
> 
> Sometimes an application is desirable even if it is vulnerable,
> e.g. if there are no alternatives. Sometimes a vulnerability is
> minor or affect a very rare use case. Sometimes users need a
> specific software version for their workflow and they don't really
> care about security — this affects many scientific packages being
> used at isolated HPC setups.
> 
> My point is that users must be informed about security problem, but
> they still should have a choice. So it should be either a rule
> "mask without removal" or clear guidelines when to remove a
> package and when to not.

At some point, of a package does not belong in the main tree due to
security vulnerabilities, they can still be kept in an overlay by a
respective project without it impacting other users. I'm not convinced
that impacts the overall user experience of other Gentoo users.


-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] RFC: Pre-GLEP: Security Project

[Kristian Fiskerstrand]

A draft of a Pre-GLEP for the Security project is available for reading
at https://wiki.gentoo.org/wiki/User:K_f/GLEP:Security

The GLEP follows a line of GLEPs for special projects that have
tree-wide access in order to ensure proper accountability (c.f GLEP 48
for QA and still non-produced GLEP for ComRel (I've started working on
this and will be presenting this one later as current ComRel Lead))

Comments, patches, threats, etc welcome

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] new virtual -- virtual/go to fix go build time dependencies

[Kristian Fiskerstrand]

On 03/09/2017 05:06 PM, Michael Orlitzky wrote:
> "How do we update insecure libraries?" would have been a good question
> to ask *before* adding Go to the tree, because the answer is pretty
> clearly "we can't." 

As it is now, if a go-package is to be in stable tree; the package
maintainer adding a go package will need to keep track of relevant
dependencies that are embedded and do a revdep of the package if a
vulnerability in the chain is discovered.

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Removal of CVS headers

[Kristian Fiskerstrand]

On 02/26/2017 09:16 PM, Lars Wendler wrote:
> Now QA again wants to do a questionable action _without_ any approval
> from neither infra nor council.

The council has reached a majority for the following statement in [bug
Bug 611234 - Council vote: CVS headers and git expansion]

"""
The council confirms its earlier decision (2014-10-14 meeting) to drop
CVS headers after migration to Git.

1) Any $Id$ and $Header$ lines are to be removed from ebuilds and
eclasses in the gentoo repository, as well as from other files, e.g.,
metadata, profiles, and files (except patches) in FILESDIR.

2) Removal should be done at once, and a repoman check should be
implemented to prevent such lines from accidentally being inserted again.

3) Infra is asked not to expand any $Id$ or other keywords, neither at
rsync generation time, nor via git attributes in the development
repository."
"""


References:
[bug Bug 611234 - Council vote: CVS headers and git expansion]
https://bugs.gentoo.org/611234

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Printer drivers and net-print

[Kristian Fiskerstrand]

On 02/28/2017 03:00 AM, Kent Fredric wrote:
> That way people don't get tricked into reading PMS and then using it as 
> grounds
> to break Gentoo policies.
> 
> It *should* go without saying, but its better to be assume the reader doesn't 
> know
> what "should go without saying" entails. 

Sounds odd to add something like this to a spec, that is an
organizational training issue.

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Printer drivers and net-print

[Kristian Fiskerstrand]

On 02/27/2017 03:30 AM, NP-Hardass wrote:
> Might be best that this not be a PMS thing, but a Gentoo-specific
> recommendation for developers conveyed via the Devmanual.  That's
> typically the place where Gentoo specifics are added in, like "New
> virtuals shouldn't be added without posting on the Gentoo mailing list,"
> etc.

+1

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: dev-util/wxglade/files/, dev-util/wxglade/

[Kristian Fiskerstrand]

On 02/20/2017 08:50 PM, Mart Raudsepp wrote:
> Have respect towards others and their wishes and their maintenance and
> don't run over other people and maintainers. Do not run over
> maintainers after a 3 hour period of bug filing 

This seems like an overall good recommendation to remember after reading
this thread

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Printer drivers and net-print

[Kristian Fiskerstrand]

On 02/20/2017 11:11 PM, Matthew Thode wrote:
> On 02/20/2017 03:47 PM, Andreas K. Huettel wrote:

>>
>> What do you think?

> The question to me is 'is there a great enough need to
> go through the pain of this?'.

I would agree with this sentiment. The lesson is to put more care into
naming categories to begin with so they are sufficiently broad to
contain a useful set of packages, but moving it around after the fact
causes more complexity than I would normally consider useful.

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] RFC: small cleanup of flag-o-matic.eclass

[Kristian Fiskerstrand]

On 02/12/2017 01:58 PM, Alexis Ballier wrote:
> On Sun, 12 Feb 2017 10:28:13 +0100
> Ulrich Mueller <u...@gentoo.org> wrote:
> 
>> See patch below. The has_m64 function is no longer used in the tree.
> 
> I think it'd be better to lock the removal with a new EAPI for
> overlays / downstreams.
> 

Sounds reasonable

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Eix and deps up for grabs

[Kristian Fiskerstrand]

On 02/11/2017 05:19 PM, Ian Stakenvicius wrote:
> Hey all - since I have never really been maintaining these properly
> and as the last commits to these packages have been from other devs,
> its time for the metadata to properly reflect this.  If anyone's
> interested, could you please take up these packages?
> 
> app-portage/eix
> app-shells/push
> app-shells/quoter
> 

Seems all of these have an existing maintainer through proxy maint
and/or other developers already, so should be safe to just remove
yourself from metadata.

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] RFC: Introducing stable profiles for arm64 (aarch64)

[Kristian Fiskerstrand]

On 02/06/2017 03:59 AM, Mart Raudsepp wrote:
> Lots of concerns, I see from the zero replies so far 

Keep in mind that quite a few have been at FOSDEM this weekend, so I
wouldn't take no response from a high number of european devs as a sign
of acceptance just yet.

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] rfc: moving OpenRC to a meson-based build

[Kristian Fiskerstrand]

On 02/03/2017 10:10 AM, Benda Xu wrote:
> William Hubbs <willi...@gentoo.org> writes:
> 
>> I have been looking at the meson build system [1] [2], and I like what I
>> see.
>>
>> I have opened an issue on OpenRC's github wrt migrating OpenRC to the
>> meson build system [3].
>>
>> As I said on the bug, the downside is the addition of py3 and ninja as
>> build time dependencies, but I think the upside (a build system where
>> we don't have to worry about parallel make issues or portability)
>> outweighs that.
>>
>> What do folks think here?
> 
> I would discourage it.  Making OpenRC build-depend on python introduces
> unnecessary complexity that will undermine the portability of OpenRC
> sooner or later.
> 
> After all OpenRC is a small program easy to build with a hand-written
> Makefile.
> 
> Parallel make issues?  No problem let's just solve it.
> 
> 
> Please, keep it simple.

I'm adding my support to this sentiment


-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Guidelines for IUSE defaults

[Kristian Fiskerstrand]

On 02/02/2017 03:11 PM, Michael Orlitzky wrote:
> Can we discourage IUSE defaults except for #1 and #2? I'm equally guilty
> of #3 and #4, but I now regret them. I would also like to see
> explanations in metadata.xml of why +flags are on by default.

This presumes that the goal is minimal system in all cases, rather than
a good user experience for inter alia a desktop system or a
server-system. If a user requires a minimal system for whatever reason
(s)he is likely more prepared to understand the choices than the average
user.

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Last rites: leechcraft

[Kristian Fiskerstrand]

On 01/31/2017 03:50 PM, Georg Rudoy wrote:
> I'll make a new release of leechcraft itself and bump the version to
> that new one, so they'll naturally be dropped to unstable, 0.6.70 and
> earlier (if any) indeed could be removed. Most of the bugs, as I saw
> them, are due to the current last released version being 2.5 years old
> and obviously bitrotten somewhat since then.

I'd still recommend spending a bit of time to consider whether this
doesn't fit better in an overlay, which would also make it easier to
maintain without overburdening proxy maint given the number of packages
involved.

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Requirements for UID/GID management

[Kristian Fiskerstrand]

On 01/30/2017 07:22 PM, Michael Orlitzky wrote:
> On 01/30/2017 01:05 PM, Patrick McLean wrote:
>>
>> No, that is also enabled by default on vanilla kernels, I just verified
>> on my machine running a vanilla kernel. It doesn't matter anyway, since
>> the permissions and ownership information is stored in the inode, not
>> the dentry so all hardlinks have exactly the same permissions.
>>
> 
> I don't believe you =P
> 
> Check https://github.com/torvalds/linux/blob/master/fs/namei.c:
> 
>   int sysctl_protected_symlinks __read_mostly = 0;
>   int sysctl_protected_hardlinks __read_mostly = 0;
> 
> And compare with:
> 
> https://gitweb.gentoo.org/proj/linux-patches.git/tree/1510_fs-enable-link-security-restrictions-by-default.patch?h=4.9
> 
> The fact that all permission and ownership information is shared is
> precisely the problem. When you change ownership of the hardlink (which
> you'll never know is a hardlink), you change ownership of /etc/shadow.
> 
> 

To provide some background for this, it was included in mainstream
kernel at one point but caused userland regression in some edge cases so
was removed again.

It is already discussed at least on [0] and it seems the behavior was
turned the other way around in [1]: "In commit 800179c9b8a1 ("This adds
symlink and hardlink restrictions to
the Linux VFS"), the new link protections were enabled by default, in
the hope that no actual application would care, despite it being
technically against legacy UNIX (and documented POSIX) behavior.

However, it does turn out to break some applications.  It's rare, and
it's unfortunate, but it's unacceptable to break existing systems, so
we'll have to default to legacy behavior.
"

You'll find some more discussion around this in e.g [bug 540006]

References:
[0] http://lwn.net/Articles/521626/
[1] http://www.spinics.net/lists/stable-commits/msg21052.html
[bug 540006] https://bugs.gentoo.org/show_bug.cgi?id=540006

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] berkdb and gdbm in global USE defaults

[Kristian Fiskerstrand]

On 01/27/2017 05:46 PM, William Hubbs wrote:
>> It breaks the highly sought after "Gentoo is about choice" mantra.
>> In this case, choice to not care and have the best chosen for me.
> Actually it doesn't. In this case the user should make a choice rather
> than the maintainer silently making a choice behind their back.

There is an argument to be made for sane defaults in profiles as well as
default IUSE specification in this though to provide a better user
experience, but the underlying mechanism should be explicit.

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] berkdb and gdbm in global USE defaults

[Kristian Fiskerstrand]

On 01/27/2017 01:01 PM, Dirkjan Ochtman wrote:
> On Fri, Jan 27, 2017 at 8:54 AM, Mart Raudsepp <l...@gentoo.org> wrote:
>> Ühel kenal päeval, N, 26.01.2017 kell 22:33, kirjutas Mike Gilbert:
>>> I recently ran into a REQUIRED_USE constraint that required I select
>>> between berkdb and gdbm for an email client.
>> There shouldn't be a REQUIRED_USE constraint that forces you to select
>> one or the other. The maintainer should be giving the choice of both,
>> but if only one can be chosen, the maintainer should make the choice
>> for you by preferring one of them. Likely gdbm, given berkdb licensing
>> saga.
> I'm not sure this makes sense to me. If the package will actually
> select one implementation out of a set, it makes sense to me that the
> maintainer for that package makes that choice explicit towards the
> user. In that case, setting REQUIRED_USE accordingly seems exactly
> right. The maintainer should set a good default, but if the user's USE
> settings are inconclusive in getting to the choice of implementation,
> it's better to whine explicitly than try to guess implicitly what the
> user wanted.

I tend to agree with this sentiment, explicit over implicit behavior
ensures better debugging ability and security considerations.

> 
> On Fri, Jan 27, 2017 at 9:32 AM, Fabian Groffen <grob...@gentoo.org> wrote:
>> Replying here because I think said email client is the one I recently
>> added REQUIRED_USE constraints for.
>>
>> Reason I added it is because it greatly simplified the ebuild: it's not
>> just bdb and gdbm, but also tokyocabinet, qdbm and lmdb, with as result
>> a lot of if-else-casing which implemented the implicit defaults before.
>> I didn't realise changing this to REQUIRED_USE resulted in a conflict on
>> default profiles, because I (obviously) have a package.use entry for the
>> package.
> I don't see Mike saying you got it wrong here. Reading your email, I
> think you did the right thing.

Yup

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] News item review: python-exec 2.3 reclaims python* symlinks

[Kristian Fiskerstrand]

On 01/21/2017 06:05 PM, Michał Górny wrote:
> On Sat, 21 Jan 2017 17:36:27 +0100
> Kristian Fiskerstrand <k...@gentoo.org> wrote:
> 


..

>>
>> How was this allowed into stable?
> 
> I know things like this don't ever happen in your beloved perfect
> corporate world but mistakes happen. FYI, in open source you usually
> report a bug instead of bitching on a semi-related topic on a mailing
> list.

How is it semi-related? the news item implies it only causes warning ,
while I'm pointing out it inflict actual damage / brokenness?

As for reporting a bug, you are of course correct, but I was still in
process of determining if it was only a local issue when noticing the ML
on the related issue to begin with.

I'm still curious how it got into stable

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] News item review: python-exec 2.3 reclaims python* symlinks

[Kristian Fiskerstrand]

On 01/21/2017 05:36 PM, Kristian Fiskerstrand wrote:
> This change broke a stable system in my case without any of these features.

without any of these features enabled explicitly...

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] News item review: python-exec 2.3 reclaims python* symlinks

[Kristian Fiskerstrand]

On 01/21/2017 10:49 AM, Michał Górny wrote:
> Please review the following news item. It was requested by users.
> Preferably I'd like to commit it today.

..

> 
> If you are using FEATURES=collision-protect, Portage will reject
> the upgrade. If this is the case, please temporarily switch to
> FEATURES=protect-owned for the upgrade.
> 
> If you are using FEATURES=protect-owned, Portage will verbosely warn
> about the file collisions but will proceed with the upgrade once
> determining no replaced files are owned. Please disregard the warning.

This change broke a stable system in my case without any of these features.

world upgrade failed with  * ERROR: dev-python/pycairo-1.10.0-r5::gentoo
failed (configure phase): due to
/usr/bin/env: ‘python’: No such file or directory

system ended up with a broken symlink
lrwxrwxrwx 1 root root 14 Jan 21 13:55
 /usr/bin/python -> python-wrapper

additionally the original upgrade, after manually setting the updated
symlink, ended up with a
python-exec: Invalid impl in /etc/python-exec/python-exec.conf: python3.3

How was this allowed into stable?

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: The changes about the stabilization process

[Kristian Fiskerstrand]

On 01/04/2017 08:09 AM, Michael Palimaka wrote:
> On 04/01/17 12:57, Andrew Savchenko wrote:
>> Hi all,
>>
>> On Sun, 25 Dec 2016 22:55:27 +0300 Andrew Savchenko wrote:
>> [...]
>>> Another question: do we steel need to set STABLEREQ keyword for
>>> stabilization bugs? Since we now have a dedicated Stabilization
>>> component, STABLEREQ looks redundant.
>>
>> Ping here.
>>
>> Best regards,
>> Andrew Savchenko
>>
> 
> With the changes, STABLEREQ and KEYWORDREQ indeed become redundant.
> 
> That said, it's entirely possible some arch team members are relying on
> these keywords for old saved searches etc. With so many people working
> in isolation, it's difficult to know who is doing what.
> 

Not sure if I like this, isn't it anyways still required for security
vulnerabilities bumping etc, so now we have a branching of processes
depending on project/category selections that needs to be taken into
consideration?

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

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

[Kristian Fiskerstrand]

On 01/03/2017 03:57 PM, Michael Mol wrote:
> For security's sake, even mature software needs, at minimum, routine 
> auditing. 
> Unless someone's doing that work, the package should be considered for 
> removal. (Call that reason #  π, in honor of TeX.)

A distinction here likely needs to be made between actively maintained
upstream and actively Gentoo maintained as well. Actively maintained
upstream might not be an issue for a feature complete package, but if it
lacks a Gentoo-maintainer in addition it is worrying.

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] RFC: global USE c++11

[Kristian Fiskerstrand]

On 01/02/2017 10:34 PM, Justin  wrote:
> 
> Seems to be very consistent in usage.

But I'm not convinced it is a correct approach to have use flag changing
this. First thing that springs to mind is if introducing something like
that it should be done consistently across Gentoo, so a GLEP. But
presumably a lot of packages are already built using C++11 without a use
flag given Qt5.7 requiring it etc.

If using C++11 enables different features the feature should be the use
flag rather than C++11. Couldn't this just be determined using Autotools
etc? What is the gain of the use flag? Immediately it sounds like it
adds complexity without much gain.

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: The changes about the stabilization process

[Kristian Fiskerstrand]

On 12/29/2016 01:08 PM, Ulrich Mueller wrote:
>>>>>> On Thu, 29 Dec 2016, Michael Palimaka wrote:
> 
>>> Any suggestions for improved text? Ideally it would be
>>> stabilisation/keywording agnostic as the same field is used in both
>>> components.
> 
>> ago suggested "Packages list" or "Package list" - thoughts?
> 
> Isn't it rather a list of "ebuilds" or "package versions"? That's the
> term which https://devmanual.gentoo.org/keywording/index.html uses.

${PF}-list? :)


-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [rfc] New global USE flag: rbd

[Kristian Fiskerstrand]

On 12/26/2016 08:45 AM, Andrew Savchenko wrote:
> 8 packages are using either rbd or rados USE flag for Rados
> Block Device support:

Are there other possibly conflicting issues of using "rados" rather than
"rbd" as name (or "radosbd") or someting a bit more verbose than rbd.

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

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

[Kristian Fiskerstrand]

> On 12/21/2016 11:23 PM, i...@gentoo.org wrote:
Why is this email sent using an invalid email addresse in FROM?

As for the rest of the email content itself, please consider the
appropriate forum for any discussion, and I strongly recommend staying
away from personal attacks.

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

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

[Kristian Fiskerstrand]

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)


-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

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

[Kristian Fiskerstrand]

On 12/07/2016 06:07 AM, Robin H. Johnson wrote:

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

You likely want to check out [gentoo-proxy-ma...@lists.gentoo.org]
instead of the project alias. The latter is restricted to Gentoo developers.

References:
[gentoo-proxy-ma...@lists.gentoo.org]
https://archives.gentoo.org/gentoo-proxy-maint/

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] rsync.gentoo.org rsync modules: ChangeLogs dropped from gentoo-portage

[Kristian Fiskerstrand]

On 11/17/2016 07:03 PM, Zac Medico wrote:
> On 11/16/2016 02:25 PM, Robin H. Johnson wrote:
>> On Wed, Nov 16, 2016 at 01:54:05PM -0500, Brian Evans wrote:
>>> Non-existent MISC files are ignored.
> 
> That has been true since Manifest2 was implemented, in Portage 2.1. It
> has allowed those who don't want ChangeLogs to exclude them via rsync
> excludes.
> 
>>> But when they do exist, they are checked like every other file which may
>>> be a misinterpretation of the GLEP.
>> The tree-signing GLEP that updates Manifest2 is clear to state that MISC
>> files which mismatch between disk and Manifest should generate a
>> non-fatal warning unless some strict mode is in effect.
> 
> The mismatch case is not supported yet. Can I get a link to the relevant
> portion of the GLEP? The most detailed information I could find on MISC
> entries was here:
> 
> https://wiki.gentoo.org/wiki/GLEP:60#MISC
> 

Fwiw, from my own perspective; not allowing mismatches if file exists
makes perfect sense.

Also GLEP says:
 * MISC entries where the file is missing may optionally be ignored as
by non-strict package managers.
 * It should be possible to install a package while all MISC entries
have been deleted from the tree.

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: Stabilisation procedure

[Kristian Fiskerstrand]

On 11/17/2016 02:47 PM, Michael Palimaka wrote:
> On 18/11/16 00:26, Kristian Fiskerstrand wrote:
>> Strictly speaking GLEP 40 forbids it still, although some arch teams
>> have made announcements to approve it, see e.g [1,2]. I wouldn't be
>> surprised if one of the results of the stable WG is an updated GLEP 40
>> that (new GLEP replacing existing) that allows for MAINTAINER
>> self-stabilization. Personally I don't like "any developer may perform"
>> part of it. The maintainer is responsible, and should at least ack
>> stabilization at all before anything is stabilized (for arch-team
>> stabilization as well), and consequently individual stabilizations by
>> developers, either the maintainer itself or someone with applicable
>> hardware.
> 
> Isn't it implied that any stabilisation is approved by the maintainer?
> Has it ever been acceptable to go around stabilising random packages?
> 

Explicit > Implicit when we're updating things anyways.

There are scenarios where e.g Security is calling for stabilization ,
I'll add some info to the draft security GLEP with some requirements for
when this can happen without maintainer involvement as well..

Ultimately maintainer is responsible for the state of the stable tree
for the packages they maintain and should be taking proactive steps for
this also for security bugs, it doesn't "always" happen like that.

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Stabilisation procedure

[Kristian Fiskerstrand]

On 11/17/2016 01:49 PM, Michael Orlitzky wrote:
> On 11/17/2016 02:16 AM, Michael Palimaka wrote:
>>
...
> 
>> === amd64 ===
>> * Any developer may perform {{keyword|amd64}} stabilisations - it is not
>> necessary to be on the arch team
>>
>> === x86 ===
>> * Any developer may perform {{keyword|x86}} stabilisations - it is not
>> necessary to be on the arch team
> 
> The arch teams are OK with this now? If so I can go close some STABLEREQs...
> 
> 

Strictly speaking GLEP 40 forbids it still, although some arch teams
have made announcements to approve it, see e.g [1,2]. I wouldn't be
surprised if one of the results of the stable WG is an updated GLEP 40
that (new GLEP replacing existing) that allows for MAINTAINER
self-stabilization. Personally I don't like "any developer may perform"
part of it. The maintainer is responsible, and should at least ack
stabilization at all before anything is stabilized (for arch-team
stabilization as well), and consequently individual stabilizations by
developers, either the maintainer itself or someone with applicable
hardware.

References:
[1]
https://archives.gentoo.org/gentoo-dev/message/355f4b4272c0049cffcdec88d815e267
[2]
https://archives.gentoo.org/gentoo-dev/message/1246dd8fabe44e7e7ecf59ecf029af3e

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Revisiting version-related tree policies

[Kristian Fiskerstrand]

On 11/03/2016 05:11 PM, Michał Górny wrote:
> == Policy changes? ==
> I think that the following new policies could make sense:
> 
> 1. Revision number must be no longer than :

You likely mean "no higher than ", longer than would give large values

> 1a. to make <=X-r reliable,
> 1b. to prevent pathological uses of revision as date.

Given revision in most cases is incremental (except for some -r100,
-r200) cases, some structure here is likely good. I take it we're
talking about devmanual changes in this case for policy?

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Gentoo-specific breakage when building dev-lisp/gcl

[Kristian Fiskerstrand]

On 11/01/2016 04:55 PM, gro...@gentoo.org wrote:
> Any hints please?

This discussion should take place on https://bugs.gentoo.org

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] OpenPGP verification for gentoo-mirror repos

[Kristian Fiskerstrand]

On 10/31/2016 09:34 AM, Michał Górny wrote:
> The major difference between a developer key and an automated key is
> that the latter is far easier target. I think we can trust Gentoo
> developers to at least have their keys encrypted. I suppose most of
> them don't 'git log -p' the commits their sign but well, it's still
> harder to target a developer PC than a public server that most likely
> keeps its signature key unencrypted (or with cleartext password).

If you go this route it becomes more complex, as you need the private
key stored on a smartcard to avoid leakage when secret key is handled
in-memory (unencrypted properties - so I don't agree with your argument
that developers store secret key encrypted). This is a lot better due to
process separation in gnupg 2.1 as a parsing error in gpg doesn't have
access to keys in gpg-agent as an example, but it is mostly wrong route
to go on discussion.

tl;dr; A signature by a release key is valuable

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Lastrites: dev-ada/cbind, net-dialup/dtrace, net-nds/lat, app-pda/jpilot-mail, net-dialup/drdsl, dev-util/insight, app-laptop/configure-trackpoint, x11-misc/lxmed, dev-util/ketchup, m

[Kristian Fiskerstrand]

On 10/29/2016 10:25 PM, NP-Hardass wrote:
> If you feel that is too high a maintenance burden, fine, remove them
> all.  I'm merely proposing it be looked at since otherwise we are
> potentially removing packages that don't have to or shouldn't be removed.

If they aren't properly maintained, they certainly should be removed. if
you want to keep them and have fixes for known issues, take over
maintainership

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Lastrites: dev-ada/cbind, net-dialup/dtrace, net-nds/lat, app-pda/jpilot-mail, net-dialup/drdsl, dev-util/insight, app-laptop/configure-trackpoint, x11-misc/lxmed, dev-util/ketchup, m

[Kristian Fiskerstrand]

On 10/29/2016 07:59 PM, NP-Hardass wrote:
> On 10/08/2016 07:57 AM, Pacho Ramos wrote:
>> # Fails to build (#515294), nothing needs it, relies on obsolete
>> capi4kutils. 
>>
> 
> For all the packages being removed due to capi4kutils, how many were
> investigated with net-libs/libcapi?  For WINE, we transitioned to using
> libcapi instead of capi4kutils, and I don't see why some of those
> couldn't as well, provided the capi4kutils is the only reason why those
> are being treecleaned.
> 

Someone needs to take over responsibility for the packages
(maintainership) and fixing the issues then. If not, they should be removed.

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Gentoo on Android stage3

[Kristian Fiskerstrand]

On 10/29/2016 06:22 PM, Benda Xu wrote:
> Kristian Fiskerstrand <k...@gentoo.org> writes:
> 


> 
> I will need first to set up a blog and then draft a writeup.
> 
> Any hints?
> 

You can request a blog from blogs.gentoo.org and ask for it to be
included in planet and universe

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Gentoo on Android stage3

[Kristian Fiskerstrand]

On 10/29/2016 05:36 PM, Rich Freeman wrote:
> On Sat, Oct 29, 2016 at 11:18 AM, M. J. Everitt <m.j.ever...@iee.org> wrote:
>> On 29/10/16 16:14, M. J. Everitt wrote:
>>> On 29/10/16 16:09, Benda Xu wrote:
>>>>
>>>> This is an announcement of the latest Gentoo on Android stage3 tarball,
>>
>> Actually .. given my nosiness in -pr matters lately, anyone done a
>> write-up for Planet.g.o or suchlike that we can post up to social media?
>> From my own stand-point it might be something the wider community would
>> be interested in, and didn't know was a 'thing'?
>>
> 
> It would be a good thing, especially since this relies on Gentoo
> Prefix (I think), which is a fairly unique capability I've yet to see
> in any other distro.
> 

+1

Would certainly like to see a writeup of positive things in a blog post
that can be shared in social media.

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Dealing with GitHub Pull Requests the easy way

[Kristian Fiskerstrand]

On 10/26/2016 04:02 AM, Rich Freeman wrote:
> I did suggest that we probably should ban this header until we
> actually have a DCO because it blurs the lines.  However, it isn't

Makes sense, at least strongly discourage, although it likely isn't too
difficult to do a full ban on git push

> really inferring something that isn't true right now because we don't
> assign any legal meaning to the header right now.  The bigger concern
> is that it blurs the lines after we have a DCO because people can
> argue the use of the header was accidental or meant something else.

This comes back to the next part, and instituting a clear timeline

> 
> Whether or not we proactively ban the header, it would probably make
> sense that if we do institute a new copyright policy including a DCO
> that we ask all devs to explicitly ack the policy and the meaning of
> the signed-off-by header somehow (maybe issue a gpg signed statement
> from a template).  It could also be made a part of the ebuild quiz or
> such so that all new devs ack it.

Exactly (although I'm pleading for people to stop talking about "gpg
signed".. thats nonsense :) OpenPGP ftw)

> 
> I don't think we need to go nuts with it.  Simply getting everybody to
> ack the policy makes it unambiguous that people understand what the
> header means.

+1
> 
> But, new policy or not the DCO really represents a practice that we
> should all be doing already.  Nobody should be sticking code in a
> Gentoo repository without ensuring the licenses are compatible and so
> on.  The DCO just represents a best practice that didn't exist when
> Gentoo started and which most projects now embrace in some form.  It
> isn't that we didn't care about copyright in the past, we just care
> enough to be a little more formal about it in the future.
> 

+1

>> > But this doesn't change the fact there is a desire to communicate other
>> > properties of commits, like the audit trail for QA purposes.
> Sure.  The repository should always make it clear who made each
> commit, when, and why (with appropriate bug x-refs and so on).
> Ideally it should somehow capture both who authored the code and who
> put it into the repository.  I think for the most part we're already
> doing all of this, but I'm sure there is room for improvement (having
> a bug header in the default repoman commit template probably wouldn't
> hurt - then they all look the same and you can always delete it or
> leave it blank if it doesn't apply).

Quality of commit messages certainly leaves something to be desired from
time to time, and actually having said trail of discussion on bugs.g.o

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] need for autotools

[Kristian Fiskerstrand]

On 10/25/2016 05:35 PM, Ian Stakenvicius wrote:
> I forgot to mention that autotools.eclass brings in these dependencies
> as-needed, though, so I agree that they definitely are not required in
> the @system set.

Also keep in mind, they are already not part of @system, the question is
whether to remove the commented out lines to clean up the packages file.

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature