| balloons | sorry yes. I should be around again :-) catching up on things | 00:31 |
|---|---|---|
| knome | hullo balloons | 00:31 |
| balloons | hello knome | 00:31 |
| 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:32 |
| 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! | 00:33 |
| === 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 | ||
| DanChapman | balloons: hey! i'm curious to see the results of pilot app. Is there some way I can view them? | 11:42 |
| 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? | 12:52 |
| pitti | nuclearbob: default copy timeout is 300s (5 min), does it actually take that long? | 13:06 |
| pitti | nuclearbob: log with --debug is usually useful | 13:07 |
| 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:11 |
| 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:12 |
| 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:13 |
| 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:14 |
| 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:15 |
| 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:17 |
| 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:18 |
| 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:19 |
| 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:20 |
| 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:21 |
| 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:22 |
| 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:23 |
| 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:24 |
| 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:25 |
| 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:32 |
| 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:33 |
| 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:35 |
| pitti | barry: but this particular syntax is used for arch restrictions already | 13:36 |
| 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:37 |
| 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:38 |
| balloons | DanChapman, yes, I'm just getting back and I'll work on getting information to you and the other core devs | 13:53 |
| DanChapman | balloons: super! thanks mate :-) | 13:55 |
| balloons | yw :-) Sorry for the delay | 14:00 |
| 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:14 |
| barry | pitti: the one bummer is that now the test needs-root | 14:32 |
| 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 | 15:41 |
| === chihchun is now known as chihchun_afk | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!