[00:00] <cjwatson> glad we (and Debian) aren't the only ones with that kind of horrible packaging hack ;)
[00:02] <Keybuk> god
[00:02] <Keybuk> now I have to figure out how to do this with cdbs
[00:02] <Keybuk> I don't suppose you know off the top of your head?
[00:03] <ion_> binary-post-install/foo ::
[00:03] <cjwatson> sed -i in ... what ion_ said
[00:03] <ion_>         sed -ire '...' debian/$(cdbs_curpkg)/foo/bar.pc
[00:09] <Keybuk> doesn't work
[00:09] <Keybuk> debian/tmp has been wiped by then
[00:10] <cjwatson> debian/libdbus-1-dev/...
[00:10] <cjwatson> it's been dh_install-ed
[00:10] <Keybuk> it's not referenced by dh_install
[00:10] <Keybuk> literally the whole of debian/tmp is gone, including the directory
[00:10] <Keybuk> I hate CDBS
[00:10] <cjwatson> $ fgrep .pc debian/libdbus-1-dev.install
[00:10] <cjwatson> debian/tmp/lib/pkgconfig/dbus-1.pc usr/lib/pkgconfig
[00:10] <Keybuk> yeah I removed that in an attempt to do the sed ;)
[00:11] <cjwatson> put it back and do 'sed -i blah debian/libdbus-1-dev/usr/lib/pkgconfig/dbus-1.pc' in binary-post-install/libdbus-1-dev
[00:11] <cjwatson> i.e. let it install and then sed in-place
[00:13] <Keybuk> sed: can't read debian/libdbus-1-dev/usr/lib/pkgconfig/dbus-1.pc: No such file or directory
[00:13] <Keybuk> nope
[00:13] <Keybuk> still fail
[00:16]  * Keybuk finds a place that works
[00:17] <soren> I would just put it in install/libdbus-1-dev
[00:17] <soren> When's binary-post-install?
[00:18] <Keybuk> now I ended up with a .pce file ?!
[00:19] <soren> o_O
[00:20] <ion_> Oh, -i must be separated from -e etc.
[00:20] <ion_> As in, sed -i.backup -re '...' something
[00:20] <soren> Oh. Heh.. :)
[00:25] <cjwatson> why bother with -e?
[00:25] <cjwatson> you don't need it
[00:25] <cjwatson> nor do you need -r in the example Keybuk gave
[00:26] <ion_> True. I just have -e as a habit. And -r is kind of a default for me. :-)
[00:26] <ion_> I didn’t really take a good look at the actual sed expression.
[00:27] <cjwatson> it has $ where it should have \$
[00:27] <ion_> Actually, \$$ since it’s in a Makefile.
[00:27] <cjwatson> oh yes
[00:29] <Keybuk> ?
[00:31] <cjwatson> this looks about right
[00:31] <cjwatson> binary-post-install/libdbus-1-dev::
[00:31] <cjwatson>         sed -i 's@-I\$${libdir}@-I$${prefix}/lib@' debian/libdbus-1-dev/usr/lib/pkgconfig/dbus-1.pc
[00:31] <Keybuk> why use ${prefix} there at all?
[00:32] <Keybuk> and why \$ ?
[00:33] <cjwatson> \$ because sed thinks $ means end of line
[00:33] <cjwatson> ${prefix} because the RH code did ;-) and seems neater
[00:37] <Keybuk> install/libdbus-1-dev::
[00:37] <Keybuk> 	mkdir -p debian/libdbus-1-dev/usr/lib/pkgconfig
[00:37] <Keybuk> 	sed -e 's@-I\$${libdir}@-I$${prefix}/lib@' debian/tmp/lib/pkgconfig/dbus-1.pc > debian/libdbus-1-dev/usr/lib/pkgconfig/dbus-1.pc
[00:37] <Keybuk> was what I went with in the end
[00:40] <cjwatson> the version I had was sufficient to get openssh building, at any rate
[00:41] <cjwatson> if yours produces the same .deb contents (as it looks like it should) then we ought to be fine
[00:41] <Keybuk> openssh depends on dbus now? :)
[00:42] <cjwatson> consolekit
[00:42] <Keybuk> sshkit
[00:43] <cjwatson> my Bad Idea light is going off
[00:43] <ion_> At this rate, /bin/sh, init and finally the kernel will use dbus. ;-)
[00:43] <Keybuk> ah, you've screwed it back in after spending a week in the same building as me? :)
[00:44] <Keybuk> ion_: well, two out of three
[00:44] <cjwatson> Keybuk: new filament in the bulb
[00:45] <ion_> keybuk: dbus being actually useful for some of them was actually supposed to be part of the joke. :-)
[00:45] <cjwatson> openssh upstream aren't too happy about the fact that dbus is GPL and openssh is rather aggressively not, which unfortunately I'd completely failed to consider
[00:45] <cjwatson> so I think I need to figure out how to split that stuff out into a helper
[00:45] <Keybuk> dbus is attempting to be MIT
[00:45] <cjwatson> that would help
[00:45] <Keybuk> it's also AFL
[00:46] <cjwatson> the AFL is a bit impenetrable
[00:46] <Keybuk> the MIT thing is held up by one of the companies that contributed having vanished
[00:46] <Keybuk> apparently this is a major stumbling block, because they can't ok it
[00:46] <Keybuk> to my mind, if they've vanished hard enough, they can't take legal action either :p
[00:47] <ion_> Heh
[00:49] <cjwatson> I think (on reading it) that the AFL is MIT-like enough for it not to be a legal problem for Ubuntu; it's literally 10 times the line length though
[00:49] <cjwatson> (which tends to trip openssh upstream's WHATEVER meter)
[00:49] <Keybuk> yes, but openssh is not on the rational side of the world
[00:50] <Keybuk> it belongs in that special camp with other upstreams like glibc
[00:53] <cjwatson> hmm. on re-reading, describing the AFL as MIT-like is definitely false - it requires source code provision
[00:53] <cjwatson> (not that I object but it's one thing the MIT/BSD licences determinedly don't do)
[00:55] <Keybuk> err
[00:55] <Keybuk> not entirely true
[00:55] <Keybuk> it only requires source code provision of the original work when distributing it
[00:55] <Keybuk> it doesn't require source code provision _at_all_ for derivative works
[00:56] <cjwatson> oh, true
[00:56] <cjwatson> ugh, though, clause 9 is horrible
[00:56] <cjwatson> you have to make a "reasonable effort" to obtain explicit assent to the licence
[00:56] <Keybuk> yeah it's a sucky licence
[00:56] <Keybuk> which is why they want to change it to MIT/X11
[00:57] <cjwatson> is there anything I can quote on that, so openssh upstream don't just get fed up and close the bug? :-)
[00:57] <Keybuk> on the relicense?
[00:58] <cjwatson> yeah
[00:58] <Keybuk> lots and lots of ML posts
[00:58] <Keybuk> but the conclusion is that it's stuck still
[01:00] <cjwatson> oh, it's on the website, I can quote that
[01:00] <Keybuk> http://lists.freedesktop.org/archives/dbus/2008-February/009410.html
[01:01] <Keybuk> the current status is that for almost all of the code, the authors have agreed to an MIT/X11 licence
[01:01] <Keybuk> (including us! :p)
[01:02] <cjwatson> ta
[01:13] <Keybuk> random use of bzr #15
[01:13] <Keybuk> import two version of a package
[01:13] <Keybuk> and use bzr blame to figure out which lines haven't been changed
[01:18] <cjwatson> like inverse diff?
[01:18] <Keybuk> yeah
[01:18] <Keybuk> patchutils doesn't have one ;)
[01:19] <Keybuk> /usr/bin/same :p
[01:19] <ion_> Heh
[01:22] <alex1> hello. I've submitted a patch upstream (linux-kernel) for detection of macbook pro 4,1 and macbook air keyboards. It'd be nice if it made it into ubuntu sooner. Should I resubmit it for ubuntu, and if so, where?
[01:27] <Keybuk> ubuntu-kernel
[01:30] <alex1> is that a mailing list? what's the full address? Is there a page that details the patch format for ubuntu etc?
[01:32] <Keybuk> mailing list
[01:32] <Keybuk> same general method as lkml
[01:33] <alex1> hm https://lists.ubuntu.com/mailman/listinfo/ubuntu-kernel says no such list
[01:33] <Keybuk> grep for kernel ;)
[01:34] <alex1> kernel-bugs?
[01:34] <cjwatson> kernel-team
[01:34] <alex1> ok. thanks guys
[01:35] <alex1> new to this stuff... heh
[01:35] <cjwatson> https://wiki.ubuntu.com/KernelGitGuide
[01:37] <alex1> can I just resend the patch I sent upstream?
[01:44] <Keybuk> probably
[01:48] <alex1> done. thanks again :)
[03:14] <cody-somerville> What does it mean when kill -9 won't kill an process? :P
[03:15] <RAOF> It's probably in D state?  It'll be waiting in the kernel, and can't recieve signals at all.
[03:16] <cody-somerville> doh, it is in D state
[03:16] <cody-somerville> Stupid firefox :/
[03:17] <RAOF> Yup.  Unkillable.
[03:17] <cody-somerville> Weird... new applications won't start :/
[03:17] <RAOF> D state makes the baby jesus cry.
[03:18] <cody-somerville> Now all my applications are going into D state :/
[03:18] <RAOF> Right.  Something has died horribly, and the world is ending.
[03:20] <cody-somerville> Reboot is only option?
[03:21] <RAOF> If you can get /sbin/shutdown to not D state, yeah :)
[03:22] <kirkland> slangasek: thanks for merging ;-)
[03:22] <slangasek> n/p
[03:23] <cody-somerville> nooo!!! :(
[03:23]  * cody-somerville just lost the Xubuntu Strategy document draft 2.
[05:52] <DrVague> Good Afternoon.
[05:54] <DrVague> I was sitting briefly, aghast 'n pondrance, and it became notable to one that there is no cron gui management tool, that one of course being me; if you could so explain some burdened parly to me in the form of a hairdresser in silk stockings, I'd be very delighted, or possibly intrigued to find a solution of some sort.
[05:56] <DrVague> ?
[06:04] <lamont> DrVague: that's probably because any gui-driven job scheduler does far more than cron, and the gui comes after the decision that cron is lacking
[06:04] <DrVague> lamont: what?  you're suggest a replacement backend for cron?
[06:05] <DrVague> you're kidding?
[06:05] <lamont> no.  I'm saying that a gui for cron is the least of its issues
[06:05] <lamont> if you expose cron to a gui-requiring user, then you also have to teach him shell scripting...
[06:07] <DrVague> hurrrrr?
[06:07] <DrVague> that doesnt follow for me
[06:07] <lamont> well, what shell commands is he going to put in his crontab?
[06:08] <DrVague> i was thinking he would just use the gui to schedule actual sh scripts to run and set the time with a mouse
[06:08] <DrVague> 'add new job' ::file selection dialog:: 'time'  ::calendar::
[06:08] <lamont> and then the first thing that anyone who's used an actual job scheduler on (say) a mainframe runs into is "how do I tell it to release job B when job A finishes??"  (answer? run a real job scheduler instead of cron, or hack together your own scheduler in the jobs)
[06:08] <DrVague> 'save' 'cancel'
[06:09] <lamont> right.  and someone has to write those shell scripts...
[06:09] <lamont> and whoever writes those generally drops something to run them into /etc/cron.*
[06:09] <DrVague> thats like saying the team who maintains geany should be responsible for teaching everyone perl
[06:10] <lamont> my point is more that anyone who is satisfied with cron in the current world doesn't use a gui, and there is zero motivation to provide one for the developers
[06:11] <DrVague> tbh, cron is used for the same, probably 2 dozen unique job scripts anywhere, a pulldown menu would cover most peoples' needs
[06:11] <lamont> rather, no motivation for the developers to produce one, since the user community divides neatly into the group that doesn't see the need, and the group that would ask lots of questions of whoever wrote the gui.
[06:11] <DrVague> oh, yeah, well that is def true
[06:12] <lamont> which tends to discourage people from bothering with that, when there are far more interesting/significant things to work on that don't immediately become a support nightmare.
[06:12] <DrVague> hrm.  i hate that community gap between devs and recreational users.
[06:12] <dholbach> good morning
[06:12] <lamont> morning dholbach
[06:12] <DrVague> morn'
[06:12] <Mithrandir> morning, lamont, Daniel
[06:13] <lamont> hrm... I think that means it's about bedtime. :-)
[06:13] <dholbach> hi lamont DrVague Mithrandir :)
[06:14] <Mithrandir> lamont: hehe.
[06:14] <lamont> well, given that the workday starts in just under 7 hours...
[06:15] <lamont> hrm.. importing a 300MB, 5900 file cvs repo into a real VCS?   not so fast.
[06:15] <Mithrandir> are you surprised?
[06:16] <lamont> nope
[06:16] <lamont> I just hope it finishes
[06:32] <pitti> Good morning
[06:34] <TheMuso> Morning pitti.
[06:35] <Hobbsee> pitti!
[06:35] <dholbach> hi pitti, TheMuso, Hobbsee
[06:35] <TheMuso> Heya dholbach.
[06:38] <ajmitch> hello pitti
[06:51] <geser> Hi pitti, Hobbsee, TheMuso, ajmitch
[06:52] <wgrant> Anybody got any idea why /dev/mapper contains all of my LVM volumes, but /dev/<VGName> doesn't?
[06:58] <pitti> wgrant: /dev/vgname isn't even supposed to exist, AFAIK
[06:59] <wgrant> pitti: sbuild seems to want it.
[06:59] <wgrant> Well, schroot.
[07:06] <slangasek> don't schroot, I'm unarmed
[07:16] <pitti> Riddell: done now
[07:42] <sdh> hmmm
[07:43] <sdh> if you install slocate and run update-alternatives to select it as the preferred locate (over mlocate)
[07:43] <sdh> then the slocate cron.daily script still doesn't fire because it has the following guard
[07:43] <sdh> if [ -x /usr/bin/slocate ] && [ ! -x /usr/bin/mlocate ]
[07:43] <pitti> sdh: that was done to avoid running slocate on gutsy->hardy (or dapper->hardy) upgrades
[07:44] <pitti> since we don't want/can't automatically uninstall slocate completely
[07:44] <sdh> pitti: interesting... why not consult alternatives and act based on that?
[07:44] <sdh> i did a gutsy -> hardy upgrade, and got mails from cron like this:
[07:44] <sdh> /usr/bin/updatedb.mlocate:/etc/updatedb.conf:4: unknown variable `FINDOPTIONS'
[07:45] <sdh> /usr/bin/updatedb.mlocate:/etc/updatedb.conf:5: unknown variable `export'
[07:45] <sdh> etc... which i assume is mlocate trying to parse slocate configuration
[07:45] <pitti> noone went through that much trouble, I guess, since slocate is basically deprecated
[07:45] <pitti> right, that would be it
[07:45] <sdh> hmm
[07:45] <pitti> sdh: can you please file a bug about it? it's worth it, at least
[07:45] <sdh> pitti: i still have to work out exactly what happened ;-)
[07:45] <sdh> but yeah, sure
[07:46] <sdh> now i'm confused:
[07:46] <sdh> % dpkg -S /etc/updatedb.conf
[07:46] <sdh> mlocate: /etc/updatedb.conf
[07:48] <sdh> i won't file a bug on that until i can understand what is going on
[07:49] <sdh> but i note that somebody said "8.04 uses mlocate instead of slocate on desktops now" -- but it seems it is used on servers too, which imho negates the reasoning behind deprecating slocate in favour of mlocate
[07:49] <sdh> (i.e. affecting user experience especially on laptops)
[07:49] <pitti> sdh: both slocate and mlocate ship this configuration file
[07:50] <pitti> on hindsight, we should have probably made the two conflict to each other
[07:50] <sdh> sounds like a plan
[07:50] <pitti> (we can still do that in -updates, at least)
[07:51] <sdh> cool
[07:51] <Mithrandir> sdh: may I ask why you prefer sloacte?
[07:51] <Mithrandir> slocate, even
[07:52] <sdh> Mithrandir: it's not that i prefer slocate - though i do think, in my case "if it's not broken, don't fix it" - it's that i dislike getting error messages from crond when the locate implementation is changed
[07:52] <Mithrandir> sdh: oh, that I can agree with.
[07:52] <sdh> i see that i've been using mlocate unknowingly on my hardy laptops for the last few months anyway and i have no problem with it :)
[07:54] <Mithrandir> yeah, I can't see anything slocate gives us over mlocate so I was wondering why anybody would want to continue using slocate.
[07:54] <sdh> sentimental reasons ;-)
[07:55] <sdh> oh god the whole mlocate/slocate thing is a mess
[07:55] <sdh> i have /etc/cron.daily/{mlocate,slocate,find}
[07:56] <sdh> i think that's https://bugs.launchpad.net/ubuntu/+source/mlocate/+bug/197170
[07:58]  * sdh wonders why findutils has cron.daily/find doing an updatedb
[07:58] <liw> sdh, so that the locate command is useful; there's been discussions of getting rid of that
[08:00] <sdh> liw: i thought locate (1) was just an alternatives link into mlocate/slocate
[08:00] <sdh> man i am confused now, i have mlocate installed and seem to have no locate (1)
[08:00] <liw> sdh, locate is part of find, and the cron job runs regardless of what the alternatives say (which, as it happens, could be considered a bug: please file one :)
[08:01] <sdh> liw: trying to get my box working first :) any chance you could dpkg -S bin/locate for me please? i appear to have lost mine
[08:03] <sdh> findutils, apparently. odd that i don't have it, then.
[08:03] <liw> I don't seem to have it either
[08:03] <liw> hmm
[08:03] <liw> this seems like a bit of a mess
[08:03] <sdh> yes! b0rkage!
[08:03] <sdh> did you do any mlocate/slocate manual tweaking?
[08:03] <liw> no
[08:04] <sdh> steve@ace:~% dpkg -l '*locate*'
[08:04] <sdh> No packages found matching *locate*.
[08:04] <sdh> steve@ace:~% dpkg -S bin/locate
[08:04] <sdh> findutils: /usr/bin/locate
[08:04] <sdh> actually ignore that, that's a gutsy box! :)
[08:04] <sdh> but the problems i've been discussing are on a hardy (from gutsy) box
[08:05] <sdh> right, having reinstalled findutils it definitely contains no locate(1)
[08:05] <Mithrandir> > dpkg -S bin/locate
[08:05] <Mithrandir> locate: /usr/bin/locate.findutils
[08:05] <Mithrandir> on hardy
[08:05] <sdh> *boggle*
[08:05] <Mithrandir> /usr/bin/locate is handled as an alternative
[08:06] <sdh> ah yes
[08:06] <sdh> % update-alternatives --list locate
[08:06] <sdh> /usr/bin/mlocate
[08:06] <sdh> % locate
[08:06] <sdh> zsh: command not found: locate
[08:07] <sdh> sorry for the pasting btw, is it excessive yet?
[08:07] <Mithrandir> nah, no problem when it's just a line or two at a time.
[08:07] <sdh> ;>
[08:08] <Mithrandir> hm, I think this machine was installed with hardy, not gutsy.
[08:08] <sdh> % dpkg -L mlocate | grep 'bin.*locate'
[08:08] <sdh> /usr/bin/mlocate
[08:08] <sdh> /usr/bin/updatedb.mlocate
[08:08] <sdh> % sudo update-alternatives --config locate
[08:08] <sdh> There is only 1 program which provides locate
[08:08] <sdh> (/usr/bin/mlocate). Nothing to configure.
[08:08] <sdh> % locate foo
[08:08] <sdh> zsh: command not found: locate
[08:08] <Mithrandir> you might need to rehash
[08:08] <sdh> that path is wrong
[08:08] <sdh> steve@nemesis:~% rehash
[08:08] <sdh> steve@nemesis:~% locate foo
[08:08] <sdh> zsh: command not found: locate
[08:08] <sdh> ;)
[08:08] <sdh> it's the path in the alternatives
[08:09] <Mithrandir> what does ls -l /etc/alternatives/locate say?
[08:09] <sdh> or, hang on
[08:09] <Mithrandir> lrwxrwxrwx 1 root root 16 2008-04-03 15:21 /etc/alternatives/locate -> /usr/bin/mlocate*
[08:09] <Mithrandir> is what I have
[08:09] <sdh> erk!
[08:09] <sdh> % ls -l /etc/alternatives/*locate*
[08:09] <sdh> lrwxrwxrwx 1 root root 16 2008-05-30 07:42 /etc/alternatives/locate -> /usr/bin/slocate
[08:10] <Mithrandir> try update-alternatives --auto locate ?
[08:10] <sdh> that seems to have fixed it
[08:10] <sdh> but why is u-a telling me it points to mlocate when it points to slocate, i wonder?
[08:10] <Mithrandir> it's not, it's just telling you there's nothing to configure
[08:11] <sdh> good point >
[08:11] <Mithrandir> I wonder if this is really an update-alternatives bug.
[08:11] <sdh> i am inclined to agree
[08:11] <Mithrandir> can you try installing slocate, changing the alternative to point to slocate, verify it's in manual mode pointing to slocate, then purge slocate?
[08:11] <sdh> it shouldn't say "only 1 program, nothing to configure" if it is in fact handling it, badly :)
[08:11] <Mithrandir> and then see what it points to?
[08:12] <sdh> though i'm reluctant to keep screwing with my production boxes... sure! :)
[08:12] <sdh> Mithrandir: step 2 using u-a --config locate, right?
[08:12] <Mithrandir> yes
[08:12] <Mithrandir> no manual hacking in /etc/alternatives. ;-)
[08:13] <sdh> Using '/usr/bin/slocate' to provide 'locate'.
[08:13] <sdh> lrwxrwxrwx 1 root root 16 2008-05-30 08:12 /etc/alternatives/locate -> /usr/bin/slocate
[08:13] <sdh> now to purge
[08:13] <soren> Mithrandir: Why not?
[08:13] <sdh> % sudo update-alternatives --list locate
[08:13] <sdh> /usr/bin/mlocate
[08:13] <sdh> lrwxrwxrwx 1 root root 16 2008-05-30 08:13 /etc/alternatives/locate -> /usr/bin/mlocate
[08:14] <sdh> seems good now
[08:14] <Mithrandir> soren: in this case, because I want to see if u-a DTRT.
[08:14] <soren> Mithrandir: Oh :)
[08:14] <Mithrandir> sdh: hmm, ok.
[08:14] <sdh> Mithrandir: strange though...
[08:14] <sdh> Mithrandir: would you expect an apt-get remove, without --purge, to update alternatives?
[08:14] <sdh> Mithrandir: let me try that again without purge.
[08:14] <Mithrandir> sdh: sure, try.  I think it should.
[08:15] <Mithrandir> since you should never be left with a dangling alternatives symlink.
[08:15] <Mithrandir> but you said you were left without /usr/bin/locate at all, or was it just dangling?
[08:15] <sdh> hmm that seemed to work too, odd.
[08:16] <sdh> Mithrandir: hard to tell, now that i've messed about! it gave me no such f/d, but that could be either
[08:16] <sdh> looks to me like it's just a gutsy/hardy upgrade quirk
[08:17] <sdh> but it does feel like a can of worms, including *locate and even u-a
[08:17] <Mithrandir> you don't happen to have a backup of the system you could take a look at a directory listing from?
[08:17] <sdh> and i definitely think that mlocate/slocate should be mutex
[08:17] <Mithrandir> yeah, it looks like it might be ordering dependent.
[08:17] <sdh> Mithrandir: not in any kind of realistic timescale, afraid not
[08:17] <Mithrandir> which is.. ugh.
[08:17] <Mithrandir> ok.
[08:19] <sdh> thanks for helping out
[08:19] <Mithrandir> oh, happy to help; I still wonder how we can get it properly fixed though.
[08:20] <sdh> yeah but it's at that awkward stage where i'm not sure how to reproduce the problem
[08:20] <Mithrandir> it might be related to /usr/bin/locate being a proper file in gutsy.
[08:20] <sdh> i'm not even 100% sure what the problem was
[08:21] <sdh> i have to get to work soon... but i suppose i have time to break out a few VMs :)
[08:21] <Mithrandir> if it's present on a stock install + upgrade, it should be fairly easy to see what's happening.
[08:22] <sdh> i conveniently have a gutsy template vm
[08:31] <sdh> right Mithrandir... i have a gutsy box ready for upgrade to hardy
[08:32] <sdh> i'll install slocate then do the upgrade
[08:32] <sdh> sound like a reasonable test to you?
[08:33] <Mithrandir> sounds good
[08:33] <sdh> just to confirm, on gutsy /usr/bin/locate is a symlink to /usr/bin/slocate
[08:33] <sdh> (with slocate installed, obviously)
[08:34] <Mithrandir> *nod*
[08:34] <sdh> before that it was provided by findutils
[08:40] <sdh> it's chugging away :)
[08:41] <dolphin> how would i go about messing with [remapping] keys
[08:53] <sdh> Mithrandir: well it came back with mlocate installed and slocate uninstalled, which i guess is right
[08:53] <sdh> and the alternatives link points to mlocate
[08:53] <sdh> ...so it all seems ok.
[08:57] <Mithrandir> hmm
[08:57] <Mithrandir> so it's.. something else or harder.
[08:58] <pitti> seb128: WDYT about bug 182945?
[08:58] <pitti> seb128: no reverse dependencies
[09:01] <seb128> pitti: it should have been removed before hardy, that was a temporary package for gio before having it in glib
[09:01] <pitti> seb128: merci; removing then
[09:01] <seb128> thanks
[09:02] <seb128> pitti: I just uploaded a new rhythmbox revision, I attached the debdiff to one of the zillion bugs it closes, is that good enough or should it be attached to all of those?
[09:02] <pitti> seb128: one is enough
[09:03] <dolphin> what's the best way to learn how to program?  i've taken a basic college course in C & C++, but I wanna look at real programs... even if they're mildly confusing at first
[09:03] <dolphin> any suggestions?
[09:11] <dolphin> what program has easy to read source code for a n00b??
[09:12] <sdh> dolphin: there's a good book... let me find it
[09:12] <sdh> http://www.spinellis.gr/codereading/
[09:16] <dolphin> sdh:  aww, man... you gotta pay for the whole thing?!?  =-(
[09:17] <sdh> dolphin: it's worth it
[09:18] <liw> dolphin, pick a program in Ubuntu that interests you, then do "apt-get source foo" to get the source, and have at it; it's probably best to pick a simple command line utility to start with, they tend to be simpler
[09:18] <sdh> fileutils or something is interesting
[09:18] <sdh> and easy to see how code relates to runtime
[09:18] <dolphin> yea, i was thinking graphical... but text is definitely a better start
[09:19] <sdh> dolphin: if you want graphical then you have to get familiar with the intricacies of whatever graphical toolkit is being used, be it gtk/qt/etc
[09:19] <liw> dolphin, the coreutils package might be a start, for example: cat, rm, cp, and such, although they have a lot of complexity by having to deal with all sorts of quirks in various Unix flavors
[09:19] <sdh> dolphin: that is hardy, so i'd start with text
[09:19] <sdh> err, s/hardy/harder/
[09:19] <liw> findutils is a good choice
[09:20] <dolphin> $51 isn't that bad, i guess i'll order that book to keep me from getting too bored this summer
[09:20] <sdh> dolphin: it seems there is a sequel but i haven't read that
[09:21] <dolphin> what is fileutils?
[09:21] <sdh> dolphin: but code reading is a good book because it talks you through various idioms in real software (e.g. apache, netbsd) that means you can make the leap from understanding, say, C syntax, to being able to understand large chunks of code
[09:21] <sdh> dolphin: sorry, i meant coreutils i guess
[09:21] <dolphin> ahh... k
[09:21] <sdh> the package with head/tail/wc etc
[09:22] <dolphin> this is definitely the starting point i'm looking for... i'm tired of simple labs
[09:22] <sdh> right
[09:22] <sdh> so between apt-get source and that book, i'd say you could spend a lot of useful time understanding and then modifying code
[09:22] <dolphin> thanks for the recommendations, ya'll!
[09:22] <sdh> np
[09:23] <dolphin> gonna catch some ZZZzz's for now.... lata
[09:23] <dolphin> thanks again!
[09:23] <liw> the nice part of going to apt-get source way is that you can easily modify code too, and try out your modifications for real
[09:23] <liw> (running, say, your modified corutils in a virtual machine may give additional confidence)
[09:38] <james_w> pitti: there's a packagekit discussion going on about offering to install relevant drivers when a piece of hardware is plugged in, does jockey take care of that for us?
[09:39] <james_w> I mean does it get triggered by hal, or does it just scan at startup?
[09:39] <pitti> james_w: not quite yet, but getting there
[09:39] <pitti> james_w: ATM it just scans at session start
[09:39] <james_w> so it's planned, and I can ignore trying to implement it for packagekit?
[09:39] <pitti> james_w: but for 0.5 I plan to hook it into hal
[09:39] <james_w> thanks
[09:39] <pitti> james_w: yes, pretty much; we'll do it the other way round, we'll use PK to install the drivers from jockey :)
[09:40] <james_w> heh, works for me :-)
[09:40] <pitti> james_w: and jockey will go into Fedora soon, too
[09:40] <pitti> so I'm not even sure whether they should do that in PK itself (one tool for one purpose, etc.)
[09:40] <pitti> but *shrug*
[09:40] <james_w> oh, cool. Apport as well, they're loving your code.
[09:52] <james_w> pitti: <hughsie> james_w: atm, gnome packagekit has a GpkFirmware GObject that watches udev for missing firmware requests and prompts to install it if finds then in a source
[09:52] <james_w> sorry to keep bothering you
[09:52] <pitti> james_w: (no problem)
[09:52] <pitti> james_w: that sounds nice; however, our packages don't support that ATM
[09:52] <pitti> james_w: most firmware should already be present in l-r-m
[09:53] <pitti> and if someone uninstalls l-r-m, he won't want the non-free firmware IMHO
[09:53] <pitti> so that doesn't really work for/apply to us
[09:53] <pitti> ATM, at least
[09:56] <|DuReX|> https://bugs.launchpad.net/ubuntu/+bug/235889
[09:56] <|DuReX|> if somebody wants to look @ it :)
[10:08] <james_w> pitti: sorry, last question I hope, hughsie is interested to speak to the Fedora folks that you have been in contact with to find out what their plans are, could I pass on a name to him?
[10:08] <pitti> james_w: sure, that's Jon Masters (RedHat employee)
[10:09] <james_w> thanks
[10:09] <pitti> james_w: he and I are members of the LinuxFoundation driver backports workgroup, we work together on the tools in that context
[10:36] <soren> wtf..
[10:37] <soren> Are moves of packages between components logged?
[10:38] <cjwatson> not really
[10:38] <cjwatson> you can see that something happened
[10:39] <cjwatson> e.g. https://launchpad.net/ubuntu/+source/db4.4 has both "Published" and "Superseded" for the same version (4.4.20-11)
[10:39] <soren> Ah, interesting.
[10:39] <cjwatson> (I think that indicates a publishing record change)
[10:40] <soren> No such luck on https://edge.launchpad.net/ubuntu/+source/nagios2
[10:40] <soren> in spite of https://bugs.edge.launchpad.net/ubuntu/+source/nagios2/+bug/211323
[10:44] <pitti> bryce: x-intel SRU upload does not have a LP # for tracking verification; can you please reupload and mention it in the changelog?
[10:44] <bryce> done
[10:44] <pitti> wow, that was fast :)
[10:44] <bryce> pitti: yeah I realized I'd forgotten it right after uploading
[10:45] <bryce> btw, the other quirk is a fix for bug 235155, which is a private bug
[10:45] <bryce> dunno if it's appropriate to list private bugs in srus or not
[10:46] <pitti> bryce: bug 235643 is public
[10:46] <pitti> bryce: the diff itself looks fine, so if there's at least one bug to say "yes, this .deb still works for me", that's enough for SRU purposes
[10:46] <pitti> bryce: the quirks themselves are probably fine
[10:46] <bryce> ok great
[10:48] <pitti> ogra: heh, ltsp fix-o-rama :)
[10:49] <wgrant> soren: It was never promoted. https://edge.launchpad.net/ubuntu/+source/nagios2/+publishinghistory shows all publishing records ever.
[10:49] <pitti> ogra_: can you please add hardy/intrepid tasks and pointers/attachments to the patches?
[10:49] <ogra> pitti, ?
[10:50] <ogra> oh ltsp you mean ?
[10:50] <pitti> yes
[10:50] <ogra> will do, one sec
[10:50] <pitti> ogra: danke; please also say whether they are fixed in intrepid, etc (intrepid task status)
[10:50] <soren> wgrant: Oh, that's handy. Thanks.
[10:51] <wgrant> soren: Only nagios-plugins was promoted - I guess pitti misread something...
[10:51] <soren> wgrant: They were handlede completely separately.
[10:52] <wgrant> nagios-plugins was mentioned a comment or two before the end, and I've had this sort of thing happen once or twice before.
[10:52] <pitti> wgrant: context?
[10:53] <wgrant> pitti: nagios2 was never promoted, though you said you did it. Bug #211323
[10:53] <liw> hrmph, reportsync isn't working for me
[10:54] <liw> er, requestsync, rather
[10:54] <soren> liw: Maybe because it's called..
[10:54] <soren> oh.
[10:54] <pitti> wgrant: hm; "oops"
[10:54] <liw> I edit the message template. I save it. requestsync doesn't notice and signs the unedited file.
[10:54] <pitti> wgrant: promoted in intrepid now; that doesn't really help hardy, of course :/
[10:56] <wgrant> soren: ^^
[10:56] <soren> pitti: I think the main problem (har har) is that component-mismatches is full of noise, so it's hard to notice when stuff like this pops up in there.
[10:56] <pitti> soren: yeah :/
[11:00] <pitti> seb128: voila, all gnome SRU stuff done
[11:01]  * seb128 hugs pitti, you rock!
[11:02] <liw> hm, it works with nvi, but not with my own editor... weird
[11:05] <seb128> pitti: is that normal that the sru page has a language-pack-en entry without a bug number?
[11:05] <liw> or at least it presented me the right file having been signed, but then it seems stuck after I press enter to actually file the bug
[11:05] <liw> socket.error: (110, 'Connection timed out')
[11:05] <liw> bah
[11:06]  * liw goes to file bugs manually
[11:09] <liw> hmm... actually, it's probably because outgoing port 25 is disabled
[11:11] <liw> if requestsync would use my local MTA, it should work
[11:15] <liw> and there is a way to do that, which is not documented in the manpage
[11:15] <ogra> pitti, they all got hardy tasks ... i cant do much about the intrepid nomination yet as there was no ltsp upload to intrepid yet
[11:15] <james_w> liw: there's a --lp option that files over http if you have python-launchpad-bugs installed.
[11:16] <liw> james_w, yeah, but that's scary :)
[11:16] <ogra> Pici, (and especially jwz's toy bug #199675 is a bit tricky here)
[11:16] <liw> james_w, I'll try it next time, though
[11:17] <liw> and am putting fixing the manpage on my todo list
[11:20]  * |DuReX| looks sweet to the devs -- https://bugs.launchpad.net/ubuntu/+bug/235889
[11:24] <pitti> ogra: I added the missing one to 224259, rest is fine; but still no patches...
[11:25] <pitti> ogra: I'll read the debdiff first, and get back to you with questions if I can't figure it out
[11:25] <pitti> but having patches/bazaar.lp.net URLs are a great help for fast processing
[11:26] <ogra> ah well ... i was suppposed to hop on a train now ... but since i missed that anyway i can as well split the patches ...
[11:26] <pitti> ogra: ah, debdiff is relatively small, so don't bother for now
[11:29] <ogra> they are all separately in ltsp upstream bzr anyway
[11:29] <ogra> (or will go there for the ones tat arent yet)
[11:30]  * ogra hugs pitti 
[11:38] <Mirv> calc: are you aware that the OOo in hardy-proposed breaks (deinstalls) a) OOo localizations b) openoffice.org-voikko extension (part of language-support-fi)
[11:40] <Mirv> bug 236010 has been seemingly filed
[11:40] <norsetto> pitti: do the archive admins use a tool to check to which section (universe/multiverse/etc.) a package should pertain?
[11:43] <cjwatson> norsetto: yes
[11:43] <cjwatson> norsetto: packages are seeded, seed dependencies are expanded, discrepancies are reported in the component-mismatches.txt output
[11:44] <norsetto> cjwatson: ah thanks! I'm asking because of bug 214727, I'm wondering if I should do something more (or less ...)
[11:45] <cjwatson> oh, we don't have any automatic tracking of universe vs. multiverse
[11:45] <cjwatson> I'm afraid that's just done by bug reports
[11:45] <cjwatson> nothing more needs to be done for that bug though
[11:45] <norsetto> cjwatson: ok, thx
[11:50] <Mithrandir> cjwatson: in hardy, the highlighting done when searching in man pages seems off; do you have a bug about this or should I report it?
[11:50] <cjwatson> bug in whatever pager you're using
[11:50] <cjwatson> I've seen that with less too, but not got round to reporting it
[11:50] <Mithrandir> are you sure it's not man-db?
[11:50] <cjwatson> yes
[11:50] <Mithrandir> ok
[11:50] <cjwatson> well, reasonably
[11:50] <Mithrandir> it's less, yes.
[11:50] <cjwatson> nothing relevant in man-db has changed
[11:51] <Mithrandir> grep seems to highlight the right bit, so I suspect you're right.
[11:51] <cjwatson> man does pass some funky options to less, so you might not see it in other documents
[11:52] <cjwatson> those options last changed in 2002
[11:52] <Mithrandir> heh, ok.
[11:55] <emgent> morning
[11:56] <bryce> http://www.oooninja.com/2008/05/openofficeorg-getting-faster-benchmark.html
[11:56] <bryce> "In conclusion, OpenOffice.org is generally getting slower with each release. However, startup performance has made great improvements, the performance losses are relatively small, advances in new computer hardware are more than making up the loses, and OpenOffice.org continues to mature with new features."
[11:58]  * cjwatson vomits all over http://bazaar.launchpad.net/~ubuntu-core-dev/net-retriever/ubuntu/revision/349
[11:58] <cjwatson> how many impediments could there possibly have been to a simple bug-fix
[12:01] <Mithrandir> cjwatson: why not just add --compare-versions to udpkg?
[12:01] <cjwatson> don't feel like doing that for hardy-proposed ...
[12:01] <Mithrandir> oh, good point.
[12:01] <Mithrandir> I thought it was for i*
[12:02] <Mithrandir> why vergt, btw?
[12:06] <cjwatson> don't need a generalised vercmp there and I don't want to encourage anything else to rely on it
[12:06] <cjwatson> I'll look at adding it to udpkg though
[12:23] <lool> persia, mvo: update-manager-hildon needs python-vte; would one of you please confirm this is the only missing bit and add it to the u-m trunk?
[12:25] <persia> lool: Looking now...
[12:27] <lool> For some reason, sudo is borken in one of my envs, can't test directly
[12:28] <ogra> hostname issues ?
[12:28] <pitti> seb128: ah, seems I'm not the only one with this problem: bug 227994
[12:31] <lool> ogra: Could be, not quite sure what the rules are; u-v-b seems to create a 127.0.1.1 ubuntu.$mydomain ubuntu in /etc/hosts and hostname reports ubuntu
[12:31] <ogra> lool, try dropping ubuntu.$mydomain from that line and just keep ubuntu
[12:32] <ogra> though sudo tells you if the prob is caused by gethostbyname() if its realy a resolving issue
[12:34] <lool> Can one loopmount qemu qcow2 files?
[12:35]  * lool lunch &
[12:37] <ogra> pitti, i saw some complaints about keymaps not being properly re-initialized after resume on the ubuntu-users ML since we switched to pm-utils ... that might be related
[12:37] <pitti> ogra: I tried both en and de layouts, that's not it
[12:37] <ogra> even though its weird that they say "leave message" works as expected
[12:38] <pitti> ogra: the same happens with src/test-passwd
[12:38] <pitti> and I verified in gdb that the password is correct
[12:38] <pitti> currently gdb'ing it
[12:38] <ogra> weird
[12:38] <pitti> ogra: you don't need a password for that
[12:38] <pitti> ogra: 'login as another user' works, too (but that's gdm again)
[12:38] <ogra> right, not gss
[12:38] <pitti> ogra: so the g-s lock dialog works for you?
[12:38] <ogra> let me try
[12:39] <pitti> gnome-screensaver-command -l
[12:39] <pitti> or ctrl+alt+l or so
[12:39] <pitti> May 30 13:30:58 donald gnome-screensaver-dialog: pam_unix(gnome-screensaver:auth): conversation failed
[12:39] <pitti> May 30 13:30:58 donald gnome-screensaver-dialog: pam_unix(gnome-screensaver:auth): auth could not identify password for [martin]
[12:39] <pitti> is what I get
[12:39] <ogra> yes, works fine after suspend
[12:39] <pitti> ogra: ok, thanks for trying
[12:40] <ogra> do you have an upgraded system ?
[12:41] <ogra> this laptop was a new hardy install
[12:41] <pitti> ogra: both my desktop and my laptop are fresh hardy installs, and it happens for both
[12:41] <ogra> meh
[12:41] <ogra> oh
[12:42] <ogra> my auth log looks itrestingly different
[12:42] <ogra> May 30 13:39:31 osiris gnome-screensaver-dialog: gkr-pam: unlocked 'login' keyring
[12:43] <ogra> smells like a communication error between gss and gkr
[12:44] <pitti> hm, it doesn't use unix_chkpwd??
[12:44] <pitti> how the heck is it supposed to be able to verify my password then?
[12:44] <pitti> it calls PAM directly, as my user
[12:44] <pitti> without shadow privileges
[12:45] <pitti> ogra: is /usr/bin/gnome-screensaver root:root 0755 for you?
[12:45] <seb128> pitti: does it happen every time for you?
[12:45] <pitti> seb128: yes, it has never worked in hardy
[12:46] <pitti> first thing I do after login is 'killall gnome-screensaver'
[12:46] <seb128> urg
[12:46] <seb128> we would have received lot of complain if that was happening to everybody for sure
[12:46] <seb128> do you configure something special in your boxes?
[12:46] <pitti> right, that's why I didn't treat it as OMGPONIES
[12:47] <pitti> seb128: not that I know of (pam-wise)
[12:47] <pitti> still debugging
[12:47] <seb128> pitti: I can get debug informations on my working systems if you need something to compare
[12:47] <pitti> /* #undef PASSWD_HELPER_PROGRAM */
[12:47] <pitti> ^ in my config.h
[12:48] <pitti> unix_chkpwd can be passed as a configure argument
[12:48] <ogra> ogra@osiris:~/Devel/packages/ltsp-5.0.40~bzr20080212$ ls -l /usr/bin/gnome-screensaver
[12:48] <ogra> -rwxr-xr-x 1 root root 134532 2008-04-09 17:06 /usr/bin/gnome-screensaver
[12:48] <pitti> but isn't
[12:48] <mantiena> hello all
[12:50] <pitti> seb128: I'm still stunned how g-s-s is supposed to verify passwords without using unix_chkpwd and without being sgid shadow
[12:50] <pitti> seb128: do you happen to have a built gnome-screensaver tree? does src/test-passwd work for you?
[12:50] <seb128> pitti: trying
[12:51] <mantiena> cjwatson: I have some questions about ubiquity's netboot support - do you have some time to answer ?
[12:52] <mantiena> I found, that blueprint﻿﻿ https://wiki.ubuntu.com/Ubiquity/Automation is implemented already
[12:52] <pitti> seb128: ah, nevermind; it does run execve("/sbin/unix_chkpwd", ["/sbin/unix_chkpwd", "martin", "nullok"], [/* 0 vars */])
[12:53] <cjwatson> mantiena: depends on the questions, I'm trying to meet 8.04.1 deadlines at the moment
[12:54] <seb128> pitti: the test-passwd thing works fine here
[12:54] <mantiena> cjwatson: So, I'm asking: there is one important (for me) sentence in that blueprint: "To support netbooted installations, we will ensure that the existing casper support for netbooting works properly (it is believed to have some bugs)..."
[12:54] <pitti> seb128: ok, thanks; mind to try something else?
[12:54] <cjwatson> mantiena: I'm afraid I'm not up to date on that; I suggest asking evand
[12:54] <seb128> pitti: I'm happy to debug it with you
[12:54] <pitti> seb128: echo 'yourpasswd' | /sbin/unix_chkpwd yourlogin nullok
[12:54] <cjwatson> he was responsible for that specification
[12:54] <pitti> seb128: while watchign tail -f /var/log/auth.log
[12:54] <pitti> May 30 13:54:15 donald unix_chkpwd[29021]: check pass; user unknown
[12:54] <pitti> May 30 13:54:15 donald unix_chkpwd[29021]: password check failed for user (martin)
[12:55] <pitti> so, unix_chkpwd itself seems to be broken
[12:55] <mantiena> cjwatson: ok, so, you don't know if casper and ubiquity would work if booting from network (on computers without CD/DVD drivers) ?
[12:56] <pitti> aaargh *headdesk*
[12:56] <pitti> -rw-r----- 1 root root 1470 2008-05-30 13:55 /etc/shadow
[12:56] <seb128> pitti: same error
[12:56] <cjwatson> mantiena: not without trying it, no
[12:56] <mvo> lool: added to trunk and uploaded to intrepid already :)
[12:56] <seb128> pitti: it's root shadow 640 on my install
[12:56] <pitti> right, as it should be
[12:57] <seb128> pitti: any idea why it's different for you?
[12:57] <elmo> hmm
[12:57] <mantiena> cjwatson: thanks for info, I will talk with evand
[12:57] <mantiena> evand: hi, are you online ?
[12:57] <pitti> seb128: yes, indeed I have; I blame my 'restore my configuration from bzr after install' script, which probably doesn't restore the permissions
[12:57] <pitti> seb128: bzr doesn't save group membership
[12:57] <pitti> seb128: so, sorry for the noise
[12:58] <seb128> ah ok
[12:58] <seb128> iz pitti bug
[12:58] <seb128> ;-)
[12:58] <pitti> works fine now
[12:58] <persia> mvo: The other thing I found looking it over is that it needs the versioned dependency on update-manager-core to get the more flexible DistUpgrader
[12:59] <elmo> pitti: thanks very much, that just helped me fix one of the admin pcs
[12:59] <pitti> elmo: hah, /etc in bzr, too? :-)
[13:00] <pitti> in fact it's not due to bzr, it's due to my 'postinst-setup' script which only adds the real users from teh backup to shadow, but keeps the system bits
[13:01] <elmo> pitti: no, someone messed up group ownership when they were r00ting it
[13:10] <charliecb> ﻿i want to download my photos from an canon ixus  80 with nautilus. since gnome 2.22, there should be an option for gphoto2. enter in nautilus gphoto2:// . but that doesn't work. i can import photos, but i can't use nautilus to see all photos from the camera. see http://library.gnome.org/misc/release-notes/2.22/index.html.de. is gphoto2 not compiled into nautilus?
[13:11] <pitti> dpkg: ../../src/packages.c:265: process_queue: Assertion `!queue.length' failed.
[13:11] <pitti> Aborted (core dumped)
[13:11] <pitti> yay intrepid's dpkg
[13:12] <seb128> charliecb: it's not compiled in the hardy gvfs no
[13:12] <cjwatson> pitti: test case?
[13:12] <cjwatson> though, er, maybe after 8.04.1 deadline
[13:12] <charliecb> seb128: do you know why not?
[13:13] <pitti> cjwatson: trying to construct one
[13:13] <seb128> charliecb: the current applications doesn't understand the gphoto uris, so you can't open an image by clicking on it and the gvfs mount lock the access to the device so you can't use an another application to download those
[13:14] <charliecb> seb128: ok. thx
[13:14] <seb128> you are welcome
[13:15] <pitti> cjwatson: ah, seems to happen on "dpkg: too many errors, stopping"
[13:17] <ogra> Amaranth, hey
[13:17] <Amaranth> hey
[13:19] <pitti> cjwatson: filed as bug 236047; I try it in sid now, too
[13:20] <pitti> yup, it's in sid, too
[13:21] <ogra> Amaranth, do you mind me taking over packaging etc for wilow during intrepid or do you prefer to be my upload bitch ? i added a branch to the upstream project which already carries a good bunch of changes
[13:21] <cjwatson> pitti: that's a relief
[13:21] <cjwatson> of sorts
[13:21] <Amaranth> ogra: go ahead, do whatever you want with it
[13:21] <pitti> cjwatson: ah, debian bug 483655; I'll send more information to that
[13:21] <ogra> Amaranth, thanks, i thought so, just didnt want to just steal it away without asking :)
[13:53] <lool> persia: Hmm not sure but did you push update-manager to ppa?  I don't see it
[14:20] <Riddell> pitti, doko: whole bunch more MIRs for you there
[14:22] <pitti> Riddell: yeah, just saw them
[14:22] <pitti> calc: is bug 220911 actually a problem in writer2latex? If not, we should remove the milestone from the task and set it to invalid
[14:26] <pitti> mvo: while I agree that bug 231805 is primarily a j2se bug, u-m should handle this a little more gracefully ideally?
[14:27] <pitti> mvo: oh, it doesn't actually crash u-m, it just reports the error
[14:27] <pitti> so that's fine
[14:29] <pitti> doko, mvo: bug 225927 is milestoned for .1, but has no assignee; is it important enough to deserve the 8.04.1 milestone?
[14:51] <pitti> seb128: do you think bug 206583 is really 8.04.1-worthy? I can reproduce it, but tricky to debug
[14:52] <pitti> but it doesn't seem terribly important to me
[14:53] <seb128> pitti: no, I just milestoned it as a target of opportunity in case there was an easy fix available, slangasek did open the hardy task
[14:53] <pitti> seb128: so you're ok with unmilestoning?
[14:53] <seb128> pitti: yes
[14:54] <seb128> pitti: or delay to 8.04.2
[14:54] <cpufreak> win 27
[14:54] <cpufreak> meh sorry :)
[14:54] <seb128> pitti: we should get a 8.04.2 milestone ;-)
[14:54] <pitti> cjwatson: ^ can you create one?
[14:55] <cjwatson> pitti: done, with a rather notional target date
[14:55] <seb128> cjwatson: thanks
[14:55] <pitti> cjwatson: thanks
[15:02] <pitti> seb128: bug 196277 sucks, though
[15:03]  * pitti grabs two more milestoned bugs and sits in a corner for hacking
[15:04]  * Hobbsee throws pitti a gummy bear so he hacks faster.
[15:04] <pitti> yummy
[15:04] <seb128> pitti: right, iz xorg bog though
[15:04] <seb128> pitti: which ones are you working on?
[15:04] <pitti> seb128: iz task inflation, too
[15:04] <pitti> bug 229000
[15:04] <pitti> and bug 206790
[15:04] <seb128> pitti: I've decided that I hate bug tasks now
[15:04] <pitti> seb128: lol
[15:04] <Hobbsee> haha
[15:05] <pitti> seb128: s/ task//, certainly? :-)
[15:05] <Hobbsee> seb128: i'm sure you can write a greasemonkey script to rename them.
[15:05] <seb128> thanks to people who open bugs having a zillion tasks
[15:05] <seb128> ie, "not using correct ubuntu maintainer information" or "need rebuild for perl transition"
[15:05] <ogra> yeah
[15:05] <seb128> you get a mail every time somebody add a comment or change a task
[15:05] <seb128> when your task as already been fixed and you don't care about the bug
[15:06] <Hobbsee> seb128: you can actually get out of those.  you can change the project to 'ubuntu', rather than the package that you're getting mail for.
[15:06] <seb128> Hobbsee: I did that but that's an ugly workaround
[15:06] <seb128> Hobbsee: and can have several tasks on "ubuntu"?
[15:06] <Hobbsee> seb128: i know.  there isn't a good solution, short of not filing bugs that way
[15:06] <Hobbsee> seb128: unsure
[15:06]  * ogra wonders why his bugs have suddenly a ton of "also notified" entries
[15:07] <ogra> makes me feel observed somehow
[15:07] <seb128> pitti: no, I've nothing against bugs, I don't get flooded by other people bugs activity ;-)
[15:07] <cjwatson> yes, people just shouldn't file bugs that way with a zillion different tasks
[15:07] <cjwatson> tasks are for multiple bits of the same problem
[15:08] <seb128> maybe a motu workflow issue
[15:08] <cjwatson> the way these are being used are different problems that happen to have basically identical fixes
[15:08] <seb128> dholbach: ^
[15:09] <cjwatson> I should have objected to this use when I first saw it, rather than now that it seems to be entrenched among a small subset of people
[15:15] <pitti> I still prefer them for things like "these 5 packages need a rebuild for libfoo transition"
[15:15] <pitti> it makes it so much easier to see the status
[15:19] <geser> I need some help with the perl 5.10 transition, I found a build-dependency loop :( how to proceed?
[15:20] <Amaranth> geser: ?
[15:20] <geser> libmodule-build-perl build-depends on libextutils-cbuilder-perl which build-depends on libmodule-build-perl
[15:20] <geser> and neither can currently be installed
[15:20] <Amaranth> fun
[15:28] <pitti> cr3, cjwatson: any idea how to reproduce bug 206790? alien works fine for me, and the example POD in /usr/share/perl5/Dpkg/Changelog/Debian.pm is absolutely, totally useless and wrong
[15:29] <cr3> pitti: err, didn't soren write patch that code?
[15:29] <cr3> pitti: I initially encountered that problem while attempting to install the lsb suite, need a url?
[15:30] <cjwatson> cr3: the bug log might help resolve confusion here
[15:30] <pitti> cr3: anything that demonstrates the problem; I can't reproduce it
[15:30] <pitti> and for a hardy SRU for dpkg I insist on something I can test :)
[15:31] <cjwatson> pitti: joeyh's comment implied that asking it to parse a changelog that had old-format entries at the end would do it
[15:31] <cjwatson> off the top of my head, man-db is one such
[15:31] <pitti> right, finding that shouldn't be a problem
[15:31] <pitti> so now I just need to find documentation how to actually use that beast
[15:32] <pitti> /usr/share/perl5/Dpkg/Changelog/Debian.pm is from dpkg-dev, while the POD in that file uses use Parse::DebianChangelog, which is libparse-debianchangelog-perl
[15:32] <cjwatson> aha
[15:32] <pitti> (separate implementation)
[15:32] <cjwatson> pitti: unpack man-db
[15:32] <cjwatson> pitti: run 'dpkg-parsechangelog --all'
[15:32] <pitti> aaaaah
[15:32] <pitti> cjwatson: thanks a lot
[15:34] <cr3> pitti: I'll append the steps to reproduce to the bug report, one moment...
[15:34] <pitti> cr3: I did that already now; thanks
[15:37] <dholbach> seb128: no, there's no MOTU process that says something like that
[15:38] <cr3> pitti: excellent, need anything else from me then?
[15:38] <pitti> cr3: that's fine, no
[15:39] <seb128> dholbach: ok, some have just decided that's a good idea apparently then and decided to use it to organize transitions, etc
[15:39] <dholbach> *nod*
[15:42] <pitti> wow, http://ntfs-3g.org/pjd-fstest.html is really nice for testing patches to packages like ntfs-3g
[15:44] <evand> nice!
[15:44] <cjwatson> nice
[15:47] <pitti> that's exactly what I was looking for for testing fakechroot
[15:47] <lool> I wonder whether it would have catched the unionfs regression with hard links, probably
[15:48] <ogra> i bet it would expose 20 new bugs in unionfs ... DONT RUN IT ON THERE, OMG ! :)
[15:52] <geser> pitti: who do I need to ask to get libextutils-cbuilder-perl and libmodule-build-perl manually rebuild on the buildds? infinity?
[15:52] <sistpoty|work> seb128: well, I did use tasks for a transition once (though that sucked, since LP rendered it very slowly). what's your problem with that?
[15:52] <pitti> geser: infinity or lamont, yes; what's up with them? a no-change upload won't help?
[15:53] <geser> libmodule-build-perl build-depends on libextutils-cbuilder-perl which build-depends on libmodule-build-perl
[15:53] <geser> pitti: ^^
[15:53] <lamont> geser: you ask infinity
[15:53] <lamont> pitti: no clue...
[15:53]  * norsetto now understands why infinity nick is infinity
[15:54] <lamont> norsetto: to be fair, his work day starts in just over an hour..
[15:55] <emgent> tseliot: o/
[15:55] <tseliot> ﻿emgent: hey
[15:55] <lamont> geser: if there isn't a way to do multiple uploads and have it happy (please wait for all 7 architectures if you do that...), then you're stuck asking the ubuntu OSA (infinity) to "halp make better"
[15:55] <martii> hi guys I got no answer on #ubuntu
[15:56] <martii> so I hope I can ask one question
[15:56] <martii> can I?
[15:56] <norsetto> !ask | martii
[15:56] <lamont> martii: that was a very simple question, and yes, you could. :-)
[15:56] <martii> http://library.gnome.org/users/user-guide/2.22/user-guide.html#nautilus-accessnetwork
[15:56] <martii> hardy uses 2.22 right?
[15:56] <martii> so where is NFS gone?
[15:57] <lamont> did you install nfs?
[15:57] <martii> as well nautilus doesn't recognize nfs://
[15:57] <geser> lamont: thanks, will try that first
[15:57] <martii> lamont: installed libs for nfs-client
[15:57] <martii> lamont: don't tell me I need to become nfs server to access nfs shares :)
[15:57] <lamont> martii: well, that expends my knowledge on the subject. :-(
[15:57] <seb128> sistpoty|work: my issue is that your mail every people who are watching a component which has a task open there
[15:58] <lamont> martii: you need to have /sbin/mount.nfs on the system
[15:58] <lamont> which should be in nfs-common, iirc
[15:58] <martii> lamont: I installed nfs-common and portmap
[15:58] <seb128> sistpoty|work: which means if I fix the task I'm watching I get zillions of bugs about things I've no interest in every time somebody touch one of the zillion other tasks I don't care about
[15:58] <martii> lamont: all according to docs
[15:58] <seb128> zillion mails rather
[15:59] <martii> which mount.nfs
[15:59] <martii> /sbin/mount.nfs
[15:59] <martii> lamont: so it's there
[15:59] <sistpoty|work> seb128: ah, I see. I guess it shouldn't be called "task" then *g* (and maybe mails shouldn't be sent to people subscribed via packages, which are already listed fixed in a task, though I'm not entirely sure about that)
[16:00] <cjwatson> sistpoty|work: tasks should be used when it's a single problem that just needs coordinated fixes in multiple places
[16:00] <seb128> sistpoty|work: you might want get comments about a bug you fixed in case the fix is not correct, etc
[16:00] <cjwatson> sistpoty|work: they aren't for when you've seen the same bug in 20 different packages
[16:00] <cjwatson> (IMO anyway)
[16:00] <seb128> sistpoty|work: there is no interest to list tasks in the transitions scenario, it's easier to file bugs and tag those
[16:01] <lamont> cjwatson++
[16:01] <cjwatson> to put it a different way: if the fixes required would be independent, they should be separate bugs
[16:01] <martii> lamont: https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/43363
[16:01] <martii> lamont: looks like this bug to me
[16:01] <sistpoty|work> hm... good point. (though I guess a transition would equally qualify as a problem, that needs coordinated fixing in multiple packages)
[16:02] <martii> lamont: but as well nobody interested to fix it?
[16:02] <seb128> martii: nautilus doesn't do nfs
[16:02] <cjwatson> for the mailbomb reason alone I think multiple bugs are a more practicably reasonable approach
[16:02] <sistpoty|work> however, as I wrote already, the ui just renders really slowly for many tasks, so I definitely won't be abusing it for this :)
[16:05] <martii> seb128: yep but It did
[16:05] <martii> seb128: as well as gnome 2.22 docs show there is NFS support
[16:05] <seb128> martii: not in ubuntu
[16:06] <martii> seb128: I noticed ;)
[16:06] <lamont> seb128: why'd we drop that?
[16:06] <seb128> lamont: we didn't, I'm not sure any GNOME 2 version ever did that
[16:06] <lamont> ah, o
[16:06] <lamont> k
[16:06] <martii> seb128: so why is it in docs?
[16:07] <martii> seb128: I'm sure it worked
[16:07] <seb128> because not a lot of people are interested in updating documentation
[16:07] <ogra> wishful thinking of doc writers ?
[16:07] <martii> seb128: as I have used it alot
[16:07] <seb128> and some very old GNOME versions might have had crackish nfs support
[16:07] <martii> seb128: nfs:// worked the same as smd:// in nautilus
[16:07] <martii> seb128: nfs:// worked the same as smb:// in nautilus
[16:07] <seb128> martii: that was GNOME1?
[16:08] <martii> seb128: when ? year ago?
[16:08] <martii> seb128: maybe that was gnome-vfs
[16:08] <seb128> martii: http://bugzilla.gnome.org/show_bug.cgi?id=328107
[16:08] <martii> seb128: and now you got gnome-vfs2
[16:08] <ogra> martii, its called gvfs, gnome-vfs2 is the older one
[16:09] <seb128> gnome-vfs2 and gnome-vfs are the same thing
[16:09] <martii> ogra: whatever
[16:09] <martii> ogra: I can't understand why new version is worse :)
[16:09] <martii> ogra: you upgrade to net LTS and things not work :)
[16:09] <martii> ogra: you upgrade to next LTS and things not work :)
[16:10] <seb128> martii: you have one thing that almost nobody used and which was buggy which has been dropped and ton of other improvements
[16:10] <martii> seb128: yep but as you can see
[16:10] <martii> seb128: this bug is still unconfirmed
[16:11] <martii> seb128: so many people confirmed a problem
[16:11] <seb128> gnome-vfs is not maintained, they are working on gvfs now
[16:11] <seb128> upstream doesn't care about confirming bugs, the doesn't make a difference, they know it's a wishlist but have other things to do
[16:12] <seb128> and a nfs gvfs backend is a low priority thing, most people using nfs use system mounts for that
[16:12] <martii> seb128: I understand I could do that as well
[16:13] <martii> seb128: but it's nice to mount stuff only when you need it
[16:13] <martii> seb128: as NFS tends to lock up my machine when I loose connectivity
[16:13] <seb128> use automount?
[16:13] <ogra> use sftp
[16:13] <martii> seb128: yep that's an option
[16:13] <martii> ogra: it's netapp filesever no sftp ssh
[16:14] <ogra> less server overhead and supported in nautilus
[16:14] <ogra> sad
[16:14] <seb128> anyway the option was to work on improving ssh, ftp, smb supports or write a nfs backend
[16:14] <martii> ogra: nfs only (there is smb but of course nautilus is unable to pass my LDAP username and password correctly)
[16:14] <seb128> almost everybody prefer to have better support for the common backends
[16:14] <seb128> but you are welcome to write a gvfs nfs backend if you think that's needed
[16:14] <martii> seb128: I know and understand that
[16:15] <martii> seb128: if it's C++ foreget it :)
[16:15] <martii> seb128: if it's C++ forget it :)
[16:15] <ogra> C
[16:15] <martii> seb128: I can only do python :)
[16:15] <seb128> it's C
[16:15] <ogra> plain and simple actually
[16:15] <martii> C is more likely I could remind myself
[16:15] <martii> seb128: any links to docs?
[16:16] <martii> seb128: if developers will be happy to apply my patch or extension
[16:16] <seb128> http://library.gnome.org/
[16:16] <martii> seb128: I had problems before
[16:16] <seb128> you can mail the gvfs upstream list
[16:16] <martii> seb128: they might start talking like you that people don't need nfs
[16:16] <martii> ;)
[16:16] <seb128> but I don't expect a nfs backend to be easy to write
[16:16] <seb128> well, they will not likely put efforts into it no
[16:17] <seb128> but if you send a work patch, that's going to be difficult though, that's not trivial coding
[16:17] <martii> seb128: http://library.gnome.org/devel/references
[16:17] <martii> no reference to gvfs
[16:18] <lamont> just remember that NFS stands for Not a File System
[16:18] <ogra> martii, they wont tell you nfs isnt needed if you send code :)
[16:18] <lamont> (per posix, with interpretation)
[16:18] <ogra> heh
[16:18] <martii> ogra: many times developers did that
[16:18] <ogra> well, ususally developers are happy if you send code and help you to improve it is what is my experience
[16:18] <martii> ogra: moslty they say they don't want to brake their code with untested stuff when priority for extension is not critical
[16:19] <geser> pitti: does it needs MIRs to get some perl modules from universe to main which are needed for build-dependencies?
[16:19] <seb128> martii: no real documentation out of the source code for now, gvfs is pretty new and it's really a rush, people are busy trying to get it work right now and didn't stop to write documentation
[16:19] <pitti> geser: at least MIR bugs; trivial ones don't need a full wiki page
[16:19] <martii> seb128: OK I'll stick with autofs
[16:19] <martii> sorry for wasting your time guys
[16:19]  * geser hates the perl 5.10 transition already
[16:19] <ogra> you expressed a need
[16:19] <ogra> not wasted time, really
[16:21] <martii> ogra: :)
[16:21] <martii> http://www.acis.ufl.edu/~ming/gvfs/ so that's not the gnome thing?
[16:22] <pitti> geser: can't say how grateful we all are that you deal with it *hug*
[16:27] <hunger> Which version of the telepathy spec will be supported in intrepid?
[16:27] <geser> pitti: http://launchpadlibrarian.net/14685812/buildlog_ubuntu-intrepid-i386.libfile-sync-perl_0.09-4build1_FAILEDTOBUILD.txt.gz Is this a bug in the package or in pkg-create-dbgsym?
[16:29] <pitti> geser: it's a bug in the package, since debhelper compat 1 needs debian/tmp; it's a problem with pkg-create-dbgsym in the sense that it is not as forgiving as debhelper about packaging bugs
[16:29] <geser> pitti: thanks, will fix the package then
[16:30] <pitti> ideally we'd fix pkg-create-dbgsym to deal with those
[16:30] <pitti> if it builds locally
[16:54]  * pitti kicks rothera again to get back to work
[16:54] <pitti> infinity, cprov: ^ FYI
[17:22] <Kano> hi, is anybody using ICH9R with raid 5 successuflyl?
[17:33] <Keybuk> ok, that's weird
[17:33] <Keybuk> "People nearby"
[17:33] <Keybuk>  O  Keybuk
[17:39] <evand> heh
[17:39] <ion_> keybuk: What says that? :-)
[17:40] <Robot101> Keybuk: you can see yourself in Empathy?
[17:41] <Keybuk> I can indeed
[17:41] <Keybuk> I suspect the machine upstairs just woke up for something and logged in
[17:42] <Robot101> ah ok, i was about to say sjoerd's here now so you can badger him on #tp if you've found a bug :)
[17:43] <sjoerd> I usually use sjoerd on X as my nick in salut to prevent that kind of confusing :)
[17:44] <Keybuk> if only we could set the status usefully ;)
[17:56] <Robot101> Keybuk: what do you mean?
[17:56] <Keybuk> doesn't jabber have an extended status bit?
[17:57] <Robot101> like the "custom messages" thing in the status dropdown?
[18:04] <ion_> Is intrepid beginning to be usable? That is, are there still some huge things like a new major release of glibc coming?
[18:05] <ion_> I don’t mind running an unstable distro on this box, but rather wouldn’t upgrade yet if it’s expected to break badly. :-)
[18:09] <geser> ion_: we are still in the middle of the perl 5.10 transition, but you could have luck
[18:11] <ion_> That sounds like something i might even be able to help with.
[18:46] <fde> Hello, several people in #ubuntu are having issues due to hardy-proposed currently... it appears that gnome-about depends an explicit version of gnome-desktop-data (2.22.2-0ubuntu1) but today it was upgraded... this removed gnome-panel for many... and I don't see this package in http://archive.ubuntu.com/ubuntu/pool/main/g/gnome-desktop/ and don't have it locally to upload to a ppa...
[18:46] <fde> What can be done about this situation?
[18:47] <cjwatson> sounds to me like architecture desync
[18:48] <cjwatson> gnome-desktop-data is built on i386 and the same package is used on all architectures
[18:48] <cjwatson> gnome-about is built on each architecture separately
[18:48] <fde> cjwatson: It is people that have hardy-proposed enabled due to virtualbox I think... seems to be unfortunate timing on their part.
[18:48] <cjwatson> but they come from the same source package
[18:48] <cjwatson> so when i386 builds out of step with the others, you'll get this happening transiently
[18:48] <cjwatson> tell them to wait for a while and try later, and it will go away
[18:49] <fde> cjwatson: Some have already lost their panels... just apologize to them?
[18:49] <pochu> the question is, why people who don't check what is going to be removed use -proposed?
[18:49] <cjwatson> https://launchpad.net/ubuntu/+source/gnome-desktop/1:2.22.2-0ubuntu2 shows that the new version hasn't quite built everywhere yet, though it should be OK for i386 and amd64 users
[18:49] <cjwatson> fde: why did they allow the upgrader to remove packages in the first place?
[18:49] <pochu> fde: first ask them to disable -proposed! :)
[18:49] <cjwatson> fde: advise them to reinstall ubuntu-desktop
[18:49] <fde> pochu: it is a documented work around for virtualbox, although apparently that documentation didn't mention disabling it when they're done.
[18:50] <fde> cjwatson: alright, thanks. pochu definitely will do  :)
[18:50] <pochu> fde: right, there should be some easy way to install packages from -proposed without enabling it completely...
[18:50] <fde> Thanks for the assistance, wanted official word  :)
[18:50] <cjwatson> fde: sounds like they used an option designed for advanced testers and got burned by the consequences; the documentation should definitely be fixed
[18:50] <fde> pochu: maybe something like experimental on debian should be enacted?
[18:51] <cjwatson> fde: hardy-proposed *is* a bit like experimental
[18:51] <cjwatson> although not so much
[18:51] <cjwatson> we have plenty of things that fill similar niches; however if people get told to use them then what can we do?
[18:51] <fde> cjwatson: still, even when enabled, people don't need to be using it always unless they're aware of what that entails.
[18:51] <pochu> cjwatson: yesterday we had the same problem with people removing firefox via update-manager, due to the "Partial upgrade" dialog in it
[18:52] <pochu> so while I think they shouldn't be running -proposed at all, update-manager could be more verbose there
[18:52] <cjwatson> hardy-proposed contains non-QAed updates that may break your system, because they have not yet been verified
[18:52] <cjwatson> it's that simple
[18:52] <pochu> of course
[18:53] <cjwatson> so while we welcome people helping us with the QA process, we can't really also have them coming to us and complaining that things were set up wrong because their system broke :-)
[18:53] <fde> cjwatson: I think it's safer to make people type 'sudo aptitude -t hardy-proposed install whatever' and document how to enable it always _no_where_... there's been a few issues like this, and people inevitably want things like firefox and virtualbox to work.
[18:53] <cjwatson> I agree that there is room for improvement in update-manager
[18:53] <cjwatson> I know that mvo knows about this, since he mentioned it yesterday (I think)
[18:53] <ion_> After this operation, 2179MB disk space will be freed.
[18:54] <fde> cjwatson: Even just having it deselect everything originating from hardy-proposed, and forcing users to select what they actually want would be better... if that is even possible?
[18:54] <cjwatson> -> mvo
[18:54] <cjwatson> though I was under the impression it already did that; could be wrong
[18:54] <cjwatson> oh, actually, no, I'm thinking of something else
[18:55] <cjwatson> remember that -proposed was instituted in response to a problem that slipped through QA that caused X not to start for some people
[18:55] <pochu> I reported bug 152335 some time ago to try to reduce the number of users running -proposed
[18:56] <fde> cjwatson: Yes, I actually discussed that at a LUG a couple nights ago  ;)
[18:56] <cjwatson> regardless of whether you deselect things by default, people will try selecting them out of curiosity - isn't X not starting much worse than firefox going away?
[18:56] <pochu> although that may not be a good solution at all :)
[18:56] <ogra> the software sources dialog doesnt really tell you that its dangerous to enable it
[18:56] <cjwatson> thus the most important thing is not to advise people to use -proposed who can't cope
[18:56] <ogra> the wroding should be better
[18:56] <ogra> *wording even
[18:56] <cjwatson> even if that's the only location for a bug fix in progress, it's more important to have it go through QA before wide deployment
[18:56] <fde> cjwatson: It's hard to ensure that in private mediums though... so maybe a technical solution is better...
[18:57] <fde> Should I file a bug with some propositions real quick just to remind?
[18:57] <cjwatson> sure, better than talking to me about it since I'm not the relevant developer ;-)
[18:57] <cjwatson> should go on apt I think
[18:58] <fde> cjwatson: alright, thank you for your recommendations... if that doesn't fix it for users (reinstalling ubuntu-desktop) then I'll likely be back... or maybe I'll break it and try to fix it locally  :P
[18:59] <fde> On a more positive note: Thanks for all the hard work, you guys are awesome  :D
[18:59] <cjwatson> it will depend on the architecture they're using
[18:59] <cjwatson> powerpc doesn't seem to have caught up yet
[19:00] <fde> cjwatson: I'll try to look into that too... luckily qemu can emulate a ppc system - although it'll be slow as molasses.
[19:01] <fde> (only from a user perspective though... see if I can come up with another solution if that doesn't fix things)
[19:05] <mvo> cjwatson: we could disable partial upgrades at all in stable, they are only required when things need to be removed and Ithat should never be the case for stable
[19:27] <rom> hi
[19:28] <alex1> hi guys. what does it mean when a bug's status is triaged in launchpad?
[19:33] <Methoxypropan> Hello :)
[19:35] <Methoxypropan> I've got a BCM94311 rev 2 wireless network card and read about a patch to get it working with the native bcm43xx-fwcutter. Where can I download the patched driver?
[19:35] <Kopfgeldjaeger> bug #214386
[19:35] <Methoxypropan> thanks Kopfgeldjaeger
[19:37] <rom> hi, I reported a bug in compiz with a patch this morning : https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/235982 (my first patch \o/ )
[19:37] <rom> do you think it could be applied
[19:41] <Methoxypropan> where can i download the patch from bug #214386
[19:48] <elmo> pitti: can I turn off the python apport stuff
[19:50] <Methoxypropan> Hi dev's ;)
[19:52] <speart> hi, can init.d rules, or udev entries prevent computer shutdown?
[19:54] <mvo> rom: the fist part of the patch looks good, I'm not sure about the "-l" bits
[19:54] <rom> mvo: why that?
[19:54] <rom> nvidia-settings -l
[19:55] <mvo> rom: it seems like this is something that we shouldn't enforce in the compiz script, I don't need it and it gives me a ugly flickering
[19:55] <rom> to load the settings (if you don't, nvidia settings are not applied)
[19:55] <rom> since a long time
[19:55] <Methoxypropan> can anybody help me with bug #214386
[19:55] <rom> (antialiasing, anisotropic, sync to vblank)
[19:56] <mvo> rom: isn't that only required if the nvidia-settings panel is used and shouldn't it be used in a place that is more generic that the compiz start script? like .xinitrc or something similar?
[19:56] <Methoxypropan> i need that patch to get my wireless working :(
[19:56] <rom> hmmm...
[19:56] <mvo> rom: actually, if its something that should always be run, I think it should be part of the nvidia-settings package and go into /etc/X11/Xsession.d maybe
[19:56]  * mvo is not a expert for the binary driver though
[19:57] <rom> should not always be run, only before compiz lunch
[19:57] <rom> I guess
[19:57] <rom>  Load the configuration file, send the values  specified  therein
[19:57] <rom>               to  the X server, and exit.  This mode of operation is useful to
[19:57] <rom>               place in your .xinitrc file, for example
[19:57] <rom> ok
[19:57] <mvo> before compiz or anything that uses 3d I guess? like games etc?
[19:58] <mvo> tjaalton: ---^ do you have a opinion on the right place to put nvidia-settings -l ?
[19:58] <rom> so, it should be added in nvidia-settings package, no?
[19:58] <rom> to add it to .xinitrc file
[19:58] <mvo> yes, that looks like a better place to me (/etc/X11/Xsession.d probably)
[20:00] <rom> where is .xinitrc?
[20:02] <rom> I don't find it
[20:02] <rom> locate .xinitrc doesn't give any result
[20:03] <rom> l
[20:04] <rom> and in which file compiz in launched when starting?
[20:06] <rom> mvo?
[20:09] <rom> ?
[20:10] <mvo> rom: its in the users homedir, but that is not a place where packages can put stuff, this is why I mentioned /etc/X11/Xsession.d
[20:11] <rom> ok, and do you know how compiz starts when system starts?
[20:11] <rom> in which file
[20:11] <rom> is it started?
[20:11] <Pici> rom: It doesnt start when the system is started.
[20:11] <Pici> rom: It starts after a user logs in.
[20:11] <rom> in ubuntu, yes
[20:11] <rom> ah
[20:11] <rom> yes :)
[20:11] <rom> where is it started?
[20:12] <Pici> rom: Have you looked into mvo's suggestion?
[20:12] <rom> I have no .xinitrc
[20:12] <Pici> rom: No one but you mentioned that, see /etc/X11/Xsession.d
[20:13] <rom> yes I searched
[20:13] <rom> but this dir is for putting nvidia-settings -l, I didn't find compiz here
[20:13] <rom> cat /etc/X11/Xsession.d/* | grep compiz → no results
[20:14] <ion_> UUOC ;-)
[20:16] <rom> no idea?
[20:21] <mvo> rom: compiz is started via the gnome-wm script by gnome-session. but I it seems to me that the nvidia-settings -l run should be independant of the compiz one
[20:22] <rom> mvo, yes, I agree nvidia-settings -l should be independant ;)
[20:22] <rom> where is "gnome-wm script by gnome-session"?
[20:25] <rom> ah, gnome-wm is in /usr/bin :)
[20:25] <rom> thanks
[20:25] <rom> but doesn't it slow down the boot time ?
[20:25] <rom> to load metacity first, then when the user is logged
[20:25] <rom> to load compiz...
[20:25] <rom> ?
[20:29] <Pici> I dont see that there.
[20:30] <rom> what do you mean (sorry, I'm not english, I don't get it)
[20:30] <rom> "I dont see that there"
[20:30] <rom> ?
[20:30] <Pici> rom: gmome-wm looks like it calls whatever window manager based on a set of rules, not both wms.
[20:30] <Pici> anyway, I need to run.
[20:31] <rom> ok, but before running compiz
[20:31] <rom> when you have login screen
[20:31] <rom> it's metacity, no?
[20:31] <rom> to run nvidia-settings -l in /etc/X11/Xsession.d, I just have to make a script containing "nvidia-settings -l" with a special filename?
[20:48] <rom> mvo? could you confirm how to add a script to Xsession.d?
[20:49] <mvo> rom: that sounds right, it needs to be added to the nvidia-settings package
[20:49] <mvo> rom: you may talk to the people in #ubuntu-x too
[20:49] <simira> mvo: are you still responsible for the update-manager?
[20:50] <rom> mvo: ok, but do you know how to add a script in Xsession.d? Just put the script "like this", no particular format?
[20:53] <mvo> simira: yes
[20:56] <simira> mvo: works very well now, I like it!
[20:56] <mvo> simira: cool, I like that :)
[20:56]  * mvo hugs simira
[20:56] <calc> Mirv: yes, i need to make an upload of the openoffice.org-l10n packages that i will be doing in a few minutes
[20:58] <calc> pitti: 220911 is a bug in openoffice.org not writer2later afaicr but i haven't added it in yet to the upload since i need to verify the patch works properly (its not a patch in ooo-build)
[21:09] <ion_> keybuk: What was this about? :-) * At this rate, I'm going to prove pitti right!
[21:38] <Methoxypropan> Hello
[21:39] <Methoxypropan> Where do i get a patched bcm43xx driver ?
[21:58] <ion_> Note to self: mention http://heh.fi/tmp/recovery-mode-dpkg.patch to mvo
[22:08] <cjwatson> ion_: 'if [ -x $python -a -e $script ]' -> 'if [ -x "$python" ] && [ -e "$script" ]' please?
[22:09] <cjwatson> (quoting is just good style, and the rules for -a and -o are so twisted and unintuitive they're best avoided)
[22:10] <ion_> cjwatson: Will do. I usually do quote pretty much everything, but that case seemed so obvious, since there are ‘2.5 2.6’ right above.
[22:10] <Methoxypropan> Hello
[22:10] <Methoxypropan> When will the patched bcm4311xx driver be in the ubuntu repo?
[22:12] <ion_> cjwatson: Updated.
[22:14] <Methoxypropan> no answer?
[22:18] <cjwatson> Methoxypropan: which patch are you talking about here?
[22:19] <cjwatson> Methoxypropan: and is there a bug filed about whatever it is?
[22:19] <Gaming4JC> hi
[22:20] <Methoxypropan> cjwatson, yes there is a bug report on launchpad...wait..i'm going to search it
[22:20] <Gaming4JC> I need some one who can compile a modem driver (I got the source), so I can get online in Ubuntu. :)
[22:20] <Mirv> calc: remember also the rebuild of openoffice.org-voikko, to be published at the same time so as not to force language-support-fi/ooo-voikko deinstallation
[22:20] <Gaming4JC> If anyone could do it, I'd give you much thanks. http://linmodems.technion.ac.il/pctel-linux/pctel-0.9.7-9-rht-6_for_Ubuntu-2.6.15-23-386.tgz
[22:21] <Mirv> (really should have automatic testing/stuff about the dependencies etc.)
[22:21] <Methoxypropan> cjwatson, its bug #214386
[22:21] <Gaming4JC> :) ...
[22:23]  * Gaming4JC you can see I cannot get online to compile the tool, so I was wondering if anyone could do it. (would help so much) 
[22:23] <Gaming4JC> I'm on Windows now.
[22:24] <Gaming4JC> :'(
[22:24] <Chipzz> Gaming4JC: the reason no-one is answering is because this is not a support channel
[22:24] <Gaming4JC> it's development?
[22:24] <Chipzz> yes, OF ubuntu
[22:24] <Gaming4JC> so not drivers for Ubutnu?...
[22:24] <Gaming4JC> :-/
[22:24] <Chipzz> what you're trying to do is not even development
[22:25] <Chipzz> it's compiling
[22:25] <Gaming4JC> eww... so where should I go for that? (main support doesn't seem to know)
[22:25] <Chipzz> forums or #ubuntu
[22:25] <Methoxypropan> cjwatson, in the last post the guy sais something about a patch.... but when will the patch be in the repo?
[22:25] <cjwatson> Methoxypropan: "a new patch has been submitted" but no link
[22:26] <Gaming4JC> ok thanks
[22:26] <Gaming4JC> byes ;)
[22:26] <cjwatson> Methoxypropan: the name in that last comment isn't one I recognise; he's not a member of the Ubuntu kernel team
[22:26] <cjwatson> (AFAIK)
[22:26] <cjwatson> so somebody needs to actually provide the patch to the Ubuntu kernel team (or a reference to it or whatever) in order for it to have a hope
[22:26] <cjwatson> I suspect he's perhaps a bcm43xx upstream guy looking at his subscribed bug list
[22:27] <cjwatson> so perhaps what he meant was that a patch has been sent to bcm43xx upstream
[22:27] <Methoxypropan> cjwatson, http://cantrip.org/bcm43xx-2619.patch
[22:27] <cjwatson> a patch from October 2006? surely not
[22:28] <cjwatson> whatever Larry is describing sounds much more recent than that
[22:28] <Methoxypropan> so how long will i have to wait?
[22:28] <cjwatson> the bug is in far too early a state to be able to say
[22:29] <Methoxypropan> ok thanks a lot ;)
[22:29] <cjwatson> if you want to help, track down whatever it is that Larry was actually referring to
[22:30] <cjwatson> I do think you will need to look for something that's actually from this year
[22:31] <Methoxypropan> cjwatson, they said that the patch that made it working has been removed because an othe card didnt work
[22:32] <cjwatson> yes, I read that
[22:35] <cjwatson> ah, he sent some patches to kernel-team@
[22:35] <cjwatson> which Tim seems to have picked up
[22:36] <Methoxypropan> cjwatson, so maybe it'll be in the next kernel?
[22:36] <cjwatson> it looks like it
[22:36] <cjwatson> see bug 197959
[22:37] <cjwatson> "There is now a test kernel in my PPA with these 4 patches at http://ppa.launchpad.net/timg-tpi/ubuntu. Please give it a try and report the results."
[22:37] <cjwatson> perhaps you could give that a shot and report results to 197959, assuming that's essentially your bug
[22:39] <Methoxypropan> thanks a lot cjwatson
[22:39] <cjwatson> I doubt that's targeted for 8.04.1 at this point (though I could be wrong); it's a bit late - but at least you'll have the PPA kernel to tide you over until then, and if it's working well then it'd be at least in the next round of hardy kernel updates after 8.04.1
[22:40] <cjwatson> (and, as I suspected above, Larry does indeed seem to be a bcm43xx upstream guy, helping out)
[22:43] <Methoxypropan> ;)
[22:44] <Methoxypropan> cjwatson, so i'm going to reboot and hopefully be back again
[23:31] <Methoxypropan> cjwatson, so its working perfectly ;)
[23:32] <cjwatson> oh good; can you update the bug on that if you haven't done so already?
[23:32] <cjwatson> (both the one you originally gave and the one I pointed out)
[23:32] <Methoxypropan> cjwatson, mhm...can i do it tomorrow? i'm really tired
[23:33] <Methoxypropan> Which bug numbers did the bugs have?
[23:34] <Methoxypropan> cjwatson, can you remember the bug numbers?
[23:34] <cjwatson> 22:21 <Methoxypropan> cjwatson, its bug #214386
[23:34] <cjwatson> 22:36 <cjwatson> see bug 197959
[23:34] <cjwatson> my IRC client can ;-)
[23:35] <Methoxypropan> thanks ;)
[23:36] <Methoxypropan> so i should say that it's working on my system and tell the guys from bug #214386 that they can use the kernel from bug #197959 ?
[23:39] <cjwatson> I think so
[23:39] <Methoxypropan> bbl [02:00 pm GMT+1] :P
[23:39] <Methoxypropan> gn8