[00:57] bdrung: I don't think we need to have a trash icon by default in gnome-panel [01:14] jbicha: two reasons for it: we had it previously and we have one in unity [01:18] bdrung: and two reasons against it: upstream doesn't do it, and who needs trash on the desktop? [01:20] there's a half dozen folders I might be interested in having quick access to, but I almost completely ignore the trash folder [01:22] gjs will require a mini-transition for fixing the gir1.2-gjs-1.0 to gir1.2-gjsdbus-1.0 package name but gnome-shell is the only rdepends [01:23] bdrung: we also had the Firefox launcher, but I'm not planning to add that to gnome-panel by default either [01:46] jbicha: What packages? Just gjs and gnome-shell? [01:47] ScottK: yes, gnome-shell is the only rdepends for the gjs gir package [01:47] jbicha: OK and does gnome-shell have it's build-dep versioning such that I can just accept them both and not worry about archive skew? [01:49] bdrung: I'm rejecting gnome-panel since it seems there's some controversy about it. Please go to the ubuntu-desktop list, get some consensus, and then upload again if needed. [02:01] ScottK: in my test build, the gjs dependency worked out ok, it's a run time depends so it was added explicitly but without an explicit version [02:02] OK. [02:02] jbicha: that's because Debian dropped the symbols file IIRC (don't remember if we took the change as well) [02:02] jbicha: oh, nevermind me :) [02:18] infinity: Did you have a chance to poke kapok this afternoon? [02:18] deej: Oh crap, not yet. Can do so right now. [02:19] deej: Though, I'm assuming some cron jobs have run by now. [02:20] infinity: I'm assuming you're right :) [02:21] deej: Certainly seems like there've been a few successful builds, yeah. [02:22] infinity: Cool, I'll chalk it up as fine, I'm going to do cardamom unless you have an objection [02:22] deej: No, no. Please do. :) [02:23] deej: We'll put them both through their paces a bit more heavily soon. I've just been headless chickening all day, and you fell off the stack. :/ [02:23] I figured, no worries, everyone's swapping hard on the run up to release [03:45] roaksoax: Where's the FFe for maas-provision? [03:45] New source during final freeze. I love it. [03:46] Happens every cycle there is some new package or major feature that some Canonical project needs to get in during final freeze. [03:49] It's universe, I assume. [03:49] We've done universe debian syncs of new packages too. [03:51] please don't promote gnome-shell/mutter/gjs to -release yet, I'm getting this error when I try running it http://fpaste.org/ZRvq/ [03:51] infinity: With FFe. [03:52] infinity: I don't mind doing FFe/sync of packages people want from Debian. I don't mind if someone wants to do an FFe and some archive admin volunteers to review this one. [03:53] New source not from Debian takes a much finer tooth comb to review. [03:53] Given that Maas was such a priority, I guess I'd have thought they could have actually considered the release schedule. [03:53] ScottK: I'm taking maas-provision along with jdstrand [03:53] OK. [03:53] ScottK: It's to satisfy MIR requirements. [03:53] There should still be an FFe. [03:53] OK. [03:54] it's a rename/copy of cobbler package, that jdstrand wanted, and has already agreed to srcNEW review. [03:54] it was requested in the cobbler MIR [03:55] debian/changelog says "Initial maas-provision release" [03:55] Then I'll revise my rant to "If it's just a fickin' source rename, please say so in debian/changelog." [03:55] ScottK: it does have a debian/Debian.readme [03:55] err, .source [03:56] Yes, I think "renamed from ...." should make it into the changelog. [03:56] Since that is, in fact, a change. [03:57] I was going to reject it with a note that said "No FFe, reupload after you get an FFe", but I'll leave it for you to deal with then. [03:57] ScottK: wait. [03:57] * ScottK isn't doing anything. [03:57] ScottK: it's not a 'rename' as the original package will still exist. [03:58] So were duplicating source in the archive under a new name? [03:58] ScottK: yes [03:59] Please tell me that's somehow actually more brilliant than it sounds. [03:59] ... [03:59] ScottK: Security team doesn't want default cobbler in main.. The other option is to embded cobbler into the maas package, which i have less interest in. [04:00] what makes this cobbler any more delicious? [04:00] why can't the universe cobbler use the main part? [04:01] micahg: My thought exactly. [04:01] see libav/libav-extra spilt [04:01] *split [04:01] "use the main part"? [04:01] Somehow I suspect that jdstrand wasn't actually begging to have duplicate source in the archive. [04:02] ScottK: He was. [04:02] Wow. [04:02] micahg: I imagine the issue is that they're trying to shove something in main that depends on bits of cobbler. [04:03] Sounds like, but I think "then why not split just those bits out" is a reasonable question. [04:03] Indeed, and have cobbler {Build-,}Depend on them. [04:11] I hope the answer isn't something like, "Yes, in theory, but this whole time based release thing threw us off - we needed more time." [04:12] infinity: FYI, cardamom is done, I'm about to close out the ticket, if you run across anything weird, just re-open it, it's enormously prioritized so we'll have a look sooner rather than later [04:14] deej: Check, thanks. They'll get a bit of a workout overnight, but I'll abuse them tomorrow to make sure they're all good. [04:17] Sounds good [04:18] ScottK: So, with maas.. we only use a subset of cobbler features. Having duplicated source measn the security team only need to support vulnerabilities in the areas that maas uses. [04:19] Otherwise security would block the full MIR, as it seems to be quite vulnerability prone. [04:19] Right, but wouldn't it be possible to have cobbler use the part you want in Main so it's not duplicated? [04:20] ScottK: do you think it's reasonable to abuse an otherwise functional package and still keep the ame name? [04:20] people should be able to use cobbler still, no? [04:20] Sure. [04:21] ScottK: we use a subset of most of the binary packages. [04:21] I see. [04:21] ScottK: Spotted an issue with the source upload, can you reject it please? [04:21] Sure. [04:21] thanks! [04:22] Done. [04:22] ta [04:46] ^ ok that gnome-shell works [04:48] Promise? [04:49] It's Universe. He's got several more tries to throw it at the archive if he needs to. [04:49] works for me [04:49] works enough for me to go to bed [04:56] jbicha: ;) [05:11] That was the "Universe not frozen" handwave. [05:19] cjwatson: Did you want to refresh d-i translations at the same time as uploading for armhf/omap4 issues? [05:25] cjwatson: My d-i bits are committed, at any rate, depends on mklibs being built and installed first. [05:25] yay, we have an LP langpack export; /me goes to build packages [05:25] pitti: Want to review my mklibs upload first? ;) [05:26] infinity: waiting for diff, will do then [05:26] pitti: Danke. [05:27] pitti: have fun with 4 shiny new roseapples :) [05:27] ooh! [05:27] and new amd64, too [05:27] still on manual, though [05:27] pitti: yeah, by design [05:27] pitti: The new ones aren't manual. [05:27] pitti: The old ones are. [05:28] infinity: OOI, why do we have so many armel PPA buildds? [05:28] pitti: Effed if I know, that's a world I don't pay attention to. [05:28] Since the PPAs I care about build on the distro buildds. [05:28] if anything I had expected armhf, but most PPAs have neither after all [05:28] anyway, was just curious [05:29] pitti: Well, those are "virtual" PPA builders. Which translates to "only a few special people build there". [05:29] * micahg estimates 2.5 hours for the langpacks with the 4 new buildds [05:29] pitti: Folks with devirt PPAs build on the distro machines. [05:29] argh, mislooked, it's the export from Monday; so, more waiting [05:29] pitti: So, I dunno, I assume IS knows what they're doing with the distribution of the "special" ones. [05:30] infinity: right, hence my question why we have so many of them, I've never seen them doing anything [05:30] pitti: Maybe they do it when you're not looking? ;) [05:30] heisenbuilders? [05:30] (I honestly have no clue, I suspect it may be Spads testing his qemu madness) [05:30] lol [05:31] you laugh, but he's serious :) [05:31] I think that's probably what they are [05:31] ScottK: Is all the dev* stuff in proposed to be copied to release? [05:32] infinity: could I temporarily reactivate the older i386 builders for langpacks, or would that screw up anything? [05:32] pitti: Go nuts. [05:32] ok, great [05:32] pitti: It's not broken, just disabled to make sure the new ones get a workout. [05:32] export is estimated to be done at 0800 UTC [05:33] with that much buildd capacity we can have them in the archive by 1200 UTC [05:33] infinity: No idea. [05:33] slangasek: How do you feel about mklibs? [05:34] pitti: if you just grab allspice and roseapple for i386 for the rebuild, you should be done in under 2 hours :) [05:34] ScottK: They start with a K, you end with a K, I just assumed. [05:34] err..I mean langpack build [05:34] Oh. Looking. [05:34] * micahg really needs to go to sleep soon [05:34] infinity: oh man, I haven't talked to mklibs in years, it'd be great to catch up [05:34] :P [05:34] slangasek: Here's your chance, he's in the queue, pacing! [05:35] infinity: Yes. [05:35] infinity: uh, it's not any more [05:35] ScottK: Cheers. [05:36] pitti: *raise brow* [05:36] infinity: I mean, I accepted it, as you asked me to :) [05:36] pitti: Oh! [05:36] pitti: I was expecting challenging questions about the fine art of library reduction and WTF I was on. [05:36] pitti: But thanks! [05:36] infinity: it seemed quite consistant with the other changes (initramfs, etc.) you did thehre [05:37] pitti: If I fall asleep before mklibs is published, want to sponsor (and tag) the debian-installer release sitting in bzr for me? [05:37] at which point will we update base-files for lsb-release? [05:38] infinity: sure, no problem [05:38] pitti: Isn't there some countdown wiki that details when we do all that? [05:38] https://wiki.ubuntu.com/ReleaseProcess [05:38] it doesn't mention base-files, though [05:38] Oh. [05:38] oh, it does [05:39] pitti: Does do. [05:39] so. [05:39] Release minus 3 days: [05:39] Make sure that /etc/issue, /etc/issue.net, and /etc/lsb-release are correct [05:39] Yeahp. [05:39] I got there just when you did. :P [05:39] it's just well within the time when skaet wanted us to have actual release candidates [05:39] so if we want to do that, we'd have to do it today [05:39] as tonight she wanted to build the first RCs [05:40] I think it's pretty optimistic to believe we won't upload a single package affecting any image after now. [05:40] But sure? [05:40] * micahg will get his blueman upload in before bed then [05:40] oh, I agree; tonight's images won't be the final ones [05:40] I thought the subtle difference was that they _could_ be [05:41] i. e. there is nothing which is knowingly missing on them, etc. [05:41] so that any further image we do is just to pick up opportunistic bug fixes [05:41] pitti: Oh, since you might end up sponsoring d-i for me, want to check the diff in bzr now and review that, so you can pre-approve your own upload? :P [05:42] r1676 is straightforward [05:42] pitti: That's already uploaded. 1677 isn't. :P [05:42] oh? [05:42] I didn't see a "released..." bzr commit [05:42] Hence why 1676 is tagged, and 1677 isn't. [05:42] ah, you don't use dch -r/debcommit -r [05:43] pitti: Follow the tags, not the commit messages. Silly man. ;) [05:43] so, I don't know what --ldlib does, but again that and the ln -s stuff seems consistent with the previous uploads [05:44] infinity: yeah, I'm a huge fan of using UNRELEASED [05:44] +1 [05:44] infinity: so, LGTM [05:44] pitti: mklibs tries to heuristically find the linker via readelf on random binaries, which on armhf finds the wrong path first (nodeterministically, no less) [05:45] pitti: Instead of trying to deal with the mystery of which one gets copied, --ldlib overrides the random search madness and just says "use that one, idiot". [05:45] * pitti nods [05:46] I so desperately want to rewrite mklibs to not be crap. [05:46] And then make initramfs-tools depend on it. [05:46] ^^ death to defoma [05:46] Cause they both get different things differently wrong. [05:47] slangasek: Huzzah! [05:47] even Debian's on board with death to defoma [05:47] most of Debian has been for quite some time; it just took a while to implement ;) [05:51] can one of the distinguished AAs copy {thunderbird,enigmail}/lucid from ubuntu-security-proposed to *lucid-proposed*? [05:53] can do [05:53] Speaking of scary library reduction silliness. Before I call this linker move "done", can anyong think of anything else that does this sort of small-filesystem-creation and might be broken? [05:54] ubuntu-vm-builder? [05:54] debootstrap? [05:54] pbuildler --create [05:54] and pbuilder, too [05:54] * slangasek waits for infinity to rephrase the question :) [05:54] None of those do reduction. [05:54] They just install packages. :P [05:55] Hrm, dracut's probably broken too, but who uses that? [05:58] pitti: is it possible to do that copy w/out retrying the failed builds? [05:58] wow, why do we have dracut in the archive? [05:58] We do. [05:58] ^^ why [05:58] Also, it's written in /bin/bash, but implements its own arg parsing instead of using getopts. [05:58] I wash my hands of this. [05:58] micahg: I don't think so; I can only specify with or without binaries [05:59] :( [05:59] micahg: https://launchpad.net/ubuntu/+source/thunderbird/11.0.1+build1-0ubuntu0.10.04.1 [06:00] pitti: ok, meh, the powerpc build dies after an hour, ok, I can get the build killed I guess [06:00] all building again :/ [06:00] enigmail copied, too [06:00] well, if someone needs the powerpc buildd in the next hour, I'll go find someone to kill the build [06:00] there's a second one free [06:01] * micahg has to do another upload anyways to fix armel/powerpc, but wanted to get some initial testing in [06:01] well, I don't have to, but I probably will [06:02] Because you want a cookie? [06:02] * infinity mails micahg porting cookies. [06:04] heh, I don't like regressions ;) [06:05] * infinity wonders what happened to the context for the debian/rules patch in http://launchpadlibrarian.net/102433012/fontconfig_2.8.0-3ubuntu8_2.8.0-3ubuntu9.diff.gz [06:05] Oh diff, you playful scamp. [06:24] pitti: Nevermind the d-i, I'll upload it myself. ;) [06:25] ack [06:29] pitti: Okay, linux-ti-omap4 and mklibs are published to ftpmaster, uploading d-i. [06:31] will review in a bit with diff [06:31] oh, already accepted apparently [06:32] Oh? [06:32] Looks like it's in the queue to me. :P [06:33] weird, wasn't when I refreshed after queuebot's msg; anyway, there now [06:41] diff from 20101020ubuntu133 to 20101020ubuntu134 (999 bytes) [06:41] infinity: desperately wanted to stay below 1 kB? :-) [06:41] * infinity hopes those are the last fires he needs to put out this week, but knows better. [06:41] pitti: Hey, I had to tweak the changelog to get that diff size! [06:43] http://people.canonical.com/~ubuntu-archive/component-mismatches.svg still makes me sad [06:43] * infinity points pitti to the server team./ [06:44] infinity: I'll flush -proposed, but keep python-defaults as that has some "not me" tag in the pad^Wwiki [06:44] pitti: Yeah, I still don't see the fear of python-defaults, but whatever. ;) [06:44] * micahg figures it's too late to drop libwvstreams4.6-qt from wvstreams [06:45] micahg: zero reverse dependencies, so technically possible; is it important to drop it? [06:46] it's the last QT3 thing in main aside from lsb [06:46] oh [06:46] But since LSB is there, we can't drop QT3 anyway. [06:46] So, meh. [06:46] yeah, but the -dev packages would drop to universe ;) [06:46] Is that a win? [06:47] doesn't encourage use? idk [06:47] We enable everything by default these days, so I don't see how it discourages use. [06:47] And anyone who knows how support works knows that we actually support by source package. Cause we kinda have to. [06:47] pitti: what's your opinion on doing SRUs for multiarch library enablements? [06:48] slangasek: at this point I don't fear simple .so multiarchification any more [06:48] slangasek: It would probably require some more strict testing than the average SRU... [06:48] slangasek: (All the rdeps, etc) [06:48] I'm more wary of the special cases like per-arch plugin paths etc, as they are prone to unintended side effects and errors [06:48] I don't fear it, but I'm not sure it meets our SRU policy :) [06:48] no, technically it doesn't [06:49] except if these could be considered "safe and simple changes" [06:49] we could theoretically use -backports since that'll require rdep testing anyways if SRU is out [06:49] traditionally we've been more permissive on LTSes, so you can certainly find plenty of examples that don't match the letter of the policy [06:50] but if we change a few libraries which actually cause pain to people, I think that would be okay [06:50] slangasek: do you have a particular example in mind? [06:50] Yeah, half the SRUs in an LTS.1 don't meet the policy, cause we try to "polish" the thing we have to support for 5 years. [06:50] pitti: orbit2, libart-lgpl, libbonobo, libbonoboui, and gnome-vfs [06:50] oh, the old gnome 2 stack [06:51] yep [06:51] yuck, why? [06:51] because software still uses them :) [06:52] yes, but anything that needs multiarch installability? [06:52] they don't have too many application rdepends, so that should be bearable IMHO [06:52] slangasek: gnome-vfs might again be more tricky, though, due to modules [06:53] micahg: they're still in main, and there's binary-only software that wants them; so yes [06:55] hmm, I guess there wasn't time to kill them properly [07:26] there, new langpack tarball for real now [07:43] good morning [07:43] hey stgraber [07:45] well, so much for a blueman upload before bed, CDBS has outsmarted me at this hour [07:46] what are you trying to do? [07:46] pitti: can we discuss in -desktop or -motu? [07:47] sure [08:05] ^ I'll reupload with an additional single-digit bug fix [08:12] ^ apport reuploaded with that bug fix, and now sent to -proposed [08:12] so it can be accepted now, and we just defer the move to release; I updated https://wiki.ubuntu.com/PrecisePangolin/FrozenArchiveStatus accordingly [08:16] pitti: Looks good. [08:17] and that won't ruin the nice tie that I have with seb128 in the bug stats :) [08:18] He'll get more in. [08:18] Just wait. [08:18] nah, all to -proposed now [08:18] which bdmurray's scripts don't seem to count [08:18] I suppose I don't even register on this statistic. [08:19] adconrad@ubuntu.com has 11 fixes [08:19] everyone does [08:20] 11. Yeah. Close enough to not registering. [08:20] I need to start filing bugs for every upload I do, to make myself look better. :P [08:23] pitti: do you want blueman in -proposed for extended testing? [08:23] it's on 2 ISOs [08:23] micahg: at least for keeping build skew/failures away, yes [08:23] it's a quick build :) [08:23] we don't actually test the bits in -proposed [08:24] as soon as they are built and published, we copy them over, unless the pad says not to [08:24] s/pad/wiki/ [08:24] pitti: right, I'm asking if you want extended testing :), I can ask the xubuntu/lubuntu folk to help [08:24] they can be tested on a live system, of course (by downloading them manually) [08:24] right, finished catching up on IRC backlog and e-mails post-vacation, now to find some bugs to kill ;) [08:24] micahg: can never hurt, but I thought it's just dropping one file? [08:25] pitti: it's dropping a few files, yeah, I just don't know if any other components depend on them [08:26] I picked a couple of simple fixes from Debian as well (control file only) [08:40] stgraber: why is queuebot not picking up the lubuntu packageset? (see blueman above) [08:41] micahg: hmm, not sure, will have a look [08:43] stgraber: thanks, one of the reasons I had it created was to help with this stuff :) [08:48] infinity: so even roseapple now counts as "old" now? [08:49] pitti: Only in the sense that it existed before elmo gave us new ones. [08:49] pitti: I think we get to keep it. [08:49] pitti: Like I said, I just had all the old ones on manual to make sure the new ones got a fair test. [08:49] micahg: well, queuebot does the right thing ... LP seems to lie though [08:49] infinity: understood, thanks [08:49] * infinity pokes the build history for all the new ones. [08:50] stgraber: http://paste.ubuntu.com/935149/, LP seems to be right :) [08:50] Task: xubuntu-desktop, lubuntu-desktop [08:50] Poor lamiak hasn't seen a build yet. All the rest seem fine. [08:50] langpack import is at zh_TW [08:50] infinity: wait until the langpack builds start ;) [08:51] it'll get plenty of exercise RSN [08:51] >>> set([pkgset.package_set_name for pkgset in lp.distributions['ubuntu'].archives[0].getPackagesetsForSource(sourcepackagename = 'blueman')]) [08:51] set([u'xubuntu']) [08:51] micahg: ^ [08:51] stgraber: Weird, cause it shows in the queue. [08:52] infinity: yeah and edit_acl.py shows it too... it's just when specifically using getPackagesetsForSource that it fails [08:52] * micahg doesn't know the LP API enough to argue [08:53] There, lamiak got a build. [08:53] micahg: I poked #launchpad [08:56] pitti: Okay, you have more i386 than you could ever want now. Enjoy. [08:56] oh, you commissioned some amd64 ones, too? [08:56] wow [08:57] infinity: may as well - I'll go and do that now [08:57] crested and yellow can keep up with the trickle. [08:57] I think at this point building the sources and uploading them from macquarie will be slower than the binary builds :-) [08:57] cjwatson: Oh see, if I'd thought you would want to, I would have not uploaded. Oh well. [08:57] cjwatson: Alternately, I could have done it myself, but I have no idea how. :P [08:59] infinity: ah, never mind, I was still working my way through scrollback. Not that important. [08:59] I've requested a download from LP now just in case there's another. [09:10] sorry for that, should be working fine now ;) [09:10] micahg: so basically the call I was using to get the packagesets was the one used by LP to check for archive upload rights [09:10] micahg: which doesn't work with the lubuntu package set as it doesn't have any uploader [09:11] micahg: the bot now uses another API call that should return the right thing [09:12] Huzzah. [09:23] langpacks look good, uploading/accepting [09:23] pitti: What do you know about this lightdm upload? Sure looks featurey to me. [09:24] infinity: not much; can review if you want [09:24] i. e. I didn't get an advance warning about it or so [09:24] I reviewed it, and is seems sane, but it's definitely new features. [09:24] -proposed: maybe it's for SRU [09:25] Possibly. [09:25] We've blurred the lines a bit. [09:25] Except, it doesn't meet SRU guidelines either. :P [09:25] Again, new features. [09:25] ah, to -set-defaults [09:25] Yes, but then it's Not Our Problem™ :P [09:26] Not saying I'd reject it off-hand, and it looks sane and well-contained, and obviously not broken at a glance. [09:26] not sure if these were requested by some derivative or OEM or whatnot [09:26] I don't remember reading a bug about those [09:26] pitti: Just get someone to formally ask for a FFe, so if another RM asks them about it, they can say "Release member X said I could." :P [09:27] so l-s-d is for derivative mybuntu-defaults pacakges to change the lightdm defaults instead of hacking the config file [09:27] pitti: It has my stamp of "looks correct to me, and I can see the value in it". [09:27] err, perhaps I should use a slightly longer abbreviation [09:27] infinity: *nod* [09:28] Though, if they're going to keep hacking features into lightdm, for the love of the Flying Spaghetti Monster, can someone make it write to utmp/wtmp? [09:28] I'm so sick of not being logged in when I'm logged in. [09:28] infinity: you can reproduce that bug? [09:28] please do tell Robert [09:28] he and I can't, at least [09:29] pitti: Bug? What bug? It's a missing feature. [09:29] adconrad@cthulhu:~$ w [09:29] 03:28:58 up 11 days, 11:00, 0 users, load average: 0.04, 0.08, 0.05 [09:29] USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT [09:29] adconrad@cthulhu:~$ [09:29] bug 870297 [09:29] Launchpad bug 870297 in lightdm "Lightdm logins not being logged in wtmp" [High,Confirmed] https://launchpad.net/bugs/870297 [09:29] ^-- Are you saying you actually have sessions? [09:29] I have 6 of them [09:29] *blink* [09:30] it's not trivial to reproduce, so perhaps robert can borrow an ssh to your box or something [09:30] Sure. I was always under the impression it was just a missing feature. [09:30] It's easy to reproduce here. :P [09:32] "last" uses the same db, right? [09:32] last uses wtmp. [09:32] I can't remember what w uses. Probably the same. [09:32] * infinity tries to remember the difference between wtmp and utmp, but it's been a while since he had to care. [09:33] Ahh, "man wtmp" is helpful. [09:33] "last" has data for every day here [09:33] wtmp is logins, utmp is current session data. [09:33] And yeah, I have neither, except for console logins. [09:34] And ssh. [09:34] So, I should invert that. [09:34] I have everything, except for lightdm-spawned sessions. :P [09:34] https://launchpad.net/builders is a joy to look at [09:36] pitti: The utmp/wtmp manpage seems pretty informative. It's like a HOWTO for mangling them in C. :P [09:47] ^ affects the testing lab in Montreal at least, possibly some other setups too (not sure how many people actually netboot the live cd though) [09:48] stgraber: Did you learn nothing 6 months ago? All important casper uploads happen within ~12h of release. [09:48] I also noticed that the current code generating resolv.conf would generate an invalid file if no domain or search path are defined in the dhcp (fairly common for home networks) [09:48] I should reject that just based on the above principle. [09:48] infinity: ;) [09:48] infinity: I'm happy to upload it next Wednesday if that makes you happy :) [09:49] I'd be thrilled, but then it need to include a fix for a REALLY RC, CAN'T LIVE WITHOUT FIXING IT bug. [09:49] So, go find one of those. [09:50] I should try sleeping again. [09:50] I can almost hear pitti giggling with childlike glee from here. [09:50] 584 jobs (1 hour) is really not that bad :) [09:51] pitti: So, if I fix launchpad to dispatch arch:all (with no any) sources to *all* architectures, will that make you even happier? [09:51] it certainly would :) [09:51] You'd have an army of angry pandas. [09:52] I'm sure a lot of people would be quite happy to that [09:52] Well, I really wanted to be able to do arch affinity at one point too (for things like openbios), but... [09:52]