On Fri, May 04, 2018 at 04:00:25PM +0200, Andrea Bolognani wrote: > On Fri, 2018-05-04 at 09:42 +0200, Fabiano Fidêncio wrote: > > > Now /isodetect/rhel passes, and I get > > > > > > /isodetect/opensuse: > > > ** (/home/test/libosinfo/tests/.libs/lt-test-isodetect:24007): ERROR > > > **: ISO openSUSE-Leap-42.3-NET-x86_64.iso.txt was not matched by OS > > > opensuse42.3 > > > Trace/breakpoint trap (core dumped) > > > > > > instead. Progress? :) > > > > Sorry for the long email. > > > > Here's the output of how I check that our tests are passing: > > > > [fidencio@machado osinfo-db]$ make > > I18N data/datamap/microsoft.com/win-7-l10n-language.xml > [...] > > GEN data/schema/osinfo.rng > > EXP osinfo-db-20180504.tar.xz > > GEN osinfo-db.spec > > GEN mingw-osinfo-db.spec > > [fidencio@machado osinfo-db]$ export OSINFO_SYSTEM_DIR=$PWD/data > > [fidencio@machado osinfo-db]$ cd ../libosinfo/ > > [fidencio@machado libosinfo]$ make check > [...] > > make check-TESTS > > make[2]: Entering directory '/home/fidencio/src/upstream/libosinfo/tests' > > make[3]: Entering directory '/home/fidencio/src/upstream/libosinfo/tests' > > PASS: test-entity > [...] > > PASS: test-isodetect > > PASS: test-install-script > > ============================================================================ > > Testsuite summary for libosinfo 1.2.0 > > ============================================================================ > > # TOTAL: 15 > > # PASS: 15 > > # SKIP: 0 > > # XFAIL: 0 > > # FAIL: 0 > > # XPASS: 0 > > # ERROR: 0 > > ============================================================================ > > Your step are not identical, but equivalent, to the ones I use. > Following your instructions to the letter didn't help. > > Weirdly, I'm only seeing this failure on Fedora 27: I tried with > Debian 9 and Fedora 28 and it worked fine both times, so there's > probably something wrong with my guest rather than with libosinfo :)
Last time I investigated this kind of wierd problem, I found that it was caused by non-deterministic file ordering from readdir(), combined with multiple matches by different osinfo files. That should have been fixed by: commit aa06a8b2905f7ee488b1215e35e486cd36c2df26 Author: Daniel P. Berrangé <[email protected]> Date: Fri Mar 16 13:18:22 2018 +0000 loader: process files in alphabetical order Currently when loading DB files we process them in whatever order readdir() returns them in, which is often inode order. This makes the order of loading files non-deterministic across installs, and if there are ambiguities in the data, we can in turn get different results. eg ISO images match different OS entries depending on load order. Alphabetically sorting the files doesn't remove any ambiguity that may exist, but at least gives us consistent results on every host. Signed-off-by: Daniel P. Berrangé <[email protected]> Reviewed-by: Fabiano Fidêncio <[email protected]> Is it possible that your $HOME/.config/osinfo directory has some stale content perhaps. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| _______________________________________________ Libosinfo mailing list [email protected] https://www.redhat.com/mailman/listinfo/libosinfo
