[00:31] <balloons> sorry yes. I should be around again :-) catching up on things
[00:31] <knome> hullo balloons
[00:31] <balloons> hello knome
[00:32] <balloons> I trust this evening finds you most well
[00:32] <knome> night
[00:32] <knome> 3am :P
[00:32] <knome> no evening any more
[00:32] <balloons> hehe, yes, I didn't bother calculating it.. It's LATE for you
[00:32] <balloons> or really.. it's early for you by now
[00:32] <knome> as always ;)
[00:32] <knome> lol
[00:32] <knome> not yet
[00:32] <balloons> 0400 is early imho
[00:33] <knome> it's around 5-6am
[00:33] <balloons> night becomes morning
[00:33] <knome> not in finland in the winter...
[00:33] <balloons> mmm.. yes, that winter thig
[00:33] <knome> thig??
[00:33] <balloons> drat, I'm ripped away again
[00:33] <balloons> *thing
[00:33] <balloons> I'll see you in the morning
[00:33] <knome> hehe, sure
[00:33] <knome> have fun!
[11:42] <DanChapman> balloons: hey! i'm curious to see the results of pilot app. Is there some way I can view them?
[12:52] <nuclearbob> 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] <pitti> nuclearbob: default copy timeout is 300s (5 min), does it actually take that long?
[13:07] <pitti> nuclearbob: log with --debug is usually useful
[13:11] <nuclearbob> 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] <nuclearbob> pitti: I think I must be close to the timeout since it's passing sometime, can I raise the timeout somehow?
[13:12] <pitti> nuclearbob: yes, --timeout-copy=3000 or so
[13:12] <nuclearbob> pitti: thanks! I'll also try to figure out why it's copying so much
[13:12] <pitti> nuclearbob: what beast of a package are you testing that copying it across a disk takes more than 5 mins? :-)
[13:13] <nuclearbob> 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] <pitti> nuclearbob: ah; well, in between testbed resets it has to copy the entire build tree out, and then back in
[13:14] <pitti> nuclearbob: not sure if you keep a whole distro in the test tree or so :)
[13:14] <nuclearbob> pitti: OH, good point. I do have several tarballs in there that I've accumulated, I'll clean those up, thanks :)
[13:14] <nuclearbob> yes, that's a lot faster
[13:15] <pitti> nuclearbob: I suppose the test itself is just a few kB, that should copy in no time?
[13:15] <pitti> perhaps a bunch of logs at the end in $ADT_ARTIFACTS
[13:15] <nuclearbob> pitti: yep. When I clear the leftover distro tarballs out, it's very fast indeed
[13:15] <pitti> :)
[13:15] <nuclearbob> now I feel a little silly
[13:17] <pitti> nuclearbob: you're working on porting the upgrade tests to standard dep-8? that's great!
[13:17] <nuclearbob> pitti: yep. we're getting as much stuff there as possible
[13:18] <pitti> 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] <pitti> nuclearbob: nice!
[13:18] <nuclearbob> pitti: yep, I'm untangling what of that we still need :)
[13:18] <pitti> 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] <pitti> 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] <nuclearbob> 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] <pitti> 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] <nuclearbob> 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] <pitti> nuclearbob: ah, I figure if you just don't specify anything  it'll use some CLI?
[13:21] <pitti> nuclearbob: but that's a thing which you should be able to just copy from the old jenkins tests?
[13:21] <nuclearbob> 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] <nuclearbob> pitti: I'm asking mvo also, thanks
[13:22] <pitti> nuclearbob: how do the old tests invoke d-r-u? should be exactly the same
[13:22] <nuclearbob> pitti: I'm using "do-release-upgrade -d -f DistUpgradeViewNoninteractive" cribbed from the old tests
[13:22] <pitti> that sounds promising
[13:23] <nuclearbob> 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] <nuclearbob> Unable to init server: Could not connect: Connection refused
[13:23] <nuclearbob> (wily:1738): Gtk-CRITICAL **: gtk_settings_get_for_screen: assertion 'GDK_IS_SCREEN (screen)' failed
[13:23] <pitti> sounds like it's using the installed ubuntu-release-upgrader-gtk then
[13:24] <pitti> nuclearbob: or maybe jibel still remembers
[13:24] <nuclearbob> pitti: that's a good question. jibel: do you have any suggestions about frontends beyond that's already in the tests?
[13:25] <pitti> or maybe the old VMs actually did set up X.org -- but you still need to drive that somehow then
[13:25] <pitti> that == the release upgrader
[13:32] <barry> 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] <pitti> 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] <barry> 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] <pitti> barry: I guess you need to take that up with the dpkg/apt maintainers :)
[13:36] <pitti> barry: but this particular syntax is used for arch restrictions already
[13:37] <barry> pitti: another crazy idea: `Depends-<vendor>: foo`.  e.g. Depends-Ubuntu: foo
[13:37] <pitti> 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] <pitti> 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] <barry> pitti: yep, that's a good idea.  thanks!
[13:38] <pitti> barry: Test-Command: is a shell string, so you can just prepend it there
[13:38] <pitti> "dpkg-vendor --is ubuntu && apt-get install -y foo || true"
[13:38] <barry> yep
[13:53] <balloons> DanChapman, yes, I'm just getting back and I'll work on getting information to you and the other core devs
[13:55] <DanChapman> balloons: super! thanks mate :-)
[14:00] <balloons> yw :-) Sorry for the delay
[14:14] <balloons> DanChapman, you can follow this bug also: https://bugs.launchpad.net/ubuntu-community-testing/+bug/1502186
[14:14] <ubot5`> Ubuntu bug 1502186 in Ubuntu Community Testing "Reports are missing P/F data, and aggregate results" [Critical,In progress]
[14:32] <barry> pitti: the one bummer is that now the test needs-root
[15:41] <gQuigs> I'm curious if this bug also affects AMD video cards - https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/1506169
[15:41] <ubot5`> 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] <gQuigs> and if anyone else has been able to reproduce