[01:15] chrisccoulson: ok; so it's not synchronous, but does it still give us enough information to fix? There can't be too many calls to XRRSetScreenSize in the code :) [01:19] slangasek - there won't be many calls to it, but it would be good to get an xtrace log to see what parameters are being passed in the call [01:19] chrisccoulson: ok, I'll find the time somewhere to do an xtrace run; probably will be after RC [01:20] i'm just looking at the very limited randr documentation for RRSetScreenSize, and it says this: "All active monitors must be configured to display a subset of the specified size, else a Match error results" [01:20] but that doesn't say much. i think i'll have to just look at the server code instead [01:22] smoser, pitti: "in th past, that has had the AMIs in paren for ec2" - did that not work right on the first pass? [01:24] pitti: yes, we use the AMIs instead of the datestamps for EC2 on the tracker because that's the unique identifier within EC2 and how testers locate it (in theory you could re-bundle the same UEC image more than once for publishing to EC2, so the datestamp isn't unique) [01:25] chrisccoulson: anyway, to fix this properly, wouldn't libxrandr have to be fixed to make RRSetScreenSize /check/ for that Match error (_XReply)? [01:29] slangasek - _XReply is for fetching the response back from the server (and also fetching the errors). However, it looks like the server doesn't actually give a response for RRSetScreenSize, and I assume this is why there is no call to _XReply there [01:29] ah [01:30] libxrandr (and libx11) generally doesn't check returned errors either - it is up to the applications to trap the errors and deal with them appropriately [01:30] in this case, the error goes untrapped because g-s-d is not expecting it [01:40] slangasek, i think we got it worked out. [01:40] smoser: well, if it didn't publish right the first time, I'd like to understand why, since I need those scripts to work when I go to publish the RC on Thursday :) [01:42] superm1: mythbuntu candidate images are up; no known RC showstoppers remaining anywhere, please test [01:42] cody-somerville, luisbg, TheMuso: xubuntu, ubuntustudio are also up [01:42] slangasek, everything worked fine. [01:42] smoser: ok, so pitti just didn't know to look at the table? [01:43] slangasek, pitti just didn't know that we wanted the AMIs to appear as the "release" [01:43] so at first he put 20091020.1 [01:43] * slangasek nods [01:43] everything worked perfectly otherwise. [01:44] as a point of reference, full build and publish took 95 minutes [01:44] publish is about 65 of that i think. something around there. [01:44] smoser: ok, thanks - I'll be sure to schedule accordingly [01:45] slangasek, but also remember that we can publish ahead of time, and just not set public [01:45] setting public takes < 1 minute [01:45] so if these RC candidates are going good, we publish them to RC but keep them private, then at "release time" we just flip them to public [01:46] smoser: right; I still have to remember to do the publishing far enough in advance :) [01:46] once published as private we even have all the ami/aki/ari ids. [01:46] yeah, theres almost no real reason to not do that right now [01:46] as we can just delete private ones with no harm [01:46] we do that kind of pre-publishing with the ISO images too [01:46] different implementation but same goal [01:47] slightly different implementation :) full of a lot less slop [01:48] what I mean really is that there's already a "pre-publish stuff" slot in the schedule, to an extent [01:48] right. === MsMaco is now known as maco [02:39] Hrm. Is it known that usplash doesn't pulsate when asking for the encryption passphrase, or is that what is wanted now? [02:41] Seems not. [03:02] guys, new bugfix release of a webkit is out [03:03] hope its not too late for an update [03:05] also can somebody update midori to 0.2? [03:08] avb: https://wiki.ubuntu.com/KarmicReleaseSchedule upstreamversionfreeze was a little while ago (Ubuntu is releasing in a week and a half!) [03:09] sladen: but as i know during this time its still allowed to upload minor updates, no? [03:10] issue is that 1.1.15.2 contains couple bugs which leads to crash and cosing some usability problems which was fixed in 1.1.15.3 [03:10] this is just a bugfix release, no new features of code changes was introduced [03:10] all is kept for 1.1.16 [03:12] avb, then submit a FFe https://wiki.ubuntu.com/FreezeExceptionProcess good luck :) [03:12] porthose: thanks for a link [03:12] ill try [03:13] porthose: same policy goes for universe as well? [03:14] they are different for main and universe read the doc :) [03:14] yes, i see now :) [03:15] as long as it's just bugfixes, you have a chance of getting changes in === dmb__ is now known as dmb === robert_ancell_ is now known as robert_ancell === kirkland` is now known as kirkland === robert_ancell_ is now known as robert_ancell [07:11] I had an Idea and the guys in #ubuntu-offtopic suggested I tell everyone here [07:11] When you go to make a file Public, Ubuntu should ask "Which are you going to be sharing this with, Windows or Linux?" Then decide which to install, gShare or Samba [07:15] RPG_Master_: Why not just unconditionally install samba? What does setting up a FTP server & advertising it via zeroconf get you over just setting up a CIFS share? [07:19] RAOF: It's FLOSS.... [07:19] So's samba. [07:19] * RPG_Master_ is 15 with no coding experience [07:19] :/ [07:19] sorry for waisting your time :( [07:20] No problem. [07:20] It's not a waste of time if it ends up being interesting :) [07:20] RAOF: so there is no benefit over Samba? [07:21] It probably has fewer buttons to tweak. [07:21] But I don't think it's got any obvious advantages, no. [07:21] I just kinda assumed because samba is based off of a Microsoft product there must be a better way of doing file sharing... [07:23] Not really. CIFS works. [07:23] RAOF: Well, thanks. At least I learned something :P [07:23] There's plenty of useful, good, Microsoft technology. Just because it's Microsoft's, doesn't mean it's bad :). [07:24] samba isn't based off a Microsoft product; it's protocol-compatible with Windows filesharing [07:24] Ah, so it was just used by Windows? [07:24] the protocol isn't even Microsoft's, it's IBM's ;) [07:24] :P [07:24] (with a few decades of embrace-and-extend piled on...) [07:24] Which is why its good :P [07:25] slangasek: Heh. You learn something new every day :) [07:25] RAOF: really :P [07:25] RAOF: somewhere there's a history of the fact that when Samba was getting started, it was because Tridge wanted to use it for connecting to *Unix* machines; then someone came along and said "oh hey, this works with Windows too!" [07:25] I miss some of the features that decnet had that went walkies when nt3 etc came out. ms-net v1 was embraced and extended by all sorts of companies. [07:26] gah. s/decnet/pathworks/ [07:26] Well then, we should change the name of the network folder to, say "Network Folders" [07:26] :P [07:26] Instead of Windows Folders [07:27] Wait [07:27] *Windows Networks [07:28] true, we should [07:28] I think that warrants a bug on the gvfs-backends package [07:31] slangasek: Hey, I think I just contributed to Ubuntu :D [07:31] RPG_Master_: thanks :) === tkamppeter_ is now known as tkamppeter [07:42] Well, I am glad I could contribute *something* to ubuntu after all that its done for me... I want to hurry up and learn python so I can do more! :) === Whoopie_ is now known as Whoopie [07:54] Good morning [07:54] slangasek: AMIs> the previous images didn't have AMIs, so I just added the build timestamps; I'm more educated now [07:55] pitti: morning [07:55] pitti: EC2 images /always/ have AMIs, they may just not have been posted there :) [07:55] slangasek: ... in the tracker, I meant [07:55] (s/may just not have been/weren't/) [07:56] yeah, I was just confused === cdE|Woozy_ is now known as cdE|Woozy [08:19] hmm... this has happened twice now: something keeps adding a second keyboard layout to GNOME (US, in addition to my native Finnish), and then switching to it; I've deleted the US layout yesterday, and it's back today [08:20] any suggestions? === porthose is now known as porthose|afk [09:03] liw: did you have US selected in gdm? [09:03] pitti, no. the keyboard layout changed on the fly, suddenly, in the middle of typing [09:03] (not that I know of, that is; if it's US there, I didn't choose it) [09:04] (stupid US keyboard layout, not fit for humans ;-) [09:04] it's the best ever for programmers :) [09:04] * pitti switched from de to us a few years back [09:04] suddenly vim, C, LaTeX etc. were so much easier :) [09:05] liw: anyway, could you check this: [09:05] gconftool -g /desktop/gnome/peripherals/keyboard/kbd/layouts [09:05] this probably has fi and us right now [09:05] liw: reset it with gconftool -u /desktop/gnome/peripherals/keyboard/kbd/layouts [09:05] produces [fi] but since I've already removed the extra layout, that is not surprising [09:05] then log out, back in, and make sure that you select fi in gdm [09:05] liw: or just keep it as it is, and log out/in with fi selected in gdm [09:05] does either of those add us/ [09:06] ? [09:06] why does it matter what I have in gdm, since it worked fine for hours? [09:06] liw: we had a recent change in gdm which fixed the selection of keyboard layouts that you pick in gdm [09:06] liw: it was really spontaneously added while gnome was running? [09:06] yes [09:06] er [09:06] or it was there all the time and you just didn't notice? [09:06] pitti, he said that the layout changed during session use [09:06] seb128: well, that's not the same [09:06] the layout changed in the middle [09:07] you could accidentally press both alt keys or so [09:07] I don't know if the us keyboard was there from the beginning [09:07] pitti, right [09:07] it doesn't prove that the new layout was _added_ to the gconf key [09:07] pressing both alt keys does not seem have an effect [09:07] * fatal^ switches keyboard layout on both-shift .... don't know if it's the default. [09:07] liw: system -> prefs -> keyboard -> layouts -> layout settings can set a key combination for switching layouts [09:08] fatal^: I believe nothing is the default [09:08] hm, gdm did have us as they default layout, how stupid of it [09:09] pitti, there is no key combo defined for switching layouts [09:09] (which is good, since if there were, I would be hitting it randomly and tearing my hair out) [09:10] if I choose US layout in gdm, and log in, I have US layout [09:11] however, that's not what happened this morning: I was typing happily for hours when it suddenly changed in the middle of a word [09:12] in the middle of a word with letters with umlauts, so less than a second earlier I still had the Finnish layout... [09:12] liw: I meant, if you chose fi layout and didn't have us configured before, do you get us configured in GNOME after that? [09:13] so, I have no idea what could have changed the layout then, I'm afraid [09:14] pitti, yeah, it's very mysterious; I'll keep an eye on things and see if I can debug further if it happens again [09:15] (too many moving parts and layers in computers these days, and I've put more in myself: keyboard -> kvm switch -> desktop machine -> kernel -> x -> gnome -> synergy -> laptop -> laptop's x/gnome stack *sigh*) [09:25] ~[5~[5~/win 43 [09:25] nice. [09:26] the examples directory on the current iso desktop is a blank document icon, bug? [09:36] What order do I approach people to get a fix into karmic at this point? main-sponsors then release, or the other way around? [09:39] maxb: since it can't go into RC any more, it's best to subscribe ubuntu-release to the bug and nominate it for karmic; you can sub the sponsors at the same time [09:40] OK, sponsors are already subbed, just wasn't sure on the protocol of when to sub ubuntu-release [09:40] "nominate for karmic" - dunno if you look at that, but I don't [09:43] evidently not, since I've had it nominated for karmic for a long time, and it hasn't garnered it any attention [09:43] yes, anybody can nominate, so nominations are really just noise today [09:44] Sad, but given I don't have a suggestion how to fix it, I can't really complain. [09:45] slangasek: I do if I get bug mail through u-release subscription [09:45] pitti: right, but the subscription's the important thing then, not the nomination :) [09:45] pitti, want to win quite some CD space? [09:45] but I don't watch the nomination bug list in general, indeed [09:45] seb128: gimme, gimme, gimme! [09:45] pitti, seems gnome-games documentation has not been langpacked for some reason [09:45] seb128: you're proposing to replace GNOME with XFCE? [09:46] and that's quite some images there [09:46] :) [09:46] I'm running baobab on the current iso [09:46] replace gdm with startx [09:46] /etc/init/startx.conf [09:46] it's like 10 megs of documentation, if it was in langpack we could win some [09:47] we aren't under serious space pressure for karmic, so I woudln't throw a lot of effort on it [09:47] but if it's cheap, why not [09:47] (like, a no-change rebuild) [09:47] well, I'm wondering if it's just a matter of rebuild [09:47] but it was uploaded on september 24 [09:47] but it was uploaded on september 24 which should be after your change [09:47] but we can only do that if we're actually going to update langpacks again [09:48] is there any way to see from the build log if the stripper was in place? [09:48] sure [09:48] oh right [09:48] pitti, http://launchpadlibrarian.net/32242856/buildlog_ubuntu-karmic-i386.gnome-games_1%3A2.28.0-0ubuntu1_FULLYBUILT.txt.gz [09:48] ^ build log [09:49] are we assured of having time to get the translations back into the final langpack export for release if we do that? [09:49] hum [09:49] "pkgstriptranslations: gnibbles does not contain translations, skipping" [09:50] weird [09:50] oh, translations, dog [09:50] doh [09:50] ignore that [09:50] slangasek: the condition for that is that the langpack build is started after gnome-games finished to build on at least one arch [09:51] (it doesn't go through Rosetta, it's just parked in soyuz) [09:51] well it's not worth bothering if we don't have anything to put on the CD instead anyway [09:51] but if we could add some extra langpacks... [09:51] ArneGoetje: did you schedule another langpack export/build over the weekend? [09:51] pitti: oh, really? [09:51] seb128: yeah, it'd just be an extra langpack [09:52] slangasek: yes, it just uses launchpadlib to grab the built stuff straight from the librarian, which has it seconds after the build finished [09:52] so, I think we should consider updating the langpacks again independently [09:53] and if we do that, we could just as well do the rebuild, but then only on Friday [09:53] pitti: doesn't that mean translators also have no opportunity to extend/fix these translations? [09:53] slangasek: correct; at least not in Rosetta, only by patching [09:53] slangasek: long term this should be fixed, of course [09:54] but given how documentatino translation works right now, it's a major project [09:54] * slangasek nods [09:54] i. e. their po files could be imported and changed in Rosetta, but you'd have to add them to the source package [09:55] since documentation is translated at build time [09:55] sure [09:55] slangasek: and then we of course need rosetta support for "translating" images :) [09:55] just make sure the images are all svg, and use po4a [09:57] seb128: hm, I think this case is a pkgstriptranslations bug [09:57] I don't think we should mess with it in karmic any more [09:57] right [09:57] we don't really need to win space now anyway [09:57] but would be nice to fix next cycle [09:57] pitti, do you want me to file a bug? [09:58] in which case what do I write in the bug? ;-) [09:58] also, _shht_ we still need some potential savings up our sleeve for further releases :-P [09:58] lol [09:58] seb128: "gnome-games help not stripped", and a pointer to the build log should suffice [09:58] pitti, ok thanks [10:04] pitti, bug #457027 [10:04] Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/457027) [10:05] seb128: merci [10:06] pitti, de rien === steveire_ is now known as steveire [10:51] asac: what do we do about the firefox installer? [10:52] apachelogger: not sure. [10:52] apachelogger: question is what _can_ we do [10:52] apachelogger: you think you can upload a package with all .po things sedded? [10:52] for after RC? [10:53] we should definitly check with Riddell [10:54] well, I could push a package with string changes, utc could probably update the existing translations to match new template [10:54] dpm: ping [10:58] hey apachelogger [10:58] it's about the above? [11:00] dpm: aye [11:00] if you upload a new package and it contains translations and a new template, they should be imported automatically, but you can ping us to double-check [11:01] have to run some errands [11:01] bb in 2h [11:01] dpm: is there some tool to export all existing pos of a package? [11:03] apachelogger, Launchpad can do that (exporting a tarball with all PO files). As the project maintainer you should be able to do that (let me give you the link). If you can't, you might be hitting bug 425578, in which case I can do the download for you, if you like [11:04] Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/425578) [11:07] apachelogger, try this link -> https://translations.launchpad.net/ubuntu/karmic/+source/kubuntu-firefox-installer/+export (it's from the main template page at https://translations.edge.launchpad.net/ubuntu/karmic/+source/kubuntu-firefox-installer/) [11:07] dpm: thanks :) [11:08] np [11:08] just let me know if there is anything else I can do [11:09] apachelogger, also, now that I've got you here, do you think you could have a look at bug 439964? [11:09] Launchpad bug 439964 in kubuntu-firefox-installer "Non-latin characters are turned into ? in Firefox Installer" [Undecided,Confirmed] https://launchpad.net/bugs/439964 [11:09] huh [11:24] dpm: http://aplg.kollide.net/images/osiris/snapshot047.png [11:24] i'll incorporate the fix in the upload [11:25] it's a one-liner anyway :D [11:25] apachelogger, awesome, thanks === MacSlow is now known as MacSlow|lunch [11:48] hum [11:48] is the "use the full disk to install" supposed to create a swap too? [11:48] I got a "swap mounting failed" dialog asking if I want to change the partitions or continue [11:50] seb128: it should create a swap partition [11:53] cjwatson, http://people.canonical.com/~seb128/install.png [11:53] cjwatson, any hint on how to get details about the issue? [11:55] wonderful [11:55] seb128: check the logs? [11:55] blink, that's weird [11:55] wolfe, what log? [11:55] seb128: /var/log/syslog, /var/log/partman [11:55] cjwatson, thanks [11:56] invalid argument error [11:56] or 'ubuntu-bug ubiquity' from inside the live environment, after exiting the installer [11:56] swapon: /dev/sda5: erreur de lecture de l'entête de zone d'échange (swap) [11:57] and the error is "invalid argument" [11:58] cjwatson, ok, will open a bug, thanks [11:58] "read swap header failed" [11:58] seb128: interesting.. [11:59] seb128: you are using a new hard drive? what brand? [11:59] (on something that's just been mkswapped) [11:59] also, is the swap at the very end of the hard drive? [12:00] I had an issue which was fairly common in certain hard drives where the space assigned didn't match the actual physical capacity. I'd receive such an error when it tried to read/write to the hard drive space which didn't exist. [12:00] or your hard drive could be going bad as well. :) [12:00] or it could be an installer bug [12:00] * cjwatson is happy to blame hardware but not as a first resort. :-) [12:01] cjwatson: if ithe hard drive is hitachi/ibm, I blame it first [12:02] or maxtor [12:02] I don't, because that's a recipe for missing installer bugs until it's too late. [12:08] cjwatson, wolfe: it's a kvm with a .img [12:08] ie not real hardware [12:08] It still uses real hardware, heh [12:09] makes me want to ask if you're using software raid [12:09] well I've no issue on my laptop out of that kvm install one [12:09] doesn't mean it's not a hardware issue though [12:09] I will retry before opening a bug [12:10] if you have the logs, I'd prefer you opened a bug now before losing the evidence [12:11] if it's not consistently reproducible, so be it, maybe we'll have to close it [12:15] cjwatson, bug #457099 [12:15] Launchpad bug 457099 in ubiquity "installation failed on swapon invalid argument error " [Undecided,New] https://launchpad.net/bugs/457099 [12:16] cjwatson, do you need any extra details before I try again? [12:22] seb128: a detailed description of how you got into this situation, from kvm disk initialisation, would be good :) [12:22] seb128: it looks to me as if, when you started up this instance of the installer, kvm was unable to recognise the previous swap partition as a swap partition; I wonder if that's related [12:22] err s/kvm/libparted/ [12:23] seb128: also can you reproduce the error with 'sudo swapon /dev/sda5' from the command line? [12:26] bug 436617 [12:26] Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/436617) === MacSlow|lunch is now known as MacSlow [12:28] cjwatson, ok, I added a comment to the bug, the kvm img I used had issues (ie wouldn't boot after a recent update) so maybe it's corrupted, I was expecting the use full disk to just reset it and make a clean install but maybe it's wrong expectation [12:28] I think that is a sound expectation [12:28] normally speaking anyway [12:28] cjwatson, the desktop seems frozen after some gstreamer codec install though so I can't try the swapon, I will reboot the image [12:30] hi, i just came across a bug, that has been reported 2 years ago, but it's still unassigned, what is going on? :S [12:31] https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/91389 [12:31] Launchpad bug 91389 in network-manager "Support for more than one VPN simultaneously" [Wishlist,Confirmed] [12:32] cjwatson, right, a swapon gives the same issue, the swap partition is screwed [12:34] rio: too many bugs and not enough developers [12:35] :( i might check out the source and see what i can do next week [12:47] example-content should really have an icon the the Examples desktop entry [12:47] the white paper icon on karmic looks weird [12:59] cjwatson, anything else required on this swap issue before I redo the partionning manually to workaround the issue? [13:01] seb128: no, I don't think so [13:01] cjwatson, ok thanks [13:03] swap issue? [13:05] Keybuk, corrupted swap partition breaking ubiquity install [13:06] ah [13:06] I though that a take over disk install would redo partitions too [13:06] but apparently it doesn't [13:06] and breaks on trying to swapon the corruption swap there [13:06] corrupted [13:07] it *does* redo the partitions actually, I can see that in the log [13:08] weird that the partition is still corrupted then [13:09] maybe not hard enough, or maybe there's a bad block under the .img file and nothing is noticing, or something; but it's definitely trying [13:09] apachelogger: so you found a solution? === porthose|afk is now known as porthose [13:26] cjwatson: thought [13:26] cjwatson: ssh shouldn't cache IP address hosts thingies for .local names [13:32] sladen: about? [13:36] Keybuk: hi [13:37] Keybuk: are you okay with the proposed solution in bug 428435? (comment 50) [13:37] Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/428435) [13:37] pitti: no, that will only lead to data corruption [13:38] and frankly, screwing around with partition detection this close to release is a BAD IDEA [13:38] I'm open for better suggestions [13:38] but given that vol_id behaved like that since hardy at least, it seems to be the safest option right now [13:38] I don't think we can squeeze in a proper migration solution at this point? [13:39] why bother with a migration solution? [13:40] this is one of those bugs that'll bite hard [13:40] because you'll stop detecting valid ext4 partitions as a result [13:40] hum [13:40] ubiquity hates kvm there today or something [13:41] I did rm the .img, created a new one using kvm-img and I still get install failure [13:42] Keybuk: no, we don't [13:43] Keybuk: migration> because you dist-upgrade your server and then it can't boot any more; not good [13:43] Keybuk: if there was a case where mkfs.ext4 over luks ever left enough traces of luks, this would have broken in hardy [13:44] we never migrated any other filesystem type this way [13:44] there are numerous "my filesystem was fat and is now ext4" type bugs since hardy [13:44] I just tell them to go away [13:44] correct [13:44] but so far we tolerated exactly that for luks-over-ext [13:45] and karmic is the very first release whose cryptsetup behaves correctly finally [13:45] (cf. the looong discussion we had in #u-release this morning with slangasek) [13:45] this is surely fixable with a quick perl script, no? [13:46] to zero the bits of the superblock that luks doesn't use [13:46] I 100% agree that cryptsetup was buggy, and that blkid should behave the way it does now [13:46] sounds a lot less hairy than rewiring blkid, with all the unexpected consequences you can cause [13:46] but we can't go from "four releases broken" to "we reject existing installs" without at least offering some help to affected users [13:47] sure, but wouldn't that help be better if it was help to fix their broken filesystem image [13:47] rather than just carrying on honouring it [13:47] sure [13:47] that's why we proposed to do exactly that for lucid [13:47] I don't want to keep that blkid behaviour forever [13:48] right, but why not do it for karmic? [13:48] -EINTRUSIVE? [13:48] it needs carefully engineered/tested initramfs scripts at least [13:48] which wouldn't even address broken USB sticks, etc. [13:48] err [13:48] you don't have to do that [13:48] you can just have it available and give it to anyone affected [13:48] and not just initramfs (for root), but also in mountall (for encrypted /home etc.) [13:49] this is a lot less intrusive than major rewiring of our filesystem detection library [13:51] Keybuk: you still need the logic to detect that at various places, like initramfs, init script, dk-disks/gnome/etc. [13:51] cjwatson, I did apport-collect on https://launchpad.net/bugs/457099 for installation breaking using a new kvm-img just created do you think it's the same issue? [13:51] cjwatson, ie local disk issue or something? [13:51] you're saying that a quick perl script for anyone effected by the bug is somehow worse than rewriting code which can have unforseen consequences [13:51] Keybuk: since right now it just silently breaks [13:51] Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/457099) [13:51] Keybuk: it's not unforeseen; it just restores the behaviour that we shippped for several releases [13:51] pitti: no you don't; we don't have that logic for any of the other problems [13:52] pitti: you're not understanding me [13:52] blkid is *complex* code [13:52] this is not a one line fix [13:52] in previous releases we had *different* code [13:52] it's not a matter of reverting a patch, or porting a patch [13:52] well, I wrote a thorough test script and am just looking into the code [13:52] you would have to make some fundamental changes to blkid [13:52] Keybuk: a "quick perl script" is a lot less helpful to the affected users, most of whom will discover the problem only after rebooting to karmic, and if they have any partitions that get decrypted post-initramfs, they won't even be able to boot the old kernel to recover [13:52] pitti: does your test script cover any cases that do not include luks or ext4? [13:53] slangasek: it's a lot better than (say) breaking everyone who uses lvm right before release [13:53] see bug; I tested luks/ext[234]/swap/vfat; I don't want to touch behaviour of everything except luks [13:53] changes to blkid tend to have that effect [13:53] pitti: that's my point [13:53] changes to blkid tend to affect everything [13:53] right, that's my intention :) [13:53] one minor change to one prober has unforseen knock-on effects on the other probers [13:53] bleh, why is blkid this brittle? [13:53] we'd fix initramfs/boot/dk-disks all at the same time [13:54] slangasek: because what it's doing is brittle [13:54] with the "if you see luks, stop detecting" change (pretty much what vol_id did) [13:54] slangasek: it is examining a block device for a unique signature [13:55] also, we have an internal test suite, now an external test script, and an image which reproduces this problem from a user [13:55] I don't care about fixing the problem, and testing that the fix is successful [13:55] I care about everything else you break in the process [13:56] well, that's pretty much what already happened; new blkid breaks systems which worked before [13:56] Keybuk: but it's the *existing* behavior that consists of "if it matches more than one prober, curl up in a ball and rock in the corner"; how can any possible change be more brittle than the current behavior? :P [13:56] and while admittedly they were broken to begin with, that makes little difference to upgraders who suddenly have a broken installation [13:57] slangasek: well, if you detect two you might pick the wrong one and destroy data [13:57]