[06:56] <RikMills> mparillo: thanks :)
[11:47] <santa_> hi everyone
[11:48] <RikMills> hi
[11:48] <santa_> RikMills: yesterday I got a weird FTBFS in plasma-desktop, apparently something change in impish and that something broke the build
[11:49] <santa_> I could reproduce it in a PPA: https://launchpad.net/~panfaust/+archive/ubuntu/kde-test-bad/+packages
[11:50] <santa_> also in my server against fw 5.81 http://tritemio-groomlake.duckdns.org/build-status/buildstatus_ubuntu-exp2/ubuntu-exp2_status_plasma.html
[11:50] <santa_> and against fw 5.82 http://tritemio-groomlake.duckdns.org/build-status/buildstatus_ubuntu-exp2/ubuntu-exp2_status_plasma.html
[11:50] <santa_> previously it was building fine against both fw versions
[11:51] <santa_> I checked if they were cmake, pkg-config, xorg-server new versions in impish, but nope, they are the same versions we had before
[11:52] <santa_> if you look at the failure build logs:
[11:52] <RikMills> -- The following features have been disabled:
[11:52] <RikMills>  XorgServer, XServer header needed for touchpad KCM (X11 backend)
[11:52] <santa_> 1. it fails to detect x server, yes
[11:52] <santa_> 2. missing files at the end of build log
[11:53] <santa_> I also checked the plasma-desktop git in case there was some kind of fix, but I found nothing
[11:54] <santa_> also note that in the PPA only fails for some archs :| that's weird
[11:56] <RikMills> sometimes that means that whatever changed has only build for certain arches so far
[11:57] <santa_> yeah, maybe
[12:00] <santa_> -- Checking for module 'xorg-server'
[12:00] <santa_> --   Package 'valgrind', required by 'libdrm', not found
[12:00] <santa_> wat
[12:13] <RikMills> so does it build with proposed disabled....
[12:17] <RikMills> libdrm build depends on valgrind [amd64 armhf i386 mips mipsel powerpc s390x]
[12:18] <RikMills> which tallies with our failing arches
[12:20] <RikMills> santa_: https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#libdrm
[12:20] <RikMills> the fails there are failure to find valgrind on a build test
[12:30] <BluesKaj> Hi folks
[12:33] <RikMills> santa_: gotta go for a short while. back later
[12:34] <santa_> ack, I'm testing some things
[12:34] <RikMills> builds ok without proposed
[13:04] <santa_> builds fine just installing valgrind, soe I guess addit it to build depends would workaround the thing
[13:08] <santa_> * adding
[13:28] <santa_> fails to build with nothing from proposed but libdrm-dev
[13:28] <RikMills> ok, we can add that dep if and when we hit things
[13:29] <RikMills> until it gets fixed
[13:30] <santa_> yep, I'm rebuilding in my PPA the failed build, I presume it might fail for all archs now
[13:31] <RikMills> I tried that in a ci-train ppa, and it still failed
[13:33] <RikMills> so I think on the arches that libdrm build deps on valgrind, it somehow now grows a dev package dependency on it
[13:33] <RikMills> I am not sure why the new libdrm in propose might now do that
[13:36] <RikMills> santa_: should note that riscv64 doesn't have a build of valgrind, so I guess any dep would need to be [!riscv64]
[13:37] <RikMills> which I am trying now
[13:37] <santa_> I have the impression that libdrm-dev should depend on valgrind [amd64 armhf i386 mips mipsel powerpc s390x]
[13:38] <santa_> (thats what new libdrm has in Build-Depends
[13:38] <santa_> )
[13:41] <RikMills> agreed
[13:41] <RikMills> or at least that seems logical on the facts
[13:44] <RikMills> I think we are going to get a few things like this for this cycle, where ubuntu is syncing less well tested new things from experimental more often :/
[14:12] <santa_> yeah, with sid freezed it's difficult to discern packages actually meant for debian experimental and packages which were uploaded to experimental because they can't be uploaded to sid
[14:12] <santa_> + the fact that debian experimental is not managed by britney which tends to reveal packaging problems
[14:13] <santa_> ok, so after a rebuild of plasma-desktop I can say you are right that the thing fails only for archs where valgrind is in libdrm build depends
[14:22] <santa_> http://tritemio-groomlake.duckdns.org/ka-iron-hand_reports/frameworks_archive/5.82_impish_retry_builds.pdf
[14:22] <santa_> http://tritemio-groomlake.duckdns.org/ka-iron-hand_reports/frameworks_archive/5.82_impish_proposed_migration.pdf
[14:39] <RikMills> kool. thanks
 TAG Everyone!
 A question regarding usb-creator-kde. The 21.04 version seems to suffer from this bug: https://bazaar.launchpad.net/~usb-creator-hackers/usb-creator/trunk/revision/488.
 If I manually install python3-sip, usb-creator-kde will run.  But I am curious how the above patch should trickle down as a standard update.
[14:54] <santa_> probably that change will generate different depends
[14:58] <santa_> hmm, nope
 @DarinMiller, 0.3.10 in updates should be fixed
[14:58] <santa_> Depends: ${misc:Depends}, ${python3:Depends},
[14:58] <santa_>  usb-creator-common (= ${binary:Version}), python3-pyqt5, python3-dbus.mainloop.pyqt5y
 @DarinMiller 0.3.10 does not require python3-sip to be installed
[15:00] <santa_> depends of usb-creator-kde above, the stuff they are using after the change is probably provided by python3-pyqt5
[15:00] <santa_> so indeed no need for python3-sip to be installed
[15:02] <santa_> (at least manually)
 @DarinMiller the update to fix it in hirsute is 90% phased, so you may be in the 10% if you don't have it yet
[15:03] <santa_> https://launchpad.net/ubuntu/+source/usb-creator
[15:04] <santa_> still in hirsute-proposed
[15:04] <santa_> oh, and updates, nvm