Bug 1110339

Summary: xine-lib xine-list-1.2 randomly missing entries
Product: [openSUSE] openSUSE Tumbleweed Reporter: Bernhard Wiedemann <bwiedemann>
Component: DevelopmentAssignee: Dave Plater <davejplater>
Status: RESOLVED FIXED QA Contact: E-mail List <qa-bugs>
Severity: Normal    
Priority: P5 - None CC: bwiedemann
Version: Current   
Target Milestone: ---   
Hardware: Other   
OS: openSUSE Factory   
Found By: Development Services Priority:
Business Priority: Blocker: ---
Marketing QA Status: --- IT Deployment: ---

Description Bernhard Wiedemann 2018-10-01 13:33:12 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
Comment 1 Dave Plater 2018-10-02 07:45:17 UTC
Both xine-ui and xine-lib are Debian maintained, there must be a patch somewhere.
Comment 2 Dave Plater 2018-10-04 08:26:09 UTC
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.
Comment 3 Bernhard Wiedemann 2018-10-05 04:14:10 UTC
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
Comment 4 Bernhard Wiedemann 2018-10-05 04:27:43 UTC
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.
Comment 5 Dave Plater 2020-05-04 07:27:05 UTC
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