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
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
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
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
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
Control: user debian-ri...@lists.debian.org
Control: usertag 1059340 + riscv64
Just to be clear, I've only observed this behavior on riscv64.
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
>
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
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
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?
Thank you for the patch, Aurelien! I’ve applied it to the 20220623.1
release and uploaded it to unstable as 20220623.1-2.
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
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
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
Control: owner 1033466 !
I’ll get 20230125.1 into experimental soon.
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
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
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
Quick update – googletest 1.12 is in sid, and I’m working now to package
Abseil 20220623.
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
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’;
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
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
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
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).
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
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
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
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:
-
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
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
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
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
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 to
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
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.
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
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
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
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
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
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 upstrea
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
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
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
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
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
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
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
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]
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.
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
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
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
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 ch
This is now in the NEW queue.
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?
>
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
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
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
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
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
---
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
That sounds 100% feasible. I’ll give Abseil packaging some more
attention this week and get back in touch.
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?
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 preliminar
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 th
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
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
>
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
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
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
-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
>
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
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
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.
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
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.
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
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.
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
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.
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
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
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,
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
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
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
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
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)
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
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
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
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
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
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
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
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
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.
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
1 - 100 of 155 matches
Mail list logo
