[09:38] <didrocks> hey czajkowski!
[09:38] <didrocks> I keep getting launchpad oooooopses  when trying to create a new project, any idea?
[09:40] <czajkowski> didrocks: hmmm
[09:41] <czajkowski> have you got an oops id
[09:41] <didrocks> sure :)
[09:41] <didrocks> (Error ID: OOPS-29cfc9dfb21844458017fdb290b5fe0f)
[09:41]  * czajkowski stabs 2FA 
[09:42] <czajkowski> one momen till I locate my phone
[09:42] <didrocks> :)
[09:43] <czajkowski> oh
[09:43] <czajkowski> hmmm
[09:43] <czajkowski> didrocks: are you doing something with sharing when you set it up ?
[09:43] <didrocks> czajkowski: sharing meaning license?
[09:43] <didrocks> I just have 2 licenses enabled
[09:44] <didrocks> information type is set to default, public
[09:44] <czajkowski> wgrant: StevenK either of ye about
[09:51] <wgrant> Argh
[09:51] <wgrant> This is exactly what I was worried about
[09:51] <czajkowski> wgrant: I cant create it on qastating either
[09:52] <czajkowski> only I'm getting an different error
[09:52] <czajkowski> wgrant: created it on qastaging
[09:53] <czajkowski> so why cant we do it on lp
[09:53] <wgrant> Because deryck's DB patch is not on qastaging
[09:53] <wgrant> Just staging and production
[09:53] <czajkowski> oh
[09:54] <wgrant> Hm, no adeuring
[09:59] <wgrant> didrocks: The problem is due to a bad database patch. A fix is deploying now, so it should work in 30-60 minutes.
[10:00] <didrocks> wgrant: ok, good luck! keep me posted please :)
[10:16] <didrocks> czajkowski: ah also, Kenneth is not working anymore at canonical and isn't available. Can you please set the pspmteam as a driver for https://launchpad.net/ubuntu-mono? (I'll deprecate this project)
[10:16] <didrocks> and same for https://launchpad.net/ubuntu-artwork
[10:17] <didrocks> (basically ubuntu-themes is merging ubuntu-mono, light-themes and ubuntu-artwork in the same project)
[10:18] <czajkowski> didrocks: just requesting it now
[10:18] <didrocks> thanks :)
[10:19] <czajkowski> didrocks: all done
[10:19] <didrocks> excellent, thanks :)
[10:21] <czajkowski> didrocks: you going to FOSDEM ?
[10:21] <nigelb> czajkowski: I was hoping to make it this year.
[10:21] <nigelb> But, it seems I'll be in UK instead.
[10:21] <nigelb> :(
[10:27] <didrocks> czajkowski: yeah, as every year ;)
[10:27] <didrocks> I need to propose a talk btw…
[10:27] <didrocks> you as well?
[10:28] <czajkowski> I am indeed
[10:28] <czajkowski> seems to be lots of chatter in #fosdem atm
[10:28] <didrocks> ah ;)
[10:28] <czajkowski> not speaking this year although may take part in panel discussion still waiting to hear
[10:50] <didrocks> czajkowski: excellent! worked \o/
[10:50] <czajkowski> yay
[10:52] <didrocks> thanks czajkowski, wgrant :)
[10:52] <wgrant> Great
[10:59] <yolanda> hi, i'm having a timeout problem trying to change the state of a bug, is there any issue?
[11:00] <czajkowski> wgrant: have you broken something with the change
[11:00] <czajkowski> yolanda: do you hvae an oops id
[11:00] <yolanda> yes, let me look at it
[11:00] <czajkowski> we need the oops id when folks say they have a timeout
[11:01] <Daviey> OOPS-a11f46e0ec5c106c13cf03881b348571
[11:01] <yolanda> that one for example: OOPS-a11f46e0ec5c106c13cf03881b348571, but i tried lots of times
[11:01] <yolanda> it fails from API or from the website
[11:03] <czajkowski> I cant even get the oops to open
[11:04] <czajkowski> yolanda: what bug
[11:05] <yolanda> the api showed that: http://paste.ubuntu.com/1425066/
[11:05] <yolanda> and from the website i just see a timeout
[11:06] <czajkowski> yolanda: yes but which bug are you trying to change the status of
[11:06] <yolanda> oh, sorry: https://bugs.launchpad.net/ubuntu/+source/keystone/+bug/1073569
[11:06] <yolanda> i try to change the keystone (Ubuntu) one
[11:07] <czajkowski> from fixed released to?
[11:07] <yolanda> i try to set it as fix released
[11:08] <yolanda> https://bugs.launchpad.net/ubuntu/+source/keystone/+bug/1073569/+editstatus - from new to fix released
[11:09] <czajkowski> ah the oops id loads
[11:09] <czajkowski> I'll file a bug
[11:09] <czajkowski> or see if we have any other similar oops
[11:09] <mgedmin> who can I ping about https://bugs.launchpad.net/udd/+bug/1084522?
[11:10] <czajkowski> mgedmin: I'm just in the middle of something at present
[11:10] <czajkowski> can you give me a few
[11:10] <mgedmin> no rush
[11:10] <mgedmin> the bug's been open for 1.5 weeks, a few more hours won't hurt anyone :)
[11:10] <czajkowski> mgz: ^^^
[11:10] <mgedmin> I just don't want it to be completely forgotten
[11:10] <czajkowski> it's not a LP bug
[11:11] <mgedmin> is there an IRC channel for ubuntu distributed development?
[11:12] <mgedmin> all I know is that bazaar is unable to get a branch from launchpad, so I assumed either it's a bug in bazaar, or a bug in launchpad
[11:13] <wgrant> It's more likely that UDD has somehow caused the bzr branch to be corrupted
[11:14] <czajkowski> wgrant: https://bugs.launchpad.net/launchpad/+bug/1088862  re yolanda and Daviey bug.
[11:14] <czajkowski> oops takes nearly 4 mins to load :/
[11:14] <wgrant> yolanda: Which attributes were you trying to change?
[11:14] <wgrant> Just the status?
[11:14] <yolanda> wgrant, yes, from the keystone(Ubuntu), from New to Fix Released
[11:15] <czajkowski> wgrant: I tried it also and it oops
[11:15] <wgrant> Oh
[11:15] <wgrant> There's like 19 billion people subscribed
[11:16] <wgrant> Because it affects so many projects
[11:17] <czajkowski> wgrant: thought we fixed that timeout
[11:17] <wgrant> Not when they're all different projects.
[11:18] <czajkowski> ugh
[11:24] <yolanda> wgrant, so can you fix that manually maybe?
[11:25] <wgrant> No
[11:26] <yolanda> so what can i do it to change it?
[11:26] <wgrant> Nothing until that bug is fixed
[11:27] <yolanda> ok, just let me know...
[11:27] <czajkowski> yolanda: it's marked as critcal
[11:28] <mgz> mgedmin: http://package-import.ubuntu.com/status/accountsservice.html
[11:28] <czajkowski> and we have about 160 of them at present
[11:29] <yolanda> ok, thanks
[11:30] <mgz> seems the debian packaging has been borked, might need some history blacklisted
[11:32] <mgz> mgedmin: the practical way of getting this fixed is to run the import locally yourself, see what's borked, what needs ommitting to make it work, and then poke someone to make that change on jubany. poke xnox for help maybe, he's worked out that process in the past.
[11:34] <xnox> yeah, I do run "local" importer on my machine for "problematic" packages, helps working out the non-trivial - if i have newer bzr/quilt/pristinetar & skip experimental it works bugs.
[11:34]  * xnox just followed the readme in the importer branch & set it word to word same on my machine.
[11:35] <mgedmin> at this point I suspect it would be simpler for me to use apt-get source and prepare a debdiff manually...
[11:37] <mgedmin> I did the apt-get source bit 1.5 weeks ago, when I filed that bug -- worked fine for me, no failing debian patches, curiously
[11:37] <mgedmin> ah, I got version accountsservice_0.6.21-6ubuntu5, while this failure is for version 0.6.21-4
[11:39] <mgz> right, it's likely they fixed it since then, the importer just wants to grab every package created to build the history, so if something was broken in a suprising way at some point in the past it falls over
[11:44] <mgedmin> I'll update the bug with the explanation
[12:32] <ricotz> hello, there are several armhf ppa builds stuck due the problem with raring
[12:33] <czajkowski> ricotz: which ppas
[12:33] <czajkowski> we've not had complaints from others
[12:33] <wgrant> I only see 3 armhf and 1 armel
[12:34] <wgrant> I've cancelled them
[12:34] <ricotz> czajkowski, i already mention it to infinity and he wants to backport qemu to fix it
[12:34] <ricotz> wgrant, thanks
[12:34] <wgrant> I have an RT open for upgrading qemu
[12:35] <ricotz> wgrant, right, he filed one
[12:36] <ricotz> czajkowski, hi, what is the "offical" policy now to get armhf support?
[12:36] <czajkowski> https://dev.launchpad.net/CommunityARMBuilds
[12:37] <czajkowski> 4hrs or less builds and 10 or less builds a week
[12:38] <ricotz> czajkowski, ok, thanks
[19:18] <shnatsel> hello
[19:18] <shnatsel> I'm trying to build a trivial patch to Qt in Launchpad recipe, but it fails with weird errors, like:
[19:18] <shnatsel> tar: <filename>: Cannot open: Permission denied
[19:18] <shnatsel> here's the full build log: https://launchpadlibrarian.net/125376199/buildlog.txt.gz
[19:19] <shnatsel> the equivalent operations work for me locally (branch, merge, debuild), though take several hours to complete on my machine
[19:19] <shnatsel> is there anything I can do to fix this?
[19:23] <dobey> what is the recipe?
[19:23] <shnatsel> https://code.launchpad.net/~elementary-os/+recipe/qt4-x11-daily
[19:23] <shnatsel> it just alters the debian/control a bit
[19:24] <shnatsel> makes libqt4-gui recommend qt-at-spi and sni-qt I think
[19:24] <shnatsel> and builds that to PPA
[19:24] <shnatsel> the recipe is needed to keep up with any updates ubuntu might release to Qt
[19:25] <shnatsel> technically we have to maintain a custom imports system because Launchpad's branches are months behind the actual code sometimes (and yes I've checked the -updates and -security pockets, they're actually outdated)
[19:26] <dobey> probably due to a bug in UDD
[19:26] <shnatsel> UDD?
[19:27] <dobey> ubuntu distributed development; the thing that does the imports into bzr of packages
[19:28] <shnatsel> Possibly. Last time I talked to somebody about that no cure-all fix for the lag was anticipated. It was roughly a year ago though; things might have changed.
[19:29] <shnatsel> Anyway, what can be wrong with the recipe?
[19:30] <dobey> it seems that perhaps the import of the source package wasn't done quite correctly
[19:30] <dobey> packages are usually imported with patches already applied, in udd at least
[19:31] <dobey> i don't know if that's the problem or not, but it might help
[19:32] <shnatsel> we had to add extra code that unapplies the patches.... I don't remember the exact reason though. Funnily, one such package refused to build locally citing a patching conflict or something like that but builds fine in a recipe!
[19:32] <shnatsel> but Qt code from the imported branch builds locally just fine
[19:33] <shnatsel> I can understand "file not found" errors in tar - definitely my bad. But how "permission denied" can even appear in a recipe build?
[19:34] <dobey> probably because dpkg-source isn't being run with fakeroot, and whatever applied the patches, was?
[19:36] <shnatsel> tar: recipe-{debversion}+elementary{revno\:elementary-patch}/.pc/kubuntu_14_systemtrayicon.diff/src/gui/util/qabstractsystemtrayiconsys.cpp: Cannot open: Permission denied
[19:37] <shnatsel> I think the patches are applied in the recipe source build state, not on the code import stage
[19:38] <dobey> yes, and i am saying that may be the problem
[19:38] <shnatsel> so the paths get hardcoded somewhere?
[19:39] <dobey> what? no
[19:39] <shnatsel> well, uh, I can't see what's the problem with applying patches in recipe source build... isn't that how it's supposed to work?
[19:43] <dobey> shnatsel: you're confusing the creation of a source package, with the building of that into binary packages. technically speaking, the patches should probably get unapplied before dpkg-source, but i am not sure why they're being applied at all here, as they're getting applied before build-depends are installed.
[19:43] <dobey> shnatsel: also, if you mean "debuild" by "works locally" you're not building the recipe. does "bzr dailydeb" work with the recipe?
[19:44] <shnatsel> dobey: I don't have the setup for building recipes locally yet but I'll install it today and try again
[19:44] <shnatsel> dobey: yes, our importer does unapply the patches before pushing the code to a branch.
[19:45] <shnatsel> dobey: oh wait! I've just remembered a workaround for this!
[19:46] <shnatsel> dobey: I've seen it on another branch but never looked into it
[19:47] <shnatsel> here it is: http://bazaar.launchpad.net/~elementary-os/elementaryos/os-patch-xdg-user-dirs-precise/revision/3
[19:47] <shnatsel> I think it will fix that.
[19:47] <shnatsel> dobey: thanks a lot for your time!
[19:47] <shnatsel> s/time/help/
[19:49] <dobey> oh; actually, the correct fix is probably to change debian/source/format to 3.0 (native)
[19:50] <dobey> the recipe builder doesn't like 3.0 (quilt) (and i'm not entirely sure why)
[19:51] <shnatsel> I think it actually is (native), I saw that in the log
[19:51] <shnatsel> I think
[19:51] <shnatsel> let me check...
[19:51] <micahg> doing .tar-ignore=.pc is probably not a good idea, you have the patches applied with no evidence that they are
[19:52] <dobey> and yeah, what micahg just said
[19:53] <dobey> shnatsel: looks like qt is 3.0 (quilt) to me
[19:54] <shnatsel> dobey: in the branch it is but I'm dead sure I just saw it show "3.0 (native)" in some log and was mighty surprised by that
[19:54] <shnatsel> yes!
[19:54] <shnatsel> dpkg-source: info: using source format `3.0 (native)'
[19:54] <shnatsel> https://launchpadlibrarian.net/125376199/buildlog.txt.gz
[19:55] <shnatsel> while the debian/source/format specifies "3.0 (quilt)"
[19:55] <shnatsel> how can that be?
[19:57] <dobey> install bzr daily-deb, make a .txt file with the contents of the recipe, and bzr dailydeb recipe.txt and see what happens. then change it to 3.0 (native) in your merged-in branch, and run dailydeb again locally and see what happens
[20:02] <shnatsel> that's gonna take at about 8 hours
[20:02] <shnatsel> is it really necessary for debugging the issue? let me see if I have a smaller branch for that...
[20:06] <dobey> why would that take 8 hours?
[20:06] <dobey> are you on 56kbps dial-up?
[20:25] <shnatsel> no, but compiling Qt is not that fast even on my fairly recent CPU
[20:25] <shnatsel> thought it uses only one core
[20:27] <dobey> bzr dailydeb doesn't build qt
[20:28] <shnatsel> oh great, will do then, as soon as I find the right package to install
[20:28] <dobey> it will build the orig.tar.gz debian.tar.gz .dsc, and  _source.changes files
[20:28] <dobey> bzr-builder is the package
[20:29] <shnatsel> thanks!
[20:43] <shnatsel> dobey: looks like I've nailed it
[20:43] <shnatsel> bzr: ERROR: Unable to find the upstream source. Import it as tag upstream-4.8.1 or build with --allow-fallback-to-native.
[20:44] <dobey> ah do bzr dailydeb --allow-fallback-to-native
[20:44] <dobey> pretty sure the build server does that
[20:44] <shnatsel> Launchpad builds it successfully, so I assume it passes --allow-fallback-to-native and that changes the format
[20:52] <dobey> shnatsel: that's probably where the "3.0 (native)" came from, but I think it breaks if you're using "3.0 (quilt)" and actually have patches being applied
[20:55] <shnatsel> dobey: dailydeb built OK with current branches
[20:56] <shnatsel> but it does in launchpad too
[20:56] <shnatsel> let me change that to native in the branch
[20:57] <dobey> what do you mean it does in lp too? i thought it was failing
[20:57] <shnatsel> oh wait
[20:58] <shnatsel> let me check again if it's source or binary which fails...
[20:58] <shnatsel> dobey: sorry, it's source which fails
[20:58] <dobey> on lp it was the source failing
[20:58] <shnatsel> dobey: and it worked OK locally
[21:03] <dobey> bzr: ERROR: Invalid deb-version: {debversion}+elementary2: Invalid version string '{debversion}+elementary2'
[21:03] <shnatsel> dobey: both work fine locally
[21:03] <dobey> i got that trying to build your recipe
[21:03] <shnatsel> # bzr-builder format 0.3 deb-version {debversion}+elementary{revno:elementary-patch}
[21:03] <shnatsel> huh
[21:05] <shnatsel> dobey: that's weird, it works for me on Precise with latest updates
[21:06] <dobey> i'm on quantal
[21:06] <shnatsel> oh wait, disregard the "native" test, it was not committed
[21:06] <shnatsel> retrying
[21:06] <dobey> but anyway
[21:06] <shnatsel> it surely works with "quilt" for me
[21:08] <shnatsel> dobey: the "invalid deb-version" looks like a regression-release to me
[21:13] <shnatsel> so changing the format to native in the source code didn't change anything indeed; it still works locally for me
[21:14] <shnatsel> so Launchpad failures looks like a bug in builder to me
[21:18] <dobey> well, like i said, the patches are being applied as root, before the build-depends are installed, and dpkg-source isn't being run as root
[21:18] <dobey> this is your problem
[21:18] <dobey> and afaict, switching to 3.0 (native) should fix that
[21:18] <shnatsel> dobey: it already builds as native it seems
[21:19] <dobey> granted, i have no idea why the patches are even being applied at the point they are
[21:19] <dobey> shnatsel: not quite
[21:20] <shnatsel> dobey: okay. Shall I file a bug about this? it's not uncommon and should not result in a debugging session every time it happens
[21:20] <shnatsel> dobey: also, is replacing "quilt" with "native" cleaner than tar-ignoring .pc ?
[21:20] <dobey> yes
[21:21] <shnatsel> dobey: yes to which question? :D
[21:21] <dobey> see the comment micahg made ~1.5 hrs ago
[21:21] <shnatsel> I'm sorry I post them so fast XD
[21:21] <dobey> yes tar-ignoring .pc is bad
[21:21] <dobey> i don't know about filing a bug
[21:21] <dobey> it's not a bug in bzr-builder, if that's what you're asking
[21:22] <shnatsel> well, bzr-builder works locally, so... (though on Quantal it doesn't it seems)
[21:22] <shnatsel> perhaps some kind of bug tracker for launchpad builders infrastructure?
[21:23] <dobey> whyever it's not working for me is unrelated
[21:23] <dobey> i don't think there is a bug tracker specifically for builder issues
[21:23] <dobey> there is just the launchpad bug tracker
[21:23] <dobey> (https://bugs.launchpad.net/launchpad)
[21:24] <dobey> though i'm pretty certain if you fix the source/format to be (native) it will fix the problem for you
[21:25] <shnatsel> okay, let's see... I have a smaller branch affected by this problem, I'll try using native instead of ignoring .pc
[21:26] <dobey> ah i have to go right now
[21:27] <shnatsel> dobey: thanks a lot for the help!
[21:27] <shnatsel> dobey: goodbye :)