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 comparing PROVIDES @@ -47,6 +47,7 @@ libXxf86vm.so.1()(64bit) 16384 mimehandler(application/adrift) 32768 mimehandler(application/annodex) 32768 +mimehandler(application/flac) 32768 mimehandler(application/ogg) 32768 mimehandler(application/playerpro) 32768 mimehandler(application/smil) 32768 @@ -83,7 +84,6 @@ mimehandler(audio/x-it) 32768 mimehandler(audio/xm) 32768 mimehandler(audio/x-mod) 32768 -mimehandler(audio/x-mp3) 32768 mimehandler(audio/x-mpeg2) 32768 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 /usr/bin/xine-list-1.2
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; if XINE_LIST -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: https://build.opensuse.org/package/show/home:plater/xine-ui and https://pmbs.links2linux.de/package/show/home:davepl/xine-ui 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 https://build.opensuse.org/package/live_build_log/multimedia:xine/xine-ui/openSUSE_Factory/x86_64 https://build.opensuse.org/package/live_build_log/multimedia:xine/xine-ui/openSUSE_Factory/i586 https://build.opensuse.org/package/live_build_log/multimedia:xine/xine-ui/openSUSE_Leap_42.3/x86_64 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 [general] 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