[00:00] <RAOF> dart: Excellent, thanks.
[00:19] <astraljava> RAOF: Perhaps you were thinking of this: https://wiki.ubuntu.com/UbuntuFriendly ?
[00:20] <nemo> Is it ever appropriate to just file a generic compatibility bug for this laptop model and detail the issues and workarounds?
[00:21] <nemo> astraljava: hm. that looks interesting, but doesn't really have a way to submit test data :)
[00:21] <nemo> looks like more an evang operation
[00:22] <astraljava> nemo: Maybe. I thought this to be interesting, though: https://blueprints.launchpad.net/certify-planning/+spec/cert-o-community-testing
[00:23] <RAOF> nemo: No, not really.  In an ideal world, a bug is a single actionable defect in the software.  ‘Some stuff on this laptop isn't working’ should be a single bug iff it's got a single cause (although you obviously can't actually tell until you've fixed it ☺).
[00:24] <nemo> RAOF: ah.  Mozilla's process is a bit more flexible. they have tracking bugs for various initiatives and whatnot
[00:24] <nemo> big ol' bug hierarchies
[00:24] <nemo> but 'k. guess what I'd be looking for is more some sort of Ubuntu on Laptops where I could fill in an entry for my laptop model - much like Wine has a software database where success can be filled out
[00:25] <RAOF> Yeah.  Launchpad doesn't support bug hierarchies in that way, so we don't use them :)
[00:25] <broder> nemo: i think that's what Ubuntu Friendly is supposed to be working towards
[00:25] <broder> though possibly with a little more rigor around what "working" and "not working" mean
[00:25] <nemo> launchpad is annoying in quite a few ways.  one that bugs me most, is no id for each comment, so I can't link to a comment in context
[00:25] <broder> that's not true
[00:26] <RAOF> nemo: https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/774938/comments/4
[00:26] <nemo> RAOF: right. that's the annoying bit
[00:26] <nemo> you can link to a specific comment
[00:26] <nemo> but if you want to see it relative to the comments around it, you have to scroll through the list
[00:26] <nemo> there is no <div id="comment54323"> as virtually every other blog and bug db out there has
[00:26] <nemo> so even if I look at the HTML I can't make a #comment54323 link
[00:27] <RAOF> Ah, yeah.  That makes sense.
[00:27] <nemo> of course it really should have an anchor for that purpose
[00:27] <nemo> oh well. has been that way for years, and I think I did complain in a bug once, so isn't likely it'll be fixed any time soon
[00:28] <nemo> broder: well. thanks for the link. I'll keep an eye on that page, and if it ever gets to the point where it accepts user submissions, I'll post my laptops :)
[00:28] <nemo> aaand, guess I'll stick w/ issue-specific bugs for now
[00:45] <cnd> RAOF, bryce, slangasek: I can't reproduce the bug in xorg-server, and it's a fairly simple traditional mouse
[00:46] <slangasek> ok
[00:46] <cnd> since there are no other reports, I'm inclined to think something is awry with his particular setup somehow
[00:46] <cnd> I've asked for some more data in the bug
[00:46] <slangasek> maybe he should try the upgrade again?
[00:46] <cnd> I asked him to upgrade, then play back his own recording
[00:46] <cnd> see if it reproduces
[00:46]  * slangasek nods
[00:46] <cnd> it could be something simple like dying batteries :)
[00:47] <slangasek> cnd: thanks; please keep us posted, but I'm not going to take any precipitous action wrt the published SRU at this point
[00:47] <cnd> I am off tomorrow :(
[00:47] <cnd> but I'll try to monitor it
[00:47] <slangasek> is there someone else who can take it over from you?
[00:48] <cnd> I would say anyone of the top dogs of ubuntu-x would be best equipped
[00:48] <cnd> tjaalton, bryce, or RAOF
[00:48] <cnd> it's not multitouch related, so it's not really in the realm of anyone else on the touch team
[00:49] <cnd> forgot about Sarvatt :)
[00:52] <RAOF> Ok.  I'll monitor it today and pass off to bryce or tjaalton in the evening.
[00:52] <RAOF> cnd: Have a good day off tomorrow!
[00:52] <cnd> RAOF, thanks!
[00:53] <tjaalton> actually, I'm off for the rest of the week ;)
[00:53] <cnd> tjaalton, then have fun too!
[00:53] <tjaalton> but yeah, sounds like a dead battery or such
[00:53] <tjaalton> cnd: thx!
[01:06] <bryce> ok
[02:42] <slangasek> hallyn: closing bug #773891 as invalid; you don't appear to be subscribed, so thought I'd let you know
[02:43] <hallyn> slangasek: drat, i thought i'd subscribed by habit.  Thanks much!
[02:44] <hallyn> looks like i need to look at a multi-ach converted library so I know what to look for
[03:21] <broder> https://wiki.ubuntu.com/UbuntuEmail
[03:21] <broder> err, wrong window
[03:32] <sivan> hi all
[03:32] <sivan> Is there anybody from the Montreal office?
[03:32] <sivan> *here
[04:00] <lifeless> kees: hi
[04:00] <lifeless> hmm perhaps too late for you
[04:00] <lifeless> micahg: I seem to recall you're in the security team ?
[04:53] <micahg> lifeless: yes
[04:54] <lifeless> micahg: oh cool
[04:54] <lifeless> micahg: bug 791652 may interest or terrify you
[04:55] <micahg> lifeless: fun :)
[04:55] <micahg> lifeless: are you sure that /tmp isn't in $PATH?
[04:55] <lifeless> /home/robertc/local/bin:/home/robertc/bin:/home/robertc/local/bin:/home/robertc/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
[04:56] <lifeless> micahg: its not there in the environment I run from for sure
[04:56] <lifeless>  set | grep LD
[04:56] <lifeless> $
[05:02] <micahg> lifeless: BTW, I failed to note it was private until after I posted the first reply to you, I guess I'm not used to the bar on top yet :-/
[05:02] <lifeless> hmm
[05:02] <lifeless> :(
[05:03] <micahg> the benefit on the bar on the side was that you could see it all the way down the page, my eyes went straight to the description
[05:03] <lifeless> thats worth noting on the bug I think
[05:11] <lifeless> micahg: found it
[05:12] <micahg> lifeless: the solution to your problem?
[05:12] <lifeless> no
[05:12] <lifeless> the utterly insane code.
[05:12] <micahg> ah, cool
[05:12] <lifeless> https://bugs.launchpad.net/ubuntu/+source/ekiga/+bug/791652/comments/2
[05:13] <lifeless> I expect at least an OMFG in about 5 seconds
[05:13] <micahg> lol
[05:14] <ScottK> This bug not found thing.  I've hit it before, but never when I had a chance to investigate at all.
[05:15] <micahg> ScottK: it's a private bug
[05:15] <lifeless> ScottK: security / private bugs
[05:15] <lifeless> ScottK: also bug numbers we don't allocate
[05:15] <lifeless> which happens if a file-a-bug transaction rollsback
[05:15] <ScottK> I see.
[05:15] <ScottK> So maybe mine was something different.
[05:19] <lifeless> anyhoo
[05:19] <lifeless> having found that, I'm off to do something completely different :)
[05:19] <StevenK> ScottK: 403 and 401 both give the idea that something is there, but you can't see it. 404 doesn't.
[05:22] <ScottK> Right.  In the case I had I got bugmail that said I'd been mailed because I was subscribed to a duplicate bug.  Then when I went to the primary bug and clicked on the named dup, I got the 404 reply.
[05:23] <StevenK> Right, that is a bug
[05:23] <lifeless> no
[05:23] <lifeless> its deliberate
[05:23] <ScottK> Ah.  So I'm trapped in bugmail hell forever?
[05:23] <StevenK> We shouldn't say "Duplicate of private bug" ?
[05:24] <lifeless> oh
[05:24] <lifeless> let me rephrase
[05:24] <ScottK> The primary bug wasn't private.
[05:24] <lifeless> the 404 is deliberate
[05:24] <lifeless> the behavior of apport duping bugs onto a private bug is a bug
[05:24] <lifeless> and launchpad permitting that is also a bug
[05:24] <ScottK> Agreed.
[05:24] <ScottK> This wasn't that case.
[05:24] <lifeless> let me get some references
[05:24] <lifeless> well, dups across privacy boundaries are problematic
[05:25] <StevenK> Agreed
[05:25] <lifeless> ScottK: we shouldn't be linkifying those dupes now, and arguably we shouldn't even show them to you if you can't see them
[05:25] <lifeless> we kindof have to when bug A that you can see is a dup of bug B that you cannot see.
[05:25] <ScottK> Right, but I could see the primary and was subscribed to the dupe.
[05:26] <lifeless> ScottK: then you should have been able to see the dupe
[05:26] <ScottK> Agreed.
[05:26] <lifeless> ScottK: so something else happens
[05:26] <ScottK> That's why I think it was a bug.
[05:26] <lifeless> maybe someone unsubscribed you from the dupe between you looking at the master and clicking on the link
[05:26] <ScottK> Possible in theory, but highly unlikely I think.
[05:27] <lifeless> anyhow, bugs in this sort of space - bug 764414 bug 434733 bug 136570 bug 262280
[05:28] <lifeless> I realise these don't match your exact situation
[05:28] <ScottK> I may have to just apply my Rosetta mail policy to bug mail.  I'm getting a bit tired of stuff I can't keep out of my inbox.
[05:28] <lifeless> ScottK: are you in the new bug mail beta ?
[05:28] <ScottK> lifeless: I'm not.
[05:28] <lifeless> ah
[05:29] <lifeless> well it should be live in a few days
[05:29] <ScottK> Does it deal with the case when I'm subscribed to a bug due to a team and I want to make the mail from that bug stop without affecting other team members?
[05:29] <ScottK> That's the one I primarily need.
[05:30] <lifeless> yes
[05:30] <lifeless> you click on 'mute'
[05:30] <StevenK> ScottK: Did you see jml's lightning talk at UDS?
[05:30] <ScottK> I saw about half of it.
[05:31] <StevenK> ScottK: I'd suggest re-watching it, it explains the new bug subscription stuff quite well.
[05:32] <ScottK> Well I think lifeless answered my immediate question.  If it can do that it's at least an 80% solution for me.
[05:34] <broder> hmph. dch changes broke backportpackage. bdrung, i'm blaming you :-P
[05:37] <broder> ah, he fixed it already, my daily builds are just a few days behind. carry on :)
[06:48] <kees> lifeless: gee, that's delightful. upstream silently fixed it in 3.3.0.
[06:54] <lifeless> woo
[06:54] <syn-ack> you the same lifeless from Undernet?
[06:55] <lifeless> many many many years ago I was
[06:55] <syn-ack> Oh, my god.
[06:55] <syn-ack> lifeless, How's it goin' dude?
[06:55] <lifeless> its someone else these days
[06:56] <syn-ack> You're the one I thought you were.
[07:28] <Sensiva> Hello, When will Karmic get moved to old-releases.ubuntu.com ? And where should I ask about that?
[07:58] <didrocks> good morning
[08:13] <hrw> morning
[08:13] <hrw> StevenK: do I assume correctly that you are archive admin today?
[08:13] <StevenK> hrw: I can be.
[08:14] <StevenK> hrw: What do you need?
[08:14] <hrw> StevenK: my package gcc-4.6-armel-cross is in NEW queue. I can answer any questions related to it
[08:14] <hrw> StevenK: lack of it makes whole armel cross toolchain not installable (gcc 4.4/4.5 cross, binutils cross are already in archive)
[08:15] <Sensiva> Does anyone know when will Karmic get moved to old-releases.ubuntu.com ? And where should I ask about that?
[08:21] <StevenK> hrw: Accepted.
[08:22] <hrw> thank you StevenK
[08:39] <bdrung> broder: backportpackage was broken, but the newer dch reveals it. it's fixed in u-d-t trunk
[13:43] <el7r> hi
[16:07] <dantti_> cjwatson: hi, I'm trying to use debconf to display conffile questions in packagekit, but subst() does not allow newlines (so I can show a diff), is there any other command that I can use to set the extended description?
[16:18] <ScottK> dantti_: cjwatson is on holiday this week.
[16:18] <dantti_> ScottK: k, thanks :)
[16:39] <jdstrand> hallyn: hi! I haven't forgotten about libvirt-- though am I right in remembering that you wanted to supply a new package? anyway, I have another question: do you have any scripts for testing qemu-kvm?
[16:40] <hallyn> no i don't.  i (or someone) need to get the kvm autotests going
[16:40] <hallyn> it always gets stalled on not having dedicated hw for it
[16:40] <jdstrand> hallyn: fyi, I came across this: http://wiki.qemu.org/Planning/0.14/Testing
[16:41] <hallyn> jdstrand: i do need to redo the package, just for -v, but nothing major
[16:41] <jdstrand> hallyn: don't bother then, cause I need to add a patch
[16:41] <hallyn> did you get my qa-regession_test patch?
[16:41] <hallyn> ok
[16:42] <jdstrand> hallyn: I like your patch to qrt btw (untested). I think I'd like to make it release specific though
[16:42] <jdstrand> hallyn: I'll handle that too, as I will be fiddling with the script
[16:42] <hallyn> cool thx
[16:59] <nemo> based on what RAOF and astraljava said yesterday, I filed bug #791898 and bug #791900
[16:59] <nemo> oh and bug #791904
[17:00] <nemo> the mouse problem is probably bug #771716, so I just left a comment there.
[17:00] <nemo> it'd be nice to be able to link to all 4 in some sort of laptop database though
[17:00] <nemo> just so others would know what to expect with this model
[17:00] <nemo> hopefully ubuntu has one, someday
[17:05] <dFshadow> anyone know their way around the twitter and facebook APIs?
[17:06] <dFshadow> nvm...found their dev chans on freenode
[17:07] <maco> dapper's eol...time to take it out of the support list
[17:19] <hrw> doko: sent eglibc merge request to fix armhf cross build
[17:19] <hrw> have a nice rest of day people
[17:40] <micahg> hi doko__ , I was wondering if you intended the libreadline5-dev rename to be a full transition to either the new package or libreadline6 depending on licensing or if you just wanted the DM/DD to fix it themselves on demand (in which case we should remove the binary libreadline5-dev so that the Provides in the new package works)
[18:06] <barry> @pilot in
[18:53] <mdz> cjwatson, slangasek, kees, Keybuk, TB meeting shortly
[18:53] <Keybuk> mdz: ack
[18:55] <slangasek> mdz: am I on the agenda today?
[18:55] <mdz> slangasek, no, my mistake, sorry
[18:55] <slangasek> ok :)
[20:51] <smoser> offlineimap recently broek for me in natty (i think this week sometime). I can "fix" it by invoking it with python2.6.
[20:52] <soren> smoser: In Natty? Really? It works fine for me.
[20:52] <soren> smoser: How does it fail?
[20:52] <smoser> i'm guessing somethign recently changed /usr/bin/python -> /usr/bin/python2.7 but it seems like python-defaults is the same in oneiric as in natty
[20:52] <smoser> s/natty/oneiric/ above, soren, sorry.
[20:52] <soren> Ah.
[20:52] <soren> Yeah, python changed.
[20:52] <soren> 2.7.1->2.7.2rc1.
[20:52] <soren> I have a couple of other things that broke that I haven't completely untangled yet.
[20:53] <smoser> so should i open bugs against python?
[20:53] <soren> Depends.
[20:53] <soren> I'd probably start by filing it against offlineimap and go from there.
[20:54] <smoser> well definitely something broke this week, surely that was not expected in a minor release bump
[20:54] <soren> It might be depending on an implementation detail of earlier python versions. That's certainly the case in at least one of the places where I've seen breakage.
[20:54] <smoser> fair.
[20:54] <soren> smoser: Do you have a traceback?
[20:54] <smoser> no.. offlineimap catches them for me :)
[20:55] <smoser> and gives error messages. but its easily recreatable. i've just not dug at all until now.
[20:55] <ScottK> smoser: File a bug and ping barry.
[20:58] <barry> hi smoser.  we'd definitely like to track those problems down asap.  if they are related to upstream 2.7.2 we have about a week to address them before 2.7.2 final (currently scheduled for 11-june)
[20:59] <smoser> nice. i just noticed my apport windows says I "Upgraded to oneiric on 2010-11-15 (198 days ago)"
[20:59] <smoser> barry, bug coming.
[20:59] <soren> barry: I have one for you.
[20:59] <soren> barry: bug 791221
[20:59] <barry> smoser, soren cool.  i'm patch piloting today so it's perfect timing :)  let me finish this upload and i'll take a look
[21:00] <micahg> smoser: that's bug 788936
[21:00] <smoser> wait...
[21:00] <smoser> $  dpkg-query --show python-minimal
[21:00] <smoser> python-minimal	2.7.1-0ubuntu5
[21:01] <soren> What about python2.7?
[21:09] <smoser> barry, bug 792043
[21:10] <barry> smoser: ack
[21:10] <smoser> soren, why did you say '2.7.1->2.7.2rc1.' ?
[21:11] <smoser> my apt-cache policy shows nothing of that sort.
[21:11] <soren> It's lying to you or severely out of date.
[21:11] <soren>  python2.7 | 2.7.2~rc1-2 |       oneiric | source, amd64, i386
[21:16] <smoser> hm...
[21:16] <soren> forget about python-minimal.
[21:17] <smoser> yeah
[21:17] <smoser> $ dpkg-query --show python2.7-minimal
[21:17] <smoser> python2.7-minimal	2.7.2~rc1-2
[21:17] <smoser> where that provides /usr/bin/python2.7
[21:17] <soren> Right.
[21:18] <soren> barry: Would it help if I set up a test system where you could see the failure?
[21:19] <barry> soren: think that would be easier than setting up a vm to test it in?
[21:20] <soren> barry: Not if you can do that easily. It's just a few steps to make it happen.
[21:20] <barry> soren: okay cool.  i can do it fairly easily.  i'll ping you if i run into trouble (finishing up something else here first)
[21:22] <soren> barry: On an oneiric system, do "apt-get build-dep nova; apt-get install bzr ; bzr branch lp:nova ; cd nova ; bash run_test.sh -N" and you should see it happen.
[21:23] <barry> soren: cool.  i have an oneiric vm all set up that should be easy to test on
[21:23] <soren> barry: Wicked. In the mean time I'll see if I can untangle this and come up with a simple test case just for this.
[21:23] <barry> soren: cool
[21:27] <kirkland> is the Oneiric desktop live image working for anyone inside of KVM?
[21:27] <kirkland> hallyn: ^ ?
[21:28] <hallyn> haven't tried
[21:28] <hallyn> trying to figure out why Package.gz doesn't seem to match the contents of pool/main/
[21:28] <hallyn> (presumably i'm misreading the kernel package names/versions)
[21:29] <soren> hallyn: What's the (supposed) discrepancy?
[21:30] <hallyn> linux-image-2.6.39-3-generic_2.6.39-3.10_i386.deb  vs pool/main/l/linux/linux-image-2.6.38-9-generic_2.6.38-9.43_i386.deb
[21:30] <hallyn> i'm sure i'm looking at the wrong thing, somewhere
[21:32] <soren> linux-image-2.6.39-3-generic_2.6.39-3.10_i386.deb is oneiric. pool/main/l/linux/linux-image-2.6.38-9-generic_2.6.38-9.43_i386.deb is natty
[21:32] <hallyn> doh!
[21:32] <hallyn> i forgot about oneiric :)  thanks
[21:32] <barry> soren: this entry in 2.7's Misc/NEWS file looks suspicious.  there's no bug number so i need to track this down to find out exactly what changed:
[21:32] <barry> - Correct lookup of __dir__ on objects. Among other things, this causes errors
[21:32] <barry>   besides AttributeError found on lookup to be propagated.
[21:32] <barry>  
[21:32] <soren> barry: Yep, found that too.
[21:33] <soren> barry: It looks intentional, so I sort of got the impression it was more of a bugfix than anything else.
[21:33] <barry> soren: then, bad python developer!  you didn't include a issue #!
[21:33]  * barry -> #python-dev
[21:33] <hallyn> kirkland: firing off testdrive
[21:34] <kirkland> hallyn: i tried cirrus, vga, and vmware
[21:34] <kirkland> hallyn: cirrus is completely broken
[21:34] <kirkland> hallyn: sorry, ubuntu desktop is completely broken on cirrus
[21:34] <kirkland> hallyn: gets slightly further with std and vmware
[21:34] <kirkland> hallyn: but still not functional
[21:34] <kirkland> hallyn: i suspect its unity 2d issues
[21:34] <micahg> kirkland: unity2d should work with vga
[21:35] <micahg> at least it does in natty
[21:35] <kirkland> micahg: right, i'm talking oneiric
[21:49] <soren> barry: http://paste.ubuntu.com/617043/ reproduces it
[21:50] <ScottK> soren: Is rpc.CnnsumerSet in line 10 a typo?
[21:50] <ScottK> Cnn/Con maybe?
[21:50] <soren> ScottK: Sorry, yes. But that's not the problem :)
[21:51] <soren> Hang on, I have a better test.
[21:51] <ScottK> Sure.  Just wanted to make sure the test case was good.
[21:51] <soren> ScottK: Thanks :)
[21:52] <soren> There:
[21:52] <soren> http://paste.ubuntu.com/617048/
[21:52] <soren> A completely novaless test case.
[21:53] <soren> pymox makes my head spin.
[21:57] <soren> If I add a __dir__ method to the MockAnything class (simply returning an empty list), everything is fine.
[21:57] <soren> barry: ^
[21:58] <soren> barry: Again, I just don't have the expertise to say if pymox is depending on cpython specifics or if this is a bug introduced in Python 2.7.2.
[21:59] <barry> soren: don't worry.  just update the lp bug with what you know and i'll track it down in pythonland
[22:00] <soren> *hugs*
[22:00] <barry> :)
[22:02] <soren> barry: Updated the bug on Launchpad and on Google Code with the test case.
[22:02] <barry> soren: thanks!
[22:02] <soren> barry: Oh, thank *you*!
[23:31] <jdstrand> hallyn: fyi, I am working on a test-qemu.py qrt script. I should have something to check in tomorrow
[23:31] <jdstrand> hallyn: it isn't complete, but is a good start
[23:37] <TheMuso> barry: Are you still piloting?
[23:37] <hallyn> jdstrand: awesome
[23:37] <barry> TheMuso: i'm about to get some dinner, but if there's something easy you need i can help out afterward
[23:37] <TheMuso> barry: No thats fine, I was looking to start my shift, just wanted to make sure we didn't clash.
[23:38] <TheMuso> on items in the queue.
[23:38] <barry> TheMuso: ah, nope, in fact i'll pilot out now
[23:38] <barry> @pilot out
[23:38] <maco> i have something easy if one of you want to sponsor an sru upload
[23:38] <TheMuso> Ok thanks.
[23:38] <TheMuso> @pilot in
[23:38] <TheMuso> maco: I'm on duty now so shute.
[23:38] <TheMuso> shoot even
[23:39] <maco> https://bugs.launchpad.net/ubuntu/+source/lintian/+bug/790960/+attachment/2149841/+files/lintian_2.4.3ubuntu3.debdiff    debdiff for lintian in maverick so debuild -S on maverick for a package-to-be-uploaded-to-oneiric doesn't bomb out on lintian not knowing what the hell oneiric is
[23:39] <TheMuso> maco: Thanks, will look at it now.
[23:40] <maco> thank you
[23:43] <TheMuso> maco: You haven't filled out the paperwork? i.e updated the bug with rationale, possible regression potential etc in the bug for SRU purposes?
[23:43] <micahg> TheMuso: can you ack the packagekit sync?
[23:43] <TheMuso> I don't doubt that the change is small and minor, but I'd say the upload will be rejected without that info.
[23:43] <TheMuso> micahg: Next in line.
[23:43] <micahg> TheMuso: thanks
[23:44] <TheMuso> maco: And the version should probably be ubuntu2.1 as well/
[23:45] <maco> TheMuso: the lintians in natty & oneiric are a different upstream version, so it cant clash with anything anyway
[23:45] <maco> (filled in the SRU points now too)
[23:45] <TheMuso> maco: Fair enough re version.
[23:46] <TheMuso> maco: Ok looks good to me, will test build and upload if all looks good.
[23:46] <maco> k thanks
[23:46] <micahg> TheMuso: maco; that version is already in the archive, please use 2.1
[23:47] <maco> micahg: it is? rmadison says 2.4.3 is only in maverick
[23:47] <micahg> maco: https://launchpad.net/ubuntu/+source/lintian/2.4.3ubuntu3
[23:47] <maco> well and lucid backports with ~lucid1
[23:47] <micahg> maco: it's not just what's in there currently, but everything
[23:48] <TheMuso> micahg: Good catch, I was about to check that myself but you beat me.
[23:48] <maco> doh. ok.
[23:48] <TheMuso> maco: Nvm will change locally.
[23:48] <maco> TheMuso: want me to re-gen, or want to just change it?
[23:48] <maco> ok
[23:48] <TheMuso> Don't worry about another diff.
[23:48] <maco> that was already the second diff. first one didnt have "-proposed"  .... and this is why im not a core-dev
[23:49] <TheMuso> Whenever I deal with SRUs, I stic to a hard and fast .1 version rule, usually safest.
[23:50] <maco> this either means i need to do more SRUs (for practice) or fewer SRUs (so i mess up less) :P
[23:51] <TheMuso> maco: Uploaded, thanks for your work.
[23:51] <maco> thanks luke
[23:52] <TheMuso> micahg: Is the packagekit sync in the sponsors queue? If so, I'll dig it out from there.
[23:52] <TheMuso> seems so
[23:52] <TheMuso> i.e packagekit sync in queue./
[23:52] <micahg> TheMuso: yeah, I did a test build and verified the changes, but am not core-dev
[23:53] <TheMuso> micahg: np wilp verify myself to be sure.
[23:53] <TheMuso> will
[23:53] <micahg> TheMuso: of course :)
[23:54] <slangasek> TheMuso, maco: the security team has some guidance on SRU versioning, linked from the SRU wiki page: https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Update%20the%20packaging
[23:55] <TheMuso> micahg: Just noticed something in the debian changelog for packagekit, something to do with depending on xulrunner or firefox. Is that likely to break anything for us if we take that wholesale?
[23:56] <micahg> TheMuso: it should be an alternate depends (which is needed for the browser plugin) (xulrunner-dev | firefox-dev)
[23:56] <TheMuso> Ok will check that once test built.
[23:56] <micahg> it works since only firefox-dev is in main
[23:57] <micahg> although, now that I think about it, I think that invalidates my test :-/