[00:07] <maxb> Well, the idea is that it's a string that should effectively be treated as opaque by all users, it just happens to contain some semantic info to make it useful to people debugging weirdness at low levels
[00:07] <maxb> It could pretty much just as well be a UUID, or other randomly assigned constant
[07:25] <kamstrup> Are there some LP admins that can help me out here? When I try to log into LP I get an error page saying "Your login was unsuccessful: User cancelled"
[07:26] <kamstrup> been getting that for over a month
[07:29] <wgrant> kamstrup: Have you tried an alternate browser? What's the URL that gives the error?
[07:30] <kamstrup> wgrant: yeah, tried using chromium with completely wiped settings as well, same problem
[07:31] <kamstrup> wgrant: https://launchpad.net/+openid-callback?starting_url=https%3A%2F%2Flaunchpad.net&janrain_nonce=2012-10-04T07%3A31%3A09ZVHoqlK&openid.mode=cancel&openid.ns=http%3A%2F%2Fspecs.openid.net%2Fauth%2F2.0
[07:33] <wgrant> kamstrup: Hm. What does https://login.launchpad.net/ say?
[07:33] <wgrant> Since that URL is pretty clear about the OpenID provider cancelling the request
[07:34] <kamstrup> wgrant: interesting - that says I am logged in - but LP begs to differ
[07:34] <kamstrup> I can change my pw there, see which sites I am authenticated to
[07:59] <dupondje> http://launchpadlibrarian.net/115453173/freerdp-team-freerdp-freerdp.log
[07:59] <dupondje> 2012-09-11 04:00:03 INFO    The repository you are fetching from contains submodules, which are not yet supported.
[07:59] <dupondje> but this doesn't seem to be the case?
[08:00] <dupondje> see https://code.launchpad.net/~freerdp-team/freerdp/freerdp
[08:00] <jelmer> dupondje: perhaps there are submodules somewhere in the history?
[08:02] <wgrant> https://github.com/FreeRDP/FreeRDP/commit/e4e6fb48370ef7476a416d490c97fae67ff1dd75 looks suspicious
[08:03] <dupondje> indeed :(
[08:03] <dupondje> already has been removed tho
[08:03] <dupondje> no way to get it fixed?
[08:03] <wgrant> Not without rebasing the commit out of the upstream repo
[08:05]  * dupondje is not really a GIT specialist :)
[08:15]  * dupondje is thinking how to fix it cleanly :)
[15:38] <doko> looking at bug #1058056
[15:38] <doko> this shows up as wontfix in the overview list, however it is confirmed. why?
[15:38] <doko> lifeless, whoever, any idea?
[15:41] <lifeless> conjoined master with mismatched state
[15:41] <lifeless> another reason why they are evil
[15:42] <lifeless> at a guess anyhow
[15:42] <lifeless> I have to sleep,s orry.
[15:42] <lifeless> night
[16:02] <Darxus> /bin/bash ../libtool  --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. -I..     -g -O2 -Wall -fno-strict-aliasing -fvisibility=hidden -MT pixman-implementation.lo -MD -MP -MF .deps/pixman-implementation.Tpo -c -o pixman-implementation.lo pixman-implementation.c
[16:02] <Darxus> pixman-combine-float.c: In function 'combine_exclusion_u_float':
[16:02] <Darxus> pixman-combine-float.c:485:1: sorry, unimplemented: inlining failed in call to 'combine_exclusion_a': function not considered for inlining
[16:02] <Darxus> Wrong channel, sorry.
[18:04] <pindonga> hi, I was wondering if we had any ETA on getting staging LP back up.
[19:20] <sinzui> pindonga, use https://qastaging.launchpad.net/ . It is up more often, but the data is from 6 months ago.
[19:22] <pindonga> sinzui: not sure I can tbh... we're doing integration testing for Ubuntu Pay, which requires talking to Software Center Agent , which talks to Staging LP
[19:22] <pindonga> so until staging LP is back up we can't release to production (our own fault probably)
[19:23] <pindonga> I was wondering how come LP staging takes so long to deploy when you guys have FDT deploys now on prod
[19:25] <sinzui> pindonga, I have no idea. It might be that the db did not restore properly from last weekend.
[19:26] <sinzui> pindonga, webops are sprinting, but if you really need that server up, ping them on #launchpad-ops and they might be able to make it run
[19:26] <czajkowski> it's been down for some time
[19:27] <pindonga> sinzui: thank you
[21:55] <SpamapS> I have a PPA build that is failing where a local sbuild with networking disabled does not. Anybody have an idea how I can debug this? https://launchpad.net/~juju/+archive/pkgs/+build/3877229
[21:55] <SpamapS> the test suite fails in odd ways that I'm unable to reproduce at all
[22:20] <wgrant> SpamapS: Your sbuild is fully upgraded?
[22:20] <wgrant> SpamapS: There was a python security update a couple of days ago
[22:20] <wgrant> Oh, but this is quantal, hmm.
[22:21] <SpamapS> wgrant: its failing the same way on oneiric <-> quantal
[22:21] <SpamapS> wgrant: and yes I've fully updated my chroots
[22:22] <SpamapS> wgrant: I do see some minor differences in the build-dep install step
[22:23] <SpamapS> wgrant: is it possible chroots built with mk-sbuild have different stuff installed than the buildd chroots?
[22:24] <wgrant> SpamapS: You can grab the buildd chroot from https://launchpad.net/api/devel/ubuntu/quantal/i386
[22:26] <SpamapS> I suppose with that I can at least try the same command line
[22:26] <SpamapS> doh
[22:26] <SpamapS> some kind of timeout/race
[22:26] <wgrant> For sbuild? No
[22:26] <SpamapS> retrying 3 times succeeded on precise
[22:50] <SpamapS> wgrant: thanks for the info. I think its juju's test suite failing on some races