#10701 epel8-next builds using libusbmuxd-devel fail due to hash change
Closed: Fixed 2 years ago by kevin. Opened 2 years ago by tdawson.

Since the RHEL 8.5 update, packages that build on epel8-next that require libusbmuxd-devel fail with the following error on x86_64
"GenericError: hash changed for external rpm: libusbmuxd-devel-1.0.10-9.el8.x86_64@centos-stream-8 (c9892b7b4d5b560b5e6f7b38d08f4e5c -> ac8d43f837ec66c30576c93cbe2e30c7)"
An example is here:
https://koji.fedoraproject.org/koji/taskinfo?taskID=84279120

  • When do you need this? (YYYY/MM/DD)
    3/18/2022

  • When is this no longer needed or useful? (YYYY/MM/DD)
    N/A

  • If we cannot complete your request, what is the impact?
    We are doing a whole KDE update and rebuild on epel8-next first, and then will rebuild on epel8 when RHEL 8.6 is released. We want to do it in epel8-next first so we can work out all the build and installation issues. As with the last issue this like, this is fairly early on in the build process .
    If this doesn't get fixed we will only be able to do this rebuild on epel8. And given the amount of minor issues we've had, that will slow things down.


Files on batcave look like they have been unchanged since December

-rw-r--r--. 1 root root 35616 2020-12-08 19:49 ./non_modular/libusbmuxd-1.0.10-9.el8.x86_64.rpm
-rw-r--r--. 1 root root 13192 2020-12-08 19:49 ./non_modular/libusbmuxd-devel-1.0.10-9.el8.x86_64.rpm
$ rpm --nosignature --qf='%{SIGMD5}\n' -qp ./non_modular/libusbmuxd-devel-1.0.10-9.el8.x86_64.rpm
ac8d43f837ec66c30576c93cbe2e30c7

This says that the 'updated' signature is correct but the one in koji is wrong. I think this is something we have run into before and needs to be looked at by kojidevs to stop it from happening.

Metadata Update from @mohanboddu:
- Issue tagged with: medium-gain, medium-trouble, ops

2 years ago
    id    | build_id | buildroot_id |       name       | version | release | epoch |  arch   |       
    payloadhash            | size  | buildtime  | external_repo_id | metadata_only | extra 
----------+----------+--------------+------------------+---------+---------+-------+---------+-------
---------------------------+-------+------------+------------------+---------------+-------
 18547012 |          |              | libusbmuxd-devel | 1.0.10  | 9.el8   |       | x86_64  | c9892b
7b4d5b560b5e6f7b38d08f4e5c | 10078 | 1534083720 |               35 | f             | 
 27764888 |          |              | libusbmuxd-devel | 1.0.10  | 9.el8   |       | x86_64  | c9892b
7b4d5b560b5e6f7b38d08f4e5c | 10078 | 1557799201 |               47 | f 

I think this is due to epel8-next inheriting from epel8 and thus the epel8 version of this package.

Metadata Update from @kevin:
- Issue untagged with: medium-gain, medium-trouble, ops

2 years ago

I'm beginning to think doing my build in epel8-next to make sure everything builds and installs correctly isn't going to be worth the hassle.
But I still think it would be good to get this fixed.

the 'easiest' fix would be that EPEL-next doesn't inherit from RHEL-8 but was a 'separate' beast built against stream completely.

I say 'easiest' in the window of 'well look at that we need to build everything twice again'

Metadata Update from @kevin:
- Issue tagged with: high-gain, high-trouble, ops

2 years ago

Due to a wayland version issue, the kde update on epel8-next has been postponed for several months. So this is isn't critical anymore.
But it would be nice to get it fixed so it doesn't just sit here until I need the package again.

From the looks of things, libusbmuxd isn't getting rebuilt on RHEL 8 or CentOS STream 8 anytime soon. So this won't just magically get fixed.

I think this was solved by not keeping all old repos around forever... or was it?

is this still happening? or can we close it?

Is this still happening? Yes.
I did a workaround so it didn't affect me this time.
I think you can close this.
As far as I know, I'm the only one who has been, or will be affected by this. And since I've finished my last KDE build on epel8-next, it won't affect me again either.

Metadata Update from @kevin:
- Issue close_status updated to: Fixed
- Issue status updated to: Closed (was: Open)

2 years ago

Login to comment on this ticket.

Metadata
Boards 1
Ops Status: Backlog