[03:26] <slangasek> 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] <dtchen> slangasek: I haven't been able to, but others have.
[03:27] <slangasek> dtchen: what's their explanation for why it's being called twice on shutdown?
[03:27] <slangasek> here, I see it being called once and failing because the logic is wrong
[03:27] <dtchen> slangasek: yes, the logic in 5 is clearly broken. I haven't actually seen anyone explain why it's being called twice.
[03:28] <dtchen> well, ubuntu4 *and* ubuntu5.
[03:29] <slangasek> 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] <dtchen> slangasek: okay
[03:47] <YokoZar> slangasek: https://bugs.launchpad.net/ubuntu/+source/ia32-libs/+bug/369498
[03:49] <YokoZar> Regardless I'm starting to see other bugs due to what I'm pretty sure is just out of date ia32-libs
[03:50] <YokoZar> 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] <slangasek> 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] <YokoZar> slangasek: that bug's just a bonus, the main benefit is to freshen the packages
[04:03] <YokoZar> the bug was meant as an example of the symlinks you were asking about
[04:05] <slangasek> YokoZar: the symlinks mentioned in https://bugs.launchpad.net/ubuntu/+source/ia32-libs/+bug/369498/comments/63 ?
[04:06] <YokoZar> 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] <Laibsch> 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] <Laibsch> How does one prepare a debdiff for one of the meta packages?  xubuntu-meta in this case?
[05:50] <Laibsch> doesn't seem to follow the standard procedure
[05:53] <StevenK> It wouldn't, it's a based on a seed
[06:08] <Laibsch> what to do then?
[06:17] <StevenK> 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] <Laibsch> OK
[06:19]  * Laibsch is not a big fan of bzr
[07:17] <jono> TheMuso, did you see https://bugs.edge.launchpad.net/ubuntu/+source/pulseaudio/+bug/452458 ?
[07:17] <jono> oops
[07:17] <jono> http://0pointer.de/blog/projects/pa-in-ubuntu.html
[08:05] <mdke> 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] <slangasek> mdke: you should add it in bzr, no need for another upload right now
[08:06] <tjaalton> 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] <slangasek> tjaalton: mountall
[08:07] <slangasek> (if it's a bug at all)
[08:07] <mdke> 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] <tjaalton> slangasek: thanks
[08:07] <slangasek> mdke: hrm, ok
[08:07] <lifeless> mdke: corrupted?
[08:08] <mdke> lifeless: I filed it as bug 454937
[08:08] <lifeless> mdke: did you have a power failure?
[08:09] <lifeless> or crash
[08:09] <mdke> lifeless: nope, it's the branch on LP that seems to be broken, no idea what happened
[08:09] <lifeless> mdke: then its not a bzr bug; you should move it to launchpad-code
[08:10] <lifeless> mdke: as in, it *might* be a bug, but the folk you need looking at it are the LOSA's.
[08:10] <lifeless> which are best attracted by a question on answers.launchpad.net/launchpad
[08:11] <mdke> 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] <lifeless> we like bugs indeed. and we'll want to track the cause
[08:12] <mdke> ok
[08:12] <mdke> I was getting the same error when trying to diff or commit to my local repository
[08:14] <mdke> lifeless: question now filed
[08:26] <asac> YokoZar: all good to go?
[08:27] <YokoZar> asac: not with fltk1.1 still FTBFS...
[08:27] <asac> YokoZar: is that somehow related to ia32 ;)?
[08:27] <asac> sorry if i lack a bit context ... just started my day :)
[08:28] <YokoZar> 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] <YokoZar> asac: since the package FTBFS then the source archive is newer than the binary available
[08:30] <asac> YokoZar: ah ok.
[08:30] <asac> YokoZar: whats the status on FTBFS?
[08:30] <YokoZar> asac: https://bugs.launchpad.net/ubuntu/+source/fltk1.1/+bug/445560
[08:33] <asac> YokoZar: how many do rdepend on that`
[08:33] <asac> ?
[08:34] <YokoZar> asac: apt-cache rdepends libfltk1.1 shows 40 packages
[08:35] <slangasek> how did libfltk1.1 end up in ia32-libs, in the first place?
[08:36] <slangasek> ah, because someone wanted it for pose
[08:36] <slangasek> YokoZar: you could just drop fltk from ia32-libs for this upload
[08:38] <YokoZar> slangasek: that's not a bad suggestion
[08:39] <asac> 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] <asac> though in this case - with a potentially pending ABI bump - its probably better to keep it out of ia32 :)
[08:40] <slangasek> 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] <seb128> slangasek, hey
[08:41]  * slangasek waves to seb128 
[08:41] <seb128> slangasek, if I sync new gtk from debian that would bypass the queue right?
[08:41] <slangasek> seb128: yes
[08:41] <seb128> slangasek, want to you need to grant the sync, a debdiff online would do?
[08:41] <slangasek> seb128: that would work
[08:42] <seb128> ok, will do that then, thanks
[08:52] <slangasek> 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] <seb128> slangasek, not right now no but I can try having a look today
[09:00] <pitti> Good morning
[09:00] <seb128> hey pitti
[09:01] <pitti> 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] <pitti> slangasek: hm, put on my list, but no offhand idea right now
[09:02] <slangasek> pitti: heh, of course PowerDevil runs in-process in kded4, that must be fun to debug
[09:02] <slangasek> pitti: ok, thanks
[09:02] <seb128> it's all a french hater conspiracy
[09:03] <slangasek> in the meantime, I'll bump French so we can get started with candidate ISOs
[09:03] <slangasek> s/candidate/smoketest/
[09:03] <seb128> slangasek, bump or dump?
[09:03] <slangasek> seb128: bump off :(
[09:03] <seb128> hum, k
[09:04] <seb128> just from amd64?
[09:04] <seb128> ie it's still on i386?
[09:04] <slangasek> yes
[09:04] <seb128> that's already something
[09:05] <maco> pitti: power devil is right
[09:06] <slangasek> seb128: c'est pas moi qui déteste le français, c'est GNOME qui ne veut pas partager les CD ;)
[09:07] <seb128> on devrait faire du français le language officiel de GNOME!
[09:07] <slangasek> d'accord
[09:07] <mneptok> seb128: i'm allowed to hate the French after 3 years in Quebec. ;)
[09:08] <seb128> mneptok, no you're not!
[09:08] <mneptok> seb128: notre langue n'est pas le propre. c'est le "nouvelle" et "au courant."
[09:08] <seb128> slangasek, http://people.canonical.com/~seb128/gtk.debdiff-simplified.gz http://people.canonical.com/~seb128/gtk.debdiff.gz
[09:08] <seb128> slangasek, the simplified one is a debdiff with po and html filtered out
[09:09] <mneptok> L'Academie ... pffft!
[09:09] <seb128> slangasek, should be easier to review
[09:09] <seb128> mneptok, tu fais des fautes de français!
[09:09] <slangasek> haha
[09:10] <mneptok> seb128: did you understand me?
[09:10] <seb128> mneptok, no
[09:11] <seb128> must be the accent
[09:11] <mneptok> seb128: then these issues have not driven you *fully* crazy yet. carry on.
[09:11] <seb128> ;-)
[09:11] <jamesh> mneptok: does that mean that you can start hating New Mexicans in 2012?
[09:11] <mneptok> jamesh: no, it means i can start hating European Spanish-speakers at that time :)
[09:12] <slangasek> qué va
[09:12] <pitti> seb128, slangasek: hah! I just found 3.2 MB to free \o/
[09:12] <mneptok> 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] <jamesh> so the Catalans will be safe then.
[09:13] <seb128> pitti, german langpacks? ;-)
[09:13] <pitti> seb128, slangasek: bug 385850
[09:13] <seb128> oh
[09:13] <pitti> slangasek: mind if I do a new ubuntu-meta upload to drop rss-glx?
[09:13] <seb128> I though that had been fixed ages ago
[09:13] <slangasek> pitti: GO GO GO
[09:13] <pitti> seb128: yes, the g-screensaver dependency, but not the u-meta one
[09:13] <seb128> k
[09:14] <pitti> viva la revolution!
[09:14] <pitti> *cough*
[09:14] <seb128> viva is spanish
[09:14] <seb128> vive is french
[09:14] <pitti> excusez-moi
[09:14] <pitti> (I'm sure that's wrong as well)
[09:14] <seb128> il n'y a pas de soucis ;-)
[09:14] <seb128> (not that's correct)
[09:14] <seb128> not->no,
[09:15] <slangasek> ni de souris
[09:17] <mneptok> es tiempo para mi siesta.
[09:18] <mneptok> ai caralho. mi manos ...
[09:18]  * mneptok tootles off to bed
[09:18] <seb128> 'night mneptok
[09:18] <mneptok> seb128: a bientot.
[09:19] <mneptok> (i guess i should say "a tootle a l'heure")
[09:19] <pitti> I put back french into the seeds
[09:19]  * seb128 hugs mneptok
[09:19] <seb128> ups
[09:19]  * seb128 hugs pitti
[09:19]  * seb128 hands mneptok a french dictionnary
[09:19] <mneptok> dpkg ERROR: Your cowboy culture is an insult to humanity.
[09:20] <mneptok> pitti: langpack works.
[09:20] <slangasek> seb128: ack on gtk
[09:20] <seb128> slangasek, thanks
[09:20] <pitti> *chuckles*
[09:21] <asac> YokoZar: do you know how to move forward?
[09:21] <pitti> seb128, slangasek: did you already happen to talk about gvfs/rhythmbox?
[09:21] <YokoZar> asac: basically I'm gonna remove fltk1.1 from ia32-libs
[09:21] <seb128> pitti, no, I've other things on my plates if you don't want the change that's ok
[09:21] <asac> YokoZar: ok. and the ftbfs in karmic will be fixed by someone :)?
[09:21] <seb128> robert_ancell though it would be nice to get since some of the main podcast distributors will have the issue
[09:21] <asac> YokoZar: otherwise i think getting most rdepends and checking with nm -D if something directly uses that symbol would help
[09:21] <pitti> I'm a bit torn, Robert says that it breaks a lot of popular podcasts
[09:21] <slangasek> mneptok: que duermes bien y que los cisnes de pesadilla no te coman
[09:22] <YokoZar> 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] <asac> 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] <slangasek> YokoZar: no, I want someone to tell me that the symbols *can't* be used
[09:23] <slangasek> checking all the rdepends is a poor second :/
[09:23] <YokoZar> slangasek: I guess that means poking upstream fltk then
[09:23] <slangasek> no
[09:23] <slangasek> it means knowing the C++ ABI better than I do
[09:23] <asac> ok. i am probably out of that set then ;)
[09:24] <seb128> 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] <slangasek> asac: heh, you do a lot more C++ stuff than me
[09:24] <seb128> pitti, usually stable series are feature frozen for GNOME
[09:24] <seb128> pitti, I will check with gicmo when he's online
[09:26] <pitti> seb128: I don't mind the API addition, but it changes existing code in daemon/gvfsbackendhttp.c
[09:26] <pitti> hm, actually it just moves it around a bit
[09:27] <seb128> pitti, I doubt many things use gvfs http anyway
[09:27] <seb128> looking at bugs we get since we have gvfs the code is not working well for webdav
[09:27] <seb128> so it's basically used for podcast and http steaming
[09:27] <seb128> streaming
[09:27] <seb128> I don't think it can break a lot
[09:27] <seb128> out of podcast which is already not working...
[09:28] <pitti> 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] <pitti> slangasek: it just adds a new function
[09:28] <slangasek> pitti: if it looks safe to you then, go ahead
[09:39] <ttx> slangasek: could bug 455114 be the root cause for bug 454362 ?
[09:40] <slangasek> ttx: <sigh> yes
[09:40] <ttx> slangasek: ok, will mark it as such
[09:42] <james_w> oops, sorry
[10:09] <slangasek> ttx: would you have time to fix qemu-kvm this morning?
[10:10] <ttx> slangasek: I can try to find some. Let mle see if I understand the issue correctly
[10:17] <ttx> 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] <james_w> let me look
[10:18] <mvo> ttx: the fix should be pretty simple, just dropping the conflicts from qemu-kvm
[10:20] <ttx> mvo: yes, I just saw the problematic diff. I'm on it.
[10:20] <mvo> great, many thanks
[10:21] <ttx> mvo: do you see any point in keeping the Provides and Replaces ?
[10:23] <slangasek> ttx, mvo: I think you still need a versioned conflicts against the old version of kvm
[10:24] <slangasek> there are numerous file overlaps between kvm 1:84+dfsg-0ubuntu11 and qemu-kvm 0.11.0-0ubuntu5
[10:24] <slangasek> so probably Conflicts: kvm (<< 1:84+dfsg-0ubuntu16+0.11.0)
[10:26] <ttx> slangasek: ok, so a versioned Conflicts/Replaces... not sure the "Provides: kvm" makes any sense with transitional packages ?
[10:27] <slangasek> 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] <ttx> ok.
[10:44] <ttx> slangasek, mvo: I'm building a package to validate the following change: http://pastebin.ubuntu.com/296713/
[10:46] <slangasek> ttx: are you sure the qemu conflict should be made conditional like that?
[10:47]  * slangasek checks
[10:47] <slangasek> 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] <ttx> slangasek: ok
[10:48] <ttx> I'll doublecheck with my package build in various scenarios.
[10:49] <ttx> (whenever it finishes to build)
[11:20] <ttx> slangasek, mvo: installs correctly but fails on upgrade scenario: http://pastebin.ubuntu.com/296732/
[11:27] <ScottK> pitti: Thanks
[11:39] <slangasek> ttx: strange, checking why that conflict didn't show up in my check of the Contents
[11:40] <slangasek> 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] <evand> 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] <evand> 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] <slangasek> ttx: the archive confirms - how do you have /etc/qemu-ifup in a current qemu package?
[11:55] <davmor2> 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:57] <pitti> davmor2: can you please just submit it again? perhaps your retrace will get better
[11:59] <slangasek> oh gar, why am I now getting a 'low disk space' pop-up every 30 seconds? :P
[11:59] <slangasek> I don't remember it doing that before
[12:00] <pitti> hm, that should be a notification
[12:00] <pitti> oh, perhaps it has an action
[12:00] <slangasek> it does
[12:01] <slangasek> my objection is that it's giving me the same notification repeatedly, instead of just giving it to me once at login
[12:01] <slangasek> s/notification/pop-up/
[12:01] <pitti> *nod* that sounds like a bug
[12:01] <slangasek> and when I click 'ignore', it only ignores it for 30 seconds :P
[12:01] <seb128> nothing which changed recently though
[12:01] <slangasek> I suppose it's because my /home partition recently fell below whatever its threshold is
[12:02] <seb128> I guess so
[12:02] <slangasek> so every time it polls, it sees the partition has changed, so feels the need to ask me again
[12:02] <slangasek> just in case the different freespace number changes my mind :P
[12:03] <seb128> you can try to ping chrisccoulson when he's around
[12:03]  * slangasek nods
[12:03] <seb128> I think he had been looking at those issues
[12:03] <slangasek> although, I'd rather he fix my crashing gnome-settings-daemon first :)
[12:04] <davmor2> pitti: bug 455356
[12:04] <davmor2> that's the new one
[12:04] <pitti> davmor2: thanks; needs retracing first
[12:05] <davmor2> no probs
[12:08] <mvo> 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] <evand> mvo: http://pastebin.ubuntu.com/296733/ - sure thing
[12:20] <ttx> slangasek: hm, that strange. That test was an update from a jaunty setup with kvm and qemu installed.
[12:20] <chrisccoulson> slangasek - i hear you're getting repeated low-disk space notifications
[12:20] <ttx> slangasek: I think the Provides plays tricks here
[12:21] <slangasek> ttx: I don't think it's the Provides, no
[12:21] <slangasek> ttx: jaunty qemu had that file; I think it's a dpkg bug in the handling of the Replaces
[12:22] <slangasek> chrisccoulson: word travels fast ;)
[12:22] <chrisccoulson> heh, it does indeed. you only get the notifications for internal volumes right?
[12:22] <slangasek> chrisccoulson: AFAIK yes
[12:23] <chrisccoulson> that's ok then. how much space is on the volume at the moment?
[12:24] <chrisccoulson> 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] <chrisccoulson> and you should never get a notification for a volume that has more than 2GB free space either
[12:25] <slangasek> chrisccoulson: 96% used; I've seen at least 4 of the notifications since my most recent login
[12:25] <chrisccoulson> does the volume stay mounted the whole time, or do you ever unmount it at all?
[12:28] <ttx> slangasek: yes, it keeps /etc/qemu-ifup in the dummy qemu filelist on upgrade
[12:28] <slangasek> chrisccoulson: it's /home ;P
[12:29] <slangasek> ttx: right - so I think we just need an unversioned Replaces: qemu
[12:29] <ttx> slangasek: you read my mind
[12:29]  * ttx is happy to have tested in various scenarios, now :)
[12:30] <chrisccoulson> 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] <TheMuso> 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] <jono> TheMuso, what can we do to help repair relations with Lennart?
[12:50] <TheMuso> 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] <jono> TheMuso, sounds like a good idea
[12:50] <jono> let me know if I can help
[12:50] <TheMuso> jono: Ok thanks.
[12:51] <jono> np :)
[12:56] <Keybuk> pitti: about?
[12:57] <pitti> hey Keybuk
[12:57] <Keybuk> pitti: so, this INPUTCHAR usplash thing
[12:57]  * Keybuk *cannot* get it to work
[12:59] <pitti> Keybuk: you mean it doesn't work any more now?
[12:59] <pitti> Keybuk: I didn't use it recently; maybe it got broken during all those console handling changes
[13:00] <pitti> want me to write a test script?
[13:00] <Keybuk> script isn't helpful ;)
[13:00] <Keybuk> in C, I keep getting the open() call blocked
[13:01] <pitti> 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] <Keybuk> pitti: am I right in thinking that you have to continually send INPUTCHAR to usplash?
[13:08] <Keybuk> and that after sending you have to open the outfifo, read (which will block for up to a second) ?
[13:09] <pitti> Keybuk: the current implementation behaves that way, yes; I didn't want INPUTCHAR to block
[13:09] <pitti> otherwise it'd be utterly hard to write shell scripts that use it
[13:10] <Keybuk> ok, so at least my understanding is right
[13:10] <pitti> Keybuk: (see man usplash_write)
[13:11] <Keybuk> right, and the code
[13:11] <Keybuk> it just doesn't tend to work :)
[13:13] <pitti> ioctl(TIOCSCTTY): Operation not permitted
[13:13] <pitti> oha
[13:13] <Keybuk> yeah I see that one from time to time too
[13:13] <pitti> Keybuk: confirmed, it blocks here and doesn't work
[13:13] <pitti> Keybuk: http://people.canonical.com/~pitti/tmp/test-input.sh
[13:13] <Keybuk> I don't think that code path has changed though?
[13:14] <pitti> no, not since jaunty
[13:14] <pitti> but terminal handling did
[13:15] <Keybuk> which console did it output that ioctl error to?
[13:15] <pitti> Keybuk: gnome-terminal (from where I started the sript)
[13:15] <Keybuk> weird, it implies either
[13:15] <Keybuk> ah
[13:15] <Keybuk> no
[13:15] <Keybuk> you need --background on that usplash call if you do that
[13:16] <Keybuk> 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] <Keybuk> so try usplash -c -v --background
[13:16] <cjwatson> attr, I'm looking at you
[13:16] <pitti> Keybuk: --background? Should't -c do that?
[13:16] <Keybuk> pitti: no -c is VT flip
[13:16] <pitti> Keybuk: ah, seems --background isn't in the manpage
[13:17] <Keybuk> pitti: -> cjwatson ;)
[13:17] <cjwatson> oops
[13:17] <pitti> instead of & then, I guess
[13:17] <cjwatson> --background is to make it less racy
[13:18] <cjwatson> so the terminal setup and fifo opening is synchronous, and *then* it backgrounds
[13:18] <pitti> doesn't help to fix INPUT, though
[13:18] <Keybuk> weird, your script works for me ;)
[13:18] <Keybuk> cjwatson: though there's another race now which I have a fix for
[13:19] <Keybuk> cjwatson: (mask SIGTERM out until after the init is finished :p)
[13:20] <pitti> Keybuk: I updated the script to test "INPUT" as well (with a full line); hangs as well, though
[13:20] <Keybuk> that's odd
[13:21] <cjwatson> Keybuk,pitti: http://paste.ubuntu.com/296791/ was aimed at something else but may help here
[13:21] <Keybuk> does it hang or does it timeout?
[13:21] <cjwatson> esp. the tcsetattr crud
[13:22] <Keybuk> cjwatson: the termios stuff is probably useful
[13:22] <Keybuk> but the other bit is actually badly wrong
[13:22] <Keybuk> it'd mean if you pressed escape at exactly the wrong ms, usplash would disappear but not fsck
[13:23] <Keybuk> in fact, most input characters would get eaten by that code, rather than the INPUT checking code
[13:23] <cjwatson> hm, ok
[13:23] <cjwatson> well, I hadn't committed it yet because I hadn't got it all working :)
[13:23] <cjwatson> although I'm not entirely sure I agree with your analysis
[13:23] <cjwatson> INPUT sends usplash into a totally different loop
[13:24] <cjwatson> I think you may be incorrectly assuming a sane main loop design? :)
[13:24] <Keybuk> I'm thinking of INPUTCHAR here
[13:24] <pitti> Keybuk: times out
[13:24] <Keybuk> which is what we use to grab Escape
[13:24] <Keybuk> pitti: that implies not locking then, just not seeing input
[13:24] <Keybuk> cjwatson: INPUTCHAR is "check for escape", return to main loop
[13:25] <Keybuk> so you then end up with two bits of code reading from stdin
[13:25] <Keybuk> depending which one gets it, you get different behaviour
[13:25] <cjwatson> this is true
[13:26] <cjwatson> anyway, I meant you to try out the termios hackery and see if that helps
[13:26] <Keybuk> that being said, it might be cute to replace INPUTCHAR with something else
[13:26]  * pitti tries termios bits
[13:26] <Keybuk> ESCAPE %d
[13:26] <Keybuk> (when escape is pressed, send SIGHUP to %d)
[13:26] <Keybuk> you could patch that into your code then :p
[13:27] <mvo> evand: I followed up on #439485, I wonder if we can just make ubiquity ignore the error from cdrom.Add() ?
[13:27] <ogra> pitti, fyi, pulsating usplash works fine on my armel images
[13:27] <mvo> evand: maybe conditional on moblin
[13:27] <pitti> ogra: thanks
[13:27] <Keybuk> cjwatson: I don't think the termios fixes my problem though - because mine is that open() locks
[13:29] <pitti> doesn't work, no
[13:29] <pitti> still no input
[13:30] <Keybuk> pitti: are you using the bogl or svgalib backends?
[13:30] <pitti> Keybuk: bogl (with KMS)
[13:31]  * Keybuk wonders whether that makes a difference
[13:34] <pitti> Keybuk: I try it in kvm now (which uses svgalib)
[13:39] <Keybuk> err
[13:39] <Keybuk> W.T.F
[13:39] <Keybuk> warcraft scott% md5sum karmic-moblin-remix-i386.iso
[13:39] <Keybuk> 91e4f415767a45617f0cbfc5b0abd19c  karmic-moblin-remix-i386.iso
[13:39] <Keybuk> warcraft scott% md5sum karmic-moblin-remix-i386.iso
[13:39] <Keybuk> 26c3177ae594a3713b0e318e12e91e1b  karmic-moblin-remix-i386.iso
[13:39] <Keybuk> the md5sum changed over time
[13:39] <pitti> ext4?
[13:39] <Keybuk> yes
[13:41] <Keybuk> ext4 is scaring me
[13:42] <slangasek> 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:44] <Keybuk> slangasek: which mount-fiddling bits?
[13:44] <slangasek> Keybuk: auto_da_alloc=0
[13:45] <slangasek> Keybuk: is this ext4 on top of LVM or dm-crypt?
[13:45] <Keybuk> no
[13:45] <Keybuk> ext4 on top of hardware
[13:45] <sladen> ogra: so how come you have pulsations and we poor x86 users don't?
[13:45] <slangasek> Keybuk: ok
[13:45] <sladen> Keybuk: I tried the scheduer=deadline and it made no difference
[13:45] <pitti> Keybuk: test-input.sh doesn't work for me in KVM either, hmm
[13:46] <slangasek> Keybuk: sorry, I guess auto_da_alloc=0 is a boot-time module option rather than a mount option
[13:46] <pitti> sladen: pulsation> should be fixed since last Friday or so?
[13:46] <ogra> sladen, heh, no idea, get arm HW then :)
[13:46] <Keybuk> slangasek: isn't that the one about rename() and stuff?
[13:46] <Keybuk> I'm seeing md5sums being wrong on single files
[13:46] <Keybuk> and worse, md5sums *changing* on single files
[13:46] <Keybuk> assumedly the change was when that file left the page cache
[13:46] <slangasek> 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] <sladen> pitti: I see no pulsatations on boot.  If I should be seeing them, what is poking usplash to PULSATE?
[13:48] <pitti> sladen: only on live system boot, not on installed one
[13:48] <pitti> sladen: casper does
[13:51] <sladen> pitti: is the /lack/ of that POKE/PULSATE also the reason that usplash vanishes back to text-mode after 20 seconds
[13:51] <Keybuk> no
[13:51] <pitti> slangasek: that's just the normal timeout
[13:51] <pitti> (30 secs)
[13:52] <pitti> or something is stopping usplash prematurely, of course
[13:52] <pitti> which seems to happen for cryptsetup
[13:52] <pitti> I regularly see the "Starting crypto disks" init message in a VT
[13:52] <Keybuk> 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] <sladen> usplash is running for 20 seconds (by the stopwatch) and 23 seconds by the bootchart
[13:53] <Keybuk> 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] <Keybuk> (large debs being corrupted)
[13:54] <Keybuk> 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] <slangasek> 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] <tseliot> 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] <Keybuk> will do
[13:55]  * tseliot is looking for an example
[13:55] <Keybuk> tseliot: that's done by triggers
[13:55] <pitti> case "$1" in
[13:55] <pitti>     configure)
[13:55] <pitti>         if [ -x /usr/sbin/update-initramfs ]; then
[13:55] <pitti>                 update-initramfs -u
[13:55] <pitti>         fi
[13:55] <pitti> tseliot: ^ doesn't that do?
[13:56] <tseliot> yes, it does
[13:56] <tseliot> I was wondering what's the best practice to add new modules
[13:56] <pitti> (it also wraps dpkg triggering correctly)
[13:56] <sladen> tseliot: sudo update-initramfs ...
[13:56] <tseliot> is it ok to add the module to /etc/initramfs-tools/modules
[13:56] <tseliot> ?
[13:56] <Keybuk> tseliot: no
[13:57] <Keybuk> tseliot: use manual_add_modules in your initramfs hook
[13:58] <tseliot> Keybuk: that's exactly what I was looking for
[13:58] <tseliot> thanks everyone
[13:58] <Keybuk> tseliot: the framebuffer hook is a great example
[14:00] <tseliot> Keybuk: is it /usr/share/initramfs-tools/hooks/framebuffer ?
[14:00] <Keybuk> yes
[14:00] <tseliot> ok, thanks again :-)
[14:01] <Keybuk> err, apport-collect crashed
[14:02] <Keybuk> AssertionError: Need to have either "project" or "distro" option
[14:02] <slangasek> apport-collect -p linux 453579 ?
[14:02] <pitti> Keybuk: this should be fixed in 1.9.3-0ubuntu2
[14:03] <Keybuk> ok
[14:03] <Keybuk> slangasek: tried that ;)
[14:05] <Keybuk> so, I guess first question worth trying
[14:05] <Keybuk> anyone here on ext4? (installed fresh, not "upgraded" from ext3?)
[14:06] <ScottK> Keybuk: Yes
[14:07] <Keybuk> ScottK: if you wget an iso, md5sum it, sync and force a page cache flush, then md5sum it again
[14:07] <Keybuk> do you get the same md5sums?
[14:07] <ScottK> Keybuk: I'll check.  How do I sync and force a page cache flush?
[14:08] <Keybuk> (as root)
[14:08] <Keybuk> sync
[14:08] <Keybuk> echo 3 > /proc/sys/vm/drop_caches
[14:08] <ScottK> OK.  Just started downloading, so it'll be a bit.
[14:09]  * Laney too
[14:16] <Keybuk> pitti: I may, in fact, be a moron
[14:16] <Keybuk> (on the usplash thing)
[14:16] <Keybuk> I just looked at my code, and err, removed the close() syscall from before me reading from the descriptor
[14:19] <mvo> Keybuk: could you please have a quick look over https://bugs.edge.launchpad.net/ubuntu/+bug/452090/comments/8 ? just want to be sure that sysvinit-utils is fine without the hard depends (AFAICS the recommends should be more appropriate)
[14:19] <ion> keybuk: When i gdb’d a mountall crash last night, ‘if (stdin_io) nih_free (stdin_io);’ lead into nih_assert (ctx->destructor != NIH_ALLOC_FINALISED) aborting. I can’t figure out how that could happen from the code, though. :-\
[14:29] <mvo> hm, rescue mode in karmic runs with quite a bunch of daemons enabled (like NM), jaunty did not. a bug or a design decision?
[14:32] <pitti> doko__: bug 454621  says that they are for lucid; do we need them in main for karmic as well?
[14:37] <doko__> pitti: yes, packages b-d on it are now uploaded
[14:39] <Keybuk> nope, that wasn't it either
[14:41] <mvo> Keybuk: single user mode (e.g. grub rescue mode) in karmic runs with quite a bunch of daemons enabled (like NM, rsyslog), jaunty did not. is that a bug or a design decision?
[14:42] <Keybuk> mvo: vague design decision
[14:42] <Keybuk> mvo: single user mode is rather wishy washy
[14:43] <mvo> Keybuk: could we document it somewhere (or return to the traditional behavior) please? maybe in the release notes
[14:43] <Keybuk> depending on your POV, either too much is running or not enough is running
[14:43] <Keybuk> there is no traditional behaviour here
[14:43] <mvo> in my POV too much is running
[14:43] <mvo> well, I used to be able to "mount -o remount,ro /" in single user mode, that was quite handy in some situations
[14:43] <Keybuk> no you didn't
[14:44] <Keybuk> that's not worked in many releases
[14:44] <Keybuk> (unless by luck)
[14:44] <jdong> heh Jaunty even started up a lot of things for that to work
[14:44] <jdong> if I wanted ro I usually just init=/bin/bash
[14:45] <Keybuk> mvo: that kind of thing hasn't really worked since udev came along
[14:45] <Keybuk> I think we do need a proper recovery shell though
[14:45] <mvo> it used to work for me most of the time, I don't mind that much that it changed, it would just be nice to document it in the release notes
[14:45] <mvo> recovery shell++
[14:45] <Keybuk> but that it should be done properly, not abusing "single user mode"
[14:46] <Keybuk> in the sysv docs, the only difference between single user mode and multi user mode is the presence of login daemons/services ;)
[14:46] <mvo> dholbach had a incident where dpkg crashed during replacing his libc and that was a pita to recover (on a vserver miles away)
[14:46] <Keybuk> ie. switching from 2 to S/1 means killing X, getty and sshd
[14:46] <Keybuk> a proper recovery shell shouldn't even be running things like udev, and instead should offer a step-by-step process to check and mount filesystems, etc.
[14:47] <Keybuk> a bit more like windows F8 perhaps
[14:47] <mterry> Where could I see a list of packages I've sponsored?  (i.e. I signed it, but it wasn't my changelog)
[14:47] <mvo> friendly-recovery tries to cover a lot of this
[14:47] <Keybuk> mvo: friendly-recovery requires /usr to be mounted ;)
[14:47] <Keybuk> that's "too late" in recovery mode terms
[14:48]  * mvo adds it to the lucid specs
[14:48] <Keybuk> since then you need udev, probably mdadm or lvm, network-manager if it's on NFS, etc.
[14:49] <pitti> zul: rabbitmq-server's init script isn't set -e?
[14:50] <Keybuk> pitti: apparently Debian initscripts skeleton now says "NEVER USE -e"
[14:50] <pitti> zu_: since you added the pkill without "|| failure-handling-code"
[14:50] <pitti> oh
[14:50] <Keybuk> pitti: I've seen people now filing bugs to remove -e from init scripts
[14:50]  * pitti ♥ -e
[14:50] <zul> pitti: no it isnt
[14:50] <pitti> zul: thanks
[14:50] <Keybuk> pitti: indeed, this is why Upstart forces it <g>
[14:50] <pitti> excellent
[14:51] <Keybuk> mvo: for me, the biggest bug with friendly recovery is that you can't get there if a filesystem check fails
[14:51] <Keybuk> which is, err, precisely when you want it :p
[14:52] <iulian> mterry: I'm not sure if such a list even exists.
[14:52] <Keybuk> mvo: you really want *any* boot failure to automatically bring friendly recovery up
[14:52] <mterry> iulian: hmm, I feared as much.  would be nice
[14:52] <Keybuk> without requiring a special grub prompt
[14:53]  * mterry will have to keep track
[14:53] <Keybuk> and instead maybe use the grub prompt for an actual true safe mode (most services missing, safe drivers only, etc.)
[14:53] <ion> keybuk: A mountall crash from current ~ubuntu-core-dev code – although not the one i described earlier, still trying to reproduce it while logging – http://pastebin.com/f6f1e0cea
[14:54] <ion> keybuk: Dunno whether the ‘Bad file descriptor’ message in the log is relevant.
[14:55] <mvo> Keybuk: agreed, there is bug #385882 open aobut this
[14:55] <Keybuk> ion: valgrind would probably help with that one
[14:56] <Keybuk> mvo: I think this is more spec work than bug work
[14:56] <mvo> Keybuk: you mean its less work to just fix it than to write a spec for it?
[14:57] <Keybuk> mvo: no, it's a lot of work to fix it properly, so we should design and spec it, rather than treat it as a simple bug fix
[14:57] <ion> keybuk: Huh. A new kind of crash this time, not the nih_free assertion failure. http://pastebin.com/fd7325
[14:58] <ion> keybuk: I’ll test with valgrind.
[14:58] <mvo> Keybuk: aha, sorry. misunderstood. ok, I made a tomboy note about it and will add it as a lucid spec
[15:08] <Keybuk> slangasek: apport collected my personal information and passwords, and put it in the bug for you ;)
[15:08] <ion> :-D
[15:12] <ion> The laptop’s fan is running like crazy with valgrind running in a VM. :-)
[15:15]  * Keybuk hates usplash
[15:15] <Keybuk> it's a buggy piece of shit
[15:15] <pitti> +1
[15:15] <pitti> and we kept bolting on hack over hack over time
[15:17] <davmor2> Keybuk: when does xsplash replace it completely?
[15:17] <Keybuk> davmor2: never
[15:18] <davmor2> Nooooooooo
[15:18] <sebner> Keybuk: then replace it with plymouth :P
[15:19] <Keybuk> sebner: every time it's suggested, somebody points out that Plymouth is KMS only
[15:20] <ion> keybuk: Ah, this seems to be the problem: nih_main_loop → nih_io_handle_fds → nih_io_watcher → nih_io_closed frees the io, then mountall’s progress_timer still does stuff with it.
[15:20] <liw> . o O (how hard can it be to rewrite usplash from scratch, cleanly...)
[15:21] <Keybuk> liw: that's what Plymouth is, arguably
[15:21] <jdong> would it really hurt to just not splash at all before xsplash?
[15:21] <ion> keybuk: http://pastebin.com/f499c1409
[15:21] <Keybuk> ion: oh, double-free?
[15:23] <Keybuk> ion: that's not the fsck_reader bug though, right?
[15:23] <ion> keybuk: In this case, both mountall.c:3377 stdin_io->data = ... and mountall.c:3363 nih_free (stdin_io) happened after nih_io_closed had freed the object.
[15:24] <ion> keybuk: Yeah, there seem to be two bugs which appear randomly. I’ll try to get a valgrind report for that one, too.
[15:25] <cjwatson> jdong: that's what we tried in karmic, and everyone screamed
[15:27] <jdong> cjwatson: heh. Seems like a lot of man-hours spent on a logo screen that shows up for 5-10s
[15:27] <cjwatson> jdong: tell me about it
[15:27] <Keybuk> jdong: then you get people like sladen spending ages screaming and whining that the logo shows up for MINUTES and DOES NOT PULSATE!
[15:27] <tgpraveen> cjwatson: if the waiting time till xsplash is really small like say in karmic+1, then usplash won't be needed
[15:27] <tgpraveen> right?
[15:27] <cjwatson> tgpraveen: that was the theory in karmic
[15:27] <jdong> Keybuk: it's supposed to pulsate?
[15:27] <jdong> hahaha kidding!
[15:28] <tgpraveen> yeah. and in karmic it didn't become possible. but is that the plan for lucid?
[15:28] <Keybuk> trouble is, I'm spending my time tracking down why our piece of shit splash screen code keeps blocking on a fifo instead of figuring out why the boot is slow for some people
[15:29] <jdong> I'd have to say the latter is more important than showing an early splash screen in the first place.
[15:29] <Riddell> pitti: what's all this about X-Ubuntu-Gettext-Domain getting changed to X-GNOME-Gettext-Domain ?
[15:29] <jdong> </captain obvious>
[15:30]  * tgpraveen sees many forum posts with slow boot times
[15:30] <Keybuk> jdong: I would agree, but I was overruled
[15:30] <pitti> Riddell: the glib patch was sent to upstream, and SUSE is using it as well; our cdbs continues to use X-Ubuntu-
[15:30] <Keybuk> and so now I spend my time debugging the splash screen instead
[15:30] <jdong> Keybuk: :( shame... My sympathies
[15:30] <pitti> Riddell: (glib looks for both now)
[15:31] <Riddell> pitti: sakes, there's more in this world than glib
[15:31] <pitti> Riddell: sure, but what's wrong with changing it in packages which use glib?
[15:31] <Riddell> pitti: because those files are read by apps which don't use glib
[15:32] <Laney> Keybuk: (I tried the md5sum thing and they were both the same, if nobody else got back to you)
[15:33] <pitti> Riddell: ok; so does it need to be reverted for some packages?
[15:33] <sebner> Riddell: don't forget your lovely k3b :-P
[15:34] <Riddell> pitti: if there are packages in our archive which use this then they either need to be reverted to use X-Ubuntu or I need to update the kdelibs patch to look for X-GNOME
[15:34] <Riddell> pitti: but who picked X-GNOME, could nobody think of a desktop agnostic term to use?
[15:34] <pitti> Riddell: as I said, cdbs langpack.mk uses X-Ubuntu- for that
[15:35] <pitti> Riddell: FWIW, we should just have "Gettext-Domain:" and the fdo spec guys should just accept it into the spec..
[15:35] <pitti> it's X-<projectname>-<fieldname>
[15:35] <Riddell> who are these mysterious fdo spec guys?
[15:36] <Riddell> neither of the KDE guys listed at http://standards.freedesktop.org/desktop-entry-spec/latest/ are active
[15:38] <Riddell> pitti: so does anything in Ubuntu use X-GNOME in karmic.  will it in lucid?
[15:38] <pitti> Riddell: http://lists.freedesktop.org/archives/xdg/2005-June/005344.html was the original discussion
[15:38] <pitti> Riddell: I don't plan to flip the cdbs default anytime soon
[15:39] <pitti> s/anytime soon/until this gets resolved at fd.o/
[15:40] <pitti> Riddell, slangasek, james_w: any of you doing syncs? there are unflushed packages in syncs/
[15:40] <james_w> pitti: I was just flushing as you asked
[15:40] <Riddell> not I
[15:40] <james_w> should be clean now
[15:42] <james_w> sbeattie: are you asking for removal in bug 414866? I can't see a clear action there.
[15:43] <Riddell> pitti: there seems to be one person involved in that discussion and he doesn't have his name on the spec. has upstream glib accepted the patch?
[15:44] <pitti> Riddell: upstream glib> no, not yet
[15:44] <pitti> james_w: thanks
[15:44] <Riddell> pitti: so no packages have X-GNOME added by our packaging but does anything from upstream use it yet?
[15:45] <pitti> Riddell: it's just used in SUSE and Ubuntu so far, I never saw it upstream
[15:45] <pitti> and our patches for non-cdbs packages are ancient and all use X-GNOME as well
[15:45] <pitti> I can't guarantee that _nothing_ is using it, obviously, that'd require a thorough archive grep
[15:45] <Riddell> pitti: you mean they use X-Ubuntu?
[15:45] <pitti> oops, sorry, yes
[15:48] <Riddell> pitti: so I'll change https://wiki.ubuntu.com/UbuntuDevelopment/Internationalisation#Desktop%20Entries back to say X-Ubuntu, I'll also investigate what this means for KDE on suse (if they patch it of if they have no gnome .desktop translations) and what that means for KDE upstream
[15:48] <pitti> ok, sounds fine
[15:48] <pitti> let's keep X-Ubuntu- everywhere for now then
[15:56]  * Keybuk is confused
[15:56] <Keybuk> we have bcmwl-kernel-source on the USB key under pool/
[15:56] <Keybuk> but not its dependencies?
[16:01] <ion> keybuk: “Normally this just calls the close handler, or if not available, it closes the file descriptor and frees the structure (which may be surprising if you were hanging on to a pointer of it).” –the documentation for nih_io_closed. Yeah, we got surprised by it. :-)
[16:02] <Keybuk> ion: not really, just forgot I needed a close handler to clear the global pointer
[16:14] <lool> cjwatson: I'm looking at why moblin remix has no Packages file; I started reading from the "ship-live" task handling and found that moblin has no "ship-live" seed; I plan adding an empty ship-live seed to not break debian-cd tasks #includes, but are there other required per-project seeds?
[16:15] <lool> Do I want to create ship/blacklist/others as well?
[16:16] <cjwatson> not unless you need the objects generated from them
[16:17] <Riddell> pitti: do you have a reference for the glib patch being submitted upstream?
[16:17] <Riddell> (for that docs page)
[16:18] <tkamppeter> pitti, hi
[16:19] <lool> cjwatson: Ok so I'm just adding an empty ship + ship-live http://paste.ubuntu.com/296916/
[16:19] <cjwatson> sounds harmless
[16:26] <Riddell> sebner: yo
[16:26] <Riddell> sebner: k3b is in my PPA (~jr) I'm having trouble finding anyone to test it
[16:27] <Riddell> sebner: so if you are able to test it that would be lovely
[16:27] <sebner> Riddell: do you really want to dirty my lovely gnome with k3b? :P Sure I can install and start and play a little bit with it but currently no CD-R around
[16:29] <Riddell> sebner: yes please, if you have a CD writer the main test I want is that it doesn't complain about a missing CD writer at startup
[16:29] <sebner> Riddell: aye aye Sir!
[16:30] <LaserJock> cjwatson: any news on bug #452429 and https://code.launchpad.net/~laserjock/debian-cd/edubuntu/+merge/13442
[16:31] <pitti> Riddell: https://bugzilla.gnome.org/show_bug.cgi?id=569829
[16:34] <tkamppeter> pitti, can you have a look at bug 437997? It is collecting a lot of duplicates and I have a 1-line fix for it.
[16:34] <cjwatson> LaserJock: sorry, running behind ... so does nothing install the Edubuntu classroom server by default any more? I don't mind, would just like to double-check that
[16:36] <cjwatson> public service announcements: bugs with tarballs attached are more hassle than bugs with individual files attached
[16:36] <pitti> tkamppeter: please just upload
[16:38] <cjwatson> LaserJock: 452429 is perplexing
[16:38] <sebner> Riddell: I hope the other stuff which gets pulled in automatically doesn't hurt anything
[16:43] <ArneGoetje> Hi, can someone please sponsor https://bugs.edge.launchpad.net/ubuntu/+source/openoffice.org-dictionaries/+bug/409813 for me? Thanks a lot!
[16:44] <cjwatson> ooh, hang on, busted manifest-desktop
[16:46] <tkamppeter> pitti, already uploaded, bug updated.
[16:47] <pollex> hi
[16:47] <ScottK> Keybuk: md5sum didn't change for me, but it'd been sitting there done for a while before I checked the md5sum.  Dunno if it might not have already sync'ed on it's own
[16:47] <Laney> I tried it and it hadn't written out
[16:49] <LaserJock> cjwatson: well, I'm expecting a classroom server to be "Hit F4 and select LTSP and then edubuntu-desktop when the task selector comes up"
[16:49] <LaserJock> cjwatson: but we don't have a distinct task for the classroom server
[16:49] <cjwatson> isn't it edubuntu-server?
[16:49] <LaserJock> no
[16:49] <cjwatson> Task-Extended-Description: This task provides the Edubuntu classroom server.
[16:50] <LaserJock> ah, well
[16:50] <cjwatson> one of you guys might like to fix the seed headers then ;-)
[16:50] <LaserJock> it's a tad complicated
[16:50] <cjwatson> I've merged your branch, thanks
[16:50] <LaserJock> edubuntu-server installs things like moodle
[16:50] <LaserJock> and in the future hopefully other non-LTSP server bits
[16:51] <LaserJock> but we used to call LTSP the "classroom server"
[16:51] <LaserJock> so yeah, a bit confusing
[16:51] <LaserJock> we've had such problems with moodle that I dropped edubuntu-server off the DVD for Karmic
[16:51] <zul> asac: around?
[16:51] <LaserJock> cjwatson: thanks
[16:52] <asac> zul: yes.
[16:52] <asac> zul: but a call in a few
[16:52] <zul> asac: do you want to discuss augeas when you are off your call?
[16:53] <asac> zul: yes. will be there for you
[16:53] <zul> asac: thanks
[16:54] <Whoopie> asac: Hi, I try to find out why NM uses /dev/ttyUSB0 instead of /dev/ttyUSB2 of my Sierra MC8775 3G card. Could you give me some hints where to start?
[16:54] <Whoopie> asac: https://bugzilla.gnome.org/show_bug.cgi?id=598939
[17:04] <ion> keybuk: A quick fix at https://code.edge.launchpad.net/~ion/ubuntu/karmic/mountall/segfault-fix, but i haven’t managed to track down the mnt != NULL issue yet.
[17:04] <Keybuk> ion: 404
[17:05] <Keybuk> oh, s/,$//
[17:05] <Keybuk> ion: hah, obvious really
[17:07] <ion> There should be a way to say ‘gdb *that*, and also valgrind it’ after you see an arbitrary crash on your screen. :-P
[17:16] <Keybuk> ion: that's what core files are for
[17:21] <sebner> Riddell: looks good to me. Thumbs up
[17:26] <Riddell> sebner: it doesn't complain about missing CD writer?
[17:28] <sebner> Riddell: nope, k3b shows me the (empty) writer above the directories. Played a little bit with preferences etc etc. Everything works fine. I need a mp3 plugin though
[17:31] <Riddell> sebner: great, thanks
[17:32] <doko__> ubuntu-archive: please process liboro-java in binary NEW (documentation package)
[17:34] <smoser> slangasek, let me know when you want to chat about uec build output
[17:38] <ion> keybuk: Meh, i don’t seem to be able to reproduce that error.
[17:46] <Keybuk> huh
[17:46] <Keybuk> why does hdparm call sync?
[18:13] <Keybuk> huh
[18:13] <Keybuk> cjwatson: today's live image seems a little broken
[18:14] <cjwatson> Keybuk: -v? worked for me
[18:14] <cjwatson> (dinner)
[18:15] <Keybuk> cjwatson: 19.2
[18:15] <Keybuk> all icons missing, N-M didn't load, u6y not on desktop, etc.
[18:20] <Qwell> So, hrm.  You guys froze the Asterisk package at an rc version?
[18:21] <Qwell> That seems...err...  like a bad idea.  At best.
[18:28] <Qwell> 10 days..  is there still time for an exception to be started/acted on?
[18:31] <zul> can someone reject the php upload it shouldnt have gone there
[18:39] <mdz> bug 455619 has now happened to me on two different machines; is anyone else seeing it?
[18:43] <MausP> Hello. Have a question regarding the function of the graphical tool that does the distribution update.
[18:43] <MausP> does it only change the sources.list && apt-get update && apt-get dist-upgrade?
[18:43] <MausP> or is it more?
[18:52] <hyperair> it is more.
[18:52] <hyperair> there are some tidying up stuff that the update-manager does that isn't done by dpkg/apt
[18:58] <MausP> hyperair: can the tidying up stuff be done manually? my background:
[18:58] <MausP> I set up a internal mirror in our company for our internal users (about 20, slowly increasing *g*)
[18:59] <MausP> because our internet connection is quite slow I want that they use the internal mirror for update to karmic
[18:59] <MausP> at the moment on the mirror there is only jaunty
[19:00] <MausP> but when karmic will be final, then I want to add karmic to the mirror
[19:00] <MausP> I think the graphical updater changes sources list to a official xy.archive.ubuntu.com mirror
[19:01] <MausP> and that is what I don't want because it  f*cks up our slow internet connection :-(
[19:02] <johanbr> MausP, make your DNS give your internal mirror IP for xy.archive.ubuntu.com
[19:03] <johanbr> or set up a caching proxy
[19:30] <hyperair> MausP: change your /etc/hosts.
[19:30] <hyperair> MausP: i've had this issue before.
[19:30] <hyperair> MausP: i think there was some bug about it, to allow sysadmins to add their mirrors to the list of "ubuntu" mirrors.
[19:31] <hyperair> MausP: what you can do is you can add your mirror to /usr/share/python-apt/templates/Ubuntu.mirrors
[20:05] <Qwell> Any MOTU devs willing to hold my hand/walk me through trying to get an exception for a package?  The freeze exception process on the wiki isn't too helpful for this case, I don't think
[20:05] <Qwell> They all suggest filing a bug with the changelog of an updated version and/or diff.  Neither apply in this case.
[20:06] <hyperair> what case would this be?
[20:06] <Qwell> The Asterisk package.  Karmic should not ship with 1.6.0-rc2.
[20:06] <Qwell> err, 1.6.2.0-rc2
[20:06] <hyperair> and instead ship with ...?
[20:06] <Qwell> something released...
[20:08] <Qwell> Latest 1.6.1.x would be appropriate.
[20:09] <bostongeek24> hi
[20:09] <davmor2> Qwell: I think the idea is that it gets tested now so it is fit for the lts next release.  It's been done deliberately
[20:09] <bostongeek24> im new to the linux community
[20:09] <davmor2> Qwell: have a chat on #ubuntu-server
[20:09] <bostongeek24> im also just learning to program
[20:09] <bostongeek24> i want to develop for ubuntu
[20:10] <bostongeek24> what language is used to develop for ubuntu/debian?
[20:10] <Qwell> davmor2: I'm confused about why that channel would be relevant
[20:11] <bostongeek24> can people see what im saying?
[20:11] <davmor2> Qwell: Asterisk is a Voip service and therefore server the package has mostly been handles by them and Daviey in particular
[20:12] <bostongeek24> hello?
[20:12] <davmor2> bostongeek24: yes
[20:12] <bostongeek24> what language is used to develop for ubuntu/debian?
[20:13] <Qwell> davmor2: I'm familiar with what Asterisk is. :)  This would be a MOTU issue though, wouldn't it?
[20:14] <bostongeek24>  im currently learning python
[20:14] <Qwell> bostongeek24: Your question is highly flawed.  Ubuntu is a basically a large collection of software.  There are many different languages involved.
[20:14] <Qwell> bostongeek24: If there is some specific application (or set of applications) you're interested in, that may be a better start.
[20:15] <bostongeek24> @Qwell not really
[20:17] <davmor2> Qwell: Like I say Daviey is your man and the server team were dealing with it so there decision etc that's why I say ask there.  They are more likely to know :)
[20:19] <bostongeek24> is there a place that lists all of the software in ubuntu and what language it uses?
[20:19] <bostongeek24> like if i saw a list then i might see something i would like to develop for
[20:20] <bostongeek24> ??
[20:23] <bostongeek24> hello??
[20:24] <Pici> bostongeek24: I don't know of a list that exists like that.  I'd look at package dependencies (and build-dependencies) to see what languages they are written in.
[20:25] <bostongeek24> how do i do that?
[20:27] <Pici> bostongeek24: apt-cache showsrc packagename.  You may also want to join #ubuntu-offtopic since #ubuntu-devel is more of a working channel
[20:56] <[reed]> what's the channel where canonical's sysadmins hang out?
[20:56] <[reed]> need to report an issue
[20:59] <Pici> [reed]: Actually, theres #canonical-sysadmin
[21:00] <[reed]> thanks
[21:12] <kees> slangasek: I just uploaded libselinux with a fix for a total regression in python-selinux (all python modules went away).  the binary deb python-selinux is unseeded and in universe, so I'll leave it up to you when to push it wrt the RC ISOs.
[21:30] <lool> cjwatson: Hey, in debian-cd r829 you dropped empty Packages files from CD; was this to save space?
[21:30] <lool> cjwatson: We have a bug on the moblin remix CD that an APT popup appears when the CD is not an usable source
[21:31] <lool> cjwatson: evand suggested this might be an APT bug, but I'm not sure
[21:31] <lool> It seems ok for APT to reject this CD
[21:32] <lool> cjwatson: So I'd like to perhaps revert your change, or keep one Packages file
[21:32] <lool> bug is LP #439485
[21:57] <doko__> ubuntu-archive: please have a look at https://bugs.edge.launchpad.net/ubuntu/+source/maven2/+bug/454826/comments/2
[21:59] <chrisccoulson> slangasek - i've uploaded a build of g-s-d to my PPA which makes the housekeeping plugin more verbose. would you mind running it with "--debug --no-daemon" and capturing the output as the low disk space warning appears a few times? it should hopefully give me some idea why it's not working
[21:59] <chrisccoulson> https://edge.launchpad.net/~chrisccoulson/+archive/ppa is my PPA
[22:00] <smoser> soren, slangasek i've updated https://wiki.ubuntu.com/UEC/Images/Publishing to cover the state of ec2 build processing.
[22:05] <soren> smoser: I don't understand this: "LABEL must be set to the "label" for this promotion. That would be one like 'beta1' or 'rc' or 'release'."
[22:06] <soren> Perhaps it's just "promotion", that confuses me.
[22:06] <soren> I've never seen that word used this way.
[22:10] <doko__> ubuntu-archive: and I missed a main sync, libcommons-lang-java, now in bug #446263
[22:12]  * ccheney hates bugs
[22:13] <ccheney> just write everything in ada ;-)
[22:16] <ccheney> shtylman: can you take a look at 452518 and verify it is the correct fix?
[22:17] <dupondje> https://bugs.launchpad.net/ubuntu/+source/aptitude/+bug/391035
[22:17] <dupondje> could somebody give me a hint where to start searching in the code to fix this ?
[22:17] <dupondje> cause its so annoying :(
[22:22] <slangasek> Keybuk: "NEVER USE -e" -- augh
[22:22] <slangasek> Keybuk: passwords> hmm, clearly my timing was off, I meant to collect those from the bug before you had a chance to change them ;)
[22:26] <dholbach> Keybuk: did you have any luck with the vserver guys?
[22:30] <slangasek> mdz: 455619> can we get a dpkg / apt log to try to figure out why grub1 was installed in the first place?  (grub1 / grub2 are supposed to conflict, there was a window when they didn't, the question is why grub was pulled in at all here and whether we can do anything about that)
[22:30] <slangasek> zul: php5 rejected as requested
[22:41] <mathiaz> zul: slangasek: what's the plan for samba 3.4.2 - bug 447360?
[22:45] <doko__> slangasek: do you agree with the fltk1.1 solution proposed in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=551612 ?
[22:48] <cjwatson> lool: I think it was to deconfuse something in the installer; please don't revert the change, but feel free to make it conditional on moblin or something
[22:49] <slangasek> doko__: why does he believe it's safe?  That's the entirety of the question
[22:50] <slangasek> mathiaz: I don't have any plan yet, do you need me to review that quickly?  Or do you want to just upload and have us pick it up from the queue?
[22:50] <mathiaz> slangasek: well - I was just triaging the New,Incomplete bugs
[22:50] <mathiaz> slangasek: I'll take it up with zul then
[22:52] <lool> cjwatson: ok; that's the temporary fix I had in mind, but I can as well call it final  :)
[22:52] <doko__> slangasek: my workaround would be to reference the methods in some other unused code
[22:54] <slangasek> doko__: does that mean you know that it's *not* safe?
[22:54]  * ccheney found out there are more kde4 bugs in OOo, argh!
[22:58] <doko__> slangasek: no, but it looks more like a fix in GCC, with 4.3 introducing these new symbols. if you look from 4.2 -> 4.4, there are no missing symbols
[22:59] <slangasek> doko__: ok - that's more convincing to me than anything else I've heard so far... go ahead and trim the symbols, then
[23:07] <asac> doko: bug 455647
[23:08] <slangasek> zul: I'm not going to give a freeze exception for fixing up LSB init script headers that we don't use
[23:09] <slangasek> asac: missed targeting to release? (done)
[23:09] <asac> doing many things in parallel ;)
[23:09] <asac> thx
[23:11] <bluefoxicy> so here's an interesting sit for you.
[23:11] <bluefoxicy> I just unplugged my ISP's wifi router (they control it, I walked over to it and disabled it)
[23:11] <bluefoxicy> they have another one nearby I can reach.
[23:11] <bluefoxicy> the one I unplugged is broken; when it's plugged in, I can't connect to the wifi, as it fails to negotiate properly.
[23:11] <bluefoxicy> when they plug it back in, I'll be redirected to it, and instantly lose internet.
[23:12] <bluefoxicy> why can't I select specifically which router to use, by MAC address?
[23:12] <slangasek> doko__: buildds still on manual for maven?
[23:13] <doko__> slangasek: no, not anymore
[23:13] <slangasek> doko__: ok, cool
[23:13] <doko__> asac: yes, known, fixed by libxalan2-java which should be in the archive by now
[23:14] <ccheney> bluefoxicy: KDE probably would let you do that ;-)
[23:15] <ccheney> bluefoxicy: or maybe using /etc/network/interfaces directly
[23:15] <ccheney> bluefoxicy: hmm actually it seems NM can do it too, or at least lets you type a mac in
[23:15] <ccheney> bluefoxicy: whether it actually do anything with it i don't know
[23:15] <ccheney> bluefoxicy: go to edit connection information
[23:15] <slangasek> doko__: how does the new libxalan2-java fix it?  that looks like a missing Conflicts/Replaces from libjaxp1.3-java
[23:17] <slangasek> smoser: sorry, I was up all night to get the ball rolling on ISO smoketesting, and am just now catching up with things today; I'll dig into UEC publishing here shortly and ping you back if you're still around
[23:17] <bluefoxicy> ccheney:  that's non-obvious ;)
[23:18]  * bluefoxicy clicks Edit, and the app freezes.
[23:18] <ccheney> bluefoxicy: heh, works for me :-\
[23:18] <ccheney> well the edit part anyway, didn't test the mac part
[23:18] <bluefoxicy> ccheney:  oh, I'd just like to see the menu pop out so you can select from the APs
[23:18] <ccheney> bluefoxicy: needing to set a mac address isn't common though so wouldn't be the default to pop up and ask you it on connection
[23:19] <ccheney> bluefoxicy: ah yea that would be nice too
[23:19] <bluefoxicy> ccheney:  I mean like put an arrow next to the signal strength, if I click it it pops out a submenu "hey here's all the APs related"
[23:19] <bluefoxicy> so I can force instead of let it autoneg.
[23:20] <ccheney> yea, normally the one with the strongest signal is the best one to use.. except in your case ;-)
[23:20] <bluefoxicy> btw I'm on Karmic
[23:20]  * ccheney is still on jaunty, will be upgrading in a few days
[23:20] <bluefoxicy> heh one day I really want a Gentoo-like apt repo
[23:20] <slangasek> no, we definitely don't want to give people an easy button for hard-associating with a particular AP
[23:20] <davmor2> bluefoxicy: just go into n-m and delete yours for the time being
[23:21] <slangasek> people will click it and not understand why their wireless has stopped working when they've roamed out of range of that AP
[23:21] <bluefoxicy> i.e. I don't want to see 16MB files to download just to update 3 packages
[23:21] <jdong> heh around here, the way the wifi is laid out, it's kind of evil...
[23:21] <bluefoxicy> slangasek:  oh, because our users are complete retards then and wifi is harder than the special olympics?
[23:21] <ccheney> slangasek: well it could be made easier than having to use iwlist
[23:21] <jdong> there are places with two AP's located on different subnets broadcasting the same ESSID
[23:22] <jdong> so if your wifi driver chooses to roam between the two, that's death
[23:22] <jdong> (naturally they are in the process of putting all of the wifi across campus on the same subnet *cringe*)
[23:23] <bluefoxicy> slangasek:  were you the same guy that decided that if Ubuntu prints status messages during boot (Loading Hardware Drivers... OK, Checking File Systems... OK) that the users will be "shocked" and will immediately cry that the computer is broken?
[23:23] <slangasek> bluefoxicy: that's inappropriate for this channel
[23:24] <bluefoxicy> slangasek:  Is it?  I asked in this channel about the 'quiet' option, and someone actually argued that if Grub prints out something like "Loading kernel..." and a bunch of text for half a second, the users would actually become shocked and confused, and it would impair their ability to use the computer
[23:24] <bluefoxicy> this was like 5 releases ago though
[23:24] <slangasek> bluefoxicy: your earlier comment.
[23:25] <bluefoxicy> slangasek:  well that's the impression I get from some of the developers.  If it's not mind-numbingly simple on a level that almost if not definitely breeds stupidity, it's assumed that the user will somehow screw it up in every case and must be kept away from any such thing at all costs.
[23:26] <slangasek> I didn't say "in every case".  You're putting up a strawman
[23:26] <bluefoxicy> the thing is I don't want the simplest things like "Associate with a different AP" or "what stage is your boot process stalling at" to come down to loading up a recovery CD on a command line and having a deep understanding of all the various configuration files on a Linux system
 people will click it and not understand why their wireless has stopped working when they've roamed out of range of that AP
[23:27] <bluefoxicy> ^^^ this argument is only significant if that's the majority of user experiences, and people aren't smart enough to figure out why this happens
[23:27] <cjwatson> 23:21 <bluefoxicy> slangasek:  oh, because our users are complete retards then and wifi is harder than the special olympics?
[23:27] <cjwatson> that needs an apology
 no, we definitely <-- And apparently you definitely think this is the case
[23:28]  * ccheney hopes his OOo mailbox doesn't fill back up by tomorrow, heh
[23:30] <slangasek> seb128: how's the GNOME queue looking?
[23:30] <ccheney> did the apport retrace service die?
[23:36] <seb128> slangasek, quite well, not sure what you want to know exactly though
[23:36] <slangasek> seb128: when it will be settled so that I can start RC rolls
[23:36] <seb128> slangasek, ie there is a few sponsoring request waiting and a bunch of things not updated yet
[23:37] <chrisccoulson> i'm just about to do gnome-terminal ;)
[23:37] <bluefoxicy> read(4, 0x1239620, 2048)                = -1 EAGAIN (Resource temporarily unavailable)
[23:37] <bluefoxicy> poll([{fd=4, events=POLLIN}], 1, 24996
[23:37] <slangasek> seb128: so probably not ready for rolls until tomorrow morning?
[23:37] <seb128> slangasek, I don't think there is lot of importants updates waiting, I would appreciate to still have tomorrow morning to sponsor robert_ancell's work from his day and review some things though
[23:38] <seb128> so it's your call
[23:38] <seb128> if we can wait tomorrow 10utc that's nice
[23:38] <seb128> if you want to roll earlier we can stop with what we will have when I go to bed in one hour or so
[23:38] <cjwatson> slangasek: ubiquity upload likely to be coming soon as well (tonight, I think), but I'm still holding out hope that I can figure out what's up with wubi
[23:39] <bluefoxicy> open("/usr/share/themes/Default/gtk-2.0-key/gtkrc", O_RDONLY) = 4 ... apparently it's stalling on gtkrc read?  *headscratch*
[23:39] <slangasek> seb128: I'll probably do some interim rebuilds just to be sure everything is still on track, probably waiting for cjwatson's uploads, then do the final desktop rolls tomorrow after 10
[23:39] <seb128> slangasek, sounds good, thanks
[23:40] <seb128> slangasek, btw you are welcome to give an hand or sponsoring if you want, there is a bunch of updates on http://people.canonical.com/~dholbach/sponsoring/index.html
[23:41] <slangasek> seb128: it's unlikely that I'll have time, and then I have to worry besides about whether I should get other eyeballs on it in the queue :/
[23:41] <seb128> ok, no problem
[23:41] <seb128> in fact there is 2 items waiting right now so we should manage