=== juliank is now known as Guest25458 === juliank_ is now known as juliank [02:49] Where can I find information on the automated tests Ubuntu runs on a kernel? [02:51] ophuk: http://autopkgtest.ubuntu.com/packages/linux [02:51] ophuk: https://git.launchpad.net/qa-regression-testing/tree/scripts kernel* [02:52] sarnold, thanks [02:53] I might have a few more questions if you guys don't mind [02:54] Is there a way to run these tests locally? [02:54] ophuk: you're welcome :) [02:55] ophuk: the kernel's special, so.. "maybe"? :) here's the wiki on how to use adt-run to run the autopkgtests by hand http://packaging.ubuntu.com/html/auto-pkg-test.html [02:55] here's the description of how the automated thing is hooked up https://wiki.ubuntu.com/ProposedMigration/AutopkgtestInfrastructure (way more work) [02:56] sarnold, lol. Yes it is. Unfortunately at work we have this old kernel with some third party thing and we had to manually patch for dirty cow:( [02:57] the qa-regression-testing there is .. potentially entangled with a bunch of other things. _probably_ you can just run "cd scripts ; ./make-test-tarball kernel " then follow the directions... copy it to a vm, unpack, and probably ./install-packages ./script-kernel or something like that... [02:57] ophuk: ouch [02:58] hmmm, possibly [02:58] ophuk: be sure to patch for this thing too, it's got a one-shot-run exploit as well https://www.ubuntu.com/usn/usn-3151-1/ [02:59] yeah. We're working on upgrading to a newer version but who knows when that will be [03:03] Debian bug 791040 [03:03] Debian bug 791040 in src:freehdl "freehdl: library transition may be needed when GCC 5 is the default" [Important,Open] http://bugs.debian.org/791040 [03:03] Hmmmmmmmmm [03:10] slangasek: Thanks many for feedback regarding freehdl, that's why I think it's a good idea to subscribe the last uploader in Ubuntu to these sort of bugs! :) === tsimonq2alt is now known as tsimonq2 [04:26] xnox: does the archive re-org mean 'cppunit' (in universe in newer releases) can be run during the build for packages in main? :) [04:42] pitti: Having problems with systemd-resolvd. I ended up having to manually change my DNS nameserver in /etc/resolv.conf to be able to access major things like Tweetdeck and the CSS for GitHub... [04:43] pitti: Pinging because I *never* had this problem before, and it's a DNS one... [04:44] note that systemd-resolved has an insanely confusing relationship with /etc/resolv.conf -- in one mode systemd-resolved is a consumer, and in the other mode, systemd-resolved populates it for other things with their own resolvers to consume [04:46] ... /o\ [04:46] sarnold: Looks like the former of which Failed Miserably. [04:46] sarnold: Because I had to do it's job... :P [05:24] sheesh, the tests can take an eternity to run.. or is there an issue with the CI? === Skuggen_ is now known as Skuggen === KingsQuest is now known as spy4eye [08:04] tjaalton: the "issue" is that it's still catching up with glibc and there was a whole new KDE upload too [08:04] see the queues on /running [08:04] tsimonq2: mind filing a bug with the details? (server/NM, journal, contents of resolv.conf, your network config) [08:05] tsimonq2: with that level of detail I'm afraid I can't help [08:05] pitti: hah, ok.. i'll check again next week :P [08:41] sarnold, yes [08:41] sarnold, it also means that header only boost libraries leak into main abi =) [08:43] tedg, /usr/bin/ld: cannot find -lpthreads [08:43] fun [08:46] xnox: I'm going to pretend I didn't hear that bit :) and leave it to do ko to cope... [08:49] pull-lp-source is boarked. [08:53] Unit193: Works for me. [08:54] infinity: Yes sorry, I did a thing that made it hit dde.debian. :3 [08:55] Basically, stupid user thought another service disappeared. [08:56] (FWIW: pull-lp-source: Error: Unable to retrieve package information from DDE: http://dde.debian.net/dde/q/udd/dist/d:ubuntu/r:zesty/p:certbot/?t=json () ) [09:05] any AA able to help process icingaweb2 and zendframework in the new queue? context is LP: #1593024 [09:05] Launchpad bug 1593024 in zend-framework (Ubuntu) "Unblacklist and sync zendframework 1.12.18+dfsg-1 (universe) from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/1593024 [09:29] pitti, hey, have you heard of issues with resolved and go programs? http://rclone.org/ errors out with http://pastebin.ubuntu.com/23602655/ when 127.0.0.53 is in resolv.conf - it's fine when I replace it with my real NS [09:30] Saviq: no, haven't heard; does dig @127.0.0.53:53 drive.amazonaws.com do the same? [09:30] err, without the :53 of course [09:31] pitti, no, that works fine, I wonder if it's because how it was compiled (building my own now to see) [09:33] Saviq: AFAIK our go compiler uses NSS, but upstream's doesn't, so it should just use straight DNS on resolv.conf [09:34] i. e. dig @127.0.0.53 should be pretty much equivalent [09:34] pitti, FWIW, rebuilding my own made it work, I'll report the issue upstream [09:41] Saviq: so that might actually be Ubuntu vs. upstream Go compiler behaviour (NSS or not)? [09:41] pitti, yeah sounds like it [09:41] depends on what rclone uses to build their bins [09:43] Saviq: so it seems their way of a DNS query looks slightly different to glibc's or dig's, and that and resolved don't understand each other [09:44] pitti, the error msg actually suggests it couldn't even find 127.0.0.53 [09:44] Saviq: hm, that's not how I interpret that error message [09:45] pitti, yeah, could be interpreted both ways... [09:46] should probably ask resolved to log requests to see if it even gets asked [09:51] Saviq: you can, start it in verbose mode [09:51] Saviq: this should then also tell you what it's trying to query/forward and where things go haywire [09:51] Saviq: sudo systemctl stop systemd-resolved [09:51] Saviq: sudo SYSTEMD_LOG_LEVEL=debug /lib/systemd/systemd-resolved [09:51] pitti, yup, already looking at the log [09:56] pitti, huh ¿? http://pastebin.ubuntu.com/23602749/ [09:58] so it says it replied, wonder if the CNAME/DNAME resolution makes the difference? [11:08] dannf: manual test run worked \o/ [11:09] pitti: :) [11:09] Laney: ^ arm64 autopkgtest run on bos01 [11:09] pitti: shall i try one myself? [11:09] we don't have custom images yet, so test runs will be slow, but that's fine for testing and manual requests [11:09] dannf: not yet, setting up the worker now; this was just a manual "call autopkgtest on the infra" run [11:10] *nod* [11:11] dannf: (still having something else half-committed in the pipe, let me finish that first) [11:15] pitti: nice! [11:15] what changed? [11:15] Laney: nothing really -- the reboot problem already got fixed a while ago, and I just re-verified that everything is okay [11:16] Laney: dannf and I just had a quick meeting about the roadmap [11:16] Laney: so the idea was to start one arm64 worker now but not enable the arch in britney yet [11:16] Laney: so that we can issue manual test requests, but only enable it in p-m once we have the capacity [11:17] Laney: actuall, the existing bos01 workers will take care of it, just adding to "architectures =" [11:18] rbasak: samba removed from xenial-proposed [11:19] pitti: right - is there more capacity planned? [11:19] pitti, https://blueprints.launchpad.net/ubuntu/+spec/boot-time-optimization [11:19] Laney: yes, it is (that was dannf's side) [11:19] [pitti] Builds a cloud image and injects package: DONE [11:19] neat [11:19] ^ ? where can i learn more info on that ? [11:19] smoser: see the whiteboard, it points to the script [11:21] Laney: yeah - i think i know what hw to purchase, will try to get it approved. i'll keep you in the loop [11:23] okay! [11:23] pitti, so you "Determining which binaries of source %(src)s are installed and have a new version...'" [11:23] but then what do you do with that info ? [11:24] seems like you should exit if its empty ? ie, you're basically only updating the image if that is inside, right ? [11:24] smoser: see line 77, it then installs these binaries [11:24] but if its empty [11:25] smoser: right, good point; "apt-get install -y" succeeds and does nothing, I had expected it to error out with something like "missing package arg" [11:25] i guess apt does "right" thing [11:25] no, there's little point in succeeding then [11:25] well, it depends on what you want. [11:25] if its not already inside, then essentially you are just adding -proposed [11:25] which i thought maybe you were desiring [11:26] smoser: well, in theory this Should Not Happen™ as we would only practically call it for packages that actually are in -proposed [11:26] but there could be some corner cases [11:26] like, binaries are only available on one architecture [11:26] then the test would run in vain [11:26] it also should not fail as that update doesn't regress boot speed [11:27] but would be nice to succeed fast [11:27] right. yeah, maybe exit SOME_NON_ZERO if not present [11:27] and handle that [11:27] * smoser is happy you used mount-image-callback :) [11:27] smoser: handling exit code is not actually all that simple as this all just gets written into m-i-c's stdin [11:28] well, sure it is [11:28] it will exit with whever you told it to in the python popen [11:28] and I want its stdout to stay on the real stdout instead of capturing it [11:28] smoser: ah, good [11:29] smoser: so [ empty ] && exit 99 will reflect in img_shell.wait() [11:29] ? [11:29] i think so , yeah. [11:29] and I can then pass through m-i-c's exit code to the caller of that script [11:29] i mean popen stuff asside. moujnt-image-callaback will exit with the program's return code [11:29] nice [11:29] ok, I'll add that [11:30] smoser: so I'll define a "magic" exit code that means "nothing to do", like "10" [11:30] slangasek: thank you! [11:30] smoser: and then it would not upload the image either === _salem is now known as salem_ [12:37] pitti: Will do a bit later. [12:43] stgraber: do you mind approving the zendframework binaries now that they are built? it's showing in https://launchpad.net/ubuntu/zesty/+queue [13:01] tjaalton: is dogtag-pki's autopkgtest issues on your plate? it's holding tomcat8 in -proposed, afaict [13:03] nacc: tomcat 8.5 broke tomcatjss & dogtag [13:04] tjaalton: ok, it did start failing before 8.5 [13:04] tjaalton: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-zesty/zesty/s390x/d/dogtag-pki/20161109_055803_e3940@/log.gz [13:04] taken from: http://autopkgtest.ubuntu.com/packages/d/dogtag-pki/zesty/s390x [13:05] dannf, Laney: [13:05] http://autopkgtest.ubuntu.com/packages/gzip/zesty/arm64 [13:05] pitti: :) [13:05] dannf: 10min 9s overhead, 1s actual test [13:06] nice, but also eek [13:06] pitti: yeah - is that container creation / other I/O? [13:07] Laney: instances take a while to boot, but most of that overhead really is due to not having an autopkgtest specific iage [13:07] thus this needs to install the full -generic kernel, purge cruft, dist-upgrade and so on [13:07] actually no, I did't call this with setup-testbed [13:08] nevermind, I did [13:08] setup-testbed took 5 mins [13:10] dannf: no, this isn't container, it's full nova instance [13:10] ah, i see [13:10] nacc: can't check, but did amd64 pass before [13:10] ? [13:10] dannf: Laney is planning some optimization to run tests in lxd containers (on all arches) that don't need a full VM (i. e. 99% of our tests) [13:10] but that's independent [13:15] tjaalton: yes, also a regression there too, i think [13:15] tjaalton: http://autopkgtest.ubuntu.com/packages/d/dogtag-pki/zesty/amd64 [13:15] pitti: you making an adt image? [13:15] Laney: not worth the trouble yet; hang on [13:15] passed with 10.3.5-5, started regressing with java-atk-wrapper/0.33.3-11 maybe? [13:15] nacc: hmm ok [13:16] my browser is frozen atm, I'll check later :) [13:16] tjaalton: thanks -- was just noticing the tomcat8 gating in z-p [13:17] anyway, dogtag upstream is finally looking into it, but most likely won't get it fixed before xmas which would be the deadline for stretch (plus 10day migration delay) [13:18] so apart from removing tomcatjss & dogtag I don't see a way to unblock tomcat8 [13:18] oh and freeipa too [13:19] tjaalton: ok, i guess it's not a huge deal, as the SRUs i need to do are all fixed in the version in of tomcat8 that made it into the archive before the dogtag regression === skorv is now known as Guest94362 [13:19] tjaalton: just sort of odd to see :) [13:19] dannf, Laney: bug 1648810 [13:19] bug 1648810 in britney "Enable arm64 autopkgtesting" [Undecided,New] https://launchpad.net/bugs/1648810 [13:20] nacc: yeah that was a bad timing to push 8.5 to debian without checking that rdeps would still build.. [13:21] tjaalton: ack, np -- thanks for confirming! [13:43] Hey, does anyone know how long it takes for the supported seed to get updated and where I can check the current list that launchpad knows ? === vigo is now known as vigo|lunch [13:52] shadeslayer: the supported seed is in revision control and developer-managed, so I suspect you must be asking about something related but different [13:53] shadeslayer: but I don't know exactly what, so can you rephrase your question? [14:04] cjwatson: is there a way to check if the changes we made were deployed ? [14:05] cjwatson: would seeded-in-ubuntu work for the supported seed? [14:08] cjwatson: oh ok it does work [14:10] hm there was a thing to check if you had upload privs to a package too [14:10] ubuntu-upload-permission! [14:15] cjwatson: ref http://bazaar.launchpad.net/~kubuntu-dev/ubuntu-seeds/kubuntu.zesty/revision/1349 , ubuntu-upload-permission -t breeze-plymouth does not list the kubuntu team [14:15] shadeslayer: OK, so you're asking about upload permissions [14:15] yep [14:15] shadeslayer: I didn't know about ubuntu-upload-permission; edit-acl in lp:ubuntu-archive-tools is the thing I use, though they're probably equivalent for this purpose [14:16] :D [14:16] shadeslayer: anyway, translating seeds into upload permissions is a manually-gated process controlled by ~developer-membership-board [14:16] aha [14:16] clivejo: ^^ [14:16] I already told clivejo the same thing [14:16] oh I wasn't aware [14:17] well there you go, someone needs offer chocolates to the dmb [14:17] ;) [14:22] cjwatson: thanks for the clarification <3 [14:22] * shadeslayer goes back into his hole to swear at binutils and dpkg-dev some more [14:25] shadeslayer: yes, we are still waiting for that seed change to get translated to our packageset by the DMB [14:25] ack [14:25] + you won't see the source name in there, just the 1st listed binary that it produces [14:26] I had the SAME confusion very recently ;) [14:59] pitti, hi, is there another network-manager upload planned? [15:00] (it could use a rebuild against valac 0.34.4) === vigo|lunch is now known as vigo [15:08] ricotz: not from my side; feel free to just do a no-change upload, although autopkgtest queues won't let this land anytime soon anyway [15:09] pitti, I see, although I can't upload things ;) [15:10] Laney: I landed the "huge queues" britney part now; should be reasonably safe [15:10] Laney: I'll have a look at it this evening just in case, though [15:10] but I'm off for a bit, sprint just ended and socializing/fresh air and such [15:11] pitti: nice, happy airing [15:12] Laney: will cd ~ tomorrow, so still Sevilla tonight [15:12] it's not like I desperately crave to move from warm Sevilla to icy Augsburg :) [16:03] pitti: I just moved things to -huge [16:03] let's see if that works [16:05] they seem to be bytes instead of strings [16:05] hope that doesn't matter ¬_¬ [17:00] it did matter, and I accidently broke huge/amd64 while trying to recover it :P [17:00] * Laney tries again to get those back [17:03] a protip is: don't put things in a queue while you're looping over it ... [20:52] should be recovering now [21:12] Laney: ah, nice -- how did you do this, delete all jobs and the britney pending cache? [21:12] Laney: or direct AMQP surgery? === salem_ is now known as _salem === JanC_ is now known as JanC [23:35] um, anyone know where i can find the iconv library? we seem to have derivatives of it (e.g. libiconv-hook) but no iconv itself? [23:35] pitti: I believe this is it: https://github.com/systemd/systemd/issues/3826 [23:36] !info libiconv [23:36] Package libiconv does not exist in wily [23:36] !info libiconv-dev zesty [23:36] Package libiconv-dev does not exist in zesty [23:36] if you think i haven't searched you got another thing coming. i'm just surprised [23:36] https://www.gnu.org/software/libiconv/ [23:36] !info iconv wily [23:36] Package iconv does not exist in wily [23:36] O__o [23:38] oh heh maybe it's in gnulib