Bug#1065110: ypbind-mt: FTBFS: missing build-dep on libnsl-dev
On Thu, Feb 29, 2024 at 10:03:53PM +0100, Aurelien Jarno wrote: This could be fixed by adding an explicit Build-Depends on libnsl-dev. The glibc change will likely be reverted in the short term, but given its a change we want to do for Trixie, this will only lower the severity of the bug. Regards Aurelien Thanks, this seems the less impacting solution. -- ⢀⣴⠾⠻⢶⣦⠀ Francesco Paolo Lovergine ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ 0579 A97A 2238 EBF9 BE61 ⠈⠳⣄ ED02 0F02 A5E1 1636 86A4
Bug#1061195: ITP: libgeo-wkt-simple-perl -- Simple utils to parse/build Well Known Text(WKT) format string
Package: wnpp Severity: wishlist Owner: "Francesco P. Lovergine" X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: libgeo-wkt-simple-perl Version : 0.05 Upstream Contact: Yuto KAWAMURA * URL : https://metacpan.org/release/KAWAMURAY/Geo-WKT-Simple-0.05 * License : Perl Programming Lang: Perl Description : Simple utils to parse/build Well Known Text(WKT) format string This module can parse/build WKT format string into/from pure Perl data structure. It is simpler than Geo::WKT and does not depend on the Proj library, and even support MULTI(LINE|STRING|POLYGON) objects. -- ⢀⣴⠾⠻⢶⣦⠀ Francesco Paolo Lovergine ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ 0579 A97A 2238 EBF9 BE61 ⠈⠳⣄ ED02 0F02 A5E1 1636 86A4
Bug#1060757: ITP: libdata-find-perl -- Find data in arbitrary data structures
Package: wnpp Severity: wishlist Owner: "Francesco P. Lovergine" X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: libdata-find-perl Version : 0.03 Upstream Contact: Andy Armstrong * URL : https://github.com/AndyA/Data--Find * License : Perl Programming Lang: Perl Description : Find data in arbitrary data structures A simple module to navigate a Perl data structure with three exported subroutines (diter, dfind and dwith) and find data occurrences. -- ⢀⣴⠾⠻⢶⣦⠀ Francesco Paolo Lovergine ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ 0579 A97A 2238 EBF9 BE61 ⠈⠳⣄ ED02 0F02 A5E1 1636 86A4
Bug#1056834: pyfuse3: ftbfs with cython 3.0.x
On Mon, Dec 11, 2023 at 12:30:24PM +0100, Sebastiaan Couwenberg wrote: On 12/11/23 12:04, Francesco P. Lovergine wrote: Unfortunately pyfuse3 is currently not more actively developedi (see it's github page), I wonder if it makes sense maintaining it in Debian, even considering the Python life cycle which far from being slow and could render the whole thing strongly obsolete even at mid-term. Removing the package because it's dead upstream makes sense. The rdeps will need to be updated before it can be removed: # Broken Depends: s3ql: s3ql # Broken Build-Depends: borgbackup: python3-pyfuse3 borgbackup2: python3-pyfuse3 s3ql: python3-pyfuse3 (3.2.0 >=) python3-pyfuse3 (4.0.0 <) For borg it's a pure recommends. About S3ql it strictly depends on pyfuse3 which is the async Trio based implementation of the fuse library. The current status of the whole fuse-in-Python is quite confused and I guess for such kind of things soon we will see a general shift to other more performant ecosystems, such as rust. At the time, I hoped that things would evolve for the best in the Python ecosystem, but I was too much optimistic... -- Francesco P. Lovergine
Bug#1056834: pyfuse3: ftbfs with cython 3.0.x
Hi folks, Unfortunately pyfuse3 is currently not more actively developedi (see it's github page), I wonder if it makes sense maintaining it in Debian, even considering the Python life cycle which far from being slow and could render the whole thing strongly obsolete even at mid-term. On Sun, Dec 10, 2023 at 10:04:19AM +0100, Sebastiaan Couwenberg wrote: Control: tags -1 patch On Sun, 26 Nov 2023 10:06:00 + Matthias Klose wrote: If the package cannot be built with cython 3.0.5, please change the build dependency from cython3 to cython3-legacy (available now in unstable). There is no replacement for cython3-dbg. The attached patch switches to cython3-legacy as the short term workaround. The package still fails to build due to #1042652. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 diff -Nru pyfuse3-3.2.1/debian/changelog pyfuse3-3.2.1/debian/changelog --- pyfuse3-3.2.1/debian/changelog 2022-10-17 04:54:25.0 +0200 +++ pyfuse3-3.2.1/debian/changelog 2023-12-10 09:59:51.0 +0100 @@ -1,3 +1,10 @@ +pyfuse3 (3.2.1-2.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Switch to cython3-legacy. + + -- Bas Couwenberg Sun, 10 Dec 2023 09:59:51 +0100 + pyfuse3 (3.2.1-2) unstable; urgency=medium [ Debian Janitor ] diff -Nru pyfuse3-3.2.1/debian/control pyfuse3-3.2.1/debian/control --- pyfuse3-3.2.1/debian/control2022-10-17 04:54:25.0 +0200 +++ pyfuse3-3.2.1/debian/control2023-12-10 09:59:50.0 +0100 @@ -4,7 +4,7 @@ Maintainer: Debian Python Team Uploaders: Nikolaus Rath , Francesco Paolo Lovergine -Build-Depends: cython3, +Build-Depends: cython3-legacy, debhelper-compat (= 13), dh-python, fuse3, -- Francesco P. Lovergine
Bug#1053604: ITP: libgeo-gdal-ffi-perl -- foreign function interface for GDAL/OGR binding
Package: wnpp Severity: wishlist Owner: "Francesco P. Lovergine" X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: libgeo-gdal-ffi-perl Version : 0.1 Upstream Contact: Ari Jolma * URL : https://metacpan.org/release/Geo-GDAL-FFI * License : Artistic-2.0 Programming Lang: Perl Description : foreign function interface for GDAL/OGR binding This is a foreign function interface (FFI) to the GDAL/OGR geospatial data access library. . The FFI interface is based on the C API for GDAL/OGR as defined in version 3.5+ and replaces the deprecated Geo::GDAL interface based on XS. -- Francesco P. Lovergine
Bug#1052224: ITP: libalien-base-modulebuild-perl -- subclass of Module::Build for building Alien:: modules and their libraries
On Wed, Sep 20, 2023 at 10:29:49AM +0200, Francesco P. Lovergine wrote: The resulting package needs to be arch:any to create a correct internal Geo::GDAL::gdal.pm module per arch, Err, not required if depending on libgdal-dev, indeed. -- Francesco P. Lovergine
Bug#1052224: ITP: libalien-base-modulebuild-perl -- subclass of Module::Build for building Alien:: modules and their libraries
On Tue, Sep 19, 2023 at 06:36:13PM +0200, Francesco P. Lovergine wrote: On Tue, Sep 19, 2023 at 06:13:09PM +0200, gregor herrmann wrote: I can't really test now, because Geo::GDAL::FFI also needs the unpackaged FFI::Platypus::Declare, but from reading https://metacpan.org/release/AJOLMA/Geo-GDAL-FFI-0.1/source/Makefile.PL and https://metacpan.org/release/AJOLMA/Geo-GDAL-FFI-0.1/source/README.md a simple override_dh_auto_configure: dh_auto_configure -- GDAL=/usr plus build dependencies on gdal-bin (for /usr/bin/gdalinfo) and libgdal-dev might be enough without any Alien::gdal. Maybe :) (Not sure about https://metacpan.org/release/AJOLMA/Geo-GDAL-FFI-0.1/source/lib/Geo/GDAL/FFI.pm#L1567 but this is also guarded by an if()) Mmmm, let me see. The chain I used was to impact minimally on changes for the module taken from CPAN. I would be happy to minimize the use of all that stuff, I was not exactly enthusiastic about the new course at the time. Ok, it seems that the solution is much more easy than the prospected. The implementation is smart enough to keep the gdal.so in the right place, something I oversight before. The resulting package needs to be arch:any to create a correct internal Geo::GDAL::gdal.pm module per arch, but it seems working. That said, I would try to patch to avoid the Platypus::Declare use which is currently discouraged/deprecated: I would avoid to read other complains by gregor :-D Thanks a lot for the hints. -- Francesco P. Lovergine
Bug#1052224: ITP: libalien-base-modulebuild-perl -- subclass of Module::Build for building Alien:: modules and their libraries
On Tue, Sep 19, 2023 at 06:13:09PM +0200, gregor herrmann wrote: On Tue, 19 Sep 2023 17:48:41 +0200, Francesco P. Lovergine wrote: > Sorry to be a pain again :) but: Do we really need this? Unfortunately yes for me, it is in the dep chain for Geo::GDAL::FFI, as for https://wiki.debian.org/BookwormGdalPerl which is my main goal to avoid to mantain an unofficial repo for the rest of time. You mean because of Alien::gdal? I can't really test now, because Geo::GDAL::FFI also needs the unpackaged FFI::Platypus::Declare, but from reading https://metacpan.org/release/AJOLMA/Geo-GDAL-FFI-0.1/source/Makefile.PL and https://metacpan.org/release/AJOLMA/Geo-GDAL-FFI-0.1/source/README.md a simple override_dh_auto_configure: dh_auto_configure -- GDAL=/usr plus build dependencies on gdal-bin (for /usr/bin/gdalinfo) and libgdal-dev might be enough without any Alien::gdal. Maybe :) (Not sure about https://metacpan.org/release/AJOLMA/Geo-GDAL-FFI-0.1/source/lib/Geo/GDAL/FFI.pm#L1567 but this is also guarded by an if()) Mmmm, let me see. The chain I used was to impact minimally on changes for the module taken from CPAN. I would be happy to minimize the use of all that stuff, I was not exactly enthusiastic about the new course at the time. -- Francesco P. Lovergine
Bug#1052224: ITP: libalien-base-modulebuild-perl -- subclass of Module::Build for building Alien:: modules and their libraries
On Tue, Sep 19, 2023 at 05:39:12PM +0200, gregor herrmann wrote: On Tue, 19 Sep 2023 11:37:29 +0200, Francesco P. Lovergine wrote: Package: wnpp Severity: wishlist Owner: Francesco Paolo Lovergine X-Debbugs-Cc: debian-de...@lists.debian.org, debian-p...@lists.debian.org * Package name: libalien-base-modulebuild-perl … . This module is in maintenance mode, use Alien::Build for new stuff. Sorry to be a pain again :) but: Do we really need this? Alien::Build is already questionable¹, although I admit that patching the requirement out can be a bit cumbersome -- but a subclass that says "This module is in maintenance mode, use Alien::Build for new stuff." looks a bit like a candidate for not-packaging to me … Unfortunately yes for me, it is in the dep chain for Geo::GDAL::FFI, as for https://wiki.debian.org/BookwormGdalPerl which is my main goal to avoid to mantain an unofficial repo for the rest of time. -- Francesco P. Lovergine
Bug#1052224: ITP: libalien-base-modulebuild-perl -- subclass of Module::Build for building Alien:: modules and their libraries
Package: wnpp Severity: wishlist Owner: Francesco Paolo Lovergine X-Debbugs-Cc: debian-de...@lists.debian.org, debian-p...@lists.debian.org * Package name: libalien-base-modulebuild-perl Version : 1.17 Upstream Contact: Joel A Berger * URL : https://metacpan.org/release/Alien-Base-ModuleBuild * License : Artistic or GPL-1+ Programming Lang: Perl Description : subclass of Module::Build for building Alien:: modules and their libraries This is a subclass of Module::Build, that with Alien::Base allows for easy creation of Alien distributions. Alien::Base::ModuleBuild is used during the build step of your distribution. When properly configured it will use pkg-config to find and use the system version of the library download, build and install the library if the system does not provide it. . This module is in maintenance mode, use Alien::Build for new stuff. -- Francesco P. Lovergine
Bug#1052161: ITP: libmozilla-ca-perl -- Mozilla's CA cert bundle in PEM format
On Mon, Sep 18, 2023 at 02:40:50PM +0200, Francesco P. Lovergine wrote: I see that you have already uploaded the package: https://alioth-lists.debian.net/pipermail/pkg-perl-maintainers/2023-September/171821.html May I suggest that you ask ftp-masters to REJECT it? Yep indeed. Maybe a wrapper could be tought for packages that have some optional dep on that? I would simply patch Mozilla::CA to have SSL_ca_file() returning the Debian directory /usr/share/ca-certificates/mozilla instead of the cacert.pem file. That would avoid to patch third-parties code that eventually use explicitly the modules. This is compatible with the IO::Socket::SSL module. Does it make sense? -- Francesco P. Lovergine
Bug#1052161: ITP: libmozilla-ca-perl -- Mozilla's CA cert bundle in PEM format
On Mon, Sep 18, 2023 at 02:33:18PM +0200, gregor herrmann wrote: On Mon, 18 Sep 2023 14:29:08 +0200, gregor herrmann wrote: > * Package name: libmozilla-ca-perl We don't package Mozilla::CA in Debian because we have ca-certificates with the same certs. I see that you have already uploaded the package: https://alioth-lists.debian.net/pipermail/pkg-perl-maintainers/2023-September/171821.html May I suggest that you ask ftp-masters to REJECT it? Yep indeed. Maybe a wrapper could be tought for packages that have some optional dep on that? -- Francesco P. Lovergine
Bug#981458: vtun systemd service
On Tue, Jul 04, 2023 at 11:24:21AM +0200, Andreas Henriksson wrote: Hello Francesco P. Lovergine, Thanks for your feedback on this! On Mon, Jul 03, 2023 at 06:17:20PM +0200, Francesco P. Lovergine wrote: Uhm, it seems to me quite irritual using a template unit file without a template variable. Which reflects the quite strange use of /etc/default/vtun with multiple indexed vars, instead of multiple configuration files such as: /etc/vtun.d/config?.vars (or even under /etc/vtun if you prefer so) and of course you can override the env variables by using an /etc/vtun.d/%i.vars where it makes sense in the template file. I think this would be the right moment to convert the insane limited number of env var sets in /etc/default/vtun into multiple ordinary configuration files and using something like that. EnvironmentFile=-/etc/vtun.d/%i.vars would override name, host and args variables. I'm missing something? While I atleast partially agree with your initial sentence, I'm not onboard with your suggested solution. In my understanding use of EnvironmentFile= is discuraged (and if I'm not mistaken I've even read statements saying it was a mistake to ever add it as an option). It seems to me like you're bending over backwards trying to invent something that actually needs the instance variable. (I'm however fine with anything that gets things moving forward of using native units instead of init script. I'm also not even a user of this package/program as previously stated, so it affects me very little. Use what ever solution you find acceptable!) Regards, Andreas Henriksson First of all, sorry for the use of irritual instead of weird (false friend term applies in this case, for non native speakers). About the discouraging of EnvironmentFile could you please point where it is expressed in the Policy? For sure, Debian has impressive use of the /etc/default/ tree which was and still is Debian specific. That is probably the origin of those rumors. Indeed, enabling/disabling of services by using an option in /etc/default/ (as for a lots of services in the past) is considered a bad practice due to the old init sysv days. Today, one should enable/disable the unit instead, which is much more clean. That make sense. I disagree with a general deprecation of Environment entries instead (files or vars), which is optimal mode of solving configuration issues without writing whole units or overrides. But on those regards, using a non-templated unit as a pseudo-templated is a very strange choice. Anyway it is your choice. -- Francesco P. Lovergine
Bug#981458: vtun systemd service
On Mon, Jul 03, 2023 at 04:03:47PM +0200, Andreas Henriksson wrote:
Control: forcemerge -1 1039413
Control: severity -1 important
Control: retitle -1 vtun: please provide vtun@.service and mask init script
Hello,
I'm attaching a patch for the vtun debian package that should hopefully
be a good start in migrating to native systemd units.
The patch is COMPLETELY UNTESTED as I'm not myself a user of vtun.
Please make sure to set FIRST_SYSTEMD_SERVICE_VERSION to the correct
debian package version including these changes.
The attached patch adds a vtun@.service as the init script seems to have
used a home-brew template units style.
The /etc/default/vtun CLIENT$i_* variables are broken up into separate
vtun@.service instances, eg CLIENT1_NAME, CLIENT1_HOST, CLIENT1_ARGS
goes to vtun@CLIENT1.service override as NAME, HOST and OPTIONS.
This is done as a one-time migration
(This also lifts the restrictions of having 0-9 instances.)
You most likely also want to make sure vtun.service (without the @)
is a symlink to /dev/null, to mask the init script.
See also:
https://src.fedoraproject.org/rpms/vtun/tree/81e15b3a03b89bffe0e6076a235720d40f343292
You might also want to provide the socket unit
Regards,
Andreas Henriksson
diff '--color=auto' -uriNp vtun-3.0.4/debian/postinst
vtun-3.0.4.systemd/debian/postinst
--- vtun-3.0.4/debian/postinst 2019-11-11 01:17:37.0 +0100
+++ vtun-3.0.4.systemd/debian/postinst 2023-07-03 15:47:08.717223223 +0200
@@ -46,6 +46,36 @@ case "$1" in
;;
esac
+# migrate old init.d style settings to systemd
+FIRST_SYSTEMD_SERVICE_VERSION="3.0.4-2.1"
+if [ "$1" = "configure" ] && dpkg --compare-versions "$2" lt-nl
"$FIRST_SYSTEMD_SERVICE_VERSION~" ; then
+(
+echo "Checking if we need to migrate /etc/default/vtun settings to
'vtun@.service'."
+if [ -e /etc/default/vtun ]; then
+. /etc/default/vtun
+fi
+
+for i in 0 1 2 3 4 5 6 7 8 9; do
+eval name=\$CLIENT${i}_NAME
+eval host=\$CLIENT${i}_HOST
+eval args=\$CLIENT${i}_ARGS
+if [ -n "$name" ] && [ -n "$host" ]; then
+echo "One-time migration of vtun CLIENT$i settings to
vtun@CLIENT$i.service"
+mkdir -p "/etc/systemd/system/vtun@CLIENT$i.service.d/"
+echo "[Service]" >>
"/etc/systemd/system/vtun@CLIENT$i.service.d/override.conf"
+echo "Environment=\"NAME=$name\"" >>
"/etc/systemd/system/vtun@CLIENT$i.service.d/override.conf"
+echo "Environment=\"HOST=$host\"" >>
"/etc/systemd/system/vtun@CLIENT$i.service.d/override.conf"
+echo "Environment=\"OPTIONS=$args\"" >>
"/etc/systemd/system/vtun@CLIENT$i.service.d/override.conf"
+if [ -n "${RUN_SERVER:-}" ] && [ "${RUN_SERVER:-}" != "no" ];
then
+deb-systemd-helper enable "vtun@CLIENT$i"
+fi
+fi
+
+done
+)
+fi
+
+
# dh_installdeb will replace this with shell code automatically
# generated by other debhelper scripts.
diff '--color=auto' -uriNp vtun-3.0.4/debian/vtun@.service
vtun-3.0.4.systemd/debian/vtun@.service
--- vtun-3.0.4/debian/vtun@.service 1970-01-01 01:00:00.0 +0100
+++ vtun-3.0.4.systemd/debian/vtun@.service 2023-07-03 15:23:25.513183684
+0200
@@ -0,0 +1,12 @@
+[Unit]
+Description=Virtual Tunnels over TCP/IP networks
+After=network.target
+
+[Service]
+ExecStart=/usr/sbin/vtund -n $OPTIONS $NAME $HOST
+# Reload should be synchronous, but signals are not...
+ExecReload=/usr/bin/kill -HUP $MAINPID
+Restart=on-failure
+
+[Install]
+WantedBy=multi-user.target
Uhm, it seems to me quite irritual using a template unit file without a
template variable. Which reflects
the quite strange use of /etc/default/vtun with multiple indexed vars,
instead of multiple configuration files such as:
/etc/vtun.d/config?.vars (or even under /etc/vtun if you prefer so)
and of course you can override the env variables by using an /etc/vtun.d/%i.vars
where it makes sense in the template file. I think this would be the right
moment to convert the
insane limited number of env var sets in /etc/default/vtun into multiple
ordinary configuration
files and using something like that.
EnvironmentFile=-/etc/vtun.d/%i.vars
would override name, host and args variables.
I'm missing something?
--
Francesco P. Lovergine
Bug#1038879: bookworm-pu: package proftpd-dfsg/1.3.8+dfsg-4+deb12u1
On Fri, Jun 30, 2023 at 12:54:23PM +0100, Jonathan Wiltshire wrote: Can I have a source-only upload please? I'll reject the upload for now, you can reuse the same version. Done. -- Francesco P. Lovergine
Bug#1038879: bookworm-pu: package proftpd-dfsg/1.3.8+dfsg-4+deb12u1
On Mon, Jun 26, 2023 at 07:28:36PM +0200, Francesco P. Lovergine wrote:
Updated debdiff attached.
Sorry wrong diff, this is the correct one :-/
--
Francesco P. Lovergine
diff -Nru proftpd-dfsg-1.3.8+dfsg/debian/changelog proftpd-dfsg-1.3.8+dfsg/debian/changelog
--- proftpd-dfsg-1.3.8+dfsg/debian/changelog 2023-03-14 10:16:31.0 +0100
+++ proftpd-dfsg-1.3.8+dfsg/debian/changelog 2023-06-22 11:15:57.0 +0200
@@ -1,3 +1,15 @@
+proftpd-dfsg (1.3.8+dfsg-4+deb12u1) bookworm; urgency=medium
+
+ * Now do not enable proftpd.socket to avoid conflicts at boot time.
+(Closes: #1038416)
+ * Introduced a new prerm script to manage stop of service/socket before
+remove.
+ * Added an entry to NEWS file to explain the change in unit files
+and how to deal with changes.
+ * Revised README.Debian to reflect changes in unit file management.
+
+ -- Francesco Paolo Lovergine Thu, 22 Jun 2023 11:15:57 +0200
+
proftpd-dfsg (1.3.8+dfsg-4) unstable; urgency=medium
* Correct Umask entry in commented section (Closes: #1006011).
diff -Nru proftpd-dfsg-1.3.8+dfsg/debian/proftpd-core.NEWS proftpd-dfsg-1.3.8+dfsg/debian/proftpd-core.NEWS
--- proftpd-dfsg-1.3.8+dfsg/debian/proftpd-core.NEWS 2023-03-13 12:24:28.0 +0100
+++ proftpd-dfsg-1.3.8+dfsg/debian/proftpd-core.NEWS 2023-06-22 11:15:57.0 +0200
@@ -1,3 +1,16 @@
+proftpd-dfsg (1.3.8+dfsg-4+deb12u1) bookworm; urgency=medium
+
+If you upgrade from 1.3.8+dfsg-4 (i.e. th 12.0 edition of bookworm) note
+that you will need to
+systemctl disable --now proftpd.socket
+systemctl enable --now proftpd.service
+after upgrade, if you run the proftpd in (default) standalone mode and you did not
+do that before. See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1038416
+for more information. For other information about inetd/standalone switching
+see also the relevant section in /usr/share/doc/proftpd-core/README.Debian.gz.
+
+ -- Francesco Paolo Lovergine Wed, 21 Jun 2023 15:21:32 +0200
+
proftpd-dfsg (1.3.7a+dfsg-6) unstable; urgency=medium
The default method of installation is the traditional standalone
diff -Nru proftpd-dfsg-1.3.8+dfsg/debian/proftpd-core.prerm proftpd-dfsg-1.3.8+dfsg/debian/proftpd-core.prerm
--- proftpd-dfsg-1.3.8+dfsg/debian/proftpd-core.prerm 1970-01-01 01:00:00.0 +0100
+++ proftpd-dfsg-1.3.8+dfsg/debian/proftpd-core.prerm 2023-06-22 11:15:57.0 +0200
@@ -0,0 +1,10 @@
+#!/bin/sh
+
+set -e
+
+if [ -z "${DPKG_ROOT:-}" ] && [ "$1" = remove ] && [ -d /run/systemd/system ] ;
+then
+deb-systemd-invoke stop 'proftpd.socket' 'proftpd.service' >/dev/null || true
+fi
+
+#DEBHELPER#
diff -Nru proftpd-dfsg-1.3.8+dfsg/debian/proftpd-core.README.Debian proftpd-dfsg-1.3.8+dfsg/debian/proftpd-core.README.Debian
--- proftpd-dfsg-1.3.8+dfsg/debian/proftpd-core.README.Debian 2023-03-13 12:24:28.0 +0100
+++ proftpd-dfsg-1.3.8+dfsg/debian/proftpd-core.README.Debian 2023-06-22 11:15:57.0 +0200
@@ -104,8 +104,7 @@
That could be done by running
- service proftpd stop
- systemctl disable proftpd.service
+ systemctl disable --now proftpd.service
then changing from 'standalone' to 'inetd' the ServerType entry in
/etc/proftpd/proftpd.conf, and:
@@ -131,10 +130,7 @@
- or using systemd support for socket. To do that run:
- systemctl stop proftpd.service
- systemctl disable proftpd.service
- systemctl enable proftpd.socket
- systemctl start proftpd.socket
+ systemctl enable --now proftpd.socket
** Other information
diff -Nru proftpd-dfsg-1.3.8+dfsg/debian/rules proftpd-dfsg-1.3.8+dfsg/debian/rules
--- proftpd-dfsg-1.3.8+dfsg/debian/rules 2023-03-13 12:24:28.0 +0100
+++ proftpd-dfsg-1.3.8+dfsg/debian/rules 2023-06-22 11:15:57.0 +0200
@@ -93,7 +93,7 @@
dh_installinit --name=$(NAME)
override_dh_installsystemd:
- dh_installsystemd -p$(PACKAGE) --name=$(NAME) $(NAME).socket
+ dh_installsystemd -p$(PACKAGE) --no-enable --no-start --name=$(NAME) $(NAME).socket
dh_installsystemd -p$(PACKAGE) --name=$(NAME)@ $(NAME)@.service
dh_installsystemd -p$(PACKAGE) --name=$(NAME) $(NAME).service
Bug#1038879: bookworm-pu: package proftpd-dfsg/1.3.8+dfsg-4+deb12u1
On Mon, Jun 26, 2023 at 10:50:05AM +0200, Francesco P. Lovergine wrote:
Ok, I did my homework again and found that the best thing to do seems removing
the
proftpd-run.service and enabling the proftpd.service only at
installation time. That would allow proftpd working flawlessly at
least for new installation on bookworm and even upgrades from bullseye
to p-u.
Unfortunately, an upgrade from -4 would not fix the situation, which
should be fixed by the admin in any case, by simply disabling
proftpd.socket by hand. But for annotating this thing in NEWS, I can't
see any other details to have care.
If you (RMs) like this plan, I would submit one more debdiff with the proposed
changes
and wait for a final approvement, if possible.
Updated debdiff attached.
--
Francesco P. Lovergine
diff -Nru proftpd-dfsg-1.3.8+dfsg/debian/changelog proftpd-dfsg-1.3.8+dfsg/debian/changelog
--- proftpd-dfsg-1.3.8+dfsg/debian/changelog 2023-03-14 10:16:31.0 +0100
+++ proftpd-dfsg-1.3.8+dfsg/debian/changelog 2023-06-22 11:15:57.0 +0200
@@ -1,3 +1,15 @@
+proftpd-dfsg (1.3.8+dfsg-4+deb12u1) bookworm; urgency=medium
+
+ * Now do not enable proftpd.socket to avoid conflicts at boot time.
+(Closes: #1038416)
+ * Introduced a new prerm script to manage stop of service/socket before
+remove.
+ * Added an entry to NEWS file to explain the change in unit files
+and how to deal with changes.
+ * Revised README.Debian to reflect changes in unit file management.
+
+ -- Francesco Paolo Lovergine Thu, 22 Jun 2023 11:15:57 +0200
+
proftpd-dfsg (1.3.8+dfsg-4) unstable; urgency=medium
* Correct Umask entry in commented section (Closes: #1006011).
diff -Nru proftpd-dfsg-1.3.8+dfsg/debian/proftpd-core.NEWS proftpd-dfsg-1.3.8+dfsg/debian/proftpd-core.NEWS
--- proftpd-dfsg-1.3.8+dfsg/debian/proftpd-core.NEWS 2023-03-13 12:24:28.0 +0100
+++ proftpd-dfsg-1.3.8+dfsg/debian/proftpd-core.NEWS 2023-06-22 11:15:57.0 +0200
@@ -1,3 +1,16 @@
+proftpd-dfsg (1.3.8+dfsg-4+deb12u1) bookworm; urgency=medium
+
+If you upgrade from 1.3.8+dfsg-4 (i.e. th 12.0 edition of bookworm) note
+that you will need to
+systemctl disable --now proftpd.socket
+systemctl enable --now proftpd.service
+after upgrade, if you run the proftpd in (default) standalone mode and you did not
+do that before. See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1038416
+for more information. For other information about inetd/standalone switching
+see also the relevant section in /usr/share/doc/proftpd-core/README.Debian.gz.
+
+ -- Francesco Paolo Lovergine Wed, 21 Jun 2023 15:21:32 +0200
+
proftpd-dfsg (1.3.7a+dfsg-6) unstable; urgency=medium
The default method of installation is the traditional standalone
diff -Nru proftpd-dfsg-1.3.8+dfsg/debian/proftpd-core.prerm proftpd-dfsg-1.3.8+dfsg/debian/proftpd-core.prerm
--- proftpd-dfsg-1.3.8+dfsg/debian/proftpd-core.prerm 1970-01-01 01:00:00.0 +0100
+++ proftpd-dfsg-1.3.8+dfsg/debian/proftpd-core.prerm 2023-06-22 11:15:57.0 +0200
@@ -0,0 +1,10 @@
+#!/bin/sh
+
+set -e
+
+if [ -z "${DPKG_ROOT:-}" ] && [ "$1" = remove ] && [ -d /run/systemd/system ] ;
+then
+deb-systemd-invoke stop 'proftpd.socket' 'proftpd.service' >/dev/null || true
+fi
+
+#DEBHELPER#
diff -Nru proftpd-dfsg-1.3.8+dfsg/debian/proftpd-core.README.Debian proftpd-dfsg-1.3.8+dfsg/debian/proftpd-core.README.Debian
--- proftpd-dfsg-1.3.8+dfsg/debian/proftpd-core.README.Debian 2023-03-13 12:24:28.0 +0100
+++ proftpd-dfsg-1.3.8+dfsg/debian/proftpd-core.README.Debian 2023-06-22 11:15:57.0 +0200
@@ -104,8 +104,8 @@
That could be done by running
- service proftpd stop
- systemctl disable proftpd.service
+ systemctl stop proftpd.service
+ systemctl disable proftpd-run.service (only for xinetd/inetd use)
then changing from 'standalone' to 'inetd' the ServerType entry in
/etc/proftpd/proftpd.conf, and:
@@ -132,10 +132,10 @@
- or using systemd support for socket. To do that run:
systemctl stop proftpd.service
- systemctl disable proftpd.service
- systemctl enable proftpd.socket
systemctl start proftpd.socket
+The proftpd-run.service will take care of the mode switching at boot time.
+
** Other information
Please, read accurately the NEWS, README and changelog file in /usr/share/doc/proftpd-basic
diff -Nru proftpd-dfsg-1.3.8+dfsg/debian/rules proftpd-dfsg-1.3.8+dfsg/debian/rules
--- proftpd-dfsg-1.3.8+dfsg/debian/rules 2023-03-13 12:24:28.0 +0100
+++ proftpd-dfsg-1.3.8+dfsg/debian/rules 2023-06-22 11:15:57.0 +0200
@@ -93,7 +93,7 @@
dh_installinit --name=$(NAME)
override_dh_installsystemd:
- dh_installsystemd -p$(PACKAGE) --name=$(NAME) $(NAME).socket
+ dh_installsystemd -p$(PACKAGE) --no-enable --no-start --name=$(NAME) $(NAME).socket
dh_installsystemd -p$(PACKAGE) --name=$(NAME)@ $(NAME)@.service
dh_installsystemd -p$(PACKAGE) --name=$(NAME) $(NAME).service
Bug#1038879: bookworm-pu: package proftpd-dfsg/1.3.8+dfsg-4+deb12u1
On Sun, Jun 25, 2023 at 05:27:04PM +0100, Jonathan Wiltshire wrote: > Maybe I missed something important, but this seems a very odd way of doing > things. Do you really set up a dummy service unit which is expected to fail > in standalone mode, and therefore starts the socket instead? > > Why not use an ExecStartPre= or ExecCondition= in your normal units to > prevent starting when in inetd mode? > Unfortunately, Exec* directives can only be used in .service units. This statement is at odds with the documentation for systemd.socket(5). I meant ExecCondition (see https://github.com/systemd/systemd/issues/14012), but indeed there is not way to by-pass the socket opening within a socket unit. Once enabled, the ftp socket is under systemd control, the only way to prevent that is by using ConditionPathExists AFAIK. That's the reason to enable an external oneshot .service unit to start alternatively one of the two other units. Ideally one day or another such features could be available also in other type of units (there is an issue open since 2019). Incidentally, it is possible to add a ConditionPathExists and a something like /etc/proftpd/proftpd_not_to_be_run (which is the trick used in sshd) but would be completely Debian specific and out of the usual workflow to manage inetd/standalone modes in proftpd. So, I'm not that keen on this kind of trick. I don't think a ConditionPathExists hack is necessary here. Yes, in the standalone case you will end up with the socket unit failing, and the local admin will have to disable that if it annoys them, but any competent administrator should be able to figure that out with the help of NEWS.Debian. Ok, I did my homework again and found that the best thing to do seems removing the proftpd-run.service and enabling the proftpd.service only at installation time. That would allow proftpd working flawlessly at least for new installation on bookworm and even upgrades from bullseye to p-u. Unfortunately, an upgrade from -4 would not fix the situation, which should be fixed by the admin in any case, by simply disabling proftpd.socket by hand. But for annotating this thing in NEWS, I can't see any other details to have care. If you (RMs) like this plan, I would submit one more debdiff with the proposed changes and wait for a final approvement, if possible. -- Francesco P. Lovergine
Bug#1039093: ITP: libalien-build-perl -- module to build external dependencies for use in CPAN
Package: wnpp Owner: Francesco Paolo Lovergine Severity: wishlist X-Debbugs-CC: debian-de...@lists.debian.org, debian-p...@lists.debian.org * Package name: libalien-build-perl Version : 2.80 Upstream Author : Graham Ollis * URL : https://metacpan.org/release/Alien-Build * License : Artistic or GPL-1+ Programming Lang: Perl Description : module to build external dependencies for use in CPAN Alien::Build provides tools for building external (non-CPAN) dependencies for CPAN. It is mainly designed to be used at install time of a CPAN client, and work closely with Alien::Base which is used at runtime. The package will be maintained under the umbrella of the Debian Perl Group. -- Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.
Bug#1038879: bookworm-pu: package proftpd-dfsg/1.3.8+dfsg-4+deb12u1
On Sun, Jun 25, 2023 at 11:06:17AM +0200, Francesco P. Lovergine wrote: Why not use an ExecStartPre= or ExecCondition= in your normal units to prevent starting when in inetd mode? Unfortunately, Exec* directives can only be used in .service units. That's the reason to enable an external oneshot .service unit to start alternatively one of the two other units. Ideally one day or another such features could be available also in other type of units (there is an issue open since 2019). Incidentally, it is possible to add a ConditionPathExists and a something like /etc/proftpd/proftpd_not_to_be_run (which is the trick used in sshd) but would be completely Debian specific and out of the usual workflow to manage inetd/standalone modes in proftpd. So, I'm not that keen on this kind of trick. Even, the ConditionPathExists would also imply adding code to manage in postinst that kind of stuff, in order to update admin's configuration in a proper way to respect the rule of least surprise at upgrade time ... -- Francesco P. Lovergine
Bug#1038879: bookworm-pu: package proftpd-dfsg/1.3.8+dfsg-4+deb12u1
First of all, thanks for the review.
Answers are embedded below.
On Sat, Jun 24, 2023 at 05:45:33PM +0100, Jonathan Wiltshire wrote:
Control: tag -1 moreinfo
On Thu, Jun 22, 2023 at 02:29:54PM +0200, Francesco P. Lovergine wrote:
diff -Nru proftpd-dfsg-1.3.8+dfsg/debian/changelog
proftpd-dfsg-1.3.8+dfsg/debian/changelog
--- proftpd-dfsg-1.3.8+dfsg/debian/changelog2023-03-14 10:16:31.0
+0100
+++ proftpd-dfsg-1.3.8+dfsg/debian/changelog2023-06-22 11:15:57.0
+0200
@@ -1,3 +1,15 @@
+proftpd-dfsg (1.3.8+dfsg-4+deb12u1) bookworm-proposed-updates; urgency=medium
You should target `bookworm`, not the admin suites.
Right, to be done.
diff -Nru proftpd-dfsg-1.3.8+dfsg/debian/proftpd-core.prerm
proftpd-dfsg-1.3.8+dfsg/debian/proftpd-core.prerm
--- proftpd-dfsg-1.3.8+dfsg/debian/proftpd-core.prerm 1970-01-01
01:00:00.0 +0100
+++ proftpd-dfsg-1.3.8+dfsg/debian/proftpd-core.prerm 2023-06-22
11:13:30.0 +0200
@@ -0,0 +1,11 @@
+#!/bin/sh
+
+set -e
+
+if [ -z "${DPKG_ROOT:-}" ] && [ "$1" = remove ] && [ -d /run/systemd/system ] ;
+then
+deb-systemd-invoke stop 'proftpd.service' >/dev/null || true
+deb-systemd-invoke stop 'proftpd.socket' >/dev/null || true
+fi
This gives rise to a race condition where the socket starts the service
again before the socket is stopped.
Well, this is exactly what debhelper does in current prerm in bookworm.
Eventually, it could be unified in `deb-systemd-invoke stop 'proftpd.socket' 'proftpd.service' || true`
like other packages do.
I'm not sure if this is what you intend, but if that risks a race condition it
would applies to
a lots of other packages.
diff -Nru proftpd-dfsg-1.3.8+dfsg/debian/proftpd-core.proftpd-run.service
proftpd-dfsg-1.3.8+dfsg/debian/proftpd-core.proftpd-run.service
--- proftpd-dfsg-1.3.8+dfsg/debian/proftpd-core.proftpd-run.service
1970-01-01 01:00:00.0 +0100
+++ proftpd-dfsg-1.3.8+dfsg/debian/proftpd-core.proftpd-run.service
2023-06-22 11:12:42.0 +0200
@@ -0,0 +1,14 @@
+[Unit]
+Description=ProFTPD FTP Server in standalone/socket mode
+Documentation=man:proftpd(8)
+OnFailure=proftpd.socket
+OnSuccess=proftpd.service
+
+[Service]
+Type=oneshot
+Environment=CONFIG_FILE=/etc/proftpd/proftpd.conf
+EnvironmentFile=-/etc/default/proftpd
+ExecStart=/usr/bin/grep -iqE '^[[:space:]]*ServerType[[:space:]]+standalone$'
$CONFIG_FILE
Maybe I missed something important, but this seems a very odd way of doing
things. Do you really set up a dummy service unit which is expected to fail
in standalone mode, and therefore starts the socket instead?
Why not use an ExecStartPre= or ExecCondition= in your normal units to
prevent starting when in inetd mode?
Unfortunately, Exec* directives can only be used in .service units. That's
the reason to enable an external oneshot .service unit to start alternatively
one of the two other units. Ideally one day or another such features could
be available also in other type of units (there is an issue open since 2019).
Incidentally, it is possible to add a ConditionPathExists and a something
like /etc/proftpd/proftpd_not_to_be_run (which is the trick used in sshd)
but would be completely Debian specific and out of the usual workflow
to manage inetd/standalone modes in proftpd. So, I'm not that keen on
this kind of trick.
--
Francesco P. Lovergine
Bug#1038879: bookworm-pu: package proftpd-dfsg/1.3.8+dfsg-4+deb12u1
Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: proftpd-d...@packages.debian.org,
pkg-proftpd-maintain...@alioth-lists.debian.net
Control: affects -1 + src:proftpd-dfsg
Hi
this is a pre-check before uploading in bookworm p-u a fixed package.
The proposed solution is described in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1038416#25
and implies adding and enable one more unit to pre-check the socket vs service
units,
and install/upgrade the other units in disabled mode. That even requires
stopping the service at prerm stage.
[ Reason ]
Murphy law applies and we (ProFTPD team) found a serious flaw in bookworm
proftpd - as summarized in the report #1038416 - which prevents having a
working service after a new install or even an upgrade in bookworm.
[ Impact ]
The default proftpd configuration requires a standalone daemon running,
but the installation of a .socket unit prevents it to run and is not
working even, because the distributed proftpd.conf (and generally the
system admin's one) renders unusable the program via systemd. This is
evident after rebooting, while the daemon is regularly
working just after installation.
At the end of the day the admin get a not working service and
needs to manually disable the .socket and enable the .service, or
change ServerType to inetd. This is unexpected and suboptimal.
[ Tests ]
The proposed solution works on a fresh install or an upgrade.
[ Risks ]
The change is quite trivial and should not impact other parts of the system.
[ 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 ]
Adding a new service unit which runs on-exit/on-success alternatively
the original .socket/.service unit on the basis of the current
proftpd configuration after install. The prerm script now stop services
just before removing package units.
Changes include documentation of the new units management in NEWS
and README.Debian.
[Other info]
--
Francesco P. Lovergine
diff -Nru proftpd-dfsg-1.3.8+dfsg/debian/changelog proftpd-dfsg-1.3.8+dfsg/debian/changelog
--- proftpd-dfsg-1.3.8+dfsg/debian/changelog 2023-03-14 10:16:31.0 +0100
+++ proftpd-dfsg-1.3.8+dfsg/debian/changelog 2023-06-22 11:15:57.0 +0200
@@ -1,3 +1,15 @@
+proftpd-dfsg (1.3.8+dfsg-4+deb12u1) bookworm-proposed-updates; urgency=medium
+
+ * Introduced a new systemd service to start the main socket/service
+on the basis of the proftpd.conf configuration (standalone/inetd).
+(Closes: #1038416)
+ * Introduced a new prerm script to manage stop of service/socket now
+not more managed by DH scripts.
+ * Added an entry to NEWS file to explain the change in unit files.
+ * Revised README.Debian to reflect changes in unit file management.
+
+ -- Francesco Paolo Lovergine Thu, 22 Jun 2023 11:15:57 +0200
+
proftpd-dfsg (1.3.8+dfsg-4) unstable; urgency=medium
* Correct Umask entry in commented section (Closes: #1006011).
diff -Nru proftpd-dfsg-1.3.8+dfsg/debian/proftpd-core.NEWS proftpd-dfsg-1.3.8+dfsg/debian/proftpd-core.NEWS
--- proftpd-dfsg-1.3.8+dfsg/debian/proftpd-core.NEWS 2023-03-13 12:24:28.0 +0100
+++ proftpd-dfsg-1.3.8+dfsg/debian/proftpd-core.NEWS 2023-06-22 11:15:57.0 +0200
@@ -1,3 +1,15 @@
+proftpd-dfsg (1.3.8+dfsg-4+deb12u1) bookworm-proposed-updates; urgency=medium
+
+Starting from this version a new systemd unit file 'proftpd-run.service' has
+been introduced to allow switching between standalone and systemd (socket) mode.
+In order to switch mode, it is possible to change ServerType from standalone to inetd
+in /etc/proftpd/proftpd.conf and run systemctl stop proftpd.service
+systemctl start proftpd.socket
+The only unit to be maintained enabled is proftpd-run.service, and disabling
+it would ensures to stop the ftp service at boot time.
+
+ -- Francesco Paolo Lovergine Wed, 21 Jun 2023 15:21:32 +0200
+
proftpd-dfsg (1.3.7a+dfsg-6) unstable; urgency=medium
The default method of installation is the traditional standalone
diff -Nru proftpd-dfsg-1.3.8+dfsg/debian/proftpd-core.prerm proftpd-dfsg-1.3.8+dfsg/debian/proftpd-core.prerm
--- proftpd-dfsg-1.3.8+dfsg/debian/proftpd-core.prerm 1970-01-01 01:00:00.0 +0100
+++ proftpd-dfsg-1.3.8+dfsg/debian/proftpd-core.prerm 2023-06-22 11:13:30.0 +0200
@@ -0,0 +1,11 @@
+#!/bin/sh
+
+set -e
+
+if [ -z "${DPKG_ROOT:-}" ] && [ "$1" = remove ] && [ -d /run/systemd/system ] ;
+then
+deb-systemd-invoke stop 'proftpd.service' >/dev/null || true
+deb-systemd-invoke stop 'proftpd.socket' >/dev/null || true
+fi
+
+#DEBHELPER#
diff -Nru proftpd-dfsg-1.3.8+dfsg/debian/proftpd-core.proftpd-run.service proftpd-dfsg-1.3.8+dfsg/debian/proftpd-core.proftpd-run.
Bug#1038416: possible fix
severity 1038416 serious tags 1038416 + patch bookworm thanks Hi all, Here we go, there is a better solution. It is possible to install and enable a third unit file such as: +++ /etc/systemd/system/proftpd-run.service: [Unit] Description=ProFTPD FTP Server in standalone/socket mode OnFailure=proftpd.socket OnSuccess=proftpd.service [Service] Type=oneshot Environment=CONFIG_FILE=/etc/proftpd/proftpd.conf EnvironmentFile=-/etc/default/proftpd ExecStart=/usr/bin/grep -iqE '^[[:space:]]*ServerType[[:space:]]+standalone$' $CONFIG_FILE RemainAfterExit=yes [Install] WantedBy=multi-user.target Here one can enable only this service and install only the other ones. systemctl disable proftpd.service systemctl disable proftpd.socket systemctl enable --now proftpd-run.service do the task. I would add this solution to git and prepare an ad hoc p-u for bookworm, but I'd prefer having a go from the release team, before that. - cheers On Tue, Jun 20, 2023 at 08:42:57PM +0200, Francesco P. Lovergine wrote: For reference, all this is a side effect of the proposed fix for #991266, strangely not caught at the time. On Tue, Jun 20, 2023 at 08:00:19PM +0200, Francesco P. Lovergine wrote: Bruno, that's right Unfortunately yes: originally the socket unit file was concepted as an example file to keep into the documentation and the Conflicts there does not ensure that the .socket unit is ignored when the .service is enabled. The simplest workaroud is systemctl disable --now proftpd.socket systemctl enable --now proftpd.service but the initial installation is definitively broken, because proftpd starts as a systemd socket, which is not intended by the distributed proftpd.conf. Hilmar, the simplest thing to do is probably addig a mask/disable of proftpd.socket at postinst time, and an enable --now for the proftpd.service, when server should be run in standalone mode (check via grepping proftpd.conf), after installing systemd stuff in --no-enable --no-start mode. This is of course not completely fair because ignores xinetd/inetd setup. -- Francesco P. Lovergine ___ Pkg-proftpd-maintainers mailing list pkg-proftpd-maintain...@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-proftpd-maintainers -- Francesco P. Lovergine
Bug#1038416: (no subject)
For reference, all this is a side effect of the proposed fix for #991266, strangely not caught at the time. On Tue, Jun 20, 2023 at 08:00:19PM +0200, Francesco P. Lovergine wrote: Bruno, that's right Unfortunately yes: originally the socket unit file was concepted as an example file to keep into the documentation and the Conflicts there does not ensure that the .socket unit is ignored when the .service is enabled. The simplest workaroud is systemctl disable --now proftpd.socket systemctl enable --now proftpd.service but the initial installation is definitively broken, because proftpd starts as a systemd socket, which is not intended by the distributed proftpd.conf. Hilmar, the simplest thing to do is probably addig a mask/disable of proftpd.socket at postinst time, and an enable --now for the proftpd.service, when server should be run in standalone mode (check via grepping proftpd.conf), after installing systemd stuff in --no-enable --no-start mode. This is of course not completely fair because ignores xinetd/inetd setup. -- Francesco P. Lovergine
Bug#1038416: (no subject)
Bruno, that's right Unfortunately yes: originally the socket unit file was concepted as an example file to keep into the documentation and the Conflicts there does not ensure that the .socket unit is ignored when the .service is enabled. The simplest workaroud is systemctl disable --now proftpd.socket systemctl enable --now proftpd.service but the initial installation is definitively broken, because proftpd starts as a systemd socket, which is not intended by the distributed proftpd.conf. Hilmar, the simplest thing to do is probably addig a mask/disable of proftpd.socket at postinst time, and an enable --now for the proftpd.service, when server should be run in standalone mode (check via grepping proftpd.conf), after installing systemd stuff in --no-enable --no-start mode. This is of course not completely fair because ignores xinetd/inetd setup. On Tue, Jun 20, 2023 at 04:21:41PM +0200, Bruno wrote: I guess that the systemd unit protfpd.socket should be disabled $ systemctl is-enabled proftpd.sockets disabled May be the Debian package postinst script wrongly enabled it ___ Pkg-proftpd-maintainers mailing list pkg-proftpd-maintain...@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-proftpd-maintainers -- Francesco P. Lovergine
Bug#1035967: ypserv: yphelper, yppush fail to run with segmentation fault
On Fri, May 12, 2023 at 01:01:24PM +0100, Robert Pumphrey wrote: Thank you for the fast response. On the NIS master, I have moved the domain directory /var/yp/domain to a backup. I then ran /usr/lib/yp/ypinit -m and added the IP addresses of the NIS slaves. This ran successfully. /usr/lib/yp/yphelper --hostname runs successfully on the master. /usr/lib/yp/yphelper --maps nameofnismaster runs successfully on the master and gives a list of maps. This is quite strange, because in moving from bullseye to bookworm no chages in the binary gdbm files have been required in my test. Test done after generating maps in bullseye. Are your current maps older than that? Even, I'm assuming you are on a amd64 arch. I have noticed that if the /etc/hosts file does not have an entry for local machine, then /usr/lib/yp/yphelper --hostname seg faults. This is expressly mandatory in NIS configuration, as by documentation. Every hostname used must be resolved at /etc/hosts level. Anyway that should not cause a segfault but an error, indeed. That seems an upstream issue (or several for each tool). All the other trials could be a direct consequence of that. The NIS master now looks to be operating correctly. On one of the NIS slaves, I moved the domain directory /var/yp/domain to a backup. I then ran /usr/lib/yp/ypinit -s nameofnismaster and I get a segmentation fault, followed by Can't enumerate maps from name>. Please check that it is running. /usr/lib/yp/yphelVper --hostname runs successfully on the slave /usr/lib/yp/yphelper --maps nameofnismaster seg faults So I have made some progress. Please let me know if there is anything else I can tell you. Regards Rob On 12/05/2023 10:09, Francesco P. Lovergine wrote: tags 1035967 + moreinfo unreproducible thanks Hi Rob, I just verified with a fresh installation of bookworm and it perfectly works. My first hypothesis could be about a gdbm-related breakage. It is somethig already seen in the past and even annotatedi at sect.9 of the Debian HOWTO. NEVER CROSS THE STREAMS (cit.). GDBM is quite weak in managing changes in file formats due to external conditions (e.g. changes in compiler/optimizations/ecc.) Could you plese run yptest on your serveri and send anomalies in result? Is this a single NIS master or do you have slaves ? Could you please regenerate gdbm stuff by ypinit -m after cleaning up maps? Anywyay, my next step will be preparing an upgrading box to test bullseye->bookworm, stay tuned. On Thu, May 11, 2023 at 07:55:26PM +, Rob Pumphrey wrote: Package: ypserv Version: 4.1-2 Severity: important Dear Maintainer, Recently upgraded our NIS master from buster to bullseye. when I run cd /var/yp; make several apps fail to run and seg fault, for example /usr/lib/yp/yphelper --hostname Segmentation fault yppush -d example.com ypservers Segmentation fault makedbm does appear to make valid files when run from the cmd line -- System Information: Debian Release: 11.7 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-22-amd64 (SMP w/4 CPU threads) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages ypserv depends on: ii hostname 3.23 ii libc6 2.31-13+deb11u6 ii libcrypt1 1:4.4.18-4 ii libgdbm6 1.19-2 ii libnsl2 1.3.0-2 ii libsystemd0 247.3-7+deb11u2 ii libtirpc3 1.3.1-1+deb11u1 ii lsb-base 11.1.0 ii make 4.3-4.1 ii rpcbind [portmap] 1.2.5-9 ii ucf 3.0043 Versions of packages ypserv recommends: ii yp-tools 4.2.3-3 Versions of packages ypserv suggests: pn krb5-kdc ii ypbind-mt 2.7.2-2 -- no debconf information -- Certus Technology Associates Limited. http://www.certus-tech.com Tel: +44 (0)114 272 5081 -- Francesco P. Lovergine
Bug#1035967: ypserv: yphelper, yppush fail to run with segmentation fault
severity 1035967 normal thanks On Fri, May 12, 2023 at 11:09:50AM +0200, Francesco P. Lovergine wrote: tags 1035967 + moreinfo unreproducible thanks Hi Rob, I just verified with a fresh installation of bookworm and it perfectly works. My first hypothesis could be about a gdbm-related breakage. It is somethig already seen in the past and even annotatedi at sect.9 of the Debian HOWTO. NEVER CROSS THE STREAMS (cit.). GDBM is quite weak in managing changes in file formats due to external conditions (e.g. changes in compiler/optimizations/ecc.) Could you plese run yptest on your serveri and send anomalies in result? Is this a single NIS master or do you have slaves ? Could you please regenerate gdbm stuff by ypinit -m after cleaning up maps? Anywyay, my next step will be preparing an upgrading box to test bullseye->bookworm, stay tuned. ... and as promised, I just tested an upgrade of a NIS server successfully. Services are all operational and the pointed binaries do not issue a segfault. In order to undestand your problem, I need to have details about your configuration, and eventually also pinned packages, additional repos etc. Feel free to send that stuff off-bugs.d.o to protect your site information, eventually. Thanks. On Thu, May 11, 2023 at 07:55:26PM +, Rob Pumphrey wrote: Package: ypserv Version: 4.1-2 Severity: important Dear Maintainer, Recently upgraded our NIS master from buster to bullseye. when I run cd /var/yp; make several apps fail to run and seg fault, for example /usr/lib/yp/yphelper --hostname Segmentation fault yppush -d example.com ypservers Segmentation fault makedbm does appear to make valid files when run from the cmd line -- System Information: Debian Release: 11.7 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-22-amd64 (SMP w/4 CPU threads) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages ypserv depends on: ii hostname 3.23 ii libc6 2.31-13+deb11u6 ii libcrypt1 1:4.4.18-4 ii libgdbm6 1.19-2 ii libnsl21.3.0-2 ii libsystemd0247.3-7+deb11u2 ii libtirpc3 1.3.1-1+deb11u1 ii lsb-base 11.1.0 ii make 4.3-4.1 ii rpcbind [portmap] 1.2.5-9 ii ucf3.0043 Versions of packages ypserv recommends: ii yp-tools 4.2.3-3 Versions of packages ypserv suggests: pn krb5-kdc ii ypbind-mt 2.7.2-2 -- no debconf information -- Francesco P. Lovergine -- Francesco P. Lovergine
Bug#1035967: ypserv: yphelper, yppush fail to run with segmentation fault
tags 1035967 + moreinfo unreproducible thanks Hi Rob, I just verified with a fresh installation of bookworm and it perfectly works. My first hypothesis could be about a gdbm-related breakage. It is somethig already seen in the past and even annotatedi at sect.9 of the Debian HOWTO. NEVER CROSS THE STREAMS (cit.). GDBM is quite weak in managing changes in file formats due to external conditions (e.g. changes in compiler/optimizations/ecc.) Could you plese run yptest on your serveri and send anomalies in result? Is this a single NIS master or do you have slaves ? Could you please regenerate gdbm stuff by ypinit -m after cleaning up maps? Anywyay, my next step will be preparing an upgrading box to test bullseye->bookworm, stay tuned. On Thu, May 11, 2023 at 07:55:26PM +, Rob Pumphrey wrote: Package: ypserv Version: 4.1-2 Severity: important Dear Maintainer, Recently upgraded our NIS master from buster to bullseye. when I run cd /var/yp; make several apps fail to run and seg fault, for example /usr/lib/yp/yphelper --hostname Segmentation fault yppush -d example.com ypservers Segmentation fault makedbm does appear to make valid files when run from the cmd line -- System Information: Debian Release: 11.7 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-22-amd64 (SMP w/4 CPU threads) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages ypserv depends on: ii hostname 3.23 ii libc6 2.31-13+deb11u6 ii libcrypt1 1:4.4.18-4 ii libgdbm6 1.19-2 ii libnsl21.3.0-2 ii libsystemd0247.3-7+deb11u2 ii libtirpc3 1.3.1-1+deb11u1 ii lsb-base 11.1.0 ii make 4.3-4.1 ii rpcbind [portmap] 1.2.5-9 ii ucf3.0043 Versions of packages ypserv recommends: ii yp-tools 4.2.3-3 Versions of packages ypserv suggests: pn krb5-kdc ii ypbind-mt 2.7.2-2 -- no debconf information -- Francesco P. Lovergine
Bug#1035336: release-notes: libgdal-perl dropped in Bookworm
Package: release-notes Severity: normal The ubiquitous geospatial GDAL library dropped the XS-based Perl binding, almost one year ago. As a consequence the Perl binding is not more directly supported at upstream level and developers/users that need a Perl support for GDAL must migrate to the FFI interface provided by Geo::GDAL::FFI package, available on CPAN. As a direct consequence, Bookworm is missing a Perl binding for GDAL (libgdal-perl in Bullseye and previous Debian releases). A wiki page is available at https://wiki.debian.org/BookwormGdalPerl to help users to start migration to the new interface.
Bug#1031261: Please, provide a valid initial configuration in /etc/multipath.conf
On Tue, Feb 14, 2023 at 11:28:50AM +0100, Chris Hofstaedtler wrote: Hi, multipath-tools upstream has in the past changed the defaults a number of times, and I think has now settled on "the best thing to do is manually configure it, because otherwise lots of edge cases pop up". * Francesco P. Lovergine [230214 09:18]: I finally figured out that multipath -t >/etc/multipath.conf generates an initial configuration which is usable, but for a find_multipaths "strict" which is the least friendly way of defining mappings and practically prevents any auto-mapping (wwids need to be provided by hand). Well, it wants you to use the `multipath` program to add a binding/wwid. This is quite explicit, but also always works. In my experience, once you leave the realm of test setups, its best to have explicit configuration. Well, at least some notes about the required manual configuration and steps to get the wwids (e.g. hinting /lib/udev/scsi_id) and finalize the config, or even alternative settings would be nice. I find the README.Debian included not the most clear possible. [...] I'll note that this is a sample for 0.4.9, and this is very old. Chris That's taken from RHEL 7 documentation, I `suppose` now it is updated. -- Francesco P. Lovergine
Bug#1031261: Please, provide a valid initial configuration in /etc/multipath.conf
Package: multipath-tools
Version: 0.9.4-3
Severity: wishlist
Hi,
after installation multipath-tools does not work properly in order to activate
mapping for devices automagically after the boot.
I finally figured out that
multipath -t >/etc/multipath.conf
generates an initial configuration which is usable, but for a
find_multipaths "strict"
which is the least friendly way of defining mappings and
practically prevents any auto-mapping (wwids need to be provided by hand).
While that is a perfectly working setup if properly manually configured, for
sure it is
not the easiast setting to cope with IMHO.
The final result, for instance, is that LVM could catch all single devices at
boot
and the proper multipaths maps result broken, with the admin not familiar with
multipathd inners lost in the dark.
A very simple configuration such as:
defaults {
user_friendly_names yes
find_multipaths yes
}
and a round of update-initramfs after that, gives a proper working
implementation, with
LVM perfectly capable of coping with variable names at boot time.
Note that RH folks provides a mpathconf script and an initial template
in /usr/share/doc/device-mapper-multipath-0.4.9/multipath.conf for that.
--
Francesco P. Lovergine
Bug#1027709: has_option command not found
Package: x2goserver-xsession Version: 4.1.0.3-5 Severity: normal Launching an x2go session on a sid host, my .xsession-x2go--errors is populated of errors, like (sorry for the italian lang): /etc/x2go/Xsession.d/30x11-common_xresources: riga 16: has_option: comando non trovato /etc/x2go/Xsession.d/75dbus_dbus-launch: riga 9: has_option: comando non trovato /etc/x2go/Xsession.d/90x11-common_ssh-agent: riga 9: has_option: comando non trovato This is very similar to recurring error seen elsewhere due to a missing execution of /etc/X11/Xsession, e.g. https://github.com/canonical/lightdm/issues/198 https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1922414 Apparently this could also prevent x2go session starting (still not sure: currently the session starts and exits, with a warning: dbus-update-activation-environment: warning: error sending to systemd: org.freedesktop.DBus.Error.Spawn.ChildExited: Process org.freedesktop.systemd1 exited with status 1 ). -cheers -- Francesco P. Lovergine
Bug#1019428: Please, fix sudo to cope with libgcrypt changes (apparently)
On Fri, Sep 09, 2022 at 07:38:48PM +0200, Marc Haber wrote: Control: tag -1 unreproducible On Fri, Sep 09, 2022 at 08:58:29AM +0200, Francesco P. Lovergine wrote: Sudo reports tons of messages like: sudo: Libgcrypt warning: missing initialization - please fix the application in syslog. Please, fix to avoid eccessive verbosity due to that. This is a quite annoying issue already fixed in other applications here and there (e.g. apt). I do not see this behavior on my systems at all. Can you please elaborate a bit? Greetings Marc Indeed it seeems the warning is triggered under certain conditions that I still did not detect. For sure, the warning is presented only during the first use of sudo in a login shell and it seems the same warning is presented for ssh, immediately beforei that. Just to note, the same warning is confirmed in the past for a series of programs (including sudo) and started to be shown after the following change in gcrypt: http://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgcrypt.git;a=commitdiff_plain;h=7627f9646701e88c827bbadd1231221d5f0c89a6 See: https://bugs.launchpad.net/ubuntu/+source/sudo/+bug/1397663 and other reports here and there. I could think it relates to the use of forward agent for gnupg in login sessions, so not directly connected to sudo, but triggered in any case at pam level (?). Eventually this issue should/could be reassigned to gnupg, but I'm not sure. -- Francesco P. Lovergine
Bug#1019428: Please, fix sudo to cope with libgcrypt changes (apparently)
Package: sudo Version: 1.9.11p3-1 Severity: normal Sudo reports tons of messages like: sudo: Libgcrypt warning: missing initialization - please fix the application in syslog. Please, fix to avoid eccessive verbosity due to that. This is a quite annoying issue already fixed in other applications here and there (e.g. apt). -- Francesco P. Lovergine
Bug#983138: ypserv: path to "bash" varies on usrmerge system
On Sun, Jul 17, 2022 at 01:52:46PM +0100, Simon McVittie wrote: On Fri, 19 Feb 2021 at 14:38:09 -0800, Vagrant Cascadian wrote: The configure script sets the BASH variable to /bin/sh when run on a usrmerge system, resulting in the pwupdate script differing between builds: https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/ypserv.html ./usr/lib/yp/pwupdate #!/bin/bash vs. #!/bin/sh In general, the Debian technical committee resolution https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=994388#110 recommends treating this class of bug as release-critical for Debian 12. However, without knowing anything about the specifics of this package, I'm unsure whether this specific bug is RC or not: will the pwupdate script still work correctly with a purely POSIX shell like dash? If it does not, then the severity of this bug should be raised to serious. Regardless of whether this is RC or not, it would be great to have it fixed for Debian 12. Vagrant's patch looks appropriate. Thanks, smcv The patch looks good enough to fix the pwupdate generation. In any case, the script seems currently POSIX compliant, so using /bin/bash or /bin/sh looks indifferent. -cheers -- Francesco P. Lovergine
Bug#997430: xaw3d: FTBFS: -q: invalid option -- '.'
tags 997430 + help
thanks
On Sat, Oct 23, 2021 at 10:36:29PM +0200, Lucas Nussbaum wrote:
Source: xaw3d
Version: 1.5+F-1
Severity: serious
Justification: FTBFS
Tags: bookworm sid ftbfs
User: lu...@debian.org
Usertags: ftbfs-20211023 ftbfs-bookworm
Hi,
During a rebuild of all packages in sid, your package failed to build
on amd64.
Relevant part (hopefully):
[...]
This seems more a breakage in binutils and/or xmkmf generated Makefile, than a
problem in the problem in the Imakefile per se, which does not define anything
related to the static library linkage.
Any ideas would be appreciated about this issue.
rm -f libXaw3d.so.6.1~
+ cd .
+ gcc -o ./libXaw3d.so.6.1~ -shared -Wl,-soname,libXaw3d.so.6 AllWidgets.o
AsciiSink.o AsciiSrc.o AsciiText.o Box.o Command.o Dialog.o Form.o Grip.o
Label.o Layout.o List.o MenuButton.o Paned.o Panner.o Porthole.o Repeater.o
Scrollbar.o Simple.o SimpleMenu.o Sme.o SmeBSB.o SmeLine.o SmeThreeD.o
StripChart.o Text.o TextSink.o TextSrc.o TextAction.o TextPop.o TextTr.o
ThreeD.o Tip.o Toggle.o Tree.o Vendor.o Viewport.o Xaw3dP.o XawInit.o laygram.o
laylex.o MultiSrc.o MultiSink.o XawIm.o XawI18n.o -lXmu -lXt -lSM -lICE -lXext
-lX11 -lXt -lSM -lICE -lXpm -lXext -lX11 -lc
/usr/bin/ld: AsciiSrc.o: in function `InitStringOrFile':
/<>/xc/lib/Xaw3d/AsciiSrc.c:1067: warning: the use of `tmpnam' is
dangerous, better use `mkstemp'
+ rm -f libXaw3d.so.6
+ ln -s libXaw3d.so.6.1 libXaw3d.so.6
rm -f libXaw3d.so.6.1
mv -f libXaw3d.so.6.1~ libXaw3d.so.6.1
+ rm -f libXaw3d.so
+ ln -s libXaw3d.so.6.1 libXaw3d.so
rm -f libXaw3d.a
+ cd unshared
+ ar clq ../libXaw3d.a AllWidgets.o AsciiSink.o AsciiSrc.o AsciiText.o Box.o
Command.o Dialog.o Form.o Grip.o Label.o Layout.o List.o MenuButton.o Paned.o
Panner.o Porthole.o Repeater.o Scrollbar.o Simple.o SimpleMenu.o Sme.o SmeBSB.o
SmeLine.o SmeThreeD.o StripChart.o Text.o TextSink.o TextSrc.o TextAction.o
TextPop.o TextTr.o ThreeD.o Tip.o Toggle.o Tree.o Vendor.o Viewport.o Xaw3dP.o
XawInit.o laygram.o laylex.o MultiSrc.o MultiSink.o XawIm.o XawI18n.o
-q: invalid option -- '.'
Usage: ar [emulation options] [-]{dmpqrstx}[abcDfilMNoOPsSTuvV] [--plugin
] [member-name] [count] archive-file file...
ar -M [ ] - specify the dependencies of this library
[S] - do not build a symbol table
[T] - make a thin archive
[v] - be verbose
[V] - display the version number
@ - read options from
--target=BFDNAME - specify the target object format as BFDNAME
--output=DIRNAME - specify the output directory for extraction operations
--record-libdeps= - specify the dependencies of this library
optional:
--plugin - load the specified plugin
emulation options:
No emulation specific options
ar: supported targets: elf64-x86-64 elf32-i386 elf32-iamcu elf32-x86-64
pei-i386 pe-x86-64 pei-x86-64 elf64-l1om elf64-k1om elf64-little elf64-big
elf32-little elf32-big pe-bigobj-x86-64 pe-i386 srec symbolsrec verilog tekhex
binary ihex plugin
make[2]: *** [Makefile:1158: libXaw3d.a] Error 1
--
Francesco P. Lovergine
Bug#989929: Suddenly restarting fetchmail started to fail with error about its global pidfile
On Thu, Jun 24, 2021 at 07:11:02PM +0200, László Böszörményi (GCS) wrote: Control: tags -1 +pending moreinfo On Wed, Jun 16, 2021 at 10:00 AM Francesco P. Lovergine wrote: This is currently run on testing since ages. I had to restart due to a changed fingerprint and the global service started to fail with: [...] giu 16 08:07:28 klecker fetchmail[846499]: fetchmail: lock creation failed, pidfile "/run/fetchmail/fetchmail.pid": File o directory non esistente Thanks for the report and the proposed fix! Can you please check if the updated package[1] is fine for you now? Cheers, Laszlo/GCS [1] dget -x https://people.debian.org/~gcs/fetchmail_6.4.16-2.dsc Yes it is working. -- Francesco P. Lovergine
Bug#989929: Suddenly restarting fetchmail started to fail with error about its global pidfile
Package: fetchmail Version: 6.4.16-1 Severity: grave This is currently run on testing since ages. I had to restart due to a changed fingerprint and the global service started to fail with: $ systemctl status fetchmail.service ● fetchmail.service - LSB: init-Script for system wide fetchmail daemon Loaded: loaded (/etc/init.d/fetchmail; generated) Active: active (exited) since Wed 2021-06-16 08:07:28 CEST; 1h 23min ago Docs: man:systemd-sysv-generator(8) Tasks: 0 (limit: 9313) Memory: 0B CPU: 0 CGroup: /system.slice/fetchmail.service giu 16 08:07:28 klecker systemd[1]: Starting LSB: init-Script for system wide fetchmail daemon... giu 16 08:07:28 klecker fetchmail[846490]: Starting mail retriever agent: fetchmail. giu 16 08:07:28 klecker systemd[1]: Started LSB: init-Script for system wide fetchmail daemon. giu 16 08:07:28 klecker fetchmail[846499]: starting fetchmail 6.4.16 daemon giu 16 08:07:28 klecker fetchmail[846499]: fetchmail: lock creation failed, pidfile "/run/fetchmail/fetchmail.pid": File o directory non esistente The /run/fetchmail directory ownership is correct (fetchmail:nogroup) and if I start the process by hand with: sudo -u fetchmail -- fetchmail --pidfile /run/fetchmail/fetchmail.pid --nosslcertck -f /etc/fetchmailrc --syslog it works regularly. So the problem is with the init script, still used by systemd. Here: start-stop-daemon -S -o -q -p $PIDFILE -x $DAEMON -u $USER -c $USER -- $OPTIONS; I think the problem resides. I see that the pidfile is passed at the same time to start-stop-daemon and the daemon (-p and $OPTIONS) which run in unprivileged mode. I changed the instruction into: start-stop-daemon -S -o -q -x $DAEMON -u $USER -c $USER -- $OPTIONS; and now it works. Note that currently man page reports: Warning: Using this match option with a world-writable pidfile or using it alone with a daemon that writes the pidfile as an unprivileged (non-root) user will be refused with an error (since version 1.19.3) as this is a security risk, because either any user can write to it, or if the daemon gets compromised, the contents of the pidfile cannot be trusted, and then a privileged runner (such as an init script executed as root) would end up acting on any system process. Using /dev/null is exempt from these checks. and bullseye runs dpkg v1.20.9 currently. I'm tagging this bug as grave because even if fetchmail is not always used in daemon mode, it breaks for sure existing configurations in an unexpected way (and the reason is quite obscure for the casual user) - cheers -- System Information: Debian Release: 11.0 APT prefers testing APT policy: (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-7-amd64 (SMP w/4 CPU threads) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages fetchmail depends on: ii adduser 3.118 ii debianutils 4.11.2 ii libc6 2.31-12 ii libcom-err2 1.46.2-1 ii libgssapi-krb5-2 1.18.3-5 ii libkrb5-3 1.18.3-5 ii libssl1.1 1.1.1k-1 ii lsb-base 11.1.0 Versions of packages fetchmail recommends: ii ca-certificates 20210119 Versions of packages fetchmail suggests: ii exim4-daemon-heavy [mail-transport-agent] 4.94.2-5 pn fetchmailconf pn resolvconf -- Configuration Files: /etc/default/fetchmail changed: OPTIONS=--nosslcertck START_DAEMON=yes PIDFILE=/run/fetchmail/fetchmail.pid -- no debconf information -- Francesco P. Lovergine
Bug#988341: unblock: nis/4.3
retitle 988341 unblock: nis/4.4 tags 988341 - moreinfo thanks debdiff included On Tue, May 11, 2021 at 08:42:46PM +0200, Sebastian Ramacher wrote: On 2021-05-11 10:52:13 +0200, Francesco P. Lovergine wrote: I found also a pending doc-only change still seating in my repo: diff --git a/debian/nis.debian.howto b/debian/nis.debian.howto index e90e549..2641b86 100644 --- a/debian/nis.debian.howto +++ b/debian/nis.debian.howto @@ -66,6 +66,13 @@ The NIS how-to on Debian 2.1 FOR LIBC6: + Ensure to have libnss-nis package installed. It is currently + only recommended by both libc and ypbind-mt, because it is not an + essential component for the system. Even, for your own reasons you + could be interested in binding a NIS domain to access the NIS maps via + yptools, but not activating it as an account information provider for + the system. +Check your /etc/nsswitch.conf file and make sure that the entries for passwd, group, shadow and netgroup look like this: I could add this note to the source-only upload, possibly. Is it ok? Yes, that's okay and in line with the freeze policy. Cheers On Tue, May 11, 2021 at 10:34:32AM +0200, Sebastian Ramacher wrote: > Control: tags -1 confirmed moreinfo > > On 2021-05-10 20:43:26 +0200, Francesco P. Lovergine wrote: > > Package: release.debian.org > > Severity: normal > > User: release.debian@packages.debian.org > > Usertags: unblock > > > > Please unblock package nis > > > > [ Reason ] > > > > Fixes serious bug #988227 (bashism in postinst). > > > > [ Impact ] > > > > Upgrade not smoothly done from stable. > > > > [ Tests ] > > > > No autopkg test. Manually tested with dash. > > > > [ Risks ] > > > > None. > > > > [ 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 testing > > > > [ Other info ] > > > > Native migration package only. > > > > unblock nis/4.3 > > Not built on buildd: arch all binaries uploaded by frankie, a new source-only upload is needed to allow migration > > Please perform a source-only upload and remove the moreinfo tag once > that's done. > > Cheers > > > > > -- > > Francesco P. Lovergine > > > diff -Nru nis-4.2/debian/changelog nis-4.3/debian/changelog > > --- nis-4.2/debian/changelog 2021-01-31 10:22:32.0 +0100 > > +++ nis-4.3/debian/changelog 2021-05-08 17:19:24.0 +0200 > > @@ -1,3 +1,10 @@ > > +nis (4.3) unstable; urgency=medium > > + > > + * Fixed a sort-of bashism in postinst. > > +(closes: #988227) > > + > > + -- Francesco Paolo Lovergine Sat, 08 May 2021 17:19:24 +0200 > > + > > nis (4.2) unstable; urgency=medium > > > >* Missed removing of /etc/init.d/nis at upgrade time added. > > diff -Nru nis-4.2/debian/postinst nis-4.3/debian/postinst > > --- nis-4.2/debian/postinst 2021-01-31 10:22:32.0 +0100 > > +++ nis-4.3/debian/postinst 2021-05-08 17:19:24.0 +0200 > > @@ -73,10 +73,13 @@ > > case "$1" in > > configure) > > PREV_VER="$2" > > - if [ ! -z "$PREV_VER" -a $(dpkg --compare-versions "$PREV_VER" lt '4~'; echo $?) -eq 0 ] > > -then > > - upgrade_old > > -fi > > + if [ ! -z "$PREV_VER" ] > > + then > > + if dpkg --compare-versions "$PREV_VER" lt '4~' > > + then > > + upgrade_old > > + fi > > + fi > > rm -f /etc/init.d/nis > > ;; > > *) > > > -- > Sebastian Ramacher -- Francesco P. Lovergine -- Sebastian Ramacher -- Francesco P. Lovergine diff -Nru nis-4.2/debian/changelog nis-4.4/debian/changelog --- nis-4.2/debian/changelog 2021-01-31 09:22:32.0 + +++ nis-4.4/debian/changelog 2021-05-12 07:00:39.0 + @@ -1,3 +1,16 @@ +nis (4.4) unstable; urgency=medium + + * Added a brief note about the recommended libnss-nis package in NIS howto doc. + + -- Francesco Paolo Lovergine Wed, 12 May 2021 09:00:39 +0200 + +nis (4.3) unstable; urgency=medium + + * Fixed a sort-of bashism in postinst. +(closes: #988227) + + -- Francesco Paolo Lovergine Sat, 08 May 2021 17:19:24 +0200 + nis (4.2) unstable; urgency=medium * Missed removing of /etc/init.d/nis at upgrade time added. diff -Nru nis-4.2/debian/nis.debian.howto nis-4.4/debian/nis.debian.howto --- nis-4.2/debian/nis.debian.ho
Bug#988341: unblock: nis/4.3
I found also a pending doc-only change still seating in my repo:
diff --git a/debian/nis.debian.howto b/debian/nis.debian.howto
index e90e549..2641b86 100644
--- a/debian/nis.debian.howto
+++ b/debian/nis.debian.howto
@@ -66,6 +66,13 @@ The NIS how-to on Debian
2.1 FOR LIBC6:
+ Ensure to have libnss-nis package installed. It is currently
+ only recommended by both libc and ypbind-mt, because it is not an
+ essential component for the system. Even, for your own reasons you
+ could be interested in binding a NIS domain to access the NIS maps via
+ yptools, but not activating it as an account information provider for
+ the system.
+
Check your /etc/nsswitch.conf file and make sure that the entries for
passwd, group, shadow and netgroup look like this:
I could add this note to the source-only upload, possibly. Is it ok?
On Tue, May 11, 2021 at 10:34:32AM +0200, Sebastian Ramacher wrote:
Control: tags -1 confirmed moreinfo
On 2021-05-10 20:43:26 +0200, Francesco P. Lovergine wrote:
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package nis
[ Reason ]
Fixes serious bug #988227 (bashism in postinst).
[ Impact ]
Upgrade not smoothly done from stable.
[ Tests ]
No autopkg test. Manually tested with dash.
[ Risks ]
None.
[ 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 testing
[ Other info ]
Native migration package only.
unblock nis/4.3
Not built on buildd: arch all binaries uploaded by frankie, a new source-only
upload is needed to allow migration
Please perform a source-only upload and remove the moreinfo tag once
that's done.
Cheers
--
Francesco P. Lovergine
diff -Nru nis-4.2/debian/changelog nis-4.3/debian/changelog
--- nis-4.2/debian/changelog2021-01-31 10:22:32.0 +0100
+++ nis-4.3/debian/changelog2021-05-08 17:19:24.0 +0200
@@ -1,3 +1,10 @@
+nis (4.3) unstable; urgency=medium
+
+ * Fixed a sort-of bashism in postinst.
+(closes: #988227)
+
+ -- Francesco Paolo Lovergine Sat, 08 May 2021 17:19:24
+0200
+
nis (4.2) unstable; urgency=medium
* Missed removing of /etc/init.d/nis at upgrade time added.
diff -Nru nis-4.2/debian/postinst nis-4.3/debian/postinst
--- nis-4.2/debian/postinst 2021-01-31 10:22:32.0 +0100
+++ nis-4.3/debian/postinst 2021-05-08 17:19:24.0 +0200
@@ -73,10 +73,13 @@
case "$1" in
configure)
PREV_VER="$2"
- if [ ! -z "$PREV_VER" -a $(dpkg --compare-versions "$PREV_VER"
lt '4~'; echo $?) -eq 0 ]
-then
-upgrade_old
-fi
+ if [ ! -z "$PREV_VER" ]
+ then
+ if dpkg --compare-versions "$PREV_VER" lt '4~'
+ then
+ upgrade_old
+ fi
+ fi
rm -f /etc/init.d/nis
;;
*)
--
Sebastian Ramacher
--
Francesco P. Lovergine
Bug#988341: unblock: nis/4.3
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package nis [ Reason ] Fixes serious bug #988227 (bashism in postinst). [ Impact ] Upgrade not smoothly done from stable. [ Tests ] No autopkg test. Manually tested with dash. [ Risks ] None. [ 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 testing [ Other info ] Native migration package only. unblock nis/4.3 -- Francesco P. Lovergine diff -Nru nis-4.2/debian/changelog nis-4.3/debian/changelog --- nis-4.2/debian/changelog 2021-01-31 10:22:32.0 +0100 +++ nis-4.3/debian/changelog 2021-05-08 17:19:24.0 +0200 @@ -1,3 +1,10 @@ +nis (4.3) unstable; urgency=medium + + * Fixed a sort-of bashism in postinst. +(closes: #988227) + + -- Francesco Paolo Lovergine Sat, 08 May 2021 17:19:24 +0200 + nis (4.2) unstable; urgency=medium * Missed removing of /etc/init.d/nis at upgrade time added. diff -Nru nis-4.2/debian/postinst nis-4.3/debian/postinst --- nis-4.2/debian/postinst 2021-01-31 10:22:32.0 +0100 +++ nis-4.3/debian/postinst 2021-05-08 17:19:24.0 +0200 @@ -73,10 +73,13 @@ case "$1" in configure) PREV_VER="$2" - if [ ! -z "$PREV_VER" -a $(dpkg --compare-versions "$PREV_VER" lt '4~'; echo $?) -eq 0 ] -then -upgrade_old -fi + if [ ! -z "$PREV_VER" ] + then + if dpkg --compare-versions "$PREV_VER" lt '4~' + then + upgrade_old + fi + fi rm -f /etc/init.d/nis ;; *)
Bug#987920: ypbind-mt: /etc/defaultdomain should be created at installation time
On Mon, May 10, 2021 at 06:45:40PM +0900, Yasuhiro Kimura wrote: From: Francesco Paolo Lovergine Subject: Re: Bug#987920: ypbind-mt: /etc/defaultdomain should be created at installation time Date: Sun, 02 May 2021 08:48:06 +0200 Indeed, the general NIS howto included in the nis package provides the full documentation for who upgrades or install both servers and clients. A small per program README could probably be a good idea for minimal setup. My original idea was having the nis package as a doc only package after bullseye. It is now a migration package, instead. Well, I think that a simple README file could be added at this stage of release... According to the unit file of ypbind.service, the value of YPBINDARGS environment variable is passed as arguments when systemd starts ypbind process. Then how does user set it if he wants to start ypbind with arguments? As far as I see the unit file this package doesn't seem to provide the way to set it. I'm not familiar with systemd but does systemd itself provide such functionality? Just set all vars in /etc/default/nis, this is the same approach used in the old package and init file. Of course it is also possible to override the default unit file with and administrator provided one in /etc/systemd -- Francesco P. Lovergine
Bug#988227: nis: /var/lib/dpkg/info/nis.postinst: 76: [: -eq: unexpected operator
Thanks for the report, but I can't see why a line like: if [ ! -z "$PREV_VER" -a $(dpkg --compare-versions "$PREV_VER" lt '4~'; echo $?) -eq 0 ] should fail under dash (which is even the default shell on Debian). You are trying to upgrade 4.2 to 4.2 in this case. Then it should run like: if [ ! -z "4.2" -a $(dpkg --compare-versions "4.2" lt '4~'; echo $?) -eq 0 ] and it works perfectly fine under dash. :-? Could you please verify that /bin/sh links /bin/dash and what is the dash version via dpkg -l ? On Sat, May 08, 2021 at 09:30:30AM +0200, Paul Menzel wrote: Package: nis Version: 4.2 Severity: normal Dear Debian folks, I encountered this in Ubuntu [1], but they use the Debian package. With `/bin/sh` being dash and not Bash, the postinst script fails. ``` $ sudo apt reinstall nis Reading package lists... Done Building dependency tree... Done Reading state information... Done 0 upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 0 not upgraded. Need to get 14.2 kB of archives. After this operation, 0 B of additional disk space will be used. Get:1 http://de.ports.ubuntu.com/ubuntu-ports hirsute/universe ppc64el nis all 4.2 [14.2 kB] Fetched 14.2 kB in 0s (110 kB/s) (Reading database ... 420369 files and directories currently installed.) Preparing to unpack .../apt/archives/nis_4.2_all.deb ... update-rc.d: error: unable to read /etc/init.d/nis Unpacking nis (4.2) over (4.2) ... Setting up nis (4.2) ... /var/lib/dpkg/info/nis.postinst: 76: [: -eq: unexpected operator ``` Using `/bin/bash` in the shebang of the postinst script, and doing `dpkg -a --configure` worked around this issue. Kind regards, Paul [1]: https://bugs.launchpad.net/ubuntu/+source/nis/+bug/1927540 [2]: https://salsa.debian.org/debian-nis-team/nis/-/blob/master/debian/postinst#L76 -- Francesco P. Lovergine
Bug#988178: Newer ypbind-mt package also affected
On Fri, May 07, 2021 at 12:28:24AM +, Brian Morris wrote: I also looked at the source of the newer ypbind-mt package in the Testing branch and it appears to have the same issue. Hi I guess you are talking about the init script still provided? -- Francesco P. Lovergine
Bug#984560: NIS binary maps could be broken after upgrades, due to GDBM oddities
On Sun, Mar 07, 2021 at 07:00:06AM +, McIntyre, Vincent (CASS, Marsfield) wrote: On Fri, Mar 05, 2021 at 09:51:34AM +0100, Francesco P. Lovergine wrote: Thank you for the quick reply. I agree with all your points and that there's little to be done but document the issue. I'm happy for this to be closed. If both buster & bullseye link with libgdbm6 then I agree it's unlikely this issue will arise during upgrades. I plan to send a wishlist patch for the nis.debian.howto, or a new README.Debian file - hopefully that will be useful. Do you prefer bugs+patches or PRs? Kind regards Vince Thinking about that, a new wishlist to integrate the documentation is welcome, with a diff file for nis.debian.howto. About the main issue, the current version of NIS supports other DBM implementations, such as qdbm or even tokyocabinet whose formats seem sane and endian-aware at a first glance. Of course, moving to a new implementation requires a rebuild of maps and a migration of all servers and clients together. I will conduct a few experiments about that to avoid heart attacks for the average admin, but that is probably the way to go in the new millennium, after bullseye. Even, the use of a different implementation has impact about interoperability with other distributions and flavors of *nix. But, the current situation is not better and NIS is not more a prime time system, since years. Thanks for having reported this long standig issue to my attention. -cheers -- Francesco P. Lovergine
Bug#984616: nis: prompting due to modified conffiles which were not modified by the user: /etc/default/nis
On Fri, Mar 05, 2021 at 09:57:27PM +0100, Andreas Beckmann wrote: during a test with piuparts I noticed your package failed the piuparts upgrade test because dpkg detected a conffile as being modified and then prompted the user for an action. As there is no user input, this fails. But this is not the real problem, the real problem is that this prompt shows up in the first place, as there was nobody modifying this conffile at all, the package has just been installed and upgraded... This is a violation of policy 10.7.3, see https://www.debian.org/doc/debian-policy/ch-files.html#behavior, which says "[These scripts handling conffiles] must not ask unnecessary questions (particularly during upgrades), and must otherwise be good citizens." This is a non sense, the 4 series is proposing a relevant change to the system, that is having all services off in that stupid file (the previous insane default was having the system in client+broadcast mode). The simple mechanism of conffiles can only undestand if the new default is different from the current file, not if the user maintained that on purpose or not. So a the question IS relevant. The whole wide changes are explained in the NEWS file and a sane admin will prefer to have all services stopped and act for the better. -- Francesco P. Lovergine
Bug#984560: nis: first byte in map changed
retitle 984560 NIS binary maps could be broken after upgrades, due to GDBM oddities thanks On Fri, Mar 05, 2021 at 03:40:35AM +, McIntyre, Vincent (CASS, Marsfield) wrote: Between stretch and buster, something subtle changed in makedbm. A map produced by the makedbm in stretch starts with the byte 0xCE. A map produced by the nakedbm in buster starts with the byte 0xCF. This makes it impossible for stretch clients to understand the contents of the map file, they just give up. Eh, this is the result of a system of propagation of information that is not arch independent and based on file format that could change its inner structure for tons of different reasons. See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=923609 for instance. and specifically the NOTES-WARNING: - Gdbm files have never been `portable' between different operating systems, system architectures, or potentially even different compilers. Differences in byte order, the size of file offsets, and even structure packing make gdbm files non-portable. - I would say that your problem was totally expected, but none pointed that issue at the time of latest release, in the release notes for instance. That implies that master/slaves _must_ be aligned to ensure a working service, and that is a requirement, not a suggestion. While one can mix clients and servers, the NIS propagation of binary maps can be broken from time to time and between different platforms. That even applies to each master/slave upgrades. I'm afraid that's nothing I can manage to do in order to deal with this type of issues, at this stage of release cycle. For sure, in next releases a map rebuild from time to time could be introduced at upgrade time, but - as you can see - the changes could be subtle and unexpected, so the most safe approach is probably to warn about that in documentation, and suggest a rebuild of maps at every binary upgrade, starting from master. And of course never cross the streams It would be bad ;-) For sure I can't see expected issues in buster -> bullseye upgrades, at least. I'm currently using in production a bullseye master, mixed with buster clients and slaves without problems. -- Francesco P. Lovergine
Bug#983521: Caja active loop causes high cpu loads randomly
Source: caja Severity: important Due to smart working increase, I recently installed mate for our users at job, with x2go/vnc servers. Soon, I found that caja randomly starts to cause high cpu loads, and having autodir even installed it also started to log tons of messages like: /var/log/syslog.1:Feb 24 18:31:07 milos autodir[3794]: [autohome] warning: no user found with name .bmp /var/log/syslog.1:Feb 24 18:31:07 milos autodir[3794]: [autohome] alert: module autohome failed on .bmp /var/log/syslog.1:Feb 24 18:31:07 milos autodir[3794]: [autohome] warning: no user found with name .cur /var/log/syslog.1:Feb 24 18:31:07 milos autodir[3794]: [autohome] alert: module autohome failed on .cur /var/log/syslog.1:Feb 24 18:31:07 milos autodir[3794]: [autohome] warning: no user found with name .gif /var/log/syslog.1:Feb 24 18:31:07 milos autodir[3794]: [autohome] alert: module autohome failed on .gif /var/log/syslog.1:Feb 24 18:31:07 milos autodir[3794]: [autohome] warning: no user found with name .icns /var/log/syslog.1:Feb 24 18:31:07 milos autodir[3794]: [autohome] alert: module autohome failed on .icns /var/log/syslog.1:Feb 24 18:31:07 milos autodir[3794]: [autohome] warning: no user found with name .ico /var/log/syslog.1:Feb 24 18:31:07 milos autodir[3794]: [autohome] alert: module autohome failed on .ico [...] where is a valid user id. This eventually causes big issues for dozens of GBs of similar messages in a few days. Of course, a workaround for the syslog stress is rate-limiting the autodir process in rsyslog configuration, but the reason for the apparent looping of caja is unknown. Even, that starts randomly, probably triggered by unknown interactions of the user with caja. This is specific of the mate desktop, never saw with other environments (even if here we are not big GUI users, and often use lighter WMs). -- Francesco P. Lovergine
Bug#983170: s3ql: High load causes "Transport endpoint is not connected"
On Sat, Feb 20, 2021 at 01:24:16PM +, Graham Cobb wrote: Package: s3ql Version: 3.7.0+dfsg-2 Severity: important Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these template lines *** After upgrading s3ql from 3.3.2+dfsg-1 I suffered from bug #982381 (trio) so I tried manually installing trio 0.15 (as mentioned in that thread). Although it allowed some files to be created, any long or complex operation (such as a backup, or even an `rm -rf` of a large directory) cause a 'Software caused connection abort' error followed by enormous numbers of 'Transport endpoint is not connected' errors. In case it was some transient network problem, I used fsck.s3ql to fix the filesystem and retried - same errors. And the same errors if I (fsck again and) just try a `rm -rf` on a large directory. I then tried installing trio 0.18. Same problem. Mounting is working. fsck is working. Simple file operations are working. But heavy load causes 'Software caused connection abort'. Completely repeatable. The following commands reproduce the problem for me: cd /mnt/mountpoint count=100 mkdir testdir ; for f in `seq 1 $count` ; do mkdir testdir/$f ; dd if=/dev/urandom bs=1000 count=1 of=testdir/$f/test status=none ; done rm -rf testdir umount /mnt/mountpoint With the count at 100 the problem occurs when the unmount happens. If the count is increased to 2000 the problem occurs during the run. This is using the S3 backend. By the way, this workload has been working for many years with no problems, and was working with 3.3.2+dfsg-1 before I decided to try testing 3.7.0+dfsg-2. Could you please follow-up with your ~/.s3ql/mount.log log about the error? -- Francesco P. Lovergine
Bug#983170: s3ql: High load causes "Transport endpoint is not connected"
severity 983170 grave tags 983170 + upstream help thanks It seems to me that this version cannot simply be distributed as is. Even, the wrong assumption about trio version compatibility renders it not compatible with bullseye status. On Sat, Feb 20, 2021 at 01:24:16PM +, Graham Cobb wrote: Package: s3ql Version: 3.7.0+dfsg-2 Severity: important Dear Maintainer, After upgrading s3ql from 3.3.2+dfsg-1 I suffered from bug #982381 (trio) so I tried manually installing trio 0.15 (as mentioned in that thread). Although it allowed some files to be created, any long or complex operation (such as a backup, or even an `rm -rf` of a large directory) cause a 'Software caused connection abort' error followed by enormous numbers of 'Transport endpoint is not connected' errors. In case it was some transient network problem, I used fsck.s3ql to fix the filesystem and retried - same errors. And the same errors if I (fsck again and) just try a `rm -rf` on a large directory. I then tried installing trio 0.18. Same problem. Mounting is working. fsck is working. Simple file operations are working. But heavy load causes 'Software caused connection abort'. Completely repeatable. The following commands reproduce the problem for me: cd /mnt/mountpoint count=100 mkdir testdir ; for f in `seq 1 $count` ; do mkdir testdir/$f ; dd if=/dev/urandom bs=1000 count=1 of=testdir/$f/test status=none ; done rm -rf testdir umount /mnt/mountpoint With the count at 100 the problem occurs when the unmount happens. If the count is increased to 2000 the problem occurs during the run. This is using the S3 backend. By the way, this workload has been working for many years with no problems, and was working with 3.3.2+dfsg-1 before I decided to try testing 3.7.0+dfsg-2. -- Francesco P. Lovergine
Bug#982381: AttributeError: lowlevel due to trio usage in s3ql/block_cache.py
On Sun, Feb 14, 2021 at 01:38:58PM +1100, Lorentz Kim wrote: Hi, I don't know if it'll help much, but I've also gotten this bug and have resolved it by manually upgrading python3-trio with pip to its latest version, overriding system's installed version (which is 0.13 last I checked). pip install trio==0.18.0 Pretty sure the s3ql release notes for 3.7 suggests anything after trio 0.9 is supported, but perhaps there's a bug in there somewhere? Regards, Lorentz I'm pretty sure this release should depend on >= 0.15, even due to #981906. Unfortunately, it is not expressed in the package, so yes it is an upstream issue apparently. -- Francesco P. Lovergine
Bug#983035: Missing dependency on dbus-x11
Package: xfce4 Version: 4.16 Severity: normal I found a missing dependency on /usr/bin/dbus-launch (dbus-x11) in bullseye, somewhere. Not sure this is an xfce4 issue specifically, feel free to reassign to another proper package. In order to replicate the problem: I just installed from scratch a bullseye current image (debian/testing64) in vagrant, with virtualbox provider, an upgraded it. Then installed xfce4i (the metapackage) and started lightdm. After that, the user cannot login and start a session due to missing dbus-launch, with appropriate message at screen. Installing dbus-x11 solves the problem. -cheers -- Francesco P. Lovergine
Bug#982879: Acknowledgement (Artifacts in x2go rendering connecting to testing from a buster client)
On Thu, Feb 18, 2021 at 11:22:27AM +0100, Francesco P. Lovergine wrote: On Thu, Feb 18, 2021 at 10:56:04AM +0100, Francesco P. Lovergine wrote: Update: I tested also with a vagrant installation of a testing64 vm (from scratch), under a virtualbox provider. It gives exactly the same result. IMHO this bug should be raised to important or grave because could render unusable the x2goserver in bullseye for many (if not most) use cases :-( I still did not check the use of bullseye from a bullseye client or other platforms. ... and it gives the same artifacts using a bullseye client (which works perfectly while connecting a buster x2go server). So this is definitively an issue of the x2goserver in bullseye. Ok, workaround: disable composite rendering, which could be done in both xfce and mate settings, for instance. -- Francesco P. Lovergine
Bug#982879: Acknowledgement (Artifacts in x2go rendering connecting to testing from a buster client)
Update: I tested also with a vagrant installation of a testing64 vm (from scratch), under a virtualbox provider. It gives exactly the same result. IMHO this bug should be raised to important or grave because could render unusable the x2goserver in bullseye for many (if not most) use cases :-( I still did not check the use of bullseye from a bullseye client or other platforms. -- Francesco P. Lovergine
Bug#981407: sysv-generator is really annoying with an eccessive verbosity
On Tue, Feb 16, 2021 at 12:17:49AM +0100, Michael Biebl wrote: Am 02.02.21 um 10:11 schrieb Francesco P. Lovergine: Well, the truly annoying thing is that it warns even for init scripts disabled, but never removed (sometimes on purpose, sometimes due to package errors). I discovered a few of them still around since years, and reduced a bit the noisei by purging. But isn't this a good thing, that it shows you that there is old cruft? Yes, but while it is reasonable at upgrade time, it is annoying at every restart of services. For sure this system is up since 28th of Jan and dmesg shows only messages after 30th of Jan currently. So generally, at every restart of services the syslog is populated with those warnings in good quantity. Any system upgraded several times and/or used for development will present tons of this warnings during its life cycle. I know upstream already refused to take in consideration the possibility of on/off that warns by option. At least, using debug priority would move those warns to a different log file in default configuration, not too bad. Fwiw, I don't think either that an On/Off switch would be a good idea. Assuming we remove the old SysV generator at some point, we do need to warn users in advance, so they can prepare. If we downgrade those messages to debug, I fear users will never see them and take appropriate steps. Well, a skilled admin will simply add a filtering expression for rsyslog to send all those messages to /dev/null. A newbie shall have just some more good reasons to curse. I still think that using debug priority is a reasonable choice for both them. -- Francesco P. Lovergine
Bug#982353: contrib/testing64 crashes on Vbox 6.1 when updated to kernel 5.10 due to deprecated use of graphic card
On Thu, Feb 11, 2021 at 06:15:24PM +0100, Emmanuel Kasper wrote: if testing64 is working so far, including with the kernel of your choice, should we close this bug report ? Well, in any case I would add a doc note about the vbox graphic controller deprecation in 6.1 that could cause issues with current stable kernel. It couuld be not so evident for headless installations and solve a lots of headaches. -- Francesco P. Lovergine
Bug#982353: contrib/testing64 crashes on Vbox 6.1 when updated to kernel 5.10 due to deprecated use of graphic card
On Wed, Feb 10, 2021 at 03:21:49PM +0100, Emmanuel Kasper wrote: This looks good to me. Vagrant/Virtualbox on testing are using the mainline kernel guest additions, probably with a fake Virtualbox version. You can see on the guest that the additions come from mainline kernel: dpkg --search /lib/modules/5.10.0-3-amd64/kernel/drivers/virt/vboxguest/vboxguest.ko /lib/modules/5.10.0-3-amd64/kernel/fs/vboxsf/vboxsf.ko linux-image-5.10.0-3-amd64: /lib/modules/5.10.0-3-amd64/kernel/drivers/virt/vboxguest/vboxguest.ko linux-image-5.10.0-3-amd64: /lib/modules/5.10.0-3-amd64/kernel/fs/vboxsf/vboxsf.ko Ah right, I did not check the modinfo for those modules, so indeed they are taken from mainstream kernel and the version 6.0.0 information is totally fake. -- Francesco P. Lovergine
Bug#982353: contrib/testing64 crashes on Vbox 6.1 when updated to kernel 5.10 due to deprecated use of graphic card
On Wed, Feb 10, 2021 at 02:16:47PM +0100, Emmanuel Kasper wrote: Le 10/02/2021 à 10:22, Francesco P. Lovergine a écrit : On Wed, Feb 10, 2021 at 10:13:02AM +0100, Francesco P. Lovergine wrote: Well, it is automagically done by vagrant at provisioning time for the debian/testing64, maybe because the local Virtualbox installation has the extension installed? Sorry, I mean the guest additions ISO installed on the host box. Could it be that you have the vagrant plugin vagrant-vbguest installed ? If yes, try to remove it, recreate a Vagrant env using debian/testing64 (which now includes the guest extensions in the mainline kernel) and tell me if that works for you. If this works you will have a faster boot time, and the satisfaction of removing the depency to non-free package :) Uhm, removed and recreated the vm. Not better, it insist to add guest addons. Maybe, the whole ~/.vagrant.d dir needs to be wiped? Non-free seems pernicious :-D $ vagrant plugin uninstall vagrant-vbguest Uninstalling the 'vagrant-vbguest' plugin... Successfully uninstalled micromachine-3.0.0 Successfully uninstalled vagrant-vbguest-0.29.0 frankie@legolas:~/vagrant $ vagrant plugin list No plugins installed. frankie@legolas:~/vagrant $ vagrant destroy testing1 testing1: Are you sure you want to destroy the 'testing1' VM? [y/N] y ==> testing1: Forcing shutdown of VM... ==> testing1: Destroying VM and associated drives... frankie@legolas:~/vagrant $ vagrant up testings1 ^Cfrankie@legolas:~/vagrant $ vagrant up testing1 Bringing machine 'testing1' up with 'virtualbox' provider... ==> testing1: Importing base box 'debian/testing64'... ==> testing1: Matching MAC address for NAT networking... ==> testing1: Checking if box 'debian/testing64' version '20210207.1' is up to date... ==> testing1: Setting the name of the VM: testing1 ==> testing1: Clearing any previously set network interfaces... ==> testing1: Preparing network interfaces based on configuration... testing1: Adapter 1: nat testing1: Adapter 2: hostonly ==> testing1: Forwarding ports... testing1: 22 (guest) => (host) (adapter 1) ==> testing1: Running 'pre-boot' VM customizations... ==> testing1: Booting VM... ==> testing1: Waiting for machine to boot. This may take a few minutes... testing1: SSH address: 127.0.0.1: testing1: SSH username: vagrant testing1: SSH auth method: private key testing1: testing1: Vagrant insecure key detected. Vagrant will automatically replace testing1: this with a newly generated keypair for better security. testing1: testing1: Inserting generated public key within guest... testing1: Removing insecure key from the guest if it's present... testing1: Key inserted! Disconnecting and reconnecting using new SSH key... ==> testing1: Machine booted and ready! ==> testing1: Checking for guest additions in VM... testing1: The guest additions on this VM do not match the installed version of testing1: VirtualBox! In most cases this is fine, but in rare cases it can testing1: prevent things such as shared folders from working properly. If you see testing1: shared folder errors, please make sure the guest additions within the testing1: virtual machine match the version of VirtualBox you have installed on testing1: your host and reload your VM. testing1: testing1: Guest Additions Version: 6.0.0 r127566 testing1: VirtualBox Version: 6.1 ==> testing1: Setting hostname... ==> testing1: Configuring and enabling network interfaces... ==> testing1: Mounting shared folders... testing1: /vagrant => /home/frankie/vagrant ==> testing1: Machine 'testing1' has a post `vagrant up` message. This is a message ==> testing1: from the creator of the Vagrantfile, and not from Vagrant itself: ==> testing1: ==> testing1: Vanilla Debian box. See https://app.vagrantup.com/debian for help and bug reports BTW thanks for the hint about VGA/VMSVGA. If VMSVGA is now the default graphic card for Linux Guests VirtualBox we should consider making the Vagrant Boxes also use it. But that's actually a topic for https://github.com/EmmanuelKasper/import2vbox which is generating the VirtualBox config. At least in 6.1 series, the default card for Linux boxes is VMSVGA. For any other type of card, the GUI issues a warning. -- Francesco P. Lovergine
Bug#982353: contrib/testing64 crashes on Vbox 6.1 when updated to kernel 5.10 due to deprecated use of graphic card
On Wed, Feb 10, 2021 at 10:13:02AM +0100, Francesco P. Lovergine wrote: Well, it is automagically done by vagrant at provisioning time for the debian/testing64, maybe because the local Virtualbox installation has the extension installed? Sorry, I mean the guest additions ISO installed on the host box. -- Francesco P. Lovergine
Bug#982353: contrib/testing64 crashes on Vbox 6.1 when updated to kernel 5.10 due to deprecated use of graphic card
On Wed, Feb 10, 2021 at 10:00:47AM +0100, Emmanuel Kasper wrote:
config.vm.provider "virtualbox" do |v|
v.customize ["modifyvm", :id, "--graphicscontroller", "vmsvga"]
end
That could probably considered a vagrant issue. I found that it is a
non-issue with 4.x up to 5.9, but 5.10+ is not compatible with the
default choice. Not sure if the suggested graphics controller is
vmsvga only in 6.1 or depending
on the host graphic card...
It should be possible to change the OVF of the Vagrant Box or add this
to the default Vagrantfile.
Just to better understand your use case, why are you building the
virtualbox guest additions ? This should not be needed anymore since
kernel 5.6, see https://kernelnewbies.org/Linux_5.6#Support_for_VirtualBox_guest_shared_folders
or am I missing something ?
Well, it is automagically done by vagrant at provisioning time for the
debian/testing64, maybe because the local Virtualbox installation has the
extension installed?
This is now the (working) stanza used:
config.vm.define "testing" do |vm5|
vm5.vm.box = "debian/testing64"
vm5.vm.network "private_network", ip: "192.168.33.20"
vm5.vm.provider "virtualbox" do |vb5|
vb5.memory = "4096"
vb5.name = "testing"
vb5.cpus = 2
vb5.customize ["modifyvm", :id, "--graphicscontroller",
"vmsvga"]
end
end
--
Francesco P. Lovergine
Bug#982353: contrib/testing64 crashes on Vbox 6.1 when updated to kernel 5.10 due to deprecated use of graphic card
On Wed, Feb 10, 2021 at 09:37:53AM +0100, Francesco P. Lovergine wrote: Tried with a fresh update of debian/testing64 the result is not that different. It hangs after shutdown and restart. See also the screenshot taken from the GUI. The issue is again the same: the box is created with the VboxVGA instead of the suggested VMSVGA. Workaround: config.vm.provider "virtualbox" do |v| v.customize ["modifyvm", :id, "--graphicscontroller", "vmsvga"] end That could probably considered a vagrant issue. I found that it is a non-issue with 4.x up to 5.9, but 5.10+ is not compatible with the default choice. Not sure if the suggested graphics controller is vmsvga only in 6.1 or depending on the host graphic card... -- Francesco P. Lovergine
Bug#982353: contrib/testing64 crashes on Vbox 6.1 when updated to kernel 5.10 due to deprecated use of graphic card
On Tue, Feb 09, 2021 at 09:01:23PM +0100, Emmanuel Kasper wrote:
Hi Frankie
Thanks for you interest for the Vagrant Boxes.
Can you reproduce the issue with
https://app.vagrantup.com/debian/boxes/testing64 ?
contrib boxes are going the way of the doodo for bullseyes, as the
dkms kernel drivers needed for the guest extensions are now in the
mainline kernel
Emmanuel
Tried with a fresh update of debian/testing64 the result is not that
different. It hangs after shutdown and restart. See also the screenshot taken from the GUI.
The issue is again the same: the box is created with the VboxVGA instead of
the suggested VMSVGA.
[...]
VirtualBox Guest Additions: Building the modules for kernel 5.10.0-3-amd64.
update-initramfs: Generating /boot/initrd.img-5.10.0-3-amd64
VirtualBox Guest Additions: Running kernel modules will not be replaced until
the system is restarted
An error occurred during installation of VirtualBox Guest Additions 6.1.18.
Some functionality may not work as intended.
In most cases it is OK that the "Window System drivers" installation failed.
Unmounting Virtualbox Guest Additions ISO from: /mnt
Got different reports about installed GuestAdditions version:
Virtualbox on your host claims: 6.0.0
VBoxService inside the vm claims: 6.1.18
Going on, assuming VBoxService is correct...
Got different reports about installed GuestAdditions version:
Virtualbox on your host claims: 6.0.0
VBoxService inside the vm claims: 6.1.18
Going on, assuming VBoxService is correct...
Got different reports about installed GuestAdditions version:
Virtualbox on your host claims: 6.0.0
VBoxService inside the vm claims: 6.1.18
Going on, assuming VBoxService is correct...
Restarting VM to apply changes...
==> testing: Attempting graceful shutdown of VM...
==> testing: Booting VM...
==> testing: Waiting for machine to boot. This may take a few minutes...
==> testing: Checking for guest additions in VM...
Timed out while waiting for the machine to boot. This means that
Vagrant was unable to communicate with the guest machine within
the configured ("config.vm.boot_timeout" value) time period.
If you look above, you should be able to see the error(s) that
Vagrant had when attempting to connect to the machine. These errors
are usually good hints as to what may be wrong.
If you're using a custom box, make sure that networking is properly
working and you're able to connect to the machine. It is a common
problem that networking isn't setup properly in these boxes.
Verify that authentication configurations are also setup properly,
as well.
If the box appears to be booting properly, you may want to increase
the timeout ("config.vm.boot_timeout") value.
On 2/9/21 11:16 AM, Francesco P. Lovergine wrote:
Package: cloud.debian.org
Severity: normal
In order to replicate the issue, just up with a current image
(20200607.1). Runnig the VM causes a kernel panic, as in the
attached screenshot
Moving from VboxSVGA to VboxMSVGA solves the issue. That happens
only after upgrading to current bullseye 5.10 kernel, instead of the
historical 5.6.
Virtualbox in use is 6.1.18.
-- System Information:
Debian Release: 10.8
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.19.0-14-amd64 (SMP w/32 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8),
LANGUAGE=it_IT.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
--
You know an upstream is nice when they even accept m68k patches.
- John Paul Adrian Glaubitz, Debian OpenJDK maintainer
--
Francesco P. Lovergine
Bug#982353: contrib/testing64 crashes on Vbox 6.1 when updated to kernel 5.10 due to deprecated use of graphic card
Package: cloud.debian.org Severity: normal In order to replicate the issue, just up with a current image (20200607.1). Runnig the VM causes a kernel panic, as in the attached screenshot Moving from VboxSVGA to VboxMSVGA solves the issue. That happens only after upgrading to current bullseye 5.10 kernel, instead of the historical 5.6. Virtualbox in use is 6.1.18. -- System Information: Debian Release: 10.8 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-14-amd64 (SMP w/32 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), LANGUAGE=it_IT.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled -- Francesco P. Lovergine
Bug#979132: auto-apt-proxy takes a long time to run under schroot
On Sat, Feb 06, 2021 at 08:55:41PM +0100, Francesco P. Lovergine wrote:
Sorry for the long delay, your answer has been probably victim of my antispam
systems.
First of all, I managed to still reproduce the issue with my current
sid chroot in buster. Something changed, because now the delays
appears only
the first time after purge and reinstall of auto-apt-proxy apparently.
Then it can run again in the same schroot session without delay...
until the next schroot session and then again: it delays at the first
run only :-(
Here it is the run of the command you requested:
00:00:00 + [ 204 -gt 60 ]
00:00:00 + rm -f /tmp/.auto-apt-proxy-1000/cache
00:00:00 + [ -f /tmp/.auto-apt-proxy-1000/cache ]
00:00:00 + __detect__
00:00:00 + detect_DNS_SRV_record
00:00:00 + + shuf
00:00:00 hostname --domain
00:00:00 + awk /^[^#]/{print "http://; $1 ":" $4;found=1;exit}END{exit !found}
00:00:00 + /usr/lib/apt/apt-helper srv-lookup _apt_proxy._tcp.lovergine.com
00:00:00 + command -v ip
00:00:00 + ip route
00:00:00 + awk /default/ { print($3) }
00:00:00 + gateway=192.168.1.1
00:00:00 + getent hosts apt-proxy
00:00:00 + awk /[:blank:]/ { print($1) }
00:00:29 + explicit_proxy=
<- HERE!?
00:00:00 + detect_apt_cacher_ng 127.0.0.1
00:00:00 + local ip=127.0.0.1
00:00:00 + local proxy=http://127.0.0.1:3142
00:00:00 + hit -o Acquire::http::Proxy::127.0.0.1=DIRECT http://127.0.0.1:3142
00:00:00 + timeout 5 /usr/lib/apt/apt-helper -o Acquire::http::Proxy=DIRECT
download-file -o Acquire::http::Proxy::127.0.0.1=DIRECT http://127.0.0.1:3142
/tmp/tmp.hr4l6p
hnyH
00:00:00 + grep -q -i 406.*usage.information
00:00:00 + echo http://127.0.0.1:3142
00:00:00 + return 0
00:00:00 + return 0
00:00:00 + cat /tmp/.auto-apt-proxy-1000/cache
00:00:00 http://127.0.0.1:3142
00:00:00 + cleanup
00:00:00 + rm -f /tmp/tmp.hr4l6phnyH
real0m28.218s
user0m0.049s
sys 0m0.021s
(sid)frankie@aragorn:~
$
Another box, in this case a bullseye that host a buster chroot:
(buster)frankie@klecker:~
$ time auto-apt-proxy http://127.0.0.1:3142
real1m0.139s
user0m0.068s
sys 0m0.000s
The cache system is apt-cacher in that case. And the delay is present at each
invocation. Note that this box lives in another network (other DNS servers,
different domain, different interfaces and so on).
--
Francesco P. Lovergine
Bug#979132: auto-apt-proxy takes a long time to run under schroot
On Sun, Jan 03, 2021 at 11:56:37AM -0300, Antonio Terceiro wrote:
Control: tag -1 + moreinfo unreproducible
Hello Francesco, thanks for your bug report.
On Sun, Jan 03, 2021 at 11:37:41AM +0100, Francesco P. Lovergine wrote:
Package: auto-apt-proxy
Version: 13.1
Severity: normal
(sid)frankie@aragorn:~
$ time auto-apt-proxy
http://127.0.0.1:3142
real0m28.223s
user0m0.028s
sys 0m0.011s
and - not secondly - it takes the same time at every invocation, which is a non
sense. It should have a persistent
knowledge of the discovered proxy.
FWIW the version your are reporting this bug against does have a caching
mechanism, however I don't know yet why it is not working for you.
This is a chroot run under stable, but I don't think it depends on
the apt-cacher-ng version.
Note that out the chroot it works fast, instead:
frankie@aragorn:~
$ time auto-apt-proxy
http://127.0.0.1:3142
real0m0,023s
user0m0,016s
sys 0m0,011s
I can't reproduce this, I need more information.
8<8<8<-
$ time schroot -c unstable-amd64-sbuild -d /tmp auto-apt-proxy
hostname: Name or service not known
http://127.0.0.1:3142
real0m0,379s
user0m0,211s
sys 0m0,084s
8<8<8<-
(note that "hostname: Name or service not known" is a separate issue which I am
handling here).
Can you post the output of
time sh -x /usr/bin/auto-apt-proxy 2>&1 | ts -i
from your chroot? (`ts` comes from the moreutils package).
Sorry for the long delay, your answer has been probably victim of my antispam
systems.
First of all, I managed to still reproduce the issue with my current sid
chroot in buster. Something changed, because now the delays appears only
the first time after purge and reinstall of auto-apt-proxy apparently.
Then it can run again in the same schroot session without delay... until the
next schroot session and then again: it delays at the first run only :-(
Here it is the run of the command you requested:
00:00:00 + [ 204 -gt 60 ]
00:00:00 + rm -f /tmp/.auto-apt-proxy-1000/cache
00:00:00 + [ -f /tmp/.auto-apt-proxy-1000/cache ]
00:00:00 + __detect__
00:00:00 + detect_DNS_SRV_record
00:00:00 + + shuf
00:00:00 hostname --domain
00:00:00 + awk /^[^#]/{print "http://; $1 ":" $4;found=1;exit}END{exit !found}
00:00:00 + /usr/lib/apt/apt-helper srv-lookup _apt_proxy._tcp.lovergine.com
00:00:00 + command -v ip
00:00:00 + ip route
00:00:00 + awk /default/ { print($3) }
00:00:00 + gateway=192.168.1.1
00:00:00 + getent hosts apt-proxy
00:00:00 + awk /[:blank:]/ { print($1) }
00:00:29 + explicit_proxy=
<- HERE!?
00:00:00 + detect_apt_cacher_ng 127.0.0.1
00:00:00 + local ip=127.0.0.1
00:00:00 + local proxy=http://127.0.0.1:3142
00:00:00 + hit -o Acquire::http::Proxy::127.0.0.1=DIRECT http://127.0.0.1:3142
00:00:00 + timeout 5 /usr/lib/apt/apt-helper -o Acquire::http::Proxy=DIRECT
download-file -o Acquire::http::Proxy::127.0.0.1=DIRECT http://127.0.0.1:3142
/tmp/tmp.hr4l6p
hnyH
00:00:00 + grep -q -i 406.*usage.information
00:00:00 + echo http://127.0.0.1:3142
00:00:00 + return 0
00:00:00 + return 0
00:00:00 + cat /tmp/.auto-apt-proxy-1000/cache
00:00:00 http://127.0.0.1:3142
00:00:00 + cleanup
00:00:00 + rm -f /tmp/tmp.hr4l6phnyH
real0m28.218s
user0m0.049s
sys 0m0.021s
(sid)frankie@aragorn:~
$
--
Francesco P. Lovergine
Bug#981626: /var/yp/nicknames missing
On Tue, Feb 02, 2021 at 01:21:24PM +0100, Thomas Lange wrote: On Tue, 2 Feb 2021 12:35:29 +0100, "Francesco P. Lovergine" said: > /usr/share/yp/templates/var_yp_nicknames Hi Francesco, Ah, I didn't saw this. Yep, maybe adding a note about templates available under /usr/share/yp/templates could be useful for most people, just in case. > In postinst ucf should manage the update of that file. Did you upgrade or > install from scratch? If upgraded, did you upgrade from nis 3.x or had a > previous version of yp-tools installed (that was available at least in the > last pair of years as a separate package). All that should be evident > from dpkg logs. That's just to understand where the problem could be. I've upgraded a bullseye system which was runnning nis 3.x as a nis client, and I got 4.x. This is a nis client, but when upgrading the packages it also installed the ypserv package. I had to manually fix some nis things. ypbind was not started automatically. Eh, at upgrade time there is no way to know in advance if your box is a client, a server or both. You can eventually remove the `nis` package and `ypserv` after the upgrade. Note that even /etc/default/nis is now optional. If you had not 'true' for NISCLIENT in /etc/default/nis then the ypbind service is not started automagically - as expected - and you need to enable+start ypbind.service via systemctl, after checking for domainname and yp.conf setup. In bookworm I'll introduce a nis-doc package and drop definitively the old nis package which is perfectly unuseful, but for the howto doc. This is completely uncorrelated with the nicknames drop anyway. This is not problem for me, because I usually do a complete reinstall and no dist-upgrade. I'm not sure if I wil lbe able to check again if an upgrade break in my environment. Feel free to close the bug. Well, I checked multiple times upgrades of nis for stable, and never saw that type of behavior, I guess you stopped at ucf prompt to check the situation and never continued after: that could be one (the only?) reason for the missing file. I'll check again to verify that no latest change altered the upgrade path somehow before closing this bug. Thanks. -- Francesco P. Lovergine
Bug#981626: /var/yp/nicknames missing
On Tue, Feb 02, 2021 at 11:15:47AM +0100, la...@debian.org wrote: Package: yp-tools Version: 4.2.3-3 With the new 4.x version of NIS this happens $ ypcat passwd nickname file /var/yp/nicknames does not exist. No such map passwd. Reason: No such map in server's domain The old 3.x nis tools provided the file /var/yp/nicknames, so one can call ypcat passwd instead of ypcat passwd.byname ypcat (4.x) still looks for /var/yp/nicknames, but it's not provided by the yp-tools package. That is a conf file managed by ucf and the distributed copy is here: /usr/share/yp/templates/var_yp_nicknames In postinst ucf should manage the update of that file. Did you upgrade or install from scratch? If upgraded, did you upgrade from nis 3.x or had a previous version of yp-tools installed (that was available at least in the last pair of years as a separate package). All that should be evident from dpkg logs. That's just to understand where the problem could be. Indeed, a fresh install regularly install the required file (sorry for the it locale): vagrant@testing1:~$ sudo apt install yp-tools Lettura elenco dei pacchetti... Fatto Generazione albero delle dipendenze Lettura informazioni sullo stato... Fatto I seguenti pacchetti sono stati installati automaticamente e non sono più richiesti: libisl22 libjson-c4 libmpdec2 libperl5.30 libpython3.8-minimal libpython3.8-stdlib linux-image-5.6.0-2-amd64 python3.8 python3.8-minimal Usare "sudo apt autoremove" per rimuoverli. I seguenti pacchetti aggiuntivi saranno inoltre installati: nscd rpcbind ypbind-mt I seguenti pacchetti NUOVI saranno installati: nscd rpcbind yp-tools ypbind-mt 0 aggiornati, 4 installati, 0 da rimuovere e 3 non aggiornati. È necessario scaricare 435 kB di archivi. Dopo quest'operazione, verranno occupati 969 kB di spazio su disco. Continuare? [S/n] Scaricamento di:1 http://deb.debian.org/debian bullseye/main amd64 rpcbind amd64 1.2.5-9 [51,4 kB] Scaricamento di:2 http://deb.debian.org/debian bullseye/main amd64 nscd amd64 2.31-9 [289 kB] Scaricamento di:3 http://deb.debian.org/debian bullseye/main amd64 ypbind-mt amd64 2.7.2-2 [39,9 kB] Scaricamento di:4 http://deb.debian.org/debian bullseye/main amd64 yp-tools amd64 4.2.3-3 [55,1 kB] Recuperati 435 kB in 1s (301 kB/s) Selezionato il pacchetto rpcbind non precedentemente selezionato. (Lettura del database... 98813 file e directory attualmente installati.) Preparativi per estrarre .../rpcbind_1.2.5-9_amd64.deb... Estrazione di rpcbind (1.2.5-9)... Selezionato il pacchetto nscd non precedentemente selezionato. Preparativi per estrarre .../archives/nscd_2.31-9_amd64.deb... Estrazione di nscd (2.31-9)... Selezionato il pacchetto ypbind-mt non precedentemente selezionato. Preparativi per estrarre .../ypbind-mt_2.7.2-2_amd64.deb... Estrazione di ypbind-mt (2.7.2-2)... Selezionato il pacchetto yp-tools non precedentemente selezionato. Preparativi per estrarre .../yp-tools_4.2.3-3_amd64.deb... Estrazione di yp-tools (4.2.3-3)... Configurazione di rpcbind (1.2.5-9)... Created symlink /etc/systemd/system/multi-user.target.wants/rpcbind.service → /lib/systemd/system/rpcbind.service. Created symlink /etc/systemd/system/sockets.target.wants/rpcbind.socket → /lib/systemd/system/rpcbind.socket. Configurazione di nscd (2.31-9)... Created symlink /etc/systemd/system/multi-user.target.wants/nscd.service → /lib/systemd/system/nscd.service. Configurazione di ypbind-mt (2.7.2-2)... Configurazione di yp-tools (4.2.3-3)... Creating config file /var/yp/nicknames with new version Elaborazione dei trigger per man-db (2.9.3-2)... vagrant@testing1:~$ ls /var/yp/ binding nicknames -- Francesco P. Lovergine
Bug#981407: sysv-generator is really annoying with an eccessive verbosity
On Mon, Feb 01, 2021 at 08:04:42PM +0100, Michael Biebl wrote: For package maintainers we already have lintian [1] Yep, much better. Unfortunately, we can't differentiate between SysV init scripts provided by Debian packages vs local ones (and no, running dpkg -S from sysv-generator is not an option). So personally, I consider the warnings from the sysv-generator more relevant actually for locally written SysV init scripts and the ones provided by 3rd party packages. Eventually, we are going to remove SysV support in systemd. This won't happen in bullseye and maybe not bookworm, but we won't keep support for SysV init scripts forever. So people should be made aware of this, and ideally, they have more then one release cycle to prepare for this. So I'm undecided whether to remove (or downgrade to debug) this warning or not. What do you suggest? For a regular bullseye installation, I wouldn't actually expect that much noise as you see. Well, the truly annoying thing is that it warns even for init scripts disabled, but never removed (sometimes on purpose, sometimes due to package errors). I discovered a few of them still around since years, and reduced a bit the noisei by purging. For sure this system is up since 28th of Jan and dmesg shows only messages after 30th of Jan currently. So generally, at every restart of services the syslog is populated with those warnings in good quantity. Any system upgraded several times and/or used for development will present tons of this warnings during its life cycle. I know upstream already refused to take in consideration the possibility of on/off that warns by option. At least, using debug priority would move those warns to a different log file in default configuration, not too bad. -- Francesco P. Lovergine
Bug#981437: Acknowledgement (Please, provide a systemd unit file also)
Also, note that bitblee could (should?) be one of those service which can be templated and activated per user, instead of supporting a single instance. That should be at least reported in documentation along with sample templates. -cheers -- Francesco P. Lovergine
Bug#908293: accountsservice: High CPU usage after system startup
On Tue, Oct 30, 2018 at 10:46:22PM -0400, Scott Bailey wrote: Package: accountsservice Version: 0.6.45-1 Followup-For: Bug #908293 Dear Maintainer, I noticed in passing that the accounts-daemon process is consuming 99%+ of one of my processors, on a long-term ongoing basis, and neither restarts (via systemctl) nor reboots seem to be curbing its enthusiasm. I'm responding to the original bug report, although that was for an earlier version, as the symptoms seem to largely mirror mine. Thanks, -Scott Apparently, this also triggering autodir daemon that I use on our servers extensively since years. Recently, I had to install x2go/vnc and mate on several boxes to allow people to use a DE during covid‐19 lockdown here, and autodir randomly starts to log tons of messages such: gen 29 09:21:31 Y autodir[42811]: [autohome] warning: no user found with name XX.tiff gen 29 09:21:31 Y autodir[42811]: [autohome] alert: module autohome failed on XX.tiff gen 29 09:21:31 Y autodir[42811]: [autohome] warning: no user found with name XX.wbmp gen 29 09:21:31 Y autodir[42811]: [autohome] alert: module autohome failed on XX.wbmp gen 29 09:21:31 Y autodir[42811]: [autohome] warning: no user found with name XX.webp gen 29 09:21:31 Y autodir[42811]: [autohome] alert: module autohome failed on XX.webp gen 29 09:21:31 Y autodir[42811]: [autohome] warning: no user found with name XX.xbm gen 29 09:21:31 Y autodir[42811]: [autohome] alert: module autohome failed on XX.xbm gen 29 09:21:31 Y autodir[42811]: [autohome] warning: no user found with name XX.xpm gen 29 09:21:31 Y autodir[42811]: [autohome] alert: module autohome failed on XX.xpm It seems directly due to the new services installed. X is generally an already logged user. Of course that stops after restarting the autodir daemon, but high cpu times appear for accounts-daemon, systemd-logd (well, of course) and caja. I could probably mitigate the issue in autodir by stopping the continuous reporting, but there's something strange in the caja/accounts-daemon or both, not sure. The whole thing is quite annoying... -- Francesco P. Lovergine
Bug#980999: nis.debian.howto isn't installed by new package nis
tags 980999 + pending quit On Mon, Jan 25, 2021 at 11:42:53AM +0100, Elimar Riesebieter wrote: Package: nis Version: 4.0 Severity: normal Dear maintainer, many, many thanks to bring nis to the 21st century ;-) There is a small but important thing: nis.debian.howto isn't installed by nis package: $ apt-file search nis.debian.howto nis: /usr/share/doc/nis/nis.debian.howto.gz Well, who needs documents nowdays, in the 21st century? :-D -- Francesco P. Lovergine
Bug#886331: nis fails to stop at removal
tags 886331 + moreinfo unreproducible quit On Thu, Jan 04, 2018 at 03:40:31PM +0100, Gürkan Myczko wrote: Package: nis Version: 3.17.1-1+b1 Severity: normal In /var/lib/dpkg/info/nis.prerm there's a try to stop ypbind daemon once with invoke-rc.d with fallback to system 5 stop, but both fail. Thank you, Gürkan Hi, I recently adopted the `nis` package and I'm housekeeping old bugs around. Are you still there to discuss this report? I'm missing the point of it. Was the ypbind stalled when you started removing? Thanks in advance for your patience... -- Francesco P. Lovergine
Bug#890994: nis: ypbind started when the computer start without network
severity 890994 wishlist tags 890994 + wontfix quit As explained by Mark, NIS is not tought for supporting intermittently connected clients. Also, in the next releases nis services will use systemd units and that would be used to switch off ypbind if the client is not connected to a netẇork. For that purpose, it will be enough: systemctl enable systemd-networkd.service systemd-networkd-wait-online.service And then add After=systemd-networkd-wait-online.service Wants=systemd-networkd-wait-online.service to the (future) ypbind.service. That should work even with DHCP. But it solves only partially the issue and not in general. What if you connect to another network? What if you are multi-homed? What if the NIS client is a laptop hosted in multiple variable networks, with more than one domain? NIS is simply not tought for this use cases, it is an old beast of the 80s. The simplest thing to do is using ad hoc scripts to on/off the service on the basis of local needs, it is simply not possible supporting all possible settings. On Wed, Feb 21, 2018 at 01:04:33PM +0100, adrien moulin wrote: Package: nis Version: 3.17.1-1+b1 Severity: normal Dear Maintainer, On stretch when i start without network, the computer is very slow to launch the graphical interface and when i try to login on tty console there are important latency. After research the origin of the problem, i found that /etc/nsswitch.conf tried to bind nis because ypbind is launch but without network it can't do it. It seems there are no timeout on this. I usually use laptop with nis client, on Jessie the nis.service do not start when the network cable was out but on Stretch it start with or without network cable. (on the laptop there are a new installation of debian not a distupgrade) The solution i have found is not very nice, i had in /etc/init.d/nis when the process is backgrouned a killall ypbind. I hope there are an other solution with systemd but i can't find out for now. -- Francesco P. Lovergine
Bug#213733: Bug#118023: nis: upgrade breaks postinst and service restart
...failed (backgrounded). . = If 'ypbind' is started manually, # /usr/sbin/ypbind -f /etc/defaultdomain The follwoing error is reported.. io:~# /usr/sbin/ypbind -f /etc/defaultdomain No NIS server and no -broadcast option specified. Add a NIS server to the /etc/defaultdomain configuration file, or start ypbind with the -broadcast option. = $ sudo kill $(cat /var/run/ypbind.pid) # the restart left a process that will retry indefinitely $ ps -ef | grep '[y]p' root 16875 1 0 12:45 ?00:00:00 /usr/sbin/ypserv root 16878 1 0 12:45 ?00:00:00 /usr/sbin/rpc.yppasswdd -D /etc -e chsh -e chfn root 16881 1 0 12:45 ?00:00:00 /usr/sbin/rpc.ypxfrd $ grep -v '^\(#.*\|\)$' /etc/yp.conf# don't show comment or empty lines $ sudo /usr/sbin/ypbind -f /etc/yp.conf No NIS server and no -broadcast option specified. Add a NIS server to the /etc/yp.conf configuration file, or start ypbind with the -broadcast option. = BUT If this option is put in, then ypbind starts properly and then (surprisingly) NIS works again as expected. Restarting manually with the ‘-broadcast’ option doesn't help: = $ ps -ef | grep '[y]p' root 16875 1 0 12:45 ?00:00:00 /usr/sbin/ypserv root 16878 1 0 12:45 ?00:00:00 /usr/sbin/rpc.yppasswdd -D /etc -e chsh -e chfn root 16881 1 0 12:45 ?00:00:00 /usr/sbin/rpc.ypxfrd $ sudo /usr/sbin/ypbind -broadcast $ ps -ef | grep '[y]p' root 16875 1 0 12:45 ?00:00:00 /usr/sbin/ypserv root 16878 1 0 12:45 ?00:00:00 /usr/sbin/rpc.yppasswdd -D /etc -e chsh -e chfn root 16881 1 0 12:45 ?00:00:00 /usr/sbin/rpc.ypxfrd root 17268 1 0 12:55 ?00:00:00 /usr/sbin/ypbind -broadcast $ ypcat group No such map group.byname. Reason: Can't bind to server which serves this domain = Since the automated service restart interface breaks, this also breaks during postinst, so I'm sending this comment to Bug#118023 also. -- \ “I must say that I find television very educational. The minute | `\ somebody turns it on, I go to the library and read a book.” | _o__)—Groucho Marx | Ben Finney -- Francesco P. Lovergine
Bug#979371: nis should depend on libnss-nis
tags 979371 + pending severity 979371 minor quit libnss-nis should be a Recommends for current nis or prospectively for ypbind-mt. On Tue, Jan 05, 2021 at 10:05:35PM +0100, Thomas Lange wrote: Package: nis Version: 3.17.1-9+b1 In bullseye the nis function of libc was moved to a new package, called libnss-nis. I think the nis package should depend or recommend libnss-nis. -- regards Thomas -- Francesco P. Lovergine
Bug#912752: Status of pyfuse3 and s3ql
Interestingly enough, there is no ITP open for pyfuse3, I'll see if I would have time to deal with both them. On Tue, Jan 05, 2021 at 09:57:35AM +, Nikolaus Rath wrote: Hi Francesco, I have no idea about the status of pyfuse3 Debian packages. All I know is this: I do not have much time for Debian packaging anymore. I would rather have someone else package S3QL, but as long as no one adopts it, I will continue to do releases as long as the effort is small. Unfortunately, I definitely do not have the capacity to also package any dependencies. Best, -Nikolaus -- GPG Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.« On Mon, 4 Jan 2021, at 16:44, Francesco P. Lovergine wrote: Hi Nikolaus, I see you opened a RFA for s3ql whose update to current version is blocked by the missing of pyfuse3 in main. That lib is seating on salsa since a pair of years. What is the current status of the whole stuff? -cheers and thanks -- Francesco P. Lovergine -- Francesco P. Lovergine
Bug#912752: Status of pyfuse3 and s3ql
Hi Nikolaus, I see you opened a RFA for s3ql whose update to current version is blocked by the missing of pyfuse3 in main. That lib is seating on salsa since a pair of years. What is the current status of the whole stuff? -cheers and thanks -- Francesco P. Lovergine
Bug#979214: proftpd-core not installable in sid
tags 979214 + pending quit On Mon, Jan 04, 2021 at 11:14:35AM +0100, Thorsten G. wrote: Package: proftpd-core Version: 1.3.7a+dfsg-8 Severity: important Dear Maintainer, it seems to me that the package is uninstallable. During setup following messages appears: Setting up proftpd-core (1.3.7a+dfsg-8) ... cp: cannot stat '/usr/share/proftpd/templates/mod_snmp.conf': No such fi le or directory dpkg: error processing package proftpd-core (--configure): installed proftpd-core package post-installation script subprocess retu rned error exit status 1 Processing triggers for man-db (2.9.3-2) ... Processing triggers for doc-base (0.11) ... Processing 1 added doc-base file... Errors were encountered while processing: proftpd-core E: Sub-process /usr/bin/dpkg returned an error code (1) I've purged all former installed proftpd packages and try to install only proftpd-core but that doesn't work -- Francesco P. Lovergine
Bug#613037: housekeeping
tags 613037 + wishlist retitile 613037 imapfilter should provide templates for dynamic connections quit First of all, imapfilter should be considered as a per-user service. So installing a ppp hook at system level is quite pointless, because that should solve only a very specific use case (personal workstation with dial out connections). The best thing to do is probably providing an hook example in documentation. Nowdays most of the box use wifi with network manager for mobile connections, so the best thing to do for most of the users is adding a personal unit service for systemd probably, because the good old days of pon/poff are gone. Again, even in this case it would be nice adding a systemd unit example for personal use, because that would not be the right thing to use in all use cases. -cheers -- Francesco P. Lovergine
Bug#979132: auto-apt-proxy takes a long time to run under schroot
Package: auto-apt-proxy Version: 13.1 Severity: normal (sid)frankie@aragorn:~ $ time auto-apt-proxy http://127.0.0.1:3142 real0m28.223s user0m0.028s sys 0m0.011s and - not secondly - it takes the same time at every invocation, which is a non sense. It should have a persistent knowledge of the discovered proxy. This is a chroot run under stable, but I don't think it depends on the apt-cacher-ng version. Note that out the chroot it works fast, instead: frankie@aragorn:~ $ time auto-apt-proxy http://127.0.0.1:3142 real0m0,023s user0m0,016s sys 0m0,011s -cheers Francesco -- System Information: Debian Release: 10.7 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.9.0-0.bpo.2-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), LANGUAGE=it_IT.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages auto-apt-proxy depends on: ii apt 1.8.2.2 Versions of packages auto-apt-proxy recommends: ii iproute2 4.20.0-2 auto-apt-proxy suggests no packages. -- no debconf information
Bug#213733: nis: Testing upgrade breaks NIS
Hi, I'm currently housekeeping long standing bug reports about NIS, aѕ I adopted recently the package. In this report, the behavior of ypbind appears as a feature, not a bug. I mean its behavior is expected. Ypbind needs to know a list of NIS servers (in /etc/yp.conf) or issues a broadcast (iif run with -broadcast or broacast is added to /etc/yp.conf) and wait for an answerṡ. Even in case of a NIS server, ypbind expects an IP address (possibly 127.0.0.1) in /etc/yp.conf. So I don't see in this report On Thu, Oct 02, 2003 at 08:36:56PM +0930, Paul Schulz wrote: Package: nis Version: 3.9-6.3 Severity: normal Upgrade NIS in testing distribution and NIS fails to restart. The usual messages is reported. Starting NIS services: ypbind [binding to YP server .. backgrounded] NIS can be stopped and restarted several times with the same result. (It was running previously without a problem.) If 'ypbind' is started manually, # /usr/sbin/ypbind -f /etc/defaultdomain Note that the right cmd is /usr/sbin/ypbind -f /etc/yp.conf, the /etc/defaultdomain is not intended as a configuration file. The follwoing error is reported.. io:~# /usr/sbin/ypbind -f /etc/defaultdomain No NIS server and no -broadcast option specified. Add a NIS server to the /etc/defaultdomain configuration file, or start ypbind with the -broadcast option. BUT If this option is put in, then ypbind starts properly and then (surprisingly) NIS works again as expected. This works only if at least one server is configured for broadcasting. Which is not even the case since the buster release... I don't remember about the woody days, but a possibility is that it did revert to broadcast per default in case of a missing list of servers, and that changed in sarge. For sure upstream applied a patch for -local-only around that time, which could have changed the behavior. For sure, nowdays and in the future broadcast is an explicit choice of the admin, there is not a default for that and the admin must specify an address for a working server or even -local-only for loopback. -- Francesco P. Lovergine
Bug#979034: RM: manpages-it -- ROM; package source outdated
Package: ftp.debian.org Severity: normal On the basis of #979027 and the ongoing work to merge -it to l10n it is time to let this package go. -cheers -- Francesco P. Lovergine
Bug#978747: RM: proftpd-mod-dnsbl/0.1.5-5+b1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: rm Please remove proftpd-mod-dnsbl in testing/unstable, it prevents migration of new proftpd-dfsg (1.3.7a+dfsg-5) which now includes that module (and fix a serious bug) and has usual provides/replaces/conflicts in place. Thanks. -- System Information: Debian Release: 10.7 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.9.0-0.bpo.2-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), LANGUAGE=it_IT.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#978706: ITP: ypserv -- Server daemon for working with Network Information System (NIS)
Package: wnpp Severity: wishlist Owner: "Francesco P. Lovergine" Package: wnpp Severity: wishlist Owner: "Francesco P. Lovergine" * Package name: ypserv Version : 4.1 Upstream Author : Thorsten Kukuk * URL : http://www.linux-nis.org/ * License : GPL, LGPL, BSD Programming Lang: C Description : Server daemon for working with Network Information System (NIS) This package provides the multi-threading version of ypserv and other tools, required to implement a NIS server for shared accounts and network names. NIS, originally known as Yellow Pages (YP), is mostly used to let several machines in a network share the same account information, such as the password file. It is an old, but simple system to share information, which should be used only in relatively trusted networks, due to its intrinsic limitations for security. Note: I'm re-organizing and modernizing the old `nis` all-in-one package, following the three distinct upstream source projects. The yp-tools is already present in the main archive since a couple of years.
Bug#978705: ITP: ypbind -- Client daemon for working with Network Information System (NIS)
Package: wnpp Severity: wishlist Owner: "Francesco P. Lovergine" * Package name: ypbind Version : 2.7.2 Upstream Author : Thorsten Kukuk * URL : http://www.linux-nis.org/ * License : GPL, LGPL, BSD Programming Lang: C Description : Client daemon for working with Network Information System (NIS) This package provides the multi-threading version of ypbind, required to implement a NIS client service for shared accounts and network names. NIS, originally known as Yellow Pages (YP), is mostly used to let several machines in a network share the same account information, such as the password file. It is an old, but simple system to share information, which should be used only in relatively trusted networks, due to its intrinsic limitations for security. Note: I'm re-organizing and modernizing the old `nis` all-in-one package, following the three distinct upstream source projects. The yp-tools is already present in the main archive since a couple of years. -- Francesco P. Lovergine
Bug#978538: O: rox -- simple graphical file manager for X11
Package: wnpp Severity: normal I intend to orphan the rox package. I do not use it anymore. The package description is: ROX-Filer is a simple and easy to use graphical file manager for X11 based on the GTK2 library. It uses a uniform drag-and-drop approach for every operation. . It is also the core component of the ROX Desktop Environment. . Invoking rox opens each directory or file listed, or the current working directory if no arguments are given. A few basic information. - Upstream development seems stalled in the last 2-3 years. There are some forks here and there on github with patches. - The rox-filer is the main component of Rox Desktop which is not distributed in Debian, so it could nice adding more components and a whole package set for the environment. - Rox-filer is still in use in Puppy Linux AFAIK, which could be a nice source of ideas and information.
Bug#978507: apt inconsistency in reporting status
Package: apt Version: 2.1.15 Severity: minor If I understand correctly the apt cmd should report kept back package, as well. $ sudo apt upgrade Reading package lists... Done Building dependency tree Reading state information... Done Calculating upgrade... Done 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. $ sudo apt-get upgrade Reading package lists... Done Building dependency tree Reading state information... Done Calculating upgrade... Done The following packages have been kept back: mime-support 0 upgraded, 0 newly installed, 0 to remove and 1 not upgraded. $ sudo apt list --upgradable Listing... Done mime-support/unstable 3.66 all [upgradable from: 3.64] N: There is 1 additional version. Please use the '-a' switch to see it $ sudo apt list --upgradable -a Listing... Done mime-support/unstable 3.66 all [upgradable from: 3.64] mime-support/now 3.64 all [installed,upgradable to: 3.66] -- Francesco P. Lovergine
Bug#978505: mime-support: Missing dependency on mailcap (virtual)
Package: mime-support Version: 3.66 Severity: normal Dear Maintainer, mime-support cannot be installed/upgraded in sid currently. $ sudo apt-get upgrade Reading package lists... Done Building dependency tree Reading state information... Done Calculating upgrade... Done The following packages have been kept back: mime-support 0 upgraded, 0 newly installed, 0 to remove and 1 not upgraded. $ sudo apt-get install mime-support Reading package lists... Done Building dependency tree Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: mime-support : Depends: mailcap but it is not installable E: Unable to correct problems, you have held broken packages. $ sudo apt-get install mailcap Reading package lists... Done Building dependency tree Reading state information... Done Package mailcap is not available, but is referred to by another package. This may mean that the package is missing, has been obsoleted, or is only available from another source E: Package 'mailcap' has no installation candidate (sid)frankie@aragorn:~ $
Bug#978340: proftpd-mod-dnsbl: FTBFS: Cannot compile mod_dnsbl using prxs
Oh well, proftpd-mod-dnsbl is now obsoleted by proftpd-core who also Provides it in sid, and the source package should be removed in testing/sid to allow migration of current proftpd. I have a lapsus about that, should I ask an explicit remove to d-release? On Sat, Dec 26, 2020 at 11:08:09PM +0100, Lucas Nussbaum wrote: Source: proftpd-mod-dnsbl Version: 0.1.5-5 Severity: serious Justification: FTBFS on amd64 Tags: bullseye sid ftbfs Usertags: ftbfs-20201226 ftbfs-bullseye Hi, During a rebuild of all packages in sid, your package failed to build on amd64. Relevant part (hopefully): make[1]: Entering directory '/<>' DESTDIR=/<>/debian/proftpd-mod-dnsbl prxs -c mod_dnsbl.c Cannot compile mod_dnsbl using prxs; use existing ./configure script instead: ./configure make make install make[1]: *** [debian/rules:15: override_dh_auto_build] Error 1 The full build log is available from: http://qa-logs.debian.net/2020/12/26/proftpd-mod-dnsbl_0.1.5-5_unstable.log A list of current common problems and possible solutions is available at http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute! If you reassign this bug to another package, please marking it as 'affects'-ing this package. See https://www.debian.org/Bugs/server-control#affects If you fail to reproduce this, please provide a build log and diff it with me so that we can identify if something relevant changed in the meantime. About the archive rebuild: The rebuild was done on EC2 VM instances from Amazon Web Services, using a clean, minimal and up-to-date chroot. Every failed build was retried once to eliminate random failures. ___ Pkg-proftpd-maintainers mailing list pkg-proftpd-maintain...@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-proftpd-maintainers -- Francesco P. Lovergine
Bug#900358: adopting NIS stuff
retitle 900358 ITA: nis -- clients and daemons for the Network Information Service (NIS) owner 900358 ! thanks I'm still using NIS in some use cases, so I'm interested in adopting it. I see that new packages are available with GPL−2 licenses and the whole package requires changes to split the three sources originally merged together and re-organize for a modern packaging style. Eventually I'm also open to team maint, if anyone would be interested. -- Francesco P. Lovergine
Bug#977853: proftpd-core: Fails to set up
severity 977853 serious tags 977853 confirmed quit Sigh, inadvertently I pasted a sftp spurious line in postinst just before the last upload. On Mon, Dec 21, 2020 at 11:08:29PM +0100, Hilmar Preusse wrote: Setting up proftpd-core (1.3.7a+dfsg-4) ... usage: sftp [-46AaCfNpqrv] [-B buffer_size] [-b batchfile] [-c cipher] [-D sftp_server_path] [-F ssh_config] [-i identity_file] [-J destination] [-l limit] [-o ssh_option] [-P port] [-R num_requests] [-S program] [-s subsystem | sftp_server] destination dpkg: error processing package proftpd-core (--configure): installed proftpd-core package post-installation script subprocess returned error exit status 1 Setting up fonts-lato (2.0-2.1) ... dpkg: dependency problems prevent configuration of proftpd-dev: proftpd-dev depends on proftpd-core (= 1.3.7a+dfsg-4); however: Package proftpd-core is not configured yet. -- Francesco P. Lovergine
Bug#637076: AllowOverwrite On doesn't work with UserOwner and GroupOwner directives
tags 637076 + upstream confirmed quit This is seems still pending with 1.3.7a. With a very simple global configuration: /etc/proftpd/conf.d/groupowner.conf: AllowOverwrite on GroupOwner nogroup UserOwner nobody vagrant@debian:~$ lftp -u vagrant localhost Password: lftp vagrant@localhost:~> cd /tmp/tmp cd ok, cwd=/tmp/tmp lftp vagrant@localhost:/tmp/tmp> ls -rw-r--r-- 1 nobody nogroup 2259 Dec 21 15:34 local.yml lftp vagrant@localhost:/tmp/tmp> put local.yml put: Access failed: 550 local.yml: Permission denied The intended behavior should be allowing the rewrite of the file, instead. On Mon, Aug 08, 2011 at 01:51:01PM +0300, Андрей Василишин wrote: Package: proftpd-basic Version: 1.3.4rc2 Directive "AllowOverwrite On" doesn't work in such config: # cat /etc/proftpd/proftpd.conf Include /etc/proftpd/modules.conf AllowOverwrite on UseIPv6 off UseReverseDNS off Port 0 SystemLog /var/log/proftpd/proftpd.log LangPath /usr/share/locale LangDefault en_US # Allow root to use chown(2) CapabilitiesEngine off #CapabilitiesSet -CAP_CHOWN ServerName "x ftp server" Port 21 DefaultServer on ServerAdmin x@x IdentLookups off MaxClients 30 "Sorry, max %m users -- try again later" TimeoutLogin 60 TimeoutIdle 300 TimeoutNoTransfer 300 TimeoutStalled 1800 DefaultTransferMode binary DeferWelcome off Umask 022 DefaultRoot ~ !andron AllowStoreRestart on RequireValidShell off User www-data Group www-data UserOwner www-data GroupOwner www-data AllowOverwrite on AllowAll But work if I comment UserOwner and GroupOwner directives it's works: # cat /etc/proftpd/proftpd.conf Include /etc/proftpd/modules.conf AllowOverwrite on UseIPv6 off UseReverseDNS off Port 0 SystemLog /var/log/proftpd/proftpd.log LangPath /usr/share/locale LangDefault en_US # Allow root to use chown(2) CapabilitiesEngine off #CapabilitiesSet -CAP_CHOWN ServerName "x ftp server" Port 21 DefaultServer on ServerAdmin x@x IdentLookups off MaxClients 30 "Sorry, max %m users -- try again later" TimeoutLogin 60 TimeoutIdle 300 TimeoutNoTransfer 300 TimeoutStalled 1800 DefaultTransferMode binary DeferWelcome off Umask 022 DefaultRoot ~ !andron AllowStoreRestart on RequireValidShell off User www-data Group www-data #UserOwner www-data #GroupOwner www-data AllowOverwrite on AllowAll -- WBR, Andrey Vasilishin CDIG1-UANIC, CDIG1-RIPE -- Francesco P. Lovergine
Bug#977209: marked as done (transition: proftpd-dfsg)
On Sun, Dec 13, 2020 at 11:24:02PM +, Debian Bug Tracking System wrote: Thanks for scheduling. I just noticed that there was no abi change between proftpd-dfsg 1.3.7a & proftpd-dfsg 1.3.7a+dfsg. I just thought there was one as [1] reported that our module packages were not installable short time ago. Closing. Note that 1.3.7a+dfsg is identical to 1.3.7a for the source code, it only removed pieces of documentation, so there was no reason to change ABI version. -- Francesco P. Lovergine
Bug#977349: Current package does not ensure a smooth upgrade from stable due to breakage of past config and new binary modules.
On Tue, Dec 15, 2020 at 09:01:51PM +0100, Hilmar Preuße wrote: Am 14.12.2020 um 11:02 teilte Francesco Paolo Lovergine mit: Hi Paolo, After upgrade: $ sudo proftpd -t Checking syntax of configuration file 2020-12-14 09:59:09,942 legolas proftpd[5444]: mod_dso/0.5: unable to load 'mod_tls.c'; check to see if '/usr/lib/proftpd/mod_tls.la' exists Please note that put the new packages into the Recommend line of proftp-basic. So people using a default apt config would get both new packages. At least on one of my installations this worked fine. Not in general, the default policy of installing Recommends could be relaxed by users for all packages in /etc/apt/apt.conf or even for single upgrades by options in apt-get/aptitude. So it would be a policy violation in any case. Not sure if this is the correct migration path according to policy. I'm sorry for the work I've caused! Well, there were in any case other details to manage. -- Francesco P. Lovergine
Bug#977107: [Gente-ctu] Bug#977107: proftpd-basic: Cannot login after upgrade from jessie to stretch then to buster
On Sun, Dec 13, 2020 at 11:03:07PM -0300, Hostmaster FCEIA-UNR wrote: Hello. Sorry for the delay. I was on a trip this weekend. I´m not using "AuthUsingAlias", just "AuthAliasOnly". Yep, I found that both directives give problems. I have a near default proftpd.conf and then ( in a file included from conf.d with) 400 users defined by the snippet I already sent (without AuthUsingAlias, as told before). Well, removing all AuthAliasOnly from the configuration, started to work as expected. What I still don´t understand is if it is a bug or a configuration error. Do you still need my proftpd.conf ? No thanks, it is a bug because intended behavior is different, and it is confirmed by using a simple configuration. The only strange thing is that I found the same issue in jessie (latest from LTS security branch) 1.3.5e+r1.3.5-2+deb8u7, so the last working one was probably 1.3.5-1.1+deb8u2? Note: Apparently a similar issue as for #4255 has been fixed in 1.3.5c and 1.3.6rc1, so it is definitively weird. -- Francesco P. Lovergine
Bug#977107: proftpd-basic: Cannot login after upgrade from jessie to stretch then to buster
tags 977107 = confirmed upstream severity 977107 normal thanks Ok, I managed to replicate the issue by using the default configuration and your snippet on buster. It works only by removing the AuthAliasOnly/AuthUsingAlias directives. Also, I did a fast trial with the latest jessie version (several security patch had been applied during its support time) with the same results. Same results with testing and moving AuthAliasOnly in global, too. AnonRequirePassword on RequireValidShell off AuthAliasOnly on <- here the problem AuthUsingAlias on <- here the problem, even by using x for UserPassword Userwww-data UserAlias x www-data Group www-data Umask 003 GroupOwner www-data MaxClients 2 AccessGrantMsg "Acceso Permitido a %u - Toda su actividad esta siendo monitoreada." HideNoAccesson UserPasswordwww-data w4/CBsf6D7jf2 -- Francesco P. Lovergine
Bug#977107: proftpd-basic: Cannot login after upgrade from jessie to stretch then to buster
tags 977107 + moreinfo thanks Please, provide the whole setup (for files that differ from distributed ones). often evil is in details. Hide sensible information like IPs, domains and passwords, of course. This smells like a configuration issue which changed from stretch times. Thanks On Thu, Dec 10, 2020 at 07:11:26PM -0300, Javier Kohan wrote: Package: proftpd-basic Version: 1.3.6-4+deb10u5 Severity: important Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? Running configuration in jessie and before. Upgraded system to stretch (didn't test in stretch) and then to buster. Using Useralias for websites . All was working ok, but after upgrade can not login. proftpd[22592] xxdu.ar (localhost[::1]): USER (Login failed): No such user found (some data edited for privacy) UserAlias users map to www-data Each folder of our web is configured like this: AnonRequirePassword on RequireValidShell off AuthAliasOnly on Userwww-data UserAlias x www-data Group www-data Umask 003 GroupOwner www-data MaxClients 2 AccessGrantMsg "Acceso Permitido a %u - Toda su actividad esta siendo monitoreada." HideNoAccesson UserPasswordwww-data w4/CBsf6D7jf2 have several folders like that. More information: we are using smbldap-tools and have users in ldap. However www-data is not in ldap, only in files (as it was from jessie and even before) *** End of the template - remove these template lines *** -- System Information: Debian Release: 10.7 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-13-amd64 (SMP w/2 CPU cores) Locale: LANG=es_AR.UTF-8, LC_CTYPE=es_AR.UTF-8 (charmap=UTF-8), LANGUAGE=es_AR:es (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages proftpd-basic depends on: ii adduser3.118 ii debianutils4.8.6.1 ii libacl12.2.53-4 ii libattr1 1:2.4.48-4 ii libc6 2.28-10 ii libcap21:2.25-2 ii libhiredis0.14 0.14.0-3 ii libmemcached11 1.0.18-4.2 ii libmemcachedutil2 1.0.18-4.2 ii libncursesw6 6.1+20181013-2+deb10u2 ii libpam-runtime 1.3.1-5 ii libpam0g 1.3.1-5 ii libpcre3 2:8.39-12 ii libssl1.1 1.1.1d-0+deb10u4 ii libtinfo6 6.1+20181013-2+deb10u2 ii libwrap0 7.6.q-28 ii lsb-base 10.2019051400 ii netbase5.6 ii sed4.7-1 ii ucf3.0038+nmu1 ii zlib1g 1:1.2.11.dfsg-1 Versions of packages proftpd-basic recommends: ii proftpd-doc 1.3.6-4+deb10u5 Versions of packages proftpd-basic suggests: ii openbsd-inetd [inet-superserver] 0.20160825-4 ii openssl 1.1.1d-0+deb10u4 pn proftpd-mod-geoip pn proftpd-mod-ldap pn proftpd-mod-mysql pn proftpd-mod-odbc pn proftpd-mod-pgsql pn proftpd-mod-snmp pn proftpd-mod-sqlite -- Configuration Files: /etc/default/proftpd changed: CONFIG_FILE=/etc/proftpd/proftpd.conf OPTIONS="-d 10" -- debconf information: * shared/proftpd/inetd_or_standalone: standalone ___ Pkg-proftpd-maintainers mailing list pkg-proftpd-maintain...@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-proftpd-maintainers -- Francesco P. Lovergine
Bug#977090: The 1.3.7a original tarball includes IETF RFCs documents
Source: proftpd-dfsg Version: 1.3.7a-1 Severity: serious Justification: Policy 2.2.1 As in subject, the RFCs need to be stripped before uploading a new upstream tarball, because not compliant to DFSG. That step was missed at the time of upload. -- Francesco P. Lovergine
Bug#975469: gpw: Weak seed to initialise the random generator
gram.h
+ rm -f gpw loadtris loadtris.o gpw.o randnum.o trigram.h
diff --git a/gpw.c b/gpw.c
index be3c307..2316f95 100644
--- a/gpw.c
+++ b/gpw.c
@@ -13,11 +13,6 @@
and looking for real words in its output.. they are very rare, on the
order of one in a thousand.
- This program uses "drand48()" to get random numbers, and "srand48()"
- to set the seed to the microsecond part of the system clock. Works
- for AIX C++ compiler and runtime. Might have to change this to port
- to another environment.
-
The best way to use this program is to generate multiple words. Then
pick one you like and transform it with punctuation, capitalization,
and other changes to come up with a new password.
@@ -35,6 +30,7 @@
/* #include */
/* following for BSD */
#include
+#include
int main (int argc, char ** argv) {
int password_length;/* how long should each password be */
@@ -47,14 +43,11 @@ int main (int argc, char ** argv) {
long sum; /* running total of
frequencies */
char password[100]; /* buffer to develop a password
*/
int nchar; /* number of chars in
password so far */
- struct timeval systime; /* time reading for random seed */
- struct timezone tz; /* unused arg to gettimeofday */
password_length = 8;/* Default value for password length */
n_passwords = 10; /* Default value for number of
pws to generate */
-gettimeofday (, ); /* Read clock. */
- srand48 (systime.tv_usec);/* Set random seed. */
+ srand48 (pw_random_number(LONG_MAX));/* Set random seed. */
if (argc > 1) { /* If args are given,
convert to numbers. */
n_passwords = atoi ([1][0]);
diff --git a/randnum.c b/randnum.c
new file mode 100644
index 000..7e55264
--- /dev/null
+++ b/randnum.c
@@ -0,0 +1,77 @@
+/*
+ * randnum.c -- generate (good) randum numbers.
+ *
+ * Copyright (C) 2001,2002 by Theodore Ts'o
+ *
+ * This file may be distributed under the terms of the GNU Public
+ * License.
+ */
+
+ /** This file is from pwgen package, adapted for gpw */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#ifdef HAVE_DRAND48
+extern double drand48(void);
+#endif
+
+static int get_random_fd(void);
+
+/* Borrowed/adapted from e2fsprogs's UUID generation code */
+static int get_random_fd()
+{
+ struct timeval tv;
+ static int fd = -2;
+
+ if (fd == -2) {
+ gettimeofday(, 0);
+ fd = open("/dev/urandom", O_RDONLY);
+ if (fd == -1)
+ fd = open("/dev/random", O_RDONLY | O_NONBLOCK);
+ }
+ return fd;
+}
+
+/*
+ * Generate a random number n, where 0 <= n < max_num, using
+ * /dev/urandom if possible.
+ */
+long int pw_random_number(max_num)
+ long int max_num;
+{
+ long int rand_num;
+ int i, fd = get_random_fd();
+ int lose_counter = 0, nbytes = sizeof(rand_num);
+ char *cp = (char *) _num;
+
+ if (fd >= 0) {
+ while (nbytes > 0) {
+ i = read(fd, cp, nbytes);
+ if ((i < 0) &&
+ ((errno == EINTR) || (errno == EAGAIN)))
+ continue;
+ if (i <= 0) {
+ if (lose_counter++ == 8)
+ break;
+ continue;
+ }
+ nbytes -= i;
+ cp += i;
+ lose_counter = 0;
+ }
+ }
+ if (nbytes == 0)
+ return (rand_num % max_num);
+
+ /* We weren't able to use /dev/random, fail hard */
+
+ fprintf(stderr, "No entropy available!\n");
+ exit(1);
+}
--
Francesco P. Lovergine
