[08:19] <zhsj> hi, could someone retry the build https://launchpad.net/ubuntu/+source/golang-golang-x-tools/1:0.6.0+ds-1/+build/26311726
[10:18] <ginggs> zhsj: .
[11:01] <paride> @pilot in
[12:19] <adrien>  \o
[12:29] <adrien> I'm doing +1 (I actually started on yesterday but I was digging in and tooling); can someone retry dolphin on armhf? retry-autopkgtest-regressions --blocked-by-tests dolfin | grep armhf
[12:29] <adrien> there have been many timeouts on armhf over the week-end and this one has shown timeouts too
[13:03] <jawn-smith> adrien: I'm on it
[13:23] <adrien> jawn-smith: \o/
[13:23] <adrien> and thanks :)
[13:24] <jawn-smith> yw!
[13:59] <adrien> ftr coq packages are blocked by 3 FTBFS: two of them will be fixed by merging from debian and one of them will also be fixed by merging but it does so by dropping 32-bit arches and I think there's a better fix (from upstream); I've added a report on LP with update-excuse tag and debian bug watch
[14:32] <paride> @pilot out
[14:38] <adrien> can someone retry-autopkgtest-regressions --blocked-by-tests gnustep-base | grep amd64
[14:38] <adrien> thanks :)
[14:39] <adrien> basically, gnustep-base uses httpbin.org for some of its tests and the host been unreliable but it seems fixed now so there's a window for making this pass
[14:39] <adrien> I think it's safe to do it on all arches; I'll let you judge if you want to do on more
[14:40] <adrien> there's also a patch upstream to use example.org/net instead but there's no reason to wait on that (it's not part of a release yet but I'm filling a bug in debian)
[15:00] <lvoytek> @pilot in
[15:11] <ginggs> adrien: gnustep-base triggered (on all arches)
[15:11] <adrien> thanks :) hopefully the timing is right and it passes
[18:58] <kanashiro[m]> vorlon: I'd like to ask if it is possible to remove containerd/1.7.2-0ubuntu2 (source and binaries) from mantic-proposed. I filed this bug with more details of what is happening LP: #2024490
[18:58] -ubottu:#ubuntu-devel- Launchpad bug 2024490 in containerd (Ubuntu) "[RM] Remove containerd from mantic-proposed" [Undecided, New] https://launchpad.net/bugs/2024490
[18:59] <lvoytek> @pilot out
[19:00] <kanashiro[m]> sorry, this should have gone to #ubuntu-release
[19:05] <seb128> kanashiro[m], removed
[19:05] <kanashiro[m]> seb128: thank you!
[19:05] <seb128> np!
[20:02] <adrien_> kanashiro[m]: btw, I'm looking at rack-related migrations and I'm wondering why it Replaces: ruby-rack (<< 3.0.0-1); disclaimer: I'm not familiar with these packages and I might also be unaware of some trick
[20:10] <adrien_> ftr, R packages seem to often need https://cran.r-project.org/doc/manuals/r-release/R-exts.html#Converting-a-package-to-use-registration  which is part of https://github.com/edzer/intervals/commit/a8078e662b857fbee418e0c545c9805012b5f011 AFAIU
[20:10] -ubottu:#ubuntu-devel- Commit a8078e6 in edzer/intervals "address various CRAN issues"
[20:12] <adrien_> unfortunately I'm not sure all these packages are well-maintained
[20:12] <adrien_> s/packages/sources/
[20:15] <kanashiro[m]> adrien_: those are new packages and some code there used to be in ruby-rack before 3.0. I need to work on the transition to ruby-rack 3 in the debian side
[20:16] <kanashiro[m]> it is in my todo list
[20:22] <adrien_> kanashiro[m]: ok; so, is ruby-rack 3.0.0-1 usable? I'm asking because of https://launchpad.net/ubuntu/+source/ruby-rack/3.0.0-1ubuntu1
[20:22] <adrien_> and https://ubuntu-archive-team.ubuntu.com/proposed-migration/update_excuses.html#ruby-rack
[20:24] <kanashiro[m]> adrien_: some apps still do not support ruby-rack version 3 upstream, if you check the bug in the end of the excuses entry you'll see that I added the block-proposed tag to not let it migrate until I make sure everything is good to go
[20:26] <adrien_> kanashiro[m]: ah, right, sorry for the noise; I've been using other frontends to excuses today and they're not showing bugs!
[20:26] <adrien_> thanks!
[20:26] <kanashiro[m]> yw :)
[20:28] <kanashiro[m]> adrien_: I suppose you are working on a +1 maintenance shift, right? If you want to submit patches to the packages blocking ruby-rack I'd be happy in reviewing them, but I'd like to tackle them in Debian first
[20:31] <adrien_> right, +1; there are quite a few things stuck at the moment and which seem to only need small nudges so I'm focusing on these at the moment; or at least analyzing the current set of excuses so that subsequent people on +1 have an easier time
[20:31] <adrien_> (plus I really don't know ruby)
[20:31] <adrien_> but I might have a look
[20:31] <kanashiro[m]> it is up to you :)
[20:31] <adrien_> it probably depends on whether I have the courage to look at the 50 or so R packages with issues :D
[20:32] <kanashiro[m]> have fun!
[20:44] <adrien> hah, for R: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034683
[20:44] -ubottu:#ubuntu-devel- Debian bug 1034683 in src:r-base "r-base: new upstream release unintentionally uploaded to unstable" [Serious, Open]
[20:44] <adrien> > r-base (4.3.0-1) unstable; urgency=medium
[20:44] <adrien> > .
[20:45] <adrien> >   * New upstream release (into 'experimental' while Debian is frozen)
[20:45] <adrien> spot the issue
[20:45] <sarnold> oops
[20:45] <sarnold> how bad is that to undo?
[20:46] <adrien> it seems it was fine for debian but for us, r-base probably needs to be removed from proposed for now
[20:48] <sarnold> ah nice, it looks like debian gets to just sit back and let things run their course... I bet that'd work for us, too?
[20:49] <adrien> dunno, I don't have enough experience to judge :)
[20:50] <adrien> but I can say that there are 23 packages impacted by the "registration" issue with native code bindings
[20:51] <adrien> at least one project is maybe abandonned (I looked at two, maybe three, so the ratio is not good)
[21:08] <mitya57> Hi! I'm getting 500 error when trying to retry an autopkgtest: https://autopkgtest.ubuntu.com/request.cgi?release=mantic&arch=armhf&package=python-hypothesis&trigger=sphinx-rtd-theme%2F1.2.2%2Bdfsg-1
[22:28] <bluca> for the cloud autopkgtest environment, is it LXD running the relevant ubuntu version under test? I need to reproduce the exact same running environment, to debug some weird test issues
[22:29] <bluca> if some documentation on how to replicate locally exist, would greatly appreciate a pointer
[22:57] <bdmurray> lxd is only used for the armhf instances otherwise we are launching instances with openstack and connecting to them via ssh
[23:01] <bluca> is that qemu VMs then?
[23:02] <bluca> (never used openstack, not familiar with it)
[23:07] <bluca> found https://packaging.ubuntu.com/html/auto-pkg-test.html#executing-the-test
[23:14] <bdmurray> I would start with using qemu as a backend and see if you can recreate the issue
[23:18] <bdmurray> mitya57: I restarted a service and was able to submit the test again