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

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

[Matt Turner]

[-- Attachment #1: Type: text/plain, Size: 4045 bytes --]

Firstly, I'd like to welcome Nick Sarnie <sarnex@gentoo.org> to the X11 team.
He's been very helpful in improving the state of media-libs/vulkan-loader for a
while now, so it's nice to make it official!


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

Frustratingly, not sure if this is sorted out. In 1.19.99.904 [1] I modified
things so that Xorg is installed setuid when USE=-systemd. Only got one test
report (unsuccessful) but it could be a separate problem.

Please test 1.19.99.905 (RC5). The next version will be 1.20.

I would appreciate an ebuild patch from any elogind user for elogind support.

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

All architectures have stabilized x11-base/xorg-proto! Non-empty x11-proto/*
packages have been removed. I was finally able to close out 15+ bugs about
missing (transitive) dependencies on x11-proto/*. That felt good.

About 20% of the way there since April 1st:

Packages depending on x11-proto/* down from  530 ->  432 [2]
 ebuilds depending on x11-proto/* down from 1908 -> 1503 [3]

Big thanks to Arfrever for handling whole categories at a time!

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.

== media-libs/vulkan-loader updates and features ==
https://bugs.gentoo.org/619124

Sarnex worked hard to get vulkan-loader updated. He added USE=layers and
USE=demos. The "layers" are an important feature of Vulkan: validation layers
that can be enabled to help you fix your application.

== Xorg stabilization for May 2018 ==
https://bugs.gentoo.org/649316

Stabilization of 27 packages appears to be going rather smoothly. The new
xorg-server version being stabilized contains a fix Sarnex found that will be
necessary for Mesa 18.0.

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

All blockers handled. Packages given last rites. Will be removed May 21st or
soon thereafter.

== Remove x11-libs/xpyb ==
https://bugs.gentoo.org/651300

Given last rites. Will be removed May 22nd or soon thereafter

== Remove media-libs/libtxc_dxtn ==
https://bugs.gentoo.org/654464

I merged the S3TC texture compression code in libtxc_dxtn into Mesa for 17.3
(the patent expired! yay!). A couple of packages actually depend directly on
libtxc_dxtn. Once those are fixed, we'll be able to tree clean it.

== Remove x11-libs/libXfont ==
https://bugs.gentoo.org/655102

libXfont has been replaced by libXfont2. With a few packages fixed, we'll be
able to tree clean the old slot.

== Convert media-libs/mesa ebuild to build with Meson ==
https://bugs.gentoo.org/652762

Ebuild posted. Blocked on problems surrounding LLVM (this is the story of
maintaining media-libs/mesa).

The problem is that Meson has no way of specifying a different llvm-config
binary without a cross file, which our meson.eclass does not generate for
32-bit x86 builds on amd64. We've filed a Meson issue here [4] but haven't seen
any progress towards a solution.

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

No progress.

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

No progress.

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

No progress.

== Fix/Remove OpenCL ==
https://bugs.gentoo.org/546320
https://bugs.gentoo.org/647330

No progress, but an upstream Mesa developer interested in OpenCL and Gentoo
user is interested in contributing in order to get rid of eselect-opencl and to
use the ICD interface instead.

== Clean out x11 overlay ==
https://gitweb.gentoo.org/proj/x11.git/

No progress.


[1] https://bugs.gentoo.org/635102#c31
[2] git grep x11-proto | cut -d '/' -f -2 | grep -v metadata | sort -u | wc -l
[3] git grep x11-proto | wc -l 
[4] https://github.com/mesonbuild/meson/issues/3327

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Matt Turner]

On Mon, May 7, 2018 at 1:38 PM, Matt Turner <mattst88@gentoo.org> wrote:
> == Convert media-libs/mesa ebuild to build with Meson ==
> https://bugs.gentoo.org/652762
>
> Ebuild posted. Blocked on problems surrounding LLVM (this is the story of
> maintaining media-libs/mesa).
>
> The problem is that Meson has no way of specifying a different llvm-config
> binary without a cross file, which our meson.eclass does not generate for
> 32-bit x86 builds on amd64. We've filed a Meson issue here [4] but haven't
> seen
> any progress towards a solution.

Just wanted to highlight this section for the Meson maintainers specifically.

Why do we not generate cross files for 32-bit builds on 64-bit? As far
as I understand that would be sufficient for us. Do you have any
suggestions?

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

[Mike Gilbert]

On Mon, May 7, 2018 at 4:49 PM, Matt Turner <mattst88@gentoo.org> wrote:
> On Mon, May 7, 2018 at 1:38 PM, Matt Turner <mattst88@gentoo.org> wrote:
>> == Convert media-libs/mesa ebuild to build with Meson ==
>> https://bugs.gentoo.org/652762
>>
>> Ebuild posted. Blocked on problems surrounding LLVM (this is the story of
>> maintaining media-libs/mesa).
>>
>> The problem is that Meson has no way of specifying a different llvm-config
>> binary without a cross file, which our meson.eclass does not generate for
>> 32-bit x86 builds on amd64. We've filed a Meson issue here [4] but haven't
>> seen
>> any progress towards a solution.
>
> Just wanted to highlight this section for the Meson maintainers specifically.
>
> Why do we not generate cross files for 32-bit builds on 64-bit? As far
> as I understand that would be sufficient for us. Do you have any
> suggestions?

Using a cross file triggers cross-compile mode in meson, which makes
it behave differently in some ways. It is hard to say exactly what the
differences are; this aspect of meson if very poorly documented.

As an experiment, I implemented some changes in meson.eclass to have
it always use a cross file.

https://github.com/gentoo/gentoo/pull/8379

This seems to work ok for building systemd with multilib enabled.

Once difference I spotted is that the CFLAGS/LDFLAGS given in the
cross file get appended at the end of the compile/link commands,
instead of in the middle. That could be problematic since link
arguments like --as-needed are sensitive to their position on the
command line.

Anyway, it would be great if meson would just look at the LLVM_CONFIG
environment var instead of forcing us to use a cross file here.

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

[Brian Dolbec]

[-- Attachment #1: Type: text/plain, Size: 1559 bytes --]

On Mon, 7 May 2018 13:38:47 -0700
Matt Turner <mattst88@gentoo.org> wrote:

> 
> 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.
> 
>

Currently there is not.

Thinking out loud...  It would mean parsing package.mask to generate
the list filtering out those with "masked for removal", from other
general mask reasons,  but even that is not consistent.

from another email in today's batch...  (not to pick on this one, was
just a lucky coincidence)

 eg:

Subject: [gentoo-dev] Last rites: old, ruby23-only, slots of various

ruby packages # Hans de Graaff <graaff@gentoo.org> (7 May 2018)
# Old slots that are ruby23-only and no longer maintained
# upstream, and that do not have packages depend on them.
# Migrate to newer slot of the same package.

Perhaps we would need to add a separate last-rites.mask list that
the package manager merges internally as part of the .mask stack.  That
would make just one file to load without a need for filtering.  A
separate list might also be beneficial for the undertakers and any
tooling for its automation. (I am not familiar with any of that tooling)

I would then suggest the dependency depth check to default to one (or
two) so as to not slow things down drastically.  Perhaps a Q/A check
report to scan the whole tree on a weekly basis.

But that would also require PMS to be updated for the new file, which
means a council vote...

-- 
Brian Dolbec <dolsen>


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 981 bytes --]

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

[Matt Turner]

On Mon, May 7, 2018 at 11:24 PM, Brian Dolbec <dolsen@gentoo.org> wrote:
> On Mon, 7 May 2018 13:38:47 -0700
> Matt Turner <mattst88@gentoo.org> wrote:
>
>>
>> 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.
>>
>>
>
> Currently there is not.
>
> Thinking out loud...  It would mean parsing package.mask to generate
> the list filtering out those with "masked for removal", from other
> general mask reasons,  but even that is not consistent.

Thanks for the reply.

One clarification: the x11-proto/* packages aren't package.masked (for
removal or otherwise) -- just deprecated. They still exist just to
provide a simpler transition to x11-base/xorg-proto. After all reverse
dependencies are updated, they will indeed be tree cleaned.

But yeah. I kind of like your idea. Perhaps some method of marking a
package deprecated would be a good addition to PMS. I can imagine it
being useful in a case like mine, and it would provide a good path
towards tree cleaning. I've always thought it was kind of silly to
start the 30-day removal timer only after the last dependency is gone
from the tree, so maybe a way of marking a package deprecated could
speed that up.

The workflow I envisage would be

(1) Package is marked as deprecated by some method (call it package.deprecated)

repoman would now emit warnings when it finds a dependency on the
deprecated package, informing developers of the necessary changes and
speeding up the transition.

(2) When the transition is complete, the deprecated package could be
masked for removal under some <30 day mask or perhaps removed directly
if it's been deprecated for >=30 days.


I'll figure out the process for suggesting a future EAPI feature... :)