Bug#1059535: transition: abseil
On Monday, April 1, 2024, at 2:57 PM +0200, Sebastian Ramacher wrote: > Could you please re-add the build dependency on dpkg-dev (>= 1.22.5) to > ensure that the build with the new armel/armhf ABI only migrates when > the time_t transition is ready to advance? Yes! I am going to wait for the current upload (20230802.1-3) to finish building on RISC-V, just to make sure the FTBFS is fixed. (It’s already 11 hours in; it can’t take too much longer.) Once that’s done, I’ll upload a new 20230802.1-4 with a Build-Depends: dpkg-dev (>= 1.22.5). (If you’d prefer that I preempt the current build and upload 20230802.1-4 right now, just let me know.)
Bug#1059535: transition: abseil
On Friday, March 29, 2024, at 1:02 PM +0100, Sebastian Ramacher wrote: > Since the version in unstable fails to build on armel and armhf and > blocks the time_t transition, but the version in experimental builds > fine, let's do this transition now. > > With the upload to unstable, please check the FTBFS issue on risc64, > though. Sounds good. I never did get around to uploading 20240116 to experimental. I’ll upload 20230802 to unstable this weekend, and I’ll come back for 20240116 later. Upstream has accepted [1], which should fix the FTBFS on riscv64. It should be an easy backport to 20230802. I’ll make sure it’s included when I do the upload this weekend. [1] https://github.com/abseil/abseil-cpp/commit/7335a36d0b5c1c597566f9aa3f458a5b6817c3b4
Bug#1059535: transition: abseil
I’d like to alter this transition request. Instead of transitioning to version 20230802, I’d like to transition to version 20240116, which upstream recently released. Is that okay? If so, I’ll upload 20240116 to experimental and reexamine reverse dependencies. If not, please let me know how to proceed; a 20230802 -> 20240116 upgrade would require a second transition, and I don’t want to create extra work.
Bug#1059535: transition: abseil
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition X-Debbugs-Cc: abs...@packages.debian.org, Rene Engelhard Control: affects -1 + src:abseil Abseil 20230802 has been out for a while, and I'd like to transition sid to it. The new version has a new ABI (with a new SONAME and new binary package names). Tests for 20230802.1-2 in experimental are green on all supported architectures except mips64el and riscv64. mips64el had no installable libc when the builders ran; I expect it'll be fine when the transition actually happens. Large parts of Abseil (including the version already in sid) are broken on riscv64 right now because of https://bugs.debian.org/1059532; transitioning doesn't introduce any new issues. A number of packages in sid depend directly on Abseil. To give early warning of breakages, I've done trial rebuilds as appropriate on the amd64 porterbox. Packages that work fine with the new version: - grpc - libgav1 - libphonenumber - mujoco - open-vm-tools - ycmd Packages that are broken by the new version: - mozc: FTBFS because it depends on a symbol in the absl::internal namespace that changed without warning - re2: FTBFS because it needs changes to some symbols files - s2geometry: FTBFS because it hard-codes std=c+11 and the new version requires -std=c++14 or later (https://bugs.debian.org/1059228) - webrtc-audio-processing: FTBFS because it relies on transitive #includes that have changed Packages that I'm not sure about: - dm-tree: has an active FTBFS (https://bugs.debian.org/1055686) - ortools: has an active FTBFS (https://bugs.debian.org/1024790) - libreoffice: too big to build on a porterbox, so left untested Although doing a transition now will break some packages in sid, I believe waiting is likely to cause more issues. Upstreams (LibreOffice in particular) are starting to use features from the new version of Abseil, and keeping the old version in sid is starting to create work for other DDs. The breakages in sid will have to be fixed eventually anyway, and none of them should be challenging to repair. Ben file: title = "abseil"; is_affected = .depends ~ /\blibabsl20220623\b/ | .depends ~ /\blibabsl20230802\b/; is_good = .depends ~ /\blibabsl20230802\b/; is_bad = .depends ~ /\blibabsl20220623\b/;
Bug#1059532: abseil:riscv64: uses privileged rdcycle instruction
Source: abseil Version: 20220623.1-1 Severity: normal Tags: upstream Control: forwarded -1 https://github.com/abseil/abseil-cpp/pull/1550 On RISC-V, Abseil's cycle counter uses the rdcycle instruction, which is a privileged instruction when running on Debian's Linux kernels. This causes some widely used Abseil functions (e.g., certain member functions on absl::Mutex) to crash with a SIGILL.
Bug#1059340: libstdc++6:riscv64: stream output for NaN is optimization-dependent
Control: user debian-ri...@lists.debian.org Control: usertag 1059340 + riscv64 Just to be clear, I've only observed this behavior on riscv64.
Bug#1059340: libstdc++6:riscv64: stream output for NaN is optimization-dependent
Package: libstdc++6
Version: 13.2.0-9
Streaming a negative NaN float produces "-nan" with g++ -O0 and "nan"
with g++ -O1 or above:
$ cat >mwe.cc < // Copyright 2023 Google LLC
> // SPDX-License-Identifier: Apache-2.0
>
> #include
> #include
>
> int main() { std::cerr << std::bit_cast(0xfff8) << '\n'; }
> EOF
$ g++ -std=c++20 -O0 mwe.cc && ./a.out
nan
$ g++ -std=c++20 -O1 mwe.cc && ./a.out
-nan
$ clang++ -std=c++20 -O0 mwe.cc && ./a.out
nan
$ clang++ -std=c++20 -O1 mwe.cc && ./a.out
-nan
For comparison, on amd64, this program always produces "-nan",
regardless of optimization level.
Tested with g++-13 13.2.0-9 and clang-16 1:16.0.6-19.
Bug#1059228: build system hard-codes -std=c++11
Source: s2geometry Version: 0.10.0-6 Severity: normal s2geometry's CMakeLists.txt includes # s2geometry needs to use the same C++ standard that absl used to avoid # undefined symbol errors since ABSL_HAVE_STD_STRING_VIEW etc will # end up defined differently. There is probably a better way to achieve # this than assuming what absl used. set(CMAKE_CXX_STANDARD 11) set(CMAKE_CXX_STANDARD_REQUIRED ON) # No compiler-specific extensions, i.e. -std=c++11, not -std=gnu++11. set(CMAKE_CXX_EXTENSIONS OFF) to pass -std=c++11 to GCC. This causes s2geometry's build to fail when built against Abseil 20230802 (currently in experimental), since that release of Abseil requires C++14 or later. Fortunately, this entire stanza is unnecessary for Debian. Debian's Abseil packages are patched to ensure that these preprocessor symbols will be defined the same way regardless of the standard used during compilation. In fact, Abseil 20220623.1, as deployed to bookworm/trixie/sid right now, is built in C++14 mode. An upgrade to s2geometry commit 30f70725a4cc76da9cf77c394092e479027eb8ac or later will fix the build with Abseil 20230802. If you’d prefer not to do an upgrade, simply removing this entire stanza fixes the issue as well.
Bug#1034668: Please update to new upstream release 3.22.3 in experimental
I will do an upload of 20230802.0 to experimental today, but I don’t think it fixes this issue. scoped_mock_log depends on symbols in GoogleMock, but there’s no good way to express those dependencies in a hypothetical libabsl_scoped_mock_log.so since libgmock.so doesn’t exist. The way upstream (Google) intends for all this to work is for protobuf to link its Abseil and GoogleMock dependencies statically. Is that possible? If not, I have some alternative ideas (like building a libabsl_scoped_mock_log.so without a DT_NEEDED entry for GoogleMock), but they all seem like hacks. I’m also open to other ideas if anybody has them.
Bug#1043299: xterm: build with ReGIS support
Package: xterm Version: 384-1 Severity: wishlist Xterm supports ReGIS (DEC vector graphics) emulation, but it’s not compiled in by default. Would you be willing to add `--enable-regis-graphics` to the `configure` invocation in debian/rules?
Bug#1037567: abseil: ftbfs with GCC-13
Thank you for the patch, Aurelien! I’ve applied it to the 20220623.1 release and uploaded it to unstable as 20220623.1-2.
Bug#1037567: abseil: ftbfs with GCC-13
I’ve been procrastinating on starting the transition because of some lingering MIPS issues. I think they’ve all been sorted out, and I just uploaded my latest work to experimental. If that passes the buildds, I’ll request a transition slot and do the transition as quickly as possible. If waiting on the transition is going to unacceptably delay the riscv64 bootstrap, please let me know. I think I know which patches I would have to backport to 20220623 to get it to build with GCC 13, so I may be able to fix this in unstable before the transition completes.
Bug#1037567: abseil: ftbfs with GCC-13
Control: fixed -1 20230125.3 Control: forwarded -1 https://github.com/abseil/abseil-cpp/issues/1366 Control: owner -1 ! Control: tags -1 upstream fixed-upstream fixed-in-experimental This has been resolved in the 20230125 series, which is currently in experimental and will be included in trixie after it transitions.
Bug#1034908: Update libabsl-dev to new upstream version/snapshot for newer protobuf
Control: owner 1034908 ! On Sun, 30 Apr 2023 22:29:27 -0500 Steven Robbins wrote: > The reported build error is: > > dpkg-shlibdeps: error: cannot find library libgtest.so.1.12.1 needed by > debian/libabsl20230125/usr/lib/x86_64-linux-gnu/ > libabsl_per_thread_sem_test_common.so.20230125.0.0 > (ELF format: 'elf64-x86-64' abi: '0201003e'; RPATH: '') > > How did libabsl20230125 get such a dependency? Debian has never shipped > libgtest.so -- was this built against a locally-built libgtest > somehow? Yes. Historically, Abseil has dynamically linked its unit tests against a one-off libgtest.so built from /usr/src/googletest. Depending on the local libgtest.so was never a problem because Abseil never shipped any public libraries that depended on GoogleTest. As of 20230125, however, Abseil ships a library that (a) is intended for public consumption and (b) depends on GoogleTest, which brings us to this issue. > My recommendation is to preferably build libgtest in your own build process > -- > this ensures gtest is built with the same compiler options as your test code; > or else link against the provided static libgtest.a. On Mon, 1 May 2023 18:39:06 +0530 Praveen Arimbrathodiyil wrote: > I will leave it to abseil maintainer to decide which approach to take. I’m about to do an upload to experimental that encourages the first option. abseil 20230125.3-1 and later will avoid shipping dynamic libraries for any Abseil library that depends on googletest; library consumers will have to manually link against libgtest. This only affects consumers who want to use Abseil libraries that involve GoogleTest (e.g., libabsl_scoped_mock_log). Thank you both for bringing this to my attention, and thank you, Praveen, for all the work you’ve done keeping Abseil going in Debian!
Bug#1033466: libabsl-dev: Please update ASAP
Control: owner 1033466 ! I’ll get 20230125.1 into experimental soon.
Bug#1025221: abseil: please consider disabling tests on riscv64
Control: owner 1025221 ! Control: tags 1025221 - patch Hi, Manuel, Yesterday, I tried a build on a porterbox with your patch. It looks like disabling parallelism improves the situation but does not completely solve it; absl_mutex_test is still flaky. I’ll continue investigating and see if I can get that test fixed. In the meantime, it looks like a recent binNMU to Abseil on riscv64 has passed the buildds. Does that unblock your work?
Bug#1018804: libabsl20220623: [!amd64] cordz statistics may be racy
I’ve uploaded 0~20220623.0-2, which skips the problematic test, to unblock the libabsl20210324-to-libabsl20220623 transition (see [1] et seq.). [1] https://lists.debian.org/debian-release/2022/08/msg00702.html (https://lists.debian.org/msgid-search/26fc0675-3232-23de-0149-83b703c4a...@debian.org)
Bug#1018804: libabsl20220623: [!amd64] cordz statistics may be racy
Package: libabsl20220623 Version: 0~20220623.0-1 Per [1], absl_cordz_info_statistics_test crashes on ppc64el. Investigation on a porterbox shows the test fails pretty consistently under asan and tsan. The test passes on amd64. I’ll continue investigating this; in the meantime, be aware that requesting cordz statistics may yield incorrect results (or may even invoke undefined behavior) on non-amd64 platforms. [1] https://buildd.debian.org/status/fetch.php?pkg=abseil=ppc64el=0%7E20220623.0-1=1661859644=0
Bug#1008730: abseil: Please update to latest upstream version
Quick update – googletest 1.12 is in sid, and I’m working now to package Abseil 20220623.
Bug#1012194: abseil: tests spuriously fail due to overly restrictive TZ handling
Source: abseil Version: 0~20210324.2-4 Tags: ftbfs If the TZ environment variable is set to anything other than America/Los_Angeles, America/New_York, Australia/Sydney, US/Pacific, or /etc/localtime, absl_time_test fails with “Unexpected time zone”. For example, TZ=/usr/share/zoneinfo/Etc/GMT+12 produces [ RUN ] TimeZone.LocalTimeZone [test_util.cc : 117] RAW: Unexpected time zone "/usr/share/zoneinfo/Etc/GMT+12" in test This occurs because absl_time_test builds a small, incomplete tzdata database into the test binary and uses that instead of the system tzdata database. (Some of upstream’s supported platforms lack proper tzdata support, and embedding a test-only database is just the easiest way to make tests work everywhere.) Upstream seems receptive to adding a fallback mechanism to their fake database. This would resolve unhandled TZ settings like /usr/share/zoneinfo/Etc/GMT+12 to America/Los_Angeles, which appears sufficient to make the tests pass. Alternatively, Debian could patch out the built-in tzdata database, since we can guarantee that the tests always run with a real system tzdata database installed.
Bug#1011294: libabsl-dev: spurious -Wl flag in some pkg-config entries
Package: libabsl-dev
Version: 0~20210324.2-3
Some of the pkg-config files installed with libabsl-dev contain errors.
For instance, absl_base.pc contains
Libs: -L${libdir} -Wl -labsl_base
The extra -Wl causes compilation to fail with
g++: error: unrecognized command-line option ‘-Wl’; did you mean ‘-W’?
Bug#1009246: New Upstream Version
Control: tags 1009246 + pending I’ve updated the packaging for 1.5.1; upload incoming. Thanks for your work on preliminary packaging! It looks like there’s still some discussion about libayatana-appindicator going on upstream [1], so I’ve left it out of this upload. I’ve filed https://bugs.debian.org/1009274 to track enabling libayatana-appindicator support. [1] https://github.com/transmission-remote-gtk/transmission-remote-gtk/pull/184
Bug#1009274: transmission-remote-gtk: reenable appindicator support using libayatana-appindicator
Package: transmission-remote-gtk Version: 1.4.1-5 Severity: wishlist This bug, split from https://bugs.debian.org/1009246, tracks reenabling appindicator support using libayatana-appindicator. There’s currently an open discussion with upstream about adding libayatana-appindicator support to their build system [1]. That said, I believe we can’t link against libayatana-appindicator due to license issues: transmission-remote-gtk is GPL-2-only because of some files like [2], while libayatana-appindicator is GPL-3-only because of some files like [3]. Upstream has indicated that they’d like to rid themselves of the GPL-2 restriction [4] but that it’s likely to be challenging [5]. [1] https://github.com/transmission-remote-gtk/transmission-remote-gtk/pull/184 [2] https://sources.debian.org/src/transmission-remote-gtk/1.4.1-5/src/torrent-cell-renderer.c/ [3] https://sources.debian.org/src/libayatana-appindicator/0.5.91-1/src/generate-id.c/ [4] https://github.com/transmission-remote-gtk/transmission-remote-gtk/pull/184#issuecomment-1094307680 [5] https://github.com/transmission-remote-gtk/transmission-remote-gtk/issues/21
Bug#1007136: abseil: Please disable tests on affected targets to unblock rdepends
Control: retitle 1007136 abseil: NominalCPUFrequency tests are bogus Control: tags 1007136 + pending Looks like upstream has disabled the broken NominalCPUFrequency tests entirely, so I’ve backported that patch. This should unbreak sparc64 and possibly some other platforms as well. Since this bug seems to have been triggered by the SPARC breakage, I’m going to go ahead and close it in my next upload. I am currently working to make the Abseil tests pass not only on official Debian architectures but on port targets as well; I don’t want to see LLVM get blocked. If there are specific architectures you’d like to me to prioritize, please let me know or file bugs for them.
Bug#1007136: abseil: Please disable tests on affected targets to unblock rdepends
Given how low-level Abseil is, I’m a little reluctant to just disable the entire testsuite. I agree that the sysinfo test is broken, though, so I’ll definitely turn that off (or just fix it).
Bug#1008730: abseil: Please update to latest upstream version
The latest Abseil release requires a prerelease version of googletest, so I’m deliberately waiting to package it. I’ve mentioned the problem to people who work on googletest at Google, and a new googletest upstream release is in the pipeline. In the meantime, I’d be happy to backport some patches – are there any that you’ve identified as good candidates?
Bug#1004043: git-annex: test --pattern can segfault
Package: git-annex Version: 8.20210223-2 Severity: normal Passing certain patterns to `git annex test -p` causes a segfault: $ git annex test -p 'Tests.Unit Tests v8 locked.move' error: git-annex died of signal 11 Other patterns work fine: $ git annex test -p Tests.QuickCheck.prop_VectorClock_sane Tests QuickCheck prop_VectorClock_sane: OK +++ OK, passed 1 test. All 1 tests passed (0.00s) Running all the tests (i.e., `git annex test` without `-p`) also works fine, and all the tests pass.
Bug#1002708: python3-gleetex: needs Depends: dvisvgm
Package: python3-gleetex Version: 3.1.0-1 Severity: serious SVG output from GleeTeX relies on executing dvisvgm; if that's not installed, attempting to emit SVG will throw an exception. Either GleeTeX or GladTeX needs Depends: dvisvgm; since python3-gleetex already has Depends: dvipng, it seems like the right place.
Bug#1002707: katex: needs Depends: node-commander
Package: katex
Version: 0.10.2+dfsg-8
Severity: serious
Installing katex without node-commander yields an unusable katex
executable.
$ katex
internal/modules/cjs/loader.js:818
throw err;
^
Error: Cannot find module 'commander'
Require stack:
- /usr/share/nodejs/katex/cli.js
at Function.Module._resolveFilename
(internal/modules/cjs/loader.js:815:15)
at Function.Module._load (internal/modules/cjs/loader.js:667:27)
at Module.require (internal/modules/cjs/loader.js:887:19)
at require (internal/modules/cjs/helpers.js:74:18)
at Object. (/usr/share/nodejs/katex/cli.js:23:17)
at Module._compile (internal/modules/cjs/loader.js:999:30)
at Object.Module._extensions..js
(internal/modules/cjs/loader.js:1027:10)
at Module.load (internal/modules/cjs/loader.js:863:32)
at Function.Module._load (internal/modules/cjs/loader.js:708:14)
at Function.executeUserEntryPoint [as runMain]
(internal/modules/run_main.js:60:12) {
code: 'MODULE_NOT_FOUND',
requireStack: [ '/usr/share/nodejs/katex/cli.js' ]
}
Installing node-commander fixes the problem.
Bug#1001405: xnec2c: blocks UI on file system sync
Package: xnec2c Version: 1:4.1.1-2 Tags: upstream Control: found -1 1:4.2-1 Control: forwarded -1 https://github.com/KJ7LNW/xnec2c/issues/1 xnec2c blocks the UI on sync(2) every time it closes a FILE (see https://sources.debian.org/src/xnec2c/1:4.2-1/src/utils.c/#L281). On file systems where sync is slow (e.g., ZFS), this can translate to multiple seconds of unresponsive UI at apparently random times during program execution. For the time being, I think Debian should probably just patch out the sync call. It’s not necessary for the program to function, and most people probably don’t expect their antenna simulator to be crash-safe. Until this gets resolved, running xnec2c under eatmydata seems to work fine.
Bug#992814: suckless-tools: stest handles dotfiles only in working directory
Package: suckless-tools Version: 44-1 File: /usr/bin/stest Tags: upstream stest’s hidden file pruning is implemented as a simple `name[0] != '.'` check, which produces confusing behavior when examining paths with more than one component. For example, users expect `foo` and `./foo` to refer to the same file, but for stest, these are different: /etc$ ls passwd passwd /etc$ echo passwd | stest -f passwd /etc$ echo ./passwd | stest -f /etc$ Users would also likely be surprised by stest’s inclusion of hidden files inside subdirectories: $ mkdir foo $ touch foo/.bar $ echo foo/.bar | stest -f foo/.bar $
Bug#987314: libabsl20200923: symbolizer miscomputes Thumb function bounds on armhf/armel
Package: libabsl20200923 Version: 0~20200923.3-2 Tags: upstream fixed-upstream pending The Abseil symbolizer has an off-by-one error when computing bounds for Thumb functions. This can cause it to symbolize incorrectly in binaries that contain both ARM and Thumb functions. signature.asc Description: PGP signature
Bug#987021: mosh: should use /usr/bin/perl #! line
Package: mosh Version: 1.3.2-2.1+b1 Severity: minor /usr/bin/mosh starts with #!/usr/bin/env perl for portability. On Debian, however, Perl is always installed at /usr/bin/perl; mosh should be patched to use the correct #! line. signature.asc Description: PGP signature
Bug#955271: libreoffice-common: AppArmor profile blocks gpg's tofu.db, causes hang opening Options
Control: tags 955271 + patch
I ran into this today and figured out the necessary patch for the
AppArmor profile to make gpg useful under a tofu+pgp trust model. I’ve
attached it as a diff to the Debian source package. Might it be possible
to get it into the archive?
On Tue, 14 Jul 2020 20:01:19 +0200 Rene Engelhard wrote:
> AppArmor allows only explicitely allowed stuff, and you can't simply
> allow anything as that would defeat the sense of apparmor.
I believe this patch does not break the security of the AppArmor
profile. It only widens access to include the GnuPG tofu.db file, which
doesn’t exist unless the user has explicitly opted into the tofu+pgp
trust model.
Best,
Benjamin
--- libreoffice-7.1.2.2/debian/patches/apparmor-gnupg-tofu.diff
+++ libreoffice-7.1.2.2/debian/patches/apparmor-gnupg-tofu.diff
@@ -0,0 +1,28 @@
+From: Benjamin Barenblat
+Subject: Support tofu+pgp trust model in GnuPG
+Bug-Debian: https://bugs.debian.org/955271
+Forwarded: no
+
+GnuPG supports a trust-on-first-use layer that sits on top of the
+standard PGP trust model. If this is enabled, 'gpg --list-keys' needs
+write and lock permissions on the TOFU database to return any useful
+data. Allow this access through AppArmor.
+
+--- libreoffice-7.1.2.2/sysui/desktop/apparmor/program.soffice.bin
libreoffice-7.1.2.2/sysui/desktop/apparmor/program.soffice.bin
+@@ -2,6 +2,7 @@
+ #
+ #Copyright (C) 2016 Canonical Ltd.
+ #Copyright (C) 2018 Software in the Public Interest, Inc.
++#Copyright (C) 2021 Google LLC
+ #
+ #This Source Code Form is subject to the terms of the Mozilla Public
+ #License, v. 2.0. If a copy of the MPL was not distributed with this
+@@ -215,6 +216,7 @@ profile gpg {
+
+ owner @{HOME}/.gnupg/* r,
+ owner @{HOME}/.gnupg/random_seed rk,
++owner @{HOME}/.gnupg/tofu.db rwk,
+ }
+
+ # probably should become a subprofile like gpg above, but then it doesn't
--- libreoffice-7.1.2.2/debian/patches/series
+++ libreoffice-7.1.2.2/debian/patches/series
@@ -46,3 +46,4 @@
pdfium-use-system-libopenjpeg.diff
apparmor-updates.diff
filter-out-lto-flags.diff
+apparmor-gnupg-tofu.diff
signature.asc
Description: PGP signature
Bug#985305: xmobar: date plugin does not handle DST correctly
Package: xmobar Version: 0.36-2 Tags: upstream fixed-upstream The xmobar date plugin does not properly detect changes in the system time zone, which means that shifts in and out of daylight saving time (summer time) aren’t handled correctly. This is upstream bug 494 [1] and was fixed in commit a58e32f7c8af7b03410ab6693019cfc92c9cfca3 [2]. [1] https://github.com/jaor/xmobar/issues/494 [2] https://github.com/jaor/xmobar/commit/a58e32f7c8af7b03410ab6693019cfc92c9cfca3 signature.asc Description: PGP signature
Bug#983936: abseil: ftbfs with -march=x86-64-v3
Control: tags 983936 + pending upstream This is a bug in the test – it’s too sensitive to fused multiply/add contraction. I’ve mailed upstream a patch to make the test more robust. I expect the patch will be accepted today or tomorrow, at which point I’ll backport it to the current release. signature.asc Description: PGP signature
Bug#984433: neofetch: should use /bin/bash #! line
Package: neofetch Version: 6.0.0-2 Severity: minor neofetch starts with #!/usr/bin/env bash for portability. On Debian, however, Bash is always installed at /bin/bash; neofetch should be patched to use the correct #! line. signature.asc Description: PGP signature
Bug#984432: neofetch: missing Recommends for pciutils
Source: neofetch Version: 6.0.0-2 Invoking neofetch on my laptop causes it to invoke lspci to get GPU information. It’s possible to disable this behavior, but neofetch should probably Recommend pciutils. signature.asc Description: PGP signature
Bug#984431: neofetch: missing Recommends for some image display tools
Source: neofetch Version: 6.0.0-2 Neofetch can invoke a number of external programs to display images in the terminal. These aren’t invoked by default, but they will be if the user specifies the appropriate flag, so they should be Recommends. Relevant packages include caca-utils (for /usr/bin/img2txt) imagemagick (for /usr/bin/identify, /usr/bin/convert, etc.) jp2a (for /usr/bin/jp2a) libsixel-bin (for /usr/bin/img2sixel) w3m-img (for /usr/lib/w3m/w3mimgdisplay) signature.asc Description: PGP signature
Bug#981199: noweb: Please package 2.12
Source: noweb Severity: normal Noweb 2.12 has been released and includes a number of bug fixes and general improvements. It would be great for it to appear in Debian. Nicolas: I’m CC’ing you because you just did an NMU to make a whole bunch of improvements to the current package. Thank you for your work! If in the process you discovered anything relevant to packaging 2.12, I’d love to hear about it. signature.asc Description: PGP signature
Bug#977638: g++-10:s390x: Large classes of std::bitset and std::vector hash the same
Package: g++-10
Version: 10.2.1-1
Severity: normal
On s390x, std::hash returns identical values for large classes of
std::bitset and std::vector:
$ cat bug.cc
#include
#include
#include
#include
int main() {
std::bitset<2> a("00"), b("01");
std::vector c = {false, true, false, true};
std::vector d = {true, false, true, false};
std::bitset<9> e("0"), f("010101010");
std::vector g = {true, true, true, true, true, true, true, true,
true};
std::vector h = {false, false, false, true, true,
false, false, false, false};
std::hash> h1;
std::hash> h2;
std::hash> h3;
std::cout << h1(a) << '\n'
<< h1(b) << '\n'
<< h3(c) << '\n'
<< h3(d) << "\n\n"
<< h2(e) << '\n'
<< h2(f) << '\n'
<< h3(g) << '\n'
<< h3(h) << '\n';
}
$ g++ -o bug bug.cc
$ ./bug
7857072875483051545
7857072875483051545
7857072875483051545
7857072875483051545
4158372090644325695
4158372090644325695
4158372090644325695
4158372090644325695
It appears that the hash value is completely dependent on the size of
the object in bytes. 1–8-bit values all hash to 7857072875483051545;
9–16-bit values all hash to 4158372090644325695; and though bug.cc
doesn’t demonstrate it, 17-bit values hash to 14756137038141193723.
signature.asc
Description: PGP signature
Bug#973492: abseil: Please consider explicitly enable -latomic with armel build
On Tuesday, November 3, 2020, at 10:27 AM -0500, Benjamin Barenblat wrote: > [...] the CMake support files that get installed with libabsl-dev should > probably specify -latomic on armel [...]. I think a single patch might > be able to do both of these [...] It turns out Abseil upstream doesn’t have a great way of specifying dependencies on external libraries in their CMake support files. So far, this hasn’t been an issue, probably because most projects using the CMake support files are happy with the default dynamic linking, where dependencies are handled by the loader. But I’m now more skeptical that a single patch will solve both of these issues. I’ll continue investigation, but in the meantime, I’m going to do an upload with -latomic in the right places. That should solve the build problems on armel. signature.asc Description: PGP signature
Bug#973492: abseil: Please consider explicitly enable -latomic with armel build
Control: owner 973492 ! Control: tags 973492 + upstream Control: forwarded 973492 https://github.com/abseil/abseil-cpp/issues/836 Indeed, some of the shared libraries need to be built with -latomic on armel. In addition, the CMake support files that get installed with libabsl-dev should probably specify -latomic on armel; otherwise, anybody using CMake to link statically will run into the same issue. I think a single patch might be able to do both of these; I’m going to do some more research this week and see if I can make it happen. I’ll plan to do an upload on Friday at the latest; if that’s too far in the future, let me know, and I’ll do a stopgap upload to fix the libgav1 FTBFS. signature.asc Description: PGP signature
Bug#973669: ksh: ignores tracked aliases during execution
Package: ksh
Version: 93u+20120801-3.4+deb10u1
Severity: normal
Tags: upstream
ksh doesn’t pay attention to tracked aliases during execution – it
always does a PATH search:
$ strace -e signal=none -P /usr/local/bin/ls -P /usr/bin/ls -P /bin/ls ksh
+E
$ ls -a
stat("/usr/local/bin/ls", 0x7ffde8d749c0) = -1 ENOENT (No such file or
directory)
stat("/usr/bin/ls", 0x7ffde8d749c0) = -1 ENOENT (No such file or
directory)
stat("/bin/ls", {st_mode=S_IFREG|0755, st_size=138856, ...}) = 0
lstat("/bin/ls", {st_mode=S_IFREG|0755, st_size=138856, ...}) = 0
. ..
$ whence -a ls
ls is a tracked alias for /bin/ls
$ ls -a
stat("/usr/local/bin/ls", 0x7ffde8d749c0) = -1 ENOENT (No such file or
directory)
stat("/usr/bin/ls", 0x7ffde8d749c0) = -1 ENOENT (No such file or
directory)
stat("/bin/ls", {st_mode=S_IFREG|0755, st_size=138856, ...}) = 0
lstat("/bin/ls", {st_mode=S_IFREG|0755, st_size=138856, ...}) = 0
. ..
This is inefficient. It’s also surprising, given that tracked aliases
were originally intended to avoid PATH lookups in cases like this.
This appears to have been first noticed in 2011 by Siddhesh Poyarekar.
marc.info has mangled the thread a bit, but I think it’s
https://marc.info/?i=AANLkTinva-vek-y4CrNPdMic9b_HaFMmKVv=+3tnh...@mail.gmail.com
└ https://marc.info/?i=201102161622.p1ggmyvv022...@penguin.research.att.com
├
https://marc.info/?i=AANLkTi=ktorzlncfmck16yxackrd6rkljv5ywszfc...@mail.gmail.com
│ ├
https://marc.info/?i=aanlktikiufzexcrxxkx8ckbgm2-tbwg6f1r2+rotw...@mail.gmail.com
│ └ https://marc.info/?i=rca1529.4d5d6c3...@rightcore.com
└ https://marc.info/?i=20110307172636.34716...@zaphod.usersys.redhat.com
-- System Information:
Debian Release: 10.6
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Versions of packages ksh depends on:
ii binfmt-support 2.2.0-2
ii libc6 2.28-10
ksh recommends no packages.
ksh suggests no packages.
-- no debconf information
signature.asc
Description: PGP signature
Bug#972827: libgiac-dev: should include config.h
Package: libgiac-dev Version: 1.4.9.69+dfsg1-2 Severity: grave Many Giac headers #include "config.h", and they use its contents in such a way that config.h is essential to define the library ABI. (For example, some members are gated behind #ifdef HAVE_LIBPTHREAD.) Developing against Giac without the exact config.h generated during the library build thus triggers an ABI mismatch, usually manifesting as a segfault. Requiring Giac’s config.h is unfortunate, and upstream recognizes it – giac/gen.h includes the note // FIXME: macros defined in config.h are not welcome in a public header! Until that FIXME is resolved, though, Debian needs to ship Giac’s config.h with the other Giac headers. signature.asc Description: PGP signature
Bug#971768: abseil: FTBFS on hppa - needs porting
On Tuesday, October 6, 2020, at 8:59 PM +, John David Anglin wrote: > The attached change enables abseil to build successfully on hppa. This is fantastic – thanks. I’ve got a few pending changes of this sort for other architectures; I’ll plan to include yours in the next upload. May I assume that you wish to contribute this patch under the Apache License, version 2.0, as is used throughout the rest of Abseil? Best, Benjamin signature.asc Description: PGP signature
Bug#970943: googletest: Please package post-2020-09-20 Git snapshot
Source: googletest Version: 1.10.0-3 Per the current googletest readme [1], googletest has abandoned numbered releases. Since the last numbered release, upstream has added support for a few useful features, notably the `GTEST_ALLOW_UNINSTANTIATED_PARAMETERIZED_TEST` macro. Would you be willing to upload a Git snapshot to the archive? [1] https://github.com/google/googletest/blob/fe4d5f10840c5f62b984364a4d41719f1bc079a2/README.md
Bug#970333: abseil: autopkgtest needs update for new version of cmake: warning on stderr
Control: owner 970333 ! Control: tags 970333 + pending upstream fixed-upstream Control: forwarded 970333 https://github.com/abseil/abseil-cpp/issues/668 This is a bug in upstream’s CMake support. I’ll patch in their fix (https://github.com/abseil/abseil-cpp/commit/68494aae959dfbbf781cdf03a988d2f5fc7e4802).
Bug#969387: ITP: wyhash -- fast, high-quality, portable hash function
Package: wnpp Severity: wishlist Owner: Benjamin Barenblat * Package name: wyhash Version : 0~1.gbpd15d6e7 Upstream Author : Wang Yi * URL : https://github.com/wangyi-fudan/wyhash * License : Unlicense Programming Lang: C Description : fast, high-quality, portable hash function Wyhash is a general-purpose non-cryptographic hash function. It produces high-quality output that passes the SMHasher test suite and is portable to 32- and 64-bit big- and little-endian platforms. Wyhash is small and quite fast, especially on 64-bit platforms. Wyhash is a header-only library, so there will only be a -dev package. There are some tags in the Wyhash Git repository, but none seems to correspond to what we would normally think of as a release; they seem more to indicate fundamental algorithm revisions. I’ll package and maintain this as a series of Git snapshots.
Bug#967077: universal-ctags: install alternatives entry for etags
Package: universal-ctags Version: 0+git20181215-2 Severity: wishlist Control: found -1 0+git20191013-1 I’d like to set ctags-universal as the etags on my system, but there’s no alternatives entry for it. An entry in the postinst/prerm à la exuberant-ctags [1] would fix this. [1] https://sources.debian.org/src/exuberant-ctags/1:5.9~svn20110310-13/debian/postinst/#L7
Bug#965217: libgrpc++1: ServerBuilder::BuildAndStart hangs
I’ve just reuploaded Abseil with an shlibs file instead of a symbols file. The symbols file doesn’t buy us a whole lot anyway, since Abseil is going to break ABI with every release.
Bug#966183: abseil FTBFS on !amd64/ppc64: missing symbols
On Friday, July 24, 2020, at 2:58 PM +0300, Adrian Bunk wrote: > When the soname of the library encodes the exact upstream > version as abseil does, there are exactly zero benefits > of using a symbols - every update of abseil will be a > library transition in any case. Makes sense. I was hoping to stick with the symbols infrastructure because it’s what I’m familiar with, but I’m completely convinced at this point that it’s going to be more trouble than it’s worth. I’ll reupload today with shlibs instead.
Bug#965217: libgrpc++1: ServerBuilder::BuildAndStart hangs
On Wednesday, July 22, 2020, at 6:22 PM +0200, László Böszörményi (GCS) wrote: > Benjamin, please upload abseil to Sid when you have time. I just did so. I've successfully built it on all official architectures manually, so I don't expect any build failures, but I'll keep an eye on the builders nonetheless.
Bug#963767: RFP: mathjax-node-page -- filter for server-side MathJax rendering
Package: wnpp Severity: wishlist * Package name: mathjax-node-page Version : 3.2.0 Upstream Author : Peter Krautzberger * URL : https://github.com/pkra/mathjax-node-page/ * License : Apache-2.0 Programming Lang: JavaScript Description : filter for server-side MathJax rendering MathJax is a widely adopted math typesetter for web-based applications. It allows you to embed TeX code in HTML and have it rendered in users’ browsers. However, because the rendering occurs in-browser, MathJax can be slow and resource-intensive. mjpage(1), included in the mathjax-node-page package, offers an alternative approach: it reads HTML from standard input, generates the DOM that MathJax would produce, and serializes that DOM into HTML on standard output. This effectively prerenders the mathematics, removing load from users’ browsers and improving load times. Since mjpage(1) uses MathJax as a library, the output is guaranteed to be identical to that produced by the in-browser renderer. mathjax-node-page’s dependency tree has some packages that aren’t yet packaged or need attention in Debian, but I haven’t investigated them too fully. No word on how much work is required here.
Bug#888705: abseil-cpp packaging
On Sat, May 23, 2020 at 2:39 PM Benjamin Barenblat wrote: > This is now in the NEW queue. On Friday, June 19, 2020, at 8:07 AM +0200, László Böszörményi (GCS) wrote: > Not anymore and not in the archives. What happened? Can I help? ftp-master rejected the upload with concerns that changing the names of all those small binary packages every time an ABI break occurs could cause too much churn in the archive. That’s an easy fix, though – just consolidate the shared libraries into a single binary package. You actually caught me at an opportune time; I just redid the upload, and it should reappear in NEW shortly. So there’s no work to be done at present, but I’ll let you know if ftp-master has further concerns. Benjamin
Bug#888705: abseil-cpp packaging
This is now in the NEW queue.
Bug#888705: abseil-cpp packaging
On Tuesday, May 19, 2020, at 8:59 PM +0200, László Böszörményi (GCS) wrote: > Doesn't build with GCC 10 due to symbol changes. Good point. Is there an established way to deal with this? Or should I just upload this as-is to unstable and then upload a GCC-10-compatible version to experimental? > How do you plan Git tagging? Might be better to prefix current tags with > 'upstream/' and have Debian releases under 'debian/'. I generally try to keep upstream’s tags intact so that no signatures get broken. Abseil doesn’t currently sign tags, but they might in the future, and I’d be a bit bummed if we couldn’t benefit from that. I think it’s totally reasonable to put Debian releases under debian/, so if you prefer that approach, I’ll make sure to prefix my tags. > Rules-Requires-Root might be set to 'no' I guess, but that's nitpicking. Today I learned about Rules-Requires-Root! I’ve fixed that and pushed the change. On Wednesday, May 20, 2020, at 12:03 PM +0200, László Böszörményi (GCS) wrote: > Please do build static libraries with the following patch. This is great – thanks! I’m still unfamiliar with CMake; I really appreciate you figuring out the incantations to get it to build both. As written, this patch builds shared libraries first and then archives, which causes abslTargets.cmake to prefer archives over shared objects when linking against Abseil. I’d like to modify it to go in the other order, thus preferring shared libraries over archives. Requiring an explicit opt-in before using Abseil archives would make it more difficult to accidentally violate the One Definition Rule by accidentally double-linking an Abseil archive. Furthermore, it would create less work for packagers trying to use the shared Abseil libraries, which I expect will be the usual case inside Debian. Does that sound reasonable?
Bug#888705: abseil-cpp packaging
Okay, we’re all set. I’ve pushed my work to https://salsa.debian.org/debian/abseil, and both command-line linking and CMake integration work. Comments and suggestions are welcome – if I don’t hear anything in the next day or two, I’ll go ahead and upload to NEW. I had to disable the Abseil testsuite to get CMake integration to work. The CMake files that Abseil installs are autogenerated, and if you enable the testsuite, the generator adds a bunch of googletest dependencies. This is unfortunate, and I’ll file a bug with upstream to try to get it fixed. In the meantime, I’ve manually verified that the tests pass. Benjamin
Bug#960730: libanyevent-irc-perl: does not verify TLS server certificates
Package: libanyevent-irc-perl Version: 0.97-2 Control: tag -1 + upstream AnyEvent::IRC supports connecting to IRC servers over TLS. When connecting, though, it does not verify that server certificates are valid. An invalid TLS certificate is better than no TLS at all, but users (and many developers) have come to expect that a successful TLS connection guarantees confidentiality, authenticity, and integrity even in the face of active interception. AnyEvent::IRC’s behavior is inconsistent with that expectation. Ideally, AnyEvent::IRC would refuse to connect to a server unless that server presents a valid TLS certificate or the API consumer has explicitly opted out of certificate verification. If backward compatibility is a concern, AnyEvent::IRC could could preserve the existing behavior by default but allow API consumers to opt in to certificate verification; this is a smaller improvement, but it would be an improvement nonetheless.
Bug#888705: abseil-cpp packaging
On Thursday, May 7, 2020, at 6:32 PM +0200, László Böszörményi (GCS) wrote: > If I understand correctly, you retained src:abseil. If not and using > src:abseil-cpp then you need a new repository named after that. Which > way should I go? If it’s all right with you, I’d prefer to stick with src:abseil. That more closely matches the way the terminology is used within Google – “Abseil” is unambiguously the C++ project, and “Abseil Python” is its Python counterpart. Benjamin
Bug#960444: brightnessctl: support fractional percentages
Package: brightnessctl Version: 0.4-1 Severity: wishlist Control: found -1 0.5.1-2 Control: tag -1 + upstream Control: forwarded -1 https://github.com/Hummer12007/brightnessctl/issues/50 It would be great if I could pass fractional percentage values to brightnessctl – e.g., brightnessctl set 0.5%. It looks like all the percentage calculations occur on the FPU anyway, so this could probably be done simply by changing value.val to be a float and using strtof to parse it.
Bug#920555: xmobar: compile flag with_alsa to support Volume command
Control: tag 920555 + patch It looks like `with_alsa` was turned off due to missing dependencies, but the dependencies are all packaged in bullseye. I’ve attached a patch to update the package with the new dependencies and enable the flag. diff -Naur a/debian/control b/debian/control --- a/debian/control +++ b/debian/control @@ -6,6 +6,8 @@ Source: xmobar Standards-Version: 4.5.0 Build-Depends: debhelper-compat (=12), ghc, + libghc-alsa-core-dev [linux-any], + libghc-alsa-mixer-dev (>= 0.3) [linux-any], libghc-dbus-dev [linux-any], libghc-extensible-exceptions-dev, libghc-hinotify-dev [linux-any], diff -Naur a/debian/copyright b/debian/copyright --- a/debian/copyright 2019-01-14 15:02:30.0 -0500 +++ b/debian/copyright 2020-05-03 19:57:33.954104115 -0400 @@ -11,6 +11,7 @@ Files: debian/* Copyright: Copyright 2008-2019 Apollon Oikonomopoulos Copyright 2018 Aggelos Avgerinos + Copyright 2020 Google LLC License: BSD-3-Clause Files: examples/xmonadpropwrite.hs diff -Naur a/debian/README.Debian b/debian/README.Debian --- a/debian/README.Debian 2018-11-14 02:55:08.0 -0500 +++ b/debian/README.Debian 2020-05-03 19:57:33.954104115 -0400 @@ -7,10 +7,10 @@ Plugin notes -- The Mail, MBox and Wireless plugins are Linux-specific and have been +- The Alsa, Mail, MBox and Wireless plugins are Linux-specific and have been disabled in non-Linux architectures (kFreeBSD, Hurd). - The MPRIS and DBus plugins require haskell-dbus, which is currently broken for non-linux platforms and so they are enabled only for Linux. -- The mpd, alsa and datezone plugins are disabled to missing dependencies. +- The mpd and datezone plugins are disabled to missing dependencies. diff -Naur a/debian/rules b/debian/rules --- a/debian/rules 2019-01-14 18:39:34.0 -0500 +++ b/debian/rules 2020-05-03 19:57:33.954104115 -0400 @@ -15,7 +15,7 @@ CONFIGURE_OPTS = --ghc-options="$(GHC_OPTIONS)" ifeq ($(DEB_HOST_ARCH_OS),linux) -CONFIGURE_OPTS += --flags="with_xft with_inotify with_iwlib with_mpris with_dbus with_xpm with_uvmeter with_conduit" +CONFIGURE_OPTS += --flags="with_xft with_inotify with_iwlib with_alsa with_mpris with_dbus with_xpm with_uvmeter with_conduit" else CONFIGURE_OPTS += --flags="with_xft with_xpm" endif
Bug#888705: abseil-cpp packaging
I’m getting very close to an Abseil upload. The CMake integration doesn’t work yet, but I can install the binary packages and build software that links Abseil. I’m going to keep working on CMake support, but I’d love to upload what I have to Salsa. Would somebody be willing to reset the https://salsa.debian.org/debian/abseil repository to a pristine state so I can push to it without any of the old history in that repo? I’d do it myself, but Google has some weird rules about creating new repositories; it would be much easier for me if someone else could create the repo and give me push access.
Bug#959675: libgrpc++1: endless looping with default settings
That sounds 100% feasible. I’ll give Abseil packaging some more attention this week and get back in touch.
Bug#888705: Bug#959675: libgrpc++1: endless looping with default settings
On Sunday, May 3, 2020, at 8:16 PM +0200, László Böszörményi (GCS) wrote: > Benjamin, do you want to package and maintain [Abseil] instead? I’ve been working on packaging it for the last few weeks, and I’m making good progress. Would an upload this week fit your timetable?
Bug#888705: abseil-cpp packaging
On Sunday, February 16, 2020, at 10:48 PM +0100, László Böszörményi (GCS) wrote: > @Benjamin: may you ask its developers to use the system gtest libraries > if only ABSL_RUN_TESTS set to ON? On Tuesday, February 18, 2020, at 6:02 PM -0500, Benjamin Barenblat wrote: > I have a preliminary version of such a patch, and I’ll try to get it > finished and sent in the next day or two; that way, even if upstream > lags taking it, we can import it and get the support we need. It took me a bit longer than I’d hoped, but https://github.com/abseil/abseil-cpp/pull/628 will let you test against the gtest in Debian simply by passing `-DABSL_RUN_TESTS=ON -DABSL_USE_GOOGLETEST_HEAD=OFF` to CMake. It looks like I just missed the LTS release of a few hours ago, but just patching this in should be fine. I’ll try to have a look at the packaging in Salsa before the end of this week.
Bug#888705: abseil-cpp packaging
On Tuesday, February 18, 2020, at 9:01 PM +0100, László Böszörményi (GCS) wrote: > There's a compatibility page[1] what Abseil is and isn't. It states > the following things. > "We do not promise any ABI compatibility — we intend for Abseil to be > built from source, hopefully from head. The internal layout of our > types may change at any point, without notice." > As I read waiting for LTS releases might be late (its head commit > version advised to be used). I guess other Google applications other > libraries commonly wants newer Abseil releases than LTS ones. I think that’s accurate. The culture at Google emphasizes continuous integration from head rather than coding against releases. However, this isn’t just about Google applications. There are other F/OSS projects that want to take an Abseil dependency and aren’t ready to commit to that sort of development model – see, for instance, https://github.com/darktable-org/rawspeed/issues/122 (“Stop reinventing the wheel”), in which Darktable investigates taking an Abseil dependency and decides to wait until the LTS story is fully hammered out. The Abseil team understands that the F/OSS world expects stable ABIs; they’re going to break ABI all over the place at head, but they’re not going to go out of their way to break it within an LTS release. > "Not all Abseil libraries are suitable for dynamic loading. Some > libraries have startup/initialization requirements and may not be > suitable for dynamic loading. We will try to be clear about which > libraries are OK for dynamic loading. However we don’t generally > deploy code in this fashion, mistakes are possible, [...]". > That is, even shared libraries can be built, those are not guaranteed to work. I don’t think we should shy away from providing functionality just because upstream doesn’t guarantee it to work. It’s true that the Abseil developers don’t test Abseil as .so’s, but testing exists in Debian for a reason. If Debian ships an Abseil .so, and bugs appear in testing, we can work with upstream to fix them or patch them ourselves if upstream is nonresponsive. I did discuss the initialization issues with an Abseiler today; he doesn’t know the full story, but he knows somebody within Abseil is working on making initialization more lazy (and therefore more .so-compatible). If you’re interested, I can discuss that with them at our next meeting and let you know what the story is. > I think there should be a compatibility matrix or test if the latest > LTS release is enough for most Google applications or those need newer > versions (no new API added for recent application development). Agreed – there should definitely be some testing involved. For what it’s worth, the next LTS is likely to be cut from head before the end of the week. For a little while afterward, at least, nobody should need anything newer than what’s in the LTS. On Sunday, February 16, 2020, at 10:48 PM +0100, László Böszörményi (GCS) wrote: >>> @Benjamin: may you ask its developers to use the system gtest libraries >>> if only ABSL_RUN_TESTS set to ON? On Monday, February 17, 2020, at 8:21 PM -0500, Benjamin Barenblat wrote: >> Absolutely. I’ll bring it up with them at work tomorrow (today was a US >> holiday). I spoke with an Abseiler today about this. He believes that Abseil definitely needs to support that, but there’s still some consensus-building that needs to happen within the team before we can guarantee that upstream will take a patch for it. I have a preliminary version of such a patch, and I’ll try to get it finished and sent in the next day or two; that way, even if upstream lags taking it, we can import it and get the support we need.
Bug#888705: abseil-cpp packaging
On Tuesday, February 18, 2020, at 9:25 AM +0100, Olaf van der Spek wrote: > What about the C++ std version? Abseil / C++14 isn't the same as Abseil / > C++17. This is true on two levels: 1. By default, Abseil detects what standard version you’re building with and conditionally defines its types to be type aliases when appropriate. For instance, in C++11, `absl::make_unique` is an actual function; in C++14 and later, `absl::make_unique` is an alias for `std::make_unique`. The next LTS release will have a CMake toggle you can set to disable this behavior, I think it would be most user-friendly for us to set it. It’s less efficient to ship an Abseil in which `absl::make_unique` is always an actual function, but I think it’s better than shipping an Abseil that can only be used with one version of the C++ standard. 2. Abseil may use some language features that changed semantics in C++17 and are therefore ABI-incompatible with translation units compiled against a different standard. I spoke with an Abseil developer about this today, and he believes it’s not likely to be an issue. Abseil does not plumb the depths of the C++ language spec (except possibly the template engine), so provided (1) is resolved, it’s entirely possible that a binary Abseil will work everywhere. We won’t really know until we package it and let it soak in testing for a while.
Bug#888705: abseil-cpp packaging
On Sunday, February 16, 2020, at 10:48 PM +0100, László Böszörményi (GCS) wrote: > In my reading abseil is _not_ guaranteed to have ABI compatibility at > all times. That's why it meant to be a static library collection only. > Forcing it to build shared libraries and have other packages than > libabseil-cpp-dev is no sense I think. Abseil does reserve the right to break ABI at any time, and I can’t speak to their future plans. But I think ABI breakages are unlikely to occur in practice within an LTS release. If we wait and then package an LTS release, I it’ll be completely reasonable to ship .so’s and .a’s. Relatedly, I think we should only package LTS Abseil for Debian. If someone finds a CVE in Abseil, the Abseil team are going to want to backport the fix to LTS releases; they’re not going to want to backport it everywhere else. > @Benjamin: may you ask its developers to use the system gtest libraries > if only ABSL_RUN_TESTS set to ON? Absolutely. I’ll bring it up with them at work tomorrow (today was a US holiday).
Bug#888705: ITP: abseil -- Collection of C++ code (compliant to C++11) designed to augment the C++ standard library
It looks like there hasn’t been any activity on this for a while. I hear there’s going to be a new Abseil LTS release sometime in the next few weeks; would it be all right if I took this bug and packaged Abseil once the LTS hits GitHub? (Full disclosure: I work at Google and sit near some Abseil developers. However, I don’t work on Abseil for my day job; packaging it would be a 20% effort. I’d continue maintaining the package even if I left Google.)
Bug#949537: elpa-elfeed-web: depends on CSS and JavaScript not in Debian
Package: elpa-elfeed-web Version: 3.1.0-1 Severity: serious Control: block -1 by 902083 Control: found -1 3.3.0-1 elfeed-web uses Foundation [1], AngularJS [2], and URI.js [3], loading them from various CDN sites in index.html: AngularJS is included in main, but Foundation and URI.js are not. This is probably a violation of Policy 2.2.1, which states that “None of the packages in the main archive area requires software outside of that area to function.” Ideally, Debian’s elfeed-web should Depend on packages containing Foundation, AngularJS, and URI.js, and it should be patched to load those resources from the same origin as index.html. There’s already an ITP for URI.js, which I’ve marked as a blocker for this bug. [1] https://foundation.zurb.com/ [2] https://angularjs.org/ [3] https://medialize.github.io/URI.js/
Bug#868164: systemd: fakeraid + cryptsetup (root) + lvm results in 90s time out waiting for device at boot
I’ve encountered what appears to be another instance of this on a Debian 10.2 system (systemd-241-7~deb10u2). The system has an LVM PV atop a LUKS container atop an mdadm RAID, and sometimes on boot, the system will time out trying to open the disk. Investigation in recovery mode suggests that the RAID is being assembled but cryptsetup isn’t figuring that out and just sits there, waiting for the disk to appear. Interestingly, the failure appears much more frequently on the systemd from buster-backports (systemd-244-3~bpo10+1) than it does on the version in buster.
Bug#944876: RFS: boogie 2.4.1-0.1 -- verifiable programming language [NMU, RC]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Tuesday, December 10, 2019, at 6:33 PM +0100, Fabian Wolff wrote: > Would you be willing to relicense your work on the Boogie Debian package > under the > Expat license? If so, and with your consent documented here in the bug > tracker for > #944876, I'd simply change the license to Expat in debian/copyright. That’s completely fine. I hereby relicense my work in that package under the Expat license. I’d appreciate it if you’d be willing to update the copyright headers in the relevant files when you switch the license. -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEQbf+q7LkywHKVTMA5ZUVm53A7cMFAl31L2UACgkQ5ZUVm53A 7cO0KQ/+Mms5/suIeB9RC1b7qevboygnTjh5q4jdxnsvwSAN8/e20K3WR1i6MBJm tP3SMtevHSH5c4h94/EpF0tg2RrJ4kZ5C8jTHN1AtSBsyuIS7bX8VgFADjKN+zKv apnBCusH5DyUaWS4x6qO9tIBIl+r/oqmVjxbOu3OEwb1AQ7XVVq03yVHzo14RhTY RK704x4h/5AtiY9YQCK/+5GUw51ZJfQwHevUpfYFe9AMDXGOO/NrUyeciCNTJ0Ue sm/YMgF7EV13+QMB1sr5WKcJnsv4WagaRIX2SXUawDKHzayHyqiU66Q3JZgV10gE keLASKx0RxQ+bX/EjZVhAOPlWjV5lIocq+Gwh7bSFVwuBBiudivXTUg1/ahwo4wx 466MrwUHskXy5LBGhmDo4K9fSZYhHAbO7Ou5i+qOT7OWoA/zHQ1rlI1U7nXo8h1n mFcWuuN7vP2Bwo3HG5oJCwiX6003BGvYFN0DDOfRuaeFtvLPh4l9Z6w6zPGOOtjY BYq7h9VS04HQk0i3qIUyGUfhqg50knlSOoVU9jQO3DcS1rbmd5WDepFtUbDLywNp VbfbxOWN02Am9/m2059X9wQBVmIsSjugPvBwiUNgaWAUgcLryHKSBwZJXGGsUj1B 66SKnRNNSzE+z9E5dUuaqIeU1V7wjL/3rhmEbi2nSDIL3vxX7Jc= =FvnM -END PGP SIGNATURE-
Bug#946227: libtext-bidi-perl: Please package misc/bidi urxvt extension
Source: libtext-bidi-perl Version: 2.15-1 Severity: wishlist libtext-bidi-perl’s upstream includes a file, misc/bidi, that can be used as a urxvt extension. (The extension filters terminal output through fribidi to display RTL text correctly.) It would be great if misc/bidi could be installed through apt. It looks like Debian puts system extensions for urxvt in /usr/lib/$DEB_HOST_MULTIARCH/urxvt/perl.
Bug#946226: rxvt-unicode: installs Perl extensions in /usr/lib, not /usr/share
Package: rxvt-unicode Version: 9.22-6 Severity: wishlist rxvt-unicode currently installs Perl extensions in /usr/lib/$DEB_HOST_MULTIARCH/urxvt/perl. However, the FHS identifies /usr/share as the preferred tree for architecture-independent data; Perl scripts should thus be installed in /usr/share. This is definitely a wishlist item: The FHS says that “application-specific, architecture-independent directories ... may, however, be placed in /usr/lib for backwards compatibility, at the distributor’s discretion.” Eventually, though, it would be nice to get all the Perl into /usr/share.
Bug#944876: RFS: boogie 2.4.1-0.1 -- verifiable programming language [NMU, RC]
As the current maintainer, I definitely do not object to this NMU (or any other NMUs associated with this package). Sponsors, please feel free to upload without delay.
Bug#939294: [Pkg-utopia-maintainers] Bug#939294: network-manager: After upgrade to 1.20.0-1, mac address of wlan0 is randomized
Just to add a data point, I’ve experienced the same failure as Jörn. I’m using ath9k, not iwlwifi, so this may indeed be an implementation difference between the two drivers. In the meantime, I’ve worked around the issue by putting [connection] wifi.cloned-mac-address=permanent in /etc/NetworkManager/NetworkManager.conf. This undoes the change in upstream commit fae5ecec5a4d9987a1915441602cb78275a9f490 [1] and makes NetworkManager default to using the permanent MAC address when it’s done scanning. [1] https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=fae5ecec5a4d9987a1915441602cb78275a9f490
Bug#939741: FTBFS with OCaml 4.08.0 (safe strings)
Control: block 939741 by 897129 I agree. coq-doc acquired a new dependency in the 8.9 release, so that’ll need to get packaged first.
Bug#935049: mkvtoolnix-gui: disable online update check
Package: mkvtoolnix-gui Version: 31.0.0-1 Severity: normal mkvtoolnix-gui checks daily for updates from upstream and notifies the user if an update is available. This is potentially confusing to users; we probably should turn it off. It looks like fixing this is as straightforward as passing `--disable-update-check` to `configure` during the build process. -- System Information: Debian Release: 10.0 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-5-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages mkvtoolnix-gui depends on: ii libboost-filesystem1.67.0 1.67.0-13 ii libboost-regex1.67.0 1.67.0-13 ii libboost-system1.67.0 1.67.0-13 ii libc6 2.28-10 ii libcmark0 0.28.3-1 ii libebml4v5 1.3.6-2 ii libgcc11:8.3.0-6 ii libmagic1 1:5.35-4 ii libmatroska6v5 1.4.9-1 ii libpugixml1v5 1.9-3 ii libqt5core5a 5.11.3+dfsg1-1 ii libqt5dbus55.11.3+dfsg1-1 ii libqt5gui5 5.11.3+dfsg1-1 ii libqt5multimedia5 5.11.3-2 ii libqt5network5 5.11.3+dfsg1-1 ii libqt5widgets5 5.11.3+dfsg1-1 ii libstdc++6 8.3.0-6 ii mkvtoolnix 31.0.0-1 ii zlib1g 1:1.2.11.dfsg-1 mkvtoolnix-gui recommends no packages. mkvtoolnix-gui suggests no packages. -- no debconf information
Bug#934950: dafny: unsatisfiable build-dependency in sid
Having dafny drop out of the archive would be fine with me – I’ve had an active RFA out for over a year (https://bugs.debian.org/903143), and nobody seems interested. I’ll officially orphan it and request ftpmaster removal.
Bug#934722: urweb: _FORTIFY_SOURCE=2 causes extreme slowdown
Source: urweb
Version: 20170720+dfsg-2
Ur/Web’s C runtime currently builds with -D_FORTIFY_SOURCE=2 (really,
with DEB_BUILD_MAINT_OPTIONS=hardening=+all), since it’s a library in
the serving path. However, the runtime makes heavy use of %n format
specifiers, and _FORTIFY_SOURCE=2 causes that format specifier to be
incredibly slow:
/tmp$ cat stuff.c
#include
int main(int argc, char* argv[]) {
int n;
for (int i = 0; i < 100; ++i) {
printf("%s%n\n", argv[1], );
printf("%d\n", n);
}
}
/tmp$ gcc -O3 -o stuff stuff.c
/tmp$ time ./stuff 'Hello, world!' >/dev/null
real0m0.167s
user0m0.167s
sys 0m0.000s
/tmp$ gcc -O3 -D_FORTIFY_SOURCE=1 -o stuff stuff.c
/tmp$ time ./stuff 'Hello, world!' >/dev/null
real0m0.170s
user0m0.170s
sys 0m0.000s
/tmp$ gcc -O3 -D_FORTIFY_SOURCE=2 -o stuff stuff.c
/tmp$ time ./stuff 'Hello, world!' >/dev/null
real0m8.605s
user0m2.058s
sys 0m6.482s
This has been confirmed to affect Ur/Web benchmark results [1, 2].
(Short version: TechEmpower switched from a custom build of Ur/Web to
using the package out of the archive and observed a 100× slowdown.)
One of Ur/Web’s major selling points is its speed, and while hardening
is valuable, users are likely to be surprised by Debian shipping an
Ur/Web that runs orders of magnitude slower than published benchmark
results. We should probably force _FORTIFY_SOURCE=1 in Ur/Web builds.
[1] http://www.impredicative.com/pipermail/ur/2019-July/002850.html
[2] http://www.impredicative.com/pipermail/ur/2019-August/002854.html
Bug#827861: Please add coq-8.5 to jessie-backports
Control: tags 827861 wontfix jessie has entered LTS, and LTS distributions no longer receive backports (see https://backports.debian.org/news/stretch-backports/), so this almost certainly isn’t going to happen.
Bug#926332: socat: please support SNI
Package: socat
Version: 1.7.3.2-2
Severity: wishlist
Tags: upstream
socat does not support the TLS Server Name Indication extension. This
extension has become pretty widely deployed at this point, and socat’s
TLS support could be substantially more useful if it sent SNI.
A patch against 1.7.3.0 is available [1]; I’ve also attached it here for
convenience. I haven’t tested or reviewed it, though, so its inclusion
should not be treated as an endorsement. :)
[1]
https://github.com/moparisthebest/socat/commit/268432bf4220502535dbd373344b60b8fd10e3ce
>From 268432bf4220502535dbd373344b60b8fd10e3ce Mon Sep 17 00:00:00 2001
From: moparisthebest
Date: Fri, 17 Jul 2015 22:08:00 -0400
Subject: [PATCH 1/1] Add OpenSSL snihost option for TLS SNI extension
---
doc/socat.yo | 9 +++--
xio-openssl.c | 16 +++-
xio-openssl.h | 2 ++
xioopts.c | 2 ++
xioopts.h | 1 +
5 files changed, 27 insertions(+), 3 deletions(-)
diff --git a/doc/socat.yo b/doc/socat.yo
index 65e9894..18269da 100644
--- a/doc/socat.yo
+++ b/doc/socat.yo
@@ -502,13 +502,15 @@ label(ADDRESS_OPENSSL_CONNECT)dit(bf(tt(OPENSSL::)))
link(openssl-commonname)(OPTION_OPENSSL_COMMONNAME) option.
Socat tries to match it against the certificates subject commonName,
and the certifications extension subjectAltName DNS names. Wildcards in the
- certificate are supported.nl()
+ certificate are supported. To specify the TLS SNI hostname to set use the
+ link(snihost)(OPTION_OPENSSL_SNIHOST) option.nl()
Option groups: link(FD)(GROUP_FD),link(SOCKET)(GROUP_SOCKET),link(IP4)(GROUP_IP4),link(IP6)(GROUP_IP6),link(TCP)(GROUP_TCP),link(OPENSSL)(GROUP_OPENSSL),link(RETRY)(GROUP_RETRY) nl()
Useful options:
link(cipher)(OPTION_OPENSSL_CIPHERLIST),
link(method)(OPTION_OPENSSL_METHOD),
link(verify)(OPTION_OPENSSL_VERIFY),
- link(commonname)(OPTION_OPENSSL_COMMONNAME)
+ link(commonname)(OPTION_OPENSSL_COMMONNAME),
+ link(snihost)(OPTION_OPENSSL_SNIHOST),
link(cafile)(OPTION_OPENSSL_CAFILE),
link(capath)(OPTION_OPENSSL_CAPATH),
link(certificate)(OPTION_OPENSSL_CERTIFICATE),
@@ -2700,6 +2702,9 @@ label(OPTION_OPENSSL_COMMONNAME)dit(bf(tt(commonname=)))
certificates commonname. This option has only meaning when option
link(verify)(OPTION_OPENSSL_VERIFY) is not disabled and the choosen cipher
provides a peer certificate.
+label(OPTION_OPENSSL_SNIHOST)dit(bf(tt(snihost=)))
+ Specify the SNI hostname for the TLS request. The server can use this TLS
+ extension to choose which certificate to send.
label(OPTION_OPENSSL_FIPS)dit(bf(tt(fips)))
Enables FIPS mode if compiled in. For info about the FIPS encryption
implementation standard see lurl(http://oss-institute.org/fips-faq.html).
diff --git a/xio-openssl.c b/xio-openssl.c
index 665430d..a04e5bf 100644
--- a/xio-openssl.c
+++ b/xio-openssl.c
@@ -117,6 +117,7 @@ const struct optdesc opt_openssl_compress= { "openssl-compress", "compress
const struct optdesc opt_openssl_fips= { "openssl-fips", "fips", OPT_OPENSSL_FIPS,GROUP_OPENSSL, PH_SPEC, TYPE_BOOL, OFUNC_SPEC };
#endif
const struct optdesc opt_openssl_commonname = { "openssl-commonname", "cn", OPT_OPENSSL_COMMONNAME, GROUP_OPENSSL, PH_SPEC, TYPE_STRING, OFUNC_SPEC };
+const struct optdesc opt_openssl_snihost = { "openssl-snihost", "snihost", OPT_OPENSSL_SNIHOST, GROUP_OPENSSL, PH_SPEC, TYPE_STRING, OFUNC_SPEC };
/* If FIPS is compiled in, we need to track if the user asked for FIPS mode.
@@ -197,6 +198,7 @@ static int
bool opt_ver = true; /* verify peer certificate */
char *opt_cert = NULL; /* file name of client certificate */
const char *opt_commonname = NULL; /* for checking peer certificate */
+ const char *opt_snihost = NULL; /* for sni host */
int result;
if (!(xioflags & XIO_MAYCONVERT)) {
@@ -226,10 +228,15 @@ static int
retropt_string(opts, OPT_OPENSSL_CERTIFICATE, _cert);
retropt_string(opts, OPT_OPENSSL_COMMONNAME, (char **)_commonname);
+ retropt_string(opts, OPT_OPENSSL_SNIHOST, (char **)_snihost);
if (opt_commonname == NULL) {
opt_commonname = hostname;
}
+ /* could do this, but might not be desired?
+ if (opt_snihost == NULL) {
+ opt_snihost = hostname;
+ } */
result =
_xioopen_openssl_prepare(opts, xfd, false, _ver, opt_cert, );
@@ -289,7 +296,7 @@ static int
return result;
}
- result = _xioopen_openssl_connect(xfd, opt_ver, opt_commonname, ctx, level);
+ result = _xioopen_openssl_connect(xfd, opt_ver, opt_commonname, opt_snihost, ctx, level);
switch (result) {
case STAT_OK: break;
#if WITH_RETRY
@@ -358,6 +365,7 @@ static int
int _xioopen_openssl_connect(struct single *xfd,
bool opt_ver,
const char *opt_commonname,
+ const char *opt_snihost,
SSL_CTX *ctx,
int level) {
SSL *ssl;
@@ -382,6 +390,12 @@ int
Bug#926134: antlr4: Please package Python 3 runtime
Control: tags 926134 wontfix On Wednesday, April 3, 2019, at 7:30 AM EDT, Emmanuel Bourg wrote: > The Java Team would prefer maintaining only the Java part of ANTLR 4. > Ideally the python part should be maintained separately […]. Sounds fine – I’ll keep an eye on https://bugs.debian.org/897129.
Bug#926179: debian-security-support: Please mark qtwebengine-opensource-src as limited-support
Package: debian-security-support Version: 2019.02.01 Tags: patch QtWebEngine isn’t explicitly listed in the release notes as “not covered by security support” [1], but QtWebKit is. QtWebEngine probably belongs in the same boat – it has a steady stream of CVEs that are quickly patched upstream, but no DSAs have been issued. Please add qtwebengine-opensource-src to security-support-limited. [1] https://www.debian.org/releases/stretch/amd64/release-notes/ch-information.en.html#browser-security --- debian-security-support/security-support-limited.orig 2018-11-25 08:39:43 +0100 +++ debian-security-support/security-support-limited 2019-04-01 12:14:58 -0400 @@ -17,6 +17,7 @@ mozjs17 Not covered by security support, only suitable for trusted content mozjs24 Not covered by security support, only suitable for trusted content ocsinventory-server Only supported behind an authenticated HTTP zone +qtwebengine-opensource-src No security support upstream and backports not feasible, only for use on trusted content qtwebkitNo security support upstream and backports not feasible, only for use on trusted content qtwebkit-opensource-src No security support upstream and backports not feasible, only for use on trusted content sql-ledger Only supported behind an authenticated HTTP zone
Bug#926137: RM: coq-doc/8.6-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: rm buster currently carries coq/8.9.0-1, but coq-doc still documents Coq 8.6. Building the reference manual for 8.9.0 requires the ANTLR 4 runtime for Python 3, which is not in buster (https://bugs.debian.org/926134). With the freeze in effect, it’s looking pretty unlikely that coq-doc for Coq 8.9.0 is going to make it into buster/non-free before the buster release gets finalized. Please remove coq-doc and its binary packages (coq-doc, coq-doc-html, and coq-doc-pdf) from buster/non-free.
Bug#926134: antlr4: Please package Python 3 runtime
On Sunday, March 31, 2019, at 3:52 PM EDT, Benjamin Barenblat wrote: > Coq now needs the ANTLR 4 runtime for Python 3 to generate its HTML > documentation. Er, correction: Some HTML documentation can be built without the runtime. However, you need the runtime to build the reference manual, and that actually holds true whether you’re building PDF or HTML.
Bug#926134: antlr4: Please package Python 3 runtime
Source: antlr4 Version: 4.7.2-1 Coq now needs the ANTLR 4 runtime for Python 3 to generate its HTML documentation. Would you be willing to add it to the antlr4 package? This may be a duplicate of https://bugs.debian.org/897129, but lacking familiarity with ANTLR, it’s not clear to me whether that bug is asking for the runtime or for bindings to script against ANTLR.
Bug#922809: unblock: aac-tactics/8.8.0+1.gbp069dc3b-1
On Saturday, March 9, 2019, at 3:17 PM EST, Paul Gevers wrote: > [...] I took a look at the times in the bug, and it seems you uploaded > the package *after* it got removed. > > Is it just me, or did you suggest a different time line? If so, why? No, it’s not just you – I believed that I had uploaded the package before it was autorm’d. However, I believed that based on what qa.debian.org said. Without looking too closely, my guess is that I uploaded after the package had been removed but before qa.debian.org’s data had been updated. > Couldn't you just fix the FTBFS by patching the original version in > Debian? That would make reviewing a lot easier. Perhaps, but unfortunately, I don’t have the time to write those patches right now. If the new version is too much to accept into buster at this point, please feel free to close this as a wontfix – I think the world can live without aac-tactics for one release cycle. Thanks for looking into this, Benjamin
Bug#922809: unblock: aac-tactics/8.8.0+1.gbp069dc3b-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package aac-tactics I uploaded coq/8.9.0-1 to unstable shortly before the soft freeze began. Unfortunately, this caused aac-tactics to FTBFS (https://bugs.debian.org/919463) and be scheduled for autoremoval. I uploaded a new aac-tactics, fixing the build, but the autoremoval timer ran out before it was migrated. aac-tactics is a leaf package, so allowing it to migrate is unlikely to produce instability in the new release. Would you consider an unblock? unblock aac-tactics/8.8.0+1.gbp069dc3b-1 -- System Information: Debian Release: 9.8 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-0.bpo.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.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#919461: ssreflect ftbfs in unstable
Control: retitle 919461 ssreflect FTBFS in unstable Control: noowner 919461 I’m guessing this is just that 1.6.1 is not compatible with Coq 8.9. Uploading 1.7.0 might resolve the issue, but I’m uninterested in doing that work, particularly since the package is licensed under CeCILL-B, which I believe to be nonfree [1]. Would anybody else like to do an upload of this? If not, we should just let it drop out of testing. [1] https://lists.debian.org/msgid-search/875zvih02a@benwick.benjamin.barenblat.name
Bug#919461: ssreflect ftbfs in unstable
Control: retitle 919461 ssreflect FTBFS in unstable due to missing ssrmatching Control: owner 919461 ! That’s my fault. In my most recent Coq upload, I disabled ssrmatching and a couple of other plugins due to license concerns [1]. Those have now been resolved upstream [2]. I’m going to backport the changes to 8.8.2 and do another upload in the next few days, after which this bug should go away. [1] https://salsa.debian.org/ocaml-team/coq/commit/4181269ff800d58e60b886d0aaa289a9cd0d [2] https://github.com/coq/coq/commit/a92e4fbe88e16c312fe57a6f00ccba94322ee111
Bug#919462: coq ftbfs on some release architectures
Control: retitle 919462 coq FTBFS on architectures without native OCaml backends Control: owner 919462 ! Coq actually does build, but the test suite fails because I messed up plugin loading on architectures that don’t have ocamlopt. Upstream handles both native and bytecode worlds by installing the same file in two different places; I found this unpalatable and just removed one of the copies [1]. I didn’t realize at the time that the bytecode world needed that file. I’ll look into fixing this in the next couple of days. [1] https://salsa.debian.org/ocaml-team/coq/commit/6fabd6380fd08b6e3defdfceb137b47d4db858a3#1823cfdb97f631de92d185f9a7ef6c1f58bc9147
Bug#918633: why3-coq: package should Depend on a specific Coq version
Package: why3-coq Version: 1.1.1-1 Severity: serious why3-coq Depends on coq, but it contains compiled .vo files that can only be read by Coq 8.6. (In general, Coq .vo files are tied to the minor version of Coq that produced them.) why3-coq should Depend on the minor version of Coq that compiled it (like 8.6 or 8.8).
Bug#889803: add package with cd-paranoia binary
Niels, it looks like you uploaded src:libcdio-paranoia 10.2+0.94+2-4, removing the cd-paranoia binary package, because cd-paranoia(1) is already included in the libcdio-utils package. However, if you look at libcdio-utils in sid, you’ll see this is no longer the case – there is currently no package in sid that provides cd-paranoia(1). Would you be willing to undo that change and upload a new src:libcdio-paranoia equivalent to 10.2+0.94+2-3? For reference, here’s the current situation. cd-paranoia(1) was originally developed in upstream’s libcdio repository.¹ In 2011, shortly after the release of libcdio 0.83, Rocky Bernstein split that repository into a libcdio repository and a libcdio-paranoia repository,² copying over cd-paranoia(1) to the new development. Further work on the program occurred there. However, libcdio appears not to have much attention paid to it in Debian at the time, so src:libcdio 0.83 and its associated binary packages were included with jessie and stretch, and libcdio-utils contained cd-paranoia(1). After the stretch release, however, src:libcdio and src:libcdio-paranoia got updates in Debian: src:libcdio to 2.0.0 and src:libcdio-paranoia to 10.2+0.94+2. During the update, cd-paranoia(1) disappeared from src:libcdio, as expected. However, the program didn’t get included in any of src:libcdio-paranoia’s binary packages. This brings us to the current situation, in which the cd-paranoia(1) program is not distributed in sid at all. ¹ https://git.savannah.gnu.org/cgit/libcdio.git ² https://github.com/rocky/libcdio-paranoia
Bug#905366: fuse: Cannot overlay autofs or FAT
On Saturday, August 4, 2018, at 1:40 AM EDT, László Böszörményi wrote: > I've fixed the FAT issue and sent it to upstream. Ha, I did the same thing (we're https://github.com/libfuse/libfuse/pull/277 and https://github.com/libfuse/libfuse/pull/278). Everything's merged now, so https://github.com/libfuse/libfuse/commit/9b287377343fd796d359e67de54d477d8084cfcd is a patch to close this. This is blocking a FUSE use case for me, so I'd like to see it resolved as soon as possible. Please let me know if there's anything I can do to help - I'm happy to build and NMU if you're busy.
Bug#905390: musepack-tools: wavcmp never shows usage
Package: musepack-tools Version: 2:0.1~r495-1+b1 Severity: normal Tags: upstream wavcmp only displays usage if `4 < argc && argc < 3` (https://sources.debian.org/src/libmpc/2:0.1~r495-1/wavcmp/wavcmp.c/#L49), which is always false. That should probably read `4 < argc || argc < 3`. -- System Information: Debian Release: 9.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.16.0-0.bpo.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.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages musepack-tools depends on: ii libc6 2.24-11+deb9u3 ii libcue1 1.4.0-1 ii libmpcdec6 2:0.1~r495-1+b1 ii libreplaygain1 1.0~r475-1 musepack-tools recommends no packages. musepack-tools suggests no packages. -- no debconf information
Bug#905366: fuse: Cannot overlay autofs or FAT
Package: fuse Version: 2.9.7-1+deb9u1 Severity: normal Attempting to mount a FUSE overlay file system over an autofs or FAT mount fails with the error fusermount: mounting over filesystem type 0x0187 is forbidden (for autofs) or fusermount: mounting over filesystem type 0x4d44 is forbidden (for FAT). This occurs because the autofs and FAT magic numbers are not in debian/patches/CVE-2018-10906/0005-fusermount-whitelist-known-good-filesystems-for-moun.patch. autofs's magic was added to upstream in https://github.com/libfuse/libfuse/commit/0ef031bfc08564e7c5920432e13373dcf18dbc63, but FAT's magic has not been added yet. -- System Information: Debian Release: 9.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.16.0-0.bpo.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.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages fuse depends on: ii adduser 3.115 ii libc6 2.24-11+deb9u3 ii libfuse2 2.9.7-1+deb9u1 ii mount 2.29.2-1+deb9u1 ii sed 4.4-1 fuse recommends no packages. fuse suggests no packages. -- no debconf information
Bug#904828: lilypond: should Suggest python-lxml
Package: lilypond Version: 2.19.81+really-2.18.2-13 Severity: wishlist If you pass `--lxml` to musicxml2ly(1), the program will "use lxml.etree; uses less memory and cpu time". It would be great if the package Suggested python-lxml, which is required to use this feature.
Bug#903143: RFA: dafny
Package: wnpp Severity: normal I request an adopter for the dafny package. The package description is: Dafny is a programming language with a program verifier. The verifier processes function preconditions, postconditions, and assertions, and sends them to an SMT solver for checking. In this way, assertion failures become compiler errors, rather than runtime ones. I'm no longer using Dafny, so my motivation to keep it up-to-date has faded. If somebody else is interested in keeping it uploaded, they're welcome to do so.
