[11:46] <balloons> howdy pitti.
[11:47] <balloons> I'm curious if you think it's possible for autopkgtest to support getting it's dependencies from a tarball, rather than the archive? I'd like to be able to craft a testing payload (from remote or local source) and have it unpack and use the debs found within rather than looking elsewhere
[12:05] <pitti> hey balloons
[12:06] <pitti> balloons: i. e. reinventing archives :)
[12:06] <balloons> pitti, :-)
[12:07] <pitti> balloons: well, if/once we have such a thing like an archive-which-isn't-an-archive, we can of course add support for it
[12:07] <balloons> pitti, it would also be nice for testing behind firewalls / in offline situations
[12:07] <pitti> it just seems easier to me to actually use archives, and use PPAs, or even archives on p.u.c.
[12:07] <balloons> ahh.. you would rather see us make a proper mini-archive than use a tarball?
[12:08] <pitti> my point is, it's not the archive format (apt-ftpindex and Packages.gz) which is the problem, it's that we don't have an archive for the things that we need
[12:08] <pitti> so why not just collect the debs and run apt-ftparchive on those, and use that as a proper apt sources?
[12:08] <pitti> or use PPAs, which already do all that?
[12:08] <pitti> seems muuuuch easier to me TBH
[12:08] <balloons> we would have to edit the apt sources list
[12:08] <balloons> but otherwise, yea, I guess it would be easier
[12:09] <pitti> add-apt-repository
[12:09] <pitti> or we could even use a temporary apt root
[12:09] <pitti> that bit isn't very hard
[12:09] <balloons> well, yea, I was thinking for keeping it temporary
[12:09] <pitti> I think we want to do that anyway in case the image is out of date and we can't run apt-get update on the r/o image
[12:09] <balloons> yes, exactly
[12:24] <balloons> pitti, so, in summary you would suggest pushing all the debs I want / need into a ppa. Then ?
[12:25] <pitti> balloons: PPA, or some other archive, maybe on people.u.c.; that's more flexible wrt. keeping multiple package versions around, or there's one PPA per image or so
[12:25] <pitti> balloons: then we can add that PPA on an image and set apt pinning to prefer versions from it, and stuff should just work
[12:26] <balloons> right.. I was wondering how to support multiple images inside a ppa
[12:26] <balloons> ok, but the setup to add the ppa and apt-pin it. Is this something we expect autpkgtest to do or no?
[12:27] <pitti> right now you can do it with a --setup-command (apt-add-repository and echo foo > /etc/apt/preferences), but we can certainly make this easier if we need it
[12:27] <pitti> we don't currently run autopkgtests on PPAs, but that's something I was planning to do anyway
[12:28] <pitti> so right now it's possible, but verbose
[12:32] <balloons> pitti, ok makes sense. I may go ahead and try to do it. I'm more curious about setting up an archive on p.u.c to do this over a ppa, since you think it might be saner
[12:32] <balloons> that said, I've little idea how to do that
[12:32] <balloons> I could attempt to lay things out so the mirror what is expected of an archive. presumably there's a tool to help or ?
[12:32] <pitti> balloons: it's not much more than throwing a bunch of debs somewhere, running apt-ftparchive packages | gzip -9 > Packages.gz
[12:33] <pitti> well, if you want to do it properly you need a Release and Release.gpg file too, that's a bit more involved
[12:33] <pitti> PPAs are secure, but don't support multiple versions
[12:33] <pitti> but then again, apt doesn't get along very well with that either
[12:33] <pitti> so I guess in the end we need one archive per image that we care about anyway
[12:34] <pitti> or do the tarball thing, and change tests to download/unpack the tarball instead of having test Depends: on stuff
[12:35] <pitti> but TBH, that's rather crazy (and totally unauth'ed too) :)
[12:35] <pitti> so for simplicity I'd recommend starting with PPAs
[12:35] <balloons> piti, presumably the same packages would go across several versions
[12:36] <balloons> I wonder for instance if just having the versions in ppa would do enough (aka, all vivid images can use the same set, all wily the same, etc)
[17:17] <svij> dkessel: balloons: running the iso tests on a bigger ec2 instance results in this: http://paste.ubuntu.com/12008253/
[17:17] <svij> I'm not sure if this is the current state, or if theres more broken here
[17:22] <balloons> svij, interesting
[17:23] <balloons> what artifcats did you get?
[17:23] <svij> where?
[17:24] <svij> oh, I should read…
[17:25] <svij> balloons: http://paste.ubuntu.com/12008303/ which files do you want to see?
[17:25] <balloons> well, hehe, there's the crash file.  But the autopilot logs would be most intersting
[17:25] <svij> (that was the wily iso btw)
[17:26] <balloons> that should hint at how far the tests got
[17:27] <svij> balloons: in /var/local/autopilot there are only those empty directories
[17:28] <balloons> oh.. so syslog and the crash file is all you got?
[17:28] <svij> yep
[17:33] <svij> openssh-server crash log: http://paste.ubuntu.com/12008347/
[17:34] <svij> syslog: http://paste.ubuntu.com/12008350/
[17:40] <balloons> svij, so it fails branching? Aug  5 17:00:59 ubuntu gnome-session[1785]: bzr: ERROR: [SSL: SSLV3_ALERT_BAD_RECORD_MAC] sslv3 alert bad record mac (_ssl.c:590)
[17:41] <svij> seems so
[17:41] <svij> ssl error? any ideas?
[17:55] <DanChapman> svij looks like it needs ca-certificates package, there's also an option to disable bzr's ca-cert check not sure if that's wise though
[17:57] <svij> isn't that preinstalled?
[17:58] <DanChapman> I would have thought so... it's just weird it's complaining about it. What's the output of apt-cache policy ca-certificates?
[17:59] <svij> http://paste.ubuntu.com/12008493/
[18:00] <svij> oh that was from my ec2 instance…
[18:13] <DanChapman> svij, might be worth testing with an older iso as well. Maybe a vivid one? to rule out it possibly being a broken image all together
[18:14] <svij> DanChapman: good idea… trying that now
[18:15] <balloons> sure.. I guess disable the cert checking as well to see. But it is odd to see bzr complaining about it
[18:16] <balloons> I wonder what's in /etc/ssl/certs/
[18:16] <balloons> how old is bzr?
[18:17] <svij> I think the instance is gone
[18:17] <balloons> I guess this is running on wily, with the current version of bzr
[18:17] <balloons> I was merely wanting to make sure you don't have an old version of bzr doing the checkout
[18:18] <svij> yes it was running the wily iso
[18:19] <svij> now I just wonder, why the script is stuck after "I:local ssh port"
[18:21] <balloons> do we have a log from running in jenkins, but on a real box to compare?
[18:22] <balloons> I guess we can have a look at the old builds
[18:25] <balloons> https://jenkins.qa.ubuntu.com/job/ubiquity_ap-xubuntu_devel_daily-test_english_default/ARCH=i386,label=drude/272/consoleFull
[18:25] <balloons> that's the actual AP bits
[18:26] <bladernr_> Hey, anyone around with triage rights on bugs filed against "linux"?
[18:27] <davmor2> bladernr_: what bug
[18:27] <bladernr_> davmor2: https://bugs.launchpad.net/linux/+bug/1464667 just need it set to "incomplete" so it'll expire if the OP doesn't bother coming back
[18:28] <davmor2> bladernr_: done
[18:29] <bladernr_> davmor2: cool, thanks!
[18:29] <bladernr_> maybe I'll even buy you pie one day
[18:29] <bladernr_> or let you buy ME pie
[19:14] <svij> balloons: DanChapman: okay… tried vivid iso… it seems that it did try to run autopilot: http://paste.ubuntu.com/12008986/
[19:14] <svij> that is autopilot.log
[19:15] <balloons> oO
[19:15] <balloons> that looks nice
[19:16] <svij> "nice" :)
[19:18]  * svij tries wily again
[19:23] <balloons> svij, did you get any other artifacts from that?
[19:23] <balloons> and does it seem that indeed we are good with cloud?
[19:24] <svij> http://paste.ubuntu.com/12009041/
[19:24] <svij> yes seems good with cloud for me
[19:57] <svij> hm… same bzr/ssl error on wily again.
[19:58] <svij> anyway… good night.
[19:58] <balloons> :-(
[19:58] <balloons> good night
[20:22] <flocculant> balloons: where do you suggest reporting this issue - http://postimg.org/image/laa0plmdt/
[20:23] <flocculant> no crypt on this machine - this is trying to use recovery mode in up to date wily
[20:24] <flocculant> and excuse the flash ...
[20:24] <bdmurray> ubuntu-qa who do I talk to about this test failure? http://autopkgtest.ubuntu.com/packages/a/apport/vivid/amd64/
[20:24] <balloons> hmm
[20:24] <bdmurray> its a failure in the setup of the system on which the tests are run
[20:25] <bdmurray> SystemError: E:You must put some 'source' URIs in your sources.list
[20:25] <bdmurray> there are no deb-src lines in /etc/apt/sources.list
[20:25] <balloons> I actually don't know what packages provide for resuce mode
[20:26] <flocculant> :)
[20:26]  * flocculant neither 
[20:26] <balloons> bdmurray, pitti is still an excellent bet. Or the package maintainer. Since it's apport, I guess that still makes pitti and you :-)
[20:27] <bdmurray> rescue mode == friendly-recovery
[20:27] <flocculant> and you said that just before I asked you :)
[20:27] <flocculant> thanks - I'll report that now then
[20:28] <bdmurray> precognition is one of my superpowers ;-)
[20:28] <flocculant> ha ha
[20:28]  * balloons adds that to the cheatsheet on isotracker
[20:28] <flocculant> balloons: good plan :)
[20:28] <bdmurray> balloons: its an infrastructure change as the test was working and then failed with no change in the package
[20:30] <balloons> bdmurray, ahh..
[20:30] <balloons> I was going to say, it's a bit odd to ask as presumably you can fix the test
[20:33] <flocculant> bug 1481904
[20:34] <flocculant> must have turned up *recently* - didn't get that a few weeks ago iirc
[20:35] <flocculant> balloons: that was quick :D
[20:35] <balloons> no, or else I forget
[20:35] <balloons> *now
[20:36] <flocculant> ha ha
[20:36] <flocculant> not sure I'll report it on tracker - not really anywhere to do so
[20:44] <balloons> yea.. the bug is the important part
[20:45] <flocculant> yep
[20:46] <flocculant> I'll try and remember tomorrow morning to check the older kernel's recovery mode
[20:58] <flocculant> balloons: or now - so older kernel no different, but then I expected that as still the same recovery package - but better to be sure I suppose
[21:10] <balloons> righto