[00:44] <chrisccoulson> james_w - i've just seen bug 284653
[00:44] <james_w> yeah
[00:45] <chrisccoulson> i don't know what to do with hid bug report anymore;)
[00:45] <james_w> I was just going to close it
[00:45] <james_w> but then I had a change of heart at the last minute
[00:45] <chrisccoulson> i was thinking of closing it too;)
[00:45] <james_w> if he carries on I think we should consider escalating things
[00:46] <chrisccoulson> yeah, i think you're right.
[00:46] <chrisccoulson> i don't understand how one person can have so many problems that nobody else seems to experience
[00:46] <james_w> have you seen any activity that goes beyond irritating?
[00:47] <chrisccoulson> did you see his recommended steps to recreate the crash in consolekit?
[00:47] <james_w> he seems to like "chmod" a bit too much
[00:47] <chrisccoulson> he does!
[00:47] <james_w> that's probably where most of his issues come from
[00:47] <chrisccoulson> i don't think that chmod -R /* is a great idea
[00:47] <james_w> really?
[00:47] <james_w> it surely fixes every possible issue
[00:48] <james_w> nothing could possibly go wrong
[00:48] <chrisccoulson> yeah, he recommended a chmod -R 777 /* i think
[00:48] <chrisccoulson> i did that once by accident!
[00:51] <chrisccoulson> he posts on the ubuntuforums too: http://ubuntuforums.org/showthread.php?t=912682
[00:51] <james_w> chrisccoulson: oh, I just replied to your sponsor request as well
[00:52] <chrisccoulson> ah yes!
[00:52] <james_w> "I do admit though that I was a little bit drunk at the moment I posted the bug."
[00:52] <james_w> I love that sentence
[00:52] <chrisccoulson> lol
[00:52] <james_w> "Anyway, the other argments are not very helpful, I need to stick to the point. I am afraid such is impossible, since I do not know what the point is."
[00:53] <chrisccoulson> haha!
[00:53] <chrisccoulson> i've got no idea why that patch got dropped from system-config-samba
[00:54] <chrisccoulson> it doesn't appear to be documented anywhere, and the libraries that the upstream source depend on have never been packaged
[00:54] <chrisccoulson> very odd
[00:54] <james_w> yeah, I hadn't bothered to pull up the changelog yet
[00:54] <chrisccoulson> i'll have a look and see when they were dropped, but i suspect it will be when the patch system was changed to quilt
[00:54] <james_w> Just thought I'd ask, I was looking for reasons to not sponsor it tonight :-)
[00:54] <chrisccoulson> lol
[00:55] <chrisccoulson> i'm not sure about your other question though. i literally just had a look at the old patch and then regenerated it with quilt
[00:55] <chrisccoulson> which was difficult! i've never used quilt before
[00:56] <chrisccoulson> i had to regenerate it because some of the source file names had changed
[00:56] <james_w> I guess you are right
[00:56] <james_w> just "grep -r N_ ." will be a start
[01:02] <james_w> right, I must sleep, I've got to be reasonably awake for a call tomorrow morning. I'll sponsor your patch tomorrow.
[01:04] <chrisccoulson> thanks for that!
[01:04] <chrisccoulson> i've got tomorrow off work;)
[02:27] <nellery> so who's running this Ubuntu Open Week's bug sessions?
[06:41] <dholbach> good morning
[08:19] <maco> can someone look at bug 282977 ? xscreensaver and gnome-screensaver both have entries in System->Preferences as just "Screensaver" in Intrepid.  Is it too late to nominate a semi-cosmetic but also rather confusing bug like that for release?
[09:19] <maco> thekorn: the applet's supposed to count down, right?
[09:21] <james_w> maco: I'd jump on #ubuntu-devel and ask that question
[09:21] <james_w> the first one I mean
[09:21] <maco> james_w: ok
[09:28] <thekorn> maco: yes, with the most recent PPA package the applet should count donw from 5 to 0
[09:28] <maco> thekorn: do i have to remove it and re-add it? it didnt count down when i tried it like 30 minutes ago
[09:30] <thekorn> maco: oh, I'm not sure about it, sorry,
[09:30] <thekorn> but maybe re-adding is neccessary
[09:31] <maco> thekorn: well the font changed when i re-added it
[09:31] <maco> so maybe now it'll count down
[09:31] <thekorn> then countdown should work
[09:32] <maco> ok
[09:42] <dholbach> or restarting the session
[09:42] <dholbach> if you didn't it will have the old version still in memory
[09:47] <maco> dholbach: ah ok, makes sense
[09:53] <maco> countdown works!
[10:02] <dholbach> ROCK
[10:03] <maco> i get now how people recognize duplicates easily
[10:03] <maco> touch enough bugs every day, and there's a very good chance you've touched the master bug or at least wandered past it at some point
[11:33] <fib1908> hi best stable version of kdenlive for ubuntu ?
[11:35] <Guest18685> can someone look at my comment to https://bugs.launchpad.net/ubuntu/+source/ssl-cert/+bug/250400 and try to verify it please? i think this bug is pretty severe (renders systems broken on upgrading!) but very easy and fast to fix ... the bug report is actually pretty old
[11:35] <stivw> sry ... nick change ;)
[11:41] <james_w> stivw: is it using unattended-upgrades?
[11:44] <stivw> the package?
[11:47] <stivw> i don't know ... i am using an automated installation script after a netinstall to install additional packages - which is started in /etc/rc.local and this fails. i then tried to install it with a cron script which also fails. if i add /usr/sbin to PATH everything works. i then built the package with the two changes i described and it also works. i think it's an error in the package NOT to use absolute paths
[12:02] <james_w> it's common to use non-absolute paths, and possibly even encouraged in policy
[12:03] <james_w> I think administrative scripts should reasonably be allowed to expect to have /usr/sbin in the path
[12:09] <stivw> well then the bug is invalid - it just fails because of the missing path
[13:41] <stivw> well ... yet another comment - the bug isn't closed yet
[13:41] <stivw> https://bugs.launchpad.net/ubuntu/+source/ssl-cert/+bug/250400
[13:47] <stivw> this also has an effect on ALL packages that use make-ssl-cert together with ssleay.cnf files. eg lighttpd has the same problem too. if installed/upgraded the path won't be set, and the pem file won't be generated (!)
[15:36] <a|wen> does upgrade-manager save a list of installed packages before the dist upgrade or some other log files you can use for debugging?
[15:38] <a|wen> or if anyone is a pycentral expert and has any idea what exactly fails here in bug 284936
[15:40] <bddebian> Boo
[15:42] <a|wen> arrgh - don't frighten people
[15:42] <a|wen> :)
[15:44] <bddebian> :)
[16:43] <maestrolinux> http://s2.ar.bitefight.org/c.php?uid=19732
[16:45] <maestrolinux> http://s2.ar.bitefight.org/c.php?uid=19732
[17:42] <macd_> a bug in the ubuntu website, would that go on LP?
[17:43] <persia> against the ubuntu-website project, I believe
[17:45] <Flannel> yep
[17:49] <macd_> thanks, and done.
[18:18] <mrooney> Hmm, apport can't report bugs in update-manager that occur before installing updates, since the updates aren't installed.
[18:18] <mrooney> How...interesting.
[18:18] <mrooney> I feel that update-manager should have a special exception there
[18:19] <persia> mrooney, Rather, that the current special exception for update-manager consider the case where update-manager itself is having an issue.
[18:20] <mrooney> persia: update manager has a special exception already?
[18:22] <persia> I believe so : I think it generates the bugs in other packages when the maintainer scripts break.
[18:22] <mrooney> persia: ah, ok
[18:31] <charlie-tca> I'm working to confirm bug 226606. It is about hal not recognizing the drive if the leading / is missing
[18:31] <charlie-tca> There are a number of other comments that have nothing to do with this. Can I confirm it and what
[18:32] <charlie-tca> do I do with the rest?
[18:36]  * mrooney looks
[18:52] <mrooney> charlie-tca: hm I don't know none of the confirming comments seem to have anything to do with the bug report...for some reason
[18:53] <charlie-tca> I know, but I can reproduce the original report. /media will work, media won't
[18:54] <charlie-tca> I think it should go wishlist, though
[18:54] <mrooney> yeah, I guess confirm and wishlist it
[18:54] <mrooney> it is easy to work around
[18:54] <charlie-tca> yea, just use the leading /
[18:55] <mrooney> just mention in the comments that you can confirm it and your wishlist rationale
[18:55] <charlie-tca> Thanks for your help
[20:04] <LimCore> default settings of ubuntu lead to data corruption
[20:06] <persia> LimCore, Really?  In what way?
[20:09] <LimCore> persia: this is thanks to brain dead design of logout feauture
[20:09] <LimCore> its so interesting, Im whipping up a bug report right now to share this amazing experience
[20:10] <persia> LimCore, OK.  I'll look forward to reading the bug, as I'm curious.  Is this hardy or intrepid?
[20:10] <LimCore> all versions
[20:10] <LimCore> also, most distros probably
[20:13] <bdmurray> saivann: wrt bug 270777 this used to work?
[20:23] <LimCore> persia: https://bugs.launchpad.net/ubuntu/+bug/285141
[20:28] <persia> LimCore, For the UPS use-case, I'd argue that the right answer is that the user should have connected a serial cable or USB cable to the UPS, and the alert should start the shutdown sequence.  For the thunderstorm use case, I can see value in your suggestion, although I still think it's Wishlist, as generally one shouldn't lose much data (immediate working set).
[20:30] <LimCore> persia: UPS is a solution,    but not for all cases
[20:33] <LimCore> User with access to power button CAN turn off computer always, so lets allow him to do it gracefully, if he insists (pressing power button several times).
[20:33] <LimCore> Also: this will solve cases like when keyboard dies (I seen it), or gfx card dies (seen it too) and other strange cases.
[20:34] <persia> LimCore, Right.  Like I said, it's a good idea.  It's just that the first example you give starts with a UPS, and the solution for a UPS is well known and different.  I encourage editing, not rejection.
[20:34] <persia> If you edit it to clean up the UPS use case, I'd even be happy to confirm it :)
[20:45] <LimCore> persia: rewritten
[20:46] <LimCore> I almost corrupted FS today, I was in the process of using damn cellphone as lighter to try to login as root and shutdown -h now # die $%^*   but I was saved in last second - power went back on. Im so irritated by such careless design like this one
[20:51] <saivann> bdmurray : What do you mean?
[20:52] <bdmurray> saivann: I was wondering if it really was a regression.  I've never tried it before today.
[20:52] <saivann> bdmurray : This works perfectly under Hardy and with previous versions of rhythmbox, I will identify specific revision in rhythmbox that introduced this problem when I'll get some time (in the next days)
[20:52] <saivann> bdmurray : Definitively a regression in rhythmbox, and not in libraries because I can build old version in intrepid and they work
[20:58] <persia> Could someone suggest a package for bug #285141, or does that belong on brainstorm?
[20:59] <LimCore> persia: I can write it probably
[21:00] <LimCore> bash script, called from ACPI power button, counts, and if needed calls shutdowns/kills/syncs
[21:02] <LimCore> if but someone else would pack it for me
[21:02] <persia> LimCore, Right, but I think acpi-support is going away, which makes it a little more complicated.
[21:02] <LimCore> it is going away? O_o ? why? what replaces it
[21:07] <LimCore> then what will be the way to have something executed on ACPI event?
[21:12] <persia> I'm not entirely sure how the new system is supposed to work : maybe Kernel -> HAL -> Dbus -> client?  Maybe ask in #ubuntu-devel, noting that you're working on that bug?
[21:12] <persia> (mind you it's not a great time to ask in #ubuntu-devel, but you might get lucky.
[21:12] <saivann> bdmurray : Thanks for your comments on the bug report!
[21:31] <LimCore> persia: that seems very bad
[21:32] <LimCore> persia: it is BAD decision imho to remove the wounderfull possiblity of simply having user defined scripts executed on ACPI events!
[21:32] <persia> LimCore, No, it's just changing the mechanism by which it's done.  That I don't understand the new mechansim shoulldn't be taken to indicate that it doesn't exist.
[21:33] <LimCore> well, we should keep it compatible - no mater what underlying mechnism, the same user(admin) defined scripts should be executed
[21:35] <persia> LimCore, Ask in -devel.  It may be that way, and I'm misunderstanding.
[21:36] <maco> thekorn_: when does the countdown reset back to 5?
[22:43] <rrittenhouse> I'm new at triaging. Can I get some help with #284434 ?
[22:43] <rrittenhouse> https://bugs.launchpad.net/ubuntu/+bug/284434
[22:44] <rrittenhouse> I'm unsure what other information would helpful in this case or what the next steps should be.
[22:44] <crimsun> well, first, the reporter should be running current intrepid
[22:45] <crimsun> there are several possible causes, and we really need the reporter running the latest kernel in intrepid for starters
[22:45] <persia> rrittenhouse, You want lspci -vvnn and lsusb -v as well, and to ask for a retest with a current daily.
[22:46] <crimsun> moreover, dmesg (or /var/log/dmesg from a daily-live)
[22:46] <rrittenhouse> ok
[22:49] <rrittenhouse> thank you.