=== ogasawara_ is now known as ogasawara [03:26] dtchen: have you actually reproduced the behavior described in that comment on a karmic system? The commenter says he's using Debian testing, and the *only* way I see that this shutdown script would be called twice is if the user has two symlinks to it by mistake [03:26] slangasek: I haven't been able to, but others have. [03:27] dtchen: what's their explanation for why it's being called twice on shutdown? [03:27] here, I see it being called once and failing because the logic is wrong [03:27] slangasek: yes, the logic in 5 is clearly broken. I haven't actually seen anyone explain why it's being called twice. [03:28] well, ubuntu4 *and* ubuntu5. [03:29] dtchen: so if nobody can explain why they're currently seeing it called twice, I think more analysis (and a more targeted fix) is called for [03:30] slangasek: okay [03:47] slangasek: https://bugs.launchpad.net/ubuntu/+source/ia32-libs/+bug/369498 [03:47] Launchpad bug 369498 in ia32-libs "32bits gtk and glib modules not found in ia32-libs" [Medium,In progress] [03:49] Regardless I'm starting to see other bugs due to what I'm pretty sure is just out of date ia32-libs [03:50] And there's probably security concerns for having month old libraries as well (since if any security issues were fixed in the past month they'd still be there in ia32-libs) [04:02] YokoZar: well, as I said the fltk1.1 FTBFS certainly should be fixed for release, but I don't think anyone's going to break their neck to make sure the fix lands with enough time to fix a 6-month-old ia32-libs bug afterwards [04:03] slangasek: that bug's just a bonus, the main benefit is to freshen the packages [04:03] the bug was meant as an example of the symlinks you were asking about [04:05] YokoZar: the symlinks mentioned in https://bugs.launchpad.net/ubuntu/+source/ia32-libs/+bug/369498/comments/63 ? [04:05] Launchpad bug 369498 in ia32-libs "32bits gtk and glib modules not found in ia32-libs" [Medium,In progress] [04:06] slangasek: asac: was patching the library to make it handle them as well (I believe the patch went in a month ago), but that hasn't been able to roll into ia32-libs [05:36] Is there still a chance to get a sync ack'd for tegaki* packages? Those are not widely used I think and upstream has apparently made the second alpha release in August. 0.1 does not work well and I think it would be good if 0.2 got more exposure. [05:50] How does one prepare a debdiff for one of the meta packages? xubuntu-meta in this case? [05:50] doesn't seem to follow the standard procedure [05:53] It wouldn't, it's a based on a seed [06:08] what to do then? [06:17] Laibsch: You propose a diff to the seeds, which can be checked out of bzr. I'd then suggest talking to cody-somerville [06:18] OK [06:19] * Laibsch is not a big fan of bzr [07:17] TheMuso, did you see https://bugs.edge.launchpad.net/ubuntu/+source/pulseaudio/+bug/452458 ? [07:17] Launchpad bug 452458 in pulseaudio "Add rtkit Conflicts to force removal of rtkit for release testing" [Undecided,Fix released] [07:17] oops [07:17] http://0pointer.de/blog/projects/pa-in-ubuntu.html === highvolt1ge is now known as highvoltage [08:05] slangasek: ok, should I add iso-codes as a depends and do another upload? I inserted isoquery because it was giving me errors during the build when i didn't have isoquery installed [08:05] mdke: you should add it in bzr, no need for another upload right now [08:06] not being able to cancel the forced fsck in karmic is a bug in what package? apparently it used to work at least in hardy [08:07] tjaalton: mountall [08:07] (if it's a bug at all) [08:07] slangasek: bzr is broken at the moment, the branch is corrupted, but I'll certainly do it once I get that sorted out... [08:07] slangasek: thanks [08:07] mdke: hrm, ok [08:07] mdke: corrupted? [08:08] lifeless: I filed it as bug 454937 [08:08] Launchpad bug 454937 in bzr "bzr: ERROR: bzrlib.errors.ShortReadvError: readv() read 0 bytes rather than 56795 bytes at 8853769 for "7eb3aa09b5969991699f71e8d264a6e5.pack"" [Undecided,New] https://launchpad.net/bugs/454937 [08:08] mdke: did you have a power failure? [08:09] or crash [08:09] lifeless: nope, it's the branch on LP that seems to be broken, no idea what happened [08:09] mdke: then its not a bzr bug; you should move it to launchpad-code [08:10] mdke: as in, it *might* be a bug, but the folk you need looking at it are the LOSA's. [08:10] which are best attracted by a question on answers.launchpad.net/launchpad [08:11] lifeless: ok. I raised it on #bzr and it was suggested that I file a bug but I can also file a question on Launchpad [08:11] we like bugs indeed. and we'll want to track the cause [08:12] ok [08:12] I was getting the same error when trying to diff or commit to my local repository [08:14] lifeless: question now filed [08:26] YokoZar: all good to go? [08:27] asac: not with fltk1.1 still FTBFS... [08:27] YokoZar: is that somehow related to ia32 ;)? [08:27] sorry if i lack a bit context ... just started my day :) [08:28] asac: it is, as ia32-libs script requires a syncing of all its component packages, and it freaks out if source and binary don't match [08:29] asac: since the package FTBFS then the source archive is newer than the binary available [08:30] YokoZar: ah ok. [08:30] YokoZar: whats the status on FTBFS? [08:30] asac: https://bugs.launchpad.net/ubuntu/+source/fltk1.1/+bug/445560 [08:30] Launchpad bug 445560 in fltk1.1 "FTBFS: conversion errors" [High,Confirmed] [08:33] YokoZar: how many do rdepend on that` [08:33] ? [08:34] asac: apt-cache rdepends libfltk1.1 shows 40 packages [08:35] how did libfltk1.1 end up in ia32-libs, in the first place? [08:36] ah, because someone wanted it for pose [08:36] YokoZar: you could just drop fltk from ia32-libs for this upload [08:38] slangasek: that's not a bad suggestion [08:39] YokoZar: isnt that "match source + package" version check a safety belt that we could ignore if carefully checking that no other mismatches exist? [08:40] though in this case - with a potentially pending ABI bump - its probably better to keep it out of ia32 :) [08:40] asac: it's there to ensure we aren't shipping binaries that aren't built from the available source... which indeed is what would happen as soon as fltk1.1's FTBFS was fixed [08:40] slangasek, hey [08:41] * slangasek waves to seb128 [08:41] slangasek, if I sync new gtk from debian that would bypass the queue right? [08:41] seb128: yes [08:41] slangasek, want to you need to grant the sync, a debdiff online would do? [08:41] seb128: that would work [08:42] ok, will do that then, thanks [08:52] pitti, seb128: amd64 has gone oversized again, I believe because of the latest langpack export; next langpack on the chopping block would be French - any ideas how we could free up 2MB somewhere else quickly instead? [08:56] slangasek, not right now no but I can try having a look today [09:00] Good morning [09:00] hey pitti [09:01] ScottK: if the input layer is okay (which seems to be the case), then you'd need to run powerdevil (or what does that in KDE now?) in debug mode and watch what it's doing [09:01] * slangasek waves [09:02] slangasek: hm, put on my list, but no offhand idea right now [09:02] pitti: heh, of course PowerDevil runs in-process in kded4, that must be fun to debug [09:02] pitti: ok, thanks [09:02] it's all a french hater conspiracy [09:03] in the meantime, I'll bump French so we can get started with candidate ISOs [09:03] s/candidate/smoketest/ [09:03] slangasek, bump or dump? [09:03] seb128: bump off :( [09:03] hum, k [09:04] just from amd64? [09:04] ie it's still on i386? [09:04] yes [09:04] that's already something [09:05] pitti: power devil is right [09:06] seb128: c'est pas moi qui déteste le français, c'est GNOME qui ne veut pas partager les CD ;) [09:07] on devrait faire du français le language officiel de GNOME! [09:07] d'accord [09:07] seb128: i'm allowed to hate the French after 3 years in Quebec. ;) [09:08] mneptok, no you're not! [09:08] seb128: notre langue n'est pas le propre. c'est le "nouvelle" et "au courant." [09:08] slangasek, http://people.canonical.com/~seb128/gtk.debdiff-simplified.gz http://people.canonical.com/~seb128/gtk.debdiff.gz [09:08] slangasek, the simplified one is a debdiff with po and html filtered out [09:09] L'Academie ... pffft! [09:09] slangasek, should be easier to review [09:09] mneptok, tu fais des fautes de français! [09:09] haha [09:10] seb128: did you understand me? [09:10] mneptok, no [09:11] must be the accent [09:11] seb128: then these issues have not driven you *fully* crazy yet. carry on. [09:11] ;-) [09:11] mneptok: does that mean that you can start hating New Mexicans in 2012? [09:11] jamesh: no, it means i can start hating European Spanish-speakers at that time :) [09:12] qué va [09:12] seb128, slangasek: hah! I just found 3.2 MB to free \o/ [09:12] jamesh: tell Etienne he speaks a funny and outdated version of French. you'll get the whole "those people in Europe know NOTHING!" rant :) [09:13] so the Catalans will be safe then. [09:13] pitti, german langpacks? ;-) [09:13] seb128, slangasek: bug 385850 [09:13] Launchpad bug 385850 in hundredpapercuts "Ship fewer screensavers by default" [Low,Fix released] https://launchpad.net/bugs/385850 [09:13] oh [09:13] slangasek: mind if I do a new ubuntu-meta upload to drop rss-glx? [09:13] I though that had been fixed ages ago [09:13] pitti: GO GO GO [09:13] seb128: yes, the g-screensaver dependency, but not the u-meta one [09:13] k [09:14] viva la revolution! [09:14] *cough* [09:14] viva is spanish [09:14] vive is french [09:14] excusez-moi [09:14] (I'm sure that's wrong as well) [09:14] il n'y a pas de soucis ;-) [09:14] (not that's correct) [09:14] not->no, [09:15] ni de souris === geser_ is now known as geser [09:17] es tiempo para mi siesta. [09:18] ai caralho. mi manos ... [09:18] * mneptok tootles off to bed [09:18] 'night mneptok [09:18] seb128: a bientot. [09:19] (i guess i should say "a tootle a l'heure") [09:19] I put back french into the seeds [09:19] * seb128 hugs mneptok [09:19] ups [09:19] * seb128 hugs pitti [09:19] * seb128 hands mneptok a french dictionnary [09:19] dpkg ERROR: Your cowboy culture is an insult to humanity. [09:20] pitti: langpack works. [09:20] seb128: ack on gtk [09:20] slangasek, thanks [09:20] *chuckles* [09:21] YokoZar: do you know how to move forward? [09:21] seb128, slangasek: did you already happen to talk about gvfs/rhythmbox? [09:21] asac: basically I'm gonna remove fltk1.1 from ia32-libs [09:21] pitti, no, I've other things on my plates if you don't want the change that's ok [09:21] YokoZar: ok. and the ftbfs in karmic will be fixed by someone :)? [09:21] robert_ancell though it would be nice to get since some of the main podcast distributors will have the issue [09:21] YokoZar: otherwise i think getting most rdepends and checking with nm -D if something directly uses that symbol would help [09:21] I'm a bit torn, Robert says that it breaks a lot of popular podcasts [09:21] mneptok: que duermes bien y que los cisnes de pesadilla no te coman [09:22] asac: you'll have to beg slangasek about that (I believe the answer is "not unless someone checks all the rdepends for symbol breakage") [09:22] i am not here for begging ... just see that having apackage ftbfs that will add a symbol if that ftbfs is fixed isnt good ;) [09:22] YokoZar: no, I want someone to tell me that the symbols *can't* be used [09:23] checking all the rdepends is a poor second :/ [09:23] slangasek: I guess that means poking upstream fltk then [09:23] no [09:23] it means knowing the C++ ABI better than I do [09:23] ok. i am probably out of that set then ;) [09:24] pitti, concerning the gvfs change not added to git 2.28 I'm not sure how they deal with api addition to gvfs in stable [09:24] asac: heh, you do a lot more C++ stuff than me [09:24] pitti, usually stable series are feature frozen for GNOME [09:24] pitti, I will check with gicmo when he's online [09:26] seb128: I don't mind the API addition, but it changes existing code in daemon/gvfsbackendhttp.c [09:26] hm, actually it just moves it around a bit [09:27] pitti, I doubt many things use gvfs http anyway [09:27] looking at bugs we get since we have gvfs the code is not working well for webdav [09:27] so it's basically used for podcast and http steaming [09:27] streaming [09:27] I don't think it can break a lot [09:27] out of podcast which is already not working... [09:28] slangasek: so, the gvfs change is mostly just diff producing noise; I think that by itself is safe (will take a look at rb again) [09:28] slangasek: it just adds a new function [09:28] pitti: if it looks safe to you then, go ahead [09:39] slangasek: could bug 455114 be the root cause for bug 454362 ? [09:39] Launchpad bug 455114 in qemu-kvm "builds uninstallable package 'kvm'" [High,Triaged] https://launchpad.net/bugs/455114 [09:39] Launchpad bug 454362 in eucalyptus "UEC node install from CD fails on installation of qemu-kvm" [Undecided,New] https://launchpad.net/bugs/454362 [09:40] ttx: yes [09:40] slangasek: ok, will mark it as such [09:42] oops, sorry [10:09] ttx: would you have time to fix qemu-kvm this morning? [10:10] slangasek: I can try to find some. Let mle see if I understand the issue correctly [10:17] james_w: any reason why the changes for qemu-kvm 0.11.0-0ubuntu5 are not appearing in lp:ubuntu/karmic/qemu-kvm ? [10:17] let me look [10:18] ttx: the fix should be pretty simple, just dropping the conflicts from qemu-kvm [10:20] mvo: yes, I just saw the problematic diff. I'm on it. [10:20] great, many thanks [10:21] mvo: do you see any point in keeping the Provides and Replaces ? [10:23] ttx, mvo: I think you still need a versioned conflicts against the old version of kvm [10:24] there are numerous file overlaps between kvm 1:84+dfsg-0ubuntu11 and qemu-kvm 0.11.0-0ubuntu5 [10:24] so probably Conflicts: kvm (<< 1:84+dfsg-0ubuntu16+0.11.0) [10:26] slangasek: ok, so a versioned Conflicts/Replaces... not sure the "Provides: kvm" makes any sense with transitional packages ? [10:27] ttx: I have no opinion on the Provides:, other than to note that changing it is not required in order to fix this bug [10:27] ok. [10:44] slangasek, mvo: I'm building a package to validate the following change: http://pastebin.ubuntu.com/296713/ [10:46] ttx: are you sure the qemu conflict should be made conditional like that? [10:47] * slangasek checks [10:47] ttx: yah, that's fine, there are no file conflicts between the current versions of the two packages; which probably means the versioned conflicts is a bit tighter than it needs to be, but not buggily so [10:48] slangasek: ok [10:48] I'll doublecheck with my package build in various scenarios. [10:49] (whenever it finishes to build) === MacSlow is now known as MacSlow|lunch [11:20] slangasek, mvo: installs correctly but fails on upgrade scenario: http://pastebin.ubuntu.com/296732/ [11:27] pitti: Thanks === agateau is now known as agateau|lunch [11:39] ttx: strange, checking why that conflict didn't show up in my check of the Contents [11:40] ttx: has something changed that would cause /etc/qemu-ifup to be present in the qemu package? Contents-i386.gz insists that this file is only found in qemu-kvm [11:42] mvo: In bug 439485, the Moblin CD doesn't have a Packages or Sources file, as it doesn't use extra packages. This causes apt to say it's not a valid CD, and in turn pops up a warning in apt-setup/ubiquity. [11:42] mvo: The CD does however include a Release.gpg file. So do you think apt not considering this sufficient a bug in apt, or should it continue to treat a CD without packages invalid? I have a patch if you think it's the former. [11:42] Launchpad bug 439485 in ubiquity "APT error during installer" [High,Triaged] https://launchpad.net/bugs/439485 [11:42] ttx: the archive confirms - how do you have /etc/qemu-ifup in a current qemu package? [11:55] pitti: Bug 450491 I just had it crash on me again is there any info you'd like me to add to the bug before I reboot the system? [11:55] Bug 450491 on http://launchpad.net/bugs/450491 is private [11:57] davmor2: can you please just submit it again? perhaps your retrace will get better [11:59] oh gar, why am I now getting a 'low disk space' pop-up every 30 seconds? :P [11:59] I don't remember it doing that before [12:00] hm, that should be a notification [12:00] oh, perhaps it has an action [12:00] it does [12:01] my objection is that it's giving me the same notification repeatedly, instead of just giving it to me once at login [12:01] s/notification/pop-up/ [12:01] *nod* that sounds like a bug [12:01] and when I click 'ignore', it only ignores it for 30 seconds :P [12:01] nothing which changed recently though [12:01] I suppose it's because my /home partition recently fell below whatever its threshold is [12:02] I guess so [12:02] so every time it polls, it sees the partition has changed, so feels the need to ask me again [12:02] just in case the different freespace number changes my mind :P [12:03] you can try to ping chrisccoulson when he's around [12:03] * slangasek nods [12:03] I think he had been looking at those issues [12:03] although, I'd rather he fix my crashing gnome-settings-daemon first :) [12:04] pitti: bug 455356 [12:04] Bug 455356 on http://launchpad.net/bugs/455356 is private [12:04] that's the new one [12:04] davmor2: thanks; needs retracing first [12:05] no probs [12:08] evand: hm, can I see the patch that you have in mind please? I will now download the CD to see what it looks like, in general I think if the cd is not valid about should complain, but I need to see the moblin cd first to judge [12:08] mvo: http://pastebin.ubuntu.com/296733/ - sure thing [12:20] slangasek: hm, that strange. That test was an update from a jaunty setup with kvm and qemu installed. [12:20] slangasek - i hear you're getting repeated low-disk space notifications [12:20] slangasek: I think the Provides plays tricks here [12:21] ttx: I don't think it's the Provides, no [12:21] ttx: jaunty qemu had that file; I think it's a dpkg bug in the handling of the Replaces [12:22] chrisccoulson: word travels fast ;) [12:22] heh, it does indeed. you only get the notifications for internal volumes right? [12:22] chrisccoulson: AFAIK yes === MacSlow|lunch is now known as MacSlow [12:23] that's ok then. how much space is on the volume at the moment? [12:24] the expected behaviour is that you will get the first notification when the free space drops to 5%, and you shouldn't get anymore notifications unless the free space drops a further 1%. in this case, they should not appear more frequently than every 10 minutes anyway [12:24] and you should never get a notification for a volume that has more than 2GB free space either [12:25] chrisccoulson: 96% used; I've seen at least 4 of the notifications since my most recent login [12:25] does the volume stay mounted the whole time, or do you ever unmount it at all? [12:28] slangasek: yes, it keeps /etc/qemu-ifup in the dummy qemu filelist on upgrade [12:28] chrisccoulson: it's /home ;P [12:29] ttx: right - so I think we just need an unversioned Replaces: qemu [12:29] slangasek: you read my mind [12:29] * ttx is happy to have tested in various scenarios, now :) [12:30] slangasek - i might need to give you a build of g-s-d later with some g_debug's in it so i can figure out what's going on [12:48] jono: Yes, I have seen it. It was a result of myself and dtchen telling Lennart about where thigns stand re pulseaudio in karmic. [12:49] TheMuso, what can we do to help repair relations with Lennart? [12:50] jono: I am not sure at this point, I need to sleep on it. I am still mentally scrambled after sed conversation, and need to sleep on it, and approach the solution with a clear mind. [12:50] TheMuso, sounds like a good idea [12:50] let me know if I can help [12:50] jono: Ok thanks. === agateau|lunch is now known as agateau [12:51] np :) [12:56] pitti: about? [12:57] hey Keybuk [12:57] pitti: so, this INPUTCHAR usplash thing [12:57] * Keybuk *cannot* get it to work [12:59] Keybuk: you mean it doesn't work any more now? [12:59] Keybuk: I didn't use it recently; maybe it got broken during all those console handling changes [13:00] want me to write a test script? [13:00] script isn't helpful ;) [13:00] in C, I keep getting the open() call blocked [13:01] ok, I'll first test it with a script to check if the usplash backend stuff is still working, and then try in C [13:08] pitti: am I right in thinking that you have to continually send INPUTCHAR to usplash? [13:08] and that after sending you have to open the outfifo, read (which will block for up to a second) ? [13:09] Keybuk: the current implementation behaves that way, yes; I didn't want INPUTCHAR to block [13:09] otherwise it'd be utterly hard to write shell scripts that use it [13:10] ok, so at least my understanding is right [13:10] Keybuk: (see man usplash_write) [13:11] right, and the code [13:11] it just doesn't tend to work :) [13:13] ioctl(TIOCSCTTY): Operation not permitted [13:13] oha [13:13] yeah I see that one from time to time too [13:13] Keybuk: confirmed, it blocks here and doesn't work [13:13] Keybuk: http://people.canonical.com/~pitti/tmp/test-input.sh [13:13] I don't think that code path has changed though? [13:14] no, not since jaunty [13:14] but terminal handling did [13:15] which console did it output that ioctl error to? [13:15] Keybuk: gnome-terminal (from where I started the sript) [13:15] weird, it implies either [13:15] ah [13:15] no [13:15] you need --background on that usplash call if you do that [13:16] otherwise it's not a session leader? [13:16] * cjwatson wishes packages would either use the autotools, or not use the autotools, not somewhere in between [13:16] so try usplash -c -v --background [13:16] attr, I'm looking at you [13:16] Keybuk: --background? Should't -c do that? [13:16] pitti: no -c is VT flip [13:16] Keybuk: ah, seems --background isn't in the manpage [13:17] pitti: -> cjwatson ;) [13:17] oops [13:17] instead of & then, I guess [13:17] --background is to make it less racy [13:18] so the terminal setup and fifo opening is synchronous, and *then* it backgrounds [13:18] doesn't help to fix INPUT, though [13:18] weird, your script works for me ;) [13:18] cjwatson: though there's another race now which I have a fix for [13:19] cjwatson: (mask SIGTERM out until after the init is finished :p) [13:20] Keybuk: I updated the script to test "INPUT" as well (with a full line); hangs as well, though [13:20] that's odd [13:21] Keybuk,pitti: http://paste.ubuntu.com/296791/ was aimed at something else but may help here [13:21] does it hang or does it timeout? [13:21] esp. the tcsetattr crud [13:22] cjwatson: the termios stuff is probably useful [13:22] but the other bit is actually badly wrong [13:22] it'd mean if you pressed escape at exactly the wrong ms, usplash would disappear but not fsck [13:23] in fact, most input characters would get eaten by that code, rather than the INPUT checking code [13:23] hm, ok [13:23] well, I hadn't committed it yet because I hadn't got it all working :) [13:23] although I'm not entirely sure I agree with your analysis [13:23] INPUT sends usplash into a totally different loop [13:24] I think you may be incorrectly assuming a sane main loop design? :) [13:24] I'm thinking of INPUTCHAR here [13:24] Keybuk: times out [13:24] which is what we use to grab Escape [13:24] pitti: that implies not locking then, just not seeing input [13:24] cjwatson: INPUTCHAR is "check for escape", return to main loop [13:25] so you then end up with two bits of code reading from stdin [13:25] depending which one gets it, you get different behaviour [13:25] this is true [13:26] anyway, I meant you to try out the termios hackery and see if that helps [13:26] that being said, it might be cute to replace INPUTCHAR with something else [13:26] * pitti tries termios bits [13:26] ESCAPE %d [13:26] (when escape is pressed, send SIGHUP to %d) [13:26] you could patch that into your code then :p [13:27] evand: I followed up on #439485, I wonder if we can just make ubiquity ignore the error from cdrom.Add() ? [13:27] pitti, fyi, pulsating usplash works fine on my armel images [13:27] evand: maybe conditional on moblin [13:27] ogra: thanks [13:27] cjwatson: I don't think the termios fixes my problem though - because mine is that open() locks [13:29] doesn't work, no [13:29] still no input [13:30] pitti: are you using the bogl or svgalib backends? [13:30] Keybuk: bogl (with KMS) [13:31] * Keybuk wonders whether that makes a difference [13:34] Keybuk: I try it in kvm now (which uses svgalib) [13:39] err [13:39] W.T.F [13:39] warcraft scott% md5sum karmic-moblin-remix-i386.iso [13:39] 91e4f415767a45617f0cbfc5b0abd19c karmic-moblin-remix-i386.iso [13:39] warcraft scott% md5sum karmic-moblin-remix-i386.iso [13:39] 26c3177ae594a3713b0e318e12e91e1b karmic-moblin-remix-i386.iso [13:39] the md5sum changed over time [13:39] ext4? [13:39] yes [13:41] ext4 is scaring me [13:42] Keybuk: could you have a look at bug #453579, and see whether the mount-fiddling bits suggested there have any effect on your ext4 problems? [13:42] Launchpad bug 453579 in linux "corruption of large files reported with linux 2.6.31-14.46 on ext4" [Critical,Triaged] https://launchpad.net/bugs/453579 [13:44] slangasek: which mount-fiddling bits? [13:44] Keybuk: auto_da_alloc=0 [13:45] Keybuk: is this ext4 on top of LVM or dm-crypt? [13:45] no [13:45] ext4 on top of hardware [13:45] ogra: so how come you have pulsations and we poor x86 users don't? [13:45] Keybuk: ok [13:45] Keybuk: I tried the scheduer=deadline and it made no difference [13:45] Keybuk: test-input.sh doesn't work for me in KVM either, hmm [13:46] Keybuk: sorry, I guess auto_da_alloc=0 is a boot-time module option rather than a mount option [13:46] sladen: pulsation> should be fixed since last Friday or so? [13:46] sladen, heh, no idea, get arm HW then :) [13:46] slangasek: isn't that the one about rename() and stuff? [13:46] I'm seeing md5sums being wrong on single files [13:46] and worse, md5sums *changing* on single files [13:46] assumedly the change was when that file left the page cache [13:46] Keybuk: I don't know, I'm just trying to figure out if this links to any of the existing open upstream bug reports [13:48] pitti: I see no pulsatations on boot. If I should be seeing them, what is poking usplash to PULSATE? [13:48] sladen: only on live system boot, not on installed one [13:48] sladen: casper does [13:51] pitti: is the /lack/ of that POKE/PULSATE also the reason that usplash vanishes back to text-mode after 20 seconds [13:51] no [13:51] slangasek: that's just the normal timeout [13:51] (30 secs) [13:52] or something is stopping usplash prematurely, of course [13:52] which seems to happen for cryptsetup [13:52] I regularly see the "Starting crypto disks" init message in a VT [13:52] slangasek: I'm still not honestly 100% sure this isn't a hardware issue, since I seem to be able to replicate it more than most [13:53] usplash is running for 20 seconds (by the stopwatch) and 23 seconds by the bootchart [13:53] slangasek: the only thing that makes me think it isn't (and which is why I've mentioned it) is that mvo has reported users with the exact same problems [13:53] (large debs being corrupted) [13:54] I would assume that if there's definitely a filesystem bug here, people on true ext4 will see it quickly now they'll be downloading isos [13:54] Keybuk: I think it would be helpful if you would apport-collect your kernel information onto that bug from the affected system, so we at least have a point of reference for collating any other reports that come in [13:55] can anyone recommend me a package which updates the initramfs (maybe after adding a module) in a sane way in its packaging scripts, please? [13:55] will do [13:55] * tseliot is looking for an example [13:55] tseliot: that's done by triggers [13:55]