Re: Nvidia GPU overclocking in Fedora Silverblue 30 is currently broken

[Ty Young]

On 7/8/19 3:59 PM, Nicolas Chauvet wrote:

Le lun. 8 juil. 2019 à 21:29, Ty Young  a écrit :

Bug filed: https://bugzilla.rpmfusion.org/show_bug.cgi?id=5307

The driver itself seems perfectly fine in that the system boots and OpenGL 
works perfectly fine. Games are playable.

How do I output strace to a file directly? It spits out way too much info.

The bug is reproducible by doing a fresh install on a new downloaded ISO but 
really the likelihood that this is a bug caused by Nvidia is slim to none. Arch 
Linux(what I primarily use) has the same driver version and everything works 
perfectly fine.

Regardless of whether or not this specific bug was by a packaging issue or 
Nvidia, the way Fedora packages the Nvidia drivers is bad:

-nvidia-smi isn't specific to CUDA and is a core Nvidia library interface that 
should come with the base driver as it does in Windows.

That's moot, but the comparison with nvidia on Windows is not
relevant. if you want nvidia-smi, please install
xorg-x11-drv-nvidia-cuda
Previously nvidia-smi relied on any cuda lib, so it was moved on the
cuda side, but we can re-evaluate this, I take take a RFE.



Arch simply includes it with the driver utils(see 
https://www.archlinux.org/packages/extra/x86_64/nvidia-utils/files/). 
The most equivalent package in Fedora would be the Nvidia-utils package 
in Fedora(see 
https://fedora.pkgs.org/30/rpmfusion-nonfree-x86_64/xorg-x11-drv-nvidia-libs-418.56-1.fc30.x86_64.rpm.html)



The main thing is that noone will ever know that nvidia-smi is apart of 
the CUDA package without digging through the provides listings.





With that said, the appropriate doc is here:
https://rpmfusion.org/Howto/NVIDIA
It is only mentioned to install akmod-nvidia and xorg-x11-drv-nvidia
that's the interface we rely on. (Everything else should be
auto-detected on purpose).
Also to wait a few for the module to build and install and reboot
(it's explicitly required).



That gets you a working driver but not OpenGL or any of the core Nvidia 
driver utils/libs such as nvidia-smi, nvidia-settings, nvidia-xconfig, 
etc. If you try to install Steam for example it will blow up real bad.






-nvidia-settings is the Linux alternative to Window's control panel and if not included 
by default, *should* be included via a "meta" package for desktop users.

It's a separate package, but it is required by the drivers as it's
mandatory indeed. So I don't understand the metapackage thing, it's a
solution for others distros, the Fedora ways is different. (virtual
provides , booleans dependencies, etc).



If memory serves me correctly nvidia-settings *is* silently installed 
but not explicitly. In other words, you can see and launch the 
application in Gnome 3 without explicitly installing it but doing:



rpm-ostree install nvidia-settings


Will still work and "install" the package despite it already been 
installed. I'll have to do another reinstall and install just the driver 
to make sure. Could be smoking shrooms here but I remember it being there...



I'd like to pose the question though, is this really a good thing? 
People don't like it when you silently install things behind their back. 
A meta package(at least in the form I'm thinking of) is different as it 
points to other packages and says to install those packages. If you want 
more information on what those packages contain you should be able to 
lookup what each package provides.






-OpenGL not packaged with the driver(or again, install-able via a meta 
package)? Who wants a graphics driver without OpenGL/Vulkan support?

Well, some people want to have selectables sub-packages as
appropriate, and the split made by RPM Fusion is carefully minded. But
we still welcome improvements.



...which is fine. A meta package(one that points to many sub packages) 
would allow this.






-it isn't clear if the command I posted(above) installs the 32-bit libraries or 
not. Really, meta packages would go a long way in simplifying GPU driver 
installs!

In regular Fedora, it will install the 32bit libraries on purpose with
the nvidia driver if you have at least a package that requires 32bit
libGL. (same for cuda-libs).



That doesn't work for 32-bit games though since they don't use the 
package manager and Steam does need 32-bit libs if not installed via 
Flatpak. Yes, Steam provides many 32-bit libs but as they have said 
during the whole Ubuntu 32-bit support mess, they still use system libs. 
Which libs? I don't know, they'd probably have a good idea.



It isn't possible to play Proton games using Fedora Steam but is 
possible with Flatpak Steam for example which I can only assume is 
because of missing 32-bit libs. Installing Wine would probably pull in 
the requires 32-bit libs since Proton is Wine...






Neither Windows nor even other Linux distros fragment the driver this much. 
You'd have to add 32-bit libraries alongside the 64 bit driver and 64 bit 
libraries to equal Fedora's fragmented driver packaging in s

Re: [atomic-announce] Fedora Atomic Host Two Week Release Announcement: 29.20190708.0

[Sinny Kumari]

On Tue, Jul 9, 2019 at 1:59 AM  wrote:

>
> A new Fedora Atomic Host update is available via an OSTree update:
>
> Version: 29.20190708.0
> Commit(x86_64):
> e4c5affdeff6cbe5c494cbad48419d9746c017f17b46e97ae83639f6328989ce
> Commit(aarch64):
> 58d13ffe3fff2cba3736dfc6a1158991e5d8845fa16b8b501b6b03c7fead3af3
> Commit(ppc64le):
> ea961b706191a4fd6bab4e5b6dda2f5250497a0d1b7fc1831a11796b5af6f57e
>
>
> We are releasing images from multiple architectures but please note
> that x86_64 architecture is the only one that undergoes automated
> testing at this time.
>
> Existing systems can be upgraded in place via e.g. `atomic host upgrade`.
>
> Corresponding image media for new installations can be downloaded from:
>
> https://getfedora.org/en/atomic/download/
>
> Alternatively, image artifacts can be found at the following links:
>
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190708.0/AtomicHost/aarch64/images/Fedora-AtomicHost-29-20190708.0.aarch64.qcow2
>
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190708.0/AtomicHost/aarch64/images/Fedora-AtomicHost-29-20190708.0.aarch64.raw.xz
>
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190708.0/AtomicHost/aarch64/iso/Fedora-AtomicHost-ostree-aarch64-29-20190708.0.iso
>
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190708.0/AtomicHost/ppc64le/images/Fedora-AtomicHost-29-20190708.0.ppc64le.qcow2
>
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190708.0/AtomicHost/ppc64le/images/Fedora-AtomicHost-29-20190708.0.ppc64le.raw.xz
>
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190708.0/AtomicHost/ppc64le/iso/Fedora-AtomicHost-ostree-ppc64le-29-20190708.0.iso
>
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190708.0/AtomicHost/x86_64/images/Fedora-AtomicHost-29-20190708.0.x86_64.qcow2
>
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190708.0/AtomicHost/x86_64/images/Fedora-AtomicHost-29-20190708.0.x86_64.raw.xz
>
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190708.0/AtomicHost/x86_64/images/Fedora-AtomicHost-Vagrant-29-20190708.0.x86_64.vagrant-libvirt.box
>
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190708.0/AtomicHost/x86_64/images/Fedora-AtomicHost-Vagrant-29-20190708.0.x86_64.vagrant-virtualbox.box
>
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190708.0/AtomicHost/x86_64/iso/Fedora-AtomicHost-ostree-x86_64-29-20190708.0.iso
>
> Respective signed CHECKSUM files can be found here:
>
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190708.0/AtomicHost/aarch64/images/Fedora-AtomicHost-29-20190708.0-aarch64-CHECKSUM
>
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190708.0/AtomicHost/aarch64/iso/Fedora-AtomicHost-29-20190708.0-aarch64-CHECKSUM
>
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190708.0/AtomicHost/ppc64le/images/Fedora-AtomicHost-29-20190708.0-ppc64le-CHECKSUM
>
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190708.0/AtomicHost/ppc64le/iso/Fedora-AtomicHost-29-20190708.0-ppc64le-CHECKSUM
>
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190708.0/AtomicHost/x86_64/images/Fedora-AtomicHost-29-20190708.0-x86_64-CHECKSUM
>
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190708.0/AtomicHost/x86_64/iso/Fedora-AtomicHost-29-20190708.0-x86_64-CHECKSUM
>
> For direct download, the "latest" targets are always available here:
> x86_64:
> https://getfedora.org/atomic_qcow2_x86_64_latest
> https://getfedora.org/atomic_raw_x86_64_latest
> https://getfedora.org/atomic_vagrant_libvirt_x86_64_latest
> https://getfedora.org/atomic_vagrant_virtualbox_x86_64_latest
> https://getfedora.org/atomic_dvd_ostree_x86_64_latest
>
> aarch64:
> https://getfedora.org/atomic_qcow2_aarch64_latest
> https://getfedora.org/atomic_raw_aarch64_latest
> https://getfedora.org/atomic_dvd_ostree_aarch64_latest
>
> ppc64le:
> https://getfedora.org/atomic_qcow2_ppc64le_latest
> https://getfedora.org/atomic_raw_ppc64le_latest
> https://getfedora.org/atomic_dvd_ostree_ppc64le_latest
>
> Filename fetching URLs are available here:
> x86_64:
> https://getfedora.org/atomic_qcow2_x86_64_latest_filename
> https://getfedora.org/atomic_raw_x86_64_latest_filename
> https://getfedora.org/atomic_vagrant_libvirt_x86_64_latest_filename
> https://getfedora.org/atomic_vagrant_virtualbox_x86_64_latest_filename
> https://getfedora.org/atomic_dvd_ostree_x86_64_latest_filename
>
> aarch64:
> https://getfedora.org/atomic_qcow2_aarch64_latest_filename
> https://getfedora.org/atomic_raw_aarch64_latest_filename
> https://getfedora.org/atomic_dvd_ostree_aarch64_latest_filename

[Fedocal] Reminder meeting : Modularity Team (weekly)

[nils]

Dear all,

You are kindly invited to the meeting:
   Modularity Team (weekly) on 2019-07-09 from 15:00:00 to 16:00:00 UTC
   At fedora-meetin...@irc.freenode.net

The meeting will be about:
Meeting of the Modularity Team.

More information available at: [Modularity Team 
Docs](https://docs.pagure.org/modularity/)

The agenda for the meeting is available as flagged tickets [in the Modularity 
repository](https://pagure.io/modularity/issues?status=Open&tags=Meeting).



Source: https://apps.fedoraproject.org/calendar/meeting/9480/

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Contents of devel Digest, Vol 185, Issue 29... rpmlint: shared-lib-without-dependency-information

[Steven Munroe]

I have a similar problem with the proposed package pveclib. I my case I
have a data only libraries. I can eliminate the rpmlint error by forcing a
link to -lc But I am not sure the the appropriate solution.

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


>
> -- Forwarded message --
> From: Florian Weimer 
> To: "Miro Hrončok" 
> Cc: devel@lists.fedoraproject.org, Marcel Plch 
> Bcc:
> Date: Mon, 08 Jul 2019 15:25:27 +0200
> Subject: Re: rpmlint: shared-lib-without-dependency-information (parts of
> Python stdlib)
> * Miro Hrončok:
>
> > On 05. 02. 19 19:04, Miro Hrončok wrote:
> >> I've just spotted these when working on Python 3.8.0a1. This happens
> >> on 3.7 as well since GCC 9:
> >>
> >> python3-debug.x86_64: E: library-not-linked-against-libc
> >> /usr/lib64/python3.7/lib-dynload/_
> contextvars.cpython-37dm-x86_64-linux-gnu.so
> >> python3-debug.x86_64: E: library-not-linked-against-libc
> >> /usr/lib64/python3.7/lib-dynload/_
> testimportmultiple.cpython-37dm-x86_64-linux-gnu.so
> >>
> >> python3-libs.x86_64: E: library-not-linked-against-libc
> >> /usr/lib64/python3.7/lib-dynload/_
> contextvars.cpython-37m-x86_64-linux-gnu.so
> >> python3-test.x86_64: E: library-not-linked-against-libc
> >> /usr/lib64/python3.7/lib-dynload/_
> testimportmultiple.cpython-37m-x86_64-linux-gnu.so
> >>
> >>
> >> (Note that there are plenty of other extension modules that do not
> >> raise this error.)
> >>
> >> This doesn't happen with latest python3 built prior to the gcc update
> to 9.
> >>
> >> $ rpmlint -I library-not-linked-against-libc
> >> library-not-linked-against-libc:
> >>
> >> That isn't helpful either.
> >>
> >> I found a similar Debian thing [1] that says:
> >>
> >>  > It is theoretically possible to have a library which doesn't use any
> symbols
> >>  > from libc...
> >>
> >> Do I care? Should I fix something? I honestly have no idea.
> >>
> >> [1]
> https://lintian.debian.org/tags/library-not-linked-against-libc.html
> >
> >
> > We have new errors on F30+:
> >
> > python38.x86_64: E: shared-lib-without-dependency-information
> > /usr/lib64/python3.8/lib-dynload/_
> contextvars.cpython-38-x86_64-linux-gnu.so
> > python38.x86_64: E: shared-lib-without-dependency-information
> > /usr/lib64/python3.8/lib-dynload/_heapq.cpython-38-x86_64-linux-gnu.so
> > python38.x86_64: E: shared-lib-without-dependency-information
> > /usr/lib64/python3.8/lib-dynload/_
> testimportmultiple.cpython-38-x86_64-linux-gnu.so
> > python38.x86_64: E: shared-lib-without-dependency-information
> > /usr/lib64/python3.8/lib-dynload/_
> testinternalcapi.cpython-38-x86_64-linux-gnu.so
> >
> > rpmlint doesn't give much info:
> > $ rpmlint -I shared-lib-without-dependency-information
> > shared-lib-without-dependency-information:
> >
> >
> > But lintian again explains the issue:
> >
> https://lintian.debian.org/tags/shared-lib-without-dependency-information.html
> >
> > The listed shared library doesn't include information about which
> > other libraries the library was linked against. (When running "ldd
> > foo.so" ldd should report about these other libraries. In your case,
> > ldd just reports "statically linked".)
> >
> > I again think this is OK for Python extension modules.
> > Thoughts?
>
> It depends on the extension module.  For _contextvars, it's okay because
> it does not link against anything (glibc or otherwise).  Global C++
> destructors will not work because of unfulfilled weak reference to
> __cxa_finalize, but you probably do not care about that.
>
> rpmlint really should have a list of symbols from system libraries that
> need linking, otherwise there's always going to be false positives for
> such plugins.  (Although extension modules could link against libpython
> on Fedora because Fedora doesn't use the fat Python interpreter, unlike
> some other distributions.)
>
> Thanks,
> Florian
>
>
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Nvidia GPU overclocking in Fedora Silverblue 30 is currently broken

[Nicolas Chauvet]

Le lun. 8 juil. 2019 à 21:29, Ty Young  a écrit :
>
> Bug filed: https://bugzilla.rpmfusion.org/show_bug.cgi?id=5307
>
> The driver itself seems perfectly fine in that the system boots and OpenGL 
> works perfectly fine. Games are playable.
>
> How do I output strace to a file directly? It spits out way too much info.
>
> The bug is reproducible by doing a fresh install on a new downloaded ISO but 
> really the likelihood that this is a bug caused by Nvidia is slim to none. 
> Arch Linux(what I primarily use) has the same driver version and everything 
> works perfectly fine.
>
> Regardless of whether or not this specific bug was by a packaging issue or 
> Nvidia, the way Fedora packages the Nvidia drivers is bad:
>
> -nvidia-smi isn't specific to CUDA and is a core Nvidia library interface 
> that should come with the base driver as it does in Windows.
That's moot, but the comparison with nvidia on Windows is not
relevant. if you want nvidia-smi, please install
xorg-x11-drv-nvidia-cuda
Previously nvidia-smi relied on any cuda lib, so it was moved on the
cuda side, but we can re-evaluate this, I take take a RFE.

With that said, the appropriate doc is here:
https://rpmfusion.org/Howto/NVIDIA
It is only mentioned to install akmod-nvidia and xorg-x11-drv-nvidia
that's the interface we rely on. (Everything else should be
auto-detected on purpose).
Also to wait a few for the module to build and install and reboot
(it's explicitly required).

> -nvidia-settings is the Linux alternative to Window's control panel and if 
> not included by default, *should* be included via a "meta" package for 
> desktop users.
It's a separate package, but it is required by the drivers as it's
mandatory indeed. So I don't understand the metapackage thing, it's a
solution for others distros, the Fedora ways is different. (virtual
provides , booleans dependencies, etc).

> -OpenGL not packaged with the driver(or again, install-able via a meta 
> package)? Who wants a graphics driver without OpenGL/Vulkan support?
Well, some people want to have selectables sub-packages as
appropriate, and the split made by RPM Fusion is carefully minded. But
we still welcome improvements.

> -it isn't clear if the command I posted(above) installs the 32-bit libraries 
> or not. Really, meta packages would go a long way in simplifying GPU driver 
> installs!
In regular Fedora, it will install the 32bit libraries on purpose with
the nvidia driver if you have at least a package that requires 32bit
libGL. (same for cuda-libs).

> Neither Windows nor even other Linux distros fragment the driver this much. 
> You'd have to add 32-bit libraries alongside the 64 bit driver and 64 bit 
> libraries to equal Fedora's fragmented driver packaging in some distros. Why?
Well, It could be worst. You could have sub-packages depending on the
need to run headless or without Xorg or without wayland dependencies
etc.
That's constraints you might not have, but a good packaging should
works everywhere.

With that said the rpm-ostree line you have used is silly with respect
to the need to llst all sub-packages. Can you point me to the
documentation you have used ?
Thx

-- 
-

Nicolas (kwizart)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 31 Self-Contained Change proposal: Qt Wayland By Default on Gnome

[Vitaly Zaitsev via devel]

Hello, John Florian.

Mon, 8 Jul 2019 15:45:38 -0400 you wrote:

> Along these lines, what's the status of Plasma on Wayland?

Too unstable. Crashes a lot, especially on NVIDIA.

--
Sincerely,
 Vitaly Zaitsev (vit...@easycoding.org)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Fedora Atomic Host Two Week Release Announcement: 29.20190708.0

[noreply]

A new Fedora Atomic Host update is available via an OSTree update:

Version: 29.20190708.0
Commit(x86_64): e4c5affdeff6cbe5c494cbad48419d9746c017f17b46e97ae83639f6328989ce
Commit(aarch64): 
58d13ffe3fff2cba3736dfc6a1158991e5d8845fa16b8b501b6b03c7fead3af3
Commit(ppc64le): 
ea961b706191a4fd6bab4e5b6dda2f5250497a0d1b7fc1831a11796b5af6f57e


We are releasing images from multiple architectures but please note
that x86_64 architecture is the only one that undergoes automated
testing at this time.

Existing systems can be upgraded in place via e.g. `atomic host upgrade`.

Corresponding image media for new installations can be downloaded from:

https://getfedora.org/en/atomic/download/

Alternatively, image artifacts can be found at the following links:
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190708.0/AtomicHost/aarch64/images/Fedora-AtomicHost-29-20190708.0.aarch64.qcow2
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190708.0/AtomicHost/aarch64/images/Fedora-AtomicHost-29-20190708.0.aarch64.raw.xz
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190708.0/AtomicHost/aarch64/iso/Fedora-AtomicHost-ostree-aarch64-29-20190708.0.iso
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190708.0/AtomicHost/ppc64le/images/Fedora-AtomicHost-29-20190708.0.ppc64le.qcow2
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190708.0/AtomicHost/ppc64le/images/Fedora-AtomicHost-29-20190708.0.ppc64le.raw.xz
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190708.0/AtomicHost/ppc64le/iso/Fedora-AtomicHost-ostree-ppc64le-29-20190708.0.iso
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190708.0/AtomicHost/x86_64/images/Fedora-AtomicHost-29-20190708.0.x86_64.qcow2
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190708.0/AtomicHost/x86_64/images/Fedora-AtomicHost-29-20190708.0.x86_64.raw.xz
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190708.0/AtomicHost/x86_64/images/Fedora-AtomicHost-Vagrant-29-20190708.0.x86_64.vagrant-libvirt.box
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190708.0/AtomicHost/x86_64/images/Fedora-AtomicHost-Vagrant-29-20190708.0.x86_64.vagrant-virtualbox.box
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190708.0/AtomicHost/x86_64/iso/Fedora-AtomicHost-ostree-x86_64-29-20190708.0.iso

Respective signed CHECKSUM files can be found here:
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190708.0/AtomicHost/aarch64/images/Fedora-AtomicHost-29-20190708.0-aarch64-CHECKSUM
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190708.0/AtomicHost/aarch64/iso/Fedora-AtomicHost-29-20190708.0-aarch64-CHECKSUM
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190708.0/AtomicHost/ppc64le/images/Fedora-AtomicHost-29-20190708.0-ppc64le-CHECKSUM
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190708.0/AtomicHost/ppc64le/iso/Fedora-AtomicHost-29-20190708.0-ppc64le-CHECKSUM
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190708.0/AtomicHost/x86_64/images/Fedora-AtomicHost-29-20190708.0-x86_64-CHECKSUM
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190708.0/AtomicHost/x86_64/iso/Fedora-AtomicHost-29-20190708.0-x86_64-CHECKSUM

For direct download, the "latest" targets are always available here:
x86_64:
https://getfedora.org/atomic_qcow2_x86_64_latest
https://getfedora.org/atomic_raw_x86_64_latest
https://getfedora.org/atomic_vagrant_libvirt_x86_64_latest
https://getfedora.org/atomic_vagrant_virtualbox_x86_64_latest
https://getfedora.org/atomic_dvd_ostree_x86_64_latest

aarch64:
https://getfedora.org/atomic_qcow2_aarch64_latest
https://getfedora.org/atomic_raw_aarch64_latest
https://getfedora.org/atomic_dvd_ostree_aarch64_latest

ppc64le:
https://getfedora.org/atomic_qcow2_ppc64le_latest
https://getfedora.org/atomic_raw_ppc64le_latest
https://getfedora.org/atomic_dvd_ostree_ppc64le_latest

Filename fetching URLs are available here:
x86_64:
https://getfedora.org/atomic_qcow2_x86_64_latest_filename
https://getfedora.org/atomic_raw_x86_64_latest_filename
https://getfedora.org/atomic_vagrant_libvirt_x86_64_latest_filename
https://getfedora.org/atomic_vagrant_virtualbox_x86_64_latest_filename
https://getfedora.org/atomic_dvd_ostree_x86_64_latest_filename

aarch64:
https://getfedora.org/atomic_qcow2_aarch64_latest_filename
https://getfedora.org/atomic_raw_aarch64_latest_filename
https://getfedora.org/atomic_dvd_ostree_aarch64_latest_filename

ppc64le:
https://getfedora.org/atomic_qcow2_ppc64le_latest_filename
https://getfedora.org/atomic_raw_ppc64le_latest_filename
https://getfedora.org/atomic_dvd_ostree_ppc64le_latest_filenam

Re: Fedora 31 Self-Contained Change proposal: Qt Wayland By Default on Gnome

[John Florian]

On 2019-06-28 18:28, Kevin Kofler wrote:

Quoting from the proposal:

Qt Wayland plugin has been available for a long time, but it hasn't
been in condition where it could be enabled by default. With Qt 5.12
the state of the Wayland plugin is much better and it's becoming more
and more reliable. It now supports all the needed protocols

Actually, the primary selection protocol (middle-click paste) is only
supported in Qt ≥ 5.14 (not released yet). (It also requires a compositor
implementing the final specification. I'm not sure whether GNOME Shell
already moved from the GNOME private version to the upstreamed version of
the protocol.)



Along these lines, what's the status of Plasma on Wayland?  Any idea 
when this might become the default way of running Plasma on Fedora?

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Plan: Update virtualenv to 16.6 and drop Python 2.6 and Jython support

[Miro Hrončok]

Just a heads up that I plan to do $subject in upcoming week in rawhide.

Let me know if I should not.

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 31 System-Wide Change proposal: Modify Fedora 31 to use CgroupsV2 by default

[Daniel Walsh]

On 7/8/19 11:00 AM, Neal Gompa wrote:
> On Mon, Jul 8, 2019 at 10:39 AM Daniel Walsh  wrote:
>> Their has not been much progress on runc development for this, which
>> might be a blocker.
>>
>> In the Podman/Buildah world, we have support for crun, an alternate OCI
>> Runtime replacement for runc.  crun supports cgroupsv2.
>>
>> There has been little movement in Kubernetes and OpenShift for adding
>> this support, but there has also been little incentive, since no OS Has
>> moved to it.
>>
>> Can systemd turn on the cgroupsv2 by default in Rawhide, to see what
>> complaints happen.
> I would be shocked if Fedora having it switched on would matter. We
> don't have a recent version of OpenShift or Kubernetes in our
> repositories...
>
It will also break Moby-Engine and Docker-ce.
> --
> 真実はいつも一つ！/ Always, there's only one truth!
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Nvidia GPU overclocking in Fedora Silverblue 30 is currently broken

[Ty Young]

Bug filed: https://bugzilla.rpmfusion.org/show_bug.cgi?id=5307

The driver itself seems perfectly fine in that the system boots and OpenGL
works perfectly fine. Games are playable.

How do I output strace to a file directly? It spits out way too much info.

The bug is reproducible by doing a fresh install on a new downloaded ISO
but really the likelihood that this is a bug caused by Nvidia is slim to
none. Arch Linux(what I primarily use) has the same driver version and
everything works perfectly fine.

Regardless of whether or not this specific bug was by a packaging issue or
Nvidia, the way Fedora packages the Nvidia drivers is bad:

-nvidia-smi isn't specific to CUDA and is a core Nvidia library interface
that should come with the base driver as it does in Windows.
-nvidia-settings is the Linux alternative to Window's control panel and if
not included by default, *should* be included via a "meta" package for
desktop users.
-OpenGL not packaged with the driver(or again, installable via a meta
package)? Who wants a graphics driver without OpenGL/Vulkan support?
-it isn't clear if the command I posted(above) installs the 32-bit
libraries or not. Really, meta packages would go a long way in simplifying
GPU driver installs!

Neither Windows nor even other Linux distros fragment the driver this much.
You'd have to add 32-bit libraries alongside the 64 bit driver and 64 bit
libraries to equal Fedora's fragmented driver packaging in some distros.
Why?


On Mon, Jul 8, 2019 at 10:37 AM Nicolas Chauvet  wrote:

> Le lun. 8 juil. 2019 à 16:30, Ty Young  a écrit :
> >
> > Hi,
> >
> >
> > To whoever is packaging the Nvidia GPU driver in Fedora / RPM Fusion,
> > overclocking support is currently broken. Not even nvidia-settings is
> > able to set a GPU core offset value via GUI despite a correct coolbits
> > value being set. This use to work some updates ago. Wayland is not being
> > used.
> >
> >
> > Command used to install the driver and related utils:
> >
> >
> > rpm-ostree install kmod-nvidia xorg-x11-drv-nvidia
> > xorg-x11-drv-nvidia-libs nvidia-settings nvidia-xconfig
> > xorg-x11-drv-nvidia-cuda xorg-x11-drv-nvidia-cuda-libs
> >
> >
> > Attempting to set an overclocking value via command line just results in
> > an "unknown error" message. nvidia-settings doesn't even know what's
> > going on in Fedora Silverblue 30.
> >
> >
> > Can this please be looked into & fixed?
>
> Not yet, you need to provide more useful info as stated in the RPM Fusion
> wiki
> https://rpmfusion.org/Howto/NVIDIA#Bug_Report
>
> Once we can determine the driver is in good state, a strace log of
> nvidia-settings would be useful.
> Please report to bugzilla.rpmfusion.org for now, but if it's
> reproducible and not related to packaging, you will have to forward to
> nvidia directly.
>
> Thx
>
> --
> -
>
> Nicolas (kwizart)
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Orphaning moby-engine (Docker)

[Daniel Walsh]

On 7/3/19 6:50 PM, Stephen John Smoogen wrote:
>
>
> On Wed, 3 Jul 2019 at 17:15, Robert-André Mauchin  > wrote:
>
> On Wednesday, 3 July 2019 19:56:47 CEST David Michael wrote:
> > I have orphaned moby-engine, the community Docker package in Fedora,
> > due to no longer working in a role where I can maintain it as
> part of
> > the job.  If anyone wants to take it, it is up to date in F30 and
> > rawhide branches (F29 was not updated for compatibility since it
> > doesn't enable SELinux), but there is an open issue that should be
> > addressed before pushing new updates:  Docker 18.09 and later
> > conflicts with runc and containerd since it dropped "docker-"
> prefixes
> > from its binaries.  I can describe some options and backstory if
> > needed, but I suppose you could address it however you want as
> the new
> > maintainer.
> >
> > Thanks.
> >
> > David
>
>
> Wasn't there a « Container team » taking care of those packages?
>
>
> And there was a "Cloud team" and a "Server team" and a... there is no
> promise that said teams will last for any longer than the last
> interested person on it. 

Correct the Container Engine team is concentrating on Podman, Skopeo,
Buildah and CRI-O, as replacements of Docker.  We originally helped get
Moby Engine into Fedora, but need volunteers for ongoing maintenance.

>  
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> 
> To unsubscribe send an email to
> devel-le...@lists.fedoraproject.org
> 
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines:
> https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
>
>
> -- 
> Stephen J Smoogen.
>
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Orphaned packages need new maintainers

[Fabio Valentini]

On Mon, Jul 8, 2019 at 5:35 PM Miro Hrončok  wrote:

> The following packages are orphaned and will be retired when they
> are orphaned for six weeks, unless someone adopts them. If you know for
> sure
> that the package should be retired, please do so now with a proper reason:
> https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life
>
> Note: If you received this mail directly you (co)maintain one of the
> affected
> packages or a package that depends on one. Please adopt the affected
> package or
> retire your depending package to avoid broken dependencies, otherwise your
> package will be retired when the affected package gets retired.
>
> Request package ownership via https://pagure.io/releng/issues
>
> Find the full report at
> https://churchyard.fedorapeople.org/orphans-2019-07-08.txt
> (grep for your FAS username and follow the dependencies)
>
>
>   Package  (co)maintainers Status
> Change
>
> ===
> aeshgil, lef, orphan  4 weeks
> ago
> bean-validation-api gil, lef, orphan  4 weeks
> ago
> cdi-api1gil, orphan   4 weeks
> ago
> cmdtest orphan6 weeks
> ago
> concurrent  orphan4 weeks
> ago
> containers  orphan1 weeks
> ago
> cookcc  gil, lef, orphan  4 weeks
> ago
> cookxml orphan4 weeks
> ago
> crypto-utilsjorton, orphan5 weeks
> ago
> csvcat  orphan3 weeks
> ago
> cxf-build-utils gil, lef, orphan  4 weeks
> ago
> cxf-xjc-utils   gil, lef, orphan  4 weeks
> ago
> derby   orphan1 weeks
> ago
> derelictcicku, kalev, orphan  1 weeks
> ago
> dreampiecicku, orphan 3 weeks
> ago
> dsymbol orphan1 weeks
> ago
> dustmitecicku, kalev, orphan  1 weeks
> ago
> dvb-appsorphan, pbrobinson0 weeks
> ago
> earth-and-moon-backgrounds  orphan1 weeks
> ago
> faience-icon-theme  orphan3 weeks
> ago
> fedocal infra-sig, orphan 4 weeks
> ago
> felix-configadmin   orphan4 weeks
> ago
> flr orphan6 weeks
> ago
> gcomprisjwrdegoede, limb, orphan  1 weeks
> ago
> genbackupdata   orphan6 weeks
> ago
> gl3ncicku, kalev, orphan  1 weeks
> ago
> gnome-shell-extension-simple-dock   orphan3 weeks
> ago
> gnumed-server   orphan6 weeks
> ago
> gscribble   orphan6 weeks
> ago
> hibernate-commons-annotations   gil, lef, orphan  4 weeks
> ago
> hibernate-hql   gil, lef, orphan  4 weeks
> ago
> hibernate-searchgil, lef, orphan  4 weeks
> ago
> hibernate-validator gil, lef, orphan  4 weeks
> ago
> jacorb  gil, lef, orphan  4 weeks
> ago
> jandex  gil, orphan   4 weeks
> ago
> jaxws-jboss-httpserver-httpspi  lef, orphan   4 weeks
> ago
> jaxws-undertow-httpspi  gil, lef, orphan  4 weeks
> ago
> jberet  gil, lef, orphan  4 weeks
> ago
> jboss-annotations-1.1-api   orphan4 weeks
> ago
> jboss-classfilewriter   gil, lef, orphan  4 weeks
> ago
> jboss-common-core   gil, lef, orphan  4 weeks
> ago
> jboss-dmr   gil, lef, orphan  4 weeks
> ago
> jboss-ejb-3.1-api   orphan4 weeks
> ago
> jboss-el-3.0-apigil, lef, orphan  4 weeks
> ago
> jboss-httpserverorphan4 weeks
> ago
> jboss-iiop-client   lef, orphan   4 weeks
> ago
> jboss-integration   lef, orphan   4 weeks
> ago
> jboss-interceptors-1.1-api  orphan4 weeks
> ago
> jboss-invoca

Orphaned packages need new maintainers

[Miro Hrončok]

The following packages are orphaned and will be retired when they
are orphaned for six weeks, unless someone adopts them. If you know for sure
that the package should be retired, please do so now with a proper reason:
https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life

Note: If you received this mail directly you (co)maintain one of the affected
packages or a package that depends on one. Please adopt the affected package or
retire your depending package to avoid broken dependencies, otherwise your
package will be retired when the affected package gets retired.

Request package ownership via https://pagure.io/releng/issues

Find the full report at
https://churchyard.fedorapeople.org/orphans-2019-07-08.txt
(grep for your FAS username and follow the dependencies)


 Package  (co)maintainers Status Change
===
aeshgil, lef, orphan  4 weeks ago
bean-validation-api gil, lef, orphan  4 weeks ago
cdi-api1gil, orphan   4 weeks ago
cmdtest orphan6 weeks ago
concurrent  orphan4 weeks ago
containers  orphan1 weeks ago
cookcc  gil, lef, orphan  4 weeks ago
cookxml orphan4 weeks ago
crypto-utilsjorton, orphan5 weeks ago
csvcat  orphan3 weeks ago
cxf-build-utils gil, lef, orphan  4 weeks ago
cxf-xjc-utils   gil, lef, orphan  4 weeks ago
derby   orphan1 weeks ago
derelictcicku, kalev, orphan  1 weeks ago
dreampiecicku, orphan 3 weeks ago
dsymbol orphan1 weeks ago
dustmitecicku, kalev, orphan  1 weeks ago
dvb-appsorphan, pbrobinson0 weeks ago
earth-and-moon-backgrounds  orphan1 weeks ago
faience-icon-theme  orphan3 weeks ago
fedocal infra-sig, orphan 4 weeks ago
felix-configadmin   orphan4 weeks ago
flr orphan6 weeks ago
gcomprisjwrdegoede, limb, orphan  1 weeks ago
genbackupdata   orphan6 weeks ago
gl3ncicku, kalev, orphan  1 weeks ago
gnome-shell-extension-simple-dock   orphan3 weeks ago
gnumed-server   orphan6 weeks ago
gscribble   orphan6 weeks ago
hibernate-commons-annotations   gil, lef, orphan  4 weeks ago
hibernate-hql   gil, lef, orphan  4 weeks ago
hibernate-searchgil, lef, orphan  4 weeks ago
hibernate-validator gil, lef, orphan  4 weeks ago
jacorb  gil, lef, orphan  4 weeks ago
jandex  gil, orphan   4 weeks ago
jaxws-jboss-httpserver-httpspi  lef, orphan   4 weeks ago
jaxws-undertow-httpspi  gil, lef, orphan  4 weeks ago
jberet  gil, lef, orphan  4 weeks ago
jboss-annotations-1.1-api   orphan4 weeks ago
jboss-classfilewriter   gil, lef, orphan  4 weeks ago
jboss-common-core   gil, lef, orphan  4 weeks ago
jboss-dmr   gil, lef, orphan  4 weeks ago
jboss-ejb-3.1-api   orphan4 weeks ago
jboss-el-3.0-apigil, lef, orphan  4 weeks ago
jboss-httpserverorphan4 weeks ago
jboss-iiop-client   lef, orphan   4 weeks ago
jboss-integration   lef, orphan   4 weeks ago
jboss-interceptors-1.1-api  orphan4 weeks ago
jboss-invocationgil, lef, orphan  4 weeks ago
jboss-jacc-1.5-api  lef, orphan   4 weeks ago
jboss-jaxb-intros   lef, orphan   4 weeks ago
jboss-jaxrpc-1.1-apigil, orphan   4 

Re: Fedora Data Engineering SIG: interested in a Fedora SIG to work on this?

[Gerald Henriksen]

On Fri, 5 Jul 2019 11:23:06 +0800, you wrote:

>I think documentation alone is not enough to make things easy, as to make
>the software better integrate with Fedora would require some more
>additional work (eg: systemd integration, quick painless installation,
>prebuilt binaries) ..
>
>What about docker images, or vendor-rpm, or automated install scripts
>approach?. Would that work?.

Not if it goes against what the users expect, as it doesn't matter if
your solution is superior if it is too different than what the
community expects / is used to.

Speaking generalities.

My position has evolved, and I have now taken the position that if a
language (like Python) has a built in infrastructure for package
installation I no longer install any Fedora packages beyond the basics
(ie the compiler/interpreter).

Whether it is good or bad, it is no longer worth fighting those
communities and instead I follow their "best practices" and use their
package systems.

You obviously can decide otherwise.

But based on the above, my advice is to see how the communities
operate and find out how best to make Fedora work for those
communities.  

For example, anything that uses the JVM it is likely the only thing
that will install from Fedora is OpenJDK - the communities built
around Java will not use distribution packaged versions of the
software, preferring to install via direct downloads or Maven.

Similiarly with Python, every blog post, video, or book states to do
"pip install ..." and it doesn't matter if an RPM is better integrated
into Fedora as few will go against the community.

Obviously there are exceptions, like anything written in C where they
don't (yet) have their own packaging system and so that stuff likely
should be packaged.

Which comes back to my original post suggesting documentation, as it
isn't so much about making things easy as just making the vast
majority of potential users aware that there are other Linux
alternatives other than say Ubuntu, which seems to dominate that
existing mindset of blog posts and other documentation.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 31 System-Wide Change proposal: Modify Fedora 31 to use CgroupsV2 by default

[Neal Gompa]

On Mon, Jul 8, 2019 at 10:39 AM Daniel Walsh  wrote:
>
> Their has not been much progress on runc development for this, which
> might be a blocker.
>
> In the Podman/Buildah world, we have support for crun, an alternate OCI
> Runtime replacement for runc.  crun supports cgroupsv2.
>
> There has been little movement in Kubernetes and OpenShift for adding
> this support, but there has also been little incentive, since no OS Has
> moved to it.
>
> Can systemd turn on the cgroupsv2 by default in Rawhide, to see what
> complaints happen.

I would be shocked if Fedora having it switched on would matter. We
don't have a recent version of OpenShift or Kubernetes in our
repositories...


--
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Nvidia GPU overclocking in Fedora Silverblue 30 is currently broken

[Nicolas Chauvet]

Le lun. 8 juil. 2019 à 16:30, Ty Young  a écrit :
>
> Hi,
>
>
> To whoever is packaging the Nvidia GPU driver in Fedora / RPM Fusion,
> overclocking support is currently broken. Not even nvidia-settings is
> able to set a GPU core offset value via GUI despite a correct coolbits
> value being set. This use to work some updates ago. Wayland is not being
> used.
>
>
> Command used to install the driver and related utils:
>
>
> rpm-ostree install kmod-nvidia xorg-x11-drv-nvidia
> xorg-x11-drv-nvidia-libs nvidia-settings nvidia-xconfig
> xorg-x11-drv-nvidia-cuda xorg-x11-drv-nvidia-cuda-libs
>
>
> Attempting to set an overclocking value via command line just results in
> an "unknown error" message. nvidia-settings doesn't even know what's
> going on in Fedora Silverblue 30.
>
>
> Can this please be looked into & fixed?

Not yet, you need to provide more useful info as stated in the RPM Fusion wiki
https://rpmfusion.org/Howto/NVIDIA#Bug_Report

Once we can determine the driver is in good state, a strace log of
nvidia-settings would be useful.
Please report to bugzilla.rpmfusion.org for now, but if it's
reproducible and not related to packaging, you will have to forward to
nvidia directly.

Thx

-- 
-

Nicolas (kwizart)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Interest in doing Fedora CI with test subpackages

[Neil Horman]

On Mon, Jul 08, 2019 at 02:17:44PM +0200, Vít Ondruch wrote:
> I am skeptical about this proposal. While this might work for your
> package, I am afraid it won't work generally and trying to do something
> like this is wasted energy. Let me explain.
> 
well, that may be fair, but when you way it "won't work generally", I could
paraphrase that to say "it may not be sufficient for all packages".  I would
make the argument that the implication is that, for some subset of packages,
this approach works quite well.  That is in fact, the case for all the packages
I maintain.

> When RubyGems were designed in 2004, TDD, BDD and testing in general was
> becoming good practice. Therefore they decided that it is good idea to
> ship code together with its test suite and also execute the tests during
> installation. So you were supposed to be able to run something like "gem
> install -t foo". But it proven to be problematic. Generally this "-t"
> option never worked and could be used just for the most naive test
> suites. So the option was removed [1]. Nowadays, more and more gem
> packages does not ship their tests suites and even the support for
> shipping the test suites is deprecated [2].
> 
Ok, that seems like a fair conclusion to draw from your experience, but it is by
no means the only experience.  I currently maintain:
cscope
irqbalance
rng-tools
dropwatch
rstp

and a few others, all of which have very mature test suites embedded into their
soruce code.  For these pacakages, being able to run their test code in the CI
environment would be very helpful to me (and I think, by extension), others who
have simmilarly constructed packages.
 
> If you want to understand how complex it might be to run the test suite
> of some packages, I welcome you to explore the %check sections of
> rubygem- packages. Some are simple, but most are not that simple,
> starting with small differences as load path, ending with test suites
> which needs to run various servers or check against cloud services. Not
> mentioning test matrices.
> 
I do run make check and part of an rpm %check script on most of these, and if
the consensus is that that approach is sufficient for CI purposes, so be it
(that would in fact be much easier for me).  But its my understanding that there
is a desire to move all our testing to a CI pipeline (or perhaps it would be
beter to say that we wish to add CI to all our packages), and running the
included self tests with an upstream source tree within the CI pipeline is
dificult at best (owing to the lack of source availability in the CI
environment), nor is running a %check script during a build an available trigger
to clear gating during CI, hence my desire to find a way to make my included
selftests from the source tree available in CI via -test rpm subpackages.

> Also, for all these tests we usually try to simulate the environment as
> similar as possible to upstream repository, because this is how these
> test suites are designed. It would be even harder to execute the test
> suites against installed packages.
> 
Unless you were able to extract the test suite into a separate package, install
it in the environment, and run it, while pointing to the installed binaries that
you are trying to test :)

Neil

> 
> Vít
> 
> 
> [1]
> https://github.com/rubygems/rubygems/commit/429f883210f8b2b38ea310f7fc6636cd0e456d5c
> 
> [2] https://github.com/rubygems/rubygems/issues/735
> 
> 
> Dne 05. 07. 19 v 19:49 Neil Horman napsal(a):
> > Hey all-
> > I was starting to setup CI for one of my packages in Fedora (cscope),
> > which requires that I have access to the sources to run my test (cscope 
> > uses its
> > own source tree to search for various symbols to confirm that its working
> > properly).  Getting the sources in the CI environment is a bit of a pain, 
> > so I
> > started working on trying to do this by creating a test subpackage 
> > (specifically
> > named -citest) to package up the sources solely for the purpose of getting 
> > them
> > installed and available during CI runs.  It occured to me that this offers
> > several advantages, among them:
> > 1) the ability to codify dependencies within the ame spec file, rather than
> > having to copy them to the test.yml file, and keep them in sync
> >
> > 2) The ability to use a file format (rpm spec files) that I'm more familiar 
> > with
> >
> > 3) Easy access to tests that are embedded in the source tree
> >
> > 4) minimizing the test harness setup in test.yml
> >
> > For anyone interested, I've got a pull request started here:
> > https://src.fedoraproject.org/rpms/cscope/pull-request/2
> >
> > If anyone wants to take a look at the changes I had to make to do this (fair
> > warning, its still very rough).
> >
> > That all said, I was wondering if perhaps there was general interest in 
> > making
> > this kind of test model somewhat more formal (i.e. creating an rpm macro 
> > library
> > to make test package generation a bit easier, creating a standard entry 

Re: Fedora 31 System-Wide Change proposal: Modify Fedora 31 to use CgroupsV2 by default

[Daniel Walsh]

On 7/4/19 5:21 AM, Zbigniew Jędrzejewski-Szmek wrote:
> On Wed, Jul 03, 2019 at 04:23:24PM -0400, Ben Cotton wrote:
>> https://fedoraproject.org/wiki/Changes/CGroupsV2
>>
>> == Summary ==
>> The kernel has had some support for CgroupsV2 for some time, and yet
>> no one has used it because it is not on by default.  There are lots of
>> new features and fixes over CgroupsV1 that it is time to reveal to the
>> user community.
>>
>> == Owner ==
>> * Name: [[User:dwalsh| Daniel J Walsh]]
>> * Email: 
>>
>>
>> == Detailed Description ==
>> Enablement of the CgroupsV2 by default will allow tools like systemd,
>> container tools and libvirt to take advantage of the new features and
>> many fixes in Cgroups V1.  A lot of the functionality in VGroups V1
>> has been rewritten to fix fundamental flaws in its design.
>>
>> The reason CGroupsV2 by default has been blocked is that the Container
>> tools and someone the Virtualization tools did not have support.  We
>> believe that the time is right to try to move these tools along to
>> take advantage of this kernel feature. In order to begin testing these
>> features more widely we believe we need to have a platform like
>> Rawhide to test on and get others to test as well.
>>
>> The main features of CgroupsV2 we would like to take advantage of in
>> the container world is delegation of cgroup hierarchies.   Allowing
>> tools like podman to be able to use CGroups in rootless mode, would be
>> a large advance.
>>
>>
>> == Benefit to Fedora ==
>> Fedora is known for being a leading platform for the enablement of new
>> kernel functions, and this would continue its legacy.  The world will
>> eventually move to CGroupsV2 and Fedora should lead the way.
>>
>> == Scope ==
>> * Proposal owners:
>> The largest changes required to make this Change is to get containers
>> runtimes like RUNC to work with the change.  After RUNC has support
>> for CgroupsV2 we need to move container engines like Podman, CRI-o,
>> Buildah and Moby into support CgroupsV2.
>>
>> * Other developers:
>> We need to find other tools that have built the CGroupsV1 API into
>> themselves and get them to support CGroupsV2.
>>
>> Known packages:
>>
>> - libvirt: The team is already working on this.
>>
>> -  JVM:  Uses Cgroups file system to check for allocated memory for
>> the JVM, will have to use and understand the CgroupV2 mechanism to
>> discover these sessings.
>>
>> - Snap package does not run with CGroupV2:
>> https://bugzilla.redhat.com/show_bug.cgi?id=1438079
>>
>> - Systemd will need to be modified to set the new default to cgroupv2
>>
>> * Release engineering: [https://pagure.io/releng/issue/8509 #8509]
>> * Policies and guidelines:
>> * Trademark approval: N/A (not needed for this Change)
>>
>>
>> == Upgrade/compatibility impact ==
>> Any tools or scripts that an administrator used to manually configure
>> the CGroupsV1 will have to be modified to CGroupsV2.  Luckily if these
>> tools took advantage of systemd interfaces they should not require
>> changes.
>>
>> == How To Test ==
>> Make sure different tools that use cgroups continue to work when
>> booted into the new system.  Make sure containers, virtual machines
>> and the Jave Virtual Machine still work properly.  Convert the VM's of
>> the Container tools like CRI-O, Buildah, Podman for run on Rawhide and
>> make sure their test suites completely pass.  Will request that the
>> libvirt team and JVM teams similarly change their test platforms.
> Actually it's enough to set 'systemd.unified-cgroup-hierarchy' on the
> kernel command line to test. I think this should be mentioned, so
> people can test already in F29 or F30 or rawhide before the default is
> changed.
>
>> == User Experience ==
>> We believe that at this point their will be no or very little user
>> experience change, unless he is an administrator looking to modify the
>> system Cgroups using the cgroupsfs.
>>
>> One potential problem will be container images that expect to be
>> running in a CgroupV1 environment.  Some container engines leak the
>> Cgroup Hierarchy into containers so that tools within the container
>> can look at how much memory the cgroup gives them for example.  These
>> tools might break with the change, but they should be adjusted quickly
>> over time, and I don't really see a way to avoid this.
>>
>> == Dependencies ==
>> Currently there are no known changes to the package requirements for
>> this change.
>>
>> == Contingency Plan ==
>> * Contingency mechanism: If the container tools and virtualization
>> tools do not work at beta and do not look like they will be ready for
>> beta freeze, then we revert to CgroupsV1 and try again in Fedora 32
>> * Contingency deadline: Beta Freeze
>> * Blocks release? Yes
> We know that cgroupv2 already (and for a long time...) works better
> than v1, so I'd rather make the switch unconditional, using the usual
> phrasing of "In the unlikely case catastrophic problems are discovered
> with v2, the default will be reverted t

Nvidia GPU overclocking in Fedora Silverblue 30 is currently broken

[Ty Young]

Hi,


To whoever is packaging the Nvidia GPU driver in Fedora / RPM Fusion, 
overclocking support is currently broken. Not even nvidia-settings is 
able to set a GPU core offset value via GUI despite a correct coolbits 
value being set. This use to work some updates ago. Wayland is not being 
used.



Command used to install the driver and related utils:


rpm-ostree install kmod-nvidia xorg-x11-drv-nvidia 
xorg-x11-drv-nvidia-libs nvidia-settings nvidia-xconfig 
xorg-x11-drv-nvidia-cuda xorg-x11-drv-nvidia-cuda-libs



Attempting to set an overclocking value via command line just results in 
an "unknown error" message. nvidia-settings doesn't even know what's 
going on in Fedora Silverblue 30.



Can this please be looked into & fixed?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: rpmlint: library-not-linked-against-libc (parts of Python stdlib, after gcc 9)

[Florian Weimer]

* Pavel Valena:

> - Original Message -
>> From: "Florian Weimer" 
>> To: "Pavel Valena" 
>> Cc: devel@lists.fedoraproject.org
>> Sent: Tuesday, May 14, 2019 10:47:41 AM
>> Subject: Re: rpmlint: library-not-linked-against-libc (parts of Python 
>> stdlib, after gcc 9)
>> 
>> * Pavel Valena:
>> 
>> > The same occurs with Ruby:
>> > https://src.fedoraproject.org/rpms/ruby/pull-request/44
>> 
>> I'm not sure if this is a false positive.  I checked fcntl.so, and it
>> references __cxa_finalize, as a weak symbol, so it needs to be linked
>> against libc.so.6, for ABI stability.
>> 
>> Can you figure out the linker command line?  It could be a binutils bug
>> in the implementation of --as-needed.
>
> From Ruby build(rawhide):
> https://da.gd/jBhE6
> https://copr.fedorainfracloud.org/coprs/pvalena/ruby/build/887856/
>
> ```
>* LDFLAGS: -L. -Wl,-z,relro -Wl,--as-needed  -Wl,-z,now \
>   -specs=/usr/lib/rpm/redhat/redhat-hardened-ld \
>   -fstack-protector-strong -rdynamic \
>   -Wl,-export-dynamic
>* DLDFLAGS:-Wl,-z,relro -Wl,--as-needed  -Wl,-z,now \
>   -specs=/usr/lib/rpm/redhat/redhat-hardened-ld
> ```
>
> The full command is:
> ```
> gcc -shared -o ../../.ext/x86_64-linux/fcntl.so fcntl.o -L. -L../.. -L. 
> -Wl,-z,relro -Wl,--as-needed  -Wl,-z,now 
> -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -fstack-protector-strong 
> -rdynamic -Wl,-export-dynamic -Wl,-z,relro -Wl,--as-needed  -Wl,-z,now 
> -specs=/usr/lib/rpm/redhat/redhat-hardened-ld  -m64  -lruby  -lm   -lc
> ```
> 
>
>
> Wich is different from F29(same SRPM; result linked correctly):
> ```
>* LDFLAGS: -L. -Wl,-z,relro   -Wl,-z,now \
>   -specs=/usr/lib/rpm/redhat/redhat-hardened-ld \
>   -fstack-protector-strong -rdynamic \
>   -Wl,-export-dynamic
>* DLDFLAGS:-Wl,-z,relro   -Wl,-z,now \
>   -specs=/usr/lib/rpm/redhat/redhat-hardened-ld
> ```
> ```
> gcc -shared -o ../../.ext/x86_64-linux/fcntl.so fcntl.o -L. -L../.. -L. 
> -Wl,-z,relro   -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld 
> -fstack-protector-strong -rdynamic -Wl,-export-dynamic -Wl,-z,relro   
> -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld  -m64  -lruby  -lm   
> -lc
> ```

Yes, it's due to the --as-needed change.  Problems like this one are
expected.  The ELF tooling certainly needs to be updated for this change.

Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: rpmlint: shared-lib-without-dependency-information (parts of Python stdlib)

[Florian Weimer]

* Miro Hrončok:

> On 05. 02. 19 19:04, Miro Hrončok wrote:
>> I've just spotted these when working on Python 3.8.0a1. This happens
>> on 3.7 as well since GCC 9:
>>
>> python3-debug.x86_64: E: library-not-linked-against-libc
>> /usr/lib64/python3.7/lib-dynload/_contextvars.cpython-37dm-x86_64-linux-gnu.so
>> python3-debug.x86_64: E: library-not-linked-against-libc
>> /usr/lib64/python3.7/lib-dynload/_testimportmultiple.cpython-37dm-x86_64-linux-gnu.so
>>  
>>
>> python3-libs.x86_64: E: library-not-linked-against-libc
>> /usr/lib64/python3.7/lib-dynload/_contextvars.cpython-37m-x86_64-linux-gnu.so
>> python3-test.x86_64: E: library-not-linked-against-libc
>> /usr/lib64/python3.7/lib-dynload/_testimportmultiple.cpython-37m-x86_64-linux-gnu.so
>>  
>>
>>
>> (Note that there are plenty of other extension modules that do not
>> raise this error.)
>>
>> This doesn't happen with latest python3 built prior to the gcc update to 9.
>>
>> $ rpmlint -I library-not-linked-against-libc
>> library-not-linked-against-libc:
>>
>> That isn't helpful either.
>>
>> I found a similar Debian thing [1] that says:
>>
>>  > It is theoretically possible to have a library which doesn't use any 
>> symbols
>>  > from libc...
>>
>> Do I care? Should I fix something? I honestly have no idea.
>>
>> [1] https://lintian.debian.org/tags/library-not-linked-against-libc.html
>
>
> We have new errors on F30+:
>
> python38.x86_64: E: shared-lib-without-dependency-information
> /usr/lib64/python3.8/lib-dynload/_contextvars.cpython-38-x86_64-linux-gnu.so
> python38.x86_64: E: shared-lib-without-dependency-information
> /usr/lib64/python3.8/lib-dynload/_heapq.cpython-38-x86_64-linux-gnu.so
> python38.x86_64: E: shared-lib-without-dependency-information
> /usr/lib64/python3.8/lib-dynload/_testimportmultiple.cpython-38-x86_64-linux-gnu.so
> python38.x86_64: E: shared-lib-without-dependency-information
> /usr/lib64/python3.8/lib-dynload/_testinternalcapi.cpython-38-x86_64-linux-gnu.so
>
> rpmlint doesn't give much info:
> $ rpmlint -I shared-lib-without-dependency-information
> shared-lib-without-dependency-information:
>
>
> But lintian again explains the issue:
> https://lintian.debian.org/tags/shared-lib-without-dependency-information.html
>
> The listed shared library doesn't include information about which
> other libraries the library was linked against. (When running "ldd
> foo.so" ldd should report about these other libraries. In your case,
> ldd just reports "statically linked".)
>
> I again think this is OK for Python extension modules.
> Thoughts?

It depends on the extension module.  For _contextvars, it's okay because
it does not link against anything (glibc or otherwise).  Global C++
destructors will not work because of unfulfilled weak reference to
__cxa_finalize, but you probably do not care about that.

rpmlint really should have a list of symbols from system libraries that
need linking, otherwise there's always going to be false positives for
such plugins.  (Although extension modules could link against libpython
on Fedora because Fedora doesn't use the fat Python interpreter, unlike
some other distributions.)

Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Character limit for spec file summary?

[Brian (bex) Exelbierd]

I created a PR https://pagure.io/packaging-committee/pull-request/912
to try and make these things clearer when the text is read.  Feedback
desired and welcome.

regards,

bex

On Mon, Jul 8, 2019 at 2:15 PM Petr Pisar  wrote:
>
> On 2019-07-06, Richard Shaw  wrote:
> > Is there an actual limit or guideline on the character length of the
> > summary tag?
> >
> > I can't seem to find anything one way or the other.
> >
> rpmlint reports an error on a summary longer than 80 characters.
>
> -- Petr
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org



-- 
Brian "bex" Exelbierd (he/him/his)
Fedora Community Action & Impact Coordinator
@bexelbie | http://www.winglemeyer.org
bexel...@redhat.com | b...@pobox.com
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Interest in doing Fedora CI with test subpackages

[Vít Ondruch]

I am skeptical about this proposal. While this might work for your
package, I am afraid it won't work generally and trying to do something
like this is wasted energy. Let me explain.

When RubyGems were designed in 2004, TDD, BDD and testing in general was
becoming good practice. Therefore they decided that it is good idea to
ship code together with its test suite and also execute the tests during
installation. So you were supposed to be able to run something like "gem
install -t foo". But it proven to be problematic. Generally this "-t"
option never worked and could be used just for the most naive test
suites. So the option was removed [1]. Nowadays, more and more gem
packages does not ship their tests suites and even the support for
shipping the test suites is deprecated [2].

If you want to understand how complex it might be to run the test suite
of some packages, I welcome you to explore the %check sections of
rubygem- packages. Some are simple, but most are not that simple,
starting with small differences as load path, ending with test suites
which needs to run various servers or check against cloud services. Not
mentioning test matrices.

Also, for all these tests we usually try to simulate the environment as
similar as possible to upstream repository, because this is how these
test suites are designed. It would be even harder to execute the test
suites against installed packages.


Vít


[1]
https://github.com/rubygems/rubygems/commit/429f883210f8b2b38ea310f7fc6636cd0e456d5c

[2] https://github.com/rubygems/rubygems/issues/735


Dne 05. 07. 19 v 19:49 Neil Horman napsal(a):
> Hey all-
>   I was starting to setup CI for one of my packages in Fedora (cscope),
> which requires that I have access to the sources to run my test (cscope uses 
> its
> own source tree to search for various symbols to confirm that its working
> properly).  Getting the sources in the CI environment is a bit of a pain, so I
> started working on trying to do this by creating a test subpackage 
> (specifically
> named -citest) to package up the sources solely for the purpose of getting 
> them
> installed and available during CI runs.  It occured to me that this offers
> several advantages, among them:
> 1) the ability to codify dependencies within the ame spec file, rather than
> having to copy them to the test.yml file, and keep them in sync
>
> 2) The ability to use a file format (rpm spec files) that I'm more familiar 
> with
>
> 3) Easy access to tests that are embedded in the source tree
>
> 4) minimizing the test harness setup in test.yml
>
> For anyone interested, I've got a pull request started here:
> https://src.fedoraproject.org/rpms/cscope/pull-request/2
>
> If anyone wants to take a look at the changes I had to make to do this (fair
> warning, its still very rough).
>
> That all said, I was wondering if perhaps there was general interest in making
> this kind of test model somewhat more formal (i.e. creating an rpm macro 
> library
> to make test package generation a bit easier, creating a standard entry point 
> to
> run tests, etc).  
>
> Thoughts welcome
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Character limit for spec file summary?

[Petr Pisar]

On 2019-07-06, Richard Shaw  wrote:
> Is there an actual limit or guideline on the character length of the
> summary tag?
>
> I can't seem to find anything one way or the other.
>
rpmlint reports an error on a summary longer than 80 characters.

-- Petr
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: MPFR 4

[James Paul Turner]

On Sat, 2019-07-06 at 17:58 -0600, Jerry James wrote:
> On Sat, Jul 6, 2019 at 1:55 PM Jakub Jelinek 
> wrote:
> > There is no way around having some compatibility version, either in
> > the same
> > or other rpm, at least for a short period of time, because gcc
> > needs libmpfr
> > and libmpfr needs to be built with gcc, so if you upgrade
> > incompatibly
> > libmpfr, you will build that package, but once it is in the
> > buildroots, gcc
> > will not install anymore and so nothing that needs gcc to build
> > will
> > succeed building.
> 
> Right.  I think James's question was about submitting a package for
> review that is a different version of a package owned by somebody
> else.  The maintainer of record for mpfr is Pavel Cahyna.  I see he
> has an mpfr COPR:
> 
> https://copr.fedorainfracloud.org/coprs/pcahyna/mpfr4/
> 
> but it looks like it hasn't been touched in a long time.  This is
> what
> fedora-active-user has to say about him:
> 
> Last login in FAS:
>pcahyna 2019-05-16
> Last action on koji:
>Fri, 11 Aug 2017 package list entry revoked: zisofs-tools in f25
> by pkgdb
> Last package update on bodhi:
>2018-02-25 21:51:52 on package mpfr-3.1.6-1.fc27
> Last actions performed according to fedmsg:
>   - joerg.schill...@fokus.fraunhofer.de updated nothing on
> RHBZ#1648742 'wodim should not pretend to handle DL-DV...' on
> 2019-07-04 08:29:55 ()
>   - ekan...@rcn.com updated nothing on RHBZ#1648742 'wodim should not
> pretend to handle DL-DV...' on 2019-07-04 08:06:42 ()
>   - r...@htt-consult.com updated nothing on RHBZ#1583845 'Cannot write
> to CDrom at all' on 2019-06-27 10:22:24 ()
>   - joerg.schill...@fokus.fraunhofer.de updated nothing on
> RHBZ#1648742 'wodim should not pretend to handle DL-DV...' on
> 2019-06-26 06:21:01 ()
>   - ekan...@rcn.com updated 'cc' on RHBZ#1648742 'wodim should not
> pretend to handle DL-DV...' on 2019-06-26 06:02:22 ()
>   - pdu...@gmx.com updated 'cc' on RHBZ#1457252 'gnuplot-5.2.7 is
> available' on 2019-06-09 12:07:09 ()
>   - ke...@tigcc.ticalc.org updated 'cc' on RHBZ#1583845 'Cannot write
> to CDrom at all' on 2019-06-05 14:27:05 ()
>   - ke...@tigcc.ticalc.org updated 'cc' on RHBZ#1583845 'Cannot write
> to CDrom at all' on 2019-06-05 14:19:32 ()
>   - ke...@tigcc.ticalc.org updated 'cc', 'dup_id', and 'resolution'
> on
> RHBZ#1580021 'wodim missing u+s will prevent usage at ...' on
> 2019-06-05 14:19:32 ()
>   - upstream-release-monitoring updated 'short_desc' on RHBZ#1457252
> 'gnuplot-5.2.7 is available' on 2019-05-29 01:05:26 ()
> Last email on mailing list:
> ERROR:active-user:[Errno socket error] [Errno -2] Name or service not
> known
> 
> Hmmm, what happened with the email on mailing list check?
> 
> The current mpfr library (3.1.6) has soname "libmpfr.so.4".  The new
> mpfr library (4.0.2) has soname "libmpfr.so.6".  We want to keep both
> sonames available until all consumers can be switched to mpfr4, which
> may take awhile.
> 
> We are not changing versions of libmpc, so the soname of
> "libmpc.so.3"
> is fixed.  Therefore, we have to have the following packages, and
> their -devel subpackages, and it has to be possible to have them all
> installed in the same buildroot:
> - mpfr 3.1.6
> - mpfr 4.0.2
> - libmpc 1.1.0 linked with mpfr 3.1.6
> - libmpc 1.1.0 linked with mpfr 4.0.2
> 
> I think it would be nice to have the "mpfr" package mean the latest
> version (i.e., 4.0.2), and introduce an mpfr3 package to hold 3.1.6.
> Likewise, it would be nice to have the "libmpc" package mean the
> version linked with mpfr 4.0.2, and introduce something, say
> "libmpc-mpfr3", to hold the version linked with mpfr 3.1.6.  I can be
> swayed otherwise, but that would let us preserve package history, and
> we can hopefully drop the mpfr3 and libmpc-mpfr3 packages from the
> distribution someday.
> 
> The tricky part, of course, is not breaking gcc while updating.  Here
> is one way that could be accomplished.  Caveat: I haven't actually
> tried doing this.  If this seems reasonable, I would like to create a
> COPR and start doing these builds to make sure nothing breaks.
> - Alter the mpfr package to produce mpfr3, mpfr3-devel, mpfr, and
> mpfr-devel
>   packages.  The mpfr3 library has the old soname, the mpfr library
> has the new
>   soname.  The -devel packages must be installable in parallel, so
> the mpfr3
>   packages have libmpfr3.so*, /usr/include/mpfr3.h, and
>   /usr/include/mpf2mpfr3.h.
> - Alter the libmpc package to produce libmpc and libmpc-mpfr3
> packages.  The
>   libmpc package keeps the current soname.  The libmpc-mpfr3 package
> gets the
>   soname “libmpc-mpfr3.so.3”.  Both are linked against mpfr3!  That’s
> important!
>   The -devel packages must be installable in parallel, so the libmpc-
> mpfr3
>   packages have libmpc-mpfr3.so* and /usr/include/mpc-mpfr3.h.
> - Build gcc with mpfr3 and libmpc-mpfr3.  This means that gcc no
> longer depends
>   on the mpfr and libmpc packages, so we can change them without
> breaking gcc

Re: Review swaps

[Jakub Jelen]

On Sat, 2019-07-06 at 21:01 -0600, Jerry James wrote:
> I'm working on getting some optional dependencies of sagemath into
> Fedora.  All of these should be fairly simple reviews.  Let me know
> what I can review for you in exchange.
> 
> gap-pkg-happrime: https://bugzilla.redhat.com/show_bug.cgi?id=1723997
> coxeter: https://bugzilla.redhat.com/show_bug.cgi?id=1727498
> gap-pkg-forms: https://bugzilla.redhat.com/show_bug.cgi?id=1727499
> gap-pkg-hecke: https://bugzilla.redhat.com/show_bug.cgi?id=1727500
> gap-pkg-profiling: 
> https://bugzilla.redhat.com/show_bug.cgi?id=1727501
> mcqd: https://bugzilla.redhat.com/show_bug.cgi?id=1727502

I will take some of them. So far, I took the last one.

Can you do me a review of the following one:

pcsc-lite-acsccid: https://bugzilla.redhat.com/show_bug.cgi?id=1725840

Thank you,
-- 
Jakub Jelen
Senior Software Engineer
Security Technologies
Red Hat, Inc.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: New Go Packaging Guidelines landed in rawhide (koji) today

[Nicolas Mailhot via devel]

Le 2019-07-08 09:06, Jakub Cajka a écrit :

- Original Message -

From: "Nicolas Mailhot via devel" 
To: "Christophe de Dinechin" , "Development 
discussions related to Fedora"


Cc: "Robin Lee" , "nicolas mailhot" 


Sent: Saturday, July 6, 2019 8:39:12 AM
Subject: Re: New Go Packaging Guidelines landed in rawhide (koji) 
today


Le vendredi 05 juillet 2019 à 16:33 +0200, Christophe de Dinechin a
écrit :
>
> Also, would anybody mind if I add a note on the guideline page
> stating
> that this is from F31 on, since the go-rpm-macros package does not
> exist before. Unless there is a plan to create branches for earlier
> releases?

It could be done for previous releases, if someone was motivated
enough. The macro code itself works, with trivial adjustments, on
ancient releases like EL7. But, it depends on things in redhat-rpm-
config, so backporting would demand to convince redhat-rpm-config
maintainers to backport too.

Anyway this is pretty academic right now, I doubt anyone would accept 
a

backport without synchronized backport of the whole Go packageset, and
that can not happen before eclipso finishes to update the stack in
devel.



You have omitted that the new macros stack is not fully backwards
compatible, so it would require more work on fixing the packages that
are affected by the breakage(AFAIK a bit under ~100). IMHO it is not a
good idea to back-port this to any stable Fedora release.


That’s why I wrote that a macro backport, without the mass spec cleanup 
& fixing eclipseo is doing in devel right now, would not be a good idea. 
(fixing a clean spec to use the new macro stack takes a couple of 
minutes; fixing the warts that accumulated in Fedora for years because 
the tooling was not there is something else entirely)


--
Nicolas Mailhot
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

libgweather soname bump

[Kalev Lember]

A quick heads up that I'm building libgweather 3.33.0 update for rawhide
that bumps the library soname with minor ABI changes.  I'll kick off
rebuilds for all dependent packages.

Kalev
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: New Go Packaging Guidelines landed in rawhide (koji) today

[Jakub Cajka]

- Original Message -
> From: "Nicolas Mailhot via devel" 
> To: "Christophe de Dinechin" , "Development discussions 
> related to Fedora"
> 
> Cc: "Robin Lee" , "nicolas mailhot" 
> 
> Sent: Saturday, July 6, 2019 8:39:12 AM
> Subject: Re: New Go Packaging Guidelines landed in rawhide (koji) today
> 
> Le vendredi 05 juillet 2019 à 16:33 +0200, Christophe de Dinechin a
> écrit :
> > 
> > Also, would anybody mind if I add a note on the guideline page
> > stating
> > that this is from F31 on, since the go-rpm-macros package does not
> > exist before. Unless there is a plan to create branches for earlier
> > releases?
> 
> It could be done for previous releases, if someone was motivated
> enough. The macro code itself works, with trivial adjustments, on
> ancient releases like EL7. But, it depends on things in redhat-rpm-
> config, so backporting would demand to convince redhat-rpm-config
> maintainers to backport too.
> 
> Anyway this is pretty academic right now, I doubt anyone would accept a
> backport without synchronized backport of the whole Go packageset, and
> that can not happen before eclipso finishes to update the stack in
> devel.
> 
> Regards,
> 
> --
> Nicolas Mailhot

You have omitted that the new macros stack is not fully backwards compatible, 
so it would require more work on fixing the packages that are affected by the 
breakage(AFAIK a bit under ~100). IMHO it is not a good idea to back-port this 
to any stable Fedora release.

JC

> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org