Bug#1068188: pthread_cond_init.3.gz: conflict with manpages-dev 6.7-1

[Alejandro Colomar]

Hi Sven,

On Wed, Apr 03, 2024 at 11:17:10PM +0200, Sven Joachim wrote:
> Those are not additional pages, but just symlinks.
> 
> ,
> | $ file $(dpkg -L glibc-doc | tail -n17)
> | /usr/share/man/man3/pthread_cond_broadcast.3.gz:   symbolic link to 
> pthread_cond_init.3.gz
> | /usr/share/man/man3/pthread_cond_destroy.3.gz: symbolic link to 
> pthread_cond_init.3.gz
> | /usr/share/man/man3/pthread_cond_signal.3.gz:  symbolic link to 
> pthread_cond_init.3.gz
> | /usr/share/man/man3/pthread_cond_timedwait.3.gz:   symbolic link to 
> pthread_cond_init.3.gz
> | /usr/share/man/man3/pthread_cond_wait.3.gz:symbolic link to 
> pthread_cond_init.3.gz
> | /usr/share/man/man3/pthread_condattr_destroy.3.gz: symbolic link to 
> pthread_condattr_init.3.gz
> | /usr/share/man/man3/pthread_getspecific.3.gz:  symbolic link to 
> pthread_key_create.3.gz
> | /usr/share/man/man3/pthread_key_delete.3.gz:   symbolic link to 
> pthread_key_create.3.gz
> | /usr/share/man/man3/pthread_mutex_destroy.3.gz:symbolic link to 
> pthread_mutex_init.3.gz
> | /usr/share/man/man3/pthread_mutex_lock.3.gz:   symbolic link to 
> pthread_mutex_init.3.gz
> | /usr/share/man/man3/pthread_mutex_trylock.3.gz:symbolic link to 
> pthread_mutex_init.3.gz
> | /usr/share/man/man3/pthread_mutex_unlock.3.gz: symbolic link to 
> pthread_mutex_init.3.gz
> | /usr/share/man/man3/pthread_mutexattr_destroy.3.gz:symbolic link to 
> pthread_mutexattr_init.3.gz
> | /usr/share/man/man3/pthread_mutexattr_getkind_np.3.gz: symbolic link to 
> pthread_mutexattr_setkind_np.3.gz
> | /usr/share/man/man3/pthread_mutexattr_gettype.3.gz:symbolic link to 
> pthread_mutexattr_init.3.gz
> | /usr/share/man/man3/pthread_mutexattr_settype.3.gz:symbolic link to 
> pthread_mutexattr_init.3.gz
> | /usr/share/man/man3/pthread_setspecific.3.gz:  symbolic link to 
> pthread_key_create.3.gz
> `
> 
> In the man-pages source such aliases are included as files just
> containing a .so directive, those should indeed be added.

Ahhh, good, then it will be easier; I don't need to import their
git histories, I guess.  Or maybe I do anyway, just for completeness.


> > I'll import those into the Linux man-pages in a week, when I get back
> > from vacation.
> 
> Have a nice vacation!

:-)

Cheers,
Alex

> Cheers,
>Sven

-- 



signature.asc
Description: PGP signature

Bug#1068188: pthread_cond_init.3.gz: conflict with manpages-dev 6.7-1

[Alejandro Colomar]

Hi Sven,

On Wed, Apr 03, 2024 at 06:01:50PM +0200, Sven Joachim wrote:
> Control: severity -1 normal
> 
> On 2024-04-03 11:29 +0200, Alejandro Colomar wrote:
> 
> > Hi,
> >
> > On Tue, Apr 02, 2024 at 08:58:32PM +0200, Aurelien Jarno wrote:
> >> Thanks, that sounds great that we can finally get rid out of those in
> >> the debian package.
> >>
> >> >  $ git diff --stat b06cd070f..128a3ae35
> >> >   man3/pthread_cond_init.3| 264 
> >> >   man3/pthread_condattr_init.3|  48 
> >> >   man3/pthread_key_create.3   | 178 +
> >> >   man3/pthread_mutex_init.3   | 241 ++
> >> >   man3/pthread_mutexattr_setkind_np.3 |  52 
> >> >   man3/pthread_once.3 |  44 
> >> >   6 files changed, 827 insertions(+)
> >
> > I now see that `apt-file show glibc-doc` shows several more pages.  I'll
> > have a look at them and maybe I also import them into the Linux
> > man-pages project.
> 
> AFAICS all of them have already been added there, right?

Nope; I added the ones that I found in upstream glibc, and then I
upgraded them to the version they had in Debian.  But for some reason, I
didn't notice that there were more in Debian.  Or maybe I thought they
were already in the Linux man-pages.  Whatever the reason, they're not
there.

See:

$ diff -u \
<(apt-file show glibc-doc \
| awk '{print $2}' \
| grep /man/ \
| sed 's,^/usr/share/man/,,' \
| sed 's/\.gz$//' \
| sort) \
<(find src/linux/man-pages/man-pages/master/man* -type f \
| sed 's,^src/linux/man-pages/man-pages/master/,,' \
| sort) \
| grep ^-;
--- /dev/fd/63  2024-04-03 22:40:00.524652442 +0200
-man3/pthread_cond_broadcast.3
-man3/pthread_cond_destroy.3
-man3/pthread_cond_signal.3
-man3/pthread_cond_timedwait.3
-man3/pthread_cond_wait.3
-man3/pthread_condattr_destroy.3
-man3/pthread_getspecific.3
-man3/pthread_key_delete.3
-man3/pthread_mutex_destroy.3
-man3/pthread_mutex_lock.3
-man3/pthread_mutex_trylock.3
-man3/pthread_mutex_unlock.3
-man3/pthread_mutexattr_getkind_np.3
-man3/pthread_mutexattr_gettype.3
-man3/pthread_mutexattr_settype.3
-man3/pthread_setspecific.3


I'll import those into the Linux man-pages in a week, when I get back
from vacation.

> >> Noted. However following the time_t transition, the glibc package does
> >> not build anymore on 32-bit architectures (i have just opened #1059937
> >> to make people aware of that), so uploading a new glibc now is probably
> >> not the best idea.
> >
> > Hmm, maybe you can drop the manual pages, but not upload yet, and wait
> > for that bug to be fixed to do an upload without the pages.
> 
> Note that manpages-dev 6.7-2 has dropped the clashing files for the time
> being.  I do not think there is any need to hurry, so I am downgrading
> the severity of this bug.  Whenever the glibc-doc package in unstable
> drops the manpages, we should file a bug against manpages-dev to include
> them again.

Sure; no problem.  Also, since I plan to also add the remaining pages,
you will be able to drop them all at once after that happens.  Maybe for
man-pages-6.8 we can do that.  How much time do you expect this
pseudo-freeze to last?  I can adapt to that.

Have a lovely night!
Alex

-- 
<https://www.alejandro-colomar.es/>


signature.asc
Description: PGP signature

Bug#1068188: pthread_cond_init.3.gz: conflict with manpages-dev 6.7-1

[Alejandro Colomar]

Hi,

On Tue, Apr 02, 2024 at 08:58:32PM +0200, Aurelien Jarno wrote:
> Thanks, that sounds great that we can finally get rid out of those in
> the debian package.
> 
> > $ git diff --stat b06cd070f..128a3ae35
> >  man3/pthread_cond_init.3| 264 
> >  man3/pthread_condattr_init.3|  48 
> >  man3/pthread_key_create.3   | 178 +
> >  man3/pthread_mutex_init.3   | 241 ++
> >  man3/pthread_mutexattr_setkind_np.3 |  52 
> >  man3/pthread_once.3 |  44 
> >  6 files changed, 827 insertions(+)

I now see that `apt-file show glibc-doc` shows several more pages.  I'll
have a look at them and maybe I also import them into the Linux
man-pages project.

> > Debian's manpages-dev_6.7-1_all.deb has been the first package since
> > that happened, and I've noticed that dpkg(1) (via apt-get(8)) refuses to
> > upgrade manpages-dev due to a conflict with glibc-doc.
> > 
> > $ sudo apt-get upgrade -V;
> > [...]
> > Do you want to continue? [Y/n] y
> > Reading changelogs... Done
> > (Reading database ... 404853 files and directories currently installed.)
> > Preparing to unpack .../manpages-dev_6.7-1_all.deb ...
> > Unpacking manpages-dev (6.7-1) over (6.05.01-1) ...
> > dpkg: error processing archive 
> > /var/cache/apt/archives/manpages-dev_6.7-1_all.deb (--unpack):
> >  trying to overwrite '/usr/share/man/man3/pthread_cond_init.3.gz', 
> > which is also in package glibc-doc 2.38-6
> > Errors were encountered while processing:
> >  /var/cache/apt/archives/manpages-dev_6.7-1_all.deb
> > needrestart is being skipped since dpkg has failed
> > E: Sub-process /usr/bin/dpkg returned an error code (1)
> 
> I think this is actually not specific to the experimental version, those
> manpages are also in the unstable version.

Right.  I only installed the experimental one to see if the bug had
been fixed (as reportbug(1) suggested trying it).

> > Please, remove from glibc-doc those manual pages that conflict with
> > manpages-dev.
> 
> Noted. However following the time_t transition, the glibc package does
> not build anymore on 32-bit architectures (i have just opened #1059937
> to make people aware of that), so uploading a new glibc now is probably
> not the best idea.

Hmm, maybe you can drop the manual pages, but not upload yet, and wait
for that bug to be fixed to do an upload without the pages.

Have a lovely day!
Alex

-- 



signature.asc
Description: PGP signature

Bug#1068188: pthread_cond_init.3.gz: conflict with manpages-dev 6.7-1

[Alejandro Colomar]

Hi Sven,

On Mon, Apr 01, 2024 at 06:38:52PM +0200, Sven Joachim wrote:
> Makes perfect sense, but at the moment it can only be uploaded to
> experimental.
> 
> > We're not in a freeze, so I guess that's fair game.
> 
> We're not in a freeze but in the middle of the largest transition in
> Debian history[1], and during that a new major glibc version in unstable is
> out of the question.
> 
> >> files for now and re-include either when glibc 2.38 is in unstable or
> >> when it is in testing.
> >
> > Why do we need to wait to ask for a glibc-doc_2.38-7 with the patch
> > dropped?  Does 2.38 have any freeze at the moment?
> 
> Yes.  Every new major glibc version requires a transition (requiring
> rebuilds of all packages which use @GLIBC_PRIVATE symbols, among other
> things), and the one for glibc 2.38[2] has been pending for three
> months[3].

Hmmm, I understand.  If you want to temporarily drop these pages from
manpages-dev, go ahead.  Please undrop them when glibc-doc can make a
new release.  BTW, I guess glibc-doc must match libc6 version?
Otherwise, you could have a more recent glibc-doc that drops these pages
without upgrading libc6.  Are documentation changes frozen in such a
transition?

> 
> >> There is also the problem that some derivatives (most notably Ubuntu)
> >> are already shipping glibc 2.39 and will have to adjust Breaks/Replaces
> >> versions in manpages-dev accordingly.
> >
> > Hmmm.  I suggest they patch glibc-doc to remove those manual pages.
> > They have been unsupported for a long time.  The last change in
> > glibc-doc is from 2013.
> 
> I guess Ubuntu can then drop the glibc-doc package entirely, as they do
> not ship the upstream changelogs in it, and after dropping the pthread_*
> manpages the package would be empty.  TBH, I do not see much value in
> these changelogs and will probably uninstall glibc-doc from my systems.

Good.

Have a lovely day!
Alex

> 
> Cheers,
>Sven
> 
> 
> 1. https://lists.debian.org/debian-devel-announce/2024/02/msg5.html
> 2. https://release.debian.org/transitions/html/glibc-2.38.html
> 3. https://bugs.debian.org/1059852

-- 

Looking for a remote C programming job at the moment.


signature.asc
Description: PGP signature

Bug#1068188: pthread_cond_init.3.gz: conflict with manpages-dev 6.7-1

[Alejandro Colomar]

Hi Sven,

On Mon, Apr 01, 2024 at 05:35:18PM +0200, Sven Joachim wrote:
> Obviously the manpages-dev package should not have shipped these files
> as long as there are in glibc-doc; this is tracked in #1068166.

I CCed back in 2023-10 the debian-glibc@ list notifying that these pages
were absorbed into the Linux man-pages project.  They didn't respond.



However, the original author of the pages talked to me, agreeing to
that.  Other glibc upstream maintainers also participated in the thread.

> 
> > Please, remove from glibc-doc those manual pages that conflict with
> > manpages-dev.
> 
> Considering that the manpages in glibc-doc are not included upstream and

The history is a bit more complex than that.  They were originally
written upstream.  Then glibc removed them.  A decade later, Debian
added them back via a patch, with some modifications.  I noted down the
history in the discussion linked above.

> created via a Debian patch, that makes a lot of sense.  I was not aware
> of that fact.
> 
> > Marcos, you'll also need to specify a breaks with glibc-doc versions
> > up to (and including) 6.38-6 in the next revision of manpages-dev, and
> > drop 6.7-1.
> 
> Adding a Breaks on glibc-doc (<= 2.38-6) to manpages-dev is no good,
> because that version is only in experimental and will remain there for
> several weeks if not months.  I think manpages-dev should drop these

Why not add glibc-doc 2.38-7 dropping the patch that adds these pages?
We're not in a freeze, so I guess that's fair game.

> files for now and re-include either when glibc 2.38 is in unstable or
> when it is in testing.

Why do we need to wait to ask for a glibc-doc_2.38-7 with the patch
dropped?  Does 2.38 have any freeze at the moment?

> There is also the problem that some derivatives (most notably Ubuntu)
> are already shipping glibc 2.39 and will have to adjust Breaks/Replaces
> versions in manpages-dev accordingly.

Hmmm.  I suggest they patch glibc-doc to remove those manual pages.
They have been unsupported for a long time.  The last change in
glibc-doc is from 2013.

> Thoughts?
> 
> Cheers,
>Sven

Have a lovely day!
Alex

-- 

Looking for a remote C programming job at the moment.


signature.asc
Description: PGP signature

Bug#1068188: glibc-doc: pthread_cond_init.3.gz: conflict with manpages-dev 6.7-1

[Alejandro Colomar]

On Mon, Apr 01, 2024 at 04:23:08PM +0200, Alejandro Colomar wrote:
> The Linux man-pages project has recently added the pthread_*(3) manual
> pages that were provided by glibc-doc.  The first upstream version of
> the Linux man-pages that includes these pages is man-pages-6.06.  Here's
> what was added:
> 
>   $ git diff --stat b06cd070f..128a3ae35
>man3/pthread_cond_init.3| 264 
>man3/pthread_condattr_init.3|  48 
>man3/pthread_key_create.3   | 178 +
>man3/pthread_mutex_init.3   | 241 ++
>man3/pthread_mutexattr_setkind_np.3 |  52 
>man3/pthread_once.3 |  44 
>6 files changed, 827 insertions(+)

Here's the relevant excerpt of the git-log(1):

* 128a3ae35 pthread_key_create.3: Mention glibc instead of LinuxThreads
* 8a00cac75 pthread_*.3: ffix (semantic newlines)
* 74235f157 pthread_*.3: ffix (paragraphing)
* 13151ec52 pthread_*.3: Remove AUTHOR section; add copyright; adapt TH
* c1c253d0e pthread_cond_init.3, pthread_condattr_init.3, 
pthread_key_create.3, pthread_mutex_init.3, pthread_mutexattr_setkind_np.3, 
pthread_once.3: Update the glibc pages with the debian/glibc version of them
*   87183bb8e Import debian/local/manpages/pthread_*.3 git history from 
debian/glibc
|\  
| * 02d79c7d9   * Remove linuxthreads from the tarball: - 
rules.d/tarball.mk: don't fetech linuxthreads and linuxthreads_db. - 
rules.d/build.mk: don't build linuxthreads manpages. - rules: don't run 
make clean in linuxthreads directory. - patches/any/local-sysctl.diff: drop 
the linuxthreads part. - patches/all/local-pthread-manpages.diff: remove.   
  - local/manpages/pthread_*.3: import the few remaining linuxthreads   
manpages. - debhelper.in/glibc-doc.manpages: update manpage locations.
|/  
* a254db8b3 pthread_cond_init.3, pthread_condattr_init.3, 
pthread_key_create.3, pthread_mutex_init.3, pthread_mutexattr_setkind_np.3, 
pthread_once.3: Import pages from glibc
* 87d09778d Revert "linuxthreads, linuxthreads_db: Directories removed 
(preserved in ports repository)."
*   281f670a4 Import linuxthreads/man/ git history from glibc
|\  
| * a3db24d46 linuxthreads, linuxthreads_db: Directories removed 
(preserved in ports repository).
| * 2988d2724 (CFLAGS-tst-align.c): Add -mpreferred-stack-boundary=4.
| * f7f73b1ca 2.5-18.1
| * 67eceac09 Update.
| * 7ffaa96aa Update.
| * 869af9b6a Correct example.
| * 31b1e42d5 LinuxThreads library.
|/  

-- 
<https://www.alejandro-colomar.es/>
Looking for a remote C programming job at the moment.


signature.asc
Description: PGP signature

Bug#1068188: pthread_cond_init.3.gz: conflict with manpages-dev 6.7-1

[Alejandro Colomar]

Package: glibc-doc
Version: 2.38-6
Severity: serious
Justification: Policy 7.4
X-Debbugs-Cc: a...@kernel.org, mar...@debian.org

Dear Maintainer,

The Linux man-pages project has recently added the pthread_*(3) manual
pages that were provided by glibc-doc.  The first upstream version of
the Linux man-pages that includes these pages is man-pages-6.06.  Here's
what was added:

$ git diff --stat b06cd070f..128a3ae35
 man3/pthread_cond_init.3| 264 
 man3/pthread_condattr_init.3|  48 
 man3/pthread_key_create.3   | 178 +
 man3/pthread_mutex_init.3   | 241 ++
 man3/pthread_mutexattr_setkind_np.3 |  52 
 man3/pthread_once.3 |  44 
 6 files changed, 827 insertions(+)

Debian's manpages-dev_6.7-1_all.deb has been the first package since
that happened, and I've noticed that dpkg(1) (via apt-get(8)) refuses to
upgrade manpages-dev due to a conflict with glibc-doc.

$ sudo apt-get upgrade -V;
[...]
Do you want to continue? [Y/n] y
Reading changelogs... Done
(Reading database ... 404853 files and directories currently installed.)
Preparing to unpack .../manpages-dev_6.7-1_all.deb ...
Unpacking manpages-dev (6.7-1) over (6.05.01-1) ...
dpkg: error processing archive 
/var/cache/apt/archives/manpages-dev_6.7-1_all.deb (--unpack):
 trying to overwrite '/usr/share/man/man3/pthread_cond_init.3.gz', 
which is also in package glibc-doc 2.38-6
Errors were encountered while processing:
 /var/cache/apt/archives/manpages-dev_6.7-1_all.deb
needrestart is being skipped since dpkg has failed
E: Sub-process /usr/bin/dpkg returned an error code (1)

Please, remove from glibc-doc those manual pages that conflict with
manpages-dev.

Marcos, you'll also need to specify a breaks with glibc-doc versions
up to (and including) 6.38-6 in the next revision of manpages-dev, and
drop 6.7-1.


Have a lovely day!
Alex


-- System Information:
Debian Release: trixie/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 6.8.0-rc7-alx-dirty (SMP w/24 CPU threads; PREEMPT)
Locale: LANG=C.utf8, LC_CTYPE=C.utf8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

glibc-doc depends on no packages.

glibc-doc recommends no packages.

Versions of packages glibc-doc suggests:
ii  glibc-doc-reference  2.38-1

-- no debconf information

Bug#1067022: man2html: Segmentation fault with tzfile(5)

[Alejandro Colomar]

Package: man2html
Version: 1.6g-16
Severity: normal
Tags: upstream
X-Debbugs-Cc: Alejandro Colomar , Paul Eggert 
, "G. Branden Robinson" , 
linux-...@vger.kernel.org, gr...@gnu.org, t...@iana.org

Dear Maintainer,

The page tzfile(5) from tzdb-2024a manages to consistently produce a
Segmentation fault with man2html(1).  Below is a reproducer:

alx@debian:~/tmp$ wget 
https://data.iana.org/time-zones/releases/tzdb-2024a.tar.lz 2>/dev/null
alx@debian:~/tmp$ tar xf tzdb-2024a.tar.lz 
alx@debian:~/tmp$ man2html tzdb-2024a/tzfile.5
Content-type: text/html; charset=UTF-8


Man page of tzfile

tzfile
Section: File Formats (5)Updated: Index
Return to Main Contents


NAME

tzfile - timezone information

DESCRIPTION









The timezone information files used by
tzset(3)

are typically found under a directory with a name like
/usr/share/zoneinfo.

These files use the format described in Internet RFC 8536.
Each file is a sequence of 8-bit bytes.
In a file, a binary integer is represented by a sequence of one or
more bytes in network order (bigendian, or high-order byte first),
with all bits significant,
a signed binary integer is represented using two's complement,
and a boolean is represented by a one-byte binary integer that is
either 0 (false) or 1 (true).
The format begins with a 44-byte header containing the following fields:
Segmentation fault
alx@debian:~/tmp$ dpkg -l | grep man2html
ii  man2html   1.6g-16  
 amd64browse man pages in your web browser
ii  man2html-base  1.6g-16  
 amd64convert man pages into HTML format

I've refreshed this page today, and the previous version I used didn't
have this crash.  Below is the part of the diff that I think is
responsible for the crash:

diff --git a/man5/tzfile.5 b/man5/tzfile.5
index 45afecc10..867348d67 100644
--- a/man5/tzfile.5
+++ b/man5/tzfile.5
@@ -26,23 +26,24 @@ .SH DESCRIPTION
 and a boolean is represented by a one-byte binary integer that is
 either 0 (false) or 1 (true).
 The format begins with a 44-byte header containing the following 
fields:
-.IP * 2
+.RS "\w'  'u"
+.IP \(bu "\w'\(bu  'u"
 The magic four-byte ASCII sequence
 .q "TZif"
 identifies the file as a timezone information file.

BTW, I noticed that the upstream homepage is dead:
<http://users.actrix.gen.nz/michael/vhman2html.html>.
Is this project defunct?

Have a lovely day!
Alex


-- System Information:
Debian Release: trixie/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 6.8.0-rc7-alx-dirty (SMP w/24 CPU threads; PREEMPT)
Locale: LANG=C.utf8, LC_CTYPE=C.utf8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages man2html depends on:
ii  debconf [debconf-2.0]  1.5.86
ii  gawk   1:5.2.1-2
ii  libc6  2.37-15.1
ii  lynx   2.9.0rel.0-2+b1
ii  man-db 2.12.0-3
ii  man2html-base  1.6g-16
ii  sensible-utils 0.0.22

man2html recommends no packages.

Versions of packages man2html suggests:
ii  firefox-esr [www-browser]  115.8.0esr-1+b1
ii  lynx [www-browser] 2.9.0rel.0-2+b1
pn  swish++
ii  w3m [www-browser]  0.5.3+git20230121-2+b3

-- debconf information:
  man2html/index_manpages: true

Bug#1065833: libbsd-dev: Missing manual page links for warn*(3bsd) functions

[Alejandro Colomar]

Package: libbsd-dev
Version: 0.12.1-1
Severity: normal
Tags: upstream
X-Debbugs-Cc: a...@kernel.org

Dear Guillem,

libbsd is missing link manual pages for warn*() functions.

Have a lvoely day!
Alex


-- System Information:
Debian Release: trixie/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 6.8.0-rc7-alx-dirty (SMP w/24 CPU threads; PREEMPT)
Locale: LANG=C.utf8, LC_CTYPE=C.utf8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libbsd-dev depends on:
ii  libbsd00.12.1-1
ii  libmd-dev  1.1.0-2

libbsd-dev recommends no packages.

libbsd-dev suggests no packages.

-- no debconf information

Bug#1065350: Build-Depends: libltdl-dev

[Alejandro Colomar]

Source: shadow
Version: 1:4.13+dfsg1-1
Severity: normal
X-Debbugs-Cc: a...@kernel.org

Dear Maintainer,

I've tried building shadow from source, using the same flags that Debian
uses in debian/rules in Devuan (which hasn't forked these packages, so
it's the Debian package).  I get an error when running ./autoget.sh:

configure.ac:35: error: possibly undefined macro: LT_LIB_DLLOAD
  If this token and others are legitimate, please use 
m4_pattern_allow.
  See the Autoconf documentation.
autoreconf: error: /usr/bin/autoconf failed with exit status: 1

Installing libltdl-dev solves the issue.  I suspect that library is
usually installed, which is probaby why this hasn't been noticed or
reported before.  I think we should add 'libltdl-dev' to Build-Depends.

Have a lovely day!
Alex


-- System Information:
Debian Release: 12.0
merged-usr: no
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-17-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Bug#1064909: libbsd-dev: Many functions (possibly all?) aren't available

[Alejandro Colomar]

Hi!

On Tue, Feb 27, 2024 at 06:10:01PM +0100, Guillem Jover wrote:
> Hi!
> 
> On Tue, 2024-02-27 at 17:33:16 +0100, Alejandro Colomar wrote:
[...]
> The strtoi() function is declared in . I don't think that
> has changed in libbsd.

Oops!  I wrote the reproducer too fast.  Actually, the problem I saw was
about errc(), but because I tried strtoi() to see if it was the only
function, and it also failed, but I forgot about the right header.

It was also aggravated by the fact that my grepc(1) program didn't find
it.  But it's due to a bug I introduced yesterday in grepc(1).  :|

$ grepc strtoi /usr/include/bsd/

But grep(1) does find it:

$ grep -rn strtoi /usr/include/bsd/
/usr/include/bsd/inttypes.h:43:intmax_t strtoi(const char *__restrict 
nptr, char **__restrict endptr,

And after fixing the bug in grepc(1):

$ grepc strtoi /usr/include/bsd/
/usr/include/bsd/inttypes.h:__BEGIN_DECLS
intmax_t strtoi(const char *__restrict nptr, char **__restrict endptr,
int base, intmax_t lo, intmax_t hi, int *rstatus);

> 
> > BTW, thanks for updating strtoi/u(3) from NetBSD!  =)
> 
> Thanks for handling the upstream interaction in NetBSD!
> 
[...]
> 
> Ah, it indeed has disappeared. The upstream build system is missing a
> conditional for the header, I'll add this later today and prepare a
> new upstream release.
> 
> Another thing which I was aware, but then slipped my mind is that the
> cdefs.h header needs to be placed under a multi-arch qualified
> directory otherwise it will conflict with other instances of the
> library now that it contains arch-specific defines. Will amend that
> with the new Debian upload.

Thanks!

Have a lovely day!
Alex

> 
> Thanks,
> Guillem

-- 
<https://www.alejandro-colomar.es/>
Looking for a remote C programming job at the moment.


signature.asc
Description: PGP signature

Bug#1064909: libbsd-dev: Many functions (possibly all?) aren't available

[Alejandro Colomar]

Hi Guillem!

On Tue, Feb 27, 2024 at 05:33:16PM +0100, Alejandro Colomar wrote:
> I've also seen errc(3bsd) disappear, and possibly many more functions.
> If you need some help to reproduce this issue, just let me know.

In the case of , the header has disappeared:

$ cat bsd.c 
#include 
#include 

long
strtoi_(char *s, char **endp, int b, long min, long max, int *st)
{
return strtoi(s, endp, b, min, max, st);
}
alx@debian:~/tmp$ gcc -Wall -Wextra -S bsd.c
bsd.c:1:10: fatal error: bsd/err.h: No such file or directory
1 | #include 
  |  ^~~
compilation terminated.

This seems consistent with the recent build system changes.  The bug is
probably there.

Have a lovely day!
Alex

-- 
<https://www.alejandro-colomar.es/>
Looking for a remote C programming job at the moment.


signature.asc
Description: PGP signature

Bug#1064909: libbsd-dev: Many functions (possibly all?) aren't available

[Alejandro Colomar]

Package: libbsd-dev
Version: 0.12.0-1
Severity: grave
Tags: upstream
Justification: renders package unusable
X-Debbugs-Cc: a...@kernel.org

Dear Guillem,

After upgrading to libbsd 0.12 today, several build systems that I use
started reporting many failures about libbsd functions.  The functions
seem to have disappeared.  I remember having seen that the build system
of libbsd has been recently tweaked, so I suspect one of those changes
might be the cause of the problem.

Here's a small reproducer:

$ cat bsd.c 
#include 

long
strtoi_(char *s, char **endp, int b, long min, long max, int *st)
{
return strtoi(s, endp, b, min, max, st);
}

Which reports the following error:

$ gcc -Wall -Wextra -S bsd.c 
bsd.c: In function ‘strtoi_’:
bsd.c:6:16: warning: implicit declaration of function ‘strtoi’; did you 
mean ‘strtoi_’? [-Wimplicit-function-declaration]
6 | return strtoi(s, endp, b, min, max, st);
  |^~
  |strtoi_

I've also seen errc(3bsd) disappear, and possibly many more functions.
If you need some help to reproduce this issue, just let me know.

BTW, thanks for updating strtoi/u(3) from NetBSD!  =)


Have a lovely day!
Alex


-- System Information:
Debian Release: trixie/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 6.8.0-rc5-alx+ (SMP w/24 CPU threads; PREEMPT)
Locale: LANG=C.utf8, LC_CTYPE=C.utf8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libbsd-dev depends on:
ii  libbsd00.12.0-1
ii  libmd-dev  1.1.0-2

libbsd-dev recommends no packages.

libbsd-dev suggests no packages.

-- no debconf information

Bug#1064645: bashrc: line 7: PS1: unbound variable

[Alejandro Colomar]

Package: bash
Version: 5.2.21-2
Severity: normal
X-Debbugs-Cc: a...@kernel.org

Dear Maintainer,

   * What led up to the situation?

Have a makefile that runs a shell with some strict flags:

$ ssh www cat tmp/Makefile
SHELL := /usr/bin/env
.SHELLFLAGS := -S bash -Eeuo pipefail -c

all:
echo foo

And run it via SSH:

$ ssh www make -C tmp
make: Entering directory '/home/alx/tmp'
echo foo
foo
/etc/bash.bashrc: line 7: PS1: unbound variable
make: Leaving directory '/home/alx/tmp'


   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?

Spuriour error messages about an unbound PS1.

   * What outcome did you expect instead?

No diagnostic messages related to .

Have a lovely day!
Alex

-- System Information:
Debian Release: trixie/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 6.8.0-rc5-alx+ (SMP w/24 CPU threads; PREEMPT)
Locale: LANG=C.utf8, LC_CTYPE=C.utf8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages bash depends on:
ii  base-files   13
ii  debianutils  5.16
ii  libc62.37-15
ii  libtinfo66.4+20240113-1

Versions of packages bash recommends:
ii  bash-completion  1:2.11-8

Versions of packages bash suggests:
pn  bash-doc  

-- no debconf information

Bug#1051551: thunderbird: When deleting a message, the list scrolls up a few messages.

[Alejandro Colomar]

Hi James!

On Thu, Feb 15, 2024 at 11:09:48PM +, James Addison wrote:
> Package: thunderbird
> Followup-For: Bug #1051551
> X-Debbugs-Cc: alx.manpa...@gmail.com, c.schoen...@t-online.de
> 
> On Sat, 09 Sep 2023 19:16:32 +0200, Alex wrote:
> > Since some recent version, every time I delete a mail, the list scrolls
> > up a few messages, and I need to manually scroll down again, every time.
> 
> I'm not 100% certain, so not setting a forwarded-to on this bug yet, but this
> sounds a lot like this upstream bug: 
> https://bugzilla.mozilla.org/show_bug.cgi?id=1857766
> 
> Does the description on that bugreport match the behaviour you found, Alex?

Hmmm, it could be; I'm not 100% sure either.  I moved to using mutt(1)
soon after reporting that bug, so I have forgotten some details.  Sorry.

> (someone also mentioned a vaguely-similar-sounding issue on debian-user
> yesterday, which is why I'm taking a brief look)

Thanks!

Have a lovely night,
Alex

-- 

Looking for a remote C programming job at the moment.


signature.asc
Description: PGP signature

Bug#1063916: RFP: freenginx -- a fork of nginx maintained by Maxim Dounin and the development community

[Alejandro Colomar]

[CC += Maxim]


On Wed, 14 Feb 2024 15:46:28 -0500 Jeffrey Walton  wrote:
> Package: wnpp
> Severity: wishlist
> X-Debbugs-CC: debian-de...@lists.debian.org
> 
> * Package name: freenginx
>   Version : 1.24.0
>   Upstream Author : Maxim Dounin and the development community
>   Section: web
> * URL : http://freenginx.org/
> * License : GPL
>   Programming Lang: C
>   Description : a fork of nginx maintained by Maxim Dounin and the
> development community
> 
> -

Is it really GPL (and if so, which version)?  I don't see any mentions
by Maxim that he would relicense it as GPL (but I would love it).

Have a lovely day!
Alex

-- 



signature.asc
Description: PGP signature

Bug#1063916: RFP: freenginx -- a fork of nginx maintained by Maxim Dounin and the development community

[Alejandro Colomar]

+1


signature.asc
Description: PGP signature

Bug#1060064: dir_colors.5: Spurious '+.' string in page

[Alejandro Colomar]

Package: manpages
Version: 6.05.01-1
Severity: minor
Tags: patch
X-Debbugs-Cc: a...@kernel.org

Dear Maintainer,

The Debian patch 0006-dir_colors.5.patch has a typo, which results in a
spurious string in the manual page:

$ man /usr/share/man/man5/dir_colors.5.gz | grep -C1 '+\.'
 ~/.dir_colors
+.   (Slackware, SuSE and RedHat only; ignored by GNU dircolors(1)
and thus Debian.)  Per‐user configuration file.

The patch for fixing this bug is here:


Have a lovely day,
Alex

-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 6.5.0-5-amd64 (SMP w/24 CPU threads; PREEMPT)
Locale: LANG=C.utf8, LC_CTYPE=C.utf8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

manpages depends on no packages.

manpages recommends no packages.

Versions of packages manpages suggests:
ii  man-db [man-browser]  2.12.0-1

-- no debconf information

Bug#208967: [docbook2man] Patch to get correct replacement for dashes/hyphen

[Alejandro Colomar]

Hi!

Here's a ping, reminding that this bug still affects Debian Trixie
(currently unstable).  I have uncommented the workaround in my
/etc/groff/man.local, because as maintainer of the Linux man-pages, I do
want to be able to check if there are problems in my manual pages.  As a
consequence, I can't search (/) for options and things that contain '-'
in manual pages that have this bug.

There's a patch, so what else do we need to fix the bug?  Can the patch
be offered to upstream, please?

Thanks,
Alex

On Sun, 10 Aug 2014 13:17:20 +0200 Joseph Herlant  wrote:
> Control: tags -1 +patch
> 
> Hi,
> 
> Please find attached the debdiff patch that should solve both #208967
> and #628751.
> 
> In short:  Current version of docbook2man's hyphen rendering makes
> lintian complain about "hyphen-used-as-minus-sign". This patch renders
> `-' as `\-' and `\-' as `\\\-', so we should have a correct output and
> lintian not complaining again.
> 
> This should solve a big amount of the current
> "hyphen-used-as-minus-sign" reports.
> 
> I wrote it as an NMU but I'd rather have it uploaded and integrated by
> official maintainers.
> 
> Tested on module-init-tools (the oldstable version which uses sgml)
> and it seems fine to me.
> Also tested on gnome-shell-pomodoro I am currently using sgml man
> pages with and it also works great!
> 
> Best,
> Joseph

-- 



signature.asc
Description: PGP signature

Bug#1052510: Ping: Bug#1052510: abook: double free detected in tcache 2

[Alejandro Colomar]

Ping

On Sat, Sep 23, 2023 at 04:53:18PM +0200, Alejandro Colomar wrote:
> Package: abook
> Version: 0.6.1-3
> Severity: normal
> Tags: upstream
> X-Debbugs-Cc: a...@kernel.org
> 
> Dear Maintainer,
> 
> abook(1) is freeing twice.  I can reproduce it with the following
> address book and command.
> 
> $ cat ./ab
> # abook addressbook file
> 
> [format]
> program=abook
> version=0.6.1
> 
> 
> [0]
> name=John Smith
> email=j...@example.com
> mobile=123123123
> nick=j
> groups=friends
> 
> 
> $ abook --convert --outformat mutt --infile ./ab
> alias -group \��L�friends j John Smith 
> free(): double free detected in tcache 2
> Aborted
> 
> 
> Thanks,
> Alex
> 
> 
> -- System Information:
> Debian Release: trixie/sid
>   APT prefers testing
>   APT policy: (500, 'testing'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 6.4.0-4-amd64 (SMP w/24 CPU threads; PREEMPT)
> Locale: LANG=C.utf8, LC_CTYPE=C.utf8 (charmap=UTF-8), LANGUAGE not set
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages abook depends on:
> ii  debconf [debconf-2.0]  1.5.82
> ii  libc6  2.37-8
> ii  libncursesw6   6.4+20230625-2
> ii  libreadline8   8.2-1.3
> ii  libtinfo6  6.4+20230625-2
> 
> abook recommends no packages.
> 
> abook suggests no packages.
> 
> -- debconf information excluded

-- 
<https://www.alejandro-colomar.es/>


signature.asc
Description: PGP signature

Bug#1052510: abook: double free detected in tcache 2

[Alejandro Colomar]

Package: abook
Version: 0.6.1-3
Severity: normal
Tags: upstream
X-Debbugs-Cc: a...@kernel.org

Dear Maintainer,

abook(1) is freeing twice.  I can reproduce it with the following
address book and command.

$ cat ./ab
# abook addressbook file

[format]
program=abook
version=0.6.1


[0]
name=John Smith
email=j...@example.com
mobile=123123123
nick=j
groups=friends


$ abook --convert --outformat mutt --infile ./ab
alias -group \��L�friends j John Smith 
free(): double free detected in tcache 2
Aborted


Thanks,
Alex


-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 6.4.0-4-amd64 (SMP w/24 CPU threads; PREEMPT)
Locale: LANG=C.utf8, LC_CTYPE=C.utf8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages abook depends on:
ii  debconf [debconf-2.0]  1.5.82
ii  libc6  2.37-8
ii  libncursesw6   6.4+20230625-2
ii  libreadline8   8.2-1.3
ii  libtinfo6  6.4+20230625-2

abook recommends no packages.

abook suggests no packages.

-- debconf information excluded

Bug#1051551: thunderbird: When deleting a message, the list scrolls up a few messages.

[Alejandro Colomar]

Hi Carsten,

On 2023-09-10 09:12, Carsten Schoenert wrote:
> Hello Alejandro,
> 
> Am 09.09.23 um 22:46 schrieb Alejandro Colomar:
>> Hi,
>>
>> Since some recent version, every time I delete a mail, the list scrolls
>> up a few messages, and I need to manually scroll down again, every time.
> 
> did tried to follow these steps?

I tried disabling the extensions (in case there was something that I
forgot about, because AFAIR, I don't use any), and it still misbehaves.

Next thing I can try is starting a new profile.  I'll update then.

Thanks,
Alex

> 
> https://wiki.debian.org/Thunderbird#Bug_Reporting_.2F_Issues
> 
> I can't reproduce this issues.

I also bought a new screen (1440p), and tweaked text size of many fonts,
and also a few other related settings, so it may be a combination of things.

I'll try a few things.  Maybe I end faster nuking all, and starting with a
clean install of thunderbird.

Cheers,
Alex

> 

-- 
<http://www.alejandro-colomar.es/>
GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1051551: thunderbird: When deleting a message, the list scrolls up a few messages.

[Alejandro Colomar]

Package: thunderbird
Version: 1:115.2.0-1
Severity: normal
X-Debbugs-Cc: alx.manpa...@gmail.com


Hi,

Since some recent version, every time I delete a mail, the list scrolls
up a few messages, and I need to manually scroll down again, every time.

Cheers,
Alex


-- System Information:
Debian Release: trixie/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.4.0-4-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages thunderbird depends on:
ii  debianutils  5.12
ii  fontconfig   2.14.2-5
ii  libasound2   1.2.9-2
ii  libatk1.0-0  2.49.91-2
ii  libc62.37-7
ii  libcairo-gobject21.17.8-3
ii  libcairo21.17.8-3
ii  libdbus-1-3  1.14.10-1
ii  libdbus-glib-1-2 0.112-3
ii  libevent-2.1-7   2.1.12-stable-8
ii  libffi8  3.4.4-1
ii  libfontconfig1   2.14.2-5
ii  libfreetype6 2.13.2+dfsg-1
ii  libgcc-s113.2.0-3
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-1+b1
ii  libglib2.0-0 2.77.3-1
ii  libgtk-3-0   3.24.38-4
ii  libnspr4 2:4.35-1.1
ii  libnss3  2:3.92-1
ii  libotr5  4.1.1-5
ii  libpango-1.0-0   1.51.0+ds-2
ii  librnp0  0.17.0-3
ii  libstdc++6   13.2.0-3
ii  libvpx7  1.12.0-1
ii  libx11-6 2:1.8.6-1
ii  libx11-xcb1  2:1.8.6-1
ii  libxcb-shm0  1.15-1
ii  libxcb1  1.15-1
ii  libxext6 2:1.3.4-1+b1
ii  libxrandr2   2:1.5.2-2+b1
ii  psmisc   23.6-1
ii  x11-utils7.7+5
ii  zlib1g   1:1.2.13.dfsg-3

Versions of packages thunderbird recommends:
ii  hunspell-en-us [hunspell-dictionary]  1:2020.12.07-2

Versions of packages thunderbird suggests:
ii  apparmor  3.0.12-1
pn  fonts-lyx 
ii  libgssapi-krb5-2  1.20.1-3

-- no debconf information

Bug#1051052: iwyu: New upstream version: 0.20

[Alejandro Colomar]

Package: iwyu
Version: 8.18-2
Severity: wishlist
X-Debbugs-Cc: alx.manpa...@gmail.com

Hi,

Would you mind packaging the new upstream version, 0.20?

Thanks,
Alex


-- System Information:
Debian Release: trixie/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.3.0-2-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages iwyu depends on:
ii  clang   1:14.0-55.7
ii  clang-141:14.0.6-12
ii  libc6   2.37-6
ii  libclang-cpp14  1:14.0.6-12
ii  libllvm14   1:14.0.6-12
ii  libstdc++6  13.1.0-9
ii  python3 3.11.4-5

iwyu recommends no packages.

iwyu suggests no packages.

-- no debconf information

Bug#1050831: wrk: No manual page

[Alejandro Colomar]

Package: wrk
Version: 4.1.0-3+b2
Severity: serious
Tags: upstream
Justification: Policy 12.1
X-Debbugs-Cc: alx.manpa...@gmail.com

Hi!

This program has no manual page.  :(

Cheers,
Alex

-- System Information:
Debian Release: trixie/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.3.0-2-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages wrk depends on:
ii  libc62.37-6
ii  libluajit-5.1-2  2.1.0~beta3+git20220320+dfsg-4.1
ii  libssl3  3.0.9-1

wrk recommends no packages.

wrk suggests no packages.

-- no debconf information

Bug#1042828: [Pkg-shadow-devel] Bug#1042828: manpage: obsolete reference in the shadow(5) man page

[Alejandro Colomar]

[CC += Tobias, Marcos]

Hi Andreas,

On 2023-08-01 16:14, Andreas Schwarz wrote:
> Package: passwd
> Version: 1:4.13+dfsg1-1+b1
> Severity: minor
> X-Debbugs-Cc: andreas.schw...@noris.de
> 
> Dear Maintainer,
> 
> The manpage shadow(5) refers to crypt(3), but this no longer exists.
> 
> This manpage was part of the manpages-dev package, as far as I can see 
> crypt(3) was last included in "Debian buster".

I'm on Debian Sid and see this:

$ apt-file find -x 'man/man3/crypt\.3\b'
libcrypt-dev: /usr/share/man/man3/crypt.3.gz
$ apt-file find -x 'man/man5/shadow\.5\b'
passwd: /usr/share/man/man5/shadow.5.gz

The Linux man-pages project has a crypt(3) page, but it is removed in the Debian
packaging due to a conflict with libcrypt-dev.  The commit where that happened
is the following one:


commit c56791e95a0759d58ded54150466f207c7cf3322
Author: Dr. Tobias Quathamer 
Date:   Tue Jul 9 20:12:48 2019 +0200

Update list of conflicting manpages

diff --git a/debian/rules b/debian/rules
index f38c428f7..5f963d152 100755
--- a/debian/rules
+++ b/debian/rules
@@ -22,6 +22,8 @@ override_dh_installman:
rm -f debian/manpages/usr/share/man/man4/sk98lin.4
# Start of automatically added files by debian/check-conflicts
rm -f debian/manpages/usr/share/man/man1/time.1
+   rm -f debian/manpages-dev/usr/share/man/man3/crypt.3
+   rm -f debian/manpages-dev/usr/share/man/man3/crypt_r.3
rm -f debian/manpages-dev/usr/share/man/man3/pthread_atfork.3
rm -f debian/manpages-dev/usr/share/man/man3/pthread_mutexattr_destroy.3
rm -f debian/manpages-dev/usr/share/man/man3/pthread_mutexattr_init.3


$ git describe --contains c56791e95a
debian/5.01-1~2


manpages-dev 5.01 first appeared in Bullseye, so Buster still shipped crypt(3)
in manpages-dev, as you experience.  The solution for you will be to install
libcrypt-dev, or complain to the manpages-dev Debian team.  :)

Cheers,
Alex


> 
> -- System Information:
> Debian Release: 12.0
>   APT prefers stable-security
>   APT policy: (500, 'stable-security'), (500, 'stable')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 6.1.0-10-amd64 (SMP w/8 CPU threads; PREEMPT)
> Kernel taint flags: TAINT_WARN
> Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not 
> set
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages passwd depends on:
> ii  libaudit1   1:3.0.9-1
> ii  libc6   2.36-9
> ii  libcrypt1   1:4.4.33-2
> ii  libpam-modules  1.5.2-6
> ii  libpam0g1.5.2-6
> ii  libselinux1 3.4-1+b6
> ii  libsemanage23.4-1+b5
> 
> Versions of packages passwd recommends:
> ii  sensible-utils  0.0.17+nmu1
> 
> passwd suggests no packages.
> 
> -- no debconf information
> 
> ___
> Pkg-shadow-devel mailing list
> pkg-shadow-de...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-shadow-devel

-- 

GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1041884: Acknowledgement (sct: segfault at e0)

[Alejandro Colomar]

Never mind.  My filesystem was full.  That was my problem.  I wrote
a program with an accidental infinite loop, and while debugging it,
a printf line started writing lines to somewhere in /opt, and I
forgot to kill it before writing 1 TB of garbage. :-)

Cheers,
Alex

On 2023-07-24 22:21, Debian Bug Tracking System wrote:
> Thank you for filing a new Bug report with Debian.
> 
> You can follow progress on this Bug here: 1041884: 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1041884.
> 
> This is an automatically generated reply to let you know your message
> has been received.
> 
> Your message is being forwarded to the package maintainers and other
> interested parties for their attention; they will reply in due course.
> 
> As you requested using X-Debbugs-CC, your message was also forwarded to
>   alx.manpa...@gmail.com
> (after having been given a Bug report number, if it did not have one).
> 
> Your message has been sent to the package maintainer(s):
>  Jacob Adams 
> 
> If you wish to submit further information on this problem, please
> send it to 1041...@bugs.debian.org.
> 
> Please do not send mail to ow...@bugs.debian.org unless you wish
> to report a problem with the Bug-tracking system.
> 

-- 

GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1041884: sct: segfault at e0

[Alejandro Colomar]

Package: sct
Version: 1.3-1+b1
Severity: grave
Justification: causes non-serious data loss
X-Debbugs-Cc: alx.manpa...@gmail.com


Hi!

I'm not sure if this is a problem with sct(1), but I got an error that
mentions sct, so I'm reporting here in case it's related to sct(1).

Here's the error message as reported by dmesg:

$ sudo dmesg | tail -n2
[  432.416640] sct[3477]: segfault at e0 ip 555a975ee0fd sp 
7ffe887af340 error 4 in sct[555a975ee000+1000] likely on CPU 1 (core 1, 
socket 0)
[  432.416669] Code: 2f 00 00 66 90 00 00 00 00 00 00 00 00 41 57 41 56 41 55 
49 89 f5 41 54 55 53 89 fb 31 ff 48 83 ec 28 e8 86 ff ff ff 48 89 c5 <48> 63 80 
e0 00 00 00 48 89 ef 48 c1 e0 07 48 03 85 e8 00 00 00 48

My computer got a black screen where the only thing I could do is
REISUB.  It had a few problems booting after that for a few times.  I'm
still unsure about the cause, but this is the most notable error report
I've seen.

I have `sct 3000` in my .bash_aliases, so that just by opening a
terminal I get a nice screen temperature.  It has worked for a long
time...

Cheers,
Alex


-- System Information:
Debian Release: trixie/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.3.0-2-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages sct depends on:
ii  libc6   2.37-6
ii  libx11-62:1.8.6-1
ii  libxrandr2  2:1.5.2-2+b1

sct recommends no packages.

sct suggests no packages.

-- no debconf information

Bug#1036648: zlib1g-dev: Missing manual pages for the functions

[Alejandro Colomar]

On 5/23/23 22:01, Mark Brown wrote:
> On Tue, May 23, 2023 at 09:57:42PM +0200, Alejandro Colomar wrote:
> 
>> I'm going to use zlib in the near future in my job, so I can write some
>> manual pages for the functions I use.  I'll keep upstream in the loop,
>> in case they want to pick the pages.  I will probably only write pages
>> for the functions I use, though, of course.
> 
> That'd be excellent!

Hi Mark!

I've already got one page written.  Since we're so close to the release of
Bookworm, I guess it's not allowed, not even if it's fixing a policy
violation, and is only documentation.

But maybe it would be interesting to backport (as a bugfix) the manual pages
once the release is made?

Here's the pull request to the upstream project, which I hope will go it
smoothly: <https://github.com/madler/zlib/pull/821>.

Cheers,
Alex

-- 
<http://www.alejandro-colomar.es/>
GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1036648: zlib1g-dev: Missing manual pages for the functions

[Alejandro Colomar]

Hi Mark,

On 5/23/23 21:45, Mark Brown wrote:
> severity 1036648 wishlist
> kthxbye
> 
> On Tue, May 23, 2023 at 09:26:57PM +0200, Alejandro Colomar wrote:
> 
>> This library lacks manual pages for the available functions, which seems
>> to be a violation of the Debian Policy.
> 
> This is an *extremely* widespread violation of policy at this point...
> it'd be nice, certainly.

Heh, that's true.  :')

I'm going to use zlib in the near future in my job, so I can write some
manual pages for the functions I use.  I'll keep upstream in the loop,
in case they want to pick the pages.  I will probably only write pages
for the functions I use, though, of course.

Cheers,
Alex

-- 
<http://www.alejandro-colomar.es/>
GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1036648: zlib1g-dev: Missing manual pages for the functions

[Alejandro Colomar]

Package: zlib1g-dev
Version: 1:1.2.13.dfsg-1
Severity: normal
Tags: upstream
X-Debbugs-Cc: alx.manpa...@gmail.com

Dear maintainer,

This library lacks manual pages for the available functions, which seems
to be a violation of the Debian Policy.

Cheers,
Alex


-- System Information:
Debian Release: 12.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.1.0-9-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages zlib1g-dev depends on:
ii  libc6-dev [libc-dev]  2.36-9
ii  zlib1g1:1.2.13.dfsg-1

zlib1g-dev recommends no packages.

zlib1g-dev suggests no packages.

-- no debconf information

Bug#1036334: bugz.1: Missing SEE ALSO

[Alejandro Colomar]

Package: bugz
Version: 0.13-3
Severity: normal
Tags: upstream
X-Debbugs-Cc: Alastair Tse , Markus Meier 
, Dylan Baker , William Hubbs 
, a...@kernel.org


Hi!

The manual page doesn't have a SEE ALSO section, so it's hard to find
the documentation for the config file.  I see that the master branch has
this issue fixed, but there hasn't been a release since then (2017).

Is the upstream project still maintained?

Cheers,
Alex

-- System Information:
Debian Release: 12.0
merged-usr: no
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-9-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=C.utf8, LC_CTYPE=C.utf8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages bugz depends on:
ii  python3  3.11.2-1+b1

bugz recommends no packages.

bugz suggests no packages.

-- no debconf information

Bug#1032393: [Pkg-shadow-devel] Bug#1032393: [PATCH v2 2/2] debian/control: Add libbsd-dev and pkg-config

[Alejandro Colomar]

Hi Paul,

On 3/12/23 23:24, Alejandro Colomar wrote:
> Hi Paul,
> 
> On 3/12/23 22:50, Paul Eggert wrote:
>> On 2023-03-12 08:28, Alejandro Colomar wrote:
>>
>>> I've pushed a signed tag paul1, so you can safely check that the
>>> repo is mine (since I don't have HTTPS).
>>
>> Thanks, I'm not sure what exactly this means as I don't contribute to 
>> shadow-devel. As far as the remaining patches go, please use your best 
>> judgment as I'm running low on time to worry about this.
> 
> Okay.  shadow accepts patches as Github pull requests[1], so I'll open a
> pull request with the patches I already took from you, plus the
> remaining ones which I'll tweak a bit following your suggestion.  When
> it's done, I'll CC you so you can have a look at the final patches.
> 
> Thanks for your patches!  :-)

In case you didn't receive a notification (I mentioned you on Github),
here's a link to the pull request:
<https://github.com/shadow-maint/shadow/pull/681>

Cheers,

Alex

> 
> Alex
> 
> 
> [1]:  <https://github.com/shadow-maint/shadow>
> 

-- 
<http://www.alejandro-colomar.es/>
GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1032393: [Pkg-shadow-devel] Bug#1032393: [PATCH v2 2/2] debian/control: Add libbsd-dev and pkg-config

[Alejandro Colomar]

Hi Paul,

On 3/12/23 22:50, Paul Eggert wrote:
> On 2023-03-12 08:28, Alejandro Colomar wrote:
> 
>> I've pushed a signed tag paul1, so you can safely check that the
>> repo is mine (since I don't have HTTPS).
> 
> Thanks, I'm not sure what exactly this means as I don't contribute to 
> shadow-devel. As far as the remaining patches go, please use your best 
> judgment as I'm running low on time to worry about this.

Okay.  shadow accepts patches as Github pull requests[1], so I'll open a
pull request with the patches I already took from you, plus the
remaining ones which I'll tweak a bit following your suggestion.  When
it's done, I'll CC you so you can have a look at the final patches.

Thanks for your patches!  :-)

Alex


[1]:  <https://github.com/shadow-maint/shadow>

-- 
<http://www.alejandro-colomar.es/>
GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1032393: [Pkg-shadow-devel] Bug#1032393: [PATCH v2 2/2] debian/control: Add libbsd-dev and pkg-config

[Alejandro Colomar]

Hi Bálint,

On 3/12/23 20:22, Bálint Réczey wrote:
> Hi Alejandro,
> 
> Alejandro Colomar  ezt írta (időpont: 2023.
> márc. 12., V, 16:52):
>>
>> Hi Bálint,
>>
>> On 3/12/23 16:38, Bálint Réczey wrote:
>>>> 142 lines of a function definition are not something I'd consider easy to
>>>> maintain.  Is it a big deal to add another dependency?  I'd say it's a
>>>> bigger deal to copy verbatim so many lines of code, and sync them from
>>>> time to time from libbsd (or OpenBSD) just to bring in any bugfixes they
>>>> apply.  That's exactly the purpose of libbsd, so I think relying on them
>>>> should be fine.
>>>
>>> The function does not change often. It changed two times in the last 13 
>>> years:
>>> https://gitlab.freedesktop.org/libbsd/libbsd/-/commits/main/src/readpassphrase.c
>>>
>>> I'd be happy to add a GitHub Action job or an autopkgtest in Debian to
>>> check if shadow's local copy needs an update.
>>>
>>> Depending on libbsd would pull the library into every single docker
>>> container image increasing their size and would make libbsd part of
>>> the pseudo-essential set, thus I prefer not depending on it for a few
>>> lines of code.
>>
>> libbsd0 is only ~ 200 kB (installed size).  That should be
>> insignificant compared to a Debian docker image, or even to the
>> shadow packages.
>>
>> libsubid4 is ~ 300 kB
>> uidmap is~ 300 kB
>> login is ~ 2.6 MB
>> passwd is~ 2.8 kB
>>
>> And the unstable-slim Debian Docker image is around 28 MB
>> (compressed size).
> 
> Yes, and libsubid4 and uidmap are not present in the docker images.
> 
>>
>> Moreover, having this libbsd part of the pseudo-essential set would
>> allow many other packages to rely on it, thus deduplicating the
>> copies that some projects currently do to avoid depending on it,
>> so the total distribution size could even shrink in the long term.
> 
> Developers of Debian are expected to be very conservative regarding
> expanding the (pseudo-) essential set:
> https://www.debian.org/doc/debian-policy/ch-binary.html#essential-packages
> 
> I value keeping the essential set minimal above providing one more
> shared library for potential reverse dependencies, too.
> I'd like to hear more people's opinion from the shadow project and if
> the project insists on adding the libbsd dependency I will bring the
> topic to debian-devel following the spirit of the Debian Policy
> offering to either carry a copy of readpassphrase.c as a patch in the
> Debian package or adding the libbsd dependency.

I've CCd Guillem to know his opinion too.

IMO, the functionallity provided by libbsd is essential; so much that
I think glibc should pick it.  However, now that libbsd has it, it's
not so important to add it to glibc, but then libbsd has to have a
status similar to libc.

We've fixed many bugs in shadow with the help of libbsd, and I think
many projects would benefit from having it available.

But of course, that needs agreement of libbsd's maintainer (Guillem),
and the debian-devel team.  Let's see what they and the shadow
maintainers think.

Cheers,
Alex

-- 
<http://www.alejandro-colomar.es/>
GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1032393: [Pkg-shadow-devel] Bug#1032393: [PATCH v2 2/2] debian/control: Add libbsd-dev and pkg-config

[Alejandro Colomar]

On 3/12/23 16:52, Alejandro Colomar wrote:

> libsubid4 is ~ 300 kB
> uidmap is~ 300 kB
> login is ~ 2.6 MB
> passwd is~ 2.8 kB

I meant 2.8 MB :)
> > 

-- 
<http://www.alejandro-colomar.es/>
GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1032393: [Pkg-shadow-devel] Bug#1032393: [PATCH v2 2/2] debian/control: Add libbsd-dev and pkg-config

[Alejandro Colomar]

Hi Bálint,

On 3/12/23 16:38, Bálint Réczey wrote:
>> 142 lines of a function definition are not something I'd consider easy to
>> maintain.  Is it a big deal to add another dependency?  I'd say it's a
>> bigger deal to copy verbatim so many lines of code, and sync them from
>> time to time from libbsd (or OpenBSD) just to bring in any bugfixes they
>> apply.  That's exactly the purpose of libbsd, so I think relying on them
>> should be fine.
> 
> The function does not change often. It changed two times in the last 13 years:
> https://gitlab.freedesktop.org/libbsd/libbsd/-/commits/main/src/readpassphrase.c
> 
> I'd be happy to add a GitHub Action job or an autopkgtest in Debian to
> check if shadow's local copy needs an update.
> 
> Depending on libbsd would pull the library into every single docker
> container image increasing their size and would make libbsd part of
> the pseudo-essential set, thus I prefer not depending on it for a few
> lines of code.

libbsd0 is only ~ 200 kB (installed size).  That should be
insignificant compared to a Debian docker image, or even to the
shadow packages.

libsubid4 is ~ 300 kB
uidmap is~ 300 kB
login is ~ 2.6 MB
passwd is~ 2.8 kB

And the unstable-slim Debian Docker image is around 28 MB
(compressed size).

Moreover, having this libbsd part of the pseudo-essential set would
allow many other packages to rely on it, thus deduplicating the
copies that some projects currently do to avoid depending on it,
so the total distribution size could even shrink in the long term.

Cheers,

Alex

-- 

GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1032393: [Pkg-shadow-devel] Bug#1032393: [PATCH v2 2/2] debian/control: Add libbsd-dev and pkg-config

[Alejandro Colomar]

On 3/12/23 13:54, Alejandro Colomar wrote:
> Hi Paul,
> 
> On 3/12/23 02:44, Paul Eggert wrote:
>> On 2023-03-11 14:02, Alejandro Colomar wrote:
>>> we should use "%s" (if we go the way of snprintf(3)).
>>
>> Yes, thanks for catching that. However, I came up with a better way that 
>> avoids snprintf (and strlcpy) entirely both here and the other place I 
>> used snprintf.
>>
>> Attached is a revised set of patches that addresses the comments you 
>> made and embodies my followups.
> 
> I've applied patches 1, 2, 3, and 4 to my repo (I'll take care of them,
> and forward them to the maintainers).  You can rebase to
> <http://www.alejandro-colomar.es/src/alx/shadow/shadow.git/log/?h=paul>

I've pushed a signed tag paul1, so you can safely check that the
repo is mine (since I don't have HTTPS).

<http://www.alejandro-colomar.es/src/alx/shadow/shadow.git/tag/?h=paul1>

$ git show paul1
tag paul1
Tagger: Alejandro Colomar 
Date:   Sun Mar 12 16:24:54 2023 +0100

First round of patches applied from Paul Eggert.
-BEGIN PGP SIGNATURE-

iQIzBAABCgAdFiEE6jqH8KTroDDkXfJAnowa+77/2zIFAmQN7tsACgkQnowa+77/
2zJUNg/+OTaAFD276I8DHo/HvOtwPuKWiwcB7u0Yp4gdzkcbU/AGZ5S0xpdqbsIP
IWgiR402NIPv5zfQPA/v5vg0UNHxK6pQx2vhIUWsm0awG1m+N0+4VifXFbWo+LoY
bwxocWnEQJS8fIzK6YKi1CMw5++LKtx/orygZF/tfEQIVSTey/AktjaQY6OM4Yrb
U4HN9w0M5PELuyUl5v92XGSmSPxUDR5b3UdJ88Pz4wW1mnSOl4DpDdmFhVjzRkQp
1MBdB2OM4l5oCxSWPguYTyRYF2qOdVbZhxujPx0ob8uOzV78+plEas5gYYRxtIwo
ymcPLvet7qXfr5JE0I8vIt8AIXBRdyvdWydyaZOQecwCr5gqW0XTmo84cVzcTJ4q
4wqpJ4N9MODiolDYhDr97CN2D9DY0jeKvFj1vTdy6lC8nxWR9E55TuFXur7AEXTJ
TP9IxBK/7IoR7D9MidSmyq9zuHcDr3lkMEvHWLDfzYoFsI5fNeumyW52ylOUs7CV
u6BpWQpX/bPvUR+p1KuEPnP/nAzDpjDdlWWmd6cdTvu1H1JJCyFwjO7GVhts0JLF
LkxFiwHF8XmEz6g5HOYL16LpuClUtIAOEP9YXCpaiF1jROHjkErFm2YjEbtQMSZD
u5Ea8or9RVFQTWgbRHS4+SfmN8292gR9QxmU6Xhxmz3CldiqypM=
=aDa2
-END PGP SIGNATURE-

commit 67be4a8f2585c8af423e358efc4934291880a900 (HEAD -> paul, tag: paul1, 
alx/paul)

Cheers,

Alex

> 
> For the rest of the patches, I'll send some comments.
> 
> Thanks!
> 
> Alex
> 

-- 
<http://www.alejandro-colomar.es/>
GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1032393: [Pkg-shadow-devel] Bug#1032393: [PATCH v2 2/2] debian/control: Add libbsd-dev and pkg-config

[Alejandro Colomar]

Hi Paul,

On 3/12/23 02:44, Paul Eggert wrote:
> From 9ebf228fb33f66d248b230d23b633800267e5a16 Mon Sep 17 00:00:00 2001
> From: Paul Eggert 
> Date: Sat, 11 Mar 2023 10:34:21 -0800
> Subject: [PATCH 8/8] Fix su silent truncation
> 
> * src/su.c (check_perms): Do not silently truncate user name.
> 
> Signed-off-by: Paul Eggert 
> ---
>  src/su.c | 10 --
>  1 file changed, 8 insertions(+), 2 deletions(-)
> 
> diff --git a/src/su.c b/src/su.c
> index 9c134a9b..112be456 100644
> --- a/src/su.c
> +++ b/src/su.c
> @@ -658,7 +658,14 @@ static /*@only@*/struct passwd * check_perms (void)
>   SYSLOG ((LOG_INFO,
>"Change user from '%s' to '%s' as requested by PAM",
>name, tmp_name));
> - strlcpy (name, tmp_name, sizeof(name));
> + if (sizeof name <= strnlen (tmp_name, sizeof name)) {

strnlen(3)'s output is limited by the second argument, which makes
the previous condition to always be false, AFAICS.  I guess you
wanted to call strlen(3)?  Which BTW we can, since we use "%s" with
tmp_name in the previous line, so we know it's a string (or we
would have already crashed --or worse--).

Cheers,

Alex

> + fprintf (stderr, _("Overlong user name '%s'\n"),
> +  tmp_name);
> + SYSLOG ((LOG_NOTICE, "Overlong user name '%s'",
> +  tmp_name));
> + su_failure (caller_tty, true);
> + }
> + strcpy (name, tmp_name);
>   pw = xgetpwnam (name);
>   if (NULL == pw) {
>   (void) fprintf (stderr,
> @@ -1213,4 +1220,3 @@ int main (int argc, char **argv)
>  
>   return (errno == ENOENT ? E_CMD_NOTFOUND : E_CMD_NOEXEC);
>  }
> -
> -- 
> 2.37.2
> 


-- 

GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1032393: [Pkg-shadow-devel] Bug#1032393: [PATCH v2 2/2] debian/control: Add libbsd-dev and pkg-config

[Alejandro Colomar]

Hi Paul,

On 3/12/23 02:44, Paul Eggert wrote:
> From fab3bcdcb3f38c7f6f5c326f4ceafb3ea54bba73 Mon Sep 17 00:00:00 2001
> From: Paul Eggert 
> Date: Sat, 11 Mar 2023 10:07:32 -0800
> Subject: [PATCH 7/8] Fix is_my_tty overruns and truncations

Is there any chance those can be fixed individually?  The patch
is rather long, and complex to review.  Maybe it's not possible
and all fixes depend on each other; if so, please confirm.  But
if it's possible, I'd like to review it split.

> 
> * libmisc/utmp.c (is_my_tty): Declare the parameter
> as a char array not char *, as it is not necessarily null-terminated.
> Avoid a read overrun when reading ut_utname.  Do not silently truncate
> the string returned by ttyname; instead, do not cache an overlong
> ttyname, as the behavior is correct in this case (albeit slower).
> Use strnlen + strcpy instead of strlcpy to avoid polluting the
> cache with truncated data.
> 
> Signed-off-by: Paul Eggert 
> ---
>  libmisc/utmp.c | 42 ++
>  1 file changed, 22 insertions(+), 20 deletions(-)
> 
> diff --git a/libmisc/utmp.c b/libmisc/utmp.c
> index ff6acee0..bf7e5675 100644
> --- a/libmisc/utmp.c
> +++ b/libmisc/utmp.c
> @@ -24,36 +24,38 @@
>  
>  #ident "$Id$"
>  
> +enum { UT_LINE_LEN = sizeof (getutent ()->ut_line) };

Isn't UT_LINESIZE (from , see utmp(5)) what you want?

alx@asus5775:~/src/linux/man-pages/man-pages/main$ grepc -tt -x. utmp man5
man5/utmp.5:72:
struct utmp {
short   ut_type;  /* Type of record */
pid_t   ut_pid;   /* PID of login process */
charut_line[UT_LINESIZE]; /* Device name of tty \- "/dev/" */
charut_id[4]; /* Terminal name suffix,
 or inittab(5) ID */
charut_user[UT_NAMESIZE]; /* Username */
charut_host[UT_HOSTSIZE]; /* Hostname for remote login, or
 kernel version for run\-level
 messages */
struct  exit_status ut_exit;  /* Exit status of a process
 marked as DEAD_PROCESS; not
 used by Linux init(1) */
/* The ut_session and ut_tv fields must be the same size when
   compiled 32\- and 64\-bit.  This allows data files and shared
   memory to be shared between 32\- and 64\-bit applications. */
#if __WORDSIZE == 64 && defined __WORDSIZE_COMPAT32
int32_t ut_session;   /* Session ID (\fBgetsid\fP(2)),
 used for windowing */
struct {
int32_t tv_sec;   /* Seconds */
int32_t tv_usec;  /* Microseconds */
} ut_tv;  /* Time entry was made */
#else
 long   ut_session;   /* Session ID */
 struct timeval ut_tv;/* Time entry was made */
#endif

int32_t ut_addr_v6[4];/* Internet address of remote
 host; IPv4 address uses
 just ut_addr_v6[0] */
char __unused[20];/* Reserved for future use */
};


>  
>  /*
>   * is_my_tty -- determine if "tty" is the same TTY stdin is using
>   */
> -static bool is_my_tty (const char *tty)
> +static bool is_my_tty (const char tty[UT_LINE_LEN])
>  {
> - /* full_tty shall be at least sizeof utmp.ut_line + 5 */
> - char full_tty[200];
> - /* tmptty shall be bigger than full_tty */
> - static char tmptty[sizeof (full_tty)+1];
> -
> - if ('/' != *tty) {
> - (void) snprintf (full_tty, sizeof full_tty, "/dev/%s", tty);
> - tty = _tty[0];
> - }
> + /* A null-terminated copy of tty, prefixed with "/dev/" if tty
> +is not absolute.  There is no need for snprintf, as sprintf
> +cannot overrun.  */
> + char full_tty[sizeof "/dev/" + UT_LINE_LEN];
> + (void) sprintf (full_tty, "%s%.*s", '/' == *tty ? "" : "/dev/",
> + UT_LINE_LEN, tty);

To be honest, I still prefer stpcpy(3).  Avoiding one call is
probably not even an optimization, since sprintf(3) internals
will counter any gains, right?

I think the following reads simpler, and hopefully it's even
faster:

p = full_tty;
*p = '\0';
if (tty[0] == '/')
p = stpcpy(p, "/dev/");
strncat(p, tty, UT_LINESIZE);

After writing, since shadow isn't performance-critical, and
32 bytes will probably not take too much to catenate, I
realized we could just use strcpy(3) instead of stpcpy(3),
to simplify even more:

full_tty[0] = '\0';
if (tty[0] == '/')
strcpy(full_tty, "/dev/");
strncat(full_tty, tty, UT_LINESIZE);

>  
> - if ('\0' == tmptty[0]) {
> - const char *tname = ttyname (STDIN_FILENO);
> - if (NULL != tname)
> - (void) strlcpy (tmptty, tname, sizeof tmptty);
> - }
> + /* Cache of ttyname, valid if tmptty[0].  */
> + static char tmptty[UT_LINE_LEN + 1];
>  
> + const char *tname;
>   if 

Bug#1032393: [Pkg-shadow-devel] Bug#1032393: [PATCH v2 2/2] debian/control: Add libbsd-dev and pkg-config

[Alejandro Colomar]

Hi Paul,

On 3/12/23 02:44, Paul Eggert wrote:
> From f3514f26297e884a00d4fb29191bd9978eb03e7b Mon Sep 17 00:00:00 2001
> From: Paul Eggert 
> Date: Sat, 11 Mar 2023 00:42:29 -0800
> Subject: [PATCH 6/8] Fix crash with large timestamps
> 
> * libmisc/date_to_str.c (date_to_str): Do not crash if gmtime
> returns NULL because the timestamp is far in the future.
> Instead, use a dummy struct tm * to pacify any pedantic runtime.
> Simplify by always calling strftime, instead of sometimes strftime
> and sometimes strlcpy.
> 
> Signed-off-by: Paul Eggert 
> ---
>  libmisc/date_to_str.c | 19 +++
>  1 file changed, 11 insertions(+), 8 deletions(-)
> 
> diff --git a/libmisc/date_to_str.c b/libmisc/date_to_str.c
> index f3b9dc76..0840c38c 100644
> --- a/libmisc/date_to_str.c
> +++ b/libmisc/date_to_str.c
> @@ -35,13 +35,16 @@
>  
>  void date_to_str (size_t size, char buf[size], long date)
>  {
> - time_t t;
> + time_t t = date;
> + struct tm *tm = gmtime ();
>  
> - t = date;
> - if (date < 0) {
> - (void) strlcpy (buf, "never", size);
> - } else {
> - (void) strftime (buf, size, "%Y-%m-%d", gmtime ());
> - buf[size - 1] = '\0';
> - }

Please split the patch into two: one that fixes the UB,
and another that removes the strlcpy(3) calls.  They
can be done independently, and I'm not convinced by your
measurement of simplicity :)


On 3/12/23 02:38, Paul Eggert wrote:
> It depends on how one measures simplicity. The reader will need to know 
> strftime's API regardless; requiring the reader to also know strlcpy's 
> API makes the reader's job harder.

I expect readers to easily learn that from the relevant man page :)
Once you know what strlcpy(3) is, that is, a function that copies a
string with truncation, it's straightforward to read.  Knowing
strftime(3)'s details is more obscure for those who are not time
nerds :-)

> 
> Also, it's less machine code to call just the one function (if one cares 
> about simplicity of debugging .

Heh, I could count with my fingers the number of days I've used
gdb(1) in my entire life :D.  Hail fprintf(3) and stderr!  Which
BTW benefit from expanded conditionals, rather than ternary ops.

> 
> If you still prefer calling two different functions instead of just one, 
> feel free to modify it to use plain strcpy. strlcpy isn't needed here as 
> the destination buffers are all big enough.

Do we know that?  The API receives a size as a parameter, which
could perfectly be 1 (well, I know we're not going to do that,
but since it's a generic API, I wouldn't rely on current sizes).

Cheers,

Alex

> To be honest though I like 
> it the way it is (though it could use a comment; I'll add that).

> + /* A dummy whose address can be passed to strftime to avoid
> +undefined behavior.  It's OK for it to be uninitialized
> +since no conversion specs are used.  */
> + struct tm dummy;
> +
> + (void) strftime (buf, size,
> +  date < 0 ? "never" : tm ? "%Y-%m-%d" : "future",
> +  tm ? tm : );
> + buf[size - 1] = '\0';
>  }
> -- 
> 2.37.2
> 


-- 

GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1032393: [Pkg-shadow-devel] Bug#1032393: [PATCH v2 2/2] debian/control: Add libbsd-dev and pkg-config

[Alejandro Colomar]

Hi Paul,

On 3/12/23 02:44, Paul Eggert wrote:
> From 54fac7560f87a134c4d3045ce7048f4819c4e492 Mon Sep 17 00:00:00 2001
> From: Paul Eggert 
> Date: Sat, 11 Mar 2023 00:38:24 -0800
> Subject: [PATCH 5/8] Avoid silent truncation of console file data
> 
> * libmisc/console.c (is_listed): Rework so that there is no
> fixed-size buffer, and no need to use fgets or strlcpy or strtok.
> Instead, the code works with arbitrary-sized input,
> without silently truncating data or mishandling NUL
> bytes in the console file.
> 
> Signed-off-by: Paul Eggert 
> ---
>  libmisc/console.c | 41 -
>  1 file changed, 20 insertions(+), 21 deletions(-)
> 
> diff --git a/libmisc/console.c b/libmisc/console.c
> index 7e2132dd..8264e1a3 100644
> --- a/libmisc/console.c
> +++ b/libmisc/console.c
> @@ -24,7 +24,6 @@
>  static bool is_listed (const char *cfgin, const char *tty, bool def)
>  {
>   FILE *fp;
> - char buf[1024], *s;
>   const char *cons;
>  
>   /*
> @@ -43,17 +42,17 @@ static bool is_listed (const char *cfgin, const char 
> *tty, bool def)
>*/
>  
>   if (*cons != '/') {
> - char *pbuf;
> - strlcpy (buf, cons, sizeof (buf));
> - pbuf = [0];
> - while ((s = strtok (pbuf, ":")) != NULL) {
> - if (strcmp (s, tty) == 0) {
> + size_t ttylen = strlen (tty);

Please separate the initialization from the declaration, and
leave a blank line in between.

> + for (;;) {
> + if (strncmp (cons, tty, ttylen) == 0
> + && (cons[ttylen] == ':' || !cons[ttylen])) {
>   return true;
>   }
> -
> - pbuf = NULL;
> + cons = strchr (cons, ':');
> + if (!cons)
> + return false;
> + cons++;
>   }
> - return false;
>   }
>  
>   /*
> @@ -70,21 +69,22 @@ static bool is_listed (const char *cfgin, const char 
> *tty, bool def)
>* See if this tty is listed in the console file.
>*/
>  
> - while (fgets (buf, sizeof (buf), fp) != NULL) {
> - /* Remove optional trailing '\n'. */
> - buf[strcspn (buf, "\n")] = '\0';
> - if (strcmp (buf, tty) == 0) {
> - (void) fclose (fp);
> - return true;
> + const char *tp = tty;
> + bool listed = false;

Please -Wdeclaration-after-statement.  If the declaration is
so far that it helps mix declarations with code, it may be the
time to split something into a helper function...

Cheers,

Alex

> + for (int c; 0 <= (c = getc (fp)); ) {
> + if (c == '\n') {
> + if (tp && !*tp) {
> + listed = true;
> + break;
> + }
> + tp = tty;
> + } else if (tp) {
> + tp = *tp == c && c ? tp + 1 : NULL;
>   }
>   }
>  
> - /*
> -  * This tty isn't a console.
> -  */
> -
>   (void) fclose (fp);
> - return false;
> + return listed;
>  }
>  
>  /*
> @@ -105,4 +105,3 @@ bool console (const char *tty)
>  
>   return is_listed ("CONSOLE", tty, true);
>  }
> -
> -- 
> 2.37.2
> 


-- 

GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1032393: [Pkg-shadow-devel] Bug#1032393: [PATCH v2 2/2] debian/control: Add libbsd-dev and pkg-config

[Alejandro Colomar]

Hi Paul,

On 3/12/23 02:44, Paul Eggert wrote:
> On 2023-03-11 14:02, Alejandro Colomar wrote:
>> we should use "%s" (if we go the way of snprintf(3)).
> 
> Yes, thanks for catching that. However, I came up with a better way that 
> avoids snprintf (and strlcpy) entirely both here and the other place I 
> used snprintf.
> 
> Attached is a revised set of patches that addresses the comments you 
> made and embodies my followups.

I've applied patches 1, 2, 3, and 4 to my repo (I'll take care of them,
and forward them to the maintainers).  You can rebase to
<http://www.alejandro-colomar.es/src/alx/shadow/shadow.git/log/?h=paul>

For the rest of the patches, I'll send some comments.

Thanks!

Alex

-- 
<http://www.alejandro-colomar.es/>
GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1032393: [Pkg-shadow-devel] Bug#1032393: [PATCH v2 2/2] debian/control: Add libbsd-dev and pkg-config

[Alejandro Colomar]

On 3/11/23 23:38, Paul Eggert wrote:
> On 2023-03-11 13:59, Alejandro Colomar wrote:
>> If the function is allowed
>> to dereference, then NULL is not allowed, but if the values are
>> uninitialized, then reading any of them should also trigger UB, no?
> 
> Sure, but the standard says that strftime reads only the struct tm 
> members needed to interpret the format. If the format contains no 
> conversion specs, strftime reads no struct tm members and thus there is 
> no UB even if the struct tm is entirely uninitialized.

Yeah, my point then is that if you don't read members, you don't even
need to dereference.  However, I see that glibc takes a copy, which is
a reason to dereference without reading any values.  So, yes, you're
right ;)

-- 
<http://www.alejandro-colomar.es/>
GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1032393: [Pkg-shadow-devel] Bug#1032393: [PATCH v2 2/2] debian/control: Add libbsd-dev and pkg-config

[Alejandro Colomar]

On 3/11/23 23:34, Paul Eggert wrote:
> On 2023-03-11 14:18, Alejandro Colomar wrote:
> 
>> What I'm not sure is that strftime(3) requires nonnull.
> 
> glibc's strftime implementation segfaults if you pass a null pointer, so 
> we can't pass NULL regardless of whether the strftime API in time.h uses 
> __attribute__ ((nonnull))'.

Hmm, please fix the API :-)

So, yes, then that dummy seems to be necessary.  However, then I wonder
if the patch is really "simplifying".  I think strlcpy(3) was simpler.

-- 
<http://www.alejandro-colomar.es/>
GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1032393: [Pkg-shadow-devel] Bug#1032393: [PATCH v2 2/2] debian/control: Add libbsd-dev and pkg-config

[Alejandro Colomar]

Hi Paul,

On 3/11/23 23:08, Paul Eggert wrote:
> On 2023-03-11 13:59, Alejandro Colomar wrote:
>> Unless the standard specifically allows us to do so, but I can't find
>> anything clear.
> 
> It's pretty clear if you're a time nerd like me. :-)

:-)

> The standard for 
> strftime says "The appropriate characters are determined using the 
> LC_TIME category of the current locale and by the values of zero or more 
> members of the broken-down time structure pointed to by timeptr, as 
> specified in brackets in the description. If any of the specified values 
> are outside the normal range, the characters stored are unspecified."
> 
> The "zero" means that if no conversion specs are present in the format 
> string, then no struct tm members are examined, and it's therefore OK 
> for all members to be uninitialized if no conversion specs are present.

Hmmm, might make sense.  I'm thinking of the following code:

int foo(bool x, int *_Nonnull i)
{
if (!x)
return *i;

return 42;
}

Some compiler might decide to read-ahead the contents of *i knowing that
it can't be NULL.  If x is true, then it just discards that value.  Since
the compiler is allowed to perform UB if it knows that it can't affect
observable behavior, it should be fine.  If you pass NULL, then it would
crash.

What I'm not sure is that strftime(3) requires nonnull.  I didn't find it
in the C17 text.  glibc doesn't seem to use nonnull attributes for it:

$ grepc strftime /usr/include/
/usr/include/time.h:100:
extern size_t strftime (char *__restrict __s, size_t __maxsize,
const char *__restrict __format,
const struct tm *__restrict __tp) __THROW;


Cheers,

Alex

-- 
<http://www.alejandro-colomar.es/>
GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1032393: [Pkg-shadow-devel] Bug#1032393: [PATCH v2 2/2] debian/control: Add libbsd-dev and pkg-config

[Alejandro Colomar]

Hi Paul,

On 3/11/23 20:29, Paul Eggert wrote:
> From 522b2db5619bd26631bd444d208768f740c2fdba Mon Sep 17 00:00:00 2001
> From: Paul Eggert 
> Date: Sat, 11 Mar 2023 10:34:21 -0800
> Subject: [PATCH 6/6] Fix su silent truncation
> 
> * src/su.c (check_perms): Do not silently truncate user name.
> Use snprintf instead of strlcpy as the latter doesn't buy much here
> and this avoids depending on strlcpy.
> 
> Signed-off-by: Paul Eggert 
> ---
>  src/su.c | 10 --
>  1 file changed, 8 insertions(+), 2 deletions(-)
> 
> diff --git a/src/su.c b/src/su.c
> index 9c134a9b..740d31f9 100644
> --- a/src/su.c
> +++ b/src/su.c
> @@ -658,7 +658,14 @@ static /*@only@*/struct passwd * check_perms (void)
>   SYSLOG ((LOG_INFO,
>"Change user from '%s' to '%s' as requested by PAM",
>name, tmp_name));
> - strlcpy (name, tmp_name, sizeof(name));
> + int tmp_namelen = snprintf (name, sizeof name, tmp_name);

This will likely trigger a warning about using a variable for the format
string.  Are you sure it's can't have conversion specifiers?  Otherwise,
we should use "%s" (if we go the way of snprintf(3)).

But I suggest adding error using strlcpy(3), since it reads much simpler,
and adding error checking to it.  Anyway, we can't stop depending on
libbsd until we find a solution for readpassphrase(3bsd).

Cheers,

Alex

> + if (! (0 <= tmp_namelen && tmp_namelen < sizeof name)) {
> + fprintf (stderr, _("Overlong user name '%s'\n"),
> +  tmp_name);
> + SYSLOG ((LOG_NOTICE, "Overlong user name '%s'",
> +  tmp_name));
> + su_failure (caller_tty, true);
> + }
>   pw = xgetpwnam (name);
>   if (NULL == pw) {
>   (void) fprintf (stderr,
> @@ -1213,4 +1220,3 @@ int main (int argc, char **argv)
>  
>   return (errno == ENOENT ? E_CMD_NOTFOUND : E_CMD_NOEXEC);
>  }
> -
> -- 
> 2.37.2
> 


-- 

GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1032393: [Pkg-shadow-devel] Bug#1032393: [PATCH v2 2/2] debian/control: Add libbsd-dev and pkg-config

[Alejandro Colomar]

On 3/11/23 22:52, Paul Eggert wrote:
> On 2023-03-11 13:31, Alejandro Colomar wrote:
>> What's this  exactly for?
> 
> It avoids undefined behavior. A call like strftime (buf, sizeof buf, 
> "XXX", NULL) has undefined behavior, as near as I can make out.

Ahh, sure, it makes sense.  Didn't consider that.

> It's OK 
> that the dummy is uninitialized.

It's not so trivial to arrive to this conclusion.  If the function is
not allowed to dereference the pointer if the fmt string doesn't
require it, then NULL should be allowed.  If the function is allowed
to dereference, then NULL is not allowed, but if the values are
uninitialized, then reading any of them should also trigger UB, no?

Unless the standard specifically allows us to do so, but I can't find
anything clear.  Maybe it would be safer to bzero(3) it.

What do you think?


-- 
<http://www.alejandro-colomar.es/>
GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1032393: [Pkg-shadow-devel] Bug#1032393: [PATCH v2 2/2] debian/control: Add libbsd-dev and pkg-config

[Alejandro Colomar]

Hi Paul,

On 3/11/23 20:29, Paul Eggert wrote:
> From 70985857d6d24262fc57a10bd62e6dbc642dda70 Mon Sep 17 00:00:00 2001
> From: Paul Eggert 
> Date: Sat, 11 Mar 2023 10:07:32 -0800
> Subject: [PATCH 5/6] Fix is_my_tty overruns and truncations
> 
> * libmisc/utmp.c: Include mempcpy.h.
> (is_my_tty): Declare the parameter as a char array not char *,
> as it is not necessarily null-terminated.  Avoid a read overrun
> when reading ut_utname.  Do not silently truncate the string
> returned by ttyname; instead, do not cache an overlong ttyname,
> as the behavior is correct in this case (albeit slower).
> Use snprintf instead of strlcpy as the latter doesn't buy much here
> and this avoids depending on strlcpy.
> 
> Signed-off-by: Paul Eggert 
> ---
>  libmisc/utmp.c | 50 --
>  1 file changed, 28 insertions(+), 22 deletions(-)
> 
> diff --git a/libmisc/utmp.c b/libmisc/utmp.c
> index ff6acee0..9d40470e 100644
> --- a/libmisc/utmp.c
> +++ b/libmisc/utmp.c
> @@ -21,39 +21,45 @@
>  #include 
>  
>  #include "alloc.h"
> +#include "mempcpy.h"
>  
>  #ident "$Id$"
>  
> +enum { UT_LINE_LEN = sizeof (getutent ()->ut_line) };
>  
>  /*
>   * is_my_tty -- determine if "tty" is the same TTY stdin is using
>   */
> -static bool is_my_tty (const char *tty)
> +static bool is_my_tty (const char tty[UT_LINE_LEN])
>  {
> - /* full_tty shall be at least sizeof utmp.ut_line + 5 */
> - char full_tty[200];
> - /* tmptty shall be bigger than full_tty */
> - static char tmptty[sizeof (full_tty)+1];
> -
> - if ('/' != *tty) {
> - (void) snprintf (full_tty, sizeof full_tty, "/dev/%s", tty);
> - tty = _tty[0];
> - }
> -
> - if ('\0' == tmptty[0]) {
> - const char *tname = ttyname (STDIN_FILENO);
> - if (NULL != tname)
> - (void) strlcpy (tmptty, tname, sizeof tmptty);
> - }
> -
> + /* A null-terminated copy of tty, prefixed with "/dev/" if tty
> +is not absolute.  There is no need for snprintf, as sprintf
> +cannot overrun.  */
> + char full_tty[sizeof "/dev/" + UT_LINE_LEN];
> + (void) sprintf (('/' == *tty
> +  ? full_tty

I think it might be easier to read if we conditionally call stpcpy(3),
and then a simple sprintf(3) catenated to it.

> +  : mempcpy (full_tty, "/dev/", sizeof "/dev/" - 1)),

This is a great use case for stpcpy(3).  It's in POSIX.1-2008, which is
a base requirement for shadow since recently, so we can use it.

Cheers,

Alex

> + "%.*s", UT_LINE_LEN, tty);
> +
> + /* Cache of ttyname, valid if tmptty[0].  */
> + static char tmptty[UT_LINE_LEN + 1];
> +
> + const char *tname;
>   if ('\0' == tmptty[0]) {
> - (void) puts (_("Unable to determine your tty name."));
> - exit (EXIT_FAILURE);
> - } else if (strncmp (tty, tmptty, sizeof (tmptty)) != 0) {
> - return false;
> + tname = ttyname (STDIN_FILENO);
> + if (! tname) {
> + (void) puts (_("Unable to determine your tty name."));
> + exit (EXIT_FAILURE);
> + }
> + int tnamelen = snprintf (tmptty, sizeof tmptty, "%s", tname);
> + if (! (0 <= tnamelen && tnamelen < sizeof tmptty)) {
> + tmptty[0] = '\0';
> + }
>   } else {
> - return true;
> + tname = tmptty;
>   }
> +
> + return strcmp (full_tty, tname) == 0;
>  }
>  
>  /*
> -- 
> 2.37.2
> 


-- 

GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1032393: [Pkg-shadow-devel] Bug#1032393: [PATCH v2 2/2] debian/control: Add libbsd-dev and pkg-config

[Alejandro Colomar]

Hi Paul,

On 3/11/23 20:29, Paul Eggert wrote:
> From 1c8388d1d1831e976cdaa6e6f27bb08bf31aedc5 Mon Sep 17 00:00:00 2001
> From: Paul Eggert 
> Date: Sat, 11 Mar 2023 00:42:29 -0800
> Subject: [PATCH 4/6] Fix crash with large timestamps
> 
> * libmisc/date_to_str.c (date_to_str): Do not crash if gmtime
> returns NULL because the timestamp is far in the future.

Thanks :)

> Instead, use a dummy struct tm * to pacify any pedantic runtime.
> Simplify by always calling strftime, instead of sometimes strftime
> and sometimes strlcpy.
> 
> Signed-off-by: Paul Eggert 
> ---
>  libmisc/date_to_str.c | 15 +++
>  1 file changed, 7 insertions(+), 8 deletions(-)
> 
> diff --git a/libmisc/date_to_str.c b/libmisc/date_to_str.c
> index f3b9dc76..4b3a4f48 100644
> --- a/libmisc/date_to_str.c
> +++ b/libmisc/date_to_str.c
> @@ -35,13 +35,12 @@
>  
>  void date_to_str (size_t size, char buf[size], long date)
>  {
> - time_t t;
> + time_t t = date;
> + struct tm *tm = gmtime ();
> + struct tm dummy;
>  
> - t = date;
> - if (date < 0) {
> - (void) strlcpy (buf, "never", size);
> - } else {
> - (void) strftime (buf, size, "%Y-%m-%d", gmtime ());
> - buf[size - 1] = '\0';
> - }
> + (void) strftime (buf, size,
> +  date < 0 ? "never" : tm ? "%Y-%m-%d" : "future",
> +  tm ? tm : );

What's this  exactly for?

Cheers,

Alex

> + buf[size - 1] = '\0';
>  }
> -- 
> 2.37.2
> 


-- 

GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1032393: [Pkg-shadow-devel] Bug#1032393: [PATCH v2 2/2] debian/control: Add libbsd-dev and pkg-config

[Alejandro Colomar]

Hi Paul,

On 3/11/23 20:29, Paul Eggert wrote:
> From 7e88c5914c1fab6c4d88e1ca39d6b6319e7ee768 Mon Sep 17 00:00:00 2001
> From: Paul Eggert 
> Date: Sat, 11 Mar 2023 00:02:45 -0800
> Subject: [PATCH 2/6] Prefer memcpy to strlcpy when either works
> 
> memcpy is standardized and should be faster here.
> * lib/gshadow.c (sgetsgent): Use memcpy not strlcpy,
> since the string is known to fit.
> 
> Signed-off-by: Paul Eggert 
> ---
>  lib/gshadow.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/lib/gshadow.c b/lib/gshadow.c
> index c17af67f..1976c9a9 100644
> --- a/lib/gshadow.c
> +++ b/lib/gshadow.c
> @@ -128,7 +128,7 @@ void endsgent (void)
>   sgrbuflen = len;
>   }
>  
> - strlcpy (sgrbuf, string, len);
> + memcpy (sgrbuf, string, len);

While this one is less of a concern, and memcpy(3) is faster than
strcpy(3), I think I'd also use strcpy(3) here.  Also, the 'len'
variable seems confusing, since it's really a size.

Cheers,
Alex

>  
>   cp = strrchr (sgrbuf, '\n');
>   if (NULL != cp) {
> -- 
> 2.37.2
> 

-- 

GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1032393: [Pkg-shadow-devel] Bug#1032393: [PATCH v2 2/2] debian/control: Add libbsd-dev and pkg-config

[Alejandro Colomar]

Hi Paul,

On 3/11/23 20:29, Paul Eggert wrote:
> From d40e2f92f3e50d13d87393bd30b2b4b20b89a2d6 Mon Sep 17 00:00:00 2001
> From: Paul Eggert 
> Date: Sat, 11 Mar 2023 00:01:02 -0800
> Subject: [PATCH 1/6] Fix undefined behavior in change_field
> 
> * lib/fields.c (change_field): Do not ever compute [-1],
> as behavior is undefined.  Since we know that the string fits,
> use memcpy rather than strlcpy.

I'd separate the UB fix, from the transformation to memcpy(3),
in two separate commits, since they are conceptually unrelated.

> 
> Signed-off-by: Paul Eggert 
> ---
>  lib/fields.c | 14 +++---
>  1 file changed, 7 insertions(+), 7 deletions(-)
> 
> diff --git a/lib/fields.c b/lib/fields.c
> index 0b5f91b2..3b119502 100644
> --- a/lib/fields.c
> +++ b/lib/fields.c
> @@ -90,17 +90,17 @@ void change_field (char *buf, size_t maxsize, const char 
> *prompt)
>* makes it possible to change the field to empty, by
>* entering a space.  --marekm
>*/
> + char *bp = newf;
>  
> - while (--cp >= newf && isspace (*cp));
> - cp++;
> + while (newf < cp && isspace (cp[-1])) {
> + cp--;
> + }
>   *cp = '\0';
>  
> - cp = newf;
> - while (('\0' != *cp) && isspace (*cp)) {
> - cp++;
> + while (isspace (*bp)) {
> + bp++;
>   }
>  
> - strlcpy (buf, cp, maxsize);
> + memcpy (buf, bp, cp + 1 - bp);

Regarding this transformation, I'd prefer transforming to strcpy(3).
It avoids the manual `cp + 1 - bp` calculation.

Thanks for the review and patches!

Cheers,
Alex

>   }
>  }
> -
> -- 
> 2.37.2
> 


-- 

GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1032393: [Pkg-shadow-devel] Bug#1032393: [PATCH v2 2/2] debian/control: Add libbsd-dev and pkg-config

[Alejandro Colomar]

Hi Bálint,

On 3/10/23 21:34, Bálint Réczey wrote:
[...]

>> I didn't have the time to look into that, but we should really
>> check if we need to add some error checking.  With strlcpy(3),
>> at least we can do it, contrary to strncpy(3), which doesn't
>> really help detecting truncation (except that you can check
>> the last byte _before_ overwriting it with the '\0', which is
>> really cumbersome).
> 
> I did not find setting the last '\0' that cumbersome,

It's not just setting '\0', but also checking truncation.  As I
said, strncpy(3) is not suited for that, but memcpy(3) could be
used.  However, using memcpy(3) for copying strings with truncation
and detecting truncation is:

memcpy(dst, src, sizeof(dst) - 1)
if (strlen(src) >= sizeof(dst))
goto trunc;
dst[sizeof(dst) - 1] = '\0';

There are a few things I don't like:

-  setting '\0' is in a separate line.  Just a minor thing.
-  Two '-1', which are likely to produce off-by-one errors
   at some point (I've already fixed a few of them, IIRC).  At
   least they didn't seem bad, since we had then on the good
   side (we were just wasting one byte).

But the behavior is indeed what we want.  Here's the definition of
stpecpy(), which basically does that (I call strnlen(3) for optimizing):

$ grepc -tfd stpecpy
./lib/stpecpy.h:67:
inline char *
stpecpy(char *dst, char *end, const char *restrict src)
{
booltrunc;
char*p;
size_t  dsize, dlen, slen;

if (dst == end)
return end;
if (dst == NULL)
return NULL;

dsize = end - dst;
slen = strnlen(src, dsize);
trunc = (slen == dsize);
dlen = slen - trunc;

p = mempcpy(dst, src, dlen);
*p = '\0';

return p + trunc;
}


> but I'd be OK
> with any implementation that's correct and uses only glibc symbols
> including strcpy() and memcpy().

Okay, stpecpy() would be enough.

>> But we can't trivially replace readpassphrase(3bsd).  We could try
>> to reimplement it ourselves, but I don't see avoiding libbsd-dev
>> as a strong-enough reason.
> 
> Indeed, readpassphrase() is the most problematic, but looking at its
> implementation in libbsd it could be just copied to shadow. I'm not a
> fan of such copies, but it seems this function has been copied
> extensively already:
> https://codesearch.debian.net/search?q=readpassphrase%28const+char=1

I'm not a fan either; rather the opposite.  I'd vote against doing so.

> 
> readpassphrase.c's ISC license allows that, too, and I think copying
> would not be a ton of work.

Copying it, probably not.  Maintaining it, maybe yes.  I mean, just look
at it:

$ grepc -tfd readpassphrase | wc -l
142


142 lines of a function definition are not something I'd consider easy to
maintain.  Is it a big deal to add another dependency?  I'd say it's a
bigger deal to copy verbatim so many lines of code, and sync them from
time to time from libbsd (or OpenBSD) just to bring in any bugfixes they
apply.  That's exactly the purpose of libbsd, so I think relying on them
should be fine.

Cheers,

Alex
-- 

GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1032393: [Pkg-shadow-devel] Bug#1032393: [PATCH v2 0/2] Update Build-Depends

[Alejandro Colomar]

On 3/8/23 13:59, Alejandro Colomar wrote:
> Hi Bálint,
> 
> On 3/8/23 13:11, Bálint Réczey wrote:
>> Hi Serge,
>>
>> Serge E. Hallyn  ezt írta (időpont: 2023. márc. 6., H, 
>> 21:30):
> 
> [...]
> 
>>>
>>> Hi Balint,
>>>
>>> right now shadow is not depending on either one.  Alex is adding
>>> the pkgconf one.  This diff is between Alex's two diffs, showing
>>> that his first diff had added pkg-config, while v2 is instead doing
>>> pkgconf.
>>
>> Yes, and I'd still depend on the more mature pkg-config variant if one
>> variant is added until the archive-wide transition to pkgconf is
>> completed.
> 
> Didn't the transition already happen?  I thought it had.  This is what
> I see:
> 
> 
> $ apt-cache show pkg-config
> Package: pkg-config
> Source: pkgconf
> [...]
> Depends: pkgconf (>= 1.8.0-7~)
> Description-en: manage compile and link flags for libraries (transitional 
> package)
>  pkgconf is an implementation of the pkg-config system, which helps to 
> configure
>  compiler and linker flags for development frameworks.
>  .
>  pkgconf is a replacement for pkg-config, providing additional functionality
>  while also maintaining compatibility.
>  .
>  This package only provides a dependency link to the pkgconf package to help
>  with package upgrades. It can be safely removed.
> [...]
> Homepage: http://pkgconf.org/
> [...]
> Filename: pool/main/p/pkgconf/pkg-config_1.8.1-1_amd64.deb
> [...]

In fact, pkg-config doesn't seem to provide anything useful by itself:

$ apt-file show pkg-config
pkg-config: /usr/share/doc/pkg-config/changelog.Debian.gz
pkg-config: /usr/share/doc/pkg-config/changelog.gz
pkg-config: /usr/share/doc/pkg-config/copyright
pkg-config: /usr/share/lintian/overrides/pkg-config

Everything it provides is through the dependency on pkgconf, it seems.

Cheers,

Alex

> 
> 
> (Some fields removed with [...] to keep it short and to the point.)
> 
> 
>>
>> Cheers,
>> Balint
> 
> Cheers,
> 
> Alex
> 
> 

-- 
<http://www.alejandro-colomar.es/>
GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1032393: [Pkg-shadow-devel] Bug#1032393: [PATCH v2 0/2] Update Build-Depends

[Alejandro Colomar]

Hi Bálint,

On 3/8/23 13:11, Bálint Réczey wrote:
> Hi Serge,
> 
> Serge E. Hallyn  ezt írta (időpont: 2023. márc. 6., H, 
> 21:30):

[...]

>>
>> Hi Balint,
>>
>> right now shadow is not depending on either one.  Alex is adding
>> the pkgconf one.  This diff is between Alex's two diffs, showing
>> that his first diff had added pkg-config, while v2 is instead doing
>> pkgconf.
> 
> Yes, and I'd still depend on the more mature pkg-config variant if one
> variant is added until the archive-wide transition to pkgconf is
> completed.

Didn't the transition already happen?  I thought it had.  This is what
I see:


$ apt-cache show pkg-config
Package: pkg-config
Source: pkgconf
[...]
Depends: pkgconf (>= 1.8.0-7~)
Description-en: manage compile and link flags for libraries (transitional 
package)
 pkgconf is an implementation of the pkg-config system, which helps to configure
 compiler and linker flags for development frameworks.
 .
 pkgconf is a replacement for pkg-config, providing additional functionality
 while also maintaining compatibility.
 .
 This package only provides a dependency link to the pkgconf package to help
 with package upgrades. It can be safely removed.
[...]
Homepage: http://pkgconf.org/
[...]
Filename: pool/main/p/pkgconf/pkg-config_1.8.1-1_amd64.deb
[...]


(Some fields removed with [...] to keep it short and to the point.)


> 
> Cheers,
> Balint

Cheers,

Alex


-- 

GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1032393: [Pkg-shadow-devel] Bug#1032393: [PATCH v2 2/2] debian/control: Add libbsd-dev and pkg-config

[Alejandro Colomar]

Hi Bálint,

[I reordered some quotes for my reply]
[CC Paul, since he's been mentioned, and I'm curious to know
if he has any comments]

On 3/8/23 11:59, Bálint Réczey wrote:
> Hi Alejandro,
> 
> Alejandro Colomar  ezt írta (időpont: 2023.
> márc. 5., V, 20:44):
>>
>> Package: passwd
>> Source: shadow
>> Tags: patch
>> X-Debbugs-CC: Bálint Réczey 
>> X-Debbugs-CC: Iker Pedrosa 
>> X-Debbugs-CC: Serge Hallyn 
>>
>> These dependencies were added upstream recently.
>>
>> Signed-off-by: Alejandro Colomar 
>> Cc: Iker Pedrosa 
>> Cc: Serge Hallyn 
>> ---
>>  debian/control | 2 ++
>>  1 file changed, 2 insertions(+)
>>
>> diff --git a/debian/control b/debian/control
>> index 3cc66f8d..75015c35 100644
>> --- a/debian/control
>> +++ b/debian/control
>> @@ -11,11 +11,13 @@ Build-Depends: bison,
>> gettext,
>> itstool,
>> libaudit-dev [linux-any],
>> +   libbsd-dev,
> 
> I checked out recent changes in shadow's master and I'm very happy
> about many of the fixes for memory allocation problems,

Thanks! :-)

> but wearing my maintainer hat I believe linking to a new library for a
> few functions which are not very different from their glibc
> counterpart is not worth it.

We added it with strlcpy(3) in mind, but I agree with you that
it's not a critical reason, and we could live without it; in fact
I introduced a similar (and IMO superior) function, stpecpy(),
which could replace strlcpy(3) in all 6 calls.

But we didn't really add it for it; we already had the libbsd-dev
dependency before adding strlcpy(3).  libbsd-dev was added for
readpassphrase(3bsd), which has nothing similar in glibc, and I don't
want to be rewriting it in terms of glibc stuff, since it's not
trivial.

It was added in this patch set:

* 2a5b8810 - Mon, 21 Nov 2022 14:00:13 +0100 (4 months ago)
|       agetpass: Hook into build-system - Guillem Jover
* ab91ec10 - Wed, 28 Sep 2022 23:09:19 +0200 (5 months ago)
|   Hide [[gnu::malloc(deallocator)]] in a macro - Alejandro Colomar
* 554f86ba - Tue, 27 Sep 2022 21:21:35 +0200 (5 months ago)
|   Replace the deprecated getpass(3) by our agetpass() - Alejandro 
Colomar
* 155c9421 - Mon, 26 Sep 2022 22:22:24 +0200 (5 months ago)
|   libmisc: agetpass(), erase_pass(): Add functions for getting 
passwords safely - Alex Colomar
* 8cce4557 - Wed, 28 Sep 2022 00:03:46 +0200 (5 months ago)
|   Don't 'else' after a 'noreturn' call - Alex Colomar
* 99ce21a3 - Tue, 22 Nov 2022 14:35:06 +0100 (4 months ago)
|   CI: add libbsd and pkg-config dependencies - Iker Pedrosa


> 
> Freezero() also provides little extra benefit over memset() and free()
> and is used only 4 times in the code.

Use of freezero(3bsd) was added later to erase_pass() for one reason:
that API pair --agetpass(), erase_pass()-- already strongly depends on a
libbsd-dev function --readpassphrase(3bsd)--, so depending on two of them
doesn't add any issues.  Anyway, freezero(3) is easy to implement if we
had a need.



> There are reasons for strlcpy() not being provided by glibc [1]:
> 
> "Reactions among core glibc contributors on the topic of including
> strlcpy() and strlcat() have been varied over the years. Christoph
> Hellwig's early patch was rejected in the then-primary maintainer's
> inimitable style (1 and 2). But reactions from other glibc developers
> have been more nuanced, indicating, for example, some willingness to
> accept the functions. Perhaps most insightfully, Paul Eggert notes
> that even when these functions are provided (as an add-on packaged
> with the application), projects such as OpenSSH, where security is of
> paramount concern, still manage to either misuse the functions
> (silently truncating data) or use them unnecessarily (i.e., the
> traditional strcpy() and strcat() could equally have been used without
> harm); such a state of affairs does not constitute a strong argument
> for including the functions in glibc. "
> 
> I agree with their position and the 6 cases where strlcpy() is used in
> shadow's current master could be implemented with strncpy() as safely
> as with strlcpy().

I would strongly advise against that.  strncpy(3) doesn't produce
strings.

See the following manual pages:

<https://mirrors.edge.kernel.org/pub/linux/docs/man-pages/book/man-pages-6.03.pdf#strncpy_3>
<https://mirrors.edge.kernel.org/pub/linux/docs/man-pages/book/man-pages-6.03.pdf#string_copying_7>

My main concerns with strncpy(3) are:

-  It zeroes the rest of the buffer, which isn't bad per se, but
   then when reading code it's hard to tell if that was necessary
   or if it was just some inessential side effect of calling
   strncpy(3).  Which was exactly wha

Bug#1032393: [PATCH v2 2/2] debian/control: Add libbsd-dev and pkg-config

[Alejandro Colomar]

Package: passwd
Source: shadow
Tags: patch
X-Debbugs-CC: Bálint Réczey 
X-Debbugs-CC: Iker Pedrosa 
X-Debbugs-CC: Serge Hallyn 

These dependencies were added upstream recently.

Signed-off-by: Alejandro Colomar 
Cc: Iker Pedrosa 
Cc: Serge Hallyn 
---
 debian/control | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/debian/control b/debian/control
index 3cc66f8d..75015c35 100644
--- a/debian/control
+++ b/debian/control
@@ -11,11 +11,13 @@ Build-Depends: bison,
gettext,
itstool,
libaudit-dev [linux-any],
+   libbsd-dev,
libcrypt-dev,
libpam0g-dev,
libselinux1-dev [linux-any],
libsemanage-dev [linux-any],
libxml2-utils,
+   pkgconf,
quilt,
xsltproc
 Standards-Version: 4.6.1
-- 
2.39.2

Bug#1032393: [PATCH v2 1/2] debian/control: Sort alphabetically package lists

[Alejandro Colomar]

Package: passwd
Source: shadow
Tags: patch
X-Debbugs-CC: Bálint Réczey 
X-Debbugs-CC: Iker Pedrosa 
X-Debbugs-CC: Serge Hallyn 

Signed-off-by: Alejandro Colomar 
Cc: Iker Pedrosa 
Cc: Serge Hallyn 
---
 debian/control | 24 
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/debian/control b/debian/control
index 88198468..3cc66f8d 100644
--- a/debian/control
+++ b/debian/control
@@ -4,20 +4,20 @@ Uploaders: Balint Reczey ,
Serge Hallyn 
 Section: admin
 Priority: required
-Build-Depends: debhelper-compat (= 13),
-   gettext,
-   libcrypt-dev,
-   libpam0g-dev,
-   quilt,
-   xsltproc,
+Build-Depends: bison,
+   debhelper-compat (= 13),
docbook-xsl,
docbook-xml,
-   libxml2-utils,
+   gettext,
+   itstool,
+   libaudit-dev [linux-any],
+   libcrypt-dev,
+   libpam0g-dev,
libselinux1-dev [linux-any],
libsemanage-dev [linux-any],
-   itstool,
-   bison,
-   libaudit-dev [linux-any]
+   libxml2-utils,
+   quilt,
+   xsltproc
 Standards-Version: 4.6.1
 Vcs-Git: https://salsa.debian.org/debian/shadow.git -b master
 Vcs-Browser: https://salsa.debian.org/debian/shadow
@@ -43,8 +43,8 @@ Multi-Arch: foreign
 Essential: yes
 Pre-Depends: ${shlibs:Depends},
  ${misc:Depends},
- libpam-runtime,
- libpam-modules
+ libpam-modules,
+ libpam-runtime
 Breaks: hurd (<< 20140206~) [hurd-any]
 Conflicts: python-4suite (<< 0.99cvs20060405-1)
 Replaces: hurd (<< 20140206~) [hurd-any]
-- 
2.39.2

Bug#1032393: [PATCH v2 0/2] Update Build-Depends

[Alejandro Colomar]

Package: passwd
Source: shadow
Tags: patch
X-Debbugs-CC: Bálint Réczey 
X-Debbugs-CC: Iker Pedrosa 
X-Debbugs-CC: Serge Hallyn 
To: sub...@bugs.debian.org

Hi Balint,

This is my first patch set sent to Debbugs.  Let's see if I do it
correctly :).

I can't open a MR in Salsa, since my account is still to be approved
(I opened it yesterday).  BTW, if you have any contacts there, please
have a look at it; the identifier is 'alx' and the associated email is
.  I sent a mail to the Salsa admin a week ago but
received no response (but I guess they might be busy).

Cheers,

Alex

---

Alejandro Colomar (2):
  debian/control: Sort alphabetically package lists
  debian/control: Add libbsd-dev and pkg-config

 debian/control | 26 ++
 1 file changed, 14 insertions(+), 12 deletions(-)

Range-diff against v1:
-:   > 1:  3d079bd9 debian/control: Sort alphabetically package lists
1:  48ac3d10 ! 2:  9e323b50 debian/control: Add libbsd-dev and pkg-config
@@ debian/control: Build-Depends: bison,
 libselinux1-dev [linux-any],
 libsemanage-dev [linux-any],
 libxml2-utils,
-+   pkg-config,
++   pkgconf,
 quilt,
 xsltproc
  Standards-Version: 4.6.1
-- 
2.39.2

Bug#1011666: need help with groff 1.23.0 (1.23.0~rc3-1 package prepared)

[Alejandro Colomar]

Hi Colin,

On 3/3/23 19:12, Colin Watson wrote:
> This isn't really analogous to your situation, though.  git-dpm is more
> like a workflow tool (such as stgit) than it is like a program you use
> to generate one-off scripted patches.  I don't think it would be
> appropriate or reasonable to try to embed this sort of thing in every
> commit generated by git-dpm, which is quite a lot of the commits that
> end up in my packaging branches.

If it's recurrent, maybe doing it only once would be nice.

> 
> I'd be happy to write a debian/README.source file, which would be a
> better place for this sort of thing.  I'm not sure exactly when I'll get
> round to it, but I've added it to my to-do list.

Sure, that would also help!

Cheers,

Alex

-- 

GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1011666: need help with groff 1.23.0 (1.23.0~rc3-1 package prepared)

[Alejandro Colomar]

Hi Branden and Colin!

On 2/27/23 13:56, G. Branden Robinson wrote:
> [added Alex Colomar to CC]
> 
> At 2023-02-26T13:30:58+, Colin Watson wrote:
>>> I am not a proficient gbp user, but I think I have done what is
>>> necessary.
>>
>> groff doesn't use gbp - it uses git-dpm.
> 
> Right.  You told me that before and the information trickled out of my
> sieve-like brain.  TLA overload, so I was SOL.  FML.

$ wtf is SOL
SOL: SOL (6)  - a collection of card games which are easy to play 
with...
$ wtf is FML
Gee...  I don't know what FML means...


Please send a patch to bsdgames :D

At least dict(1) could help with SOL.  No luck with FML though,
I had to search it on the web.  No good.  Fuck my life! :D

$ dict -d foldoc SOL
1 definition found

From The Free On-line Dictionary of Computing (30 December 2018) [foldoc]:

  SOL
  
 1.  {Simulation Oriented Language}.
  
 2. {Second-Order lambda-calculus}.
  
 3. Semantic Operating Language.  Language for manipulating
 semantic networks for building cognitive models, particularly
 for natural language understanding.  "Explorations in
 Cognition", D.A. Norman et al, W.H.  Freeman 1974.
  
 4. Shit Outta Luck.

$ dict FML
No definitions found for "FML", perhaps you mean:
gcide:  ml  Fm  Fil  -ful
wn:  ml  fl  fm  ful
vera:  ml  fl  fm  cfml  aml  bml  dml  eml  gml  iml  kml  mml
  nml  qml  sml  uml  vml  wml  xml  fal  fbl  fcl  fdl  frl  ftl
  fma  fmb  fmm  fmo  fms
jargon:  fm
foldoc:  ml  fl  fm


> 
>> If you try to use gbp for it then you will probably get quite confused
>> and so will I, so please don't.
> 
> Yes, indeed, thanks.
> 
>> First, move your current branch somewhere for reference, then make a new
>> one.  Then, my routine for pulling in new upstreams looks roughly like
>> this:
>>
>>   git-dpm import-new-upstream -p $UPSTREAMTAG^{} --rebase-patched 
>> ../foo.orig.tar.gz
>>   # this imports the unpacked upstream tarball onto an upstream branch
>>   # based on $UPSTREAMTAG, then drops you into a rebase session
>>
>>   ... continue with rebase as needed, then once you're finished ...
>>
>>   git-dpm update-patches --amend
>>   # the --amend is just because the import-new-upstream step will
>>   # already have recorded the new upstream on the branch you started
>>   # from, but the history looks clearer if you bundle the rebase with
>>   # that in a single merge commit, which this does

May I ask something from you, Colin?  Could you please embed that
info in the commit messages in salsa?  That would help those who
want to learn Debian packaging from actual practice rather than
tutorials (I've read and watched many of those, and my confusion
only grows; I mean, just look at
<https://www.youtube.com/watch?v=O83rIRRJysA> :p).

In the Linux man pages I write the scripts or commands run to produce
a scripted or semi-scripted patch, or when some important information
needed to write a patch was gotten from some script.  See for example:


commit a1eaacb1a569cd492b09c04982cd40b4b733ba3c
Author: Alejandro Colomar 
Date:   Wed Nov 9 16:36:36 2022 +0100

Many pages: Add '\" t' comment where necessary

Scripted change:

$ grep -l -x '^[.]TS$' man*/* | sort -u | xargs sed -i -e "1i'\" t"

Link: 
<https://lore.kernel.org/linux-man/07a7d4e7-79a6-b2c3-6892-1e39a0679...@gmail.com/T/#mcf36c8a387fd5ff4f800dc220e3dbdd229b556bd>
Reported-by: Jakub Wilk 
Cc: Mike Frysinger 
Cc: "G. Branden Robinson" 
Cc: Michael Kerrisk 
Cc: Stefan Puiu 
Signed-off-by: Alejandro Colomar 

commit b324e17d3208c940622ab192609b836928d5aa8d
Author: Alejandro Colomar 
Date:   Sun Dec 4 20:38:06 2022 +0100

Many pages: wfix

Refer consistently to software versions.  In most cases, it is done as
 .  In the case of Linux and glibc, use the project
name, instead of other terms such as 'kernel' or 'library'.

I found the uses of inconsistent language with the following:

$ find man* -type f \
| xargs grep -i 
'\(since\|before\|after\|until\|to\|from\|in\|between\|version\|with\) 
\(kernel\|version\|2\.\|3\.\|4\.\|5\.\)' \
| sort

However, I might have missed some cases.  Anyway, 99% consistency is
pretty good consistency.  We'll fix the remaining cases as we see them.

Signed-off-by: Alejandro Colomar 


>>
>> Then you can cherry-pick your packaging changes on top of this, as well
>> as telling pristine-tar about the new upstream tarball based on the
>> appropriate imported branch.
>>
>> If you push the results to a temporary branch on salsa then I can look
>> over them, which is probably a good idea since you're unfamiliar with
>> git-dpm.
> 
> Thanks f

Bug#1031275: partman: Should allow binary multipliers

[Alejandro Colomar]

Package: debian-installer
Severity: normal
X-Debbugs-Cc: alx.manpa...@gmail.com


Dear maintainer,

when installing Debian, it's painful to size the partitions.  I want
them to be aligned with certain boundaries, and want them to have very
specific sizes (usually, multiples of 1 GiB), but the default
partitioning program doesn't allow that.  fdisk or gdisk provide a
much better way of specifying such things by allowing one to specify
initial sector and size in several formats.  Please add such semantics
to the default program, or include fdisk and gdisk in the installer.

I usually format disks from a live system with those tools, and later
run the installer on the formatted disk, because I hate how it formats
disks.

Thanks,

Alex

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.1.0-3-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#1026389: xfce4: split screen doesn't work anymore

[Alejandro Colomar]

Hi Bernhard!

On 1/7/23 12:00, Bernhard Übelacker wrote:



The patch at the bottom would set tile_on_move to true,
if the "With a dragged window" gets switched off.



Now after some sleep I found that this might really be the
way upstream wants this to handle, so the patch is wrong.

After enabling "With a dragged window" in xfwm4-settings
which switches off the tile_on_move setting,
the user can re-enable this setting by
"Automatically tile windows when moving towards the screen edge"
in xfwm4-tweaks-settings.
(If both settings applications are opened side by side,
one can watch how enabling the first disables the second.)


Thanks a lot!  This worked (and yes, unintuitive as hell).



Unfortunately not the most intuitive process.

Kind regards,
Bernhard


Cheers,

Alex

--



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1022844: man subsection directories are needed for mandoc(1)

[Alejandro Colomar]

Hello Marcos,

On 1/6/23 19:35, Marcos Fouces wrote:

Hello Alejandro,

Debian policy is clear on this point: manual pages should be assigned
to man[1..9]/ dirs [1]. Lintian also issues error tags when this
behavior is not observed [2].

The desired section expressed through the file extension and the .TH
field is not modified. All .so links are corrected to point to the
corresponding man page.

 From dh_installman(1) manual page:

" ...you tell dh_installman what man pages go in your packages, and it
figures out where to install them based on the section field in their
.TH or .Dt line. If you have a properly formatted .TH or .Dt line, your
man page will be installed into the right directory, with the right
name (this includes proper handling of pages with a subsection, like
3perl, which are placed in man3, and given an extension of .3perl). If
your .TH or .Dt line is incorrect or missing, the program may guess
wrong based on the file extension."

What is the precise drawback of this solution?


There are two (not huge drawbacks, but they exist):

-  mandoc(1) (and possibly other software) understands that if a page is in 
directory manX, it is in section X, so it will for example appear in searches of 
pages in that section.


-  3 is for functions and 3const is for constants, so having them separate makes 
it easier to list all functions and all constants in a system (or at least those 
that are documented in manual pages.




Greetings,
Marcos


Cheers,

Alex



[1] https://www.debian.org/doc/debian-policy/ch-docs.html#manual-pages
[2] https://lintian.debian.org/tags/odd-place-for-manual-page


--



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1026389: xfce4: split screen doesn't work anymore

[Alejandro Colomar]

Hi Bernhard,

On 1/6/23 00:17, Bernhard Übelacker wrote:



And indeed, when unchecking following in Window Manager
settings it seems to "snap" again:

   Wrap workspaces when reaching the screen edge / With a dragged window



I had that one disabled (but I didn't do that; I guess it was like that by 
default).  My windows don't move to other workspaces when moving them, and 
yet don't "snap".


I don't know exactly what is meant by snap, so I'll clarify:

If I move a window adjacent to another window or the edge of the screen, it 
repositions itself so the the borders are touching (I can adjust the distance 
at which that occurs).  That's "Settings manager->Personal->Window 
Manager->Advanced->Windows Snapping".


However, windows don't resize automatically to use half screen or quarter 
screen.  I can't manage to get that working, which previously worked by default.



Sorry for not being enough precise.
When I disabled "With a dragged window" and applied the setting a file manager 
window

dragged to the left border of my VM did get resized to fill half of the screen.

"To screen borders" - default as far as I see is on and was on in all my tests.
"To other windows" - default as far as I remember is off and was off in all my 
tests.
"With the mouse pointer" - default as far as I see is off and was off in all my 
tests.

"With a dragged window" - default as far as I see is on.


I confirm that either with those 4 defaults, or with "with a dragged window" off 
(as you suggested that would fix it), I still have it bugged.




If you still don't get a dragged window filling half of the screen,
then I can't reproduce your issue and don't have a solution.


Is there any other setting that might be affecting?

Cheers,

Alex



Kind regards,
Bernhard



--



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1026389: xfce4: split screen doesn't work anymore

[Alejandro Colomar]

On 1/5/23 02:45, Alejandro Colomar wrote:

Hi Bernhard,

On 1/5/23 02:33, Bernhard Übelacker wrote:



When I upgraded my Sid system yesterday (I do it every week or so),
windows cannot be moved to the edge of the screen to have them use half
screen.  It simply moves there without readjusting.


Dear Maintainer, hello Alejandro,
this looks like it appeared in unstable with the
appearance of xfwm4 4.18.0-1 at 2022-12-15,
replacing the previous version 4.16.1-1 in unstable.

And looks like it was discussed upstream in this report:
   https://gitlab.xfce.org/xfce/xfwm4/-/issues/685


Thanks!



And indeed, when unchecking following in Window Manager
settings it seems to "snap" again:

   Wrap workspaces when reaching the screen edge / With a dragged window



I had that one disabled (but I didn't do that; I guess it was like that by 
default).  My windows don't move to other workspaces when moving them, and yet 
don't "snap".


I don't know exactly what is meant by snap, so I'll clarify:

If I move a window adjacent to another window or the edge of the screen, it 
repositions itself so the the borders are touching (I can adjust the distance at 
which that occurs).  That's "Settings manager->Personal->Window 
Manager->Advanced->Windows Snapping".


However, windows don't resize automatically to use half screen or quarter 
screen.  I can't manage to get that working, which previously worked by default.


  I just get windows that are half in a workspace, half nowhere. 
They don't jump to another workspace nor tile.



So this looks like expected behaviour from upstream.

Kind regards,
Bernhard


Kind regards,

Alex



--
<http://www.alejandro-colomar.es/>


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1026389: xfce4: split screen doesn't work anymore

[Alejandro Colomar]

Hi Bernhard,

On 1/5/23 02:33, Bernhard Übelacker wrote:



When I upgraded my Sid system yesterday (I do it every week or so),
windows cannot be moved to the edge of the screen to have them use half
screen.  It simply moves there without readjusting.


Dear Maintainer, hello Alejandro,
this looks like it appeared in unstable with the
appearance of xfwm4 4.18.0-1 at 2022-12-15,
replacing the previous version 4.16.1-1 in unstable.

And looks like it was discussed upstream in this report:
   https://gitlab.xfce.org/xfce/xfwm4/-/issues/685


Thanks!



And indeed, when unchecking following in Window Manager
settings it seems to "snap" again:

   Wrap workspaces when reaching the screen edge / With a dragged window



I had that one disabled (but I didn't do that; I guess it was like that by 
default).  My windows don't move to other workspaces when moving them, and yet 
don't "snap".  I just get windows that are half in a workspace, half nowhere. 
They don't jump to another workspace nor tile.



So this looks like expected behaviour from upstream.

Kind regards,
Bernhard


Kind regards,

Alex

--



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1027793: closed by Debian FTP Masters (reply to James McCoy ) (Bug#1027766: fixed in vim 2:9.0.1000-3)

[Alejandro Colomar]

Hi,

On 1/3/23 17:09, Debian Bug Tracking System wrote:

This is an automatic notification regarding your Bug report
which was filed against the vim-common package:

#1027793: vim: insert mode: Backspace doesn't do anything

It has been closed by Debian FTP Masters  (reply to 
James McCoy ).

Their explanation is attached below along with your original report.
If this explanation is unsatisfactory and you have not received a
better one in a separate message then please contact Debian FTP Masters 
 (reply to James McCoy ) 
by
replying to this email.



For my own curiosity, would you mind pointing to the specific change that fixed 
this bug?


Thanks,

Alex





--



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1027793: vim: insert mode: Backspace doesn't do anything

[Alejandro Colomar]

Package: vim
Version: 2:9.0.1000-2
Severity: normal
X-Debbugs-Cc: alx.manpa...@gmail.com

Hi,

This is not a bug in vim(1), since I can't reproduce it with --clean.
However, I can reproduce it with -u NONE, so I guess it's some plugin.
But I didn't install any plugins myself, so this is with whatever the
defaults are in Debian, I guess.

The issue is reproducible as:

(1)  Go to insert mode.
(2)  Press backspace.  It should remove a character; but doesn't.

Cheers,

Alex

-- Package-specific info:

--- real paths of main Vim binaries ---
/usr/bin/vi is /usr/bin/vim.basic
/usr/bin/vim is /usr/bin/vim.basic

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.0.0-6-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages vim depends on:
ii  libacl1  2.3.1-2
ii  libc62.36-7
ii  libgpm2  1.20.7-10+b1
ii  libselinux1  3.4-1+b4
ii  libsodium23  1.0.18-1
ii  libtinfo66.4-1
ii  vim-common   2:9.0.1000-2
ii  vim-runtime  2:9.0.1000-2

vim recommends no packages.

Versions of packages vim suggests:
ii  universal-ctags [ctags]  5.9.20210829.0-1
pn  vim-doc  
pn  vim-scripts  

-- no debconf information

Bug#988546: Ping^1: Bug#988546: iwyu.1, include-what-you-use.1: Missing sections in the manual page

[Alejandro Colomar]

Ping.

On Sat, 15 May 2021 19:13:30 +0200 Alejandro Colomar  
wrote:

Hi,

On 5/15/21 1:14 PM, Alejandro Colomar wrote:
> Package: iwyu
> Version: 8.15-2
> Severity: minor
> X-Debbugs-Cc: Alejandro Colomar (man-pages) 
> 
> Dear Maintainer,
> 
> The manual page for this package has some formatting errors,

> and has everything in the DESCRIPTION section.
> 
> I found that the upstream manual page is correct, so it's a bug specific to

> Debian.  Where is the Debian manual page coming from??
> 
> See <https://github.com/include-what-you-use/include-what-you-use/blob/master/include-what-you-use.1>.


I digged in Salsa, and it looks like the manual page there
<https://salsa.debian.org/pkg-llvm-team/iwyu/-/blob/master/include-what-you-use.1>
is the same as the upstream one, but the ones I got installed with
`apt-get install iwyu` are very different
(,
).  Is there anything you
do when you build the package that changes them so much?

Thanks,

Alex

--
Alejandro Colomar
Linux man-pages comaintainer; https://www.kernel.org/doc/man-pages/
http://www.alejandro-colomar.es/




--
<http://www.alejandro-colomar.es/>


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1026302: isystem: Specify path for system headers

[Alejandro Colomar]

Hi Joachim,

On 12/19/22 10:26, Joachim Reichel wrote:

severity 1026302 wishlist
thanks


Hi Alex,


Similar to GCC's -isystem to specify a path to check for system headers,
it would be very useful to tell cppcheck where to find system headers.
I'm writing a library, whose headers include eachother using <> since
it's intended to be used as a system library.  However, for building
(and linting) it, I need to tell the compiler (and linters) that the
includes are not really system includes.


I don't quite understand why you want/need -isystem for cppcheck. Is it just the 
minor inconvenience that you have to replace possible "-isystem" occurrences in 
your CFLAGS etc. by "-I"? Or is it the fact -isystem directories will be 
processes after -I directories?


Also I don't understand "I need to tell ... are not really ..." in the last 
sentence. What does that mean in terms of actual compiler/cppcheck arguments? If 
you need to do something special (?) for the compiler, why is it not ok to do 
the same for cppcheck (maybe with s/-isystem/-I/)?


It might help if you provide more details.


Sorry, my mistake.  I was getting a warning that cppcheck(1) wasn't finding some 
headers, and I had assumed it was my own headers, but it seems it was libc 
headers, which it is fine if it doesn't find them.  So invalid bug report, I 
guess.  :)


Cheers,

Alex

--



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1026303: clang-tidy: clang-diagnostic-unused-macros: Spurious trigger in header guards

[Alejandro Colomar]

Hi Sylvestre,

On 12/18/22 09:55, Sylvestre Ledru wrote:

Hello

You should report this upstream with an example;


Done; thanks.

<https://github.com/llvm/llvm-project/issues/59572>

Cheers,

Alex



Cheers

S

Le 18/12/2022 à 01:30, Alejandro Colomar a écrit :

Package: clang-tidy
Version: 1:14.0-55.2+b1
Severity: normal
Tags: upstream
X-Debbugs-Cc: alx.manpa...@gmail.com

Dear maintainer,

The clang-tidy clang-diagnostic-unused-macros warning triggers on header
guards, which of course are unused.


--
<http://www.alejandro-colomar.es/>


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1026303: clang-tidy: clang-diagnostic-unused-macros: Spurious trigger in header guards

[Alejandro Colomar]

Package: clang-tidy
Version: 1:14.0-55.2+b1
Severity: normal
Tags: upstream
X-Debbugs-Cc: alx.manpa...@gmail.com

Dear maintainer,

The clang-tidy clang-diagnostic-unused-macros warning triggers on header
guards, which of course are unused.

Cheers,

Alex


-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.0.0-5-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages clang-tidy depends on:
ii  clang-tidy-14  1:14.0.6-9

clang-tidy recommends no packages.

clang-tidy suggests no packages.

-- no debconf information

Bug#1026302: isystem: Specify path for system headers

[Alejandro Colomar]

Package: cppcheck
Version: 2.9-1
Severity: normal
Tags: upstream
X-Debbugs-Cc: alx.manpa...@gmail.com

Dear maintainer,

Similar to GCC's -isystem to specify a path to check for system headers,
it would be very useful to tell cppcheck where to find system headers.
I'm writing a library, whose headers include eachother using <> since
it's intended to be used as a system library.  However, for building
(and linting) it, I need to tell the compiler (and linters) that the
includes are not really system includes.

Would you please add such an option?

Thanks,

Alex


-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.0.0-5-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages cppcheck depends on:
ii  libc6 2.36-6
ii  libgcc-s1 12.2.0-10
ii  libpcre3  2:8.39-14
ii  libstdc++612.2.0-10
ii  libtinyxml2-9 9.0.0+dfsg-3.1
ii  python3   3.10.6-3
ii  python3-pygments  2.13.0+dfsg-1

cppcheck recommends no packages.

Versions of packages cppcheck suggests:
ii  clang 1:14.0-55.2+b1
ii  clang-tidy1:14.0-55.2+b1
pn  cppcheck-gui  

-- no debconf information

Bug#1022763: Acknowledgement (/usr/share/man/man1/tail.1.gz: documentation: tail(1): -NUM is undocumented)

[Alejandro Colomar]

Ahh, I see it documented in the texinfo(5) documentation:

{
For compatibility tail also supports an obsolete usage ‘tail -[num][bcl][f] 
[file]’, which is recognized only if it does not conflict with the usage 
described above. This obsolete form uses exactly one option and at most one 
file. In the option, num is an optional decimal number optionally followed by a 
size letter (‘b’, ‘c’, ‘l’) to mean count by 512-byte blocks, bytes, or lines, 
optionally followed by ‘f’ which has the same meaning as -f.

}

Being an obsolete feature, it might make sense to omit it in the manual page, to 
avoid too much noise, as long as it can't interfere with non-obsolete options.


Cheers,
Alex

--



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1022763: /usr/share/man/man1/tail.1.gz: documentation: tail(1): -NUM is undocumented

[Alejandro Colomar]

Package: coreutils
Version: 9.1-1
Severity: normal
File: /usr/share/man/man1/tail.1.gz
Tags: upstream
X-Debbugs-Cc: a...@kernel.org, a...@nginx.com, l...@nginx.com

Dear maintainer,

`tail -1` works equivalently to `tail -n1`, but is undocumented.  As
far as I can see, it's not in POSIX, but is available in several
systems.  I guessed that it's not documented because it looks like a
backwards-compatibility feature not intended to be used by new scripts,
but still it would be good to document it, and maybe mark it as a
deprecated feature.  Could you please add it to the manual page?

Cheers,

Alex

Reported-by: Alejandro Colomar 
Reported-by: Liam Crilly 


-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.19.0-2-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages coreutils depends on:
ii  libacl1  2.3.1-1
ii  libattr1 1:2.5.1-1
ii  libc62.35-3
ii  libgmp10 2:6.2.1+dfsg1-1.1
ii  libselinux1  3.4-1+b2

coreutils recommends no packages.

coreutils suggests no packages.

-- no debconf information

Bug#1020893: Bug has been fixed.

[Alejandro Colomar]

Hi!

The root issue #1008735 has been recently fixed, and this bug is 
indirectly fixed by it.


To confirm:

$ lsb_release -cs
No LSB modules are available.
n/a
$ lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description:Debian GNU/Linux bookworm/sid
Release:n/a
Codename:   n/a
$ # apt-get upgraded in another terminal ...
$ lsb_release -cs
No LSB modules are available.
bookworm
$ lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description:Debian GNU/Linux bookworm/sid
Release:n/a
Codename:   bookworm

Cheers,

Alex

--



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1021418: builtin: echo: Treat -n as a string

[Alejandro Colomar]

Package: dash
Version: 0.5.11+git20210903+057cd650a4ed-9
Severity: normal
X-Debbugs-Cc: alx.manpa...@gmail.com

Hi,

I'd like if dash(1)'s built-in echo(1) would treat -n as a string.
POSIX specifies the behavior as implementation-defined, but XSI
(see standards(7)) is stricter, and specifies that echo(1) has no
options (-n has to be treated as any other string).

Considering that dash(1) tends to be minimal, the minimal thing to
do is to not implement the option.

Cheers,

Alex


-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.19.0-1-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages dash depends on:
ii  debianutils  5.7-0.3
ii  dpkg 1.21.9
ii  libc62.35-1

dash recommends no packages.

dash suggests no packages.

-- debconf information:
* dash/sh: true

Bug#1019686: /usr/bin/pee: moreutils: manual pages: Add EXAMPLES section

[Alejandro Colomar]

Package: moreutils
Version: 0.67-1
Severity: normal
File: /usr/bin/pee
Tags: upstream
X-Debbugs-Cc: alx.manpa...@gmail.com

Hi,

I'd like to see an EXAMPLES section in the moreutils manual pages
showing how you'd normally use them, possibly showing several
common patterns.  More or less, what tldr(1) pages show.

The sponge(1) page for example, abuses the SYNOPSIS a little bit
to show an example.  It's not a crazy idea, but separating them
into a proper synopsis, and a proper examples sections might be
better.

The pee(1) program (in which I am interested now), doesn't have
any examples at all.  And it doesn't have a "conventional" usage,
so it's not trivial to know how to make it work.

Cheers,

Alex


-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.19.0-1-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages moreutils depends on:
ii  libc6  2.34-7
ii  libipc-run-perl20220807.0-1
ii  libtime-duration-perl  1.21-1
ii  libtimedate-perl   2.3300-2
ii  perl   5.34.0-5

moreutils recommends no packages.

moreutils suggests no packages.

-- no debconf information

Bug#1019257: vim: syntax highlight: roff, man: man highlighting could be improved with some roff rules

[Alejandro Colomar]

Package: vim
Version: 2:9.0.0242-1
Severity: wishlist
Tags: upstream
X-Debbugs-Cc: alx.manpa...@gmail.com, gr...@gnu.org

Hi,

man(7) pages with a filename as foo.man are interpreted by vim as
written in man(7).  However, if the filename is written as foo.7,
vim thinks they are written in roff(7).  That's not a big issue,
but it's not really correct: although manual pages written in pure
roff(7) will work with man(1), it's very rare to find such pages
in the wild.  Vim could be fixed to realize that .[0-9] files are
man(7) pages, and highlight them as such.

I realized that vim didn't consider those as true man(7) pages
when I wrote some pages with the *.man extension for some tests.
The highlighting is different, and in some ways inferior.

Vim highlights macros, embedded tbl(1), and comments, within the
manual pages when it thinks they are written in roff(7).  But when
it thinks they are written in man(7), it doesn't highlight any of
those things, and it's a bit more difficult to read.

Cheers,

Alex


-- Package-specific info:

--- real paths of main Vim binaries ---
/usr/bin/vi is /usr/bin/vim.basic
/usr/bin/vim is /usr/bin/vim.basic

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.18.0-4-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages vim depends on:
ii  libacl1  2.3.1-1
ii  libc62.34-7
ii  libgpm2  1.20.7-10
ii  libselinux1  3.4-1+b1
ii  libsodium23  1.0.18-1
ii  libtinfo66.3+20220423-2
ii  vim-common   2:9.0.0242-1
ii  vim-runtime  2:9.0.0242-1

vim recommends no packages.

Versions of packages vim suggests:
ii  universal-ctags [ctags]  5.9.20210829.0-1
pn  vim-doc  
pn  vim-scripts  

-- no debconf information

Bug#1018737: /usr/bin/rst2man: rst2man: .TH 5th field shouldn't be empty

[Alejandro Colomar]

Hi Dmitry,

On 9/5/22 18:42, Dmitry Shachnev wrote:

Hi Alejandro!

On Mon, Aug 29, 2022 at 09:14:26PM +0200, Alejandro Colomar wrote:

Package: python3-docutils
Version: 0.17.1+dfsg-2
Severity: normal
File: /usr/bin/rst2man
Tags: upstream
X-Debbugs-Cc: alx.manpa...@gmail.com, gr...@gnu.org, Quentin Monnet 


Hi,

When rst2man has no information to generate the 5th field to the
.TH macro (the one that sets the title line, i.e., the header and
footer of the manual page), it generates it as an empty argument,
that is "".  groff(1) and mandoc(1) have good defaults for the 5th
field of .TH when it is not specified, so that most manual pages
should need to specify it, but to use that default, the field has
to be missing, and an empty argument is an existing argument.


Regarding this bug, upstream wants to know [1] whether omitting the 5th
argument will work with all troff/manpage writers.

I believe it is the case, but can you confirm?


AFAIK, it will work.  The behavior may differ, in that groff(1) and 
mandoc(1) produce a default text, while others may not produce any text 
at all, but it should work.




[1]: https://sourceforge.net/p/docutils/bugs/458/#b7b6

--
Dmitry Shachnev


Cheers,

Alex

--
Alejandro Colomar
<http://www.alejandro-colomar.es/>


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1018901: /bin/nc.traditional: nc -U: Add support for Unix sockets

[Alejandro Colomar]

Package: netcat-traditional
Version: 1.10-47
Severity: wishlist
File: /bin/nc.traditional
Tags: upstream
X-Debbugs-Cc: alx.manpa...@gmail.com


Hi,

It would be nice if nc(1) could support Unix sockets (including
abstract ones).  OpenBSD's nc(1), which is based on the same
original Hobbit's source has support for them.

Cheers,

Alex


-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.18.0-4-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages netcat-traditional depends on:
ii  libc6  2.34-7

netcat-traditional recommends no packages.

netcat-traditional suggests no packages.

-- no debconf information

Bug#1018737: /usr/bin/rst2man: rst2man: .TH 5th field shouldn't be empty

[Alejandro Colomar]

On 8/29/22 21:14, Alejandro Colomar wrote:

Package: python3-docutils
Version: 0.17.1+dfsg-2
Severity: normal
File: /usr/bin/rst2man
Tags: upstream
X-Debbugs-Cc: alx.manpa...@gmail.com, gr...@gnu.org, Quentin Monnet 



Hi,

When rst2man has no information to generate the 5th field to the
.TH macro (the one that sets the title line, i.e., the header and
footer of the manual page), it generates it as an empty argument,
that is "".  groff(1) and mandoc(1) have good defaults for the 5th
field of .TH when it is not specified, so that most manual pages
should need to specify it, but to use that default, the field has


s/should/shouldn't/


to be missing, and an empty argument is an existing argument.
I'll show an example, which may be more explicative:


--
Alejandro Colomar
<http://www.alejandro-colomar.es/>


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1018737: /usr/bin/rst2man: rst2man: .TH 5th field shouldn't be empty

[Alejandro Colomar]

Package: python3-docutils
Version: 0.17.1+dfsg-2
Severity: normal
File: /usr/bin/rst2man
Tags: upstream
X-Debbugs-Cc: alx.manpa...@gmail.com, gr...@gnu.org, Quentin Monnet 



Hi,

When rst2man has no information to generate the 5th field to the
.TH macro (the one that sets the title line, i.e., the header and
footer of the manual page), it generates it as an empty argument,
that is "".  groff(1) and mandoc(1) have good defaults for the 5th
field of .TH when it is not specified, so that most manual pages
should need to specify it, but to use that default, the field has
to be missing, and an empty argument is an existing argument.
I'll show an example, which may be more explicative:

$ cat th1.man 
.TH title 7 1234-04-05 foo-1.0 fifth
$ man -P cat ./th1.man 
title(7)  fifth title(7)

foo‐1.01234‐04‐05   title(7)


$ cat th2.man 
.TH title 7 1234-04-05 foo-1.0 ""
$ man -P cat ./th2.man 
title(7)title(7)

foo‐1.01234‐04‐05   title(7)


$ cat th3.man 
.TH title 7 1234-04-05 foo-1.0
$ man -P cat ./th3.man 
title(7)Miscellaneous Information Manualtitle(7)

foo‐1.01234‐04‐05   title(7)


So, please remove that "" and just use 4 fields if there's no
information for filling it.

Cheers,

Alex


-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.18.0-4-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages python3-docutils depends on:
ii  docutils-common  0.17.1+dfsg-2
ii  python3  3.10.6-1
ii  python3-roman3.3-1

Versions of packages python3-docutils recommends:
ii  libpaper-utils1.1.28+b1
ii  python3-pil   9.2.0-1+b1
ii  python3-pygments  2.12.0+dfsg-2

Versions of packages python3-docutils suggests:
pn  docutils-doc
pn  fonts-linuxlibertine | ttf-linux-libertine  
pn  texlive-lang-french 
ii  texlive-latex-base  2022.20220722-1
ii  texlive-latex-recommended   2022.20220722-1

-- no debconf information

Bug#1016527: rst2man: --date should be used to form the .TH title heading

[Alejandro Colomar]

Hi Ingo,

On 8/2/22 16:17, Ingo Schwarze wrote:

Strictly speaking, the third argument of the man(7) .TH macro is supposed
to be the date when a human being last edited the content of the manual
page, or in case rst2man(1) is used, the date when a human being last
edited the content of the input '*.rst' file, *not* the date when
rst2man(1) did the format conversion.


I use it to update bpf-helpers(7), from kernel stuff.  See 
<https://git.kernel.org/pub/scm/docs/man-pages/man-pages.git/commit/man7/bpf-helpers.7?id=19c7f78393f2b038e76099f87335ddf43a87f039>


I pick a file from the linux git repo, so the fs timestamp is going to 
be meaningless.  It would make sense to add an optional argument to the 
`--date` option, so that one would be able to pass a more meaningful date:


/path/to/linux//scripts/bpf_doc.py | rst2man --date="..." > 
man7/bpf-helpers.7




That said, i am able to reproduce that the rst2man(1) program contained
in the py3-docutils-0.17.1 package on OpenBSD-current also puts the line
"Generated on: 2022\-08\-02." into the NAME section, which is indeed a
severe man(7) syntax error.  So the bug appears to be operating system
independent.

If the date of the last human edit is unknown, putting the date on
which rst2man(1) was run into the third argument of the .TH macro
is of course still better than putting it into a place where it
violates the syntax of the man(7) language.  On the other hand,
couldn't the correct time be found by inspecting the mtime of
the inode of the '*.rst' file?



The input might very well be stdin.  What to do in that case?  I guess 
current date would be the best thing to do.


Cheers,

Alex

--
Alejandro Colomar
<http://www.alejandro-colomar.es/>


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1016527: rst2man: --date should be used to form the .TH title heading

[Alejandro Colomar]

Package: python3-docutils
Version: 0.17.1+dfsg-2
Severity: normal
Tags: upstream
X-Debbugs-Cc: Alejandro Colomar , , 
Quentin Monnet 

Hi,

The --date argument to rst2man(1) produces the following text:

Generated on: -MM-DD

And that text is put in the NAME section of the manual page.  That
is incorrect.  The date should be put as the 3rd argument to the
.TH macro, preferably in ISO 8601 format (-MM-DD):

.TH title section date source-and-version manual


Cheers,

Alex



-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.18.0-2-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages python3-docutils depends on:
ii  docutils-common  0.17.1+dfsg-2
ii  python3  3.10.5-3
ii  python3-roman3.3-1

Versions of packages python3-docutils recommends:
ii  libpaper-utils1.1.28+b1
ii  python3-pil   9.2.0-1+b1
ii  python3-pygments  2.12.0+dfsg-2

Versions of packages python3-docutils suggests:
pn  docutils-doc
pn  fonts-linuxlibertine | ttf-linux-libertine  
pn  texlive-lang-french 
ii  texlive-latex-base  2022.20220722-1
ii  texlive-latex-recommended   2022.20220722-1

-- no debconf information

Bug#1016412: dh-make: manpage.1.ex: Incorrect formatting for dash

[Alejandro Colomar (man-pages)]

Hi Baptiste,

On 7/31/22 13:49, Baptiste Beauplat wrote:

Hi Alejandro,

On 2022/07/31 12:35 PM, Alejandro Colomar wrote:

The template page 'manpage.1.ex' uses '-' instead of '\-' for a
dash that should be a Latin minus sign (as it's in the context of
command options).  Using '-' would produce a hyphen, which if
copy, wouldn't be interpreted correctly by a command.

The offending line in the file is 41:

options starting with two dashes ('-')


When I run the following command on the manpage :

man ./manpage.1.ex | xxd

The resulting text from the dash line 41 is converted to the correct 2d
minus ascii char.

The same is true for the two examples following that text, which are
correctly shown as \-\- in the source.

I am missing something? Or maybe the fact that this text is in a .SH
section make it work correctly?


Upstream groff(1) renders '-' and '\-' differently, as they should.
However, since many manual pages in existence are incorrect, and they 
use '-' when they should use '\-', Debian modifies the behavior by 
downgrading hyphens into Latin minus sign.


Let's fix the page in the hope that Debian can some day remove that 
workaround.


See the relevant part of :

.  \" Debian: Strictly, "-" is a hyphen while "\-" is a minus sign, and the
.  \" former may not always be rendered in the form expected for things like
.  \" command-line options.  Uncomment this if you want to make sure that
.  \" manual pages you're writing are clear of this problem.
.  if '\*[.T]'utf8' \
.char - \[hy]

Cheers,

Alex

--
Alejandro Colomar
Linux man-pages comaintainer; http://www.kernel.org/doc/man-pages/
http://www.alejandro-colomar.es/

Bug#1016415: manpages: [src] manpages: debian/POSIX-MANPAGES is not correct anymore

[Alejandro Colomar]

Source: manpages
Version: 5.13-1
Severity: normal
X-Debbugs-Cc: alx.manpa...@gmail.com

Hi Tobias and Marcos,

The debian/POSIX-MANPAGES file says that the POSIX pages are
included in the upstream package, but they aren't anymore.
They were splitted into their own repository a long time ago.

Please remove or update that file.

Cheers,

Alex


-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.17.0-1-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#1016412: dh-make: manpage.1.ex: Incorrect formatting for dash

[Alejandro Colomar]

Package: dh-make
Version: 2.202202
Severity: normal
X-Debbugs-Cc: alx.manpa...@gmail.com

Hi,

The template page 'manpage.1.ex' uses '-' instead of '\-' for a
dash that should be a Latin minus sign (as it's in the context of
command options).  Using '-' would produce a hyphen, which if
copy, wouldn't be interpreted correctly by a command.

The offending line in the file is 41:

options starting with two dashes ('-')

Cheers,

Alex


-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.17.0-1-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages dh-make depends on:
ii  debhelper  13.8
ii  dpkg-dev   1.21.9
ii  make   4.3-4.1
ii  python33.10.5-3

dh-make recommends no packages.

Versions of packages dh-make suggests:
ii  build-essential  12.9

-- no debconf information

Bug#1015719: libc6-dev: Build glibc with latest packaged kernel version

[Alejandro Colomar]

Hi Aurelien,

On 7/25/22 19:39, Aurelien Jarno wrote:

On 2022-07-25 14:51, Alejandro Colomar wrote:

E.g., when one runs `apt-get upgrade`, if the kernel is upgraded,
update-libc-syscalls(1) would be called by apt-get as a post install script,
and libc macros would have the new syscall numbers provided by the new
kernel.  No need to wait glibc programmers to provide the backport.

Makes sense?


I don't think so. You do not want to modify files provided by a package.


Yeah, maybe it's better that the packagers run that script at packaging 
time, instead of apt-get at install time.  But, the script would be a 
good thing, I think, independently of who runs it.



Cheers,

Alex


--
Alejandro Colomar
<http://www.alejandro-colomar.es/>


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1015719: libc6-dev: Build glibc with latest packaged kernel version

[Alejandro Colomar]

Hi Florian!

On 7/25/22 12:38, Florian Weimer wrote:

* Alejandro Colomar via Libc-alpha:


Is there an easy way to regenerate that header to get the tatest
syscalls?  Maybe a command could be supplied so that users (or at
least distributors) have it easy to regenerate them?  Maybe it already
exists but it's not widely known?


I have recently backported the syscall-names.list updates to glibc 2.34,
but not glibc 2.33.  It's a simple backport.

We could perhaps enhance the glibc build process that it uses the union
of the known system call names and what's found in the kernel headers.


I guess it's a simple backport, since it's just adding the macros (I 
guess 0 side effects).


But maybe providing a script, e.g., update-libc-syscalls(1), that 
distributions and users can call when updating a kernel to immediately 
backport syscalls to their system, would make it even simpler.


E.g., when one runs `apt-get upgrade`, if the kernel is upgraded, 
update-libc-syscalls(1) would be called by apt-get as a post install 
script, and libc macros would have the new syscall numbers provided by 
the new kernel.  No need to wait glibc programmers to provide the backport.


Makes sense?

Cheers,

Alex

--
Alejandro Colomar
<http://www.alejandro-colomar.es/>


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1016020: pinentry-gtk2: doesn't support ^U (control-U)

[Alejandro Colomar]

Package: pinentry-gtk2
Version: 1.2.0-2
Severity: important
Tags: upstream
X-Debbugs-Cc: alx.manpa...@gmail.com


Hi,

pinentry-gtk2 should support ^U to clear the password field,
as is common in many other places where a password is accepted
(login prompts, ...).

pinentry-tty added support for it ,
so maybe you can take a similar approach?

Cheers,

Alex


-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.18.0-2-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages pinentry-gtk2 depends on:
ii  libassuan0 2.5.5-4
ii  libc6  2.33-8
ii  libglib2.0-0   2.72.3-1
ii  libgpg-error0  1.45-2
ii  libgtk2.0-02.24.33-2
ii  libncursesw6   6.3+20220423-2
ii  libsecret-1-0  0.20.5-2
ii  libtinfo6  6.3+20220423-2

pinentry-gtk2 recommends no packages.

Versions of packages pinentry-gtk2 suggests:
pn  pinentry-doc  

-- no debconf information

Bug#1015719: libc6-dev: Build glibc with latest packaged kernel version

[Alejandro Colomar (man-pages)]

[CC += libc-alpha]

Hi glibc developers,

On 7/24/22 14:24, Aurelien Jarno wrote:

Hi,

On 2022-07-24 12:39, Alejandro Colomar (man-pages) wrote:

Hi Aurelien,

On 7/23/22 11:43, Aurelien Jarno wrote:

Hi,

On 2022-07-19 21:55, Alejandro Colomar wrote:

Package: libc6-dev
Version: 2.33-8
Severity: normal
X-Debbugs-Cc: alx.manpa...@gmail.com


Hi,

We had a discussion in NGINX Unit about if we should use __NR_xxx
or SYS_xxx syscall numbers.  As maintainer of the Linux man-pages,
I suggested that we should use the libc macros (SYS_xxx), since
they are compatible with other non-Linux systems, and also because
they are the documented way for user space.  However, there was
some concern that someone might be running a new kernel with an
old glibc, and that __NR_xxx symbols might be available but not
SYS_xxx in that case.


Yes that sounds good.


Since the  (included through )
header is generated automatically from the kernel headers at glibc
build time, Debian should make sure that the latest available
kernel headers are used, so building the latest Sid glibc package
should be done on a system with also the latest kernel available
in Sid, to have a complete SYS_xxx list.


This is basically what is done, the buildd chroots are updated twice a
week, so in the worst case glibc is build against a kernel headers
package that is 4 days old.


Is it?  I have kernel 5.18, but my bits/syscalls.h still says it was
generated from kernel 5.10 (that's a long time ago).  I have the latest Sid
packages for both the kernel and glibc.


Yes, this is definitely the case, glibc 2.33-8 has been built against
linux-libc-dev 5.18.5-1. What is wrong is "header is generated
automatically from the kernel headers at glibc build time". They are
generated by upstream at release time, not at build time.


Is there an easy way to regenerate that header to get the tatest 
syscalls?  Maybe a command could be supplied so that users (or at least 
distributors) have it easy to regenerate them?  Maybe it already exists 
but it's not widely known?


Cheers,

Alex

--
Alejandro Colomar
Linux man-pages comaintainer; http://www.kernel.org/doc/man-pages/
http://www.alejandro-colomar.es/

Bug#1015719: libc6-dev: Build glibc with latest packaged kernel version

[Alejandro Colomar (man-pages)]

Hi Aurelien,

On 7/23/22 11:43, Aurelien Jarno wrote:

Hi,

On 2022-07-19 21:55, Alejandro Colomar wrote:

Package: libc6-dev
Version: 2.33-8
Severity: normal
X-Debbugs-Cc: alx.manpa...@gmail.com


Hi,

We had a discussion in NGINX Unit about if we should use __NR_xxx
or SYS_xxx syscall numbers.  As maintainer of the Linux man-pages,
I suggested that we should use the libc macros (SYS_xxx), since
they are compatible with other non-Linux systems, and also because
they are the documented way for user space.  However, there was
some concern that someone might be running a new kernel with an
old glibc, and that __NR_xxx symbols might be available but not
SYS_xxx in that case.


Yes that sounds good.


Since the  (included through )
header is generated automatically from the kernel headers at glibc
build time, Debian should make sure that the latest available
kernel headers are used, so building the latest Sid glibc package
should be done on a system with also the latest kernel available
in Sid, to have a complete SYS_xxx list.


This is basically what is done, the buildd chroots are updated twice a
week, so in the worst case glibc is build against a kernel headers
package that is 4 days old.


Is it?  I have kernel 5.18, but my bits/syscalls.h still says it was 
generated from kernel 5.10 (that's a long time ago).  I have the latest 
Sid packages for both the kernel and glibc.


Cheers,

Alex



Regards
Aurelien



--
Alejandro Colomar
Linux man-pages comaintainer; http://www.kernel.org/doc/man-pages/
http://www.alejandro-colomar.es/

Bug#1015719: libc6-dev: Build glibc with latest packaged kernel version

[Alejandro Colomar]

Package: libc6-dev
Version: 2.33-8
Severity: normal
X-Debbugs-Cc: alx.manpa...@gmail.com


Hi,

We had a discussion in NGINX Unit about if we should use __NR_xxx
or SYS_xxx syscall numbers.  As maintainer of the Linux man-pages,
I suggested that we should use the libc macros (SYS_xxx), since
they are compatible with other non-Linux systems, and also because
they are the documented way for user space.  However, there was
some concern that someone might be running a new kernel with an
old glibc, and that __NR_xxx symbols might be available but not
SYS_xxx in that case.

Since the  (included through )
header is generated automatically from the kernel headers at glibc
build time, Debian should make sure that the latest available
kernel headers are used, so building the latest Sid glibc package
should be done on a system with also the latest kernel available
in Sid, to have a complete SYS_xxx list.

Cheers,

Alex


-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.18.0-2-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libc6-dev depends on:
ii  libc-dev-bin2.33-8
ii  libc6   2.33-8
ii  libcrypt-dev1:4.4.28-2
ii  libnsl-dev  1.3.0-2
ii  linux-libc-dev  5.18.5-1
ii  rpcsvc-proto1.4.2-4

libc6-dev recommends no packages.

Versions of packages libc6-dev suggests:
pn  glibc-doc 
ii  manpages-dev  5.13-1

-- no debconf information

Bug#1014003: iwyu 0.18 requires clang-14

[Alejandro Colomar]

Package: iwyu
Version: 8.18-1
Severity: grave
Justification: renders package unusable
X-Debbugs-Cc: alx.manpa...@gmail.com


Hi,

iwyu 0.18 requires clang 14 to work, as specified on their documentation.
Having an older version of clang causes iwyu to fail for the most basic
stuff, such as finding compiler builtin headers (e.g., ).

Just by installing the correct clang version, the problem was fixed
(I'm not sure if installing a clang library, without installing the full
clang would have been enough, though).

Cheers,

Alex


-- System Information:
Debian Release: bookworm/sid
Architecture: amd64 (x86_64)

Kernel: Linux 5.18.0-2-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages iwyu depends on:
ii  clang   1:13.0-54
ii  clang-111:11.1.0-6+b2
ii  clang-131:13.0.1-6
ii  clang-141:14.0.6-1
ii  libc6   2.33-7
ii  libclang-cpp14  1:14.0.6-1
ii  libllvm14   1:14.0.6-1
ii  libstdc++6  12.1.0-4
ii  python3 3.10.4-1+b1

iwyu recommends no packages.

iwyu suggests no packages.

-- no debconf information

Bug#1011482: cgit: Package cgit-pink as a more up-to-date alternative for cgit

[Alejandro Colomar]

Package: cgit
Severity: wishlist
X-Debbugs-Cc: alx.manpa...@gmail.com

Dear maintainer,

Could you please package cgit-pink as an alternative to cgit that
is well maintained?  cgit development has been stopped for a year
now.

cgit-pink: 

Cheers,

Alex

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.17.0-1-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages cgit depends on:
ii  libc62.33-7
pn  liblua5.1-0  
ii  zlib1g   1:1.2.11.dfsg-4

Versions of packages cgit recommends:
pn  apache2 | httpd  

Versions of packages cgit suggests:
ii  python3   3.10.4-1+b1
pn  python3-docutils  
pn  python3-markdown  
ii  python3-pygments  2.11.2+dfsg-2

Bug#1010495: iwyu: Depends: clang version is incorrect

[Alejandro Colomar]

Package: iwyu
Version: 8.18-1
Severity: important
X-Debbugs-Cc: alx.manpa...@gmail.com

Hi,

iwyu 0.18 requires clang 14.  See the dependency table here:
.

I noticed because I just upgraded my system from Debian stable to unstable,
and I until I installed (manually) clang-14, iwyu(1) didn't work:

 In file included from tmp/src/man2/add_key.2.d/add_key.c:2:
 /usr/include/x86_64-linux-gnu/sys/types.h:144:10: fatal error: 'stddef.h' file 
not found
 #include 
  ^~

After installing clang-14, the issue is fixed.
Please, fix the dependencies of the iwyu package.


Thanks,

Alex



-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.17.0-1-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages iwyu depends on:
ii  clang   1:13.0-54
ii  clang-131:13.0.1-3+b2
ii  clang-141:14.0.3-1
ii  libc6   2.33-7
ii  libclang-cpp14  1:14.0.3-1
ii  libllvm14   1:14.0.3-1
ii  libstdc++6  12-20220428-1
ii  python3 3.10.4-1+b1

iwyu recommends no packages.

iwyu suggests no packages.

-- no debconf information

Bug#1010458: linux/sysctl.h: unknown type name 'size_t'

[Alejandro Colomar]

Package: linux-libc-dev
Version: 5.17.3-1
Severity: normal
Tags: upstream
X-Debbugs-Cc: alx.manpa...@gmail.com


I was cleaning up the example programs in the man-pages by using
iwyu(1), when I found that  is using 'size_t'
without including any definition for it.

See the following example program:

$ cat tmp/src/man2/sysctl.2.d/sysctl.c

#define _GNU_SOURCE
#include 
#include 
#include 
#include 
#include 
#include 

int _sysctl(struct __sysctl_args *args );

#define OSNAMESZ 100

int
main(void)
{
struct __sysctl_args args;
char osname[OSNAMESZ];
size_t osnamelth;
int name[] = { CTL_KERN, KERN_OSTYPE };

memset(, 0, sizeof(args));
args.name = name;
args.nlen = sizeof(name)/sizeof(name[0]);
args.oldval = osname;
args.oldlenp = 

osnamelth = sizeof(osname);

if (syscall(SYS__sysctl, ) == -1) {
perror("_sysctl");
exit(EXIT_FAILURE);
}
printf("This machine is running %*s\n", (int) osnamelth, osname);
exit(EXIT_SUCCESS);
}

for which I get the following errors:

$ cc -c -std=gnu17 -Wall -Wextra -Werror -Wno-error=unused-parameter \
 -Wno-error=sign-compare -Wno-error=format \
 -o tmp/src/man2/sysctl.2.d/sysctl.o \
 tmp/src/man2/sysctl.2.d/sysctl.c;
In file included from tmp/src/man2/sysctl.2.d/sysctl.c:3:
/usr/include/linux/sysctl.h:39:9: error: unknown type name 'size_t'
   39 | size_t *oldlenp;
  | ^~
/usr/include/linux/sysctl.h:41:9: error: unknown type name 'size_t'
   41 | size_t newlen;
  | ^~
tmp/src/man2/sysctl.2.d/sysctl.c: In function 'main':
tmp/src/man2/sysctl.2.d/sysctl.c:26:18: error: assignment to 'int *' 
from incompatible pointer type 'size_t *' {aka 'long unsigned int *'} 
[-Werror=incompatible-pointer-types]
   26 | args.oldlenp = 
  |  ^
cc1: all warnings being treated as errors


It seems that it's supposed to know some types, but for some reason
'size_t' is not defined by the included headers:

$ grep include 
#include 


Cheers,

Alex



-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.16.0-5-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

-- no debconf information

Bug#1010178: ruby-dev: pkg-config: -I triggers system header warnings from Clang

[Alejandro Colomar]

Package: ruby-dev
Version: 1:2.7+2
Severity: normal
X-Debbugs-Cc: alx.manpa...@gmail.com


Hi,

I'm getting warnings from ruby system headers, and I see that the pkg-config
file included with the package is using `-I` instead of `-isystem`.

$ cat ruby.c
#include 

int
main(void)
 {
static const char *argv[3] = {
"NGINX_Unit", "-rrbconfig",
"-eprint RbConfig::CONFIG['libdir']"
};

RUBY_INIT_STACK;
ruby_init();
return ruby_run_node(ruby_options(3, (char **) argv));
 }


$ pkg-config --cflags ruby
-I/usr/include/x86_64-linux-gnu/ruby-2.7.0 -I/usr/include/ruby-2.7.0


$ clang ruby.c $(pkg-config --cflags --libs ruby)
In file included from ruby.c:1:
In file included from /usr/include/ruby-2.7.0/ruby.h:33:
/usr/include/ruby-2.7.0/ruby/ruby.h:1863:1: warning: unknown attribute 
'__error__' ignored [-Wunknown-attributes]
ERRORFUNC((" argument length doesn't match"), int 
rb_varargs_bad_length(int,int));
^
/usr/include/x86_64-linux-gnu/ruby-2.7.0/ruby/config.h:153:43: note: expanded 
from macro 'ERRORFUNC'
#define ERRORFUNC(mesg,x) __attribute__ ((__error__ mesg)) x
  ^


I suggest using -isystem instead of -I to silence the warnings (and also,
to fix the warnings themselves, but I'll report those upstream directly).


Thanks,

Alex


-- System Information:
Debian Release: 11.3
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-13-amd64 (SMP w/4 CPU threads)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages ruby-dev depends on:
ii  ruby2.7-dev  2.7.4-1+deb11u1

ruby-dev recommends no packages.

ruby-dev suggests no packages.

-- no debconf information