Bug#972545: RFS: fonts-jetbrains-mono/2.002-1 -- free and open-source typeface for developers
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "fonts-jetbrains-mono": * Package name: fonts-jetbrains-mono Version : 2.002-1 Upstream Author : [fill in name and email of upstream] * URL : https://www.jetbrains.com/lp/mono/ * License : Apache-2, OFL-1.1 * Vcs : https://salsa.debian.org/fonts-team/fonts-jetbrains-mono Section : contrib/fonts It builds those binary packages: fonts-jetbrains-mono - free and open-source typeface for developers To access further information about this package, please visit the following URL: https://mentors.debian.net/package/fonts-jetbrains-mono/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/contrib/f/fonts-jetbrains-mono/fonts-jetbrains-mono_2.002-1.dsc Changes since the last upload: fonts-jetbrains-mono (2.002-1) unstable; urgency=medium . * Import new upstream release v2.002. * Update debhelper from v12 to v13. ** why are the fonts not built from source? ** Because if we do so we cannot currently generate variants such as the "non-ligature" versions. Upstream seems to have delivered a build script in their master git branch, but it was not released yet. As soon as upstream releases a new version with their modifications, we can try to build from source and move this package to main instead of currently contrib. Regards, -- Romain Porte signature.asc Description: PGP signature
Bug#972544: solaar: upstream url is incorrect
Package: solaar Version: 0.9.2+dfsg-9 Severity: minor Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? I installed solaar on debian buster using the gnome-softare tool. * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? in gnome-software it has a Website button that links to the upstream project. when i click the icon, it takes me to https://pwr.github.io/Solaar which is 404. * What outcome did you expect instead? I expect it to take me to https://pwr-solaar.github.io/Solaar/ Also the the about page in Solaar has the wrong url link in it and should be corrected. *** End of the template - remove these template lines *** -- System Information: Debian Release: 10.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-debug'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.8.0-0.bpo.2-amd64 (SMP w/16 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE=en_AU:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages solaar depends on: ii adduser3.118 ii debconf [debconf-2.0] 1.5.71 ii gir1.2-gtk-3.0 3.24.5-1 ii passwd 1:4.5-1.1 ii python 2.7.16-1 ii python-gi 3.30.4-1 ii python-pyudev 0.21.0-1 ii udev 241-7~deb10u4 Versions of packages solaar recommends: ii gir1.2-notify-0.7 0.7.7-4 ii python-dbus1.2.8-3 ii systemd246.6-2~bpo10+1 ii upower 0.99.10-1 Versions of packages solaar suggests: ii gir1.2-appindicator3-0.1 0.4.92-7 pn solaar-gnome3 -- debconf information: solaar/use_plugdev_group: false
Bug#972543: apt-file: Apt-update downloads full Contents file, not pdiffs
Package: apt-file
Version: 3.2.2
Severity: normal
X-Debbugs-Cc: calumlikesapple...@gmail.com
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Basically, on every call to apt-update that isn't completely trivial (ie, at
least
1 package changed), my computer downloads the full 60 Mb of Contents files.
This
is irritating, for while I am often on a fast internet, I frequently find
myself on
a very slow connection.
I know my config file enables pdiffs (and I attached it so you can know, too).
The Readme talks a lot about pdiffs, and why I should enable them, but except
for
one sentence, it doesn't mention anything about apt update. (The sentence in
question *could* be interpreted to mean that apt update will never download
Pdiffs, but that is unlikely, given its context).
I don't know what's the cause. If you need me to get a log file, I can, but
Apt doesnt include these files in its final output: only while it is
drawing progress bars.
Thank you!
Calum
- -- System Information:
Debian Release: bullseye/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.8.0-3-amd64 (SMP w/4 CPU threads)
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 apt-file depends on:
ii apt 2.1.10
ii libapt-pkg-perl 0.1.36+b3
ii liblist-moreutils-perl 0.416-1+b5
ii libregexp-assemble-perl 0.36-1
ii perl 5.30.3-4
apt-file recommends no packages.
apt-file suggests no packages.
- -- no debconf information
-BEGIN PGP SIGNATURE-
iQJRBAEBCgA7FiEE/vC/PEGxsMPJ5u5w7/Xh1+DNmzIFAl+ObBsdHGNhbHVtbGlr
ZXNhcHBsZXBpZUBnbWFpbC5jb20ACgkQ7/Xh1+DNmzKbuQ//SXtp2pvjIgjQa2As
eWwtieJpvjlxG+qsKKJSfeHxLuCdGKoTs2a7/e4/BVbaQhPvNHdsDOPA6tY+QcdU
+iPU48L9fkA8B4YxeQqB6AzUyZM2bNdiaYNMJSyLu+o1WBDbk/an/QclkD23wQGL
E+Yyo9vIzVtmIA8S/NTWT6u9gW0mov4zH4ORHavacR3z/c4Yx17yNhHc5OlFbqmk
4nAuAedgirkj4OTbjwh+xofFkX7iP5P9X1rkz59UUJmKBOti9ZQs4GZYpHd8YLOG
FKJlOjumHbTB4kz16TfLAYvP/w0BIYkqPMTfZMjZxpFfyYllYx31K6j/w5qXaFTi
GYyBUnqB6+zk6doNzZwV0cBTwaO7tW0snptIHwLtM0iU1LyYkTh5M62IcLeqrozL
eNX9WZOk/OSqiwlJqg2mqB7R2ZRYtJaYf4qGmdQzQ2xMft16Vm+1q9WB0RY+RIJ7
RexE8fo+UrewdKkyuzMw6aMjpFm6iSakagx7Szc02RN9LnL9r63AsIbl0nDIxCQh
a933Oto7D2WbF+tl3OO+I0m2+xGt941VWUD+3yp/RBQcjnSieYIRSfwINlXiNVc+
6/+u3W0NhigH/qS88XH0gc3jQY0DixcGROvrtkVe4+1fwQEwGMrjtjG9aH3E2bif
HfPVdM8L2mhoKuUV7lg4rFLXPEk=
=+avA
-END PGP SIGNATURE-
## This file is provided by apt-file(1) to download Contents
## files, which is used by apt-file for searching.
Acquire::IndexTargets {
deb::Contents-deb {
MetaKey "$(COMPONENT)/Contents-$(ARCHITECTURE)";
ShortDescription "Contents-$(ARCHITECTURE)";
Description "$(RELEASE)/$(COMPONENT) $(ARCHITECTURE) Contents (deb)";
flatMetaKey "Contents-$(ARCHITECTURE)";
flatDescription "$(RELEASE) Contents (deb)";
PDiffs "true";
KeepCompressed "true";
};
# Download Contents for source files if there is a deb-src
# line
deb-src::Contents-dsc {
MetaKey "$(COMPONENT)/Contents-source";
ShortDescription "Contents-source";
Description "$(RELEASE)/$(COMPONENT) source Contents (dsc)";
flatMetaKey "Contents-source";
flatDescription "$(RELEASE) Contents (dsc)";
PDiffs "true";
KeepCompressed "true";
DefaultEnabled "false";
};
# Configuration for downloading Contents files for
# debian-installer packages (udebs).
deb::Contents-udeb {
MetaKey "$(COMPONENT)/Contents-udeb-$(ARCHITECTURE)";
ShortDescription "Contents-udeb-$(ARCHITECTURE)";
Description "$(RELEASE)/$(COMPONENT) $(ARCHITECTURE) Contents (udeb)";
flatMetaKey "Contents-udeb-$(ARCHITECTURE)";
flatDescription "$(RELEASE) Contents (udeb)";
KeepCompressed "true";
PDiffs "true";
DefaultEnabled "false";
};
### FALLBACKS
deb::Contents-deb-legacy {
MetaKey "Contents-$(ARCHITECTURE)";
ShortDescription "Contents-$(ARCHITECTURE)";
Description "$(RELEASE) $(ARCHITECTURE) Contents (deb)";
PDiffs "true";
KeepCompressed "true";
Fallback-Of "Contents-deb";
Identifier "Contents-deb";
};
};
Dir::Etc::apt-file-main "apt-file.conf";
# Default for -I/--index-names (comma-separated)
apt-file::Index-Names "deb";
# Set to true, if you are working with Contents files generated by
# older versions of dak or reprepro (<< 5.2.0-1~) that includes a
# descriptive header.
apt-file::Parser::Check-For-Description-Header "false";
Bug#972542: ITP: librust-libnotcurses-sys-dev -- Character graphics and TUI library (Rust development)
Package: wnpp Severity: wishlist Owner: "Nick Black (Public gmail account)" X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: librust-libnotcurses-sys-dev Version : 2.0.1 Upstream Author : Nick Black * URL : https://nick-black.com/dankwiki/index.php/Notcurses * License : Apache-2.0 Programming Lang: Rust Description : Character graphics and TUI library (Rust development) Notcurses facilitates the creation of modern TUI programs, making full use of Unicode and 24-bit TrueColor. It presents an API similar to that of Curses, and rides atop Terminfo. . These files are necessary for Rust development using Notcurses. The Notcurses C++ and Python wrappers are already being packaged. The Rust wrappers are not yet being packaged (see https://github.com/dankamongmen/notcurses/issues/355), but with the recent release of Notcurses 2.0 and its stable API, that time has come. All of these wrappers come from the same upstream source, though this package will be using source taken from crates.io. -- nick black -=- https://www.nick-black.com to make an apple pie from scratch, you need first invent a universe.
Bug#972541: node-ws: embedded module agent-base is in Debian as node-agent-base
Source: node-ws Version: 7.3.1+~cs24.0.5-1 Dear Maintainer(s), node-ws embeds nodejs module agent-base which has recently entered Debian as package node-agent-base. Please remove the embedded module and depend on node-agent-base instead. Best wishes, Andrius
Bug#972540: python3-torch: Depends on not-existing packages "3.8"
Hi
> python3-torch requests a package
> 3.8
Comes from this line (the remove done)
--- a/debian/control
+++ b/debian/control
@@ -63,7 +63,6 @@ Architecture: any
Depends: libtorch1.6 (= ${binary:Version}),
${misc:Depends},
${python3:Depends},
- ${python3:Versions},
${shlibs:Depends}
# PyTorch's JIT (C++ Extension) functionality needs development files/tools.
Recommends: libtorch-dev (= ${binary:Version}), ninja-build,
Norbert
--
PREINING Norbert https://www.preining.info
Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev
GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
Bug#954824: chromium: Enable PipeWire support in WebRTC
severity: minor (I have no idea if that will work: I'm not a DD, nor the reporter. But this is definitely minor, if not normal) On Wed, 22 Apr 2020 11:43:48 +0200 Domenico Cufalo wrote: > Dear Maintainer, > > I would like to add my vote in favor of the request to enable > PipeWire support. As would I > Yes, I do know that this request, as it seems, has already been > rejected for security reasons (see bug #886358)*, Actually, though the bugs look related, they aren't. That bug is about installing Google-specific extensions to chromium by default. This one regards enabling a setting. To be clear, the change wouldn't enable it for everyone: it would only make it possible for it to be enabled by a savvy user. > but this lack > renders Chromium unusable for remote working and this is a problem in > a period like this, characterized by the lock-down for Covid-19. > > Due to this lack I was forced to install Google Chrome, but i would > by far prefer to be able to use Chromium, instead. I agree. I would rather not have to install Chrome manually, especially when such a minor change could make the difference. > Therefore, I would ask you to reconsider the question of whether to > enable that support, if possible. > > In the meantime, I thank you for all your efforts in maintaining this > excellent browser and I send you my best regards. I agree here, too. It looks like your trying to maintain packaging for one of the largest open-source projects on your own (at least, with only 1 other person helping). If you need a hand, just ask! signature.asc Description: This is a digitally signed message part
Bug#972524: [Pkg-nagios-devel] Bug#972524: monitoring-plugins: FTBFS on buster (dh_compress)
Control: tags -1 unreproducible Control: severity -1 important Hi Jakob, Thanks for reporting this issue, but unfortunately I cannot reproduce it. Building 2.2-6 in a buster chroot works as expected: gbp clone \ https://salsa.debian.org/nagios-team/pkg-monitoring-plugins.git git checkout -b buster debian/2.2-6 gbp buildpackage --git-pbuilder \ --git-dist=buster \ --git-debian-branch=buster Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#972540: python3-torch: Depends on not-existing packages "3.8"
Package: python3-torch Version: 1.6.0-3 Severity: grave Hi, it seems that something went havoc in the depends field and python3-torch requests a package 3.8 which probably should have been a version number. Best Norbert -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.9.1+ (SMP w/8 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages python3-torch depends on: pn 3.8 ii libc6 2.31-4 ii libgcc-s1 10.2.0-15 pn libgoogle-glog0v5 pn libonnx1 ii libprotobuf23 3.12.3-2+b1 ii libstdc++6 10.2.0-15 pn libtorch1.6 ii python3 3.8.6-1 ii python3-future 0.18.2-4 ii python3-numpy [python3-numpy-abi9] 1:1.19.2-2+b1 ii python3-pkg-resources 50.3.0-1 ii python3-requests2.23.0+dfsg-2 ii python3-six 1.15.0-1 ii python3-yaml5.3.1-2+b1 ii python3.8 3.8.6-1 Versions of packages python3-torch recommends: pn libtorch-dev ii ninja-build 1.10.1-1 Versions of packages python3-torch suggests: pn python3-hypothesis ii python3-pytest 4.6.11-1
Bug#972539: isc-dhcp-client: fails to set valid_lft if IP exists, then IP expires early
Package: isc-dhcp-client Version: 4.4.1-2.1+b2 Severity: normal Dear Maintainer, I believe I have found the exact bug anticipated by Sven Ulland in his fix for #834532. Here is a quote from his report: > A problem remains: If dhclient is terminated and started again, it starts with > reason=REBOOT and attempts to do a 'ip -4 addr add ...'. Since the address is > still configured on the interface, this results in 'RTNETLINK answers: File > exists', and the lifetimes are not reset. If the lifetimes expire before the > DHCP renew hits, the address(es) are removed from the interface. This should > probably be fixed in a separate issue. Just to expand on Sven's description with my actual symptoms... I have a script which can restart dhclient rather abruptly (killall -9 dhclient; dhclient wlan0). Sometimes the IP address remains on the interface, and then after dhclient restarts the valid_lft is not reset. Then the kernel kills the IP address after the lifetime runs out, but dhclient isn't ready to renew the interface yet. The connection is then dead until dhclient renews on its own schedule (or it is manually restarted). To work around it on my system, I simply found the two commands that set valid_lft and replaced "ip -4 addr add" with "ip -4 addr replace". I think this fix should be generally applicable. Here's the trivial patch: http://galexander.org/x/0001-replace-IPv4-lifetime-instead-of-add-in-case-it-alre.patch Hope this helps! Thanks! - Greg -- System Information: Distributor ID: Debian Description:Devuan GNU/Linux 3 (beowulf) Release:3 Codename: beowulf Architecture: x86_64 Kernel: Linux 4.19.0-11-amd64 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) LSM: AppArmor: enabled Versions of packages isc-dhcp-client depends on: ii debianutils4.8.6.1 ii iproute2 4.20.0-2 ii libc6 2.31-4 ii libdns-export1110 1:9.11.19+dfsg-1 ii libisc-export1105 1:9.11.19+dfsg-1 Versions of packages isc-dhcp-client recommends: ii isc-dhcp-common 4.4.1-2 Versions of packages isc-dhcp-client suggests: pn avahi-autoipd pn isc-dhcp-client-ddns ii resolvconf1.84 -- Configuration Files: /etc/dhcp/dhclient.conf changed [not included] -- no debconf information
Bug#972527: Support arbitrary arguments in /etc/default/dnss
Package: dnss
Version: 0.0~git20180721.0.2de63ab0-1+b11
Severity: wishlist
/lib/systemd/system/dnss.service uses curly braces with
${MONITORING_FLAG} and ${MODE_FLAGS}, which means each one can only have
a single argument in it. It would be great if there were some way to
specify additional arguments to dnss, either via one of those variables
or a new variable.
For reference,
https://www.freedesktop.org/software/systemd/man/systemd.service.html#Command%20lines:
Basic environment variable substitution is supported. Use "${FOO}" as part of a word, or
as a word of its own, on the command line, in which case it will be erased and replaced by the
exact value of the environment variable (if any) including all whitespace it contains, always
resulting in exactly a single argument. Use "$FOO" as a separate word on the command
line, in which case it will be replaced by the value of the environment variable split at
whitespace, resulting in zero or more arguments. For this type of expansion, quotes are respected
when splitting into words, and afterwards removed.
Bug#972538: ThinkPad TrackPoint Keyboard II: with bluetooth, middle-mouse scrolling doesn't work in all applications
Package: libinput10 Version: 1.16.2-1 Severity: normal X-Debbugs-Cc: j...@joshtriplett.org I have a ThinkPad TrackPoint Keyboard II ( https://www.lenovo.com/us/en/accessories-and-monitors/keyboards-and-mice/keyboards/KBD-BO-TrackPoint-KBD-US-English/p/4Y40X49493 ), which works via either Bluetooth or a custom USB wireless dongle. If I connect the keyboard via the USB wireless dongle, everything seems to work perfectly. If I connect the keyboard via Bluetooth, the mouse is substantially less responsive (have to push further to move), and more imortantly, middle-mouse scrolling doesn't work in all applications. No matter how I've connected the keyboard, middle-mouse scrolling (hold the middle button and move the stick to scroll) works in Firefox. But if I connect via Bluetooth, that method doesn't scroll in the gnome-settings window. If I connect via USB, it does. - Josh -- 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.8.0-3-amd64 (SMP w/4 CPU threads) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages libinput10 depends on: ii libc6 2.31-4 ii libevdev2 1.9.1+dfsg-1 ii libinput-bin 1.16.2-1 ii libmtdev1 1.1.6-1 ii libudev1 246.6-2 ii libwacom2 1.5-1 libinput10 recommends no packages. libinput10 suggests no packages. -- no debconf information
Bug#972537: please add --enable-ros3-vfd to the build options to allow RO access to HDF5 on S3
Source: hdf5
Version: 1.12.0+repack-1~exp2
Severity: wishlist
Overall patch below worked for me now now hdf5 tools work with ros3 driver,
e.g.
$> h5ls -r --vfd=ros3
https://dandiarchive.s3.amazonaws.com/girder-assetstore/6a/2f/6a2fe9e83746474790c504b9c8abb3ae
/Group
/acquisition Group
/acquisition/lick_times Group
..
diff --git a/debian/control.in b/debian/control.in
index e5d14995..17f67763 100644
--- a/debian/control.in
+++ b/debian/control.in
@@ -13,6 +13,8 @@ Build-Depends: debhelper (>= 10~),
chrpath,
libaec-dev,
default-jdk-headless (>= 2:1.7) [!hppa !hurd-i386],
+ libcurl4-openssl-dev,
+ libssl-dev,
javahelper [!hppa !hurd-i386]
Build-Depends-Indep: doxygen,
php-cli
diff --git a/debian/rules b/debian/rules
index 42962deb..ec072691 100755
--- a/debian/rules
+++ b/debian/rules
@@ -103,7 +103,7 @@ CONFIGURE_FLAGS = --prefix=/usr --host=$(DEB_HOST_GNU_TYPE)
\
--enable-shared --enable-build-mode=$(USE_PROD) \
--disable-sharedlib-rpath --with-zlib
--with-default-api-version=v18 \
--with-szlib \
- --enable-fortran --enable-fortran2003
+ --enable-fortran --enable-fortran2003 --enable-ros3-vfd
FLAVOR_FLAGS = --includedir=\$${prefix}/include/hdf5/$(1) \
--with-flavor=$(1) \
-- System Information:
Debian Release: bullseye/sid
APT prefers testing
APT policy: (900, 'testing'), (600, 'unstable'), (300, 'experimental'), (100,
'unstable-debug'), (100, 'stable-updates'), (100, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.6.0-1-amd64 (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=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Bug#969247: FIX: add /etc/boinc-client/config.properties
On Thu, 24 Sep 2020 19:08:25 +0200 Marcel Partap wrote: > .. so after some research, this happens due to these changes merged in March: https://github.com/BOINC/boinc/pull/3709 > > Fortunately, previous behaviour can easily be restored by adding a /etc/boinc-client/config.properties file containing: > > > data_dir=/var/lib/boinc > > That points boincmgr and boinccmd where to find the gui_rpc_auth.cfg file to read the password from. > In order for a random password (in case of an empty file) to be written successfully, I think I had to change the permission for either the sym link /var/lib/boinc-client/gui_rpc_auth.cfg or the actual file in /etc. > > Regards! > > Hi, I purged my BOINC installation, reinstalled, added a /etc/boinc-client/config.properties file containing "data_dir=/var/lib/boinc" and changed permissions in both /var/lib/boinc-client/gui_rpc_auth.cfg and the actual file in /etc, and still gave me the same error. Any chance we can get the package fixed soonish in testing? Thanks for all your work :) Cheers, Marcos
Bug#971214: elpy: FTBFS: tests failed
Control: tag -1 unreproducible Justification: fixed via black-20.8b1-2 Hi Lucas, Lucas Nussbaum writes: > Source: elpy > Version: 1.34.0-2 > Severity: serious > Justification: FTBFS on amd64 > Tags: bullseye sid ftbfs > Usertags: ftbfs-20200926 ftbfs-bullseye > I believe this was due to #970901 in Black. The failure logs are dated 2020-10-06, and the fix for Black was uploaded 2020-10-12. At the moment, due to hardware failure, I don't have access to my SSO certificate and cannot schedule a rebuild for affected archs at https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/elpy.html I just tried building against black-20.8b1-2, and this build was successful. If you or someone else could schedule a rebuild I would very much appreciate it :-) I've marked this bug unreproducible in the meantime, and believe that a rebuild will confirm my results. Thanks! Nicholas
Bug#908712: Still present in stable
* Arnaud Patard [2020-10-15 11:37]: > No, I've missed it. Sorry. I've just sent the patch again. It's in 4.19.152 now. Thanks everyone! -- Martin Michlmayr https://www.cyrius.com/
Bug#968459: python-modernize: please upgrade to 0.8.0 or newer
Hi Thomas, Benjamin, and Python Team, Thomas Grainger writes: > Awesome, thanks for the update! Just to let you know there's a pre-release > https://pypi.org/project/modernize/0.9rc0/ version that combines the > libmodernize and modernize namespace Good to know! I'm not familiar with the details, but it sounds like either the "modernize" or "python3-modernize" Debian package will need to be removed from src:modernize for versions >= 0.9rc0 (the remaining packages would need a "Provides:removed-package" in debian/control). This would mean that src:modernize would need to pass through the NEW queue again. https://ftp-master.debian.org/new.html As you can see, there's a bit of a backlog! Any packages that need to pass through NEW need to do so before 2021-02-12. I'm hopeful that fissix will be reviewed and accepted before then, thus enabling an update to Modernize 0.8.0, and I recommend preparing an upload well before then (even though we can't upload until fissix clears NEW) After the 0.8.0 upload has been prepared, work could commence on updating the Modernize for Debian to 0.9rc0. If 0.9.0 (final release) is not released early enough for it to pass through NEW, at least we'll have 0.8.0 in Bullseye (Debian 11). Alternatively, while the semantics are wrong, I wonder if it would be acceptable to use a dummy transitional package to avoid a trip through NEW? My feeling is it wouldn't be acceptable, but I could be wrong. And yes, unfortunately if fissix doesn't clear NEW before the soft-freeze deadline then we won't see a new Modernize release in a Debian stable release before Bookworm (Debian 12). Regards, Nicholas
Bug#972536: fpc: the old version 3.0.4+dfsg-23 still in sid
Source: fpc Version: 3.0.4+dfsg-23 Severity: minor Dear Maintainer, The newest verison of fpc is 3.2.0+dfsg-8, now is in the testing. But the old version 3.0.4+dfsg-23 is still in sid. Is need to remove old version from sid? -- System Information: Debian Release: 10.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.8.0-0.bpo.2-amd64 (SMP w/4 CPU cores) Locale: LANG=zh_CN.utf8, LC_CTYPE=zh_CN.utf8 (charmap=UTF-8), LANGUAGE=zh_CN:zh (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#969648: BD-Uninstallable Re: dask, pandas 1.1
A bot wrote: Dependency installability problem for dask on all: dask build-depends on: - python3-pandas:amd64 (>= 0.19.0) dask build-depends on: - python3-distributed:amd64 python3-distributed depends on: - python3-dask:amd64 (>= 2.9.0) python3-pandas conflicts with: - python3-dask:amd64 (< 2.11.0+dfsg-1.1~) I removed the python3-distributed build-dependency to break this cycle, but I've only tested that with my version. It can be added back once we have an installable dask.
Bug#972535: easyssh: Misuses the alternatives systems without reasons to just rename binbaries
Package: easyssh Version: 1.7.4-1 Hi, citing from https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=972462#10: > I plan to provide /usr/bin/easyssh via update-alternatives tool. This > is better than making a plain symlink. This is just wrong. Use dh_link for symlinks. Or even better: Just rename that binary as our users expect it and as FTP-Master requested it. > It is almost sure that someone will try to provide /usr/bin/easyssh in > another project sooner or later since this is a good name. This is _NOT_ what the alternatives system is for. The alternatives system is solely for implementations of the same functionality and at least generally the same commandline parameter syntax. You can neither expect that an arbitrary other project called easyssh would provide the same functionality nor that it would have the same commandline options, etc. Please read the Debian Policy about what the alternatives system is for: https://www.debian.org/doc/debian-policy/ap-pkg-alternatives.html -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (990, 'unstable'), (600, 'testing'), (500, 'unstable-debug'), (500, 'buildd-unstable'), (110, 'experimental'), (1, 'experimental-debug'), (1, 'buildd-experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.7.0-2-amd64 (SMP w/4 CPU threads) 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) LSM: AppArmor: enabled Versions of packages easyssh depends on: ii dconf-gsettings-backend [gsettings-backend] 0.38.0-1 ii libc62.31-4 ii libgee-0.8-2 0.20.3-1 ii libglib2.0-0 2.66.1-2 ii libgranite5 5.5.0-1 ii libgtk-3-0 3.24.23-2 ii libjson-glib-1.0-0 1.6.0-1 ii libpango-1.0-0 1.46.2-1 ii libvte-2.91-00.62.0-3 easyssh recommends no packages. easyssh suggests no packages. -- no debconf information
Bug#964221: googletest: meson support
On Fri, 3 Jul 2020 22:14:18 +0200 Philipp Kern wrote: > Would it be possible for googletest in Debian to ship these meson.build files > alongside the source in the library packages? That way packages could > build-depend on libgtest-dev without requiring them to use CMake. It's a reasonable request. Where in the filesystem would you like to see these three files? -Steve signature.asc Description: This is a digitally signed message part.
Bug#972205: arm-compute-library binary-all FTBFS: This package can only be built for armhf and arm64
yes, the attempt in the package rules to avoid build failures on unsupported architectures actually was null in the debian context and just broke the ability to build the arch-all binaries on any architecture (needed for source-only uploads). Fixed in 19.11-3, just uploaded. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Bug#972534: scribus: Inconsistent behaviour with lines selection
Package: scribus Version: 1.5.5+svn23928+dfsg-1+b2 Severity: important X-Debbugs-Cc: riveravaldezm...@gmail.com Dear Maintainer, * What led up to the situation? Seems like a problem of the version. Can't think of anything that I've done that could have originated it. * What exactly did you do (or not do) that was effective (or ineffective)? When a file has multiple lines (object line) the selection seems odd. Clicking over some lines will produce the selection of others, which are distant of the clicking point. With multiple pages clicking in a clear space of one page will select some line in some other, distant page - or even creat a line randomly, apparently - and then if one moves the selected object let's say being in page 2, the view will jump to let's say page 10, where the randomly selected line is. I tried with File > Preferences > Default (button) with no modification of this behaviour. * What outcome did you expect instead? Essentially, to click in a line and get that line selected. Thanks a lot, let me know if I can give any other useful information. Best regards. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.8.0-1-amd64 (SMP w/3 CPU threads) Kernel taint flags: TAINT_WARN Locale: LANG=es_AR.UTF-8, LC_CTYPE=es_AR.UTF-8 (charmap=UTF-8), LANGUAGE=es_AR:es Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages scribus depends on: ii ghostscript 9.52.1~dfsg-1 ii libc62.30-8 ii libcairo21.16.0-4 ii libcdr-0.1-1 0.1.6-1+b1 ii libcups2 2.3.3-3 ii libfontconfig1 2.13.1-4.2 ii libfreehand-0.1-10.1.2-3 ii libfreetype6 2.10.2+dfsg-3 ii libgcc-s110.2.0-7 ii libgraphicsmagick-q16-3 1.4+really1.3.35+hg16297-1 ii libharfbuzz-icu0 2.6.7-1 ii libharfbuzz0b2.6.7-1 ii libhunspell-1.7-01.7.0-3 ii libicu67 67.1-4 ii libjpeg62-turbo 1:2.0.5-1.1 ii liblcms2-2 2.9-4+b1 ii libmspub-0.1-1 0.1.4-3+b1 ii libopenscenegraph161 3.6.5+dfsg1-5 ii libopenthreads21 3.6.5+dfsg1-5 ii libpagemaker-0.0-0 0.0.4-1 ii libpng16-16 1.6.37-2 ii libpodofo0.9.6 0.9.6+dfsg-5 ii libpoppler10220.09.0-2 ii libpython3.8 3.8.5-2 ii libqt5core5a 5.14.2+dfsg-6 ii libqt5gui5 5.14.2+dfsg-6 ii libqt5network5 5.14.2+dfsg-6 ii libqt5opengl55.14.2+dfsg-6 ii libqt5printsupport5 5.14.2+dfsg-6 ii libqt5widgets5 5.14.2+dfsg-6 ii libqt5xml5 5.14.2+dfsg-6 ii libqxp-0.0-0 0.0.2-1+b1 ii librevenge-0.0-0 0.0.4-6+b1 ii libstdc++6 10.2.0-7 ii libtiff5 4.1.0+git191117-2 ii libvisio-0.1-1 0.1.7-1+b1 ii libxml2 2.9.10+dfsg-6 ii libzmf-0.0-0 0.0.2-1+b3 ii scribus-data 1.5.5+svn23928+dfsg-1 ii zlib1g 1:1.2.11.dfsg-2 Versions of packages scribus recommends: ii cups-bsd2.3.3-3 ii fonts-dejavu2.37-2 ii fonts-liberation1:1.07.4-11 ii gsfonts-x11 0.27 ii hyphen-pt-pt [hyphen-hyphenation-patterns] 1:7.0.1-1 ii icc-profiles-free 2.0.1+dfsg-1 ii xfonts-scalable 1:1.0.3-1.1 Versions of packages scribus suggests: pn icc-profiles pn scribus-doc pn scribus-template ii texlive-latex-recommended 2020.20200804-2 -- no debconf information
Bug#972524: monitoring-plugins: FTBFS on buster (dh_compress)
Source: monitoring-plugins Version: 2.2-6 Severity: serious Tags: ftbfs Justification: fails to build from source Dear Maintainer, When trying to locally rebuild monitoring-plugins on a Buster system with the build-depends installed, the build actually fails during dh_compress. This was tried with both the version 22-6 packaged source and the suggested git package source. Steps to reproduce: # LC_ALL=C aptitude build-depends monitoring-plugins No packages will be installed, upgraded, or removed. 0 packages upgraded, 0 newly installed, 0 to remove and 0 not upgraded. Need to get 0 B of archives. After unpacking 0 B will be used. $ apt-get source monitoring-plugins Reading package lists... Done NOTICE: 'monitoring-plugins' packaging is maintained in the 'Git' version control system at: https://salsa.debian.org/nagios-team/pkg-monitoring-plugins.git Please use: git clone https://salsa.debian.org/nagios-team/pkg-monitoring-plugins.git to retrieve the latest (possibly unreleased) updates to the package. Skipping already downloaded file 'monitoring-plugins_2.2-6.dsc' Skipping already downloaded file 'monitoring-plugins_2.2.orig.tar.gz' Skipping already downloaded file 'monitoring-plugins_2.2-6.debian.tar.xz' Need to get 0 B of source archives. dpkg-source: info: extracting monitoring-plugins in monitoring-plugins-2.2 dpkg-source: info: unpacking monitoring-plugins_2.2.orig.tar.gz dpkg-source: info: unpacking monitoring-plugins_2.2-6.debian.tar.xz dpkg-source: info: using patch list from debian/patches/series dpkg-source: info: applying 02_check_icmp_links dpkg-source: info: applying 10_spell_fixes dpkg-source: warning: diff 'monitoring-plugins-2.2/debian/patches/10_spell_fixes' patches file monitoring-plugins-2.2/plugins-root/check_icmp.c more than once dpkg-source: info: applying 11_check_dhcp_MSG_PEAK dpkg-source: info: applying 12_check_apt_only_crit dpkg-source: info: applying 13_check_apt_list_packages dpkg-source: info: applying 14_mariadb dpkg-source: info: applying 15_check_smtp_initialize $ cd monitoring-plugins-2.2 .../monitoring-plugins-2.2$ fakeroot dpkg-buildpackage -b --no-sign Expected results: Successful build Actual results with monitoring-plugins_2.2-6.dsc ... dh_compress -s dh_compress: Compatibility levels before 9 are deprecated (level 5 in use) dh_compress: -s/--same-arch is deprecated; please use -a/--arch instead dh_compress: This feature will be removed in compat 12. gzip: usr/share/doc/monitoring-plugins-standard/changelog.gz: No such file or directory dh_compress: gzip -9nf usr/share/doc/monitoring-plugins-standard/changelog usr/share/doc/monitoring-plugins-standard/changelog.Debian returned exit code 1 gzip: usr/share/doc/monitoring-plugins-basic/changelog.gz: No such file or directory dh_compress: gzip -9nf usr/share/doc/monitoring-plugins-basic/changelog usr/share/doc/monitoring-plugins-basic/changelog.Debian returned exit code 1 dh_compress: Aborting due to earlier error make: *** [debian/rules:219: binary-arch] Error 25 dpkg-buildpackage: error: debian/rules binary-arch subprocess returned exit status 2 .../monitoring-plugins-2.2$ Actual results with a git checkout instead of the source package (HEAD tag is c852ee9514a8d5c9fc497a944c8d7e4801223dca): .../pkg-monitoring-plugins$ fakeroot dpkg-buildpackage -b --no-sign ... dh_compress -i gzip: usr/share/doc/monitoring-plugins/README.Debian.gz: No such file or directory gzip: usr/share/doc/monitoring-plugins/changelog.gz: No such file or directory dh_compress: gzip -9nf usr/share/doc/monitoring-plugins/README.Debian usr/share/doc/monitoring-plugins/changelog usr/share/doc/monitoring-plugins/changelog.Debian returned exit code 1 dh_compress: Aborting due to earlier error make: *** [debian/rules:199: binary-indep] Error 25 dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2 .../pkg-monitoring-plugins$ Note 1: System has been set up to also use the buster-backports repository for any packages there included. Note 2: The git repository source no longer uses compat 5, but same failure still happens -- System Information: Debian Release: 10.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable'), (500, 'oldstable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-10-amd64 (SMP w/2 CPU cores) Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), LANGUAGE=en_IE:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#972533: libsvm: debian/tests/python3-simple needs to depend on python3-all
Source: libsvm Version: 3.24+ds-5 Severity: normal User: debian-pyt...@lists.debian.org Usertags: python3.9 Dear Maintainer, The debian/tests/python3-simple test tests using all supported python3 versions but does not install them all. Cheers, mwh -- System Information: Debian Release: bullseye/sid APT prefers focal-updates APT policy: (500, 'focal-updates'), (500, 'focal-security'), (500, 'focal'), (400, 'focal-proposed'), (100, 'focal-backports') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.4.0-51-generic (SMP w/8 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_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
Bug#972532: liblinear: python3-simple autopkgtest needs to depend on python3-all
Here we go: https://salsa.debian.org/science-team/liblinear/-/merge_requests/1
Bug#972532: liblinear: python3-simple autopkgtest needs to depend on python3-all
Source: liblinear Version: 2.3.0+dfsg-4 Severity: normal User: debian-pyt...@lists.debian.org Usertags: python3.9 Dear Maintainer, The debian/tests/python3-simple test tests using all supported python3 versions but does not install them all. The fix is trivial and I will propose it on salsa momentarily. Cheers, mwh -- System Information: Debian Release: bullseye/sid APT prefers focal-updates APT policy: (500, 'focal-updates'), (500, 'focal-security'), (500, 'focal'), (400, 'focal-proposed'), (100, 'focal-backports') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.4.0-51-generic (SMP w/8 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_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
Bug#971645: sshfs: truncates timestamps to whole seconds
Dear Maintainer,
tried to track where the time is set/retrieved for a remote file
and came up with this location [1].
I am not sure if flag SSH_FILEXFER_ATTR_ACMODTIME/SSH2_FILEXFER_ATTR_ACMODTIME
is the only possible way ssh has to transfer the date, but at
least that way seems to just use 32 bits without the nano seconds.
Unfortunately the "has no historic wire protocols" might not be
completely true because sshfs relies on ssh, which shows a similar
limitation also with sftp/scp.
Kind regards,
Bernhard
[1]
(rr) bt
#0 0x55c9a06ba46b in buf_get_attrs (buf=0x7f994b5d6b50,
stbuf=, flagsp=) at ../sshfs.c:912
#1 0x55c9a06bfe66 in sshfs_getattr (path=,
stbuf=0x7f994b5d6c80, fi=) at ../sshfs.c:3393
#2 0x55c9a06c184d in cache_getattr (fi=0x0, stbuf=0x7f994b5d6c80,
path=0x7f993c000c30 "/.bash_history") at ../cache.c:272
#3 cache_getattr (path=0x7f993c000c30 "/.bash_history",
stbuf=0x7f994b5d6c80, fi=0x0) at ../cache.c:266
#4 0x7f994c67a557 in lookup_path (f=0x55c9a07270e0, nodeid=1,
name=0x7f994a9d5038 ".bash_history", path=, e=0x7f994b5d6c70,
fi=) at ../lib/fuse.c:2537
#5 0x7f994c67a66b in fuse_lib_lookup (req=0x7f993c000b60, parent=1,
name=) at ../lib/fuse.c:2725
#6 0x7f994c687a83 in fuse_session_process_buf_int (se=0x55c9a07274b0,
buf=buf@entry=0x7f9944000b80, ch=) at ../lib/fuse_lowlevel.c:2666
#7 0x7f994c683393 in fuse_do_work (data=0x7f9944000b60) at
../lib/fuse_loop_mt.c:163
#8 0x7f994c655ea7 in start_thread (arg=) at
pthread_create.c:477
#9 0x7f994c456d4f in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:95
866 if ((flags & SSH_FILEXFER_ATTR_ACMODTIME)) {
867 if (buf_get_uint32(buf, ) == -1 ||
868 buf_get_uint32(buf, ) == -1)
...
912 stbuf->st_ctime = stbuf->st_mtime = mtime;
[2]
benutzer@debian:~$ touch --date="2260-10-18 00:00:00.123456789"
/tmp/future-test-a
benutzer@debian:~$ scp -p benutzer@localhost:/tmp/future-test-a
/tmp/future-test-c
benutzer@localhost's password:
future-test-a
100%0 0.0KB/s 00:00
benutzer@debian:~$ sftp -p benutzer@localhost:/tmp/future-test-a
/tmp/future-test-b
benutzer@localhost's password:
Connected to localhost.
Fetching /tmp/future-test-a to /tmp/future-test-b
benutzer@debian:~$ ls -lisah --full-time /tmp/future-test*
70 0 -rw-r--r-- 1 benutzer benutzer 0 2260-10-18 00:00:00.123456789 +0200
/tmp/future-test-a
74 0 -rw-r--r-- 1 benutzer benutzer 0 1988-08-04 11:03:28.0 +0200
/tmp/future-test-b
73 0 -rw-r--r-- 1 benutzer benutzer 0 2260-10-18 00:00:00.0 +0200
/tmp/future-test-c
Bug#972531: genshi: incompatible with Python 3.9
Source: genshi Version: 0.7.3-2 Severity: normal Tags: upstream User: debian-pyt...@lists.debian.org Usertags: python3.9 Forwarded-To: https://github.com/edgewall/genshi/issues/23 Dear Maintainer, Python 3.9 is now a supported version in unstable, and genshi's autopkgtests now fail. Cheers, mwh -- System Information: Debian Release: bullseye/sid APT prefers focal-updates APT policy: (500, 'focal-updates'), (500, 'focal-security'), (500, 'focal'), (400, 'focal-proposed'), (100, 'focal-backports') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.4.0-51-generic (SMP w/8 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_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
Bug#972530: feature-check: debian/tests/tap-python.sh needs to depend on python3-all
Here we go: https://salsa.debian.org/roam/feature-check/-/merge_requests/1
Bug#972529: ecflow: debian/tests/control needs to depend on python3-all
Also the git repo on salsa seems to be a couple of uploads out of date, or I'd propose the change there. On Tue, 20 Oct 2020 at 12:57, Michael Hudson-Doyle < michael.hud...@ubuntu.com> wrote: > Source: ecflow > Version: 5.5.3-3 > Severity: normal > User: debian-pyt...@lists.debian.org > Usertags: python3.9 > > Dear Maintainer, > > Now that the extension module is built for all supported python 3 > releases, the next problem is that the autopkgtest tests for all python > 3 releases but does install them... > > Cheers, > mwh > > -- System Information: > Debian Release: bullseye/sid > APT prefers focal-updates > APT policy: (500, 'focal-updates'), (500, 'focal-security'), (500, > 'focal'), (400, 'focal-proposed'), (100, 'focal-backports') > Architecture: amd64 (x86_64) > Foreign Architectures: i386 > > Kernel: Linux 5.4.0-51-generic (SMP w/8 CPU cores) > Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_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 >
Bug#971449: mutool exits with successful status on failure w/ no OpenSSL
Control: block -1 by 969301 > This probably needs fixing upstream regardless, but if MuPDF can > be built with OpenSSL 3 when it's ready that'd also be suitable > to close this bug. Per the FTP team's decision today, it seems MuPDF won't need to wait for Apache-licensed OpenSSL to build with it. It still stands that the incorrect exit status should be fixed for non-OpenSSL builds however. signature.asc Description: This is a digitally signed message part.
Bug#972530: feature-check: debian/tests/tap-python.sh needs to depend on python3-all
Source: feature-check Version: 0.2.2-5 Severity: normal User: debian-pyt...@lists.debian.org Usertags: python3.9 Dear Maintainer, Now that python3.9 is a supported python 3 version in unstable, the tap-python.sh test is failing: it runs the tests with all supported python 3 versions but does not install them. The change is trivial and I'll propose it on salsa imminently. Cheers, mwh -- System Information: Debian Release: bullseye/sid APT prefers focal-updates APT policy: (500, 'focal-updates'), (500, 'focal-security'), (500, 'focal'), (400, 'focal-proposed'), (100, 'focal-backports') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.4.0-51-generic (SMP w/8 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_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
Bug#972455: Does not compile for Linux 5.9
Control: tag -1 + patch - moreinfo unreproducible
Hi Sven,
Sven Hartge wrote:
> Um 19:54 Uhr am 19.10.20 schrieb Sven Hartge:
> > If I add the switch "-B" to the make command in gen_compat_def I can
> > reliably get the test to work correctly even on the systems with the older
> > filesystem:
> >
> >cmd="make -s -B -C $KDIR M=$PWD modules"
>
> I locally rebuild the iptables-netflow packages with the attached patch
> applied and this fixes this problem for me.
Thanks for digging that deep. I must admit that I so far never ran
into this kind of problem despite I consider my systems to have quite
some history, too. Bust most installations are nevertheless not older
than mid-2000s. (One excpetion, but there I'm bound to Debian 8 Jessie
as libc and kernel unfortunately kicked out Pentium I support with
Debian 9 Stretch.)
> (This is like #631245 all over again.)
Oh, one of my packages (now), too. Marked as fixed, but not yet
closed. Hmmm. Do you think we can close this now? Lynx no more uses
the alternatives system besides /usr/bin/www-browser and we've cleaned
up that multiple lynx packages mess we had in the past.
> --- a/gen_compat_def
> +++ b/gen_compat_def
> @@ -26,7 +26,7 @@
>
>cat > test.c
>echo obj-m = test.o > Makefile
> - cmd="make -s -C $KDIR M=$PWD modules"
> + cmd="make -s -B -C $KDIR M=$PWD modules"
>echo "$cmd" > log
>if $cmd >> log 2>&1; then
> [ "$2" ] && echo "// $2 is declared ${3:+in <$3>}"
Will apply that patch in the next upload.
"-B" is a rather hefty switch, but inside a test it should still be
ok.
Mind submitting a pull request for this upstream at
https://github.com/aabc/ipt-netflow? You are likely better in
explaining the whole background of this patch and we would not have
Chinese whispers when I'd be relaying potential arguments between you
and upstream.
Regards, Axel
--
,''`. | Axel Beckert , https://people.debian.org/~abe/
: :' : | Debian Developer, ftp.ch.debian.org Admin
`. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5
`-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#972529: ecflow: debian/tests/control needs to depend on python3-all
Source: ecflow Version: 5.5.3-3 Severity: normal User: debian-pyt...@lists.debian.org Usertags: python3.9 Dear Maintainer, Now that the extension module is built for all supported python 3 releases, the next problem is that the autopkgtest tests for all python 3 releases but does install them... Cheers, mwh -- System Information: Debian Release: bullseye/sid APT prefers focal-updates APT policy: (500, 'focal-updates'), (500, 'focal-security'), (500, 'focal'), (400, 'focal-proposed'), (100, 'focal-backports') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.4.0-51-generic (SMP w/8 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_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
Bug#956591: gpick: please make the build reproducible
On Thu, Oct 15, 2020 at 04:55:03PM -, Chris Lamb wrote: > I don't actually use reprotest myself, so I can't help you specifically here. > Probably best to contact the rb-gene...@lists.reproducible-builds.org mailing > list.j > Ok. I'll send an email. Best regards, Elías Alejandro
Bug#972528: ctdopts: incompatible with Python 3.9
Source: ctdopts Version: 1.4-1 Severity: normal Tags: upstream User: debian-pyt...@lists.debian.org Usertags: python3.9 Forwarded: https://github.com/WorkflowConversion/CTDopts/pull/25 Dear Maintainer, The autopkgtests fail with Python 3.9. It appears to be a simple fix which I have already proposed upstream. Cheers, mwh -- System Information: Debian Release: bullseye/sid APT prefers focal-updates APT policy: (500, 'focal-updates'), (500, 'focal-security'), (500, 'focal'), (400, 'focal-proposed'), (100, 'focal-backports') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.4.0-51-generic (SMP w/8 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_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
Bug#972404: transition: KDEPIM 20.08 and Frameworks 5.74.0
Control: severity 972224 serious Control: severity 972226 serious Hey, I uploaded Frameworks 5.74.0 and KDEPIM 20.08 completely, so you can do the binNMUs. hefee -- On Sonntag, 18. Oktober 2020 12:39:20 CEST Sebastian Ramacher wrote: > Control: forwarded -1 > https://release.debian.org/transitions/html/kdepim-20.08.html Control: tags > -1 + confirmed > > On 2020-10-18 01:35:12 +0200, Sandro Knauß wrote: > > Package: release.debian.org > > User: release.debian@packages.debian.org > > Usertags: transition > > X-Debbugs-Cc: pkg-kde-t...@alioth-lists.debian.net > > Severity: normal > > Control: Block -1 by 972224 972226 > > > > Dear Release team, > > > > We would like to request a transition for KDEPIM 20.08 and Frameworks > > 5.74.0. We request both in one shot, because KDEPIM depends on the new > > Frameworks, so we need to upload Frameworks anyways. For Framework in > > itself no transition is needed, as it gives ABI stability, that is not > > broken. But this time KDAV has moved from KDEPIM to KDE Frameworks. And > > inside KDEPIM there was no ABI stability, that's why we need to binNMU > > for packages depending on libkf5dav5. In this case it is only > > kdepim-runtime that is part of KDEPIM, what is the reason why I think we > > shoud upload KDEPIM and Frameworks together. > > > > Outside KDEPIM and KDE Frameworks there are only some other packages, that > > needs a normal binNMU. Additionally KDEPIM 20.08 removed 4 libraries: > > * libkf5libkdepimakonadi5 > > * libkf5followupreminder5 > > * libkf5kdepimdbusinterfaces5 > > * libkf5followupreminder5 > > > > I checked the packages the need a binNMU, if they build successfully or > > filed issues when not. The complete list of packages outside KDEPIM and > > Frameworks are: > > > > * digikam > > * kgpg > > * kio-gdrive > > > > * kjots (#972226) MR is already provided: > >https://salsa.debian.org/qt-kde-team/extras/kjots/-/merge_requests/1 > > > > * kmymoney > > * kraft > > > > * zanshin (#972224) MR is already provided: > > https://salsa.debian.org/qt-kde-team/extras/zanshin/-/merge_requests/2 > > > > > >From my side every is ready for the transition. > > Trackers are at > https://release.debian.org/transitions/html/kdepim-20.08.html and > https://release.debian.org/transitions/html/kdav.html > > Please go ahead with the uploads to unstable. > > Cheers > > > hefee > > > > Here is the ben file that is based on one from the previous transition: > > https://salsa.debian.org/release-team/transition-data/-/blob/master/old/kd > > epim-20.04.ben > > > > Ben file: > > > > title = "KDEPIM 20.08"; > > is_affected = .depends ~ > > /libkf.*-20\.04|libkf5libkdepimakonadi5|libkf5followupreminder5|libkf5kde > > pimdbusinterfaces5|libkf5followupreminder5/ | .depends ~ /libk.*-20\.08/; > > is_good = .depends ~ /libk.*-20\.08/; > > is_bad = .depends ~ > > /libkf.*-20\.04|libkf5libkdepimakonadi5|libkf5followupreminder5|libkf5kde > > pimdbusinterfaces5|libkf5followupreminder5/; > > > > title = "KDAV moved to Frameworks 5.74.0" > > is_affected = .depends ~ /libkf5dav5/; > > is_good = .depends ~ /libkf5dav5 \(>= 1:5\.74/; > > is_bad = .depends ~ /libkf.*-20\.04/; signature.asc Description: This is a digitally signed message part.
Bug#924937: OpenSSL license contamination of GPL reverse-dependencies
On Wed, 27 Mar 2019 11:04:30 +0100 Christoph Berg wrote:> Re: Ansgar Burchardt 2019-03-20 <751a89074fcaa393f2cc26ff676e9e3434ecd706.ca...@43-1.org> > > the OpenSSL ./. GPL problem (if one sees it as a problem) is larger > > than just libpq5: just looking at a small sample of the direct rdeps of > > libssl1.1, one can find the following GPL-licensed programs linking it: > > > > cryptsetup, wesnoth, mydumper, mupdf, gatling, kopete > > > > Also amanda-client, validns as they contain patches in d/patches > > licensed under the GPL. > > > > There are probably lots more, especially when you start looking at > > libraries (and their whole dependency trees). > > > > There is also cups which was reported to switch to Apache-2 which is > > also GPL-2-incompatible... That has lots of rdeps too (including for > > example all GTK applications). > > > > Fedora treats OpenSSL as a "system library"[1]. I would guess they > > might do the same for libcups too. > > > > Ansgar > > > > [1] > > https://fedoraproject.org/wiki/Licensing:FAQ#What.27s_the_deal_with_the_OpenSSL_license.3F > > Reassigning to ftp-master to get an answer on if this is a problem for > Debian, or if we can invoke the system library exception, or other > resolutions. > > Christoph OpenSSL, cups, and libgcc are considered system libraries now: http://meetbot.debian.net/debian-ftp/2020/debian-ftp.2020-03-13-20.02.html. I guess this issue can be closed.
Bug#969648: dask, pandas 1.1
On 19/10/2020 20:07, Stefano Rivera wrote: Hi Rebecca (2020.10.19_11:51:33_-0700) Or maybe not an actual regression...it's a ~5e-7 difference and one of the things the patch does (at around dask/dataframe/tests/test_rolling.py:270) is _tighten_ the tolerance on that test. Hrm, I didn't see that failure. Testing again on a 32bit arch to be sure... My log is from amd64, but I don't know if it's reproducible.
Bug#972526: mutagen: dep8 tests need to depend on python3-all
Source: mutagen Version: 1.45.1-1 Severity: normal Tags: patch Dear Maintainer, mutagen's autopkgtests fail with the python3-defaults in unstable because the tests are run with all supported python3 versions but only the default is installed. It's an easy fix. Cheers, mwh -- System Information: Debian Release: bullseye/sid APT prefers focal-updates APT policy: (500, 'focal-updates'), (500, 'focal-security'), (500, 'focal'), (400, 'focal-proposed'), (100, 'focal-backports') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.4.0-51-generic (SMP w/8 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_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
Bug#969648: dask, pandas 1.1
Or maybe not an actual regression...it's a ~5e-7 difference and one of the things the patch does (at around dask/dataframe/tests/test_rolling.py:270) is _tighten_ the tolerance on that test. I have filed a separate bug (#972516) for the fsspec issues.
Bug#972516: dask: fsspec API changes / new aiohttp dependency
Package: python3-dask
Version: 2.11.0+dfsg-1
Some of fsspec's functionality now requires python3-aiohttp, including
parts used in dask autopkgtests:
https://ci.debian.net/data/autopkgtest/testing/amd64/d/dask/7549002/log.gz
Some of these work if I add a test-dependency, but 2 continue to fail.
Upstream fixes:
https://github.com/dask/dask/commit/024f690b6d269c11a496db088c4ddd8d5de12a49
https://github.com/dask/dask/commit/416d348f7174a302815758cb87dbf6983226ddc5
_ test_errors
__
dir_server = '/tmp/tmpt3k96rrg'
def test_errors(dir_server):
f = open_files("http://localhost:8999/doesnotexist;)[0]
with pytest.raises(requests.exceptions.RequestException):
with f as f:
> f.read()
/usr/lib/python3/dist-packages/dask/bytes/tests/test_http.py:117:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _
/usr/lib/python3/dist-packages/fsspec/implementations/http.py:343: in read
self._fetch_all()
/usr/lib/python3/dist-packages/fsspec/asyn.py:121: in wrapper
return maybe_sync(func, self, *args, **kwargs)
/usr/lib/python3/dist-packages/fsspec/asyn.py:100: in maybe_sync
return sync(loop, func, *args, **kwargs)
/usr/lib/python3/dist-packages/fsspec/asyn.py:71: in sync
raise exc.with_traceback(tb)
/usr/lib/python3/dist-packages/fsspec/asyn.py:55: in f
result[0] = await future
/usr/lib/python3/dist-packages/fsspec/implementations/http.py:360: in
async_fetch_all
r.raise_for_status()
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _
self = http://localhost:8999/doesnotexist) [404 File not
found]>
GMT', 'Connection': 'close', 'Content-Type': 'text/html;charset=utf-8',
'Content-Length': '469')>
def raise_for_status(self) -> None:
if 400 <= self.status:
# reason should always be not None for a started response
assert self.reason is not None
self.release()
> raise ClientResponseError(
self.request_info,
self.history,
status=self.status,
message=self.reason,
headers=self.headers)
E aiohttp.client_exceptions.ClientResponseError: 404,
message='File not found', url=URL('http://localhost:8999/doesnotexist')
/usr/lib/python3/dist-packages/aiohttp/client_reqrep.py:941:
ClientResponseError
- Captured stderr call
-
127.0.0.1 - - [19/Oct/2020 18:05:00] code 404, message File not found
127.0.0.1 - - [19/Oct/2020 18:05:00] "HEAD /doesnotexist HTTP/1.1" 404 -
127.0.0.1 - - [19/Oct/2020 18:05:00] code 404, message File not found
127.0.0.1 - - [19/Oct/2020 18:05:00] "GET /doesnotexist HTTP/1.1" 404 -
test_urlpath_inference_errors
_
def test_urlpath_inference_errors():
# Empty list
with pytest.raises(ValueError, match="empty"):
get_fs_token_paths([])
# Protocols differ
with pytest.raises(ValueError, match="the same protocol"):
get_fs_token_paths(["s3://test/path.csv", "/other/path.csv"])
# Options differ
with pytest.raises(ValueError, match="the same file-system
options"):
get_fs_token_paths(
[
"ftp://myu...@node.com/test/path.csv;,
"ftp://otheru...@node.com/other/path.csv;,
]
)
# Unknown type
with pytest.raises(TypeError):
> get_fs_token_paths(
{
"sets/are.csv",
"unordered/so/they.csv",
"should/not/be.csv",
"allowed.csv",
}
)
E Failed: DID NOT RAISE
/usr/lib/python3/dist-packages/dask/bytes/tests/test_local.py:86: Failed
Bug#969648: dask, pandas 1.1
I have now tested it. (The dask tests are run in autopkgtest, not build.)
The attached is what I have so far, but it had these failures. The
first two happen with or without 969648.patch and (from debci results)
appear to be triggered by the new fsspec, but the last is a *regression*
caused by this patch.
=== FAILURES
===
_ test_errors
__
dir_server = '/tmp/tmpuxg_g6b8'
def test_errors(dir_server):
f = open_files("http://localhost:8999/doesnotexist;)[0]
with pytest.raises(requests.exceptions.RequestException):
with f as f:
> f.read()
/usr/lib/python3/dist-packages/dask/bytes/tests/test_http.py:117:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _
/usr/lib/python3/dist-packages/fsspec/implementations/http.py:343: in read
self._fetch_all()
/usr/lib/python3/dist-packages/fsspec/asyn.py:121: in wrapper
return maybe_sync(func, self, *args, **kwargs)
/usr/lib/python3/dist-packages/fsspec/asyn.py:100: in maybe_sync
return sync(loop, func, *args, **kwargs)
/usr/lib/python3/dist-packages/fsspec/asyn.py:71: in sync
raise exc.with_traceback(tb)
/usr/lib/python3/dist-packages/fsspec/asyn.py:55: in f
result[0] = await future
/usr/lib/python3/dist-packages/fsspec/implementations/http.py:360: in
async_fetch_all
r.raise_for_status()
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _
self = http://localhost:8999/doesnotexist) [404 File not
found]>
GMT', 'Connection': 'close', 'Content-Type': 'text/html;charset=utf-8',
'Content-Length': '469')>
def raise_for_status(self) -> None:
if 400 <= self.status:
# reason should always be not None for a started response
assert self.reason is not None
self.release()
> raise ClientResponseError(
self.request_info,
self.history,
status=self.status,
message=self.reason,
headers=self.headers)
E aiohttp.client_exceptions.ClientResponseError: 404,
message='File not found', url=URL('http://localhost:8999/doesnotexist')
/usr/lib/python3/dist-packages/aiohttp/client_reqrep.py:941:
ClientResponseError
- Captured stderr call
-
127.0.0.1 - - [19/Oct/2020 17:38:10] code 404, message File not found
127.0.0.1 - - [19/Oct/2020 17:38:10] "HEAD /doesnotexist HTTP/1.1" 404 -
127.0.0.1 - - [19/Oct/2020 17:38:10] code 404, message File not found
127.0.0.1 - - [19/Oct/2020 17:38:10] "GET /doesnotexist HTTP/1.1" 404 -
test_urlpath_inference_errors
_
def test_urlpath_inference_errors():
# Empty list
with pytest.raises(ValueError, match="empty"):
get_fs_token_paths([])
# Protocols differ
with pytest.raises(ValueError, match="the same protocol"):
get_fs_token_paths(["s3://test/path.csv", "/other/path.csv"])
# Options differ
with pytest.raises(ValueError, match="the same file-system
options"):
get_fs_token_paths(
[
"ftp://myu...@node.com/test/path.csv;,
"ftp://otheru...@node.com/other/path.csv;,
]
)
# Unknown type
with pytest.raises(TypeError):
> get_fs_token_paths(
{
"sets/are.csv",
"unordered/so/they.csv",
"should/not/be.csv",
"allowed.csv",
}
)
E Failed: DID NOT RAISE
/usr/lib/python3/dist-packages/dask/bytes/tests/test_local.py:86: Failed
__ test_time_rolling_methods[window3-std-args6-True]
___
method = 'std', args = (), window = <5 * Seconds>, check_less_precise = {}
@pytest.mark.parametrize(
"method,args,check_less_precise",
rolling_method_args_check_less_precise
)
@pytest.mark.parametrize("window", ["1S", "2S", "3S",
pd.offsets.Second(5)])
def test_time_rolling_methods(method, args, window,
check_less_precise):
if dd._compat.PANDAS_GT_110:
check_less_precise = {}
else:
check_less_precise = {"check_less_precise": check_less_precise}
# DataFrame
if method == "apply":
kwargs = {"raw": False}
else:
kwargs = {}
prolling = ts.rolling(window)
drolling = dts.rolling(window)
> assert_eq(
getattr(prolling, method)(*args, **kwargs),
getattr(drolling, method)(*args, **kwargs),
**check_less_precise,
)
/usr/lib/python3/dist-packages/dask/dataframe/tests/test_rolling.py:288:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Bug#967896: (no subject)
Same issue here on HP Envy x360 cn1002ng with Intel WiFi-AC 9560. Similar to other reports, neither approach of providing different versions of the requested drivers works.
Bug#970111: enigmail: Upgrade to migration version 2.2.x for Thunderbird 78
On Tue, 6 Oct 2020 13:04:24 +0200 Gregor Riepl wrote: > Thunderbird 78.3.1 is now in unstable, and without Enigmail 2.2, > existing users may lose their existing configuration. > > Please consider uploading the migration wizard (i.e. Enigmail 2.2) as > soon as possible. enigmail seems to be the only package keeping thunderbird from migrating to testing. I second the asap request.
Bug#971645: sshfs: truncates timestamps to whole seconds
On Mon, Oct 19, 2020 at 10:52:45PM +0200, Bernhard Übelacker wrote: > Dear Maintainer, > tried to track where the time is set/retrieved for a remote file > and came up with this location [1]. > > I am not sure if flag SSH_FILEXFER_ATTR_ACMODTIME/SSH2_FILEXFER_ATTR_ACMODTIME > is the only possible way ssh has to transfer the date, but at > least that way seems to just use 32 bits without the nano seconds. > > Unfortunately the "has no historic wire protocols" might not be > completely true because sshfs relies on ssh, which shows a similar > limitation also with sftp/scp. Looks like I've misread something, and such historic wire protocols indeed exist for sftp (which sshfs uses). On the other hand, they're long-expired drafts of the protocol. The granularity was 1s up to Draft 03: https://tools.ietf.org/html/draft-ietf-secsh-filexfer-03 then changed to 1ns if SSH_FILEXFER_ATTR_SUBSECOND_TIMES is defined, in Draft 04: https://tools.ietf.org/html/draft-ietf-secsh-filexfer-04 Thus, using that flag will stop timestamp truncation. (Well, programs that can't cope with truncated timestamps are buggy, but...) I have no idea if there are servers based on old drafts in the wild. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ in the beginning was the boot and root floppies and they were good. ⢿⡄⠘⠷⠚⠋⠀ -- on #linux-sunxi ⠈⠳⣄
Bug#972172: Removed package(s) from unstable
Hello, Am 19.10.20 um 23:33 schrieb Debian FTP Masters: > We believe that the bug you reported is now fixed; the following > package(s) have been removed from unstable: > > libnb-absolutelayout-java | 12.1-1 | all > libnb-apisupport3-java | 10.0-3 | all > libnb-ide14-java | 10.0-3 | all > libnb-java5-java | 10.0-3 | all > netbeans | 10.0-3 | source, all > netbeans | 12.1-1 | source > > --- Reason --- > NBS; no longer viable to maintain in Debian > -- I only requested that the obsolete binary packages got removed from unstable because libnb-absolutelayout-java, the only remaining binary package, did not migrate to testing. It appears you just removed the complete source package src:netbeans. How can we fix this? Regards, Markus signature.asc Description: OpenPGP digital signature
Bug#972525: buildd: sbuild randomly fails to sign changes file despite valid signature keys
Source: sbuild Version: 0.80.0 Severity: normal User: debian-sp...@lists.debian.org Usertags: sparc64 Hi! I'm observing random failures of sbuild signing the changes file after build on some buildds, especially on sparc64 and most often on the machine sompek. I'm not sure yet what the problem is but it looks like a GPG problem [1]: gpg: can't connect to the agent: IPC connect call failed gpg: keydb_search failed: No agent running gpg: skipped "F1EA40F487003E5047A04D0A62D1430FE7E0DE86": No agent running gpg: /tmp/debsign.oB0Milcr/rust-kstring_1.0.0-1_sparc64.changes: clear-sign failed: No agent running debsign: gpg error occurred! Aborting I'm filing this issue here to get some attention and maybe some ideas where the problem could be. Maybe sbuild should wait a little longer before attempting to sign? Or maybe the GPG daemon is crashing often? In case it's safe not to be an issue with buildd/sbuild, feel free to reassign. Thanks, Adrian > [1] > https://buildd.debian.org/status/fetch.php?pkg=rust-kstring=sparc64=1.0.0-1=1603142545=0 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#972394: likely cause: Python.h not found because of version mismatch 3.8 vs 3.9
Am 19.10.20 um 23:33 schrieb Joachim Wuttke: > Markus: > > Further investigation shows that the problem is not with NumPy. > CMake not even finds Python.h. > > The problem is most likely a mixture of Python 3.8 and 3.9 files on your > system. > > Try to uninstall libpython3-dev, which still depends on 3.8. > > Good luck, Joachim I built siconos in a clean chroot environment. The recent rebuild of siconos also shows build failures https://buildd.debian.org/status/package.php?p=siconos I don't think it's specific to my environment. Cheers, Markus signature.asc Description: OpenPGP digital signature
Bug#972394: likely cause: Python.h not found because of version mismatch 3.8 vs 3.9
Markus: Further investigation shows that the problem is not with NumPy. CMake not even finds Python.h. The problem is most likely a mixture of Python 3.8 and 3.9 files on your system. Try to uninstall libpython3-dev, which still depends on 3.8. Good luck, Joachim smime.p7s Description: S/MIME Cryptographic Signature
Bug#972394: got same error in other project
Hi Joachim, Am 19.10.20 um 23:15 schrieb Joachim Wuttke: > Hi Markus, > > I confirm that this is a serious issue. > > I got the same error message > > Could NOT find Python3 (missing: Python3_INCLUDE_DIRS Python3_LIBRARIES > Development NumPy Development.Module Development.Embed) (found version > "3.9.0") at first I just thought the package is missing a build-dependency on python3. > in a completely different software project after I dist-upgraded my Debian/ > testing system. That upgrade did not affect my cmake, which I compile > myself (version 3.18.20200714-g2da7786-dirty). However, the upgrade did > change numerous Python3 packages, among them > > python3-numpy:amd64 (1:1.19.1-1, 1:1.19.2-2+b1) > > but not python3-dev. So my guess is the problem is a change in > python3-numpy > that breaks CMake's > > find_package(Python3 COMPONENTS Development NumPy) > > command. > > Accordingly, I will report the bug to python3-numpy. Ok, that sounds reasonable. I just stumbled upon this issue while rebuilding your package, feel free to reassign or address it as you see fit. Regards, Markus signature.asc Description: OpenPGP digital signature
Bug#972523: sogo: New upstream version available
Source: sogo Version: sogo/4.3.2-1 Hi, The new upstream version 5.0.1 is available. Please consider packaging it. This will also take care of #932081 for bullseye.
Bug#972394: got same error in other project
Hi Markus, I confirm that this is a serious issue. I got the same error message Could NOT find Python3 (missing: Python3_INCLUDE_DIRS Python3_LIBRARIES Development NumPy Development.Module Development.Embed) (found version "3.9.0") in a completely different software project after I dist-upgraded my Debian/ testing system. That upgrade did not affect my cmake, which I compile myself (version 3.18.20200714-g2da7786-dirty). However, the upgrade did change numerous Python3 packages, among them python3-numpy:amd64 (1:1.19.1-1, 1:1.19.2-2+b1) but not python3-dev. So my guess is the problem is a change in python3-numpy that breaks CMake's find_package(Python3 COMPONENTS Development NumPy) command. Accordingly, I will report the bug to python3-numpy. Regards, Joachim smime.p7s Description: S/MIME Cryptographic Signature
Bug#972428: anymeal FTCBFS: abuses AC_CHECK_FILE
On Mon, 19 Oct 2020, Boyuan Yang wrote: Hi, 在 2020-10-19星期一的 18:33 +0100，Jan Wedekind写道： Hi Boyuan, hi Helmut, I have incorporated the bug fixes for cross-platform build. I also have made other changes in the meantime. Boyuan, can you please upload the new version to Debian unstable. You can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/a/anymeal/anymeal_1.10-1.dsc Kind regards Jan Wedekind It's now uploaded. Best, Boyuan Yang Hi Boyuan, Thank you for reviewing and uploading. Kind regards Jan
Bug#594573: Translation Anymeal to Russian
Hi, The translation would need updating anyway, because I did a lot of changes to the user interface. Regards Jan On Mon, 19 Oct 2020, tony mancill wrote: Hello, On Mon, Oct 19, 2020 at 04:01:37PM +0300, Сергей Савин wrote: Hello. I don't have a copy. I have checked and the most recent build of anymeal I have is from an upload in May of 2008 (0.30-7), and I can't find a copy of the patch on my system. I apologize for dropping the ball on this. tony 19.10.2020 03:42, Paul Wise пишет: On Tue, Aug 24, 2010 at 20:34, Sergey Savin wrote: I've translated program Anymeal from Debian lenny repository to Russian. I send you ru.po file. Please, include it to the package anymeal in debian lenny repository. Sergey, your Russian translation of Anymeal appears to have been lost. If you do not have a copy of the translation, please let us know. If you do have a copy of the translation: If you have a GitHub account, please update it for the latest version and file an issue requesting it be included into the upstream project. https://github.com/wedesoft/anymeal/issues Otherwise, you could attach it to a mail and send to the Debian bug: 594...@bugs.debian.org PS: the bug that was filed about your translation is available here: https://bugs.debian.org/594573
Bug#952868: OpenSSL linking without license exception
Am 19.10.20 um 22:42 schrieb Michael Biebl: > On Sun, 1 Mar 2020 13:14:49 +0100 Bastian Germann > wrote: >> Package: wesnoth >> Severity: serious >> >> This GPL2 package links with OpenSSL. The OpenSSL license is >> incompatible with the GPL (see >> https://ftp-master.debian.org/REJECT-FAQ.html). This can be solved by >> asking upstream to add a license exception or by linking with wolfSSL >> instead. You can find a patch enclosed (untested). > > This patch is not strictly needed anymore, given that OpenSSL is now > considered a system library, i.e. doesn't require a license exception in > wesnoth. > > See > http://meetbot.debian.net/debian-ftp/2020/debian-ftp.2020-03-13-20.02.html > See also https://salsa.debian.org/ftp-team/website/-/merge_requests/6 signature.asc Description: OpenPGP digital signature
Bug#951854: fixed in muchsync 5-2
Am 19.10.20 um 22:40 schrieb Michael Biebl: > See > http://meetbot.debian.net/debian-ftp/2020/debian-ftp.2020-03-13-20.02.html See also https://salsa.debian.org/ftp-team/website/-/merge_requests/6 signature.asc Description: OpenPGP digital signature
Bug#951854: fixed in muchsync 5-2
On Mon, 24 Feb 2020 22:09:01 + Debian FTP Masters wrote: > muchsync (5-2) unstable; urgency=medium > . >* Links with wolfssl instead of libcrypto, fix: > "OpenSSL linking without license exception", thanks to Bastian Germann > (Closes: #951854). This patch is not needed anymore, given that OpenSSL is now considered a system library, i.e. doesn't require a license exception in muchsync. See http://meetbot.debian.net/debian-ftp/2020/debian-ftp.2020-03-13-20.02.html It's obviously your choice, if you want to continue to ship this patch and use libwolfssl. Regards, Michael signature.asc Description: OpenPGP digital signature
Bug#952868: OpenSSL linking without license exception
On Sun, 1 Mar 2020 13:14:49 +0100 Bastian Germann wrote: > Package: wesnoth > Severity: serious > > This GPL2 package links with OpenSSL. The OpenSSL license is > incompatible with the GPL (see > https://ftp-master.debian.org/REJECT-FAQ.html). This can be solved by > asking upstream to add a license exception or by linking with wolfSSL > instead. You can find a patch enclosed (untested). This patch is not strictly needed anymore, given that OpenSSL is now considered a system library, i.e. doesn't require a license exception in wesnoth. See http://meetbot.debian.net/debian-ftp/2020/debian-ftp.2020-03-13-20.02.html It's obviously your choice, if you want to continue to ship this patch and use libwolfssl (although I think OpenSSL is much more battle tested). Regards, Michael signature.asc Description: OpenPGP digital signature
Bug#963699: libpq5: OpenSSL license contamination of GPL reverse-dependencies
Am 19.10.20 um 22:36 schrieb Michael Biebl: > OpenSSL is now considered a system library in Debian, see > http://meetbot.debian.net/debian-ftp/2020/debian-ftp.2020-03-13-20.02.html > i.e. now such license exception is needed anymore. See also https://salsa.debian.org/ftp-team/website/-/merge_requests/6 signature.asc Description: OpenPGP digital signature
Bug#963699: libpq5: OpenSSL license contamination of GPL reverse-dependencies
On Mon, 18 Mar 2019 16:58:01 + Robie Basak wrote: > Package: libpq5 > Version: 11.2-2 > Severity: serious > Affects: bandwidthd-pgsql dballe inspircd libnss-pgsql2 libodb-pgsql-2.4 > pmacct r-cran-rpostgresql saga sphinxsearch tora ulogd2-pgsql yubikey-server-c > Justification: renders many Debian packages undistributable > > Hello, > > It's come to my attention that in buster and unstable, packages which > build-depend on libpq-dev wind up linked against libpq5, which in turn > links against OpenSSL (libssl1.1). > > This includes software which is licensed under the GPL and uses the > PostgreSQL APIs. > > It is well understood that the OpenSSL license is not "compatible" with > the GPL (either version 2 or 3); and furthermore, Debian has long taken > the position that, unless a license exception is granted by the > copyright holders, a package which is distributed under the GPL must > only link to libraries whose licenses are also GPL-compatible in order > for it to be included in Debian. OpenSSL is now considered a system library in Debian, see http://meetbot.debian.net/debian-ftp/2020/debian-ftp.2020-03-13-20.02.html i.e. now such license exception is needed anymore. Given that OpenSSL is much more battle tested then WolfSSL, I'd say Postgresql should stick with it and not switch. Regards, Michael signature.asc Description: OpenPGP digital signature
Bug#971976: libtraceevent-dev: please build from git.kernel.org/pub/scm/libs/libtrace/libtraceevent.git
Hi Ben, On Mon, Oct 12, 2020 at 05:26:37PM +0100, Ben Hutchings wrote: > On Sat, 2020-10-10 at 23:25 +0100, Sudip Mukherjee wrote: > > Source: linux > > Severity: wishlist > > X-Debbugs-Cc: b...@decadent.org.uk, debian-ker...@lists.debian.org > > > > Hi, > > > > This is similar to #948041 and libtraceevent now lives in its own repo > > at git.kernel.org/pub/scm/libs/libtrace/libtraceevent.git. > > > > The upstream maintainer hopes that this will now be the source of all > > updates to the libtraceevent library that can be used as a stand alone > > package that both perf and tracecmd can use. > > > > Link to the announcement mail at: > > https://lore.kernel.org/lkml/20201007130750.49349...@gandalf.local.home/ > > > > If the kernel team agrees I can raise a MR to remove the build of > > libtraceevent from the kernel source and can also make it a separate > > package and maintain it. > > I have no objection to this. Thanks for taking this on, Sudip. Thanks. I have opened the MR to remove libtracevent from kernel at: https://salsa.debian.org/kernel-team/linux/-/merge_requests/275. And the new package for libtraceevent is at: https://salsa.debian.org/sudip/libtraceevent. I have not uploaded yet, just thought if you will like to have a look at it first (specially the copyright for debian/*). -- Regards Sudip
Bug#972522: coreutils: install: Recursively install directories with new flag
Package: coreutils Version: 8.32-4+b1 Severity: wishlist Tags: upstream X-Debbugs-Cc: colomar.6@gmail.com Dear Maintainer, Could you please add a new flag to the install program so that it can install directories too? Maybe "-r" would do. If I can help in any way, please help me to do so. I'll be happy to work on that if you help me. Thanks, Alex -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.6.0-2-amd64 (SMP w/4 CPU threads) Locale: LANG=C, LC_CTYPE=C.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 coreutils depends on: ii libacl1 2.2.53-8 ii libattr1 1:2.4.48-5 ii libc62.31-3 ii libgmp10 2:6.2.0+dfsg-6 ii libselinux1 3.1-2 coreutils recommends no packages. coreutils suggests no packages. -- no debconf information
Bug#972521: fastd: DoS'able memory leak on invalid packets
Package: fastd
Severity: important
Version: 17-4
fastd doesn't free receive buffers for invalid packets. This can lead to
memory exhaustion or (with v20) to an assert. From the release text:
The new buffer management of fastd v20 revealed that received packets with
an
invalid type code were handled incorrectly, leaking the packet buffer. This
lead
to an assertion failure as soon as the buffer pool was empty, crashing
fastd.
Older versions of fastd are affected as well, but display a different
behaviour:
instead of crashing, the buffer leaks will manifest as a regular memory
leak.
This can still be used for Denial of Service attacks, so a patch for older
versions will be provided, for the case that users can't or do not want to
update to a newer version yet.
The fix can also be found inside the attached mail.
Kind regards,
Sven--- Begin Message ---
Faster than expected, there is a new release of fastd, fixing a critial
Denial of Service (fastd crash) vulnerability. All users of fastd v20 must
update.
In fastd v19 and older, the same vulnerablity exists, but exploiting it
will cause a memory leak rather than an instant crash. Users that can't or
do not want to update to v21 yet should apply the patch that is attached to
this mail.
The release notes can be found at:
https://fastd.readthedocs.io/en/stable/releases/v21.html
The new release can be obtained via Git from
https://github.com/NeoRaider/fastd
or as a tarball:
https://github.com/NeoRaider/fastd/releases/download/v21/fastd-21.tar.xz
SHA256: 942f33bcd794bcb8e19da4c30c875bdfd4d0f1c24ec4dcdf51237791bbfb0d4c
-- NeoRaider
From f6a2651fa91c472d04cb34264718f761669c8aa1 Mon Sep 17 00:00:00 2001
Message-Id:
From: Matthias Schiffer
Date: Mon, 19 Oct 2020 21:08:16 +0200
Subject: [PATCH] receive: fix buffer leak when receiving invalid packets
For fastd versions before v20, this was just a memory leak (which could
still be used for DoS, as it's remotely triggerable). With the new
buffer management of fastd v20, this will trigger an assertion failure
instead as soon as the buffer pool is empty.
(cherry picked from commit 737925113363b6130879729cdff9ccc46c33eaea)
---
src/receive.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/src/receive.c b/src/receive.c
index ba92802186fb..5696747162bd 100644
--- a/src/receive.c
+++ b/src/receive.c
@@ -170,6 +170,11 @@ static inline void handle_socket_receive_known(
case PACKET_HANDSHAKE:
fastd_handshake_handle(sock, local_addr, remote_addr, peer, buffer);
+ break;
+
+ default:
+ fastd_buffer_free(buffer);
+ pr_debug("received packet with invalid type from %P[%I]", peer, remote_addr);
}
}
@@ -197,6 +202,11 @@ static inline void handle_socket_receive_unknown(
case PACKET_HANDSHAKE:
fastd_handshake_handle(sock, local_addr, remote_addr, NULL, buffer);
+ break;
+
+ default:
+ fastd_buffer_free(buffer);
+ pr_debug("received packet with invalid type from unknown address %I", remote_addr);
}
}
--
2.28.0
signature.asc
Description: OpenPGP digital signature
--- End Message ---
signature.asc
Description: This is a digitally signed message part.
Bug#972520: geary: new upstream release
Package: geary Version: 3.38.0.1-3 Severity: wishlist There's a new minor release of geary out. There's also an open RC bug (#970933) with the existing package that would be fixed by simply updating the package with the new upstream release. Please package 3.38.1 so that geary 3.38 can transition to testing.
Bug#972519: black: autopkgtest regression
Source: black Version: 20.8b1-2 Severity: serious black currently fails its autopkgtests on amd64 and is thus unable to migrate to testing: | test_async_main (tests.test_primer.PrimerCLITests) ... Can not find 'black' executable in PATH. No point in running | FAIL | test_handle_debug (tests.test_primer.PrimerCLITests) ... ok | test_help_output (tests.test_primer.PrimerCLITests) ... ok | | == | FAIL: test_async_main (tests.test_primer.PrimerCLITests) | -- | Traceback (most recent call last): | File "/usr/lib/python3.8/contextlib.py", line 75, in inner | return func(*args, **kwds) | File "./tests/test_primer.py", line 204, in test_async_main | self.assertEqual(0, return_val) | AssertionError: 0 != -1 | | -- | Ran 141 tests in 35.425s | | FAILED (failures=1, skipped=13, expected failures=3) | Test failed: | error: Test failed: See https://ci.debian.net/data/autopkgtest/testing/amd64/b/black/7489655/log.gz Cheers -- Sebastian Ramacher signature.asc Description: PGP signature
Bug#972517: dlm: autopkgtest passes but only reports errors
Hi Valentin, On 19-10-2020 21:23, Valentin Vidic wrote: > On Mon, Oct 19, 2020 at 08:57:37PM +0200, Paul Gevers wrote: >> Your package dlm has an autopkgtest, great. However, I believe that it >> should fail as the messages in the log suggest the test didn't succeed. >> Failing autopkgtests are RC. Please fix your autopkgtest. > > Yes, unfortunately dlm requires a kernel component so the basic test > that runs in containers can't check much other that the binaries start > correctly. If the message is just fooling me, and the autopkgtest is doing what you describe above, please mark the test as superficial and close this bug when you upload. Paul signature.asc Description: OpenPGP digital signature
Bug#972428: anymeal FTCBFS: abuses AC_CHECK_FILE
Hi, 在 2020-10-19星期一的 18:33 +0100，Jan Wedekind写道： > Hi Boyuan, hi Helmut, > I have incorporated the bug fixes for cross-platform build. I also have > made other changes in the meantime. > > Boyuan, can you please upload the new version to Debian unstable. You can > download the package with dget using this command: > > dget -x > https://mentors.debian.net/debian/pool/main/a/anymeal/anymeal_1.10-1.dsc > > Kind regards > Jan Wedekind It's now uploaded. Best, Boyuan Yang
Bug#972393: transition: armadillo
Control: tags -1 = confirmed On 2020-10-19 08:37:30 +0530, Kumar Appaiah wrote: > Dear Sebastian, > > On Sun, Oct 18, 2020 at 12:10:18AM +0200, Sebastian Ramacher wrote: > > > I wish to update armadillo in unstable. A binNMU should suffice for > > > all reverse dependencies. Please let me know your opinion. > > > > Did you check if the reverse dependencies build against the new versuin > > of armadillo? > > > > Since upstream works with many of the reverse dependencies, he has > sent me this: > > "For the dependencies that involve mlpack, the associated version of > mlpack should be upgraded to 3.4.1. > Specifically, the following packages: libmlpack3, mlpack-bin, > python3-mlpack. > > mlpack 3.4.1 is currently in Debian "unstable": > https://qa.debian.org/developer.php?login=debian-science-maintain...@alioth-lists.debian.net#mlpack > > The other dependencies you listed should be fine." mlpack is currently not in testing, so won't block the transition. Please go ahead with the upload to unstable. Cheers > > Thanks. > > Kumar > > > -- > Kumar Appaiah > -- Sebastian Ramacher signature.asc Description: PGP signature
Bug#972517: dlm: autopkgtest passes but only reports errors
On Mon, Oct 19, 2020 at 08:57:37PM +0200, Paul Gevers wrote: > Your package dlm has an autopkgtest, great. However, I believe that it > should fail as the messages in the log suggest the test didn't succeed. > Failing autopkgtests are RC. Please fix your autopkgtest. Yes, unfortunately dlm requires a kernel component so the basic test that runs in containers can't check much other that the binaries start correctly. The second test (corosync) requires isolation-machine and does a better job but it requires a full kvm machine. -- Valentin
Bug#969362: python-flask-cors: CVE-2020-25032
Hi Bastian, On Wed, Oct 14, 2020 at 05:39:00PM +0200, Salvatore Bonaccorso wrote: > Hi Bastian, > > On Tue, Oct 13, 2020 at 11:36:40PM +0200, Bastian Germann wrote: > > Hi Salvatore, > > > > Thanks for your hints. > > > > Am 10.10.20 um 23:02 schrieb Salvatore Bonaccorso: > > > Hi Bastian, > > > > > > [Please do send such requests always to team@s.d.o, dev-ref gives as > > > well some further hints at > > > https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#handling-security-related-bugs] > > > > > > On Thu, Oct 08, 2020 at 04:25:55PM +0200, Bastian Germann wrote: > > >> On Tue, 01 Sep 2020 10:51:48 +0200 Salvatore Bonaccorso > > >> wrote: > > >>> The following vulnerability was published for python-flask-cors. > > >>> > > >>> CVE-2020-25032[0]: > > >>> | An issue was discovered in Flask-CORS (aka CORS Middleware for Flask) > > >>> | before 3.0.9. It allows ../ directory traversal to access private > > >>> | resources because resource matching does not ensure that pathnames are > > >>> | in a canonical format. > > >>> > > >>> > > >>> 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-25032 > > >>> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-25032 > > >>> [1] > > >>> https://github.com/corydolphin/flask-cors/commit/67c4b2cc98ae87cf1fa7df4f97fd81b40c79b895 > > >> > > >> I have prepared a buster-security release at > > >> > > >> https://salsa.debian.org/python-team/packages/python-flask-cors/-/tags/debian%2F3.0.7-2 > > > > > > As for the update, please do send always as a debdiff from a built > > > (and tested) package (this request is similarly to what stable release > > > managers would expect for point release updates, it helps us as well > > > to archive discussion and debdiffs to review). > > > > The debdiff is enclosed. Also available at: > > https://salsa.debian.org/python-team/packages/python-flask-cors/-/tags/debian%2F3.0.7-1+deb10u1 > > > > > > But I can give already a first feedback: debian/changelog uses 3.0.7-2 > > > as version. Even though 3.0.7-2 might never have been seen in the > > > archive, please do use 3.0.7-1+deb10u1 instead following the usual > > > convention. While at it use urgency=high (for consistency in security > > > updates). > > > > > > For the bug closer I think you will need to use "Closes: #969362)". > > > > I applied all suggestions. > > > > > Furthermore: what kind of testing did the update recieve, were you > > > able to test the update in production environments, are there any > > > problems spotted? I'm asking in particular as the modfied tests seem > > > to pass ok as well without the patch (but I only quickly gave it a > > > test from the git repository, might be something else strange here). > > > > I ran the built package on buster but did not try to confirm that the > > security issue is closed as claimed by upstream. No problems spotted. > > Ack thanks for confirming. I have uploadd the package to > security-master and we will release DSA soon when time permits. DSA 4775-1 has been released now for it. > I think it's okay to not have patched as well the example (wher the > call was fixed accordingly including /api/ in the target URL, anybody > searching for examples will probably look online anyway). > > > >> The new upstream release is waiting in the master branch to be published > > >> in sid. > > > > > > Ok, although not required, if you have that already ok to be uploaded > > > I would say to go ahead with the unstable upload and have the fixes > > > exposed there already. > > > > I cannot upload because I am not a DD. It would be nice if someone could > > sponsor the new version. It also closes a FTBFS, which got me interested > > in the package in the first place. > > Can you ask anybody in the team to do that? This still would be needed. Regards, Salvatore
Bug#972512: ITP: offlineimap3 -- IMAP/Maildir synchronization and reader support
On 19/10/2020 18:54, Sudip Mukherjee wrote: Package: wnpp Severity: wishlist Owner: Sudip Mukherjee * Package name: offlineimap3 Version : Upstream Author : * URL : https://github.com/OfflineIMAP/offlineimap3 * License : GPL-2+ with OpenSSL exception Programming Lang: Python Description : IMAP/Maildir synchronization and reader support This is the python3 port of OfflineIMAP. As discussed in https://github.com/OfflineIMAP/offlineimap3/issues/10 upstream is asking to treat offlineimap and offlineimap3 separately and it can be packaged after upstream has done its first official release. What's the point of packaging this under a new name, if the old version is going to be removed? If they aren't meant to be coinstalled, and specially if the application interface is compatible with the old version, then there's little benefit in renaming it. The language (version) is just an implementation detail in this case. Cheers, Emilio
Bug#969301: mutool: add OpenSSL support
On Sun, 30 Aug 2020 19:32:15 -0400 John Scott wrote: > It appears mutool can't verify signed PDFs because it wasn't built > with OpenSSL support: > $ mutool sign -v signed.pdf > verifying signature 81 > error: No OpenSSL support. > error processing signatures: No OpenSSL support. > > I realize that since MuPDF uses the AGPL this is probably due to the > licenses clashing, but OpenSSL 3.0 with Apache v2 is in experimental > and might help the situation. OpenSSL is considered a system library (GPL: "major component of the operating system") in Debian as of http://meetbot.debian.net/debian-ftp/2020/debian-ftp.2020-03-13-20.02.html With that, the exception for system libraries can be invoked and an AGPL-licensed program may link with OpenSSL without an additional exception. So, the #951705 changes can be reverted.
Bug#969648: dask, pandas 1.1
Hi Rebecca (2020.10.19_12:07:08_-0700) > > Or maybe not an actual regression...it's a ~5e-7 difference and one of the > > things the patch does (at around dask/dataframe/tests/test_rolling.py:270) > > is _tighten_ the tolerance on that test. > > Hrm, I didn't see that failure. Testing again on a 32bit arch to be > sure... Aha. Reproduced. And found https://github.com/dask/dask/pull/6502 SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Bug#972510: glibc: Please ignore misc/tst-sbrk and/or misc/tst-sbrk-pie on all archs
On 2020-10-19 18:05, John Paul Adrian Glaubitz wrote: > Source: glibc > Version: 2.31-4 > Severity: normal > User: debian-sp...@lists.debian.org > Usertags: alpha hppa ia64 m68k sh4 sparc64 > > Hello! > > The two tests: > > FAIL: misc/tst-sbrk > FAIL: misc/tst-sbrk-pie > > fail on multiple architectures. > > According to the discussion in #debian-ports, the tests are broken and not > really necessary anyway: > > jrtc27 | misc/tst-sbrk and/or misc/tst-sbrk-pie seem to be failing on a > *lot* of architectures > jrtc27 | if it were up to me the problem would be solved by just deleting > sbrk... > jrtc27 | FreeBSD just took the stance of not implementing them for new ports > jrtc27 | so it's arm64 and riscv64 ports just have no sbrk > jrtc27 | cbmuser: looks like the tests are Debian-specific > jrtc27 | added as part of Hurd sbrk reworking to test it didn't break This is a bit exaggerated, this test actually passes on more architectures than it fails. Also this doesn't mean the test is useless, it means those architectures behaves differently, and that something has to be fixed. It could be some architecture specific code or the test itself. > Can we disable them? With the tests disabled, glibc should pass its testsuite > on at least alpha and > sparc64. Not sure what the problem with hppa is at the moment. We can definitely ignore it on the affected architectures, do you please give more details why the test is so wrong that it should be ignored on *all* architectures? Ignoring it on the affected architectures, will indeed fix alpha. Not sure about hppa, ia64 and sparc64 that have other issues. And there is no build log for m68k and sh4 to judge. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Bug#969648: dask, pandas 1.1
Hi Rebecca (2020.10.19_11:26:19_-0700) > I have now tested it. (The dask tests are run in autopkgtest, not build.) Thanks. I took your untested patch and tested it, too. It needed some tweaking, which it looks like you've also done. > The attached is what I have so far, but it had these failures. The first > two happen with or without 969648.patch and (from debci results) appear to > be triggered by the new fsspec, but the last is a *regression* caused by > this patch. I cherry picked these to fix these failures: https://github.com/dask/dask/pull/6331 https://github.com/dask/dask/pull/6446 SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Bug#972510: (no subject)
Hello, Adhemerval Zanella, le lun. 19 oct. 2020 15:44:03 -0300, a ecrit: > On Mon, Oct 19, 2020 at 1:09 PM John Paul Adrian Glaubitz > wrote: > > FAIL: misc/tst-sbrk > > FAIL: misc/tst-sbrk-pie > > Just to you know these tests were never actually pushed upstream. > They came from the debian > patch: > > patches/hurd-i386/git-sbrk-end.diff Oh, they were indeed spuriously imported from the tree that Thomas Schwinge was testing. I have now removed these tests, sorry for the clutter. Samuel
Bug#969648: dask, pandas 1.1
Hi Rebecca (2020.10.19_11:51:33_-0700) > Or maybe not an actual regression...it's a ~5e-7 difference and one of the > things the patch does (at around dask/dataframe/tests/test_rolling.py:270) > is _tighten_ the tolerance on that test. Hrm, I didn't see that failure. Testing again on a 32bit arch to be sure... > That looks like my earlier version, which fails with NameError. Yeah, I applied it as-is first, and then followed up with the fixes, after seeing the test failures. SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Bug#972510: (no subject)
On 2020-10-19 15:44, Adhemerval Zanella wrote: > On Mon, Oct 19, 2020 at 1:09 PM John Paul Adrian Glaubitz > wrote: > > > > Source: glibc > > Version: 2.31-4 > > Severity: normal > > User: debian-sp...@lists.debian.org > > Usertags: alpha hppa ia64 m68k sh4 sparc64 > > > > Hello! > > > > The two tests: > > > > FAIL: misc/tst-sbrk > > FAIL: misc/tst-sbrk-pie > > Just to you know these tests were never actually pushed upstream. > They came from the debian > patch: > > patches/hurd-i386/git-sbrk-end.diff > > And the original commit (8c6beab4e1c03ac57150241015486e3f497c17cc) > only contains the Hurd > specific bits. Indeed, good catch. Samuel, can you split the patch in two parts, the one that upstream and the one that is debian specific with the test? Also can it be upstreamed? Thanks, Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Bug#954112: tzdata: Add ICU tzdata files
Hi, On 2020-10-19 14:56, Dimitri John Ledkov wrote: > On Mon, 16 Mar 2020 23:09:58 + Dimitri John Ledkov > wrote: > > Package: tzdata > > Version: 2019c-3 > > Severity: normal > > > > Dear Maintainer, > > > > This adds ICU timezone datafiles from icu-data repository. > > > > The source .txt data files are sources for the binary .res files, > > which are compiled at build time. Shipping this enabled to update > > timezone database files at runtime for icu, by rebuilding icu by > > setting `U_TIMEZONE_FILES_DIR` build-time config option, or at runtime > > with environment variable `ICU_TIMEZONE_FILES_DIR`. This will resolve > > a long standing bug that tzdata inside icu is never updated, and thus > > apps that use icu to access tzdata are always out of date (i.e. php). > > > > Note that the .txt files do duplicate tzdata data files a bit. As they > > are generated with a Java app by ICU upstream which merges tzdata > > files as input together with https://github.com/unicode-org/cldr xmls > > overrides. Maybe in the future, I will provide a more complete / > > reproducible process to rebuild icu input .txt files from the tzdata > > files directly with the xml overlays "from complete scratch". > > > > However, at least .res files generated are reproducible and match > > checksums of the prebuild .res files distributed in the icu-data > > repository. > > > > Regards, > > > > Dimitri. > > Hi, Is this going to be reviewed / considered for inclusion? > > icu package in Debian now compiles with such a definition too, and is > actively trying to lookup updated tzdata from that location. For some reason this bug never went to the mailing list, so I am discovering it just now. I'll try to have a look at it in the next weeks. Regards, Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Bug#972437: debian-reference: mentions no longer existing packages
Hi, xiao sheng wen (肖盛文) wrote: > hi, > > I create a patch to fix NOT_FOUND in pkgsize.ent. > > This patch add the script to get package data from Stable and Oldstable . > > Please help to review it. Modify is also welcome. We should better remove the whole content about those packages, right? It is of no use for Debian users anyway, if they no longer can install the corresponding packages. (If they still have the packages installed, let's say on an oldstable system, then they should read the debian-reference for *oldstable*.) Regarding your patch: > @@ -73,6 +73,8 @@ CODE:= sid > ARCH := amd64 > UDEBA:= $(DEBM)/$(CODE) > UDEBB:= $(DEBM)/experimental > +UDEBC:= $(DEBM)/buster > +UDEBD:= $(DEBM)/stretch > DR_VERSION :=$(shell dpkg-parsechangelog --show-field Version) Those 'buster' and 'stretch' lines are error-prone, since they get outdated with the next release. We should not add hard-coded release-names, there are already too much cases existing with such hard-coded values (Debian-wide, not just in the debian-reference). Holger > 在 2020/10/19 下午5:39, xiao sheng wen (肖盛文) 写道: > > > >> > >> Moreover, when calling "make entity" there are several packages > >> mentioned as > >> no longer existing: (and they are indeed not in sid) > >> > >> > >> # GENERATE pkgsize.ent > >> sort pkg.lst | uniq | bin/sizeent packages.txt > >> packages.bkup.txt > pkgsize.ent > >> . > >> ... ERROR ...: bootchart2, probably a removed or non-amd64 package. > >> .: See > >> http://packages.qa.debian.org/common/index.html > >> . > >> > >> > >> ... ERROR ...: dosemu, probably a removed or non-amd64 package. > >> .: See > >> http://packages.qa.debian.org/common/index.html > >> .. > > > > In HTML files, there are links like > > https://packages.debian.org/sid/dosemu is break for these packages. > > > > How about to use url like this: > > > > https://packages.debian.org/search?keywords=dosemu > > > > Also these package's pkgsize will display: > > > > NOT_FOUND > > > > The "NOT_FOUND" word is come from pkgsize.ent: > > > > pkgsize.ent: > > > > grep -c NOT_FOUND pkgsize.ent > > 15 > > > > Would you has any suggestion for this "NOT_FOUND" ? > > > > > -- > 肖盛文 xiao sheng wen Faris Xiao > 微信(wechat)：atzlinux > 《铜豌豆 Linux》 > 基于 Debian 的 Linux 中文桌面操作系统：https://www.atzlinux.com > Debian QA page: https://qa.debian.org/developer.php?login=atzlinux%40sina.com > GnuPG Public Key: 0x339240CB > -- Holger Wansing PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076
Bug#972517: dlm: autopkgtest passes but only reports errors
Source: dlm Version: 4.0.9-1 X-Debbugs-CC: debian...@lists.debian.org User: debian...@lists.debian.org Usertags: issue Dear maintainer(s), Your package dlm has an autopkgtest, great. However, I believe that it should fail as the messages in the log suggest the test didn't succeed. Failing autopkgtests are RC. Please fix your autopkgtest. Paul https://ci.debian.net/data/autopkgtest/unstable/amd64/d/dlm/7310664/log.gz autopkgtest [21:56:42]: test basic: [--- === dlm_tool === dlm_tool 4.0.9 (built Jul 14 2019 15:25:42) Copyright Red Hat, Inc. 2004-2013 === dlm_controld === 979848 dlm_controld 4.0.9 started 979848 our_nodeid 1 979848 node_config 1 979848 Is dlm missing from kernel? No misc devices found. 979848 /sys/kernel/config/dlm/cluster/comms: opendir failed: 2 979848 /sys/kernel/config/dlm/cluster/spaces: opendir failed: 2 979848 No /sys/kernel/config, is configfs loaded? 979848 shutdown 979848 /sys/kernel/config/dlm/cluster/comms: opendir failed: 2 979848 /sys/kernel/config/dlm/cluster/spaces: opendir failed: 2 === dlm_stonith === kick_helper error -79 nodeid 1 autopkgtest [21:56:42]: test basic: ---] signature.asc Description: OpenPGP digital signature
Bug#972510: (no subject)
On Mon, Oct 19, 2020 at 1:09 PM John Paul Adrian Glaubitz wrote: > > Source: glibc > Version: 2.31-4 > Severity: normal > User: debian-sp...@lists.debian.org > Usertags: alpha hppa ia64 m68k sh4 sparc64 > > Hello! > > The two tests: > > FAIL: misc/tst-sbrk > FAIL: misc/tst-sbrk-pie Just to you know these tests were never actually pushed upstream. They came from the debian patch: patches/hurd-i386/git-sbrk-end.diff And the original commit (8c6beab4e1c03ac57150241015486e3f497c17cc) only contains the Hurd specific bits. > > fail on multiple architectures. > > According to the discussion in #debian-ports, the tests are broken and not > really necessary anyway: > > jrtc27 | misc/tst-sbrk and/or misc/tst-sbrk-pie seem to be failing on a > *lot* of architectures > jrtc27 | if it were up to me the problem would be solved by just deleting > sbrk... > jrtc27 | FreeBSD just took the stance of not implementing them for new ports > jrtc27 | so it's arm64 and riscv64 ports just have no sbrk > jrtc27 | cbmuser: looks like the tests are Debian-specific > jrtc27 | added as part of Hurd sbrk reworking to test it didn't break > > Can we disable them? With the tests disabled, glibc should pass its testsuite > on at least alpha and > sparc64. Not sure what the problem with hppa is at the moment. > > Thanks, > Adrian > > -- > .''`. John Paul Adrian Glaubitz > : :' : Debian Developer - glaub...@debian.org > `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de > `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 >
Bug#594573: Translation Anymeal to Russian
Hello, On Mon, Oct 19, 2020 at 04:01:37PM +0300, Сергей Савин wrote: > Hello. I don't have a copy. I have checked and the most recent build of anymeal I have is from an upload in May of 2008 (0.30-7), and I can't find a copy of the patch on my system. I apologize for dropping the ball on this. tony > 19.10.2020 03:42, Paul Wise пишет: > > On Tue, Aug 24, 2010 at 20:34, Sergey Savin wrote: > > > > > I've translated program Anymeal from Debian lenny repository to Russian. > > > I send you ru.po file. > > > Please, include it to the package anymeal in debian lenny repository. > > Sergey, your Russian translation of Anymeal appears to have been lost. > > > > If you do not have a copy of the translation, please let us know. > > > > If you do have a copy of the translation: > > > > If you have a GitHub account, please update it for the latest version > > and file an issue requesting it be included into the upstream project. > > > > https://github.com/wedesoft/anymeal/issues > > > > Otherwise, you could attach it to a mail and send to the Debian bug: > > > > 594...@bugs.debian.org > > > > PS: the bug that was filed about your translation is available here: > > > > https://bugs.debian.org/594573
Bug#868745: Mesa llvmpipe rendering crashes on mips
On Sun, Mar 24, 2019 at 02:36:00PM +0300, Dmitry Shachnev wrote:
> This bug still happens with the latest versions of llvm, mesa and Qt
> in Buster.
Today I found another occurrence of this bug — it makes pyside2 FTBFS in
unstable.
And here is a simple way to reproduce this bug on a mips64el machine
(the needed test.qml file is attached).
1) Install packages:
qml qml-module-qtqml qml-module-qtquick2 qml-module-qtquick-window2 xauth xvfb
2) xvfb-run -a qml --verbose ./test.qml
Output:
qml: Qt 5.14.2 (mips64-little_endian-lp64-n64-hardfloat shared (dynamic)
release build; by GCC 10.2.0)
qml: Using built-in configuration: default.qml
qml: loading file:///home/mitya57/test.qml
Vendor : Mesa/X.org
Renderer: llvmpipe (LLVM 11.0.0, 128 bits)
Version : 3.1 Mesa 20.2.1
Language: 1.40
Segmentation fault
3) QSG_NO_DEPTH_BUFFER=1 xvfb-run -a qml --verbose ./test.qml
Same output, but does not segfault and keeps running.
--
Dmitry Shachnev
import QtQuick 2.0
Item {
width: 300
height: 200
Rectangle {
anchors.fill: parent
}
}
signature.asc
Description: PGP signature
Bug#972408: Don't call packages New Debian packages if not yet on Debian
Hello, On Sun 18 Oct 2020 at 08:25am +08, 積丹尼 Dan Jacobson wrote: > X-Debbugs-Cc: Sudip Mukherjee > Package: ftp.debian.org > > When reading e.g., > https://ftp-master.debian.org/new/getmail6_6.7-1.html > the user sees > Debian NEW package overview for getmail6 > > Therefore the user assumes it is a new debian package. > > However it is not yet a new debian package. Yes it may be a > debian-formated package, but it is not yet on Debian as seen in > https://packages.debian.org/ . > > So call them something different. This terminology is baked in all over the place and it would be impractical to change it. We could, however, add a note to those HTML pages saying that the package is not yet available. Perhaps just the text that gets sent to uploaders when their package lands in NEW. Patches welcome, I think. -- Sean Whitton
Bug#972515: src:csvkit: fails to migrate to testing for too long: autopkgtest failure
Source: csvkit Version: 1.0.2-2 Severity: serious Control: close -1 1.0.5-1 Tags: sid bullseye User: release.debian@packages.debian.org Usertags: out-of-sync Control: block -1 by 969550 Control: affects -1 src:python-agate-sql src:python-agate Dear maintainer(s), As recently announced [1], the Release Team now considers packages that are out-of-sync between testing and unstable for more than 60 days as having a Release Critical bug in testing. Your package src:csvkit in its current version in unstable has been trying to migrate for 62 days [2]. Hence, I am filing this bug. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and bullseye, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html [2] https://qa.debian.org/excuses.php?package=csvkit signature.asc Description: OpenPGP digital signature
Bug#972455: Does not compile for Linux 5.9
Um 19:54 Uhr am 19.10.20 schrieb Sven Hartge:
> If I add the switch "-B" to the make command in gen_compat_def I can
> reliably get the test to work correctly even on the systems with the older
> filesystem:
>
>cmd="make -s -B -C $KDIR M=$PWD modules"
I locally rebuild the iptables-netflow packages with the attached patch
applied and this fixes this problem for me.
Grüße,
Sven.
(This is like #631245 all over again.)
--- a/gen_compat_def
+++ b/gen_compat_def
@@ -26,7 +26,7 @@
cat > test.c
echo obj-m = test.o > Makefile
- cmd="make -s -C $KDIR M=$PWD modules"
+ cmd="make -s -B -C $KDIR M=$PWD modules"
echo "$cmd" > log
if $cmd >> log 2>&1; then
[ "$2" ] && echo "// $2 is declared ${3:+in <$3>}"
Bug#972513: u-boot-tools: build with CONFIG_FIT_SIGNATURE=y
Package: u-boot-tools Version: 2020.10+dfsg-1 Severity: wishlist Tags: patch Dear Maintainer(s), The FTP team revised their guidance related to OpenSSL linkage. It is now considered a "system library", so it is now allowed to dynamically link a GPL binary to libssl: http://meetbot.debian.net/debian-ftp/2020/debian-ftp.2020-03-13-20.02.html https://salsa.debian.org/ftp-team/website/-/merge_requests/6 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=972181 Please consider removing the override of CONFIG_FIT_SIGNATURE in debian/rules to get signature supports in u-boot tools. MR opened on Salsa: https://salsa.debian.org/debian/u-boot/-/merge_requests/14 Thank you! -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#972455: Does not compile for Linux 5.9
Hi! I think I know what the problem is and is really really stupid. The age of my systems was the correct hint here: The filesystem /usr is on is too old and it does not have microsecond resolution but the CPU is fast enough to get the job done in under a second. Which means the test is so fast, that the test.c is compiled once and then for every other test make just skips the compilation because it thinks the result is recent enough. The systems where this works reliably have microsecond resolution. If I add the switch "-B" to the make command in gen_compat_def I can reliably get the test to work correctly even on the systems with the older filesystem: cmd="make -s -B -C $KDIR M=$PWD modules" (To test my theory I added a "sleep 2" into the kbuild_test_compile() function and got the same correct result every time.) Argh! Grüße, Sven
Bug#972428: anymeal FTCBFS: abuses AC_CHECK_FILE
Hi Boyuan, hi Helmut, I have incorporated the bug fixes for cross-platform build. I also have made other changes in the meantime. Boyuan, can you please upload the new version to Debian unstable. You can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/a/anymeal/anymeal_1.10-1.dsc Kind regards Jan Wedekind [1]: https://mentors.debian.net/package/anymeal/
Bug#972455: Does not compile for Linux 5.9
Um 19:28 Uhr am 19.10.20 schrieb Sven Hartge: > What?! > > I tested with debsums -c and even reinstalled > linux-headers-5.9.0-1-common, comparing the before and after, nothing > broken, nothing missing. Scratch that last part. Because make did run correctly during gen_compat_def it wasn't recompiling the test code outside of it because of the timestamp. Removing "-s" and adding "-B" to make make more talkative and force it to compile stuff helps. But: Then the problem disappears: Working system: -8<--- # make -B -C /lib/modules/5.9.0-1-amd64/build M=/var/lib/dkms/ipt-netflow/2.5.1/source/cc-test-build modules make: Entering directory '/usr/src/linux-headers-5.9.0-1-amd64' CC [M] /var/lib/dkms/ipt-netflow/2.5.1/source/cc-test-build/test.o /var/lib/dkms/ipt-netflow/2.5.1/source/cc-test-build/test.c:4:16: error: storage size of 'test' isn't known 4 | struct timeval test; |^~~~ make[2]: *** [/usr/src/linux-headers-5.9.0-1-common/scripts/Makefile.build:288: /var/lib/dkms/ipt-netflow/2.5.1/source/cc-test-build/test.o] Error 1 make[1]: *** [/usr/src/linux-headers-5.9.0-1-common/Makefile:1796: /var/lib/dkms/ipt-netflow/2.5.1/source/cc-test-build] Error 2 make: *** [/usr/src/linux-headers-5.9.0-1-common/Makefile:185: __sub-make] Error 2 make: Leaving directory '/usr/src/linux-headers-5.9.0-1-amd64' -8<--- Broken system: -8<--- # make -B -C /lib/modules/5.9.0-1-amd64/build M=/var/lib/dkms/ipt-netflow/2.5.1/source/cc-test-build modules make: Entering directory '/usr/src/linux-headers-5.9.0-1-amd64' CC [M] /var/lib/dkms/ipt-netflow/2.5.1/source/cc-test-build/test.o /var/lib/dkms/ipt-netflow/2.5.1/source/cc-test-build/test.c:4:16: error: storage size of 'test' isn't known 4 | struct timeval test; |^~~~ make[2]: *** [/usr/src/linux-headers-5.9.0-1-common/scripts/Makefile.build:288: /var/lib/dkms/ipt-netflow/2.5.1/source/cc-test-build/test.o] Error 1 make[1]: *** [/usr/src/linux-headers-5.9.0-1-common/Makefile:1796: /var/lib/dkms/ipt-netflow/2.5.1/source/cc-test-build] Error 2 make: *** [/usr/src/linux-headers-5.9.0-1-common/Makefile:185: __sub-make] Error 2 make: Leaving directory '/usr/src/linux-headers-5.9.0-1-amd64' -8<--- Why is compiling the test code inside gen_compat_def behaving differently than outside of it? I have already compared the environment variables and cannot find anything relevant. There are no strange LD_* or CLFAGS set globally, no distcc or ccache remnants. My brain hurts. Grüße, Sven.
Bug#972344: bash automatically selects the copied text
On 10/16/20 5:07 PM, Antonio wrote: > Package: bash > Version: 5.1~rc1-2 > Severity: normal > > Dear Maintainer, > after updating bash to version 5.1 ~ rc1-2 I noticed a new behavior: when > you paste a text it is automatically selected. > This however creates confusion as on plasma / konsole as the text is > confused with the cursor (block), placed at the end of the word. > How can I disable this new feature? please could you forward that issue upstream, using the bashbug script? Thanks, Matthias
Bug#894884: [Pkg-ayatana-devel] Bug#894884: Doesn't show anything under X11 or Wayland
Control: forwarded -1 https://gitlab.com/vala-panel-project/vala-panel/-/issues/121 On Do 05 Apr 2018 10:30:41 CEST, Guido Günther wrote: Package: vala-panel Version: 0.3.74-1 Severity: normal Hi, starting vala-panel on a X11 based gnome-session gives: $ vala-panel ** (vala-panel:10456): WARNING **: 10:21:47.654: applet-holder.vala:106: Could not find plugin: wincmd ** (vala-panel:10456): WARNING **: 10:21:47.654: applet-holder.vala:106: Could not find plugin: pager ** (vala-panel:10456): WARNING **: 10:21:47.655: applet-holder.vala:106: Could not find plugin: tasklist ** (vala-panel:10456): WARNING **: 10:21:47.655: applet-holder.vala:106: Could not find plugin: xembed but nothing show up. If I then install vala-panel-plugins-wnck and vala-panel-appmenu the above warnings go away but there's still no panel. Cheers, -- Guido this still seems to be an issue with upcoming vala-panel 0.5.0. Upstream issue filed: https://gitlab.com/vala-panel-project/vala-panel/-/issues/121 Mike -- DAS-NETZWERKTEAM c\o Technik- und Ökologiezentrum Eckernförde Mike Gabriel, Marienthaler Str. 17, 24340 Eckernförde mobile: +49 (1520) 1976 148 landline: +49 (4351) 850 8940 GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22 0782 9AF4 6B30 2577 1B31 mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de pgpEDjSzV6SWt.pgp Description: Digitale PGP-Signatur
Bug#969717: libgl1-mesa-dri: Champions of Regnum display deteriorates after libgl1-mesa-dri upgrade to 20.1.7-1
On 19.10.2020 18.13, VB wrote: Just tried again with 20.2.1 from recent unstable. The game still crashes after the credentials are checked, while starting the loading screen. you should probably file it upstream at https://gitlab.freedesktop.org/mesa/mesa -- t
Bug#972455: Does not compile for Linux 5.9
Um 16:02 Uhr am 19.10.20 schrieb Axel Beckert:
>> Next step would be to strace the dkms build process and compare the
>> output to find out what files are referenced to find the offending
>> header files.
>
> Good idea, thanks!
The more I look at this, the more ?!?! appear above my head.
I am currently comparing one working system and one failing system.
On both I did the following:
# cd /var/lib/dkms/ipt-netflow/2.5.1/source
# ./configure --kver=5.9.0-1-amd64 --kdir=/lib/modules/5.9.0-1-amd64/build
This resulted in the following *identical* output:
--8<-
Module version: 2.5.1
Kernel version: 5.9.0-1-amd64 (requested)
Kernel sources: /lib/modules/5.9.0-1-amd64/build (requested)
! Warning: requested kernel version (5.9.0-1-amd64) and requested version of
kernel source (5.9.1) doesn't match!
! You may try to specify only kernel source tree with
--kdir=/lib/modules/5.9.0-1-amd64/build
! and configure will pick up version properly.
! Assuming you want to build for 5.9.1
Checking for presence of include/linux/netfilter.h... No
Checking for presence of include/linux/llist.h... No
Checking for presence of include/linux/grsecurity.h... No
Iptables binary version: 1.8.5 (legacy) (detected from /usr/sbin/iptables)
pkg-config for version 1.8.5 (legacy) exists: No (reported: 1.8.5)
Check for working gcc: Yes (gcc)
Checking for presence of xtables.h... Yes
Searching for iptables-1.8.5 (legacy) sources..
! Can not find iptables source directory, you may try setting it with --ipt-src=
! This is not fatal error, yet. Will be just using default include dir.
Iptables include flags: none (default)
Iptables module path: /usr/lib/debug/.dwz/x86_64-linux-gnu/iptables.debug (from
binary)
Searching for net-snmp-config... No.
Searching for net-snmp agent... No.
Assuming you don't want net-snmp agent support.
Otherwise do: apt-get install snmpd libsnmp-dev
Checking for DKMS... Yes.
! You are already have module installed via DKMS
! it will be uninstalled on 'make install' and
! current version of module installed afterwards.
! Use --disable-dkms option if don't want this.
Creating Makefile.. done.
If you need some options enabled run ./configure --help
Now run: make all install
--8<-
Then I ran ./gen_compat_def which is used to generate compat_def.h where the
problem stem from.
And here the output differs:
Broken System:
--8<
// Autogenerated for /lib/modules/5.9.0-1-amd64/build
Test symbol xt_family linux/netfilter_ipv4/ip_tables.h
// xt_family is declared in
#define HAVE_XT_FAMILY
Test struct timeval linux/ktime.h
// struct timeval is declared in
#define HAVE_TIMEVAL
Test struct proc_ops linux/proc_fs.h
// struct proc_ops is declared in
#define HAVE_PROC_OPS
Test symbol synchronize_sched linux/rcupdate.h
// synchronize_sched is declared in
#define HAVE_SYNCHRONIZE_SCHED
// End of compat_def.h
--8<
Working System with undef'ed HAVE_TIMEVAL and HAVE_SYNCHRONIZE_SCHED:
--8<
// Autogenerated for /lib/modules/5.9.0-1-amd64/build
Test symbol xt_family linux/netfilter_ipv4/ip_tables.h
// xt_family is declared in
#define HAVE_XT_FAMILY
Test struct timeval linux/ktime.h
#undef HAVE_TIMEVAL
// struct timeval is undeclared in . Compile:
// #include
// #include
// MODULE_LICENSE("GPL");
// struct timeval test;
// Output:
// make -s -C /lib/modules/5.9.0-1-amd64/build
M=/var/lib/dkms/ipt-netflow/2.5.1/source/cc-test-build modules
// /var/lib/dkms/ipt-netflow/2.5.1/source/cc-test-build/test.c:4:16: error:
storage size of 'test' isn't known
// 4 | struct timeval test;
// |^~~~
// make[2]: ***
[/usr/src/linux-headers-5.9.0-1-common/scripts/Makefile.build:288:
/var/lib/dkms/ipt-netflow/2.5.1/source/cc-test-build/test.o] Error 1
// make[1]: *** [/usr/src/linux-headers-5.9.0-1-common/Makefile:1796:
/var/lib/dkms/ipt-netflow/2.5.1/source/cc-test-build] Error 2
// make: *** [/usr/src/linux-headers-5.9.0-1-common/Makefile:185: __sub-make]
Error 2
Test struct proc_ops linux/proc_fs.h
// struct proc_ops is declared in
#define HAVE_PROC_OPS
Test symbol synchronize_sched linux/rcupdate.h
#undef HAVE_SYNCHRONIZE_SCHED
// synchronize_sched is undeclared in . Compile:
// #include
// #include
// MODULE_LICENSE("GPL");
// void *test = synchronize_sched;
// Output:
// make -s -C /lib/modules/5.9.0-1-amd64/build
M=/var/lib/dkms/ipt-netflow/2.5.1/source/cc-test-build modules
// /var/lib/dkms/ipt-netflow/2.5.1/source/cc-test-build/test.c:4:14: error:
'synchronize_sched' undeclared here (not in a function); did you mean
'synchronize_srcu'?
// 4 | void *test = synchronize_sched;
// | ^
// | synchronize_srcu
// make[2]: ***
[/usr/src/linux-headers-5.9.0-1-common/scripts/Makefile.build:288:
/var/lib/dkms/ipt-netflow/2.5.1/source/cc-test-build/test.o] Error 1
// make[1]:
Bug#971335: broadcom-sta: [patch] Driver improvements, cleanups, fixes
Hey Roger, Apologies for the radio silence. I just saw that this email ended up in the spam folder :(. Thanks for your comments and eagerness to welcome and test this, I'm really glad that more people will find this useful :) :) Some comments: On Thu, Oct 1, 2020 at 11:08 AM Roger Shimizu wrote: > > My "frankenwl" branch is functionally the same as the above > > "diegoe_debian" branch, but it certainly makes it less convoluted to try > > and find problems in the code going forward. That said, I wasn't sure > > what would be the best way to proceed, or if it was a smart thing to do > > anyway. I guess this package is on "life support" on most distros, so I > > doubt there would be a objections on creating a shared new upstream (but > > I'm not familiar with the packaging of this driver in Debian, or other > > distros). > > Since the upstream seems not active for quite a few years, so I think > it's totally fine if you want to fork. > And if you do so, I'm happy to update debian package to follow your > forked git repo. > Do you think it would be worth it to reach out to maintainers at a few main distros and see if there's any interest to collaborate on this? When I was trying to figure out the issues with my card (see below) I noticed that most distros either copy+paste patches, or brew their own slightly different versions. > > I'm also aware that cards supported by this driver are "old" but most > > computers trapped in the broadcom-sta driver are perfectly functional > > today and will be for a few more years. In my particular case I'm > > running a macbookpro11,1 (2013) which works flawlessly except for the > > wifi! (Hah!) -- And I understand most other macbookpro models from > > around 2013 share this or similar Broadcom cards that use this driver. > > All those machines should be perfectly functional with Debian right now, > > and for a few more years. > > Yes, I also have two mac devices that use this driver. > Thanks for your effort to make the driver better. I wonder if you have run into the connection timeouts/unstable wifi issues that many other users run into? I have been trying to debug why and when this issue happens, but perhaps you might have any clue or anecdote that might help figure this out. The issue seems to appear when using certain (seemingly old) APs that do not implement anything newer than 802.11n -- meaning that anything with 802.11ac is usually free of the issue. The problem manifests as sudden very high latency, and sometimes lost ARP/identity towards the AP. I have been unable to debug the issue, but I have reasonably eliminated WMM, power saving (both PCI/card and 802.11 protocol), b/g/n, and a few other suspects. >From my own testing it would seem that the firmware blob in the card (or the blob uploaded by the driver) simply stops reporting new packets, either queuing them, or simply dropping them silently, which on user space manifests as progressively higher latency and eventual lost of connectivity until resync/reconnection happens, or the firmware behaves again. I don't have the proper network hardware to test the router side, so I can't 100% confirm what's going on. AFAIK, these cards have a hybrid firmware model where there's a ROM firmware in the card, but by design you have/can upload a RAM firmware that allows the OEM/IHV to upload new features or fix bugs. Fairly standard, I understand. But my current hypothesis is that the particular card I have is an slightly custom module by Apple that has certain buggy behaviors that get corrected with the RAM firmware made by Apple. To give some support to this hypothesis, my current card + AP combo exhibited the same buggy behavior under OSX. However, this buggy behavior got fixed on OSX a few months after the last ever release of broadcom-sta for Linux. My hypothesis is that whatever bug that this ROM firmware has with slow or old APs (whether a Broadcom or Apple integration bug), got fixed by Apple or Broadcom in an updated RAM firmware, but said fix missed the window of the last ever broadcom-sta. Anyway, my current understanding is that we can't fix the described problem with the "open" part of the driver. It is the firmware part that is the problem, so unless someone learns or knows how to extract the firmware from the binary blob in OSX/Windows, and then use that in Linux, or something like that, then the use case of "old weird AP + this card" is broken under Linux (under some undetermined circumstances). Rant over. Thought I would share the above info anyway, in case you might have any clue or anecdote that could help figure this out.
Bug#957250: gadmin-rsync: diff for NMU version 0.1.7-1.1
Control: tags 957250 + patch Control: tags 957250 + pending -- Dear maintainer, I've prepared an NMU for gadmin-rsync (versioned as 0.1.7-1.1) and uploaded it to DELAYED/2. Please feel free to tell me if I should cancel it. -- Regards Sudip diff -Nru gadmin-rsync-0.1.7/debian/changelog gadmin-rsync-0.1.7/debian/changelog --- gadmin-rsync-0.1.7/debian/changelog 2011-03-26 09:31:20.0 + +++ gadmin-rsync-0.1.7/debian/changelog 2020-10-19 18:03:24.0 +0100 @@ -1,3 +1,10 @@ +gadmin-rsync (0.1.7-1.1) unstable; urgency=medium + + * Non-maintainer upload. + * Fix ftbfs with GCC-10. (Closes: #957250) + + -- Sudip Mukherjee Mon, 19 Oct 2020 18:03:24 +0100 + gadmin-rsync (0.1.7-1) unstable; urgency=low * New Maintainer. (Closes: #605305) diff -Nru gadmin-rsync-0.1.7/debian/patches/fix_gcc-10.patch gadmin-rsync-0.1.7/debian/patches/fix_gcc-10.patch --- gadmin-rsync-0.1.7/debian/patches/fix_gcc-10.patch 1970-01-01 01:00:00.0 +0100 +++ gadmin-rsync-0.1.7/debian/patches/fix_gcc-10.patch 2020-10-19 18:02:58.0 +0100 @@ -0,0 +1,19 @@ +Description: Fix ftbfs with GCC-10 + +Author: Sudip Mukherjee +Bug-Debian: https://bugs.debian.org/957250 +Forwarded: no + +--- + +--- gadmin-rsync-0.1.7.orig/src/restore_menu.c gadmin-rsync-0.1.7/src/restore_menu.c +@@ -41,8 +41,6 @@ + //#include "key_handling.h" + + +-GtkTreeIter iter_filesel; +- + extern gchar *global_key_path; + extern gchar *global_scripts_dir; + extern gchar *global_backup_name; diff -Nru gadmin-rsync-0.1.7/debian/patches/series gadmin-rsync-0.1.7/debian/patches/series --- gadmin-rsync-0.1.7/debian/patches/series2011-03-09 18:35:03.0 + +++ gadmin-rsync-0.1.7/debian/patches/series2020-10-19 17:56:03.0 +0100 @@ -1,3 +1,4 @@ 01-icondir.patch 02-desktop.patch 03_spelling_errors.patch +fix_gcc-10.patch
Bug#965256: logilab-common: please make the build reproducible
Chris Lamb wrote: > [..] Friendly ping on this? Looks like it was merged upstream. Kind regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
