=== chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun [11:46] howdy pitti. [11:47] 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] hey balloons [12:06] balloons: i. e. reinventing archives :) [12:06] pitti, :-) [12:07] 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] pitti, it would also be nice for testing behind firewalls / in offline situations [12:07] it just seems easier to me to actually use archives, and use PPAs, or even archives on p.u.c. [12:07] ahh.. you would rather see us make a proper mini-archive than use a tarball? [12:08] 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] so why not just collect the debs and run apt-ftparchive on those, and use that as a proper apt sources? [12:08] or use PPAs, which already do all that? [12:08] seems muuuuch easier to me TBH [12:08] we would have to edit the apt sources list [12:08] but otherwise, yea, I guess it would be easier [12:09] add-apt-repository [12:09] or we could even use a temporary apt root [12:09] that bit isn't very hard [12:09] well, yea, I was thinking for keeping it temporary [12:09] 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] yes, exactly [12:24] pitti, so, in summary you would suggest pushing all the debs I want / need into a ppa. Then ? [12:25] 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] 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] right.. I was wondering how to support multiple images inside a ppa [12:26] ok, but the setup to add the ppa and apt-pin it. Is this something we expect autpkgtest to do or no? [12:27] 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] we don't currently run autopkgtests on PPAs, but that's something I was planning to do anyway [12:28] so right now it's possible, but verbose [12:32] 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] that said, I've little idea how to do that [12:32] 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] balloons: it's not much more than throwing a bunch of debs somewhere, running apt-ftparchive packages | gzip -9 > Packages.gz [12:33] 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] PPAs are secure, but don't support multiple versions [12:33] but then again, apt doesn't get along very well with that either [12:33] so I guess in the end we need one archive per image that we care about anyway [12:34] or do the tarball thing, and change tests to download/unpack the tarball instead of having test Depends: on stuff [12:35] but TBH, that's rather crazy (and totally unauth'ed too) :) [12:35] so for simplicity I'd recommend starting with PPAs [12:35] piti, presumably the same packages would go across several versions [12:36] 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) === vrruiz_ is now known as rvr === chihchun is now known as chihchun_afk [17:17] dkessel: balloons: running the iso tests on a bigger ec2 instance results in this: http://paste.ubuntu.com/12008253/ [17:17] I'm not sure if this is the current state, or if theres more broken here [17:22] svij, interesting [17:23] what artifcats did you get? [17:23] where? [17:24] oh, I should read… [17:25] balloons: http://paste.ubuntu.com/12008303/ which files do you want to see? [17:25] well, hehe, there's the crash file. But the autopilot logs would be most intersting [17:25] (that was the wily iso btw) [17:26] that should hint at how far the tests got [17:27] balloons: in /var/local/autopilot there are only those empty directories [17:28] oh.. so syslog and the crash file is all you got? [17:28] yep [17:33] openssh-server crash log: http://paste.ubuntu.com/12008347/ [17:34] syslog: http://paste.ubuntu.com/12008350/ [17:40] 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] seems so [17:41] ssl error? any ideas? [17:55] 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] isn't that preinstalled? [17:58] 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] http://paste.ubuntu.com/12008493/ [18:00] oh that was from my ec2 instance… [18:13] 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] DanChapman: good idea… trying that now [18:15] sure.. I guess disable the cert checking as well to see. But it is odd to see bzr complaining about it [18:16] I wonder what's in /etc/ssl/certs/ [18:16] how old is bzr? [18:17] I think the instance is gone [18:17] I guess this is running on wily, with the current version of bzr [18:17] I was merely wanting to make sure you don't have an old version of bzr doing the checkout [18:18] yes it was running the wily iso [18:19] now I just wonder, why the script is stuck after "I:local ssh port" [18:21] do we have a log from running in jenkins, but on a real box to compare? [18:22] I guess we can have a look at the old builds [18:25] https://jenkins.qa.ubuntu.com/job/ubiquity_ap-xubuntu_devel_daily-test_english_default/ARCH=i386,label=drude/272/consoleFull [18:25] that's the actual AP bits [18:26] Hey, anyone around with triage rights on bugs filed against "linux"? [18:27] bladernr_: what bug [18:27] 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:27] Ubuntu bug 1464667 in Linux "HP Dynamic Smart Array fails with 14.04" [Undecided,New] [18:28] bladernr_: done [18:29] davmor2: cool, thanks! [18:29] maybe I'll even buy you pie one day [18:29] or let you buy ME pie [19:14] balloons: DanChapman: okay… tried vivid iso… it seems that it did try to run autopilot: http://paste.ubuntu.com/12008986/ [19:14] that is autopilot.log [19:15] oO [19:15] that looks nice [19:16] "nice" :) [19:18] * svij tries wily again [19:23] svij, did you get any other artifacts from that? [19:23] and does it seem that indeed we are good with cloud? [19:24] http://paste.ubuntu.com/12009041/ [19:24] yes seems good with cloud for me [19:57] hm… same bzr/ssl error on wily again. [19:58] anyway… good night. [19:58] :-( [19:58] good night [20:22] balloons: where do you suggest reporting this issue - http://postimg.org/image/laa0plmdt/ [20:23] no crypt on this machine - this is trying to use recovery mode in up to date wily [20:24] and excuse the flash ... [20:24] ubuntu-qa who do I talk to about this test failure? http://autopkgtest.ubuntu.com/packages/a/apport/vivid/amd64/ [20:24] hmm [20:24] its a failure in the setup of the system on which the tests are run [20:25] SystemError: E:You must put some 'source' URIs in your sources.list [20:25] there are no deb-src lines in /etc/apt/sources.list [20:25] I actually don't know what packages provide for resuce mode [20:26] :) [20:26] * flocculant neither [20:26] 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] rescue mode == friendly-recovery [20:27] and you said that just before I asked you :) [20:27] thanks - I'll report that now then [20:28] precognition is one of my superpowers ;-) [20:28] ha ha [20:28] * balloons adds that to the cheatsheet on isotracker [20:28] balloons: good plan :) [20:28] balloons: its an infrastructure change as the test was working and then failed with no change in the package [20:30] bdmurray, ahh.. [20:30] I was going to say, it's a bit odd to ask as presumably you can fix the test [20:33] bug 1481904 [20:33] bug 1481904 in friendly-recovery (Ubuntu) "Recovery mode wants root password" [Undecided,New] https://launchpad.net/bugs/1481904 [20:34] must have turned up *recently* - didn't get that a few weeks ago iirc [20:35] balloons: that was quick :D [20:35] no, or else I forget [20:35] *now [20:36] ha ha [20:36] not sure I'll report it on tracker - not really anywhere to do so [20:44] yea.. the bug is the important part [20:45] yep [20:46] I'll try and remember tomorrow morning to check the older kernel's recovery mode [20:58] 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] righto === txomon|home_ is now known as txomon|home