Bug#1083242: podman: obsolete conffiles aren't removed on upgrade
Package: podman Version: 5.2.2+ds1-2 Severity: important X-Debbugs-Cc: jcris...@debian.org Hi, The podman package used to ship conffiles in /etc/profile.d, but it doesn't clean them up on upgrade, so if podman-docker isn't installed the conffiles stick around as obsolete. Cheers, Julien -- System Information: Debian Release: trixie/sid APT prefers testing-debug APT policy: (600, 'testing-debug'), (600, 'testing'), (500, 'unstable-debug'), (500, 'stable-updates'), (500, 'stable-security-debug'), (500, 'stable-security'), (500, 'buildd-unstable'), (500, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386, arm64 Kernel: Linux 6.10.9-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages podman depends on: ii conmon 2.1.10+ds1-1+b1 ii golang-github-containers-common 0.60.3+ds1-3 ii init-system-helpers 1.67 ii libc62.40-2 ii libgpgme11t641.18.0-6+b1 ii libseccomp2 2.5.5-1+b1 ii libsqlite3-0 3.46.0-1 ii libsubid51:4.16.0-4 ii netavark 1.12.1-3 ii runc 1.1.12+ds1-5+b1 Versions of packages podman recommends: ii buildah 1.37.3+ds1-3 ii ca-certificates 20240203 ii containers-storage 1.55.0+ds1-3+b1 ii dbus-user-session 1.14.10-4+b1 ii passt 0.0~git20240906.6b38f07-1 ii slirp4netns 1.2.1-1+b1 ii tini0.19.0-1 ii uidmap 1:4.16.0-4 Versions of packages podman suggests: ii docker-compose 1.29.2-6.3 ii iptables1.8.10-4 -- Configuration Files: /etc/cni/net.d/87-podman-bridge.conflist [Errno 13] Permission denied: '/etc/cni/net.d/87-podman-bridge.conflist' -- no debconf information
Bug#1076449: mercurial: does not start anymore with python 3.12.4-3, hgdemandimport problem
On Tue, Jul 16, 2024 at 11:12:12 -0400, Daniel Serpell wrote: > Package: mercurial > Version: 6.8-1 > Severity: grave > Justification: renders package unusable > > Dear maintainer, > > In current sid, with python 3.12.4-3, mercurial fails at load with: > > ~$ hg > Traceback (most recent call last): >File "/usr/bin/hg", line 57, in > from mercurial import dispatch >File "", line 1360, in _find_and_load >File "", line 1331, in _find_and_load_unlocked >File "", line 935, in _load_unlocked >File "/usr/lib/python3/dist-packages/hgdemandimport/demandimportpy3.py", > line 52, in exec_module > super().exec_module(module) >File "", line 257, in exec_module >File "", line 1360, in _find_and_load >File "", line 1331, in _find_and_load_unlocked >File "", line 935, in _load_unlocked >File "/usr/lib/python3/dist-packages/hgdemandimport/demandimportpy3.py", > line 52, in exec_module > super().exec_module(module) >File "", line 267, in exec_module > AttributeError: partially initialized module 'threading' has no attribute > 'RLock' (most likely due to a circular import) > ~$ > > Commenting out the hgdemandimport.enable() at line 55 of /usr/bin/hg, it > works: > > ~$ hg > Mercurial Distributed SCM [...] https://github.com/python/cpython/commit/81f575427edf497ee9d2dafe97986d3b9ed85ee5 seems like it might be the reason. Cheers, Julien
Bug#1076449: python3.12 threading breakage?
Control: reassign -1 python3.12 3.12.4-3 On Mon, Jul 22, 2024 at 13:32:28 +0200, Vincent Lefevre wrote: > On 2024-07-22 17:58:01 +0700, Sam wrote: > > So, I have now two machines where this bug happens, but on a third one > > (my notebook) there seems to be no problem, despite all of them showing > > 6.8-1 as the installed version (via `dpkg --list | grep mercurial`). > > > > Any recommendations how to make a differential-diagnosis between two > > systems? I think the only difference is that my notebook is a bit behind > > in regards to updates through apt. > > Look at the version of the python3.12 packages. The issue occurs > with 3.12.4-3, but not with 3.12.4-1. > > On my machines, downgrading all the packages of python3.12 source > from 3.12.4-3 to 3.12.4-1 made the issue disappear. > Reassigning. Cheers, Julien
Bug#1076081: mercurial-evolve: incompatible with mercurial 6.8
Package: mercurial-evolve Version: 11.1.3-1 Severity: grave Justification: renders package unusable Tags: upstream fixed-upstream X-Debbugs-Cc: jcris...@debian.org Hi, https://repo.mercurial-scm.org/evolve/rev/4657010685af fixes an incompatibility with hg 6.8. Cheers, Julien -- System Information: Debian Release: trixie/sid APT prefers testing-debug APT policy: (600, 'testing-debug'), (600, 'testing'), (500, 'unstable-debug'), (500, 'stable-updates'), (500, 'stable-security-debug'), (500, 'stable-security'), (500, 'buildd-unstable'), (500, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386, arm64 Kernel: Linux 6.7.12-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages mercurial-evolve depends on: ii libjs-sphinxdoc 7.3.7-3 ii mercurial6.8-1 ii python3 3.12.2-1 ii python3-cbor 1.0.0-1.2+b2 mercurial-evolve recommends no packages. mercurial-evolve suggests no packages.
Bug#1069407: mercurial: FTBFS on arm64: dh_auto_test: error: make -j4 check PYTHON=python3 "TESTFLAGS=--verbose --timeout 1800 --jobs 4 --blacklist /<>/debian/mercurial.test_blacklist" re
Control: forcemerge 1052811 1074678 1069407 On Sat, Apr 20, 2024 at 14:08:55 +0200, Lucas Nussbaum wrote: > Source: mercurial > Version: 6.7.2-1 > Severity: serious > Justification: FTBFS > Tags: trixie sid ftbfs > User: lu...@debian.org > Usertags: ftbfs-20240420 ftbfs-trixie ftbfs-t64-arm64 > > Hi, > > During a rebuild of all packages in sid, your package failed to build > on arm64. > > [...] > > --- /<>/tests/test-http-bad-server.t > > +++ /<>/tests/test-http-bad-server.t.err > > @@ -42,7 +42,7 @@ > >$ cat hg.pid > $DAEMON_PIDS > > > >$ hg clone http://localhost:$HGPORT/ clone > > - abort: error: (\$ECONNRESET\$|\$EADDRNOTAVAIL\$) (re) > > + abort: error: Connection refused > >[100] > > > > (The server exits on its own, but there is a race between that and > > starting a new server. > > > > ERROR: test-http-bad-server.t output changed On Tue, Jul 2, 2024 at 14:47:34 +0200, Lucas Nussbaum wrote: > Source: mercurial > Version: 6.7.4-1 > Severity: serious > Justification: FTBFS > Tags: trixie sid ftbfs > User: lu...@debian.org > Usertags: ftbfs-20240702 ftbfs-trixie > > Hi, > > During a rebuild of all packages in sid, your package failed to build > on amd64. > > > Relevant part (hopefully): [...] > > --- /<>/tests/test-http-bad-server.t > > +++ /<>/tests/test-http-bad-server.t.err > > @@ -42,7 +42,7 @@ > >$ cat hg.pid > $DAEMON_PIDS > > > >$ hg clone http://localhost:$HGPORT/ clone > > - abort: error: (\$ECONNRESET\$|\$EADDRNOTAVAIL\$) (re) > > + abort: error: Connection refused > >[100] > > > > (The server exits on its own, but there is a race between that and > > starting a new server. > > > > ERROR: test-http-bad-server.t output changed You filed this before; merging. Cheers, Julien
Bug#1075963: x11-xserver-utils: xsetmode, xsetpointer obsolete
Control: severity -1 minor On Mon, Jul 8, 2024 at 14:55:14 +0200, Chris Hofstaedtler wrote: > Source: x11-xserver-utils > Severity: important > > Hi, > > In https://www.openwall.com/lists/oss-security/2023/05/02/3 upstream > pointed out that xsetmode and xsetpointer are obsolete and do not > receive any fixes. > xsetpointer supposedly is broken since xorg-server 1.4. > > Please drop them from the package. > Is there a particular reason to make this bug important? Both are tiny utilities, basically making a single X request, so from my point of view while there's likely little to no usage there's also little cost to keeping them. Cheers, Julien
Bug#1069683: firefox-esr: clearkey gmp plugin crashes
On Mon, Apr 22, 2024 at 18:44:02 +0200, Julien Cristau wrote: > Package: firefox-esr > Version: 115.10.0esr-1~deb12u1 > Severity: normal > X-Debbugs-Cc: jcris...@debian.org > > It seems that the gmp code does not expect the executable to be called > something other than firefox: > > GMPChild::MakeCDMHostVerificationPaths > (https://searchfox.org/mozilla-esr115/source/dom/media/gmp/GMPChild.cpp#424) Wrong URL here, I meant to link to https://searchfox.org/mozilla-esr115/rev/d80a6646e597210be779f6cdbd8af0044e94312b/dom/media/gmp/GMPChild.cpp#424 > calls AppendHostPath with /usr/lib/firefox-esr/firefox, but that file > doesn't exist, so AppendHostPath fails, and we end up calling into > VerifyCdmHost_0 > (https://searchfox.org/mozilla-esr115/source/dom/media/gmp/GMPChild.cpp#422) And wrong URL there, this was meant to be https://searchfox.org/mozilla-esr115/rev/d80a6646e597210be779f6cdbd8af0044e94312b/media/gmp-clearkey/0.1/gmp-clearkey.cpp#152 > with aNumFiles==2, which fails the assertion that it's equal to > NumExpectedHostFiles (4). >
Bug#1069683: firefox-esr: clearkey gmp plugin crashes
Package: firefox-esr Version: 115.10.0esr-1~deb12u1 Severity: normal X-Debbugs-Cc: jcris...@debian.org It seems that the gmp code does not expect the executable to be called something other than firefox: GMPChild::MakeCDMHostVerificationPaths (https://searchfox.org/mozilla-esr115/source/dom/media/gmp/GMPChild.cpp#424) calls AppendHostPath with /usr/lib/firefox-esr/firefox, but that file doesn't exist, so AppendHostPath fails, and we end up calling into VerifyCdmHost_0 (https://searchfox.org/mozilla-esr115/source/dom/media/gmp/GMPChild.cpp#422) with aNumFiles==2, which fails the assertion that it's equal to NumExpectedHostFiles (4). Cheers, Julien -- Package-specific info: -- Addons package information -- System Information: Debian Release: trixie/sid APT prefers testing-debug APT policy: (600, 'testing-debug'), (600, 'testing'), (500, 'unstable-debug'), (500, 'stable-updates'), (500, 'stable-security-debug'), (500, 'stable-security'), (500, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386, arm64 Kernel: Linux 6.6.15-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages firefox-esr depends on: ii debianutils 5.17 ii fontconfig 2.15.0-1.1 ii libasound2 1.2.10-3 ii libatk1.0-0 2.50.0-1+b1 ii libc62.37-15 ii libcairo-gobject21.18.0-1+b1 ii libcairo21.18.0-1+b1 ii libdbus-1-3 1.14.10-4 ii libdbus-glib-1-2 0.112-3+b1 ii libevent-2.1-7 2.1.12-stable-8 ii libffi8 3.4.6-1 ii libfontconfig1 2.15.0-1.1 ii libfreetype6 2.13.2+dfsg-1+b1 ii libgcc-s114-20240201-3 ii libgdk-pixbuf-2.0-0 2.42.10+dfsg-3+b1 ii libglib2.0-0 2.78.4-1 ii libgtk-3-0 3.24.41-1 ii libnspr4 2:4.35-1.1+b1 ii libnss3 2:3.99-1 ii libpango-1.0-0 1.52.0+ds-1 ii libstdc++6 14-20240201-3 ii libvpx7 1.12.0-1.2 ii libx11-6 2:1.8.7-1 ii libx11-xcb1 2:1.8.7-1 ii libxcb-shm0 1.15-1 ii libxcb1 1.15-1 ii libxcomposite1 1:0.4.5-1 ii libxdamage1 1:1.1.6-1 ii libxext6 2:1.3.4-1+b1 ii libxfixes3 1:6.0.0-2 ii libxrandr2 2:1.5.4-1 ii libxtst6 2:1.2.3-1.1 ii procps 2:4.0.4-4 ii zlib1g 1:1.3.dfsg-3+b1 Versions of packages firefox-esr recommends: ii libavcodec58 7:4.4.2-1+b3 ii libavcodec60 7:6.1.1-1 Versions of packages firefox-esr suggests: pn fonts-lmodern pn fonts-stix | otf-stix ii libcanberra0 0.30-11 ii libgssapi-krb5-2 1.20.1-5+b1 pn pulseaudio -- debconf-show failed
Bug#1068470: xorg-server: double free in fix for CVE-2024-31083
Source: xorg-server Version: 2:21.1.11-3 Severity: grave Tags: security upstream patch Justification: user security hole X-Debbugs-Cc: jcris...@debian.org, Debian Security Team The latest security fixes introduced a regression, apparently replacing use-after-free with double-free in some circumstances: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1659 https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1476 Cheers, Julien
Bug#1060795: severity of 1060795 is grave
severity 1060795 grave thanks Not sure how this was allowed to get into testing, but surely this qualifies as RC... Cheers, Julien
Bug#1067487: mercurial-evolve: update for mercurial 6.7
Source: mercurial-evolve Version: 10.5.3-4 Tags: sid trixie X-Debbugs-Cc: jcris...@debian.org Mercurial 6.7 breaks at least the topic extension (https://repo.mercurial-scm.org/evolve/rev/3635782b0290); not sure about evolve. Cheers, Julien
Bug#1063502: snapshot.debian.org: 'Archive-update-in-Progress' since Feb 6
Control: tag -1 moreinfo On Fri, Feb 9, 2024 at 10:33:55 +1100, Peter Chubb wrote: > Package: snapshot.debian.org > Severity: normal > > Dear Maintainer, > http://snapshot.debian.org/archive/debian/20240206T163351Z/ > does not have a Release file, and has a file called > Archive-Update-in-Progress-sallinen.debian.org > that was last updated on 2024-02-06 16:33:51 > > This makes that snapshot unusable. How so? What you described sounds like the expected state to me. Release files aren't at the root, they're under dists/*/, and the AUIP file is there because the snapshot import runs as part of the "archive update" on that host. Cheers, Julien
Bug#1060922: Status of debian-ports
On Tue, Jan 16, 2024 at 18:25:10 +0100, Christoph Biedl wrote: > Looking at > > https://snapshot.debian.org/archive/debian-ports/ > > it seems debian-ports was not updated for almost half a year now. If > that was just an error, please fix it. If it was discontinued by > intention, please place according notices - or better, re-consider your > decision: For release architectures, there's at least archive.d.o to > access some older versions of packages, although in a two-year interval > only. For the ports, there's plain nothing. > The snapshot infrastructure currently can't cope with -ports imports, as they take longer than the interval between pushes, for reasons. We'll turn it back on when we can. Cheers, Julien
Bug#1063093: ca-certificates: expired certificate: Security_Communication_Root_CA.crt
Control: severity -1 minor On Mon, Feb 5, 2024 at 10:19:10 +0800, Paul Wise wrote: > I noticed that there is one expired certificate in ca-certificates: > > $ cat test > now=$(date -u) > date -d "$now" > now="$(date -d "$now" +%s)" > for f in /usr/share/ca-certificates/mozilla/* ; do > date="$(openssl x509 -enddate -noout -in "$f" | cut -d= -f2)" > d="$(date -d "$date" +%s)" > if [ $((d<=now)) -eq 1 ] ; then > echo Expired: $f $date $d $now > fi > done > $ sh test > Mon 05 Feb 2024 10:13:46 AWST > Expired: > /usr/share/ca-certificates/mozilla/Security_Communication_Root_CA.crt Sep 30 > 04:20:49 2023 GMT 1696047649 1707099226 > > It might be a good idea to add an autopkgtest to check them. > It doesn't actually matter, though, and it'll be gone next time we pull from mozilla. Cheers, Julien
Bug#1058670: python3-poetry: fail with Can't instantiate abstract class IsolatedEnv with abstract methods executable, scripts_dir
Control: severity -1 serious On Sat, Dec 23, 2023 at 15:54:25 +0100, Tomas Janousek wrote: > Control: severity 1058670 important > Control: forwarded 1058670 https://github.com/python-poetry/poetry/issues/8803 > > Hi, > > On Thu, Dec 14, 2023 at 12:14:12PM +0200, George Shuklin wrote: > > According to github bug: > > https://github.com/python-poetry/poetry/issues/8458 it > > is caused by conflict (interactions?) with python3-build package. > > > > python3-build 0.10.0-1 > > Indeed, as https://github.com/python-poetry/poetry/issues/8803 explains, > poetry 1.7.1 needs python3-build ^= 1.0.3 [1], yet the Debian python3-poetry > package just depends on python3-build without any version constraints and > python3-build is still at 0.10.0-1 in Debian unstable. > > Additionally, python3-poetry version 1.6.1+dfsg-2 also has an unbounded > dependency on python3-build despite its > /usr/lib/python3/dist-packages/poetry-1.6.1.dist-info/METADATA clearly > specifying the dependency as "Requires-Dist: build (>=0.10.0,<0.11.0)". > Broken dependencies is a serious bug. Upgrading severity again. Emmanuel, do you have any plan to update python3-build and fix poetry's dependencies? Cheers, Julien
Bug#1060849: mesa: FTBFS on armel: static assertion failed: "vn_ring_shared requires lock-free 32-bit atomic_uint"
On Tue, Jan 16, 2024 at 11:02:25 +0100, Julien Cristau wrote: > On Mon, Jan 15, 2024 at 16:14:17 +, Simon McVittie wrote: > > > The armel baseline does not have lock-free atomic operation opcodes. The > > result is a build failure: > > > > https://buildd.debian.org/status/fetch.php?pkg=mesa&arch=armel&ver=23.3.3-1&stamp=1705055313&raw=0 > > > In file included from ../src/util/u_math.h:43, > > > from ../src/virtio/vulkan/vn_common.h:35, > > > from ../src/virtio/vulkan/vn_buffer.h:14, > > > from ../src/virtio/vulkan/vn_buffer.c:11: > > > ../src/virtio/vulkan/vn_ring.h:40:1: error: static assertion failed: > > > "vn_ring_shared requires lock-free 32-bit atomic_uint" > > >40 | static_assert(ATOMIC_INT_LOCK_FREE == 2 && sizeof(atomic_uint) == > > > 4, > > > > Could this perhaps be solved by disabling the virtio driver on armel? > > > Looks like that already happened in > https://salsa.debian.org/xorg-team/lib/mesa/-/commit/71deba800f28059724dd7899b8901e86c0eb2365 > a few months ago, looks like it regressed. > Right, https://salsa.debian.org/xorg-team/lib/mesa/-/commit/9e99f52bf2c9c8f2993cc2a6bec1e13b70fd10b8 seems to have dropped the armel special-case there. Cheers, Julien
Bug#1060849: mesa: FTBFS on armel: static assertion failed: "vn_ring_shared requires lock-free 32-bit atomic_uint"
On Mon, Jan 15, 2024 at 16:14:17 +, Simon McVittie wrote: > The armel baseline does not have lock-free atomic operation opcodes. The > result is a build failure: > > https://buildd.debian.org/status/fetch.php?pkg=mesa&arch=armel&ver=23.3.3-1&stamp=1705055313&raw=0 > > In file included from ../src/util/u_math.h:43, > > from ../src/virtio/vulkan/vn_common.h:35, > > from ../src/virtio/vulkan/vn_buffer.h:14, > > from ../src/virtio/vulkan/vn_buffer.c:11: > > ../src/virtio/vulkan/vn_ring.h:40:1: error: static assertion failed: > > "vn_ring_shared requires lock-free 32-bit atomic_uint" > >40 | static_assert(ATOMIC_INT_LOCK_FREE == 2 && sizeof(atomic_uint) == 4, > > Could this perhaps be solved by disabling the virtio driver on armel? > Looks like that already happened in https://salsa.debian.org/xorg-team/lib/mesa/-/commit/71deba800f28059724dd7899b8901e86c0eb2365 a few months ago, looks like it regressed. Cheers, Julien
Bug#1007343: python-hglib: please consider upgrading to 3.0 source format
Control: tag -1 wontfix On Tue, Mar 15, 2022 at 08:52:04 +0100, Lucas Nussbaum wrote: > Source: python-hglib > Version: 2.6.2-1 > Severity: wishlist > Tags: bookworm sid > Usertags: format1.0 format1.0-nkp-nv > > Dear maintainer, > > This package is among the few (1.9%) that still use source format 1.0 in > bookworm. Please upgrade it to source format 3.0, as (1) this format has many > advantages, as documented in https://wiki.debian.org/Projects/DebSrc3.0 ; (2) > this contributes to standardization of packaging practices. > > Please note that this is also a sign that the packaging of this software > could maybe benefit from a refresh. It might be a good opportunity to > look at other aspects as well. > > It was noticed in https://lists.debian.org/debian-devel/2022/03/msg00096.html > that the conversion for this package is likely trivial, and builds bit-by-bit > identical binary packages. > In my opinions the downside of 3.0 (quilt) outweigh the advantages so do not expect I'll switch to it. Cheers, Julien
Bug#1058041: ncurses: breaks `hg histedit` (_curses.error: endwin() returned ERR)
Hi Sven, On Mon, Dec 11, 2023 at 21:12:35 +0100, Sven Joachim wrote: > On 2023-12-11 17:47 +0100, Sven Joachim wrote: > > > On 2023-12-11 16:22 +0100, Julien Cristau wrote: > >>> _curses.error: endwin() returned ERR > > > > I am not familiar with Mercurial, but most likely this has been > > triggered by the following change in the 2023111 patchlevel: > > > > , > > | 2023 > > | + modify endwin() to return an error if it is called again without an > > | intervening screen update (report by Rajeev Pillai, NetBSD #57592). > > ` > > I now had a look at the histedit code, and it does this: > > , > | with util.with_lc_ctype(): > | rc = curses.wrapper(functools.partial(_chisteditmain, repo, > rules)) > | curses.echo() > | curses.endwin() > ` > > AFAICS, invoking curses.echo() and curses.endwin() is superfluous > because curses.wrapper already does that for you, and calling > curses.endwin() twice throws an error with the newer ncurses. Removing > those two lines should fix the problem. > Thanks a lot for taking a look, and for the hint! I can confirm this appears to work; I've reported the issue to mercurial upstream (https://bz.mercurial-scm.org/show_bug.cgi?id=6859) and opened a MR (https://foss.heptapod.net/mercurial/mercurial-devel/-/merge_requests/730). Cheers, Julien
Bug#1058041: ncurses: breaks `hg histedit` (_curses.error: endwin() returned ERR)
Source: ncurses Version: 6.4+20231121-1 Severity: important Control: affects -1 mercurial X-Debbugs-Cc: jcris...@debian.org Hi, Since a ncurses upgrade in testing recently `hg histedit` seems to crash consistently, upon trying to apply the changes: > Traceback (most recent call last): > File "/usr/bin/hg", line 59, in > dispatch.run() > File "/usr/lib/python3/dist-packages/mercurial/dispatch.py", line 142, in > run > status = dispatch(req) > ^ > File "/usr/lib/python3/dist-packages/mercurial/dispatch.py", line 231, in > dispatch > status = _rundispatch(req) > ^ > File "/usr/lib/python3/dist-packages/mercurial/dispatch.py", line 275, in > _rundispatch > ret = _runcatch(req) or 0 > ^^ > File "/usr/lib/python3/dist-packages/mercurial/dispatch.py", line 456, in > _runcatch > return _callcatch(ui, _runcatchfunc) >^ > File "/usr/lib/python3/dist-packages/mercurial/dispatch.py", line 466, in > _callcatch > return scmutil.callcatch(ui, func) >^^^ > File "/usr/lib/python3/dist-packages/mercurial/scmutil.py", line 152, in > callcatch > return func() >^^ > File "/usr/lib/python3/dist-packages/mercurial/dispatch.py", line 446, in > _runcatchfunc > return _dispatch(req) >^^ > File "/usr/lib/python3/dist-packages/mercurial/dispatch.py", line 1271, in > _dispatch > return runcommand( >^^^ > File "/usr/lib/python3/dist-packages/mercurial/dispatch.py", line 904, in > runcommand > ret = _runcommand(ui, options, cmd, d) > > File "/usr/lib/python3/dist-packages/mercurial/dispatch.py", line 1283, in > _runcommand > return cmdfunc() >^ > File "/usr/lib/python3/dist-packages/mercurial/dispatch.py", line 1269, in > > d = lambda: util.checksignature(func)(ui, *args, **strcmdopt) > ^ > File "/usr/lib/python3/dist-packages/mercurial/util.py", line 1878, in check > return func(*args, **kwargs) >^ > File "/usr/lib/python3/dist-packages/hgext/histedit.py", line 1918, in > histedit > return _chistedit(ui, repo, freeargs, opts) > > File "/usr/lib/python3/dist-packages/hgext/histedit.py", line 1764, in > _chistedit > curses.endwin() > _curses.error: endwin() returned ERR Downgrading to the bookworm version (6.4-4) fixes it. Cheers, Julien
Bug#1035587: linux: broken AHCI controller on MIPS Loongson 3 (regression from 5.10.162-1)
Hi, On Mon, Oct 9, 2023 at 09:08:31 +0100, Jiaxun Yang wrote: > > > 在2023年10月8日十月 上午11:11，Aurelien Jarno写道： > > On 2023-07-19 16:28, Jiaxun Yang wrote: > >> > >> > >> 在 2023/7/8 18:11, Aurelien Jarno 写道: > >> [...] > >> > Any news about that? We need to be able to run the latest stable kernel > >> > on the build daemon. > >> > >> Hi all, > >> > >> After receiving more reports on that patch I think we shoud workaround it > >> in > >> Kernel. > >> > >> I had posted a patch to kernel, kernel bug tracker [1]. > >> > >> [1]: https://bugzilla.kernel.org/show_bug.cgi?id=217680 > > > > Any news about that? I haven't spotted any fix for this in Linus' tree > > nor in next. > > Still waiting for a response from PCI folks. > Will resend the patch later. > Any news on this? It's been several months... Thanks, Julien
Bug#1053751: d-i.debian.org: security repo being set up with HTTP even if HTTPS is selected
Control: reassign -1 apt-setup Control: forcemerge 860467 -1 On Tue, Oct 10, 2023 at 14:11:19 +0300, Viktor Voloshko wrote: > debian-installer has a choice between HTTP/HTTPS/FTP while setting up package > manager in expert install mode. > > If HTTPS is chosen and security repository enabled it will be added to > /etc/apt/sources.list with http:// as it's protocol instead of https:// (may > be same with FTP too, I didn't have a chance to check it). > > Every other mirror was added with https:// as expected. This includes > bookworm, bookworm-updates and bookworm-backports. > > This can be easily fixed later in installed system by editing > /etc/apt/sources.list without any consequences. > > Thank you for attention. > Hi, As far as I can tell this was already reported in bug #860467. Cheers, Julien
Bug#1053500: quilt: dh_quilt_unpatch broken in the absence of a series file
Source: quilt Version: 0.67+really0.67-2 Severity: grave X-Debbugs-Cc: jcris...@debian.org, s...@debian.org Hi, As explained by Sune in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1053444#17, reverting the change from the previous upload in dh_quilt_unpatch is insufficient, as it brings back bug #1030781, where the absence of a series file causes dh_quilt_unpatch to error out instead of happily not doing anything. Cheers, Julien
Bug#1053444: severity of 1053444 is grave
severity 1053444 grave thanks See e.g. https://buildd.debian.org/status/fetch.php?pkg=libx11&arch=all&ver=2%3A1.8.7-1&stamp=1696420352&raw=0 quilt pop exits 2 if it has nothing to do (https://sources.debian.org/src/quilt/0.67%2Breally0.67-1/quilt/pop.in/#L246), so that should be expected and not an error for dh_quilt_unpatch.
Bug#1053178: hg-git: incompatible with mercurial 6.5
Source: hg-git Version: 1.0.2-1 Severity: grave X-Debbugs-Cc: jcris...@debian.org Hi, hg-git looks like it needs an update for compatibility with current mercurial, see e.g. https://ci.debian.net/data/autopkgtest/testing/amd64/h/hg-git/38210693/log.gz > ** Unknown exception encountered with possibly-broken third-party extension > "hggit" unknown (dulwich 0.21.6) > ** which supports versions 6.4 of Mercurial. > ** Please disable "hggit" and try your action again. > ** If that fixes the bug please report it to > https://foss.heptapod.net/mercurial/hg-git/issues > ** Python 3.11.5 (main, Aug 29 2023, 15:31:31) [GCC 13.2.0] > ** Mercurial Distributed SCM (version 6.5.2) > ** Extensions loaded: hggit unknown (dulwich 0.21.6) > Traceback (most recent call last): > File "/usr/bin/hg", line 59, in > dispatch.run() > File "/usr/lib/python3/dist-packages/mercurial/dispatch.py", line 143, in > run > status = dispatch(req) > ^ > File "/usr/lib/python3/dist-packages/mercurial/dispatch.py", line 232, in > dispatch > status = _rundispatch(req) > ^ > File "/usr/lib/python3/dist-packages/mercurial/dispatch.py", line 276, in > _rundispatch > ret = _runcatch(req) or 0 > ^^ > File "/usr/lib/python3/dist-packages/mercurial/dispatch.py", line 457, in > _runcatch > return _callcatch(ui, _runcatchfunc) >^ > File "/usr/lib/python3/dist-packages/mercurial/dispatch.py", line 467, in > _callcatch > return scmutil.callcatch(ui, func) >^^^ > File "/usr/lib/python3/dist-packages/mercurial/scmutil.py", line 153, in > callcatch > return func() >^^ > File "/usr/lib/python3/dist-packages/mercurial/dispatch.py", line 447, in > _runcatchfunc > return _dispatch(req) >^^ > File "/usr/lib/python3/dist-packages/mercurial/dispatch.py", line 1272, in > _dispatch > return runcommand( >^^^ > File "/usr/lib/python3/dist-packages/mercurial/dispatch.py", line 905, in > runcommand > ret = _runcommand(ui, options, cmd, d) > > File "/usr/lib/python3/dist-packages/mercurial/dispatch.py", line 1284, in > _runcommand > return cmdfunc() >^ > File "/usr/lib/python3/dist-packages/mercurial/dispatch.py", line 1270, in > > d = lambda: util.checksignature(func)(ui, *args, **strcmdopt) > ^ > File "/usr/lib/python3/dist-packages/mercurial/util.py", line 1881, in check > return func(*args, **kwargs) >^ > File "/usr/lib/python3/dist-packages/mercurial/commands.py", line 1992, in > clone > r = hg.clone( > ^ > File "/usr/lib/python3/dist-packages/hggit/schemes.py", line 121, in clone > srcpeer, destpeer = orig(*args, **opts) > ^^^ > File "/usr/lib/python3/dist-packages/mercurial/hg.py", line 727, in clone > srcpeer = peer(ui, peeropts, src_path) > > File "/usr/lib/python3/dist-packages/hggit/schemes.py", line 112, in peer > newpeer = orig(uiorrepo, *args, **opts) > ^ > File "/usr/lib/python3/dist-packages/mercurial/hg.py", line 286, in peer > peer = repo.peer(path=peer_path, remotehidden=remotehidden) > > TypeError: gitrepo.peer() got an unexpected keyword argument 'remotehidden' Cheers, Julien
Bug#837060: debootstrap: Do not install packages of Priority:required for buildd variant
On Thu, Sep 28, 2023 at 12:42:27PM +0200, Santiago Vila wrote: > El 28/9/23 a las 11:50, Julien Cristau escribió: > > I still think that is absolutely the wrong thing to do, and makes > > debootstrap more fragile for no good reason. > > Julien, I believe you are mixing two different things here. > > (A) What this bug is really about. > > (B) What the effect of the bug is. > > The bug (A) is that debootstrap, being the tool used to create chroots > to build packages, has the responsibility of ensuring that > the chroot is composed by build-essential packages only, and it > should try hard not to install packages which are not build-essential. > I guess more than mixing two different things I disagree that that is debootstrap's responsibility, and so I disagree that that is a valid bug. In my view it's more important for debootstrap to reliably be able to create chroots than some sort of philosophical purity about what is included in said chroot. Package priorities are how the archive tells debootstrap which packages to install, and so since I don't see your (A) as a bug, I'm saying if there's a bug it's (B) and belongs with the archive. I also think your argument, even if I went along with it, breaks down when the apt package gets included, since apt is clearly not build-essential, so by that logic we'd go back to the days where builds used the host system's apt instead of including it in the chroot. > In other words, the bug says that the algorithm followed by debootstrap > to determine which packages should be installed is *flawed*. > > Then there is the effect of the bug (B). The effect, obviously, > is that we end up having non-build-essential packages in a chroot > when using the buildd profile, which is definitely not ok. > > Why do you suggest that we fix only the effects of the bug but not > the bug itself? In other words: Why are you apparently mixing (A) and (B) > as if they were the same thing? > > True, the ftpmasters might change priorities so that debootstrap > does the right thing by default, but this would be "by pure chance", > as the algorithm would still be wrong. > > Even if they change the priorities today, it would suffice that > some day another essential package becomes non-essential but still required, > and then we would have to wait another seven years for debootstrap > to do the right thing again. > There's no reason that would need to take seven years, so I don't know what that point is about. Cheers, Julien
Bug#837060: debootstrap: Do not install packages of Priority:required for buildd variant
Hi, I still think that is absolutely the wrong thing to do, and makes debootstrap more fragile for no good reason. If you think a particular package shouldn't be priority:required then file a bug against ftp.debian.org to change it. Cheers, Julien On Sat, Sep 23, 2023 at 20:13:45 +0200, Johannes Schauer Marin Rodrigues wrote: > Hi all, > > On Sun, 25 Jun 2017 06:01:13 +0200 Johannes Schauer wrote: > > Quoting Cyril Brulebois (2017-06-24 20:23:25) > > > Julien Cristau (2016-09-12): > > > > This is a transient situation because some Essential packages' > > > > dependencies changed. I'd consider this a bug in the archive, not in > > > > debootstrap. > > > Any reasons to keep this bug report open then? Seen no objections, so I'm > > > tempted to close it. > > > > But... the buildd variant still explicitly (and not only implicitly through > > dependencies of essential:yes packages) installs Priority:required packages, > > no? > > as we are at the beginning of the trixie development cycle, I have opened a > merge request against debootstrap which avoids installing priority:required > packages with the buildd variant: > > https://salsa.debian.org/installer-team/debootstrap/-/merge_requests/106#note_430035 > > I've put Ansgar and Julien in CC as they were opposed to this change. > > I'm putting Luca and Guillem in CC who wrote in favour of this change also in > policy bug #1029831. > > Santiago is in CC as the driver of the mass bug filing for source packages > that > fail to build in a chroot environment with just Essential:yes and > build-essential installed. > > According to the last MBF from December 2022 and January 2023, there are 13 > source packages that would FTBFS after this change because they are missing an > explicit build dependency on tzdata or mount. > > As part of the thread starting at > 9b40f6f2-4942-acfc-2f9c-4668f05d9...@debian.org a number of arguments were > made > for and against this change. I still believe that the arguments for this > change > weigh stronger than those against it and thus I filed that merge request > above. > > Luca, as the debootstrap maintainer, what are your thoughts? > > Thank you! > > cheers, josch
Bug#1052811: mercurial: FTBFS: dh_auto_test: error: make -j8 check PYTHON=python3 "TESTFLAGS=--verbose --timeout 1800 --jobs 8 --blacklist /<>/debian/mercurial.test_blacklist" returned ex
Control: severity -1 important Control: tag -1 upstream Control: retitle -1 mercurial: test-http-bad-server.t intermittent failure Sounds like a flaky or racy test, downgrading. On Tue, Sep 26, 2023 at 14:43:44 +0200, Lucas Nussbaum wrote: > > --- /<>/tests/test-http-bad-server.t > > +++ /<>/tests/test-http-bad-server.t.err > > @@ -42,7 +42,7 @@ > >$ cat hg.pid > $DAEMON_PIDS > > > >$ hg clone http://localhost:$HGPORT/ clone > > - abort: error: (\$ECONNRESET\$|\$EADDRNOTAVAIL\$) (re) > > + abort: error: Connection refused > >[100] > > > > (The server exits on its own, but there is a race between that and > > starting a new server. > > > > ERROR: test-http-bad-server.t output changed > > !# Ret was: 0 (test-http-bad-server.t)
Bug#1026455: mirror submission for mirrors.xtom.au
Control: reopen 1026455 Hi, This was an issue on my end yesterday, sorry. Cheers, Julien On Tue, Aug 01, 2023 at 11:35:37AM +, David Guo wrote: > Hello, > > > > I checked our DNS settings and the domain is working fine: > > > > https://ping.sx/ping?t=mirrors.xtom.au > > > > We have set DNSSEC for xtom.au, did you check your resolver settings for > DNSSEC? > > > > Regards, > > > > David > > > > From: Julien Cristau > Date: Tuesday, August 1, 2023 at 01:40 > To: xTom Mirrors , 1026455-d...@bugs.debian.org > <1026455-d...@bugs.debian.org> > Subject: Re: Bug#1026455: mirror submission for mirrors.xtom.au > > Hi, > > mirrors.xtom.au does not resolve. Closing. > > Cheers, > Julien > > On Tue, Dec 20, 2022 at 02:15:48PM +, xTom wrote: > > Package: mirrors > > Severity: wishlist > > User: mirr...@packages.debian.org > > Usertags: mirror-submission > > > > Submission-Type: new > > Site: mirrors.xtom.au > > Type: leaf > > Archive-architecture: ALL amd64 arm64 armel armhf hurd-i386 i386 > kfreebsd-amd64 kfreebsd-i386 mips mips64el mipsel powerpc ppc64el s390x > > Archive-http: /debian/ > > Archive-rsync: debian/ > > Maintainer: xTom > > Country: AU Australia > > Location: Sydney > > Sponsor: xTom https://xtom.com/ > > > > > > > > > > Trace Url: http://mirrors.xtom.au/debian/project/trace/ > > Trace Url: http://mirrors.xtom.au/debian/project/trace/ftp-master.debian.org > > Trace Url: http://mirrors.xtom.au/debian/project/trace/mirrors.xtom.au >
Bug#1040897: successor to trumpetti.atm.tut.fi
Hi Aleksi, FTP Admins can probably set you up with push triggers. Otherwise, the latest ftpsync versions come with a wrapper script called ftpsync-cron, which is intended to be run out of cron every hour or so (at a randomish offset). The script monitors your upstream mirror, and if there was an update triggers a full sync using ftpsync. You might want to give it a try. Regarding HTTPS, feel free to set it up for non-debian.org names, that's generally a good idea. Thanks, Julien On Mon, Jul 17, 2023 at 01:31:53PM +0300, Debian Mirror at TREX wrote: > Hi, > > The Tampere University of Technology hosted ftp.fi.debian.org for a long > time. I was also involved with it, but close to a decade ago the university > decided to discontinue the service. I've been looking for somewhere to host > its replacement, and this debian.web.trex.fi is finally it. > > In other words, once the mirror is accepted, I'd like to ask you to point > ftp.fi.debian.org at it. I've already configured the name as a ServerAlias. > > Right now I'm running ftpsync every four hours, which I realise is > suboptimal. Who do I contact for push trigger config? Someone at > mirror.accum.se aka ftp.acc.umu.se? > > What is the current HTTPS policy? Should I configure certbot to fetch Let's > Encrypt certificates for the mirror's vhosts? > > Best Regards, > > -- > +358 44 9756548 / http://www.trex.fi/ > Aleksi Suhonen / TREX Regional Exchanges Oy > > You say "potato", I say "closest-exit."
Bug#1028953: mirror submission for deb.holownych.com
Control: tag -1 moreinfo On Sun, Jan 15, 2023 at 06:56:37AM +, Mike Holownych wrote: > Site: deb.holownych.com Hi, How does this compare with your other submission (#1034123, for debian.holownych.com)? Thanks, Julien
Bug#1011625: mercurial: autopkgtest regression on s390x
Control: retitle -1 mercurial: test-convert-svn-encoding.t fails on s390x On Sun, Mar 26, 2023 at 20:08:31 +0200, Paul Gevers wrote: > tags 1011625 serious > user release.debian@packages.debian.org > usertag 1011625 bookworm-can-defer > retitle 1011625 mercurial: autopkgtest regression > thanks > > Hi, > > On Wed, 25 May 2022 15:03:58 +0200 Graham Inggs wrote: > > Sometime between 2021-10-16 and 2021-11-25 [1], mercurial's > > autopkgtests regressed on s390x in testing. > > It now regressed everywhere. > Please don't mix unrelated issues in the same bug. Retitling back to focus on the s390x convert-svn-encoding issue. If there's something else on other architectures then they need their own report. Cheers, Julien
Bug#1040108: mercurial: deprecation of Python libraries asyncore and asynchat
Control: tag 1040108 upstream Control: tag 1040121 upstream Control: forwarded 1040108 https://bz.mercurial-scm.org/show_bug.cgi?id=6700 Control: forwarded 1040121 https://bz.mercurial-scm.org/show_bug.cgi?id=6727 On Sat, Jul 1, 2023 at 21:44:30 -0400, Louis-Philippe Véronneau wrote: > In Python 3.6, asyncore and asynchat have been formally marked as > deprecated. Code that imports these libraries will no longer work from > Python 3.12, which is currently in Trixie. > On Sat, Jul 1, 2023 at 22:03:40 -0400, Louis-Philippe Véronneau wrote: > In Python 3.5.4, smtpd has been formally marked as deprecated. Code that > imports this library will no longer work from Python 3.12, which is > currently in Trixie. > > Since mercurial use this Python library, please prepare for this removal and > migrate away from them. > Basically these boil down to tests/dummysmtpd.py needing to be rewritten. Unless/until that happens we'll have to skip test-patchbomb-tls.t. Cheers, Julien
Bug#1036543: linux: WARNING at drivers/crypto/ccp/sev-dev.c:168 __sev_do_cmd_locked+0x31b/0x350 [ccp]
Source: linux Version: 5.10.179-1 Severity: normal Tags: upstream Control: found -1 5.10.178-3 User: debian-ad...@lists.debian.org Usertags: needed-by-DSA-Team X-Debbugs-Cc: debian-ad...@lists.debian.org, jcris...@debian.org Hi, We're seeing a new WARNING in kernel logs on several Lenovo servers since the latest bullseye point release, when the ccp module gets loaded: > ccp :44:00.1: no command queues available > ccp :44:00.1: sev enabled > ccp :44:00.1: psp enabled > [ cut here ] > WARNING: CPU: 87 PID: 1534 at drivers/crypto/ccp/sev-dev.c:168 > __sev_do_cmd_locked+0x31b/0x350 [ccp] > Modules linked in: ccp(+) rng_core kvm irqbypass ip6t_REJECT nf_reject_ipv6 > ip6table_filter ip6_tables nfnetlink_log nfnetlink xt_hashlimit ipt_REJECT > nf_reject_ipv4 xt_NFLOG xt_multiport xt_tcpudp xt_state xt_conntrack > nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 iptable_filter loop tun sch_fq > tcp_bbr usbhid uas usb_storage sr_mod cdrom joydev hid_generic hid cdc_ether > usbnet mii drbd drm lru_cache fuse configfs efivarfs ip_tables x_tables > autofs4 ext4 crc16 mbcache jbd2 raid10 raid1 raid0 multipath linear dm_mod > raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor sd_mod > raid6_pq libcrc32c crc32c_generic crc32_pclmul crc32c_intel md_mod ahci > libahci xhci_pci xhci_hcd libata tg3 nvme usbcore nvme_core libphy t10_pi > bnxt_en scsi_mod crc_t10dif crct10dif_generic usb_common i2c_piix4 ptp > crct10dif_pclmul crct10dif_common pps_core > CPU: 87 PID: 1534 Comm: systemd-modules Not tainted 5.10.0-23-amd64 #1 Debian > 5.10.179-1 > Hardware name: Lenovo ThinkSystem SR635 -[7Y99CTO1WW]-/-[7Y99CTO1WW]-, BIOS > CFE126V 06/23/2021 > RIP: 0010:__sev_do_cmd_locked+0x31b/0x350 [ccp] > Code: 31 ed e9 a1 fd ff ff 48 8b 33 44 89 e9 48 c7 c2 f8 fb c4 c0 48 c7 c7 a0 > 2c c5 c0 e8 8f d9 28 de b8 fb ff ff ff e9 3b fe ff ff <0f> 0b b8 ea ff ff ff > e9 34 fe ff ff 44 89 fd e9 f4 fe ff ff b8 f0 > RSP: 0018:b75f82c0fcf8 EFLAGS: 00010246 > RAX: RBX: 90986ef00e98 RCX: > RDX: 0004d908 RSI: 09b2 RDI: b76002c0fd6c > RBP: c0c59000 R08: R09: b75f82c0fc90 > R10: 9098c49bb000 R11: a02153e0 R12: b75f82c0fd6c > R13: 0004 R14: b75f82c0fd68 R15: > FS: 7f3466446900() GS:90f60e5c() knlGS: > CS: 0010 DS: ES: CR0: 80050033 > CR2: 557be22d1c98 CR3: 000131af8000 CR4: 00350ee0 > Call Trace: > ? kobject_uevent_env+0x11f/0x6a0 > ? kfree+0xba/0x490 > ? 0xc0c59000 > sev_get_api_version+0x4a/0xa0 [ccp] > sev_pci_init+0x46/0x300 [ccp] > ? bus_add_driver+0x1a8/0x200 > ? 0xc0c59000 > sp_mod_init+0x18/0x1000 [ccp] > do_one_initcall+0x44/0x1e0 > ? do_init_module+0x23/0x250 > ? kmem_cache_alloc_trace+0xf5/0x200 > do_init_module+0x4c/0x250 > __do_sys_finit_module+0xb1/0x120 > do_syscall_64+0x33/0x80 > entry_SYSCALL_64_after_hwframe+0x61/0xc6 > RIP: 0033:0x7f3466d15f29 > Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 > 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 > 01 c3 48 8b 0d 37 8f 0d 00 f7 d8 64 89 01 48 > RSP: 002b:7ffcbd5be308 EFLAGS: 0246 ORIG_RAX: 0139 > RAX: ffda RBX: 557be22ca9c0 RCX: 7f3466d15f29 > RDX: RSI: 7f3466e09e2d RDI: 0008 > RBP: 0002 R08: R09: 557be22ca9c0 > R10: 0008 R11: 0246 R12: 7f3466e09e2d > R13: R14: 557be22ca970 R15: 557be22ca9c0 > ---[ end trace e089f2660ccf25dd ]--- > ccp :44:00.1: SEV: failed to get status. Error: 0x0 Ben forwarded the report to https://lore.kernel.org/stable/2023051729-jumbo-uncolored-05c1@gregkh/T/#mf89c978a24a0297b279e87de5fa19741f2c63980 after I mentioned it on IRC. Cheers, Julien
Bug#1032948: linux-image-6.1.0-5-amd64: oops in ucsi_acpi_notify
Control: tag -1 upstream fixed-upstream patch On Tue, Apr 4, 2023 at 22:03:28 +0200, Diederik de Haas wrote: > On Tuesday, 4 April 2023 13:11:16 CEST Julien Cristau wrote: > > On Mon, Apr 3, 2023 at 15:16:42 +0200, Diederik de Haas wrote: > > > On Saturday, 18 March 2023 23:10:39 CEST Diederik de Haas wrote: > > > > > > On Monday, 3 April 2023 14:57:02 CEST Julien Cristau wrote: > > > > > Not sure why patchwork still shows v2 of the patch as v4 is available > > > > > here: > > > > > https://lore.kernel.org/all/20230308154244.722337-1-hdego...@redhat.com/ > > > > > > > > I'll give the patch series you linked in the other reply a go now. > > > > > > FTR: 2 out of the 3 patches have landed in 6.1.22 > > > > Thanks for letting me know. I've built 6.1.22 from upstream and it > > doesn't seem to crash. > > That's awesome :-) Let's hope it stays that way now ;-) > > You may have seen it on IRC already, but could you test a > Debian 6.1.20-1 kernel with (only) those patches applied? > These are the URLs: > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-6.1.y&id=1c5abcb13491da8c049f20462189c12c753ba978 > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-6.1.y&id=1e8525f37871741a52370627633962f8bdcab15a > > If you need help with that, feel free to ask :-) > > If we know that fixes the issue too, then we have the option of going for > a 6.1.20-2 release with just those 2 patches (and what's already in -2 now). > Testing this now: linux (6.1.20-1a~test) UNRELEASED; urgency=medium * Testing patches ../0001-usb-ucsi-Fix-NULL-pointer-deref-in- ucsi_connector_ch.patch ../0001-usb-ucsi_acpi-Increase-the-command- completion-timeou.patch -- Julien Cristau Wed, 05 Apr 2023 11:09:30 + and it doesn't seem to crash, as far as I can tell. Cheers, Julien
Bug#1033944: sptag: build loops until the disk fills up
Source: sptag Version: 0.0~git20230323.0341c33+ds-1 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) X-Debbugs-Cc: jcris...@debian.org The latest sptag upload to experimental broke one of our buildds after its log took up 70G disk space. It goes like this, and then repeats that last line forever: > 1: [1] Setting MaxCheckForRefineGraph with value 8192 > 1: [1] Setting RNGFactor with value 1.00 > 1: [1] Setting GPUGraphType with value 2 > 1: [1] Setting GPURefineSteps with value 0 > 1: [1] Setting GPURefineDepth with value 30 > 1: [1] Setting GPULeafSize with value 500 > 1: [1] Setting HeadNumGPUs with value 1 > 1: [1] Setting TPTBalanceFactor with value 2 > 1: [1] Setting NumberOfThreads with value 2 > 1: [1] Setting DistCalcMethod with value L2 > 1: [1] Setting DeletePercentageForRefine with value 0.40 > 1: [1] Setting AddCountForRebuild with value 1000 > 1: [1] Setting MaxCheck with value 8192 > 1: [1] Setting ThresholdOfNumberOfContinuousNoBetterPropagation with value 3 > 1: [1] Setting NumberOfInitialDynamicPivots with value 50 > 1: [1] Setting NumberOfOtherDynamicPivots with value 4 > 1: [1] Setting HashTableExponent with value 2 > 1: [1] Setting DataBlockSize with value 1048576 > 1: [1] Setting DataCapacity with value 2147483647 > 1: [1] Setting MetaRecordSize with value 10 > 1: [1] Load Vector (205,100) Finish! > 1: [1] Load BKT (1,207) Finish! > 1: [1] Load RNG (205,32) Finish! > 1: [1] Load DeleteID (205,1) Finish! > 1: [1] Setting NumberOfThreads with value 2 > 1: [1] Setting MaxCheck with value 2048 > 1: [1] Setting HashTableExponent with value 4 > 1: [1] Finish reading header info, list count 205, total doc count 1000, > dimension 100, list page offset 1. > 1: [1] Big page (>4K): list count 126, total element count 2147. > 1: [1] Total Element Count: 2678 > 1: [1] Page Count Dist: 0 1 > 1: [1] Page Count Dist: 1 78 > 1: [1] Page Count Dist: 2 126 > 1: [1] select head time: 0.00s build head time: 0.00s build ssd time: 0.00s > 1: [1] Start generating truth. It's maybe a long time. > 1: [1] Load Vector(1000,100) > 1: [1] Load Vector(10,100) > 1: [1] Begin to generate truth for query(10,100) and doc(1000,100)... > 1: [1] Start to write truth file... > 1: [1] End generating truth. > 1: [1] Start loading warmup query set... > 1: [1] Load Vector(10,100) > 1: [1] Start warmup... > 1: [1] Searching: numThread: 2, numQueries: 10. > 1: [1] Sent 0.00%... > 1: [4] fid:0 channel 2, to submit:64, submitted:Operation not permitted > 1: [4] fid:0 channel 2, to submit:64, submitted:Operation not permitted > 1: [4] fid:0 channel 2, to submit:64, submitted:Operation not permitted > 1: [4] fid:0 channel 2, to submit:64, submitted:Operation not permitted > 1: [4] fid:0 channel 2, to submit:64, submitted:Operation not permitted > 1: [4] fid:0 channel 2, to submit:64, submitted:Operation not permitted > 1: [4] fid:0 channel 2, to submit:64, submitted:Operation not permitted > 1: [4] fid:0 channel 2, to submit:64, submitted:Operation not permitted > 1: [4] fid:0 channel 2, to submit:64, submitted:Operation not permitted > 1: [4] fid:0 channel 2, to submit:64, submitted:Operation not permitted > 1: [4] fid:0 channel 2, to submit:64, submitted:Operation not permitted > 1: [4] fid:0 channel 2, to submit:64, submitted:Operation not permitted > 1: [4] fid:0 channel 2, to submit:64, submitted:Operation not permitted > 1: [4] fid:0 channel 2, to submit:64, submitted:Operation not permitted Cheers, Julien
Bug#1032948: linux-image-6.1.0-5-amd64: oops in ucsi_acpi_notify
On Mon, Apr 3, 2023 at 15:16:42 +0200, Diederik de Haas wrote: > On Saturday, 18 March 2023 23:10:39 CEST Diederik de Haas wrote: > On Monday, 3 April 2023 14:57:02 CEST Julien Cristau wrote: > > > Not sure why patchwork still shows v2 of the patch as v4 is available > > > here: > > > https://lore.kernel.org/all/20230308154244.722337-1-hdego...@redhat.com/ > > I'll give the patch series you linked in the other reply a go now. > > FTR: 2 out of the 3 patches have landed in 6.1.22 Thanks for letting me know. I've built 6.1.22 from upstream and it doesn't seem to crash. Cheers, Julien
Bug#1032984:
On Sun, Mar 26, 2023 at 22:03:25 +0200, Stefan Schippers wrote: > I have closed upstream bug: > https://gitlab.freedesktop.org/xorg/lib/libx11/-/issues/186 > since i got no feedback at all and it seems affecting only the specific > libX11 1.8.4 - fvwm2 combination that very few people use, I think. > Expecting a response within a few days was probably unrealistic in the first place... Cheers, Julien
Bug#1032948: linux-image-6.1.0-5-amd64: oops in ucsi_acpi_notify
On Thu, Mar 16, 2023 at 20:39:51 +0100, Diederik de Haas wrote: > On Thursday, 16 March 2023 18:11:27 CET Julien Cristau wrote: > > > I rebooted on 6.1.15-1 last night and things are still looking good so > > > I'll call this fixed. Thanks. > > > > Spoke too soon: > > > [84564.498495] BUG: kernel NULL pointer dereference, address: > > > 0398 [84564.498502] #PF: supervisor write access in kernel > > > mode > > > [84564.498504] #PF: error_code(0x0002) - not-present page > > > [84564.498506] PGD 4c9444067 P4D 4c9444067 PUD 0 > > > [84564.498510] Oops: 0002 [#1] PREEMPT SMP NOPTI > > > [84564.498512] CPU: 0 PID: 140651 Comm: kworker/0:0 Not tainted > > > 6.1.0-6-amd64 #1 Debian 6.1.15-1 [84564.498516] Hardware name: LENOVO > > > 20XW00ABUS/20XW00ABUS, BIOS N32ET82W (1.58 ) 12/05/2022 [84564.498518] > > > Workqueue: kacpi_notify acpi_os_execute_deferred > > Bummer. > > Since 6.1.8 I found the following 2 commits in drivers/usb/typec/ucsi: > > 3d7f77e55da3455c8844b651e37779c90e201f48 titled > "usb: ucsi: Ensure connector delayed work items are flushed" > > fdd11d7136fd070b3a74d6d8799d9eac28a57fc5 titled > "usb: typec: ucsi: Don't attempt to resume the ports before they exist" > > Especially the first one looks 'promising'. > Can you make a patch which reverts that commit and use 'test-patches' from > https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html > to build a kernel and test that? Reverting "usb: ucsi: Ensure connector delayed work items are flushed" doesn't fix the crash, pretty much instant upon unplugging my monitor. I'll give the patch series you linked in the other reply a go now. Cheers, Julien > [ 34.956155] usb 3-6: USB disconnect, device number 4 > [ 34.956164] usb 3-6.1: USB disconnect, device number 6 > [ 34.956167] usb 3-6.1.4: USB disconnect, device number 8 > [ 34.995650] usb 2-3: USB disconnect, device number 2 > [ 34.995654] usb 2-3.1: USB disconnect, device number 3 > [ 34.995655] usb 2-3.1.2: USB disconnect, device number 4 > [ 34.995778] cdc_ncm 2-3.1.2:2.0 enxc84bd6b0b3e0: unregister 'cdc_ncm' > usb-:00:0d.0-3.1.2, CDC NCM (NO ZLP) > [ 35.449317] usb 3-6.5: USB disconnect, device number 7 > [ 35.843033] BUG: kernel NULL pointer dereference, address: 0388 > [ 35.843040] #PF: supervisor write access in kernel mode > [ 35.843041] #PF: error_code(0x0002) - not-present page > [ 35.843043] PGD 0 P4D 0 > [ 35.843046] Oops: 0002 [#1] PREEMPT SMP NOPTI > [ 35.843048] CPU: 0 PID: 2704 Comm: kworker/0:3 Tainted: GE > 6.1.0-7-amd64 #1 Debian 6.1.20-1a~test > [ 35.843051] Hardware name: LENOVO 20XW00ABUS/20XW00ABUS, BIOS N32ET82W > (1.58 ) 12/05/2022 > [ 35.843052] Workqueue: kacpi_notify acpi_os_execute_deferred > [ 35.843058] RIP: 0010:queue_work_on+0x15/0x40 > [ 35.843063] Code: ff ff ff e9 9a fe ff ff 66 66 2e 0f 1f 84 00 00 00 00 00 > 66 90 0f 1f 44 00 00 53 9c 58 0f 1f 40 00 48 89 c3 fa 0f 1f 44 00 00 48 > 0f ba 2a 00 73 15 31 c9 80 e7 02 74 06 fb 0f 1f 44 00 00 89 > [ 35.843065] RSP: 0018:b4a50467be38 EFLAGS: 00010002 > [ 35.843067] RAX: 0202 RBX: 0202 RCX: > > [ 35.843069] RDX: 0388 RSI: 8a0640051000 RDI: > 2000 > [ 35.843070] RBP: 0004 R08: 8a06fa490a38 R09: > 8a06fa490a20 > [ 35.843071] R10: 000f R11: b4a50467bc20 R12: > 8a0d7f639b00 > [ 35.843072] R13: R14: 8a06c642a9c0 R15: > 8a06bc057918 > [ 35.843074] FS: () GS:8a0d7f60() > knlGS: > [ 35.843075] CS: 0010 DS: ES: CR0: 80050033 > [ 35.843076] CR2: 0388 CR3: 00039d410004 CR4: > 00770ef0 > [ 35.843078] PKRU: 5554 > [ 35.843079] Call Trace: > [ 35.843082] > [ 35.843087] ucsi_acpi_notify+0xa8/0xc0 [ucsi_acpi] > [ 35.843092] acpi_ev_notify_dispatch+0x42/0x60 > [ 35.843096] acpi_os_execute_deferred+0x13/0x20 > [ 35.843099] process_one_work+0x1c4/0x380 > [ 35.843102] worker_thread+0x4d/0x380 > [ 35.843105] ? _raw_spin_lock_irqsave+0x23/0x50 > [ 35.843109] ? rescuer_thread+0x3a0/0x3a0 > [ 35.843111] kthread+0xe6/0x110 > [ 35.843114] ? kthread_complete_and_exit+0x20/0x20 > [ 35.843116] ret_from_fork+0x1f/0x30 > [ 35.843121] > [ 35.843122] Modules linked in: xt_conntrack(E) nft_chain_nat(E) > xt_MASQUERADE(E) nf_nat(E) nf_conntrack_netlink(E) nf_conntrack(E) > nf_defrag_ipv6(E) nf_defrag_ipv4(E) xfrm_user(E) xfrm_algo(
Bug#1033670: unblock: xwayland/2:22.1.9-1
Acked-by: Olivier Fourdan > (cherry picked from commit 511d1686a6ac3e3e0d66fb67b62620ba2a6575c8) > > hw/xwayland/xwayland-output.c | 16 > hw/xwayland/xwayland-output.h | 1 + > 2 files changed, 17 insertions(+) > > commit 7d039914ff5baf1ebd5dca1ddcb8d3a74ba3587e > Author: Minh Phan > Date: Tue Nov 29 19:35:13 2022 +0700 > > randr: introduce rrCrtcGetInfo DDX function > > This allows rrCrtcGetInfo to override the values in the XRRCrtcGetInfo > reply. One use case is to allow Xwayland to return the current emulated > mode for the specific client instead of the global mode. > > Signed-off-by: Minh Phan > Acked-by: Olivier Fourdan > (cherry picked from commit 5145742fb6e3d108b05db1521b51112e0dbfb95a) > > randr/randrstr.h | 8 > randr/rrcrtc.c | 3 +++ > 2 files changed, 11 insertions(+) > > commit cedf933c7cbbc0285e7f9ddb17706b9a8d84f6aa > Author: Doğukan Korkmaztürk > Date: Tue Nov 22 13:43:16 2022 -0500 > > GLX: Free the tag of the old context later > > In CommonMakeCurrent() function, the tag of the old context is freed > before the new context is made current. This is problematic because if > the CommonMakeNewCurrent() function fails, the tag of the old context > ends up being removed, even though it is still active. This causes > subsequent glXMakeCurrent() or glXMakeContextCurrent() requests to > generate a GLXBadContextTag error. > > This change moves the function call that frees the old tag to a location > where the result of CommonMakeNewCurrent() call is known and it is safe > to free it. > > Signed-off-by: Doğukan Korkmaztürk > (cherry picked from commit 4781f2a5a8c2c2b000374e2d87982a6701d5a6b3) > > glx/vndcmds.c | 7 +++ > 1 file changed, 3 insertions(+), 4 deletions(-) > > commit e982ca4420a6003c97cb076ee40172e904ce290a > Author: Doğukan Korkmaztürk > Date: Tue Nov 8 10:05:59 2022 -0500 > > xwayland/glx: Mirror all EGLConfigs > > Updated the for-loop that iterates over the received EGLConfigs to > include the very first EGLConfig with index 0. > > Signed-off-by: Doğukan Korkmaztürk > Fixes: 8469241592 - xwayland: Add EGL-backed GLX provider > (cherry picked from commit 3852b0d10a061348ea8214fbcbef3c5c08cac0b6) > > hw/xwayland/xwayland-glx.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > commit 4303ddfbf98023f33c1067007543df345c68b459 > Author: Corentin Noël > Date: Mon Aug 1 16:03:38 2022 +0200 > > glamor: Only check for llvmpipe renderer > > The virgl driver exposes the name of the host renderer which might be > llvmpipe. > In this case we still need glamor to be initialized. > > Only check if the renderer starts with llvmpipe (which is what llvmpipe > exposes). > > Signed-off-by: Corentin Noël > Reviewed-by: Adam Jackson > (cherry picked from commit fdebbc60d89cdc1b3353424b6568b25a61dcf372) > > glamor/glamor_egl.c | 2 +- > hw/xwayland/xwayland-glamor-gbm.c | 2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) > > commit bc288f59a4d6bf5e713f1473e42d9cdb20d879bf > Author: Lucas Stach > Date: Sun Jul 10 17:51:14 2022 +0200 > > xwayland: properly get FDs from multiplanar GBM BOs > > Multiplanar GBM buffers can point to different objects from each plane. > Use the _for_plane API when possible to retrieve the correct prime FD > for each plane. > > Signed-off-by: Lucas Stach > Reviewed-by: Simon Ser > Tested-by: Guido Günther > (cherry picked from commit 7d5ad2d372cc88648f6744c318a4bee18443689d) > > hw/xwayland/xwayland-glamor-gbm.c | 66 > +-- > 1 file changed, 57 insertions(+), 9 deletions(-) > > commit 57db30e637192df0600999cd40ec14edbeb1c68a > Author: Lucas Stach > Date: Thu Jul 28 22:44:59 2022 +0200 > > xwayland: handle fd export failure in glamor_egl_fds_from_pixmap > > Check the fd for validity before giving a success return code. > > Signed-off-by: Lucas Stach > Reviewed-by: Simon Ser > Tested-by: Guido Günther > (cherry picked from commit 951502e49797ab4c5db047e9df32c93d050d64af) > > hw/xwayland/xwayland-glamor-gbm.c | 7 +++ > 1 file changed, 7 insertions(+) unblock xwayland/2:22.1.9-1 diff -Nru xwayland-22.1.8/composite/compwindow.c xwayland-22.1.9/composite/compwindow.c --- xwayland-22.1.8/composite/compwindow.c 2023-02-07 08:30:43.0 +0100 +++ xwayland-22.1.9/composite/compwindow.c 2023-03-29 14:22:52.0 +0
Bug#1033668: unblock: xorg-server/2:21.1.7-2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock X-Debbugs-Cc: jcris...@debian.org Please unblock package xorg-server [ Reason ] CVE-2023-1393 [ Risks ] Simple patch to reset a pointer to freed memory. [ Checklist ] [x] all changes are documented in the d/changelog [x] I reviewed all changes and I approve them [x] attach debdiff against the package in testing unblock xorg-server/2:21.1.7-2 diff --git a/composite/compwindow.c b/composite/compwindow.c index 73a1871a0b..9a651636e3 100644 --- a/composite/compwindow.c +++ b/composite/compwindow.c @@ -620,6 +620,11 @@ compDestroyWindow(WindowPtr pWin) ret = (*pScreen->DestroyWindow) (pWin); cs->DestroyWindow = pScreen->DestroyWindow; pScreen->DestroyWindow = compDestroyWindow; + +/* Did we just destroy the overlay window? */ +if (pWin == cs->pOverlayWin) +cs->pOverlayWin = NULL; + /*compCheckTree (pWin->drawable.pScreen); can't check -- tree isn't good*/ return ret; } diff --git a/debian/changelog b/debian/changelog index 0949487831..f7e8a40cb5 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,10 @@ +xorg-server (2:21.1.7-2) unstable; urgency=high + + * composite: Fix use-after-free of the COW +ZDI-CAN-19866/CVE-2023-1393 + + -- Julien Cristau Wed, 29 Mar 2023 15:11:07 +0200 + xorg-server (2:21.1.7-1) unstable; urgency=medium * New upstream release
Bug#1032948: linux-image-6.1.0-5-amd64: oops in ucsi_acpi_notify
Control: reopen -1 Control: found it 6.1.15-1 On Thu, Mar 16, 2023 at 11:17:19 +0100, Julien Cristau wrote: > Version: 6.1.15-1 > > On Tue, Mar 14, 2023 at 15:29:08 +0100, Diederik de Haas wrote: > > > On Tuesday, 14 March 2023 14:55:04 CET Julien Cristau wrote: > > > Package: src:linux > > > Version: 6.1.12-1 > > > > > > After upgrading to 6.1.12-1 my laptop started hanging regularly (3 times > > > in a few hours). Downgraded to 6.1.8-1 and I've not seen this for a > > > week, so this looks like a recent regression. > > > > Testing now has 6.1.15-1, can you test it with that? > > There's another update in the pipeline (at least to 6.1.19) and when it > > becomes available, it would be useful if you could test that as well. > > I rebooted on 6.1.15-1 last night and things are still looking good so > I'll call this fixed. Thanks. > Spoke too soon: > [84564.498495] BUG: kernel NULL pointer dereference, address: 0398 > [84564.498502] #PF: supervisor write access in kernel mode > [84564.498504] #PF: error_code(0x0002) - not-present page > [84564.498506] PGD 4c9444067 P4D 4c9444067 PUD 0 > [84564.498510] Oops: 0002 [#1] PREEMPT SMP NOPTI > [84564.498512] CPU: 0 PID: 140651 Comm: kworker/0:0 Not tainted 6.1.0-6-amd64 > #1 Debian 6.1.15-1 > [84564.498516] Hardware name: LENOVO 20XW00ABUS/20XW00ABUS, BIOS N32ET82W > (1.58 ) 12/05/2022 > [84564.498518] Workqueue: kacpi_notify acpi_os_execute_deferred > [84564.498525] RIP: 0010:queue_work_on+0x15/0x40 > [84564.498529] Code: ff ff ff e9 9a fe ff ff 66 66 2e 0f 1f 84 00 00 00 00 00 > 66 90 0f 1f 44 00 00 53 9c 58 0f 1f 40 00 48 89 c3 fa 0f 1f 44 00 00 48 > 0f ba 2a 00 73 15 31 c9 80 e7 02 74 06 fb 0f 1f 44 00 00 89 > [84564.498531] RSP: 0018:b15ea96c3e38 EFLAGS: 00010002 > [84564.498533] RAX: 0202 RBX: 0202 RCX: > > [84564.498535] RDX: 0398 RSI: 93ea00051000 RDI: > 2000 > [84564.498536] RBP: 0004 R08: 93ea0383b510 R09: > > [84564.498537] R10: R11: 005f R12: > 93f13f639b00 > [84564.498538] R13: R14: 93ebffadba80 R15: > 93ebdd74a998 > [84564.498539] FS: () GS:93f13f60() > knlGS: > [84564.498540] CS: 0010 DS: ES: CR0: 80050033 > [84564.498541] CR2: 0398 CR3: 000503886004 CR4: > 00770ef0 > [84564.498543] PKRU: 5554 > [84564.498544] Call Trace: > [84564.498546] > [84564.498552] ucsi_acpi_notify+0xa8/0xc0 [ucsi_acpi] > [84564.498557] acpi_ev_notify_dispatch+0x42/0x5a > [84564.498560] acpi_os_execute_deferred+0x13/0x20 > [84564.498563] process_one_work+0x1c4/0x380 > [84564.498565] worker_thread+0x4d/0x380 > [84564.498568] ? _raw_spin_lock_irqsave+0x23/0x50 > [84564.498572] ? rescuer_thread+0x3a0/0x3a0 > [84564.498574] kthread+0xe6/0x110 > [84564.498577] ? kthread_complete_and_exit+0x20/0x20 > [84564.498580] ret_from_fork+0x1f/0x30 > [84564.498584] > [84564.498585] Modules linked in: tun xt_conntrack nft_chain_nat > xt_MASQUERADE nf_nat nf_conntrack_netlink nf_conntrack nf_defrag_ipv6 > nf_defrag_ipv4 xfrm_user xfrm_algo xt_addrtype nft_compat nf_tables libcrc32c > nfnetlink br_netfilter bridge stp llc ctr ccm rfcomm cmac algif_hash > algif_skcipher af_alg snd_seq_dummy snd_hrtimer snd_seq snd_seq_device qrtr > overlay ipmi_devintf bnep ipmi_msghandler binfmt_misc nls_ascii nls_cp437 > vfat fat snd_ctl_led snd_soc_skl_hda_dsp snd_soc_intel_hda_dsp_common > snd_soc_hdac_hdmi snd_sof_probes snd_hda_codec_hdmi snd_hda_codec_realtek > snd_hda_codec_generic snd_soc_dmic snd_sof_pci_intel_tgl > snd_sof_intel_hda_common soundwire_intel soundwire_generic_allocation > soundwire_cadence snd_sof_intel_hda snd_sof_pci snd_sof_xtensa_dsp snd_sof > iwlmvm snd_sof_utils snd_soc_hdac_hda snd_hda_ext_core > snd_soc_acpi_intel_match x86_pkg_temp_thermal intel_powerclamp snd_soc_acpi > snd_soc_core coretemp snd_compress mac80211 soundwire_bus btusb mei_hdcp > btrtl kvm_intel btbcm > [84564.498630] btintel intel_rapl_msr snd_hda_intel btmtk pmt_telemetry > pmt_class bluetooth libarc4 snd_intel_dspcfg kvm snd_intel_sdw_acpi iwlwifi > snd_hda_codec irqbypass uvcvideo snd_hda_core videobuf2_vmalloc rapl > processor_thermal_device_pci_legacy videobuf2_memops jitterentropy_rng > snd_hwdep processor_thermal_device intel_cstate cfg80211 videobuf2_v4l2 > snd_pcm processor_thermal_rfim thinkpad_acpi videobuf2_common drbg > processor_thermal_mbox nvram processor_thermal_rapl ansi_cprng videodev > platform_profile snd_timer ecdh_generic iTCO_wdt ledtrig
Bug#1032948: linux-image-6.1.0-5-amd64: oops in ucsi_acpi_notify
Package: src:linux Version: 6.1.12-1 Severity: important X-Debbugs-Cc: jcris...@debian.org Hi, After upgrading to 6.1.12-1 my laptop started hanging regularly (3 times in a few hours). Downgraded to 6.1.8-1 and I've not seen this for a week, so this looks like a recent regression. Not all the hangs left traces in logs, but I got at least one oops: > [ 485.537559] usb 3-6: USB disconnect, device number 4 > [ 485.537569] usb 3-6.1: USB disconnect, device number 6 > [ 485.537574] usb 3-6.1.4: USB disconnect, device number 8 > [ 485.574521] usb 2-3: USB disconnect, device number 2 > [ 485.574529] usb 2-3.1: USB disconnect, device number 3 > [ 485.574531] usb 2-3.1.2: USB disconnect, device number 4 > [ 485.574730] cdc_ncm 2-3.1.2:2.0 enxc84bd6b0b3e0: unregister 'cdc_ncm' > usb-:00:0d.0-3.1.2, CDC NCM (NO ZLP) > [ 486.051935] usb 3-6.5: USB disconnect, device number 7 > [ 486.413430] BUG: kernel NULL pointer dereference, address: 0398 > [ 486.413436] #PF: supervisor write access in kernel mode > [ 486.413438] #PF: error_code(0x0002) - not-present page > [ 486.413440] PGD 0 P4D 0 > [ 486.413442] Oops: 0002 [#1] PREEMPT SMP NOPTI > [ 486.413444] CPU: 0 PID: 129 Comm: kworker/0:2 Not tainted 6.1.0-5-amd64 #1 > Debian 6.1.12-1 > [ 486.413447] Hardware name: LENOVO 20XW00ABUS/20XW00ABUS, BIOS N32ET82W > (1.58 ) 12/05/2022 > [ 486.413448] Workqueue: kacpi_notify acpi_os_execute_deferred > [ 486.413455] RIP: 0010:queue_work_on+0x15/0x40 > [ 486.413460] Code: ff ff ff e9 9a fe ff ff 66 66 2e 0f 1f 84 00 00 00 00 00 > 66 90 0f 1f 44 00 00 53 9c 58 0f 1f 40 00 48 89 c3 fa 0f 1f 44 00 00 48 > 0f ba 2a 00 73 15 31 c9 80 e7 02 74 06 fb 0f 1f 44 00 00 89 > [ 486.413462] RSP: 0018:af8a80d53e38 EFLAGS: 00010002 > [ 486.413464] RAX: 0202 RBX: 0202 RCX: > > [ 486.413465] RDX: 0398 RSI: 8a2800051000 RDI: > 2000 > [ 486.413466] RBP: 0004 R08: 8a2815581ea0 R09: > > [ 486.413468] R10: R11: 005f R12: > 8a2f3f639b00 > [ 486.413469] R13: R14: 8a28836f3d80 R15: > 8a2860a03798 > [ 486.413470] FS: () GS:8a2f3f60() > knlGS: > [ 486.413471] CS: 0010 DS: ES: CR0: 80050033 > [ 486.413472] CR2: 0398 CR3: 1b010002 CR4: > 00770ef0 > [ 486.413474] PKRU: 5554 > [ 486.413475] Call Trace: > [ 486.413477] > [ 486.413483] ucsi_acpi_notify+0xa8/0xc0 [ucsi_acpi] > [ 486.413488] acpi_ev_notify_dispatch+0x42/0x5a > [ 486.413492] acpi_os_execute_deferred+0x13/0x20 > [ 486.413494] process_one_work+0x1c4/0x380 > [ 486.413497] worker_thread+0x4d/0x380 > [ 486.413500] ? _raw_spin_lock_irqsave+0x23/0x50 > [ 486.413503] ? rescuer_thread+0x3a0/0x3a0 > [ 486.413505] kthread+0xe6/0x110 > [ 486.413508] ? kthread_complete_and_exit+0x20/0x20 > [ 486.413510] ret_from_fork+0x1f/0x30 > [ 486.413515] > [ 486.413515] Modules linked in: xt_conntrack nft_chain_nat xt_MASQUERADE > nf_nat nf_conntrack_netlink nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 > xfrm_user xfrm_algo xt_addrtype nft_compat nf_tables libcrc32c nfnetlink > br_netfilter bridge stp llc ctr ccm rfcomm cmac algif_hash algif_skcipher > af_alg snd_seq_dummy snd_hrtimer snd_seq snd_seq_device qrtr overlay > ipmi_devintf bnep ipmi_msghandler binfmt_misc nls_ascii nls_cp437 vfat fat > snd_ctl_led snd_soc_skl_hda_dsp snd_soc_intel_hda_dsp_common > snd_soc_hdac_hdmi snd_sof_probes snd_hda_codec_hdmi snd_hda_codec_realtek > snd_hda_codec_generic snd_soc_dmic snd_sof_pci_intel_tgl > snd_sof_intel_hda_common soundwire_intel soundwire_generic_allocation btusb > soundwire_cadence btrtl snd_sof_intel_hda btbcm snd_sof_pci btintel > snd_sof_xtensa_dsp btmtk snd_sof x86_pkg_temp_thermal intel_powerclamp > snd_sof_utils bluetooth snd_soc_hdac_hda snd_hda_ext_core > snd_soc_acpi_intel_match iwlmvm snd_soc_acpi snd_soc_core coretemp > snd_compress soundwire_bus mac80211 > [ 486.413562] snd_hda_intel snd_intel_dspcfg snd_intel_sdw_acpi > snd_hda_codec kvm_intel snd_hda_core pmt_telemetry libarc4 mei_hdcp > intel_rapl_msr jitterentropy_rng pmt_class kvm iwlwifi uvcvideo snd_hwdep > irqbypass snd_pcm videobuf2_vmalloc drbg thinkpad_acpi iTCO_wdt > videobuf2_memops videobuf2_v4l2 rapl processor_thermal_device_pci_legacy > nvram ansi_cprng snd_timer intel_pmc_bxt platform_profile videobuf2_common > intel_cstate processor_thermal_device ecdh_generic ledtrig_audio cfg80211 > videodev ucsi_acpi processor_thermal_rfim pcspkr iTCO_vendor_support > processor_thermal_mbox typec_ucsi mei_me processor_thermal_rapl intel_uncore > intel_rapl_common wmi_bmof watchdog roles snd mei mc ecc intel_vsec > intel_soc_dts_iosf typec joydev soundcore ac cdc_mbim rfkill int3403_thermal > cdc_wdm soc_button_array int340x_thermal_zone intel_hid sparse_keymap > int3400_thermal acpi
Bug#1032886: unblock: ca-certificates/20230311
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock X-Debbugs-Cc: ca-certifica...@packages.debian.org, jcris...@debian.org Control: affects -1 + src:ca-certificates Please unblock package ca-certificates [ Reason ] Update root CA store, and fix RC FTBFS bug. [ Impact ] Key package FTBFS, root store data is 2 years out of date. [ Tests ] N/A, the changes are 1) update to data files, 2) FTBFS fix by updating a build-time script, 3) trivial compat fix for update-ca-certificates. [ Risks ] Changes are reasonably minimal. [ Checklist ] [x] all changes are documented in the d/changelog [x] I reviewed all changes and I approve them [x] attach debdiff against the package in testing unblock ca-certificates/20230311 Thanks, Julien
Bug#1021749: ca-certificates: expired certificates: E-Tugra_Certification_Authority.crt
Control: notfound 1021749 20230311 Control: fixed it 20230311 Please don't mix different issues in the same report. Cheers, Julien On Sun, Mar 12, 2023 at 10:20:16 +0800, Paul Wise wrote: > Control: found -1 20230311 > Control: retitle -1 ca-certificates: expired certificates: > E-Tugra_Certification_Authority.crt > > On Fri, 14 Oct 2022 09:01:30 +0800 Paul Wise wrote: > > > File: /usr/share/ca-certificates/mozilla/Cybertrust_Global_Root.crt > > File: /usr/share/ca-certificates/mozilla/GlobalSign_Root_CA_-_R2.crt > > > > I noticed that there are two expired certificates in ca-certificates, > > presumably Mozilla would have removed them and so an update is needed. > > These are now fixed but there is one newly expired CA certificate: > >$ sh test >Sun 12 Mar 2023 10:17:20 AWST >Expired: > /usr/share/ca-certificates/mozilla/E-Tugra_Certification_Authority.crt Mar 3 > 12:09:48 2023 GMT 1677845388 1678587440 > > Since the version is from today, probably Mozilla needs to fix this. > > -- > bye, > pabs > > https://wiki.debian.org/PaulWise
Bug#1031714: python3.11: doctest fails to deal with method wrappers
Package: python3.11
Version: 3.11.1-2
Severity: important
X-Debbugs-Cc: jcris...@debian.org
Tags: upstream fixed-upstream
Forwarded: https://github.com/python/cpython/issues/99433
Control: affects -1 mercurial
Hi,
python3.11 breaks mercurial's test-doctest.py with:
---
/tmp/autopkgtest-lxc.jj0p4qad/downtmp/build.aoZ/src/tests/test-doctest.py.out
+++
/tmp/autopkgtest-lxc.jj0p4qad/downtmp/build.aoZ/src/tests/test-doctest.py.err
@@ -0,0 +1,14 @@
+Traceback (most recent call last):
+ File
"/tmp/autopkgtest-lxc.jj0p4qad/downtmp/build.aoZ/src/tests/test-doctest.py",
line 116, in
+testmod(modname, **kwargs)
+ File
"/tmp/autopkgtest-lxc.jj0p4qad/downtmp/build.aoZ/src/tests/test-doctest.py",
line 46, in testmod
+for test in finder.find(mod, name):
+^^
+ File "/usr/lib/python3.11/doctest.py", line 940, in find
+self._find(tests, obj, name, module, source_lines, globs, {})
+ File "/usr/lib/python3.11/doctest.py", line 1012, in _find
+self._from_module(module, val)):
+^^
+ File "/usr/lib/python3.11/doctest.py", line 974, in _from_module
+raise ValueError("object must be a class or function")
+ValueError: object must be a class or function
ERROR: test-doctest.py output changed
Looks like this was fixed in 3.11.2 with
https://github.com/python/cpython/commit/c88a83e7d81fbf394bbdebe0f453bb64bdf33ba6
Cheers,
Julien
Bug#1027832: debian-policy: Please clarify that priority required packages are not automatically build essential
On Tue, Jan 3, 2023 at 22:14:10 +0100, Santiago Vila wrote: > Hello. This is an attempt to put the basis for fixing this bug: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=837060 > > As an example, packages tzdata, mount or e2fsprogs are not build-essential > and afaik have not been for a long time, but there are still people who > believe that they are build-essential for the mere fact that they are > priority:required. > Like I said in the debootstrap bug, I believe we should treat a case where a package is Priority: required but not actually required by the Essential set as a bug in package priorities, and neither debootstrap nor policy need to change. Cheers, Julien
Bug#1026508: ca-certificates: FTBFS: TypeError: argument 'data': 'bytearray' object cannot be converted to 'PyBytes'
Control: forcemerge 1008244 -1 This is fixed in git, I need to get around to uploading an update. Cheers, Julien On Tue, Dec 20, 2022 at 05:36:27PM +0100, Lucas Nussbaum wrote: > Source: ca-certificates > Version: 20211016 > Severity: serious > Justification: FTBFS > Tags: bookworm sid ftbfs > User: lu...@debian.org > Usertags: ftbfs-20221220 ftbfs-bookworm > > Hi, > > During a rebuild of all packages in sid, your package failed to build > on amd64. > > > Relevant part (hopefully): > > make[2]: Entering directory '/<>/mozilla' > > python3 certdata2pem.py > > Ignoring certificate "Verisign Class 1 Public Primary Certification > > Authority - G3". SAUTH=CKT_NSS_MUST_VERIFY_TRUST, > > EPROT=CKT_NSS_TRUSTED_DELEGATOR > > Ignoring certificate "Verisign Class 2 Public Primary Certification > > Authority - G3". SAUTH=CKT_NSS_MUST_VERIFY_TRUST, > > EPROT=CKT_NSS_TRUSTED_DELEGATOR > > Ignoring certificate "Certum Root CA". SAUTH=CKT_NSS_MUST_VERIFY_TRUST, > > EPROT=CKT_NSS_TRUSTED_DELEGATOR > > Ignoring certificate "Camerfirma Chambers of Commerce Root". > > SAUTH=CKT_NSS_MUST_VERIFY_TRUST, EPROT=CKT_NSS_TRUSTED_DELEGATOR > > Ignoring certificate "Camerfirma Global Chambersign Root". > > SAUTH=CKT_NSS_MUST_VERIFY_TRUST, EPROT=CKT_NSS_TRUSTED_DELEGATOR > > Certificate "DST Root CA X3" blacklisted, ignoring. > > Ignoring certificate "SwissSign Platinum CA - G2". > > SAUTH=CKT_NSS_MUST_VERIFY_TRUST, EPROT=CKT_NSS_TRUSTED_DELEGATOR > > Ignoring certificate "OISTE WISeKey Global Root GA CA". > > SAUTH=CKT_NSS_MUST_VERIFY_TRUST, EPROT=CKT_NSS_TRUSTED_DELEGATOR > > Ignoring certificate "Chambers of Commerce Root - 2008". > > SAUTH=CKT_NSS_MUST_VERIFY_TRUST, EPROT=CKT_NSS_TRUSTED_DELEGATOR > > Ignoring certificate "Global Chambersign Root - 2008". > > SAUTH=CKT_NSS_MUST_VERIFY_TRUST, EPROT=CKT_NSS_TRUSTED_DELEGATOR > > Certificate "Explicitly Distrust DigiNotar Root CA" blacklisted, ignoring. > > Certificate "Explicitly Distrusted DigiNotar PKIoverheid G2" blacklisted, > > ignoring. > > Certificate "MITM subCA 1 issued by Trustwave" blacklisted, ignoring. > > Certificate "MITM subCA 2 issued by Trustwave" blacklisted, ignoring. > > Certificate "TURKTRUST Mis-issued Intermediate CA 1" blacklisted, ignoring. > > Certificate "TURKTRUST Mis-issued Intermediate CA 2" blacklisted, ignoring. > > Ignoring certificate "Staat der Nederlanden Root CA - G3". > > SAUTH=CKT_NSS_MUST_VERIFY_TRUST, EPROT=CKT_NSS_TRUSTED_DELEGATOR > > Ignoring certificate "Symantec Class 1 Public Primary Certification > > Authority - G6". SAUTH=CKT_NSS_MUST_VERIFY_TRUST, > > EPROT=CKT_NSS_TRUSTED_DELEGATOR > > Ignoring certificate "Symantec Class 2 Public Primary Certification > > Authority - G6". SAUTH=CKT_NSS_MUST_VERIFY_TRUST, > > EPROT=CKT_NSS_TRUSTED_DELEGATOR > > Ignoring certificate "D-TRUST Root CA 3 2013". > > SAUTH=CKT_NSS_MUST_VERIFY_TRUST, EPROT=CKT_NSS_TRUSTED_DELEGATOR > > Ignoring certificate "GlobalSign Secure Mail Root R45". > > SAUTH=CKT_NSS_MUST_VERIFY_TRUST, EPROT=CKT_NSS_TRUSTED_DELEGATOR > > Ignoring certificate "GlobalSign Secure Mail Root E45". > > SAUTH=CKT_NSS_MUST_VERIFY_TRUST, EPROT=CKT_NSS_TRUSTED_DELEGATOR > > Traceback (most recent call last): > > File "/<>/mozilla/certdata2pem.py", line 125, in > > cert = x509.load_der_x509_certificate(obj['CKA_VALUE']) > > File "/usr/lib/python3/dist-packages/cryptography/x509/base.py", line > > 528, in load_der_x509_certificate > > return rust_x509.load_der_x509_certificate(data) > > TypeError: argument 'data': 'bytearray' object cannot be converted to > > 'PyBytes' > > make[2]: *** [Makefile:6: all] Error 1 > > > The full build log is available from: > http://qa-logs.debian.net/2022/12/20/ca-certificates_20211016_unstable.log > > All bugs filed during this archive rebuild are listed at: > https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ftbfs-20221220;users=lu...@debian.org > or: > https://udd.debian.org/bugs/?release=na&merged=ign&fnewerval=7&flastmodval=7&fusertag=only&fusertagtag=ftbfs-20221220&fusertaguser=lu...@debian.org&allbugs=1&cseverity=1&ctags=1&caffected=1#results > > A list of current common problems and possible solutions is available at > http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute! > > If you reassign this bug to another package, please mark it as 'affects'-ing > this package. See https://www.debian.org/Bugs/server-control#affects > > If you fail to reproduce this, please provide a build log and diff it with > mine > so that we can identify if something relevant changed in the meantime. >
Bug#1025621: mercurial: FTBFS on 32-bit (test-revset.t: output changed)
Source: mercurial Version: 6.3.1-1 Severity: serious Tags: upstream patch ftbfs Justification: fails to build from source (but built successfully in the past) X-Debbugs-Cc: jcris...@debian.org Forwarded: https://bz.mercurial-scm.org/show_bug.cgi?id=6770 mercurial 6.3 fails its testsuite on 32-bit. More info and proposed patch in the bugzilla ticket. Cheers, Julien
Bug#1024867: mercurial: FTBFS on riscv64 (test timeout)
Control: tag -1 moreinfo On Sun, Nov 27, 2022 at 14:21:52 +0800, Eric Long wrote: > Source: mercurial > Version: 6.2.3-1 > Severity: important > Tags: ftbfs patch > Justification: fails to build from source (but built successfully in the past) > User: debian-ri...@lists.debian.org > Usertags: riscv64 > X-Debbugs-Cc: i...@hack3r.moe, debian-ri...@lists.debian.org > > Dear maintainer(s), > > Some tests time out on riscv64 as seen in buildd log: > > ``` > Failed test-copies-chain-merge.t#pull: timed out > Failed test-copies-chain-merge.t#pull-upgrade: timed out > Failed test-copies-chain-merge.t#push: timed out > Failed test-copies-chain-merge.t#push-upgrade: timed out > Failed test-copies-chain-merge.t#sidedata: timed out > Failed test-copies-chain-merge.t#upgraded: timed out > Failed test-copies-chain-merge.t#upgraded-parallel: timed out > # Ran 892 tests, 80 skipped, 7 failed. > python hash seed: 74757585 > # Timout reached for process 2161206 > # Cleaning up HGTMP /tmp/hgtests.3yx9dxu8 > make[2]: *** [Makefile:140: tests] Error 1 > ``` > > Full log: > https://buildd.debian.org/status/fetch.php?pkg=mercurial&arch=riscv64&ver=6.2.3-1&stamp=1668895854&raw=0 > > These timeouts has existed for a long time (about a year), so maybe disable > them is a better idea for more consistent builds on riscv64. Alternatively, we > can increase test timeout further and hopefully let them finish in time. > > I've included a patch to disable those tests in debian/rules. Please let me > know if more help is needed. > I'd rather not duplicate the blacklist, that sounds like a maintenance nightmare. How long do these tests actually need on your hardware? Cheers, Julien
Bug#1025172: gnome-shell: crash when moving window to another monitor
Package: gnome-shell Version: 43.1-2 Severity: important X-Debbugs-Cc: jcris...@debian.org Hi, I've been seeing this for a few weeks, it happens when I try to move a window from one monitor to the other. Bits of log from today: Nov 30 15:48:54 carotte gnome-shell[488815]: Object .Gjs_ui_windowPreview_WindowPreview (0x5638f1b45bc0), has been already disposed — impossible to access it. This might be caused by the object having been dest> Nov 30 15:48:54 carotte gnome-shell[488815]: == Stack trace for context 0x5638edbea7b0 == Nov 30 15:48:54 carotte gnome-shell[488815]: #0 5638f1d81560 i resource:///org/gnome/shell/ui/windowPreview.js:645 (1ac9a09c4150 @ 195) Nov 30 15:48:54 carotte gnome-shell[488815]: #1 7ffe8e416ab0 b resource:///org/gnome/shell/ui/windowPreview.js:353 (1ac9a09c2880 @ 62) Nov 30 15:48:54 carotte gnome-shell[488815]: #2 5638f1d814d0 i resource:///org/gnome/shell/ui/windowPreview.js:591 (1ac9a09c2fb0 @ 75) Nov 30 15:48:54 carotte gnome-shell[488815]: #3 5638f1d81440 i resource:///org/gnome/shell/ui/workspace.js:1355 (1ac9a09c1f60 @ 94) Nov 30 15:48:54 carotte gnome-shell[488815]: #4 5638f1d81358 i resource:///org/gnome/shell/ui/windowPreview.js:345 (1ac9a09c27e0 @ 822) Nov 30 15:48:54 carotte gnome-shell[488815]: #5 5638f1d812c8 i resource:///org/gnome/shell/ui/windowPreview.js:551 (1ac9a09c2e70 @ 18) Nov 30 15:48:54 carotte gnome-shell[488815]: clutter_actor_set_child_above_sibling: assertion 'sibling->priv->parent == self' failed Nov 30 15:48:59 carotte gnome-shell[488815]: ** Nov 30 15:48:59 carotte gnome-shell[488815]: libmutter:ERROR:../src/core/window.c:5156:meta_window_set_focused_internal: assertion failed: (link) Nov 30 15:48:59 carotte gnome-shell[488815]: Bail out! libmutter:ERROR:../src/core/window.c:5156:meta_window_set_focused_internal: assertion failed: (link) Nov 30 15:48:59 carotte gnome-shell[488815]: == Stack trace for context 0x5638edbea7b0 == Nov 30 15:48:59 carotte gnome-shell[488815]: #0 7ffe8e416c90 b resource:///org/gnome/shell/ui/main.js:658 (198ec19bf8d0 @ 371) Nov 30 15:48:59 carotte gnome-shell[488815]: #1 5638f1d81500 i resource:///org/gnome/shell/ui/dnd.js:211 (198ec19e3ab0 @ 61) Nov 30 15:48:59 carotte gnome-shell[488815]: #2 5638f1d81468 i resource:///org/gnome/shell/ui/dnd.js:785 (198ec19fd290 @ 93) Nov 30 15:48:59 carotte gnome-shell[488815]: #3 5638f1d813d8 i resource:///org/gnome/shell/ui/dnd.js:755 (198ec19fd1f0 @ 73) Nov 30 15:48:59 carotte gnome-shell[488815]: #4 5638f1d81358 i resource:///org/gnome/shell/ui/dnd.js:420 (198ec19e3c90 @ 12) Nov 30 15:48:59 carotte gnome-shell[488815]: #5 7ffe8e4181e0 b resource:///org/gnome/shell/ui/workspace.js:1143 (1ac9a09c17e0 @ 75) Nov 30 15:48:59 carotte gnome-shell[488815]: #6 5638f1d812c8 i resource:///org/gnome/shell/ui/workspace.js:1259 (1ac9a09c1ab0 @ 20) Nov 30 15:48:59 carotte gnome-shell[488815]: #7 7ffe8e418ca0 b self-hosted:1121 (198ec197eec0 @ 463) Nov 30 15:48:59 carotte gnome-shell[495852]: (EE) failed to read Wayland events: Broken pipe Nov 30 15:48:59 carotte firefox-bin[490666]: Error reading events from display: Connection reset by peer Nov 30 15:48:59 carotte gnome-terminal-[491509]: Error reading events from display: Broken pipe Nov 30 15:48:59 carotte gsd-color[489171]: Error reading events from display: Broken pipe Nov 30 15:48:59 carotte gsd-wacom[489199]: Error reading events from display: Broken pipe Nov 30 15:48:59 carotte gsd-power[489186]: Error reading events from display: Broken pipe Nov 30 15:48:59 carotte gsd-keyboard[489180]: Error reading events from display: Broken pipe Nov 30 15:48:59 carotte xdg-desktop-por[489449]: Error reading events from display: Broken pipe Nov 30 15:48:59 carotte gnome-calendar[490374]: Error reading events from display: Broken pipe Nov 30 15:48:59 carotte gsd-media-keys[489183]: Error reading events from display: Broken pipe Nov 30 15:48:59 carotte systemd[1650]: org.gnome.Shell@wayland.service: Main process exited, code=killed, status=6/ABRT [...] Cheers, Julien -- System Information: Debian Release: bookworm/sid APT prefers testing-debug APT policy: (600, 'testing-debug'), (600, 'testing'), (500, 'unstable-debug'), (500, 'stable-updates'), (500, 'stable-security'), (500, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.0.0-4-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gnome-shell depends on: ii dconf-gsettings-backend [gsettings-backend] 0.40.0-3 ii gir1.2-accountsservice-1.0 22.08.8-1+b1 ii gir1.2-adw-1 1.2.0-1 ii gir1.2-atk-1.0 2.46.0-4 ii gir1.2-atspi-2.0 2.46.0-4 ii gir1.2-freedeskto
Bug#1021002: ftp.halifax.rwth-aachen: intermittent dns failures
Hi Carsten,
On Tue, Oct 4, 2022 at 13:06:27 +0200, Carsten Otto wrote:
> Dear all,
>
> On Fri, Sep 30, 2022 at 06:49:48PM +0200, Carsten Otto wrote:
> > I escalated this to the university staff managing DNS for
> > rwth-aachen.de.
>
> Bernd Kohler of RWTH Aachen university investigated and found something
> interesting.
>
> The CNAME ftp2.de.debian.org -> ftp.halifax.rwth-aachen.de resolves for
> public DNS servers like 8.8.8.8, but it does not resolve for those used
> by Debian.
>
> date -R; for i in "82.195.75.105" "2001:41b8:202:deb:1a1a:0:52c3:4b69"
> "209.87.16.31" "2607:f8f0:614:1::1274:31" "194.177.211.201"
> "2001:648:2ffc:deb::211:201"; do for j in "a" ""; do dig +noall +answer
> @${i} ftp2.de.debian.org ${j}; done; echo -e "\n###\n";
> done
>
> Maybe this is related to the issues you are seeing?
>
These aren't the IP addresses of the debian.org name servers, they serve
the www.debian.org zone only.
Cheers,
Julien
Bug#1020997: mirror.sitsa.com.ar: out-of-date
Hi Franco, http://mirror.sitsa.com.ar/debian/project/trace/mirror.sitsa.com.ar is dated July 20. ftpsync should be updating it after each successful sync. Cheers, Julien On Fri, Sep 30, 2022 at 08:40:46AM -0300, Franco E. Lazos - SiTSA Telecomunicaciones wrote: > Hi Julien and team, > > Our replica server is working properly and is up to date. > The only thing that was done (perhaps approximately 2 months ago) was to > migrate it to a machine with greater processing and storage capacity. > > Feel free to request any modification that you think is convenient. > > Best regards, > > P.S: the migration was quick in terms of availability because no changes were > made to production until all the installation processes for the new machine > were complete. > > Franco E. Lazos > Departamento Técnico > SiTSA – Telecomunicaciones > Entre Rios 1435 – (X5900AGI) – Villa María – CBA-ARG > Fijo (54 353) 453-1146 | INT 107 > Móvil (54 351) 248-2514 > e-Mail franco.la...@sitsa.com.ar > Website www.sitsa.com.ar / www.trackmaster.com.ar > > P Proteja el medio ambiente, no imprima este mail sino es necesario. > > > > ATTORNEY - CLIENT PRIVILEGED INFORMATION > > Este mensaje es privado y confidencial, y está dirigido exclusivamente a > su(s) > destinatario(s). Si usted ha recibido este mensaje por error, debe abstenerse > de distribuirlo, copiarlo o usarlo en cualquier sentido. > Asimismo, le agradecemos comunicarlo al remitente y borrar el mensaje y > cualquier documento adjunto > > This email and any files transmitted with it are confidential and intended > solely for the use of the individual or entity to whom they are addressed. > Please notify the sender immediately by e-mail if you have received this > e-mail > by mistake and delete this e-mail from your system. > > > > > El 30 sep. 2022, a las 07:13, Julien Cristau > escribió: > > Package: mirrors > Severity: normal > X-Debbugs-Cc: NOC SiTSA Telecomunicaciones > User: mirr...@packages.debian.org > Usertags: mirror-problem > > Hi, > > Our monitoring shows[1] mirror.sitsa.com.ar/debian is 2 months out of > date. Can you please let us know what's going on? > > [1]: https://mirror-master.debian.org/status/mirror-info/ > mirror.sitsa.com.ar.html > > Thanks, > Julien - Debian mirrors team > >
Bug#1021004: mirror.it4i.cz: out-of-date
Package: mirrors Severity: normal User: mirr...@packages.debian.org Usertags: mirror-problem X-Debbugs-Cc: IT4Innovations National Supercomputing Center Hi, I was checking some things in the Debian mirror universe and noticed a problem with your mirror: o It seems your mirror is not up to date, having last successfully updated on Fri, 16 Sep 2022 10:10:06 + There have been later attempts to sync but at least the mirror's trace file isn't getting updated. Can you look into this and report back? Thanks, Julien - Debian mirrors team
Bug#1021002: ftp.halifax.rwth-aachen: intermittent dns failures
Package: mirrors Severity: normal User: mirr...@packages.debian.org Usertags: mirror-problem X-Debbugs-Cc: Carsten Otto Hi, I was checking some things in the Debian mirror universe and noticed a problem with your mirror: Our monitoring appears to have intermittent trouble resolving the mirror name: https://mirror-master.debian.org/status/mirror-info/ftp.halifax.rwth-aachen.de.html Any chance you could take a look at this? Thanks, Julien - Debian mirrors team
Bug#1021001: mirror-prg.webglobe.com: out-of-date
Package: mirrors User: mirr...@packages.debian.org Usertags: mirror-problem X-Debbugs-Cc: Jiri Lunacek Hi, I was checking some things in the Debian mirror universe and noticed a problem with your mirror: o It seems your mirror is not up to date, having last successfully updated on Tue, 13 Sep 2022 14:10:44 + It looks like there were later sync attempts but they seem to be failing (at least the trace file is not getting updated). Can you check on it and report back? Thanks, Julien - Debian mirrors team
Bug#1021000: mirror.lzu.edu.cn: tracefile
Package: mirrors X-Debbugs-Cc: Chuhao Li User: mirr...@packages.debian.org Usertags: mirror-problem Hi, I was checking some things in the Debian mirror universe and noticed a problem with your mirror: o trace file: I notice there is no tracefile matching your site name mirror.lzu.edu.cn in http://mirror.lzu.edu.cn/debian/project/trace/ Please set MIRRORNAME to the mirror's hostname in ftpsync.conf. Also: o we recommend mirrors not sync directly from service aliases such as ftp..debian.org (only http is guaranteed to be available at ftp..d.o sites). Maybe change your config to sync from the site currently backing the ftp..debian.org service you sync from? Thanks, Julien - Debian mirrors team
Bug#1020999: mirrors.hit.edu.cn: tracefile
Package: mirrors X-Debbugs-Cc: Harbin Institute of Technology Linux User Group User: mirr...@packages.debian.org Usertags: mirror-problem Hi, I was checking some things in the Debian mirror universe and noticed a problem with your mirror: o trace file: I notice there is no tracefile matching your site name mirrors.hit.edu.cn in http://mirrors.hit.edu.cn/debian/project/trace/ Please use our ftpsync script to mirror Debian. It should produce the trace files we require, and do the mirroring in a way that ensures the mirror is in a consistent state even during updates. http://mirrors.hit.edu.cn/debian/project/ftpsync/ftpsync-current.tar.gz Cheers, Julien - Debian mirrors team
Bug#1020998: mirror.csclub.uwaterloo.ca: syncscript
Package: mirrors X-Debbugs-Cc: David Bartley User: mirr...@packages.debian.org Usertags: mirror-problem Hi, I was checking some things in the Debian mirror universe and noticed a problem with your mirror: o The tracefile http://mirror.csclub.uwaterloo.ca/debian/project/trace/mirror.csclub.uwaterloo.ca suggests that you are not using ftpsync. Please use our ftpsync script to mirror Debian. It should produce better trace files, and do the mirroring in a way that ensures the mirror is in a consistent state even during updates. http://mirror.csclub.uwaterloo.ca/debian/project/ftpsync/ftpsync-current.tar.gz Thanks, Julien - Debian mirrors team
Bug#1020997: mirror.sitsa.com.ar: out-of-date
Package: mirrors Severity: normal X-Debbugs-Cc: NOC SiTSA Telecomunicaciones User: mirr...@packages.debian.org Usertags: mirror-problem Hi, Our monitoring shows[1] mirror.sitsa.com.ar/debian is 2 months out of date. Can you please let us know what's going on? [1]: https://mirror-master.debian.org/status/mirror-info/mirror.sitsa.com.ar.html Thanks, Julien - Debian mirrors team
Bug#1008601: mirror submission for ftp.psnc.pl
Hi Rafal, On Fri, Sep 23, 2022 at 03:00:36PM +0200, PSNC Mirrors Team wrote: > Hi, > > Our mirror was updating twice a day. > According to the recommendation, we changed to run every hour with a random > offset of 1-60 minutes. > We also changed from ftpsync to ftpsync-cron. > If you have any more comments, let us know about it, we will correct it. > Thank you :) > It is known perhaps where we could see the statuses of mirrors? > On https://people.debian.org/~jcristau/mirror-status/mirror-status.html > shows our server under the old name ftp.man.poznan.pl where the current one > we have now is ftp.psnc.pl and on other sites we are not there, such as: > - https://mirror-master.debian.org/status/mirror-status.html > - https://www.debian.org/mirror/list > What is the difference between these sites? > https://people.debian.org/~jcristau/mirror-status/mirror-status.html was an old static snapshot of the status page from 5 years ago, I've now deleted it. https://mirror-master.debian.org/status/mirror-status.html is updated every 20 minutes or so; I've now added the mirror to the list it uses as source, so it should show up soon. https://www.debian.org/mirror/list is updated regularly, by filtering the source list and removing mirrors with a low "score", as seen by the mirror-status page. So for new mirrors it takes a few days for the score to reach the threshold. Cheers, Julien > Greetings > Rafal Wisniewski > PSNC Mirror Team > > On 9/17/22 15:39, Julien Cristau wrote: > > Control: tag -1 moreinfo > > > > Hi, > > > > o It seems your mirror is not up to date, having last updated on Fri, 16 > > Sep 2022 20:56:25 + > > o The latest ftpsync versions come with a wrapper script called > >ftpsync-cron, which is intended to be run out of cron every hour or so > >(at a randomish offset). The script monitors your upstream mirror, > >and if there was an update triggers a full sync using ftpsync. > >You might want to give it a try. > > > >NOTE: This requires having your upstream mirror name set correctly to > >a specific mirror which is also correctly configured (and thus has a > >tracefile in /debian/project/trace with its name). > > > > Can you double check on this? (The debian archive updates roughly every > > six hours, and we expect mirrors to follow that frequency.) > > > > Cheers, > > Julien > > > > On Tue, Mar 29, 2022 at 11:29:44AM +, PSNC mirrors team wrote: > > > Package: mirrors > > > Severity: wishlist > > > User: mirr...@packages.debian.org > > > Usertags: mirror-submission > > > > > > Submission-Type: new > > > Site: ftp.psnc.pl > > > Type: leaf > > > Archive-architecture: ALL amd64 arm64 armel armhf hurd-i386 i386 > > > kfreebsd-amd64 kfreebsd-i386 mips mips64el mipsel powerpc ppc64el s390x > > > Archive-http: /debian/ > > > Maintainer: PSNC mirrors team > > > Country: PL Poland > > > Location: Poznań > > > Sponsor: Poznan Supercomputing and Networking Center https://psnc.pl/ > > > > > > > > > > > > > > > Trace Url: http://ftp.psnc.pl/debian/project/trace/ > > > Trace Url: http://ftp.psnc.pl/debian/project/trace/ftp-master.debian.org > > > Trace Url: http://ftp.psnc.pl/debian/project/trace/ftp.psnc.pl >
Bug#1014262: mirror submission for mirror.serverion.com
Control: reopen -1 Control: tag -1 + moreinfo Hi, It seems you're still not using ftpsync? What software are you using instead for the mirror? Also, connections seem to be quite slow, at least 5s and up to 40s for me to get a single small file, in a few attempts. Cheers, Julien On Sun, Sep 18, 2022 at 08:49:21AM +0200, Desmond van der Winden wrote: > Thank you, can you please check again? > > > With kind regards, > > > > Desmond van der Winden > > > > E-mail: i...@serverion.com > Web: https://www.serverion.com > > Serverion B.V. > Krammer 8 > 3232 HE Brielle > The Netherlands > Tel: +31 (0)85 - 130 8333 > > Serverion L.L.C. > 600 N. Broadstreet Suite 5#3252 > 19709 Middletown > Delaware > United States of America > Tel: +1(302) - 380 39 02 > > > Op 17-09-2022 16:30 heeft Julien Cristau geschreven: > > Hi, > > Your trace file doesn't look right: > > o The first line of the tracefile at > http://mirror.serverion.com/debian/project/trace/mirror.serverion.com > should be the date, formatted like: Sat Sep 17 14:28:37 UTC 2022 > > Please use ftpsync to mirror debian. It should produce the trace files > we require, and do the mirroring in a way that ensures the mirror is in > a consistent state even during updates. > > > http://mirror.serverion.com/debian/project/ftpsync/ftpsync-current.tar.gz > > Cheers, > Julien > > On Sun, Jul 03, 2022 at 06:06:46AM +, serverion.com wrote: > > Package: mirrors > > Severity: wishlist > > User: mirr...@packages.debian.org > > Usertags: mirror-submission > > > > Submission-Type: new > > Site: mirror.serverion.com > > Type: leaf > > Archive-architecture: ALL amd64 arm64 armel armhf hurd-i386 i386 > kfreebsd-amd64 kfreebsd-i386 mips mips64el mipsel powerpc ppc64el s390x > > Archive-http: /debian/ > > Archive-rsync: debian/ > > Maintainer: serverion.com > > Country: NL Netherlands > > Location: Zoetermeer, NL > > Sponsor: Serverion.com https://www.serverion.com > > Comment: Hi, > > > > Please add > > > > http://mirror.serverion.com/debian > > http://mirror.serverion.com/debian-cd > > http://mirror.serverion.com/debian-archive > > > > https/rsync/ftp enabled on ipv4 and ipv6 > > > > Thank you, > > > > Desmond > > > > > > > > > > Trace Url: http://mirror.serverion.com/debian/project/trace/ > > Trace Url: > http://mirror.serverion.com/debian/project/trace/ftp-master.debian.org > > Trace Url: > http://mirror.serverion.com/debian/project/trace/mirror.serverion.com > >
Bug#1014757: mirror submission for mirror.ukrnames.com
Control: tag -1 moreinfo Hi, Please fix this issue with the mirror and let us know: o we recommend mirrors not sync directly from service aliases such as ftp..debian.org (only http is guaranteed to be available at ftp..d.o sites). Maybe change your config to sync from the site currently backing the ftp..debian.org service you sync from? (Also you might want to pick an upstream closer than the US) Cheers, Julien On Mon, Jul 11, 2022 at 04:01:24PM +, Oleksandr Loboda wrote: > Package: mirrors > Severity: wishlist > User: mirr...@packages.debian.org > Usertags: mirror-submission > > Submission-Type: new > Site: mirror.ukrnames.com > Type: leaf > Archive-architecture: amd64 arm64 armel armhf hurd-i386 i386 kfreebsd-amd64 > kfreebsd-i386 mips mips64el mipsel powerpc ppc64el s390x > Archive-http: /debian/ > Archive-rsync: debian/ > Maintainer: Oleksandr Loboda > Country: UA Ukraine > Location: Kharkiv, Ukraine > Sponsor: Ukrnames.com https://www.ukrnames.com > > > > > Trace Url: http://mirror.ukrnames.com/debian/project/trace/ > Trace Url: > http://mirror.ukrnames.com/debian/project/trace/ftp-master.debian.org > Trace Url: http://mirror.ukrnames.com/debian/project/trace/mirror.ukrnames.com
Bug#1014587: mirror submission for mirrors.nic.cz
Control: tag -1 moreinfo Hi, Please fix the below issue before we add to the mirror list: o we recommend mirrors not sync directly from service aliases such as ftp..debian.org (only http is guaranteed to be available at ftp..d.o sites). Maybe change your config to sync from the site currently backing the ftp..debian.org service you sync from? Thanks, Julien On Fri, Jul 08, 2022 at 12:28:27PM +, NIC admins team wrote: > Package: mirrors > Severity: wishlist > User: mirr...@packages.debian.org > Usertags: mirror-submission > > Submission-Type: new > Site: mirrors.nic.cz > Type: leaf > Archive-architecture: ALL amd64 arm64 armel armhf hurd-i386 i386 > kfreebsd-amd64 kfreebsd-i386 mips mips64el mipsel powerpc ppc64el s390x > Archive-http: /debian/ > Archive-rsync: debian/ > Maintainer: NIC admins team > Country: CZ Czechia > > > > > Trace Url: http://mirrors.nic.cz/debian/project/trace/ > Trace Url: http://mirrors.nic.cz/debian/project/trace/ftp-master.debian.org > Trace Url: http://mirrors.nic.cz/debian/project/trace/mirrors.nic.cz
Bug#1011475: mirror submission for mirror.xtx.cloud
Another thing: o The tracefile http://mirrors.m247.com/debian/project/trace/mirrors.m247.com suggests that the ftpsync version you are using is very old. Please upgrade. Using a modern ftpsync ensures updates are done in the correct order so apt clients don't get confused. In particular, it processes translations, contents, and more files that have been added to the archive in recent years in the correct stage. It also should produce trace files that contain more information that is useful for us and helps downstream mirrors sync better. http://mirrors.m247.com/debian/project/ftpsync/ftpsync-current.tar.gz Cheers, Julien On Sat, Sep 17, 2022 at 04:12:42PM +0200, Julien Cristau wrote: > Control: tag -1 moreinfo > > Hi, > > I notice there is no tracefile matching your site name mirror.xtx.cloud > in http://mirror.xtx.cloud/debian/project/trace/ > We expect the trace file name to match the mirror name we list, so we > can monitor it. > You can either change MIRRORNAME in ftpsync.conf, or list the mirror as > mirrors.m247.com (which seems to be the current trace file name?). > > Cheers, > Julien > > On Mon, May 23, 2022 at 06:45:14PM +, Mirror Admin wrote: > > Package: mirrors > > Severity: wishlist > > User: mirr...@packages.debian.org > > Usertags: mirror-submission > > > > Submission-Type: new > > Site: mirror.xtx.cloud > > Type: leaf > > Archive-architecture: amd64 arm64 armhf i386 > > Archive-http: /debian/ > > Maintainer: Mirror Admin > > Country: GB United Kingdom > > Location: Dorset, UK > > Sponsor: XTX Cloud https://www.xtx.cloud > > Comment: Hosted with love on a 1Gbit connection > > > > > > > > > > Trace Url: http://mirror.xtx.cloud/debian/project/trace/ > > Trace Url: > > http://mirror.xtx.cloud/debian/project/trace/ftp-master.debian.org > > Trace Url: http://mirror.xtx.cloud/debian/project/trace/mirror.xtx.cloud
Bug#1011475: mirror submission for mirror.xtx.cloud
Control: tag -1 moreinfo Hi, I notice there is no tracefile matching your site name mirror.xtx.cloud in http://mirror.xtx.cloud/debian/project/trace/ We expect the trace file name to match the mirror name we list, so we can monitor it. You can either change MIRRORNAME in ftpsync.conf, or list the mirror as mirrors.m247.com (which seems to be the current trace file name?). Cheers, Julien On Mon, May 23, 2022 at 06:45:14PM +, Mirror Admin wrote: > Package: mirrors > Severity: wishlist > User: mirr...@packages.debian.org > Usertags: mirror-submission > > Submission-Type: new > Site: mirror.xtx.cloud > Type: leaf > Archive-architecture: amd64 arm64 armhf i386 > Archive-http: /debian/ > Maintainer: Mirror Admin > Country: GB United Kingdom > Location: Dorset, UK > Sponsor: XTX Cloud https://www.xtx.cloud > Comment: Hosted with love on a 1Gbit connection > > > > > Trace Url: http://mirror.xtx.cloud/debian/project/trace/ > Trace Url: http://mirror.xtx.cloud/debian/project/trace/ftp-master.debian.org > Trace Url: http://mirror.xtx.cloud/debian/project/trace/mirror.xtx.cloud
Bug#1009048: mirror submission for debian.mirrors.orange.ro
Control: tag -1 moreinfo Hi, Our scripts found an issue with the mirror setup: o we recommend mirrors not sync directly from service aliases such as ftp..debian.org (only http is guaranteed to be available at ftp..d.o sites). Maybe change your config to sync from the site currently backing the ftp..debian.org service you sync from? Please switch from ftp.de.debian.org to debian.inf.tu-dresden.de as RSYNC_HOST. Thanks, Julien On Wed, Apr 06, 2022 at 01:51:46PM +, Orange Roamania Communications wrote: > Package: mirrors > Severity: wishlist > User: mirr...@packages.debian.org > Usertags: mirror-submission > > Submission-Type: new > Site: debian.mirrors.orange.ro > Type: leaf > Archive-architecture: ALL amd64 arm64 armel armhf hurd-i386 i386 > kfreebsd-amd64 kfreebsd-i386 mips mips64el mipsel powerpc ppc64el s390x > Archive-http: /debian/ > Archive-rsync: debian-archive/ > Maintainer: Orange Roamania Communications > Country: RO Romania > Location: Bucharest > > > > > Trace Url: http://debian.mirrors.orange.ro/debian/project/trace/ > Trace Url: > http://debian.mirrors.orange.ro/debian/project/trace/ftp-master.debian.org > Trace Url: > http://debian.mirrors.orange.ro/debian/project/trace/debian.mirrors.orange.ro
Bug#1019864: mirror submission for mirror.stjschools.org
Control: tag -1 moreinfo Hi, Our scripts found an issue with the mirror setup: o we recommend mirrors not sync directly from service aliases such as ftp..debian.org (only http is guaranteed to be available at ftp..d.o sites). Maybe change your config to sync from the site currently backing the ftp..debian.org service you sync from? ftp.us.debian.org is a round robin so it'd be better to pick one host for consistency. Let us know when that is updated. Cheers, Julien On Thu, Sep 15, 2022 at 04:31:14AM +, Grant Brooks wrote: > Package: mirrors > Severity: wishlist > User: mirr...@packages.debian.org > Usertags: mirror-submission > > Submission-Type: new > Site: mirror.stjschools.org > Type: leaf > Archive-architecture: ALL amd64 arm64 armel armhf hurd-i386 i386 > kfreebsd-amd64 kfreebsd-i386 mips mips64el mipsel powerpc ppc64el s390x > Archive-http: /debian/ > Archive-rsync: debian/ > Maintainer: Grant Brooks > Country: US United States > Location: Missouri > Comment: Network Information: > Bandwidth: 10G > ASN: 55140 (directly connected to the Kansas City / St. Louis Internet > Exchanges) > > Geo-IP Blocked Countries: > China, Cuba, Crimea Region of Ukraine, Iran, Iraq, Libya, North Korea, > Russia, Sudan, Syria, Yemen > > > > > Trace Url: http://mirror.stjschools.org/debian/project/trace/ > Trace Url: > http://mirror.stjschools.org/debian/project/trace/ftp-master.debian.org > Trace Url: > http://mirror.stjschools.org/debian/project/trace/mirror.stjschools.org
Bug#1008601: mirror submission for ftp.psnc.pl
Control: tag -1 moreinfo Hi, o It seems your mirror is not up to date, having last updated on Fri, 16 Sep 2022 20:56:25 + o The latest ftpsync versions come with a wrapper script called ftpsync-cron, which is intended to be run out of cron every hour or so (at a randomish offset). The script monitors your upstream mirror, and if there was an update triggers a full sync using ftpsync. You might want to give it a try. NOTE: This requires having your upstream mirror name set correctly to a specific mirror which is also correctly configured (and thus has a tracefile in /debian/project/trace with its name). Can you double check on this? (The debian archive updates roughly every six hours, and we expect mirrors to follow that frequency.) Cheers, Julien On Tue, Mar 29, 2022 at 11:29:44AM +, PSNC mirrors team wrote: > Package: mirrors > Severity: wishlist > User: mirr...@packages.debian.org > Usertags: mirror-submission > > Submission-Type: new > Site: ftp.psnc.pl > Type: leaf > Archive-architecture: ALL amd64 arm64 armel armhf hurd-i386 i386 > kfreebsd-amd64 kfreebsd-i386 mips mips64el mipsel powerpc ppc64el s390x > Archive-http: /debian/ > Maintainer: PSNC mirrors team > Country: PL Poland > Location: Poznań > Sponsor: Poznan Supercomputing and Networking Center https://psnc.pl/ > > > > > Trace Url: http://ftp.psnc.pl/debian/project/trace/ > Trace Url: http://ftp.psnc.pl/debian/project/trace/ftp-master.debian.org > Trace Url: http://ftp.psnc.pl/debian/project/trace/ftp.psnc.pl
Bug#1008477: mirror submission for mirror.ihost.md
Control: tag -1 moreinfo Hi, It looks like this mirror hasn't successfully synced with its upstream since August 29. Can you take a look? Cheers, Julien On Sun, Mar 27, 2022 at 12:28:17AM +, iHost wrote: > Package: mirrors > Severity: wishlist > User: mirr...@packages.debian.org > Usertags: mirror-submission > > Submission-Type: new > Site: mirror.ihost.md > Type: leaf > Archive-architecture: ALL amd64 arm64 armel armhf hurd-i386 i386 > kfreebsd-amd64 kfreebsd-i386 mips mips64el mipsel powerpc ppc64el s390x > Archive-http: /debian/ > Archive-rsync: debian/ > Maintainer: iHost > Country: MD Moldova > Location: Chisinau > Sponsor: iHost https://ihost.md/ > > > > > Trace Url: http://mirror.ihost.md/debian/project/trace/ > Trace Url: http://mirror.ihost.md/debian/project/trace/ftp-master.debian.org > Trace Url: http://mirror.ihost.md/debian/project/trace/mirror.ihost.md
Bug#1008985: mirror listing update for debian.cs.nctu.edu.tw
Hi, Could you please change the mirror name (MIRRORNAME variable in ftpsync.conf) to the new name? Our monitoring expects this to match the hostname on the mirrors list. Thanks, Julien On Tue, Apr 05, 2022 at 03:07:45PM +, NYCU CSIT wrote: > Package: mirrors > Severity: minor > User: mirr...@packages.debian.org > Usertags: mirror-list > > Submission-Type: update > Site: debian.cs.nctu.edu.tw > Type: leaf > Archive-architecture: ALL amd64 arm64 armel armhf hurd-i386 i386 > kfreebsd-amd64 kfreebsd-i386 mips mips64el mipsel powerpc ppc64el s390x > Archive-http: /debian/ > Archive-rsync: debian/ > Maintainer: NYCU CSIT > Country: TW Taiwan > Location: Asia Taiwan > Sponsor: IT Center, Department of Computer Science, National Yang Ming Chiao > Tung University https://it.cs.nycu.edu.tw/ > Comment: Hi, > we would like to change our mirror domain name and contact information due > to our school being merged with NYMU into NYCU (National Yang Ming Chiao Tung > University). > > The following is our new information, and we also have enabled https support > additionally: > http: http://debian.cs.nycu.edu.tw > https: https://debian.cs.nycu.edu.tw > rsync (debian): rsync://debian.cs.nycu.edu.tw/debian/ > > > > > Trace Url: http://debian.cs.nctu.edu.tw/debian/project/trace/ > Trace Url: > http://debian.cs.nctu.edu.tw/debian/project/trace/ftp-master.debian.org > Trace Url: > http://debian.cs.nctu.edu.tw/debian/project/trace/debian.cs.nctu.edu.tw >
Bug#1019434: sources.debian.org: 500 Something went wrong
On Fri, Sep 9, 2022 at 10:56:25 +0200, Jakub Wilk wrote: > Package: qa.debian.org > User: qa.debian@packages.debian.org > Usertags: debsources > > $ wget -nv https://sources.debian.org/src/nyancat/unstable/ > https://sources.debian.org/src/nyancat/unstable/: > 2022-09-09 10:55:39 ERROR 500: INTERNAL SERVER ERROR. > This was likely due to: Sep 8 23:45:07 danzi/danzi kernel: oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0,global_oom,task_memcg=/system.slice/system-postgresql.slice/postgresql@13-debsources.service,task=postgres,pid=2682646,uid=107 Sep 8 23:45:07 danzi/danzi kernel: Out of memory: Killed process 2682646 (postgres) total-vm:14563424kB, anon-rss:14125644kB, file-rss:0kB, shmem-rss:113964kB, UID:107 pgtables:28420kB oom_score_adj:0 We might have some tuning to do, and try to understand what's eating so much ram. Cheers, Julien
Bug#1018296: ftpsync: rsync 3.2.5-1 breaks ftpsync
On Sun, Aug 28, 2022 at 17:05:10 +0100, Chris Boot wrote: > Package: ftpsync > Version: 20180513+nmu1 > Severity: important > > Hi all, > > I discussed this a few days ago in #debian-ftp; I think the bug is > probably in rsync but ftpsync is how I ran across it. > > My mirror syncs against free.hands.com / ftp.uk.debian.org. With rsync > 3.2.5-1 my mirror fails to sync: stage1 executes fine but stage 2 fails > with the following error from rsync: > > ERROR: rejecting excluded file-list name: project > rsync error: protocol incompatibility (code 2) at flist.c(994) > [Receiver=3.2.5] > rsync error: protocol incompatibility (code 2) at io.c(1644) > [sender=3.2.3] > (from rsync-ftpsync.error.0) > On Fri, Sep 2, 2022 at 10:19:01 -0700, Lance Albertson wrote: > I have reported a similar bug to RedHat: > https://bugzilla.redhat.com/show_bug.cgi?id=2123815 > The RH bug points to https://github.com/WayneD/rsync/issues/356 which seems to confirm this is an rsync bug/regression. Hopefully it can be fixed soon; I see Samuel is active in the upstream issue. Cheers, Julien
Bug#1009741: mercurial: flaky autopkgtest which times out on amd64 regularly
On Fri, Sep 2, 2022 at 16:21:51 +0200, Paul Gevers wrote: > > > On 11-07-2022 15:14, Julien Cristau wrote: > > > > What are the specs of these hosts? > > > > > > We have m5a.large instances with Amazon: > > > https://aws.amazon.com/ec2/instance-types/m5/ > > > > > > M5a and M5ad instances feature AMD EPYC 7000 series processors with an all > > > core turbo clock speed of 2.5 GHz. The AMD-based instances provide > > > additional options for customers that do not fully utilize the compute > > > resources and can benefit from a cost savings of 10%. With M5ad instances, > > > local NVMe-based SSDs are physically connected to the host server and > > > provide block-level storage that is coupled to the lifetime of the > > > instance. > > > > > > vCPU Memory (GiB) Instance Storage (GB) Network Bandwidth (Gbps) > > > EBS > > > Bandwidth (Mbps) > > > 2 8EBS-Only Up to 10 Up to 2,880 > > > > > > > How long are tests allowed to take? > > > > > > 1 seconds, i.e. 2 hours and 47 minutes. > > > > > Hmm. Looking at > > https://ci.debian.net/packages/m/mercurial/unstable/amd64/ some of the > > runs seem to finish in under 10 minutes, others take over 2 hours (but > > end up passing anyway). Are all instances the same? Most of the "fast" > > runs seem to be on ci-worker13. > > As I mentioned in my original report, I noticed the same about the passing > tests and I said ci-worker13 is a completely different beast. All instances > *except* ci-worker13 are the same, the one I mentioned above. ci-worker13 is > an m3.large.x86 host at equinix: > https://metal.equinix.com/product/servers/m3-large/ > How fast is the storage on the aws hosts? It looks like EBS has a number of variations with different characteristics, and the hg testsuite is probably quite dependent on that. It might also be interesting to see how it does when running in a tmpfs (or at least with /tmp on a tmpfs). Cheers, Julien
Bug#919697: arcanist: file conflict with arc
On Fri, Sep 2, 2022 at 15:01:01 +0200, Sylvestre Ledru wrote: > Le 02/09/2022 à 13:18, Adrian Bunk a écrit : > > On Fri, Sep 02, 2022 at 12:12:06PM +0200, Christoph Biedl wrote: > > > Sylvestre Ledru wrote... > > > > > > > I don't think renaming is the right approach against an MS-DOS > > > > software (and I still think that Debian's policy is too binary for > > > > this). > > > > > > As there is a very small chance users would want to install *both* > > > packages, can't we just resolve this with a Breaks: on both sides, or > > > anything else that prevents co-installation from happening? > > > ... > > > > "Two different packages must not install programs with different > > functionality but with the same filenames."[1] > > > Yeah, but with that many packages in the archive, it makes less and less > sense ... > I would say it makes more and more sense, on the contrary, for the distribution to do this job to avoid arbitrary conflicts. Cheers, Julien
Bug#1009741: mercurial: flaky autopkgtest which times out on amd64 regularly
Hi Paul, On Tue, Jul 12, 2022 at 11:06:12 +0200, Paul Gevers wrote: > Hi Julien, > Please reply-all if you want me to see replies. > On 11-07-2022 15:14, Julien Cristau wrote: > > What are the specs of these hosts? > > We have m5a.large instances with Amazon: > https://aws.amazon.com/ec2/instance-types/m5/ > > M5a and M5ad instances feature AMD EPYC 7000 series processors with an all > core turbo clock speed of 2.5 GHz. The AMD-based instances provide > additional options for customers that do not fully utilize the compute > resources and can benefit from a cost savings of 10%. With M5ad instances, > local NVMe-based SSDs are physically connected to the host server and > provide block-level storage that is coupled to the lifetime of the instance. > > vCPU Memory (GiB) Instance Storage (GB) Network Bandwidth (Gbps) EBS > Bandwidth (Mbps) > 2 8EBS-Only Up to 10 Up to 2,880 > > > How long are tests allowed to take? > > 1 seconds, i.e. 2 hours and 47 minutes. > Hmm. Looking at https://ci.debian.net/packages/m/mercurial/unstable/amd64/ some of the runs seem to finish in under 10 minutes, others take over 2 hours (but end up passing anyway). Are all instances the same? Most of the "fast" runs seem to be on ci-worker13. Cheers, Julien
Bug#1014821: python3-hgapi: duplicates python-hglib functionality
On Fri, Aug 12, 2022 at 12:06:20AM +0100, Nick Morrott wrote: > On Tue, 12 Jul 2022 at 16:09, Julien Cristau wrote: > > > > I'm curious why python-hgapi exists when from its description it sounds > > like it's a clone of python-hglib which predates it (at least in the > > debian archive) by a number of years? > > Dear Julien, > > I seem to remember checking this when I was packaging the micro:bit > toolchain and finding their different approaches: > > - python-hgapi uses the Mercurial command line for its work > - python-hglib uses the internal Mercurial API for its work > That's not true, actually, python-hglib uses the hg command line, it doesn't use any mercurial internals. Cheers, Julien > python-hgapi was packaged solely as a dependency for yotta. Having > neither the experience with hg internally, nor the desire, I did not > got through the source to migrate from one to the other. > > Please let me know if you're happy to close the report. > > Cheers, > Nick >
Bug#1016408: nheko refuses to start because of unknown symbol
Control: reassign -1 libspdlog1 1:1.10.0+ds-0.1 Control: retitle -1 libspdlog1: ABI breakage without SONAME bump Control: severity -1 serious On Sun, Jul 31, 2022 at 10:32:48AM +0200, Stefan Pasteiner wrote: > Package: nheko > Version: 0.9.3+ds-1 > Severity: grave > Justification: renders package unusable > X-Debbugs-Cc: a...@pasteiner.eu > [...] > Versions of packages nheko depends on: [...] > ii libspdlog1 [libspdlog1-fmt8]1:1.10.0+ds-0.1 [...] > > nheko just prints nheko: symbol lookup error: nheko: undefined symbol: > _ZN6spdlog5sinks18rotating_file_sinkISt5mutexEC1ENSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEmmb > > according to https://github.com/Nheko-Reborn/nheko/issues/362 rebuilding > could solve the problem. That symbol was exported by libspdlog.so.1 in 1:1.8.1+ds-2.1 but is missing in 1:1.10.0+ds-0.1, so the bug belongs in that package; reassigning. Cheers, Julien
Bug#1015887: debian-installer: Adding https repo doesn't work without manually installing ca-certificates
On Sat, Jul 23, 2022 at 03:49:55PM +1200, Richard Hector wrote: > Package: debian-installer > Severity: important > > Dear Maintainer, > > Using netinst bullseye 11.4 installer: > > https://cdimage.debian.org/debian-cd/current/amd64/iso-cd/debian-11.4.0-amd64-netinst.iso > > I chose to add a network mirror, using https, and the default > 'deb.debian.org'. > > I used (non-graphical) Expert Mode. > > The problem first showed up when tasksel only displayed 'standard system > utilities'. When I went ahead with that, the next screen was a red > 'Installation step failed' screen. > > The log on tty4 showed various dependency problems. > > I tried to 'chroot /target' and 'apt update', which showed certificate > problems. I then ran 'apt install ca-certificates', which worked > (installing from the cd image?), after which 'apt update' worked, and I > was also able to continue successfully with the installer. > > I was able to reproduce this in a (kvm/qemu) VM (which is where I > confirmed my steps); the original problem was on an HP Thin Client > (t520). In both cases only 8G of storage was available. > > It all works fine using http for the mirror. > > I'm happy to do further testing with the VM; the thin client is less > convenient as it has a job to do. > Please attach syslog from the installer. Cheers, Julien
Bug#1014821: python3-hgapi: duplicates python-hglib functionality
Package: python3-hgapi Severity: normal Hi, I'm curious why python-hgapi exists when from its description it sounds like it's a clone of python-hglib which predates it (at least in the debian archive) by a number of years? Thanks, Julien
Bug#1014817: mercurial: broken fsmonitor extension in 6.2
Package: mercurial Version: 6.2-1 Severity: serious Tags: upstream Upstream commit be9bf75a837c looks like it broke the fsmonitor extension: > File "/usr/lib/python3/dist-packages/hgext/fsmonitor/__init__.py", line > 338, in > if e._v1_state() != b"n" or e._v1_mtime() == -1 > AttributeError: 'dirstate_tuple' object has no attribute '_v1_state' Cheers, Julien
Bug#1014806: tortoisehg: uninstallable with mercurial 6.2
Source: tortoisehg Version: 6.1.1-3 Severity: serious I uploaded mercurial 6.2-1 to sid yesterday, making thg uninstallable. Cheers, Julien
Bug#1009741: mercurial: flaky autopkgtest which times out on amd64 regularly
On Mon, May 16, 2022 at 09:08:45PM +0200, Paul Gevers wrote: > Hi Julien, > > On 16-05-2022 14:10, Julien Cristau wrote: > > Control: severity -1 normal > > > > On Fri, Apr 15, 2022 at 10:36:54PM +0200, Paul Gevers wrote: > > > I looked at the results of the autopkgtest of you package because it was > > > showing up as a regression for the upload of python3-defaults. I noticed > > > that the test regularly fails on several architectures. Most peculiarly on > > > amd64, the latest version seems to pass on ci-worker13 (our most powerful > > > host looking at number of cores, memory and disk space) and fails > > > (timeout) > > > on the other amd64 hosts. What are the specs of these hosts? How long are tests allowed to take? > > > Because the unstable-to-testing migration software now blocks on > > > regressions in testing, flaky tests, i.e. tests that flip between > > > passing and failing without changes to the list of installed packages, > > > are causing people unrelated to your package to spend time on these > > > tests. > > > > > Which specific tests are you having issues with? > > It seems not at all specific: > > E.g. > https://ci.debian.net/data/autopkgtest/testing/amd64/m/mercurial/21333636/log.gz > ends with: > test-encode.t > test-encode.t ... # Test test-encode.t > # Running sh "/tmp/hgtests.qsr01vxk/child797/test-encode.t.sh" > # Timout reached for process 98896 > > https://ci.debian.net/data/autopkgtest/testing/amd64/m/mercurial/21329273/log.gz > ends with: > test-share-bookmarks.t#vfs#normal > test-share-bookmarks.t#vfs#normal ... # Test > test-share-bookmarks.t#vfs#normal > # Timout reached for process 77193 > # Running sh > "/tmp/hgtests.f1fx8cv7/child370/test-share-bookmarks.t-vfs-normal.sh" > > https://ci.debian.net/data/autopkgtest/testing/amd64/m/mercurial/20890959/log.gz > ends with: > test-debugbackupbundle.t > test-debugbackupbundle.t ... # Test test-debugbackupbundle.t > # Running sh "/tmp/hgtests.d5oe121c/child855/test-debugbackupbundle.t.sh" > # Timout reached for process 100461 > > https://ci.debian.net/data/autopkgtest/testing/amd64/m/mercurial/20858105/log.gz > ends with: > test-status.t#dirstate-v1 > test-status.t#dirstate-v1 ... # Test test-status.t#dirstate-v1 > # Timout reached for process 56796 > # Running sh "/tmp/hgtests.p1egbody/child227/test-status.t-dirstate-v1.sh" > AFAICT the above are expected messages, and not errors. When autopkgtest itself errors out with "ERROR: timed out on command ..." it would probably be useful if it showed which processes were running at the time it gave up so it's maybe a bit easier to tell what got stuck. > https://ci.debian.net/data/autopkgtest/testing/amd64/m/mercurial/20816570/log.gz > ends with: > Failed test-hghave.t: output changed > Failed test-hgrc.t: output changed > Failed test-https.t: output changed > Failed test-parseindex.t: output changed > Failed test-patchbomb-tls.t: output changed > Failed test-paths.t: output changed > Failed test-run-tests.t: output changed > # Ran 918 tests, 47 skipped, 7 failed. > python hash seed: 1267217074 > # Timout reached for process 101372 > # Cleaning up HGTMP /tmp/hgtests.fo156zei > make: *** [Makefile:140: tests] Error 1 > > https://ci.debian.net/data/autopkgtest/testing/arm64/m/mercurial/21443035/log.gz > ends with > Failed test-convert-bzr.t: output changed > # Ran 918 tests, 47 skipped, 1 failed. > python hash seed: 2382336912 > # Timout reached for process 101344 > # Cleaning up HGTMP /tmp/hgtests.a0d42699 > make: *** [Makefile:140: tests] Error 1 These two are actual test failures, not timeouts. The first set were fixed in 6.1.2-1; I'm not familiar with the test-convert-bzr.t failure, could be a race condition in the test. Either way, it's unrelated to the "timeouts" issue. Cheers, Julien
Bug#1013634: opensc: infinite loop in card_detect when unplugging yubikey
Package: opensc Version: 0.22.0-2+b1 Severity: important Hi, I recently started seeing firefox's socket thread go in an infinite loop after unplugging my yubikey (not all the time, maybe once a week or so). I initially reported the bug to Mozilla at https://bugzilla.mozilla.org/show_bug.cgi?id=1769942 but AFAICT from more debugging it actually comes from opensc: card_detect never finishes, it keeps calling sc_detect_card_presence in a loop here: https://github.com/OpenSC/OpenSC/blob/0.22.0/src/pkcs11/slot.c#L220 Per https://bugzilla.mozilla.org/show_bug.cgi?id=1769942#c6, this commit may be relevant: https://github.com/OpenSC/OpenSC/commit/738588fd2b1c69794ba9ebe7bdb898486e001ecb Cheers, Julien -- System Information: Debian Release: bookworm/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'testing'), (101, 'unstable-debug'), (101, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.17.0-1-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages opensc depends on: ii libc6 2.33-7 ii libreadline8 8.1.2-1.2 ii libssl33.0.3-7 ii opensc-pkcs11 0.22.0-2+b1 ii zlib1g 1:1.2.11.dfsg-4 Versions of packages opensc recommends: ii pcscd 1.9.8-1 opensc suggests no packages. -- no debconf information
Bug#1013341: /usr/bin/ld.bfd: warning: /usr/lib/crt0-efi-x86_64.o: missing .note.GNU-stack section implies executable stack
On Wed, Jun 22, 2022 at 10:50:48AM +0200, Michael Biebl wrote: > Package: gnu-efi > Version: 3.0.13+git20210716.269ef9d-2 > Severity: serious > Forwarded: https://sourceforge.net/p/gnu-efi/bugs/28/ > > Hi, > > since the latest update of binutils to 2.38.50.20220615, > the systemd source package fails to build: > > ``` > $ ninja -C build/ > ninja: Entering directory `build/' > [72/2108] Generating src/boot/efi/linuxx64.elf.stub with a custom command > FAILED: src/boot/efi/linuxx64.elf.stub > /usr/bin/cc -o src/boot/efi/linuxx64.elf.stub -DGNU_EFI_USE_MS_ABI -DSD_BOOT > -ffreestanding -fshort-wchar -fvisibility=hidden -I > /home/michael/git/systemd/src/fundamental -I > /home/michael/git/systemd/src/boot/efi -include src/boot/efi/efi_config.h > -include version.h -isystem /usr/include/efi/x86_64 -isystem /usr/include/efi > -std=gnu11 -Wall -Wextra -Wno-format-signedness > -Wno-missing-field-initializers -Wno-unused-parameter -Wdate-time > -Wendif-labels -Werror=format=2 -Werror=implicit-function-declaration > -Werror=incompatible-pointer-types -Werror=int-conversion -Werror=overflow > -Werror=override-init -Werror=return-type -Werror=shift-count-overflow > -Werror=shift-overflow=2 -Werror=undef -Wfloat-equal -Wimplicit-fallthrough=5 > -Winit-self -Wlogical-op -Wmissing-include-dirs -Wmissing-noreturn > -Wnested-externs -Wold-style-definition -Wpointer-arith -Wredundant-decls > -Wshadow -Wstrict-aliasing=2 -Wstrict-prototypes -Wsuggest-attribute=noreturn > -Wunused-function -Wwrite-strings -Wno-unused-result -fno-stack-protector > -fno-strict-aliasing -fpic -fwide-exec-charset=UCS2 -mno-red-zone -mno-sse > -mno-mmx -ggdb -DEFI_DEBUG -fuse-ld=bfd -L /usr/lib -nostdlib -T > /usr/lib/elf_x86_64_efi.lds -Wl,--build-id=sha1 -Wl,--fatal-warnings > -Wl,--no-undefined -Wl,--warn-common -Wl,-Bsymbolic -z nocombreloc > /usr/lib/crt0-efi-x86_64.o -pie -Wl,--no-dynamic-linker > src/boot/efi/bootspec-fundamental.c.o src/boot/efi/efivars-fundamental.c.o > src/boot/efi/sha256.c.o src/boot/efi/string-util-fundamental.c.o > src/boot/efi/assert.c.o src/boot/efi/devicetree.c.o src/boot/efi/disk.c.o > src/boot/efi/efi-string.c.o src/boot/efi/graphics.c.o src/boot/efi/initrd.c.o > src/boot/efi/measure.c.o src/boot/efi/pe.c.o src/boot/efi/secure-boot.c.o > src/boot/efi/ticks.c.o src/boot/efi/util.c.o src/boot/efi/cpio.c.o > src/boot/efi/splash.c.o src/boot/efi/stub.c.o src/boot/efi/linux_x86.c.o > -lefi -lgnuefi -lgcc > /usr/bin/ld.bfd: warning: /usr/lib/crt0-efi-x86_64.o: missing .note.GNU-stack > section implies executable stack > /usr/bin/ld.bfd: NOTE: This behaviour is deprecated and will be removed in a > future version of the linker > collect2: error: ld returned 1 exit status > [77/2108] Generating catalog/systemd.ru.catalog with a custom command > (wrapped by meson to capture output) > ninja: build stopped: subcommand failed. > ``` > > I originally raised this at systemd upstream [1], but it was mentioned > there, that this might actually be a gnu-efi issue. > [1] also contains links to the relevant changes in binutils which now > trigger this warning. > > Marking as RC, as it causes a FTBFS > Not using -Wl,--fatal-warnings might be a workaround for systemd until gnu-efi fixes this? Cheers, Julien
Bug#1012609: schroot: FTBFS on arch:all, cannot find ".../debian/build/po/cs.gmo": No such file or directory
Source: schroot Version: 1.6.10-14 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) https://buildd.debian.org/status/fetch.php?pkg=schroot&arch=all&ver=1.6.10-14&stamp=1654764990&raw=0 > make[3]: Entering directory '/<>/debian/build/po' > cd /<>/debian/build && /usr/bin/cmake -S/<> > -B/<>/debian/build --check-build-system > CMakeFiles/Makefile.cmake 0 > cd /<>/debian/build && /usr/bin/make -f CMakeFiles/Makefile2 > po/preinstall > make[4]: Entering directory '/<>/debian/build' > make[4]: Nothing to be done for 'po/preinstall'. > make[4]: Leaving directory '/<>/debian/build' > Install the project... > /usr/bin/cmake -P cmake_install.cmake > -- Install configuration: "None" > CMake Error at cmake_install.cmake:54 (file): > file INSTALL cannot find > "/<>/debian/build/po/cs.gmo": No such file > or directory. > > > make[3]: *** [Makefile:113: install] Error 1 > make[3]: Leaving directory '/<>/debian/build/po' Cheers, Julien
Bug#1012174: Inconsistent advice wrt security archive
On Tue, May 31, 2022 at 02:26:39PM +0200, David Prévot wrote: > Package: www.debian.org,release-notes > Severity: normal > X-Debbugs-Cc: t...@security.debian.org > > Hi teams, > > The [errata] advises one to use > > deb http://security.debian.org/debian-security bullseye-security main > contrib non-free > > while the [release-notes] advises > > deb https://deb.debian.org/debian-security bullseye-security main contrib > > Even if both will have the same result (the last time a non-free package > was uploaded to the security archive may have been during Etch), having > two different official advice makes it difficult in some situation > (“what should we actually use?”). Is the use of HTTPS via deb.d.o > preferable over HTTP via security.d.o? If so maybe the errata should be > updated, if it’s the other way around, the realease-notes should be > updated. > > errata: https://www.debian.org/releases/stable/errata#security > release-notes: > https://www.debian.org/releases/stable/amd64/release-notes/ch-information#security-archive > The release-notes version is preferred, as far as scheme and hostname. I don't have a particular opinion (and definitely not an authoritative one) on listing non-free, but there's precedent of shipping intel-microcode updates via the security archive, much more recently than etch. Cheers, Julien
Bug#1011227: xserver-xorg-video-vesa: open /dev/dri/card0: No such file or directory
On Wed, May 18, 2022 at 05:37:32PM +0300, Martin-Éric Racine wrote: > On Wed, May 18, 2022 at 5:03 PM Julien Cristau wrote: > > On Wed, May 18, 2022 at 04:52:01PM +0300, Martin-Éric Racine wrote: > > > xf86-video-vesa fails to lauch on a VESA-capable host. Logs attached. > > > > > Please include kernel logs, and contents of /proc/fb. > > $ cat /proc/fb > 0 VESA VGA > > Output of dmesg attached. > So you're using vesafb in the kernel, that's not compatible with the vesa Xorg driver, you have to pick one. Another question is why the fbdev Xorg driver fails to init, so you can try debugging that. Cheers, Julien
Bug#1011227: xserver-xorg-video-vesa: open /dev/dri/card0: No such file or directory
Control: severity -1 normal Control: tag -1 moreinfo On Wed, May 18, 2022 at 04:52:01PM +0300, Martin-Éric Racine wrote: > xf86-video-vesa fails to lauch on a VESA-capable host. Logs attached. > Please include kernel logs, and contents of /proc/fb. Cheers, Julien
Bug#1011076: libssl3,mercurial: can't connect to server created with `openssl s_server -tls1`
Package: libssl3,mercurial Severity: normal X-Debbugs-Cc: jcris...@debian.org Hi, mercurial's test suite no longer passes in sid, with: > --- /<>/tests/test-https.t > +++ /<>/tests/test-https.t.err > @@ -362,9 +362,11 @@ > Clients talking same TLS versions work > >$ P="$CERTSDIR" hg --config hostsecurity.minimumprotocol=tls1.0 --config > hostsecurity.ciphers=DEFAULT id https://localhost:$HGPORT/ > - 5fed3813f7f5 > + abort: error: [SSL: TLSV1_ALERT_INTERNAL_ERROR] tlsv1 alert internal error > (_ssl.c:997) > + [100] >$ P="$CERTSDIR" hg --config hostsecurity.minimumprotocol=tls1.1 --config > hostsecurity.ciphers=DEFAULT id https://localhost:$HGPORT1/ > - 5fed3813f7f5 > + abort: error: [SSL: TLSV1_ALERT_INTERNAL_ERROR] tlsv1 alert internal error > (_ssl.c:997) > + [100] >$ P="$CERTSDIR" hg --config hostsecurity.minimumprotocol=tls1.2 id > https://localhost:$HGPORT2/ >5fed3813f7f5 > > @@ -399,8 +401,8 @@ > --insecure will allow TLS 1.0 connections and override configs > >$ hg --config hostsecurity.minimumprotocol=tls1.2 id --insecure > https://localhost:$HGPORT1/ > - warning: connection security to localhost is disabled per current > settings; communication is susceptible to eavesdropping and tampering > - 5fed3813f7f5 > + abort: error: [SSL: TLSV1_ALERT_INTERNAL_ERROR] tlsv1 alert internal error > (_ssl.c:997) > + [100] > > The per-host config option overrides the default > > @@ -408,7 +410,8 @@ >> --config hostsecurity.ciphers=DEFAULT \ >> --config hostsecurity.minimumprotocol=tls1.2 \ >> --config hostsecurity.localhost:minimumprotocol=tls1.0 > - 5fed3813f7f5 > + abort: error: [SSL: TLSV1_ALERT_INTERNAL_ERROR] tlsv1 alert internal error > (_ssl.c:997) > + [100] > > The per-host config option by itself works > > > ERROR: test-https.t output changed The failures happen in parts of the test that spin up and attempt to connect to a TLS1.0 or TLS1.1 server. It used to pass on 1.1.1n and (I think) 1.1.1o. Trying to replicate with openssl's cmdline tools, e.g.: openssl s_server -cert tests/sslcerts/pub.pem -key tests/sslcerts/priv.pem -tls1 and openssl s_client -connect localhost:4433 -tls1 The server reports: 4084745F427F:error:0A76:SSL routines:tls_choose_sigalg:no suitable signature algorithm:../ssl/t1_lib.c:3331: Talking with Sebastian on IRC he suggested some extra -cipher / -provider command line options which didn't seem to make a difference. I guess I have two questions: - is this a bug or an intended change? - if it's intended, is there a way to allow these connections again? Thanks, Julien
Bug#1009741: mercurial: flaky autopkgtest which times out on amd64 regularly
Control: severity -1 normal On Fri, Apr 15, 2022 at 10:36:54PM +0200, Paul Gevers wrote: > I looked at the results of the autopkgtest of you package because it was > showing up as a regression for the upload of python3-defaults. I noticed > that the test regularly fails on several architectures. Most peculiarly on > amd64, the latest version seems to pass on ci-worker13 (our most powerful > host looking at number of cores, memory and disk space) and fails (timeout) > on the other amd64 hosts. > > Because the unstable-to-testing migration software now blocks on > regressions in testing, flaky tests, i.e. tests that flip between > passing and failing without changes to the list of installed packages, > are causing people unrelated to your package to spend time on these > tests. > Which specific tests are you having issues with? Cheers, Julien
Bug#1010314: ca-certificates: Executable search ordering for OpenSSL?
Control: tag -1 moreinfo unreproducible On Thu, Apr 28, 2022 at 12:38:28PM -0400, S. Egbert wrote: > A group of auditors were reviewing the CA inclusion process I.. don't know what the above means. > and have examined the `update-ca-certificates` and its code. > > This issue is not about the PKI nor its certificate handling. > > One auditor noticed that the ordering of looking for OpenSSL > executable file (`openssl`) seems ... counterintuitive? > > I would imagine that the correct ordering for searching this `openssl` > executable file be something like: > > 1. /usr/local/sbin/openssl > 2. /usr/local/bin/openssl > 3. /usr/sbin/openssl > 4. /usr/bin/openssl > > > The actually and current order by the latest `update-ca-certificates` > in looking for this `openssl` exectuable is currently: > > 1. $CWD/openssl > 2. /usr/local/bin/openssl > 3. /usr/local/sbin/openssl > 4. /usr/bin/openssl > 5. /usr/sbin/openssl > > Please note the inversal of `sbin` and `bin`. (The ordering of > `/usr`/`/usr/local` complies with FSSTD v2.3). > update-ca-certificates doesn't specify a path for openssl, it relies on $PATH being set, like most things. I don't see a bug here. Cheers, Julien
Bug#1010161: x11-xkb-utils-udeb: broken setxkbmap within the installer
Control: tag -1 upstream patch Control: forwarded -1 https://gitlab.freedesktop.org/xorg/app/setxkbmap/-/merge_requests/4 On Mon, Apr 25, 2022 at 03:44:59PM +0200, Cyril Brulebois wrote: > And thanks again for the quick turnaround for the libxrandr2 udeb > addition. The next issue is is_xwayland() erroring out at runtime, with > BadRROutput on the RRGetOutputInfo call. This breaks setxkbmap in the > installer, and prevents the graphical installer from going further than > 2 steps. > Fixed with the above MR. Cheers, Julien
Bug#1010160: x11-xkb-utils: setxkbmap -layout cz_qwerty loads layout which fails with a particular dead-key combination
Control: reassign -1 xkeyboard-config Control: tag -1 upstream On Mon, Apr 25, 2022 at 03:53:22PM +0200, Pavel Sanda wrote: > for keyboard configuration I use the following command on my system: > setxkbmap -model pc105 -layout "us,cz_qwerty" -option "grp:alt_shift_toggle" > > The cz_qwerty layout works mostly fine, except one singular failure: > dead-key ˇ (caron) + u (the same for upper-case variant ˇ+U). > > I am afraid non-native prepared/"fixed" this layout, because the layout > logically ends up with caron+u, which is non-existent in czech while > on all czech keyboards you end up with overring+u (ů, see > https://en.wikipedia.org/wiki/Ring_(diacritic) ). > > It renders this layout unusable for continuous czech writing, can it get > fixed? > (Or at leat can you give me a hint where to fix this, I expect this could > be two-liner change in some kayboard-layout files...) > The cz_qwerty layout is defined here: https://gitlab.freedesktop.org/xkeyboard-config/xkeyboard-config/-/blob/ade97960d7bfc7fde8d08e9fa5584e7c3c51c23b/symbols/cz#L81 Key combinations including those with dead keys live in Xlib though: https://gitlab.freedesktop.org/xorg/lib/libx11/-/blob/master/nls/en_US.UTF-8/Compose.pre Reassigning to xkeyboard-config for now, let us know if you end up reporting/fixing this upstream. Cheers, Julien
Bug#1004924: xkb: Alt key ceased working after last update
Control: tag -1 moreinfo On Thu, Feb 03, 2022 at 11:26:16AM -0600, Carlos wrote: > >* What led up to the situation? > updating packages with apt >* What exactly did you do (or not do) that was effective (or > ineffective)? > press key combinations that involve Alt keys. For example: Alt + . used > to produce a middle dot, and I have a shortcut defined with Super+Alt+T, > which opens thunderbird. The most simple possible test I could imagine was > opening xev, and pressing different keys. The only one I could find not > working are Alt keys (no events are produced). >* What was the outcome of this action? > No keypress events are produced with the alt keys >* What outcome did you expect instead? > Keypress events should be produced when pressing Alt keys. > Hi, Please share more information about your system, desktop environment, setup, config, relevant logs. Also, after which specific update did the problem start, and can you pin down which exact package caused it (e.g. by downgrading individual packages that were part of that update)? Cheers, Julien
Bug#1009872: dovecot-core: postinst fails when snakeoil cert is removed
Package: dovecot-core Version: 1:2.3.13+dfsg1-2 Severity: serious X-Debbugs-Cc: jcris...@debian.org This bit of dovecot-core.postinst breaks (at least on the second invocation) if the snakeoil cert or key don't exist: test -e returns false, but ln -s fails because the symlink is already there: # SSL configuration # Use the ssl-cert-snakeoil certificate in the following cases: # - On new installations # - On upgrades from versions that did not enable SSL by default if [ -z "$2" ] || dpkg --compare-versions "$2" lt "1:2.2.31-1~"; then if [ ! -e /etc/dovecot/private/dovecot.key ] && \ [ ! -e /etc/dovecot/private/dovecot.pem ]; then ln -s /etc/ssl/certs/ssl-cert-snakeoil.pem /etc/dovecot/private/dovecot.pem ln -s /etc/ssl/private/ssl-cert-snakeoil.key /etc/dovecot/private/dovecot.key fi fi Cheers, Julien
Bug#1009189: python3.10: please build with --with-ssl-default-suites=openssl
Package: python3.10 Version: 3.10.4-1 Severity: normal X-Debbugs-Cc: jcris...@debian.org Hi, Apparently python3.10 has its own ideas of cipher suites to use, overriding openssl defaults, local admin configuration in /etc/ssl/openssl.cnf, and user configuration through OPENSSL_CONF. That seems like a bad behaviour. IMO the local config should be respected, and if a stricter default for debian is desired then the proper place to set that is the openssl package, not individual language bindings. Thanks, Julien
Bug#1008747: mercurial: FTBFS with Python 3.10 as default
Control: tag -1 upstream On Thu, Mar 31, 2022 at 07:27:51PM +0200, Graham Inggs wrote: > As can be seen on reproducible builds [1], mercurial FTBFS with Python > 3.10 as the default version. I've copied what I hope is the relevant > part of the log below. > > This appears to be due to the following appearing in the output of some tests: > > DeprecationWarning: The distutils package is deprecated and slated for > removal in Python 3.12. > That's one of them, but there's a bunch more :( Working on it... Cheers, Julien > [1] https://tests.reproducible-builds.org/debian/rb-pkg/mercurial.html > > > Failed test-hghave.t: output changed > Failed test-https.t: output changed > Failed test-parseindex.t: output changed > Failed test-patchbomb-tls.t: output changed > Failed test-run-tests.t: output changed > # Ran 885 tests, 80 skipped, 5 failed.
Bug#1006113: mirror submission for mirror.lostpacket.org
Hi, http://mirror.lostpacket.org/debian/project/trace/ is empty. Please use our ftpsync script to mirror Debian. It should produce the trace files we require, and do the mirroring in a way that ensures the mirror is in a consistent state even during updates. https://deb.debian.org/debian/project/ftpsync/ftpsync-current.tar.gz Cheers, Julien On Sun, Mar 27, 2022 at 06:28:06PM -0500, mirror...@lostpacket.org wrote: > Should be good at this time. > > Thank you, > > Grant > > On 2022-03-24 11:31, Julien Cristau wrote: > > Hi, > > > > mirror.lostpacket.org seems unreachable for me right now. > > > > Feel free to resubmit later. > > > > Cheers, > > Julien > > > > On Sat, Feb 19, 2022 at 11:27:01AM +, Grant Brooks wrote: > > > Package: mirrors > > > Severity: wishlist > > > User: mirr...@packages.debian.org > > > Usertags: mirror-submission > > > > > > Submission-Type: new > > > Site: mirror.lostpacket.org > > > Type: leaf > > > Archive-architecture: ALL amd64 arm64 armel armhf hurd-i386 i386 > > > kfreebsd-amd64 kfreebsd-i386 mips mips64el mipsel powerpc ppc64el > > > s390x > > > Archive-http: /debian/ > > > Maintainer: Grant Brooks > > > Country: US United States > > > Location: Kansas City, Missouri > > > > > > > > > > > > > > > Trace Url: http://mirror.lostpacket.org/debian/project/trace/ > > > Trace Url: > > > http://mirror.lostpacket.org/debian/project/trace/ftp-master.debian.org > > > Trace Url: > > > http://mirror.lostpacket.org/debian/project/trace/mirror.lostpacket.org > > > >
Bug#1006504: bullseye-pu: package bash/5.1-6~deb11u1
Control: tag -1 confirmed On Sun, Mar 27, 2022 at 09:04:03PM +0200, Salvatore Bonaccorso wrote: > Okay attached the alternative, and only cherry-pick the 014 patch > upstream to address #1003012. Would that be acceptable instead? > That's fine, thanks. Cheers, Julien
