Bug#1072622: UDD/bugs: Show forwarded status in table
Package: qa.debian.org Severity: wishlist User: qa.debian@packages.debian.org Usertags: udd Dear UDD team, could you please show the forwarded status of a bug in the bug summary table (perhaps as an additional column) and, if available, provide a clickable link to the forwarded URL? Thanks, -- Gioele Barabucci
Bug#1072621: UDD/bugs: Missing abbreviation for a11y
Package: qa.debian.org Severity: minor User: qa.debian@packages.debian.org Usertags: udd Dear UDD team, the "tags" column for bugs tagged with "a11y" (accessibility) is slightly broken: it just shows "[]". You can see an instance of this error in the row for bug #953591 at <https://udd.debian.org/bugs/?packages=bash=1>. Regards, -- Gioele Barabucci
Bug#1072613: RM: libnss-gw-name -- RoQA; abandoned upstream, unmaintained
Package: ftp.debian.org Severity: normal Control: affects -1 + src:libnss-gw-name User: ftp.debian@packages.debian.org Usertags: remove Dear FTP Masters, please remove the libnss-gw-name package: it has been RFA'd/orphaned since 2015 [1] and upstream development has ceased because this functionality is now integrated in systemd-resolved. In addition, this NSS module misbehaves if it enabled together with nss-resolve. A removal notice has been given in Debian bookworm's release notes. [2] No package in Debian Depends on libnss-gw-name; one package Recommends it and its maintainers have been informed of the upcoming removal. [3] [1] https://bugs.debian.org/805266 [2] https://www.debian.org/releases/stable/amd64/release-notes/ch-information.en.html#deprecated-components [3] https://bugs.debian.org/1069240 Regards, -- Gioele Barabucci
Bug#1072587: RM: ruby-filepath -- ROM; abandoned upstream, low popcon
Package: ftp.debian.org Severity: normal Control: affects -1 + src:ruby-filepath User: ftp.debian@packages.debian.org Usertags: remove Dear FTP Masters, the upstream developer (me) has abandoned the filepath Ruby gem. Most functionalities of this library have been integrated in Ruby 3. No package in Debian depends on this gem. Regards, -- Gioele Barabucci
Bug#1072332: dpkg-buildflags: CFLAGS_FOR_BUILD should match CFLAGS for native builds
On 03/06/24 01:24, Guillem Jover wrote: during native builds, dpkg-buildflags returns an empty CFLAGS_FOR_BUILD. The same happens for CPPFLAGS_FOR_BUILD, LDFLAGS_FOR_BUILD and other *_FOR_BUILD variables. Given that CFLAGS_FOR_BUILD is supposed to be used instead of CFLAGS (not _in addition to_ it), dpkg-buildflags should set CFLAGS_FOR_BUILD to CFLAGS, so that the same set of, say, hardening flags will be used. This was covered in <https://lists.debian.org/debian-dpkg/2023/11/msg00032.html>. The important part is that we cannot unconditionally set *_FOR_BUILD flags from the host ones or that would break with host specific ones. Right. This is also what I experienced when I tried to do that in d/rules. I guess we could special case the native build one and then copying them over, although this could incur build failures at this point in time. :/ Why should this lead to build failures? Support for _FOR_BUILD in dpkg-dev is new (not yet shipped in a stable release) and opt-in. In addition, there is only a handful of packages that explicitly deal with _FOR_BUILD variables [1], and pretty much of them use a variation of: export CFLAGS_FOR_BUILD = $(shell dpkg-architecture -f -a$(DEB_BUILD_ARCH) -c dpkg-buildflags --get CFLAGS) or: CFLAGS_FOR_BUILD="$(CFLAGS)" dh_auto_configure As long as this bug is not fixed, maintainers will have to add to d/rules something like (from [2]): ``` export DEB_BUILD_MAINT_OPTIONS = hardening=+all export DEB_CFLAGS_MAINT_APPEND = -Wall export CFLAGS CPPFLAGS LDFLAGS ifeq ($(DEB_BUILD_ARCH),$(DEB_HOST_ARCH)) # *_FOR_BUILD variables are not set for native builds, see #1072332. export CFLAGS_FOR_BUILD = $(CFLAGS) export CPPFLAGS_FOR_BUILD = $(CPPFLAGS) export LDFLAGS_FOR_BUILD = $(LDFLAGS) else export CFLAGS_FOR_BUILD CPPFLAGS_FOR_BUILD LDFLAGS_FOR_BUILD endif ``` This seems the kind of "knowledge" that is best dealt with in dpkg-dev. I guess this might be in the context of blhc? blhc was indeed what kick-started my research into _FOR_BUILD. Regards, [1] https://codesearch.debian.net/search?q=_FOR_BUILD+path%3Adebian%2Frules=1=1 [2] https://salsa.debian.org/gioele/bash/-/commit/011ebd44 -- Gioele Barabucci
Bug#1072520: bash: Update to debhelper 13; use standard dh sequence
Package: src:bash Version: 5.2.21-2 Tags: patch Dear bash maintainer, could you please update the bash packaging to debhelper compat 13 and make `debian/rules` use the standard dh sequence? You can find a set of patches at https://salsa.debian.org/gioele/bash/-/compare/shell-sh...rules-std-dh The updated `debian/rules` file is much shorter and simpler to follow compared to the current hand-written set of rules. `debian/rules` could be further improved and simplified. However this will lead to small changes in the resulting packages. diffoscope says that the binary packages generated using the proposed set of patch are identical to the current binary packages (except for unavoidable build ID changes in `.gnu_debuglink`). Please note that these patches build on the `nodoc`, `rrr-no` and `shell-sh` series related to <https://bugs.debian.org/1067150>, <https://bugs.debian.org/1067394> and <https://bugs.debian.org/1067400>. Regards, -- Gioele Barabucci
Bug#1072332: dpkg-buildflags: CFLAGS_FOR_BUILD should match CFLAGS for native builds
Package: dpkg-dev Version: 1.22.6 Dear dpkg maintaner, during native builds, dpkg-buildflags returns an empty CFLAGS_FOR_BUILD. The same happens for CPPFLAGS_FOR_BUILD, LDFLAGS_FOR_BUILD and other *_FOR_BUILD variables. Given that CFLAGS_FOR_BUILD is supposed to be used instead of CFLAGS (not _in addition to_ it), dpkg-buildflags should set CFLAGS_FOR_BUILD to CFLAGS, so that the same set of, say, hardening flags will be used. Regards, -- Gioele Barabucci
Bug#1055415: Wrong order for the `resolve' option in nsswitch.conf
On 26/05/24 16:11, Luca Boccassi wrote: See https://salsa.debian.org/systemd-team/systemd/-/merge_requests/162 I don't think anybody else here has the required knowledge to provide any more info than we already have. Gioele could you please make a recommendation and update the MR so that we can do something, one way or the other? My suggestion is: merge that PR, do not change `d/libnss-resolve.nss` (thus leaving `resolve` after `files`), close this bug. The original bug report requested: Specifically, it is recommended to place "resolve" early in /etc/nsswitch.conf's "hosts:" line. It should be before the "files" entry, since systemd-resolved supports /etc/hosts internally, but with caching. The post-MR hosts line will look like this: hosts: files myhostname mymachines resolve [!UNAVAIL=return] dns This sequence matches all suggestions in nss-myhostname(8), nss-mymachines(8), and nss-resolve(8), with the exception of > [resolve] should be before the "files" entry /etc/hosts is a "resolver of last resource". Having it behind a daemon is reasonable but it is a diversion from the status quo for which Debian is not ready IMO. Maybe in trixie+1. The above hosts line seems like the best compromise between enabling new functionality and preserving long established backstops. Regards, -- Gioele Barabucci
Bug#1071371: bash-builtins: Please add support for multiarch
On Sat, 18 May 2024 00:31:20 +0200 Gioele Barabucci
wrote:
the Makefiles and the pkgconfig file shipped in bash-builtins use
`/usr/lib` instead of `/usr/lib/${DEB_HOST_MULTIARCH}`.
Lintian warns about pkg-config-unavailable-for-cross-compilation:
> [...]
>
> Please install the file to /usr/lib/${DEB_HOST_MULTIARCH}/pkgconfig
> instead.
Maybe /usr/lib/pkgconfig/bash.pc could be dropped altogether, given that
1) it does not seem to be used by any other package,
2) it is not present in many other distros and
3) is also slightly broken.
Regards,
--
Gioele Barabucci
Bug#1071371: bash-builtins: Please add support for multiarch
Package: bash-builtins
Version: 5.2.21-2+b1
Severity: wishlist
User: crossbu...@debian.org
Usertags: cross
Dear bash maintainer,
the Makefiles and the pkgconfig file shipped in bash-builtins use
`/usr/lib` instead of `/usr/lib/${DEB_HOST_MULTIARCH}`.
Lintian warns about pkg-config-unavailable-for-cross-compilation:
The specified pkg-config(1) file is installed to /usr/lib/pkgconfig.
As the cross-compilation wrapper of pkg-config does not search this
directory the file is unavailable under cross-compilation.
Please install the file to /usr/lib/${DEB_HOST_MULTIARCH}/pkgconfig
instead.
Would it be possible to make the bash-builtins package multiarch-compatible?
Regards,
--
Gioele Barabucci
Bug#1071370: bash: Errors during generation of documentation files
Package: src:bash
Version: 5.2.21-2
Tags: ftbfs
Severity: minor
Dear bash maintainer,
some of the documentation files included in the bash-doc package
(bash.{html,pdf}, bashref.{html,pdf}) are taken directly from the
upstream tree and not recompiled from sources.
This is due to a couple of compilation errors are silently ignored:
```
/usr/bin/make -C build-bash/doc info html MAN2HTML=/usr/bin/man2html
make[1]: Entering directory '/<>/build-bash/doc'
make[1]: Nothing to be done for 'info'.
makeinfo --html --no-split -I../.././lib/readline/doc
../.././doc/bashref.texi
rluser.texi:2: warning: @setfilename after the first element
rm -f bash.html
/usr/bin/man2html ../.././doc/bash.1 | ../.././doc/htmlpost.sh > bash.html
man2html: Unknown operator �.
make[1]: Leaving directory '/<>/build-bash/doc'
/usr/bin/make -C build-bash/doc bash.pdf bashref.pdf
make[1]: Entering directory '/<>/build-bash/doc'
rm -f bash.ps
groff -I../.././doc -man ../.././doc/bash.1 > bash.ps
groff: error: couldn't exec grn: No such file or directory
make[1]: [Makefile:110: bash.ps] Error 4 (ignored)
rm -f bash.pdf
```
https://buildd.debian.org/status/fetch.php?pkg=bash=all=5.2.21-2=1701004303=1
Regards,
--
Gioele Barabucci
Bug#988981: dh-autoreconf: please switch autoconf to verbose mode
On Sat, 22 May 2021 14:53:36 +0200 Nicolas Boulenguez wrote:> The policy now recommends verbose logs unless DEB_BUILD_OPTIONS contains terse. By default, autoreconf does not say in which subdirectory it enters, which is quite inconvenient when debugging a failure. Please consider applying the attached patch. Dear dh-autoreconf maintainer, could you please consider applying Nicolas' patch? Alternatively, dh_autoreconf could call `autoreconf` with the `--verbose` parameter if DH_VERBOSE has been set. Regards, -- Gioele Barabucci
Bug#420752: bash: Ignores ENV and BASH_ENV
Control: tags -1 moreinfo
On Tue, 24 Apr 2007 14:56:08 +0100 Tony Houghton wrote:
I want to add ${HOME}/bin to my PATH for non-interactive shells as well
as interactive ones. I tried to do this by adding:
ENV=/etc/home_path
BASH_ENV=/etc/home_path
Hi,
for the record, ENV/BASH_ENV are used only in non-interactive shells:
When bash is started non-interactively, to run a shell script, for
example, it looks for the variable BASH_ENV in the environment,
expands its value if it appears there, and uses the expanded value
as the name of a file to read and execute.
(From the bash man page)
to /etc/environment and creating /etc/home_path:
#!/bin/sh
if [ -d "${HOME}/bin" ] && echo $PATH | grep -qv "${HOME}/bin" ; then
export PATH="${PATH}:${HOME}/bin"
fi
The (BASH_)ENV variables are being set, and /etc/home_path is readable
and executable by everyone, but bash never runs it (confirmed by adding
extra diagnostics as well as setting PATH).
BASH_ENV seems to work fine in bash 5.2.21-2.
$ echo "echo BASH_ENV executed; FOOBAR=baz" > /tmp/env
$ export FOOBAR=eee; BASH_ENV=/tmp/env bash -c 'echo $FOOBAR'
BASH_ENV executed
baz
/etc/environment is read only if the pam_env module is loaded. Maybe in
your system pam_env is not being loaded?
Regards,
--
Gioele Barabucci
Bug#666937: bash "source" not equivalent to "."
Version: 5.2.21-2
On Mon, 02 Apr 2012 20:11:36 +0200 Pawel Zaluski wrote:
However, when "." and "source" are used in ".bash_profile" each works
differently.
When runnning a sub-script, which uses "export" it works differently, depending
on whether "." (example C) or "source" (example D) is used.
-- START example C
pawel@debiann:~$ cat .bash_profile
.. /u01/app/oracle/product/11.2.0/xe/bin/oracle_env.sh
pawel@debiann:~$ cat /u01/app/oracle/product/11.2.0/xe/bin/oracle_env.sh
export ORACLE_HOME=/u01/app/oracle/product/11.2.0/xe
-- STOP example C
-- START example D
pawel@debiann:~$ cat .bash_profile
source /u01/app/oracle/product/11.2.0/xe/bin/oracle_env.sh
pawel@debiann:~$ cat /u01/app/oracle/product/11.2.0/xe/bin/oracle_env.sh
export ORACLE_HOME=/u01/app/oracle/product/11.2.0/xe
-- STOP example D
Hi,
this issue does not seem to affect version 5.2.21-2 of bash.
$ echo $VARVAR
$ echo "export VARVAR=foo" > /tmp/source
$ echo "source /tmp/source" >> ~/.profile
$ bash --login
$ echo $VARVAR
foo
$ exit
logout
$ sed -i ~/.profile -e 's_^source /tmp_. /tmp_'
$ bash --login
$ echo $VARVAR
foo
Please reopen this bug if you can still reproduce this issue.
Regards,
--
Gioele Barabucci
Bug#1069978: bash: incorrect value of $BASH for login shells
On 28/04/24 22:50, Chet Ramey wrote:
On 4/28/24 3:07 PM, Gioele Barabucci wrote:
$ su -l $USER -s /bin/bash-static -c 'echo $BASH; readlink
/proc/$$/exe; head -1z /proc/$$/cmdline; echo'
/bin/bash
/usr/bin/bash-static
-bash-static
So argv[0] == "-bash-static", which causes $0 to be set to -bash-static
and internally sets shell_name to "bash-static" and login_shell to 1
(which notes that bash was executed with argv[0][0] == '-').
Then when you get to setting $BASH, this code gets executed:
if ((login_shell == 1) && RELPATH(shell_name))
{
if (current_user.shell == 0)
get_current_user_info ();
name = savestring (current_user.shell);
}
which has been the way bash has behaved since the bash-1.x days. Is
this enough of an issue to change behavior that dates back that far?
The bash manual defines $BASH as follows:
Expands to the full filename used to invoke this instance of bash.
So, either the code or the manual should be changed.
I see why changing such an old behavior for the sake of correctness may
not be worth the risk of breaking somebody's workflow. But at the same
time it is hard to believe that anybody may be relying on "$BASH
contains the user shell set up in /etc/passwd when read from a login shell".
In my case, I intended to use $BASH to make sure that the right binary
was picked up by a certain test. I assume I'm not the only one using it
in that way.
Regards,
--
Gioele Barabucci
Bug#781212: bash: please document the different behaviour for FCEDIT
Control: found -1 5.2.21-2 On Thu, 26 Mar 2015 04:40:09 +0100 Christoph Anton Mitterer wrote: Debian seems to behave differently than upstream regarding the value of FCEDIT. This is fine, but could you please document it appropriately in the manpage? For the record, the difference referenced here is the default value of FCEDIT. d/patches/bash-default-editor.diff changes the default value of FCEDIT from `vi`, `ed`, `emacs` to `command -v editor`, with a fallback to `vi`, `ed`, `emacs`. -- Gioele Barabucci
Bug#1069978: bash: incorrect value of $BASH for login shells
On 28/04/24 20:01, Chet Ramey wrote: On 4/27/24 6:23 PM, Gioele Barabucci wrote: bash 5.0 and 5.2 do not set $BASH to the right value when bash is used as the login shell: $ apt install bash-static $ getent passwd $USER | cut -d: -f 7 /bin/bash $ su $USER -s /bin/bash-static -c 'echo $BASH; readlink /proc/$$/exe; true' /usr/bin/bash-static /usr/bin/bash-static $ su -l $USER -s /bin/bash-static -c 'echo $BASH; readlink /proc/$$/exe; true' /bin/bash /usr/bin/bash-static (bash-static is not a link to bash) What does `su' pass to bash in argv[0]? $ su $USER -s /bin/bash-static -c 'echo $BASH; readlink /proc/$$/exe; head -1z /proc/$$/cmdline; echo' /usr/bin/bash-static /usr/bin/bash-static bash-static $ su -l $USER -s /bin/bash-static -c 'echo $BASH; readlink /proc/$$/exe; head -1z /proc/$$/cmdline; echo' /bin/bash /usr/bin/bash-static -bash-static Regards, -- Gioele Barabucci
Bug#1069978: bash: incorrect value of $BASH for login shells
Package: bash Version: 5.2.21-2 X-Debbugs-CC: bug-b...@gnu.org Hi, bash 5.0 and 5.2 do not set $BASH to the right value when bash is used as the login shell: $ apt install bash-static $ getent passwd $USER | cut -d: -f 7 /bin/bash $ su $USER -s /bin/bash-static -c 'echo $BASH; readlink /proc/$$/exe; true' /usr/bin/bash-static /usr/bin/bash-static $ su -l $USER -s /bin/bash-static -c 'echo $BASH; readlink /proc/$$/exe; true' /bin/bash /usr/bin/bash-static (bash-static is not a link to bash) Bash also uses the value in /etc/passwd when in login mode, although the documentation says > BASH Expands to the full filename used to invoke this instance of bash. "full filename" could be interpreted both as "an absolute filename" as well as "the canonical absolute path". $ su $USER -s /bin/bash -c 'echo $BASH; readlink /proc/$$/exe; true' /usr/bin/bash /usr/bin/bash $ su -l $USER -s /bin/bash -c 'echo $BASH; readlink /proc/$$/exe; true' /bin/bash /usr/bin/bash Regards, -- Gioele Barabucci
Bug#588935: bash-static: warning: setlocale: LC_CTYPE: cannot change locale (en_US.UTF-8)
Version: 5.0-6 On Tue, 13 Jul 2010 17:10:39 +0200 "Raoul Bhatia [IPAX]" wrote: using bash-static as a login shell on debian squeeze. i want to "scp" a file cleanup.sh from this very machine to another one: > # scp cle resulting in: > # scp cle-bash-static: warning: setlocale: LC_CTYPE: cannot change locale (en_US.UTF-8) > -bash-static: warning: setlocale: LC_CTYPE: cannot change locale (en_US.UTF-8) > anup.sh auto complete works thou as you can see by the third line where bash-static adds "anup.sh" this does not happen if: 1. i use /bin/bash as a login shell, or 2. i start "bash-static" after login as a regular program. Hi, this issue does not seem to affect version 5.0-6 and later of bash. Please reopen this bug if you can still reproduce this issue. Regards, -- Gioele Barabucci
Bug#935905: bash: ":?xxx" filename broken on autocomplete
Control: found -1 5.2.21-2
On Tue, 27 Aug 2019 16:36:03 +0200 Philipp Marek
wrote:
the autocompletion is broken on filenames or directories with ":?" at the
beginning.
# mkdir ':?aa'
# rmdir :
gives me
# rmdir :\:\?
which doesn't match the filename; I can finish completion by entering "aa",
but then "rm" rejects this name.
In bash 5.2.21(1) the filename is now fully completed, but the stray ":"
at the beginning is still produced:
$ mkdir ':?aa'
$ rmdir :
$ rmdir :\:\?aa/
Regards,
--
Gioele Barabucci
Bug#1069324: gbp-export-orig does not take into account Files-Excluded
Package: git-buildpackage Version: 0.9.33 Dear git-buildpackage maintainer, tarballs generated by gbp-export-orig should not include files listed in the Files-Excluded stanza of d/copyright. mk-origtargz (called by uscan) respects this setting, so it and gbp-export-orig confusingly generate two different orig tarballs. Regards, -- Gioele Barabucci
Bug#1069240: freedombox: Deprecated libnss-gw-name in Recommends
Package: src:freedombox Version: 24.8 Dear freedombox maintainers, freedombox currently Recommends libnss-gw-name with the following justification: "Resolve gateway.localhost". However, «Development of the NSS service gw_name stopped in 2015. The associated package libnss-gw-name may be removed in future Debian releases. The upstream developer suggests using libnss-myhostname instead.» [1] Could you please remove libnss-gw-name and transition to libnss-myhostname? Also note that when systemd-resolved is in use, `gateway.localhost` will be resolved to 127.0.0.1/::1, in case the user's nsswitch.conf file specifies `resolve` before `gw_name`. [1] https://www.debian.org/releases/stable/amd64/release-notes/ch-information.en.html#deprecated-components Regards, -- Gioele Barabucci
Bug#973620: bash: overflow on integer variables greater than 9223372036854775807
Control: found -1 5.2.21-2
Control: tags -1 upstream
X-Debbugs-CC: bug-b...@gnu.org
On Mon, 2 Nov 2020 16:46:14 +0100 Antonio wrote:
Dear Maintainer,
recently while I was running some tests, I ran into this strange overflow:
$ declare -i n=9223372036854775800; for((i=0; i<15; ++i)); do echo "$i -> $n";
n+=1; done
0 -> 9223372036854775800
1 -> 9223372036854775801
2 -> 9223372036854775802
3 -> 9223372036854775803
4 -> 9223372036854775804
5 -> 9223372036854775805
6 -> 9223372036854775806
7 -> 9223372036854775807
8 -> -9223372036854775808
9 -> -9223372036854775807
10 -> -9223372036854775806
11 -> -9223372036854775805
12 -> -9223372036854775804
13 -> -9223372036854775803
14 -> -9223372036854775802
The integer handled by bash is obviously very large, but I believe
that in the event of an overflow it would be better to reset the
variable and issue an error flow warning, rather than remain silent.
Bash 5.2.21 is affected by this issue:
$ declare -i n=$((2**63 - 2))
$ for i in {1..4}; do echo "$i -> $n"; n+=1; done
1 -> 9223372036854775806
2 -> 9223372036854775807
3 -> -9223372036854775808
4 -> -9223372036854775807
$ declare -i n=36893488147419103234; echo $?
0
$ echo $n
2
Would it be possible to detect this overflow (or non-representable
numbers, like in the second case) and warn about it?
Regards,
--
Gioele Barabucci
Bug#780554: bash loses its mind and simply bails with "malloc: unknown:0: assertion botched"
Control: tags -1 moreinfo On Mon, 16 Mar 2015 02:03:35 +0100 =?utf-8?q?Christian_B=C3=B6hme?= wrote: Package: bash Version: 4.3-11+b1 Severity: important * What exactly did you do (or not do) that was effective (or ineffective)? assuming a new user identity via su, thereby starting a new interactive bash session, and entering the first command * What was the outcome of this action? bash bails with malloc: unknown:0: assertion botched malloc: block on free list clobbered last command: exit Aborting... leaving the terminal misconfigured in the process as well; note that there was no exit command given at all - bash made that up This does not seem to happen in Debian 12 with bash version 5.2.15-2. Can you still reproduce this issue? -- Gioele Barabucci
Bug#724461: bash: ulimit -T documented but doesn't work
Control: found -1 4.3-11+b1 Control: found -1 5.2.21-2 On Mon, 23 Sep 2013 18:58:20 -0700 Russ Allbery wrote: bash(1) under ulimit in shell built-ins claims: -T The maximum number of threads However, bash itself appears to disagree: wanderer:~$ ulimit -T bash: ulimit: -T: invalid option ulimit: usage: ulimit [-SHacdefilmnpqrstuvx] [limit] Bash 5.2.21-2 still fails, but at least the error message now mentions -T: $ ulimit -T -bash: ulimit: -T: invalid option ulimit: usage: ulimit [-SHabcdefiklmnpqrstuvxPRT] [limit] Regards, -- Gioele Barabucci
Bug#379696: ~/bin handled incorrectly in .bashrc and .bash_profile
Control: found -1 5.2.21-2 Control: tags -1 patch Bug #904930 contains a patch to fix this issue. [1] https://bugs.debian.org/904930
Bug#306043: bash executable completion doesn't work if there is a space in the executable path
Control: found -1 5.2.21-2
Control: tags -1 upstream
X-Debbugs-CC: bug-b...@gnu.org
On Sat, 23 Apr 2005 15:20:19 -0700 Frederik Eaton wrote:
Bash executable completion doesn't work if there is a space in the
executable path.
This issue is still partially present in current version of Bash.
The most basic case has been fixed:
$ touch "cmd with spaces"
$ chmod +x "cmd with spaces"
$ PATH=$PWD:$PATH
$ cmd
$ cmd\ with\ spaces
However there seems to be a linger issue that appears when multiple
commands with spaces match a given prefix:
$ touch "myfoo "{a,b,c}" command"
$ chmod +x "myfoo "{a,b,c}" command"
$ ls myfo*
'myfoo a command' 'myfoo b command' 'myfoo c command'
$ PATH=$PWD:$PATH
$ myf
$ myfoo\
$ myfoo\
No suggestions are shown after the double tab. Instead, double tabbing
should show all available commands matching the "myfoo " prefix:
$ myfoo\
myfoo a command myfoo b command myfoo c command
Regards,
--
Gioele Barabucci
Bug#344783: bash3: the random number generator seems to be reseeded when a subshell is created
Control: tags -1 wontfix
On Mon, 26 Dec 2005 09:39:07 + mr_platelet+m689
wrote:
I would expect the following command to always give the same output,
because I seed RANDOM at the outset:
bash3 -c 'RANDOM=1; set -x; true $RANDOM; true $RANDOM | true $RANDOM'
What I find in practise, however, is that, although the first line
printed is always the same, the next 2 lines are different on each run.
My guess is that a subshell is being created to run the pipeline, and
that bash, as part of its initialisation code for a subshell, seeds
RANDOM again, wiping out the seed I specified.
Bash holds its promise to provide a stable output once RANDOM is seeded
inside the same shell:
$ cmd='RANDOM=1; set -x; true $RANDOM; true $RANDOM | true $RANDOM;
true $RANDOM; true $RANDOM'
$ diff -u <(bash -c "$cmd" 2>&1) <(bash -c "$cmd" 2>&1)
--- /dev/fd/63
+++ /dev/fd/62
@@ -1,5 +1,5 @@
+ true 16807
-+ true 20358
-+ true 31354
++ true 8403
++ true 13062
+ true 10791
+ true 19566
As you noted, the evaluation of pipelines is a bit surprising, but the
documentation clearly states:
> Each command in a multi-command pipeline, where pipes are created, is
executed in a subshell, which is a separate process.
Exporting RANDOM does not help, but explicitly setting RANDOM inside
each subshell fixes this issue:
$ cmd='RANDOM=1; set -x; true $RANDOM; { RANDOM=3; true $RANDOM;} |
{ RANDOM=7; true $RANDOM;} ; true $RANDOM; true $RANDOM'
$ diff -u <(bash -c "$cmd" 2>&1) <(bash -c "$cmd" 2>&1) && echo same
same
Regards,
--
Gioele Barabucci
Bug#929178: bash: in a subshell trap displays the trap definition of main
Control: tags -1 wontfix The bash maintainer has confirmed in https://lists.gnu.org/archive/html/bug-bash/2024-03/msg00212.html that this behavior of trap is both intended and allowed by the spec, although other shell behave differently. Regards, -- Gioele Barabucci
Bug#781056: bash: undocumented deviation from upstream behaviour
Control: tags -1 moreinfo On Mon, 23 Mar 2015 22:12:18 +0100 Christoph Anton Mitterer wrote: Apparently there's some strange patch applied against the Debian version of bash, which allows suid scripts to be executed (isn't that a security issue?). Hi, why would that be a security issues? Executing suid scripts is just as dangerous as executing suid binaries. It also seems to invalidate that documented behaviour from the manpage: >If the shell is started with the effective user (group) id not equal to >the real user (group) id, and the -p option is not supplied, no startup >files are read, shell functions are not inherited from the environment, >the SHELLOPTS, BASHOPTS, CDPATH, and GLOBIGNORE variables, if they >appear in the environment, are ignored, and the effective user id is >set to the real user id. If the -p option is supplied at invocation, >the startup behavior is the same, but the effective user id is not >reset. So could you please either correct the behaviour or accordingly remove that documentation and add it to a secution of deviations between upstream and Debian? The documentation states what happens when bash acts as the interpreter for a suid script. Certain variables are cleared, some files are not read. Did you find that any of the described measures are not applied when running suid scripts? Regards, -- Gioele Barabucci
Bug#423207: bash builtins should not kill script when they get SIGPIPE
Control: tags -1 wontfix In https://lists.gnu.org/archive/html/bug-bash/2024-03/msg00201.html the bash maintainer stated that this behavior is intended and reflects the current consensus among POSIX shell implementations. See also https://www.austingroupbugs.net/view.php?id=789 Regards, -- Gioele Barabucci
Bug#929702: bash-builtins: Please add loadables 'rm' and 'cat'
Control: found -1 5.2.21-2 Control: tags -1 upstream On Wed, 29 May 2019 12:37:42 +0200 Tim Ruehsen wrote: Package: bash-builtins Version: 5.0-4 Severity: wishlist Dear Maintainer, as developer, I make use of the 'rm' and 'cat' bash loadables to speed up ./configure runs. Currently, I have to build my own bash + builtins because the package 'bash-builtins' does not contain these two builtins. To build them, you have to execute make target 'others' in examples/loadables, 'make -C examples/loadables others'. `rm` is now shipped in bash-builtins, `cat` isn't (it is still classified as OTHERPROG). Regards, -- Gioele Barabucci
Bug#681001: bash should handle scripts starting with BOM character
Here is a script to reproduce this scenario: $ printf '\xEF\xBB\xBF#!/bin/bash\necho hi\n' > /tmp/x.sh $ chmod +x /tmp/x.sh $ bash -c /tmp/x.sh /tmp/x.sh: line 1:_#!/bin/bash: No such file or directory hi
Bug#1059325: bash: printf does not recognise numeric constants with explicit base 10
Control: tags -1 moreinfo On Fri, 22 Dec 2023 15:12:12 +0100 Francesco =?utf-8?Q?Potort=C3=AC?= wrote: Package: bash Version: 5.2.21-2 Severity: normal X-Debbugs-Cc: none, Francesco Potortì $ bash --version GNU bash, version 5.2.21(1)-release (x86_64-pc-linux-gnu) Copyright (C) 2022 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software; you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. $ echo $((10#08)) 8 pot@pot:~$ printf %d\\n 10#08 bash: printf: 10#08: invalid number 10 This is clearly a bug: printf should print no error, and just print 8 followed by newline. The rules that apply to printf arguments are not the same rules that apply to $(( )). Here "10#08" is a plain string that is not interpreted at all by bash nor printf. Only inside $(( )) and a few other cases, "10#08" will be interpreted as the representation of a number in base 10 (this is a bashism, other shells do not do that). From ARITHMETIC EVALUATION in bash(1): The shell allows arithmetic expressions to be evaluated, under certain circumstances (see the let and declare builtin commands, the (( compound command, and Arithmetic Expansion).> [...] Integer constants follow the C language definition, without suffixes> or character constants. Constants with a leading 0 are interpreted as octal numbers. A leading 0x or 0X denotes hexadecimal. Otherwise, numbers take the form [base#]n, where the optional base is a decimal number between 2 and 64 representing the arithmetic base, and n is a number in that base. If base# is omitted, then base 10 is used. However, this only happens on one of my two boxes with Debian testing. The other one does not exhibit the bug, and printf just prints 8 followed by newline. That's interesting. What version of bash is installed in the other boxes? Regards, -- Gioele Barabucci
Bug#1029954: Problems with Bash
Control: tags -1 moreinfo On Sun, 29 Jan 2023 14:23:01 + Mcgiwer wrote: Package: Bash Version: any Affect's following OS: Debian / Ubuntu / AntiX Description: I wanted to report unintended bad behaviour of Bash that cause problems with usage of it. - no possibility to neither unset, nor remove the readonly bit from the read only variables - changes of value on some variables aren't beeing set or are sillently dropped - there seem be a issue with output redirection (it isn't always working). Example: I run a command that should output into a file, but instead of thay, it output's to stdout. Hi, you already filed bug 1010103 for the third issue. Could you please provide runnable commands that show the other two issues, including what results you expect? Regards, -- Gioele Barabucci
Bug#1010103: [Bug report] Bash: issues with redirecting output
Control: rename -1 bash: output redirection is ineffective
Control: tags -1 moreinfo
On Sun, 24 Apr 2022 14:12:34 + Mcgiwer wrote:
Package: bash
Serverity: serious
OS: Debian 11
Description:
I had found a strange issue in Bash: there is a problem with redirecting the
output of some commands when executing them in the console.
I had attempted all variants (wroten as a template):
\`\`\`
\* command > file.txt
\* command >> file.txt
\* command 1> file.txt
\* command 2> file.txt
\* command 3> file.txt
\* command &> file.tx
\* command \| tee file.txt
\`\`\`
In every case the output was shown in the console and the file remained empty.
Could anyone check what's wrong?
I had tested it on:
\`\`\`
apt update \| grep "NO\_PUBKEY"
\`\`\`
Dear Mcgiwer,
is the command you tried to run
$ apt update | grep "NO_PUBKEY" > file.txt
?
In this case, the redirection mechanism was working like expected: what
you are redirecting is the output of the last command, not of the whole
pipeline. So the warnings printed on stderr by apt will never be
redirected and will appear in your console.
If you want to redirect the collective output of all commands in a
pipeline you can use
$ { cmd1 | cmd2 ; } > file.txt
Regards,
--
Gioele Barabucci
Bug#1067480: hostname: fails to change host name inside container; misleading message "you must be root to change the host name" while root
Package: hostname Version: 3.23+nmu1 Dear hostname maintainer, `hostname` fails to set the host name when run inside a container. After it fails it states "you must be root to change the host name" even if called by root. To reproduce: $ sudo podman image pull debian:bookworm Trying to pull docker.io/library/debian:bookworm... [...] $ sudo podman run debian:bookworm bash -c 'whoami; hostname a.b.c' root hostname: you must be root to change the host name Regards, -- Gioele Barabucci
Bug#822605: bash: SIGPIPE not handled, terminates shell
Control: retitle -1 bash: SIGPIPE not handled, terminates shell Control: found -1 5.2.21-2 Bash 5.2.21 still exhibits this issue, the subshell terminates once a SIGPIPE is received: (shell1)$ rm -f /tmp/f && mkfifo /tmp/f && (i=0; while true; do echo $((i=i+1)) > /tmp/f; done); echo "terminated with exit status $?" (shell2)$ while true; do echo $(< /tmp/f); done The command in shell1 will output "terminated with exit status 141". For the record, dash 0.5.12 has the same behavior. Regards, -- Gioele Barabucci
Bug#1067400: bash should build with standard shell
Package: src:bash Version: 5.2.21-2 Tags: patch Dear bash maintainer, currently d/rules sets "SHELL = /bin/bash". This may create problems during bootstrapping. Please find a at https://salsa.debian.org/gioele/bash/-/compare/rrr-no...shell-sh a couple of small commits that remove this limitation and get rid of the few bashisms present in d/rules. With these changes bash builds just fine with dash. Please note that these commits build on the rrr-no series related to . Diffoscope shows no changes in the generated binaries. Regards, -- Gioele Barabucci
Bug#421591: bash: test builtin (or [) does not behave correctly
found 421591 5.2.21-2 thanks On Mon, 11 Feb 2008 13:20:25 +0100 Vincent Lefevre wrote: As a summary, the following test at least does not behave correctly: vlefevre@vin:~$ test \( ! -e \) ; echo $? bash: test: `)' expected 2 And I think this one is also buggy: vlefevre@vin:~$ test true -a \( ! -a \) ; echo $? bash: test: `)' expected 2 FYI, the coreutils and zsh test utility both output 1 on these tests; so does dash on the second one only. In bash 5.2.21-2 the first invocation behaves correctly: $ test \( ! -e \) ; echo $? 1 but the second is still broken: test true -a \( ! -a \) ; echo $? -bash: test: `)' expected 2 -- Gioele Barabucci
Bug#1067394: bash: Support for Rules-Requires-Root: no
Package: src:bash Version: 5.2.21-2 Tags: patch Dear bash maintainer, please find at https://salsa.debian.org/gioele/bash/-/compare/nodoc...rrr-no a series of commits that enable `Rules-Requires-Root: no` and implement all the minor but necessary changes to d/rules needed to support it. Please note that the commits rely on the simplification work done to support the profile and reported in <https://bugs.debian.org/1067150>. Regards, -- Gioele Barabucci
Bug#1067150: bash: FTBFS when building with
Package: src:bash Version: 5.2.21-2 Tags: patch ftbfs Dear bash maintainer, bash fails to build when the profile is active: /bin/bash: line 1: cd: debian/bash-doc/usr/share/doc/bash/examples: No such file or directory Additionally, bash still Build-Depends on texinfo, ghostscript and other utils related to the creation of documentation files (info and man pages, bashref) even when the profile is active. You can find a series of commits that fix these issues and enable full support for the profile at: https://salsa.debian.org/gioele/bash/-/compare/debian%2Fsid...nodoc diffoscope shows that these changes have no impact at all on the generated binary packages when is not active. Regards, -- Gioele Barabucci
Bug#1032366: bts --smtp-host=reportbug.d.o fails with "certificate verify failed"
Version: 2.23.7 This issue does not occur anymore with 2.23.7 and the current setup of reportbug.d.o. Regards, -- Gioele Barabucci
Bug#1049943: wrap-and-sort: always place the build-system packages (e.g., debhelper-compat) first
Control: tags + patch Dear devscripts maintainers, please find a MR that implements this feature (placing build-system packages such as "debhelper-compat" first) at https://salsa.debian.org/debian/devscripts/-/merge_requests/392 Regards, -- Gioele Barabucci
Bug#1065347: Outdated VCS for dnsmasq packaging
Package: src:dnsmasq Version: 2.90-2 Tags: patch X-Debbugs-CC: debma...@g-e-u-e-r.de Dear dnsmasq maintainer, the VCS headers in d/control still point to the upstream Git repository, but that repository no longer contains the debian/ directory. Could you please update the d/control to point to the new repository URLs? BTW, given that now the debian packaging is separate, could you please move it to salsa.debian.org, so to simplify sending merge requests and allowing the use of the Salsa-CI pipeline? Regards, --- control | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/control b/control index 27d5c8e..3dd8e7d 100644 --- a/control +++ b/control @@ -8,8 +8,8 @@ Build-Depends: dh-exec, gettext, libnetfilter-conntrack-dev [linux-any], pkg-config, libnftables-dev Maintainer: Simon Kelley Homepage: https://www.thekelleys.org.uk/dnsmasq/doc.html -Vcs-Git: https://thekelleys.org.uk/git/dnsmasq.git -Vcs-Browser: https://thekelleys.org.uk/gitweb/?p=dnsmasq.git +Vcs-Git: https://thekelleys.org.uk/git/dnsmasq-debian.git +Vcs-Browser: https://thekelleys.org.uk/gitweb/?p=dnsmasq-debian.git Standards-Version: 4.6.2 Rules-Requires-Root: no -- Gioele Barabucci
Bug#829444: Use DEP14 branch layout by default
On Fri, 5 Jan 2024 16:44:03 +0100 Guido =?iso-8859-1?Q?G=FCnther?=
wrote:
What we need to figure out is a way to distinguish "old" style
repos (default upstream and master (or what gbp.conf provides) with
newly created ones (default debian/latest and upstream/latest or what
gbp.conf provides).
Likely the best way to do so is to add a `gbp.conf` option:
`layout = [legacy|dep14]`
defaulting to `legacy` if unset.
Another possibility would be to check which branch exist and understand
what is the intended layout. debian-janitor does that.
Pseudo-code:
if branches.include?("debian/latest", "upstream/latest"):
layout = dep14-2020
if branches.include?("debian/master"):
layout = dep14-2014
else:
layout = legacy
Obviously this must be tweaked to take into account branch names set via
gbp.conf.
Regards,
--
Gioele Barabucci
Bug#1030668: dinstall could run more often (every hour?)
Control: tag -1 - moreinfo On Mon, 06 Feb 2023 20:45:30 +0100 Ansgar wrote: > > Not sure what you mean. Can you please explain the workflow you > > are talking about? > > The linked Michale Stapelberg's blog post explains it better than I > can: > > https://michael.stapelberg.ch/posts/2019-03-10-debian-winding-down/#old-infrastructure-package-uploads That sounds like Michael didn't know about incoming.d.o which has been publically accessible since 2014[1]. [1]: https://lists.debian.org/debian-devel-announce/2014/08/msg8.html Please explain what issues you have that are not solved by using incoming.d.o. Not all services fetch their packages from incoming.d.o, for example britney. So perhaps a way to alleviate this problem is to ask all official services to use incoming.d.o in addition to the regular unstable archive. Regards, -- Gioele Barabucci
Bug#1060209: libopenzwave1.6 install hundreds of data files and images in /etc
Package: libopenzwave1.6 Version: 1.6.1914+ds-1 Severity: minor libopenzwave1.6 currently installs 1489 in /etc, including 635 PNG images, 9 JPEG images, and 1 Zip file. These files are obviously not conffiles but are treated as such. Could they be moved under /usr, for example under /usr/share/openzwave? Regards, -- Gioele Barabucci
Bug#1059363: gbp-import-dsc crashes when changelog contains leap seconds ("Sun, 1 Jan 2006, 00:59:60 +0100")
On 30/12/23 11:27, Guido Günther wrote:
from gbp.git.modifier import GitModifier # noqa: F401
@@ -41,7 +42,11 @@ def rfc822_date_to_git(rfc822_date, fuzzy=False):
>>> rfc822_date_to_git('So, 26 Feb 1998 8:50:00 +0100', fuzzy=True)
'888479400 +0100'
"""
+rfc822_date_orig = rfc822_date
+rfc822_date = rfc822_date.replace(":60 ", ":59 ")
d = dateutil.parser.parse(rfc822_date, fuzzy=fuzzy)
+if rfc822_date != rfc822_date_orig: # Handle leap seconds.
+d += datetime.timedelta(seconds=1)
That works. Could you add a line to the doctest in that function too so
we check for and don't break it on accident again. Otherwise I can do it
when applying the patch.
Hi Guido, I'll be happy to leave the doctest to you. :)
Thanks for accepting the patch.
PS: Beware: the indentation may be wrong.
Regards,
--
Gioele Barasbucci.
Bug#1059579: unicode: Package does not use standard dh sequence/dh-sequence-python3
Package: src:unicode Tags: patch Dear unicode maintainer, this package currently uses debhelper with an ad-hoc sequence of steps in d/rules. This long list of steps can be shortened and greatly simplified by using the standard dh sequence and the modern dh-sequence-python3, as recommended by Debian policy section 4.9. You can find a series of patches that update the packaging of `unicode` to debhelper 13 and to the standard dh sequence at https://salsa.debian.org/gioele/unicode/-/compare/upstream-info...dh-13 Regards, -- Gioele Barabucci
Bug#1059577: unicode: Missing d/watch file and upstream information
Package: src:unicode Tags: patch Dear unicode maintainer, the package does not currently contain a debian/watch file that uscan can use to automatically detect new releases. It also does not contain information about upstream URLs such as its homepage and where to report bugs. You can find a patch to adds a d/watch file as well as upstream metadata as the last commit of the branch https://salsa.debian.org/gioele/unicode/-/commits/upstream-info Regards, -- Gioele Barabucci
Bug#1059575: unicode: DEP-14 compliant VCS repository (with all past Debian releases)
Package: src:unicode Tags: patch Dear unicode maintainer, you can find a DEP-14-compliant git repository with the history of the unicode package at https://salsa.debian.org/gioele/unicode Could you please adopt it as the reference git repository for the Debian packaging of unicode (not as the upstream repo) by forking the repo on salsa.d.o, and then using "Settings" → "General" → "Remove fork relationship"? Alternatively I could help moving it to the debian/ shared namespace on salsa.debian.org, if your prefer that. Regards, -- Gioele Barabucci
Bug#1059395: libacl1, debhelper: changelog not detected as binNMU
Control: tags -1 - moreinfo
Control: tags -1 + patch
Control: retitle -1 debhelper: binNMU changelog not created w/ --no-trim
On 26/12/23 13:19, Sven Joachim wrote:
On 2023-12-26 12:34 +0100, Gioele Barabucci wrote:
This binNMU changelog entry would normally be separated into
changelog.Debian.${DEB_HOST_ARCH}.gz, as can be seen in
/usr/share/doc/libxext6/ at the time of writing.
dh_installchangelogs still has the same behavior as before when it
comes to binNMU and their arch-specific changelogs, independent of the
trimming logic.
That is not the case, AFAICS. This is what you installed in commit
af652db00:
Thanks Sven for the analysis, you're right.
A fix for this issue is available at
https://salsa.debian.org/debian/debhelper/-/merge_requests/117
Regards,
--
Gioele Barabucci
Bug#1059395: libacl1, debhelper: changelog not detected as binNMU
Control: tags -1 moreinfo
Control: retitle -1 libacl1, debhelper: changelog not detected as binNMU
On Sun, 24 Dec 2023 14:27:22 + Simon McVittie wrote:
libacl1 was recently binNMU'd on all architectures to address version skew.
Unfortunately, the binNMU'd version is no longer multiarch co-installable
because its changelog differs between architectures:
│ │ ├── ./usr/share/doc/libacl1/changelog.Debian.gz
│ │ │ ├── changelog.Debian
│ │ │ │ @@ -1,13 +1,13 @@
│ │ │ │ acl (2.3.1-3+b1) sid; urgency=low, binary-only=yes
│ │ │ │
│ │ │ │ - * Binary-only non-maintainer upload for amd64; no source changes.
│ │ │ │ + * Binary-only non-maintainer upload for i386; no source changes.
│ │ │ │* Rebuild to sync binNMU versions
│ │ │ │
│ │ │ │ - -- all / amd64 / i386 Build Daemon (x86-conova-01) ...
│ │ │ │ + -- i386 Build Daemon (x86-grnet-01) ...
This binNMU changelog entry would normally be separated into
changelog.Debian.${DEB_HOST_ARCH}.gz, as can be seen in
/usr/share/doc/libxext6/ at the time of writing.
dh_installchangelogs still has the same behavior as before when it comes
to binNMU and their arch-specific changelogs, independent of the
trimming logic.
What seems to have happened here is that the binNMU detection failed.
The binNMU detection is (and has always been) "the string
`binary-only=yes` appears in the first line of the changelog".
```
if (($. == 1) && ($line =~ /\A\S.*;.*\bbinary-only=yes/)) {
$is_binnmu = 1;
}
```
Please attach the changelog of the binNMU, so that it is possible to
debug why the binNMU detection logic failed in this case.
Regards,
--
Gioele Barabucci
Bug#1059363: gbp-import-dsc crashes when changelog contains leap seconds ("Sun, 1 Jan 2006, 00:59:60 +0100")
Control: tags -1 patch
Hi Guido,
On 23/12/23 16:57, Guido Günther wrote:
the gbp-import-dsc script crashes while parsing changelogs that include leap
seconds.
dateutil.parser._parser.ParserError: second must be in 0..59: Sun, 1 Jan
2006 00:59:60 +0100
This looks like a bug in dateutil, can you reassign there?
Not really:
As of 2023-12 there is an open issue asking for support for leap seconds in
dateutils [3].
That issue has been open for almost three years. The dateutils
developers say that Python's datetime does not handle leap seconds, so
they are not going to mess around with it.
In order to deal with Debian policy's request to support :60,
application-level workarounds are needed.
Please find attached a small patch that fix this issue.
Regards,
--
Gioele BarabucciFrom 5dd36d1a7ed44f7cd10eb7afeb58e6c747558e91 Mon Sep 17 00:00:00 2001
From: Gioele Barabucci
Date: Sat, 23 Dec 2023 17:03:39 +0100
Subject: [PATCH] git: rfc822_date_to_git: Handle leap seconds
Closes: #1059363
---
gbp/git/__init__.py | 5 +
1 file changed, 5 insertions(+)
diff --git a/gbp/git/__init__.py b/gbp/git/__init__.py
index 3d0bb0b9..773ba822 100644
--- a/gbp/git/__init__.py
+++ b/gbp/git/__init__.py
@@ -17,6 +17,7 @@
"""Accessing Git from python"""
import calendar
+import datetime
import dateutil.parser
from gbp.git.modifier import GitModifier # noqa: F401
@@ -41,7 +42,11 @@ def rfc822_date_to_git(rfc822_date, fuzzy=False):
>>> rfc822_date_to_git('So, 26 Feb 1998 8:50:00 +0100', fuzzy=True)
'888479400 +0100'
"""
+rfc822_date_orig = rfc822_date
+rfc822_date = rfc822_date.replace(":60 ", ":59 ")
d = dateutil.parser.parse(rfc822_date, fuzzy=fuzzy)
+if rfc822_date != rfc822_date_orig: # Handle leap seconds.
+d += datetime.timedelta(seconds=1)
seconds = calendar.timegm(d.utctimetuple())
tz = d.strftime("%z")
return '%d %s' % (seconds, tz)
--
2.43.0
Bug#1059363: gbp-import-dsc crashes when changelog contains leap seconds ("Sun, 1 Jan 2006, 00:59:60 +0100")
Package: git-buildpackage
Version: 0.9.33
Dear git-buildpackage maintainer,
the gbp-import-dsc script crashes while parsing changelogs that include
leap seconds.
For example, while parsing the changelog of unicode/5.0, gbp-import-dsc
crashes with
```
File "/usr/lib/python3/dist-packages/gbp/scripts/import_dsc.py", line
116, in get_author_from_changelog
date = rfc822_date_to_git(dch.date, fuzzy=True)
File "/usr/lib/python3/dist-packages/gbp/git/__init__.py", line 44,
in rfc822_date_to_git
d = dateutil.parser.parse(rfc822_date, fuzzy=fuzzy)
^^^
File "/usr/lib/python3/dist-packages/dateutil/parser/_parser.py",
line 1368, in parse
return DEFAULTPARSER.parse(timestr, **kwargs)
^^
File "/usr/lib/python3/dist-packages/dateutil/parser/_parser.py",
line 651, in parse
six.raise_from(ParserError(str(e) + ": %s", timestr), e)
File "", line 3, in raise_from
dateutil.parser._parser.ParserError: second must be in 0..59: Sun, 1
Jan 2006 00:59:60 +0100
```
Leap seconds (:60) are explicitly permitted by Debian Policy [1] and RFC
5322 [2] and produced by `date -R`.
As of 2023-12 there is an open issue asking for support for leap seconds
in dateutils [3].
A possible solution to this issue, suggested by olasd, would to parse
the date using the stdlib method `email.utils.parsedate_tz` and handle
the leap seconds manually:
```
import email, datetime
add_leap_second = False
dateinfo = list(email.utils.parsedate_tz(rfc822_date))
if dateinfo[5] == 60:
dateinfo[5] = 59
add_leap_second = True
date = datetime.datetime(*dateinfo[:6])
if add_leap_second:
date += datetime.timedelta(seconds=1)
```
Alternatively:
```
dhc_date = dch.date.replace(":60 ", ":59 ")
date = rfc822_date_to_git(dch.date, fuzzy=True)
if dch_date != dch.date:
date += datetime.timedelta(seconds=1)
```
Regards,
[1] «ss is the two-digit seconds (00-60)»
https://www.debian.org/doc/debian-policy/ch-source.html#s-dpkgchangelog
[2] «the time-of-day MUST be in the range 00:00:00 through 23:59:60 (the
number of seconds allowing for a leap second; see [RFC1305])»
https://datatracker.ietf.org/doc/html/rfc5322#section-3.3
[3] https://github.com/dateutil/dateutil/issues/1018
--
Gioele Barabucci
Bug#1059238: cpio-win32 is no longer needed
Package: src:cpio Version: 2.13+dfsg-7.1 Dear cpio maintainers, you can stop building the binary package cpio-win32. `debian-installer` stopped depending on cpio-win32 in 2019. It has since been removed from the list of build dependencies. See commit https://salsa.debian.org/installer-team/win32-loader/-/commit/a0c59b24 . No packages depend nor build-depend on cpio-win32. Regards, -- Gioele Barabucci
Bug#1013868: nfs-common: Split between Python scripts to separate package
Control: tags -1 patch Control: retitle -1 nfs-common makes Python required on NFS clients On Fri, 25 Aug 2023 16:58:33 +0200 Gioele Barabucci wrote: > > could you please move the three Python scripts included in nfs-common to > > a separate -extras package? > > We can remove nfsconvert.py and revisit this after the bookworm > release. now that nfsconvert.py has been removed (thanks!) [1], do you think it would be possible to move these Python scripts to a separate package? Hi, you can find a MR that moves the Python scripts to a separate package at https://salsa.debian.org/kernel-team/nfs-utils/-/merge_requests/29 Regards, -- Gioele Barabucci
Bug#1058785: poppler-data: Repo on salsa.d.o lacks recent packages (0.4.10-1, 0.4.11-1, 0.4.12-1)
Package: src:poppler-data Version: 0.4.10-1 Control: found -1 0.4.11-1 Control: found -1 0.4.12-1 Dear poppler-data maintainer, the poppler-data repository on salsa.d.o is stuck at version 0.4.9-2 (May 2018, commit 050e1ba7) and does not currently contain the commits related the Debian packages that you have released in the meantime: 0.4.10-1, 0.4.11-1, and 0.4.12-1. Could you please push the missing commits to salsa.d.o? Kind regards, -- Gioele Barabucci
Bug#1058037: gzip fails to build due to outdated patch
Package: src:gzip Tags: ftbfs patch Dear gzip maintainers, the current VCS repo of gzip (fa4d2086) fails to build due to an outdated patch that no longer applies cleanly: ``` dpkg-source: info: using patch list from debian/patches/series patching file doc/gzip.texi Hunk #1 FAILED at 9. 1 out of 1 hunk FAILED dpkg-source: info: the patch has fuzz which is not allowed, or is malformed dpkg-source: info: if patch 'gzip_reproducible_build.diff' is correctly applied by quilt, use 'quilt refresh' to update it dpkg-source: info: if the file is present in the unpacked source, make sure it is also present in the orig tarball dpkg-source: error: LC_ALL=C patch -t -F 0 -N -p1 -u -V never -E -b -B .pc/gzip_reproducible_build.diff/ --reject-file=- < source_dir.orig.icZoT6/debian/patches/gzip_reproducible_build.diff subprocess returned exit status 1 dpkg-buildpackage: error: dpkg-source -b . subprocess returned exit status 2 ``` You can find a fix for this issue as the last commit of the branch <https://salsa.debian.org/gioele/gzip/-/tree/refresh-repro-patch>. PS: could you please enable merge requests on salsa.d.o? It would greatly simplify sending patches. Regards, -- Gioele Barabucci
Bug#1058033: poppler-data: CMap symlinks should be in /usr instead of /var
Package: poppler-data Version: 0.4.12-1 Dear poppler-data maintainers, currently the poppler-data package ships around 250 symlinks that are needed so that ghostscript can access the same CMap files as poppler. These symlinks are however in /var/. /var is supposed to be used for variable system data and not for normal package-supplied static resources. Fedora's ghostscript package, for instance, puts these symlinks in /usr/share/ghostscript/Resource/CMap/. Could you please update d/links so that the links are created under /usr instead of /var? Regards, [1] https://src.fedoraproject.org/rpms/ghostscript/blob/f39/f/ghostscript.spec#_325 -- Gioele Barabucci
Bug#1053399: ITP: fonts-albert-sans
Control: block -1 by 1013213 The initial WIP packaging can be found at <https://salsa.debian.org/gioele/fonts-albert-sans> (the repo will be moved to fonts-team once ready). The packaging work is currently blocked by the lack of a recent enough version of gftools, see #1013213. Regards, -- Gioele Barabucci
Bug#1057233: pipewire-bin: installs files into /lib/udev/rules.d
Upstream pipewire now (post 1.0) defaults to /usr/lib/udev/rules.d. So if no backports are planned for oldstable (Debian 11, bullseye), just waiting for a new pipewire release will be enough and no changes to d/rules are needed to fix this bug. Regards, -- Gioele Barabucci
Bug#1057250: coreutils: Unnecessary postinst maintscript
Package: src:coreutils Version: 9.4-2 Severity: minor Dear coreutils maintainers, the postinst maintscript of coreutils can be completely dropped: it contains a single command and the guard condition is always false. ``` if [ "$1" = 'configure' -a ! -e "$DPKG_ROOT/usr/bin/touch" ]; then ln -s /bin/touch "$DPKG_ROOT/usr/bin/touch" fi ``` The guard condition is always false because `/usr/bin/touch` is assured to exist since bookworm. Regards, -- Gioele Barabucci
Bug#1057136: coreutils: Support for build profile
Package: src:coreutils Version: 9.4-2 Tags: patch Dear coreutils maintainers, the coreutils package is affected by three issues related to the profile: 1. Even when the build profile is used, `texinfo` remains a required build dependency. 2. Certain documentation files are also kept in the package because they are not handled by dh_installdocs but via ad-hoc commands in d/rules. 3. coreutils Build-Depends on `groff` but `groff` is not used by the build process. Please find attached three patches that fix all these issues and add support for the build profile. Regards, -- Gioele BarabucciFrom 0a040804acf78e6e2fbe63610a6ff8b3aad5d880 Mon Sep 17 00:00:00 2001 From: Gioele Barabucci Date: Wed, 29 Nov 2023 22:49:53 +0100 Subject: [PATCH 1/3] d/control: Removed unused groff dependency groff is not used during the build process --- debian/control | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/debian/control b/debian/control index d4f4a69a..67bd9aaf 100644 --- a/debian/control +++ b/debian/control @@ -3,7 +3,7 @@ Maintainer: Michael Stone Section: utils Priority: required Standards-Version: 4.5.0 -Build-Depends: gettext (>= 0.10.37), debhelper-compat (= 13), texinfo (>= 4.2), groff, libattr1-dev [linux-any], libacl1-dev [linux-any], libselinux1-dev (>= 1.32) [linux-any], gperf, bison, libgmp3-dev, libssl-dev [linux-amd64] +Build-Depends: gettext (>= 0.10.37), debhelper-compat (= 13), texinfo (>= 4.2), libattr1-dev [linux-any], libacl1-dev [linux-any], libselinux1-dev (>= 1.32) [linux-any], gperf, bison, libgmp3-dev, libssl-dev [linux-amd64] Package: coreutils Architecture: any -- 2.42.0 From 529dadbe67366cf5b92c5cb5ea87bc739189bb3a Mon Sep 17 00:00:00 2001 From: Gioele Barabucci Date: Wed, 29 Nov 2023 22:49:55 +0100 Subject: [PATCH 2/3] d/coreutils.docs: Install extra documentation using dh_installdocs --- debian/coreutils.docs | 5 + debian/rules | 7 --- 2 files changed, 5 insertions(+), 7 deletions(-) create mode 100644 debian/coreutils.docs diff --git a/debian/coreutils.docs b/debian/coreutils.docs new file mode 100644 index ..04303916 --- /dev/null +++ b/debian/coreutils.docs @@ -0,0 +1,5 @@ +AUTHORS +NEWS +README +THANKS +TODO diff --git a/debian/rules b/debian/rules index 3e14f8e7..619f2e4e 100755 --- a/debian/rules +++ b/debian/rules @@ -66,10 +66,3 @@ endif # some build environments will leave a dangling info dir rm -f $(d)/usr/share/info/dir - - cp AUTHORS \ - NEWS README \ - THANKS \ - TODO \ - $(d)/usr/share/doc/coreutils - -- 2.42.0 From 5c4f7cd755c2a0acd1504619e7912acee418d284 Mon Sep 17 00:00:00 2001 From: Gioele Barabucci Date: Wed, 29 Nov 2023 22:49:55 +0100 Subject: [PATCH 3/3] Support build profile --- debian/control | 2 +- debian/rules | 10 ++ 2 files changed, 11 insertions(+), 1 deletion(-) diff --git a/debian/control b/debian/control index 67bd9aaf..2e408e2b 100644 --- a/debian/control +++ b/debian/control @@ -3,7 +3,7 @@ Maintainer: Michael Stone Section: utils Priority: required Standards-Version: 4.5.0 -Build-Depends: gettext (>= 0.10.37), debhelper-compat (= 13), texinfo (>= 4.2), libattr1-dev [linux-any], libacl1-dev [linux-any], libselinux1-dev (>= 1.32) [linux-any], gperf, bison, libgmp3-dev, libssl-dev [linux-amd64] +Build-Depends: gettext (>= 0.10.37), debhelper-compat (= 13), texinfo (>= 4.2) , libattr1-dev [linux-any], libacl1-dev [linux-any], libselinux1-dev (>= 1.32) [linux-any], gperf, bison, libgmp3-dev, libssl-dev [linux-amd64] Package: coreutils Architecture: any diff --git a/debian/rules b/debian/rules index 619f2e4e..9e94f0a5 100755 --- a/debian/rules +++ b/debian/rules @@ -13,6 +13,10 @@ ifeq ($(DEB_HOST_ARCH_CPU),sh4) DEB_CFLAGS_MAINT_APPEND += -mieee endif +ifneq ($(filter nodoc,$(DEB_BUILD_PROFILES)),) + export MAKEINFO = true +endif + BIN_PROGS = cat chgrp chmod chown cp date dd df dir echo false ln ls mkdir \ mknod mv pwd readlink rm rmdir vdir sleep stty sync touch true uname \ mktemp @@ -66,3 +70,9 @@ endif # some build environments will leave a dangling info dir rm -f $(d)/usr/share/info/dir + +ifneq ($(filter nodoc,$(DEB_BUILD_PROFILES)),) + # Remove info files and manual pages if building with + rm -rf $(d)/usr/share/info/ + rm -rf $(d)/usr/share/man/ +endif -- 2.42.0
Bug#1057101: coreutils: Upstream metadata missing and outdated URLs
Package: src:coreutils Version: 9.4-2 Tags: patch Dear coreutils maintainers, the package does not contain the d/upstream/metadata file with information about the upstream project. Also a few URLs (in d/control and d/watch) are outdated. Please find attached three patches that fix these issues. Regards, -- Gioele BarabucciFrom 02a7cc3f4861536eac3aa4462fd14a24927b39da Mon Sep 17 00:00:00 2001 From: Gioele Barabucci Date: Wed, 29 Nov 2023 15:11:25 +0100 Subject: [PATCH 1/3] d/watch: Use HTTPS instead of FTP --- debian/watch | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/debian/watch b/debian/watch index 004a5420..b5b44921 100644 --- a/debian/watch +++ b/debian/watch @@ -1,2 +1,2 @@ version=4 -opts=pgpsigurlmangle=s/$/.sig/ ftp://ftp.gnu.org/gnu/coreutils/coreutils-([\d+\.]+)\.tar\.(?:gz|bz2|lzma|xz) +opts=pgpsigurlmangle=s/$/.sig/ https://ftp.gnu.org/gnu/coreutils/coreutils-([\d+\.]+)\.tar\.(?:gz|bz2|lzma|xz) -- 2.42.0 From b0ba27efe5bea93915b17b65ef6a7143efd2a812 Mon Sep 17 00:00:00 2001 From: Gioele Barabucci Date: Wed, 29 Nov 2023 15:31:06 +0100 Subject: [PATCH 2/3] d/control: Use HTTPS in homepage URL Fixes: lintian: homepage-field-uses-insecure-uri --- debian/control | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/debian/control b/debian/control index d4f4a69a..bb3ff5f1 100644 --- a/debian/control +++ b/debian/control @@ -24,4 +24,4 @@ Description: GNU core utilities rmdir runcon sha*sum seq shred sleep sort split stat stty sum sync tac tail tee test timeout touch tr true truncate tsort tty uname unexpand uniq unlink users vdir wc who whoami yes -Homepage: http://gnu.org/software/coreutils +Homepage: https://gnu.org/software/coreutils -- 2.42.0 From 0129171d932544b5f77f9ee1fab959853b507c59 Mon Sep 17 00:00:00 2001 From: Gioele Barabucci Date: Wed, 29 Nov 2023 14:48:29 +0100 Subject: [PATCH 3/3] d/u/metadata: Add metadata about upstream project --- debian/upstream/metadata | 5 + 1 file changed, 5 insertions(+) create mode 100644 debian/upstream/metadata diff --git a/debian/upstream/metadata b/debian/upstream/metadata new file mode 100644 index ..98e38e0d --- /dev/null +++ b/debian/upstream/metadata @@ -0,0 +1,5 @@ +--- +Bug-Database: https://bugs.gnu.org/coreutils +Documentation: https://www.gnu.org/software/coreutils/manual/ +Repository: https://git.savannah.gnu.org/git/coreutils.git +Repository-Browse: https://git.savannah.gnu.org/gitweb/?p=coreutils.git -- 2.42.0
Bug#1057054: findutils: Support for build profile
Package: src:findutils Version: 4.9.0-5 Tags: patch Dear findutils maintainers, even when the build profile is used, `texinfo` remains a required build dependency. A MR that fixes this issue is available at: https://salsa.debian.org/debian/findutils/-/merge_requests/2 Regards, -- Gioele Barabucci
Bug#1056782: findutils: VCS repo breaks dpkg-source/gbp-buildpackage
Package: src:findutils Tags: patch Dear findutils maintainers, the VCS repo at https://salsa.debian.org/debian/findutils/ contains two issues that make it incompatible as-is with dpkg-souce and with gbp-buildpackage (used, among others, by Salsa-CI), making it impossible to buuild without manual (undocumented) interventions: 1. dpkg-source blindly copies the top-level README.md file and the detects it as a local change, aborting the build process 2. The fact that this a non-standard, non-DEP-14 repository is not documented in gbp.conf. These issues are fixed by the following MR: https://salsa.debian.org/debian/findutils/-/merge_requests/1 Regards, -- Gioele Barabucci
Bug#1056109: util-linux: Broken packages when building with
Package: src:util-linux Version: 2.39.2-6 Tags: patch Dear util-linux maintainers, Building util-linux with generates invalid packages (for example they contain broken symlinks to missing manpages). Also, even when the build profile is used, `asciidoctor` remains a required build dependency. A MR that fixes these issues is available at: https://salsa.debian.org/debian/util-linux/-/merge_requests/27 Regards, -- Gioele Barabucci
Bug#1053834: debhelper: dh_installman should support glob patterns like dh_install
On 13/10/23 07:54, Niels Thykier wrote: `dh_install` is a special snowflake of doing everything differently than anything else. The `dh_install` helper manually does the glob'ing rather than using the `filedoublearray` for glob expansion. [...] For everything else, glob support should be done by the executable itself (possibly indirectly via dh-exec). Hi Niels, allow me, for the sake of argument, to champion the idea that what `dh_install` does should done also by `dh_installman` (and others). Independently from the implementation, I was quite surprised when I realized, through trial and error, that just adding `#!/usr/bin/dh-exec` to a `.manpages` file required two additional changes: 1) turning the glob patterns into exact paths, and 2) prefix each entry with `debian/tmp/`. Although technically justified and documented in the man page, this goes against the Principle of Least Astonishment for debhelper users. (This is as surprising as the need to change debian/tmp/ into debian/pkg/ when going from multi- to single-binary package.) Making `dh_installman` behave like `dh_install` would not be a breaking change. Currently no `.manpages` file use both globs and dh-exec (they would not work), so enabling glob expansion would be a backward compatible change. Regards, -- Gioele Barabucci
Bug#1053921: dnsmasq: missing Git tag upstream/2.90
Package: src:dnsmasq Found: 2.90-1 Dear dnsmasq maintainer, the tag upstream/2.90 is missing from the Git repo <http://thekelleys.org.uk/git/dnsmasq.git>. This breaks gbp-buildpackage and the Salsa-CI pipeline: $ gbp buildpackage gbp:error: upstream/2.90 is not a valid treeish (From <https://salsa.debian.org/gioele/dnsmasq/-/jobs/4807124>.) Regards, -- Gioele Barabucci
Bug#1053834: debhelper: dh_installman should support glob patterns like dh_install
On 12/10/23 14:54, Niels Thykier wrote: Gioele Barabucci: On 12/10/23 14:11, Niels Thykier wrote: ``` debian/tmp/usr/share/man/*/man1/foo.1 ``` is correctly expanded by dh_install (`d/pkg.install`) but it causes dh_installman (`d/pkg.manpages`) to fail. Whatever problem you are experiencing, it is *not* that `dh_installman`does not support globs, because definitely does as debhelper itself would FTBFS otherwise (`debian/debhelper.mapages` includes globs). maybe it is the combination of dh_installman + dh-exec? When using executable debhelper config files, please be aware of the following: Otherwise, the output will be used exactly as‐is. Notably, debhelper will **not expand wildcards** or strip comments or strip whitespace in the output. This surprises me a bit. util-linux currently uses both dh-exec and wildcards in `d/util-linux-locales.install` and it works as "expected" (but not as documented?): https://salsa.debian.org/debian/util-linux/-/blob/f7d972e9d/debian/util-linux-locales.install Doesn't this mean that `dh_install` expands the globs found in the output of the executable `foo.install`? Regards, -- Gioele Barabucci
Bug#1053834: debhelper: dh_installman should support glob patterns like dh_install
On 12/10/23 14:11, Niels Thykier wrote: ``` debian/tmp/usr/share/man/*/man1/foo.1 ``` is correctly expanded by dh_install (`d/pkg.install`) but it causes dh_installman (`d/pkg.manpages`) to fail. Whatever problem you are experiencing, it is *not* that `dh_installman`does not support globs, because definitely does as debhelper itself would FTBFS otherwise (`debian/debhelper.mapages` includes globs). Hi, maybe it is the combination of dh_installman + dh-exec? This is the error message <https://salsa.debian.org/gioele/util-linux/-/jobs/4799773#L2146>: ``` dh_installman: error: open debian/tmp/usr/share/man/*/man1/col.1 failed: No such file or directory install -m0755 -d debian/util-linux-locales/usr/share/man/man1/ install -p -m0644 debian/tmp/dh-exec.czfddtTB/usr/share/man/de/man1/rename.ul.1 debian/util-linux-locales/usr/share/man/man1/rename.ul.1 install -m0755 -d debian/util-linux-locales/usr/share/man/man1/ install -p -m0644 debian/tmp/usr/share/man/uk/man1/col.1 debian/util-linux-locales/usr/share/man/man1/col.1 dh_installman: error: Aborting due to earlier error ``` The `manpages` file starts with: ``` #!/usr/bin/dh-exec debian/tmp/usr/share/man/de/man1/rename.1 => /usr/share/man/de/man1/rename.ul.1 debian/tmp/usr/share/man/uk/man1/col.1 debian/tmp/usr/share/man/*/man1/col.1 ``` And the files are definitely there: https://salsa.debian.org/gioele/util-linux/-/jobs/4799773#L2146 ``` $ find debian/ | grep man | grep col.1 | sort debian/tmp/usr/share/man/de/man1/col.1 debian/tmp/usr/share/man/man1/col.1 debian/tmp/usr/share/man/sr/man1/col.1 debian/tmp/usr/share/man/uk/man1/col.1 ``` Regards, -- Gioele Barabucci
Bug#1053834: debhelper: dh_installman should support glob patterns like dh_install
Package: debhelper Version: 13.11.6 Severity: minor Dear debhelper maintainer, the line ``` debian/tmp/usr/share/man/*/man1/foo.1 ``` is correctly expanded by dh_install (`d/pkg.install`) but it causes dh_installman (`d/pkg.manpages`) to fail. While it is technically possible to install manpages via d/pkg.install, doing so skips all the man-specific processing done by dh_installman, for instance handling the build profile. It would be nice if dh_installman expanded glob patterns in the same way dh_install and other dh helpers do. Regards, -- Gioele Barabucci
Bug#1044890: gzip: Fails to build source after successful build
Control: tags -1 patch On Sun, 13 Aug 2023 18:56:58 +0200 Lucas Nussbaum wrote: This package fails to build a source package after a successful build (dpkg-buildpackage ; dpkg-buildpackage -S). Dear gzip maintainer, a fix for this issue is available in the commit "d/rules: Restore modified files during cleanup" as part of the branch https://salsa.debian.org/gioele/gzip/-/commits/dh-std-sequence Regards, -- Gioele Barabucci
Bug#1053795: lintian: Should warn if CDBS is used
Package: lintian Version: 2.116.3 Severity: wishlist The authors of CDBS stopped developing it in 2021 and it has been orphaned in 2022. [1] With the exclusion of Haskell packages, CDBS is mostly used by orphaned or not actively maintained packages. Lintian should raise a warning if it detects that a package uses CDBS. The last maintainer of CDBS stated that he «welcome[s …] the suggestion for a lintian warning to discourage the continued use of CDBS». [2] [1] https://bugs.debian.org/1026085 [2] https://bugs.debian.org/1026085#10 Regards, -- Gioele Barabucci
Bug#985218: package-supports-alternative-init-but-no-init.d-script is outdated
Control: tags -1 pending On Sun, 14 Mar 2021 17:38:46 +0200 Faidon Liambotis wrote: The package-supports-alternative-init-but-no-init.d-script check has this text at the end: N: Refer to Debian Policy Manual section 9.11 (Alternate init systems) N: for details. However, section 9.11 reads "This section has been deleted." in the Policy. So at minimum that needs to be fixed :) https://salsa.debian.org/lintian/lintian/-/merge_requests/473 has been merged. `package-supports-alternative-init-but-no-init.d-script` will no longer be emitted starting with the next version of lintian. Regards, -- Gioele Barabucci
Bug#1053794: grep: Support for build profile
Package: src:grep Version: 3.11-3 Tags: patch Dear grep maintainers, even when the build profile is used, `texinfo` remains a required build dependency. A fix for this issue is available as part of the following MR: https://salsa.debian.org/debian/grep/-/merge_requests/12 Regards, -- Gioele Barabucci
Bug#1053793: grep: Directly use debhelper instead of abandoned cdbs
Package: src:grepO Version: 3.11-3 Tags: patch Dear grep maintainers, CDBS has been deprecated by the upstream authors in 2021 and has been orphaned in 2022, See <https://bugs.debian.org/1026085> The current packaging already relies on debhelper, so converting the packaging to the standard `dh` sequence is quite straightforward and brings additional benefits like binary reproducibility fixes and support for any future infrastructural change. A small MR that implements the switch to dh is available at: https://salsa.debian.org/debian/grep/-/merge_requests/12 Regards, -- Gioele Barabucci
Bug#1032396: build-rdeps does not work in bookworm
Control: tags -1 patch A patch to fix this issue is available at: https://salsa.debian.org/debian/devscripts/-/merge_requests/368 Regards, -- Gioele Barabucci
Bug#1053466: unicorn: Fails to build binary package again after successful build
Package: src:unicorn Version: 6.1.0-2 Severity: minor Tags: ftbfs patch User: debian...@lists.debian.org Usertags: qa-doublebuild Dear maintainers, due to files modified in d/rules, the `unicorn` package fails to build a binary-only package after a successful build. ``` dpkg-source: info: local changes detected, the modified files are: source_dir/GIT-VERSION-FILE source_dir/ext/unicorn_http/unicorn_http.c source_dir/lib/unicorn/version.rb dpkg-source: error: aborting due to unexpected upstream changes, see /tmp/unicorn_6.1.0-2+salsaci+20231004+2.diff.Ltit1F ``` A patch to fix this issue is included in the following MR: https://salsa.debian.org/ruby-team/unicorn/-/merge_requests/2 -- Gioele Barabucci
Bug#1053465: unicorn: Unnecessary Build-Depends on quilt
Package: src:unicorn Version: 6.1.0-2 Tags: patch Dear maintainers, the `unicorn` package does not need to Build-Depends on `quilt`. `dpkg-source` built-in support for quilt patches (already integrated in the standard `dh` pipeline) is enough. A patch to fix this issue is included in the following MR: https://salsa.debian.org/ruby-team/unicorn/-/merge_requests/2 -- Gioele Barabucci
Bug#1053399: ITP: fonts-albert-sans
Package: wnpp Severity: wishlist * Package name: fonts-albert-sans Version : 1.25 * URL : https://github.com/usted/Albert-Sans * License : OFL Description : Modern geometric sans-serif font Albert Sans is a modern geometric sans serif family, inspired by the type characteristics of Scandinavian architects and designers in the early 20th century. The Albert Sans family includes ten weights from Thin to Black and supports over two hundred languages. Designed by the Danish type designer Andreas Rasmussen from a.Foundry. -- Gioele Barabucci
Bug#1053139: override: bats:devel/optional
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: override X-Debbugs-Cc: team+b...@tracker.debian.org FTP Team, Please change bats from: shell/optional to: devel/optional The change of section happened a couple of versions ago, in 1.8.2-1: https://salsa.debian.org/bats-team/bats/-/commit/4d5a96ed Regards, -- Gioele Barabucci
Bug#1051861: gzip-win32 is no longer needed
Package: gzip-win32 Version: 1.12-1 Tags: patch Dear gzip maintainers, could you please stop building the package gzip-win32? `debian-installer` stopped depending on gzip-win32 in 2020. It has since been removed from the list of build dependencies. See commit https://salsa.debian.org/installer-team/win32-loader/-/commit/650f33f6 . A nice side effect of not building gzip-win32 as part of gzip will be to greatly simplify the bootstrap of the essential set, as it would remove mingw-w64 from the list of required dependencies. A patch to fix this issue can be found as the last commit of the branch https://salsa.debian.org/gioele/gzip/-/tree/win32-remove Regards, -- Gioele Barabucci
Bug#1051827: shadow: Support for build profile
Package: src:shadow Version: 1:4.13+dfsg1-1 Tags: patch Dear shadow maintainers, `xsltproc`, `docbook` and various other XML-related packages are kept as build dependencies even when the `` build profile is used. A MR that fixes this issue is available at: https://salsa.debian.org/debian/shadow/-/merge_requests/18 Regards, -- Gioele Barabucci
Bug#1051825: init-system-helpers: Support for build profile
Package: src:init-system-helpers Version: 1.65.2 Tags: patch Dear init-system-helpers maintainers, `python3-docutils` is kept as build dependency even when the `` build profile is used. A MR that fixes this issue is available at: https://salsa.debian.org/debian/init-system-helpers/-/merge_requests/26 Regards, -- Gioele Barabucci
Bug#1051810: base-passwd: Unused w3m build dependency
Package: src:base-passwd Version: 3.6.2 Tags: patch Dear base-passwd maintainers, `w3m` is listed as a build dependency for base-passwd but it does not seem to be used at all during the build process. A MR that fixes this issue is available at: https://salsa.debian.org/debian/base-passwd/-/merge_requests/14 Regards, -- Gioele Barabucci
Bug#1051809: base-passwd: Support for build profile
Package: src:base-passwd Version: 3.6.2 Tags: patch Dear base-passwd maintainers, `docbook` and `docbook-tools` are kept as build dependencies even when the build profile is used. A MR that fixes this issue is available at: https://salsa.debian.org/debian/base-passwd/-/merge_requests/14 Regards, -- Gioele Barabucci
Bug#1051792: sed: Support for build profile
Package: src:sed Version: 4.9-1 Tags: patch Dear sed maintainers, even when the build profile is used, `texinfo` remains a required build dependency. A MR that fixes this issue is available at: https://salsa.debian.org/debian/sed/-/merge_requests/2 Regards, -- Gioele Barabucci
Bug#1051388: bash: Prompt messed up if PS1 contains ANSI escape sequences
Package: bash
Version: 5.2.15-2+b2
Bash will produce erroneous output when PS1 contains escape sequences.
It will also misplace the cursor and corrupt the state the current line.
To replicate this issue:
1. Modify P1 to contain one or more ANSI escape sequences, for example
"\e[45m" (tput setab 5, changes the background color to purple) or
"\e(B\e[m" (tput sgr0, reset for xterm terminals):
$ PS1="x$(printf '\e(B\e[m') \\\$ "
2. Press the up arrow to recall the last command. The command line will
now show [■ indicates the position of the cursor]:
x $ PS1="x$(printf '\e(B\e[m') \\\$ "■
3. Press the down arrow to go back to the empty prompt.
What one should see at this point is just the prompt
x $ ■
Instead, left-overs from the recalled line will be visible and the
cursor will be placed in the wrong spot:
x $ PS1="x■
The amount of garbage left on the prompt is proportional to the number
of escape sequences:
PS1="x$(printf '\e(B\e[m')\\\$ " => 6 left-over chars
PS1="x$(printf '\e(B\e[m%.0s' {1..2})\\\$ " => 12 left-over chars
PS1="x$(printf '\e(B\e[m%.0s' {1..4})\\\$ " => 24 left-over chars
Tested with TERM = linux, xterm, xterm-256color.
--
Gioele Barabucci
Bug#1039958: autopkgtest-build-podman: Image creation fails with "sd-bus call: Permission denied"
On 06/09/23 15:27, Faidon Liambotis wrote: On Fri, Jun 30, 2023 at 12:52:31PM +0200, Gioele Barabucci wrote: autopkgtest-build-podman's failure is due to the issue reported in [1], i.e. the Debian setup of podman requires `dbus-user-session`, but none of the podman-related packages Depends on it. podman may not Depend on dbus-user-session, but it Recommends it. Indeed this is not a `podman` issue, but a `autopkgtest-build-podman` one. To rephrase it: autopkgtest-build-podman does not work without dbus-user-session. Why doesn't the package that contains autopkgtest-build-podman Depends: on dbus-user-session? The answer is (I presume) that the package containing autopkgtest-build-podman (autopkgtest) is a bit too generic to have an hard Depend on dbus-user-session. This is why I was suggesting splitting it into a separate package. If there is consensus, I volunteer to create a MR to move autopkgtest-build-podman and related files to a separate package that can then Depends: on podman, dbus-user-session and all other packages required to make it work out of the box. Regards, -- Gioele Barabucci
Bug#1051312: DDPO: Group packages by team
Package: qa.debian.org Severity: wishlish User: qa.debian@packages.debian.org Usertags: ddpo Dear QA Team, would it be possible to group the packages maintained by a DD/DM (and listed in the "main" table) by team? In my case https://qa.debian.org/developer.php?login=gio...@svario.it would show just two packages maintained by me, then 4 packages maintained by the Bats team, then 5 maintained by the Fonts team and finally one related to the Ruby team. A visualization of a DD/DM's packages grouped by team would provide a better overview of their interests and responsibilities. Regards, -- Gioele Barabucci
Bug#1021607: debhelper: Also trim (or delete) NEWS.Debian.gz if changelog.Debian.gz is trimmed
Control: tags -1 patch On Sun, 09 Oct 2022 19:37:12 +0200 "Francesco Poli (wintermute)" wrote: W: apt-listbugs: debian-news-entry-has-unknown-version 0.1.14 [usr/share/doc/apt-listbugs/NEWS.Debian.gz:1] N: N: The version number of the most recent NEWS.Debian entry does not match any N: of the version numbers in the changelog file for this package. This A patch to fix this problem is available at https://salsa.debian.org/debian/debhelper/-/merge_requests/110 -- Gioele Barabucci
Bug#1048718: tar: Fails to build source after successful build
Control: tags -1 patch On Sun, 13 Aug 2023 21:21:29 +0200 Lucas Nussbaum wrote: This package fails to build a source package after a successful build (dpkg-buildpackage ; dpkg-buildpackage -S). A fix for this issue is included in <https://salsa.debian.org/debian/tar/-/merge_requests/3>. Tested via the `test-build-twice` test on salsa-ci. Regards, -- Gioele Barabucci
Bug#1050568: tar-scripts should be Architecture: all
Package: tar-scripts Found: 1.34+dfsg-1.2 Tags: patch Dear tar-scripts maintainers, currently tar-scripts is built as Architecture: any, but it only contains architecture-independent shell scripts, so it should be built as Architecture: all. You can find a MR that fixes this issue at: https://salsa.debian.org/debian/tar/-/merge_requests/4 Regards, -- Gioele Barabucci
Bug#1050566: tar: Consider using the standard dh sequence in d/rules
Package: src:tar Version: 1.34+dfsg-1.2 Severity: wishlist Tags: patch Dear tar maintainers, this package currently uses debhelper with an ad-hoc sequence of steps in d/rules. This long list of steps can be shortened and greatly simplified by using the standard dh sequence. You can find a MR that changes `d/rules` to use the standard dh sequence at: https://salsa.debian.org/debian/tar/-/merge_requests/3 According to diffoscope, the generated `tar` binary package is identical to the current one. The `tar-scripts` binary package is slightly different because it contains a fix for https://bugs.debian.org/1050565 Regards, -- Gioele Barabucci
Bug#1050565: tar-scripts: SYSCONFDIR defaults to non-existing dir /usr/etc
Package: tar-scripts Version: 1.34+dfsg-1.2 Severity: minor Tags: patch Dear tar-scripts maintainers, the scripts backup.sh, dump-remind, tar-backup, and tar-restore use the non-existing directory /usr/etc as the default value for SYSCONFDIR. A fix for this problem is available as part of the following MR: https://salsa.debian.org/debian/tar/-/merge_requests/3 Regards, -- Gioele Barabucci
Bug#1050544: tar: missing Git tags upstream/1.33+dfsg, upstream/1.34+dfsg
Package: src:tar Found: 1.34+dfsg1-1 Dear tar maintainers, the tags upstream/1.33+dfsg and upstream/1.34+dfsg are missing from the Git repo <https://salsa.debian.org/debian/tar>. This breaks gbp-buildpackage: $ gbp buildpackage gbp:error: upstream/1.34+dfsg is not a valid treeish Regards, -- Gioele Barabucci
Bug#1013868: nfs-common: Split between Python scripts to separate package
On Fri, 01 Jul 2022 21:57:44 +0200 Ben Hutchings wrote:> On Sun, 2022-06-26 at 09:47 +0200, Gioele Barabucci wrote: > Package: nfs-common > Version: 1:2.6.1-2 > > Dear maintainers of nfs-common, > > could you please move the three Python scripts included in nfs-common to > a separate -extras package? No, the postinst may run nfsconvert.py. > Currently nfs-common Depends on `python3` and, on lean/containerized > client systems, it is the only package that requires it. For this > reason, in 2019 Fedora moved the scripts `mountstats`, `nfsiostat` and > `nfsconvert` to a separate package [1,2], required on servers (for > `nfsconver`) but not on clients. nfsconvert.py is also required on clients. We can remove nfsconvert.py and revisit this after the bookworm release. Hi, now that nfsconvert.py has been removed (thanks!) [1], do you think it would be possible to move these Python scripts to a separate package? Are patches/MR welcome? [1] https://salsa.debian.org/kernel-team/nfs-utils/-/commit/490e6fd -- Gioele Barabucci
