| === Unit193 is now known as Hypnotoad | ||
| === Hypnotoad is now known as Unit193 | ||
| === rbanffy_ is now known as rbanffy | ||
| ESphynx | doko: I imagine this is now published? https://launchpad.net/ubuntu/+source/pkgbinarymangler/127/+build/8801747 | 02:19 |
|---|---|---|
| ESphynx | oh it's you doko :) | 02:20 |
| ESphynx | Could someone please retry the AMD64 build of ecere-sdk on Xenial now? https://launchpad.net/ubuntu/xenial/+source/ecere-sdk | 02:24 |
| slangasek | mhall119: 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 | 03:04 |
| slangasek | mhall119: "Subject: Best Windows Replacement Deals of the Year- Available Now.=" -- that your mail to the TB? ;) | 03:06 |
| slangasek | mhall119: (messages approved) | 03:06 |
| ESphynx | 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 | 03:38 |
| darkxst | ESphynx, 15.04 will be end-of-life in a few weeks, you should upgrade! | 04:11 |
| infinity | tjaalton: Ping, re: lts-w X stack. Time's running out. | 04:23 |
| ESphynx | darkxst: 15.10 I mean, sorry | 04:43 |
| ESphynx | darkxst: also, seriously annoyed that upgrades put back Unity as my default WM | 04:43 |
| darkxst | ESphynx, how did you set your default WM? | 04:44 |
| ESphynx | or maybe it didn't | 04:44 |
| ESphynx | 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) | 04:44 |
| darkxst | that should not be reset on upgrades | 04:45 |
| ESphynx | 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 | 04:45 |
| darkxst | ESphynx, file bugs, not whine on IRC! | 04:46 |
| darkxst | a. might be a kernel issue | 04:46 |
| ESphynx | darkxst: bugs take considerable time to file and it just depresses me when they get ignored for years :P | 04:48 |
| ESphynx | re: a), not that I can use the keyboard keys to turn it 'off' once logged in | 04:49 |
| ESphynx | note* | 04:49 |
| darkxst | ESphynx, use `ubuntu-bug <package>` should only take a couple of minutes | 04:49 |
| darkxst | if they are ignored after a while send an email to relevant email list linking to your bugs | 04:50 |
| ESphynx | darkxst: finding what package is responsible in those cases would take me a while :) | 04:50 |
| darkxst | a.) likely kernel b.) possible gnome-settings-daemon | 04:50 |
| ESphynx | thanks. will take note and may end up filing bugs :P | 04:50 |
| ESphynx | you don't happen to have rights to re-schedule a failed build, do you? ;) | 04:51 |
| darkxst | probably not unless its part of ubuntu GNOME or -desktop packagesets | 04:55 |
| ESphynx | ah, no it's not, but thanks! | 04:56 |
| TheMuso | ESphynx: I can retry a failed build for you, as long as you are sure it will succeed. What package? | 05:02 |
| ESphynx | TheMuso: https://launchpad.net/ubuntu/xenial/+source/ecere-sdk | 05:03 |
| ESphynx | TheMuso: doko published a fix earlier for pkgbinarymangler which should theoretically fix the failed build | 05:04 |
| TheMuso | ESphynx: Which version? | 05:04 |
| ESphynx | TheMuso: this amd64 build https://launchpad.net/ubuntu/+source/ecere-sdk/0.44.13-1/+build/8791598 | 05:04 |
| ESphynx | the 'all' architecture is actually what was failing due to the PNG optimization code | 05:05 |
| TheMuso | ESphynx: Ok, retried. | 05:05 |
| ESphynx | thank you! | 05:05 |
| TheMuso | You're welcome. | 05:06 |
| ESphynx | doko, TheMuso: 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 ) | 05:21 |
| TheMuso | ESphynx: Ah that sucks. I'm not familiar with that package, so don't feel I can be any further help sorry. | 05:29 |
| ESphynx | TheMuso: thanks, will ping doko again tomorrow :) | 05:31 |
| tjaalton | infinity: bug 1519753 is there for libdrm which needs to go in first | 05:56 |
| ubottu | bug 1519753 in libdrm (Ubuntu Trusty) "Please backport libdrm for 14.04.4" [High,In progress] https://launchpad.net/bugs/1519753 | 05:56 |
| pitti | Good morning | 06:48 |
| pitti | doko: for gcc-5? well, because they do fail.. | 06:49 |
| pitti | doko: but the rebuild test succeeds, so good enough for gcc, I'll hint it | 06:49 |
| pitti | cjwatson: I just saw commit 803 in hints-ubuntu -- i. e. we actually do need a manual hint for perl transitions? | 07:51 |
| cjwatson | pitti: no, if it was "unblock" there must have been a freeze in progress at the time or something | 07:53 |
| pitti | cjwatson: yes, it was "unblock" | 07:54 |
| pitti | cjwatson: ah, so these are not manual hints, just counter freeze hints; check | 07:55 |
| * pitti wonders how he can convince britney to let systemd and ifupdown in -- they have a mutual Breaks:, but otherwise work fine | 07:57 | |
| pitti | I tested a dist-upgrade from wily to xenial-proposed | 07:58 |
| cjwatson | pitti: probably "easy systemd/blah ifupdown/blah" then | 07:58 |
| pitti | cjwatson: ah, thanks; this type of hint is/was new to me | 07:59 |
| cjwatson | pitti: The current autohint seems to be getting there, but still 129 extra uninstallables. I'll poke at it some more after breakfast. | 08:05 |
| cjwatson | pitti: 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? | 08:33 |
| cjwatson | pitti: (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) | 08:34 |
| pitti | cjwatson: 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 :( | 08:35 |
| * pitti retries those without apt pinning, maybe a few of them will work | 08:35 | |
| cjwatson | Deliberate language changes, or bugs? | 08:35 |
| pitti | "Missing PHP extension "http" or wrong version!" might be due to apt pinning | 08:36 |
| pitti | but I didn't see a pattern there, they fail due to dozens of different causes | 08:36 |
| cjwatson | maybe worth punting to mdeslaur as the person who merged php5 | 08:37 |
| cjwatson | can also temporarily remove uwsgi from the release pocket to disentangle these, but let's see | 08:38 |
| pitti | uwsgi has reverse dependencies, though | 08:38 |
| pitti | I remember that this was one of the remaining hard ones on http://people.canonical.com/~ubuntu-archive/transitions/html/html/perl5.22.html | 08:38 |
| cjwatson | a few, yes | 08:39 |
| pitti | retried the php tests (without pinning), but queues are also Qt-DoSed, will take a bit | 08:39 |
| cjwatson | it was previously hard on the transition tracker because it depended on libcoro-perl, but the sync from unstable disentangled those | 08:40 |
| pitti | in the meantime I'll run them against release and see which ones are actual regressions | 08:40 |
| pitti | cjwatson: 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 :) | 08:40 |
| cjwatson | 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 | 08:41 |
| pitti | geneweb has no reverse deps, so that sounds fine | 08:42 |
| cjwatson | I want to see if it can be fixed properly before doing that though | 08:42 |
| pitti | cjwatson: oh, arm64 distro builds are now on bos, with more capacity -- nice! | 08:43 |
| cjwatson | pitti: 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 | 08:47 |
| pitti | 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 | 08:48 |
| pitti | interestingly it succeeds in Debian | 08:51 |
| pitti | cjwatson: oh, there are a couple of php module FTBFS, I'll look at those; they explain at least part of the regressions | 08:56 |
| Saviq | pitti, can you please restart qtmir with qtmir-gles trigger http://autopkgtest.ubuntu.com/packages/q/qtmir/xenial/i386/ | 08:58 |
| Saviq | /we need to look into that test, starts looking unstable | 08:58 |
| pitti | Saviq: queued | 08:58 |
| Saviq | thanks | 08:58 |
| pitti | Saviq: but it will take a while, cf. the rather large queue on http://autopkgtest.ubuntu.com/running.shtml | 08:58 |
| Saviq | ack | 08:59 |
| pitti | . o O { can we just test everything on s390x? :-) | 08:59 |
| pitti | cjwatson: 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 | 09:10 |
| pitti | dear debian, please stop allowing arch:all uploads, kthxbye | 09:10 |
| cjwatson | pitti: 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 | 09:17 |
| cjwatson | pitti: you probably *could* disentangle those manually, but it sucks to have to | 09:17 |
| cjwatson | i.e. via uploads | 09:17 |
| cjwatson | leaves garbage in the archive | 09:17 |
| pitti | 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 | 09:18 |
| pitti | ATM it fails for an entirely different reason, meh | 09:18 |
| === shuduo is now known as shuduo-afk | ||
| Odd_Bloke | xnox: Did you see gaughen's email asking if you're ready for s390x cloud images to be built? | 10:22 |
| pitti | Odd_Bloke: speaking of which, what's the word on xenial cloud images (for other arches)? | 10:23 |
| pitti | Odd_Bloke: and happy new year! | 10:23 |
| Odd_Bloke | pitti: Happy New Year! | 10:24 |
| Odd_Bloke | pitti: So we are building xenial cloud images using the old system at the moment, which should work as you expect. | 10:24 |
| pitti | Odd_Bloke: I mean http://cloud-images.ubuntu.com/xenial/ has Dec 18 as latest image | 10:24 |
| Odd_Bloke | pitti: Oh, hm. | 10:25 |
| Odd_Bloke | pitti: It looks like we've been publishing that image to clouds since December 18th; let me work out what's going on. | 10:26 |
| Odd_Bloke | pitti: OK, that's unwedged now. | 10:29 |
| pitti | Odd_Bloke: nice, thanks! | 10:29 |
| Odd_Bloke | pitti: 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). | 10:30 |
| xnox | Odd_Bloke, hm... yes =) i just have. | 10:31 |
| === _salem is now known as salem_ | ||
| xnox | Odd_Bloke, yo, send a reply. Yes, we can start building series of bytes that resemble a cloud image =) | 10:47 |
| xnox | Odd_Bloke, do you have ability to add hooks and things in the initramfs? | 10:47 |
| Odd_Bloke | xnox: 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? | 10:50 |
| xnox | 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. | 10:52 |
| xnox | Odd_Bloke, or e.g. change sysconfig-hardware to take hints from kernel cmdline or some such. | 10:52 |
| xnox | Odd_Bloke, anyway, does my email sound clear at all? to e.g. produce "a series of bytes that look like a cloud-image" ? =) | 10:59 |
| Odd_Bloke | xnox: Yep, it does (to me at least :p). | 11:04 |
| === dupingping__ is now known as dupingping | ||
| doko | xnox, are you looking at the cython ftbfs issue? | 11:17 |
| xnox | doko, yes, i believe it's a bug with asyncio module and regression in python. | 11:17 |
| xnox | doko, as it used to build with earlier 3.4 python. | 11:17 |
| xnox | but i didn't bisect it yet, to hand over to you / upstream. | 11:18 |
| doko | earlier 3.4 or 3.5? | 11:18 |
| tumbleweed | cython uses asyncio? | 11:26 |
| doko | at least some test case | 11:28 |
| jtaylor | cython implements asyncio, also in python3.4 | 11:28 |
| tumbleweed | neat | 11:29 |
| jtaylor | so you should be able to use await et. al. probably also in python2 | 11:29 |
| jtaylor | (never tested it though) | 11:29 |
| cjwatson | pitti: Can you work out what's up with http://autopkgtest.ubuntu.com/packages/d/debci/xenial/s390x/ ? | 11:49 |
| cjwatson | (blocking librabbitmq -> kamailio -> perl) | 11:49 |
| pitti | cjwatson: will do | 11:50 |
| cjwatson | thanks | 11:50 |
| pitti | ok, it seems I finally untangled phpunit, mass-retrying the failed php builds | 11:56 |
| cjwatson | nice | 11:57 |
| cjwatson | I fixed findlib on s390x, so a bunch of retries going through for that too | 11:57 |
| pitti | cjwatson: btw, are your lcy builders still busted? (most of them are "cleaning") | 11:58 |
| pitti | cjwatson: my lcy instances are sometimes brittle, but they by and large survived over the holidays (I was quite surprised) | 11:58 |
| cjwatson | pitti: looks like it, our clouds are in various pieces | 11:59 |
| pitti | lgw seems to be back (was broken yesterday) | 12:00 |
| mdeslaur | pitti: infinity promised to fix the phpunit-mock-object <-> phpunit circular build depends before the holidays... | 12:01 |
| mdeslaur | pitti: I was waiting on that to see how many php5 stuff would then pass | 12:01 |
| pitti | mdeslaur: good morning, happy new year! | 12:01 |
| pitti | mdeslaur: indeed, it was phpunit-mock-objejct, phpunit, and php-codecoverage circularly depending | 12:02 |
| pitti | mdeslaur: but it seems they work now; I'll revert the changes once britney settles down (I have the uploads locally prepared) | 12:02 |
| mdeslaur | pitti: happy new year to you too! :) | 12:04 |
| === xavigarcia is now known as xavigarcia_lunch | ||
| mdeslaur | pitti: awesome, thanks for fixing that! | 12:15 |
| === marcusto_ is now known as marcustomlinson| | ||
| === marcustomlinson| is now known as marcustomlinson_ | ||
| === marcustomlinson_ is now known as marcustomlinson | ||
| === xavigarcia_lunch is now known as xavigarcia | ||
| dgadomski | 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? | 13:07 |
| ubottu | bug 1337873 in ifupdown (Ubuntu Vivid) "Precise, Trusty, Utopic - ifupdown initialization problems caused by race condition" [Medium,Confirmed] https://launchpad.net/bugs/1337873 | 13:07 |
| mhall119 | thanks slangasek | 13:27 |
| doko | dholbach, LocutusOfBorg1: any update on the boost1.58-mpisource package? | 13:52 |
| dholbach | doko: I thought LocutusOfBorg1 would look into it | 13:52 |
| dholbach | LocutusOfBorg1: AFAICT the boost1.58-mpi source package needs to be updated to have the same contents and version number as boost1.58 | 13:53 |
| pitti | dgadomski: yes, I think so | 14:10 |
| dgadomski | pitti: cool, could you please sponsor it? | 14:11 |
| pitti | dgadomski: yes, can do; I'll skip vivid though, that's going to be EOL in two or three weeks | 14:12 |
| dgadomski | pitti: sounds good, thank you | 14:13 |
| pitti | dgadomski: why is https://launchpadlibrarian.net/221884579/trusty_ifenslave_2.4ubuntu1.2.debdiff necessary for trusty, but not for precise or wily? | 14:14 |
| dgadomski | pitti: the fix is only for 14.04+ and wily's ifenslave already has the necessary change | 14:15 |
| pitti | dgadomski: ah, and there is no precise patch yet, I see | 14:16 |
| dgadomski | pitti: that's right, there are so many differences in implementation that I was not able to backport it without backporting half of trusty ifupdown | 14:17 |
| pitti | dgadomski: so I guess we just don't care for precise; after all, it has lived for so long without this that it hardly matters | 14:18 |
| pitti | dgadomski: sponsored and bug updated | 14:19 |
| dgadomski | pitti: thanks! | 14:21 |
| === greyback__ is now known as greyback | ||
| LocutusOfBorg1 | doko, I'm doing some other work, I''ll look at it soon (TM) | 14:41 |
| pitti | cjwatson: FYI, that's debian bug 809265, race condition in the test | 14:44 |
| ubottu | 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 | 14:44 |
| pitti | cjwatson: so if this unblocks stuff, I'm happy to ignore it for now | 14:44 |
| pitti | cjwatson: (but looking at it right now anyway) | 14:45 |
| cjwatson | pitti: Yeah, it will unblock stuff. Thanks | 14:45 |
| cjwatson | geneweb/s390x is fixed now, though p-m hasn't caught up yet | 14:46 |
| pitti | cjwatson: hinted | 14:46 |
| cjwatson | thanks | 14:48 |
| doko | LocutusOfBorg1, just be aware that everything b-d on boost-mpi ftbfs currently | 14:50 |
| pitti | cjwatson: debci fix committed to Debian git, FTR | 15:08 |
| pitti | Laney, apw: blimey! I just got my autopkgtest quota bumped, 40 new instances!!!11! | 15:09 |
| pitti | they zipped through the remaining queue in no time | 15:09 |
| cjwatson | pitti: oh cool, thanks | 15:09 |
| pitti | now armhf looks really bad :) | 15:09 |
| apw | pitti, awsome, thats more like it | 15:16 |
| Laney | pitti: nice! some new capacity arrived then? | 15:26 |
| pitti | Laney: I don't think so, I just got my quota bumped | 15:34 |
| pitti | Laney: apparently lcy and lgw already have enough capacity | 15:34 |
| pitti | Laney: that's for x86 -- ppc64el still only has 15 parallel instances | 15:34 |
| Laney | oh, well, good news either way | 15:35 |
| LocutusOfBorg1 | doko, I wasn't | 15:39 |
| cjwatson | pitti: your debci hint version should be 1.0.1ubuntu1, not 1.0.1 | 15:42 |
| pitti | cjwatson: argh, sorry; fixed | 15:42 |
| pitti | cjwatson: btw, I pushed your test fix upstream, thanks for that | 15:43 |
| pitti | so we can sync 1.0.2 and it should be good | 15:43 |
| cjwatson | pitti: ah, thanks, I evidently forgot about that | 15:44 |
| cjwatson | pitti: does http://autopkgtest.ubuntu.com/packages/c/composer/xenial/amd64/ need to be retried without pinning? | 15:44 |
| pitti | cjwatson: done so 10 mins ago, they are running | 15:44 |
| pitti | (wholesale) | 15:44 |
| cjwatson | pitti: or maybe that'll get sorted out when composer's armhf tests finish anyway ... | 15:45 |
| cjwatson | pitti: thanks | 15:45 |
| pitti | this becomes unnerving; /me bumps bug 1517426 and works on that RSN | 15:45 |
| ubottu | 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 | 15:45 |
| pitti | cjwatson: ok, news on http://autopkgtest.ubuntu.com/ look much more promising now :) | 15:48 |
| cjwatson | pitti: ah, indeed! | 15:56 |
| cjwatson | down to 41 extra uninstallables for perl now | 15:58 |
| cjwatson | 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 | 15:59 |
| xnox | cjwatson, hm, but i thought insighttoolkit4 will fail the test-suite on amd64 and will ftbfs, no? | 16:00 |
| xnox | oh i386 succeeded =) i guess you did things to it. | 16:00 |
| pitti | cjwatson: 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 | 16:01 |
| xnox | cjwatson, it will take 3 days to build... it's non-parallel amd64 build. | 16:01 |
| xnox | e.g. https://launchpad.net/ubuntu/+source/insighttoolkit4/4.8.1-1ubuntu3/+build/8174103 | 16:01 |
| smoser | infinity, i went ahead and tested ppc64el for https://bugs.launchpad.net/ubuntu-cdimage/+bug/1524366 also. | 16:14 |
| ubottu | Launchpad bug 1524366 in livecd-rootfs (Ubuntu Trusty) "Add support for lts-wily kernel flavours in trusty" [Medium,Fix committed] | 16:14 |
| pitti | cjwatson: err, except that I'm on a national holiday tomorrow :) (but I'll have a look in the morning all the same) | 16:29 |
| pitti | mdeslaur, cjwatson: 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 | 16:39 |
| pitti | so as soon as armhf catches up, it should hopefully become valid | 16:40 |
| * pitti is almost tempted to let it in now | 16:40 | |
| mdeslaur | great! | 16:42 |
| Odd_Bloke | cjwatson: 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? | 16:43 |
| pitti | slangasek, mdeslaur, infinity, stgraber, kees: reminder, TB meeting in 15 mins | 16:44 |
| mdeslaur | pitti: ack | 16:46 |
| Odd_Bloke | xnox: ^^^ is on s390x, so you might also have run in to something like it... | 16:51 |
| xnox | Odd_Bloke, cjwatson: old kernel image, without loop.ko module, which is in -extra package in old kernel builds. | 16:52 |
| xnox | Odd_Bloke, cjwatson: new kernels have it as built in. | 16:52 |
| * xnox checks kernel version numbers. | 16:53 | |
| xnox | infinity, wgrant, cjwatson - either extra package should be installed, and loop modprobed. Or upgrade to 4.3.0-5.16 kernels throughout. | 16:54 |
| xnox | Odd_Bloke, is that a good enough answer for you =) | 16:55 |
| infinity | xnox: I'll upgrade all the buildds today. | 17:00 |
| xnox | infinity, thanks \o/ =) | 17:00 |
| Odd_Bloke | \o/ | 17:01 |
| cjwatson | xnox: 3> oh well | 17:02 |
| Laney | pitti: what TB? :) | 17:04 |
| pitti | Laney: tech board | 17:05 |
| Laney | this one? https://launchpad.net/~techboard/+members | 17:05 |
| * Laney is gently trolling, sorry | 17:05 | |
| pitti | Laney: ah right :) | 17:06 |
| tseliot | pitti: 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? | 17:10 |
| pitti | tseliot: without knowing the details, maybe your udev rule runs earlier than the one that adds these properties? | 17:11 |
| tseliot | pitti: entirely possible. Maybe 71-seat-rules or 80-drivers then? http://pastebin.ubuntu.com/14412167/ (trying to get PCI_ID) | 17:13 |
| pitti | tseliot: you could equivalently use the "vendor" and "device" attributes which don't depend on any extra probing | 17:18 |
| tseliot | pitti: I'm doing RUN+="/bin/touch /run/u-d-c-nvidia-%k-%s{device}" and, while %k works, %s{device} doesn't | 17:20 |
| pitti | tseliot: oh, I haven't seen that one, just $attr{device} | 17:23 |
| tseliot | pitti: yes, no change though | 17:25 |
| xnox | 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 | 17:56 |
| ubottu | 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 | 17:56 |
| xnox | i'm not sure how to bisect the changes further, given that asyncio module is imported into stdlib... | 17:57 |
| dannf | 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 | 18:01 |
| dannf | the chip errata workarounds seemed like a logical explanation, but disabling those in the CFLAGS didn't help | 18:03 |
| cjwatson | dannf: I reported it on grub-devel@, and Leif was looking into adding the necessary relocation support | 18:06 |
| dannf | oh, cool | 18:06 |
| cjwatson | dannf: 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 | 18:06 |
| LocutusOfBorg1 | doko, | 18:36 |
| LocutusOfBorg1 | dput ubuntu boost-mpi-source1.58_1.58.0+dfsg-4.1ubuntu1_source.changes | 18:36 |
| LocutusOfBorg1 | please double check as soon as the upload is finished | 18:36 |
| LocutusOfBorg1 | :) | 18:36 |
| LocutusOfBorg1 | thanks | 18:36 |
| cjwatson | pitti,Mirv: 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/ | 18:49 |
| cjwatson | related to latest Qt? | 18:50 |
| cjwatson | hm, maybe due to the libqt5gui5->libqt5xcbqpa5 depends->recommends change in qtbase-opensource-src 5.5.1+dfsg-10 | 18:51 |
| cjwatson | Mirv: what should gain a dependency on libqt5xcbqpa5 to keep autopkgtests working if not libqt5gui5? | 18:52 |
| infinity | A reasonable change if it's a plugin, but yeah, rdeps need tending to, then, to see if they load it. | 18:52 |
| cjwatson | Maybe autopilot-desktop would be a good package to gain a dependency on libqt5xcbqpa5? | 18:54 |
| ESphynx | doko: thanks, it built this time with 128 :) | 19:16 |
| Mirv | cjwatson: probably autopilot-desktop yes, although it's an option to deviate from Debian too there and they are also still juggling them. | 19:28 |
| * Mirv AFK though now | 19:28 | |
| Mirv | cjwatson: 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 | 19:30 |
| Mirv | feel free to upload any solution(s) you want, I'm away tomorrow | 19:30 |
| jdstrand_ | pitti: 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>" | 19:31 |
| jdstrand_ | pitti: 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" | 19:31 |
| jdstrand_ | pitti: "UInput: UInputError('"/dev/uinput" cannot be opened for writing',)" | 19:32 |
| === jdstrand_ is now known as jdstrand | ||
| jdstrand | pitti: this upload involved no code changes (only changed the nameservice abstraction) | 19:32 |
| Mirv | 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 | 19:33 |
| mterry | 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? | 19:41 |
| ubottu | bug 1526927 in python-openstacksdk (Ubuntu) "[MIR] python-senlinclient, python-openstacksdk, python-keystoneauth1" [Undecided,New] https://launchpad.net/bugs/1526927 | 19:41 |
| coreycb | mterry, it's not a test requirement so I'd have to guess we were getting lucky building without it | 19:51 |
| coreycb | mterry, it's a run-time requirement | 19:51 |
| mterry | 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 | 19:52 |
| mterry | coreycb, so it presumably is at least partly a build-time requirement? | 19:52 |
| coreycb | mterry, you're right, it's used in some tests too. I was just going off of it being in requirements.txt only. | 19:52 |
| mterry | coreycb, but then I'm wondering why we didn't need the py3 versoin? | 19:53 |
| coreycb | mterry, that's a great question. let me give it a run and make sure tests are actually running. | 19:53 |
| coreycb | py3 tests. | 19:53 |
| mterry | cool thanks | 19:54 |
| coreycb | mterry, ok, so the current version in xenial doesn't run py3 tests | 19:55 |
| mterry | huh? I thought I saw it doing that, must have missed that | 19:55 |
| coreycb | mterry, however the next version, that needs to get uploaded, does | 19:55 |
| mterry | coreycb, yup I see that now | 19:56 |
| coreycb | mterry, I need to poke some folks to get that uploaded | 19:56 |
| mterry | coreycb, ok with that caveat, I'll approve | 19:57 |
| coreycb | mterry, great, thanks | 19:57 |
| barry | xnox: hey. interesting. did you end up reporting it upstream? | 20:24 |
| infinity | Odd_Bloke: s390x buildds should have loopy kernels now. | 20:52 |
| === salem_ is now known as _salem | ||
| barry | robru: 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 | 21:49 |
| robru | barry: oh cyphermox is off this week. can anybody else pick that up/ | 22:05 |
| smoser | any one want to hazard to guess what would cause newaliases to fail | 22:05 |
| smoser | in a qemu-static chroot | 22:06 |
| smoser | https://bugs.launchpad.net/debian/+source/postfix/+bug/1531299 | 22:06 |
| ubottu | 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] | 22:06 |
| barry | robru: anyone else on the mir team: https://launchpad.net/~ubuntu-mir/+members#active | 22:06 |
| smoser | utlemming, ^ that is our maas image arm64 build failure cause | 22:06 |
| robru | barry: but will somebody grab it or do I have to hassle people? | 22:07 |
| barry | robru: since the issue is currently assigned to cyphermox you probably have to hassle people | 22:07 |
| robru | barry: oh mterry did the assignment. *shakes fist* | 22:08 |
| mterry | robru, what I do? | 22:09 |
| robru | mterry: you assigned https://bugs.launchpad.net/ubuntu/+source/lazy-object-proxy/+bug/1531033 to cyphermox but he's off this week | 22:09 |
| ubottu | Launchpad bug 1531033 in lazy-object-proxy (Ubuntu) "[MIR] lazy-object-property is new dep for main package pylint" [Undecided,Confirmed] | 22:09 |
| mterry | robru, ah didn't know | 22:09 |
| mterry | robru, this is urgent? I can look | 22:09 |
| robru | mterry: well, not super urgent. it fixes pylint, which is important before release, but it's not like the world is burning or anything. | 22:10 |
| mterry | robru, sure. But no reason to wait a week | 22:10 |
| mterry | robru, I bet it's small, I can probably bang it out now | 22:10 |
| robru | mterry: I don't know what your workload is like ;-) | 22:10 |
| robru | mterry: thanks! | 22:10 |
| cjwatson | smoser: why are you doing image builds inside qemu-static? | 22:15 |
| utlemming | cjwatson: that is the evilness we are trying to get away from | 22:16 |
| infinity | utlemming: So, let's get away from it? :) | 22:17 |
| infinity | utlemming: What's still blocking that? | 22:17 |
| cjwatson | ah, right, this is not something you're seeing in LP then? | 22:17 |
| utlemming | cjwatson: no, that is the KVM builders for the cloud images | 22:17 |
| utlemming | infinity: working on it :) | 22:17 |
| infinity | smoser: 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. | 22:18 |
| cjwatson | Mirv: OK, moving Recommends back to Depends for the moment, then. | 22:26 |
| cjwatson | Mirv: (but feel free to revert if you have a better solution, this is just to unblock stuff) | 22:27 |
| lpotter | Saviq: any way to get qmake to work with sbuild on arm? | 23:40 |
| Saviq | lpotter, hey, not unless you're willing to hack around debian/rules | 23:40 |
| Saviq | lpotter, I assume you mean to cross-build for arm, not "just" qmake on arm? | 23:41 |
| lpotter | yes cross | 23:41 |
| Saviq | lpotter, so yeah, we have qt5-qmake-arm-linux-gnueabihf | 23:42 |
| Saviq | 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) | 23:42 |
| Saviq | lpotter, but I don't think there's any package that does the magic in their debian/ yet | 23:44 |
| lpotter | ever tried using qtchooser? | 23:46 |
| Saviq | 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 | 23:47 |
| Saviq | lpotter, qtchooser doesn't really help much here, since we only have qmake prepped for cross, not the whole thing | 23:47 |
| Saviq | lpotter, it is an unfortunate design decision of qmake that it compiles the paths in build-time | 23:48 |
| Saviq | lpotter, qtchooser only lets you configure a single PATH for all qtchooser-managed binaries, not per-binary (afaict) | 23:49 |
| Saviq | [...] unfortunate in the sense it's not compatible with debian/ubuntu's approach to multiarch | 23:50 |
| Saviq | other build systems have different profiles that you can choose from runtime | 23:50 |
| lpotter | ya qtopia had to do some real funky stuff with qmake, coming up with qtopiamake. | 23:55 |
| Saviq | 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 ;) | 23:56 |
| Saviq | 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 | 23:57 |
| Saviq | but it worked after all | 23:57 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!