[00:44] <antarus> dear god
[00:44] <antarus> how is any of d-i maintainable
[00:44]  * antarus shudders
=== antarus is now known as winters
=== winters is now known as Guest42400
=== Guest42400 is now known as antarus
[00:49] <infinity> antarus: It's not so bad, once you get the hang of it.
[00:49] <antarus> no its terrible
[00:49] <antarus> interfaces that rely on a sed command with 10 lines of input
[00:49]  * antarus shudders
[01:05] <antarus> infinity: I'm just amused why we can't just ship a real language in the initramfs and use that ;p
[01:06] <infinity> I won't listen to you speak ill of shell.
[01:34] <antarus> don't get me wrong, I love shell....just not in the context of large systems :/
[02:04] <CIA-32> ubiquity: stgraber * r5211 ubiquity/ubiquity/plugins/ubi-usersetup.py: Merge slightly modified patch from Dan Kegel to detect broken DNS servers always returning DNS records (some ISPs and captive portals), in such case, simply stop trying to resolve the hostname. (LP: #760884)
[02:05] <CIA-32> ubiquity: stgraber * r5212 ubiquity/ (debian/changelog tests/test_usersetup.py): Add a test for the previous change and update changelog
[02:07] <infinity> stgraber: Is that the fix for *.domain.com records?
[02:07] <infinity> stgraber: If so, yay.
[02:08] <stgraber> infinity: I guess that covers that yes. It's the fix for "host <random string of characters>" returning something.
[02:09] <CIA-32> ubiquity: stgraber * r5213 ubiquity/ (d-i/manifest debian/changelog): releasing version 2.9.20
[02:10] <infinity> stgraber: Right, which is generally due to wildcard DNS.
[02:10] <infinity> stgraber: So, yay. :)
[02:17] <stgraber> and uploaded so I get something fresh on tomorrow's images, I guess it's time I focus a bit on installer bugs with cjwatson away for while and all the cool features I wanted either already in the archive or postponed :)
[02:19] <stgraber> oh right, I guess next one on the list is that ibus bug I said I'd fix two months ago ... let's do some Chinese testing
[02:26] <infinity> stgraber: Which continent are you on right now?
[02:32] <stgraber> same as you
[02:33] <stgraber> same country even :)
[02:33] <stgraber> well, unless you aren't home
[02:33] <infinity> I am. :P
[02:33] <infinity> Was just hinting that, perhaps, it's beer o'clock.
[02:38] <stgraber> sounds like a good idea (maybe it'll even help figure out what need magic is needed to get ibus to do something remotely useful...)
[04:09] <CIA-32> ubiquity: stgraber * r5214 ubiquity/ (bin/ubiquity-dm debian/changelog): Get ubiquity-dm to spawn ibus-daemon if available.
[16:02] <ev> some day we'll release ubiquity-dm as it's own entire operating system
[16:11]  * infinity shudders.
[16:12] <infinity> Those who don't learn from Emacs are doomed to reimplement it?
[16:29] <stgraber> ev: hehe, I was actually wondering why it's in python and not in shell ... all these subprocess calls take a lot of space ;)
[16:58] <antarus> stgraber: shell is overly fragile and unmaintainable? ;p
[17:01] <stgraber> antarus: when all you need to do is run 50 commands in a row, shell works pretty well, calling subprocess.Popen 50 times is just slower and uglier ;)
[17:01] <infinity> ^
[17:02] <ev> stgraber: it's just in python because it started in python
[17:02] <ev> it was never intended to grow into the hideous monster you see before you
[17:02] <ev> but that's life when you're a mad scientist
[17:02] <stgraber> ;)
[17:03] <antarus> stgraber: its confusing because 'ubiquity' is a work-internal codename
[17:03] <antarus> stgraber: I have to look up the ubuntu project every time to tell what it is ;p
[17:05] <antarus> stgraber: the Popen interface does kind of suck ;)
=== JanC_ is now known as JanC
[19:00] <infinity> ev: Is there any reason we haven't done anything about #859552 since it was filed?
[19:00] <infinity> ev: It's a one-line change on cdimage to swap from ext3 to ext4, if you want to test it in wubi.
[19:01] <ev> it happened close to release
[19:01] <ev> or rather, it was discovered close to release
[19:01] <infinity> Right, but then we did nothing post-release. :P
[19:02] <ev> such is the nature of bug reports :-P
[19:02] <infinity> ev: I'm game for just changing it on cdimage right now, if you want to make wubi cope?
[19:02] <ogra_> hmm, i thought colin applied that change
[19:03] <infinity> No.
[19:03] <infinity> wubi is still ext3.
[19:04] <ogra_> hmm, weird
[19:05] <ogra_> i thought i saw him committing it
[19:05] <infinity> To cdimage?
[19:05] <ev> infinity: by all means, go ahead
[19:06] <infinity> ev: Hrm, do we build new wubi disk images for lucid point-releases too?
[19:06] <infinity> If so, I might have to special-case this.
[19:06] <ev> we do
[19:06] <infinity> Right, special-casing.
[19:07] <infinity>     if [ "$SUBPROJECT" = "wubi" ]; then
[19:07] <infinity>         if dist_ge precise
[19:07] <infinity>             OPTIONS="${OPTIONS:--f ext4}"
[19:07] <infinity>         else
[19:07] <infinity>             OPTIONS="${OPTIONS:--f ext3}"
[19:07] <infinity>         fi
[19:07] <infinity>     fi
[19:07] <infinity> ogra_: eyeball review?
[19:08] <ogra_> looks fine to me
[19:08] <ogra_> err
[19:08] <ogra_> dist_ge ?
[19:08] <ogra_> is that a builtin ?
[19:08] <infinity> Yeah. :)
[19:08] <ogra_> oh, i didnt know that !
[19:08] <ogra_> but yeah, looks good
[19:08] <infinity> cdimage has evolved its own shell libraries. :P
[19:09] <infinity> ev: Committed.  precise and beyond are ext4.
[19:09] <ev> yay
[19:11] <infinity> ev: And closed all tasks on 859552 except the wubi one.
[19:11] <infinity> ev: No idea if wubi will need an s/ext3/ext4/ change somewhere, but I'm sure it's worth a grep. :)
[19:12] <ev> I think it's fairly agnostic, as it just calls into e2resize with the path
[19:12] <ev> but I'll look
[19:12] <infinity> ev: Yeah, but the original filename is foo.ext3, isn't it?
[19:12] <ev> oh yes, that will need to be fixed :)
[19:15] <ev> ah, no it isn't
[19:16] <ev> root.disk
[19:16] <ev> should be okay
[19:16] <infinity> mv "binary/boot/filesystem.ext3" "ubuntu/disks/root.disk"
[19:16] <infinity> Indeed.
[19:16] <ev> assuming resize2fs.exe copes
[19:16] <infinity> I *do* need to fix live-build. :P
[19:16] <infinity> La la la.
[19:16] <ev> hahaha
[19:17] <ev> bits of string
[19:17] <ev> that's all that's holding our infrastructure together
[19:17] <ev> lets hope no one trips while climbing through it
[19:17] <infinity> Bubblegum too.
[19:17] <ev> haha
[19:22] <infinity> Okay, live-build fixed.  *cough*
[19:23] <infinity> Had I realised this could be fixed without touching wubi at all, I would have done it ages ago.
[19:24] <infinity> (I wonder if I'm the only person who still pronounces wubi as "voobee")
[19:36] <infinity> ev: Can I get you to close the wubi task on that bug after we've built and tested a daily?
[19:36] <ev> infinity: sure thing
[19:36] <infinity> (Or reopen the other tasks, if I screwed up) :P
[19:37] <ev> heh
[19:41] <bdmurray> stgraber: could you look at a diff for the apport package hook for ubiquity - http://paste.ubuntu.com/853127/
[19:42] <bdmurray> it is to block more bug reports from systems with hardware failures
[19:43] <stgraber> bdmurray: looking
[19:45] <stgraber> bdmurray: seems reasonable, we might be getting a few false positives in recoverable cases but there's no good way to detect that and well, an error still occured :)
[19:47] <bdmurray> okay, thanks.  in looking at existing bug reports I don't think I've seen cases where it has recovered
[19:49] <stgraber> yeah and we tend to be getting enough duplicates anyway, so even if it's a bug and the I/O error is unrelated, someone else will have it and will report it ;)
[19:50] <stgraber> oh, almost time for the ISC-DHCP upload ... I finally gave up on listing all the fixes as the changelog would be > 100 lines long, will just put a link to the upstream changelog instead ;)