=== juliank is now known as Guest25458 | ||
=== juliank_ is now known as juliank | ||
ophuk | Where can I find information on the automated tests Ubuntu runs on a kernel? | 02:49 |
---|---|---|
sarnold | ophuk: http://autopkgtest.ubuntu.com/packages/linux | 02:51 |
sarnold | ophuk: https://git.launchpad.net/qa-regression-testing/tree/scripts kernel* | 02:51 |
ophuk | sarnold, thanks | 02:52 |
ophuk | I might have a few more questions if you guys don't mind | 02:53 |
ophuk | Is there a way to run these tests locally? | 02:54 |
sarnold | ophuk: you're welcome :) | 02:54 |
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:55 |
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:56 |
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:57 |
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:58 |
ophuk | yeah. We're working on upgrading to a newer version but who knows when that will be | 02:59 |
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:03 |
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! :) | 03:10 |
=== tsimonq2alt is now known as tsimonq2 | ||
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:26 |
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:42 |
tsimonq2 | pitti: Pinging because I *never* had this problem before, and it's a DNS one... | 04:43 |
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:44 |
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 | 04:46 |
tjaalton | sheesh, the tests can take an eternity to run.. or is there an issue with the CI? | 05:24 |
=== Skuggen_ is now known as Skuggen | ||
=== KingsQuest is now known as spy4eye | ||
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:04 |
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:05 |
xnox | sarnold, yes | 08:41 |
xnox | sarnold, it also means that header only boost libraries leak into main abi =) | 08:41 |
xnox | tedg, /usr/bin/ld: cannot find -lpthreads | 08:43 |
xnox | fun | 08:43 |
sarnold | xnox: I'm going to pretend I didn't hear that bit :) and leave it to do ko to cope... | 08:46 |
Unit193 | pull-lp-source is boarked. | 08:49 |
infinity | Unit193: Works for me. | 08:53 |
Unit193 | infinity: Yes sorry, I did a thing that made it hit dde.debian. :3 | 08:54 |
Unit193 | Basically, stupid user thought another service disappeared. | 08:55 |
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>) ) | 08:56 |
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:05 |
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:29 |
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:30 |
Saviq | pitti, no, that works fine, I wonder if it's because how it was compiled (building my own now to see) | 09:31 |
pitti | Saviq: AFAIK our go compiler uses NSS, but upstream's doesn't, so it should just use straight DNS on resolv.conf | 09:33 |
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:34 |
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:41 |
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:43 |
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:44 |
Saviq | pitti, yeah, could be interpreted both ways... | 09:45 |
Saviq | should probably ask resolved to log requests to see if it even gets asked | 09:46 |
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:51 |
Saviq | pitti, huh ¿? http://pastebin.ubuntu.com/23602749/ | 09:56 |
Saviq | so it says it replied, wonder if the CNAME/DNAME resolution makes the difference? | 09:58 |
pitti | dannf: manual test run worked \o/ | 11:08 |
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:09 |
dannf | *nod* | 11:10 |
pitti | dannf: (still having something else half-committed in the pipe, let me finish that first) | 11:11 |
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:15 |
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:16 |
pitti | Laney: actuall, the existing bos01 workers will take care of it, just adding to "architectures =" | 11:17 |
slangasek | rbasak: samba removed from xenial-proposed | 11:18 |
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:19 |
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:21 |
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:23 |
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:24 |
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:25 |
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:26 |
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:27 |
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:28 |
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:29 |
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 | 11:30 |
=== _salem is now known as salem_ | ||
tsimonq2 | pitti: Will do a bit later. | 12:37 |
nacc | stgraber: do you mind approving the zendframework binaries now that they are built? it's showing in https://launchpad.net/ubuntu/zesty/+queue | 12:43 |
nacc | tjaalton: is dogtag-pki's autopkgtest issues on your plate? it's holding tomcat8 in -proposed, afaict | 13:01 |
tjaalton | nacc: tomcat 8.5 broke tomcatjss & dogtag | 13:03 |
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:04 |
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:05 |
Laney | nice, but also eek | 13:06 |
dannf | pitti: yeah - is that container creation / other I/O? | 13:06 |
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:07 |
pitti | nevermind, I did | 13:08 |
pitti | setup-testbed took 5 mins | 13:08 |
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:10 |
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:15 |
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:16 |
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:17 |
tjaalton | so apart from removing tomcatjss & dogtag I don't see a way to unblock tomcat8 | 13:18 |
tjaalton | oh and freeipa too | 13:18 |
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 | 13:19 |
=== skorv is now known as Guest94362 | ||
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:19 |
tjaalton | nacc: yeah that was a bad timing to push 8.5 to debian without checking that rdeps would still build.. | 13:20 |
nacc | tjaalton: ack, np -- thanks for confirming! | 13:21 |
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 ? | 13:43 |
=== vigo is now known as vigo|lunch | ||
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:52 |
cjwatson | shadeslayer: but I don't know exactly what, so can you rephrase your question? | 13:53 |
shadeslayer | cjwatson: is there a way to check if the changes we made were deployed ? | 14:04 |
shadeslayer | cjwatson: would seeded-in-ubuntu work for the supported seed? | 14:05 |
shadeslayer | cjwatson: oh ok it does work | 14:08 |
shadeslayer | hm there was a thing to check if you had upload privs to a package too | 14:10 |
shadeslayer | ubuntu-upload-permission! | 14:10 |
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:15 |
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:16 |
shadeslayer | well there you go, someone needs offer chocolates to the dmb | 14:17 |
shadeslayer | ;) | 14:17 |
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:22 | |
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:25 |
acheronuk | I had the SAME confusion very recently ;) | 14:26 |
ricotz | pitti, hi, is there another network-manager upload planned? | 14:59 |
ricotz | (it could use a rebuild against valac 0.34.4) | 15:00 |
=== vigo|lunch is now known as vigo | ||
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:08 |
ricotz | pitti, I see, although I can't upload things ;) | 15:09 |
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:10 |
Laney | pitti: nice, happy airing | 15:11 |
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 :) | 15:12 |
Laney | pitti: I just moved things to -huge | 16:03 |
Laney | let's see if that works | 16:03 |
Laney | they seem to be bytes instead of strings | 16:05 |
Laney | hope that doesn't matter ¬_¬ | 16:05 |
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:00 | |
Laney | a protip is: don't put things in a queue while you're looping over it ... | 17:03 |
Laney | should be recovering now | 20:52 |
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? | 21:12 |
=== salem_ is now known as _salem | ||
=== JanC_ is now known as JanC | ||
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:35 |
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:36 |
wxl | oh heh maybe it's in gnulib | 23:38 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!