[00:00] 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] Hm, really? [00:00] What's the error? [00:00] wgrant: well, see, I need it to rebuild in the staging PPAs [00:01] copy for rebuild says, "same version already has published binaries in the destination archive" [00:01] just spammed the hell out of myself with errors [00:01] Did you ensure that you selected the option to copy binaries, rather than to rebuild? [00:01] wgrant: there's no arm binaries yet [00:02] hence the need for a rebuild [00:02] or will it autobuild arm binaries [00:02] 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] ahh okay [00:02] so copy binaries to itself then, copy over to the other ppa as well then [00:03] after it sees it needs ARM builds [00:03] ok [00:03] 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] right [00:03] * teward expects to see 2 FTBFS shortly [00:03] It's qemu-user, so "shortly" may be over-optimistic, but we'll see. [00:03] well, 'shortly' as in when it runs [00:03] (we [00:04] 'll have proper ARM VMs Soon™, but getting enough capable hardware is harder than it looks) [00:04] 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] Hm, that seems unlikely. [00:04] precise's armhf port is excellent. [00:04] mm, i lied, it wasn't gcc [00:04] The only reason this might fail is that qemu-user doesn't like threads very much sometimes. [00:04] guile-2.0-dev is missing. check that in precise repos... [00:05] yeah that there's ftbfs in armhf [00:05] but ultimately, nginx should be fine, if all the main deps are present [00:06] the only thing i hate about the NGINX packaging is the 3rd party modules >.< [00:07] wgrant: i can disregard the complaints about copying failed, as its talking about i386 / amd64, not armhf, right? [00:07] ('cause building armhf right now) [00:07] You could probably have just backported a modern guile-2.0 to precise. There are no huge changes in vivid. [00:08] teward: I think those complaints are from the previous copies without binaries. [00:08] teward: Each copy is atomic, and the latest batch clearly worked. [00:09] mmm [00:09] wgrant: the FTBFS was the tests [00:09] https://launchpadlibrarian.net/102666041/buildlog_ubuntu-precise-armhf.guile-2.0_2.0.5%2B1-1_FAILEDTOBUILD.txt.gz [00:09] FAIL: test-with-guile-module, FAIL: test-pthread-create, FAIL: test-scm-spawn-thread (SEGV all around) [00:10] i'm too lazy to [00:10] it only affects the ZNC PPA anyways [00:13] wgrant: reminder, arch:all packages are arch-independent, right? [00:14] s/reminder/remind me/ [00:15] Yes. [00:15] They build on a single architecture, but are published on all. [00:18] right that's what i assumed [00:35] teward: Succeeded in just under half an hour. === reed_ is now known as reed [02:51] 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] Launchpad bug 1425324 in Nginx "[PPA] Please provide PPA builds/packages for armhf" [Wishlist,Fix committed] [02:51] teward: You don't need them on any other PPAs? [02:52] It's no problem to keep them enabled. My only concern is that they might not be enabled in enough places :) [02:53] 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:54] 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] 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] so meh [02:56] wgrant: so far, the only things I needed built for armhf were my swig3.0 backports PPA, and nginx. [02:56] nothing else on my radar for arm builds - only put nginx on the list because 5 emails today on it [02:57] :) [02:57] 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] wgrant: indeed. thanks. [02:57] wgrant: i should be extra glad though... nobody's asked me to set up arm builds for my wireshark backports ppa... xD [02:57] that'd... not go well [03:00] Heh [03:03] 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:04] except when i made a grave fail in package edits that forces me to reupload to fix xD [08:35] 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:36] this after the previous build failed, i found the problem, fixed it, but my new upload is rejected [08:36] what am i supposed to do? [08:37] ppisati: You need to change the version when you change the package. [08:37] wgrant: i feared that answer [08:38] 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] wgrant: well, abi checck is off [08:39] wgrant: anyhow, let me change the version [08:39] wgrant: but i don't really understand why you keep the previous diff around [08:39] ppisati: We don't keep it around, but it is remembered. [08:40] Each filename in a PPA references a unique file throughout time. [08:40] wgrant: os it's per PPA, right? [08:40] *so [08:40] ok [08:40] Changing the version when you change the package is normal good practice, not an onerous restriction. [08:40] ppisati: Right. [08:41] 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] anyway [08:41] no need to argue [08:41] The package did exist! [08:41] i bump the version === Odd_Blok1 is now known as Odd_Bloke === Mission-Critical is now known as MissionCritical [17:43] hrmm, not sure if anyone is around who would know the answer to this... [17:44] anyone know if there's a way to force LP to do the translations update commit to a branch? [17:46] wgrant: around? [17:46] (if not i won't bother you) [17:48] 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] cjwatson: that's what i thought. and it runs at like 00:00 UTC daily, iirc. [17:48] 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 === wedgwood1 is now known as wedgwood [21:32] 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:33] teward: just don't build for precise on that ppa then? [21:33] teward: you can't build for quantal, raring, or saucy anyway [21:34] dobey: ehh, to do *that*, I'd have to set up an ARM builds PPA to separate it from primary staging [21:34] for the software i'm packaging in question that is [21:34] except that I know why it FTBFS in precise - one of the build-deps is not built in Precise [21:35] so short of a backport which I'm too lazy to do... :P [21:35] (the FTBFS in precise are dep-waits) [21:35] just doa backport [21:36] 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:37] dobey: precise is the next schroot i'm building for the armhf environment, but... slow. [21:37] have to build each schroot after all [21:37] (I use sbuild) [21:37] teward: well, does it build on x86 precise? [21:37] i don't test builds on every arch. that would be annoying :) [21:40] dobey: haven't tested - the target is armhf, not x86, but i'll test after the sbuild schroot is done building [21:41] 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:43] dobey: and how are armhf builds currently done in the PPA builders? [21:44] teward: qemu [21:52] 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] and that FTBFS due to some threads error or something in precise armhf [21:53] is guile not included in precise archive already? [21:53] dobey: for x86, yes. FTBFS in armhf [21:54] oh well [21:55] and the version in trusty fixes that? [21:55] 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] 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] well you said your package builds fine on trusty [21:55] so i presume that means guile is available on trusty arm [21:56] mhm [21:56] and indeed the trusty package is available on armhf [21:56] but not on precise armhf [21:57] 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] well, no, it's trusty, not precise [21:57] you'd have to backport it to precise [21:58] right [21:58] if it builds on precise armhf fine, then it might be worth asking to get it shipped as an update on precise [21:59] dobey: right, but i don't have an armhf environment to test build in [21:59] dobey: and no PPA to run that test in [21:59] hence my conundrum [22:00] well i didn't know it was guile and the issue was that armhf build failed on precise in archive [22:00] 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:01] 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] well the sbuild armhf builder i have crapped out before running any build [22:01] it's easy, it's just slow [22:01] first, i'm checking to make sure amd64 builds [22:01] cross-compile is a lot faster [22:01] and i386 [22:01] that's a qemu issue, but yay [22:01] but not everything works with it [22:26] dobey: FTBFS - configure.ac:41: require Automake 1.12, but have 1.11.3 [22:27] dobey: so the backport is out of the question [22:27] unless you know a way around that [22:28] backport automake :) [22:30] dobey: at that point it becomes too much work for me to care [22:32] wgrant: around? [22:33] "require Automake 1.12, but have 1.11.3" that's silly. 1.12 < 1.13, yet, it fails. muh [22:34] mapreri: remember, precise [22:34] mapreri: huh? [22:34] mapreri: 1.11.3 < 1.12 [22:34] 1.11.3 != 1.13 [22:35] ah, ouch. sorry for the noise, misread the digits... [22:38] 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] besides, no idea if automake 1.12 is reverse compatible [22:39] don't want OTHER things to ftbfs anywhere [22:41] teward: Hi [22:42] wgrant: so yesterday you said to bug you to enable ARM in places. [22:43] 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] since i know Precise would ftbfs [22:43] Sure [22:43] and i can actually avoid some... nasty things... by separating Precise out from the staging [22:43] wgrant: https://launchpad.net/~teward/+archive/ubuntu/znc-staging-trusty+ is the one i'd like ARM builds on, if you can [22:44] teward: Done. [22:44] wgrant: thank you kindly [22:57] wgrant: oopsies, i forgot to add a PPA dependency LOL (depwaits are evil) [22:58] Luckily you can just add the dep and retry. [22:58] wgrant: indeed - i forgot to define the PPA to depend on [22:58] 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] again [22:59] Depwaits are quick to fail and can be manually retried immediately, so that's not so bad. [22:59] 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 [23:00] looks like I snuck it in XD [23:00] right before it started [23:00] 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] or can you force it to just fail and not check again [23:06] teward: Just ignore old depwaits. But you don't need to upload a new version just because the old one depwaited. [23:06] wgrant: that's not the reason i uploaded a new wone [23:07] 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:08] Ah, right. [23:08] 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] 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:09] teward: qemu-user times are pretty hard to predict, but we'll see. [23:09] wgrant: and also - https://dev.launchpad.net/CommunityARMBuilds - do you really have >4 hr builds? [23:09] Er yeah :) [23:09] gcc, libreoffice, linux, eglibc... [23:10] libreoffice takes like 6 hours even on a very modern fast amd64 machine. [23:10] With 8 cores [23:10] Let alone on a silly little ARM board. [23:10] Or, worse, an ARM emulator. [23:10] eurgh [23:11] wgrant: betcha wireshark would take around that long - that thing's a BEAST [23:11] although, IMO, anyone running Wireshark on an ARM board might have some... issues... other than lag and build time [23:12] Heh, quite. [23:12] i'd question the sanity of anyone running wireshark on ARM [23:12] tshark, or a pure capture, i can understand. but not the gui [23:29] wgrant: looks like it's working... [23:29] slowly, but... working === s8321414_ is now known as s8321414