[00:31] sorry yes. I should be around again :-) catching up on things [00:31] hullo balloons [00:31] hello knome [00:32] I trust this evening finds you most well [00:32] night [00:32] 3am :P [00:32] no evening any more [00:32] hehe, yes, I didn't bother calculating it.. It's LATE for you [00:32] or really.. it's early for you by now [00:32] as always ;) [00:32] lol [00:32] not yet [00:32] 0400 is early imho [00:33] it's around 5-6am [00:33] night becomes morning [00:33] not in finland in the winter... [00:33] mmm.. yes, that winter thig [00:33] thig?? [00:33] drat, I'm ripped away again [00:33] *thing [00:33] I'll see you in the morning [00:33] hehe, sure [00:33] have fun! === chihchun is now known as chihchun_afk === nudtrobert1 is now known as nudtrobert === chihchun_afk is now known as chihchun === nudtrobert1 is now known as nudtrobert [11:42] balloons: hey! i'm curious to see the results of pilot app. Is there some way I can view them? [12:52] pitti: I'm getting a lot of timeouts during the copy up of adt-virt-chroot, are there specific logs or data I should get to look into it further? [13:06] nuclearbob: default copy timeout is 300s (5 min), does it actually take that long? [13:07] nuclearbob: log with --debug is usually useful [13:11] pitti: I've been running with -d, and it is taking that long, but I don't know why. Sometimes it doesn't take that long, and the test passes [13:11] pitti: I think I must be close to the timeout since it's passing sometime, can I raise the timeout somehow? [13:12] nuclearbob: yes, --timeout-copy=3000 or so [13:12] pitti: thanks! I'll also try to figure out why it's copying so much [13:12] nuclearbob: what beast of a package are you testing that copying it across a disk takes more than 5 mins? :-) [13:13] pitti: it's just the auto-upgrade-testing, I don't know why it's taking so long, I'm looking at that as well [13:14] nuclearbob: ah; well, in between testbed resets it has to copy the entire build tree out, and then back in [13:14] nuclearbob: not sure if you keep a whole distro in the test tree or so :) [13:14] pitti: OH, good point. I do have several tarballs in there that I've accumulated, I'll clean those up, thanks :) [13:14] yes, that's a lot faster [13:15] nuclearbob: I suppose the test itself is just a few kB, that should copy in no time? [13:15] perhaps a bunch of logs at the end in $ADT_ARTIFACTS [13:15] pitti: yep. When I clear the leftover distro tarballs out, it's very fast indeed [13:15] :) [13:15] now I feel a little silly [13:17] nuclearbob: you're working on porting the upgrade tests to standard dep-8? that's great! [13:17] pitti: yep. we're getting as much stuff there as possible [13:18] nuclearbob: I still vaguely remember the old tests which had two metric tons of setup logic around basically just a handful of lines for upgrading and some post-upgrade tests [13:18] nuclearbob: nice! [13:18] pitti: yep, I'm untangling what of that we still need :) [13:18] nuclearbob: the post-upgrade tests were nice; some of them are probably not necessary any more, such as the python imports, but maybe some still are [13:19] nuclearbob: but ensuring that do-release-upgrade works, and the effing thing still boots after that would indeed be really helpful to get back [13:19] pitti: yeah, first trick is to get the upgrade working at all, then I can do those. Do you happen to know where I can get all the frontend options available for do-release-upgrade? [13:20] nuclearbob: not sure what you mean by that, but my knowledge of d-r-u is pretty much limited to the manpage [13:20] * pitti points mvo-wards [13:20] pitti: okay. the manpage says I can specify a frontend, but doesn't mention which ones exist, and the one I'm using seems like it maybe wants X, which seems wrong [13:21] nuclearbob: ah, I figure if you just don't specify anything it'll use some CLI? [13:21] nuclearbob: but that's a thing which you should be able to just copy from the old jenkins tests? [13:21] pitti: yeah, I want it to be noninteractive, and I'm passing that frontend, but I'm getting errors about mir and a display [13:22] pitti: I'm asking mvo also, thanks [13:22] nuclearbob: how do the old tests invoke d-r-u? should be exactly the same [13:22] pitti: I'm using "do-release-upgrade -d -f DistUpgradeViewNoninteractive" cribbed from the old tests [13:22] that sounds promising [13:23] yeah, it sounds great until I get a lot of Failed to connect to Mir: Failed to connect to server socket: No such file or directory [13:23] Unable to init server: Could not connect: Connection refused [13:23] (wily:1738): Gtk-CRITICAL **: gtk_settings_get_for_screen: assertion 'GDK_IS_SCREEN (screen)' failed [13:23] sounds like it's using the installed ubuntu-release-upgrader-gtk then [13:24] nuclearbob: or maybe jibel still remembers [13:24] pitti: that's a good question. jibel: do you have any suggestions about frontends beyond that's already in the tests? [13:25] or maybe the old VMs actually did set up X.org -- but you still need to drive that somehow then [13:25] that == the release upgrader [13:32] pitti: is it possible, in a d/tests/control to specify Depends that only get installed on one vendor or another? i have a package that differs b/w ubuntu and debian only in one extra dependency that has to be installed on ubuntu. iwbni i didn't have to delta the package just for that [13:33] barry: apt doesn't have a concept of that; but of course you can call "apt-get install -y thatpackage" in your test based on "if dpkg-vendor --is ubuntu" [13:35] pitti: ah yep, i could do that. right now i have a nice little Test-Command but i can script it up. didn't know if you did some preprocessing on Depends or not. would it be insane to support a syntax like: `Depends: @ foo[ubuntu]` ? [13:35] barry: I guess you need to take that up with the dpkg/apt maintainers :) [13:36] barry: but this particular syntax is used for arch restrictions already [13:37] pitti: another crazy idea: `Depends-: foo`. e.g. Depends-Ubuntu: foo [13:37] barry: another hack would be to depend on "foo | aspell-doc" or something -- i. e. alternatively depend on a package which is unlikely to be already installed [13:37] barry: but my gut feeling is that just adding the apt-get that you want with the condition you want to the test is simplest [13:38] pitti: yep, that's a good idea. thanks! [13:38] barry: Test-Command: is a shell string, so you can just prepend it there [13:38] "dpkg-vendor --is ubuntu && apt-get install -y foo || true" [13:38] yep [13:53] DanChapman, yes, I'm just getting back and I'll work on getting information to you and the other core devs [13:55] balloons: super! thanks mate :-) [14:00] yw :-) Sorry for the delay [14:14] DanChapman, you can follow this bug also: https://bugs.launchpad.net/ubuntu-community-testing/+bug/1502186 [14:14] Ubuntu bug 1502186 in Ubuntu Community Testing "Reports are missing P/F data, and aggregate results" [Critical,In progress] [14:32] pitti: the one bummer is that now the test needs-root [15:41] I'm curious if this bug also affects AMD video cards - https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/1506169 [15:41] Ubuntu bug 1506169 in software-properties (Ubuntu) "fresh install - linux-headers-generic linux-image-generic python-notify thermald can be auto removed" [Undecided,New] [15:41] and if anyone else has been able to reproduce === chihchun is now known as chihchun_afk