Bug#993177: RFS: dtkwidget/5.5.17.1-1~exp1 -- dtkwidget-examples is generated by dtkwidget
Adam Borowski 于2021年9月1日周三 下午9:10写道： > > On Wed, Sep 01, 2021 at 10:57:45AM +0800, clay stan wrote: > > Adam Borowski 于2021年8月31日周二 上午10:27写道： > > > On Tue, Aug 31, 2021 at 09:12:52AM +0800, clay stan wrote: > > > > Adam Borowski 于2021年8月30日周一 下午4:17写道： > > > > > On Sat, Aug 28, 2021 at 08:12:20PM +0800, clay stan wrote: > > > > > > dtkwidget (5.5.17.1-1~exp1) experimental; urgency=medium > > > > > > . > > > > > >* New upstream version 5.5.17.1. > > > Has rebuild and reupload to mentors. > > After discussion, our team(pkg-deepin) decided to remove the symbols, > > Because all deepin packages are maintained by our team (pkg-deepin), > > So symbols of dtk(deepin toolkit) projects are meaningless. > > Actually, symbols are meant for auto-generating versions in Depends: field, > to tell the minimal version of the library that matches the ABI. But, > managing symbols for C++ code is notoriously hard, thus dropping them is > not a problem. > > There's another issue, though. The packaging includes a number of changes > that are not mentioned in the changelog -- and at least adding a new binary > package requires a different type of upload. > > Thus: please mention packaging changes inside debian/changelog. Hey, Adam I added the details to the changelog. Regards. > > > Meow! > -- > ⢀⣴⠾⠻⢶⣦⠀ The oldest dated printed book includes the following license grant: > ⣾⠁⢠⠒⠀⣿⡁ Reverently made for universal free distribution by Wang Jie > ⢿⡄⠘⠷⠚⠋⠀ on behalf of his two parents on the 15th of the 4th moon of > ⠈⠳⣄ the 9th year of Xiantong [11 May 868].
Bug#993493: O: doctest -- Light and feature-rich C++ testing framework
Package: wnpp
Severity: normal
X-Debbugs-Cc: doct...@packages.debian.org
Control: affects -1 src:doctest
I have orphaned the doctest package for reasons independant of this package, or
of Debian.
The package description is:
doctest is a light and feature-rich C++98 / C++11 single-header testing
framework for unit tests and TDD.
.
It is inspired by the unittest {} functionality of the D programming
language and Python's docstrings - tests can be considered a form of
documentation and should be able to reside near the production code
which they test. This isn't possible (or at least practical) with any
other testing framework for C++.
Bug#993371: Support for cgroups v2
Control: forwarded -1 https://github.com/ansible/ansible-runner/issues/810 El 01/09/21 a las 21:17, Sakirnth Nagarasa escribió: > Hello > > Thank you for your bug report. > > I have opened a bug in upstream: > https://github.com/ansible/ansible-runner/issues/810 > > As soon as they adapt the code I will upload the new version to debian. > > Cheers, > Saki Thanks Saki. I'm letting know the BTS that the bugs has been forwarded upstream. Cheers, -- S signature.asc Description: PGP signature
Bug#979041: libopempi3: aborts python code due to libfabric fork() issues
On 02/09/21 at 00:16 +0200, Lucas Nussbaum wrote: > reopen 979041 > notfixed 979041 4.1.0-7 > thanks > > Hi, > > I ran into this problem with 4.1.0-7. The ofi BTL was disabled, but not > the ofi MTL. In some cases, both need to be disabled. > > You need something like: > mtl = ^ofi > in addition to: > btl = ^ofi > > (I ran into this with https://github.com/LLNL/mpiGraph and > libhwloc-contrib-plugins, and CUDA installed -- let me know if you need > help reproducing) Thinking about this again, I wonder if instead of disabling OFI/libfabric in OpenMPI, we shouldn't instead disable the EFA provider in libfabric, since it seems to be the only one causing the error on fork(). Alternatively, fork() support has been added to the libfabric EFA provider (https://github.com/ofiwg/libfabric/issues/6332), but this is unlikely to be accepted in a stable update. Given that OFI was not really disabled in OpenMPI anyway, keeping it enabled and disabling EFA in libfabric is actually a minor change. For context, EFA is an AWS-specific provider, see https://www.hpcworkshops.com/07-efa/00-efa-basics.html Lucas
Bug#993391: lxc: Unprivileged lxc example from README.Debian.gz gives AppArmor error "Failed to mount proc"
Hello, I copy-pasted configuration and commands from /usr/share/doc/lxc/README.Debian.gz under "Unprivileged containers". Are you talking about another file? https://salsa.debian.org/lxc-team/lxc/-/blob/7d692c266c63fced9417042ae904cc2a280b96d8/debian/README.Debian lxc.rootfs defaults to the system root / per lxc.container.conf(5). Creation is unnecessary, it is just a convenience to avoid -f and does not affect the container runtime. My (still privileged) lxc setup works perfectly with -f without ever creating any containers. I pasted full logs above. Please try to be respectful and helpful, do not reproduce on a configured machine, and leave bug triaging to the lxc experts. Thanks,
Bug#993173: proftpd-basic: mod_radius leaks memory contents to radius server
Hello, * Hilmar Preuße [210901 08:28]: > Am 28.08.2021 um 13:31 teilte Chris Hofstaedtler mit: > > it has been found that proftpd's mod_radius leaks uninitialised memory > > to the RADIUS server, as part of the encrypted User-Password. > > > > Upstream report: https://github.com/proftpd/proftpd/issues/1284 > > Patch: https://github.com/proftpd/proftpd/pull/1285/files > > > > Upstream fixed this in HEAD and version 1.3.7c. > > > > Please consider applying the patch to buster and bullseye. If need be I > > can also look into supplying updated (source) packages. > > > I've pushed the patch to stable and oldstable branch. Further I've packaged > the 1.3.7c for unstable and would upload soon. Thanks a lot! > - Do we need to have the fix in all 3 distributions? > - Are you willing to test the fix before I upload? I can easily test on oldstable (=buster), but not on bullseye. Chris (Also, I'll be away most of the remaining September weeks, so I could only do that relatively soon.)
Bug#993496: ITP: libfeature-compat-try-perl -- make try/catch syntax available
Package: wnpp Owner: Andrius Merkys Severity: wishlist * Package name: libfeature-compat-try-perl Version : 0.04 Upstream Author : Paul Evans * URL : https://metacpan.org/release/Feature-Compat-Try * License : Artistic or GPL-1+ Programming Lang: Perl Description : make try/catch syntax available Feature::Compat::Try is written in preparation for when perl will gain true native syntax support for try/catch control flow. . Perl added such syntax in the development version 5.33.7, which is enabled by . use feature 'try'; . On that version of perl or later, this module simply enables the core feature equivalent to using it directly. On such perls, this module will install with no non-core dependencies, and requires no C compiler. . On older versions of perl before such syntax is available, it is currently provided instead using the Syntax::Keyword::Try module, imported with a special set of options to configure it to recognise exactly and only the same syntax as the core perl feature, thus ensuring that any code using it will still continue to function on that newer perl. This package is required to update libtest-json-schema-acceptance-perl. Remark: This package is to be maintained with Debian Perl Group at https://salsa.debian.org/perl-team/modules/packages/libfeature-compat-try-perl
Bug#993499: RFS: python-marshmallow-polyfield/5.10-1 -- marshmallow extension for polymorphic fields
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "python-marshmallow-polyfield": * Package name: python-marshmallow-polyfield Version : 5.10-1 Upstream Author : Matt Bachmann * URL : https://github.com/Bachmann1234/marshmallow-polyfield * License : Apache-2.0 * Vcs : https://salsa.debian.org/python-team/packages/python-marshmallow-polyfield Section : python It builds those binary packages: python3-marshmallow-polyfield - marshmallow extension for polymorphic fields To access further information about this package, please visit the following URL: https://mentors.debian.net/package/python-marshmallow-polyfield/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/p/python-marshmallow-polyfield/python-marshmallow-polyfield_5.10-1.dsc Changes since the last upload: python-marshmallow-polyfield (5.10-1) UNRELEASED; urgency=medium . [ Ondřej Nový ] * d/control: Update Maintainer field with new Debian Python Team contact address. * d/control: Update Vcs-* fields with new Debian Python Team Salsa layout. . [ Diego M. Rodriguez ] * New upstream version 5.10 * d/watch: version 4, use signature * d/control: bump Standards-Version to 4.6.0 (no changes needed) * d/control: set architecture to all Regards, -- Diego M. Rodriguez
Bug#993501: openssl: FTBFS on kfreebsd-amd64 and kfreebsd-i386
Source: openssl Version: 1.1.1l-1 Severity: important Tags: ftbfs, patch, fixed-upstream Control: forward -1 https://github.com/openssl/openssl/pull/16477 Control: found -1 1.1.1k-1 Control: found -1 1.1.1j-1 Control: found -1 1.1.1i-3 Control: found -1 1.1.1i-2 Control: found -1 1.1.1i-1 Control: found -1 1.1.1h-1 Control: found -1 1.1.1g-1 Control: found -1 1.1.1f-1 Control: found -1 1.1.1e-1 Control: found -1 1.1.1d-2 Control: found -1 1.1.1d-1 Control: found -1 1.1.1b-2 Control: found -1 1.1.1b-1 Openssl fails to compile on Debian with kfreebsd kernels (kfreebsd- amd64, kfreebsd-i386). The error reported by the compiler is: ../crypto/uid.c: In function 'OPENSSL_issetugid': ../crypto/uid.c:50:22: error: 'AT_SECURE' undeclared (first use in this function) 50 | return getauxval(AT_SECURE) != 0; | ^ The git commit that fixes the 1.1.1 branch is: The issue has been fixed upstream. https://github.com/openssl/openssl/commit/1f8e36720fff9bdc9f08fe24a38cc91b1b78ddb0 I.e. the patch can be retrieved from https://github.com/openssl/openssl/commit/1f8e36720fff9bdc9f08fe24a38cc91b1b78ddb0.patch Mattias signature.asc Description: This is a digitally signed message part
Bug#988386: ntfs-3g is now on GitHub
ntfs-3g is now on GitHub. https://github.com/tuxera/ntfs-3g The security vulnerabilities are resolved in version 2021.8.22. https://www.openwall.com/lists/oss-security/2021/08/30/1
Bug#991341: guake: apt progress bar distorted on Guake after hide/unhide
Package: guake Version: 3.6.3-2 Followup-For: Bug #991341 It seems like the distortion of apt progress bar only happens when guake is in full screen mode.
Bug#993495: upgrade-reports: autologin to kde via sddm fails after buster->bullseye
Package: upgrade-reports
Severity: normal
X-Debbugs-Cc: boris+deb...@bretonium.net
My previous release is: buster
I am upgrading to: bullseye
Archive date: before Thu Sep 2 02:22:57 UTC 2021
Upgrade date: Thu Sep 1 ~22:00 UTC+1 2021
uname -a before upgrade: missing
uname -a after upgrade: Linux stationary-pc 5.10.0-8-amd64 #1 SMP Debian
5.10.46-4 (2021-08-03) x86_64 GNU/Linux
Method: apt full-upgrade via internet
Contents of /etc/apt/sources.list: only default `main` repos, no
non-Debian packages, all packages upgraded successfully.
I use sddm as my desktop manager and launch kde plasma with it. I also
use autologin into my single non-root user, that was created during
installation of buster.
After the upgrade autologin failed and sddm and/or plasma crashed. There was
either a black screen or only a cursor on a black background. Logs are
in the end of the report.
The problem was in autologin and in the contents of /etc/sddm.conf. The
contents was probably something like this (it got rewritten after
reconfiguration via gui and original content lost):
[Autologin]
User=breton
Session=plasma
After i commented out these lines, i was able to log again. After
re-configuring autologin via kde gui things were still working.
I will try to reproduce it again in a VM.
Logs:
Sep 02 01:33:25 stationary-pc systemd[1]: Started Simple Desktop Display
Manager.
Sep 02 01:33:25 stationary-pc sddm[885]: Initializing...
Sep 02 01:33:25 stationary-pc sddm[885]: Starting...
Sep 02 01:33:25 stationary-pc sddm[885]: Logind interface found
Sep 02 01:33:25 stationary-pc sddm[885]: Adding new display on vt 7 ...
Sep 02 01:33:25 stationary-pc sddm[885]: Loading theme configuration from ""
Sep 02 01:33:25 stationary-pc sddm[885]: Display server starting...
Sep 02 01:33:25 stationary-pc sddm[885]: Adding cookie to
"/var/run/sddm/{18e1b067-6f34-44ab-b601-234f264b7fe2}"
Sep 02 01:33:25 stationary-pc sddm[885]: Running: /usr/bin/X -nolisten tcp
-auth /var/run/sddm/{18e1b067-6f34-44ab-b601-234f264b7fe2} -background none
-noreset -displ>
Sep 02 01:33:26 stationary-pc sddm[885]: Setting default cursor
Sep 02 01:33:26 stationary-pc sddm[885]: Running display setup script
"/usr/share/sddm/scripts/Xsetup"
Sep 02 01:33:26 stationary-pc sddm[885]: Display server started.
Sep 02 01:33:26 stationary-pc sddm[885]: Reading from
"/usr/share/xsessions/plasma.desktop"
Sep 02 01:33:26 stationary-pc sddm[885]: Reading from
"/usr/share/xsessions/plasma.desktop"
Sep 02 01:33:26 stationary-pc sddm[885]: Session
"/usr/share/xsessions/plasma.desktop" selected, command:
"/usr/bin/startplasma-x11"
Sep 02 01:33:26 stationary-pc sddm-helper[920]: [PAM] Starting...
Sep 02 01:33:26 stationary-pc sddm-helper[920]: [PAM] Authenticating...
Sep 02 01:33:26 stationary-pc sddm-helper[920]: [PAM] returning.
Sep 02 01:33:26 stationary-pc sddm[885]: Authenticated successfully
Sep 02 01:33:26 stationary-pc sddm-helper[920]:
pam_unix(sddm-autologin:session): session opened for user breton(uid=1000) by
(uid=0)
Sep 02 01:33:26 stationary-pc sddm-helper[920]: Starting:
"/etc/sddm/wayland-session /usr/bin/startplasma-x11"
Sep 02 01:33:26 stationary-pc sddm[885]: Session started
Sep 02 01:33:27 stationary-pc sddm-helper[920]: [PAM] Closing session
Sep 02 01:33:27 stationary-pc sddm-helper[920]:
pam_unix(sddm-autologin:session): session closed for user breton
Sep 02 01:33:27 stationary-pc sddm-helper[920]: [PAM] Ended.
Sep 02 01:33:27 stationary-pc sddm[885]: Auth: sddm-helper exited with 1
Bug#993498: Checkinstall should use dpkg-shlibdeps
Package: checkinstall Version: 1.6.2+git20170426.d24a630-2 Severity: wishlist Tags: upstream When creating a deb on Debian using checkinstall (eg. to get a working distributable version of software whose build dependencies are so compilcated[1] it stands little chances in regular packaging), several dependencies could be detected automatically using shlibdeps, as is done eg. by debhelper dh_shlibdeps. When binaries are installed, that would detect the necessary libc versions as well as any other shared libraries the installed binaries depend on. The correct dependency information would help both cleaning up the local system (otherwise uninstalling the -dev packages might autoremove also the libraries that are now depended on) and using it on a different system (where now one has to read linker errors and add files on demand). [1]: https://github.com/immunant/c2rust/issues/326 Minimal test case: $ fakeroot checkinstall --pkgname test --default --install=no -- cp -a /usr/bin/ssh /bin $ dpkg-deb --info test_20??-1_*.deb | grep Depends (no results) If shlibdeps were extracted, it should print at least something about libc. A minimal working example of how to arrive at the relevant shlibdeps is: $ mkdir debian $ touch debian/control $ dpkg-shlibdeps /usr/bin/ssh $ cat debian/substvars shlibs:Depends=libc6 (>= 2.26), libgssapi-krb5-2 (>= 1.17), libselinux1 (>= 3.1~), libssl1.1 (>= 1.1.0), zlib1g (>= 1:1.1.4) -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.13.0 (SMP w/8 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages checkinstall depends on: ii dpkg-dev1.20.9 ii file1:5.39-3 ii libc6 2.31-17 ii sensible-utils 0.0.17 Versions of packages checkinstall recommends: ii make 4.3-4.1 Versions of packages checkinstall suggests: ii gettext 0.21-4 -- no debconf information signature.asc Description: PGP signature
Bug#992980: gnome-shell complains if using lightdm
Hello, After this update ``` Réception de :15 https://cdn-aws.deb.debian.org/debian bookworm/main amd64 gnome-shell amd64 3.38.6-1 [829 kB] Réception de :16 https://cdn-aws.deb.debian.org/debian bookworm/main amd64 gnome-shell-common all 3.38.6-1 [744 kB] ``` The notification is no more displayed. https://metadata.ftp-master.debian.org/changelogs/main/g/gnome-shell/gnome-shell_3.38.6-1_changelog * Make sure to return a value from D-Bus methods so callers won’t time out
Bug#993494: thunderbird FTBFS with autoconf 2.71
Source: thunderbird Version: 1:78.4.0-1 Severity: serious Tags: ftbfs bookworm sid https://buildd.debian.org/status/package.php?p=thunderbird=sid https://buildd.debian.org/status/package.php?p=thunderbird=experimental ... debian/rules binary-arch dh binary-arch dh_update_autotools_config -a dh_autoreconf -a autoreconf: warning: autoconf input should be named 'configure.ac', not 'configure.in' autoreconf: error: configure.in: AC_INIT not found; not an autoconf script? dh_autoreconf: error: autoreconf -f -i returned exit code 1
Bug#986997: ITA: netkit-telnet
* Simon Josefsson [210902 10:02]: > All, > > I'm considering to adopt this package, as it has been orphaned for > around five years in Debian. I wanted to reach out to some people > (cc'd) that appear to have been involved in the discussions around it to > make sure I'm not missing anything that should be considered. > > My aim is to 1) refresh the packaging including hopefully some > autopkgtests, 2) figure out if there is a better upstream for this > package, and 3) prepare to smooth out any issues preventing migrating > towards inetutils in Debian. Sounds good to me. If the plan is indeed to fade out src:netkit-telnet, then assuming Maintainer:-ship for it is a very good start. Chris
Bug#993500: Watch sould honor npm source
Package: qa.debian.org Severity: minor Dear Maintainer, Node-resolve watch fail with: uscan had problems while searching for a new upstream version: unknown ctype nodejs Could we support ctype nodejs ? Thanks Bastien
Bug#993492: buster-pu: package cyrus-imapd/3.0.8-6+deb10u6
Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
[ Reason ]
cyrus-imapd before 3.0.16 allows remote attackers to cause a denial of
service (multiple-minute daemon hang) via input that is mishandled
during hash-table interaction. Because there are many insertions into
a single bucket, strcmp becomes slow. This is fixed in 3.4.2, 3.2.8,
and 3.0.16.
[ Impact ]
Medium vulnerability
[ Tests ]
The new cunit/strhash.testc passed.
[ Risks ]
Low risk, patch is easy to read
[ Checklist ]
[X] *all* changes are documented in the d/changelog
[X] I reviewed all changes and I approve them
[X] attach debdiff against the package in (old)stable
[X] the issue is verified as fixed in unstable
[ Changes ]
New string hashing algorithm and test.
Cheers,
Yadd
diff --git a/debian/changelog b/debian/changelog
index 240d1f4d..02f57603 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+cyrus-imapd (3.0.8-6+deb10u6) buster; urgency=medium
+
+ * Replace string hashing algorithm (Closes: #993433, CVE-2021-33582)
+
+ -- Yadd Thu, 02 Sep 2021 07:14:26 +0200
+
cyrus-imapd (3.0.8-6+deb10u5) buster; urgency=medium
* Fix cron script (Closes: #980240)
diff --git a/debian/patches/CVE-2021-33582.patch
b/debian/patches/CVE-2021-33582.patch
new file mode 100644
index ..4d74118d
--- /dev/null
+++ b/debian/patches/CVE-2021-33582.patch
@@ -0,0 +1,567 @@
+Description: Fixed CVE-2021-33582
+ Certain user inputs are used as hash table keys during processing. A
+ poorly chosen string hashing algorithm meant that the user could control
+ which bucket their data was stored in, allowing a malicious user to direct
+ many inputs to a single bucket. Each subsequent insertion to the same bucket
+ requires a strcmp of every other entry in it. At tens of thousands of
+ entries, each new insertion could keep the CPU busy in a strcmp loop for
+ minutes.
+ .
+ The string hashing algorithm has been replaced with a better one, and now
+ also uses a random seed per hash table, so malicious inputs cannot be
+ precomputed.
+ .
+ Discovered by Matthew Horsfall, Fastmail
+Author: ellie timoney
+Origin: upstream,
https://github.com/cyrusimap/cyrus-imapd/compare/cyrus-imapd-3.2.7...cyrus-imapd-3.2.8
+Bug: https://security-tracker.debian.org/tracker/CVE-2021-33582
+Forwarded: not-needed
+Reviewed-By: Yadd
+Last-Update: 2021-09-02
+
+--- a/Makefile.am
b/Makefile.am
+@@ -651,6 +651,7 @@
+ cunit/squat.testc \
+ cunit/strarray.testc \
+ cunit/strconcat.testc \
++ cunit/strhash.testc \
+ cunit/times.testc \
+ cunit/tok.testc \
+ cunit/vparse.testc
+--- a/configure.ac
b/configure.ac
+@@ -180,7 +180,7 @@
+
+ AC_CHECK_HEADERS(unistd.h sys/select.h sys/param.h stdarg.h)
+ AC_REPLACE_FUNCS(memmove strcasecmp ftruncate strerror posix_fadvise strsep
memmem)
+-AC_CHECK_FUNCS(strlcat strlcpy strnchr getgrouplist fmemopen pselect)
++AC_CHECK_FUNCS(strlcat strlcpy strnchr getgrouplist fmemopen pselect getline)
+ AC_HEADER_DIRENT
+
+ dnl check whether to use getpassphrase or getpass
+--- a/cunit/hash.testc
b/cunit/hash.testc
+@@ -117,6 +117,9 @@
+ hash_enumerate(, count_cb, );
+ CU_ASSERT_EQUAL(0, count);
+
++/* check hash_numrecords */
++CU_ASSERT_EQUAL(0, hash_numrecords());
++
+ /* free the hash table */
+ free_hash_table(, NULL);
+ }
+@@ -146,6 +149,9 @@
+ hash_enumerate(, count_cb, );
+ CU_ASSERT_EQUAL(1, count);
+
++/* check hash_numrecords */
++CU_ASSERT_EQUAL(1, hash_numrecords());
++
+ /* re-insert into the hash table */
+ d = hash_insert(KEY0, VALUE1, );
+ /* get the old value back */
+@@ -160,6 +166,9 @@
+ hash_enumerate(, count_cb, );
+ CU_ASSERT_EQUAL(1, count);
+
++/* check hash_numrecords */
++CU_ASSERT_EQUAL(1, hash_numrecords());
++
+ /* delete from the hash table */
+ d = hash_del(KEY0, );
+ CU_ASSERT_PTR_EQUAL(VALUE1, d);
+@@ -173,6 +182,9 @@
+ hash_enumerate(, count_cb, );
+ CU_ASSERT_EQUAL(0, count);
+
++/* check hash_numrecords */
++CU_ASSERT_EQUAL(0, hash_numrecords());
++
+ /* free the hash table */
+ free_hash_table(, NULL);
+ }
+@@ -239,6 +251,9 @@
+ hash_enumerate(, count_cb, );
+ CU_ASSERT_EQUAL(N, count);
+
++/* check hash_numrecords */
++CU_ASSERT_EQUAL(N, hash_numrecords());
++
+ /* delete from the hash table */
+ for (i = 0 ; i < N ; i++) {
+ d = hash_del(key(i), );
+@@ -256,6 +271,9 @@
+ hash_enumerate(, count_cb, );
+ CU_ASSERT_EQUAL(0, count);
+
++/* check hash_numrecords */
++CU_ASSERT_EQUAL(0, hash_numrecords());
++
+ /* free the hash table */
+ freed_count = 0;
+ free_hash_table(, lincoln);
+@@ -286,6 +304,9 @@
+ hash_enumerate(, count_cb, );
+ CU_ASSERT_EQUAL(N, count);
+
++/* check hash_numrecords */
++CU_ASSERT_EQUAL(N, hash_numrecords());
++
+ /* free the hash table */
+
Bug#991221: buster-pu: package mariadb-10.3 10.3.31-0+deb10u1
Hello! I uploaded this now: mariadb-10.3_10.3.31-0+deb10u1_source.changes ACCEPTED into oldstable-proposed-updates->oldstable-new Uploading without prior permissions is allowed according to https://lists.debian.org/debian-devel-announce/2018/04/msg7.html I will do the same for MariaDB 10.5 and Galera 4 and 3 unless somebody objects. - Otto
Bug#987378: yara breaks golang-github-hillu-go-yara autopkgtest + ftbfs
Hi, I think this is done now. With YARA 4.1.2 and golang-github-hillu-go-yara 4.1.0 now in unstable, the build works again as the build-time tests complete fine. @Hilko any other comments? Cheers Sascha
Bug#993497: RFS: thorvg/0.4.2-1 [ITP] -- library for drawing vector-based scenes
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "thorvg": * Package name: thorvg Version : 0.4.2-1 Upstream Author : Hermet Park * URL : https://www.thorvg.org/ * License : MIT * Vcs : https://github.com/Samsung/thorvg Section : libs It builds those binary packages: libthorvg-dev - library for drawing vector-based scenes (development headers) libthorvg-0.4.2-1 - library for drawing vector-based scenes To access further information about this package, please visit the following URL: https://mentors.debian.net/package/thorvg/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/t/thorvg/thorvg_0.4.2-1.dsc Changes for the initial release: thorvg (0.4.2-1) unstable; urgency=medium . * Fix the Picture crash issue if it reloads the image again. * Fix SVG Loader that wrongly parses the opacity percentage values. * Fix the Picture to return the bounds() size with the designated view size. * Fix the crash issue when the wrong pair of commands & points of Shapes are given. * Fix invalid memory access issues of TVG Loader. Regards, -- Michal Maciola
Bug#993502: RM: libhwsan0 [mips64el] -- NBS; not build anymore by source
Package: ftp.debian.org Severity: normal libhwsan0/mips64el has been built by mistake in gcc-11-mipsen/11.2.0-3 as an empty package. It therefore hasn't been built anymore in binNMU version 11.2.0-3+b1. Could you please remove it from the archive? Thanks, Aurelien
Bug#986997: ITA: netkit-telnet
All, I'm considering to adopt this package, as it has been orphaned for around five years in Debian. I wanted to reach out to some people (cc'd) that appear to have been involved in the discussions around it to make sure I'm not missing anything that should be considered. My aim is to 1) refresh the packaging including hopefully some autopkgtests, 2) figure out if there is a better upstream for this package, and 3) prepare to smooth out any issues preventing migrating towards inetutils in Debian. I have create a Salsa project and imported unstable debian/ and fixed some minor issues: https://salsa.debian.org/jas/netkit-telnet https://salsa.debian.org/jas/netkit-telnet/-/pipelines What do you think? /Simon signature.asc Description: PGP signature
Bug#993510: dolfinx: FTBFS with glibc 2.34
Source: dolfinx Version: 2019.2.0~git20210130.c14cb0a-5 Severity: important Hi Maintainer Your package uses a vendored copy of catch.hpp. It will FTBFS once glibc is upgraded to 2.34 due to MINSIGSTKSZ and SIGSTKSZ no longer being defined. You could take this opportunity to switch to using the catch2 package [1] in Debian where this is already fixed. Regards Graham [1] https://tracker.debian.org/pkg/catch2
Bug#993495:
Nope, i cannot reproduce it in a virtual machine.
Bug#987378: yara breaks golang-github-hillu-go-yara autopkgtest + ftbfs
Hi, On Thu, 2 Sep 2021 10:17:22 +0200 Sascha Steinbiss wrote: > I think this is done now. With YARA 4.1.2 and > golang-github-hillu-go-yara 4.1.0 now in unstable, the build works again > as the build-time tests complete fine. > > @Hilko any other comments? If there are incompatible API changes, the soname needs to be bumped. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#993518: osmcoastline: Does not work with projections other than WGS84
Source: osmcoastline Version: 2.3.0-1 Severity: important Tags: upstream Dear Maintainer, As reported by Jochen Topf on the Debian GIS list: " I just released a new version 2.3.1 of osmcoastline which contains an important fix: == Fix axis order problem with GDAL 3: In GDAL 3 the axis order for WGS84 changed from (lon, lat) to (lat, lon)! So we need to use the magic "CRS84" instead which does the same thing in GDAL 2 and GDAL 3. This is an important fix, without it osmcoastline doesn't work with GDAL 3 when using any output SRS other than WGS84. == Without this fix osmcoastline does not work in Debian Bullseye if you are using any projection but WGS84, this means the especially that the popular Mercator projection does not work. Sorry I only noticed that now due to insufficient automatic tests. It took me a day to find the problem, but the fix is quite easy. The release contains a few more things (including better tests), but if you only want a backport of that one fix: https://github.com/osmcode/osmcoastline/commit/a0a95090410106730d57eb31d2cf5869f4539be8 " Kind Regards, Bas
Bug#993523: bullseye-pu: package osmcoastline/2.3.0-1+deb11u1
Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: pkg-grass-de...@lists.alioth.debian.org
[ Reason ]
As reported on the GIS list by the upstream author, osmcoastline in
bullseye doesn't work with projections other than WGS84.
[ Impact ]
Only partially functional osmcoastline.
[ Tests ]
Upstream CI.
[ Risks ]
Very low.
[ Checklist ]
[x] *all* changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in (old)stable
[x] the issue is verified as fixed in unstable
[ Changes ]
Updated branch in gbp.conf & Vcs-Git URL.
Add upstream patch to fix #993518.
[ Other info ]
N/A
Kind Regards,
Bas
diff -Nru osmcoastline-2.3.0/debian/changelog
osmcoastline-2.3.0/debian/changelog
--- osmcoastline-2.3.0/debian/changelog 2021-01-08 16:22:58.0 +0100
+++ osmcoastline-2.3.0/debian/changelog 2021-09-02 15:43:37.0 +0200
@@ -1,3 +1,11 @@
+osmcoastline (2.3.0-1+deb11u1) bullseye; urgency=medium
+
+ * Update branch in gbp.conf & Vcs-Git URL.
+ * Add upstream patch to fix projections other than WGS84.
+(closes: #993518)
+
+ -- Bas Couwenberg Thu, 02 Sep 2021 15:43:37 +0200
+
osmcoastline (2.3.0-1) unstable; urgency=medium
* New upstream release.
diff -Nru osmcoastline-2.3.0/debian/control osmcoastline-2.3.0/debian/control
--- osmcoastline-2.3.0/debian/control 2021-01-08 16:22:30.0 +0100
+++ osmcoastline-2.3.0/debian/control 2021-09-02 15:43:31.0 +0200
@@ -18,7 +18,7 @@
zlib1g-dev
Standards-Version: 4.5.1
Vcs-Browser: https://salsa.debian.org/debian-gis-team/osmcoastline
-Vcs-Git: https://salsa.debian.org/debian-gis-team/osmcoastline.git
+Vcs-Git: https://salsa.debian.org/debian-gis-team/osmcoastline.git -b bullseye
Homepage: https://osmcode.org/osmcoastline/
Package: osmcoastline
diff -Nru osmcoastline-2.3.0/debian/gbp.conf osmcoastline-2.3.0/debian/gbp.conf
--- osmcoastline-2.3.0/debian/gbp.conf 2019-07-07 09:13:36.0 +0200
+++ osmcoastline-2.3.0/debian/gbp.conf 2021-09-02 15:43:23.0 +0200
@@ -6,7 +6,7 @@
# The default name for the Debian branch is "master".
# Change it if the name is different (for instance, "debian/unstable").
-debian-branch = master
+debian-branch = bullseye
# git-import-orig uses the following names for the upstream tags.
# Change the value if you are not using git-import-orig
diff -Nru
osmcoastline-2.3.0/debian/patches/0001-Fix-axis-order-problem-with-GDAL-3.patch
osmcoastline-2.3.0/debian/patches/0001-Fix-axis-order-problem-with-GDAL-3.patch
---
osmcoastline-2.3.0/debian/patches/0001-Fix-axis-order-problem-with-GDAL-3.patch
1970-01-01 01:00:00.0 +0100
+++
osmcoastline-2.3.0/debian/patches/0001-Fix-axis-order-problem-with-GDAL-3.patch
2021-09-02 15:43:37.0 +0200
@@ -0,0 +1,20 @@
+Description: Fix axis order problem with GDAL 3.
+ In GDAL 3 the axis order for WGS84 changed from lon, lat to lat, lon!
+ So we need to use the magic "CRS84" instead which does the same thing in
+ GDAL 2 and GDAL 3. See https://gdal.org/tutorials/osr_api_tut.html .
+Author: Jochen Topf
+Origin:
https://github.com/osmcode/osmcoastline/commit/a0a95090410106730d57eb31d2cf5869f4539be8
+Bug-Debian: https://bugs.debian.org/993518
+Forwarded: not-needed
+
+--- a/src/srs.hpp
b/src/srs.hpp
+@@ -60,7 +60,7 @@ public:
+ }; // class TransformationException
+
+ SRS() noexcept {
+-m_srs_wgs84.SetWellKnownGeogCS("WGS84");
++m_srs_wgs84.SetWellKnownGeogCS("CRS84");
+ }
+
+ /**
diff -Nru osmcoastline-2.3.0/debian/patches/series
osmcoastline-2.3.0/debian/patches/series
--- osmcoastline-2.3.0/debian/patches/series1970-01-01 01:00:00.0
+0100
+++ osmcoastline-2.3.0/debian/patches/series2021-09-02 15:43:37.0
+0200
@@ -0,0 +1 @@
+0001-Fix-axis-order-problem-with-GDAL-3.patch
Bug#993503: gcc-11-base: coinstallation error for mipsel
Package: gcc-11-base Version: 11.2.0-3 Severity: serious Justification: dpkg unpack error gcc-11-base's changelog.Debian.gz is different on mipsel than everywhere else. Indeed, the version is duplicate in the changelog. As such, gcc-11-base:mipsel fails to coinstall with everything else despite being marked Multi-Arch: same. | Unpacking gcc-11-base:mipsel (11.2.0-3) ... | dpkg: error processing archive /tmp/apt-dpkg-install-kpSb1U/012-gcc-11-base_11.2.0-3_mipsel.deb (--unpack): | trying to overwrite shared '/usr/share/doc/gcc-11-base/changelog.Debian.gz', which is different from other instances of package gcc-11-base:mipsel The cause seems to be a binary upload. Any normal upload should fix this issue without further changes. Helmut
Bug#993505: netgen-lvs FTBFS: configure: error: cannot find required auxiliary files: install-sh config.guess config.sub
Source: netgen-lvs
Version: 1.5.133-1
Severity: serious
Tags: ftbfs
netgen-lvs fails to build from source. A build on amd64 ends as follows:
|dh_autoreconf
| autoreconf: warning: autoconf input should be named 'configure.ac', not
'configure.in'
| aclocal: warning: autoconf input should be named 'configure.ac', not
'configure.in'
| configure.in:9: warning: The macro `AC_CANONICAL_SYSTEM' is obsolete.
| configure.in:9: You should run autoupdate.
| ./lib/autoconf/general.m4:2081: AC_CANONICAL_SYSTEM is expanded from...
| configure.in:9: the top level
| configure.in:25: warning: The macro `AC_ISC_POSIX' is obsolete.
| configure.in:25: You should run autoupdate.
| ./lib/autoconf/specific.m4:550: AC_ISC_POSIX is expanded from...
| configure.in:25: the top level
| configure.in:149: warning: The macro `AC_HEADER_STDC' is obsolete.
| configure.in:149: You should run autoupdate.
| ./lib/autoconf/headers.m4:704: AC_HEADER_STDC is expanded from...
| configure.in:149: the top level
| configure.in:171: warning: The macro `AC_TRY_LINK' is obsolete.
| configure.in:171: You should run autoupdate.
| ./lib/autoconf/general.m4:2920: AC_TRY_LINK is expanded from...
| configure.in:171: the top level
| configure.in:184: warning: The macro `AC_TRY_LINK' is obsolete.
| configure.in:184: You should run autoupdate.
| ./lib/autoconf/general.m4:2920: AC_TRY_LINK is expanded from...
| configure.in:184: the top level
| configure.in:874: warning: $as_echo is obsolete; use AS_ECHO(["message"])
instead
| configure.in:1293: warning: AC_OUTPUT should be used without arguments.
| configure.in:1293: You should run autoupdate.
| configure.in:1293: warning: AC_C_BIGENDIAN should be used with
AC_CONFIG_HEADERS
|debian/rules override_dh_auto_configure
| make[1]: Entering directory '/<>'
| dh_auto_configure -- --libdir=\${prefix}/lib
| ./configure --build=x86_64-linux-gnu --prefix=/usr
--includedir=\${prefix}/include --mandir=\${prefix}/share/man
--infodir=\${prefix}/share/info --sysconfdir=/etc --localstatedir=/var
--disable-option-checking --disable-silent-rules
--libdir=\${prefix}/lib/x86_64-linux-gnu --runstatedir=/run
--disable-maintainer-mode --disable-dependency-tracking --libdir=\${prefix}/lib
| configure: error: cannot find required auxiliary files: install-sh
config.guess config.sub
| dh_auto_configure: error: ./configure --build=x86_64-linux-gnu --prefix=/usr
--includedir=\${prefix}/include --mandir=\${prefix}/share/man
--infodir=\${prefix}/share/info --sysconfdir=/etc --localstatedir=/var
--disable-option-checking --disable-silent-rules
--libdir=\${prefix}/lib/x86_64-linux-gnu --runstatedir=/run
--disable-maintainer-mode --disable-dependency-tracking --libdir=\${prefix}/lib
returned exit code 1
| make[1]: *** [debian/rules:18: override_dh_auto_configure] Error 2
| make[1]: Leaving directory '/<>'
| make: *** [debian/rules:15: build] Error 2
| dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2
Helmut
Bug#993380: [pkg-lxc-devel] Bug#993380: lxc FTCBFS: compilation error in non-default code path
Control: tags -1 + upstream Control: forwarded -1 https://github.com/lxc/lxc/issues/3961 On Thu, Sep 02, 2021 at 12:21:08AM +0200, Pierre-Elliott Bécue wrote: > Would you like me to forward the bug to their github issue tracker? If > you prefer I'm eager to do it. But to be honest, as you did the work, I > would prefer if you handled it, opening an issue on > https://github.com/lxc/lxc/issues . Done. > If in your opinion there would be a preferred way to fix, please do > offer a patch! :) I prefer the upstream community figuring it out as they are going to maintain it. Helmut
Bug#993506: dublin-traceroute: Malformed packet error (fixed upstream)
Package: dublin-traceroute Version: 0.4.2-2+b1 Severity: normal Some hosts give me this error: > sudo dublin-traceroute 176.95.137.92 WARNING: you are running this program as root. Consider setting the CAP_NET_RAW capability and running as non-root user as a more secure alternative. Starting dublin-traceroute Traceroute from 0.0.0.0:12345 to 176.95.137.92:33434~33453 (probing 20 paths, min TTL is 1, max TTL is 30, delay is 10 ms) Failed: Malformed packet This may be the same or a regression of https://github.com/insomniacslk/dublin-traceroute/issues/27 . A fresh build from the current git head (06d4c881bded5dabf397bcce789840ec118ce874 , Apr 5 2021 ) doesn't give me the error and traces the route properly. -- System Information: Debian Release: 11.0 APT prefers stable APT policy: (990, 'stable'), (500, 'stable-security'), (50, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.13.7 (SMP w/16 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to de_DE.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 dublin-traceroute depends on: ii libc6 2.31-13 ii libdublintraceroute0 0.4.2-2+b1 ii libgcc-s1 10.2.1-6 ii libstdc++610.2.1-6 ii libtins4.04.0-1+b1 Versions of packages dublin-traceroute recommends: ii libcap2-bin 1:2.44-1 dublin-traceroute suggests no packages. -- no debconf information
Bug#993504: niceshaper FTCBFS: relinks with the build architecture compiler during make install
Source: niceshaper Version: 1.2.3-1 Tags: patch upstream User: debian-cr...@lists.debian.org Usertags: ftcbfs niceshaper fails to cross build from source, because make install relinks the main executable with the build architecture compiler. Such relinking is unnecessary and happens due to suboptimal makefile rules. The attached patch adjusts the rules, prevents the unnecessary relinking and makes niceshaper cross buildable. Please consider applying it. Helmut --- niceshaper-1.2.4.orig/src/Makefile +++ niceshaper-1.2.4/src/Makefile @@ -10,7 +10,8 @@ .cc.o: $(CXX) $(CPPFLAGS) $(CXXFLAGS) -c $< -all: $(OBJS) +all: $(TARGET) +$(TARGET): $(OBJS) $(CXX) $(OBJS) $(LDFLAGS) -o $(TARGET) clean: --- niceshaper-1.2.4.orig/Makefile +++ niceshaper-1.2.4/Makefile @@ -15,7 +15,7 @@ @echo "# Compiling" @echo "###" $(MAKE) -C src - mv src/$(TARGET) $(TARGET) + cp -a src/$(TARGET) $(TARGET) install: all @echo ""
Bug#993507: libgnutls30: fails to negotiate X25519 where NSS & OpenSSL succeed, success with X448
Package: libgnutls30 Version: 3.7.2-2 Severity: normal $ gnutls-cli --priority 'NORMAL:-GROUP-SECP256R1:-GROUP-SECP384R1:-GROUP-SECP521R1' fxtop.com Processed 138 CA certificate(s). Resolving 'fxtop.com:443'... Connecting to '5.39.68.178:443'... *** Fatal error: An illegal parameter has been received. $ openssl s_client -curves X25519 -connect fxtop.com:443 CONNECTED(0003) (... snip ...) --- No client certificate CA names sent Peer signing digest: SHA256 Peer signature type: RSA-PSS Server Temp Key: X25519, 253 bits --- (... snip ...) I attach a pcapng of network corresponding traffic. The same is reproducible with www.collaboraoffice.com instead of fxtop.com Note, though (not included in pcapng file): $ gnutls-cli --priority 'NORMAL:-GROUP-SECP256R1:-GROUP-SECP384R1:-GROUP-SECP521R1:-GROUP-X25519' fxtop.com (...) Resolving 'fxtop.com:443'... Connecting to '5.39.68.178:443'... (...) - Description: (TLS1.3)-(ECDHE-X448)-(RSA-PSS-RSAE-SHA256)-(AES-256-GCM) -- System Information: Debian Release: 10.10 APT prefers oldstable APT policy: (600, 'oldstable'), (500, 'oldstable-updates'), (400, 'testing'), (300, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.7.0-1-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_WARN Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8), LANGUAGE=en_GB.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libgnutls30 depends on: ii libc6 2.31-13 ii libgmp10 2:6.1.2+dfsg-4 ii libhogweed63.7.3-1 ii libidn2-0 2.0.5-1+deb10u1 ii libnettle8 3.7.3-1 ii libp11-kit00.23.22-1 ii libtasn1-6 4.16.0-2 ii libunistring2 0.9.10-1 libgnutls30 recommends no packages. Versions of packages libgnutls30 suggests: ii gnutls-bin 3.6.7-4+deb10u7 -- no debconf information -- Lionel Mamane Tél: +352 46 67 74 Fax: +352 46 67 76 This message and any attachments may be intended to be confidential, intended solely for the addressee and/or contain legally privileged information. Any unauthorised use or dissemination is prohibited. Unless cryptographically protected, emails are susceptible to interception, alteration and spoofing, so in case of doubt, please check by independent means. We do not make any commitment by email, ever; if this emails appears to contain a commitment, we will not recognise the latter as valid, nor as engaging our liability. We make commitments only by a written paper document signed by at least one person entitled to engage our liability. gnutls_openssl_x25519.pcapng Description: Binary data
Bug#993517: RM: mit-scheme [i386] -- ROM; i386 support removed upstream
Package: ftp.debian.org Severity: normal Upstream no longer supports building for i386. Well, trying to build on i386 runs out of memory, and upstream no longer releases i386 binaries, so I'm taking that to mean i386 support is kaput.
Bug#991919: List of all packages in BioConductor transition dependency level 1 failing due issue with either RUnit or testthat
Hi Andreas,
On 02-09-2021 13:12, Andreas Tille wrote:
> I did added an info about all those packages of level 1 that are failing
> either due to RUnit or testthat issues and here is a manually edited
> `grep -A8 '/jobs/' r-bioc-*/debian/changelog` on my local disk:
>
> r-bioc-biocparallel/debian/changelog: TODO:
> https://salsa.debian.org/r-pkg-team/r-bioc-biocparallel/-/jobs/1898498
> r-bioc-biocparallel/debian/changelog- >
> BiocGenerics:::testPackage("BiocParallel")
> r-bioc-biocparallel/debian/changelog- Error in library("RUnit", quietly =
> TRUE) :
> r-bioc-biocparallel/debian/changelog-there is no package called ‘RUnit’
> r-bioc-biocparallel/debian/changelog- Calls: -> library
> r-bioc-biocparallel/debian/changelog- Execution halted
I only checked this one.
> The packages in question are mentioned as Test-Depends and I have no
> idea why these are not found.
No, it's the autodep8 one that fails, not the one mentioned in
d/t/control. I don't recall of the top of my head how you can enhance
autodep8, but $(man autodep8) should come to the rescue.
Paul
OpenPGP_signature
Description: OpenPGP digital signature
Bug#977732: closing as won't fix for 3.9, fixed in 3.10
closing as won't fix for 3.9, fixed in 3.10.
Bug#992439: libconfig-model-dpkg-perl: blocks fails autopkgtest with recent licensecheck
Quoting Dominique Dumont (2021-09-02 12:41:03) > On Fri, 20 Aug 2021 02:57:28 +0200 gregor herrmann wrote: > > Right, there is e.g. > > https://ci.debian.net/data/autopkgtest/testing/amd64/libc/libconfig-model-dpkg-perl/14728439/log.gz > > with libconfig-model-dpkg-perl/2.147 licensecheck/3.2.11-1 and > > > > #v+ > > not ok 7 - check scikit-learn copyright > > > > # Failed test 'check scikit-learn copyright' > > # at t/scanner/scan-copyright.t line 27. > > # --- t/scanner/examples/scikit-learn.out Thu Aug 19 00:15:51 2021 > > # +++ /tmp/cKnQzIwFn2 Thu Aug 19 14:57:19 2021 > > # @@ -2,3 +2,7 @@ > > # Copyright: 2007-2019, The scikit-learn developers. > > # License: BSD-3-clause > > # > > # +Files: sklearn/* > > # +Copyright: no-info-found > > # +License: BSD-3-clause > > # + > > #v- > > Actually, this is related to: > > https://salsa.debian.org/perl-team/modules/packages/libconfig-model-dpkg-perl/-/commit/fb4dbe585de59a8aeb5d01904869a7f3415e35a5 > > (Note: I found this commit while checking the history of t/scanner/examples/ > scikit-learn.out) > > > And I still can't reproduce the failure locally. > > *sigh* > > I can reproduce this bug locally with libregexp-pattern-license-perl_3.4.0-1 > which is the version used in the FTBS build. > > This bug is gone after installing libregexp-pattern-license-perl/unstable. Thanks for looking into this, Dominique. Licensecheck does not promise any specific detection, so if your tool rely on specific detection then I guess it should declare tight dependencies on both App::Licensecheck and Regexp::Pattern::License. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#993512: openmsx: FTBFS with glibc 2.34
Source: openmsx Version: 17.0-1 Severity: important Hi Maintainer Your package uses a vendored copy of catch.hpp. It will FTBFS once glibc is upgraded to 2.34 due to MINSIGSTKSZ and SIGSTKSZ no longer being defined. You could take this opportunity to switch to using the catch2 package [1] in Debian where this is already fixed. Regards Graham [1] https://tracker.debian.org/pkg/catch2
Bug#993513: ensmallen: FTBFS with glibc 2.34
Source: ensmallen Version: 2.17.0-1 Severity: important Hi Maintainer Your package uses a vendored copy of catch.hpp. It will FTBFS once glibc is upgraded to 2.34 due to MINSIGSTKSZ and SIGSTKSZ no longer being defined. You could take this opportunity to switch to using the catch2 package [1] in Debian where this is already fixed. Regards Graham [1] https://tracker.debian.org/pkg/catch2
Bug#993522: buildbot-worker: Setting WORKER_OPTIONS to any non-empty value doesn't work
Package: buildbot-worker
Version: 2.10.1-1
Severity: normal
Dear Maintainer,
Setting WORKER_OPTIONS in /etc/default/buildbot-worker to e.g. "--verbose"
doesn't work because its value is used in a wrong place in the init.d
script: it does
"$WORKER_RUNNER $op ${WORKER_OPTIONS[$mi]} ${WORKER_BASEDIR[$mi]}
when the correct syntax would be
"$WORKER_RUNNER ${WORKER_OPTIONS[$mi]} $op ${WORKER_BASEDIR[$mi]}
i.e. the options must come _before_ the operation for buildbot-worker, not
after it.
-- System Information:
Debian Release: 11.0
APT prefers stable-security
APT policy: (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 5.10.0-8-amd64 (SMP w/12 CPU threads)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to
C.UTF-8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages buildbot-worker depends on:
ii lsb-base 11.1.0
ii passwd 1:4.8.1-1
ii python3 3.9.2-3
ii python3-future 0.18.2-5
ii python3-twisted 20.3.0-7
Versions of packages buildbot-worker recommends:
ii git 1:2.30.2-1
buildbot-worker suggests no packages.
-- Configuration Files:
/etc/default/buildbot-worker changed [not included]
-- no debconf information
pgpU1yClnS8cy.pgp
Description: PGP signature
Bug#989816: Duplicate
This seems like a duplicate of #934372 to me.
Bug#991919: List of all packages in BioConductor transition dependency level 1 failing due issue with either RUnit or testthat
Hi,
I did added an info about all those packages of level 1 that are failing
either due to RUnit or testthat issues and here is a manually edited
`grep -A8 '/jobs/' r-bioc-*/debian/changelog` on my local disk:
r-bioc-biocparallel/debian/changelog: TODO:
https://salsa.debian.org/r-pkg-team/r-bioc-biocparallel/-/jobs/1898498
r-bioc-biocparallel/debian/changelog- >
BiocGenerics:::testPackage("BiocParallel")
r-bioc-biocparallel/debian/changelog- Error in library("RUnit", quietly =
TRUE) :
r-bioc-biocparallel/debian/changelog-there is no package called ‘RUnit’
r-bioc-biocparallel/debian/changelog- Calls: -> library
r-bioc-biocparallel/debian/changelog- Execution halted
--
r-bioc-lpsymphony/debian/changelog: TODO:
https://salsa.debian.org/r-pkg-team/r-bioc-lpsymphony/-/jobs/1901441
r-bioc-lpsymphony/debian/changelog- > library(testthat)
r-bioc-lpsymphony/debian/changelog- Error in library(testthat) : there is no
package called ‘testthat’
r-bioc-lpsymphony/debian/changelog- Execution halted
--
r-bioc-matrixgenerics/debian/changelog:
https://salsa.debian.org/r-pkg-team/r-bioc-matrixgenerics/-/jobs/1901420
r-bioc-matrixgenerics/debian/changelog- > library(testthat)
r-bioc-matrixgenerics/debian/changelog- Error in library(testthat) : there
is no package called ‘testthat’
r-bioc-matrixgenerics/debian/changelog- Execution halted
--
r-bioc-protgenerics/debian/changelog: TODO:
https://salsa.debian.org/r-pkg-team/r-bioc-protgenerics/-/jobs/1902072
r-bioc-protgenerics/debian/changelog- > library("testthat")
r-bioc-protgenerics/debian/changelog- Error in library("testthat") : there is
no package called ‘testthat’
r-bioc-protgenerics/debian/changelog- Execution halted
--
r-bioc-s4vectors/debian/changelog: TODO:
https://salsa.debian.org/r-pkg-team/r-bioc-s4vectors/-/jobs/1897207
r-bioc-s4vectors/debian/changelog- > S4Vectors:::.test()
r-bioc-s4vectors/debian/changelog- Error in library("RUnit", quietly = TRUE) :
r-bioc-s4vectors/debian/changelog-there is no package called ‘RUnit’
r-bioc-s4vectors/debian/changelog- Calls: -> -> library
r-bioc-s4vectors/debian/changelog- Execution halted
--
r-bioc-seqlogo/debian/changelog: TODO:
https://salsa.debian.org/r-pkg-team/r-bioc-seqlogo/-/jobs/1898537
r-bioc-seqlogo/debian/changelog- > library(testthat)
r-bioc-seqlogo/debian/changelog- Error in library(testthat) : there is no
package called ‘testthat’
r-bioc-seqlogo/debian/changelog- Execution halted
--
r-bioc-tximport/debian/changelog: TODO:
https://salsa.debian.org/r-pkg-team/r-bioc-tximport/-/jobs/1902367
r-bioc-tximport/debian/changelog- strangely enough it had
r-bioc-tximport/debian/changelog- > skip_if_not_installed("tximportData")
r-bioc-tximport/debian/changelog- Error: Reason: tximportData cannot be
loaded
r-bioc-tximport/debian/changelog- Execution halted
r-bioc-tximport/debian/changelog- In my local build I get
r-bioc-tximport/debian/changelog- > library(testthat)
r-bioc-tximport/debian/changelog- Error in library(testthat) : there is no
package called ‘testthat’
The packages in question are mentioned as Test-Depends and I have no
idea why these are not found.
The transition is effectively blocked by these issues and any ideas are
really welcome.
Kind regards
Andreas.
--
http://fam-tille.de
Bug#993511: spdlog: FTBFS with glibc 2.34
Source: spdlog Version: 1:1.8.5+ds-2 Severity: important Hi Maintainer Your package uses a vendored copy of catch.hpp. It will FTBFS once glibc is upgraded to 2.34 due to MINSIGSTKSZ and SIGSTKSZ no longer being defined. You could take this opportunity to switch to using the catch2 package [1] in Debian where this is already fixed. Regards Graham [1] https://tracker.debian.org/pkg/catch2
Bug#993519: termonad: Could not find module Termonad.App, Termonad.Config, Termonad.Config.Colour
Package: termonad Version: 4.0.0.1-1 Severity: wishlist Dear Maintainer, Hello. I, according to my needs, i wanted to build my custom-configured version of Termonad. So I created a termonad.hs file in the directory ~ / .config / termonad /. However, the program fa iled to configure because ghc could not find module 'Termonad.App', 'Termonad.Config', 'Termonad.Config.Colour'. After stepping deeper, i realized that i needed to install a separate package called libghc-termonad-dev, which apparently attracted other necessary dependencies. It is very strange that in Debian, this package (libghc-termonad-dev) is not in the the proposed Termonad package. I think, when installed in the standard way, you get a terminal emulator that can be used, but whose configuration options are limited. Therefore, I would suggest adding a descriptio n to the Termonad package so that users who are configuring this program know what dependencies are required (libghc-termonad-dev). Here is a link to my published problem description for the author of this package (bug report now is closed) https://github.com/cdepillabout/termonad/issues/197 -- System Information: Debian Release: 11.0 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-8-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_FIRMWARE_WORKAROUND, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=lt_LT.UTF-8, LC_CTYPE=lt_LT.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 termonad depends on: ii libatk1.0-02.36.0-2 ii libc6 2.31-13 ii libcairo-gobject2 1.16.0-5 ii libcairo2 1.16.0-5 ii libffi73.3-6 ii libgdk-pixbuf2.0-0 2.40.2-2 ii libgirepository-1.0-1 1.66.1-1+b1 ii libglib2.0-0 2.66.8-1 ii libgmp10 2:6.2.1+dfsg-1 ii libgtk-3-0 3.24.24-4 ii libharfbuzz-gobject0 2.7.4-1 ii libharfbuzz0b 2.7.4-1 ii libpango-1.0-0 1.46.2-3 ii libpangocairo-1.0-01.46.2-3 ii libpcre2-8-0 10.36-2 ii libvte-2.91-0 0.62.3-1 ii libyaml-0-20.2.2-1 ii zlib1g 1:1.2.11.dfsg-2 termonad recommends no packages. termonad suggests no packages. -- no debconf information
Bug#993516: dolfin: FTBFS with glibc 2.34
Source: dolfin Version: 2019.2.0~git20201207.b495043-5 Severity: important Hi Maintainer Your package uses a vendored copy of catch.hpp. It will FTBFS once glibc is upgraded to 2.34 due to MINSIGSTKSZ and SIGSTKSZ no longer being defined. You could take this opportunity to switch to using the catch package [1] in Debian where this still needs to be fixed (see #993515). Regards Graham [1] https://tracker.debian.org/pkg/catch
Bug#993520: O: fosfat -- API for the Smaky file system
Package: wnpp Severity: normal X-Debbugs-Cc: fos...@packages.debian.org Control: affects -1 src:fosfat I have orphaned the fosfat package for reasons independant of this package, or of Debian. The package description is: Fosfat is a C library for providing read-only access to a Smaky formatted disk. Currently, only a tool and a FUSE extension that use this library can be used for reading a directory and copying a file. . The Smaky is a line of mostly 8-bit personal computers and accompanying operating system developed at the EPFL (École Polytechnique Federale de Lausanne), in Switzerland, from 1974. . This package contains the libfosfat0, which provides the API for the Smaky file system.
Bug#993391: [pkg-lxc-devel] Bug#993391: lxc: Unprivileged lxc example from README.Debian.gz gives AppArmor error "Failed to mount proc"
Can you post your complete config for autopkgtest-lxc-xwkkud, autopkgtest-unstable or other working unpriv container? Your output reads "unprivileged true". Thanks
Bug#983591: iproute2: running 'ip -6 -r route' results in printing an unitialized buffer for the hostname on 'dev' routes
Control: tags -1 moreinfo
On Fri, 26 Feb 2021 21:41:17 +0100 Axel Scheepers
wrote:
> Package: iproute2
> Version: 5.10.0-4
> Severity: normal
> Tags: ipv6
>
> Dear Maintainer,
>
> * What led up to the situation?
>
> Using ip -6 -r route shows (on 10.8) either an information leak:
> $ ip -6 -r r
> +U dev lo proto kernel metric 256 pref medium
>
> or (on testing) empty output:
>
> $ ip -6 -r r
> dev lo proto kernel metric 256 pref medium
>
> for the resolved hostname.
>
> * What outcome did you expect instead?
>
> Printing of the resolved name, e.g. 'localhost' for dev lo.
>
> Reading the source and a bit of printf debugging i can see it's
> in lib/utils.c, format_host_r:
>
> 1113z20n
> 1113 const char *format_host_r(int af, int len, const void *addr,
> 1114 char *buf, int buflen)
> 1115 {
> 1116 #ifdef RESOLVE_HOSTNAMES
> 1117 if (resolve_hosts) {
> 1118 const char *n;
> 1119
> 1120 puts("XXX: here");
> 1121 len = len <= 0 ? af_byte_len(af) : len;
> 1122
> 1123 if (len > 0 &&
> 1124 (n = resolve_address(addr, len, af)) !=
> NULL)
> 1125 {
> 1126 printf("n is '%s'\n", n);
> 1127 strncpy(buf, n, buflen);
> 1128 return n;
> 1129 }
> 1130 }
> 1131 #endif
>
>
> results in:
> ./ip/ip -6 -r r
> XXX: here
> n is 'localhost'
> localhost dev lo proto kernel metric 256 pref medium
>
>
> Something better then this awful hack should be implemented i guess.
>
> Kind regards,
This is fixed for me with 5.13, which is now in testing - can you
confirm?
$ ip -6 -r r
localhost dev lo proto kernel metric 256 pref medium
$ ip -V
ip utility, iproute2-5.13.0, libbpf 0.4.0
--
Kind regards,
Luca Boccassi
signature.asc
Description: This is a digitally signed message part
Bug#993509: etags segfaults
Package: universal-ctags Version: 0+git20200824-1.1 ctags-universal binary segfaults when started as etags on Bullseye in Docker. /usr/bin/etags -> /etc/alternatives/etags -> /usr/bin/ctags-universal # /usr/bin/ctags-universal ctags-universal: No files specified. Try "ctags-universal --help". # /usr/bin/etags Segmentation fault (core dumped) etags[16739]: segfault at 58 ip 55a97283eea6 sp 7ffe02002528 error 4 in ctags-universal[55a972834000+97000] Code: 74 24 08 48 89 43 20 48 83 c4 10 48 89 c7 5b e9 60 93 00 00 48 63 ff 48 8b 15 56 2b 0e 00 48 8d 04 bf 48 8d 04 47 48 8d 04 c2 <48> 8b 10 89 f0 83 e0 01 0f b6 b2 0c 01 00 00 83 e6 fe 09 c6 40 88
Bug#992439: libconfig-model-dpkg-perl: blocks fails autopkgtest with recent licensecheck
On Fri, 20 Aug 2021 02:57:28 +0200 gregor herrmann wrote: > Right, there is e.g. > https://ci.debian.net/data/autopkgtest/testing/amd64/libc/libconfig-model-dpkg-perl/14728439/log.gz > with libconfig-model-dpkg-perl/2.147 licensecheck/3.2.11-1 and > > #v+ > not ok 7 - check scikit-learn copyright > > # Failed test 'check scikit-learn copyright' > # at t/scanner/scan-copyright.t line 27. > # --- t/scanner/examples/scikit-learn.out Thu Aug 19 00:15:51 2021 > # +++ /tmp/cKnQzIwFn2 Thu Aug 19 14:57:19 2021 > # @@ -2,3 +2,7 @@ > # Copyright: 2007-2019, The scikit-learn developers. > # License: BSD-3-clause > # > # +Files: sklearn/* > # +Copyright: no-info-found > # +License: BSD-3-clause > # + > #v- Actually, this is related to: https://salsa.debian.org/perl-team/modules/packages/libconfig-model-dpkg-perl/-/commit/fb4dbe585de59a8aeb5d01904869a7f3415e35a5 (Note: I found this commit while checking the history of t/scanner/examples/ scikit-learn.out) > And I still can't reproduce the failure locally. > *sigh* I can reproduce this bug locally with libregexp-pattern-license-perl_3.4.0-1 which is the version used in the FTBS build. This bug is gone after installing libregexp-pattern-license-perl/unstable. HTH
Bug#993515: catch: FTBFS with glibc 2.34
Source: catch Version: 1.12.1-1.1 Severity: important Hi Maintainer Catch will FTBFS once glibc is upgraded to 2.34 due to MINSIGSTKSZ and SIGSTKSZ no longer being defined. This was fixed Catch2's upstream [1]. I'm not sure if this can be adapted for Catch(1). Another approach is to simply replace SIGSTKSZ with a constant, as done in Fedora [2]. Regards Graham [1] https://github.com/catchorg/Catch2/issues/2178 [2] https://src.fedoraproject.org/rpms/catch1/c/059104ba87494c0b5ebe16844ec190f253e51cac
Bug#993514: perl/experimental FTBFS with gdbm 1.20
Source: perl Version: 5.34.0-1 Severity: serious Tags: ftbfs fixed-upstream Forwarded: https://github.com/Perl/perl5/issues/18915 https://tests.reproducible-builds.org/debian/rb-pkg/experimental/amd64/perl.html https://buildd.debian.org/status/package.php?p=perl=experimental ... Failed 1 test out of 2544, 99.96% okay. ../ext/GDBM_File/t/gdbm.t ... make[2]: *** [makefile:808: test] Error 1
Bug#993521: buildbot-worker: Setting WORKER_OPTIONS to any non-empty value doesn't work
Package: buildbot-worker
Version: 2.10.1-1
Severity: normal
X-Debbugs-Cc: vz-deb...@zeitlins.org
Dear Maintainer,
Setting WORKER_OPTIONS in /etc/default/buildbot-worker to e.g. "--verbose"
doesn't work because its value is used in a wrong place in the init.d
script: it does
"$WORKER_RUNNER $op ${WORKER_OPTIONS[$mi]} ${WORKER_BASEDIR[$mi]}
when the correct syntax would be
"$WORKER_RUNNER ${WORKER_OPTIONS[$mi]} $op ${WORKER_BASEDIR[$mi]}
i.e. the options must come _before_ the operation for buildbot-worker, not
after it.
-- System Information:
Debian Release: 11.0
APT prefers stable-security
APT policy: (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 5.10.0-8-amd64 (SMP w/12 CPU threads)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to
C.UTF-8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages buildbot-worker depends on:
ii lsb-base 11.1.0
ii passwd 1:4.8.1-1
ii python3 3.9.2-3
ii python3-future 0.18.2-5
ii python3-twisted 20.3.0-7
Versions of packages buildbot-worker recommends:
ii git 1:2.30.2-1
buildbot-worker suggests no packages.
-- Configuration Files:
/etc/default/buildbot-worker changed [not included]
-- no debconf information
Bug#993525: /var/log/ufw.log not re-opened from rsyslog
Package: ufw Version: 0.36-7.1 Postrotate in /etc/logrotate.d/ufw still wants to use invoke-rc.d rsyslog rotate to signal HUP to rsyslog, which is not available w/ systemd. Other packages use /usr/lib/rsyslog/rsyslog-rotate, which handles SysV/systemd automatically. Patch attached. Thank you. Regards,Bastian Triller logrotate.diff Description: Binary data
Bug#989051: mrc: FTBFS on hppa - obj/mrc_rsrc.o created with wrong OS/ABI
Dear Dave, Thanks for reporting, and apologies for not responding earlier. I found the underlying problem, apparently the ABI field of the ELF header should contain a flag indicating it is a Linux executable. In order to set this flag properly, I need to find out various things and perhaps it is easiest to try to figure out these myself. Is it possible to get access to a HPPA machine running Debian? I am a Debian maintainer, if that makes any difference. Otherwise, could you provide me the output of `cpp -dM /dev/null` and perhaps also how to detect PA-RISC/Debian in a cmake file. That last question is perhaps a bit too much to ask for, but any hint is appreciated. regards, -maarten Op 24-05-2021 om 20:09 schreef John David Anglin: Source: mrc Version: 1.2.3-2 Severity: normal Dear Maintainer, The build fails with the following error: make[1]: Entering directory '/<>' mrc.cpp dummy.cpp g++ -std=c++17 -o mrc-bootstrap obj/mrc.o obj/dummy.o -L/usr/lib/hppa-linux-gnu -lboost_program_options ./mrc-bootstrap -o obj/mrc_rsrc.o mrsrc.h g++ -std=c++17 -o mrc obj/mrc.o obj/mrc_rsrc.o -L/usr/lib/hppa-linux-gnu -lboost_program_options /usr/bin/ld: unknown architecture of input file `obj/mrc_rsrc.o' is incompatible with hppa1.1 output collect2: error: ld returned 1 exit status make[1]: *** [GNUmakefile:87: mrc] Error 1 As far as I can tell, this occurs because obj/mrc_rsrc.o is created with the wrong OS/ABI: dave@mx3210:~/debian/mrc/mrc-1.2.3$ file obj/mrc_rsrc.o obj/mrc_rsrc.o: ELF 32-bit MSB relocatable, PA-RISC, 1.1 version 1 (SYSV), not stripped SYSV should be GNU/Linux: dave@mx3210:~/debian/mrc/mrc-1.2.3$ file obj/mrc.o obj/mrc.o: ELF 32-bit MSB relocatable, PA-RISC, 1.1 version 1 (GNU/Linux), with debug_info, not stripped Not sure why this happens. Regards, Dave Anglin -- System Information: Debian Release: 11.0 APT prefers buildd-unstable APT policy: (500, 'buildd-unstable'), (500, 'unstable') Architecture: hppa (parisc64) Kernel: Linux 5.10.39+ (SMP w/4 CPU threads) Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) -- Maarten L. Hekkelman http://www.hekkelman.com/
Bug#993526: thunderbird: Movemail support removed in Thunderbird v91
Hello Mikhail, Am 02.09.21 um 18:05 schrieb Mikhail Morfikov: It looks like that with the version of 91, Thunderbird removed support for Movemail accounts. There's no way to setup such account anymore with this version, and all already present account are removed without any info or warning. At least the mail stayed intact. I had to install the previous version (1:78.13.0-1) to revert the unpleasant change. and what do you expect as further action? If you want to complain about the removal you need to address this to MZLNA. Debian is packaging what upstream is providing, some things might need some adjustment to be in compliance with the Debian project rules. But at least for Thunderbird and similar packages we do not re-add and maintain features we can't keep up to date in the long run. Following the bug report you pointed it's obvious that the user base is simply to small that it will come back in the near future. I see no work I or Debian needs to do here and will close this report by this email. -- Regards Carsten
Bug#993508: RFS: howardhinnant-date/3.0.1-1 [ITP] -- date and time library based on the C++ header
Package: sponsorship-requests Severity: wishlist X-Debbugs-Cc: martin.quin...@ens-rennes.fr -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Dear mentors, I am looking for a sponsor for my package "howardhinnant-date": * Package name: howardhinnant-date Version : 3.0.1-1 Upstream Author : Howard Hinnant * URL : https://github.com/HowardHinnant/date * License : Expat * Vcs : https://github.com/HowardHinnant/date.git Section : libs It builds those binary packages: libhowardhinnant-date-tz3 - date and time library based on the C++ header libhowardhinnant-date-dev - date and time library based on the C++ header - development files To access further information about this package, please visit the following URL: https://mentors.debian.net/package/howardhinnant-date/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/h/howardhinnant- date/howardhinnant-date_3.0.1-1.dsc Changes since the last upload: howardhinnant-date (3.0.1-1) UNRELEASED; urgency=low . * Initial release. Closes: #895222 Regards, - -- Andrea Pappacoda -BEGIN PGP SIGNATURE- iIoEARYIADIWIQSlw/BqXszDGx3GlQz/yQfijUdG7QUCYTCm0xQcYW5kcmVhQHBh cHBhY29kYS5pdAAKCRD/yQfijUdG7SCyAP9B+9t+Lhpaeqa+UjyuzcyWFZ13jdbK k4YK0FoUH2EfagEAmNYX6tua6Rd6ndq9xySvoqOdX74/USSAPZIJ2NbzPgc= =cGa3 -END PGP SIGNATURE-
Bug#898259: RFP: vscode -- Microsoft Visual Studio Code
On Thu, 7 Jan 2021 14:55:47 +0200 Anya Annetova wrote: Any progress on this? See #842420, the blocker for this and many many other programs. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=842420 Jonathan Rubenstein jrub...@gmail.com
Bug#993528: lintian-brush: debhelper-but-no-misc-depends.py does not consider Pre-Depends
Package: lintian-brush
Version: 0.109
Severity: normal
I have received a merge request from the Debian Janitor for ncurses
which looks incorrect to me, see my comment at [1].
It seems that the script fixers/debhelper-but-no-misc-depends.py does
not look at ${misc:Depends} in Pre-Depends, but should do so.
1. https://salsa.debian.org/debian/ncurses/-/merge_requests/5
Bug#992692: general: Use https for {deb,security}.debian.org by default
On 2021-09-02 10:22:15 +0900 (+0900), Hideki Yamane wrote: [...] > Providing "default secure setting" is good message to users. [...] As previously covered, I'd suggest steering clear of referring to this as adding "default security." That implies APT wasn't already effectively secure over plain HTTP, and may give a false impression that HTTPS is addressing gaps in the existing apt-secure design. This change is more about recognizing HTTPS as the primary transport protocol for the modern Web, not sending mixed signals regarding the general security risks posed by plain HTTP when used for unrelated purposes, and no longer needing to repeatedly explain to users that Debian has gone to great lengths to implement package distribution security which doesn't really depend at all on transport layer encryption. -- Jeremy Stanley signature.asc Description: PGP signature
Bug#993529: mlocate: cruft left behind on purge
Package: mlocate Version: 1.1.10-2 Severity: normal I have noticed that some cruft remained on the system after purging the mlocate package, namely - a dangling symlink /etc/systemd/system/timers.target.wants/mlocate.timer - a statoverride for /usr/bin/mlocate in the dpkg database The postrm script in mlocate version 0.26-5 cleaned these up on purge, for the transitional package it might make more sense to do it in the postinst. See the attached log file which reproduces the problems in a throwaway chroot (install mlocate 0.26-5, upgrade to 1.1.10-2 and purge the package). -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable'), (101, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.61-nouveau (SMP w/2 CPU threads) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) # find / -name "mlocate*" /var/cache/apt/archives/mlocate_0.26-5_amd64.deb # dpkg -i $(find / -name "mlocate*") Selecting previously unselected package mlocate. (Reading database ... 12635 files and directories currently installed.) Preparing to unpack .../mlocate_0.26-5_amd64.deb ... Unpacking mlocate (0.26-5) ... Setting up mlocate (0.26-5) ... update-alternatives: using /usr/bin/mlocate to provide /usr/bin/locate (locate) in auto mode Adding group `mlocate' (GID 102) ... Done. # apt upgrade Reading package lists... Done Building dependency tree... Done Reading state information... Done Calculating upgrade... Done The following NEW packages will be installed: liburing1 plocate The following packages will be upgraded: mlocate 1 upgraded, 2 newly installed, 0 to remove and 0 not upgraded. Need to get 4544 B/133 kB of archives. After this operation, 57.3 kB of additional disk space will be used. Do you want to continue? [Y/n] Get:1 http://ftp.de.debian.org/debian sid/main amd64 mlocate all 1.1.10-2 [4544 B] Fetched 4544 B in 0s (9658 B/s) debconf: delaying package configuration, since apt-utils is not installed Selecting previously unselected package liburing1:amd64. (Reading database ... 12698 files and directories currently installed.) Preparing to unpack .../liburing1_0.7-3_amd64.deb ... Unpacking liburing1:amd64 (0.7-3) ... Preparing to unpack .../mlocate_1.1.10-2_all.deb ... Unpacking mlocate (1.1.10-2) over (0.26-5) ... Selecting previously unselected package plocate. Preparing to unpack .../plocate_1.1.10-2_amd64.deb ... Unpacking plocate (1.1.10-2) ... Setting up liburing1:amd64 (0.7-3) ... Setting up plocate (1.1.10-2) ... Installing new version of config file /etc/updatedb.conf ... update-alternatives: warning: alternative /usr/bin/mlocate (part of link group locate) doesn't exist; removing from list of alternatives update-alternatives: warning: /etc/alternatives/locate is dangling; it will be updated with best choice update-alternatives: using /usr/bin/plocate to provide /usr/bin/locate (locate) in auto mode Adding group `plocate' (GID 103) ... Done. Setting up mlocate (1.1.10-2) ... Removing obsolete conffile /etc/cron.daily/mlocate ... Processing triggers for libc-bin (2.31-17) ... # apt purge mlocate Reading package lists... Done Building dependency tree... Done Reading state information... Done The following packages were automatically installed and are no longer required: liburing1 plocate Use 'sudo apt autoremove' to remove them. The following packages will be REMOVED: mlocate* 0 upgraded, 0 newly installed, 1 to remove and 0 not upgraded. After this operation, 14.3 kB disk space will be freed. Do you want to continue? [Y/n] (Reading database ... 12659 files and directories currently installed.) Removing mlocate (1.1.10-2) ... (Reading database ... 12656 files and directories currently installed.) Purging configuration files for mlocate (1.1.10-2) ... # find / -name "mlocate*" /etc/systemd/system/timers.target.wants/mlocate.timer /var/cache/apt/archives/mlocate_0.26-5_amd64.deb /var/lib/systemd/deb-systemd-helper-enabled/timers.target.wants/mlocate.timer /var/lib/systemd/deb-systemd-helper-enabled/mlocate.timer.dsh-also # dpkg-statoverride --list | grep mlocate root mlocate 2755 /usr/bin/mlocate
Bug#992692: general: Use https for {deb,security}.debian.org by default
On 2021-09-02 12:27:34 -0400 (-0400), Roberto C. Sánchez wrote: [...] > In this context, it might make sense to describe using HTTPS as > the transport for APT operations is providing "default > confidentiality". Which, as similarly discussed, it really doesn't do either (because of deterministic blob sizes for publicly served files, current SNI implementations leaking hostnames, general state of the CA and CDN industries...), so suggesting that may also give users a false impression. If they really do need confidentiality of their package installation, they're probably better off doing updates over Tor or a some VPN which does batching/interleaving of bulk transfers with some cover traffic, or keeping a private local package mirror. But to a great extent the degree of confidentiality they can expect really depends on who they're trying to hide their traffic from. If their concern is that a company headquartered in the USA might be tracking the packages they're downloading from deb.debian.org, then that's already a possibility even with HTTPS: the site is currently fronted by the Fastly CDN service which terminates TLS encryption for those HTTPS requests in order to be able to cache them globally. Of course, without a CDN, mirror site operators can track what packages you're downloading from them over HTTPS as well. More generally, what I'm saying is don't try to paint this change as actually implementing any significant amount of new security or privacy for Debian users, that would be disingenuous. Just say the default is switching to HTTPS because that's what users, by and large, expect today. -- Jeremy Stanley signature.asc Description: PGP signature
Bug#993522: buildbot-worker: Setting WORKER_OPTIONS to any non-empty value doesn't work
Hi Vadim,
2021-09-02, Vadim Zeitlin:
> Package: buildbot-worker
> Version: 2.10.1-1
> Severity: normal
>
> Dear Maintainer,
>
> Setting WORKER_OPTIONS in /etc/default/buildbot-worker to e.g. "--verbose"
> doesn't work because its value is used in a wrong place in the init.d
> script: it does
>
> "$WORKER_RUNNER $op ${WORKER_OPTIONS[$mi]} ${WORKER_BASEDIR[$mi]}
>
> when the correct syntax would be
>
> "$WORKER_RUNNER ${WORKER_OPTIONS[$mi]} $op ${WORKER_BASEDIR[$mi]}
>
> i.e. the options must come _before_ the operation for buildbot-worker, not
> after it.
Actually, this is only true for the --verbose option. Other options must
be passed after $op.
> -- System Information:
> Debian Release: 11.0
> APT prefers stable-security
> APT policy: (500, 'stable-security'), (500, 'stable')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 5.10.0-8-amd64 (SMP w/12 CPU threads)
> Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set
> to C.UTF-8), LANGUAGE=en_US:en
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
I see that you are using systemd. You should not use the init.d script
but the systemd unit template which is provided with the package. There
are examples in the man page to tweak the unit parameters:
https://manpages.debian.org/bullseye/buildbot-worker/buildbot-worker.7.en.html#systemd
In your case, you should override ExecStart= in a drop-in file.
Also, it looks like this is a duplicate of bug #993521. Should I close
the first one?
--
Robin
Bug#985196: on OpenRD "client" ( arch = armv5tel ) Upgraded from Buster to Bullseye and haveged stoped working.
I had the same problem when I upgraded my SheevaPlug (armel) from Buster to Bullseye. I found this thread: https://archlinuxarm.org/forum/viewtopic.php?f=15=14549 Adding the following service override makes haveged start as expected: root@puny:~# cat /etc/systemd/system/haveged.service.d/override.conf [Service] SystemCallFilter=uname Please would you consider including that for armel packages? Cheers, Dave
Bug#993501: Merge request on Salsa
Hi. I have created a merge request on salsa for this fix. https://salsa.debian.org/debian/openssl/-/merge_requests/6 Mattias signature.asc Description: This is a digitally signed message part
Bug#954998: libconfig-model-dpkg-perl: cme edit dpkg does not start
Hi Sorry for the late reply. I had a freelance mission from April to August that did not leave me much free time (or energy). On Thu, 26 Mar 2020 10:38:38 -0500 Ryan Pavlik wrote: > Recently, I have had cme edit dpkg stop working on my Buster system, which is mostly clean, > with some use of buster-backports. This seemed to occur in conjunction with an update in which > lintian was upgraded - lintian (2.59.0~bpo10+1) over (2.55.0~bpo10+1). However, downgrading > (to 2.57~bpo10+1 at least) did not resolve it, so perhaps it was something unrelated. Lintian 2.57 brought a change to an API that broke cme. Long story short, libconfig-model-dpkg-perl >= 2.132 depends on lintian >= 2.57 And libconfig-model-dpkg-perl < 2.132 must use lintian < 2.57 Please get back to me if this is too inconvenient to backport cme and I'll suggest a patch to cope with this breakage in lintian API. HTH Dod
Bug#983591: iproute2: running 'ip -6 -r route' results in printing an unitialized buffer for the hostname on 'dev' routes
Hello Luca, On Thu, Sep 02, 2021 at 11:44:09AM +0100, Luca Boccassi wrote: > This is fixed for me with 5.13, which is now in testing - can you > confirm? Yes indeed it works on testing for me too, thanks! Kind regards, Axel Scheepers
Bug#984849: dpkg-divert: too sensitive to order of command-line args
Hello, On Thu, Sep 02, 2021 at 04:16:36AM +0200, Guillem Jover wrote: > On Mon, 2021-03-08 at 22:35:49 -0800, Ross Vandegrift wrote: > > dpkg-divert is too sensitive to the order of the command line parameters. > > Since I only use it rarely, I almost always run into: > > > > # dpkg-divert --add /wooo --divert /yeah --rename > > dpkg-divert: warning: please specify --no-rename explicitly, the default > > will change to --rename in 1.20.x > > dpkg-divert: error: --add needs a single argument > > > > Use --help for help about diverting files. > > > > The fix is to move --add last. But neither the error nor the manpage makes > > that clear. > > Both the man page and the --help output mention that the usage is: > > dpkg-divert [...] > > And then go to list the commands and options on their respective > sections. While I guess I could add a hint or similar on the error > message (because modifying the way this is parsed would be a pain), > that seems it would be too specific for such a generic message. So > I'm inclined to leave it as is, TBH. If you have an alternative > suggestion I'm happy to consider, otherwise I'm afraid I'll just > going to close the report. I don't have any good suggestions - I think usage would be more obvious if the commands weren't prefixed with dashes, but that would cause much worse breakage. If the parsing is too hard to change, then leaving it as-is is sounds reasonable. Thanks for thinking about it, feel free to close. Ross
Bug#993530: ddcutil version bump
Package: enlightenment Version: 0.24.2-8 - Forwarded message from Sanford Rockowitz - Date: Thu, 2 Sep 2021 01:11:11 -0400 From: Sanford Rockowitz To: pkg-e-de...@lists.alioth.debian.org Cc: Andrey Rahmatullin Subject: Fwd: ddcutil version bump User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.23) Gecko/20090812 Thunderbird/2.0.0.23 Mnenhy/0.7.6.666 And, I neglected to mention, update Recommends: libddcutil3 to Recommends: libddcutil4 Forwarded Message Subject:ddcutil version bump Date: Wed, 1 Sep 2021 23:45:37 -0400 From: Sanford Rockowitz Organization: Minaret Software To: pkg-e-de...@lists.alioth.debian.org CC: Andrey Rahmatullin The latest ddcutil release (1.1.0) that's about to go into sid increments the shared library to libddcutil.so.4. I've reviewed the code in file e_system_ddc.c. There are no changes that affect your use of the API. All you need to do is check for libddcutil.so.4 before libddcutil.so.3 and libddcutil.so.2. Regards, Sanford Rockowitz ddcutil developer -- Pkg-e-devel mailing list pkg-e-de...@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-e-devel - End forwarded message -
Bug#993526: thunderbird: Movemail support removed in Thunderbird v91
Package: thunderbird Version: 1:91.0~b5-1 Severity: important Dear Maintainer, It looks like that with the version of 91, Thunderbird removed support for Movemail accounts. There's no way to setup such account anymore with this version, and all already present account are removed without any info or warning. At least the mail stayed intact. I had to install the previous version (1:78.13.0-1) to revert the unpleasant change. More info at: https://developer.thunderbird.net/planning/roadmap https://bugzilla.mozilla.org/show_bug.cgi?id=1625741
Bug#993527: mariadb-server: At full-upgrade from buster to bullseye mariadb-server (and also client) are removed.
Package: mariadb-server Version: 1:10.5.11-1 Severity: normal Tags: a11y Dear Maintainer, I upgraded my Webserver from Buster to Bullseye. During the upgrade mariadb-server and mariadb-client was removed from the server. A apt install mariadb-server mariadb-client and everything was working fine again, no loose of databases or other information. Only official Debian sources in apt.sorces.list. A friend of mine told me that this happens yesterday night, so I tried today to report as bug if I can confirm. Greetings and Thanks for your work on Debian Sven -- System Information: Debian Release: 11.0 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-17-amd64 (SMP w/2 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) Versions of packages mariadb-server depends on: ii mariadb-server-10.5 1:10.5.11-1 mariadb-server recommends no packages. mariadb-server suggests no packages. -- no debconf information
Bug#992692: general: Use https for {deb,security}.debian.org by default
On Thu, Sep 02, 2021 at 04:08:37PM +, Jeremy Stanley wrote: > On 2021-09-02 10:22:15 +0900 (+0900), Hideki Yamane wrote: > [...] > > Providing "default secure setting" is good message to users. > [...] > > As previously covered, I'd suggest steering clear of referring to > this as adding "default security." That implies APT wasn't already > effectively secure over plain HTTP, and may give a false impression > that HTTPS is addressing gaps in the existing apt-secure design. > > This change is more about recognizing HTTPS as the primary transport > protocol for the modern Web, not sending mixed signals regarding the > general security risks posed by plain HTTP when used for unrelated > purposes, and no longer needing to repeatedly explain to users that > Debian has gone to great lengths to implement package distribution > security which doesn't really depend at all on transport layer > encryption. In this context, it might make sense to describe using HTTPS as the transport for APT operations is providing "default confidentiality". Regards, -Roberto -- Roberto C. Sánchez
Bug#993524: calibre: pypy3compile "Failed to byte-compile ..." from postinst
Package: calibre Version: 5.26.0+dfsg-2 Severity: normal Dear Maintainer, Installing calibre 5.26.0+dfsg-2 on a system with pypy3 7.3.5+dfsg-2 installed produced the following message: Setting up calibre (5.26.0+dfsg-2) ... Failed to byte-compile /usr/lib/calibre/calibre/utils/formatter.py: File "/usr/lib/calibre/calibre/utils/formatter.py", line 928 if v := self.expr(expr): ^ SyntaxError: invalid syntax It appears that /var/lib/dpkg/info/calibre.postinst contains 2 calls to py3compile and pypy3compile for /usr/lib/calibre, first with -V 3.7-, then with -V 3.9: -8<--[calibre.postinst from line 28]-- if which py3compile >/dev/null 2>&1; then py3compile -p calibre /usr/lib/calibre -V 3.7- fi if which pypy3compile >/dev/null 2>&1; then pypy3compile -p calibre /usr/lib/calibre -V 3.7- || true fi # Automatically added by dh_python3 if which py3compile >/dev/null 2>&1; then py3compile -p calibre /usr/lib/calibre -V 3.9 fi if which pypy3compile >/dev/null 2>&1; then pypy3compile -p calibre /usr/lib/calibre -V 3.9 || true fi if which py3compile >/dev/null 2>&1; then py3compile -p calibre /usr/share/calibre -V 3.9 fi if which pypy3compile >/dev/null 2>&1; then pypy3compile -p calibre /usr/share/calibre -V 3.9 || true fi -8<--[calibre.postinst]--- On my system, `pypy3compile -p calibre /usr/lib/calibre -V 3.7-` produces the error. It appears that removing the calls to py3compile and pypy3compile from debian/calibre.postinst in favor of the ones added by dh_python3 would avoid the issue. Thanks, Kevin -- System Information: Debian Release: bookworm/sid APT prefers testing-debug APT policy: (990, 'testing-debug'), (990, 'testing'), (500, 'unstable-debug'), (500, 'stable-debug'), (500, 'oldoldstable'), (500, 'unstable'), (101, 'experimental'), (1, 'experimental-debug') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.14.0-rc7 (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 calibre depends on: ii calibre-bin 5.26.0+dfsg-2 ii dpkg 1.20.9 ii fonts-liberation22.1.4-2 ii imagemagick 8:6.9.11.60+dfsg-1.3 ii imagemagick-6.q16 [imagemagick] 8:6.9.11.60+dfsg-1.3 ii libjpeg-turbo-progs 1:2.0.6-4 ii libjxr-tools 1.1-6+b1 ii optipng 0.7.7-1+b1 ii poppler-utils20.09.0-3.1 ii python3 3.9.2-3 ii python3-apsw 3.34.0-r1-1 ii python3-bs4 4.9.3-1 ii python3-chardet 4.0.0-1 ii python3-chm 0.8.6-2+b3 ii python3-css-parser 1.0.6-1 ii python3-cssselect1.1.0+ds-1 ii python3-cssutils 1.0.2-3 ii python3-dateutil 2.8.1-6 ii python3-feedparser 5.2.1-3 ii python3-html2text2020.1.16-1 ii python3-html5-parser 0.4.9-3+b3 ii python3-html5lib 1.1-3 ii python3-jeepney 0.6.0-1 ii python3-lxml 4.6.3+dfsg-0.1 ii python3-markdown 3.3.4-1 ii python3-mechanize1:0.4.5-2 ii python3-msgpack 1.0.2-2 ii python3-netifaces0.10.9-0.2+b3 ii python3-pil 8.1.2+dfsg-0.3 ii python3-pkg-resources52.0.0-4 ii python3-py7zr0.11.3+dfsg-1 ii python3-pygments 2.7.1+dfsg-2.1 ii python3-pyparsing2.4.7-1 ii python3-pyqt55.15.2+dfsg-3 ii python3-pyqt5.qtsvg 5.15.2+dfsg-3 ii python3-pyqt5.qtwebengine5.15.2-2 ii python3-pyqt5.sip12.8.1-1+b2 ii python3-regex0.1.20201113-1 ii python3-routes 2.5.1-1 ii python3-speechd 0.10.2-2 ii python3-zeroconf 0.26.1-1 ii python3.93.9.2-1 ii xdg-utils1.1.3-4.1 Versions of packages calibre recommends: ii python3-dnspython 2.0.0-1 pn python3-ipython ii udisks22.9.3-1 Versions of packages calibre suggests: ii python3-openssl 20.0.1-1 pn python3-unrardll -- no debconf information
Bug#992442: bzip2: Use tempfile in /usr/bin/bzexe, which is no longer available
Control: tags -1 + pending On Wed, 18 Aug 2021 12:34:23 -0400 Boyuan Yang wrote: > Package: bzip2 > Severity: grave > Version: 1.0.8-4 > Control: tags -1 sid > X-Debbugs-CC: santi...@debian.org santi...@debian.org > > Dear Debian bzip2 package maintainers, > > As discussed in https://bugs.debian.org/992396 , the tempfile command has been > removed from debianutils package. However, it looks like the bzexe command > provided by Debian still uses it: > > https://sources.debian.org/src/bzip2/1.0.8-4/debian/bzexe/#L123 > > > set -C > umask=`umask` > umask 77 > tmpfile=`tempfile -p gztmp -d /tmp` || exit 1 > > > Please consider switching to mktemp(1) provided by GNU coreutils. > > Thanks, > Boyuan Yang Fixed in git. signature.asc Description: PGP signature
Bug#982177: Bullseye has been released
Hi Just a reminder that Bullseye has been released, so I think this blocking bug should be closed Best regards Carlos
Bug#992439: libconfig-model-dpkg-perl: blocks fails autopkgtest with recent licensecheck
On Thu, 02 Sep 2021 12:41:03 +0200, Dominique Dumont wrote: > Actually, this is related to: > > https://salsa.debian.org/perl-team/modules/packages/libconfig-model-dpkg-perl/-/commit/fb4dbe585de59a8aeb5d01904869a7f3415e35a5 > > (Note: I found this commit while checking the history of t/scanner/examples/ > scikit-learn.out) Merci bien ! I looked again into this issue yesterday and didn't find anything … (I also didn't go back far enough in history.) > > And I still can't reproduce the failure locally. > > *sigh* > I can reproduce this bug locally with libregexp-pattern-license-perl_3.4.0-1 > which is the version used in the FTBS build. Oh; that explains why I didn't see it in pure unstable chroots. Cheers, gregor (PS: Sorry about the mess I created in git and the archive with the upload of the same version number when I missed the interim releases into experimental.) -- .''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06 `. `' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe `- NP: Ludwig Hirsch: Der Dorftrottel signature.asc Description: Digital Signature
Bug#993522: Re[2]: Bug#993522: buildbot-worker: Setting WORKER_OPTIONS to any non-empty value doesn't work
On Thu, 2 Sep 2021 16:27:27 +0200 Robin Jarry wrote:
> 2021-09-02, Vadim Zeitlin:
> > Package: buildbot-worker
> > Version: 2.10.1-1
> > Severity: normal
> >
> > Dear Maintainer,
> >
> > Setting WORKER_OPTIONS in /etc/default/buildbot-worker to e.g. "--verbose"
> > doesn't work because its value is used in a wrong place in the init.d
> > script: it does
> >
> > "$WORKER_RUNNER $op ${WORKER_OPTIONS[$mi]} ${WORKER_BASEDIR[$mi]}
> >
> > when the correct syntax would be
> >
> > "$WORKER_RUNNER ${WORKER_OPTIONS[$mi]} $op ${WORKER_BASEDIR[$mi]}
> >
> > i.e. the options must come before the operation for buildbot-worker, not
> > after it.
>
> Actually, this is only true for the --verbose option. Other options must
> be passed after $op.
Hello and thank you for your reply!
Yes, indeed, sorry, I haven't realized this. Even the symmetric --quiet
option does need to come after the operation. So this looks like poor
buildbot command line UI and not a problem in the package itself, finally.
> I see that you are using systemd. You should not use the init.d script
> but the systemd unit template which is provided with the package. There
> are examples in the man page to tweak the unit parameters:
>
> https://manpages.debian.org/bullseye/buildbot-worker/buildbot-worker.7.en.html#systemd
>
> In your case, you should override ExecStart= in a drop-in file.
Oh, I see... it's really a comedy of errors and it looks like I did just
about everything wrong because I did try using systemd, but when I saw that
the buildbot-worker.service was masked, I've removed the file
/lib/systemd/system/buildbot-worker.service to unmask it -- instead of
using buildbot-worker@$NAME which is, as I now understand, the right thing
to do. And while this allowed me to run "systemctl start buildbot-worker",
in the meanwhile I had added "--verbose" to the defaults file to help me
debugging the problem and this "--verbose" actually prevented things from
working.
> Also, it looks like this is a duplicate of bug #993521. Should I close
> the first one?
Yes, sorry about this one too, I've resent the bug report accidentally.
I've tried to correct the problem by merging the 2 reports, but I'm not
sure if I made things better or worse by doing it.
In any case, it looks like both bug reports should be closed and the only
thing to do might be to update the comment in the defaults file to say that
the "--verbose" option can't be used there.
Thanks again for your reply and explanations!
VZ
pgpdR0QSDOh5j.pgp
Description: PGP signature
Bug#992216: thunderbird: Version 91 available upstream and fixes security problems
Just for the record, the FTP-Masters accepted 1:91.0-1 and 1:91.0.2-1 from the new queue. Should be installable already. -- Regards Carsten
Bug#993169: fixed in eckit 1.17.1-2
Dear Alastair, On Sun, 29 Aug 2021 12:03:45 + Debian FTP Masters wrote: >* Drop support for 32-bit archs. Closes: #993169 Don't forget to ask ftp-master to remove the existing binaries on those architectures where it built in the past. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#993393: sensible-utils: [INTL:de] updated German man page translation
Hello Bastien, On Wed, Sep 01, 2021 at 08:04:00PM +, Bastien Roucariès wrote: > This is not a patch how can I apply ? This is the updated file. Just place it in man/po4a. As it has been done (by you) several times in the past already. (And happens in any other case as well). Greetings Helge -- Dr. Helge Kreutzmann deb...@helgefjell.de Dipl.-Phys. http://www.helgefjell.de/debian.php 64bit GNU powered gpg signed mail preferred Help keep free software "libre": http://www.ffii.de/ signature.asc Description: PGP signature
Bug#993391: [pkg-lxc-devel] Bug#993391: lxc: Unprivileged lxc example from README.Debian.gz gives AppArmor error "Failed to mount proc"
Hi, pk writes: > Hello, > > I copy-pasted configuration and commands from > /usr/share/doc/lxc/README.Debian.gz under "Unprivileged containers". > Are you talking about another file? > https://salsa.debian.org/lxc-team/lxc/-/blob/7d692c266c63fced9417042ae904cc2a280b96d8/debian/README.Debian The configuration in that file is lxc.include = /etc/lxc/default.conf lxc.idmap = u 0 10 65536 lxc.idmap = g 0 10 65536 lxc.mount.auto = proc:mixed sys:ro cgroup:mixed lxc.apparmor.profile = unconfined and goes to ~/.config/lxc/default.conf You removed at least the lxc.include statement, and actually tried something of your own, in particular not creating a default config for your user and a container afterwards. > lxc.rootfs defaults to the system root / per lxc.container.conf(5). Which is not acceptable for an *unprivileged* container, which is the case you brought here. The reason why Apparmor intervenes instead of letting either init crash upon startup (because not being able to manipulate the filesystem) or things explode is because lxc.apparmor.profile doesn't apply to lxc-start call, but to only to the lxc child process. > Creation is unnecessary, it is just a convenience to avoid -f and does > not affect the container runtime. My (still privileged) lxc setup > works perfectly with -f without ever creating any containers. Creation is necessary as you need a valid rootfs to work, and a valid rootfs for an unprivileged container has to fit the usernamespace which will be created upon startup of the container. "/" is not a valid rootfs for an unprivileged container as the uid mappings are totally out of line. You therefore need to at least create one container using lxc-create or manually create a rootfs using mmdebstrap or whatever fits best. > I pasted full logs above. You pasted truncated logs, and actually did not follow the README. > Please try to be respectful and helpful, do not reproduce on a > configured machine, and leave bug triaging to the lxc experts. Being one of the LXC maintainers, I'm totally entitled to triage your bug report, especially since what you claim being a bug does not look like one. I won't reply to your assumption about my expertise. Please follow the README properly and if that fails please come back with full logs. With best regards, -- PEB signature.asc Description: PGP signature
Bug#993527: [debian-mysql] Bug#993527: mariadb-server: At full-upgrade from buster to bullseye mariadb-server (and also client) are removed.
On Thu, 2 Sep 2021 10:50:29 -0700 Otto Kekäläinen wrote: > Please test with the version in Debian testing. > > An identical version is about to enter Bullseye in next stable update. I do not think, that it has to do with the mariadb-server Version, I paste the output of /var/log/apt/history.log here. The mariadb-server was upgraded, and after upgrade removed. I removed anything, that has not mariadb in its name from the log: Start-Date: 2021-09-02 18:00:08 Commandline: apt full-upgrade Install: ., mariadb-client-10.5:amd64 (1:10.5.11-1, automatic), ., mariadb-client-core-10.5:amd64 (1:10.5.11-1, automatic), . Upgrade: , mariadb-client:amd64 (1:10.3.29-0+deb10u1, 1:10.5.11-1), Remove: , mariadb-server:amd64 (1:10.3.29-0+deb10u1),.., mariadb-server-core-10.3:amd64 (1:10.3.29-0+deb10u1), ., mariadb-client-10.3:amd64 (1:10.3.29-0+deb10u1), .., mariadb-server-10.3:amd64 (1:10.3.29-0+deb10u1), , mariadb-client-core-10.3:amd64 (1:10.3.29-0+deb10u1), End-Date: 2021-09-02 18:02:04
Bug#993507: libgnutls30: fails to negotiate X25519 where NSS & OpenSSL succeed, success with X448
tags 993507 +upstream forwarded 993507 https://gitlab.com/gnutls/gnutls/-/issues/1249 retitle 993507 libgnutls30: client 'illegal parameter' error when both X25519 and X448 are enabled and the server picks one of those thanks On Thu, Sep 02, 2021 at 12:04:02PM +0200, Lionel Elie Mamane wrote: > $ gnutls-cli --priority > 'NORMAL:-GROUP-SECP256R1:-GROUP-SECP384R1:-GROUP-SECP521R1' fxtop.com > *** Fatal error: An illegal parameter has been received. > $ gnutls-cli --priority > 'NORMAL:-GROUP-SECP256R1:-GROUP-SECP384R1:-GROUP-SECP521R1:-GROUP-X25519' > fxtop.com > - Description: (TLS1.3)-(ECDHE-X448)-(RSA-PSS-RSAE-SHA256)-(AES-256-GCM) $ gnutls-cli --priority 'NORMAL:-GROUP-ALL:+GROUP-X25519' fxtop.com succeeds, too, in line with the upstream bug description, It is not immediately obvious to me in what released version that upstream bug is fixed. -- Lionel
Bug#993536: xfce4-panel: Wrong copyright year for 4.16.3
Package: xfce4-panel Version: 4.16.3-1 Severity: minor X-Debbugs-Cc: ed7-aspire4...@hotmail.com Issue: The version in question isn't released in 2018. Remedy: Pull `panel/panel-dialogs.c` from upstream which has the new copyright year of 2021. -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads) 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 not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages xfce4-panel depends on: ii exo-utils4.16.2-1 ii libatk1.0-0 2.36.0-2 ii libc62.31-17 ii libcairo21.16.0-5 ii libdbusmenu-gtk3-4 18.10.20180917~bzr492+repack1-2+b1 ii libexo-2-0 4.16.2-1 ii libgarcon-1-04.16.1-1 ii libgarcon-gtk3-1-0 4.16.1-1 ii libgdk-pixbuf-2.0-0 2.42.6+dfsg-2 ii libglib2.0-0 2.68.4-1 ii libgtk-3-0 3.24.30-2 ii libpango-1.0-0 1.48.9+ds1-2 ii libpangocairo-1.0-0 1.48.9+ds1-2 ii libwnck-3-0 3.36.0-1+b1 ii libx11-6 2:1.7.2-1 ii libxext6 2:1.3.3-1.1 ii libxfce4panel-2.0-4 4.16.3-1 ii libxfce4ui-2-0 4.16.0-1+b1 ii libxfce4util74.16.0-1 ii libxfconf-0-34.16.0-2 xfce4-panel recommends no packages. xfce4-panel suggests no packages. -- no debconf information
Bug#992435: devscripts 2.21.3+deb11u1 flagged for acceptance
package release.debian.org tags 992435 = bullseye pending thanks Hi, The upload referenced by this bug report has been flagged for acceptance into the proposed-updates queue for Debian bullseye. Thanks for your contribution! Upload details == Package: devscripts Version: 2.21.3+deb11u1 Explanation: make --bpo target bullseye-backports
Bug#993049: rpki-trust-anchors 20210817-1~deb11u1 flagged for acceptance
package release.debian.org tags 993049 = bullseye pending thanks Hi, The upload referenced by this bug report has been flagged for acceptance into the proposed-updates queue for Debian bullseye. Thanks for your contribution! Upload details == Package: rpki-trust-anchors Version: 20210817-1~deb11u1 Explanation: add https URL to the LACNIC TAL
Bug#993277: krb5 1.18.3-6+deb11u1 flagged for acceptance
package release.debian.org tags 993277 = bullseye pending thanks Hi, The upload referenced by this bug report has been flagged for acceptance into the proposed-updates queue for Debian bullseye. Thanks for your contribution! Upload details == Package: krb5 Version: 1.18.3-6+deb11u1 Explanation: fix KDC null dereference crash on FAST request with no server field [CVE-2021-37750]; fix memory leak in krb5_gss_inquire_cred
Bug#992078: libbluray 1.2.1-4+deb11u1 flagged for acceptance
package release.debian.org tags 992078 = bullseye pending thanks Hi, The upload referenced by this bug report has been flagged for acceptance into the proposed-updates queue for Debian bullseye. Thanks for your contribution! Upload details == Package: libbluray Version: 1.2.1-4+deb11u1 Explanation: switch to embedded libasm. The version from libasm-java is too new
Bug#993535: linux: Enable CONFIG_EVM
> I'd also consider to enable non-default CONFIG_EVM_ATTR_FSUUID. Actually CONFIG_EVM_ATTR_FSUUID is enabled by default. But I'd consider enabling also CONFIG_ENCRYPTED_KEYS as it's enabled for Ubuntu [1] Thanks! Kind regards, Petr [1] https://patchwork.ozlabs.org/project/ubuntu-kernel/patch/1403911081-32056-6-git-send-email-tyhi...@canonical.com/
Bug#993534: 389-ds-base breaks dogtag-pki autopkgtest: CA spawn failed
Source: 389-ds-base, dogtag-pki
Control: found -1 389-ds-base/1.4.4.16-1
Control: found -1 dogtag-pki/10.10.2-3
Severity: serious
Tags: sid bookworm
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: breaks needs-update
Dear maintainer(s),
With a recent upload of 389-ds-base the autopkgtest of dogtag-pki fails
in testing when that autopkgtest is run with the binary packages of
389-ds-base from unstable. It passes when run with only packages from
testing. In tabular form:
passfail
389-ds-basefrom testing1.4.4.16-1
dogtag-pki from testing10.10.2-3
all others from testingfrom testing
I copied some of the output at the bottom of this report.
Currently this regression is blocking the migration of 389-ds-base to
testing [1]. Due to the nature of this issue, I filed this bug report
against both packages. Can you please investigate the situation and
reassign the bug to the right package?
More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation
Paul
[1] https://qa.debian.org/excuses.php?package=389-ds-base
https://ci.debian.net/data/autopkgtest/testing/amd64/d/dogtag-pki/14986372/log.gz
autopkgtest [09:10:45]: test pkispawn: [---
IP address is 192.168.122.100
Hostname was:
/etc/hosts now has:
127.0.0.1 localhost
::1 localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
192.168.122.100 autopkgtest.debci autopkgtest
Starting installation...
Completed installation for pki-tomcat
Notice: Trust flag u is set automatically if the private key is present.
/usr/lib/python3/dist-packages/urllib3/connection.py:455:
SubjectAltNameWarning: Certificate for autopkgtest.debci has no
`subjectAltName`, falling back to check for a `commonName` for now. This
feature is being removed by major browsers and deprecated by RFC 2818.
(See https://github.com/urllib3/urllib3/issues/497 for details.)
warnings.warn(
Loading deployment configuration from debian/tests/deploy.cfg.
Installation log: /var/log/pki/pki-ca-spawn.20210902091106.log
Installing CA into /var/lib/pki/pki-tomcat.
Installation failed:
HTTP Status 404 – Not
Foundbody
{font-family:Tahoma,Arial,sans-serif;} h1, h2, h3, b
{color:white;background-color:#525D76;} h1 {font-size:22px;} h2
{font-size:16px;} h3 {font-size:14px;} p {font-size:12px;} a
{color:black;} .line
{height:1px;background-color:#525D76;border:none;}HTTP
Status 404 – Not FoundType Status
ReportMessage The requested resource
[caadmincagetStatus] is not
availableDescription The origin server did not find a
current representation for the target resource or is not willing to
disclose that one exists.Apache Tomcat/9.0.43
(Debian)
Please check the CA logs in /var/log/pki/pki-tomcat/ca.
CA spawn failed:
autopkgtest [09:12:24]: test pkispawn: ---]
OpenPGP_signature
Description: OpenPGP digital signature
Bug#993391: [pkg-lxc-devel] Bug#993391: Bug#993391: lxc: Unprivileged lxc example from README.Debian.gz gives AppArmor error "Failed to mount proc"
pk writes: > Can you post your complete config for autopkgtest-lxc-xwkkud, > autopkgtest-unstable or other working unpriv container? Your output > reads "unprivileged true". Because they are unprivileged which is the topic of the current discussion. -- PEB signature.asc Description: PGP signature
Bug#993539: "functions/Misc.zwc" isn't compiled from the bundled source files
Package: zsh-common
Version: 5.8-7
Files affected (at least):
/usr/share/zsh/functions/Misc.zwc
/usr/share/zsh/functions/Misc/run-help
If I try to call "run-help" at a ZSH prompt, it reports:
> $ run-help
> There is no list of special help topics available at this time.
And trying to use it to see the help text for any built-in command just
opens a man page for zsh...
Turns out that the default HISTDIR (which is wrong) in the file that
contains the bytecode compiled version of "run-help" is different from the
default in the source code "run-help" file:
> $ grep 'HELPDIR:-/' /usr/share/zsh/functions/Misc/run-help
> local HELPDIR=${HELPDIR:-/usr/share/zsh/help}
> $ strings /usr/share/zsh/functions/Misc.zwc | grep 'HELPDIR:-/'
> HELPDIR:-/usr/share/zsh/5.8/help
> HELPDIR:-/usr/share/zsh/5.8/help
Setting HELPDIR fixes it, as expected.
It seems something went wrong in a modified building process for this
package --all sourced and compiled files for functions have identical
modification times, so at least they were "touched". I couldn't find a way,
inspecting the build script (debian/rules) and the source for "run-help",
it would end with this result.
Best,
Leonardo Gama
[image: https://]about.me/leogama
Bug#993526: thunderbird: Movemail support removed in Thunderbird v91
You need to keep the BTS within the mail loop so others can follow the conversion too! Am 02.09.21 um 19:34 schrieb Mikhail Morfikov: At least to notify people about this change with upgrade to v91 because I was really surprised when one of my accounts disappeared without any info. Did you have read the official release notes? https://www.thunderbird.net/en-US/thunderbird/91.0/releasenotes/ It's listed under changes. I see no gain to duplicate this information somewhere in Debian. Maybe if more people will complain about the feature removal, the upstream will bring it back. Maybe, but I expect no return of this feature. -- Regards Carsten
Bug#993531: lintian: doesn't know about conffile remove-on-upgrade tag
Package: lintian Version: 2.104.0 Severity: normal Dear Maintainer, I was building my package (chkboot 1.3-8) when lintian reported the following tags: ``` E: chkboot: conffile-is-not-in-package remove-on-upgrade /etc/kernel/postinst.d/zzz-chkboot E: chkboot: conffile-is-not-in-package remove-on-upgrade /etc/kernel/postrm.d/zzz-chkboot E: chkboot: non-etc-file-marked-as-conffile remove-on-upgrade /etc/kernel/postinst.d/zzz-chkboot E: chkboot: non-etc-file-marked-as-conffile remove-on-upgrade /etc/kernel/postrm.d/zzz-chkboot E: chkboot: relative-conffile remove-on-upgrade /etc/kernel/postinst.d/zzz-chkboot E: chkboot: relative-conffile remove-on-upgrade /etc/kernel/postrm.d/zzz-chkboot ``` Based on the following conffile generated by dpkg 1.20.9 and debhelper 13.5.1: ``` remove-on-upgrade /etc/kernel/postinst.d/zzz-chkboot remove-on-upgrade /etc/kernel/postrm.d/zzz-chkboot /etc/apt/apt.conf.d/05chkboot /etc/default/chkboot /etc/init.d/chkboot /etc/profile.d/chkboot-profilealert.sh ``` The remove-on-upgrade tag is a new feature from dpkg 1.20.6 as stated in deb-conffiles(5): ``` There is currently only one flag supported, remove-on-upgrade, to mark that a conffile needs to be removed on the next upgrade (since dpkg 1.20.6). These files must not exist in the binary package, as both dpkg(1) and dpkg-deb(1) will not accept building nor processing such binary packages. ``` Lintian should skip the tag if present while checking for the given tags. Best, -- Baptiste Beauplat - lyknode signature.asc Description: PGP signature
Bug#993533: netgen: please mark autopkgtest as superficial
Source: netgen Version: 6.2.2006+really6.2.1905+dfsg-2.1 Severity: important X-Debbugs-CC: debian...@lists.debian.org User: debian...@lists.debian.org Usertags: issue Hi Maintainer, Your package has an autopkgtest, great. However, I noticed that the test coverage is very limited. Because of the way the results of autopkgtests are used in Debian to influence migration, the Release Team demands [1] such tests to be marked as superficial. Paul [1] https://release.debian.org/testing/rc_policy.txt 6(a) OpenPGP_signature Description: OpenPGP digital signature
Bug#993535: linux: Enable CONFIG_EVM
Source: linux Version: linux-support-5.13.0-trunk Severity: wishlist Dear Maintainer, #972459 reenabled CONFIG_IMA for linux/5.13.9-1~exp1 (thanks!). Could you please enable also CONFIG_EVM, as EVM is commonly used with IMA? I'd also consider to enable non-default CONFIG_EVM_ATTR_FSUUID. If you have additional questions about the setup, feel free to ask on linux-integrity ML or directly Mimi Zohar (IMA/EVM maintainer). Thanks! Kind regards, Petr -- System Information: Debian Release: bookworm/sid APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.13.0-trunk-amd64 (SMP w/4 CPU threads) Locale: LANG=en_GB.utf8, LC_CTYPE=cs_CZ.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB.utf8 Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#993538: libzapojit: CVE-2021-39360
Source: libzapojit Version: 0.0.3-5 Severity: important Tags: security upstream Forwarded: https://gitlab.gnome.org/GNOME/libzapojit/-/issues/4 X-Debbugs-Cc: car...@debian.org, Debian Security Team Hi, The following vulnerability was published for libzapojit. CVE-2021-39360[0]: | In GNOME libzapojit through 0.0.3, zpj-skydrive.c does not enable TLS | certificate verification on the SoupSessionSync objects it creates, | leaving users vulnerable to network MITM attacks. NOTE: this is | similar to CVE-2016-20011. 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-2021-39360 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-39360 [1] https://gitlab.gnome.org/GNOME/libzapojit/-/issues/4 Regards, Salvatore
Bug#992693: bullseye-pu: package glibc/2.31-13+deb11u1
On 2021-08-22 14:58, Aurelien Jarno wrote: > Package: release.debian.org > Severity: normal > Tags: bullseye > User: release.debian@packages.debian.org > Usertags: pu > X-Debbugs-Cc: debian-gl...@lists.debian.org > > [ Reason ] > During the upgrade from Buster to Bullseye, the SSH server is not > restarted following the libc6 upgrade, causing new SSH connections to > get rejected until the SSH server is restarted later in the upgrade. > > It could be considered as a regression as it didn't happen during the > upgrade from Stretch to Buster. > > [ Impact ] > Upgrade might fail or get stuck for remote upgrade using SSH if for some > reason the SSH connection breaks. Using screen or tmux doesn't help here > as it is not possible to connect again using SSH. > > [ Tests ] > This is not covered by any automated test. This has been tested using a > VM with a fresh Buster installation. This code is in unstable for a few > days, and no issue has been reported so far. Please note that the code is now in testing. Regards, Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Bug#993394: transition: glibc 2.32
On 2021-08-31 20:54, Aurelien Jarno wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: transition > X-Debbugs-Cc: debian-gl...@lists.debian.org > > Dear release team, > > I would like to get a transition slot for glibc 2.32. It has been built > successfully on all release architectures except mips*el, however I have > successfully built them manually on eller.d.o. It also builds fine on most > ports architectures. It has been finally built on mipsel and mips64el, successfully. Regards, Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
