[00:00] <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:01] <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:02] <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:03] <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:04] <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:05] <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:06] <teward> the only thing i hate about the NGINX packaging is the 3rd party modules >.<
[00:07] <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:08] <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:09] <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:10] <teward> i'm too lazy to
[00:10] <teward> it only affects the ZNC PPA anyways
[00:13] <teward> wgrant: reminder, arch:all packages are arch-independent, right?
[00:14] <teward> s/reminder/remind me/
[00:15] <wgrant> Yes.
[00:15] <wgrant> They build on a single architecture, but are published on all.
[00:18] <teward> right that's what i assumed
[00:35] <wgrant> teward: Succeeded in just under half an hour.
[02:51] <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] <wgrant> teward: You don't need them on any other PPAs?
[02:52] <wgrant> It's no problem to keep them enabled. My only concern is that they might not be enabled in enough places :)
[02:53] <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:54] <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:56] <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:57] <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
[03:00] <wgrant> Heh
[03:03] <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:04] <teward> except when i made a grave fail in package edits that forces me to reupload to fix xD
[08:35] <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:36] <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:37] <wgrant> ppisati: You need to change the version when you change the package.
[08:37] <ppisati> wgrant: i feared that answer
[08:38] <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:39] <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:40] <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:41] <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
[17:43] <dobey> hrmm, not sure if anyone is around who would know the answer to this...
[17:44] <dobey> anyone know if there's a way to force LP to do the translations update commit to a branch?
[17:46] <teward> wgrant: around?
[17:46] <teward> (if not i won't bother you)
[17:48] <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
[21:32] <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:33] <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:34] <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:35] <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:36] <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:37] <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:40] <teward> dobey: haven't tested - the target is armhf, not x86, but i'll test after the sbuild schroot is done building
[21:41] <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:43] <teward> dobey: and how are armhf builds currently done in the PPA builders?
[21:44] <dobey> teward: qemu
[21:52] <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:53] <dobey> is guile not included in precise archive already?
[21:53] <teward> dobey: for x86, yes.  FTBFS in armhf
[21:54] <dobey> oh well
[21:55] <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:56] <teward> mhm
[21:56] <dobey> and indeed the trusty package is available on armhf
[21:56] <teward> but not on precise armhf
[21:57] <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:58] <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:59] <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
[22:00] <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:01] <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:26] <teward> dobey: FTBFS - configure.ac:41: require Automake 1.12, but have 1.11.3
[22:27] <teward> dobey: so the backport is out of the question
[22:27] <teward> unless you know a way around that
[22:28] <dobey> backport automake :)
[22:30] <teward> dobey: at that point it becomes too much work for me to care
[22:32] <teward> wgrant: around?
[22:33] <mapreri> "require Automake 1.12, but have 1.11.3" that's silly. 1.12 < 1.13, yet, it fails. muh
[22:34] <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:35] <mapreri> ah, ouch. sorry for the noise, misread the digits...
[22:38] <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:39] <teward> don't want OTHER things to ftbfs anywhere
[22:41] <wgrant> teward: Hi
[22:42] <teward> wgrant: so yesterday you said to bug you to enable ARM in places.
[22:43] <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:44] <wgrant> teward: Done.
[22:44] <teward> wgrant: thank you kindly
[22:57] <teward> wgrant: oopsies, i forgot to add a PPA dependency LOL (depwaits are evil)
[22:58] <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:59] <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
[23:00] <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:06] <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:07] <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:08] <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:09] <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:10] <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:11] <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:12] <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:29] <teward> wgrant: looks like it's working...
[23:29] <teward> slowly, but... working