[00:00] <ajmitch> mwhudson: stock up on the flight over?
[00:00] <mwhudson> ajmitch: i guess duty free in london, yeah
[02:55] <Tohuw> So, besides the apparently unmaintained procmon for Linux, how can I view a running snapshot of system calls in Ubuntu a la SysInternal's ProcMon for Windows?
[03:05] <sarnold> Tohuw: probably strace is what you're looking for
[03:08] <Tohuw> sarnold: Quite possibly, but how can I get strace to continuously follow. For example, "strace firefox" gives me very helpful data right up until firefox is fully launched, then quits. I played around with follow options and could not achieve what I want: follow system calls indefinitely
[03:13] <slangasek> Tohuw: '-ff'
[03:13] <Tohuw> slangasek: nope, still exits
[03:14] <slangasek> mmm
[03:14] <Tohuw> Ah, it's something to do with how firefox spawns the process. This works fine in gedit. I'd still like to see an easy option for monitoring *everything*
[03:15] <slangasek> well, there are a few tools for monitoring everything, but nothing particularly easy AFAIK
[03:15] <Tohuw> It's handy to see all the changes and system calls everything on the system is making. Yes, it spawns very, very long logs, but it's still wonderful
[04:58] <pitti> Good morning
[05:05] <obounaim> Good morning pitti,
[05:14] <sarnold> Tohuw: hrm. if strace -f firefox doesn't actually follow all children of firefox, please file a bug.
[05:14] <sarnold> Tohuw: if you want to see more system calls than just firefox, look into auditd; it can be configured to dump system calls and results. It is _extremely_ verbose, so be careful. :)
[05:39] <vibhav> Good Morning
[05:47] <vibhav> Hmm, /win 6
[05:48] <vibhav> Sorry
[06:23] <vibhav> The toolchain will be uploaded today, right?
[06:26] <vibhav> ( according to https://wiki.ubuntu.com/RaringRingtail/ReleaseSchedule)
[06:46] <dholbach> good morning
[07:27] <darkxst> TheMuso, I hear you are from my part of the world
[07:57] <pitti> wookey: FYI, pcre3 can be synced, newer upstream version in Debian contains newer config.{guess,sub} with aarch64; doing now
[07:58] <pitti> wookey: (in case you are looking at merges)
[07:58] <pitti> we need the new version for current glib
[08:05] <pitti> infinity: OOI, why do we have all those armel/armhf PPA builders? do the "blessed" PPAs not use the distro builders any more?
[08:06] <pitti> infinity: or do we plan on enabling arm for PPAs in general?
[08:07] <pitti> cjwatson, doko_: is the thawing of raring blocked on doing some toolchain merges? (I'll do cdbs now) or do we want to wait for the "everything to -proposed" magic?
[08:31] <dpm> pitti, cjwatson, could any of you add me to the uds-organizers team in LP? I'm told that as a track lead it will enable me to approve blueprints for the app dev track. Or do I need to send an e-mail to the Tech Board to request membership?
[08:32] <pitti> dpm: added you
[08:33] <dpm> excellent, thanks pitti :)
[08:35] <pitti> cjwatson, doko: cdbs uploaded FYI
[08:39] <ailo-w> Hi, I was wondering if someone could help me with tips on creating some blueprints. Like those done here https://blueprints.launchpad.net/ubuntu/+spec/topic-quantal-flavor-ubuntustudio. I can see how I create one blueprint, like this one https://blueprints.launchpad.net/ubuntu/+spec/ubuntustudio-q-documentation. My question is, how do I create dependencies?
[08:39] <cjwatson> pitti: waiting for the "everything to -proposed" stuff to finish landing; also I believe infinity is planning on a glibc upload
[08:40] <cjwatson> pitti: the armel/armhf PPA builders are part of urgent work being done for PS
[08:41] <pitti> cjwatson: ah thanks; so we are not particularly blocked on merges
[08:41] <cjwatson> No
[08:41] <pitti> cjwatson: so we have PPAs which can build for ARM now? nice!
[08:41] <cjwatson> Well
[08:41] <cjwatson> Only on explicit request and I think currently intended only for specific clients of the system
[08:41] <cjwatson> I don't know the full details
[08:42] <pitti> right, I didn't mean "all PPAs", just that they exist
[08:42] <cjwatson> Some are Pandas, but they have no useful security and are very limited-access
[08:42] <cjwatson> Most of the rest are qemu instances running on x86 boxes, AFAIK
[08:48] <ailo-w> ..never mind. I'll ask someone specifically :)
[08:49] <infinity> cjwatson: The pandas should be all gone from the PPAs.
[08:50] <cjwatson> Good.
[08:51] <cjwatson> Ah yes, mizar's now a disabled distro builder rather than a disabled PPA builder. :-P
[08:55] <infinity> cjwatson: Yep.
[08:55] <infinity> cjwatson: There's some vague hope that it won't be disabled after a reinstall.
[09:16] <infinity> jodh: Around?
[09:18] <infinity> jodh: Witness pitti's back-to-back commits to glib to first use __abort_msg, and then not:
[09:18] <infinity> jodh: http://git.gnome.org/browse/glib/commit/glib/gtestutils.c?id=da66897950431870390f8dc3f798e24f23ffb8c8
[09:18] <infinity> jodh: http://git.gnome.org/browse/glib/commit/glib/gtestutils.c?id=3658727cfa0eca8c66bc2cdff46992099caf0acd
[09:18] <infinity> jodh: Methinks that NIH should just follow in the same footsteps here, regardless of how and when apport catches up.
[09:19] <tjaalton> is raring open yet?
[09:20] <infinity> tjaalton: It exists, but it's frozen while we hammer out some last-minute bits.
[09:20] <tjaalton> infinity: ok, thanks
[09:22] <infinity> jodh: And, in fact, I see no indication that apport was ever changed to embrace glib's method.  And one can only assume just due to its much larger number of consumers, that glib aborts far more often than nih.
[09:22] <infinity> pitti: Say, am I missing something there, BTW?
[09:24] <pitti> infinity: I initially wanted to re-use glibc's symbol, but was then told not to
[09:24] <pitti> see gnome bug 594872
[09:25] <pitti> infinity: so apport and friends now need to check both symbols indeed
[09:25] <infinity> pitti: Yeah, reusing glibc private symbols is totally Bad and Wrong, I agree.
[09:25] <pitti> eek, but indeed Apport doesn't
[09:25] <infinity> pitti: I meant am I missing... Yeah. :)
[09:26] <jodh> infinity: agreed. __nih_abort_msg or similar, as mentioned on bug 997359.
[09:26] <infinity> pitti: So, let's fix apport to DTRT for glib.  And let's fix NIH to follow in glib's footsteps, and make apport also check for __nih_abort_msg, and life will be good.
[09:27] <infinity> jodh: Right, shall we JFDI?  I'd love to see it finally not be an issue.
[09:27] <jodh> infinity: yeah, i'm keen :)
[09:28] <infinity> jodh: (Given I'm prepping a pre-opening glibc, this is part of the reason I suddenly care.  I'd like an nih landing first that doesn't have the *&#@%# private symbol linkage, so upgrading isn't a silly bootstrap dance)
[09:29] <infinity> It also, interestingly, will take a pretty big load off apt's resolver on upgrades, I suspect.
[09:30] <infinity> Given the importance of both libnih1 and libc6, and the messed up dependency apt needs to sort on every new upstream glibc...
[09:33] <jodh> infinity: ok. I'll get this fixed in NIH upstream first...
[09:33] <cjwatson> (this should be today, BTW; there's a decent chance the other blocker to opening will be resolved by EOD)
[09:38]  * infinity gets back to glibc, to see about hitting this EOD deadline.
[09:46] <hrw> will all raring uploads have to wait for approval?
[09:47] <cjwatson> No
[09:47] <stgraber> no, archive is just not opened yet
[09:48] <cjwatson> Not long now
[09:48] <hrw> ok, I uploaded first part of my cross compiler update to raring gcc
[09:59] <xnox> So apparently  I need autoconf2.63 to build postgresql-9.1 which briefly existed in karmic&jaunty. pitti, do you have a stash of old autoconf?
[10:00]  * xnox has a patch to make it build against py3.3 by default but it needs autoconf run =/
[10:00] <pitti> xnox: uh? I'm building 9.1 just fine on lucid to quantal and squeeze to unstable with 2.69
[10:00] <pitti> (or whicever is the default)
[10:00] <pitti> xnox: oh, autoreconfig doesn't work?
[10:01] <xnox> pitti: yeah, you can build but cannot patch configure.in & regenerate configure =)
[10:01] <xnox> configure.in:22: error: Autoconf version 2.63 is required.
[10:01] <xnox> Untested combinations of 'autoconf' and PostgreSQL versions are not
[10:01] <xnox> recommended.  You can remove the check from 'configure.in' but it is then
[10:01] <xnox> your responsibility whether the result works or not.
[10:01] <pitti> xnox: https://launchpad.net/ubuntu/+source/autoconf/2.63-3ubuntu1/+build/988278 ?
[10:01] <xnox> =)))))
[10:02] <xnox> i386 build of autoconf 2.63-3ubuntu1 in ubuntu karmic RELEASE produced these files:
[10:02] <xnox> autoconf_2.63-3ubuntu1_all.deb (deleted)
[10:02] <pitti> oh, I thought LP would never forget anything
[10:02] <cjwatson> We eventually expire pre-release binaries
[10:02] <cjwatson> Though only several years later
[10:02] <pitti> xnox: well, the source is still there, so I guess you could jusjt build it locally
[10:03] <xnox> I found this build: https://launchpad.net/ubuntu/karmic/amd64/autoconf/2.63-2ubuntu1
[10:03] <xnox> I think I'll do the reconf in a chroot.
[10:06] <pitti> infinity: fixed in apport trunk, thanks for pointing out!
[10:07] <infinity> pitti: shiny.  bug 997359 has apport tasks too, for after jodh settles on a symbol name (which, I assume, will be __nih_abort_msg)
[10:07] <pitti> infinity: right, that's straightforward to add then
[10:08] <pitti> well, writing a test for it requires a build dep on libnih-dev, but oh well
[10:08] <pitti> I'll make it fail gracefully if it's not there
[10:16] <fabbione> morning guys
[10:16] <fabbione> doko_: you around?
[10:19] <pitti> hey fabbione, how are you?
[10:19] <fabbione> pitti: doing ok.. waiting for you guys to show up in CPH for UDs
[10:19] <fabbione> pitti: you?
[10:19] <pitti> quite fine, thanks! looking forward to UDS indeed
[10:20] <fabbione> and the beer... ;)
[10:20] <fabbione> pitti: is doko_ still in charge of toolchain?
[10:20] <fabbione> i think i found a bug in gcc, but i need to confirm
[10:20] <pitti> yes
[10:20] <fabbione> ok
[10:29] <xnox> barry: https://blueprints.launchpad.net/ubuntu/+spec/desktop-r-python3 and https://blueprints.launchpad.net/ubuntu/+spec/foundations-r-python-versions are suspiciously similar
[10:30] <seb128> xnox, barry: would be good to merge both, I doubt we have lot to discuss for desktop on the topic
[10:30] <seb128> xnox, barry: I can drop the desktop one from the UDS schedule if that works for you
[10:31] <xnox> seb128: if there specific packages you'd like to turn into workitems feel free to add them on foundations-r-python-versions spec. It was meant to be a "low-entry" for workitems =) as there is plenty to do.
[10:31] <xnox> seb128: that would be best. Yes, please. =)
[10:32] <seb128> xnox, ok, we don't have much remaining for desktop ... mostly system-config-printer that we plan to deprecate (it has its own blueprint) and u1 (which is rather u1 team than us)
[10:32] <pitti> seb128: software-center?
[10:33] <xnox> seb128: yeap & yeap. There is a big software-centre bit, but it's blocked on xapian, last time I checked.
[10:33] <seb128> pitti, I don't consider that to be ours :p
[10:33] <seb128> ours == desktop
[10:34]  * seb128 looks at mvo
[10:34] <pitti> ah, "team" vs. "image"
[10:34] <xnox> seb128: what the pretty wallpapers? =))))
[10:34] <seb128> pitti, yeah, we were speaking about merging foundation and desktop blueprints
[10:34] <seb128> so I was on "what items on what team plate"
[10:34] <seb128> U1 is also an issue
[10:34] <seb128> but that's on online's services plates
[10:37] <xnox> pitti: in which shape, form and where do you prefer postgresql patches?
[10:38] <pitti> xnox: preferably, sent to pgsql-bugs@postgresql.org
[10:38] <pitti> xnox: I'm happy to backport it to Debian then
[10:38] <pitti> xnox: I'm on that list, so I'll see it
[10:39] <pitti> xnox: (no need to be subscribed to post)
[10:39] <xnox> pitti: I kind of want it into raring-proposed now, it's one of few packages that ftbfs with py3.3 by default.
[10:39] <xnox> pitti: Ok, I'll submit the patch & upload into staging PPA and then we can decide where else it can/should go.
[10:39] <pitti> xnox: well, go ahead and upload it then :) but please send it to upstream, too
[10:40] <xnox> ack.
[10:40] <pitti> xnox: I can grab the patch from LP, etc.
[10:40] <pitti> or grab the upstream committed variant from git, etc.
[11:21] <xnox> I cannot login into summit.ubuntu.com because of bug 881019 who can I contact about this?
[11:24] <cjwatson> xnox: #is internal
[11:24] <cjwatson> xnox: (though you might need to wait for US webops to come online)
[11:25] <xnox> cjwatson: ack. thanks.
[11:32] <infinity> pitti: http://launchpadlibrarian.net/121078084/libnih_1.0.3-4ubuntu11_1.0.3-4ubuntu12.diff.gz <-- Should indicate what apport needs to do to support libnih being fixed the same way as glib.
[12:08] <apw> @pilot in
[12:11] <pitti> infinity: yep, will do
[12:13] <infinity> pitti: <3
[12:51] <cjwatson> slomo: Sorry, I'm going to reject these gst-* uploads.  Firstly, they'll be auto-synced tomorrow or thereabouts anyway, and it's better to have that ancestry where we can.  Secondly, if we just wait for a few more hours then they get to go through the -proposed migration stuff.
[12:51] <xnox> I think lubuntu is smaller than libreoffice source package.
[12:52] <slomo> cjwatson: ok, sorry
[12:52] <cjwatson> (which will decrease risk of things being uninstallable)
[12:53] <cjwatson> I understand dual uploads late in the cycle, but at this point I wouldn't recommend bothering :)
[13:07] <tjaalton> i made a dodgy upload of xorg-server to quantal-proposed, could an archive admin drop it from the queue?
[13:15] <pitti> tjaalton: there are two uploads
[13:15] <pitti> tjaalton: drop the older one and keep the newer one? or otherwise?
[13:17] <tjaalton> pitti: yeah the first one had an extra (disabled) patch on it, but they both were from the wrong branch :) mlankhorst, is it ok to push anyway?
[13:17] <pitti> tjaalton: ah, so reject both?
[13:18] <tkamppeter> pitti, chrisccoulson, you remember that (probably on Monday) I complained on this channel that Thunderbird clogged up my SSD with a 27G mailbox file from my Canonical Inbox? It seems that I got hitten by bug 1068921.
[13:18] <tjaalton> pitti: yeah, i'll fix it later today
[13:19] <pitti> tjaalton: ok, rejected both
[13:19] <tjaalton> thanks
[13:34] <bjaanes> Can someone here explain why dash does not show amazon results in Norway?
[13:34] <Laney> cjwatson: can you help us with an ubuntu-desktop packageset query perchance? rhythmbox isn't in it. Do you know why?
[13:35] <Laney> also seeded-in-ubuntu rhythmbox doesn't show it being seeded (only -dbg/dev/doc)
[13:36] <seb128> bjaanes, that would be a question for the u1 guys, either bug or amazon doesn't provide that service in Norway
[13:36] <stgraber> Laney: should seeded-in-ubuntu return anything at this point? I thought it was parsing .manifest and .list which we don't have yet (as we didn't spin any raring image yet)
[13:37] <bjaanes> seb128, okey how can I get in touch with them?
[13:37] <Laney> perhaps it is looking for raring-* - I thought it was just grabbing all the latest .manifests
[13:38] <pitti> cjwatson: btw, we haven't forgotten about/ignored your britney/autopkgtest mail, but we need to fight with some firewall/set up http server etc. stuff
[13:41] <Laney> stgraber: ah, yeah, it excludes all supported releases
[13:51] <brendand> what is the source package of ubuntu-bug?
[13:52] <Laney> laney@iota> dpkg -S /usr/bin/ubuntu-bug                                                                                                    ~
[13:52] <Laney> apport: /usr/bin/ubuntu-bug
[14:03] <barry> xnox, seb128: thanks for collapsing those blueprints down to foundations-r-python-versions.  also, don't forget the 13.04 spreadsheet of work: http://tinyurl.com/93kpvef
[14:03] <barry> seb128: please review and add or let me know if anything obvious is missing
[14:03] <seb128> barry, ok
[14:03] <xnox> barry: thanks =)
[14:04] <xnox> barry: about half of the rebuilds are done now in a ppa https://launchpad.net/~ubuntu-rebuilds/+archive/py3.3
[14:05] <barry> seb128, xnox: thanks guys.  oh and yeah, xapian is still a painful blocker.  last time i chatted with mvo about it, he thought there might be work underway to put a dbus front on xapian, which would alleviate the need for a py3 port of it (maybe).  do you know anything about that?
[14:06] <barry> xnox: oh cool.  i had started to set up another ppa for this https://launchpad.net/~pythoneers/+archive/py33 but didn't get to populating it before i had to give my talk.  i think i'll just delete this ppa and start looking at the ftbfs in yours
[14:07] <xnox> barry: ack. I think I did add you to mine. I created a new team, as i didn't know about ~pythoneers
[14:07] <xnox> barry: me and doko have been crunching through them
[14:07] <barry> xnox: we also have ~pythonistas but don't ask what the difference is :)
[14:07] <barry> xnox: awesome!  what have you gotten to?  i can start working on others
[14:08] <barry> xnox: and i should add you to pythoneers
[14:08] <xnox> I am in progress on fixing: blender.
[14:09] <barry> xnox: going alphabetically? :)
[14:09] <xnox> barry: from here https://launchpad.net/~ubuntu-rebuilds/+archive/py3.3/+packages if it's not build and has an X it needs looking into.
[14:09] <barry> xnox: yep, that's the one i'm looking at too.  let's divide and conquer
[14:10] <cjwatson> Laney: It's ended up in core, probably due to (build-)dependencies from other core packages.  The process for moving such things that are actually maintained by desktop folks to the desktop packageset is to mail me.
[14:10] <cjwatson> pitti: No great rush, thanks.  I'd just like to have a clear idea by next week of what we're doing.
[14:11] <xnox> barry: this one passes unit tests in 3.2, but not 3.3: https://launchpadlibrarian.net/120976604/buildlog_ubuntu-raring-i386.objgraph_1.7.1-1build1_FAILEDTOBUILD.txt.gz
[14:12] <barry> xnox: probably the first thing to check is hash order dependencies
[14:12] <xnox> barry: and shiboken is also a thing for you =)
[14:12] <barry> xnox: yay!  my old friend shiboken (shibroken?) :)
[14:13] <barry> xnox: i also want to look at passlib since i know that library a bit
[14:13] <barry> xnox: so when you fix one are you uploading it to both raring and the ppa?
[14:14] <xnox> all sounds good =)
[14:14] <xnox> barry: for now yes. raring-proposed and the ppa.
[14:14] <barry> xnox: yep.  cool.
[14:14] <xnox> barry: ppa has 3.3 as default, while archive has 3.2 as default. Both have 3.2-3.3 as supported
[14:15] <barry> xnox: perfect
[14:15] <barry> xnox: i wish it was easy to copy packages from one ppa to another
[14:16] <cjwatson> It is
[14:16] <cjwatson> If you're finding it not so, I can help
[14:17] <cjwatson> But there's clicky web UI for it and everything, as well as command-line tools
[14:18] <xnox> barry: go to source ppa, and click "copy packages" on the package overview page =)
[14:18] <xnox> barry: are you in ~ubuntu-rebuilds? I think I did add you...
[14:18] <cjwatson> Indeed.  Or use copy-package from lp:ubuntu-archive-tools if you prefer the command line
[14:19] <barry> xnox: i'm not, but ~ubuntu-core-dev is a pending member.  can you just add me explicitly?
[14:21] <xnox> barry: welcome to the team =)
[14:21] <barry> cjwatson: that's exactly what i was looking for: copy-package --ppa-name foo --to-ppa bar
[14:22] <barry> cjwatson, xnox tho i don't think it's worth it in this case.  however, if for some reason we plan on keeping a py33-as-default ppa long term (and i hope we won't), we should move it to ~pythoneers
[14:23] <xnox> barry: I think doko is eager to flip the switch. Not sure when, but the vibes I'm getting from him are before UDS.
[14:23] <ogra_> vibes eh
[14:23] <barry> xnox: i'm supportive of that.  gives us two days to whip that thing in shape :)
[14:25] <xnox> ogra_: well... he is being conservative. if it was up to him it would be 3.3 default, drop 3.2, rebuild archive, done =)
[14:25] <ogra_> heh, yeah, its a devel release after all :)
[14:25] <mterry> barry, I somehow renamed the first column header in your python3 porting matrix to 'oauth' and can't fix it back
[14:27] <mterry> barry, also, python3-oauthlib exists, and the python-oauth section should mention that
[14:27] <barry> fixed
[14:28] <xclaesse> Hello, any idea how I could work around this bug? https://bugs.launchpad.net/ubuntu/+bug/1071330
[14:28] <barry> mterry: it does, but it's buried in a bunch of gobbledygook
[14:28] <barry> mterry: i suppose we should officially endorse oauthlib as the way forward
[14:29] <mterry> barry, it mentions that a python3 port exists on the web somewhere, but not that it was in quantal
[14:29] <mterry> barry, yeah probably
[14:30] <mterry> it's in main and all that jazz
[14:40] <barry> mterry: i know you submitted patches upstream.  have they been accepted yet? (i suppose i could try to dig out the link to that)
[14:40] <mterry> barry, yes
[14:40] <mterry> barry, let me find link
[14:42] <mterry> barry, https://github.com/idan/oauthlib/pull/56
[14:42] <mterry> barry, https://github.com/idan/oauthlib/issues/62 has a report about issues with 3.3 though
[14:43] <mterry> My patch was only for 3.2
[14:43] <barry> mterry: thanks.  dict ordering.  i'll take a look at that
[16:00] <Laney> pitti: rejecting glib and pcre3 so that I can sync them into -proposed, per the new world order
[16:00] <pitti> Laney: ack; I thought that would be redirected automatically soon
[16:00] <Laney> not for copies
[16:01] <cjwatson> Redirecting copies ended up being too complex an API that would be very hard to fix any more later
[16:01] <cjwatson> Since the copy API is very explicit about what pocket it's going into
[16:02] <pitti> ah, ok
[16:02] <cjwatson> For now, use syncpackage -r raring-proposed; I've changed the default in bzr
[16:02] <pitti> cjwatson: I guess we'd build that redirection into syncpackage then, i. e. rewriting the destination on the fly
[16:02] <pitti> or that, thanks!
[16:03] <cjwatson> Yeah, no point rewriting really since I expect -r is rather rarely used
[16:03] <barry> xnox: i think it's best to build in the ppa, and only after it passes there, upload to r-p.  the reason is that some of the packages in the ppa have version numbers ahead of the archive, so it requires additional bumps to build in the ppa.  but those intermediate (ppa-only) versions can be thrown out when uploading to r-p.  passlib is an example of that.
[16:03] <pitti> good night everyone
[16:03] <cjwatson> And I'm happier changing defaults than adding magic
[16:05] <xnox> barry: well I test build locally in sbuild, which has that ppa added. So i know it passes when I upload fixes to both =)
[16:05] <mitya57> hey barry (finally you are here at the same time as I am!)
[16:05] <mitya57> can you ask birkenfeld about one thing?
[16:05] <barry> mitya57: sure
[16:06] <mitya57> barry: I wonder whether he is going to fix https://bitbucket.org/birkenfeld/sphinx/issue/1008/test-failures-with-python-33
[16:07] <mitya57> it's causing ftbfs in raring and I don't have enough sphinx experience to fix that myself.
[16:07] <xnox> doko: I have a fix for blender, but I think I may have done a mistake in my python3-defaults, because I got a stray/unneeded python3.2 dependency via ${python3:Depends}
[16:08] <barry> xnox: not quite though.  passlib is ftbfs in the ppa, but is a version ahead of raring afaict.  so i have to bump the version *again* for the ppa, but when i upload to raring, i won't need to skip that version number.  unless it has your ppa version# in r-p, but tools like rmadison and bzr branch ubuntu:passlib haven't caught up with that yet.
[16:08] <barry> mitya57: let me check with him over in #python-dev
[16:09] <mitya57> barry: whois says he is only at #pocoo and is offline there
[16:09] <xnox> barry: yes, ppa has funny version numbers for some packages. I bumped all version numbers when doing rebuild. For most it's builX which doesn't matter, but for those that had ubuntuX it became ubuntuX+1 ahead of the archive.
[16:09] <barry> mitya57: seems to be online on #python-dev, tho away
[16:09] <barry> xnox: right.  that's really all i was saying :)
[16:10] <xnox> barry: I see =) just keeping you on your toes. I guess I should have used copy-package to rebuild from the archive -> ppa. But oh well.
[16:10] <mitya57> barry: oops, so my /whois lies :)
[16:10] <barry> mitya57: i guess so :)
[16:10] <barry> xnox: yeah, no worries.  just something to be aware of.
[16:11] <xnox> barry: I was hoping to copy src from the ppa back to the archive, but that won't be happing now due to slightly wrong changelog entries in most of them (stray multimaintainer lines)
[16:11] <mitya57> barry: thanks!
[16:11] <barry> mitya57: i'm watching the issue now too.  i pinged birkenfeld over in #python-dev, but maybe he really is away :)
[16:12] <mitya57> let's hope he reads his scrollback :)
[16:12] <barry> xnox: /me -> lunch but i guess i'll set up my local sbuild to add the ppa so i don't have to wait 3 hours for stuff like this: https://launchpad.net/~ubuntu-rebuilds/+archive/py3.3/+build/3929285 :)
[16:13] <xnox> barry: yeah doko has rescoring them for me such that most of them were building instantly
[16:14] <barry> ah.  say doko, can you rescore ^^ ? :)
[16:15] <stgraber> barry: done
[16:15] <barry> stgraber: thanks!
[16:15] <seb128> bjaanes, the reason seems to be "there is no amazon in Norway"
[16:16] <barry> xnox: did you add-apt-repository in your source:raring-arch schroot, or do you use sbuild --setup-hook, twiddle the config file, or something else?
[16:17] <xnox> barry: install software-sources-common, add-apt-repository, then purge software-sources-common
[16:17] <xnox> =)))
[16:18] <barry> ok :)
[16:18] <mitya57> s/sources/properties/ ?
[16:20] <xnox> mitya57: barry: yeah something like that. Long winded and descriptive =)
[16:30] <barry> xnox: something tells me this is going to be a meme: http://paste.ubuntu.com/1305272/
[16:32] <bdmurray> mvo: could you a look at bug 1070035?
[16:33] <xnox> barry: I think it dates back to an older meme, where packages worked with 3.2 only, which 3.1 was default and 3.2 supported, or something like that =)))))
[16:33] <xnox> barry: it's certainly one of the common cases.
[16:36] <mitya57> barry: is module.__loader__ gone in python3.3?
[16:38] <mitya57> ah, it's new, the contrary :)
[16:41] <mitya57> barry: what can this check mean: https://bitbucket.org/birkenfeld/sphinx/src/d7ac5e46307d/sphinx/util/__init__.py?at=default#cl-200
[16:41] <mitya57> and what's its equivalent in python3.3 (if you know)?
[16:42] <mvo> bdmurray: certainly
[16:47] <mvo> bdmurray: I followed up in the bug, the root is that universe is not enabled, but I am a bit in the dark what the best fix is
[16:48] <mvo> bdmurray: i.e. the user has only main enabled so he/she will not want universe packages but kubuntu-netbook is now universe, so its a bit tricky to decide whats the right course of action (enable universe automatically, fail with a better error message)
[16:48] <bjaanes> seb128, That is true i suppose, but there is no problem buying from Amazon in Norway. I do it all the time. Its very popular over here.
[16:48] <bjaanes> amazon.com works perfectly and ships to norway with most of their stuff
[16:48] <seb128> bjaanes, well, I asked the U1 guys, that's the reason it doesn't work, there is no amazon.no
[16:49] <seb128> bjaanes, right, that's a known "would be nice if that worked"
[16:49] <bjaanes> seb128, okey - but is there any workaround?
[16:49] <seb128> bjaanes, you should ask to Chipaca on #ubuntu-desktop
[16:49] <bjaanes> seb128, Shall do, thank you for your help!
[16:50] <seb128> bjaanes, yw!
[16:51] <ceolin> hey folks, about the appmenu, is it requires patched version of gtk and qt to works ?
[16:57] <doko> xnox, barry: rescored
[16:57] <xnox> doko: \0/
[16:57] <bdmurray> mvo: ah, thanks for looking
[17:01] <Riddell> mvo: fail with a better error seems the most sensible, otherwise it's a security issue
[17:04] <mvo> Riddell: thanks, yeah, a string change :/ I wonder if we can release note it at least
[17:04] <mvo> so that everyone knows
[17:04] <doko> xnox, barry do you have a list, who addresses which ftbfs? or who's working on what?
[17:05] <xnox> doko: just finished/uploaded blender and morse-simulator (they were hard-coded to 3.2 so not an easy spot)
[17:07] <xnox> doko: I'd like to look at boost.
[17:08] <doko> xnox, sure, if you want to =) see my comment in the bug report what I figured out
[17:17] <xnox> doko: looks like there is multiarch.jam in the wild http://code.ohloh.net/file?fid=6JCqBzlemTFqf5oPg9xW4FA-3BQ&cid=WGhTHTVrHL8&s=&browser=Default#L0
[17:17] <alexbligh> what is approved Ubuntu way of resizing the console post boot? resizecons & SVGATextMode do not appear to exist.
[17:19] <alexbligh> hmm, that's on Lucid. Allegedly resizecons is in precise
[17:31] <alexbligh> packages.ubuntu.com has resizecons in package kbd: http://packages.ubuntu.com/search?searchon=contents&keywords=resizecons&mode=exactfilename&suite=lucid&arch=any - however installing it and dpkg -L on the package gives the manpage but not the binary. Any ideas?
[17:34] <xnox> alexbligh: support is at #ubuntu or http://askubuntu.com
[17:35] <xnox> doko: for boost, is doing dpkg-architecture -qDEB_HOST_MULTIARCH called cheating? =)
[17:35] <doko> xnox, no, why?
[17:36] <xnox> doko: I may have a patch then ;-)
[17:36] <doko> nice
[17:37] <xnox> doko: need to test it with both boost sources and both boost versions (4 source packages) =))) will take a while.
[17:39] <doko> xnox: use osageorange for one build
[17:39] <fabbione> doko: hey
[17:40] <fabbione> doko: do you still maintain gcc/toolchain ?
[17:40] <xnox> doko: ?????
[17:41] <fabbione> doko: i think i found an alignment bug on amd64 but i need an expert to look at it
[17:45] <doko> fabbione, heya, will you be at uds?
[17:46] <barry> doko: i don't think we have a list.  i was just going to pick them off and mention it here so i don't duplicate work you or xnox is doing
[17:46] <doko> if you're still in Denmark
[17:46] <fabbione> doko: yes, it's behind the corner ;)
[17:46] <fabbione> doko: yeps
[17:46] <fabbione> i am still here
[17:46] <doko> cool
[17:46] <fabbione> doko: that means you will have to see my ugly face again :P
[17:46] <fabbione> s/:P//
[17:46] <doko> heh
[17:46] <fabbione> seriously tho.. do you still maintain gcc?
[17:47] <doko> yep
[17:47] <fabbione> ok
[17:47] <fabbione> doko@u.c ?
[17:47] <doko> yes
[17:47] <fabbione> ok.. sending
[17:47] <barry> xnox, doko: either of you looking at dirspec?
[17:48] <xnox> nope
[17:48] <doko> barry, already fixed
[17:48] <doko> as nose
[17:48] <xnox> barry: too easy =)
[17:48] <doko> now looking at lxc
[17:48] <barry> doko, xnox: ah, okay.  i guess the ppa is just behind the times
[17:48] <doko> barry, subscribe to raring-changes, and look what got uploaded
[17:49] <barry> doko: i'm subscribed, but behind on those emails
[17:49] <fabbione> doko: sent.. i tested different gcc in ubuntu and debian and fedora. same issue
[17:49]  * barry catches up
[17:49] <fabbione> doko: if it's a bug it's very old
[17:50] <fabbione> doko: i just can't wrap my head around it... it doesn't make any sense
[17:51] <cjwatson> that sounds like it ought to get a reduced test case and go upstream ...
[17:51] <fabbione> cjwatson: i already have a reduced test case to the bare minimum
[17:52] <fabbione> cjwatson: but there is no guarantee it's a bug. it might be my code
[17:53] <doko> xnox, barry: lcx fixed, now looking at libguestfs
[17:53] <barry> doko, xnox cool.  i'll do shiboken i guess
[17:56] <xnox> barry: yeah it even fails to build in quantal.
[17:57] <fabbione> doko: thanks tho! have a nice evening and see you soon (let me know if you need more info)
[18:22] <addiks> hi, i have recently upgraded to 12.10 and noticed that unity now uses nux instead of geis for multitouch. In 12.04 i have patched unity to disable geis to be able to use ginn with my own gestures, but i dont know how to do that with nux. Anyone got a clue?
[18:24] <doko> what am I doing wrong? http://paste.ubuntu.com/1305518/
[18:31] <xnox> doko: make ate the first set of quotes?
[18:31] <xnox> doko: passing -O2 directly to configure.
[18:32] <xnox> doko: that's why I don't like inlining shell in makefiles, and instead prefer $(for ) make function loops, not shell loops.
[18:32] <doko> xnox, no $ is evaluated by the shell, make doesn't see any quotes. thing is that at this point of expansion, it's too late
[18:33] <xnox> doko: include /usr/share/dpkg/buildflags.mk
[18:33] <xnox> is all you need?
[18:33] <xnox> doko: yeah, you are right.
[18:34] <micahg> doko: CXXFLAGS isn't being properly quoted
[18:34]  * xnox off for a little while.
[18:35] <micahg> doko: nevermind
[18:35] <ScottK> If you're switching from a directory to a symlink in a package, it's my understanding that dpkg won't do that change for you.  What's the right way to handle that?  Remove the directory in the preinst?
[18:35] <xnox> ScottK: spended of patches / uploads in debian recently. yes preinst snippets.
[18:35] <xnox> ScottK: see debian-devel or recentish RC bug fixes...
[18:36] <ScottK> xnox: Right.  The reason I ask is I just got one of those bugs filed on a package of mine and so I'd like to fix it.
[18:36] <ScottK> Do you have a patch/snippet example you could point me at?
[18:38] <xnox> ScottK: https://launchpadlibrarian.net/117993446/bitlbee_3.0.5-1.1_3.0.5-1.2.diff.gz
[18:39] <ScottK> xnox: Thanks.
[19:07] <doko> ScottK, uploaded a fixed qscintilla2
[19:59] <barry> doko, xnox, ScottK shiboken is annoying.  one of the tests is segfaulting, and it seems consistent in ubuntu and debian chroots.  nothing upstream that i can tell :/  anyway, still investigating
[20:06] <slangasek> jbicha: bug #1071008 sounds like it might be a gnome-remix package selection issue?
[20:21] <jbicha> slangasek: yes, thank you
[20:21] <slangasek> jbicha: ok - guess you'll reassign to an appropriate place then :)
[20:38] <ScottK> doko: Thanks (re qscintilla2)
[20:39] <doko> ScottK, won't file a Debian report
[20:39] <ScottK> I'll take care of it.
[20:45] <ScottK> python3-dbus.mainloop.qt is now an empty package.  Fixing that up.
[20:48] <slangasek> infinite loop in under 3 seconds
[20:50] <ScottK> It's not important until we care if the installer works.
[21:40] <barry> xnox: still around by any chance?
[21:54] <xnox> barry: just for you =)
[21:54] <xnox> barry: i didn't manage to reproduce shiboken in debian chroot.
[21:54] <xnox> barry: if it is, file a bug there as well.
[21:54] <barry> xnox: otp w/slangasek, but how did you get the output in bug 1070772?  i get different failures
[21:55] <xnox> barry: right, so I peaked at the full environment variables of how the test is executed. I did the build and run it with exact same parameters but added -vv to python.
[21:55] <xnox> barry: nothing fancy
[21:58] <barry> xnox: ah.  so i'm inclined to punt on this bug, after reporting it upstream.  i'm going to leave the package ftbfs so it's more obvious if someone wants to fix it.  it's clearly unrelated to python3.x since it ftbfs in quantal, and crashes w/2.7
[21:59] <xnox> barry: ack. I think it's fine it's not blocking.