[00:35] hi [00:35] I'm having a problem to compile for ARM [00:35] I can compile in my arm board, ubuntu 14.04 [00:36] but launchpad complains about "undeclared identifier" [00:36] https://launchpadlibrarian.net/196348889/buildlog_ubuntu-trusty-armhf.libretro-desmume_0.9.10.svn%2Br4840~12~ubuntu14.04.1_FAILEDTOBUILD.txt.gz [00:36] I'm using clang in the board too === rvba` is now known as rvba === Logan_ is now known as Logan === mthaddon` is now known as mthaddon === dpm_ is now known as dpm === cjwatson_ is now known as cjwatson === ahasenac` is now known as ahasenack [11:32] Cannot add PPA: '"Error reading https://launchpad.net/api/1.0/~ubuntu-wine/+archive/ppa: (7, 'Failed to connect to launchpad.net port 443: Connection refused')"'. [11:32] حمئ تثمح [11:32] plz hep [11:32] plz help [11:37] Ahmed__: I don't see why it should have caused this, but we're deploying upgrades to launchpad.net at the moment, so try again? [12:28] I'm trying to backport a kernel package and upload it to my PPA. The build succeeds, but the upload fails. Can someone help me understand whats wrong? https://launchpad.net/~acooks/+archive/ubuntu/libnl3-backport/+build/6771534 [12:30] acooks: You changed debian/changelog, but the kernel packaging is a bit special. [12:30] You need to change debian.master/changelog instead, as te build autogenerates debian/changelog from debian.master. [12:32] wgrant, thanks, I'll need to read some more before I'll understand that. I've just been using 'backportpackage' without really understanding what it's doing. [12:33] Kernel packaging is very special. [12:34] wgrant, I'll go rtfm, thanks! [12:35] wgrant, is there a way to backport a dependency on linux-libc-dev without trying to backport the whole kernel? [12:36] acooks: No, but are you sure you need a new linux-libc-dev? [12:36] What exactly are you trying to do? [12:37] I'm trying to backport libnl-3 3.2.24 to Precise, because Travis CI is still running Precise and the libnl-3 version that shipped with Precise is broken. [12:38] (for my application) [12:38] I would probably copy any necessary declarations from linux-libc-dev into private headers used by the libnl-3 build. [12:39] The new libnl-3 depends on a newer linux-libc-dev (>= 3.2.41) [12:40] OK, so modify the libnl-3 build, instead of an unmodified backport? [12:41] I might as well patch the missing function declaration in the version of libnl-3 that shipped with precise. [12:41] If that's straightforward, why not ... [12:42] I'll give that a go, thanks. [13:06] hi cjwatson, it took a while until I could look into fixing the issues pointed in your review, but they should have been addressed now. When you've got a minute, would you mind re-reviewing https://code.launchpad.net/~dpm/lp-get-ul10nstats/distro-support/+merge/234349 ? [13:31] dpm: still needs a bit of work, I'm afraid; commented [14:08] ok, looking at it, thanks cjwatson [14:15] cjwatson, ok, fixed. Sorry, I had misread your original inline comment. Would you mind having another look? [14:23] Hmm, we need an LP security.cfg patch to make this work [14:23] psycopg2.ProgrammingError: permission denied for relation distribution [14:23] Hate this thing [14:42] wgrant: Could you have a quick look at https://code.launchpad.net/~cjwatson/launchpad/ul10nstats-security-distribution/+merge/248257 for the above, please? [14:42] dpm: ^- you'll be blocked on that being reviewed/landed/deployed [14:44] thanks cjwatson [14:45] seems to work ok locally given that, at least with a few trivial queries against launchpad_dev [14:54] nice === charles_ is now known as charles [15:56] I remember reading awhile back that the build farm was moved to make it faster to setup and remove builders (Juju/Openstack?). Anyway, are ARM ppa's still not available? [15:57] they still must be requested [15:57] I see [15:57] dobey: are they still Canonical only? Or can other teams request them? [15:58] afaik, anyone can request them. they are just not enabled by default (not sure why, and if/when they will be for the virtualized builders) === tasdomas` is now known as tasdomas [15:58] i think maybe there are still some reliability concerns with qemu there [15:58] tgm4883: Anyone can request them, but the virtual builder pool does non-x86 builds using qemu-user. [15:58] dobey: sounds good. When requested, is it just a one time build or are they enabled forever? [15:59] We'll have proper virtual ARM and POWER builders some time this year, but not yet. [15:59] Forever. [15:59] for that ppa, not that user [16:00] I ask, because the Raspberry Pi 2 was released, and the Mythbuntu team might need to start building our builds for ARM [16:00] reliability> qemu-user manages to build some things, but there's a sizeable percentage of stuff where it just falls over hard. [16:00] and those problems aren't terribly likely to get fixed in qemu. [16:00] is the pi2 arm, or arm64? [16:00] and it's likely powerful enough to actually run the frontend [16:00] hmm, let me check [16:00] so enabling arm builds across the board would result in us having lots and lots of failed builds that there's basically no way to fix [16:01] RPi 2 is ARMv7, so armhf. [16:01] And qemu is slow. [16:01] But at least finally v7 not v6. [16:01] cjwatson: yeah, that's what i thought [16:01] So we don't enable it by default. [16:01] re: reliability that is [16:01] yea I'm not seeing anything about arm64 on it [16:02] oh, i haven't read anything about it yet. i just saw some "possibly a cheap arm64 board" and "rpi 2 released" at the same time, so i wasn't sure :) [16:03] Ok, so last 2 questions. Where do I go to request this for a PPA, and if we build ARM on one PPA, can we safely copy the binaries to another PPA? [16:05] dobey: Ooh, what's the cheap arm64 board? [16:05] tgm4883: https://answers.launchpad.net/launchpad/+addquestion [16:05] And you can safely copy them elsewhere. Only building them is restricted. [16:05] wgrant: i don't know, i thought it was the rpi2, but i guess not :) [16:05] wgrant: cool, I'll file a question then [16:06] wgrant: dobey cjwatson thanks for the info === seelaman` is now known as seelaman [22:04] so regarding the reliability of those arm builds, when one fails, should I just tell it to retry that build? [22:04] provided it's not something that is obviously an issue I can fix [22:06] Out of 4 builds, 1 finished successfully, 1 is still building, 1 seems to hang on "debconf-updatepo" and was eventually killed, and 1 failed with a seg fault and "*** stack smashing detected ***: /usr/bin/qemu-arm-static terminated" [22:06] It's not likely to be sporadic. [22:06] cjwatson: so then don't try again [22:07] fwiw, the two that failed were on precise/trusty, the successful one is utopic and vivid is still building [22:08] cjwatson: so you are saying that it will likely always fail on the two that failed? [22:09] That's my guess, but you're welcome to test it. [22:10] The worst problems are generally with threading. In principle those aren't deterministic but AIUI any build that runs into that usually has pretty poor probability of succeeding [22:11] cjwatson: I'll just try it once, if it fails with the same issue I'll see what I can do about removing it from our builds (although I doubt that will be easy) [22:11] cjwatson: is that something that would be resolved with the changes that are coming later? [22:11] Yes [22:12] cool [22:12] Once we have virtualisable native builders everything will be much happier [22:28] tgm4883: if you want to test builds on armhf, you can test locally building under qemu with sbuild [22:29] you can iterate faster that way at least [22:29] and it won't take up resources from other builds [22:29] dobey: good point. I'll take a look at that when I get home