date:20240317

Source: x11vnc
Version: 0.9.16-9
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: sramac...@debian.org

https://buildd.debian.org/status/fetch.php?pkg=x11vnc=armhf=0.9.16-9%2Bb1=1710639780=0

gcc -DHAVE_CONFIG_H -I. -I..   -D_REENTRANT  -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 -c -o x11vnc-user.o `test -f 'user.c' || echo 
'./'`user.c
uinput.c: In function ‘ptr_move’:
uinput.c:723:25: error: ‘struct input_event’ has no member named ‘time’
  723 | gettimeofday(, NULL);
  | ^
uinput.c: In function ‘ptr_abs’:
uinput.c:776:25: error: ‘struct input_event’ has no member named ‘time’
  776 | gettimeofday(, NULL);
  | ^
uinput.c: In function ‘button_click’:
uinput.c:962:25: error: ‘struct input_event’ has no member named ‘time’
  962 | gettimeofday(, NULL);
  | ^
uinput.c: In function ‘uinput_key_command’:
uinput.c:1256:25: error: ‘struct input_event’ has no member named ‘time’
 1256 | gettimeofday(, NULL);
  | ^

Cheers
-- 
Sebastian Ramacher

Bug#1067077: frr: FTBFS on armel: /usr/bin/ld: ./build/../bgpd/bgp_io.c:476:(.text+0x51c): undefined reference to `__atomic_store_8'

Source: frr
Version: 9.1-0.1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: sramac...@debian.org

https://buildd.debian.org/status/fetch.php?pkg=frr=armel=9.1-0.1=1710631814=0

libtool: link: gcc -fms-extensions -fno-omit-frame-pointer -funwind-tables 
-Wall -Wextra -Wformat-nonliteral -Wformat-security -Wswitch-enum 
-Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wpointer-arith 
-Wbad-function-cast -Wwrite-strings -Wundef -Wno-unused-result 
-Wno-unused-parameter -Wno-missing-field-initializers -g -O2 
-Werror=implicit-function-declaration -ffile-prefix-map=/<>=. 
-fstack-protector-strong -fstack-clash-protection -Wformat 
-Werror=format-security -Wl,-z -Wl,relro -Wl,-z -Wl,now -g -o bgpd/.libs/bgpd 
bgpd/bgp_main.o yang/frr-bgp-types.yang.o yang/frr-bgp.yang.o 
yang/frr-bgp-common-structure.yang.o yang/frr-bgp-common.yang.o 
yang/frr-bgp-common-multiprotocol.yang.o yang/frr-bgp-neighbor.yang.o 
yang/frr-bgp-peer-group.yang.o yang/frr-bgp-bmp.yang.o yang/frr-bgp-rpki.yang.o 
yang/frr-deviations-bgp-datacenter.yang.o yang/frr-bgp-filter.yang.o 
yang/frr-bgp-route-map.yang.o -Wl,--export-dynamic  bgpd/libbgp.a 
bgpd/rfp-example/librfp/librfp.a lib/.libs/libfrr.so -lyang -lcap -lm -ljson-c 
-lrt -Wl,-rpath -Wl,/usr/lib/arm-linux-gnueabi/frr
/usr/bin/ld: /usr/bin/ld: bgpd/libbgp.a(bgp_vty.o): in function `bgp_show_peer':
./build/../bgpd/bgp_vty.c:13678:(.text+0x1d934): undefined reference to 
`__atomic_load_8'
/usr/bin/ld: ./build/../bgpd/bgp_vty.c:13686:(.text+0x1d9bc): undefined 
reference to `__atomic_load_8'
/usr/bin/ld: ./build/../bgpd/bgp_vty.c:13778:(.text+0x1ed90): undefined 
reference to `__atomic_load_8'
bgpd/libbgp.a(bgp_vty.o): in function `bgp_show_peer':
./build/../bgpd/bgp_vty.c:13678:(.text+0x1d934): undefined reference to 
`__atomic_load_8'
/usr/bin/ld: ./build/../bgpd/bgp_vty.c:13686:(.text+0x1d9bc): undefined 
reference to `__atomic_load_8'
/usr/bin/ld: ./build/../bgpd/bgp_vty.c:13778:(.text+0x1ed90): undefined 
reference to `__atomic_load_8'
/usr/bin/ld: bgpd/libbgp.a(bgp_packet.o): in function `bgp_update_receive':
./build/../bgpd/bgp_packet.c:2328:(.text+0x5fac): undefined reference to 
`__atomic_store_8'
/usr/bin/ld: bgpd/libbgp.a(bgp_fsm.o): in function `bgp_stop':
./build/../bgpd/bgp_fsm.c:1549:(.text+0x7dc): undefined reference to 
`__atomic_store_8'
/usr/bin/ld: bgpd/libbgp.a(bgp_fsm.o): in function `bgp_adjust_routeadv':
./build/../bgpd/bgp_fsm.c:984:(.text+0x3700): undefined reference to 
`__atomic_load_8'
/usr/bin/ld: bgpd/libbgp.a(bgp_io.o): in function `bgp_write':
./build/../bgpd/bgp_io.c:471:(.text+0x3e8): undefined reference to 
`__atomic_store_8'
/usr/bin/ld: ./build/../bgpd/bgp_io.c:471:(.text+0x4f4): undefined reference to 
`__atomic_store_8'
/usr/bin/ld: ./build/../bgpd/bgp_io.c:476:(.text+0x51c): undefined reference to 
`__atomic_store_8'
/usr/bin/ld: bgpd/libbgp.a(bgp_packet.o): in function `bgp_update_receive':
./build/../bgpd/bgp_packet.c:2328:(.text+0x5fac): undefined reference to 
`__atomic_store_8'
/usr/bin/ld: bgpd/libbgp.a(bgp_fsm.o): in function `bgp_stop':
./build/../bgpd/bgp_fsm.c:1549:(.text+0x7dc): undefined reference to 
`__atomic_store_8'
/usr/bin/ld: bgpd/libbgp.a(bgp_fsm.o): in function `bgp_adjust_routeadv':
./build/../bgpd/bgp_fsm.c:984:(.text+0x3700): undefined reference to 
`__atomic_load_8'
/usr/bin/ld: bgpd/libbgp.a(bgp_io.o): in function `bgp_write':
./build/../bgpd/bgp_io.c:471:(.text+0x3e8): undefined reference to 
`__atomic_store_8'
/usr/bin/ld: ./build/../bgpd/bgp_io.c:471:(.text+0x4f4): undefined reference to 
`__atomic_store_8'
/usr/bin/ld: ./build/../bgpd/bgp_io.c:476:(.text+0x51c): undefined reference to 
`__atomic_store_8'
collect2: error: ld returned 1 exit status
make[3]: *** [Makefile:8013: bgpd/bgp_btoa] Error 1

Cheers
-- 
Sebastian Ramacher

Bug#1065655: dot2tex: SyntaxWarning: invalid escape sequences

2024-03-17 Thread Torrance, Douglas


Control: tags -1 moreinfo

On Fri, 08 Mar 2024 09:54:07 + Julian Gilbey  wrote:

Package: dot2tex
Version: 2.11.3-4
Severity: normal

While installing this version on a testing system, lots of warning
messages were given; the relevant strings should be marked as raw.

/usr/lib/python3/dist-packages/dot2tex/dot2tex.py:900: SyntaxWarning: invalid 
escape sequence '\i'
  variables['<>'] = "\input{gvcols.tex}"
/usr/lib/python3/dist-packages/dot2tex/dot2tex.py:1236: SyntaxWarning: invalid 
escape sequence '\p'
  s += "  \psellipse[%s](%sbp,%sbp)(%sbp,%sbp)\n" % (stylestr, smart_float(x), 
smart_float(y),
/usr/lib/python3/dist-packages/dot2tex/dot2tex.py:1256: SyntaxWarning: invalid 
escape sequence '\p'
  s = "  \pspolygon[%s]%s\n" % (stylestr, "".join(pp))
/usr/lib/python3/dist-packages/dot2tex/dot2tex.py:1262: SyntaxWarning: invalid 
escape sequence '\p'
  s = "  \psline%s\n" % "".join(pp)
/usr/lib/python3/dist-packages/dot2tex/dot2tex.py:1272: SyntaxWarning: invalid 
escape sequence '\p'
  return "  \psbezier{%s}%s\n" % (arrowstyle, "".join(pp))
/usr/lib/python3/dist-packages/dot2tex/dot2tex.py:1299: SyntaxWarning: invalid 
escape sequence '\p'
  s = "  \psset{linecolor=%s}\n" % color
/usr/lib/python3/dist-packages/dot2tex/dot2tex.py:1306: SyntaxWarning: invalid 
escape sequence '\p'
  s = "  \psset{fillcolor=%s}\n" % color
/usr/lib/python3/dist-packages/dot2tex/dot2tex.py:1313: SyntaxWarning: invalid 
escape sequence '\p'
  s = "  \psset{linecolor=%s}\n" % color
/usr/lib/python3/dist-packages/dot2tex/dot2tex.py:1322: SyntaxWarning: invalid 
escape sequence '\p'
  return "  \psset{%s}\n" % psstyle
/usr/lib/python3/dist-packages/dot2tex/dot2tex.py:1393: SyntaxWarning: invalid 
escape sequence '\p'
  s += "  \psbezier[%s]%s\n" % (stylestr, "".join(pp))
/usr/lib/python3/dist-packages/dot2tex/dot2tex.py:1395: SyntaxWarning: invalid 
escape sequence '\p'
  s += "  \psline[%s]%s%s\n" % (stylestr, pp[0], pp[-1])
/usr/lib/python3/dist-packages/dot2tex/dot2tex.py:1589: SyntaxWarning: invalid 
escape sequence '\p'
  dashed='\pgfsetdash{{3pt}{3pt}}{0pt}',
/usr/lib/python3/dist-packages/dot2tex/dot2tex.py:1590: SyntaxWarning: invalid 
escape sequence '\p'
  dotted='\pgfsetdash{{\pgflinewidth}{2pt}}{0pt}',
/usr/lib/python3/dist-packages/dot2tex/dot2tex.py:1591: SyntaxWarning: invalid 
escape sequence '\p'
  bold='\pgfsetlinewidth{1.2pt}')
/usr/lib/python3/dist-packages/dot2tex/dot2tex.py:1639: SyntaxWarning: invalid 
escape sequence '\d'
  s += "  \definecolor{newcol}%s;\n" % ccolor
/usr/lib/python3/dist-packages/dot2tex/dot2tex.py:1641: SyntaxWarning: invalid 
escape sequence '\p'
  s += "  \pgfsetcolor{%s}\n" % ccolor
/usr/lib/python3/dist-packages/dot2tex/dot2tex.py:1649: SyntaxWarning: invalid 
escape sequence '\d'
  s += "  \definecolor{strokecol}%s;\n" % ccolor
/usr/lib/python3/dist-packages/dot2tex/dot2tex.py:1651: SyntaxWarning: invalid 
escape sequence '\p'
  s += "  \pgfsetstrokecolor{%s}\n" % ccolor
/usr/lib/python3/dist-packages/dot2tex/dot2tex.py:1661: SyntaxWarning: invalid 
escape sequence '\d'
  s += "  \definecolor{fillcol}%s;\n" % ccolor
/usr/lib/python3/dist-packages/dot2tex/dot2tex.py:1663: SyntaxWarning: invalid 
escape sequence '\p'
  s += "  \pgfsetfillcolor{%s}\n" % ccolor
/usr/lib/python3/dist-packages/dot2tex/dot2tex.py:1707: SyntaxWarning: invalid 
escape sequence '\%'
  s += "  \%s%s (%sbp,%sbp) ellipse (%sbp and %sbp);\n" % (cmd, stylestr, 
smart_float(x), smart_float(y),
/usr/lib/python3/dist-packages/dot2tex/dot2tex.py:1723: SyntaxWarning: invalid 
escape sequence '\%'
  s = "  \%s%s %s -- cycle;\n" % (cmd, stylestr, " -- ".join(pp))
/usr/lib/python3/dist-packages/dot2tex/dot2tex.py:1730: SyntaxWarning: invalid 
escape sequence '\d'
  return "  \draw%s %s;\n" % (stylestr, " -- ".join(pp))
/usr/lib/python3/dist-packages/dot2tex/dot2tex.py:1753: SyntaxWarning: invalid 
escape sequence '\d'
  s = "  \draw (%sbp,%sbp) node%s {%s};\n" % (smart_float(x), smart_float(y), 
lblstyle, text)
/usr/lib/python3/dist-packages/dot2tex/dot2tex.py:1765: SyntaxWarning: invalid 
escape sequence '\d'
  s += "  \draw%s %s .. %s;\n" % (stylestr, " .. ".join(pstrs), pp[-1])
/usr/lib/python3/dist-packages/dot2tex/dot2tex.py:1857: SyntaxWarning: invalid 
escape sequence '\d'
  s += "  \draw [%s] %s to[%s]%s %s;\n" % (stylestr, src,
/usr/lib/python3/dist-packages/dot2tex/dot2tex.py:1860: SyntaxWarning: invalid 
escape sequence '\d'


Thanks for the report!

I'm not able to reproduce these warnings.  What did you run to get them?


signature.asc
Description: PGP signature

Bug#1067075: openvas-scanner: FTBFS on arm{el,hf}: /<>/src/attack.c:1617:16: error: format ‘%ld’ expects argument of type ‘long int’, but argument 5 has type ‘__time64_t’ {aka ‘long long

Source: openvas-scanner
Version: 22.7.9-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: sramac...@debian.org

https://buildd.debian.org/status/fetch.php?pkg=openvas-scanner=armhf=22.7.9-1%2Bb1=1710667919=0

[ 89%] Building C object src/CMakeFiles/openvas.dir/pluginload.c.o
cd /<>/obj-arm-linux-gnueabihf/src && /usr/bin/cc 
-DNVT_TIMEOUT=320 -DOPENVAS_CONF=\"/etc/openvas/openvas.conf\" 
-DOPENVAS_DATA_DIR=\"/usr/share/openvas\" 
-DOPENVAS_FEED_LOCK_PATH=\"/var/lib/openvas/feed-update.lock\" 
-DOPENVAS_NVT_DIR=\"/var/lib/openvas/plugins\" -DOPENVAS_RUN_DIR=\"/run/ospd\" 
-DOPENVAS_STATE_DIR=\"/var/lib/openvas\" -DOPENVAS_SYSCONF_DIR=\"/etc/openvas\" 
-DOPENVAS_VERSION=\"22.7.9\" -DPREFIX=\"/usr\" -DSCANNER_NVT_TIMEOUT=36000 
-DSYSCONFDIR=\"/etc\" -I/usr/include/glib-2.0 
-I/usr/lib/arm-linux-gnueabihf/glib-2.0/include -I/usr/include/gvm -g -O2 
-Werror=implicit-function-declaration -ffile-prefix-map=/<>=. 
-fstack-protector-strong -fstack-clash-protection -Wformat 
-Werror=format-security -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 
-D_TIME_BITS=64 -Wdate-time -D_FORTIFY_SOURCE=2 -D_FILE_OFFSET_BITS=64 
-DLARGEFILE_SOURCE=1 -std=c11   
  -Wall -Wextra 
-Werror -Wpedantic  
   -Wmissing-prototypes -Wshadow
 -Wsequence-point 
-D_BSD_SOURCE -D_ISOC11_SOURCE  
   -D_SVID_SOURCE -D_DEFAULT_SOURCE 
-O3 -DNDEBUG -Wformat -Wformat-security -D_FORTIFY_SOURCE=2 -fstack-protector 
-MD -MT src/CMakeFiles/openvas.dir/pluginload.c.o -MF 
CMakeFiles/openvas.dir/pluginload.c.o.d -o 
CMakeFiles/openvas.dir/pluginload.c.o -c /<>/src/pluginload.c
In file included from /usr/include/glib-2.0/glib.h:64,
 from /<>/src/../misc/scanneraux.h:14,
 from /<>/src/attack.h:16,
 from /<>/src/attack.c:13:
/<>/src/attack.c: In function ‘attack_network’:
/<>/src/attack.c:1617:16: error: format ‘%ld’ expects argument of 
type ‘long int’, but argument 5 has type ‘__time64_t’ {aka ‘long long int’} 
[-Werror=format=]
 1617 | g_message ("Vulnerability scan %s finished in %ld seconds: "
  |^
 1618 |"%d alive hosts of %d",
 1619 |globals->scan_id, now.tv_sec - then.tv_sec,
  |  
  | |
  | __time64_t {aka long long 
int}
/usr/include/glib-2.0/glib/gmessages.h:350:32: note: in definition of macro 
‘g_message’
  350 |__VA_ARGS__)
  |^~~
/<>/src/attack.c:1617:53: note: format string is defined here
 1617 | g_message ("Vulnerability scan %s finished in %ld seconds: "
  |   ~~^
  | |
  | long int
  |   %lld
/<>/src/attack.c:1622:16: error: format ‘%ld’ expects argument of 
type ‘long int’, but argument 5 has type ‘__time64_t’ {aka ‘long long int’} 
[-Werror=format=]
 1622 | g_message ("Vulnerability scan %s finished in %ld seconds: %d 
hosts",
  |^
 1623 |globals->scan_id, now.tv_sec - then.tv_sec,
  |  
  | |
  | __time64_t {aka long long 
int}
/usr/include/glib-2.0/glib/gmessages.h:350:32: note: in definition of macro 
‘g_message’
  350 |__VA_ARGS__)
  |^~~
/<>/src/attack.c:1622:53: note: format string is defined here
 1622 | g_message ("Vulnerability scan %s finished in %ld seconds: %d 
hosts",
  |   ~~^
  | |
  | long int
  |   %lld

Cheers
-- 
Sebastian Ramacher

Bug#1067074: liblog4ada: FTBFS on arm{el,hf}: gprbuild: raised CONSTRAINT_ERROR : a-calend.adb:371 overflow check failed

Source: liblog4ada
Version: 1.3.1.b6dafb49-13
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: sramac...@debian.org

https://buildd.debian.org/status/fetch.php?pkg=liblog4ada=armhf=1.3.1.b6dafb49-13=1710696951=0

/usr/bin/gcc-13 -c -x ada -gnatA -gnat12 -gnati1 -gnatf -gnatyM122 -gnatwa 
-gnatwe -g -O2 -Werror=implicit-function-declaration 
-ffile-prefix-map=/<>=. -fstack-protector-strong 
-fstack-clash-protection -gno-record-gcc-switches -fPIC 
-gnatec=/tmp/GPR.1869/GNAT-TEMP-03.TMP 
-gnatem=/tmp/GPR.1869/GNAT-TEMP-04.TMP 
/<>/client/src/log4ada.ads
gnat1: warning: ‘-Werror=’ argument ‘-Werror=implicit-function-declaration’ is 
not valid for Ada
gnat1: warning: ‘-Werror=’ argument ‘-Werror=implicit-function-declaration’ is 
not valid for Ada
gnat1: warning: ‘-Werror=’ argument ‘-Werror=implicit-function-declaration’ is 
not valid for Ada
gnat1: warning: ‘-Werror=’ argument ‘-Werror=implicit-function-declaration’ is 
not valid for Ada
gprbuild: raised CONSTRAINT_ERROR : a-calend.adb:371 overflow check failed

make[1]: *** [debian/rules:35: override_dh_auto_build-arch] Error 7

Cheers
-- 
Sebastian Ramacher

Bug#1067073: libncursesada: FTBFS on arm{el,hf}: gprbuild: raised CONSTRAINT_ERROR : a-calend.adb:371 overflow check failed

Source: libncursesada
Version: 6.3.20211021-11
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: sramac...@debian.org

https://buildd.debian.org/status/fetch.php?pkg=libncursesada=armel=6.3.20211021-11=1710701629=0

/usr/bin/gcc-13 -c -x ada -gnatA -gnataEfnoQq -gnatVa -gnatwa.eH.Y -Wall 
-Wextra -gnatyyM80 -g -O2 -Werror=implicit-function-declaration 
-ffile-prefix-map=/<>=. -fstack-protector-strong 
-fstack-clash-protection -gno-record-gcc-switches 
-gnatec=/tmp/GPR.16132/GNAT-TEMP-03.TMP 
-gnatem=/tmp/GPR.16132/GNAT-TEMP-04.TMP 
/<>/src/terminal_interface-curses-trace.adb
gnat1: warning: ‘-Werror=’ argument ‘-Werror=implicit-function-declaration’ is 
not valid for Ada
gnat1: warning: ‘-Werror=’ argument ‘-Werror=implicit-function-declaration’ is 
not valid for Ada
gnat1: warning: ‘-Werror=’ argument ‘-Werror=implicit-function-declaration’ is 
not valid for Ada
gnat1: warning: ‘-Werror=’ argument ‘-Werror=implicit-function-declaration’ is 
not valid for Ada
terminal_interface-curses.ads:460:30: warning: memory layout out of order 
[-gnatw_r]
terminal_interface-curses.ads:490:10: warning: component clause out of order 
with respect to declaration [-gnatw_r]
terminal_interface-curses.ads:499:16: warning: component clause out of order 
with respect to declaration [-gnatw_r]
gprbuild: raised CONSTRAINT_ERROR : a-calend.adb:371 overflow check failed

Cheers
-- 
Sebastian Ramacher

Bug#1067072: libflorist: FTBFS on arm{el,hf}: posix-c.ads:876:07: error: size for "suseconds_t" too small, minimum allowed is 64

Source: libflorist
Version: 2022.0.1~20220616-5
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: sramac...@debian.org

https://buildd.debian.org/status/fetch.php?pkg=libflorist=armhf=2022.0.1%7E20220616-5=1710701527=0

gnat1: warning: ‘-Werror=’ argument ‘-Werror=implicit-function-declaration’ is 
not valid for Ada
/usr/bin/gcc-13 -c -x ada -gnatA -O2 -gnatp -gnat95 -g -O2 
-Werror=implicit-function-declaration -ffile-prefix-map=/<>=. 
-fstack-protector-strong -fstack-clash-protection -gno-record-gcc-switches 
-gnatVa -gnatafno -fPIC -gnatec=/tmp/GPR.1718/GNAT-TEMP-03.TMP 
-gnatem=/tmp/GPR.1718/GNAT-TEMP-05.TMP 
/<>/libsrc/threads/posix-message_queues.adb
gnat1: warning: ‘-Werror=’ argument ‘-Werror=implicit-function-declaration’ is 
not valid for Ada
posix-c.ads:876:07: error: size for "suseconds_t" too small, minimum allowed is 
64
gnat1: warning: ‘-Werror=’ argument ‘-Werror=implicit-function-declaration’ is 
not valid for Ada
posix-c.ads:876:07: error: size for "suseconds_t" too small, minimum allowed is 
64
gnat1: warning: ‘-Werror=’ argument ‘-Werror=implicit-function-declaration’ is 
not valid for Ada
posix-c.ads:876:07: error: size for "suseconds_t" too small, minimum allowed is 
64
gnat1: warning: ‘-Werror=’ argument ‘-Werror=implicit-function-declaration’ is 
not valid for Ada
posix-c.ads:876:07: error: size for "suseconds_t" too small, minimum allowed is 
64

   compilation of posix-message_queues.adb failed
   compilation of posix-condition_variables.adb failed
   compilation of posix-asynchronous_io.adb failed
   compilation of posix-timers-extensions.adb failed

gprbuild: *** compilation phase failed

Cheers
-- 
Sebastian Ramacher

Bug#1067071: lubaunit: FTBFS on arm{el,hf}: gprbuild: raised CONSTRAINT_ERROR : a-calend.adb:371 overflow check failed

Source: libaunit
Version: 24.0.0-2
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: sramac...@debian.org

https://buildd.debian.org/status/fetch.php?pkg=libaunit=armel=24.0.0-2=1710701210=0

/usr/bin/gcc-13 -c -x ada -gnatA -O2 -gnatp -gnatn -gnatwa.X -g -O2 
-Werror=implicit-function-declaration -ffile-prefix-map=/<>=. 
-fstack-protector-strong -fstack-clash-protection -gno-record-gcc-switches 
-gnatfno -gnatwa -gnatVa -fno-strict-aliasing -fPIC 
-gnatec=/tmp/GPR.3085/GNAT-TEMP-03.TMP 
-gnatem=/tmp/GPR.3085/GNAT-TEMP-06.TMP 
/<>/include/aunit/framework/aunit.adb
gnat1: warning: ‘-Werror=’ argument ‘-Werror=implicit-function-declaration’ is 
not valid for Ada
gnat1: warning: ‘-Werror=’ argument ‘-Werror=implicit-function-declaration’ is 
not valid for Ada
gnat1: warning: ‘-Werror=’ argument ‘-Werror=implicit-function-declaration’ is 
not valid for Ada
gnat1: warning: ‘-Werror=’ argument ‘-Werror=implicit-function-declaration’ is 
not valid for Ada
gprbuild: raised CONSTRAINT_ERROR : a-calend.adb:371 overflow check failed

Cheers
-- 
Sebastian Ramacher

Bug#1067070: adacgi: FTBFS on arm{el,hf}: gprbuild: raised CONSTRAINT_ERROR : a-calend.adb:371 overflow check failed

Source: adacgi
Version: 1.6-34
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: sramac...@debian.org

https://buildd.debian.org/status/fetch.php?pkg=adacgi=armel=1.6-34=1710700906=0

/usr/bin/gcc-13 -c -x ada -gnatA -g -O2 -Werror=implicit-function-declaration 
-ffile-prefix-map=/<>=. -fstack-protector-strong 
-fstack-clash-protection -gno-record-gcc-switches 
-gnatec=/tmp/GPR.27197/GNAT-TEMP-03.TMP 
-gnatem=/tmp/GPR.27197/GNAT-TEMP-05.TMP /<>/cgi.adb
gnat1: warning: ‘-Werror=’ argument ‘-Werror=implicit-function-declaration’ is 
not valid for Ada
gnat1: warning: ‘-Werror=’ argument ‘-Werror=implicit-function-declaration’ is 
not valid for Ada
gprbuild: raised CONSTRAINT_ERROR : a-calend.adb:371 overflow check failed

make[1]: *** [debian/rules:28: override_dh_auto_build] Error 7

Cheers
-- 
Sebastian Ramacher

Bug#860890: needs ssl-cert membership, does not report the error

2024-03-17 Thread Gürkan Myczko

sorry wrong link, here's the right one: 
https://github.com/alexmyczko/autoexec.bat/blob/master/config.sys/install-rdp

Bug#860890: needs ssl-cert membership, does not report the error

2024-03-17 Thread Gürkan Myczko

Thank you for all the input, I can't decide yet, as I just fix it for 
myself using this:


https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=860890

I feel a note in README.Debian is okay, if you also think so, I'll close 
the bug with

a future update.

Otherwise let us discuss this further here, and/or #debian-remote

Best,
Alex

Bug#1067068: mpfi: Please package new upstream version

2024-03-17 Thread Hilmar Preusse

Source: mpfi
Version: 1.5.3+ds-6
Severity: wishlist
Tags: upstream
X-Debbugs-Cc: debian-tex-ma...@lists.debian.org

Dear Maintainer,

I'm on the way to package the TeX Live sources (also known as src:texlive-bin)
for TL 2024. The sources use the library mpfi. Unfortunately(?) the TL
maintainers use the library in version 1.5.4; compiling with version 1.5.3
fails:

gcc -DHAVE_CONFIG_H -I. -I../../../texk/web2c -I./w2c -I./../../libs   
-I/<>/Work/texk -I/<>/texk 
-I../../../texk/web2c/mplibdir -Wdate-time -D_FORTIFY_SOURCE=2 -Wimplicit 
-Wreturn-type -g -O2 -Werror=implicit-function-declaration 
-ffile-prefix-map=/<>=. -fstack-protector-strong 
-fstack-clash-protection -Wformat -Werror=format-security 
-mbranch-protection=standard -c -o libmplibextramath_a-mpmathinterval.o `test 
-f 'mpmathinterval.c' || echo '../../../texk/web2c/'`mpmathinterval.c
../../../texk/web2c/mplibdir/mpmathinterval.w: In function ‘mpfi_remainder_1’:
../../../texk/web2c/mplibdir/mpmathinterval.w:305:1: error: implicit 
declaration of function ‘mpfi_inits2’; did you mean ‘mpfi_init2’? 
[-Werror=implicit-function-declaration]
  305 |  mpfi_inits2(precision_bits, ret1, ret2, l1, l2, (mpfi_ptr) 0);
  | ^~~
  | mpfi_init2
../../../texk/web2c/mplibdir/mpmathinterval.w:312:1: error: implicit 
declaration of function ‘mpfi_clears’; did you mean ‘mpfi_clear’? 
[-Werror=implicit-function-declaration]
  312 |  mpfi_clears(ret1, ret2, l1,l2,(mpfi_ptr)0);
  | ^~~
  | mpfi_clear
cc1: some warnings being treated as errors

a test with:

hille@rasppi2:~/devel/TeXLive $ ls -l *mpfi*
-rw-r--r-- 1 hille hille 34036 Mar 17 23:01 libmpfi0_1.5.4+ds-1_arm64.deb
-rw-r--r-- 1 hille hille 32228 Mar 17 23:01 libmpfi-dev_1.5.4+ds-1_arm64.deb
-rw-r--r-- 1 hille hille 10032 Mar 17 23:01 
libmpfi-dev-common_1.5.4+ds-1_all.deb

was positive, so I would like to use your library. The binary packages I
created were really just hacks, so feel free to ignore them.

Please be so kind to upgrade to the latest upstream version, so I can start
using your package. Thanks!

Hilmar

-- System Information:
Debian Release: 12.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: arm64 (aarch64)
Foreign Architectures: armhf

Kernel: Linux 6.6.20+rpt-rpi-v8 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_CRAP
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)


signature.asc
Description: PGP signature

Bug#1067041: Please also include "Incus UI"

2024-03-17 Thread Mathias Gibbens

Hi Osamu,

  Prior to the LXD/Incus hard fork, I did have an ITP to look at
packaging lxd-ui (#1036926). I think the "proper" way to package Incus
UI would be to have it as a new package (incus-ui), which incus
packaging could then Recommend or Suggest.

  I would also be more comfortable with Incus UI it was a proper fork
of Canonical's repository that carried the seven patches from
zabbly/incus. As a packager, we shouldn't be taking one upstream and
totally transforming it into something else via patches since that's
just too much work to carry in our packaging. :)

  My suggestion would be to rework this bug into a RFP and/or merge
with the prior ITP. I don't have any plans to work on this, but someone
else might.

Mathias


signature.asc
Description: This is a digitally signed message part

Bug#1067067: ruby-rdiscount: FTBFS: rdiscount.c:50:17: error: implicit declaration of function ‘rb_rdiscount__get_flags’ [-Werror=implicit-function-declaration]

Source: ruby-rdiscount
Version: 2.1.8-2
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: sramac...@debian.org

https://buildd.debian.org/status/fetch.php?pkg=ruby-rdiscount=amd64=2.1.8-2%2Bb3=1710698993=0

gcc -fdebug-prefix-map=/<>=. -I. 
-I/usr/include/x86_64-linux-gnu/ruby-3.1.0 
-I/usr/include/ruby-3.1.0/ruby/backward -I/usr/include/ruby-3.1.0 -I. 
-DHAVE_RANDOM -DHAVE_SRANDOM -DHAVE_RAND -DHAVE_SRAND -DSIZEOF_UNSIGNED_LONG=8 
-DSIZEOF_UNSIGNED_INT=4 -DSIZEOF_UNSIGNED_INT=4 -DVERSION=\"2.1.8\" -Wdate-time 
-D_FORTIFY_SOURCE=2   -fPIC -g -O2 -Werror=implicit-function-declaration 
-ffile-prefix-map=BUILDDIR=. -fstack-protector-strong -fstack-clash-protection 
-Wformat -Werror=format-security -fcf-protection -fPIC  -o rdiscount.o -c 
rdiscount.c
rdiscount.c: In function ‘rb_rdiscount_to_html’:
rdiscount.c:50:17: error: implicit declaration of function 
‘rb_rdiscount__get_flags’ [-Werror=implicit-function-declaration]
   50 | int flags = rb_rdiscount__get_flags(self);
  | ^~~
cc1: some warnings being treated as errors
make[1]: *** [Makefile:246: rdiscount.o] Error 1

Cheers
-- 
Sebastian Ramacher

Bug#1067066: ruby-fusefs: fusefs_fuse.c:31:10: error: implicit declaration of function ‘fuse_chan_fd’ [-Werror=implicit-function-declaration]

Source: ruby-fusefs
Version: 0.7.0-5
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: sramac...@debian.org

https://buildd.debian.org/status/fetch.php?pkg=ruby-fusefs=amd64=0.7.0-5%2Bb3=1710696156=0

make[1]: Entering directory '/<>/ext'
gcc -fdebug-prefix-map=/<>=. -I. 
-I/usr/include/x86_64-linux-gnu/ruby-3.1.0 
-I/usr/include/ruby-3.1.0/ruby/backward -I/usr/include/ruby-3.1.0 -I. 
-Wdate-time -D_FORTIFY_SOURCE=2   -fPIC -g -O2 
-Werror=implicit-function-declaration -ffile-prefix-map=BUILDDIR=. 
-fstack-protector-strong -fstack-clash-protection -Wformat 
-Werror=format-security -fcf-protection -fPIC  -o fusefs_fuse.o -c fusefs_fuse.c
fusefs_fuse.c: In function ‘fusefs_fd’:
fusefs_fuse.c:31:10: error: implicit declaration of function ‘fuse_chan_fd’ 
[-Werror=implicit-function-declaration]
   31 |   return fuse_chan_fd(fusech);
  |  ^~~~
fusefs_fuse.c: In function ‘fusefs_unmount’:
fusefs_fuse.c:41:5: warning: ignoring return value of ‘system’ declared with 
attribute ‘warn_unused_result’ [-Wunused-result]
   41 | system(buf);
  | ^~~
cc1: some warnings being treated as errors
make[1]: *** [Makefile:246: fusefs_fuse.o] Error 1
make[1]: Leaving directory '/<>/ext'

Cheers
-- 
Sebastian Ramacher

Bug#1066979: common-auth: sudo should not have incorrect password delay

2024-03-17 Thread Sam Hartman

> "Tim" == Tim Hutt  writes:
Tim> By default, on Debian and derivatives, `sudo` has a ~2 second
Tim> delay for incorrect password attempts. This serves no security
Tim> purpose whatsoever and merely annoys the user.

It's not obvious to me that it serves no security purpose.
Why can't sudo be used as a channel for password guessing?
Consider a case where ssh authentication does not permit passwords, but
where a password is required for sudo.

I'm unlikely to decide this is worth the complexity to fix (I think your
analysis of the possible options is roughly correct) even if there is no
security benefit.  I'm definitely not interested in fixing if there is a
security benefit.

Bug#1065202: RM: python-ppmd -- ROM; leaf package

2024-03-17 Thread Alexandre Detiste

This one is dead upstream too... it should be removed.

https://qa.debian.org/popcon.php?package=python-ppmd

"This repository has been archived by the owner on Apr 14, 2022. It is
now read-only."

Bug#1062092: coin3: NMU diff for 64-bit time_t transition

Although the package renaming in this patch appears to have been correct,
the actual code fails to build on 32-bit archs with 64-bit time_t.  Please
find an updated NMU patch that corrects this issue.

I am uploading this change to unstable.

On Wed, Feb 28, 2024 at 04:52:14PM +, Steve Langasek wrote:
> Dear maintainer,
> 
> Please find attached a final version of this patch for the time_t
> transition.  This patch is being uploaded to unstable.
> 
> Note that this adds a versioned build-dependency on dpkg-dev, to guard
> against accidental backports with a wrong ABI.
> 
> Thanks!
> 
> 
> -- System Information:
> Debian Release: trixie/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 6.5.0-14-generic (SMP w/12 CPU threads; PREEMPT)
> Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
> Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)

> diff -Nru coin3-4.0.2+ds/debian/changelog coin3-4.0.2+ds/debian/changelog
> --- coin3-4.0.2+ds/debian/changelog   2023-12-09 15:57:42.0 +
> +++ coin3-4.0.2+ds/debian/changelog   2024-02-28 16:47:51.0 +
> @@ -1,3 +1,10 @@
> +coin3 (4.0.2+ds-1.1) unstable; urgency=medium
> +
> +  * Non-maintainer upload.
> +  * Rename libraries for 64-bit time_t transition.  Closes: #1062092
> +
> + -- Steve Langasek   Wed, 28 Feb 2024 16:47:51 +
> +
>  coin3 (4.0.2+ds-1) unstable; urgency=medium
>  
>* Team upload.
> diff -Nru coin3-4.0.2+ds/debian/control coin3-4.0.2+ds/debian/control
> --- coin3-4.0.2+ds/debian/control 2023-12-09 15:56:48.0 +
> +++ coin3-4.0.2+ds/debian/control 2024-02-28 16:47:51.0 +
> @@ -3,7 +3,7 @@
>  Uploaders: Leopold Palomo-Avellaneda 
>  Section: graphics
>  Priority: optional
> -Build-Depends: debhelper-compat (= 13),
> +Build-Depends: dpkg-dev (>= 1.22.5), debhelper-compat (= 13),
> cmake,
> doxygen,
> libexpat-dev,
> @@ -25,7 +25,10 @@
>  Vcs-Git: https://salsa.debian.org/science-team/coin3.git
>  Homepage: https://github.com/coin3d
>  
> -Package: libcoin80c
> +Package: libcoin80t64
> +Provides: ${t64:Provides}
> +X-Time64-Compat: libcoin80c
> +Breaks: libcoin80c (<< ${source:Version})
>  Architecture: any
>  Multi-Arch: same
>  Section: libs
> @@ -37,7 +40,7 @@
>libsimage-dev,
>zlib1g
>  Pre-Depends: ${misc:Pre-Depends}
> -Replaces: libcoin80v5
> +Replaces: libcoin80c, libcoin80v5
>  Description: high-level 3D graphics kit implementing the Open Inventor API
>   Coin is an OpenGL-based, retain-mode 3D graphics library that
>   implements the Open Inventor 2.1 API. It also includes support for
> @@ -52,7 +55,7 @@
>  Package: libcoin-dev
>  Architecture: any
>  Section: libdevel
> -Depends: libcoin80c (= ${binary:Version}),
> +Depends: libcoin80t64 (= ${binary:Version}),
>   libgl-dev,
>libopengl-dev,
>libglew-dev,
> @@ -93,7 +96,7 @@
>  Multi-Arch: foreign
>  Section: libs
>  Depends: ${misc:Depends}
> -Suggests: libcoin80c
> +Suggests: libcoin80t64
>  Replaces: libcoin80-runtime
>  Breaks: libcoin80-runtime
>  Description: high-level 3D graphics kit - external data files
> diff -Nru coin3-4.0.2+ds/debian/libcoin80c.install 
> coin3-4.0.2+ds/debian/libcoin80c.install
> --- coin3-4.0.2+ds/debian/libcoin80c.install  2023-12-09 15:56:48.0 
> +
> +++ coin3-4.0.2+ds/debian/libcoin80c.install  1970-01-01 00:00:00.0 
> +
> @@ -1 +0,0 @@
> -usr/lib/*/lib*.so.*
> diff -Nru coin3-4.0.2+ds/debian/libcoin80t64.install 
> coin3-4.0.2+ds/debian/libcoin80t64.install
> --- coin3-4.0.2+ds/debian/libcoin80t64.install1970-01-01 
> 00:00:00.0 +
> +++ coin3-4.0.2+ds/debian/libcoin80t64.install2023-12-09 
> 15:56:48.0 +
> @@ -0,0 +1 @@
> +usr/lib/*/lib*.so.*
> diff -Nru coin3-4.0.2+ds/debian/libcoin80t64.lintian-overrides 
> coin3-4.0.2+ds/debian/libcoin80t64.lintian-overrides
> --- coin3-4.0.2+ds/debian/libcoin80t64.lintian-overrides  1970-01-01 
> 00:00:00.0 +
> +++ coin3-4.0.2+ds/debian/libcoin80t64.lintian-overrides  2024-02-28 
> 16:46:37.0 +
> @@ -0,0 +1 @@
> +libcoin80t64: package-name-doesnt-match-sonames libcoin80c


-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru coin3-4.0.2+ds/debian/changelog coin3-4.0.2+ds/debian/changelog
--- coin3-4.0.2+ds/debian/changelog 2023-12-09 15:57:42.0 +
+++ coin3-4.0.2+ds/debian/changelog 2024-03-17 21:56:00.0 +
@@ -1,3 +1,18 @@
+coin3 (4.0.2+ds-1.2) unstable; urgency=medium
+
+  * Non-maintainer

Bug#1043098: [Pkg-mailman-hackers] Bug#1043098: python3-django-hyperkitty: tracebacks with update_index_one_list on mailman2 migration

2024-03-17 Thread Pierre-Elliott Bécue

Hello,

Steve Langasek  wrote on 06/08/2023 at 01:10:58+0100:

> Package: python3-django-hyperkitty
> Version: 1.3.4-4
> Severity: important
>
> Dear Maintainer,
>
> Having just upgraded a system to bullseye, I am in the process of migrating
> my mailing lists from the obsolete mailman 2 to mailman3.  Following guides
> such as https://docs.mailman3.org/en/latest/migration.html leads me to run,
> as list:
>
> $ django-admin hyperkitty_import --settings mailman-web \
> --pythonpath /var/lib/mailman3/hyperkitty/ -l $list_email $mbox_path
> $
>
> which succeeds (/var/lib/mailman3/hyperkitty/mailman-web.py is a forked copy
> of /etc/mailman3/mailman-web.py with appropriate permissions).
>
> I am then supposed to run update_index_one_list, which fails with a 
> confusing error about missing templates:
>
> $ django-admin update_index_one_list --settings mailman-web \
> --pythonpath /var/lib/mailman3/hyperkitty/ -l $list_email
> Indexing 421 emails
> [ERROR/MainProcess] Failed indexing 1 - 421 (retry 5/5): 
> search/indexes/hyperkitty/email_text.txt (pid 6818): 
> search/indexes/hyperkitty/email_text.txt
> Traceback (most recent call last):
>   File 
> "/usr/lib/python3/dist-packages/haystack/management/commands/update_index.py",
>  line 111, in do_update
> backend.update(index, current_qs, commit=commit)
>   File "/usr/lib/python3/dist-packages/haystack/backends/whoosh_backend.py", 
> line 269, in update
> doc = index.full_prepare(obj)
>   File "/usr/lib/python3/dist-packages/haystack/indexes.py", line 236, in 
> full_prepare
> self.prepared_data = self.prepare(obj)
>   File "/usr/lib/python3/dist-packages/haystack/indexes.py", line 227, in 
> prepare 
> self.prepared_data[field.index_fieldname] = field.prepare(obj)
>   File "/usr/lib/python3/dist-packages/haystack/fields.py", line 235, in 
> prepare
> return self.convert(super(CharField, self).prepare(obj))
>   File "/usr/lib/python3/dist-packages/haystack/fields.py", line 99, in 
> prepare
> return self.prepare_template(obj)
>   File "/usr/lib/python3/dist-packages/haystack/fields.py", line 212, in 
> prepare_template
> t = loader.select_template(template_names)
>   File "/usr/lib/python3/dist-packages/django/template/loader.py", line 47, 
> in select_template
> raise TemplateDoesNotExist(', '.join(template_name_list), chain=chain)
> django.template.exceptions.TemplateDoesNotExist: 
> search/indexes/hyperkitty/email_text.txt
> Traceback (most recent call last):
>   File "/usr/bin/django-admin", line 5, in 
> management.execute_from_command_line()
>   File "/usr/lib/python3/dist-packages/django/core/management/__init__.py", 
> line 381, in execute_from_command_line
> utility.execute()
>   File "/usr/lib/python3/dist-packages/django/core/management/__init__.py", 
> line 375, in execute
> self.fetch_command(subcommand).run_from_argv(self.argv)
>   File "/usr/lib/python3/dist-packages/django/core/management/base.py", line 
> 323, in run_from_argv
> self.execute(*args, **cmd_options)
>   File "/usr/lib/python3/dist-packages/django/core/management/base.py", line 
> 364, in execute
> output = self.handle(*args, **options)
>   File 
> "/usr/lib/python3/dist-packages/hyperkitty/management/commands/update_index_one_list.py",
>  line 41, in handle
> update_index(listname=options.get("listname")[0],
>   File "/usr/lib/python3/dist-packages/hyperkitty/search_indexes.py", line 
> 117, in update_index
> update_cmd.update_backend("hyperkitty", "default")
>   File 
> "/usr/lib/python3/dist-packages/haystack/management/commands/update_index.py",
>  line 319, in update_backend
> max_pk = do_update(
>   File 
> "/usr/lib/python3/dist-packages/haystack/management/commands/update_index.py",
>  line 111, in do_update
> backend.update(index, current_qs, commit=commit)
>   File "/usr/lib/python3/dist-packages/haystack/backends/whoosh_backend.py", 
> line 269, in update
> doc = index.full_prepare(obj)
>   File "/usr/lib/python3/dist-packages/haystack/indexes.py", line 236, in 
> full_prepare
> self.prepared_data = self.prepare(obj)
>   File "/usr/lib/python3/dist-packages/haystack/indexes.py", line 227, in 
> prepare   
> self.prepared_data[field.index_fieldname] = field.prepare(obj)
>   File "/usr/lib/python3/dist-packages/haystack/fields.py", line 235, in 
> prepare
> return self.convert(super(CharField, self).prepare(obj))
>   File "/usr/lib/python3/dist-packages/haystack/fields.py", line 99, in 
> prepare
> return self.prepare_template(obj)
>   File "/usr/lib/python3/dist-packages/haystack/fields.py", line 212, in 
> prepare_template
> t = loader.select_template(template_names)
>   File "/usr/lib/python3/dist-packages/django/template/loader.py", line 47, 
> in select_template
> raise TemplateDoesNotExist(', '.join(template_name_list), chain=chain)
> django.template.exceptions.TemplateDoesNotExist: 
> search/indexes/hyperkitty/email_text.txt
> $
>
> This is quite confusing, as 
>

Bug#1067065: nmu: gringo_5.6.2-1

2024-03-17 Thread Steve M. Robbins

Package: release.debian.org
Severity: normal
X-Debbugs-Cc: gri...@packages.debian.org
Control: affects -1 + src:gringo
User: release.debian@packages.debian.org
Usertags: binnmu

nmu gringo_5.6.2-1 . ANY . unstable . -m "Rebuild against updated python3.11
for 64-bit time transition"

Bug#1067064: transition: petsc hypre

2024-03-17 Thread Drew Parsons

Package: release.debian.org
Severity: normal
X-Debbugs-Cc: pe...@packages.debian.org, francesco.balla...@unicatt.it
Control: affects -1 + src:petsc
User: release.debian@packages.debian.org
Usertags: transition

The petsc patch for the 64-bit time_t transition was deeply invasive.
It makes petsc (and slepc) essentially unmaintainable.

I think the best way to deal with it is to pretend it never happened
and move on with petsc 3.20, upgrading from petsc 3.19.  We'd want to
doing this upgrade anyway.

As part of this transition I'll also upgrade hypre from 2.28.0 to
2.29.0.

I've checked that sundials and getdp build without problem against the
new petsc. dolfinx, dolfin too.

deal.ii builds but fails tests with a reference to undefined
__gmpn_com symbols. This indicates instructions to link to libgmp
didn't get through.  I think this is unrelated to the petsc upgrade,
and I suspect it might be an artifact of my local installation. i.e. I
suspect the build on buildds will be fine. If necessary we can update
deal.ii to take more care linking GMP.


Ben file:

title = "petsc";
is_affected = .depends ~ "libpetsc*3.19" | .depends ~ "libpetsc*3.20";
is_good = .depends ~ "libpetsc*3.20";
is_bad = .depends ~ "libpetsc*3.19";

Bug#1067063: Fix in experimental

2024-03-17 Thread Thomas Goirand


Hi,

OpenStack Carcal is about to be released, and the fix must be in the 
package in Experimental already.


Cheers,

Thomas Goirand (zigo)

Bug#1064605: [Pkg-rust-maintainers] rustup_1.26.0-5_source.changes ACCEPTED into unstable

2024-03-17 Thread Geert Stappers

On Sun, Mar 17, 2024 at 02:11:37PM +0100, Tobias Frost wrote:
> Debian FTP Masters 
> > 
> > rustup_1.26.0-5.dsc: Refers to non-existing file 'rustup_1.26.0.orig.tar.xz'
> > Perhaps you need to include the file in your upload?
> > 
> > If the orig tarball is missing, the -sa flag for dpkg-buildpackage will be 
> > your friend.
> 
> The problem was the the sponsoree's dsc included a different orig.tar,
> (identical in content, but compressed with xz; If I'd had to guess maybe
> gbp created that one.) 
> 
> I've reuploaded alrady with the one using the one in the archives, so
> this should(tm) appear soon.
> 

Yes, it did.



- Forwarded message from Debian FTP Masters -

Date: Sun, 17 Mar 2024 13:22:35 +
From: Debian FTP Masters 
To: t...@debian.org, Zixing Liu , Debian Rust 
Maintainers 
Subject: [Pkg-rust-maintainers] rustup_1.26.0-5_source.changes ACCEPTED into 
unstable

Thank you for your contribution to Debian.



Accepted:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Sat, 24 Feb 2024 14:34:36 -0700
Source: rustup
Architecture: source
Version: 1.26.0-5
Distribution: unstable
Urgency: medium
Maintainer: Debian Rust Maintainers 

Changed-By: Zixing Liu 
Closes: 1064564
Changes:
 rustup (1.26.0-5) unstable; urgency=medium
 .
   * Team upload.
   * d/debcargo.toml: declare additional conflict packages for:
 - rust-web-clippy
 - rustfmt-web
 - rust-mozilla-gdb
 - rust-mozilla-lldb
 - rust-web-gdb
 - rust-web-lldb
 ... so that users can correctly install rustup when those packages are
 present (by replacing them with rustup). (Closes: #1064564)
   * d/copyright: update copyright years.
   * d/control: update Conflicts using debcargo.
Checksums-Sha1:
 e45316006bb96cac88f9df90024b9cf364ef2651 4019 rustup_1.26.0-5.dsc
 68b311c6b0f2eae7fdaf1e9eed88ca86d2a92ba8 16984 rustup_1.26.0-5.debian.tar.xz
 3533c0a2edbc169d33fc21c26c51b0c01018d94c 24868 rustup_1.26.0-5_amd64.buildinfo
Checksums-Sha256:
 d65d71a09983e527a230711cf806cc3b5bce107c7bc34ec374070a2079155520 4019 
rustup_1.26.0-5.dsc
 799739439acccd871a2bf87a6f0ffb8bd6abd8514aa11d5c2a33ce14e50f9b66 16984 
rustup_1.26.0-5.debian.tar.xz
 18e8e8cfc5a92d468d4b8845c863e7a92583b9c84036fc69e317841dfb6dd969 24868 
rustup_1.26.0-5_amd64.buildinfo
Files:
 3fa90be920ca43511b0ec6911456924b 4019 rust optional rustup_1.26.0-5.dsc
 5077ba37f31ce8f96a41be7aa1e6a5db 16984 rust optional 
rustup_1.26.0-5.debian.tar.xz
 5d61d24cbeb4c2da8cc77d4c3faba955 24868 rust optional 
rustup_1.26.0-5_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEE/d0M/zhkJ3YwohhskWT6HRe9XTYFAmX26Y8ACgkQkWT6HRe9
XTa1eBAAyU6GRradzzHpQMFSaJvxdAVX7Doxy3LGLrb8JD4pZPsgOZnjLw99tXMX
hX8h1Q8/psSWci7ZC7uUf1pI3D7DNgMoOWDe5jcghqmc8m/CnKvq6DsGakKG/6Zb
s+0A67Ah2ML6hmVnQ60LiRlsxADnw2b4YBqyX1+Y9Ifa4ubnHwBxGczwgKw9eFF2
3N12QkZUZKRi9A+CMgckvz8F8gkptLQQDkULDarNXg8PjZ3/qVu4MbGTzh7WjWn5
B9ws0cCd6b4NiKlhI/yq5DrcJx62ar9fJKQwZa9w+4lchqdAkkHn7CcZ9cElOyYJ
ntGL+RFQCGP1+NE+jWEU5OIqBWBzxmv6g1xUl8ioDGf3dvvWyV/zCsiJItn81KNI
+237ttrrzhHgUc63zHtxBqeffDj8J8uAD5NQFxXcDExlA6NDjOnmY/uq0Pea24dY
IwEomAcYcbs/qvTEY0QukkaggwDwAuy5OslxupXJ/yJrDy9TF6NrgGLoTzMnWFJL
j0tEApieKOPQxjoDU1xCqDrbDzkL09otJ0RC+Da117GUwacG6+86qyoNKshmjfYI
6awgteCl9LlTv/jXraTP6S8b3Z9M1NZZFQtBnapV5N5cNiZI+b8iJ0/2al3afIqL
J4GTuj4S4g8Qlc+tMaiUxvQujV9agVLdzl1YE+sb7mE33Gxz1BI=
=HpE8
-END PGP SIGNATURE-




___
Pkg-rust-maintainers mailing list
pkg-rust-maintain...@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-rust-maintainers


- End forwarded message -

Thanks!
 

Groeten
Geert Stappers
-- 
Silence is hard to parse

Bug#1065879: openvpn: protocol configs have contradictory and confusing meanings in the man page + broken link + links to walled gardens

2024-03-17 Thread Bernhard Schmidt

Hi,

Many of the man page URLs link into an access-restricted walled
garden. E.g. all openvpn.net links go to a Cloudflare site that is not
open to all people. It’s an injustice for a Debian man page to refer
users to exclusive resources that may exclude them. This is perhaps
something that should be fixed in the Debian version as the upstream
project has no duty to the users. Debian has a quality standard as
well as a social contract and users to give equitable treatment
to. Therefore IMO the Debian project should remove the
access-restricted links from the man page and ideally replace them
with openly accessible links. The most convenient way to do that would
be to find mirrored versions of the pages in the Wayback Machine.

This one-liner would perhaps do the job well enough:

sed -e
'/http.*.openvpn.net/s@https://\([[:alnum:].]*openvpn.net\)@https://web.archive.org/web/\1@'

ietf.org has the same problem.

For this, while I share your concerns about the unmindful use of
Cloudflare reverse proxy for basically everything I don't agree to call
this a "walled garden". Certainly not enough to call the mentioning of
an URL that just _now_ happens to be "protected" by Cloudflare a policy
violation (or social contract violation) and alter the URLs to
web.archive.org, which to my experience is broken quite often, dog-slow
and not necessarily up-to-date. I think this would be more of a disservice.

Most of the interesting content should be in the manpage and in
/usr/share/doc/packages/openvpn anyway.

If you have concerns about the use of Cloudflare, please raise this
upstream. I know there are some devs sensitive to these concerns listening.

Bernhard

Bug#1064165: lam: NMU diff for 64-bit time_t transition

Unfortunately, the lam source package has a debian/shlibs.local file which
resulted in incorrect internal dependencies between binary packages built
from this source.

The debian/shlibs.local is actually incorrect (it is more lax than the
public one) so the correct fix here is to drop it.

Attached is a full NMU debdiff for -7.2 which I am uploading now.

On Sat, Feb 17, 2024 at 10:27:54PM +, Steve Langasek wrote:
> Source: lam
> Version: 7.1.4-7
> Severity: important
> Tags: patch pending sid trixie
> User: debian-...@lists.debian.org
> Usertags: time-t
> 
> NOTICE: these changes must not be uploaded to unstable yet!
> 
> Dear maintainer,
> 
> As part of the 64-bit time_t transition required to support 32-bit
> architectures in 2038 and beyond
> (https://wiki.debian.org/ReleaseGoals/64bit-time), we have identified
> lam as a source package shipping runtime libraries whose ABI
> either is affected by the change in size of time_t, or could not be
> analyzed via abi-compliance-checker (and therefore to be on the safe
> side we assume is affected).
> 
> To ensure that inconsistent combinations of libraries with their
> reverse-dependencies are never installed together, it is necessary to
> have a library transition, which is most easily done by renaming the
> runtime library package.
> 
> Since turning on 64-bit time_t is being handled centrally through a change
> to the default dpkg-buildflags (https://bugs.debian.org/1037136), it is
> important that libraries affected by this ABI change all be uploaded close
> together in time.  Therefore I have prepared a 0-day NMU for lam
> which will initially be uploaded to experimental if possible, then to
> unstable after packages have cleared binary NEW.
> 
> Please find the patch for this NMU attached.
> 
> If you have any concerns about this patch, please reach out ASAP.  Although
> this package will be uploaded to experimental immediately, there will be a
> period of several days before we begin uploads to unstable; so if information
> becomes available that your package should not be included in the transition,
> there is time for us to amend the planned uploads.
> 
> 
> 
> -- System Information:
> Debian Release: trixie/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 
> 'experimental')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 6.5.0-14-generic (SMP w/12 CPU threads; PREEMPT)
> Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
> Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)

> diff -Nru lam-7.1.4/debian/changelog lam-7.1.4/debian/changelog
> --- lam-7.1.4/debian/changelog2021-11-06 14:23:49.0 +
> +++ lam-7.1.4/debian/changelog2024-02-17 22:00:52.0 +
> @@ -1,3 +1,10 @@
> +lam (7.1.4-7.1) experimental; urgency=medium
> +
> +  * Non-maintainer upload.
> +  * Rename libraries for 64-bit time_t transition.
> +
> + -- Steve Langasek   Sat, 17 Feb 2024 22:00:52 +
> +
>  lam (7.1.4-7) unstable; urgency=medium
>  
>* --with-romio-flags=-ar_nolocal in two configure runs in debian/rules
> diff -Nru lam-7.1.4/debian/control lam-7.1.4/debian/control
> --- lam-7.1.4/debian/control  2021-11-06 14:22:46.0 +
> +++ lam-7.1.4/debian/control  2024-02-17 22:00:52.0 +
> @@ -21,7 +21,7 @@
>  Package: lam4-dev
>  Section: devel
>  Architecture: any
> -Depends: liblam4 (= ${binary:Version}), libc6-dev,${misc:Depends}
> +Depends: liblam4t64 (= ${binary:Version}), libc6-dev,${misc:Depends}
>  Provides: lam-dev
>  Conflicts: lam-dev,lam,lam1-dev,mpi-doc (<< 1.2.7-4),lam-runtime (<= 7.1.2-2)
>  Replaces: lam-dev,lam,lam1-dev,lam2-dev,lam3-dev,lam-runtime (<= 7.1.2-2)
> @@ -31,16 +31,16 @@
>   .
>   This package provides the development headers and related files.
>  
> -Package: liblam4
> +Package: liblam4t64
>  Section: libs
>  Architecture: any
>  Multi-Arch: same
>  Depends: ${shlibs:Depends},${misc:Depends}
> -Provides: mpi
> +Provides: ${t64:Provides}, mpi
>  Conflicts: lam,lam1,lam4,lam4c2
> -Replaces: lam,lam1,lam4,lam4c2
> +Replaces: liblam4, lam,lam1,lam4,lam4c2
>  Recommends: lam-runtime
> -Breaks: libopenmpi-dev (<< 3.0.1~rc1-2), openmpi-bin (<< 3.0.1~rc1-2), mpich 
> (<< 3.3~a3-2), libmpich-dev (<< 3.3~a3-2)
> +Breaks: liblam4 (<< ${source:Version}), libopenmpi-dev (<< 3.0.1~rc1-2), 
> openmpi-bin (<< 3.0.1~rc1-2), mpich (<< 3.3~a3-2), libmpich-dev (<< 3.3~a3-2)
>  Description: Shared libraries used by LAM parallel programs
>   LAM (Local Area Multicomputer) is an open source implementation of the
>   Message Passing Interface (MPI) standard.
> diff -Nru lam-7.1.4/debian/liblam4.files lam-7.1.4/debian/liblam4.files
> --- lam-7.1.4/debian/liblam4.files2012-04-05 14:02:40.0 +
> +++ lam-7.1.4/debian/liblam4.files1970-01-01 00:00:00.0 +
> @@ -1 +0,0 @@
> -usr/lib/*.so.*
> diff -Nru

Bug#1064726: 0ad: FTBFS: ImportError: cannot import name 'dist' from 'distutils' (/usr/lib/python3.11/distutils/init.py)

2024-03-17 Thread David W. Kennedy


Hi,

I found that adding Build-Depends: python3-distutils solves this 
problem.


The natural question is why did build of 0ad work in the past, but not 
now. I found that python3-distutils was being pulled in only as a side 
effect of one of the dependencies, libsdl2-dev. The build failure is 
caused by the fact that the Debian package of glib2.0 stopped depending 
on python3-distutils as of 23 Jan 2024.


Specifically, libsdl2-dev depends on libibus-1.0-dev, which depends on 
libglib2.0-dev, which depends on libglib2.0-dev-bin, which used to 
depend on python3-distutils, but now depends on python3-packaging. This 
change was made to libglib2.0-dev-bin in version 2.78.3-2 on 23 Jan 
2024.


I've committed the Build-Depends change to Debian Salsa.

Thanks.
--
David W. Kennedy

Bug#1066314: regina-rexx: FTBFS: ./rexxext.c:95:7: error: implicit declaration of function ‘getcallstack’; did you mean ‘popcallstack’? [-Werror=implicit-function-declaration]

2024-03-17 Thread Agustin Martin

El vie, 15 mar 2024 a las 18:57, Agustin Martin
() escribió:
>
> Hi, Lucas and Alen.
>
> While it is easy to fix this particular error (see attached patch,
> from upstream repo), other similar error happens afterwards in my
> tests. The problem is that this package is way behind upstream and I
> think priority is to upgrade to a recent upstream version and then fix
> whatever is left.

Hi, Alen,

Some time ago I played a bit with upgrading regina-rexx to a recent
upstream version. I think I can find that stuff and try again with
last upstream version. In case of success, I would like to push
changes to regina-rexx salsa repo for further inspection. Let me know
your POV.

Regards,

-- 
Agustin

Bug#1065879: openvpn: protocol configs have contradictory and confusing meanings in the man page + broken link + links to walled gardens

2024-03-17 Thread Bernhard Schmidt


Control: tags -1 upstream

Hi,


Users can perhaps experiment to work out which of the various possible
behaviors result, but the man page should be written unambiguously.


I completely agree, but this is not something the Debian OpenVPN 
maintainers can do. Please check the latest version at the upstream 
Github repository https://github.com/OpenVPN/openvpn and file issues 
there, if the issue is still present.


Bernhard

Bug#1067063: OpenSSL.crypto.PKCS12 is removed in pyOpenSSL 24.1.0

Package: octavia-tempest-plugin
Version: 2.4.1-1
Severity: serious
Tags: upstream fixed-upstream

octavia_tempest_plugin/common/cert_utils.py uses OpenSSL.crypto.PKCS12() which
was deprecated since pyOpenSSL 23.3.0 and is removed in 24.1.0 which will soon
be uploaded to Debian.  The issue is fixed upstream at
https://github.com/openstack/octavia-tempest-
plugin/commit/25872b36de18a857b1ef36450980f52c8e08e97d , included in 2.5.0.


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

Kernel: Linux 6.7.9-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.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 octavia-tempest-plugin depends on:
ii  python3 3.11.8-1
pn  python3-barbicanclient  
ii  python3-cryptography41.0.7-5
ii  python3-dateutil2.8.2-3
pn  python3-httpx   
pn  python3-keystoneauth1   
ii  python3-openssl 24.0.0-3
pn  python3-oslo.config 
pn  python3-oslo.log
pn  python3-oslo.serialization  
pn  python3-oslo.utils  
pn  python3-oslotest
ii  python3-pbr 6.0.0-1
ii  python3-requests2.31.0+dfsg-1
pn  python3-tempest 
pn  python3-tenacity
pn  python3-testtools   
pn  tempest 

octavia-tempest-plugin recommends no packages.

octavia-tempest-plugin suggests no packages.

Bug#1067062: OpenSSL.crypto.PKCS12 is removed in pyOpenSSL 24.1.0

Package: salt-common
Version: 3004.1+dfsg-2.2
Severity: serious
Tags: upstream

salt/modules/tls.py uses OpenSSL.crypto.PKCS12 which was deprecated since
pyOpenSSL 23.3.0 and is removed in 24.1.0 which will soon be uploaded to
Debian. The issue is not fixed (or reported) upstream as far as I can see. The
pyOpenSSL changelog suggests "OpenSSL.crypto.PKCS12 may be replaced by the
PKCS#12 APIs in the cryptography package."


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

Kernel: Linux 6.7.9-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.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 salt-common depends on:
ii  iproute2   6.8.0-1
ii  python33.11.8-1
ii  python3-apt2.7.6+b1
ii  python3-dateutil   2.8.2-3
ii  python3-distro 1.9.0-1
ii  python3-jinja2 3.1.3-1
ii  python3-markupsafe 2.1.5-1
ii  python3-msgpack1.0.3-3+b1
ii  python3-pkg-resources  68.1.2-2
ii  python3-psutil 5.9.8-2
ii  python3-pycryptodome   3.20.0+dfsg-1
ii  python3-requests   2.31.0+dfsg-1
ii  python3-yaml   6.0.1-2
pn  python3-zmq

Versions of packages salt-common recommends:
ii  lsb-release   12.0-2
pn  python3-croniter  

Versions of packages salt-common suggests:
ii  python3-mako  1.3.2-1
pn  salt-doc

Bug#1062426: libmstoolkit: NMU diff for 64-bit time_t transition

Unfortunately, the scripting to automatically patch packages for the rename
can't address debian/rules so the hard-coded reference to the library
package name there was missed.  Please find an updated NMU patch for this
issue.  I am uploading this follow-up fix to unstable.

On Thu, Feb 01, 2024 at 10:16:27AM +, Steve Langasek wrote:
> Source: libmstoolkit
> Version: 82-7
> Severity: serious
> Tags: patch pending
> Justification: library ABI skew on upgrade
> User: debian-...@lists.debian.org
> Usertags: time-t
> 
> Dear maintainer,
> 
> As part of the 64-bit time_t transition required to support 32-bit
> architectures in 2038 and beyond
> (https://wiki.debian.org/ReleaseGoals/64bit-time), we have identified
> libmstoolkit as a source package shipping runtime libraries whose ABI
> either is affected by the change in size of time_t, or could not be
> analyzed via abi-compliance-checker (and therefore to be on the safe
> side we assume is affected).
> 
> To ensure that inconsistent combinations of libraries with their
> reverse-dependencies are never installed together, it is necessary to
> have a library transition, which is most easily done by renaming the
> runtime library package.
> 
> Since turning on 64-bit time_t is being handled centrally through a change
> to the default dpkg-buildflags (https://bugs.debian.org/1037136), it is
> important that libraries affected by this ABI change all be uploaded close
> together in time.  Therefore I have prepared a 0-day NMU for libmstoolkit
> which will initially be uploaded to experimental if possible, then to
> unstable after packages have cleared binary NEW.
> 
> Please find the patch for this NMU attached.
> 
> If you have any concerns about this patch, please reach out ASAP.  Although
> this package will be uploaded to experimental immediately, there will be a
> period of several days before we begin uploads to unstable; so if information
> becomes available that your package should not be included in the transition,
> there is time for us to amend the planned uploads.
> 
> 
> 
> -- System Information:
> Debian Release: trixie/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 6.5.0-14-generic (SMP w/12 CPU threads; PREEMPT)
> Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
> Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)

> diff -Nru libmstoolkit-82/debian/changelog libmstoolkit-82/debian/changelog
> --- libmstoolkit-82/debian/changelog  2020-06-16 11:25:37.0 +
> +++ libmstoolkit-82/debian/changelog  2024-02-01 10:15:18.0 +
> @@ -1,3 +1,10 @@
> +libmstoolkit (82-7.1) experimental; urgency=medium
> +
> +  * Non-maintainer upload.
> +  * Rename libraries for 64-bit time_t transition.
> +
> + -- Steve Langasek   Thu, 01 Feb 2024 10:15:18 +
> +
>  libmstoolkit (82-7) unstable; urgency=low
>  
>* Fix the VCS urls to point to the salsa git repos.
> diff -Nru libmstoolkit-82/debian/control libmstoolkit-82/debian/control
> --- libmstoolkit-82/debian/control2020-06-16 11:25:37.0 +
> +++ libmstoolkit-82/debian/control2024-02-01 10:15:18.0 +
> @@ -18,7 +18,7 @@
>  Section: libdevel
>  Architecture: any
>  Depends: ${misc:Depends}, 
> - libmstoolkit82 (= ${binary:Version}),
> + libmstoolkit82t64 (= ${binary:Version}),
>zlib1g-dev (>=1:1.2.8),
>   libsqlite3-dev (>= 3.8.6),
>   libexpat1-dev (>= 2.1.0) 
> @@ -44,7 +44,10 @@
> - Sequential or random-access file reading.
>  
>  
> -Package: libmstoolkit82
> +Package: libmstoolkit82t64
> +Provides: ${t64:Provides}
> +Replaces: libmstoolkit82
> +Breaks: libmstoolkit82 (<< ${source:Version})
>  Architecture: any
>  Depends: ${shlibs:Depends}, 
>   ${misc:Depends}
> @@ -78,7 +81,7 @@
>  Package: libmstoolkit-tools
>  Section: science
>  Architecture: any
> -Depends: libmstoolkit82 (= ${binary:Version}),
> +Depends: libmstoolkit82t64 (= ${binary:Version}),
>   ${shlibs:Depends}, 
>   ${misc:Depends}
>  Description: libraries for manipulating mass spectrometry data - tools
> diff -Nru libmstoolkit-82/debian/libmstoolkit82.dirs 
> libmstoolkit-82/debian/libmstoolkit82.dirs
> --- libmstoolkit-82/debian/libmstoolkit82.dirs2020-06-16 
> 11:25:37.0 +
> +++ libmstoolkit-82/debian/libmstoolkit82.dirs1970-01-01 
> 00:00:00.0 +
> @@ -1 +0,0 @@
> -usr/lib
> diff -Nru libmstoolkit-82/debian/libmstoolkit82.install 
> libmstoolkit-82/debian/libmstoolkit82.install
> --- libmstoolkit-82/debian/libmstoolkit82.install 2020-06-16 
> 11:25:37.0 +
> +++ libmstoolkit-82/debian/libmstoolkit82.install 1970-01-01 
> 00:00:00.0 +
> @@ -1,2 +0,0 @@
> -libmstoolkit.so.82.0.0  usr/lib
>

Bug#1067057: tcpdump: Environment undocumented in the man page, yet the TZ variable has effect on the timezone

2024-03-17 Thread Romain Francoise

tcpdump has no special handling of TZ, it just calls strftime() which
handles TZ as described in strftime(3).

-- 
Romain Francoise 
https://people.debian.org/~rfrancoise/

Bug#1067061: RM: kvirc [armel ppc64el riscv64 s390x] -- RoM; ANAIS; new version needs qtwebengine5-dev

2024-03-17 Thread Andrey Rahmatullin

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: kv...@packages.debian.org
Control: affects -1 + src:kvirc
User: ftp.debian@packages.debian.org
Usertags: remove

AFAICS this is the list of release architectures currently lacking
qtwebengine5-dev. All subpackages are AFAIK leaf packages.

Bug#1067056: libpcap0.8: man page gives incorrect syntax specification for 'proto ICMP'

2024-03-17 Thread Romain Francoise

Hi,

On Sun, Mar 17, 2024 at 7:45 PM  wrote:
> From the pcap-filter man page:
[...]
> > tcp, udp, icmp
> >   Abbreviations for:
> >proto \protocol
[...]
> I was stumped. I could not work out why my usage was syntactically
> incorrect. I had to get support from someone who suggested simply
> removing “proto”. That worked. But according to the man page my
> original attempt should have also worked.

No, the backslash character in the example is significant and you did
not provide it. What you were looking for is either 'icmp', 'ip proto
1' or 'ip proto \icmp' which are equivalent.

'proto \icmp' also works but generates support code for IPv6 as well
which does not really make sense for ICMP and is likely not what you
wanted.

-- 
Romain Francoise 
https://people.debian.org/~rfrancoise/

Bug#1067060: kde-spectacle: Typo in man page, fixed upstream

2024-03-17 Thread Wesley Schwengle

Package: kde-spectacle
Severity: minor
X-Debbugs-Cc: wes...@schwengle.net

Dear Maintainer,

someone on #debian on libera noticed a small typo in the man page. It is fixed
upstream:

https://github.com/KDE/spectacle/commit/992d197d34a0f04ac259e34b2e1e7a821eaff519

Cheers,
Wesley

-- System Information:
Debian Release: 12.5
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'oldstable-security'), (500, 
'stable'), (10, 'oldoldstable'), (10, 'oldstable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-18-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.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 kde-spectacle depends on:
pn  kio   
ii  libc6 2.36-9+deb12u4
pn  libkf5configcore5 
pn  libkf5configgui5  
pn  libkf5configwidgets5  
pn  libkf5coreaddons5 
pn  libkf5dbusaddons5 
pn  libkf5globalaccel-bin 
pn  libkf5globalaccel5
pn  libkf5guiaddons5  
pn  libkf5i18n5   
pn  libkf5kiocore5
pn  libkf5kiogui5 
pn  libkf5kiowidgets5 
pn  libkf5newstuff5   
pn  libkf5notifications5  
pn  libkf5purpose-bin 
pn  libkf5purpose5
pn  libkf5service-bin 
pn  libkf5service5
pn  libkf5waylandclient5  
pn  libkf5widgetsaddons5  
pn  libkf5windowsystem5   
pn  libkf5xmlgui5 
pn  libkimageannotator0   
pn  libqt5core5a  
pn  libqt5dbus5   
pn  libqt5gui5 | libqt5gui5-gles  
pn  libqt5printsupport5   
pn  libqt5widgets5
pn  libqt5x11extras5  
ii  libstdc++612.2.0-14
pn  libxcb-cursor0
pn  libxcb-image0 
pn  libxcb-util1  
ii  libxcb-xfixes01.15-1
ii  libxcb1   1.15-1
pn  qdbus-qt5 

kde-spectacle recommends no packages.

kde-spectacle suggests no packages.

Bug#1067029: closed by Thomas Lange (closing)

2024-03-17 Thread c . buhtz


Dear Thomas,

thanks for your your reply.

My report was not about how to find donation info because I am looking 
for them. My intention was to improve Debian.


I still recommend to add "Donations" as a term to the landing page. 
Doing a text search (CTRL+F) on that page for "Donation" has 0 hits.


IMHO such an info should be obvious and not hidden behind a search 
engine or a "more" button. It is to important.


But I am not the maintainer here. Of course I do accept your decision. I 
simply offered my point of view as a user.


Kind
Christian buhtz

Am 17.03.2024 18:42 schrieb Debian Bug Tracking System:

This is an automatic notification regarding your Bug report
which was filed against the www.debian.org package:

#1067029: www.debian.org: Landing page missing donation information

It has been closed by Thomas Lange .

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 Thomas Lange
 by
replying to this email.

Bug#1067059: ruby-hdfeos5: FTBFS with gcc-14 (-Werror=implicit-function-declaration)

2024-03-17 Thread Bas Couwenberg

Source: ruby-hdfeos5
Version: 1.2-11
Severity: serious
Tags: ftbfs upstream
Justification: makes the package in question unusable or mostly so

Dear Maintainer,

Your package FTBFS in unstable:

 hdfeos5pt_wrap.c: In function ‘sort_data_byte’:
 hdfeos5pt_wrap.c:329:14: error: implicit declaration of function 
‘HE5_PTreadlevelF’; did you mean ‘HE5_PTreadlevel’? 
[-Werror=implicit-function-declaration]
   329 | status = HE5_PTreadlevelF(i_ptid, i_level, o_linkfield, 
H5T_NATIVE_CHAR, o_data_parent);
   |  ^~~~
   |  HE5_PTreadlevel

 
https://buildd.debian.org/status/fetch.php?pkg=ruby-hdfeos5=amd64=1.2-11%2Bb4=1710703222=log

See also: 
https://gcc.gnu.org/gcc-14/porting_to.html#implicit-function-declaration

Kind Regards,

Bas

Bug#1067058: gnuradio b-d's on a shared library which doesn't exist anymore


Package: src:gnuradio
Version: 3.10.9.2-1.1
Severity: serious
Tags: sid trixie ftbfs patch

gnuradio b-d's on a shared library which doesn't exist anymore. Just 
drop it, depend on the -dev packages instead.


patch at
http://launchpadlibrarian.net/719912937/gnuradio_3.10.9.2-1.1build1_3.10.9.2-1.1ubuntu1.diff.gz

Bug#1055771: sysvinit script corrections

2024-03-17 Thread Jonas Smedegaard

Quoting Frank Lienhard (2024-03-17 19:10:43)
> On 17.03.2024 00:55, Jonas Smedegaard wrote:
> > Thanks for the proposed patch.
> > Unfortunately it does not apply to the Debian package.
> First: apologies.
> I seem to have made a mistake during my dist-upgrade and ended up with 
> the old init-script, which makes my provided "patch" logically totally 
> wrong.
> 
> > Please provide a patch against the Debian package (not Devuan).
> which makes this request unnecessary, because the devuan package is 
> identical to the debian package.

Ah, make sense.

No need for apology.

> > Also, nothing else in the Debian packaging messes with the path
> > "$dir/collection-root" - that is left for Radicale itself to handle.
> > Can you please test if adequate to replace the 3 instances of
> > "$dir/collections" with "$dir" instead?
> 
> So the actual needed patch is quite small and more cosmetic, since it 
> works out of the box, just w/o logging. And your suggested adjustment 
> works, too.

Looking again, I don't think my suggested change is sensible after all:
Might fail to work for a totally clean system where the needed paths are
not created yet and assigned appropriate access rights.  I haven't
tested that, just stared a the logic of the code...

> I had a minor problem changing the storage dir.
> All works fine with the defaults storage dir 
> (/var/lib/radicale/collections). When changing it to a different 
> location in the config file, I only got it working, if I do not generate 
> the "storage" part from "filesystem_folder = /path/to/storage" beforehand.
> 
> Otherwise I get a write permission problem.

Yes, it is tricky to get the access rights in order.  I am not in the
mood to try guide you there, as I might very well make mistakes in that,
just remember that it indeed tricky.  I am pretty confident that it
works correctly as it is packaged, and also pretty confident that it is
possible to reconfigure - but then you are on your own about making the
right amount of layers of directories, accessible for the init system
and for the inner code spawned by the daome, without leaking access to
local filesystem users.

So it looks like the only part left of your patch is setting log path in
init script.

I am hesitant doing that: I seem to recall that it requires custom
configuration - that systemd and sysv setups cannot share same default
logging configuration, and I therefore chose to provide a working
default setup only for systemd.

This might actually have changed again with the very newest release of
Radicale that I released earlier today.

It would be helful if you could double-check using newest package and
with *only* the init script change, leaving all other settings at their
defaults and with no prior Radicale-related files created on the system
- and then check if the logging works as intended.

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#1065193: RFS: libhx/4.23-1 [RC] -- C library providing queue, tree, I/O and utility functions

2024-03-17 Thread Tobias Frost

Control: tags -1 moreinfo

On Sun, Mar 17, 2024 at 04:57:54PM +0100, Jörg Frings-Fürst wrote:
> tags 1065193 - moreinfo
> thanks
> 
> Hi Tobias,
> 
> 
> 
> Am Sonntag, dem 17.03.2024 um 14:39 +0100 schrieb Tobias Frost:
> > Hi Jörg,
> > 
> > "debcheckout libhx" still gives me 4.17-1 as head.
> > 
> > After looking at your repo, I think I should point you to DEP-14
> > as a recommended git layout for packaging. 
> > As the branch name indicates you are using per-package-revision
> > branches:
> > IMHO It makes little sense to have one branch per debian package
> > version/revision; (I had a similiar discussion on vzlogger lately,
> > so to avoid repetiions: #1064344#28)
> > 
> > Please clarify how you want to manage the package in git, as
> > this needs to be reflected in d/control's VCS-* fields correctly.
> > (this is now blocking the upload.)
> 
> I have been using Vincent Driessen's branching model and the corresponding git
> extension gitflow-avh for at least 7 years with Debian and for a long time at
> work.
> 
> The default branch is master and development takes place in the develop 
> branch.
> 
> The release candidates are managed in the branch release. The extension
> debian/debian-version is used as a tag during the transfer.
> 
> The master branch always contains the last published executable version to 
> which
> the git tag in debian/control points.
> 
a> The procedure is described in the README.debian.

ok, won't further argue about how to organize your git repo, but I can
only tell the Debian perspective: It is breaking expectations as a
debcheckout libhx does today NOT give me a state that represents the
package in unstable. VCS-Git specifies where the (package)
development is happening [1].

[1] Policy 5.6.26 

But as I am not using the git repo as base for the sponsoring, lets put
that topic to rest.

> > 
> > (The current fields say the package is maintained in the default branch
> > of your repo. I see a debian/ directory there, but that one is missing
> > released (it is at 4.17-1, while unstable is at 4.19-1.1)
> > 
> > The review is based on the .dsc, timestamped on mentors.d.n
> > 2024-03-17 12:00
> > 
> > d/changelog is *STILL* changing history for the 4.19-1 changelog
> > block. (This issue must be fixed before upload.)
> > 
> 
> I think these were artifacts because my changes to the NMU were not adopted. 
> Has
> been corrected.

No it has not. I expect old changelog entries to be *identical* to
the ones that have been uploaded, and they still are not, so I fear
we are talking past each other. Please let me know what you think that
you have fixed, so that we can spot the different expectations.

For my perspective:
This is the diff from debian/changelog from the current
version in the archives and the dsc uploaded to mentors at 2024-03-17 14:45
You are still rewriting history (second hunk of this diff), this hunk
should not exists.

diff -Naur archive/libhx-4.19/debian/changelog 
mentors/libhx-4.23/debian/changelog
--- archive/libhx-4.19/debian/changelog 2024-02-28 13:48:09.0 +0100
+++ mentors/libhx-4.23/debian/changelog 2024-03-17 15:23:31.0 +0100
@@ -1,3 +1,17 @@
+libhx (4.23-1) unstable; urgency=medium
+
+  * New upstream release (Closes: #1064734).
+  * Add debian/.gitignore
+  * Remove not longer needed debian/libhx-dev.lintian-overrides.
+  * Fix debian/libhx32t64.lintian-overrides.
+  * debian/copyright:
+- Add 2024 to myself.
+  * debian/control:
+- Readd BD dpkg-dev (>= 1.22.5).
+  Thanks to Tobias Frost 
+
+ -- Jörg Frings-Fürst   Sun, 17 Mar 2024 15:23:31 +0100
+
 libhx (4.19-1.1) unstable; urgency=medium

   * Non-maintainer upload.
@@ -9,11 +23,8 @@

   * New upstream release.
 - Refresh symbols files.
-  * Remove empty debian/libhx-dev.symbols.
-  * debian/rules:
-- Remove build of libhx-dev.symbols.

- -- Jörg Frings-Fürst   Sun, 17 Dec 2023 14:44:39 +0100
+ -- Jörg Frings-Fürst   Tue, 21 Nov 2023 10:41:07 +0100

 libhx (4.14-1) unstable; urgency=medium

Bug#1064671: yuzu: FTBFS: vulkan_wrapper.cpp:285:12: error: enumeration value ‘VK_ERROR_INVALID_VIDEO_STD_PARAMETERS_KHR’ not handled in switch [-Werror=switch]


I am uploading a NMU to fix this.
Please find the debdiff attached.diff -Nru yuzu-0-1335+ds/debian/changelog yuzu-0-1335+ds/debian/changelog
--- yuzu-0-1335+ds/debian/changelog 2023-11-01 22:22:28.0 +
+++ yuzu-0-1335+ds/debian/changelog 2024-03-17 18:37:24.0 +
@@ -1,3 +1,10 @@
+yuzu (0-1335+ds-1.4) unstable; urgency=medium
+
+  * Non-maintainer upload
+  * Fix build with current vulkan-headers (Closes: #1064671)
+
+ -- Bastian Germann   Sun, 17 Mar 2024 18:37:24 +
+
 yuzu (0-1335+ds-1.3) unstable; urgency=medium
 
   * Non-maintainer upload
diff -Nru yuzu-0-1335+ds/debian/patches/series 
yuzu-0-1335+ds/debian/patches/series
--- yuzu-0-1335+ds/debian/patches/series2023-11-01 22:22:28.0 
+
+++ yuzu-0-1335+ds/debian/patches/series2024-03-17 18:35:09.0 
+
@@ -1,6 +1,7 @@
 update-savecontext-loadcontext.patch
 update-vulkan-headers.patch
 fixes-for-gcc-13.patch
+vulkan-headers.patch
 # Upstreamable patches
 cmake-mbedtls.patch
 #cmake-microprofile.patch
diff -Nru yuzu-0-1335+ds/debian/patches/vulkan-headers.patch 
yuzu-0-1335+ds/debian/patches/vulkan-headers.patch
--- yuzu-0-1335+ds/debian/patches/vulkan-headers.patch  1970-01-01 
00:00:00.0 +
+++ yuzu-0-1335+ds/debian/patches/vulkan-headers.patch  2024-03-17 
18:34:23.0 +
@@ -0,0 +1,25 @@
+Origin: 
https://gitlab.com/suyu-emu/suyu/-/commit/310834aea2fa3293ec30bad9f5f37ac7b5681b26
+From: Jan Beich 
+Date: Wed, 20 Dec 2023 01:07:26 +0100
+Subject: vulkan_common: unbreak build with Vulkan-Headers 1.3.274
+
+src/video_core/vulkan_common/vulkan_wrapper.cpp:293:13: error: enumeration 
value 'VK_ERROR_INVALID_VIDEO_STD_PARAMETERS_KHR' not handled in switch 
[-Werror,-Wswitch]
+switch (result) {
+^~
+---
+ src/video_core/vulkan_common/vulkan_wrapper.cpp | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/src/video_core/vulkan_common/vulkan_wrapper.cpp 
b/src/video_core/vulkan_common/vulkan_wrapper.cpp
+index 70cf14afa9..2f78b8af08 100644
+--- a/src/video_core/vulkan_common/vulkan_wrapper.cpp
 b/src/video_core/vulkan_common/vulkan_wrapper.cpp
+@@ -377,6 +377,8 @@ const char* ToString(VkResult result) noexcept {
+ return "VK_OPERATION_DEFERRED_KHR";
+ case VkResult::VK_OPERATION_NOT_DEFERRED_KHR:
+ return "VK_OPERATION_NOT_DEFERRED_KHR";
++case VkResult::VK_ERROR_INVALID_VIDEO_STD_PARAMETERS_KHR:
++return "VK_ERROR_INVALID_VIDEO_STD_PARAMETERS_KHR";
+ case VkResult::VK_PIPELINE_COMPILE_REQUIRED_EXT:
+ return "VK_PIPELINE_COMPILE_REQUIRED_EXT";
+ case VkResult::VK_RESULT_MAX_ENUM:

Bug#1064231: another fix needed


also needs fixing ...

http://launchpadlibrarian.net/719907211/ogre-1.12_1.12.10+dfsg2-3.1~exp1ubuntu1_1.12.10+dfsg2-3.1~exp1ubuntu2.diff.gz

Bug#1067057: tcpdump: Environment undocumented in the man page, yet the TZ variable has effect on the timezone

2024-03-17 Thread debbug . tcpdump

Package: tcpdump
Version: 4.99.0-2+deb11u1
Severity: minor
Tags: upstream
X-Debbugs-Cc: debbug.tcpd...@sideload.33mail.com

Normally by convention useful environmental variables are documented
in an ENVIRONMENT section of the man page. There is no coverage of any
env vars in the man page. I was trying to work out how to make
timestamps print in terms of the UTC timezone. It’s undocumented. As a
guess, I tried:

  $ env TZ=UTC tcpdump -r session.pcap
 
It worked as expected. Is that because tcpdump reads the TZ variable?
Or does tcpdump make a system call to obtain the time and the system
uses the TZ variable?

If it’s the former, then TZ should be documented in the man page. If
it’s the latter, then it’s unclear to me how to document that but
nonetheless users should be informed somehow.

Along these lines, it’s worth noting that the man page says this:

  “A packet trace that crosses a daylight savings time change will
   give skewed time stamps (the time change is ignored).”

Perhaps a TZ that’s shifted by 12 hours or set to a timezone that does
not honor daylight savings will work around that problem?  If so, the
man page could suggest that.

-- System Information:
Debian Release: 11.5
  APT prefers oldstable-updates
  APT policy: (990, 'oldstable-updates'), (990, 'oldstable-security'), (990, 
'testing'), (990, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages tcpdump depends on:
ii  adduser 3.118
ii  libc6   2.31-13+deb11u5
ii  libpcap0.8  1.10.0-2
ii  libssl1.1   1.1.1n-0+deb11u3

tcpdump recommends no packages.

Versions of packages tcpdump suggests:
ii  apparmor  2.13.6-10

-- no debconf information

Bug#870836: imake generated makefile use deprecated -D_BSD_SOURCE and -D_SVID_SOURCE

2024-03-17 Thread Steve McIntyre

On Sat, Nov 24, 2018 at 02:02:58PM -0800, Bart Massey wrote:
>Hilariously, I just ran into this today when building a program I wrote in
>1987. Thanks huge to Teemu for working out the patch; I have verified that it
>works for me. It would be great if this could be packaged.

Still seeing this over 5 years later. Is there any reason not to do an
upload with the patch here?

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
You raise the blade, you make the change... You re-arrange me 'til I'm sane...

Bug#714549: mini-httpd: literal charset=%s in error pages and directory listings

2024-03-17 Thread Alexander Foken


Dear Maintainer,


I've tried to reproduce the problem in Debian sid, and it still exists. 
I've looked at the source code, and the problem should be easy to fix.


Actually, the "charset=%s" problem are two different, but closely 
related problems.


The entire source code contains "charset=%s" only three times:

(1) In do_file() starting at line 1593, "charset=%s" may be returned by 
figure_mime() into mime_type, it is then passed to 
snprintf(fixed_mime_type, sizeof(fixed_mime_type), mime_type, charset) 
to expand %s to the default charset in fixed_mime_type, and a few lines 
below, fixed_mime_type is passed to add_headers().


This seems to be the way that "charset=%s" was intended to be used.

No problem here.

(2) In do_dir() starting at line 1731, "charset=%s" is directly passed 
to add_headers(), without any call to snprintf().


To me, this looks like a little oversight, I would gess the "charset=%s" 
was added in assuming that add_headers() would expand "%s" (which is 
does not).


Looking up a few lines (line 1678), the generated HTML response sets the 
charset to UTF-8 via a META element, so it makes no sense to use any 
other charset than UTF-8 in do_dir().


So the fix for do_dir() is simple: Replace "charset=%s" with 
"charset=UTF-8" in line 1731.


This actually makes the META element in line 1678 redundant, so the 
entire line 1678 should be removed.


(3) In send_error() a line 2465, add_headers() is againg called with a 
literal "charset=%s", without any call to snprintf().


This seems to be the same little oversight as in do_dir().

send_error() is always called with a fixed title and a fixed error 
message, and except for the call in send_authenticate() line 2431, the 
extra_header parameter is always empty. It is very tempting to just use 
a hardcoded "charset=UTF-8" as in do_dir(), but send_error() has one 
extra trick: It calls send_error_body(), which in turn calls 
send_error_file to handle custom error pages. They should be encoded in 
the default charset, which may be something else than UTF-8.


So send_error() needs to follow the behaviour of do_file(): Use a buffer 
and snprintf() to expand %s to the default charset. In other words:


Replace  starting at line 2465 ...

    add_headers(s, title, extra_header, "", "text/html; charset=%s", 
(off_t) -1, (time_t) -1);


... with ...

    char fixed_mime_type[500];
    (void) snprintf(
    fixed_mime_type, sizeof(fixed_mime_type), "text/html; 
charset=%s", charset );

    add_headers(
    s, title, extra_header, "", fixed_mime_type, (off_t) -1, 
(time_t) -1 );


... and remove the hardcoded META element emitted by send_error_body() 
in line 2511.



Testing in a default installation of mini-httpd can be done from the shell:

root@debian-sid:~# mkdir -p /var/www/html/directory
root@debian-sid:~# echo -en 'GET /no/such/file HTTP/1.0\r\n\r\n' | nc 
127.0.0.1 80 | grep -i Content-Type

Content-Type: text/html; charset=%s
    
root@debian-sid:~# echo -en 'GET /directory/ HTTP/1.0\r\n\r\n' | nc 
127.0.0.1 80 | grep -i Content-Type

Content-Type: text/html; charset=%s
    
root@debian-sid:~#


Best regards,

Alexander Foken

--

Alexander Foken
mailto:alexan...@foken.de

Bug#1067056: libpcap0.8: man page gives incorrect syntax specification for 'proto ICMP'

2024-03-17 Thread debbug . libpcap0 . 8

Package: libpcap0.8
Version: 1.10.0-2
Severity: normal
Tags: upstream
X-Debbugs-Cc: debbug.libpcap...@sideload.33mail.com

>From the pcap-filter man page:

> proto  proto qualifiers restrict the match to a particular protocol.
>Possible protos are: ether, fddi, tr, wlan, ip, ip6, arp,
>rarp, decnet, tcp and udp.  E.g., `ether src foo', `arp net
>128.3', `tcp port 21', `udp portrange 7000-7009', `wlan addr2
>0:2:3:4:5:6'.  If there is no proto qualifier, all protocols
>consistent with the type are assumed.  E.g., `src foo' means
>`(ip or arp or rarp) src foo' (except the latter is not legal
>syntax), `net bar' means `(ip or arp or rarp) net bar' and
>`port 53' means `(tcp or udp) port 53'.
> …
> 
> proto protocol
>
>   True if the packet is an IPv4 or IPv6 packet of protocol type
>   protocol.  Note that this primitive does not chase the protocol
>   header chain.
>
> tcp, udp, icmp
>   Abbreviations for:
>proto \protocol
>   where protocol is one of the above protocols.

It’s a bit screwy because the “proto” conditional is specified twice
in the man page. The first time it presents a mostly different set of
possible arguments than the 2nd time. When a user searches the man
page for “ICMP” they only see the 2nd syntax spec for “proto”. This
2nd occurance does not supply the BNF for the argument. The very next
paragraph is not intented but appears to list the arguments. A
speed-reading user sees “tcp, udp, icmp” and stops reading. Not that
it matters, because this abbreviation clause seems to suggest “tcp,
udp, icmp” are in fact valid parameters for “proto”. Yet this fails:

  $ tcpdump -Avvv -r session.pcap 'proto icmp'
  reading from file session.pcap, link-type LINUX_SLL2 (Linux cooked v2), 
snapshot length 262144
  Warning: interface names might be incorrect
  tcpdump: can't parse filter expression: syntax error

I was stumped. I could not work out why my usage was syntactically
incorrect. I had to get support from someone who suggested simply
removing “proto”. That worked. But according to the man page my
original attempt should have also worked.

-- System Information:
Debian Release: 11.5
  APT prefers oldstable-updates
  APT policy: (990, 'oldstable-updates'), (990, 'oldstable-security'), (990, 
'testing'), (990, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages libpcap0.8 depends on:
ii  libc62.31-13+deb11u5
ii  libdbus-1-3  1.12.24-0+deb11u1

libpcap0.8 recommends no packages.

libpcap0.8 suggests no packages.

-- no debconf information

Bug#1061866: reopen, wrong shlibs.local file


Control: reopen -1

reopen, wrong shlibs.local file

patch at
http://launchpadlibrarian.net/719903241/adns_1.6.0-2.1ubuntu1_1.6.0-2.1ubuntu2.diff.gz

Bug#1066281: libdbi-drivers: FTBFS: src/unit.c:229:5: error: implicit declaration of function ‘wait’; did you mean ‘want’? [-Werror=implicit-function-declaration]

Package: libdbi-drivers
Version: 0.9.0-11
Followup-For: Bug #1066281
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu noble ubuntu-patch
Control: tags -1 patch

Please find attached a (trivial) patch for this issue.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru libdbi-drivers-0.9.0/debian/control 
libdbi-drivers-0.9.0/debian/control
--- libdbi-drivers-0.9.0/debian/control 2023-01-18 07:10:49.0 -0800
+++ libdbi-drivers-0.9.0/debian/control 2024-03-17 11:28:49.0 -0700
@@ -1,8 +1,7 @@
 Source: libdbi-drivers
 Section: libs
 Priority: optional
-Maintainer: Ubuntu Developers 
-XSBC-Original-Maintainer: Laszlo Boszormenyi (GCS) 
+Maintainer: Laszlo Boszormenyi (GCS) 
 Uploaders: Prach Pongpanich 
 Build-Depends: automake,
debhelper-compat (= 12),
diff -Nru libdbi-drivers-0.9.0/debian/patches/no-implicit-declarations.patch 
libdbi-drivers-0.9.0/debian/patches/no-implicit-declarations.patch
--- libdbi-drivers-0.9.0/debian/patches/no-implicit-declarations.patch  
1969-12-31 16:00:00.0 -0800
+++ libdbi-drivers-0.9.0/debian/patches/no-implicit-declarations.patch  
2024-03-17 11:28:43.0 -0700
@@ -0,0 +1,20 @@
+Description: fix implicit declaration error for wait()
+ 64-bit time_t requires us to be stricter about function declarations.
+ include the missing system header that defines wait().
+Author: Steve Langasek 
+Bug-Debian: https://bugs.debian.org/1066281
+Forwarded: no
+Last-Update: 2024-03-17
+
+Index: libdbi-drivers-0.9.0/tests/cgreen/src/unit.c
+===
+--- libdbi-drivers-0.9.0.orig/tests/cgreen/src/unit.c
 libdbi-drivers-0.9.0/tests/cgreen/src/unit.c
+@@ -9,6 +9,7 @@
+ #include 
+ #include 
+ #include 
++#include 
+ 
+ enum {test_function, test_suite};
+ 
diff -Nru libdbi-drivers-0.9.0/debian/patches/series 
libdbi-drivers-0.9.0/debian/patches/series
--- libdbi-drivers-0.9.0/debian/patches/series  2023-01-18 07:10:47.0 
-0800
+++ libdbi-drivers-0.9.0/debian/patches/series  2024-03-17 11:26:21.0 
-0700
@@ -10,3 +10,4 @@
 test_mysql_date_tz.patch
 mysql-8.0.patch
 no_mariadb_timezone.patch
+no-implicit-declarations.patch

Bug#1067055: openmpi: error: implicit declaration of function 'OPAL_THREAD_ADD_FETCH64'

2024-03-17 Thread Thorsten Glaser

Source: openmpi
Version: 4.1.6-7
Severity: serious
Justification: ftbfs
Tags: ftbfs
Tag: ftbfs
X-Debbugs-Cc: t...@mirbsd.de

[…]
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../../../../../../opal/mca/btl/ofi 
-I../../../../opal/include -I../../../../ompi/include 
-I../../../../oshmem/include 
-I../../../../opal/mca/hwloc/hwloc201/hwloc/include/private/autogen 
-I../../../../opal/mca/hwloc/hwloc201/hwloc/include/hwloc/autogen 
-I../../../../ompi/mpiext/cuda/c -I../../../../../.. -I../../../.. 
-I../../../../../../opal/include -I../../../../../../orte/include 
-I../../../../orte/include -I../../../../../../ompi/include 
-I../../../../../../oshmem/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 
-D_TIME_BITS=64 -Wdate-time -D_FORTIFY_SOURCE=2 -I/usr/local/include 
-I/usr/local/include -DNDEBUG -g -O2 -Werror=implicit-function-declaration 
-ffile-prefix-map=/tmp/buildd/openmpi-4.1.6=. -fstack-protector-strong -Wformat 
-Werror=format-security -O3 -finline-functions -fno-strict-aliasing -c 
../../../../../../opal/mca/btl/ofi/btl_ofi_rdma.c  -fPIC -DPIC -o 
.libs/btl_ofi_rdma.o
In file included from ../../../../../../opal/mca/btl/ofi/btl_ofi_rdma.c:14:
../../../../../../opal/mca/btl/ofi/btl_ofi_rdma.c: In function 
'mca_btl_ofi_get':
../../../../../../opal/mca/btl/ofi/btl_ofi_rdma.h:33:13: error: implicit 
declaration of function 'OPAL_THREAD_ADD_FETCH64'; did you mean 
'OPAL_THREAD_ADD_FETCH32'? [-Werror=implicit-function-declaration]
   33 | OPAL_THREAD_ADD_FETCH64(&(module)->outstanding_rdma, 1);
\
  | ^~~
../../../../../../opal/mca/btl/ofi/btl_ofi_rdma.c:70:5: note: in expansion of 
macro 'MCA_BTL_OFI_NUM_RDMA_INC'
   70 | MCA_BTL_OFI_NUM_RDMA_INC(ofi_btl);
  | ^~~~
../../../../../../opal/mca/btl/ofi/btl_ofi_rdma.c:82:40: warning: cast from 
pointer to integer of different size [-Wpointer-to-int-cast]
   82 | remote_address = (remote_address - (uint64_t) 
remote_handle->base_addr);
  |^
../../../../../../opal/mca/btl/ofi/btl_ofi_rdma.c: In function 
'mca_btl_ofi_put':
../../../../../../opal/mca/btl/ofi/btl_ofi_rdma.c:132:40: warning: cast from 
pointer to integer of different size [-Wpointer-to-int-cast]
  132 | remote_address = (remote_address - (uint64_t) 
remote_handle->base_addr);
  |^
cc1: some warnings being treated as errors
make[4]: *** [Makefile:1946: btl_ofi_rdma.lo] Error 1
make[4]: Leaving directory 
'/tmp/buildd/openmpi-4.1.6/debian/build-gfortran/opal/mca/btl/ofi'

Bug#1067054: Debian 12 - Copy files on USB 3

2024-03-17 Thread pham...@bluewin.ch

Package: kernel
Version: 6.1.76-1 (2024-02-01)
Severity: critical

Bug Description:
Good morning,
I noticed a problem with Debian 12 and USB 3.
When I copy a large volume of data +/- 150 Gb onto a 2.5 inch SSD integrated 
into an external enclosure (Satechi) which has a USB 3 type C socket and this 
enclosure is plugged into a USB 3 A socket on my PC, the copy cuts out after a 
while (+/- 20%), there is a crash. If I use a USB 3 C socket on my PC it seems 
to make the problem worse.
Same thing if I restore a 250 GB disk image, it also crashes.
If I do the same restoration job but on a 2 A USB socket, everything works 
perfectly, except that it takes a lot of time...
If I use an M.2 2280 drive also integrated into an external enclosure with a 
USB 3 type C socket, everything works fine.
If I use an SD card connected to an SD card reader connected via USB 3 to my 
machine it also works perfectly.
Debian and its kernel do not seem to appreciate 2.5 inch SSDs integrated into 
external enclosures with a USB 3 type C socket...
Please try to fix this...
Best regards.

Bug#1055771: sysvinit script corrections

2024-03-17 Thread Frank Lienhard




On 17.03.2024 00:55, Jonas Smedegaard wrote:

Thanks for the proposed patch.
Unfortunately it does not apply to the Debian package.

First: apologies.
I seem to have made a mistake during my dist-upgrade and ended up with 
the old init-script, which makes my provided "patch" logically totally 
wrong.



Please provide a patch against the Debian package (not Devuan).
which makes this request unnecessary, because the devuan package is 
identical to the debian package.


Also, nothing else in the Debian packaging messes with the path
"$dir/collection-root" - that is left for Radicale itself to handle.
Can you please test if adequate to replace the 3 instances of
"$dir/collections" with "$dir" instead?


So the actual needed patch is quite small and more cosmetic, since it 
works out of the box, just w/o logging. And your suggested adjustment 
works, too.


Again, apologies for my f***up.

I had a minor problem changing the storage dir.
All works fine with the defaults storage dir 
(/var/lib/radicale/collections). When changing it to a different 
location in the config file, I only got it working, if I do not generate 
the "storage" part from "filesystem_folder = /path/to/storage" beforehand.


Otherwise I get a write permission problem.--- radicale_orig	2024-03-17 18:39:40.696898778 +0100
+++ radicale	2024-03-17 18:41:25.995228178 +0100
@@ -55,9 +55,9 @@
 			chown $DAEMON_UID:$DAEMON_GID $dir
 			chmod g-w,o-rwx $dir
 			if [ "$CALDIR" = $dir ]; then
-[ -e $dir/collections ] || mkdir -p $dir/collections
-chown $DAEMON_UID:$DAEMON_GID $dir/collections
-chmod g-w,o-rwx $dir/collections
+[ -e $dir ] || mkdir -p $dir
+chown $DAEMON_UID:$DAEMON_GID $dir
+chmod g-w,o-rwx $dir
 			fi
 		fi
 	done
@@ -70,7 +70,7 @@
 	start-stop-daemon --start --quiet --startas $DAEMON \
 		--exec $DAEMON --test > /dev/null \
 		|| return 1
-	start-stop-daemon --start --quiet --startas $DAEMON --background \
+	start-stop-daemon --start --quiet --startas $DAEMON --background --output $LOGDIR/$NAME.log \
 		--exec $DAEMON --umask 0027 --chuid $DAEMON_UID:$DAEMON_GID -- \
 		$RADICALE_OPTS \
 		|| return 2

Bug#1067052: [Pkg-utopia-maintainers] Bug#1067052: network-manager: Wrong priorities for OpenVPN connections

2024-03-17 Thread Evgeny Fishgalov

The problem is that when connected to VPN via Network Manager

a) I can't access the resources of the remote local network;

b) the traffic does not get tunneled over VPN routes.


This problem doesn't appear when connected via sudo openvpn


Here are (anonymised) contents of the .nmconnection file for my VPN
connection in /etc/NetworkManager/system-connections

[connection]
id=korolev
uuid=ANONYMISED-UUID
type=vpn
autoconnect=false

[vpn]
auth=SHA256
ca=/home/eugrus/.cert/nm-openvpn/korolev-ca.pem
cert=/home/eugrus/.cert/nm-openvpn/korolev-cert.pem
cert-pass-flags=0
cipher=AES-128-GCM
connection-type=tls
dev=tun
key=/home/eugrus/.cert/nm-openvpn/korolev-key.pem
remote=ANONYMISED.IP:1194
remote-cert-tls=server
tls-cipher=TLS-ECDHE-ECDSA-WITH-AES-128-GCM-SHA256
tls-crypt=/home/eugrus/.cert/nm-openvpn/korolev-tls-crypt.pem
tls-version-min=1.2
verify-x509-name=name:server_ANONYMISED
service-type=org.freedesktop.NetworkManager.openvpn

[ipv4]
may-fail=false
method=auto

[ipv6]
addr-gen-mode=stable-privacy
may-fail=false
method=auto

[proxy]


On Sun, 17 Mar 2024 18:27:58 +0100 Michael Biebl  wrote:

> Control: tags -1 + moreinfo

>

> Where exactly is the problem?

> Please highlight it explicitly.

> Please also share your NM configuration for the openvpn connection.

>

Bug#1061902: consolekit2: NMU diff for 64-bit time_t transition

The build failure is not caused by this patch.  You have an existing
severity: serious bug open about the build failure:
https://bugs.debian.org/1061493

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Bug#965333: libvirt-daemon-system: Please make a separate package for apparmor profiles

2024-03-17 Thread Mikhail Morfikov


On 17/03/2024 5.18 pm, Andrea Bolognani wrote:

On Wed, Mar 06, 2024 at 08:34:59AM +0100, Mikhail Morfikov wrote:

Take a look for example at the thunderbird email client package. They ship
the apparmor profile for the app in the thunderbird package (I also asked them
to do the move, but no one cared, see #949649 from 23 Jan 2020 -- no one ever
answered).


That bug report looks identical to the one you've filed against
libvirt, so it doesn't provide any additional information.


So I use thunderbird and I have my own separate profile for this app because
I have different rules, aiming different security policy. Each time the
thunderbird package is updated, the apparmor profile is also installed, and
I have no option to forbid that. So the apparmor policy is rewritten, which
requires me to manually remove the newly installed thunderbird profile (the
physical file), remove non exising profiles from apparmor (aa-remove-unknown),
reload my own profile, update initramfs (since I load the apparmor policy during
initramfs phase).


That does indeed sound very annoying.

I wonder why you have to go through that whole process though. The
AppArmor configuration is in /etc, so everything is marked as
conffiles. If you make local customizations, shouldn't you at worst
be prompted to confirm whether you want your changes to be preserved
or overwritten?


It's because of the naming scheme. Some time ago, apparmor changed the naming
scheme from the path (like usr.bin.thunderbird) to just the name of the 
app/binary
(thunderbird). And most of the app still have the old naming.

So as you can see, even when apps have apparmor profiles, no one even cares 
about
having them updated -- this is the main reason I wanted them in separate 
packages.

I have many profiles and all of them have the new naming scheme, and in such
case, apps like thunderbird simply install new files with each update, which I 
have
to remove and do all the stuff I described earlier.




Most of people don't even use apparmor, so they don't care whether the profile 
is
in the core package, or in some app-apparmor-profile package.


I don't think this is a fair assessment: AppArmor is enabled by
default in Debian and has been for several releases, so people *are*
in fact using AppArmor unless they go out of their way to disable it.


Even when it's enabled by default, it doesn't really matter when people don't 
know
what apparmor is and when all profiles are in the complain mode. Try to enforce 
all
of the installed profiles by default and see what happens. :]




The all issues/problems call for a separate apparmor profile packages, but 
someone
has to make that move first, so others would follow. 4 years has passed and no 
one
did this, because no one care, and no one really use apparmor. And I bet no one 
will
make that first step and in the next 4 years the problems will still persist.


Have you raised the topic on a project-wide forum, such as
debian-devel? That would IMO be the best way forward. Convince the
project that AppArmor profiles should be packaged separately, and
make that into a (mini-)policy that is officially adopted.

Opening bug reports against individual packages when no project-wide
consensus has been reached is unlikely to result in much progress.



No I haven't. At that time (several years ago) there were just a couple of apps 
which
were shipping apparmor profiles in the core app package. Since no one really 
answered me
at that time, I just let it go because I had the feeling that no one really 
cares of
such thing like apparmor, so I stopped asking people and simply got over it.

Bug#988730: CVE-2017-18641

2024-03-17 Thread Mathias Gibbens

On Sun, 2024-01-28 at 08:44 +0100, Salvatore Bonaccorso wrote:
> Thanks for the update. Do you know of any plans of making
> distrobuilder available?

  distrobuilder is now available in both testing and unstable. I'll be
reaching out to some of the users of lxc-templates to let them know and
suggesting that they migrate to using distrobuilder.

Mathias

signature.asc
Description: This is a digitally signed message part

Bug#1066485: [Debian-med-packaging] Bug#1066485: volpack: diff for NMU version 1.0b3-9.1

2024-03-17 Thread Étienne Mollier

Hi Andrey,

Andrey Rakhmatullin, on 2024-03-17:
> I've prepared an NMU for volpack (versioned as 1.0b3-9.1) and
> uploaded it to DELAYED/4. Please feel free to tell me if I
> should delay it longer.

Thank you for helping out with tackling these bugs, I reviewed
through your changes, with which I agree, and inlined them in
the VCS, so they will be preserved on further uploads.  Please
feel even free to reduce the delay to 0, if you like.

Have a nice day,  :)
-- 
  .''`.  Étienne Mollier 
 : :' :  pgp: 8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
 `. `'   sent from /dev/pts/4, please excuse my verbosity
   `-on air: Jean-Luc Ponty - Upon The Wings Of Music


signature.asc
Description: PGP signature

Bug#1067053: qa.debian.org: Documented policy needed for bug archival + archival transparency needed

2024-03-17 Thread debbug . qa . debian . org

Package: qa.debian.org
Severity: normal
X-Debbugs-Cc: debbug.qa.debian@sideload.33mail.com
Control: affects -1 +www.debian.org

There are essentially no documented policies or procedures for bug
report archival. The only disclosure on the website is here:

  https://www.debian.org/Bugs/server-control#unarchive

It’s so minimal I will just copy it here:

> archive bugnumber
> 
>   Archives a bug that had been archived at some point in the past but
>   is currently not archived if the bug fulfills the requirements for
>   archival, ignoring time.
> 
> unarchive bugnumber
> 
>   Unarchives a bug that was previously archived. Unarchival should
>   generally be coupled with reopen and found/fixed as
>   appropriate. Bugs that have been unarchived can be archived using
>   archive assuming the non-time based archival requirements are
>   met. You should not be using unarchive to make trivial changes to
>   archived bugs, such as changing the submitter; its primary purpose
>   is to allow for the reopening of bugs which have been archived
>   without the intervention of BTS administrators.

That’s it. There is no further guidance in the www.debian.org/Bugs/*
tree. It seems to say artificial archival can only be requested on
bugs that were previously archived. Yet there are bugs that have been
archived just 1 month after opening. This indicates undisclosed /
non-transparent procedures are in play. Then it says unarchival should
only be requested on naturally archived bugs (due to aging). Should
that “policy” be revisited?

Is archival a synonym for bug closure?  What are the reasons a bug
report can or should be artificially archived by intervention?

The Debian Social Contract (DSC) has a transparency clause:

> 3. We will not hide problems
>
>We will keep our entire bug report database open for public view
>at all times. Reports that people file online will promptly
>become visible to others.

That’s a good start but IMO it would improve quality if that were to
go a step further and (by extension) state that open public
/discussion/ of problems will also be facilitated.

The archival of a bug report has the speech/idea-chilling effect of
closing it and blocking further discussion.

This bug report is motivated by another. I thought of a new feature
that would improve the reportbug application. A search of bug reports
showed that someone already put forward the same idea (bug
1002906). There’s more to say on that, so I responded. My contribution
was suppressed because the bug was archived. In fact it was archived
just a month or so after it was opened.

Big transparency problem: even the verbose view of the bug report
showing extraneous control messages gives no indication of /how/ or
/why/ the bug was archived, or /who/ initiated it. We can only guess
that based on the very short timeframe open that it was archived by
intervention. Which means requesting unarchival goes against what I
quoted from the server control page.

I don’t imagine that whoever initiated the archival actually intended
to suppress the discussion. It was likely maintainers looking to get
the bug report out of their view (out of sight, out of mind) for
organizational reasons. But since archival has the effect of
suppressing discussion, it’s not a proper mechanism for that.

** Proposal **

I propose several actions to remedy all this.

① Revision to the DSC to include public discourse w.r.t bug reports.

② Drafting a clear and comprehensive policy informing everyone as to
proper and improper usage of bug archival and unarchival. Adapt
Bugs/server-control#unarchive as needed.

③ Modify the BTS as needed to include basic archival information in
the public views of bug reports, such as:

  * who initiated the archival

  * why it was archived (age or intervention; and if intervention then
the rationale for the intervention)

④ Reopen bug 1002906 if it’s deemed to have been archived without good
cause.

Bug#1067052: [Pkg-utopia-maintainers] Bug#1067052: network-manager: Wrong priorities for OpenVPN connections

2024-03-17 Thread Michael Biebl


Control: tags -1 + moreinfo

Where exactly is the problem?
Please highlight it explicitly.
Please also share your NM configuration for the openvpn connection.

Am 17.03.2024 um 18:18 schrieb Evgeny Fishgalov:


eugrus@eugensdebianpc:~$ ip route # without VPN
default via 192.168.178.1 dev enp0s25
default via 192.168.178.1 dev enp0s25 proto dhcp src 192.168.178.25 
metric 100
10.0.3.0/24  dev lxcbr0 proto kernel scope link src 
10.0.3.1 linkdown

169.254.0.0/16  dev enp0s25 scope link metric 1000
192.168.178.0/24  dev enp0s25 proto kernel 
scope link src 192.168.178.25
192.168.178.0/24  dev enp0s25 proto kernel 
scope link src 192.168.178.25 metric

100
192.168.178.1 dev enp0s25 scope link
eugrus@eugensdebianpc:~$ ip route # VPN established from Network Manager
default via 192.168.178.1 dev enp0s25
default via 10.8.0.1 dev tun0 proto static metric 50
default via 192.168.178.1 dev enp0s25 proto dhcp src 192.168.178.25 
metric 100
10.0.3.0/24  dev lxcbr0 proto kernel scope link src 
10.0.3.1 linkdown
10.8.0.0/24  dev tun0 proto kernel scope link src 
10.8.0.2 metric 50

94.198.134.88 via 192.168.178.1 dev enp0s25 proto static metric 50
169.254.0.0/16  dev enp0s25 scope link metric 1000
192.168.178.0/24  dev enp0s25 proto kernel 
scope link src 192.168.178.25
192.168.178.0/24  dev enp0s25 proto kernel 
scope link src 192.168.178.25 metric

100
192.168.178.1 dev enp0s25 scope link
192.168.178.1 dev enp0s25 proto static scope link metric 50
eugrus@eugensdebianpc:~$ ip route # VPN established with sudo openvpn
0.0.0.0/1  via 10.8.0.1 dev tun0
default via 192.168.178.1 dev enp0s25
default via 192.168.178.1 dev enp0s25 proto dhcp src 192.168.178.25 
metric 100
10.0.3.0/24  dev lxcbr0 proto kernel scope link src 
10.0.3.1 linkdown
10.8.0.0/24  dev tun0 proto kernel scope link src 
10.8.0.2

94.198.134.88 via 192.168.178.1 dev enp0s25
128.0.0.0/1  via 10.8.0.1 dev tun0
169.254.0.0/16  dev enp0s25 scope link metric 1000
192.168.178.0/24  dev enp0s25 proto kernel 
scope link src 192.168.178.25
192.168.178.0/24  dev enp0s25 proto kernel 
scope link src 192.168.178.25 metric

100
192.168.178.1 dev enp0s25 scope link

Kind regards,
Evgeny Fishgalov


-- System Information:
Debian Release: 12.5
   APT prefers stable-updates
   APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'stable')

Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.1.0-17-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8), 
LANGUAGE=ru_RU:ru

Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages network-manager depends on:
ii  adduser                         3.134
ii  dbus [default-dbus-system-bus]  1.14.10-1~deb12u1
ii  libaudit1                       1:3.0.9-1
ii  libbluetooth3                   5.66-1+deb12u1
ii  libc6                           2.36-9+deb12u4
ii  libcurl3-gnutls                 7.88.1-10+deb12u5
ii  libglib2.0-0                    2.74.6-2
ii  libgnutls30                     3.7.9-2+deb12u2
ii  libjansson4                     2.14-2
ii  libmm-glib0                     1.20.4-1
ii  libndp0                         1.8-1
ii  libnewt0.52                     0.52.23-1+b1
ii  libnm0                          1.42.4-1
ii  libpsl5                         0.21.2-1
ii  libreadline8                    8.2-1.3
ii  libselinux1                     3.4-1+b6
ii  libsystemd0                     252.22-1~deb12u1
ii  libteamdctl0                    1.31-1
ii  libudev1                        252.22-1~deb12u1
ii  policykit-1                     122-3
ii  polkitd                         122-3
ii  udev                            252.22-1~deb12u1

Versions of packages network-manager recommends:
ii  dnsmasq-base [dnsmasq-base]  2.89-1
ii  libpam-systemd               252.22-1~deb12u1
ii  modemmanager                 1.20.4-1
ii  ppp                          2.4.9-1+1.1+b1
ii  wireless-regdb               2022.06.06-1
ii  wpasupplicant                2:2.10-12

Versions of packages network-manager suggests:
ii  iptables       1.8.9-2
pn  libteam-utils  

Versions of packages network-manager is related to:
ii  isc-dhcp-client  4.4.3-P1-2

-- no debconf information

___
Pkg-utopia-maintainers mailing list
pkg-utopia-maintain...@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-utopia-maintainers




OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1067052: network-manager: Wrong priorities for OpenVPN connections

2024-03-17 Thread Evgeny Fishgalov

Package: network-manager
Version: 1.42.4-1
Severity: normal
X-Debbugs-Cc: evg...@fishgalov.com

Dear Maintainer,

Differently from VPN-connections established from console via sudo openvpn,
the
ones established via Network Manager have lower priority than the wired
connection. This leads to VPN-connections established via Network Manager
not
being used.

To illustrate that, here are the listings of my routes without VPN, with a
VPN-
connection established via Network Manager and with a VPN-connection
established via sudo openvpn:

eugrus@eugensdebianpc:~$ ip route # without VPN
default via 192.168.178.1 dev enp0s25
default via 192.168.178.1 dev enp0s25 proto dhcp src 192.168.178.25 metric
100
10.0.3.0/24 dev lxcbr0 proto kernel scope link src 10.0.3.1 linkdown
169.254.0.0/16 dev enp0s25 scope link metric 1000
192.168.178.0/24 dev enp0s25 proto kernel scope link src 192.168.178.25
192.168.178.0/24 dev enp0s25 proto kernel scope link src 192.168.178.25
metric
100
192.168.178.1 dev enp0s25 scope link
eugrus@eugensdebianpc:~$ ip route # VPN established from Network Manager
default via 192.168.178.1 dev enp0s25
default via 10.8.0.1 dev tun0 proto static metric 50
default via 192.168.178.1 dev enp0s25 proto dhcp src 192.168.178.25 metric
100
10.0.3.0/24 dev lxcbr0 proto kernel scope link src 10.0.3.1 linkdown
10.8.0.0/24 dev tun0 proto kernel scope link src 10.8.0.2 metric 50
94.198.134.88 via 192.168.178.1 dev enp0s25 proto static metric 50
169.254.0.0/16 dev enp0s25 scope link metric 1000
192.168.178.0/24 dev enp0s25 proto kernel scope link src 192.168.178.25
192.168.178.0/24 dev enp0s25 proto kernel scope link src 192.168.178.25
metric
100
192.168.178.1 dev enp0s25 scope link
192.168.178.1 dev enp0s25 proto static scope link metric 50
eugrus@eugensdebianpc:~$ ip route # VPN established with sudo openvpn
0.0.0.0/1 via 10.8.0.1 dev tun0
default via 192.168.178.1 dev enp0s25
default via 192.168.178.1 dev enp0s25 proto dhcp src 192.168.178.25 metric
100
10.0.3.0/24 dev lxcbr0 proto kernel scope link src 10.0.3.1 linkdown
10.8.0.0/24 dev tun0 proto kernel scope link src 10.8.0.2
94.198.134.88 via 192.168.178.1 dev enp0s25
128.0.0.0/1 via 10.8.0.1 dev tun0
169.254.0.0/16 dev enp0s25 scope link metric 1000
192.168.178.0/24 dev enp0s25 proto kernel scope link src 192.168.178.25
192.168.178.0/24 dev enp0s25 proto kernel scope link src 192.168.178.25
metric
100
192.168.178.1 dev enp0s25 scope link

Kind regards,
Evgeny Fishgalov


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

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

Versions of packages network-manager depends on:
ii  adduser 3.134
ii  dbus [default-dbus-system-bus]  1.14.10-1~deb12u1
ii  libaudit1   1:3.0.9-1
ii  libbluetooth3   5.66-1+deb12u1
ii  libc6   2.36-9+deb12u4
ii  libcurl3-gnutls 7.88.1-10+deb12u5
ii  libglib2.0-02.74.6-2
ii  libgnutls30 3.7.9-2+deb12u2
ii  libjansson4 2.14-2
ii  libmm-glib0 1.20.4-1
ii  libndp0 1.8-1
ii  libnewt0.52 0.52.23-1+b1
ii  libnm0  1.42.4-1
ii  libpsl5 0.21.2-1
ii  libreadline88.2-1.3
ii  libselinux1 3.4-1+b6
ii  libsystemd0 252.22-1~deb12u1
ii  libteamdctl01.31-1
ii  libudev1252.22-1~deb12u1
ii  policykit-1 122-3
ii  polkitd 122-3
ii  udev252.22-1~deb12u1

Versions of packages network-manager recommends:
ii  dnsmasq-base [dnsmasq-base]  2.89-1
ii  libpam-systemd   252.22-1~deb12u1
ii  modemmanager 1.20.4-1
ii  ppp  2.4.9-1+1.1+b1
ii  wireless-regdb   2022.06.06-1
ii  wpasupplicant2:2.10-12

Versions of packages network-manager suggests:
ii  iptables   1.8.9-2
pn  libteam-utils  

Versions of packages network-manager is related to:
ii  isc-dhcp-client  4.4.3-P1-2

-- no debconf information

Bug#1067051: python3-fs: Switch from appdirs to platformdirs

2024-03-17 Thread Scott Kitterman

Package: python3-fs
Version: 2.4.16-2
Severity: important

Python3-fs uses python3-appdirs, which is dead upstream.  It is being
replaced by python3-platformdirs.  As a maintainer of appdirs, I would
prefer that we do not release Trixie with appdirs.  As far as I can
tell, python3-fs is the only critical package that uses it, so if
python3-fs were ported to platformdirs, it could be removed.

I investigated and it's more than just s/appdirs/platformdirs// for some
reason (mostly that is all that's needed to port to platformdirs).
Upstream for fs looks pretty dead, so it may be a long wait for an
upstream solution.

Scott K

Bug#1067050: ITP: ultimateultimateguitar -- CLI for the ultimateguitar website

2024-03-17 Thread Salvo Tomaselli

Package: wnpp
Severity: wishlist
Owner: Salvo Tomaselli 
X-Debbugs-Cc: debian-de...@lists.debian.org, ltw...@debian.org

* Package name: ultimateultimateguitar
  Version : 1.4
  Upstream Contact: Salvo Tomaselli 
* URL : https://codeberg.org/ltworf/ultimateultimateguitar
* License : AGPL
  Programming Lang: Python
  Description : CLI for the ultimateguitar website

It is a CLI to search songs on ultimateuguitar website, parse their format
and output the text and chords on the terminal.

It has support for transpose.

It can be useful to hobby musicians such as myself to avoid all the spam that
the website contains when accessed from a browser.

I plan to maintain it alone, on the same repository where the project is hosted.

I'm happy to add people to the project if they want to help out.

Bug#1007589: mhonarc: please consider upgrading to 3.0 source format


I am uploading a NMU to DELAYED/10 in order to fix this.
The debdiff is included.diff -Nru mhonarc-2.6.19/debian/changelog mhonarc-2.6.19/debian/changelog
--- mhonarc-2.6.19/debian/changelog 2024-03-17 16:59:20.0 +
+++ mhonarc-2.6.19/debian/changelog 2024-03-17 16:50:37.0 +
@@ -1,3 +1,11 @@
+mhonarc (2.6.19-2.3) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Convert to source format 3.0. (closes: #1007589)
+  * d/copyright: Convert to machine-readable format.
+
+ -- Bastian Germann   Sun, 17 Mar 2024 16:50:37 +
+
 mhonarc (2.6.19-2.2) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru mhonarc-2.6.19/debian/copyright mhonarc-2.6.19/debian/copyright
--- mhonarc-2.6.19/debian/copyright 2024-03-17 16:59:20.0 +
+++ mhonarc-2.6.19/debian/copyright 2024-03-17 16:50:37.0 +
@@ -1,13 +1,25 @@
-This package was first debianized by Michael Alan Dorman
- and is now maintained by others.
+Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
+Comment:
+ This package was first debianized by Michael Alan Dorman
+  and is now maintained by others.
+Source:
+ http://www.mhonarc.org/
+Upstream-Contact:
+ Earl Hood 
 
-It was downloaded from: http://www.mhonarc.org/
-
-Upstream author: Earl Hood 
-
-This software is copyright 1995-2001, Earl Hood, mhon...@mhonarc.org
-
-You are free to distribute this software under the terms of
-the GNU General Public License.
-On Debian systems, the complete text of the GNU General Public
-License can be found in /usr/share/common-licenses/GPL file.
+Files: *
+Copyright:
+ This software is copyright 1995-2001, Earl Hood, mhon...@mhonarc.org
+License: GPL-2+
+ This program is free software; you can redistribute it and/or modify
+ it under the terms of the GNU General Public License as published by
+ the Free Software Foundation; either version 2 of the License, or
+ (at your option) any later version.
+ .
+ This program is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ GNU General Public License for more details.
+Comment:
+ On Debian systems, the complete text of the GNU General Public
+ License version 2 can be found in /usr/share/common-licenses/GPL-2 file.
diff -Nru mhonarc-2.6.19/debian/patches/debian.patch 
mhonarc-2.6.19/debian/patches/debian.patch
--- mhonarc-2.6.19/debian/patches/debian.patch  1970-01-01 00:00:00.0 
+
+++ mhonarc-2.6.19/debian/patches/debian.patch  2024-03-17 16:50:37.0 
+
@@ -0,0 +1,63 @@
+--- mhonarc-2.6.19.orig/install.me
 mhonarc-2.6.19/install.me
+@@ -255,6 +255,7 @@ my $Root   = '';
+  noman
+  perl=s
+  prefix=s
++ instprefix=s
+ 
+  help));
+ 
+@@ -430,6 +431,10 @@ my $Root  = '';
+ my $plprefix  = "#!$OptValues{'perl'}\n";
+$plprefix .= "use lib qw($OptValues{'libpath'});\n"
+   if $OptValues{'libpath'};
++$OptValues{'instprefix'} and $OptValues{'binpath'} = join ('', 
$OptValues{'instprefix'}, $OptValues{'binpath'});
++$OptValues{'instprefix'} and $OptValues{'libpath'} = join ('', 
$OptValues{'instprefix'}, $OptValues{'libpath'});
++$OptValues{'instprefix'} and $OptValues{'docpath'} = join ('', 
$OptValues{'instprefix'}, $OptValues{'docpath'});
++$OptValues{'instprefix'} and $OptValues{'manpath'} = join ('', 
$OptValues{'instprefix'}, $OptValues{'manpath'});
+ my($file, $destfile);
+ if ($dobin) {
+   print STDOUT qq(Installing programs to "$OptValues{'binpath'}":\n);
+--- mhonarc-2.6.19.orig/lib/mhamain.pl
 mhonarc-2.6.19/lib/mhamain.pl
+@@ -1565,7 +1565,7 @@ sub signal_catch {
+ ##
+ sub defineIndex2MsgId {
+ no warnings qw(deprecated);
+-if (!defined(%Index2MsgId)) {
++unless (%Index2MsgId) {
+   foreach (keys %MsgId) {
+   $Index2MsgId{$MsgId{$_}} = $_;
+   }
+--- mhonarc-2.6.19.orig/lib/mhmimetypes.pl
 mhonarc-2.6.19/lib/mhmimetypes.pl
+@@ -48,6 +48,7 @@ $UnknownExt = 'bin';
+ 'application/ms-powerpoint',  'ppt:MS-Powerpoint presentation',
+ 'application/ms-project', 'mpp:MS-Project file',
+ 'application/msword', 'doc:MS-Word document',
++
'application/vnd.openxmlformats-officedocument.wordprocessingml.document',  
  'docx:MS-Word 2007 document',
+ 'application/octet-stream',   'bin:Binary data',
+ 'application/oda','oda:ODA file',
+ 'application/pdf','pdf:Adobe PDF document',
+@@ -71,7 +72,9 @@ $UnknownExt = 'bin';
+ 'application/vnd.lotus-wordpro','lwp,sam:Lotus WordPro',
+ 'application/vnd.mif','mif:Frame MIF document',
+ 'application/vnd.ms-excel', 'xls:MS-Excel spreadsheet',
++'application/vnd.openxmlformats-officedocument.spreadsheetml.sheet',

Bug#1067049: rust-smallvec: please update to v1.13.1

2024-03-17 Thread Jonas Smedegaard

Source: rust-smallvec
Version: 1.11.2-1
Severity: normal
Tags: upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please update to to at least v1.13.1.

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmX3I34ACgkQLHwxRsGg
ASEqRQ//d418N0hRBYKFYyDSf7sh+c1NC9rtyulHu2xVRvmIkAW2dC0wVWPS/rT9
eBcUAoA7y052ni9z8pwr35lWIsKWho9JF78OGhH7SM9Dn9VITpEBBeTrGcG/Qkyi
sBPwV8t91gr2hoFVcpEz+W35sILdHSl4fa90E6Toq2on48FpMp4VvdrvIVuC/R/T
D533UGfhdS758zg2sJtzSH5BZ73G+Qvh2QTPv2tuS+JRPc1hsDTxIuF73BS0eMna
+bt6/1dEuCd2Mg8XIhfyitpkpVMNRmQsDXrhbqULcvPDKdDJ0YeV44HpenZLkSSb
Wcg6uma1ayNEN/ouy68y9ed5j1snAFqv4Nb4jXK0HKzs6O7RXr1LloyEkx+gvxK5
y4RA4pOIoNwb3EEO2m7PcpLRM/s32+sDXibGx5Bf9BBIkUxX8wjSN/dEZ8CDTGNd
D/WhYnZU5mnAQi1/LvS8SHe6hxFsypSRb37WGUgX7AwwI1wvI378EOy9esgEkBaC
MiIUjOhc+diFE7ii4ZkRGyqYFG9Aid9HH44ECC0R7fHnNq+Tv1iL3NbnoA4OHu7K
aXjwMA5Z6I7EvbfC09hxLLqcf9ro8FskwESCqVMB6yk4ySDQXSjvLQyHt7x7Yzaz
KIGUcN1pM2H+AJkozOOeLDvVZ9RM4T6FkGt3jg1lLKOK6wBSOnw=
=b+Cx
-END PGP SIGNATURE-

Bug#1067048: RFS: cxxopts/3.2.1-1 [ITA] -- Lightweight C++ option parser library

2024-03-17 Thread Shriram Ravindranathan


Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "cxxopts":

 * Package name : cxxopts
   Version  : 3.2.1-1
   Upstream contact : [fill in name and email of upstream]
 * URL  : https://github.com/jarro2783/cxxopts
 * License  : Expat, Boost-1.0
 * Vcs  : https://salsa.debian.org/debian/cxxopts
   Section  : libs

The source builds the following binary packages:

  libcxxopts-dev - Lightweight C++ option parser library

To access further information about this package, please visit the following 
URL:

  https://mentors.debian.net/package/cxxopts/

Alternatively, you can download the package with 'dget' using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/c/cxxopts/cxxopts_3.2.1-1.dsc

Changes since the last upload:

 cxxopts (3.2.1-1) unstable; urgency=medium
 .
   * New upstream version 3.2.1
   * New maintainer (Closes: #1065748)
   * d/copyright:
 + Update copyright years
 + Add new maintainer to copyright
   * d/control:
 + Replace deprecated build-dep pkg-config with pkgconf
 + Add new maintainer to maintainer field
   * d/p/0001-install-pkgconfig-file-into-arch-indep-usr-share-pkg.patch:
 + Add Forwarded info to patch header

Regards,
--
  Shriram Ravindranathan



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1064139: ogre-1.12: FTBFS: error: ‘BuildFontAtlas’ is not a member of ‘ImGuiFreeType’

2024-03-17 Thread Flavien Bridault

Mmm this is weird, I got it built completely with the latest unstable 
docker image, thus with swig 4.2... What could be the difference?


I'll try with cowbuilder now...


*Dr. Flavien BRIDAULT*
Director of Software Development
IRCAD France & IRCAD Africa

flavien.brida...@ircad.fr 
Tél. : +33 (0)3 88 119 201
IRCAD France
http://www.ircad.fr/
http://www.ircad.africa/ 

Suivez l'IRCAD sur Facebook 



*IRCAD France*
Hôpitaux Universitaires - 1, place de l'Hôpital - 67091 Strasbourg Cedex 
- FRANCE


Le 17/03/2024 à 16:05, Matthias Klose a écrit :

On 17.03.24 14:59, Matthias Klose wrote:

with both patches, I get until:

/home/packages/tmp/x/ogre-1.12-1.12.10+dfsg2/obj-x86_64-linux-gnu/Components/Python/CMakeFiles/_ 

Overlay.dir/OgreOverlayPYTHON_wrap.cxx:6527:56: error: expected 
template-name before '<' token
  6527 | struct SwigPyMapIterator_T : 
SwigPyIteratorClosed_T
 >
   | ^
/home/packages/tmp/x/ogre-1.12-1.12.10+dfsg2/obj-x86_64-linux-gnu/Components/Python/CMakeFiles/_ 

Overlay.dir/OgreOverlayPYTHON_wrap.cxx:6527:56: error: expected '{' 
before '<' token


[...]

/home/packages/tmp/x/ogre-1.12-1.12.10+dfsg2/obj-x86_64-linux-gnu/Components/Python/CMakeFiles/_Overlay.dir/OgreOverlayPYTHON_wrap.cxx:6547:12: 
error: 'SwigPyIterator' does not name a type; did you mean 
'SwigPyMapIterator_T'?

  6547 | inline SwigPyIterator*
   |    ^~
   |    SwigPyMapIterator_T
/home/packages/tmp/x/ogre-1.12-1.12.10+dfsg2/obj-x86_64-linux-gnu/Components/Python/CMakeFiles/_Overlay.dir/OgreOverlayPYTHON_wrap.cxx:6565:12: 
error: 'SwigPyIterator' does not name a type; did you mean 
'SwigPyMapIterator_T'?

  6565 | inline SwigPyIterator*
   |    ^~
   |    SwigPyMapIterator_T



this is introduced by swig 4.2.x, builds with wig 4.1.x



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1066485: volpack: diff for NMU version 1.0b3-9.1

Control: tags 1066485 + patch
Control: tags 1066485 + pending

Dear maintainer,

I've prepared an NMU for volpack (versioned as 1.0b3-9.1) and
uploaded it to DELAYED/4. Please feel free to tell me if I
should delay it longer.

Regards.


-- 
WBR, wRAR
diff -Nru volpack-1.0b3/debian/changelog volpack-1.0b3/debian/changelog
--- volpack-1.0b3/debian/changelog	2020-08-28 09:42:35.0 +0500
+++ volpack-1.0b3/debian/changelog	2024-03-17 21:32:58.0 +0500
@@ -1,3 +1,10 @@
+volpack (1.0b3-9.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTBFS with -Werror=implicit-function-declaration (Closes: #1066485).
+
+ -- Andrey Rakhmatullin   Sun, 17 Mar 2024 21:32:58 +0500
+
 volpack (1.0b3-9) unstable; urgency=medium
 
   * Test-Depends: build-essential
diff -Nru volpack-1.0b3/debian/patches/fix-implicit-function-declaration.patch volpack-1.0b3/debian/patches/fix-implicit-function-declaration.patch
--- volpack-1.0b3/debian/patches/fix-implicit-function-declaration.patch	1970-01-01 05:00:00.0 +0500
+++ volpack-1.0b3/debian/patches/fix-implicit-function-declaration.patch	2024-03-17 21:32:58.0 +0500
@@ -0,0 +1,104 @@
+Description: Add missing header includes and prototypes.
+Author: Andrey Rakhmatullin 
+Bug-Debian: https://bugs.debian.org/1066485
+Last-Update: 2024-03-17
+
+Index: volpack-1.0b3/examples/scalevolume.c
+===
+--- volpack-1.0b3.orig/examples/scalevolume.c
 volpack-1.0b3/examples/scalevolume.c
+@@ -38,6 +38,10 @@
+ #include 
+ #include 
+ #include 
++#include 
++#include 
++
++int write_den(char* filename, unsigned char* data, int xlen, int ylen, int zlen);
+ 
+ main(argc, argv)
+ int argc;
+Index: volpack-1.0b3/examples/rendervolume.c
+===
+--- volpack-1.0b3.orig/examples/rendervolume.c
 volpack-1.0b3/examples/rendervolume.c
+@@ -29,8 +29,13 @@
+  */
+ 
+ #include 
++#include 
++#include 
++#include 
+ #include "volume.h"
+ 
++int StorePGM(char* image, int width, int height, char* filename);
++
+ main(argc, argv)
+ int argc;
+ char **argv;
+Index: volpack-1.0b3/examples/denfile.c
+===
+--- volpack-1.0b3.orig/examples/denfile.c
 volpack-1.0b3/examples/denfile.c
+@@ -6,6 +6,9 @@
+  */
+ 
+ #include 
++#include 
++#include 
++#include 
+ 
+ #ifndef MIN
+ #define MIN(a, b) ((a) > (b) ? (b) : (a))
+@@ -17,6 +20,11 @@
+ 
+ #define MAX_READ_SIZE	8192	/* maximum # of bytes per read(2) call */
+ 
++int read_shorts(int fd, short* sbuf, int shortcount, int swap);
++int read_words(int fd, int* wbuf, int wordcount, int swap);
++int read_bytes(int fd, char* buf, int bytecount);
++int write_bytes(int fd, char* buf, int bytecount);
++
+ /*
+  * read_den
+  *
+Index: volpack-1.0b3/examples/classifyvolume.c
+===
+--- volpack-1.0b3.orig/examples/classifyvolume.c
 volpack-1.0b3/examples/classifyvolume.c
+@@ -29,6 +29,9 @@
+  */
+ 
+ #include 
++#include 
++#include 
++#include 
+ #include "volume.h"
+ 
+ main(argc, argv)
+Index: volpack-1.0b3/examples/makeoctree.c
+===
+--- volpack-1.0b3.orig/examples/makeoctree.c
 volpack-1.0b3/examples/makeoctree.c
+@@ -29,6 +29,8 @@
+  */
+ 
+ #include 
++#include 
++#include 
+ #include "volume.h"
+ 
+ main()
+Index: volpack-1.0b3/examples/makevolume.c
+===
+--- volpack-1.0b3.orig/examples/makevolume.c
 volpack-1.0b3/examples/makevolume.c
+@@ -29,6 +29,8 @@
+  */
+ 
+ #include 
++#include 
++#include 
+ #include "volume.h"
+ 
+ main()
diff -Nru volpack-1.0b3/debian/patches/series volpack-1.0b3/debian/patches/series
--- volpack-1.0b3/debian/patches/series	2020-08-28 09:42:35.0 +0500
+++ volpack-1.0b3/debian/patches/series	2024-03-17 21:32:58.0 +0500
@@ -1,3 +1,4 @@
 10_examples.patch
 10_vp_global_h.patch
 fixmanpages.patch
+fix-implicit-function-declaration.patch


signature.asc
Description: PGP signature

Bug#1067018: lnav: FTBFS on arm{el,hf}: test failures

2024-03-17 Thread Salvatore Bonaccorso

Hi Sebastian,

On Sat, Mar 16, 2024 at 11:34:23PM +0100, Sebastian Ramacher wrote:
> Source: lnav
> Version: 0.11.2-1
> Severity: serious
> Tags: ftbfs
> Justification: fails to build from source (but built successfully in the past)
> X-Debbugs-Cc: sramac...@debian.org
> 
> https://buildd.debian.org/status/fetch.php?pkg=lnav=armhf=0.11.2-1%2Bb1=1710618595=0
> 
> 
> 2024-03-16T19:49:36+00:00 
> ␛[0;35m=␛[0m
> ␛[0;35mCommand␛[0m: test: env TEST_COMMENT=parse_url1 ./drive_sql
> ␛[0;32mBEGIN␛[0m 
> test_sql_str_func.sh_b088735cf46f23ca3d5fb3da41f07a6a3b1cba35.out
> ␛[0;32mEND␛[0m   
> test_sql_str_func.sh_b088735cf46f23ca3d5fb3da41f07a6a3b1cba35.out
> OUT: test: env TEST_COMMENT=parse_url1 ./drive_sql
> --- 
> /<>/test/expected/test_sql_str_func.sh_b088735cf46f23ca3d5fb3da41f07a6a3b1cba35.out
>   2023-07-03 04:16:02.0 +
> +++ test_sql_str_func.sh_b088735cf46f23ca3d5fb3da41f07a6a3b1cba35.out 
> 2024-03-16 19:49:36.550940820 +
> @@ -1,2 +0,0 @@
> -Row 0:
> -  Column parse_url('https://example.com'): 
> {"scheme":"https","user":null,"password":null,"host":"example.com","port":null,"path":"/","query":null,"parameters":null,"fragment":null}
> FAIL! EXPECTED OUT DIFF
> ␛[0;31mBEGIN␛[0m 
> test_sql_str_func.sh_b088735cf46f23ca3d5fb3da41f07a6a3b1cba35.err
> error: sqlite3_exec failed -- misuse of sqlite3_result_subtype() by 
> parse_url()
> ␛[0;31mEND␛[0m   
> test_sql_str_func.sh_b088735cf46f23ca3d5fb3da41f07a6a3b1cba35.err
> ERR: test: env TEST_COMMENT=parse_url1 ./drive_sql
> --- 
> /<>/test/expected/test_sql_str_func.sh_b088735cf46f23ca3d5fb3da41f07a6a3b1cba35.err
>   2023-07-03 04:16:02.0 +
> +++ test_sql_str_func.sh_b088735cf46f23ca3d5fb3da41f07a6a3b1cba35.err 
> 2024-03-16 19:49:36.558940841 +
> @@ -0,0 +1 @@
> +error: sqlite3_exec failed -- misuse of sqlite3_result_subtype() by 
> parse_url()
> FAIL! EXPECTED ERR DIFF
> 
> 2024-03-16T19:49:36+00:00 
> ␛[0;35m=␛[0m
> ␛[0;35mCommand␛[0m: test: env TEST_COMMENT=parse_url2 ./drive_sql
> ␛[0;32mBEGIN␛[0m 
> test_sql_str_func.sh_0947bfe7ec626eaa0409a45b10fcbb634fb12eb7.out
> ␛[0;32mEND␛[0m   
> test_sql_str_func.sh_0947bfe7ec626eaa0409a45b10fcbb634fb12eb7.out
> OUT: test: env TEST_COMMENT=parse_url2 ./drive_sql
> --- 
> /<>/test/expected/test_sql_str_func.sh_0947bfe7ec626eaa0409a45b10fcbb634fb12eb7.out
>   2023-07-03 04:16:02.0 +
> +++ test_sql_str_func.sh_0947bfe7ec626eaa0409a45b10fcbb634fb12eb7.out 
> 2024-03-16 19:49:36.662941118 +
> @@ -1,2 +0,0 @@
> -Row 0:
> -  Column parse_url('https://example.com/'): 
> {"scheme":"https","user":null,"password":null,"host":"example.com","port":null,"path":"/","query":null,"parameters":null,"fragment":null}
> FAIL! EXPECTED OUT DIFF
> ␛[0;31mBEGIN␛[0m 
> test_sql_str_func.sh_0947bfe7ec626eaa0409a45b10fcbb634fb12eb7.err
> error: sqlite3_exec failed -- misuse of sqlite3_result_subtype() by 
> parse_url()
> ␛[0;31mEND␛[0m   
> test_sql_str_func.sh_0947bfe7ec626eaa0409a45b10fcbb634fb12eb7.err
> ERR: test: env TEST_COMMENT=parse_url2 ./drive_sql
> --- 
> /<>/test/expected/test_sql_str_func.sh_0947bfe7ec626eaa0409a45b10fcbb634fb12eb7.err
>   2023-07-03 04:16:02.0 +
> +++ test_sql_str_func.sh_0947bfe7ec626eaa0409a45b10fcbb634fb12eb7.err 
> 2024-03-16 19:49:36.674941150 +
> @@ -0,0 +1 @@
> +error: sqlite3_exec failed -- misuse of sqlite3_result_subtype() by 
> parse_url()
> FAIL! EXPECTED ERR DIFF
> 
> 2024-03-16T19:49:36+00:00 
> ␛[0;35m=␛[0m
> ␛[0;35mCommand␛[0m: test: env TEST_COMMENT=parse_url3 ./drive_sql
> ␛[0;32mBEGIN␛[0m 
> test_sql_str_func.sh_bac7f6531a2adf70cd1871fb13eab26dff133b7c.out
> ␛[0;32mEND␛[0m   
> test_sql_str_func.sh_bac7f6531a2adf70cd1871fb13eab26dff133b7c.out
> OUT: test: env TEST_COMMENT=parse_url3 ./drive_sql
> --- 
> /<>/test/expected/test_sql_str_func.sh_bac7f6531a2adf70cd1871fb13eab26dff133b7c.out
>   2023-07-03 04:16:02.0 +
> +++ test_sql_str_func.sh_bac7f6531a2adf70cd1871fb13eab26dff133b7c.out 
> 2024-03-16 19:49:36.778941428 +
> @@ -1,2 +0,0 @@
> -Row 0:
> -  Column parse_url('https://example.com/search?flag'): 
> {"scheme":"https","user":null,"password":null,"host":"example.com","port":null,"path":"/search","query":"flag","parameters":{"flag":null},"fragment":null}
> FAIL! EXPECTED OUT DIFF
> ␛[0;31mBEGIN␛[0m 
> test_sql_str_func.sh_bac7f6531a2adf70cd1871fb13eab26dff133b7c.err
> error: sqlite3_exec failed -- misuse of sqlite3_result_subtype() by 
> parse_url()
> ␛[0;31mEND␛[0m   
> test_sql_str_func.sh_bac7f6531a2adf70cd1871fb13eab26dff133b7c.err
> ERR: test: env TEST_COMMENT=parse_url3 ./drive_sql
> --- 
> /<>/test/expected/test_sql_str_func.sh_bac7f6531a2adf70cd1871fb13eab26dff133b7c.err
>   2023-07-03 04:16:02.0 +
> +++ test_sql_str_func.sh_bac7f6531a2adf70cd1871fb13eab26dff133b7c.err 
> 2024-03-16 19:49:36.790941460 +
> @@

Bug#1067047: Buildng the package removes debian/.gitlab-ci.yml

2024-03-17 Thread Andrey Rahmatullin

Source: gnucash
Version: 1:5.5-1.1
Severity: serious

Simply build the package from source produces a source package that doesn't
contain debian/.gitlab-ci.yml in debian.tar, one needs to rebuild the source
package separately, skipping the clean target. The reason for that is that the
file is listed debian/clean for some reason (alternatively, if it shouldn't be
in the package, please remove it from the package).


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

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

Bug#1066245: gnucash: diff for NMU version 1:5.5-1.2

Control: tags 1066245 + patch
Control: tags 1066245 + pending

Dear maintainer,

I've prepared an NMU for gnucash (versioned as 1:5.5-1.2) and
uploaded it to DELAYED/4. Please feel free to tell me if I
should delay it longer.

Regards.


-- 
WBR, wRAR
diff -Nru gnucash-5.5/debian/changelog gnucash-5.5/debian/changelog
--- gnucash-5.5/debian/changelog	2024-02-23 22:55:23.0 +0500
+++ gnucash-5.5/debian/changelog	2024-03-17 20:39:48.0 +0500
@@ -1,3 +1,10 @@
+gnucash (1:5.5-1.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTBFS with -Werror=implicit-function-declaration (Closes: #1066245).
+
+ -- Andrey Rakhmatullin   Sun, 17 Mar 2024 20:39:48 +0500
+
 gnucash (1:5.5-1.1) unstable; urgency=medium
 
   * Non-maintainer upload
diff -Nru gnucash-5.5/debian/patches/fix-implicit-function-declaration.patch gnucash-5.5/debian/patches/fix-implicit-function-declaration.patch
--- gnucash-5.5/debian/patches/fix-implicit-function-declaration.patch	1970-01-01 05:00:00.0 +0500
+++ gnucash-5.5/debian/patches/fix-implicit-function-declaration.patch	2024-03-17 20:39:48.0 +0500
@@ -0,0 +1,18 @@
+Description: Add missing header includes.
+Author: Andrey Rakhmatullin 
+Bug-Debian: https://bugs.debian.org/1066245
+Last-Update: 2024-03-17
+
+Index: gnucash-5.5/bindings/python/sqlite3test.c
+===
+--- gnucash-5.5.orig/bindings/python/sqlite3test.c
 gnucash-5.5/bindings/python/sqlite3test.c
+@@ -20,6 +20,8 @@
+ 
+ #include 
+ #include "qofsession.h"
++#include "qoflog.h"
++#include "gnc-engine.h"
+ #define TESTFILE "/tmp/blah.gnucash"
+ int main()
+ {
diff -Nru gnucash-5.5/debian/patches/series gnucash-5.5/debian/patches/series
--- gnucash-5.5/debian/patches/series	2024-02-23 22:55:23.0 +0500
+++ gnucash-5.5/debian/patches/series	2024-03-17 20:39:48.0 +0500
@@ -1,3 +1,4 @@
 build-flags.patch
 
 #t-skip--python-bindings.patch
+fix-implicit-function-declaration.patch


signature.asc
Description: PGP signature

Bug#965333: libvirt-daemon-system: Please make a separate package for apparmor profiles

2024-03-17 Thread Andrea Bolognani

On Wed, Mar 06, 2024 at 08:34:59AM +0100, Mikhail Morfikov wrote:
> Take a look for example at the thunderbird email client package. They ship
> the apparmor profile for the app in the thunderbird package (I also asked them
> to do the move, but no one cared, see #949649 from 23 Jan 2020 -- no one ever
> answered).

That bug report looks identical to the one you've filed against
libvirt, so it doesn't provide any additional information.

> So I use thunderbird and I have my own separate profile for this app because
> I have different rules, aiming different security policy. Each time the
> thunderbird package is updated, the apparmor profile is also installed, and
> I have no option to forbid that. So the apparmor policy is rewritten, which
> requires me to manually remove the newly installed thunderbird profile (the
> physical file), remove non exising profiles from apparmor (aa-remove-unknown),
> reload my own profile, update initramfs (since I load the apparmor policy 
> during
> initramfs phase).

That does indeed sound very annoying.

I wonder why you have to go through that whole process though. The
AppArmor configuration is in /etc, so everything is marked as
conffiles. If you make local customizations, shouldn't you at worst
be prompted to confirm whether you want your changes to be preserved
or overwritten?

> Most of people don't even use apparmor, so they don't care whether the 
> profile is
> in the core package, or in some app-apparmor-profile package.

I don't think this is a fair assessment: AppArmor is enabled by
default in Debian and has been for several releases, so people *are*
in fact using AppArmor unless they go out of their way to disable it.

> The all issues/problems call for a separate apparmor profile packages, but 
> someone
> has to make that move first, so others would follow. 4 years has passed and 
> no one
> did this, because no one care, and no one really use apparmor. And I bet no 
> one will
> make that first step and in the next 4 years the problems will still persist.

Have you raised the topic on a project-wide forum, such as
debian-devel? That would IMO be the best way forward. Convince the
project that AppArmor profiles should be packaged separately, and
make that into a (mini-)policy that is officially adopted.

Opening bug reports against individual packages when no project-wide
consensus has been reached is unlikely to result in much progress.

-- 
Andrea Bolognani 
Resistance is futile, you will be garbage collected.

signature.asc
Description: PGP signature

Bug#1007449: libtext-chasen-perl: please consider upgrading to 3.0 source format


I am uploading a NMU to DELAYED/10 in order to fix this.
The debdiff is attached.diff -Nru libtext-chasen-perl-1.04/Makefile.PL 
libtext-chasen-perl-1.04/Makefile.PL
--- libtext-chasen-perl-1.04/Makefile.PL2024-03-17 16:16:27.0 
+
+++ libtext-chasen-perl-1.04/Makefile.PL1999-08-18 06:58:18.0 
+
@@ -3,6 +3,5 @@
 WriteMakefile(
  'NAME' => 'Text::ChaSen',
  'VERSION_FROM' => 'ChaSen.pm',
- 'LD' => 'g++',
  'LIBS' => ['-lchasen']
 );
diff -Nru libtext-chasen-perl-1.04/debian/changelog 
libtext-chasen-perl-1.04/debian/changelog
--- libtext-chasen-perl-1.04/debian/changelog   2024-03-17 16:16:27.0 
+
+++ libtext-chasen-perl-1.04/debian/changelog   2024-03-17 16:10:23.0 
+
@@ -1,3 +1,10 @@
+libtext-chasen-perl (1.04-5.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Convert to source format 3.0, closes: #1007449.
+
+ -- Bastian Germann   Sun, 17 Mar 2024 16:10:23 +
+
 libtext-chasen-perl (1.04-5) unstable; urgency=medium
 
   * Adopt debhelper 9.
@@ -30,7 +37,7 @@
   
  -- NOKUBI Takatsugu   Tue, 16 Jul 2002 17:13:02 +0900
 
-libtext-chasen-perl (0.20-2) frozen unstable; urgency=low
+libtext-chasen-perl (0.20-2) unstable; urgency=low
 
   * Added missing depends line (libchasen).
   * Fixed clean rule.
diff -Nru libtext-chasen-perl-1.04/debian/patches/Makefile.patch 
libtext-chasen-perl-1.04/debian/patches/Makefile.patch
--- libtext-chasen-perl-1.04/debian/patches/Makefile.patch  1970-01-01 
00:00:00.0 +
+++ libtext-chasen-perl-1.04/debian/patches/Makefile.patch  2024-03-17 
16:10:23.0 +
@@ -0,0 +1,9 @@
+--- libtext-chasen-perl-1.04.orig/Makefile.PL
 libtext-chasen-perl-1.04/Makefile.PL
+@@ -3,5 +3,6 @@ use ExtUtils::MakeMaker;
+ WriteMakefile(
+ 'NAME' => 'Text::ChaSen',
+ 'VERSION_FROM' => 'ChaSen.pm',
++'LD' => 'g++',
+ 'LIBS' => ['-lchasen']
+ );
diff -Nru libtext-chasen-perl-1.04/debian/patches/series 
libtext-chasen-perl-1.04/debian/patches/series
--- libtext-chasen-perl-1.04/debian/patches/series  1970-01-01 
00:00:00.0 +
+++ libtext-chasen-perl-1.04/debian/patches/series  2024-03-17 
16:10:23.0 +
@@ -0,0 +1 @@
+Makefile.patch
diff -Nru libtext-chasen-perl-1.04/debian/source/format 
libtext-chasen-perl-1.04/debian/source/format
--- libtext-chasen-perl-1.04/debian/source/format   1970-01-01 
00:00:00.0 +
+++ libtext-chasen-perl-1.04/debian/source/format   2024-03-17 
16:10:15.0 +
@@ -0,0 +1 @@
+3.0 (quilt)

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

2024-03-17 Thread Andrea Bolognani

On Wed, Mar 13, 2024 at 11:06:03AM +, Simon McVittie wrote:
> 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.

Just for the record, I agree with everything Simon has written.

-- 
Andrea Bolognani 
Resistance is futile, you will be garbage collected.


signature.asc
Description: PGP signature

Bug#1067045: libsendmail-pmilter-perl: Includes non-free document


I am uploading a NMU in order to fix this.
The debdiff is attached.diff -Nru libsendmail-pmilter-perl-1.00/Makefile.PL 
libsendmail-pmilter-perl-1.00/Makefile.PL
--- libsendmail-pmilter-perl-1.00/Makefile.PL   2024-03-17 15:56:40.0 
+
+++ libsendmail-pmilter-perl-1.00/Makefile.PL   2011-04-16 13:05:03.0 
+
@@ -1,4 +1,4 @@
-# $Id: Makefile.PL,v 1.3 2004-08-14 18:09:38 bengen Exp $
+# $Id: Makefile.PL,v 1.11 2004/08/10 21:10:36 tvierling Exp $
 
 use 5.006;
 use ExtUtils::MakeMaker;
diff -Nru libsendmail-pmilter-perl-1.00/debian/changelog 
libsendmail-pmilter-perl-1.00/debian/changelog
--- libsendmail-pmilter-perl-1.00/debian/changelog  2024-03-17 
15:56:40.0 +
+++ libsendmail-pmilter-perl-1.00/debian/changelog  2024-03-17 
15:27:27.0 +
@@ -1,3 +1,14 @@
+libsendmail-pmilter-perl (1.00-1.3) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Convert source to format 3.0.
+(Closes: #1007675)
+  * d/copyright: Convert to machine-readable format.
+  * Exclude non-free document according to README.Debian.
+(Closes: #1067045)
+
+ -- Bastian Germann   Sun, 17 Mar 2024 15:27:27 +
+
 libsendmail-pmilter-perl (1.00-1.2) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru libsendmail-pmilter-perl-1.00/debian/copyright 
libsendmail-pmilter-perl-1.00/debian/copyright
--- libsendmail-pmilter-perl-1.00/debian/copyright  2024-03-17 
15:56:40.0 +
+++ libsendmail-pmilter-perl-1.00/debian/copyright  2024-03-17 
15:27:27.0 +
@@ -1,31 +1,32 @@
-This is the debian package for the PMilter module.
-It was created by Hilko Bengen  using
-dh-make-perl.
-
-Upstream author:
-
+Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
+Upstream-Name: PMilter
+Comment:
+This is the debian package for the PMilter module.
+It was created by Hilko Bengen  using
+dh-make-perl.
+Files-Excluded: doc/milter-protocol.txt
+Upstream-Contact:
 Todd Vierling  
 
+Files:
+*
 Copyright:
-
 Copyright (c) 2002-2004 Todd Vierling
-
-License: BSD
-
+License: BSD-3-clause
 Redistribution and use in source and binary forms, with or without
 modification, are permitted provided that the following conditions are met:
-
+.
 1. Redistributions of source code must retain the above copyright notice,
 this list of conditions and the following disclaimer.
-
+.
 2. Redistributions in binary form must reproduce the above copyright
 notice, this list of conditions and the following disclaimer in the
 documentation and/or other materials provided with the distribution.
-
+.
 3. Neither the name of the author nor the names of contributors may be used
 to endorse or promote products derived from this software without specific
 prior written permission.
-
+.
 THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
 AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
 IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
diff -Nru libsendmail-pmilter-perl-1.00/debian/patches/debian.patch 
libsendmail-pmilter-perl-1.00/debian/patches/debian.patch
--- libsendmail-pmilter-perl-1.00/debian/patches/debian.patch   1970-01-01 
00:00:00.0 +
+++ libsendmail-pmilter-perl-1.00/debian/patches/debian.patch   2024-03-17 
15:27:27.0 +
@@ -0,0 +1,92 @@
+Description: Correct headings
+--- libsendmail-pmilter-perl-1.00.orig/lib/Sendmail/Milter.pm
 libsendmail-pmilter-perl-1.00/lib/Sendmail/Milter.pm
+@@ -145,6 +145,10 @@ __END__
+ 
+ =pod
+ 
++=head1 NAME
++
++Sendmail::Milter - compatibility interface for Sendmail::PMilter
++
+ =head1 SYNOPSIS
+  
+ use Sendmail::Milter;
+--- libsendmail-pmilter-perl-1.00.orig/lib/Sendmail/PMilter.pm
 libsendmail-pmilter-perl-1.00/lib/Sendmail/PMilter.pm
+@@ -80,8 +80,6 @@ to be called Mail::Milter.
+ 
+ =head1 METHODS
+ 
+-=over 4
+-
+ =cut
+ 
+ # Symbols exported to the caller
+@@ -124,6 +122,8 @@ sub new ($) {
+ 
+ =pod
+ 
++=over 4
++
+ =item get_max_interpreters()
+ 
+ Returns the maximum number of interpreters passed to C.  This is
+@@ -470,10 +470,6 @@ these methods would not be useful with t
+ 
+ =over 4
+ 
+-=cut
+-
+-=pod
+-
+ =item auto_getconn(NAME[, CONFIG])
+ 
+ Returns the connection descriptor for milter NAME in Sendmail configuration
+@@ -950,6 +946,8 @@ Note that, because the default socket ba
+ wise to increase this backlog by calling C before entering
+ C if using this dispatcher.
+ 
++=back
++
+ =cut
+ 
+ sub sequential_dispatcher () {
+@@ -1042,8 +1040,6 @@ when called:
+ 
+ =back
+ 
+-=back
+-
+ =head1 SECURITY CONSIDERATIONS
+ 
+ =over 4
+--- libsendmail-pmilter-perl-1.00.orig/lib/Sendmail/PMilter/Context.pm
 libsendmail-pmilter-perl-1.00/lib/Sendmail/PMilter/Context.pm
+@@ -48,7 +48,7 @@ our $VERSION = '0.94';
+ 
+ =pod
+ 
+-=head1 SYNOPSIS
++=head1 NAME
+ 
+

Bug#1066475: libpsortb: FTBFS: debug_funcs.c:320:38: error: implicit declaration of function ‘get_mtx_index’ [-Werror=implicit-function-declaration]

On Wed, Mar 13, 2024 at 12:52:40PM +0100, Lucas Nussbaum wrote:
> > debug_funcs.c:320:38: error: implicit declaration of function 
> > ‘get_mtx_index’ [-Werror=implicit-function-declaration]
An obvious solution would be including funcs.h into debug_funcs.c but this
dead code is so bad that the prototypes in funcs.h for the functions
defined in debug_funcs.c itself are different from the function
definitions so this isn't possible. Probably nobody actually calls those
functions so nothing breaks at the run time but to be able to actually
compile them the prototypes in funcs.h should probably be fixed.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#1065193: RFS: libhx/4.23-1 [RC] -- C library providing queue, tree, I/O and utility functions

2024-03-17 Thread Jörg Frings-Fürst

tags 1065193 - moreinfo
thanks

Hi Tobias,



Am Sonntag, dem 17.03.2024 um 14:39 +0100 schrieb Tobias Frost:
> Hi Jörg,
> 
> "debcheckout libhx" still gives me 4.17-1 as head.
> 
> After looking at your repo, I think I should point you to DEP-14
> as a recommended git layout for packaging. 
> As the branch name indicates you are using per-package-revision
> branches:
> IMHO It makes little sense to have one branch per debian package
> version/revision; (I had a similiar discussion on vzlogger lately,
> so to avoid repetiions: #1064344#28)
> 
> Please clarify how you want to manage the package in git, as
> this needs to be reflected in d/control's VCS-* fields correctly.
> (this is now blocking the upload.)

I have been using Vincent Driessen's branching model and the corresponding git
extension gitflow-avh for at least 7 years with Debian and for a long time at
work.

The default branch is master and development takes place in the develop branch.

The release candidates are managed in the branch release. The extension
debian/debian-version is used as a tag during the transfer.

The master branch always contains the last published executable version to which
the git tag in debian/control points.

The procedure is described in the README.debian.


> 
> (The current fields say the package is maintained in the default branch
> of your repo. I see a debian/ directory there, but that one is missing
> released (it is at 4.17-1, while unstable is at 4.19-1.1)
> 
> The review is based on the .dsc, timestamped on mentors.d.n
> 2024-03-17 12:00
> 
> d/changelog is *STILL* changing history for the 4.19-1 changelog
> block. (This issue must be fixed before upload.)
> 

I think these were artifacts because my changes to the NMU were not adopted. Has
been corrected.

> Thanks for re-adding the B-D on dpkg-dev.
> 
> 
> So, please elaborate on the git issue (so that the correct VCS-* can be
> confirmed or specified) , and fix the rewriting history part, and I'll upload 
> 
> Remove the moreinfo tag when ready.
> 
> Cheers,
> --
> tobi
> 
[...]

CU
Jörg
-- 
New:
GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D
GPG key (long) : 09F89F3C8CA1D25D
GPG Key: 8CA1D25D
CAcert Key S/N : 0E:D4:56


Jörg Frings-Fürst
D-54470 Lieser


git:  https://git.jff.email/cgit/

Skype:jff-skype@jff.email
Jami: joergfringsfuerst
Telegram: @joergfringsfuerst
Matrix:   @joergff:matrix.snct-gmbh.de

My wish list: 
 - Please send me a picture from the nature at your home.






signature.asc
Description: This is a digitally signed message part

Bug#1067046: RM: pyhanko/experimental -- ROM; An ITP was raised for python-pyhanko, and python-pyhanko is in the NEW queue

2024-03-17 Thread Georges Khaznadar

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove

-- 
Georges KHAZNADAR et Jocelyne FOURNIER
22 rue des mouettes, 59240 Dunkerque France.
Téléphone +33 (0)3 28 29 17 70



signature.asc
Description: PGP signature

Bug#969354:

2024-03-17 Thread allan

I've been trying to subscribe to debian-devel for about a month
through both https://lists.debian.org/debian-deval and direct
subscribe emails to debian-devel-requ...@lists.debian.org and until
this morning haven't received a confirmation email using either
method.

Today I got confirmation emails but confirmation is failing; I'm
receiving a canned error message.

I've tried confirming by just hitting reply on the confirmation email
and also by creating a new email with "confirm" and the confirmation
number in the subject line.  Both methods are failing consistently.

-- 
we see things not as they are, but as we are.
 -- anais nin

Bug#1066340: t4kcommon: FTBFS: linebreak.c:163:19: error: implicit declaration of function ‘u8_mbtouc_unsafe’ [-Werror=implicit-function-declaration]

On Wed, Mar 13, 2024 at 12:45:32PM +0100, Lucas Nussbaum wrote:
> > linebreak.c:163:19: error: implicit declaration of function 
> > ‘u8_mbtouc_unsafe’ [-Werror=implicit-function-declaration]
> >   163 |   int count = u8_mbtouc_unsafe (, s, s_end - s);
The prototype, in src/linebreak/unistr.h, is under 
#ifdef GNULIB_UNISTR_U8_MBTOUC_UNSAFE, but nothing sets that.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#1067045: libsendmail-pmilter-perl: Includes non-free document


Source: libsendmail-pmilter-perl
Version: 1.00-1
Severity: serious

The source package includes the non-free milter-protocol.txt that is claimed to 
be excluded in README.Debian.

Bug#1067044: hyperkitty: please drop obsolete python3-mock build-dependency

2024-03-17 Thread Alexandre Detiste

Source: hyperkitty
Version: 1.3.7-1
Severity: normal

HyperKitty has switched to "unittest.mock" from
the standard library since 1.3.6.

python3-mock is now being slowly removed from Debian.

Greetings

Bug#1064231: incomplete patch


Control: reopen -1

renaming of libogre1.12.10.install to libogre1.12.10t64.install is missing.

Bug#1063376: RM: r-bioc-rhtslib [armel armhf i386 hppa m68k powerpc sh4] -- ROM; No support of 32 bit architectures any more

2024-03-17 Thread Sausanti Hani

On Wed, 07 Feb 2024 08:07:33 +0100 Andreas Tille  wrote:
> Package: ftp.debian.org
> Severity: normal
> User: ftp.debian@packages.debian.org
> Usertags: remove
> X-Debbugs-Cc: r-bioc-rhts...@packages.debian.org, 1063...@bugs.debian.org, 
> debia...@bugs.debian.org
> Control: affects -1 + src:r-bioc-rhtslib
>
> Hi,
>
> as per bug #1063275 the time_t transition would be quite hard for the
> r-bioc-htslib package. Since this kind of package is typically not used
> on 32bit architectures I've just uploaded r-bioc-htslib restricted to
> 64bit architectures where time_t transition is not needed. Please
> remove the binaries for 32bit architectures from the Debian archive.
>
> I'm aware that r-bioc-htslib has has the following rdepends:
>
> r-bioc-rsamtools
> r-bioc-variantannotation
> r-bioc-shortread
>
> I will file removal according requests for 32 bit architectures
> successively to clean up the archive once I get a bug number for this
> bug to keep it in CC.
>
> Thanks a lot for your work as ftpmaster
> Andreas.
>
>

Dikirim dari iPhone saya

Bug#1061019: xdg-desktop-portal: FTBFS: test_inputcapture: Timed out waiting for response from SetPointerBarriers

2024-03-17 Thread Simon McVittie

Control: tags -1 + moreinfo help
Control: severity -1 important

On Sun, 21 Jan 2024 at 13:17:45 +, Simon McVittie wrote:
> On Tue, 16 Jan 2024 at 20:37:49 +0100, Lucas Nussbaum wrote:
> > > 26/28 xdg-desktop-portal:pytest / pytest test_inputcaptureFAIL
> > > 11.21s   exit status 1
> > > >>> MALLOC_PERTURB_=39 
> > > >>> ASAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1 
> > > >>> UBSAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1:print_stacktrace=1
> > > >>>  /usr/bin/pytest-3 --verbose --log-level=DEBUG -k test_inputcapture
> 
> I tried rebuilding the package locally (in sbuild in an amd64 bookworm
> VM) and this test passed.

I still cannot reproduce this, and it doesn't seem to affect the buildds
or reproducible-builds infrastructure, so I don't consider this to be RC.
I attach an example of a successful build log.

It's probably a race condition in the upstream test suite, possibly
triggered by Lucas' test-build happening on a machine with 8 cores and 32G
of RAM. If someone else can reproduce this, patches gratefully received.

Thanks,
smcv

xdg-desktop-portal_1.18.2-1_amd64_20240317t150806.build.gz
Description: application/gzip

Bug#1067043: libruby: needs updating for libruby3.1t64

2024-03-17 Thread Chris Hofstaedtler

Control: tags -1 + pending

* Simon McVittie  [240317 15:57]:
> Package: libruby
> Version: 1:3.1
[..]

> Now that libruby3.1t64 has reached unstable, libruby is uninstallable on
> the architectures affected by the 64-bit time_t transition, 
[..]

> I suspect the only change needed here is to update the libruby metapackage
> so that it depends on libruby3.1t64 instead of libruby3.1. Please could
> someone who knows Ruby check this?

Indeed. I've uploaded ruby-defaults 1:3.1+nmu1 and pushed to salsa.

Chris

PS: @ruby-team: if you disagree / want to take over, please let me know.

Bug#1064139: ogre-1.12: FTBFS: error: ‘BuildFontAtlas’ is not a member of ‘ImGuiFreeType’