[00:00] <Presonus_Probs> nope! First time ever in Ubuntu and  xchat, though I used to use mIRC in high school.. can you poss recommend channels / servers to check on? Thx for your help
[00:00] <TheMuso`> Yeah #lad is the only other channel I can think of.
[00:01] <Presonus_Probs> will check it cheers :D Is there a reason noone uses firewire ie is it known to be a pain?
[00:05] <TheMuso`> I don't think its that so much as this is a general Ubuntu development channel, and firewire audio is generally in the domain of those who are doing audio production.
[00:05] <TheMuso`> Hense more specific to Ubuntu Tudio.
[00:16] <Presonus_Probs> Thanks for your time :)
[02:36] <malkauns> in 12.04 how do i change the color of the top horizontal panel?
[02:38] <mbutubuntu> malkauns, this is a development channel, for support question use #ubuntu
[03:33] <pitti> Good morning
[04:02] <infinity> pitti: Hey, I'm just heading out, but sru-report was your code, right?
[04:02] <pitti> infinity: right
[04:02] <infinity> pitti: Can you run it on lillypilly and decipher the backtrace and decide if it's IS's fault or something and whine at the right people (or fix it)? :P
[04:03] <infinity> pitti: It works locally, so I'm guessing firewall rules or some weird proxying or something, but I didn't have the urge to understand what was failing.
[04:03] <infinity> (See above about heading out)
[04:03] <pitti> infinity: I just deleted the launchpad cache dir, hoping that it will work again now
[04:03] <pitti> it spammed me over night with the cron mails
[04:03] <pitti> it seems deleting the LP cache works for a lot of similar problems
[04:03] <pitti> infinity: I'll keep an eye on it over the day
[04:04] <infinity> pitti: Oh, I didn't even think of a cache issue, since the trace sounded like an XMLRPC response issue, but if the cache just caches JSON objects, that would make sense.
[04:04] <infinity> pitti: Thanks.
[04:12] <pitti> infinity: it's at least running now for > 2 minutes
[04:14] <pitti> infinity: FYI, I'll remove all langpacks from precise-proposed; dpm said they were unplanned and there are no current testing resources for them
[04:21] <ScottK> infinity: In your copious free time, would you please accept libksane into precise-proposed when it appears in the queue.  I'd like to get it in and tested and released with the rest of KDE 4.8.5.
[04:22] <ScottK> Actually it should be there now.
[04:22] <ScottK> That's one I found over the weekend when I was upgrading my wife's computer.
[06:35] <lifeless> slangasek: hi
[06:35] <lifeless> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=330500
[06:36] <lifeless> I seem to be affected by this (and the fourth me-too on it reports it happening post-upload-that-should-fix-it)
[06:36] <lifeless> slangasek: wondering whether you want diagnostics a login, etc
[07:04] <dholbach> good morning
[07:12] <darkxst> is apport-retrace known to be broken on quantal?
[07:12] <darkxst> I always just get "ERROR: report file does not contain one of the required fields: CoreDump DistroRelease Package ExecutablePath"
[07:26] <pitti> darkxst: you need to let the UI collect information first
[07:26] <pitti> darkxst: or call apport-retrace with -R, if you are sure that packages didn't change since the crash
[07:33] <darkxst> pitti, ok, I see, thanks
[07:34] <darkxst> I have a huge stack of errors, hiding in the g-s message try, oops ;)
[08:26] <cjwatson> lifeless: I specifically don't want lpmadison (though I don't object if somebody else wants to create it).  I need madison-lite/rmadison's particular behaviour anyway for all kinds of reasons, and I want it to be fast.  So yes, I know this comes up, and I know why you're suggesting it, but it isn't IMO a sufficient solution to the problem at hand.
[08:26] <cjwatson> xnox: grub2/bios/lvm/luks> thanks
[08:26] <cjwatson> infinity: grub2/powerpc> yeah, I saw in mail, will look
[08:27] <cjwatson> SpamapS: I wonder if just consolidating the cache files would help; makes it more expensive to update but perhaps quicker to query.  But as you say maybe it should just be a vaguely proper DB.
[08:36] <lifeless> cjwatson: k
[09:00] <cjwatson> bdmurray: I've analysed bug 1047092 and reassigned to the proper place
[09:00] <cjwatson> ogasawara: ^- easy kernel fix, will help with the "no more alternate CD" project
[09:19] <zyga> pitti, ping
[09:22] <zyga> pitti, I'm working on the UDisks2 migration of checkbox, as you know, while testing the code I've noticed that the UDisks1 code has a few problems. In particular the 'dectect device removal' parts, current checkbox code monitors org.freedesktop.UDisks.DeviceRemoved (http://hal.freedesktop.org/docs/udisks/UDisks.html#UDisks::DeviceRemoved) yet watching dbus-monitor --system and trying various SD cards and thumb drives I can never see this signal being sent.
[09:22] <zyga> I only see DeviceChanged signals. Could you shed some light on this please?
[09:23] <zyga> pitti, to be precise, DeviceChanged gets sent for my SD card readers, DeviceRemoved gets sent, but for things like USB-HDDs
[09:23] <ogra_> USB SD card reader ?
[09:24] <ogra_> they often are providing a permament device and only emit a media changed signal
[09:24] <ogra_> (like a CD rom)
[09:25] <ogra_> i have only seen native SD readers that actually treat them as actual devices (vs USB media) (dev/mmcYXZ vs /dev/sdX)
[09:27] <xnox> zyga: does UDisks1 run on quantal?! I can't seem to run usb-creator at all anymore.... failure to communicate with dbus.... which is pain because I cannot test / compare with UDisks2 back-end
[09:28] <zyga> xnox, it's still installed as it's pulled by usb-creator
[09:29] <zyga> xnox, usb-creator may just get confused as it may expect additional signals that no longer get sent
[09:29] <zyga> xnox, (they get sent by udisks2 now)
[09:29] <zyga> ogra_, yes USB
[09:29] <zyga> ogra_, yeah, it seems to be the case
[09:29] <zyga> ogra_, thanks
[09:29] <xnox> zyga: hmm... well usb-creator-gtk fails to launch =(
[09:29] <ogra_> :)
[09:29] <zyga> xnox, are you rewriting it to udisks2?
[09:30]  * ogra_ just ported usb-imagewriter to udisks and had the same issues :)
[09:30] <ogra_> thogh i jumped from hal to udisks2 directly ... less pain :)
[09:30] <zyga> heh :)
[09:30] <zyga> usb-imagewriter? what is that?
[09:30] <xnox> zyga: yeah... but I want to test it against both. Cause usb-creator has concepts of backends & I am adding UDisks2 backend to the UDisks1, well i did a few days ago.
[09:30] <zyga> some low level friend of usb-creator-gtK?
[09:30] <ogra_> a GUI frontend to dd
[09:30] <zyga> ogra_, oh, cool!
[09:31] <xnox> usb-imagewriter is usb-creators evil twin
[09:31] <zyga> ogra_, doesn't gnome disks have that? (palimpset?)
[09:31] <xnox> zyga: s/palimpset/gnome-disks/
[09:31] <ogra_> it happened to me a few times that i accidentially used of=/dev/sda1 in dd
[09:31] <xnox> =))))) lolz
[09:31] <ogra_> which isnt so cool if thats your rootfs device
[09:31] <ogra_> so i wrote usb-imagewriter that only shows removable devices
[09:32] <zyga> ogra_, cool thing
[09:32] <ogra_> to prevent me from such errors
[09:32] <xnox> ogra_: do you have a trap for that now?!
[09:32] <xnox> =)
[09:32] <zyga> ogra_, push that to linaro please
[09:32] <ogra_> its in universe :)
[09:32] <ogra_> (not the final version with udisks yet but it will land before release since i want to refer to it on the arm install pages)
[09:34] <alexbligh1> Naive library question: I have a library (libfreerdp1) which I am trying to update (for a PPA initially). It all builds, but dpkg-gensymbols complains that the symbol table is (very) different from the previous version. I know I could just replace the libfreerdp1.symbols files, but if the library is not binary compatible, should I be doing something else?
[09:35] <ogra_> xnox, https://launchpad.net/usb-imagewriter the 1.99 tarball has a find_devices python script (pretty trivial and not 100% done yet) that shoud do it
[09:36] <ogra_> hmm, didnt i also push that to a bzr tree ...
[09:37] <xnox> alexbligh1: is it actually binary incompatible? is it C or C++? Is it only symbol additions or removals as well?
[09:37] <xnox> alexbligh1: is it symbols that are now hidden by gcc4.7 and thus are private and should be marked optional?
[09:37] <alexbligh1> xnox, I don't know, but it's failing a -c4 test which according to the manpage means 'new libraries'. It's C.
[09:37] <xnox> alexbligh1: did you run abi checker (there are two good tools in the wild) and do they confirm that ABI is broken?
[09:38] <ogra_> http://bazaar.launchpad.net/~ogra/usb-imagewriter/trunk/revision/20
[09:38] <ogra_> there we go
[09:38] <alexbligh1> xnox, nope.
[09:38] <xnox> =/
[09:39] <alexbligh1> xnox, what I'm trying to establish is what I need to do if the ABI /is/ broken. Right now I can no doubt get it to compile with dpkg-gensymbols -p (from memory).
[09:39] <alexbligh1> (I presume)
[09:40] <xnox> alexbligh1: make a new build (remove dpkg-gensymbols), take both debs (old & new) unpack in two parallel trees
[09:41] <xnox> alexbligh1: install abi-compliance-checker write simple xml config file (paths to both  unpacked trees & extra -L and -I stanzas)
[09:41] <xnox> alexbligh1: run it get html it will tell you if they are compatible
[09:44] <alexbligh1> xnox, what do I need to override to remove the call to dpkg-gensymbols? The rules file is pretty bare at the moment
[09:46] <cjwatson> Not remove but you could pass -c0 so that it doesn't fail
[09:46] <cjwatson> override_dh_makeshlibs:
[09:46] <cjwatson>         dh_makeshlibs -- -c0
[09:46] <cjwatson> assuming dh7
[09:46] <alexbligh1> cjwatson, thanks
[09:47] <xnox> ;-)
[10:36] <mpt> ev, <https://blueprints.launchpad.net/ubuntu/+spec/other-q-defects-dashboard> includes this line: "Split errors.ubuntu.com crashes per pockets (-updates, -proposed, etc)"
[10:36] <mpt> Is that doable with the Launchpad API?
[10:37] <mpt> I'm thinking items in the "all packages" menu ("-updates packages", "-proposed packages", etc)
[10:37] <ev> hmm
[10:41] <ev> mpt: I suspect we can start adding this information in with the report
[10:41] <ev> using the origins data from apt
[10:42] <mpt> ev, want a bug report for it?
[10:42] <ev> please
[10:42] <mpt> whoopsie?
[10:42] <ev> and apport
[10:42] <mpt> k
[10:42] <ev> both will need changes
[10:42] <ev> and daisy and errors
[10:42] <ev> yay multiple bug targets
[10:43] <ev> apport will need to include it, whoopsie will need to add it to the list of fields it sends, daisy will need to increment counters based on it, and errors will have to be adapted to show that
[10:43] <ev> at least that's how its working in my head right now
[10:44] <ev> I don't think getting the data from the launchpad API after we have the crashes works. There's no way to tell if a version came from -proposed or -updates (once it's there)
[10:44] <ev> but maybe once it's in -updates we just assume viewers care about that?
[10:44] <ev> hm
[10:47] <mpt> reported bug 1050853
[10:49] <ogra_> ev, is https://rt.admin.canonical.com/Ticket/Display.html?id=55322 solved (working on the release team weekly report atm and i listed it as a blocker last week)
[10:50] <pitti> zyga: hm, I'm not sure why udisks 1 wouldn't relay the device removed signals; can you run it in foreground/debugging mode and see whether it reacts to the uevents?
[10:50] <pitti> zyga: if you see them in udisks2, you should also see them in u 1
[10:50] <zyga> pitti, I suspect it never really removes the device, but sure
[10:50] <zyga> pitti, udisks sees partitions going away
[10:50] <zyga> (udisks2)
[10:50] <pitti> zyga: that may be, but it shouldn't differ
[10:50] <zyga> let me see
[10:51] <pitti> zyga: perhaps there's something broken in udisks1, and nobody noticed because we don't really use it any more
[10:51] <ev> ogra_: it is, yes
[10:51] <ogra_> thx
[10:51] <zyga> http://pastebin.ubuntu.com/1204518/
[10:51] <pitti> zyga: you can run sudo /usr/lib/udisks/udisks-daemon --replace, and watch its output
[10:51] <zyga> pitti, that's the removal with udisks --monitor
[10:51] <zyga> oh, cool
[10:51] <pitti> zyga: I'm mostly offline over the afternoon, working in a train; just spot-checking IRC
[10:52] <zyga> http://pastebin.ubuntu.com/1204521/
[10:52] <zyga> pitti, removed SD card with two partitions
[10:53] <pitti> zyga: perhaps it just doesn't report the removals properly? the force-unmounting etc. seems to work fine
[10:53] <zyga> pitti, the card reader?
[10:54] <pitti> no, udisks1
[10:54] <pitti> you can see the actual kernel events with udevadm monitor -e --udev
[10:54] <zyga> pitti, udisks2 reported objects being removed (InterfacesRemoved IIRC) on each partition
[10:54] <pitti> you shold see the removals there, and they ought to correlate with the udisks[12] daemon output
[10:54] <zyga> ok, trying
[10:55] <pitti> zyga: yeah, that's what I meant -- seems udisks1 is not reporting those; but do you need them?
[10:55] <zyga> pitti, well the code was written to expect them and they do get reported, for example, when I remove a thumb drive
[10:55] <zyga> pitti, no removal in udev
[10:55] <zyga> http://pastebin.ubuntu.com/1204529/
[10:56] <pitti> zyga: then I suppose you only removed the media, not the actual card reader?
[10:56] <zyga> yes!
[10:56] <zyga> :-)
[10:56] <zyga> sorry if that was not evident
[10:56] <zyga> but, some readers report the reader to go away as well
[10:56] <pitti> weird, the kernel should at least send removal events for sdd1 and sdd2
[10:56] <zyga> it's somewhat messy
[10:56] <pitti> depends if you eject or "safe removal", too
[10:57] <zyga> I just yank the card
[10:57] <pitti> the latter powers down the reader (if it's on USB)
[10:57] <zyga> but you are right
[10:57] <zyga> if I do this it will permanently disable the reader (it's internal USB)
[10:57] <pitti> zyga: then it seems there's something wrong with the media polling
[10:57] <pitti> sd card readers are a bit of a nuisance and expose interesting corner cases
[10:57] <pitti> perhaps you shold try this with an usb stick
[10:57] <pitti> and we can debug the sd card reader on Monday
[10:57] <pitti> (the polling)
[10:57] <zyga> ok
[10:58] <zyga> just quick question
[10:58] <zyga> where is the polling implemented? udisks?
[10:58] <pitti> so that you don't need to block on this
[10:58] <pitti> no, the kernel does it these days
[10:58] <zyga> ah
[10:58] <zyga> pitti, http://pastebin.ubuntu.com/1204533/
[10:58] <pitti> with the help of some udev rules to enable it
[10:58] <zyga> pitti, adds are properly reported though
[10:58] <zyga> ok
[10:58] <zyga> thanks a lot :)
[10:58] <pitti> yeah
[10:58] <pitti> sd card readers and cd-roms just don't bother to report ejected media
[10:59] <pitti> so something needs to poll them (yay hardware)
[10:59] <zyga> well they report something, I get a changed event and udisks force-unmounts stuff
[10:59] <pitti> yes, that's due to the polling
[10:59] <zyga> DISK_MEDIA_CHANGE=1
[10:59] <zyga> ah
[10:59] <pitti> ah, so that works
[10:59] <zyga> so a kernel bug on partitions?
[10:59]  * zyga checks if they are still around
[11:00] <zyga> YES
[11:00] <zyga> both /dev/sdd{1,2} exist
[11:00] <zyga> funny
[11:00] <ev> mpt: replied to bug 1050853 and asked you, bdmurray, skaet, and pitti for your follow up thoughts.
[11:00] <pitti> so, no idea why it doesn't remove /dev/sdd[12] then
[11:00] <pitti> but that seems to be a bug at the kernel/driver level
[11:00] <zyga> ok, let's trace this next week
[11:00] <pitti> zyga: usb sticks should behave more sensibly
[11:00] <pitti> so, /me -> offline again, bbl
[12:08] <jamespage> doko, when is the rebuild test scheduled for?  I can fixup maven-debian-helper (know the codebase a bit...)
[12:08] <jamespage> I did suggest making it a little more intelligent - i.e. if its building jars for a libXXX-java to assume --java-lib even if not specified
[12:09] <doko> jamespage, would like to understand the kernel/binutils issue first. but planning to start it tomorrow
[12:28] <georgelappies> hi all, I am second year CS student and I am learning all these cool things like data structures and class templates STL etc in c++. I am looking for a c++ project where I can get my feet wet. Nothing as involved as chromium for instance at the moment. How can I see which apps are written in what language for ubuntu?
[12:29] <cjwatson> 'apt-cache show PACKAGENAME' will show you its dependencies - just about anything written in C++ will depend on libstdc++6
[12:30] <georgelappies> cjwatson, thanks :)
[12:32] <cjwatson> although I would say that real-world programs use nowhere near the astonishing array of data structures that you learn in CS class, except in a tiny minority of cases
[12:32] <cjwatson> for most things it turns out that a fairly small number of standard facilities are enough
[12:40] <georgelappies> cool, yeah I must admit the course material is very generic.
[12:40] <georgelappies> but nothing beats the feeling of trying to get your program to compile and run bug free :)
[12:43] <georgelappies> but it seems like nearly everything in ubuntu is c and not c++
[12:47] <georgelappies> does ubuntu ship with the qt library? I have qtcreator installed so I cannot check it on my system.
[12:48] <SpamapS> georgelappies: Drizzle is a great one to take a look at
[12:48] <georgelappies> SpamapS, thanks will check it out right away ;)
[12:48] <SpamapS> georgelappies: its a fork of MySQL that has been refactored to take more advantage of the STL and do things in a more C++ way
[12:48] <SpamapS> georgelappies: drizzle.org
[13:01] <georgelappies> SpamapS, I am busy creating vm for ubuntu-server 12.04 to install drizzle in, should I go for the debs in the repo or should I try to get the latest code? If so where do I begin with that?
[13:03] <SpamapS> georgelappies: if you're going to hack on the code, you want the trunk, 'bzr branch lp:drizzle'
[13:05] <georgelappies> SpamapS, ok cool thanks I can just run that out of for instance ~/src on my main machine? sorry if these questions seem trivial but I complete noob atm.
[13:10] <SpamapS> georgelappies: no worries. yes thats exactly what I do
[13:10] <SpamapS> georgelappies: #drizzle is quiet, btw, but the devs do occasionally answer questions (myself included)
[13:17] <SpamapS> doko: status on bug 1048710 ? Juju is dead in the water without a fix. :-/
[13:18] <doko> SpamapS, on my list
[13:22] <SpamapS> doko: ok cool. Its worth noting that juju being broken also means all of the openstack QA for quantal is broken too. :-P
[13:38] <georgelappies> SpamapS, roughly how much will bzr download the first time when checking out drizzle?
[13:39] <SpamapS> georgelappies: oh.. heh.. a ridiculous amount..
[13:40] <SpamapS> georgelappies: 267M	.bzr
[13:40] <georgelappies> lol, ok cool :)
[13:40] <jamespage> > samba < openjdk-7
[13:40] <jamespage> gotta love big branches....
[13:40] <SpamapS> georgelappies: the code is not small.. :)
[13:40] <georgelappies> SpamapS, thank you
[13:46] <georgelappies> SpamapS, ok while it is downloading some more noob questions: I first just want to confirm that it is not possible for me to corrupt or damage the bzr code. Will all the changes I make only effect my local code? how then many moons from now when I get to a situation where I may want to submit something will it get updated / reviewed?
[13:51] <mpt> Can anyone tell me what <http://people.canonical.com/~ubuntu-archive/NBS/> (linked to from <http://reports.qa.ubuntu.com/reports/ogasawara/weatherreport.html>) is for?
[13:52] <SpamapS> georgelappies: right, you can't hurt anything. You have to be in the drizzle developers team to commit code to the main trunk
[13:52] <SpamapS> georgelappies: what you can do right away is make a change, commit it (locally), push it to launchpad, and then propose it for merging
[13:53] <SpamapS> mpt: NBS == Not Built from Source
[13:53] <SpamapS> mpt: means they are binaries whose Source: does not exist
[13:53] <mpt> SpamapS, interesting. How was the binary built, then?
[13:53] <SpamapS> mpt: previously, when the source existed
[13:54] <mpt> SpamapS, so why would the source have disappeared?
[13:54] <georgelappies> SpamapS, thanks for your detailed assistance it much appreciated.
[13:54] <SpamapS> mpt: archive maintenance presumably
[13:56] <SpamapS> mpt: forgive me, I misspoke. The source: is still there, but no longer builds that particular binary
[13:57] <mpt> SpamapS, so there is source for a newer version that hasn't built yet, and the source for the built version has been deleted?
[13:57] <SpamapS> mpt: even if the newer version has been built, the old binaries aren't removed on publish
[13:58] <SpamapS> mpt: because of the reverse deps on them, that would break the archive
[13:58] <mpt> SpamapS, ah, so that's why the individual files in that directory are lists of dependencies
[13:58] <SpamapS> mpt: for the libs, the rdeps just need a rebuild most likely
[13:58] <cjwatson> mpt: Also, the more usual thing we look at nowadays is http://people.canonical.com/~ubuntu-archive/nbs.html
[13:59] <cjwatson> Same data but more helpfully formatted
[13:59] <mpt> splendid
[13:59] <SpamapS> yeah that one is much better :)
[13:59] <cjwatson> mpt: This is essentially a to-do list for the +1 maintenance team
[13:59] <mpt> thanks cjwatson, thanks SpamapS
[14:00] <cjwatson> ogasawara: ^- you might like to update the weather report to point to the new NBS location
[14:00] <cjwatson> Though maybe just the link, as I suspect the location you're pointing to at the moment is easier to count automatically
[14:01] <ogasawara> cjwatson: ack, will do.  also I'll get that fix for 1047092 uploaded shortly.
[14:01] <cjwatson> (And, indeed, +1 maint has been making good progress on that list lately ...)
[14:01] <cjwatson> ogasawara: Thanks
[14:02] <mlankhorst> hey
[14:02] <mpt> cjwatson, one final question: Who is the "+1 maintenance team"? I don't see them searching for "maintenance" on LP
[14:03] <cjwatson> mpt: It's a frequently rotating team, so not expressed in LP.  https://wiki.ubuntu.com/PlusOneMaintenanceTeam
[14:03] <mpt> thanks
[14:03] <cjwatson> Currently Matthias and Didier according to that schedule
[14:05] <slangasek> lifeless: er, considering that bug has been fixed since 2005, you probably have a different bug?
[14:06] <slangasek> lifeless: yes there is a metoo on the bug that's after the upload, but if this were a pam problem a lot more people would've reported it over the past 7 years :)
[15:30] <akheron> I'm unable to install quantal from usb stick
[15:30] <akheron> bug 1050590
[15:30] <akheron> this isn't reported by me but seems to be exactly the same bug
[15:32] <akheron> according to syslog, apt-install grub-efi cannot download the package for some reason
[15:33] <akheron> any workarounds?
[15:35] <cjwatson> akheron: I'm currently waiting to pick up a hire car; I'll have a look at your problem when I get home
[15:35] <cjwatson> since I expect it's related to GRUB 2.00
[15:36] <akheron> cjwatson: ok, thanks
[15:36] <akheron> I'll be actually leaving work right now, and the hardware is left here
[15:36] <akheron> but I'll be back on monday
[15:37] <akheron> I'll read irc, though, if you have suggestions
[15:38] <cjwatson> I expect I'll just fix it rather than offering suggestions
[15:38] <cjwatson> If the hire co's computer systems ever come back up
[15:39] <cjwatson> (If it takes too long, then I won't be able to fix anything until Monday)
[15:40] <ogra_> sell them ubuntu support contracts while you're there waiting ;)
[15:41] <cjwatson> It is tempting, but there are issues with revealing one's knowledge of computers in this kind of situation
[15:41] <rickspencer3> lol
[15:41] <ogra_> lol, i know exactly wht you meana
[15:41] <ogra_> *mean
[16:28] <infinity> ScottK: Do you care that the changelog for libksane is wrong (the actual change to debian/control appears correct)
[16:29] <cjwatson> akheron: Oh.  This has nothing to do with GRUB 2.00, from that other user's log.  Either the nameserver fell over at a suspiciously inconvenient time (unlikely with multiple reports, though still possible), or the resolver configuration was broken mid-install.  (It's also a bit odd that grub-efi-amd64 apparently wasn't available locally, without going to the network.)
[16:30] <cjwatson> akheron: I'll have to look at this in more depth on Monday.
[16:36] <infinity> pitti: So, uhm, did the same weird accident happen five hours ago for lucid?
[16:37] <infinity> pitti: Or were those 300+ langpacks intentional?
[16:47] <ScottK> infinity: Not really.
[16:50] <mitya57> ScottK: Hi, can you please look at lp:~mitya57/+junk/python3-defaults, especially r170?
[16:50] <mitya57> ScottK: (POX doesn't respond, and the bug is quite important)
[16:52] <ScottK> mitya57: What bug?
[16:52] <mitya57> ScottK: http://bugs.debian.org/685167
[16:53] <ScottK> If it's urgent, I'd ask barry.  I'm unlikely to have any time to look at it before the middle of next week.
[16:54] <mitya57> ScottK: does barry have push access to pkg-python bzr?
[16:55] <ScottK> I think so, if not, I'll push it after he reviews/tests.
[16:58] <infinity> ScottK: Accepted, then.
[16:58] <ScottK> infinity: Thanks.
[17:06]  * mitya57 hopes barry will read this eventually
[17:19] <alkisg> stgraber: sshfs-fuse has a bug that results in fat clients offering to "execute / open" text files instead of just opening them. The upstream dev posted a patch in a mailing list, I was planning to upload a fixed sshfs package in the greek PPA, but maybe it's worth it to SRU it instead?
[17:19] <alkisg> LP bug #1017870
[17:22] <mitya57> That can't be SRUed until it's fixed in quantal...
[17:23] <stgraber> alkisg: oh, that's an actual sshfs bug, not nautilus as the bug seems to indicate?
[17:23] <stgraber> alkisg: anyway, yeah, it's a bug so if the patch is of a reasonable size, I'd go with pushing to quantal + SRU to precise
[17:23] <alkisg> stgraber: yes, the nautilus devs pointed me that it might be an sshfs bug, and I posted in the sshfs mailing list and the dev there proposed a fix
[17:24] <alkisg> The diff is there, pretty small: http://sourceforge.net/mailarchive/forum.php?thread_name=87y5keushb.fsf%40tucsk.pomaz.szeredi.hu&forum_name=fuse-sshfs
[17:24] <alkisg> I'll attach the patch to the bug report and target quantal, hope someone uploads it
[17:25] <micahg> alkisg: you'll have more luck if you attach a debdiff and subscribe ubuntu-sponsors
[17:25] <micahg> and fill out the SRU paperwork
[17:25] <alkisg> debdiff it is, thank you
[17:26]  * alkisg hates paperwork but it's the right thing to do... :(
[17:26] <micahg> alkisg: so, 2 debdiff, 1 for quantal, and 1 for precise, I"ll give you a bug task for precise
[17:27] <stgraber> alkisg: let me know once you have the diffs on the bug (ideally debdiffs) and I'll review + upload to quantal and precise
[17:27] <alkisg> OK, doing so...
[17:41] <cking> is anyone seeing issues with libreoffice since the last load of updates?  The global menu for it sometimes does not appear and I'm getting segfaults when inserting graphs from my data sets
[17:43] <micahg> bug 1044657?
[17:44] <cking> hrm, well I am running unity with the global menus disabled (cough)
[17:44] <cking> so,yes, looks possible
[17:45] <cking> ah, actually, I've just double checked on my test box and I get the same issue with unit + global menus
[17:47] <cking> bah, now it's segfaulted again, /me files a bug
[17:48] <alkisg> sshfs-fuse version number is 2.4-1, would the fixed package version be 2.4-1ubuntu1 or 2.4-1-0ubuntu1 ?
[17:48] <micahg> alkisg: for quantal 1ubuntu1
[17:49] <alkisg> Ty
[17:52] <slangasek> cjwatson: not sure if I'm looking at a grub bug or an aptdaemon/u-m bug, but grub-pc has hung for me at a ucf prompt that I'm not seeing
[17:54] <stgraber> alkisg: 2.4-1ubuntu1 for quantal and 2.4-1ubuntu0.1 for precise
[17:55] <alkisg> stgraber: does this look ok to propose for merging? https://code.launchpad.net/~alkisg/ubuntu/quantal/sshfs-fuse/sshfs-fuse-lp1017870/
[17:55]  * alkisg followed https://wiki.ubuntu.com/PackagingGuide/Recipes/Debdiff ...
[17:56] <stgraber> alkisg: precise => quantal in the changelog
[17:56] <alkisg> Ouch, fixing...
[17:57] <stgraber> alkisg: the change should also be properly registered in debian/patches. If you're using bzr-builddeb you can do that by running "bzr bd -e && dpkg-source --commit", then enter a name for the patch (bug number should do) and enter a short description in the editor that will open
[17:57] <alkisg> Fixed the changelog...
[17:58] <infinity> doko: By the way, all the Pandas are (finally) running precise, so I'd say we're good to go for test rebuilds.
[17:58] <stgraber> once the patch created by dpkg-source --commit, add all the new files created by it and commit that and you should be good
[17:59] <barry> ScottK: i'll take a look
[17:59] <ScottK> Thanks.
[18:13] <alkisg> stgraber: could you have another look? http://bazaar.launchpad.net/~alkisg/ubuntu/quantal/sshfs-fuse/sshfs-fuse-lp1017870/revision/15
[18:14] <stgraber> alkisg: sure
[18:14] <stgraber> alkisg: looks good!
[18:14] <alkisg> OK, should I propose it for merging, and do the same for precise?
[18:15] <stgraber> alkisg: just give me a similar branch for precise, I'll take care of merging and uploading
[18:15] <alkisg> Thanks :)
[18:15] <stgraber> alkisg: but yeah, when you don't already have someone taking care of this for you, the usual process is to propose for merging on Launchpad so it shows up on the sponsoring report
[18:15] <alkisg> Gotcha
[18:22] <stgraber> alkisg: oh, for the precise one, can you also run update-maintainer? I just noticed that was missing in the quantal one and did it for you
[18:22] <alkisg> (08:54:50 μμ) stgraber: alkisg: 2.4-1ubuntu1 for quantal and 2.4-1ubuntu0.1 for precise ==> precise has 2.3-1, so would it be 2.3-1ubuntu1 instead ?
[18:22] <alkisg> Sure
[18:23] <stgraber> alkisg: oh, for some reason I thought they had the same version. So use 2.3-1ubuntu0.1 for precise
[18:23] <alkisg> Ty
[18:24] <stgraber> alkisg: quantal one uploaded
[18:27] <alkisg> stgraber: https://code.launchpad.net/~alkisg/ubuntu/precise/sshfs-fuse/sshfs-fuse-lp1017870/
[18:28] <alkisg> stgraber: ignore that
[18:28] <alkisg> Forgot bzr add, reuploading...
[18:29] <alkisg> stgraber: ok, done
[18:31] <stgraber> alkisg: thanks
[18:31] <stgraber> alkisg: finishing something else, will merge and upload in a few minutes
[18:48] <lifeless> slangasek: probably yes.
[18:48] <lifeless> slangasek: anyhow, I have the symptoms :)
[19:02] <mterry> ev, how do I associate a bug with a line in errors.ubuntu.com?
[19:04] <stgraber> alkisg: looking now
[19:04] <alkisg> ty
[19:18] <geofft> Is there a particularly good way for me to recompile one kernel module with different Kconfig options?
[19:19] <geofft> Preferably without recompiling the whole kernel, and preferably getting a .deb out of it, but that might be hard
[19:19] <stgraber> alkisg: uploaded to precise-proposed
[19:29] <dobey> geofft: #ubuntu-kernel might be more help
[19:34] <alkisg> stgraber: thanks man
[20:20] <slangasek> lifeless: right, so, what symptoms do you have specifically?  'dpkg-reconfigure locales' is a no-op on Ubuntu
[20:22] <slangasek> lifeless: in what pam service context do you see the problem, what are the contents of /etc/default/locale, what are the env vars that are or aren't set
[20:32] <lifeless> slangasek: I ssh into an lxc container I have
[20:32] <lifeless> slangasek: /etc/environment and /etc/defaulte/locale have en_US set, locale-gen has create en_US (utf8 in both cases)
[20:32] <lifeless> after login LANG and LANGUAGE and LC_ALL are empty, and the other LC variables are set to POSIX
[20:33] <lifeless> setting my LANG and LANGUAGE in my outer session to various values seems to have no effect.
[20:33] <lifeless> the lxc container is lucid, with no changes made to the ssh config, postgresql installed and thats about it.
[20:33] <lifeless> oh, rabbitmq as well
[20:34] <lifeless> slangasek: I'm not familiar enough with where the locales are setup to be very effective debugging atm :(
[20:34] <slangasek> lifeless: /etc/pam.d/sshd unmodified?  (should have 'auth       required     pam_env.so envfile=/etc/default/locale')
[20:49] <lifeless> slangasek: checking
[20:50] <lifeless> auth       required     pam_env.so envfile=/etc/default/locale
[20:50] <lifeless> /etc/default$ cat locale
[20:50] <lifeless> LANG="en_US.UTF-8"
[20:50] <lifeless> LANGUAGE="en_US"
[21:18] <slangasek> lifeless: not that this would impact the variables being set or not, but I think LANGUAGE should be set to en rather than en_US, no?
[21:20] <lifeless> slangasek: AIUI you can say LANGUAGE="en_AU:en_US:tlh_UK:en" to do fallbacks
[21:20] <lifeless> slangasek: however I tried a few things, happy to fiddle.
[21:20] <lifeless> slangasek: the odd thing is that LANGUAGE and LANG are empty in the output of locales in the container
[21:20] <slangasek> right
[21:21] <slangasek> do you have syslog capabilities within the container?  might want to crank up the debugging in both ssh and pam_env (which takes a 'debug' argument)
[21:23] <lifeless> I imagine so
[21:23] <lifeless> yes, it has a syslog
[21:23] <stgraber> lifeless: I usually install language-pack-en in the container to fix that kind of issue, though generating the locale with locale-gen should work just as well (and it doesn't explain the empty environment)
[21:23] <lifeless> so, the pam.d/sshd file is the one to change for pam_env? What would it look like ?
[21:23] <lifeless> stgraber: its installed
[21:24] <lifeless> ii  language-pack-en                                      1:10.04+20110931
[21:24] <lifeless> stgraber: first thing I checked.
[21:24] <lifeless> OK WTF
[21:24] <lifeless> its now working.
[21:24] <slangasek> heh
[21:24] <lifeless> I spent an hour this yesterday.
[21:24] <lifeless> I  bet I can reproduce, and that something is only evaluated at container startup.
[21:25] <lifeless> because thats the one thing I didn't do at all.
[21:25] <stgraber> lifeless: for a while we had an apparmor/kernel bug that was preventing writes to /usr/lib/locale/locale-archive and that'd have caused similar symptoms, but that's been fixed in the first kernel sru after the 12.04 release
[21:25] <lifeless> stgraber: I have no /usr/lib/locale/locale-archive
[21:25] <lifeless> stgraber: the container is lucid
[21:26] <lifeless> lsb_release -a
[21:26] <lifeless> No LSB modules are available.
[21:26] <lifeless> Distributor ID: Ubuntu
[21:26] <lifeless> Description:    Ubuntu 10.04.4 LTS
[21:27] <lifeless> slangasek: stgraber: thanks for your attention on this. :/
[23:24] <achiang> anyone around familiar with gnome-power-manager? i just grabbed the source thinking there might be power policy in there, but a quick glance looks like "not really"
[23:27] <mdeslaur> achiang: I believe you're looking for gnome-settings-daemon
[23:28] <achiang> mdeslaur: ah, thanks for the hint
[23:28] <mdeslaur> achiang: look in plugins/power
[23:28] <achiang> mdeslaur: thanks. that's... not so intuitive. :)
[23:28] <mdeslaur> achiang: +1
[23:34] <slangasek> yes, gnome-power-manager should be renamed to gnome-power-observer