[00:13] <sergio-br2> ugh, didn't work
[00:13] <sergio-br2> why it was working with gcc 4.9.2, but not with 4.9.3
[00:14] <sergio-br2> 4.9.2-0ubuntu1~14.04
[01:06] <sergio-br2> damn launchpad
[01:11] <sergio-br2> damn apt
[01:11] <sergio-br2> I just installed the gcc for dolphin ppa, with 4.9.3
[01:11] <sergio-br2> and i can't install the packages
[01:11] <sergio-br2> it asks to remove a bunch of packages
[01:12] <sergio-br2> or conflicts
[01:13] <sergio-br2> it's just a bug fix update 4.9.2 --> 4.9.3
[01:13] <sergio-br2> never saw something like that
[01:18] <sergio-br2> why that didn't happened with 4.9.2, from the same toolchain ppa?
[01:21] <sergio-br2> ok, I just deleted the 4.9.3
[01:21] <sergio-br2> it's possible to put the 4.9.2 again in the ppa right? (i deleted it too...)
[01:50] <sergio-br2> "You should not attempt to use deletion requests to re-upload the same source version with different contents, as this is still prevented even after the content has been deleted. "
[01:50] <sergio-br2> oh man
[01:50] <sergio-br2> I really need to re-upload gcc 4.9.2 in that ppa
[01:51] <sarnold> even though the archive is very picky about that, _copying_ from one ppa to another ought to work
[01:51] <sergio-br2> can someone help me here?
[01:51] <sarnold> it's building that it refuses to do
[01:51] <sergio-br2> humm
[01:53] <sergio-br2> I hope it works
[01:53] <sergio-br2> launchpad should be less pick about this
[01:56] <sergio-br2> yay seems it worke
[01:59] <sergio-br2> thanks sarnold
[02:05] <sarnold> the 4.9.2 copies?
[02:05] <sarnold> is your build underway? o rjust the copy worked? heh
[02:09] <sergio-br2> yeah, it copied
[02:09] <sergio-br2> it's pending yet
[10:05] <morphis> I am currently trying to register a launchpad project with the name 'wds', however I always get from launchpad "wds is already used by another project"
[10:05] <morphis> I've searched for a project with the name 'wds' on launchpad but couldn't find one
[10:06] <morphis> even the url https://launchpad.net/wds is not used by anything
[10:06] <morphis> there is also no source package with that name either in debian or ubuntu
[10:06] <morphis> anyone has an idea what else could it be?
[11:02] <cjwatson> wxl: Launchpad has private branches, but it's a paid commercial feature.
[11:04] <cjwatson> morphis: It's an old inactive project.  File a question on https://answers.launchpad.net/launchpad explaining the situation and we'll see what we can do.
[11:04] <cjwatson> morphis: (i.e. it is used, you just can't see it)
[11:39] <morphis> cjwatson: thanks, will do that
[11:52] <Odd_Bloke> So I'm trying to create OAuth configuration to put on a Jenkins system, but passing consumer_name to Launchpad.login_with doesn't seem to stop it using "System-wide: Ubuntu (<my local hostname>)" as the consumer.
[11:53] <Odd_Bloke> I also don't want to run it on the system in question, because we'll use the same credentials across multiple slaves, and having a specific hostname there will probably lead to confusion.
[11:58] <Odd_Bloke> Hmm, looking at the launchpadlib code, I don't have much choice in the matter.
[11:58] <Odd_Bloke> Unless I want to delve in to the API more than I want to.
[12:01] <cjwatson> It has to be a subclass of lazr.restfulclient.authorize.oauth.Consumer, I believe, not just a string.
[12:02] <cjwatson> Er, an instance of, I mean.
[12:03] <cjwatson> Consumer("Your consumer name", application_name="Your application name") should do; you can leave out application_name if it's fine for it to be the same as the consumer name.
[12:03] <cjwatson> (application_name goes in User-Agent)
[12:03] <cjwatson> I don't know the OAuth stuff very well, but this doesn't seem to be very much delving into the API.
[12:13] <Odd_Bloke> cjwatson: Aha: http://bazaar.launchpad.net/~lazr-developers/launchpadlib/trunk/view/head:/src/launchpadlib/credentials.py#L615
[12:15] <Odd_Bloke> So I'll just do a system-wide integration on one of the slaves and live with the potential confusion.
[12:25] <cjwatson> Odd_Bloke: Ah, true, you'd need to pass an authorization_engine, which gets a bit more complicated.
[12:31]  * xnox recalls there were two types of tokens "system-wide" and "ad-hoc" one. With one type, one gets to set time limits, with the other one access permissions (e.g. read-only, write, write-private, etc.)
[12:31] <xnox> and it did depend on the magic consumer name.
[12:32]  * xnox is sure i have used straight oauthlib before to get both types of launchpad tokens, bypassing launchpadlib. (when i was trying to write a minimal wadlwalker in python3, instead of porting launchpadlib to python3)
[12:33] <cjwatson> Probably a bit much for what Odd_Bloke is trying to do.
[14:14] <HeOS> Hello! Could you help us with the problem:  we want to get information from LP by the link: https://launchpad.net/fuel/+milestone/8.0. But we see only 'Timeout error' instead data. Why it happens?
[14:54] <cjwatson> HeOS: Do you have an OOPS ID?
[14:55] <HeOS> cjwatson, sorry, I closed that tab. :(
[14:56] <HeOS> I'm going to open it again.
[14:56] <HeOS> cjwatson, (Error ID: OOPS-a6e1220cbc8ffb650971d176846a10b1)
[15:03] <cjwatson> Be with you as soon as I can - having difficulty getting oops.canonical.com to answer me just now.
[15:04] <cjwatson> In the meantime you could perhaps get equivalent information using the API.
[15:18] <HeOS> cjwatson, yes, I can, but not all members from my team can do it too unfortunately.
[15:25] <cjwatson> HeOS: I understand.  Unfortunately the OOPS must be absolutely gigantic as I can't get it to load at all here
[15:25] <cjwatson> Oh wait, it *just* did
[15:34] <cjwatson> HeOS: I've filed https://bugs.launchpad.net/launchpad/+bug/1520281 as a starting point
[15:39] <HeOS> cjwatson, great thanks!
[16:34] <thopiekar> Hey, I started two days ago a recipe build, which takes a long time, and it normally takes 19hours, but stopped after 9hours. For me it is not a problem if you stop my builds. But is there time in a week where armhf is almost idle? Maybe on weekends? I also wonder why you stopped the build, because the quere for armhf was empty most of the time (just interested).
[16:35] <thopiekar> https://launchpad.net/~thopiekar/+archive/ubuntu/arm/+build/8342848
[16:36] <HeOS> cjwatson, btw, who should fix that bug?
[16:39] <cjwatson> HeOS: I'm working on it
[16:39] <cjwatson> thopiekar: As far as I'm aware, we didn't manually stop it, it must have crashed
[16:39] <cjwatson> thopiekar: Feel free to retry that
[16:41] <cjwatson> thopiekar: (That sort of "failed but no build log" is a symptom of the buildd crashing for whatever reason; we can look into it if it's reproducible)
[16:42] <HeOS> cjwatson, thanks. :)
[16:42] <cjwatson> thopiekar: virtualised armhf builds are in fact run on x86 builders with qemu-user-static emulation to execute armhf binaries - not very reliable, best we can do just for the moment
[16:43] <thopiekar> cjwatson: Ok, thanks. I just remember that you already contacted me in the past because of other build of other projects which were wasting your build time. And whenever it is possible and needed I will trigger builds less as possible and tweak them as well :)
[16:43] <cjwatson> thopiekar: I don't remember that, but it's probably less of a problem nowadays
[16:43] <thopiekar> cjwatson: I don't know much about arm64. But isn't it possible to run armhf, like i386 on amd64?
[16:44] <cjwatson> thopiekar: That's the plan, but we're not there yet
[16:44] <thopiekar> Ok, because I saw some arm64 builders ^^
[16:45] <thopiekar> cjwatson: Thank you for you feedback :)
[16:45] <cjwatson> thopiekar: Right, we're working on those but there are some reliability problems in the infrastructure that we still need to investigate, and we'll need a kernel patch and a couple of other things to get their armhf emulation sufficiently accurate for us.
[16:46] <thopiekar> How many of these builds do you allow me to run at once?
[16:50] <cjwatson> thopiekar: It's not currently limited.  If we see you managing to take up a very significant fraction of the build farm on your own then we'll probably come and have a word :-)
[16:51] <cjwatson> https://help.launchpad.net/PPATermsofUse applies
[16:52] <thopiekar> cjwatson: Ok, like we had in the past. Hope you are not counting :D
[16:52] <cjwatson> thopiekar: It would normally only be if it causes complaints from other users.  Just remember it's a shared resource.
[16:54] <thopiekar> Of course. I just often don't notice that I take so much resources because many of me work is made by recipes. To be honest I use recipes for 99% of the packages. 1% of the packages are copied because I have missing dependencies :)
[18:12] <cjwatson> HeOS: I've pushed a fix for review, but it may not be reviewed+landed+deployed until next week, and it's non-trivial enough that I certainly want to get review for it
[18:15] <HeOS> cjwatson, great work, thanks! We will wait merging of your request and implementing. :)