[00:53]  * hggdh is away: walking the dogs
[03:52] <ovoskeuiks_> hi, how would I go about reporting a bug in intrepid alpha4?
[03:54] <bcurtiswx> ovoskeuiks_, go to http://bugs.launchpad.net/ubuntu and click "report new bug"
[03:56] <bcurtiswx> ovoskeuiks_, you should also go to https://help.ubuntu.com/community/ReportingBugs
[03:56] <ovoskeuiks_> thanks
[03:59] <bcurtiswx> ovoskeuiks_, you're welcome
[05:44] <dholbach> gooooood morning
[11:56] <Oli``> I just had one of my bugs tagged as a duplicate of another bug but I can't see that bug because it's private. How can I help resolve my problem if I can't see what's going on?
[11:57] <Oli``> (I assume it's private - I'm not sure what other permission modifiers LP has that might stop me seeing another bug)
[11:57] <Ampelbein> Oli``: what bug number is the duplicate bug?
[11:59] <Oli``> Mine: https://bugs.launchpad.net/bugs/263940 the one it's being pointed to: https://bugs.launchpad.net/bugs/263767
[11:59] <Oli``> Indeed =)
[12:05] <MortenB> Hello. Anyone here with updated knowledge of the freeze issues with Hardy (ref: http://ubuntuforums.org/showthread.php?t=907910)? I'm experiencing it myself and am desperately looking for some way to get a usable Ubuntu running.
[12:19] <persia> Oli``: If you're the submitter of a bug, you ought be subscribed, and therefore implicitly subscribed to the suplicate.
[12:20] <persia> Oli``: Which was your bug?
[12:20] <Oli``> The first. Mine is the duplicate.
[12:20] <persia> 940?
[12:21] <Oli``> persia: yup
[12:22] <persia> Yep.  I can confirm it's a duplicate, and the master bug doesn't appear to contain any private information, so I'm opening it.
[12:23] <Oli``> persia: thank you
[12:23] <persia> To All apport triagers: if you're manually marking a dup, please check to see if the master bug needs to be private.
[12:24] <techno_freak> may be this should be added to the wiki under marking duplicates section :)
[12:34] <persia> techno_freak: If you'd like to figure out where specifically the edit should happen, and make that change, I suspect that those like Oli` would be well-served.
[12:34] <techno_freak> ok :)
[12:38] <techno_freak> persia, is the parent bug is private, what should be course of action?
[12:38] <techno_freak> s/is/if/
[12:39] <persia> techno_freak: Well, one ought try to determine why it's private.  If one can't see it, it may be that someone else in the channel is able to do so.
[12:39] <techno_freak> ok
[12:39] <persia> If it's only private because apport makes all bugs private by default, but the coredump has been removed, and none of the apport attachments contain anything private, it may be made public.
[12:40] <persia> On the other hand, if it does contain credit card numbers, phone numbers, email addresses, usernames, passwords, personal email, bank statements, or anything else best kept private, it ought be kept private: in these cases it's worth looking through the duplicates to see if one can find a better candidate for the master (as it could be made public)
[12:48] <techno_freak> persia, added to the end of https://wiki.ubuntu.com/Bugs/MarkingDuplicate
[12:48] <persia> techno_freak: Thank you.
[12:49] <techno_freak> :)
[13:55] <CarlFK> tjaalton: for bug 261977 I just tried your xserver-xorg-core
[13:56] <tjaalton> CarlFK: ok, did it change anything?
[13:56] <CarlFK> if you need anything else, now is a good time
[13:56] <CarlFK> yes
[13:56] <tjaalton> for better or worse?-)
[13:56] <tjaalton> ah
[13:56] <tjaalton> worse
[13:57] <CarlFK> different :)
[13:57] <tjaalton> so the fallback mechanism isn't there yet :/
[13:57] <CarlFK> brb - need to make coffee
[13:58] <tjaalton> thanks for testing, I won't be pushing this in intrepid just yet :)
[14:01] <CarlFK> anything else for now?
[14:37] <tjaalton> CarlFK: no, it doesn't work like it should. but maybe we'll be able to fix it later
[14:51] <dholbach> bdmurray: do you think you could apply the "duplicate filter" to the other data sources in harvest-data too?
[15:09] <bddebian> Boo
[15:13] <techno_freak> baa
[15:36] <bdmurray> dholbach: yes, I could
[15:37] <dholbach> bdmurray: that'd be VERY nice
[16:46] <hggdh> bdmurray, ping
[16:47] <bdmurray> hggdh: pong
[17:09] <hggdh> bdmurray, mrooney and I have changed somewhat eeebotu, and it is now more stable
[17:10] <bdmurray> hggdh: great!
[17:11] <hggdh> mike will be expanding it to do some other things you asked for, and probably) I will be adding a configuration option to it
[17:11] <hggdh> bdmurray, just -- please -- bear in mind this is my very first python script/programme
[17:12] <hggdh> program
[17:53] <LaserJock> anybody seen secretlondon lately?
[17:56] <techno_freak> no, long long ago
[18:01] <ogra> LaserJock, only on tons of bugmail today
[18:04] <LaserJock> ogra: yeah!
[18:04] <LaserJock> ogra: I wanted to spread some hugs ;-)
[18:05] <ogra> that would become a grouphug then :)
[18:08]  * LaserJock grouphugs #ubuntu-bugs and runs away
[19:58] <trtr> Hello. I have a doubt. I do not know when and where I should report a regression in "intrepid". The problem is with multimedia keys of my laptop, several keys do not work and others are wrong code assigned.
[19:58] <trtr> Nor do I know to which package should I report the bug.
[20:02] <Ampelbein> trtr: i would report it against hotkeys
[20:02] <Ampelbein> trtr: and regression should be used when it worked in hardy and now its broken
[20:05] <trtr> Ampelbein: in hardy some keys wor
[20:05] <trtr> Ampelbein: From Hardy some key codes are wrong
[20:06] <trtr> ...in intrepid
[20:07] <Ampelbein> trtr: so it did not work completely in hardy?
[20:10] <trtr> Ampelbein: In hardy in the begining I had this problem: https://bugs.launchpad.net/ubuntu/hardy/+source/linux/+bug/217504
[20:12] <trtr> but now also I have the problem with the wrong keycodes
[20:13] <Ampelbein> trtr: report against hotkeys, the report can still be reassigned lateron.
[20:15] <trtr> Ampelbein: ok, thanks :)
[22:52] <nullack> ping seb128
[22:52] <seb128> hi nullack
[22:52] <nullack> Hi Sebastien
[22:52] <nullack> Did you have an opinion on my comments RE an ffmpeg sync for intrepid?
[22:53] <nullack> I realise gstreamer has its own plugin but theres lots of other apps that use libavcodec
[22:54] <seb128> nullack: no, no clue about ffmpeg but talk to siretart on IRC, he's working on xine and ffmpeg
[22:55] <nullack> Will do, I note you suggested the thumbnailer bug I reported was due to ffmpeg thats why I asked
[22:55] <nullack> Also, I noticed the new gstreamer plugins build is missing deps
[22:55] <seb128> nullack: the crash is in the ffmpeg lib indeed
[22:56] <seb128> ah, which one?
[22:56] <nullack> Both ugly and good failed mate
[22:56] <seb128> nullack: failed to?
[22:56] <nullack> Missing dependency one sec Ill look
[22:57] <seb128> nullack: ah, they depwait which is different
[22:57] <seb128> they are waiting on a new gstreamer
[22:58] <nullack> Oh I see, thanks - Missing dependencies: libgstreamer0.10-dev (>= 0.10.20-3)
[22:58] <seb128> I'll will sort that tomorrow thanks for pointing it
[22:59] <seb128> also about new versions request
[22:59] <nullack> Im just keen to see Intrepid have great video :) Thanks mate, have a good day
[22:59] <seb128> ubuntu is version frozen now, so updates need freeze exception
[22:59] <seb128> and having hundred of users opening bugs to have their favorite application updated to the new shiny version is not very optimal
[23:00] <nullack> Well as I understand it the process is to raise a bug
[23:00] <nullack> Perhaps the process should be improved if certain people done like it
[23:01] <seb128> right
[23:01] <seb128> I'm not convinced that launchpad is the right place for such things though
[23:01] <nullack> Id be happy to help you with wording on any justifications for version upgrades if needed
[23:01] <seb128> I tend to think that todo lists should not be handled as bugs
[23:02] <seb128> we usually update gstreamer* when that's reasonable that's why I didn't ask for those but will doubt if required ;-)
[23:02] <nullack> Im happy to follow a process, but right now, Im complying with the process. If it changes, I will comply with the new
[23:02] <nullack> The problem is it becomes chaos when people dont know what to do and invent conflicting processes
[23:04] <seb128> right, opening bugs seem to be the current process
[23:04] <nullack> I will support process improvement, thats important
[23:04] <seb128> I don't like new versions request bugs usually because the issue is often not that we don't know about the update (at least for desktop updates) but that we lack manpower to do those
[23:05] <seb128> and that's not opening a bug which will fix that, it just generates extra bug mails and users who add "+1" comments
[23:06] <nullack> I think the complexity is that your needs are different to say a MOTU package that may not be watched all the time
[23:06] <seb128> right
[23:06] <seb128> though arguably if the packages is not watched the bugs are not either
[23:07] <nullack> MOT seem to mark it wishlist and let it sit until they have manpower - they do tend to watch the upgrade bugs
[23:07] <seb128> right, that do a nice and easy todolist for contributors when they are nicely tagged
[23:09] <nullack> The problem is one of the packages I did to you was MOTU, so any rule about one process for MOTU and one for core dev may not work
[23:09] <nullack> The gstreamer ugly request
[23:10] <nullack> What if launchpad had some logic to decide it automatically or something?
[23:10] <seb128> not sure it would scale
[23:10] <seb128> each team might have workflows etc
[23:10] <nullack> different ones yeah
[23:11] <nullack> I want to optimise my time and especially yours mate, right now I dont have a process in mind that would universally work
[23:11] <nullack> Im against having formal processes that doesnt work for certain people
[23:13] <seb128> right, I've no strong objection against upgrade bugs if people who file those are reasonable
[23:13] <seb128> ie if those don't turn to users who don't understand the freeze need voting to get their favorite software updated
[23:13] <nullack> Perhaps then the process should more fully define what is reasonable. Right now, any existing package could get an upgrade request at any time and comply with the process
[23:14] <seb128> right, maybe it should have a note that update requests during freezes should have a freeze breakage rational
[23:15] <nullack> And an example one
[23:18] <RAOF> Perhaps the thinking should not be "please upgrade this software" so much as "upgrading this software will fix $LIST_OF_LP_BUGS"
[23:18] <nullack> Morning RAOF
[23:19] <RAOF> Morning
[23:19] <nullack> That would make the free breakage rational easier too by giving some base content to support it
[23:19] <nullack> *freeze
[23:20] <RAOF> "New version fixes LP: foo, bar, baz" is more likely to be useful to packagers, even packagers who follow upstream reasonably closely.
[23:21] <nullack> And maybe new functionality that would be useful like a new decoder being in libavcodec
[23:22] <nullack> I assume seb128 and RAOF you blokes know how processes get reviewed / implemented? I dont know myself
[23:23] <nullack> i.e. how to go about gaining agreement to the change, documenting it and communicating it
[23:24] <seb128> the usual way is what you did, mailing the lists to start a discussion about the issue
[23:24] <seb128> and then suggesting to document what seems to be the agreement
[23:26] <nullack> RAOF would you like to respond to my mail with your ideas and Sebs then?
[23:27] <nullack> Or I could summarise it, just dont want to be seen to steal your ideas :)