[03:51] <luk3yx> Should questions about staging.launchpad.net be asked here or somewhere else?
[04:21] <wgrant> luk3yx: Here is fine.
[04:21] <luk3yx> How long does it take for it to clone a git repo?
[04:22] <wgrant> luk3yx: staging.launchpad.net doesn't have git support today. What are you doing with it?
[04:23] <luk3yx> I was trying to clone a git repository to test the snap building feature.
[04:23] <wgrant> staging can only upload to the staging snap store, which you can't install from unless you build a custom snapd. You probably want to use production for that instead.
[04:24] <wgrant> staging's better if you're testing scripts to manipulate lots of bugs, or do other things that might disrupt other users.
[04:24] <luk3yx> Oh, okay.
[04:24] <luk3yx> Thank you.
[04:25] <luk3yx> What's https://qastaging.launchpad.net/?
[04:27] <wgrant> luk3yx: It's like staging... except different. It runs a different branch of the code, and is mostly used by us for QA purposes. But it does have git support.
[04:27] <luk3yx> Oh, okay.
[04:27] <luk3yx> How often are the staging ones reset?
[04:29] <wgrant> staging is reset weekly. qastaging is reset when we feel like it.
[04:29] <luk3yx> Okay.
[04:30] <luk3yx> Thank you for your help.
[04:30] <wgrant> np
[04:31] <luk3yx> How long does qastaging take to clone a git repo?
[09:41] <cjwatson> luk3yx: That's a bit of a "how long is a piece of string" question.  What repository in particular?  Do you mean that you're trying to set up a code import?
[09:46] <alkisg> Hi, I tried copying to packages from one PPA to another, and I got some launchpad error mails. Now it's been stuck at either building or pending to be published, for 1 hour or so. Should I just wait, or should I report the issue?
[09:46] <alkisg> https://launchpad.net/~ts.sch.gr/+archive/ubuntu/ppa/+packages?field.name_filter=java8&field.status_filter=published&field.series_filter=
[09:46] <alkisg> *s/to/two
[09:55] <cjwatson> alkisg: It's backed up due to a particularly large rebuild in one PPA, but it'll get there eventually.
[09:56] <alkisg> cjwatson: so no action needed on my part, thank you
[09:56] <cjwatson> Indeed.
[14:54] <jorgesumle> I want to submit a bug to Launchpad, but I can't because I cannot validate my Ubuntu One account. Can someone do it for me?
[14:56] <cjwatson> What goes wrong when you try to validate it?
[14:57] <jorgesumle> I need to complete a CAPTCHA, but it doesn't appear when JavaScript is disabled
[14:57] <jorgesumle> I surf the web with JS disabled because of privacy.
[14:57] <jorgesumle> The bug should be sent here: https://bugs.launchpad.net/midori
[14:58] <jorgesumle> Here it is the bug report, you just have to copy and paste: https://paste.debian.net/955781
[14:58] <jorgesumle> I would be very helpful if someone could fill it for me :)
[14:58] <rbasak> I have a separate browser profile for stuff like this. Its set to clear everything on exit - basically private browsing mode. I don't believe there's any realistic loss in privacy by jumping in there to do the odd task like this.
[14:59] <cjwatson> We aren't likely to drop the captcha requirement; it's an important spam defence.
[15:01] <jorgesumle> I'm not asking you that, I just asked for someone to take 30 secs to help me fill a bug report. Though it would be an improvement if the CAPTCHA would work with JS disabled.
[15:02] <cjwatson> I'm afraid I don't file bugs on other people's behalf because that breaks the ability for developers to contact the bug reporter.
[15:05] <Mc> I thought midori just uses webkit
[15:07] <cjwatson> From https://developers.google.com/recaptcha/docs/faq it looks like we can only support non-JS signups by weakening security, and our spam situation is already bad enough, sorry :(
[15:09] <jorgesumle> There is an IRC channel called #midori, I'm also trying there. Thanks for your responses.
[16:39] <bdmurray> cjwatson: I've also been encountering some more LP OOPSes recently e.g. https://oops.canonical.com/?oopsid=OOPS-fbdcf5eec6283761189e84d5d66da7ba
[16:58] <cjwatson> bdmurray: That looks worth filing a bug on: we appear to be spending at least a second on lots of per-bug queries that could almost certainly be done in bulk instead.
[17:00] <bdmurray> cjwatson: okay
[18:44] <sergio-br2> hi
[18:45] <sergio-br2> how do I workaround "virtual memory exhausted: Operation not permitted" in launchpad i386 builds?
[18:45] <sergio-br2> trying building mame there...
[18:45] <cjwatson> The usual approach is to reduce your build's parallelism level
[18:45] <cjwatson> Also worth looking into various memory-saving linker options
[18:45] <sergio-br2> 	dh $@ --parallel
[18:45] <sergio-br2> hummm
[18:46] <sergio-br2> removing that will take a lot of time to build heh
[18:46] <cjwatson> there's a --max-parallel option.  see debhelper(7)
[18:46] <sergio-br2> let's see
[18:46] <cjwatson> so you could e.g. try --max-parallel=2
[18:47] <sergio-br2> what's the maximum used in launchpad farm?
[18:47] <cjwatson> the builder VMs have 4 VCPUs, so --parallel will default to that
[18:47] <sergio-br2> ok, let's see if it works
[20:45] <sergio-br2> didn't work, let's see without --parallel
[21:46] <sergio-br2> didn't work either cjwatson
[21:47] <cjwatson> sergio-br2: 19:45 <cjwatson> Also worth looking into various memory-saving linker options
[21:47] <cjwatson> sergio-br2: but I'm sorry, I can't really debug your build for you, only make general suggestions.
[21:48] <cjwatson> sergio-br2: https://launchpad.net/ubuntu/+source/mame appears to build fine on i386 so you should look at what it does; I see at least one memory-saving tweak in debian/rules there.
[22:01] <sergio-br2> ahh, true
[22:01] <sergio-br2> #export DEB_LDFLAGS_MAINT_APPEND = -Wl,--no-keep-memory
[22:01] <sergio-br2> let's see there
[22:05] <cjwatson> Doesn't look like it's your linker step that's failing, so you might need to look into other flags there.  I didn't look very hard.
[22:46] <sergio-br2> cjwatson, does launchpad farm use swap?
[23:08] <cjwatson> sergio-br2: 4GiB swap IIRC
[23:08] <sergio-br2> wut
[23:08] <sergio-br2> man, mame became a huge monster heh
[23:08] <cjwatson> sergio-br2: Not that that's relevant to "virtual memory exhausted".
[23:09] <sergio-br2> isn't it using swap in the build?
[23:10] <sergio-br2> virtual memory = RAM + swap ?
[23:12] <nacc> RAM + swap would be more like physical memory, sort of
[23:12] <cjwatson> sergio-br2: You get that error when you try to allocate more than will fit in your process' address space.
[23:12] <nacc> sergio-br2: virtual memory is more about the addressable memory (so exceeding 2^32)
[23:13] <sergio-br2> 2^32 = 4 GB right
[23:13] <cjwatson> Possibly even 3GiB on i386, I forget.  At any rate it's not relevant how much RAM+swap is available beyond that, in this case.
[23:13] <sergio-br2> 3 GB in PC arch
[23:14] <nacc> cjwatson: good point, it's not quite 4GB
[23:14] <cjwatson> Note that the amd64 builders are exactly the same VMs.
[23:14] <sergio-br2> yeah, I forgot this detail, too much used to amd64