Hi Gerald, On Wed, 2020-04-22 at 18:32 +0200, Gerald Pfeifer wrote:
On Sun 2020-04-19, Dominique Leuenberger wrote:
The full online repo contains too many changes to be listed here.
I noticed the following as part of this
libreoffice 6.4.3.2-1.1 -> 6.4.3.2-1.2 libreoffice-branding-upstream 6.4.3.2-1.1 -> 6.4.3.2-1.2 libreoffice-calc 6.4.3.2-1.1 -> 6.4.3.2-1.2 libreoffice-draw 6.4.3.2-1.1 -> 6.4.3.2-1.2 libreoffice-filters-optional 6.4.3.2-1.1 -> 6.4.3.2-1.2 libreoffice-gnome 6.4.3.2-1.1 -> 6.4.3.2-1.2 libreoffice-gtk3 6.4.3.2-1.1 -> 6.4.3.2-1.2 libreoffice-icon-themes 6.4.3.2-1.1 -> 6.4.3.2-1.2 libreoffice-impress 6.4.3.2-1.1 -> 6.4.3.2-1.2 libreoffice-l10n-de 6.4.3.2-1.1 -> 6.4.3.2-1.2 libreoffice-l10n-en 6.4.3.2-1.1 -> 6.4.3.2-1.2 libreoffice-mailmerge 6.4.3.2-1.1 -> 6.4.3.2-1.2 libreoffice-math 6.4.3.2-1.1 -> 6.4.3.2-1.2 libreoffice-pyuno 6.4.3.2-1.1 -> 6.4.3.2-1.2 libreoffice-writer 6.4.3.2-1.1 -> 6.4.3.2-1.2 libreofficekit 6.4.3.2-1.1 -> 6.4.3.2-1.2
where I had doubts that libreoffice-icon-themes and libreoffice-l10n-en, for example, really changed.
All those packages actually come out of a single source package - so they always stay in sync with the version/release counters. As we can already see from the version-release (version = 6.4.3.2, release old 1.1, release new 1.2) is that this is 'only' a rebuild (not source change). The release is built from CheckinCount (1) and BuildCount (1, then 2)
And, hold and below, yesterday another update, to 6.4.3.2-1.3.
and sorry: next snapshot 0422 will come with a rebuild again! At the moment I seem to see too many 'random' failures on OBS workers. We already have a bug to track slowdowns on some workers, they might be related.
At 36.6 MiB and 54.4MiB, respectively, those are significant.
Now I got curious and compared the situation before/after such an update using sha5sum and a little script, and ... of all those downloads only a single package brought different contents: the main libreoffice package.
Is there a way to avoid such "empty" updates?
well, it's not empty (there is a change in some of the packages) - If there were 0 diff, build-compare should catch it. So, the questions are: * why did we trigger a rebuild (from what I see to recover a build fail on i586) * Why did build-compare not consider the builds as identical. Looking at rebuild 4 that I have the current logs for, I see diffs like this: [17243s] Extracting packages [17244s] /usr/lib64/libreoffice/share/extensions/nlpsolver/help/af/help.idxl/segments_3 differs at offset '9' (data) [17244s] --- /dev/fd/63 2020-04-22 04:46:20.904000000 +0000 [17244s] +++ /dev/fd/62 2020-04-22 04:46:20.904000000 +0000 [17244s] @@ -1,4 +1,4 @@ [17244s] -00000000 ff ff ff fc 00 00 01 71 8a ff ce 5d 00 00 00 01 |.......q...]....| [17244s] +00000000 ff ff ff fc 00 00 01 71 9f 8f 46 c2 00 00 00 01 |.......q..F.....| [17244s] 00000010 00 00 00 01 02 5f 30 00 00 00 02 ff ff ff ff ff |....._0.........| [17244s] 00000020 ff ff ff ff ff ff ff 01 ff ff ff ff 01 |.............| [17244s] 0000002d Build-comapre though only considers 'the whole thing' - so all packages are identical, the build is discarded, one difference in one subpackage found: all must be published (think about Requires FOO = %{version}-%{release}; this construct would break otherwise) Interestingly, LO is not in the list of non-reproducible packages as per the latest monthly reports by Bernhard (compare https://lists.opensuse.org/opensuse-factory/2020-04/msg00026.html). So it makes it a bit worse to identify why we now have 4 rebuilds (differing) since the last checkin of LO on April 13 - maybe reproducibly got broken. Tomas might know more / have a fix. Cheers, Dominique