Bugzilla – Bug 1110339
xine-lib xine-list-1.2 randomly missing entries
Last modified: 2020-05-04 07:27:05 UTC
While working on reproducible builds for openSUSE, I found that
the xine-ui package differed between builds, even when trying to make them as similar as possible.
Maybe part of the build rootfs layout makes an influence.
This results in diffs like
@@ -47,6 +47,7 @@
@@ -83,7 +84,6 @@
This is parsed from /usr/share/applications/xine.desktop
(that differs in the same way but has everything in one line)
The .desktop file is produced by
Both xine-ui and xine-lib are Debian maintained, there must be a patch somewhere.
I'm assuming that it isn't xine-list-1.2 that is changing with every build. I found a patch from the end of January lurking in my local build directory called reproducible.patch it had one change in misc/desktops/Makefile.am :
--- misc/desktops/Makefile.am.orig 2017-12-28 18:34:15.000000000 +0200
+++ misc/desktops/Makefile.am 2018-10-03 12:25:03.678527099 +0200
@@ -30,7 +30,7 @@ desktop_DATA = xine.desktop
INPUT_MIME_TYPES = x-content/audio-cdda;x-content/video-dvd;x-content/video-svcd;x-content/video-vcd;
-xine.desktop: xine.desktop.in @XINE_LIST@
+xine.desktop: xine.desktop.in @XINE_LIST@;
$(AM_V_GEN)cat $< > $@; \
@XINE_LIST@ | perl -ne 'print join(";",sort(split(";")))' >> $@; \
echo ';$(INPUT_MIME_TYPES)' >> $@
Don't know if the ; semicolon could cause this.
You can find builds in:
but I've removed the SUSE specific crippling code because mpeg2video is no longer patent encumbered.
I've tested this locally and can't get a difference.
I've also found 3 xine.desktopx files in my obs xine-ui directory that are identical to the one produced by home:davepl (Packman) xine-ui so I think that I fixed this long ago and something big distracted me.
I now also had difficulty reproducing this bug, but it is still there.
It seems to be just 1 bit of entropy,
so there is a 50% chance to get 2 identical builds.
I found that you need to use
osc build --clean --noservice --vm-type=kvm
to get a new roll of the dice and a 50% chance for a different result.
You can check which of the 2 possible results you got with
rpm -qp --provides RPMS/xine-ui-0.99.10-*.x86_64.rpm|
grep -e application/flac -e audio/x-mp3
The semicolon patch does not make a difference there.
The official builds at
differ in the same way, when you look at
the build-compare output at the end of the log.
All this really indicates that the randomness comes from the build-root filesystem because without kvm or without clean it remains the same fs
Make sure to give kvm enough memory - have in your ~/.oscrc
build-memory = 2048
In strace I can see
openat(AT_FDCWD, "/usr/lib64/xine/plugins/2.7", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 3
openat(AT_FDCWD, "/usr/lib64/xine/plugins/2.7/post", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 4
so it is listing files in these directories
and the order varies by filesystem.
The | perl -ne 'print join(";",sort(split(";")))'
that I added to xine-ui earlier did hide most of the problems,
but it seems not all.
xine-list should really process entries in deterministic order.
Sorry I forgot about this bug. I think it's resolved. I had libxine2-1.2.9 installed and made 3 files from xine-list and then updated to current 1.2.10 then made another 3 xine-list files. The 1.2.9 files were all identical as were the 1.2.10 ones and as might have been expected the 1.2.9 and 1.2.10 files differed.
Judging by the bug's last modified date this bug was against 1.2.9.
The plugin abi looks like it has changed to 2.8
Is this fixed, reopen if it's not