[00:18] <slangasek> kirkland: your base-files upload doesn't modify debian/links?
[00:18] <kirkland> slangasek: it wasn't actually created
[00:18] <kirkland> slangasek: i backed it out
[00:18] <slangasek> $ dpkg -L base-files|grep etc/motd
[00:18] <slangasek> /etc/motd
[00:18] <kirkland> slangasek: i couldn't actually figure out who's creating that link at this point ... any hints ?
[00:19] <slangasek> the file is listed as belonging to the package
[00:20] <kirkland> slangasek: debian/rules:         ln -sf /var/run/motd debian/tmp/etc/motd
[00:20] <kirkland> slangasek: i'll prune that line
[00:20] <kirkland> slangasek: sorry
[00:20] <kirkland> slangasek: thanks for the sanity check
[00:23] <slangasek> kirkland: sure thing
[00:24] <slangasek> kirkland: since it's no longer in the package, that also means the symlink will disappear on upgrade - so the version check in the postinst needs to be dpkg --compare-versions "$2" lt 5.0.0ubuntu17, not just -z "$2"
[00:24] <kirkland> slacker_nl: http://paste.ubuntu.com/413371/
[00:25] <slangasek> kirkland: why was the 'rm -f' line there?  hopefully that was redundant :)
[00:25] <kirkland> slangasek: yeah, redundant
[00:26] <zul> slangasek: thanks...i saw your earlier comment but havent gotten to it yet
[00:26] <slangasek> zul: well, can you confirm that these packages are supposed to be in main?  I can fix up the seeds quickly for that
[00:27] <zul> slangasek: yeah they are
[00:27] <slangasek> ok
[00:27] <slangasek> I'll follow through then
[00:30] <kirkland> slangasek: http://paste.ubuntu.com/413375/
[00:30] <kirkland> slangasek: can you give that a once-over?
[00:30] <slangasek> kirkland: looks good; please do an upgrade test before upload, to confirm
[00:30] <kirkland> slangasek: ack
[00:54] <kirkland> slangasek: that rm -f debian/tmp/etc/motd was not in vain
[00:54] <kirkland> slangasek: some other part of the packaging was putting something there
[00:56] <kirkland> slangasek: http://paste.ubuntu.com/413388/ appears to be doing the right thing
[00:59] <slangasek> ok
[01:04] <kirkland> slangasek: http://pastebin.ubuntu.com/413396/
[01:06] <slangasek> kirkland: looks good
[01:06] <kirkland> slangasek: cheers, thanks, uploading
[01:33] <FeasibilityStudy> I keep getting kernel failure messages on boot, and when apport runs, it cannot show me the details because I get a permissions error
[01:33] <FeasibilityStudy> IOError(13, 'Permission denied')
[02:47] <psusi> hoo rah!  e2defrag now works with uninit_bg, crc checksumed block group descriptors and all!
[04:17] <robertzaccour> i reported a bug a while back, it seems to have been forgotten about
[04:17] <robertzaccour> https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/555503
[04:18] <robertzaccour> is there any possibility it will be fixed before the final release?
[04:21] <robertzaccour> anyone here?
[04:21] <RAOF> robertzaccour: THat's likely to be fixed by booting with the powersave=0 option; have you tried that (as requested in the bug)?
[04:21] <genii> robertzaccour: 279 give or take
[04:22] <robertzaccour> RAOF, i tried that, didn't work
[04:22] <robertzaccour> genii, whats that mean?
[04:23] <robertzaccour> i reported it and the info was incomplete, then i included the needed info, then it was confirmed and seems to be forgotten about. wish there was somethin i could do. i do what i can to help when possible
[04:23] <genii> robertzaccour: This channel has currently about 279 people in it. So the question "anyone here" has the answer of 279.
[04:23] <robertzaccour> genii, oh i see haha just wan't sure who was awake thanks
[04:25] <robertzaccour> is it likely to be fixed before the release? i'm hoping so. all thats happened in the report is confirmed
[04:26] <soren> nixternal: Still awake?
[04:26] <soren> nixternal: When did we decide tomorrow's DMB meeting was going to be?
[04:27] <robertzaccour> did i ask a bad question?
[04:28] <persia> soren: Isn't it 15:00 as always?
[04:28] <soren> persia: It may be.
[04:28] <genii> robertzaccour: There are no bad questions. There are questions to which there are no immediate answer.
[04:28] <persia> That's when I'm planning to be paying attention, if that matters :)
[04:28] <nixternal> soren: 15:00, my alarm on my cell phone just went off 15 minutes ago letting me know to wake up for it :)
[04:29] <soren> Fair enough. I Google'd it, got UWN which said 1400 UTC.
[04:29] <robertzaccour> if the bug has been confirmed and no other action, should i assume its gonna be fixed well after the release if it is?
[04:29] <robertzaccour> wish there was something else i could do
[04:30] <soren> persia, nixternal: Thanks. I'll try to make it. I'm holidaying with the family, so it may not work out.
[04:31] <persia> Best of luck on finding the opportunity to be present :)
[04:31] <persia> (and have fun otherwise)
[04:31] <soren> Thanks, and will do.
[04:31] <RAOF> Yeah.  For what it's worth, other people with what sound like a similar bug have found that i915.powersave=0 fixed it for them.  One thing you could try would be using the drivers from the xorg-edgers PPA; they're newer and might already have a fix for you.
[04:33] <nixternal> i have been on holiday for the past year
[04:34] <robertzaccour> RAOF, you talkin to me?
[04:34] <RAOF> Yes.
[04:35] <ajmitch> nixternal: I'm sure I can beat that :)
[04:35] <robertzaccour> RAOF, i915powersave=0 didn't work for me. where can i get xorg-edgers PPA?
[04:35] <soren> Whoever reviewed python-cloudservers source and binary: Big thanks!
[04:35] <soren> I wished we kept track of that.
[04:36] <soren> s/wished/wish/
[04:36] <nixternal> ajmitch: how much longer for you?
[04:36] <RAOF> robertzaccour: launchpad.net/~xorg-edgers/ppa/+archive.  Bear in mind that those are unsupported drivers.  If they work for you, it's possible that we could isolate what's fixed it and backport to Lucid.
[04:38] <robertzaccour> RAOF, should i try the pre-released and unsupported updates in software souces option also?
[04:38] <ajmitch> nixternal: who knows, I occasionally do a few uploads, like today
[04:39] <RAOF> robertzaccour: There's nothing in there at the moment; that will start to be populated once Lucid is released.
[04:39] <robertzaccour> RAOF, it said page not found
[04:39] <RAOF> Sorry; http://launchpad.net/~xorg-edgers/+archive
[04:41] <robertzaccour> RAOF, thanks. which link do i select?
[04:42] <RAOF> There's a section “Adding this PPA to your system” with details.
[04:45] <robertzaccour> oh i got it thanks
[04:45] <robertzaccour> i'm gonna update and then restart thanks
[04:46] <robertzaccour> brb
[04:49] <robertzaccour> back
[04:50] <robertzaccour> RAOF, thanks again. i'll keep an eye on it for a few minutes and let ya know what happens
[04:54] <robertzaccour> RAOF, it didn't seem to work, just did it again
[04:54] <slangasek> chrisccoulson: seen that xulrunner-1.9.2 still FTBFS on ia64?
[04:56] <slangasek> chrisccoulson: ah, yes you have because you've commented on the bug :-)
[04:56] <slangasek> chrisccoulson: in the meantime, I'm nuking the out-of-date couchdb-bin binary on ia64, so we can get component-mismatches cleaned up
[04:59] <robertzaccour> RAOF, it didn't work and I posted a comment on the launchpad log file. thanks anyhow
[04:59] <robertzaccour> any other ideas?
[05:00] <robertzaccour> did i make someone mad?
[05:01] <RAOF> boot, adding the “drm.debug=0x06” kernel parameter to the boot line.  Wait until you've reproduced the bug, then run “dmesg > dmesg.log” and attach both dmesg.log and /var/log/Xorg.0.log to the bug.
[05:02] <RAOF> That will cause all sorts of debugging information to be attached to those logs, and we can send it upstream.
[05:02] <robertzaccour> RAOF, is that in the grub you're talking about next to the end of the text?
[05:04] <RAOF> Yup.  In the same place as you'd put the “i915.powersave=0” bit; just after “quiet splash”
[05:05] <robertzaccour> RAOF, whats /car/log/Xorg.0.log?
[05:06] <RAOF>  /var/log/Xorg.0.log is your X log file.
[05:06] <robertzaccour> RAOF, oops i meant /var/log/Xorg.0.log
[05:06] <robertzaccour> do i type that in the terminal too?
[05:06] <RAOF> No, you attach it to the bug.
[05:07] <robertzaccour> how do i attatch it? just type it in the comments?
[05:08] <RAOF> There's an “add attachment or patch” button at the bottom of the bug page, just after the “add comment” box.
[05:08] <robertzaccour> oh ok thanks
[05:09] <robertzaccour> i'll try that brb
[05:12] <robert__> RAOF, in the drm.debug=0X06 i capitalized the x. was i wrong?
[05:12] <robert__> huh?
[05:12] <RAOF> robert__: I'm not sure; I think you should...
[05:13] <robertzaccour> RAOF, was i supposed to capitalize that x or does it matter?
[05:13] <RAOF> I don't know if it matters or not.  It would probably be best to not capitalise it, though.
[05:14] <robertzaccour> RAOF, ok i'll try it again then brb
[05:18] <robertzaccour> back
[05:19] <robertzaccour> RAOF, what you told me to run didn't do anything
[05:21] <RAOF> What do you mean by “didn't do anything”
[05:21] <robertzaccour> RAOF, dmesg > dmesg.log
[05:21] <RAOF> dmesg > dmesg.log will create a file called “dmesg.log” in your home directory.
[05:22] <robertzaccour> i did it right that time and thats what it said
[05:22] <robertzaccour> robert@robert-laptop:~$ dmesg . dmesg.log
[05:22] <robertzaccour> Usage: dmesg [-c] [-n level] [-r] [-s bufsize]
[05:22] <robertzaccour> thats what it said when i typed it right this time
[05:22] <RAOF> Um, that's not the same as “dmesg > dmesg.log”
[05:22] <RAOF> . is not the same as > :)
[05:24] <robertzaccour> http://pastebin.com/HEkQe7Bm
[05:24] <robertzaccour> thats whats in the folder
[05:24] <robertzaccour> does that look right?
[05:25] <RAOF> That looks right, but you didn't boot with drm.debug=0x06
[05:25] <robertzaccour> RAOF, i did
[05:25] <robertzaccour> at the end of all the text i put a space between that last word and what you said to put
[05:26] <robertzaccour> did i insert it wrong? i thought it was correct
[05:27] <RAOF> I think you've inserted it wrong.  Which is good!  Because that means you probably inserted the i915.powersave=0 wrong too, which means it might fix your bug.
[05:28] <robertzaccour> how was i supposed to insert it? at the grub menu i pressed e. went to the end of all that text, added a space, then inserted what you said
[05:29] <RAOF> Ok.  So, rather than the end of all that text, you want to go next to the “quiet splash” bit, hit space, and then add i915.powersave=0.  This should be on the *same line* as “quiet splash”.
[05:30] <robertzaccour> RAOF, i didn't see anything about quiet splash, but i'll check again brb
[05:30] <robertzaccour> RAOF, to the right of that line?
[05:30] <RAOF> I'm taking a photo of what it should look like.
[05:30] <robertzaccour> and should i delete the repos from earlier?
[05:30] <robertzaccour> oh ok
[05:32] <robertzaccour> should i delete those x repos i added earlier?
[05:33] <RAOF> That's probably a good idea.
[05:33] <RAOF> You should follow the instructions from the xorg-edgers site - use “ppa-purge”
[05:33] <robertzaccour> RAOF, i just deleted those repos
[05:34] <robertzaccour> i'm gonna restart and look for "quiet splash"
[05:34] <robertzaccour> brb
[05:36] <robertzaccour> RAOF, i'm back
[05:37] <robertzaccour> the line ends like this now quiet splash i915.powersave=0
[05:37] <robertzaccour> is that correct?
[05:37] <RAOF> That sounds correct, yes.
[05:37] <robertzaccour> oh i didn't use ppa purge? i just deleted those repos via gui
[05:38] <robertzaccour> RAOF, so i should just wait a few minutes and see if the bug is still there?
[05:38] <RAOF> That won't have removed the packages.  You probably want to re-add the PPA and then use ppa-purge.
[05:38] <RAOF> Yes.  Wait a while and see if that's fixed it first :)
[05:38] <robertzaccour> how do i do ppa purge?
[05:39] <RAOF> It's a package in the xorg-edgers PPA.  You run “sudo ppa-purge ppa:xorg-edgers” and it removes the ppa packages, installs the ubuntu ones, and then disables the PPA repository.
[05:39] <robertzaccour> its a quick blink so i'll try not to blink lol
[05:39] <robertzaccour> should i reinstall them before doin that or go ahead and purge?
[05:41] <RAOF> You haven't removed the packages.  Removing the repository just means you won't be getting any updates - the packages that you already had installed will remain.
[05:43] <robertzaccour> RAOF, oh ok installing now
[05:44] <robertzaccour> RAOF, it says command not found
[05:44] <RAOF> You'll need to install the ppa-purge package first.
[05:44] <robertzaccour> i did
[05:46] <robertzaccour> RAOF, http://pastebin.com/bYfXGRSG
[05:46] <robertzaccour> thats what the update says
[05:46] <robertzaccour> sudo-apt-get update
[05:47] <robertzaccour> RAOF, robert@robert-laptop:~$ sudo ppa-purge ppa:xorg-edgers
[05:47] <robertzaccour> sudo: ppa-purge: command not found
[05:47] <robertzaccour> robert@robert-laptop:~$
[05:48] <RAOF> You now also need to run “sudo apt-get install ppa-purge”.  That installs the ppa-purge package.
[05:48] <robertzaccour> RAOF, oh i did the ppa but forgot to install them lol sorry
[05:49] <robertzaccour> robert@robert-laptop:~$ sudo apt-get install ppa-purge
[05:49] <robertzaccour> Reading package lists... Done
[05:49] <robertzaccour> Building dependency tree
[05:49] <robertzaccour> Reading state information... Done
[05:49] <robertzaccour> E: Couldn't find package ppa-purge
[05:51] <RAOF> Then you'll need to re-add the xorg-edgers PPA; that means that you don't have the right PPA added.
[05:52] <RAOF> Incidentally, have the flashes been occuring?
[05:53] <robertzaccour> RAOF, no not since the i915.powersave=0
[05:54] <robertzaccour> RAOF, i see xorg in synaptic
[05:56] <robertzaccour> lucid wasn't listed in the sources so i just changed the word karmic to lucid
[05:57] <robertzaccour> i did it again and still can't find it
[05:58] <robertzaccour> well, i guess if it can't find it maybe i can just delete it from the repos
[05:58] <RAOF> Ok.  Run “sudo add-apt-repository ppa:xorg-edgers” from a terminal.  That will definitely add the right repository.  Then run “sudo apt-get update”, then “sudo apt-get install ppa-purge”
[06:00] <robertzaccour> ok
[06:02] <robertzaccour> RAOF, i did those commands. is it ok to delete it from software sources now? its still there
[06:02] <robertzaccour> RAOF, i guess i purged it
[06:03] <RAOF> If you run “sudo ppa-purge ppa:xorg-edgers” the repository will automatically get removed.
[06:03] <robertzaccour> i know i did that and the terminal did its thing, but in the software sources gui i see the 2 i added plus the one i added in the terminal
[06:05] <robertzaccour> robert@robert-laptop:~$ sudo ppa-purge ppa:xorg-edgers
[06:05] <robertzaccour> PPA to be removed: ppa:xorg-edgers ppa:xorg-edgers
[06:05] <robertzaccour> Warning:  Could not find package list for PPA: ppa:xorg-edgers ppa:xorg-edgers
[06:05] <robertzaccour> robert@robert-laptop:~$
[06:06] <robertzaccour> haven't noticed any more screen blinking
[06:08] <robertzaccour> RAOF, is this gonna be a problem? the ppa i mean
[06:09] <robertzaccour> RAOF, brb i'll read when i get back if you type anything
[06:09] <RAOF> Try running “sudo apt-get update && sudo ppa-purge xorg-edgers”.  The PPA is not necessarily a problem, but it will mean that you don't get updates or support, and there are almost certainly bugs in those drivers which are not in the Ubuntu packages (and visa versa, obviously).
[06:15] <robertzaccour> back
[06:17] <robertzaccour> RAOF, http://pastebin.com/SFA5q72j
[06:18] <robertzaccour> but look at this
[06:19] <RAOF> Good, that seems to have worked.
[06:19] <robertzaccour> wait brb
[06:22] <robertzaccour> http://i455.photobucket.com/albums/qq274/Knuckle_Brawler/Screenshot-1-2.png?t=1271136148
[06:23] <robertzaccour> thats what i meant by still in the software sources gui
[06:25] <robertzaccour> oh and still haven't seen any screen blinking :)
[06:29] <robertzaccour> RAOF, hey you still there?
[06:29] <RAOF> That's fine; that's the other PPAs that you have enabled.
[06:30] <robertzaccour> RAOF, oh ok i'll just delete those
[06:31] <robertzaccour> RAOF, how do i make this permanent?
[06:31] <robertzaccour> and how should i post this on launchpad?
[06:33] <robertzaccour> RAOF, you still there?
[06:34] <robertzaccour> a lot of quit text along the screen there, did i lose ya in the text? lol
[06:35] <robertzaccour> RAOF, are you there?
[06:36] <robertzaccour> i need to submit a confirmed bug fix. can someone help me do it properly?
[06:39] <robertzaccour> RAOF_, hey you there?
[06:39] <robertzaccour> can anyone help me with this confirmed bug fix?
[06:39] <robertzaccour> I need to make sure i posted it right on the log or at least know how to make it a permanent fix on my system
[06:40] <robertzaccour> please someone that can help me please respond
[06:40] <persia> What's the bug number?
[06:40] <robertzaccour> https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/555503
[06:41] <robertzaccour> persia, the update worked. now i just gotta make it a permanent boot up from my end and make sure i posted it correctly at the very end of the log
[06:41] <RAOF_> I've already updated the launchpad bug; to make this permanent you can edit /etc/default/grub, and add i915.powersave=0 next to quiet splash.
[06:42] <persia> Yeah, the bug state looks great.
[06:42] <robertzaccour> RAOF_, what do i do now?
[06:42] <robertzaccour> RAOF_, is there any way i can make it permanent on my end or just wait for the updates?
[06:47] <robertzaccour> are yall awake? anything else i can do? can i make it a permanent change from my end?
[06:54] <robertzaccour> did i add i915 powersave correctly? http://pastebin.com/REXnmmUw
[06:57] <robertzaccour> RAOF_,  persia did i add i915 powersave correctly? http://pastebin.com/REXnmmUw
[06:57] <persia> You're at least missing a close-double-quites
[06:58] <robertzaccour> persia, whats that mean?
[06:59] <persia> On line 9, you want to add stuff *inside* the quotes.
[07:00] <robertzaccour> persia, thats what it brought up when i ran /etc/default/grub
[07:01] <robertzaccour> persia, with other people's help we found a bug fix, reported it, and now just gotta get it set to the grub defaults on my end
[07:02] <persia> Right.  On line 9, you want to add the extra bits inside the quotation marks.
[07:03] <robertzaccour> the i915.powersave=0 i added myself, wanted to make sure i did i right before i save it and have a kernel panic
[07:03] <robertzaccour> persia, what do i add?
[07:04] <RAOF_> GRUB_CMDLINE_LINUX_DEFAULT="quiet splash" i915.powersave=0 should be GRUB_CMDLINE_LINUX_DEFAULT="quiet splash i915.powersave=0"
[07:04] <RAOF_> Note the position of the double-quotes.
[07:06] <robertzaccour> ok thanks. what about the line below that one?
[07:06] <robertzaccour> line 9
[07:06] <RAOF_> That is line 9
[07:07] <robertzaccour> oh yeah one line is blank. what about line 10?
[07:08] <robertzaccour> should i just erase line 10?
[07:08] <persia> Just leave the rest of the file as it was before you edited.  you just have to change the one line.
[07:08] <robertzaccour> i'm gonna pastebin what i got now brb
[07:09] <robertzaccour> http://pastebin.com/Qz6LnbGa
[07:09] <robertzaccour> thats what it looks like now. is that right for saving?
[07:11] <persia> No.
[07:11] <robertzaccour> persia, what do i need to do now?
[07:12] <robertzaccour> the first part of line 9 is there twice. is that what i need to delete?
[07:12] <persia> delete everything on line 9 up to the second 'G' character.
[07:12] <RAOF_> As in: line 9 should be exactly:
[07:12] <RAOF_> GRUB_CMDLINE_LINUX_DEFAULT="quiet splash i915.powersave=0"
[07:12] <persia> and see the /topic : this used to be on-topic, but I fear we're drifint :)
[07:14] <robertzaccour> persia, RAOF_ http://pastebin.com/U2YeMbUf
[07:15] <robertzaccour> i really appreciate yall helping me
[07:17] <robertzaccour> are yall still awake?
[07:18] <robertzaccour> i need to save this correctly, gettin up real early in the morning all i need to know is if i got it right please help me
[07:20] <robertzaccour> are yall still awake? please help me
[07:20] <robertzaccour> anyone else??
[07:21] <robertzaccour> yall please help me i gotta get up in a few hours
[07:21] <robertzaccour> please please help is there anyone else here?
[07:21] <robertzaccour> :( maybe Linux isn't for me
[07:22] <RAOF_> You've replaced that with the original.
[07:22] <RAOF_> You'll probably get better support in #ubuntu+1
[07:22] <robertzaccour> RAOF_, i replaced what with the original?
[07:25] <robertzaccour> ok thanks yall
[07:25] <robertzaccour> here's what it says now http://pastebin.com/cRdCHdxb
[07:26] <RAOF_> That looks good.
[07:29] <robertzaccour> RAOF_, thanks. what do i save as? grub?
[07:29] <robertzaccour> oh everytime something is successfully fixed in ubuntu i email it to myself. i have a bit list of ubuntu emails i emailed myself lol
[07:34] <pitti> Good morning
[07:37] <robertzaccour> good mornin
[07:38] <dholbach> good morning
[07:39] <RAOF_> Good morning :)
[07:40] <robertzaccour> the Ubuntu community is wonderful
[07:40] <robertzaccour> wouldn't trade it for any distro in the world :)
[07:46] <dholbach> hey RAOF_
[07:46] <dholbach> hey seb128
[07:46] <seb128> hey dholbach
[07:46] <seb128> how are you?
[07:47] <RAOF_> Morning seb128
[07:47] <dholbach> seb128: getting better :)
[07:47] <dholbach> thanks
[07:49] <robertzaccour> ok time to restart with the bug fix :)
[07:49] <seb128> hey RAOF_
[07:49] <seb128> dholbach, good!
[07:50] <robertzaccour> man if i didn't bring up the bug i'm not sure if anyone else would have before the release. there was only one other person affected by it on launchpad
[07:50]  * dholbach hugs seb128
[07:50] <robertzaccour> it was accomplished with other people's knowledge and not my own, however i still fill like i contributed by telling the right people about the bug
[07:50]  * seb128  hugs  dholbach
[07:51] <robertzaccour> i'm goin to sleep for a few hours, yall have a great day thanks and God bless
[07:58] <dholbach> zul: does bug 557110 need to get reopened?
[09:04] <tseliot> slangasek: still around?
[09:13] <Damascene> hello, any one care https://bugs.launchpad.net/vte/+bug/263822 ?
[09:15] <wgrant> mvo: Hi.
[09:21] <joaopinto> Damascene, I am not sure you get much attention on a non critical bug wich requires a complex resolution at this time :P
[09:22] <Damascene> not so complex
[09:22] <Damascene> only add mlterm when installing rtl support
[09:22] <Damascene> is it too complex?
[09:25] <joaopinto> Damascene, first it needs to be decided whether that's the proper fix :)
[09:26] <joaopinto> and I believe mlterm would also need to be moved to main
[09:26] <Damascene> I don't know what to do. I've sent to ubuntu-desktop ubuntu-devel talked in the channel of both
[09:26] <Damascene> who can really help? Mark?
[09:27] <joaopinto> Damascene, I don't think Mark is doing bug fixing lately :P
[09:27] <Damascene> :)
[09:27] <lifeless> Damascene: mark could make it critical priority if you convince him its critical. So can any other bug triager though.
[09:28] <lifeless> Damascene: are you claiming that its a critical bug ?
[09:28] <Damascene> will not critical but a bug that could be fixed by using mlterm which is ready to fix it
[09:29] <Damascene> it will not fix vte or gnome-terminal but it will give you a working terminal for rtl
[09:29] <lifeless> so joaopinto says that its not clear that that is the fix.
[09:29] <lifeless> Damascene: have you proposed a merge making the change you think will fix it ?
[09:29] <cjwatson> I don't think it's appropriate to pull in a completely different terminal emulation program, personally
[09:30] <cjwatson> certainly not at this point in the cycle, we don't have time to discover new bugs when it's installed by default
[09:30] <joaopinto> Damascene, to be honest what you are requesting should be recored on a different bug report, one thing is the lack of RTL on VTE, another thing is the lack of an usable terminal for RTL languages (by default)
[09:31] <Damascene> :S
[09:31] <Damascene> I
[09:31] <Damascene> I'm not asking to replace vte. just installing mlterm with rtl support
[09:31] <Damascene> not for every ubuntu user
[09:31] <Damascene> joaopinto, are you sure I should open another bug?
[09:32] <slangasek> tseliot: hi
[09:32] <tseliot> slangasek: hey, are you ok with what I wrote in my last email?
[09:32] <tseliot> (on escaping the percent sign)
[09:33] <joaopinto> Damascene, I think you should, the proper fix for VTE would be to have the RTL support, that take ages or never be fixed, on the other hand if you have a specific bug to include mlterm with a good ration it may be considered and fixed on Lucid+1
[09:33] <mvo> hi wgrant
[09:33] <slangasek> heh, mlterm certainly has plenty of its own bugs
[09:33] <slangasek> tseliot: uhm, you shouldn't have to escape the percent sign
[09:33] <slangasek> tseliot: if you're having to escape the percent sign, you're passing it in the wrong place :)
[09:34] <joaopinto> erm, I am eating letters
[09:34] <Damascene> joaopinto, I've spent much time heating that bug :)
[09:34] <joaopinto> Damascene, If I were using a language with a default broken terminal I would also be ;)
[09:35] <Damascene> should I use ubuntu-bug?
[09:35] <wgrant> mvo: Why was it chosen to use the /changelogs/pool hierarchy rather than something like SOURCE_VERSION.changelog in the normal pool?
[09:35] <slangasek> tseliot: ply_boot_client_update_daemon() takes a static string; unless you need to do percent substitution in *both* mountall and the theme, you shouldn't have to escape anything
[09:35] <wgrant> (I'm looking at the Soyuz implementation of this.)
[09:35] <Damascene> and what do you suggest as title please
[09:37] <joaopinto> Damascene, "Selecting an RTL language should install and RTL capable terminal emulator"
[09:38] <joaopinto> the package is language-selector
[09:38] <Damascene> thanks
[09:39] <tseliot> slangasek: but I have to create the string first, right? I think nih_sprintf will complain if I don't escape %
[09:39] <tseliot> as printf would do
[09:39] <slangasek> tseliot: why do you need nih_sprintf() to create the string?
[09:40] <mvo> wgrant, no specific reason, it could as well be this. it was simply modeled after the current way of storing them
[09:40] <slangasek> tseliot: if you mean composing the "fsck:%s:%d", only the first argument will have %s interpreted
[09:40] <slangasek> tseliot: a subsequent argument that contains %s is just treated as a literal string
[09:41] <wgrant> mvo: It seems a little awkward to have two pools if they're in the same place.
[09:41] <wgrant> (and it's more than a little awkward for Soyuz)
[09:41] <mvo> wgrant, that is true
[09:42] <tseliot> slangasek: something like nih_sprintf (NULL, _("Checking disk %1$d of %2$d (%d %% complete)"), progress));
[09:42] <mvo> wgrant, if joaopinto (he was doing the patch) does not mind we can easily change it at this point
[09:42] <persia> What are the mirroring implications of the change?  My memory is that the changelogs collection is fairly large.
[09:42] <wgrant> mvo: So he has the only server-side implementation at the moment?
[09:42] <mvo> wgrant, AFAIK
[09:43] <tseliot> slangasek: but I guess I can solve it with string concatenation
[09:43] <joaopinto> mvo, it's ok for me, that will allow also to use the mirrors for changelogs
[09:43] <persia> And my understanding of the default mirroring is that it would pull anything in /pool/
[09:43] <mvo> wgrant, I would suggest to put the changelog alongside each binary package (or symlink from source changelog)
[09:43] <slangasek> tseliot: right, that wouldn't work so well.  But this would: nih_sprintf (NULL, _("fsck:%s:%d", _("Checking disk %1$d of %2$d (%3$d %% complete)"), progress));
[09:43] <joaopinto> mvo, but aren't other files on /changelogs/.. I noted some *copyright on some random packages ?
[09:44] <mvo> wgrant, this make it more robust in the client implementation if e.g. no deb-src line is avaialble
[09:44] <wgrant> persia: I've no plans to use this for the primary archive yet. u-m is already specially hardcoded for the primary archive.
[09:44] <slangasek> tseliot: ... except with right syntax
[09:44] <mvo> joaopinto, yes, but those are not fetched currently, they are just there for information
[09:44] <slangasek> (i.e., no stray '_(" in front of the format string...)
[09:44] <wgrant> mvo: Right, we should be able to easily do the symlink dance in Soyuz.
[09:45] <mvo> wgrant, ok, cool. give me some minutes to update the code, I have another u-m bugfix pending anyway
[09:45] <joaopinto> symlinks from each binary package to the source changelog ?
[09:46] <wgrant> mvo: I guess this will even fix the differing source/binary version issue.
[09:46] <mvo> wgrant, exactly
[09:46] <mvo> wgrant, on changelogs.ubuntu.com there is a crawler that does fixup (via symlinks) like this as well
[09:47] <persia> wgrant: Cool.  Just wanted to make sure :)
[09:48] <wgrant> (conveniently enough, we have raw changelogs available in Soyuz as of a couple of weeks ago)
[09:48] <tseliot> slangasek: ok, I see what you mean now. Thanks
[09:50] <Damascene> joaopinto, https://bugs.launchpad.net/ubuntu/+source/language-selector/+bug/562130
[09:50] <Damascene> please adjust the description as you want
[09:51] <wgrant> joaopinto: How easy would it be for you to adapt to this change?
[09:51] <mvo> wgrant, joaopinto: to properly fix the src-version != binary-version (a good example is gcc-defaults with gcc-defaults != gcc) we would have to add a .changelog alonside earch foo_$arch.deb that reads "foo_$arch.changelog" (via symlink or file)
[09:51] <cjwatson> that's a lot of extra files in the mirror :-/
[09:51] <cjwatson> (may be unavoidable)
[09:51] <mvo> cjwatson, yeah, but we will not do it on the default archive
[09:52] <wgrant> cjwatson: Right, this probably won't work for the primary archive.
[09:52] <mvo> cjwatson, at least now :) only third-parties
[09:52] <cjwatson> oh, this is for PPAs?
[09:52] <mvo> cjwatson, yes, PPAs plus archives like getdeb
[09:52] <cjwatson> fair enough!
[09:52] <joaopinto> mvo, ok
[09:52] <wgrant> mvo: That was exactly the binary I was thinking of...
[09:53] <wgrant> So, yes, I guess we just need a foo_1.0.changelog, and foo_1.0_i386.changelog etc. symlinks.
[09:53] <mvo> wgrant, yes
[09:53] <mvo> foo-src_1.0.changelog
[09:54] <mvo> foo_2.0_i386.changelog
[09:54] <wgrant> Right.
[09:54] <joaopinto> hum, I will need to move the changelog extraction to the build process, or just assume it was built for every arch
[09:54] <mvo> wgrant, so that does mean we have a good change to get it for PPAs relatively soon :) ?
[09:54] <wgrant> That's pretty easy to do on my end.
[09:55] <wgrant> Much easier than the separate pool.
[09:55] <wgrant> And it will be more reliable too.
[09:55]  * mvo nods
[09:55] <persia> wgrant: Did the importer job run already, so that it's time for the UI exposure?
[09:55] <persia> (re: changelogs)
[09:55] <wgrant> persia: The importer doesn't exist yet.
[09:55] <persia> Aha!  I thought that was still missing :)  I'll poke some more to see if it gets created.
[09:55] <wgrant> I'm not sure how NCommander's going with that, or whether someone else needs to pick it up.
[09:56] <mvo> joaopinto, you could just opportunisticly assume its build for each arch (or test if foo_$arch.deb exists). I hope it does not cause too much trouble, but I think its a better schema in the longer run
[09:59] <joaopinto> mvo, I will create the links, on my case is only i386/amd64, will work just fine
[10:00] <mvo> joaopinto, cool
[10:00] <wgrant> joaopinto: OOI, which archive software does GetDeb use?
[10:01] <joaopinto> wgrant, custom build system, bzr branch lp:debfactory
[10:01] <joaopinto> it was prior to PPAs implementation :P
[10:02] <wgrant> Ah, right, I remember that vaguely.
[10:02] <joaopinto> and there are other technical reasons to not use PPAs, more flexibility to plugin our own features, license issues, mirror size, etc etc
[10:03] <wgrant> Yep.
[10:06] <directhex> bugger, apt in hardy doesn't support http 301 redirects - only in jaunty+.
[10:27] <mvo> wgrant, the code in u-m is updated now, would you mind updating the bugreport against soyuz so that it reflects the new schema too? I will upload the new u-m today
[10:29] <wgrant> mvo: Will do. Thanks for being so swiftly adaptable!
[10:29] <didrocks> cjwatson: do you have a minute to discuss about the long standing bug #221112? (it's even worse now that ubuntu one music store is available)
[10:32] <wgrant> mvo: So it's now binary_version_arch.changelog, in the same directory as the binary itself?
[10:32]  * wgrant checks the branch.
[10:33] <mvo> wgrant, yes
[10:33] <cjwatson> didrocks: well, we switched to the oss variant at the specific request (indeed, quite loud demand IIRC) of the French community
[10:34] <cjwatson> what does the option people are talking about correspond to in XKB-speak?
[10:34] <Damascene> joaopinto, I've opened a bug as you said. what should I do now please?
[10:34] <didrocks> cjwatson: right, I think we can fix/workaround the oss variant. The bug was introduced by fixing bug #198759. after debugging a little bit, in the oss variant, Ctrl + space and space return the same XLookupString
[10:35] <didrocks> I guess gtk_action_group_add_toggle_actions use a lookup to set up accelerator
[10:35] <joaopinto> Damascene, the best place to get help with bugs is #ubuntu-bugs ;)
[10:35] <wgrant> mvo: Heh, that code's a bit simpler now.
[10:35] <didrocks> one fix is to use in /usr/share/X11/xkb/symbols/fr include "nbsp(level4n)" instead of include "nbsp(level4nl)" in the oss variant
[10:36] <mvo> wgrant, yes, its a nice change :)
[10:36] <mvo> wgrant, if the diff has more "-" than "+" while keeping or extending functionality I'm happy
[10:37] <didrocks> we lost the "without forcing the use of level5 for mostly four-level layouts". Upstream responded a little bit to that: https://bugs.freedesktop.org/show_bug.cgi?id=15804 stating that no option there will fit everyone
[10:37] <joaopinto> Damascene, and keep in mind that your bug is very unlikely to be fixed at this  time, IMHO it's not a critical bug
[10:38] <Damascene> joaopinto, if someone can't use apt-get it is non critical?
[10:38] <Damascene> all apt-get messages are not readable
[10:38] <joaopinto> Damascene, there is an easy work around
[10:39] <Damascene> but there is a workaround. 1. don't use your language 2. use LC_ALL=C apt-get
[10:39] <joaopinto> and software center works just fine
[10:39] <cjwatson> didrocks: so we definitely shouldn't force the use of level-5 modifiers for fr(oss), but beyond that it's been years since I touched this stuff
[10:39] <didrocks> cjwatson: I have no real clue about the pros and the cons of those 2 layout (the level4nl definition is in /usr/share/X11/xkb/symbols/nbsp) as I don't have this background. But the fact that with level4n, we don't loose unbreakable space in for instance OOo as they use Ctrl + Shift + space) and that people can enter a space character in rhythmbox then seems better
[10:39] <joaopinto> Damascene, the work around is to manually install mlterm and use it
[10:39] <joaopinto> any way, this is something you need to discuss with bug triagers, I am not one ;)
[10:39] <awilkins> Is this the right place to mention that Eclipse seems to have been right proper broken by the last update?
[10:40] <cjwatson> isn't level4n the one that hijacks right-ctrl again?
[10:40] <didrocks> do you have good pointers as the docs seems sparse in that area and I don't think I have enough background, even reading the 5 related bug reported (upstream and in different distros) to take that decision?
[10:40] <Damascene> may I ask in which team you are? joaopinto
[10:40] <cjwatson> I don't any more, like I say it's been years
[10:40] <didrocks> cjwatson: from what I understand no, the change in the first bug report (the initial change in 2008) was another setup
[10:41] <joaopinto> Damascene, and like it was already mentioned, introducing mlterm could bring a new bunch of other unknown/untested issues
[10:41] <cjwatson> I think if you can simultaneously fix the rhythmbox bug and avoid regressing that right-ctrl bug, you should go ahead
[10:41] <cjwatson> it shouldn't need any installer changes - it's just in xkeyboard-config
[10:41] <Damascene> right, but even kernels have this
[10:41] <joaopinto> Damascene, kernels have a team handling them, mlterm does not
[10:42] <Damascene> who said that?
[10:42] <didrocks> right, I saw that. but I don't want to make a bad change there, hence the fact I asked this to you as you should have better knowledge than I :)
[10:42] <seb128> didrocks, if you need details on those keyboard changes talk to svu
[10:42] <Damascene> mlterm 3.0.0 released a days ago
[10:42] <seb128> he does IRC on irc.gnome.org and is nice to questions usually
[10:42] <seb128> didrocks, try on #control-center
[10:42] <didrocks> enforcing the level5 was in including "level5(rctrl_switch)"
[10:43] <didrocks> seb128: thanks, doing it now. Just wanted all available inputs first :)
[10:43] <cjwatson> didrocks: you want a time machine plus me a couple of years ago, unfortunately, I think :)
[10:43] <didrocks> cjwatson: so hard to find nowdays ;)
[10:43] <cjwatson> it took me about a day to cram all this stuff into my head and I think it's fallen out again
[10:43] <joaopinto> Damascene,  I am dropping the debate, I can't help you and I don't want you to be more frustrated than you already are :P
[10:44] <Damascene> oh, thanks
[11:15] <apachelogger> mvo: ping.. is there a way to do-release-upgrade without having 3rd party repos disabled?
[11:29] <apachelogger> mvo: nvm, already found it :)
[11:30] <sebner> apachelogger: 3rd party repos are evil :P
[11:31] <ajmitch> sebner: not when the 3rd party repository is your local mirror of packages
[11:31] <sebner> ajmitch: local mirrors are evil :P
[11:32] <ajmitch> says you who wasn't trying to grab lucid packages at ~8k/sec earlier today :P
[11:33] <sebner> ajmitch: /me grabs with ~600kb/s anytime. Well except the first few days after a stable release
[11:33] <apachelogger> 600 Oo
[11:33] <apachelogger> who can you work like that?
[11:33] <ajmitch> yeah, this is because I was trying to fetch from archive.ubuntu.com
[11:33] <ajmitch> it's not always fast fetching from there to NZ
[11:33]  * apachelogger gets already majorly annoyed with 2000
[11:34] <sebner> apachelogger: 600kb/s = 6Mbit, you have 20 Mbit?
[11:34] <apachelogger> sebner: at times we get there ^^
[11:34] <apachelogger> average is around 1200 though
[11:34] <sebner> apachelogger: pffffff, at home (carinthia) I have 16Mbit
[11:34] <ajmitch> I'd probably get up to about that from a NZ mirror
[11:35] <apachelogger> sebner: like a friend who apparently has 16, in fact I never saw it go beyond 200 ;)
[11:35] <apachelogger> err
[11:35] <apachelogger> 2
[11:36] <sebner> apachelogger: not true, Carinthia is different *hahahahaha*
[11:36] <apachelogger> no argument there :P
[11:37] <sebner> apachelogger: we get ~1450 maximum, average is between 1200 -1400
[11:38] <ev> is it just my machine, or are dbgsym packages broken?
[11:39] <seb128> ev: how broken?
[11:40] <ev> seb128: http://paste.ubuntu.com/413583/
[11:40] <seb128> ev: seems about right?
[11:40] <seb128> "Reading symbols from /usr/bin/cheese...Reading symbols from /usr/lib/debug/usr/bin/cheese...done."
[11:40] <ev> right, but no source code listing
[11:41] <seb128> we don't embed source code in the dbg or dbgsym the way rpm distro are doing
[11:41] <seb128> you need to apt-get source cheese
[11:41] <ev> oh?  Weird, I thought we did.
[11:41] <seb128> cd in the source
[11:41] <seb128> and run gdb there
[11:41] <seb128> no we don't ;-)
[11:41] <ev> fair enough, thanks!
[11:41] <seb128> you're welcome
[11:42] <baptistemm> StevenK, could you approve me as member on ~bluetooth? I'd like a to give a hand there
[11:43] <lamont> mvo: bug 559194 also needs a fix in update-manager, thanks
[11:46] <mvo> lamont: could you elaborate a bit please? the update-notifier change is uploaded
[11:50] <nosse1> Do you know of a good guide of how to create a company internal apt-source repo? (With tools to rebuild Packages, etc.)
[11:50] <Riddell> persia, bryceh: xserver-xorg-video-displaylink seems to ignore the source code in the .orig.tar.gz and add it through the .diff.gz , why is that?
[11:51] <Riddell> W: xserver-xorg-video-displaylink source: patch-system-but-direct-changes-in-diff COPYING and 10 more
[11:51] <persia> Um, if it does that, I made a mistake.
[11:51] <persia> I'll go fix that now.
[11:51] <Riddell> persia: ok I'll reject for now
[11:51] <jpds> nosse1: https://wiki.ubuntu.com/Mirrors
[11:51] <jibel> mvo: hey, I ported the "3rd party changelog" fix to synaptic.
[11:51] <jibel> mvo: I'm wondering how the change of this morning to u-m will work with 3rd party repos other than ppa like e.g medibuntu.
[11:51] <persia> Reject it?  From where?
[11:51] <jpds> nosse1: #ubuntu-mirrors is a better place to ask.
[11:52] <mvo> jibel: woah, thanks!
[11:52] <jibel> mvo: they use the format base_uri+"/changelogs/pool/%s/%s/%s/%s_%s/%s"
[11:52] <jibel> mvo: Do they need to change the way they provide the changelog or must we try different format depending on the repo ?
[11:52] <jibel> mvo: joaopinto's fix was working well with this format.
[11:52] <mvo> jibel: they already have this? I was not aware of that. easiest is probably to ask them if they can provide symlinks
[11:53] <jibel> mvo: e.g http://packages.medibuntu.org/changelogs/pool/non-free/g/googleearth/current.lucid/changelog
[11:53] <nosse1> jpds, well thanks. But I'm not looking for a mirror. I'm looking for a description of how to build repo of custom, non-official packages
[11:53] <mvo> jibel: joaopinto from getdebs is fine with the change, I hope they will be too. maybe they can even share the code
[11:53] <lamont> mvo: update-manager-common delivers /etc/update-motd.d/91-release-upgrade as a symlink, rather than a file (which makes it not a conffile, and therefore it keeps coming back).  Same bug, different package doing the delivery
[11:53] <mvo> jibel: lets ask them first if they can adept before adding compat code
[11:53] <jibel> mvo, ok, I'll ask them. thanks.
[11:54] <mvo> jibel: great, thanks
[11:54] <persia> Oh, yeah.  That's a mess :)
[11:54]  * persia fixes
[11:55] <mvo> jibel: just for reference, the reason to do it like this was to avoid problems with src-version != binary-version (like gcc-defaults)
[11:55] <mvo> lamont: thanks
[11:56] <jibel> mvo, yes, I've read the irc log.
[11:56] <persia> bryceh: Remind me: what benefit do we get from not using the tiny debian/rules again?
[11:56] <jpds> nosse1: Oh, sorry then.
[12:19] <jibel> mvo, can you join us on #medibuntu to talk about the changelog
[12:50] <directhex> slangasek, as requested (well, noticed - we just forgot), banshee-coverwallpaper just yanked from sid
[13:06] <Laney> did i forget to do that one :(
[13:13] <bdrung> how can i test an apport hook?
[13:17] <Riddell> doko_: do you have any comment on bug 492139 ?
[13:17] <persia> bdrung: kill -1 the program?
[13:17] <persia> bdrung: Or kill -11 if you want a specific sort of kill (that would be segfault)
[13:17] <bdrung> persia: can i see what apports wants to send?
[13:18] <persia> Yep.  Just choose "View the Report", and (optionally) don't actually submit to LP.
[13:18] <persia> Works for CLI and GUI variants.
[13:21] <james_w> you should be able to write a test case that calls the hook with a dummy report and checks the output
[13:21] <Riddell> doko_: how about bug 523910 ?
[13:24] <doko_> Riddell: there was a glassfish package before, packaged by sun, but I can't find it now, neither in universe, nor multiverse. ahh, I see, filed the removal request myself ... in 449905. yes, I think that is ok
[13:27] <doko_> Riddell: about 523910: it's fixing the PIL bug, yeah, have to be more verbose for the FFe
[13:31] <Riddell> doko_: ok I'll remove the blacklist for glassfish and sync that
[13:35] <Riddell> doko_: what's to be done with bug 535386 ?
[13:42] <doko_> Riddell: could you sync the four remaining packages?
[13:43] <Riddell> doko_: the outdated ones on http://people.canonical.com/~doko/ubuntu-diff/status/ada.html ?
[13:43] <doko_> Riddell: yes
[13:43] <doko_> just updated this page
[13:43] <doko_> and then closing the report
[14:08] <Ryan1> Is there any chance bug #554432 will be fixed before Lucid is released?
[14:09] <dmart> Does anyone know how to encrypt the whole rootfs when installing using ubiquity?
[14:10] <ogra> i think thats only possible with d-i
[14:10] <ogra> unless that changed
[14:10] <cjwatson> correct
[14:12] <dmart> ogra, can I chat to you later about that?
[14:12] <ogra> dmart, i havent done any encrypted root installs in my life but indeed you can :)
[14:12] <dmart> cjwatson: have you done this?
[14:13] <cjwatson> I just port that stuff over from Debian and make sure it doesn't break too badly :-)
[14:13] <dmart> ok, I'll chat to ogra later and see if we get anywhere.  Thanks
[14:14] <cjwatson> there should be an "encrypted LVM" choice in d-i's autopartitioner, though
[14:14] <cjwatson> which with any luck should just DTRT on arm too
[14:18] <persia> Riddell: xsever-xorg-video-displaylink back in NEW for your reviewing pleasure: should be *much* cleaner now.
[14:22] <Riddell> Daviey: what's the status of bug 555111 ?
[14:25] <tseliot> Riddell: is kubuntu-default-settings maintained in a bzr branch? I might have to upload a fix for the bootsplash (bug #553954)
[14:25] <Riddell> tseliot: yes lp:~kubuntu-members/kubuntu-default-settings/ubuntu
[14:25] <Riddell> persia: nothing there yet
[14:26]  * persia goes to hunt
[14:26] <tseliot> Riddell: ok, so what shall I do when my fix is ready? Upload and make a bzr merge request?
[14:26] <Riddell> tseliot: yes please
[14:27] <tseliot> Riddell: ok, thanks
[14:36] <persia> Riddell: Really there this time, including round-trip download test
[14:40] <Riddell> persia: accepted
[14:40] <persia> Riddell: Thanks.
[14:40] <joaopinto> where can I find the reason for the libuser1 removal ?
[14:40]  * persia files the corresponding removal bug
[14:41] <joaopinto> shouldn't the reverse depends be also removed ?
[14:42] <james_w> joaopinto: I don't see it removed
[14:42] <joaopinto> it's no longer available on the lucid repository
[14:42] <joaopinto> usermode which depends on it was not
[14:43] <james_w> ah, probably unbuildable binaries spec
[14:44] <joaopinto> hum, there was a mail about checking such packages right ?
[14:44] <james_w> yes
[14:44] <joaopinto> if I can fix it at this time would it still be included on the archive ?
[14:45] <james_w> http://people.ubuntuwire.org/~lucas/ubuntu-nbs/32/libuser_1:0.56.9.dfsg.1-1ubuntu2_llucid32.buildlog
[14:45] <james_w> yes
[14:46] <NCommander> ccheney: ping?
[14:47] <james_w> joaopinto: the problem is that the upstream build system installs in to site-packages, and then the packaging tries to copy from dist-packages
[14:48] <joaopinto> james_w, ok, i will atempt to fix it, thanks
[15:18] <cjwatson> apw: you had a machine that exhibited ridiculous slowness with dpkg when installing linux-headers, I recall, before we worked around it in dpkg.  Would you be up for trying a different workaround for me?  I'd like to sync to upstream if possible
[15:18] <apw> cjwatson, don't think it was me
[15:18] <apw> i do remember it though
[15:19] <cjwatson> hm, at this point I don't want to upload it without advance testing
[15:19] <apw> cjwatson, though any machine should show it, it being the size of the kernel headers which are the issue
[15:19] <apw> so if you want me to try it i think reinstalling a kernel headers package should trigger it
[15:19] <apw> and if it does not with your dpkg would that do for testing?
[15:20] <cjwatson> that ought to do, I just don't have a system with ext4 right here
[15:20]  * apw cirtaonly has those
[15:21] <deryck> pitti, I'm starting work on bug 556499 which is for launchpad bugs team from the last UDS...
[15:21] <apw> cjwatson, i have a 32 and a 64 bit i could test that on
[15:21] <nemo> Say, this may be incredibly obvious, but I was wondering as I watched downloads scroll by (slowly)
[15:21] <nemo> Does Ubuntu use / has considered  binary diffs?
[15:22] <nemo> From last updated version of the package, if the user has it cached?
[15:22] <nemo> Or perhaps partial updates.
[15:22] <deryck> pitti, as I understand this, the idea is to have an aleart on the page after a user files a bug letting them know what they can expect, i.e. you should be able to reproduce this, etc.  sound right?
[15:22] <jpds> nemo: Yes.
[15:22] <nemo> jpds: yes to use or considered?
[15:22] <nemo> :)
[15:23] <jpds> nemo: https://wiki.ubuntu.com/AptSyncInKarmicSpec
[15:23] <pitti> deryck: so, some things that come to my mind which we should point out, are: providing a good description and reproducer; most bugs aren't looked at quickly, and they might stay around for some time; checking for duplicates yourself helps a lot (although at this time it's a bit late, and we have a dupe detector now)
[15:24] <joaopinto> james_w, the proper fix would be regenerate the autoconf* stuff, would a small patch directly on configure be prefered ?
[15:24] <pitti> deryck: and of course that everyone, including the reporter, is encouraged to help with debugging and fixing
[15:25] <deryck> pitti, right.  seems good.  I'm wondering, too, about making this generic.  Would it be ok to add a field to a project/distro in lp akin to the bug reporting guidelines, and then you guys could put whatever text you like to show up there after someone files a bug?
[15:25] <pitti> rickspencer3: ^ you might have some thoughts about it as well?
[15:25] <james_w> joaopinto: really? why does that fix it?
[15:26] <pitti> deryck: that's a good idea indeed, so that we can adapt it over time without needing to change LP itself again
[15:26] <deryck> pitti, ok, that makes sense to me too.  In a perfect world, we would prompt better according to the state of the bug, but as a first step, this seems useful, IMHO.
[15:27] <pitti> deryck: perfect world> "Success probability: 0.3%" :)
[15:27] <deryck> heh, exactly. :-)
[15:28] <pitti> deryck: it would be useful to warn about bugs wit low gravity
[15:28] <joaopinto> james_w, hum, I had the idea that the sites-packages dir was defined on the configure script
[15:28] <pitti> i. e. short description, no attachments, no apport data, etc.
[15:29] <deryck> pitti, right, and if we do that, that's a good bit more involved then a simple message alert.
[15:29] <nemo> jpds: cool.
[15:29] <pitti> deryck: oh, another thing comes to my mind: there are certainly a lot of packages with no package bug contact; could we do the text based on that?
[15:29] <deryck> pitti, yes, that would be reasonable.
[15:30] <pitti> deryck: I'm not sure whether it'd be easier to do with macros and just one complex notice, or different notices for the two cases
[15:31] <deryck> pitti, so as a first cut, a base message that is configurable per project but if it's Ubuntu with no package specified, an additional message appears?
[15:31] <pitti> deryck: "no package" is another interesting (and rather hopeless) case indeed
[15:32] <pitti> deryck: I actually meant "no package bug contact", but both are indeed different cases
[15:32] <deryck> pitti, oh, sorry I misread the scrollback, sorry.  right
[15:32] <deryck> pitti, I think we could handle both cases there.
[15:32] <ccheney> NCommander: I was wanting to find out the status of the arm patch
[15:33] <NCommander> ccheney: we're going to force building for ARM mode. (-marm)
[15:33] <james_w> joaopinto: if you can confirm that a patch to configure.ac and configure will fix it then that's great
[15:33] <joaopinto> actually the path comes from aclocal.m4
[15:34] <ccheney> NCommander: that needs a patch for the part of the build you need to force it on, right?
[15:34] <NCommander> ccheney: no, we're going to force the entire build, just not some bits
[15:34] <deryck> pitti, I'm worried that a dynamic solution based on gravity or heat is a bit much for a first cut.  Does the variable message option mentioned above sound useful?
[15:35] <pitti> deryck: yes, definitively; we can include all those cases in text form, too
[15:35] <pitti> deryck: like "if this has no package, you lose"
[15:35] <ccheney> NCommander: oh ok, do i need a patch of some sort to do that in OOo, or is it going to be forced at the buildd level?
[15:35] <NCommander> ccheney: got a debdiff coming for you
[15:35] <ccheney> NCommander: ok thanks
[15:36] <deryck> pitti, ok, great.  I'm curious like you if others agree, but if so, I can start work on this.
[15:37] <NCommander> ccheney: http://paste.ubuntu.com/413678/ - how's that look? (I'm doing a partial test build to make sure -marm sticks, but other then that ...)
[15:37] <pitti> deryck: there certainly will be some debate about the particular text still :)
[15:38] <deryck> pitti, of course. :-)
[15:40] <ccheney> NCommander: looks simple enough :)
[15:51] <pwk> hi I have two build boxes freshly installed from 9.10. when they compile my c++ project using g++-4.1 the x86 build box adds symbols that require GLIBCXX_3.4.11 (and GLIBCXX_3.4.9). The amd64 build box does no such thing and just requires any GLIBCXX_3.4...I am unclear why this is, but would appreciate any insight...since I distribute the binary I need to get rid of those dependencies on x865
[15:52] <pwk> here are the symbols that x86 build box adds that are the problem: http://pastebin.org/149195
[15:53] <pwk> I compile using g++-4.1 to make sure my application runs on as many systems as possible, and yet it punishes me with that 3.4.11 dependency which was introduced in 9.10
[16:00] <Riddell> cjwatson: for bug 557220 where is the image file?
[16:04] <NCommander> ccheney: do you want me to upload it directly when ready?
[16:07] <ccheney> NCommander: no i have lots of patches already in queue
[16:07] <ccheney> NCommander: i added your patch from the pastebin to my set
[16:07] <NCommander> ccheney: alright
[16:07] <NCommander> ccheney: I'll make sure I can test build it
[16:07] <ccheney> ok
[16:08] <ccheney> i'll be ready to upload as soon as i finish copying over a bunch of updated copyright strings :-\
[16:16] <joaopinto> does anyone know the equivalent to  sysconfig.get_python_lib(0,0) to get the dist-packages path ?
[16:18] <james_w> python -c "from distutils import sysconfig; print sysconfig.get_python_lib()"
[16:18] <james_w> /usr/lib/python2.6/dist-packages
[16:18] <james_w> joaopinto: ^
[16:19] <joaopinto> hum
[16:19] <joaopinto> sorry, it returns the proper value, I am going crazy :P
[16:25] <mathiaz> slangasek: hi - what's your opinion on creating the openldap user with a home directory set to /nonexistent instead of /var/lib/ldap?
[16:39] <ScottK> joaopinto: libuser1, IIRC, had it's binaries removed because it didn't build.  It just needs the FTBFS fixed and uploaded to get back in.
[16:40] <joaopinto> ScottK, I am working on it, thanks
[16:40] <ScottK> joaopinto: OK.
[16:42] <joaopinto> I had to remove the prefix parameter on the get_python_lib, I believe there is a bug with get_python_lib() but this is not the best time to file a bug for distutils :P
[16:42] <james_w> pitti: when do you normally disable apport? Can you please ping me when you do so?
[16:42] <pitti> james_w: usually right after the RC release, but seb128 asked me to do it a bit earlier this time; probably for RC
[16:42] <pitti> james_w: yes, I can do that; for disabling kerneloops?
[16:42] <james_w> exactly, thanks
[16:43] <james_w> or feel free to do it yourself if you find uploads easier than IRC pings ;-)
[16:53] <tseliot> slangasek: I fixed #553954. Shall I proceed with the upload and update some bzr branch?
[17:23] <bdrung> sistpoty|work: i don't understand point 1 of your comment in bug #494604.
[17:24] <sistpoty|work> bdrung: in the patch you add dependencies against audacious-dev, right?
[17:24] <kwwii> Keybuk: hey, did you get the images I sent for the low-colour boot?
[17:25] <sistpoty|work> bdrung: audacious-dev should have any dependencies that are needed to develop using the shipped headers
[17:25] <Keybuk> kwwii: I've been travelling over the weekend
[17:25] <kwwii> Keybuk: ok, just wanted to make sure the email made it to your inbox :-)
[17:26] <Keybuk> I've no idea yet ;)
[17:26] <kwwii> :P
[17:26] <kwwii> lucky you
[17:26] <kwwii> I'll bug you tomorrow then
[17:26] <Keybuk> that might not scale
[17:26] <bdrung> sistpoty|work: aha, ok. this needs to be fixed in debian
[17:27] <Keybuk> slangasek: so I think I've figured out with Plymouth SEGVs inside ply_process_pending_events() all the time
[17:27] <sistpoty|work> bdrung: wait a second, let me take a look again, maybe I'm confused with what patch I looked at
[17:27] <bdrung> sistpoty|work: audacious-dev depends on (nearly) everything from B-D
[17:28] <sistpoty|work> bdrung: ah, now I'm back on track, yes
[17:31] <sistpoty|work> bdrung: actually audacious-dev as seen in experimental seems to be more or less sane (e.g. there's an include that requires libmowgli-dev), at least after taking a short look
[17:32] <sistpoty|work> bdrung: actually I did confuse your audacious-plugins patch with one for audacious (there are depends added there as well), let me take another look
[17:38] <sistpoty|work> bdrung: I think the same logic should apply for the -plugins-dev
[17:39] <sistpoty|work> bdrung: however it's not too much of a problem, so if you want, feel free to leave it as is
[17:39] <sistpoty|work> bdrung: just saw another thing: how is the upgrade path handled if you've got plugins-extra installed?
[17:39] <bdrung> sistpoty|work: the question is: do we really need a -plugins-dev package
[17:39] <bdrung> ?
[17:40] <bdrung> plugins-extra will be removed
[17:41] <sistpoty|work> bdrung: aha, audacious-plugins-dev is a meta package, so *shrug*, not too sure if it's needed or not
[17:41] <bdrung> it does the same as "sudo apt-get build-dep audacious-plugins"
[17:42] <sistpoty|work> yeah, might make sense to just drop it then...
[17:43] <ion> keybuk: A random thought: implementing the last-good-boot stuff not in boot time, but by running something like update-last-good-boot in the preinst of all packages that change relevant files, and having update-last-good-boot exit if /var/run/updated-last-good-boot exists, create a new updated-last-good-boot snapshot and create the /var/run stamp so that subsequent updates during the current OS runtime don’t change the last-good-boot (since the one we’re ...
[17:43] <ion> ... about to unpack changes the files not to match with what we’re running).
[17:44] <ion> s/new updated-/new /
[17:45] <sistpoty|work> bdrung: anyway, as I tried to express, the dependencies of the -dev package aren't really too much of a problem, feel free to leave them as is for this upload (I doubt anyone will complain about dependency bloat of -dev packages)
[17:45] <ion> keybuk: If the system manages to get into a state that’s running a preinst of a package, the boot is *probably* “good”.
[17:45] <bdrung> sistpoty|work: i will fix it in debian. then it gets fixed by the next sync/merge
[17:45] <sistpoty|work> bdrung: excellent, thanks!
[17:46] <Keybuk> ion: that's how I keep telling people to implement it ;-)
[17:46] <Keybuk> at least, roughly
[17:49] <ogra> Keybuk, wasnt the "mountall goes into an endless loop if the clock is wrong" bug supposed to be fixed ?
[17:49] <ogra> i thought we should end up in a maintanace shell now
[17:50] <Keybuk> ogra: yes, it's fixed
[17:50] <Keybuk> no, you end up with a plymouth prompt
[17:50] <Keybuk> "fsck failed, what you want to do?"
[17:50] <ogra> hmm, and if you dont have plymouth ?
[17:50] <lamont> why doesn't my SD card show up anymore?
[17:50] <ogra> i know that amitk saw the issue today on a beagleboard
[17:51] <Keybuk> ogra: mountall Depends: plymouth
[17:51] <ogra> and he definately didnt get any prompt
[17:51] <ogra> ah, good
[17:51] <ogra> he went into an endless loop
[17:51] <ogra> the bad thing is that we support the beagle now but it doesnt have a battery at all to keep the clock
[17:52] <Keybuk> it sounds like he was using an old version
[17:53] <ogra> well, whatever was in the archive today
[17:54]  * ogra would really love to just drop the pass 1 from /dev/root in /lib/init/fstab by default ... but i suspect several people would attempt to kill me then :)
[18:03] <tseliot> Keybuk: I've fixed bug #553954 by modifying mountall, plymouth and other themes. How shall I proceed with the upload (e.g. bzr branches, etc.) for these 2 packages?
[18:04] <Keybuk> I'd like to review your patches first
[18:04] <Keybuk> could you e-mail me the URLs to the relevant commits
[18:04] <Keybuk> this is something that has a large breakage potential right before release
[18:04] <Keybuk> so I think "additional eyes" review is worthwhile
[18:04] <tseliot> Keybuk: absolutely, I'll send you an email
[18:05] <sabdfl> rickspencer3: please can i ask for a late sync of the schroedinger package?
[18:05] <sabdfl> to get 1.0.9
[18:05] <sabdfl> i don't think there are any critical deps, but it's worth chacking in case that's a bad req
[18:05] <rickspencer3> sabdfl, in team meeting atm
[18:05] <rickspencer3> will ping back soon
[18:05] <sabdfl> danke
[18:07] <seb128> sabdfl, I was pondering syncing it while I did some GNOME sync before meeting but there was no bug open about it, any bug fixed or new feature we want in the update?
[18:10] <tseliot> Keybuk: ok, email sent. Let me know if/when I can upload.
[18:10] <tseliot> slangasek will get an email too
[18:10] <Keybuk> tseliot: will review today
[18:10] <tseliot> thanks
[18:13] <deryck> ttx, ping
[18:14] <Keybuk> bug #558865 is clearly a DFSG violation (restriction of endeavour)
[18:25] <mathiaz> Keybuk: what's your plan for bug 552786?
[18:26] <Keybuk> mathiaz: I don't have a specific plan
[18:26] <Keybuk> I agree it's a bug, and that it should have proper exit codes
[18:26] <Keybuk> but I have REAL BUGS to fix between now and release
[18:26] <Keybuk> so I'm very unlikely to do it
[18:26] <Keybuk> I will more than happily review patches though and provide all necessary advice
[18:26] <maco> as opposed to....heisenbugs?
[18:27] <Keybuk> mathiaz: the "open question" is, what are the exit codes when the job is starting and stopping? :)
[18:27] <Keybuk> ie. if the job is start/pre-start ... it's not running, so should not exit 0
[18:27] <Keybuk> but it's not "not running", so should not exit 1
[18:27] <Keybuk> and stop/running is obviously running right now, but very soon won't be, so should not exit 0 probably
[18:28] <Keybuk> I guess 0 := goal = start & state = running
[18:28] <Keybuk> anything else can be 1
[18:28] <Keybuk> (the states change for 1.0 anyway, so too much thought at this point is only going to be thrown away soon enough)
[18:29] <mathiaz> Keybuk: right - I agree that returns 0 only if the process is running is enough
[18:40] <james_w> kenvandine: which package for a music store bug?
[18:42] <kenvandine> james_w, most likely libubuntuone
[18:42] <kenvandine> or rhythmbox-ubuntuone-music-store
[18:42] <kenvandine> but most of the functionality is in libubuntuone
[18:42] <james_w> hmm, it's via banshee
[18:42] <kenvandine> ok
[18:42] <james_w> I'll test in rhythmbox
[18:42] <kenvandine> libubuntuone
[18:42] <kenvandine> :)
[18:44] <james_w> yep, libubuntuone, thanks
[18:45] <kenvandine> james_w, np
[18:54] <seb128> sabdfl, new schroedinger synced
[19:16] <sabdfl> thanks seb128
[19:43] <zyga> mvo: hi
[19:43] <zyga> mvo: did you manage to merge the other software-center branch?
[20:37] <slangasek> mathiaz: /nonexistent> I think that's pretty ugly :)
[21:18] <ccheney> NCommander: about to upload the new OOo with your change, did it seem to work so far?
[21:18] <NCommander> ccheney: I didn't get a chance to try it
[21:18]  * NCommander is not having the best day
[21:20] <NCommander> ccheney: I just kicked a build, if you can wait 45 minuts for patch+configure, I can tell you to if it works
[21:24] <ccheney> NCommander: ok
[21:24] <ccheney> NCommander: ping me when you verify it works and i will upload it
[21:24]  * ccheney is going to do a ooo-l10n test build before uploading
[21:24] <NCommander> ccheney: thanks. The patch looks correct to you, right?
[21:25] <ccheney> NCommander: it looks sane to me, whether it will actually work i don't know :)
[21:26] <NCommander> ccheney: well, building to the point of failure takes two hours
[21:26] <zul> slangasek: i updated the autofs5 upstart script fyi
[21:28] <ccheney> NCommander: oh thats not bad, if you are going to be around long enough to see if it passe that point then just ping me then
[21:28] <ccheney> NCommander: i'm always around on irc :)
[21:28] <NCommander> ccheney: yeah, I'll be around. Its just waiting for OOo to configure takes eternity
[21:32] <NCommander> ccheney: 'CFLAGS=-g -O2' 'LDFLAGS=-Wl,-Bsymbolic-functions' 'CPPFLAGS='
[21:32] <NCommander> didn't work
[21:32] <NCommander> ugh
[21:33]  * YokoZar waits for his package to be built...Launchpad first says build starts in 15 minutes.  Then 1 hour.  Then 30 minutes.  Now 5 hours.
[21:35] <NCommander> ccheney: oh, I put ifneq versus ifeq (note to self: don't patch OOo at 8am in the morning)
[21:37] <ccheney> NCommander: should be ifeq?
[21:37] <NCommander> ccheney: if arch == armel, then pass -marm
[21:38] <NCommander> the code as written is arch != armel :-)
[21:38] <seb128> bug #554478
[21:38] <seb128> does somebody known about this issue?
[21:38] <ccheney> NCommander: ah heh
[21:39] <NCommander> seb128: ENOG5 :-/
[21:39] <seb128> (just asking because I've a GNOME upstream who is running into the issue)
[21:39] <seb128> oh, Keybuk!
[21:39] <seb128> Keybuk, you wouldn't have a clue of what issue could create bug #554478 or what info would be useful there?
[21:40] <seb128> Keybuk, just trying to be nice to an GNOME upstream who is using ubuntu ;-)
[21:40] <seb128> Keybuk, workarounds hints are welcome if you have some too
[21:41] <Keybuk> if it's suspected to be a mountall bug, add --debug and capture that output
[21:41] <chrisccoulson> is svu the only gnome upstream using ubuntu? ;)
[21:41] <Keybuk> though by the looks of it, it's not a mountall bug
[21:41] <Keybuk> it looks like it's passed that
[21:41] <seb128> chrisccoulson, no, but still he's nice with us ;-)
[21:41] <seb128> Keybuk, any idea what could be to blame rather?
[21:42] <Keybuk> no, none
[21:42] <chrisccoulson> seb128 - he is, but i think i scare him away ;)
[21:42] <sabdfl> pgraner: who's a good person to chat with regarding a USB issue?
[21:42] <Keybuk> oh, wait, "it reports failed mount"
[21:42] <Keybuk> no idea on that
[21:43] <Keybuk> The /dev/mapper/control file is the only file in /dev/mapper. Nothing else in that dir.
[21:43] <Keybuk> seb128: ^ sounds like an LVM issue
[21:43] <ccheney> NCommander: ifneq is right changing that causes it to be used on not arm
[21:43] <ccheney> NCommander: and causes build to fail on amd64
[21:44] <NCommander> ccheney: oops :-)
[21:44] <NCommander> ccheney: I think I also need to set ARCH_CXXFLAGS
[21:44] <seb128> hey svu
[21:45] <seb128> Keybuk, thanks, I copied what you said to svu
[21:45] <svu> seb128: hey
[21:45] <Keybuk> I also copied it to the bug ;)
[21:45] <svu> Keybuk: I was told it would be useful to capture --debug, right?
[21:45] <seb128> svu, do you know what you upgraded just before getting the bug?
[21:45] <Keybuk> svu: yes, that's always useful
[21:45] <svu> Keybuk: is there anything I could check in dmesg?
[21:45] <Keybuk> dmesg is unlikely to be helpful
[21:45] <ccheney> NCommander: ok, well let me know once you get a working patch :)
[21:46] <Keybuk> it looks, to me, like you're missing LVM device nodes
[21:46] <svu> seb128: I think I upgraded both kernel and mountall - but not 100% sure
[21:46] <Keybuk> you should have /dev/vg/lv -> /dev/mapper/vg--lv device nodes
[21:46] <seb128> svu, did you try to boot previous kernel from grub?
[21:46] <Keybuk> if there's nothing else in /dev/mapper other than control, that bit is likely to be broken
[21:46] <svu> Keybuk: I will check /dev/vg
[21:46]  * NCommander wishes he knew why SPARC didn't boot at all anymore past the kernel
[21:46] <Keybuk> (where "vg" and "lv" are your volume group and LV names)
[21:46] <seb128> svu, you have the upgrade in /var/log/dpkg.log too
[21:46] <svu> seb128: it is power g5. there is no grub. there is yaboot. And If only I remember how to boot the prev kernel...
[21:47] <seb128> svu, oh right...
[21:47] <svu> Keybuk:  I see. The real vg and lv names...
[21:48] <svu> (and my Power G5 gives me only couple of minutes. The fans turn ON and make horrible NOISE, then it turns itself off automatically! :)
[21:48] <svu> and no boot from USB AFAIK
[21:48] <svu> what a platform :)
[21:48] <NCommander> svu: LinuxOLD at the yaboot prompt
[21:48] <NCommander> svu: and it should support USB boot if you hold option down and theres a proper yaboot partition on the USB drive
[21:49] <svu> NCommander: ghm. I should check about LinuxOLD. Not sure it is still there - I might have removed it:)
[21:49] <NCommander> svu: heh. yaboot is pathetically limited compared to grub, or silo on SPARC
[21:49] <svu> NCommander: I was told in Web, they ignore USB. Well, there are some tricks with OpenFirmware...
[21:49] <NCommander> but thats because openfirmware sucks
[21:50] <NCommander> (openfirmware on mac anyway)
[21:50] <NCommander> svu: worse case, you have to drop into the OF propmpt, and insert some voodoo into nvramrc to get it to USB boot
[21:50] <svu> Anyway, I am leaving for a moment, going to try  (If am not back, count me as communist:)
[21:50] <svu> NCommander: yes, as I heard
[21:51] <NCommander> svu: you can have a lot of fun in OF, but you've got to also like pain
[21:51] <slangasek> zul: right, seen
[21:52] <slangasek> Riddell: bug #523910> so there hadn't been an FFe granted yet, were you implicitly granting one with your sync?
[21:52] <NCommander> ccheney: when do arch flags get passed into the OOo build, I don't see it on the ooo-build command line
[21:59] <ccheney> NCommander: hmm not sure will take a look and see if i see where its done
[22:00] <mathiaz> Keybuk: what do you think about http://bazaar.launchpad.net/~mathiaz/ubuntu/lucid/upstart/workaround-status-exit-code/revision/1273
[22:00] <mathiaz> Keybuk: as a workaround the lack of proper exit code for initctl status command?
[22:01] <ccheney> NCommander: around line 2147, i have a different version of rules than you though
[22:01] <NCommander> ccheney: ugh, hrm
[22:01] <ccheney> NCommander: two different places next to each other:
[22:01] <ccheney> cd $(OOO_BUILD_TREE) ; PATH=$(BUILD_PATH) LD_LIBRARY_PATH=$(BUILD_LD_LIBRARY_PATH) DEFAULT_TO_ENGLISH_FOR_PACKING=1 ARCH_FLAGS=$(ARCH_FLAGS) TMP=/tmp $(MAKE)
[22:01] <ccheney> with verbose on and off
[22:01] <NCommander> ccheney: ugh, let me go to bzr packaging. I really don't think either one of us wants OOo uploaded twice :-)
[22:01] <Keybuk> mathiaz: I think that's exactly the kind of work-around that I don't want to do
[22:01] <Keybuk> not this late in a release cycle
[22:01] <Keybuk> it's also wrong ;)
[22:01] <ccheney> NCommander: yea
[22:01] <NCommander> ccheney: (or at least, wait until this build gets to the actual configure/build --all stage)
[22:02] <ccheney> NCommander: i haven't committed my most recent changes to bzr yet
[22:02]  * Keybuk introduces mathiaz to the concept of translations
[22:02] <Keybuk> (plus it silences all command output from a user POV)
[22:03] <slangasek> Keybuk: so what did you figure out with the plymouth segvs?
[22:03] <mathiaz> Keybuk: wouldn't LANG=C handle the translation issues?
[22:04] <slangasek> Keybuk: and is it related to the deadlock identified in bug #554737?
[22:04] <Keybuk> mathiaz: no, because then upstart-job would output everything in english
[22:04] <Keybuk> slangasek: I don't know what that bug is
[22:04] <Riddell> slangasek: yes, from talking to doko earlier today
[22:04] <Keybuk> I have reached the point where, even if I sat here right now
[22:04] <slangasek> Riddell: ok :)
[22:04] <Keybuk> and for the next two weeks just read bugs and replied to them
[22:05] <Keybuk> I would have more unread mails in my LP folder than when I started
[22:06] <Keybuk> slangasek: would you like me to read that bug, or would you like me to talk to you about the process_pending_events() bug?
[22:06] <slangasek> Keybuk: both
[22:07] <Keybuk> ok, I shall read that bug first
[22:08] <mathiaz> slangasek: what's your take on bug 562261?
[22:08] <slangasek> they're both high-priority, targeted bugs, and as I say I have suspicions they may even be related
[22:08] <mathiaz> slangasek: it seems that the ABI break wouldn't effect any package in the archive
[22:08] <Keybuk> slangasek: I don't see how they can be related so far
[22:09] <slangasek> Keybuk: fair enough
[22:09] <Keybuk> according to the back trace I've just read, plymouthd in bug #554737 is blocked in write()
[22:10] <slangasek> mathiaz: does the Debian plan include any binary package name changes?
[22:10] <Keybuk> hmm
[22:10] <Keybuk> bug #554737 is strange
[22:10] <Keybuk> plymouthd is blocked in write()
[22:10] <Keybuk> plymouth quit is blocked in epoll_wait()
[22:10] <mathiaz> slangasek: I don't think so
[22:10] <Keybuk> this should not be possible
[22:11] <Keybuk> and mountall is blocked in write() too
[22:11] <mathiaz> slangasek: I haven't review the extend of the ABI break
[22:11] <slangasek> Keybuk: mountall is also running; the deadlock is between plymouthd and mountall, 'plymouth quit' is just waiting its turn
[22:11] <mathiaz> slangasek: sam has been answering promptly to my requests
[22:11] <Keybuk> slangasek: are you sure?
[22:12] <slangasek> Keybuk: as sure as I can be without having had a chance yet to reproduce it locally
[22:12] <Keybuk> at a guess
[22:12] <Keybuk> ply_boot_client_flush() is flushing all pending writes
[22:12] <Keybuk> but not reading the replies
[22:12] <Keybuk> plymouthd is blocking on sending a reply before read()ing again?
[22:12] <ccheney> NCommander: so you needed more than just -marm?
[22:12] <slangasek> Keybuk: yes, that's what I think is happening
[22:13] <NCommander> ccheney: not sure, maybe I'm loosing it, its going to start build --all in a moment and I'll look at the GCC line to see if I'm loosing it
[22:13] <slangasek> mathiaz: no package name changes in unstable; what verification did you do that the ABI change doesn't hurt us?
[22:13] <Keybuk> slangasek: makes sense
[22:13] <Keybuk> I agree with your diagnosis then
[22:13] <ccheney> NCommander: ok
[22:13] <slangasek> Keybuk: ok - and that's unrelated to the other bug?
[22:14] <mathiaz> slangasek: talking and trusting the debian maintainer
[22:14] <mathiaz> slangasek: I haven't had time to get into deeper investigations
[22:14] <Keybuk> slangasek: completely unrelated
[22:15] <slangasek> Keybuk: ok - what's the story on bug #553745, then?
[22:15] <Keybuk> slangasek: just fixing status of this
[22:15] <Keybuk> slangasek: do you want a go at fixing, or do you need me to?
[22:15] <slangasek> I have time to follow through today
[22:16] <Keybuk> my hunch for a fix; I have that function just calling the write() side of plymouthy stuff
[22:16] <Keybuk> it probably instead should do the full thing
[22:16] <svu> Keybuk: I attached my mountall results
[22:16] <Keybuk> maybe even call ply_boot_client_process_pending_events() in a loop until there are no more pending requests
[22:16]  * slangasek nods
[22:16] <Keybuk> svu: remind me of the bug number
[22:17] <Keybuk> slangasek: so SEGV bug
[22:17] <Keybuk> do you know much about epoll?
[22:18] <svu> Keybuk: https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/554478
[22:18] <slangasek> Keybuk: a medium amount
[22:18] <Keybuk> slangasek: so cliff's notes
[22:18] <Keybuk> unlike poll, the kernel keeps track of the stack of fds you want to watch
[22:19] <Keybuk> when you add an fd to the epoll, you pass in "data"
[22:19] <Keybuk> when you call epoll_wait(), you get an array of all the "data" that matched
[22:19] <Keybuk> in plymouth's case, the "data" is a pointer to a ply_source structure
[22:19] <Keybuk> that points at the handlers and stuff to call
[22:19] <Keybuk> so
[22:19] <Keybuk> big array of pointers to ply_source (handlers)
[22:19] <Keybuk> iterate the array, calling the handlers
[22:19] <Keybuk> what if the handler frees watches? :p
[22:20]  * slangasek nods
[22:20] <Keybuk> what if those watches actually polled true this loop - and are later in the array?
[22:20] <Keybuk> I talked to Ray this morning about it, and he has proposed http://cgit.freedesktop.org/plymouth/commit/?id=5daa29168df38b8b5f0f59b0c65a5740082e002a
[22:20] <Keybuk> I think it'd be a good idea to update to 0.8.2 (lots of bug fixes) and add that patch
[22:20] <Keybuk> and get some testing
[22:21] <NCommander> ccheney: didn't work, can't even tell if ARCH_FLAGS got passed in
[22:21] <ccheney> NCommander: hmm weird
[22:21] <ccheney> maybe i should commit my changes to bzr and then you can try them out
[22:21] <svu> Keybuk: does my output give any hints?
[22:21] <NCommander> ccheney: yeah
[22:23] <Keybuk> plymouth_connect: Failed to connect to Plymouth: Connection refused
[22:23] <ccheney> NCommander: ok it should be there now
[22:23] <Keybuk> svu: ^ that's a little odd
[22:23] <ccheney> NCommander: its 6ubuntu1 unreleased tag
[22:23] <ccheney> NCommander: commit 1286
[22:23] <Keybuk> svu: but yes, clearly no LVM devices here - do you have /var/log/udev from that machine ?
[22:24] <svu> Keybuk: nope. my /var is in different partition, so, no /var/log here. I can create it - will it populate all necessary files?
[22:25] <slangasek> Keybuk: 0.8.2> none of the bugfixes jumped out at me as urgent; I agree that testing would be the most effective way to validate those changes, but am concerned about the timeline.  You don't think cherry picking the one reference-counting commit is appropriate?
[22:25] <Keybuk> slangasek: well, in terms of fixing that bug, sure
[22:25] <Keybuk> but a lot of the other fixes looked really key to me
[22:25] <Keybuk> like fixing all the keyboard problems ;)
[22:25] <NCommander> ccheney: grabbing
[22:26] <Keybuk> svu: check /dev/.udev.log
[22:26] <Keybuk> or something
[22:26] <Keybuk> it usually hides there until /var is mounted
[22:26] <slangasek> Keybuk: ok - nothing in the upstream changelog tickled my memory on known major bugs we have right now, but I'll defer to you on this
[22:26] <svu> Keybuk: ok. I will try. Thanks
[22:27] <Keybuk> slangasek: oh, I just looked at the git commits and they all looked quite sane
[22:27] <slangasek> Keybuk: right - go for it
[22:28] <slangasek> Keybuk: do you also have some time for bug #539655?
[22:28] <Keybuk> slangasek: I've been running "bzr merge-upstream" for the past 6 hours
[22:28] <Keybuk> it's still running
[22:28] <slangasek> (to talk with me about it)
[22:28] <slangasek> heh
[22:28] <Keybuk> slangasek: I can talk to you about it anytime
[22:28] <Keybuk> here's the dump of stuff I know about it:
[22:28] <Keybuk> --
[22:28] <slangasek> heh
[22:28] <Keybuk> :-)
[22:28] <Keybuk> smb knows a bit more
 we still haven't tracked down the mysterious source of the ioctl()s that smb is adamant that Plymouth is making
[22:29] <Keybuk> something to do with "the number of cpu gets that plymouth does is not the same as the number of puts"
[22:29] <Keybuk> right
[22:29] <james_w> Keybuk: the command is hung?
[22:29] <Keybuk> so smb looked from a kernel POV
[22:29] <Keybuk> and plymouth is apparently resulting in more gets than puts
[22:29] <Keybuk> so "holds the card" at the point X tries to start
[22:29] <Keybuk> this could be:
[22:29] <Keybuk> - a nouveau bug (plymouth is correct, nouveau is wrong)
[22:29] <Keybuk> - a libdrm bug
[22:29] <Keybuk> - a plymouth nouveau renderer bug
[22:29] <slangasek> what does the userspace side of that ioctl look like?
[22:29] <Keybuk> - a plymouth drm renderer bug
[22:30] <Keybuk> or none of the above
[22:30] <Keybuk> but I still don't have OOTB working nouveau hardware
[22:30] <Keybuk> so I've been able to do zero testing
[22:30] <slangasek> right; I do
[22:30] <Keybuk> slangasek: userspace side looks like libdrm function calls
[22:30] <slangasek> I meant low-level - what are the ioctls in question?  (trying to work my way up from the libdrm-nouveau1 source)
[22:30] <Keybuk> ie. src/plugins/renderers/drm/ply-renderer-nouveau-driver.c
[22:31] <Keybuk> oh
[22:31] <Keybuk> no idea there
[22:31] <Keybuk> that's beyond my knowledge
[22:31] <slangasek> ok, will circle around with smb when he's here
[22:31] <slangasek> oh, he's here, just not here; will follow up with him
[22:31] <NCommander> ccheney: build kicked
[22:31] <Keybuk> I understand from a black box POV what plymouth does
[22:32] <Keybuk> it creates a buffer onto which it can draw
[22:32] <Keybuk> and has that buffer mapped to the virtual console
[22:32] <Keybuk> (replacing fbcon)
[22:32] <Keybuk> but I don't really understand the calls it makes or anything like that
[22:32] <Keybuk> even from an intel pov
[22:32]  * slangasek nods
[22:33] <Keybuk> it could be a "deactivate" bug
[22:33] <Keybuk> ie. at the point after deactivate is called, the nouveau driver for the drm renderer has more references open than is acceptable for nouveau
[22:33] <Keybuk> intel needs a reference held otherwise fbcon reasserts
[22:33] <Keybuk> nouveau is probably written assuming the same
[22:34] <Keybuk> it may turn out that holding that reference is what prevents X from starting
[22:34] <Keybuk> it may even turn out that it's therefore impossible to do a smooth transition with nouveau
[22:34] <Keybuk> etc.
[22:34] <Keybuk> it may be a kernel bug
[22:34] <Keybuk> (that X can't start with that reference held)
[22:34] <slangasek> right
[22:34] <Keybuk> it's in that hideous area I fear to tred :p
[22:34] <slangasek> I'll work on understanding the drm code and try some live debugging; probably won't get to it today
[22:34] <Keybuk> I don't really "understand" this layer from a programming POV, just from a black box architecture POV
[22:35] <Keybuk> and I fear that if I start to learn it, I'll end up maintaining X or something
[22:35] <Keybuk> or Wayland <g>
[22:35] <ccheney> NCommander: ok, i'm running a build to test ooo-l10n also, let me know what you come up with and i will do the upload in a few hours (or whenever yours is done testing)
[22:35] <ccheney> NCommander: i think my ooo-l10n test will probably take a couple hours
[22:35] <NCommander> ccheney: I flipped the ifneq to a ifeq
[22:36] <ccheney> NCommander: if that works then the check itself must be flawed as when i had it the other way it was being used even for amd64
[22:36] <NCommander> ccheney: oh, I'm building on armel ;-)
[22:36] <NCommander> ccheney: its possible, I copied one of the other checks in the source and tweaked it
[22:36] <Keybuk> james_w: poor internet connection ;)
[22:36] <james_w> ah
[22:37] <ccheney> NCommander: ok, will look into it once you see if the -marm bit fixes it at least, only takes about 5-10m to fail on amd64 if its not set right on my box, heh
[22:37] <NCommander> ccheney: heh, it takes a good 30-45 minutes ;.;
[22:37] <ccheney> NCommander: so it should be easy enough to verify it doesn't break other things
[22:37] <ccheney> only takes me 30m for a full OOo build (not ooo-l10n) :)
[22:38] <ccheney> well as i have ccache primed
[22:39] <ccheney> a lot of that time is spent in the shlib stuff too i think
[22:39] <NCommander> ccheney: heh
[22:39] <ccheney> and then running lintian and compressing the lzma debs, etc :)
[22:40] <ccheney> the build itself seems to be fairly small part of the 30m
[22:40] <ccheney> i wish the lzma compression was threaded
[22:43] <lamont> persia: fpc is building on ppc now. armel gave http://paste.ubuntu.com/413787/
[22:45] <joaopinto> thinking on a rollback sysem for dpkg, would it be as trivial as backing up all the files contained on a package before the upgrade and restoring them for the rollback (applying this recursively to dependencies) ?
[22:45] <ajmitch> no, because maintainer scripts can do arbitrary things
[22:46] <joaopinto> right, I know I was missing something
[22:46] <joaopinto> so it would be FS snapshot based
[22:46] <joaopinto> need to be
[22:47] <micahg> joaopinto: etckeeper is good for helping with that
[22:48] <joaopinto> micahg, it doesn't help much to revert upgrades
[22:48] <svu> Keybuk: attached udev.log
[22:48] <svu> https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/554478
[22:50] <joaopinto> hum, files created/changed from maintainer scripts could be identified on system calls (checkinstall alike) and also be backed up
[22:50] <ccheney> NCommander: is our arch called armel or arm?
[22:51] <ccheney> NCommander: i see another reference to filtering for arm that had both in it
[22:51] <joaopinto> if those files were changed manually after the newest package install then user prompt would be required
[22:52] <joaopinto> I am I missing something :) ?
[22:53] <ccheney> NCommander: eg the code that sets the ICU flags for arm
[22:53] <NCommander> chrisccoulson: armel
[22:53] <NCommander> er
[22:53] <NCommander> ccheney:
[22:53] <chrisccoulson> ;)
[22:55] <ccheney> NCommander: well comparing the other uses of ifneq (,$(filter $(ARCH), foo))  the foo is what it applies to code to afaict
[22:55] <ccheney> NCommander: eg the openjdk-6-jre java runtime depends list, etc
[22:56] <Keybuk> svu: your log confirms that no dm-X devices are being created in the kernel
[22:57] <svu> Keybuk: lovely. So, is there workaround?
[22:57] <Keybuk> no idea
[22:57] <Keybuk> it's LVM
[22:57] <Keybuk> my jurisdiction stops at the state line between sane things and LVM ;-)
[22:59] <svu> :)
[22:59] <svu> so, should that bug be reassigned to LVM? who should I talk to?
[23:00] <Keybuk> I've reassigned the bug to LVM
[23:02] <svu> and who would be my next person to talk to, if you happen to know?
[23:03] <seb128> svu, the lvm2 source didn't change for 8 weeks, did you try to boot the previous kernel?
[23:07] <Keybuk> svu: no idea on that
[23:07] <svu> seb128: I did. same result
[23:07] <Keybuk> I don't think anyone is maintaining LVM right now
[23:08] <svu> seb128: my system broke ~2 weeks ago
[23:09] <seb128> svu, did you try to look in the dpkg.log what you updated just before getting the issue?
[23:09] <Keybuk> dpm-afk: bug #559997 probably warrants a UDS session?
[23:09] <svu> seb128: I just found. it was ~2 Apr
[23:10] <svu> seb128: nope. ghm, I'm afraid it is on one of those volumes I cannot access
[23:11] <seb128> svu, :-(
[23:11] <svu> well, I can access them, booting from CD. For 2 mins - till my fans turn the system off
[23:11] <svu> I can try that...
[23:11] <sladen> svu: if when you boot from CD (eg. older versions), does the mapper find them
[23:11] <svu> yes
[23:11] <svu> can I can mount them
[23:11] <svu> and I actually did apt-get upgrade on mountall
[23:12] <svu> and linux kernel
[23:12] <svu> but that did not help
[23:12] <sladen> so the 2 minutes is because ACPI/throttling/similar is not being loaded?
[23:12] <seb128> Keybuk, the packages using cdbs have their template updated by langpack.mk, we will do something similar for dh7, other packages in main not using those should update the template in their rules
[23:12] <sladen> svu: sudo apt-get update --reinstall mountall
[23:12] <svu> sladen: yes. perhaps. my Power G5 turns ALL fans on. Horrible noise. And after 2 mins the system turns off
[23:13] <svu> sladen: why not. will try that. But Keybuk  says it is not mountall, it is most probably lvm. but it is worth trying anyway...
[23:14] <sladen> svu: as in  http://www.macintouch.com/readerreports/powermacg5/index.html
[23:15] <sladen> svu: or are we talking another type of G5 ?
[23:16] <svu> sladen: well, http://www.everymac.com/systems/apple/powermac_g5/stats/powermac_g5_2.0_dp.html
[23:17] <svu> no, this one: http://www.everymac.com/systems/apple/powermac_g5/stats/powermac_g5_2.0_dp_2.html
[23:19] <Keybuk> seb128: right, it's the dh7 things I'm thinking of
[23:20] <Keybuk> if it's the case where everything needs to "make -C po update-po" somewhere, then it's the kind of thing that should be done automatically
[23:20] <Keybuk> sladen: the bug is clearly unrelated to mountall
[23:20] <Keybuk> the logs show no devices in /dev/mapper
[23:20] <seb128> Keybuk, we usually do it by calling intltool-update but right
[23:21] <Keybuk> seb128: an interesting question is where that should be done, of course
[23:21] <Keybuk> if the .pot is in the tarball (which it always is)
[23:21] <Keybuk> then you need to run it on "debian/rules clean"
[23:21] <Keybuk> since you need to commit the changes to bzr
[23:21] <Keybuk> but if you have a patch system, you *also* need to run it after the patches are applied
[23:21] <Keybuk> (or on build somewhere)
[23:22] <seb128> right not we run it after build (at least in the cdbs version)
[23:22] <Ng> if I had a lucid machine (packages a few days out of date) boot up and do a routine fsck, finish and mount / rw, but plymouth still think fsck was at 70% forever, what would I file that against? :)
[23:22] <seb128> which should always be right for launchpad import
[23:23] <Keybuk> Ng: you should read the list of duplicate bugs first
[23:23] <Keybuk> Ng: though, since you're here
[23:23] <Keybuk> Ng: can you run "ps" on that machine for me
[23:24] <Ng> unfortunately it's not still in that state, but perhaps I can provoke it - do we still support /forcefsck?
[23:25] <Keybuk> Ng: we do
[23:25] <seb128> Keybuk, what are you looking for in the ps in case I get the issue again there? (I got it yesterday on a box)
[23:25] <Keybuk> seb128: whether plymouthd is still running, whether plymouth commands are still running and whether mountall is still running
[23:26] <seb128> k, noted
[23:26] <Keybuk> if they are, it's a dup of bug #554737
[23:26] <Keybuk> if not, it isn't
[23:29] <Ng> aha, rebooted with forcefsck and it looks like it's done it again
[23:30] <Keybuk> Ng: "ps" output?
[23:31] <Ng> Keybuk: plymouthd is running, there's a "plymouth quit" running, mountall is running
[23:32] <Keybuk> Ng: sweet
[23:32] <Keybuk> Ng: then you have the same bug
[23:32] <Keybuk> kill the plymouth quit and mountall processes
[23:32] <Keybuk> tbh, killing mountall is probably enough
[23:32] <Ng> Keybuk: http://pastebin.com/cEfCkVkh fwiw
[23:33] <Keybuk> actually yes, only kill mountall
[23:33] <Ng> ta :)
[23:33] <cjwatson> seb128: the right way to do this with dh7 would be for something to provide a langpack addon, so you'd do dh --with langpack
[23:33] <cjwatson> that's basically equivalent to include langpack.mk
[23:34] <Keybuk> cjwatson: I can't figure out a way to do this in debian/rules sanely *at all*
[23:34] <cjwatson> seb128: /usr/share/doc/debhelper/PROGRAMMING.gz has docs on writing sequence addons, near the end
[23:34] <seb128> cjwatson, we don't want to patch every rules to list it though
[23:34] <cjwatson> mm, joeyh gets really upset when we patch debhelper to behave substantively differently from Debian; I assume the cdbs maintainer doesn't
[23:34] <seb128> cjwatson, with cdbs we make gnome.mk which is used in most desktop packages include langpack.mk
[23:35] <cjwatson> well, why not have a '--with gnome' then?
[23:35] <cjwatson> and have it provide whatever semantics you want in the desktop
[23:35] <seb128> because gnome packages still use cdbs in debian and ubuntu ;-)
[23:35] <seb128> but right if GNOME ever migrates to dh7
[23:35] <cjwatson> sure, but --with gnome is the equivalent of gnome.mk, that's all I'm saying
[23:35] <Keybuk> cjwatson: but this doesn't just affect gnome packages
[23:36] <seb128> I'm thinking we should maybe figure something out of the packaging system though
[23:36] <Keybuk> this affects every single package for which we patch the source
[23:36] <Keybuk> including those we wrote ourselves ;)
[23:36] <cjwatson> Keybuk: not that simple because po files live in different places
[23:36] <Keybuk> and that's regardless of the fact that there's no sane way to do this
[23:36] <cjwatson> and it only affects those for which we made string changes
[23:36] <cjwatson> and those for which the string changes actually matter
[23:36] <Keybuk> I can't figure out how to do it at all for mountall
[23:37] <seb128> cjwatson, lot of upstream tarballs don't ship a template too or some ship an outdated one
[23:37] <cjwatson> (e.g. grub2, really doesn't matter that much if the two new rarely-hit error strings get translated or not)
[23:37] <cjwatson> seb128: well, ok, but lots of them do it right as well
[23:37] <seb128> Keybuk, run intltool-update manually and commit the update?
[23:37] <cjwatson> I don't think the scale is actually all that bad
[23:37] <Keybuk> seb128: there's no intltool here
[23:37] <cjwatson> most of the packages where it matters, we're modifying them already
[23:37] <seb128> Keybuk, you don't use intltool?
[23:37] <Keybuk> no
[23:37] <cjwatson> seb128: most non-desktop packages don't use intltool for translations
[23:38] <seb128> oh ok
[23:38] <cjwatson> gettext has an update-po target, I thought
[23:38] <Keybuk> cjwatson: where do you run that? :p
[23:38] <cjwatson> hooked from make dist
[23:38] <Keybuk> the pot file is in the source tarball
[23:38] <cjwatson> you run gettextize and it sets it up for you ...
[23:38] <Keybuk> so running it in build/binary is pointless
[23:38] <Keybuk> and you can't run it in clean, because there's no po/Makefile
[23:38] <cjwatson> I don't really believe in this business of generating pot at build time, if the upstream is sane
[23:38] <seb128> Keybuk, run make update-po and commit the update as a source change?
[23:39] <cjwatson> if we're upstream, we should just ship a sane pot upstream
[23:39] <Keybuk> seb128: requires every uploader to remember to do that
[23:39] <Keybuk> cjwatson: how do you *generate* that
[23:39] <seb128> everybody doing a string change yes...
[23:39] <Keybuk> again, fundamental problem being missed
[23:39] <cjwatson> you just do it occasionally as a maintenance task, string changes are relatively infrequent
[23:39] <Keybuk> it requires every single person patching mountall to remember to run "make -C po update-po"
[23:39] <cjwatson> huh?  that doesn't make sense to me
[23:39] <Keybuk> (and have the entire mountall deps list installed - which is often impossible)
[23:39] <Keybuk> why not
[23:39] <cjwatson> because that's not how e.g. man-db works
[23:40] <Keybuk> how does man-db work?
[23:40] <cjwatson> people patching it upstream don't have to run that
[23:40] <Keybuk> mountall is native
[23:40] <cjwatson> because I check the damn generated files into bzr because I do not love pain
[23:40] <cjwatson> native/non shouldn't matter ...
[23:41] <Keybuk> so where do I put this in debian/rules ?
[23:41] <Keybuk> I don't know where/how
[23:41] <cjwatson> I leave it the hell out of debian/rules :-)
[23:41] <GrueMaster> who can reenable partimage builds for amd64?  It has been down since hardy (if I read bug 198724 correctly).  I rebuilt it for karmic on amd64 and it is working fine.  The bug report says someone has it working for lucid as well.
[23:41] <Keybuk> you clearly do
[23:42] <Keybuk> cjwatson: so where does it go?
[23:42] <cjwatson> I let automake/gettext take care of it, and ignore it
[23:42] <Keybuk> because right now, no fucker even remembers to bump the version properly ;-)
[23:42] <Keybuk> automake never runs gettext
[23:43] <cjwatson> I just occasionally run update-po when I can be bothered
[23:43] <cjwatson> po/Makefile takes care of spitting out reasonably correct po files
[23:44] <cjwatson> if I'm feeling disciplined, I run update-po after making string changes
[23:44] <Keybuk> yeah, I don't want to depend on someone remembering to run update-po
[23:44] <Keybuk> because that won't happen
[23:44] <cjwatson> it isn't necessary otherwise
[23:44] <Keybuk> I could add a debian/rules check I guess
[23:44] <Keybuk> so build fails if you've forgotten to run it
[23:44] <cjwatson> then you have your top-level makefile run it as part of all, and anyone who does a test build will have it run
[23:45] <Keybuk> but test builds are done in pbuilder
[23:45] <cjwatson> that works, it tends to create annoying changes in po/pot headers all the time which is why I don't
[23:45] <Keybuk> which means the updated pot file gets lost
[23:45] <cjwatson> it only needs one developer to do them outside pbuilder :)
[23:45] <Keybuk> this is my basic problem
[23:45] <Keybuk> yes
[23:45] <Keybuk> and I *don't*
[23:45] <primes2h> Keybuk: try asking dpm about it as well. He can probably suggest you something I think.
[23:45] <Keybuk> I can't find a way for my workflow to work
[23:46] <cjwatson> doing it in debian/rules clean seems not unreasonable given your use model
[23:46] <Keybuk> cjwatson: that would require running configure in debian/rules
[23:46] <cjwatson> it's part of preparing the source package for shipping
[23:46] <Keybuk> and again, I can't install mountall's dependencies on the machine I work on mountall on
[23:46] <Keybuk> so again
[23:46] <Keybuk> can't be done
[23:46] <Keybuk> configure will fail
[23:46] <Keybuk> clean will fail
[23:46] <Keybuk> etc.
[23:47] <cjwatson> it should be possible to do an update-po equivalent without having configured, really
[23:47] <Keybuk> yeah, but is isn't ;-(
[23:47] <cjwatson> it's just a bunch of xgettext calls
[23:47] <cjwatson> you could pull it out into a separate script if you wanted
[23:48] <cjwatson> in fact, some packages just have their own trivial implementation of it
[23:48] <cjwatson> see e.g. debconf/po/Makefile
[23:48] <cjwatson> obviously gettext's Makefile.in.in is optimised for being generic
[23:48] <svu> obviously, --reinstall did not help. neithe upgrade to the latest kernel
[23:49] <Keybuk> hmm, that's an idea
[23:49] <Keybuk> but pretty crappy
[23:49] <cjwatson> Keybuk: FWIW, mind you, all that the langpack stuff in Ubuntu requires is that the pot be up to date at the end of the build
[23:49] <Keybuk> cjwatson: ohhh, does it?
[23:49] <Keybuk> I thought it got it from the source tarball from what dpm-afk said
[23:50] <cjwatson> so while I can't be bothered with the pratting about involved in doing that (and the inevitable unclean build trees you tend to end up with if you do build/clean in bzr), it's workable
[23:50] <cjwatson> probably works better if you do out-of-tree builds
[23:50] <cjwatson> that's what seb128 was talking about with langpack.mk just doing it after build
[23:52] <cjwatson> seb128: if gnome ever migrates to dh7> http://people.debian.org/~cjwatson/dhstats.png, I know which trend I think is the interesting one ... ;-)
[23:52] <seb128> Keybuk, no, it get it from the build dir after build
[23:52] <Keybuk> ahh
[23:52] <seb128> cjwatson, right, should rather be "when" ;-)
[23:53] <cjwatson> heh
[23:57] <quidnunc> ifhp doesn't seem to show up in the repositories (e.g via apt-cache search) but it is not listed as removed here https://launchpad.net/ubuntu/+source/ifhp
[23:57] <quidnunc> What give?
[23:57] <quidnunc> What gives?
[23:57] <cjwatson> it's only built on sparc
[23:58] <quidnunc> It won't be available on x86?
[23:59] <cjwatson> dunno guv, I just work here.  bit of patience and I'll see if I can track down more detail