[01:01] <hggdh> Ampelbein, you are doing a good work, old bugs are as worthy as new ones. And yes, many reporters will complain it took us quite a long time to get there
[01:01] <hggdh> such is life
[01:01] <hggdh> mrooney, makes sense, I think. Go ahead and change it
[01:02] <mrooney> I think we need a wiki page for complainers :)
[01:04] <mrooney> explaining paradigms for non-free OSes simply don't apply to a free OS like Ubuntu, where it is very rare someone is getting paid to work on a piece of software. and since it is open source, the best thing they can do for an issue they care about is learn how to fix it and do so
[01:04] <hggdh> one single wiki page will not be enough ;-)
[01:05] <mrooney> haha, I know
[01:06] <mrooney> something like WhyIsntMyBugFixed could be useful
[01:07] <mrooney> Ampelbein: just read your stuff, yes I think what you are doing is great, as long as you can "take the heat" of some users, it will improve everything in the end. it is better IMO to get a reply asking why it has taken so long, than leave someone waiting indefinitely
[01:07] <james_w> just subscribe them to the ubuntu-bugs mailing list for a day
[01:07] <mrooney> james_w: brilliant :)
[01:36] <mrooney> okay I have thinking about this stock response change a little more
[01:37] <mrooney> "Thank you for taking the time to report this bug and helping to make Ubuntu better. Unfortunately we can't fix it in its current state..." doesn't make grammatical sense, as the `it` is sort of ambiguous and assuming it refers to the bug, that doesn't make semantic sense, the state of the bug isn't what needs to be changed
[01:38] <mrooney> what about just changing "Unfortunately we can't fix it, because your description didn't include enough information." to "Unfortunately we can't fix it without more information."?
[01:43] <hggdh> mrooney, this is indeed better
[01:44] <mrooney> okay, that is used in 8 of the responses, I will just adjust all of them? obviously it is easy to change later :)
[06:09] <tuxmaniac> good morrning folks
[06:44] <dholbach> good morning
[06:58] <techno_freak> dholbach, morning
[06:58] <dholbach> hi techno_freak
[07:02] <mattik> Hello, how is it possible, that I have reported many bugs what is marked duplicated newer one? Is there some people who try to collect more karma and ubuntuteros who help they?
[07:02] <dholbach> mattik: the age of a bug is not relevant when deciding which bug is a duplicate of which other bug
[07:02] <mattik> why
[07:02] <dholbach> mattik: which contains more information is much more important
[07:03] <mattik> ok
[07:03] <dholbach> so if bug A is forward upstream already, has clear instructions how to reproduce, etc, bug B is likely to be made a duplicate of A
[07:04] <mattik> but who decide it
[07:05] <dholbach> whoever triages the bug and finds out about a duplicate
[07:08] <mattik> ok, I agree
[07:10] <elmargol> the guys from the linux action show are flaming about the ubuntu bugtracker :(
[07:12] <dholbach> elmargol: do you have a link to that?
[08:03] <mouz> dholbach: it might be (i could not find the flaming itself) somewhere here: http://www.jupiterbroadcasting.com/?cat=4
[08:04] <dholbach> mh
[10:10] <mcas> good morning
[10:21] <nullack> Hi everyone :) I just joined the team, Ive been testing professionally for 12 years and have related experience in release management, problem management, ITIL, etcetc
[10:22] <nullack> Anyway where is the bug management policies? The wiki is pretty brief on reporting bugs and Im getting inconsistencies from some devs on bugs Im involved on
[10:34] <dholbach> hi nullack - did you check out  https://help.ubuntu.com/community/ReportingBugs ?
[10:34] <nullack> Yes I did, I need deeper info :) Anyway Im now looking at the IRC chat logs from the KB it has some info
[10:34] <seb128> hey nullack, thanks for the good bug work ;-)
[10:35] <seb128> nullack: about upstream bugs, things like "software is using too much ressources" are not usually distro changes, especially for gedit which has no distro change
[10:35] <nullack> I dont have credentials to move the importance for bug 257818 - according to the bug policy as stated in the IRC chat log "High importance: This is a bug that has a severe impact on a small portion of Ubuntu users. It makes a default Ubuntu installation generally unusable." and it should be this priority. Can someone please change it, the dev is wrong
[10:36] <seb128> nullack: looks like that's something which never worked right?
[10:36] <seb128> nullack: you are the first one to complain about that, it might be annoying for some usecase but that's not something most users run into
[10:36] <nullack> Sebastien how can we gaurentee that it isnt due to customisation in debian or Ubuntu? And it only recently came into existence when no gedit chages were made very recently
[10:36] <seb128> nullack: and that's not something the ubuntu team has ressources to work on, so fighting over bug settings will not make a difference
[10:37] <nullack> Sebastien, please Im not fighting :) Im simply looking to apply the Ubuntu policy
[10:37] <seb128> nullack: a new gedit has been uploaded some days ago which uses gio
[10:37] <nullack> I understand your reasons but thats not the policy
[10:37] <seb128> you are using intrepid?
[10:37] <nullack> Yes I am mate
[10:37] <seb128> no gedit changed a lot
[10:37] <seb128> they ported the code to gio
[10:38] <seb128> and I uploaded that new version some days ago
[10:38] <seb128> s/no/so
[10:38] <nullack> Yeah I know, but I didnt have the issue until very recently
[10:38] <seb128> maybe a gio thing
[10:38] <nullack> I was synched to your change no problems then
[10:38] <seb128> like you mounted a share which is low latency
[10:38] <seb128> and it doesn't handle that correctly
[10:39] <seb128> that would require somebody having the issue to use sysprof or similar to know what is going on
[10:39] <nullack> I will look into that, can we please quickly discuss the deinterlace issue?
[10:40] <seb128> nullack: gedit didn't change after the new version update (and a svn change backport), and there is no distro patch there, so I doubt the issue is specific to ubuntu, but right not easy to determine for users
[10:40] <seb128> nullack: right, first what you call policy are guidelines
[10:40] <nullack> Yeah Ive reported it upstream anyway :)
[10:40] <seb128> the maintainers decide on what are the appropriate settings
[10:40] <seb128> is that something which ever working using totem-gstreamer?
[10:40] <nullack> No its not
[10:41] <seb128> ok, so it's something which is not a regression
[10:41] <nullack> Yes my friend, no regression
[10:41] <seb128> and you are the first one to complain in several years of ubuntu
[10:41] <seb128> now I can understand it's frustrating in your usecase
[10:41] <nullack> Most people just install mplayer or VLC
[10:41] <seb128> but that's not a high priority for our userbase
[10:41] <nullack> Hmm, I understand, but I think I need to make a point
[10:42] <nullack> It does effect the userbase, quite a bit, but people go and work around it by installing vlc or mplayer
[10:42] <nullack> People rubbish gstreamer / vlc for the deinterlacing reason, and also other stuff like the stream bug I reported
[10:43] <nullack> I want to support the default Ubuntu build with my tests and this is why Im one of the few who have reported these bugs instead of installing vlc or mplayer
[10:44] <nullack> The user impact of not being able to deinterlace wrecks use cases like watching digital TV thats interlaced and using footage shot on interlaced cameras
[10:44] <seb128> nullack: I don't agree about that, we get lot of people reporting totem bugs
[10:45] <seb128> I just think 98% of users play avi, wmv, or mpeg files
[10:45] <nullack> Ok, well I will defer to your judgement since youve seen my point of view :) If your really, really sure
[10:45] <seb128> ok, let's be clear
[10:45] <seb128> - it sucks
[10:45] <seb128> - it's not trivial to fix
[10:45] <seb128> - the ubuntu team doesn't write the software and doesn't have the ressources to work on this right now
[10:46] <seb128> so the settings are not making any difference
[10:46] <seb128> I think it's doesn't make the installation un-usable
[10:47] <seb128> "# A cosmetic/usability issue that does not limit the functionality of an application "
[10:47] <seb128> that would be low
[10:47] <seb128> "# A bug that has a moderate impact on a core application. "
[10:47] <seb128> that would be medium
[10:47] <seb128> it's somewhere between those
[10:47] <seb128> but as said picking on or the other is not going to make a difference
[10:48] <nullack> Higher priorities might make a difference to an ethusiast whos looking at what the key issue are, but as you say its not trivial to fix
[10:49] <nullack> I think not being able to watch interlaced DVB is serious, same with camera footage, but your view is that those use cases are not common
[10:49] <elmargol> dholbach, on the latest podcast... reporting bugs is a waste of time for you and for the developers
[10:50] <seb128> nullack: I don't know what DVB is and I think 95% of users just want youtube videos or divx movies yes
[10:50] <nullack> Its Digital Video Broadcasts :) mostly Free to air TV thats sometimes broadcast in interlaced format
[10:51] <dholbach> elmargol: maybe mail the link of the podcast to ubuntu-buqsquad@ along with the minute when that occurs - maybe somebody better than me can approach the producers of the podcast and have a chat with them about it
[10:51] <seb128> nullack: and I don't think anybody looking at fixing hard issues will look at the ubuntu bug trackers, people working on gstreamer will do that upstream
[10:51] <nullack> Ive added test files and info upstream
[10:51] <seb128> cool
[10:51] <seb128> anyway the importance is suggestive there
[10:52] <nullack> I now understand your reasons and accept the policy are guidelines, thanks for your time Sebastien
[10:52] <seb128> and if users want to get their issues considered they should let us know about it those rather than switching softwares
[10:52] <nullack> I agree, thats what I was trying to do
[10:52] <nullack> And besides, MOTU dont keep ffmpeg and mplayer up to date
[10:52] <seb128> right, and I consider your bug, but you are the only one who raised that as a real issue so far
[10:53] <seb128> another topic ;-)
[10:53] <seb128> part of that is due to debian, ffmpeg is the debian version
[10:53] <seb128> and there is also a manpower issue there, MOTU is way understaffed for the work to do
[10:53] <nullack> Yeah their swamped
[10:54] <seb128> btw about the file-roller chmod issue, I agree low was maybe not appropriate, though basic users don't know how to use sudo and user who do should know better than running graphical tools using it
[10:54] <elmargol> dholbach, I'll that
[10:54] <seb128> but thanks for sending it upstream and getting it fixed
[10:55] <seb128> new GNOME tarballs are due today so it'll be fixed in intrepid
[10:55] <nullack> No worries Sebastien, Im pleased you agree with my reasons why that particular bug was pretty nasty :)
[10:55] <nullack> Great, were looking forward to testing it Ive got a few peeps on the forums lined up ready for it
[10:59] <elmargol> dholbach, sadly I have to agree an some parts :( I have some verry old bugreports and since they are not easy to fix they get ignored
[11:04] <elmargol> #55496 2006-08-07
[11:04] <elmargol> Bug #103210 2007-04-05
[11:07] <mcas> can someone please look at bug 258588
[11:07] <mcas> i think this should be medium or high importance but i cannot change it
[11:08] <gnomefreak> mcas: i see a few issues with -5
[11:08] <mcas> ok
[11:08] <gnomefreak> file system is read only so cant get X working due to that
[11:09] <mcas> i forgot to search for duplicate bugs. sorry
[11:09] <gnomefreak> but it upgrades fine. browser is slow
[11:09] <gnomefreak> mcas: i havent filed a bug yet
[11:09] <mcas> ah ok
[11:10] <mcas> and my suggestions about the importance... do you think its ok?
[11:10] <gnomefreak> im assuming its stopping you from upgrading the kernel is due to its issues but i havent looked at logs yet
[11:11] <mcas> ok
[11:28] <nullack> Anyone: When I have a bug that I already linked upstream, and upstream decide that its a duplicate of an existing other bug, LP says bugwatch for the upstream bug is invalid. How do I point the LP bug to the new upstream path? Trying it the usual way doesnt work, thanks
[11:38] <nullack> Ah! Ive got it. Its the little yellow icon that allows to change the bug watch details next to the bug watch panel in LP in case anyone else has run into this :)
[11:40] <anakron> Hi all
[12:57] <mrooney> can anyone recommend a course of action for bug 250497?
[12:57] <nullack> WinTesting1
[12:58] <mrooney> the reporter says it hasn't happened recently and guessed it was fixed in a recent update, however the package hasn't been updated since months before his report
[12:58] <mrooney> do I just mark as Invalid and ask him to re-open if he experiences the issue again?
[12:58] <Hobbsee> i would - it could well be pebkac
[12:59] <Hew> mrooney: I'd mark it invalid and use the standard response from https://wiki.ubuntu.com/Bugs/Responses
[13:03] <mrooney> Hobbsee: pebkac?
[13:04] <Hobbsee> !google pebkac
[13:04] <Hobbsee> aww
[13:04] <Hobbsee> problem exists between keyboard and chair
[13:04] <mrooney> Hobbsee: :)
[13:05] <nullack> lol
[13:06] <seb128> mrooney: right, close the bug and ask him to reopen if he gets the issue again
[13:12] <mrooney> Hew, seb128: thanks!
[13:45] <nullack> Ping Sebastien : Gnome dont want to use ffdeinterlace for a work around to the current deinterlacing and it appears I wont be able to convince them. Get the feeling they are not keen on ffmpeg. Perhaps by October the newer gstreamer bad plugins and playbin2 will be happening
[13:53] <seb128> nullack: let's see, not really something ubuntu can change in a distribution specific way
[13:55] <nullack> No, next cycle should be much better though with playbin2, resindvd, deinterlace support - gstreamer coming of age :)
[13:55] <seb128> right
[14:51] <bddebian> Boo
[14:53] <pedro_> buuu
[14:55] <bddebian> :)
[15:37] <nullack> Anyone: Ive found a bunch of bugs in Intrepid with gnome not recognising certain file extensions as multimedia files by default and the second related issue being that although I have all the necessary demuxers and decoders installed, I dont get thumbnails generated as gnome doesnt know they are video. Im not sure, is this an upstream bug or one I should report in LP?
[15:38] <qense> This could indeed be an upstream bug. However, I would report it at LP. The Bugsquad nows Ubuntu better than upstream and can ask for the right files. If it turns out to be caused by something else, the report won't go lost.
[15:39] <qense> It's also good for us to have an overview of bugs in Ubuntu. ;)
[15:39] <nullack> Ok Ill kick it off in LP and consider bugwatching it to a new one in gnomes bugzilla
[15:40] <qense> I'd add first the files requested in https://wiki.ubuntu.com/DebuggingProcedures and wait for the Bugsqua to respond.
[15:41] <nullack> Not too much there thats relevant https://wiki.ubuntu.com/DebuggingGNOME :) Its ok, I know the gnome revision Im on and can provide details
[15:41] <qense> OK
[15:44] <nullack> What package in gnome controls the desktop file extension stuff?
[15:44] <qense> I'm not even sure if it's gnome at all, I just realized that some things are handled by shared-mime-info.
[15:45] <nullack> Even on KDE?
[15:47] <qense> At the moment it's just being used my ROX and GNOME, but they expect KDE to change soon too. I'm not sure about KDE 4.1 though, I'm running hardy.
[15:47] <nullack> ok well I will put the package as shared-mime-info because I honestly dont know what packages this is for
[15:48] <qense> It could be a bug in the GNOME handling.
[15:48] <qense> It's a database.
[15:49] <nullack> Sebastien might be busy, maybe I should leave it blank till a gnome guru is available
[15:49] <seb128> nullack: could you describe the bug?
[15:49] <nullack> lol
[15:49] <nullack> Hi mate
[15:49] <nullack> There is two issues
[15:50] <nullack> One, some common multimedia file types are not associated with their extensions as video by default
[15:50] <seb128> which ones?
[15:50] <nullack> Heres my list one sec
[15:50] <seb128> do you have an example?
[15:51] <nullack> So far I have ps. ts and mqv being missing
[15:51] <nullack> Minor as user can open with, but as you know I have reported a bug on that as well
[15:51] <seb128> I still didn't understand this open with bug but let's talk about that later
[15:52] <nullack> TS and PS especially are very common types
[15:52] <seb128> .ts like the video dvd thing?
[15:52] <seb128> .ps for a video? namespace conflict ...
[15:52] <nullack> Its a transport stream so it is many things, but one of them is video dvd
[15:53] <nullack> Well see alot more ts and people get into DVB more
[15:53] <seb128> .ts is a defined type
[15:53] <seb128>   <mime-type type="application/x-linguist">
[15:53] <seb128>     <comment>message catalog</comment>
[15:53] <nullack> Gnome errors with an error dialogue saying there is no application of this type
[15:54] <seb128> nothing claims this mimetype
[15:54] <seb128> ok, so way it works
[15:54] <nullack> Error test is Could not display (filepath and name)
[15:54] <seb128> shared-mime-info define known mimetype
[15:54] <seb128> see /usr/share/mime/packages/freedesktop.org.xml
[15:54] <seb128> it can using filenames and content for that
[15:55] <nullack> Do you agree its a bug?
[15:55] <seb128> then .desktop in /usr/share/applications list the mimetype they can open
[15:55] <seb128> well
[15:55] <nullack> So root cause .desktop is missing ts app?
[15:55] <seb128> it requires somebody who has a clue about the format to open a freedesktop bug on shared-mime-info
[15:55] <seb128> including an example of possible
[15:55] <seb128> no
[15:55] <seb128> first we should know what you call .ts
[15:56] <nullack> A transport steam file
[15:56] <seb128> shared-mime-info knows "application/x-linguist" which are .ts
[15:56] <nullack> is x-linguist common?
[15:57] <seb128> no clue
[15:57] <seb128> I've never used any I think
[15:57] <nullack> Ive never heard of it and IMHO most people would think video when someone said .ts
[15:57] <seb128> anyway
[15:57] <seb128> that's purely upstream request
[15:58] <seb128> so
[15:58] <seb128> https://bugs.freedesktop.org/enter_bug.cgi?product=shared-mime-info
[15:58] <seb128> open a bug there
[15:58] <nullack> Righto, upstream
[15:58] <seb128> describing the mimetype you want to be added
[15:58] <seb128> and attach an example if possible
[15:58] <nullack> Ready for the second issue?
[15:58] <seb128> they will want to know how the format is called
[15:58] <seb128> where it's used
[15:58] <seb128> and if the content is specific
[15:58] <seb128>  
[15:58] <seb128> yes
[15:58] <nullack> Ok
[15:58] <seb128> what is the next one?
[15:59] <nullack> 2nd one is I have the right demuxers and decoders installed but gnome fails to thumbnail them, even though totem plays them through gstreamer no problems
[15:59] <nullack> These are TS's, MKV's, SWF's and MQV's
[16:00] <seb128> gconf-editor, desktop, gnome, thumbnailers
[16:00] <seb128> you have a list of formats to thumbnail there
[16:00] <nullack> Right I can look that up :)
[16:01] <seb128> those need a mimetype again, so .ts will not work until defined in shared-mime-info
[16:01] <seb128> there is a /desktop/gnome/thumbnailers/video@x-matroska/command so those should work though
[16:01] <seb128> verify if they have the correct mimetype in the nautilus dialog
[16:02] <seb128> otherwise for those which are not listed that's a totem upstream bug
[16:02] <nullack> Nautilus opens MKVs into Totem and plays them fine
[16:02] <nullack> No tumbnails though
[16:02] <seb128> look to /desktop/gnome/thumbnailers/video@x-matroska/command in gconf-editor
[16:02] <seb128> and try running the command on a command line
[16:02] <nullack> Ok one moment
[16:03] <seb128> verify also that they have the correct mimetype in nautilus too
[16:04] <nullack> Sebastien do you know the syntax for the path, the command in gconfeditor has input variables
[16:05] <nullack> e.g. /desktop/gnome/thumbnailers/video@x-matroska/command
[16:05] <nullack> No man pages for it either
[16:06] <nullack> Ah got it, executing is spat out the parameters
[16:09] <seb128> nullack: command source destination
[16:10] <seb128> nullack: there is a timeout so if the thumbnailing is too slow for this format that might be the issue
[16:11] <nullack> nullack@PPP:/mnt/vault/Film/Tests$ gnome-video-thumbnailer -j Mushishi24-head.mkv 1.jpg
[16:11] <nullack> gnome-video-thumbnailer couldn't process file: 'Mushishi24-head.mkv'
[16:11] <nullack> Reason: Took too much time to process.
[16:11] <nullack> Your spot on :)
[16:12] <seb128> I think we already got some bug about that issue
[16:12] <nullack> Ok so 1st is an upstream bug and second is a feature not a bug
[16:12] <seb128> not sure what we can do though
[16:12] <nullack> Buy me a faster machine? what ya reckon? hehe
[16:12] <seb128> bumping the timeout would mean increase ressource usage for that
[16:12] <nullack> Exactly
[16:12] <seb128> and optimizing the thumbnail might not be trivial
[16:13] <nullack> Yes it is H.264 and until we have AVC GPU acceleration my sys struggles
[16:13] <seb128> but that sounds quite some work for a low importance issue so not likely a priority
[16:13] <nullack> Agreed, Im dropping the second item
[16:14] <nullack> Would you like to discuss the open with later, I know your busy
[16:14] <seb128> that's fine, I can discuss while updates are building
[16:14] <nullack> Its a usability thing, low priority
[16:15] <nullack> My thinking is...
[16:15] <nullack> Gstreamer is installed by default
[16:15] <nullack> So choosing between Movie Player and Movie Player (gstreamer) is no choice
[16:15] <nullack> It confuses a user
[16:15] <seb128> I've no such options
[16:16] <seb128> I've only "movie player" listed
[16:16] <seb128> and then xine and mplayer because I installed those
[16:16] <nullack> They are there by default, I did a special clean install of Alpha 4
[16:16] <seb128> that's weird
[16:16] <nullack> As well, that link I sent you to the forum many others have it
[16:16] <nullack> Yeah it is
[16:16] <nullack> Would installing gstreamer plugins do it?
[16:16] <seb128> where do you get those? in the context menu?
[16:17] <nullack> Right mouse click video file, choose open with, and observe those two options in the list of apps to open the video with
[16:18] <nullack> Specifically it is Open With Other Application
[16:18] <seb128> do you have any mimetype in /usr/share/applications/totem-gstreamer.desktop?
[16:19] <nullack> lemme grep it one sec
[16:20] <nullack> Are you sure your going into the seperate dialog box with the heading Open With and not just the right mouse click window?
[16:20] <seb128> those should be equivalent
[16:21] <seb128> and yes, I tried on a .avi
[16:21] <nullack> Ive got lots of entries in different languages in that desktop file
[16:21] <nullack> I will post a screenshot right now to show you, one moment please
[16:21] <seb128> look into /usr/share/applications/mimeinfo.cache the avi line for example
[16:21] <seb128> video/x-avi=totem.desktop;mplayer.desktop;
[16:21] <seb128> is what I get here
[16:23] <nullack> nullack@PPP:/mnt/vault/Film/Tests$ cat /usr/share/applications/mimeinfo.cache | grep avi
[16:23] <nullack> video/x-avi=totem.desktop
[16:23] <nullack> nullack@PPP:/mnt/vault/Film/Tests$
[16:24] <seb128> nullack: and in .local?
[16:24] <seb128> grep avi .local -R?
[16:24] <nullack> No movie apps, other stuff
[16:25] <seb128> did you try on a .avi?
[16:25] <nullack> The thing is, once you right mouse click, go into Open With other Application ...  noting the three dots means its going into a new window
[16:25] <seb128> and you have a gstreamer entry listed?
[16:25] <nullack> Its not just the right mouse menu
[16:25] <nullack> No gstreamer is listed in the right click menu
[16:25] <seb128> oh
[16:26] <seb128> you are speaking about the dialog to pick an application
[16:26] <nullack> Yes sir
[16:26] <seb128> not the "open with" tab in the properties dialog
[16:26] <nullack> Its the "open with" window
[16:26] <seb128> I was thinking about the tab in the property dialog
[16:26] <seb128> ok, I can confirm the issue now
[16:26] <nullack> Sorry
[16:27] <nullack> Can you see it now?
[16:27] <seb128> not your fault, just a misunderstanding there
[16:27] <seb128> yes
[16:27] <seb128> I just never use this dialog usually
[16:27] <nullack> The thing is because some video mime types arent recognised a user has to go into this menu to fix video playback
[16:28] <nullack> To force it
[16:28] <seb128> I usually open totem and dnd things to it
[16:28] <seb128> but right, this dialog is there and should be fixed
[16:28] <nullack> Yeah, alternative workflows
[16:28] <seb128> this issue is a packaging one
[16:28] <nullack> Can I do anything else to help?
[16:28] <seb128> that's due to the "make possible to install xine and gstreamer variants together"
[16:29] <seb128> you can try to work on a patch if you want ;-)
[16:29] <seb128> hum, the .desktop has a NoDisplay=true, maybe nautilus should respect that
[16:30] <nullack> I have alot to learn about packaging and really my professional skills are in test management / release management / problem management not configuration management
[16:31] <seb128> nullack: I've a fix, those should use Hidden=true rather than NoDisplay=true, will fix in the next upload
[16:31] <nullack> Great thanks my friend, will test when you deliver the goodness in updates
[16:31] <seb128> nullack: ok, keep the good work on bugs then and let other people come with changes, that works too ;-)
[16:31] <seb128> thanks for your interest in this issues
[17:10] <nullack> Ping Pedro : Thankyou for adding your comment to 250021 but I do not think that a new file roller has been committed for build - I have not received any emails about it and I dont see it in the build farm
[17:10] <nullack> #250021
[17:12] <seb128> bug #250021
[17:13] <pedro_> nullack: according to upstream that doesn't affect trunk
[17:13] <pedro_> that's why i marked as fix committed
[17:13] <seb128> nullack: we use "fix commited" when the bug is fixed upstream so we know what to close in the next version update
[17:13] <pedro_> at the desktop (gnome) fix committed  = fixed upstream also
[17:14] <pedro_> indeed
[17:14] <nullack> Ok, I understand, not intuitive but Ill follow the standards :0 Since our tree isnt their tree
[17:14] <nullack> Sorry Pedro, thanks for your help on this bug :)
[17:14] <pedro_> nullack: you're welcome, thanks for following up ;-)
[17:16] <awalton_laptop> is anyone from the bug squad around that could renew my membership?
[17:17] <Igorot> awalton_laptop: ask bdmurray
[17:17] <awalton_laptop> Igorot, thanks
[17:21] <pedro_> awalton_laptop: renewed
[17:21] <awalton_laptop> pedro_, thanks
[17:22] <pedro_> you're welcome
[17:51] <nullack> Ping someone at Canonical : I think packages,ubuntu.org has lost the plot it tells me that my search for ffmpeg packages in intrepid and hardy are not found
[17:51] <nullack> You have searched for packages that names contain ffmpeg in suite(s) intrepid, all sections, and all architectures.
[17:51] <nullack> Sorry, your search gave no results
[17:52] <nullack> Edit: No Ive lost the plot - time for coffee - I forgot to put search by package name
[17:54] <nullack> lol edit2: it has :)
[17:54] <nullack> Internal Server Error
[17:54] <nullack> The server encountered an internal error or misconfiguration and was unable to complete your request.
[17:54] <nullack> Please contact the server administrator, frank@lichtenheld.de and inform them of the time the error occurred, and anything you might have done that may have caused the error.
[17:54] <nullack> More information about this error may be available in the server error log.
[18:33] <chrisccoulson> just having a look through some of the expirable bugs. i've just come across bug 217760
[18:34] <chrisccoulson> personally, i think thats a bad idea, but what does everyone else think?
[18:34] <pheeror> as isv (read adobe) sux hard, it's not so bad idea
[18:35] <hggdh> argh, LP is slow...
[18:35] <chrisccoulson> it is a bad idea. we shouldn't give users an easy way of installing packages that have been specifically built for 32-bit architecture on a 64-bit machine
[18:36] <hggdh> well, there are builds for this
[18:36] <chrisccoulson> the packages should be re-packaged to install on a 64-bit architecture. that is already the case with adobe (which is installable from medibuntu on 64-bit)
[18:36] <pheeror> take in consideration that amd64 is backward compatible with x86
[18:36] <pheeror> yes sure
[18:36] <pheeror> my bad
[18:36] <chrisccoulson> but 32-bit packages will contain files in /usr/lib. installing these on a 64-bit machine is almost guaranteed to cause breakage
[18:37] <chrisccoulson> hggdh, what did you mean about there are builds for this?
[18:37] <pheeror> indeed, i've misunderstood the issue
[18:37] <hggdh> for example, ia32
[18:37] <hggdh> (and I do run both 32 and 64 bits on my laptop)
[18:38] <pheeror> btw is it possible to install ff x86-32 with that evil flash on amd64 hardy?
[18:38] <pheeror> (by one or two commands)
[18:38] <chrisccoulson> i thought so, thanks. do you think that bug 217760 should be set to won't fix?
[18:38] <hggdh> if a specific package/library needs to be built for 32 bits on a 64bits architecture, this has to be requested
[18:39] <hggdh> darn it, my browser refuses to go online right now
[18:39] <chrisccoulson> yeah, i agree with you. i definately don't think we should enable an easy way to pull packages from a repository built for 32-bit architectures on to a 64-bit machine
[18:41] <hggdh> this is usually not a good idea. I have done that before, but by copying the necessary individual libraries over to /usr/lib32, and stitching the resulting mess by hand
[18:42] <chrisccoulson> me too. could you mark the bug report as 'wont fix' please? :) i can't do that unfortunately
[18:44] <james_w> hey chrisccoulson, thanks for working on the gnome-session bug
[18:44] <chrisccoulson> no problem! sorry i havent responded yet.
[18:45] <chrisccoulson> i think yours is probably the better solution, as it is more consistent with the rest of the code
[18:45] <james_w> it does seem to be
[18:45] <james_w> shall I forward it to upstream?
[18:45] <chrisccoulson> you can do. i already attached my patch to the upstream report actually, but nobody has commented yet
[18:46] <james_w> ah, ok, I should have looked
[18:55] <chrisccoulson> james_w, are you familiar with bug 235698?
[18:59] <james_w> chrisccoulson: I don't think so
[18:59] <james_w> why?
[19:00] <chrisccoulson> ah, ok. it's been fixed in intrepid, and i was going to ask if you knew whether it was going to be fixed in hardy as a SRU?
[19:00] <seb128> chrisccoulson: not likely, it's a non issue for hardy, the only reason users notice is apport
[19:01] <chrisccoulson> ah, ok. thanks for that seb128
[19:18] <chrisccoulson> seb128, what do you think about blacklisting gvfs-fuse-daemon in apport? it might stop people who have enabled apport from reporting new bugs...
[19:19] <seb128> chrisccoulson: there is not a lot of recent duplicates and I would prefer to backport the patch for this specific issue rather than workaround it this way
[19:20] <chrisccoulson> the only reason i suggested that was because i got the impression it probably wasn't going to be fixed in hardy
[19:21] <seb128> chrisccoulson: and?
[19:21] <seb128> chrisccoulson: do you think it's important to fix there? it should create no real issue
[19:23] <chrisccoulson> i was just trying to think of a way to reduce the number of people reporting that bug from hardy, but, like you said - there aren't that many recent duplicates anyway, so it's probably a non-issue
[19:28] <seb128> chrisccoulson: apport also has a list of known bugs in bzr, so you can add an entry there and user will be pointed to this bug when trying to open a new duplicate
[19:30] <chrisccoulson> seb128: i didn't know that actually. thanks!
[19:30] <seb128> you're welcome
[20:00] <_stink_> I'm new-ish to bug triage. Bug 154621 is apparently a well known KDE issue, with solutions and other info available in more than one KDE bug (75828 and 70624, e.g.). Other info at http://ur1.ca/30z. I'd like to add these links to the LP bug and close it somehow.  Is invalid the right status?
[20:01] <_stink_> those KDE bug #s are at bugs.kde.org
[20:02] <yuriy> _stink_: there is an "also affects project" link to link the reports together
[20:02] <yuriy> _stink_: if there are other reports about it in launchpad, you can pick a "main" one and mark the others as duplicates
[20:03] <yuriy> _stink_: and add all relevant information to the main report in a comment  if it's not already there
[20:04] <_stink_> yuriy: ok. i don't see other LP bugs on the same issue, just bugs at bugs.kde.org.  so i'll put the info in a comment on this bug.
[20:04] <yuriy> _stink_: if it is an actual bug, and can be confirmed in other reports, invalid is not the right status
[20:04] <yuriy> _stink_: right, that's what "also affects project" is for
[20:04] <_stink_> yuriy: the KDE bug reports about this don't consider it an open bug. they are old reports and amount to telling the user to config correctly
[20:04] <_stink_> ok
[20:05] <_stink_> which is why i thought it should be closed somehow in LP
[20:05] <yuriy> oh
[20:05] <yuriy> well, that may be correct then, but comment carefully
[20:05] <_stink_> ok, thanks
[20:05] <_stink_> i'll be nice :)
[21:53] <dupondje> https://bugs.launchpad.net/ubuntu/+source/audacious/+bug/258797
[21:53] <dupondje> would be cool if it was added, now audacious is useless imo :)
[21:55] <bdrung> dupondje: may be I have a look at it
[21:55] <dupondje> tested and successfully working :)
[22:26] <bdrung> dupondje: can you give me the link to the bugreport from the upstream project?
[22:27] <dupondje> bdrung: http://bugzilla.atheme.org/show_bug.cgi?id=42
[22:28] <bdrung> dupondje: thx
[22:29] <dupondje> without the patch audacious creates logfile with size of 1gb/10mins or something :p
[22:29] <dupondje> quite crap :P
[22:30] <bdrung> dupondje: what do i have to do to reproduce this bug or does this happen right on the start?
[22:31] <dupondje> think u need to load files in the playlist
[22:32] <bdrung> k, i'll try it
[22:32] <dupondje> and I got ARTIST - TITLE as playlist info ...
[22:40] <bdmurray> hggdh_: Do you remember what we said about needs-packaging bugs that are already packaged for debian?  change to sync request?
[22:41] <LaserJock> bdmurray: that's what it was originally, but then we decided to take that out
[22:41] <LaserJock> bdmurray: do you think it should go back in?
[22:42] <bdmurray> LaserJock: maybe, I wrote a script this weekend that found a fair number of n-p bugs that are already packaged for debian
[22:42] <LaserJock> well
[22:42] <LaserJock> to me it depends on the intent of the bug
[22:43] <LaserJock> if they are saying "I want this software in" I'd invalidate it
[22:43] <LaserJock> but if they're saying "I know it's in debian, I just want the latest version" I'd maybe turn it into a "upgrade" bug
[22:44] <LaserJock> but I'd avoid turning them into sync requests because that's a more defined process bug
[22:44] <LaserJock> bdmurray: does that make sense?
[22:45] <bdmurray> not really
[22:45] <LaserJock> heh
[22:45] <LaserJock> what would be the purpose of the bug then, if the software is already in Debian?
[22:46] <LaserJock> unless there's more to the story it's probably useless
[22:47] <LaserJock> and I'd rather have people do investigation first before doing a sync bug
[22:47] <dupondje> its about my bug ? ;)
[22:47] <LaserJock> so I think it's counter-productive to try to turn needs-packaging into sync bugs
[22:48] <bdmurray> right, but I could run requestsync for the the bug, invalidate the n-p bug and point them the at the sync request bug to subscribe to
[22:48] <LaserJock> but I don't want people using requestsync unless they know what they're doing
[22:48] <bdmurray> I said "I could run requestsync"
[22:49] <LaserJock> people should at a minimum test build the debian package in sbuild/pbuilder before submitting requestsync
[22:49] <LaserJock> ah
[22:49] <LaserJock> well, that'd be a lot of work on your part
[22:49] <LaserJock> or wait
[22:50] <bdmurray> https://wiki.ubuntu.com/SyncRequestProcess doesn't say anything about sbuild/pbuilder
[22:50] <LaserJock> if these packages are in Debian but not in Ubuntu then nothing should be done at all really, depending on the stage of release
[22:51] <LaserJock> packages are semi-automatically imported in that case
[22:51] <bdmurray> Right, but we are past Import Freeze now
[22:51] <LaserJock> so we shouldn't be filing sync bugs for those unless there's a good reason
[22:52] <LaserJock> I'm not sure when the archive admins stop importing new sources
[22:52] <bdmurray> I'll check with them then
[22:53] <LaserJock> but SyncRequestProcess should probably have something about test building
[22:53] <LaserJock> currently it's implied
[22:53] <jpds> LaserJock: If the person running requestsync is not a member of the MOTU team, they will first need approval of the u-(m|u)-s team.
[22:53] <LaserJock> jpds: exactly, I don't think we should fill up the queue with low-priority bugs
[22:54] <jpds> Good point.
[22:54] <LaserJock> I'd rather people do some work on it first to make sure it's worth the sponsors time
[22:54] <bdmurray> So I should just forget about those?
[22:55] <LaserJock> honestly I don't think it's worth your time to file sync requests
[22:56] <bdmurray> Okay, so I am at a point we are know something should be done w/ 10 bugs or so but just shouldn't do anything?
[22:57] <LaserJock> in a reply to invalidating you might point people to SyncRequestprocess and say something like "This software has already been packaged in Debian. If it is not available in the current Ubuntu development version feel free to follow [sync wikii page]"
[22:58] <LaserJock> bdmurray: which bugs are you talking about?
[23:01] <bdmurray> bug 255110, bug 151564, bug 198048, bug 181084, bug 230453, bug 255106, bug 255402, bug 141171, bug 204711
[23:03] <bdrung> dupondje: i cannot repproduce it.
[23:05] <dupondje> strange
[23:05] <bdrung> dupondje: with wich filetype does this bug appears?
[23:05] <dupondje> if u google the error, tons of people have it
[23:05] <dupondje> .MP3
[23:05] <bdrung> i will test with mp3
[23:06] <LaserJock> bdmurray: you're saying you have ~ 10 needs-packaging bugs now in your list of New/Undecided ?
[23:06] <LaserJock> s/Undecided/Unkown/
[23:10] <vadi2> A pair of people after an update of ubuntu got their themes broken, and I'm not sure how to fix it. The question has been open for quite a while: https://answers.launchpad.net/ubuntu/+question/38900
[23:10] <bdmurray> LaserJock: no, I'm saying I've discovered that those needs-packaging bugs are already packaged in Debian
[23:11] <bdrung> dupondje: still not
[23:11] <LaserJock> bdmurray: oh, right
[23:11] <dupondje> what version using ? :)
[23:11] <LaserJock> bdmurray: I'm guessing a few of them are people who've filed a bug in both Ubuntu and Debian
[23:12] <bdrung> dupondje: 1.5.1-2ubuntu2
[23:12] <dupondje> same :x
[23:12] <bdrung> does it also happen on other file types?
[23:13] <LaserJock> bdmurray: so are you wanting to mark them Invalid or no?
[23:13] <dupondje> http://pastebin.ubuntu.com/38616/
[23:13] <dupondje> this is my conf
[23:16] <bdrung> dupondje: where do i have to put it?
[23:16] <LaserJock> Invalidating a needs-packaging bug that's In Progress is a bit troublesome, but people can reopen them if they've got a reason to
[23:16] <dupondje> /home/<user>/.config/audacious/config
[23:18] <dupondje> also see: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=491655
[23:24] <bdrung> dupondje: with your config audacious does not start. there is no alsa device, because i run intrepid in a virtual machine. therefore i use null output instead of alsa
[23:28] <dupondje> oh :s well dunno, try loading ALOT of MP3 files
[23:29] <dupondje> +1000
[23:29] <dupondje> but I gtg now
[23:29] <dupondje> pm me if u have questions