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#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#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#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#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#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#1000146: cppcheck: incorrect dependencies: libc6 should be >= 2.32

[Alejandro Colomar]

Package: cppcheck
Version: 2.6-1
Severity: grave
Justification: renders package unusable
X-Debbugs-Cc: colomar.6@gmail.com

Dear Maintainer,

I installed and run cppcheck on a system which I had not used for half a year.
For that reason, many of its packages were outdated.

glibc was on version 2.31.

When I run cppcheck, it failed with the following error:

cppcheck: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.32' not found 
(required by cppcheck)

I found the following dependencies' information:

$ apt-rdepends cppcheck | head -n2
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
cppcheck
  Depends: libc6 (>= 2.29)


So it clearly is incorrect, AFAICS.
It should declare a dependency for libc6 2.32


Regards,
Alex


P.S.:
You'll find below that my installed libc6 is 2.32;
that's because I updated it to be able to use checkpatch,
prior to sending this bug report.
Please ignore that.


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

Kernel: Linux 5.10.0-7-amd64 (SMP w/4 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
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.32-4
ii  libgcc-s1 11.2.0-10
ii  libpcre3  2:8.39-13
ii  libstdc++611.2.0-10
ii  libtinyxml2-9 9.0.0+dfsg-3
ii  libz3-4   4.8.12-1+b1
iu  python3   3.9.8-1
ii  python3-pygments  2.7.1+dfsg-2.1

cppcheck recommends no packages.

Versions of packages cppcheck suggests:
ii  clang 1:11.0-51+nmu5
ii  clang-tidy1:11.0-51+nmu5
pn  cppcheck-gui  

-- no debconf information