[01:11] <mwhudson> hmm
[01:11] <mwhudson> are the gcc cross compilers built for all arches?
[01:12] <mwhudson> e.g. can i install arm-linux-gnueabihf-gcc on arm64?
[01:33] <wgrant> mwhudson: gcc-*-cross arm64 builds produce an arm-linux-gnueabi cross-compiler, yes.
[01:33] <wgrant> (not all arches, though. powerpc has no cross-compilers, and ppc64el only has powerpc)
[01:34] <mwhudson> wgrant: oh hm
[01:37] <mwhudson> wgrant: E: Unable to locate package arm-linux-gnueabihf-gcc
[01:43] <wgrant> mwhudson: You mean gcc-arm-linux-gnueabihf?
[01:43] <wgrant> The binary and package names are not quite the same.
[03:09] <mwhudson> wgrant: bah
[03:09] <mwhudson> :-)
[03:51] <mwhudson> hmm
[03:51] <mwhudson> so which packages do i need to install to run armhf stuff on arm64
[03:52] <lifeless> qemu-user ?
[03:53] <lifeless> or possibly qemu-user-static
[03:53] <lifeless> plus you'll need the userspace libraries etc if you're not running a full VM
[03:54] <mwhudson> lifeless: err
[03:54] <mwhudson> no, the cpu supports the 32 bit arm insns
[03:54] <mwhudson> this is more like running ia32 on amd64
[03:55] <lifeless> mwhudson: oh sorry, I read 'arm64' as 'amd64'
[03:55] <lifeless> mwhudson: total fritzout
[03:55] <mwhudson> :)
[03:55] <mwhudson> so very easily done
[03:55] <lifeless> so yeah in that case add the right multiarch
[03:55] <lifeless> apt-get update
[03:55] <mwhudson> (about the best argument that people should have used aarch64 like arm wanted)
[03:55] <lifeless> and then install the thing you want
[03:56] <lifeless> *I think*
[03:57] <mwhudson> lifeless: seems plausible
[04:33] <infinity> mwhudson: Shouldn't need to install anything at all, if you're doing it in an armhf chroot.  If not then, yes, you'd need to add armhf as a secondary arch and install whatever bits you want.
[04:35] <mwhudson> hm porter-arm64 has a wily-armhf chroot but no vivid one
[04:35] <mwhudson> guess that works
[04:35] <mwhudson> infinity: thanks for the cluebat to look for that :)
[04:35] <mwhudson> (wily-armhf)mwh@rugby:~/go/src$ ./trivial
[04:35] <mwhudson> Segmentation fault (core dumped)
[04:36] <mwhudson> progress!
[04:36] <infinity> Sort of. :)
[04:39] <infinity> libruntime,sync-atomic,math,runtime-cgo,sync.so
[04:39] <infinity> That's quite the library name.
[04:40] <mwhudson> shush you
[04:40] <infinity> THAT'S QUITE THE LIBRARY NAME.
[04:50] <pitti> Good morning
[04:52] <pitti> infinity: config is /etc/systemd/timesyncd.conf
[04:52] <mwhudson> uh huh does -Bsymbolic-functions on armhf only work with gold or something?
[04:52] <pitti> infinity: see man timesyncd.conf
[04:53] <pitti> infinity: merges> cool, thanks
[07:00] <dholbach> good morning
[07:00] <dholbach> @pilot in
[10:18] <ari-tczew> is it possible to get extra PPA or something with supported archs like ppc64el and arm64?
[10:18] <ari-tczew> it would be much useful for patch testing
[10:22] <cjwatson> ari-tczew: arm64 is possible, but only via qemu-user-static, which doesn't work on that well for a lot of things.  But we hope to be able to fix this very soon - a POWER-based builder cloud is almost working, and we have the hardware installed to do the same for ARM shortly afterwards
[10:22] <ari-tczew> cjwatson: ok, assuming: no at this moment.
[10:23] <cjwatson> indeed, unfortunately.  but there is hope.
[10:23] <ari-tczew> that's already something
[10:24] <cjwatson> I expect that within a small number of months both Ubuntu and (virtualised) PPAs will be building on the same infrastructure, and then it's easy.
[10:25] <ari-tczew> cjwatson: will be arm64/ppc64el available for all PPA users or only for extra ask?
[10:26] <cjwatson> ari-tczew: Initially, available on request.  Once we're confident in it we'll probably make the architecture selection self-service.
[10:27] <cjwatson> Building just for x86 probably remains a reasonable default.
[10:44] <ari-tczew> cjwatson: ok, thanks for the info
[10:51] <hjd> Anyone have an idea what could cause the difference between Debian and Ubuntu, regarding bug 1471741?
[11:47] <jamespage> zyga, around? I'm debugging a test failure in django-testscenarios with new python-testtools in wily and the failures have me scratching my head
[11:47] <jamespage> zyga, for context - https://jenkins.qa.ubuntu.com/job/wily-adt-django-testscenarios/lastBuild/ARCH=amd64,label=adt/console
[11:52] <zyga> jamespage: re
[11:52] <zyga> jamespage: yes
[11:52] <zyga> jamespage: looking
[11:53] <zyga> jamespage: that looks like assertions on how django manages transactions
[11:53] <zyga> jamespage: perhaps new django has changed behavior there
[11:53] <jamespage> zyga, well it was new testtools which triggers the failure - confirmed that
[11:53] <zyga> jamespage: ah
[11:53] <zyga> jamespage: ok, let me look again then
[11:53] <jamespage> zyga, other problems I've seen where caused by testtools always using unittest2 as its base now
[11:54] <jamespage> zyga, thankyou - much appreciated
[11:54] <zyga> jamespage: how is that causing problems?
[11:54] <jamespage> zyga, we had one issue where using unittest.skipTest was not working
[11:54] <jamespage> zyga, that's probably not related to this
[11:54] <zyga> jamespage: mm
[11:54] <zyga> jamespage: unittest.skipTest or unittest2.skipTest?
[11:55] <jamespage> zyga, https://bugs.launchpad.net/bugs/1467558
[11:55] <jamespage> that's the bug
[11:55] <zyga> ah
[11:55] <zyga> I'm not using testtools anymore so I'm not up to date, let me see django-testscenarios first
[11:59] <zyga> jamespage: hmm, so whatever is causing this
[11:59] <zyga> jamespage: the tests fail because django constraints on how transaction tests are started don't work
[11:59] <zyga> jamespage: that might be testscenarios or testscenarios + django-testscenarios
[12:00] <zyga> jamespage: or all that + new django
[12:00] <zyga> jamespage: how can I reproduce that?
[12:00] <zyga> jamespage: wily?
[12:01] <dholbach> @pilot out
[12:19] <doko> pitti, https://launchpadlibrarian.net/210709148/buildlog_ubuntu-trusty-amd64.python-apt_0.9.3.5ubuntu1_BUILDING.txt.gz  again changed proxy setup?
[12:20] <pitti> doko: buildds are cjwatson and wgrant's domains, but I suppose it could be related to moving builds to scalingstack?
[12:20] <pitti> doko: that certainly looks like a bad/missing $no_proxy
[12:32] <jamespage> zyga, yeah - wily with testtools from proposed
[13:01] <xpheres> hello
[13:02] <xpheres> anyone has a ubuntu tablet or phone?
[13:02] <xpheres> if so, please test my app https://uappexplorer.com/app/analyticaltranslatordemo.xpheresdev
[13:03] <xpheres> there's no way I can make the emulator work
[13:03] <cyphermox> good morning!
[13:19] <cjwatson> pitti: that build isn't in scalingstack
[13:21] <cjwatson> doko: there are no proxy-related environment variables set by the builder (see the "User Environment" section), so anything here must be set by the build itself
[14:01] <mitya57> sil2100, hi, can I land appmenu-qt5 myself?
[14:01] <sil2100> mitya57: hey! There's one more fix I want to target, but I'm not entirely done yet
[14:01] <mitya57> Ok, no problem
[14:43] <xpheres> does anyone knows if there are people working to fix the emulator?
[14:45] <teward> xpheres: 'emulator'?
[14:45] <xpheres> yes for ubuntu touch
[14:45] <xpheres> I'm developing an app
[14:45] <xpheres> but I have to do it blind
[14:45] <xpheres> or asking for help to people who have ubuntu mobiles
[14:45] <davmor2> xpheres: known issue it is being looked at but it is pretty low level stuff so might take a while to fix completely, ref emulator
[14:45] <xpheres> a pitty
[14:46] <xpheres> I won't work anymore with ubuntu apps till is fixed, I can not see the results and many weird stuff appears in the guy
[14:46] <xpheres> gui sorry
[14:47] <xpheres> and I can not afford an ubuntu phone right now
[15:11] <cjwatson> pitti: still around?  we could use a ~techboard member to create a "15.04" series for us in ubuntu-rtm, status "Future" (won't be used for publishing, just for bug tracking)
[15:11] <cjwatson> well, bugs and translations
[15:18] <slangasek> cjwatson: I'm around fwiw
[15:21] <cjwatson> slangasek: ah, you want to do the honours then?  should be straightforward on https://launchpad.net/ubuntu-rtm/+addseries if you agree with this work, we don't need the complex derived series initialisation here
[15:21] <slangasek> cjwatson, pitti: https://launchpad.net/ubuntu-rtm/15.04 - status is currently 'future'
[15:21] <slangasek> cjwatson: er, I mean 'experimental'
[15:22] <cjwatson> I think either of those statuses is fine
[15:22] <cjwatson> slangasek: could you do the same on qastaging?
[15:22] <cjwatson> https://code.launchpad.net/~cjwatson/launchpad/phone-overlay-translations/+merge/263819 is the immediate driver for this FWIW
[15:26] <slangasek> cjwatson: also done
[15:35] <cjwatson> slangasek: thanks
[15:38] <pitti> cjwatson: sorted now, right?
[15:43] <cjwatson> pitti: Yep, thanks
[16:14] <pitti> slangasek: do you have some minutes today to re-review https://code.launchpad.net/~pitti/britney/britney2-ubuntu-amqp/+merge/263679 ?
[16:14] <pitti> slangasek: I have another branch with teh corresponding results collection, I did a run on britney with that
[16:15] <pitti> this triggered 430 tests which the poor underpowered scalingstack is grinding through now, but that's a nice smoketest :)
[16:15] <pitti> (I'll submit that MP after landing the AMQP bits)
[16:18]  * pitti waves good night
[16:23] <slangasek> pitti: yes, re-reviewed and merged.
[16:23] <slangasek> pitti: are you ready for this to be rolled out to production, or do you want to be around for that?
[16:54] <pitti> slangasek: thanks for reviewing!
[16:54] <pitti> slangasek: should be fine, with the actual config files it should be a no-op
[16:54] <pitti> slangasek: but please don't roll it out yet, as the current backlog is huge (see above)
[16:54] <pitti> slangasek: I'd like to give it a day or two to settle down
[16:55] <pitti> queues are at 340, from 430 from ~ 4 hours ago
[16:55] <pitti> slangasek: err, sorry -- of course you can roll it out, it won't actually do requests until we set the amqp config option
[16:55] <pitti> (but there's no hurry to do so)
[16:56] <pitti> I'll get the swift MP ready tomorrow
[16:56] <slangasek> pitti: ok; I'll roll it out all the same just so it's done
[17:00] <ogra_> cjwatson, hmm, do seeds know about multiarch ?
[17:01]  * ogra_ needs to seed libc:i386 into the amd64 snappy images somehow 
[17:01] <ogra_> (or infinity ^^)
[17:10] <cjwatson> ogra_: No
[17:10] <ogra_> hmpf, k ...
[17:10] <cjwatson> That is Hard (TM)
[17:10] <ogra_> yeah ...
[17:10] <cjwatson> Probably better to just force it in from livecd-rootfs
[17:10] <ogra_> and i guess add-apt-package in live-build wont handle it either
[17:10] <cjwatson> Or whatever
[17:10] <cjwatson> Not sure, experiment :)
[17:10] <cjwatson> (locally!)
[17:10] <ogra_> haha
[17:11] <ogra_> worst case i can make a metapackage that depends on it ... but i'd rather not
[18:04] <gordon_> Hello! I initially came here to look for hire to get involved page but I guess I've found nice link in topic. https://wiki.ubuntu.com/HelpingWithBugs I will give something to fix and then ask again :)
[19:24] <mterry> happyaron, hello!  I am looking at fcitx-unikey for main inclusion, and I happened to notice a small typo.  in debian/copyright, the first copyright stanza description should mention GPL 3 instead of GPL 2.  That's all!
[21:58] <soee> hi, what kernel version is planned to be shipped with Wily ?
[22:01] <sarnold> soee: looks like 4.0 or 4.1 https://lists.ubuntu.com/archives/ubuntu-devel/2015-May/038770.html
[22:01] <soee> sarnold: ok, thank you for the information
[22:39] <infinity> soee: I think 4.2 was the plan, actually.
[22:39] <infinity> sarnold: ^
[22:40] <sarnold> infinity: man I feel old
[22:40] <soee> ;]
[23:25] <cyphermox> zul: are you aware that tgt you merged a month ago is still in -proposed? I'd like to fix the test so it works properly, since it blocks other stuff, but I don't have anything to run proper testing of the pacakge
[23:32] <mwhudson> hm, so i've gotten as far as installing enough bits on my arm64 system that i can run exectuables
[23:32] <mwhudson> but how can i debug them?
[23:33] <mwhudson> gdb says unhelpful things like
[23:33] <mwhudson> warning: Selected architecture arm is not compatible with reported target architecture aarch64
[23:33] <mwhudson> i guess i can just make a chroot
[23:51] <zul> cyphermox: be my guest
[23:51] <zul> cyphermox: ill take a look though
[23:51] <infinity> adt-run [21:55:24]: test daemon: [-----------------------
[23:51] <infinity> ERROR: tgtd IS NOT RUNNING
[23:52] <infinity> adt-run [21:55:25]: test daemon: -----------------------]
[23:52] <infinity> I can't think that needs much of a special setup to test why it's broken. :P
[23:55] <infinity> And, indeed, installing tgt doesn't start it.