[08:18] pitti: the apparmor fix you asked will be in 3.10 for everyone [08:18] I updated the bug [08:19] cpaelzer: ah nice, thanks! [08:19] I'll update the debian bug as well [08:19] with aping to the upstream commit [08:21] not sure when guido will merge 3.10, but then it will be resolved on Debian as well === Elimin8r is now known as Elimin8er [09:30] pitti: I see on autopkgtest you have a test against what seems a personal ppa [09:30] pitti: Ppas: ['pitti/systemd-semaphore'] [09:31] for the un-enlightened like me is there somewhere a howto to do so? [09:31] I used bileto but that recently lets me down considering everything as "always failed" [09:31] and sometimes testing "on" the infra is just what you need [09:50] 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] 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] cpaelzer: you can use the run-autopkgtest CLI for convenience (https://wiki.ubuntu.com/ProposedMigration/AutopkgtestInfrastructure#Re-running_tests) [09:52] actually no, this script is horribly out of date; I don't think it's being used any more [09:53] it's that script actually: https://git.launchpad.net/~ubuntu-release/britney/+git/britney2-ubuntu/tree/run-autopkgtest [09:53] (same name, but using the CGI API instead of ssh to snakefruit) [09:55] 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] 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] thanks pitti [12:22] Does anyone know if it's possible to run armhf autopkgtests on an amd64 host? [12:23] 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] Is there any guide somewhere for that? [12:25] ahasenack: didn't you try that just days ago - any success? [12:25] sil2100: I had to tell it to use a wrapper script for qemu [12:25] I had it like this [12:25] options=$(echo "$@" | sed "s%-enable-kvm%%") [12:25] options="$options -M virt" [12:25] echo "options: $options" [12:26] that just got me a bit further, but it still didn't work [12:26] I don't remember exactly what now, but I think it just didn't boot [12:26] 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] was my command line [12:27] the -q bit specified the wrapper [12:27] and I used --cloud-image-url so my proxy would cache the image (as opposed to https) [12:30] pitti: you are usually the last resort on autopkgtest magic - ideas for the above? === maclin1 is now known as maclin [12:41] eh, and I can't even create an armhf schroot right now, debootstrap is dying presumably on bash [12:42] sil2100, you want qemu-debootstrap [12:43] I'd assume mk-sbuild knows what it should use [12:44] 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] 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] It was working fine always and the problem lies somewhere else [12:48] eh, I'll try creating an artful schroot and just hope I can reproduce the issue I'm chasing in there [12:51] well, qemu-debootstrap is actually only a "cp" :) [12:51] but that one cp call is what makes qemu-user-static work :) [12:51] else you get an exec format error on bash ;) [12:52] It's a bit more than a cp but anyway, mk-sbuild uses that for non-native archs anyway [12:52] well, it used to be cp when i wrote it ... [12:52] not sure how it has grown sicne === alan_g is now known as alan_g|lunch [13:10] sil2100: autopkgtest-buildvm-ubuntu-cloud uses qemu-system-`uname -m` by default indeed, but you can specify a different one with -q [13:10] pitti: yeah, tried that, did a wrapper even to get the -machine specified but it then failed further [13:10] pitti: ahasenack went further with his hacks but still didn't get it working AFAIK [13:11] sil2100: ah, autopkgtest-virt-qemu has an option for specifying additional qemu args, but not buildvm-ubuntu-cloud === maclin1 is now known as maclin [13:44] hello sru team, i just uploaded a new version of neutron to the zesty unapproved queue that has a fix for bug 1731595 [13:44] bug 1731595 in neutron (Ubuntu Zesty) "L3 HA: multiple agents are active at the same time" [High,Triaged] https://launchpad.net/bugs/1731595 === alan_g|lunch is now known as alan_g === maxb is now known as Guest16693 [16:02] 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] meh sforshee I can do it then [16:03] thanks === mnepton is now known as mneptok [16:03] I was waiting for test results on excuses page... can you please link them to me? [16:03] got them [16:04] sforshee, the kernel module builds correctly with 4.14 [16:04] https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic/bionic/amd64/v/virtualbox/20171207_024001_8610a@/log.gz [16:04] if you mean this error, just ask apw to override it [16:05] it means that the same module is already built so there is no need to dkms it [16:05] 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] seems already done... so I don't know what is missing [16:05] huh, my bad. I thought I saw a module build error in the log, maybe I was looking at the wrong one [16:06] so nm. Thanks LocutusOfBorg! [16:09] :) [16:09] please close the bugs in case [16:09] we have a patch for 4.15, but I don't care to upload it right now [16:10] that's fine, I'm behind on 4.15 anyhow, still haven't finished the initial rebase [16:10] too many balls in the air right now :-( [16:11] 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] https://www.virtualbox.org/pipermail/vbox-dev/2017-December/014885.html [16:13] BTW with 4.15 you should really start using the mainline vboxvideo instead of the hacky copy-pasta one [16:15] LocutusOfBorg: with 4.14 I've already disabled the one from vboxguests in favor of the staging driver [16:15] we don't even build it [16:17] oh sad news [16:17] please make sure you cherry-picked this commit ce10d7b4e8e3574b9616e54a09d64521b9aeb8b6 [16:17] and upload the fix asap in case :p [16:18] we already got that fix from stable [16:19] <3 [16:19] thanks! [16:20] 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] 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] You don't need a retry for that [17:27] I need the failure to be ignored so the package can migrate [17:28] or "always failed" [17:28] not sure what the state will be after this change [17:29] ok, for artful you need an SRU team member to apply hints, I can't do it [17:29] Laney: oh, you did the force-badtest thing for bionic? [17:29] ya [17:29] it's wrong there, the test works in bionic [17:30] ooop [17:30] ps [17:30] wait [17:30] Would someone like to through an MP at me? [17:30] it's firejail [17:30] Uh [17:30] Throw [17:30] Laney: n/m me === sarnold_ is now known as sarnold [19:33] 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] grub-probe: error: not a directory. [19:33] run-parts: /etc/kernel/postinst.d/zz-update-grub exited with return code 1 [19:33] in trusty [19:33] https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-trusty/trusty/ppc64el/a/autopkgtest/20171207_002904_c5112@/log.gz is one of them === BrAsS_mOnKeY is now known as william