[04:54] <hallyn> mdeslaur: but development release is not available there.  ok to complicate that logic with a special case?
[04:55] <hallyn> slangasek: originally he thought it was a race condition, but he has deeper issues
[05:54] <pitti> Good morning
[06:00] <pitti> slangasek: I don't know about urfkill, I'm afraid; but I'm surprised that we need it, I thought network-manager would already handle these
[06:00] <pitti> slangasek: but I guess it can be changed to be inert when n-m is running, similar to e. g. the powerbutton script of acpi-support?
[06:02] <slangasek> pitti: eh, network-manager is entirely the wrong layer to handle these keys
[06:02] <slangasek> because they are intended to control all antennas, not just wifi
[06:03] <slangasek> n-m is not what handles the thinkpad antenna key at all, for instance; acpi-support does that currently
[06:04] <pitti> slangasek: ah, I see; so that's generally the Fn+Something soft switch?
[06:04] <slangasek> yep
[06:05] <pitti> I certainly remember quite a lot of bug reports which say that the key is not working on a particular model
[06:05] <pitti> usually in udev bugs which send the wrong key code, but even when fixing it it doesn't seem to work sometimes
[06:05] <pitti> so maybe urfkill will work better with those than acpi-support
[06:06] <slangasek> yes, because acpi-support only handles acpi events, not keys
[06:06] <pitti> that would certainly explain it
[06:07] <pitti> could we move the config files to /lib/ or /usr/share somewhere?
[06:07] <slangasek> if you wish? :)
[06:08] <pitti> slangasek: as you were concerned that they aren't really conffiles
[06:08] <slangasek> I was mostly concerned about it being a possible sign that the code wasn't mature enough to DTRT
[06:09] <slangasek> but then I found the per-vendor files which showed that to not be an issue
[06:09] <slangasek> so I'm not worried about moving them, but I think it would be legitimate to do so
[06:12] <pitti> installed the package now; the two per-vendor conffiles look rather harmless
[07:12] <TheMuso> doko_: Ok I just confirmed that java-atk-wrapper can be used as a drop-in replacement for java-access-bridge. I have a local copy of the openjdk-6 packaging branch with the needed changes, shall I push and upload, or would you like to have a look first? (Note I have also merged your most recent upload).
[07:32] <pitti> TheMuso: we also need it for openjdk-7, right?
[07:38] <rickspencer3> hey all ... daily images today looking good:
[07:38] <rickspencer3> https://jenkins.qa.ubuntu.com/view/Precise%20ISO%20Testing%20Dashboard/view/Daily/?
[07:41]  * SpamapS looks on in awe of the awe-tomation awesomeness
[07:53] <pitti> libo i386 built yesterday, so today's images should be a little less oversized, too
[07:54] <dholbach> good morning
[07:54] <pitti> hey dholbach
[07:54] <nigelb> Hey dholbach, pitti :)
[07:55] <dholbach> hey pitti
[07:55] <pitti> nigelb: good morning
[07:55] <dholbach> hey nigelb :)
[07:56] <TheMuso> pitti: Oh yeah, we do.
[07:57] <TheMuso> pitti: Although that is in universe.
[07:57] <pitti> TheMuso: ah, I wasn't sure whether we'll use that by default in precise eventually
[09:09] <pitti> @pilot in
[09:10] <pitti> argh, 72 items? seems we never quite get down to a sane number..
[09:27] <seb128> pitti, that's 3 weeks of no piloting and a rally for you ;-)
[09:28] <seb128> pitti, there was no piloting scheduled between mid-decembre and the rally
[09:28] <bkerensa> pitti: I found out what was causing the conflicts in my requested merge for snort can I just re-request? Please :)
[09:28]  * bkerensa also forwarded upstream
[09:33] <pitti> bkerensa: as you prefer, but updateing the debdiff on the bug might be easier
[09:36] <cjwatson> pitti: I was curious over the weekend if there was a particular reason there aren't python3-problem-report and python3-apport packages yet, despite the apport tests passing with Python 3
[09:37] <pitti> cjwatson: I actually fixed quite a lot of the apport.* modules, but problem_report is particularly broken with python 3 stil
[09:37] <cjwatson> ah
[09:37] <cjwatson> the tests didn't seem to show that?
[09:38] <cjwatson> maybe I missed something
[09:38] <pitti> I need to make up my mind what makes more sense to store in Report objects: always byte arrays (more flexible, but doens't work well with real strings), always utf8 (need to be more careful with logs, etc.), or mix (too confusing)
[09:38] <pitti> python3 problem_report.py -v
[09:38] <cjwatson> (hmm, also https://blueprints.launchpad.net/ubuntu/+spec/foundations-p-python-versions seems to say that apport's in update-manager's dependency chain but I don't see it there)
[09:38] <pitti> fails all over the place
[09:39] <cjwatson> ah, ye
[09:39] <cjwatson> s
[09:39] <pitti> you can run the whole suite with PYTHON=python3 test/run, FYI
[09:39] <cjwatson> I thought I did, must have missed that
[09:39] <pitti> cjwatson: I think I can make the whole thing work for python 3, but I didn't put urgency into this as we are missing python3-launchpadlib
[09:39] <cjwatson> oh, I just ran python3 test/python, that was why
[09:39] <cjwatson> pitti: yeah, barry and I are working on that
[09:42] <pitti> I think I fixed pretty much all the imports etc., the remaining bits are all str vs. bytearray problems
[09:45] <l3on> pitti, agda needs a rebuild too
[09:45] <l3on> :)
[09:45] <l3on> Package: agda-mode
[09:45] <l3on> Version: 2.2.10-4build1
[09:45] <l3on> Missing: libghc-agda-dev (< 2.2.10-4build1.1~)
[09:45] <\sh> could it be that something broke libreoffice? eventually the last openjdk upload?
[09:46] <l3on> after rebuild libghc-agda-dev (<< 2.3.0-1build2.1~)
[09:50] <pitti> hey l3on
[09:50] <pitti> l3on: ah, can do
[09:50] <l3on> thanks :)
[09:50] <pitti> l3on: for https://code.launchpad.net/~l3on/ubuntu/precise/anjuta-extras/fix-unmetdep/+merge/89639, did you check that anjuta-extras actually works with anjuta 3.3?
[09:51] <pitti> l3on: agda uploaded
[09:52] <bkerensa> pitti: Hopefully my merge request is much more satisfactory this time
[09:52] <pitti> bkerensa: not on the sponsoring page yet, could you please toss me the URL?
[09:53] <bkerensa> pitti: https://code.launchpad.net/~bkerensa/ubuntu/precise/snort/fix-for-889721/+merge/89643
[09:54] <pitti> bkerensa: ah, thanks
[09:56] <pitti> bkerensa: FYI, fixing the changelog syntax
[09:56] <pitti> it's (LP: #889721)
[09:56] <bkerensa> oh ok
[09:59] <bkerensa> pitti: I pushed a fix for changelog syntax
[09:59] <pitti> bkerensa: nevermind, did that while merging
[09:59] <bkerensa> oh
[10:00] <bkerensa> pitti: Thanks for the merge gnight!
[10:03] <Laibsch> bdrung: thank you for letting me know about distro-info.  Hehe.  And Stefano and you are even the maintainer.  What a coincidence.  Let's hope packages like ubuntu-dev-tools and especially pbuilder as well as others are patched in time for precise to rely on that info instead of hard-coding it.
[10:03] <pitti> l3on: did you see my anjuta-extras question?
[10:04] <Laibsch> looks like ubuntu-dev-tools already depends on distro-info.  Very well indeed.
[10:04] <l3on> pitti, yep :)
[10:04] <l3on> just a moment ... i need my precise and I don't find ti
[10:04] <Laibsch> pbuilder doesn't
[10:06] <l3on> pitti, in the while.. can you take a look at ruby-sinatra ?
[10:06] <pitti> l3on: yep, getting to this
[10:15] <l3on> pitti, ok, anjuta-extras does not work... but, in the homepage there is a mistake...
[10:16] <l3on> we have anjuta 3.3.4, that's the unstable version, and for -extras there's a unstable version too
[10:16] <pitti> yeah, I noticed -- there is no corresponding extras upstream version
[10:16] <l3on> but in the anjuta homepage does not appera
[10:16] <l3on> http://ftp.acc.umu.se/pub/GNOME/sources/anjuta-extras/3.3/
[10:16] <pitti> oh, there is? nice
[10:16] <pitti> this should be packaged then
[10:16] <l3on> ok, I'm working on it
[10:16] <pitti> cheers
[10:17] <l3on> :)
[10:17] <pitti> l3on: the sinatra branches are both uploaded
[10:17] <l3on> thanks again :)
[10:17]  * pitti goes to the other MPs
[10:33] <doko> TheMuso, thanks! see message
[10:35] <gammax> Hello all, Is there anyone that may be able to help create a notification icon? It is very basic.
[10:44] <cjwatson> barry: FYI it looks like you need to write an MIR for python3-chardet
[10:45] <cjwatson> (it's a separate source, so more effort than usual)
[10:51] <diwic> no queue on launchpad today \o/
[11:03] <jibel> pitti, yesterday the retracer behaved oddly and marked crashes in software-center in Precise as duplicates of an old bug (bug 440889)
[11:03] <jibel> pitti, the only common error is they are both an ImportError in software-center
[11:04] <jibel> see the original description because the main description has been updated to match the new error.
[11:09] <pitti> jibel: indeed, so it seems this bug has regressed
[11:09] <pitti> but it seems recent comments indicate that it is fixed again now?
[11:10] <jibel> pitti, no, the original error was an import in webkit but the recent error was with bsddb in python2.7
[11:10] <jibel> pitti, the point is that trhe 2 bugs are different but the retracer marked them as dupes.
[11:12] <pitti> /usr/share/software-center/software-center:ImportError:<module>:<module>:<module>:<module>:<module>:<module>|440889||2009-10-02 20:40:05
[11:12] <pitti> ah, that's indeed not very helpful
[11:14] <pitti> jibel: filed as bug 920403, thanks for pointing out!
[11:24] <glatzor> barry, hello. I just wanted to inform you that I ported aptdaemon to gobject introspection.
[12:06] <l3on> pitti, if you're still free, anjuta extras - merge proposed uploaded :)
[12:06] <l3on> https://code.launchpad.net/~l3on/ubuntu/precise/anjuta-extras/new-version-3.3.4/+merge/89672
[12:07] <pitti> l3on: nice, thanks! will do ASAP
[12:07] <l3on> ok, thanks.
[12:07] <pitti> l3on: ah, so you closed the other MP?
[12:08] <l3on> pitti, yes, I don't know how uncommit that branch...
[12:08] <pitti> that's fine; you can just delete it, or leave it to bitrot
[12:08] <l3on> so I choose to remove that and create a new one
[12:43] <mdeslaur> hallyn: yeah, I just need to think of a way to automatically determine which release is a dev release...let me ponder it a while
[12:47] <Daviey> mdeslaur: the launchpad api tells you that.
[12:51] <mdeslaur> Daviey: yeah, that'll have to wait until I rewrite the whole thing in python though :P
[12:59] <Daviey> mdeslaur: perhaps asking someone closer to the API, but i imagine something based on, https://api.launchpad.net/1.0/ubuntu/current_series/ might help ?
[13:00] <mdeslaur> Daviey: yes, thanks
[13:07] <cjwatson> or distro-info
[13:07] <cjwatson> though that runs too fast to be talking to the API :-)
[13:08] <cjwatson> you can just about fit the API call into a one-liner:
[13:09] <cjwatson> $ python -c 'from launchpadlib.launchpad import Launchpad; lp = Launchpad.login_with("check-series", "production"); print(lp.distributions["ubuntu"].current_series.name)'
[13:09] <cjwatson> precise
[13:11] <tumbleweed> if it's not python, distro-info is probably easier
[13:11] <tumbleweed> we'll have to be keeping thata data up to date via SRU for other packages
[14:23] <bdrung> Laibsch: you're welcome. :) distro-info is already a year old (initially lived in ubuntu-dev-tools)
[14:24] <valterstr> so... I was interested in developing for ubuntu.
[14:24] <valterstr> anyone could give me some pointers where to start?
[14:24] <valterstr> I have programming skills, but I wouldn't call myself very advanced
[14:25] <tumbleweed> valterstr: what sort of things do you want to work on?
[14:25] <valterstr> well, what is there? :?
[14:25] <valterstr> core development, packages. more?
[14:27] <valterstr> tumbleweed: what is there?
[14:28] <tumbleweed> valterstr: https://wiki.ubuntu.com/MOTU/GettingStarted comes to mind, but it's less than perfect
[14:28] <valterstr> I have seen it...
[14:28] <valterstr> but it doesn't really explain much.
[14:29] <valterstr> it gives guidelines
[14:29] <tumbleweed> you can work upstream, on packages that Ubuntu packages. You can fix bugs on things in Ubuntu, write patches for bugs in our bugtracker, test proposed fixes, clean things up, write developement utilities, etc. Really, anything you want to...
[14:29] <tumbleweed> #ubuntu-motu for this, maybe?
[14:29] <valterstr> will check there then.
[14:29] <valterstr> thanks.
[14:49] <seb128> zul, hi
[14:49] <seb128> zul, could you look at bug #911888?
[14:49] <zul> seb128: yeah ill have a look today
[14:50] <seb128> zul, we keep getting duplicates, basically adding smb printers and browsing smb shares is broken in precise for some weeks
[14:50] <seb128> zul, thanks
[14:50]  * smb knew he was broken
[14:51] <seb128> smb, unfortunate name conflict :p
[14:51] <smb> hehe
[14:52] <zul> seb128: its supposedly fixed in 3.6.2 so ill backport the patch today
[14:52] <seb128> zul, excellent, thank you
[14:59] <barry> cjwatson: another alternative would be to remove the chardet requirement for feedparser.  upstream test suite fails when chardet is installed, and upstream has essentially deprecated its use in feedparser.  so i think i should just remove python3-chardet as a *dep.  thoughts?
[15:22] <bdrung> tumbleweed: what do you think about http://paste.ubuntu.com/814370/ ?
[15:24] <tumbleweed> bdrung: I guess that works. Bit of an odd interface, but simple enough
[15:25] <bdrung> tumbleweed: or do you prefer a string parameter?
[15:26] <tumbleweed> yes, that'd be a nicer interface
[15:34]  * dholbach hugs pitti
[15:34] <bdrung> micahg: re bug #909570, can you give me a testcase for that bug?
[15:39] <micahg> bdrung: lp:firefox
[16:04] <micahg> cjwatson: about the puppet backport, natty got the right version, but maverick and lucid only got a backport from the release pocket and not updates
[16:13]  * pitti hugs dholbach back
[16:45] <bdrung> tumbleweed: better: http://paste.ubuntu.com/814434/ ?
[16:47] <tumbleweed> bdrung: yeah
[16:47] <bdrung> tumbleweed: suggestions for the FIXME?
[16:47] <tumbleweed> raise ValueError ?
[16:50] <cjwatson> barry: python-debian is going to want python3-chardet anyway
[16:51] <cjwatson> micahg: oh, bah, sorry about that
[16:52] <barry> cjwatson: okay.  i just uploaded a new feedparser without the deps on py3-chardet, but i'll review/file the MIR for it anyway
[16:52] <cjwatson> barry: ok - if it's just -debian then I guess you can make it my problem if you want :)
[16:52] <cjwatson> waiting for an upstream review there
[16:53] <barry> cjwatson: let's say, if you get to it first, i won't complain :)
[16:53] <cjwatson> micahg: can you reopen the relevant two tasks for me, please?  I can't
[16:54] <micahg> cjwatson: done, thanks
[17:03] <l3on> someone can rebuild python-pysqlite1.1?
[17:03] <l3on> there is an unmetdep here:
[17:03] <l3on> Package: python-pysqlite1.1-dbg
[17:03] <l3on> Version: 1.1.8a-3ubuntu2
[17:03] <l3on> Missing: python-pysqlite1.1 (= 1.1.8a-3ubuntu2
[17:05] <cjwatson> micahg: should be all fixed now.
[17:06] <micahg> cjwatson: looks good, thanks
[17:06] <tumbleweed> l3on: it looks like that was supposed to have been deleted, but i tcame back in oneiric
[17:06] <cjwatson> l3on: err, that's kind of odd ...
[17:07] <cjwatson> tumbleweed: I don't see a deletion in the publishing histsory
[17:07] <cjwatson> *history
[17:07] <cjwatson> oh, yes I do
[17:07] <tumbleweed> cjwatson: https://launchpad.net/ubuntu/+source/python-pysqlite1.1/+publishinghistory deleted in natty
[17:07] <cjwatson> the phrase "WTF" comes to mind
[17:07] <tumbleweed> indeed
[17:07] <cjwatson> maybe we should just delete it again
[17:08]  * tumbleweed hands cjwatson a garlic stake
[17:08] <cjwatson> its only reverse dependencies have alternatives
[17:10] <cjwatson> I've removed it and with any luck it will stay dead this time
[17:11] <mneptok> if zombie movies are any indication, you have to remove HEAD
[17:33] <GridCube> hello, im having a few problems, im trying to use the ubuntu-bug to report a few bugs im finding on today's xubuntu image, the problem is that im behind a proxy, so ubuntu-bug is refusing to work, i tried setting html_proxy on a terminal and launching it from there, but with no luck
[17:34] <GridCube> the html_proxy does work because i just zsynced the image a few minutes ago
[17:37] <pitti> micahg: should we look into releasing firefox tomorrow (my) morning (i. e. in about 12 hours)?
[17:39] <cjwatson> GridCube: there is no such environment variable as html_proxy
[17:39] <cjwatson> (as I told you on -release)
[17:39] <cjwatson> it's http_proxy
[17:39] <GridCube> sorry yes
[17:40] <GridCube> thats the one i used i was just writing from memory now
[17:40] <cjwatson> and #ubuntu-devel still isn't the right place to ask, as micahg said on -release
[17:40] <GridCube> i know
[17:40] <GridCube> :P i already asked on -bugs
[17:42] <cjwatson> if you ask on several different channels in parallel, you should expect parallel responses ... ;-)
[17:42] <GridCube> :P indeed
[17:50] <mpt> kirkland, hi, I'd like to talk with you about privacy and encryption settings if you have time
[18:04] <kirkland> mpt: please
[18:04] <kirkland> mpt: sure, shoot
[18:04] <kirkland> mpt: irc or voice?
[18:04] <mpt> kirkland, arg, I need to go now, sorry ... What time will you be around tomorrow?
[18:05] <kirkland> mpt: I'm UTC-6 right now
[18:05] <kirkland> mpt: most of that work day
[18:05] <kirkland> mpt: it's noon here right now
[18:06] <mpt> kirkland, ok, see you in 21-ish hours :-)
[18:19] <bdrung> tumbleweed: pushed distro-info. can you have a look at it? i want to upload it.
[19:11] <SpamapS> Ugh.. really not a fan of the new bug listing design
[19:12] <ScottK> Oh.  My.
[19:40] <cjwatson> scott-work: http://cdimage.ubuntu.com/ubuntustudio/dvd/current/ merry Christmas
[19:40] <cjwatson> the text is a bit wrong I guess
[19:42] <cjwatson> I might leave it that way for now but feel free to file suggestions for HTML changes as bugs on the ubuntu-cdimage project
[19:44] <cjwatson> hmm, suspiciously short build though!
[19:44] <cjwatson> scott-work: ok, sorry, this is busted, I'll try again
[19:48] <cjwatson> next build should be happier
[20:17] <SpamapS> hrm.. still stuff lingering for libmysqlclient16
[20:19] <micahg> looks only like 3 or 4 thinsg
[20:19] <micahg> can give you a pastebin if you like
[20:30] <tumbleweed> bdrung: lgtm
[20:47] <cjwatson> micahg: re puppet, I've also now fixed backport-helper.py so that the same mistake shouldn't happen again
[20:48] <micahg> cjwatson: thanks
[21:04] <stgraber> mdz, pitti: TB meeting?
[21:15]  * cjwatson grins at a Debian removal bug
[21:15] <cjwatson> "Also, there seem to be 4 installations, 3 of which are mine."
[21:26] <Daviey> cjwatson: the 4th is probably piuparts.debian.org :)
[21:28] <jono> has Empathy been removed from the disc?
[21:28] <scott-work> cjwatson: lol
[21:28] <jono> I just noticed in my new install that it is not installed
[21:28] <scott-work> cjwatson: but i can defintely tell you that i truly appreciate your efforts on this :)
[21:29] <l3on> Hey guys... I have 4 packages that need a rebuild... since I don't have upload rights, someone can do that for me ?
[21:30] <micahg> l3on: sure, which ones and why?
[21:30] <l3on> micahg, well:
[21:30] <l3on> This three: haskell-test-framework-hunit haskell-test-framework-quickcheck2 haskell-test-framework-th
[21:30] <SpamapS> why does haskell get rebuilt every 3 weeks? ;)
[21:31] <micahg> ABI changes per upload
[21:31] <l3on> are against: haskell-test-framework
[21:31] <l3on> this: haskell-clientsession against haskell-skein
[21:32] <l3on> thanks micahg :)
[21:32] <jbicha> jono: I just did a new install of precise this morning and empathy is definitely installed, maybe you did a dist-upgrade that removed it?
[21:32] <jono> jbicha, hmmm odd
[21:32] <jono> thanks jbicha
[21:34] <l3on> micahg, here the motivation → http://paste.ubuntu.com/814739/
[21:35] <micahg> l3on: yeah, makes sense
[21:37] <cjwatson> l3on: fyi, although haskell is a known standard case where we need rebuilds, in general you cannot assume that unmet dependencies will be magically fixed by a rebuild
[21:37] <cjwatson> I've noticed you asking for that as a sort of reflex for unmet deps - you do need to check that rebuilding will actually help
[21:38] <l3on> I rebuild http://debomatic.debian.net/precise/pool/haskell-test-framework-th_0.2.2-3build1/
[21:39] <l3on> but, onestly, I dind't check the other :/
[21:39] <l3on> *others
[21:40] <cjwatson> haskell needs to be rebuilt in dependency order - otherwise you may end up having to rebuild multiple times
[21:40] <cjwatson> use http://people.canonical.com/~ubuntu-archive/transitions/ghc.html
[21:41] <cjwatson> likewise with ocaml
[21:42] <l3on> well.... and is that link public ?
[21:42] <TheMuso> doko: https://bugs.launchpad.net/ubuntu/+source/at-spi/+bug/790240/+attachment/2689627/+files/openjdk-use-atk-wrapper.diff are my changes for openjdk-6.
[21:42] <l3on> no, because it's the first time I ever seen that ...
[21:42] <cjwatson> l3on: yes
[21:43] <cjwatson> I mean yes it is public
[21:43] <l3on> there is some wiki page that I have not read yet ?
[21:43] <cjwatson> I can hardly answer that reasonably
[21:43] <infinity> I suspect there are several?
[21:44] <l3on> can you give me a wikipage that links to that html ?
[21:44] <cjwatson> https://lists.ubuntu.com/archives/ubuntu-devel/2011-May/033270.html
[21:44] <cjwatson> no idea if it is on the wiki
[21:44] <cjwatson> but it's a wiki, you can edit it :)
[21:46] <cjwatson> https://wiki.ubuntu.com/OneiricOcelot/TechnicalOverview/Alpha1 and https://wiki.ubuntu.com/PlusOneMaintenanceTeam/Specs/Infrastructure link to it, although neither is particularly documentation; but you specified wiki pages. :-)
[21:46] <l3on> It's absolutely not clear for a new contributor all these things... there's an well known lack in devel-doc that scares me ... :/
[21:47] <l3on> beh... let's go to read :) thank cjwatson
[21:47] <YokoZar> Which debhelper program might be responsible for deleting a .so file in a package directory?
[21:48]  * SpamapS starts a discussion about bug #871907
[21:48] <infinity> SpamapS: Agreed, ship it.
[21:49] <infinity> SpamapS: (Obviously, the correct answer here is "why the heck isn't vim detecting the current terminal palette and adjusting sanely?"
[21:49] <infinity> )
[21:49] <infinity> SpamapS: But people who use white terminals are Wrong(tm) anyway.
[21:51]  * SpamapS raises infinity a few ticks on the list of people who get to come on the space ship this December
[21:52] <SpamapS> infinity: indeed, "terminal" isn't enough, we need a new bit to the emulation spec which is "normal" or "eye burning"
[21:54] <cjwatson> l3on: I don't think it would be reasonable for most new contributors to need to know about the transition tracker; it's a fairly advanced archive management tool
[21:54] <cjwatson> maybe s/advanced/specialised/
[21:57] <micahg> l3on: I did the ones for haskell-test-framework, the haskell-clientsession one requires a few extra rebuilds on top of this and I'm not going to do that right now, are you blocked on this for something or are you just trying to fix stuff?
[21:57] <l3on> micahg, fixing unmetdep in precise...
[22:01] <micahg> ok, so, it's 7 rebuilds total and they have to be in the right order
[22:02] <micahg> maybe I look later this week unless someone else grabs it first
[22:02] <micahg> actually, it's 8 (forgot about the first one )
[22:03] <infinity> SpamapS: Is there no way for vim to determine its current bgcolor?
[22:03] <infinity> SpamapS: I would have thought that it would know what it inherited from its parent.
[22:16] <stgraber> cjwatson: if you have a sec, the TB meeting minutes are waiting in ubuntu-devel-announce
[22:19] <cjwatson> stgraber: accepted
[22:20] <stgraber> cjwatson: thanks
[22:21] <RAOF> We're almost ready to perform the Xserver transition, so I now need to know how to/who to do the source+binary copy from the staging PPA.
[22:52] <RAOF> cjwatson: If you're not too busy/asleep, I suspect that you know how I can go about binary-copying from the X staging PPA into precise. :)
[22:53] <cjwatson> yep.  needs an archive admin.  I can do it - can you give me full details?
[22:53] <cjwatson> oh, wait, you ARE an archive admin
[22:53] <YokoZar> If package foo version 1 provides i386 and amd64 versions, and package foo version 2 in precise only provides i386 versions (that install fine via multiarch), what happens at upgrade time?
[22:54] <RAOF> cjwatson: Only for purposes of SRU-teamage.
[22:54] <YokoZar> IE, do we have to special case each multiarch transition from packages that used to use ia32-libs?
[22:54] <cjwatson> I think it wants an adaptation of https://wiki.ubuntu.com/ArchiveAdministration#Publishing_packages_from_the_ubuntu-mozilla-security_public_PPA
[22:54] <Laney> does copyPackage(s) + include_binaries=True not work for anyone? does it work at all?
[22:55] <cjwatson> Laney: wgrant seems to think it's busted, and I've seen some corroboration of that, so I intend to avoid it until I have time to write a unit test that shows up the problem
[22:55] <Laney> righto
[22:55] <cjwatson> I think it worked for me when copying oneiric-proposed -> precise but not oneiric-proposed -> oneiric-updates
[22:55] <wgrant> cjwatson: I don't know that it's busted, I just know how many problems the implementation has had, and how little it was tested.
[22:55] <RAOF> We want everything in https://launchpad.net/~canonical-x/+archive/x-staging/+packages to land in Precise.  It's all built and ready.
[22:56] <cjwatson> but at least some of the implementors seem to be opposed to having the damn thing just e-mail me to tell me what the problem is
[22:56] <cjwatson> so I can't debug it
[22:56] <cjwatson> RAOF: should I care about the four build failures there?
[22:57] <RAOF> Three of them are expected dep-waits rather than build failures; the msm failure on armhf needs fixing, but that can be done later.
[22:58] <cjwatson> I'm not sure it can after I copy
[22:58] <cjwatson> I mean I'm not certain it won't need a new upload
[22:58] <RAOF> Oh, it will need a new upload.
[22:59] <RAOF> But I'm not sure if anyone uses that driver at all, I don't particularly want to invest the time in fixing the build on armhf right now, and I don't want to delay the transition further.
[23:00] <RAOF> And I *know* that no-one uses that driver on armhf right now, because it's never been built there before.
[23:00]  * Laney hopes this transition will bring super meat boy back :-)
[23:02]  * RAOF had no idea that super meat boy went away, so he confidently responds *yes* !
[23:18] <kirkland> cjwatson: hey, any chance you're still around?
[23:18] <kirkland> cjwatson: I have some questions about linux-headers and dkms
[23:19] <cjwatson> RAOF: xkeyboard-config has a newer version in precise?
[23:19] <cjwatson> kirkland: sort of, not sure that sounds like I'm the best person to ask though ...
[23:19] <kirkland> cjwatson: who do you recommend to field this one, then?
[23:19] <kirkland> maybe slangasek has some ideas
[23:19] <RAOF> cjwatson: Yes, that's expected, sorry.  I should have removed that from the PPA.
[23:19] <cjwatson> kirkland: I don't know.  You could ask the question to the channel first and then we could find out
[23:20]  * RAOF could even have some relevant dkms knowledge
[23:20] <kirkland> slangasek: cjwatson: okay, I think this should probably be a systemic problem with any dkms packages
[23:20] <kirkland> RAOF: \o/
[23:20] <kirkland> slangasek: cjwatson: i have a dkms package, which, of course requires linux-headers to build
[23:21] <kirkland> slangasek: cjwatson: i can depend on linux-headers, clearly
[23:21] <kirkland> slangasek: cjwatson: but in practice, that doesn't seem to be enough
[23:21] <robert_ancell> @pilot on
[23:21] <udevbot_> (pilot (in|out)) -- Set yourself an in or out of patch pilot.
[23:21] <robert_ancell> @pilot in
[23:21] <kirkland> slangasek: cjwatson: because of the combination of all of the different versions and flavors that might be on a given user's system
[23:21] <infinity> kirkland: Depending on headers is as much of a failing idea as depending on kernel images.
[23:21] <slangasek> kirkland: there's no good solution to this problem
[23:22] <slangasek> fwiw
[23:22] <kirkland> slangasek: ah, okay, so this is a known issue, that others have tried to solve?
[23:22] <slangasek> yep
[23:22] <kirkland> slangasek: is there a currently recommended best practice?
[23:22] <slangasek> there's no way to express the dependency "I need the version of the headers corresponding to the kernel the user has installed / is running"
[23:22] <infinity> kirkland: nvidia* goes for a best guess of "linux-headers-generic | linux-headers", but that will fail often enough.
[23:23] <kirkland> infinity: yep, which is where we are
[23:23] <infinity> kirkland: Generally, the assumption is that people installing dkms packages have the right linux-* metapackage installed, or know what they're doing. :/
[23:23] <slangasek> kirkland: I think whatever superm1 is doing is probably "recommended best practice"
[23:23] <cjwatson> RAOF: http://paste.ubuntu.com/814880/ - please review
[23:23] <kirkland> infinity: i have a check in the postinst, that can echo to the user exactly what they need to install
[23:23] <kirkland> slangasek: okay, i poked superm1 about this several weeks ago, never heard back from him
[23:23] <infinity> kirkland: People who watch postinst output have a high incidence of intersection with people who know what headers they need.
[23:24] <kirkland> infinity: ack
[23:24] <infinity> kirkland: Now, if this is a driver being enabled by jockey, I suspect jockey can DTRT (and if it doesn't, it could be taught how to)
[23:24] <kirkland> perhaps what i need is a wrapper script that DTRT
[23:24] <slangasek> kirkland: right - but you can work out which dkms-using packages in the archive he's touched, I guess, and look at what they do :)  (I honestly don't remember which those are)
[23:24] <kirkland> and recommend that as the way to install this dkms module
[23:25] <kirkland> slangasek: heh
[23:25] <cjwatson> RAOF: It's possible I could do it all in one command, but then I wouldn't get version checks
[23:25] <cjwatson> And I'm paranoid about this sort of thing
[23:26] <RAOF> Fair enough.  I'm checking the versions, too.
[23:26] <infinity> kirkland: To be fair, on a "standard" Ubuntu system (server or any desktop flavor), it's fair to assume that the right headers are installed, and dkms will "just work".
[23:26] <kirkland> headers=$(dpkg -l linux-image-* | grep "^ii" | awk '{print $2}' | sed "s/-image-/-headers-/") ; sudo apt-get install $headers
[23:26] <infinity> kirkland: People who break that assumption, while in an unfortunate situation from a support and DWIM standpoint, are hopefully fairly rare.
[23:27] <kirkland> infinity: hmm, are you sure about that?
[23:27] <infinity> kirkland: Quite.
[23:27] <kirkland> infinity: i didn't think headers were installed everywhere by default?
[23:28] <infinity> kirkland: We jump through hoops to make sure post-installer systems have kernel+headers that match, and a metapackage to make that persist on upgrades.
[23:28] <RAOF> cjwatson: That list looks correct.
[23:28]  * cjwatson idly notes that linux-headers-generic is no longer the default on i386 ...
[23:29] <cjwatson> (And no idea if we always get upgrades right.)
[23:29] <infinity> cjwatson: You mean generic -> pae upgrades?
[23:29] <infinity> cjwatson: I have no idea either, but I'd like to hope so? :)
[23:30] <cjwatson> So would I.
[23:30] <cjwatson> But I hope for money to rain from the sky too.
[23:30] <infinity> That's hot happening in Cambridge?
[23:31] <infinity> You need to move.
[23:31] <cjwatson> Sucks to be us.
[23:31] <infinity> s/hot/not/
[23:31] <RAOF> I hope you're hoping for notes.  Coins would be really annoying!
[23:31] <infinity> I need new fingers to rain from the sky.
[23:32] <kirkland> if not linux-headers-generic, what is "the default" on i386 now, cjwatson ?
[23:32] <cjwatson> -generic-pae
[23:32] <kirkland> cjwatson: k
[23:32] <cjwatson> as announced a month or two back
[23:34]  * infinity has an inexplicable craving for strawberry milkshakes, and decides it's time for lunch.
[23:36] <kirkland> slangasek: cjwatson: infinity: thanks for your help
[23:36] <kirkland> superm1: ping me about dkms when you have some time
[23:36] <kirkland> superm1: re: the conversation I just had with infinity, cjwatson, and slangasek above
[23:37] <kirkland> superm1: re: best practices on ensuring that all of the necessary headers are installed
[23:37] <slangasek> infinity: new fingers> eew
[23:37] <slangasek> kirkland: sure thing
[23:48] <SpamapS> slangasek: think you'd have time to sponsor a mysql upload?
[23:49] <SpamapS> slangasek: 5.5.20 did in fact fix compiling with gcc 4.6
[23:49] <SpamapS> slangasek: I think I'll keep it in experimental though, until I figure out how to not build /usr/bin/mysql statically linked
[23:57] <micahg> robert_ancell: would be appreciated if you can have a look at bug Bug #916477 after your piloting session (blocking lightdm-gtk-greeter getting into Debian)
[23:59] <robert_ancell> micahg, do you understand why it is failing?  The greeter doesn't need to link against gio