You are not logged in.
Pages: 1
==> Starting check()...
We trust you have received the usual lecture from the local System
Administrator. It usually boils down to these three things:#1) Respect the privacy of others.
#2) Think before you type.
#3) With great power comes great responsibility.[sudo] password for builduser:
==> ERROR: A failure occurred in check().
Aborting...
A sudo entry for builduser missing?
Offline
strange, this has worked before. I'll have a look, when I got some time.
Offline
hmm, the file
/etc/sudoers.d/builduser-pacmanwith content
builduser ALL = NOPASSWD: /usr/bin/pacmanis still present on the build-slave's container.
Offline
On a local built of s-nail I get:
[t_behave_atxplode]
./cc-test.sh: line 2204: 2366 Segmentation fault (core dumped) ${MAILX} ${ARGS} -X'source ./.t.rc' -Xx > "${MBOX}" 2>&1
..
[t_behave_e_H_L_opts]
./cc-test.sh: line 2655: 3060 Segmentation fault (core dumped) ${MAILX} ${ARGS} -ef ./.t.mbox
./cc-test.sh: line 2655: 3073 Segmentation fault (core dumped) ${MAILX} ${ARGS} -ef ./.t.mbox
./cc-test.sh: line 2655: 3074 Segmentation fault (core dumped) ${MAILX} ${ARGS} -efL @t@me ./.t.mbox
./cc-test.sh: line 2655: 3075 Segmentation fault (core dumped) ${MAILX} ${ARGS} -efL @t@you ./.t.mbox
./cc-test.sh: line 2655: 3076 Segmentation fault (core dumped) ${MAILX} ${ARGS} -efL '@>@Line 1' ./.t.mbox
./cc-test.sh: line 2655: 3077 Segmentation fault (core dumped) ${MAILX} ${ARGS} -efL '@>@Hello.' ./.t.mbox
./cc-test.sh: line 2655: 3078 Segmentation fault (core dumped) ${MAILX} ${ARGS} -efL '@>@Bye.' ./.t.mbox
./cc-test.sh: line 2655: 3079 Segmentation fault (core dumped) ${MAILX} ${ARGS} -efL '@>@Good bye.' ./.t.mbox
./cc-test.sh: line 2655: 3080 Segmentation fault (core dumped) ${MAILX} ${ARGS} -fH ./.t.mbox >> "${MBOX}"
./cc-test.sh: line 2655: 3081 Segmentation fault (core dumped) ${MAILX} ${ARGS} -fL @t@me ./.t.mbox >> "${MBOX}"
./cc-test.sh: line 2655: 3082 Segmentation fault (core dumped) ${MAILX} ${ARGS} -fL @t@you ./.t.mbox >> "${MBOX}"
./cc-test.sh: line 2655: 3083 Segmentation fault (core dumped) ${MAILX} ${ARGS} -fL '@>@Line 1' ./.
I'll have to check what's causing the segfault.
Offline
The sudo issue is s-nail's or archbuild's fault. I opened a bug against s-nail for using improper sudo statement.
Offline
sudo sed '/en_US.UTF-8/s/^#//' -i /etc/locale.gen
sudo locale-gen
Every time I'm reporting an error in FS concerting LC_ALL=UTF-8 and
stuff, I get the bug closed. But manipulating as root my locale settings
is fine. :-)
Offline
The segfaults don't happen on 32-bit if building using `asp export s-nail; cd s-snail; makepkg -si`.
Also nothing segfaults if I'm chrooting into the absbuild environment with
`linux32 arch-chroot /var/lib/archbuild/staging-i686/copy` and executing `make test`
Offline
ok, I'd propose to build it manually and search for the error (most probably in one of the chroot-systemd-setarch layers) later/never - because it blocks so many packages
Offline
I just built the package manually without running check() (it ran fine manually) - but maybe, finding out the reason for the segfault is still interesting.
Offline
oj: debugging with coredumpctl, chroot, sudo is fun. Finally nailed it:
The secret is to set 'ulimit -c unlimited' in for instance ' /var/lib/archbuild/staging-i686/root/etc/profile'
and of course configure coredump.conf correctly.
All the cores segfault in:
(gdb) bt
#0 0xf71f94aa in setvbuf () from /usr/lib/libc.so.6
#1 0x56618af9 in main ()
Offline
The reason gets clear here
setvbuf(n_stdin, NULL, _IOLBF, 0);
setvbuf(n_stdout, NULL, _IOLBF, 0);
setvbuf(n_tty_fp, NULL, _IOLBF, 0);
setvbuf(n_stdout, NULL, _IOLBF, 0);
setvbuf(n_stdin, NULL, _IOLBF, 0);
So, if this is a there to disable stdin/stdout buffering in non-TTY mode, I have
actually three questions:
- why is building with the build scripts triggering the segfault?
- why is s-nail not using _IONBF to enable non-buffering behaviour?
- was there a glibc change? setvbuf with no buffer and 0 as size parameter:
what does it mean exactly? implementations and standards are a little bit
vague here..
Offline
There was a change in devtools (and devtools32) assigning /dev/console to /dev/stdin - this probably makes the difference.
I cannot comment on the other questions, but I'd say you should open a bugreport against s-nail upstream - this behaviour seems erroneous.
Offline
I can confirm: commenting out 'exec </dev/console' makes 's-nail' pass its tests.
Resetting a stdio buffer, as done in s-nail, seems legit, so nothing to report upstream.
I hesitate to add a PKGBUILD variable 'tty_is_console: yes' or so for packages needing
it..
I also don't like to patch s-nail..
Offline
Can't we just run 'make test < /dev/null'?
Offline
yep, we can!
Offline
Ah. Neat. :-)
Offline
Should I make the patch and retest?
Offline
I wrote bisson, I guess, he'll fix it upstream
Offline
ok.
Offline
Hi, here upstream, i have committed a fix with credit to you all!
But i have a question: that crash could only happen if /dev/console is not writable, i.e., if the call fdopen(fileno(n_stdin), "w") would fail.
How could that be given that n_stdin/n_stdout/n_stderr == stdin/stdout/stderr and the test framework does 'exec </dev/console'?
Offline
If I'm not mistaken /dev/console belongs to root (traditionally):
crw-------. 1 root root 5, 1 Oct 30 18:53 /dev/console
I don't feel comfortable redirecting it in the build scripts.
On the other hand: I'm most likely the only one constantly ignoring warnings and running
the Arch build scripts as root, so I don't care about permission.. ;-)
Offline
Pages: 1