[00:03] <giaco> azeem, you missed the right order
[00:03] <azeem> dang
[00:03] <giaco> but probably you could guess one answer :-P
[00:05] <giaco> really, I'm reading the gdb manual to find out why the backtrace always says that the library doesn't have any debug symbol.
[00:08] <avb> giaco: just in case u can use LD_PRELOAD=/usr/lib/debug/usr/lib/libGL.so.1.5.070200 gdb myappname
[00:08] <slangasek> no, you can't
[00:08] <avb> why?
[00:09] <avb> was working all the time just fine
[00:09] <avb> :)
[00:09] <giaco> no, it just contains debug symbols
[00:09] <avb> ah
[00:09] <avb> i see
[00:09] <giaco> that's what I've just learned: it segfaults immediately if I preload it
[00:12] <giaco> isn't there a way to confirm that gdb loads the symbols automatically? The backtrace says that /usr/lib/libGL.so.1 is used, but no symbols inside
[00:13] <slangasek> giaco: that's really not on-topic for this channel; but are you sure that /usr/lib/GL.so.1 on your system is the one from libgl1-mesa-swx11?
[00:16] <giaco> slangasek, that's what this page says http://packages.ubuntu.com/intrepid/i386/libgl1-mesa-swx11/filelist
[00:16] <giaco> I've just installed it, I could reinstall it if it's necessary
[00:16] <slangasek> that's the wrong place to look; the question is not "does libgl1-mesa-swx11 contain such a file", the question is "is that the package which provides that file on your system"
[00:17] <slangasek> that question is answered by dpkg -S /usr/lib/libGL.so.1 - and now this is definitely off-topic
[00:17] <giaco> it's off topic, ok, btw libgl1-mesa-swx11: /usr/lib/libGL.so.1 and the debug is not working
[00:49] <mathiaz> kees: so it seems that pie breaks at least one test case in openldap 2.4.15
[00:49] <mathiaz> slangasek: ^^
[00:49] <mathiaz> slangasek: debian doesn
[00:50] <mathiaz> slangasek: debian doesn't enable pie in openldap right?
[00:50] <slangasek> there's nothing in the Debian packaging to enable PIE, no
[00:50] <mathiaz> slangasek: great - thanks.
[00:50] <mathiaz> kees: how can I debug this?
[00:52] <kees> mathiaz: ew, is it only with the new version?
[00:52] <kees> mathiaz: I've actually never debugged a PIE problem, but I'd basically treat it like any other corruption problem -- what's die, where, what variables are involved, and how does it compare to the non-PIE version
[00:53] <mathiaz> kees: yes - 2.4.14 built sucessfully in jaunty
[00:54] <mathiaz> kees: 2.4.15 does not
[00:54] <mathiaz> kees: it always fails in the same test case.
[00:54] <mathiaz> kees: ok - I'll try to replicate the setup - a least I've got a test case to work from
[00:57] <TheMuso> /c/c
[01:28] <vbgunz> I pretty much got suspend to ram working pretty flawlessly. anyone have any ideas why suspending to disk can still be an epic failure? I'll try anything, any ideas?
[03:37] <vbgunz> I finally got suspend to disk working too. but upon second resume, although everything appeared fine, my networking is dead. the first time it was fine. the second time, dead and sudo /etc/init.d/networking restart|stop|start didn't do a thing about it :/
[03:37] <vbgunz> can someone help me troubleshoot that?
[03:40] <ScottK> vbgunz: Help is in #ubuntu for dapper/gutsy/hardy/intrepid and #ubuntu+1 for Jaunty
[03:42] <vbgunz> ScottK: ok. thought this was a big issue here. I have about 90% suspend issues solved. 100% if not for the failed network on second resume. cool.
[07:50] <pitti> Good morning
[07:52] <sbeattie> pitti: moin
[07:53] <sbeattie> pitti: re apport-collect, in https://bugs.launchpad.net/ubuntu/+source/cups/+bug/336512 the reporter used apport-collect to collect additional information, but it looks like only the stuff reported by attach_hardware(report) got attached and not attach_printing(report), which is sadly the crucial bit. Any idea why?
[07:56] <pitti> sbeattie: but it does
[07:56] <pitti> sbeattie: there's Papersize and a (failed) lpstat
[07:57] <sbeattie> pitti: hrm, but where's the cups error log?
[07:57] <pitti> sbeattie: problem for error_log is that a normal user doesn't have permission to access it
[07:58] <sbeattie> Oh. mu.
[07:58] <pitti> PpdFiles is missing, too, though
[07:58] <pitti> sbeattie: looks like the hook crashed halfway through
[07:58] <pitti> sbeattie: let me try that here locally
[07:59] <sbeattie> pitti: was wondering if the failed lpstat was causing something like that.
[07:59] <pitti> no, shouldn't
[08:00] <pitti> but wait..
[08:00] <pitti>     nicknames = command_output(['fgrep', '-H', '*NickName'] + glob.glob('/etc/cups/ppd/*.ppd'))
[08:00] <pitti> sbeattie: ^ if the glob is empty, then this will hang forever
[08:00] <pitti> >>> apport.hookutils.attach_printing(r)
[08:00] <pitti> -> indeed that never returns
[08:01]  * pitti fixes
[08:01] <pitti> sbeattie: ah, and it also tries to attach "error-log", not "error_log"
[08:04] <sbeattie> cool, thanks for digging into it.
[08:04] <pitti> sbeattie: btw, attaching error_log will do fine for crashes (which are processed as root), but not for bug reports
[08:05] <pitti> arguably those log files should be root:adm, not root:lp
[08:07] <sbeattie> is there anything sensitive that gets reported in error_log?
[08:08] <pitti> well, file names, dates, etc.
[08:37] <directhex> tseliot, after all that, seems 180.11 DOES support the 216-core gtx260..... however, intrepid's kernel doesn't support the audio or networking on my board ;)
[08:37] <directhex> so seems i'll be updating my desktop to jaunty earlier than planned :|
[08:37] <tseliot> directhex: problem solved then, well kind of ;)
[08:38] <directhex> tseliot, good thing i had a spare tg3 card
[09:29] <slytherin> StevenK: Hi. Do you maintain seed for mobile-meta?
[09:30] <StevenK> slytherin: I do.
[09:31] <slytherin> StevenK: just wanted to bring bug 337881 to your attention. :-)
[09:35] <StevenK> slytherin: Commented on, thanks!
[09:36] <lool> Where are the removal reasons again?
[09:36] <lool> StevenK: Could you please check why mesa-swx11-source was removed in intrepid?
[09:37] <lool> StevenK: it's needed to build vnc4 it seems
[09:37] <lool> Build-Depends: ... mesa-swx11-source (>> 6.4.1)
[09:38] <StevenK> lool: The removal reasons have all been pulled into LP
[09:39] <lool> Ah right
[09:39] <StevenK> lool: But dropping a binary is up to the source package that provided it
[09:43] <lool> StevenK: Right, I see it was dropped in mesa now; thanks
[09:55] <Cimi> how can I download the linux-image souce?
[09:55] <Cimi> the LPIA jaunty port has a mistake
[09:55] <Cimi> strangely it lacks of the ext4 module
[09:55] <Cimi> it has to be recompiled/patched
[09:56] <cjwatson> I'm fairly sure there's a bug report about that
[09:56] <cjwatson> apt-get --only-source source linux
[09:56] <Cimi> I did them
[09:57] <cjwatson> I've targeted it for jaunty so that it doesn't get forgotten (bug 331848)
[09:57] <Cimi> perfect
[09:57] <Cimi> anyway apt-get --only-source source linux doesn't work with jaunty
[09:57] <Cimi> it doesn't fetch the sources
[09:57] <Cimi> just something like a meta package
[09:57] <Cimi> only few bytes
[09:58] <directhex> correct
[09:59] <directhex> linux-meta
[09:59] <Cimi> where's the source of those packages?
[09:59] <cjwatson> are you sure you used the --only-source option?
[09:59] <Cimi> I've tried a lot of combinations, it just downloads the linux.meta
[10:00] <cjwatson> hmm, indeed that doesn't work, odd
[10:00] <directhex> oh. tee hee. the source package "linux" contains images; the source package "linux-meta" contains the "linux" package
[10:00] <cjwatson> yeah, but --only-source is meant to avoid that problem
[10:00] <cjwatson> http://archive.ubuntu.com/ubuntu/pool/main/l/linux/ anyway
[10:00] <directhex> apt-get source linux-image-2.6.28-8-generic ;)
[10:01] <directhex> sigh, there has GOT to be a better way to enumerate model= parameters for snd-hda-intel than looking at the source
[10:01] <Cimi> generic will work for LPIA?
[10:01] <cjwatson> Cimi: same source package, don't worry about it
[10:01] <cjwatson> hmm, apt-get source seems a bit broken here
[10:01] <Cimi> I mean when I will run the dpkg-buildpackage it will generate the lpia deb with custom kernel config?
[10:02] <cjwatson> if you're building on an lpia system, yes
[10:02] <Cimi> but I want the lpia config with the lpia patches
[10:02] <Cimi> just with ext4 support
[10:02] <cjwatson> mvo: why does 'apt-get source linux-source-2.6.28' print out some strange misformatted messages and then get me the linux-meta source?
[10:02] <cjwatson> Cimi: yes
[10:02] <Cimi> I don't want a generic, i385 compiled for lpia
[10:02] <Cimi> ok
[10:02] <Cimi> *i386
[10:03] <cjwatson> 'apt-get source linux-image-2.6.28-8-generic' doesn't work at the moment anyway
[10:03] <cjwatson> Cimi: just download the source from http://archive.ubuntu.com/ubuntu/pool/main/l/linux/ directly
[10:03] <Cimi> cjwatson, I'm using apt-get source linux-image-2.6.28-8-generic
[10:03] <Cimi> it works here
[10:03] <cjwatson> Cimi: you want the linux_2.6.28.orig.tar.gz, linux_2.6.28-8.27.diff.gz, and linux_2.6.28-8.27.dsc files
[10:04] <cjwatson> ok
[10:06] <Cimi> cjwatson, I would like to attach a patch on the bugreport, which is the correct way to get debian diffs? I mean, i just need to use diff on the uncompressed folder or something different?
[10:07] <cjwatson> Cimi: is a patch actually going to speed things up? it would take a kernel developer about ten seconds to fix
[10:07] <cjwatson> (so I nudged them)
[10:07] <Cimi> it's one second patch
[10:07] <cjwatson> so don't bother :)
[10:07] <Cimi> ok ;)
[10:08] <cjwatson> Cimi: for submitting patches to the kernel in general though, https://wiki.ubuntu.com/KernelGitGuide
[10:08] <Cimi> but since this bugreport is opened from days and no one did anything...
[10:08] <cjwatson> Cimi: so you could do that
[10:10] <mvo> cjwatson: looks like a bug, give me a sec, I have a closer look (it seems to prefer the binary "linux" that is build from linux-meta over the srcpkg "linux"
[10:10] <cjwatson> mvo: well, that's just the behaviour that --only-source changes; but linux-source-2.6.28 should be unambiguous
[10:10] <cjwatson> (I'm not asking for the --only-source default to change, that seems like a bikeshed)
[10:11] <cjwatson> Cimi: smb_tp said he'd fix it
[10:12] <Cimi> cjwatson, so I just need to wait for an updated package?
[10:12] <cjwatson> that's usual when a developer says he'll fix something, yes :)
[10:13] <Cimi> cjwatson, please ask him when it will be released: I have a big partition I would like to use, and I need to know if it worth a compile on my netbook
[10:15] <cjwatson> Cimi: you can ask him yourself, he's here
[10:15] <Cimi> oh :)
[10:15] <Cimi> smb_tp, ^^
[10:16] <smb_tp> I am on it to enable the ext4 module
[10:16] <Cimi> yeah
[10:16] <Cimi> do you know when the package will hit the repository?
[10:17] <smb_tp> not exactly, I'll have to check with someone else, but I could provide you with intermediate kernels.
[10:18] <Cimi> that would be wonderful, compilation on an atom is somewhat painful :)
[10:18] <directhex>         _R("RTL8168d/8111d",    RTL_GIGA_MAC_VER_25, 0xff7e1880)  // PCI-E
[10:18] <directhex> damn. jaunty supports this, but not intrepid
[10:18] <smb_tp> I know :) Will update the bug when I got something up
[10:19] <Cimi> smb_tp, something like a link on a deb? :-)
[10:19] <smb_tp> yep
[10:19] <Cimi> amazing, thank you
[10:20] <directhex> intrepid has RTL_GIGA_MAC up to VER_20, new motherboard has VER_25
[10:20] <mvo> cjwatson: it seems like the prolem is that it goes over the Source file sequentially and stops on the first (bin|src) name it finds. so if the bin linux name is found first it gives this confusing result
[10:22] <Cimi> mvo, cjwatson https://bugs.launchpad.net/ubuntu/+source/linux-meta/+bug/330103
[10:28] <mvo> thanks Cimi
[10:38] <slytherin> pitti: with regards to bug 305790, any idea why lucene2 was never moved to main?
[10:47] <davmor2> guys what package should I file this too Bug 338159
[10:49] <directhex> davmor2, you know that's intentional, right?
[10:50] <davmor2> almost certainly but you can't overwrite the one with the other
[10:57] <slytherin> davmor2: what do you mean by overwrite?
[10:58] <directhex> not clear to me. the conflicts is intentional, it forces apt to replace onewith the other (but never both together) as needed
[10:59] <slytherin> right. Even I am not clear what the issue is.
[11:02] <davmor2> slytherin: I understand this.  How ever only synaptic is able to replace the packages.  Add/remove and apt-get can't and don't give a sensible explanation as to why it failed
[11:03] <davmor2> slytherin, directhex: It is this that I'm having issues with rather than the conflict in packages
[11:04] <slytherin> davmor2: Both synaptic and add/remove use apt-get as backend. So I don't see why it should fail in apt-get and add/remove while it works in synaptic.
[11:04] <directhex> davmor2, you've neglected to paste the actual messages from apt/synaptic/whatever, which makes it harder to diagnose
[11:04] <slytherin> davmor2: may be there is something wrong on your system.
[11:05] <davmor2> slytherin: it's a vanilla install and it has been confirmed by others
[11:07] <davmor2> directhex: it just says it can't be installed in add/remove syaptic says nothing it just removes the non-unstripped versions
[11:12] <Keybuk> superm1: around?
[11:16] <directhex> hm @ current gdm theme in jaunty. not unique & brown enough!
[11:17] <slytherin> directhex: and I remember some problem with the right click menu not visible enough.
[11:55] <asac> Keybuk: http://launchpadlibrarian.net/20975050/ifupdown_0.6.8ubuntu13_0.6.8ubuntu14.diff.gz
[11:56] <asac> Keybuk: did you look at the debdiff before uploading?
[11:56] <Keybuk> asac: webm always goes mad
[11:57] <Keybuk> oh
[11:57] <Keybuk> that debdiff isn't even webm mostly
[11:57] <asac> Keybuk: well. you trashed the complete _darcs directory ;)
[11:57] <Keybuk> it's just that _darcs isn't included in the .tar.gz now
[11:57] <asac> Keybuk: can you do something like that: https://edge.launchpad.net/ubuntu/+source/ifupdown/0.6.8ubuntu12
[11:57] <Keybuk> and this is a bad thing because?
[11:57] <asac> Keybuk: unreadable debdiff ...
[11:58] <asac> Keybuk: i dont care. its just that the feature to not up interfaces if they are managed=true by NM seemed not to work
[11:58] <asac> and i tried to find the reason ;)
[11:58] <Keybuk> I guess dpkg doesn't include the _darcs directories anymore?
[11:58] <Keybuk> I would have just done dpkg-buildpackage -S
[11:59] <asac> Keybuk: yes. you need to trick it
[11:59] <asac> thats why i had this issue in ubuntu11
[11:59] <Keybuk> yeah, can't be arsed with that
[11:59] <Keybuk> if a package needs to be tricked to dpkg-buildpackage, it's a bug in the package
[11:59] <asac> Keybuk: its -I""
[11:59] <asac> or something
[11:59] <Keybuk> putting revision control in the package is a bug anyway
[11:59] <asac> Keybuk: well. tell that debian ;)
[11:59] <asac> Keybuk: i agree, but do having this diff in ubuntu makes future merges hard
[12:00] <Keybuk> we can fix that next time we merge
[12:02] <cjwatson> Keybuk: are you building on intrepid by any chance?
[12:02] <Keybuk> asac: hmm, the _darcs directory has come back again?
[12:02] <asac> Keybuk: even after filtering out _darcs from the diff its still really huge ;)
[12:02] <Keybuk> cjwatson: yes
[12:02] <cjwatson> Keybuk: see bug 317761
[12:03] <cjwatson> I'm just uploading an SRU for that now
[12:03] <Keybuk> ahh
[12:03] <Keybuk> interesting
[12:03] <asac> Keybuk: not sure. i will check now if the ifupdown feature is really broken ... if not i will not care
[12:03] <Keybuk> I thought that was deliberate :p
[12:03] <asac> if it is, i will let you knwo ;)
[12:03] <cjwatson> nah, causes real problems
[12:03] <Keybuk> heh
[12:04] <Keybuk> I should just upgrade dpkg to jaunty I guess
[12:04] <cjwatson> particularly for people who are intentionally trying to put binary gunk in source packages for one reason or another
[12:04] <cjwatson> you can test my SRU once it's approved :)
[12:04] <Keybuk> ok, deal
[12:07] <asac> Keybuk: could it be that we dont run ifup -a at boot time anymore now?
[12:07] <asac> but ifup IFACE for each individual one?
[12:10] <Keybuk> we do run ifup -a at boot
[12:10] <asac> Keybuk: hmm ok. i will check why the managed=true NM case was broken on my last boot then
[12:10] <asac> e.g. it was upped
[12:11] <asac> thanks
[12:38] <Keybuk> just once
[12:38] <Keybuk> for one release
[12:38] <Keybuk> or even just one day
[12:38] <Keybuk> I'd like the brightness setting and keys to work properly on my Dell
[12:38] <ion_> :-)
[12:39] <directhex> i've never owned a dell where they DON'T work!
[12:39] <directhex> it seems computers just hate you, Keybuk
[12:40] <Hobbsee> wfm?
[12:40] <Hobbsee> but still - i'd *love* my next track button to work again!
[12:40]  * Hobbsee has never been able to track that one down
[12:41] <Keybuk> directhex: if I don't touch my laptop, the backlight basically turns off
[12:41] <Keybuk> then if I do anything ... nothing happens
[12:41] <Keybuk> it doesn't go brighter again
[12:41] <Keybuk> if I use the brightness keys, there are over a hundred presses required to get it back to full brightness
[12:41] <Keybuk> and you can't just hold the key down either :p
[12:42] <asac> Keybuk: so the reason seems to be that the udev rules now trigger ifup UDEVDEVICE
[12:42] <Keybuk> asac: they have since ~dapper
[12:42] <asac> really?
[12:42] <Keybuk> pretty sure it was dapper, yeah
[12:42] <asac> Keybuk: then the order seems to have changed ... or the udev rules are now triggered on startup while they were not in intrepid?
[12:42] <Keybuk> nope, always been triggered on startup ;)
[12:43] <asac> Keybuk: well. i 100% sure that ifup IFACE was not run on startup ... only ifup -a in intrepid ;)
[12:43] <asac> Keybuk: any idea why? maybe the rules were broken?
[12:45] <asac> anyway. now that i know whats up i will fix that somehow.
[12:45] <Keybuk> if they didn't run, that was a bug in intrepid
[12:45] <cjwatson> pitti: damn, you're ahead of me on http://qa.ubuntu.com/reports/bug-fixing/jaunty-fixes-report.html
[12:45] <Keybuk> it might have been caused by that whole /var/run/network/initialized madness
[12:45]  * cjwatson considers strategies for catching up
[12:46] <cjwatson> ... ethical ones
[12:46] <asac> Keybuk: you mean ifstate?
[12:46] <Keybuk> asac: no, siretart did a whole bunch of changes in intrepid to try and fix a wpa_supplicant bug
[12:46] <Keybuk> but broke just about everything else in the process
[12:46] <Keybuk> he may have broken udev ifup too
[12:46] <Keybuk> we reverted them all in jaunty
[12:46] <asac> oh... that might be possible
[12:46] <pitti> cjwatson: *psssst* <whisper>secret tip: fix more?</whisper
[12:47] <pitti> cjwatson: I have 5 more in the pipe right now :)
[12:47] <asac> anyway, i will fix that somehow, but come back to you in case i am still on top of changelog for next merge round ;)
[12:47] <cjwatson> pitti: bah :)
[12:47] <cjwatson> I'm working on it :)
[12:47] <asac> pitti: so i talked to wellark. he said he would prefer if we wait till next week with mbpi
[12:47] <pitti> go, cjwatson, go!
[12:47] <asac> pitti: he wants to bake a real release over the weekend
[12:47] <asac> pitti: did you already push the upload out?
[12:47] <pitti> asac: hm, MBPI?
[12:47] <pitti> oh, that
[12:48]  * pitti knows that as Meyer-Briggs Personality Index
[12:48] <asac> ;)
[12:48] <pitti> (or something like that)
[12:48] <ogra> cjwatson, hmm, didnt flash-kernel get moved to main during the arm enablement ?
[12:48] <pitti> asac: can't talk longer, must fix more bugz!!
[12:48]  * mneptok is an ENFP
[12:48] <asac> pitti: sure. just wanted to let you know that we should wait with the upload/SRU
[12:49]  * pitti is ISTJ
[12:49] <pitti> asac: (just kidding); thanks for the heads-up
[12:49]  * Hobbsee twitches at pitti
[12:49] <cjwatson> ogra: I had thought so but apparently not
[12:49] <ogra> cjwatson, ah, that might explain bug 336770 then *g*
[12:49] <cjwatson> ogra: no bugs ever reported on flash-kernel so there can't have been an MIR either
[12:49] <mneptok> asac: your nick always makes me think of notes Spanish-speaking developers write themselves to remind them to lock the house on the way out. ;)
[12:49] <cjwatson> yes, I'll reassign
[12:49] <ogra> right, i'll write one later today
[12:50] <pitti> Hobbsee: http://en.wikipedia.org/wiki/Myers-Briggs_Type_Indicator
[12:50] <asac> mneptok: heh. how does that come?
[12:50] <Hobbsee> pitti: i'm aware.  it was discussed in lecture today, along with a whole lot of other management type things.   it's interesting, but...wow...
[12:50] <mneptok> casa
[12:50] <asac> mneptok: ;)
[12:50] <mneptok>    make food
[12:51] <mneptok>     watch movie
[12:51] <mneptok> asac
[12:51] <asac> mneptok: actually when my nick is not avail, i use asacasa :)
[12:51]  * directhex is chaotic neutral
[12:52] <mneptok> directhex: Chaotic Good FTW
[12:52] <directhex> mneptok, i'm a mono packager, i don't think i'm allowed good alignments
[12:52] <mneptok> directhex: http://www.wilddamntexan.com/kids/demotivators/chaotic_good.jpg
[12:53]  * Keybuk always gets a different result every time he takes one of those tests
[12:59] <Keybuk> mneptok: isn't that just "good" in 4th ed?
[13:00] <mneptok> Keybuk: i still have my First Edition rules. you kids ...
[13:02] <stgraber> seb128: hey, any idea what change in Jaunty's gnome broke the way LTSP makes USB keys and other local medias to work ?
[13:02] <seb128> no
[13:02] <stgraber> seb128: basically mounting something in /media no longer appears on the desktop
[13:02] <seb128> I've not clue about ltsp
[13:03] <ogra> seb128, gvfs used to pick up all mounts that show up in /media, does it still do that ?
[13:03] <stgraber> seb128: LTSP mounts local devices in /media/<USERNAME>/<device name> so something like /media/stgraber/usbdisk-sdc
[13:03] <seb128> ogra: dunno, we got no bug about it not doing that and there is no reason to think that it changed
[13:04] <ogra> well, ltsp is the only thing acutally relying on it
[13:04] <seb128> you guys write a testcase which work on an ubuntu desktop and I will have a look
[13:04] <seb128> I don't plan to a ltsp install for that
[13:04] <ogra> indeed
[13:04] <seb128> hum? on media mounts?
[13:04] <ogra> and thats not needed
[13:04] <seb128> usb keys are mounted there
[13:04] <seb128> I've fstab partitions mounted there
[13:04] <ogra> on gvfs picking it up from the directory change
[13:04] <seb128> wfm
[13:04] <ogra> without hal being involved
[13:05] <seb128> ntfs and usb key are listed
[13:05] <ogra> or dbus ...
[13:05] <ogra> ok
[13:16] <savvas> is nvidia graphics driver 180 in intrepid considered "silent"? it's not present in hardware drivers and many users are wondering why
[13:16] <directhex> savvas, it's a backport. you need to explicitly install the modaliases
[13:17] <directhex> nvidia-180-modaliases package
[13:17] <directhex> possibly also run jockey-gtk -u
[13:18] <savvas> ah... thanks for the tip directhex :)
[13:51] <james_w> for those that were hitting the 2.6 problems with it, a fixed bzr-builddeb has just been synced, sorry for the delay
[13:52] <Keybuk> cjwatson: got that SRU yet?
[13:54] <cjwatson> Keybuk: it's uploaded and waiting for ubuntu-sru to review, I believe
[13:54] <cjwatson> Keybuk: you could pull the patch from the bug and build it
[13:55] <Keybuk> what's the bug#?
[13:55] <cjwatson> 12:02 <cjwatson> Keybuk: see bug 317761
[14:02] <geser> doko: have you some time to look at python-4suite? Building for python2.5 works but with python2.6 setup.py only eats memory and I've no idea how to debug this. A build log is at http://launchpadlibrarian.net/23448421/buildlog_ubuntu-jaunty-amd64.python-4suite_1.0.2-7ubuntu1_FAILEDTOBUILD.txt.gz
[14:03] <doko> geser: there's a bug report about it, not compatible with 2.6. we should repackage this as python2.5-4suite
[14:04] <ScottK> doko: It is problematic though since it has rdepends.
[14:05] <doko> ScottK: yes, however what do you want to do?
[14:05] <ScottK> I want you to fix it?
[14:05] <ScottK> Dunno.  I'm afraid the transition to 2.6 isn't quite as smooth as I'd hoped.
[14:06] <ScottK> jelmer: Are you interested in doing the packaging changes for samaba4 for Python2.6?  I'd rather not be touched-it-last for samba4.
[14:07] <james_w> it's not a trivial one
[14:09] <jelmer> ScottK, shouldn't it just be a binNMU (or whatever the equivalent of that is in Ubuntu)?
[14:10] <ScottK> jelmer: We don't have binNMU, it's all sourceful uploads.  It does look like rules needs a spot of work due to site-packages/dist-packages in 2.6.
[14:12] <directhex> jelmer, ubuntu doesn't have a maintainer per package per se, so there's no "non-maintainer" to upload. however, generally the last guy in changelog gets consulted about the package as a guy who "cares" about it, and i think ScottK would rather someone convenient with an @samba.org address did it instead of him ;)
[14:17] <kirkland> Keybuk: hi, are you around?
[14:17] <Keybuk> always
[14:17] <kirkland> Keybuk: sweet, could you have a look at Bug 71418
[14:18] <maxb> Hi, when proposing a debdiff to a package not currently using a patch system and not currently having any patches outside debian/ dir, is it correct to just patch the package in the traditional directly-in-.diff.gz way?
[14:18] <Keybuk> is there new information on it?
[14:18] <kirkland> Keybuk: yes, i mean my latest comments :-)
[14:19] <cjwatson> maxb: yes
[14:20] <cjwatson> maxb: don't add patch systems to packages that don't have them, generally
[14:39] <pitti> cjwatson: we had the "cdrom in fstab" discussion a number of times already; however, do you think it would be reasonable to at least use /dev/cdrom instead of hardcoded /dev/scd0??
[14:39] <pitti> cjwatson: aside from the fact that the number might change, scd0 is already deprecated again AFAIUI (it's srN now)
[14:40] <Keybuk> right
[14:41] <kirkland> Keybuk: ?
[14:41] <cjwatson> pitti: the installer doesn't hardcode /dev/scd0, actually
[14:42] <kirkland> Keybuk: oh, that probably wasn't for me :-)
[14:42] <Keybuk> kirkland: tab open, please wait ;)
[14:42] <cjwatson> pitti: it uses the device that /cdrom gets mounted on
[14:42] <cjwatson> pitti: which I think comes out of 'list-devices cd'
[14:42] <pitti> cjwatson: right, I expect it detects it, but for the purpose of writing it into fstab I still consider it hardcoding
[14:42] <cjwatson> I could try to check whether there's a symlink pointing there
[14:42] <Keybuk> scd0 is a symlink itself
[14:42] <pitti> cjwatson: maybe easier: if /dev/cdrom exists, put that in, otherwise use the current device name?
[14:43] <cjwatson> scd0 isn't relevant
[14:43] <directhex> there's a /dev/cdrom and /dev/dvd, i wonder if there are blu-ray names. remind me to check
[14:43] <cjwatson> pitti: no, we should check that it matches the device actually in use, in case of multiple drives
[14:43] <Keybuk> cjwatson: be thankful it's even there before ;)
[14:43] <pitti> cjwatson: okay
[14:43] <Keybuk> the scsi cd maintainer was pushing pretty hard to just drop it and only have /dev/sr0
[14:43]  * pitti wishes we could just drop it entirely for desktop installs
[14:43] <Keybuk> directhex: there are not
[14:44] <seb128> I've "/dev/scd0       /media/cdrom   udf,iso9660 user,noauto,exec 0       0" in my fstab which breaks eject of unmounted CDs
[14:44] <directhex> Keybuk, aw. but how else can i feel special about owning a blu-ray drive? :o
[14:44] <pitti> for seb128's problem: eject apparently doesn't resolve symlinks in mount points
[14:45] <seb128> $ eject /media/cdrom0
[14:45] <seb128> eject: tried to use `/media/cdrom0' as device name but it is no block device
[14:45] <seb128> eject: unable to find or open device for: `/media/cdrom0'
[14:46] <directhex> so the bug is with eject, shirley?
[14:46] <Keybuk> well, that's clearly just a bug in eject as well ;)
[14:46] <pitti> absolutely
[14:46] <Keybuk> if it can't found the mount point name, and it's looking at a symlink, it should at least call readlink()
[14:46] <pitti> it just reminded me that we still put it into fstab in the first place, and with hardcoded device names
[14:47] <Keybuk> yeah, the fstab entry is ugly
[14:47] <Keybuk> I also find it odd that it's /dev/scd0 and /media/cdrom0
[14:47] <Keybuk> shouldn't it /media/scd0 ?
[14:47] <Keybuk> (or just /dev/cdrom and /media/cdrom)
[14:49] <seb128> hum
[14:49] <seb128> bug #264071
[14:49] <seb128> pitti: you fixed that symlink bug in intrepid apparently
[14:49] <pitti> seb128: that's what I seemed to remember, but apparently not then
[14:50] <Keybuk> someone sync'd eject
[14:50] <Keybuk>   * Merge to Debian unstable. Remaining Ubuntu changes:
[14:50] <Keybuk>     - Fix eject -T for Macs (ioctl() can return EIO if tray is open). Thanks
[14:50] <Keybuk>       to Andy Matteson for the patch. (LP #91873, Debian #504478)
[14:50] <Keybuk>     - Resolve symbolic links when reading CD-ROM names, to fix "eject -X"
[14:50] <Keybuk>       and possibly other modes. Thanks to Adam Buchbinder for the patch.
[14:50] <Keybuk>       (LP #264071, Debian ##504480, submitted upstream via email)
[14:50] <pitti> it might also have been to resolve symlinks for device names
[14:50] <Keybuk> pitti did a merge
[14:50] <Keybuk> then barely two days later, someone sync'd it
[14:50] <Keybuk> says that pitti requested the sync ;)
[14:51] <pitti>   * Added patches from Ubuntu submitted by Martin Pitt:
[14:51] <pitti>     + Fix cdrom speed detection if /proc/sys/dev/cdrom/info references a
[14:51] <pitti>       symlink. LP: #264071, Closes: #504480
[14:51] <pitti> different symlink :)
[14:55] <seb128> seems a different issue, the log on the debian bug had "eject: error while finding CD-ROM name"
[14:55] <seb128> now it does
[14:55] <seb128> "eject: listing CD-ROM speed
[14:55] <seb128> 24
[14:55] <seb128> "
[14:55] <seb128> not sure what this 24 is about though
[14:58] <Keybuk> eep
[14:58] <Keybuk> should have so done a test reboot before that upload
[15:01] <pitti> Keybuk: you want to say "don't dist-upgrade in the next couple of hours"?
[15:01] <Keybuk> no ;) it's all good
[15:01] <Keybuk> I just should have tested that one :p
[15:05] <Keybuk> kirkland: right, let's look at this bug of yours
[15:06] <kirkland> Keybuk: ;-)
[15:06] <Keybuk> kirkland: ethtool enables wake-on-lan right?
[15:06] <Keybuk> but you still need to not have the -i iirc
[15:07] <Keybuk> otherwise reboot downs the interface, disabling it
[15:07] <kirkland> Keybuk: one of many things that it does, but yes, it can set the WoL mode
[15:07] <Keybuk> extra lines in /e/n/i are passed to the /etc/network/if-*.d scripts
[15:08] <kirkland> Keybuk: I don't disagree with that;  but that alone is not sufficient to solve the problem on my kit
[15:08] <Keybuk> so all you actually need to do is read $WAKEONLAN in /etc/network/if-down.d
[15:08] <Keybuk> .../wakeonlan
[15:08] <Keybuk> or is it up.d?
[15:08] <Keybuk> whichever ifup phase you need ;)
[15:08] <kirkland> Keybuk: cool, that actually sounds pretty straight forward
[15:08] <Keybuk> (it might be $IF_WAKEONLAN actually)
[15:09] <Keybuk> though configuring such things with /e/n/i sounds evil to me
[15:09] <Keybuk> how will that interact with NetworkManager
[15:09] <Keybuk> what about desktops?
[15:09] <Keybuk> etc.
[15:09] <kirkland> Keybuk: hmm, i thought you might say that
[15:10] <kirkland> Keybuk: is NetworkManager able to set the WoL mode?
[15:10] <Keybuk> kirkland: -> asac
[15:11] <kirkland> asac and I discussed this briefly last week
[15:11] <kirkland> asac: around? i did a bit of testing that you asked for, regarding bug #71418
[15:14] <kirkland> cjwatson: question for you, about a bug that i marked as a 'pet-bug' ...  bug #63172
[15:15] <kirkland> cjwatson: i'd like to upload something like this: http://pastebin.ubuntu.com/126749/
[15:15] <kirkland> cjwatson: but i thought i'd check with you first
[15:15] <cjwatson> kirkland: yes, I think that's fine
[15:15] <cjwatson> kirkland: autoindent is known to piss some people off
[15:15] <kirkland> cjwatson: agreed.
[15:16] <asac> Keybuk: for me connection managers dont sound like the right place to set WoL ... which seems to be rather a device thing
[15:17] <asac> i though it could be done in something lower, like udev looking at some config somewhere
[15:17] <asac> thought
[15:17] <cjwatson> kirkland: commented on the bug
[15:17] <kirkland> cjwatson: cheers, thanks much
[15:18] <Keybuk> I HATE YADA
[15:18] <Keybuk> asac: then you need a root helper just to change the config
[15:19] <asac> yeah. still putting it into a connection manager still sounds wrong. anyway, if its done it should be done in a if-*.d/ script, right.
[15:19] <Keybuk> but does NM call those scripts properly?
[15:20] <Chipzz> cjwatson: I have the following snippet in my .vimrc:
[15:20] <Chipzz> " In normal mode, have <Insert> go to insert mode...
[15:20] <Chipzz> noremap <Insert> i
[15:20] <Chipzz> " ...and in insert mode, have <Insert> toggle paste mode (who uses replace anyway?)
[15:20] <Chipzz> set pastetoggle=<Insert>
[15:20] <asac> Keybuk: depends on what is properly for this case
[15:20] <cjwatson> Chipzz: sure, so do I (or similar)
[15:20] <Chipzz> dunnow if that makes sense though as a default
[15:20] <Keybuk> asac: does it parse /e/n/i and pass the variables for the unknown options from it?
[15:21] <Chipzz> Keybuk: what do you mean by "extra lines"?
[15:22] <asac> Keybuk: probably not. which option should be passed in?
[15:23] <Keybuk> asac: all of them
[15:23] <Keybuk> Chipzz: if you put
[15:23] <Keybuk> iface eth0 inet dhcp
[15:23] <Keybuk>   hello-foo bar
[15:23] <Keybuk> then the if-*.d scripts will get $IF_HELLO_FOO=bar passed to them in their environment
[15:24] <Chipzz> that looks rather ambiguous?
[15:24] <kirkland> cjwatson: i'm also going to decline that vimrc syntax-on change for Hardy
[15:24] <kirkland> cjwatson: doesn't seem to rise to the level for SRU, IMHO
[15:24] <asac> Keybuk: i wonder if you ask that because using /etc/network/interfaces is suggested in the bug or because you think thats the right place to configure WoL?
[15:25] <Keybuk> just the former
[15:25] <Keybuk> ie. I don't think ifup is the right place to do it at all
[15:25] <kirkland> yeah, that was purely my crackpot idea
[15:25] <asac> Keybuk: yeah. i dont think its the right place. this was ment to be a workaround for server setup
[15:25] <Chipzz> kirkland: as you're on the topic of vimrc options; what about set background=dark by default to get decent colors in screen?
[15:25] <asac> Keybuk: similar i dont think NM is the right place
[15:25] <cjwatson> kirkland: oh heck yes
[15:26] <cjwatson> kirkland: nominations crack is fairly common
[15:26] <kirkland> Keybuk: asac: it's the first place i would go to as a system administrator to permanently (across interface restarts) change some aspect of my interface's configuration
[15:26] <Keybuk> isn't it something you only want to do when powering down?
[15:26] <Keybuk> "power down and wake on lan"
[15:26] <kirkland> cjwatson: ;-)  cheers.
[15:26] <Keybuk> sounds a bit like "power down and wake for updates"
[15:26] <Chipzz> Keybuk: do options that get recognized by ifupdown also get passed that way, or just the unrecognized options?
[15:27] <Keybuk> and "power down and wake on keyboard press"
[15:27] <kirkland> Chipzz: hmm, dunno about that one
[15:32] <asac> sounds a bit like powermanager should do the root config
[15:42] <superm1> Keybuk, hi.  what's up?
[16:17] <cjwatson> oh joy oh rapture I need a feisty chroot to investigate this bug
[16:18] <directhex> yay feisty!
[16:19] <directhex> isn't feisty dead?
[16:19] <cjwatson> sure, but it's easier to start by reproducing the bug on the same release
[16:19] <cjwatson> unless you have this strange religious belief that bugs magically become obsolete when we EOL releases ;-)
[16:20] <directhex> i do!
[16:20] <cjwatson> odd person
[16:25] <Keybuk> superm1: there's an upload of dkms in the archive that you'll want to merge into your GIT tree
[16:26] <superm1> Keybuk, noted. thanks.
[16:27] <superm1> Keybuk, looking at http://launchpadlibrarian.net/23511372/dkms_2.0.21.1-0ubuntu1_2.0.21.1-0ubuntu2.diff.gz , was there actually anything changed for the second changelog entry?
[16:27] <Keybuk> how do you mean?
[16:28] <Keybuk> oh, weird
[16:28] <Keybuk> where did that go?
[16:28] <Keybuk> dkms isn't generated it is?
[16:28] <Keybuk> *shrug*
[16:29] <Keybuk> superm1: uploaded again ;)
[16:29] <superm1> Keybuk, okay thanks
[16:29] <Keybuk> it's in my test .deb
[16:29] <Keybuk> but not in the source
[16:29] <Keybuk> must have forgotten to run -S again after <g>
[16:31] <ion_> Perhaps dput should be replaced as the preferred tool by something that runs both debuild -S and dput for its result. :-)
[16:31] <ogra_> when did our default for TERM change ?
[16:31] <Keybuk> ogra_: our default for TERM is "linux"
[16:31] <Keybuk> this changed sometime in the 90s
[16:32] <ogra_> ogra@osiris:~$ env|grep TERM
[16:32] <ogra_> TERM=xterm
[16:32] <ogra_> COLORTERM=gnome-terminal
[16:32] <ogra_> ogra@osiris:~$
[16:32] <ogra_> so why is minbe not since i upgraded to jaunty ?
[16:32] <Keybuk> oh, no idea on _that_ one ;)
[16:32] <Keybuk> you didn't say which default <g>
[16:32] <ogra_> i juwst found out thats the reason why my minicom freaks out since the upgrade
[16:32] <Keybuk> TERM=xterm has been the default for every ubuntu release though, no?
[16:33] <ogra_> took me since the sprint to find that
[16:33] <ion_> My gnome-terminal in jaunty seems to have TERM=xterm as well.
[16:33] <Keybuk> (for X)
[16:33] <ion_> Oh, so does my gnome-terminal in intrepid. So no change there.
[16:33] <ogra_> Keybuk, well, then minicom doesnt know about xterm anymore since jaunty or something
[16:33] <Keybuk> minicom should know about everything that terminfo knows about
[16:34] <ogra_> right
[16:34] <Keybuk> you have a /lib/terminfo/x/xterm ?
[16:34] <ogra> yup
[16:36] <Keybuk> ogra: though, WHILE YOU'RE HERE ... ;)
[16:36] <ogra> YES ?!?
[16:36] <Keybuk> ogra: /etc/modprobe.d/fuse
[16:36] <Keybuk> is that one of yours? :p
[16:37] <ogra> not completely, but i added it
[16:37] <Keybuk> I have a few questions
[16:37] <ogra> shoot
[16:37] <Keybuk> what uses /sys/fs/fuse/connections ?
[16:37] <ogra> fusectl iirc
[16:38] <Keybuk> so, I can see why you did it that way
[16:38] <Keybuk> but it's rather broken
[16:38] <Keybuk> for example
[16:38] <Keybuk> try this:
[16:38] <Keybuk> sudo modprobe -f fuse
[16:38] <ogra> feel free to wipe/redo/improve :)
[16:38] <Keybuk> err
[16:38] <Keybuk> sudo modprobe -r fuse
[16:39] <ogra> that doesnt exec the modprobe.d stuff ?
[16:39] <Keybuk> no, try it ;)
[16:39] <ogra> do you promis it wont trash my system ?
[16:39] <Keybuk> I promise
[16:39] <ogra> i havew important stuff going on
[16:39] <ogra> ok
[16:39] <Keybuk> but if it does, you wrote that file <g>
[16:39] <Keybuk> you'll get an error that fuse is in use, right?
[16:40] <ogra> yup
[16:40] <Keybuk> now ls /sys/fs/fuse/connections
[16:40] <ogra> nothing
[16:40] <Keybuk> right
[16:40] <Keybuk> in fact
[16:40] <Keybuk> it's not even mounted anymore
[16:40] <ogra> right
[16:40] <Keybuk> your remove rule unmounts it before attempting to remove the module
[16:40] <Keybuk> but if the module fails to remove, the unmount has still happened
[16:41] <ogra> right
[16:41] <ogra> so the script needs a check
[16:41] <Keybuk> you also don't use $CMDLINE_OPTS there
[16:41] <Keybuk> so any command-line options passed to modprobe for the module will be dropped
[16:42] <ogra> hmm
[16:42] <Keybuk> I can't think of any better way to do what you're trying to do though :-/
[16:42] <Keybuk> you can't do it from a udev rule because you can't remove the fuse module while the path is mounted
[16:44] <ogra> right
[16:44] <Keybuk> remove fuse { if grep -q " /sys/fs/fuse/connections " /proc/mounts; then /bin/umount /sys/fs/fuse/connections; fi } && \
[16:44] <ogra> i tried with a udev rule first iirc
[16:44] <Keybuk>         /sbin/modprobe -r --ignore-remove fuse $CMDLINE_OPTS || \
[16:44] <Keybuk>         { if grep -q fusectl /proc/filesystems; then /bin/mount -t fusectl fusectl /sys/fs/fuse/connections; fi ; : ; }
[16:44] <Keybuk> is what I came up with
[16:44] <Keybuk> of course
[16:45] <ogra> ugh
[16:45] <Keybuk> none of this works if fuse is built into the kernel
[16:45] <ogra> is it yet ?
[16:45] <Keybuk> not yet
[16:45] <Keybuk> but it's worth thinking about
[16:45] <ogra> if its in the kernel we can have fusectl permanently mounted
[16:45] <ogra> thats a non issue then
[16:45] <Keybuk> it's force-loaded in /etc/modules
[16:46] <ion_> Shouldn’t that be modprobe -r || { mount; ... exit 1; } or something to convey the failure?
[16:46] <ogra> right
[16:46] <ogra> ion_, thats what it does ?
[16:46] <Keybuk> ion_: that'd fail the remove and remove the module again I think :p
[16:46] <ogra> oh, the exit
[16:46] <Keybuk> oh, hmm, no idea what it'd do on a failed remove actually
[16:46] <Keybuk> sorry, was thinking in terms of the actual C code there
[16:47] <allquixotic> Well, there goes the rest of my day: http://watchout4snakes.com/creativitytools/RandomParagraph/RandomParagraph.aspx
[16:47] <ion_> I prefixed the remove rule with “exit 1;”. % sudo modprobe -r fuse
[16:47] <ion_> FATAL: Error running remove command for fuse
[16:48] <allquixotic> ion_: Can't remove your fuse module? tried rmmod?
[16:48] <ion_> allquixotic: You missed the context, that error message was intentional.
[16:48] <allquixotic> ah!
[16:48] <allquixotic> yes, I did miss the context
[16:53] <ogra> Keybuk, well, i'd be for including it in the kernel by default
[16:53] <ogra> and make fusectl a kernfs
[16:54] <ogra> we add all users to fuse by default anyway and gvfs makes use of fuse all the time
[16:55] <ogra> no need to keep it modular anymore
[17:26]  * ogra vomits over his crashy X and hugs Keybuk for making reboots reasonably fast at least
[17:28] <Keybuk> they'll get about 10s faster rsn
[17:30] <ion_> How?
[17:30] <ion_> sreadahead?
[17:36] <Keybuk> ion_: new module-init-tools
[17:36] <Keybuk> finally
[17:36] <ion_> Oh, ok
[17:41] <ion_> keybuk: I seem to fail at finding information about what has changed re: speed/performance.
[17:42] <JanC> ion_: IIRC there was something that made modprobe much slower than needed
[17:42] <Keybuk> ion_: https://wiki.ubuntu.com/FoundationsTeam/BootPerformance
[17:42] <ion_> keybuk: Thanks!
[17:42] <Keybuk> not fully up to date
[17:47] <savvas> is there a pykde module I could use that reads /usr/share/locale and /usr/share/locale-langpacks directories?
[17:54] <pitti> bash: x-terminal-emulator: command not found
[17:54] <pitti> le huh?
[17:55] <pitti> oh, argh; go, broken alternatives handling
[18:20]  * Keybuk wonders who the hell Lödur is
[18:36] <pedahzur> Is there anyone doing Qt 4.5 builds for Ubuntu Hardy?  (And planning on doing PyQt4.5 builds for Hardy?)  I want to do some Qt 4.5 work, but I'm not readyto move off of an LTS version.  Should I file a bug and ask for a back-port for those packages?
[18:42] <SyL> anybody use eucalyptus?
[18:43] <highvoltage> aparently colgate uses it in herbal toothpaste
[18:43] <highvoltage> (and aparently ubuntu will too in 9.10)
[18:46] <LaserJock> highvoltage: lol
[18:47] <ScottK> pedahzur: Qt has far too many reverse dependencies to backport.  I can tell you right now I wouldn't approve it.
[18:48] <SyL> I'm just asking about ubuntu's version of eucalyptus is all...
[18:50] <pedahzur> ScottK: Bummer. Thanks, though.
[18:51] <maxb> Can anyone enlighten me on how to build udev packages from the ubuntu packaging bzr? I've got the branch, I've got the orig.tar.gz in ../, but when I dpkg-buildpackage, it spews huge amounts of warnings about unrepresentable changes.
[18:52] <pedahzur> join #kubuntu-devel
[18:52] <pedahzur> oops
[18:53]  * ScottK hands pedahzur a '/'
[18:53]  * ogra hands ScottK a '\' so the / doesnt fall over
[18:54] <ScottK> \o/
[18:55] <ogra> heh
[18:55] <ScottK> Tonio_: Altnernatively the problem is no one uploaded kde4bindings.
[18:55] <cjwatson> maxb: I think you need to use bzr builddeb
[18:55] <ScottK> Sorry wrong channel
[18:56] <cjwatson> maxb: (which basically just chains through to dpkg-buildpackage but with the right options ...)
[18:56] <maxb> cjwatson: that was my second guess, but apparently not - same errors
[18:56] <Tonio_> ScottK: hum... https://edge.launchpad.net/ubuntu/jaunty/+source/kdebindings/4:4.2.1-0ubuntu2
[18:57] <alex-weej> pulseaudio has frequently just killed itself since ubuntu introduced it, and it still happens in jaunty
[18:57] <alex-weej> do we need a process to babysit it?
[18:58] <alex-weej> it's really bad that sound apps sometimes just don't work when you try to launch them
[18:58] <cjwatson> maxb: ok, I think it might be something like -i'(?:^|/)(?:\.bzr|\.git|test/)' then
[18:58] <cjwatson> maxb: IIRC Keybuk had some problems getting bzr builddeb to DTRT
[18:59] <maxb> yikes. Ok, I'll try. I can't imagine that people type that regex every build, though
[18:59] <slangasek> alex-weej: Works For Me; maybe you should file a bug report about your issue
[18:59] <slangasek> as for using a supervisor process... that would almost certainly make things worse.
[19:02] <slytherin> can someone please give back evolution-exchange?
[19:04] <alex-weej> /usr/bin/dbus-launch --exit-with-session /usr/bin/pulse-session /usr/bin/seahorse-agent --execute /usr/bin/gnome-session
[19:04] <alex-weej> is this how we launch our desktop session?
[19:14] <slangasek> alex-weej: yes?
[19:21] <slytherin> can someone please give back evolution-exchange?
[19:34] <jdstrand> kees: do you know what package sets up the sources.list file? specifically, the parts that say '## N.B. software from this repository is ENTIRELY UNSUPPORTED ..."
[19:46] <kees> jdstrand: hrm, I don't -- I would assume it's a d-i template, maybe
[19:48] <slangasek> apt-setup udeb, I think
[19:48] <slangasek> sorry, 'apt-setup-udeb' actually :)
[19:56] <jdstrand> slangasek: cool, thanks
[21:00] <dtchen> alex-weej: please ensure your symptoms for 338377 are not in fact caused by 330814, and try my PPA packages.
[21:02] <alex-weej> dtchen: does pa log anything anywhere that i can check?
[21:02] <dtchen> alex-weej: yes, by default, /var/log/syslog
[21:03] <dtchen> alex-weej: you will likely find it more useful to use `killall pulseaudio;pulseaudio -vvv'
[21:04] <alex-weej> dtchen: ok, i will try and figure it out
[22:15] <SuperQ> So this is probably too late for jaunty
[22:15] <SuperQ> but is there a reason server installs don't include acpid?
[22:15] <slangasek> what do you want acpid for?
[22:16] <slangasek> (we're in the process of trying to get rid of it on the desktop)
[22:16] <SuperQ> hardware event notification
[22:16] <SuperQ> like powerbutton
[22:17] <SuperQ> I'm playing with libvirt/kvm, and I noticed my hardy guests didn't shutdown when asked
[22:17] <SuperQ> but Lenny would
[22:17] <SuperQ> turns out it was that acpid was missing from hardy
[22:17] <cjwatson> SuperQ: https://wiki.ubuntu.com/Hotkeys/Architecture
[22:17] <cjwatson> also https://wiki.ubuntu.com/Hotkeys/Troubleshooting
[22:18] <slangasek> I believe the power button handler is meant to be implemented by hal rather than acpid in jaunty
[22:18] <slangasek> (which is not a hotkey actually, but a some-sort-of-standard ACPI 'button' event)
[22:19] <SuperQ> That sounds like a great solution
[22:19] <SuperQ> yea, psudo-standard event
[22:19] <SuperQ> like standby-button
[22:19] <slangasek> I don't think hal is currently in the server seed either, though
[22:20] <slangasek> and even if it were, hal only handles propagating the event across dbus, it doesn't include anything to act on the event
[22:20] <kees> cjwatson: dpkg is so much prettier with 392317 solved.  quiet postinst scripts shouldn't make themselves known via the dpkg output.  :P  This seems like a good fix to keep.
[22:20] <kees> (that's debian bug 392317)
[22:20] <slangasek> so adding acpid+acpi-support to the servers might be the only possible short-term solution
[22:20] <cjwatson> kees: I actually prefer it the way we have it now
[22:20] <SuperQ> slangasek: hrm
[22:21] <cjwatson> kees: I'd revert to the Debian fix if that was essentially our only remaining dpkg diff, though
[22:21] <cjwatson> kees: that's actually not wildly implausible with the dpkg 1.15 series
[22:21] <slangasek> SuperQ: I would suggest filing a bug on the ubuntu-meta package for this and subscribing the ubuntu server team
[22:21] <Tonio_> hi
[22:22] <SuperQ> slangasek: Sure
[22:22] <Tonio_> slangasek: may I ping about something ? skrooge finally got accepted from NEW? and ended up... nowhere :)
[22:22] <cjwatson> err ... I mean the Debian state, since I don't regard it as a fix :)
[22:22] <Tonio_> slangasek: I have the email confirming it was accepted, btw...
[22:22] <slangasek> Tonio_: it's in universe, dunno why you think it's "nowhere"
[22:23] <kees> cjwatson: cool.  I'm curious about the technical benefit you see with it, since it's always erked me aesthetically
[22:23] <slangasek> Tonio_: I see it in apt-cache policy as well, so it's mirrored successully
[22:23] <SuperQ> slangasek: So this would be a bug against ubuntu-minimal or ubuntu-standard?
[22:23] <slangasek> SuperQ: "ubuntu-meta", bugs are filed by source package :)
[22:23] <slangasek> (so don't worry about the implementation details too much)
[22:24] <Tonio_> slangasek: it just appeared, indeed... sorry for the stupid ping... when I looked a couple of hours ago I couldn't find it (it was accepted yesterday morning...)
[22:24] <SuperQ> slangasek: Ok
[22:24] <cjwatson> kees: I just always found it useful to know which packages actually had postinst scripts and which didn't, when debugging problems
[22:24] <cjwatson> kees: if a package doesn't have a postinst, it saves time going and looking
[22:24] <cjwatson> I don't actually recall the details, but I know that there have been cases where this saved me time :)
[22:25] <kees> cjwatson: just a short-cut to looking in /var/lib/dpkg/info ?  yeah, I guess that can be useful.
[22:25] <TheMuso> /c/c
[22:28] <SuperQ> slangasek: https://bugs.launchpad.net/ubuntu/+source/ubuntu-meta/+bug/36838
[22:28] <SuperQ> slangasek: Matt Zimmerman says: No
[22:28] <slangasek> ah. :)
[22:28] <SuperQ> Not a great answer
[22:28] <SuperQ> I can see the case for not caring about suspend
[22:28] <SuperQ> but powerbutton is a very good use case for servers
[22:29] <ivoks> that's acpid
[22:29] <cjwatson> kees: a shortcut to looking in somebody else's /var/lib/dpkg/info/ when digging through dpkg output in bug reports :)
[22:29] <slangasek> SuperQ: however, the rationale given was about 'power management', which I think overlooks the power button use case
[22:29] <slangasek> SuperQ: so I think it's worth revisiting this
[22:30] <SuperQ> I agree
[22:31] <kees> cjwatson: I remain unconvinced :)  but then I want to have nothing to do with doing dpkg merges, so you can do whatever you like.  :)
[22:32]  * slangasek plays whack-a-mole with the python2.5 server reverse-deps
[22:33] <davismj> where would i go to ask a question about alpha 5 network manager?
[22:36] <RainCT> davismj: try #ubuntu+1
[22:37] <davismj> cool thanks
[22:38] <SuperQ> slangasek: https://bugs.launchpad.net/bugs/338493
[22:39] <slangasek> SuperQ: hmm, I expected we would reopen the old bug, but I guess a bug reference also works. :)
[22:41] <SuperQ> well, the use case is different
[22:41] <ScottK> SuperQ: I'd suggest talking to kirkland about it on #ubuntu-server as he's been investigating power related issues for server recently.
[22:42] <SuperQ> ScottK: Thanks
[22:44] <kirkland> SuperQ: ScottK: hi
[22:44] <SuperQ> :)
[22:44] <ScottK> OK.  or here
[22:45] <kirkland> SuperQ: what's up?
[22:45] <kirkland> (i'm only partially here ...  helping the wife with some chores)
[22:45] <SuperQ> kirkland: I've been playing around with libvirt+kvm
[22:46] <SuperQ> kirkland: One "bug" I found was that ubuntu-server installs don't pick up the acpi power button event by default
[22:47] <SuperQ> kirkland: so when I tell libvirt "shutdown FOO" it doesn't go into init 0
[22:47] <mathiaz> SuperQ: right - install acpid in the guest and the shutdown command will work correclty.
[22:47] <SuperQ> kirkland: Lenny default minimal install includes acpid, which supports the event
[22:47] <SuperQ> mathiaz: Yes, I found this out
[22:48] <SuperQ> mathiaz: I'm arguing for the case that acpid (or powerbutton events) should be include with ubuntu-standard
[22:48] <SuperQ> (Debian does this, I figure why not Ubuntu as well)
[22:52] <slangasek> mm, acpid isn't "standard" on Debian; I'm not sure what would be pulling it in by default
[22:54] <cjwatson> debian-installer/packages/hw-detect/hw-detect.sh:526:   apt-install acpid || true
[22:54] <slangasek> ah
[22:54] <cjwatson> conditional on existence of /proc/acpi
[22:54] <cjwatson> actually, that code is there in Ubuntu as well!
[22:55] <cjwatson> don't suppose somebody who knows about this could go and fix it up? lp:~ubuntu-core-dev/hw-detect/ubuntu
[22:55] <mathiaz> SuperQ: how do you install your guests? Do you enable acpi support in libvirt?
[22:56] <mathiaz> SuperQ: if you start an install with a guest that has acpi support, acpid will automatically be installed.
[22:56] <slangasek> was it there in intrepid?
[22:56] <mathiaz> I think so.
[23:00] <SuperQ> mathiaz: virt-install python script
[23:01] <mathiaz> kees: so I've able to reproduce the openldap issue - one test fails when pie is enabled while it passes when slapd is not compiled with the hardening flags
[23:01] <mathiaz> kees: how should I proceed now?
[23:01] <mathiaz> SuperQ: so you're not using the installer?
[23:02] <SuperQ> mathiaz: I spawn a VM with the ubuntu server ISO as a boot device
[23:02] <SuperQ> mathiaz: Then I go through a normal alternate menu install
[23:02] <slangasek> mathiaz: anything suspicious in the compile-time warnings?
[23:03] <SuperQ> mathiaz: acpi is True
[23:03] <SuperQ> mathiaz: so it should be on when the VM starts up
[23:03] <kees> mathiaz: open an upstream bug report?
[23:04] <kees> anyone know the pythonic form of    blah ? "true" : "false"   ?
[23:04] <mathiaz> slangasek: http://people.ubuntu.com/~mathiaz/trans.1
[23:04] <SuperQ> cjwatson: I don't think the ubuntu version of that is working
[23:04] <SuperQ> cjwatson: Atleast in hardy
[23:04] <mathiaz> slangasek: ^^ this grep translu from the build log
[23:04] <mathiaz> kees: I guess that's the next step. However I'd like to include the compilation flags
[23:04]  * kees nods
[23:05] <mathiaz> kees: reading through the build logs doesn't help me
[23:05] <SuperQ> Ugh, late for a meeting
[23:05] <slangasek> mathiaz: what about grepping 'warning', and filtering out those stupid 'too many arguments for format' warnings that I haven't been able to get rid of (grr)?
[23:06] <kees> mathiaz: -fPIE -pie
[23:06] <mathiaz> slangasek: http://paste.ubuntu.com/126966/
[23:06] <slangasek> kees: blah and "true" or "false"
[23:07] <kees> slangasek: oh.  heh.
[23:07] <mathiaz> kees: should these be in the build logs?
[23:08] <slangasek> mathiaz: I meant over the whole log, without first filtering for translucent :)
[23:08] <mathiaz> kees: because I don't see any PIE/pie in the build logs
[23:08] <slangasek> mathiaz: but is this just the build log on LP?
[23:08] <kees> mathiaz: no, they're forced under the hood
[23:08] <mathiaz> slangasek: it's a local sbuild log
[23:08] <mathiaz> kees: ok thanks.
[23:08] <slangasek> mathiaz: ok
[23:08] <kees> mathiaz: if you want to see the final output, set export DEB_BUILD_HARDENING_DEBUG=1 in the rules dfile
[23:09] <kees> mathiaz: that'll spew the actual gcc command line that hardening-wrapper is generating.
[23:10] <cjwatson> SuperQ: probably because acpid isn't on the server CD
[23:10] <cjwatson> SuperQ: I bet it'd work for netboot installs
[23:11] <mathiaz> slangasek: http://people.ubuntu.com/~mathiaz/openldap_2.4.15-1ubuntu1_20090304-1744 <- 1MB build log of a local sbuild
[23:13] <slangasek> kees: wait, so PIE is being forced on now for all packages?  Does that mean I can drop that bit of delta on the samba package?
[23:14] <kees> slangasek: no, PIE is enabled via native upstream mechanisms in samba.  for openldap (and most other PIE builds) PIE is enabled via the use of the hardening-wrapper package.
[23:14] <SuperQ> cjwatson: Ahhh, that would make sense
[23:15] <slangasek> kees: so the hardening-wrapper package doesn't do anything to builds by default...?
[23:15] <SuperQ> cjwatson: hrm, no, my VM installs do have network access
[23:15] <slangasek> (the 'native upstream' method in Samba isn't particularly interesting, it just adds stuff to the compiler flags AFAIK)
[23:15] <kees> slangasek: correct, it must be enabled with an environment variable in the rules file
[23:15] <slangasek> ah
[23:15] <cjwatson> SuperQ: it's a property of the installation method, not of whether the VM had network access during installation
[23:15] <SuperQ> cjwatson: ok
[23:16] <cjwatson> SuperQ: the installer deliberately only uses packages on the CD at certain points, for CD installs
[23:16] <kees> slangasek: right, but doing PIE builds tends to be non-trivial, so it's nice to have native upstream support.
[23:16] <SuperQ> so it's just a matter of getting the extra deb(s) on the CD
[23:16] <cjwatson> well, only if that's appropriate
[23:16] <kees> slangasek: i.e. you can't just arbitrarily add -fPIE -pie to CFLAGS and everything works out.  :)
[23:16] <cjwatson> the seed change would take care of that automatically
[23:16] <SuperQ> <- thinks so
[23:16] <cjwatson> right, but there seems to be some debate on the subject
[23:16] <slangasek> kees: are we also carrying gdb patches related to PIE?  I would enable PIE in Debian then, except the last time I tried to debug a Samba bug that showed up in Ubuntu but not in Debian, my backtraces with the Debian gdb went all to crap
[23:16] <cjwatson> ... which I don't really want to have to get involved in :)
[23:16] <SuperQ> hehe
[23:17] <SuperQ> well, I'm perfectly willing to get involved
[23:18] <slangasek> mathiaz: heh, there are some very nice hardened warnings in there that we should take a look at some time :/
[23:19] <mathiaz> slangasek: yes. I'm building a package with DEB_BUILD_HARDENING_DEBUG=1 and plan to file a bug with upstream about pie.
[23:20] <mathiaz> slangasek: upstream may be interested at fixing the other issues brough up by the hardening wrappers.
[23:20]  * slangasek nods
[23:21] <slangasek> really nothing that looks like it's related to your bug, though
[23:21] <kees> slangasek: Debian's gdb is not carrying the PIE patches.  Ubuntu's is.
[23:22] <slangasek> kees: right.  upstream and/or Debian prognosis for those patches?
[23:22] <kees> slangasek: Debian's gdb maintainer does not want the PIE patches because they are semi-crack.
[23:22] <slangasek> ... it's gdb
[23:22] <slangasek> how can you tell the difference
[23:22] <kees> slangasek: upstream gdb wants the functionality, but doesn't have time to fix up the patch that Ubuntu, RH, and SuSE carry around for PIE.
[23:22] <slangasek> anyway, I'll defer to Dan's judgement there :)
[23:22] <kees> yeah
[23:25] <jdong> kees: is there a non-crackful way to generate an on-the-fly apparmor profile for executing a single process under, like sandbox-exec() on OS X?
[23:25] <jdong> haha even re-reading the idea sounds like crack :)
[23:27] <kees> jdong: I don't know OSX, but the best I've done for on-the-fly AA profiling is just to use aa-genprof -- run it in "complain" mode until it's done, and then end the genprof run, and it flips to "enforce"
[23:30] <test> in Ubuntu 9.04 for testing we removed eth0, now we are unable to add it back
[23:30] <test> and get an error "Adding connection failed: PolicyKit authorization could not be created"
[23:30] <test> any help ?
[23:30] <test> bdmurray, ping
[23:30] <test> is this a known issue ?
[23:31] <jdong> kees: well I'm working on a crazy easily verifiable middleman for breaking out of the Apparmor confines of Firefox (i.e. to open a download in OpenOffice, for example) and would like to provide an option for "Open with constrained system access" which would launch the helper app with a limited set of privs plus access to the downloaded files
[23:31] <sbeattie> jdong: I've not used sandbox-exec() either, but I'm guessing it's using the systrace tools interactively. That's been a wishlist goal for apparmor for a long time.
[23:31] <jdong> kees: and I guess I just wanted a way to inject an apparmor profile for one binary without having to apply it system-wide or put it in apparmor.d
[23:32] <jdong> sandbox-exec basically would be like "apparmor-run some_profile /usr/bin/foo ...."
[23:32] <jdong> where it would temporarily attach some_profile to foo
[23:32] <kees> jdong: well, you need to be root to add a profile, and the profile is tied to the application across all runs, so I'm not sure what you want exists.
[23:32] <jdong> kees: ah, I guess "it doesn't exist" would be an acceptable answer then.
[23:32] <jdong> it would be nice if available :)
[23:33] <kees> jdong: yeah, sorry about that.
[23:33] <sbeattie> test: I suspect it may be related to bug 312105
[23:33] <jdong> I mean I could always hack something up with (ugh) temp file juggling.
[23:33] <jdong> just trying to work on a solution for the #1 nag with my Firefox AA profile, opening downloaded files.
[23:34] <jdong> having apps launch with Ux arbitrary is obviously not gonna work, having them launch with Px requires a lot of work on my part, ix puts on too tough restrictions for say starting up openoffice.org ;-)
[23:35] <jdong> so my current compromise solution is to have a simple GTK middleman that can be Ux'ed with minimal risk.
[23:37] <test> sbeattie, not sure
[23:39] <sbeattie> jdong: in intrepid's apparmor, you can have an "inner" profile that only applies to a program when invoked from from the surrounding profile.
[23:40] <jdong> sbeattie: I guess what I need is to be able to dynamically supplement/substitute that based on a template of an app the user wants to execute
[23:40] <jdong> but meh it already sounds like more trouble than it would be worth :)
[23:40] <jdong> I'll just stay with unconfined-executes once it gets to the middleman level
[23:40] <jdong> it's the user's (read: my) responsiblity at that point to not be an idiot ;-)
[23:42] <mathiaz> kees: hm - using export DEB_BUILD_HARDENING_DEBUG=1 makes the build fail in a completely different places
[23:42] <mathiaz> *place*
[23:42] <kees> mathiaz: yeah, it's not perfect, some build systems are very sensitive to stderr output
[23:43] <kees> mathiaz: basically, everything building .o's has -fPIE added, and everything building executables has -pie added
[23:44] <mathiaz> kees: ok - thanks. I'll file a bug with upstream and attach the failed build log (but not the hardened_debug =1 one)
[23:45] <sbeattie> jdong: well, it's an interesting problem to solve, IMO. Though I'm not quite sure what solution you're envisioning... feel free to take it to email, if you'd like.