You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Another test failure on Debian's s390x port. If ostree is treating s390x as a "first class citizen" with its own bootloader-specific code paths, perhaps someone in Red Hat/IBM could set up CI to run its build-time tests on that architecture, so that it isn't always me reporting the test failures?
Relevant-looking part of the log, running build-time tests as non-root in a Debian unstable s390x chroot on a ssh-accessible s390x, which is the only way I can test on this architecture:
+ ostree --repo=testos-repo commit --tree=dir=osdata/ -b testos/buildmain/x86_64-runtime
+ ostree admin upgrade --os=testos
+ assert_file_has_content sysroot/boot/uEnv.txt loadfdt=
+ fpath=sysroot/boot/uEnv.txt
+ shift
+ for re in "$@"
+ grep -q -e loadfdt= sysroot/boot/uEnv.txt
grep: sysroot/boot/uEnv.txt: No such file or directory
+ _fatal_print_file sysroot/boot/uEnv.txt 'File '\''sysroot/boot/uEnv.txt'\'' doesn'\''t match regexp '\''loadfdt='\'''
+ file=sysroot/boot/uEnv.txt
+ shift
+ ls -al sysroot/boot/uEnv.txt
lrwxrwxrwx 1 smcv smcv 15 Oct 26 10:18 sysroot/boot/uEnv.txt -> loader/uEnv.txt
+ sed -e 's/^/# /'
/home/smcv/ostree/tests/libtest-core.sh: line 92: sysroot/boot/uEnv.txt: No such file or directory
It fails on a porterbox. ostree hard-codes zipl to be used on s390x,
so it's reasonable that tests for other bootloaders might not work.
Bug: ostreedev/ostree#3086
Forwarded: no
Gbp-Pq: Topic debian
Gbp-Pq: Name Skip-test-admin-deploy-uboot.sh-on-s390x.patch
It fails on a porterbox. ostree hard-codes zipl to be used on s390x,
so it's reasonable that tests for other bootloaders might not work.
Bug: ostreedev/ostree#3086
Forwarded: no
Gbp-Pq: Topic debian
Gbp-Pq: Name Skip-test-admin-deploy-uboot.sh-on-s390x.patch
It fails on a porterbox. ostree hard-codes zipl to be used on s390x,
so it's reasonable that tests for other bootloaders might not work.
Bug: ostreedev/ostree#3086
Forwarded: no
Gbp-Pq: Topic debian
Gbp-Pq: Name Skip-test-admin-deploy-uboot.sh-on-s390x.patch
It fails on a porterbox. ostree hard-codes zipl to be used on s390x,
so it's reasonable that tests for other bootloaders might not work.
Bug: ostreedev/ostree#3086
Forwarded: no
Gbp-Pq: Topic debian
Gbp-Pq: Name Skip-test-admin-deploy-uboot.sh-on-s390x.patch
Another test failure on Debian's s390x port. If ostree is treating s390x as a "first class citizen" with its own bootloader-specific code paths, perhaps someone in Red Hat/IBM could set up CI to run its build-time tests on that architecture, so that it isn't always me reporting the test failures?
Relevant-looking part of the log, running build-time tests as non-root in a Debian unstable s390x chroot on a ssh-accessible s390x, which is the only way I can test on this architecture:
test-suite.log
The text was updated successfully, but these errors were encountered: