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#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=armel=23.3.3-1=1705055313=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=armel=23.3.3-1=1705055313=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#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#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#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#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#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=ign=7=7=only=ftbfs-20221220=lu...@debian.org=1=1=1=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#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#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#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#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=all=1.6.10-14=1654764990=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#1011076: marked as pending in mercurial
Control: tag -1 pending Hello, Bug #1011076 in mercurial reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/python-team/packages/mercurial/-/commit/8adcdc9fa53367961c8c0a736729d5e74cda0dac Fix test failures with openssl 3 Closes: #1011076 (this message was generated automatically) -- Greetings https://bugs.debian.org/1011076
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#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#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#1008747: marked as pending in mercurial
Control: tag -1 pending Hello, Bug #1008747 in mercurial reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/python-team/packages/mercurial/-/commit/1c6fb697d9790c0a5d0d7b9b1cf54a300f17c780 Fix test failures with python 3.10 (closes: #1008747). (this message was generated automatically) -- Greetings https://bugs.debian.org/1008747
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#1006383: mercurial: autopkgtest needs update for new version of pygments: output changed
Control: fixed -1 6.1-1 On Sat, Mar 26, 2022 at 10:34:40PM +0100, Paul Gevers wrote: > Version: 6.1-4 > > Hi, > > On Thu, 24 Feb 2022 19:27:56 +0100 Paul Gevers wrote: > > With a recent upload of pygments the autopkgtest of mercurial fails in > > testing when that autopkgtest is run with the binary packages of > > pygments from unstable. > > Apparently this has been fixed with the last upload. > Fixed by https://www.mercurial-scm.org/repo/hg/rev/21c0ae0693bc
Bug#1005930: nvidia-graphics-drivers-tesla-418: incompatible with xorg-server video ABI 25
Control: clone -1 -2 -3 -4 Control: reassign -2 xserver-xorg-video-nvidia-tesla-450 450.172.01-1 Control: retitle -2 nvidia-graphics-drivers-tesla-450: incompatible with xorg-server video ABI 25 Control: reassign -3 xserver-xorg-video-nvidia-tesla-460 460.106.00-1 Control: retitle -3 nvidia-graphics-drivers-tesla-460: incompatible with xorg-server video ABI 25 Control: reassign -4 xserver-xorg-video-nvidia-tesla-470 470.103.01-1 Control: retitle -4 nvidia-graphics-drivers-tesla-470: incompatible with xorg-server video ABI 25 Same issue for the other tesla driver versions. On Thu, Feb 17, 2022 at 02:56:03PM +0100, Julien Cristau wrote: > Source: nvidia-graphics-drivers-tesla-418 > Version: 418.226.00-1 > Severity: serious > > xorg-server's video ABI was recently bumped, and > nvidia-graphics-drivers-tesla-418 only declares compatibility for up to > v24. > > Cheers, > Julien
Bug#1005930: nvidia-graphics-drivers-tesla-418: incompatible with xorg-server video ABI 25
Source: nvidia-graphics-drivers-tesla-418 Version: 418.226.00-1 Severity: serious xorg-server's video ABI was recently bumped, and nvidia-graphics-drivers-tesla-418 only declares compatibility for up to v24. Cheers, Julien
Bug#1004662: prosody: postinst keeps messing with snakeoil certs
Package: prosody
Version: 0.11.13-1
Severity: serious
Control: found -1 0.11.9-2+deb11u2
X-Debbugs-Cc: jcris...@debian.org
prosody's postinst seems to insist on creating
/etc/prosody/certs/localhost.{crt,key}, but does this in a fragile way.
They're created as symlinks, but the call to ln is guarded by "test -e",
which doesn't actually test for the existence of a symlink, and returns
false if the symlink exists but is dangling.
It seems to me these links should only be created on first install, if
anything, and not re-created at each postinst invocation, especially if
the actual configuration doesn't use it.
The recent security updates resulted in:
> Setting up prosody (0.11.9-2+deb11u2) ...
> ln: failed to create symbolic link '/etc/prosody/certs/localhost.crt': File
> exists
> dpkg: error processing package prosody (--configure):
> installed prosody package post-installation script subprocess returned error
> exit status 1
until I went and manually deleted the dangling symlinks.
Cheers,
Julien
Bug#996048: [Pkg-openssl-devel] Bug#996048: postfix-mta-sts-resolver: autopkgtest doesn't handle new version of ca-certificates nicely: rehash: warning: skipping ca-certificates.crt, it does not conta
Control: reassign -1 postfix-mta-sts-resolver On Mon, Nov 08, 2021 at 03:57:00PM +0200, Adrian Bunk wrote: > On Tue, Oct 19, 2021 at 09:13:56AM +0200, Julien Cristau wrote: > > On Mon, Oct 18, 2021 at 11:05:14PM +0200, Kurt Roeckx wrote: > > > On Mon, Oct 18, 2021 at 10:40:59PM +0200, Julien Cristau wrote: > > > > On Mon, Oct 18, 2021 at 02:50:50PM +0200, Benjamin Hof wrote: > > > > > Hi, > > > > > > > > > > I think the following change might be the relevant one: > > > > > > > > > > --- a/update-ca-certificates > > > > > +++ b/update-ca-certificates > > > > > @@ -164,8 +164,6 @@ > > > > >done > > > > > fi > > > > > > > > > > -rm -f "$CERTBUNDLE" > > > > > - > > > > > ADDED_CNT=$(wc -l < "$ADDED") > > > > > REMOVED_CNT=$(wc -l < "$REMOVED") > > > > > > > > > > It triggers this stderr output during openssl rehash (l. 184): > > > > > > > > > > rehash: warning: skipping ca-certificates.crt,it does not contain > > > > > exactly one certificate or CRL > > > > > > > > > Ah, that makes sense. Annoying... > > > > > > > > Kurt/Sebastian, do you think there's a chance openssl rehash could grow > > > > some sort of ignore option so update-ca-certificates could ask it to > > > > skip ca-certificates.crt, to avoid spitting out a warning for it? > > > > > > As in rehash all files in that directory, excluding a file? I > > > guess that's an option. I guess it's not an option to move the > > > file to a different location. > > > > > Exactly. /etc/ssl/certs/ca-certificates.crt is the package's main > > "interface" so I suspect it'd be quite painful to move. Likewise moving > > the certs and hash symlinks themselves would break packages/scripts > > looking them up that way. > > > > The other option for me would be to revert the fix for bug #920348. > > In any case, there is nothing happening here specific to > postfix-mta-sts-resolver, the same problem would happen with > any other package that does not permit stderr output in the > autopkgtest when upgrading ca-certificates is tested. > > The failing part of the autopkgtest is a testing->unstable upgrade of > ca-certificates. > > Any objections to reassigning this to ca-certificates? > After thinking about this a bit more I think ca-certificates is doing the right thing here, and permitting this stderr output is a reasonable workaround for affected packages until we can avoid the warning with an openssl change. Cheers, Julien
Bug#1003171: calibre: Calibre version used in debian stable does not start
Control: tag -1 moreinfo Control: severity -1 normal On Wed, Jan 05, 2022 at 04:34:34PM +0100, Georges Gouriten wrote: > File "/usr/lib/calibre/calibre/devices/smart_device_app/driver.py", line > 2044, in > from zeroconf import (BadTypeInNameException, _HAS_A_TO_Z, > ImportError: cannot import name '_HAS_A_TO_Z' from 'zeroconf' > (/usr/local/lib/python3.9/dist-packages/zeroconf/__init__.py) > You've got a zeroconf python package installed in /usr/local, outside the Debian package management, overriding the packaged version, and breaking things. Cheers, Julien
Bug#998706: git breaks mercurial autopkgtest: Failed test-convert-git.t: output changed
Control: reassign -1 mercurial 5.9.3-1 Control: close -1 mercurial/6.0~rc0-1 On Sat, Nov 06, 2021 at 09:57:34PM +0100, Paul Gevers wrote: > Source: git, mercurial > Control: found -1 git/1:2.33.1-1 > Control: found -1 mercurial/5.9.3-1 > Severity: serious > Tags: sid bookworm > X-Debbugs-CC: debian...@lists.debian.org > User: debian...@lists.debian.org > Usertags: breaks needs-update > > Dear maintainer(s), > > With a recent upload of git the autopkgtest of mercurial fails in > testing when that autopkgtest is run with the binary packages of git > from unstable. It passes when run with only packages from testing. In > tabular form: > >passfail > gitfrom testing1:2.33.1-1 > mercurial from testing5.9.3-1 > all others from testingfrom testing > Fixed in mercurial 6.0 by https://www.mercurial-scm.org/repo/hg/rev/fd3d4b7f8e62 Cheers, Julien
Bug#998867: debootstrap: --no-merged-usr became a no-op
On Mon, Nov 15, 2021 at 01:54:36PM +, Dimitri John Ledkov wrote: > > Also, build chroots must still be created without merged-usr for > > sid/bookworm, until something's been done to migrate user systems. > > But Julien, you said that buildds run stable, meaning they are > unaffected by this debootstrap change in sid/bookworm. > This isn't just about buildds, it's about everything that builds Debian packages. (And even if it was just about buildds, we should still do things in the right order.) Cheers, Julien
Bug#997736: marked as pending in moment-timezone.js
Control: tag -1 - pending On Wed, Oct 27, 2021 at 09:13:11AM +, Yadd wrote: > Control: tag -1 pending > > Hello, > > Bug #997736 in moment-timezone.js reported by you has been fixed in the > Git repository and is awaiting an upload. You can see the commit > message below and you can check the diff of the fix at: > > https://salsa.debian.org/js-team/moment-timezone.js/-/commit/a0d3e6761a48f8cccbbb4c46ac3d99315b36e2b3 > > > Require tz-data = 2021e > > Closes: #997736 > > I'm afraid that commit is not an acceptable fix. Cheers, Julien
Bug#987379: llvm-toolchain-11 autopkgtest segfaults on armhf
On Tue, Oct 26, 2021 at 04:14:35PM +0200, Paul Gevers wrote: > Hi Diederik, all, > > On 26-10-2021 08:34, Diederik de Haas wrote: > > Therefor it may be worth trying whether this bug is resolved as well. > > Well, it's not fixed in the Debian archive: > https://ci.debian.net/data/autopkgtest/unstable/armhf/l/llvm-toolchain-12/16229260/log.gz > Should this be reassigned to binutils then? Cheers, Julien
Bug#996048: [Pkg-openssl-devel] Bug#996048: postfix-mta-sts-resolver: autopkgtest doesn't handle new version of ca-certificates nicely: rehash: warning: skipping ca-certificates.crt, it does not conta
On Mon, Oct 18, 2021 at 11:05:14PM +0200, Kurt Roeckx wrote: > On Mon, Oct 18, 2021 at 10:40:59PM +0200, Julien Cristau wrote: > > On Mon, Oct 18, 2021 at 02:50:50PM +0200, Benjamin Hof wrote: > > > Hi, > > > > > > I think the following change might be the relevant one: > > > > > > --- a/update-ca-certificates > > > +++ b/update-ca-certificates > > > @@ -164,8 +164,6 @@ > > >done > > > fi > > > > > > -rm -f "$CERTBUNDLE" > > > - > > > ADDED_CNT=$(wc -l < "$ADDED") > > > REMOVED_CNT=$(wc -l < "$REMOVED") > > > > > > It triggers this stderr output during openssl rehash (l. 184): > > > > > > rehash: warning: skipping ca-certificates.crt,it does not contain > > > exactly one certificate or CRL > > > > > Ah, that makes sense. Annoying... > > > > Kurt/Sebastian, do you think there's a chance openssl rehash could grow > > some sort of ignore option so update-ca-certificates could ask it to > > skip ca-certificates.crt, to avoid spitting out a warning for it? > > As in rehash all files in that directory, excluding a file? I > guess that's an option. I guess it's not an option to move the > file to a different location. > Exactly. /etc/ssl/certs/ca-certificates.crt is the package's main "interface" so I suspect it'd be quite painful to move. Likewise moving the certs and hash symlinks themselves would break packages/scripts looking them up that way. The other option for me would be to revert the fix for bug #920348. Thanks, Julien
Bug#996048: postfix-mta-sts-resolver: autopkgtest doesn't handle new version of ca-certificates nicely: rehash: warning: skipping ca-certificates.crt,it does not contain exactly one certificate or CRL
On Mon, Oct 18, 2021 at 02:50:50PM +0200, Benjamin Hof wrote: > Hi, > > I think the following change might be the relevant one: > > --- a/update-ca-certificates > +++ b/update-ca-certificates > @@ -164,8 +164,6 @@ >done > fi > > -rm -f "$CERTBUNDLE" > - > ADDED_CNT=$(wc -l < "$ADDED") > REMOVED_CNT=$(wc -l < "$REMOVED") > > It triggers this stderr output during openssl rehash (l. 184): > > rehash: warning: skipping ca-certificates.crt,it does not contain exactly > one certificate or CRL > Ah, that makes sense. Annoying... Kurt/Sebastian, do you think there's a chance openssl rehash could grow some sort of ignore option so update-ca-certificates could ask it to skip ca-certificates.crt, to avoid spitting out a warning for it? Thanks, Julien
Bug#996005: marked as pending in ca-certificates
Control: tag -1 pending Hello, Bug #996005 in ca-certificates reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/debian/ca-certificates/-/commit/ddcda60b9467d0369487cf6e7338bdcff946b51e Fix error on install when TEMPBUNDLE missing. Closes: #996005 [jcristau: also make the restorecon call conditional] (this message was generated automatically) -- Greetings https://bugs.debian.org/996005
Bug#996048: postfix-mta-sts-resolver: autopkgtest doesn't handle new version of ca-certificates nicely: rehash: warning: skipping ca-certificates.crt,it does not contain exactly one certificate or CRL
Hi, On Sun, Oct 10, 2021 at 10:21:40PM +0200, Paul Gevers wrote: > Source: postfix-mta-sts-resolver > Version: 1.0.0-4 > Severity: serious > Tags: sid bookworm > User: debian...@lists.debian.org > Usertags: needs-update > Control: affects -1 src:ca-certificates > > [X-Debbugs-CC: debian...@lists.debian.org, > ca-certifica...@packages.debian.org] > > Dear maintainer(s), > > With a recent upload of ca-certificates the autopkgtest of > postfix-mta-sts-resolver fails in testing when that autopkgtest is run > with the binary packages of ca-certificates from unstable. It passes > when run with only packages from testing. In tabular form: > > passfail > ca-certificates from testing20211004 > postfix-mta-sts-resolver from testing1.0.0-4 > all others from testingfrom testing > > I copied some of the output at the bottom of this report. The *warning* > seems to be innocent, but causes the test to fail because by default > autopkgtest considers output on stderr as fatal (without the > allow-stderr restriction). > > Currently this regression is blocking the migration of ca-certificates > to testing [1]. Of course, ca-certificates shouldn't just break your > autopkgtest (or even worse, your package), but it seems to me that the > change in ca-certificates was intended and your package needs to update > to the new situation. > That's very surprising to me, I'm not aware of any such change to ca-certificates, much less an intended one. > If this is a real problem in your package (and not only in your > autopkgtest), the right binary package(s) from ca-certificates should > really add a versioned Breaks on the unfixed version of (one of your) > package(s). Note: the Breaks is nice even if the issue is only in the > autopkgtest as it helps the migration software to figure out the right > versions to combine in the tests. > I think this "Note" is bad advice. Breaks shouldn't be added just to pacify a tool. Cheers, Julien > More information about this bug and the reason for filing it can be found on > https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation > > Paul > > [1] https://qa.debian.org/excuses.php?package=ca-certificates > > https://ci.debian.net/data/autopkgtest/testing/amd64/p/postfix-mta-sts-resolver/15856707/log.gz > > autopkgtest [19:39:52]: test run: [--- > Updating certificates in /etc/ssl/certs... > rehash: warning: skipping ca-certificates.crt,it does not contain > exactly one certificate or CRL > 1 added, 0 removed; done. > Running hooks in /etc/ca-certificates/update.d... > done. > autopkgtest [19:40:04]: test run: ---] > autopkgtest [19:40:04]: test run: - - - - - - - - - - results - - - - - > - - - - - > run FAIL stderr: rehash: warning: skipping > ca-certificates.crt,it does not contain exactly one certificate or CRL >
Bug#993023: tortoisehg: uninstallable, needs an update for mercurial 5.9
Package: tortoisehg Version: 5.6.1-1 Severity: serious Tags: bookworm sid Hi, mercurial 5.9 is now in sid, making tortoisehg uninstallable. There'll hopefully be a tortoisehg 5.9 release in the near future... Cheers, Julien
Bug#992844: mercurial: FTBFS on s390x (ERROR: test-upgrade-repo.t output changed)
Source: mercurial Version: 5.9-1 Severity: serious Tags: ftbfs >From the log https://buildd.debian.org/status/fetch.php?pkg=mercurial=s390x=5.9-1=1629766216=0 > --- /<>/tests/test-upgrade-repo.t > +++ /<>/tests/test-upgrade-repo.t.err > @@ -1531,9 +1531,8 @@ >sparserevlog >store >$ hg debugsidedata -c 0 > - 2 sidedata entries > - entry-0001 size 4 > - entry-0002 size 32 > + abort: cannot read from revlog 00changelog-5e69c5d1.sda; expected > 1942585158 bytes from offset 0, data size is 90 > + [50] > > downgrade > > @@ -1552,6 +1551,8 @@ > - changelog > - manifest > > + abort: cannot read from revlog data/foo-1335303a.sda; expected 1942585158 > bytes from offset 0, data size is 0 > + [50] >$ hg debugformat -v >format-variant repo config default >fncache:yesyes yes > @@ -1563,7 +1564,7 @@ >persistent-nodemap: no no no (no-rust !) >persistent-nodemap: yesyes no (rust !) >copies-sdc: no no no > - revlog-v2: no no no > + revlog-v2: yes no no >changelog-v2:no no no >plain-cl-delta: yesyes yes >compression:zlib zlibzlib (no-zstd !) > @@ -1571,14 +1572,16 @@ >compression-level: default default default >$ cat .hg/requires >dotencode > - fncache > + exp-revlogv2.2 > + fncache > + persistent-nodemap (rust !) >generaldelta > - persistent-nodemap (rust !) > - revlog-compression-zstd (zstd !) > - revlogv1 > + revlog-compression-zstd >sparserevlog >store >$ hg debugsidedata -c 0 > + abort: cannot read from revlog 00changelog-5e69c5d1.sda; expected > 1942585158 bytes from offset 0, data size is 90 > + [50] > > upgrade from hgrc > > @@ -1587,20 +1590,8 @@ >> revlogv2=enable-unstable-format-and-corrupt-my-data >> EOF >$ hg debugupgraderepo --run --no-backup --quiet > - upgrade will perform the following actions: > - > - requirements > preserved: dotencode, fncache, generaldelta, sparserevlog, store > (no-zstd !) > - preserved: dotencode, fncache, generaldelta, revlog-compression-zstd, > sparserevlog, store (zstd no-rust !) > preserved: dotencode, fncache, generaldelta, persistent-nodemap, > revlog-compression-zstd, sparserevlog, store (rust !) > - removed: revlogv1 > - added: exp-revlogv2.2 > - > - processed revlogs: > -- all-filelogs > -- changelog > -- manifest > - >$ hg debugformat -v >format-variant repo config default >fncache:yesyes yes > @@ -1628,6 +1619,8 @@ >sparserevlog >store >$ hg debugsidedata -c 0 > + abort: cannot read from revlog 00changelog-5e69c5d1.sda; expected > 1942585158 bytes from offset 0, data size is 90 > + [50] > > Demonstrate that nothing to perform upgrade will still run all the way > through > > > ERROR: test-upgrade-repo.t output changed > !# Ret was: 0 (test-upgrade-repo.t)
Bug#982122: redis: experimental package OOMs s390x buildds
On Thu, Aug 12, 2021 at 11:13:59AM +0100, Chris Lamb wrote: > Hey Julian, > > > sorry about my tone yesterday, and thanks for working on this, that's > > great to hear. > > Really, no worries at all... > > Still, I'm somewhat at a loss to debug this. In the first instance, can > one of you throw over the s390x log for the latest upload? As alluded > to in my previous mail, that should have some more debugging information > and buildd.debian.org is telling me "no log" at the moment. > https://people.debian.org/~jcristau/redis_6.2.5-2_s390x-2021-08-11T16:17:34Z > Failing that, I would be happy to disable the testsuite for the time > being, limiting this to s390x on the problematic experimental branch. > Let me know your thoughts on this. > That'd be kind of unfortunate, obviously. I guess the issue isn't limited to a specific test? Have you maybe tried reaching out to the porters on the debian-s390 list? Do you know if it's reproducible on the porter box? Cheers, Julien
Bug#982122: redis: experimental package OOMs s390x buildds
On Wed, Aug 11, 2021 at 10:38:03PM -, Chris Lamb wrote: > Julien Cristau wrote: > > > It'd be appreciated if you could make fixing this a priority, and > > refrained from uploading further versions until then. > > Sure. Just to say though, your message was rather unfortunate to > receive given this latest upload was, in part, an attempt to resolve > this very issue. > Hi Chris, sorry about my tone yesterday, and thanks for working on this, that's great to hear. Cheers, Julien
Bug#982122: redis: experimental package OOMs s390x buildds
On Sat, Feb 06, 2021 at 04:58:09PM +, Adam D. Barratt wrote: > Source: redis > Version: 5:6.2~rc3-1 > Severity: serious > Tags: ftbfs > > Hi, > > Both s390x buildds hit OOM conditions while attempting to build redis > 6.2 in experimental. > > The log from zani ends with: > > [33/63 done]: integration/rdb (10 seconds) > Testing integration/corrupt-dump > [ok]: corrupt payload: #7445 - with sanitize > [...] > [ok]: corrupt payload: fuzzer findings - hash convert asserts on RESTORE with > shallow sanitization > [ok]: corrupt payload: OOM in rdbGenericLoadStringObject > [TIMEOUT]: clients state report follows. > sock2aa3bc1aa00 => (SPAWNED SERVER) pid:45952 > Killing still running Redis server 41748 > > Today's redis upload to experimental OOMed on the s390x buildd again. It'd be appreciated if you could make fixing this a priority, and refrained from uploading further versions until then. Thanks, Julien
Bug#988722: postgresql-common: Upgrading cluster with postgis does not migrate tables using postgis
Control: reassign -1 hdf5 1.10.5+repack-1~exp6 On Tue, May 18, 2021 at 07:48:08PM +0200, Dennis Filder wrote: > X-Debbugs-CC: d.fil...@web.de > > On Tue, May 18, 2021 at 06:47:38PM +0200, Christoph Berg wrote: > > > Can you share the apt command and output that led to this removal? > > I attached the output from "apt full-upgrade" until the "Do you want > to continue?" > > Having gimp-gmic (recommended by gimp-plugin-registry) installed may > have been a contributing factor due to these dependency chains: > > * gimp-gmic -> libgmic1 -> libopencv-videoio4.5 -> libopencv-imgcodecs4.5 -> > libgdal28 > * postgis -> libgdal28 > * postgresql-13-postgis-3 -> libgdal28 > > I remember that I uninstalled gimp-gmic to make it easier to get > something workable again before I could continue with the cluster > migration. > So: - postgresql-11-postgis-2.5 depends on libgdal20 - libgdal20 depends on libnetcdf13 - libnetcdf13 depends on libhdf5-103 - the upgrade pulls in libgdal28 - libgdal28 depends on libhdf5-103-1 - libhdf5-103-1 Breaks/Replaces libhdf5-103 - sadness ensues That Breaks/Replaces is not OK, hdf5 should have bumped SONAMEs if the ABI broke, to preserve co-installability. Cheers, Julien
Bug#931566: Don't complain about suite changes (Acquire::AllowReleaseInfoChange::Suite should be "true")
On Mon, Apr 19, 2021 at 06:28:05PM +0200, Julian Andres Klode wrote: > On Mon, Apr 19, 2021 at 06:08:23PM +0200, Julien Cristau wrote: > > On Mon, Apr 19, 2021 at 06:01:18PM +0200, Julian Andres Klode wrote: > > > I see. Nobody pinged me since then, but it is indeed fixed in the > > > 1.8.5 stable update that at least one release team member was > > > not exited about. > > > > > > https://salsa.debian.org/apt-team/apt/-/compare/1.8.2.2...1.8.5 > > > > > > So it's up to the release team if they want 1.8.5 or whether we'll have > > > to cherry-pick a subset of it into a 1.8.2.3. I think my opinion on that > > > is clear - I don't want to maintain a 1.8.2.z branch, it's more work > > > compared > > > to just following the normal stable apt updates, and there's a lot less > > > testing going on. > > > > > Please upload just that fix to buster; I don't care too much about the > > version number you pick. > > Is there a buster point release before bullseye release, or should that > be in buster-updates? > I don't know. It needs to make its way to spu soon either way. > Given that buster is going to security support only soon anyway, I don't > mind where I apply security updates to that much :D > > > But I really do want to cherry-pick at least two other code fixes, and one > test > suite fix: > Can we defer these until after the AllowReleaseInfoChange change is out, please? Thanks, Julien > * > https://salsa.debian.org/apt-team/apt/-/commit/cfee71c6f2d1478ce4d4ed74ef690ae1350ea403 > > https://salsa.debian.org/apt-team/apt/-/commit/75f452c7309d66548c86a6526cbd65fc51a70039 > > (really just one change, but it was split over two releases, first > turned error to warning, next one ignores it completely; because it > was in 2 releases in main so I kept it separate :D) > > too, they'll make immediate configuration errors non-fatal. Currently > they are fatal in the sense that they are ignored and the upgrade runs > and then it just exits with 1 at the end. So it does not change the > outcome, it just makes the error reporting less silly. > > It is very likely that some upgrades on multi-arch systems fail erronously > without them. To be fair, the multi-arch aspect is also fixed by > > https://salsa.debian.org/apt-team/apt/-/commit/7f65fa3843abc476cbba65c808abc5dd77835815 > but that changes ordering results, and is not strictly necessary. > > * And I want > > https://salsa.debian.org/apt-team/apt/-/commit/cfc6870e9b8ad119219ce5dc1871531006bb2d71 > > to avoid people getting packages removed that stuff still depends on > because their prerm script failed. This might happen during an upgrade > to bullseye, and it's very very likely APT will not be able to recover from > it > - I've never successfully recovered a distribution upgrade that had a > failure in the > middle (and fwiw, all of them had, but they were my faults, really). > > * Also the testsuite-only change in > > https://salsa.debian.org/apt-team/apt/-/commit/730c5c861c32c9385dc862af8673984b12902343 > which makes things work reliably on debci armhf (no regression > potential, wheee) > > -- > debian developer - deb.li/jak | jak-linux.org - free software dev > ubuntu core developer i speak de, en >
Bug#931566: Don't complain about suite changes (Acquire::AllowReleaseInfoChange::Suite should be "true")
On Mon, Apr 19, 2021 at 06:01:18PM +0200, Julian Andres Klode wrote: > I see. Nobody pinged me since then, but it is indeed fixed in the > 1.8.5 stable update that at least one release team member was > not exited about. > > https://salsa.debian.org/apt-team/apt/-/compare/1.8.2.2...1.8.5 > > So it's up to the release team if they want 1.8.5 or whether we'll have > to cherry-pick a subset of it into a 1.8.2.3. I think my opinion on that > is clear - I don't want to maintain a 1.8.2.z branch, it's more work compared > to just following the normal stable apt updates, and there's a lot less > testing going on. > Please upload just that fix to buster; I don't care too much about the version number you pick. Thanks, Julien
Bug#986514: mercurial: FTBFS: dh_auto_test: error: make -j4 check PYTHON=python3.9 "TESTFLAGS=--verbose --timeout 1440 --jobs 4 --blacklist /<>/debian/mercurial.test_blacklist" returned e
On Tue, Apr 13, 2021 at 07:33:04PM +0200, Chris Hofstaedtler wrote: > * Julien Cristau [210413 17:32]: > > I'm not sure that's quite correct as it doesn't restore the backwards > > compatibility that python broke. On the other hand I don't know if > > python even provides a way for consumers to remain backwards-compatible. > > Thanks, python... > > No: https://bugs.python.org/issue42967#msg387638 and ff. > Thanks for the pointer. Seems to me that misguided change should be reverted. Cheers, Julien
Bug#986514: mercurial: FTBFS: dh_auto_test: error: make -j4 check PYTHON=python3.9 "TESTFLAGS=--verbose --timeout 1440 --jobs 4 --blacklist /<>/debian/mercurial.test_blacklist" returned e
Control: tag -1 upstream Control: tag -1 - patch On Tue, Apr 13, 2021 at 06:18:52PM +0200, Ivo De Decker wrote: > control: tags -1 patch > > Hi Julien, > > On Wed, Apr 07, 2021 at 08:42:06AM +0200, Lucas Nussbaum wrote: > > Source: mercurial > > Version: 5.6.1-2 > > Severity: serious > > Justification: FTBFS on amd64 > > Tags: bullseye sid ftbfs > > Usertags: ftbfs-20210406 ftbfs-bullseye > > [...] > > > ERROR: test-archive.t output changed > > > !# Ret was: 0 (test-archive.t) > > I'm pretty sure this is caused by changes in python 3.9.2 and fixed by this > patch from ubuntu: > > https://patches.ubuntu.com/m/mercurial/mercurial_5.6.1-2ubuntu1.patch > I'm not sure that's quite correct as it doesn't restore the backwards compatibility that python broke. On the other hand I don't know if python even provides a way for consumers to remain backwards-compatible. Thanks, python... Cheers, Julien
Bug#922981: tagging 922981 (ca-certificates-java: /etc/ca-certificates/update.d/jks-keystore doesn't update /etc/ssl/certs/java/cacerts)
I've started to look at it, I'm afraid building up context on this stuff to understand what it's doing is going to take a while... Cheers, Julien On Tue, Apr 06, 2021 at 10:31:51PM +0200, Ivo De Decker wrote: > Hi Julien, > > Do you have any comment on the merge request Andreas submitted to > ca-certificates, to allow breaking to dependency cycle in > ca-certificates-java (see mail quoted below, from #922981)? > > Thanks, > > Ivo > > On Fri, Mar 19, 2021 at 03:04:35AM +0100, Andreas Beckmann wrote: > > On Thu, 11 Mar 2021 09:11:37 +0100 Paul Gevers wrote: > > > Is it possible that we get this uploaded soon? If you have the fix > > > ready, it would be good to have it sooner rather than later as we're in > > > the freeze, so it gets a bit of exposure. > > > > I'd like to get some maintainer feedback on > > > > https://salsa.debian.org/java-team/ca-certificates-java/-/merge_requests/5 > > > > https://salsa.debian.org/debian/ca-certificates/-/merge_requests/6 > > > > I have now run some tests in my piuparts instance by injecting these > > packages into buster->bullseye upgrades and have not observed any upgrade > > issues related to ca-certificates-java. > > > > > > Andreas > > >
Bug#986544: ca-certificates: change versioning scheme
Control: tag -1 moreinfo Control: severity -1 wishlist On Wed, Apr 07, 2021 at 11:40:34AM +0200, Andreas Beckmann wrote: > Package: ca-certificates > Version: 20210119 > Severity: serious > > Hi, > > as I had commented on > https://salsa.debian.org/debian/ca-certificates/-/merge_requests/6 > > After seeing the new version scheme for debian-security-support (sid now > has 1:11+2021.01.23), I was thinking whether something similar would be > sensible for ca-certificates, too. Am I correct to assume that the sole > source of certificates included is the "mozilla bundle"? > Currently yes. Historically it has included other CAs, and that could conceivably happen again. > What about changing the versioning scheme to > :++ ? > With =1, =11 for bullseye, =2.46, > =1, s.t. we would have 1:11+2.46+1 for now. A new mozilla bundle > packaged could use 1:11+2.47+1 for bullseye and 1:10+2.47+1 for buster > while excluding some of my patches that are not compatible with > ca-certificates-java in buster (or would require an update of -java too, > but that needs to be done very carefully). (ca-certificates-java in > bullseye needs to depend on ca-certificates (>= 1:11) in that case). > Such versioning would be more clear than 20200401 for bullseye > backported with reduced functionality as 20200401~deb10u1 to buster. > That hypothetical buster version would still satisfy the new versioned > constraint in ca-certificates-java in spite of not having the expected > functionality. > That doesn't really make sense to me, I'm afraid. I'm not familiar with the issue you're trying to fix with this, though... Cheers, Julien
Bug#985840: gitlab-shell: should not ship /usr/bin/check
Package: gitlab-shell Version: 13.13.0+debian-1+b1 Severity: serious /usr/bin/check seems like an awfully generic program name to be shipped in something like gitlab-shell. Please don't. Thanks, Julien -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'testing-security'), (500, 'testing-debug'), (500, 'testing'), (101, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-3-amd64 (SMP w/8 CPU threads) 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 gitlab-shell depends on: ii libc6 2.31-9 gitlab-shell recommends no packages. gitlab-shell suggests no packages. -- no debconf information
Bug#985539: git-hub: New upstream version
Control: severity -1 wishlist On Fri, Mar 19, 2021 at 04:58:47PM +0100, Leandro Lucarella wrote: > Package: git-hub > Version: 1.0.3-1 > Severity: grave > Justification: renders package unusable > The fact that there's a new upstream release does not in itself make the current package unusable. There's already a separate bug (#943037) about moving away from python 2. Cheers, Julien
Bug#962596: Divergence in Symantec CA blacklist reverting between sid and *stable?
On Mon, Mar 15, 2021 at 05:44:44PM +, Thorsten Glaser wrote: > Hi Julien, > > >Yes, they're different. I'm not sure what you're asking. > > the reason for the difference; sorry if I was unclear. > They're different versions of the mozilla root store, so they include different sets of CA certificates. Cheers, Julien
Bug#962596: Divergence in Symantec CA blacklist reverting between sid and *stable?
On Sat, Mar 13, 2021 at 08:32:32PM +, Thorsten Glaser wrote: > Hi, > > the changelogs seem to differ in re-added certificates: > Yes, they're different. I'm not sure what you're asking. Cheers, Julien
Bug#948346: [PATCH] Ensure graceful signal handling when the pid file exists
On Mon, Feb 08, 2021 at 09:41:17AM +0100, Eduard Bloch wrote: > @Julien: okay to add myself as Uploader and upload? No. Cheers, Julien
Bug#980576: marked as pending in mercurial
Control: tag -1 pending Hello, Bug #980576 in mercurial reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/python-team/packages/mercurial/-/commit/b844a5fc220777af4894e0ba0eb1808d7a599ddf tests: make test-subrepo-git.t compatible with git's master->main rename (closes: #980576). (this message was generated automatically) -- Greetings https://bugs.debian.org/980576
Bug#980576: mercurial: autopkgtest needs update for new version of git
Control: tag -1 upstream fixed-upstream patch On Mon, Feb 01, 2021 at 05:42:04PM +0100, Julien Cristau wrote: > On Mon, Feb 01, 2021 at 08:14:13AM -0800, Steve Langasek wrote: > > Package: mercurial > > Version: 5.6.1-1 > > Followup-For: Bug #980576 > > User: ubuntu-de...@lists.ubuntu.com > > Usertags: origin-ubuntu hirsute ubuntu-patch > > > > Dear maintainers, > > > > Attached is a patch that makes the mercurial test suite compatible with both > > the old and new git behavior. It has been uploaded to Ubuntu. Please > > consider applying in Debian as well. > > > Hi Steve, > > is this actually still an issue? > https://www.mercurial-scm.org/repo/hg/rev/366c547a8a57 is in 5.6 and > should address this, as far as I can tell. > Nevermind, I see https://www.mercurial-scm.org/repo/hg/rev/88dfe1c279bb is also needed and is not in the release, so I'll cherry-pick that. Cheers, Julien
Bug#980576: mercurial: autopkgtest needs update for new version of git
On Mon, Feb 01, 2021 at 08:14:13AM -0800, Steve Langasek wrote: > Package: mercurial > Version: 5.6.1-1 > Followup-For: Bug #980576 > User: ubuntu-de...@lists.ubuntu.com > Usertags: origin-ubuntu hirsute ubuntu-patch > > Dear maintainers, > > Attached is a patch that makes the mercurial test suite compatible with both > the old and new git behavior. It has been uploaded to Ubuntu. Please > consider applying in Debian as well. > Hi Steve, is this actually still an issue? https://www.mercurial-scm.org/repo/hg/rev/366c547a8a57 is in 5.6 and should address this, as far as I can tell. Thanks, Julien > diff -Nru mercurial-5.6.1/debian/patches/git-2.30.0-test-compat.patch > mercurial-5.6.1/debian/patches/git-2.30.0-test-compat.patch > --- mercurial-5.6.1/debian/patches/git-2.30.0-test-compat.patch > 1969-12-31 16:00:00.0 -0800 > +++ mercurial-5.6.1/debian/patches/git-2.30.0-test-compat.patch > 2021-01-30 17:04:28.0 -0800 > @@ -0,0 +1,33 @@ > +Description: make test cases compatible with git 2.30.0 > + New git upstream includes an additional warning when calling 'git init' > + if you do not first set init.defaultBranch in your config. Make the test > + case compatible with both old and new git by setting init.defaultBranch > + before calling git init. > +Author: Steve Langasek > +Last-Update: 2021-01-30 > +Bug-Debian: https://bugs.debian.org/980576 > + > +Index: mercurial-5.6.1/tests/test-convert-git.t > +=== > +--- mercurial-5.6.1.orig/tests/test-convert-git.t > mercurial-5.6.1/tests/test-convert-git.t > +@@ -677,6 +677,7 @@ > + > + $ mkdir git-testrevs > + $ cd git-testrevs > ++ $ git config --global init.defaultBranch master > + $ git init > + Initialized empty Git repository in $TESTTMP/git-testrevs/.git/ > + $ echo a >> a ; git add a > /dev/null; git commit -m 'first' > /dev/null > +Index: mercurial-5.6.1/tests/test-subrepo-git.t > +=== > +--- mercurial-5.6.1.orig/tests/test-subrepo-git.t > mercurial-5.6.1/tests/test-subrepo-git.t > +@@ -1199,6 +1199,7 @@ > + $ hg init malicious-subrepository > + $ cd malicious-subrepository > + $ echo "s = [git]ext::sh -c echo% pwned:% \$PWNED_MSG% >pwned.txt" > > .hgsub > ++ $ git config --global init.defaultBranch master > + $ git init s > + Initialized empty Git repository in > $TESTTMP/tc/malicious-subrepository/s/.git/ > + $ cd s > diff -Nru mercurial-5.6.1/debian/patches/series > mercurial-5.6.1/debian/patches/series > --- mercurial-5.6.1/debian/patches/series 2021-01-08 07:02:06.0 > -0800 > +++ mercurial-5.6.1/debian/patches/series 2021-01-30 14:48:59.0 > -0800 > @@ -3,3 +3,4 @@ > deb_specific__optional-dependencies > deb_specific__disable_libdir_replacement.patch > 0005-Tolerate-SIGINT-getting-the-kill-in-test-stdio.py.patch > +git-2.30.0-test-compat.patch
Bug#962596: Backport to stretch?
Hi Michael, stretch is EOL, so I am not planning on touching it myself. Cc:ing the team that looks after stretch-lts in case they want to handle this. Cheers, Julien On Mon, Feb 01, 2021 at 03:14:38PM +, Michael Simons (.NET) wrote: > Hi Julien, > > > > Thanks for pushing the changes to buster. Will this get backported to stretch > as well? If so, what is the timeframe users can expect? > > > > > I'm not sure why this is blowing up again this week > > > > See https://github.com/NuGet/Announcements/issues/49 for details on how this > affected .NET users building on Debian. > > Thanks > > Michael > > > On Thu, 28 Jan 2021 15:17:34 +0100 “Julien Cristau" > wrote: > > Hi, > > > > > > I'm not sure why this is blowing up again this week when things have > > > been in a bit of a limbo state since June last year, but in any case > > > I've just pushed a change to buster to try and revert the blacklisting > > > of legacy Symantec CAs. That should hopefully make it to the archive in > > > the next few days. > > > > > > Cheers, > > > Julien >
Bug#962596: NuGet incident on Debian Buster
Hi, I'm not sure why this is blowing up again this week when things have been in a bit of a limbo state since June last year, but in any case I've just pushed a change to buster to try and revert the blacklisting of legacy Symantec CAs. That should hopefully make it to the archive in the next few days. Cheers, Julien On Wed, Jan 27, 2021 at 06:22:00PM +, Svetlana Kofman wrote: > Hi Julien, > > We are reaching out to you since you worked on issue #962596. > > Some background: > > NuGet packages that are being restored on Debian Buster are failing package > validation. This is caused by an expired cert which causes us to check the > time > signature. The time signature is deemed invalid due to this recent Debian > change. > > > > Broken by: Caused by Debian change #911289 - ca-certificates should remove > Symantec certs - Debian Bug report logs > > Later fixed by Debian: #962596 - ca-certificates: Removal of GeoTrust Global > CA > requires investigation - Debian Bug report logs … but not released yet. > > > > NuGet issue is Tracked in this public issue: > > Package validation broken in docker builds with errors NU3028 and NU3037 · > Issue #10491 · NuGet/Home (github.com) > > > > We are looking into helping customers mitigate the issue, and one of the > options is to obtain the latest ca-certificates package with the fix. > > We see the fix is available in sid and bullseye, are there plans to back port > the fix to buster? If so what is the timeline? > > > > Thanks, > > Svetlana > > NuGet Team > > > On Wed, Jan 27, 2021 at 07:33:02PM +, Michael Simons (.NET) wrote: > I see this was recently released to testing, is there an eta on when it will > be > available in stable, (e.g. buster)? > > > > Thanks >
Bug#976731: firefox: FTBFS on arm64 (explicit specialization in non-namespace scope ‘class js::wasm::BaseRegAlloc’)
Source: firefox
Version: 83.0-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
Log:
https://buildd.debian.org/status/fetch.php?pkg=firefox=arm64=83.0-1=1606251110=0
Excerpt:
> In file included from Unified_cpp_js_src_wasm0.cpp:20:
> /<>/js/src/wasm/WasmBaselineCompile.cpp:661:13: error: explicit
> specialization in non-namespace scope ‘class js::wasm::BaseRegAlloc’
> 661 | template <>
> | ^
> /<>/js/src/wasm/WasmBaselineCompile.cpp:662:8: error:
> template-id ‘hasFPU’ in declaration of primary
> template
> 662 | bool hasFPU() {
> |^~~~
> /<>/js/src/wasm/WasmBaselineCompile.cpp:747:17: error: too many
> template-parameter-lists
> 747 | FloatRegister allocFPU() {
> | ^~~~
> /<>/js/src/wasm/WasmBaselineCompile.cpp:752:13: error: explicit
> specialization in non-namespace scope ‘class js::wasm::BaseRegAlloc’
> 752 | template <>
> | ^
> /<>/js/src/wasm/WasmBaselineCompile.cpp:753:17: error: expected
> ‘;’ at end of member declaration
> 753 | FloatRegister allocFPU() {
> | ^~~~
> | ;
> /<>/js/src/wasm/WasmBaselineCompile.cpp:753:17: error:
> ‘js::jit::FloatRegister js::wasm::BaseRegAlloc::allocFPU’ conflicts with a
> previous declaration
> /<>/js/src/wasm/WasmBaselineCompile.cpp:738:8: note: previous
> declaration ‘void js::wasm::BaseRegAlloc::allocFPU(js::jit::FloatRegister)’
> 738 | void allocFPU(FloatRegister r) {
> |^~~~
> /<>/js/src/wasm/WasmBaselineCompile.cpp:753:25: error: expected
> unqualified-id before ‘<’ token
> 753 | FloatRegister allocFPU() {
> | ^
> /<>/js/src/wasm/WasmBaselineCompile.cpp: In member function
> ‘js::wasm::RegF32 js::wasm::BaseRegAlloc::needF32()’:
> /<>/js/src/wasm/WasmBaselineCompile.cpp:937:27: error: invalid
> use of non-static member function ‘void
> js::wasm::BaseRegAlloc::allocFPU(js::jit::FloatRegister)’
> 937 | return RegF32(allocFPU());
> | ^
> /<>/js/src/wasm/WasmBaselineCompile.cpp:738:8: note: declared
> here
> 738 | void allocFPU(FloatRegister r) {
> |^~~~
> /<>/js/src/wasm/WasmBaselineCompile.cpp:937:18: error: expected
> primary-expression before ‘(’ token
> 937 | return RegF32(allocFPU());
> | ^
> /<>/js/src/wasm/WasmBaselineCompile.cpp:937:27: error: invalid
> use of non-static member function ‘void
> js::wasm::BaseRegAlloc::allocFPU(js::jit::FloatRegister)’
> 937 | return RegF32(allocFPU());
> | ^
> /<>/js/src/wasm/WasmBaselineCompile.cpp:738:8: note: declared
> here
> 738 | void allocFPU(FloatRegister r) {
> |^~~~
> /<>/js/src/wasm/WasmBaselineCompile.cpp:937:46: error: expected
> primary-expression before ‘)’ token
> 937 | return RegF32(allocFPU());
> | ^
> /<>/js/src/wasm/WasmBaselineCompile.cpp: In member function
> ‘js::wasm::RegF64 js::wasm::BaseRegAlloc::needF64()’:
> /<>/js/src/wasm/WasmBaselineCompile.cpp:951:27: error: invalid
> use of non-static member function ‘void
> js::wasm::BaseRegAlloc::allocFPU(js::jit::FloatRegister)’
> 951 | return RegF64(allocFPU());
> | ^~~~
> /<>/js/src/wasm/WasmBaselineCompile.cpp:738:8: note: declared
> here
> 738 | void allocFPU(FloatRegister r) {
> |^~~~
> /<>/js/src/wasm/WasmBaselineCompile.cpp:951:18: error: expected
> primary-expression before ‘(’ token
> 951 | return RegF64(allocFPU());
> | ^
> /<>/js/src/wasm/WasmBaselineCompile.cpp:951:27: error: invalid
> use of non-static member function ‘void
> js::wasm::BaseRegAlloc::allocFPU(js::jit::FloatRegister)’
> 951 | return RegF64(allocFPU());
> | ^~~~
> /<>/js/src/wasm/WasmBaselineCompile.cpp:738:8: note: declared
> here
> 738 | void allocFPU(FloatRegister r) {
> |^~~~
> /<>/js/src/wasm/WasmBaselineCompile.cpp:951:45: error: expected
> primary-expression before ‘)’ token
> 951 | return RegF64(allocFPU());
> | ^
> make[5]: *** [/<>/config/rules.mk:676:
> Unified_cpp_js_src_wasm0.o] Error 1
Cheers,
Julien
Bug#976730: firefox: FTBFS on armhf (unresolved imports `core::arch::arm::float32x4_t`, `core::arch::arm::int32x4_t`, `core::arch::arm::vaddq_f32`)
Source: firefox Version: 83.0-1 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) Forwarded: https://bugzilla.mozilla.org/show_bug.cgi?id=1680495 The log at https://buildd.debian.org/status/fetch.php?pkg=firefox=armhf=83.0-1=1605661388=0 seems to match the error reported upstream by SUSE, with qcms relying on nightly rustc features. Cheers, Julien
Bug#976216: xorg-server: CVE-2020-25712 CVE-2020-14360
On Wed, Dec 02, 2020 at 12:10:43PM +0100, Moritz Muehlenhoff wrote: > I'll compare them with yours tonight, but I'd expect them to be identical > given > how close buster is to upstream. > Yeah, they're the same. Thanks for getting this rolling. Cheers, Julien
Bug#976216: xorg-server: CVE-2020-25712 CVE-2020-14360
Hi,
On Tue, Dec 01, 2020 at 05:58:56PM +0100, Salvatore Bonaccorso wrote:
> The following vulnerabilities were published for xorg-server.
>
> CVE-2020-25712[0]:
> | Fix XkbSetDeviceInfo() and SetDeviceIndicators() heap overflows
>
> CVE-2020-14360[1]:
> | Check SetMap request length carefully
>
> If you fix the vulnerabilities please also make sure to include the
> CVE (Common Vulnerabilities & Exposures) ids in your changelog entry.
>
I'm assuming we'll want this in buster-security?
Proposed patch below, it's a clean cherry-pick from server-1.20-branch;
Timo's working on updating sid to 1.20.10. This being xkb I'd prefer to
wait a couple of days to watch out for any regressions before shipping
the update in stable if possible, but we can get started with an upload
and builds right away.
Cheers,
Julien
diff -u xorg-server-1.20.4/debian/changelog xorg-server-1.20.4/debian/changelog
--- xorg-server-1.20.4/debian/changelog
+++ xorg-server-1.20.4/debian/changelog
@@ -1,3 +1,15 @@
+xorg-server (2:1.20.4-1+deb10u2) buster-security; urgency=high
+
+ * Team upload.
+ * Security fixes from
+https://lists.x.org/archives/xorg-announce/2020-December/003066.html
+(closes: #976216)
+ * Fix XkbSetDeviceInfo() and SetDeviceIndicators() heap overflows
+(CVE-2020-25712)
+ * Check SetMap request length carefully (CVE-2020-14360)
+
+ -- Julien Cristau Wed, 02 Dec 2020 11:39:24 +0100
+
xorg-server (2:1.20.4-1+deb10u1) buster-security; urgency=high
* Non-maintainer upload by the Security Team.
only in patch2:
unchanged:
--- xorg-server-1.20.4.orig/xkb/xkb.c
+++ xorg-server-1.20.4/xkb/xkb.c
@@ -2366,6 +2366,93 @@
return (char *) wire;
}
+#define _add_check_len(new) \
+if (len > UINT32_MAX - (new) || len > req_len - (new)) goto bad; \
+else len += new
+
+/**
+ * Check the length of the SetMap request
+ */
+static int
+_XkbSetMapCheckLength(xkbSetMapReq *req)
+{
+size_t len = sz_xkbSetMapReq, req_len = req->length << 2;
+xkbKeyTypeWireDesc *keytype;
+xkbSymMapWireDesc *symmap;
+BOOL preserve;
+int i, map_count, nSyms;
+
+if (req_len < len)
+goto bad;
+/* types */
+if (req->present & XkbKeyTypesMask) {
+keytype = (xkbKeyTypeWireDesc *)(req + 1);
+for (i = 0; i < req->nTypes; i++) {
+_add_check_len(XkbPaddedSize(sz_xkbKeyTypeWireDesc));
+if (req->flags & XkbSetMapResizeTypes) {
+_add_check_len(keytype->nMapEntries
+ * sz_xkbKTSetMapEntryWireDesc);
+preserve = keytype->preserve;
+map_count = keytype->nMapEntries;
+if (preserve) {
+_add_check_len(map_count * sz_xkbModsWireDesc);
+}
+keytype += 1;
+keytype = (xkbKeyTypeWireDesc *)
+ ((xkbKTSetMapEntryWireDesc *)keytype + map_count);
+if (preserve)
+keytype = (xkbKeyTypeWireDesc *)
+ ((xkbModsWireDesc *)keytype + map_count);
+}
+}
+}
+/* syms */
+if (req->present & XkbKeySymsMask) {
+symmap = (xkbSymMapWireDesc *)((char *)req + len);
+for (i = 0; i < req->nKeySyms; i++) {
+_add_check_len(sz_xkbSymMapWireDesc);
+nSyms = symmap->nSyms;
+_add_check_len(nSyms*sizeof(CARD32));
+symmap += 1;
+symmap = (xkbSymMapWireDesc *)((CARD32 *)symmap + nSyms);
+}
+}
+/* actions */
+if (req->present & XkbKeyActionsMask) {
+_add_check_len(req->totalActs * sz_xkbActionWireDesc
+ + XkbPaddedSize(req->nKeyActs));
+}
+/* behaviours */
+if (req->present & XkbKeyBehaviorsMask) {
+_add_check_len(req->totalKeyBehaviors * sz_xkbBehaviorWireDesc);
+}
+/* vmods */
+if (req->present & XkbVirtualModsMask) {
+_add_check_len(XkbPaddedSize(Ones(req->virtualMods)));
+}
+/* explicit */
+if (req->present & XkbExplicitComponentsMask) {
+/* two bytes per non-zero explicit componen */
+_add_check_len(XkbPaddedSize(req->totalKeyExplicit * sizeof(CARD16)));
+}
+/* modmap */
+if (req->present & XkbModifierMapMask) {
+ /* two bytes per non-zero modmap component */
+_add_check_len(XkbPaddedSize(req->totalModMapKeys * sizeof(CARD16)));
+}
+/* vmodmap */
+if (req->present & XkbVirtualModMapMask) {
+_add_check_len(req->totalVModMapKeys * sz_xkbVModMapWireDesc);
+}
+if (len == req_len)
+return Success;
+bad:
+ErrorF("[xkb] BOGUS LENGTH in SetMap: expected %ld got %ld\n",
+ len, req_len);
+return BadLength;
+}
+
+
/**
* Check if the given request can be applied to the given devi
Bug#974895: ftp.debian.org: MRS should be updated to support the new libzeep library
Control: severity -1 normal Control: tags -1 - ftbfs Control: retitle -1 RM: mrs -- ROM, incompatible with current libzeep On Mon, Nov 16, 2020 at 08:10:11AM +0100, Maarten L. Hekkelman wrote: > Package: ftp.debian.org > Severity: serious > Tags: ftbfs > Justification: fails to build from source (but built successfully in the past) > > MRS is an information retrieval system, used to index terabytes of text based > databanks on a single machine. Mostly used in the medical and biological > world. > > The version of MRS in currently in Debian is based on libzeep version 3. > Libzeep was in fact a spin off project from MRS. > > I stopped development of MRS in 2012 when I switched to a new employer but I > took libzeep with me. Since then, libzeep has evolved and changed a lot and > now compatibility with MRS is broken. > > I've submitted the new version of libzeep into debian (it is currently in > unstable) but now MRS no longer builds and so I request to remove it from > Debian until it is updated. > > regards, -maarten
Bug#970111: Bug#971989: unblock: thunderbird/1:78.3.2-1
On Tue, Oct 20, 2020 at 05:54:19PM +0200, Michael Biebl wrote: > So I decided to do that, and NMU enigmail. > I used Gregors patches from [1] (thanks for that!) with some minor changes > - Updated to 2.2.4 (instead of 2.2.2) > - Marked the upload as NMU (versioned as 2:2.2.4-0.1) and removed Gregor > from Uploaders again. It seemed a bit controversial to add oneself to > Uploaders as part of an NMU > - Removed Files-Excluded from debian/copyright as the offending files > are no longer part of the dist tarball, so a repack is not necessary anymore > > I gave the package some light testing and the migration wizard did > properly show up and import my private and public keys (it skipped one > public key, haven't investigated yet, why) and the account settings. > > I've pushed my work to https://salsa.debian.org/biebl/enigmail and > uploaded to DELAYED/14. > In the interest of getting thunderbird updated in bullseye, I've just gone ahead and rescheduled the NMU from 5-day to 0-day. Cheers, Julien
Bug#972758: ABI breakage without soname bump
On Fri, Oct 23, 2020 at 12:20:30PM +0200, Steinar H. Gunderson wrote: > On Fri, Oct 23, 2020 at 11:33:41AM +0200, Julien Cristau wrote: > > https://github.com/axboe/liburing/commit/25bbcbef3e0a8bfba8044be55d08d5116c51dccd > > seems to have bumped SONAME upstream. > > That would fix it, yes, but it seems to have missed the kflags change > (the commit says all added padding is at the end). > > The kflags change was made a month or so before 0.7 release: > > > https://github.com/axboe/liburing/commit/0f0517331307605e576b3492c93dc4988e06fdc0 > Yeah, I'm not saying the commit message is accurate, just that that change will end up fixing this bug. :) All that's needed is a 0.8 release I guess. Cheers, Julien
Bug#972758: ABI breakage without soname bump
On Fri, Oct 23, 2020 at 10:47:57AM +0200, Steinar H. Gunderson wrote: > On Fri, Oct 23, 2020 at 09:55:36AM +0200, Steinar H. Gunderson wrote: > > If this were somehow only about newer functionality or critical fixes, it > > could > > be fixed by bumping the versioned dependency, but rhis goes both ways; if > > you > > build plocate against liburing 0.6-3, and then upgrade liburing1 to 0.7-1, > > you get a similar crash. So it would seem there's hidden ABI breakage here > > that > > needs a soname bump. > > It seems there's a new “unsigned *kflags;” added in the middle of > struct io_uring_cq that would explain this. > https://github.com/axboe/liburing/commit/25bbcbef3e0a8bfba8044be55d08d5116c51dccd seems to have bumped SONAME upstream. Cheers, Julien
Bug#888423: firefox: FF 58.0 segfaults each 1-2 minute
On Thu, Jan 25, 2018 at 03:25:32PM +0300, Dmitry E. Oboukhov wrote: > Package: firefox > Version: 58.0-1 > Severity: grave > > I used FF58b4, it works fine. > Then I upgraded it to FF58b14, it crashed from time to time. > > Today I upgraded FF to 58.0, it crashes each 1 minute (see backtrace) > (see below). > Hi Dmitry, are you still seeing this? If so, and assuming the firefox crash reporter shows up, please send a report, and share the crash-stats.mozilla.org URL (which should be visible from about:crashes). Thanks, Julien
Bug#969739: Segmentation fault on startup
Control: severity -1 important Control: tag -1 moreinfo On Mon, Sep 07, 2020 at 11:59:34AM -0400, Christophe Kalt wrote: > Package: xserver-xorg-core > Version: 2:1.20.9-1 > Severity: grave > > Same setup was working with 2:1.20.7-2, but with 2:1.20.9-1 crashes on startup > (xinit). /var/log/Xorg.0.log follows: > There's a number of things going wrong here... [...] > [881147.372] (EE) dbus-core: error connecting to system bus: > org.freedesktop.DBus.Error.FileNotFound (Failed to connect to socket > /run/dbus/ > system_bus_socket: No such file or directory) That's not good for input but probably doesn't explain the crash in InitOutput. [...] > [881147.372] (II) xfree86: Adding drm device (/dev/dri/card0) > [881147.372] (II) Platform probe for /sys/devices/pci:00/:00:02.0/drm/ > card0 > [881147.377] (--) PCI:*(0@0:2:0) 8086:3ea5:8086:2074 rev 1, Mem @ > 0x604b00/ > 16777216, 0x40/134217728, I/O @ 0x4000/64, BIOS @ > 0x/131072 That's Intel "Iris Plus Graphics 655". [...] > [881147.426] (II) modeset(G0): using drv /dev/dri/card0 > [881147.427] (II) modeset(0): Creating default Display subsection in Screen > section > "Default Screen Section" for depth/fbbpp 24/32 > [881147.427] (==) modeset(0): Depth 24, (==) framebuffer bpp 32 > [881147.427] (EE) > [881147.427] (EE) Backtrace: > [881147.428] (EE) 0: /usr/lib/xorg/Xorg (OsLookupColor+0x135) [0x557662d21f35] > [881147.429] (EE) 1: /lib/x86_64-linux-gnu/libpthread.so.0 (funlockfile+0x50) > [0x7f3bb952318f] > [881147.430] (EE) 2: /usr/lib/xorg/Xorg (xf86PlatformMatchDriver+0x5c0) > [0x557662c1a2b0] > [881147.430] (EE) 3: /usr/lib/xorg/Xorg (xf86CollectOptions+0x77) > [0x557662bfd197] > [881147.431] (EE) unw_get_proc_name failed: no unwind info found [-10] > [881147.431] (EE) 4: /usr/lib/xorg/modules/drivers/modesetting_drv.so (?+0x0) > [0x7f3bb8a25940] > [881147.432] (EE) 5: /usr/lib/xorg/Xorg (InitOutput+0x9ae) [0x557662c0085e] > [881147.433] (EE) 6: /usr/lib/xorg/Xorg (InitFonts+0x1cc) [0x557662bc235c] > [881147.434] (EE) 7: /lib/x86_64-linux-gnu/libc.so.6 (__libc_start_main+0xea) > [0x7f3bb936ecca] > [881147.434] (EE) 8: /usr/lib/xorg/Xorg (_start+0x2a) [0x557662babc9a] > [881147.434] (EE) > [881147.435] (EE) Segmentation fault at address 0x124 > [881147.435] (EE) > Fatal server error: > [881147.435] (EE) Caught signal 11 (Segmentation fault). Server aborting > [881147.435] (EE) > [881147.435] (EE) > Please consult the The X.Org Foundation support > at http://wiki.x.org > for help. > [881147.435] (EE) Please also check the log file at "/var/log/Xorg.0.log" for > additional information. > [881147.435] (EE) > [881147.467] (EE) Server terminated with error (1). Closing log file. Any details you can provide as to the setup and how you're starting Xorg? Please also provide a kernel log. Cheers, Julien
Bug#969136: xserver-xorg-video-amdgpu: Xserver keeps crashing inside of /usr/lib/xorg/modules/drivers/amdgpu_drv.so
Control: severity -1 important Control: reassign -1 mesa On Thu, Aug 27, 2020 at 06:36:27PM -0700, Phil Dibowitz wrote: > Package: xserver-xorg-video-amdgpu > Version: 19.1.0-1 > Severity: grave > Justification: causes non-serious data loss > > Dear Maintainer, > > About once a day my Xserver crashes. The following stracktrace appears > in the Xorg log: > > ``` > [ 72995.788] (EE) > [ 72995.788] (EE) Backtrace: > [ 72995.793] (EE) 0: /usr/lib/xorg/Xorg (OsLookupColor+0x138) [0x56449292fe88] > [ 72995.794] (EE) 1: /lib/x86_64-linux-gnu/libpthread.so.0 (funlockfile+0x50) > [0x7f8803c4e18f] > [ 72995.794] (EE) 2: /lib/x86_64-linux-gnu/libc.so.6 > (__nss_database_lookup+0x28131) [0x7f8803bfdc41] > [ 72995.797] (EE) 3: /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so > (radeon_drm_winsys_create+0x112f0f) [0x7f880208227f] > [ 72995.797] (EE) 4: /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so > (radeon_drm_winsys_create+0x138740) [0x7f88020ccd30] > [ 72995.798] (EE) 5: /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so > (radeon_drm_winsys_create+0x13b601) [0x7f88020d22f1] > [ 72995.799] (EE) 6: /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so > (nouveau_drm_screen_create+0x1db4ac) [0x7f88023cc4bc] > [ 72995.799] (EE) 7: /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so > (nouveau_drm_screen_create+0x1d7a0f) [0x7f88023c4e6f] > [ 72995.800] (EE) 8: /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so > (nouveau_drm_screen_create+0x1dbf83) [0x7f88023cd923] > [ 72995.800] (EE) 9: /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so > (__driDriverGetExtensions_zink+0x210f9) [0x7f88018aa579] > [ 72995.801] (EE) 10: /usr/lib/xorg/modules/libglamoregl.so > (glamor_destroy_pixmap+0x148) [0x7f87f80a0b68] > [ 72995.802] (EE) unw_get_proc_name failed: no unwind info found [-10] > [ 72995.802] (EE) 11: /usr/lib/xorg/modules/drivers/amdgpu_drv.so (?+0x0) > [0x7f880313d650] > [ 72995.802] (EE) 12: /usr/lib/xorg/Xorg (BlockHandler+0xa5) [0x5644927d72c5] > [ 72995.802] (EE) 13: /usr/lib/xorg/Xorg (WaitForSomething+0x11a) > [0x5644929296fa] > [ 72995.802] (EE) 14: /usr/lib/xorg/Xorg (SendErrorToClient+0x113) > [0x5644927d2723] > [ 72995.802] (EE) 15: /usr/lib/xorg/Xorg (InitFonts+0x3b4) [0x5644927d6914] > [ 72995.803] (EE) 16: /lib/x86_64-linux-gnu/libc.so.6 > (__libc_start_main+0xea) [0x7f8803a99cca] > [ 72995.803] (EE) 17: /usr/lib/xorg/Xorg (_start+0x2a) [0x5644927c073a] > [ 72995.803] (EE) > [ 72995.803] (EE) Segmentation fault at address 0x7f87e07f9000 > [ 72995.803] (EE) > Fatal server error: > [ 72995.803] (EE) Caught signal 11 (Segmentation fault). Server aborting > [ 72995.803] (EE) > [ 72995.803] (EE) > Please consult the The X.Org Foundation support > at http://wiki.x.org > for help. > [ 72995.803] (EE) Please also check the log file at "/var/log/Xorg.0.log" for > additional information. > [ 72995.803] (EE) > [ 72995.803] (II) AIGLX: Suspending AIGLX clients for VT switch > ``` > > There's nothing specific to trigger the bug, I've had it happen while > doing a variety of different things. > Which version of libgl1-mesa-dri is this on? If you're still seeing this on the latest version it would probably be good to report at https://gitlab.freedesktop.org/mesa/mesa/-/issues for the mesa devs to take a look. Cheers, Julien
Bug#969948: [debian buster] [xbase-clients] The following packages have unmet dependencies:
On Wed, Sep 09, 2020 at 11:07:23AM +0200, Jean-Marc LACROIX wrote: > > ansible@vm-buster-amd64-190:~$ sudo apt install -y libgl1-mesa-dri > Reading package lists... Done > Building dependency tree > Reading state information... Done > Some packages could not be installed. This may mean that you have > requested an impossible situation or if you are using the unstable > distribution that some required packages have not yet been created > or been moved out of Incoming. > The following information may help to resolve the situation: > > The following packages have unmet dependencies: > libgl1-mesa-dri : Depends: libdrm-nouveau2 (>= 2.4.66) but it is not > installable > E: Unable to correct problems, you have held broken packages. > ansible@vm-buster-amd64-190:~$ > Right, so now you can keep going down that rabbit hole with libdrm-nouveau2? Cheers, Julien
Bug#969948: [debian buster] [xbase-clients] The following packages have unmet dependencies:
Control: tag -1 moreinfo unreproducible On Wed, Sep 09, 2020 at 10:23:53AM +0200, Jean-Marc LACROIX wrote: > Package: xbase-clients > Version: 3.2-2 That is not the version of xbase-clients in any Debian release as far as I can tell. > Severity: grave > > Dear maintainers, > > It seems there is a dependancy issue (?) when trying to install > xbase-clients Debian buster 10.5 package. > > The installation in done on one LXC container running with sysvinit, > and without droping any Posix 1003.2 capabilities. > > ansible@vm-buster-amd64-190:~$ sudo apt install xbase-clients [...] > xbase-clients : Depends: x11-utils but it is not going to be installed > [...] > ansible@vm-buster-amd64-190:~$ sudo apt install libglx-mesa0 [...] > libglx-mesa0 : Depends: libgl1-mesa-dri but it is not going to be installed > E: Unable to correct problems, you have held broken packages. > > > ansible@vm-buster-amd64-190:~$ sudo apt install libglx-mesa-dri > Reading package lists... Done > Building dependency tree > Reading state information... Done > E: Unable to locate package libglx-mesa-dri > The above said libgl1-mesa-dri, not libglx-mesa-dri. Cheers, Julien
Bug#969284: xorg-server: FTBFS: configure: error: Xwayland build explicitly requested, but required modules not found
Control: reassign -1 libwayland-dev 1.18.0-2~exp1 Control: affects -1 + src:xorg-server On Sun, Aug 30, 2020 at 09:21:55PM +0200, Salvatore Bonaccorso wrote: > Source: xorg-server > Version: 2:1.20.8-2 > Severity: serious > Justification: FTBFS > X-Debbugs-Cc: car...@debian.org > > Hi > > When trying to build xorg-server 2:1.20.8-2 in unstable, the build > fails (on configure already) with: > > configure: error: Xwayland build explicitly requested, but required modules > not found > > full build log though attached (and I have not further checked if > another dependency is actually at fault). > Log says: Package 'libffi', required by 'wayland-client', not found Cheers, Julien
Bug#968013: swi-prolog: time bomb in swi-prolog-test, and failing autopkgtest
Package: swi-prolog Severity: serious X-Debbugs-Cc: jcris...@debian.org Hi, swi-prolog autopkgtests are currently failing: https://ci.debian.net/data/autopkgtest/testing/amd64/s/swi-prolog/6535300/log.gz >From what I can tell, there's a step in the build process to generate test certs, which are then shipped in the swi-prolog-test package. Among those files is rootCA-crl.pem which is valid for 30 days, so running the tests more than 30 days after the package was built fails. I guess the certs should be generated as part of the test procedure instead. Cheers, Julien
Bug#956007: marked as pending in mercurial
Control: tag -1 pending Hello, Bug #956007 in mercurial reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/python-team/applications/mercurial/-/commit/306a0553aa60103c40bd0a89de6e2d67f3b851ff Remove python-subversion from autopkgtest dependencies (closes: #956007) (this message was generated automatically) -- Greetings https://bugs.debian.org/956007
Bug#963287: notmuch: FTBFS: grotty: ():1662: fatal error: output error
On Mon, Jun 22, 2020 at 19:46:21 +0200, Michael Meskes wrote: > > Depending on bsdmainutils to get col et al seems entirely right, it's > > been right forever, there doesn't seem to be a reason to break that > > both > > for dependent packages and for end users. Especially not without > > notice. > > There is no point arguing against your "do not change anything" > attitude. > I'm not saying don't change anything, I'm saying don't break stuff for users for no reason. Cheers, Julien
Bug#963287: notmuch: FTBFS: grotty: ():1662: fatal error: output error
On Mon, Jun 22, 2020 at 19:04:49 +0200, Michael Meskes wrote: > > I think it's probably best at this point to have bsdmainutils depend > > on > > bsdextrautils. That gets rid of the breakage in the place where it > > originated, and doesn't leave things without a transition path. > > I beg to disagree, there is a transition plan, namely depending on the > right package. Things change, that's what unstable is for. Depending on > bsdmainutils to get bsdextrautils does not sound right to me. > Depending on bsdmainutils to get col et al seems entirely right, it's been right forever, there doesn't seem to be a reason to break that both for dependent packages and for end users. Especially not without notice. Cheers, Julien
Bug#963287: notmuch: FTBFS: grotty: ():1662: fatal error: output error
On Mon, Jun 22, 2020 at 13:37:56 -0300, David Bremner wrote: > Michael Meskes writes: > > > On Mon, 2020-06-22 at 11:37 -0300, David Bremner wrote: > >> Michael Meskes writes: > >> > >> > > IMO the move of col needs to be rolled back ASAP. And, if it is > >> > > to > >> > > >> > Why? Care to give a reason? > >> > > >> > >> The change broke man-db, as I explained in a previous message. > > > > Oh, that I understand and I'm sorry I didn't notice that issue before, > > but why is rolling back preferable over fixing man-db? > > I don't know what Julien had in mind, presumably worried about other > breakage to surface. Note that obvious fix to man-db will all debhelper > using packages transitively build-depending on bsdextrautils. > I think it's probably best at this point to have bsdmainutils depend on bsdextrautils. That gets rid of the breakage in the place where it originated, and doesn't leave things without a transition path. Cheers, Julien
Bug#963287: notmuch: FTBFS: grotty: ():1662: fatal error: output error
On Mon, Jun 22, 2020 at 03:42:33PM +0200, Michael Meskes wrote: > > 'm adding the maintainers of util-linux (bsdextrautils) and > > bsdmainutils > > to Cc. Which path forward do you see for this issue? A similar issue > > seems to affect many packages, such as: > > ... > > It seems to me there are two options here, either we ask all those > packages to change the dependency or we force bsdextrautils > installation by making bsdmainutils depend on it. > > When changing the package I decided against a hard dependency because > it forces people to install something even if they don't need/want it > without a technical reason. > > And quite frankly I think the build dependency should be to the package > that is needed directly and not through another one. > IMO the move of col needs to be rolled back ASAP. And, if it is to happen again, it needs to be managed properly and not break reverse deps without notice. Cheers, Julien
Bug#961245: marked as pending in mercurial
Control: tag -1 pending Hello, Bug #961245 in mercurial reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/python-team/applications/mercurial/-/commit/4cf9254d50bee3f2106b53dc4984e68b641c998e Don't install the hgext.git extension That namespace is used by the mercurial-git package, and ours is still very experimental. Closes: #961245 (this message was generated automatically) -- Greetings https://bugs.debian.org/961245
Bug#961245: mercurial-common: trying to overwrite '/usr/lib/python2.7/dist-packages/hgext/git/__init__.py', which is also in package mercurial-git 0.8.12-1.2
On Fri, May 22, 2020 at 10:46:29AM +0200, Jakub Wilk wrote: > * Axel Beckert , 2020-05-22, 00:22: > > dpkg: error processing archive > > /var/cache/apt/archives/mercurial-common_5.4-1_all.deb (--unpack): > > trying to overwrite > > '/usr/lib/python2.7/dist-packages/hgext/git/__init__.py', which is also in > > package mercurial-git 0.8.12-1.2 > > dpkg-deb: error: paste subprocess was killed by signal (Broken pipe) > > Errors were encountered while processing: > > /var/cache/apt/archives/mercurial-common_5.4-1_all.deb > > Note that there's no such conflict upstream, because hg-git installs the > module as "hggit" (not in the "hgext" namespace). > > This mess is my fault. When I packaged hg-git in 2009, it was so immature it > didn't even have installation scripts. Instead their README said: > > > Clone this repository somewhere and make the 'extensions' section in > > your `~/.hgrc` file look something like this: > > > >[extensions] > >hgext.bookmarks = > >hgext.hg-git = [path-to]/hg-git > > I decided to install it as a public module "hgext.git", without even talking > to upstream. In retrospect, it was a terrible idea. :-( > > Ideally this should be fixed by renaming the hg-git's module back to what > upstream uses. But of course this is going to break all hg-git users' > configurations. :-/ > I wonder if it's still early enough to ask mercurial upstream to rename theirs. Given https://www.mercurial-scm.org/repo/hg/file/5.4/hgext/git/__init__.py#l3 I'll fix this issue for now by not shipping it in the package, so we get some time to figure out the next step. Cheers, Julien
Bug#932296: qa.debian.org: getwatch filling up /tmp
On Wed, Jun 17, 2020 at 07:00:43 +0100, Adam D. Barratt wrote: > On Wed, 2020-06-17 at 00:14 +0200, Lucas Nussbaum wrote: > > Apparently the condition where this happens is quite rare > > occurences on 08/2019, 12/2019, 06/2020), so notifying me after the > > files were cleaned up from /tmp makes it hard to identify which > > packages cause this issue. If I could get notified when a warning > > limit is reached, it would be much easier to debug. > > I'm not sure what the usual policy on that is, but I didn't clean up > /tmp after disabling the importer last night: > > drwx-- 3 udd uddadm 4096 Jun 16 20:20 getwatch.qmapshack.n13QHA > drwx-- 3 udd uddadm 4096 Jun 16 20:20 getwatch.picard-tools.Zg0jud > drwx-- 3 udd uddadm 4096 Jun 16 20:50 getwatch.qmapshack.aH184l > drwx-- 3 udd uddadm 4096 Jun 16 20:50 getwatch.picard-tools.SqIkjD > drwx-- 3 udd uddadm 4096 Jun 16 21:20 getwatch.qmapshack.1pIg10 > drwx-- 3 udd uddadm 4096 Jun 16 21:20 getwatch.picard-tools.g3weib > drwx-- 3 udd uddadm 4096 Jun 16 21:50 getwatch.qmapshack.oklPSa > drwx-- 3 udd uddadm 4096 Jun 16 21:50 getwatch.picard-tools.Lo3UhJ > This is how it looked before reboot yesterday, according to my terminal's scroll buffer: jcristau@ullmann:~$ ls -l /tmp/getwatch.* -d drwx-- 3 udd uddadm 4096 Jun 16 12:50 /tmp/getwatch.deepin-icon-theme.dXa34U drwx-- 3 udd uddadm 4096 Jun 16 12:20 /tmp/getwatch.deepin-icon-theme.EDzB2B drwx-- 3 udd uddadm 4096 Jun 16 11:20 /tmp/getwatch.deepin-icon-theme.fG5L65 drwx-- 3 udd uddadm 4096 Jun 16 13:50 /tmp/getwatch.deepin-icon-theme.GKeDmI drwx-- 3 udd uddadm 4096 Jun 16 10:50 /tmp/getwatch.deepin-icon-theme.JiwELJ drwx-- 3 udd uddadm 4096 Jun 16 14:20 /tmp/getwatch.deepin-icon-theme.kgoDIn drwx-- 3 udd uddadm 4096 Jun 16 09:50 /tmp/getwatch.deepin-icon-theme.kqqITx drwx-- 3 udd uddadm 4096 Jun 16 13:20 /tmp/getwatch.deepin-icon-theme.p0Lknv drwx-- 3 udd uddadm 4096 Jun 16 10:20 /tmp/getwatch.deepin-icon-theme.sMzg7u drwx-- 3 udd uddadm 4096 Jun 16 11:50 /tmp/getwatch.deepin-icon-theme.uSHETI drwx-- 3 udd uddadm 4096 Jun 16 11:20 /tmp/getwatch.htsjdk.eC4uvs drwx-- 3 udd uddadm 4096 Jun 16 11:50 /tmp/getwatch.htsjdk.EU4suU drwx-- 3 udd uddadm 4096 Jun 16 14:20 /tmp/getwatch.htsjdk.kih83R drwx-- 3 udd uddadm 4096 Jun 16 12:20 /tmp/getwatch.htsjdk.L9J9LA drwx-- 3 udd uddadm 4096 Jun 16 10:20 /tmp/getwatch.htsjdk.m2FgS0 drwx-- 3 udd uddadm 4096 Jun 16 10:50 /tmp/getwatch.htsjdk.MwALoV drwx-- 3 udd uddadm 4096 Jun 16 09:50 /tmp/getwatch.htsjdk.N7bIVe drwx-- 3 udd uddadm 4096 Jun 16 13:20 /tmp/getwatch.htsjdk.NRopqF drwx-- 3 udd uddadm 4096 Jun 16 13:50 /tmp/getwatch.htsjdk.wEFDNs drwx-- 3 udd uddadm 4096 Jun 16 12:50 /tmp/getwatch.htsjdk.Wqf6gL drwx-- 3 udd uddadm 4096 Jun 16 09:50 /tmp/getwatch.picard-tools.BfwMyC drwx-- 3 udd uddadm 4096 Jun 16 12:20 /tmp/getwatch.picard-tools.gY2ZQk drwx-- 3 udd uddadm 4096 Jun 16 12:50 /tmp/getwatch.picard-tools.I1wZDY drwx-- 3 udd uddadm 4096 Jun 16 11:50 /tmp/getwatch.picard-tools.JG01pg drwx-- 3 udd uddadm 4096 Jun 16 14:20 /tmp/getwatch.picard-tools.KawVh5 drwx-- 3 udd uddadm 4096 Jun 16 11:20 /tmp/getwatch.picard-tools.l0wUag drwx-- 3 udd uddadm 4096 Jun 16 13:20 /tmp/getwatch.picard-tools.oVJAT9 drwx-- 3 udd uddadm 4096 Jun 16 13:50 /tmp/getwatch.picard-tools.SdFotX drwx-- 3 udd uddadm 4096 Jun 16 10:50 /tmp/getwatch.picard-tools.Tq98F0 drwx-- 3 udd uddadm 4096 Jun 16 10:20 /tmp/getwatch.picard-tools.zPqqVr drwx-- 3 udd uddadm 4096 Jun 16 12:20 /tmp/getwatch.qmapshack.B3SMHo drwx-- 3 udd uddadm 4096 Jun 16 10:20 /tmp/getwatch.qmapshack.hADG4I drwx-- 3 udd uddadm 4096 Jun 16 13:20 /tmp/getwatch.qmapshack.I1X2xV drwx-- 3 udd uddadm 4096 Jun 16 09:50 /tmp/getwatch.qmapshack.i8ooLp drwx-- 3 udd uddadm 4096 Jun 16 11:20 /tmp/getwatch.qmapshack.JRgmcP drwx-- 3 udd uddadm 4096 Jun 16 13:50 /tmp/getwatch.qmapshack.k7ujsc drwx-- 3 udd uddadm 4096 Jun 16 10:50 /tmp/getwatch.qmapshack.muqRD1 drwx-- 3 udd uddadm 4096 Jun 16 11:50 /tmp/getwatch.qmapshack.VkgQed drwx-- 3 udd uddadm 4096 Jun 16 14:20 /tmp/getwatch.qmapshack.W00S3T drwx-- 3 udd uddadm 4096 Jun 16 12:50 /tmp/getwatch.qmapshack.zPrnz7 Cheers, Julien
Bug#932296: qa.debian.org: getwatch filling up /tmp
On Wed, Dec 18, 2019 at 02:03:13PM +0100, Julien Cristau wrote: > Control: severity -1 serious > > On Thu, Aug 08, 2019 at 01:45:27PM +0200, Julien Cristau wrote: > > On Wed, Jul 17, 2019 at 10:11:39PM +0200, Lucas Nussbaum wrote: > > > On 17/07/19 at 14:01 +0200, Julien Cristau wrote: > > > > something in udd seems to extract entire source packages to > > > > /tmp/getwatch.*. This fills up the disk. Please make it not do that. > > > > > > Hi, > > > > > > Thanks for reporting. > > > > > > It needs to extract the source packages to get the watch file. I don't > > > think there's a way to ask dpkg-source to only extract a single file, > > > and I don't want to re-implement dpkg-source. > > > > > It would be a single call to tar or patch though, which doesn't seem > > like a huge amount of effort. > > > > > Reviewing the code, there was a path where the tmp dir was not removed. > > > I've fixed that. I'm not 100% sure this fixes everything, but it should > > > clearly help. > > > > > There were quite a few getwatch temp dirs before I rebooted ullmann just > > now because it was out of space. > > > > > However, I also note that /tmp is on /, and / is quite small (only 5.3 > > > GB remaining). Would it be possible to add some disk space for /tmp or / > > > on ullmann? > > > > > I'd dispute the "quite small" bit, extracting watch files shouldn't need > > more than 5g. But you could also put your temp files somewhere under > > /srv? > > > This happened again. If it won't get fixed I'll go ahead and disable that > job. > Done now, removed the "upstream" importer from the config file. Cheers, Julien
Bug#962218: gnutls28: build fails on IPv6-only buildds
On Thu, Jun 04, 2020 at 11:19:31PM +0200, Julien Cristau wrote: > The arch:all failure is at grnet and that buildd has both v4 and v6 > addresses, so presumably unrelated. > A further give-back seems to have worked, so 3.6.13-4 managed to build on all arches and move to testing now. Cheers, Julien
Bug#962218: gnutls28: build fails on IPv6-only buildds
On Thu, Jun 4, 2020 at 22:18:10 +0300, Adrian Bunk wrote: > On Thu, Jun 04, 2020 at 07:55:32PM +0200, Julien Cristau wrote: > > Control: tag -1 moreinfo > > > > On Thu, Jun 04, 2020 at 07:59:22PM +0300, Adrian Bunk wrote: > > > FAIL: dtls_hello_random_value > > > = > > > > > > testing: default > > > client:156: client: Handshake failed: Resource temporarily unavailable, > > > try again. > > > server:271: server: Handshake has failed: The TLS connection was > > > non-properly terminated. > > > > > > FAIL dtls_hello_random_value (exit status: 1) > > > > > This particular test seems to use a AF_UNIX socketpair, I'm not sure > > how it would fail due to network setup? > > I copied the log from the 3.6.13-4 arm64 failure. > This specific test passes in the other logs. > > The binary-all log (non-conova) of 3.6.13-4 has no test failures, > but the build fails due to timeout after 150 minutes without output. > > My gut feeling is that there might be an (unrelated) problem with > the #961889 fix, but this is just a guess. > The arch:all failure is at grnet and that buildd has both v4 and v6 addresses, so presumably unrelated. Which leaves us with the armel failure (on arm-conova-03) which does look related to the lack of public v4 address, e.g.: > FAIL: sni-hostname.sh > = > > Checking SNI hostname in gnutls-cli > Echo Server listening on IPv6 :: port 26448...done > Could not connect to 127.0.0.1:26448: Connection refused > Failure: 1. handshake should have succeeded! > Exiting via signal 15 > FAIL sni-hostname.sh (exit status: 1) If we listen on :: and then try to connect to 127.0.0.1, that won't work. And indeed gnutls-serv seems to call getaddrinfo with node == NULL and hints.ai_flags == AI_PASSIVE|AI_ADDRCONFIG, to figure out what address to listen on. If the host has no non-local ipv4 address, that getaddrinfo call returns :: but not 0.0.0.0; and then the test hardcodes 127.0.0.1 as the address for gnutls-cli to connect to, and sadness ensues. Cheers, Julien
Bug#962218: gnutls28: build fails on IPv6-only buildds
On Thu, Jun 04, 2020 at 07:32:13PM +0200, Andreas Metzler wrote: > On 2020-06-04 Adrian Bunk wrote: > > Source: gnutls28 > > Version: 3.6.13-2 > > Severity: serious > > Tags: ftbfs > > > https://buildd.debian.org/status/logs.php?pkg=gnutls28=3.6.13-3 > > https://buildd.debian.org/status/logs.php?pkg=gnutls28=3.6.13-4 > > > ... > [...] > > > The conova buildds are IPv6-only, see #962019 for a similar > > problem in perl. > > Helo Adrian, > > is there a way to declare a dependency on IPv4 for building? > > Also the setup is strange, both netstat and ifconfig show IPv4: > eth0 has no ipv4, that's all. Why is that strange? Cheers, Julien
Bug#962218: gnutls28: build fails on IPv6-only buildds
Control: tag -1 moreinfo On Thu, Jun 04, 2020 at 07:59:22PM +0300, Adrian Bunk wrote: > FAIL: dtls_hello_random_value > = > > testing: default > client:156: client: Handshake failed: Resource temporarily unavailable, try > again. > server:271: server: Handshake has failed: The TLS connection was non-properly > terminated. > > FAIL dtls_hello_random_value (exit status: 1) > This particular test seems to use a AF_UNIX socketpair, I'm not sure how it would fail due to network setup? Cheers, Julien
Bug#962019: perl: arch:all build fails on buildd (transient error?)
Control: tag -1 patch On Tue, Jun 02, 2020 at 08:09:43AM +0200, Salvatore Bonaccorso wrote: > On Tue, Jun 02, 2020 at 06:40:41AM +0200, Salvatore Bonaccorso wrote: > > Source: perl > > Version: 5.30.3-1 > > Severity: serious > > Justification: FTBFS > > > > Hi Dom an Niko > > > > Guess you have seen it but filling a bug for tracking. arch:all build > > failed on buildd: > > > > https://buildd.debian.org/status/fetch.php?pkg=perl=all=5.30.3-1=1591057198=0 > > FTR, the issue is that the build got picked up by a IPv6-only enabled > buildd. FWIW, it seems IO::Socket::IP passes AI_ADDRCONFIG to getaddrinfo, which then doesn't return ipv4 addresses because the host doesn't have non-local ones, even though the address we're trying to resolve is "127.0.0.1". Passing either GetAddrInfoFlags => AI_NUMERICHOST or GetAddrInfoFlags => 0 to both IO::Socket::IP->new calls in the test file lets it pass, by turning off the smarts in getaddrinfo. Cheers, Julien
Bug#938544: sphinx-patchqueue: Python2 removal in sid/bullseye
Hi Dmitry, mercurial in experimental is built for python3, is there a chance you could test sphinx-patchqueue with it before I upload to sid? Thanks, Julien
Bug#960598: fontconfig: diff for NMU version 2.13.1-4.2
Control: tags 960598 + patch
Control: tags 960598 + pending
Dear maintainer,
I've prepared an NMU for fontconfig (versioned as 2.13.1-4.2) and
uploaded it to DELAYED/0. (The -4.1 NMU ran into bug #960679 so I need
to do a new upload anyway, figured I'd fix this while at it.)
Also at
https://salsa.debian.org/freedesktop-team/fontconfig/-/merge_requests/7
Cheers,
Julien
diff -Nru fontconfig-2.13.1/debian/changelog fontconfig-2.13.1/debian/changelog
--- fontconfig-2.13.1/debian/changelog 2020-05-13 12:21:13.0 +0200
+++ fontconfig-2.13.1/debian/changelog 2020-05-15 12:55:02.0 +0200
@@ -1,3 +1,11 @@
+fontconfig (2.13.1-4.2) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Hopefully this otherwise dummy upload lets us work around bug #960679.
+ * Add missing Breaks for the -doc package split (closes: #960598)
+
+ -- Julien Cristau Fri, 15 May 2020 12:55:02 +0200
+
fontconfig (2.13.1-4.1) unstable; urgency=medium
* Non-maintainer upload.
diff -Nru fontconfig-2.13.1/debian/control fontconfig-2.13.1/debian/control
--- fontconfig-2.13.1/debian/control 2020-05-13 12:15:26.0 +0200
+++ fontconfig-2.13.1/debian/control 2020-05-15 12:55:02.0 +0200
@@ -134,6 +134,7 @@
Build-Profiles:
Depends: ${misc:Depends}
Replaces: libfontconfig1-dev (<< 2.13.1-3)
+Breaks: libfontconfig1-dev (<< 2.13.1-3)
Description: generic font configuration library - documentation
Fontconfig is a font configuration and customization library, which
does not depend on the X Window System. It is designed to locate
Bug#960679: fontconfig: strict dependency of arch:any libfontconfig1 on arch:all fontconfig-config going wrong
Source: fontconfig
Version: 2.13.1-2
Severity: serious
libfontconfig1 Depends on fontconfig-config (>= ${source:Version})
If the arch:amd64 buildd is faster than the arch:all one, as happened
with 2.13.1-4.1, the new libfontconfig1 becomes uninstallable, and,
because fontconfig indirectly build-depends on libfontconfig1, that
situation can't fix itself.
One way around that is to make fontconfig-config arch:any; there may be
other solutions.
Cheers,
Julien
Bug#959828: systemctl: `Provides: systemd`, but doesn't provide what systemd does
On Thu, May 07, 2020 at 09:48:34PM +1000, Dmitry Smirnov wrote: > On Thursday, 7 May 2020 7:04:17 PM AEST Julien Cristau wrote: > > This use of Provides is not acceptable. The systemctl package does not > > in any way provide the same functionality / interfaces as the systemd > > package, and as such it does not get to pretend that it does and cause > > problems to other packages. > > I have to challenge that. "systemctl" provides enough functionality to > replace "systemd" inside application containers. Therefore there are > situations where "Provides: systemd" is justified. > That's not what "Provides" means though. What you're saying is "systemctl provides a subset of the systemd package's functionality". That's not good enough. Provides is much stronger than "there are cases where this might be enough", and there's more to systemd than systemctl. Also, per policy §3.6, virtual packages outside the defined agreed-upon names should only be used "amongst a cooperating group of packages". It seems clear to me this is neither of those cases. You're welcome to try and convince either the systemd maintainers to split some of the functionality to separate binary packages, or the php-fpm maintainer to forgo using functionality that is only available in systemd, but abusing package relationships the way you're doing now is just not on. Cheers, Julien
Bug#932794: xorg: X server crashes when unplugging dock station (Intel hw with kernel modesetting)
Control: reassign -1 xserver-xorg-core 2:1.20.4-1 Control: tag -1 important On Tue, Jul 23, 2019 at 01:31:36PM +0200, Lucas Nussbaum wrote: > Since upgrading from Debian 9 to Debian 10, I experience crashes when > unplugging my dock station. > > The end of the log is: > > [ 12796.678] (II) AIGLX: Suspending AIGLX clients for VT switch > [ 12797.533] (II) libinput: DELL081C:00 044E:121F Touchpad: SetProperty on > 318 called but device is disabled. > This driver cannot change properties on a disabled device > [ 12798.120] (II) AIGLX: Resuming AIGLX clients after VT switch > [ 12798.387] (EE) modeset(0): failed to set mode: No such file or directory > [ 12798.388] (EE) > Fatal server error: > [ 12798.388] (EE) EnterVT failed for screen 0 > [ 12798.388] (EE) > [ 12798.388] (EE) > Please consult the The X.Org Foundation support > at http://wiki.x.org > for help. > [ 12798.388] (EE) Please also check the log file at "/var/log/Xorg.0.log" for > additional information. > [ 12798.388] (EE) > [ 12798.388] (II) AIGLX: Suspending AIGLX clients for VT switch > [ 12799.328] (EE) Server terminated with error (1). Closing log file. > > I will investigate further but wanted to file a bug first in case this > is a known issue. (I found no obvious bug reports for that) > > A workaround is to switch to the "intel" driver as suggested in > https://bugzilla.redhat.com/show_bug.cgi?id=1630367#c18 > but this has other limitations. > Hi, if this is still an issue please file it upstream at https://gitlab.freedesktop.org/xorg/xserver/-/issues Cheers, Julien
Bug#959698: tmux: "incompatible server protocol change" does not seem acceptable
Package: tmux Version: 3.1-1 Severity: serious Hi, on apt upgrade in testing today I was greeted by this NEWS entry from tmux saying: The server protocol was changed in an incompatible manner, we recommend that you close any open tmux sessions before proceeding with the upgrade. I don't think that's acceptable. Running upgrades inside screen or tmux is a best practice, so IMO it needs to work, and people need to be able to re-attach to existing sessions across the upgrade. And even if it was acceptable to do this, NEWS.Debian is displayed 1) too late for the user to do anything about it, 2) in English. See #683228 for what seems like a similar issue in screen back in the day. Cheers, Julien -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'testing'), (101, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.5.0-2-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages tmux depends on: ii libc6 2.30-4 ii libevent-2.1-7 2.1.11-stable-1 ii libtinfo6 6.2-1 ii libutempter01.1.6-6 tmux recommends no packages. tmux suggests no packages. -- no debconf information
Bug#880233: [PosibleSpam] Re: Bug#880233: fixed in openbsc 0.15.0-3
On Sun, Apr 26, 2020 at 18:28:07 +0200, Santiago Vila wrote: > On Sun, Apr 26, 2020 at 06:09:53PM +0200, Julien Cristau wrote: > > On Wed, Dec 27, 2017 at 11:42:35PM +0100, Santiago Vila wrote: > > > reopen 880233 > > > thanks > > > > > > Hi. > > > > > > Reopening because this also happens in stretch. > > > (Packages in stable must be buildable in stable) > > > > > But bugs get closed when they're fixed in sid. [...] > > Usually, but not always, so I disagree. If the BTS was only to track > what happens in sid, it would be impossible to use it to track a > package in stable which FTBFS in stable and has been removed from > testing and sid. > That's not true, we do that all the time. Cheers, Julien
Bug#948610: mercurial: calls python instead of python2
Control: severity -1 wishlist On Fri, Jan 10, 2020 at 08:54:07PM +0100, Gianfranco Costamagna wrote: > Severity: serious Why? Cheers, Julien
Bug#937808: python-hglib: diff for NMU version 2.6.1-1.1
On Tue, Dec 31, 2019 at 18:25:04 -0500, Sandro Tosi wrote: > On Tue, Dec 31, 2019 at 6:11 PM Julien Cristau wrote: > > > > Nak. I don't want to drop python support at this stage. > > can you explain why? there is no package in debian depending on > python-hglib, and in a week it will be auto-removed from testing > because of this > Because I find this removal premature and distasteful. I was hoping my downgrading this bug would be a hint, but you decided to ignore that. Cheers, Julien
Bug#937808: python-hglib: diff for NMU version 2.6.1-1.1
Nak. I don't want to drop python support at this stage. Julien On December 31, 2019 11:58:44 PM GMT+01:00, Sandro Tosi wrote: >Control: tags 937808 + patch > > >Dear maintainer, > >I've prepared an NMU for python-hglib (versioned as 2.6.1-1.1). The >diff >is attached to this message. > >Regards.
Bug#945993: diffoscope: FAILED tests/test_source.py::test_code_is_black_clean - assert 228381 == 0
On Mon, Dec 02, 2019 at 07:37:02PM +, Chris Lamb wrote:
> Hi Julien,
>
> > It seems to me the test is inherently extremely sensitive to the exact
> > version of black used, so it probably shouldn't be part of autopkgtests?
>
> Mmm, except I anticipated this at the time with the following
> commit:
>
>
> https://salsa.debian.org/reproducible-builds/diffoscope/commit/aefa5a39bb5f86f21cb67f94a013aa2c9bc4b69d
>
> At a quick guess, I think this is problem caused by the autopkgtests
> being run without the pyproject.toml. As in:
>
> --- a/debian/tests/pytest
> +++ b/debian/tests/pytest
> @@ -14,7 +14,7 @@ fi
>
> for py in $(py3versions -s); do
> echo " Running against $py"
> -cp -r tests "$AUTOPKGTEST_TMP"
> +cp -r tests pyproject.toml "$AUTOPKGTEST_TMP"
> (cd "$AUTOPKGTEST_TMP"; "$py" -m pytest -vv -l -r a)
> rm -rf "${AUTOPKGTEST_TMP:?}"/*
> done
>
> … will likely fix this.
>
>
Aha. Thanks for the quick reply and fix!
Cheers,
Julien
Bug#945993: diffoscope: FAILED tests/test_source.py::test_code_is_black_clean - assert 228381 == 0
Package: diffoscope Severity: serious Tags: bullseye sid X-Debbugs-Cc: bl...@packages.debian.org diffoscope autopkgtests fail with the current version of "black" in sid: https://ci.debian.net/data/autopkgtest/unstable/amd64/d/diffoscope/3557636/log.gz It seems to me the test is inherently extremely sensitive to the exact version of black used, so it probably shouldn't be part of autopkgtests? Cheers, Julien
Bug#945041: openfoam: severe build time regression
Source: openfoam Version: 1906+dfsg1-1 Severity: serious Hi, Looking at https://buildd.debian.org/status/logs.php?pkg=openfoam the build time for your package increased unreasonably in this version. Cheers, Julien
Bug#944362: hgsubversion: incompatible with mercurial 5.2
Package: hgsubversion
Version: 1.9.3+git20190419+6a6ce-1
Severity: grave
Tags: bullseye sid
The current version of hgsubversion in sid doesn't work with hg 5.2, as
evidence by the autopkgtest failing.
Specifically, the mercurial.repository module moved to
mercurial.interfaces.repository. Changing that in
hgsubversion/svnrepo.py lets the autopkgtest pass:
--- hgsubversion-1.9.3+git20190419+6a6ce.orig/hgsubversion/svnrepo.py
+++ hgsubversion-1.9.3+git20190419+6a6ce/hgsubversion/svnrepo.py
@@ -23,7 +23,7 @@ from mercurial import util as hgutil
peerapi = 0
try:
try:
-from mercurial.repository import peer as peerrepository
+from mercurial.interfaces.repository import peer as peerrepository
peerapi = 1
except ImportError:
from mercurial.peer import peerrepository
(Obviously this breaks earlier versions but should be easy enough to fix
up)
Incidentally, I made some changes to the test to clean up better when it
fails:
diff -Nru hgsubversion-1.9.3+git20190419+6a6ce/debian/tests/hgsubversion
hgsubversion-1.9.3+git20190419+6a6ce/debian/tests/hgsubversion
--- hgsubversion-1.9.3+git20190419+6a6ce/debian/tests/hgsubversion
2019-09-16 19:30:22.0 +0200
+++ hgsubversion-1.9.3+git20190419+6a6ce/debian/tests/hgsubversion
2019-11-08 16:03:13.0 +0100
@@ -3,10 +3,18 @@
set -e
SVN_ROOT=$(mktemp --tmpdir -d hgsubversion.X)
-mkdir -p $SVN_ROOT
+testdir=$(pwd)
PID_FILE=/tmp/svnmock.pid
+cleanup () {
+ # Kill the server and cleanup
+ kill $(cat $PID_FILE)
+ rm -rf $SVN_ROOT
+ rm -rf $testdir/celesteville
+}
+trap cleanup EXIT
+
# Create a local svn server with an empty repo
svnadmin create $SVN_ROOT/celesteville
cat > $SVN_ROOT/celesteville/conf/svnserve.conf << EOF
@@ -33,10 +41,4 @@
echo Arthur >> people
hg commit -u "Babar " -m "Add more people"
hg --config extensions.hgsubversion= push
-cd ..
-
-# Kill the server and cleanup
-kill $(cat $PID_FILE)
-rm -rf $SVN_ROOT
-rm -r celesteville
-- System Information:
Debian Release: bullseye/sid
APT prefers testing-debug
APT policy: (500, 'testing-debug'), (500, 'stable-updates'), (500,
'stable-debug'), (500, 'testing'), (500, 'stable'), (101, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 5.2.0-3-amd64 (SMP w/28 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages hgsubversion depends on:
ii mercurial 5.2-1
ii python2.7.17-1
ii python-subvertpy 0.10.1-3
ii subversion1.10.6-1+b1
hgsubversion recommends no packages.
hgsubversion suggests no packages.
-- no debconf information
