User1: User13 I imagine this is now published? https://launchpad.net/ubuntu/+source/pkgbinarymangler/127/+build/8801747
User1: oh it's you doko :)
User1: Could someone please retry the AMD64 build of ecere-sdk on Xenial now? https://launchpad.net/ubuntu/xenial/+source/ecere-sdk
User2: User18 hi, so the xubuntu thing hadn't been a concern about package names, but rather image names.  I'm pretty sure we talked through that and reached a resolution, and now there's just the matter of getting their livecd-rootfs changes reviewed and merged
User2: User18 "Subject:  Best Windows Replacement Deals of the Year- Available Now.=" -- that your mail to the TB? ;)
User2: User18 (messages approved)
User1: This annoying Unity Alt-F (for my app) bug popping up the Unity dash board that I had reported and was supposed to be fixed is apparently still there in 15.04
User3: ESphynx, 15.04 will be end-of-life in a few weeks, you should upgrade!
User4: User6 Ping, re: lts-w X stack.  Time's running out.
User1: User3 15.10 I mean, sorry
User1: User3 also, seriously annoyed that upgrades put back Unity as my default WM
User3: ESphynx, how did you set your default WM?
User1: or maybe it didn't
User1: I have a drop down and normally do GNOME Classic, I think 'Ubuntu (Default)' got selected by default (i.e. just entering password at login screen)
User3: that should not be reset on upgrades
User1: 2 other major issues I have with Ubuntu is A) always puts my backlit keyboard on bootup, and can't even turn it down before login (and every login turns it back on) and B) Does not remember my choice of deactivating the Touch Pad when a mouse is plugged in
User3: ESphynx, file bugs, not whine on IRC!
User3: a. might be a kernel issue
User1: User3 bugs take considerable time to file and it just depresses me when they get ignored for years :P
User1: re: a), not that I can use the keyboard keys to turn it 'off' once logged in
User1: note*
User3: ESphynx, use `ubuntu-bug <package>` should only take a couple of minutes
User3: if they are ignored after a while send an email to relevant email list linking to your bugs
User1: User3 finding what package is responsible in those cases would take me a while :)
User3: a.) likely kernel b.) possible gnome-settings-daemon
User1: thanks. will take note and may end up filing bugs :P
User1: you don't happen to have rights to re-schedule a failed build, do you? ;)
User3: probably not unless its part of ubuntu GNOME or -desktop packagesets
User1: ah, no it's not, but thanks!
User5: User1 I can retry a failed build for you, as long as you are sure it will succeed. What package?
User1: User5 https://launchpad.net/ubuntu/xenial/+source/ecere-sdk
User1: User5 doko published a fix earlier for pkgbinarymangler which should theoretically fix the failed build
User5: User1 Which version?
User1: User5 this amd64 build  https://launchpad.net/ubuntu/+source/ecere-sdk/0.44.13-1/+build/8791598
User1: the 'all' architecture is actually what was failing due to the PNG optimization code
User5: User1 Ok, retried.
User1: thank you!
User5: You're welcome.
User1: doko, User5 it failed again... :( It does seem to be using pkgbinarymangler 127 which was supposed to fix this ( https://launchpadlibrarian.net/232975999/buildlog_ubuntu-xenial-amd64.ecere-sdk_0.44.13-1_BUILDING.txt.gz )
User5: User1 Ah that sucks. I'm not familiar with that package, so don't feel I can be any further help sorry.
User1: User5 thanks, will ping doko again tomorrow :)
User6: User4 bug 1519753 is there for libdrm which needs to go in first
User7: bug 1519753 in libdrm (Ubuntu Trusty) "Please backport libdrm for 14.04.4" [High,In progress] https://launchpad.net/bugs/1519753
User8: Good morning
User8: User13 for gcc-5? well, because they do fail..
User8: User13 but the rebuild test succeeds, so good enough for gcc, I'll hint it
User8: User9 I just saw commit 803 in hints-ubuntu -- i. e. we actually do need a manual hint for perl transitions?
User9: User8 no, if it was "unblock" there must have been a freeze in progress at the time or something
User8: User9 yes, it was "unblock"
User8: User9 ah, so these are not manual hints, just counter freeze hints; check
 * pitti wonders how he can convince britney to let systemd and ifupdown in -- they have a mutual Breaks:, but otherwise work fine
User8: I tested a dist-upgrade from wily to xenial-proposed
User9: User8 probably "easy systemd/blah ifupdown/blah" then
User8: User9 ah, thanks; this type of hint is/was new to me
User9: User8 The current autohint seems to be getting there, but still 129 extra uninstallables.  I'll poke at it some more after breakfast.
User9: User8 I've poked it along a reasonable amount.  One problem is that the new uwsgi needs new php5, which is blocked on various autopkgtest failures; any chance you could have a look at those?
User9: User8 (also it needs insighttoolkit4 to build on amd64, an unfortunate casualty of Swift problems during the break, which I've retried but usually takes something like 18 hours)
User8: User9 I did over the holidays; we could decide to ignore all those, but it seems the new php actually does break a whole lot of stuff :(
 * pitti retries those without apt pinning, maybe a few of them will work
User9: Deliberate language changes, or bugs?
User8: "Missing PHP extension "http" or wrong version!" might be due to apt pinning
User8: but I didn't see a pattern there, they fail due to dozens of different causes
User9: maybe worth punting to mdeslaur as the person who merged php5
User9: can also temporarily remove uwsgi from the release pocket to disentangle these, but let's see
User8: uwsgi has reverse dependencies, though
User8: I remember that this was one of the remaining hard ones on http://people.canonical.com/~ubuntu-archive/transitions/html/html/perl5.22.html
User9: a few, yes
User8: retried the php tests (without pinning), but queues are also Qt-DoSed, will take a bit
User9: it was previously hard on the transition tracker because it depended on libcoro-perl, but the sync from unstable disentangled those
User8: in the meantime I'll run them against release and see which ones are actual regressions
User8: User9 right; I tried to remove libcoro from it (as discussed in the Debian bug), but gave up after an hour or so; fortunately the Debian maintainer did it the next day :)
User9: so I think the only remaining issues are geneweb (tangled with ocaml issues on s390x, but I might just remove the geneweb/s390x binary), waiting for all the pending builds, and uwsgi/php5
User8: geneweb has no reverse deps, so that sounds fine
User9: I want to see if it can be fixed properly before doing that though
User8: User9 oh, arm64 distro builds are now on bos, with more capacity -- nice!
User9: User8 it's a hideous hack (we're treating virtualised builders as nonvirt, because that way we don't run into all the reset bugs), but does the job for now
User8: I can reproduce the php5 regressions locally; e. g. "adt-run php-doctrine-bundle" succeeds, "adt-run --apt-pocket=proposed=src:php5 -U php-doctrine-bundle" failsl
User8: interestingly it succeeds in Debian
User8: User9 oh, there are a couple of php module FTBFS, I'll look at those; they explain at least part of the regressions
User10: pitti, can you please restart qtmir with qtmir-gles trigger http://autopkgtest.ubuntu.com/packages/q/qtmir/xenial/i386/
User10: /we need to look into that test, starts looking unstable
User8: User10 queued
User10: thanks
User8: User10 but it will take a while, cf. the rather large queue on http://autopkgtest.ubuntu.com/running.shtml
User10: ack
User8: . o O { can we just test everything on s390x? :-)
User8: User9 I'm creating a nice long list of php module related FTBFS/depwaits, now in a nice phpunit-mock-object <-> phpunit circular build dep; I'll see to untangle this
User8: dear debian, please stop allowing arch:all uploads, kthxbye
User9: User8 I wanted to bootstrap that ages ago, but I've been blocked on infinity adding the usual bootstrap archive back to the xenial amd64 chroot
User9: User8 you probably *could* disentangle those manually, but it sucks to have to
User9: i.e. via uploads
User9: leaves garbage in the archive
User8: I'm trying to build phpunit with the older phpunit-mock-object, if that fails I'll just temporarily disable its tests, let both build, and re-enable them
User8: ATM it fails for an entirely different reason, meh
User11: User12 Did you see gaughen's email asking if you're ready for s390x cloud images to be built?
User8: User11 speaking of which, what's the word on xenial cloud images (for other arches)?
User8: User11 and happy new year!
User11: User8 Happy New Year!
User11: User8 So we are building xenial cloud images using the old system at the moment, which should work as you expect.
User8: User11 I mean http://cloud-images.ubuntu.com/xenial/ has Dec 18 as latest image
User11: User8 Oh, hm.
User11: User8 It looks like we've been publishing that image to clouds since December 18th; let me work out what's going on.
User11: User8 OK, that's unwedged now.
User8: User11 nice, thanks!
User11: User8 So I'll let this next build go through, then I'll be plumbing the new system in (which will probably break everything for a few days :p).
User12: Odd_Bloke, hm... yes =) i just have.
User12: Odd_Bloke, yo, send a reply. Yes, we can start building series of bytes that resemble a cloud image =)
User12: Odd_Bloke, do you have ability to add hooks and things in the initramfs?
User11: User12 I haven't done it myself, but I assume that dropping stuff in /etc/initramfs-tools/... and then running something in a chroot would do the trick?
User12: Odd_Bloke, ok. I'll think about it. I think we will need s390-cloud-init or some such package (or changes to sysconfig-hardware) which will activate first NIC and first DASD drive (for example) on first boot, and remember that persistently, when no other NICs/Drives are configured.
User12: Odd_Bloke, or e.g. change sysconfig-hardware to take hints from kernel cmdline or some such.
User12: Odd_Bloke, anyway, does my email sound clear at all? to e.g. produce "a series of bytes that look like a cloud-image" ? =)
User11: User12 Yep, it does (to me at least :p).
User13: xnox, are you looking at the cython ftbfs issue?
User12: doko, yes, i believe it's a bug with asyncio module and regression in python.
User12: doko, as it used to build with earlier 3.4 python.
User12: but i didn't bisect it yet, to hand over to you / upstream.
User13: earlier 3.4 or 3.5?
User14: cython uses asyncio?
User13: at least some test case
User15: cython implements asyncio, also in python3.4
User14: neat
User15: so you should be able to use await et. al. probably also in python2
User15: (never tested it though)
User9: User8 Can you work out what's up with http://autopkgtest.ubuntu.com/packages/d/debci/xenial/s390x/ ?
User9: (blocking librabbitmq -> kamailio -> perl)
User8: User9 will do
User9: thanks
User8: ok, it seems I finally untangled phpunit, mass-retrying the failed php builds
User9: nice
User9: I fixed findlib on s390x, so a bunch of retries going through for that too
User8: User9 btw, are your lcy builders still busted? (most of them are "cleaning")
User8: User9 my lcy instances are sometimes brittle, but they by and large survived over the holidays (I was quite surprised)
User9: User8 looks like it, our clouds are in various pieces
User8: lgw seems to be back (was broken yesterday)
User16: User8 infinity promised to fix the phpunit-mock-object <-> phpunit circular build depends before the holidays...
User16: User8 I was waiting on that to see how many php5 stuff would then pass
User8: User16 good morning, happy new year!
User8: User16 indeed, it was phpunit-mock-objejct, phpunit, and php-codecoverage circularly depending
User8: User16 but it seems they work now; I'll revert the changes once britney settles down (I have the uploads locally prepared)
User16: User8 happy new year to you too! :)
User16: User8 awesome, thanks for fixing that!
User17: hey pitti, I guess noone reported any problems with fix for bug 1337873 on xenial, do you think we're good to proceed with earlier releases?
User7: bug 1337873 in ifupdown (Ubuntu Vivid) "Precise, Trusty, Utopic - ifupdown initialization problems caused by race condition" [Medium,Confirmed] https://launchpad.net/bugs/1337873
User18: thanks slangasek
User13: dholbach, User20 any update on the boost1.58-mpisource package?
User19: User13 I thought LocutusOfBorg1 would look into it
User19: User20 AFAICT the boost1.58-mpi source package needs to be updated to have the same contents and version number as boost1.58
User8: User17 yes, I think so
User17: User8 cool, could you please sponsor it?
User8: User17 yes, can do; I'll skip vivid though, that's going to be EOL in two or three weeks
User17: User8 sounds good, thank you
User8: User17 why is https://launchpadlibrarian.net/221884579/trusty_ifenslave_2.4ubuntu1.2.debdiff necessary for trusty, but not for precise or wily?
User17: User8 the fix is only for 14.04+ and wily's ifenslave already has the necessary change
User8: User17 ah, and there is no precise patch yet, I see
User17: User8 that's right, there are so many differences in implementation that I was not able to backport it without backporting half of trusty ifupdown
User8: User17 so I guess we just don't care for precise; after all, it has lived for so long without this that it hardly matters
User8: User17 sponsored and bug updated
User17: User8 thanks!
User20: doko, I'm doing some other work, I''ll look at it soon (TM)
User8: User9 FYI, that's debian bug 809265, race condition in the test
User7: Debian bug 809265 in src:debci "debci: FTBFS: ./test_blame.sh failed at least one test (test_passing_the_test_resets_the_blame?)" [Serious,Open] http://bugs.debian.org/809265
User8: User9 so if this unblocks stuff, I'm happy to ignore it for now
User8: User9 (but looking at it right now anyway)
User9: User8 Yeah, it will unblock stuff.  Thanks
User9: geneweb/s390x is fixed now, though p-m hasn't caught up yet
User8: User9 hinted
User9: thanks
User13: LocutusOfBorg1, just be aware that everything b-d on boost-mpi ftbfs currently
User8: User9 debci fix committed to Debian git, FTR
User8: Laney, User21 blimey! I just got my autopkgtest quota bumped, 40 new instances!!!11!
User8: they zipped through the remaining queue in no time
User9: User8 oh cool, thanks
User8: now armhf looks really bad :)
User21: pitti, awsome, thats more like it
User22: User8 nice! some new capacity arrived then?
User8: User22 I don't think so, I just got my quota bumped
User8: User22 apparently lcy and lgw already have enough capacity
User8: User22 that's for x86 -- ppc64el still only has 15 parallel instances
User22: oh, well, good news either way
User20: doko, I wasn't
User9: User8 your debci hint version should be 1.0.1ubuntu1, not 1.0.1
User8: User9 argh, sorry; fixed
User8: User9 btw, I pushed your test fix upstream, thanks for that
User8: so we can sync 1.0.2 and it should be good
User9: User8 ah, thanks, I evidently forgot about that
User9: User8 does http://autopkgtest.ubuntu.com/packages/c/composer/xenial/amd64/ need to be retried without pinning?
User8: User9 done so 10 mins ago, they are running
User8: (wholesale)
User9: User8 or maybe that'll get sorted out when composer's armhf tests finish anyway ...
User9: User8 thanks
User8: this becomes unnerving; /me bumps bug 1517426 and works on that RSN
User7: bug 1517426 in Auto Package Testing "apt-get source the pinned versions, not the latest available ones" [High,In progress] https://launchpad.net/bugs/1517426
User8: User9 ok, news on http://autopkgtest.ubuntu.com/ look much more promising now :)
User9: User8 ah, indeed!
User9: down to 41 extra uninstallables for perl now
User9: 18 of those will be fixed by php5 autopkgtests being sorted out, the rest (plus at least 6 progressions) will be from insighttoolkit4/amd64 finishing building plus maybe a couple of rebuilds against that
User12: cjwatson, hm, but i thought insighttoolkit4 will fail the test-suite on amd64 and will ftbfs, no?
User12: oh i386 succeeded =) i guess you did things to it.
User8: User9 great; on my side, armhf is swamped, but the queue contains the necessary retries, so at this point I think we should continue to look at this tomorrow morning
User12: cjwatson, it will take 3 days to build... it's non-parallel amd64 build.
User12: e.g. https://launchpad.net/ubuntu/+source/insighttoolkit4/4.8.1-1ubuntu3/+build/8174103
User23: infinity, i went ahead and tested ppc64el for https://bugs.launchpad.net/ubuntu-cdimage/+bug/1524366 also.
User7: Launchpad bug 1524366 in livecd-rootfs (Ubuntu Trusty) "Add support for lts-wily kernel flavours in trusty" [Medium,Fix committed]
User8: User9 err, except that I'm on a national holiday tomorrow  :) (but I'll have a look in the morning all the same)
User8: mdeslaur, User9 FYI, I hinted the tests which are still failing everywhere (and for a long time) on http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#php5
User8: so as soon as armhf catches up, it should hopefully become valid
 * pitti is almost tempted to let it in now
User16: great!
User11: User9 I'm seeing "mount: /build/binary/boot/filesystem.ext4: failed to setup loop device: No such device or address" in  https://launchpadlibrarian.net/233040357/buildlog_ubuntu_xenial_s390x_cpc_BUILDING.txt.gz, which I haven't seen before; any ideas as to what that might be, before I start digging in to live{-build,cd-rootfs} code to try to debug it?
User8: slangasek, mdeslaur, infinity, stgraber, kees: reminder, TB meeting in 15 mins
User16: User8 ack
User11: User12 ^^^ is on s390x, so you might also have run in to something like it...
User12: Odd_Bloke, User9 old kernel image, without loop.ko module, which is in -extra package in old kernel builds.
User12: Odd_Bloke, User9 new kernels have it as built in.
 * xnox checks kernel version numbers.
User12: infinity, wgrant, cjwatson - either extra package should be installed, and loop modprobed. Or upgrade to 4.3.0-5.16 kernels throughout.
User12: Odd_Bloke, is that a good enough answer for you =)
User4: User12 I'll upgrade all the buildds today.
User12: infinity, thanks \o/ =)
User11: \o/
User9: User12 3> oh well
User22: User8 what TB? :)
User8: User22 tech board
User22: this one? https://launchpad.net/~techboard/+members
 * Laney is gently trolling, sorry
User8: User22 ah right :)
User24: User8 hey, how is it that udevadm info reports properties of a pci device after this is added but I don't get all the said properties to match when using a udev rule?
User8: User24 without knowing the details, maybe your udev rule runs earlier than the one that adds these properties?
User24: User8 entirely possible. Maybe 71-seat-rules or 80-drivers then? http://pastebin.ubuntu.com/14412167/ (trying to get PCI_ID)
User8: User24 you could equivalently use the "vendor" and "device" attributes which don't depend on any extra probing
User24: User8 I'm doing RUN+="/bin/touch /run/u-d-c-nvidia-%k-%s{device}" and, while %k works, %s{device} doesn't
User8: User24 oh, I haven't seen that one, just $attr{device}
User24: User8 yes, no change though
User12: doko, barry - there is asyncio regression in 3.5.1 wrt 3.5.0. The regression is spotted by cython test-suite, it fails when using generators. Reverting asyncio module changes between .0 and .1 makes it pass again. Details are at Bug #1526613
User7: bug 1526613 in python3.5 (Ubuntu) "ftbfs asyncio test failure with 3.5.1-2, used to pass with 3.5.0-2" [Undecided,New] https://launchpad.net/bugs/1526613
User12: i'm not sure how to bisect the changes further, given that asyncio module is imported into stdlib...
User25: cjwatson, doko, cyphermox : have you looked into the grub2 FTBFS? fwiw, i've determined it is due enabling linaro in gcc-5, but wasn't able to identify the specific change
User25: the chip errata workarounds seemed like a logical explanation, but disabling those in the CFLAGS didn't help
User9: User25 I reported it on grub-devel@, and Leif was looking into adding the necessary relocation support
User25: oh, cool
User9: User25 if you do happen to figure out compiler flags that disable the use of the relocations, that would be nice in the meantime, but it may not be possible
User20: doko,
User20: dput ubuntu boost-mpi-source1.58_1.58.0+dfsg-4.1ubuntu1_source.changes
User20: please double check as soon as the upload is finished
User20: :)
User20: thanks
User9: pitti,User26 ubuntu-system-settings-online-accounts autopkgtests may need some attention; I can't quite see what's going on there.  http://autopkgtest.ubuntu.com/packages/u/ubuntu-system-settings-online-accounts/xenial/amd64/
User9: related to latest Qt?
User9: hm, maybe due to the libqt5gui5->libqt5xcbqpa5 depends->recommends change in qtbase-opensource-src 5.5.1+dfsg-10
User9: User26 what should gain a dependency on libqt5xcbqpa5 to keep autopkgtests working if not libqt5gui5?
User4: A reasonable change if it's a plugin, but yeah, rdeps need tending to, then, to see if they load it.
User9: Maybe autopilot-desktop would be a good package to gain a dependency on libqt5xcbqpa5?
User1: User13 thanks, it built this time with 128 :)
User26: User9 probably autopilot-desktop yes, although it's an option to deviate from Debian too there and they are also still juggling them.
 * Mirv AFK though now
User26: User9 they're thinking of putting the plugins back to libqt5gui5 after all so while waiting for it (they're doing it for 5.6) we could also change back the Recommens to Dependency
User26: feel free to upload any solution(s) you want, I'm away tomorrow
User27: User8 hi! looking at the apparmor regressions on excuses, the lxc ones are all due to "There is no download available for release=xenial, stream=daily, arch=<arch>"
User27: User8 the ubuntu-system-settings-online-accounts failures for amd64 and i386 are "18:02:02.016 WARNING testcase:547 - Failed to create Touch device for bug lp:1297595 workaround: Unable to instantiate any backends"
User27: User8 "UInput: UInputError('"/dev/uinput" cannot be opened for writing',)"
User28: User8 this upload involved no code changes (only changed the nameservice abstraction)
User26: right, some circular dependency thing coming with 5.6 if I understood correctly and they'll merge libqt5xcb5 back to libqt5gui5 so it'd be ok to change Recommends -> Depends for us for the time being. mitya57 can confirm if he's around, I can't check the details right now
User29: coreycb, re: bug 1526927 -- good that the python-keystoneauth1 build-depend got fixed in debian.  But why was it building without it?  is the dep not actually needed for the tests or do the py3 tests not fail the build when the dep is missing?
User7: bug 1526927 in python-openstacksdk (Ubuntu) "[MIR] python-senlinclient, python-openstacksdk, python-keystoneauth1" [Undecided,New] https://launchpad.net/bugs/1526927
User30: mterry, it's not a test requirement so I'd have to guess we were getting lucky building without it
User30: mterry, it's a run-time requirement
User29: coreycb, our only delta with debian (added in 0.7.1-1ubuntu1) is to add a build-dep on the py2 version to fix tests
User29: coreycb, so it presumably is at least partly a build-time requirement?
User30: mterry, you're right, it's used in some tests too.  I was just going off of it being in requirements.txt only.
User29: coreycb, but then I'm wondering why we didn't need the py3 versoin?
User30: mterry, that's a great question.  let me give it a run and make sure tests are actually running.
User30: py3 tests.
User29: cool thanks
User30: mterry, ok, so the current version in xenial doesn't run py3 tests
User29: huh?  I thought I saw it doing that, must have missed that
User30: mterry, however the next version, that needs to get uploaded, does
User29: coreycb, yup I see that now
User30: mterry, I need to poke some folks to get that uploaded
User29: coreycb, ok with that caveat, I'll approve
User30: mterry, great, thanks
User31: User12 hey.  interesting.  did you end up reporting it upstream?
User4: User11 s390x buildds should have loopy kernels now.
User31: User32 i merged and uploaded the new pylint, but it will wait until astroid un-depwaits and builds.  i believe cyphermox is assigned the mir for lazy-object-property, so if/when that's approved the queue should ungunk itself
User32: User31 oh cyphermox is off this week. can anybody else pick that up/
User23: any one want to hazard to guess what would cause newaliases to fail
User23: in a qemu-static chroot
User23: https://bugs.launchpad.net/debian/+source/postfix/+bug/1531299
User7: Launchpad bug 1531299 in postfix (Ubuntu) "postfix upgrade can fail due to "newaliases: fatal: inet_addr_local[getifaddrs]: getifaddrs: Address family not supported by protocol"" [Medium,Confirmed]
User31: User32 anyone else on the mir team: https://launchpad.net/~ubuntu-mir/+members#active
User23: utlemming, ^ that is our maas image arm64 build failure cause
User32: User31 but will somebody grab it or do I have to hassle people?
User31: User32 since the issue is currently assigned to cyphermox you probably have to hassle people
User32: User31 oh mterry did the assignment. *shakes fist*
User29: robru, what I do?
User32: User29 you assigned https://bugs.launchpad.net/ubuntu/+source/lazy-object-proxy/+bug/1531033 to cyphermox but he's off this week
User7: Launchpad bug 1531033 in lazy-object-proxy (Ubuntu) "[MIR] lazy-object-property is new dep for main package pylint" [Undecided,Confirmed]
User29: robru, ah didn't know
User29: robru, this is urgent?  I can look
User32: User29 well, not super urgent. it fixes pylint, which is important before release, but it's not like the world is burning or anything.
User29: robru, sure.  But no reason to wait a week
User29: robru, I bet it's small, I can probably bang it out now
User32: User29 I don't know what your workload is like ;-)
User32: User29 thanks!
User9: User23 why are you doing image builds inside qemu-static?
User33: User9 that is the evilness we are trying to get away from
User4: User33 So, let's get away from it? :)
User4: User33 What's still blocking that?
User9: ah, right, this is not something you're seeing in LP then?
User33: User9 no, that is the KVM builders for the cloud images
User33: User4 working on it :)
User4: User23 As for that specific error, it looks more like a misconfigured chroot in general rather than a qemu-related problem but replacing that hack seems more important than fixing it.
User9: User26 OK, moving Recommends back to Depends for the moment, then.
User9: User26 (but feel free to revert if you have a better solution, this is just to unblock stuff)
User34: User10 any way to get qmake to work with sbuild on arm?
User10: lpotter, hey, not unless you're willing to hack around debian/rules
User10: lpotter, I assume you mean to cross-build for arm, not "just" qmake on arm?
User34: yes cross
User10: lpotter, so yeah, we have qt5-qmake-arm-linux-gnueabihf
User10: which is a qmake binary built so it's prepared for cross-building (library paths and such, which are unfortunately baked into qmake build-time)
User10: lpotter, but I don't think there's any package that does the magic in their debian/ yet
User34: ever tried using qtchooser?
User10: lpotter, you'd need to add it to Build-Depends for [i386, amd64] unconditionally, or generate debian/control in debian/rules clean after querying dpkg-architecture, and do the same for dh_override_auto_configure
User10: lpotter, qtchooser doesn't really help much here, since we only have qmake prepped for cross, not the whole thing
User10: lpotter, it is an unfortunate design decision of qmake that it compiles the paths in build-time
User10: lpotter, qtchooser only lets you configure a single PATH for all qtchooser-managed binaries, not per-binary (afaict)
User10: [...] unfortunate in the sense it's not compatible with debian/ubuntu's approach to multiarch
User10: other build systems have different profiles that you can choose from runtime
User34: ya qtopia had to do some real funky stuff with qmake, coming up with qtopiamake.
User10: lpotter, at least it's doable now (if inconvenient...), but it's really just a case of someone doing it for the first time and others will be able to copypasta ;)
User10: lpotter, FYI, if you want to try, I did see an issue with PKG_CONFIG_PATH not being set right, had to point it at the armhf path
User10: but it worked after all
ubuntu-devel
Ubuntu IRC