[08:19] 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] zhsj: . [11:01] @pilot in === ChanServ changed the topic of #ubuntu-devel to: Archive: Mantic Open | Devel of Ubuntu (not support) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Bionic-Lunar | Patch Pilots: paride === Guest277 is now known as ogra === ogra is now known as Guest711 === Guest711 is now known as ogra [12:19] \o [12:29] 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] there have been many timeouts on armhf over the week-end and this one has shown timeouts too [13:03] adrien: I'm on it [13:23] jawn-smith: \o/ [13:23] and thanks :) [13:24] yw! [13:59] 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] @pilot out === ChanServ changed the topic of #ubuntu-devel to: Archive: Mantic Open | Devel of Ubuntu (not support) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Bionic-Lunar | Patch Pilots: N/A [14:38] can someone retry-autopkgtest-regressions --blocked-by-tests gnustep-base | grep amd64 [14:38] thanks :) [14:39] 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] 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] 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) === coreycb_ is now known as coreycb [15:00] @pilot in === ChanServ changed the topic of #ubuntu-devel to: Archive: Mantic Open | Devel of Ubuntu (not support) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Bionic-Lunar | Patch Pilots: lvoytek [15:11] adrien: gnustep-base triggered (on all arches) [15:11] thanks :) hopefully the timing is right and it passes === mmikowski5 is now known as mmikowski === klebers_ is now known as klebers [18:58] 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] @pilot out [19:00] sorry, this should have gone to #ubuntu-release === ChanServ changed the topic of #ubuntu-devel to: Archive: Mantic Open | Devel of Ubuntu (not support) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Bionic-Lunar | Patch Pilots: N/A [19:05] kanashiro[m], removed [19:05] seb128: thank you! [19:05] np! [20:02] 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] 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] unfortunately I'm not sure all these packages are well-maintained [20:12] s/packages/sources/ [20:15] 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] it is in my todo list [20:22] 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] and https://ubuntu-archive-team.ubuntu.com/proposed-migration/update_excuses.html#ruby-rack [20:24] 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] 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] thanks! [20:26] yw :) [20:28] 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] 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] (plus I really don't know ruby) [20:31] but I might have a look [20:31] it is up to you :) [20:31] it probably depends on whether I have the courage to look at the 50 or so R packages with issues :D [20:32] have fun! === adrien_ is now known as adrien [20:44] 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] > r-base (4.3.0-1) unstable; urgency=medium [20:44] > . [20:45] > * New upstream release (into 'experimental' while Debian is frozen) [20:45] spot the issue [20:45] oops [20:45] how bad is that to undo? [20:46] it seems it was fine for debian but for us, r-base probably needs to be removed from proposed for now [20:48] 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] dunno, I don't have enough experience to judge :) [20:50] but I can say that there are 23 packages impacted by the "registration" issue with native code bindings [20:51] at least one project is maybe abandonned (I looked at two, maybe three, so the ratio is not good) [21:08] 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] 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] if some documentation on how to replicate locally exist, would greatly appreciate a pointer [22:57] lxd is only used for the armhf instances otherwise we are launching instances with openstack and connecting to them via ssh [23:01] is that qemu VMs then? [23:02] (never used openstack, not familiar with it) [23:07] found https://packaging.ubuntu.com/html/auto-pkg-test.html#executing-the-test [23:14] I would start with using qemu as a backend and see if you can recreate the issue [23:18] mitya57: I restarted a service and was able to submit the test again