[00:00] wgrant: Yeah, intermittent problems are the worst sort of demon [03:11] SpamapS: We think it's been fixed for a while. Let me know if it's still broken. [09:55] Hello, how much RAM do the arm64 builders have and is there an image of the VM it uses available? [09:58] oparoz: 8GiB per guest, and sorry no but it's basically just a cloud image with launchpad-buildd bzr-builder git-build-recipe quilt binfmt-support qemu-user-static installed [09:59] a 15.10 cloud image at the moment if I recall correctly [09:59] what are you trying to achieve? [10:02] Thanks cjwatson [10:02] I'm trying to see if I can design a local builder instead of a remot one [10:03] The smaller devices can't compile MySQL and the remote builders don't offer enough debugging capabilities [10:04] Aside from the network proxy issue, surely it's just a matter of running snapcraft in a chroot [10:04] You could look at lp:launchpad-buildd and see what buildsnap does, which isn't complicated [10:05] And ignore the network proxy bit and cross fingers :) [10:05] Well, the network issue is gone when using a different URL, but there is another failure, right at the end, during stripping and I have no idea why this is happening [10:06] (I don't think there's anything secret about the VM images, and it would even be useful for us to have them public; but it's a bit logistically difficult to arrange, and I suspect it wouldn't actually be of much direct help to you anyway) [10:06] And that's one other thing, inherent to the nature of sharing builders. We have to start from the beginning every time whereas locally, you just rebuild the part which failed [10:07] I'll take a look at lp:launchpad-buildd :) [10:07] That certainly looks like just running snapcraft would reveal the same thing. [10:08] Except that you have access to all the files, so you can look at the config and build logs, etc. [10:09] Perhaps there's something odd with Go on arm64 [10:09] It did work last week, so I suspect some package update [10:10] But I didn't write that part, so it's difficult to offer help if I report the issue. All I can say is that this doesn't compile on arm64 [10:12] It's also odd that ldd apparently exits non-zero without writing anything to stderr. [10:13] (Also also, I wish I'd never looked at the run_output function. Why on earth doesn't it just use subprocess's ordinary environment-handling facilities?) [10:15] No idea :D [10:16] That's the code: https://github.com/kyrofa/mdns-publisher [10:16] No help to me, I don't speak Go. [10:16] Me neither [11:08] Hi! I'm having problems "porting" a package in our ppa from wily to xenial. It depends on "libqt5webengine5" in another of our PPAs. I copied that over from wily to xenial but the package is still not found. [11:08] build log: https://launchpad.net/~ethereum/+archive/ubuntu/ethereum-dev/+build/9564842/+files/buildlog_ubuntu-xenial-amd64.cpp-ethereum_1.2.3-SNAPSHOT-260-20160412-44207e7~xenial-0ubuntu1_BUILDING.txt.gz [11:09] That doesn't say it's not found; it says that it's uninstallable. [11:09] ppa that contains the package: https://launchpad.net/~ethereum/+archive/ubuntu/ethereum-qt/+packages [11:09] (Possibly in combination with your other build-dependencies.) [11:09] ah, ok [11:09] the webengine package is also slightly odd [11:10] it says wily in several places although it is sorted into xenial [11:10] I tried to re-upload it manually, but did not get any reply from launchpad [11:11] If you don't get any reply that's normally because you forgot to sign it or the signature was bad in some way. [11:12] When a package says "wily" in the top entry in debian/changelog, that's only where the developer initially intended to upload it; it can be copied around elsewhere later without modifying the package. [11:17] ok, thanks! Then I'll try to dig deeper into why the package is not installable. [11:20] chrisr_: http://paste.ubuntu.com/15785085/ [11:20] chrisr_: i.e. libqt5webengine5 and libqt5qml5 are inconsistent in this environment [11:21] Whether you need a different libqt5qml5 or a different build of libqt5webengine5 I do not know [11:23] The last line there should have been "chdist apt-cache ethereum show libqt5qml5 | grep qtdeclarative-abi" actually, but it doesn't matter since the result is the same - neither of your PPAs contain libqt5qml5 [11:24] Basically it looks like you've binary-copied forward a wily build of qtwebengine-opensource-src that actually needs to be rebuilt against xenial's Qt libraries [11:31] ah, thanks [11:31] but the versions seems to be different too, right? [11:32] do you think a sourc-build of the qt5 package would help? [11:32] (qtwebengine at least) [11:32] so as far as I know, qtwebengine is not included in any of the ubuntu repositories, but qt5 itself is [12:03] chrisr_: What I'm saying is exactly that you appear to need to rebuild qtwebengine-opensource-src for xenial. [12:03] I don't know what you mean regarding versions, but it probably isn't important. [12:13] Hi there [12:13] I'd like to setup a snap package from a github brnch [12:13] I understand this can only be done with a branch in Launchpad [12:13] so I've requested a mirrored branch here https://code.launchpad.net/~openswitch/openswitch/ops-snappy [12:14] but a) the import failed (2016-04-12 12:12:05 INFO No branch found at remote location.) and b) would it be possible for the import to be a git branch too? [12:14] lool: You need a trailing ".git" on the import source, because GitHub does some strange user-agent sniffing. I've fixed that and am re-running the import. [12:14] lool: git-to-git mirroring is underway, but not available yet. [12:15] thanks [12:15] 2016-04-12 12:15:13 INFO Unable to import branch because of limitations in Bazaar. [12:15] Ah, submodules. [12:15] You lose, sorry. [12:15] 2016-04-12 12:15:13 INFO The repository you are fetching from contains submodules, which are not yet supported. [12:15] ok; I guess I might go with travis-ci for now [12:15] lool [12:15] You do have one other option. [12:15] thanks for the quick action though [12:15] lool: Mirror it manually. [12:15] I could cron the git mirror [12:15] yeah [12:16] lool, Just add a remote repo to your project [12:16] and push to 2 locations [12:16] Oh, right, snap [12:16] oparoz: I don't think this is lool's project [12:16] I do co-maintain this specific github project [12:16] Or maybe it is? OK [12:16] Ah, yeah, that won't work then... [12:17] but I'm not the only one pushing to it [12:17] is there a github mechanism I can leverage to trigger a push to launchpad? [12:17] like webhooks or something [12:17] I kept hearing about this, but I never researched what it is [12:17] lool: You could use webhooks, but you'll need something external to Launchpad to receive the webhook and arrange a pull/push. [12:17] Webhooks are basically just an HTTP POST. [12:19] At the moment Launchpad can send webhooks itself, but doesn't have the facility to receive them, so that would have to be hooked up elsewhere. But it would certainly be an option for making the thing event-driven rather than cronned. [12:19] I'm trying to see if github has a way to trigger a git push directly, seems not [12:19] Not as far as I know. [12:19] otherwise I could have a CGI on some host receive the web hook and do the git pull + push [12:20] Besides, it would have to have your key. [12:21] there's a PubSubHubbub alternative to web hooks, but it's quite similar in nature [12:21] They're pretty similar. [12:21] Basically the same in fact. [12:22] Webhooks can be signed in the way specified by the PubSubHubbub spec. [12:22] I don't know if GitHub implements the subscribe bit of PubSubHubbub. [12:23] Webhooks are basically an implementation of the publishing part. [12:26] Ah yes, from https://developer.github.com/v3/repos/hooks/#pubsubhubbub it looks like it does implement subscribe, nice. I think that just gives you a way to create webhooks on repositories you don't own. [12:27] It might be worth us using that for git imports once we have them. [12:48] cjwatson: I wonder: have travis CI ever contacted about watching Launchpad repos? [12:53] lool: No, and they've rejected requests to do anything other than GitHub in the past. [12:54] ah, too bad [14:25] cjwatson: How do you feel about pushing an official Snapcraft patch part of 2.8 to the arm64 building cloud? ;) [14:26] cjwatson: It fixes the go stripping problem [14:27] oparoz: we don't push snapcraft to our builder cloud, that's not how it works [14:27] Ah, you pull it from a central repo I guess [14:27] oparoz: each build installs snapcraft from a sources.list which includes ppa:snappy-dev/ubuntu/tools and the primary Ubuntu archive [14:28] cjwatson: OK, so we'll just have to wait :) [14:28] oparoz: so the snappy developers can do this either by uploading a suitably-patched package to their PPA, or just by putting it in xenial [14:28] oparoz: but it's explicitly up to them, not us :) [14:29] cjwatson: Final freeze is this week, so we'll just have to wait [14:30] oparoz: final freeze has no bearing on their PPA [14:30] oparoz: and in any case a simple targeted bug fix could still be uploaded to xenial [14:30] cjwatson: I think they don't want to push 2 releases this week, but I'll ask, thanks [17:53] Hi Guys ... I am new to launchpad [17:53] I have a upstream project I need to work on. But I have no idea where to start ? [17:53] is this something similar to git ? can I clone a repository ? n work locally ? [17:54] shishir-a412ed: what upstream project? [17:54] nacc, cloud-init [17:55] shishir-a412ed: i think you mean to be asking about bzr not launchpad? [17:55] nacc what the difference ? [17:55] shishir-a412ed: https://help.launchpad.net/Code/Git and http://doc.bazaar.canonical.com/latest/en/mini-tutorial/ [17:55] shishir-a412ed: should be able to follow the instructions at: https://code.launchpad.net/cloud-init to set up your own local branch [17:55] the code is hosted on launchpad i.e launchpad.net/cloud-init [17:55] shishir-a412ed: right, hosting != SCM [17:56] shishir-a412ed: git and bzr are SCMs [17:56] nacc, right but can I use git for SCM ? [17:56] with cloud-init [17:57] shishir-a412ed: i would ask in #cloud-init to be sure, but afaict it's bzr only? [17:57] nacc, oh okay. let me ping over there.