On 2020-01-08, Jeff wrote: > I didn't express myself very well. I found a bug in my code causing it > not to parse the GMT-14 timezone, and fixed it here: > > https://sourceforge.net/p/gscan2pdf/code/ci/3fa16ee77c5fffde5b8c48a0213d387b087fd2e0/ > > That fixed the general problem, and just leaves me scratching my head > over this: > > https://sourceforge.net/p/gscan2pdf/code/ci/master/tree/t/1628_import_pdf_metadata.t > > The above skipped test fails in reprotest (but not in any normal > schroot). Whatever variants I change like this: > > reprotest -vv --variations="-time" 'prove -lv > t/1628_import_pdf_metadata.t' 'dist/*.tar.gz' > > The build log still gives me: > > INFO:reprotest:build "control": FIX environment, FIX build_path, FIX > kernel, FIX aslr, FIX num_cpus, FIX time, FIX user_group, FIX > fileordering, FIX domain_host, FIX home, FIX locales, FIX exec_path, FIX > timezone, FIX umask > > How do I narrow down which variant caused the problem?
Try reprotest --auto-build, which attempts to bisect which variation is causing the issue, but it's very build intensive, of course... so a bit time consuming. Which I know isn't exactly what you were looking for, but maybe you missed the option and have a machine you can leave running for a long time and come back to later which might point out where to look more specifically. > How do I reproduce it outside reprotest? I do not think anyone knows at this point, unfortunately. Good luck and thanks for trying to sort out this particularly sneaky issue! live well, vagrant
signature.asc
Description: PGP signature
_______________________________________________ Reproducible-builds mailing list Reproducible-builds@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds