[01:11] hmm [01:11] are the gcc cross compilers built for all arches? [01:12] e.g. can i install arm-linux-gnueabihf-gcc on arm64? [01:33] mwhudson: gcc-*-cross arm64 builds produce an arm-linux-gnueabi cross-compiler, yes. [01:33] (not all arches, though. powerpc has no cross-compilers, and ppc64el only has powerpc) [01:34] wgrant: oh hm [01:37] wgrant: E: Unable to locate package arm-linux-gnueabihf-gcc [01:43] mwhudson: You mean gcc-arm-linux-gnueabihf? [01:43] The binary and package names are not quite the same. === Nigel_ is now known as G [03:09] wgrant: bah [03:09] :-) [03:51] hmm [03:51] so which packages do i need to install to run armhf stuff on arm64 [03:52] qemu-user ? [03:53] or possibly qemu-user-static [03:53] plus you'll need the userspace libraries etc if you're not running a full VM [03:54] lifeless: err [03:54] no, the cpu supports the 32 bit arm insns [03:54] this is more like running ia32 on amd64 [03:55] mwhudson: oh sorry, I read 'arm64' as 'amd64' [03:55] mwhudson: total fritzout [03:55] :) [03:55] so very easily done [03:55] so yeah in that case add the right multiarch [03:55] apt-get update [03:55] (about the best argument that people should have used aarch64 like arm wanted) [03:55] and then install the thing you want [03:56] *I think* [03:57] lifeless: seems plausible [04:33] 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] hm porter-arm64 has a wily-armhf chroot but no vivid one [04:35] guess that works [04:35] infinity: thanks for the cluebat to look for that :) [04:35] (wily-armhf)mwh@rugby:~/go/src$ ./trivial [04:35] Segmentation fault (core dumped) [04:36] progress! [04:36] Sort of. :) [04:39] libruntime,sync-atomic,math,runtime-cgo,sync.so [04:39] That's quite the library name. [04:40] shush you [04:40] THAT'S QUITE THE LIBRARY NAME. [04:50] Good morning [04:52] infinity: config is /etc/systemd/timesyncd.conf [04:52] uh huh does -Bsymbolic-functions on armhf only work with gold or something? [04:52] infinity: see man timesyncd.conf [04:53] infinity: merges> cool, thanks === Noskcaj changed the topic of #ubuntu-devel to: Archive: wily open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> vivid| #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: === Noskcaj changed the topic of #ubuntu-devel to: Archive: wily open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise -> vivid | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: [07:00] good morning [07:00] @pilot in === udevbot changed the topic of #ubuntu-devel to: Archive: wily open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise -> vivid | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: dholbach === OdyX_ is now known as OdyX [10:18] is it possible to get extra PPA or something with supported archs like ppc64el and arm64? [10:18] it would be much useful for patch testing [10:22] 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] cjwatson: ok, assuming: no at this moment. [10:23] indeed, unfortunately. but there is hope. [10:23] that's already something [10:24] 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] cjwatson: will be arm64/ppc64el available for all PPA users or only for extra ask? [10:26] ari-tczew: Initially, available on request. Once we're confident in it we'll probably make the architecture selection self-service. [10:27] Building just for x86 probably remains a reasonable default. [10:44] cjwatson: ok, thanks for the info [10:51] Anyone have an idea what could cause the difference between Debian and Ubuntu, regarding bug 1471741? [10:51] bug 1471741 in frosted (Ubuntu) "frosted FTBFS ImportError: No module named builtins" [Undecided,New] https://launchpad.net/bugs/1471741 === MacSlow is now known as MacSlow|lunch [11:47] 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] zyga, for context - https://jenkins.qa.ubuntu.com/job/wily-adt-django-testscenarios/lastBuild/ARCH=amd64,label=adt/console [11:52] jamespage: re [11:52] jamespage: yes [11:52] jamespage: looking [11:53] jamespage: that looks like assertions on how django manages transactions [11:53] jamespage: perhaps new django has changed behavior there [11:53] zyga, well it was new testtools which triggers the failure - confirmed that [11:53] jamespage: ah [11:53] jamespage: ok, let me look again then [11:53] zyga, other problems I've seen where caused by testtools always using unittest2 as its base now [11:54] zyga, thankyou - much appreciated [11:54] jamespage: how is that causing problems? [11:54] zyga, we had one issue where using unittest.skipTest was not working [11:54] zyga, that's probably not related to this [11:54] jamespage: mm [11:54] jamespage: unittest.skipTest or unittest2.skipTest? [11:55] zyga, https://bugs.launchpad.net/bugs/1467558 [11:55] Ubuntu bug 1467558 in testtools "testtools.skip decorator not functional with unittest.TestCase as base class" [Undecided,New] [11:55] that's the bug [11:55] ah [11:55] I'm not using testtools anymore so I'm not up to date, let me see django-testscenarios first [11:59] jamespage: hmm, so whatever is causing this [11:59] jamespage: the tests fail because django constraints on how transaction tests are started don't work [11:59] jamespage: that might be testscenarios or testscenarios + django-testscenarios [12:00] jamespage: or all that + new django [12:00] jamespage: how can I reproduce that? [12:00] jamespage: wily? [12:01] @pilot out === udevbot changed the topic of #ubuntu-devel to: Archive: wily open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise -> vivid | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: === psivaa is now known as psivaa-afk [12:19] pitti, https://launchpadlibrarian.net/210709148/buildlog_ubuntu-trusty-amd64.python-apt_0.9.3.5ubuntu1_BUILDING.txt.gz again changed proxy setup? [12:20] doko: buildds are cjwatson and wgrant's domains, but I suppose it could be related to moving builds to scalingstack? [12:20] doko: that certainly looks like a bad/missing $no_proxy === _salem is now known as salem_ [12:32] zyga, yeah - wily with testtools from proposed === MacSlow|lunch is now known as MacSlow [13:01] hello [13:02] anyone has a ubuntu tablet or phone? [13:02] if so, please test my app https://uappexplorer.com/app/analyticaltranslatordemo.xpheresdev [13:03] there's no way I can make the emulator work [13:03] good morning! === marcusto_ is now known as marcustomlinson [13:19] pitti: that build isn't in scalingstack [13:21] 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] sil2100, hi, can I land appmenu-qt5 myself? [14:01] mitya57: hey! There's one more fix I want to target, but I'm not entirely done yet [14:01] Ok, no problem [14:43] does anyone knows if there are people working to fix the emulator? [14:45] xpheres: 'emulator'? [14:45] yes for ubuntu touch [14:45] I'm developing an app [14:45] but I have to do it blind [14:45] or asking for help to people who have ubuntu mobiles [14:45] 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] a pitty [14:46] 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] gui sorry [14:47] and I can not afford an ubuntu phone right now [15:11] 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] well, bugs and translations [15:18] cjwatson: I'm around fwiw [15:21] 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] cjwatson, pitti: https://launchpad.net/ubuntu-rtm/15.04 - status is currently 'future' [15:21] cjwatson: er, I mean 'experimental' [15:22] I think either of those statuses is fine [15:22] slangasek: could you do the same on qastaging? [15:22] https://code.launchpad.net/~cjwatson/launchpad/phone-overlay-translations/+merge/263819 is the immediate driver for this FWIW [15:26] cjwatson: also done [15:35] slangasek: thanks [15:38] cjwatson: sorted now, right? [15:43] pitti: Yep, thanks === roaksoax_ is now known as roaksoax [16:14] slangasek: do you have some minutes today to re-review https://code.launchpad.net/~pitti/britney/britney2-ubuntu-amqp/+merge/263679 ? [16:14] slangasek: I have another branch with teh corresponding results collection, I did a run on britney with that [16:15] this triggered 430 tests which the poor underpowered scalingstack is grinding through now, but that's a nice smoketest :) [16:15] (I'll submit that MP after landing the AMQP bits) [16:18] * pitti waves good night [16:23] pitti: yes, re-reviewed and merged. [16:23] pitti: are you ready for this to be rolled out to production, or do you want to be around for that? === imcleod is now known as imcleod-lunch [16:54] slangasek: thanks for reviewing! [16:54] slangasek: should be fine, with the actual config files it should be a no-op [16:54] slangasek: but please don't roll it out yet, as the current backlog is huge (see above) [16:54] slangasek: I'd like to give it a day or two to settle down [16:55] queues are at 340, from 430 from ~ 4 hours ago [16:55] 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] (but there's no hurry to do so) [16:56] I'll get the swift MP ready tomorrow [16:56] pitti: ok; I'll roll it out all the same just so it's done [17:00] cjwatson, hmm, do seeds know about multiarch ? [17:01] * ogra_ needs to seed libc:i386 into the amd64 snappy images somehow [17:01] (or infinity ^^) [17:10] ogra_: No [17:10] hmpf, k ... [17:10] That is Hard (TM) [17:10] yeah ... [17:10] Probably better to just force it in from livecd-rootfs [17:10] and i guess add-apt-package in live-build wont handle it either [17:10] Or whatever [17:10] Not sure, experiment :) [17:10] (locally!) [17:10] haha [17:11] worst case i can make a metapackage that depends on it ... but i'd rather not === imcleod-lunch is now known as imcleod [18:04] 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] 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! === salem_ is now known as _salem === _salem is now known as salem_ [21:58] hi, what kernel version is planned to be shipped with Wily ? [22:01] soee: looks like 4.0 or 4.1 https://lists.ubuntu.com/archives/ubuntu-devel/2015-May/038770.html [22:01] sarnold: ok, thank you for the information === salem_ is now known as _salem [22:39] soee: I think 4.2 was the plan, actually. [22:39] sarnold: ^ [22:40] infinity: man I feel old [22:40] ;] [23:25] 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] hm, so i've gotten as far as installing enough bits on my arm64 system that i can run exectuables [23:32] but how can i debug them? [23:33] gdb says unhelpful things like [23:33] warning: Selected architecture arm is not compatible with reported target architecture aarch64 [23:33] i guess i can just make a chroot [23:51] cyphermox: be my guest [23:51] cyphermox: ill take a look though [23:51] adt-run [21:55:24]: test daemon: [----------------------- [23:51] ERROR: tgtd IS NOT RUNNING [23:52] adt-run [21:55:25]: test daemon: -----------------------] [23:52] I can't think that needs much of a special setup to test why it's broken. :P [23:55] And, indeed, installing tgt doesn't start it.