[05:04] <vimpulse> hi all.  http://bugs.launchpad.net/ubuntu/+source/partman-auto/+bug/94382 (filed in 2007) says that the phrase "Guided - use entire disk" that ubiquity used is unclear.  The phrase it uses instead nowadays is still four words, but different: "Use the entire disk".  The new phrase is still unclear.  Should I file a new bug, or add to the current bug?
[05:05] <vimpulse> I would like the installer to use the phrase "Erase and use the entire disk" instead.
[05:14] <vimpulse> crosspasting to ##linux
[05:29] <vimpulse> never mind.  I decided to add the comment http://bugs.launchpad.net/ubuntu/+source/partman-auto/+bug/94382/comments/2 and to retitle the bug to ' "Use the entire disk" is unclear; please rename to "Erase and use the entire disk" '.
[06:00] <leoXsys> thurston: Welcome :) Now you can put your question here :)
[06:01] <thurston> LeoXsys: Thanks, I am about to do that right now :).
[06:04] <thurston> I am new to ubuntu, in fact a week old. I have downloaded and installed the latest version of Skype. I have noticed how Skype interferes with movie player and also the sound on the laptop. When Skype is running, video playback gets retarted and I lose sound totally. I have played about with different settings but the only remedy is when I quit Skype, then everything returns to normal. I have ubuntu Intrepid running on an "acer T
[06:04] <thurston> ravelMate 6292".
[06:04] <dtchen> yeah, that's Skype being crackful
[06:04] <dtchen> and until Skype has a native PulseAudio backend, things will continue to be crackful
[06:05] <dtchen> the best that can be done is to configure Skype to use PA for playback and hw:X for capture
[06:05] <dtchen> (or just drop PA totally and use ALSA only)
[06:10] <thurston> dtchen: Thank you for your advice, I made a quick change to PA for playback, applied the changes and it seems to have sorted my problem. I will monitor this for a while and will report back soon. Thanks again.
[06:11] <thurston> leoXsys: thank you again for guiding me here, it seems I have been sorted.
[06:17] <leoXsys> thurston: One more thing you can switch over from PA to ALSA using asoundconf-gtk, (Just install it from CLI sudo apt-get install asoundconf-gtk)
[06:19] <dtchen> leoXsys: asoundconf* is deprecated; we're completely removing it in karmic (and it has been removed in Debian unstable's alsa-utils)
[06:19] <leoXsys> dtchen: Okk...
[06:21] <leoXsys> leoXsys: Mostly it's helpful me to switchover between my ALSA / WL USB Headset / PA .
[06:36] <thurston> leoXsys, dtchen: Clearly then I will no be able to get asoundconf, even if I tried.
[06:44] <dtchen> thurston: you should not use asoundconf; it will make native ALSA apps route directly through alsa-lib instead of through PulseAudio
[06:44] <dtchen> thurston: you can rm ~/.asoundrc to work around any changes you've made with asoundconf*
[07:48] <thekorn> good morning
[07:48] <methril|work> morning
[09:51] <TheHobbit> hi
[10:04] <TheHobbit> There is something I do not understand in the definition of when an attacment can be defined a patch. Should it be something that can just be dropped in the debian/pathces directory?
[10:11] <thekorn> TheHobbit, I think https://wiki.ubuntu.com/Bugs/Patches has a good definition of a patch in ubuntu
[10:22] <TheHobbit> thekorn: ok, then the diff I found in the bug I'm loking at is a patch, if it works that is:)
[10:52] <TheHobbit> I hava another stupid question... unqualified patch numbers (those with just a sharp sign) in debian/changelog refers to debian bugs, right? which is then the right way to indicate that a patch closes a launchpad bug?
[10:53] <jpds> TheHobbit: (LP: #NNNN). (Closes: #NN) is for Debian.
[10:54] <TheHobbit> :)
[10:55] <TheHobbit> hmmm this leads me to think there is something to do in the debian tools for emacs... may be changing them in ubuntu tools, with minor differences..
[11:57] <TheHobbit> hmmmm I'm sorry, but I have another question... I'm working on a bug in the hugday list. I've verified that the attached diff is realy a patch, transformed it a dpatch patch in the correct directory, modified the changelog and build the new package
[11:58] <TheHobbit> I've installed it and verified it solves the bug
[11:58] <TheHobbit> what's next?
[12:03] <Hobbsee> subscribe ubuntu-universe-sponsors?
[12:05] <IntuitiveNipple> Create a debdiff between the current package version and the new version, attach that to the bug, then , I think, you need a Feature Freeze Exception (FFE) request? https://wiki.ubuntu.com/FeatureFreeze
[12:06] <Hobbsee> IntuitiveNipple: it's unlikely to be a feature...
[12:06] <IntuitiveNipple> I thought the "is a reasonable fix for an important bug" reason covered it?
[12:07] <Hobbsee> feature freeze only covers new features.  Bug fixes are totally separate
[12:07] <Hobbsee> (although the section you just quoted would be a "to fix this bug reasonably, we need to put in this feature")
[12:08] <BUGabundo> IntuitiveNipple Hobbsee hey
[12:08] <Hobbsee> hey BUGabundo
[12:08] <IntuitiveNipple> Hobbsee: Ahhh, that would make more sense
[12:09] <TheHobbit> hmmm the problem is, I'm not even sure that this bug should be fixed anyway :)
[12:09] <IntuitiveNipple> So a debdiff to make the change easy and subscribe the appropriate sponsor, then?
[12:09] <IntuitiveNipple> lol @ TheHobbit ... go on, why?
[12:10] <Hobbsee> by the sounds of it, it appears that TheHobbit has a debdiff already, as he's made one
[12:10] <TheHobbit> is 354912, which states that grsync is not in the "right" menu
[12:11] <TheHobbit> while I'm agree I'm not sure that other people would not disagree
[12:11] <TheHobbit> and as the "Network" menu is the one chosen by upstream...
[12:13] <TheHobbit> and, yes Hobbsee I have a debdiff
[12:15] <IntuitiveNipple> I wish openjdk didn't take so long and so much space to build. I've had to extend the encrypted LVM for /var/ twice so far!
[12:16] <IntuitiveNipple> I suspect /var/cache/ is going to be moved to it's own unencrypted LV
[12:27] <TheHobbit> hmmm I must go, anyhow, I posted the debdiff and set the status to confirmed, I hope this is enough,,, (I also signaled it closed on the HugDay list..)
[12:27] <TheHobbit> see you
[14:03] <BUGabundo> back
[14:42] <BUGabundo> I would like for bug 357719 to be marked wishlist. thanks
[14:46] <Hobbsee> (done)
[14:46] <BUGabundo> Hobbsee: thanks
[14:47] <BUGabundo> I really should apply to bug control team....
[14:47] <BUGabundo> but then ppl would pick on every little bit of stress I put in my words
[14:47] <BUGabundo> eheh
[14:54] <BUGabundo> hey pedro_ that was fast
[14:56] <pedro_> hola BUGabundo, yeap, just remember to set enhancement as a severity for upstream wishlist items :-)
[14:56] <BUGabundo> I did choose improvement
[14:56] <BUGabundo> guess != enhancement
[15:11] <hggdh> pedro_,  ping
[15:12] <pedro_> hggdh: hello
[17:51] <pedro_> Ubuntu QA Meeting at #ubuntu-meeting in ~9 minutes
[18:15] <YoBoY> hi
[18:18] <mdz> bdmurray: was it you who was working on an apport hook for alsa-info?
[18:18] <BUGabundo> YoBoY: hey! you have been missing !! eeh
[18:19] <bdmurray> mdz: no, I haven't done any work on that.  ogasawara and I were talking about separating sound bugs from kernel bugs and having a hook for alsa-driver.
[18:19] <mdz> bdmurray: I was talking with someone about it and can't remember who it was
[18:20] <bdmurray> mdz: the hook would have to be for a separate package (than linux) correct?
[18:22] <mdz> bdmurray: actually I would like to add it to hookutils and use it in any sound-related package
[18:23] <bdmurray> mdz: ah, that makes sense.
[18:23] <mdz> bdmurray: heh, I just checked and realized I already implemented it
[18:23] <mdz> it's just that no package uses it yet
[18:23] <mdz> bdmurray: hookutils.attach_alsa(report)
[18:24] <bdmurray> mdz: ah great!  I'll work on getting some packages set up with it then
[18:29] <mdz> bdmurray: I'll do alsa-driver
[18:37] <mdz> bdmurray:   Uploading alsa-driver_1.0.18.dfsg-1ubuntu8_source.changes: done.
[18:38] <mdz> bdmurray: this should make it possible to (e.g. for kernel bugs) run apport-collect -p alsa-base NNNNNN
[18:39] <bdmurray> mdz: You can add random package info to an existing bug?
[18:39] <mdz> bdmurray: yes!  bug 333875
[18:39] <mdz> bdmurray: spread the word
[18:41] <bdmurray> mdz: will do thanks for that information!
[18:45] <YoBoY> BUGabundo: missing? only today :D lot of work
[18:45] <BUGabundo> ahh nice to see you back!
[18:52] <mdz> bdmurray: I've also committed to apport (revision 1379) a new function, hookutils.attach_relevant_packages() which attaches version info for a set of packages (I saw this code duplicated in several hooks)
[18:53] <sbeattie> mdz: yay! I duplicated that code in a few places.
[18:55] <mdz> sbeattie: it should go in the next time pitti makes a release
[19:16] <mdz> bdmurray: I didn't realize there was no pulseaudio hook yet, I'll whip one up
[19:16] <mdz> bdmurray: I'm thinking attach_alsa + recent_syslog for pulseaudio.  anything else you think would be good?
[19:17] <mdz> bdmurray: I bet we could get a lot more good stuff with pulseaudio-utils, but that's not installed by default
[19:18] <dtchen> if attach_alsa does not include everything that alsa-info does, we'll still have to ask for alsa-info.
[19:19] <dtchen> something that alsa-info currently doesn't grab that would be useful is dmesg (filtered for codec messages) and /proc/interrupts
[19:19] <dtchen> some things*
[19:21] <mdz> dtchen: I went line-by-line through alsa-info.sh and included everything which made sense
[19:21] <dtchen> i'll look at it later and make additions as necessary
[19:21] <mdz> dtchen: I skipped basic things like version numbers because apport does those all by default
[19:22] <dtchen> oh, and we need fuser -v /dev/dsp* /dev/snd/* /dev/seq* [...]
[19:22] <mdz> dtchen: one thing I left out was alsactl -f - store
[19:22] <mdz> dtchen: that seemed redundant with the amixer output.  is there some subtle difference I missed?
[19:23] <dtchen> mdz: no, that should be fine
[19:24] <mdz>     report['AlsaDevicesInUse'] = command_output(
[19:24] <mdz>         ['fuser','-v'] + glob.glob('/dev/dsp*')
[19:24] <mdz>             + glob.glob('/dev/snd/*')
[19:24] <mdz>             + glob.glob('/dev/seq*') )
[19:24] <mdz> should do the trick
[19:24] <mdz> I'll add that to attach_alsa
[19:25] <dtchen> slight problem: it returns nothing useful as an privileged user.
[19:25] <dtchen> sorry, unprivileged
[19:26] <mdz> dtchen: it finds my own processes OK
[19:26] <mdz> perseus:[~] fuser -v /dev/snd/*
[19:26] <mdz>                      USER        PID ACCESS COMMAND
[19:26] <mdz> /dev/snd/controlC0:  mdz        3799 F.... mixer_applet2
[19:26] <mdz> it may not see pulseaudio since that runs with some privileges I believe
[19:27] <dtchen> right, and those apps are the ones that "cause problems"
[19:28] <mdz> we don't currently have access to elevated privs in this context, but I'll add it anyway and we can improve it later
[19:28] <dtchen> ok
[19:32] <mdz> dtchen: bzr commit -m 'apport/hookutils.py: Add fuser info and dmesg to attach_alsa'
[19:33] <mdz> dtchen: do you have any suggestions for things to add to pulseaudio beyond attach_alsa and syslog?
[19:34] <dtchen> mdz: /etc/default/pulseaudio, /etc/pulse/default.pa, and /etc/pulse/client.conf
[19:34] <mdz> dtchen: those are conffiles, so apport will get them automatically iff they're modified from the defaults
[19:35] <dtchen> mdz: ah, ok
[19:38] <dtchen> mdz: no, i think that covers it. ~/.pulse* really is only useful in special cases.
[19:38] <mdz> dtchen: ok, thanks
[19:38] <mdz> I'll upload pulseaudio with a hook shortly
[19:53] <mdz> bdmurray,dtchen: bug 357913
[19:57] <bdmurray> mdz: How does PciMultimedia get generated?
[19:57] <mdz> bdmurray:     report['PciMultimedia'] = pci_devices(PCI_MULTIMEDIA)
[19:59] <mdz> bdmurray: pci_devices uses lspci to find all of the devices with a certain PCI class
[20:00] <bdmurray> mdz: it seems like xorg might benefit from using that
[20:01] <bdmurray> it currently grabs all of lspci
[20:01] <mdz> bdmurray: yes, I'm surprised it doesn't already use that
[20:01] <bdmurray> mdz: I think they were written before the convenience functions
[20:02] <mdz> bdmurray: it should use pci_devices(PCI_DISPLAY)
[20:07] <bdmurray> mdz: looking at the compiz one it makes more sense to me to remove attach_hardware and add pci_devices(PCI_DISPLAY).  Do you think so?
[20:08] <maco> mdz: dan says he's missing the /proc/asound/card/Codec stuff from alsa-info.sh in the apport-bug that was just reported. he says unless it's just lag between uploading, he needs the codec info to be added to the apport alsa hooks
[20:08] <bdmurray> I didn't see it either
[20:09] <maco> he said for AC97 and A...um...something else...crap I can't type and listen at the same time
[20:09] <mdz> maco: which bug?
[20:09] <maco> i dont know, he hung up
[20:09] <bdmurray> mdz: your sample pulseaudio one
[20:09] <maco> yeah thats the impression i got
[20:09] <mdz> maco: it includes the entire contents of /proc/asound/cards
[20:10] <mdz> oh, no it doesn't
[20:10] <mdz> then again, I don't see why it would be needed either
[20:10] <maco> codec info's really important
[20:10] <mdz> maco: if you/he can let me know exactly what he wants in there, I can add it easily
[20:11] <maco>  i think it'd be /proc/asound/card*/Codec*
[20:12] <mdz> maco: those are directories; what should I pull out of there?
[20:12] <mdz> /proc/asound/card0/codec97#0
[20:12] <mdz> /proc/asound/card0/codec97#0/ac97#0-0+regs
[20:12] <mdz> /proc/asound/card0/codec97#0/ac97#0-0
[20:13] <maco> ac97 makes them into directories? lemme check alsa-info.sh. i only have intel to look at here
[20:13] <bdmurray> mdz: #Check for HDA-Intel cards codec#*
[20:13] <bdmurray> cat /proc/asound/card*/codec\#* > /tmp/alsainfo/alsa-hda-intel.tmp 2> /dev/null
[20:13] <bdmurray> from alsa-info.sh
[20:14] <maco> thanks
[20:14] <bdmurray> and then
[20:14] <bdmurray> cat /proc/asound/card*/codec97\#0/ac97\#0-0
[20:14] <bdmurray> cat /proc/asound/card*/codec97\#0/ac97\#0-0+regs
[20:17] <maco> mdz: i dont know anything about ac97, but at least in the hda category, codec's important in the way that can determine what hardware you should or shouldn't buy. sigmatel and realtek (hey great, both my laptops) are ones dan says are often problematic
[20:20] <calc> maco: just means you need to write the quirks for your system, its not too hard :)
[20:23] <mdz> bdmurray,maco: ok, thanks
[20:24] <mdz> pulseaudio takes ages to build
[20:27] <mrooney> can someone remind me what we do for a bug like bug 357877?
[20:27] <mrooney> that needs like 4 tags, doesn't it?
[20:27] <mrooney> regression-potential, suspend, resume, dell?
[20:28] <bdmurray> ogasawara: ?
[20:29] <mrooney> thanks :) I think the package is also linux for those
[20:29] <bdmurray> mrooney: a whole new bug report would probably be best I'm surprised apport didn't catch it
[20:29] <mrooney> bdmurray: yeah I have seen some seemingly automated suspend resume issues, how does that work?
[20:30] <bdmurray> there is an apportcheckresume script
[20:30] <jgoguen> bug 261595 should be set to High because of the data loss/corruption potential right?
[20:31] <bdmurray> mrooney: https://wiki.ubuntu.com/KernelTeam/SuspendResumeTesting/ has full details
[20:31] <maco> calc: yeah i know
[20:32] <maco> calc: that's what dan was teaching me about last summer
[20:32] <bdmurray> mrooney: so they should run that script to get the higher quality bug report
[20:32] <calc> maco: ah
[20:33] <mrooney> bdmurray: okay, shall I just link to that, asking them to run that, incomplete the bug, and invalidate it if they post a link to the new bug?
[20:34] <bdmurray> mrooney: sounds great
[20:34] <mrooney> also is this a dupe? bug 357928
[20:34] <mrooney> something about printing using notify-osd sounds familiar
[20:34] <maco> dont forget there are two printing systems installed by default
[20:35] <maco> there's that cups configuration thing from fedora too
[20:36] <maco> (that one's notifications seem to work fine, by way, though i think it ought to say "$file has been sent to the printer" instead of "$file has been printed" since it displays long before the printer even responds, let alone finishes)
[20:38] <mrooney> bdmurray: is there any way to investigate why apport didn't catch that suspend issue?
[20:41] <bdmurray> mrooney: I don't know specifically but would check with the kernel team
[20:44] <mdz> bdmurray,maco: bzr commit -m 'apport/hookutils.py: Add codec info to attach_alsa'
[20:46] <mdz> dtchen: I must have overlooked that, but it'll be there with the next apport upload
[21:48] <javito> hi
[22:20] <ausimage> hello I believe bug 320393 is not related to the remote desktop server perse...
[22:20] <ausimage> That aludes xrdp and I have the same bug in tightvncserver
[22:21] <ausimage> does anyone know what package in gnome it should go against instead?
[22:22] <ausimage> the workaround is turning off /apps/gnome_settings_daemon/plugins/keyboard
[22:22] <ausimage> and I could not believe the bug was incomplete either :/
[22:23] <ausimage> just cause there was no backtrace
[22:23] <ausimage> the bug here does not generate a crash... just a miscommunication :/
[22:23] <ausimage> IMHO
[23:41] <jgoguen> bug 261595, this should be set to High because of data loss/corruption potential?
[23:49]  * ausimage spies that Jaunty is now RC :)
[23:50] <ausimage> at least that is what the change logs indicate
[23:51] <ausimage> oops wrong channel :S