[00:56] <alucardni> Hello, I'm in process of triaging LP 618562 but I'm not able to mark the bug as triage :-S
[00:59] <micahg> alucardni: no, you can't, you should request that in #ubuntu-bugs if you think it has all the information
[01:00] <alucardni> thanks micahg :)
[03:19] <lfaraone> Hmm. Would bug 578608  qualify for a SRU? Upstream asked for the fix to be ported back to Lucid.
[03:22] <micahg> wow, they're really bad at 1 fix per commit...
[03:23] <micahg> lfaraone: you would need the code for that one fix
[03:23] <micahg> ugh...http://code.google.com/p/autokey/source/detail?r=233
[03:23] <lfaraone> micahg: hehe. upstream identified the change.
[03:24] <micahg> lfaraone: out of that mess?
[03:24] <lfaraone> micahg: http://code.google.com/p/autokey/source/diff?spec=svn233&r=233&format=side&path=/branches/autokey-combined/src/lib/gtkui/settingsdialog.py
[03:25] <micahg> lfaraone: just that file?
[03:25] <lfaraone> micahg: that's what I was told. http://code.google.com/p/autokey/issues/detail?id=44#c5
[03:25] <lfaraone> micahg: the fix looks right, too.
[03:26] <lfaraone> since we don't ship an autokey.desktop anymore.
[03:26] <micahg> lfaraone: k, well, they review in upload queue now, so I'd say make the SRU and upload to -proposed, seems pretty safe
[03:31] <lfaraone> micahg: okay, that version of the package has no patch system. I'm okay to just make the change directly to the source, then?
[03:31] <lfaraone> (it has a debian/patches/ dir though :X )
[03:31] <micahg> lfaraone: yes
[03:31] <micahg> lfaraone: is it source format 3?
[03:32] <lfaraone> micahg: nope.
[03:33] <lfaraone> that's odd, that changeset was already in lucid.
[03:33] <lfaraone> upstream must have found the wrong fix, then :)
[03:34] <micahg> lfaraone: heh :)
[03:34] <lfaraone> well then, makes my life easier. "incomplete, identify a fix and get back to me"
[03:46] <ScottK> 10.04.1 is released, so -proposed is open for business again.
[03:53] <cody-somerville> ScottK, has there been any changed to 10.04.1 in the last hour?
[03:53] <cody-somerville> *changes
[03:54] <ScottK> cody-somerville: It was released.
[03:56] <cody-somerville> fabulous
[07:09] <Rhonda> Now that the FeatureFreeze is in place, how would one request a sync? Does requestsync has a special option for that?
[07:10] <Rhonda> Actually I missed the timeline for a sync request for wesnoth-1.8 which finally contains the unversioned meta package to ease upgrades.
[07:10] <persia> It doesn't.  If the sync doesn't include new features, just follow the normal procedure.  If it does, file an exception request, and change to a sync when approved.
[07:10] <persia> !ffe
[07:10] <Rhonda> And it would be a good idea to drop the wesnoth source package from maverick alltogether.
[07:11] <Rhonda> persia: Well, it actually can be considered a new feature that it now builds the unversioned metapackage to ease upgrades. :)
[07:11] <persia> File a bug with the rationale for removal, and subscribe the archive admins.  Most with good rationales are honored,.
[07:11] <Rhonda> I'll try that.
[07:12] <persia> heh.  Well, if you want, file an exception request :)  To me it sounds like you're just fixing an upgrade bug.
[07:12]  * persia is *not* involved in approving freeze exceptions, so any guidelines expressed are entirely personal
[07:18] <ajmitch> requestsync does actually have a feature for syncs after feature freeze
[07:19] <ajmitch> it just subscribes the release team to the bug that gets filed
[07:22] <Rhonda> argl, subscribed OEM Archive Admins by accident.  %-/
[07:23] <nigelb> heh, don't think it matters
[07:23] <Rhonda> How do I find the archive admins in the subscribe box? It only lists me the OEM ones and UK Mirror Service?
[07:24] <nigelb> ubuntu-archive
[07:26] <Rhonda> Alright, #619650 and #619652 :)
[07:27] <ajmitch> this is why requestsync has the -e flag :)
[07:28] <ajmitch> but I see one is a removal request
[07:28] <Rhonda> Yes, and I can't use the requestsync tool from here. :)
[07:28] <ajmitch> but why not? :)
[07:29] <Rhonda> my notebook is not networked here
[07:29] <ajmitch> ah
[07:29] <ajmitch> irc by phone?
[07:30]  * ajmitch saw something scary on debian-devel today - an ITP for an emacs twitter client
[07:30] <nigelb> o.O
[07:30] <Rhonda> No, but firewall and similar means. Won't even get an IP address. :)
[07:31] <Rhonda> ajmitch: qataki is all the twitter client that I ever need.
[07:32] <ajmitch> morning dholbach
[07:32] <dholbach> good morning
[07:33]  * nigelb waves to dholbach 
[07:33] <ajmitch> nigelb: so when's the next behind the circle interview going up? :)
[07:33] <dholbach> hey nigelb
[07:33] <nigelb> ajmitch: as soon as LucidFox and I get organized.  We're getting there :0
[07:34] <nigelb> ajmitch: I finally got the new list and processing it.
[07:34] <nigelb> dholbach: http://blog.qa.ubuntu.com/node/101 \o/
[07:34] <dholbach> nigelb, YES!
[07:35] <nigelb> 409 is a good number, small but good :)
[07:35] <ajmitch> great
[07:36] <nigelb> We're moving slowly. (hint hint: Review one patch a day!)
[07:44]  * ajmitch decides to be naughty & start up debian
[08:35] <vish> nigelb: i think we need a reality check.. :) '409' i would consider that number very close to the normal patch/debdiff review which /had/ already been going on. the script tags debdiffs as patch as well, so debdiffs moving out of the sponsors queue is also included in 409. Plus if you see the desktop patches, patch submitters are immediately asked by the desktop team to forwarded them upstream,so bug gets tagged -forwarded which /was/ already a regula
[08:35] <vish> r process,[a lot of the other teams do the same as well], which would eventually yield a much lower number of reviews actually being done. but yes, "We're moving on very slow and we need to Review one patch a day!"  we have to remember that this is the first cycle this has been started, so its not bad for a new start... :)
[08:36] <vish> oh! typed too much ;p
[08:41]  * nigelb blinks
[08:41] <nigelb> I turn my eyes away and I have 2 paragraphs to read.
[08:41] <vish> ;p
[08:41] <nigelb> vish: If desktop patches come under our workflow that is indeed a good thing.
[08:42] <nigelb> But that is still not cheating the numbers anyway.
[08:43] <vish> nigelb: dint say it was cheating , but the number of patches being actually reviewed is lower than we can attribute,  while it only increases their work
[08:43] <nigelb> vish: the 409 is the sum of all unique bugs with anything other than patch tags.
[08:43] <nigelb> vish: how is it increasing their work?
[08:43] <nigelb> Its just a workflow that we follow for bugs with patches.  they're happy to adopt the same as well.
[08:44] <vish> nigelb: yeah , they now have to remember to tag a bug patch-whatever for something they have already been doing..
[08:44] <nigelb> which is not a big deal if you ask me.
[08:44] <nigelb> I know that seb has been reviewing a good number of patches :)
[08:45] <vish> nigelb: nope not a big deal, but what i'm trying to mention is, that it doesnt/shouldnt really count as a patch reviewed by the "Operation cleansweep"
[08:50] <nigelb> vish: why NOT!
[08:51] <nigelb> Operating cleansweep is about reviewing all the patches.  It doesn't say that if desktop does something it shouldn't be counted.
[08:51] <vish> nigelb: we've just increased a bit of their work and claiming it as part of the success for the project, which is supposed to clean up the old patch which were left unattended
[08:52] <vish> nigelb: what i'm trying to say , is review process != Operation Cleansweep
[08:52] <vish> nigelb: desktop following th process is good
[08:52] <vish> the*
[08:53] <vish> but claiming it as part of something different which we initially intended to do is just a bit of hogwash.. ;p
[08:54] <Rhonda> Can someone help me understand the openarena build errors on amd64 and powerpc? https://launchpad.net/ubuntu/+source/openarena/0.8.5-3
[08:55] <Rhonda> The following packages have unmet dependencies:
[08:55] <Rhonda>  libsdl1.2-dev : Depends: libpulse-dev but it is not going to be installed
[08:55] <Rhonda> … in both build logs. It doesn't look like that would be something that has to get addressed in openarena, is it?
[08:58] <nigelb> vish: Cleansweep was not perse about old patches.  It was about *all* the patches.
[08:58] <nigelb> This discussion did come up at UDS.  Did we want to do only old or both old and new.
[08:59] <nigelb> The choice was to do all and this was a known side effect.
[08:59] <nigelb> s/was/is
[09:01] <nigelb> lunch, afk
[09:06] <geser> Rhonda: it looks like archive skew, a give-back of openarena should work
[09:06] <vish> nigelb:  i dont see how that sounds really sensible, taking the work that has already been going on by the existing teams and tagging them as /our/ success is wrong..  :)
[09:06] <Rhonda> geser: So clicking on the retry?
[09:07] <geser> yes
[09:07] <Rhonda> Thanks. Rather asking twice (and annoy through that) than annoy through clicks that weren't meant to follow. :)
[09:08] <geser> I checked with "apt-get -s build-dep openarena" if this got fixed (pbuilder would also work)
[09:09] <Rhonda> Don't have a powerpc or amd64 system on which I could try that at hands. :/
[09:10] <geser> I've only amd64 and checked there
[09:11] <vish> nigelb: in the sense, what has Operation Cleansweep actually improved, wrt patches? we brought in a workflow, but has it really improved the chances of a patch getting reviewed?
[09:15] <nigelb> vish: It has.   To some extent.
[09:15] <nigelb> The problem is the backlog.
[09:15] <nigelb> If we are at zero, its easier to review the newer ones
[09:16] <nigelb> if at some point we manage to clear the backlog (I hope by end of N cycle), then patches would be processed fast.
[09:16] <bilalakhtar> hey
[09:16] <vish> nigelb: yes it did, but we need to claim responsibility *only* for that, right now, its like just using a contributors patch and the uploader claiming it to be his just because he uploaded it..
[09:16] <bilalakhtar> vish: IMHO it hasn't improved anything
[09:16] <bilalakhtar> vish: we are still at 13% progress
[09:17] <nigelb> bilalakhtar: isn't taht much better than zero.
[09:17] <nigelb> It was bitrotting
[09:17] <vish> bilalakhtar: yes, we have not improved a lot, but if you check the backlog that 13% is a bit cooked up too ;)
[09:17]  * nigelb notes that its 19%
[09:17] <nigelb> http://bobbo.me.uk/
[09:17] <nigelb> vish: How /can/ you claim its cooked up
[09:18] <nigelb> Operation cleansweep is about reviewing *all* the patches.  We are getting there.  Which is process.  *NOT* cooked up.
[09:18] <vish> nigelb: yes, its not *actual* work what has been done..
[09:18] <nigelb> ugh, you're rounding up to the same point again.
[09:18] <bilalakhtar> nigelb: vish is right. its cooked up. people are just in a hurry and are reviewing patches in a very easy and quick way
[09:19] <bilalakhtar> nigelb: There are many regression bugs coming up now
[09:19] <nigelb> bilalakhtar: wait, are you confusing one with other?
[09:19] <nigelb> patch review is about forwarding patches to relevant upstream
[09:19] <vish> nigelb: it is just claiming a process that has been going on for years and saying "yay! we have done these many bugs" , when the actual bugs being reviewed are by the sponsors and the teams which have been doing this work for ages
[09:19] <nigelb> Its not about getting them into Ubuntu immediately.
[09:19] <bilalakhtar> nigelb: I understand, but both needs to be done, right?
[09:20] <nigelb> bilalakhtar: can you read the wiki for reviewers team please? You're confusing sru process with this.  Its totatly different.
[09:20] <bilalakhtar> nigelb: no I am not
[09:20] <nigelb> vish: We started at 0.  Now we're at 400.  How does this be done by sponsors?
[09:21] <bilalakhtar> nigelb: I completely understand OC is for development releases
[09:21] <bilalakhtar> not *stable* releases
[09:21] <vish> nigelb: why are debdiffs being tagged? and counted when they are done by the sponsors?
[09:21] <nigelb> bilalakhtar: NO.  OC is not for development release either.
[09:21] <nigelb> vish: debdiffs are not counted.
[09:21] <bilalakhtar> nigelb: then what?
[09:21] <vish> nigelb: they are, i have shown you this several times
[09:21] <bilalakhtar> nigelb: lol, are all patches going into lucid then?
[09:21] <nigelb> bilalakhtar: https://wiki.ubuntu.com/OperationCleansweep
[09:22]  * bilalakhtar has that page open
[09:22] <nigelb> vish: YES, but that doesn't get into the count which I'm talking about
[09:22]  * nigelb moves discussion to -reviews
[09:22] <bilalakhtar> nigelb: 'The idea is to get the number of bugs with patches down to 0 by Maverick's release.'
[09:23] <nigelb> bilalakhtar: Yes, but we will not incorporate them into maverick immediately.
[09:23] <nigelb> The idea is to forward them upstream, and let them make a call
[09:23] <bilalakhtar> nigelb: that's whta I meant
[10:32] <Rhonda> geser: \o/ - the builds did now succeed. :)
[10:36] <bilalakhtar> Rhonda: DDs rule the world! Are you fre?
[10:36] <bilalakhtar> *free
[10:36] <bilalakhtar> I have an NMU awaiting sponsorship from a long time
[10:38] <Rhonda> No, I'm commercial.
[10:38] <bilalakhtar> Rhonda: You could have said 'I am contrib'
[10:39] <Rhonda> Hmm, that might fit pretty well actually. I only depend on non-free stuff to sustain my life, personally I could be considered free. Though, it might be that some special person in my life could disagree with that. :)
[10:40] <bilalakhtar> well, it was http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=10;filename=debdebdiff.debdiff;att=1;bug=589502 Rhonda
[10:41]  * Rhonda wonders where the attached screenshot in that bugreport is :)
[10:42] <Rhonda> Did you try contact the gnome team?
[10:42] <bilalakhtar> Rhonda: yup, from the last 2 days
[10:42] <bilalakhtar> Rhonda: sent a message to their list, but it is bouncing
[10:42] <Rhonda> I might give it a shot tomorrow evening (european time), can you ping me again then?
[10:42] <bilalakhtar> Rhonda: Thanks a lot!
[10:42] <azeem> well, once
[10:42] <Rhonda> I don't have the ressources or environment right now to test it.
[10:42] <bilalakhtar> Rhonda: np at all
[11:23] <raywang> anyone knows how to remove a deb package regardless the dependencies, i want to force to remove a package
[11:27] <tumbleweed> raywang: I assume you have a good reason? dpkg has a --force option
[11:28] <raywang> tumbleweed, well , it doesn't work
[11:29] <bond_gone> raywang, but you should be beware of reverse dependencies as it might break working of a system
[11:29] <tumbleweed> raywang: if I have to talk you through getting it to work, I'm worried that you aren't aware enough of how bad this is
[11:29] <raywang> bond_gone, yeah, i know, but no problem with that, i just want an option like --nodeps in rpm
[11:30] <raywang> tumbleweed, well, i know, i want to downgrade a package, but it doesn't allow me to do that with apt-get
[11:30] <tumbleweed> apt-get does allow you to downgrade
[11:30] <tumbleweed> as does dpkg
[11:30] <bond_gone> raywang, even aptitude does
[11:30] <raywang> so what i'm thinking is remove that package regardless the dependencies, and use apt-get to install right away
[11:31] <azeem> raywang: that's the wrong solution
[11:31] <azeem> just downgrade it
[11:31] <raywang> well, how to use apt-get to downgrade a package, i still can get it from the manpage :(
[11:31] <raywang> can't
[11:31] <tumbleweed> raywang: apt-get install package=$VERSION
[11:32] <raywang> ok
[11:32] <tumbleweed> or package/$RELEASE
[11:32] <azeem> raywang: then your question should've been that, not "how do I break my system"
[11:33] <raywang> well, it remove some dependencies as well when I downgrade it...
[11:34] <tumbleweed> raywang: was this a new version from a ppa?
[11:34] <raywang> yep
[11:34] <tumbleweed> look at ppa-purge
[11:34] <bond_gone> raywang, aptitude resolves the dependencies on downgrade i think
[11:35] <bond_gone> so that your system will not break stuff
[11:35] <raywang> the original name is like x.x.x-lucid0~ppa15, but new version is like x.x.x.-lucid~ppa19
[11:35] <azeem> ouch
[11:35] <raywang> so apt-get can't install the newer one,
[12:51] <AnAnt> Hello
[13:17] <highvoltage> tumbleweed: ooh, happy belated birthday!
[13:17] <tumbleweed> highvoltage: thanks :)
[13:19] <nigelb> oh.
[13:19] <nigelb> HAPPY BIRTHDAY tumbleweed !
[13:19] <tumbleweed> nigelb: 'twas yesterday, thanks
[13:20] <nigelb> ah.  Still.  Birthday is birthday :)
[13:24] <yofel> who reviews merges against ubuntu packages again? it wasn't ubuntu-branches iirc
[13:24] <AnAnt> ubuntu-sponsors ?
[13:26] <yofel> hm, and how do you change that? As https://code.edge.launchpad.net/~chilicuil/ubuntu/maverick/dkms/fix-613407/+merge/32626 has ubuntu-branches as reviewer
[13:27] <tumbleweed> yofel: it appears on the sponsor list just fine
[13:28] <yofel> really? I guess I missed it then :(
[13:29] <yofel> meh, right, should have just used ctrl+f to search for it -.-, sry
[13:33] <bond_gone> tumbleweed, happy belated birthday
[13:35] <nigelb> yofel: Its a mistake by the person requesting the merge
[13:35] <nigelb> The reviewer should be set to ubuntu-sponsors.
[13:35] <nigelb> (or so I think.  somone correct me if I'm wrong)
[13:36] <tumbleweed> nigelb: practically speaking that probably doesn't matter (as ubuntu-sponsors doesn't receive mail). nigelb: thanks :)
[13:36] <tumbleweed> bleh, bond_gone: thanks
[13:36] <nigelb> tumbleweed: its not about mail
[13:37] <nigelb> its about getting permission to merge it (I think. Again)
[13:37] <nigelb> Its been a while since I packaged.
[13:37] <tumbleweed> anyone can merge it
[13:37] <tumbleweed> (with the right rights)
[13:37] <tumbleweed> and anyone can review it
[13:37] <nigelb> hm, then things have changed.
[13:38] <nigelb> Earlier if you didn't set sponsors as reviewer, the sponsor couldn't review it.
[13:39] <tumbleweed> nigelb: as far as I understand it, the request review function is just to generate mail (and to differentiate between requested reviews and "community" reviews)
[13:39] <nigelb> tumbleweed: I'm talkinga bout setting Branch Reviewer
[13:40] <nigelb> tumbleweed: I may be wrong though.
[13:40]  * nigelb is a bit rusty.
[13:41] <tumbleweed> I thikn the branch reviewer sets the default review request, and who has the permission to manipulate the review status, in which case ubuntu-dev seems to be right
[13:42] <nigelb> tumbleweed: as far as I remember, the default reviewer would be ubuntu-branches which needs to be changed to ubuntu-sponsors.
[13:42] <nigelb> (by the person requesting the merge)
[13:42] <nigelb> should ask bdrung for more info though
[13:42] <nigelb> He would know better :)
[14:35] <MDC1> is it possible to create a ppa from a bzr repo on launchpad automatically now?
[14:38] <shadeslayer> MDC1: erm you mean recipes ?
[14:38] <shadeslayer> creating packages for daily builds
[14:38] <MDC1> shadeslayer: maybe?
[14:39] <MDC1> shadeslayer: would be good if it's not only daily builds but also from tags
[14:39] <shadeslayer> cant do tags for now
[14:39] <shadeslayer> but dailies are there
[14:39] <MDC1> shadeslayer: and for different versions of ubuntu
[14:39] <MDC1> dailies would be a good start :)
[14:39] <shadeslayer> import project to bzr -> make packaging branch -> make recipe -> fire away
[14:40] <shadeslayer> MDC1: yeah thats supported
[14:40] <shadeslayer> goes ALL the way back
[14:40] <shadeslayer> i think it goes back to hardy :PO
[14:41] <MDC1> shadeslayer: hmm.. i was more thinking about clicking things in lp and not doing anything locally. just commit to bzr and lp automaticlly triggers a build + upload to ppa..
[14:41] <MDC1> shadeslayer: i thought i read that a while back that it was in the pipe..
[14:41] <MDC1> shadeslayer: might be wrong though
[14:41] <shadeslayer> actually
[14:42] <shadeslayer> it is all webbased
[14:42] <shadeslayer> MDC1: you just push your packaging to one branch
[14:42] <MDC1> shadeslayer: oh.. it is
[14:42] <shadeslayer> and import your project in another
[14:43] <shadeslayer> MDC1: https://help.launchpad.net/Packaging/SourceBuilds/Recipes
[14:43] <MDC1> shadeslayer: hmm.. not really sure what you mean. thing is this is a new small application i'm writing and thinking if using lp + bzr + ppa would make my life happier ;
[14:43] <MDC1> ;)
[14:44] <shadeslayer> yeah, should not be a problem :)
[14:44] <shadeslayer> MDC1: for eg. project neon : https://code.edge.launchpad.net/~neon : the packaging is in foo-ubuntu and code import in foo
[14:47] <MDC1> shadeslayer: hmm.. lots of new magic to learn. i'll give it a try :) thanks a lot
[14:48] <shadeslayer> no problemo
[16:14] <AnAnt> Hello
[18:37]  * jdong mumbles quietly about build-deps for clean target
[18:51]  * geser mumbles "dpkg-source -b" might work depending on the changes
[19:03] <lfaraone> Wrt Planet Ubuntu, is the list of corporate blogs up to date? I've seen Turnkey and Dell on the 'net, but they 're not isted on <https://wiki.ubuntu.com/PlanetUbuntu#Corporate Blogs>
[19:23] <bdrung> nigelb: i am back. something you want to ask?
[19:40] <fta> siretart, hi, any idea what's causing subs to stay on screen in recent mplayer (in maverick)?
[20:53] <angelabad> Hi cjwatson,
[21:04] <Rhonda> Hmm, did daniel find someone for tomorrow's tech talk?
[21:04] <dyfet> ping scottk
[21:05] <Rhonda> ScottK?
[21:05] <ScottK> On the phone.
[21:05] <dyfet> ok :)
[22:54] <ScottK> dyfet: I forgot to get back to you.  Sorry.
[22:54] <ScottK> dyfet: I'll be sort of here/not for a bit so ping with what's up and I'll reply when I can.
[22:55] <dyfet> scottk: ah, yes.  I had not been able to rebuild python-qt4 either currently on Maverick, so I had not been able to try some of my fixes for kdebindings :(
[22:55] <ScottK> OK.  Still needs doing ....
[22:56] <dyfet> python-qt4 dies trying to get qtdirs...seems like it may be very basic
[22:57] <dyfet> but I never played with the qt config stuff
[23:15] <geser> argh, /me just following the link from Martin Meredith blog post
[23:16] <directhex> NARWHALS!
[23:18] <dyfet> I guess naughty numbat is out then...
[23:23] <directhex> i still want owls for 11.10
[23:31] <micahg> do packaging cleanup changes need an FFe (I can never remember this)
[23:34] <ScottK> micahg: Depends on if you're fixing stuff or changing the entire build system....
[23:36] <micahg> ScottK: it's for a merge from Debian: http://changelog.debian.net/google-gadgets  <-- we have everything except the top changelog
[23:36] <micahg> I would think that's all just cleanup except for source format 3
[23:41] <jdong> hmm, grumble
[23:41] <jdong> a lot of hash sum mismatches from debmirrored Packages.bz2
[23:42]  * jdong wonders if it's time to look for a different mirroring solution
[23:46] <jdong> but the hashes of the mirrored file and real file are the same...
[23:50] <micahg> wgrant: I have a feeling ubuntuwire is still pulling from testing instead of unstable
[23:53] <micahg> wgrant: nm
[23:53] <wgrant> micahg: What was the problem?
[23:54] <micahg> wgrant: idk some things just aren't updating like chmsee
[23:54] <wgrant> Let's see.
[23:54] <wgrant> Which page?
[23:54] <micahg> http://qa.ubuntuwire.org/mdt/mozilla.html
[23:55] <wgrant> OK, yeah, something is still broken.
[23:56] <wgrant> It's still getting confused when there are multiple versions of a source in Sources :(