Re: [gentoo-dev] Adding USE=udev to linux profiles

[Matt Turner]

On Thu, Jul 19, 2018 at 3:00 PM, Michael Orlitzky  wrote:
> On 07/19/2018 05:51 PM, Ben Kohler wrote:
>> Hello,
>>
>> I'd like to propose adding USE=udev to our linux profiles (in
>> profiles/default/linux/make.defaults probably).  This flag is already
>> enabled on desktop profiles but it also affects quite a few packages
>> used on non-desktop linux systems.
>>
>> ...
>>
>> Any objections to this idea?
>>
>
> Please add defaults per-package, only where they make sense. Enabling
> flags globally creates a huge headache for people that want them off.
>
> If I want to undo your new flag, I have to set USE="-udev" globally, and
> that clobbers any important per-package defaults that maintainers have set.

I understand the concern at least in theory. But can you please give
me a concrete example of a package where you don't want USE=udev and
another example of a package where you do?

Grepping the tree, I see the following packages pulled in with
USE=udev predominantly:

virtual/libudev
virtual/libgudev
virtual/udev

A few others have some additional dependencies enabled with USE=udev:

app-emulation/libvirt: x11-libs/libpciaccess
dev-qt/qtgui/qtgui: sys-kernel/linux-headers
gnome-base/gnome-desktop: sys-apps/hwids
media-gfx/iscan-data: dev-libs/libxslt, media-gfx/sane-backends
sys-auth/consolekit: x11-libs/libdrm
sys-fs/dosfstools: virtual/pkgconfig


What dependency are you trying to avoid? Or is it just a design issue?

Re: [gentoo-dev] Re: What means bup?

[Matt Turner]

On Wed, Jul 18, 2018 at 3:26 AM, Matthew Thode
 wrote:
> On 18-07-18 09:16:07, Johannes Huber wrote:
>> Hi all,
>>
>> english is not my mother language, so please clarify what bup means, just
>> seen here:
>>
>> https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ee0e0401478cf30b3ced0405f6b89391e05d2397
>>
>> Just checked if it was a typo, but can't be:
>> git log --oneline --grep bup | count -l
>> Expected 0 lines, got 1248.
>>
>
> It's similiar to a sound you make when you touch something's nose.
> *boop*
>
> I just prefer bup instead.  I generally only use it when doing simple
> bumps of packages (copy ebuilds with only keyword edits).

Cute.

Since 94.5% of the 1248 instances were from you... can you please stop?

Re: [gentoo-dev] RFC: gles global USE flag, USE=opengl clarifying

[Matt Turner]

On Mon, Jul 23, 2018 at 10:11 AM, Mart Raudsepp  wrote:
> Hello,
>
> Currently we have rather a mess in terms of OpenGL API handling.
> I think much of it comes from USE=opengl being rather vague - is it
> supposed to mean "Use desktop GL", "Use GLX", or "Enable OpenGL
> support". All of these mean quite different things:
> * desktop GL means full OpenGL API, which in turn can be either used
> via GLX platform (X11 only) or EGL platform.
> * GLX means GLX platform - usable only on X11; all good and same as
> desktop GL in the past, but we have people wanting wayland-only now
> (and YES, desktop GL via EGL platform _is_ a thing), and GLX obviously
> isn't something that works in native wayland.
> * GL support could mean 3D via OpenGL in general; be it OpenGL, GLESv2,
> GLESv3...
>
> To make things easier to follow, there are basically three different
> concepts and potential choices to make:
>
> * API
> * Platform
> * Windowing system
>
> API is either "full desktop" OpenGL (think e.g. OpenGL 4.5), or GLES;
> GLES has multiple versions, but in practice it's GLESv2 with optional
> support for GLESv3 - however afaik latest mesa supports GLESv3 too
> whenever GLESv2 is built.
>
> Platform is either GLX or EGL. GLX only works in combination with "full
> desktop" OpenGL; EGL can work with either.
> For non-Linux there's also CGL (OSX), WGL (Windows), EAGL (iOS) and
> more. Can be interesting for Gentoo Prefix.
>
> "EGL is an interface between Khronos rendering APIs such as OpenGL ES
> or OpenVG and the underlying native platform window system." - thus the
> third choice with EGL platform - windowing system. This then is about
> supporting a certain graphics environment with EGL (with GLX that can
> be taken as just always X).
> This can be for example x11, wayland, GBM (think rendering 3D directly
> on top of a KMS terminal), win32, cocoa, android, vivante framebuffer
> (with proprietary vivante 3D stack; not applicable to open source
> etnaviv), DispmanX (RPi), etc.
> This can be a choice especially for certain kind of OpenGL libraries;
> one big example I know of is GStreamer GL libraries.
>
>
>
> Anyhow, here's an initial proposal to try to sort it out via a USE=gles
> global USE flag and a set of guidelines how to use it together with a
> USE=opengl and other related USE flags in ebuilds:
>
>
> use.desc:
> opengl - Add support for desktop OpenGL (3D graphics)
> gles - Add support for OpenGL ES, or prefer it over desktop OpenGL. This 
> should usually only be enabled globally on embedded systems that do not 
> support full desktop GL.
>
> [How is it correct to refer to "full desktop" GL without it being
> confusing with OpenGL in general?]

That's what people on my team call it to differentiate. "Desktop" vs ES.

> Guidelines:
>
> * If package has optional GL support in general (can work with either
> desktop GL or GLES when OpenGL is enabled; doesn't care which one is
> there), use both opengl and gles in IUSE and enable GL support and
> ebuild logic when either is enabled

Sounds good.

> * If package is fully about OpenGL (GL itself isn't optional) and
> supports either desktop GL or GLES, but not both at once: IUSE="gles"
> and use GLES if that is set, "full desktop" GL otherwise.

Probably the best thing to do.

> * If package is fully about OpenGL (GL itself isn't optional) and
> supports either desktop GL or GLES, including both at once: IUSE="gles
> +opengl" and use whichever is enabled. As GL isn't optional as a whole,
> require at least one of them: REQUIRED_USE="|| ( gles opengl )".

Sounds good.

> * If package has optional OpenGL support and needs specific logic for
> the chosen API: IUSE="gles opengl" or IUSE="gles +opengl", depending if
> GL should be default enabled (albeit we might want to revise this via
> profile level defaults flag instead?) - don't default enable gles, as
> it's not a common use case and such embedded system users will have it
> globally enabled anyways.
> ** Enable any of the GL logic only if either gles or opengl is enabled.
> ** If both are supported at the same time, enable whichever is chosen
> by user (this could often mean also passing a generic --enable-gl
> passing if either USE is set and then specifying the API to use with a
> separate build flag).
> ** If both are not supported at the same time, set REQUIRED_USE="gles?
> ( !opengl )", use whichever is chosen (keeping in mind that both might
> be disabled → no GL at all).
>
> * If package needs to provide choices for the used GL platform or
> windowing system, while GL itself is optional as a whole, don't forget
> to keep the dependencies and other logic for the platform/WS
> conditional to USE=gles and/or USE=opengl. This is usually easiest to
> handle via GL_DEPS helper variable with dependencies applicable to
> either and then putting it in as e.g. "opengl? ( $GL_DEPS ) gles? (
> $GL_DEPS )" together with any specific ones; similar for certain needed
> REQUIRED_USEs, with appropriate conditional blocks in 

Re: [gentoo-dev] Adding USE=udev to linux profiles

[Matt Turner]

On Fri, Jul 20, 2018 at 7:13 AM, Michael Orlitzky  wrote:
> On 07/20/2018 03:37 AM, Matt Turner wrote:
>>>
>>> If I want to undo your new flag, I have to set USE="-udev" globally, and
>>> that clobbers any important per-package defaults that maintainers have set.
>>
>> I understand the concern at least in theory. But can you please give
>> me a concrete example of a package where you don't want USE=udev and
>> another example of a package where you do?
>>
>
> I... probably don't want USE=udev enabled anywhere. What does it
> actually do? I don't know, and the flag description is useless, and I
> don't have time to read the source code to every package with the flag.
>
> But, I'm willing to trust the maintainers who have set IUSE="+udev" in
> their ebuilds.
>
> As an example of how this works out, I have both sys-apps/hwids and
> sys-apps/pciutils built with USE=udev, but media-gfx/gimp built without it.

If it adds no additional dependencies, why do you care?

Re: [gentoo-dev] Changing policy about -Werror

[Matt Turner]

On Sun, Sep 9, 2018 at 4:32 AM Andrew Savchenko  wrote:
>
> Hi!
>
> Our current -Werror policy demands unconditional removal:
> https://devmanual.gentoo.org/ebuild-writing/common-mistakes/index.html#-werror-compiler-flag-not-removed
>
> I think this is wrong, see bugs 665464, 665538 for a recent
> discussion why.

Bug 665464 supports the exact opposite conclusion. Werror turned a
trivial warning into a build failure.

> My point is that in *most* cases -Werror indeed should be removed,
> because upstream rarely can keep up with all possible configure,
> *FLAGS, compiler versions and arch combinations. But! In some cases
> — especially for security oriented software — this flag may be
> pertain and may be kept at maintainer's discretion.
>
> The rationale is that -Werror usually points to dangerous
> situations like uninitialized variables, pointer type mismatch or
> implicit function declaration (and much more) which may lead to
> serious security implications.

Warnings are often over unimportant details (like in this bug). It is
certainly not the case that they "usually point to dangerous
situations".

> So, if maintainer has enough manpower to support this flag, we
> should allow to keep it. Of course if it will cause long-standing
> troubles (e.g. bugs opened for a long time) QA should have power to
> remove it or demand its removal.

In the bug that started this, it was the case that the maintainer
himself had not built the package with this configuration. Nor had any
arch team that recently stabilized the package (x86, amd64, ia64, ppc,
ppc64, arm).

So again, the bug supports the opposite conclusion.

The policy is sound, and I don't think we could have found a worse bug
as supporting evidence that we should revise the policy.

Re: [gentoo-dev] Changing policy about -Werror

[Matt Turner]

On Mon, Sep 10, 2018 at 1:34 PM Chí-Thanh Christopher Nguyễn
 wrote:
>
> Jason Zaman schrieb:
> >> No. With -Werror, upstream indicates that if a warning occurs, the build
> >> should fail and the resulting code not be installed on user systems.
> >>
> >> Instead, someone knowledgeable should look at the situation *first* and
> >> determine whether it is a bogus warning, a trivial issue, or something 
> >> which
> >> warrants further attention.
> >>
> >> I have long disagreed with QA policy on this, and think that ebuilds should
> >> respect upstream here. Of course giving users the ability to override.
> >
> > I disagree. -Werror means that upstream wants it to build without
> > warnings on their distro with their version of the compiler with their
> > versions of all the libraries.
>
> It means, upstream wants it to build without warnings everywhere. And if a
> warning occurs (due to change in compiler, libraries, architecture, etc.),
> have a developer look at it first before installing the code on user systems.

This sounds good in theory, but I think it's pretty well established
that in practice this isn't effective and instead is a large waste of
time. In fact, the foundational premise that it's possible to build
without warnings everywhere is simply wrong.

Consider again the bug that started this. The maintainer had not built
this configuration. None of the arch teams had built this
configuration until I did for the last architecture Cc'd. The patch
committed doesn't change anything installed on the system, if not for
Werror preventing the code from building.

Re: [gentoo-dev] rfc: why are we still distributing the portage tree via rsync?

[Matt Turner]

On Tue, Jul 3, 2018 at 11:38 AM Rich Freeman  wrote:
> 4.  by default git tends to accumulate history, which can eat up disk
> space.  I imagine this could be automatically trimmed if users wanted,
> though during syncing it would at least need to store all the commits
> between the last fetched and next-fetched, and that means fetching
> things that might have been subsequently removed/changed

This is why I have not switched to git. I have /usr/portage on a
separate 1GB partition (with distfiles and packages stored elsewhere).
The ebuild tree is 600MB with rsync and cannot fit on the partition
with git.

I'd be happy to switch if the space requirements were similar.

Re: [gentoo-dev] Is removing old EAPIs worth the churn?

[Matt Turner]

On Mon, Mar 5, 2018 at 9:56 PM, Kent Fredric  wrote:
> On Mon, 5 Mar 2018 17:52:54 -0800
> And with Perl packages at least, incrementing EAPI results in actual
> changes driven by the eclass:
>
> - Changes the names of various control variables
> - Makes perl tests on by default, and parallel by default ( previously
>   required opt-in )
> - Disables the legacy code path that kills the '.packlist' files, which
>   are actually useful to some tools, and was the wrong place to kill
>   those files in the first place.

Sounds like you're not bumping EAPI for its own sake.

Re: [gentoo-dev] Is removing old EAPIs worth the churn?

[Matt Turner]

On Tue, Mar 6, 2018 at 1:35 PM, Rich Freeman  wrote:
> On Tue, Mar 6, 2018 at 4:17 PM, Andreas K. Huettel  
> wrote:
>>
>> Is it worth the effort? Yes, see below.
>> Is it a high priority task? No.
>>
>
> It sounds like all that has been done is to log a tracker and create
> some bugs.  That is hardly a major burden on anybody.  If it nudges
> people to bump the EAPI when they're doing other work so much the
> better, but there doesn't seem to be a drop-dead date yet.
>
> If devs don't want to think about EAPI cleanup they don't have to right now.

No, not true. Look at the blocking bugs. We're asking arch teams to
retest and restabilize ebuilds whose only difference is the EAPI bump.

Re: [gentoo-dev] Is removing old EAPIs worth the churn?

[Matt Turner]

On Tue, Mar 6, 2018 at 1:00 AM, Dirkjan Ochtman <d...@gentoo.org> wrote:
> On Tue, Mar 6, 2018 at 2:52 AM, Matt Turner <matts...@gentoo.org> wrote:
>>
>> In the end we might get to delete some code from portage or an eclass?
>> Does this seem worth it?
>
>
> To add to some of the points Kent made, I think so, yes: this means freeing
> us from the cognitive overhead of thinking about older EAPIs at all, having
> to remember the differences between those old EAPIs and the newer ones.
> Removing that complexity from developer's minds as well as from our tooling
> means our tooling will be we can spend our time and energy on other things,
> which will be a win for the distribution.
>
> Yes, the long tail is painful: these are probably the packages that haven't
> been upgraded before for a reason, but actually putting the finishing
> touches on the EAPI migration will be worth it in the end.

The long tail of packages were packages that by definition didn't
require any maintenance or add to our collective cognitive overhead.
:)

Re: [gentoo-dev] Is removing old EAPIs worth the churn?

[Matt Turner]

On Tue, Mar 6, 2018 at 1:17 PM, Andreas K. Huettel <dilfri...@gentoo.org> wrote:
> Am Dienstag, 6. März 2018, 02:52:54 CET schrieb Matt Turner:
>> EAPI 2 removal bug: https://bugs.gentoo.org/648050
>>
>> It seems like tons of churn to update old stable ebuilds to a new
>> EAPI, just for its own sake. Take https://bugs.gentoo.org/648154 for
>> example. New ebuild added with EAPI 6 bumped from EAPI 2. Otherwise
>> functionally identical. Now asking arch teams to retest and
>> restabilize. Multiply by 100 or more.
>
> OK so here's my personal opinion:
>
> Is it worth the effort? Yes, see below.
> Is it a high priority task? No.
>
> Is it really that much effort? Well, we're even in the case of EAPI=2 talking
> about only 400 ebuilds of 35000 in total. That's roughly 1% of the tree. And
> I'd strongly suspect that even without the EAPI update it would make very much
> sense to check these 400 old ebuilds and test whether they still work as
> intended.

There are plenty of reported bugs to look at. No need to go searching
for more :)

> What do we gain?
>
> * Mainly, less stuff to memorize. I'll be throwing a party on the day when the
> last EAPI=0 ebuild is gone. (In the retirement home, probably.)

This is the argument made by others about the cognitive overhead of
remembering all the EAPI differences. If the packages are untouched
for ages and don't require maintenance, my claim is that there is no
cognitive load to begin with.

> * Also, it's not just having a bigger number, but also useful features...
>
> Why now EAPI=2?
>
> * EAPI=3 is nearly gone (27 ebuilds left, scheme & java please get a move! :)
> * EAPI=2 is the one with the next-least ebuilds.
>
> While it would be very nice to remove EAPI=0, let's go for easier targets
> first; the number of EAPI=0 ebuilds will decrease organically in the meantime.
>
> [Interestingly, as long as no specific efforts are made, the number of ebuilds
> in all deprecated EAPI decreases roughly equally and exponentially. That means
> the probability of any old ebuild to be removed within a certain time interval
> is a constant as function of time...]

This is a great point in favor of *not* bothering to proactively bump EAPI.

Re: [gentoo-dev] Is removing old EAPIs worth the churn?

[Matt Turner]

On Tue, Mar 6, 2018 at 2:27 PM, Alec Warner <anta...@gentoo.org> wrote:
> On Tue, Mar 6, 2018 at 5:22 PM, Matt Turner <matts...@gentoo.org> wrote:
>> On Tue, Mar 6, 2018 at 1:35 PM, Rich Freeman <ri...@gentoo.org> wrote:
>> > On Tue, Mar 6, 2018 at 4:17 PM, Andreas K. Huettel
>> > <dilfri...@gentoo.org> wrote:
>> >>
>> >> Is it worth the effort? Yes, see below.
>> >> Is it a high priority task? No.
>> >>
>> >
>> > It sounds like all that has been done is to log a tracker and create
>> > some bugs.  That is hardly a major burden on anybody.  If it nudges
>> > people to bump the EAPI when they're doing other work so much the
>> > better, but there doesn't seem to be a drop-dead date yet.
>> >
>> > If devs don't want to think about EAPI cleanup they don't have to right
>> > now.
>>
>> No, not true. Look at the blocking bugs. We're asking arch teams to
>> retest and restabilize ebuilds whose only difference is the EAPI bump.
>>
>
> Ultimate the arch teams are supposed to test the ebuild (that it works), so
> when we change the EAPI of the ebuild re-testing is required.

Of course, but that's not the point...

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

[Matt Turner]

On Sat, Apr 7, 2018 at 12:57 PM, Lars Wendler  wrote:
> On Sat, 7 Apr 2018 14:16:33 -0500 William Hubbs wrote:
>
>>On Sat, Apr 07, 2018 at 02:55:53PM -0400, Michael Orlitzky wrote:
>>> On 04/07/2018 02:44 PM, William Hubbs wrote:
>>> >
>>> > I'm with floppym on this one. Is there a specific reason we enable
>>> > them globally?
>>>
>>> It's a relic from before we had IUSE defaults.
>>>
>>>
>>> > Since there has been so little discussion on this thread, I will
>>> > start looking at what I need to do to remove these use flags from
>>> > the profiles.
>>>
>>> There's probably a few packages that will need IUSE defaults to avoid
>>> breakage, and everyone else should get fair warning before the flags
>>> are turned off by default.
>>
>>There is the case of packages that optionally use a db back end,
>>and I would argue that those may not need iuse defaults.
>>
>>It could also be argued that having one backend enabled globally is
>>good for consistency, but that would end up leading down a bikeshed
>>path that I'm not sure we should go down. I'm just not sure it makes
>>sense to enable more than one of these backends globally.
>>
>>Thoughts?
>>
>>William
>>
>
> Considering the questionable license situation with latest sys-libs/db
> releases (AGPL), I'd say we should prefer gdbm over berkdb in case we
> want to keep one db backend default enabled.
> IIRC Fedora is even trying to entirely getting rid of berkdb.

Interesting. I wasn't aware of that. Here's a link with more information:

https://bugzilla.redhat.com/show_bug.cgi?id=1361971

[gentoo-dev] Last Rites: x11-libs/libXp and x11-proto/printproto

[Matt Turner]

# Matt Turner <matts...@gentoo.org> (21 Apr 2018)
# Protocol headers and client library for the long dead Xprint extension.
# Removal in 30 days. Bug #649076.
x11-proto/printproto
x11-libs/libXp


signature.asc
Description: Digital signature

[gentoo-dev] Last rites: x11-libs/xpyb

[Matt Turner]

# Matt Turner <matts...@gentoo.org> (21 Apr 2018)
# Awful, unmaintained, unused. Removal in 30 days. Bug #651300.
x11-libs/xpyb


signature.asc
Description: Digital signature

[gentoo-dev] Re: Monthly x11@ project status for April 2018

[Matt Turner]

On Sun, Apr 1, 2018 at 8:08 PM, Matt Turner <matts...@gentoo.org> wrote:
> == Update packages to depend on x11-base/xorg-proto ==
> https://bugs.gentoo.org/651286
>
> The new x11-base/xorg-proto package combines nearly all (28 in fact) of
> the x11-proto/* packages into one, with a very fast Meson build system.
> It installs on my laptop in less time than it takes to ./configure one
> of the individual x11-proto/ packages. I've kept empty versions of the
> x11-proto/ packages to ease the transition.
>
> Once the last two architectures have stabilized it (arm@ and arm64@), we
> can begin transitioning to depending on x11-base/xorg-proto directly
> instead of the x11-proto/ packages.

Question from IRC: why is the package named x11-base/xorg-proto
instead of x11-proto/xorgproto?

Once all of the now empty compatibility packages in x11-proto/ are
gone, the only remaining packages in the category will be printproto
and xcb-proto. The plan is to give last rites to printproto and move
xcb-proto to some other category, x11-base probably, and get rid of
x11-proto/ entirely.

The dash in the xorg-proto is just for consistency with the other
x11-base/ packages.

[gentoo-dev] Monthly x11@ project status for April 2018

[Matt Turner]

I'd like to start giving ~monthly updates on the status of x11@ packages
in Gentoo. I hope it gives some insight into the status of a rather
important set of packages and maybe encourages others to lend a hand to
a very understaffed project when possible.

I expect future reports to be significantly shorter.

x11@ currently maintains 291 packages. This number is down from 328
after the removal of 37 drivers for very old hardware in bug 606132.

x11@ is currently assigned or cc'd on 222 bugs. This number is down from
more than 412 in February 2015 (I reported this on #gentoo-desktop after
closing out a bunch of bugs that day).

I work on media-libs/mesa professionally for Intel, so I am involved
with upstream for a number of the projects maintained by x11@ and know
the right people to contact for the others. My strategy maintaining x11
packages is to keep a git ebuild in sync with upstream changes. When a
release is made, everything should already be ready on the Gentoo side,
and I'm able to just copy the git ebuild. This has enabled me to provide
new versions of packages very quickly. I believe it has also helped
reduce the time to stabilizing packages, since users often test and
report bugs against the git ebuilds.

My list of to-do items consists of:

== Fix x11-base/xorg-server suid/systemd situation ==
https://bugs.gentoo.org/635102

Under some circumstances (kernel modesetting driver + systemd, I think)
Xorg should be able to run without root privileges. We were shipping a
USE=suid option without anyone knowing or understanding its purpose.

For >=x11-base/xorg-server-1.20 I plan to ship the xserver in a way that
allows systemd/elogind users with kernel modesetting drivers to run Xorg
without root privileges. I expect to push version 1.19.99.902 (1.20 RC2)
into the tree soon with something working for systemd. I would very much
appreciate an ebuild patch from any elogind user as well as non-systemd
testing to make sure I haven't broken anything like I did with
1.19.99.901.

== Update packages to depend on x11-base/xorg-proto ==
https://bugs.gentoo.org/651286

The new x11-base/xorg-proto package combines nearly all (28 in fact) of
the x11-proto/* packages into one, with a very fast Meson build system.
It installs on my laptop in less time than it takes to ./configure one
of the individual x11-proto/ packages. I've kept empty versions of the
x11-proto/ packages to ease the transition.

Once the last two architectures have stabilized it (arm@ and arm64@), we
can begin transitioning to depending on x11-base/xorg-proto directly
instead of the x11-proto/ packages.

If there's a way to have repoman alert developers to deprecated
dependencies in the same way we handle deprecated eclasses, I'd like to
know about it.

== Remove x11-proto/printproto and x11-libs/libXp ==
https://bugs.gentoo.org/649076

Support for the Xprint extension was removed from xorg-server-1.6.0
released 9 years ago, yet a handful of packages still claimed a
dependence on the Xprint client library libXp.

We've nearly removed all traces of it, and are waiting on the last few
bugs to be closed out.

== Convert media-libs/mesa ebuild to build with Meson ==

Mesa has grown a Meson build system over the last few months. I plan to
ship media-libs/mesa-18.1 (Q2 2018) using Meson.

hanetzer in #gentoo-desktop has been working on this.

== Convert media-libs/xorg-server ebuild to build with Meson ==

The Xserver has also grown a Meson build system. I think it will
probably be in reasonable shape by 1.20, but I don't want to delay it
getting into the tree for that. 1.21 will probably be a long way off,
but I expect to ship it with Meson, if not something before.

No work has been done on this.

== Add and require glvnd ==
https://bugs.gentoo.org/606924
https://github.com/NVIDIA/libglvnd

OpenGL has historically been provided by a vendor's libGL.so. That's
caused a number of headaches for distributions, since both
x11-drivers/nvidia-drivers and media-libs/mesa would like to install
/usr/lib/libGL.so.

The GL Vendor-Neutral Dispatch library ("glvnd") defines a new common
library interface, which dispatches to the underlying hardware driver.

Mesa and the NVIDIA drivers both have support, but it needs to be wired
up in Gentoo. Doing this would allow us to get rid of
app-eselect/eselect-opengl and a whole class of build failures.

No work has been done on this. I plan to do it after Mesa is converted
to build with Meson.

== Drop app-eselect/eselect-mesa ==
https://bugs.gentoo.org/576334

While app-eselect/eselect-opengl allows users to switch between OpenGL
implementations (x11-drivers/nvidia-drivers vs media-libs/mesa),
app-eselect/eselect-mesa allows users to switch between Mesa drivers for
the same hardware. This made sense a few years ago, when there were both
Gallium and "classic" DRI drivers for the same hardware, but today only
the 10 year old i915/i945 integrated graphics still falls into this
category. Frankly, both of the driver options 

[gentoo-dev] Monthly mips@ project status for April 2018

[Matt Turner]

I'd like to start giving ~monthly updates on the status of mips@ in
Gentoo.

Recently I received a Loongson 3A system (quad-core 1.35GHz, 16GB RAM,
AMD graphics) which is significantly faster and more stable than any
other mips system I have.

mips@ is currently assigned or cc'd on 29 bugs. This number is down from
probably >50 at the beginning of March.

My list of to-do items consists of:

== Switch to stable profiles ==
https://github.com/gentoo/gentoo/pull/7672

While keeping mips unstable (KEYWORDS=~mips) I plan to switch the
profiles from exp to stable so that no new breakage is added.

To that end, I've been working to test and keyword packages until we can
flip the switch without adding any breakage ourselves. See the github
pull request for the current status. I'll periodically rebase the branch
as I add more keywords to the main tree.

My plan is to add stable 17.0 mips profiles when the keywording is
sorted out and kill two birds with one stone.

== Loongson 3A support ==

The Loongson 3A system I received requires a number of out of tree
patches to the kernel, gcc, binutils, and glibc. I've seen their
developers working to upstream kernel patches, but it's slow going and
there are a lot of them.

I haven't seen much work to upstream the other patches. I'm not sure how
to reasonably support hardware requiring so many out-of-tree patches.

== n64 (the ABI!) support ==
https://bugs.gentoo.org/show_bug.cgi?id=442548
https://bugs.gentoo.org/show_bug.cgi?id=513042

I want to support the tree main ABIs: Old 32 ("o32"), New 32 ("n32"),
and New 64 ("n64").

n32 is equivalent to amd64's x32 ABI: 64-bit ABI but with 32-bit
pointers. It's the default ABI we use for 64-bit MIPS.

I'd like to offer n64 support as well, but gcc is not quite ready. At
this point I have figured out the gcc build system enough to hack
something together that works. I just need to... upstream something I
guess?

== n64 toolchain in n32 system ==
https://bugs.gentoo.org/show_bug.cgi?id=477956

n32 (and o32) only offer 31-bits of address space (2GB). That's not
sufficient to link large libraries like webkit-gtk. For n32 systems, I'd
like the toolchain binaries to be n64, to avoid these problems.

That's going to be some amount of work on top of regular n64 support,
but hopefully not too much. multilib/ABI_MIPS support already exists and
works.

== stages and installation media ==
https://bugs.gentoo.org/show_bug.cgi?id=150402
https://bugs.gentoo.org/show_bug.cgi?id=348647

With so many subarchitectures, ABIs, and two byte orderings providing
stages and installation media has been a pain point.

I'd like to automate as much of this as possible. I really need Kumba to
build a new SGI CD, but well, that bug's been open since 2006.


signature.asc
Description: Digital signature

Re: [gentoo-dev] [PATCH] cmake-utils.eclass: Make the new ASM-ATT rules actually work

[Matt Turner]

Thanks for looking into this!

I'm not sure I understand the -nostdlib portion. It's something about
working around a side-effect of -x assembler?

Re: [gentoo-dev] [PATCH] cmake-utils.eclass: Make the new ASM-ATT rules actually work

[Matt Turner]

On Mon, Mar 19, 2018 at 3:40 PM, James Le Cuirot <ch...@gentoo.org> wrote:
> On Mon, 19 Mar 2018 15:16:47 -0700
> Matt Turner <matts...@gentoo.org> wrote:
>
>> Thanks for looking into this!
>>
>> I'm not sure I understand the -nostdlib portion. It's something about
>> working around a side-effect of -x assembler?
>
> It's not related to that option. I think it's because this is normally
> built with "as" and "ld" and by using "gcc" instead, it tries to link
> libc and friends, which otherwise wouldn't happen. It'll fail if you
> take it away and you'll find the error if you dig through tons of
> strace. Strangely you don't see the linking command in the regular
> build output.

I finally got around to testing this, and it works like a charm.
Thanks a bunch, and thanks for the upstream fix as well.

I just pushed it -- finally that pesky bug 625844 is fixed after 9 months :)

Thanks to mgorny for his work on it too!

[gentoo-dev] Is removing old EAPIs worth the churn?

[Matt Turner]

EAPI 2 removal bug: https://bugs.gentoo.org/648050

It seems like tons of churn to update old stable ebuilds to a new
EAPI, just for its own sake. Take https://bugs.gentoo.org/648154 for
example. New ebuild added with EAPI 6 bumped from EAPI 2. Otherwise
functionally identical. Now asking arch teams to retest and
restabilize. Multiply by 100 or more.

In the end we might get to delete some code from portage or an eclass?
Does this seem worth it?

Re: [gentoo-dev] net-dns/dnssec-root: Blind stable on arm, critical bug 667774

[Matt Turner]

On Thu, Oct 11, 2018 at 4:38 PM Sergei Trofimovich  wrote:
>
> On Thu, 11 Oct 2018 17:10:10 +0200
> Thomas Deutschmann  wrote:
>
> > Let me quote 
> > https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=f6f6bb91b7f134a121ef9fa1dd504b9ca52c5aa8:
> >
> > > net-dns/dnssec-root: Blind stable on arm, critical bug 667774
> > >
> > > Note that this is a major fail for a stable architecture.
> > > In addition, all arm devboxes are currently offline.
> > >
> > > Bug: https://bugs.gentoo.org/667774
> > > Signed-off-by: Andreas K. Hüttel 
> > > Package-Manager: Portage-2.3.49, Repoman-2.3.11
> >
> > ...and now let's all sit down and enjoy how stable ARM users lose access
> > to the Internet and have to figure out how to deactivate DNSSEC to get
> > back online. ;]
> >
> > Maybe it is time to destabilize ARM on Gentoo to stop the impression
> > that we really support ARM.
>
> [ CC: arm@ ]
>
> A few points to think about:
>
> 1. I have read this as a direct statement that ARM is not maintained.
>I don't think it is a fair (or constructive) assessment of team's work
>on ARM front.

It's maintained, but in my experience it's often the last architecture
to handle a bug. Often by a wide margin.

Take a look at the shapes these graphs:
https://www.akhuettel.de/gentoo-bugs/arches.php

maekke and zlogene do a lot of arm stabilizations, but I'm sure it's
too much work for two people alone, especially if all the arm devboxes
are offline (WTF?).

[gentoo-dev] Last rites: app-eselect/eselect-mesa

[Matt Turner]

Forgot to send this one out when I committed it.

# Matt Turner  (29 Sep 2018)
# Removal in 30 days, bug #576334
app-eselect/eselect-mesa


signature.asc
Description: PGP signature

[gentoo-dev] Last rites: media-libs/libomxil-bellagio

[Matt Turner]

# Matt Turner  (16 Oct 2018)
# Unmaintained. Unused. Removal in 30 days. Bug #668826
media-libs/libomxil-bellagio


signature.asc
Description: PGP signature

Re: [gentoo-dev] Last rites: =x11-drivers/nvidia-drivers-375* =x11-drivers/nvidia-drivers-378* =x11-drivers/nvidia-drivers-381* =x11-drivers/nvidia-drivers-384* =x11-drivers/nvidia-drivers-387* =x11-d

[Matt Turner]

On Sun, Dec 16, 2018 at 5:20 PM Jeroen Roovers  wrote:
>
> On Sun, 16 Dec 2018 14:45:11 -0500
> Matt Turner  wrote:
>
> > I guess my question to you is whether you think it's okay to mask -304
> > for removal or whether there are enough users that we should keep it
> > under package.mask?
>
> "The Linux 304.* legacy driver series is the last to support the NV4x
> and G7x GPUs and motherboard chipsets based on them. Support for new
> Linux kernels and X servers, as well as fixes for critical bugs, will
> be included in 304.* legacy releases through the end of 2017." [1]
>
> That should be fine, then: 304 no longer receives security support so it
> can go away along with xorg-server-1.19.

Thanks Jer!

Re: [gentoo-dev] Last rites: =x11-drivers/nvidia-drivers-375* =x11-drivers/nvidia-drivers-378* =x11-drivers/nvidia-drivers-381* =x11-drivers/nvidia-drivers-384* =x11-drivers/nvidia-drivers-387* =x11-d

[Matt Turner]

On Sun, Dec 16, 2018 at 2:40 PM Jeroen Roovers  wrote:
>
> On Fri, 14 Dec 2018 12:03:52 -0800
> Matt Turner  wrote:
>
> > Thanks. What do we want to do about -304?
>
> It's not on the list above because it's a "legacy driver", not a
> "short lived" branch[1]. It's not relevant in this context what happens
> to the 304 branch, the context being a cleanup of intermediate branches
> that were abandoned and surpassed by "long lived" branches.

I understand. This was just a convenient place to ask a related question.

> > It still requires xorg-server-1.19 which I'd like to drop due to a
> > security vulnerability. After the listed versions are gone, -304 will
> > be the only thing keeping 1.19 in tree.

It's bug https://bugs.gentoo.org/669588

> I see no open security bug report for this. If we had one of those, then
> we could write a package.mask entry for both xorg-server and
> nvidia-drivers with a reference to the security issue, or add the
> branches that are now masked for removal. That way people can plan
> their hardware's obsolescence properly or shift to a different driver.

I guess my question to you is whether you think it's okay to mask -304
for removal or whether there are enough users that we should keep it
under package.mask?

Re: [gentoo-dev] Last rites: =x11-drivers/nvidia-drivers-375* =x11-drivers/nvidia-drivers-378* =x11-drivers/nvidia-drivers-381* =x11-drivers/nvidia-drivers-384* =x11-drivers/nvidia-drivers-387* =x11-d

[Matt Turner]

On Fri, Dec 14, 2018 at 6:04 AM Jeroen Roovers  wrote:
>
> According to Nvidia these are former "Short Lived" branches that are no
> longer supported.
>
>
> # Jeroen Roovers  (14 Dec 2018)
> # Deprecated short lived branches
> # https://www.nvidia.com/object/unix.html
> # File a bug report if you need to use one of these
> # Removal on or about 14 January 2019
> =x11-drivers/nvidia-drivers-375*
> =x11-drivers/nvidia-drivers-378*
> =x11-drivers/nvidia-drivers-381*
> =x11-drivers/nvidia-drivers-384*
> =x11-drivers/nvidia-drivers-387*
> =x11-drivers/nvidia-drivers-396*

Thanks. What do we want to do about -304? It still requires
xorg-server-1.19 which I'd like to drop due to a security
vulnerability. After the listed versions are gone, -304 will be the
only thing keeping 1.19 in tree.

Re: [gentoo-dev] Packages up for grabs from xmw@g.o

[Matt Turner]

On Sun, Nov 25, 2018 at 2:05 AM Michał Górny  wrote:
> app-shells/autojump

I'll take this.

Re: [gentoo-dev] AUTHORS file for portage repository

[Matt Turner]

On Tue, Nov 27, 2018 at 7:41 AM Rich Freeman  wrote:
> It makes sense to ensure that the solution actually solves the problem
> before we simply implement it.
>
> If we really need such a file it would probably also make more sense
> to have it auto-generated from git commit headers

And how do you want to determine whether William's contributions are
copyright Sony or now? Do you want to look up his timezone and check
whether they were made during work hours?

If this satisfies Sony, please don't bikeshed this. The perfect it the
enemy of the good.

Re: [gentoo-dev] AUTHORS file for portage repository

[Matt Turner]

On Tue, Nov 27, 2018 at 7:58 AM Andrey Utkin  wrote:
>
> On Tue, Nov 27, 2018 at 09:12:26AM -0600, William Hubbs wrote:
> > All,
> >
> > based on the previous thread about copyright attribution clarifications,
> > I want to add the following AUTHORS file to the top level of the portage
> > repository if no one objects.
> >
> > This is based on the description of the AUTHORS file at Google [1].
> >
> > Everyone is not required to be listed, but  there is no reason you can't
> > add yourself if you have contributed to the tree and want to be listed.
> >
> > I hope this will satisfy everyone involved in the discussion.
> >
> > Thoughts?
>
> It seems to me this will grow huge, and be the source of annoyance for
> users.

I'm imagining it's only those that are not obvious from the commit log
that will be listed here. But regardless, you're right that it will
grow. At the same time I doubt it will be a serious concern, and in
the case that it becomes one we can sort it out then.

Re: [gentoo-dev] AUTHORS file for portage repository

[Matt Turner]

On Tue, Nov 27, 2018 at 12:11 PM Rich Freeman  wrote:
>
> On Tue, Nov 27, 2018 at 2:58 PM Matt Turner  wrote:
> >
> > What Copyright-owner header are you talking about?
>
> We would create one, just as we've created bugzilla tags in git for
> closing bugs/etc.  Surely putting one line in a commit is no more
> difficult than putting one file in a repository?  Indeed anybody can
> start sticking such a tag in commits today without any involvement
> from anybody else.
>
> > You've been the
> > most outspoken opponent of using what appears to be the standard
> > attribution form specified in GLEP-76
>
> When have I been opposed to anything in GLEP 76?  I'll admit that I

Now what I said. You've been the most outspoken opponent of using the
standard attribution format specified in GLEP-76. You know, the one
that says

Copyright YEARS MAIN-CONTRIBUTOR [OTHER-CONTRIBUTOR]... [and others]

and would suggest that it's allowable for Sony's name to be listed as
the MAIN-CONTRIBUTOR instead of Gentoo Authors.

> don't 100% agree with everything in there, but I'm fine with following
> the GLEP as it is written.  Multi-line copyright notices aren't in
> there, and the intent was never to be accumulating copyright holders
> on the single notice line.  An authors file was a compromise I wasn't
> a huge fan of, but I'm suggesting that if we have one it ought to be
> auto-generated (presumably with the work being done by somebody who
> actually wants the file to be there).
>
> Also, GLEP 76 as it is written says: "Projects using this scheme must
> track authorship in a VCS, unless they list all authors of
> copyrightable contributions in an AUTHORS file."
>
> So, a VCS is the PREFERRED way of doing it.  The alternative is
> listing ALL authors in the authors file.  Right now it seems like
> people are advocating for only listing some authors.

Let's not pretend that the authors of the GLEP (you're listed first,
by the way!) foresaw these issues (and rather obvious ones at that, I
might add). I'm already having to communicate the authors' intentions
and how they're different from what regular folks would think after
reading the GLEP (see:
https://github.com/gentoo/gentoo/pull/10481#issuecomment-442175181)

So let's satisfy everyone and be done with it: Let's put AUTHORS in
Git with a section header that states that these Copyright holders are
not obvious from the git history. This is where Sony would go. Then
let's append the output of "git log --format='%aN <%aE>" during
metadata generation or whenever stuff like that gets expanded. That
output is currently 36k FWIW.

Or, I don't know. Come up with something better and continue
bikeshedding. I won't.

> > I know mailing list debates are your personal pastime but this is a
> > real wasteoftime.
>
> You're the one advocating for changing the status quo.  I'm happy if
> we drop the whole topic entirely.  You certainly can't point fingers
> at others when you're proposing doing something differently.  We
> wouldn't be having this discussion if some contributors were unwilling
> to contribute under our current standards.

At what point would you say maybe gentoo-{dev,proj}@ has heard enough
of me for a while? I'd wager that you have an order of magnitude more
emails to these lists this calendar year than commits to gentoo.git. I
see 20 commits and I'm not going to try count all your messages.

Re: [gentoo-dev] AUTHORS file for portage repository

[Matt Turner]

On Tue, Nov 27, 2018 at 9:49 AM Rich Freeman  wrote:
>
> On Tue, Nov 27, 2018 at 11:59 AM Matt Turner  wrote:
> >
> > On Tue, Nov 27, 2018 at 7:41 AM Rich Freeman  wrote:
> > > It makes sense to ensure that the solution actually solves the problem
> > > before we simply implement it.
> > >
> > > If we really need such a file it would probably also make more sense
> > > to have it auto-generated from git commit headers
> >
> > And how do you want to determine whether William's contributions are
> > copyright Sony or now? Do you want to look up his timezone and check
> > whether they were made during work hours?
>
> No, you look at the Copyright-owner header or whatever we want to call
> it, and use that.  Companies that care about labeling what they own
> can take the time to properly document this.

What Copyright-owner header are you talking about? You've been the
most outspoken opponent of using what appears to be the standard
attribution form specified in GLEP-76, and now that we have what I
think is a really good compromise you're against that too?

I know mailing list debates are your personal pastime but this is a
real wasteoftime.

Re: [gentoo-dev] Changing policy about -Werror

[Matt Turner]

On Wed, Sep 12, 2018 at 4:03 PM Rich Freeman  wrote:
> Now, I could buy that -Werror turns NEW warnings into fatal errors,
> due to the use of a newer toolchain, since upstream probably didn't
> test with that toolchain and thus wouldn't have seen the warning.

Yes, exactly. This is one of the major things people have said repeatedly.

Werror makes moving gcc forward much more difficult.

Re: [gentoo-dev] Changing policy about -Werror

[Matt Turner]

On Wed, Sep 12, 2018 at 5:11 PM Rich Freeman  wrote:
>
> On Wed, Sep 12, 2018 at 7:52 PM Matt Turner  wrote:
> >
> > On Wed, Sep 12, 2018 at 4:03 PM Rich Freeman  wrote:
> > > Now, I could buy that -Werror turns NEW warnings into fatal errors,
> > > due to the use of a newer toolchain, since upstream probably didn't
> > > test with that toolchain and thus wouldn't have seen the warning.
> >
> > Yes, exactly. This is one of the major things people have said repeatedly.
> >
> > Werror makes moving gcc forward much more difficult.
> >
>
> Sure, but wouldn't a block on newer versions of gcc cause similar headaches?

Sure...? Who is suggesting that? I'm not sure where you're going with this.

With new GCC comes new warnings, and harmless as the vast majority are
they cause the build to break with Werror.

Re: [gentoo-dev] [RFC] C++ standard in ebuilds

[Matt Turner]

I don't understand what a potential solution would be.

The various projects use -std=c++XXX because that's what their code
requires. -std=c++XXX can't generally be changed. If a dependent
project is incompatible that's no different than any other case of
incompatible dependencies in Gentoo.

I think -std=c++XXX discussions before happened because gcc changed
the C++ ABI with -std=c++11. I don't think that's particularly
relevant here, since as far as I know different -std=c++XXX values
don't change the ABI with current gcc.

So I guess my understanding is that there isn't a problem different
than existing incompatible dependencies, but maybe I have
misunderstood you.

Re: [gentoo-dev] Changing policy about -Werror

[Matt Turner]

On Thu, Sep 13, 2018 at 4:13 PM Richard Yao  wrote:
> > On Sep 13, 2018, at 12:03 PM, Fabian Groffen  wrote:
> >
> >> On 13-09-2018 07:36:09 -0400, Richard Yao wrote:
> >>
> >>
>  On Sep 12, 2018, at 6:55 PM, Thomas Deutschmann  
>  wrote:
> 
>  On 2018-09-12 16:50, Rich Freeman wrote:
>  There is also the case where we want these warnings to block
>  installation, because the risk of there being a problem is too great.
> >>>
> >>> I really disagree with that. So many devs have already said multiple
> >>> times in this thread that "-Werror" is only turning existing warnings
> >>> into fatal errors but "-Werror" itself doesn't add any new checks and
> >>> more often requires "-O3" to be useful.
> >> The way that compilers work is that the warnings are generated in the 
> >> front end while the optimization level affects the backend. That means 
> >> that -O3 has no effect on the code that does error generation. This remark 
> >> about -O3 being needed to make -Werror useful is just plain wrong.
> >
> > Huh?  -O3 enables more checks, which can generate more warnings.
>
> What checks are those? -O3 affects backend optimization while warnings are 
> generated by the front end. Once the immediate representation is generated, 
> there are no other warnings aside from those from the linker.

https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html

Search for "depend on"

-> [...] estimated based on heuristics that depend on thelevel
argument and on optimization

-> Because these warnings depend on optimization [...]

Yes, warnings are dependent on optimization level.

Re: [gentoo-dev] Changing policy about -Werror

[Matt Turner]

On Thu, Sep 13, 2018 at 5:44 PM Richard Yao  wrote:
> > On Sep 13, 2018, at 7:21 PM, Matt Turner  wrote:
> >
> > On Thu, Sep 13, 2018 at 4:13 PM Richard Yao  wrote:
> >>> On Sep 13, 2018, at 12:03 PM, Fabian Groffen  wrote:
> >>>
> >>>> On 13-09-2018 07:36:09 -0400, Richard Yao wrote:
> >>>>
> >>>>
> >>>>>> On Sep 12, 2018, at 6:55 PM, Thomas Deutschmann  
> >>>>>> wrote:
> >>>>>>
> >>>>>> On 2018-09-12 16:50, Rich Freeman wrote:
> >>>>>> There is also the case where we want these warnings to block
> >>>>>> installation, because the risk of there being a problem is too great.
> >>>>>
> >>>>> I really disagree with that. So many devs have already said multiple
> >>>>> times in this thread that "-Werror" is only turning existing warnings
> >>>>> into fatal errors but "-Werror" itself doesn't add any new checks and
> >>>>> more often requires "-O3" to be useful.
> >>>> The way that compilers work is that the warnings are generated in the 
> >>>> front end while the optimization level affects the backend. That means 
> >>>> that -O3 has no effect on the code that does error generation. This 
> >>>> remark about -O3 being needed to make -Werror useful is just plain wrong.
> >>>
> >>> Huh?  -O3 enables more checks, which can generate more warnings.
> >>
> >> What checks are those? -O3 affects backend optimization while warnings are 
> >> generated by the front end. Once the immediate representation is 
> >> generated, there are no other warnings aside from those from the linker.
> >
> > https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html
> >
> > Search for "depend on"
> >
> > -> [...] estimated based on heuristics that depend on thelevel
> > argument and on optimization
> >
> > -> Because these warnings depend on optimization [...]
> >
> > Yes, warnings are dependent on optimization level.
>
> There are three such options. The first two are for format statements:
>
> > “When the exact number of bytes written by a format directive cannot be 
> > determined at compile-time it is estimated based on heuristics that depend 
> > on the level argument and on optimization. While enabling optimization will 
> > in most cases improve the accuracy of the warning, it may also result in 
> > false positives. “
>
> My read of this is that the warning occurs regardless of optimization level, 
> but it could somehow be improved by optimization.
>
> As for the last, it is for uninitialized variable reads. However, I think you 
> are misinterpreting the claim. The way that optimization level could affect 
> warning generation would be if the warning generation came after optimization 
> passes that could hide reads. That means that -O3 would prevent the warning.
>
> This is a really odd design decision by the GCC developers. With other 
> compilers, the separation between front end and backend is strong enough that 
> you will never have this sort of thing. It does not seem necessary to me 
> either. :/

I'm sorry, but you really don't know what you're talking about. I've
already told you once that you were just adding noise to this
conversation.

Re: [gentoo-dev] (Lots of) Packages up for grabs due to net-mail@ project disbanding

[Matt Turner]

On Wed, Mar 27, 2019 at 12:23 PM Michael Orlitzky  wrote:
>
> On 3/27/19 3:19 PM, Matt Turner wrote:
> >>
> >> You got it: I just pushed 17 commits, addressing ~5 open bugs. I've
> >> added you, klondike, proxy-maint, and myself as maintainers.
> >
> > Nice. I'm curious: what were you waiting on before?
> >
>
> It was pretend-maintained by net-mail, and I wasn't a member of the
> project. Most of the changes were available as part of bug 629914
> though, so it's not like I was keeping them secret.

Makes sense. I suppose this is exactly the reason we want to disband
these herd-projects.

Re: [gentoo-dev] Packages up for grabs due to samba project being disbanded

[Matt Turner]

On Wed, Mar 27, 2019 at 10:04 AM Michał Górny  wrote:
> The samba project will most likely be disbanded shortly.  While
> the current project members may stay as fallback maintainers,
> the following packages (being part of the Samba stack) would really use
> new, dedicated maintainers:

I understand disbanding projects when they're really just the old
"herd" concept, but this actually looks like a coherent set of
packages that a project should maintain. I don't see a bug about
disbanding samba. What's the rationale?

Re: [gentoo-dev] (Lots of) Packages up for grabs due to net-mail@ project disbanding

[Matt Turner]

On Wed, Mar 27, 2019 at 10:28 AM Michael Orlitzky  wrote:
>
> On 3/26/19 5:09 PM, Ralph Seichter wrote:
> > * Michael Orlitzky:
> >
> >> I'd be happy to work on all of that stuff either before or after you
> >> guys take over and get settled in.
> >
> > I'd appreciate you adding all improvements you already have in store.
> > It would be a shame to waste the work you have already done.
> >
>
> You got it: I just pushed 17 commits, addressing ~5 open bugs. I've
> added you, klondike, proxy-maint, and myself as maintainers.

Nice. I'm curious: what were you waiting on before?

Re: [gentoo-dev] Packages up for grabs due to samba project being disbanded

[Matt Turner]

On Wed, Mar 27, 2019 at 1:26 PM Michał Górny  wrote:
>
> On Wed, 2019-03-27 at 12:18 -0700, Matt Turner wrote:
> > On Wed, Mar 27, 2019 at 10:04 AM Michał Górny  wrote:
> > > The samba project will most likely be disbanded shortly.  While
> > > the current project members may stay as fallback maintainers,
> > > the following packages (being part of the Samba stack) would really use
> > > new, dedicated maintainers:

What are you basing that on? I see Lars bumping
Samba/talloc/tdb/tevent consistently. (Those are the only ones I
checked)

Re: [gentoo-dev] Fwd: [gentoo-commits] repo/gentoo:master commit in: dev-libs/elfutils/

[Matt Turner]

On Sat, Apr 6, 2019 at 8:31 AM Andreas K. Huettel  wrote:
>
> Public service announcement: Calling for stabilization requires maintainer
> acknowledgment.
>
> While there may be parts of Gentoo where this requirement is seen a bit more
> loosely, it is definitely true for TOOLCHAIN and BASE-SYSTEM.

Just want to emphasize: this isn't a complaint about toe-stepping.
This version actually cannot be stabilized yet because it will cause
kernels to fail to build.

Re: [gentoo-dev] [PATCH 2/3] xorg-2.eclass: Remove use of prune_libtool_files

[Matt Turner]

On Fri, Feb 22, 2019 at 8:30 PM desultory  wrote:
>
> On 02/20/19 02:36, Michał Górny wrote:
> > On Wed, 2019-02-20 at 07:20 +0100, Ulrich Mueller wrote:
> >>>>>>> On Wed, 20 Feb 2019, Matt Turner wrote:
> >>
> >>
> >>> # Don't install libtool archives (even for modules)
> >>> -   prune_libtool_files --all
> >>> +   find "${D}" -name '*.la' -delete || die
> >>
> >> Maybe restrict removal to regular files, i.e. add "-type f"?
> >
> > I suppose you should have spoken up when people started adopting that
> > 'find' line all over the place.  Though I honestly doubt we're going to
> > see many packages installing '*.la' non-files.
> >
> Just so we are all clear here: your argument is that more fully correct
> approaches should not be considered in the present and future because
> less fully correct approaches were implemented in the past? And,
> further, that since nothing matching a specific pattern happens to come
> to your mind at he moment, such things do not exist? Perhaps dialing
> back the rhetoric from 11 and considering feedback as an opportunity to
> improve existing code is called for in this case, among others.

I think you might be reading more into this than was intended.

I read his email as lamenting that the horse has left the barn, so to
speak. There are already hundreds of uses of find -name '*.la' -delete
without -type f in the tree, probably in large part because
ltprune.eclass suggests the form without it.

Suggesting dialing down the rhetoric when it appears that you have
overreacted is a bit humorous.

[gentoo-dev] Last rites: some old X11 packages

[Matt Turner]

# Matt Turner  (02 Mar 2019)
# Old, unused drivers.
# Masked for removal in 30 days. Bug #679256
x11-drivers/xf86-input-elographics
x11-drivers/xf86-video-newport
x11-drivers/xf86-video-tdfx
x11-drivers/xf86-video-voodoo

# Matt Turner  (02 Mar 2019)
# No reverse dependencies. No releases in 13 years.
# Masked for removal in 30 days. Bug #679256
x11-libs/libxkbui


signature.asc
Description: PGP signature

[gentoo-dev] [PATCH] xorg-3.eclass: Copy from xorg-2.eclass and add EAPI 7 support

[Matt Turner]

Nearly all the work is just removing uses of autotools-multilib and
autotools-utils.

Bug: https://bugs.gentoo.org/619832
Signed-off-by: Matt Turner 
---
Let's just make an xorg-3 eclass to avoid any possibility of breaking
stable things.

Points of concern:

1)  The fonts code is dead code as a result of fonts.eclass only
supporting EAPI=6. None of the fonts ebuilds have changed since
the transition to git, so we might just drop that code from
xorg-3 and perhaps ultimately rename xorg-2 to xorg-fonts or
something when all other ebuilds have transitioned?

2)  Suggestions welcome for solving https://bugs.gentoo.org/637898
I have no ideas...

3)  Meson support? This eclass is pretty autotools focused. Can we
somehow allow Meson support without too much hassle? Maybe it's
not worth it, since I'm not aware of any X11 projects other than
the Xserver to have Meson build systems. I'm happy to punt.

 eclass/xorg-3.eclass | 583 +++
 1 file changed, 583 insertions(+)
 create mode 100644 eclass/xorg-3.eclass

diff --git a/eclass/xorg-3.eclass b/eclass/xorg-3.eclass
new file mode 100644
index 000..fd045122013
--- /dev/null
+++ b/eclass/xorg-3.eclass
@@ -0,0 +1,583 @@
+# Copyright 1999-2019 Gentoo Authors
+# Distributed under the terms of the GNU General Public License v2
+
+# @ECLASS: xorg-3.eclass
+# @MAINTAINER:
+# x...@gentoo.org
+# @AUTHOR:
+# Author: Tomáš Chvátal 
+# Author: Donnie Berkholz 
+# Author: Matt Turner 
+# @SUPPORTED_EAPIS: 7
+# @BLURB: Reduces code duplication in the modularized X11 ebuilds.
+# @DESCRIPTION:
+# This eclass makes trivial X ebuilds possible for apps, fonts, drivers,
+# and more. Many things that would normally be done in various functions
+# can be accessed by setting variables instead, such as patching,
+# running eautoreconf, passing options to configure and installing docs.
+#
+# All you need to do in a basic ebuild is inherit this eclass and set
+# DESCRIPTION, KEYWORDS and RDEPEND/DEPEND. If your package is hosted
+# with the other X packages, you don't need to set SRC_URI. Pretty much
+# everything else should be automatic.
+
+GIT_ECLASS=""
+if [[ ${PV} == ** ]]; then
+   GIT_ECLASS="git-r3"
+   XORG_EAUTORECONF="yes"
+fi
+
+# If we're a font package, but not the font.alias one
+FONT_ECLASS=""
+if [[ ${PN} == font* \
+   && ${CATEGORY} = media-fonts \
+   && ${PN} != font-alias \
+   && ${PN} != font-util ]]; then
+   # Activate font code in the rest of the eclass
+   FONT="yes"
+   FONT_ECLASS="font"
+fi
+
+# @ECLASS-VARIABLE: XORG_MULTILIB
+# @DESCRIPTION:
+# If set to 'yes', the multilib support for package will be enabled. Set
+# before inheriting this eclass.
+: ${XORG_MULTILIB:="no"}
+
+# we need to inherit autotools first to get the deps
+inherit autotools eutils libtool multilib toolchain-funcs \
+   flag-o-matic ${FONT_ECLASS} ${GIT_ECLASS}
+
+if [[ ${XORG_MULTILIB} == yes ]]; then
+   inherit multilib-minimal
+fi
+
+EXPORTED_FUNCTIONS="src_prepare src_configure src_unpack src_compile 
src_install pkg_postinst pkg_postrm"
+case "${EAPI:-0}" in
+   7) ;;
+   *) die "EAPI=${EAPI} is not supported" ;;
+esac
+
+# exports must be ALWAYS after inherit
+EXPORT_FUNCTIONS ${EXPORTED_FUNCTIONS}
+
+IUSE=""
+HOMEPAGE="https://www.x.org/wiki/ https://cgit.freedesktop.org/;
+
+# @ECLASS-VARIABLE: XORG_EAUTORECONF
+# @DESCRIPTION:
+# If set to 'yes' and configure.ac exists, eautoreconf will run. Set
+# before inheriting this eclass.
+: ${XORG_EAUTORECONF:="no"}
+
+# @ECLASS-VARIABLE: XORG_BASE_INDIVIDUAL_URI
+# @DESCRIPTION:
+# Set up SRC_URI for individual modular releases. If set to an empty
+# string, no SRC_URI will be provided by the eclass.
+: ${XORG_BASE_INDIVIDUAL_URI="https://www.x.org/releases/individual"}
+
+# @ECLASS-VARIABLE: XORG_MODULE
+# @DESCRIPTION:
+# The subdirectory to download source from. Possible settings are app,
+# doc, data, util, driver, font, lib, proto, xserver. Set above the
+# inherit to override the default autoconfigured module.
+if [[ -z ${XORG_MODULE} ]]; then
+   case ${CATEGORY} in
+   app-doc) XORG_MODULE=doc/ ;;
+   media-fonts) XORG_MODULE=font/;;
+   x11-apps|x11-wm) XORG_MODULE=app/ ;;
+   x11-misc|x11-themes) XORG_MODULE=util/;;
+   x11-base)XORG_MODULE=xserver/ ;;
+   x11-drivers) XORG_MODULE=driver/  ;;
+   x11-libs)XORG_MODULE=lib/ ;;
+   *)   XORG_MODULE= ;;
+   esac
+fi
+
+# @ECLASS-VARIABLE: XORG_PACKAGE_NAME
+# @DESCRIPTION:
+# For git checkout the git repository might differ from package name.
+# Th

Re: [gentoo-dev] [PATCH 3/3] xorg-2.eclass: Add EAPI=7 support

[Matt Turner]

On Sun, Feb 24, 2019 at 4:44 AM Matija Skala  wrote:
>
> Dne sreda, 20. februar 2019 ob 05:45:41 CET je Matt Turner napisal:
> > + default
> >   xorg-2_reconf_source
> > - autotools-utils_src_prepare "$@"
> > +
> > + [[ ${PATCHES} ]] && epatch "${PATCHES[@]}"
> >  }
> >
>
> On EAPI=7, this code would apply ${PATCHES} twice.

Thank you! Removed.

Re: [gentoo-dev] Last rites: some old X11 packages

[Matt Turner]

On Sun, Mar 3, 2019 at 1:09 AM Joshua Kinard  wrote:
>
> On 3/2/2019 13:46, Matt Turner wrote:
> > # Matt Turner  (02 Mar 2019)
> > # Old, unused drivers.
> > # Masked for removal in 30 days. Bug #679256
>
> > x11-drivers/xf86-video-newport
>
> This is for the SGI Indy's newport graphics board.  Does it not build with
> modern Xorg or anything, or not maintained upstream?  My Indy is dead due to
> a bad RTC, so I can't test it for the foreseeable future.

Yes, it no longer builds and it requires packed 24-bit color support
which has been removed from the xserver.

We would have to package an old xserver for -newport to be useful
(which is something I'd be interested to do with sufficient time).

Re: [gentoo-dev] [PATCH 2/3] xorg-2.eclass: Remove use of prune_libtool_files

[Matt Turner]

On Sat, Mar 2, 2019 at 3:41 PM Mike Gilbert  wrote:
>
> On Sat, Mar 2, 2019 at 5:10 PM Michał Górny  wrote:
> >
> > On Sat, 2019-03-02 at 16:59 -0500, Mike Gilbert wrote:
> > > On Mon, Feb 25, 2019 at 1:37 AM Ulrich Mueller  wrote:
> > > > > > > > > On Wed, 20 Feb 2019, Michał Górny wrote:
> > > > > On Wed, 2019-02-20 at 07:20 +0100, Ulrich Mueller wrote:
> > > > > > > > > > > On Wed, 20 Feb 2019, Matt Turner wrote:
> > > > > > ># Don't install libtool archives (even for modules)
> > > > > > > -  prune_libtool_files --all
> > > > > > > +  find "${D}" -name '*.la' -delete || die
> > > > > >
> > > > > > Maybe restrict removal to regular files, i.e. add "-type f"?
> > > > > I suppose you should have spoken up when people started adopting that
> > > > > 'find' line all over the place.  Though I honestly doubt we're going
> > > > > to see many packages installing '*.la' non-files.
> > > >
> > > > I have updated the example in ltprune.eclass now.
> > > >
> > > > That still won't catch regular non-libtool files, but people needing
> > > > additional sanity checks can still use the eclass.
> > >
> > > Perhaps we should un-ban the ltprune eclass for EAPI 7?
> > >
> > > It seems like it would still be useful to have a way of detecting
> > > libtool-archives instead of removing any file that ends with ".la".
> > >
> >
> > How many valid cases for this are there?  For comparison, how many
> > useless complexity will be added to ebuilds by thoughtless maintainers
> > using the first thing that seems to work without actually verifying
> > whether it is necessary?
>
> As a maintainer, any time spent worrying about .la files is wasted
> time. We have code that can figure it out automatically and allow me
> to stop wasting brain power.

Exactly.

Re: Re[2]: [gentoo-dev] Last rites: sys-boot/raspberrypi-firmware

[Matt Turner]

On Fri, Mar 15, 2019 at 2:55 PM Conrad Kostecki  wrote:
>
> Hi!
>
> Am 15.03.2019 20:29:11, "Matt Turner"  schrieb:
>
> On Fri, Mar 15, 2019 at 7:04 AM Conrad Kostecki  wrote:
>
>
>
> Do you know something about media-libs/raspberrypi-userland as well?
> I'm hoping to enable libglvnd support in media-libs/mesa and
> x11-drivers/nvidia-drivers soon, and this is the only other package in
> Gentoo that uses app-eselect/eselect-opengl.
>
> Do we care to keep this now that Mesa's vc4 driver is in good shape?
>
> At least, I've somewhere my modified  release, which I've fixed for 
> myself, since there were some bugs and added eselect-opengl support to this. 
> What do you mean exactly with libglvnd or at what do you want to know?

libglvnd is the "GL Vendor-Neutral Dispatch library" [0]. It provides
libGL, libGLESv1_CM, libGLESv2, etc, and then dispatches those calls
to the underlying hardware driver. This allows a single libGL.so to
work for Mesa and nvidia-drivers for example. If
media-libs/raspberrypi-userland doesn't support libglvnd (which it
doesn't as far as I can tell) that kind of throws a wrench in the plan
for IMO minimal benefit.

[0] https://github.com/NVIDIA/libglvnd

Re: [gentoo-dev] Last rites: sys-boot/raspberrypi-firmware

[Matt Turner]

On Fri, Mar 15, 2019 at 6:16 PM Chí-Thanh Christopher Nguyễn
 wrote:
>
> Matt Turner schrieb:
> >> Do you know something about media-libs/raspberrypi-userland as well?
> >> I'm hoping to enable libglvnd support in media-libs/mesa and
> >> x11-drivers/nvidia-drivers soon, and this is the only other package in
> >> Gentoo that uses app-eselect/eselect-opengl.
> >>
> >> Do we care to keep this now that Mesa's vc4 driver is in good shape?
>
> There are uses for raspberrypi-userland which the vc4 driver (last I checked
> at least) does not cover very well.
>
> The most important one is support for the 256 MB RAM devices (original RPi
> Model B), which works fine on raspberrypi-userland. vc4 still has issues if
> less than 256 MB RAM are allocated to the GPU.

That sounds like an awful device to run Gentoo on.

I'd like to require libglvnd for all libGL providers and get rid of
app-eselect/eselect-opengl. What do you suggest we do about
raspberrypi-userland?

Re: [gentoo-dev] Last Rites: sys-fs/cryptmount

[Matt Turner]

On Thu, Mar 7, 2019 at 2:33 AM Conrad Kostecki  wrote:
>
> Hi Matt,
>
> > Matt Turner  hat am 7. März 2019 um 06:34 geschrieben:
> > # Matt Turner  (06 Mar 2019)
> > # Does not build with glibc >= 2.25 (stabilized a year ago). Unmaintained by
> > # maintainer-by-proxy: Bugs #628734 and #641176
> > # Removal in 30 days
> > sys-fs/cryptmount
>
> I've submitted a PR for a version bump, which should fix all those bugs.

Thank you, and thank you for taking maintainership as well!

[gentoo-dev] Last Rites: sys-fs/cryptmount

[Matt Turner]

Frankly, I think this is a good example of why we shouldn't allow
maintainer-by-proxy for random people without a track record of
contributions. Especially when they want to *add* a package to the tree.

# Matt Turner  (06 Mar 2019)
# Does not build with glibc >= 2.25 (stabilized a year ago). Unmaintained by
# maintainer-by-proxy: Bugs #628734 and #641176
# Removal in 30 days
sys-fs/cryptmount


signature.asc
Description: PGP signature

Re: [gentoo-dev] Last rites: sys-boot/raspberrypi-firmware

[Matt Turner]

On Fri, Mar 15, 2019 at 7:04 AM Conrad Kostecki  wrote:
> > # Michael Weber  (17 Jul 2013)
> > # Upstream next versions
> > # Michał Górny  (15 Mar 2019)
> > # No single unmasked version since.  Removal in 30 days.  Bug #671238.
> > >=sys-boot/raspberrypi-firmware-1_pre
>
> Could we keep this package? I can take it, and make a proper release, if that 
> would be enough to keep this package? I am using this on my gentoo with my 
> Rpi3.

Do you know something about media-libs/raspberrypi-userland as well?
I'm hoping to enable libglvnd support in media-libs/mesa and
x11-drivers/nvidia-drivers soon, and this is the only other package in
Gentoo that uses app-eselect/eselect-opengl.

Do we care to keep this now that Mesa's vc4 driver is in good shape?

Re: [gentoo-dev] Last rites: sys-boot/raspberrypi-firmware

[Matt Turner]

On Fri, Mar 15, 2019 at 12:29 PM Matt Turner  wrote:
>
> On Fri, Mar 15, 2019 at 7:04 AM Conrad Kostecki  wrote:
> > > # Michael Weber  (17 Jul 2013)
> > > # Upstream next versions
> > > # Michał Górny  (15 Mar 2019)
> > > # No single unmasked version since.  Removal in 30 days.  Bug #671238.
> > > >=sys-boot/raspberrypi-firmware-1_pre
> >
> > Could we keep this package? I can take it, and make a proper release, if 
> > that would be enough to keep this package? I am using this on my gentoo 
> > with my Rpi3.
>
> Do you know something about media-libs/raspberrypi-userland as well?
> I'm hoping to enable libglvnd support in media-libs/mesa and
> x11-drivers/nvidia-drivers soon, and this is the only other package in
> Gentoo that uses app-eselect/eselect-opengl.
>
> Do we care to keep this now that Mesa's vc4 driver is in good shape?

Using correct email address for chithanh this time.

Re: [gentoo-dev] wayland category

[Matt Turner]

On Sat, Feb 9, 2019 at 2:26 AM Mart Raudsepp  wrote:
>
> Ühel kenal päeval, R, 08.02.2019 kell 16:44, kirjutas Matthew Thode:
> > wayland, weston, sway{,lock,idle}, wl-clipboard, etc would be the
> > start,
> > I'm sure there are a ton I'm missing but I don't know where to put
> > things like wl-clipboard, dev-libs doesn't seem right.
>
>
> Another problem are many of the toolkits and GUI libraries; many either
> support wayland and X11 and more, or are really agnostic to it (but
> deal with GUI stuff on top of GTK or other stuff), but historically we
> have them in x11-libs/. As-is, they'd be better off in dev-libs/, but
> really a new gui-libs/ seems better to me.
> Maybe the pure-wayland stuff could be in some sort of gui-* category
> too.

Agreed. gui-*/ seems like the best plan.

[gentoo-dev] [PATCH 2/3] xorg-2.eclass: Remove use of prune_libtool_files

[Matt Turner]

---
 eclass/xorg-2.eclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/eclass/xorg-2.eclass b/eclass/xorg-2.eclass
index 7133aa365f1..74660e7f213 100644
--- a/eclass/xorg-2.eclass
+++ b/eclass/xorg-2.eclass
@@ -500,7 +500,7 @@ xorg-2_src_install() {
fi
 
# Don't install libtool archives (even for modules)
-   prune_libtool_files --all
+   find "${D}" -name '*.la' -delete || die
 
[[ -n ${FONT} ]] && remove_font_metadata
 }
-- 
2.19.2

Re: [gentoo-dev] [PATCH 3/3] xorg-2.eclass: Add EAPI=7 support

[Matt Turner]

On Tue, Feb 19, 2019 at 10:24 PM Ulrich Mueller  wrote:
>
> >>>>> On Wed, 20 Feb 2019, Matt Turner wrote:
>
> > Nearly all the work is just removing uses of autotools-multilib and
> > autotools-utils. The new code should work in EAPI 4 and 5. Don't add
> > support for EAPI 6; that ship has already sailed.
>
> AFAICS, adding EAPI 6 support wouldn't require any additional code?

I think that is true. (I have no strong preference on whether to add
EAPI 6 support. I just figured that anything that gets an EAPI bump
now should go to the latest available)

Re: [gentoo-dev] [PATCH 2/3] xorg-2.eclass: Remove use of prune_libtool_files

[Matt Turner]

On Tue, Feb 19, 2019 at 10:21 PM Ulrich Mueller  wrote:
>
> >>>>> On Wed, 20 Feb 2019, Matt Turner wrote:
>
> >   # Don't install libtool archives (even for modules)
> > - prune_libtool_files --all
> > + find "${D}" -name '*.la' -delete || die
>
> Maybe restrict removal to regular files, i.e. add "-type f"?

Is that ever a problem? The 'find ...' that I replaced
prune_libtool_files is a verbatim copy of what ltprune.eclass says to
use instead:

# Discouraged. Whenever possible, please use much simpler:
# @CODE
# find "${D}" -name '*.la' -delete || die
# @CODE

grepping the repo, I think a strong case can be made in favor of
ltprune.eclass given the wide variety of ways this is open coded...

[gentoo-dev] [PATCH 3/3] xorg-2.eclass: Add EAPI=7 support

[Matt Turner]

Nearly all the work is just removing uses of autotools-multilib and
autotools-utils. The new code should work in EAPI 4 and 5. Don't add
support for EAPI 6; that ship has already sailed.
---
There are a number of trivial x11 bumps coming up, so I figured I'd try
to finally add EAPI=7 support to xorg-2.eclass. This is lightly tested,
and I don't feel like an expert at this, so any review and feedback is
appreciated.

I find the if-multilib ... fi blocks a little odd. Is there a better way
to do that?

 eclass/xorg-2.eclass | 80 ++--
 1 file changed, 48 insertions(+), 32 deletions(-)

diff --git a/eclass/xorg-2.eclass b/eclass/xorg-2.eclass
index 74660e7f213..eb2aa1594b4 100644
--- a/eclass/xorg-2.eclass
+++ b/eclass/xorg-2.eclass
@@ -1,4 +1,4 @@
-# Copyright 1999-2017 Gentoo Foundation
+# Copyright 1999-2019 Gentoo Authors
 # Distributed under the terms of the GNU General Public License v2
 
 # @ECLASS: xorg-2.eclass
@@ -7,7 +7,7 @@
 # @AUTHOR:
 # Author: Tomáš Chvátal 
 # Author: Donnie Berkholz 
-# @SUPPORTED_EAPIS: 4 5
+# @SUPPORTED_EAPIS: 4 5 7
 # @BLURB: Reduces code duplication in the modularized X11 ebuilds.
 # @DESCRIPTION:
 # This eclass makes trivial X ebuilds possible for apps, fonts, drivers,
@@ -44,16 +44,16 @@ fi
 : ${XORG_MULTILIB:="no"}
 
 # we need to inherit autotools first to get the deps
-inherit autotools autotools-utils eutils libtool multilib toolchain-funcs \
+inherit autotools eutils libtool multilib toolchain-funcs \
flag-o-matic ${FONT_ECLASS} ${GIT_ECLASS}
 
 if [[ ${XORG_MULTILIB} == yes ]]; then
-   inherit autotools-multilib
+   inherit multilib-minimal
 fi
 
-EXPORTED_FUNCTIONS="src_unpack src_compile src_install pkg_postinst pkg_postrm"
+EXPORTED_FUNCTIONS="src_prepare src_configure src_unpack src_compile 
src_install pkg_postinst pkg_postrm"
 case "${EAPI:-0}" in
-   4|5) EXPORTED_FUNCTIONS="${EXPORTED_FUNCTIONS} src_prepare 
src_configure" ;;
+   4|5|7) ;;
*) die "EAPI=${EAPI} is not supported" ;;
 esac
 
@@ -129,7 +129,16 @@ for arch in ${XORG_EAUTORECONF_ARCHES}; do
EAUTORECONF_DEPENDS+=" ${arch}? ( ${EAUTORECONF_DEPEND} )"
 done
 DEPEND+=" ${EAUTORECONF_DEPENDS}"
-[[ ${XORG_EAUTORECONF} != no ]] && DEPEND+=" ${EAUTORECONF_DEPEND}"
+if [[ ${XORG_EAUTORECONF} != no ]] ; then
+   case "${EAPI:-0}" in
+   4|5)
+   DEPEND+=" ${EAUTORECONF_DEPEND}"
+   ;;
+   7)
+   BDEPEND+=" ${EAUTORECONF_DEPEND}"
+   ;;
+   esac
+fi
 unset EAUTORECONF_DEPENDS
 unset EAUTORECONF_DEPEND
 
@@ -311,20 +320,6 @@ xorg-2_src_unpack() {
[[ -n ${FONT_OPTIONS} ]] && einfo "Detected font directory: ${FONT_DIR}"
 }
 
-# @FUNCTION: xorg-2_patch_source
-# @DESCRIPTION:
-# Apply all patches
-xorg-2_patch_source() {
-   debug-print-function ${FUNCNAME} "$@"
-
-   # Use standardized names and locations with bulk patching
-   # Patch directory is ${WORKDIR}/patch
-   # See epatch() in eutils.eclass for more documentation
-   EPATCH_SUFFIX=${EPATCH_SUFFIX:=patch}
-
-   [[ -d "${EPATCH_SOURCE}" ]] && epatch
-}
-
 # @FUNCTION: xorg-2_reconf_source
 # @DESCRIPTION:
 # Run eautoreconf if necessary, and run elibtoolize.
@@ -335,14 +330,17 @@ xorg-2_reconf_source() {
*-aix* | *-winnt*)
# some hosts need full eautoreconf
[[ -e "./configure.ac" || -e "./configure.in" ]] \
-   && AUTOTOOLS_AUTORECONF=1
+   && XORG_EAUTORECONF=yes
;;
*)
# elibtoolize required for BSD
[[ ${XORG_EAUTORECONF} != no && ( -e "./configure.ac" 
|| -e "./configure.in" ) ]] \
-   && AUTOTOOLS_AUTORECONF=1
+   && XORG_EAUTORECONF=yes
;;
esac
+
+   [[ ${XORG_EAUTORECONF} != no ]] && eautoreconf
+   elibtoolize --patch-only
 }
 
 # @FUNCTION: xorg-2_src_prepare
@@ -351,9 +349,10 @@ xorg-2_reconf_source() {
 xorg-2_src_prepare() {
debug-print-function ${FUNCNAME} "$@"
 
-   xorg-2_patch_source
+   default
xorg-2_reconf_source
-   autotools-utils_src_prepare "$@"
+
+   [[ ${PATCHES} ]] && epatch "${PATCHES[@]}"
 }
 
 # @FUNCTION: xorg-2_font_configure
@@ -447,17 +446,28 @@ xorg-2_src_configure() {
local selective_werror="--disable-selective-werror"
fi
 
-   local myeconfargs=(
+   local econfargs=(
${dep_track}
${selective_werror}
${FONT_OPTIONS}
"${xorgconfadd[@]}"
)
 
+   # Handle static-libs found in IUSE, disable them by default
+   if in_iuse static-libs; then
+   econfargs+=(
+   --enable-shared
+   $(use_enable static-libs static)

[gentoo-dev] [PATCH 1/3] xorg-2.eclass: Drop support for EAPI 3

[Matt Turner]

No ebuilds inheriting xorg-2 are EAPI=3.
---
 eclass/xorg-2.eclass | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/eclass/xorg-2.eclass b/eclass/xorg-2.eclass
index 4ed65e676a0..7133aa365f1 100644
--- a/eclass/xorg-2.eclass
+++ b/eclass/xorg-2.eclass
@@ -7,7 +7,7 @@
 # @AUTHOR:
 # Author: Tomáš Chvátal 
 # Author: Donnie Berkholz 
-# @SUPPORTED_EAPIS: 3 4 5
+# @SUPPORTED_EAPIS: 4 5
 # @BLURB: Reduces code duplication in the modularized X11 ebuilds.
 # @DESCRIPTION:
 # This eclass makes trivial X ebuilds possible for apps, fonts, drivers,
@@ -53,7 +53,7 @@ fi
 
 EXPORTED_FUNCTIONS="src_unpack src_compile src_install pkg_postinst pkg_postrm"
 case "${EAPI:-0}" in
-   3|4|5) EXPORTED_FUNCTIONS="${EXPORTED_FUNCTIONS} src_prepare 
src_configure" ;;
+   4|5) EXPORTED_FUNCTIONS="${EXPORTED_FUNCTIONS} src_prepare 
src_configure" ;;
*) die "EAPI=${EAPI} is not supported" ;;
 esac
 
@@ -271,7 +271,7 @@ fi
 
 if [[ ${XORG_MODULE_REBUILD} == yes ]]; then
case ${EAPI} in
-   3|4)
+   4)
;;
*)
RDEPEND+=" x11-base/xorg-server:="
@@ -530,7 +530,7 @@ xorg-2_pkg_postrm() {
 
if [[ -n ${FONT} ]]; then
# if we're doing an upgrade, postinst will do
-   if [[ ${EAPI} -lt 4 || -z ${REPLACED_BY_VERSION} ]]; then
+   if [[ -z ${REPLACED_BY_VERSION} ]]; then
create_fonts_scale
create_fonts_dir
font_pkg_postrm "$@"
-- 
2.19.2

[gentoo-dev] Re: EAPI 2 must die

[Matt Turner]

On Wed, Jun 5, 2019 at 11:39 PM Agostino Sarubbo  wrote:
>
> On giovedì 6 giugno 2019 08:25:54 CEST Luca Barbato wrote:
> > Anybody has hardware to test it?
>
> I can do it on timberdoodle.

The issue is that the package is for "OldWorld" Macs (like 20+ years
old). We recently dropped the bootloader, sys-boot/quik, so I think
we'd be fine to drop sys-apps/powerpc-utils as well.

Re: [gentoo-dev] Rethinking multilib flags in Gentoo

[Matt Turner]

On Wed, May 8, 2019 at 3:19 AM Alexis Ballier  wrote:
>
> On Wed, 08 May 2019 12:01:21 +0200
> Michał Górny  wrote:
>
> > On Wed, 2019-05-08 at 11:54 +0200, Alexis Ballier wrote:
> > > On Wed, 08 May 2019 11:41:41 +0200
> > > Michał Górny  wrote:
> > >
> > > > > There's multilib that adds a lot of flags with a single eclass
> > > > > change, but I'd guess the number of packages and flags is
> > > > > constantly growing, so sooner or later you'll be hit by this
> > > > > again and no multilib killing will help you then.
> > > > >
> > > > > I think it is more future proof to use the addition of multilib
> > > > > flags to fix pkgcheck rather than actively reducing the number
> > > > > of multilib flags to cope with its limitations.
> > > >
> > > > Then please do it, by all means.  The reality is simple.  If the
> > > > tool is broken, you either fix it or stop doing what you know
> > > > that breaks it. Being unable to do the former, and having no good
> > > > replacement, I'd go for the latter.
> > >
> > > Well, why is it slow ? IO ? CPU ? Did you collect profiling data ?
> >
> > CPU definitely.  More detail than that, I don't and I don't have time
> > to investigate.
>
> So you don't have time to change 3 lines to add cProfile but do have
> time to send various emails and rework the entire multilib system ?
> weird.

This isn't productive.

If you'd like to do the work you're suggesting, I'm sure Michał will
support that, but as is you're just passive-aggressively questioning
his choices in the regards to the multilib system he created and the
CI system he created.

[gentoo-dev] Re: Rethinking multilib flags in Gentoo

[Matt Turner]

On Tue, May 7, 2019 at 2:47 PM Michał Górny  wrote:
> On the other hand, if I am consider the benefit of having large number
> of flags that will never benefit the majority of users (if anyone)
> vs. having much faster CI (= being able to run it more frequently,
> and therefore report problems faster), you can guess which way I prefer.

Does mips' multilib support affect CI since all the profiles are 'exp'?

Presumably it's something we'd have to think a lot about if we ever
wanted to promote the mips profiles...

[gentoo-dev] Re: Proposed last rites for sci-chemistry/coot and a bunch of reverse dependencies

[Matt Turner]

Thanks. Done, except for x11-libs/guile-gtk which is still a
dependency of the current stable sci-electronics/gwave.

Bug: https://bugs.gentoo.org/639760

Re: [gentoo-dev] [PATCH] CPU_FLAGS_X86: add global 'f16c' flag

[Matt Turner]

Both this and the avx512f change look good to me.

Re: [gentoo-dev] Retirement / packages up for grabs

[Matt Turner]

On Mon, Apr 8, 2019 at 8:51 PM Austin English  wrote:
>
> Howdy all,
>
> I haven't had much time for Gentoo lately, so I'm turning in my keys.
> It's been a great learning experience, and I hope my contributions were
> helpful. Best of luck on your future endeavors.

I'm sorry to see you go. Thank you for your contributions and good
luck to you in the future :)

> media-gfx/xdot

I'll take this.

[gentoo-dev] Proposed last rites for sci-chemistry/coot and a bunch of reverse dependencies

[Matt Turner]

I was investigating what needs to be done to drop guile-1.8 from the
tree (bug 590558, 587252). sci-chemistry/coot is one of the blocking
packages (bug 591410). It has a version bump request open for 18
months (bug 639760) and hasn't been maintained in as long. The new
version doesn't appear to work with guile-2.0 either, though it seems
that it may be possible to build without guile? Something for a
maintainer...

If we just drop it, we can remove the following dependencies as well:

sci-chemistry/coot (no rev deps)
sci-libs/coot-data (rev deps: sci-chemistry/coot)
sci-libs/ssm (rev deps: sci-chemistry/coot)
sci-libs/gpp4 (no rev deps)
sci-libs/cctbx (no rev deps)
sci-libs/clipper (rev deps: sci-chemistry/coot, sci-libs/cctbx)
sci-libs/libccp4 (rev deps: sci-chemistry/coot, sci-libs/{clipper,ssm}
sci-libs/monomer-db (rev deps: sci-chemistry/coot)
sci-libs/mmdb (rev deps: sci-chemistry/coot,
   sci-libs/{clipper,gpp4,libcpp4,ssm}
sci-chemistry/reduce (rev deps: sci-chemistry/coot)
dev-scheme/guile-gui (rev deps: sci-chemistry/coot; dead home page)
dev-scheme/guile-www (rev deps: sci-chemistry/coot)
dev-scheme/net-http (rev deps: sci-chemistry/coot; dead home page)
x11-libs/guile-gtk (rev deps: dev-scheme/guile-gui, dev-scheme/guile-gui)

Thoughts?

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

[Matt Turner]

On Mon, Jul 29, 2019 at 10:20 PM Michał Górny  wrote:
>
> On Tue, 2019-07-30 at 01:49 +, Matt Turner wrote:
> > commit: 6f680e4fe73925ae130343e02adb416cb799ce7d
> > Author: Chris Mayo  gmail  com>
> > AuthorDate: Fri Jul 26 18:48:13 2019 +
> > Commit: Matt Turner  gentoo  org>
> > CommitDate: Tue Jul 30 01:49:41 2019 +
> > URL:https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=6f680e4f
> >
> > virtualx.eclass: Fix no display for an emerge following a failure
> >
> > If using GNOME GDM, X is started on DISPLAY :0 but a lock file
> > /tmp/.X1024-lock is created instead of /tmp/.X0-lock.
> > virtx() will initially set XDISPLAY to 0 and attempt to start Xvfb on
> > DISPLAY :0 which fails but DISPLAY :1 (and greater) is not attempted if
> > a previous emerge left /tmp/.X1-lock behind.
> >
> > Closes: https://bugs.gentoo.org/690778
> > Signed-off-by: Chris Mayo  gmail.com>
> > Signed-off-by: Matt Turner  gentoo.org>
> >
> >  eclass/virtualx.eclass | 7 +--
> >  1 file changed, 5 insertions(+), 2 deletions(-)
> >
> > diff --git a/eclass/virtualx.eclass b/eclass/virtualx.eclass
> > index fb6a867a35c..40eeea5463b 100644
> > --- a/eclass/virtualx.eclass
> > +++ b/eclass/virtualx.eclass
> > @@ -1,4 +1,4 @@
> > -# Copyright 1999-2018 Gentoo Foundation
> > +# Copyright 1999-2019 Gentoo Authors
> >  # Distributed under the terms of the GNU General Public License v2
> >
> >  # @ECLASS: virtualx.eclass
> > @@ -178,7 +178,10 @@ virtx() {
> >   # Xvfb is started, else bump the display number
> >   #
> >   # Azarah - 5 May 2002
> > - XDISPLAY=$(i=0; while [[ -f /tmp/.X${i}-lock ]] ; do ((i++));done; 
> > echo ${i})
> > + # GNOME GDM may have started X on DISPLAY :0 with a
> > + # lock file /tmp/.X1024-lock, therefore start the search at 1.
> > + # Else a leftover /tmp/.X1-lock will prevent finding an available 
> > display.
> > + XDISPLAY=$(i=1; while [[ -f /tmp/.X${i}-lock ]] ; do ((i++));done; 
> > echo ${i})
> >   debug-print "${FUNCNAME}: XDISPLAY=${XDISPLAY}"
> >
> >   # We really do not want SANDBOX enabled here
>
> Isn't this a cheap hack that doesn't fix the underlying issue but shifts
> the problem into hopefully-won't-happen-this-time?

Yes, but given that the prior code was a cheap hack as well (from
2002, no less!) and has worked out well enough for 17 years that no
one has reported problems with it until now, I don't think it's
critical to make it bullet-proof.

Of course I'm happy to accept patches.

> Also, why are you skipping mailing list review for eclass changes?

Ah, you are right. My apologies.

[gentoo-dev] Last Rites: sci-physics/meep, sci-physics/harminv, sci-libs/libctl

[Matt Turner]

# Matt Turner  (2019-08-02)
# Unmaintained in Gentoo. Incompatible with guile-2
# Masked for removal in 30 days, Bugs #685540, #629058
sci-libs/libctl
sci-physics/harminv
sci-physics/meep


signature.asc
Description: PGP signature

[gentoo-dev] Last Rites: x11-libs/guile-gtk

[Matt Turner]

# Matt Turner  (2019-08-02)
# Unmaintained. Incompatible with guile-2
# Masked for removal in 30 days, Bugs #641864, #647536, #688244
x11-libs/guile-gtk


signature.asc
Description: PGP signature

[gentoo-dev] Last Rites: mail-filter/anubis

[Matt Turner]

# Matt Turner  (2019-08-02)
# Incompatible with guile-2. No longer a use case
# Masked for removal in 30 days, Bugs #617792
mail-filter/anubis


signature.asc
Description: PGP signature

[gentoo-dev] Last Rites: sci-mathematics/drgeo

[Matt Turner]

# Matt Turner  (2019-08-02)
# Incompatible with guile-2
# Masked for removal in 30 days, Bugs #592188
sci-mathematics/drgeo


signature.asc
Description: PGP signature

Re: [gentoo-dev] mark ppc64le profiles stable

[Matt Turner]

Looks great!

[gentoo-dev] [PATCH] xorg-3.eclass: Add XORG_TARBALL_SUFFIX

[Matt Turner]

To allow overriding the tarball type.

Signed-off-by: Matt Turner 
---
 eclass/xorg-3.eclass | 18 +-
 1 file changed, 17 insertions(+), 1 deletion(-)

diff --git a/eclass/xorg-3.eclass b/eclass/xorg-3.eclass
index f135058fba6..bd857e1cca2 100644
--- a/eclass/xorg-3.eclass
+++ b/eclass/xorg-3.eclass
@@ -89,10 +89,26 @@ fi
 
 HOMEPAGE="https://www.x.org/wiki/ 
https://gitlab.freedesktop.org/xorg/${XORG_MODULE}${XORG_PACKAGE_NAME};
 
+# @ECLASS-VARIABLE: XORG_TARBALL_SUFFIX
+# @DESCRIPTION:
+# Most X11 projects provide tarballs as tar.bz2 or tar.xz. This eclass defaults
+# to bz2.
+: ${XORG_TARBALL_SUFFIX:="bz2"}
+
+# Even though xz-utils are in @system, they must still be added to DEPEND; see
+# 
https://archives.gentoo.org/gentoo-dev/msg_a0d4833eb314d1be5d5802a3b710e0a4.xml
+if [[ ${XORG_TARBALL_SUFFIX} == "xz" ]]; then
+   if [[ ${EAPI:-0} != [0123456] ]]; then
+   BDEPEND="app-arch/xz-utils"
+   else
+   DEPEND="app-arch/xz-utils"
+   fi
+fi
+
 if [[ -n ${GIT_ECLASS} ]]; then
: 
${EGIT_REPO_URI:="https://gitlab.freedesktop.org/xorg/${XORG_MODULE}${XORG_PACKAGE_NAME}.git"}
 elif [[ -n ${XORG_BASE_INDIVIDUAL_URI} ]]; then
-   SRC_URI="${XORG_BASE_INDIVIDUAL_URI}/${XORG_MODULE}${P}.tar.bz2"
+   
SRC_URI="${XORG_BASE_INDIVIDUAL_URI}/${XORG_MODULE}${P}.tar.${XORG_TARBALL_SUFFIX}"
 fi
 
 : ${SLOT:=0}
-- 
2.21.0

Re: [gentoo-dev] [PATCH] xorg-3.eclass: Add XORG_TARBALL_SUFFIX

[Matt Turner]

On Mon, Aug 12, 2019 at 3:29 PM Ulrich Mueller  wrote:
>
> >>>>> On Tue, 13 Aug 2019, Matt Turner wrote:
>
> > +# Even though xz-utils are in @system, they must still be added to DEPEND; 
> > see
> > +# 
> > https://archives.gentoo.org/gentoo-dev/msg_a0d4833eb314d1be5d5802a3b710e0a4.xml
>
> I didn't understand that argument in 2011, and I understand it even
> less in 2019. Why would we add xz but not bzip2 and tar as dependencies?
>
> The devmanual is clear on this:
> https://devmanual.gentoo.org/general-concepts/dependencies/index.html#implicit-system-dependency

Thanks. I'm happy to drop that block. I copied the code from
gnome.org.eclass and figured that was the best thing to do to not rock
the boat.

Re: [gentoo-dev] [RFC] Moving UID/GID assignments to api.gentoo.org

[Matt Turner]

On Sat, Aug 10, 2019 at 1:49 PM William Hubbs  wrote:
>
> On Tue, Aug 06, 2019 at 11:29:50PM +0200, Michał Górny wrote:
> > Hi,
> >
> > Some time ago William asked me to move UID/GID assignments from wiki [1]
> > to something more accessible.  I've finally gotten around to draft
> > something, and I'd like to hear your comments about it.  The idea is to
> > keep a whitespace-separated record format file in api.gentoo.org repo.
> >
> > This is mostly inspired by Fedora's format, specifically the ability to
> > specify both UID and GID for matching user/group on the same line.
> > I've also decided not to attempt to specify disjoint Linux and FreeBSD
> > users/groups on a single line.  Instead, they are specified separately
> > and defined by providers (as suggested by Ulrich).
> >
> > Sample, along with big comment explaining the file format, below.
>
> I'm not sure how I feel about whitespace delimiters for this. withno
> further specification, it would make these two lines completely valid:
>
> root 0 0 baselayout
> bin 1   1   baselayout
>   some notes here

That's true, but I think with editor settings embedded in the file and
visual pattern of vertical alignment we shouldn't expect a bunch of
problems.

Michał's original proposal is very readable. Just because it's a "data
file" I don't think we should go out of our way to limit readability.

Re: [gentoo-dev] [RFC] Moving UID/GID assignments to api.gentoo.org

[Matt Turner]

On Sun, Aug 11, 2019 at 12:48 PM William Hubbs  wrote:
>
> On Sat, Aug 10, 2019 at 05:41:56PM -0700, Matt Turner wrote:
> > On Sat, Aug 10, 2019 at 1:49 PM William Hubbs  wrote:
> > >
> > > On Tue, Aug 06, 2019 at 11:29:50PM +0200, Michał Górny wrote:
> > > > Hi,
> > > >
> > > > Some time ago William asked me to move UID/GID assignments from wiki [1]
> > > > to something more accessible.  I've finally gotten around to draft
> > > > something, and I'd like to hear your comments about it.  The idea is to
> > > > keep a whitespace-separated record format file in api.gentoo.org repo.
> > > >
> > > > This is mostly inspired by Fedora's format, specifically the ability to
> > > > specify both UID and GID for matching user/group on the same line.
> > > > I've also decided not to attempt to specify disjoint Linux and FreeBSD
> > > > users/groups on a single line.  Instead, they are specified separately
> > > > and defined by providers (as suggested by Ulrich).
> > > >
> > > > Sample, along with big comment explaining the file format, below.
> > >
> > > I'm not sure how I feel about whitespace delimiters for this. withno
> > > further specification, it would make these two lines completely valid:
> > >
> > > root 0 0 baselayout
> > > bin 1   1   
> > > baselayout  some notes here
> >
> > That's true, but I think with editor settings embedded in the file and
> > visual pattern of vertical alignment we shouldn't expect a bunch of
> > problems.
>
> We don't honor editor settings in files by default, so this will not
> work out of the box (see this in /etc/vim/vimrc).
>
> --- cut here ---
> " {{{ Modeline settings
> " We don't allow modelines by default. See bug #14088 and bug #73715.
> " If you're not concerned about these, you can enable them on a per-user
> " basis by adding "set modeline" to your ~/.vimrc file.
> set nomodeline
> " }}}
> --- cut here ---
>
> If we are going to require a modeline, shouldn't we consider allowing
> them by default so we can work out of the box instead of having to tweak
> our editor settings?

Perhaps we should. Is this really an important point for you?

I don't think any of that needs to hold up Michał's proposal though.

Re: [gentoo-dev] [RFC] Moving UID/GID assignments to api.gentoo.org

[Matt Turner]

On Sun, Aug 11, 2019 at 3:54 PM William Hubbs  wrote:
>
> On Sun, Aug 11, 2019 at 03:04:02PM -0700, Matt Turner wrote:
> > On Sun, Aug 11, 2019 at 12:48 PM William Hubbs  wrote:
> > > If we are going to require a modeline, shouldn't we consider allowing
> > > them by default so we can work out of the box instead of having to tweak
> > > our editor settings?
> >
> > Perhaps we should. Is this really an important point for you?
> >
> > I don't think any of that needs to hold up Michał's proposal though.
>
> Let's move away from talking about alignment for a minute.
>
> The reason I responded originally was that his proposal is a bit
> vague. It says that whitespace separates fields; that could be spaces
> or tabs. whitespace can also be a completely valid character in
> the notes field. So, since he says we can add more fields in the future,
> you either have to escape whitespace in the notes field or quote the
> field.
>
> Also, he may have used one whitespace character to separate fields in his
> example, but the spec allows any number of whitespace characters.

Sigh.

The intention is to make it easily machine parseable and easily
readable by humans.

One or more whitespace characters is easy to recognize by a machine,
be they space or tabs. Aligned columns are easily readable by humans.
I think humans are able to follow existing convention when adding new
lines to the file and don't require specific rules like this.

There's nothing unclear or vague in his explanation. Can we please proceed?

Re: [gentoo-dev] [RFC] package.deprecated to mark packages deprecated and report dependencies

[Matt Turner]

On Fri, Aug 16, 2019 at 10:10 AM Michał Górny  wrote:
>
> Hi,
>
> leio asked me yesterday for the possibility of marking packages
> as deprecated, so that CI would issue warnings when other packages
> depend on them.  I think that's quite a good idea, so I'd like to
> propose a simple implementation for it.
>
> The idea is to provide profiles/package.deprecated using the same format
> as package.mask.  However, unlike the latter it wouldn't cause any user-
> visible results but only affect pkgcheck (and possibly repoman, if
> someone writes the check).
>
> Basically you'd put something like:
>
>   # name  (date)
>   # We don't like this package anymore, so we want to remove it ASAP.
>   dev-foo/bar
>
>   # name  (date)
>   # Old slot is not nice at all.
>   dev-bar/frobnicate:0.1
>
>   # name  (date)
>   # Nononono, don't use that.
>11.0
>
> This would cause matching packages to be marked as deprecated.  It
> wouldn't affect normal install behavior but pkgcheck/CI would complain
> if any package had a dependency that can only be satisfied
> by the deprecated packages.
>
> What do you think?

I think it's a great idea. It would have been perfect for the
x11-proto/* -> x11-base/xorg-proto transition.

[gentoo-dev] Last Rites: games-strategy/liquidwar6

[Matt Turner]

# Matt Turner  (2019-09-01)
# Depends on dev-scheme/guile:12. Unpackaged versions from 2015.
# Removal in 30 days. # Bug #654654.
games-strategy/liquidwar6


signature.asc
Description: PGP signature

Re: [gentoo-dev] Last Rites: sci-chemistry/burrow-owl and dependencies

[Matt Turner]

On Sun, Sep 1, 2019 at 1:04 PM Matt Turner  wrote:
>
> # Matt Turner  (2019-09-01)
> # dev-scheme/guile-gnome-platform depends on dev-scheme/guile:12. Its only
> # reverse dependency is sci-chemistry/burrow-owl, so include it. The others 
> are
> # dependencies of sci-chemistry/burrow-owl as well, and it is their only
> # reverse dependency.

Like with the games-strategy/liquidwar6 mask, I mistook guile:12 for
guile < 2. Should we still give last rites to these packages?

I'm inclined to keep the last rites mask in place and see if anyone
wants any of these packages.

> # Bug #693290.
> dev-libs/g-wrap
> dev-scheme/guile-cairo
> dev-scheme/guile-gnome-platform
> dev-scheme/guile-lib
> sci-chemistry/burrow-owl
> sci-libs/starparse

Re: [gentoo-dev] Last Rites: games-strategy/liquidwar6

[Matt Turner]

On Sun, Sep 1, 2019 at 1:05 PM Matt Turner  wrote:
>
> # Matt Turner  (2019-09-01)
> # Depends on dev-scheme/guile:12. Unpackaged versions from 2015.

I made a mistake here (that I corrected in commit 7ca64f844e18). The
mask now reads:

 # Matt Turner  (2019-09-01)
-# Depends on dev-scheme/guile:12. Unpackaged versions from 2015.
+# Unmaintained, unpackaged versions from 2015. Incompatible with guile-2.2.
 # Removal in 30 days. # Bug #654654.

> # Removal in 30 days. # Bug #654654.
> games-strategy/liquidwar6

[gentoo-dev] Last Rites: sci-chemistry/burrow-owl and dependencies

[Matt Turner]

# Matt Turner  (2019-09-01)
# dev-scheme/guile-gnome-platform depends on dev-scheme/guile:12. Its only
# reverse dependency is sci-chemistry/burrow-owl, so include it. The others are
# dependencies of sci-chemistry/burrow-owl as well, and it is their only
# reverse dependency.
# Bug #693290.
dev-libs/g-wrap
dev-scheme/guile-cairo
dev-scheme/guile-gnome-platform
dev-scheme/guile-lib
sci-chemistry/burrow-owl
sci-libs/starparse


signature.asc
Description: PGP signature

Re: [gentoo-dev] Home directory for the 'portage' user

[Matt Turner]

On Mon, Sep 2, 2019 at 10:05 AM Mike Gilbert  wrote:
>
> I would like to create an acct-user package for the 'portage' user,
> but I'm having trouble deciding on a home directory.
>
> baselayout currently sets it to /var/tmp/portage, and this just seems
> like a bad idea to me. I'm pretty sure we have a QA policy against
> installing files there anyway.

Agreed. Many people would like to put /var/tmp/portage on tmpfs. If
the portage user needs any persistent configuration (like an ssh key)
putting its home on tmpfs would be difficult.

Re: [gentoo-dev] [RFC] Mass last-riting of x86-but-not-amd64 packages

[Matt Turner]

On Sat, Aug 31, 2019 at 1:04 AM Michał Górny  wrote:
> sys-fs/hfsplusutils

Your script should probably check for other keywords as well. This
package is almost entirely for use on ppc/ppc64 machines. For whatever
reason it has an x86 keyword as well, so the lack of an amd64 keyword
doesn't indicate that it should be removed.

Re: [gentoo-dev] Need ARM/AArch64 test data for cpuid2cpuflags

[Matt Turner]

>From my original generation SolidRun Cubox:

$ ./hwcap-dump
hwcap:0004ead6
hwcap2:
mattst88@cubox ~/cpuid2cpuflags-7-dev $ uname -a
Linux cubox 5.2.7 #11 Wed Aug 7 17:50:03 PDT 2019 armv7l ARMv7
Processor rev 5 (v7l) Marvell Dove GNU/Linux

cpuid2cflags says
CPU_FLAGS_ARM: edsp iwmmxt thumb vfp vfpv3 v4 v5 v6 v7 thumb2

/proc/cpuinfo:

processor   : 0
model name  : ARMv7 Processor rev 5 (v7l)
BogoMIPS: 333.33
Features: half thumb fastmult vfp edsp iwmmxt thumbee vfpv3
vfpv3d16 tls idivt
CPU implementer : 0x56
CPU architecture: 7
CPU variant : 0x0
CPU part: 0x581
CPU revision: 5

Hardware: Marvell Dove
Revision: 
Serial  : 

I've got an "iwmmxt2" flag on x11-libs/pixman, but I don't think
there's a hwcap bit for it. At least not that I see in
arch/arm/include/uapi/asm/hwcap.h

That's just as well. It's only a very small optimization over iwmmxt.

Re: [gentoo-dev] [PATCH 1/2] use.desc: Make lz4 a global flag

[Matt Turner]

On Sun, Sep 15, 2019 at 7:12 AM Michał Górny  wrote:
>
> The 'lz4' flag is used consistently for the LZ4 compression algorithm
> in 23 packages.  Make it a global flag.

Good idea. Ack for both this and snappy.

Re: [gentoo-dev] [RFC] New QA policy: Packages must not disable installing manpages via USE flags

[Matt Turner]

On Sat, Jul 20, 2019 at 1:22 PM Michał Górny  wrote:
>
> On Sat, 2019-07-20 at 23:04 +0300, Andrew Savchenko wrote:
> > On Sat, 20 Jul 2019 20:28:39 +0200 Michał Górny wrote:
> > > On Sat, 2019-07-20 at 20:50 +0300, Andrew Savchenko wrote:
> > > > On Wed, 17 Jul 2019 15:25:10 +0200 Michał Górny wrote:
> > > > > Hello,
> > > > >
> > > > > The QA team would like to introduce the following policy:
> > > > >
> > > > > """
> > > > > Packages must not disable installing manpages via USE flags (e.g.
> > > > > USE=man or USE=doc).  If upstream does not ship prebuilt manpages
> > > > > and building them requires additional dependencies, the maintainer
> > > > > should build them and ship along with the package.
> > > > > """
> > > > >
> > > > >
> > > > > Explanatory note:
> > > > >
> > > > > This applies to having USE flags that specifically control building
> > > > > manpages.  It obviously does not affect:
> > > > >
> > > > > a. USE flags that disable building both a program and its manpage 
> > > > > (e.g.
> > > > > if USE=gui disables building gfrobnicate, not installing 
> > > > > gfrobnicate(1)
> > > > > is correct),
> > > > >
> > > > > b. use of LINGUAS to control installed manpages.
> > > > >
> > > > >
> > > > > Rationale:
> > > > >
> > > > > Manpages are the basic form of user documentation on Gentoo Linux.  
> > > > > Not
> > > > > installing them is harmful to our users.  On the other hand, requiring
> > > > > additional dependencies is inconvenient.  Therefore, packaging 
> > > > > prebuilt
> > > > > manpages (whenever upstream doesn't do that already) is a good
> > > > > compromise that provides user with documentation without additional
> > > > > dependencies.
> > > > >
> > > > >
> > > > > What are your comments?
> > > >
> > > > The basic foundation of Gentoo is freedom of choise for our users.
> > > > If installing man pages means no additional dependencies, than
> > > > proposed rule is ok. However if such dependencies are required it is
> > > > up to users to decide if they wan them or not.
> > > >
> > > > Having USE=man (or USE=doc) for such purposes is fine. Having
> > > > USE=man enabled by default in user profile is also fine. Forcing
> > > > users to install unnecessary dependencies on minimal systems in a
> > > > no go and turns Gentoo into something else.
> > > >
> > >
> > > Could you please read the proposed policy?  It explicitly says you are
> > > *not* supposed to force extra deps on users but build manpages for them.
> >
> > Could you please what the other developers have already replied to
> > you on this matter? This will be a significant increase in
> > maintenance burden for both developers and advanced users without
> > much to gain.
> >
>
> Yes, I get it.  User experience is not important if it would mean
> developers would actually do anything but the bare minimum to get
> from one paycheck to another.  The usual Gentoo attitude.

I don't understand your reaction, but it's very common with
predictable steps to generate it:

  1) You make a proposal
  2) People offer feedback and ask questions
  3) You respond combatively (or not at all), as if you are upset that
people perhaps are not 100% aligned with your view.

... which honestly shouldn't be at all unexpected and is precisely why
requesting comments on a proposal is valuable.

My question earlier in the thread is relevant and still unaddressed.

Re: [gentoo-dev] [RFC] New QA policy: Packages must not disable installing manpages via USE flags

[Matt Turner]

On Wed, Jul 17, 2019 at 6:25 AM Michał Górny  wrote:
>
> Hello,
>
> The QA team would like to introduce the following policy:
>
> """
> Packages must not disable installing manpages via USE flags (e.g.
> USE=man or USE=doc).

Xorg libraries use USE=doc to control the build (sometimes) and
installation of thousands of developer-documentation man pages. 99.9%
of the time users don't want the developer man pages installed.

With USE=-doc the packages still install man pages for the
applications, just not the developer documentation man pages.

Is that not reasonable?

Re: [gentoo-dev] [PATCH] CPU_FLAGS_X86: Introduce 'sha' flag

[Matt Turner]

On Thu, Jul 18, 2019 at 7:53 AM Michał Górny  wrote:
>
> Introduce 'sha' flag that corresponds to SHA-NI instruction set.
> This has two potential users, and is present in git version
> of cpuid2cpuflags (pending release once the flag is added).

Ack

Re: [gentoo-dev] Re: [RFC] Adding 'GPL-2-only', 'GPL-3-only' etc. license variants for better auditing

[Matt Turner]

On Sat, Sep 21, 2019 at 1:58 PM Ulrich Mueller  wrote:
>
> > On Sat, 21 Sep 2019, Michał Górny wrote:
>
> > I'd like to propose to employ a more systematic method of resolving this
> > problem.  I would like to add additional explicit 'GPL-n-only' licenses,
> > and discourage using short 'GPL-n' in favor of them.  The end result
> > would be three licenses per every version/variant, e.g.:
>
> >   GPL-2-only -- version 2 only
> >   GPL-2+ -- version 2 or newer
> >   GPL-2  -- might be either, audit necessary
>
> To elaborate a bit more on this: "GPL-2" already has that well defined
> meaning that your proposed "GPL-2-only" has, namely that the package is
> licensed under the GNU General Public License, version 2.

We are all aware. But the point is to explicitly put "-only" in the
LICENSE metadata so that ebuild authors are less likely to confuse
GPL-2 vs GPL-2+.

> Presumably, your change would cause a long transition time, in which we
> would have *three* variants for every GPL version (as well as LGPL,
> AGPL, FDL), two of them with identical meaning. And after the transition
> time, we would have "GPL-2-only" instead of "GPL-2", which is not only
> longer but also not accurate.

Sure, but who cares about a long transition time? We still have EAPI=0
ebuilds in tree -- and that's okay since we can quickly and easily
tell what hasn't been transitioned!

> Plus, it would result in paradoxical entries like "|| ( GPL-2-only
> GPL-3-only )" for a package that can be distributed under GPL versions 2
> or 3 but no later version.

That paradoxical entry is pretty clear to me.

> If the goal of this exercise is to do an audit of ebuilds labelled as
> "GPL-2", then a less intrusive approach (which I had already suggested
> when this issue had last been discussed) would be to add a comment to
> the LICENSE line, either saying "# GPL-2 only" for packages that have
> been verified. Or the other way aroung, starting with a comment saying
> that it is undecided, which would be removed after an audit. This would

It's not a one-time audit. Michał has a history of fixing things in
ways that does not allow the issue to return. I imagine that's what
he's doing here, and it would not surprise me at all if something
could be wired into CI to help ensure this.

> have the advantage not to confuse users, and have no impact on their
> ACCEPT_LICENSE settings. (For example, some people exclude AGPL and
> would have to add entries for AGPL-3-only.)

Trivial concern solved with a news item.

Re: [gentoo-dev] [RFC] Adding 'GPL-2-only', 'GPL-3-only' etc. license variants for better auditing

[Matt Turner]

On Sat, Sep 21, 2019 at 4:46 PM Ulrich Mueller  wrote:
>
> >>>>> On Sun, 22 Sep 2019, Matt Turner wrote:
>
> > An idea to consider: use SPDX license identifiers (see
> > https://spdx.org/licenses/)
>
> > For GPL 2 they are "GPL-2.0-only" and "GPL-2.0-or-later"
>
> Yeah, they have a history of using silly names. What does 2.0 mean?
> There is no such version of the GPL, and with Gentoo versioning rules,
> 2 is not equal to 2.0.
>
> Another funny thing is that they first introduced a "+" operator, but
> then decided not to use it for the GPL family, but append "-or-later"
> instead. (And IIUC, "GPL-2.0-only+" is valid in their scheme and
> equivalent to "GPL-2.0-or-later".)

Yes, from the page I cited it seems that they decided that
differentiating with only a '+' character was a bad idea -- the exact
thing Michał is suggesting we stop doing.

> Release 3.0 replaced previous Identifiers for GNU licenses with more explicit 
> Identifiers to reflect the "this version only" or "any later version" option 
> specific to those licenses. As such, the previously used Identifiers for 
> those licenses are deprecated as of v3.0.

Re: [gentoo-dev] [RFC] Adding 'GPL-2-only', 'GPL-3-only' etc. license variants for better auditing

[Matt Turner]

On Sat, Sep 21, 2019 at 9:57 AM Matt Turner  wrote:
>
> On Sat, Sep 21, 2019 at 9:09 AM Michał Górny  wrote:
> > TL;DR: I'd like to replace 'GPL-2' with 'GPL-2-only' etc., having
> > the former trigger QA warning asking the dev to double-check if it's
> > 'GPL-2-only' or 'GPL-2+'.
>
> I think that's a good idea.

An idea to consider: use SPDX license identifiers (see
https://spdx.org/licenses/)

For GPL 2 they are "GPL-2.0-only" and "GPL-2.0-or-later"

Re: [gentoo-dev] [RFC] Adding 'GPL-2-only', 'GPL-3-only' etc. license variants for better auditing

[Matt Turner]

On Sat, Sep 21, 2019 at 9:09 AM Michał Górny  wrote:
> TL;DR: I'd like to replace 'GPL-2' with 'GPL-2-only' etc., having
> the former trigger QA warning asking the dev to double-check if it's
> 'GPL-2-only' or 'GPL-2+'.

I think that's a good idea.

[gentoo-dev] RFC: GID/UID assignment for mosquitto (482)

[Matt Turner]

I don't see this being defined in other distros' lists, so I've
selected the highest ID available (after Bitcoin gets 483).

Re: [gentoo-dev] [RFC] Adding 'GPL-2-only', 'GPL-3-only' etc. license variants for better auditing

[Matt Turner]

On Tue, Sep 24, 2019 at 12:13 AM Ulrich Mueller  wrote:
>
> >>>>> On Tue, 24 Sep 2019, Matt Turner wrote:
>
> > Just responding because the absurdity of this angers me, to be honest.
> > See if you notice anything funny about the URL:
>
> > https://www.gnu.org/licenses/old-licenses/gpl-2.0.en.html
>
> What do you mean? Should we localise it, because translations in other
> languages exist? Sorry, but that's not going to happen.

No, I am pointing out that even the GNU project sometimes refers to
the license as GPL "2.0", which you seemed to object to SPDX doing.

Re: [gentoo-dev] stable-bot is down. Temporary? Forever? Can we have a contacts page for it?

[Matt Turner]

On Thu, Sep 26, 2019 at 12:29 AM Sergei Trofimovich  wrote:
>
> I noticed that stable-bot stopped marking bugs as verified for stbilization.
> Example:
> https://bugs.gentoo.org/695252
>
> 1. Is it gone forever and arch teams should stop relying on it's presence?
> 2. If not can the owner tweak it?
> 3. Can we have a wiki page that describes the setup and who to send reports 
> to?
>Doc would be useful to run it locally, send bugs/enhancements, post current
>status if it's known to be broken.
>

It looks like it is working now, but I think we really should know a few things:

   (1) Who maintains it
   (2) Where the code is
   (3) and perhaps what happened to bring it down

It's a pretty important piece of infrastructure that we've come to
rely on, so it should be treated as such.

Re: [gentoo-dev] Re: [RFC] Adding 'GPL-2-only', 'GPL-3-only' etc. license variants for better auditing

[Matt Turner]

On Mon, Sep 23, 2019 at 6:42 PM Jason Zaman  wrote:
>
> On Sat, Sep 21, 2019 at 09:17:53PM +0200, Ulrich Mueller wrote:
> > > On Sat, 21 Sep 2019, Michał Górny wrote:
> >
> > > TL;DR: I'd like to replace 'GPL-2' with 'GPL-2-only' etc., having
> > > the former trigger QA warning asking the dev to double-check if it's
> > > 'GPL-2-only' or 'GPL-2+'.
> >
> > This has been discussed before. There is no such license as GPL-2-only.
>
> Yes there is:
> https://spdx.org/licenses/GPL-2.0-only.html
> https://spdx.org/licenses/GPL-2.0-or-later.html

Just so everything is clear: Ulrich is just making an extremely
pedantic point that the there's no version of the GPL-2 license itself
with the "only" in it. Strange, now that I think about it I don't
remember a "GPL-2+" license either...

Re: [gentoo-dev] [RFC] Adding 'GPL-2-only', 'GPL-3-only' etc. license variants for better auditing

[Matt Turner]

On Sat, Sep 21, 2019 at 4:46 PM Ulrich Mueller  wrote:
>
> >>>>> On Sun, 22 Sep 2019, Matt Turner wrote:
>
> > An idea to consider: use SPDX license identifiers (see
> > https://spdx.org/licenses/)
>
> > For GPL 2 they are "GPL-2.0-only" and "GPL-2.0-or-later"
>
> Yeah, they have a history of using silly names. What does 2.0 mean?
> There is no such version of the GPL, and with Gentoo versioning rules,
> 2 is not equal to 2.0.

Just responding because the absurdity of this angers me, to be honest.
See if you notice anything funny about the URL:

https://www.gnu.org/licenses/old-licenses/gpl-2.0.en.html

Re: [gentoo-dev] RFC: Require full $P not just $PN on stable/keyword commit messages

[Matt Turner]

On Fri, Nov 1, 2019 at 12:59 PM Michael 'veremitz' Everitt
 wrote:
>
> Hello,
>
> I've noticed a lot of stabilisation commit messages (and a few keywording
> ones too) simply state the package atom and not the relevant
> release/version. I find this a little meaningless, as unless this is the
> first time the package has ever been either stabilised or keyworded, it is
> reasonable to expect that there is/was some transition point for a package
> from when it first entered the Gentoo Repository.
>
> Therefore, it would be much /more/ useful to have the package-version
> tagged in the commit message, so that you could easily grep logs for when a
> given version of a package was stabilised, and/or keyworded. Granted, this
> is more of-use in a historical context compared to a present (future?!)
> one, but I would argue that it conveys more meaning -with- the version than
> without.

Yes, I agree we should do this. My commit messages look like:

sys-apps/systemd-243-r2: ppc64 stable, bug 698766
net-misc/mosh-1.3.2: added ~alpha

In the past people have argued that the version in the title is
superfluous since you can get the same info from git (log|show) --stat
but the same (misguided argument) can be used to justify something
absurd like simply making the bug number the subject.

Honestly, just put the dang version in the title.