[00:10] I don't really know where to start in solving this s390x FTBFS: https://launchpad.net/ubuntu/+source/kpmcore/3.3.0-5 [00:10] Tests are failing with Invalid CBOR stream: unexpected 'break' byte [00:10] It's Ubuntu-s390x-specific. [00:25] step one, get an s390x... [00:39] I'd try to repro it in a porterbox if Debian was having the issue too... [00:39] tsimonq2: reproducible on a big endian 64bit system? [00:41] I'll see. [00:41] which endianness is our arm64? [00:50] doko: I can't repro on zelenka with a fresh sid schroot. [01:35] sarnold: little, we're not crazy [01:36] mwhudson: hehe [08:33] cpaelzer, doko: can we get python-os-ken, python-os-resources and python-websockify promoted to main pls - I think the MIR's are all approved and mismatched nova/neutron is currently blocking testing [08:53] jamespage: I have no powers to do so [08:53] jamespage: resolving acked MIRs by promoting is an AA task [08:54] but doko can and so does (considering the time and timezones) maybe apw ? [08:54] cpaelzer: yep - hence my inclusion of doko in my request :) [08:54] jamespage: well I was mostly commenting on my inclusion being useless on this task :-) [08:55] cpaelzer: I was a bit unclear on the bug task status's - what's the normal status for 'Reviewed, ready for promotion' [08:55] ? [08:59] jamespage: "in progress" means ready, the next is "Fix committed" if you have put the stuff in proposed that makes the dependency appear [08:59] jamespage: so in your case I think all of them are fix committed then right? [08:59] jamespage: since I never understood the states I wrote this some time ago https://wiki.ubuntu.com/MIRTeam#Process_states [09:00] cpaelzer: yes I think so [09:04] cpaelzer: so do I do that? [09:05] done [10:13] jdstrand_: hey - just tripped on https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1823862 - something you where aware of? [10:13] Launchpad bug 1823862 in ufw (Ubuntu) "disco: unable to enable ufw" [Undecided,New] [11:22] xnox, vorlon, what is happening to bug #1816812? it's 1 liner fix and important to have in disco, you agreed when we discussed it during the foundation team meeting some weeks ago ... is it still on track to land before the freeze this week? [11:23] bug 1816812 in systemd (Ubuntu Disco) "desktop logout delays due to missing PropertiesChanged signal" [Undecided,New] https://launchpad.net/bugs/1816812 [12:46] rbalint: you are saving my day on 1823872 thanks a lot [12:46] saw your update [12:46] if I can help anything let me know [12:47] let me check on steps to reproduce and prep an SRU Teamplate for you at least === jdstrand_ is now known as jdstrand [13:16] jamespage: python-os-* promoted [13:16] doko: ta [13:19] jamespage: looks like websockify isn't yet ready [13:19] websockify is, spice-html5 is not [13:19] at least I think that's what cpaelzer indicated [13:23] yes [13:23] jamespage: yes you said you want to punt spice-html5 after my feedback [13:24] doko: what else seems missing on websockify - IIRC it had no hard dependency on spice-html5 [13:25] ahh, ok [13:28] websockify promoted [13:58] cyphermox: jamespage: new heat-dashboard version uploaded to disco with tests running successfully [14:05] rbalint: FYI I added you test steps and an SRU template as promised [14:05] rbalint: if you have a PPA that I should test let me know [14:17] hi folks. today i noticed a strange behaviour in apt, that might be a bug in ubuntu or upstream. what place is best to report bugs? launchpad? ubuntuforums.org? some other place? please advice. [14:18] Not the forums! "ubuntu-bug apt" is normally best [14:21] cjwatson: looks neat. thank you! [14:22] np [14:34] coreycb: hurray :) [14:51] coreycb: mir approved [14:51] cyphermox: thanks! [15:14] cpaelzer, thanks, i'm adding build time tests as well because i'm fixing conffile moves in general (wip: https://github.com/rbalint/unattended-upgrades/tree/conffile-moves ) [15:26] ok great [15:28] kyrofa: hey, the darktable snap doesn't support opencl? [15:29] tjaalton, it seems not, but I haven't had time to dig into why [15:31] it tries to search for libOpenCL.so.1 [15:31] can't find it if it's installed on the system [15:31] probably the same for the drivers [15:37] tjaalton, looks like we'd need to bundle opencl: https://forum.snapcraft.io/t/snaps-and-opencl/8509/10 [15:38] yeah, fun [15:38] I've now packaged the intel neo driver [15:38] and tested it using darktable. deb works, snap doesn't [16:07] tjaalton, if you have ideas, pull requests are always welcome [16:10] there would have to be a platform snap for it [16:10] or if there is, opencl support added to it [16:10] otherwise it's just madness adding all drivers to each snap that might use opencl [16:14] though it might be an unavoidable madness :) [16:43] jamespage: yikes, no, thanks :) [16:57] jdstrand: I tripped over it this morning - we use ufw to secure firewall comms between swift storage nodes for openstack [17:00] jamespage: I asked for more information [17:19] hi [17:20] I've been trying to deal with this bug for days now: https://bugs.freedesktop.org/show_bug.cgi?id=110214 [17:20] Freedesktop bug 110214 in Drivers/Gallium/radeonsi "radeonsi: xterm scrollback buffer disappears while Shift+PgUp and Shift+PgDn" [Normal,New] [17:20] basically, xterm does not behave properly (the fonts become invisible when I shift+pageup) [17:20] however, on ubuntu this works fine... on other distros, I get the bug [17:21] I was wondering if ubuntu devs can shed me some light into why it works on ubuntu and doesn't on other distros [17:22] we tried a lot of things... [17:26] none of the patches in xterm's debian/patches/ directory feel like they'd be involved [17:26] is it the same version on all those distros? [17:27] it might be a gallium/radeonsi patch thing too [17:27] or a default setting difference [17:27] Most likely to be a kernel/mesa/xorg difference than an xterm thing. [17:27] might be freetype too [17:28] xterm's font rendering is from 1975, I don't suspect much trickery there. [17:28] If it was gnome-terminal, I'd go looking for differences in pango. [17:30] JanC: no, but we compiled different versions of Xephyr, mesa, xterm, etc. yet it only works on ubuntu for some reason [17:30] it might be as simple as a different default setting in Ubuntu? [17:31] on arch it works if I disable GL_NV_texture_barrier or if I export R600_DEBUG=nodpbb, which seems strange, I wonder what ubuntu is doing different [17:33] I tried looking at the patches ubuntu applies on top of mesa and there doesn't seem to be anything related [17:34] bdmurray: since you are so closely aligned with apport, can you explain to me why python3-launchpadlib is a suggest for python-apport rather than a depend as it once was? [17:34] wxl: Are you sure it was a depend? [17:35] not sure if I'm looking at the right thing... [17:35] bdmurray: yeah, like back in saucy or something XD [17:35] bdmurray: since it is required for apport-collect, i can at minimum see it being a recommend. suggest seems way too weak [17:38] wxl: the rationale is in the bzr log and bug 1192330 although it may not apply anymore since there is python3-launchpadlib [17:38] bug 1192330 in apport (Ubuntu) "missing dependencies on Ubuntu Server" [Medium,Fix released] https://launchpad.net/bugs/1192330 [17:39] bdmurray: yeah, i saw that. i guess the question is why we haven't returned it back to the way it was given that that's not entirely relevant anymore. [17:40] wxl: because its not a huge priority [17:41] bdmurray: ok good enough for me :) if i submitted a fix i presume there would be no other reason to think it wouldn't be accepted? [17:43] wxl: well another reason it wouldn't be accepted might be the release coming up [17:44] bdmurray: yeah i didn't mean NOW. :) good enough, thanks [17:47] jamespage: thanks for the added info. please see comments (still can't reproduce) [19:03] mdeslaur, stgraber: meeting? [19:23] where can I see how a package was compiled with? configure switches, etc [19:23] or rather, how [19:23] build logs are available on launchpad [19:23] thanks [19:24] from eg https://launchpad.net/ubuntu/+source/xterm you can click the 330-1ubuntu2 under bionic beaver, then amd64 under builds, then buildlog on the left [19:34] got it, thanks [19:46] for mesa, I see it applies a few patches [19:46] https://launchpadlibrarian.net/417491370/buildlog_ubuntu-disco-amd64.mesa_19.0.1-1ubuntu2_BUILDING.txt.gz [19:46] e.g. Applying patch revert-set-full-thread-affinity.diff [19:47] do you know where can I see those patches? [19:47] the easiest way is to have deb-src lines configured in your apt sources, then you can use apt-get source mesa and then it'll probably be in mesa*/debian/patches/ [19:48] thanks [19:49] if you just want the patches you can find the deltas from debian on https://patches.ubuntu.com/ [20:08] thanks [20:08] I guess I'll compile mesa and revert that commit [20:08] https://gitlab.freedesktop.org/mesa/mesa/commit/d877451b48a59ab0f9a4210fc736f51da5851c9a [20:09] I can't see other patches that relates to radeonsi [20:09] dviola: wow. if *that*s the fix I'm going to be very dissapointed [20:09] hrm, I have no idea :) [20:12] we've spent crazy amount of time with this bug already... hopefully it's this one [20:12] everything we tried, it failed basically [20:13] except this: export R600_DEBUG=nodpbb [20:13] and the other extension [20:19] fedora is affected, arch is affected [20:19] ubuntu doesn't have the bug [20:42] at least it reverted cleanly [20:42] ok mesa is compiling [20:49] nope, that wasn't it [20:53] bdmurray: hi, would you happen to have cycles to take a look at tye python-oslo.cache fix in the cosmic unapproved queue? i just uploaded it today. it's currently tagged as a release blocker for the openstack charms release. [20:54] coreycb: sure [21:03] found another potential culprit [21:03] a patch [21:03] https://patches.ubuntu.com/x/xorg-server/xorg-server_2:1.20.4-1ubuntu3.patch [21:04] glamor-disable-logic-ops-when-doing-compositing.diff: Fix libreoffice with glamor. (LP: #1575000) [21:04] Launchpad bug 1575000 in xorg-server (Ubuntu Xenial) " font glyph corruption on dialog box" [High,Fix released] https://launchpad.net/bugs/1575000 [21:19] that patch is already merged upstream, so it can't be that [21:20] thanks bdmurray === msmarcal is now known as msmarcal|eod