[00:35] <sergio-br22> hi
[00:35] <sergio-br22> I'm having a problem to compile for ARM
[00:35] <sergio-br22> I can compile in my arm board, ubuntu 14.04
[00:36] <sergio-br22> but launchpad complains about "undeclared identifier"
[00:36] <sergio-br22> https://launchpadlibrarian.net/196348889/buildlog_ubuntu-trusty-armhf.libretro-desmume_0.9.10.svn%2Br4840~12~ubuntu14.04.1_FAILEDTOBUILD.txt.gz
[00:36] <sergio-br22> I'm using clang in the board too
[11:32] <Ahmed__> 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] <Ahmed__> حمئ تثمح
[11:32] <Ahmed__> plz hep
[11:32] <Ahmed__> plz help
[11:37] <cjwatson> 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] <acooks> 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] <wgrant> acooks: You changed debian/changelog, but the kernel packaging is a bit special.
[12:30] <wgrant> You need to change debian.master/changelog instead, as te build autogenerates debian/changelog from debian.master.
[12:32] <acooks> 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] <wgrant> Kernel packaging is very special.
[12:34] <acooks> wgrant, I'll go rtfm, thanks!
[12:35] <acooks> wgrant, is there a way to backport a dependency on linux-libc-dev without trying to backport the whole kernel?
[12:36] <wgrant> acooks: No, but are you sure you need a new linux-libc-dev?
[12:36] <wgrant> What exactly are you trying to do?
[12:37] <acooks> 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] <acooks> (for my application)
[12:38] <cjwatson> I would probably copy any necessary declarations from linux-libc-dev into private headers used by the libnl-3 build.
[12:39] <acooks> The new libnl-3 depends on a newer linux-libc-dev (>= 3.2.41)
[12:40] <acooks> OK, so modify the libnl-3 build, instead of an unmodified backport?
[12:41] <acooks> I might as well patch the missing function declaration in the version of libnl-3 that shipped with precise.
[12:41] <cjwatson> If that's straightforward, why not ...
[12:42] <acooks> I'll give that a go, thanks.
[13:06] <dpm> 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] <cjwatson> dpm: still needs a bit of work, I'm afraid; commented
[14:08] <dpm> ok, looking at it, thanks cjwatson
[14:15] <dpm> cjwatson, ok, fixed. Sorry, I had misread your original inline comment. Would you mind having another look?
[14:23] <cjwatson> Hmm, we need an LP security.cfg patch to make this work
[14:23] <cjwatson> psycopg2.ProgrammingError: permission denied for relation distribution
[14:23] <cjwatson> Hate this thing
[14:42] <cjwatson> 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] <cjwatson> dpm: ^- you'll be blocked on that being reviewed/landed/deployed
[14:44] <dpm> thanks cjwatson
[14:45] <cjwatson> seems to work ok locally given that, at least with a few trivial queries against launchpad_dev
[14:54] <dpm> nice
[15:56] <tgm4883> 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] <dobey> they still must be requested
[15:57] <tgm4883> I see
[15:57] <tgm4883> dobey: are they still Canonical only? Or can other teams request them?
[15:58] <dobey> 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)
[15:58] <dobey> i think maybe there are still some reliability concerns with qemu there
[15:58] <wgrant> tgm4883: Anyone can request them, but the virtual builder pool does non-x86 builds using qemu-user.
[15:58] <tgm4883> dobey: sounds good. When requested, is it just a one time build or are they enabled forever?
[15:59] <wgrant> We'll have proper virtual ARM and POWER builders some time this year, but not yet.
[15:59] <wgrant> Forever.
[15:59] <dobey> for that ppa, not that user
[16:00] <tgm4883> I ask, because the Raspberry Pi 2 was released, and the Mythbuntu team might need to start building our builds for ARM
[16:00] <cjwatson> reliability> qemu-user manages to build some things, but there's a sizeable percentage of stuff where it just falls over hard.
[16:00] <cjwatson> and those problems aren't terribly likely to get fixed in qemu.
[16:00] <dobey> is the pi2 arm, or arm64?
[16:00] <tgm4883> and it's likely powerful enough to actually run the frontend
[16:00] <tgm4883> hmm, let me check
[16:00] <cjwatson> 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] <wgrant> RPi 2 is ARMv7, so armhf.
[16:01] <wgrant> And qemu is slow.
[16:01] <cjwatson> But at least finally v7 not v6.
[16:01] <dobey> cjwatson: yeah, that's what i thought
[16:01] <wgrant> So we don't enable it by default.
[16:01] <dobey> re: reliability that is
[16:01] <tgm4883> yea I'm not seeing anything about arm64 on it
[16:02] <dobey> 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] <tgm4883> 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] <wgrant> dobey: Ooh, what's the cheap arm64 board?
[16:05] <wgrant> tgm4883: https://answers.launchpad.net/launchpad/+addquestion
[16:05] <wgrant> And you can safely copy them elsewhere. Only building them is restricted.
[16:05] <dobey> wgrant: i don't know, i thought it was the rpi2, but i guess not :)
[16:05] <tgm4883> wgrant: cool, I'll file a question then
[16:06] <tgm4883> wgrant: dobey cjwatson thanks for the info
[22:04] <tgm4883> so regarding the reliability of those arm builds, when one fails, should I just tell it to retry that build?
[22:04] <tgm4883> provided it's not something that is obviously an issue I can fix
[22:06] <tgm4883> 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] <cjwatson> It's not likely to be sporadic.
[22:06] <tgm4883> cjwatson: so then don't try again
[22:07] <tgm4883> fwiw, the two that failed were on precise/trusty, the successful one is utopic and vivid is still building
[22:08] <tgm4883> cjwatson: so you are saying that it will likely always fail on the two that failed?
[22:09] <cjwatson> That's my guess, but you're welcome to test it.
[22:10] <cjwatson> 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] <tgm4883> 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] <tgm4883> cjwatson: is that something that would be resolved with the changes that are coming later?
[22:11] <cjwatson> Yes
[22:12] <tgm4883> cool
[22:12] <cjwatson> Once we have virtualisable native builders everything will be much happier
[22:28] <dobey> tgm4883: if you want to test builds on armhf, you can test locally building under qemu with sbuild
[22:29] <dobey> you can iterate faster that way at least
[22:29] <dobey> and it won't take up resources from other builds
[22:29] <tgm4883> dobey: good point. I'll take a look at that when I get home