[00:09] <ohsix> down the broken extension rabbithole again; i hope they eventually sort that stuff out :[
[00:13] <micahg> ohsix: any non-binary extensions should be updating from addons.mozilla.org (not all extensions in the archive have been updated yet, that will be staged next week in -proposed), but there shouldn't be many at all left in the archive
[00:14] <ohsix> yar i meant a.m.o; extension authors haven't really even caught up with 4 yet; and if they have they didn't also add 5 like they were supposed to at the time, so there will be more adjustment
[00:14] <ohsix> i just hope eventually it all catches up; not having tabkit and bartab is giving me fits
[00:15] <micahg> ohsix: the compatibility rate is ~76% ATM
[00:15] <ohsix> ya i read it's pretty good
[00:15] <ohsix> but it's a big bummer when it's not the ones you use :D
[00:15] <micahg> extension authors will probably move to the technologies which are less likely to break over time
[00:15] <ohsix> nod
[00:16] <ohsix> i've read about all the developer changes since 3.5 and why they were made and whatnot
[00:16] <ohsix> wouldn't need tabkit if there was ui for the new delayed browser tab loading :]
[00:17] <ohsix> you can pretty much see the situation in the last update dates https://addons.mozilla.org/en-us/firefox/addon/tab-kit/ https://addons.mozilla.org/en-US/firefox/addon/bartab/
[00:41] <[lan3y]> Hi i have a question about a feature on the brainstorm do i ask here?
[10:16] <bdrung_> mdeslaur: should i take a look at the vlc security fix later this day or are someone else working on it?
[11:54] <cjwatson> directhex: mono 2.10.1-4 binaries accepted through NEW; I punted all the new binaries into main for now, but expect to drop some of them back out to universe depending on what component-mismatches tells me
[11:56] <cjwatson> doko__: libffi6-udeb accepted now, thanks
[12:11] <mdeslaur> bdrung_: I haven't had time to look at it yet, sorry. I think this is the fix: http://repo.or.cz/w/vlc.git/commitdiff/cd929923ff49175a501bb3e9553a683bc42ff61c
[12:41] <asac> anyone else has problems with ubuntu SSO? seems it doesnt like my pass anymore :/
[13:35] <doko__> slangasek: the debian cmake sync did break the build on armel
[13:58] <directhex> cjwatson: thanks. i'm still chasing the armel build failure, personally. i'll alert people to start transition management
[16:46] <ImDexter> hi
[16:47] <ImDexter> it seems there is not any option to allow users to estabkish as a default the opening of plugged in external HD in a new tab, instead of a new window, as is the current action permorfed. are you developing a tool or option that would enable users to, everytim an user opens his home folder to see several predetermined tabs?
[16:48] <ImDexter> and, of course, to choose to open ny plugged in external HD in a new tab, instead of window
[16:48] <ImDexter> any
[20:38] <bdrung_> mdeslaur: bug #795410
[21:44] <broder> i'm trying to get the most recent version of a package in a given suite of the debian archive. is rmadison the best tool i get?
[21:45] <cjwatson> that or the source package publishing history tables in LP
[21:45] <cjwatson> oh, you said Debian
[21:45] <cjwatson> well, you could still use the LP import I suppose :-)  I can't remember if the dak db is exported to non-DDs
[21:46] <broder> it's seemed in the past that the LP's import of history tends to have gaps
[21:46] <broder> although maybe information about tip is consistently current?
[21:47] <cjwatson> it's usually not too far off
[21:48] <cjwatson> you could also just grab and parse Packages/Sources files
[21:48] <cjwatson> that's essentially what rmadison is doing, remotely
[21:48] <broder> actually, i guess i could just use rmadison for everything
[21:52] <cjwatson> broder: it's not ideal for machine-parsing, but not dreadful
[21:53] <broder> cjwatson: i just realized that u-d-t actually has a helper function that does the parsing for me :)
[21:53] <cjwatson> hah
[22:36] <broder> bdrung: ping? right now backportpackage lets you specify --version without --source, in which case it searches the entire publishing history for all releases to find a given version of the package
[22:37] <broder> this is annoying to implement consistently with the debian support, and i think it's something of a mis-feature to grab a non-current version anyway
[22:37] <broder> are you strongly opposed to punting that, and making --version purely for verifying that the package you get is a specific version?
[22:40] <bdrung_> broder: no, because if you upload a new version you can backport it with specifying the version, but not specifying the version would backport the previous one
[22:40] <bdrung_> if you fix this lag, you can make the change :)
[22:41] <broder> i don't understand...
[22:42] <bdrung_> broder: there is a delay between the upload and the recognition of pull-lp-source
[22:43] <bdrung_> s/upload/an upload to the main archive/
[22:43] <broder> what about between the upload and rmadison? i'm using rmadison for looking up all version numbers now
[22:43] <broder> (i don't know what sorts of delays it exhibits)
[22:43] <bdrung_> broder: it takes some time for the information to hit rmadison
[22:44] <bdrung_> it takes minutes or hours
[22:44] <broder> :(
[22:44]  * broder sighs
[22:44] <bdrung_> it takes too much time if you want to do a backport directly atfer an upload
[22:44] <broder> ok, i'll go work something out
[22:45] <bdrung_> that's when i need to specify the version
[22:45] <broder> why not just backport from the dsc file you have locally in that case?
[22:45] <bdrung_> would be possible in most cases. sometimes someone else is doing a team upload.
[22:46] <broder> and if you specified the version, you'd be able to pull it out of the lp publishing history?
[22:47] <bdrung_> specifying the version works, but i don't know if the lp publishing history is used for it.
[22:47]  * broder goes to see which particular rabbit hole in the current code you go down when you specify a version
[22:48] <bdrung_> broder: in doubt ask tumbleweed
[22:49] <broder> ah, i see. it doesn't hit the lp publishing history at all in that case, and just assumes that https://launchpad.net/ubuntu/+archive/primary/+files/package_version.dsc exists
[22:49] <broder> i can make that work
[22:55] <broder> yeah, got it...i think. merge proposal will be inbound as soon as i update the manpage
[23:09] <bdrung_> broder: i plan to split distro_info into a separate library
[23:09] <bdrung_> broder: your merge proposal makes that harder
[23:10] <broder> the stuff i added could conceivably live in ubuntutools.misc instead
[23:13] <broder> let me push an update with it moved there
[23:14] <bdrung_> broder: you may want to add a "exists" method to the distro_info class
[23:15] <broder> instead of doing "in .all"?
[23:15] <bdrung_> yes
[23:16] <bdrung_> the question is what to do with "unstable"?
[23:16] <broder> hmm...do we not handle that correctly?
[23:16] <bdrung_> .all will give you only the codename
[23:17] <broder> but distro_info knows about unstable?
[23:18] <bdrung_> it maps unstable to sid
[23:23] <broder> hmm...it looks like i might need to check both .all and .codename()
[23:27] <bdrung_> i think a valid(codename) check would be the solution.
[23:28] <broder> ok, that seems reasonable
[23:29] <broder> would you be willing to make that change, though? i've got some other backlogged stuff i want to get to
[23:29] <bdrung_> yes, i can do that
[23:29] <bdrung_> but first i go to bed :)
[23:29] <broder> heh
[23:55] <slangasek> doko: hmm.  I don't know why (cmake on armel); the same thing succeeded in Debian