Bug#967030: ITP: cockpit-podman -- Cockpit component for Podman containers
Control: tag -1 pending I did the initial upload now, and created a VCS at the usual place: https://salsa.debian.org/debian/cockpit-podman Note that I did *not* push the release commit and tag yet, as there may still be changes during NEW review. Martin
Bug#937202: openjfx: Python2 removal in sid/bullseye
On Tue, Nov 12, 2019 at 12:06:05AM +0100, Emmanuel Bourg wrote: > Control: forwarded -1 https://bugs.openjdk.java.net/browse/JDK-8230779 > > The issue has been forwarded upstream. We may disable the webkit > component until the issue is addressed upstream. > > Emmanuel Bourg I'm not able to reproduce the build failure with 11.0.7+0. I will upload an updated package that builds using python3. signature.asc Description: PGP signature
Bug#966914: sambamba: FTBFS: collect2: error: ld returned 1 exit status
On Thu, Aug 06, 2020 at 03:49:51AM +0200, Matthias Klumpp wrote: > Where does the > `bgzf.c` file reference come from? I used find on my local disk and several projects do contain bgzf.c. My guess is these are all code copies from htslib - thus I'd assume it comes from htslib. This seems quite probable since cram/htslib.d in sambamba contains the string bgzf several times. Kind regards Andreas. -- http://fam-tille.de
Bug#966610: systemd: autopkgtest-virt-lxc fails in timedated on arm64
Package: systemd Version: 246-2 Followup-For: Bug #966610 Dear Maintainer, This bug remains with version 246-2 on armhf. Ryutaroh -- Package-specific info: -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: armhf (armv7l) Kernel: Linux 5.4.51-v7l+ (SMP w/4 CPU threads) Kernel taint flags: TAINT_CRAP Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages systemd depends on: ii adduser 3.118 ii libacl1 2.2.53-8 ii libapparmor1 2.13.4-3 ii libaudit11:2.8.5-3+b1 ii libblkid12.36-2 ii libc62.31-3 ii libcap2 1:2.36-1 ii libcrypt11:4.4.16-1 ii libcryptsetup12 2:2.3.3-1+b1 ii libgcrypt20 1.8.6-2 ii libgnutls30 3.6.14-2+b1 ii libgpg-error01.38-2 ii libidn2-02.3.0-1 ii libip4tc21.8.5-2 ii libkmod2 27+20200310-2 ii liblz4-1 1.9.2-2 ii liblzma5 5.2.4-1+b1 ii libmount12.36-2 ii libpam0g 1.3.1-5+rpt2 ii libpcre2-8-0 10.34-7 ii libseccomp2 2.4.3-1+b1 ii libselinux1 3.1-2 ii libsystemd0 246-2 ii libzstd1 1.4.5+dfsg-3 ii mount2.36-2 ii systemd-timesyncd [time-daemon] 246-2 ii util-linux 2.36-2 Versions of packages systemd recommends: ii dbus 1.12.20-1 Versions of packages systemd suggests: pn policykit-1 pn systemd-container Versions of packages systemd is related to: pn dracut pn initramfs-tools ii libnss-systemd 246-2 ii libpam-systemd 246-2 ii udev 246-2 -- Configuration Files: /etc/systemd/journald.conf changed [not included] /etc/systemd/logind.conf changed [not included] /etc/systemd/networkd.conf changed [not included] /etc/systemd/sleep.conf changed [not included] /etc/systemd/system.conf changed [not included] /etc/systemd/user.conf changed [not included] -- no debconf information
Bug#967906: systemd 246 resolvconf path unit
I too find both installed on all my machines. What sense does that make? Shouldn't the packages conflict? > "KL" == Kai Lüke writes: KL> Yes, I had resolvconf around for some reason while using systemd-resolved. KL> Thanks for forwarding to upstream.
Bug#967938: libc6: systemd-sysusers SEGV due to glibc bug in fgetgsent
Hi Florian, On Wed, Aug 5, 2020 at 6:44 PM Florian Weimer wrote: > > * Jinpu Wang: > > > Dear Maintainer: > > > > Sorry, add some missing information below: > > > > After update to Buster, the systemd-sysusers are segfaulting every time. > > After search around, I found following bugreport in glibc > > https://sourceware.org/legacy-ml/libc-alpha/2016-06/msg01015.html > > > > I backported to the fix to 2.28-10, it fixed the problem. > > > > glibc upstream have a different fix for it in 2.32, see > > https://sourceware.org/bugzilla/show_bug.cgi?id=20338 > > > > I think it's still easier to backport the fix in msg01015.html to 2.28 > > version, > > patch attached in the initial report. > > The patch from 2016 is incomplete because it does not seek back to the > original file position, so the next call of fgetsgent_r skips over the > entry that could not be fully parsed. Thanks for quick response, can you provide a minimum bugfix, which can be easily backported to old version like 2.28? as you also make the bug 20338 as a security hole. Regards! Jinpu
Bug#967970: redis-server crashes with jemalloc error if activedefrag is enabled
Package: redis-server Version: 5:6.0.6-1 Severity: normal I also filed this here. The error received and the reason why are different on Ubuntu and Debian, so the solution might be similar or it might be different. So, I am just trying to be complete / comprehensive. https://bugs.launchpad.net/ubuntu/+source/redis/+bug/1890517 Matthew. -- System Information: Debian Release: bullseye/sid APT prefers focal-updates APT policy: (500, 'focal-updates'), (500, 'focal-security'), (500, 'focal'), (100, 'focal-backports') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.4.0-42-generic (SMP w/12 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE= (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages redis-server depends on: ii init-system-helpers 1.57 ii lsb-base 11.1.0ubuntu2 ii redis-tools 5:6.0.6-1 redis-server recommends no packages. redis-server suggests no packages. -- Configuration Files: /etc/redis/redis.conf changed: bind 127.0.0.1 ::1 protected-mode yes port 6379 tcp-backlog 511 timeout 0 tcp-keepalive 300 daemonize no supervised auto pidfile /var/run/redis/redis-server.pid loglevel notice logfile /var/log/redis/redis-server.log databases 16 always-show-logo no save 900 1 save 300 10 save 60 1 stop-writes-on-bgsave-error yes rdbcompression yes rdbchecksum yes dbfilename dump.rdb rdb-del-sync-files no dir /var/lib/redis replica-serve-stale-data yes replica-read-only yes repl-diskless-sync no repl-diskless-sync-delay 5 repl-diskless-load disabled repl-disable-tcp-nodelay no replica-priority 100 acllog-max-len 128 maxmemory 1073741824 maxmemory-policy volatile-ttl lazyfree-lazy-eviction no lazyfree-lazy-expire no lazyfree-lazy-server-del no replica-lazy-flush no lazyfree-lazy-user-del no appendonly yes appendfilename "appendonly.aof" appendfsync everysec no-appendfsync-on-rewrite no auto-aof-rewrite-percentage 100 auto-aof-rewrite-min-size 64mb aof-load-truncated yes aof-use-rdb-preamble yes lua-time-limit 5000 slowlog-log-slower-than 1 slowlog-max-len 128 latency-monitor-threshold 0 notify-keyspace-events "" hash-max-ziplist-entries 512 hash-max-ziplist-value 64 list-max-ziplist-size -2 list-compress-depth 0 set-max-intset-entries 512 zset-max-ziplist-entries 128 zset-max-ziplist-value 64 hll-sparse-max-bytes 3000 stream-node-max-bytes 4096 stream-node-max-entries 100 activerehashing yes client-output-buffer-limit normal 0 0 0 client-output-buffer-limit replica 256mb 64mb 60 client-output-buffer-limit pubsub 32mb 8mb 60 hz 10 dynamic-hz yes aof-rewrite-incremental-fsync yes rdb-save-incremental-fsync yes activedefrag yes jemalloc-bg-thread yes -- no debconf information
Bug#967969: pkg-config-crosswrapper wrongly asks to install dpkg-dev even if installed already
Package: pkg-config
Version: 0.29.2-1
Severity: normal
Tags: patch
Hello,
With newer dpkg-architecture (I'm using 1.19.7), when I cross build
for i686-w64-mingw32, the command i686-w64-mingw32-pkg-config (linked
to pkg-config-crosswrapper) fails with the message:
Please install dpkg-dev to use pkg-config when cross-building
... even if dpkg-dev is installed.
This is because the command invocation in pkg-config-crosswrapper
dpkg-architecture -ti686-w64-mingw32 -qDEB_HOST_MULTIARCH
fails with the message:
dpkg-architecture: error: unknown GNU system type i686-w64-mingw32, you must
specify Debian architecture, too
with the exit code of 255 (as of version 1.19.7).
# It is related to the change of dpkg and this dpkg bug:
# https://bugs.debian.org/606825
#
# When I modify /usr/share/dpkg/ostable and
# /usr/share/dpkg/tupletable, I can let i686-w64-mingw32-pkg-config
# work correctly.
If we can depend on the behavior of shell having the exit code of 127 when
it can't find the command, I think that we can do like this:
===
--- pkg-config-crosswrapper~2020-04-22 03:30:00.0 +0900
+++ pkg-config-crosswrapper 2020-08-06 10:24:58.149356309 +0900
@@ -11,7 +11,7 @@
triplet="${basename%-pkg-config}"
# Normalized multiarch path if any, e.g. i386-linux-gnu for i386
multiarch="$(dpkg-architecture -t"${triplet}" -qDEB_HOST_MULTIARCH
2>/dev/null)"
- if [ "$?" != 0 ]; then
+ if [ "$?" = 127 ]; then
echo "Please install dpkg-dev to use pkg-config when cross-building" >&2
exit 1
fi
===
Could you please consider an improvement like this?
Well, let me explain my situation adding some more information.
I encounter this bug when I cross build GnuPG for i686-w64-mingw32 on
Debian host. Note that Debian's GnuPG package build process includes
building gpgv for Windows (IIUC, so that it can be used for
win32-loader).
Even if I have dpkg-dev installed, when the GnuPG's configure script
invokes pkg-config, pkg-config fails like:
=
...
checking for cc for build... cc
checking for i686-w64-mingw32-pkg-config... /usr/bin/i686-w64-mingw32-pkg-config
checking pkg-config is at least version 0.9.0... Please install dpkg-dev to use
pkg-config when cross-building
no
...
=
-- System Information:
Debian Release: 10.5
APT prefers stable
APT policy: (990, 'stable'), (500, 'stable-debug'), (500, 'unstable'), (500,
'testing'), (500, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, ppc64el
Kernel: Linux 4.19.0-10-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages pkg-config depends on:
ii libc6 2.31-3
ii libdpkg-perl 1.19.7
ii libglib2.0-0 2.64.3-2
pkg-config recommends no packages.
Versions of packages pkg-config suggests:
ii dpkg-dev 1.19.7
Bug#967968: bup package missing for buster
Package: bup Severity: important Dear Maintainer, I'm running Debian Buster, and I tried to apt-get install bup. Here's the error I got: Package bup is not available, but is referred to by another package. This may mean that the package is missing, has been obsoleted, or is only available from another source E: Package 'bup' has no installation candidate It seems like bup is only available for jessie, stretch, sid, and experimental. Not buster? - Dan -- System Information: Debian Release: 10.4 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.4.40-04224-g891a6cce2d44 (SMP w/2 CPU cores; PREEMPT) 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#957020: Fixed already in upstream commit 017e6c6ab95df55f34e339d2139def83e5dada1f
Upstream fixed this via commit https://github.com/linux-audit/audit-userspace/commit/017e6c6ab95df55f34e339d2139def83e5dada1f however this has not yet been released in an official release.
Bug#958035: marked as pending in pango
On 2020-08-06 05:41, Simon McVittie wrote: Revert removal of libpango1.0-0 binary package Apparently 7 years is not long enough to update dependencies in the fast-moving world of third-party proprietary software. Interestingly, Adobe has decided it's going to stop supporting Flash altogether from Dec 31 2020. https://www.adobe.com/au/products/flashplayer/end-of-life.html So I guess we don't need to worry about the flash plugin anymore...
Bug#966914: sambamba: FTBFS: collect2: error: ld returned 1 exit status
Am Di., 4. Aug. 2020 um 11:23 Uhr schrieb Andreas Tille : > > Control: tags -1 help > > Hi, > > On Mon, Aug 03, 2020 at 10:06:32AM +0200, Lucas Nussbaum wrote: > > > lto1: fatal error: bytecode stream in file > > > ‘/usr/lib/x86_64-linux-gnu/libhts.a’ generated with GCC compiler older > > > than 10.0 > > I've uploaded a new htslib that is now build with GCC 10 and used a > versioned Build-Depends inside sambamba. Now the build issue changed > to: > > [38/41] ldc2 -enable-color -O -g -release -wi -I/usr/include/x86_64-linux-gnu > -I/usr/include/d/bio -O3 -release -enable-inlining -boundscheck=off -J../ > -I=.. -I=. -I=sambamba.p -I=sambamba.p > -of=sambamba.p/_build_sambamba-0.7.1_obj-x86_64-linux-gnu_utils_ldc_version_info_.d.o > -c /build/sambamba-0.7.1/obj-x86_64-linux-gnu/utils/ldc_version_info_.d > [39/41] ldc2 -enable-color -O -g -release -wi -I/usr/include/x86_64-linux-gnu > -I/usr/include/d/bio -O3 -release -enable-inlining -boundscheck=off -J../ > -I=.. -I=. -I=sambamba.p -I=sambamba.p > -of=sambamba.p/thirdparty_unstablesort.d.o -c ../thirdparty/unstablesort.d > [40/41] ldc2 -enable-color -O -g -release -wi -I/usr/include/x86_64-linux-gnu > -I/usr/include/d/bio -O3 -release -enable-inlining -boundscheck=off -J../ > -I=.. -I=. -I=sambamba.p -I=sambamba.p -of=sambamba.p/sambamba_view.d.o -c > ../sambamba/view.d > [41/41] ldc2 -of=sambamba sambamba.p/sambamba_main.d.o > sambamba.p/sambamba_depth.d.o sambamba.p/sambamba_fixbins.d.o > sambamba.p/sambamba_flagstat.d.o sambamba.p/sambamba_index.d.o > sambamba.p/sambamba_markdup2.d.o sambamba.p/sambamba_markdup.d.o > sambamba.p/sambamba_merge.d.o sambamba.p/sambamba_pileup.d.o > sambamba.p/sambamba_slice.d.o sambamba.p/sambamba_sort.d.o > sambamba.p/sambamba_subsample.d.o sambamba.p/sambamba_utils_common_bed.d.o > sambamba.p/sambamba_utils_common_file.d.o > sambamba.p/sambamba_utils_common_filtering.d.o > sambamba.p/sambamba_utils_common_intervaltree.d.o > sambamba.p/sambamba_utils_common_ldc_gc_workaround.d.o > sambamba.p/sambamba_utils_common_overwrite.d.o > sambamba.p/sambamba_utils_common_pratt_parser.d.o > sambamba.p/sambamba_utils_common_progressbar.d.o > sambamba.p/sambamba_utils_common_queryparser.d.o > sambamba.p/sambamba_utils_common_readstorage.d.o > sambamba.p/sambamba_utils_common_tmpdir.d.o > sambamba.p/sambamba_utils_view_alignmentrangeprocessor.d.o > sambamba.p/sambamba_utils_view_headerserializer.d.o > sambamba.p/sambamba_validate.d.o sambamba.p/sambamba_view.d.o > sambamba.p/utils_lz4.d.o sambamba.p/utils_strip_bcf_header.d.o > sambamba.p/utils_version_.d.o sambamba.p/cram_exception.d.o > sambamba.p/cram_htslib.d.o sambamba.p/cram_reader.d.o > sambamba.p/cram_reference.d.o sambamba.p/cram_slicereader.d.o > sambamba.p/cram_wrappers.d.o sambamba.p/cram_writer.d.o > sambamba.p/thirdparty_mergesort.d.o sambamba.p/thirdparty_unstablesort.d.o > sambamba.p/_build_sambamba-0.7.1_obj-x86_64-linux-gnu_utils_ldc_version_info_.d.o > -L=--allow-shlib-undefined -link-defaultlib-shared -O -g -release -wi -L=-z > -L=relro -L=/usr/lib/x86_64-linux-gnu/libbiod.a > -L=/usr/lib/x86_64-linux-gnu/libz.a -L=/usr/lib/x86_64-linux-gnu/libhts.a > -L=-z -L=relro -L=-z -L=now -L=-flto -fvisibility=hidden > -L=/usr/lib/x86_64-linux-gnu/libbz2.a > -L=/usr/lib/x86_64-linux-gnu/libdeflate.a -L=-lm -L=-lpthread > -L=/usr/lib/x86_64-linux-gnu/liblzma.a > /usr/lib/gcc/x86_64-linux-gnu/10/../../../x86_64-linux-gnu/liblz4.so > /usr/lib/x86_64-linux-gnu/libcurl.so /usr/lib/x86_64-linux-gnu/libcrypto.so > /usr/lib/x86_64-linux-gnu/liblzma.so -L=-rpath > -L=/usr/lib/gcc/x86_64-linux-gnu/10/../../../x86_64-linux-gnu:/usr/lib/x86_64-linux-gnu > -L=-rpath-link -L=/usr/lib/gcc/x86_64-linux-gnu/10/../../../x86_64-linux-gnu > -L=-rpath-link -L=/usr/lib/x86_64-linux-gnu > FAILED: sambamba > ldc2 -of=sambamba sambamba.p/sambamba_main.d.o sambamba.p/sambamba_depth.d.o > sambamba.p/sambamba_fixbins.d.o sambamba.p/sambamba_flagstat.d.o > sambamba.p/sambamba_index.d.o sambamba.p/sambamba_markdup2.d.o > sambamba.p/sambamba_markdup.d.o sambamba.p/sambamba_merge.d.o > sambamba.p/sambamba_pileup.d.o sambamba.p/sambamba_slice.d.o > sambamba.p/sambamba_sort.d.o sambamba.p/sambamba_subsample.d.o > sambamba.p/sambamba_utils_common_bed.d.o > sambamba.p/sambamba_utils_common_file.d.o > sambamba.p/sambamba_utils_common_filtering.d.o > sambamba.p/sambamba_utils_common_intervaltree.d.o > sambamba.p/sambamba_utils_common_ldc_gc_workaround.d.o > sambamba.p/sambamba_utils_common_overwrite.d.o > sambamba.p/sambamba_utils_common_pratt_parser.d.o > sambamba.p/sambamba_utils_common_progressbar.d.o > sambamba.p/sambamba_utils_common_queryparser.d.o > sambamba.p/sambamba_utils_common_readstorage.d.o > sambamba.p/sambamba_utils_common_tmpdir.d.o > sambamba.p/sambamba_utils_view_alignmentrangeprocessor.d.o > sambamba.p/sambamba_utils_view_headerserializer.d.o > sambamba.p/sambamba_validate.d.o sambamba.p/sambamba_view.d.o >
Bug#957379: Commit that fix this issue is 129b7e402bd6e7278854e5a8935fce460552b5f4
Issue link: https://gitlab.isc.org/isc-projects/dhcp/-/issues/117 commit/merge request link: https://gitlab.isc.org/isc-projects/dhcp/-/commit/129b7e402bd6e7278854e5a8935fce460552b5f4?merge_request_iid=60 signature.asc Description: This is a digitally signed message part
Bug#966692: stunnel4: FTBFS because of test hang
On Thu, Aug 06, 2020 at 03:10:55AM +0200, Michał Mirosław wrote:
> On Thu, Aug 06, 2020 at 02:39:42AM +0200, Michał Mirosław wrote:
> > On Thu, Aug 06, 2020 at 03:16:35AM +0300, Peter Pentchev wrote:
> > > On Thu, Aug 06, 2020 at 12:48:10AM +0200, Michał Mirosław wrote:
> > > > On Thu, Aug 06, 2020 at 12:29:36AM +0300, Peter Pentchev wrote:
> > > > > On Wed, Aug 05, 2020 at 10:52:31PM +0200, Michał Mirosław wrote:
> > > > [...]
> > > > > > Using print-debugging, I see that it stops at wait_for_child line
> > > > > > just
> > > > > > after printing the version. It seems that something is reaping the
> > > > > > child
> > > > > > before the main thread has a chance to wait for it.
> > > > >
> > > > > OK, so the only thing that comes to my mind now is that you may be
> > > > > hitting a crazy, crazy race between register_child() and
> > > > > child_reaper(),
> > > > > and I say "a crazy, crazy race", because the test has to (apparently
> > > > > reproducibly) receive the CHLD signal exactly between the check and
> > > > > the creation in register_child()'s first "$children{...} //= ...cv"
> > > > > statement.
> > > >
> > > > Well, there is nothing that prevents SIGCHLD arriving between fork() and
> > > > register_child(). You could test this with more confidence (though not
> > > > 100%-reliably) by putting 'exit 1' just at the start of ($pid == 0)
> > > > branch.
> > >
> > > Nah, the problem is not just "between fork() and register_child()".
> > > It really must arrive at a very specific moment in time, because
> > > the //= operations for setting $children{$pid}{cv} try to make sure that
> > > a new value is not set (that is, a new condition variable is not
> > > created) if there already is such an element in the array. So the race
> > > is indeed between the //= in register_child() and the //= in
> > > child_reaper() - that is, child_reaper() must be invoked (SIGCHLD must
> > > arrive) *during* the execution of the //= in register_child().
> > >
> > > Unless I'm missing something, which is not at all out of the question :)
> >
> > The assignment seems not to be at fault (see last strace). I don't know
> > perl's
> > internals enough to say if this statement can be interrupted visibly by a
> > signal
> > handler (I would guess not a perl handler, though). There are two wait4()
> > calls
> > even before child_reaper has a chance to run.
>
> Another data point: this happens only with anyevent + libev and not with
> anyevent + libevent. The first is preferred and installed by default with
> libanyevent-perl, though.
>
> $ dpkg -l libanyevent-perl libev-perl | cat
> Desired=Unknown/Install/Remove/Purge/Hold
> | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
> |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
> ||/ Name Version Architecture Description
> +++----
> ii libanyevent-perl 7.140-3 amd64event loop framework with
> multiple implementations
> ii libev-perl 4.25-1 amd64Perl interface to libev, the
> high performance event loop
AnyEvent's doc [1] mentions that the framework installs (or just might?) it's
own SIGCHLD handler. Maybe there are just too many handlers for SIGCHLD?
[1] https://metacpan.org/pod/AnyEvent#SIGNALS
Best Regards,
Michał Mirosław
Bug#802852: CPack packaging code has been merged into the upstream
Olga Yakovleva has merged my PR https://github.com/Olga-Yakovleva/RHVoice/pull/135 bringing CMake support for building and CPack support for packaging. So, it creates packages that are ready to be installed. Though the packages are not yet debianic, I mean they don't have machine-readable copyright information, manpages and the changelog. But they work pretty well ;) Please notice there are some memory-safety issues are present in RHVoice. At least when built with CLang++-11 it sigsegvs. Needs investigation with help of valgrind and MSan and UBSan.
Bug#966692: stunnel4: FTBFS because of test hang
On Thu, Aug 06, 2020 at 02:39:42AM +0200, Michał Mirosław wrote:
> On Thu, Aug 06, 2020 at 03:16:35AM +0300, Peter Pentchev wrote:
> > On Thu, Aug 06, 2020 at 12:48:10AM +0200, Michał Mirosław wrote:
> > > On Thu, Aug 06, 2020 at 12:29:36AM +0300, Peter Pentchev wrote:
> > > > On Wed, Aug 05, 2020 at 10:52:31PM +0200, Michał Mirosław wrote:
> > > [...]
> > > > > Using print-debugging, I see that it stops at wait_for_child line just
> > > > > after printing the version. It seems that something is reaping the
> > > > > child
> > > > > before the main thread has a chance to wait for it.
> > > >
> > > > OK, so the only thing that comes to my mind now is that you may be
> > > > hitting a crazy, crazy race between register_child() and child_reaper(),
> > > > and I say "a crazy, crazy race", because the test has to (apparently
> > > > reproducibly) receive the CHLD signal exactly between the check and
> > > > the creation in register_child()'s first "$children{...} //= ...cv"
> > > > statement.
> > >
> > > Well, there is nothing that prevents SIGCHLD arriving between fork() and
> > > register_child(). You could test this with more confidence (though not
> > > 100%-reliably) by putting 'exit 1' just at the start of ($pid == 0)
> > > branch.
> >
> > Nah, the problem is not just "between fork() and register_child()".
> > It really must arrive at a very specific moment in time, because
> > the //= operations for setting $children{$pid}{cv} try to make sure that
> > a new value is not set (that is, a new condition variable is not
> > created) if there already is such an element in the array. So the race
> > is indeed between the //= in register_child() and the //= in
> > child_reaper() - that is, child_reaper() must be invoked (SIGCHLD must
> > arrive) *during* the execution of the //= in register_child().
> >
> > Unless I'm missing something, which is not at all out of the question :)
>
> The assignment seems not to be at fault (see last strace). I don't know perl's
> internals enough to say if this statement can be interrupted visibly by a
> signal
> handler (I would guess not a perl handler, though). There are two wait4()
> calls
> even before child_reaper has a chance to run.
Another data point: this happens only with anyevent + libev and not with
anyevent + libevent. The first is preferred and installed by default with
libanyevent-perl, though.
$ dpkg -l libanyevent-perl libev-perl | cat
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture Description
+++----
ii libanyevent-perl 7.140-3 amd64event loop framework with
multiple implementations
ii libev-perl 4.25-1 amd64Perl interface to libev, the
high performance event loop
Best Regards,
Michał Mirosław
Bug#963244: Wrong "Bug-Debian" in protobuf_generated_classes_no_inheritance.patch
I think that the wrong "Bug-Debian" tag was inserted in debian/patches/protobuf_generated_classes_no_inheritance.patch: Description: Fix build with latest protobuf Origin: gentoo https://gitweb.gentoo.org/repo/gentoo.git/plain/app-i18n/mozc/files/mozc-2.23.2815.102-protobuf_generated_classes_no_inheritance.patch Bug-Debian: http://bugs.debian.org/265678
Bug#966096: geeqie: immediate segfault
On Wed, 5 Aug 2020 19:41:14 -0400 James Van Zandt wrote: >Thanks! Though none of the discussion I saw there mentioned the >g_strsplit: assertion failed message. I'll hope for the best. > Ah, of course, if the fixes doesn't fix that specific problem, I'll split it out to a bug of it's own. /Andreas
Bug#967966: ITP: collectd-graph-panel -- web-based graphing app for collectd statistics
Package: wnpp Severity: wishlist Owner: Joseph Nahmias * Package name: collectd-graph-panel Version : 1 Upstream Author : Pim van den Berg * URL : http://pommi.nethuis.nl/category/cgp/ * License : GPL3 Programming Lang: PHP Description : web-based graphing app for collectd statistics Collectd Graph Panel (CGP) is a graphical web-based front-end for visualizing RRD collected by collectd, written in the PHP language.
Bug#966692: stunnel4: FTBFS because of test hang
On Thu, Aug 06, 2020 at 03:16:35AM +0300, Peter Pentchev wrote:
> On Thu, Aug 06, 2020 at 12:48:10AM +0200, Michał Mirosław wrote:
> > On Thu, Aug 06, 2020 at 12:29:36AM +0300, Peter Pentchev wrote:
> > > On Wed, Aug 05, 2020 at 10:52:31PM +0200, Michał Mirosław wrote:
> > [...]
> > > > Using print-debugging, I see that it stops at wait_for_child line just
> > > > after printing the version. It seems that something is reaping the child
> > > > before the main thread has a chance to wait for it.
> > >
> > > OK, so the only thing that comes to my mind now is that you may be
> > > hitting a crazy, crazy race between register_child() and child_reaper(),
> > > and I say "a crazy, crazy race", because the test has to (apparently
> > > reproducibly) receive the CHLD signal exactly between the check and
> > > the creation in register_child()'s first "$children{...} //= ...cv"
> > > statement.
> >
> > Well, there is nothing that prevents SIGCHLD arriving between fork() and
> > register_child(). You could test this with more confidence (though not
> > 100%-reliably) by putting 'exit 1' just at the start of ($pid == 0) branch.
>
> Nah, the problem is not just "between fork() and register_child()".
> It really must arrive at a very specific moment in time, because
> the //= operations for setting $children{$pid}{cv} try to make sure that
> a new value is not set (that is, a new condition variable is not
> created) if there already is such an element in the array. So the race
> is indeed between the //= in register_child() and the //= in
> child_reaper() - that is, child_reaper() must be invoked (SIGCHLD must
> arrive) *during* the execution of the //= in register_child().
>
> Unless I'm missing something, which is not at all out of the question :)
The assignment seems not to be at fault (see last strace). I don't know perl's
internals enough to say if this statement can be interrupted visibly by a signal
handler (I would guess not a perl handler, though). There are two wait4() calls
even before child_reaper has a chance to run.
> > > Can you apply the following patch and show me the output of running
> > > the test?
> >
> > Sure, but I got no patch. :-)
>
> Oof. Not my day, is it... Here it is... I hope.
[cut patch]
With the patch applied:
$ TEST_STUNNEL=src/stunnel strace -f -o /tmp/log debian/tests/runtime
Found the certificate at debian/tests/certs/certificate.pem and the
private key at debian/tests/certs/key.pem
Using the /tmp/user/1000/EklzlCzeRO temporary directory
About to get the stunnel version information
register_child: pid 14943 cv AnyEvent::CondVar=HASH(0x559e0d7572e0)
RDBG child_reaper() invoked
RDBG - pid -1 status -1
RDBG - done
RDBG - out of the child_reaper() loop
Got stunnel version 5.56
^C
And in the strace log:
14942 epoll_wait(3, [{EPOLLIN, {u32=5, u64=4294967301}}], 64, 59743) = 1
14942 epoll_wait(3, [{EPOLLIN, {u32=5, u64=4294967301}}], 64, 59743) = 1
14943 exit_group(0
14942 read(5,
14943 <... exit_group resumed>) = ?
14942 <... read resumed> "TIMEOUTconnect = 10 seco"..., 8192) = 105
14942 epoll_wait(3, [{EPOLLHUP, {u32=5, u64=4294967301}}], 64, 59743) = 1
14943 +++ exited with 0 +++
14942 epoll_ctl(3, EPOLL_CTL_MOD, 5, {EPOLLIN, {u32=5, u64=4294967301}}) = 0
14942 --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=14943,
si_uid=1000, si_status=0, si_utime=0, si_stime=0} ---
14942 write(4, "\1\0\0\0\0\0\0\0", 8) = 8
14942 rt_sigreturn({mask=[PIPE]}) = 0
14942 epoll_wait(3, [{EPOLLHUP, {u32=5, u64=4294967301}}, {EPOLLIN, {u32=4,
u64=4294967300}}], 64, 59743) = 2
14942 epoll_ctl(3, EPOLL_CTL_MOD, 5, {EPOLLIN, {u32=5, u64=4294967301}}) = 0
14942 read(4, "\1\0\0\0\0\0\0\0", 8)= 8
14942 wait4(-1, [{WIFEXITED(s) && WEXITSTATUS(s) == 0}],
WNOHANG|WSTOPPED|WCONTINUED, NULL) = 14943
14942 wait4(-1, 0x7fffcacfddc4, WNOHANG|WSTOPPED|WCONTINUED, NULL) = -1 ECHILD
(No child processes)
14942 write(1, "RDBG child_reaper() invoked\n", 28) = 28
14942 wait4(-1, 0x7fffcacfdb74, WNOHANG, NULL) = -1 ECHILD (No child processes)
14942 write(1, "RDBG - pid -1 status -1\n", 24) = 24
14942 write(1, "RDBG - done\n", 14) = 14
14942 write(1, "RDBG - out of the child_reaper()"..., 38) = 38
14942 epoll_wait(3, [{EPOLLHUP, {u32=5, u64=4294967301}}], 64, 59743) = 1
14942 epoll_ctl(3, EPOLL_CTL_MOD, 5, {EPOLLIN, {u32=5, u64=4294967301}}) = 0
14942 read(5, "", 8192) = 0
14942 write(1, "Got stunnel version 5.56\n", 25) = 25
14942 epoll_wait(3, [{EPOLLHUP, {u32=5, u64=4294967301}}], 64, 59743) = 1
14942 epoll_ctl(3, EPOLL_CTL_DEL, 5, 0x559e0dba9760) = 0
14942 epoll_wait(3, 0x559e0dba9760, 64, 59743) = -1 EINTR (Interrupted system
call)
14942 --- SIGINT {si_signo=SIGINT, si_code=SI_KERNEL} ---
With 'exit 1' in child branch:
$ TEST_STUNNEL=src/stunnel strace -f -o /tmp/log debian/tests/runtime
Found the certificate at debian/tests/certs/certificate.pem and the private key
at debian/tests/certs/key.pem
Using the /tmp/user/1000/MWxDeDDlxS temporary
Bug#967965: astropy: FTBFS with scipy 1.5: [doctest] astropy.stats.funcs.binom_conf_interval failed
Source: astropy Version: 4.0.1+post1-3 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) Control: found -1 4.1~rc1-2 Hi, astropy recently started to FTBFS in sid (and experimental, but not yet in bullseye). I could reproduce the failure in bullseye with python3-scipy/sid: === FAILURES === __ [doctest] astropy.stats.funcs.binom_conf_interval ___ 631 632 Integer inputs return an array with shape (2,): 633 634 >>> binom_conf_interval(4, 5, interval='wilson') 635 array([0.57921724, 0.92078259]) 636 637 Arrays of arbitrary dimension are supported. The Wilson and Jeffreys 638 intervals give similar results, even for small k, N: 639 640 >>> binom_conf_interval([0, 1, 2, 5], 5, interval='wilson') Expected: array([[0., 0.07921741, 0.21597328, 0.8304], [0.1696, 0.42078276, 0.61736012, 1.]]) Got: array([[1.38777878e-17, 7.92174125e-02, 2.15973276e-01, 8.3042e-01], [1.6958e-01, 4.20782762e-01, 6.17360116e-01, 1.e+00]]) /build/astropy-4.0.1+post1/.pybuild/cpython3_3.8/build/astropy/stats/funcs.py:640: DocTestFailure = 1 failed, 13907 passed, 412 skipped, 49 xfailed, 12 xpassed in 169.79 seconds = Andreas astropy_bullseye+scipy_sid.build.gz Description: application/gzip
Bug#967964: unison-2.48: file conflict with unison -4
Package: unison-2.48 Version: 2.48.4-5+b1 Severity: serious Justification: fails to upgrade Hi! I'm afraid there's no Replaces: stanza, resulting in: Unpacking unison-2.48 (2.48.4-5+b1) ... dpkg: error processing archive /tmp/apt-dpkg-install-Q6eH0z/4-unison-2.48_2.48.4-5+b1_amd64 .deb (--unpack): trying to overwrite '/usr/bin/unison-2.48', which is also in package unison 2.48.4-4 dpkg-deb: error: paste subprocess was killed by signal (Broken pipe) Obviously: Replaces: unison (<< 2.48.4-5~) -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'stable'), (150, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.8.0-umbar-00027-gfee487f15878 (SMP w/6 CPU threads) Kernel taint flags: TAINT_WARN Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages unison-2.48 depends on: ii libc6 2.31-3 Versions of packages unison-2.48 recommends: ii openssh-client [ssh-client] 1:8.3p1-1 Versions of packages unison-2.48 suggests: pn unison-all -- no debconf information
Bug#966692: stunnel4: FTBFS because of test hang
On Thu, Aug 06, 2020 at 12:48:10AM +0200, Michał Mirosław wrote:
> On Thu, Aug 06, 2020 at 12:29:36AM +0300, Peter Pentchev wrote:
> > On Wed, Aug 05, 2020 at 10:52:31PM +0200, Michał Mirosław wrote:
> [...]
> > > Using print-debugging, I see that it stops at wait_for_child line just
> > > after printing the version. It seems that something is reaping the child
> > > before the main thread has a chance to wait for it.
> >
> > OK, so the only thing that comes to my mind now is that you may be
> > hitting a crazy, crazy race between register_child() and child_reaper(),
> > and I say "a crazy, crazy race", because the test has to (apparently
> > reproducibly) receive the CHLD signal exactly between the check and
> > the creation in register_child()'s first "$children{...} //= ...cv"
> > statement.
>
> Well, there is nothing that prevents SIGCHLD arriving between fork() and
> register_child(). You could test this with more confidence (though not
> 100%-reliably) by putting 'exit 1' just at the start of ($pid == 0) branch.
Nah, the problem is not just "between fork() and register_child()".
It really must arrive at a very specific moment in time, because
the //= operations for setting $children{$pid}{cv} try to make sure that
a new value is not set (that is, a new condition variable is not
created) if there already is such an element in the array. So the race
is indeed between the //= in register_child() and the //= in
child_reaper() - that is, child_reaper() must be invoked (SIGCHLD must
arrive) *during* the execution of the //= in register_child().
Unless I'm missing something, which is not at all out of the question :)
> > Can you apply the following patch and show me the output of running
> > the test?
>
> Sure, but I got no patch. :-)
Oof. Not my day, is it... Here it is... I hope.
G'luck,
Peter
--
Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13
commit 859acd0603a5bc74620df4949e1450805b7ba151
Author: Peter Pentchev
Date: Thu Aug 6 00:26:32 2020 +0300
Diagnostic output for the runtime test's child reaper.
diff --git a/debian/tests/runtime b/debian/tests/runtime
index f594d9a..81cef23 100755
--- a/debian/tests/runtime
+++ b/debian/tests/runtime
@@ -55,19 +55,25 @@ sub unregister_child_reaper()
sub child_reaper()
{
+ say 'RDBG child_reaper() invoked';
while (1) {
my $pid = waitpid -1, WNOHANG;
my $status = $?;
+ say "RDBG - pid $pid status $status";
if (!defined $pid) {
die "Could not waitpid() in a SIGCHLD handler: $!\n";
} elsif ($pid == 0 || $pid == -1) {
+ say 'RDBG - done';
last;
} else {
+ say 'RDBG - '.(exists $children{$pid} ? '' : 'not
').'found in the children hash';
$children{$pid}{cv} //= AnyEvent->condvar;
+ say 'RDBG - cv '.$children{$pid}{cv}.':
'.($children{$pid}{cv}->ready ? '' : 'not ').'ready';
$children{$pid}{cv}->send($status);
}
}
+ say 'RDBG - out of the child_reaper() loop';
}
sub register_child($ $)
@@ -76,6 +82,7 @@ sub register_child($ $)
# Weird, but we want it to be at least reasonably atomic-like
$children{$pid}{cv} //= AnyEvent->condvar;
+ say "register_child: pid $pid cv ".$children{$pid}{cv};
my $ch = $children{$pid};
$ch->{pid} = $pid;
signature.asc
Description: PGP signature
Bug#967963: installation failure: rockpro64
Package: installation-reports Boot method: SD card Image version: https://d-i.debian.org/daily-images/arm64/20200727-02:25/netboot/SD-card-images/firmware.rockpro64-rk3399.img.gz Date: 2020-08-05 Machine: RockPro64 Processor: Rockchip rk3399 Memory: 4GB Partitions: /dev/mmcblk1p1 Output of lspci -knn (or lspci -nn): 00:00.0 PCI bridge [0604]: Fuzhou Rockchip Electronics Co., Ltd RK3399 PCI Express Root Port [1d87:0100] Kernel driver in use: pcieport 01:00.0 SATA controller [0106]: Marvell Technology Group Ltd. 88SE9235 PCIe 2.0 x2 4-port SATA 6 Gb/s Controller [1b4b:9235] (rev 11) Subsystem: Marvell Technology Group Ltd. 88SE9235 PCIe 2.0 x2 4-port SATA 6 Gb/s Control Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot: [O] Detect network card:[O] Configure network: [O] Detect media: [O] Load installer modules: [E] Detect hard drives: [ ] Partition hard drives: [ ] Install base system:[ ] Clock/timezone setup: [ ] User/password setup:[ ] Install tasks: [ ] Install boot loader:[ ] Overall install:[E] Comments/Problems: I used the installer image from over a week ago, because d-i.debian.org has no newer daily images. Booting with my serial adapter set for 150 bps showed nothing but garbage. Using 115200 bps instead showed several bootloader messages clearly, and then nothing but garbage. Editing extlinux.conf to append console=ttyS2,115200n8 to the kernel command line and then setting my serial port to that speed made kernel boot messages visible and allowed me operate the debian installer. The installer stopped at the "Download installer components" step, displaying this message: """ No kernel modules were found. This probably is due to a mismatch between the kernel used by this version of the installer and the kernel version available in the archive. You should make sure that your installation image is up-to-date, or - if that's the case - try a different mirror, preferably deb.debian.org. """ Last lines in the "log" virtual screen: """ Jan 1 00:07:07 net-retriever: gpgv: key DC30D7C23CBBABEE was created 18000 days in the future (time warp or clock problem) Jan 1 00:07:07 net-retriever: gpgv: key 648ACFD622F3D138 was created 18000 days in the future (time warp or clock problem) Jan 1 00:07:07 net-retriever: gpgv: Good signature from "Debian Archive Automatic Signing Key (10/buster) " Jan 1 00:07:07 anna[1474]: 1970-01-01 00:07:07 URL:http://deb.debian.org/debian//dists/unstable/main/debian-installer/binary-arm64/Packages.xz [51000/51000] -> "/tmp/_fetch-url_net-retriever-1476-Packages.1509" [1] Jan 1 00:07:08 anna[1474]: 1970-01-01 00:07:08 URL:http://deb.debian.org/debian//dists/unstable/contrib/debian-installer/binary-arm64/Packages.xz [32/32] -> "/tmp/_fetch-url_net-retriever-1476-Packages.1530" [1] Jan 1 00:07:09 anna[1474]: 1970-01-01 00:07:09 URL:http://deb.debian.org/debian//dists/unstable/non-free/debian-installer/binary-arm64/Packages.xz [32/32] -> "/tmp/_fetch-url_net-retriever-1476-Packages.1551" [1] Jan 1 00:07:09 anna[1474]: WARNING **: no packages matching running kernel 5.7.0-1-arm64 in archive """
Bug#967962: lintian: wildcard-matches-nothing-in-dep5-copyright incorrectly reported for existing file
Package: lintian Version: 2.87.0 Severity: normal With neovim 0.4.3-3, lintian is reporting: neovim source: wildcard-matches-nothing-in-dep5-copyright scripts/check_urls.vim (line 13) However, such a file does exist: $ tar atf neovim_0.4.3.orig.tar.gz | grep check_urls neovim-0.4.3/scripts/check_urls.vim -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.7.0-2-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages lintian depends on: ii binutils 2.35-1 ii bzip2 1.0.8-4 ii diffstat 1.63-1 ii dpkg 1.20.5 ii dpkg-dev 1.20.5 ii file 1:5.38-5 ii gettext 0.19.8.1-10 ii gpg 2.2.20-1 ii intltool-debian 0.35.0+20060710.5 ii libapt-pkg-perl 0.1.36+b3 ii libarchive-zip-perl 1.68-1 ii libcapture-tiny-perl 0.48-1 ii libclass-xsaccessor-perl 1.19-3+b5 ii libclone-perl 0.45-1 ii libconfig-tiny-perl 2.24-1 ii libcpanel-json-xs-perl4.19-1 ii libdata-dpath-perl0.58-1 ii libdata-validate-domain-perl 0.10-1 ii libdevel-size-perl0.83-1+b1 ii libdpkg-perl 1.20.5 ii libemail-address-xs-perl 1.04-1+b2 ii libfile-basedir-perl 0.08-1 ii libfile-find-rule-perl0.34-1 ii libfont-ttf-perl 1.06-1 ii libhtml-parser-perl 3.72-5 ii libio-async-loop-epoll-perl 0.21-1 ii libio-async-perl 0.77-3 ii libipc-run3-perl 0.048-2 ii libjson-maybexs-perl 1.004002-1 ii liblist-compare-perl 0.53-1 ii liblist-moreutils-perl0.416-1+b5 ii liblist-utilsby-perl 0.11-1 ii libmoo-perl 2.004000-1 ii libmoox-aliases-perl 0.001006-1 ii libnamespace-clean-perl 0.27-1 ii libpath-tiny-perl 0.114-1 ii libperlio-gzip-perl 0.19-1+b6 ii libsereal-decoder-perl4.018+ds-1 ii libsereal-encoder-perl4.018+ds-1 ii libtext-levenshteinxs-perl0.03-4+b7 ii libtext-xslate-perl 3.5.8-1 ii libtime-duration-perl 1.21-1 ii libtime-moment-perl 0.44-1+b2 ii libtimedate-perl 2.3300-1 ii libtry-tiny-perl 0.30-1 ii libtype-tiny-perl 1.010002-1 ii libunicode-utf8-perl 0.62-1+b1 ii liburi-perl 1.76-2 ii libxml-libxml-perl2.0134+dfsg-2 ii libxml-writer-perl0.625-1 ii libyaml-libyaml-perl 0.82+repack-1 ii lzip 1.21-7 ii man-db2.9.3-2 ii patchutils0.4.2-1 ii perl [libdigest-sha-perl] 5.30.3-4 ii t1utils 1.41-4 ii xz-utils 5.2.4-1+b1 lintian recommends no packages. Versions of packages lintian suggests: pn binutils-multiarch pn libtext-template-perl -- no debconf information
Bug#967961: lintian: redundant-globbing-patterns reported for globs in the same Files stanza
Package: lintian Version: 2.87.0 Severity: normal As seen in neovim 0.4.3-3, lintian is expecting globs in a single Files paragraph to follow the same ordering expectations of globs in separate Files paragraph. E: neovim source: redundant-globbing-patterns [src/nvim/api/* src/nvim/*.lua] for src/nvim/api/dispatch_deprecated.lua N: N:Two globbing patterns in the same Files section in debian/copyright N:match the same file. N: N:This situation can occur when a narrow pattern should apply the same N:license as a broader pattern. Please create another Files section for N:the narrow pattern and place it below other patterns that compete for N:the same files. N: N:Refer to N:https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ for N:details. N: N:Severity: error N: N:Check: debian/copyright/dep5 Policy's description of the narrowing effect of globs is: Multiple Files paragraphs are allowed. The last paragraph that matches a particular file applies to it. More general paragraphs should therefore be given first, followed by more specific overrides. It's applied on a paragraph-by-paragraph basis, not globs within the same paragraph. -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.7.0-2-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages lintian depends on: ii binutils 2.35-1 ii bzip2 1.0.8-4 ii diffstat 1.63-1 ii dpkg 1.20.5 ii dpkg-dev 1.20.5 ii file 1:5.38-5 ii gettext 0.19.8.1-10 ii gpg 2.2.20-1 ii intltool-debian 0.35.0+20060710.5 ii libapt-pkg-perl 0.1.36+b3 ii libarchive-zip-perl 1.68-1 ii libcapture-tiny-perl 0.48-1 ii libclass-xsaccessor-perl 1.19-3+b5 ii libclone-perl 0.45-1 ii libconfig-tiny-perl 2.24-1 ii libcpanel-json-xs-perl4.19-1 ii libdata-dpath-perl0.58-1 ii libdata-validate-domain-perl 0.10-1 ii libdevel-size-perl0.83-1+b1 ii libdpkg-perl 1.20.5 ii libemail-address-xs-perl 1.04-1+b2 ii libfile-basedir-perl 0.08-1 ii libfile-find-rule-perl0.34-1 ii libfont-ttf-perl 1.06-1 ii libhtml-parser-perl 3.72-5 ii libio-async-loop-epoll-perl 0.21-1 ii libio-async-perl 0.77-3 ii libipc-run3-perl 0.048-2 ii libjson-maybexs-perl 1.004002-1 ii liblist-compare-perl 0.53-1 ii liblist-moreutils-perl0.416-1+b5 ii liblist-utilsby-perl 0.11-1 ii libmoo-perl 2.004000-1 ii libmoox-aliases-perl 0.001006-1 ii libnamespace-clean-perl 0.27-1 ii libpath-tiny-perl 0.114-1 ii libperlio-gzip-perl 0.19-1+b6 ii libsereal-decoder-perl4.018+ds-1 ii libsereal-encoder-perl4.018+ds-1 ii libtext-levenshteinxs-perl0.03-4+b7 ii libtext-xslate-perl 3.5.8-1 ii libtime-duration-perl 1.21-1 ii libtime-moment-perl 0.44-1+b2 ii libtimedate-perl 2.3300-1 ii libtry-tiny-perl 0.30-1 ii libtype-tiny-perl 1.010002-1 ii libunicode-utf8-perl 0.62-1+b1 ii liburi-perl 1.76-2 ii libxml-libxml-perl2.0134+dfsg-2 ii libxml-writer-perl0.625-1 ii libyaml-libyaml-perl 0.82+repack-1 ii lzip 1.21-7 ii man-db2.9.3-2 ii patchutils0.4.2-1 ii perl [libdigest-sha-perl] 5.30.3-4 ii t1utils 1.41-4 ii xz-utils 5.2.4-1+b1 lintian recommends no packages. Versions of packages lintian suggests: pn binutils-multiarch pn libtext-template-perl -- no debconf information
Bug#966096: geeqie: immediate segfault
Thanks! Though none of the discussion I saw there mentioned the g_strsplit: assertion failed message. I'll hope for the best. On Wed, Aug 5, 2020 at 4:19 PM Andreas Ronnquist wrote: > On Wed, 22 Jul 2020 20:02:43 -0400 James Van Zandt > wrote: > > Package: geeqie > > Version: 1:1.5.1-11 > > Severity: important > > X-Debbugs-Cc: jim.vanza...@gmail.com > > > > /tmp/bug > > > > I assume this is the bug: > https://github.com/BestImageViewer/geeqie/issues/559 > > I will probably package a git snapshot (again) if upstream don't make a > new release soon, and then you will have the option --disable-clutter > which should make it possible to run again. > > /Andreas >
Bug#935035: u-boot: Olimex Teres-I support for builtin keyboard
Quoting Vagrant Cascadian (2020-07-21 19:43:21) > On 2020-07-21, Jonas Smedegaard wrote: > > Quoting Jonas Smedegaard (2020-07-21 02:28:11) > >> Quoting Vagrant Cascadian (2020-07-20 22:05:43) > >> > I think could probably be trimmed down to a more minimal patch. e.g. > >> > It doesn't look like CONFIG_USE_PREBOOT is needed at all; I *think* > >> > you could just use CONFIG_PREBOOT without adding Kconfig support > >> > (needs testing) and then use ifdef/ifndef directly where the preboot > >> > command is added. > >> > >> Sorry, I don't follow how you think it could be done without per-board > >> definitions. > > > > Sleeping on it helped: I figured it out - here's a much shorter patch: > > https://salsa.debian.org/debian/u-boot/-/commit/17bcf50 > > Yeah, that's more like what I was thinking! Clever figuring out > configuration options only present on the teres-i. :) > > > > Tested to work with TERES-I laptop. > > > > I also issued a minor update to the upstream patch: > > https://patchwork.ozlabs.org/project/uboot/list/?series=191157 > > Yeah, wondered about usb "reset" vs usb "start". Part 1/2 entered mainline u-boot few hours ago. The remaining part, touching only Teres-I, bumped and still pending: https://patchwork.ozlabs.org/project/uboot/list/?series=194355 - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#967917:
Seeing this problem as well with the latest LVM package update on unstable.
Setting up dmeventd (2:1.02.171-2) ...
dm-event.service is a disabled or a static unit not running, not starting
it.
Setting up systemd-sysv (246-2) ...
Setting up grub2-common (2.04-9) ...
Setting up libnss-systemd:amd64 (246-2) ...
Setting up grub-pc-bin (2.04-9) ...
Setting up lvm2 (2.03.09-2) ...
update-initramfs: deferring update (trigger activated)
Failed to start blk-availability.service: Unit blk-availability.service has
a bad unit file setting.
See system logs and 'systemctl status blk-availability.service' for details.
Setting up grub-pc (2.04-9) ...
Installing for i386-pc platform.
Installation finished. No error reported.
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-5.7.0-2-amd64
Found initrd image: /boot/initrd.img-5.7.0-2-amd64
done
Setting up libpam-systemd:amd64 (246-2) ...
# systemctl status blk-availability.service
● blk-availability.service - Availability of block devices
Loaded: bad-setting (Reason: Unit blk-availability.service has a bad
unit file setting.)
Active: active (exited) since Fri 2020-06-26 18:15:45 EDT; 1 months 9
days ago
Main PID: 227 (code=exited, status=0/SUCCESS)
CGroup: /system.slice/blk-availability.service
Aug 05 16:59:36 testlaptop systemd[1]: blk-availability.service: Unit
configuration has fatal error, unit will not be started.
Aug 05 16:59:36 testlaptop systemd[1]:
/lib/systemd/system/blk-availability.service:10: Neither a valid executable
name nor an absolute path: ${exec_prefix}/bin/true
Aug 05 16:59:36 testlaptop systemd[1]: blk-availability.service: Unit
configuration has fatal error, unit will not be started.
Aug 05 16:59:37 testlaptop systemd[1]:
/lib/systemd/system/blk-availability.service:10: Neither a valid executable
name nor an absolute path: ${exec_prefix}/bin/true
Aug 05 16:59:37 testlaptop systemd[1]: blk-availability.service: Unit
configuration has fatal error, unit will not be started.
Aug 05 16:59:38 testlaptop systemd[1]:
/lib/systemd/system/blk-availability.service:10: Neither a valid executable
name nor an absolute path: ${exec_prefix}/bin/true
Aug 05 16:59:38 testlaptop systemd[1]: blk-availability.service: Unit
configuration has fatal error, unit will not be started.
Aug 05 17:00:08 testlaptop systemd[1]:
/lib/systemd/system/blk-availability.service:10: Neither a valid executable
name nor an absolute path: ${exec_prefix}/bin/true
Aug 05 17:00:08 testlaptop systemd[1]: blk-availability.service: Unit
configuration has fatal error, unit will not be started.
Aug 05 17:00:08 testlaptop systemd[1]: blk-availability.service: Cannot add
dependency job, ignoring: Unit blk-availability.service has a bad unit file
setting.
# dpkg -l | grep lvm
ii liblvm2cmd2.03:amd64 2.03.09-2 amd64
LVM2 command library
ii lvm2 2.03.09-2 amd64
Linux Logical Volume Manager
Bug#936873: libhdate: diff for NMU version 1.6.02-2.1
Hi Bourch, We're still alive/here, and any help is much appreciated (thanks Moritz, feel free to NMU, no need to wait for us). Most members are busy with Debconf20 (moved from Haifa to an online conference). On Wed, Aug 5, 2020 at 10:42 PM Boruch Baum wrote: > Thanks Moritz for stepping forward and adopting this. I still haven't > heard back from any member of the 'Debian Hebrew Maintainers' team, but > will continue in the future to attempt to use them as a first point of > contact until/unless I hear that they have been disolved / superseded / > replaced. Any word on why the silence from them? > > On 2020-08-05 19:57, Moritz Mühlenhoff wrote: > > The debdiff for my NMU for libhdate (versioned as 1.6.02-2.1) > > > > Cheers, > > Moritz > > -- > hkp://keys.gnupg.net > CA45 09B5 5351 7C11 A9D1 7286 0036 9E45 1595 8BC0 > >
Bug#967922: [pkg-cryptsetup-devel] Bug#967922: initramfs-tools-core: /run/cryptsetup should be configure with /usr/lib/tmpfiles.d/cryptsetup.conf
Control: tag -1 moreinfo On Tue, 04 Aug 2020 at 22:14:13 -0500, Diego Escalante Urrelo wrote: > `initramfs-core-tools` however just creates it manually: > […] > So, I believe perhaps the above directory might follow upstream > recommendation and be created in a tmpfiles.d configuration file. tmpfiles.d are AFAICT not honored at initramfs stage, and if that's indeed the case I believe we're following the upstream recommendation: | If your distro does not support tmpfiles.d directory, you have | to create locking directory (/run/lock/cryptsetup) in cryptsetup | package (or init scripts). (from docs/v2.0.0-ReleaseNotes.) > `dracut` does something similar in its scripts, but apparently in my > system systemd takes over and said script is never run, or ran too late? The dracut stuff is not shipped by src:cryptsetup. In our scripts we also create the directory *before* the first call to cryptsetup(8). I'm not sure what the problem is? -- Guilhem. signature.asc Description: PGP signature
Bug#967958: linux-image-5.7.0-2-amd64: thinkpad 495 LED for mute button no longer works after upgrading kernel
I believe it was 4.19. I also know it was working in 4.10 when I originally installed debian testing in june. ~Justin On Wed, Aug 5, 2020 at 6:49 PM Ben Hutchings wrote: > What was the last version you used in which this worked? > > Ben. > > -- > Ben Hutchings > Theory and practice are closer in theory than in practice - John Levine > > >
Bug#967958: linux-image-5.7.0-2-amd64: thinkpad 495 LED for mute button no longer works after upgrading kernel
What was the last version you used in which this worked? Ben. -- Ben Hutchings Theory and practice are closer in theory than in practice - John Levine signature.asc Description: This is a digitally signed message part
Bug#967922: initramfs-tools-core: /run/cryptsetup should be configure with /usr/lib/tmpfiles.d/cryptsetup.conf
Control: reassign -1 cryptsetup-initramfs On Tue, 2020-08-04 at 22:14 -0500, Diego Escalante Urrelo wrote: > Package: initramfs-tools-core > Version: 0.137 > Severity: normal > X-Debbugs-Cc: die...@gnome.org > > cryptsetup expects the `/run/cryptsetup` directory to exist, and > according to upstream the preferred way to get it to exist is with a > tmpfiles.d file: > https://gitlab.com/cryptsetup/cryptsetup/-/merge_requests/99#note_390506222 > > `initramfs-core-tools` however just creates it manually: > ``` > /usr/share/initramfs-tools /scripts/local-top/cryptroot: [...] This is not part of initramfs-tools-core, but part of cryptsetup- initramfs. (Use 'dpkg -S' to see which package owns a file.) Ben. -- Ben Hutchings Theory and practice are closer in theory than in practice - John Levine signature.asc Description: This is a digitally signed message part
Bug#966692: stunnel4: FTBFS because of test hang
On Thu, Aug 06, 2020 at 12:29:36AM +0300, Peter Pentchev wrote:
> On Wed, Aug 05, 2020 at 10:52:31PM +0200, Michał Mirosław wrote:
[...]
> > Using print-debugging, I see that it stops at wait_for_child line just
> > after printing the version. It seems that something is reaping the child
> > before the main thread has a chance to wait for it.
>
> OK, so the only thing that comes to my mind now is that you may be
> hitting a crazy, crazy race between register_child() and child_reaper(),
> and I say "a crazy, crazy race", because the test has to (apparently
> reproducibly) receive the CHLD signal exactly between the check and
> the creation in register_child()'s first "$children{...} //= ...cv"
> statement.
Well, there is nothing that prevents SIGCHLD arriving between fork() and
register_child(). You could test this with more confidence (though not
100%-reliably) by putting 'exit 1' just at the start of ($pid == 0) branch.
> Can you apply the following patch and show me the output of running
> the test?
Sure, but I got no patch. :-)
Best Regards,
Michał Mirosław
Bug#967960: navit or navit-data does not include the layout xml files required to display maps.
Package: navit Version: 0.5.4+dfsg.1-4 Severity: normal Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? Downloading maps for navit from the navit map site and editing navit.xml didn't let maps be displayed * What exactly did you do (or not do) that was effective (or ineffective)? I downloaded a layout file from github https://github.com/navit-gps/navit/blob/trunk/navit/navit_layout_car_android_shipped.xml and edited the navit.xml to load it. e.g. * What was the outcome of this action? The map was able to be displayed * What outcome did you expect instead? the layouts should be packaged in navit-data and loaded automatically. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: arm64 (aarch64) Kernel: Linux 5.7-pinephone (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_CRAP Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages navit depends on: ii libc6 2.31-2 ii libdbus-1-3 1.12.20-1 ii libdbus-glib-1-20.110-5 ii libfontconfig1 2.13.1-4.2 ii libfreetype62.10.2+dfsg-3 ii libfribidi0 1.0.8-2 ii libgarmin0 0~svn320-6 ii libglib2.0-02.64.4-1 ii libgps263.20-12 ii libspeechd2 0.9.1-5 ii navit-data 0.5.4+dfsg.1-4 ii navit-gui-internal 0.5.4+dfsg.1-4 ii zlib1g 1:1.2.11.dfsg-2 Versions of packages navit recommends: ii gpsd 3.20-12 Versions of packages navit suggests: pn maptool -- no debconf information
Bug#967959: nitrocli: please include the bash-completion
Package: nitrocli
Version: 0.2.3-1
Severity: minor
Dear Maintainer,
nitrocli includes bash-completion:
https://github.com/d-e-s-o/nitrocli#bash-completion
Please enable this in the package! Attached is a simple example of how
I added it to another package.
-- System Information:
Debian Release: 10.5
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable'), (100,
'proposed-updates')
Architecture: amd64 (x86_64)
Kernel: Linux 4.19.0-9-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages nitrocli depends on:
ii libc6 2.28-10
ii libgcc1 1:8.3.0-6
ii libnitrokey3 3.4.1-4
Versions of packages nitrocli recommends:
ii gnupg-agent 2.2.12-1+deb10u1
ii gpg-agent [gnupg-agent] 2.2.12-1+deb10u1
nitrocli suggests no packages.
-- no debconf information
>From 18acf9c9c19b2f02a7f23b4a9235f17bc060a5c0 Mon Sep 17 00:00:00 2001
From: Hans-Christoph Steiner
Date: Wed, 5 Aug 2020 14:17:12 +0200
Subject: [PATCH 1/1] add bash-completion
---
debian/bash-completion/ocf-cc | 19 +++
debian/control| 1 +
debian/libocf-cc-java.bash-completion | 1 +
debian/rules | 2 +-
4 files changed, 22 insertions(+), 1 deletion(-)
create mode 100644 debian/bash-completion/ocf-cc
create mode 100644 debian/libocf-cc-java.bash-completion
diff --git a/debian/bash-completion/ocf-cc b/debian/bash-completion/ocf-cc
new file mode 100644
index 000..153dc4b
--- /dev/null
+++ b/debian/bash-completion/ocf-cc
@@ -0,0 +1,19 @@
+_have ocf-cc &&
+_ocf_cc()
+{
+local cur
+
+COMPREPLY=()
+cur="${COMP_WORDS[COMP_CWORD]}"
+prev="${COMP_WORDS[COMP_CWORD-1]}"
+
+case $prev in
+ '-r'|'-s')
+ return 0
+ ;;
+esac
+OPTS="-l -n -p -q -r -s -v"
+COMPREPLY=( $(compgen -W "${OPTS[*]}" -- $cur) )
+return 0
+}
+complete -F _ocf_cc ocf-cc
diff --git a/debian/control b/debian/control
index 8a63a49..2f8a993 100644
--- a/debian/control
+++ b/debian/control
@@ -6,6 +6,7 @@ Uploaders: Hans-Christoph Steiner
Build-Depends: debhelper-compat (= 13),
ant,
ant-optional,
+ bash-completion,
default-jdk-headless (>= 2:1.8) | default-jdk (>= 2:1.8),
javahelper,
ivy,
diff --git a/debian/libocf-cc-java.bash-completion
b/debian/libocf-cc-java.bash-completion
new file mode 100644
index 000..3f6ae58
--- /dev/null
+++ b/debian/libocf-cc-java.bash-completion
@@ -0,0 +1 @@
+debian/bash-completion/ocf-cc
diff --git a/debian/rules b/debian/rules
index 51a1ddc..f413584 100755
--- a/debian/rules
+++ b/debian/rules
@@ -4,7 +4,7 @@ include /usr/share/dpkg/default.mk
%:
- dh $@ --with javahelper
+ dh $@ --with bash-completion,javahelper
override_dh_auto_build:
ant dist -lib /usr/share/java/ivy.jar
--
2.20.1
Bug#967953: Package not installable in sid due to missing dependencies python-argcomplete and python-ipaddr
Hi Julian, Thanks for your submission. We've ported ifupdown2 to python3. Our release has been ready for a few months now, unfortunately our usual sponsor is not responding anymore. We are now looking for a new debian sponsor to upload our latest version to the debian repository. Best Julien On Wed, Aug 5, 2020 at 7:57 PM Julian Brost wrote: > > Package: ifupdown2 > Version: 1.2.7-1 > Severity: grave > > The package ifupdown2 currently cannot be installed on systems running > sid as the two of its dependencies, python-argcomplete and > python-ipaddr, are no longer present in sid. > > The suggested packages python-gvgen and python-mako also no longer exist.
Bug#967958: linux-image-5.7.0-2-amd64: thinkpad 495 LED for mute button no longer works after upgrading kernel
Package: src:linux Version: 5.7.10-1 Severity: normal Tags: upstream -- Package-specific info: ** Version: Linux version 5.7.0-2-amd64 (debian-ker...@lists.debian.org) (gcc version 9.3.0 (Debian 9.3.0-16), GNU ld (GNU Binutils for Debian) 2.35) #1 SMP Debian 5.7.10-1 (2020-07-26) ** Command line: BOOT_IMAGE=/boot/vmlinuz-5.7.0-2-amd64 root=UUID=d4e30f1e-7b0c-490f-ab75-ac0491e11b51 ro quiet ** Not tainted ** Kernel log: [2.951379] input: HDA Digital PCBeep as /devices/pci:00/:00:08.1/:06:00.6/sound/card1/input13 [2.951441] input: HD-Audio Generic Mic as /devices/pci:00/:00:08.1/:06:00.6/sound/card1/input14 [2.951492] input: HD-Audio Generic Headphone as /devices/pci:00/:00:08.1/:06:00.6/sound/card1/input15 [2.969492] iwlwifi :01:00.0: Detected Intel(R) Wireless-AC 9260, REV=0x324 [2.977628] systemd[1]: Starting Load/Save Screen Backlight Brightness of leds:tpacpi::kbd_backlight... [2.985580] systemd[1]: Condition check resulted in Dispatch Password Requests to Console Directory Watch being skipped. [2.985698] systemd[1]: Condition check resulted in FUSE Control File System being skipped. [2.985764] systemd[1]: Condition check resulted in Kernel Configuration File System being skipped. [2.985837] systemd[1]: Condition check resulted in Set Up Additional Binary Formats being skipped. [2.985863] systemd[1]: Condition check resulted in Store a System Token in an EFI Variable being skipped. [2.985890] systemd[1]: Condition check resulted in Rebuild Hardware Database being skipped. [2.985918] systemd[1]: Condition check resulted in Commit a transient machine-id on disk being skipped. [2.985936] systemd[1]: Condition check resulted in Platform Persistent Storage Archival being skipped. [2.992315] systemd[1]: Condition check resulted in Dispatch Password Requests to Console Directory Watch being skipped. [2.992447] systemd[1]: Condition check resulted in FUSE Control File System being skipped. [2.992509] systemd[1]: Condition check resulted in Kernel Configuration File System being skipped. [2.992575] systemd[1]: Condition check resulted in Set Up Additional Binary Formats being skipped. [2.992598] systemd[1]: Condition check resulted in Store a System Token in an EFI Variable being skipped. [2.992620] systemd[1]: Condition check resulted in Rebuild Hardware Database being skipped. [2.992648] systemd[1]: Condition check resulted in Commit a transient machine-id on disk being skipped. [2.992666] systemd[1]: Condition check resulted in Platform Persistent Storage Archival being skipped. [2.993591] systemd[1]: Finished Load AppArmor profiles. [2.995014] systemd[1]: Starting Raise network interfaces... [3.000131] kvm: Nested Virtualization enabled [3.000138] SVM: kvm: Nested Paging enabled [3.000138] SVM: Virtual VMLOAD VMSAVE supported [3.000138] SVM: Virtual GIF supported [3.015288] systemd[1]: Finished Load/Save Screen Backlight Brightness of leds:tpacpi::kbd_backlight. [3.023695] iwlwifi :01:00.0: base HW address: 04:33:c2:75:2f:e2 [3.048806] systemd[1]: Started Journal Service. [3.051684] MCE: In-kernel MCE decoding enabled. [3.051830] usb 4-2.4: New USB device found, idVendor=06cb, idProduct=00bd, bcdDevice= 0.00 [3.051831] usb 4-2.4: New USB device strings: Mfr=0, Product=0, SerialNumber=1 [3.051833] usb 4-2.4: SerialNumber: ead137803126 [3.053846] EDAC amd64: F17h_M10h detected (node 0). [3.054037] EDAC amd64: Node 0: DRAM ECC disabled. [3.058060] systemd-journald[284]: Received client request to flush runtime journal. [3.058729] alg: No test for fips(ansi_cprng) (fips_ansi_cprng) [3.088564] Bluetooth: Core ver 2.22 [3.088586] NET: Registered protocol family 31 [3.088587] Bluetooth: HCI device and connection manager initialized [3.088593] Bluetooth: HCI socket layer initialized [3.088596] Bluetooth: L2CAP socket layer initialized [3.088600] Bluetooth: SCO socket layer initialized [3.091690] ieee80211 phy0: Selected rate control algorithm 'iwl-mvm-rs' [3.092493] thermal thermal_zone0: failed to read out thermal zone (-61) [3.095659] iwlwifi :01:00.0 wlp1s0: renamed from wlan0 [3.144152] EDAC amd64: F17h_M10h detected (node 0). [3.144279] EDAC amd64: Node 0: DRAM ECC disabled. [3.146483] mc: Linux media interface: v0.10 [3.151320] input: TPPS/2 Elan TrackPoint as /devices/platform/i8042/serio1/serio2/input/input8 [3.153007] usbcore: registered new interface driver btusb [3.156839] Bluetooth: hci0: Firmware revision 0.1 build 164 week 20 2020 [3.162890] videodev: Linux video capture interface: v2.00 [3.212320] EDAC amd64: F17h_M10h detected (node 0). [3.212445] EDAC amd64: Node 0: DRAM ECC disabled. [3.224799] uvcvideo: Found UVC 1.10 device Integrated Camera (04f2:b6d9) [3.233140] uvcvideo 4-2.1:1.0:
Bug#890627: getting worse
In the 2 years since I filed this bug report, it's also started hotlinking a font from google, in addition to now 2 mathjax js files from cloudflare. The font seems to be packaged in Debian in fonts-paratype. -- see shy jo signature.asc Description: PGP signature
Bug#967029: take the bug to irc/support channel?
Hello bebyx, could you please take this bug to a Debian support channel [1] (I suggest IRC!) and find out, what package this needs to be reassigned to? And maybe collect more info along the way? Thanks, *t [1] https://www.debian.org/support
Bug#388182: Fixed in mdk 1.2.2 back in 2006
package mdk fixed 388182 1.2.2-1 forwarded 388182 https://savannah.gnu.org/bugs/?15746 thanks This bug was indeed fixed in mdk-1.2.2 released in August 2006. The changelog entry from the upstream NEWS file is as follows: """ * Version 1.2.2 (07/08/06) [snip] ** Bug fixes: [snip] - I1 and I2 in mixvm swapped to their correct position (closes #15746). """ Thanks for reporting it way back then, though! G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: PGP signature
Bug#966692: stunnel4: FTBFS because of test hang
On Wed, Aug 05, 2020 at 10:52:31PM +0200, Michał Mirosław wrote:
> On Wed, Aug 05, 2020 at 09:28:12PM +0300, Peter Pentchev wrote:
> > On Wed, Aug 05, 2020 at 08:01:53PM +0200, Michał Mirosław wrote:
> > > On Sun, Aug 02, 2020 at 05:34:40PM +0300, Peter Pentchev wrote:
> > > > On Sun, Aug 02, 2020 at 02:02:22AM +0200, Michał Mirosław wrote:
> > > [...]
> > > > --- a/debian/tests/runtime
> > > > +++ b/debian/tests/runtime
> > > > @@ -432,6 +432,7 @@ MAIN:
> > > >
> > > > if (!defined $line) {
> > > > $eof->send($got_version);
> > > > + undef $f_out;
> > > > } elsif (!$got_version) {
> > > > if ($line =~ m{^
> > > > stunnel \s+
> > >
> > > I believe $f_out will not be defined here, as it only gets set after
> > > sub{} is created. Perl confirms this:
> > >
> > > $ TEST_STUNNEL=src/stunnel strace -f -o /tmp/log debian/tests/runtime
> > > Global symbol "$f_out" requires explicit package name (did you forget to
> > > declare "my $f_out"?) at debian/tests/runtime line 435.
> > > Execution of debian/tests/runtime aborted due to compilation errors.
> >
> > Of course you're right. Sorry about that! That's what I get for writing
> > a patch three minutes before I have to head out and never remembering to
> > actually test it later :(
> >
> > How about the attached one?
[snip]
>
> This stops the endless readings of EOF, but:
>
> 1. the FD gets leaked (shouldn't matter much, though)
> 2. the test hangs anyway
>
> Using print-debugging, I see that it stops at wait_for_child line just
> after printing the version. It seems that something is reaping the child
> before the main thread has a chance to wait for it.
OK, so the only thing that comes to my mind now is that you may be
hitting a crazy, crazy race between register_child() and child_reaper(),
and I say "a crazy, crazy race", because the test has to (apparently
reproducibly) receive the CHLD signal exactly between the check and
the creation in register_child()'s first "$children{...} //= ...cv"
statement.
Can you apply the following patch and show me the output of running
the test?
G'luck,
Peter
--
Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13
signature.asc
Description: PGP signature
Bug#966069: analysis and partial patch
ghc-pkg dump output has changed slightly, it now indents values with spaces
to make then line up or something
haddock-interfaces: /usr/lib/ghc-doc/haddock/th-lift-0.8.1/th-lift.haddock
haddock-html: /usr/share/doc/libghc-th-lift-doc/html/
In some cases, it also wraps single line values to the next line:
haddock-interfaces:
/usr/lib/ghc-doc/haddock/filepath-bytestring-1.4.2.1.6/filepath-bytestring.haddock
This patch partially fixed it for me, but does not deal with the line wrapping,
which would take more of a rfc-822 type parser than this.
--- /usr/lib/ghc-doc/gen_contents_index.old 2020-08-05 17:05:47.355190738
-0400
+++ /usr/lib/ghc-doc/gen_contents_index 2020-08-05 17:05:49.967249906 -0400
@@ -26,13 +26,13 @@
my $fh = shift;
my %dat;
while (<$fh>) {
- if (/^name: (.*)/) {
+ if (/^name:\s+(.*)/) {
$dat{pkg} = $1;
- } elsif (/^version: (.*)/) {
+ } elsif (/^version:\s+(.*)/) {
$dat{ver} = $1;
- } elsif (/^haddock-interfaces: (.*)/) {
+ } elsif (/^haddock-interfaces:\s+(.*)/) {
$dat{ifaces} = $1;
- } elsif (/^haddock-html: (.*)/) {
+ } elsif (/^haddock-html:\s+(.*)/) {
$dat{html} = $1;
} elsif (/^---/) {
process(\%dat, @_);
--
see shy jo
signature.asc
Description: PGP signature
Bug#966692: stunnel4: FTBFS because of test hang
On Wed, Aug 05, 2020 at 09:28:12PM +0300, Peter Pentchev wrote:
> On Wed, Aug 05, 2020 at 08:01:53PM +0200, Michał Mirosław wrote:
> > On Sun, Aug 02, 2020 at 05:34:40PM +0300, Peter Pentchev wrote:
> > > On Sun, Aug 02, 2020 at 02:02:22AM +0200, Michał Mirosław wrote:
> > [...]
> > > --- a/debian/tests/runtime
> > > +++ b/debian/tests/runtime
> > > @@ -432,6 +432,7 @@ MAIN:
> > >
> > > if (!defined $line) {
> > > $eof->send($got_version);
> > > + undef $f_out;
> > > } elsif (!$got_version) {
> > > if ($line =~ m{^
> > > stunnel \s+
> >
> > I believe $f_out will not be defined here, as it only gets set after
> > sub{} is created. Perl confirms this:
> >
> > $ TEST_STUNNEL=src/stunnel strace -f -o /tmp/log debian/tests/runtime
> > Global symbol "$f_out" requires explicit package name (did you forget to
> > declare "my $f_out"?) at debian/tests/runtime line 435.
> > Execution of debian/tests/runtime aborted due to compilation errors.
>
> Of course you're right. Sorry about that! That's what I get for writing
> a patch three minutes before I have to head out and never remembering to
> actually test it later :(
>
> How about the attached one?
[...]
> --- a/debian/tests/runtime
> +++ b/debian/tests/runtime
> @@ -424,7 +424,8 @@ MAIN:
>
> my ($got_version, $before_version) = (undef, '');
> my $eof = AnyEvent->condvar;
> - my $f_out = AnyEvent->io(
> + my $f_out;
> + $f_out = AnyEvent->io(
> fh => $s_in,
> poll => 'r',
> cb => sub {
> @@ -432,6 +433,7 @@ MAIN:
>
> if (!defined $line) {
> $eof->send($got_version);
> + undef $f_out;
> } elsif (!$got_version) {
> if ($line =~ m{^
> stunnel \s+
This stops the endless readings of EOF, but:
1. the FD gets leaked (shouldn't matter much, though)
2. the test hangs anyway
Using print-debugging, I see that it stops at wait_for_child line just
after printing the version. It seems that something is reaping the child
before the main thread has a chance to wait for it.
>From strace:
4285 +++ exited with 0 +++
4284 <... epoll_ctl resumed> ) = 0
4284 --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=4285,
si_uid=1000, si_status=0, si_utime=0, si_stime=0} ---
4284 write(4, "\1\0\0\0\0\0\0\0", 8) = 8
4284 rt_sigreturn({mask=[PIPE]}) = 0
4284 epoll_wait(3, [{EPOLLHUP, {u32=5, u64=4294967301}}, {EPOLLIN, {u32=4,
u64=4294967300}}], 64, 59743) = 2
4284 epoll_ctl(3, EPOLL_CTL_MOD, 5, {EPOLLIN, {u32=5, u64=4294967301}}) = 0
4284 read(4, "\1\0\0\0\0\0\0\0", 8)= 8
4284 wait4(-1, [{WIFEXITED(s) && WEXITSTATUS(s) == 0}],
WNOHANG|WSTOPPED|WCONTINUED, NULL) = 4285
4284 wait4(-1, 0x7ffcd56d5784, WNOHANG|WSTOPPED|WCONTINUED, NULL) = -1 ECHILD
(No child processes)
4284 wait4(-1, 0x7ffcd56d5534, WNOHANG, NULL) = -1 ECHILD (No child processes)
This is before the 'wait_for_child' a few lines later.
4284 epoll_wait(3, [{EPOLLHUP, {u32=5, u64=4294967301}}], 64, 59743) = 1
4284 epoll_ctl(3, EPOLL_CTL_MOD, 5, {EPOLLIN, {u32=5, u64=4294967301}}) = 0
4284 read(5, "", 8192) = 0
4284 write(1, "Got stunnel version 5.56\n", 25) = 25
4284 write(2, "wait child 4285\n", 16) = 16
This is version printout plus my check.
4284 epoll_wait(3, [{EPOLLHUP, {u32=5, u64=4294967301}}], 64, 59743) = 1
4284 epoll_ctl(3, EPOLL_CTL_DEL, 5, 0x5631c0d44a40) = 0
This clears watcher for the pipe.
4284 epoll_wait(3, 0x5631c0d44a40, 64, 59743) = -1 EINTR (Interrupted system
call)
And this waits forever.
Best Regards
Michał Mirosław
Bug#936309: closure-linter: Python2 removal in sid/bullseye
On Fri, Aug 30, 2019 at 07:13:28AM +, Matthias Klose wrote: > Package: src:closure-linter > Version: 2.3.19-1 > Severity: normal > Tags: sid bullseye > User: debian-pyt...@lists.debian.org > Usertags: py2removal > > Python2 becomes end-of-live upstream, and Debian aims to remove > Python2 from the distribution, as discussed in > https://lists.debian.org/debian-python/2019/07/msg00080.html Hi Laszlo, the upstream homepage now states: | Closure Linter is deprecated | | As the syntax of JavaScript has continued to evolve, with ES2015 and | beyond, it has become increasingly difficult to keep Closure Linter | up to date. It is unstaffed, unmaintained, and deprecated. Most | projects at Google have migrated to the new linter. | | For teams using the Closure tools, we recommend they use the new | linter based on the Closure Compiler instead. Given that closure-compiler is already packaged, let's simply remove closure-linter? Cheers, Moritz
Bug#967957: ITP: ulcc -- Teaching children by pictures
Package: wnpp Severity: wishlist Owner: Joao Eriberto Mota Filho * Package name: ulcc Version : 1.0.1 Upstream Author : DanSoft * URL : https://bitbucket.org/admsasha/ulcc/src/master/ * License : GPL-3+ Programming Lang: C++ Description : Teaching children by pictures This program will show a picture and four clickable names. The child must click over the right option. This program is useful for elementary schools. PS: this program was developed by same upstream author of qabcs, already in Debian.
Bug#967181: mupdf: Unversioned Python removal in sid/bullseye
As already pointed out in #937093, the upstream version 1.17.0 is compatibel with python3. Please update the Debian package to that version.
Bug#718394: Hello
-- Hallo schat, hoe gaat het met je? 'Ik ben kapitein Katie uit de Verenigde Staten, kan ik alsjeblieft iets belangrijks met je bespreken?Bedankt. Hi dear, how are you doing? "I'm captain Katie from United States, please can I discuss something important with you? Thanks.
Bug#966096: geeqie: immediate segfault
On Wed, 22 Jul 2020 20:02:43 -0400 James Van Zandt wrote: > Package: geeqie > Version: 1:1.5.1-11 > Severity: important > X-Debbugs-Cc: jim.vanza...@gmail.com > > /tmp/bug > I assume this is the bug: https://github.com/BestImageViewer/geeqie/issues/559 I will probably package a git snapshot (again) if upstream don't make a new release soon, and then you will have the option --disable-clutter which should make it possible to run again. /Andreas
Bug#967955: golang-github-unknwon-cae: CVE-2020-7664
Source: golang-github-unknwon-cae Version: 0.0~git20160715.0.c6aac99-4 Severity: grave Tags: security upstream Justification: user security hole X-Debbugs-Cc: car...@debian.org, Debian Security Team Hi, The following vulnerability was published for golang-github-unknwon-cae. CVE-2020-7664[0]: | In all versions of the package github.com/unknwon/cae/zip, the | ExtractTo function doesn't securely escape file paths in zip archives | which include leading or non-leading "..". This allows an attacker to | add or replace files system-wide. If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2020-7664 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-7664 [1] https://snyk.io/vuln/SNYK-GOLANG-GITHUBCOMUNKNWONCAEZIP-570383 Regards, Salvatore
Bug#967956: golang-github-unknwon-cae: CVE-2020-7668
Source: golang-github-unknwon-cae Version: 0.0~git20160715.0.c6aac99-4 Severity: grave Tags: security upstream Justification: user security hole X-Debbugs-Cc: car...@debian.org, Debian Security Team Hi, The following vulnerability was published for golang-github-unknwon-cae. CVE-2020-7668[0]: | In all versions of the package github.com/unknwon/cae/tz, the | ExtractTo function doesn't securely escape file paths in zip archives | which include leading or non-leading "..". This allows an attacker to | add or replace files system-wide. If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2020-7668 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-7668 Regards, Salvatore
Bug#886221: libnetsnmptrapd.so: undefined symbols: needs -lmysql
Control: reopen -1 Control: found -1 5.8+dfsg-5 I'm reopening this bug because it is still valid. I can reproduce it locally when I install libsnmp35 in a schroot and then run: $ ldd -r /usr/lib/x86_64-linux-gnu/libnetsnmptrapd.so.35.0.0 linux-vdso.so.1 (0x7ffdb51b8000) libnetsnmpmibs.so.35 => /lib/x86_64-linux-gnu/libnetsnmpmibs.so.35 (0x7fe28cd99000) libnetsnmp.so.35 => /lib/x86_64-linux-gnu/libnetsnmp.so.35 (0x7fe28cbf5000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7fe28ca3) libnetsnmpagent.so.35 => /lib/x86_64-linux-gnu/libnetsnmpagent.so.35 (0x7fe28c9b9000) libsensors.so.5 => /lib/x86_64-linux-gnu/libsensors.so.5 (0x7fe28c9a8000) libpci.so.3 => /lib/x86_64-linux-gnu/libpci.so.3 (0x7fe28c997000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7fe28c98f000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x7fe28c96d000) libssl.so.1.1 => /lib/x86_64-linux-gnu/libssl.so.1.1 (0x7fe28c8db000) libcrypto.so.1.1 => /lib/x86_64-linux-gnu/libcrypto.so.1.1 (0x7fe28c5ef000) /lib64/ld-linux-x86-64.so.2 (0x7fe28d042000) libwrap.so.0 => /lib/x86_64-linux-gnu/libwrap.so.0 (0x7fe28c5e3000) libperl.so.5.30 => /lib/x86_64-linux-gnu/libperl.so.5.30 (0x7fe28c284000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7fe28c13e000) libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7fe28c121000) libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x7fe28c107000) libudev.so.1 => /lib/x86_64-linux-gnu/libudev.so.1 (0x7fe28c0e) libnsl.so.1 => /lib/x86_64-linux-gnu/libnsl.so.1 (0x7fe28c0c6000) libcrypt.so.1 => /lib/x86_64-linux-gnu/libcrypt.so.1 (0x7fe28c08b000) undefined symbol: mysql_sqlstate (/usr/lib/x86_64-linux-gnu/libnetsnmptrapd.so.35.0.0) undefined symbol: mysql_stmt_errno (/usr/lib/x86_64-linux-gnu/libnetsnmptrapd.so.35.0.0) undefined symbol: mysql_commit (/usr/lib/x86_64-linux-gnu/libnetsnmptrapd.so.35.0.0) undefined symbol: mysql_options (/usr/lib/x86_64-linux-gnu/libnetsnmptrapd.so.35.0.0) undefined symbol: mysql_stmt_init (/usr/lib/x86_64-linux-gnu/libnetsnmptrapd.so.35.0.0) undefined symbol: mysql_stmt_prepare (/usr/lib/x86_64-linux-gnu/libnetsnmptrapd.so.35.0.0) undefined symbol: mysql_errno (/usr/lib/x86_64-linux-gnu/libnetsnmptrapd.so.35.0.0) undefined symbol: mysql_stmt_close (/usr/lib/x86_64-linux-gnu/libnetsnmptrapd.so.35.0.0) undefined symbol: mysql_server_end (/usr/lib/x86_64-linux-gnu/libnetsnmptrapd.so.35.0.0) undefined symbol: mysql_real_connect (/usr/lib/x86_64-linux-gnu/libnetsnmptrapd.so.35.0.0) undefined symbol: mysql_close (/usr/lib/x86_64-linux-gnu/libnetsnmptrapd.so.35.0.0) undefined symbol: mysql_stmt_error (/usr/lib/x86_64-linux-gnu/libnetsnmptrapd.so.35.0.0) undefined symbol: mysql_init (/usr/lib/x86_64-linux-gnu/libnetsnmptrapd.so.35.0.0) undefined symbol: mysql_insert_id (/usr/lib/x86_64-linux-gnu/libnetsnmptrapd.so.35.0.0) undefined symbol: mysql_error (/usr/lib/x86_64-linux-gnu/libnetsnmptrapd.so.35.0.0) undefined symbol: mysql_stmt_execute (/usr/lib/x86_64-linux-gnu/libnetsnmptrapd.so.35.0.0) undefined symbol: mysql_stmt_bind_param (/usr/lib/x86_64-linux-gnu/libnetsnmptrapd.so.35.0.0) undefined symbol: mysql_autocommit (/usr/lib/x86_64-linux-gnu/libnetsnmptrapd.so.35.0.0) undefined symbol: mysql_stmt_sqlstate (/usr/lib/x86_64-linux-gnu/libnetsnmptrapd.so.35.0.0) The Ubuntu net-snmp package has a patch to fix this problem; I'll submit it shortly as a MR via salsa. Thanks, -- Sergio GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36 Please send encrypted e-mail if possible https://sergiodj.net/ signature.asc Description: PGP signature
Bug#967857: debian-policy: [Files/Permissions and owners] files installed by package manager should not be writable
I'm ignoring the case where capabilities are dropped in my analysis. I've long valued that Debian does not mark file paths as readonly and would not support this change. I've worked on other Unix distributions that did this, and I found that it decreased the quality of life of the sysadmin enough that I just enjoyed being on Debian better and that this decision was one that contributed. Yes, root can write to anything. But several tools make it harder to write to things as root if they are without write permission. I think the value of stability and making it easy for the sysadmins is more important than this change absent cases where capabilities are dropped. I haven't thought about the capability dropped case enough. If that ends up being our rationale, I could hold my nose and go off in my own corner and grow a beard and grumble in my old age, talking about how great things used to be back in the day. In other cases I'm strongly opposed to this change. --Sam signature.asc Description: PGP signature
Bug#936873: libhdate: diff for NMU version 1.6.02-2.1
Thanks Moritz for stepping forward and adopting this. I still haven't heard back from any member of the 'Debian Hebrew Maintainers' team, but will continue in the future to attempt to use them as a first point of contact until/unless I hear that they have been disolved / superseded / replaced. Any word on why the silence from them? On 2020-08-05 19:57, Moritz Mühlenhoff wrote: > The debdiff for my NMU for libhdate (versioned as 1.6.02-2.1) > > Cheers, > Moritz -- hkp://keys.gnupg.net CA45 09B5 5351 7C11 A9D1 7286 0036 9E45 1595 8BC0
Bug#967954: debcargo: generated ranged build-deps result in "BD-uninstallable" on debian buildd network
Package: debcargo Version: 2.4.2-1 Severity: normal Control: affects -1 + rust-buffered-reader Looking at buffered-reader version 0.18.0, upstream lists dependencies in Cargo.toml including: [dependencies.flate2] version = ">= 1.0.1, < 1.0.16" optional = true debcargo 2.4.2 converts this to a b-d list: Build-Depends: […] librust-flate2-1.0.15+default-dev | librust-flate2-1.0.14+default-dev | librust-flate2-1.0.13+default-dev | librust-flate2-1.0.12+default-dev | librust-flate2-1.0.11+default-dev | librust-flate2-1.0.10+default-dev | librust-flate2-1.0.9+default-dev | librust-flate2-1.0.8+default-dev | librust-flate2-1.0.7+default-dev | librust-flate2-1.0.6+default-dev | librust-flate2-1.0.5+default-dev | librust-flate2-1.0.4+default-dev | librust-flate2-1.0.3+default-dev | librust-flate2-1.0.2+default-dev | librust-flate2-1.0.1+default-dev , […] But https://buildd.debian.org/status/package.php?p=rust-buffered-reader says "BD-uninstallable" for all platforms, for example: rust-buffered-reader build-depends on missing: - librust-flate2-1.0.15+default-dev:amd64 note that librust-flate2+rust-backend-dev version 1.0.13-2 is in unstable, and it has: Provides: […] librust-flate2-1.0.13+default-dev (= 1.0.13-2) Clearly, the solver is ignoring all but the first build-depends in an "or"ed dependency. debcargo probably needs to figure out a way around this :/ (or, maybe something about the resolver for the build daemon network needs to be fixed to try subsequent entries in an "or"ed dependency? if so, feel free to reassign this ticket) I can work around this in rust-buffered-reader by dropping that particular constraint (it is only added upstream to keep the MSRV low, which doesn't matter for debian). --dkg -- System Information: Debian Release: bullseye/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'testing'), (200, 'unstable-debug'), (200, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.7.0-2-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages debcargo depends on: ii libc62.31-2 ii libcurl3-gnutls 7.68.0-1+b1 ii libgcc-s1 [libgcc1] 10.1.0-6 ii libgit2-28 0.28.5+dfsg.1-1 ii libssh2-11.8.0-2.1 ii libssl1.11.1.1g-1 ii quilt0.66-2.1 ii zlib1g 1:1.2.11.dfsg-2 Versions of packages debcargo recommends: ii dh-cargo 24 debcargo suggests no packages. -- no debconf information signature.asc Description: PGP signature
Bug#957019: atlc: diff for NMU version 4.6.1-2.1
Sudip Mukherjee writes: > Control: tags 957019 + patch > Control: tags 957019 + pending > > Dear maintainer, > > I've prepared an NMU for atlc (versioned as 4.6.1-2.1) and > uploaded it to DELAYED/5. Please feel free to tell me if I > should cancel it. Thank you! Bdale signature.asc Description: PGP signature
Bug#880437: libglade2: diff for NMU version 1:2.6.4-2.1
On Wed, 5 Aug 2020 12:32:44 +0200, Matthias Klose wrote: > On 8/4/20 10:08 PM, Simon McVittie wrote: > > On Tue, 04 Aug 2020 at 20:56:46 +0200, Stephen Kitt wrote: > >> On Tue, 4 Aug 2020 20:24:40 +0200, Stephen Kitt > >> wrote: > >>> I've prepared an NMU for libglade2 (versioned as 1:2.6.4-2.1) and > >>> uploaded it to the archive. It fixes #967157, #936867, and #880437. > >> > >> Except not, because I forgot to update my key in the keyring and it’s > >> expired. Ho hum... > > > > It would have collided with Matthias Klose's NMU anyway, except that > > doesn't seem to have made it into the archive either for some reason > > (possibly *because* they collided). > > a .2 upload was accepted. maybe .1 was silently rejected because it sits in > the delayed queue ... > > > Dropping libglade-convert (which is even more obsolete than the rest of > > the package, and that's really saying something) seems like a better > > solution than using python2. > > Could you follow-up with that, once the current package is in testing? Yes, I’ll take care of it (along with the maintainer fix-ups). Regards, Stephen pgpM0jnwYCuxN.pgp Description: OpenPGP digital signature
Bug#966692: stunnel4: FTBFS because of test hang
On Wed, Aug 05, 2020 at 08:01:53PM +0200, Michał Mirosław wrote:
> On Sun, Aug 02, 2020 at 05:34:40PM +0300, Peter Pentchev wrote:
> > On Sun, Aug 02, 2020 at 02:02:22AM +0200, Michał Mirosław wrote:
> [...]
> > --- a/debian/tests/runtime
> > +++ b/debian/tests/runtime
> > @@ -432,6 +432,7 @@ MAIN:
> >
> > if (!defined $line) {
> > $eof->send($got_version);
> > + undef $f_out;
> > } elsif (!$got_version) {
> > if ($line =~ m{^
> > stunnel \s+
>
> I believe $f_out will not be defined here, as it only gets set after
> sub{} is created. Perl confirms this:
>
> $ TEST_STUNNEL=src/stunnel strace -f -o /tmp/log debian/tests/runtime
> Global symbol "$f_out" requires explicit package name (did you forget to
> declare "my $f_out"?) at debian/tests/runtime line 435.
> Execution of debian/tests/runtime aborted due to compilation errors.
Of course you're right. Sorry about that! That's what I get for writing
a patch three minutes before I have to head out and never remembering to
actually test it later :(
How about the attached one?
G'luck,
Peter
--
Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13
commit eb303ad2e9c925bf7243e6877d8598d0356d68f9
Author: Peter Pentchev
Date: Sun Aug 2 17:31:26 2020 +0300
Destroy the stunnel version watcher on EOF.
diff --git a/debian/tests/runtime b/debian/tests/runtime
index ecffe7b..f594d9a 100755
--- a/debian/tests/runtime
+++ b/debian/tests/runtime
@@ -424,7 +424,8 @@ MAIN:
my ($got_version, $before_version) = (undef, '');
my $eof = AnyEvent->condvar;
- my $f_out = AnyEvent->io(
+ my $f_out;
+ $f_out = AnyEvent->io(
fh => $s_in,
poll => 'r',
cb => sub {
@@ -432,6 +433,7 @@ MAIN:
if (!defined $line) {
$eof->send($got_version);
+ undef $f_out;
} elsif (!$got_version) {
if ($line =~ m{^
stunnel \s+
signature.asc
Description: PGP signature
Bug#957360: insighttoolkit4: ftbfs with GCC-10
Greetings, Étienne Mollier, on 2020-08-04 20:31:23 +0200: > On Mon, 3 Aug 2020 08:45:35 +0200 Étienne Mollier > wrote: > > * an update to ITK 4.13.3. > > I am now working on this part. Hopefuly this will help getting > through the build process further. I updated the package to version 4.13.3, and so, last night build went through; actually it ended around 11:00 AM today. I'm seeing several test failures in the build log, with a message like: ERROR: ld.so: object 'libfakeroot-sysv.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored. ERROR: ld.so: object 'libfakeroot-sysv.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored. Loading ITKPyBase... Traceback (most recent call last): File "", line 1, in File "/home/emollier/debian/med-team/insighttoolkit/BUILD/Wrapping/Generators/Python/itkLazy.py", line 44, in __getattribute__ itkBase.LoadModule(module, namespace) File "/home/emollier/debian/med-team/insighttoolkit/BUILD/Wrapping/Generators/Python/itkBase.py", line 118, in LoadModule LoadModule(dep, namespace) File "/home/emollier/debian/med-team/insighttoolkit/BUILD/Wrapping/Generators/Python/itkBase.py", line 118, in LoadModule LoadModule(dep, namespace) File "/home/emollier/debian/med-team/insighttoolkit/BUILD/Wrapping/Generators/Python/itkBase.py", line 128, in LoadModule module = loader.load(swigModuleName) File "/home/emollier/debian/med-team/insighttoolkit/BUILD/Wrapping/Generators/Python/itkBase.py", line 250, in load return imp.load_module(name, fp, pathname, description) File "/home/emollier/debian/med-team/insighttoolkit/BUILD/lib/ITKPyBasePython.py", line 15, in import _ITKPyBasePython ImportError: /home/emollier/debian/med-team/insighttoolkit/BUILD/lib/_ITKPyBasePython.so: undefined symbol: PyUnicode_FromFormat However, I am suspecting an ill placed `fakeroot` in my building command. That may just be my bad hopefully. I will redo a run in a clean chroot. Kind Regards, -- Étienne Mollier Old rsa/3072: 5ab1 4edf 63bb ccff 8b54 2fa9 59da 56fe fff3 882d New rsa/4096: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da Sent from /dev/pts/1, please excuse my verbosity. signature.asc Description: PGP signature
Bug#966692: stunnel4: FTBFS because of test hang
On Sun, Aug 02, 2020 at 05:34:40PM +0300, Peter Pentchev wrote:
> On Sun, Aug 02, 2020 at 02:02:22AM +0200, Michał Mirosław wrote:
[...]
> --- a/debian/tests/runtime
> +++ b/debian/tests/runtime
> @@ -432,6 +432,7 @@ MAIN:
>
> if (!defined $line) {
> $eof->send($got_version);
> + undef $f_out;
> } elsif (!$got_version) {
> if ($line =~ m{^
> stunnel \s+
I believe $f_out will not be defined here, as it only gets set after
sub{} is created. Perl confirms this:
$ TEST_STUNNEL=src/stunnel strace -f -o /tmp/log debian/tests/runtime
Global symbol "$f_out" requires explicit package name (did you forget to
declare "my $f_out"?) at debian/tests/runtime line 435.
Execution of debian/tests/runtime aborted due to compilation errors.
$ dpkg -l perl
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture Description
+++-==---=
ii perl 5.28.1-6 amd64Larry Wall's Practical Extraction
and Report Language
Best Regards
Michał Mirosław
Bug#936873: libhdate: diff for NMU version 1.6.02-2.1
The debdiff for my NMU for libhdate (versioned as 1.6.02-2.1)
Cheers,
Moritz
diff -Nru libhdate-1.6.02/debian/changelog libhdate-1.6.02/debian/changelog
--- libhdate-1.6.02/debian/changelog 2018-07-30 05:49:11.0 +0200
+++ libhdate-1.6.02/debian/changelog 2020-08-02 23:13:33.0 +0200
@@ -1,3 +1,11 @@
+libhdate (1.6.02-2.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Drop python-hdate, there are no remaining rdeps remaining
+(Closes: #936873)
+
+ -- Moritz Muehlenhoff Sun, 02 Aug 2020 23:13:33 +0200
+
libhdate (1.6.02-2) unstable; urgency=medium
* Update maintainer address (Closes: #899576)
diff -Nru libhdate-1.6.02/debian/control libhdate-1.6.02/debian/control
--- libhdate-1.6.02/debian/control 2018-07-30 05:41:00.0 +0200
+++ libhdate-1.6.02/debian/control 2020-08-02 23:11:28.0 +0200
@@ -7,8 +7,6 @@
Vcs-Git: https://salsa.debian.org/hebrew-team/libhdate.git
Build-Depends: debhelper (>= 9),
swig,
- python-dev (>= 2.6.6-3~),
- dh-python,
dh-autoreconf,
Standards-Version: 3.9.8
Homepage: http://libhdate.sourceforge.net/
@@ -26,20 +24,6 @@
This package contains headers and support files required
to build new applications with libhdate.
-Package: python-hdate
-Section: python
-Architecture: any
-Provides: ${python:Provides}
-Depends: libhdate1 (= ${binary:Version}), ${python:Depends}, ${shlibs:Depends}, ${misc:Depends}
-Description: Provides a library that help use Hebrew dates (Python bindings)
- LibHdate is a small C,C++ library for Hebrew dates,
- holidays, and reading sequence (parasha). It is using
- the source code from Amos Shapir's "hdate" package fixed and
- patched by Nadav Har'El. The Torah reading sequence
- is from tables by Zvi Har'El.
- .
- This package contains Python bindings to libhdate
-
Package: libhdate-perl
Section: perl
Architecture: any
diff -Nru libhdate-1.6.02/debian/python-hdate.install libhdate-1.6.02/debian/python-hdate.install
--- libhdate-1.6.02/debian/python-hdate.install 2018-07-30 05:28:32.0 +0200
+++ libhdate-1.6.02/debian/python-hdate.install 1970-01-01 01:00:00.0 +0100
@@ -1 +0,0 @@
-usr/lib/python*/*
diff -Nru libhdate-1.6.02/debian/rules libhdate-1.6.02/debian/rules
--- libhdate-1.6.02/debian/rules 2018-07-30 05:28:32.0 +0200
+++ libhdate-1.6.02/debian/rules 2020-08-02 23:11:45.0 +0200
@@ -3,10 +3,7 @@
ARCHLIB := $(shell perl -MConfig -e 'print $$Config{vendorarch}')
%:
- dh $* --with python2,autoreconf
+ dh $* --with autoreconf
override_dh_auto_configure:
dh_auto_configure -- --with-perl-sitelib-dir=$(ARCHLIB)
-
-override_dh_python2:
- dh_python2 -s --no-guessing-versions
Bug#967953: Package not installable in sid due to missing dependencies python-argcomplete and python-ipaddr
Package: ifupdown2 Version: 1.2.7-1 Severity: grave The package ifupdown2 currently cannot be installed on systems running sid as the two of its dependencies, python-argcomplete and python-ipaddr, are no longer present in sid. The suggested packages python-gvgen and python-mako also no longer exist.
Bug#967952: tootle: could depend on libhandy
Package: tootle Version: 0.2.0-2 Severity: wishlist Dear Federico, Since recently, libhandy-1 is available in unstable. tootle upstream marked libhandy as an optional dependency. I am not sure how its absence is handled but it seems to be using a git submodule. Could you, instead, build depend on libhandy-1-dev? Best regards, Henry-Nicolas Tourneur
Bug#967951: OpenBLAS ILP64 with symbol suffixes
Package: libopenblas64-0 Version: 0.3.10+ds-3 As per https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=878121 libopenblas64-0 has been made available containing the ILP64 build of OpenBLAS. Debian uses the same symbol names in libopenblas64-0 and libopenblas0, which leads to conflicts if users load multiple libraries into the same process that expect 32bit and 64bit interfaces respectively as the dynamic loader will only resolve the symbols once. For example, python3-numpy may depend on the 32bit libraries, but users can compile a package against libopenblas64-0 and load both into the same Python process. I believe that for this reason Debian's Julia package bundles OpenBlas "compiled with SONAME=libopenblas64_.so, INTERFACE64=1 and all symbols suffixed by "64_" as of 1.2.0+dfsg-1. See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=905826 Why not provide libopenblas64_-0 packages with symbol name suffixes? This should allow Julia package to stop bundling OpenBlas as well as ease the life of users that want to compile against OpenBLAS ILP64 interface on Debian systems while avoiding symbol name conflicts. This seems to be the approach taken by Fedora: https://src.fedoraproject.org/rpms/openblas/blob/HEAD/f/openblas.spec Thank you Leonard
Bug#957710: ftbfs with GCC-10
Hi,
I've written a patch.
After that, I've seen Reiner Herrmann already posted a working solution.
It's mostly the same fix but slightly different.
Please consider my version as an alternative. IMAO mine is preferable ;)
Regards,
--
Antoni Villalonga
https://friki.cat/
Description: Fix ftbfs with GCC-10
Forwarded: no
Author: Antoni Villalonga
Last-Update: 2020-08-05
--- a/proxychains/core.h
+++ b/proxychains/core.h
@@ -68,27 +68,27 @@
typedef int (*connect_t)(int, const struct sockaddr *, socklen_t);
-connect_t true_connect;
+extern connect_t true_connect;
typedef struct hostent* (*gethostbyname_t)(const char *);
-gethostbyname_t true_gethostbyname;
+extern gethostbyname_t true_gethostbyname;
typedef int (*getaddrinfo_t)(const char *, const char *,
const struct addrinfo *,
struct addrinfo **);
-getaddrinfo_t true_getaddrinfo;
+extern getaddrinfo_t true_getaddrinfo;
typedef int (*freeaddrinfo_t)(struct addrinfo *);
-freeaddrinfo_t true_freeaddrinfo;
+extern freeaddrinfo_t true_freeaddrinfo;
typedef int (*getnameinfo_t) (const struct sockaddr *,
socklen_t, char *,
socklen_t, char *,
socklen_t, unsigned int);
-getnameinfo_t true_getnameinfo;
+extern getnameinfo_t true_getnameinfo;
typedef struct hostent *(*gethostbyaddr_t) (const void *, socklen_t, int);
-gethostbyaddr_t true_gethostbyaddr;
+extern gethostbyaddr_t true_gethostbyaddr;
int proxy_getaddrinfo(const char *node, const char *service,
const struct addrinfo *hints,
--- a/proxychains/libproxychains.c
+++ b/proxychains/libproxychains.c
@@ -81,6 +81,12 @@
unsigned int *proxy_count,
chain_type *ct,
my_network *subnets);
+connect_t true_connect;
+gethostbyname_t true_gethostbyname;
+getaddrinfo_t true_getaddrinfo;
+freeaddrinfo_t true_freeaddrinfo;
+getnameinfo_t true_getnameinfo;
+gethostbyaddr_t true_gethostbyaddr;
static void init_lib()
{
Bug#964905: upstream packaging
Control: forward -1 https://github.com/zgoat/goatcounter/issues/368 upstream is also working on a package -- Life is like riding a bicycle. To keep your balance you must keep moving. - Albert Einstein
Bug#967938: libc6: systemd-sysusers SEGV due to glibc bug in fgetgsent
* Jinpu Wang: > Dear Maintainer: > > Sorry, add some missing information below: > > After update to Buster, the systemd-sysusers are segfaulting every time. > After search around, I found following bugreport in glibc > https://sourceware.org/legacy-ml/libc-alpha/2016-06/msg01015.html > > I backported to the fix to 2.28-10, it fixed the problem. > > glibc upstream have a different fix for it in 2.32, see > https://sourceware.org/bugzilla/show_bug.cgi?id=20338 > > I think it's still easier to backport the fix in msg01015.html to 2.28 > version, > patch attached in the initial report. The patch from 2016 is incomplete because it does not seek back to the original file position, so the next call of fgetsgent_r skips over the entry that could not be fully parsed.
Bug#967950: doxygen: Autopkgtest regression with json-c 0.15
Source: doxygen Version: 1.8.18-1 Severity: serious Justification: failing autopkgtest on amd64 Dear Maintainer, doxygen autopkgtest started failing after json-c 0.15-1 was uploaded to unstable. This blocks migration of some other packages: https://ci.debian.net/user/britney/jobs?package=doxygen See any of the “test log” links for the log, for example this one: https://ci.debian.net/data/autopkgtest/testing/amd64/d/doxygen/6526799/log.gz The relevant line is: error: Doxyfile not found and no input file specified! Attached is a patch that adapts the test to work with new json-c. However, I think it would be better if that test did not rely on any external data, and the needed data was shipped with doxygen itself. Maybe the test can build doxygen's own documentation? -- Dmitry Shachnev diff --git a/debian/tests/control b/debian/tests/control index f46086a..d707d73 100644 --- a/debian/tests/control +++ b/debian/tests/control @@ -1,2 +1,7 @@ Tests: run -Depends: apt:native, dpkg-dev, doxygen, graphviz:native +Depends: apt:native, + build-essential, + cmake:native, + doxygen, + dpkg-dev, + graphviz:native diff --git a/debian/tests/run b/debian/tests/run index 31e4da5..f84a376 100755 --- a/debian/tests/run +++ b/debian/tests/run @@ -7,6 +7,10 @@ trap "rm -rf $WORKDIR" 0 INT QUIT ABRT PIPE TERM cd $WORKDIR apt-get source json-c 2>&1 cd json-c-* +mkdir build +cd build +cmake .. +cd doc doxygen 2>&1 cd / rm -Rf "$WORKDIR" signature.asc Description: PGP signature
Bug#966557: Blacklist nvidia-modeset and nvidia-drm
On 2020-08-05 09:56, Andreas Beckmann wrote: On 8/5/20 5:30 PM, Joel Johnson wrote: Thanks, I'll comment out the additional blacklist entries and test with that package installed. Those lines aren't harmful in any other way that I see, but just unexpected from your original response? Correct. The additional blacklist entries should be completely harmless, I was just curious to investigate why you needed them because in the "expected" bumblebee-nvidia setup they should not be needed at all. I just learned that we allow some "unusual" bumblebee-nvidia setups (like yours) that were probably not intended (and will likely be disabled in a future upload). In initial testing I installed the additional nvidia metapackage, commented out the additional lines in my /etc/modprobe.d/bumblebee.conf, regenerated initramfs, and rebooted. That does seem to have worked as neither the modeset or drm drivers appear to be loaded automatically. Updating of the dependencies and/or addition of the additional module blacklists as an additional safety check works for me, thanks! Joel
Bug#967655: nitrokey-app: depends on deprecated GTK 2
> This does not seem right, as Nitrokey App uses Qt5. Perhaps some invalid > package dependency in the Debian metafile? libgtk2.0-dev is in the Build-Depends: Build-Depends: bash-completion, cmake (>= 3.1.0), debhelper (>= 12~), *libgtk2.0-dev*, libnotify-dev, libusb-1.0-0-dev, udev, qt5-qmake, qtbase5- dev, qttools5-dev, libqt5svg5-dev, qtchooser, libhidapi-dev, libnitrokey-dev (>= 3.5) signature.asc Description: This is a digitally signed message part.
Bug#966557: Blacklist nvidia-modeset and nvidia-drm
On 8/5/20 5:30 PM, Joel Johnson wrote: > Thanks, I'll comment out the additional blacklist entries and test with > that package installed. Those lines aren't harmful in any other way that > I see, but just unexpected from your original response? Correct. The additional blacklist entries should be completely harmless, I was just curious to investigate why you needed them because in the "expected" bumblebee-nvidia setup they should not be needed at all. I just learned that we allow some "unusual" bumblebee-nvidia setups (like yours) that were probably not intended (and will likely be disabled in a future upload). Andrea
Bug#966557: Blacklist nvidia-modeset and nvidia-drm
On 2020-08-04 15:47, Andreas Beckmann wrote: On 8/4/20 1:49 AM, Felix Dörre wrote: I've got a slight clue, what could be wrong here: The posted update-glx --display glx shows the following line: [...] but none libGLX_nvidia.so.0. From the maintainer-script however having [...] I hope this helps to understand what's wrong in this case. Good point! Does anyone remember why bumblebee-nvidia depends on nvidia-driver* | nvidia*-kernel-dkms (complete Depends: bumblebee (= 3.2.1-25), glx-alternative-nvidia (>= 0.6.92), nvidia-driver | nvidia-tesla-450-driver | nvidia-tesla-440-driver | nvidia-tesla-418-driver | nvidia-legacy-390xx-driver | nvidia-legacy-340xx-driver | nvidia-driver-any | nvidia-kernel-dkms | nvidia-tesla-450-kernel-dkms | nvidia-tesla-440-kernel-dkms | nvidia-tesla-418-kernel-dkms | nvidia-legacy-390xx-kernel-dkms | nvidia-legacy-340xx-kernel-dkms) That allows for a broken bumblebee-nvidia installation nvidia-kernel-dkms + bumblebee-nvidia but we need at least the following additional driver components: * xserver-xorg-video-nvidia * nvidia-driver-libs Joel, if you install the nvidia-driver metapackage, everything should be fine for you. Thanks, I'll comment out the additional blacklist entries and test with that package installed. Those lines aren't harmful in any other way that I see, but just unexpected from your original response? Joel
Bug#965098: please remove geda-gaf from the archive
Moritz Mühlenhoff writes: > On Thu, Jul 16, 2020 at 08:47:39AM -0700, Sean Whitton wrote: >> > There are two reverse dependencies on geda-gaf, gspiceui, and >> > contrib/easyspice. Both appear to be maintained by Gudjon >> > I. Gudjonsson, who I will CC. >> >> Please remove the moreinfo tag from this bug once these packages have >> been removed or updated such that there are no more rdeps. > > I've filed #967915 and g#967916 against gspiceui and easyspice. Thank you. Bdale signature.asc Description: PGP signature
Bug#967949: ITP: ipqalc -- graphical utility for IPv4 subnet calculation
Package: wnpp Severity: wishlist Owner: Fabio Augusto De Muzio Tobich X-Debbugs-Cc: debian-de...@lists.debian.org, ftob...@gmail.com * Package name: ipqalc Version : 1.5.3 Upstream Author : Alexander Danilov * URL : https://bitbucket.org/admsasha/ipqalc * License : GPL-3+ Programming Lang: C++ Description : graphical utility for IPv4 subnet calculation Small utility for IP address calculations including broadcast and network addresses as well as Cisco wildcard mask. >From a given IPv4 address calculates broadcast, network, Cisco wildcard mask, and host range. It can also be used as a teaching tool and presents the results in binary, and hex, values.
Bug#953033: bug#39901: Emacs needs to update window-width when the user updates the text size
Eli Zaretskii writes: > I do: there's no bug here -- window-width is documented to return a > value in terms of the frame's canonical character width (i.e. it uses > the dimensions of the frame's default font). And that doesn't change > when you change the font only for a single buffer. > > However, window-width can be asked to return the value in pixels, if > someone wants that, and then one can compute the width in units of any > other, larger or smaller, font. > > IOW, if some applications produce unexpected or unpleasant effects > when the buffer text is resized, those applications need to be > sensitive to such resizing. But changing the semantics of a veteran > API like suggested here is a non-starter, as it would definitely break > gobs of existing code. Yeah, that's true. I had completely forgotten that C-x C-+ only affects the current buffer, so resizing the window on that command would be nonsensical. So I'm closing this bug report. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no
Bug#957995: xscorch: diff for NMU version 0.2.1-1+nmu4
Control: tags 957995 + pending
Dear maintainer,
I've prepared an NMU for xscorch (versioned as 0.2.1-1+nmu3) and
uploaded it to mentors to be sponsored. Please feel free to tell me
if I should remove it. A debdiff showing all changes is attatched.
Regards,
--
Luis Paulo (lpfll)
diff -Nru xscorch-0.2.1/debian/changelog xscorch-0.2.1/debian/changelog
--- xscorch-0.2.1/debian/changelog 2020-07-02 09:57:17.0 -0300
+++ xscorch-0.2.1/debian/changelog 2020-08-05 01:00:19.0 -0300
@@ -1,3 +1,11 @@
+xscorch (0.2.1-1+nmu4) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * debian/patches/gcc10.patch: fix a FTBFS witch gcc 10. Thanks to
+Reiner Herrmann . (Closes: #957995)
+
+ -- Luis Paulo Linares Wed, 05 Aug 2020 01:00:19 -0300
+
xscorch (0.2.1-1+nmu3) unstable; urgency=medium
* Non-maintainer upload.
diff -Nru xscorch-0.2.1/debian/patches/gcc10.patch xscorch-0.2.1/debian/patches/gcc10.patch
--- xscorch-0.2.1/debian/patches/gcc10.patch1969-12-31 21:00:00.0 -0300
+++ xscorch-0.2.1/debian/patches/gcc10.patch2020-08-05 01:00:19.0 -0300
@@ -0,0 +1,29 @@
+Description: Fix FTBFS with GCC 10
+Author: Reiner Herrmann
+Bug-Debian: https://bugs.debian.org/957995
+Last-Update: 2020-08-05
+Index: xscorch-0.2.1/sgame/slscape.c
+===
+--- xscorch-0.2.1.orig/sgame/slscape.c
xscorch-0.2.1/sgame/slscape.c
+@@ -56,6 +56,7 @@ static double _sc_lscape_eval_plains(dou
+ static double _sc_lscape_eval_traditional(double x);
+ static double _sc_lscape_eval_valley(double x);
+
++double (*_sc_lscape_eval)(double x);
+
+
+ static double _sc_lscape_eval_none(__libj_unused double x) {
+Index: xscorch-0.2.1/sgame/slscape.h
+===
+--- xscorch-0.2.1.orig/sgame/slscape.h
xscorch-0.2.1/sgame/slscape.h
+@@ -64,7 +64,7 @@ void sc_lscape_setup(const struct _sc_co
+
+ /* Interface to the profile evaluating function */
+ #define sc_lscape_eval(x) ((*_sc_lscape_eval)(x))
+-double (*_sc_lscape_eval)(double x);
++extern double (*_sc_lscape_eval)(double x);
+
+
+ #endif /* __slscape_h_included */
diff -Nru xscorch-0.2.1/debian/patches/series xscorch-0.2.1/debian/patches/series
--- xscorch-0.2.1/debian/patches/series 2018-03-31 11:36:36.0 -0300
+++ xscorch-0.2.1/debian/patches/series 2020-08-05 01:00:19.0 -0300
@@ -1,2 +1,3 @@
overlapping-memcpy
gdk-include
+gcc10.patch
Bug#967945: systemd is way too aggressive in deleting journals of yesterday
* Harald Dunkel [200805 14:44]: > # ls -al /var/log/journal > total 56 > drwxr-sr-x+ 3 root systemd-journal 4096 Jan 13 2016 . > drwxr-xr-x 20 root root12288 Aug 4 00:00 .. > drwxr-sr-x+ 2 root systemd-journal 36864 Aug 4 08:38 > 42b7d4373eff9fb16ebd59084afbff3f [..] > According to the specs this should give me 4 GByte journal. More important: how large is your journal directory now? Chris
Bug#953033: bug#39901: Emacs needs to update window-width when the user updates the text size
> From: Lars Ingebrigtsen > Date: Wed, 05 Aug 2020 14:04:59 +0200 > Cc: 953...@bugs.debian.org, Katsumi Yamaoka , > 39...@debbugs.gnu.org > > 積丹尼 Dan Jacobson writes: > > > Emacs needs to update window-width when the user updates the text size. > > I think that makes sense. > > Anybody got an opinion here? I do: there's no bug here -- window-width is documented to return a value in terms of the frame's canonical character width (i.e. it uses the dimensions of the frame's default font). And that doesn't change when you change the font only for a single buffer. However, window-width can be asked to return the value in pixels, if someone wants that, and then one can compute the width in units of any other, larger or smaller, font. IOW, if some applications produce unexpected or unpleasant effects when the buffer text is resized, those applications need to be sensitive to such resizing. But changing the semantics of a veteran API like suggested here is a non-starter, as it would definitely break gobs of existing code.
Bug#966876: Bug fixed, but new version needs work on autopkgtest (Was: Bug#966876: trinityrnaseq: FTBFS: sift_bam_max_cov.cpp:99:10: error: ‘string’ is not a member of ‘std’)
Control: tags -1 pending On Mon, Aug 03, 2020 at 10:07:38AM +0200, Lucas Nussbaum wrote: > Relevant part (hopefully): > > g++ -g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong > > -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 > > -Wl,-z,relro -Wl,-z,now sift_bam_max_cov.cpp -Wall -lhts -O2 -o bamsifter > > sift_bam_max_cov.cpp: In function ‘int main(int, char**)’: > > sift_bam_max_cov.cpp:99:10: error: ‘string’ is not a member of ‘std’ > >99 | std::string tmp_text(input_header->text, input_header->l_text); > > | ^~ > > sift_bam_max_cov.cpp:16:1: note: ‘std::string’ is defined in header > > ‘’; did you forget to ‘#include ’? > >15 | #include "htslib/bgzf.h" > > +++ |+#include I've fixed this bug (and I think new upstream has found another way by using '-std=c++11' option (which would be hopefully unneeded by my patch but I did not tested). Unfortunately the autopkgtest is broken by the new version which I imported as well. Not sure whether seqtk-trinity is missing and thus autopkgtest fails is the only problem. seqtk-trinity was provided as *binary* which needed to be removed in Files-Excluded. I have not checked how / whether it is build and whether other issues might exist. Any takers for the remaining issues? Kind regards Andreas. -- http://fam-tille.de
Bug#967948: libuev: Please disable build on non-linux platforms
Source: libuev Version: 2.3.1-1 Severity: normal Tags: sid Dear Debian libuev maintainer, According to the buildd logs[1], this software requires epoll.h, which is not present on non-linux platforms. As a result, it might be reasonable to linux supported architectures to linux-any. Thanks, Boyuan Yang [1] https://buildd.debian.org/status/package.php?p=libuev signature.asc Description: This is a digitally signed message part
Bug#964541: flatpak: Wrong argument order for clone syscall seccomp filter on s390x (Was: make: Regression on s390x, echo EPERM, caused by posix_spawn change)
Control: reassign -1 flatpak
Control: retitle -1 flatpak: Wrong argument order for clone syscall seccomp
filter on s390x
Hello flatpak maintainer!
On Wed, Aug 05, 2020 at 03:19:39PM +0200, Christian Borntraeger wrote:
>
> On 21.07.20 13:24, Julian Andres Klode wrote:
> > On Tue, Jul 21, 2020 at 12:49:59PM +0200, Christian Borntraeger wrote:
> >> On 21.07.20 10:18, Adrian Bunk wrote:
> >>> [ adding debian-s390 to Cc ]
> >>>
> >>> On Wed, Jul 08, 2020 at 01:42:33PM +0200, Julian Andres Klode wrote:
> Package: make-dfsg
> Version: 4.3-4
> Severity: serious
> Tags: patch
> User: ubuntu-de...@lists.ubuntu.com
> Usertags: origin-ubuntu groovy ubuntu-patch
>
> In Ubuntu, the attached patch was applied to achieve the following:
>
> The autopkgtests for flatpak-builder/s390x where failing with
>
> echo Building
> make: echo: Operation not permitted
> make: *** [Makefile:2: all] Error 127
> >>
> >> Julian,
> >>
> >> is there a launchpad entry for the Ubuntu bug that was fixed by this
> >> change?
> >
> > Yes, https://bugs.launchpad.net/ubuntu/+source/make-dfsg/+bug/1886814, it's
> > also
> > in the IBM bugzilla thingy - you can see Andreas Krebbel is replying to
> > that.
>
> FWIW, Stefan Liebler looked into this and this needs to be fixed in
> flatpak-build.
> See the bug for details.
flatpak has the wrong argument order in the seccomp filter for 390x, the
attached patch should fix it.
--
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer i speak de, en
Description: Fix argument order of clone() for s390x in seccomp filter
clone() is a mad syscall with about 4 different argument orders. While
most of them agree that argument 0 is flags, s390 and s390x have the
flags argument second - A0 is the child stack pointer there.
Author: Julian Andres Klode
Bug-Debian: https://bugs.debian.org/964541
Bug-Ubuntu: https://launchpad.net/bugs/1886814
Forwarded: no
Last-Update: 2020-08-05
--- flatpak-1.8.1.orig/common/flatpak-run.c
+++ flatpak-1.8.1/common/flatpak-run.c
@@ -2667,7 +2667,11 @@ setup_seccomp (FlatpakBwrap *bwrap,
{SCMP_SYS (unshare)},
{SCMP_SYS (mount)},
{SCMP_SYS (pivot_root)},
+#if defined(__s390__) || defined(__s390x__)
+{SCMP_SYS (clone), _A1 (SCMP_CMP_MASKED_EQ, CLONE_NEWUSER, CLONE_NEWUSER)},
+#else
{SCMP_SYS (clone), _A0 (SCMP_CMP_MASKED_EQ, CLONE_NEWUSER, CLONE_NEWUSER)},
+#endif
/* Don't allow faking input to the controlling tty (CVE-2017-5226) */
{SCMP_SYS (ioctl), _A1 (SCMP_CMP_MASKED_EQ, 0xu, (int) TIOCSTI)},
Bug#967947: RM: python-snowballstemmer -- NBS; binary python3-snowballstemmer now built by src:snowball
Package: ftp.debian.org Severity: normal Dear FTP masters, Please remove python-snowballstemmer source package from sid. The only binary package which used to be built from it is now built from snowball source. See this merge request for details: https://salsa.debian.org/debian/snowball/-/merge_requests/4 -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#937927: python-mode: Python2 removal in sid/bullseye
Control: severity -1 important Now uses python2 explicitly.
Bug#966509: geeqie: can not start due to clutter-gtk init failure
On Wed, 29 Jul 2020 20:09:55 +0300 Eugene Berdnikov wrote: > Dear Maintainers, > > > % geeqie > > (geeqie:28868): Clutter-CRITICAL **: 19:45:09.437: Unable to > initialize Clutter: Unable to initialize the Clutter backend: no > available drivers found. Can't initialize clutter-gtk. > > > Problem was found after upgrade from 1.5.1-11: > > 2020-07-29 17:13:18 upgrade geeqie:amd64 1:1.5.1-11 > 1:1.5.1+git20200723-2 2020-07-29 17:13:19 upgrade geeqie-common:all > 1:1.5.1-11 1:1.5.1+git20200723-2 > > In ~/.config/geeqie/geeqierc.xml clutter is turned OFF: > image.use_clutter_renderer = "false" > As you can see in the upstream bug report [1], this is due to geeqie tries to start GTK with clutter no matter what, and if that fails it causes a hard crash that it has a hard time recovering from. As you can see there will be an command line option in future releases to start without clutter, and by this work around the problem. /Andreas gus...@debian.org 1: https://github.com/BestImageViewer/geeqie/issues/559
Bug#967946: gnome-settings-daemon: pulls in usbguard, even though GNOME has no GUI for it and silently blocks devices
Package: gnome-settings-daemon Version: 3.36.1-1 Severity: normal It took me days to find out why my system suddenly refuses most USB devices I plug in with the kernel message "device not authorized". It turns out the reason is that gnome-settings-daemon has pulled in usbguard, which by default rejects just about anything. I had no idea that USBGuard exists in the first place, so I had no idea where to start looking for the cause. However, since there is no GUI, the user is never prompted to allow a device. Why is gnome-settings-daemon depending on usbguard when there is no GUI and apparently no functionality in GNOME to allow or disallow USB devices? I would suggest that until there is such a GUI, this dependency should be dropped. Johannes -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.7.0-2-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gnome-settings-daemon depends on: ii gnome-settings-daemon-common 3.36.1-1 ii gsettings-desktop-schemas 3.36.1-1 ii libasound2 1.2.2-2.3 ii libc6 2.31-3 ii libcairo2 1.16.0-4 ii libcanberra-gtk3-0 0.30-7 ii libcanberra0 0.30-7 ii libcolord2 1.4.4-2 ii libcups2 2.3.3-2 ii libfontconfig1 2.13.1-4.2 ii libgcr-base-3-1 3.36.0-2 ii libgdk-pixbuf2.0-0 2.40.0+dfsg-5 ii libgeoclue-2-0 2.5.6-1 ii libgeocode-glib0 3.26.2-2 ii libglib2.0-0 2.64.4-1 ii libgnome-desktop-3-19 3.36.4-1 ii libgtk-3-0 3.24.20-1 ii libgudev-1.0-0 233-1 ii libgweather-3-16 3.36.0-1 ii liblcms2-2 2.9-4+b1 ii libmm-glib0 1.14.0-0.1 ii libnm0 1.26.0-1 ii libnotify4 0.7.9-1 ii libnspr4 2:4.27-1 ii libnss3 2:3.55-1 ii libpam-systemd [logind] 246-2 ii libpango-1.0-0 1.44.7-4 ii libpangocairo-1.0-0 1.44.7-4 ii libpolkit-gobject-1-0 0.105-29 ii libpulse-mainloop-glib0 13.0-5 ii libpulse0 13.0-5 ii libupower-glib3 0.99.11-2 ii libwacom2 1.4.1-1 ii libwayland-client0 1.18.0-1 ii libx11-6 2:1.6.10-3 ii libxext6 2:1.3.3-1+b2 ii libxi6 2:1.7.10-1 Versions of packages gnome-settings-daemon recommends: ii iio-sensor-proxy 3.0-1 ii pulseaudio 13.0-5 ii x11-xserver-utils 7.7+8 Versions of packages gnome-settings-daemon suggests: ii usbguard 0.7.8+ds-1+b1 -- no debconf information
Bug#967058: Init script missing
On Mon, 3 Aug 2020 20:53:43 +0200 Andreas Messer wrote: > I think the problem is changed behavior of 'dh_installinit'. The file > > debian/lcdproc.init > > should be renamed to > > debian/lcdproc.LCDd.init > > according to the man-page when using the --name argument. lintian is not happy when systemd name and init.d name do not match (lcdproc vs LCDd). I'm going to rename LCDd to lcdproc. All the best
Bug#964541: make: Regression on s390x, echo EPERM, caused by posix_spawn change
On 21.07.20 13:24, Julian Andres Klode wrote: > On Tue, Jul 21, 2020 at 12:49:59PM +0200, Christian Borntraeger wrote: >> On 21.07.20 10:18, Adrian Bunk wrote: >>> [ adding debian-s390 to Cc ] >>> >>> On Wed, Jul 08, 2020 at 01:42:33PM +0200, Julian Andres Klode wrote: Package: make-dfsg Version: 4.3-4 Severity: serious Tags: patch User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu groovy ubuntu-patch In Ubuntu, the attached patch was applied to achieve the following: The autopkgtests for flatpak-builder/s390x where failing with echo Building make: echo: Operation not permitted make: *** [Makefile:2: all] Error 127 >> >> Julian, >> >> is there a launchpad entry for the Ubuntu bug that was fixed by this change? > > Yes, https://bugs.launchpad.net/ubuntu/+source/make-dfsg/+bug/1886814, it's > also > in the IBM bugzilla thingy - you can see Andreas Krebbel is replying to that. FWIW, Stefan Liebler looked into this and this needs to be fixed in flatpak-build. See the bug for details.
Bug#931046: Some functions are in header but not exported in the .so
05.08.2020 16:21, Michael Tokarev wrote: ... > ... (which is still not fixed in-testing, btw).. this is ofcourse wrong statement, it is fixed in testing for a long time. /mjt
Bug#931046: Some functions are in header but not exported in the .so
On Tue, 25 Jun 2019 08:41:43 +0200 Christian Ehrhardt wrote: > package: device-tree-compiler > version: 1.5.0-1 > > libfdt 1.4.7-3 and 1.5.0-1 currently define some functions that it ... > I don't think it is a big issue for Buster, as other SW didn't pick > these up yet. Actually it is an issue for buster, or, rather, for buster-backports. I'm currently backporting current qemu to buster, due to popular demand, and faced this very issue, - qemu does not build on buster because of missing fdt_check_full() in the dynamic library. And with that I don't really know what to do - backporting a much more recent fdt to buster just to fix this bug (which is still not fixed in -testing, btw) seems to be overkill, but do we have some other way to fix this simple issue for buster? Thanks, /mjt
Bug#967058: Init script missing
On lundi 3 août 2020 20:53:43 CEST you wrote: > I think the problem is changed behavior of 'dh_installinit'. The file I think you're right. I'm on it. Thanks for the heads-up. All the best
Bug#967945: systemd is way too aggressive in deleting journals of yesterday
Package: systemd Version: 241-7~deb10u4 Everytime I look into the status of some failed service there is a message saying Warning: Journal has been rotated since unit was started. Log output is incomplete or unavailable. How comes? Disk space is cheap. And I didn't mess with the defaults: # egrep -v ^\# /etc/systemd/system.conf [Manager] # egrep -v ^\# /etc/systemd/journald.conf [Journal] # df -h /var/log/journal/ Filesystem Size Used Avail Use% Mounted on /dev/drbd1 11T 6.3T 4.1T 61% / # ls -al /var/log/journal total 56 drwxr-sr-x+ 3 root systemd-journal 4096 Jan 13 2016 . drwxr-xr-x 20 root root12288 Aug 4 00:00 .. drwxr-sr-x+ 2 root systemd-journal 36864 Aug 4 08:38 42b7d4373eff9fb16ebd59084afbff3f # # ls -al /dev/pts total 0 drwxr-xr-x 2 root root 0 Jul 18 10:18 . drwxr-xr-x 6 root root520 Jul 18 10:18 .. crw--w 1 root tty 136, 0 Jul 18 10:18 0 crw--w 1 root tty 136, 1 Jul 18 10:18 1 crw--w 1 root tty 136, 2 Jul 18 10:18 2 crw--w 1 root tty 136, 3 Jul 18 10:18 3 crw--- 1 root tty 136, 4 Aug 4 09:27 4 crw--w 1 root tty 136, 5 Aug 4 09:59 5 crw-rw-rw- 1 root root 5, 2 Aug 4 09:59 ptmx According to the specs this should give me 4 GByte journal. There was no such problem for stretch, AFAIR. I would strongly recommend to keep logs *by default* at least for a week, unless they don't exceed 2 GByte. Regards Harri
Bug#966575: How to fix LLVM/LUKS installs?
I.d.k. if it helps: We had problems on many Systems (all of them used noninteractive installation method) We saw, that if we do debconf-show grub-pc it showed us a wrong device: grub2/update_nvram: true grub-pc/install_devices_failed: false grub2/force_efi_extra_removable: false * grub2/linux_cmdline: debian-installer=en_US grub-pc/kopt_extracted: false * grub2/linux_cmdline_default: quiet grub-pc/install_devices_disks_changed: grub2/kfreebsd_cmdline: grub-pc/install_devices_failed_upgrade: true grub2/kfreebsd_cmdline_default: quiet grub-pc/mixed_legacy_and_grub2: true grub-pc/hidden_timeout: false * grub-pc/install_devices: /dev/vda grub-pc/install_devices_empty: false grub-pc/partition_description: grub-pc/postrm_purge_boot_grub: false grub-pc/disk_description: grub-pc/timeout: 5 grub-pc/chainload_from_menu.lst: true * should be /dev/xvda if we start the installer manually (interactive) the output is like this * grub-pc/install_devices_disks_changed: /dev/xvda grub2/kfreebsd_cmdline: grub-pc/mixed_legacy_and_grub2: true grub-pc/kopt_extracted: false grub-pc/hidden_timeout: false grub-pc/partition_description: grub2/kfreebsd_cmdline_default: quiet grub-pc/timeout: 5 * grub2/linux_cmdline: debian-installer=en_US apparmor=1 security=apparmor grub-pc/disk_description: grub-pc/install_devices_empty: false * grub-pc/install_devices: /dev/xvda grub-pc/chainload_from_menu.lst: true grub2/force_efi_extra_removable: false grub-pc/postrm_purge_boot_grub: false grub-pc/install_devices_failed_upgrade: true * grub2/linux_cmdline_default: quiet grub2/update_nvram: true grub-pc/install_devices_failed: false with the last output the system worked flawlessly strangely we had no problems whatsoever with systems which where major upgraded to buster. All the Best Dorian
Bug#967944: llvm-11 build/install failure on armhf, mipsel and mips64el
Package: src:llvm-toolchain-11 Version: 1:11.0.0~+rc1-1 Severity: important Tags: sid bullseye llvm-11 install failure on armhf, mipsel and mips64el: [...] dh_install --fail-missing dh_install: warning: Compatibility levels before 10 are deprecated (level 9 in use) dh_install: warning: Please use dh_missing --list-missing/--fail-missing instead dh_install: warning: This feature will be removed in compat 12. dh_install: warning: Cannot find (any matches for) "/usr/lib/llvm-11/include/ompt-multiplex.h" (tried in ., debian/tmp) dh_install: warning: libomp-11-dev missing files: /usr/lib/llvm-11/include/ompt-multiplex.h dh_install: error: missing files, aborting make[1]: *** [debian/rules:767: override_dh_install] Error 25 make[1]: Leaving directory '/<>'
Bug#966765: obs-build: Unversioned Python removal in sid/bullseye
On Wed, 5 Aug 2020, at 14:39, Dimitri John Ledkov wrote: > On Sun, 02 Aug 2020 13:18:51 + Matthias Klose wrote: > > Package: src:obs-build > > Version: 20180831-3 > > Severity: serious > > Tags: sid bullseye > > User: debian-pyt...@lists.debian.org > > Usertags: py2unversioned > > > > Python2 becomes end-of-live upstream, and Debian aims to remove > > Python2 from the distribution, as discussed in > > https://lists.debian.org/debian-python/2019/07/msg00080.html > > > > We will keep some Python2 package as discussed in > > https://lists.debian.org/debian-python/2020/07/msg00039.html > > but removing the unversioned python packages python-minimal, python, > > python-dev, python-dbg, python-doc. > > > > Your package either build-depends, depends on one of those packages. > > Please either convert these packages to Python3, or if that is not > > possible, replaces the dependencies on the unversioned Python > > packages with one of the python2 dependencies (python2, python2-dev, > > python2-dbg, python2-doc). > > > > Please check for dependencies, build dependencies AND autopkg tests. > > > > If there are questions, please refer to the wiki page for the removal: > > https://wiki.debian.org/Python/2Removal, or ask for help on IRC > > #debian-python, or the debian-pyt...@lists.debian.org mailing list. > > > > > > This is obsolete version of obs-build which is no longer used or > maintained upstream. It has long moved on to python3 version, which > are still not packaged yet in Debian. > > Ditto other things in the same stack i.e. dnf / zypper / yum / rpm. > > Please RM obs-build, and somebody who still cares about OBS tooling in > Debian might want to repackage this. Please don't RM it, I'll update it shortly. > Note that OBS upstream do provide Debian & Ubuntu repositories with up > to date tooling, which is readily available and at this point in time, > recommended to be used. > > I've stopped using OBS years ago. > > -- > Regards, > > Dimitri. > > -- Cheers, Andrej
Bug#967086: Empty pages when authenticated
Hi, On Tue, 04 Aug 2020, Stéphane Glondu wrote: > tracker.debian.org does not seem to respond or responds always empty > pages (no error) when I use a client certificate. I don't have the issue with my own certificate. I see this in the error log: [Wed Aug 05 11:17:05.798925 2020] [ssl:error] [pid 31979:tid 140564909500160] [client 80.227.5.106:40019] AH02039: Certificate Verification: Error (66): EE certificate key too weak [Wed Aug 05 11:59:09.029731 2020] [ssl:error] [pid 31979:tid 140565890987776] [client 80.227.5.106:9418] AH02039: Certificate Verification: Error (66): EE certificate key too weak So maybe get a new certificate? I don't think that I can change anything in the configuration on my side. Cheers, -- ⢀⣴⠾⠻⢶⣦⠀ Raphaël Hertzog ⣾⠁⢠⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/ ⠈⠳⣄ Debian Long Term Support: https://deb.li/LTS
Bug#966765: obs-build: Unversioned Python removal in sid/bullseye
On Sun, 02 Aug 2020 13:18:51 + Matthias Klose wrote: > Package: src:obs-build > Version: 20180831-3 > Severity: serious > Tags: sid bullseye > User: debian-pyt...@lists.debian.org > Usertags: py2unversioned > > Python2 becomes end-of-live upstream, and Debian aims to remove > Python2 from the distribution, as discussed in > https://lists.debian.org/debian-python/2019/07/msg00080.html > > We will keep some Python2 package as discussed in > https://lists.debian.org/debian-python/2020/07/msg00039.html > but removing the unversioned python packages python-minimal, python, > python-dev, python-dbg, python-doc. > > Your package either build-depends, depends on one of those packages. > Please either convert these packages to Python3, or if that is not > possible, replaces the dependencies on the unversioned Python > packages with one of the python2 dependencies (python2, python2-dev, > python2-dbg, python2-doc). > > Please check for dependencies, build dependencies AND autopkg tests. > > If there are questions, please refer to the wiki page for the removal: > https://wiki.debian.org/Python/2Removal, or ask for help on IRC > #debian-python, or the debian-pyt...@lists.debian.org mailing list. > > This is obsolete version of obs-build which is no longer used or maintained upstream. It has long moved on to python3 version, which are still not packaged yet in Debian. Ditto other things in the same stack i.e. dnf / zypper / yum / rpm. Please RM obs-build, and somebody who still cares about OBS tooling in Debian might want to repackage this. Note that OBS upstream do provide Debian & Ubuntu repositories with up to date tooling, which is readily available and at this point in time, recommended to be used. I've stopped using OBS years ago. -- Regards, Dimitri.
Bug#964446: sane-airscan stuck in NEW
Thanks for heads up, I'll update it. On 8/5/20 2:02 PM, Alexander Pevzner wrote: > Hi Till, OdyX, Zdenek, > > I've just created the new 0.99.12 release, and I highly recommend to > upgrade existent packaging. > > All technical details were posted to the > sane-de...@alioth-lists.debian.net mailing list. > > On 8/4/20 9:17 PM, Till Kamppeter wrote: >> Great, so I will base my Ubuntu package also on the new version. >> >> OdyX, could you update the Debian packaging appropriately, too? Thanks. >> >> Till >> >> On 04/08/2020 20:10, Alexander Pevzner wrote: >>> I think I will merge -unstable in few hours and will release result >>> as 0.99.12. It would be nice, if Debian will synchronize with .12, >>> not .11 (otherwise we will wait a couple of month before next chance >>> to synchronize). >>> >>> As .12 drops dependency on libsoup and libglib, and adds dependency >>> on gnutls, it will require packaging to be tweaked a little bit. > > -- Zdenek Dohnal Software Engineer Red Hat Czech - Brno TPB-C signature.asc Description: OpenPGP digital signature
Bug#967906: systemd 246 resolvconf path unit
Yes, I had resolvconf around for some reason while using systemd-resolved. Thanks for forwarding to upstream.
Bug#953033: bug#39901: Emacs needs to update window-width when the user updates the text size
積丹尼 Dan Jacobson writes: > Emacs needs to update window-width when the user updates the text size. I think that makes sense. Anybody got an opinion here? I'm not sure how this would be implemented, though. Where's the code that computes the pixel width upon startup? I guess that code would have to be run again to compute the new width... -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no
