[01:08] <dtchen> calc: not necessary at this point; we've already narrowed it down. In short, alsa-kernel and alsa-lib are broken for all cards. Fix is in progress.
[01:09] <dtchen> calc: it seems disabling PREEMPT and HZ=1000 in our kernel config makes the bug easier to trigger, so we should thank the kernel team for that
[02:07] <cactaur> Hey everyone! I'm caught in a dilemma. I installed Intrepid and experienced a crippling (for me) bug which renders me unable to use my Desktop's internet. I did work on a bug report, which there hasn't been much activity on recently, but I'm not sure how much longer I can go without internet on my Desktop. So, I'm planning on reinstalling Hardy, but that would mean that I can no longer work on that particular bug. Does anyone have ideas on ho
[02:07] <cactaur> w I can get internet on my Desktop and at the same time be able to supply the bug report with needed information, cause that's one bug I really want squashed (though I can't program).
[02:07] <maco> dual boot?
[02:10] <cactaur> Hmm.... that would work, but is there another way? Cause then I think I'll have issues trying to unify the two if the bug is squashed.
[02:11] <maco> well is it a driver bug?
[02:11] <hggdh> cactaur, at least give us the bug #
[02:11] <maco> i wonder if just booting different kernels would work
[02:11] <cactaur> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/293424
[02:11] <maco> what?
[02:11] <maco> i cannot duplicate that bug
[02:12] <maco> i have an iwl3945 laptop that i used with wep while i was at my parents'
[02:12] <cactaur> maco: Did you use a passphrase?
[02:12] <maco> and...actually it worked even with network manager, now that i think about it. it used to only work from the command line
[02:13] <maco> and it showing a different value after youve entered it when you tell it to show the stored key is normal. in any chipset, nm keeps showing the hash of the key instead of the real key
[02:13] <cactaur> maco: Actually, I was kinda confused with it, cause I'm experiencing the same symptoms with an entirely different chipset. So, I wasn't sure whether to comment on it, or just file a new bug.
[02:13] <maco> i was using a hex thing
[02:14] <maco> are you able to connect if you just use the command line?
[02:15] <cactaur> maco: No, dhclient gets a DHCPREQUEST, but ignores it (see the link to the forum post on my comment for the output)
[02:15] <maco> though i may have already been running jaunty by that point...
[02:15] <maco> on hardy i had to use the command line for wep. in jaunty it works fine even with NM. not sure about itrepid
[02:15] <maco> forum post...
[02:15] <maco> looking
[02:20] <calc> dtchen: great... i think :)
[05:41] <dholbach> good morning
[06:59] <thekorn> good morning
[07:38] <YoBoY> hi
[07:38] <YoBoY> bug 334596 -> wishlist
[07:40] <dholbach> YoBoY: that's a request for getting a new version uploaded - not suitable for brainstorm
[07:40] <YoBoY> arf ^^"
[07:40] <YoBoY> what i have to put for things like this?
[07:43] <dholbach> I'm taking care of this one
[07:43] <YoBoY> ok tanks :)
[07:44] <YoBoY> lol, 3 comments ? xD you need coffee ^^
[07:50] <YoBoY> bug 334563 -> wishlist
[07:59] <savvas> hey, why is "needs-upstream-report" tag kubuntu-specific ?
[08:00] <savvas> it could be used for ubuntu as well, there are a lot of bugs that are practically begging to be forwarded upstream
[08:04] <YoBoY> bug 334479 -> invalid
[08:07] <dholbach> savvas: I don't see why the tag should be used at all - we can simply open en empty upstream task
[08:08] <dholbach> savvas: and can query it from the advanced bug page
[08:08] <persia> I think the use of the tag predates the wide definition of upstream projects.
[08:08] <dholbach> persia: I think tags came after upstream tasks in LP :)
[08:08] <savvas> dholbach: could you give me an example query link in launchpad?
[08:08] <dholbach> savvas: hang on
[08:08] <savvas> thanks :)
[08:09] <persia> dholbach, No, after definitions.  We now have most of the upstream projects defined, but that wasn't always true.  That said, I could well be mistaken.
[08:10] <dholbach> savvas: on the advanced bug page it's "Show bugs that need to be forwarded to an upstream bug tracker "
[08:11] <dholbach> savvas: https://bugs.launchpad.net/ubuntu/+bugs?field.status_upstream-empty-marker=1
[08:11] <dholbach> all Ubuntu bugs with an empty upstream task
[08:12] <savvas> that's amazing! thanks :D
[08:12] <savvas> let me reply to my own email :P
[08:12] <dholbach> :)
[08:24] <savvas> "Displaying first 80 comments.  View all 1005 comments or add a comment. " :P
[08:38] <savvas> mvo: hey, the patch for bug 190907 is working correctly! just tested it in greek - the other user probably didn't do something correctly
[08:39] <mvo> savvas: thanks for confirming!
[08:39] <mvo> savvas: after alpha-5 I will merge it
[08:39] <savvas> great, thanks :)
[08:40] <savvas> 09:38:55 < savvas> mvo: hey, the patch for bug 190907 is working correctly! just tested it in greek - the other  user probably didn't do something correctly
[08:40] <savvas> oops
[08:40] <savvas> sorry
[08:40] <mvo> np
[13:01] <kaushal> hi
[13:02] <kaushal> I am looking out for a Bug which is relevant with tomcat application server which does not log in Catalina.out file in Ubuntu Server 8.04
[14:55] <bddebian> Boo
[15:12] <patanachai> Hi
[15:13] <patanachai> Should bug #334669 > invalid ?
[15:15] <hggdh> patanachai, ask the reporter if he has more details -- what was updated, etc. It is possible that some critical components were upgraded, and an inconsistent state reached... so yes, it is a candidate for INVALID
[15:15] <hggdh> patanachai, but first ask for more details
[15:15] <patanachai> thanks
[15:16] <hggdh> welcome. Thank you for helping.
[15:45] <Laibsch> Hi
[15:45] <Laibsch> Did anybody else ever experience high WLAN load resulting in a drifting mouse? -> bug 334957
[15:46] <Laibsch> If it wasn't so annoying, it'd be one of the more funny bugs
[15:50] <IntuitiveNipple> shared interrupts issue maybe?
[15:54] <Laibsch> IntuitiveNipple: BIOS?
[15:54] <Laibsch> Where do I look
[15:55] <IntuitiveNipple> Start with cat /proc/interrupts and also look in the dmesg or kern.log to determine what interrupts the hardware is assigned
[16:02] <Laibsch> thanks
[16:10] <Laibsch> IntuitiveNipple: Seems like indeed they are using the same interrupt
[16:10] <Laibsch> I'll reboot in a little while and see if I can change something in the BIOS
[16:11] <Laibsch> In case that is not possible, is there anything on the software side that could be improved?
[16:11] <IntuitiveNipple> Laibsch: Sharing interrupts isn't bad, but in some circumstances drivers can get confused
[16:11] <IntuitiveNipple> Laibsch: Does /cat/interrupts show an unusually larger number of interrupts for their shared IRQ # ?
[16:12] <Laibsch> I added the output to the bug
[16:12] <Laibsch> unfortunately, the tabs were collapsed to single white space and thus the output isn't cleanly formatted
[16:12] <Laibsch> The information is there, though
[16:13] <Laibsch> IntuitiveNipple: is what you are asking for the second column, 1897568 in this case?
[16:13] <Laibsch> Not sure if that would be high or not.
[16:14] <IntuitiveNipple> what kind of mouse is it?
[16:16] <hggdh> Laibsch, this is the interrupt count since the last reboot
[16:17] <hggdh> sort of high, yes, unless the system has been up for quite a long time (think weeks or months)
[16:18] <IntuitiveNipple> It looks like almost everything wants to share #11
[16:18] <Laibsch> $ uptime
[16:18] <Laibsch>  01:18:30 up 21:11,  5 users,  load average: 2.49, 1.17, 0.88
[16:18] <Laibsch> yes, everything is on #11, more or less
[16:22] <Laibsch> IntuitiveNipple: It is a USB mouse from Logitech, I think the name is MX310, that is what is says on the underside
[16:26] <IntuitiveNipple> Laibsch: OK, nothing ultra high resolution then
[16:27] <IntuitiveNipple> It does look as if somehow the input driver is seeing spurious interrupts. I've seen it before on both Windows and Linux.
[16:27] <Laibsch> Alright, what I should do now?
[16:28] <Laibsch> To resolve the situation for me, I'll see if I can do something in the BIOS
[16:28] <Laibsch> to get the mouse onto another interrupt
[16:28] <Laibsch> But what about the bug report.  I wonder if there is some information I could provide that would help improve the driver.
[17:39] <Kaushal> hi
[17:40] <Kaushal> Good Afternoon everyone
[17:45] <hggdh> cheers
[17:47] <Kaushal> hggdh, I was looking for a Bug which i dont recollect the Bug ID which was regarding no logging in Catalina.out file of tomcat application server
[17:47] <Kaushal> I think its being closed
[17:47] <Kaushal> is the issue fixed ?
[17:48] <hggdh> Kaushal, did you try LP advanced searc (and make sure you select also the closed stati)
[17:48] <Kaushal> hggdh, i could not locate it in http://bugs.launchpad.net
[17:49] <Kaushal> I have also used the Advanced search too
[17:51] <hggdh> hold on
[17:52] <Kaushal> sure
[17:52] <hggdh> you opened it agaisnt which package?
[17:53] <Kaushal> Ubuntu 8.04
[17:53] <hggdh> give me some possible search terms
[17:54] <Kaushal> no logging in catalina.out file
[17:56] <YoBoY> Kaushal: have you commented this bug?
[17:57] <Kaushal> YoBoY, i have not commented on that Bug
[17:58] <Kaushal> Actually I am looking out for that Bug which i wanted to discuss with my Engg team
[17:59] <YoBoY> not one of these ? https://bugs.launchpad.net/ubuntu/+bugs?field.searchtext=Catalina&orderby=-importance&search=Search&field.status%3Alist=NEW&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=FIXCOMMITTED&field.assignee=&field.bug_reporter=&field.omit_dupes=on&field.has_patch=&fi
[17:59] <YoBoY> eld.has_no_package=
[17:59] <hggdh> but you opened it
[17:59] <YoBoY> (arg sorry)
[18:00] <hggdh> Kaushal,  what is you userid on LP?
[18:01] <Kaushal> hggdh, i dont think so i have one
[18:01] <hggdh> if you do not have a LP Id, you cannot open a bug there...
[18:02] <Kaushal> hggdh,Let me explain it briefly
[18:03] <Kaushal> I have installed Ubuntu 8.04 Server and installed tomcat on it using apt-get
[18:04] <Kaushal> so when i uploaded my WAR into it, i could not see any logging in Tomcat Catalina.out file
[18:05] <hggdh> but you did not open a bug
[18:05] <Kaushal> nope
[18:05] <Kaushal> I saw a similar Bug being opened by someone else
[18:05] <Kaushal> but now i am not able to trace that Bug ID
[18:06] <Kaushal> so wanted to know is that Bug resolved
[18:07] <hggdh> ah
[18:08] <hggdh> well, we are even more limited than you there... we know less than you on this particular issue.  YoBoY's search is pretty much what I found also
[18:08] <Kaushal> ok
[18:10] <Kaushal> hggdh, so is it difficult to get that Bug ?
[18:12] <hggdh> given what you told us, this is as far as we can get
[18:13] <IntuitiveNipple> Kaushal: Have you looked in /var/log/syslog ?
[18:13] <Kaushal> IntuitiveNipple, yes
[18:13] <IntuitiveNipple> nothing there from Tomcat?
[18:14] <Kaushal> nothing
[18:14] <IntuitiveNipple> which version of tomcat is it?
[18:14] <Kaushal> tomcat 5.5.25
[18:16] <Kaushal> IntuitiveNipple, is it https://bugs.launchpad.net/ubuntu/+source/tomcat5.5/+bug/303058
[18:16] <Kaushal> ?
[18:18] <IntuitiveNipple> I was going to suggest that one to you... you tell me :)
[18:18] <IntuitiveNipple> I was just looking at a Hardy installation to see what is there. No file in /var/log/tomcat5.5/
[18:19] <Kaushal> IntuitiveNipple, is there a workaround for https://bugs.launchpad.net/ubuntu/+source/tomcat5.5/+bug/303058
[18:20] <IntuitiveNipple> Kaushal: I don't know. You might want to check /etc/tomcat5.5/logging.properties
[18:23] <IntuitiveNipple> Are you using the standard sever.xml?
[18:24] <Kaushal> IntuitiveNipple, yeah
[18:25] <IntuitiveNipple> OK. Have you started Tomcat manually at a console and looked at what it reports for clues?
[18:25] <Kaushal> nope
[18:26] <Kaushal> How can i start manually >
[18:26] <Kaushal> ?
[18:30] <IntuitiveNipple> I don't have it installed here on Jaunty, but I've chroot-ed to the Hardy install to see what it does. The most obvious thing is in the /etc/init.d/tomcat5.5 script where it starts it and sets SYSLOG for console output: "$DAEMON -user "$TOMCAT5_USER" -cp "$JSVC_CLASSPATH" -outfile SYSLOG -errfile SYSLOG  -pidfile "$CATALINA_PID" $JAVA_OPTS "$BOOTSTRAP_CLASS"
[18:32] <IntuitiveNipple> The reason is, according to both the man-page and "start-stop-daemon --help" -outfile -errfile don't exist
[18:33] <Kaushal> ok
[18:33] <IntuitiveNipple> Have you tried the solution suggested in #277508 ?
[18:34] <Kaushal> IntuitiveNipple, great
[18:34] <Kaushal> I would use that workaround
[18:34] <Kaushal> IntuitiveNipple, Thanks a Lot
[18:35] <thekorn> hi bdmurray, can you please renew my membership in bughelper-dev
[18:35] <Kaushal> IntuitiveNipple, you said <IntuitiveNipple> The reason is, according to both the man-page and "start-stop-daemon --help" -outfile -errfile don't exist
[18:35] <Kaushal> what did you searched for the man page
[18:35] <IntuitiveNipple> Kaushal: Yes, I'm not convinced those options exist since I can't find any other uses of them either, but I wondered if you're tried #277508 suggestion?
[18:35] <Kaushal> Just curious to know
[18:36] <IntuitiveNipple> Kaushal: man start-top-daemon
[18:36] <IntuitiveNipple> Kaushal: or start-stop-daemon --help
[18:36] <IntuitiveNipple> Kaushal: I'd always trust the program over the man-page since man-pages can and do get out-of-date
[18:37] <IntuitiveNipple> Kaushal: My bet is that init.d/ script was designed to work across several different Linux distributions, and the one it was tested on, a different start-stop-daemon is used that does accept -outfile -errfile
[18:38] <Kaushal> IntuitiveNipple, ok
[18:40] <Kaushal> IntuitiveNipple, so it should work if i use #277508
[18:40] <Kaushal> right
[18:40] <bdmurray> thekorn: you are an admin of the team ;-)
[18:41] <thekorn> bdmurray, right, but I can't renew my own membership
[18:41] <IntuitiveNipple> Kaushal: *only* if start-stop-daemon supports -outfile and -errfile
[18:41] <bdmurray> that's weird
[18:42] <thekorn> that's launchpad ;)
[18:43] <IntuitiveNipple> Kaushal: Which JVM are you using to host tomcat?
[18:43] <Kaushal> IntuitiveNipple, I am using sun-java5-jdk
[18:43] <IntuitiveNipple> I've installed tomcat5.5 on Jaunty here and it is logging to syslog, but I noticed in its /etc/init.d/tomcat5.5 it says "# juli LogManager disabled if running under gij (see bug #395167)" - and the logging is set by default to use apache juli
[18:44] <Kaushal> IntuitiveNipple, start-stop-daemon doesnot support -outfile or -errfile
[18:44] <IntuitiveNipple> Kaushal: lol ignore me about -outfile.... I just noticed it uses /usr/bin/jsvc as the DAEMON !! :*blush*
[18:45] <Kaushal> It wont work
[18:45] <IntuitiveNipple> That'll teach me to read the init script clearly
[18:46] <IntuitiveNipple> Kaushal: jsvc.exec[1779]: 26-Feb-2009 18:41:39 org.apache.coyote.http11.Http11BaseProtocol init INFO: Initializing Coyote HTTP/1.1 on http-8180
[18:50] <Kaushal> IntuitiveNipple, so that suggestion wont work
[18:50] <Kaushal> right ?
[18:50] <IntuitiveNipple> It *might* now I realised it uses jsvc
[18:58] <Kaushal> IntuitiveNipple, where do i seek help for this issue ?
[18:58] <IntuitiveNipple> You should post a new bug report and describe the versions and what precisely you are doing and assign it to the tomcat package so the package maintainers get pinged
[18:59] <Kaushal> great
[19:11] <savvas> can someone set bug 267513 as Triaged please?
[19:21] <hggdh> savvas, done. I thought you would be able to do it yourself...
[19:24] <salty-horse> hi. using jaunty, /var/log/messages shows a usb device is connected, but nautilus doesn't mount it (set the correct options in nautilus's preferences). any ideas?
[19:24] <savvas> hggdh: I didn't apply to be a bug triager :)
[19:25] <savvas> not yet that is :P
[19:56] <hggdh> heh
[20:32]  * bcurtiswx waves to room
[20:32]  * Ienorand waves back
[21:38] <bcurtiswx> seb128: was my response alright in the rhythmbox bug? or should I have gone about that differently? j/w
[21:39] <seb128> bcurtiswx: bug number? I look to 60 rhythmbox bugs or so today and didn't pay attention to the submitter nicknames
[21:39] <seb128> look -> looked
[21:39] <bcurtiswx> seb128: bug #335062
[21:39] <seb128> bcurtiswx: yes, it's good!
[21:39] <seb128> that's the right stock reply for such bugs ;-)
[21:40] <bcurtiswx> seb128: ok thx, always trying to learn wherever i ca n
[21:40] <bcurtiswx> can*