search

rockowitz / ddcutil

Control monitor settings using DDC/CI and USB
http://www.ddcutil.com
GNU General Public License v2.0
989 stars 42 forks source link

[COPR] Multiple build with same version will cause issues #142

Open Crote opened 4 years ago

Crote commented 4 years ago

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:

rockowitz commented 4 years ago

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 <version epoch="0" ver="0.9.9" rel="1.fc32"/> <checksum type="sha256" pkgid="YES">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
rockowitz commented 4 years ago

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:

Applications based on PackageKit:

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/-appstream.xml. Currently, the appstream.xml file for ddcutil is essentially empty. It's not clear to me what information needs to be specified, and how, in order to create the necessary AppStream files within COPR.

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 <version epoch="0" ver="0.9.9" rel="1.fc32"/> <checksum type="sha256" pkgid="YES">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
Crote commented 4 years ago

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?

rockowitz commented 4 years ago

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.

Crote commented 4 years ago

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

It doesn't show up in search, but it does show up as an update.

rockowitz commented 4 years ago

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.