Bug#1066198: gbatnav: FTBFS: gbnserver.c:411:24: error: implicit declaration of function ‘net_listen’ [-Werror=implicit-function-declaration]

[Lucas Nussbaum]

Source: gbatnav
Version: 1.0.4cvs20051004-6
Severity: serious
Justification: FTBFS
Tags: trixie sid ftbfs
User: lu...@debian.org
Usertags: ftbfs-20240313 ftbfs-trixie ftbfs-impfuncdef

Hi,

During a rebuild of all packages in sid, your package failed to build
on amd64.

This is most likely caused by a change in dpkg 1.22.6, that enabled
-Werror=implicit-function-declaration. For more information, see
https://wiki.debian.org/qa.debian.org/FTBFS#A2024-03-13_-Werror.3Dimplicit-function-declaration

Relevant part (hopefully):
> gcc -DHAVE_CONFIG_H -I. -I.. -I./../common -I./../intl 
> -DGNOMELOCALEDIR=\""/usr/share/locale"\" -I/usr/include  
> -I./../gbnclient/pixmaps -DBINDIR=\"/usr/games\" -I/usr/include/goocanvas-2.0 
> -I/usr/include/gtk-3.0 -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 
> -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/harfbuzz 
> -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/libmount 
> -I/usr/include/blkid -I/usr/include/fribidi -I/usr/include/cairo 
> -I/usr/include/pixman-1 -I/usr/include/gdk-pixbuf-2.0 
> -I/usr/include/x86_64-linux-gnu -I/usr/include/webp 
> -I/usr/include/gio-unix-2.0 -I/usr/include/cloudproviders 
> -I/usr/include/atk-1.0 -I/usr/include/at-spi2-atk/2.0 
> -I/usr/include/at-spi-2.0 -I/usr/include/dbus-1.0 
> -I/usr/lib/x86_64-linux-gnu/dbus-1.0/include -pthread   -Wdate-time 
> -D_FORTIFY_SOURCE=2  -g -O2 -Werror=implicit-function-declaration 
> -ffile-prefix-map=/<>=. -fstack-protector-strong 
> -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection -c 
> -o batnavggz.o batnavggz.c
> /usr/lib/x86_64-linux-gnu/glib-2.0/glib-compile-schemas --strict --dry-run  
> --schema-file=net.sf.batnav.gbnserver.gschema.xml && mkdir -p . && touch 
> net.sf.batnav.gbnserver.gschema.valid
> gbnserver.c: In function ‘main_loop’:
> gbnserver.c:411:24: error: implicit declaration of function ‘net_listen’ 
> [-Werror=implicit-function-declaration]
>   411 | usuario.sock = net_listen(usuario.server_name,usuario.port);
>   |^~
> cc1: some warnings being treated as errors
> make[3]: *** [Makefile:537: gbnserver.o] Error 1


The full build log is available from:
http://qa-logs.debian.net/2024/03/13/gbatnav_1.0.4cvs20051004-6_unstable.log

All bugs filed during this archive rebuild are listed at:
https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ftbfs-20240313;users=lu...@debian.org
or:
https://udd.debian.org/bugs/?release=na=ign=7=7=only=ftbfs-20240313=lu...@debian.org=1=1=1=1#results

A list of current common problems and possible solutions is available at
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!

If you reassign this bug to another package, please mark it as 'affects'-ing
this package. See https://www.debian.org/Bugs/server-control#affects

If you fail to reproduce this, please provide a build log and diff it with mine
so that we can identify if something relevant changed in the meantime.

Bug#1066196: pacman4console: FTBFS: pacman.c:142:12: error: implicit declaration of function ‘GameOverScreen’ [-Werror=implicit-function-declaration]

[Lucas Nussbaum]

Source: pacman4console
Version: 1.3-1
Severity: serious
Justification: FTBFS
Tags: trixie sid ftbfs
User: lu...@debian.org
Usertags: ftbfs-20240313 ftbfs-trixie ftbfs-impfuncdef

Hi,

During a rebuild of all packages in sid, your package failed to build
on amd64.

This is most likely caused by a change in dpkg 1.22.6, that enabled
-Werror=implicit-function-declaration. For more information, see
https://wiki.debian.org/qa.debian.org/FTBFS#A2024-03-13_-Werror.3Dimplicit-function-declaration

Relevant part (hopefully):
> gcc pacman.c -o pacman -DDATAROOTDIR=\"/usr/local/share\" -Wdate-time 
> -D_FORTIFY_SOURCE=2 -g -O2 -Werror=implicit-function-declaration 
> -ffile-prefix-map=/<>=. -fstack-protector-strong 
> -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection 
> -Wl,-z,relro -lncurses
> In file included from pacman.c:21:
> pacman.h:3: warning: "DATAROOTDIR" redefined
> 3 | #define DATAROOTDIR "/usr/share"
>   | 
> : note: this is the location of the previous definition
> pacman.c: In function ‘main’:
> pacman.c:142:12: error: implicit declaration of function ‘GameOverScreen’ 
> [-Werror=implicit-function-declaration]
>   142 | if(GameOverScreen() == 1) loop = 0;
>   |^~
> pacman.c: In function ‘Delay’:
> pacman.c:294:5: warning: ‘ftime’ is deprecated: Use gettimeofday or 
> clock_gettime instead [-Wdeprecated-declarations]
>   294 | ftime(_start);
>   | ^
> In file included from pacman.c:20:
> /usr/include/x86_64-linux-gnu/sys/timeb.h:29:12: note: declared here
>29 | extern int ftime (struct timeb *__timebuf)
>   |^
> pacman.c:299:9: warning: ‘ftime’ is deprecated: Use gettimeofday or 
> clock_gettime instead [-Wdeprecated-declarations]
>   299 | ftime(_current);  //Update time and check if enough 
> time has overlapped
>   | ^
> /usr/include/x86_64-linux-gnu/sys/timeb.h:29:12: note: declared here
>29 | extern int ftime (struct timeb *__timebuf)
>   |^
> pacman.c: In function ‘LoadLevel’:
> pacman.c:589:25: warning: ignoring return value of ‘fscanf’ declared with 
> attribute ‘warn_unused_result’ [-Wunused-result]
>   589 | fscanf(fin, "%d", [a][b]);//Get 
> character from file
>   | ^~~
> pacman.c:602:9: warning: ignoring return value of ‘fscanf’ declared with 
> attribute ‘warn_unused_result’ [-Wunused-result]
>   602 | fscanf(fin, "%d", );
>   | ^~~
> cc1: some warnings being treated as errors
> make[1]: *** [Makefile:6: all] Error 1


The full build log is available from:
http://qa-logs.debian.net/2024/03/13/pacman4console_1.3-1_unstable.log

All bugs filed during this archive rebuild are listed at:
https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ftbfs-20240313;users=lu...@debian.org
or:
https://udd.debian.org/bugs/?release=na=ign=7=7=only=ftbfs-20240313=lu...@debian.org=1=1=1=1#results

A list of current common problems and possible solutions is available at
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!

If you reassign this bug to another package, please mark it as 'affects'-ing
this package. See https://www.debian.org/Bugs/server-control#affects

If you fail to reproduce this, please provide a build log and diff it with mine
so that we can identify if something relevant changed in the meantime.

Bug#1066195: a56: FTBFS: keybld.c:29:15: error: implicit declaration of function ‘gets’; did you mean ‘fgets’? [-Werror=implicit-function-declaration]

[Lucas Nussbaum]

Source: a56
Version: 1.3+dfsg-10
Severity: serious
Justification: FTBFS
Tags: trixie sid ftbfs
User: lu...@debian.org
Usertags: ftbfs-20240313 ftbfs-trixie ftbfs-impfuncdef

Hi,

During a rebuild of all packages in sid, your package failed to build
on amd64.

This is most likely caused by a change in dpkg 1.22.6, that enabled
-Werror=implicit-function-declaration. For more information, see
https://wiki.debian.org/qa.debian.org/FTBFS#A2024-03-13_-Werror.3Dimplicit-function-declaration

Relevant part (hopefully):
> cc -g -O2 -Werror=implicit-function-declaration 
> -ffile-prefix-map=/<>=. -fstack-protector-strong 
> -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection -O 
> -DLDEBUG -Wdate-time -D_FORTIFY_SOURCE=2 -Wl,-z,relro -Wl,-z,now -c keybld.c
> keybld.c:25:1: warning: return type defaults to ‘int’ [-Wimplicit-int]
>25 | main()
>   | ^~~~
> keybld.c: In function ‘main’:
> keybld.c:29:15: error: implicit declaration of function ‘gets’; did you mean 
> ‘fgets’? [-Werror=implicit-function-declaration]
>29 | while(gets(buf)) {
>   |   ^~~~
>   |   fgets
> keybld.c:37:27: error: implicit declaration of function ‘add_tok’ 
> [-Werror=implicit-function-declaration]
>37 | } else if(add_tok(buf, bp) == -1) {
>   |   ^~~
> keybld.c:42:9: error: implicit declaration of function ‘dump_machine’ 
> [-Werror=implicit-function-declaration]
>42 | dump_machine();
>   | ^~~~
> keybld.c: At top level:
> keybld.c:72:1: warning: return type defaults to ‘int’ [-Wimplicit-int]
>72 | add_tok(tok, actions)
>   | ^~~
> keybld.c: In function ‘add_tok’:
> keybld.c:88:12: error: implicit declaration of function ‘follow’ 
> [-Werror=implicit-function-declaration]
>88 | if(follow(*tok, tok + 1, stop) == -1)
>   |^~
> keybld.c: At top level:
> keybld.c:95:1: warning: return type defaults to ‘int’ [-Wimplicit-int]
>95 | follow(c, tp, sp)
>   | ^~
> keybld.c: In function ‘follow’:
> keybld.c:118:50: warning: cast to pointer from integer of different size 
> [-Wint-to-pointer-cast]
>   118 | arcp->arg = arcup->arg = (void 
> *)n_user_actions;
>   |  ^
> keybld.c: At top level:
> keybld.c:163:1: warning: return type defaults to ‘int’ [-Wimplicit-int]
>   163 | dump_machine()
>   | ^~~~
> keybld.c: In function ‘dump_machine’:
> keybld.c:171:21: warning: format ‘%d’ expects argument of type ‘int’, but 
> argument 2 has type ‘long unsigned int’ [-Wformat=]
>   171 | printf("/* %d bytes required for transition table storage 
> */\n",
>   |~^
>   | |
>   | int
>   |%ld
>   172 | sizeof(short) * TRANSITIONS * n_states);
>   | ~~
>   | |
>   | long unsigned int
> keybld.c:185:47: warning: cast from pointer to integer of different size 
> [-Wpointer-to-int-cast]
>   185 | printf("%d", -(int)tp->arg - 1);
>   |   ^
> cc1: some warnings being treated as errors
> make[2]: *** [Makefile:78: keybld.o] Error 1


The full build log is available from:
http://qa-logs.debian.net/2024/03/13/a56_1.3+dfsg-10_unstable.log

All bugs filed during this archive rebuild are listed at:
https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ftbfs-20240313;users=lu...@debian.org
or:
https://udd.debian.org/bugs/?release=na=ign=7=7=only=ftbfs-20240313=lu...@debian.org=1=1=1=1#results

A list of current common problems and possible solutions is available at
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!

If you reassign this bug to another package, please mark it as 'affects'-ing
this package. See https://www.debian.org/Bugs/server-control#affects

If you fail to reproduce this, please provide a build log and diff it with mine
so that we can identify if something relevant changed in the meantime.

Bug#1066194: nstreams: FTBFS: parse_tcpdump.c:262:50: error: implicit declaration of function ‘int2proto’ [-Werror=implicit-function-declaration]

[Lucas Nussbaum]

Source: nstreams
Version: 1.0.4-1
Severity: serious
Justification: FTBFS
Tags: trixie sid ftbfs
User: lu...@debian.org
Usertags: ftbfs-20240313 ftbfs-trixie ftbfs-impfuncdef

Hi,

During a rebuild of all packages in sid, your package failed to build
on amd64.

This is most likely caused by a change in dpkg 1.22.6, that enabled
-Werror=implicit-function-declaration. For more information, see
https://wiki.debian.org/qa.debian.org/FTBFS#A2024-03-13_-Werror.3Dimplicit-function-declaration

Relevant part (hopefully):
> gcc -g -O2 -Werror=implicit-function-declaration 
> -ffile-prefix-map=/<>=. -fstack-protector-strong 
> -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection 
> -I/usr/include/pcap  -I/usr/include -I/<>/includes -c 
> parse_tcpdump.c
> parse_tcpdump.c: In function ‘parse_tcpdump_line’:
> parse_tcpdump.c:262:50: error: implicit declaration of function ‘int2proto’ 
> [-Werror=implicit-function-declaration]
>   262 |  ret->src = ascaddr2intaddr(src, >ports[0], 
> int2proto(ret->proto));
>   |  ^
> cc1: some warnings being treated as errors
> make[2]: *** [Makefile:17: parse_tcpdump.o] Error 1


The full build log is available from:
http://qa-logs.debian.net/2024/03/13/nstreams_1.0.4-1_unstable.log

All bugs filed during this archive rebuild are listed at:
https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ftbfs-20240313;users=lu...@debian.org
or:
https://udd.debian.org/bugs/?release=na=ign=7=7=only=ftbfs-20240313=lu...@debian.org=1=1=1=1#results

A list of current common problems and possible solutions is available at
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!

If you reassign this bug to another package, please mark it as 'affects'-ing
this package. See https://www.debian.org/Bugs/server-control#affects

If you fail to reproduce this, please provide a build log and diff it with mine
so that we can identify if something relevant changed in the meantime.

Bug#1066193: adasockets: FTBFS: gnat1: error: ‘-Werror=’ argument ‘-Werror=implicit-function-declaration’ is not valid for Ada [-Werror]

[Lucas Nussbaum]

Source: adasockets
Version: 1.12-8
Severity: serious
Justification: FTBFS
Tags: trixie sid ftbfs
User: lu...@debian.org
Usertags: ftbfs-20240313 ftbfs-trixie ftbfs-impfuncdef

Hi,

During a rebuild of all packages in sid, your package failed to build
on amd64.

This is most likely caused by a change in dpkg 1.22.6, that enabled
-Werror=implicit-function-declaration. For more information, see
https://wiki.debian.org/qa.debian.org/FTBFS#A2024-03-13_-Werror.3Dimplicit-function-declaration

Relevant part (hopefully):
>   /bin/bash ../libtool --tag=CC --mode=compile \
>   ../support/adacompiler gnatmake -v -j8 -R -eS  -cargs -g -O2 -Wall -Werror 
> -gnatag -gnatwa -gnatwe -gnatg -g -O2 -Werror=implicit-function-declaration 
> -ffile-prefix-map=/<>=. -fstack-protector-strong 
> -fstack-clash-protection -fcf-protection  -gno-record-gcc-switches -I. -I. 
> -largs -Wl,-z,relro -Wl,-z,now -Wl,--no-allow-shlib-undefined 
> -Wl,--no-copy-dt-needed-entries -Wl,--no-undefined -margs sockets-thin.ads; \
> fi
> gcc-12 -I. -o constants_nodef ./constants.c -g -O2 
> -Werror=implicit-function-declaration -ffile-prefix-map=/<>=. 
> -fstack-protector-strong -fstack-clash-protection -Wformat 
> -Werror=format-security -fcf-protection -Wdate-time -D_FORTIFY_SOURCE=2 
> -Wl,-z,relro -Wl,-z,now -Wl,--no-allow-shlib-undefined 
> -Wl,--no-copy-dt-needed-entries -Wl,--no-undefined
> 
> GNATMAKE 12.3.0
> Copyright (C) 1992-2022, Free Software Foundation, Inc.
>   "split.ali" being checked ...
>   -> "split.ali" missing.
> x86_64-linux-gnu-gcc-12 -c -I./ -g -O2 -Wall -Werror -gnatag -gnatwa -gnatwe 
> -gnatg -g -O2 -Werror=implicit-function-declaration 
> -ffile-prefix-map=/<>=. -fstack-protector-strong 
> -fstack-clash-protection -fcf-protection -gno-record-gcc-switches -I. -I. -I- 
> ./split.adb
> gnat1: error: ‘-Werror=’ argument ‘-Werror=implicit-function-declaration’ is 
> not valid for Ada [-Werror]
> libtool: compile:  ../support/adacompiler gnatmake -v -j8 -R -eS -cargs -g 
> -O2 -Wall -Werror -gnatag -gnatwa -gnatwe -gnatg -g -O2 
> -Werror=implicit-function-declaration -ffile-prefix-map=/<>=. 
> -fstack-protector-strong -fstack-clash-protection -fcf-protection 
> -gno-record-gcc-switches -I. -I. -largs -Wl,-z,relro -Wl,-z,now 
> -Wl,--no-allow-shlib-undefined -Wl,--no-copy-dt-needed-entries 
> -Wl,--no-undefined -margs sockets-utils.adb  -fPIC -DPIC -o 
> .libs/sockets-utils.o
> libtool: compile:  ../support/adacompiler gnatmake -v -j8 -R -eS -cargs -g 
> -O2 -Wall -Werror -gnatag -gnatwa -gnatwe -gnatg -g -O2 
> -Werror=implicit-function-declaration -ffile-prefix-map=/<>=. 
> -fstack-protector-strong -fstack-clash-protection -fcf-protection 
> -gno-record-gcc-switches -I. -I. -largs -Wl,-z,relro -Wl,-z,now 
> -Wl,--no-allow-shlib-undefined -Wl,--no-copy-dt-needed-entries 
> -Wl,--no-undefined -margs sockets-stream_io.adb  -fPIC -DPIC -o 
> .libs/sockets-stream_io.o
> libtool: compile:  ../support/adacompiler gnatmake -v -j8 -R -eS -cargs -g 
> -O2 -Wall -Werror -gnatag -gnatwa -gnatwe -gnatg -g -O2 
> -Werror=implicit-function-declaration -ffile-prefix-map=/<>=. 
> -fstack-protector-strong -fstack-clash-protection -fcf-protection 
> -gno-record-gcc-switches -I. -I. -largs -Wl,-z,relro -Wl,-z,now 
> -Wl,--no-allow-shlib-undefined -Wl,--no-copy-dt-needed-entries 
> -Wl,--no-undefined -margs sockets-link.ads  -fPIC -DPIC -o 
> .libs/sockets-link.o
> libtool: compile:  ../support/adacompiler gnatmake -v -j8 -R -eS -cargs -g 
> -O2 -Wall -Werror -gnatag -gnatwa -gnatwe -gnatg -g -O2 
> -Werror=implicit-function-declaration -ffile-prefix-map=/<>=. 
> -fstack-protector-strong -fstack-clash-protection -fcf-protection 
> -gno-record-gcc-switches -I. -I. -largs -Wl,-z,relro -Wl,-z,now 
> -Wl,--no-allow-shlib-undefined -Wl,--no-copy-dt-needed-entries 
> -Wl,--no-undefined -margs sockets-types.ads  -fPIC -DPIC -o 
> .libs/sockets-types.o
> libtool: compile:  ../support/adacompiler gnatmake -v -j8 -R -eS -cargs -g 
> -O2 -Wall -Werror -gnatag -gnatwa -gnatwe -gnatg -g -O2 
> -Werror=implicit-function-declaration -ffile-prefix-map=/<>=. 
> -fstack-protector-strong -fstack-clash-protection -fcf-protection 
> -gno-record-gcc-switches -I. -I. -largs -Wl,-z,relro -Wl,-z,now 
> -Wl,--no-allow-shlib-undefined -Wl,--no-copy-dt-needed-entries 
> -Wl,--no-undefined -margs sockets-thin.ads  -fPIC -DPIC -o 
> .libs/sockets-thin.o
> 
> GNATMAKE 12.3.0
> Copyright (C) 1992-2022, Free Software Foundation, Inc.
> x86_64-linux-gnu-gcc-12 -c -g -O2 -Wall -Werror -gnatag -gnatwa -gnatwe 
> -gnatg -g -O2 -Werror=implicit-function-declaration 
> -ffile-prefix-map=/<>=. -fstack-protector-strong 
> -fstack-clash-protection -fcf-protection -gno-record-gcc-switches -

Bug#1066192: qm-dsp: FTBFS: hmm/hmm.c:703:15: error: implicit declaration of function ‘dgetrf_’ [-Werror=implicit-function-declaration]

[Lucas Nussbaum]

Source: qm-dsp
Version: 1.7.1-7.1
Severity: serious
Justification: FTBFS
Tags: trixie sid ftbfs
User: lu...@debian.org
Usertags: ftbfs-20240313 ftbfs-trixie ftbfs-impfuncdef

Hi,

During a rebuild of all packages in sid, your package failed to build
on amd64.

This is most likely caused by a change in dpkg 1.22.6, that enabled
-Werror=implicit-function-declaration. For more information, see
https://wiki.debian.org/qa.debian.org/FTBFS#A2024-03-13_-Werror.3Dimplicit-function-declaration

Relevant part (hopefully):
> cc -g -O2 -Werror=implicit-function-declaration 
> -ffile-prefix-map=/<>=. -fstack-protector-strong 
> -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection 
> -DNDEBUG -O3 -fPIC -ffast-math -ftree-vectorize -DUSE_PTHREADS  -I. 
> -Iext/kissfft -Iext/kissfft/tools -Dkiss_fft_scalar=double -Wdate-time 
> -D_FORTIFY_SOURCE=2  -c -o hmm/hmm.o hmm/hmm.c
> hmm/hmm.c: In function ‘invert’:
> hmm/hmm.c:703:15: error: implicit declaration of function ‘dgetrf_’ 
> [-Werror=implicit-function-declaration]
>   703 | ret = dgetrf_(, , a, , ipiv, );   /* ret should 
> be zero, negative if cov is singular */
>   |   ^~~
> hmm/hmm.c:730:9: error: implicit declaration of function ‘dgetri_’ 
> [-Werror=implicit-function-declaration]
>   730 | dgetri_(, a, , ipiv, , , );
>   | ^~~
> g++ -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong 
> -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection 
> -fPIC -Wall -g -O2 -Werror=implicit-function-declaration 
> -ffile-prefix-map=/<>=. -fstack-protector-strong 
> -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection 
> -DNDEBUG -O3 -fPIC -ffast-math -ftree-vectorize -DUSE_PTHREADS  -I. 
> -Iext/kissfft -Iext/kissfft/tools -Dkiss_fft_scalar=double -I. -Iext/kissfft 
> -Iext/kissfft/tools -Dkiss_fft_scalar=double -Wdate-time -D_FORTIFY_SOURCE=2  
> -c -o maths/Correlation.o maths/Correlation.cpp
> cc1plus: warning: ‘-Werror=’ argument ‘-Werror=implicit-function-declaration’ 
> is not valid for C++
> g++ -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong 
> -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection 
> -fPIC -Wall -g -O2 -Werror=implicit-function-declaration 
> -ffile-prefix-map=/<>=. -fstack-protector-strong 
> -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection 
> -DNDEBUG -O3 -fPIC -ffast-math -ftree-vectorize -DUSE_PTHREADS  -I. 
> -Iext/kissfft -Iext/kissfft/tools -Dkiss_fft_scalar=double -I. -Iext/kissfft 
> -Iext/kissfft/tools -Dkiss_fft_scalar=double -Wdate-time -D_FORTIFY_SOURCE=2  
> -c -o maths/CosineDistance.o maths/CosineDistance.cpp
> cc1plus: warning: ‘-Werror=’ argument ‘-Werror=implicit-function-declaration’ 
> is not valid for C++
> g++ -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong 
> -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection 
> -fPIC -Wall -g -O2 -Werror=implicit-function-declaration 
> -ffile-prefix-map=/<>=. -fstack-protector-strong 
> -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection 
> -DNDEBUG -O3 -fPIC -ffast-math -ftree-vectorize -DUSE_PTHREADS  -I. 
> -Iext/kissfft -Iext/kissfft/tools -Dkiss_fft_scalar=double -I. -Iext/kissfft 
> -Iext/kissfft/tools -Dkiss_fft_scalar=double -Wdate-time -D_FORTIFY_SOURCE=2  
> -c -o maths/KLDivergence.o maths/KLDivergence.cpp
> cc1plus: warning: ‘-Werror=’ argument ‘-Werror=implicit-function-declaration’ 
> is not valid for C++
> g++ -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong 
> -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection 
> -fPIC -Wall -g -O2 -Werror=implicit-function-declaration 
> -ffile-prefix-map=/<>=. -fstack-protector-strong 
> -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection 
> -DNDEBUG -O3 -fPIC -ffast-math -ftree-vectorize -DUSE_PTHREADS  -I. 
> -Iext/kissfft -Iext/kissfft/tools -Dkiss_fft_scalar=double -I. -Iext/kissfft 
> -Iext/kissfft/tools -Dkiss_fft_scalar=double -Wdate-time -D_FORTIFY_SOURCE=2  
> -c -o maths/MathUtilities.o maths/MathUtilities.cpp
> cc1plus: warning: ‘-Werror=’ argument ‘-Werror=implicit-function-declaration’ 
> is not valid for C++
> dsp/wavelet/Wavelet.cpp: In static member function ‘static void 
> Wavelet::createDecompositionFilters(Type, std::vector&, 
> std::vector&)’:
> dsp/wavelet/Wavelet.cpp:80:9: warning: variable ‘flength’ set but not used 
> [-Wunused-but-set-variable]
>80 | int flength = 0;
>   | ^~~
> cc -g -O2 -Werror=implicit-function-declaration 
> -ffile-prefix-map=/<>=. -fstack-protector-strong 
> -fstack-clash-protection -Wformat -Werror=format-security -fcf-p

Bug#1065831: document package specifiers for `upgrade`

[David Kalnischkies]

On Wed, Mar 13, 2024 at 09:44:02AM +0100, Miguel Angel Rojas wrote:
> > If "apt upgrade" is saying that it removes packages, that is a bug, yes.
> 
> @david: it is not a bug, apparently.

Yeah, but for different reasons. I know that exists & even use it
frequently… but its two different things for me as the modifiers are
from the user and as such always correct and intended while what upgrade
performs later on has restrictions applied (again from the user).
Having the same restrictions that upgrade has also apply for the
modifiers would make them less useful and in some sense be second
guessing the user as they asked for this to happen…

(modifiers btw is not a good word. I guess it was never documented so
 far partly as this is a rather advanced feature and mainly because
 naming things is hard)

So, I said "apt upgrade" meaning exactly that, not "apt upgrade foo-".
That could be interpreted in slightly different ways, but given how
our other commands behave it seems most sensible to interpret it as:
After the upgrade, foo is not installed, which if foo is currently
installed means remove it. More frequently it will mean through that
foo should not be part of the solution (as in, it is e.g. a non-pick
for resolving an or-dependency, so e.g. not installed as a NEW package).

An alternative interpretation could have been: Do upgrade all but foo,
but that can be achieved differently (e.g. foo/now) and would be
rather specific for upgrade, while behaving differently elsewhere.


And yes, "apt upgrade foo" can lead to bar being removed, which seems
surprising at first, but that depends on the foo. If its e.g. exim vs
postfix that is clear for the user based on what those packages
represent.
I just tried, "--no-remove" catches that, it also catches "foo-" through
which I am not super-happy about and I think we have a bug report for
open… but I could see that go either way and in any case that leads us
further away from the initial topic.


> In the meantime, while the documentation is modified, can some developer
> provide some explanation to the current "apt upgrade" behaviour? (*)
[…]
> (*) I'm a bit confused because I don't know which of the people involved in
> this bug are actually a developer of the apt package ;)

Well, does it really matter who is and who isn't?

I suppose we could have a borderline philosophical discussion about what
makes someone an APT developer given this is a muddily self-defined
non-delegated accumulation of people who for some reason feel some sort
of responsibility for and/or derive enjoyment from it; like most other
teams in Debian.

We could look at uploaders, changelog entries, commit history or access
right on e.g. salsa… but if either of those provide the full picture?


Anyway, I suppose for practical proposes you can think of Julian and me
as main APT developers in terms of who do the most and as such stir it
in recentish years.

If you are asking if that behaviour was added intentionally:
https://salsa.debian.org/apt-team/apt/-/commit/d8a8f9d7f01c75a7bbad7a488bf359a94291d1de

That said, you can be an APT developer, too: Propose the documentation
text you had hoped to find in the first place. Nobody is born an APT
developer, they are chosen based on their patch offerings… 


Best regards

David Kalnischkies


signature.asc
Description: PGP signature

Bug#1066190: mtree-netbsd FTBFS due to -Werror=implicit-function-declaration

[Helmut Grohne]

Source: mtree-netbsd
Version: 20180822-7
Severity: serious
Tags: ftbfs

As part of the time64 transition, -Werror=implicit-function-declaration
was enabled in default build flags. This makes mtree-netbsd fail to
build from source. A build ends with:

| gcc -DHAVE_CONFIG_H -Wdate-time -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE -DBSD4_4 
-Dst_mtimespec=st_mtim -I. -I. -g -O2 -Werror=implicit-function-declaration 
-ffile-prefix-map=/<>=. -fstack-protector-strong 
-fstack-clash-protection -Wformat -Werror=format-security -fcf-protection -c 
getid.c
| getid.c: In function ‘setup_getid’:
| getid.c:163:13: error: implicit declaration of function ‘pwcache_groupdb’ 
[-Werror=implicit-function-declaration]
|   163 | if (pwcache_groupdb(gi_setgroupent, gi_endgrent,
|   | ^~~
| getid.c:165:16: error: implicit declaration of function ‘pwcache_userdb’ 
[-Werror=implicit-function-declaration]
|   165 | || pwcache_userdb(gi_setpassent, gi_endpwent,
|   |^~
| cc1: some warnings being treated as errors
| make[1]: *** [Makefile:30: getid.o] Error 1
| make[1]: Leaving directory '/<>'
| dh_auto_build: error: make -j1 returned exit code 2
| make: *** [debian/rules:18: build] Error 255
| dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2

Helmut

Bug#1051237: transition: move files from / to /usr to finalize /usr-merge

[Helmut Grohne]

Hi,

On Sat, Mar 09, 2024 at 09:50:11PM +0100, Sebastian Ramacher wrote:
> > I'd now like to coordinate a time of upload. Given that chroots are
> > rebuilt in Wednesday and Sunday, I suggest we pick a Thursday morning
> > for the actual upload. If I unexpectedly break stuff, I still have a few
> > days to fix. How about March 21st?
> 
> If and only if time64_t is done by then. Adding more changes where
> transition has to be coordinated to the ongoing mega transition does not
> help.

Aurelien also said that glibc doesn't really build at this time.
Furthermore, cryptsetup needs to migrate to testing before the upload
and cryptsetup -> openssl -> dpkg is also entangled in time64.

I propose April 11th on the condition that all relevant packages
(including cryptsetup and e2fsprogs) have migrated. I'll also check with
Aurelien on feasibility after Easter.

Helmut

Bug#1066031: Your mail

[Kentaro HAYASHI]

Control: retitle -1 nmu: zeromq3

It seems that it should be nmu instead of gb because currently they are
"Installed" state.
As buildd given-back action says:

> Package in state Installed, cannot giveback. ✗

nmu zeromq3_4.3.5-1+b1 . ANY . unstable . -m "Rebuild to sync with
  64bit time_t runtime dependency."

Regards,

Bug#1031802: fuse3: inaccurate information in symbols file (was: Re: libvirt-daemon-driver-lxc: Incorrect dependencies)

[Simon McVittie]

On Sat, 18 Mar 2023 at 14:46:47 +0100, Andrea Bolognani wrote:
> In other words, upstream developers have retroactively added symbols
> (fuse_new_31) to existing symbol groups (FUSE_3.1).
...
> really this looks like an upstream
> bug in my opinion: even if the function was present in the source
> code all the way back in 3.1, it's only publicly exported starting
> with 3.13, and so exposing it as fuse_new_31@FUSE_3.13 would have
> been the correct way to go about it IMO.

I agree that this was incorrect, but now that several released libfuse
versions have had this bug, it is part of the ABI. In the absence of a
time machine, upstream cannot go back and correct it.

> I believe it should be possible to work around this in Debian by
> adding an entry like
> 
>   fuse_new_31@FUSE_3.1 3.13.0
> 
> to debian/libfuse3-3.symbols

Since we don't have a time machine, I think this would be the
correct answer to this bug. That would result in packages like
libvirt-daemon-driver-lxc generating correct dependencies next time they
are rebuilt.

On Wed, 13 Mar 2024 at 01:05:40 +0100, Bernd Schubert wrote:
> Would it help to move that symbol to FUSE_3.13 in the version script
> (for example in libfuse-3.17?)?

No, please don't do that: that would make the library as shipped by
Debian permanently incompatible with one built from upstream source.

smcv

Bug#1065779: libcdk5: FTBFS on arm{el,hf}: configure:7804:12: error: implicit declaration of function 'tgoto' [-Werror=implicit-function-declaration]

[Thomas Dickey]

On Wed, Mar 13, 2024 at 03:09:03PM +0500, Andrey Rakhmatullin wrote:
> On Sun, Mar 10, 2024 at 05:51:43AM -0400, Thomas Dickey wrote:
> > | configure:7811: gcc -c -g -O2 -Werror=implicit-function-declaration
> > | -ffile-prefix-map=/<>=. -fstack-protector-strong
> > | -fstack-clash-protection -Wformat -Werror=format-security -fPIE
> > | -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64 -Wdate-time
> > | -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE -D_DEFAULT_SOURCE conftest.c >&5
> > | configure: In function 'main':
> > | configure:7804:12: error: implicit declaration of function 'tgoto'
> > 
> > already fixed upstream,
> > over a year ago,
> > if someone chose to upgrade.
> > 
> > https://invisible-island.net/cdk/CHANGES.html#t20230201
> I tried to cherry-pick the changes, but "simply" diffing aclocal.m4 in the

that wouldn't go well, because it involved redesigning the checks

> last two upstream releases and removing hunks that only change the
> comments didn't produce a diff that can be applied directly to the older
> version in Debian so somebody needs to either indeed update to the latest
> version or make a usable diff.

upgrading really is the simplest solution - not much depends on this,
and nothing cares about the actual version:

libcdk5nc6
Reverse Depends:
  libcdk5-dev
  osmo-bsc-meas-utils
  cpm
  libcdk-perl
  gphoto2

-- 
Thomas E. Dickey 
https://invisible-island.net


signature.asc
Description: PGP signature

Bug#1066189: dict-vera,dict-wn,dictd: removing or purging packages fail related to restart limiting of dictd

[Jonas Smedegaard]

Package: dict-vera,dict-wn,dictd
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

When installing dict-vera, dict-wn and dictd, and removing or purging
then all in same apt batch execution fails like this:

Afinstallerer dict-gcide (0.48.5+nmu2) ...
Afinstallerer dict-jargon (4.4.7-3.1) ...
Afinstallerer dict-vera (1:1.24-1) ...
Job for dictd.service failed.
See "systemctl status dictd.service" and "journalctl -xeu dictd.service" for 
details.
invoke-rc.d: initscript dictd, action "restart" failed.
× dictd.service - LSB: Start and stop dictionary server daemon
 Loaded: loaded (/etc/init.d/dictd; generated)
 Active: failed (Result: start-limit-hit) since Wed 2024-03-13 11:38:16 
CET; 15ms ago
   Duration: 184ms
   Docs: man:systemd-sysv-generator(8)
Process: 61378 ExecStart=/etc/init.d/dictd start (code=exited, 
status=0/SUCCESS)
Process: 61432 ExecStop=/etc/init.d/dictd stop (code=exited, 
status=0/SUCCESS)
CPU: 53ms

mar 13 11:38:16 bastian systemd[1]: Starting dictd.service - LSB: Start and 
stop dictionary server daemon...
mar 13 11:38:16 bastian dictd[61378]: Starting dictionary server: dictd.
mar 13 11:38:16 bastian systemd[1]: Started dictd.service - LSB: Start and stop 
dictionary server daemon.
mar 13 11:38:16 bastian systemd[1]: Stopping dictd.service - LSB: Start and 
stop dictionary server daemon...
mar 13 11:38:16 bastian dictd[61432]: Stopping dictionary server: dictd.
mar 13 11:38:16 bastian systemd[1]: dictd.service: Deactivated successfully.
mar 13 11:38:16 bastian systemd[1]: Stopped dictd.service - LSB: Start and stop 
dictionary server daemon.
mar 13 11:38:16 bastian systemd[1]: dictd.service: Start request repeated too 
quickly.
mar 13 11:38:16 bastian systemd[1]: dictd.service: Failed with result 
'start-limit-hit'.
mar 13 11:38:16 bastian systemd[1]: Failed to start dictd.service - LSB: Start 
and stop dictionary server daemon.
Afinstallerer dict-wn (1:3.0-37) ...
Job for dictd.service failed.
See "systemctl status dictd.service" and "journalctl -xeu dictd.service" for 
details.
invoke-rc.d: initscript dictd, action "restart" failed.
× dictd.service - LSB: Start and stop dictionary server daemon
 Loaded: loaded (/etc/init.d/dictd; generated)
 Active: failed (Result: start-limit-hit) since Wed 2024-03-13 11:38:16 
CET; 229ms ago
   Duration: 184ms
   Docs: man:systemd-sysv-generator(8)
Process: 61378 ExecStart=/etc/init.d/dictd start (code=exited, 
status=0/SUCCESS)
Process: 61432 ExecStop=/etc/init.d/dictd stop (code=exited, 
status=0/SUCCESS)
CPU: 53ms

mar 13 11:38:16 bastian systemd[1]: Stopping dictd.service - LSB: Start and 
stop dictionary server daemon...
mar 13 11:38:16 bastian dictd[61432]: Stopping dictionary server: dictd.
mar 13 11:38:16 bastian systemd[1]: dictd.service: Deactivated successfully.
mar 13 11:38:16 bastian systemd[1]: Stopped dictd.service - LSB: Start and stop 
dictionary server daemon.
mar 13 11:38:16 bastian systemd[1]: dictd.service: Start request repeated too 
quickly.
mar 13 11:38:16 bastian systemd[1]: dictd.service: Failed with result 
'start-limit-hit'.
mar 13 11:38:16 bastian systemd[1]: Failed to start dictd.service - LSB: Start 
and stop dictionary server daemon.
mar 13 11:38:17 bastian systemd[1]: dictd.service: Start request repeated too 
quickly.
mar 13 11:38:17 bastian systemd[1]: dictd.service: Failed with result 
'start-limit-hit'.
mar 13 11:38:17 bastian systemd[1]: Failed to start dictd.service - LSB: Start 
and stop dictionary server daemon.
dpkg: fejl under behandling af pakken dict-wn (--remove):
 installed dict-wn package post-removal script subprocess returned error exit 
status 1


 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmXxhnwACgkQLHwxRsGg
ASEsEw/9HfGT6JBKOefKZvdnLXyo0GWHQH4ggQWAYUtG/rlwz/Rnxx4hm6jfcx1g
4ikwVLSqh0m6IT0ZWrrdp/S/Btgpq7zllHJuRyy0v6Ud1Y9Pfg0W6rg8HvylyqKf
pPxgH6a5ZvcLCYKfTNxY0UlTvkoyufy5MzT6Hf/QPaUkIPYlxappaGr3i/hRCqiL
ONr9hPRTXiVKNcj5mmrn71jdx5ykonhD5f07138WYmD8Cj0rEOHry8YeUVEATU6q
pSRYr5NwyGhDsNXt+8QLLbYar6WjiPq4EooA0xE8t4TggFb/+ZzlfvYGKl/1CiIh
RdUdv3if6pswxsm7obdnD2RPXRZ21cJP8zk3Vh8AKL7IIJW+cQ+3D7PAqyxnaLVi
XdSQj5ZwDtJzxtAbQP1YZXLGlFCmxqxDi8L5EQSydm/xY4n4kHliLlDFKi/DQNCf
vOO3G3gj0pM+Rx/E93vZcswskHaMSOusYB4Vg3grAZzUYMM8G2mPRchEL/jKBTFb
iyvch/ZIg3HQvGOXRFxl1s423rdGIY+B7Xe5zJYtHFffV2/VSUv18UbjFHqNszUN
xxof0/e2cH2PY0Y3LhjEvAcfoVZGmeM948/iKCtmXe0tIrtBQMYJ4Yrj5oisE7Cz
45MWegfFYafCtO5qNuoeb2yYm87K/ZXs71Oslvm0lfWwXRTdcwk=
=KuAH
-END PGP SIGNATURE-

Bug#1066090: psmisc: killall --older-than doesn't work as documented in a container

[Craig Small]

Control: tag 1066090 fixed-upstream

On Wed, 13 Mar 2024 at 00:30, Tim Connors  wrote:

> I'm guessing it's looking at field 22 starttime in /proc/$pid/stat?
> starttime is seconds since boot.  Since the process exists in the
> parent system as well, starttime will surely be seconds since host
> boot?  But /proc/uptime is seconds since container boot.
>
/proc/uptime is sometimes seconds since host boot and sometimes seconds
since container boot.

Generally docker is the former, LXC is the latter but it's not consistent.
You can tell because if you run the uptime command
you'll see the difference. LXC basically overrides the uptime file with a
fuse-mounted file.You'd probably see there
is an issue with things like "ps -o etimes" as well which is where this
first was noticed.

There is already an upstream fix for this[1] in procps which uses
clock_gettime() instead so the start times are correct.
killall would be impacted by the same issue.
 - Craig

1:
https://gitlab.com/procps-ng/procps/-/commit/b5e19c1730bcc68d553f44b5585704e3c92267bf#83c45d853acc8384452b404946e4a0c484b16a4e_1519_1515

Bug#1065787: 64-bit time_t transition: cargo needs manual intervention

[Simon McVittie]

On Tue, 12 Mar 2024 at 23:13:30 -0500, Steven Robbins wrote:
> I checked the build logs for cargo and noticed that most architectures have 
> been built on the buildds.  All release arches except armel & armhf.  How is 
> it that these two have build dep installability problems but others do not?

Those two are the only release architectures where the 64-bit time_t
transition has caused an ABI break:

1. amd64, arm64, mips64el, ppc64el, riscv64, s390x are all 64-bit, so they
   already had 64-bit time_t
  - non-release architectures in the same category:
alpha hurd-amd64 ia64 loong64 ppc64 sparc64

2. i386 is 32-bit but has been excluded from the 64-bit time_t transition
   because its major purpose this decade is running legacy 32-bit binaries,
   a purpose that would no longer be possible if it broke ABI
   - non-release architectures in the same category: hurd-i386 (I think)

3. There is currently no release architecture that is 32-bit but already had
   a 64-bit time_t prior to 2024
   - non-release architectures in this category: x32

4. armel, armhf are the two remaining 32-bit release architectures after
   excluding all of the above
   - non-release architectures in the same category:
 hppa m68k powerpc sh4

I hope that helps to categorise the architectures that do/don't have a
problem here.

For architectures in categories 1, 2 and 3 above, libfoo0 is still renamed
to libfoo0t64, but libfoo0t64 Provides: libfoo0, making it significantly
easier to satisfy build-dependencies. The last category is the only one
where there has genuinely been a compatibility break and therefore this
Provides would be wrong, so it is also the category where some packages
need re-bootstrapping.

smcv

Bug#1062968: initramfs-tools-core: Use zstdmt instead of zstd by default

[Benjamin Drung]

On Sun, 04 Feb 2024 09:15:42 +0100 Tollef Fog Heen 
wrote:
> Package: initramfs-tools-core
> Version: 0.142
> Severity: wishlist
> 
> It would be nice if initramfs-tools-core used zstdmt (multi-threaded)
> instead of plain zstd when creating the initramfs.  On my system, that
> saves about 15% of the time spent building the initramfs.
> 
> The following change seems sufficient:
> 
> --- /usr/sbin/mkinitramfs~2022-07-12 23:51:34.0 +0200
> +++ /usr/sbin/mkinitramfs 2024-02-04 09:09:07.614462279 +0100
> @@ -227,7 +227,7 @@
>   fi
>   ;;
>  lz4) compress="lz4 ${compresslevel} -l" ;;
> -zstd)compress="zstd -q ${compresslevel}"
> +zstd)compress="zstdmt -q ${compresslevel}"
>   # If we're not doing a reproducible build, enable multithreading
>   test -z "${SOURCE_DATE_EPOCH}" && compress="$compress -T0"
>   ;;

The man page of zstdmt says that is equivalent to "zstd -T0". As you can
see from the code, -T0 is added in case not doing a reproducible build.
So this change should have no performance impact. A test on a Raspberry
Pi Zero 2 did not reveal any performance difference.

-- 
Benjamin Drung
Debian & Ubuntu Developer

Bug#1066188: ITP: golang-github-schollz-pake -- Generate a strong secret over an insecure channel

[Guilherme Puida Moreira]

Package: wnpp
Severity: wishlist
Owner: Guilherme Puida Moreira 

* Package name: golang-github-schollz-pake
  Version : 3.0.5-1
  Upstream Author : Zack
* URL : https://github.com/schollz/pake
* License : Expat
  Programming Lang: Go
  Description : Generate a strong secret over an insecure channel

 Password-authenticated key exchange (PAKE) allows two parties to generate a
 mutual secret key by using a weak key that is known to both beforehand (e.g
 via some other channel of communication).
 .
 This library exposes a simple API for an implementation of PAKE.

This is a dependency of croc, which I'm also working on packaging.

Bug#1063380: ITP: libuio -- Linux Kernel UserspaceIO helper library

[Traut Manuel LCPF-CH]

> On Thu, Mar 07, 2024 at 05:02:29PM +0200, Peter Pentchev wrote:
>> On Thu, Mar 07, 2024 at 03:25:01PM +0100, Manuel Traut wrote:
>>> On 7 Feb 2024, at 18:27, Dima Kogan  wrote:
>>>
>>> Hi. Thanks for your contribution. I looked at the upstream code a tiny
>>> bit, and it looks like it might have portability bug, at least on
>>> big-endian architectures. For instance:
>>>
>>> https://github.com/missinglinkelectronics/libuio/blob/6ef3d8d096a641686bfdd112035aa04aa16fe81a/irq.c#L78
>>>
>>> This assumes that sizeof(long)==4. Maybe this is benign, but it would be
>>> nice to fix. Are you upstream or do you know upstream? Can yall fix
>>> these?
>>>
>> The kernel expects a 4 byte write here, since unsigned long is defined as at 
>> least 32 bit this shall work on all architectures.
>>
>> If your concern is about endianess this is not in the current scope of 
>> libuio and needs to be addressed by a higher layer.
>>
>> I am very familiar with library and in close contact with upstream.
>>
> In the case of uio_disable_irq() the bug is nicely hidden by the fact
> that tmp is guaranteed to be all-zeroes. However, consider the previous
> function in the file, uio_enable_irq(). If sizeof(unsigned long) == 8,
> then the "tmp" variable's value of 1 will be encoded in memory as
> 8 bytes containing the values 0, 0, 0, 0, 0, 0, 0, and 1 respectively.
> When uio_enable_irq() calls write(..., , 4), it will only send
> the first four bytes to the kernel - and they are 0, 0, 0, and... 0.
> So it turns out that uio_disable_irq() and uio_enable_irq() do
> exactly the same - send a 32-bit zero value to the kernel.
>
> ...of course, this will only happen on a big-endian system, as
> Dima Kogan was concerned about. On a little-endian system, this
> will work by chance.
>
> Is this the expected behavior indeed?

No it is not :) Thanks for the detailed explanation.

Looks this fix sane to you?
https://github.com/manut/libuio/commit/1edcf262fbfaf0b7f8519875ed5b357964dd1e55

I am not sure if users also expect an automatic conversion for the read/write 
functions:
https://github.com/manut/libuio/commit/d0319169359bffc73374f1011e942702e9bafb1e

It will be somehow inconsistent since a user could also access the device 
memory by pointer:
https://github.com/manut/libuio/blob/add-ci/mem.c#L93
and than needs to take care on the endianess by its own anyway.

Bug#1066187: lacks dependency on libblaspp-dev

[Pierre Gruet]

Package: liblapackpp-dev
Version: 2023.11.05-1
Severity: normal

Dear Maintainer,

liblapackpp-dev lacks a dependency on libblaspp-dev.

The latter is needed as
/usr/lib//cmake/lapackpp/lapackConfig.cmake
has a ``find_dependency(blaspp)'' command.

Cheers,

-- 
Pierre


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

Kernel: Linux 6.6.15-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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#1054822: opam: FTBFS: sed: can't read opam.install: No such file or directory

[zhangdandan]

Hi,

On Fri, 27 Oct 2023 21:42:50 +0200 Lucas Nussbaum wrote:

> Source: opam
> Version: 2.1.5-1
> Severity: serious
> Justification: FTBFS
> Tags: trixie sid ftbfs
> User: lu...@debian.org
> Usertags: ftbfs-20231027 ftbfs-trixie
>
> Hi,
>
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
>
> Actual targets:
> - _build/default/opam-installer.install
> - _build/default/opam.install
> Running[1]: (cd _build/default/src/client && /bin/sh -c 'git describe 
--exact HEAD || echo [dev]') > _build/default/src/client/git-describe 2> 
/dev/null
> Running[2]: (cd _build/default/src/client && /bin/sh -c 'git 
rev-parse --quiet --verify HEAD || echo .') > 
_build/default/src/client/git-sha 2> /dev/null

> sed -f process.sed opam.install > processed-opam.install
> sed: can't read opam.install: No such file or directory
> make[2]: *** [Makefile:166: processed-opam.install] Error 2

Compiling the opam failed for loong64 in the Debian Package 
Auto-Building environment.
In fact, there are compilation errors in riscv64, m68k, powerpc and 
other architectures.
If you compile opam again on amd64 and arm64 (compiled 190 days ago), 
there will be the same error.

The error log as the above report.

After analyzing, I can explain the reason for the compilation error by 
the following code,

```
From opam-2.1.5/Makefile

DUNE_PROMOTE_ARG =
DUNE_PROMOTE_ARG += --promote-install-files

ifeq ($(DUNE),)
  DUNE_EXE = src_ext/dune-local/dune.exe
  ifeq ($(shell command -v cygpath 2>/dev/null),)
    DUNE := $(DUNE_EXE)
  else
    DUNE := $(shell echo "$(DUNE_EXE)" | cygpath -f - -a)
  endif
else
  DUNE_EXE=
  # NB make does not export the PATH update in Makefile.config to 
$(shell ...)
  ifeq ($(shell PATH='$(PATH)' $(DUNE) build --root . --help=plain 
2>/dev/null \

  | grep -F -- '$(DUNE_PROMOTE_ARG) '),)  //Note that ti
    $(info DD-Pre-Var=$(DUNE_PROMOTE_ARG))
    //printf "--promote-install-files"
    DUNE_PROMOTE_ARG =
    $(info DD-After-Var=$(DUNE_PROMOTE_ARG))
    //printf " "
  endif
endif
```
- Case 1: "DUNE_PROMOTE_ARG = --promote-install-files"
The opam compiles fine in my local rootfs.
- Case 2: "DUNE_PROMOTE_ARG = "
Compiling opam fails with the same phenomenon as Debian Package 
Auto-Building.


Maybe the following error is related to the value of the parameter 
DUNE_PROMOTE_ARG in the Makefile file.

```
sed -f process.sed opam.install > processed-opam.install
sed: can't read opam.install: No such file or directory
make[2]: *** [Makefile:166: processed-opam.install] Error 2
```

BTW, the opam's build dependency is ocaml-dune.
Before 190 days, amd64 compiled opam fine, and the version of ocaml-dune 
is ocaml-dune (3.10.0-2).
Now, compiling opam fails, and the version of ocaml-dune is ocaml-dune 
(3.11.1-1).


Hopefully the above information will provide some help to maintainers.

Thanks,
Dandan Zhang

Bug#1051202: docker.io: Please upgrade to upstream version 24 or later

[Jonathan Dowland]

On Mon, Sep 04, 2023 at 07:28:06AM -0400, Reinhard Tartler wrote:
> I'll try to patch podman to use the older API, but it seems to me the
> docker.io package in debian is lagging several upstream releases behind
> anyways.
> 
> any plans to upgrade it soon?

Echoing Reinhard here. Lots of external tooling I work with has now
moved their minimum API versions on past the ceiling value supported
by the docker.io package (e.g. [1]).  We seem to be three versions
behind (23,42,25) and tracker.d.o notes that 26.0.0~rc2 is tagged, so
it's likely 26 is just around the corner.


Thank you!


[1] https://github.com/openshift/source-to-image/issues/1135

Bug#1066139: podman: Cannot create a network with dns_enabled

[Faidon Liambotis]

Control: tags -1 + moreinfo

On Wed, Mar 13, 2024 at 12:17:12AM +0100, Antoine Sirinelli wrote:
> When I create a new custom network, the dns is not enabled:
> 
> $ podman network create test
> test
> $ podman network inspect test
>
> [...]
> 
> The outcome should have "dns_enabled" to true.

Per podman-network(1):
> Podman supports two network backends Netavark and CNI. Netavark is the
> default network backend and was added in Podman version 4.0. CNI  is
> deprecated and will be removed in the next major Podman version 5.0,
> in preference of Netavark.

For DNS, you need to have installed:
  - golang-github-containernetworking-plugin-dnsname (CNI, deprecated)
  - aardvark-dns (Netavark)

podman Depends on golang-github-containers-common which Recommends
netavark, which Recommends aardvark-dns, so a clean install brings in
Netavark by default (per upstream).

I've verified that clean installs, with the exact commands you executed,
with either Netavark (default install), or without Netavark but with
golang-github-containernetworking-plugin-dnsname, and could not
reproduce the issue.

So I would guess that you don't have either of those packages installed.

The question is why.

1) Perhaps you installed podman with apt install --no-install-recommends?

   In this case, I don't think this is a bug. Recommends is the
   appropriate package relationship here, and failure to install all the
   recommended dependencies can result in reduced, non-essential
   functionality.

2) Alternatively, perhaps you first set up podman without Netavark (e.g.
   before 4.0), and later upgraded to a newer version?

   (In this case, I wonder how the setup ended up without the "dnsname"
   plugin. But moot at this point regardless)

   I don't think an automatic transition from the old stack to the new
   stack exists. A "podman system reset" should fix it; I'm not sure if
   there is a less intrusive way to do that. Perhaps we'll know more
   about upgrade paths with the 5.0 release, which is imminent.

3) Some other reason that I can't imagine right now :)

Would love to hear from you and some insight on how your setup ended up
in the way it did. Perhaps we could figure out ways to avoid any further
surprises.

Best,
Faidon

Bug#1065779: libcdk5: FTBFS on arm{el,hf}: configure:7804:12: error: implicit declaration of function 'tgoto' [-Werror=implicit-function-declaration]

[Andrey Rakhmatullin]

On Sun, Mar 10, 2024 at 05:51:43AM -0400, Thomas Dickey wrote:
> | configure:7811: gcc -c -g -O2 -Werror=implicit-function-declaration
> | -ffile-prefix-map=/<>=. -fstack-protector-strong
> | -fstack-clash-protection -Wformat -Werror=format-security -fPIE
> | -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64 -Wdate-time
> | -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE -D_DEFAULT_SOURCE conftest.c >&5
> | configure: In function 'main':
> | configure:7804:12: error: implicit declaration of function 'tgoto'
> 
> already fixed upstream,
> over a year ago,
> if someone chose to upgrade.
> 
> https://invisible-island.net/cdk/CHANGES.html#t20230201
I tried to cherry-pick the changes, but "simply" diffing aclocal.m4 in the
last two upstream releases and removing hunks that only change the
comments didn't produce a diff that can be applied directly to the older
version in Debian so somebody needs to either indeed update to the latest
version or make a usable diff.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#1066121: ionos 5/6/15/16 loosing network

[Holger Levsen]

[22:39] * | h01ger filed a bug about 5/6/15/16 loosing network now
[22:40] * | mapreri ponders the accuracy: the link was still up, so perhaps it 
only lost the IP somehow?
[22:40]  next time I will look up the dhcp lease if there is anything 
odd
[22:40]  mapreri: that pondering could be the right direction..
[11:03]  mapreri: and ionos5+15 are gone again..


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

"Any fool can know. The point is to understand." - A. Einstein 


signature.asc
Description: PGP signature

Bug#1066007: qm-dsp: FTBFS on arm{el,hf}: hmm/hmm.c:703:15: error: implicit declaration of function ‘dgetrf_’ [-Werror=implicit-function-declaration]

[Andrey Rakhmatullin]

On Sun, Mar 10, 2024 at 11:19:48PM +0100, Sebastian Ramacher wrote:
> hmm/hmm.c: In function ‘invert’:
> hmm/hmm.c:703:15: error: implicit declaration of function ‘dgetrf_’ 
> [-Werror=implicit-function-declaration]
>   703 | ret = dgetrf_(, , a, , ipiv, );   /* ret should 
> be zero, negative if cov is singular */
>   |   ^~~
> hmm/hmm.c:730:9: error: implicit declaration of function ‘dgetri_’ 
> [-Werror=implicit-function-declaration]
>   730 | dgetri_(, a, , ipiv, , , );
>   | ^~~
These functions are declared in include/clapack.h, but a recent Debian
patch removes #include  from hmm/hmm.c.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#1065792: libspf2: FTBFS on arm{el,hf}: spf_utils.c:207:9: error: implicit declaration of function ‘memset’ [-Werror=implicit-function-declaration]

[Andrey Rakhmatullin]

On Sat, Mar 09, 2024 at 10:42:33PM +0100, Sebastian Ramacher wrote:
> /bin/bash ../../libtool  --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. 
> -I../.. -I../../src/include -I../../src  -D_LARGEFILE_SOURCE 
> -D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64 -Wdate-time -D_FORTIFY_SOURCE=2  -g 
> -O2 -Werror=implicit-function-declaration 
> -ffile-prefix-map=/<>=. -fstack-protector-strong 
> -fstack-clash-protection -Wformat -Werror=format-security -Wall -MT 
> spf_utils.lo -MD -MP -MF .deps/spf_utils.Tpo -c -o spf_utils.lo spf_utils.c
> libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../.. -I../../src/include 
> -I../../src -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64 
> -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 -Werror=implicit-function-declaration 
> -ffile-prefix-map=/<>=. -fstack-protector-strong 
> -fstack-clash-protection -Wformat -Werror=format-security -Wall -MT 
> spf_utils.lo -MD -MP -MF .deps/spf_utils.Tpo -c spf_utils.c  -fPIC -DPIC -o 
> .libs/spf_utils.o
> spf_utils.c: In function ‘SPF_recalloc’:
> spf_utils.c:207:9: error: implicit declaration of function ‘memset’ 
> [-Werror=implicit-function-declaration]
>   207 | memset(*bufp, '\0', *buflenp);
>   | ^~
> spf_utils.c:32:1: note: include ‘’ or provide a declaration of 
> ‘memset’
>31 | #include "spf_internal.h"
>   +++ |+#include 
>32 | 
> spf_utils.c:207:9: warning: incompatible implicit declaration of built-in 
> function ‘memset’ [-Wbuiltin-declaration-mismatch]
>   207 | memset(*bufp, '\0', *buflenp);
>   | ^~
> spf_utils.c:207:9: note: include ‘’ or provide a declaration of 
> ‘memset’
I've checked the package and while the file already has #include
 it has it under #ifdef HAVE_MEMORY_H, and configure doesn't
seem to set that define in config.h. So it may be a question of
modernizing (they are from 2012) or fixing the autotools files.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#1065778: libcdio: FTBFS on arm{el,hf}: _cdio_stdio.c:53:20: error: implicit declaration of function ‘fseeko64’; did you mean ‘fseeko’? [-Werror=implicit-function-declaration]

[Andrey Rakhmatullin]

On Sat, Mar 09, 2024 at 09:54:29PM +0100, Sebastian Ramacher wrote:
> libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../.. -I../../lib/driver 
> -I../../include -I../../include/ -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 
> -D_TIME_BITS=64 -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 
> -Werror=implicit-function-declaration -ffile-prefix-map=/<>=. 
> -fstack-protector-strong -fstack-clash-protection -Wformat 
> -Werror=format-security -Wall -Wbad-function-cast -Wcast-align 
> -Wchar-subscripts -Wdeclaration-after-statement -Wdisabled-optimization 
> -Wendif-labels -Winline -Wmissing-declarations -Wmissing-prototypes 
> -Wnested-externs -Wno-sign-compare -Wpointer-arith -Wshadow 
> -Wstrict-prototypes -Wundef -Wunused -Wwrite-strings -c cdio.c  -fPIC -DPIC 
> -o .libs/cdio.o
> _cdio_stdio.c: In function ‘_stdio_seek’:
> _cdio_stdio.c:53:20: error: implicit declaration of function ‘fseeko64’; did 
> you mean ‘fseeko’? [-Werror=implicit-function-declaration]
>53 | #define CDIO_FSEEK fseeko64
For the record, this failure doesn't happen on amd64.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#1066186: setup mastadon2irc bot

[Holger Levsen]

package: jenkins.debian.org

not strictly a jenkins.d.o topic, but it would be nice to have mastadon
mentions on #reproducible-builds again in that channel.

https://github.com/hackspace-marburg/troet

is a Mastodon plugin for Sopel IRC bots, sopel is available in Debian.


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

If it feels like we’re breaking climate records every year, it’s because we are.


signature.asc
Description: PGP signature

Bug#990451: (no subject)

[David Kalnischkies]

On Wed, Mar 13, 2024 at 12:35:14AM -0700, Chandler Sobel-Sorenson wrote:
> I concur and also request `--no-all-versions` apply to `apt-cache
> policy` command as well.

What would this achieve; what is the use case?

I literally see no point in having 'policy' limited to a single version
(and which one?) given its usually used to show which versions are
available from where, how the pin values are for those and which one is
considered the candidate as a result of that.


> Perhaps, instead, a new option with argument `--versions=N` could be
> implemented, allowing a limited number of versions to be returned, with
> `--versions=0` or `--versions=none` being the equivalent of
> `--no-all-versions`.

Uhm… beside that the --no-all-versions flag switches the display from
"display all versions" to "display the candidate version only" in e.g.
'show' (and one or the other is the default in apt-cache vs. apt), so
the equivalent would be more like '1' … and '0' would display nothing?

How would --versions=3 behave through: Assuming I have 5 different
versions available in the sources, which of these are displayed and
which are not… regardless of the choice, this seems rather unintuitive
to discover without many paragraphs of documentation that basically
duplicates the code in prose text.

Again, what would this achieve and what is the use case for this?


Sidenote: If a specific task has no people interested in working on
it, its not a good idea to add additional tasks as that is the moral
equivalent of saying: "Nobody bought it for 5€, lets ask for 20€"¹.
Either create a compelling new task referencing related ones or much
better yet do work on it yourself. Its open source after all and nothing
will ever get done if everyone hopes someone else will do it.


Best regards

David Kalnischkies

¹ well, I suppose for e.g. life style products that might work, but
  somehow I doubt we can "sell" requests as a life style product…


signature.asc
Description: PGP signature

Bug#1034771: generate_firmware_patterns failed: 512 at ./tmp/debian-cd/tools/make_disc_trees.pl line 1257

[Vincas Dargis]

> This is because reprepro does not generate or support these
> dep11/Components-*.ym.gz files...

My workaround was to download Components files:

${YOUR_MIRROR}/dists/bookworm/main/dep11/Components-amd64.yml.gz

and

${YOUR_MIRROR}/dists/bookworm/non-free-firmware/dep11/Components-amd64.yml.gz

Also setting environment variables:

> env FORCE_FIRMWARE=1 NONFREE_COMPONENTS='non-free non-free-firmware' 
> build-simple-cdd --dvd --dist bookworm --profiles myprofile

Bug#1066185: pekwm: New upstream version available: 0.3.0

[Andrew Chadwick]

Package: pekwm
Version: 0.1.18-1
Severity: wishlist
X-Debbugs-Cc: a.t.chadw...@gmail.com

Dear Maintainer,

A new version of pekwm, 0.30.0, has been available from upstream since Jan 
2023. I understand that it comes with a bunch of desktop-focused utilities 
now. Please can you consider updating the version in Debian, when 
convenient, for the next stable release?

https://github.com/pekwm/pekwm/releases/tag/release-0.3.0
https://pekdon.pekwm.se/posts/pekwm_release_history/


many thanks,
Andrew

Bug#1065831: document package specifiers for `upgrade`

[Miguel Angel Rojas]

Hi there,

> If "apt upgrade" is saying that it removes packages, that is a bug, yes.

@david: it is not a bug, apparently.

To put everything in a nutshell:

   - "apt upgrade" can remove packages
   - "apt upgrade" accepts specific packages to be upgraded

Therefore, this behaviour is expected and documentation needs to be
modified.

In the meantime, while the documentation is modified, can some developer
provide some explanation to the current "apt upgrade" behaviour? (*)

Thanks

(*) I'm a bit confused because I don't know which of the people involved in
this bug are actually a developer of the apt package ;)

Bug#904233: Adoption of persp-projectile

[Xiyue Deng]

Control: tags -1 pending

Sean Whitton  writes:

> Hello,
>
> On Tue 12 Mar 2024 at 08:47pm -07, Xiyue Deng wrote:
>
>> Sean Whitton  writes:
>>
>>> Hello Xiyue,
>>>
>>> Do you still intend to adopt persp-projectile?
>>>
>>> Thanks.
>>
>> Yes.  And it seems I forgot to close this ITA bug in the Changelog.  Can
>> we close this directly instead?
>
> We could, but I don't think you actually adopted it :)

Ah indeed.  I've pushed a few more commits with one that adds myself as
an uploader.  So tagging this bug pending and waiting for the next upload.

-- 
Xiyue Deng

Bug#1066184: ITP: networking-generic-switch -- OpenStack virtual network service - networking-generic-switch

[Thomas Goirand]

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: networking-generic-switch
  Version : 7.2.0
  Upstream Contact: OpenStack Foundation 
* URL : https://github.com/openstack/networking-generic-switch
* License : Apache-2.0
  Programming Lang: Python
  Description : OpenStack virtual network service - 
networking-generic-switch

 Neutron provides an API to dynamically request and configure virtual networks.
 These networks connect "interfaces" from other OpenStack services (such as
 vNICs from Nova VMs). The Neutron API supports extensions to provide advanced
 network capabilities, including QoS, ACLs, and network monitoring.
 .
 This package provides the networking-generic-switch ML2 plugin.

Bug#1066134: FTBFS due -Werror=implicit-function-declaration

[Christoph Biedl]

Christoph Biedl wrote...

> So, assuming this is the cause here, the fix is pretty simple:
(...)
> +#ifdef INET6
>  if (if6_is_up)
> sif6down(0);
> +#endif

This was silently done as part of

commit 80b8744eb42c7493794f3e3fe0bf1ce14f53e6dd
Author: Eivind Næss 
Date:   Fri Aug 6 09:14:02 2021 -0700

Changing INET6 to PPP_WITH_IPV6CP and adding configure option

http://git.ozlabs.org/?p=ppp.git;a=blobdiff;f=pppd/sys-linux.c;h=94e5a19ed4c67cc44f97b2257c3b0d57b4ed15a0;hp=0ffc4277b2aa4b661fae8faac27ca450596f6599;hb=80b8744;hpb=a6622771e2dc03a2682c86c4bcf6bf6ae9e85df7

Christoph



signature.asc
Description: PGP signature

Bug#1065435: aptitude: FTBFS on armhf and armel (probably -Werror=implicit-function-declaration related)

[Steinar H. Gunderson]

On Mon, Mar 04, 2024 at 07:34:06PM +0100, Sven Joachim wrote:
> Not really, these arches now default to a 64-bit time_t and therefore
> you get the conflicting types (suseconds_t is a long int,
> __suseconds64_t a long long int).  This has nothing to do with implicit
> function declarations.

It's a bit crazy that tv_usec changes type, it should be in [0,100)
no matter what tv_sec is:

struct timeval
{
#ifdef __USE_TIME_BITS64
  __time64_t tv_sec;/* Seconds.  */
  __suseconds64_t tv_usec;  /* Microseconds.  */
#else 
  __time_t tv_sec;  /* Seconds.  */
  __suseconds_t tv_usec;/* Microseconds.  */
#endif
};
#endif

But the fix is straightforward, no? Just change the offending test to something 
like

  CPPUNIT_ASSERT_EQUAL(static_cast(99), c.tv_usec);

and it should work no matter what type c.tv_usec is. Or, if you prefer
brace-initialization (which would prevent you from ever writing in a too-big
value, like 999 or something):

  CPPUNIT_ASSERT_EQUAL(decltype(c.tv_usec){99}, c.tv_usec);

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#1066137: [pkg-gnupg-maint] Bug#1066137: gnupg2: -Werror=implicit-function-declaration failure testing for ldap_open

[Sune Stolborg Vuorela]

On Tuesday, March 12, 2024 11:56:48 PM CET Thorsten Glaser wrote:
> Source: gnupg2
> Version: 2.2.40-1.1
> Severity: serious
> Justification: ftbfs
> X-Debbugs-Cc: t...@mirbsd.de
> 
> Trying to binNMU gnupg2 to make it installable during t64 transition,
> I notice the following configury output:

apparantly since some version, ldap_open prototype is put behind 
#if LDAP_DEPRECATED

Given the only reference to ldap_open is in the configure script, I guess a 
quickfix could be to just define that in the m4 scripts / configure scripts as 
a 
minimal change.

> 
> | /* end confdefs.h.  */
> | 
> | #ifdef _WIN32
> | #include 
> | #include 
> | #else
#if LDAP_DEPRECATED

> | #include 
> | #endif
> | 
> | int
> | main (void)
> | {
> | ldap_open("foobar",1234);
> | 
> |   ;
> |   return 0;
> | 
> | }
> 
> configure:11608: result: no
> 
> 
> Prototypes are now mandatory, both for C23 and because the t64 transition
> can only work if prototypes are properly used.

I'm a bit surprised the way ldap has decided to deprecate functions, but I 
guess users needs to work with it.

/Sune
-- 
I didn’t stop pretending when I became an adult, it’s just that when I was a 
kid I was pretending that I fit into the rules and structures of this world. 
And now that I’m an adult, I pretend that those rules and structures exist.
   - zefrank

Bug#990451: (no subject)

[Chandler Sobel-Sorenson]

I concur and also request `--no-all-versions` apply to `apt-cache
policy` command as well.

Perhaps, instead, a new option with argument `--versions=N` could be
implemented, allowing a limited number of versions to be returned, with
`--versions=0` or `--versions=none` being the equivalent of
`--no-all-versions`.

Bug#1065973: kmod: FTBFS due to time64 transition

[Helge Deller]

The patch below builds for me on the hppa platform.
Testcases needs verifying on physical hardware though.

Helge


diff -up ./testsuite/path.c.org ./testsuite/path.c
--- ./testsuite/path.c.org  2024-03-13 07:01:04.610222544 +
+++ ./testsuite/path.c  2024-03-13 07:11:16.630339502 +
@@ -15,9 +15,14 @@
  * License along with this library; if not, see .
  */
 
+#if !defined(_TIME_BITS) || _TIME_BITS != 64
+#define NEED_WRAPPER
 /* We unset _FILE_OFFSET_BITS here so we can override both stat and stat64 on
  * 32-bit architectures and forward each to the right libc function */
 #undef _FILE_OFFSET_BITS
+#else
+#undef NEED_WRAPPER
+#endif
 
 #include 
 #include 
@@ -191,6 +196,7 @@ TS_EXPORT int prefix ## stat ## suffix (
return _fn(ver, p, st); \
 }
 
+#ifdef NEED_WRAPPER
 WRAP_1ARG(DIR*, NULL, opendir);
 WRAP_1ARG(int, -1, chdir);
 
@@ -212,3 +218,4 @@ WRAP_VERSTAT(__lx,);
 WRAP_VERSTAT(__x,64);
 WRAP_VERSTAT(__lx,64);
 #endif
+#endif
diff -up ./tools/depmod.c.org ./tools/depmod.c
--- ./tools/depmod.c.org2024-03-13 06:56:13.616085242 +
+++ ./tools/depmod.c2024-03-13 07:13:11.417610532 +
@@ -2613,8 +2613,8 @@ static int depmod_output(struct depmod *
int mode = 0644;
int fd;
 
-   snprintf(tmp, sizeof(tmp), "%s.%i.%li.%li", itr->name, 
getpid(),
-   tv.tv_usec, tv.tv_sec);
+   snprintf(tmp, sizeof(tmp), "%s.%i.%lli.%lli", 
itr->name, getpid(),
+   (long long)tv.tv_usec, (long 
long)tv.tv_sec);
fd = openat(dfd, tmp, flags, mode);
if (fd < 0) {
ERR("openat(%s, %s, %o, %o): %m\n",

Bug#1065742: dh_install: cannot use empty lines or comments in substitution

[Niels Thykier]

Control: tags -1 wontfix

Andreas Metzler:

On 2024-03-10 Niels Thykier  wrote:

Andreas Metzler:

[...]

supporting build-profiles like nodoc with dh_install seems to cumbersome.



Any reason for not using dh_installdocs, which does `nodoc` out of the box?


Hello Niels

Because for this specific case I need to handle files outside of
/usr/share/doc/$package.

cu Andreas


Ok, thanks for clarifying.

The use of substitution is not intended as a filtering mechanism. The 
go-to solution for having filtering beyond debhelper's built-in is 
`dh-exec` which has architecture and build-profile filtering.


I understand that this might not be what you want. However, this is the 
feature set provided. If you really want to do all this logic in 
debian/rules, then you can simply do a `install foo bar` directly in the 
d/rules (or a `dh_install foo bar`).


Best regards,
Niels

Bug#1060000: e2fsprogs NMU for /usr-move

[Helmut Grohne]

Hi Ted,

On Sun, Mar 10, 2024 at 09:56:46PM +0100, Helmut Grohne wrote:
> I've uploaded this to experimental directly to clear NEW and to get a
> dumat report quickly. Barring your opposition, I'll NMU this to unstable
> as well.

Given reviews from Michael Hudson-Doyle, Matthias Klose and Steve
Langasek, I'm moving to unstable without delay as this reduces the need
for binNMUs. I'm also improving Breaks/Provides given feedback from
Matthias.

Helmut
diff --minimal -Nru e2fsprogs-1.47.0/debian/changelog 
e2fsprogs-1.47.0/debian/changelog
--- e2fsprogs-1.47.0/debian/changelog   2024-02-29 20:01:06.0 +0100
+++ e2fsprogs-1.47.0/debian/changelog   2024-03-13 07:20:06.0 +0100
@@ -1,3 +1,20 @@
+e2fsprogs (1.47.0-2.4) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Upload to unstable.
+  * Version Provides and Breaks (thanks to Matthias Klose).
+
+ -- Helmut Grohne   Wed, 13 Mar 2024 07:20:06 +0100
+
+e2fsprogs (1.47.0-2.4~exp1) experimental; urgency=medium
+
+  * Non-maintainer upload.
+  * Revert time64 transitions for libss2 and libcom-err2.
+  * Enable dh_movetousr (DEP17). (Closes: #106)
++ Mitigate file loss in libext2fs2 -> libext2fs2t64 upgrade and /usr-move.
+
+ -- Helmut Grohne   Sun, 10 Mar 2024 21:02:48 +0100
+
 e2fsprogs (1.47.0-2.3) unstable; urgency=medium
 
   * Non-maintainer upload.
diff --minimal -Nru e2fsprogs-1.47.0/debian/control 
e2fsprogs-1.47.0/debian/control
--- e2fsprogs-1.47.0/debian/control 2024-02-29 19:03:22.0 +0100
+++ e2fsprogs-1.47.0/debian/control 2024-03-13 07:20:06.0 +0100
@@ -2,7 +2,7 @@
 Section: admin
 Priority: required
 Maintainer: Theodore Y. Ts'o 
-Build-Depends: dpkg-dev (>= 1.22.5), gettext, texinfo, pkg-config, libfuse-dev 
[linux-any kfreebsd-any] , debhelper-compat (= 12), 
dh-exec, libblkid-dev, uuid-dev, m4, udev [linux-any], systemd [linux-any], 
systemd-dev [linux-any], cron [linux-any]
+Build-Depends: dpkg-dev (>= 1.22.5), gettext, texinfo, pkg-config, libfuse-dev 
[linux-any kfreebsd-any] , debhelper-compat (= 12), 
dh-exec, libblkid-dev, uuid-dev, m4, udev [linux-any], systemd [linux-any], 
systemd-dev [linux-any], cron [linux-any], dh-sequence-movetousr
 Rules-Requires-Root: no
 Standards-Version: 4.6.2
 Homepage: http://e2fsprogs.sourceforge.net
@@ -64,13 +64,13 @@
  This package provides translations for messages for programs found in
  the 'e2fsprogs' package.
 
-Package: libcom-err2t64
+Package: libcom-err2
 Section: libs
 Priority: optional
 Depends: ${shlibs:Depends}, ${misc:Depends}
-Replaces: libcom-err2, libcomerr2 (<< 1.43.9-1~)
-Breaks: libcom-err2 (<< ${source:Version}), libcomerr2 (<< 1.43.9-1~)
-Provides: ${t64:Provides}, libcomerr2 (= ${binary:Version})
+Replaces: libcom-err2t64, libcomerr2 (<< 1.43.9-1~)
+Breaks: libcom-err2t64 (<< 1.47.0-2.4~exp1~), libcomerr2 (<< 1.43.9-1~)
+Provides: libcom-err2t64 (= ${binary:Version}), libcomerr2 (= 
${binary:Version})
 Architecture: any
 Multi-Arch: same
 Pre-Depends: ${misc:Pre-Depends}
@@ -82,7 +82,7 @@
 Package: comerr-dev
 Section: libdevel
 Priority: optional
-Depends: libc6-dev | libc-dev, libcom-err2t64 (= ${mainBinary}), 
${misc:Depends}
+Depends: libc6-dev | libc-dev, libcom-err2 (= ${mainBinary}), ${misc:Depends}
 Suggests: doc-base
 Replaces: e2fslibs-dev (<< 1.33-2), libkrb5-dev (<< 1.3)
 Architecture: any
@@ -94,13 +94,13 @@
  .
  This package contains the development environment for the com_err library.
 
-Package: libss2t64
-Provides: ${t64:Provides}
-Breaks: libss2 (<< ${source:Version})
+Package: libss2
+Provides: libss2t64 (= ${binary:Version})
+Breaks: libss2t64 (<< 1.47.0-2.4~exp1~)
 Section: libs
 Priority: optional
-Depends: libcom-err2t64, ${shlibs:Depends}, ${misc:Depends}
-Replaces: libss2, e2fsprogs (<< 1.34-1)
+Depends: libcom-err2, ${shlibs:Depends}, ${misc:Depends}
+Replaces: libss2t64, e2fsprogs (<< 1.34-1)
 Architecture: any
 Multi-Arch: same
 Pre-Depends: ${misc:Pre-Depends}
@@ -114,7 +114,7 @@
 Package: ss-dev
 Section: libdevel
 Priority: optional
-Depends: libc6-dev | libc-dev, libss2t64 (= ${mainBinary}), comerr-dev, 
${misc:Depends}
+Depends: libc6-dev | libc-dev, libss2 (= ${mainBinary}), comerr-dev, 
${misc:Depends}
 Architecture: any
 Multi-Arch: same
 Description: command-line interface parsing library - headers and static 
libraries
diff --minimal -Nru e2fsprogs-1.47.0/debian/libcom-err2.install 
e2fsprogs-1.47.0/debian/libcom-err2.install
--- e2fsprogs-1.47.0/debian/libcom-err2.install 1970-01-01 01:00:00.0 
+0100
+++ e2fsprogs-1.47.0/debian/libcom-err2.install 2024-02-29 19:03:22.0 
+0100
@@ -0,0 +1 @@
+lib/*/libcom_err*.so.*
diff --minimal -Nru e2fsprogs-1.47.0/debian/libcom-err2.symbols 
e2fsprogs-1.47.0/debian/libcom-err2.symbols
--- e2fsprogs-1.47.0/debian/libcom-err2.symbols 1970-01-01 01:00:00.0 
+0100
+++ e2fsprogs-1.47.0/debian/libcom-err2.symbols 2024-03-10 20:51:48.0 
+0100
@@ -0,0 +1,22 @@
+libcom_err.so.2 libcom-err2 #MINVER#
+* Build-Depends-Package: 

Bug#1066183: mate-equake-applet FTBFS due to -Werror=implicit-function-declaration

[Helmut Grohne]

Source: mate-equake-applet
Version: 1.3.8.2-1.1
Severity: serious
Tags: ftbfs

Due to the time64 transition -Werror=implicit-function-declaration was
turned on by default in unstable. This change makes mate-equake-applet
fail to build from source. Relevant snippet:

| equake_processdata.c: In function ‘convert_localtime’:
| equake_processdata.c:1105:3: error: implicit declaration of function 
‘strptime’; did you mean ‘strftime’? [-Werror=implicit-function-declaration]
|  1105 |   strptime(datetime, "%Y %m %d %H %M %S %z", tp); /* year month day 
hour minute second */
|   |   ^~~~
|   |   strftime

Helmut

Bug#904233: Adoption of persp-projectile

[Sean Whitton]

Hello,

On Tue 12 Mar 2024 at 08:47pm -07, Xiyue Deng wrote:

> Sean Whitton  writes:
>
>> Hello Xiyue,
>>
>> Do you still intend to adopt persp-projectile?
>>
>> Thanks.
>
> Yes.  And it seems I forgot to close this ITA bug in the Changelog.  Can
> we close this directly instead?

We could, but I don't think you actually adopted it :)

-- 
Sean Whitton

Bug#1066182: erlang-jiffy: please add support for loongarch

[wuruilong]

Source: erlang-jiffy
Version: 1.1.1-2
Severity: normal
X-Debbugs-Cc: wuruil...@loongson.cn
User: debian-de...@lists.debian.org
Usertags: loong64

Dear Maintainer,

Erlang-jiffy has a compilation error in the loong64 architecture. 
The attached patch solves the problem. Please refer to it supports loong64 
architecture

wuruilong

-- System Information:
Debian Release: trixie/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'unstable')
Architecture: loong64 (loongarch64)

Kernel: Linux 5.10.0-60.96.0.126.oe2203.loongarch64 (SMP w/32 CPU threads)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect
Description: 
 TODO: Put a short summary on the line above and replace this paragraph
 with a longer explanation of this change. Complete the meta-information
 with other relevant fields (see below for details). To make it easier, the
 information below has been extracted from the changelog. Adjust it or drop
 it.
 .
 erlang-jiffy (1.1.1-2) unstable; urgency=medium
 .
   * Removed superfluous line from debian/copyright
   * Updated Standards-Version: 4.6.2 (no changes needed)
   * Updated lintian overrides
   * Updated years in debian/copyright
   * Renamed debian/erlang-jiffy.lintian-overrides -> debian/lintian-overrides
   * Updated debian/rules
   * Updated debian/patches/remove_git_clean
Author: Philipp Huebner 

---
The information above should follow the Patch Tagging Guidelines, please
checkout https://dep.debian.net/deps/dep3/ to learn about the format. Here
are templates for supplementary fields that you might want to add:

Origin: (upstream|backport|vendor|other), (|commit:)
Bug: 
Bug-Debian: https://bugs.debian.org/
Bug-Ubuntu: https://launchpad.net/bugs/
Forwarded: (no|not-needed|)
Applied-Upstream: , (|commit:)
Reviewed-By: 
Last-Update: 2024-03-13

--- erlang-jiffy-1.1.1.orig/c_src/double-conversion/utils.h
+++ erlang-jiffy-1.1.1/c_src/double-conversion/utils.h
@@ -93,6 +93,7 @@ int main(int argc, char** argv) {
 #if defined(_M_X64) || defined(__x86_64__) || \
 defined(__ARMEL__) || defined(__avr32__) || defined(_M_ARM) || 
defined(_M_ARM64) || \
 defined(__hppa__) || defined(__ia64__) || \
+defined(__loongarch__) ||\
 defined(__mips__) || \
 defined(__powerpc__) || defined(__ppc__) || defined(__ppc64__) || \
 defined(_POWER) || defined(_ARCH_PPC) || defined(_ARCH_PPC64) || \

Bug#1066117: FTBFS: missing build-dep on libnsl-dev

[Aurelien Jarno]

Hi,

On 2024-03-12 23:22, Preuße, Hilmar wrote:
> On 12.03.2024 21:59, Aurelien Jarno wrote:
> 
> Hi Aurelien,
> 
> > Starting with glibc 2.31, support for NIS (libnsl library) has been
> > moved to a separate libnsl2 package. In order to allow a smooth
> > transition, a libnsl-dev has been added to the libc6-dev package.
> > 
> > This dependency has been temporarily dropped in the 2.37-15.1 NMU, as
> > part of the 64-bit time_t transition. This causes proftpd-dfsg to FTBFS in
> > sid with:
> > 
> I've seen the issue, but I wasn't sure if I have to do something or if I
> have just have to wait until the dep change has been reverted. Let me
> know if I should upload a fixed package w/ the BD added.

Yes, please upload a package with the extra BD. The time_t transition
takes longer than expected, and proftpd-dfsg is part of the transition.

Thanks
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://aurel32.net