ddcutil
ddcutil copied to clipboard
rockowitz
[COPR] Multiple build with same version will cause issues
I know this is a bit of a long shot, but it never hurts to try!
So, I noticed that ddcutil has multiple builds with exactly the same version number. See, for example, builds 1506802 and 1499738: at least for F32 x86_64, they both built ddcutil-0.9.9-1.fc32.x86_64.rpm.
The problem is that COPR will output both versions in the repo metadata, not just the last one. For example, the current repodata (see here, the file named $checksum-primary.xml.gz contains:
<package type="rpm">
<name>ddcutil</name>
<arch>x86_64</arch>
<version epoch="0" ver="0.9.9" rel="1.fc32"/>
<checksum type="sha256" pkgid="YES">6c530a531ac2c850b36727ecde79ef374a1080c6ece78335a54d80f82822bb7c</checksum>
<summary>Query and update monitor settings</summary>
<description>Query and change monitor settings
ddcutil communicates with monitors implementing MCCS (Monitor Control Command
Set), using either the DDC/CI protocol on the I2C bus or as a Human Interface
Device on USB. In general, anything that can be controlled using a monitor's
on-screen display can be controlled by this program. Examples include
changing a monitor's input source and adjusting its brightness.</description>
<packager></packager>
<url>http://www.ddcutil.com</url>
<time file="1592995344" build="1592995309"/>
<size package="261425" installed="646526" archive="649140"/>
<location href="01499738-ddcutil/ddcutil-0.9.9-1.fc32.x86_64.rpm"/>
<format>
<rpm:license>GPLv2</rpm:license>
<rpm:vendor></rpm:vendor>
<rpm:group>Unspecified</rpm:group>
<rpm:buildhost>ip-172-30-2-96.ec2.internal</rpm:buildhost>
<rpm:sourcerpm>ddcutil-0.9.9-1.fc32.src.rpm</rpm:sourcerpm>
<rpm:header-range start="5096" end="12164"/>
<rpm:provides>
<rpm:entry name="ddcutil" flags="EQ" epoch="0" ver="0.9.9" rel="1.fc32"/>
<rpm:entry name="ddcutil(x86-64)" flags="EQ" epoch="0" ver="0.9.9" rel="1.fc32"/>
</rpm:provides>
<rpm:requires>
<rpm:entry name="i2c-tools"/>
<rpm:entry name="libX11.so.6()(64bit)"/>
<rpm:entry name="libXrandr.so.2()(64bit)"/>
<rpm:entry name="libdrm.so.2()(64bit)"/>
<rpm:entry name="libglib-2.0.so.0()(64bit)"/>
<rpm:entry name="libudev.so.1()(64bit)"/>
<rpm:entry name="libudev.so.1(LIBUDEV_183)(64bit)"/>
<rpm:entry name="rtld(GNU_HASH)"/>
<rpm:entry name="shadow-utils" pre="1"/>
<rpm:entry name="libc.so.6(GLIBC_2.17)(64bit)"/>
</rpm:requires>
<file>/usr/bin/ddcutil</file>
</format>
</package>
<package type="rpm">
<name>ddcutil</name>
<arch>x86_64</arch>
<version epoch="0" ver="0.9.9" rel="1.fc32"/>
<checksum type="sha256" pkgid="YES">85f73decbcc13e0705d5cb341afa8111d23fe01b7a27d777334f5adc0c226ea8</checksum>
<summary>Query and update monitor settings</summary>
<description>Query and change monitor settings
ddcutil communicates with monitors implementing MCCS (Monitor Control Command
Set), using either the DDC/CI protocol on the I2C bus or as a Human Interface
Device on USB. In general, anything that can be controlled using a monitor's
on-screen display can be controlled by this program. Examples include
changing a monitor's input source and adjusting its brightness.</description>
<packager></packager>
<url>http://www.ddcutil.com</url>
<time file="1593261658" build="1593261623"/>
<size package="261427" installed="646526" archive="649140"/>
<location href="01506802-ddcutil/ddcutil-0.9.9-1.fc32.x86_64.rpm"/>
<format>
<rpm:license>GPLv2</rpm:license>
<rpm:vendor></rpm:vendor>
<rpm:group>Unspecified</rpm:group>
<rpm:buildhost>ip-172-30-2-103.ec2.internal</rpm:buildhost>
<rpm:sourcerpm>ddcutil-0.9.9-1.fc32.src.rpm</rpm:sourcerpm>
<rpm:header-range start="5096" end="12168"/>
<rpm:provides>
<rpm:entry name="ddcutil" flags="EQ" epoch="0" ver="0.9.9" rel="1.fc32"/>
<rpm:entry name="ddcutil(x86-64)" flags="EQ" epoch="0" ver="0.9.9" rel="1.fc32"/>
</rpm:provides>
<rpm:requires>
<rpm:entry name="i2c-tools"/>
<rpm:entry name="libX11.so.6()(64bit)"/>
<rpm:entry name="libXrandr.so.2()(64bit)"/>
<rpm:entry name="libdrm.so.2()(64bit)"/>
<rpm:entry name="libglib-2.0.so.0()(64bit)"/>
<rpm:entry name="libudev.so.1()(64bit)"/>
<rpm:entry name="libudev.so.1(LIBUDEV_183)(64bit)"/>
<rpm:entry name="rtld(GNU_HASH)"/>
<rpm:entry name="shadow-utils" pre="1"/>
<rpm:entry name="libc.so.6(GLIBC_2.17)(64bit)"/>
</rpm:requires>
<file>/usr/bin/ddcutil</file>
</format>
</package>
Basically, the same package twice.
As it turns out, some tooling really does not like this. An example is Gnome Software: it is unable to distinguish between them, and as a result updates will fail. That is, not just updating ddcutil, it will fail to update any package on your system.
Furthermore, the COPR Documentation states that "we keep the build with the greatest EPOCH:NAME-VERSION-RELEASE, even though that build might not be the newest one. Also, if there are two builds of the same package version, it is undefined which one is going to be kept."
I know this isn't really an issue you caused - it's more one of COPR itself and Gnome Software - but it's probably a good idea not to re-use version numbers. Would you perhaps be able to avoid this in the future? :smile:
First, thank you for the detailed problem description.
It certainly is possible to bump the release number every time ddcutil
is uploaded to COPR. I'm not sure that entirely addresses the problem
though, as a rebuild can be triggered without any change to the rpm.
Sometimes its a change to the COPR configuration that enables an
additional architecture to build.
I'm afraid this issue is at the edge of my understanding of COPR - the complete solution is not immediately apparent to me. However, I want to at least acknowledge your problem report. It has not gone into the void.
Regards, Sanford
On 08/24/2020 04:02 PM, L. K. Post wrote:
I know this is a bit of a long shot, but it never hurts to try!
So, I noticed that |ddcutil| has multiple builds with exactly the same version number. See, for example, builds 1506802 https://copr.fedorainfracloud.org/coprs/rockowitz/ddcutil/build/1506802/ and 1499738 https://copr.fedorainfracloud.org/coprs/rockowitz/ddcutil/build/1499738/: at least for F32 x86_64, they both built |ddcutil-0.9.9-1.fc32.x86_64.rpm|.
The problem is that COPR will output both versions in the repo metadata, not just the last one. For example, the current repodata (see here https://copr-be.cloud.fedoraproject.org/results/rockowitz/ddcutil/fedora-32-x86_64/repodata/, the file named |$checksum-primary.xml.gz| contains:
|
ddcutil x86_64 6c530a531ac2c850b36727ecde79ef374a1080c6ece78335a54d80f82822bb7c Query and update monitor settings Query and change monitor settings ddcutil communicates with monitors implementing MCCS (Monitor Control Command Set), using either the DDC/CI protocol on the I2C bus or as a Human Interface Device on USB. In general, anything that can be controlled using a monitor's on-screen display can be controlled by this program. Examples include changing a monitor's input source and adjusting its brightness. http://www.ddcutil.com GPLv2 Unspecified ip-172-30-2-96.ec2.internal ddcutil-0.9.9-1.fc32.src.rpm /usr/bin/ddcutil | ddcutil x86_64 85f73decbcc13e0705d5cb341afa8111d23fe01b7a27d777334f5adc0c226ea8 Query and update monitor settings Query and change monitor settings ddcutil communicates with monitors implementing MCCS (Monitor Control Command Set), using either the DDC/CI protocol on the I2C bus or as a Human Interface Device on USB. In general, anything that can be controlled using a monitor's on-screen display can be controlled by this program. Examples include changing a monitor's input source and adjusting its brightness. http://www.ddcutil.com GPLv2 Unspecified ip-172-30-2-103.ec2.internal ddcutil-0.9.9-1.fc32.src.rpm /usr/bin/ddcutil Basically, the same package twice. As it turns out, some tooling really does not like this. An example is Gnome Software: it is unable to distinguish between them, and as a result updates will fail. That is, not just updating |ddcutil|, it will fail to update any package on your system.
Furthermore, the COPR Documentation https://docs.pagure.org/copr.copr/user_documentation.html#how-long-do-you-keep-the-builds states that "we keep the build with the greatest EPOCH:NAME-VERSION-RELEASE, even though that build might not be the newest one. Also, if there are two builds of the same package version, it is undefined which one is going to be kept."
I know this isn't really an issue you caused - it's more one of COPR itself and Gnome Software - but it's probably a good idea not to re-use version numbers. Would you perhaps be able to avoid this in the future? 😄
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/rockowitz/ddcutil/issues/142, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADMGY3XVI2GM3R5652YIG2LSCLBOBANCNFSM4QJ3UUWA.
This issue led me to delve into Fedora packaging. The bottom line is
that gnome-software cannot (at least for now) install ddcutil/ddcui.
Other package management software works. Here are the gory details.
On Fedora there numerous applications, both command line and GUI, that maintain repository data and install/update/remove software. These break down into 2 groups:
dnf/dnfdragora:
- Repository data saved in /var/cache/dnf
Applications based on PackageKit:
- pkcon, gnome-software (Software), gpk-application (Packages), apper (Apper), plasma-discover (Discover)
- Repository data saved in /var/cache/PackageKit
- Alternatively, PackageKit can be configured to use the dnf backend, but that doesn't matter for our purposes.
The repository data downloaded from COPR is the same in both directories.
All the applications other than gnome-software successfully install software from the COPR repository.
gnome-software does not find ddcutil/ddcui. From online posts this appears to be a common problem with packages not in the official repositories.
I didn't observe that a ddcutil repository with multiple builds having the same epoch-version-release prevents gnome-software from updating other software on the system. However, I will ensure that there is only one copy of ddcutil or ddcui in the repository with a given epoch-version-release, and will bump the release number if anything changes in the specfile.
What's different about gnome-software is that it requires AppStream
metadata. (See AppStream-Glib,
https://github.com/hughsie/appstream-glib/blob/master/README.mdAppStream
documentation https://www.freedesktop.org/software/appstream/docs/,
and Wikipedia https://en.wikipedia.org/wiki/AppStream for details.)
The AppStream files for a COPR repository are collected into a file in
repository directory repodata. For COPR this file is named
repodata/
On 08/24/2020 04:02 PM, L. K. Post wrote:
I know this is a bit of a long shot, but it never hurts to try!
So, I noticed that |ddcutil| has multiple builds with exactly the same version number. See, for example, builds 1506802 https://copr.fedorainfracloud.org/coprs/rockowitz/ddcutil/build/1506802/ and 1499738 https://copr.fedorainfracloud.org/coprs/rockowitz/ddcutil/build/1499738/: at least for F32 x86_64, they both built |ddcutil-0.9.9-1.fc32.x86_64.rpm|.
The problem is that COPR will output both versions in the repo metadata, not just the last one. For example, the current repodata (see here https://copr-be.cloud.fedoraproject.org/results/rockowitz/ddcutil/fedora-32-x86_64/repodata/, the file named |$checksum-primary.xml.gz| contains:
|
ddcutil x86_64 6c530a531ac2c850b36727ecde79ef374a1080c6ece78335a54d80f82822bb7c Query and update monitor settings Query and change monitor settings ddcutil communicates with monitors implementing MCCS (Monitor Control Command Set), using either the DDC/CI protocol on the I2C bus or as a Human Interface Device on USB. In general, anything that can be controlled using a monitor's on-screen display can be controlled by this program. Examples include changing a monitor's input source and adjusting its brightness. http://www.ddcutil.com GPLv2 Unspecified ip-172-30-2-96.ec2.internal ddcutil-0.9.9-1.fc32.src.rpm /usr/bin/ddcutil | ddcutil x86_64 85f73decbcc13e0705d5cb341afa8111d23fe01b7a27d777334f5adc0c226ea8 Query and update monitor settings Query and change monitor settings ddcutil communicates with monitors implementing MCCS (Monitor Control Command Set), using either the DDC/CI protocol on the I2C bus or as a Human Interface Device on USB. In general, anything that can be controlled using a monitor's on-screen display can be controlled by this program. Examples include changing a monitor's input source and adjusting its brightness. http://www.ddcutil.com GPLv2 Unspecified ip-172-30-2-103.ec2.internal ddcutil-0.9.9-1.fc32.src.rpm /usr/bin/ddcutil Basically, the same package twice. As it turns out, some tooling really does not like this. An example is Gnome Software: it is unable to distinguish between them, and as a result updates will fail. That is, not just updating |ddcutil|, it will fail to update any package on your system.
Furthermore, the COPR Documentation https://docs.pagure.org/copr.copr/user_documentation.html#how-long-do-you-keep-the-builds states that "we keep the build with the greatest EPOCH:NAME-VERSION-RELEASE, even though that build might not be the newest one. Also, if there are two builds of the same package version, it is undefined which one is going to be kept."
I know this isn't really an issue you caused - it's more one of COPR itself and Gnome Software - but it's probably a good idea not to re-use version numbers. Would you perhaps be able to avoid this in the future? 😄
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/rockowitz/ddcutil/issues/142, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADMGY3XVI2GM3R5652YIG2LSCLBOBANCNFSM4QJ3UUWA.
Hmm, that is very interesting. The weird thing is that my log contains entries like
Aug 22 10:43:28 lkpost-desktop gnome-software[3648]: not handling error failed for action refine: failed to get update details for vlc;1:3.0.11-7.fc32;x86_64;rpmfusion-free-updates: Multiple matches of ddcutil;0.9.9-1.fc32;x86_64;copr:copr.fedorainfracloud.org:rockowitz:ddcutil
Aug 22 10:43:28 lkpost-desktop gnome-software[3648]: not handling error failed for action download: Multiple matches of ddcutil;0.9.9-1.fc32;x86_64;copr:copr.fedorainfracloud.org:rockowitz:ddcutil
Aug 22 23:23:20 lkpost-desktop gnome-software[3648]: not handling error failed for action refine: failed to get update details for akmod-VirtualBox;6.1.12-1.fc32;x86_64;rpmfusion-free-updates: Multiple matches of ddcutil;0.9.9-1.fc32;x86_64;copr:copr.fedorainfracloud.org:rockowitz:ddcutil
So it definitely seems to be aware of it existing. Perhaps my installation of PackageKit uses the dnf backend? It's a standard F32 installation, I don't know what the defaults should be.
I definitely initially installed ddcutil via dnf, and it has no issues whatsoever with the update to 0.9.9.2-2. It seems like AppStream shouldn't be the issue I ran into?
Whether you're using the dnf backend or the PackageKit backend, the same files are downloaded from COPR. They just get stored in different locations.
gnome-software is unique among all the front-ends (dnf, pkcon, etc.) in that it requires metadata in AppStream format. If the metadata does not exist, gnome-software does not show the application. It's out of your hands. I need to create the metadata, which is turning out to be an exercise in yak shaving. (If you don't know the phrase, google it.)
On 08/29/2020 03:05 PM, L. K. Post wrote:
Hmm, that is very interesting. The weird thing is that my log contains entries like
|Aug 22 10:43:28 lkpost-desktop gnome-software[3648]: not handling error failed for action refine: failed to get update details for vlc;1:3.0.11-7.fc32;x86_64;rpmfusion-free-updates: Multiple matches of ddcutil;0.9.9-1.fc32;x86_64;copr:copr.fedorainfracloud.org:rockowitz:ddcutil Aug 22 10:43:28 lkpost-desktop gnome-software[3648]: not handling error failed for action download: Multiple matches of ddcutil;0.9.9-1.fc32;x86_64;copr:copr.fedorainfracloud.org:rockowitz:ddcutil Aug 22 23:23:20 lkpost-desktop gnome-software[3648]: not handling error failed for action refine: failed to get update details for akmod-VirtualBox;6.1.12-1.fc32;x86_64;rpmfusion-free-updates: Multiple matches of ddcutil;0.9.9-1.fc32;x86_64;copr:copr.fedorainfracloud.org:rockowitz:ddcutil |
So it definitely seems to be aware of it existing. Perhaps my installation of PackageKit uses the dnf backend? It's a standard F32 installation, I don't know what the defaults should be.
I definitely initially installed |ddcutil| via |dnf|, and it has no issues whatsoever with the update to |0.9.9.2-2|. It seems like AppStream shouldn't be the issue I ran into?
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/rockowitz/ddcutil/issues/142#issuecomment-683330373, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADMGY3QGB5YL2GQEGX7C6D3SDFGPVANCNFSM4QJ3UUWA.
Heh, I've shaved many a yak myself.
The thing is, GS clearly does know something about it:
It doesn't show up in search, but it does show up as an update.
That is PackageKit's update list. Note that (almost) none of the other packages show up in gnome-software because, like ddcutil, they lack the requisite metadata. Unlike the other PackageKit front ends, it's more of an application manager than a general package manager.
On 08/29/2020 09:08 PM, L. K. Post wrote:
Heh, I've shaved many a yak myself.
The thing is, GS clearly does know /something/ about it: Screenshot from 2020-08-30 03-03-37 https://user-images.githubusercontent.com/931757/91648901-b5c2d180-ea6d-11ea-9f53-e0407b424f65.png
It doesn't show up in search, but it does show up as an update.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/rockowitz/ddcutil/issues/142#issuecomment-683362438, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADMGY3VHIH3BLQF6UDVW26TSDGQ7RANCNFSM4QJ3UUWA.