[00:00] <veebers> is ssh preferable/more stable?
[00:12] <lifeless> veebers: ssh is more efficient
[00:12] <lifeless> veebers: if you have network issues of anysort it would be better.
[00:12] <veebers> lifeless: cool, thanks
[00:13] <veebers> I'm not sure why I received the 2 different errors
[00:13] <lifeless> we had an issue with http earlier today.
[00:13] <lifeless> You may have been using it at the time.
[00:15] <veebers> ahh ok, that would explain that
[00:36] <GriffenJBS> any way to pull a tarball of files out of launchpad?
[00:36] <lifeless> wget
[00:42] <GriffenJBS> lifeless: ... you made me feel really stupid.
[00:42] <GriffenJBS> thanks for the help
[00:42] <lifeless> GriffenJBS: sorry!
[00:43] <GriffenJBS> don't be, I wasn't thinking
[00:43] <lifeless> ah, no worries then :)
[00:43] <GriffenJBS> I looked at launchpad and saw bazaar everywhere was was thinking it was needed
[00:44] <GriffenJBS> I can wget -r the files, I would like to have it compressed on host then transfered, but I just need the files
[00:45] <wgrant> GriffenJBS: A URL like http://bazaar.launchpad.net/~loggerhead-team/loggerhead/trunk-rich/tarball will give you a tarball
[00:48] <GriffenJBS> oh nice, wget didn't work, and the compression is possible
[00:49] <GriffenJBS> wget checks robots.txt which disallows everything
[00:51] <ajmitch> you can use wget -e robots=off
[00:52] <GriffenJBS> ajmitch: the manual makes no mention of that
[00:52] <ajmitch> no, the manpage doesn't list every option
[00:55] <GriffenJBS> I got the files, wgrant, the tarball url worked like a charm
[01:00] <lifeless> yeah, recursive wget does the right thing; using robots=off would likely be detected and your ip blocked :P
[01:01] <ajmitch> blocked if it's just a single url being fetched, or does wget not look up robots.txt for that?
[01:01] <lifeless> wget -r obeys robots
[01:01] <lifeless> wget URL doesn't.
[01:01] <ajmitch> right
[01:01] <ajmitch> then don't ignore robots.txt with -r, otherwise angry ops hunt you down :)
[11:14] <ricotz> could someone please restart this freezed build? https://launchpad.net/~ricotz/+archive/staging/+build/3738707
[11:14] <ricotz> bigjools, hi :) ^
[11:16] <czajkowski> ricotz: patience
[11:16] <czajkowski> I'm just asking
[11:16] <czajkowski> asked
[11:17] <ricotz> czajkowski, sorry, thanks
[11:19] <ricotz> czajkowski, jfyi, this freeze is happening quite often on some (i think, newer) i386 builders since the move of launchpad
[11:19] <czajkowski> ricotz: yes there was a backlog since the move
[11:39] <ricotz> czajkowski, sorry for bothering, is there any progress?
[11:45] <ricotz> hmm, the build is now cancelled which i could have done myself :\
[11:46] <ricotz> sorry, i need to run
[12:47] <serg> hi. our repository looks corrupted:
[12:47] <serg> $ bzr branch lp:maria/5.1
[12:47] <serg> bzr: ERROR: No such file: '/srv/bazaar.launchpad.net/mirrors/00/05/62/51/.bzr/repository/indices/b658cec5bdb393a80d29dc
[12:47] <serg> what could I do?
[12:47] <jelmer> serg: is that the entire error?
[12:48] <mgz> jelmer: I guess the useful part would be in the smart server log anyway...
[12:48] <mgz> (rather than on the client)
[12:48] <serg> yes. it's the error when I run bzr in a local shared repo. If I run it in an emtry directory it's an python exception
[12:49] <serg> that still boils down to a missing file up the stack trace
[12:50] <serg> bzr: ERROR: bzrlib.errors.ErrorFromSmartServer: Error received from smart server: ('NoSuchFile', '/srv/bazaar.launchpad.net/mirrors/00/05/62/51/.bzr/repository/indices/b658cec5bdb393a80d29dc93e9c94ea3.rix')
[12:52]  * serg notices that the first error message, was indeed, truncated. "...93e9c94ea3.rix" was missing
[12:55] <mgz> serg: so, the lo-fi way of fixing this would be for someone who has 5.1 to push it up to a new branch stacked on maria, then do a switcheroo
[12:55] <mgz> provided that works.
[12:55] <serg> that probably would. 5.2 branch works ok and it's stacked on maria too
[12:56] <serg> but I'll loose all subscribers and I don't know what else
[12:56] <serg> but if it's the only solution, I'll do that, of course
[12:57] <mgz> ah, hold that for a sec
[12:57] <mgz> the branch is listed as stacked on 5.3?
[12:58] <mgz> that does not sound right, perhaps the stacking just needs resolving
[12:58] <mgz> ...they were created at about the same time by you though...
[13:00] <serg> and it's me who actually broke 5.1 branch. I pushed, it hanged (this happens, rarely), I ^C, broke the lock. And the branch is broken.
[13:01] <mgz> ...that's not good, seeing the server log from that operation would be nice
[13:01] <mgz> but probably some odd stacking interaction
[13:02] <serg> ok, I'll recreate it, then :(
[13:03] <mgz> what do you have in .bzr/repository/indices locally for that branch?
[13:04] <wgrant> serg, mgz: I'd recommend moving the .bzr away and pushing with --use-existing-dir
[13:04] <wgrant> Rather than deleting the branch and the metadata and blah
[13:05] <czajkowski> https://answers.launchpad.net/launchpad/+question/206528  is serg question on LP
[13:05] <wgrant> This'll preserve the stacking relationships and merge proposals and subscriptions and blah
[13:05] <serg> mgz: it's a shared repo.
[13:05] <serg> wgrant: what do you mean "moving the .bzr away" ?
[13:05] <wgrant> Rename .bzr on the server to some other permitted name (like backup.bzr)
[13:05] <mgz> serg: a hack with sft
[13:05] <wgrant> So you can push up a clean copy of the branch
[13:06] <mgz> *sftp
[13:06] <wgrant> Into the existing branch on Launchpad
[13:06] <serg> oh. interesting
[13:06] <mgz> which lets you poke the contents of .bzr directly
[13:06] <mgz> wgrant is right that just wiping then pushing fresh is probably safest as stacking complicates things
[13:07] <wgrant> Well, "wiping" except with a backup so we can recover the old one if something goes wrong :)
[13:07] <mgz> so... you need to do this yourself (as we don't have access to the branch), but in short
[13:09] <serg> wgrant: thanks! very useful, I could've used it earlier too, we had problems before (but nothing that bad)
[13:09] <czajkowski> serg: can we close your question on LP so ?
[13:10] <serg> hmm. I got permission denied when I tried to rename
[13:10] <mgz> `sftp serge@bazaar.launchpad.net:~maria-captains/maria/5.1`
[13:10] <mgz> then rename to er... needs to be a specific thing, just checking
[13:11] <wgrant> ALLOWED_DIRECTORIES = ( '.bzr', '.bzr.backup', 'backup.bzr', 'backup.bzr.~1~', 'backup.bzr.~2~',
[13:11] <serg> czajkowski: 1 min. I'll close it myself when I'll fix it. by the way, do you want me to put this trick in the answer? or better not?
[13:11] <mgz> backup.bzr
[13:11] <mgz> right, what wgrant said :)
[13:11] <czajkowski> serg: up to you
[13:11] <serg> got it, thanks!
[13:12] <serg> thanks! worderful!
[13:12] <serg> czajkowski: I'm closing it now
[13:27] <ricotz> czajkowski, hi, are you still around?
[13:32] <ricotz> since the mentioned build was canceled which i was told can't the restarted from this state, i uploaded a new build which got stuck too https://launchpad.net/~ricotz/+archive/staging/+build/3738754
[13:34] <czajkowski> hmm another one
[13:34] <czajkowski> wgrant: any ideas
[13:34] <czajkowski> as now I'm confused
[13:35] <ricotz> e.g. this one worked https://launchpad.net/~ricotz/+archive/staging/+build/3737282
[13:37] <ricotz> the problem might be that the g-ir-scanner is requested to initialize clutter and xthreads where some builders running into problems it seems
[13:38] <ricotz> i can cancel and upload new build over and over again until it works, but i dont like this idea, so i asked to restart this specific build to avoid a rebuild of the amd64 packages
[13:39] <ricotz> so please don't just cancel it again ;)
[13:39] <czajkowski> ricotz: I didnt cancel it, I requested it to be restarted!
[13:40] <ricotz> hmm, looks canceled to me :\ https://launchpad.net/~ricotz/+archive/staging/+build/3738707
[13:40] <czajkowski> yes it was but that wasn't what I requested
[13:40] <czajkowski> and I'm also no tthe one who did it.
[13:40] <czajkowski> mgz: can you please help out
[13:40] <czajkowski> thanks
[13:40] <mgz> request to restart = cancel current, start again, no?
[13:41] <ricotz> czajkowski, alright, just saying
[13:41] <ricotz> at least i was told there is no going back from "cancel"
[13:42] <ricotz> not sure if that changed recently
[13:45] <mgz> so, how do we know the 3738754 build has hung?
[13:46] <mgz> just that it should have progressed by now?
[13:46] <ricotz> mgz, trust me i know
[13:47] <ricotz> mgz, i already waited out some of those
[13:55] <mgz> okay, so gumiho hasn't managed to do anything for two hours
[14:07] <mgz> ricotz: so, the builder is doing work, but not obviously getting anywhere
[14:08] <mgz> inside the /usr/bin/g-ir-scanner process from the log, is running `python /usr/bin/check-implicit-pointer-functions --inline --warnonly`
[14:08] <mgz> but that's not a complicated looking script
[14:10] <ricotz> mgz, are you able to gdb this process and send a SIGSEGV?
[14:10] <mgz> so, it's not clear whether the builder is at fault somehow, or the build script is unreliable
[14:10] <mgz> we could, though getting a dump off the builder is a bit of a fag
[14:11] <ricotz> i see
[14:13] <ricotz> mgz, can you paste the versbose log somewhere?
[14:13] <mgz> will have a look now, best guess is an io deadlock of some kind
[14:14] <ricotz> while it works on some builders, something is different then with e.g. this one
[14:14] <mgz> active process from the build is lt-ClutterGst-2.0
[14:15] <ricotz> yeah, that is the one trying initialize clutter and X
[14:15] <ricotz> which should just fail and still work
[14:25] <mgz> ricotz: so, stracing that process had the side effect of breaking the loop, so you can now see the full build log
[14:28] <mgz> ricotz: and a chunk of the strace <http://pastebin.ubuntu.com/1162745/>
[14:30] <mgz> basically seems to be cloning, communicating a bit, waiting for child to exit, repeat
[14:31] <mgz> and gumiho is now successfully building other things, so probably out of the blame
[14:31] <mgz> the build log <https://launchpadlibrarian.net/113396105/buildlog_ubuntu-quantal-i386.clutter-gst-2.0_1.9.90-0ubuntu1~12.10~ricotz3_FAILEDTOBUILD.txt.gz>
[14:45] <ricotz> mgz, thanks, i copied the logs
[14:45] <ricotz> mgz, i will just restart it and hoping for a working builder
[14:47] <mgz> ^actually, build just got killed after 150mins, missed that in the log
[14:48] <mgz> ricotz: so, my point is it's probably not a working builder you're hoping for, but the luck to avoid a race/loop in your package's build process
[14:49] <mgz> the builders are pretty much homogeneous
[14:52] <ricotz> mgz, alright, thanks for your time
[14:52] <ricotz> i might be back ;)
[14:52] <mgz> :)
[20:35] <tsmith-away> how do i create a release for my project??? I CANNOT figure this out and have thoroughly googled.
[20:35] <tsmith-away> The project is https://launchpad.net/phpu-training/
[22:12] <cmars232> hi, quick question about the launchpad builders... would they block a build from downloading additional sources from bzr, hg, git, etc?
[22:12] <cmars232> my build does this and it seems to have timed out
[22:12] <cmars232> https://launchpadlibrarian.net/113443191/buildlog_ubuntu-precise-i386.hockeypuck_0.1~alpha_FAILEDTOBUILD.txt.gz
[22:14] <maxb> cmars232: The builders permit no internet access
[22:14] <cmars232> maxb: bummer
[22:14] <cmars232> maxb: thanks
[22:14] <maxb> This is entirely deliberate, to enforce that the source package is actually a complete representation of what you need to build the package
[22:16] <cmars232> the source package builds, it's just that the language tools are able to provision all the deps
[22:16] <cmars232> they're not debian packaged
[22:16] <cmars232> becoming a maintainer of all of the deps would be ... cumbersome for a developer
[22:17] <cmars232> maybe i could put all the deps in the source tarball?
[22:17] <cmars232> is there a limit on source tarball size?
[22:26] <maxb> I don't believe so
[22:26] <maxb> You're unlikely to beat libreoffice, anyway :-)
[22:30] <cmars232> maxb: haha, thanks