| teward | bleh, well, i'll just upload a version bump, LP's erroring on what i want it to do (it can't basically) | 00:00 |
|---|---|---|
| wgrant | Hm, really? | 00:00 |
| wgrant | What's the error? | 00:00 |
| teward | wgrant: well, see, I need it to rebuild in the staging PPAs | 00:00 |
| teward | copy for rebuild says, "same version already has published binaries in the destination archive" | 00:01 |
| teward | just spammed the hell out of myself with errors | 00:01 |
| wgrant | Did you ensure that you selected the option to copy binaries, rather than to rebuild? | 00:01 |
| teward | wgrant: there's no arm binaries yet | 00:01 |
| teward | hence the need for a rebuild | 00:02 |
| teward | or will it autobuild arm binaries | 00:02 |
| wgrant | You have to copy the existing binaries, but then it will notice that there are still binaries missing and create the ARM build anyway. | 00:02 |
| teward | ahh okay | 00:02 |
| teward | so copy binaries to itself then, copy over to the other ppa as well then | 00:02 |
| teward | after it sees it needs ARM builds | 00:03 |
| teward | ok | 00:03 |
| wgrant | You can't ask it to rebuild the existing binaries, because they'd try to overwrite the existing ones with the same filenames. | 00:03 |
| teward | right | 00:03 |
| * teward expects to see 2 FTBFS shortly | 00:03 | |
| wgrant | It's qemu-user, so "shortly" may be over-optimistic, but we'll see. | 00:03 |
| teward | well, 'shortly' as in when it runs | 00:03 |
| wgrant | (we | 00:03 |
| wgrant | 'll have proper ARM VMs Soon™, but getting enough capable hardware is harder than it looks) | 00:04 |
| teward | last time I ran an ARM build was swig3.0, and it FTBFS in Precise because dep-wait on gcc, which apparently is FTBFS in the repos | 00:04 |
| wgrant | Hm, that seems unlikely. | 00:04 |
| wgrant | precise's armhf port is excellent. | 00:04 |
| teward | mm, i lied, it wasn't gcc | 00:04 |
| wgrant | The only reason this might fail is that qemu-user doesn't like threads very much sometimes. | 00:04 |
| teward | guile-2.0-dev is missing. check that in precise repos... | 00:04 |
| teward | yeah that there's ftbfs in armhf | 00:05 |
| teward | but ultimately, nginx should be fine, if all the main deps are present | 00:05 |
| teward | the only thing i hate about the NGINX packaging is the 3rd party modules >.< | 00:06 |
| teward | wgrant: i can disregard the complaints about copying failed, as its talking about i386 / amd64, not armhf, right? | 00:07 |
| teward | ('cause building armhf right now) | 00:07 |
| wgrant | You could probably have just backported a modern guile-2.0 to precise. There are no huge changes in vivid. | 00:07 |
| wgrant | teward: I think those complaints are from the previous copies without binaries. | 00:08 |
| wgrant | teward: Each copy is atomic, and the latest batch clearly worked. | 00:08 |
| teward | mmm | 00:09 |
| teward | wgrant: the FTBFS was the tests | 00:09 |
| teward | https://launchpadlibrarian.net/102666041/buildlog_ubuntu-precise-armhf.guile-2.0_2.0.5%2B1-1_FAILEDTOBUILD.txt.gz | 00:09 |
| teward | FAIL: test-with-guile-module, FAIL: test-pthread-create, FAIL: test-scm-spawn-thread (SEGV all around) | 00:09 |
| teward | i'm too lazy to | 00:10 |
| teward | it only affects the ZNC PPA anyways | 00:10 |
| teward | wgrant: reminder, arch:all packages are arch-independent, right? | 00:13 |
| teward | s/reminder/remind me/ | 00:14 |
| wgrant | Yes. | 00:15 |
| wgrant | They build on a single architecture, but are published on all. | 00:15 |
| teward | right that's what i assumed | 00:18 |
| wgrant | teward: Succeeded in just under half an hour. | 00:35 |
| === reed_ is now known as reed | ||
| teward | wgrant: indeed, I got an email from the person on https://bugs.launchpad.net/nginx/+bug/1425324 about it - can we keep the armhf builds enabled there then? | 02:51 |
| ubot5 | Launchpad bug 1425324 in Nginx "[PPA] Please provide PPA builds/packages for armhf" [Wishlist,Fix committed] | 02:51 |
| wgrant | teward: You don't need them on any other PPAs? | 02:51 |
| wgrant | It's no problem to keep them enabled. My only concern is that they might not be enabled in enough places :) | 02:52 |
| teward | wgrant: well, i'm not going to enable them on the ZNC PPA, and for nginx, i only need them on staging since I do all the builds there before moving them to the main nginx ppas | 02:53 |
| teward | wgrant: and ZNC Precise will always FTBFS unless I backport within the swig3.0 PPA the build deps and i'm too lazy to do that at the moment | 02:54 |
| teward | and i noticed a bug where ZNC won't install after compile when the ubuntu-toolchain-r/test ppa is included (for g++-4.7/precise) because it needs newer c libs apparently | 02:54 |
| teward | so meh | 02:54 |
| teward | wgrant: so far, the only things I needed built for armhf were my swig3.0 backports PPA, and nginx. | 02:56 |
| teward | nothing else on my radar for arm builds - only put nginx on the list because 5 emails today on it | 02:56 |
| wgrant | :) | 02:57 |
| wgrant | If you need anything else, give me a yell. If I'm not around, https://answers.launchpad.net/launchpad/+addquestion is your friend. | 02:57 |
| teward | wgrant: indeed. thanks. | 02:57 |
| teward | wgrant: i should be extra glad though... nobody's asked me to set up arm builds for my wireshark backports ppa... xD | 02:57 |
| teward | that'd... not go well | 02:57 |
| wgrant | Heh | 03:00 |
| teward | wgrant: i'll likely give a holler if I need arm turned on anywhere else, for now I think we're set, since it's not like I respin the software every day xD | 03:03 |
| teward | except when i made a grave fail in package edits that forces me to reupload to fix xD | 03:04 |
| ppisati | ok so, i'm geting this: "File linux_3.18.3-2.2.diff.gz already exists in Misc packages for Ubuntu, but uploaded version has different contents" | 08:35 |
| ppisati | this after the previous build failed, i found the problem, fixed it, but my new upload is rejected | 08:36 |
| ppisati | what am i supposed to do? | 08:36 |
| wgrant | ppisati: You need to change the version when you change the package. | 08:37 |
| ppisati | wgrant: i feared that answer | 08:37 |
| wgrant | ppisati: Unless you want to hack the build system to disable the ABI check, the easiest way to build a kernel in a PPA is to replace the latest changelog entry rather than appending a new one. | 08:38 |
| ppisati | wgrant: well, abi checck is off | 08:38 |
| ppisati | wgrant: anyhow, let me change the version | 08:39 |
| ppisati | wgrant: but i don't really understand why you keep the previous diff around | 08:39 |
| wgrant | ppisati: We don't keep it around, but it is remembered. | 08:39 |
| wgrant | Each filename in a PPA references a unique file throughout time. | 08:40 |
| ppisati | wgrant: os it's per PPA, right? | 08:40 |
| ppisati | *so | 08:40 |
| ppisati | ok | 08:40 |
| wgrant | Changing the version when you change the package is normal good practice, not an onerous restriction. | 08:40 |
| wgrant | ppisati: Right. | 08:40 |
| ppisati | wgrant: i agree that changing version everytime you change a pkg is right, but since this pkg never existed, the previous sentence could be debated | 08:41 |
| ppisati | anyway | 08:41 |
| ppisati | no need to argue | 08:41 |
| wgrant | The package did exist! | 08:41 |
| ppisati | i bump the version | 08:41 |
| === Odd_Blok1 is now known as Odd_Bloke | ||
| === Mission-Critical is now known as MissionCritical | ||
| dobey | hrmm, not sure if anyone is around who would know the answer to this... | 17:43 |
| dobey | anyone know if there's a way to force LP to do the translations update commit to a branch? | 17:44 |
| teward | wgrant: around? | 17:46 |
| teward | (if not i won't bother you) | 17:46 |
| cjwatson | dobey: I don't believe so; that code is only called from a cron script, so you'd have to wait for that. | 17:48 |
| dobey | cjwatson: that's what i thought. and it runs at like 00:00 UTC daily, iirc. | 17:48 |
| cjwatson | taotie.canonical.com-codehost:30 04 * * * $LP_PY /srv/bazaar.launchpad.net/production/launchpad/cronscripts/translations-export-to-branch.py -q --log-file=INFO:/srv/bazaar.launchpad.net/production-logs/translations-export-to-branch.log | 17:48 |
| === wedgwood1 is now known as wedgwood | ||
| teward | general question: if i want arm builds for a specific ppa but i know for a fact pre-Trusty releases won't build at all for armhf, is it still acceptable to ask for ARM builds on a given PPA? | 21:32 |
| dobey | teward: just don't build for precise on that ppa then? | 21:33 |
| dobey | teward: you can't build for quantal, raring, or saucy anyway | 21:33 |
| teward | dobey: ehh, to do *that*, I'd have to set up an ARM builds PPA to separate it from primary staging | 21:34 |
| teward | for the software i'm packaging in question that is | 21:34 |
| teward | except that I know why it FTBFS in precise - one of the build-deps is not built in Precise | 21:34 |
| teward | so short of a backport which I'm too lazy to do... :P | 21:35 |
| teward | (the FTBFS in precise are dep-waits) | 21:35 |
| dobey | just doa backport | 21:35 |
| dobey | grab the source and see if it builds in a precise chroot locally, and if it does then make the minimal changes to denote it's a backport for precise (append ~12.04.1 to version, and change release in changelog to precise) and upload it | 21:36 |
| teward | dobey: precise is the next schroot i'm building for the armhf environment, but... slow. | 21:37 |
| teward | have to build each schroot after all | 21:37 |
| teward | (I use sbuild) | 21:37 |
| dobey | teward: well, does it build on x86 precise? | 21:37 |
| dobey | i don't test builds on every arch. that would be annoying :) | 21:37 |
| teward | dobey: haven't tested - the target is armhf, not x86, but i'll test after the sbuild schroot is done building | 21:40 |
| dobey | yeah, but x86 is much faster to build on x86, and unless it supports cross-compiling and you're building a cross-compile chroot instead of a qemu one, it's going to likely be quite slow to build on armhf | 21:41 |
| teward | dobey: and how are armhf builds currently done in the PPA builders? | 21:43 |
| dobey | teward: qemu | 21:44 |
| teward | dobey: ok. i'm running an x86 build now in sbuild, if it works there then hopefully the armhf ones do - it's the guile-2.0 source package that's the build-dep :/ | 21:52 |
| teward | and that FTBFS due to some threads error or something in precise armhf | 21:52 |
| dobey | is guile not included in precise archive already? | 21:53 |
| teward | dobey: for x86, yes. FTBFS in armhf | 21:53 |
| dobey | oh well | 21:54 |
| dobey | and the version in trusty fixes that? | 21:55 |
| teward | https://launchpad.net/ubuntu/+source/guile-2.0/2.0.5+1-1/+build/3245257 <-- log: https://launchpad.net/ubuntu/+source/guile-2.0/2.0.5+1-1/+build/3245257/+files/buildlog_ubuntu-precise-armhf.guile-2.0_2.0.5%2B1-1_FAILEDTOBUILD.txt.gz | 21:55 |
| teward | dobey: no idea, i haven't tested yet - the only way to know if it fixes the FTBFS is to run the arm build | 21:55 |
| dobey | well you said your package builds fine on trusty | 21:55 |
| dobey | so i presume that means guile is available on trusty arm | 21:55 |
| teward | mhm | 21:56 |
| dobey | and indeed the trusty package is available on armhf | 21:56 |
| teward | but not on precise armhf | 21:56 |
| dobey | so if you take the trusty package and build it on precise, it should work i think, unless there's another dependency issue that creates | 21:57 |
| dobey | well, no, it's trusty, not precise | 21:57 |
| dobey | you'd have to backport it to precise | 21:57 |
| teward | right | 21:58 |
| dobey | if it builds on precise armhf fine, then it might be worth asking to get it shipped as an update on precise | 21:58 |
| teward | dobey: right, but i don't have an armhf environment to test build in | 21:59 |
| teward | dobey: and no PPA to run that test in | 21:59 |
| teward | hence my conundrum | 21:59 |
| dobey | well i didn't know it was guile and the issue was that armhf build failed on precise in archive | 22:00 |
| dobey | so yeah, best way to test that is with an sbuild armhf builder (hopefully it can be cross-compiled, but i suspect it might not be possible) | 22:00 |
| mapreri | teward: just create an armhf chroot. it's easy with pbuilder, I guess it's easy with sbuild too. if you do a lot of this funny things you may ask access to stuff like debomatic-armhf.debian.net | 22:01 |
| teward | well the sbuild armhf builder i have crapped out before running any build | 22:01 |
| dobey | it's easy, it's just slow | 22:01 |
| teward | first, i'm checking to make sure amd64 builds | 22:01 |
| dobey | cross-compile is a lot faster | 22:01 |
| teward | and i386 | 22:01 |
| mapreri | that's a qemu issue, but yay | 22:01 |
| dobey | but not everything works with it | 22:01 |
| teward | dobey: FTBFS - configure.ac:41: require Automake 1.12, but have 1.11.3 | 22:26 |
| teward | dobey: so the backport is out of the question | 22:27 |
| teward | unless you know a way around that | 22:27 |
| dobey | backport automake :) | 22:28 |
| teward | dobey: at that point it becomes too much work for me to care | 22:30 |
| teward | wgrant: around? | 22:32 |
| mapreri | "require Automake 1.12, but have 1.11.3" that's silly. 1.12 < 1.13, yet, it fails. muh | 22:33 |
| teward | mapreri: remember, precise | 22:34 |
| dobey | mapreri: huh? | 22:34 |
| dobey | mapreri: 1.11.3 < 1.12 | 22:34 |
| dobey | 1.11.3 != 1.13 | 22:34 |
| mapreri | ah, ouch. sorry for the noise, misread the digits... | 22:35 |
| teward | dobey: i'll just separate out Precise from staging - saves me the headache of doing multiple backports just to make the one package build | 22:38 |
| teward | besides, no idea if automake 1.12 is reverse compatible | 22:38 |
| teward | don't want OTHER things to ftbfs anywhere | 22:39 |
| wgrant | teward: Hi | 22:41 |
| teward | wgrant: so yesterday you said to bug you to enable ARM in places. | 22:42 |
| teward | had a feeling you knew this would happen, but I need arm builds for another staging PPA - this time for a brand new staging PPA for ZNC that handles Trusty and newer | 22:43 |
| teward | since i know Precise would ftbfs | 22:43 |
| wgrant | Sure | 22:43 |
| teward | and i can actually avoid some... nasty things... by separating Precise out from the staging | 22:43 |
| teward | wgrant: https://launchpad.net/~teward/+archive/ubuntu/znc-staging-trusty+ is the one i'd like ARM builds on, if you can | 22:43 |
| wgrant | teward: Done. | 22:44 |
| teward | wgrant: thank you kindly | 22:44 |
| teward | wgrant: oopsies, i forgot to add a PPA dependency LOL (depwaits are evil) | 22:57 |
| wgrant | Luckily you can just add the dep and retry. | 22:58 |
| teward | wgrant: indeed - i forgot to define the PPA to depend on | 22:58 |
| teward | wgrant: HOPEFULLY i put the PPA dep in before the latest upload for that PPA got in - if not, well... there's a depwait | 22:58 |
| teward | again | 22:58 |
| wgrant | Depwaits are quick to fail and can be manually retried immediately, so that's not so bad. | 22:59 |
| teward | wgrant: indeed, although, if the depwaits are what i think it is, there'll be 3 depwaits for trusty upload to that ppa - i386, amd64, and armhf | 22:59 |
| teward | looks like I snuck it in XD | 23:00 |
| teward | right before it started | 23:00 |
| teward | wgrant: i had to cancel 2 armhf for the prior version in the system - the one that depwait'd i can't cancel, will it autocancel when it sees there's a newer version? | 23:00 |
| teward | or can you force it to just fail and not check again | 23:00 |
| wgrant | teward: Just ignore old depwaits. But you don't need to upload a new version just because the old one depwaited. | 23:06 |
| teward | wgrant: that's not the reason i uploaded a new wone | 23:06 |
| teward | wgrant: the new staging PPA means I don't have to define CXX in the debian/rules - it was defined because the previous staging PPA pulled in ppa:ubuntu-toolchain-r/test which has g++-4.9 - which breaks those actual releases other than Utopic/Vivid (which have the libraries) | 23:07 |
| wgrant | Ah, right. | 23:08 |
| teward | because unless CXX is defined correctly, it will actually use the highest g++ - 4.9 - which isn't present anywhere, and may cause libc problems | 23:08 |
| teward | wgrant: unlike nginx, I think these builds'll take about 45 - 50 minutes - based on the Vivid build time for 1.6.0-2 in the repos themselves | 23:08 |
| wgrant | teward: qemu-user times are pretty hard to predict, but we'll see. | 23:09 |
| teward | wgrant: and also - https://dev.launchpad.net/CommunityARMBuilds - do you really have >4 hr builds? | 23:09 |
| wgrant | Er yeah :) | 23:09 |
| wgrant | gcc, libreoffice, linux, eglibc... | 23:09 |
| wgrant | libreoffice takes like 6 hours even on a very modern fast amd64 machine. | 23:10 |
| wgrant | With 8 cores | 23:10 |
| wgrant | Let alone on a silly little ARM board. | 23:10 |
| wgrant | Or, worse, an ARM emulator. | 23:10 |
| teward | eurgh | 23:10 |
| teward | wgrant: betcha wireshark would take around that long - that thing's a BEAST | 23:11 |
| teward | although, IMO, anyone running Wireshark on an ARM board might have some... issues... other than lag and build time | 23:11 |
| wgrant | Heh, quite. | 23:12 |
| teward | i'd question the sanity of anyone running wireshark on ARM | 23:12 |
| teward | tshark, or a pure capture, i can understand. but not the gui | 23:12 |
| teward | wgrant: looks like it's working... | 23:29 |
| teward | slowly, but... working | 23:29 |
| === s8321414_ is now known as s8321414 | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!