[00:01] <bdmurray> kees: what do you mean by handle?  keep it in one place and use includes is what I'd do
[00:01] <kees> bdmurray: okay, in which direction?  should the 'master' be in SecurityTeam/BugTriage or in Bugs/Responses ?
[00:02] <bdmurray> kees: whichever you are more likely to edit ;-)
[00:02] <kees> heh
[00:02] <bdmurray> so I'd say SecurityTeam/BugTriage
[00:04] <kees> is there a way to do section includes?
[00:05] <bdmurray> kees: its just a regex so make the from and to your section
[00:07]  * kees fights with moin
[00:10] <kees> bdmurray: \o/ got it
[00:10] <bdmurray> what's the regex look like?
[00:11] <kees> <<Include(SecurityTeam/BugTriage, , from="[00:13] <bdmurray> it looks like you got a bit extra too
[00:13] <bdmurray> and in a to="== Existing Bugs ==" maybe
[00:14] <bdmurray> after from
[00:16] <bdmurray> kees: ^
[00:18] <kees> bdmurray: d'oh! thanks
[00:19] <kees> Include: Nothing found for "== Existing Bugs=="!  wtf
[00:20] <bdmurray> kees: you are missing a space after Bugs
[00:21] <kees> *facepalm*
[00:23] <kees> okay!  fixed up.
[00:23] <bdmurray> sweet
[00:25] <maco> does ubuntu-qa include doing qa on the wiki?
[00:26] <bdmurray> no, that's just part of being awesome! ;-)
[00:26] <maco> heh
[00:27] <maco> well its probably a job for more than one person, but very repetitive: some wiki pages have hundreds of attachments which need to be removed because they are html files of spam. some of them are pornographic in nature.
[06:23] <dholbach> good morning
[06:28] <maco> hiya
[06:29] <dholbach> hi maco
[08:11] <thekorn> ara, good morning, what do you think about merging changes (new hugday tool) from lp:ubuntu-qa-tools/ubuntu-qa-tools-0.1 into lp:ubuntu-qa-tools?
[08:11] <thekorn> so the hugday tool is also in trunk
[08:11] <thekorn> or do you want to keep packaging stuff seperated
[08:12] <thekorn> (as this would also pullin all the packaging related changes)
[08:13] <ara> thekorn: no, it is absolutely worth merging, but I did some changes in those in trunk, that I need also to request the merge. I will see what's worth merging and request a merge today
[08:13] <ara> bdmurray will review it
[08:13] <thekorn> ok great
[08:15] <thekorn> I will wait for requesting the merge of the fix for bug 328537 until everything is in trunk
[08:55] <SPF> when I use apt-get install flashplugin-nonfree, the wget executed in this script is not using the apt proxy settings so the download will fail
[09:22] <savvas> SPF: which distribution?
[09:44] <savvas> SPF: https://bugs.launchpad.net/ubuntu/+source/wget/+bug/232469
[09:47] <SPF> savvas: yes, that is my problem :)
[09:48] <SPF> I manually downloaded the file and it works now
[09:50] <SPF> the distro is intrepid am I right?
[09:55] <savvas> SPF: the problem isn't fixed in neither intrepid nor jaunty, the development release
[09:55] <savvas> I've updated the bug with some suggestions
[10:04] <mnemo> is it necessary to have a GPG key to fix bugs in ubuntu (i.e. to submit a debdiff) ???
[10:06] <savvas> mnemo: I don't think so, but it is recommended
[10:07] <seb128> mnemo: no
[10:07] <seb128> savvas: why would it be recommended to have a gpg key to send a patch to a bug?
[10:08] <mnemo> i already wrote the patch and got it merged upstream... but I would like to learn how to update the .deb in ubuntu
[10:08] <mnemo> i know I can just attach the .patch file but I want to do it right so that there is minimal work for the guy who does the upload
[10:09] <mnemo> so then do I need the GPG key?
[10:10] <mnemo> this page mentions "the GPG key" for example? --> https://wiki.ubuntu.com/PackagingGuide/Recipes/Debdiff
[10:10] <seb128> no, gpg is used to sign uploads
[10:10] <seb128> you don't need it for a local build or sending a debdiff
[10:10] <mnemo> ok great, I'll wait with that then
[10:10] <seb128> and you signing or not makes no different on the amonth of work for the sponsor
[10:11] <savvas> seb128: sorry, I was thinking about packaging while I typed that
[10:28] <mnemo> hmm, if I want to apply two patches from upstream into the ubuntu package, then must I open two bugs in launchpad and also do two debdiffs ??
[10:29] <seb128> mnemo: depends of the changes I would say
[10:30] <seb128> mnemo: if they are easy enough you can use one bug
[10:30] <seb128> mnemo: what sort of changes do you work on?
[10:30] <mnemo> im hoping to submit fixes for http://bugzilla.gnome.org/show_bug.cgi?id=564372 and http://bugzilla.gnome.org/show_bug.cgi?id=564371
[10:31] <mnemo> the second one is _really_ minor
[10:32] <seb128> you should try to get upstream to roll a new tarball ;-)
[10:33] <mnemo> just getting them to merge these two patches int osvn was a looong process, maintainers are very busy/unresponsive it seems
[10:34] <mnemo> besides, i sort of really want to learn how to create debdiffs and I thought these were sort of easy beginners bugs
[10:35] <mnemo> seb128: hmm..   _if_ they did a new tarball, could I package that directly into ubuntu or would I need to get it into debian first?
[10:35] <seb128> ubuntu directly works
[10:36] <mnemo> ok I will ask them at least then
[10:40] <seb128> mnemo: otherwise for such changes better to open one bug and do one debdiff listing both changes
[10:42] <mnemo> okay
[11:31] <mnemo> seb128: to apply those two patches in a single debdiff, should I run "cdbs-edit-patch" twice and then "dch -i" once (describing both changes) ??? or should I run dch -i twice?
[11:32] <seb128> mnemo: dch one, dch is to add a changelog entry
[11:32] <seb128> you can use your editor then to edit the changelog entry if required
[11:32] <seb128> one changelog entry can list several changes
[11:33] <mnemo> ok so I will use the first alternative then
[11:33] <mnemo> thanks
[12:07] <dholbach> "How to run a Bug Jam" sesion in #ubuntu-classroom now!
[12:11] <Laney> Can someone school me in making upstream package links on Launchpad?
[12:11] <Laney> I want to link bug #329018 to http://prototype.lighthouseapp.com/projects/8886/tickets/216-improve-initial-loading-speed
[12:12] <dholbach> you might need to start with https://launchpad.net/projects/+new
[12:12] <Laney> ah
[12:13] <dholbach> https://bugs.launchpad.net/bugs/bugtrackers/+newbugtracker too
[14:01] <dupondje--> Cannot use both zlib.output_compression and output_handler together!!
[14:01] <dupondje--> this is a new bug in php ?
[14:01] <dupondje--> went broken after updating to new php modules
[14:08] <dupondje--> https://bugs.launchpad.net/ubuntu/+source/php5/+bug/329053
[15:08] <bddebian> Boo
[15:11] <BUGabundo> foo
[15:11] <mnemo> whee I just finished my first debdiff --> https://bugs.launchpad.net/ubuntu/+source/ghex/+bug/329020
[15:11] <mnemo> looking for a sponsor :)
[15:11] <mnemo> seb128: still here? ^^
[15:12] <seb128> mnemo: yes and no, I'm busy enough on standard desktop I will let universe sponsoring to motu rather
[15:13] <mnemo> mmkay, np
[15:13] <seb128> mnemo: the debdiff looks good, don't bother backporting changelog entries though, they often don't apply cleaning are extra work for no win
[15:14] <mnemo> aha, ok.. good to know
[15:16] <dholbach> mnemo: good work! :-)
[15:17] <seb128> mnemo: I've pinged some desktop contributors on #ubuntu-desktop who won motu membership today about your bug
[15:18] <seb128> dholbach: do you know if upload rights are already granted?
[15:18] <mnemo> thanks guys
[15:19] <dholbach> seb128: whom?
[15:19] <dholbach> seb128: ah yes, I added all of them to the team
[15:19] <seb128> dholbach: huats and didrock, can they upload to universe?
[15:19] <dholbach> laney and quadrispro too
[15:19] <seb128> ok cool
[15:19] <seb128> I was not sure if that was pending is tasks too
[17:22] <bdmurray> Can anybody recreate bug 283316 on jaunty?
[17:33] <charlie-tca> I haven´t seen it in a while; using jaunty daily for over a month
[17:35] <maco> er...laptop users cant really answer i guess, since they only open
[17:36] <bdmurray> It might just be me, it only happens with one drive
[17:41] <thekorn> hmm, the new feature in LP to only show the first 80 comments is a real pain
[19:45] <charlie-tca> I need a little help with bug 307491
[19:46] <charlie-tca> What does "/usr/bin/yelp" have to do with thunar crashing when trying to open the Trash directory?
[19:47] <charlie-tca> Is this even valid?
[19:48] <bdmurray> charlie-tca: that's a bug reported via 'help - report a problem' in yelp
[19:48] <bdmurray> notice the apport-bug tag
[19:49] <bdmurray> most bugs with 'sourcepackage: yelp' and apport-bug tag are not really related to yelp
[19:49] <charlie-tca> I saw the apport tag, but never saw a bug referencing yelp as executable before
[19:49] <charlie-tca> That's the answer then. Thanks.
[19:50] <bdmurray> so I'd just worry about their description and disregard everything else
[19:51] <charlie-tca> That I can do.
[19:51] <hggdh> and adjust the package accordingly ;-)
[21:20] <hyperair> when a patch has been commited upstream, does it mean that the ubuntu task should be set to "fix commited"?
[21:20] <hyperair> i thought the ubuntu task was only set to fix commited when a sponsor has uploaded the patched package to ubuntu
[21:21] <maxb> I'd say anything upstream goes in the upstream task
[21:21] <maxb> and an uploaded package would be "Fix Released"
[21:22] <charlie-tca> Usually fix-committed when upstream goes fix-released, since we will have to wait for the package to get to us to say the bug is fixed
[21:26] <hyperair> maxb: i thought uploaded package means fix committed, and when the binaries hit the archives then it's fix released?
[21:26] <maxb> I don't believe that's the case
[21:26] <hyperair> hmm isn't there any documentation regarding the policy?
[21:26] <maxb> Not least because there's the question: Which architecture's binaries?
[21:27] <hyperair> ah good point
[21:27] <maxb> AFAIK "Fix Committed" means the fix is in the packager's VCS
[21:28] <charlie-tca> yes, there is documentation in bugsquad docs
[21:28] <maxb> https://wiki.ubuntu.com/Bugs/Status
[21:32] <hggdh> yeee! The powers-that-be now accept fix-committed on upstream source code control systems!
[21:32] <charlie-tca> \o/
[21:33] <maxb> on upstream tasks... which is unambiguously sane, no?
[21:34] <hggdh> darnit, I again read too fast!
[21:35] <hggdh> so nothing really changed. I wonder how you can set fix committed on an upstream bug watch
[21:35] <hggdh> since LP automagically sets it
[23:25] <andresmujica1> watch -n1 date +%s
[23:27] <BUGabundo> could some one take a look at https://bugs.launchpad.net/ubuntu/+source/linux/+bug/329254