[09:45] <Saviq> pitti, hey, does this adt-run(schroot) error mean anything to you http://pastebin.ubuntu.com/9251865/ ?
[09:47] <pitti> Saviq: I'm afraid not; if you can reproduce it, would you mind filing a bug with reproduction instructions?
[09:47] <pitti> Saviq: apparently it did copy up teh stderr file from the testbed (line 20 in pastebin)
[09:47] <pitti> so I'm not sure why it's missing
[09:48] <Saviq> pitti, another thing is that it didn't drop me to shell, even though I asked for it
[09:49] <pitti> Saviq: yeah, as it got that unexpected error
[09:50] <pitti> Saviq: the "drop into shell" happens after displaying stderr
[09:51] <Saviq> pitti, ah
[09:51] <Saviq> pitti, any package in particular I could use to verify that it's not my packages' fault?
[09:52] <pitti> Saviq: my preferred guinea pig is usually d-conf or libpng
[09:52] <pitti> Saviq: as they are fast
[09:52] <Saviq> pitti, ok
[09:52] <pitti> adt-run libpng --- schroot sid
[09:52] <pitti> Saviq: but it doesn't matter much
[09:52] <pitti> Saviq: so, this is definitively not the "fault" of your package, it might just trigger something funky
[09:53] <Saviq> pitti, yup, understand
[09:53] <pitti> Saviq: have you used the schroot runner before?
[09:54] <Saviq> pitti, no, I've been setting up proper for adt for the first time, qemu runner seems to have worked better, but I got schroots laying around for sbuild so thought would use those
[09:54] <pitti> Saviq: yeah; I use them all the time, so I rather suspect that you and I have some slightly different schroot setups
[09:54] <Saviq> pitti, hmm same happens with libpng
[09:54] <pitti> and schroot is used in production on ci.debian.net, too
[09:54] <Saviq> pitti, I wonder, eatmydata or something
[09:55] <pitti> yeah, I suspected as much (not package specific)
[09:55]  * Saviq drops the custom commands from schroot
[09:56] <pitti> Saviq: can you try --- ssh -d <schroot_name> to get debug information from the schroot runner?
[09:56] <pitti> Saviq: does that happen with other schroots? or just unity8-amd64-shm
[09:56] <Saviq> pitti, all of them
[09:57] <Saviq> pitti, you mean schroot -d, no ssh -d?
[09:57] <pitti> Saviq: err yes -- autofinger
[09:57] <Saviq> pitti, http://paste.ubuntu.com/9265598/, that's from `adt-run libpng -d --- schroot -d vivid-amd64`
[09:59] <Saviq> pitti, here's my schroot config, tried without command-prefix, same thing... anything springs to mind http://paste.ubuntu.com/9265616/ ?
[10:00] <pitti> Saviq: hm, perhaps the eatmydata; it might not flush the stderr file to disk (especially not when it's a 0-byte file) early enough?
[10:01] <pitti> Saviq: otherwise my sid schroot uses overlayfs and directory, too
[10:01] <pitti> (most of my other schroots are tarballs)
[10:01] <Saviq> pitti, yeah, I tried to drop the command-prefix, didn't help
[10:01] <Saviq> weeird, /me will create a new chroot
[10:06] <pitti> Saviq: in /usr/share/autopkgtest/python/VirtSubproc.py could you apply http://paste.ubuntu.com/9265758/ and see if that helps?
[10:06] <pitti> Saviq: i. e. if it's some kind of file system race, or some logic error
[10:07] <pitti> (this isn't a proper solution of course, just a quick test)
[10:08] <Saviq> pitti, same thing I'm afraid
[10:09] <pitti> Saviq: ok, that makes it more likable :)
[10:11] <pitti> Saviq: ooh! libpng also failed for you, right?
[10:12] <pitti> Saviq: can you please try this:
[10:12] <pitti> schroot -c sid -u root -- su -s /bin/bash  -c 'whoami'
[10:12] <pitti> erk
[10:12] <pitti> schroot -c vivid-amd64 -u root -- su -s /bin/bash michal -c 'whoami'
[10:12] <pitti> Saviq: ^ this
[10:14] <pitti> Saviq: i. e. maybe it's the su itself which fails (can't resolve your user name), this would explain why the -stdout/err files are not created and libpng fails
[10:15] <Saviq> pitti, it returned my uid
[10:15] <Saviq> "michal"
[10:16] <Saviq> s/uid/username/
[10:23] <pitti> Saviq: ack, so that one works
[10:26] <pitti> schroot -c vivid-amd64 -u root -- su -s /bin/bash michal -c 'set -e; export USER=`id -nu`; . /etc/profile >/dev/null 2>&1 || true;  . ~/.profile >/dev/null 2>&1 || true; whoami'
[10:27] <pitti> Saviq: ^ can you try this?
[10:27] <Saviq> pitti, retcode 1
[10:27] <pitti> a-haa!
[10:27] <Saviq> ;)
[10:28] <pitti> schroot -c vivid-amd64 -u root -- su -s /bin/bash michal -c 'set -ex; export USER=`id -nu`; . /etc/profile >/dev/null || true;  . ~/.profile || true; whoami'
[10:28] <pitti> Saviq: ^
[10:28] <Saviq> pitti, works
[10:28] <Saviq> pitti, ah
[10:28] <Saviq> pitti, byobu
[10:28] <Saviq> daaamit
[10:29] <Saviq> pitti, yeah, it's byobu
[10:29] <Saviq> if I disabled byobu in my session, it's all back in order
[10:30] <pitti> Saviq: ah, interesting; that hooks itself into ~/.profile?
[10:30] <Saviq> pitti, yeah
[10:30] <Saviq> _byobu_sourced=1 . /usr/bin/byobu-launch
[10:30] <Saviq> is what it adds
[10:32] <pitti> Saviq: ah, I wonder if that should only be done on interactive shells
[10:33] <pitti> Saviq: so apparently the || true for sourcing doesn't work as it should? what did you see when you ran this command without the stdout/err redirection?
[10:34] <Saviq> pitti, http://pastebin.ubuntu.com/9266194/
[10:34] <Saviq> pitti, I'll talk to Dustin on that, thanks for the interactive debugging session
[10:35] <pitti> Saviq: interesting, thanks; could you still file a bug about it, please? it seems ". file || true" doesn't work
[10:35] <Saviq> pitti, yup, will do
[10:35] <pitti> cheers
[10:53] <Saviq> pitti, bug #1396955
[10:53] <pitti> Saviq: cheers
[19:57] <doug5> can someone trigger a build of this? http://91.189.93.70:8080/job/ubuntu-calendar-app-ci/