[02:23] <sagaci> about to file a bug, is it ok to link to a screenshot of the bug?
[02:54] <ali1234> sagaci: you can add it as an attachment, then it won't get lost. but generally it's fine...
[02:55] <ali1234> sometimes i link to youtube videos of bugs :)
[02:55] <ali1234> make sure there's nothing private in the screenshot though
[02:58] <sagaci> righteo thanks, didn't even see the attachment link :P
=== abhinav_ is now known as abhinav-
[09:37] <somethinginteres> hi all, wanting to test a diff patch at https://bugs.launchpad.net/ubuntu/+source/festival/+bug/778619 - how would a newbie such as myself go about applying the diff to test it? Thanks. Looked at the man pages already but looking for specific guidance on this case.
[09:37] <ubot4> Launchpad bug 778619 in festival (Ubuntu) "Festival TTS starts 'paused' for blocks of text (affects: 1) (heat: 8)" [Undecided,New]
[14:13] <trinikrono> hey is a triager around i believe i have a bug that can be triaged
[14:13] <trinikrono> its bug 835920 and i just added the bugwatch, that should be sufficient right?
[14:13] <ubot4> Launchpad bug 835920 in checkgmail (Ubuntu) (and 1 other project) "CheckGmail with 2-step verification doen't work (affects: 2) (dups: 1) (heat: 16)" [Undecided,Confirmed] https://launchpad.net/bugs/835920
[14:16] <charlie-tca> trinikrono: you should comment on the bug that you have triaged it and sent it upstream
[14:16] <trinikrono> charlie-tca: i just put one :D
[14:17] <trinikrono> do you think that it has enough info to be considered triaged?
[14:17] <charlie-tca> Okay, I will mark it, then. Importance desired?
[14:17] <charlie-tca> sure, it is upstream already, right? also it has a duplicate, which confirms it.
[14:18] <charlie-tca> done
[14:18] <charlie-tca> Thanks for working on bugs. It does help!
[14:19] <trinikrono> charlie-tca: i would say low because it does not seem to be affecting a lot of users, only people wanting to use two step auth
[14:20] <charlie-tca> I can agree with that.
[14:22] <trinikrono> thanks charlie-tca
[14:23] <charlie-tca> You are welcome.
[14:42] <trinikrono> charlie-tca: if you are not busy can you look at bug 762392
[14:42] <ubot4> Launchpad bug 762392 in nautilus (Ubuntu) "Nautilus Crashes On Opening Directory With Large Number Of Files (affects: 1) (heat: 3)" [Undecided,New] https://launchpad.net/bugs/762392
[14:42] <trinikrono> i am thinking to tell the reporter to run nautilus from the command prompt and see what it says when it crashes
[14:44] <trinikrono> i saw this page also http://live.gnome.org/Nautilus/Development/Bugs
[14:45] <trinikrono> where it says if nautilus crashes it makes a debug file
[14:46] <charlie-tca> I would have the reporter do that. Then they can attach nautilus-debug-log
[14:46] <charlie-tca> but, make sure to tell them to remove that .conf after or it will keep building the logs
[14:58] <trinikrono> where does the log end up charlie-tca in the ~/ folder?
[14:59] <charlie-tca> That is where I think it will be, yes
[14:59] <charlie-tca> It should be in the same directory as the .conf file
[15:04] <trinikrono> charlie-tca: i put it too incomplete and asked for them to check out the wikipage and attach the file
[15:04] <trinikrono> so hopefully that would cover it for now
[15:04] <trinikrono> since apport did not collect anything useful
[15:05] <charlie-tca> yeah, that should be good
[15:05] <charlie-tca> Without something showing what is happening, it is not going to be possible to fix it
[15:06] <trinikrono> :D thanks i am off now charlie-tca
[15:06] <charlie-tca> Thank you for helping
=== paul__ is now known as Elbrus
[19:20] <denva-ingram> Hiya everyone, I have reported a bug but it seems that no one has a answer for, could anyone help me sort it out?
[19:21] <denva-ingram> bug is https://bugs.launchpad.net/linux/+bug/816145
[19:21] <ubot4> Launchpad bug 816145 in linux (Ubuntu) (and 1 other project) "Atheros AR5001 wireless card "wireless is disabled by hardware switch" (affects: 4) (dups: 1) (heat: 16)" [Medium,Incomplete]
=== SWAT___ is now known as SWAT
[19:27] <xteejx> Evening all!
[20:36] <penguin42> can someone set importance on bug 551432 - I won't do it myself because I'm one of the people suffering from it and I'm about out of ideas to debug it
[20:36] <ubot4> Launchpad bug 551432 in virt-manager (Ubuntu) "virt-manager create disk image with LVM hangs for ever (affects: 2) (heat: 12)" [Undecided,Confirmed] https://launchpad.net/bugs/551432
[20:38] <charlie-tca> Okay, what importance you want?
[20:40] <penguin42> well I guess it's either medium or low depending if virt-manager is a 'core application'
[20:40] <penguin42> (although for me it's a pit....)
[20:40] <penguin42> it's in main, so I guess it's core - Medium
[20:41] <charlie-tca> done
[20:42] <penguin42> Thanks - it's time I learn't some more python :-(
[20:46] <charlie-tca> python? No one said I have to learn python to do this now... ;)
[20:54] <penguin42> oh it's just virt-manager is written in python - and a window is falling down a crack somewhere and I don't understand why
[21:15] <mdeslaur> penguin42: what virt-manager version are you getting that issue on?
[22:10] <penguin42> mdeslaur: 0.9.0-1ubuntu3
[22:10] <mdeslaur> penguin42: ah! thanks
[22:11] <penguin42> let me just gather that stuff you asked for
[22:16] <penguin42> ok, done - back in 10min
[22:23]  * penguin42 returns
[22:25] <penguin42> mdeslaur: Would you expect virsh vol-list main    to give me something useful - it doesn't
[22:25] <mdeslaur> penguin42: did you create the "main" pool? do you have any idea what /dev/main is?
[22:26] <penguin42> mdeslaur: It's an lvm2 volume group
[22:26] <mdeslaur> oh, I see...are you storing stuff directly on lvm volumes?
[22:26] <penguin42> mdeslaur: In there are  'archhurd  crypt  debianvm  fedora13  fiddle2disk  more  server1a  server1a-lucid  testing' many of which are the disks used for VMs - yes
[22:27] <mdeslaur> hmm...I'm going to need to install a machine with some lvm volumes to try and reproduce this...a few people have mentioned problems with lvms before
[22:28] <mdeslaur> penguin42: has it ever worked?
[22:28] <penguin42> mdeslaur: Yes, it worked great on Natty
[22:28] <penguin42> mdeslaur: I've been running with this setup for about 18months - since I got this machine
[22:30] <mdeslaur> penguin42: I'll try and reproduce this as soon as I get back from vacation...sorry about that...
[22:30] <penguin42> mdeslaur: although I can't remember when I last created a VM was - probably a few months
[22:30] <penguin42> mdeslaur: That's fine - can you give me some suggestions as to where to look for more debug; what I don't get is virt-manager is creating the window but it's not getting mapped, so what should be causing it to get mapped?
[22:33] <mdeslaur> let me look at the code, one sec
[22:35] <mdeslaur> something is createvol.py is going wrong I guess
[22:37] <penguin42> yeh that's what I guessed - I've scattered debug prints everywhere and nothing seems to be exiting any of the functions early, the cleanup/finish functions aren't getting called
[22:39] <mdeslaur> penguin42: what if you add "logging.debug("DAG: vol_class is %s" % self.vol_class)" to createvol.py line 44
[22:40] <penguin42> is line 44 the one after self.vol_class =   ?
[22:40] <mdeslaur> yep
[22:40] <mdeslaur> just to see if it manages to get something sane there
[22:41] <mdeslaur> penguin42: oh, can you also start virt-manager with "virt-manager --debug --no-fork" to see if that works any better?
[22:41] <penguin42> 2011-08-28 23:41:48,453 (createvol:46): DAG: vol_class is <class 'virtinst.Storage.LogicalVolume'>
[22:42] <mdeslaur> ok, that's fine I guess
[22:42] <penguin42> mdeslaur: It happily gets all the way to the end of that function,
[22:44] <penguin42> oooh!
[22:45] <penguin42> mdeslaur: I think I might see what's going on
[22:45] <mdeslaur> do tell :)
[22:45] <penguin42> ok, I partially take that back - but I've got a change in behaviour
[22:46] <mdeslaur> by doing what?
[22:46] <penguin42> mdeslaur: I've got virsh vol-list to work, by changing the debug levels of lvm
[22:47] <penguin42> 'New Volume' still isn't working - but at least it's now listing the volumes I had
[22:47] <penguin42> mdeslaur: It seems to be sensitive to the 'command_names' option in /etc/lvm/lvm.conf
[22:47] <mdeslaur> ah, yeah...it's probably parsing the output of lvm tools, and is sensitive to configuration and/or redhat differences
[22:48] <mdeslaur> I'll need to reproduce this when I get back and go through it all
[22:48] <penguin42> mdeslaur: Yeuch parsing the output of the lvm commands is grim!
[22:48] <mdeslaur> so that would actually be in libvirt
[22:48] <penguin42> ok, but 'New Volume' still doesn't work any better
[22:50] <penguin42> but, that's work-aroundable since I can do it with LVM commands
[22:50] <penguin42> (which then makes me wonder if New Volume has ever worked there and I've always done it on lvm commands?)
[22:51] <mdeslaur> so...maybe you should get libvirt logging running and look in the libvirt logs...that would explain why virt-manager isn't printing anything useful
[22:51] <penguin42> mdeslaur: I did - the libvirt logs are HUGE
[22:51] <mdeslaur> virt-manager is probably incorrectly handling data that libvirt is returning
[22:52]  * penguin42 decides to start by filing a bug about the sensitivey to the 'command_names' lvm debug option
[22:53] <penguin42> it's an option in the lvm config file, so is a perfectly valid thing to use - although to be honest I'd expected that to change only the output of logging
[22:56] <mdeslaur> yeah...storage_backend_logical.c in libvirt parses the output of various lvm commands
[22:56]  * penguin42 grabs a bucket - surely there is an API for that
[22:57] <penguin42> or use udisks
[22:57] <mdeslaur> are you running en_US?
[22:57] <penguin42> en_GB
[22:58] <penguin42> oh dear that would get very messy
[23:00] <mdeslaur> yeah, I think storage_backend_logical.c needs to be looked at to make sure all the regexes in there actually work with the tools we have in oneiric and will different locales
[23:00] <mdeslaur> *sigh*
[23:00] <penguin42> if it's parsing the output of lvm commands it'll probably break just by thinking about it
[23:01] <mdeslaur> it probably doesn't handle spaces in filenames, that's for sure
[23:02] <mdeslaur> anyway, I have to stop looking at this now...
[23:02] <penguin42> I think one of the bugs here is that the command_names option in lvm actually changes the output of the command, not (just?) the stuff that's logged - so I'd happily take that as an LVM bug
[23:02] <penguin42> mdeslaur: Thank you!
[23:04] <mdeslaur> np, I'll take a look when I get back. thanks!
[23:04] <penguin42> mdeslaur: For reference bug 836329 is the sensitivty to command_names, I'm also going to mark it as affecting lvm and let the lvm and libvirt side fight out which one is wrong :-)
[23:04] <ubot4> Launchpad bug 836329 in libvirt (Ubuntu) "lvm volumes not listed if lvm has command_names option = 1 (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/836329
[23:04] <mdeslaur> thanks!