[gentoo-dev] tinderbox infrastructure project

[Paweł Hajdan , Jr .]

On 07/09/2018 15:11, Andreas K. Huettel wrote:
>>  - Invest significantly in Infrastructure spending to fund ambitious
>> projects.
> 
> You need people who work on that first.
> 
> Suggestion: Found a tinderbox project, get toralf, kensington, zerochaos, 
> mgorny, whoelse? on board, integrate this into one nice system with (for 
> authorized users) point-and-click interfaces for bug reporting and public 
> status web pages. *Then*, invest in fat hardware for it.
> 
> Our shortage is not money or infrastructire.
> Our shortage is a) people, and b) cooperation.

I'd be interested in this.

I've been doing infrastructure work for the Chromium project for a few
years, and when done right can be exciting and a good force multiplier
for development.

Being used to a cloud environment (provisioning a VM within minutes,
easy networking, storage, etc, all I can do myself as cloud project
owner without intermediaries or becoming a sysadmin myself). I found it
harder to start on Gentoo infrastructure projects, and having some kind
of private cloud, or Kubernetes-like deployment would IMO help a lot.

Paweł



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] Solving the problem of huge number of wrong LICENSES=*GPL-[23]

[Paweł Hajdan , Jr .]

On 28/08/2018 00:46, Michael Mol wrote:
> I can say that if the licenses are habitually misidentified, I could not use 
> Gentoo's portage tree in my job without extensive and ongoing revalidation of 
> the license metadata.
> 
> There are, in fact, automated tools for advising about the license 
> disposition 
> of these types of things, examining source files for unfortunate edits and 
> variants and flagging them, etc. It might be an interesting task at some 
> point 
> to point some of these tools at portage, look for incorrect metadata and file 
> bug reports.
> 
> Not suggesting this is a worthwhile approach up front, but it might be a 
> useful tool in the future for dealing with license metadata quality as a 
> chronic issue. (Which, in turn, is useful for commercial consumption and 
> participation.)

Given the reality of how open source project works, I believe it's up to
people who care/need this most to do such work in Gentoo.

From what I see, nobody would be opposed to _someone_ making the
metadata more precise. On the other hand, I sense most people don't see
enough benefit to sign up for such work themselves - which I totally
understand.

Paweł



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] Solving the problem of huge number of wrong LICENSES=*GPL-[23]

[Paweł Hajdan , Jr .]

On 26/08/2018 13:15, Michał Górny wrote:
> I'm not aware of any major implications.  However, I think that if we
> provide for the distinction, the distinction should be used correctly.

Makes sense.

Note that this might also be an argument for _not_ providing such
fine-grained distinction (unless there's corresponding value in it).

If in doubt, at least my intuition is to err on the side of simplicity.

I also like Rich's opinion on this,


Paweł



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] Solving the problem of huge number of wrong LICENSES=*GPL-[23]

[Paweł Hajdan , Jr .]

On 26/08/2018 12:53, Mart Raudsepp wrote:
> The common issue here is that upstream COPYING files really do only
> talk about one of the versions. And then you get to validate or source
> files to be sure that they do have a "or later" clause in them. And
> then on each bump you ideally should validate it again, etc, that no
> sources without "or later" allowance are in there...

Yup, precise tracking of license metadata can be a pain.

I'm not really sure if that level of it is worth for us as a distro. For
_importing_ other project's source code directly into one's project
precise license compatibility matters a lot. That's not the scenario
we're in. I see LICENSES as mostly a mechanism for end users to accept
or reject EULAs etc, and I'm curious what are other common scenarios.

Michał, could you elaborate on why not distinguishing more precisely
between these GPL variants in LICENSES is a _problem_ ? I can certainly
see the information is not always accurate, but it's not obvious to me
how severe is the downside, what are the consequences in practice.

Paweł



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Idea for a new project: gentoo-libs

[Paweł Hajdan , Jr .]

On 23/06/2018 09:43, Mikle Kolyada wrote:
> But how would it serve gentoo itself? Lots of packages in the distro
> have dead upstream but still work.
> Why would you want to make gentoo an upstream area rather than moving a
> dead project itself, say,
> to github and do the job there?

+1

I like the idea of taking responsibility for the abandoned packages that
are still useful.

It's probably not Gentoo-specific, so a distro-neutral way of handling
that seems most appropriate.

It may even be worth it to coordinate with other distros (and maybe
downstreams) so that the new version becomes a standard.

Finally, having more than one person on this (to help continuity), and a
common platform like GitHub also seem very helpful.

Paweł



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] multiversion ebuilds

[Paweł Hajdan , Jr .]

On 12/05/2018 14:20, Gerion Entrup wrote:
> just an idea for now. But what you think about multiversion ebuilds?
> Technically this could be realized with the following line in the ebuild 
> itself:
> ```
> VERSIONS=( 3.0.11 3.0.12 3.1 )
> ```
> 
> and the filename without version:
> //.ebuild

I'm wondering: if the main goal would be more code sharing between
ebuilds, would something like

(essentially per-package eclasses) be an option?

Paweł



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Gentoo-dev whitelisting

[Paweł Hajdan , Jr .]

On 14/05/2018 07:35, Michał Górny wrote:
> W dniu nie, 13.05.2018 o godzinie 17∶28 -0400, użytkownik Alec Warner
> napisał:
>> On Sun, May 13, 2018 at 5:25 PM, Paweł Hajdan, Jr. <phajdan...@gentoo.org>
>> wrote:
>>> I'm wondering,
>>> <https://gitweb.gentoo.org/infra/gentoo-dev-whitelist.git> currently
>>> says for me "No repositories found".
>>
>> Its not a public repo, so it isn't listed. If you think it should be
>> public, ask council; its a 1 line config change on our side.
>>
> I don't think publishing it is a good idea.  Spammers are going to love
> the easy list of e-mail addresses.  Also GDPR may apply.

Good points. Nevermind.

Paweł



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Gentoo-dev whitelisting

[Paweł Hajdan , Jr .]

On 13/05/2018 20:57, Alec Warner wrote:
> https://wiki.gentoo.org/wiki/Project:Infrastructure/
> Mailing_Lists#Managing_the_Gentoo-Dev_whitelist

I'm wondering,
 currently
says for me "No repositories found".

Am I using a wrong address, or does the new repo need gitweb setup?

FWIW of course I can use git, it's just in some cases (especially casual
browsing) gitweb can be more convenient.

Paweł



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] bug queue size over time

[Paweł Hajdan , Jr .]

On 20/03/2018 06:05, Paweł Hajdan, Jr. wrote:
> On 19/03/2018 21:33, Alec Warner wrote:
>> I'd avoid the REST API here. If you want this data; I'd consider filing a
>> bug. Infra can do stuff like run nightly reports for this information and
>> hang them off of endpoints you can access.
>> This works well for public bugs; and not well for private ones.
> 
> Luckily, I'm not that concerned with private bugs.
> 
> Would it only collect data going forward, or does this method also
> support historical backfill?
> 
>>> I've done something like this before with Perl bugs[1], but again, very
>>> painful, slow and time consuming.
> 
> Ah, that looks like lots of stats.
> 
> I'm mostly interested in how many bugs were open for given assignee for
> each point in time.
> 
> If you still have scripts that generated these reports and they could be
> useful to compute the above, I could be interested.

Just checking back here - what would be the best way to graph number of
bugs with given assignee, preferably with historical backfill?

I'm not necessarily looking for something ready to use right away. If
there's some work to be done or code to implement, I may be willing to
do so.

Paweł



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] rfc: empty directories in ${D}

[Paweł Hajdan , Jr .]

On 29/03/2018 19:00, Michał Górny wrote:
> W dniu czw, 29.03.2018 o godzinie 11∶34 -0500, użytkownik William Hubbs
> napisał:
>> If we are going to strip the empty directories, we should hard fail the
>> emerge at the same time. Otherwise there is no way to know whether the
>> package we successfully install will now run.
> 
> The developer is supposed to *look* at what the package installs.
> If people just commit ebuilds based on 'Portage did not explode',
> then maybe they shouldn't have commit access in the first place.

You're IMO both making good points.

I have an impression proponents of each solution comment on parts of the
opposing argument, but I'm yet to see a more organized pros and cons list.

There's an element of design taste, and it may help to have some
reasonable guidelines, like "avoid breaking users' systems" - as opposed
to expecting volunteer developers never to make mistakes, or optimizing
for anyone but the user.

Paweł



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Mailing list moderation and community openness

[Paweł Hajdan , Jr .]

On 20/03/2018 05:17, Michael Palimaka wrote:
> I see that in bug #650964[1] Council is pushing forward again with
> implementing user whitelisting on this mailing list (ie. anyone that is
> not "approved" will have their mail rejected).
> 
> Could someone please explain how this doesn't directly contradict the
> core tenets of an open and inclusive community?
> 
> 1: https://bugs.gentoo.org/650964

This is a controversial topic which continues to be rehashed.

I think it'd be good for people opposing it (I share at least some of
your concern) to make sure they read the following resources and suggest
the best means to keep our community a nice place.





Paweł



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] bug queue size over time

[Paweł Hajdan , Jr .]

On 19/03/2018 21:33, Alec Warner wrote:
> I'd avoid the REST API here. If you want this data; I'd consider filing a
> bug. Infra can do stuff like run nightly reports for this information and
> hang them off of endpoints you can access.
> This works well for public bugs; and not well for private ones.

Luckily, I'm not that concerned with private bugs.

Would it only collect data going forward, or does this method also
support historical backfill?

>> I've done something like this before with Perl bugs[1], but again, very
>> painful, slow and time consuming.

Ah, that looks like lots of stats.

I'm mostly interested in how many bugs were open for given assignee for
each point in time.

If you still have scripts that generated these reports and they could be
useful to compute the above, I could be interested.

Paweł



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] bug queue size over time

[Paweł Hajdan , Jr .]

Is it possible to get graphs of bugs.g.o bug queue size for certain
query (e.g. by assignee) over time?

Best,
Paweł



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] stability of 17.0 hardened profile

[Paweł Hajdan , Jr .]

I was looking into the new 17.0 profiles (nice work!), and noticed the
hardened one is marked as dev. I'm somewhat concerned about switching to
that on my laptop (I'm currently using hardened/linux/amd64).

Is there something I can do to help move the profile to stable?

Alternatively, is there a different profile recommended for hardened?

# eselect profile list
...
  [12]  default/linux/amd64/17.0 (stable)
  [13]  default/linux/amd64/17.0/selinux (dev)
  [14]  default/linux/amd64/17.0/hardened (dev)
  [15]  default/linux/amd64/17.0/hardened/selinux (dev)
  [16]  default/linux/amd64/17.0/desktop (stable)
  [17]  default/linux/amd64/17.0/desktop/gnome (stable)
  [18]  default/linux/amd64/17.0/desktop/gnome/systemd (stable)
  [19]  default/linux/amd64/17.0/desktop/plasma (stable)
  [20]  default/linux/amd64/17.0/desktop/plasma/systemd (stable)
  [21]  default/linux/amd64/17.0/developer (stable)
  [22]  default/linux/amd64/17.0/no-multilib (stable)
  [23]  default/linux/amd64/17.0/no-multilib/hardened (dev)
  [24]  default/linux/amd64/17.0/no-multilib/hardened/selinux (dev)
  [25]  default/linux/amd64/17.0/systemd (stable)
  [26]  default/linux/amd64/17.0/x32 (dev)
...
  [40]  hardened/linux/amd64 (stable) *

Paweł



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] SAT-based dependency solver: request for test cases

[Paweł Hajdan , Jr .]

On 10/02/2018 09:20, Michał Górny wrote:
> To be honest, I don't think this is the right approach to the problem.

Feel free to suggest a better one.

> Truth is, dependencies in Gentoo are seriously broken, and most of
> the developers aren't even aware of that because of layers upon layers
> of hacks in Portage that make emerge somewhat go on.

Indeed, I may not be aware of many such problems.

Is there a place where the known ones can be documented?

Paweł



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] about stable, dev and exp profile status

[Paweł Hajdan , Jr .]

On 11/01/2018 08:43, Fabian Groffen wrote:
> I always was under the impression the following order (and explanation)
> was the case:
> 
> stable -> development -> experimental
> 
> For this reason, e.g. Prefix profiles are (still) experimental, which
> means they really shouldn't bother non-Prefix people.  Prefix users and
> developers work on an environment where those profiles are promoted to
> development ones, such that repoman kicks in for their work.  (At least
> that was the idea.)
> 
> I see you (re-)define dev as "developer's playground", and I wonder if
> in that case it wouldn't be better to introduce a new one instead?
> 
> Maybe I'm just one of a few who thinks the order is reversed now.

The stable -> dev -> exp order also feels more natural to me.

I don't have a strong opinion on this though.

Paweł

Re: [gentoo-dev] Manifest2 hashes, take n+1-th: one hash to decide them all

[Paweł Hajdan , Jr .]

On 25/10/2017 14:32, Hanno Böck wrote:
> Good security includes reducing complexity. Tough (as evident by this
> thread) it's a thought many people find hard to accept.
>
> This thread is going into a completely different direction and I find
> that worriesome. We have two non-problems ("what if secure hash X gets
> broken?" and "what if it's too slow? I haven't benchmarked, but what if
> it's too slow??") and people proposing increasingly complex solutions.
> 
> If you do what you propose my worries aren't that any hash gets broken
> or that it's too slow. It's that some bug will chime in where in some
> situation no hash gets checked whatsoever.

+1

I consider the multiple hashes we have a part of providing smooth
migration path (keeping around hashes supported by older portage
versions). Other than that, yeah, watch out for complexity.

Paweł



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Manifest2 hashes, take n+1-th: 3 hashes for the tie-breaker case

[Paweł Hajdan , Jr .]

On 24/10/2017 06:11, Michał Górny wrote:
> W dniu wto, 24.10.2017 o godzinie 06∶04 +0200, użytkownik Michał Górny
> napisał:
>> Three hashes don't give any noticeable advantage. If we want a diverse
>> construct, we take SHA3. SHA3 is slower than SHA2 + BLAKE2 combined, so
>> even with 3 threaded computation it's going to be slower.
> 
> Oh, and most notably, the speed loss will be mostly visible to users.
> An attacker would have to compute the additional hashes only
> if the fastest hash already matched, i.e. rarely. Users will have to
> compute them all the time.

I'm surprised to see bikeshedding about this, where the performance
argument was shown to be speculative.

Consider clarifying what's the goal of this thread.

It seemed like a relatively obvious cleanup / modernizing the set of
hash functions, and I'd still be supportive of that.

Paweł



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Manifest2 hashes, take n+1-th

[Paweł Hajdan , Jr .]

On 20/10/2017 18:15, Michał Górny wrote:
> W dniu pią, 20.10.2017 o godzinie 17∶42 +0200, użytkownik Paweł Hajdan,
> Jr. napisał:
>> Curious, do we have any measurements/estimates of the performance cost?
> 
> With a single thread serial processing of all hashes, it's just sum of
> times involved in every hash, i.e. Th = T1 + T2 + T3 + ... You'd have to
> get some numbers to get something smarter out of it.
> 
> If we assume we can do N threads, then cost of N algorithms is equal to
> the slowest of them all. Which implies that having N algorithms is
> fastest on systems capable of at least N threads.
> 
> Taking a random comparison [1], it seems that SHA3/512 is 3-5 times
> slower than SHA2/512.
How large part of dependency calculation / other portage's operation is
this though?

My point is, did profiling turn out hash computation as bottleneck, or
is this more speculative?

I'm still in favor of modernizing the hashes, just somewhat skeptical
when performance is being mentioned.

Paweł



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Manifest2 hashes, take n+1-th

[Paweł Hajdan , Jr .]

On 19/10/2017 21:08, Michał Górny wrote:
> Considering all arguments made so far, I'd like to propose changing:
>   manifest-hashes = SHA256 SHA512 WHIRLPOOL
> to:
>   manifest-hashes = SHA512 SHA3_512

+1, fine for me

> 1. The main argument for using multiple hashes is to prevent the (very
> unlikely) possibility that if a weakness is discovered in one of
> the hashes, the other would still hold. This is given by using two
> algorithms; more than two do not increase security significantly, while
> they do increase performance cost.

Curious, do we have any measurements/estimates of the performance cost?

Paweł



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Revisions for USE flag changes

[Paweł Hajdan , Jr .]

On 12/08/2017 03:11, Brian Evans wrote:
> --changed-use (-U)
>Tells emerge to include installed packages where USE flags have
>changed   since  installation.  This  option  also  implies  the
>--selective option. Unlike --newuse,  the  --changed-use  option
>does not trigger reinstallation when flags that the user has not
>enabled are added or removed.
> 
> The option is the same as --newuse except it ignores functionality that
> you suggest to remove.  You could certainly deprecate one option or the
> other if they became the same.  But the core functionality of
> system-wide USE changes (by profile or user), needs to be scanned somehow.

+1

There are use-cases for --changed-use / --newuse other than changed IUSE.

I find it useful to easily rebuild affected packages when changing USE
flags in make.conf. If the flags were removed, would we have a good
alternative?

Paweł



signature.asc
Description: OpenPGP digital signature

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

[Paweł Hajdan , Jr .]

On 20/07/2017 11:38, Kristian Fiskerstrand wrote:
> 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)

Thanks for the suggestion.

I did above, but no log file was even created.

I can still successfully commit with plain git.

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

Okay, I'll try that.

Paweł



signature.asc
Description: OpenPGP digital signature

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

[Paweł Hajdan , Jr .]

Hey folks,

This is mysterious, and likely some issue with my setup, although it
used to work.

Trying tocommit with repoman commit (app-portage/repoman version 2.3.1)
results in the following:

* 4 files being committed...
error: gpg failed to sign the data
fatal: failed to write commit object
!!! Exiting on git (shell) error code: 128

However, committing directly with git commit works (and asks for gpg
passphrase).

In .git/config I have the following:

[user]
signingkey = 0x4F1A2555EA71991D
[commit]
gpgsign = 1
[push]
gpgsign = 1

In /etc/make.conf I have:

PORTAGE_GPG_KEY="0x4F1A2555EA71991D"

In ~/.gnupg/gpg-agent.conf I have the following:

pinentry-program /usr/bin/pinentry

eselect pinentry show prints pinentry-gnome3

I'm using app-crypt/gnupg-2.1.20-r1, last updated May 24.

Interestingly, I recently (July 17) re-emerged
app-crypt/pinentry-0.9.7-r1, probably changing some USE flags. It may
have been broken before that anyway, I don't remember now.

Most of all, I'm interested how to get more debug info from repoman than
it currently shows me.

Any other insights would be welcome. Please let me know if you need any
other info.

Paweł



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] stabilization candidates, July 2017

[Paweł Hajdan , Jr .]

Hey folks,

If you'd like to help Gentoo stable be more up to date, please read on.

See

for potential stabilization candidates (over 1000 of them).

These are automatically checked to pass repoman, and bugzilla is also
checked for bugs. Only ebuilds not modified in last 30 days are considered.

Feel free to check out 
for the script(s) which generate this. It's a project I've been working
on throughout 2011-2014, and might now work more on it.

Feedback about next steps would be welcome.

Paweł



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] crossdev: installing _host_ build dependencies not automatic?

[Paweł Hajdan , Jr .]

On 03/05/2017 17:56, Alexis Ballier wrote:
> From man emerge:
> 
>--root-deps[=rdeps]
>   If  no argument is given then build-time dependencies of
>packages for ROOT are installed to ROOT instead of /.  If the
>rdeps argument is given then discard all build-time dependencies
>of packages for ROOT.  This option is only meaningful when used
>together with ROOT and it should not be enabled under normal
>circumstances!

Ah, I didn't know about that. Thanks!

>   Does not affect EAPIs that support HDEPEND.  Experimental
>   EAPI 5-hdepend provides HDEPEND as a new means to adjust
>   installation into "/" and ROOT.  If ebuilds using EAPIs
>   which do not support HDEPEND are built  in  the same
>   emerge run as those using EAPIs which do support HDEPEND,
>   this option affects only the former.

Curious - what's the status of HDEPEND for the main tree?

Paweł



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] crossdev: installing _host_ build dependencies not automatic?

[Paweł Hajdan , Jr .]

I encountered  while
working on some cross-compiling project.

Admittedly, it may not be that easy to handle host package dependencies
fully automatically.

I'm wondering - is it documented what portage guarantees, and what I'm
expected to just manually handle to provide host build dependencies?

Any other advice about properly using crossdev would also be
appreciated. I'd be happy to test and help improve things.

Paweł



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] packages up for grabs (from phajdan.jr, May 2017)

[Paweł Hajdan , Jr .]

This is probably overdue. I'm not really maintaining the following
packages, mostly because I no longer use them.

I have dropped myself from metadata.xml . Feel free to grab. If you have
questions about them, just email me.

app-admin/logcheck (2 bugs)
app-admin/syslog-summary (1 bug)
app-misc/lockfile-progs
media-plugins/gimp-lqr
sci-mathematics/spin
sys-apps/hardened-shadow (1 bug)

For the following packages, I've removed myself from metadata.xml, but
there are other maintainers/projects:

dev-python/pyftpdlib (python)

Thanks,
Paweł



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Bugzilla package list editing

[Paweł Hajdan , Jr .]

On 02/05/2017 02:31, Andreas K. Huettel wrote:
> Am Sonntag, 30. April 2017, 12:29:46 CEST schrieb Mart Raudsepp:
>> Please stop editing package lists when you are not the maintainer and
>> arches are already CCed.
> +1
> 
> Please stop it.
> And yes that's also true for arch team members.
> 
> Package list is maintainer territory.

Curious, what are the reasons and what changes people make that they
shouldn't?

I'm wondering if there's some solution to these issues (maybe better
documentation, or an alternative way of accomplishing what these people
try to do).

Paweł




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [PATCH 3/4] www-client/chromium: Use eninja from ninja-utils

[Paweł Hajdan , Jr .]

On 30/04/2017 22:28, Michał Górny wrote:
> ---
>  www-client/chromium/chromium-59.0.3067.0.ebuild | 19 +--
>  1 file changed, 1 insertion(+), 18 deletions(-)

Thanks!

Please make sure to patch the latest chromium version - at this moment,
60.0.3080.5 . I'm fine with backporting the patch to older ones.

Paweł



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] chromium-59.0.3053.3 will require >=sys-apps/sandbox-2.11 (currently hard masked)

[Paweł Hajdan , Jr .]

The latest dev channel release of chromium (59.0.3053.3) will require
>=sys-apps/sandbox-2.11 to build.

I'm sending this announcement because this version of sandbox is
currently hard masked. So is the chromium version, but with its fast
release cycle we can expect it hitting ~arch in few weeks, and stable in
the next few weeks. I'd like to make sure we'd be able to push sandbox
to stable at the same pace, or find some alternative solution.

For curious folks, new sandbox fixes a hang which occurs with tcmalloc.
See https://crbug.com/586444 . The new chromium adds a code generator
needed for build (inside the network stack). I didn't find an easy way
to disable tcmalloc just for that code generator, and after finding
above bug new sandbox seemed like the best choice.

See

for the commit which introduced this, and feel free to share your
suggestions.

Paweł



signature.asc
Description: OpenPGP digital signature

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

[Paweł Hajdan , Jr .]

On 29/03/2017 19:51, Matt Turner 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.

Thanks for the pointer!

I filed 

Paweł




signature.asc
Description: OpenPGP digital signature

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

[Paweł Hajdan , Jr .]

I was packaging chromium-59.0.3053.3 . I worked around the problem
described here, but I'd like to find the right long term solution.

I was hitting the following compile error:

../../ui/gfx/linux/client_native_pixmap_dmabuf.cc:39:27: fatal error:
linux/dma-buf.h: No such file or directory
 #include 

Despite having sys-kernel/linux-headers-4.10 installed, I do not have
that header. Interestingly, it is present in the tarball
(gentoo-headers-base-4.10.tar.xz), but doesn't seem to get installed.

This is the workaround I applied:


This is part of the chromium code in question:



#if LINUX_VERSION_CODE < KERNEL_VERSION(4, 6, 0)
#include 

struct local_dma_buf_sync {
  __u64 flags;
};

#define LOCAL_DMA_BUF_SYNC_READ (1 << 0)
#define LOCAL_DMA_BUF_SYNC_WRITE (2 << 0)
#define LOCAL_DMA_BUF_SYNC_RW \
  (LOCAL_DMA_BUF_SYNC_READ | LOCAL_DMA_BUF_SYNC_WRITE)
#define LOCAL_DMA_BUF_SYNC_START (0 << 2)
#define LOCAL_DMA_BUF_SYNC_END (1 << 2)

#define LOCAL_DMA_BUF_BASE 'b'
#define LOCAL_DMA_BUF_IOCTL_SYNC \
  _IOW(LOCAL_DMA_BUF_BASE, 0, struct local_dma_buf_sync)

#else
#include 
#endif

Paweł



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Pre-GLEP for review: mix-in profiles

[Paweł Hajdan , Jr .]

On 23/01/2017 13:12, Alexis Ballier wrote:
> For example, if you allow use.mask or use.force in mixins, you can end
> up having unsatisfiable deps that repoman will never catch.

Whoa, that sounds bad. Could you elaborate why we wouldn't be able to
catch these errors?

> Arguably, desktop profiles relying on having an useflag forced on a
> given package are already semi-broken: they'd be better with the
> useflag default enabled and proper usedeps, so the mask/force game
> doesnt seem really useful for mixins.

Could you give examples of such assumptions? I'd agree in general
usedeps sound like the proper solution.

> It'd also be great to have "rules" ensuring all mixins commute, but I
> doubt that's easily doable.

Could you elaborate more on that, and what the difficulties are?

Michał: also consider including in the GLEP how eselect profile would
look like and behave.

Paweł




signature.asc
Description: OpenPGP digital signature

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

[Paweł Hajdan , Jr .]

On 16/01/2017 10:35, Michał Górny wrote:
> Just a quick side project we've done a while ago. It's a timeline of
> developer commit activity [1]. Code for data processing in [2]. I did
> the data, Amynka prepared a nice JS to graph it.
> 
> [1]:http://dev.gentoo.org/~mgorny/dev-timeline.html
> [2]:https://github.com/mgorny/dev-timeline

This is fascinating!

I like how it also shows when various developers have joined, and how
long they stayed active.

Paweł




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Google Code shutdown requires 524 ebuilds to be fixed before end of 2016

[Paweł Hajdan , Jr .]

On 05/11/2016 00:54, Jonas Stein wrote:
> Today we have still 524 ebuilds with SRC_URI=*googlecode* in the tree
> [2] and should get these fixed before end of 2016.
> 
> [3] https://wiki.gentoo.org/wiki/Shutdown_of_google_code

The wiki page seems to indicate some sense of urgency. I'm not sure how
much of that is needed.

Brainstorming mentions just cloning the URLs, but don't existing Gentoo
Mirrors have the same effect? My understanding is fetching will not
break even if original URLs go down.

I'm also not fully convinced by the manpower argument. It seems the same
work needs to be done, one way or another.

For the parts that can be automated and done in batch, this is indeed
more effective than 500 individual bugs.

However, I'm not sure if finding the new homepage and download URL can
be that easily automated. In fact, users may do some work for us and
help point to the right page.

HTH

Paweł



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Contributed ebuilds and copyright questions

[Paweł Hajdan , Jr .]

On 25/10/2016 01:03, Rich Freeman wrote:
> As long as you have their permission to change the copyright notice.
> You cannot currently commit anything with a different copyright notice
> to gentoo.git, and you cannot legally change it without permission.

How should that permission be documented?

Is a statement the original author consents sufficient?

Paweł




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Mentor request

[Paweł Hajdan , Jr .]

On 19/10/2016 07:14, Kevin Simmons wrote:
> In general, I could use a mentor I can ask questions of and get answers
> from. I have been a tinkerer/user only of Gentoo in the past and am now
> wanting to be more involved.

Sounds great! :)

Not sure if I'd call myself a mentor, but feel free to send questions my
way.

> For instance, there is a bug to have
> gramps-4.2.4 stable (it is ~amd64 ~x86 now).

That's , right?

The usual procedure is to CC arches on the bug - amd64@ and x86@ in that
case.

> To stabilize this package for amd64 and x86 it would also need to be
> verified on x86. I suppose I could do that myself by creating an x86
> virtual guest and testing or I should ask for assistance via a bug to
> x86@.

x86@ would probably be slow to respond, and it's really a dying arch.

A more lightweight solution in case you need it would be a chroot.

> Also, when I run 'repoman full' from the proposed ebuild directory I get
> QA issues for  RDEPEND for dev-python/pyicu, which is also ~amd64. This
> dependent package (and its dependencies) would need to be stable as
> well.

Ah, yes - I suggest opening stabilization bugs for these packages, and
marking them us blocking gramps stabilization bug.

> When it comes time to commit (repoman commit), do I need any user access
> set up before I commit?

repoman commit will create a local commit in your local git checkout.

Only developers can push directly to Gentoo git. Otherwise you can maybe
create a PR on github or just send a git-formatted patch for someone to
proxy commit.

Paweł




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Local workarounds with no reported bugs

[Paweł Hajdan , Jr .]

On 17/10/2016 12:42, Patrice Clement wrote:
> We don't need yet another policy to "fix" two problems you've
> encountered

+1 ; policies don't always fix things

It's a worthwhile guideline though - as Gentoo devs, and maybe even
wider community, we should work together to fix problems.

That's one of the advantages I see in open source and communities - that
we don't need to work around each other's bugs, but can just squash them
at the source.

Paweł



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] recommended way to get gcc-6 for testing packages

[Paweł Hajdan , Jr .]

On 05/09/16 13:07, Joshua Kinard wrote:
> On 08/31/2016 17:28, Paweł Hajdan, Jr. wrote:
>> gcc-6 doesn't seem to be in portage.
> It's in the hardened-development overlay.  You can use layman to install the
> overlay, then test out gcc-6.2.x.  Already found a bug related to mips 
> myself, heh.

Okay. I'll probably take a look.

Why not add it to portage, unkeyworded or something?

Paweł



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] recommended way to get gcc-6 for testing packages

[Paweł Hajdan , Jr .]

I was looking at  .

gcc-6 doesn't seem to be in portage.

Is there recommended way to get it installed?

I'm also wondering what are the plans for adding it to portage. Why not
just add it hard masked or unkeyworded?

Paweł



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] chromium-54 needs ffmpeg-3.0.1

[Paweł Hajdan , Jr .]

See  for context.

chromium-54 is currently hard masked; it'd soon enter ~arch, and then
stable in ~6 weeks. ffmpeg-3.0.1 is currently hard masked.

These are the options I see for how to proceed. Feel free to share
further alternatives.

A. Prepare to unmask and eventually stabilize ffmpeg-3.0.1

B. Backport just the changes needed for chromium to older ffmpeg

C. Mask chromium's system-ffmpeg flag when the dependency on
ffmpeg-3.0.1 can't be satisfied

D. Patch chromium not to require newer ffmpeg

Please share your thoughts about pros, cons, and viability of each option.

I'd certainly be willing to help with testing and making progress on
these, and I could possibly use a fast machine as a tinderbox for this.

That also means help is welcome.

Paweł



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] 'Gentoo Linux' bugzilla component reorganization

[Paweł Hajdan , Jr .]

On 15/06/16 21:11, Michał Górny wrote:
> I would personally go for the following layout:
> 
> - All packages,
> - Core system [includes baselayout],
> - Eclasses and Profiles,
> - GCC Porting,
> - Hardened,
> - Keywording & Stabilization,
> - New packages ('New ebuilds' previously),
> - SELinux.

Sounds good to me.

Some cleanup is definitely due.

Paweł



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] ssh keys setup for git.gentoo.org after ssh-dss deprecation

[Paweł Hajdan , Jr .]

On 3/26/16 11:41 AM, Michał Górny wrote:
> On Sat, 26 Mar 2016 18:40:17 +0900
> Aaron Bauman  wrote:
>> Git SSH key changes are done manually by the infra team.  I just went 
>> through 
>> the same issue when I updated my keys.  Hope this helps.
> 
> Updated.

Thanks! Everything works now.

Should the docs also be updated to make this more obvious?

Some candidates:




(mentions DSA keys but looks like they're being deprecated in ssh now).

Paweł



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] ssh keys setup for git.gentoo.org after ssh-dss deprecation

[Paweł Hajdan , Jr .]

I recently hit ssh-dss key deprecation
(),
and PubkeyAcceptedKeyTypes=+ssh-dss on the client side allows me to keep
access to Gentoo infrastructure I need.

I generated a new RSA key using instructions from
, and
added it to LDAP following
.

I can now login to dev.gentoo.org with just the new RSA key.

However, git.gentoo.org gives me access denied errors unless I use the
DSA key.

Is this expected?

I'm just wondering if it's some error on my side or something else.

Looking at
,
I see things like:
- "DSA keys are preferred over RSA keys"
- "where possible users should be required to use DSA keys to authenticate"

Should I actually rather look at generating a ed25519 key?

Paweł



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] gcc-5 news item wrt C++ ABI

[Paweł Hajdan , Jr .]

On 10/3/15 4:13 AM, Mike Frysinger wrote:
> Title: GCC 5 Defaults to the New C++11 ABI 
> Author: Mike Frysinger 
> Content-Type: text/plain
> Posted: 2015-10-02
> Revision: 1
> News-Item-Format: 1.0
> Display-If-Installed: >=sys-devel/gcc-5
> 
> GCC 5 uses the new C++ ABI by default.  When building new code, you might run
> into link time errors like:
> ...: undefined reference to '_ZNSt6chrono12steady_clock3nowEv@GLIBCXX_3.4.17'
> Or you might see linkage failures with "std::__cxx11::string" in the output.
> 
> These are signs that you need to rebuild packages using the new C++ ABI.
> You can quickly do so by using revdep-rebuild like so:
> # revdep-rebuild --library 'libstdc\+\+\.so\.6'
> 
> For more details, feel free to peruse:
> https://developerblog.redhat.com/2015/02/05/gcc5-and-the-c11-abi/
> https://blogs.gentoo.org/blueness/2015/03/10/the-c11-abi-incompatibility-problem-in-gentoo/

Curious, can one reasonably easy downgrade from GCC 5 back to GCC 4?

Are there any instructions for that? Is it sufficient to do a similar
revdep-rebuild command?

In case the downgrade would horribly break systems or be otherwise
highly nontrivial, I'd recommend some note for that.

Paweł




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] gcc-5 news item wrt C++ ABI

[Paweł Hajdan , Jr .]

On 10/3/15 7:30 PM, Ciaran McCreesh wrote:
> On Sat, 3 Oct 2015 13:24:11 -0400
> Mike Frysinger  wrote:
>> On 03 Oct 2015 13:38, Ciaran McCreesh wrote:
>>> On Fri, 2 Oct 2015 22:13:09 -0400 Mike Frysinger wrote:
 Display-If-Installed: >=sys-devel/gcc-5
>>>
>>> This means that two years from now, when stages are built using GCC
>>> 5, every new user will get this news item shown to them.
>>
>> multiple news items already use this syntax
> 
> Yes, and they cause problems. Do you want to cause another problem, or
> do you want to think more carefully about who should see the news item?

Hey Ciaran - I see you can point technical deficiencies in a lot of cases.

Could you just suggest an alternative solution?

Paweł



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] LibreSSL import plan

[Paweł Hajdan , Jr .]

On 9/29/15 3:32 PM, Rich Freeman wrote:
> The thing is that I think the libressl authors are shooting themselves
> in the feet.  When upstreams do this sort of thing they think they're
> making the upgrade path easier by not changing their symbol names.  In
> reality, they're making the upgrade path harder by preventing
> side-by-side adoption of the new solution.

Yeah, it's not that obvious how to handle it best.

Curious - how would the alternative look like? My reasoning is that if
upstream changes symbols, that makes it easy for a distro to install it
side-by-side. However, for anything to use such modified lib, they'd
need to change all callers to use the alternative function names,
wouldn't they?

Paweł




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Request to add ~> atom prefix operator on Portage.

[Paweł Hajdan , Jr .]

On 9/14/15 9:13 AM, konsolebox wrote:
> On Mon, Sep 14, 2015 at 2:29 PM, Paweł Hajdan, Jr. 
> <phajdan...@gentoo.org> wrote:
>> On 9/14/15 6:35 AM, konsolebox wrote:
>>> Many times we need to match packages like this:
>>> something-1.0.2a.*
>> 
>> Could you give specific examples, i.e. what packages, what
>> dependencies, why is that needed?
> 
> For accuracy and peace of mind regardless of how often conflicts
> could happen.

I agree =pkg-4.1* also matching pkg-4.10 is a concern.

In that case though, it would change the focus of the discussion to how
* operator should work, not necessarily adding a new ~> operator.

I think it'd be okay to e.g. change the meaning and behavior of * in a
new EAPI.

> I can't give any example yet, but we know that if pkg-4.1.2 exists
> and pkg-4.10.0 exists as well, then we can't use '=pkg-4.1*' to only 
> target pkg-4.1.*.  This could also happen more often with packages 
> having 4 version numbers.

It's unfortunate this is rather theoretical now.

Consider looking for some real examples, I believe this could really
help the discussion.

Paweł



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Request to add ~> atom prefix operator on Portage.

[Paweł Hajdan , Jr .]

On 9/14/15 6:35 AM, konsolebox wrote:
> Many times we need to match packages like this: something-1.0.2a.*

Could you give specific examples, i.e. what packages, what dependencies,
why is that needed?

Paweł




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] www-client/chromium gtk3 support

[Paweł Hajdan , Jr .]

On 9/10/15 8:05 PM, hasufell wrote:
> a) the gnome maintainers already said they are not interested in
> supporting it indefinitely (they are the maintainers of gtk+ as well)

Aren't there at least some gtk2-only apps? It seems to me we're not that
close to removal of gtk2 from the tree.

I'm also not aware of bugs being files about Gentoo gtk maintainers as a
result of gtk2/gtk3 USE flags on packages - please let me know if there
are in fact such bugs.

> c) it introduces maintenance and configuration complexity where it is
> absolutely unnecessary (because no one could come up with a real use
> case) und breaks consistency

Who decides whether a use case is valid? Clearly having discussions like
this for 10 years indicates people are interested in this.

I'm not saying a user is always right. I just wouldn't go out of my way
to block it if package maintainers are willing to support such requests.

Paweł



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] www-client/chromium gtk3 support

[Paweł Hajdan , Jr .]

A user asked for optional gtk3 support in www-client/chromium:


However, reading e.g.

says this:

> having USE=gtk3 to enable gtk+-3 instead of gtk+-2 support is
> forbidden

> package is an application with support for multiple gtk+, maintainer
> is free to select whatever slot he desires to support. It is strongly
> advised to use gtk+-3 if functionality is equivalent. This is to
> reduce workload of bugs being triggered with one slot but not the
> other.

What are your recommendations for the best course of action?

For stability and maintainability, I'd prefer www-client/chromium to use
the upstream defaults (gtk+-2 AFAIK) since it's most common, tested, and
supported configuration. If/when upstream moves to gtk+-3, we'd just follow.

I also understand we have users who are eager to run various
configurations, and expect Gentoo to be flexible and allow that. Would
masking a gtk3 USE flag for www-client/chromium be acceptable? Are there
any other solutions that might work?

Paweł



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] samba (and related) packages are in desperate need of help

[Paweł Hajdan , Jr .]

On 9/9/15 4:00 PM, Lars Wendler wrote:
> On Wed, 2 Sep 2015 21:23:24 +0200 Paweł Hajdan, Jr. wrote:
>> I don't see any references to upstream bug reports, and so no evidence
>> of upstream being uncooperative.
>>
>> Are there any public links that you could share?
> 
> Sorry, I forgot about the mails I sent to samba upstream [1]
> 
> [1]
> http://samba-technical.samba.narkive.com/9UGYmeiG/patch-samba-4-0-automagically-depends-on-dmapi-libdm-so

I see. I'm not sure if I'm interpreting this correctly without more
context. These are my reactions to above thread:

1. All people who replied are listed on
<https://www.samba.org/samba/team/> . To me this means it's indeed
"official" upstream response.

2. Upstream is indeed initially confused.

3. After reading the reference to
<https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Automagic_dependencies>,
they point to "--with{out,}-pam, --with{out,}-aio-support and
--with{out,}-attr" flags. Notably, dmapi is not mentioned.

4. At that point I'd expect a reply from you Lars, that since they have
flags for other libraries but not dmapi (or the dmapi ones don't work -
and provide steps to repro), why wouldn't they take the patch.

5. In fact, <https://bugs.gentoo.org/show_bug.cgi?id=474492> from your
original post links to upstream
<https://bugzilla.samba.org/show_bug.cgi?id=10369> with a slightly
different patch that apparently has been landed.

Paweł



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] www-client/chromium gtk3 support

[Paweł Hajdan , Jr .]

On 9/9/15 5:48 PM, hasufell wrote:
> There was a tracker on bugzilla about it at some point, but people 
> didn't care enough, so I stopped filing bugs. Neither the gnome team
> nor QA had a strong enough opinion to enforce consistency here over
> the whole tree.

Looks like that was  .

I'm not sure whether the underlying issue was enforcement, or just
handling various use cases.

Similar situation with qt/qt4/qt5 seems to confirm to me that it's not
whims that make people not follow the policy, but real needs and use cases.

Quotes from above bug:

> You really have not addressed all the situations here.

> Yes I know there may be situations where the proposed solutions are
> not sufficient.

Also, most blocking bugs seem to be resolved as WONTFIX/WORKSFORME/INVALID.

FWIW I do care. For now responses on this thread seem to recommend (or
be at least OK with) adding gtk3 USE flag to www-client/chromium . If
there's an alternative solution endorsed by GNOME or QA team that would
make progress on 
possible, I'd just switch to that solution.

Paweł



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: Better way to direct upstream bugs upstream?

[Paweł Hajdan , Jr .]

On 9/3/15 10:16 PM, Andrew Udvare wrote:
> Chromium team is no different in this regard. No options, for anything.
> It is extremely annoying when they implement 'privacy-violating'
> features like the previously visited sites in the New tab (before you've
> entered a URL), with no option to disable despite pleas to give that option.

Do you have references to these pleas? I'd expect e.g. some public bug
reports.

Would overriding the new tab page using an extension
(https://developer.chrome.com/extensions/override) work for you?

Paweł



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: Better way to direct upstream bugs upstream?

[Paweł Hajdan , Jr .]

On 8/30/15 12:02 PM, Kent Fredric wrote:
> Or upstream might be a monolithic giant like Google where their
> upstream bug tracking is some pointless forum where you get ignored by
> the people actually working on things.

Ouch.

Do you have specific examples?

I'm not denying they exist. I just had mostly positive experience with
 . Because I'm also Chromium
developer, I know that's what people "actually working on things" use.

I admit with 85000+ open issues not all of them are getting enough
attention. But if you know an upstream developer, it's easier to get the
right people to look at the bug.

Of course above is not the only Google project, and I don't have much
experience with the other ones.

Paweł




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] samba (and related) packages are in desperate need of help

[Paweł Hajdan , Jr .]

On 9/1/15 3:24 PM, Lars Wendler wrote:
> * samba upstream is extremely uncooperative. Best example is that we
>   still have some automagic dependencies [5] in samba's build system and
>   upstream is not very keen on fixing these.
> 
> [...]
>
> [5] https://bugs.gentoo.org/489748
> https://bugs.gentoo.org/489770

I don't see any references to upstream bug reports, and so no evidence
of upstream being uncooperative.

Are there any public links that you could share?

Paweł




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] RFC: EAPI 4 deprecated ban

[Paweł Hajdan, Jr.]

On 8/16/15 3:29 PM, Rich Freeman wrote:
 They are deprecated already:
 https://gitweb.gentoo.org/repo/gentoo.git/tree/metadata/layout.conf
 
 Deprecated means stop adding them, and move away from them.  Repoman
 will give you a warning about them.

Is anything blocking deprecating EAPI4 in the same way?

Paweł




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] RFC: EAPI 4 deprecated ban

[Paweł Hajdan, Jr.]

On 8/15/15 3:16 AM, Ian Stakenvicius wrote:
 Secondly, though, conversion to EAPI5 is not actually trivial, there
 are a couple of things, 'usex' related for instance, that also need
 to be taken care of.  If it was just a matter of running a sed -e
 's/^EAPI=4/EAPI=5/' on all in-tree ebuilds this would have been done
 a long time ago.

Do you mean that it would break things or just while technically working
the ebuilds mass converted in this way would not take advantage of EAPI5
features such use 'usex'?

mgorny@ mentioned the latter in another post, and I think we can address
that e.g. by adding TODO comments to each ebuild converted this way for
a manual review later.

If you think this can actually break things, could you explain more?

 Finally, the gentoo developer quiz -should- still contain questions
 about ancient stuff.  There are still EAPI0 and EAPI2 ebuilds in the
 tree at least.

EAPI0 can be tricky, but why don't we deprecate EAPI2?

Paweł



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] RFC: EAPI 4 deprecated ban

[Paweł Hajdan, Jr.]

On 8/15/15 7:35 AM, Michał Górny wrote:
 Dnia 2015-08-15, o godz. 00:05:57
 Johannes Huber j...@gentoo.org napisał(a):
 if we want to attract more contributors we should consider to have one
 supported EAPI (latest). EAPI 4 is the last not marked as deprecated
 ( EAPI 5). The move in ebuilds from EAPI 4 to EAPI 5 is very simple
 replacing the declaration. As we have now git in place we could easily
 do this with one commit (awesome).
 
 This is a cheap hack, not a conversion. Proper conversion to a new EAPI
 is about using the new EAPI features. Not marking it 'done',
 and pretending there's nothing more to do.

Good point.

My understanding here it's more about deprecating EAPI 4 which we
wouldn't be able to do without moving to a newer EAPI.

Also note that even when writing from scratch, it's not guaranteed that
the developer will use all relevant EAPI 5 features.

Nothing seems to prevent doing the mass conversion first, deprecating
EAPI 4, and then having a second, slower pass to make sure the ebuilds
are using EAPI 5 as they should be. One way might be to add a TODO
comment during mass conversion, which then can be grepped for (and
removed after manual review).

Paweł



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] git history older than proj/gentoo: Initial commit (56bd759)

[Paweł Hajdan, Jr.]

I'd like to start with: kudos for the very skilfully performed migration
from CVS to git! I just committed a simple changed and it worked great.

I was curious and started exploring the repo a little bit, and the
initial commit says:

 This commit is the start of the NEW history.
 Any historical data is intended to be grafted onto this point.

Is the historical data available now? Is it still work in progress?

I've checked the following two places looking for related documentation
but didn't find anything:

https://wiki.gentoo.org/wiki/Gentoo_git_workflow
https://wiki.gentoo.org/wiki/Project:Infrastructure/Git_migration

Paweł



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] useflag policies

[Paweł Hajdan, Jr.]

On 8/2/15 7:27 PM, Michał Górny wrote:
 What would be really clean is USE='qt qt5' (or 'qt qt4'), alike GNOME
 team policy. USE=qt would mean 'any version of Qt, if optional', and
 qt4/qt5 would be used to switch between Qt4/Qt5. If Qt would be
 obligatory, no USE=qt would apply. If only one Qt version would be
 supported, no USE=qt4/qt5 would apply. Clean, sane and limited
 package.use cruft.

+1

 However, as you can see QA has previously outvoted the clean policy for
 USE=gtk. I don't see why it would decide otherwise for USE=qt*.

I wonder what was the reasoning for the QA decision you refer to. Do you
have more details or archive references?

FWIW I think decisions like that can be revisited. Now could be a good
moment for that.

Paweł



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] check-reqs.eclass: fail check-reqs_memory() for virtual rather than physical RAM

[Paweł Hajdan, Jr.]

On 6/3/15 10:56 PM, Mike Gilbert wrote:
 The chromium build issue is a point of some contention; see the bug below.
 
 https://bugs.gentoo.org/show_bug.cgi?id=471810
 
 I agree that it makes sense to check virtual memory. I guess that
 would be MemTotal + SwapTotal in /proc/meminfo.
 
 It would also probably make more sense to check available memory
 (MemAvailable + SwapFree). Maybe that should be implemented in a new
 function, like check-reqs_memory_available.

Agreed.

I think one of the issues is that the eclass aims to support multiple
kernels, not just Linux.

It's not obvious how to implement such check portably for non-Linux
systems. Maybe we could keep it just Linux-only.

I'm totally open to suggestions from the community.

Paweł



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] what's the correct format for bugs containing package name and version?

[Paweł Hajdan, Jr.]

I'm trying to find the best fix for
https://bugs.gentoo.org/show_bug.cgi?id=535814

Currently file-stabilization-bugs.py uses the '%s: stabilization
request' % cpv format.

Here are some options I see:

a) keep '%s:' as is
b) change to just '%s'
c) change to '=%s:'
d) change to '=%s'
e) something else

What is your preference? Let's agree on something and avoid unnecessary
changes on bugzilla.

Paweł



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] do we need special elog messages for bindist?

[Paweł Hajdan, Jr.]

On 2/25/15 8:38 PM, Mike Gilbert wrote:
 I would like to remove the elog for a couple of reasons:
 
 1. The use flag description is there for whoever cares to read it.
 There is no need to alert the user every time.
 2. We are not lawyers, and I have no business giving legal advice
 about patent law which varies from country to country.
 
 To take it one step further: I think it would make more sense to call
 the flag h264 or something similar. We could then set
 RESTRICT=h264? ( bindist ) if we want to give some indication that
 it is not appropriate for binary redistribution.

Makes sense.

My suggestion for the flag name would actually be proprietary-codecs.
This matches config option name in Chromium sources, and it's not just
h264 but also e.g. MPEG-4 and MP3.

The flag would be disabled by default.

I'd then add RESTRICT=proprietary-codecs? ( bindist ) to the ebuild
and remove both elog messages.

Paweł



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Re: [gentoo-dev-announce] Service relaunch: archives.gentoo.org

[Paweł Hajdan, Jr.]

On 2/26/15 9:23 AM, Robin H. Johnson wrote:
 The Gentoo Infrastructure team is proud to announce that we have re-engineered
 the mailing list archives, and re-launched it, back at archives.gentoo.org.
 
 [...]
 
 Major thanks to a3li, for his development of this project.

Awesome work!

I was always proud about Gentoo's mailing list archives - no spam,
simple UI.

Just wanted to say thanks to a3li, and entire Infra team. Oh, and the
new design looks great.

Paweł



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] do we need special elog messages for bindist?

[Paweł Hajdan, Jr.]

I'm looking at https://bugs.gentoo.org/show_bug.cgi?id=538628 which
suggests removing elog messages chromium has for bindist:

This is the snippet we use in the ebuild:

if use bindist; then
elog bindist enabled: H.264 video support will be disabled.
else
elog bindist disabled: Resulting binaries may not be legal to
re-distribute.
fi

I think I used existing examples, e.g. from firefox ebuilds.

Anyway, do you consider the part when bindist is disabled necessary? I'm
open to removing it if it's not needed.

While we're discussing this, do you consider the message when bindist is
enabled useful? bindist is described in chromium's metadata.xml:
Disable patent-encumbered HTML5 video codecs.

Paweł



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] please review ebuilds for neovim and deps

[Paweł Hajdan, Jr.]

On 2/20/15 12:10 PM, Ben de Groot wrote:
 At the suggestion of radhermit, I'm putting my neovim  deps ebuilds
 up here for review, before I commit them to the official tree. Do you
 see any possible improvements?

Overall the ebuilds look nice and clean. Some ideas:

- consider asking libtermkey upstream to provide a way to make demos
optional in a cleaner way than sed over the Makefile

- in neovim-python-client, 0.0.28.tar.gz is hardcoded in the ebuild;
consider using ${PV} instead

Paweł



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] proposed update to toolchain.eclass

[Paweł Hajdan, Jr.]

On 1/18/15 10:50 PM, Anthony G. Basile wrote:
 Hi everyone, I'd like to make a commit to toolchain.eclass in a few
 days.  mgorny noticed some code which can be improved.  Basically gcc
 creates fixed include files from system headers because of the
 requirement that it have ansi c compliant headers.  These are fixed via
 shells scripts during the build process, but we just delete them
 afterwards.  Rather than generate and then delete them, just don't
 generate them in the first place.  Its bug number #536878.  I've tested
 on gcc-3 to the latest and both approaches yield the same results. 

Sounds good.

 Here's the patch so you don't have to go hunting for it:
 
 diff -u -B -r1.647 toolchain.eclass
 --- toolchain.eclass15 Nov 2014 08:45:33 -1.647
 +++ toolchain.eclass18 Jan 2015 20:36:08 -
 @@ -595,6 +595,13 @@
  einfo   ${f%%...}
  done
  fi
 +
 +# we don't want fixed includes :)

Please consider summarizing above in the comment (mostly to the effect
that fixed headers are deleted afterwards and are not needed on modern
systems). It's obvious it's just disabling the logic in given shell
scripts, but from the code itself it's not obvious why.

Paweł

 +if tc_version_is_at_least 4.0; then
 +echo :  ${S}/fixincludes/fixinc.in || die
 +else
 +echo :  ${S}/gcc/fixinc/fixincl.sh || die
 +fi
  }
  
  guess_patch_type_in_dir() {




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [gentoo-project] Re: towards a more distributed model

[Paweł Hajdan, Jr.]

On 11/20/14 5:15 PM, Ciaran McCreesh wrote:
 On Thu, 20 Nov 2014 01:36:32 +0100
 hasufell hasuf...@gentoo.org wrote:
 Exherbo is already running a more modular approach, I'd be interested
 what they have to say about this or which problems they were facing.
 
 Well the big thing is that unlike Gentoo, Exherbo was able to switch to
 using Git for its repositories. On top of that, Exherbo also has proper
 automated tinderbox runs (with automated conflict resolution) for
 changes, including across repositories, and a much stronger culture of
 accepting that breaking changes to APIs and APIs that give an error on
 misuse are necessary for a quality product, and a tolerance of
 developers making those changes and then applying the fixes to other
 people's packages. Distributed is much easier to do if you're starting
 from something which is correct and verified...

I'm glad Exherbo has been mentioned - this gives us something specific
to discuss, including how it works in practice. Using git is certainly
an advantage.

Ciaran, could you share more about the automatic tinderbox runs and
automated conflict resolution? I look at Exherbo site from time to time
but didn't notice this. Please bear with my ignorance, I've even tried
searching for things like Exherbo tinderbox.

I think you have a good point about necessity of breaking changes from
time to time, and APIs that give an error on misuse. This reminds me of
these two other good resources:

http://www.infoq.com/presentations/effective-api-design (just the
slides are at http://www.newt.com/java/GoodApiDesign-JoshBloch.pdf)

https://www.kernel.org/doc/Documentation/stable_api_nonsense.txt

Note that Linus Torvalds pays very close attention to never break
userspace. But within the kernel, large-scale changes are not uncommon,
which I think is a good thing.

Paweł



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] more help needed with gcc-4.8 stabilization, chromium starts heavily using C++11

[Paweł Hajdan, Jr.]

On 11/20/14 5:04 PM, Ian Stakenvicius wrote:
 Ok, added the RESO/NEEDINFO case, and bumped my polling time to 5
 minute intervals.
 
 Diego, please keep going, your efforts are still very much appreciated.

+1, and thanks Ian for your script!

Paweł



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: RFC: News item regarding c++98 vs c++11

[Paweł Hajdan, Jr.]

On 10/24/14 7:29 PM, Anthony G. Basile wrote:
 So I don't have to keep email the entire item to the list, how about 
 just adding it as follows:
 
 Nor is c++11 code compiled with gcc-4.7 ABI-compatible with c++11 
 compiled with 4.8, and vice versa.  An example can be see in ref.
 [2]
 
 Ref. [2] https://bugs.gentoo.org/show_bug.cgi?id=513386

I think this could still be clearer about the user/sysadmin perspective
more than a developer perspective, i.e. present this more like both
gcc-4.7 and 4.8 installed with 4.7 being active than not
ABI-compatible with C++11 compiled with 4.8.

Here's my suggested draft:

-%- CUT HERE -%-
GCC 4.7 introduced the new experimental 2011 ISO C++ standard [1].

Users that wish to try enabling C++11 globally (e.g. using CXXFLAGS)
should exercise caution because it is not ABI-compatible with C++98.
Packages which are self-contained or do not link against any libraries
written in C++ are not affected. Note that some packages like
www-client/chromium and net-libs/webkit-gtk among others are already
using C++11 features.

Even having different versions of gcc installed simultaneously might
lead to problems, especially if the active version of gcc is older.
Please see [2] for example known bug with webkit-gtk. It is recommended
to set the latest installed version of gcc as active; some packages may
work when an older version is selected, but GCC upstream provides no
guarantees of C++11 ABI stability for code compiled with gcc-4.x and 4.y
for any x != y [3].

Ref.
[1] http://www.stroustrup.com/C++11FAQ.html
[2] https://bugs.gentoo.org/show_bug.cgi?id=513386
[3] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61758
-%- CUT HERE -%-

Paweł



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: RFC: News item regarding c++98 vs c++11

[Paweł Hajdan, Jr.]

On 10/24/14 4:31 PM, Anthony G. Basile wrote:
 I've update the c++ news item for your consideration.  I incorporated
 suggestions, in particular a note about incompatibility between c++11
 compiled with different version of gcc differing in minor number (eg 4.7
 and 4.8).

Thanks, I think this is an improvement.

I'd still prefer an explicit mention that having gcc-4.7 and 4.8
installed simultaneously leads to known breakages, especially if 4.7 is
the active gcc version. The text of the news item implies this, but it's
just not obvious.

Also consider explicitly mentioning
https://bugs.gentoo.org/show_bug.cgi?id=513386. Obviously this
wouldn't be a complete list of issues, but from the CC list it's a
pretty common bug.

If in doubt, consider this question: what would be bad about including
the info I suggested above?

Paweł

 Title: GCC 4.7 Introduces New c++11 ABI 
 Author: Anthony G. Basile bluen...@gentoo.org
 Content-Type: text/plain
 Posted: 2014-10-20
 Revision: 1
 News-Item-Format: 1.0
 Display-If-Installed: =sys-devel/gcc-4.7.0
 Display-If-Keyword: amd64
 Display-If-Keyword: arm
 Display-If-Keyword: mips
 Display-If-Keyword: ppc
 Display-If-Keyword: ppc64
 Display-If-Keyword: x86
 Display-If-Keyword: amd64-fbsd
 Display-If-Keyword: x86-fbsd
 
 GCC 4.7 introduced the new experimental 2011 ISO C++ standard [1], along with
 its GNU variant.  This new standard is not the default in GCC 4.7, 4.8 or 4.9,
 the default is still gnu++98, but it can be enabled by passing -std=c++11 or
 -std=gnu++11 to CXXFLAGS.
 
 Users that wish to try c++11 should exercise caution because it is not
 ABI-compatible with c++98.  Nor is c++11 code compiled with gcc-4.7 
 ABI-compatible
 with c++11 compiled with 4.8, and vice versa.  Thus linking c++98 and c++11, 
 or
 c++11 compiled with different versions of gcc, is likely to cause breakage.  
 For
 packages which are self-contained or do not link against any libraries written
 in C++, there is no problem.  However, switching to c++11 and then building
 packages which link against any of the numerous libraries in an incompatible
 ABI can lead to a broken system.
 
 This is a precautionary news item and the typical user need not do anything.
 However, as c++11 gains in popularity and the number of packages using it
 increase, it is important that users understand these issues.
 
 For an ABI compliance checker, and more information about C++ ABIs, see [2].  
 
 Ref.
 [1] http://www.stroustrup.com/C++11FAQ.html
 [2] http://ispras.linuxbase.org/index.php/ABI_compliance_checker
 




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: RFC: News item regarding c++98 vs c++11

[Paweł Hajdan, Jr.]

On 10/21/14 4:25 PM, Mike Gilbert wrote:
 On Tue, Oct 21, 2014 at 4:45 AM, Martin Vaeth mar...@mvath.de wrote:
 Ian Stakenvicius a...@gentoo.org wrote:
 On 20/10/14 06:58 AM, Anthony G. Basile wrote:

 I don't think we'll ever want to support a mixed abi system.

 Can we, even?  Would it be a mixed-abi system or a multi-abi system?

 I am afraid, we *have* to, in the moment when at least one program
 adds -std=c++11 or -std=gnu++11 by itself (which AFAIK chromium does;
 also eix does, if it can).
 
 FYI, Chromium currently has a ban on using C++ 11 library features. I
 imagine that helps on a system/toolchain with C++ 98 libs.
 
 http://chromium-cpp.appspot.com/

Good catch. Two more observations:

1. The ban on C++11 library features will eventually get lifted as
toolchain support on all platforms improves.

2. We may be linking against C++ libraries like ICU. I'd need to check
that, and in many cases it would be Gentoo-specific thing since upstream
uses bundled libs by default.

Paweł




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] RFC: News item regarding c++98 vs c++11

[Paweł Hajdan, Jr.]

On 10/20/14 12:53 AM, Anthony G. Basile wrote:
 GCC 4.7 introduced the new experimental 2011 ISO C++ standard [1], along
 with
 its GNU variant.  This new standard is not the default in GCC 4.7, 4.8
 or 4.9,
 the default is still gnu++98, but it can be enabled by passing
 -std=c++11 or
 -std=gnu++11 to CXXFLAGS.
 
 Users that wish to try c++11 should exercise caution because it is not
 ABI-compatible with c++98.

This seems to focus on the Gentoo user adding -std=c++11 to CXXFLAGS.

Do we consider this #1 problem with gcc-4.8 or 4.7+?

As far as I'm concerned, the big issue is e.g.
https://bugs.gentoo.org/show_bug.cgi?id=513386, where having gcc-4.7
and gcc-4.8 installed on the same system (and using gcc-4.7 as the
active gcc version) is known to be broken.

Another concern I have with the above news item is it might actually
encourage crazy users to add -std=c++11 to CXXFLAGS, even though
otherwise they wouldn't even know about the flag.

To summarize, my suggestion is to make sure we clearly communicate known
bugs reported to Gentoo, like example above one.

Paweł



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] more help needed with gcc-4.8 stabilization, chromium starts heavily using C++11

[Paweł Hajdan, Jr.]

On 10/13/14 1:38 AM, viv...@gmail.com wrote:
   have you considered to stabilize gcc:4.9 instead possibly 4.9.2 ?
 I'm not really suggesting to do so, but seem that most of the problems
 of 4.9.1 are the same of 4.8.3 so maybe it's worth considering.
 
 Il 11/10/2014 13:57, Paweł Hajdan, Jr. ha scritto:
 We'll really need gcc-4.8 in stable within 6-12 weeks from now. Chromium
 starts making heavy use of C++11 language features, see
 http://chromium-cpp.appspot.com/ . I don't realistically see us being
 able to just patch chromium to work around that.
 
 for 4.9.2 the 6-12 week window could be a problem

Yeah, I don't think we can go straight to 4.9 without the latter
spending time in ~arch, and for now it's still hard masked.

Paweł



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] more help needed with gcc-4.8 stabilization, chromium starts heavily using C++11

[Paweł Hajdan, Jr.]

In my earlier thread
http://thread.gmane.org/gmane.linux.gentoo.devel/92113 I explored the
possibility to stabilize gcc-4.8, and we have that going now in
https://bugs.gentoo.org/show_bug.cgi?id=516152.

Meanwhile I just applied a small patch for chromium-38 that allows it to
compile with gcc-4.7. It's in stable now.

We'll really need gcc-4.8 in stable within 6-12 weeks from now. Chromium
starts making heavy use of C++11 language features, see
http://chromium-cpp.appspot.com/ . I don't realistically see us being
able to just patch chromium to work around that.

I'd like to ask for every possible help with
https://bugs.gentoo.org/show_bug.cgi?id=461954 blockers on amd64 and
x86. There are harder problems on arches like MIPS, but newer gcc is not
as urgent there I think.

One highlight is https://bugs.gentoo.org/show_bug.cgi?id=513386. It
occurs only when the user has gcc-4.7 and 4.8 installed simultaneously
and using 4.7 as the active compiler. It's not obvious to me whether we
have to support this (while it's obviously better to support rather than
not, it's webkit-gtk in a specific and rare configuration versus
chromium with security updates in all configurations).

There is also https://bugs.gentoo.org/show_bug.cgi?id=500966 which may
be more tricky. I could reproduce that bug. It's also about webkit-gtk.

There are couple more blockers of
https://bugs.gentoo.org/show_bug.cgi?id=461954. If you can, please
take a look and help. I think several other distros are using gcc-4.8 or
later now, they may have hit the same problems and either have patches
or something that could also help us. There may be some upstream patches
to be backported etc.

Paweł



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Adding dev-lang/perl version to emerge --info

[Paweł Hajdan, Jr.]

On 10/4/14 12:05 AM, Andreas K. Huettel wrote:
 since Perl is a fairly central package and it's hard to debug problems 
 without 
 the exact version, the perl team would like to add dev-lang/perl to 
 profiles/info_pkgs. 
 
 This has the effect that the installed version of dev-lang/perl is by default 
 included in every emerge --info output.
 
 Opinions, encouragement, opposition, flamewars? :)

Encouragement.

Paweł




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Why masks are being used for security issues instead of GLSA?

[Paweł Hajdan, Jr.]

On 9/25/14 6:03 AM, Alex Xu wrote:
 1. one of your examples is clearly wrong, mariadb has no masked
 versions in the tree.
 
 2. since you claim to have read package.mask, [...] if you bothered
 to read a single one of them, they will have said that there is a
 GLSA in progress or that stabilization is still in progress.
 
 3. if you want to use old-ass packages from the age of bourne shell,
 use debian, not gentoo.

While technically you have a point, I'd discourage replies that may feel
almost like an attack on the original poster. Please help keep
gentoo-dev friendly for everyone, as far as possible.

Thanks
Paweł



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Early idea: install_qa_check() refactor and 'public API'

[Paweł Hajdan, Jr.]

On 9/11/14 12:20 AM, Michał Górny wrote:
 I would like the post-install QA checks to be modularized, standardized
 and extensible. For a start, I've split most of the function into
 install-qa-check.d/ scripts in Portage and made install_qa_check()
 function run them [1]. However, that's just a start.
 
 I would like to have install-qa-check.d in three main places:
 
 1. /usr/lib/portage/install-qa-check.d (or alike) for scripts
 installed by Portage and other packages,
 
 2. /etc/portage/install-qa-check.d for extra scripts installed
 by sysadmin,
 
 3. ${repo}/metadata/install-qa-check.d for repository-specific
 QA checks.
 
 The rationale for (3) is quite simple: many of the modern QA checks are
 results of policies specific to Gentoo tree and the eclasses in it --
 like my recent bash-completion checks (still in review queue). Keeping
 them in Portage is cumbersome, and has some code duplication factor.

I see no downsides of this, so +1, and thanks for doing this!

I'd let others comment on the implementation details, as I'm not very
familiar with bash trickyness, portage and existing checks.

Paweł




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Followup notes: {cvs,git,git.overlays}.gentoo.org migration; awol: some overlays commits, gitweb

[Paweł Hajdan, Jr.]

On 8/19/14 1:00 AM, Robin H. Johnson wrote:
 The new SSH keys, in case you still didn't have them:
 On Mon, Jun 30, 2014 at 10:26:52PM +, Robin H. Johnson wrote:
 1024 5f:c3:fe:9a:ac:a7:99:f4:d3:c1:93:4c:52:87:74:28 (DSA)
 256  aa:6a:e4:74:1d:73:d2:5a:9f:45:9f:18:55:81:c9:9a (ECDSA)
 256  1c:2e:99:7d:c7:f0:bc:3b:a9:fb:d0:3e:2c:2a:79:ba (ED25519)
 2048 24:3b:2d:3b:47:ca:7e:62:48:97:49:6a:f5:ad:66:88 (RSA)

I noticed the ssh host key for cvs.gentoo.org changed just now.

IMHO such announcement would greatly benefit from a digital signature.

Just in case, this is what ssh printed out for me (the new key matches
the announcement):

$ cvs up
@@@
@   WARNING: POSSIBLE DNS SPOOFING DETECTED!  @
@@@
The RSA host key for cvs.gentoo.org has changed,
and the key for the corresponding IP address 148.251.78.52
is unknown. This could either mean that
DNS SPOOFING is happening or the IP address for the host
and its host key have changed at the same time.
@@@
@WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
24:3b:2d:3b:47:ca:7e:62:48:97:49:6a:f5:ad:66:88.
Please contact your system administrator.
Add correct host key in /home/ph/.ssh/known_hosts to get rid of this
message.
Offending RSA key in /home/ph/.ssh/known_hosts:15
RSA host key for cvs.gentoo.org has changed and you have requested
strict checking.
Host key verification failed.
cvs [update aborted]: end of file from server (consult above messages if
any)

Paweł



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] rfc: calling all eclass phase functions by default

[Paweł Hajdan, Jr.]

On 8/17/14, 12:32 AM, Kent Fredric wrote:
 Collison systems I've seen usually do one of two things:
 
 - In the event of a collision, demand the consumer resolve the problem by
 redefining the function the collision occurs on in terms of its composite
 parts. ( which is basically what we already do )
 - Declare syntax to exclude a potential collision from either composite
 part.
 
 Our only real difference at present is unlike these systems, we assume we
 can simply guess which one wins and just choose it automatically, where
 collision systems tend to force you to deal with the situation if any
 collision occurs.

This makes sense to me. Can we consider starting with just a repoman
warning for the collision cases?

The warning would make the problem more visible to ebuild writers. Then
we already have a solution that works, i.e. explicitly defining the
phase function in the ebuild, possibly calling the eclass functions.

My understanding is people not being aware of the problem is the main
issue here, not the ability to address it.

Paweł

 I am also not very comfortable with our current state, because it has
 a lot of uncertainty in terms of how the eclass phase functions are
 called.

 My counter proposal to this is that we stop calling eclass phase
 functions automatically, and to minimize the amount of boilerplating
   we would have to do, we use a variable, such as ECLASS_PHASES  which
   would be defined at the ebuild level and contain a list of the eclass
   phase functions we want to run automatically.

 Going back to my previous example, say your ebuild does the following:

 -- code begins here --

 inherit foo bar

 # Foo and bar both have src_unpack and src_install functions.
 # we want foo's src_unpack and bar's src_install:

 ECLASS_PHASES=foo_src_unpack
 bar_src_install

 -- code ends here ---

 If ECLASS_PHASES is undefined, I think the default should be to not run
 the eclass phase functions.

 Yes, this means there is some boilerplating. However, there are some
 strong advantages:

 - this is no longer dependent on order of inheritance.
 - The ebuild author knows exactly which eclass phase functions will
   be run.


 This proposal, seems reasonable, given my comments. I anticipate however
 its biggest downside would be
 the requirement to state *all* the functions you want, which would lead to
 maintenance headaches
 due to people forgetting to declare they wanted some function or other.
 
 So if you could sculpt it to be broader by default and have less scope for
 developer error, that'd be an improvement.
 
 --- code start --
 ECLASS_EXCLUDE=foo_src_unpack bar_src_unpack
 inherit foo bar baz
 
 
 --- code end ---
 
 here, src_unpack would be baz_src_unpack *regardless* of composition order
 because foo and bar were barred from being used, and baz took
 precedence as a result.
 
 If baz provides no src_unpack, then the ebuild in question is simply left
 without one.
 
 You'll still need to declare src_unpack explicitly if you need use
 conditional behaviour, however.
 




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] rfc: calling all eclass phase functions by default

[Paweł Hajdan, Jr.]

On 8/17/14, 9:18 AM, Michał Górny wrote:
 Dnia 2014-08-17, o godz. 09:06:04
 Paweł Hajdan, Jr. phajdan...@gentoo.org napisał(a):
 The warning would make the problem more visible to ebuild writers. Then
 we already have a solution that works, i.e. explicitly defining the
 phase function in the ebuild, possibly calling the eclass functions.

 My understanding is people not being aware of the problem is the main
 issue here, not the ability to address it.
 
 What we could do is printing the phase function names when starting
 them, e.g.:
 
[foo_src_compile] Compiling sources in ...
 
 As for another idea, we could warn if an eclass overrides phase
 function via implicit inherit without redefining it. As I see it, this
 is the biggest issue here, and a solution that's relatively easy to
 accept.

Both of these sound good to me.

Paweł




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] gcc-4.8 may be needed in stable for www-client/chromium-38.x

[Paweł Hajdan, Jr.]

On 7/29/14 6:49 PM, Michał Górny wrote:
 Dnia 2014-07-23, o godz. 19:48:17
 Paweł Hajdan, Jr. phajdan...@gentoo.org napisał(a):
 
 Looks like www-client/chromium is going to start using c++11 seriously
 and require gcc-4.8+, see thread
 https://groups.google.com/a/chromium.org/d/msg/chromium-packagers/fvJvPG8fa7I/iWPEsUxhKikJ

 This is in the dev channel for now, but given the 6 weeks release cycle
 it'll go to stable in about 3 months, and every time it's a security update.

 I'm trying to get Gentoo prepared now, and so what are our chances to
 get gcc-4.8 to stable by that time?
 
 For the record: https://bugs.gentoo.org/show_bug.cgi?id=516152
 
 I think 4.8 should be our current choice for stable since 4.7 is
 unsupported upstream and 4.7.4 (4.7.3 is stable now) has known unfixed
 bugs.

Sounds good, should we set a specific version as a stabilization target?

I'm successfully using 4.8.3 here.

Paweł




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] minimalistic emerge

[Paweł Hajdan, Jr.]

On 8/8/14, 6:27 PM, Igor wrote:
 Is there any warranty that updated with -uDN system will remain 
 full functional for 1 year? I have 100% warranty that not updated
 system is going to remain functional for 5 or 6 years. I have some with 
 7 years uptime. 

I'd say there is no warranty. However, a staging environment can help
detecting issues earlier, before deploying them to production and
allowing you to come up with a way to address them.

I certainly wouldn't recommend just running an update on a running
production server without testing it first.

 I'm in a trap - if I update daily - the systems are offline, I'm not able 
 to maintain systems after updates - requires too much resources. If you have 
 1 gentoo it might take a few days, imagine you have 100 or 1000 systems and 
 they do not share the same hardware or the same boot locations, 
 they all can be managed by 2 people if not updated and you need about 100 
 people if you update. 

Consider automating the processes - as you pointed out, the way
described above doesn't scale.

Possibly relevant article would be
http://www.site-reliability-engineering.info/2014/04/what-is-site-reliability-engineering.html

 The number of bugs is the same. It's more difficult to hack into 1996 system 
 than in 2012.

Do you have any evidence to back that claim? There are tons of known
vulnerabilities in '96-era software, and automated exploits for them.

By the way, I can see a point in your thread. Our updates and package
manager could be improved. They have improved greatly in the last few
years. I think I can safely say we welcome further contributions of
patches, packaging and testing effort, especially helping automate many
of these tasks.

Paweł



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Status of ppc and ppc64 teams.

[Paweł Hajdan, Jr.]

On 8/5/14, 12:03 AM, Anthony G. Basile wrote:
 The bigger problem is actually KEYWORDREQ's so we are going to
 request maintainers not ever drop ~ppc or ~ppc64 even when they feel
 a major bump has occurred, eg a deep rewrite to a library.  We know 
 this is living dangerously but we'll going to make use of the
 community in this regard --- either someone will bug us on a broken
 ~ppc/~ppc64 package, or we'll catch it at stabilization.

FWIW I don't drop KEYWORDS for bumps considered major.

However, sometimes a major bump means a new dependency not keyworded for
given arch, and in that case I would drop KEYWORDS.

Note that most packages I (co-)maintain are not keyworded ~ppc/ppc64,
but this has happened e.g. for ~arm.

Paweł



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: don't rely on dynamic deps

[Paweł Hajdan, Jr.]

On 7/30/14, 7:36 AM, Samuli Suominen wrote:
 If it's 2-3 packages out of ~300, I'd rather pick them out than
 revision bump all ~300 for the 2-3. Or not pick them out at all
 and let users do the rebuild (which is the obvious answer
 to the output you posted)

Peter Stuge pointed it out already, but I also wanted to say rebuilding
the affected packages is not obvious to me either.

Paweł


 !!! Multiple package instances within a single package slot have been pulled
 !!! into the dependency graph, resulting in a slot conflict:

 virtual/udev:0

   (virtual/udev-208-r2::gentoo, installed) pulled in by
 =virtual/udev-171:0/0=[gudev] required by 
 (media-video/cheese-3.12.2::gentoo, installed)
 virtual/udev:0/0=[gudev] required by (x11-misc/colord-1.2.1::gentoo, 
 installed)

   (virtual/udev-215::gentoo, ebuild scheduled for merge) pulled in by
 =virtual/udev-215 required by (games-util/xboxdrv-0.8.5-r1::gentoo, 
 installed)
 (and 22 more with the same problem)

 
 
 




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: don't rely on dynamic deps

[Paweł Hajdan, Jr.]

On 7/27/14, 1:42 PM, Samuli Suominen wrote:
 Only one person said he had to manually build 2 GNOME related packages,
 simple-scan and something else
 
 So, broken? Far from it. More like essential feature.
 
 People have just listed some known races dynamic deps have, and I take
 those races anyday over an regression that causes
 endless rebuilding...

I think this really boils down to deciding on the tradeoff between
correctness and speed.

Even the example above shows that with dynamic rebuilds some manual
rebuilds were needed, which I interpret as dynamic deps not being correct.

Static deps go the other way around: they do lead to more rebuilds, and
I think no one is denying that. However, they seem more predictable to me.

Paweł



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] don't rely on dynamic deps

[Paweł Hajdan, Jr.]

On 7/21/14, 11:52 PM, Alexander Berntsen wrote:
 Michał has documented the shortcomings of dynamic deps in our wiki[0].
 (Thank you!) [...]
 [0]  https://wiki.gentoo.org/wiki/Project:Portage/Dynamic_dependencies

There's one more thing I'd like to ask about:

For Minor linking change w/ dependency change (unnecessary linking
removed) the dynamic deps cell is red with revbump + mostly
unnecessary rebuild, and static deps says applied after rebuild.

Arguably with dynamic deps one could also skip the revbump, and the
update would similarly be applied after rebuild.

Is my logic correct? I'm just trying to understand it better, and don't
intend an argument in favor of any of the options.

Paweł



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] don't rely on dynamic deps

[Paweł Hajdan, Jr.]

On 7/27/14, 4:42 PM, Rich Freeman wrote:
 With dynamic deps you'd need to revbump if there is a linking change.
 Otherwise portage would just allow the dependency to be removed, and
 then linking will break, since the executable is unnecessarily linked
 to the dependency (in that scenario).

Right, I see - I think I got that right when first reading this, but got
confused after reading so many messages in this thread. Thanks for
patient explanation.

It seems really tricky to correctly reason about dependency resolution.

 One thing I would question in that table is applied immediately (but
 can break hard when dynamic-deps stop working)).  How can dynamically
 removing an unused dependency cause something to break, setting
 aside bugs in the package manager?  If removing a dependency causes
 something to break, how can it be unused?

Yeah, I was also wondering about this.




signature.asc
Description: OpenPGP digital signature

[gentoo-dev] gcc-4.8 may be needed in stable for www-client/chromium-38.x

[Paweł Hajdan, Jr.]

Looks like www-client/chromium is going to start using c++11 seriously
and require gcc-4.8+, see thread
https://groups.google.com/a/chromium.org/d/msg/chromium-packagers/fvJvPG8fa7I/iWPEsUxhKikJ

This is in the dev channel for now, but given the 6 weeks release cycle
it'll go to stable in about 3 months, and every time it's a security update.

I'm trying to get Gentoo prepared now, and so what are our chances to
get gcc-4.8 to stable by that time?

Possible alternative solutions:

1. Depend on clang, and force the build to use it. Possible problem with
this is that since chromium uses very bleeding edge clang, this can put
some strain on our system clang just as well.

2. Patch chromium to make it compile with gcc-4.7. This is almost always
technically possible, but can be a maintainability burden, especially if
upstream doesn't accept some parts of the patches. Also, there are known
problem with chromium, c++11 and gcc-4.7
(https://groups.google.com/a/chromium.org/d/msg/chromium-dev/NrtrEnoMH6g/ERRiVAQcE18J
, although Gentoo is not affected by this one because we have newer dbus).

WDYT?

Paweł



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] don't rely on dynamic deps

[Paweł Hajdan, Jr.]

On 7/21/14, 11:52 PM, Alexander Berntsen wrote:
 Michał has documented the shortcomings of dynamic deps in our wiki[0].
 (Thank you!) This documentation also includes two of our possible
 solutions.

 [0]  https://wiki.gentoo.org/wiki/Project:Portage/Dynamic_dependencies

Thank you, this is very useful. I didn't understand the issue much
before reading that page.

One question: why for Removal of a USE flag along with the relevant
dependencies dynamic deps say revbump + unnecessary rebuild? What
would happen without the revbump?

 1. Improve dynamic-deps. This is, as Michał pointed out earlier in
 this thread a pipe dream.

Agreed.

 2. Remove dynamic-deps. This is what I think currently makes sense.

+1 I also think it's the best option.

Paweł



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Enable format-security in the dev profiles

[Paweł Hajdan, Jr.]

On 7/21/14, 6:02 AM, Samuli Suominen wrote:
 Why not generate a Portage QA warning out from the warning
 -Wformat-security produces instead?
 That way compile wouldn't abort needlessly.

+1, and then it can be done globally.

Paweł




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Prevent to need to change all keywords at the same time

[Paweł Hajdan, Jr.]

On 7/17/14, 2:28 PM, Pacho Ramos wrote:
 I recently noticed this:
 https://bugs.gentoo.org/show_bug.cgi?id=502836
 
 imlib2 ebuild can only be stabilized in one round for all arches as
 KEYWORDS are set in eclass depending on E_STATE=release. That has an
 important drawback as forces all arches to be done at the same time and,
 since some are much slower than others, forces all to wait for them.
 And, as that can depend on even more stabilizations (like it's the case)
 all that bugs blocking the stabilization need to also be done for *all*
 arches before.
 
 I am not sure if any policy exists for this, but I would forbid to make
 this due this issue. I would instead move to use KEYWORDS en ebuild as
 done usually.
 
 What do you think?

+1 to moving KEYWORDS to ebuilds.

Do we know what is the reason for doing this via enlightenment.eclass?

Paweł




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Returning dev: Thomas Alan Gall (tgall)

[Paweł Hajdan, Jr.]

On 7/14/14, 10:26 AM, Justin (jlec) wrote:
 we have an returning oldtimer here, Thomas Gall aka. tgall. His original
 bug has been opened in 2003, so he knows gentoo from the early days.
 
 He is joining the arm team now and will stabilize mostly for arm64,
 where he already started to work with a rate of  10 pkgs/day. Happy
 days for arm users!
 
 Some biographic notes from himself:
 
 Reenactor of War of 1812, Napoleonic French and US Civil War eras. Long
 time software engineer currently working for Linaro as the acting
 director of the Linaro Mobile Group. Former and now returned Gentoo dev
 interested now days in arm and arm64. Former Mayor of Mantorville. Dad,
 husband and general jack of all trades.

Yay, welcome!

Paweł



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] PSA: ruby_targets_ruby21 masked on stable

[Paweł Hajdan, Jr.]

I added the following entry to profiles/base/use.stable.mask:

# dev-lang/ruby:2.1 is not stable.
ruby_targets_ruby21

This is needed for https://bugs.gentoo.org/show_bug.cgi?id=505920, as
otherwise rexical would generate the following repoman error:

  dependency.bad18
   dev-ruby/rexical/rexical-1.0.5-r3.ebuild: DEPEND:
x86(default/linux/x86/13.0)
['=dev-ruby/hoe-2.6.2[ruby_targets_ruby21]', '=dev-ruby/hoe-2.6.2[
ruby_targets_ruby21]', 'dev-ruby/test-unit:2[ruby_targets_ruby21]',
'dev-lang/ruby:2.1', 'dev-ruby/rdoc[ruby_targets_ruby21]',
'dev-ruby/rake[ruby_ta
rgets_ruby21]', 'virtual/rubygems[ruby_targets_ruby21]',
'virtual/rubygems[ruby_targets_ruby21]']

Feel free to recommend better solutions to this in case I missed
something - this error appeared in the middle of this multiple-packages
stabilization, and it seemed better than e.g. reverting the keyword
changes, especially that they're needed for security bug
https://bugs.gentoo.org/show_bug.cgi?id=513290 .

Paweł



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] scanelf-based RDEPEND

[Paweł Hajdan, Jr.]

I'd like to ask for some help with
https://bugs.gentoo.org/show_bug.cgi?id=512806

After the latest check I've done I think the list is valid and should be
added to www-client/chromium's RDEPEND.

Do you see any obvious problems with that? Should I perform some
additional checks?

Note that while ldd -u -r flags /usr/lib/libXrender.so.1 as unused, I
can easily find calls to xrender using http://cs.chromium.org, e.g. in
ui/base/x/x11_util.cc (XRenderFindFormat, XRenderFindStandardFormat,
XRenderQueryExtension). Other libs flagged as unused are not part of the
list attached to the bug.

Paweł



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] RFC: Removing src_test from www-client/chromium

[Paweł Hajdan, Jr.]

On 6/1/14, 4:41 PM, Tom Wijsman wrote:
 I can't speak for other people, but please consider reporting issues
 to Gentoo first. Our bug queue is under 30 bugs, while upstream is
 several thousand. Once we can confirm a bug clearly belongs to
 upstream, we can tell the reporter to file bug upstream or do that
 ourselves, but keeping Gentoo out of the loop seems to increase the
 time needed to fix a bug.
 
 This confuses me; your thread opener seems to suggest you have too much
 bugs, whereas this one seems to suggest you don't have enough bugs.

Encouraging people to report bugs to Gentoo is not the same as saying we
don't have enough bugs. My goal is to make sure the package works well,
and I can't fix problems I don't know about.

 Iotw, why are you making a project-internal decision here?

Please refer to my first post - just checking whether there is something
I may have missed, or some volunteers to help us with the tests.

 Yeah; if failing tests on distributions aren't getting fixed by
 upstream, then there's indeed no point to keep them running.
 
 Though; on the other hand, one has to consider that this acts like a
 priority queue and therefore tests that fail on most distributions would
 get fixed before tests that fail on just one or two distributions.

I haven't seen that happening for Chromium.

 It's a tricky decision to drop them; but it's not an irreversible
 decision, thus a reevaluation in 5 years from now could be possible. If
 that reevaluation then shows a responsive upstream, reconsider src_test.

Yes, totally agreed.

 Don't mind me, I've played devil's advocate to explore the reasoning;
 go ahead if you want to, given it barely result in fatal test failures.

OK.

Paweł



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] RFC: Removing src_test from www-client/chromium

[Paweł Hajdan, Jr.]

On 5/31/14, 8:30 PM, Tom Wijsman wrote:
 On Sat, 31 May 2014 19:50:20 +0200
 Paweł Hajdan, Jr. phajdan...@gentoo.org wrote:
 This is one of my points: I don't remember a single chromium bug filed
 in Gentoo that would be caught by a test or that a failing test
 actually detected.
 
 Your point covers the lack of tests, or tests that are non-fatal;
 however, it doesn't cover tests that are fatal, what if they fail?

I'm confused by the distinction of fatal and non-fatal tests. Neither
upstream nor the Gentoo chromium package makes that distinction.

 By the way, I don't remember seeing many reports about font issues or
 tab crashes. Please make sure to file them when they occur, or just
 point me to them in case I somehow missed them.
 
 They usually go straight to upstream, though I've managed to somehow
 fix it up; as for Gentoo, some people create forum threads about them.

I can't speak for other people, but please consider reporting issues to
Gentoo first. Our bug queue is under 30 bugs, while upstream is several
thousand. Once we can confirm a bug clearly belongs to upstream, we can
tell the reporter to file bug upstream or do that ourselves, but keeping
Gentoo out of the loop seems to increase the time needed to fix a bug.

 (One was due to a library compiled with a less common flag, the other
 due to fontconfig being a regression magnet; both fun to debug, the
 former a test wolud've caught, the latter is due to the lack thereof)

If there's something that could be changed e.g. in chromium's
dependencies, please let me know. There are cases where we require
certain USE flags to be set on dependencies for things to work properly.

About the issue that a test would have caught: was that a chromium test?
If so, which one?

 While I don't run tests myself; the need for them is clear, for
 those that aim for more production ready systems (eg. university
 network PCs).

 This seems too theoretical to me. I'd be fine with someone
 volunteering to maintain chromium's src_test in Gentoo. Unless we
 have such a person though, it seems to mostly take valuable focus
 away from bugs that definitely *do* affect our users, for no provable
 benefit for Gentoo.
 
 What about provable benefit for upstream? Does upstream /dev/null them?

Effectively yes. For an example see
https://bugs.gentoo.org/show_bug.cgi?id=497512 and
https://groups.google.com/a/chromium.org/d/msg/chromium-dev/OdX7ShsOqsM/-R9sexJAEa4J

The failure is not Gentoo-specific, and is not a bug in code but problem
with the test (it makes assumptions about internal glibc
implementation). It actually fails on the latest Ubuntu LTS Trusty Tahr,
which means the test will have to be fixed or disabled upstream. But 6
months of no reaction is not really a good sign IMHO.

Paweł




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] RFC: Removing src_test from www-client/chromium

[Paweł Hajdan, Jr.]

On 5/29/14, 12:46 PM, Tom Wijsman wrote:
 In general it has always worked well after a compile; but, there's every
 now and then one or another annoying regression, like recent Chromium
 had some font issues or some random tabs crash some versions ago and ...
 
 If a test catches one of these, you can immediately report the problem;
 if it is left untested, you'll have to do a debugging adventure instead.

This is one of my points: I don't remember a single chromium bug filed
in Gentoo that would be caught by a test or that a failing test actually
detected.

By the way, I don't remember seeing many reports about font issues or
tab crashes. Please make sure to file them when they occur, or just
point me to them in case I somehow missed them.

 While I don't run tests myself; the need for them is clear, for those
 that aim for more production ready systems (eg. university network PCs).

This seems too theoretical to me. I'd be fine with someone volunteering
to maintain chromium's src_test in Gentoo. Unless we have such a person
though, it seems to mostly take valuable focus away from bugs that
definitely *do* affect our users, for no provable benefit for Gentoo.

Paweł




signature.asc
Description: OpenPGP digital signature

[gentoo-dev] RFC: Removing src_test from www-client/chromium

[Paweł Hajdan, Jr.]

It's more of a project-internal decision IMHO, but just wanted to get
feedback from the larger community.

Currently 11 out of 27 bugs assigned to chromium.g.o are related to test
failures.

I don't remember a single case where a test failure would point to a
real bug in our package.

I'm seriously considering just removing src_test to make the package
more maintainable (less code, less bugs filed, can focus on things that
*do* impact our users).

If you decide to comment in favor of keeping src_test, please consider
volunteering to help us with the bugs.

Feel free to suggest solutions that fall somewhere in between - e.g.
having src_test but not excluding any tests there and using
RESTRICT=test, so that someone who really wants to run the tests FYI can
do so.

Paweł



signature.asc
Description: OpenPGP digital signature