Bug#1070304: util-linux: Please build and provide the cal binary
On Sat, May 04, 2024 at 04:13:37PM +0200, Michael Meskes wrote: > > The example was to show how people could achieve using ncal to get > > cal, if the > > ncal package would not ship a cal binary. > > Sure, but the only reason for the cal binary as it is, is to have the > original cal available. All new and extended features are in ncal and > are explicitly deactivated when called as cal. > That is valid reasoning or was at some point, but I want to argue that it might be good to rethink it today, since Alpine [1], Arch [2], CentOS [3], Fedora [4], Gentoo [5], Mageia [6], OpenMandriva [7], OpenSuse [8], RHEL [9], and Slackware [10] ship the /usr/bin/cal binary from the util-linux package (or split version of the package in case of Alpine or they don't disable it by default in the case of Gentoo). This is true even for very BSD forward Linux distributions like OpenMandriva. My point is, that anybody not using Debian or a derivative will expect cal to be the util-linux version. > But it is supported in ncal. Again, think of cal as traditional-cal if > that makes it easier. I will continue to think of ncal as the weird column-order calendar. :) In more seriousness, if the expectation is for people to use ncal and cal is just a remnant, that should best be ignored, I'd prefer that difference to the rest of the Linux distribution ecosystem be whittled away instead. [1] https://alpine.pkgs.org/3.19/alpine-main-x86_64/util-linux-2.39.3-r0.apk.html [2] https://archlinux.pkgs.org/rolling/archlinux-core-x86_64/util-linux-2.40-3-x86_64.pkg.tar.zst.html [3] https://centos.pkgs.org/9-stream/centos-baseos-x86_64/util-linux-2.37.4-18.el9.x86_64.rpm.html [4] https://fedora.pkgs.org/40/fedora-x86_64/util-linux-2.40-0.9.rc1.fc40.i686.rpm.html [5] https://gitweb.gentoo.org/repo/gentoo.git/tree/sys-apps/util-linux/util-linux-2.39.4.ebuild [6] https://mageia.pkgs.org/cauldron/mageia-core-release-x86_64/util-linux-2.40-3.mga10.x86_64.rpm.html [7] https://openmandriva.pkgs.org/rolling/openmandriva-main-release-aarch64/util-linux-2.39.4-1-omv2490.aarch64.rpm.html [8] https://opensuse.pkgs.org/tumbleweed/opensuse-oss-x86_64/util-linux-2.39.3-4.2.x86_64.rpm.html [9] by virtue of CentOS [10] https://slackware.pkgs.org/current/slackware-x86_64/util-linux-2.40-x86_64-2.txz.html signature.asc Description: PGP signature
Bug#1070304: util-linux: Please build and provide the cal binary
On Fri, May 03, 2024 at 08:38:27PM +0200, Michael Meskes wrote:
> > I think that ship has sailed already, since e.g. -m in the ncal
> > version
> > specifies the month (a bit superfluously), whereas in the util-linux
> > version it
> > sets the beginning of the week to Monday.
>
> Not sure why specifying the month is superfluous.
>
I'm sorry, that was a bit tongue in cheek. I'm sure there are valid uses for
this, but since cal can take the month as first argument, when given two
numeric arguments, there are multiple ways of achieving the same goal.
> > An alternative I could see would be to drop cal from the ncal package
> > and only
> > provide cal from util-linux.
> >
> > Nothing would be lost, since ncal can act as cal with the -C option,
> > so users
> > wanting that specific cal could use a function
> >
> > cal() {
> > ncal -C $@
> > }
> >
> > and the rest would get a cal that can show week numbers and set the
> > beginning of
> > the Monday.
>
> Now I'm confused. Is the reason for this proposal to have a cal that
> shows week numbers and forces the start of the week to Monday? Well,
> ncal does both of this, so why don't you just use something like "ncal
> -wMb" as cal? Not that ncal needs "-M", it is able to get this from
> your locale.
>
The example was to show how people could achieve using ncal to get cal, if the
ncal package would not ship a cal binary.
This is *not* about forcing Monday, util-linux cal takes that from the locale as
well, but when working in mixed locale settings or on a machine with just
C.UTF-8, it is nice to be able to change it and the obvious "cal -M" fails for
the ncal version, as does "cal -w". Requiring the use of ncal (instead of cal)
and an option documented as "Use oldstyle format for ncal output" seems highly
non-obvious to me.
> The question is does it offer all the other features? Or would we be
> better of switching to something like gcal instead?
That depends on what all the necessary features are? The differences as far as I
can see them at this moment are
- util-linux cal doesn't provide the date of Easter, unlike ncal cal
- util-linux cal supports beginning of week and week number switches for cal,
which do not work with ncal cal
- util-linux cal supports years after
- util-linux cal supports month names as strings instead of the -m argument
- ncal cal has -B and -A arguments for before and after, util-linux cal has a
--months (-n) switch for the number of months and they can be cented around a
given month with the --span (-S) option
gcal supports more different calendars and more holidays, but this seems to go
beyond the basic calendar functionality of either util-linux' and ncal's
implementation.
signature.asc
Description: PGP signature
Bug#1070304: util-linux: Please build and provide the cal binary
On Fri, May 03, 2024 at 05:38:46PM +0200, Chris Hofstaedtler wrote:
> > Unfortunately the command line switches
> > are not compatible and util-linux cal cannot display the date of Easter, so
> > it
> > is not drop-in compatible. It would nevertheless be great if e.g. an
> > alternatives selection for util-linux cal could be provided.
>
> I'm somewhat open to shipping util-linux's cal, but not if that
> involves update-alternatives.
>
> Could you maybe work with upstream, so that util-linux's cal becomes
> a drop-in replacement, and can work as both cal and ncal?
>
I think that ship has sailed already, since e.g. -m in the ncal version
specifies the month (a bit superfluously), whereas in the util-linux version it
sets the beginning of the week to Monday.
> Also, quite obviously is this something we want to do as Debian?
> Michael, as the maintainer of the current ncal package, what is your
> opinion here?
>
An alternative I could see would be to drop cal from the ncal package and only
provide cal from util-linux.
Nothing would be lost, since ncal can act as cal with the -C option, so users
wanting that specific cal could use a function
cal() {
ncal -C $@
}
and the rest would get a cal that can show week numbers and set the beginning of
the Monday.
signature.asc
Description: PGP signature
Bug#1070304: util-linux: Please build and provide the cal binary
Package: util-linux Version: 2.38.1-5+deb12u1 Severity: wishlist Upstream util-linux provides a cal binary, that is, in my opinion, superior to the cal provided by the ncal package, since the output is much more flexible. With the current cal provided ncal package the switches to configure the start of the week or week numbers are only available with the ncal binary, but not the cal binary. The util-linux version of cal provides a unified interface, including a vertical display like ncal, in a single binary. Unfortunately the command line switches are not compatible and util-linux cal cannot display the date of Easter, so it is not drop-in compatible. It would nevertheless be great if e.g. an alternatives selection for util-linux cal could be provided. -- System Information: Debian Release: 12.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-18-amd64 (SMP w/6 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages util-linux depends on: ii libblkid1 2.38.1-5+deb12u1 ii libc6 2.36-9+deb12u6 ii libcap-ng00.8.3-1+b3 ii libcrypt1 1:4.4.33-2 ii libmount1 2.38.1-5+deb12u1 ii libpam0g 1.5.2-6+deb12u1 ii libselinux1 3.4-1+b6 ii libsmartcols1 2.38.1-5+deb12u1 ii libsystemd0 252.22-1~deb12u1 ii libtinfo6 6.4-4 ii libudev1 252.22-1~deb12u1 ii libuuid1 2.38.1-5+deb12u1 ii util-linux-extra 2.38.1-5+deb12u1 ii zlib1g1:1.2.13.dfsg-1 Versions of packages util-linux recommends: ii sensible-utils 0.0.17+nmu1 Versions of packages util-linux suggests: ii dosfstools 4.2-1 ii kbd 2.5.1-1+b1 pn util-linux-locales -- no debconf information
Bug#1069658: python3-lib389: dsconf security subcommand does not work due to misnamed function parameters
Package: python3-lib389 Version: 2.3.1+dfsg1-1 Severity: important Tags: patch Dear maintaner, when following the 389ds documentation [1] to enable TLS for 389ds I noticed that the step dsconf security rsa set \ --tls-allow-rsa-certificates on \ --nss-token "internal (software)" \ --nss-cert-name Server-Cert failed with "Error: name 'log' is not defined". This is the same bug as [2]. Applying the upstream patch [3] fixes the problem. [1] https://access.redhat.com/documentation/en-us/red_hat_directory_server/12/html/securing_red_hat_directory_server/assembly_enabling-tls-encrypted-connections-to-directory-server_securing-rhds#proc_enabling-tls-encrypted-connections-to-directory-server-using-the-command-line_assembly_enabling-tls-encrypted-connections-to-directory-server [2] https://pagure.io/freeipa/issue/9283 [3] https://github.com/389ds/389-ds-base/commit/12c14ed15dba332378613ac3ad0bb046811c4d75 -- System Information: Debian Release: 12.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-18-amd64 (SMP w/6 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages python3-lib389 depends on: pn libnss3-tools ii openssl 3.0.11-1~deb12u2 ii python3 3.11.2-1+b1 ii python3-argcomplete 2.0.0-1 pn python3-argparse-manpage ii python3-dateutil 2.8.2-2 ii python3-distro1.8.0-1 pn python3-ldap ii python3-packaging 23.0-1 ii python3-pkg-resources 66.1.1-1 pn python3-pyasn1 pn python3-pyasn1-modules ii python3-pytest7.2.1-2 python3-lib389 recommends no packages. python3-lib389 suggests no packages.
Bug#1068250: dracut: Consider switching to the fork dracut-ng
Package: dracut Version: 059-4 Severity: wishlist Activity in dracut upstream has died down recently and though there is a version 60 of dracut in sid, upstream has not tagged such a release. A fork of dracut has been started by some dracut developers at https://github.com/dracut-ng/dracut-ng It should be evaluated to switch to this fork. -- System Information: Debian Release: 12.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-13-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages dracut depends on: ii dracut-core 059-4 dracut recommends no packages. Versions of packages dracut suggests: ii dracut-network 059-4 -- no debconf information
Bug#1032267: fai-client: Using holds crashes install_packages
Package: fai-client Version: 6.0 Severity: normal Tags: patch Using a holds throws message > Not an ARRAY reference at /usr/sbin/install_packages line 207, line 317. because the data has a different form than the code assumes. A fix is found upstream at https://github.com/faiproject/fai/pull/116 -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-5-amd64 (SMP w/6 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages fai-client depends on: ii debconf-utils1.5.82 ii file 1:5.44-3 ii iproute2 6.1.0-1 ii libfile-lchown-perl 0.02-3+b1 ii libgraph-perl1:0.9726-1 ii perl 5.36.0-7 ii procps 2:4.0.2-3 ii zstd 1.5.4+dfsg2-3 Versions of packages fai-client recommends: ii fdisk 2.38.1-5 ii util-linux 2.38.1-5 Versions of packages fai-client suggests: ii libgraph-perl 1:0.9726-1 pn logtail -- Configuration Files: /etc/fai/fai.conf [Errno 13] Permission denied: '/etc/fai/fai.conf' -- no debconf information
Bug#1010632: slurm-wlm: CVE-2022-29502
Package: slurm-wlm Version: 20.11.7+really20.11.4-2 Followup-For: Bug #1010632 This bug is is also present in the package version released in bullseye and fixed in upstream version 20.11.9. bullseye should definitely receive this update. -- System Information: Debian Release: 11.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-13-amd64 (SMP w/6 CPU threads) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages slurm-wlm depends on: ii slurm-client 20.11.7+really20.11.4-2 ii slurmctld 20.11.7+really20.11.4-2 ii slurmd20.11.7+really20.11.4-2 slurm-wlm recommends no packages. slurm-wlm suggests no packages. -- no debconf information
Bug#1001068: samba: Missing upstream commit 0a546be0 on bullseye, bookworm and sid (part of CVE-2020-25717)
Package: samba Version: 2:4.13.13+dfsg-1~deb11u2 Severity: important X-Debbugs-Cc: t...@security.debian.org The upstream samba commit 0a546be0 is included in the buster security release 2:4.9.5+dfsg-5+deb10u2 via the patch file bug-14901-v4-9.patch, but is missing in the bullseye security release 2:4.13.13+dfsg-1~deb11u2. Pleae apply that patch in bullseye as well, so that the idmap_nss fallback via SID mapping works. -- Package-specific info: * /etc/samba/smb.conf present, but not attached * /var/lib/samba/dhcp.conf not present -- System Information: Debian Release: 11.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-8-amd64 (SMP w/48 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_FIRMWARE_WORKAROUND, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages samba depends on: ii adduser 3.118 ii dpkg 1.20.9 ii init-system-helpers 1.60 ii libbsd0 0.11.3-1 ii libc62.31-13+deb11u2 ii libgnutls30 3.7.1-5 ii libldb2 2:2.2.3-2~deb11u1 ii libpam-modules 1.4.0-9+deb11u1 ii libpam-runtime 1.4.0-9+deb11u1 ii libpopt0 1.18-2 ii libpython3.9 3.9.2-1 ii libtalloc2 2.3.1-2+b1 ii libtasn1-6 4.16.0-2 ii libtdb1 1.4.3-1+b1 ii libtevent0 0.10.2-1 ii libwbclient0 2:4.13.13+dfsg-1~deb11u2 ii lsb-base 11.1.0 ii procps 2:3.3.17-5 ii python3 3.9.2-3 ii python3-dnspython2.0.0-1 ii python3-samba2:4.13.13+dfsg-1~deb11u2 ii samba-common 2:4.13.13+dfsg-1~deb11u2 ii samba-common-bin 2:4.13.13+dfsg-1~deb11u2 ii samba-libs 2:4.13.13+dfsg-1~deb11u2 ii tdb-tools1.4.3-1+b1 Versions of packages samba recommends: ii attr1:2.4.48-6 ii logrotate 3.18.0-2 ii python3-markdown3.3.4-1 pn samba-dsdb-modules pn samba-vfs-modules Versions of packages samba suggests: pn bind9 pn bind9utils pn ctdb pn ldb-tools pn ntp | chrony pn smbldap-tools pn ufw ii winbind2:4.13.13+dfsg-1~deb11u2 -- no debconf information
Bug#883911: lmod: new version available upstream
Package: lmod Version: 6.6-0.4 Followup-For: Bug #883911 The current upstream version is 8.5.8. It would be great if this package could be updated to the current major release. It could then also bump the dependency to lua 5.4. -- System Information: Debian Release: 11.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-7-amd64 (SMP w/6 CPU threads) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages lmod depends on: ii lua-filesystem 1.8.0-1 ii lua-json1.3.4-2 pn lua-posix pn lua-term pn lua5.2 ii tcl 8.6.11+1 lmod recommends no packages. lmod suggests no packages.
Bug#920556: lua-md5: lua5.3 support
Package: lua-md5 Version: 1.2+git+1+8d87fee-1.1 Followup-For: Bug #920556 It would be great if lua 5.3 could be added to the package and if the current version (1.3) could be packaged as well, as right, I need to depend on luarocks for this package. -- System Information: Debian Release: 11.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-7-amd64 (SMP w/6 CPU threads) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages lua-md5 depends on: ii libc6 2.31-12 lua-md5 recommends no packages. lua-md5 suggests no packages.
Bug#960676: autofs: update service file
So my race condition doesn't seem to be because of autofs not signalling readiness itself, since my problem still occurs with systemd support enabled in autofs and, as I noticed, also well after boot. Still, building autofs with systemd support would be nice to have in bookworm. It's time. :) Upstream also supplies a service file in their samples, so that can be used. In that case the init script is not installed, so as long as people want to have that, it needs to be added manually (in override_dh_auto_install I guess). OpenPGP_signature Description: OpenPGP digital signature
Bug#960676: autofs: update service file
On Tue, Jun 15, 2021 at 09:00:36AM +, Mike Gabriel wrote: > thanks for your contribution. To make an update possible for Debian bullseye > (we are in deep freeze), I need a more dramatic description of things that > might go wrong with the current .service file. > > Please explain the opposite of "robust" with concrete observations (i.e. > bugs). > > Furthermore, have you tested the proposed service file with autofs-ldap??? > With autofs-ldap we still have a nasty race condition that leaves autofs > non-function if it starts before nslcd (libnss LDAP caching daemon). > I'm not sure I can help you with the latter, since we use sssd and have never experienced any issues in that regard. I'm currently debugging a race condition with another service that only depends on autofs where a single autofs mountpoint doesn't work but all the others (all backed via LDAP) are. The service in question usually starts at the same second as autofs. Since notify will notify readiness when the service thinks it's ready instead of at fork time, my hope is that it will go away if autofs is actually ready, when it is shown as such. Just spitballing here, but maybe that's the issue with nslcd for you, too? Unfortunately nslcd doesn't doesn't have notification support, but I once worked around a similar issue with autofs data in NIS by busy looping in ExecStartPre= until NIS was actually working. Fortunately, with sssd this was no longer an issue. :) And as a nit: the /var/run path was a log nuisance for a long time and the only reason this has stopped, is because the systemd package now carries a patch to silence the warning, because it was apparently easier to do that than fix the service files all over Debian. Since the autofs package is built without --with-systemd, the above service file cannot be used out of the box. I'll rebuild autofs for my machines and will let you know whether it fixes my issue, but even if it doesn't it would be a positive change for all people using autofs on systemd. I completely understand that this probably can't make it into bullseye, but maybe for bookworm we can use the service file, that upstream has been shipping since end of October 2018. :) signature.asc Description: PGP signature
Bug#960676: autofs: update service file
Package: autofs Version: 5.1.7-1 Followup-For: Bug #960676 The current upstream version of autofs provides a sample service file that for Debian would look like this > [Unit] > Description=Automounts filesystems on demand > After=network.target ypbind.service sssd.service network-online.target > remote-fs.target rpc-statd.service rpcbind.service > Wants=network-online.target rpc-statd.service rpcbind.service > > [Service] > Type=notify > EnvironmentFile=-/etc/default/autofs > ExecStart=/usr/sbin/automount $OPTIONS --systemd-service --dont-check-daemon > ExecReload=/usr/bin/kill -HUP $MAINPID > KillMode=process > TimeoutSec=180 > > [Install] > WantedBy=multi-user.targe It would be great if you could change the service file to this. While those options are not documented in the man page, they are visible in the help output of the automount command. Changing the service file would make the service more robust. -- System Information: Debian Release: 11.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-5-amd64 (SMP w/6 CPU threads) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages autofs depends on: ii init-system-helpers 1.60 ii libc62.31-12 ii libnsl2 1.3.0-2 ii libtirpc31.3.1-1 ii libxml2 2.9.10+dfsg-6.7 ii ucf 3.0043 Versions of packages autofs recommends: ii e2fsprogs 1.46.2-1 ii kmod28-1 ii nfs-common 1:1.3.4-5 autofs suggests no packages. -- no debconf information
Bug#976960: systemd: Please package systemd-userdbd and systemd-homed
Thank you for your response! On Mon, Dec 21, 2020 at 06:22:04PM +0100, Michael Biebl wrote: > I still fail to see the use-case for homed, tbh and the current > implementation still requires quite a few hacks (see the fosdem 2020 > talk of Lennart and the problems e.g. with SSH keys). > > Atm this appears more like a tech-preview/demo and I don't feel > comfortable yet supporting it. > This can be reconsidered in bookworm. > While this is true, for the part that Lennart gave talks about, I've been using homed with the btrfs backend on Arch machine as a daily driver for a while and I think the cifs backend could be interesting for multi-user setups, e.g. in universities. signature.asc Description: PGP signature
Bug#976960: systemd: Please package systemd-userdbd and systemd-homed
Package: systemd Version: 246.6-2~bpo10+1 Severity: wishlist Dear systemd maintainers, judging from salsa [1] and the file lists of the systemd package on buster-backports and sid, systemd is currently built without the the systemd-userdbd and systemd-homed binaries and accompanying services. It would be great if these tools could be distributed either in the systemd package or, if deemed necessary, as an extra package, like systemd-container. I am aware, that these tools might need some more integration with Debian, e.g. providing PAM snippets, but they are mostly standalone and their use can be completely avoided even when installed, as they are installed by default e.g. on Arch Linux. I think this these tools could be a great boon in enterprise settings for mounting users' homes via SMB in a nicely portable fashion. Thank you for your work! best regards, Jörg Behrmann [1] https://salsa.debian.org/systemd-team/systemd/-/blob/debian/master/debian/rules -- Package-specific info: -- 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.8.0-0.bpo.2-amd64 (SMP w/6 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages systemd depends on: ii adduser 3.118 ii libacl1 2.2.53-4 ii libapparmor1 2.13.2-10 ii libaudit11:2.8.4-3 ii libblkid12.33.1-0.1 ii libc62.28-10 ii libcap2 1:2.25-2 ii libcryptsetup12 2:2.1.0-5+deb10u2 ii libgcrypt20 1.8.4-5 ii libgnutls30 3.6.7-4+deb10u5 ii libgpg-error01.35-1 ii libidn2-02.0.5-1+deb10u1 ii libip4tc01.8.2-4 ii libkmod2 26-1 ii liblz4-1 1.8.3-1 ii liblzma5 5.2.4-1 ii libmount12.33.1-0.1 ii libpam0g 1.3.1-5 ii libpcre2-8-0 10.32-5 ii libseccomp2 2.3.3-4 ii libselinux1 2.8-1+b1 ii libsystemd0 246.6-2~bpo10+1 ii libzstd1 1.4.4+dfsg-3~bpo10+1 ii mount2.33.1-0.1 ii systemd-timesyncd [time-daemon] 246.6-2~bpo10+1 ii util-linux 2.33.1-0.1 Versions of packages systemd recommends: ii dbus 1.12.20-0+deb10u1 Versions of packages systemd suggests: ii policykit-10.116-1~~zedv1 ii systemd-container 246.6-2~bpo10+1 Versions of packages systemd is related to: ii dracut 048+80-2 pn initramfs-tools pn libnss-systemd ii libpam-systemd 246.6-2~bpo10+1 ii udev 246.6-2~bpo10+1 -- no debconf information
Bug#976959: systemd: Please package systemd-repart
Package: systemd Version: 246.6-2~bpo10+1 Severity: wishlist Dear systemd maintainers, judging from salsa [1] and the file lists of the systemd package on buster-backports and sid, systemd is currently built without the the systemd-repart binary. It would be great if this tool could be distributed either in the systemd package or, if deemed necessary, as a new package systemd-repart, like systemd-container. I think this tool is pretty standalone and its inclusion shouldn't hurt people not using it, but it would remove the burden of having to rebuild the systemd package from people wanting to use it. Thank you for your work! best regards, Jörg Behrmann [1] https://salsa.debian.org/systemd-team/systemd/-/blob/debian/master/debian/rules -- Package-specific info: -- 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.8.0-0.bpo.2-amd64 (SMP w/6 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages systemd depends on: ii adduser 3.118 ii libacl1 2.2.53-4 ii libapparmor1 2.13.2-10 ii libaudit11:2.8.4-3 ii libblkid12.33.1-0.1 ii libc62.28-10 ii libcap2 1:2.25-2 ii libcryptsetup12 2:2.1.0-5+deb10u2 ii libgcrypt20 1.8.4-5 ii libgnutls30 3.6.7-4+deb10u5 ii libgpg-error01.35-1 ii libidn2-02.0.5-1+deb10u1 ii libip4tc01.8.2-4 ii libkmod2 26-1 ii liblz4-1 1.8.3-1 ii liblzma5 5.2.4-1 ii libmount12.33.1-0.1 ii libpam0g 1.3.1-5 ii libpcre2-8-0 10.32-5 ii libseccomp2 2.3.3-4 ii libselinux1 2.8-1+b1 ii libsystemd0 246.6-2~bpo10+1 ii libzstd1 1.4.4+dfsg-3~bpo10+1 ii mount2.33.1-0.1 ii systemd-timesyncd [time-daemon] 246.6-2~bpo10+1 ii util-linux 2.33.1-0.1 Versions of packages systemd recommends: ii dbus 1.12.20-0+deb10u1 Versions of packages systemd suggests: ii policykit-10.116-1~~zedv1 ii systemd-container 246.6-2~bpo10+1 Versions of packages systemd is related to: ii dracut 048+80-2 pn initramfs-tools pn libnss-systemd ii libpam-systemd 246.6-2~bpo10+1 ii udev 246.6-2~bpo10+1 -- no debconf information
Bug#844528: systemd is missing the systemd-firstboot binary (and service)
Dear maintainers I'd like to use systemd-firstboot in some custom bootstrapping work. systemd-firstboot shouldn't interfere with anything else. Would it maybe be possible to get it included now that Debian allows for stronger integration with systemd? sincerely, Jörg Behrmann signature.asc Description: OpenPGP digital signature
Bug#968039: dracut: Install config files to /usr/lib/dracut/dracut.conf.d instead of /etc/dracut.conf.d
Package: dracut Version: 048+80-2 Severity: normal The man page for dracut.conf says > *.conf files are read from /usr/lib/dracut/dracut.conf.d and > /etc/dracut.conf.d. > Files with the same name in /etc/dracut.conf.d will replace files in > /usr/lib/dracut/dracut.conf.d. with the intention being, similarly to systemd config, that distributor supplied files can be overwritten by the local sysadmin, by putting files into /etc/dracut.conf.d and/or symlinking files from /usr/lib/dracut/dracut.conf.d to /dev/null. The packages - dracut-config-generic, - dracut-config-rescue, - dracut-core, and - dracut-network install files to /etc/dracut.conf.d that should probably be installed to /usr/lib/dracut/dracut.conf.d instead. -- System Information: Debian Release: 10.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.4.0-0.bpo.2-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_WARN Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages dracut depends on: ii dracut-core 048+80-2 dracut recommends no packages. Versions of packages dracut suggests: ii dracut-network 048+80-2 -- no debconf information
Bug#960672: [Pkg-sssd-devel] Bug#960672: sssd: Update service file
On 01.07.20 09:14, Timo Aaltonen wrote: > I'm not doing this, instead I'll add DEBUG_LOGGER template to > /etc/default/sssd and mention that DAEMON_OPTS is only used for the > initscript. > I would like to argue, that the total removal of the coupling of the service file and /etc/defaults/sssd might be the better way forward. The current state is that /etc/defaults/sssd has no effect on sssd.service. I don't think it's a good idea to introduce it now, since it's a hidden layer of configuration that cannot be accessed via `systemctl cat`. It's perfectly fine for init scripts to use /etc/defaults, as there is no better mechanism to alter configuration, but for systemd unit files drop-ins are far superior, since `systemctl cat` aggregates them, shifting the burden of piecing together the configuration away from admins. Furthermore, using drop-ins in /lib/systemd/system/sssd.service.d would allow to carry Debian changes to the default config in files that could be changed atomically on updates without interfering with locally supplied changes. signature.asc Description: OpenPGP digital signature
Bug#857678: [Pkg-utopia-maintainers] Bug#857678: use /run prefix in systemd socket unit
Ah, sorry. I had only checked debian/master on salsa and had missed debian/experimental. signature.asc Description: PGP signature
Bug#960676: autofs: update service file
Package: autofs Version: 5.1.2-4 Severity: wishlist I have two small issues with the service file 1) The current service file for autofs on buster sets PIDFile=/var/run/autofs.pid I saw that it is changed to PIDFile=/run/autofs.pid on salsa, which is great, but ExecStart still sets --pid-file /var/run/autofs.pid which should be changed for consistency. 2) Type=forking could be changed to Type=simple, when the -f option is added. In this mode autofs logs to stderr instead of syslog, so it might be advisable to also set SyslogIdentifier= -- System Information: Debian Release: 10.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.4.0-0.bpo.2-amd64 (SMP w/6 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages autofs depends on: ii libc62.28-10 ii libxml2 2.9.4+dfsg1-7+b3 ii ucf 3.0038+nmu1 Versions of packages autofs recommends: ii e2fsprogs 1.44.5-1+deb10u3 ii kmod26-1 ii nfs-common 1:1.3.4-2.5 autofs suggests no packages. -- no debconf information
Bug#857678: use /run prefix in systemd socket unit
I just wanted to open this very same bug. Could this issue maybe be looked at again? /run seems to have now won and /var/run only be used by legacy systems. systemd automatically updates the path to /run even if /var/run is set, but logs a warning, that leads to quite a bit of log spam in tje journal. It would be wonderful if dbus would be configured with the appropriate --with-systemd-socket signature.asc Description: PGP signature
Bug#960672: sssd: Update service file
Package: sssd Version: 1.16.3-3.2 Severity: normal Tags: patch The service file for sssd seems to be the upstream one, but on Debian it has some minor issues: 1. PIDFile is set to /var/run/sssd.pid via PIDFile=@pidpath@/sssd.pid during the build, but systemd-analyze complains /lib/systemd/system/sssd.service:13: PIDFile= references a path below legacy directory /var/run/, updating /var/run/sssd.pid → /run/sssd.pid; please update the unit file accordingly. The path is automatically updated, but it does produce unnecessary logspam. The configure script seems to have an option --with-pid-path to change this. 2. The EnvironmentFile is set to -/etc/default/sssd, but said file says that it is only used for /etc/init.d/sssd and its DAEMON_OPTS, that are thankfully unused in the service file, would daemonize sssd in contradiction to the explicit foreground option in ExecStart and also use the deprecated --debug-to-files option (via its shorthand -f). It would be best to just remove the line, although this would need to be done in all sssd service files. 3. The DEBUG_LOGGER environment variable should be unnecessary, when all sssd services are socket activated, and --logger could be set on the ExecStart line, making the configuration clearer. Attached is how the sssd.service file could look. I do understand, though, that all the service files for the socket activated mode of service would need to be changed as well. I would do the busy work if needed. -- System Information: Debian Release: 10.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.4.0-0.bpo.2-amd64 (SMP w/6 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages sssd depends on: ii python3-sss 1.16.3-3.2 ii sssd-ad 1.16.3-3.2 ii sssd-common 1.16.3-3.2 ii sssd-ipa 1.16.3-3.2 ii sssd-krb51.16.3-3.2 ii sssd-ldap1.16.3-3.2 ii sssd-proxy 1.16.3-3.2 sssd recommends no packages. sssd suggests no packages. -- no debconf information [Unit] Description=System Security Services Daemon # SSSD must be running before we permit user sessions Before=systemd-user-sessions.service nss-user-lookup.target Wants=nss-user-lookup.target [Service] ExecStart=/usr/sbin/sssd -i --logger=files Type=notify NotifyAccess=main PIDFile=/run/sssd.pid [Install] WantedBy=multi-user.target
Bug#960673: sssd: build sssd with support for journald logging
Package: sssd Version: 1.16.3-3.2 Severity: wishlist According to the man page sssd can be run with --logger=journald This unfortunately produced the warnings Unexpected logger: journald Expected: stderr, files I quickly looked at the upstream configure file and this seems to depend on a --with-syslog option. It would be nice if sssd could log directly to the journal. -- System Information: Debian Release: 10.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.4.0-0.bpo.2-amd64 (SMP w/6 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages sssd depends on: ii python3-sss 1.16.3-3.2 ii sssd-ad 1.16.3-3.2 ii sssd-common 1.16.3-3.2 ii sssd-ipa 1.16.3-3.2 ii sssd-krb51.16.3-3.2 ii sssd-ldap1.16.3-3.2 ii sssd-proxy 1.16.3-3.2 sssd recommends no packages. sssd suggests no packages. -- no debconf information
Bug#929382: python3-lib389: dsidm posixgroup create fails due to Namespace error in cli_idm/posixgroup.py
Package: python3-lib389
Version: 1.4.0.22-1
Severity: normal
Tags: patch
When running
dsidm posixgroup create foo
to create the group foo, dsidm fails with a namespace error, saying that
args does not have the attribute extra.
The problem can be found in versions 1.4.0.21 and 1.4.0.22 and has been
fixed upstream.
A patch is attached.
-- System Information:
Debian Release: 10.0
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.19.0-5-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL
set to en_US.UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) (ignored: LC_ALL set to
en_US.UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages python3-lib389 depends on:
ii python3 3.7.2-1
ii python3-argcomplete 1.8.1-1
ii python3-argparse-manpage 1.1-1
ii python3-dateutil 2.7.3-3
ii python3-ldap 3.1.0-2
ii python3-pyasn10.4.2-3
ii python3-pyasn1-modules0.2.1-0.2
ii python3-pytest3.10.1-2
ii python3-six 1.12.0-1
python3-lib389 recommends no packages.
python3-lib389 suggests no packages.
-- no debconf information
--- posixgroup.py.broken2019-05-22 16:51:15.051955626 +0200
+++ posixgroup.py 2019-05-22 16:52:03.423941608 +0200
@@ -39,7 +39,7 @@
_generic_get_dn(inst, basedn, log.getChild('_generic_get_dn'), MANY, dn,
args)
def create(inst, basedn, log, args):
-kwargs = _get_attributes(args.extra, MUST_ATTRIBUTES)
+kwargs = _get_attributes(args, MUST_ATTRIBUTES)
_generic_create(inst, basedn, log.getChild('_generic_create'), MANY,
kwargs, args)
def delete(inst, basedn, log, args):
Bug#925221: [Pkg-freeipa-devel] Bug#925221: python3-lib389: Instance removal fails due to hard-coded path
On Thu, Mar 21, 2019 at 03:29:00PM +0200, Timo Aaltonen wrote: > Thanks a lot for sending it upstream. I wonder if it should/could be > pushed for buster too. > I got an answer from upstream and for the 1.4.1.X release cycle they revamped that part of the code [1], since lib389 was merged into 389-ds-base and I was looking at the old lib389 repo. I will need to see, whether this fixes the issue, but I already noted, that they still hardcode /etc/sysconfig there at one point. For the 1.4.0.X releases it would then make sense to push this for buster, since otherwise instances cannot be deleted with dsctl. [1] https://pagure.io/389-ds-base/issue/50208 signature.asc Description: PGP signature
Bug#925221: python3-lib389: Instance removal fails due to hard-coded path
Package: python3-lib389 Version: 1.4.0.21-1 Severity: normal Tags: patch upstream Running "dsctil remove --do-it" or "dsctl --remove-all" fail fails in lib389/instance/remove.py:remove_ds_instance when asserting the existence of its marker file, which on RH systems is in /etc/sysconfig/dirsrv-, but in Debian is in /etc/default/dirsrv-. Unfortunately this path is hard-coded. A patch is attached and will be submitted upstream. -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-2-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages python3-lib389 depends on: ii python3 3.7.2-1 ii python3-argcomplete 1.8.1-1 ii python3-argparse-manpage 1.1-1 ii python3-dateutil 2.7.3-3 ii python3-ldap 3.1.0-2 ii python3-pyasn10.4.2-3 ii python3-pyasn1-modules0.2.1-0.2 ii python3-pytest3.10.1-2 ii python3-six 1.12.0-1 python3-lib389 recommends no packages. python3-lib389 suggests no packages. -- no debconf information --- remove.py 2019-03-21 11:37:29.093572057 +0100 +++ remove.py.fixed 2019-03-21 11:36:23.389675946 +0100 @@ -39,7 +39,7 @@ remove_paths['tmpfiles_d'] = dirsrv.ds_paths.tmpfiles_d + "/dirsrv-" + dirsrv.serverid + ".conf" remove_paths['inst_dir'] = dirsrv.ds_paths.inst_dir -marker_path = "%s/sysconfig/dirsrv-%s" % (dirsrv.ds_paths.sysconf_dir, dirsrv.serverid) +marker_path = "%s/dirsrv-%s" % (dirsrv.ds_paths.initconfig_dir, dirsrv.serverid) etc_dirsrv_path = os.path.join(dirsrv.ds_paths.sysconf_dir, 'dirsrv/') ssca_path = os.path.join(etc_dirsrv_path, 'ssca/')
Bug#692108: python-pip: --ignore-installed option is ignored
The version 1.5 of pip, fixing this bug [1] has incidentally been released today. best regards, Joerg [1] http://www.pip-installer.org/en/latest/news.html#id1 signature.asc Description: OpenPGP digital signature
Bug#692108: python-pip: --ignore-installed option is ignored
Control: tag + fixed-upstream
On Sun, Jun 02, 2013 at 01:21:53AM +0200, Stefano Rivera wrote:
Control: tag -1 upstream
Hi Joerg (2012.11.02_11:58:16_+0200)
pip install --install-option=--prefix=${HOME}/.mypython27
--ignore-installed module name
Since 1.3, this should be possible, using --user instead of setting a
prefix. While this doesn't solve your specific problem, it should allow
you to install a newer version of a system package, locally.
See https://github.com/pypa/pip/pull/705
Sorry for the late answer, yep, --user works (and has been working since 1.3).
Following up on this bug, I even noticed, that if one first does a --user
install even my above commandline works again, since it then tries to uninstall
the installation in .local but not in /usr
I'm not going to close this bug in the 1.3.1 upload, as this specific
issue isn't dealt with. I recommend filing it upstream.
Even with me forgetting about the bug it has been filed upstream (
https://github.com/pypa/pip/issues/991 )
an recently fixed (see this pull request https://github.com/pypa/pip/pull/1352 )
I just built pip 1.5rc4 and found that the bug is indeed fixed, so when pip 1.5
is released I would hope for it to quickly move to the Debian repos.
best regards,
Joerg
pgpFwsk0YJh5W.pgp
Description: PGP signature
