[00:43] <cjwatson> zykes-: as I said yesterday, the apt_pkg.TagFile class can read Packages files
[00:45] <cjwatson> zykes-: I'm not aware of any *library* that can read Contents-* files; in your context I think it's probably reasonable to knock together your own quickly
[00:45] <ajmitch> cjwatson: I spotted an x lts backport package in -proposed that's in universe, xserver-xorg-input-mouse-lts-quantal. should this be promoted to main?
[00:47] <cjwatson> ajmitch: yeah, moved (along with -keyboard-), thanks - but the whole thing probably needs a complete audit which I'm not going to do now :)
[00:47] <ajmitch> I'm somewhat surprised you're still awake :)
[00:48] <ajmitch> thanks for that
[00:48] <cjwatson> just back from a Christmas dinner ...
[00:49] <cjwatson> anyway I have fairly mutable hours, you should be used to that by now :P
[00:49] <ajmitch> certainly
[00:51]  * xnox declares defeated by cmakes inability to be cross-compiled (from bootstrap)... for now...
[00:53] <cjwatson> xnox: dpkg-cross has helper bits for that
[00:54] <cjwatson> ah, if you mean cmake itself not sure about that
[00:54] <xnox> cjwatson: awesome, actually it does have cmake toolchain file, that should be possible to feed to cmake's bootstrap script.
[00:55] <cjwatson> there's stuff in dpkg-cross' man page about how to use it, if that actually turns out to be helpful
[00:55] <cjwatson> I fixed it to suck marginally less just recently
[00:55] <cjwatson> but haven't actually got an entire package cross-building with it yet - just got past some initial obvious errors
[00:56] <xnox> well, I was missing only 2 out of 9 magic variables needed to make it work. close but not enough. Will try cmake again later.
[00:57] <xnox> cjwatson: how often new builds are tried as eventually seen on http://people.canonical.com/~cjwatson/cross/armhf/raring ? Approx. ~once a week?
[00:57] <xnox> or is it continious?
[00:57] <cjwatson> on request
[00:58] <cjwatson> it's all still kind of manual
[00:59] <xnox> fair enough.
[00:59] <xnox> good night.
[01:02] <cjwatson> xnox: I've poked it now - you should have updated results by the time you get up
[01:04] <infinity> cjwatson: Oh, you don't have something importing to wanna-build on a regular basis?
[01:05] <infinity> cjwatson: (And by "something", I'd mean quinn-diff, if it still exists)
[01:33] <slangasek> cjwatson: will your reimport pick up new versions of build-dependencies that happen to land in raring now-ish?  The valac I've just uploaded probably unbreaks a bunch of build-deps, but I don't know how many
[04:23] <psusi> banshee appears to have been misbuilt somehow... it lists depends that don't exist ( future versions )... how could this have happened?  build server misconfiguration?
[04:29] <RAOF> psusi: In what release?
[05:11] <hyperair> psusi: i saw your bug. where are you installing banshee from, and what version of ubuntu is that?
[05:15] <infinity> psusi: apt-cache policy banshee?
[05:15] <hyperair> huh, hang on, how old is libc6 2.6 anyway? the bug report complained that banshee was depending on libc6 2.7.
[05:16] <infinity> Erm, wait, the complaint is about libc6?  What bug is this? :P
[05:16] <infinity> We have 2.7 in hardy...
[05:16] <hyperair> https://bugs.launchpad.net/bugs/1091942
[05:16] <hyperair> that must have been a seriously old version of ubuntu..
[05:17] <hyperair> and he probably plucked the deb out of a later release
[05:17] <infinity> It does, indeed, list libc6 twice, but that's a non-issue (other than being weird).
[05:17] <slangasek> banshee in raring does have a dependency on libc6 (>= 2.7), [...] libc6 (>= 2.16); but that's clearly not the cause of uninstallability
[05:17] <infinity> So, I'd like to see the actual error message.
[05:18] <slangasek> and it's installable here
[05:18] <hyperair> infinity: it's probably a result of dh_shlibdeps and dh_clideps both running.
[05:18] <infinity> (Why it's producing that dep is a different and curious question, mind you)
[05:18] <infinity> Second-guessing shlibs is usually not smart.
[05:18] <hyperair> no actually shlibdeps is smarter than clideps
[05:19] <slangasek> hyperair: why would dh_clideps reference libc6 | libc6.1?  That's unhelpful
[05:19] <hyperair> the issue is probably that ${shlibs:Depends} has libc6, and ${cli:Depends} has libc6 as well
[05:19] <infinity> hyperair: Yes, shlibdeps is smarter, that was sort of my point.
[05:19] <hyperair> slangasek: clideps just gets it from the .shlibs file.
[05:19] <infinity> hyperair: shlibdes gets it right (>= 2.7), clideps is a lie. :P
[05:19] <hyperair> slangasek: and clideps doesn't understand .symbols
[05:20] <infinity> Anyhow, the libc6 dep there isn't causing an issue, it's just silly.
[05:20] <slangasek> hyperair: it most certainly isn't doing so here
[05:20] <slangasek> the libc6 .shlibs file lists libc6.  Only the libc6.1 .shlibs file lists libc6, and I'm pretty sure banshee wasn't built on an alpha.
[05:21] <hyperair> i see libc 6 libc6 (>= 2.15)
[05:21] <hyperair> but i don't see libc6.1.
[05:21] <hyperair> hmm
[05:21] <infinity> Right, but not 6.1 or 0.1
[05:21] <hyperair> weird
[05:21] <infinity> So something's doing that manually to work around some other braindeadery.
[05:21] <infinity> Where does dh_clideps come from?
[05:21] <hyperair> but i don't think dh_clideps does any weird things with libc6..
[05:22] <hyperair> oh there is a hack in dh_clideps
[05:23] <hyperair> if you grep -C3 libc6 /usr/bin/dh_clideps you'll see it
[05:23] <infinity> Yeah, I'm there.
[05:23] <infinity> And lost as to why anyone feels this is necessary.
[05:23] <hyperair> because dh_clideps is arch:all
[05:23] <infinity> If something links to libc6, dh_shlibdeps will pick it up.
[05:23] <infinity> And if it doesn't, you don't depend on it...
[05:24] <hyperair> dh_clideps parses .dlls
[05:24] <hyperair> as in mono p/invokes
[05:25] <hyperair> stuff that appears in ${cli:Depends} comes from parsed .dll's. if libc6 shows up there, that means a mono .dll or .exe has a DllImport of libc6.
[05:25] <infinity> s/libc6/libc/, surely.
[05:25] <hyperair> whichever
[05:25] <infinity> Otherwise, there's no way this hack would work. :P
[05:25] <hyperair> eh well
[05:25] <hyperair> it's overridden in /etc/mono/something
[05:25] <hyperair> <dllmap dll="libc" target="libc.so.6" os="!windows"/>
[05:26] <hyperair> yeah libc
[05:26] <infinity> I'm beginning to be sorry I asked.
[05:26] <hyperair> :)
[05:26] <infinity> Anyhow, those deps can all be satisfied, so I'm still curious what psusi's bug is about.
[05:26] <hyperair> see, the issue is that windows's .NET engine has no support for remapping library name imports
[05:27] <hyperair> only mono does. so you have to target windows, and map it back to the appropriate one on other platforms
[05:27] <hyperair> well this whole ugliness only happens when you try to call native code from within managed code
[05:27] <hyperair> oh i see the culprit has vanished.
[05:28] <slangasek> he's busy time travelling with his warty system
[05:29] <hyperair> hahah
[05:29] <hyperair> i wonder if i should wait or if i should just mark the bug invalid immediately
[05:29] <infinity> My guess would be a multiarch issue clouding things.
[05:29] <hyperair> eh maybe
[05:29] <infinity> Since that sort of thing can get apt to print unhelpful messages that look like "all your libraries aren't installable", as he claimed.
[05:30] <hyperair> especially if you try to use aptitude
[05:30] <hyperair> that bug's still not fixed
[05:30] <infinity> Just double-checked, and banshee's installable on precise/quantal/raring.
[05:30] <hyperair> great
[05:32] <infinity> Now, back to packaging glibc 2.17, which will obviously solve his problem.
[05:32] <infinity> Since 17 is a pretty big number.
[07:03] <pitti> Good morning
[07:24] <pitti> ah, UDD discussion round umpteen
[08:06] <dholbach> good morning
[09:09] <Laney> pitti: shall we start a systemd/upstart thread to distract everyone? :-)
[09:10] <pitti> Laney: christmas holiday, the time for harmony :)
[09:10] <Laney> you need the flames to keep you warm in this cold cold winter
[09:10] <pitti> we need upstart maintained in UDD with a graphical Unity shell that sends all your system events to amazon
[09:11] <pitti> and with naked people, of course!
[09:11]  * pitti wonders if the old warty backgrounds package still exists somewhere in the mists of the interwebs
[09:16] <dholbach> naked people!
[09:17] <dholbach> pitti, if you search on images.google.com for 'ubuntu calendar' you should be able to find them :)
[09:17] <pitti> http://ubuntu.ecchi.ca/wallpapers/, at the very bottom
[09:32] <persia> http://old-releases.ubuntu.com/ubuntu/pool/main/u/ubuntu-calendar-*/...
[09:34] <hyperair> heh
[09:49] <Laney> RAOF: still here?
[09:50] <Laney> banshee was released into quntal-updates but it's uninstallable
[09:51] <Laney> Depends: libglib2.0-0 (>= 2.34.1) but 2.34.0-1ubuntu1 is to be installed
[09:55] <Laney> can I query e.u.c somehow to see if any instances of a crash have the SRUed glib installed?
[09:56] <cjwatson> infinity: I haven't made it regular because wanna-build's merge algorithm tends to involve retrying uninstallable-build-dep failures over and over again, and there are hundreds of those here so I don't want to overdo it - for now, I have a script I run every day or two
[09:59] <cjwatson> slangasek: should build against current raring+raring-proposed as of whenever the build starts - I'm not using an imported archive to satisfy build-deps or anything
[10:12] <Laney> I checked a lot of instances of bug #1044322 on e.u.c and none had the -proposed glib installed
[10:12] <Laney> someone SRUy please to be advising
[10:12] <caribou> If I need to modify an existing Quilt patch in a package, and I'm working off the bzr branch, is it expected to have the ./pc quilt files included in the merge proposal ?
[10:13] <caribou> I did "quilt pop; {modify the patch};quilt push;quilt refresh" to update the patch, so some of the ./pc files got also modified
[10:15] <caribou> another way at it would be to work off the source package & submit a debdiff (this is for an upcoming SRU btw)
[10:17] <xnox> caribou: yes, please do "$ bzr add .pc" before committing.
[10:18] <xnox> caribou: easy test - $ bzr bd -S, should work. SRUs are typically easier to sponsor with debdiffs though.
[10:19] <pitti> +1
[10:19] <pitti> UDD is just an unnecessary pain for both sides for SRUs
[10:19] <caribou> xnox: depends who I talk to :) some teams have asked me for Merge Proposals
[10:19] <pitti> (IMHO with my sponsor hat on)
[10:20] <Laney> the sponsoring into Ubuntu side is smoother with a diff
[10:20] <Laney> you might want MPs at some other stage, like submitting upstream
[10:20] <persia> Do the importers not import all the -security and -updates uploads?
[10:20] <persia> If not, is there a bug about this?
[10:20] <xnox> (when I say "easier" I imply that a subjective majority of sponsors prefer that. I prefer UDD branches for everything: as then it doesn't matter if it's a new package, SRU, merge, new upstream release & i can work with it)
[10:20] <caribou> pitti: I tend to agree too; working off the source pkg/debdiff is easier for most of the changes
[10:20] <pitti> they do, but an MP for the first-ever SRU doesn't work as there is no branch to propose _to_
[10:21] <pitti> and then, almost nobody can modify the status of those MPs, so everyone pings me about "please close/reject/wip this branch", etc.
[10:21] <persia> Oh, there's no "we're releasing now, so populate all the release branches" action?
[10:21] <pitti> plus, UDD and quilt patches are just a pain
[10:21] <xnox> caribou: I find bzr branches to be the best tool to create the debdiff: out of tree builds are awesome and vcs is awesome for work-in-progress. In the end generate a source package, debdiff & done.
[10:22] <persia> Why?  I thought the advantage of UDD was to have stuff in branches to generate diffs, etc.  With Format:3.0(bzr) being quite as experimental as it is, I would expect everyone to use quilt.
[10:22] <pitti> xnox: you obviously do not work a lot with debian/patches/ :)
[10:22] <xnox> heh, I do =)
[10:22] <pitti> for native packages I fully agree
[10:23]  * xnox has scripted around quilt patches.
[10:23] <pitti> but UDD only keeps precisely those bits under "proper" version control which we are not interested in modifying
[10:23] <persia> Oh, that's a different problem then :)
[10:23] <pitti> but with the bits that we do it still requires quilt, plus keeping track of pre-applied patches in the actual source, not forgetting .pc, and so on
[10:24] <pitti> oh argh, I'm being drawn into that discussion again, I'll STFU
[10:24] <Laney> :D
[10:24] <caribou> xnox: from a bugfixing pow, debdiff are simpler, but I can understand the value of UDD from a developer's pow
[10:24] <persia> pitti: Sorry for dragging you into that discussion: I did appreciate the better understanding.
[10:24] <caribou> pitti: thanks for the clarification though :)
[10:24] <pitti> heh, no worries :)
[10:42] <hyperair> bug #1091942
[10:42] <hyperair> it looks like banshee was released from -proposed before its dependencies.
[10:42] <Laney> fixed
[10:42] <hyperair> ah
[10:42] <hyperair> thansk
[10:43] <hyperair> Laney: as in, glib has been released from proposed?
[10:43] <Laney> right
[10:43] <hyperair> okay, thanks
[10:43] <Laney> I saw you talked about it last night, how come nobody did it then?
[10:44] <hyperair> because nobody knew what was wrong
[10:44] <hyperair> psusi filed a bug report with hardly any information
[10:44] <Laney> but it was uninstallable in updates
[10:44] <hyperair> it just said that "a lot of libraries had the wrong version" but it didn't say which ubuntu he was running
[10:44] <hyperair> in fact, he said that banshee depended upon libc6 2.7
[10:44] <hyperair> while he only had libc6 2.6
[10:44] <hyperair> that really threw us off
[10:45] <hyperair> libc6 2.6 was during hardy.
[10:45] <hyperair> before that, even, since it looks like hardy has 2.7
[10:46] <RAOF> Oh, urgh. Why did banshee pick up a depend on that glib? Stupid dh_clideps.
[10:46] <pitti> http://people.canonical.com/~ubuntu-archive/testing/precise-updates_probs.html FYI
[10:46] <hyperair> heh
[10:46] <pitti> RAOF: or precise-proposed's  glib bumped shlibs?
[10:47] <hyperair> that's most probably it.
[10:47] <hyperair> it could be -V
[10:47] <Laney> not precise, quantal
[10:47] <RAOF> pitti: That would be unusually obnoxious.
[10:47] <Laney> and it has symbols
[10:47] <Laney> which clideps doesn't understand ...
[10:47] <hyperair> yes, clideps only uses shlibs
[10:48]  * hyperair brb. leaving work
[10:48] <RAOF> You know, I bet it wouldn't be *that* hard to get clideps to use symbols.
[10:48]  * RAOF foretells of some more godforsaken perl hacking in his future.
[10:53] <mlankhorst> RAOF: can you clear the x sru queue for precies? :>
[10:54]  * RAOF did a bunch of precise unapproved clearing this morning.
[10:54] <RAOF> mlankhorst: What are you after? Not that I'll get to it today; it's 10pm.
[11:07] <mlankhorst> RAOF: 'xorg' + blobs
[11:28] <cjwatson> jibel: Hi - did you get my mail with further questions about britney/autopkgtest integration?
[11:29] <cjwatson> I was hoping to make some progress on that before EOY but am blocked on those questions
[11:32] <jibel> cjwatson, Hi, I did, I've been side tracked by other things and delayed my reply, sorry, replying now.
[11:32] <cjwatson> great, thank you
[11:58] <pitti> ev: s3 merge> yay! that means the charms can now be updated to just lp:daisy?
[12:00] <blackz> cjwatson: so is bug #917708 officially fixed? can the "workaround" applied to affected packages be dropped?
[12:07] <cjwatson> blackz: yes
[12:11] <cjwatson> blackz: I didn't know there were outstanding workarounds or I might have dropped them myself :)
[12:13] <blackz> cjwatson: https://launchpad.net/ubuntu/+source/bitcoin/0.6.2.2-1ubuntu1 for example
[12:15] <cjwatson> feel free to revert that
[12:39] <bambee> Hi, nvidia-current does not build with linux-image 3.5.21-generic on precise  (there is a 3.5 kernel packaged on precise)
[12:42] <ev> pitti: yes :)
[12:42] <ev> pitti: working on integrating it into lp:~ev/daisy/prodstack-prep
[12:54] <xnox> bambee: but nvidia-updates does build.
[12:54] <xnox> bambee: also note ubiquity sru comment: https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1070427/comments/24
[12:56] <bambee> nvidia-current-updates you said, interesting, looking
[12:56] <bambee> thanks
[13:33] <jibel> cjwatson, I replied and updated the interface on lillypilly to never overwrite sources.list, so it can uses the apt index directly.
[14:06] <jibel> pitti, I finished enabling jhbuild for gnome on raring
[14:06] <jibel> https://jenkins.qa.ubuntu.com/view/Quantal/view/JHBuild%20Gnome/
[14:06] <jibel> it's written Quantal but is really Raring
[14:07] <jibel> I filled a ticket to have that changed
[14:07] <jibel> pitti, currently it builds gnome-core moduleset, check is disabled
[14:27] <pitti> jibel: merci! il semble mieux que j'ai pensé
[14:30] <jibel> pitti, indeed, I think I can enable checks, what do you think?
[14:31] <pitti> jibel: in my jhbuild I have quite a lot of failures, but indeed let's enable them so that we have something to point to for upstream reports
[14:31] <pitti> that's the point anyway
[14:32] <pitti> jibel: any idea what this is about? https://jenkins.qa.ubuntu.com/view/Quantal/view/JHBuild%20Gnome/job/jhbuild-amd64-gnome-doc-utils/1/console
[14:32] <pitti> ah, so control-center is an actual bug, it shouldn't hard-depend on systemd
[14:32] <caribou> xnox: I'm preparing the SRU for https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/833368 on Precise
[14:33] <caribou> xnox: should there be a specific task for Precise in the bug ?
[14:37] <jibel> pitti, wrt. gnome-doc-utils, I started the build while there is nothing to build, and it was waiting for something that will never happen
[14:38] <pitti> jibel: ah, so that was a genuine timeout
[14:46] <caribou> xnox or anyone who can answer, just so happen that he is assigned to that bug
[14:48] <xnox> caribou: well, I need to sponsor this into raring first before it goes into precise. & also sru for quantal will be needed.
[14:48] <caribou> xnox: it's already fixed in Q & R
[14:49] <caribou> xnox: let me double check again, but I tested both and only found the bug in Precise
[14:51] <xnox> caribou: ok, I have adjusted statuses and opened the task for precise. please correct me if the per-series tasks are wrong now.
[14:53] <caribou> xnox: looks good. I'll assign myself to the bugs and will check with ivoks on the resource-agent side when he's back from vacation
[14:53] <caribou> xnox: just checked Quantal and it is indeed fixed but I'll confirm with ivoks
[14:54] <ivoks> heh?
[14:55] <ivoks> caribou: act fast; i'm not on vacation today and tomorrow; but i will be starting on friday :)
[14:56] <caribou> ivoks: so will I, so I want this one SRUed before I leave
[14:56] <ivoks> caribou: xnox first glance is that this bug is *invalid* in Q and R and will be invalid in P once lvm2 monitoring bug is fixed
[15:00] <xnox> ivoks: are you saying that resource-agents should not be part of the bug at all?
[15:13] <ivoks> xnox: caribou overall view of the problem is that clustered lvm requires monitoring to be on
[15:13] <ivoks> xnox: caribou in ubuntu, default is monitoring off
[15:14] <ivoks> xnox: caribou and it's off by a change in the code, not by choosing within lvm.conf
[15:14] <ivoks> xnox: caribou resource-agents assumes that monitoring is set to on, if one wants to use it
[15:15] <ivoks> xnox: caribou since we disable monitoring in the code of lvm, even if someone enables monitoring in lvm config, that setting is ignored
[15:15]  * xnox really should setup & learn clustered lvm & add automatic tests for it.....
[15:15] <ivoks> xnox: caribou therefore, user enables monitoring in lvm.conf and finds out that lvm commands still don't enable monitoring
[15:16] <ivoks> xnox: caribou once we fix lvm in precise to use config option to disable monitoring, instead hardcoding it in the code, all problems go away
[15:16] <caribou> ivoks: this is the SRU I'm preparing, right ?
[15:17] <ivoks> caribou: correct
[15:17] <caribou> ivoks: the one we discussed yesterday
[15:17] <caribou> xnox: ivoks: the debdiff is ready, changes tested on precise so the SRU is about to go
[15:17] <ivoks> if you need help in testing it, let me know
[15:18] <xnox> caribou: well, attach debdiff to the bug report & i can test & sponsor it.
[15:18] <caribou> ivoks: I've tested monitoring = [0|1] in /etc/lvm/lvm.conf and it works as designed
[15:18] <xnox> caribou: note that for an SRU the bug description should match https://wiki.ubuntu.com/StableReleaseUpdates?action=show&redirect=StableReleaseUpdate#SRU_Bug_Template
[15:18] <ivoks> caribou: and without the rest of the changes in the code?
[15:18] <caribou> xnox: yep, was waiting for the Precise task you just added to add the SRU template
[15:19] <caribou> ivoks: with the patch you gave me yesterday
[15:19] <ivoks> caribou: excellent
[15:19] <caribou> ivoks: it basically reverts the hardcoding and changes doc/example.conf.in
[15:19] <ivoks> yep
[15:20] <ivoks> caribou: you might build that package and ask people in the bug 833368 to test it
[15:20] <caribou> ok, I'm updating the template then will subscribe the proper people to it
[15:20] <caribou> ivoks: I already have a PPA ready for testing if someone wants to
[15:21] <ivoks> caribou: there are few candidates in that bug
[15:21] <xnox> ivoks: well testing a package from ppa will not speed up sru.... as we want people to test the -proposed package.
[15:21] <ivoks> xnox: ah, right
[15:21] <caribou> xnox: yeah, usually I refrain from doing that, so people don't end up using my PPA instead of the fix
[15:22] <caribou> ivoks: and building a new pkg from the debdiff can be done if they want to
[15:22] <xnox> caribou: ivoks: as far as I understand resource-agents task should be removed or  marked as "invalid" since the bug is in the lvm package.
[15:22] <ivoks> caribou: https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/833368/comments/31 target this guy
[15:23] <caribou> ivoks: ok
[15:23] <ivoks> caribou: ask him to revert his changes
[15:23] <ivoks> caribou: and, of course, test the package from proposed, including changing monitoring to 1 in lvm.conf
[15:24] <caribou> ivoks: yep, that will be done as well
[15:51] <vibhav> Are ubuntu-sponsors automatically suscribed when a merge proposal is created?
[15:51] <slangasek> if the merge is targeted to the right branch, yes
[15:52] <Laney> check http://reqorts.qa.ubuntu.com/reports/sponsoring/ if you're in doubt
[15:57] <vibhav> slangasek, Laney: thanks
[15:58] <jibel> pitti, look http://10.98.0.1:8080/view/Raring/view/JHBuild%20Gnome/job/jhbuild-amd64-nautilus/2/ failed
[15:58] <jibel> pitti, commit was 34 min ago :)
[15:58] <jibel> looks like our testing is working
[15:59] <jibel> https://jenkins.qa.ubuntu.com/view/Raring/view/JHBuild%20Gnome/job/jhbuild-amd64-nautilus/2/ for the public address
[16:05] <Riddell> doko: do you know if python2.7 has had recent multiarch changes?
[16:06] <doko> Riddell, yes
[16:08] <Riddell> doko: mm, poor old cmake seems to be confused
[16:08] <doko> Riddell, about what?
[16:08] <xnox> Riddell: i almost have a working patch for cmake to unbreank FindPython
[16:08] <xnox> Riddell: sorry for the delay.
[16:08] <Riddell> doko: it can't find pyconfig.h which has been moved to a multiarch dir
[16:09] <Riddell> xnox: oh?
[16:09] <Riddell> I'm using this workaround currently http://paste.kde.org/627974/
[16:09] <xnox> Riddell: do you know who did original debian-multiarch patches for cmake? /me wants a review.
[16:09] <xnox> Riddell: that workaround is fine, but it does not scale across all of cmake code for python2.7 =/
[16:09] <Riddell> xnox: might have been slangasek?
[16:10] <xnox> (there were only a couple of packages for python3)
[16:15] <slangasek> xnox: MoDaX did them
[16:17] <xnox> slangasek: heh a comrade =)
[16:21] <jbicha> doko: were you interested in working on bug 914631 ?
[16:23] <doko> not now
[16:27] <pitti> jibel: hah -- unpackaged/undeclared dependency
[17:05] <doko> xnox, when will you commit the cmake fix? wanting to start the test rebuild tomorrow
[17:08] <xnox> doko: ha. ok. let me do the cmake fix now & come back to upstart tomorrow.
[17:14] <hrw> does someone here has Samsung Chromebook (arm one)?
[17:34] <armor_xt> hello everybody, short question: is it possible to find out which packages are depending on an individual one? e.g. which packages are depending on libc
[17:34] <stgraber> armor_xt: apt-cache rdepends
[17:35] <stgraber> though the outpout for libc6 may be pretty long ;)
[17:35] <stgraber> (16k)
[17:35] <armor_xt> great, thank you!
[17:35] <armor_xt> I was looking in the apt-get *cache evironment, but couldn't find it
[17:35] <armor_xt> stgraber, *lol* was just an example
[17:39] <infinity> stgraber: apt-cache rdepends is poorly-named, it actually lists packages with *any* relationship (including breaks and conflicts)
[17:39] <infinity> armor_xt: reverse-depends from ubuntu-dev-tools is a bit more reliable on this score.
[17:40] <infinity> (And also acts on all architectures, rather than just the one(s) you have in your apt cache)
[17:41] <stgraber> infinity: indeed. Main brain still isn't used to reverse-depends (and reverse-depends -b for build-dep) :)
[17:41] <Laney> src:foo is awesome too
[17:42] <infinity> Of course, the CGI may be having a hissy fit right now.  I can't get it to spit out any useful responses...
[17:42] <infinity> Oh, there it goes.  Probably just overloaded.
[17:47] <gotwig> jo
[17:47] <gotwig> Are ubiquity dev's available?
[17:47] <gotwig> Can you tell me where can I change the font for the terminal in ubiquity while installing?
[17:47] <gotwig> at the bottom
[17:48] <stgraber> that'd be in the gtk theme
[17:48] <stgraber> we don't explicitly configure the theme for that part of the ubiquity UI, we just use the standard gnome vte widget
[17:48] <gotwig> I talk about changing the font, the installer uses for the embeded terminal
[17:48] <gotwig> the font is different for the embedded terminal.
[17:48] <gotwig> that is not ubuntu mono
[17:49] <stgraber> gotwig: oh, actually, we do hardcode the font
[17:49] <stgraber> ./ubiquity/frontend/gtk_ui.py:        self.vte.set_font_from_string("Ubuntu Mono 8")
[17:49] <gotwig> lol? xD
[17:50] <gotwig> stgraber, thank you for your quick help
[17:50] <gotwig> stgraber, may I show you the bug report, I want to fix?
[17:50] <gotwig> https://bugs.launchpad.net/bugs/1072426
[17:51] <gotwig> When I would change the font to e.g Droid Sans Mono, would it use that font for the terminal?
[17:52] <infinity> Could it be that your image isn't shipping "Ubuntu Mono" in the live environment, and X is doing a near-match lookup and finding something uglier?
[17:52] <slangasek> infinity: on your system where you get the "disk drive for /tmp is not ready yet" error, do you have crypted swap (on its own partition, not via LVM)?
[17:52] <stgraber> gotwig: you can try, just edit gtk_ui.py directly on the live media
[17:52] <infinity> infinity: Nope, no LVM or encryption on this machine.
[17:53] <stgraber> gotwig: it should be either under /usr/lib/ubiquity/ or /usr/share/ubiquity/ (can't remember, sorry)
[17:53] <infinity> slangasek: Just a big, fat /
[17:53] <gotwig> stgraber, can you tell me, how to test such stuff, demo an installation :X?
[17:53] <slangasek> infinity: no crypted swap, even?  Ok, then that's not a commonality with bug #1091792, drat
[17:53] <infinity> slangasek: Though, I haven't seen the bug since I reinstalled, so maybe I accidentally made it go away. :/
[17:53] <slangasek> heh
[17:53] <stgraber> gotwig: you could write a gtk software using the same vte code, or just run a test install in a vm
[17:54] <infinity> slangasek: I reinstalled to correctly 4k-align my partitions (and switched from GPT to MBR at the same time and ditched EFI), so I've probably changed far too many variables to be of use.  Unless the bug comes back anyway.
[17:54] <gotwig> thank you really much
[17:54] <slangasek> you *ditched* EFI?  Luddite
[17:54] <infinity> slangasek: I sure did.
[17:55] <hrw> can someone upload packages from bug #1085392 so SRU process can start?
[17:55] <xnox> gotwig: usually on #ubuntu-installer channel, what's up?
[17:55] <gotwig> xnox, I've already got help I guess, thx
[17:56] <infinity> hrw: Why are we SRUing Chromebook userspace support back to Q and P?  It's not like we ship kernels.
[17:57] <hrw> infinity: because users use 12.04 and 12.10 with chromium kernel?
[17:57] <slangasek> infinity: I think this falls under the "hardware non-disablement" policy for SRUs, doesn't it?
[17:57] <hrw> infinity: I created chromium kernel package today - will build for my ppa in 14+ hours
[17:58] <slangasek> (we don't have to support the hardware, but maybe we shouldn't set it on fire :)
[17:58] <infinity> slangasek: Yeah, in this case, I'm okayish with it because it melts laptops.
[17:58] <infinity> slangasek: I'd forgotten about that until I re-read the bug and the test-case. :P
[17:58] <slangasek> :-)
[17:58] <hrw> :)
[17:59] <infinity> hrw: I'll look at both these diffs.  I have a nagging suspicion I might also need to re-fix PandES in Q while I'm at it (as I did with the R upload)
[17:59] <hrw> infinity: iirc Q has pandaes but P does not
[18:00] <infinity> Oh, so maybe the ES stuff was dropped between Q and R?  That could be.  I forget the history.
[18:00] <infinity> Anyhow, I'll poke 'em sometime today.
[18:00] <hrw> infinity: thanks
[18:05] <cjwatson> slangasek: vala cross> you seem to have managed to get unity-lens-music and unity-lens-shopping cross-building, at least
[18:05] <slangasek> huzzah
[18:15] <infinity> slangasek: Good job on fixing the most contentious package in the archive?
[18:15] <slangasek> infinity: which one is that?
[18:15] <infinity> (unity-lens-shopping)
[18:16] <slangasek> ah, heh
[18:30] <xnox> doko: the fix will make sure that PYTHON_INCLUDE_DIRS has the correct both paths & work for all pythons[2,3]. but many packages still use deprecated PYTHON_INCLUDE_PATH & those will still need manual fixing.
[19:13] <slangasek> pff, why is gobject-introspection FTBFS due to a *libtool-generated linker script*?
[19:18] <slangasek> ah, because I screwed up a symbol name, hee
[19:56] <slangasek> barry: ping
[19:56] <barry> slangasek: pong
[19:57] <slangasek> barry: hey, so I have most of a python3 port now at lp:~vorlon/ubuntu/raring/gobject-introspection/python3/
[19:57] <slangasek> barry: the most recent "last" issue I have is DictMixin -> MutableMapping telling me that I need to implement __len__ and __iter__... where would I find documentation on the right way to do this?
[19:59]  * barry looks
[20:00] <barry> slangasek: this has some examples:http://docs.python.org/3/library/collections.abc.html#collections.abc.MutableMapping
[20:01] <barry> slangasek: and this some additional background: http://docs.python.org/3/reference/datamodel.html#object.__len__
[20:13] <gotwig> stgraber, it worked. Thx
[20:14] <slangasek> xnox: mdeslaur seems to have found your ubiquity-desktop-background-broken-in-raring-VM bug
[20:14] <slangasek> xnox: bug #1080674
[20:15] <xnox> aha. good.
[20:17] <xnox> doko: Riddell: cmake uploaded, if packages use standard FindPythonLibs & PYTHON_INCLUDE_DIRS they should be all multi-arch ready.... if not patch them to use system FindPythonLibs & PYTHON_INCLUDE_DIRS (instead of _DIR or _PATH)
[20:25] <cjwatson> slangasek: IIRC I did that in python-debian, if you want a cargo-cult source for MutableMapping stuff
[20:26] <cjwatson> or maybe in germinate
[20:26] <slangasek> cjwatson: barry hit me over the head with a pointer to the stock OrderedDict instead :)
[20:27] <barry> collections.OrderedDict
[20:27] <cjwatson> if that's appropriate, sure :)
[20:28] <cjwatson> IIRC it requires 2.7, so upstream might raise an eyebrow
[20:28] <barry> yeah, i was gonna ask how far back you needed to support
[20:28] <slangasek> I just wrapped the import with a try
[20:29] <slangasek> they can fall back to their existing implementation for python2.6, that's fine
[20:34] <cjwatson> OK; failing that I believe MutableMapping is in 2.6
[20:35] <cjwatson> which I believe is the approach I took in germinate, albeit for something less stock than an ordered dict
[20:47] <slangasek> barry: why does file.write() want a string instead of bytes?
[20:48] <slangasek> barry: or perhaps a better question is, if I have a stream of bytes that I want to shove out an fd, how can I do this without having to convert it to unicode and back? :P
[20:48] <cjwatson> depends on the mode in which the file has been opened
[20:48] <cjwatson> mode="wb"
[20:48] <slangasek> oh, I need 'b'
[20:48] <slangasek> right, thanks
[20:49] <cjwatson> also if it's literally an fd then os.write always takes bytes
[20:49] <slangasek> cool, no more python parse errors from gir, now I just get a segfault to track down ;)
[20:55] <barry> sorry, i was making tea :)
[20:56] <gotwig> barry, :O
[20:56] <slangasek> ok... and pdb fails
[20:57] <slangasek> anyone know what this is? http://paste.ubuntu.com/1450819/
[20:57] <slangasek> I shouldn't think that 'import os' would be a problem for pdb :P
[20:58] <barry> slangasek: are there c extension modules involved, or is this pure python?
[20:58] <slangasek> barry: there's a C extension
[20:58] <slangasek> so I have a perfectly fine C backtrace in gdb
[20:59] <barry> slangasek: my first suspicion when there are incomprehensible tracebacks and c extensions is that the c extension is broken somehow.  something's not checking a return value or some mess in refcount.  never makes it easy to find unfortunately
[21:00] <slangasek> barry: would you mind having a look at my gobject-introspection/python3 branch and seeing if anything jumps out at you as broken in the C extension porting?
[21:01] <barry> slangasek: sure
[21:01] <barry> slangasek: the url above?
[21:01] <slangasek> yes, lp:~vorlon/ubuntu/raring/gobject-introspection/python3/
[21:02] <slangasek> segfault seems to be pygi_source_scanner_parse_macros() getting passed an empty list as an argument, and segfaulting deeper in the code for some reason
[21:02] <slangasek> not sure if that empty list points to a bug in the C extension porting, or an issue in the python code
[21:05] <barry> slangasek: unrelated, but maybe useful: http://docs.python.org/3/c-api/none.html?highlight=py_return_none#Py_RETURN_NONE
[21:06] <slangasek> ok
[21:06] <slangasek> ah, definitely a C extension bug
[21:06] <slangasek>       filename = PyUnicode_AsUTF8 (obj);
[21:07] <slangasek> somehow that's returning NULL for each one
[21:08] <barry> slangasek: in type_get_child_list(), you should check that PyList_New doesn't return NULL
[21:08] <barry> and that PyList_SetItem() doesn't return -1
[21:08] <slangasek> well
[21:08] <slangasek> I should also check that I've spelled 'PY_MAJOR_VERSION' right everywhere :-)
[21:09] <barry> also, i don't think you need to incref list since PyList_New returns a new reference
[21:09] <barry> that too :)
[21:10] <barry> also, in pygi_source_scanner_parse_macros(), you should incref list while inside the function, and decref it on exit from the function
[21:11] <barry> since PyTuple_GET_ITEM steals a reference
[21:11] <barry> (and i'll just assume that pygi_source_scanner_parse_macros() actually does get called with args as a tuple ;)
[21:12] <slangasek> barry: mind throwing me a patch for those?
[21:12] <barry> slangasek: why don't i just do a branch from your branch? :)
[21:12] <slangasek> sounds good :)
[21:12] <slangasek> I'm past the segfault due to the swapped python3/2 code branches; now I'm finding that OrderedDict may not be sufficient after all :)
[21:13] <barry> dang
[21:13] <slangasek> ah no, this is 'itervalues', that's a python2ism anyway
[21:14] <barry> which i'm guessing you probably don't need.  is the dict so big that a concrete list of its values will kill memory?
[21:15] <slangasek> probably not?
[21:15] <barry> right, so just use .values() :)
[21:15] <barry> probably
[21:16] <barry> i.e. you don't have itervalues() in py3, but .values() always returns an iterator in py3
[21:16] <barry> for loops won't care
[21:19]  * slangasek nods
[21:26] <barry> slangasek: oh.  does g_list_append() create a new object if its first argument is NULL?
[21:27] <slangasek> barry: evidently, since it doesn't crash ;)
[21:27] <barry> :-o
[21:27] <barry> ;)
[21:28] <barry> well, i could either try to dig up the gobject api docs or just roll with it :)
[21:30] <barry> slangasek: apparently so... -ish: http://developer.gnome.org/glib/stable/glib-Doubly-Linked-Lists.html#g-list-append
[21:31]  * slangasek nods
[21:36] <slangasek> bryce: have you seen the comments on bug #1041063, and bug #1091976? the patch author asserts that this SRU is broken
[21:47] <hallyn> hi - for bug 589063, the SRU fix for lucid-proposed was not verified in time.  someone just asked that it be re-uploaded, they can verify they claim.  Should I d/l and re-upload the .dsc from the Done queue (i see it there), or can someone just click a button to move it over?
[21:56] <barry> slangasek: what's a good way to test this, or do you just want my untested branch?  i'm probably being a bit over-paranoid, but better to be over than under ;)
[21:56] <slangasek> barry: well, so far building the package has been a very good test, it hasn't passed yet ;)
[21:57] <barry> k
[22:01] <barry> slangasek: hmm:
[22:01] <barry> checking for python module mako... no
[22:01] <barry> configure: error: Could not find python module: mako
[22:01] <barry>  
[22:01] <barry> python-mako needed?
[22:01] <slangasek> barry: should only need python3-mako
[22:02] <slangasek> oops
[22:02] <slangasek> I didn't update debian/control.in
[22:02] <barry> ah
[22:08] <mako> people talking about mako again
[22:08] <barry> mako: hi!
[22:08] <mako> greetings! :)
[22:08] <slangasek> barry: fix pushed
[22:09] <slangasek> mako: hey, I heard something about you being back on this side of the continent now?
[22:10] <barry> slangasek: dang, i can't pull it because of conflicts on the quilt patch, but i think i fixed it locally anyway
[22:10] <mako> slangasek:not quite yet. i just took a job in seattle, but i won't move out until august probably
[22:10] <slangasek> barry: yay quilt ;)
[22:11] <slangasek> mako: ah, ok :)
[22:17] <barry> slangasek: iter*() pain
[22:17] <slangasek> ah?
[22:17] <barry> yeah, just a few more .iter*() calls causing the build to fail.  no worries
[22:36] <hallyn> stgraber: would you be able to toggle a switch to move the 0.5.1-0ubuntu2.1 seabios from https://launchpad.net/ubuntu/lucid/+queue?queue_state=3&queue_text=seabios back into lucid-proposed ?
[22:36] <hallyn> (if i try to re-push it complains the contents have changed)
[22:39] <stgraber> hallyn: it's in "done" state, so it's been accepted in the archive, meaning you have to bump the version if you want to re-upload
[22:39] <stgraber> hallyn: ah, or do you mean https://launchpad.net/ubuntu/lucid/+queue?queue_state=1&queue_text=seabios ?
[22:40] <stgraber> oh, ok, that's odd, so one of the 0.5.1-0ubuntu2.1 has been accepted in the archive
[22:40] <stgraber> so that number is burned and you need to bump
[22:40] <hallyn> what the...
[22:40] <stgraber> though there's another 0.5.1-0ubuntu2.1 in the Unapproved queue with the same version number
[22:40] <stgraber> that can't possibly be accepted
[22:41] <hallyn> stgraber: it was accepted into lucid-proposed, but never into lucid.  doesn't show up in rmadison
[22:41] <hallyn> is there a way to just 'move' it back into -proposed from whatever bitbucket it neded up in?
[22:44] <hallyn> i'm gonna guess no and put down a note to build 0.5.1-0ubuntu2.2 tomorrow
[22:50] <stgraber> hallyn: you'll need 2.2 either way. I'm not sure exactly what happened there but someone from ~sru and who's more awake than I'm can probably help :)
[22:51] <hallyn> stgraber: noone verified it, so pitti dropped it.  id ont' know what dropping it entails
[22:52] <hallyn> so i can use the same .dsc, just bump the version number, and push?  will do, thx
[22:52] <slangasek> it entails removing it from the archive; it's possible to restore it, but that's necromancy
[22:52] <slangasek> is your 2.2 going to be the exact same thing?
[22:53] <stgraber> was it just a case of not getting any testing done in a long time or was there another reason for removing the package?
[22:53] <slangasek> https://launchpad.net/ubuntu/+source/seabios/+publishinghistory claims "moved to updates"
[22:54] <slangasek> oh, no, that's the wrong one
[22:54] <slangasek> pitti didn't delete it, I did ;)
[22:54] <slangasek> "SRU not verified" - so it sat there for 90+ days with no SRU verification, then an additional 15 days after a reminder ping
[22:54] <hallyn> yup
[22:55] <slangasek> so if you're going to reupload, I would first ask why it'll go differently this time :)
[22:55] <hallyn> slangasek: bc someone commented on the bug sayin gthey're ready to verify
[22:55] <slangasek> ok
  am i a hopeless romantic? :)
[22:55] <hallyn> slangasek: if you want to drop, i'm fine with that.  ij ust pushed 2.2
[22:56] <hallyn> mahmoh: are you there?
[22:56] <hallyn> mahmoh: you also could jump in and verify bug 589063 if slangasek accepts the fix again?
[22:58] <mahmoh> hallyn: I saw that, I can
[22:58] <mahmoh> hallyn: but not until next week :)
[23:02] <barry> slangasek: gotta run, but lp:~barry/ubuntu/raring/gobject-introspection/cleanups is my progress so far.  enjoy detangling the quilt changes <wink>.  i can help hack on this tomorrow if needed
[23:05] <hallyn> mahmoh: a week is good :)  thanks - ttyl
[23:05] <slangasek> barry: cheers :)
[23:05] <mahmoh> hallyn: np, happy all that stuff!
[23:28] <bryce> slangasek, not broken; it builds fine and if you look, the change is sane even for 1.11.  The bug had been nominated for precise.  After it was processed then he says it's unneeded for precise.
[23:28] <bryce> slangasek, we have much/most of the Q input stack backported to P's 1.11 so there's no particular reason to doubt that the bug affects precise as well.
[23:29] <slangasek> bryce: ok; can you comment on the bug, and un-verification-failed it?
[23:29] <bryce> slangasek, however since the original reporter seems to doubt it's applicable, if it makes you feel better go ahead and drop the package.  I'm not going to bother digging through patches.
[23:30] <bryce> slangasek, I've reverted the 10.10 change in git.
[23:30] <slangasek> bryce: well, I'm merely flagging it to you to make sure you know about it; I'm not going to get in the middle of an argument about whether the patch is needed/appropriate :)
[23:31] <slangasek> but there were other bugs fixed in that SRU, so if this one won't get verified, it would be good to have a reupload with it dropped
[23:31] <bryce> slangasek, neither am I interested in that.  I'm just an sru monkey, it matters not at all if no one wants the srus they ask for.  ;-)
[23:31] <bryce> slangasek, 10.10 only had the one patch.  Just go with 10.9.
[23:31] <slangasek> bryce: well, we can't go with it, it's already been superseded in -proposed
[23:32] <bryce> slangasek, I wasn't the uploader for 10.9 remember...
[23:33] <slangasek> hmm?
[23:33] <slangasek> was that the one I asked you to reupload with a different -v? :/
[23:34] <slangasek> in any case, either we have to take .10 with this patch, or we need a .11 to get any of the fixes from .9