[00:15] slangasek: do you have an idea what went wrong in bug 328525? [00:15] Launchpad bug 328525 in openldap "package libldap-2.4-2 2.4.11-0ubuntu6.1 failed to install/upgrade: package libldap-2.4-2 is already installed and configured" [Undecided,New] https://launchpad.net/bugs/328525 [00:43] calc: what functionality in OpenOffice needs java, so I have something I can test? [00:45] TheMuso: help - search for item [00:46] er 'Find' [00:46] it doesn't install it by default but i believe if you have either 'openoffice.org' installed or at minimum openoffice.org-java-common it should work [00:48] calc: ok [00:49] calc: there is no search option in the help menu, do I have to go into OpenOffice help? [00:50] I am in writer [00:51] calc: nvm found it [00:56] calc: ok once I made sure I had openoffice.org-java-common installed, the find function in the help worked without issue. WIll add my comment to the bug. [01:07] TheMuso: cool thanks :) [01:08] TheMuso: that uses java so it seems it does work now :) [01:08] Great! [01:08] TheMuso: so i can close the bug after you follow up to it, and if anyone else has troubles they can always reopen it :) [01:09] calc: I've followed up to it. [01:09] TheMuso: ok thanks [01:09] yea in the past ppc wouldn't even compile with java enabled at all so i think it should be fine now that you have verified it [01:10] Sweeet! [01:18] TheMuso: is there a known bug in Jaunty's pulseaudio that'd make it using way more CPU than it should (10-15% with a single sound input) and making the sound to cut sometimes (especially during movies) ? [01:18] TheMuso: I see a few bugs that could cause that on LP but couldn't find THE bug [01:18] stgraber: what ver are you using currently? A new version was uploaded several hours ago, please make sure you have that before filing bugs etc. [01:18] ubuntu11 [01:19] still running 10, will update and retry. [01:19] ok thanks [01:20] a lot of work went into 11, as you might see from the changelog. [01:20] yeah, just saw the changelog on LP :) lot of changes. [01:20] Yep. [01:21] Thanks to Daniel for all that hard work to get Pulse running stable. :) [01:22] good to know siretart is back at work :) [01:28] TheMuso: no glitch so far, seems to have fixed it. thanks [01:29] stgraber: thanks dtchen. :) [01:29] s/thanks/thank/ [01:30] stgraber: did the cpu usage go down at all? [01:30] johanbr: nope but sound is perfect now [01:30] alright. always something. :) [01:31] still some 10% of CPU usage from pulse .. though that's on an Atom cpu so ... [01:32] johanbr: "high cpu usage" was due to two major culprits: spinning on snd_pcm_avail_update() and cpu-intensive resampler. both have been addressed for the most common hardware. [01:35] dtchen: That's good to hear. I should give pulse a try again. Thanks. [01:52] dtchen: thx for fixing pulse [01:52] I have a novice archive-admin question for one of you who's more experienced if someone is around? [01:53] ScottK: Shoot [01:55] StevenK: I'm looking at a package that is one BSD file, one file that's explicitly GPL v2 and later, and the rest say GPL v2. Debian/copyright lumps the V2 files and the V2 and later file together and describes them as V2 and later. [01:55] Ahh, that's licensing [01:55] Is incorrectly describing files as V2 and later that are just V2 a reject or an accept and file a bug? [01:56] ScottK: It doesn't mention the BSD file, and isn't clear, since V2 is different from V2 and later [01:56] It does mention the BSD file. That part is fine. [01:56] The problem as I see it is listing V2 files as V2 and later. [01:57] No advertising clause on the BSD file, so that's OK to mix with GPL. [01:57] It's mythnettv if you'd rather just look. [01:58] ScottK: Right, but the BSD file isn't shown in the copyright file? [01:59] It is. [01:59] It's fine. [01:59] Ah [01:59] It's not separating the GPL v2 only and the GPL v2 and later. Sorry I'm not being clear. [01:59] ScottK: Not sure, to be honest [02:00] I would be inclined to reject it for that; it should be simple to fix [02:00] It's got some interesting packaging issues like build-dep on python-central and build-dep-indep on python-support. [02:01] ScottK: Eeek [02:01] cjwatson: Thanks. I'll do that along with some commentary on the packaging. [02:02] ScottK: that sounds just plain wrong ? [02:03] It is. [02:03] And it's a cdbs rules file, so I have no idea what would actually happen if one built it. [02:03] The guy that uploaded it is new, so .... [02:24] mathiaz: smells to me like a dpkg/trigger bug [02:25] mathiaz: in fact, the 'Processing triggers' line 7 lines earlier is fairly conclusive IMHO :) [02:25] i tried adding a local repo to sources.list but apt just claims 'Ign file: ./ Packages' [02:25] in intrepid [02:25] the same setup works in jaunty [02:26] the sources.list contains deb file:/root/debs ./ [02:26] check which files it's actually accessing [02:26] and in /root/debs/ i ran apt-ftparchive packages . > Packages [02:26] you need to give it a Packages.gz, IIRC [02:26] does the same thing for Packages.gz [02:27] or maybe even Packages.bz2 [02:27] cf. Debian #440973 [02:27] Debian bug 440973 in dpkg-dev "dpkg-scanpackages.1.gz: bzip2 vs. gzip" [Minor,Closed] http://bugs.debian.org/440973 [02:27] anyway, my advice stands, strace it or something to see what it's actually trying to fetch [02:28] --print-uris works, too [02:29] cjwatson: hmm that seems to work with bzip2, but doesn't seem to be needed on jaunty for some reason [02:30] hmm actually that didn't seem to work but it made the Hit/Ign line go away, i'll strace and see what is going on [02:30] apt (0.7.17~exp2) experimental; urgency=low [02:30] [ Eugene V. Lyubimkin ] [02:30] * apt-pkg/acquire-item.cc: [02:30] - Added fallback to uncompressed 'Packages' if neither 'bz2' nor 'gz' [02:30] available. (Closes: #409284) [02:30] apt | 0.7.14ubuntu6 | intrepid | source, amd64, i386 [02:33] ok so it did download it, hmm [02:34] but it still doesn't show up in apt-cache policy [02:34] i see it in /var/lib/apt/lists/_root_debs_._Packages [03:06] * calc kicks himself [03:06] i am trying to install amd64 debs on... i386, argh!!! [03:06] no wonder it didn't work [03:06] cjwatson: sorry for bugging you earlier :\ [03:20] way cool. kernel panic on hibernation now. I'm sure this was working a week ago! [03:20] Hobbsee: what wireless driver are you using? [03:21] TheMuso: iwl3945 [03:22] Hobbsee: we're moving the panics closer to the start of the uptime [03:22] lifeless: ahhh. is that the problem... right ;) [03:22] TheMuso: abentley was reporting hangs on iwl3945, on intrepid, but didn't that get a kernel update recent? [03:23] not sure if it got a kernel headers update, though? [03:24] lifeless: don't know. [03:24] oh, hmm. they're all together [03:40] * calc deletes his remaining i386 vm's since he doesn't need them anymore [03:47] * Amaranth reports an i386 OOo bug for calc === bluesmoke is now known as Amaranth [03:59] .win 4 [03:59] Grmph. [04:05] Amaranth: you can keep it ;-) [04:07] Amaranth: i wasn't able to run amd64 vm's until i upgraded my laptop this past month since the cpu didn't have the right support [04:07] Amaranth: and so whenever i build test packages i had to remember to build them for i386, but i don't need to anymore :) === slangasek changed the topic of #ubuntu-devel to: Archive: feature-frozen | frozen for alpha-6 | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-intrepid | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | LP believed fixed - please report any further timeouts to #launchpad === slangasek changed the topic of #ubuntu-devel to: Archive: feature-frozen | frozen for alpha-6 | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-intrepid | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs [04:51] slangasek: it's Tuesday already? :-) [04:51] yep [04:52] By almost 5 hours [04:52] UTC time === bluesmoke is now known as Amaranth [04:56] TheMuso: should be end of Tuesday UTC :-) [04:56] LaserJock: What, and push the alpha out bya day? :p [04:56] LaserJock, Why? We've been midnight-starting for a while now. [04:56] Often enough the alpha doesn't get out until well into Friday on this side of the world anyway. [05:00] persia: I don't have a particular reason. I need to do a couple Edubuntu uploads to make edubuntu-desktop properly installable but I think that shouldn't be a problem. [05:00] LaserJock, The do them. It's a "soft freeze". You should feel guilty that they are late. [05:00] s/The/Then/ [05:00] Just make sure to inform the release managers if the Edubuntu alpha CDs need rerolling once candidates are ready. [05:01] (and don't do it too often or the release managers may not reroll) [05:02] Or the release managers might sharpen weapons while re-rolling [05:02] That too :) [05:02] * Hobbsee sharpens her Long Pointy Stick of DOOM!!!!!!!!!!!!!!!™ [05:03] ah oh [05:03] :) [05:23] How often does ddebs.ubuntu.com get updated with dbgsym packages? [05:26] nvm my local screw up here === asac_ is now known as asac [06:42] Tonio_: hrm; why does "libk3b4" contain libk3b.so.6? [06:43] how do packages get included into the synaptic package manager? like how is it decided that a particular package needs to be there in the online repositories [06:50] good morning [06:52] slangasek: I just uploaded edubuntu-artwork. Due to a miscommunication pitti removed the entire source package instead of just the edubuntu-artwork-usplash .deb so it's going to land in NEW :( [06:54] l3ftm1n0r, Essentially, a developer uploads it. See https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages for more information. [06:59] persia, thanks [07:00] persia, the reason i asked was that some packages for ubuntu arent on the synaptic but are available on the developers site ( case in point frostwire and limewire deb packages) [07:14] l3ftm1n0r: often times those sorts of packages are not in Ubuntu for license/patent reasons [07:16] LaserJock, ok. but i guess frostwire is os? [07:19] l3ftm1n0r: I think there were still some problems with it, I can't remember for sure though [07:20] LaserJock, maybe the whole jacking off the Ui of limewire :P [07:33] slangasek, to avoid going through binary NEW? [07:50] damn, we need a fresh pidgin once again :/ [07:51] 2.5.5 works ;) [07:51] Good morning [07:51] calc: pong [07:52] also good morning from here ;) [07:52] LaserJock: oh, sorry; I thought you entirely wanted to drop it [07:52] pitti: no, we have other artwork (gdm, FF homepage, etc.) that we still keep [07:52] it's all in the same source [07:53] unlike ubuntu I think which has separate source packages [07:53] pitti: no harm done though, we got it back :-) === tkamppeter_ is now known as tkamppeter [08:27] thanks slangasek [08:35] pitti, hi [08:36] hey tkamppeter, good morning === azeem_ is now known as azeem [08:48] james_w: could you upload the patch for python-crypto? I'm still in Hamburg [08:49] doko: james_w is in .au :) [08:49] ahh [08:49] he was awake 1h ago :) [08:50] doko: I would have if it wasn't in main :-) [08:50] doko: and james_w is not in core-dev :) [08:50] aha ... [08:50] ok, will do tomorrow [08:50] thanks [08:51] totally unjustified in my opinion, but looks like James is working on it: https://wiki.ubuntu.com/JamesWestby/CoreDevApplication :-) [08:51] * pitti puts up the "James for core-dev!" sign [08:52] pitti: you can speed up the process by adding your endorsement to the wiki page :) [08:52] * dholbach hugs pitti, james_w and doko [08:52] * pitti hugs dholback [08:52] * james_w hugs dholbach [08:57] doko, don't you hug anybody? [09:00] * seb128 hugs dholbach [09:01] * dholbach hugs seb128 back [09:01] * dholbach hugs ara too [09:01] * ara hugs dholbach :D [09:05] * juanje likes hugs as well and hugs dholbach :-P [09:05] * dholbach hugs juanje [09:06] juanje: (-: ¡hola! ¿como estas? :-) [09:07] dholbach: fine, trying to do so many things at the same time... but I like to come to this channel because is so full of love :-D hehe [09:09] juanje: so how's guadalinex coming together? [09:09] dholbach: I post it some things we've done in Guadalinex (btw, you are there :-P) and I'm working now in some i18n stuff, some documentation in Spanish for our collaborators and a bit on Ubiquity and casper [09:10] juanje: are you in touch with the ubuntu installer folks for ubiquity and casper? [09:10] dholbach: I'm still have some things I don't know well how to work with in Launchpad, but I'll try step by step... [09:11] dholbach: no much for now, just about some missing strings for translations, but I planning to do for some stuff. [09:11] juanje: just ask :) [09:12] dholbach: but actually we did a kind of wrapper for the frontend so we don't need to touch so much by now the Installer [09:13] dholbach: anyway, I was wondering if is still possible to touch things there (ie. in casper) [09:13] juanje: evand and cjwatson might be good people to judge if it can go into Jaunty or if it should wait [09:14] dholbach: yeah, I guessed so, I was thinking to ask them today or tomorrow (before it be too late) about it === The_Company is now known as Company [09:16] dholbach: but I like to create branches with solutions (when I know about it) before put a bug a bug or bother someone [09:17] dholbach: maybe I should ask first, i don't know.... [09:17] juanje: best to just ask quickly :) [09:17] dholbach: yeah, you right ;-) [09:33] slangasek: concerning k3b that's for historical reasons... previous version was libk3b3 and contained libk3b.so.5, same for the one before etc... [09:34] yay for historical raisins [09:34] slangasek: I prefered not to change the naming schema, still debian will use that one to (they started to package it) in order to remain sync [09:35] slangasek: also, that upload was targetted to my ppa, shouldn't have reached the archives... we're currently testing it and I'll it reviewed before upload [09:35] mvo: great news, the new libcompizconfig does, like I suspected, take ca. 4-5 seconds away from GNOME login. Keybuk will be happy probably as well, if he was the one doing boot time improvements. [09:35] slangasek: I've reuploaded back the kde3 version for the moment... [09:35] pitti, hi [09:35] hey tkamppeter [09:36] Mirv: excellent! thanks for confirming this :) === pbn_ is now known as pbn [09:37] directhex: to say it differently, I prefer to stay sync with debian naming convention on that package, and I don't have the all history behind it, it's just the way it is for long now... [09:43] slangasek: hum, just looked again, k3b-kde3 had libk3bdevice.so.5 and libk3b.so.3 in fact... [09:44] slangasek: now it's been sync to be all .so.6.... so maybe I should fix to libk3b6, you're right [09:46] slangasek: but I have to see with debian since afaik, the maintainer is using 4 too... [09:52] dholbach, james_w: nbs and edos up again (and sorry for the long delay...) [09:52] dholbach: i'm updating harvest-data to point to the right urls. [09:54] * dholbach hugs gaspa [09:54] awesome [09:55] dholbach: :) [09:55] * dholbach hugs gaspa [09:55] awesome :-) [10:07] Keybuk: hi. the new libcompizconfig should do something visible to your grub -> desktop bootcharts :) in the case of warm login the difference is huge, since compiz was the only thing that prevented warm login (no disk access needed) from being ca. 3s [10:08] Mirv: yes, I know, mvo and I have been discussing it for a while [10:08] Keybuk: ok. [10:15] slangasek: I uploaded base-installer to fix bug 340308 [10:15] Launchpad bug 340308 in base-installer "keyboard layout gets reset when console-setup is installed during base system installation" [Undecided,Fix released] https://launchpad.net/bugs/340308 [10:16] ubiquity ought to see an upload too [10:22] doko: with pycentral, how can I tell XS-Python-Version: to only use python >= 2.5? [10:22] doko: or do I need to use pysupport for that? [10:23] pitti: 2.5- [10:23] doko: debian/pyversions is already 2.5-, but it still tries to compile for 2.4, which fails [10:24] Keybuk: ah, indeed; that's not documented on http://wiki.debian.org/DebianPython/NewPolicy [10:24] Keybuk: thanks [10:25] though I had endless problems with pycentral last night, and switched to pysupport [10:25] I had lots of problems with that too, but at least they weren't endless ;) [10:25] pyversions: error parsing Python-Version attribute [10:25] it doesn't seem to like this very much [10:31] Keybuk: I give up, and switch to pysupport, too, I think [10:33] pitti: try ">= 2.5" for XS-Python-Version (it's mentioned on the wiki page and pyversions seems to like it too) [10:33] aah [10:41] slangasek: ok, ubiquity and casper (for a slight security problem) uploaded now too === svolpe_gerrath is now known as svolpe [10:50] Keybuk: could you look at bug 340188? it has a udev debug log now, although the problem went away upon cranking up the log level [10:50] Launchpad bug 340188 in debian-installer "Jaunty alternate ISO fails to partition using Guided / use entire disk" [Undecided,New] https://launchpad.net/bugs/340188 [10:51] cjwatson: I have too much else to do right now, sorry [10:51] Keybuk: this is critical for alpha-6 - can I have some advice at least? [10:51] what's the problem? [10:52] Keybuk: recurrence of the partitioning races we saw in alpha-5 [10:52] BLKPG_DEL_PARTITION* then BLKPG_ADD_PARTITION says busy [10:52] meh [10:52] I've had multiple reports [10:52] are there change events i nvolved? [10:52] yes [10:52] then vol_id or something is probably running on the partition [10:53] I had a random thought [10:53] I asked the reporter to add a udevadm settle before we tell parted_server to commit, and that didn't help [10:53] why do we even have those rules in udev in the installer? [10:53] libparted *does* open devices read-write [10:53] do you use /dev/disk/by-uuid at all? [10:53] or udevinfo ? [10:53] why does libparted open devices at all? [10:53] err, it kind of has to write to them sometimes [10:54] I don't think we use /dev/disk/by-uuid/ [10:55] I was wondering if adding system("udevadm settle") after the BLKPG_DEL_PARTITION calls might be a good idea [10:55] though I guess postinst's and stuff might [10:55] settle won't help here [10:55] since it won't want for the inotify event [10:55] if libparted closes a device, at some point later udev will check the device for changes [10:56] oof. we really need a way to make that synchronous [10:57] Keybuk: I've had scattered previous reports suggesting that this may happen in ubiquity too, where it isn't so easy to just strip stuff out of the udeb [10:57] ...is there a bug about misspositioned window decoration known, or is my local config screwn up? [11:01] basically, this sounds as though the problem is that if you open a device read-write and close it, then at some random point later udev will open it and fiddle with it, and you have absolutely no way to control when [11:01] right [11:01] because udev is checking to see what you changed [11:01] I have a really hard time seeing how this could possibly be fixed anywhere other than udev [11:02] sure, don't open block devices for writing unless you intend to write to them? [11:02] I don't see why libparted is doing that if it's about to remove the partition [11:03] it's doing it at some previous point for something else, I imagine, and it's just outracing udev [11:03] why can't udev also check that the inotify queue is empty when you say udevadm settle? [11:03] because there's no such thing [11:04] where are you adding the settle call? [11:04] it could at least check for pending inotify evenets! [11:04] events [11:04] if it's also affecting ubiquity, it would need to be in parted itself, surely? [11:04] cjwatson: it doesn't work that way [11:04] I added it in partman-base right before it tells parted_server to COMMIT [11:05] that code is common to d-i and ubiquity [11:05] Keybuk: why doesn't it work that way? [11:05] when you close the fd, the kernel writes to inotify watchers, does it not? [11:06] when you run udevadm settle, you don't have access to udevd's inotify file descriptor [11:06] obviously [11:07] Keybuk: can udevadm not communicate with udevd? [11:07] that would be a hell of a lot of overhead [11:08] better than the sleep 5 I'm going to have to insert otherwise [11:08] since you're not even giving me a chance to think about this, go with the sleep 5 for now [11:09] I've no problem at all with you thinking about this :-) It's just that you're rejecting everything I come up with out of hand and this is making me (I think understandably) rather frustrated. [11:09] I told you, I'm in the middle of other things right now [11:10] hassling me about a bug when I've already said I'm busy is not exactly going to elicit the most helpful responses from me [11:10] well, I'm sorry that things are urgent [11:10] everything's urgent [11:10] we're at that point of the release cycle [11:10] I've lost several days fighting with this [11:12] I assume that this also affects non-LVM cases? [11:13] yes [11:13] what syscall actually returns an error? [11:13] BTW, if the answer is "go away for several hours and I'll look later today" or something, that would be fine - you just didn't give me any idea of timescale [11:15] ioctl(fd, BLKPG, {BLKPG_ADD_PARTITION, 0, datalen, data}) [11:15] I'm trying to understand where you're thinking of sticking the settle call [11:15] I assume you're looking through the libparted code [11:15] is there an obvious point to do so? [11:15] ie. you can see it opening block devices, closing them again, etc. [11:17] it doesn't make any sense to me that it's the BLKPG_ADD_PARTITION that fails with "in use" [11:17] note that errors from BLKPG_DEL_PARTITION are not checked [11:17] I expect that it's failing too [11:17] I could understand if it were the BLKPG_DEL_PARTITION :) [11:17] KaiL: file it, I had somebody show me that yesterday (and also asked them to file it) [11:17] isn't that a bit error-prone? [11:18] well, you'll always get an error from BLKPG_ADD_PARTITION if BLKPG_DEL_PARTITION failed, so it doesn't matter except in that you get slightly more confusing error messages [11:18] where were you thinking of putting the settle? [11:18] the point where I asked a user affected by this to add udevadm settle is outside libparted, but effectively immediately before the first BLKPG_DEL_PARTITION [11:19] thinking about it, there's of course no point in calling settle after BLKPG_DEL_PARTITION [11:19] indeed [11:19] I'm assuming it's the partition deletion that's actually failing [11:19] ie. you're doing [11:19] yes, I think so [11:19] [11:19] [11:19] [11:19] and the delete is failing, because changing the block device causes it to be opened [11:19] right [11:20] so I can probably fudge things such that the change goes away [11:20] but I'm concerned that there will be cases where I can't, simply because it's a race [11:20] sure, so there's a few obvious solutions [11:20] firstly is to try and eliminate the change [11:20] the second is to fix settle so that you can call it between the change and delete and have it actually wait [11:21] or perhaps something based around udevadm control (I see stuff like --stop-exec-queue?) [11:21] right, that's another option [11:21] also you can just do evil things [11:21] before the change, do [11:21] echo -n remove > /sys/block/*/*/uevent ;) [11:21] (filling in the *s) [11:21] heh [11:22] you'll lose the device node though [11:22] I suspect the change is actually fairly unrelated (i.e. at that point I don't yet know I'm going to remove the device) [11:22] right [11:22] fixing settle seems the right approach [11:22] but ok, that gives me enough to work with [11:22] thanks a lot [11:22] the problem there is that udevd receives the inotify watch [11:22] but doesn't immediately process it [11:22] instead it asks the kernel to send a change event for that device [11:22] so there's a gap between the two [11:23] I'm thinking that the right solution there is to add a second line to /dev/.udev/uevent_seqnum when inotify events are received [11:23] and clear that second line when uevents are received [11:23] and have udevsettle wait unconditionally if that second line exists [11:24] that's still not perfect though [11:24] since you don't know that there aren't pending inotify events that udevd hasn't picked up yet [11:24] you'd have to make sure that udevd picks up inotify events before you do the rest of the settle [11:24] that wouldn't be atomic though :-/ [11:25] I have a thought [11:26] udevadm control obviously sends messages to udev [11:26] at the moment, it looks like udevd might actually synthesise the change event after it has received a remove event for the same device, in some cases [11:26] cjwatson: that shouldn't happen [11:27] no idea whether there's a sanity check on it though [11:31] this is actually a fun problem [11:31] a test case should be easy to do [11:31] have a udev rule that sleeps for a minute on change [11:31] and try removing a partition during that minute === lamont` is now known as lamont [11:32] oh, good idea [11:32] ok, will do that [11:34] right, need to download a couple of dailies now for these HPs [11:34] I'm all yours for a bit ;) [11:34] this USB key has moblin on it ... *screams a war cry and deletes it* :p [11:35] Hah [11:36] sladen, bug 340423; I hope that information helps ;) [11:36] Launchpad bug 340423 in metacity "missplaced window decoration" [Undecided,New] https://launchpad.net/bugs/340423 [11:38] cjwatson: obv. you need to "open" the block device for that minute [11:38] I was just about to say the exact same thing :-) [11:38] ie. RUN+="/bin/sh -c 'sleep 60 < %k'" [11:38] just setting that up now [11:38] sorry, you know how it is [11:39] certain debugging patterns are so deep-rooted in your brain you forget that other people might now know them enough to know which one you mean [11:39] cjwatson, do you plan a d-i upload before A6 (i see no changes in bzr) [11:39] * ogra is wondering if the seed changes will end up in the slug firmware image without rebuild [11:40] ogra: seed changes shouldn't need a d-i upload [11:40] d-i uploads are just for the initrd bit [11:40] right, but the firmware is a bit special [11:40] err $root/$name not %k ;p [11:41] i wasnt sure it pulls in flash-kernel automatically [11:41] well, you certainly can't delete a partition if anything has it open [11:41] but i trust you if you say it is so :) [11:41] BLKPG ioctl returns -EBUSY [11:42] ogra: it should just require it to be priority standard; let me check [11:43] prio should be fine, i just wasnt sure the info ends up in the initrd without rebiuld, since its so oddly merged into a firmware image [11:44] yes, it's priority standrd [11:44] a [11:44] ogra: well, the point is that this isn't information that goes in the initrd at all [11:44] ogra: remind me which d-i image this is? [11:45] ixp4xx/netboot? [11:45] yep [11:45] di-nslu2.bin [11:45] ogra: the way the initrd image is packed is essentially not relevant here [11:45] ok [11:46] ogra: what happens is that the initrd contains code to bring up the network and retrieve package lists from it (net-retriever) [11:46] just wanted to be sure it pulls the info late enough and doesnt need it inside [11:46] right [11:46] ogra: and anna then figures out from the information delivered by net-retriever which packages it needs to install [11:46] ogra: so as long as it can bring up the network, it'll be fine [11:47] it'll syslog what it installs, though, so you can check without having to wait for the end of the install [11:47] or you can look in /var/lib/dpkg/status in the running installer after it installs additional components [11:47] right, but it takes over 8h to do one install so i want to exclude all surprises as early as possible :) [11:48] its about 3h to get to net-retriever [11:51] fair enough :-) [11:51] Keybuk: what I'm seeing here is that settle waits for the change events; presumably it was lucky enough to happen to run after udevd processed the inotifies [11:51] so the race is actually between inotify and udevadm settle [11:52] cjwatson: right [11:52] well [11:52] the race is between the close() and the settle [11:52] if you do them quick enough, udev may not have received the inotify event or sent the change event [11:54] yeah, I think I might nobble udevd to be slower about processing the inotify or something [11:54] for the purposes of reproducing this [12:00] * cjwatson hacks up 'udevadm control --slow-inotify' [12:13]