[10:12] <ed_> quick question, how do you know if a package with sec fix in testing will sync to hirsute?
[10:28] <ronthecookie> hey so I installed bzr-builddeb but I still get `brz: ERROR: unknown command "dh-make"`? do I need to restart/source for more env vars or something?
[10:28] <ronthecookie> sourcing /etc/profile hasn't done much of anything
[10:40] <ronthecookie> (am I supposed to go ask in #ubuntu-motu instead?)
[10:42] <ed_> ronthecookie: isn't dh-make a package of its own?
[10:42] <ed_> so apt-get install dh-make
[10:43] <ronthecookie> I did, I'm following https://packaging.ubuntu.com/html/packaging-new-software.html#starting-a-package
[10:43] <ronthecookie> perhaps it is outdated
[10:45] <rbasak> ed_: it won't automatically. A manual step is required.
[10:53] <ed_> rbasak: ok, who/what should i speak to?
[11:02] <rbasak> ed_: can you provide more specifics please?
[11:05] <ed_> sure, rust-pleaser, will migrate into testing tonight. wanted to make sure that ubuntu hirsute gets that fix too
[11:06] <rbasak> Are you the Debian uploader? Why Hirsute? Do you mean Impish? Which releases in Ubuntu are affected?
[11:06] <ed_> hirsute needs the fix. impish has it already from sid.
[11:07] <ed_> im upstream/uploader, not the dd
[11:07] <rbasak> Ah, OK. Stable releases need a source package prepared with a version number "in the middle"
[11:07] <rbasak> If you can provide a debdiff, the security team will review and sponsor it.
[11:08] <ed_> are they happy to take https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=988071
[11:08] <rbasak> https://wiki.ubuntu.com/SecurityTeam/UpdateProcedures#Sponsoring_an_update
[11:08] <rbasak> That page is the starting point for what the security team have documented
[11:09] <ed_> ok i'll drop them a mail, thanks very much for the info!
[11:10] <rbasak> Try #ubuntu-hardened to speak to them
[11:10] <rbasak> They often have someone on rota to help with this kind of request
[11:10] <rbasak> And thank you for looking after the package in Ubuntu!
[11:11] <ed_> np, thanks for maintaining ubuntu!
[12:24] <RikMills> tjaalton: builds using libdrm in proposed are failing for amd64 armhf and s390x
[12:25] <RikMills> Package 'valgrind', required by 'libdrm', not found
[12:27] <RikMills> as are autpkgtests of clutter and wlroots
[12:29] <RikMills> as those have a 'build' test
[12:30] <RikMills> santa_: fyi ^
[15:06] <santa_> tjaalton: for the record, our guess is that libdrm-dev should depend on valgrind [amd64 armhf i386 mips mipsel powerpc s390x]
[15:06] <santa_> example of build failure: https://launchpad.net/~panfaust/+archive/ubuntu/kde-test-bad/+sourcepub/12418334/+listing-archive-extra
[19:27] <tjaalton> RikMills: there's nothing in libdrm which would require valgrind
[19:28] <RikMills> tjaalton: the build output disagrees
[19:29] <RikMills> -- Checking for module 'xorg-server'
[19:29] <RikMills> --   Package 'valgrind', required by 'libdrm', not found
[19:29] <tjaalton> I can read that, but it makes no sense
[19:30] <RikMills> :/
[19:32] <tjaalton> ok so it's libdrm_intel.pc which has ~always wanted it, but was fulfilled by some other dependency until now
[19:33] <tjaalton> just like libpciaccess-dev
[19:36] <RikMills> libdrm_intel.pc in 2.4.104-1build1 in the release pocket does not require it
[19:38] <RikMills> at least there is no: Requires.private: pciaccess >=  0.10, valgrind
[19:39] <santa_> tjaalton: FYI this new libdrm build depends on valgrind for a number of archs
[19:40] <tjaalton> oh i know
[19:41] <santa_> hence why I suggested that dependency for libdrm-dev above, but maybe there's a better solution
[19:41] <santa_> of course we can fix this in plasma-desktop but other packages will fail to build as well
[19:41] <tjaalton> it's caused by https://gitlab.freedesktop.org/mesa/drm/-/issues/45 most likely
[19:46] <tjaalton> https://gitlab.freedesktop.org/mesa/drm/-/issues/63 explains the regression
[19:46] <RikMills> just found that
[19:47] <tjaalton> I'll revert the commit
[19:49] <RikMills> thanks. hopefully they will figure out a better solution soon!
[22:11] <DarkTrick> **Q**@ help files: help files for programs on ubuntu are sorted by language, instead of "by program" ( /usr/share/help/[LANG]/[APP_ID]/ ). Is there any record on why this was choosen over sorting by application first and then by language?
[22:15] <DarkTrick> solved: apparently it's a freedesktop decision