Bug#916122: pbuilder: misleading warning about missing cgroups
We still have pbuilder version 0.231 for current Debian OS 12 (Bookworm)
and warning message about not using cgroups is still shown.
It is in shell script file "/usr/lib/pbuilder/pbuilder-checkparams":
1) The check in line 398 "systemctl is-system-running --quiet >/dev/null
2>&1" returns with shell exit code 1 which must 0 and if-condition using
cgroups is never fulfilled.
2) Semantically, the if-condition in line 398 and 394 does not work
anymore for newer bash releases
391 if [ "$USECGROUP" = "yes" ]; then
392 # v215 is required for systemd-escape
393 if systemctl is-system-running --quiet >/dev/null 2>&1 && \
394 dpkg --compare-versions "$(dpkg-query -W
--showformat='${Version}' systemd)" gt 215; then
395 # --description uses that no-spaces string because the
quoting sucks
396 # right now, and it would end up trying to execute
$PBUILDER_OPERATION…
397 # long-term solution is to turn $CHROOTEXEC into a
command and properly
398 # use arrays instead of plain strings.
399
SYSTEMD_SLICE="system-pbuilder-${PBUILDER_OPERATION}${1:+-"$(systemd-escape "$(basename "$1" .dsc)")"}-$$.slice"
400 systemctl_run=(
401 systemd-run
402 --quiet
403 --scope
404
--description="pbuilder_${PBUILDER_OPERATION}${1:+_"$(basename "$1")"}"
405 --slice="$SYSTEMD_SLICE"
406 )
407 CHROOTEXEC="${systemctl_run[*]} $CHROOTEXEC"
408 else
409 log.w "cgroups are not available on the host, not using
them."
410 USECGROUP=not-available
411 fi
I changed the code in this way from line 393 until 395:
391 if [ "$USECGROUP" = "yes" ]; then
392 # v215 is required for systemd-escape
393 _systemd_ver=$(systemd --version | grep 'systemd' | sed -r
's/(^systemd[[:blank:]]+)([0-9]{3})(.*$)/\2/')
394
395 if [[ ${_systemd_ver} -gt 215 ]] ; then
396 # --description uses that no-spaces string because the
quoting sucks
397 # right now, and it would end up trying to execute
$PBUILDER_OPERATION…
398 # long-term solution is to turn $CHROOTEXEC into a
command and properly
399 # use arrays instead of plain strings.
400
SYSTEMD_SLICE="system-pbuilder-${PBUILDER_OPERATION}${1:+-"$(systemd-escape "$(basename "$1" .dsc)")"}-$$.slice"
401 systemctl_run=(
402 systemd-run
403 --quiet
404 --scope
405
--description="pbuilder_${PBUILDER_OPERATION}${1:+_"$(basename "$1")"}"
406 --slice="$SYSTEMD_SLICE"
407 )
408 CHROOTEXEC="${systemctl_run[*]} $CHROOTEXEC"
409 else
410 log.w "cgroups are not available on the host, not using
them."
411 USECGROUP=not-available
412 fi
1) Problematic check if systemd is running was eliminated, it was
introduced with Debian 8, long time ago. So systemd is status quo!
2) The evaluation of the systemd version is done in line 393 using the
"systemd --version" command
3) Line 395, simplified expression in if-clause, executing shell
commands in clause will/may not work anymore like in my case
On Mon, 07 Jan 2019 18:01:01 +0100 Yves-Alexis Perez
wrote:
On Mon, 2019-01-07 at 16:03 +0100, Mattia Rizzolo wrote:
> On Sun, Jan 06, 2019 at 11:47:03AM +0100, Yves-Alexis Perez wrote:
> > Also, I also have the message while I *am* using systemd as init
system.
> Most likely that's a different issue, filed as #917354
> Check your system with `systemctl list-units --failed`.
Indeed, my system is basically half the time in degraded mode:
root@scapa:~# systemctl is-system-running
degraded
root@scapa:~# echo $?
1
root@scapa:~# systemctl --failed
UNIT LOAD ACTIVE
SUB DESCRIPTION
● mnt-scapa\x2dbackup.mount loaded failed failed /mnt/scapa-backup
(this is my external backup drive). Thanks for the tip anyway.
Regards,
>
Bug#961660: Cause is have() Wrapper Function of Function _have()
Hello Gabriel,
> If I try to complete the second word, then it doesn't work, but that's
> because I don't have the configuration file under /etc and I believe
> that this is unrelated to your problem:
> $ fsmtool2 showconfig
> grep: /etc/fsmd2/fsmd2.conf: No such file or directory
Yes, that's unrelated.
> So, would you be willing to make that change in your scripts? It looks
> like the right thing to do anyway.
I did this already:
1) I removed my old workaround, storing the completion script
below /etc/bash_completion.d/,
a) not using anymore the .install files as a workaround
b) using dh_bash-completion which stores it below
/usr/share/bash-completion/completions/ which is the
right way - yes (there is only one completion script
left from distribution side, "git-prompt")
c) I removed the broken surrounding "have(){ }" function not
using it anymore as many other do (look into some completion
scripts, neither have() nor _have() is used)
It works now for Stretch, Buster and Bullseye. By the way, have() is also
broken in Bullseye, with _have() it works.
--
Thanks
Jürgen
Bug#961660: Cause is have() Wrapper Function of Function _have()
Hello Gabriel,
I found the cause. It is the wrapper function have() of the obviously newer
function _have() in the shell script
/usr/share/bash-completion/bash_completion
As shown there, have() is still kept for backwards compatibility reasons:
--8<-
# This function checks whether we have a given program on the system.
#
_have()
{
# Completions for system administrator commands are installed as well in
# case completion is attempted via `sudo command ...'.
PATH=$PATH:/usr/sbin:/sbin:/usr/local/sbin type $1 &>/dev/null
}
# Backwards compatibility for compat completions that use have().
# @deprecated should no longer be used; generally not needed with dynamically
# loaded completions, and _have is suitable for runtime use.
have()
{
unset -v have
_have $1 && have=yes
}
--8<-
If have() is used AND bash-completion script is stored into directory
/usr/share/bash-completion/completions
completion does not work anymore. If the script with the old have() function is
stored in the path
/etc/bash_completion.d/
it will work as reported earlier.
If we replace have() by _have() or simply remove it in the bash completion
script (like many other do) it will work in both storage paths.
--
Jürgen
Bug#963606: AW: Bug#963606: Info received (Bug#963606: On Debian Stretch OS, screen Session killed after System Logout)
Hello Axel, the OpenVZ/container maintainer went into this and fixed it with the installation of the libpam-systemd: apt-get install libpam-systemd After the question from my side how he came to this conclusion, this is all I got out of him: "I think the cause is not easily identified now. Maybe something was changed longer ago and that caused a change in system behavior when the system rebooted. The other system I tried (without success) to reproduce the problem had systemd --user sessions running. This seems to prevent the problem. I am not sure though, so this should be tested." Regards Jürgen
Bug#963606: On Debian Stretch OS, screen Session killed after System Logout
Hello Axel, first, thank you for the quick response, I am not used to it from the Debian community. > * Which init system do you use? To me it looks like a "pseudo-hybrid" of SysV and systemd: $ ps axfwu USER PID %CPU %MEMVSZ RSS TTY STAT START TIME COMMAND root 1 0.1 0.1 67092 4744 ?Ss 14:27 0:00 init -z root 2 0.0 0.0 0 0 ?S14:27 0:00 [kthreadd/219364] root 3 0.0 0.0 0 0 ?S14:27 0:00 \_ [khelper/2193643] root37 0.0 0.0 43104 1756 ?Ss 14:27 0:00 /lib/systemd/systemd-udevd root38 0.0 0.0 46036 3316 ?Ss 14:27 0:00 /lib/systemd/systemd-journald root 110 0.0 0.0 37924 2488 ?Ss 14:27 0:00 /lib/systemd/systemd-logind [...] The system is virtualised running on an OpenVZ hypervisor, a virtualisation on OS level, similar to LXC. As we can see, process with PID=1 is not systemd, it's init. I assume it's the hypervisor's init (hypervisor obviously running with SysV), so not virtualised. I don't know about the details of OpenVZ and the setup here. The container where screen is running in it and the hypervisor itself is maintained and operated by the run responsible team. My role here is a software developer, software used by another team, the first level support. >> But I have the same issue with all self-compiled screen binaries, >> the detached screen session was killed after system logout. > > Yes, because that's smells a lot like a systemd issue and not a screen > issue. > > I was thinking of this bug in systemd: https://bugs.debian.org/825394 > > But to my surprise this was actually fixed before Stretch. There one more detail I detected meanwhile. The application running in screen worked for a year impeccably without killed sessions after system logout. What I detected after I reported this bug was, the container was rebooted 30 days ago and since then this issue with screen occurs. > So some more questions: > > * Any chance that there are systemd-sysv and systemd installed on your > system, but the package is not up to date? The most resent release of systemd-sysv and systemd is installed inside the container: $ apt policy systemd-sysv systemd-sysv: Installed: 232-25+deb9u12 Candidate: 232-25+deb9u12 Version table: *** 232-25+deb9u12 500 500 http://debian.schlund.de/debian stretch/main amd64 Packages 100 /var/lib/dpkg/status 232-25+deb9u11 500 500 http://debian.schlund.de/debian-security stretch/updates/main amd64 Packages root@shl-ehb-tool:~# apt policy systemd systemd: Installed: 232-25+deb9u12 Candidate: 232-25+deb9u12 Version table: *** 232-25+deb9u12 500 500 http://debian.schlund.de/debian stretch/main amd64 Packages 100 /var/lib/dpkg/status 232-25+deb9u11 500 500 http://debian.schlund.de/debian-security stretch/updates/main amd64 Packages > * Any chance that you configured systemd with KillUserProcesses=yes in > /etc/systemd/logind.conf? Good point. The unchanged "factory" setting of it is installed, all configuration keys are put in comment below the "[Login]" section which means "KillUserProcesses" defaults to "yes" according the manual page of logind.conf(5). I uncommented the line, so it's "KillUserProcesses=no" and rebooted the container, I did not help - same result. I don't think /etc/systemd/logind.conf was changed before the reboot, I suppose it worked before even with the "factory" setting where "KillUserProcesses" defaults to "yes". >> I installed the tmux package, started a tmux session, detached from >> it and logged out from system. After login, there was no more tmux >> session I can reattach, no more such processes. So Same behaviour. > > Another clear sign that this is no bug in screen. Yes, after this step it was clear to me, it has nothing to do with screen. >> libtinfo5 is a low level terminal library, maintained by Debian, >> derived from libncurses: > > Yeah, but completely unrelated to this issue. > >> I suppose the bug is in libtinfo5 shared library. I placed a binary compatible .so from my workstation in the container and yes, I can confirm, it has nothing to do with libtinfo5 shared library. > But why did you then report the bug against screen then? I asked the same question to myself before I reported the bug. I decided not opening a bug report for libtinfo5. I thought and I hoped to get a little bit more information about the interaction between screen and libtinfo5 in order to get some hints or ideas where to look else in case you can't help here. I expected obtaining more useful information when I go this way first as vice versa, since screen has more dependencies than the shared library and the developer of screen has more detailed know- ledge about interactions with other components. So, from the hints and clues you gave, I wasn't that wrong with my decision. But
Bug#963606: On Debian Stretch OS, screen Session killed after System Logout
Package: screen Version: 4.5.0-6 Severity: important Steps to Reproduce on Debian Stretch OS --- 1) invoke: screen 2) start a program e.g. top (or none) 3) detach from screen session by pressing keys CRTL+A+D 4) process listing looks as usual, SCREEN process has no TTY, all the forks have one: $ ps axfwu root 1581 0.0 0.0 28176 1628 ?Ss 10:12 0:00 SCREEN root 1582 0.0 0.0 20068 2408 pts/1Ss 10:12 0:00 \_ /bin/bash root 1585 0.0 0.0 42744 2052 pts/1S+ 10:12 0:00 \_ top 5) log out from system, in my case close SSH-session on remote system 6) log in again, screen session does not exist anymore, no more such processes Screen Session on Debian Buster OS -- If you start a screen session, detach and log out and in, screen session persists and is reattachable - works as expected. Attempt to Workaround - Since there is no newer or older (regression) release for screen package available from repository, I compiled the screen binary on my own with the original source. It compiled successfully for all screen code releases I tried: - 4.8.0 - 4.6.2 - 4.2.1 But I have the same issue with all self-compiled screen binaries, the detached screen session was killed after system logout. Installation of the tmux Package I installed the tmux package, started a tmux session, detached from it and logged out from system. After login, there was no more tmux session I can reattach, no more such processes. So Same behaviour. Common Shared Library Bindings of screen and tmux - libtinfo.so.5 is the common shared object file which screen and tmux are linked against it: ldd /usr/bin/screen linux-vdso.so.1 (0x7fffa24ae000) libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 (0x7fe796fe4000) libcrypt.so.1 => /lib/x86_64-linux-gnu/libcrypt.so.1 (0x7fe796dac000) libpam.so.0 => /lib/x86_64-linux-gnu/libpam.so.0 (0x7fe796b9e000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7fe7967ff000) libaudit.so.1 => /lib/x86_64-linux-gnu/libaudit.so.1 (0x7fe7965d7000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7fe7963d3000) /lib64/ld-linux-x86-64.so.2 (0x7fe79748d000) libcap-ng.so.0 => /lib/x86_64-linux-gnu/libcap-ng.so.0 (0x7fe7961cd000) ldd /usr/bin/tmux linux-vdso.so.1 (0x7ffe083ec000) libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x7f54bbecb000) libutempter.so.0 => /usr/lib/x86_64-linux-gnu/libutempter.so.0 (0x7f54bbcc8000) libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 (0x7f54bba9e000) libevent-2.0.so.5 => /usr/lib/x86_64-linux-gnu/libevent-2.0.so.5 (0x7f54bb856000) libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x7f54bb63f000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f54bb2a) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x7f54bb083000) /lib64/ld-linux-x86-64.so.2 (0x7f54bc355000) libtinfo5 is a low level terminal library, maintained by Debian, derived from libncurses: dkpkg --status libtinfo5 -bash: dkpkg: command not found root@shl-ehb-tool:~/dev# dpkg --status libtinfo5 Package: libtinfo5 Status: install ok installed Priority: required Section: libs Installed-Size: 478 Maintainer: Craig Small Architecture: amd64 Multi-Arch: same Source: ncurses Version: 6.0+20161126-1+deb9u2 Replaces: libncurses5 (<< 5.9-3) Depends: libc6 (>= 2.16) Breaks: dialog (<< 1.2-20130523) Description: shared low-level terminfo library for terminal handling The ncurses library routines are a terminal-independent method of updating character screens with reasonable optimization. . This package contains the shared low-level terminfo library. Homepage: http://invisible-island.net/ncurses/ I suppose the bug is in libtinfo5 shared library. Attempt to Backport libtinfo5 Library from Debian Buster OS === Downloaded source tar's from https://packages.debian.org/buster/libtinfo5: [ncurses_6.1+20181013-2+deb10u2.dsc] [ncurses_6.1+20181013.orig.tar.gz] [ncurses_6.1+20181013.orig.tar.gz.asc] [ncurses_6.1+20181013-2+deb10u2.debian.tar.xz] Attempt to build it first for Buster First try to build it under Debian Buster with pdebuild but I failed, autoconf did not create the configure script, it's missing when it was tried to invoke: debian/rules build dh_update_autotools_config dh_autoreconf autoreconf-dickey -- -f -i touch config.guess-stamp test -d /build/ncurses-6.1+20181013/obj || mkdir /build/ncurses-6.1+20181013/obj cd /build/ncurses-6.1+20181013/obj && ../configure \ --prefix=/usr
Bug#962090: Same Issue with a Python3 Project for Buster
> "pyversions" is part of package "python2-minimal". Why python2-minimal if I > build a Python3 project? "p3versions" is part of package "python3-minimal". But "/usr/share/perl5/Debian/Debhelper/Buildsystem/python_distutils.pm" calls the external script explicitly (`pyversions`) in line 124. "python_distutils.pm" should be updated for Python3 builds using "py3versions" - right? Notwithstanding, if I add "python2-minimal" package to my build dependencies the Python3 project will be built.
Bug#962090: Same Issue with a Python3 Project for Buster
-- cd /build/ehbackup-api-3.3.2+3+g6939d93~ui10/ && env PATH="/usr/lib/ccache:/usr/sbin:/usr/bin:/sbin:/bin" HOME="/nonexistent" dpkg-buildpackage -us -uc -d dpkg-buildpackage: info: source package ehbackup-api dpkg-buildpackage: info: source version 3.3.2+3+g6939d93~ui10 dpkg-buildpackage: info: source distribution UNRELEASED dpkg-buildpackage: info: source changed by EhBackup Team dpkg-buildpackage: info: host architecture amd64 dpkg-source --before-build . dpkg-source: info: using options from ehbackup-api-3.3.2+3+g6939d93~ui10/debian/source/options: --tar-ignore=build-bundle --tar-ignore=.git --tar-ignore=.gitignore debian/rules clean dh clean dh_auto_clean dh_auto_clean: warning: Please use the third-party "pybuild" build system instead of python-distutils dh_auto_clean: warning: This feature will be removed in compat 12. Can't exec "pyversions": No such file or directory at /usr/share/perl5/Debian/Debhelper/Buildsystem/python_distutils.pm line 124. dh_auto_clean: error: failed to run pyversions make: *** [debian/rules:9: clean] Error 255 dpkg-buildpackage: error: debian/rules clean subprocess returned exit status 2 -- "pyversions" is part of package "python2-minimal". Why python2-minimal if I build a Python3 project? My "Build-Depends" in "debian/control" file is: - Build-Depends: debhelper (>= 8.0.0), build-essential, python3-dev, libmysqlclient-dev | default-libmysqlclient-dev, python3-pip, python3-venv, libxml2-dev, libxslt1-dev, python3-sphinx, python3-setuptools X-Python3-Version: >= 3.7 -- Jürgen 0xA811F9F222306A1E.asc Description: application/pgp-keys
Bug#961660: DebHelper dh_bash-completion broken since Stretch OS, Bash Completion scripts not installed anymore into Path according to debian/.bash-completion
On Sun, 31 May 2020 15:00:46 -0300 "Gabriel F. T. Gomes"
wrote:
> On the other, you are saying that the completions do not work from this
> location, and that's puzzling me. Could you provide more details about
> the problem you are actually getting? Bash-completion is supposed to
> work with files in this location.
One detail is, if you invoke the program fsmtool2 or fsmtool2_mtest for which I
have the completion scripts, the directory listing of $PWD is shown if I press
TAB two times consecutively.
As another detail find attached the completion script.
Thanks
Jürgen
have fsmtool2 && {
_fsmtool2_commands() {
COMPREPLY=( $(compgen -W "help showconfig showfiles showfileslex deleteall"
-- $1) )
}
_fsmtool2()
{
local areas command cur
cur=${COMP_WORDS[COMP_CWORD]}
command=${COMP_WORDS[1]}
case $COMP_CWORD in
1)
_fsmtool2_commands $cur
;;
2)
case $command in
help)
_fsmtool2_commands $cur
;;
showconfig|showfiles|showfileslex|deleteall)
areas=$(grep '^\s*AREA' /etc/fsmd2/fsmd2.conf | awk '{print
$2}')
COMPREPLY=( $(compgen -W "$areas" -- $cur) )
;;
esac
;;
3)
case $command in
showfiles|showfileslex)
COMPREPLY=-n
;;
esac
;;
esac
}
complete -F _fsmtool2 fsmtool2
}
0xA811F9F222306A1E.asc
Description: application/pgp-keys
Bug#961660: DebHelper dh_bash-completion broken since Stretch OS, Bash Completion scripts not installed anymore into Path according to debian/.bash-completion
Package: bash-completion Version: 1:2.8-6 Severity: normal I have a project for which I build Debian installation packages with the help of pbuilder. The packages are built for Debian OS * Jessie * Stretch * Buster I have two different bash-completion scripts for two different command line tools for which I have two different installation path instruction files for each command line tool located in debian/: * debian/fsmd2-mtest.bash-completion * debian/fsmd2.bash-completion Inside that two installation instruction files we have the following lines: $ cat debian/fsmd2.bash-completion scripts/etc/bash_completion.d/fsmtool2-completion $ cat debian/fsmd2-mtest.bash-completion scripts/etc/bash_completion.d/fsmtool2_mtest-completion The completion scripts are located in the source tre as defined: $ ls -la scripts/etc/bash_completion.d/ total 16 drwxr-xr-x 2 pbuilder pbuilder 4096 May 18 15:26 . drwxr-xr-x 4 pbuilder pbuilder 4096 May 18 15:26 .. -rw-r--r-- 1 pbuilder pbuilder 933 May 18 15:26 fsmtool2-completion -rw-r--r-- 1 pbuilder pbuilder 980 May 18 15:26 fsmtool2_mtest-completion When I build the packages for Debian Jessie, everything works as expected, both completion scripts are installed into the path: $ ls -la /etc/bash_completion.d/ total 24 drwxr-xr-x 2 root root 4096 May 26 16:58 . drwxr-xr-x 92 root root 4096 May 18 12:12 .. -rw-r--r-- 1 root root 933 May 18 17:26 fsmtool2-completion -rw-r--r-- 1 root root 980 May 18 17:26 fsmtool2_mtest-completion When I build the packages for Debian OS Stretch or Buster, bash-completion does not work for both command line tools any more cause the completion scripts are installed below: * /usr/share/bash-completion/completions/fsmtool2-completion * /usr/share/bash-completion/completions/fsmtool2_mtest-completion I can reproduce it very easily without building the entire project by just invoking the dh_bash-completion helper in the source tree base directory: $ dh_bash-completion -v install -d debian/fsmd2/usr/share/bash-completion/completions installing scripts/etc/bash_completion.d/fsmtool2-completion as fsmtool2-completion install -p -m0644 ./scripts/etc/bash_completion.d/fsmtool2-completion debian/fsmd2/usr/share/bash-completion/completions/fsmtool2-completion installing scripts/etc/bash_completion.d/fsmtool2_mtest-completion as fsmtool2_mtest-completion install -p -m0644 ./scripts/etc/bash_completion.d/fsmtool2_mtest-completion debian/fsmd2-mtest/usr/share/bash-completion/completions/fsmtool2_mtest-completion 0xA811F9F222306A1E.asc Description: application/pgp-keys
Bug#939976: After unattended Upgrade of openssh-server from Release 1:7.4p1-10+deb9u6 to 1:7.4p1-10+deb9u7 no more Public Key Auth if 8K key is used
Package: openssh-server Severity: normal Tags: stretch Steps to Reproduce: 1) Have a Debian Stretch amd64 in place 2) Have the packages openssh-* of previous release 1:7.4p1-10+deb9u6 installed: apt install openssh-server=1:7.4p1-10+deb9u6 openssh-sftp-server=1:7.4p1-10+deb9u6 openssh-client=1:7.4p1-10+deb9u6 3) Have an 8k and a 16k ssh-key pair in place and install the public key on the test system 4) Login with the 8k private key: ssh -i /home/myhome/.ssh/id_rsa_8k Result: login successful with public key authentication 5) Login with the 16k private key: ssh -i /home/myhome/.ssh/id_rsa_16k Result: login successful with public key authentication 6) upgrade openssh-* packages to current release 1:7.4p1-10+deb9u7: apt install openssh-server=1:7.4p1-10+deb9u7 openssh-sftp-server=1:7.4p1-10+deb9u7 openssh-client=1:7.4p1-10+deb9u7 7) Login with the 8k private key: ssh -i /home/myhome/.ssh/id_rsa_8k Result: login fails: Permission denied (publickey). 8) 5) Login with the 16k private key: ssh -i /home/myhome/.ssh/id_rsa_16k Result: login successful with public key authentication Colleagues of mine use 4k key pairs which works fine with the current openssh-* release 1:7.4p1-10+deb9u7 Please have a look. Thank you, Jürgen
Bug#933957: AW: dh_installman.buster: Cannot find (any matches for) "/tmp/ehbackup/bkstool-add-client.1" (tried in .)
Hello Niels, thanks for quick help. > To be honest, I am surprised that worked in the past. My advice is to > stop using absolute paths in the debhelper config files[1]. It worked since December 2012! Since then code wasn't changed and it built For Debian Squeeze, Wheezy, Jessie, Stretch so far but not for Buster. > If you are very happy with using the absolute path, then it might work > if you pass it via command line. Alternatively, you can use > "bkstool-add-client.1" in the file and pass --sourcedir /tmp/ehbackup to > dh_instalman - I think that should work as well. These are also better > supported as people occasionally generate these paths via variables that > happen to use full path. No, I'll change the way you suggested, have the files for the manual pages inside the build directory and work with relative paths relative to the build directory. > Is there a particular reason that made you put that file in /tmp instead > of in a build directory inside the package source? The manual pages do not consist of static files from code repository, they are dynamically generated at build time. The developer who implemented it decided to create them in a temporary directory before they are processed furthermore. So that's the reason why he chose the "/tmp" directory but why outside the build directory, I have no idea. I updated the code, the man page files are now created in the "manpages/" inside the build directory. I think this is the place where they should be. After that, dh_installman worked without any options or workaround. Thank you again and I think you can close this ticket. Jürgen
Bug#933957: Works with symbolic link to /tmp in bild directory
If you create a smylink "ln -s /tmp ." in build directory (same dir level where "debian/" exists) it works with dh_installman from Buster distribution. -- Jürgen Kuri
Bug#933957: dh_installman.buster: Cannot find (any matches for) "/tmp/ehbackup/bkstool-add-client.1" (tried in .)
Package: debhelper
Version: 12.1.1
Hello,
$ dh_installman
dh_installman.buster: Cannot find (any matches for)
"/tmp/ehbackup/bkstool-add-client.1" (tried in .)
dh_installman.buster: Aborting due to earlier error
-
$ cat /etc/os-release
PRETTY_NAME="Debian GNU/Linux 10 (buster)"
NAME="Debian GNU/Linux"
VERSION_ID="10"
VERSION="10 (buster)"
VERSION_CODENAME=buster
ID=debian
HOME_URL="https://www.debian.org/;
SUPPORT_URL="https://www.debian.org/support;
BUG_REPORT_URL="https://bugs.debian.org/;
Looks like bug #903365.
$ strace -ff dh_installman reveals wrong path string:
read(3, "/tmp/ehbackup/bkstool-add-client"..., 8192) = 4188
lstat(".//tmp/ehbackup/bkstool-add-client.1", 0x7ffebc7f7c20) = -1 ENOENT (No
such file or directory)
lstat(".//tmp/ehbackup/bkstool-add-client.1", 0x5608717f2478) = -1 ENOENT (No
such file or directory)
lstat(".//tmp/ehbackup/bkstool-add-client.1", 0x7ffebc7f7c20) = -1 ENOENT (No
such file or directory)
write(2, "dh_installman: Cannot find (any "..., 96) = 96
Build of the same project works impeccably with Debian Stretch or Jessie but
not with Buster.
If I copy /usr/bin/dh_installman Perl script from Debian Stretch distribution
to my Buster build environment it works.
--
Jürgen Kuri
