Re: [gentoo-dev] Last Rites: app-eselect/eselect-opengl

2020-08-11 Thread Matt Turner
On Tue, Aug 11, 2020 at 8:00 PM Philip Webb  wrote:
>
> 200811 Matt Turner wrote:
> > # Matt Turner  (2020-08-11)
> > # Replaced by media-libs/libglvnd.
> > # Masked for removal in 30 days. Bug #728286
> > app-eselect/eselect-opengl
>
> root:552 ~> emerge -cpv eselect-opengl
> Calculating dependencies... done!
>   app-eselect/eselect-opengl-1.3.1-r4 pulled in by:
> media-libs/mesa-20.0.8 requires >=app-eselect/eselect-opengl-1.3.0
> x11-base/xorg-server-1.20.8-r1 requires >=app-eselect/eselect-opengl-1.3.0
>
> 'mesa' is installed with USE="egl", which perhaps needs changing :
>
> root:554 ~> eixe mesa
> [I] media-libs/mesa
>  Available versions:  20.0.8^t ~20.1.4^t ~20.1.5^t ***l^t {+X 
> +classic d3d9 debug +dri3 +egl +gallium +gbm gles1 +gles2 +libglvnd +llvm 
> lm-sensors opencl osmesa selinux test unwind vaapi valgrind vdpau vulkan 
> vulkan-overlay wayland xa xvmc +zstd ABI_MIPS="n32 n64 o32" ABI_RISCV="lp64 
> lp64d" ABI_S390="32 64" ABI_X86="32 64 x32" KERNEL="linux" 
> VIDEO_CARDS="freedreno i915 i965 intel iris lima nouveau panfrost r100 r200 
> r300 r600 radeon radeonsi vc4 virgl vivante vmware"}
>  Installed versions:  20.0.8^t([2020-06-20 09:13:08])(X egl gallium gbm 
> wayland -classic -d3d9 -debug -dri3 -gles1 -gles2 -libglvnd -llvm -lm-sensors 
> -opencl -osmesa -selinux -test -unwind -vaapi -valgrind -vdpau -vulkan 
> -vulkan-overlay -xa -xvmc -zstd ABI_MIPS="-n32 -n64 -o32" ABI_RISCV="-lp64 
> -lp64d" ABI_S390="-32 -64" ABI_X86="64 -32 -x32" KERNEL="linux" 
> VIDEO_CARDS="nouveau -freedreno -i915 -i965 -intel -iris -lima -panfrost 
> -r100 -r200 -r300 -r600 -radeon -radeonsi -vc4 -virgl -vivante -vmware")
>
> but there is no similar flag on 'xorg-server' :
>
> root:553 ~> eix xorg-server
> [I] x11-base/xorg-server
>  Available versions:  1.20.8(0/1.20.8) 1.20.8-r1(0/1.20.8) 
> **(0/)*l {debug dmx doc (+)elogind ipv6 kdrive +libglvnd libressl 
> minimal selinux static-libs (+)suid systemd +udev unwind wayland xcsecurity 
> xephyr xnest xorg xvfb}
>  Installed versions:  1.20.8-r1(0/1.20.8)([2020-08-09 20:16:16])(elogind 
> udev xorg -debug -dmx -doc -ipv6 -kdrive -libglvnd -libressl -minimal 
> -selinux -static-libs -suid -systemd -unwind -wayland -xcsecurity -xephyr 
> -xnest -xvfb)
>
> Before I do anything damaging, can you advise how to handle the above ?

The eix output indicates that you have both mesa and xorg-server built
with USE=-libglvnd. Rebuild both with USE=libglvnd, and then neither
will depend on eselect-opengl. In the same series of commits as I
added this mask, I added 'libglvnd' to use.force, so no local
configuration changes should be necessary, although you appear to have
USE=-libglvnd set somewhere, so you probably will want to clean that
up.



Re: [gentoo-dev] Last Rites: app-eselect/eselect-opengl

2020-08-11 Thread Philip Webb
200811 Matt Turner wrote:
> # Matt Turner  (2020-08-11)
> # Replaced by media-libs/libglvnd.
> # Masked for removal in 30 days. Bug #728286
> app-eselect/eselect-opengl

root:552 ~> emerge -cpv eselect-opengl
Calculating dependencies... done!
  app-eselect/eselect-opengl-1.3.1-r4 pulled in by:
media-libs/mesa-20.0.8 requires >=app-eselect/eselect-opengl-1.3.0
x11-base/xorg-server-1.20.8-r1 requires >=app-eselect/eselect-opengl-1.3.0

'mesa' is installed with USE="egl", which perhaps needs changing :

root:554 ~> eixe mesa
[I] media-libs/mesa
 Available versions:  20.0.8^t ~20.1.4^t ~20.1.5^t ***l^t {+X +classic 
d3d9 debug +dri3 +egl +gallium +gbm gles1 +gles2 +libglvnd +llvm lm-sensors 
opencl osmesa selinux test unwind vaapi valgrind vdpau vulkan vulkan-overlay 
wayland xa xvmc +zstd ABI_MIPS="n32 n64 o32" ABI_RISCV="lp64 lp64d" 
ABI_S390="32 64" ABI_X86="32 64 x32" KERNEL="linux" VIDEO_CARDS="freedreno i915 
i965 intel iris lima nouveau panfrost r100 r200 r300 r600 radeon radeonsi vc4 
virgl vivante vmware"}
 Installed versions:  20.0.8^t([2020-06-20 09:13:08])(X egl gallium gbm 
wayland -classic -d3d9 -debug -dri3 -gles1 -gles2 -libglvnd -llvm -lm-sensors 
-opencl -osmesa -selinux -test -unwind -vaapi -valgrind -vdpau -vulkan 
-vulkan-overlay -xa -xvmc -zstd ABI_MIPS="-n32 -n64 -o32" ABI_RISCV="-lp64 
-lp64d" ABI_S390="-32 -64" ABI_X86="64 -32 -x32" KERNEL="linux" 
VIDEO_CARDS="nouveau -freedreno -i915 -i965 -intel -iris -lima -panfrost -r100 
-r200 -r300 -r600 -radeon -radeonsi -vc4 -virgl -vivante -vmware")

but there is no similar flag on 'xorg-server' :

root:553 ~> eix xorg-server
[I] x11-base/xorg-server
 Available versions:  1.20.8(0/1.20.8) 1.20.8-r1(0/1.20.8) **(0/)*l 
{debug dmx doc (+)elogind ipv6 kdrive +libglvnd libressl minimal selinux 
static-libs (+)suid systemd +udev unwind wayland xcsecurity xephyr xnest xorg 
xvfb}
 Installed versions:  1.20.8-r1(0/1.20.8)([2020-08-09 20:16:16])(elogind 
udev xorg -debug -dmx -doc -ipv6 -kdrive -libglvnd -libressl -minimal -selinux 
-static-libs -suid -systemd -unwind -wayland -xcsecurity -xephyr -xnest -xvfb)

Before I do anything damaging, can you advise how to handle the above ?

-- 
,,
SUPPORT ___//___,   Philip Webb
ELECTRIC   /] [] [] [] [] []|   Cities Centre, University of Toronto
TRANSIT`-O--O---'   purslowatcadotinterdotnet




Re: [gentoo-dev] Re: Python 2.7 cleanup: plan B

2020-08-11 Thread Brian Dolbec
On Tue, 11 Aug 2020 23:41:33 + (UTC)
"Thomas Mueller"  wrote:

> > Hi, everyone.  
> 
> > TL;DR: we might keep Python 2.7 supported as a build-time dependency
> > of a few packages as necessary, while removing the eclass support
> > for installing packages for py2.7.  
> 
> 
> > As I've mentioned earlier, the plan is to get rid of Python 2.7
> > target support at the beginning of 2021.  The plan was to last rite
> > all remaining packages failing to support Python 3 at 2021-01-01,
> > and remove the eclass support on 2021-02-15.  At the same time, the
> > Python interpreter was going to stay around for as long as
> > necessary.  
> 
> > I've also mentioned that there is a high risk that this will not be
> > possible because of a few large entities ignoring the problem
> > and failing to port their build system scripts away from Python 2.
> > We can't really last rite all major web browsers, and postponing
> > the deadline indefinitely is not a good solution either.  
> 
> > Therefore, I advise the following plan B: if it is impossible to
> > remove Python 2.7 support from packages entirely, the support for
> > installing Python packages for Python 2.7 will be removed.
> > However, there will be exemptions granted for build-time
> > dependencies on the Python interpreter to keep things working, for
> > as long as the interpreter itself is going to stay.  
> 
> > The candidates for exemptions are pypy/pypy3 (CPython 2.7 is needed
> > for bootstrap on new platforms), Mozilla products, WebKit and
> > WebKit-based browsers.  
> 
> > Best regards,
> > Micha=C5=82 G=C3=B3rny  
> 
> I believe net-print/hplip also depends on Python 2.7.  This is
> print/hplip in NetBSD pkgsrc and FreeBSD ports.
> 
> Or did they fix that recently?
> 
> Possibly hplip is mainly for older HP printers, not sure about what's
> going on with HP laser printers more recently.
> 
> Maybe that's why there has been reluctance to fix the Python 2.7
> dependency?
> 
> I have such an HP printer (LaserJet M1212nf MFP), and my experience
> dissuades me from ordering anything further from HP.
> 
> I think most everybody involved with open-source would agree that
> proprietary binary plugins suck.
> 
> Tom
> 
> 
latest hplip has: PYTHON_COMPAT=( python3_{6,7,8} )
and older one was just missing py3.8



[gentoo-dev] Re: Python 2.7 cleanup: plan B

2020-08-11 Thread Thomas Mueller
> Hi, everyone.

> TL;DR: we might keep Python 2.7 supported as a build-time dependency
> of a few packages as necessary, while removing the eclass support for
> installing packages for py2.7.


> As I've mentioned earlier, the plan is to get rid of Python 2.7 target
> support at the beginning of 2021.  The plan was to last rite all
> remaining packages failing to support Python 3 at 2021-01-01, and remove
> the eclass support on 2021-02-15.  At the same time, the Python
> interpreter was going to stay around for as long as necessary.

> I've also mentioned that there is a high risk that this will not be
> possible because of a few large entities ignoring the problem
> and failing to port their build system scripts away from Python 2.
> We can't really last rite all major web browsers, and postponing
> the deadline indefinitely is not a good solution either.

> Therefore, I advise the following plan B: if it is impossible to remove
> Python 2.7 support from packages entirely, the support for installing
> Python packages for Python 2.7 will be removed.  However, there will be
> exemptions granted for build-time dependencies on the Python interpreter
> to keep things working, for as long as the interpreter itself is going
> to stay.

> The candidates for exemptions are pypy/pypy3 (CPython 2.7 is needed for
> bootstrap on new platforms), Mozilla products, WebKit and WebKit-based
> browsers.

> Best regards,
> Micha=C5=82 G=C3=B3rny

I believe net-print/hplip also depends on Python 2.7.  This is print/hplip in 
NetBSD pkgsrc and FreeBSD ports.

Or did they fix that recently?

Possibly hplip is mainly for older HP printers, not sure about what's going on 
with HP laser printers more recently.

Maybe that's why there has been reluctance to fix the Python 2.7 dependency?

I have such an HP printer (LaserJet M1212nf MFP), and my experience dissuades 
me from ordering anything further from HP.

I think most everybody involved with open-source would agree that proprietary 
binary plugins suck.

Tom




[gentoo-dev] Last Rites: app-eselect/eselect-opengl

2020-08-11 Thread Matt Turner
# Matt Turner  (2020-08-11)
# Replaced by media-libs/libglvnd.
# Masked for removal in 30 days. Bug #728286
app-eselect/eselect-opengl


signature.asc
Description: PGP signature


[gentoo-dev] Last Rites: app-eselect/eselect-opencl

2020-08-11 Thread Matt Turner
# Matt Turner  (2020-08-11)
# No longer needed with virtual/opencl-3
# Masked for removal in 30 days. Bug #728284
app-eselect/eselect-opencl


signature.asc
Description: PGP signature


[gentoo-dev] Last Rites: x11-drivers/nvidia-drivers:0/340

2020-08-11 Thread Matt Turner
# Matt Turner  (2020-08-11)
# NVIDIA declared this branch to have reached end of life about six months ago.
# Blocks removal of app-eselect/eselect-opengl and app-eselect/eselect-opencl.
# Masked for removal in 30 days. Bug #728290
x11-drivers/nvidia-drivers:0/340


signature.asc
Description: PGP signature


Re: [gentoo-dev] Python 2.7 cleanup: plan B

2020-08-11 Thread Matt Turner
On Tue, Aug 11, 2020 at 9:31 AM Michał Górny  wrote:
> TL;DR: we might keep Python 2.7 supported as a build-time dependency
> of a few packages as necessary, while removing the eclass support for
> installing packages for py2.7.

I think this is the right plan (and is along the lines of what I
suggested in the context of removing offlineimap, which didn't need
anything except the Python 2.7 interpreter).



[gentoo-dev] last rite: x11-libs/flowcanvas

2020-08-11 Thread Miroslav Šulc

# Miroslav Šulc  (2020-08-11)
# Package dead. No consumers in the tree.
# Removal in 30 days. Bug #735518
x11-libs/flowcanvas




[gentoo-dev] Python 2.7 cleanup: plan B

2020-08-11 Thread Michał Górny
Hi, everyone.

TL;DR: we might keep Python 2.7 supported as a build-time dependency
of a few packages as necessary, while removing the eclass support for
installing packages for py2.7.


As I've mentioned earlier, the plan is to get rid of Python 2.7 target
support at the beginning of 2021.  The plan was to last rite all
remaining packages failing to support Python 3 at 2021-01-01, and remove
the eclass support on 2021-02-15.  At the same time, the Python
interpreter was going to stay around for as long as necessary.

I've also mentioned that there is a high risk that this will not be
possible because of a few large entities ignoring the problem
and failing to port their build system scripts away from Python 2.
We can't really last rite all major web browsers, and postponing
the deadline indefinitely is not a good solution either.

Therefore, I advise the following plan B: if it is impossible to remove
Python 2.7 support from packages entirely, the support for installing
Python packages for Python 2.7 will be removed.  However, there will be
exemptions granted for build-time dependencies on the Python interpreter
to keep things working, for as long as the interpreter itself is going
to stay.

The candidates for exemptions are pypy/pypy3 (CPython 2.7 is needed for
bootstrap on new platforms), Mozilla products, WebKit and WebKit-based
browsers.

-- 
Best regards,
Michał Górny



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


Re: [gentoo-dev] rfc: switching default udev provider for new systems to udev

2020-08-11 Thread Piotr Karbowski
On 11/08/2020 15.38, Joonas Niilola wrote:
> 
> On 8/11/20 11:36 AM, Jaco Kroon wrote:
>> And I've already provided you one use case where udev doesn't work well
>> but eudev does.  I've also mentioned some historic issues I believe
>> should already be fixed but which did bit me in systemd-udev which was
>> never a problem in eudev.
>>
> Your systems seem to diverge a lot from what I'd consider as 'default'.
> You must already make many changes to them.
> 
> Before this thread I didn't even know/remember I was using eudev. It
> works and there doesn't seem to be any global issues related to it.
> However after reading this thread I'm a bit considered about the
> maintenance state of it.
> 
> Switched to udev. Simple as 'emerge -1 sys-fs/udev'. It works, didn't
> notice any difference.
> 
> If musl is a problem, to my knowledge musl has its own stage images, so
> why can't those stages use eudev while other ones defaulting to udev?

For the sake of science, I've also moved one of my systems to
sys-fs/udev and noticed a single incompatibility. There are few ways how
to disable the systemd/udev predictable NIC names, one of them is to
boot with net.ifnames=0, another is to mask rule file that trigger the
rename, as described on wiki[1]

Long story short, on eudev it's 80-net-name-slot.rules, on udev it's
80-net-setup-link.rules

The result was that my system booted without working network, as connman
started to poke around Ethernet interfaces (this is ok, I had
blacklisted eth*, not enp*), which then resulted in switching routing to
Ethernet that failed to get IP from DHCP, even that WiFi had a fully
working Internet access, so more like connman bug. (And yes, I am aware
that net.ifnames=0 will work on both)

This however shows two things: eudev is (no longer) drop-in replacement,
as some interfaces changed in upstream udev, which leads to second
thing, we need to have migration path, because even if(!) Gentoo change
default (I am not a fan of this idea really), then it might lead to
people doing fresh installation or reinstallation, migrating their
configs resulting in not working systems/working in other way that
previous one.

[1] https://wiki.gentoo.org/wiki/Udev#Keep_classic_.27eth0.27_naming

-- Piotr.



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] rfc: switching default udev provider for new systems to udev

2020-08-11 Thread Joonas Niilola

On 8/11/20 11:36 AM, Jaco Kroon wrote:
> And I've already provided you one use case where udev doesn't work well
> but eudev does.  I've also mentioned some historic issues I believe
> should already be fixed but which did bit me in systemd-udev which was
> never a problem in eudev.
>
Your systems seem to diverge a lot from what I'd consider as 'default'.
You must already make many changes to them.

Before this thread I didn't even know/remember I was using eudev. It
works and there doesn't seem to be any global issues related to it.
However after reading this thread I'm a bit considered about the
maintenance state of it.

Switched to udev. Simple as 'emerge -1 sys-fs/udev'. It works, didn't
notice any difference.

If musl is a problem, to my knowledge musl has its own stage images, so
why can't those stages use eudev while other ones defaulting to udev?

-- juippis




signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] rfc: switching default udev provider for new systems to udev

2020-08-11 Thread Jaco Kroon


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

> As I have said earlier on the thread, we should look at udev and seee if
> it breaks things in relation to eudev. That would take some folks
> migrating their systems and reporting issues.

And I've already provided you one use case where udev doesn't work well
but eudev does.  I've also mentioned some historic issues I believe
should already be fixed but which did bit me in systemd-udev which was
never a problem in eudev.

But then again, with past experience I'm now one of those that refuse to
install systemd-udev and give it a twirl on production systems to see if
it's still an issue whereby I end up rebooting servers on a weekly basis.

Kind Regards,
Jaco

-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEEyyCUcKjG7P5BDam8CC3Esa/37p4FAl8yWHEACgkQCC3Esa/3
7p6w1wf/clHZuUn3KgCheQQvEyBSBf3IEmXgN+ejtxGNn+cyK4p6A7j3dU6n9ain
aPcL4zGOkixHpEwhz2bQAIljEtHI2wYhBYBv7+c9mUEmbSp7xhwZUvZd1a69YUk1
cEclzHGlKQwcRFqyrGIOLk6/iuwr8REavd1EwcLsrXeuCI7xukFRdHeOideGCztI
4ziK6QZaN/BZ1ZPV1yzdheBq2E0tAiMRG2gKiuNopBEETc+PpegUPsk6T4dnmEZV
EGG3LlzpufgPUF+qymzyRiT94i7azebfO17hOzJ4cZJXi7Lz9dzUTrxJvpYknbzp
XruDKuoRBSPp5OQ2ZeO/0Q0L8WILZg==
=Q6Bl
-END PGP SIGNATURE-




Re: [gentoo-dev] rfc: switching default udev provider for new systems to udev

2020-08-11 Thread Mart Raudsepp
Ühel kenal päeval, T, 11.08.2020 kell 07:44, kirjutas Michał Górny:
> > Examples?
> 
> I suppose nobody remembers the time (the previous year) where eudev
> broke reverse dependencies because of wrong version number, and it
> took
> around 3 months to get a fix (read: changing the version number) into
> ~arch.

Having forgotten about that (even when being directly involved in it),
it doesn't look all that bad in this example on hindsight.

Upstream issue tracker got a notification of it (being unusable for
mutter) in https://github.com/gentoo/eudev/issues/173 on 2019-05-12.
It was fixed upstream eudev on 2019-05-19, and the fix was released
into eudev-3.2.8, released on 2019-05-20.

But Gentoo virtual/libudev-232 still claimed >=eudev-1.3 is fine for
it, while mutter had to depend on >=virtual/libudev-228.
So eudev-3.2.8 already available in main tree was fine for mutter, but
there was no virtual/libudev-228, which would ensure >=eudev-3.2.8 and
that eudev version wasn't stable. So a quick fix would have been to add
a virtual/libudev-228 too in ~arch, which would have given a way to
ensure 228 by eudev-3.2.8, but this seems to have been overlooked,
thinking that a new eudev release is needed. This was compounded by no
(rather) quick replies from eudev maintainers to advise what to do with
the virtual. Eventually eudev-3.2.9 ended up being what is required, as
it provides claimed compatibility with libudev-243, which is new enough
for virtual/libudev-232.
So after initial Gentoo problem report[1] on 2019-09-11, and the
virtual/libudev bug report[2] on 2019-10-12, it all got solved by
stabilization request[3] of eudev-3.2.9 (and virtual/libudev restoring
eudev as provider) on 2019-10-28 with main arches dealing with it the
same day. ~arch was fixed on 2019-10-26, 1.5 months after initial bug
report, which per the above actually turns out actually not been an
~arch problem, but ~arch mutter mixed with stable eudev. Affected
mutter version was only stabilized in 2019-12-08.

So virtual/libudev dropping eudev as provider for this forced stable
tree to be fixed to be technically correct.
I think the main takeaway point is that on virtual/libudev version
bumps, the eudev claimed versions need to be checked as well, and the
matching >= dep for eudev figured out from the start. What each eudev
version claims as the libudev version can be seen in the UDEV_VERSION
variable set at top of configure.ac.

Personally I believe the first choice for virtual/udev should be
sys-fs/udev instead of sys-fs/eudev for our users, as it's more
maintained upstream, but don't have any personal stake in it as my udev
provider is systemd.

Various changes in udev upstream that wouldn't be in eudev (yet) would
be dealing with rule changes and bug fixes, which aren't relevant to
those people that aren't affected by these bugs, but very relevant if
you are affected by them.

I don't think it would be impossible to have musl-supporting out of the
box udev out of systemd tarball, if there was someone actually working
with upstream systemd on it in a constructive manner, effectively being
the musl support maintainer as part of upstream community.


Mart


References:
1. https://bugs.gentoo.org/694014
2. https://bugs.gentoo.org/697550
3. https://bugs.gentoo.org/698698


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