[01:57] <jgoguen> Bug 397504, would that be Low because the most common IRC commands have GUI alternatives, or Medium because this makes Empathy unusable as an IRC client if commands without GUI alternatives are needed?
[01:57] <ubot4> Launchpad bug 397504 in empathy "Basic IRC commands not working (Karmic)" [Undecided,Confirmed] https://launchpad.net/bugs/397504
[01:58] <hggdh> jgoguen, I would mark it as medium. This was the reason I quit using empathy right now...
[01:58] <micahg> hggdh: shouldn't it be high since empathy will be default in karmic?
[01:59] <hggdh> micahg, yes, you are correct. High it is.
[01:59] <jgoguen> But IRC isn't installed for Empathy by default
[01:59] <jgoguen> Or is that another bug :)
[02:00] <hggdh> heh.
[02:00] <hggdh> BTDNW. (Bloody thing does not work)
[02:00] <jgoguen> +1
[02:01] <hggdh> jgoguen, still, I think micahg is correct. If Empathy is going to be the default, it has to perform
[02:01] <jgoguen> Sounds good, High it is
[02:01]  * hggdh meanwhile still suffers on xchat
[02:03] <hggdh> well, to be honest, this is also because I am used to /this and /that on IRC, and prehaps empathy dev will elect not to use them.
[02:03] <jgoguen> From the upstream bug, I think they're leaning toward "not a bug"
[02:04] <hggdh> to even more honest, this might, perhaps, be also caused by a bit of not-so-kosher wine during dinner. But, of course, this would not be the case (or cause ;-))
[02:04] <jgoguen> Except that there's no replacement for /kick, /ban, /part.../quit and /join are just annoying
[02:04] <micahg> from what everyone said before I don't know what the rush is to have it in karmic
[02:05] <jgoguen> Neither do I, it's behind Pidgin in functionality and stability IMO
[02:05] <jgoguen> And apparently also can't connect to Groupwise servers, which means I can't use it at work...
[02:06] <Pici> Is there at least a /quote or /raw command?
[02:06] <hggdh> micahg, I do not know either. I do know that empathy devs are doing their best, and empathy (or telepathy) does have an interesting future
[02:06] <hggdh> Pici, not one that I could find
[02:07] <jgoguen> Pici: No, only /me works
[02:07] <Pici> :(
[02:07] <hggdh> and barely
[02:07] <jgoguen> The user list doesn't distinguish users from users with voice or ops either
[02:07]  * micahg will stick with Pidgin :)
[02:08]  * hggdh will still stick with <shudder/> xchat. irssi turned out to require more effort than expected
[02:08] <maxb> I actually like xchat. and irssi
[02:09]  * micahg wants to learn irssi so as to always be on :)
[02:09] <hggdh> maxb, get someone to start an encrypted session with you. Then you may reconsider xchat. irssi is cool, just requires a bit of relearning shortkeys, and I was not in the mood for that
[02:09] <maxb> irssi has a builtin proxy module - when I use xchat, I just connect it to my existing irssi session :-)
[02:10] <micahg> hggdh: who would that be that starts encrypted sessions ;)
[02:10] <hggdh> micahg, I would respectfully beg not to answer ;-)
[02:11] <hggdh> maxb, this proxying is cool. I wil reconsider, now
[02:11]  * micahg was inferring his own guilt
[02:11]  * hggdh did not want to throw blame on anyone but the beastly programme
[02:12] <hggdh> program
[02:16] <LimCore> my hard drive still fails...  sata link dies, any ideas? https://bugs.launchpad.net/ubuntu/+source/linux-meta/+bug/409639
[02:16] <ubot4> Launchpad bug 409639 in linux-meta "sata hard drive connection fails with link is slow to respond, please be patient (ready=0) ; SRST failed (errno=-16) ; hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK,SUGGEST_OK" [Undecided,New]
[02:17] <hggdh> LimCore, looking at it
[02:19] <LimCore> I bought 1 TB hard drive,  and linux tell me I have a new 1 TB device, and also a 2 TB one; Oh man if this is true then this is the best hardware shop ever
[02:28] <LimCore> hggdh: I added a comment with a bit more details
[02:30] <LimCore> Also there seem to be.... typos in the /var/log/messages O_o   Perhaps this is another bug being exposed by this bug causing so many errors being logged (thousands at once) ?    Or some memory corruption resulting from, or causing, the SATA problem.   https://bugs.launchpad.net/ubuntu/+source/linux-meta/+bug/409639/comments/1
[02:30] <ubot4> Launchpad bug 409639 in linux-meta "sata hard drive connection fails with link is slow to respond, please be patient (ready=0) ; SRST failed (errno=-16) ; hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK,SUGGEST_OK" [Undecided,New]
[02:36] <LimCore> if any feedback or ideas or tests to do then please comment there (Im idle)
[02:40] <hggdh> LimCore, sorry got a call, back to it now
[02:41] <Slick666> hi all, just wanted to let you folks on the bugs channel that the syracuse are NY loco is having it's own bug jam
[02:41] <Slick666> https://wiki.ubuntu.com/NewYorkTeam/Events/20090808
[02:42] <Slick666> It's kind of a test run of the facility and partly something easy that we can put togeather
[02:42] <Slick666> just thought you guy would get a kick out of it
[02:44] <hggdh> Slick666, good! Consider announcing it on planet (if you have access), and on the mailing lists
[02:46] <hggdh> LimCore, I myself have had two instances of unresponsive SATA, resolved on reboot. There is always the chance yours is caused by a real faulty drive, or SATA hardware, but I really do not know what else you should do
[02:46] <Slick666> I've already hit up the regional mailing lists
[02:46] <Slick666> but I'm missing the "planet" reference
[02:46] <hggdh> LimCore, a temp of 80C is sort of high, but I do not know how this would impact you...
[02:47] <Slick666> oh, http://planet.ubuntu.com/ cool
[02:48] <hggdh> Slick666, planet is the channel Ubuntu member have to publish blogs (although I personally have never used it, I do not think I have much of importance to publish)
[02:48] <hggdh> LimCore, could you try booting with Karmic, and trying it off the liveCD to see how it behaves?
[02:56] <LimCore> hggdh: I could try that in few days
[02:56] <hggdh> cool.
 LimCore, FAR too high    <ceil420> i can barely stand 30 C, personally   <LimCore> wtf?    <ceil420> (oh, you mean hardware)
[02:57] <hggdh> heh
[03:01] <LimCore> hggdh: you think this could be a driver/kernel issue?
[03:02] <hggdh> LimCore, it might be. There were many changes from 2.6.28 to 2.6.31; also, temperature might be a factor (not only CPU temp, but temps around the mainboard)
[03:03] <LimCore> can kernel execute full reboot of a device and it's link, as full as on reboot?
[03:03] <LimCore> "full power cycle" etc
[03:03] <LimCore> or only reset/power switch
[03:04] <hggdh> yes, it can do a cold boot. Power switch is also easily done, if in doubt
[03:04] <LimCore> if yes then  this kernel could  be better at auto-fixing the problemn
[03:04] <LimCore> mhm, I ment,  could it fully reset hdd + sata controller, without restarting system
[03:04] <LimCore> if yes then it should
[03:04] <LimCore> in such case
[03:05] <hggdh> for a while (I think at the beginning of the Karmic cycle) I was getting warn reboots (i.e., no BIOS). Now I get BIOS reboot
[03:05] <hggdh> so if BIOS would reset the controllers, you are good to go. Otherwise, a power cycle is needed
[03:06] <hggdh> ("power off, count to ten, power on again" type. Of course, I would wait longer to allow for capacitors discharge)
[03:51] <hggdh> Esta alma, que sedenta e si não coube,
[03:51] <hggdh> no abismo vos sumiu dos desenganos.
[04:07] <micahg> ping hggdh
[11:26] <gnomefreak> what bug would we file running processes under? example ps aux |grep gdm shows 6. IMHO 6 is a bit high
[11:26] <gnomefreak> someone else has 102 udevd running
[11:27] <ogra> erm
[11:27] <ogra> did you look what processes these 6 are actually ?
[11:27] <ogra> your grep is quite broad
[11:27] <gnomefreak> yes lib bin ect..
[11:28] <ogra> gdm runs a complete gnome session nowadays and was split into multiple binarys
[11:28] <gnomefreak> oh
[11:28] <ogra> (assuming you talk about karmic)
[11:28] <gnomefreak> ogra: yeah
[11:28] <gnomefreak> http://paste.ubuntu.com/248566/
[11:28] <ogra> right, completely new design
[11:29] <kklimonda> gnomefreak: you should see ps aux |grep gvfs ;)
[11:29] <gnomefreak> ok thanks. im guessing 102 udevd processes is too many and file under udevd?
[11:30] <gnomefreak> kklimonda: 6
[11:30] <kklimonda> heh, it's 12 for me :)
[11:31] <gnomefreak> i only have a terminal open
[11:31] <gnomefreak> ok X keeps restarting
[11:31] <gnomefreak> thats bad
[11:32] <gnomefreak> restarting maybe flickering is better word
[16:06] <bddebian> Boo
[19:33] <Chris_S> I have a bug report etiquette question (which I hope is appropriate for here): if a bug I submitted gets its status updated to Invalid, what is the correct/best way to disagree with the new status? Is writing a comment explaining why sufficient, or should I change the status back to New? (This is bug 407459 if anyone wants to look at the specifics.)
[19:33] <ubot4> Chris_S: Error: Could not parse data returned by Launchpad: The read operation timed out
[19:36]  * hggdh kicks ubot4
[19:36] <hggdh> bug 407459
[19:36] <ubot4> Launchpad bug 407459 in procmail "Procmail opens $HOME/.procmailrc before dropping setuid permissions" [Undecided,Invalid] https://launchpad.net/bugs/407459
[19:40] <hggdh> Chris_S: just reopen NEW. It owuld be good if you could provide such an attack^b scenario. I do not have NFSs, so cannot really show it
[19:40] <hggdh> Chris_S: you can also go to #ubuntu-hardened, and discuss it there
[19:42] <Chris_S> Okay, thanks; I've reopened/reset it to New status. I'll look into #ubuntu-hardened too.
[19:43] <Chris_S> (An attack scenario doesn't need NFS, just I think pointing $HOME/.procmailrc to something that has side effects when opened, especially by root.)
[19:47] <hggdh> Chris_S: agreed. But I do not have -- say -- a tape either... and no test system right now I am willing to sacrifice to the gods of correct triage ;-)
[19:53] <ssam> grip has been dropped from karmic (and debian http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=515887 ). should its old bugs be marked invalid (with a message explaining why)?
[19:53] <ubot4> Debian bug 515887 in ftp.debian.org "RM: grip -- RoM" [Normal,Open]
[19:54] <ssam> ditto for the last xmms bug #139754
[19:54] <ubot4> Launchpad bug 139754 in xmms "[GUTSY] XMMS is missing the Flac plugin from repositories" [Undecided,Confirmed] https://launchpad.net/bugs/139754
[20:05] <hggdh> ssam: they may be out of karmic, but still valid on previous supported releases (although the chance of getting a fix is probably low)
[20:08] <ssam> what about xmms, i think that was last in dapper.
[20:11] <hggdh> xmms itself was last on dapper (which is still supported); a series of xmms-* are also available on Gutsy/Hardy; xmms2 seems to have replaced (if indeed they are the same thing) from there on
[20:12] <hggdh> I remember reading something about xmms, I think on the -devel (or -devel-discuss) mailing lists some time ago
[20:12] <ssam> isn't dapper only supported on the server now?
[20:13] <ssam> xmms2 is a rewrite, so the bug would not apply there
[20:14] <hggdh> yes, only on the server (for dapper)
[20:15] <hggdh> so if the bugs are on the desktop, you could go ahead and close them
[20:15] <hggdh> oups
[20:16] <hggdh> ssam: I beg your pardon. bug 139754 was opened against gutsy, so it is a drop indeed
[20:16] <ubot4> Launchpad bug 139754 in xmms "[GUTSY] XMMS is missing the Flac plugin from repositories" [Undecided,Confirmed] https://launchpad.net/bugs/139754
[20:17] <ssam> its confusing, packages.ubuntu.com says does not list a gutsy package for gutsy, only for dapper. is that because gutsy is EOL even though its newer
[20:17] <maxb> yes
[20:18] <ssam> https://launchpad.net/ubuntu/+source/xmms lists a hardy package, and then that its deleted, does that mean it was only in hardy during development
[20:18] <maxb> yes
[20:19] <hggdh> now I would like a question where maxb could answer 'no' ;-)
[20:20] <ssam> is there a such a question, maxb?
[20:20] <ssam> :-)
[20:21] <maxb> yes
[20:21] <hggdh> darn!
[20:22] <hggdh> would you answer no if I asked you to answer yes?
[20:22] <ssam> mental note: in april 2011 close these bugs https://bugs.launchpad.net/ubuntu/+source/grip
[20:23] <hggdh> ssam: you can always ask if it is still an issue for the reporter
[20:26] <ssam> i suspect they have not been fixed. grip upstream version has been at 3.3.1 since 2008
[20:26] <ssam> 2005 sorry
[20:28] <hotblack23> Hi, any xorg specialists here that can take a look at launchpad bug 380009?
[20:28] <ubot4> Launchpad bug 380009 in xorg-server "[Needs quirk] Huge font in GDM on HP Compaq nc8430" [Undecided,New] https://launchpad.net/bugs/380009
[20:29] <hggdh> yes. But the reporter may have gone to a different option. If grip is dead at Debian, and upstream development orphaned/abandoned/went MIA, then -- unless and until someone takes it over, we will drop (have already dropped) it here
[20:34] <ssam> should i do a message along the lines of "Are you still suffering from this issue? Grip is no longer being maintained by upstream or debian, it will be dropped from Karmic (unless someone takes over maintenance), hence the change of this being fixed is small." and set to needs info
[20:35] <ssam> (i reported one of the bugs :-) )
[20:35] <ssam> s/needs info/incomplete/
[21:39] <kamusin> what status should I mark for some report that is not a bug exactly?, actually is a default parameter set in his configuration file (sudo package)
[21:42] <micahg> Well, if it's a support request (i.e. how to configure) you can convert to question
[21:43] <hggdh> kamusin, what is the bug # ?
[21:48] <kamusin> yep but this person think is a bug
[21:48] <kamusin> bug #410022
[21:48] <ubot4> Launchpad bug 410022 in sudo "sudo doesn't propagate $PWD" [Undecided,New] https://launchpad.net/bugs/410022
[21:51] <BUGabundo> hey guys
[21:54] <hggdh> kamusin, I agree this is not a bug. The user can set any environment variables needed to be maintained by editing env_keep
[21:55] <hggdh> you can transform it into a question, as micahg pointed out, and then go ahead and answer it there ;-)
[21:55] <kamusin> okidoki! thanks hggdh
[21:56] <hggdh> you aew welcome, kamusin. Thank you for helping
[21:59] <kamusin> hggdh: no problem sir ;)
[22:32] <grepory> hmmm