We have an iRedMail installation here that was originally on CentOS, migrated in January to Rocky 8.4 then eventually 8.5. We run dnf upgrade on a regular basis, which has worked for ages.
Yesterday, a number of sope components were listed (among others) to upgrade, but the downloads for these sope packages failed to download with 404 errors. Today, the sope packages (not certain they’re exactly the same version numbers) fail with bad checksums.
[MIRROR] sope49-appserver-4.9-20220311_1664.el8.1.1.x86_64.rpm: Downloading successful, but checksum doesn't match. Calculated: 758717f70514b55a5744dedc22bc49d0527b484c714a857f0f31eaa92b923c61(sha256) Expected: b4e0e57738cafc2ef5a991844f230508f5f7f57f48840e14b173d1fe1bdc5d9c(sha256)
(same for
sope49-core-4.9-20220311_1664.el8.1.1.x86_64.rpm
sope49-appserver-4.9-20220311_1664.el8.1.1.x86_64.rpm
)
I think I understand the technical issues here – unless something somewhere has been hacked and the failure is correctly identifying tampering – but I don’t know where to report this.
My question is about the roles and chain of responsibilities in this process. Do the sope people add new versions to the repos? Or the repo people get them from sope? Do the product developers (iRedMail) have any role in this?
Thanks for all help,
Paul
I would suggest running a dnf clean all and trying your update again. If you get the same errors, it’ll be an issue on the repository maintainers that manage sope49 or other packages that deal with your software. You would need to report it to those who maintain the repository you get the packages from. Most repositories will have email, github, or some form of a bug tracker.
When it comes to software to this, it depends on the libraries and how the developers of the application operate. Since sope is part of SOGo, it would make sense that sope may get updated at specific moments for compatibility or for some new version of their overall software. For example, if SOGo 5.5.1 is released, it stands to reason that SOPE 5.5.1 is also released at the same time. Since I do not have access to their repositories, I’m not able to see how their software versions work, only their release tags in github. iRedMail and SOGo are two different products that can run together. It is likely they are not related to each other developer wise.
This may be a better question for those who make the software/packages/repositories.
1 Like
Thanks for this, it’s already a big help.
I had run dnf clean packages already, but forgot to mention it. Now I’ve run dnf clean all, but the result is the same.
There are sogo packages listed as requiring updating too; but unlike sope, they are downloaded correctly.
I hadn’t considered the question of which repository is involved. I didn’t add any new (non-default) ones, but perhaps the iRedMail install added some.
I will investigate and report back.
I always suspected this was a lot more complex under the hood than it appeared on the surface. 
Here are the installed repos (all enabled):
SOGo Inverse SOGo Repository
appstream Rocky Linux 8 - AppStream
baseos Rocky Linux 8 - BaseOS
epel Extra Packages for Enterprise Linux 8 - x86_64
epel-modular Extra Packages for Enterprise Linux Modular 8 - x86_64
extras Rocky Linux 8 - Extras
iRedMail iRedMail
Here’s the info on SOGo:
Last metadata expiration check: 0:46:44 ago on Sun 13 Mar 2022 01:06:15 PM EDT.
Installed Packages
Name : sogo
Version : 5.5.1.20220305
Release : 1.el8
Architecture : x86_64
Size : 55 M
Source : sogo-5.5.1.20220305-1.el8.src.rpm
Repository : @System
From repo : SOGo
Summary : SOGo
URL : https://sogo.nu/
License : GPL
Description : SOGo is a groupware server built around OpenGroupware.org (OGo) and
: the SOPE application server. It focuses on scalability.
:
: The Inverse edition of this project has many feature enhancements:
: - CalDAV and GroupDAV compliance
: - full handling of vCard as well as vCalendar/iCalendar formats
: - support for folder sharing and ACLs
:
: The Web interface has been rewritten in an AJAX fashion to provided a faster
: UI for the users, consistency in look and feel with the Mozilla applications,
: and to reduce the load of the transactions on the server.
Available Packages
Name : sogo
Version : 5.5.1.20220313
Release : 1.el8
Architecture : x86_64
Size : 20 M
Source : sogo-5.5.1.20220313-1.el8.src.rpm
Repository : SOGo
Summary : SOGo
URL : https://sogo.nu/
License : GPL
Description : SOGo is a groupware server built around OpenGroupware.org (OGo) and
: the SOPE application server. It focuses on scalability.
:
: The Inverse edition of this project has many feature enhancements:
: - CalDAV and GroupDAV compliance
: - full handling of vCard as well as vCalendar/iCalendar formats
: - support for folder sharing and ACLs
:
: The Web interface has been rewritten in an AJAX fashion to provided a faster
: UI for the users, consistency in look and feel with the Mozilla applications,
: and to reduce the load of the transactions on the server.
What isn’t clear is why the installed package says Repository: @System, but the Available Package says Repository: SOGo
Does this mean I have a package conflict being provided in two competing ways?
Edit: or does it mean the installed one is in @system but there’s an available one in SOGo?
When was the current sogo installed?
rpm -qi sogo
sudo dnf history list sogo
IIRC, the packages installed initially (by installer) do not show “regular repoids” in dnf list.
1 Like
18 months ago. But bear in mind that although SOGo is the main package, it is not the one that’s failing with a bad checksum (that being three sope packages that are part of SOGo)
ID | Command line | Date and time | Action(s) | Altered
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
56 | upgrade | 2022-03-05 15:31 | Upgrade | 18
55 | upgrade | 2022-02-15 10:51 | Upgrade | 14
54 | upgrade | 2022-02-14 13:50 | Upgrade | 6
53 | upgrade | 2022-02-09 09:24 | Upgrade | 7
52 | upgrade | 2022-02-08 10:33 | Upgrade | 42 E<
50 | upgrade | 2022-01-28 10:14 | Upgrade | 14 >
49 | upgrade | 2022-01-27 09:41 | ?, E, I, U | 38 EE
48 | upgrade | 2022-01-06 17:07 | Upgrade | 14 <
45 | upgrade | 2022-01-02 15:45 | ?, E, I, U | 17 >
44 | upgrade | 2021-12-30 10:03 | Upgrade | 6
43 | upgrade | 2021-12-29 11:42 | Upgrade | 6
42 | upgrade | 2021-12-24 10:23 | Upgrade | 6
41 | upgrade | 2021-12-23 13:38 | Upgrade | 25 EE
40 | upgrade | 2021-12-20 16:53 | Upgrade | 19
39 | upgrade | 2021-12-12 09:55 | Upgrade | 6
38 | upgrade | 2021-12-11 21:58 | E, I, U | 382 EE
37 | upgrade | 2021-10-31 10:50 | Upgrade | 15
36 | upgrade | 2021-10-24 09:49 | Upgrade | 64 EE
35 | upgrade | 2021-09-18 12:37 | E, I, U | 36 EE
34 | upgrade | 2021-08-21 11:25 | Upgrade | 14
33 | | 2021-08-18 12:30 | Upgrade | 6
32 | upgrade | 2021-08-17 20:40 | E, I, U | 76 EE
31 | upgrade | 2021-07-27 08:26 | E, I, U | 25 EE
30 | upgrade | 2021-07-01 09:07 | E, I, O, U | 409 E<
27 | update sogo* *sope* | 2021-06-03 15:22 | Upgrade | 14 >
26 | upgrade | 2021-05-02 15:17 | E, I, U | 61 EE
25 | update | 2021-04-04 18:13 | Upgrade | 23 <
23 | upgrade | 2021-03-28 13:40 | E, I, U | 38 >E
22 | upgrade | 2021-03-01 19:44 | Upgrade | 28 EE
21 | upgrade | 2021-02-02 19:24 | E, I, U | 24 EE
20 | upgrade | 2021-01-13 11:20 | Upgrade | 58 EE
19 | upgrade | 2020-12-27 16:24 | E, I, O, U | 363 E<
17 | upgrade | 2020-12-05 14:56 | Upgrade | 6 >
16 | upgrade | 2020-12-03 21:16 | E, I, U | 37 E<
13 | upgrade | 2020-10-03 13:51 | Upgrade | 6 >
12 | upgrade | 2020-09-29 10:00 | Upgrade | 14
11 | upgrade | 2020-09-24 11:01 | Upgrade | 6
10 | | 2020-09-21 10:14 | I, U | 40 <
8 | -d 2 -y --disablerepo=rpmforge,ius,remi,atrpms install rsyslog firewalld postfix postfix-pcre postfix-mysql mariadb mariadb-server perl-DBD-MySQL php-cli php-common p | 2020-09-16 11:22 | Install | 255 >E
Here’s the same command on sope49-appserver, one of the failing packages:
[root@engels ~]# dnf history list sope49-appserver
ID | Command line | Date and time | Action(s) | Altered
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
56 | upgrade | 2022-03-05 15:31 | Upgrade | 18
55 | upgrade | 2022-02-15 10:51 | Upgrade | 14 <
52 | upgrade | 2022-02-08 10:33 | Upgrade | 42 ><
50 | upgrade | 2022-01-28 10:14 | Upgrade | 14 >
49 | upgrade | 2022-01-27 09:41 | ?, E, I, U | 38 EE
48 | upgrade | 2022-01-06 17:07 | Upgrade | 14 <
40 | upgrade | 2021-12-20 16:53 | Upgrade | 19 ><
38 | upgrade | 2021-12-11 21:58 | E, I, U | 382 >E
37 | upgrade | 2021-10-31 10:50 | Upgrade | 15
36 | upgrade | 2021-10-24 09:49 | Upgrade | 64 EE
35 | upgrade | 2021-09-18 12:37 | E, I, U | 36 EE
34 | upgrade | 2021-08-21 11:25 | Upgrade | 14 <
32 | upgrade | 2021-08-17 20:40 | E, I, U | 76 ><
30 | upgrade | 2021-07-01 09:07 | E, I, O, U | 409 ><
27 | update sogo* *sope* | 2021-06-03 15:22 | Upgrade | 14 >
26 | upgrade | 2021-05-02 15:17 | E, I, U | 61 EE
25 | update | 2021-04-04 18:13 | Upgrade | 23 <
23 | upgrade | 2021-03-28 13:40 | E, I, U | 38 >E
22 | upgrade | 2021-03-01 19:44 | Upgrade | 28 E<
16 | upgrade | 2020-12-03 21:16 | E, I, U | 37 ><
12 | upgrade | 2020-09-29 10:00 | Upgrade | 14 ><
8 | -d 2 -y --disablerepo=rpmforge,ius,remi,atrpms install rsyslog firewalld postfix postfix-pcre postfix-mysql mariadb mariadb-server perl-DBD-MySQL php-cli php-common php-fpm php-gd php-xml php-mysq | 2020-09-16 11:22 | Install | 255 >E
What I think (but not authoritatively know):
The @ means “it is installed”.
@System is kind of a pseudo repo.
That means the package comes from the repo SOGo and is installed.
Note that output from dnf info differs from the presentation from dnf list which would tell you most probably @sogo.
The problem has now resolved itself (all packages now download correctly). I suspect somebody managing the SOGo repo corrected whatever the issue was.