| 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:35 |
| 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 | 00:36 |
| === 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 | ||
| 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:32 |
| 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? | 11:37 |
| 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:28 |
| 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:30 |
| 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:32 |
| wgrant | Kernel packaging is very special. | 12:33 |
| acooks | wgrant, I'll go rtfm, thanks! | 12:34 |
| acooks | wgrant, is there a way to backport a dependency on linux-libc-dev without trying to backport the whole kernel? | 12:35 |
| 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:36 |
| 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:37 |
| 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:38 |
| acooks | The new libnl-3 depends on a newer linux-libc-dev (>= 3.2.41) | 12:39 |
| acooks | OK, so modify the libnl-3 build, instead of an unmodified backport? | 12:40 |
| 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:41 |
| acooks | I'll give that a go, thanks. | 12:42 |
| 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:06 |
| cjwatson | dpm: still needs a bit of work, I'm afraid; commented | 13:31 |
| dpm | ok, looking at it, thanks cjwatson | 14:08 |
| dpm | cjwatson, ok, fixed. Sorry, I had misread your original inline comment. Would you mind having another look? | 14:15 |
| 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:23 |
| 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:42 |
| dpm | thanks cjwatson | 14:44 |
| cjwatson | seems to work ok locally given that, at least with a few trivial queries against launchpad_dev | 14:45 |
| dpm | nice | 14:54 |
| === charles_ is now known as charles | ||
| 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:56 |
| 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:57 |
| 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 |
| === tasdomas` is now known as tasdomas | ||
| 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:58 |
| 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 | 15:59 |
| 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:00 |
| 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:01 |
| 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:02 |
| 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:03 |
| 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:05 |
| tgm4883 | wgrant: dobey cjwatson thanks for the info | 16:06 |
| === seelaman` is now known as seelaman | ||
| 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:04 |
| 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:06 |
| tgm4883 | fwiw, the two that failed were on precise/trusty, the successful one is utopic and vivid is still building | 22:07 |
| tgm4883 | cjwatson: so you are saying that it will likely always fail on the two that failed? | 22:08 |
| cjwatson | That's my guess, but you're welcome to test it. | 22:09 |
| 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:10 |
| 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:11 |
| tgm4883 | cool | 22:12 |
| cjwatson | Once we have virtualisable native builders everything will be much happier | 22:12 |
| dobey | tgm4883: if you want to test builds on armhf, you can test locally building under qemu with sbuild | 22:28 |
| 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 | 22:29 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!