[00:13] ugh, didn't work [00:13] why it was working with gcc 4.9.2, but not with 4.9.3 [00:14] 4.9.2-0ubuntu1~14.04 [01:06] damn launchpad [01:11] damn apt [01:11] I just installed the gcc for dolphin ppa, with 4.9.3 [01:11] and i can't install the packages [01:11] it asks to remove a bunch of packages [01:12] or conflicts [01:13] it's just a bug fix update 4.9.2 --> 4.9.3 [01:13] never saw something like that [01:18] why that didn't happened with 4.9.2, from the same toolchain ppa? [01:21] ok, I just deleted the 4.9.3 [01:21] it's possible to put the 4.9.2 again in the ppa right? (i deleted it too...) [01:50] "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] oh man [01:50] I really need to re-upload gcc 4.9.2 in that ppa [01:51] even though the archive is very picky about that, _copying_ from one ppa to another ought to work [01:51] can someone help me here? [01:51] it's building that it refuses to do [01:51] humm [01:53] I hope it works [01:53] launchpad should be less pick about this [01:56] yay seems it worke [01:59] thanks sarnold [02:05] the 4.9.2 copies? [02:05] is your build underway? o rjust the copy worked? heh [02:09] yeah, it copied [02:09] it's pending yet === commandoline_ is now known as commandoline === commandoline is now known as Guest50174 === Peng_ is now known as Peng === maclin1 is now known as maclin === semiosis_ is now known as semiosis === JoseeAntonioR is now known as jose === lifeless_ is now known as lifeless === cprov_ is now known as cprov === teran_ is now known as teran === JoseeAntonioR is now known as jose === DaGardner_ is now known as DaGardner === su_v_ is now known as su_v === L235_ is now known as L235 === wgrant is now known as Guest42266 === tasdomas` is now known as tasdomas === maclin1 is now known as maclin [10:05] 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] I've searched for a project with the name 'wds' on launchpad but couldn't find one [10:06] even the url https://launchpad.net/wds is not used by anything [10:06] there is also no source package with that name either in debian or ubuntu [10:06] anyone has an idea what else could it be? [11:02] wxl: Launchpad has private branches, but it's a paid commercial feature. [11:04] 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] morphis: (i.e. it is used, you just can't see it) === tolecnal_ is now known as tolecnal [11:39] cjwatson: thanks, will do that [11:52] 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 ()" as the consumer. [11:53] 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] Hmm, looking at the launchpadlib code, I don't have much choice in the matter. [11:58] Unless I want to delve in to the API more than I want to. [12:01] It has to be a subclass of lazr.restfulclient.authorize.oauth.Consumer, I believe, not just a string. [12:02] Er, an instance of, I mean. [12:03] 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] (application_name goes in User-Agent) [12:03] I don't know the OAuth stuff very well, but this doesn't seem to be very much delving into the API. [12:13] cjwatson: Aha: http://bazaar.launchpad.net/~lazr-developers/launchpadlib/trunk/view/head:/src/launchpadlib/credentials.py#L615 [12:15] So I'll just do a system-wide integration on one of the slaves and live with the potential confusion. [12:25] 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] 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] Probably a bit much for what Odd_Bloke is trying to do. [14:14] 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] HeOS: Do you have an OOPS ID? [14:55] cjwatson, sorry, I closed that tab. :( [14:56] I'm going to open it again. [14:56] cjwatson, (Error ID: OOPS-a6e1220cbc8ffb650971d176846a10b1) [14:56] https://oops.canonical.com/?oopsid=OOPS-a6e1220cbc8ffb650971d176846a10b1 [15:03] Be with you as soon as I can - having difficulty getting oops.canonical.com to answer me just now. [15:04] In the meantime you could perhaps get equivalent information using the API. [15:18] cjwatson, yes, I can, but not all members from my team can do it too unfortunately. [15:25] HeOS: I understand. Unfortunately the OOPS must be absolutely gigantic as I can't get it to load at all here [15:25] Oh wait, it *just* did [15:34] HeOS: I've filed https://bugs.launchpad.net/launchpad/+bug/1520281 as a starting point [15:34] Ubuntu bug 1520281 in Launchpad itself "Milestone:+index times out with enormous XRef query" [Critical,Triaged] [15:39] cjwatson, great thanks! === JanC_ is now known as JanC [16:34] 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] https://launchpad.net/~thopiekar/+archive/ubuntu/arm/+build/8342848 === robru_ is now known as robru [16:36] cjwatson, btw, who should fix that bug? [16:39] HeOS: I'm working on it [16:39] thopiekar: As far as I'm aware, we didn't manually stop it, it must have crashed [16:39] thopiekar: Feel free to retry that [16:41] 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] cjwatson, thanks. :) [16:42] 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] 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] thopiekar: I don't remember that, but it's probably less of a problem nowadays [16:43] cjwatson: I don't know much about arm64. But isn't it possible to run armhf, like i386 on amd64? [16:44] thopiekar: That's the plan, but we're not there yet [16:44] Ok, because I saw some arm64 builders ^^ [16:45] cjwatson: Thank you for you feedback :) [16:45] 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] How many of these builds do you allow me to run at once? [16:50] 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] https://help.launchpad.net/PPATermsofUse applies [16:52] cjwatson: Ok, like we had in the past. Hope you are not counting :D [16:52] thopiekar: It would normally only be if it causes complaints from other users. Just remember it's a shared resource. [16:54] 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 :) === maxb_ is now known as maxb [18:12] 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] cjwatson, great work, thanks! We will wait merging of your request and implementing. :) === tumbleweed_ is now known as tumbleweed === DaGardner_ is now known as DaGardner === HeOS is now known as 14WABTYGV === tumbleweed is now known as 7F1AA3EDF === tumbleweed_ is now known as tumbleweed === 7F1AA3EDF is now known as tumbleweed === xnox_ is now known as xnox === mwhudson_ is now known as mwhudson === tolecnal_ is now known as tolecnal === infinity2 is now known as infinity === nickoe_ is now known as nickoe