=== plars_ is now known as plars
=== ebarretto_ is now known as ebarretto
[02:25] <xnox> doko:  you re-added python-minieigen can i drop it again? otherwise it ftbfs against the new boost
=== pieq_ is now known as pieq
=== SuperKaramba is now known as BenderRodriguez
=== sparr_ is now known as sparr
=== addyess_ is now known as addyess
[07:30] <cpaelzer> I was finding https://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.html update slowly the last few days
[07:30] <cpaelzer> last 24 hours it didn't update at all
[07:30] <cpaelzer> is anyone aware of details what might be going on ?
[07:30] <cpaelzer> (I have pinged the last two days but I'm not sure who owns/manages this)
[07:31] <JackFrost> Urgh, ruby-zip still hasn't migrated..
[07:36] <cpaelzer> kanashiro: ^^ FYI
[07:36] <JackFrost> I hit retest on yet another failing test, hopefully it'll work this time.
[07:37] <JackFrost> Another == it didn't want to re-test with the "new" ruby-roo, so I had to manually kick them all off.
[08:31] <Aliekezhi> hi, I'm trying to edit gnome css files but it doesn't seem to have any effect. modifying all of .css files /usr/share/gnome-shell/theme$
[08:32] <Aliekezhi> is there another file used by default on ubuntu ?
[09:33] <jamespage> xnox: I'm having trouble with boost-context on s390x  - https://launchpadlibrarian.net/463652248/buildlog_ubuntu-focal-s390x.ceph_15.1.0-0ubuntu1~ubuntu20.04.1~ppa202002051350_BUILDING.txt.gz
[09:33] <jamespage> for the time being I'm going to disable use on s390x to allow your boost transition to proceed
[09:53] <ogra> waveform, sil2100 the new flash-kernel breaks all my lxd containers on my pi's ... could we add a runtime test if the environment is a container ?
[09:53] <doko> tkamppeter: th ghostscript sync without the completed MIR makes a lot of packages now ftbfs
[10:12] <kanashiro> JackFrost, re ruby-zip: did you do any investigation on s390 autopkgtest failure?
[10:20] <jamespage> hmm is there something up with the launchpad builders? I swear I just saw a load of active builds for a PPA disappear and restart?
[10:22] <seb128> jamespage, probably more a question for #launchpad, but I saw some weird thing happening to one of my ppa builds as well
[10:47] <sahid> jamespage, coreycb, cinder is ready https://code.launchpad.net/~sahid-ferdjaoui/ubuntu/+source/cinder/+git/cinder
[10:48] <ogra> waveform, sil2100 seems FLASH_KERNEL_SKIP also became a no-op now ? (at least exporting it doesnt stop f-k from running here)
[10:51] <waveform> ogra, which version?
[10:53] <ogra> waveform, https://paste.ubuntu.com/p/xcG6gQkFnc/
[10:54] <ogra> thats a freshly pulled bionic container simply running apt update/upgrade
[10:55] <ogra> (this run with FLASH_KERNEL_SKIP set ... but it doesnt seem to make any difference)
[10:56] <waveform> ogra, that looks like it can't determine the kernel version (judging by the search paths); FLASH_KERNEL_SKIP *should* still work ... let me check the postinst in the bionic branch
[11:04] <waveform> ogra, FLASH_KERNEL_SKIP looks like it should still work: https://git.launchpad.net/ubuntu/+source/flash-kernel/tree/debian/flash-kernel.postinst?h=ubuntu/bionic-devel&id=b2fbda45824cfdd2950349979b1cfda52fa86d9d#n48
[11:05] <ogra> yeah, that seems to be an issue with the way i execute apt in a non-interactive shell ...
[11:06] <ogra> yet it would still be cool if it simply detected that it runs inside a contrainer ... that will likely also break armhf docker images on upgrade
[11:08] <xnox> jamespage:  ack and thank you. I will escalate this back to IBM they had students port boost context for ceph specifically, as nothing else important uses it pretty much =)
[11:17] <tkamppeter> doko, how? Are they using libgs?
[11:18] <xnox> jamespage:  i wonder if i missbuilt it
[11:21] <waveform> ogra, wouldn't it be better not to have flash-kernel installed at all? I've just tried firing up a bionic container on a pi to see what "linux-version list" returns (nothing, which explains why flash-kernel's getting confused about its search paths), and I note u-boot isn't installed, /lib/firmware doesn't exist, etc. so it seems a bit odd that flash-kernel is there at all?
[11:22] <ogra> waveform, well, some seed or taks pulls it in for whatever reason ... i agree it should probably not be there
[11:22] <ogra> *task
[11:24] <waveform> ogra, that would seem the preferable course of action here - rather than adding logic for detecting various containers to flash-kernel - especially when we've apparently managed to exclude stuff like u-boot and the linux firmware from the image
[11:25] <ogra> well, it would protect people that accidentially get it pulled in through a dependency
[11:25] <ogra> (or explicitly install it but then they should perhaps know about FLASH_KERNEL_SKIP)
[11:26] <ogra> ... though it might make F_K_S unnecessary completely
[11:27] <waveform> F_K_S seems to be used by the packaging system too (judging from the comments) so I suspect it has some other uses which would keep it around; I'm sure I recall *some* detection code somewhere already but I can't remember where I saw it
[11:27] <waveform> still, for now I'm definitely leaning toward ensuring our images simply don't include f-k - it's a cleaner solution
[11:28] <waveform> oh, the initramfs hooks it installs ... that's where the detection is
[11:30] <jamespage> xnox: its odd because the unit that fails lists boost_context in the list of things to link with
[11:31] <jamespage> and I only see this on s390x - other archs that have previously built with boost-context continue todo so
[11:31] <jamespage> sahid: sorry missed your ping - looking now
[11:32] <xnox> jamespage:  i do wonder if some included copies of code leaked into the build. cause there is a copy of boost in ceph, and a system one, which are out of sync on s390x now.
[11:33] <xnox> (only on s390x they are out of sync)
[11:33] <jamespage> hmm
[11:34] <xnox> minor for now, will play with it when everything else is more in shape
[11:36] <jamespage> yah
[11:41] <tkamppeter> doko, the openjpeg2 MIR finished finally after 9 years, otherwise I had not done the sync, the urw-fonts MIR should go quickly, as it has no executable code, only data.
[11:42] <tkamppeter> bug 1862048
[11:42] <ubottu> bug 1862048 in fonts-urw-base35 (Ubuntu) "[MIR] fonts-urw-base35" [Undecided,New] https://launchpad.net/bugs/1862048
=== mpt_ is now known as mpt
[12:28] <mdeslaur> tjaalton: how do I install the hwe stack on bionic? I tried the instructions here: https://wiki.ubuntu.com/Kernel/LTSEnablementStack but it didn't pull in xorg-server-hwe-18.04...
[12:30] <mdeslaur> tjaalton: ah, never mind, I fat-fingered it
[12:30] <tjaalton> :)
[12:30] <mdeslaur> -ENEEDCOFFEE
[12:36] <ahasenack> cpaelzer: +1ed https://code.launchpad.net/~paelzer/ubuntu-seeds/+git/platform/+merge/378436
[12:50] <ahasenack> rafaeldtinoco: hi, could you perhaps pick this one up? It's related to the i386 work you did in samba:
[12:50] <ahasenack>  LP: #1861316 - (New)            [samba]          - ubuntu 20.04: libnss-winbind:386 should remain
[12:50] <ubottu> Launchpad bug 1861316 in samba (Ubuntu) "ubuntu 20.04: libnss-winbind:386 should remain" [High,Triaged] https://launchpad.net/bugs/1861316
[12:57] <rafaeldtinoco> ahasenack: I'll get it
[12:57] <rafaeldtinoco> if its just adding them back it will be easy
[12:57] <rafaeldtinoco> based on what steve has replied
[12:58] <ahasenack> yep
[12:58] <ahasenack> thanks
=== ricab is now known as ricab|lunch
[13:31] <RikMills> marcustomlinson: smoketest, test-extension & odk-build-examples fail with badpgk as they depend on the nogui packages, which don't seem to exist on armhf
[13:37] <marcustomlinson> RikMills: interesting, thanks I'll have a look
[13:44] <cpaelzer> ahasenack: thanks pushing ndctl change
[13:44] <cpaelzer> cjwatson: also did fix up the report generation \o/
[13:45] <cpaelzer> ahasenack: so in a bit we can try to grab an AA and get things moved
[13:45] <ahasenack> ok
=== ricab|lunch is now known as ricab
[15:15] <JackFrost> kanashiro: ZipFileExtractTest#test_extract_incorrect_size was the test failure, wanted to see if it'd fix on re-try.
[16:03] <tkamppeter> doko, could you help on a gcc problem with ppc64: bug 1862053?
[16:03] <ubottu> bug 1862053 in gcc (Ubuntu) "Compiler gets stuck (or extremely slow) on ppc64el" [High,New] https://launchpad.net/bugs/1862053
[16:08] <juliank> tjaalton: OK, got a soft hang with -13 now, while running hangout meet
[16:09] <juliank> but I mean, hangouts is crazy
[16:10] <juliank> without iris now, default mesa i915 driver again
[16:10] <juliank> this is likely a different issue
[16:11] <tjaalton> check dmesg
[16:12] <juliank> dmesg just says
[16:12] <juliank> [10161.268097] i915 0000:00:02.0: GPU HANG: ecode 9:1:0x00000000, hang on rcs0
[16:12] <juliank> and then two reset messages
[16:12] <tjaalton> ok
[16:13] <tjaalton> file a new bug upstream I guess, saying that the fix from the other one is already included
[16:13] <juliank> yup
[16:15] <tjaalton> grab /sys/class/drm/card0/error
[16:23] <juliank> tjaalton: Yes, sure, I did. I'd love to reboot with drm debug, but I don't want to spam my journal with huge kernel logs :/
[16:24] <juliank> Then I can keep a window with netflix running while working and if it hangs we get a lot of nice debug
[16:24] <juliank> or a hangout meet, but needs lot of people
[16:25] <tjaalton> you don't need drm debug, it should always save the error state there
[16:25] <tjaalton> drm debug only shows what the driver is doing, mostly helpful with modesetting issues
[16:26] <juliank> intel wants that, though, they say
[16:30] <tjaalton> for hangs?
[16:30] <tjaalton> it does say things about the hw though
[16:31] <juliank> tjaalton: forwarded to https://gitlab.freedesktop.org/drm/intel/issues/1150
[16:32] <juliank> tjaalton: It's just in their generic bug reporting guidelines
[16:32] <juliank> aka https://gitlab.freedesktop.org/drm/intel/-/wikis/How-to-file-i915-bugs
[16:32] <juliank> ah it says and/or a crash dump
[16:33] <juliank> missed the and/or :D
[16:33] <tjaalton> ok
[17:08] <tjaalton> juliank: are you able to modify the mimetype of the attachments of your bug? the error state shows as octet-stream and not text/plain
[17:09] <juliank> hmm
[17:09] <tjaalton> oh, I have the same laptop :P
[17:10] <tjaalton> time to upgrade to focal
[17:10] <juliank> tjaalton: I re-uploaded it as error.txt, but that did not seem to help
[17:11] <juliank> in any case it downloads
[17:11] <juliank> other people simply embed ``` the dump, but that's too much text for me to be comfortable embedding
[17:12] <juliank> but it should respond text/plain now
[17:12] <tjaalton> probably just a feature of gitlab, I prefer to open them on the browser
[17:12] <tjaalton> and a regression compared to bugzilla
[17:13] <juliank> they're stored in storage.googleapis.com
[17:13] <juliank> But it redirects with response-content-disposition=attachment
[17:13] <juliank> it could probably redirect with response-content-disposition=inline or something set
[17:14] <juliank> you can grab it like this:
[17:14] <juliank> https://storage.googleapis.com/fdo-gitlab-uploads/%40hashed/f3/6e/f36e412aea00d7c622f3d331c5ceec42eaf18bda2d0374971a09fc79d7d9f293/8dfdebf043239f6d2e192c7826638e99/error.txt?response-content-disposition=inline%3B%20filename%3D%22error.txt%22%3B%20filename%2A%3DUTF-8%27%27error.txt&amp;response-content-type=text%2Fplain&amp;GoogleAccessId=GOOGOEXJKVLVDILPMJ5V2WSY&amp;Signature=kuzMpvRKv0nLaTY7
[17:14] <juliank> Cb8b%2F%2BzYsKc%3D&amp;Expires=1581009795
[17:14] <juliank> Or you could write a browser extension that rewrites the urls for you
[17:15] <tjaalton> well, error.txt is at least being opened in an editor, instead of just saving to disk
[17:15] <juliank> that's good
[17:15] <tjaalton> but it is what it is :)
[17:17] <juliank> hmm there's a weird bug in nautilus
[17:17] <juliank> when you have a video in a directory it has padding at the top of the item grid
[17:18] <juliank> it's not normally there
[17:18] <juliank> If you do it with a picture it's at the left
[17:30] <didrocks> doko: it seems that grub2 is blocked as build-dep on python, should it only bump the build-dep to mention "python2"?
[17:34] <cjwatson> didrocks: I fixed that to use python3 in Debian some time back
[17:34] <cjwatson> Like August
[17:35] <cjwatson> Somebody should merge it
[17:35] <didrocks> cjwatson: ack, thanks!
[17:36] <cjwatson> https://salsa.debian.org/grub-team/grub/commit/615a8893413f85c58e59a99948f97ceb9ab5dc16
[17:37] <didrocks> cjwatson: I was just looking. I think I’ll cherry-pick to unblock the package. Thanks :)
[17:44] <mitya57> xnox, Trevinho: hi, do you know whether we still need the window-mocker package? It is the last package that depends on python-qt4, which I want to remove.
[17:44] <mitya57> Its reverse dependencies are python3-autopilot-tests and unity-autopilot and you touched these packages last, that's why I'm asking you.
[17:44] <Trevinho> mitya57: not that I know
[17:45] <Trevinho> I suppose we can also get rid of the unity-autopilot one
[17:46] <mitya57> If you could do a MP that would be nice.
[17:54] <mitya57> Hmm, I think python3-autopilot-tests should depend on python3-windowmocker instead of python-windowmocker. Its other dependencies are already python3-*.
[17:55] <mitya57> xnox: ^^^
[17:55] <mitya57> This way we will be able to drop at least the Python 2 version of window-mocker (and python-qt4).
[19:49] <ahasenack> hi, the package src:vmem was not being synced from debian because it had binaries conflicting with pmdk <= 1.7. I now updated pmdk in focal, it migrated, and was wondering if I need to sync vmem manually, or if a cron job somehwere will take another shot at it
[19:50] <ahasenack> OK (Y/n)?  y
[19:50] <ahasenack>  * Trying to add vmem ...
[19:50] <ahasenack> vmem_1.8-1 is trying to override modified binary libvmem1_1.7-1ubuntu1.  OK (y/N)?  n
[19:50] <ahasenack> let me see when that ran
[19:51] <ahasenack> hm, looks like 3 times a day
[19:51] <ahasenack> I'll check again tomorrow
=== hggdh is now known as hggdh-msft
[20:53] <ahasenack> Skuggen: hi, around? Sorry, I don't know your tz
[21:56] <xnox> mitya57:  ideally i want to drop all of autopilot but i fear it is still used in places - like ubiquity ui tests
[21:57] <xnox> seb128:  Laney: jibel:  do we still run the autopilot ubiquity tests? any others?
[21:57] <xnox> mitya57:  and what is python3-windowmocker written in? Imho we should only really need gtk3 python3 portions of autopilot, but i am not sure how to untangle it all