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