[01:56] <infinity> smoser: So... What are you doing on first boot to change the filesystem?
[04:10] <pitti> Good morning
[04:41] <cyphermox> pitti: morning
[07:01] <smb> pitti, Morning. I hate to be the anal guy, but... any thoughts about the ifup@.service changes I was looking at? bug 1466790
[07:12] <dholbach> good morning
[07:20] <pitti> smb: still on my TODO, haven't forgotten
[07:23] <smb> pitti, Ok, thanks. It might be helpful in other ways than the specific bug I reported. At least I think it might. But that slightly different handling of sub-processes of processes started with ExecStart compared to ExecStart(Pre|Post) feels like it could cause weird things
[07:24] <pitti> smb: I have some other bug reports in Debian about ifup@; I need to take some time to analyze them all, probably they are related
[07:25] <smb> pitti, I can imagine. It seems like anything triggered by an ifup call in ExecStartPost will be suffering. That includes dhclient but also ntpdate
[07:31] <pitti> smb: right, ExecStart{Pre,Post} must not start anything long-running
[07:31] <pitti> smb: so I suppose I need to put both ifup's into ExecStart
[07:32] <smb> pitti, Right, that was my proposal (actually put all 3 calls into ExecStart and explicitly mark the service as type=oneshot)
[07:33] <pitti> smb: we used to have oneshot, but that's not correct either as it blocks the boot if ifup hangs (slow DHCP, missing cable, etc.)
[07:34] <smb> pitti, Hm but at least from the man page multiple ExecStart are only allowed for oneshot
[07:34] <pitti> smb: right, but that's not a serious limitation
[07:35] <pitti> smb: ExecStart=/bin/sh -c 'if ifquery; ... ifup auto; ifup allow-hotplug;'
[07:35] <smb> pitti, The other option might be to move back to the Vivid style maybe (and have one ExecStart with a shell command executing the 3 commands...
[07:35] <smb> Oh yes, that. :)
[07:35] <pitti> right, I'll probably do that, and check history why I changed it
[07:35] <pitti> but I want to take some time to properly understand and test this in different scenarios
[07:37] <smb> Ok, sure. Just had the feeling that maybe other instances too may have missed the implications of "must not start long running"
[07:39] <smb> Somehow to me that means the command should not take long to run, not that it is not allowed to start something in the background
[07:48] <infinity> pitti: Can we sort out how to make "test logs" linked to by debci have proper content encoding headers so my web browser unzips them instead of forcing me to download them and unzip them manually?
[07:49] <pitti> infinity: incidentally, the remaining TODO on https://git.launchpad.net/~pitti/+git/autopkgtest-cloud/tree/TODO :)
[07:50] <pitti> infinity: that's not debci, it's swift; I'll look into that
[07:50] <infinity> pitti: Right, hence why I said "linked to from", not "served by". :)
[07:50] <pitti> anyway, IKWYM
[07:50] <infinity> pitti: Though, some httpd implementations will serve the right mime-type if you just fudge the filename as foo.txt.gz
[07:51] <infinity> pitti: Which, if it would, could avoid arguing with the server itself.
[08:02] <SpamapS> cjwatson: thanks! I'll explore adding a /boot capability to my image builder instead. :)
[08:05] <doko> siretart, aspectc++ ping
[08:19] <pitti> wow, at first I thought I had a bug in autopkgtesting, but https://tracker.debian.org/pkg/ruby-rails-assets-markdown-it--markdown-it-for-inline actually exists
[08:59] <LocutusOfBorg1> ginggs, congrats for the AM approved :)
[09:00] <Unit193> LocutusOfBorg1: How's vbox 5.0 looking to you then? ;P
[09:10] <pitti> infinity: filed as bug 1474271 FYI
[09:26] <LocutusOfBorg1> Unit193, ready to upload, we are discussing if unstable or experimental
[09:26] <LocutusOfBorg1> for sure I'll ask for an Ubuntu sync, if it lands in experimental :)
[09:30] <seb128> hum, language-pack-touch-zh-hans is blocked in wily-proposed because of a Boottest regression which seems to be flackyness again, could somebody retry it?
[09:38] <Laney> seb128: AFAIK you should have the permission to do that
[09:39] <Laney> but it looks like infinity already got there
[09:39] <seb128> k, going to try next time
[09:39] <seb128> I was on the public jenkins, I guess I need the private one to retry?
[09:40] <Laney> If you go to http://d-jenkins.ubuntu-ci:8080/view/Wily/view/BootTest/job/wily-boottest-language-pack-touch-zh-hans/ and log in you should see a "Build Now" which does it
[09:41] <Laney> pitti: sort of related, does your new autopkgtest infrastructure let anyone retry tests? :)
[09:41] <Laney> hopefully not *anyone*, YKWIM
[09:42] <pitti> Laney: not right now; you need the AMQP credentials for that and be in the data center
[09:43] <pitti> Laney: I'll create some convenience script on snakefruit, or ubuntu-archive-tools or something
[09:44] <pitti> Laney: btw, as I'll be on holidays next week, would you have half an hour or so for me to give you a quick tour about it?
[09:44] <pitti> Laney: i. e. some minimal worker admin in case this stuff hits a bug
[09:45] <Laney> Ah right - hopefully the goal is to let all uploaders do that
[09:45] <Laney> pitti: 'kay, in an hour or so?
[09:45] <pitti> Laney: sounds good
[09:45] <pitti> Laney: just in case I need to sort out stuff with IS, can you ssh wendigo.canonical.com?
[09:48] <Laney> pitti: yeah, and I seem to have access to prod-ues-proposed-migration
[09:48] <pitti> Laney: alright, then you are all set
[09:49] <pitti> Laney: sent a cal appointment with a hangout, please feel free to move it around as you see fit
[09:50] <Laney> ack, just want to not lose my brain state
[10:46] <pitti> infinity: meh, I give up on bug 1474271 for now :/
[10:50] <pragomer> I am remastering Ubuntu with package wireshark. On the live cd I get permission error /usr/bin/dumpcap. I found this solution when I execute it on the live system: http://pastebin.com/JttCCLKD   But when remastering usermod says, in the chroot, MYUSERNAME does not exist. How else can I solve this?
[10:53] <cjwatson> You'd need to put it in a casper-bottom script in the initramfs - the live user is created at boot time
[10:54] <pragomer> ah ok. this was also the direction of my thoughts cjwatson.. doing it in the the init script.. so casper-bottom is a stage where the user is already built?
[10:56] <cjwatson> pragomer: it's created in 25adduser there, so anything after 25 should be fine
[12:13] <arges> pitti: not sure who I should be talking to, but for the autopkgtests run by ubuntuci. Who should I ask to unblock ddebs.ubuntu.com ?
[12:13] <arges> It causes my crash autopkgtest to fail.
[12:15] <Mirv> FYI some more Qt packaging moved to Debian git, so now moved are: qtbase, qtdeclarative, qt3d, qtlocation (+ all that are synced as is). I keep http://is.gd/Q5huYG doc up to date (linked to also from https://wiki.ubuntu.com/Touch/QtTesting)
[12:16] <pragomer> cjwatson: thank you very much
[12:53] <pitti> arges: sorry, WDYM by "unblock"?
[13:12] <arges> pitti: i know there was discussion about the ubuntu tests only having internet access to the archive. I wonder if ddebs.ubuntu.com access is blocked (as it seems from looking at the log)
[13:14] <smoser> infinity, nothing is happening on first boot. the script there shows everyything, entirely automated failure.
[13:14] <smoser> s/nothing/nothing of particular interest/
[13:14] <smoser> not even apt-get upgrade or anything.
[13:15] <pitti> arges: ooh! you mean the source package "crash"?
[13:15] <pitti> arges: I had some trouble parsing that sentence, now it makes much more sense :)
[13:15] <arges> pitti: yes
[13:15] <arges> pitti: : )
[13:15] <pitti> arges: I see it in the logs of http://autopkgtest.ubuntu.com/packages/c/crash/wily/amd64/ too, I'll have a look
[13:16] <pitti> apparently we can't exclude *.ubuntu.com in $no_proxy, this one does need a proxy
[13:23] <infinity> smoser: Well, something must be happening to it, or the second boot would be the same as the first...
[13:24] <smoser> agreed. i can give you access to diamond if you'd like.
[13:31] <infinity> smoser: I'm assuming either the PReP partition or the partition table in general is being broken.  Hard to say which.  Unless qemu itself is breaking your image for you, which seems unlikely.
[13:31] <smoser> i'm suspecting growpart right now. checking that.
[13:32] <Daviey> [A
[13:32] <Daviey> [A
[13:33] <infinity> Daviey: Go on, say [A again.  I dare  you.
[13:33] <Daviey> [A
[13:34] <infinity> Oh.  Well done, then.
[13:34] <smoser> it would seem to be growpart related . :-(.
[13:35] <Daviey> [A
[13:35] <Daviey> [A
[13:36]  * smoser tries to imagine what emotion that is.
[13:38] <Daviey> Sorry all, having odd locale problems.. generating odd control characters on pg/up.
[15:30] <seb128> does anyone know who handles http://ubottu.com/meetingology/logs ?
[15:30] <seb128> that gives a permission error
[15:32] <teward> seb128: perhaps poke -irc, but i think they've had issues with the bots lately?
[15:37] <seb128> teward, did that (as you noticed on the other channel, thanks ;-)
[15:38] <teward> :)
[16:53] <ScottK> It should be possible to get qscintilla2 and a stack of other packages to migrate with a few no change uploads, FYI.
[17:27] <infinity> slangasek: Do you know what the ddebs.u.c lag is, compared to archive.u.c?
[17:27] <infinity> slangasek: (ie: how long after publishing a deb should I expect to wait for a ddeb?)
[17:28] <slangasek> infinity: afraid not, no.  bdmurray, do you know?
[17:31] <bdmurray> infinity, slangasek: I do not know.
[17:31] <infinity> Check.
[17:31] <infinity> I could try to divine from the code, but I'm not that impatient to know the answer.
[17:54] <roaksoax> /w/win 9
[18:20] <mwenning> hi guys is there an irc channel for lxd?
[18:22] <stgraber> mwenning: #lxcontainers
[18:22] <stgraber> (same as lxc, cgmanager, lxcfs, ...)
[18:47] <cjwatson> $ ssh -t germanium sudo -iu ddebs crontab -l | grep 'ddeb-retriever --quiet today'
[18:47] <cjwatson> 40 */2 * * * ~/ddeb-retriever/ddeb-retriever --quiet today
[18:47] <cjwatson> infinity: ^-
[18:48] <infinity> cjwatson: Yeah, I know.
[18:48] <infinity> cjwatson: You'll note I logged in well before you did. ;)
[18:49] <cjwatson> I didn't note that, note the lack of interactive shell above :)
[18:49] <infinity> cjwatson: NOTE HARDER.
[18:50] <infinity> cjwatson: The more interesting thing I'm confused by now is that the latest ddeb-retriever run appears to have decided that wily has no kernels.
[18:50] <infinity> Not sure what to make of that.
[18:51] <cjwatson> Maybe only on some arches?
[18:52] <infinity> cjwatson: I'd like to think we have kernels on all arches.
[18:52] <cjwatson> Yeah :)
[18:52] <cjwatson> Anyway, late meeting tonight, so I was doing some of that not working thing.
[18:52] <infinity> I approve of this message.
[18:54] <infinity> cjwatson: Huh.  You're right.  Only on some arches.  Curious.  Maybe it needs a 'yesterday' run to unconfuse itself.
[18:54]  * infinity tries forcing the issue.
[18:56] <infinity> cjwatson: Oh, crap.  Wait.  That timestamp windowing you and pitti worked out for only grabbing builds from X to Y.  Is that build completion date or build accept date?
[18:56] <infinity> cjwatson: Cause I'm now thinking that leaving an amd64 build in UNAPPROVED for more than a day might have fooled ddeb-retriever's tiny brain.
[18:57] <infinity> In fact, I'm sure that's what happened...
[18:57] <cjwatson> Hm.
[18:57] <cjwatson> BPPH creation date.
[18:58] <cjwatson> Which you'd think would be accept date.
[18:58] <cjwatson> But you can manually stuff a different timestamp in and it'll try again.
[18:59] <infinity> cjwatson: Yeah, I'll do that.
[18:59] <infinity> cjwatson: But out of curiosity, what's the BPPH creation date for https://launchpad.net/ubuntu/+source/linux/4.0.0-4.7/+build/7636518 ?
[18:59] <infinity> FInished building on the 9th, but I only accepted it yesterday.
[18:59] <infinity> Guessing the date is the 9th.
[19:04] <cjwatson> infinity: 2015-07-14 17:05:58.537532+00:00
[19:04] <infinity> cjwatson: Okay, very confused.  I guess I need to read this code. :/
[19:07] <cjwatson> infinity: You sure another today run wouldn't have sorted it out?  I'm thinking maybe there's a race with BPPHs that have been dominated or something
[19:07] <cjwatson> Pretty difficult to tell without logging, though.
[19:07] <infinity> cjwatson: I've done a few more today runs with no luck.  But, there's a threshold file that makes it skip ahead.
[19:08] <infinity> cjwatson: So, it might have raced a bit, then skipped ahead.
[19:08] <cjwatson> There's a one-hour grace period on that threshold, which ought to be enough.
[19:08] <infinity> INFO: Retrieving Launchpad publications since 2015-07-14 17:53:13+00:00
[19:09] <infinity> Clearly too late.
[19:10]  * infinity knocks it back two hours and tries again.
[19:10] <cjwatson> Right, but a previous run ought to have covered it at least once.  Weird.
[19:13] <infinity> cjwatson: Huh.  And now I'm stumped.  Even that didn't download the amd64 kernel ddebs.
[19:16] <infinity> cjwatson: Even weirder (and this doesn't seem possible), one armhf ddeb is there, but not both...
[19:17] <infinity> slangasek: Remember when you offered to look at this? :P
[19:18] <infinity> slangasek: http://paste.ubuntu.com/11879214/
[19:19] <infinity> slangasek: The missing amd64 ddebs make "sense", in that a whole build is gone, though I can't figure out how to force ddeb-retriever to find it.
[19:19] <infinity> slangasek: But the armhf thing is even weirder.  generic-lpae is there, but generic is missing.  How does half a build go missing?
[19:20] <cjwatson> Is it maybe failing to associate them with the deb partners?
[19:20] <cjwatson> There's some fairly baroque code for that IIRC
[19:21] <infinity> cjwatson: But only for this one version?
[19:21] <cjwatson> Yeah, that's odd.  Crank up logging and trawl through the output?
[19:21] <cjwatson> --verbose
[19:23] <infinity> That was a lot more verbose than I'd expected...
[19:33] <infinity> cjwatson: No mention of the missing kernels in a verbose log: http://paste.ubuntu.com/11879283/
[19:34] <infinity> Oh, but my time hack got reverted.
[19:34]  * infinity undoes that and tries harder.
[19:39] <slangasek> oh man, you have time hacks?!
[19:39] <slangasek> I want time hacks
[19:42] <infinity> slangasek: It's not nearly as cool as the movies make it sound.
[19:55] <carlgeorge> Rackspace is looking for a Linux Engineer with experience building Ubuntu and/or Debian packages.  http://rackspace.jobs/san-antonio-tx/ubuntu-linux-engineer/2532116AFB2B4E7093C154362DFB5F5B/job/
[20:22] <slangasek> mdeslaur: is there any chance you could help with bug #1474541?
[20:26] <mdeslaur> slangasek: hrm, I'll take a look at it tomorrow
[20:28] <slangasek> mdeslaur: thanks :)
[21:15] <xnox> slangasek: i hope you are not jealous =)
[21:16] <xnox> slangasek: http://spi-inc.org/corporate/votes/2015-board-election/
[21:18] <Unit193> xnox: "Congrats"? :)
[21:22] <xnox> Unit193: thanks.
[21:29] <slangasek> xnox: I was just celebrating here that you got the position so I didn't have to
[21:29] <slangasek> :)
[21:31] <xnox> slangasek: ;-) if you have any requests or insight, i'm all ears.