[08:18] <cpaelzer> pitti: the apparmor fix you asked will be in 3.10 for everyone
[08:18] <cpaelzer> I updated the bug
[08:19] <pitti> cpaelzer: ah nice, thanks!
[08:19] <cpaelzer> I'll update the debian bug as well
[08:19] <cpaelzer> with aping to the upstream commit
[08:21] <cpaelzer> not sure when guido will merge 3.10, but then it will be resolved on Debian as well
[09:30] <cpaelzer> pitti: I see on autopkgtest you have a test against what seems a personal ppa
[09:30] <cpaelzer> pitti: Ppas:	['pitti/systemd-semaphore']
[09:31] <cpaelzer> for the un-enlightened like me is there somewhere a howto to do so?
[09:31] <cpaelzer> I used bileto but that recently lets me down considering everything as "always failed"
[09:31] <cpaelzer> and sometimes testing "on" the infra is just what you need
[09:50] <pitti> cpaelzer: ah, yes! these are upstream tests, set up like https://wiki.ubuntu.com/ProposedMigration/AutopkgtestInfrastructure#Integration_with_GitHub_and_GitLab_pull.2Fmerge_requests
[09:50] <pitti> cpaelzer: the underlying mechanics is just adding a ppa= to the test request, like in https://wiki.ubuntu.com/ProposedMigration/AutopkgtestInfrastructure#Test_request_format
[09:51] <pitti> cpaelzer: you can use the run-autopkgtest CLI for convenience (https://wiki.ubuntu.com/ProposedMigration/AutopkgtestInfrastructure#Re-running_tests)
[09:52] <pitti> actually no, this script is horribly out of date; I don't think it's being used any more
[09:53] <pitti> it's that script actually: https://git.launchpad.net/~ubuntu-release/britney/+git/britney2-ubuntu/tree/run-autopkgtest
[09:53] <pitti> (same name, but using the CGI API instead of ssh to snakefruit)
[09:55] <pitti> argh, it's been too long - so that script isn't useful for you, it's indeed the one that directly talks to AMQP and thus you can't access it
[09:56] <pitti> you can trigger them through request.cgi, but ATM you have to build the URL manually; bileto did that, not sure if there's some CLI for that by now
[10:08] <cpaelzer> thanks pitti
[12:22] <sil2100> Does anyone know if it's possible to run armhf autopkgtests on an amd64 host?
[12:23] <sil2100> I tried using autopkgtest-buildvm-ubuntu-cloud with -a armhf but I guess it's using qemu-system-x86_64 by default, tried switching it to qemu-system-arm but then it fails as the script seems to hard-code some params
[12:23] <sil2100> Is there any guide somewhere for that?
[12:25] <cpaelzer> ahasenack: didn't you try that just days ago - any success?
[12:25] <ahasenack> sil2100: I had to tell it to use a wrapper script for qemu
[12:25] <ahasenack> I had it like this
[12:25] <ahasenack> options=$(echo "$@" | sed "s%-enable-kvm%%")
[12:25] <ahasenack> options="$options -M virt"
[12:25] <ahasenack> echo "options: $options"
[12:26] <ahasenack> that just got me a bit further, but it still didn't work
[12:26] <ahasenack> I don't remember exactly what now, but I think it just didn't boot
[12:26] <ahasenack> autopkgtest-buildvm-ubuntu-cloud -r bionic -m http://br.archive.ubuntu.com/ubuntu/  -p http://10.0.100.2:3128/ -o ~/adt-qemu-images -a armhf -q /home/andreas/bin/qemu-arm.sh --cloud-image-url http://cloud-images.ubuntu.com
[12:26] <ahasenack> was my command line
[12:27] <ahasenack> the -q bit specified the wrapper
[12:27] <ahasenack> and I used --cloud-image-url so my proxy would cache the image (as opposed to https)
[12:30] <cpaelzer> pitti: you are usually the last resort on autopkgtest magic - ideas for the above?
[12:41] <sil2100> eh, and I can't even create an armhf schroot right now, debootstrap is dying presumably on bash
[12:42] <ogra_> sil2100, you want qemu-debootstrap
[12:43] <sil2100> I'd assume mk-sbuild knows what it should use
[12:44] <persia> Take care with such assumptions.  Code changes, and needs patches.  When code doesn't work, it is worth looking at why, and maybe fixing it.
[12:47] <sil2100> What I wanted to say by that: mk-sbuild uses what it should, it's not the problem here, qemu-debootstrap is just a wrapper and mk-sbuild is made to create different chroots of different architecture
[12:47] <sil2100> It was working fine always and the problem lies somewhere else
[12:48] <sil2100> eh, I'll try creating an artful schroot and just hope I can reproduce the issue I'm chasing in there
[12:51] <ogra_> well, qemu-debootstrap is actually only a "cp" :)
[12:51] <ogra_> but that one cp call is what makes qemu-user-static work :)
[12:51] <ogra_> else you get an exec format error on bash ;)
[12:52] <sil2100> It's a bit more than a cp but anyway, mk-sbuild uses that for non-native archs anyway
[12:52] <ogra_> well, it used to be cp when i wrote it ...
[12:52] <ogra_> not sure how it has grown sicne
[13:10] <pitti> sil2100: autopkgtest-buildvm-ubuntu-cloud uses qemu-system-`uname -m` by default indeed, but you can specify a different one with -q
[13:10] <sil2100> pitti: yeah, tried that, did a wrapper even to get the -machine specified but it then failed further
[13:10] <sil2100> pitti: ahasenack went further with his hacks but still didn't get it working AFAIK
[13:11] <pitti> sil2100: ah, autopkgtest-virt-qemu has an option for specifying additional qemu args, but not buildvm-ubuntu-cloud
[13:44] <coreycb> hello sru team, i just uploaded a new version of neutron to the zesty unapproved queue that has a fix for bug 1731595
[16:02] <sforshee> LocutusOfBorg: we have a 4.14 kernel in bionic-proposed now but the vbox dkms drivers still fail to build with it. When will we have those fixes?
[16:02] <LocutusOfBorg> meh sforshee I can do it then
[16:03] <sforshee> thanks
[16:03] <LocutusOfBorg> I was waiting for test results on excuses page... can you please link them to me?
[16:03] <LocutusOfBorg> got them
[16:04] <LocutusOfBorg> sforshee, the kernel module builds correctly with 4.14
[16:04] <LocutusOfBorg> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic/bionic/amd64/v/virtualbox/20171207_024001_8610a@/log.gz
[16:04] <LocutusOfBorg> if you mean this error, just ask apw to override it
[16:05] <LocutusOfBorg> it means that the same module is already built so there is no need to dkms it
[16:05] <LocutusOfBorg> autopkgtest for virtualbox/5.2.2-dfsg-2: amd64: Always failed, arm64: Always failed, armhf: Always failed, i386: Always failed, ppc64el: Always failed, s390x: Always failed
[16:05] <LocutusOfBorg> seems already done... so I don't know what is missing
[16:05] <sforshee> huh, my bad. I thought I saw a module build error in the log, maybe I was looking at the wrong one
[16:06] <sforshee> so nm. Thanks LocutusOfBorg!
[16:09] <LocutusOfBorg> :)
[16:09] <LocutusOfBorg> please close the bugs in case
[16:09] <LocutusOfBorg> we have a patch for 4.15, but I don't care to upload it right now
[16:10] <sforshee> that's fine, I'm behind on 4.15 anyhow, still haven't finished the initial rebase
[16:10] <sforshee> too many balls in the air right now :-(
[16:11] <LocutusOfBorg> 5.1.4 will be out before you upload the kernel, but in case... just grab it from vbox-dev mail list if you care
[16:11] <LocutusOfBorg> https://www.virtualbox.org/pipermail/vbox-dev/2017-December/014885.html
[16:13] <LocutusOfBorg> BTW with 4.15 you should really start using the mainline vboxvideo instead of the hacky copy-pasta one
[16:15] <sforshee> LocutusOfBorg: with 4.14 I've already disabled the one from vboxguests in favor of the staging driver
[16:15] <sforshee> we don't even build it
[16:17] <LocutusOfBorg> oh sad news
[16:17] <LocutusOfBorg> please make sure you cherry-picked this commit ce10d7b4e8e3574b9616e54a09d64521b9aeb8b6
[16:17] <LocutusOfBorg> and upload the fix asap in case :p
[16:18] <sforshee> we already got that fix from stable
[16:19] <LocutusOfBorg> <3
[16:19] <LocutusOfBorg> thanks!
[16:20] <LocutusOfBorg> let me know if you do some vm testing then :)
[16:20]  * LocutusOfBorg grabs a bionic from http://cdimage.ubuntu.com/ubuntu/daily-live/20171207/
[17:21] <ahasenack> can someone please click on the retry button in the s390x failed firejail test for iproute2 on http://people.canonical.com/~ubuntu-archive/proposed-migration/artful/update_excuses.html? It's failing because thunderbird is not available in s390x, and the test has been "force-badtested" already so I think it just needs another try
[17:24] <Laney> You don't need a retry for that
[17:27] <ahasenack> I need the failure to be ignored so the package can migrate
[17:28] <ahasenack> or "always failed"
[17:28] <ahasenack> not sure what the state will be after this change
[17:29] <Laney> ok, for artful you need an SRU team member to apply hints, I can't do it
[17:29] <ahasenack> Laney: oh, you did the force-badtest thing for bionic?
[17:29] <Laney> ya
[17:29] <ahasenack> it's wrong there, the test works in bionic
[17:30] <ahasenack> ooop
[17:30] <ahasenack> ps
[17:30] <ahasenack> wait
[17:30] <rbasak> Would someone like to through an MP at me?
[17:30] <ahasenack> it's firejail
[17:30] <rbasak> Uh
[17:30] <rbasak> Throw
[17:30] <ahasenack> Laney: n/m me
[19:33] <ahasenack> is there something going on with setting up ppc64el autopkg tests in excuses? I have 3 different packages failing there with the same error
[19:33] <ahasenack> grub-probe: error: not a directory.
[19:33] <ahasenack> run-parts: /etc/kernel/postinst.d/zz-update-grub exited with return code 1
[19:33] <ahasenack> in trusty
[19:33] <ahasenack> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-trusty/trusty/ppc64el/a/autopkgtest/20171207_002904_c5112@/log.gz is one of them