=== JayFo is now known as JFo === dous__ is now known as dous === Whoopie_ is now known as Whoopie === dendro-afk is now known as dendrobates === asac_ is now known as asac [07:05] good morning [07:07] hey dholbach [07:07] hey mvo [07:07] mvo: ALTER!!!!! [07:07] * dholbach hugs mvo [07:07] :) [07:07] * mvo hugs dholbach [07:07] Up early? [07:07] yes [07:08] same here :) [07:10] are we the upstream of the acpi-support package? [07:10] dholbach, hello! [07:11] hiya jml [07:11] jml: what about that UDW session? :-D [07:12] dholbach, last week of January, right? I'll be in the UK that week. [07:12] https://wiki.ubuntu.com/UbuntuDeveloperWeek/Prep is the preliminary schedule [07:12] dholbach, I was just about to ask :) [07:12] jml: acpi-support is in debian too [07:13] I'm trying to find the upstream vcs for it. [07:13] let me see [07:13] dholbach, I can do the Friday 1800 slot. [07:13] wow, it's even in sync with debian in lucid [07:14] jml: which topic? lplib? :) [07:14] dholbach, I can do lplib. I could also do an "Ask Launchpad" session [07:14] dholbach, whichever you think would be more interesting. [07:14] jml: which one would you prefer? [07:15] dholbach, I have no preference. [07:15] wow, it's going to be exciting being able to actually attend some of these sessions :) [07:16] dholbach, probably lplib is best. [07:16] dholbach, keep it concrete & code-y [07:16] hum, it could be that we're "upstream" for acpi-support [07:17] it's a bit of a weird divergence [07:17] slangasek might know more [07:17] the debian/copyright of the debian source package says something like "It was downloaded from http://archive.ubuntu.com/....." [07:18] jml: shall I pencil you in? session title? :) [07:19] * jml tries to think of a clever title that doesn't violate the CoC [07:19] haha [07:19] * dholbach hugs jml [07:20] I'm all out of clever. How about "Meet launchpadlib"? [07:21] "launchpadlib and you: Making access to Launchpad easier" ? [07:21] sounds good to me :) [07:22] I'm just going to make lp:~ubuntu-core-dev/acpi-support/trunk the dev focus for acpi-support. slangasek can correct me if I'm wrong. [07:22] jml: sounds good to me [07:23] jml: thanks a bunch for helping out with UDW :) [07:23] dholbach, my pleasure. [07:23] we have a fantastic line-up this time [07:23] I mean we always do :) [07:24] dholbach, yeah. I'm looking forward to heckling at rockstar's talk :) [07:24] haha [07:25] Ng, hello. [07:25] Ng, could I persuade you to set the development focus branch for https://code.edge.launchpad.net/evdev ? [07:26] who can I interest in another UDW session? there's still 4 open slots! [07:26] https://wiki.ubuntu.com/UbuntuDeveloperWeek/Prep === dendrobates is now known as dendro-afk [07:31] jml: that should work [07:31] slangasek, thanks. [07:32] * jml is doing a little mindless data gardening [07:35] Can I convince somebody to sync something like jack-tools? 3.0 support works now, and I'd like to see that syncing actually works. [07:36] (jack-tools has all the things that are likely to trip Soyuz up, and it has no real changes, so it seems like a good test) [07:38] wgrant: I synced one already [07:38] (abraca, now in dep-wait) [07:38] slangasek: But it at least hit the buildds? Good. [07:39] yep [07:40] thanks for all your help to get v3 happening :) [07:40] np [07:40] Sorry it took so long. === tkamppeter_ is now known as tkamppeter [08:08] hi [08:09] i get the source of 9.10 kernel, and found that Ubuntu patches the vanilla kernel. where can i find the information on the patch? [08:09] i want to know which change Ubuntu made to the vanilla kernel [08:09] the patch to 2.6.31 is pretty big. [08:10] except AppArmor, and ndiswrapper, what else Ubuntu change to the kernel? [08:13] junjun: try asking in #ubuntu-kernel (and maybe wait a bit, the folks might still be asleep :-)) [08:13] dholbach: thanks! [08:14] Good morning [08:16] slangasek: right, I think there should be an extra field in the workitems table eventually; but oh well, kees already fixed it for now [08:21] from Ubuntu 9.10, we patch kernel with Non-Exec stack patch. Is that exactly the patch named Exec-Shield from Redhat? [08:21] if not, what is the difference with Redhat's Exec-shield?? [08:24] oh well, it seems Ubuntu uses the patch from Redhat (Fedora) [08:25] junjun: "execshield" is the entire unbrella project that Redhat put all their hardening features under. [08:25] junjun: Ubuntu's kernel carries the last remaining piece of that which is not already upstream, the partial nx-emulation for i386 [08:25] kees: so you mean we only port the kernel patch to Ubuntu, but not the rest? [08:25] junjun: everything else already in the kernel, userspace, etc. [08:26] junjun: some details here: https://wiki.ubuntu.com/Security/Features [08:26] it is interesting to know, thanks [08:26] sure, np [08:26] so far, it seems only kernel of Fedora (and Redhat, CentOS) and Ubuntu uses this patch. [08:27] junjun: afaik, SUSE uses it as well, but I haven't personally verified it. [08:27] the rest like OpenSuse, Debian, .... dont. is that correct? [08:27] Debian does not use it, correct. I'm unsure about SUSE [08:27] kees: ok, i will check that [08:28] junjun: as linked from https://wiki.ubuntu.com/Security/Features#Non-Exec%20Memory I have a simple regression test that can help validate a given kernel. [08:29] junjun: the patch itself is here: http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-karmic.git;a=commitdiff;h=eb56f42a4bc9c671a19dcf8fd36eb3f341de7dfa [08:30] it's based on the bits from http://www.codemonkey.org.uk/projects/execshield/ [08:32] kees: very clear, thanks! [08:33] kees: why this patch doesnt work for 64bit kernel?? [08:33] junjun: the cs-limit approach doesn't make sense for 64bit, and nearly all 64bit system already implement non-exec in hardware, so the emulation is unneeded. === doko__ is now known as doko [08:34] what do you mean by "cs-limit approach doesn't make sense"?? [08:35] the partial nx-emulation patch uses the cs segment limit to split userspace into two region (one executable, the other not). as I understand it, there's no reason to do this for 64bit, since 64bit is PAE, which implements the NX bit in the page table, so no artificial separation is needed. [08:41] pitti: shall I make nvidia depend on acpid and acpi-support or would the former suffice? [08:41] tseliot: just acpid, please [08:41] acpi-support is unrelated to what nvidia does, and is still on the "to die" list [08:42] pitti: ok, the latter seemed too much as a dependency to me but I wanted to be sure [08:45] zul: ping? is there a bacula 3.0.X backport for hardy anywhere? [09:02] pitti, can you upload Poppler for me, debdiff on bug 293832? Thanks. [09:02] Launchpad bug 293832 in poppler "printer prints page at wrong position, page cut" [High,Fix committed] https://launchpad.net/bugs/293832 [09:24] tkamppeter: hi! sure [09:25] tkamppeter: should the other tasks be "invalid"ated then? [09:26] jml: hey, is that still required? [09:26] pitti, I think so. [09:26] tkamppeter: uploaded [09:26] jml: well, I suppose I can see that there's no focus set, so I suppose a better question would be what would you like it set to? ;) [09:28] pitti, the non-Poppler tasks are invalidated now, thanks for uploading. [09:28] ogra: bryce_ wrote a basic test plan for touch screens to check that the udevification didn't break anything (https://wiki.ubuntu.com/X/Testing/Touchscreen); does that look reasonable to you, or is there something important that should be added there? [09:50] Ng: re: the mkinitramfs error, 17-12-2009 11:30:21 < slangasek!n=vorlon@minbar.dodds.net: mdz: yes, Keybuk said he was going to fix that today [09:51] ah, sorry [10:24] pitti: What was the magical gvfs-mount option again? [10:24] StevenK: for doing what? [10:25] pitti: A USB key I just inserted is not automounting [10:28] StevenK: so you want to mount it manually? gvfs-mount -d /dev/foo [10:28] steven@liquified:~% gvfs-mount -d /dev/sdb [10:28] No volume for device file /dev/sdb [10:30] so gvfs-mount -li doesn't have /dev/sdb then? [10:30] does devkit-disks --mount /dev/sdb work? [10:31] pitti: No, gvfs-mount -li does not have sdb [10:31] devkit-disks ... does work, though [10:34] StevenK: does gvfs-mount -oi say anything when you plug this in? [10:35] pitti: Yes, and it actually mounted it this time. [10:35] * StevenK curses heisenbugs [10:50] free: can you please make bug 455217 public, so that it can be SRU-processed? [10:50] Bug 455217 on http://launchpad.net/bugs/455217 is private [10:51] pitti: oops, sorry, just made it pubblic, thanks [10:51] free: and please make sure that all the fixed bugs have proper ubuntu package tasks [10:52] pitti: I think I'm not entitled to create tasks? or how do I? [10:52] pitti: I couldn't figure out how to do it last time [10:52] free: "Also affects distribution" -> ubuntu/landscape-client [10:52] pitti: okay, on all the bugs related to the SRU? [10:52] right [10:53] we need to track their fixes/status in all releases [10:53] I started adding them [10:54] okay [10:55] all added now, I think [10:55] free: would you mind reviewing the bugs and closing the lucid tasks which are already fixed? [10:56] pitti: sure [10:56] thanks [11:06] pitti: I guess I can use "Fix released" for lucid tasks right? [11:06] free: if they are fixed in lucid, yes [11:06] pitti: okay, so that's done [11:07] cheers [11:07] pitti: there a now bugs that have the Lucid task with fix-released, and bugs that have a new Ubuntu task (no release-specifc tasks yet) [11:08] pitti: so, I don't think I can open release-specifc tasks, can I? [11:08] free: you can nominate [11:08] pitti: what does that mean exactly? [11:09] free: the tasks won't be created yet, but they will shown as "proposed for jaunty-update", etc. [11:09] I'll accept them while reviewing [11:09] okay [11:12] pitti: I can't figure out how to nominate, I can't see any "nominate" or similar button in the bug page UI.. [11:12] free: "Target to release" [11:12] (with the ubuntu task selected, not the upstream task) [11:17] pitti: and how do you select the Ubuntu task? clicking on it just brings me to the landscape-client source page in the ubuntu LP project === jelmer_ is now known as jelmer [11:18] free: hm; just change the URL to /ubuntu/+source/landscape-client/... ? [11:19] or change anything else in the ubuntu task [11:19] like priority, assignee, etc. [11:22] pitti: okay, manually entering the url like you suggest works, but changing something the ubuntu task doesn't, I couldn't find any way to do it except manually entering the url [11:26] pitti: okay, the bugs without specific release tasks should be all nominated now (for intrepid to lucid) [12:00] free: can bug 455217 be fixed in lucid, too? [12:00] Launchpad bug 455217 in landscape-client "Handle release-upgrade messages in the packagemanager plugin" [Medium,Fix committed] https://launchpad.net/bugs/455217 [12:01] pitti: yes [12:02] pitti: just marked it as Fix released [12:02] great === Hellow_ is now known as Hellow === vila is now known as vila-lunch === ara_ is now known as ara === mac_v_ is now known as mac_v === vila-lunch is now known as vila [13:16] fabbione: no there isnt a backport [13:16] zul: thanks, I have done myself [13:16] fabbione: cool [13:16] zul: you might want to take care of Lucid release notes for upgrading tho [13:17] zul: you need to have a director > 3.0 to talk to fd > 3.0 [13:17] zul: dir 3.0 can talk to fd in any version but not the other way around [13:17] fabbione: thanks for the heads up [13:17] zul: so basically, if you want LTS to LTS upgrade plan, the director machine needs to be done first [13:18] gotcha [13:46] james_w: did the import failed for samba i dont see it in launchpad? [13:47] zul: it was stuck in the queue, I've set it to run next [13:48] james_w: thanks [14:06] mdz, Ng: it was stuck in NEW :p === asac_ is now known as asac [14:27] http://www.advogato.org/person/robertc/diary.html?start=129 [14:27] this gets a major ++ from me [14:27] I would hope this mentality would propagate to more debian and ubuntu developers [14:31] I really don't see the relation between upstreams doing their own packaging, and including the debian/* in the upstream source [14:32] I agree with the first, not with the second [14:32] why? [14:33] because debian/* use dependencies or rules some times tweeaked for specific distros/releases [14:33] there is no advantage on having them including on the source, there is the advantage that other packagers will need to patch or rm the upstream debian/* [14:34] ops, disadvantage [14:35] upstreams doing the packaging is a social subject, including debian/* in the source is a technical one [14:36] upstream sometimes has code that doesn't work on Ubuntu, so there is a disadvantage that we sometimes need to patch it, so upstream shouldn't ship any code [14:38] james_w, source code is generic, as far as possible, debian/rules are not, and you failed ot mention what at the advantages of having it include on the source :) [14:38] ops, I meant debian/* [14:38] debian/* are generally, otherwise we wouldn't be able to derive from Debian without making vastly more changes than we do [14:40] joaopinto_: I like it when I unpack a tarball of some new software and I can just build a package out of it immediately. That's why I include a debian/ in my projects :) [14:40] Is Google Talk audio supposed to be working with Empathy in Karmic? [14:40] Ng: The problem is most upstreams that attempt to do this, don't know a lot about Debian packaging. [14:41] ScottK: I don't see that as a reason to tell every single upstream that does it off, as seems to be the culture currently [14:41] james_w, you are refering to the general case of Debian versus Ubuntu, the debian/* world does not stop there, and still, your sentence is not accurate when you need to backport [14:41] ScottK: I would absolutely fit in that pot, which is why I merge back in the correctness from nxvl's packaging :) [14:42] Ng, if you want your projects just to build, provide a .dsc file [14:43] Ng, you will help those which "just want to build" per your rules, without interfering with others that want to build in another way [14:43] joaopinto_: I don't follow, how does a .dsc help? [14:43] for a .dsc file to make any sense you have to have a debian directory, no? [14:43] Ng, dget file.dsc && debuild [14:44] no, you just need the .dsc, diff, and orig [14:44] and everone is happy with a single dget command, versus a wget source [14:44] joaopinto_: Which you can't build without a debian directory in the source [14:45] StevenK, you can, because I am refering to a .dsc which points to both the orig.tar.gz and the debian diff [14:46] joaopinto_: And what do you think is in the debian diff? The debian directory. [14:46] StevenK, right, but provided as it should as a diff, not included on the original source [14:47] joaopinto_: so you refuse to let us re-use and collaborate on that debian/ directory in the most natural way, as we do the rest of the code? [14:47] no thanks [14:48] james_w, no, but I don't agree that the proper place for packaging collaboration is the source, you do collaboration for a group at the cost of other group [14:48] Another issue is that improvements to Debian packaging need a new upstream release if that's the canonical source for them. [14:48] it's not a cost that means much [14:49] it doesn't have to be the canonical source, or diff.gz can make modifications [14:49] how much variation is there in the packaging of debian derivatives? talk of costs without numbers seems a bit pointless [14:49] james_w, ah ok, so you assume that your need for collaboration is more important than others needs for a clean source :) [14:49] improvements to the code don't need a new upstream release, we are generally happy to patch and feed the changes back for the next release [14:49] that's something personal, nothing to argue about :) [14:52] james_w, upstreams should be able to collaborate if the debian/* dir is kept in any VCS [14:55] huh? [14:55] upstream should never put the debian/ directory into their VCS [14:55] that's just wrong [14:56] the only good reason I see on this change would be, "Hey you cand build .debs from the source", when there is no one able to set up a PPA or get it into the repositories [14:56] anyone can have a PPA [14:56] but again, that is not collaboration :) [14:56] Keybuk, we are debating that http://www.advogato.org/person/robertc/diary.html?start=129 [14:57] there's no loop or step to getting one, just create a Launchpad account [14:57] I disagree strongly with Robert ;) [14:57] one of the biggest problems I ever have, as a distribution maintainer, is upstreams who put the packaging into their tarball [14:57] because it's always wrong [14:57] and it makes it very hard for us to modify it [14:58] it should just be another branch imo [14:58] in certain ways, for example removing a debhelper config file, it becomes impossible to modify without repackaging the software entirely [14:58] like how we're doing for UDD [14:58] Keybuk, that was the pointing I was making [14:58] (because our source package format doesn't permit removing files in the diff.gz) [14:58] Keybuk: to be fair, Rob says we should fix that. [14:59] you also end up the situation where it looks like it's got a package [14:59] but the package is wrong [14:59] so people think they can grab the upstream tarball [14:59] build it [14:59] and then install it on their distribution [14:59] that could go *badly* wrong [15:00] look at the .spec file issues between SuSE and RedHat for an example ;) [15:02] hmm, so what happens if upstream has a debian/ but Debian, Ubuntu, wants to package in different ways? [15:03] does the upstream need to pick which distro to support? or do they use something like control.in? [15:04] LaserJock: it gets more fun [15:04] upstream might disagree with the way distributions change their packages [15:04] and deliberately make it hard for distributions [15:04] (this happens) [15:11] Keybuk: why are you packaging things in isolation from the upstream? if their debian/ is wrong they must care enough to have one, so presumably want a correct one? [15:12] Ng: it means they want one they *think* is correct [15:12] that's so far removed from "a correct one" that they may as well be in different universes [15:13] Keybuk: I think they want one that produces a working package [15:13] see, that's the problem [15:13] let me give you an example [15:13] Ng: Which is a small subset of what it takes to be correct. [15:13] I have an upstream, who we'll call Ted [15:13] he maintains a piece of software, which we'll call e2fsprogs [15:13] and he also happens to put the entire debian/ directory in his package [15:14] Ted sounds like he cares about his users! [15:14] tricks that Ted has done in the past include adding code to his debian/rules to disable features on Ubuntu [15:14] because he thought that Ubuntu was doing things wrong [15:14] turned out that was a bug in his kernel code he was hiding [15:14] the only reason he was getting bug reports from Ubuntu users is because we have lots of users [15:15] so to avoid fixing a kernel bug we just take the packaging away from him? [15:15] Ted has deliberately blocked library transitions [15:15] etc. [15:15] no [15:15] I'm saying that in the released upstream tarball is the wrong place for packaging [15:15] for a start, what's right for Debian might not be right for Ubuntu [15:15] even though the packaging files are the same) [15:15] I think the right way is what we do on Upstart [15:15] we have a tarball we release without packaging [15:16] then an upstream branch which is the tarball + packaging [15:16] and we collaborate on that [15:16] I'd concede plumbing stuff, but I like being able to grab a tarball or vcs checkout of some application and have it be ready to build [15:16] if distros need their own tweaks, they branch off it [15:16] so one person spoils it for the rest of us? [15:16] Ng: build for Ubuntu or build for Debian? [15:16] or build for SuSE or build for RedHat? [15:16] if you build something for Ubuntu, it might not work on Debian [15:16] and vice-vera [15:16] plus, the same arguments can apply for code, though admittedly less often [15:17] james_w: one of the major portions of packaging is patches to the code [15:17] that's kinda the point [15:17] here's a better question for you [15:17] why do we have packaging at all? [15:17] if the upstream tarball is perfect as-is [15:17] why do we *need* a debian directory in it? [15:17] why can't we automate the process of taking an autoconfery tarball and turning it into debs? [15:17] packaging is all about hacks to the code [15:18] packaging is changing the code to fit the distribution [15:18] or changing the default configuration of the code or result [15:18] changing install paths [15:18] removing files we don't want [15:18] adding ones that aren't incldued [15:18] etc. [15:18] if the upstream tarball is correct [15:18] (which it often is in a large majority of the cases) [15:18] you don't need packaging [15:19] this is probably the primary reason I don't like packaging-in-upstream [15:19] aside from the issue of autoconf/setup.py/Makefile.PL etc., yes [15:19] you end up with a qmail-esque bizarre situation where you have "the upstream code", and "the upstream approved patches to the code" [15:19] it strikes me you should write all this in a blog post and propose your preferred way instead [15:20] we discussed this in autotools a while back [15:20] the only bit you're really missing is knowing which files are libraries, which are headers, which are data, which are docs, etc. [15:20] a lot of that can be guessed by path [15:20] but you kinda want a manifest-like file that hints to a packaging system [15:21] you also want a standard format file for things like source descriptions, licencing, etc. === binitamshah is now known as binitamshah|away === dendro-afk is now known as dendrobates [15:24] hmm, maybe you would want all that in a directory, maybe you could call it debian/ or something ;-) [15:25] LaserJock: the idea is that it'd be useful for everyone [15:25] and the debian formats are ... bizarre [15:25] like, why the hell would an upstream want to have a separate changelog? [15:25] their version number is already in configure.ac [15:25] unfortunately the discussion kinda veered towards "looks a lot like a .spec file" [15:25] heh [15:26] the problem I see mostly though is upstreams either 1) don't want to package at all or 2) don't want to package for several different distros [15:27] Or don't want to deal with distros at all and just have their users get packages from them [15:27] yes [15:29] One of my upstreams (who uses Fedora) didn't see the point of getting his stuff into distros. [15:29] I got one of his packages into Debian/Ubuntu and he mentioned he'd gotten a lot of new users show up right after I did that on his mailing list. [15:29] Suddenly he got it and he packages his stuff for Fedora now. [15:30] Had he been tuomov, he’d have hated you for getting new users. [15:30] popcon numbers can sometimes make a good impression :) [15:31] must upstreams I know just don't have time to learn .specs and debian/ etc. [15:31] *most [15:32] This guy was distributing rpms already, he just hadn't seen the point in going to the trouble to get it in a distro. [15:33] and then there are upstreams that fork dependencies in PPAs and call it good ;-) [15:34] barry: ping [15:34] you sent a mail as "barry@canonical.com" that got blocked going to udd [15:34] did you want me to add that address? [15:35] jam: dang. yes please! [15:36] hmm.. it says the sender is "now" a member of the list already [15:36] so apparently it should just work now [15:36] I know I have a few accounts that get a bit confused sometimes [15:36] weird, maybe it got held for other reasons [15:36] if upstreams did their job properly, we wouldn't _need_ distros ;-) [15:36] I'm pretty sure it thought you weren't a member for a bit === freeflyi1g is now known as freeflying [15:37] barry: ahh, I see why now [15:37] Reason: SpamAssassin identified this message as possible spam (score 3.8) [15:38] ouch. i should use fewer ! and $ [15:38] barry: though the message that got through was: X-Spam-Status: No, score=-2.2 required=4.5 tests=ALL_TRUSTED,AWL,BAYES_00, DATE_IN_PAST_03_06,MIME_BASE64_NO_NAME,MIME_BASE64_TEXT autolearn=ham version=3.1.7 [15:38] had you posted to udd before? [15:39] As it looks like SQLGrey may have also been involved [15:39] jam: yep, lots [15:39] (I'm pretty sure you have) [15:39] oh, and that sqlgrey stuff may be my local machine, not canonicals [15:40] yeah, it probably is [15:40] was barry trying to sell us on the "effects" bzr can have on our personal life? ;-) [15:40] apparently my mail host likes you [15:40] but canonical's doesn't :) [15:41] barry: so my guess is that SA doesn't like "date in past" [15:41] since it seems to think that it was sent at 4am [15:41] and then the fact that your mail client encodes everything as base64 [15:41] * barry restarts ntpd [15:41] even though it is just text [15:41] * persia reads backscroll and yet again wishes that `gzcat foo.diff.gz | patch` was capable of deleting files [15:41] persia: it is [15:42] Ian Jackson just disagreed with being able to do it, so had dpkg refuse to do so [15:42] jam: i'm posting from a vm and when the host sleeps, my time gets out of whack. unfortunately, that also seems to kill the ntpd service for some reason :( [15:43] persia: I think the reason dpkg refuses is quite logical [15:43] people might think that patching a file out of the tarball is an acceptable way to solve DFSG issues [15:43] when, of course, it isn't [15:44] That's all! [15:44] because Debian would still have been distributing the file in the tarball [15:44] arent you sposed to do that in the orig? [15:44] of course, nobody believed people would ever put debian directories in the tarball ;) [15:45] I agree that it's not an acceptable way to make something DFSG-free (the tarball is shipped anyway), but it would mean that suddenly it wouldn't *matter* if upstream ships packaging (debhelpers -i helps to some degree, but only to some degree) [15:45] it still makes your life hard [15:45] you'd have to review every new upstream version carefully [15:45] Can we revisit that, or is that reviving horses that are best forgotten? [15:45] "grr, upstream added a debian/wibble.foo file that I missed, and now my package fails to install" [15:46] if we were to revisit anything basic like that, we should probably just invent a new source package format [15:46] Yeah, but one should be at least reviewing the file listing and dpkg --contents listings anyway, at an absolute minimum. [15:46] put it in an ubuntu/ directory [15:46] and then be done ;) [15:46] Hrm. tempting.... but maybe not. [15:47] if Colin ever gets hit by a bus, it'll be one of my first jobs ;) [15:47] Mark's been wanting to do that since day one, so I know I'll be allowed [15:48] * pitti tosses http://cdimage.ubuntu.com/daily-live/20091218.1/ Keybukwards [15:48] pitti: way ahead of you ;) already rsync'd down and updating TFTP and NFS roots [15:49] will be interesting to see how this works [15:49] I got good numbers on ratchet [15:49] and I'm getting increasingly convinced that ratchet is slightly slower than max [15:49] good luck! [15:51] what's new in this image? [15:51] james_w: Keybuk's speedup work from today [15:51] (initramfs-tools, etc.) [15:51] well, last night [15:51] mostly initramfs-tools [15:52] the tsort stuff? [15:52] How about devtmpfs? [15:52] no, that was in 18 [15:52] I replaced all of the scripts/local loop with a tiny binary [15:52] that uses libudev to do what all that shell was trying to do *properly* [15:52] cool [15:52] ie. if the device doesn't exist, use netlink to wait for udev to finish with it [15:52] if the device exists, and is in udev's queue, also use netlink [15:53] if the device exists, and is not in udev's queue, done [15:53] also obviously outputs the filesystem type as udev knows it, so we don't have to separately probe fstype/blkid in the initramfs [15:54] one major advantage speed-wise is that it never calls "settle" [15:54]