[06:18] <fenris> hi .. anyone notice about this issue on 21.04 ? https://ubuntuhandbook.org/index.php/2021/04/workaround-nautilus-admin-not-working-ubuntu-21-04/
[06:32] <fenris> all gvfs in hirsute is already latest .. but if still having error
[09:25] <utkarsh2102> LocutusOfBorg: hey, can you do some re-triggers for me w/ some triggers, please?
[09:25] <utkarsh2102> cf: https://autopkgtest.ubuntu.com/request.cgi?release=impish&arch=amd64&package=ruby-rails-html-sanitizer&trigger=ruby-loofah/2.10.0-1&trigger=ruby-rails-html-sanitizer/1.3.0-2
[09:26] <utkarsh2102> for arm64: https://autopkgtest.ubuntu.com/request.cgi?release=impish&arch=arm64&package=ruby-rails-html-sanitizer&trigger=ruby-loofah/2.10.0-1&trigger=ruby-rails-html-sanitizer/1.3.0-2
[09:26] <utkarsh2102> for armhf: https://autopkgtest.ubuntu.com/request.cgi?release=impish&arch=armhf&package=ruby-rails-html-sanitizer&trigger=ruby-loofah/2.10.0-1&trigger=ruby-rails-html-sanitizer/1.3.0-2
[09:26] <utkarsh2102> for ppc64el: https://autopkgtest.ubuntu.com/request.cgi?release=impish&arch=ppc64el&package=ruby-rails-html-sanitizer&trigger=ruby-loofah/2.10.0-1&trigger=ruby-rails-html-sanitizer/1.3.0-2
[09:27] <utkarsh2102> for s390x: https://autopkgtest.ubuntu.com/request.cgi?release=impish&arch=s390x&package=ruby-rails-html-sanitizer&trigger=ruby-loofah/2.10.0-1&trigger=ruby-rails-html-sanitizer/1.3.0-2
[09:28] <utkarsh2102> I've uploaded a fix for ruby-rails-html-sanitizer w/ newer API  of loofah, so it should migrate after this^
[09:29] <utkarsh2102> s/uploaded/got uploaded to Debian/g :)
[09:40] <LocutusOfBorg> .
[09:56] <utkarsh2102> awesome, thank you!
[09:57] <utkarsh2102> LocutusOfBorg: all passed (as expected), thanks, again!
[10:51]  * mwhudson waves https://code.launchpad.net/~mwhudson/ubuntu-seeds/+git/ubuntu/+merge/404107 around under any core devs noses
[10:59] <mwhudson> rbasak: merci
[13:29] <cipherboy> sergiodj: Cool, thanks! I'll take a look this afternoon :) That should help me a lot!
[13:29] <cipherboy> sergiodj++
[14:31] <sergiodj> cipherboy: awesome, let me know how it goes :)
[14:35] <ogra> mitya57, i see you are the one person that seems ot care for the packaging guide, would you be able to update https://packaging.ubuntu.com/html/communication.html to point to libera ? (still says irc.freenode.net)
[14:36] <mitya57> ogra: yes, I can do it
[14:36] <ogra> awesome !
[14:36] <ogra> (poerhaps a grep -R for freenode across the tree would also be a good idea 😉 )
[14:37] <mitya57> Right.
[15:41] <toabctl> sil2100, could you have a look at https://bugs.launchpad.net/ubuntu/+source/livecd-rootfs/+bug/1930686 plase? I think it's ready for moving from -proposed to -updates...
[15:52] <sil2100> toabctl: hey! Sure! Per the SRU policy there is a 7 day aging period before we can release a -proposed SRU to -updates
[15:53] <sil2100> That being said, livecd-rootfs is a bit of a special thing
[15:53] <toabctl> sil2100, isn't 7 days over?
[15:53] <sil2100> Since it can't really break users
[15:53] <sil2100> No, it was accepted on the 8th from what I see
[15:53] <sil2100> Anyway, I can handle it anyway as well, there's not much merit in letting it age longer anyway
[15:54] <toabctl> true (and sorry for the of-by-one error on my side)
[15:54] <waveform> rbasak, have you got a moment to have a look at the last comment on https://bugs.launchpad.net/ubuntu/+source/update-notifier/+bug/1836475 ? I'd like to have another stab at getting it SRU'd
[15:54] <toabctl> thanks!
[16:01] <smoser1> bdmurray: do you have thoughts on hallyn's lxc SRU bug 1923232 . Is the lxc autopkgtest there sufficient to mark as 'verification-done' ? if not, what else would you like to see?
[16:03] <bdmurray> smoser: I'll have a look today
[16:14] <smoser> thank you.
[16:18] <rbasak> waveform: I commented on bug 1836475. Does anyone specifically object to using a random delay for the SRU as a simpler fix less likely to hit user customizations? vorlon, any opinion, as you wanted to avoid a random delay earlier in the bug? Was that just for the development release or did you have an SRU in mind there as well?
[17:04] <petrj> hmm, on focal i tried to create a userspace riscv environment using: `apt install debootstrap qemu-user-static; qemu-debootstrap --arch riscv64 focal ubuntu-riscv64`
[17:04] <petrj> it errors out like `chroot: failed to run command '/debootstrap/debootstrap': Exec format error`
[17:05] <petrj> any ideas what am i missing?
[17:05] <cjwatson> Do you have binfmt-support installed?
[17:06] <petrj> `binfmt-support is already the newest version (2.2.0-2).`
[17:06] <petrj> yup
[17:08] <cjwatson> Seems to get past that stage for me FWIW
[17:09] <cjwatson> Maybe check with "update-binfmts --display qemu-riscv64" that that binary format is enabled?
[17:10] <cjwatson> But I'm about to be called for dinner
[17:11] <petrj> reproducible with just `docker run ubuntu:focal sh -c 'apt update && apt install -y debootstrap qemu-user-static; qemu-debootstrap --arch riscv64 focal ubuntu-riscv64'`
[18:06] <petrj> ah, thanks cjwatson! that was indeed the problem. the binary format was disabled so i had to run docker with priv and still enable it explicitly after the install.
[18:06] <petrj> `docker run --privileged ubuntu:focal sh -c 'apt update && apt in stall -y debootstrap qemu-user-static; update-binfmts --enable qemu-riscv6; qemu-debootst rap --arch riscv64 focal ubuntu-riscv64'`
[18:10] <mitya57> ogra: https://bazaar.launchpad.net/~ubuntu-packaging-guide-team/ubuntu-packaging-guide/trunk/revision/707
[18:10] <mitya57> The website will get automatically updated within a day.
[18:11]  * ogra hugs mitya57 
[20:00] <petrj> hmm, libomp5 and libomp-dev are missing from riscv64 (focal).
[20:01] <petrj> tracking down source repo suggests it comes from https://salsa.debian.org/pkg-llvm-team/llvm-toolchain/-/tree/11/debian
[20:01] <petrj> is that correct?
[20:06] <petrj> apparently there is no explicit exclusion or inclusion of any architecture for libomp*. does it mean someone here with superpowers can trigger the riscv64 build. if you are such person, please do! :)
[20:07] <cjwatson> You're probably looking at a newer version, since focal was released a year ago and stable releases only get selected updates.
[20:08] <cjwatson> For a relatively experimental architecture like riscv64, you might be better off using a newer non-LTS release.  That said, riscv64 doesn't have a libomp5 binary in impish either; it's clearly not just a matter of triggering a new build.
[20:09] <cjwatson> https://salsa.debian.org/pkg-llvm-team/llvm-defaults/-/blob/experimental/debian/control shows an explicit architecture list for libomp*.
[20:10] <cjwatson> Ah yeah, you were looking at the wrong repository.
[20:11] <cjwatson> But in any case https://salsa.debian.org/pkg-llvm-team/llvm-toolchain/-/blob/11/debian/control shows explicit architecture lists for libomp* too.
[20:25] <petrj> ah thanks cjwatson. i will send an MR adding riscv64 in architecture list. i have heard that it works (still waiting on gentoo packages webpage update to confirm this)
[21:05] <vorlon> rbasak: looking back, my objection there was not to the notion of a random sleep, but to an implementation that introduced random sleeps inside of cron.weekly.  I think that holds for SRUs as well as for devel.