Bug#60377: "reset" broken for dumb terminals

[Sven Joachim]

It does not happen very often that somebody replies to an over 20 years
old bug, and this seems to have escaped both my and upstream's
attention.  Thomas, could you please have a look?

Cheers,
   Sven

On 2022-12-06 15:44 -0800, Ben Wong wrote:

> Package: ncurses-bin
> Version: 6.3+20220423-2
> Followup-For: Bug #60377
> Control: tags -1 patch
> Control: tags -1 patch
>
> Dear Maintainer,
>
> This is still a problem. It causes my VT340 serial terminal to hang,
> but not immediately. It happens the next time a program tries to open
> /dev/ttyUSB0, for example, getty after logging out. I presume this
> hasn't been fixed because the bug only affects hardware terminals that
> lack a carrier detect line (such as any DEC terminal connected via
> DEC423 MMJ).
>
> If anything, clocal ought to be asserted by default, not disabled.
> However, I suggest that `reset` should do neither. The man page for
> reset is clear on what it does and it does not mention clocal. I have
> attached a patch which brings the program back into line with its
> documentation.
>
> Thank you,
>
> --Ben
>
>
>
> -- System Information:
> Debian Release: bookworm/sid
>   APT prefers testing
>   APT policy: (500, 'testing')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 6.0.0-4-amd64 (SMP w/8 CPU threads; PREEMPT)
> Kernel taint flags: TAINT_SOFTLOCKUP
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.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 ncurses-bin depends on:
> ii  libc6  2.36-6
> ii  libtinfo6  6.3+20220423-2
>
> ncurses-bin recommends no packages.
>
> ncurses-bin suggests no packages.
>
> -- no debconf information
>
> --- reset_cmd.c.orig  2021-10-02 11:08:44.0 -0700
> +++ reset_cmd.c   2022-11-22 16:00:29.005361817 -0800
> @@ -190,13 +190,14 @@
>
>  /*
>   * Reset the terminal mode bits to a sensible state.  Very useful after
> - * a child program dies in raw mode.
> + * a child program dies in raw mode. Requires termios(3) to work.
>   */
>  void
>  reset_tty_settings(int fd, TTY * tty_settings, int noset)
>  {
>  GET_TTY(fd, tty_settings);
>
> + /* First reset any special characters to their default values */
>  #ifdef TERMIOS
>  #if defined(VDISCARD) && defined(CDISCARD)
>  reset_char(VDISCARD, CDISCARD);
> @@ -228,94 +229,38 @@
>  reset_char(VWERASE, CWERASE);
>  #endif
>
> -tty_settings->c_iflag &= ~((unsigned) (IGNBRK
> -| PARMRK
> -| INPCK
> -| ISTRIP
> -| INLCR
> -| IGNCR
> -#ifdef IUCLC
> -| IUCLC
> -#endif
> -#ifdef IXANY
> -| IXANY
> -#endif
> -| IXOFF));
>
> +/* Next, the reset command does the following
> + *
> + *   sets cooked and echo modes,
> + *   turns off cbreak and raw modes and
> + *   turns on newline translation on output.
> + *
> + * It does not mess with other settings, such as IXOFF and CLOCAL,
> + * as the correct values depend upon what type of terminal (and
> + * even what type of serial cable) is being used.
> + *
> + * Users who need a blunter instrument can try `stty sane` which
> + * makes presumptions about a "typical" setup.
> + */
> +
> +/* "Cooked" means: brkint ignpar istrip icrnl ixon opost isig icanon */
> +/* Setting cooked automatically turns off "raw" and "cbreak" */
>  tty_settings->c_iflag |= (BRKINT
> -   | IGNPAR
> -   | ICRNL
> -   | IXON
> -#ifdef IMAXBEL
> -   | IMAXBEL
> -#endif
> - );
> +  | IGNPAR
> +  | ISTRIP
> +  | ICRNL/* Input maps CR to NL */
> +  | IXON);
>
> -tty_settings->c_oflag &= ~((unsigned) (0
> -#ifdef OLCUC
> -| OLCUC
> -#endif
> -#ifdef OCRNL
> -| OCRNL
> -#endif
> -#ifdef ONOCR
> -| ONOCR
> -#endif
> -#ifdef ONLRET
> -| ONLRET
> -#endif
> -#ifdef OFILL
> -| OFILL
> -#endif
> -#ifdef OFDEL
> -| OFDEL
> -#endif
> -#ifdef NLDLY
> -| NLDLY
> -#endif
> -#ifdef CRDLY
> -| CRDLY
> -#endif
> -#ifdef TABDLY
> -| TABDLY
> -#endif
> -#ifdef BSDLY
> -| BSDLY
> -#endif
> -#ifdef VTDLY
> - 

Bug#1029230: gdb: None of the gdb pretty printers are working

[BogDan Vatra]

Hi,

I just tested it again on another debian (sid) and this time it worked just
fine from the command line.
The problem seems to be when I'm using it from Qt Creator, which adds its
own pretty printers.
Please close this bug and I'll create another one for Qt Creator.

Cheers,
BogDan.

În vin., 20 ian. 2023 la 10:55, Héctor Orón Martínez 
a scris:

> Hello BogDan,
>
>   Could you please share a reproducible test with error output?
>
> Regards
>
> On Fri, 20 Jan 2023 at 07:39, BogDan Vatra  wrote:
> >
> > Package: gdb
> > Version: 13.0.90.20230114-0.1
> > Severity: important
> > X-Debbugs-Cc: bog...@kde.org
> >
> > Dear Maintainer,
> >
> > Since python3 upgrade, none of the gdb pretty printers are working (e.g.
> > std::*).
> >
> >
> > -- System Information:
> > Debian Release: bookworm/sid
> >   APT prefers unstable-debug
> >   APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1,
> 'experimental')
> > Architecture: amd64 (x86_64)
> > Foreign Architectures: i386
> >
> > Kernel: Linux 6.1.0-1-amd64 (SMP w/32 CPU threads; PREEMPT)
> > Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
> > Locale: LANG=ro_RO.UTF-8, LC_CTYPE=ro_RO.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 gdb depends on:
> > ii  libbabeltrace1  1.5.11-1+b1
> > ii  libc6   2.36-8
> > ii  libdebuginfod1  0.188-2.1
> > ii  libexpat1   2.5.0-1
> > ii  libgcc-s1   12.2.0-14
> > ii  libgmp102:6.2.1+dfsg1-1.1
> > ii  libipt2 2.0.5-1
> > ii  liblzma55.4.1-0.0
> > ii  libmpfr64.2.0-1
> > ii  libncursesw66.4-1
> > ii  libpython3.11   3.11.1-2
> > ii  libreadline88.2-1.3
> > ii  libsource-highlight4v5  3.1.9-4.2+b2
> > ii  libstdc++6  12.2.0-14
> > ii  libtinfo6   6.4-1
> > ii  libxxhash0  0.8.1-1
> > ii  libzstd11.5.2+dfsg2-3
> > ii  zlib1g  1:1.2.13.dfsg-1
> >
> > Versions of packages gdb recommends:
> > ii  libc6-dbg [libc-dbg]  2.36-8
> >
> > Versions of packages gdb suggests:
> > pn  gdb-doc
> > ii  gdbserver  13.0.90.20230114-0.1
> >
> > -- no debconf information
>
>
>
> --
>  Héctor Orón  -.. . -... .. .- -.   -.. . ...- . .-.. --- .--. . .-.
>

Bug#1029313: reportbug: Reportbug GUI does not have a back button after selecting a package to report

[Heston Corbeil]

Package: reportbug
Version: 7.10.3+deb11u1
Severity: important
X-Debbugs-Cc: i...@heston.ca

Dear Maintainer,

Without a back button, any errors made are difficult to correct.

There is also no way to not select an option on the page "Do any of the
following apply to this report" once an option is selected.


-- Package-specific info:
** Environment settings:
INTERFACE="gtk"

** /home/heston/.reportbugrc:
reportbug_version "7.10.3+deb11u1"
mode standard
ui gtk
realname "Heston Corbeil"
email "i...@heston.ca"
no-cc
list-cc-me
smtphost reportbug.debian.org

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

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

Versions of packages reportbug depends on:
ii  apt2.2.4
ii  python33.9.2-3
ii  python3-reportbug  7.10.3+deb11u1
ii  sensible-utils 0.0.14

reportbug recommends no packages.

Versions of packages reportbug suggests:
pn  claws-mail 
pn  debconf-utils  
ii  debsums3.0.2
pn  dlocate
pn  emacs-bin-common   
ii  exim4-daemon-light [mail-transport-agent]  4.94.2-7
ii  file   1:5.39-3
ii  gnupg  2.2.27-2+deb11u2
pn  python3-urwid  
pn  reportbug-gtk  
ii  xdg-utils  1.1.3-4.1

Versions of packages python3-reportbug depends on:
ii  apt2.2.4
ii  file   1:5.39-3
ii  python33.9.2-3
ii  python3-apt2.2.1
ii  python3-debian 0.1.39
ii  python3-debianbts  3.1.0
ii  python3-requests   2.25.1+dfsg-2
ii  sensible-utils 0.0.14

python3-reportbug suggests no packages.

-- no debconf information

Bug#1029312: Linux-headers-*-amd64 depends on linux-compiler-gcc-*-x86 despite the kernel having support for Clang Compilation

[Heston Corbeil]

Package: linux-headers-5.10.0-14-amd64
Severity: normal
X-Debbugs-Cc: i...@heston.ca

Dear Maintainer,

Support for compiling the linux kernel with clang has been present for a while
now, yet gcc is a mandatory dependancy despite not being needed. Why force the
user to muddy their build environment?


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

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

Versions of packages linux-headers-5.10.0-14-amd64 depends on:
pn  linux-compiler-gcc-10-x86   
pn  linux-headers-5.10.0-14-common  
pn  linux-kbuild-5.10   

linux-headers-5.10.0-14-amd64 recommends no packages.

Bug#1028036: libx11-xcb1: uim's preedit hangs libreoffice

[dai]

Control: tags -1 + moreinfo unreproducible

I clean-installed bookworm, this issue was unreproducible.
So there is another cause, but I cannot find it at now.
-- 
Regards,
dai

GPG Fingerprint = 0B29 D88E 42E6 B765 B8D8 EA50 7839 619D D439 668E


signature.asc
Description: PGP signature

Bug#1029311: mwm mouse cannot be used after suspend

[Marco Moock]

Package: mwm
Version: 2.3.8-3
Severity: important
X-Debbugs-Cc: m...@posteo.de

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
I use mwm on my system (X11 with nouveau). If I suspend the system via 
"systemctl suspend", sometimes the situation occurs that after I woke it up, I 
can't use the mouse on mwm, but on the active X clients. Keyboard shortcuts 
work properly (like Alt+Tab), but I cannot use the context menu on the window 
borders nor the background. It happened many times, but not every time I sent 
the system to suspend.
If you need more information, please tell me, so I can provide it.

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

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

Versions of packages mwm depends on:
ii  libc6   2.36-8
ii  libx11-62:1.8.3-3
ii  libxext62:1.3.4-1+b1
ii  libxm4  2.3.8-3
ii  libxt6  1:1.2.1-1
ii  menu2.1.49
ii  x11-common  1:7.7+23

mwm recommends no packages.

mwm suggests no packages.

-- no debconf information

Bug#1029232: dask.distributed: broken by version mismatch with dask

[Diane Trout]

On Fri, 2023-01-20 at 13:20 -0800, Diane Trout wrote:
> On Fri, 2023-01-20 at 21:02 +, Rebecca N. Palmer wrote:
> > Would you like some help?  If so, please push what you currently
> > have
> > to 
> > Salsa so we can see it.
> > 
> > (No promises - #1029251 doesn't look like a big job but I might be
> > wrong 
> > about that.)
> 
> In shocking news, the build I did this morning actually finished.
> 
> I should hopefully be able to organize the hacks and commit them to
> salsa tonight. Maybe even get it uploaded tonight to.

Unfortunately there was a lintian error that should get fixed before
release.

I pushed most of what changes I'd made to salsa, I need change the
d/rules to keep a __pycache__ file from getting added to the -doc
package, (not done yet)

But then it should be ready to upload, but I'm tired so I wont get to
it tonight.

Diane

Bug#1029310: src:r-cran-bayesplot: fails to migrate to testing for too long: autopkgtest regression

[Paul Gevers]

Source: r-cran-bayesplot
Version: 1.9.0-1
Severity: serious
Control: close -1 1.10.0-2
Tags: sid bookworm
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 60 days as having a Release Critical bug in 
testing [1]. Your package src:r-cran-bayesplot has been trying to 
migrate for 61 days [2]. Hence, I am filing this bug. Your package fails 
its own autopkgtest if the package from unstable is installed in 
testing. A very quick glance suggests that it's just a missing 
*versioned* (test) dependency as I see it pass in unstable on armel (I 
scheduled the other archs too just now).


If a package is out of sync between unstable and testing for a longer 
period, this usually means that bugs in the package in testing cannot be 
fixed via unstable. Additionally, blocked packages can have impact on 
other packages, which makes preparing for the release more difficult. 
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that 
hamper the migration of their package in a timely manner.


This bug will trigger auto-removal when appropriate. As with all new 
bugs, there will be at least 30 days before the package is auto-removed.


I have immediately closed this bug with the version in unstable, so if 
that version or a later version migrates, this bug will no longer affect 
testing. I have also tagged this bug to only affect sid and bookworm, so 
it doesn't affect (old-)stable.


If you believe your package is unable to migrate to testing due to 
issues beyond your control, don't hesitate to contact the Release Team.


Paul

[1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html
[2] https://qa.debian.org/excuses.php?package=r-cran-bayesplot



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1028201: riseup-vpn unable to find a usable polkit agent under phosh

[Nilesh Patra]

Hi Praveen,

On Tue, 17 Jan 2023 18:20:03 +0100 Evangelos Ribeiro Tzaras 
 wrote:

On Sun, 2023-01-08 at 18:54 +0530, Pirate Praveen via Debian-on-mobile-
maintainers wrote:

Package: riseup-vpn,phosh
severity: grave

On mobian under phosh (librem 5), riseup-vpn gives error.
output of riseup-vpn attached.

phosh provides polkit-1-auth-agent

phosh 0.23
riseup-vpn 0.21.11+ds1-2+b1


I've tried to reproduce this by running 
$ pkexec echo bla


On both my Pinephone running Mobian, as well as on my Librem 5 running PureOS
the polkit authentication dialog is presented.

If you send a SIGUSR1 to phosh you can enable debug logging.
You should find something like the following in your journal:

Jan 17 18:10:04 hades phosh[1264]: New prompt for Authentication is needed to
run `/usr/bin/echo' as the super user
Jan 17 18:10:04 hades phosh[1264]: Adding PHOSH_STATE_MODAL_SYSTEM_PROMPT to
shells state. New state: PHOSH_STATE_MODAL_SYSTEM_PROMPT

While I've not tried it with riseup this test should already indicate whether
polkit authentication itself is working in phosh itself.


I maintain riseup-vpn in debian. As you might see in the dependency list, it 
depends on
policykit as "policykit-1-gnome | polkit-1-auth-agent"

If this is not functional for you, there is nothing I can do from riseup-vpn 
side to make
it work. As it works for Evangelos, please kindly check if this works as well 
for you and ensure
that this is not a local issue.

Thank you
Nilesh

Bug#1029309: qemu-system-misc misses Provides: qemu-kvm [linux-s390x] on !ubuntu

[Helmut Grohne]

Package: qemu-system-misc
Version: 1:7.2+dfsg-1
Control: affects -1 + debvm

Hi Michael,

On Debian s390x, qemu-system-misc contains /usr/bin/kvm, but it does not
provide qemu-kvm. It misses a "Provides: qemu-kvm [linux-s390x]". I
think this originates from the Ubuntu divergence where there is a
separate qemu-system-s390x which actually does provide qemu-kvm. This
provide should be specific to !ubuntu.

Helmut

Bug#1027686: Rakudo transition is stuck ?

[Adrian Bunk]

On Fri, Jan 20, 2023 at 08:34:23PM +0100, Sebastian Ramacher wrote:
> On 2023-01-20 21:29:30 +0200, Adrian Bunk wrote:
> > On Fri, Jan 20, 2023 at 08:16:29PM +0100, Sebastian Ramacher wrote:
> > > Hi
> > > 
> > > On 2023-01-20 18:29:37 +0100, Dominique Dumont wrote:
> > > > Hi
> > > > 
> > > > Nothing is happening in rakudo transition [1], no package are rebuilt.
> > > > 
> > > > Is there a way to unblock this transition ?
> > > 
> > > I've now scheduled the binNMUs. Please take care of the FTBFS bugs filed
> > > against the involved packages.
> > 
> > The "FTBFS bugs" are #1023576 and duplicates of that.
> > 
> > Shouldn't this transition fix such bugs?
> 
> I didn't check. If that's case, somebody should reassign/merge/close as
> appropriate.

Done.

> Cheers

cu
Adrian

Bug#1029308: ITP: libtest-mock-cmd-perl -- Mock system(), exec(), and qx() for testing

[mtj]

Package: wnpp
Owner: Mason James 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, debian-p...@lists.debian.org

* Package name: libtest-mock-cmd-perl
  Version : 0.7
  Upstream Author : Daniel Muey 

Bug#1029307: node-katex: reproducible-builds: build path in .mjs files

[Vagrant Cascadian]

Source: node-katex
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps kernel
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

The build path is embedded in various .mjs files:

  
https://tests.reproducible-builds.org/debian/rb-pkg/bookworm/amd64/diffoscope-results/node-katex.html

  /usr/share/javascript/katex/contrib/auto-render.mjs

  import·katex·from·'/build/1st/node-katex-0.16.4+~cs6.1.0/contrib/katex.mjs';
  vs.
  import·katex·from·'/build/2/node-katex-0.16.4+~cs6.1.0/2nd/contrib/katex.mjs';

Obviously, the build path is not likely to be present on an installed
system, so these files are presumably not functional.

The attached patch fixes this in debian/rules by replacing the build
path to katex.mjs with the installed path of katex.mjs.

Alternately, dropping these non-functional .mjs files might fix the
issue?

Hopefully it might also be possible to fix the problem some other way;
my guess is that rollup.config.js is where the build path gets embedded,
though I am honestly not sure:

  
https://sources.debian.org/src/node-katex/0.16.4%2B~cs6.1.0-1/rollup.config.js/#L18


According to my local tests, with this patch applied node-katex should
build reproducibly on tests.reproducible-builds.org!

Thanks for maintaining node-katex!

live well,
  vagrant
From bb4205c0a9b6f045bb614b3b9d9212a7b7c4ffe9 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Sat, 21 Jan 2023 02:41:10 +
Subject: [PATCH] debian/rules: Replace build path with installed path to
 katex.mjs in several contrib .mjs files.

---
 debian/rules | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/debian/rules b/debian/rules
index aba1567..9c3a32a 100755
--- a/debian/rules
+++ b/debian/rules
@@ -17,3 +17,6 @@ override_dh_install:
 	# Remove useless files
 	rm -rf debian/katex/usr/share/nodejs/katex/src/metrics \
 		debian/katex/usr/share/nodejs/katex/src/fonts/generate_fonts.py
+	# Replace build path with installed path
+	sed -i -e "s,$(CURDIR)/contrib/katex.mjs,/usr/share/javascript/katex/katex.mjs,g" \
+		debian/*/usr/share/javascript/katex/contrib/*.mjs
-- 
2.39.0



signature.asc
Description: PGP signature

Bug#1029306: ITP: libplaywright-perl -- Perl client for Playwright

[mtj]

Package: wnpp
Owner: Mason James 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, debian-p...@lists.debian.org

* Package name: libplaywright-perl
  Version : 1.251
  Upstream Author : George S. Baugh 

Bug#1029305: steam-installer: Broken tray icon after upgradring from steam to steam-installer

[Nelson A. de Oliveira]

Package: steam-installer
Version: 1:1.0.0.75+ds-3
Severity: minor
X-Debbugs-Cc: nao...@gmail.com

Hi!

After upgrading from steam to steam-installer, the tray icon is now
broken (tray.png, attached; it's the broken icon with a red X).

Thank you!

Best regards,
Nelson

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

Kernel: Linux 6.1.0-1-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=pt_BR.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8), 
LANGUAGE=pt_BR:pt:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages steam-installer depends on:
ii  debconf [debconf-2.0]  1.5.82
ii  steam-libs 1:1.0.0.75+ds-3
ii  steam-libs-i3861:1.0.0.75+ds-3
ii  zenity 3.43.0-1

steam-installer recommends no packages.

steam-installer suggests no packages.

Versions of packages steam-libs depends on:
ii  ca-certificates  20211016
ii  curl 7.87.0-2
ii  file 1:5.44-2
ii  libc62.36-8
ii  libcrypt11:4.4.33-2
ii  libgcc-s1 [libgcc1]  12.2.0-14
ii  libgl1   1.6.0-1
ii  libgl1-mesa-dri  22.3.3-1
ii  libgpg-error01.46-1
ii  libstdc++6   12.2.0-14
ii  libudev1 252.4-1
ii  libva-x11-2  2.17.0-1
ii  libva2   2.17.0-1
ii  libxcb-dri3-01.15-1
ii  libxcb1  1.15-1
ii  libxi6   2:1.8-1+b1
ii  libxinerama1 2:1.1.4-3
ii  xz-utils 5.4.1-0.0

Versions of packages steam-libs recommends:
ii  fontconfig   2.14.1-3
ii  fonts-liberation 1:1.07.4-11
ii  i965-va-driver [va-driver]   2.4.1+dfsg1-1
ii  libasound2-plugins   1.2.7.1-1
ii  libegl1  1.6.0-1
ii  libexpat12.5.0-1
ii  libfontconfig1   2.14.1-3
ii  libgbm1  22.3.3-1
ii  libsdl2-2.0-02.26.2+dfsg-1
ii  libva-drm2   2.17.0-1
pn  libva-glx2   
ii  libx11-6 2:1.8.3-3
ii  libx11-xcb1  2:1.8.3-3
ii  libxau6  1:1.0.9-1
ii  libxcb-dri2-01.15-1
ii  libxcb-glx0  1.15-1
ii  libxcb-present0  1.15-1
ii  libxcb-sync1 1.15-1
ii  libxdamage1  1:1.1.6-1
ii  libxdmcp61:1.1.2-3
ii  libxext6 2:1.3.4-1+b1
ii  libxfixes3   1:6.0.0-2
ii  libxss1  1:1.2.3-1
ii  libxxf86vm1  1:1.1.4-1+b2
pn  mesa-vulkan-drivers  
ii  rxvt-unicode [x-terminal-emulator]   9.30-2+b3
pn  steam-devices
ii  xdg-desktop-portal   1.16.0-2
ii  xdg-desktop-portal-gtk [xdg-desktop-portal-backend]  1.14.1-1
ii  xdg-utils1.1.3-4.1
ii  xterm [x-terminal-emulator]  378-1

Versions of packages steam-libs suggests:
pn  libudev0
pn  nvidia-driver-libs  
pn  nvidia-vulkan-icd   
ii  pipewire0.3.64-2

Versions of packages steam-libs:i386 depends on:
ii  ca-certificates  20211016
ii  curl 7.87.0-2
ii  file 1:5.44-2
ii  libc62.36-8
ii  libcrypt11:4.4.33-2
ii  libgcc-s1 [libgcc1]  12.2.0-14
ii  libgl1   1.6.0-1
ii  libgl1-mesa-dri  22.3.3-1
ii  libgpg-error01.46-1
ii  libstdc++6   12.2.0-14
ii  libudev1 252.4-1
ii  libva-x11-2  2.17.0-1
ii  libva2   2.17.0-1
ii  libxcb-dri3-01.15-1
ii  libxcb1  1.15-1
ii  libxi6   2:1.8-1+b1
ii  libxinerama1 2:1.1.4-3
ii  xz-utils 5.4.1-0.0

Versions of packages steam-libs:i386 recommends:
ii  fontconfig   2.14.1-3
ii  fonts-liberation 1:1.07.4-11
ii  i965-va-driver [va-driver]   2.4.1+dfsg1-1
ii  libasound2-plugins   1.2.7.1-1
ii  libegl1  1.6.0-1
ii  libexpat1   

Bug#1027869: dahdi-linux: please switch to B-D: dh-sequence-dkms (or dh-dkms)

[Andreas Beckmann]

Followup-For: Bug #1027869
Control: tag -1 patch pending

Hi,

In order to be able to drop the dkms -> dh-dkms dependency for bookworm
I've prepared a NMU and uploaded it to DELAYED/10. Please let me know if
I should delay it longer or cancel it.


Andreas
diff -Nru dahdi-linux-2.11.1.0.20170917~dfsg/debian/changelog 
dahdi-linux-2.11.1.0.20170917~dfsg/debian/changelog
--- dahdi-linux-2.11.1.0.20170917~dfsg/debian/changelog 2023-01-14 
15:33:58.0 +0100
+++ dahdi-linux-2.11.1.0.20170917~dfsg/debian/changelog 2023-01-21 
01:53:57.0 +0100
@@ -1,3 +1,13 @@
+dahdi-linux (1:2.11.1.0.20170917~dfsg-8.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Switch to B-D: dh-dkms.  (Closes: #1027869)
+  * Declare Testsuite: autopkgtest-pkg-dkms.
+  * Use upstream version without dfsg suffix and revision for dkms.
+  * Skip module build for kernels without CONFIG_USB.
+
+ -- Andreas Beckmann   Sat, 21 Jan 2023 01:53:57 +0100
+
 dahdi-linux (1:2.11.1.0.20170917~dfsg-8.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru dahdi-linux-2.11.1.0.20170917~dfsg/debian/control 
dahdi-linux-2.11.1.0.20170917~dfsg/debian/control
--- dahdi-linux-2.11.1.0.20170917~dfsg/debian/control   2023-01-14 
15:33:58.0 +0100
+++ dahdi-linux-2.11.1.0.20170917~dfsg/debian/control   2023-01-20 
20:11:53.0 +0100
@@ -4,7 +4,7 @@
 Maintainer: Debian VoIP Team 
 Uploaders: Tzafrir Cohen , Mark Purcell 
 Build-Depends: debhelper (>= 12), bzip2, asciidoc-base | asciidoc,
- dkms,
+ dh-dkms,
  module-assistant,
  tar (>= 1.28)
 Standards-Version: 4.3.0
@@ -12,6 +12,7 @@
 Vcs-Git: https://salsa.debian.org/pkg-voip-team/dahdi-linux.git
 Vcs-Browser: https://salsa.debian.org/pkg-voip-team/dahdi-linux
 Rules-Requires-Root: no
+Testsuite: autopkgtest-pkg-dkms
 
 Package: dahdi-linux
 Architecture: all
diff -Nru dahdi-linux-2.11.1.0.20170917~dfsg/debian/dkms.conf.in 
dahdi-linux-2.11.1.0.20170917~dfsg/debian/dkms.conf.in
--- dahdi-linux-2.11.1.0.20170917~dfsg/debian/dkms.conf.in  2023-01-14 
15:33:58.0 +0100
+++ dahdi-linux-2.11.1.0.20170917~dfsg/debian/dkms.conf.in  2023-01-21 
01:47:08.0 +0100
@@ -1,5 +1,8 @@
 PACKAGE_VERSION="#CVERSION#"
 
+# the xpp_usb module is only conditionally built but unconditionally listed 
below
+BUILD_EXCLUSIVE_CONFIG="CONFIG_USB"
+
 # Items below here should not have to change with each driver version
 PACKAGE_NAME="dahdi"
 MAKE[0]="(make modules KVERS=$kernelver MODULES_EXTRA='dahdi_dummy 
dahdi_echocan_oslec'; make KVERS=$kernelver)"
diff -Nru dahdi-linux-2.11.1.0.20170917~dfsg/debian/rules 
dahdi-linux-2.11.1.0.20170917~dfsg/debian/rules
--- dahdi-linux-2.11.1.0.20170917~dfsg/debian/rules 2023-01-14 
15:33:58.0 +0100
+++ dahdi-linux-2.11.1.0.20170917~dfsg/debian/rules 2023-01-20 
20:12:00.0 +0100
@@ -9,9 +9,9 @@
CFLAGS += -g
 endif
 
-# For DKMS. Use the full release (e.g.: 2.2.1+dfsg-1ubuntu1)
+# For DKMS. Use the upstream version without dfsg suffix.
 include /usr/share/dpkg/pkg-info.mk
-CVERSION = DEB_VERSION
+DKMS_MODULE_VERSION = $(DEB_VERSION_UPSTREAM:~dfsg=)
 
 ## MODULE-ASSISTANT STUFF
 # prefix of the target package name
@@ -70,9 +70,9 @@
exit 1
 endif
# For DKMS
-   sed -e "s|#CVERSION#|$(CVERSION)|"   \
+   sed -e "s|#CVERSION#|$(DKMS_MODULE_VERSION)|"   
 \
debian/dkms.conf.in > debian/dkms.conf
-   sed -e "s|#CVERSION#|$(CVERSION)|"   \
+   sed -e "s|#CVERSION#|$(DKMS_MODULE_VERSION)|"   
 \
debian/dahdi-dkms.install.in > debian/dahdi-dkms.install
 
$(MAKE) docs

Bug#1029182: Uploaded to DELAYED/3

[Tomasz Rybak]

I just fixed package (git diff in attachment)
and uploaded pgcli 3.5.0-4.1 to DELAYED/3.
Feel free to provide your own fix, or just we can just
wait for a bit :-).

Best regards.

-- 
Tomasz Rybak, Debian Developer 
GPG: A565 CE64 F866 A258 4DDC F9C7 ECB7 3E37 E887 AA8C
diff --git a/debian/changelog b/debian/changelog
index e23fada..0c93a07 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+pgcli (3.5.0-4.1) sid; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix psycopg depends (Closes: #1029182).
+
+ -- Tomasz Rybak   Sat, 21 Jan 2023 01:24:45 +0100
+
 pgcli (3.5.0-4) sid; urgency=medium
 
   * Uploading to sid.
diff --git a/debian/control b/debian/control
index c414842..9cc1f84 100644
--- a/debian/control
+++ b/debian/control
@@ -25,7 +25,7 @@ Depends:
  python3-pgspecial (>= 2),
  python3-pkg-resources,
  python3-prompt-toolkit (>= 3.0),
- python3-psycopg | python3-psycopg3 (>= 3.0.14),
+ python3-psycopg,
  python3-sqlparse (>= 0.3),
  python3-tabulate,
  python3-terminaltables,


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

Bug#1025213: Extra info

[Gert van de Kraats]

I also tried mutter 43.2-4 without the Debian patches,
specially the Support-Dynamic-triple-double-buffering.patch .
This did not solve the problem,
The only difference is that during blinking of the cursor
there is switching between 2 different (old) backgrounds i.s.o. 3.

Bug#1029265: www.debian.org: "Bugs/server-control" missing information about "Control:"

[Paul Wise]

On Fri, 2023-01-20 at 14:06 +, Christian Buhtz wrote:

> https://www.debian.org/Bugs/server-control
> 
> It lacks the information that all on that site described commands need to have
> a "Control: " string in front of them.

FTR, the Control pseudo-header is documented here:

https://www.debian.org/Bugs/Reporting#control

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#1029168: fonts-urw-base35: Apache pdfbox cannot load fonts. Complains "Start marker missing"

[James Cloos]

having looked at one of those .t1 files now, i see that it is indeed a
new file format.

the plrm notes that eexec can handle either hex or binary data
transparently, and that is the only difference from traditional
pfa i can see.

so they saved some disk size and some memory pressure compared to pfa.

it should be possible these days to embed those files as is into a
postscript file, given that transmission is likely to be over ip or usb.
(unlike, say, rs232 with xon/xoff.)

software which expects pfa or pfb should learn to hadle these, too.

freetype has no problem with them.

-JimC
-- 
James Cloos  OpenPGP: 0x997A9F17ED7DAEA6

Bug#1029304: fonts-lxgw-wenkai: Please package new 1.250 version

[Boyuan Yang]

Source: fonts-lxgw-wenkai
Version: 1.245+repack-1
Severity: normal
X-Debbugs-CC: atzli...@sina.com

Dear fonts-lxgw-wenkai package maintainer,

The upstream has released a new 1.250 version, containing many glyph fixes.
Please consider packaging the new upstream version in Debian to make sure that
this change would enter Debian 12.

Thanks,
Boyuan Yang


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

Bug#895089: postfix: Please replace 'c_rehash' with 'openssl rehash'

[Scott Kitterman]

On Friday, January 20, 2023 3:58:07 PM EST you wrote:
> Control: severity -1 important
> Control: tags -1 patch

Thanks.  Patch is committed in git.  I expect 3.7.4 out this weekend and this 
will be included when I upload that.

Scott K

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

Bug#993996: RFS: guerillabackup/0.4.0-1 [ITP] -- resilient, distributed backup and archiving solution

[halfdog]

Dear mentors,

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

 * Package name : guerillabackup
   Version  : 0.4.0-1
   Upstream contact : m...@halfdog.net
 * URL  : https://github.com/halfdog/guerillabackup
 * License  : LGPL-3.0+
 * Vcs  : https://salsa.debian.org/halfdog-guest/guerillabackup
   Section  : misc

Changes to the previous version:
* Features:
  * StorageTool:
* Added "Size" check policy to detect backups with abnormal size.
* Improved messages for interval policy violations and how to fix.
* Warn about files not having any applicable policies defined.
* Made policy inheritance control more explicit, improved documentation.
* Bugfixes:
  * BackupGenerator:
* Fixed invalid executable path in systemd service templates.
* Fixed backup generation pipeline race condition on asynchronous shutdown.
* Applied pylint.
  * StorageTool:
* Removed anti-file-deletion protection left in code accidentally.
* Fixed Interval policy status handling when applying retention policies.
* Fixed deletion mark handling with concurrent retention policies.
* Fixed exception attempting element retrieval from nonexisting source.
* Fixed error message typos.

The source builds the following binary packages:

  guerillabackup - resilient, distributed backup and archiving solution

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/g/guerillabackup/guerillabackup_0.4.0-1.dsc

Changes for the initial release:

 guerillabackup (0.4.0-1) unstable; urgency=medium
 .
   * Initial packaging of guerillabackup (Closes: #849714)

Regards,
-- 
  hd

Bug#588349: Supported in 5.2.7

[Jeremy Sowden]

Control: tags -1 - wontfix + pending

Separate columns for sport and dport were introduced in 5.2.7.  5.2.8
will be uploaded in the no too distant future.

J.



signature.asc
Description: PGP signature

Bug#1029145: fontconfig: the selection of the Bitstream font is broken, increasing the height, e.g. in the menus

[Vincent Lefevre]

On 2023-01-21 00:09:07 +0100, Vincent Lefevre wrote:
> Actually, this is now Noto, which explains the behavior:
> 
> https://gitlab.freedesktop.org/fontconfig/fontconfig/-/commit/ad70d785974992c569b30108923875e5b5e9dc5e
> 
> BTW, I'm wondering whether this isn't configurable in a simple way.

In fact, I meant: Why isn't there some kind of debconf configuration
for that, as this is a major setting?

I can see that /var/lib/dpkg/info/fontconfig-config.postinst has just
things related to hinting, subpixel rendering and bitmap fonts.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1029145: fontconfig: the selection of the Bitstream font is broken, increasing the height, e.g. in the menus

[Vincent Lefevre]

On 2023-01-20 23:56:43 +0100, Vincent Lefevre wrote:
> On 2023-01-20 18:56:46 +, Simon McVittie wrote:
> > So I think this is probably working as intended, and the configuration
> > change that prompted your different font rendering is that fontconfig
> > 2.13.1 had Bitstream Vera Sans as its fallback font, whereas 2.14.1 has
> > Noto Sans and DejaVu Sans listed as its preferred sans-serif fonts for
> > Latin text, as a result of
> > 
> > and then
> > .
> 
> This change was not announced. I think that the change of the default
> font is quite a big change. I've just noticed that I also did a mistake
> when I retrieved the /etc/fonts contents to compare them, which led the
> symlinks to be excluded. :(

Actually, this is now Noto, which explains the behavior:

https://gitlab.freedesktop.org/fontconfig/fontconfig/-/commit/ad70d785974992c569b30108923875e5b5e9dc5e

BTW, I'm wondering whether this isn't configurable in a simple way.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1029303: fiat-ecmwf: reproducible-builds: timestamps and kernel version embeded in /usr/bin/fiat

[Vagrant Cascadian]

Source: fiat-ecmwf
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps kernel
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

The timestamp and kernel version is embedded in /usr/bin/fiat:

  
https://tests.reproducible-builds.org/debian/rb-pkg/bookworm/amd64/diffoscope-results/fiat-ecmwf.html

  echo·"··timestamp···:·20240111001119"
  vs.
  echo·"··timestamp···:·20221209195227"

  echo·"··op.·system··:·Linux-6.0.0-0.deb11.2-amd64·(linux.64)"
  vs.
  echo·"··op.·system··:·Linux-5.10.0-19-amd64·(linux.64)"

The attached two patches fix this by using CMAKE_SYSTEM_NAME instead of
CMAKE_SYSTEM, and using CMake's timestamp function for the build date,
which supports a consistent timestamp if the SOURCE_DATE_EPOCH
environment variable is set.

According to my local tests, with these patches applied fiat-ecmwf should
build reproducibly on tests.reproducible-builds.org once the package
migrates to bookworm/testing!

Unfortunately, there are other outstanding issues with build paths,
which are tested in unstable and experimental.

Thanks for maintaining fiat-ecmwf!

live well,
  vagrant
From fa4c73e2d8875eea58af026485b508461c657f42 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Fri, 20 Jan 2023 22:50:55 +
Subject: [PATCH 1/2] src/programs/fiat.in: Avoid embedding the running kernel
 version.

Use CMAKE_SYSTEM_NAME instead of CMAKE_SYSTEM to avoid embedding the
running kernel version.

https://tests.reproducible-builds.org/debian/issues/bookworm/captures_kernel_version_via_CMAKE_SYSTEM_issue.html
---
 src/programs/fiat.in | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/programs/fiat.in b/src/programs/fiat.in
index 86f52eb..cab504c 100755
--- a/src/programs/fiat.in
+++ b/src/programs/fiat.in
@@ -42,7 +42,7 @@ info()
   echo "Build:"
   echo "  build type  : @CMAKE_BUILD_TYPE@"
   echo "  timestamp   : @EC_BUILD_TIMESTAMP@"
-  echo "  op. system  : @CMAKE_SYSTEM@ (@EC_OS_NAME@.@EC_OS_BITS@)"
+  echo "  op. system  : @CMAKE_SYSTEM_NAME@ (@EC_OS_NAME@.@EC_OS_BITS@)"
   echo "  processor   : @CMAKE_SYSTEM_PROCESSOR@"
   echo "  c compiler  : @CMAKE_C_COMPILER_ID@ @CMAKE_C_COMPILER_VERSION@"
   echo "flags : @EC_C_FLAGS@"
-- 
2.39.0

From 470c9ba8160be203eba1a43b208596e4b9abc1c8 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Fri, 20 Jan 2023 22:53:19 +
Subject: [PATCH 2/2] Pass BUILD_TIMESTAMP via CMakeLists.txt and use in
 fiat.in for the build timestamp.

The CMake TIMESTAMP function respects SOURCE_DATE_EPOCH when
specifying UTC timezone.

https://reproducible-builds.org/docs/timestamps/
---
 src/programs/CMakeLists.txt | 1 +
 src/programs/fiat.in| 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/programs/CMakeLists.txt b/src/programs/CMakeLists.txt
index 6a96196..2f1188e 100644
--- a/src/programs/CMakeLists.txt
+++ b/src/programs/CMakeLists.txt
@@ -16,6 +16,7 @@ foreach( lang ${langs} )
   set( EC_${lang}_FLAGS "${CMAKE_${lang}_FLAGS} ${CMAKE_${lang}_FLAGS_${CMAKE_BUILD_TYPE_CAPS}}" )
 endforeach()
 
+string(TIMESTAMP BUILD_TIMESTAMP "%Y%m%d%H%M%S" UTC)
 configure_file( ${tool}.in ${CMAKE_BINARY_DIR}${CMAKE_FILES_DIRECTORY}/${tool} @ONLY )
 
 file(COPY ${CMAKE_BINARY_DIR}${CMAKE_FILES_DIRECTORY}/${tool}
diff --git a/src/programs/fiat.in b/src/programs/fiat.in
index cab504c..707e385 100755
--- a/src/programs/fiat.in
+++ b/src/programs/fiat.in
@@ -41,7 +41,7 @@ info()
   echo ""
   echo "Build:"
   echo "  build type  : @CMAKE_BUILD_TYPE@"
-  echo "  timestamp   : @EC_BUILD_TIMESTAMP@"
+  echo "  timestamp   : @BUILD_TIMESTAMP@"
   echo "  op. system  : @CMAKE_SYSTEM_NAME@ (@EC_OS_NAME@.@EC_OS_BITS@)"
   echo "  processor   : @CMAKE_SYSTEM_PROCESSOR@"
   echo "  c compiler  : @CMAKE_C_COMPILER_ID@ @CMAKE_C_COMPILER_VERSION@"
-- 
2.39.0



signature.asc
Description: PGP signature

Bug#1029145: fontconfig: the selection of the Bitstream font is broken, increasing the height, e.g. in the menus

[Vincent Lefevre]

On 2023-01-20 18:56:46 +, Simon McVittie wrote:
> On Wed, 18 Jan 2023 at 15:35:54 +0100, Vincent Lefevre wrote:
> > After the upgrade from fontconfig 2.13.1-4.5 to fontconfig 2.14.1-3,
> > the selection of the Bitstream font is broken
> 
> There is no font of that name in Debian. Bitstream is (was?) a font
> foundry, not a font, so asking for a font named "Bitstream" is like
> asking for an application named "Microsoft" if what you actually wanted
> was Microsoft Word.

Yes, I don't know what I put only "Bitstream", probably because it
worked with no warnings or errors (I've got this setting since 2010).
Anyway...

> > With fontconfig 2.13.1-4.5,
> > 
> > cventin% fc-match Bitstream
> > Vera.ttf: "Bitstream Vera Sans" "Roman"
> > 
> > With fontconfig 2.14.1-3,
> > 
> > cventin% fc-match Bitstream
> > NotoSans-Regular.ttf: "Noto Sans" "Regular"
> 
> I can reproduce this. I think this is happening because you don't have any
> font named "Bitstream" installed (and neither do I), so fontconfig is
> falling back to looking for *any* font, for which its default seems to be
> to go through a list of sans-serif fonts in preference order:
> 
> $ fc-match "Bitstream Vera Sans"
> Vera.ttf: "Bitstream Vera Sans" "Roman"
> $ fc-match "Bitstream"
> NotoSans-Regular.ttf: "Noto Sans" "Regular"
> $ fc-match "hello, world"
> NotoSans-Regular.ttf: "Noto Sans" "Regular"

This doesn't behave as documented in the fc-match(1) man page:
"fc-match matches pattern (empty pattern by default) [...]"

This is a pattern matching. Even with explicit wildcards, this
doesn't work:

$ fc-match "*Bitstream*"
NotoSans-Regular.ttf: "Noto Sans" "Regular"

> So I think this is probably working as intended, and the configuration
> change that prompted your different font rendering is that fontconfig
> 2.13.1 had Bitstream Vera Sans as its fallback font, whereas 2.14.1 has
> Noto Sans and DejaVu Sans listed as its preferred sans-serif fonts for
> Latin text, as a result of
> 
> and then
> .

This change was not announced. I think that the change of the default
font is quite a big change. I've just noticed that I also did a mistake
when I retrieved the /etc/fonts contents to compare them, which led the
symlinks to be excluded. :(

[...]
> However, Bitstream Vera is essentially unmaintained, so consider using
> the DejaVu family (community-maintained forks of Bitstream Vera with
> wider glyph coverage, which had to change the name for licensing reasons)
> from the fonts-dejavu-core and optionally fonts-dejavu-extra packages,
> in preference to ttf-bitstream-vera.

Yes, I already use the DejaVu family in some other applications
(Emacs, Firefox).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#661591: shorewall-init not affected

[Jeremy Sowden]

Control: affects -1 - shorewall-init

Shorewall's script always returns zero, afaics.

J.


signature.asc
Description: PGP signature

Bug#1026945: bullseye-pu: package guix/1.2.0-4

[Holger Levsen]

Hi Vagrant,

On Fri, Jan 20, 2023 at 02:27:19PM -0800, Vagrant Cascadian wrote:
> On 2022-12-24, Vagrant Cascadian wrote:
> > Package: release.debian.org
> > Severity: normal
> > Tags: bullseye
> > User: release.debian@packages.debian.org
> > Usertags: pu
> > X-Debbugs-Cc: g...@packages.debian.org vagr...@debian.org
> > Control: affects -1 + src:guix
> 
> Should I have intead filed this with the intended version
> (e.g. guix/1.2.0-4+deb11u1) ? Should I just go ahead and upload, as this
> fixes a FTBFS issue in bullseye?
 
yes & yes, you are encouraged to upload if you are certain the upload
will be accepted.

https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#special-case-uploads-to-the-stable-and-oldstable-distributions
 

-> third paragraph there:

If you are confident that the upload will be accepted without changes, please 
feel free to upload at the same time as filing the release.debian.org bug. 
However if you are new to the process, we would recommend getting approval 
before uploading so you get a chance to see if your expectations align with 
ours.


disclaimer: I'm not a stable release manager, but you know that. :)


-- 
cheers,
Holger

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

Every time you see the word "smart" used to describe a device, replace it with
"surveillance." Surveillance watch. Surveillance streetlights. Surveillance
oven. Surveillance toilet. Surveillance car. Surveillance city. (@mollyali)


signature.asc
Description: PGP signature

Bug#1029302: python-mox: obsolete, rc-buggy, should be removed

[Timo Röhling]

Control: reassign -1 ftp.debian.org
Control: retitle -1 RM: python-mox -- RoM; obsolete, upstream dead, alternative 
available

* Iustin Pop  [2023-01-20 22:37]:

I'll have to check how to make the ROM official, haven't done that in a
looong while :)

We can repurpose this bug; I took the liberty to reassign and
retitle it.


Cheers
Timo

--
⢀⣴⠾⠻⢶⣦⠀   ╭╮
⣾⠁⢠⠒⠀⣿⡁   │ Timo Röhling   │
⢿⡄⠘⠷⠚⠋⠀   │ 9B03 EBB9 8300 DF97 C2B1  23BF CC8C 6BDD 1403 F4CA │
⠈⠳⣄   ╰╯


signature.asc
Description: PGP signature

Bug#1026945: bullseye-pu: package guix/1.2.0-4

[Vagrant Cascadian]

On 2022-12-24, Vagrant Cascadian wrote:
> Package: release.debian.org
> Severity: normal
> Tags: bullseye
> User: release.debian@packages.debian.org
> Usertags: pu
> X-Debbugs-Cc: g...@packages.debian.org vagr...@debian.org
> Control: affects -1 + src:guix

Should I have intead filed this with the intended version
(e.g. guix/1.2.0-4+deb11u1) ? Should I just go ahead and upload, as this
fixes a FTBFS issue in bullseye?

Thanks for any guidance!


live well,
 vagrant

> [ Reason ]
>
> This fixes a FTBFS of due several test suites using expired OpenPGP
> keys. At the time the current packages in Debian were built, the keys
> had not yet expired, but was later fixed upstream:
>
>   https://issues.guix.gnu.org/55506
>
> And was reported in Debian against the 1.3.x versions and fixed by
> applying the upstream patch:
>
>   https://bugs.debian.org/1011863
>
> [ Impact ]
>
> Future security updates will not be able to be fixed without fixing
> this issue first or disabling the affected tests.
>
> [ Tests ]
>
> Building the package succeeds with the patch; test suites pass.
>
> [ Risks ]
>
> None known at this time.
>
> [ Checklist ]
>   [x] *all* changes are documented in the d/changelog
>   [x] I reviewed all changes and I approve them
>   [x] attach debdiff against the package in (old)stable
>   [x] the issue is verified as fixed in unstable
>
> [ Changes ]
>
> Replaces the OpenPGP keys that have expired with keys with no
> expiration date.
>
> [ Other info ]
>
> None.
>
>
> live well,
>   vagrant
> diff -Nru guix-1.2.0/debian/changelog guix-1.2.0/debian/changelog
> --- guix-1.2.0/debian/changelog   2021-03-27 19:18:29.0 -0700
> +++ guix-1.2.0/debian/changelog   2022-12-24 07:16:17.0 -0800
> @@ -1,3 +1,11 @@
> +guix (1.2.0-4+deb11u1) bullseye; urgency=medium
> +
> +  [ Santiago Vila ]
> +  * debian/patches: Remove expiration dates on openpgp keys used in test
> +suite. (Closes: #1011863).
> +
> + -- Vagrant Cascadian   Sat, 24 Dec 2022 07:16:17 -0800
> +
>  guix (1.2.0-4) unstable; urgency=medium
>  
>* debian/patches: Fix privilege escalation issue in
> diff -Nru guix-1.2.0/debian/patches/series guix-1.2.0/debian/patches/series
> --- guix-1.2.0/debian/patches/series  2021-03-18 15:14:54.0 -0700
> +++ guix-1.2.0/debian/patches/series  2022-12-24 06:55:26.0 -0800
> @@ -38,3 +38,4 @@
>  0028-tests-lint.scm-Disable-several-lint-tests-that-fail-.patch
>  0029-tests-swh.scm-Disable-tests-the-fail-with-guile-2.2.patch
>  security/daemon-Prevent-privilege-escalation-with-keep-failed.patch
> +tests-Ensure-test-OpenPGP-keys-never-expire.patch
> diff -Nru 
> guix-1.2.0/debian/patches/tests-Ensure-test-OpenPGP-keys-never-expire.patch 
> guix-1.2.0/debian/patches/tests-Ensure-test-OpenPGP-keys-never-expire.patch
> --- 
> guix-1.2.0/debian/patches/tests-Ensure-test-OpenPGP-keys-never-expire.patch   
> 1969-12-31 16:00:00.0 -0800
> +++ 
> guix-1.2.0/debian/patches/tests-Ensure-test-OpenPGP-keys-never-expire.patch   
> 2022-12-24 06:55:26.0 -0800
> @@ -0,0 +1,55 @@
> +From 3ae7632ca0a1edca9d8c3c766efb0dcc8aa5da37 Mon Sep 17 00:00:00 2001
> +From: =?UTF-8?q?Ludovic=20Court=C3=A8s?= 
> +Date: Wed, 18 May 2022 23:20:21 +0200
> +Subject: [PATCH] tests: Ensure test OpenPGP keys never expire.
> +
> +All these keys had expiration dates.  'tests/keys/ed25519.pub' expired
> +on 2022-04-24.
> +
> +Fixes .
> +
> +* tests/keys/ed25519.pub, tests/keys/ed25519-2.pub,
> +tests/keys/ed25519-3.pub: Remove expiration date.
> +---
> + tests/keys/ed25519-2.pub | 11 +--
> + tests/keys/ed25519-3.pub | 10 +-
> + tests/keys/ed25519.pub   | 10 +-
> + 3 files changed, 15 insertions(+), 16 deletions(-)
> +
> +Adjusted to apply to older locations present in 1.3.0.
> +
> +--- a/tests/ed25519bis.key
>  b/tests/ed25519bis.key
> +@@ -1,10 +1,9 @@
> + -BEGIN PGP PUBLIC KEY BLOCK-
> + 
> + mDMEXtVsNhYJKwYBBAHaRw8BAQdAnLsYdh3BpeK1xDguJE80XW2/MSmqeeP6pbQw
> +-8jAw0OG0IkNoYXJsaWUgR3VpeCA8Y2hhcmxpZUBleGFtcGxlLm9yZz6IlgQTFggA
> +-PhYhBKBDaY1jer75FlruS4IkDtyrgNqDBQJe1Ww2AhsDBQkDwmcABQsJCAcCBhUK
> +-CQgLAgQWAgMBAh4BAheAAAoJEIIkDtyrgNqDM6cA/idDdoxo9SU+witdTXt24APH
> +-yRzHbX9Iyh4dZNIek9JwAP9E0BwSvDHB4LY9z4RWf2hJp3dm/yZ/jEpK+w4BGN4J
> +-Ag==
> +-=JIU0
> ++8jAw0OG0IkNoYXJsaWUgR3VpeCA8Y2hhcmxpZUBleGFtcGxlLm9yZz6IkAQTFggA
> ++OAIbAwULCQgHAgYVCgkICwIEFgIDAQIeAQIXgBYhBKBDaY1jer75FlruS4IkDtyr
> ++gNqDBQJihWJtAAoJEIIkDtyrgNqDbs0BAPOaGSYf3pX3DReEe1zbxxVQrolX9/AZ
> ++VP0AOt0TAgkzAP0Sr7G1NuCtjWWGK1WmlyTFPhOWLhNriKgZFkBZrGypAw==
> ++=pdTB
> + -END PGP PUBLIC KEY BLOCK-
> +--- a/tests/ed25519.key
>  b/tests/ed25519.key
> +@@ -2,9 +2,9 @@
> + 
> + mDMEXqNaoBYJKwYBBAHaRw8BAQdArviKtelb4g0I3zx9xyDS40Oz8i1/LRXqppG6
> + b23Hdim0KEVkIFR3by1GaWZ0eSA8bHVkbyt0ZXN0LWVjY0BjaGJvdWliLm9yZz6I
> +-lgQTFggAPhYhBETTHiGvcTj5tjIoCncfScv6rgctBQJeo1qgAhsDBQkDwmcABQsJ
> +-CAcCBhUKCQgLAgQWAgMBAh4BAheAAAoJEHcfScv6rgctq4MA/1R9G0roEwrHwmTd
> +-DHxt211

Bug#986152: Offer of help

[Roberto C . Sánchez]

On Fri, Jan 20, 2023 at 09:46:35PM +, Jeremy Sowden wrote:
> On 2023-01-19, at 22:56:39 +0100, Romain Francoise wrote:
> > On Thu, Jan 19, 2023 at 7:01 PM Jeremy Sowden wrote:
> > > I've pushed all the work to my repo on Salsa:
> > >
> > >   https://salsa.debian.org/azazel/shorewall
> > >
> > > Do you want to review it before I push to the shorewall-team repo?
> > 
> > It all looks pretty good to me! In fact, it's a radical improvement
> > over the previous packaging with seven source packages.
> > 
> > [...]
> > 
> > I have not yet actually tested the packages in my lab but please feel
> > free to push your changes to the team repo, and I will do the final
> > testing and upload over the week-end. I can also take care of opening
> > the bugs to have the previous source packages removed from unstable.
> 
> I was wondering about this shorewall-doc bug:
> 
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=266957
> 
> Once 5.2.8 is uploaded there won't be a shorewall-doc source package.
> Shall I reassign it to shorewall?
> 
> J.

That's a good question.  I think that the bug is actually assigned to
the shorewall-doc binary package, not the shorewall-doc source package.
Assuming that the shorewall source package will start to emit a
shorewall-doc binary package, I think that the BTS will do the right
thing and leaving the bug assigned to shorewall-doc is correct.  In that
case, the source package association of shorewall-doc will change, but
its bugs will still belong to shorewall-doc (the binary package).  If
you think about it, this must be the case, as closed and archived bugs
would end up being orphaned otherwise.

Regards,

-Roberto

-- 
Roberto C. Sánchez

Bug#855695: packages.debian.org shows non-existing binutils packages on arm64

[Cyril Brulebois]

Hi Jochen,

(Answering with my “I have the gid by accident” hat.)

Jochen Sprickerhof  (2023-01-20):
> There are more old files that should probably go:
> 
> jspricke@picconi:/srv/packages.debian.org/archive/debports$ find -type f 
> -mtime +0 -exec ls -l {} \;
> -rw-r--r-- 1 pkg_user pkg_maint 1029950 Nov  6  2014 
> ./experimental/Contents-arm64.gz
> -rw-r--r-- 1 pkg_user pkg_maint 1817658 Mai 19  2019 
> ./experimental/main/binary-powerpcspe/Packages.gz
> -rw-r--r-- 1 pkg_user pkg_maint 9198 Mai 19  2019 
> ./experimental/main/debian-installer/binary-powerpcspe/Packages.gz
> -rw-r--r-- 1 pkg_user pkg_maint 20 Nov  6  2014 
> ./experimental/main/debian-installer/binary-arm64/Packages.gz
> -rw-r--r-- 1 pkg_user pkg_maint 316060 Nov  6  2014 
> ./experimental/main/binary-arm64/Packages.gz
> -rw-r--r-- 1 pkg_user pkg_maint 5221435 Mai 19  2019 
> ./experimental/Contents-powerpcspe.gz
> -rw-r--r-- 1 pkg_user pkg_maint 27303127 Nov  6  2014 ./sid/Contents-arm64.gz
> -rw-r--r-- 1 pkg_user pkg_maint 95517 Mai 19  2019 
> ./sid/main/debian-installer/binary-powerpcspe/Packages.gz
> -rw-r--r-- 1 pkg_user pkg_maint 98536 Nov  6  2014 
> ./sid/main/debian-installer/binary-arm64/Packages.gz
> -rw-r--r-- 1 pkg_user pkg_maint 38478639 Mai 19  2019 
> ./sid/Contents-powerpcspe.gz

Looks good to me, all gone.

> There is also arm, avr32, mips, powerpcspe, s390 and sparc listed in
> /srv/packages.debian.org/config.sh. I guess they can be removed as well.

Given the git checkout is in the following state, I don't think it's
reasonable for me to touch anything else:

pkg_user@picconi:/srv/packages.debian.org$ git diff --stat|tail -1
 52 files changed, 12833 insertions(+), 10634 deletions(-)


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#1029265: www.debian.org: "Bugs/server-control" missing information about "Control:"

[Cyril Brulebois]

Hi Christian,

While improving the current doc can always happen, I'm not sure I agree
with your assessment that critical information is missing…

Christian Buhtz  (2023-01-20):
> https://www.debian.org/Bugs/server-control […]

The very first line mentions writing those mails to cont...@bugs.debian.org.

(That's the historical way of manipulating bug reports; support for
Control: when mailing n...@bugs.debian.org came much later.)

https://www.debian.org/Bugs/server-refcard is also very clear about
which commands can be sent to request@ and to control@.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#1025049: asymptote: Error in shipout3

[Hilmar Preuße]

Am 20.01.2023 um 13:06 teilte Picca Frédéric-Emmanuel mit:

Dear Frédéric,

as I'm not able to reproduce the issue (due to different software
constellation on the Desktop): would you be so kind to forward that
issue to upstream by your own? The upstream tracker is on
https://github.com/vectorgraphics/asymptote/issues

I case of questions regarding the Debian package feel free to contact us.

Many thanks,
  Hilmar


Here the backtrace generated after the crash, it seems that there is an 
Arithmetic Exception.

the gl parameter at line 23 seems strange

#23 0x5591db410072 in gl::glrender (prefix="", pic=0x2, format=, width=5.3049894774131808e-315, height=0, 
angle=2.3978552443441112e-312, zoom=5.3982412455708344e-315, m=..., M=..., shift=..., 
margin=...,
 t=0x7ffc641f9990, background=0x5591db748b90, nlightsin=3, 
lights=0x7f31c6fb10e8, diffuse=0x7f31c6fb1070, specular=0x7f31c6fb1000, 
view=false, oldpid=0) at ./glrender.cc:2207



--
sigfault

Bug#1029168: fonts-urw-base35: Apache pdfbox cannot load fonts. Complains "Start marker missing"

[Roland Rosenfeld]

On Fri, 20 Jan 2023, Jorge Moraleda wrote:

> > I searched for some definition that says, that a .pfb file has to
> > be prefixed with 80 01 91 03 00 00 (in front of %!PS-AdobeFont-1.),
> > but didn't find such a specification.

> I found this in case it helps
> https://personal.math.ubc.ca/~cass/piscript/type1.pdf

That's quite interesting.  Chapter 1 of this document explains, that
.pfb files have multiple of these "segment headers" but I miss them in
the fonts-urw-base35 .t1 fonts (not only at the beginning of the file,
but also at the beginning of the binary part as well as at the end of
the binary part).

It's not possible to simply prefix the .t1 files with 6 bytes, since
the other headers have to be added, too, and byte 3-6 of each header
contains the segment size.

But for me it seems that the .t1 files are neither .pfa files (since
they contain binary content, which isn't ascii armored) nor .pfb files
(since the segment headers are missing).

So we should think about "repairing" these files and make them real
.pfb files with segment headers.  Only problem is, that t1binary
doesn't handle C059-Italic.t1 correctly but generates a completely
broken font file.

So I did some perl hacking and created a addsegmentheaders.pl, which
adds segment headers at the beginning of the file, at the beginning of
the binary data and at the end.

First tests with the patched files look good, but someone else should
have a look on this...

You find my changes in my segmentheaders branch:
https://salsa.debian.org/roland/fonts-urw-base35/-/tree/segmentheaders

Next problem: lintian complains about

E: fonts-urw-base35: license-problem-font-adobe-copyrighted-fragment-no-credit 
[usr/share/fonts/type1/urw-base35/C059-BdIta.t1]
N: 
N:   This type 1 font file includes some postscript fragment with a non-free
N:   license of Adobe. In order to check if this tag is genuine please follow
N:   the procedure described in the reference.
N:   
N:   Moreover the fragment was likely verbatim copied from black book without
N:   any credit to Adobe.
N:   
N:   Should this be a false-positive, please override the tag.
N: 
N:   Please refer to https://wiki.debian.org/qa.debian.org/type1nondfsg for
N:   details.
N: 
N:   Visibility: error
N:   Show-Always: no
N:   Check: fonts/postscript/type1
N

for all the fonts now.  This is because the disassembled code contains
"startlock get exec" which may be a fragment from Adobe
from the following book:
https://web.archive.org/web/20150321034514/http://partners.adobe.com/public/developer/en/font/T1_SPEC.PDF
Appendix 3, page 95 (of the book) page 101 (of the PDF).

It wasn't tested before, since the file type wasn't detected as
"PostScript Type 1 font program data" before, so lintian didn't check
the files...

Greetings
Roland

Bug#986152: Offer of help

[Jeremy Sowden]

On 2023-01-19, at 22:56:39 +0100, Romain Francoise wrote:
> On Thu, Jan 19, 2023 at 7:01 PM Jeremy Sowden wrote:
> > I've pushed all the work to my repo on Salsa:
> >
> >   https://salsa.debian.org/azazel/shorewall
> >
> > Do you want to review it before I push to the shorewall-team repo?
> 
> It all looks pretty good to me! In fact, it's a radical improvement
> over the previous packaging with seven source packages.
> 
> [...]
> 
> I have not yet actually tested the packages in my lab but please feel
> free to push your changes to the team repo, and I will do the final
> testing and upload over the week-end. I can also take care of opening
> the bugs to have the previous source packages removed from unstable.

I was wondering about this shorewall-doc bug:

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

Once 5.2.8 is uploaded there won't be a shorewall-doc source package.
Shall I reassign it to shorewall?

J.


signature.asc
Description: PGP signature

Bug#1029302: python-mox: obsolete, rc-buggy, should be removed

[Iustin Pop]

On 2023-01-20 22:24:39, Timo Röhling wrote:
> Hi,
> 
> python3-mox has no reverse dependencies, last upstream activity is from
> 2018, the package is RC-buggy and there are plenty of Python mock
> libraries available already.

Thanks for checking - I was going to do so this weekend. For the last
release, there were still about 8 packages (IIRC - could be wrong, of
course), so didn't ask for removal back then.

As you say, this is old tech. The only and really only reason to keep it
was for reverse deps.

I'll have to check how to make the ROM official, haven't done that in a
looong while :)

thanks,
iustin

Bug#1026231: debian-policy: document droppage of support for legacy locales

[Anthony Fok]

On Fri, Jan 20, 2023 at 10:15 AM Adam Borowski  wrote:
>
> On Fri, Jan 20, 2023 at 03:57:17PM +0200, Wouter Verhelst wrote:
> > On Thu, Jan 19, 2023 at 11:47:42AM +, Simon McVittie wrote:
> > If the PRC government *requires* a non-UTF-8 encoding for things sold to
> > them, we would be doing our users who want to sell a product containing
> > Debian to the PRC government a disservice by dropping support for it
> > altogether.
>
> It appears to me they require the character _set_ but not encoding: ie,
> that all glyphs can be displayed, they can be entered from keyboard, etc.
> The standard talks a lot about font support, etc.

Hi Adam,

You are correct indeed.  Yes, they worry more about the correct
coverage of characters, especially those that were added in 2022
corresponding to the latest ISO/IEC 10646 standard.

That said, they do require the ability to open, edit, and convert
GB18030-encoded files, but that is at the iconv() / ICU / application
level, but, like you said, they are NOT enforcing the use of
zh_CN.GB18030 as system locale.  (I now stand corrected.)

Incidentally, they have published three pre-recorded webinars thus
far, and I have reuploaded them to YouTube here for easier access for
the rest of the world:


https://www.youtube.com/watch?v=6gByuPXth7s&list=PLWCc17-QBkRjwhRfvCpxM8ez3b0qWO59a

I have yet to figure out how to add automatic Chinese subtitles and to
have it translated to English.  Maybe some day.  :-)

> > We don't have to ensure it works perfectly out of the box; just that
> > support is achievable with a reasonable amount of work.
>
> Our installer doesn't allow choosing such a locale, thus if indeed the
> encoding not character set is legally required, then we'd need to change
> so before the release.
>
> But I don't expect that to be the case -- a few years ago I played with
> Deepin and don't remember any weird encoding being used.  It would be good
> to either check again, or ask one of their maintainers.

Indeed, and that is what friends on #debian-zh IRC channel are trying
to tell me, and I have personally confirmed that not only Deepin, but
also Red Flag, openKylix, Ubuntu Kylix all use zh_CN.UTF-8 as the
default system locale (see my one of the really long-winded response
in this thread for details.  So you are indeed correct, and I stand
corrected too.  Sorry for the false alarm!  My mindset was still
living in 2002 when zh_CN.GB18030 was assumed to be a requirement by
the industry, but apparently all distros have switched over to
zh_CN.UTF-8 by default.

Debian does still support zh_CN.GB18030 with KDE, LXDE, LXQt,
Cinnamon, MATE, etc., but crashes with GNOME 43 and XFCE at the moment
(at least not on my system), but that's good enough to pass the most
basic GB18030 test.  Just like you correctly observe, "zh_CN.GB18030
as system locale" is not legally required, and thus no need to change
the Debian installer or the locales package for that, so I wouldn't
worry about that for Debian 12.0.  (If the winds do change, we could
hypothetically sneak in the change in, say, Debian 12.1.  And the
myriad of Debian derivatives in China can easily make that change for
basic conformance too.

Cheers,

Anthony

Bug#1021502: lintian: incorrectly complains about debian-news-entry-has-unknown-version

[Vincent Bernat]

On Tue, 11 Oct 2022 20:11:07 +0200 Axel Beckert  wrote:

> > Please investigate and fix this bug in lintian.

I see no possibility how to do that in Lintian except for switching
the check from a binary to a source package check. Not sure if this is
that easily doable. Additionally it will become more complex as it
would have each per-binary-package debian/.NEWS files
separately. (It would also invalidate any lintian override about it.)

But I actually would prefer to not have to do that at all as IMHO that
tag is validly emitted and this is IMHO a newly introduced bug in
debhelper. Cloning an according (wishlist) bug report against
debhelper


As it won't be fixed in debhelper either, maybe downgrade this warning?

Bug#1029302: python-mox: obsolete, rc-buggy, should be removed

[Timo Röhling]

Source: python-mox
Version: 0.7.8-5
Severity: serious
User: debian...@lists.debian.org
Usertags: proposed-removal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

python3-mox has no reverse dependencies, last upstream activity is from
2018, the package is RC-buggy and there are plenty of Python mock
libraries available already.

I propose this package be removed, which will also help python3-defaults
migrate to testing.


Cheers
Timo


-BEGIN PGP SIGNATURE-

iQGzBAEBCgAdFiEEJvtDgpxjkjCIVtam+C8H+466LVkFAmPLBpMACgkQ+C8H+466
LVm3WQwAl+rAEy++SrbwqFXCgtwaapZWl1NszaHmf7IgJnEyjtwpU1jww+sYmgGk
n95CiBSUIoGA/Xga6dE4tGmc+lAfwBiUzaDsP6wx16lOjRPnjhDvOVdOxGBMDgVu
l6oeXvGwMkEPijpQaiDow+dTZrxeP7a5Hmd5yLEChbNLIWqdxcytmdb2TWIktubw
XA8j8hq6wTlpP+DAlrDF3eR78Ir0bImScA2zLQI+jnoeV6ub07IYP363KwU9QgJ7
EvTE0oMXWk+BFpDrYo34AHyP9FHepRwPgXdWOb4zToWGlI4ZFlZ/Iw+FTL5Rvzln
M2u/HOZ3/AUqBxykvQRfSfusAPpPhJJ5SkoWFNxFBBD+e1WELVYVItN1XwYsu7F2
KY+2V1NG3nZlLqZe1Tks+80apgoP41ouS+7vslyBF5vZge1g3qONh9r+rrfsBOsZ
mVMv7f3VxeTPQ14C0o8NAfK3xpjrYhupEPH4D02ggOTFalawvlBSELi6TspH2zJM
0WWOx8Qt
=stcv
-END PGP SIGNATURE-

Bug#1019230: Bug#1021276: Pending snort 2.9.20 update

[Javier Fernandez-Sanguino]

Dear Markus,

Thank you for preparing. Could you please share the patch you are working
on? Snort is available in Salsa. Maybe  you could upload / provide there
your propose changes in a separate branch?

Saludos,

Javier

El vie, 20 ene 2023, 21:42, Markus Koschany  escribió:

> Control: tags -1 pending
> Control: owner -1!
>
> Dear maintainer,
>
> I have prepared a new upstream release of snort, version 2.9.20, which will
> address the current release critical bugs in your package. I am currently
> testing it and intend to upload it to delayed 5 tomorrow. That should
> ensure
> snort will re-enter testing in time for Bookworm's soft freeze.
>
> Regards,
>
> Markus
>

Bug#1018811: Three new test issues preventing upload of patch (Was: pyfai: autopkgtest regression on armel and i386)

[Andreas Tille]

Hi Jerome,

I've applied the suggested patch to relax the tests on 32 bit architectures.
Unfortunately there are new test suite errors as you can see in Salsa CI[1]:


==
FAIL: test_count_csr (pyFAI.test.test_histogram.TestHistogram2d.test_count_csr)
Test that the pixel count and the total intensity is conserved
--
Traceback (most recent call last):
  File 
"/builds/science-team/pyfai/debian/output/source_dir/.pybuild/cpython3_3.11_pyfai/build/pyFAI/test/test_histogram.py",
 line 339, in test_count_csr
self.assertTrue(delta == 0, msg="check all pixels were counted")
AssertionError: False is not true : check all pixels were counted
==
FAIL: test_numpy_vs_cython_vs_csr_2d 
(pyFAI.test.test_histogram.TestHistogram2d.test_numpy_vs_cython_vs_csr_2d)
Compare numpy histogram with cython simple implementation
--
Traceback (most recent call last):
  File 
"/builds/science-team/pyfai/debian/output/source_dir/.pybuild/cpython3_3.11_pyfai/build/pyFAI/test/test_histogram.py",
 line 373, in test_numpy_vs_cython_vs_csr_2d
self.assertTrue(delta_max <= self.err_max_cnt, "pixel count difference 
numpy/csr : max delta=%s" % delta_max)
AssertionError: False is not true : pixel count difference numpy/csr : max 
delta=8.0
==
FAIL: test_2d_nosplit (pyFAI.test.test_csr.TestCSR.test_2d_nosplit)
--
Traceback (most recent call last):
  File 
"/builds/science-team/pyfai/debian/output/source_dir/.pybuild/cpython3_3.11_pyfai/build/pyFAI/test/test_csr.py",
 line 195, in test_2d_nosplit
self.assertLess(error.mean(), 1e-3, "img are almost the same")
AssertionError: 244.15215998872887 not less than 0.001 : img are almost the same
==

Any idea how to fix these?

Kind regards
   Andreas.


[1] https://salsa.debian.org/science-team/pyfai/-/jobs/3826387

-- 
http://fam-tille.de

Bug#1029232: dask.distributed: broken by version mismatch with dask

[Diane Trout]

On Fri, 2023-01-20 at 21:02 +, Rebecca N. Palmer wrote:
> Would you like some help?  If so, please push what you currently have
> to 
> Salsa so we can see it.
> 
> (No promises - #1029251 doesn't look like a big job but I might be
> wrong 
> about that.)

In shocking news, the build I did this morning actually finished.

I should hopefully be able to organize the hacks and commit them to
salsa tonight. Maybe even get it uploaded tonight to.

Diane

Bug#1029232: dask.distributed: broken by version mismatch with dask

[Rebecca N. Palmer]

Would you like some help?  If so, please push what you currently have to 
Salsa so we can see it.


(No promises - #1029251 doesn't look like a big job but I might be wrong 
about that.)

Bug#1029301: src:camv-rnd: fails to migrate to testing for too long: unresolved RC bug and uploader built arch:all binaries

[Paul Gevers]

Source: camv-rnd
Version: 1.0.2-1
Severity: serious
Control: close -1 1.1.0-2
Tags: sid bookworm
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 1024559

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 60 days as having a Release Critical bug in 
testing [1]. Your package src:camv-rnd has been trying to migrate for 62 
days [2]. Hence, I am filing this bug. The new version is blocked by bug 
#1024559.


If a package is out of sync between unstable and testing for a longer 
period, this usually means that bugs in the package in testing cannot be 
fixed via unstable. Additionally, blocked packages can have impact on 
other packages, which makes preparing for the release more difficult. 
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that 
hamper the migration of their package in a timely manner.


This bug will trigger auto-removal when appropriate. As with all new 
bugs, there will be at least 30 days before the package is auto-removed.


I have immediately closed this bug with the version in unstable, so if 
that version or a later version migrates, this bug will no longer affect 
testing. I have also tagged this bug to only affect sid and bookworm, so 
it doesn't affect (old-)stable.


If you believe your package is unable to migrate to testing due to 
issues beyond your control, don't hesitate to contact the Release Team.


Paul

[1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html
[2] https://qa.debian.org/excuses.php?package=camv-rnd



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1029300: src:tar: fails to migrate to testing for too long

[Paul Gevers]

Source: tar
Version: 1.34+dfsg-1
Severity: serious
Control: close -1 1.34+dfsg-1.1
X-Debbugs-CC: mechti...@debian.org
Tags: sid bookworm
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 1026204

Dear Mechtilde, maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 60 days as having a Release Critical bug in 
testing [1]. Your package src:tar has been trying to migrate for 61 days 
[2]. Hence, I am filing this bug.


If a package is out of sync between unstable and testing for a longer 
period, this usually means that bugs in the package in testing cannot be 
fixed via unstable. Additionally, blocked packages can have impact on 
other packages, which makes preparing for the release more difficult. 
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that 
hamper the migration of their package in a timely manner.


This bug will trigger auto-removal when appropriate. As with all new 
bugs, there will be at least 30 days before the package is auto-removed.


I have immediately closed this bug with the version in unstable, so if 
that version or a later version migrates, this bug will no longer affect 
testing. I have also tagged this bug to only affect sid and bookworm, so 
it doesn't affect (old-)stable.


If you believe your package is unable to migrate to testing due to 
issues beyond your control, don't hesitate to contact the Release Team.


Paul

[1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html
[2] https://qa.debian.org/excuses.php?package=tar



OpenPGP_signature
Description: OpenPGP digital signature

Bug#895089: postfix: Please replace 'c_rehash' with 'openssl rehash'

[Sven Joachim]

Control: severity -1 important
Control: tags -1 patch

On 2018-04-07 00:48 +0200, Sebastian Andrzej Siewior wrote:

> Source: postfix
> Version: 3.3.0-1
> Severity: normal
> Tags: sid buster
> User: pkg-openssl-de...@lists.alioth.debian.org
> Usertags: c_rehash
>
> This package is using the c_rehash command which is part of the
> openssl package. The c_rehash script is considered by upstream as a
> fallback script and will disappear at some point. The recommended way
> is to use the "openssl rehash" command instead which appeared in
> 1.1.0. Please make sure that this package does not use the c_rehash
> command anymore.
>
> The "openssl rehash" command creates half that many symlinks (one per
> certificate instead of two) because it uses only the newer hash.
> There is also the -compat option which creates both symlinks (and
> behaves like c_rehash currently does). The hash changed from md5 to
> sha1 during the 0.9.8 to 1.0.0 transition so I doubt that the
> "compat" mode will be required.

This is now causing real problems in Bookworm.  At least two people,
namely Charles Curley (CC'ed) and myself, have experienced long delays
in the postfix startup process, because the hashes get recomputed on
_every_ start.  In Charles' case this even exceeded the default systemd
timeout of 90 seconds.  See the thread starting at [1] for details.

Changing 'c_rehash' to 'openssl rehash' in
/usr/lib/postfix/configure-instance.sh reduced the time of
"systemctl restart postfix.service" on my laptop from ~30 seconds to 2,
I have attached at patch for your convenience.

> Should the c_rehash script be mentioned in the source code or script
> of this package but is not used during the build process or in the
> final package then feel free to close the bug saying so.

There are more occurrences of c_rehash in the current source code, but
only in documentation and comments, so it should not be necessary to
change them.

Cheers,
   Sven

1. https://lists.debian.org/debian-user/2023/01/threads.html#00294

From 9735f4f2456518e92f769b6f5402a57493f46efa Mon Sep 17 00:00:00 2001
From: Sven Joachim 
Date: Fri, 20 Jan 2023 21:39:03 +0100
Subject: [PATCH] Stop using c_rehash in configure-instance.sh

It is deprecated and now causes recomputation of the hashes every time
postfix starts, which is very slow.  Replace it with "openssl rehash"
as recommended.

Closes: #/895089
---
 debian/configure-instance.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/configure-instance.sh b/debian/configure-instance.sh
index f8ef185c..6a297d15 100644
--- a/debian/configure-instance.sh
+++ b/debian/configure-instance.sh
@@ -81,7 +81,7 @@ copyCAdir() {
 		# handle files in subdirectories
 		(cd "$ca_path" && find . -name '*.pem' -not -xtype l -print0 | cpio -0pdL --quiet "$dest_dir") 2>/dev/null ||
 		(echo failure copying certificates; exit 1)
-		c_rehash "$dest_dir" >/dev/null 2>&1
+		openssl rehash "$dest_dir" >/dev/null 2>&1
 		if [ "$new" = 1 ]; then
 			# and replace the old directory
 			rm -rf "${dest_dir%.NEW}"
--
2.39.0

Bug#1029292: lomiri-greeter: Depends: lomiri-system-compositor but it is not installable

[Mike Gabriel]

Hi Adrian, hi Marius,

On  Fr 20 Jan 2023 19:48:19 CET, Adrian Bunk wrote:


Package: lomiri-greeter
Version: 0.1~git20230111.ba0fc6a-4
Severity: serious

The following packages have unmet dependencies:
 lomiri-greeter : Depends: lomiri-system-compositor but it is not installable



Thanks Adrian for spotting this.

@Marius: is it more realistic to get lomiri-system-compositor operate  
on top of Miral or should we drop lomiri-greeter from the lomiri  
bin:pkg for a while until we can bring lomiri-system-compositor to  
Debian?


@Marius: Or might it be legitimate to simply drop l-s-c from Depends:  
of lomiri-greeter.


Request for feedback!

Thanks,
Mike
--

DAS-NETZWERKTEAM
c\o Technik- und Ökologiezentrum Eckernförde
Mike Gabriel, Marienthaler Str. 17, 24340 Eckernförde
mobile: +49 (1520) 1976 148
landline: +49 (4351) 850 8940

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de



pgpc2KWhClBuX.pgp
Description: Digitale PGP-Signatur

Bug#1028451: 2nd DisplayPort doesn't get video

[Salvatore Bonaccorso]

There is the patchset currently asked for inclusion at
https://lore.kernel.org/stable/20230119235200.441386-1-harry.wentl...@amd.com/T/#m3b5b3616eac750cfd7c9bd00ac1cf95006a6aeec
which is for addressing this issue.

Regards,
Salvatore

Bug#1019230: Pending snort 2.9.20 update

[Markus Koschany]

Control: tags -1 pending
Control: owner -1!

Dear maintainer,

I have prepared a new upstream release of snort, version 2.9.20, which will
address the current release critical bugs in your package. I am currently
testing it and intend to upload it to delayed 5 tomorrow. That should ensure
snort will re-enter testing in time for Bookworm's soft freeze.

Regards,

Markus


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

Bug#1029114: Please confirm subscription to 1029...@bugs.debian.org (git: CVE-2022-23521 CVE-2022-41903)

[nmantero]

Subscribe

Sent with Spark
El 20 ene 2023 21:09 +0100, 1029114-subh...@bugs.debian.org, escribió:
> Hello,
>
> This email has been sent to you as someone requested for this address
> to be subscribed to Bug#1029114. This bug is currently filed against
> src:git.
>
> If you reply to this mail, you confirm that you wish to be added as a
> subscriber. The contents of the reply do not matter. Usually, you can
> just use the normal reply feature in your mail program. Alternatively,
> you can send mail to the address below:
>
> 1029114-subyes-ceaf7fb48c79a560d43f6478768cc66d-13633ee96c18184ddf9f748a8fe76...@bugs.debian.org
>
> If you don't want to subscribe, just ignore this mail.
>
> If you have problems, please contact the Debian Listmaster Team
> at listmas...@lists.debian.org.
>
> Thank you.
>
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>
> Return-Path: <1...@buxtehude.debian.org>
> X-Original-To: lists-bugs=1029114-subscr...@bendel.debian.org
> Delivered-To: lists-bugs=1029114-subscr...@bendel.debian.org
> Received: from localhost (localhost [127.0.0.1])
> by bendel.debian.org (Postfix) with ESMTP id C72502046D
> for ; Fri, 20 Jan 2023 
> 20:09:10 + (UTC)
> X-Virus-Scanned: Debian amavisd-new at bendel.debian.org
> X-Spam-Flag: NO
> X-Spam-Score: -3.95
> X-Spam-Level:
> X-Spam-Status: No, score=-3.95 tagged_above=-1 required=6.31
> tests=[BAD_ENC_HEADER=0.001, BAYES_00=-1.9,
> HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_MED=-2.3]
> autolearn=ham autolearn_force=no
> Received: from bendel.debian.org ([127.0.0.1])
> by localhost (lists.debian.org [127.0.0.1]) (amavisd-new, port 2525)
> with ESMTP id IMmwHaCqLalm
> for ;
> Fri, 20 Jan 2023 20:09:06 + (UTC)
> Received: from buxtehude.debian.org (buxtehude.debian.org 
> [IPv6:2607:f8f0:614:1::1274:39])
> (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
> key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest 
> SHA256
> client-signature RSA-PSS (2048 bits) client-digest SHA256)
> (Client CN "buxtehude.debian.org", Issuer "Debian SMTP CA" (not verified))
> by bendel.debian.org (Postfix) with ESMTPS id 60BC621193
> for ; Fri, 20 Jan 2023 20:09:06 
> + (UTC)
> Received: from debbugs by buxtehude.debian.org with local (Exim 4.94.2)
> (envelope-from <1...@buxtehude.debian.org>)
> id 1pIxh9-007Tum-1G
> for bugs=1029114-subscr...@lists.debian.org; Fri, 20 Jan 2023 20:09:03 +
> Received: (at 1029114-subscribe) by bugs.debian.org; 20 Jan 2023 20:05:09 
> +
> X-Spam-Bayes: =?ISO-8859-1?Q?score:0. Tokens: new, 56; hammy, 53; 
> neutral, 23; spammy, 2.
> spammytokens:0.997-1--asociacin, 0.997-1--asociaci=c3=b3n
> hammytokens:0.000-+--H*u:102.0, 0.000-+--H*UA:102.0,
> 0.000-+--H*UA:102.6.1, 0.000-+--H*u:102.6.1, 0.000-+--H*u:20100101?=
> Received: from llsk766-a17.servidoresdns.net ([82.223.190.172]:38822)
> by buxtehude.debian.org with esmtps 
> (TLS1.2:ECDHE_SECP256R1__RSA_SHA512__AES_256_GCM:256)
> (Exim 4.94.2)
> (envelope-from )
> id 1pIxdN-007TQN-Eu
> for 1029114-subscr...@bugs.debian.org; Fri, 20 Jan 2023 20:05:09 +
> Received: from [192.168.1.35] (unknown [94.228.7.97])
> by llsk766-a17.servidoresdns.net (Postfix) with ESMTPA id 4Nz9JS71D1z2y3p
> for <1029114-subscr...@bugs.debian.org>; Fri, 20 Jan 2023 20:57:28 +0100 (CET)
> Message-ID: 
> Date: Fri, 20 Jan 2023 20:57:27 +0100
> MIME-Version: 1.0
> User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
> Thunderbird/102.6.1
> To: 1029114-subscr...@bugs.debian.org
> Content-Language: es-ES
> From: Nacho Mantero 
> Subject: subscribe
> Organization: =?UTF-8?Q?Asociaci=c3=b3n_de_Desarrolladores_del_Programa_Ador?=
> Content-Type: text/plain; charset=UTF-8; format=flowed
> Content-Transfer-Encoding: 8bit
> X-purgate-type: clean
> X-purgate-ID: 155848::1674244649-16FFC55B-86695675/0/0
> X-Greylist: delayed 454 seconds by postgrey-1.36 at buxtehude; Fri, 20 Jan 
> 2023 20:05:08 UTC
> X-Debian-PR-Message: list 1029114
> X-Debian-PR-Package: src:git
> X-Debian-PR-Title: git: CVE-2022-23521 CVE-2022-41903
>
> subscribe
>
> --
> Nacho Mantero
> Arquitecto de Software de la Asociación de Desarrolladores del Programa Ador
>
>
>
>

Bug#1029245: Help with numpydoc needed (Was: Bug#1029245: nitime: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p "3.10 3.11" returned exit code 13)

[Andreas Tille]

Control: tags -1 help

Hi,

I think I have fixed the numpy 1.24 issues that were causing this build
failure.  Unfortunately there are also numpydoc issues and I did not
found documentation about this when doing a web search.  I failed
finding something for inspect.formatargspec which I simply commented
out[1] (review for a better solution is welcome).

I finally do not have an idea how to replace:

   Handler  for event 
'autodoc-process-docstring' threw an exception (exception: 'FullArgSpec' object 
has no attribute 'replace')

which you can find in the latest build log in Salsa CI.

Any help is welcome

Andreas.

[1] 
https://salsa.debian.org/med-team/nitime/-/blob/master/debian/patches/numpydoc_1.24.patch#L15
[2] https://salsa.debian.org/med-team/nitime/-/jobs/3826316

-- 
http://fam-tille.de

Bug#966443: plantuml depends on ditaa but uses embedded version of ditaa instead

[Andrej Shadura]

On Tue, 28 Jul 2020 17:17:32 +0200 Tomas Janousek  wrote:

I was a bit confused how could ditaa work in plantuml as the usage in there
doesn't match the API in ditaa:

https://sources.debian.org/src/plantuml/1:1.2020.2+ds-1/src/net/sourceforge/plantuml/ditaa/PSystemDitaa.java/#L121
vs
https://sources.debian.org/src/ditaa/0.10+ds1-1.2/src/org/stathissideris/ascii2image/graphics/Diagram.java/#L113

Turns out it only works because plantuml includes its own (patched) version of
ditaa:
https://sources.debian.org/src/plantuml/1:1.2020.2+ds-1/src/org/stathissideris/ascii2image/graphics/Diagram.java/#L109

Therefore I find it confusing and unnecessary to depend on ditaa and patch the
full path to ditaa.jar into classpath in
https://sources.debian.org/src/plantuml/1:1.2020.2+ds-1/debian/patches/pdf.patch/
(Depending on ditaa pulled in the jarwrapper dependency, which seems to
duplicate functionality already provided by
/usr/lib/jvm/java-11-openjdk-amd64/lib/jar.binfmt)

It's also worth noting that the included (patched) version of ditaa is, if I
remember correctly, a bit older than the 0.10 we have in Debian. So you may
want to drop the included ditaa and use the one shipped in Debian instead
(but that one also seems unmaintained and behind upstream, unfortunately). In
that case it'll be helpful to know that the patching done in plantuml is
unnecessary and PSystemDitaa.java can be made to work with vanilla ditaa:
https://salsa.debian.org/liskin/plantuml/-/commit/5ee7fe82b098fa1402eb43acfff0fcc1bd19dbc4#96bdf10a122277d146e589cf010af72842d73ddd

Alternatively you may just drop the dependency and let plantuml use its own
copy of ditaa as it does upstream. Or you can also update the embedded ditaa
in plantuml, which is what I do in https://salsa.debian.org/liskin/plantuml/
(I'm now in the process of rebasing onto current Debian version).

Thanks a lot, I have finally found time to pull your patches in.

--
Cheers,
  Andrej

Bug#1029299: puppetserver: Broken symlink: /usr/lib/puppetserver/vendored-jruby-gems/specifications/puppetserver-ca-2.3.6.gemspec

[intrigeri]

Severity: normal
Package: puppetserver
Version: 7.9.3-1

Hi!

First, thank you so much for packaging puppetserver and puppet-agent
7.x for Bookworm!

# puppet agent --test --noop
  
Info: Using environment 'production'
Info: Retrieving pluginfacts
Info: Retrieving plugin
Info: Loading facts
Error: Could not retrieve catalog from remote server: Error 500 on SERVER: 
Server Error: No such file or directory - 
/usr/lib/puppetserver/vendored-jruby-gems/specifications/puppetserver-ca-2.3.6.gemspec

$ readlink -f 
/usr/lib/puppetserver/vendored-jruby-gems/specifications/puppetserver-ca-2.3.6.gemspec
/usr/share/rubygems-integration/all/specifications/puppetserver-ca-2.3.6.gemspec

And
/usr/share/rubygems-integration/all/specifications/puppetserver-ca-2.3.6.gemspec
does not exist.

Interestingly, I have ruby-puppetserver-ca-cli 2.4.0-1 installed,
which includes
/usr/share/rubygems-integration/all/specifications/puppetserver-ca-2.4.0.gemspec.

This satisfies the current dependency that puppetserver has:

  ruby-puppetserver-ca-cli (>= 2.3.6)

Cheers,
-- 
intrigeri

Bug#1029135: xtrx-dkms: xtrx module fails to build for kernel version 6.1

[Ying-Chun Liu (PaulLiu)]

Hi all,

I plan to do NMU to fix this bug. The debdiff is as attachment.
I'll wait for 3 days to see if anyone objects. And I'll upload it to 
delay/10 queue.


Yours,
Paul
diff -Nru xtrx-dkms-0.0.1+git20190320.5ae3a3e/debian/changelog 
xtrx-dkms-0.0.1+git20190320.5ae3a3e/debian/changelog
--- xtrx-dkms-0.0.1+git20190320.5ae3a3e/debian/changelog2022-11-17 
13:30:42.0 +0800
+++ xtrx-dkms-0.0.1+git20190320.5ae3a3e/debian/changelog2023-01-21 
03:20:02.0 +0800
@@ -1,3 +1,11 @@
+xtrx-dkms (0.0.1+git20190320.5ae3a3e-3.2) unstable; urgency=low
+
+  * Non-maintainer upload.
+  * Fix dkms build failure with kernel 6.1 (Closes: #1029135)
+- add debian/patches/0002-xtrx.c-fix-build-error-with-kernel-6.1.patch
+
+ -- Ying-Chun Liu (PaulLiu)   Sat, 21 Jan 2023 03:20:02 
+0800
+
 xtrx-dkms (0.0.1+git20190320.5ae3a3e-3.1) unstable; urgency=low
 
   * Non-maintainer upload.
diff -Nru 
xtrx-dkms-0.0.1+git20190320.5ae3a3e/debian/patches/0002-xtrx.c-fix-build-error-with-kernel-6.1.patch
 
xtrx-dkms-0.0.1+git20190320.5ae3a3e/debian/patches/0002-xtrx.c-fix-build-error-with-kernel-6.1.patch
--- 
xtrx-dkms-0.0.1+git20190320.5ae3a3e/debian/patches/0002-xtrx.c-fix-build-error-with-kernel-6.1.patch
1970-01-01 08:00:00.0 +0800
+++ 
xtrx-dkms-0.0.1+git20190320.5ae3a3e/debian/patches/0002-xtrx.c-fix-build-error-with-kernel-6.1.patch
2023-01-21 03:20:02.0 +0800
@@ -0,0 +1,27 @@
+Description: xtrx.c: fix build error with kernel 6.1
+ uart_ops.set_termios type changes a little in kernel 6.1. Thus
+ we need to change xtrx_uart_set_termios() third parameter as a
+ const pointer when building with kernel version >= 6.1
+Forwarded: https://github.com/xtrx-sdr/xtrx_linux_pcie_drv/pull/15
+Author: Ying-Chun Liu (PaulLiu) 
+Last-Update: 2023-01-21
+Index: xtrx-dkms-0.0.1+git20190320.5ae3a3e/xtrx.c
+===
+--- xtrx-dkms-0.0.1+git20190320.5ae3a3e.orig/xtrx.c
 xtrx-dkms-0.0.1+git20190320.5ae3a3e/xtrx.c
+@@ -361,8 +361,13 @@ static void xtrx_uart_shutdown(struct ua
+ }
+ 
+ static void xtrx_uart_set_termios(struct uart_port *port,
+-   struct ktermios *new,
+-   struct ktermios *old)
++struct ktermios *new,
++#if LINUX_VERSION_CODE < KERNEL_VERSION(6, 1, 0)
++struct ktermios *old
++#else
++const struct ktermios *old
++#endif
++  )
+ {
+   unsigned long flags;
+ 
diff -Nru xtrx-dkms-0.0.1+git20190320.5ae3a3e/debian/patches/series 
xtrx-dkms-0.0.1+git20190320.5ae3a3e/debian/patches/series
--- xtrx-dkms-0.0.1+git20190320.5ae3a3e/debian/patches/series   2022-11-17 
13:30:42.0 +0800
+++ xtrx-dkms-0.0.1+git20190320.5ae3a3e/debian/patches/series   2023-01-21 
03:20:02.0 +0800
@@ -1 +1,2 @@
 0001-xtrx-fix-PCI-DMA-allow-free-with-kernel-5.18.patch
+0002-xtrx.c-fix-build-error-with-kernel-6.1.patch


OpenPGP_0x44173FA13D05.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1029283: pywebdav: autopkgtest regression

[Mathias Behrle]

Source: pywebdav
Version: 0.10.0-1
Control: forwarded -1 https://github.com/andrewleech/PyWebDAV3/issues/33
Control: retitle -1 pywebdav: autopkgtest regression with Python 3.11

Due to new Python version  3.11.


pgpxwhHwdCtj5.pgp
Description: Digitale Signatur von OpenPGP

Bug#1029135: xtrx-dkms: xtrx module fails to build for kernel version 6.1

[Ying-Chun Liu (PaulLiu)]

forwarded 1029135 https://github.com/xtrx-sdr/xtrx_linux_pcie_drv/pull/15
thanks

I fixed this bug. The patch is as attachment.

Yours,
Paul

Description: xtrx.c: fix build error with kernel 6.1
 uart_ops.set_termios type changes a little in kernel 6.1. Thus
 we need to change xtrx_uart_set_termios() third parameter as a
 const pointer when building with kernel version >= 6.1
Forwarded: https://github.com/xtrx-sdr/xtrx_linux_pcie_drv/pull/15
Author: Ying-Chun Liu (PaulLiu) 
Last-Update: 2023-01-21
Index: xtrx-dkms-0.0.1+git20190320.5ae3a3e/xtrx.c
===
--- xtrx-dkms-0.0.1+git20190320.5ae3a3e.orig/xtrx.c
+++ xtrx-dkms-0.0.1+git20190320.5ae3a3e/xtrx.c
@@ -361,8 +361,13 @@ static void xtrx_uart_shutdown(struct ua
 }
 
 static void xtrx_uart_set_termios(struct uart_port *port,
- struct ktermios *new,
- struct ktermios *old)
+  struct ktermios *new,
+#if LINUX_VERSION_CODE < KERNEL_VERSION(6, 1, 0)
+  struct ktermios *old
+#else
+  const struct ktermios *old
+#endif
+	)
 {
 	unsigned long flags;
 


OpenPGP_0x44173FA13D05.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#988908: plantuml: Can plantuml work with default-jre-headless?

[Andrej Shadura]

Control: forcemerge 927340 988908

Hi,

On Wed, 18 Jan 2023, at 13:52, Petter Reinholdtsen wrote:
> Dear maintainer of plantuml.  Did you have a chance to look at the
> proposal to make the JDK dependency of plantuml more flexible?  Would be
> great if this could be solved before the next release of Debian.  I use
> plantuml a lot, byt only non-interactively from the command line.

In fact, this has been fixed in 1:1.2020.2+ds-1 already. Could you please 
verify it works for you?

-- 
Cheers,
  Andrej

Bug#1029298: ITP : node-dom-serialize - Serializes any DOM node into a String

[Sandra Uwah]

Package: wnpp
X-Debbugs-Cc:debian-de...@lists.debian.org
Owner: Sandra Uwah 
X-Debbugs-Cc:sandrauwa...@gmail.com 
Severity: wishlist
 
* Package name    : node-dom-serialize
  Version : 2.2.1+~cs4.1.1
  Upstream Author : Nathan Rajlich 
* URL : https://github.com/webmodules/dom-serialize/issues  
* License : MIT
  Programming Lang: Javascript
     Description :  Serializes any DOM node into a String


Sent from Mail for Windows

Bug#1027686: Rakudo transition is stuck ?

[Sebastian Ramacher]

On 2023-01-20 21:29:30 +0200, Adrian Bunk wrote:
> On Fri, Jan 20, 2023 at 08:16:29PM +0100, Sebastian Ramacher wrote:
> > Hi
> > 
> > On 2023-01-20 18:29:37 +0100, Dominique Dumont wrote:
> > > Hi
> > > 
> > > Nothing is happening in rakudo transition [1], no package are rebuilt.
> > > 
> > > Is there a way to unblock this transition ?
> > 
> > I've now scheduled the binNMUs. Please take care of the FTBFS bugs filed
> > against the involved packages.
> 
> The "FTBFS bugs" are #1023576 and duplicates of that.
> 
> Shouldn't this transition fix such bugs?

I didn't check. If that's case, somebody should reassign/merge/close as
appropriate.

Cheers
-- 
Sebastian Ramacher

Bug#1027686: Rakudo transition is stuck ?

[Adrian Bunk]

On Fri, Jan 20, 2023 at 08:16:29PM +0100, Sebastian Ramacher wrote:
> Hi
> 
> On 2023-01-20 18:29:37 +0100, Dominique Dumont wrote:
> > Hi
> > 
> > Nothing is happening in rakudo transition [1], no package are rebuilt.
> > 
> > Is there a way to unblock this transition ?
> 
> I've now scheduled the binNMUs. Please take care of the FTBFS bugs filed
> against the involved packages.

The "FTBFS bugs" are #1023576 and duplicates of that.

Shouldn't this transition fix such bugs?

> Cheers

cu
Adrian

Bug#1029297: python-graphviz: please make the build reproducible

[Chris Lamb]

Source: python-graphviz
Version: 0.20.1-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0] we noticed that
python-graphviz could not be built reproducibly.

This is because it shipped .PDF files that were generated during the
tests which were then installed under
/usr/lib/python3.X/dist-packages/doctest-output (!).

A patch is attached that removes this entire directory, similar to how
the package removes htmlconv, etc.

 [0] https://reproducible-builds.org/


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/debian/rules  2023-01-20 11:05:01.682844889 -0800
--- b/debian/rules  2023-01-20 11:15:48.332534092 -0800
@@ -16,3 +16,4 @@
rm -rf debian/python3-graphviz/usr/lib/python3*/dist-packages/.coverage
rm -rf debian/python3-graphviz/usr/lib/python3*/dist-packages/htmlcov
rm -f  
debian/python3-graphviz/usr/lib/python3*/dist-packages/test-log.txt
+   rm -rf 
debian/python3-graphviz/usr/lib/python3*/dist-packages/doctest-output

Bug#1028528: transition: libcotp

[Sebastian Ramacher]

Control: tags -1 trixie

On 2023-01-19 15:38:06 +, Francisco Vilmar Cardoso Ruviaro wrote:
> Hi Sebastian,
> 
> On 1/17/23 22:37, Sebastian Ramacher wrote:
> > Control: tags -1 moreinfo
> > 
> > On 2023-01-12 11:45:45 +, Francisco Vilmar Cardoso Ruviaro wrote:
> >> Package: release.debian.org
> >> Severity: normal
> >> User: release.debian@packages.debian.org
> >> Usertags: transition
> >> 
> >> Dear Release Team,
> >> 
> >> I would like to update libcotp in unstable to the 2.0.0-1.
> >> 
> >> I would like to request a transition slot for libcotp, changing the
> >> library name from libcotp12 to libcotp2. The version 2.0.0
> > 
> > Why is the SONAME going backwards?
> > 
> I believe this was an upstream decision, please check it out:
> 
> "the soversion is now set only from the $major version (e.g. 2),
> and not from $major$minor (e.g. 12) like it used to be."
> https://github.com/paolostivanin/libcotp/releases/tag/v2.0.0

Is upstream aware that the can never release with major versions 11 and
12 (at least)? Please clarify this with upstream.

In any case, let's postpone this transition to trixie.

Cheers

> 
> 
> I checked it this way:
> 
> $ readelf -d libcotp.so.1.2.8 | grep SONAME
>  0x000e (SONAME) Library soname: [libcotp.so.12]
> 
> $ readelf -d libcotp.so.2.0.0 | grep SONAME
>  0x000e (SONAME) Library soname: [libcotp.so.2]
> 
> 
> > Cheers
> > 
> 
> Thanks!
> -- 
> Francisco Vilmar Cardoso Ruviaro 
> 4096R: 1B8C F656 EF3B 8447 2F48 F0E7 82FB F706 0B2F 7D00




-- 
Sebastian Ramacher

Bug#1019293: python3-pip: installs setup_requires into /tmp/.../overlay/local/bin but then adds /tmp/.../overlay/bin to PATH

[stefanor]

Hi Simon (2023.01.20_13:54:00_+)

Actually, with a tweak, it can work.

SR

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272

Bug#1029296: poetry: non-determinism in generated RECORDS files

[Vagrant Cascadian]

Package: src:poetry
Version: 1.3.2+dfsg-2
Severity: normal
X-Debbugs-Cc: vagr...@debian.org, po...@debian.org, 
reproducible-b...@lists.alioth.debian.org
User: reproducible-bui...@lists.alioth.debian.org
Usertags: toolchain

Poetry generates RECORDS files with contents in non-dereministic order,
and a pull request fixing the issue was merged upstream:

  https://github.com/python-poetry/poetry-core/pull/545

The only package I know is affected is "reuse":

  
https://tests.reproducible-builds.org/debian/rb-pkg/bookworm/amd64/diffoscope-results/reuse.html

I monkey-patched the change into poetry and it fixed the issue building
"reuse", so can confirm it works!

I presume there are many more affected packages...

Please backport the trivial patch which wraps a couple calls in
"sorted()" or a new upstream if available to fix this!


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1027686: Rakudo transition is stuck ?

[Sebastian Ramacher]

Hi

On 2023-01-20 18:29:37 +0100, Dominique Dumont wrote:
> Hi
> 
> Nothing is happening in rakudo transition [1], no package are rebuilt.
> 
> Is there a way to unblock this transition ?

I've now scheduled the binNMUs. Please take care of the FTBFS bugs filed
against the involved packages.

Cheers

> 
> All the best
> 
> 
> [1] https://release.debian.org/transitions/html/rakudo.html
> 

-- 
Sebastian Ramacher

Bug#1029295: python-miio: Compatibility with python3-click > 8.0 (& make the build reproducible)

[Chris Lamb]

Source: python-miio
Version: 0.5.0.1-2
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: buildpath
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0] we noticed that
python-miio could not be built reproducibly.

This because the generation of the manual pages via help2man was
resulting in an error and thus the inclusion of a Python traceback
within those manpages. This traceback specified the absolute build
path which made the build unreproducible. (As it happens, I believe
there is a Lintian check for manpages that include Python tracebacks.)

However, I believe the issue is deeper than just a reproducibility
issue, in that miio is not actually compatible with python3-click
versions greater than 8.0, as that is the version that Click renamed
the "resultcallback" method to "result_callback":

  
https://click.palletsprojects.com/en/8.1.x/api/#click.MultiCommand.result_callback

Patch attached that simply renames these methods.

 [0] https://reproducible-builds.org/


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/debian/patches/result_callback.patch  1969-12-31 16:00:00.0 
-0800
--- b/debian/patches/result_callback.patch  2023-01-20 11:05:18.752043147 
-0800
@@ -0,0 +1,26 @@
+Description: Make the build reproducible
+Author: Chris Lamb 
+Last-Update: 2023-01-20
+
+--- python-miio-0.5.0.1.orig/miio/vacuum.py
 python-miio-0.5.0.1/miio/vacuum.py
+@@ -670,7 +670,7 @@ class Vacuum(Device):
+ callback=callback,
+ )
+ 
+-@dg.resultcallback()
++@dg.result_callback()
+ @dg.device_pass
+ def cleanup(vac: Vacuum, *args, **kwargs):
+ if vac.ip is None:  # dummy Device for discovery, skip teardown
+--- python-miio-0.5.0.1.orig/miio/vacuum_cli.py
 python-miio-0.5.0.1/miio/vacuum_cli.py
+@@ -77,7 +77,7 @@ def cli(ctx, ip: str, token: str, debug:
+ cleanup(vac, id_file=id_file)
+ 
+ 
+-@cli.resultcallback()
++@cli.result_callback()
+ @pass_dev
+ def cleanup(vac: miio.Vacuum, *args, **kwargs):
+ if vac.ip is None:  # dummy Device for discovery, skip teardown
--- a/debian/patches/series 1969-12-31 16:00:00.0 -0800
--- b/debian/patches/series 2023-01-20 11:05:15.760517986 -0800
@@ -0,0 +1 @@
+result_callback.patch

Bug#1010653: busco: add autopkgtest to check integration with hmmer and prodigal

[Andreas Tille]

Am Fri, Jan 20, 2023 at 07:46:49PM +0100 schrieb Sascha Steinbiss:
> > To have BUSCO lineages in the archive their licensing details have to
> > be clarified as the data does not contain any explicit statements.
> The website [0] states that
> 
>   The BUSCO datasets are licensed under the Creative Commons
>   Attribution-NoDerivatives 4.0 International License. To view a copy of
>   this license, visit http://creativecommons.org/licenses/by-nd/4.0/ or
>   send a letter to Creative Commons, PO Box 1866, Mountain View, CA
>   94042, USA.
> 
> The lineages and the URL you mention are referenced as the "datasets" so
> that seems to be the license statement.
> Consequently I guess including them in the package for the autopkgtest is
> not an option as the ND clause in their license is incompatible with DFSG.
> We might still download one of them at autopkgtest time but I am not sure
> that's a good idea. Any comments?

I'm wondering whether there might be some alternative data sets with a
free license.  We could ask upstream to provide something without the ND
clause.

Kind regards
   Andreas.

-- 
http://fam-tille.de

Bug#1028643: fontconfig: 2.14.1-3 greatly changes font rendering

[Ryan Thoryk]

Yesterday I noticed a substantial change in the interface fonts for my 
whole system, I'm running Testing.  They appear somewhat clearer, but 
don't align properly like the old fonts.  I'm using MATE, and it caused 
things like titlebars to increase in size.  I had noticed rendering 
changes with fontconfig in previous years, but this one seems to be a 
lot more than just rendering changes.


--
Ryan Thoryk
r...@thoryk.com
r...@tliquest.net

Bug#1029293: wxhexeditor: undefined symbol when accessing wxWidgets library

[Andrej Shadura]

Control: tag -1 moreinfo unreproducible

Hi,

On Fri, 20 Jan 2023, at 19:52, Jorge Moraleda wrote:
> Package: wxhexeditor
> Version: 0.24+repack-2+b2

> Dear Maintainer,
>
> The current version of wxHexEditor fails to start with error:
>
> wxHexEditor: symbol lookup error: wxHexEditor: undefined symbol:
> _ZN12wxEvtHandler21WXReservedEvtHandler1EPv, version WXU_3.2
>
> Perhaps this is related to the upgrade of the wxWidgets dependency from 
> version
> 3.0 to version 3.2 as discussed in https://bugs.debian.org/1019812 ?

I have installed the latest version, and it works without an issue.

$ apt policy libwxbase3.2-1 libwxgtk3.2-1
libwxbase3.2-1:
  Installed: 3.2.1+dfsg-4+b1
  Candidate: 3.2.1+dfsg-4+b1
  Version table:
 *** 3.2.1+dfsg-4+b1 500
500 mirror+file:/etc/apt/mirrors.list testing/main amd64 Packages
 10 https://deb.debian.org/debian unstable/main amd64 Packages
100 /var/lib/dpkg/status
libwxgtk3.2-1:
  Installed: 3.2.1+dfsg-4+b1
  Candidate: 3.2.1+dfsg-4+b1
  Version table:
 *** 3.2.1+dfsg-4+b1 500
500 mirror+file:/etc/apt/mirrors.list testing/main amd64 Packages
 10 https://deb.debian.org/debian unstable/main amd64 Packages
100 /var/lib/dpkg/status


-- 
Cheers,
  Andrej

Bug#1029294: dnf-plugins-core reposync plugin requires a higher version of dnf package

[Keyu Tao]

Package: dnf-plugins-core
Version: 4.3.1-2~bpo11+1
Severity: important
X-Debbugs-Cc: taok...@outlook.com

Dear Maintainer,

dnf-plugins-core provides a reposync implementation as the alternative of the 
nonexist package yum-utils.
In /usr/lib/python3/dist-packages/dnf-plugins/reposync.py, it calls:

```
base._download_remote_payloads(payloads, drpm, progress, None, False)
```

However, in dnf 4.5.2, the current version in bullseye and bookworm, this 
function only takes 4 positional arguments:

(/usr/lib/python3/dist-packages/dnf/base.py)

```
def _download_remote_payloads(self, payloads, drpm, progress, callback_total):
```

In dnf 4.14.0, the current version in sid, it takes 5 positional arguments:

```
def _download_remote_payloads(self, payloads, drpm, progress, callback_total, 
fail_fast=True):
```

Thus the reposync plugin may not be usable in bookworm (and 
bullseye-backports): You may meet following backtrace:

```
Traceback (most recent call last):
  File "/usr/bin/dnf", line 58, in 
main.user_main(sys.argv[1:], exit_code=True)
  File "/usr/lib/python3/dist-packages/dnf/cli/main.py", line 201, in user_main
errcode = main(args)
  File "/usr/lib/python3/dist-packages/dnf/cli/main.py", line 67, in main
return _main(base, args, cli_class, option_parser_class)
  File "/usr/lib/python3/dist-packages/dnf/cli/main.py", line 106, in _main
return cli_run(cli, base)
  File "/usr/lib/python3/dist-packages/dnf/cli/main.py", line 122, in cli_run
cli.run()
  File "/usr/lib/python3/dist-packages/dnf/cli/cli.py", line 1167, in run
return self.command.run()
  File "/usr/lib/python3/dist-packages/dnf-plugins/reposync.py", line 157, in 
run
self.download_packages(pkglist)
  File "/usr/lib/python3/dist-packages/dnf-plugins/reposync.py", line 306, in 
download_packages
base._download_remote_payloads(payloads, drpm, progress, None, False)
TypeError: _download_remote_payloads() takes 5 positional arguments but 6 were 
given
```

For reproducing this bug, I created a config file (k8s.conf):

```
[main]
keepcache=0
cachedir=/tmp/

[kubernetes-el7-x86_64]
name=kubernetes-el7-x86_64
baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-x86_64
repo_gpgcheck=0
gpgcheck=0
enabled=1
```

And then:

```
dnf reposync -a x86_64 -c k8s.conf --delete -p /path/to/packages
```

Although I'm using the backported version of dnf-plugins-core, it's certain 
that this bug should also affects bookworm (testing).

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

Kernel: Linux 6.0.0-0.deb11.6-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages dnf-plugins-core depends on:
ii  dnf   4.5.2-6
ii  python3   3.9.2-3
ii  python3-dbus  1.2.16-5
ii  python3-dnf   4.5.2-6

dnf-plugins-core recommends no packages.

dnf-plugins-core suggests no packages.

-- Configuration Files:
/etc/dnf/plugins/local.conf changed [not included]

-- no debconf information

Bug#1029145: fontconfig: the selection of the Bitstream font is broken, increasing the height, e.g. in the menus

[Simon McVittie]

On Wed, 18 Jan 2023 at 15:35:54 +0100, Vincent Lefevre wrote:
> After the upgrade from fontconfig 2.13.1-4.5 to fontconfig 2.14.1-3,
> the selection of the Bitstream font is broken

There is no font of that name in Debian. Bitstream is (was?) a font
foundry, not a font, so asking for a font named "Bitstream" is like
asking for an application named "Microsoft" if what you actually wanted
was Microsoft Word.

> With fontconfig 2.13.1-4.5,
> 
> cventin% fc-match Bitstream
> Vera.ttf: "Bitstream Vera Sans" "Roman"
> 
> With fontconfig 2.14.1-3,
> 
> cventin% fc-match Bitstream
> NotoSans-Regular.ttf: "Noto Sans" "Regular"

I can reproduce this. I think this is happening because you don't have any
font named "Bitstream" installed (and neither do I), so fontconfig is
falling back to looking for *any* font, for which its default seems to be
to go through a list of sans-serif fonts in preference order:

$ fc-match "Bitstream Vera Sans"
Vera.ttf: "Bitstream Vera Sans" "Roman"
$ fc-match "Bitstream"
NotoSans-Regular.ttf: "Noto Sans" "Regular"
$ fc-match "hello, world"
NotoSans-Regular.ttf: "Noto Sans" "Regular"

So I think this is probably working as intended, and the configuration
change that prompted your different font rendering is that fontconfig
2.13.1 had Bitstream Vera Sans as its fallback font, whereas 2.14.1 has
Noto Sans and DejaVu Sans listed as its preferred sans-serif fonts for
Latin text, as a result of

and then
.

In a bullseye container with the older fontconfig:

# apt install fontconfig fonts-noto ttf-bitstream-vera
# fc-match "hello, world"
Vera.ttf: "Bitstream Vera Sans" "Roman"

which would seem consistent with what I said above.

Please configure applications to use Bitstream Vera Sans, Bitstream
Vera Serif or Bitstream Vera Sans Mono, whichever is most appropriate
for your use-case, instead of "Bitstream".

However, Bitstream Vera is essentially unmaintained, so consider using
the DejaVu family (community-maintained forks of Bitstream Vera with
wider glyph coverage, which had to change the name for licensing reasons)
from the fonts-dejavu-core and optionally fonts-dejavu-extra packages,
in preference to ttf-bitstream-vera.

smcv

Bug#1027326: kde-plasma-desktop: Process 1465 (kded5) of user 1000 dumped core.

[Bernhard Übelacker]

On Fri, 30 Dec 2022 09:46:49 -0300 craudio  wrote:


#8  0x7f2ba43e5b99 n/a (kded_apperd.so + 0xeb99)
#9  0x7f2becae8fcf n/a (libQt5Core.so.5 + 0x2e8fcf)
#10 0x7f2ba4323095 
_ZN10PackageKit6Daemon22transactionListChangedERK11QStringList 
(libpackagekitqt5.so.1 + 0xe095)



Hello,
this seems similar to the backtrace in bug #1026062.
At least the "transactionListChanged" and the two lines above.

Kind regards,
Bernhard


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

Bug#1029168: fonts-urw-base35: Apache pdfbox cannot load fonts. Complains "Start marker missing"

[Roland Rosenfeld]

On Fri, 20 Jan 2023, Roland Rosenfeld wrote:

> Anyway, it still may be a good idea to run the t1 file through
> t1binary(1) at build time to add this 80 01 91 03 00 00 header.
> 
> So I tried so in
> https://salsa.debian.org/roland/fonts-urw-base35/-/commits/t1binary
> which I expected to work in the same way as 20200910-6 does, but I had
> to notice, that my above mentioned xfig test fails with century
> schoolbook font now sometimes (okay, I reproduced this multiple times
> while switching between -6 and my -7, but now I cannot reproduce the
> issue any longer with my -7, maybe I should pause and try this out
> later (maybe on a different machine)...

In the meantime I noticed, that the above branch isn't a good idea,
since
 t1binary C059-Italic.t1
results in an broken font.
 t1lint C059-Italic.t1
on the _converted_ font reports
 While interpreting 'uni04AE':
  command 19: stack underflow in 'hstem'

This is because t1utils fails on C059-Italic.t1.  I just reported this
as a bug in t1utils: #1029289.

> PS: Just noticed, that the build pipeline of my above t1binary
> branch fails because the converted C059-Italic.t1 now triggers the
> flowing warning:
> "cp1252 "\x90" does not map to Unicode at
> /usr/share/lintian/lib/Lintian/Check/Fonts/Postscript/Type1.pm
> line 57."
> (whatever this means, maybe some bug in lintian).

This problem is also triggered by t1utils fails on the C059-Italic.t1
font.  This time
 t1disasm C059-Italic.t1
contains some parts of the font as binary in the disasm output (which
is expected to be clean ascii), which results in the above lintian
failure.

Greetings
Roland

Bug#1010653: busco: add autopkgtest to check integration with hmmer and prodigal

[Sascha Steinbiss]

Hi,

I'm at the Debian Med sprint and currently taking a look at various 
things to take care of.


[...]

To have BUSCO lineages in the archive their licensing details have to
be clarified as the data does not contain any explicit statements.

The website [0] states that

  The BUSCO datasets are licensed under the Creative Commons
  Attribution-NoDerivatives 4.0 International License. To view a copy of
  this license, visit http://creativecommons.org/licenses/by-nd/4.0/ or
  send a letter to Creative Commons, PO Box 1866, Mountain View, CA
  94042, USA.

The lineages and the URL you mention are referenced as the "datasets" so 
that seems to be the license statement.
Consequently I guess including them in the package for the autopkgtest 
is not an option as the ND clause in their license is incompatible with 
DFSG. We might still download one of them at autopkgtest time but I am 
not sure that's a good idea. Any comments?


Best
Sascha

[0] https://busco.ezlab.org/#license



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1029293: wxhexeditor: undefined symbol when accessing wxWidgets library

[Jorge Moraleda]

Package: wxhexeditor
Version: 0.24+repack-2+b2
Severity: grave
Justification: renders package unusable
X-Debbugs-Cc: jorge.moral...@gmail.com

Dear Maintainer,

The current version of wxHexEditor fails to start with error:

wxHexEditor: symbol lookup error: wxHexEditor: undefined symbol:
_ZN12wxEvtHandler21WXReservedEvtHandler1EPv, version WXU_3.2

Perhaps this is related to the upgrade of the wxWidgets dependency from version
3.0 to version 3.2 as discussed in https://bugs.debian.org/cgi-
bin/bugreport.cgi?bug=1019812 ?


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

Kernel: Linux 6.0.0-6-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.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 wxhexeditor depends on:
ii  libc6   2.36-8
ii  libdisasm0  0.23-6+b1
ii  libgcc-s1   12.2.0-14
ii  libgomp112.2.0-14
ii  libmhash2   0.9.9.9-9
ii  libstdc++6  12.2.0-14
ii  libwxbase3.2-1  3.2.1+dfsg-4+b1
ii  libwxgtk3.2-1   3.2.1+dfsg-4+b1

wxhexeditor recommends no packages.

wxhexeditor suggests no packages.

-- no debconf information

Bug#1029292: lomiri-greeter: Depends: lomiri-system-compositor but it is not installable

[Adrian Bunk]

Package: lomiri-greeter
Version: 0.1~git20230111.ba0fc6a-4
Severity: serious

The following packages have unmet dependencies:
 lomiri-greeter : Depends: lomiri-system-compositor but it is not installable

Bug#1029291: qtmir-tests and qml-module-qtmir both ship qtmir-demo-client.desktop

[Adrian Bunk]

Package: src:qtmir
Version: 0.8.0~git20230115.30c2337-2
Severity: serious
Control: affects -1 qtmir-tests qml-module-qtmir

https://piuparts.debian.org/sid/fail/qtmir-tests_0.8.0~git20230115.30c2337-2.log

...
  Unpacking qtmir-tests (0.8.0~git20230115.30c2337-2) ...
  dpkg: error processing archive 
/tmp/apt-dpkg-install-4YfO5r/253-qtmir-tests_0.8.0~git20230115.30c2337-2_amd64.deb
 (--unpack):
   trying to overwrite '/usr/share/applications/qtmir-demo-client.desktop', 
which is also in package qml-module-qtmir:amd64 0.8.0~git20230115.30c2337-2
  Errors were encountered while processing:
   
/tmp/apt-dpkg-install-4YfO5r/253-qtmir-tests_0.8.0~git20230115.30c2337-2_amd64.deb
  E: Sub-process /usr/bin/dpkg returned an error code (1)

Bug#1029224: davegnukem: Does not compile on big endian

[Matteo Bini]

Hi Bastian,
thank you for the notice!

I've uploaded your suggested fix to mentors:
https://mentors.debian.net/package/davegnukem/

We will add retro settings for big-endian systems later. It's not an
important option since you can play the game without it, it's just a
visual filter to simulate EGA and CGA colours.

All the best!

--
Matteo Bini

Bug#1029290: dnf-plugins-core: Changelog plugin needs python3-dateutil as its dependency

[Keyu Tao]

Package: dnf-plugins-core
Version: 4.3.1-2~bpo11+1
Severity: normal
X-Debbugs-Cc: taok...@outlook.com

Dear Maintainer,

`dnf-plugins-core` does not include python3-dateutil as its dependency. 
When running commands like `dnf reposync`, it will display a "plugin load 
failure" warning like this:

```
Failed loading plugin "changelog": No module named 'dateutil'
```

It seems that it does not affect other plugins running, but it looks a little 
bit anonying.
Installing python3-dateutil silences this warning. Thus it may be necessary to 
make python3-dateutil
as dep or rec of dnf-plugins-core.

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

Kernel: Linux 6.0.0-0.deb11.6-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages dnf-plugins-core depends on:
ii  dnf   4.5.2-6
ii  python3   3.9.2-3
ii  python3-dbus  1.2.16-5
ii  python3-dnf   4.5.2-6

dnf-plugins-core recommends no packages.

dnf-plugins-core suggests no packages.

-- no debconf information

Bug#1029289: t1utils: t1disasm C059-Italic.t1 broken

[Roland Rosenfeld]

Package: t1utils
Version: 1.41-4
Severity: normal

Dear Maintainer,

during my tests with #1029168 I run into a lintian issue:

Warning in processable
[...]/fonts-urw-base35/debian/output/fonts-urw-base35_20200910-7+salsaci+20230120+4_all.deb:
In file usr/share/fonts/type1/urw-base35/C059-Italic.t1: cp1252 "\x90"
does not map to Unicode at
/usr/share/lintian/lib/Lintian/Check/Fonts/Postscript/Type1.pm line
57.

digging some deeper I had to notice that
 t1disasm C059-Italic.t1
(/usr/share/fonts/type1/urw-base35/C059-Italic.t1 from package
fonts-urw-base35) does not disassemble the complete file but returns
some binary data after the definition of /uni04E8.

Similar behavior, if I try to convert the font to ascii using
 t1ascii C059-Italic.t1
which has some binary data (instead of the expected hex data) near the
end of the output.

If I compare the output of
 t1disasm C059-Italic.t1
and
 t1disasm C059-BdIta.t1
that there are 206 character definitions missing at the end of the
output of the former.


First I thought, that C059-Italic.t1 is broken, but than I did some
testing with lcdf-typetools.
 t1lint C059-Italic.t1
does not shows only the same warning as I see on C059-BdIta.t1, but no
errors.
Creating a t1testpage for C059-Italic.t1 works and the result contains
the same charset than C059-BdIta.t1 including some characters, that
are missing in t1disasm output of C059-Italic.t1.

So maybe not the font is broken but t1utils.

If I try to convert C059-Italic.t1 to .pfa (using t1ascii) or to .pfb
(using t1binary), the resulting files are always broken.  t1lint shows
errors on both generated files and a generated t1testpage cannot be
opened (PS errors) and seems to have less pages than the testpage of
C059-Italic.t1.  So maybe this is a hint, that the problem does not
exist in the font but in t1utils, which is only triggered by this
special font.


Greetings
Roland

Bug#1029168: fonts-urw-base35: Apache pdfbox cannot load fonts. Complains "Start marker missing"

[Jorge Moraleda]

> I searched for some definition that says, that a .pfb file has to
> be prefixed with 80 01 91 03 00 00 (in front of %!PS-AdobeFont-1.),
> but didn't find such a specification.

I found this in case it helps
https://personal.math.ubc.ca/~cass/piscript/type1.pdf

Bug#1028608: evdi-dkms: EVDI module does not build with linux-headers-6.0.0-6-amd64

[Andreas Beckmann]

Control: tag -1 unreproducible
Control: severity -1 normal

Hi,

On Fri, 13 Jan 2023 16:16:12 +0100 Miroslav Maiksnar 
 wrote:

Error! Bad return status for module build on kernel: 6.0.0-6-amd64 (x86_64)


I cannot reproduce that with the Linux 6.1 kernel currently in sid.


Andreas

Bug#1027871: evdi: please switch to B-D: dh-sequence-dkms (or dh-dkms)

[Andreas Beckmann]

Followup-For: Bug #1027871
Control: tag -1 patch pending

Hi,

I've prepared a NMU and uploaded it to DELAYED/10. Please let me know if
I should delay it longer or cancel it.


Andreas
diff -Nru evdi-1.12.0+dfsg/debian/changelog evdi-1.12.0+dfsg/debian/changelog
--- evdi-1.12.0+dfsg/debian/changelog   2022-11-01 16:56:26.0 +0100
+++ evdi-1.12.0+dfsg/debian/changelog   2023-01-20 18:37:23.0 +0100
@@ -1,3 +1,12 @@
+evdi (1.12.0+dfsg-0.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Switch to dh-sequence-dkms.  (Closes: #1027871)
+  * Switch to Testsuite: autopkgtest-pkg-dkms.
+  * Do not build the module for kernels without CONFIG_I2C.
+
+ -- Andreas Beckmann   Fri, 20 Jan 2023 18:37:23 +0100
+
 evdi (1.12.0+dfsg-0.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru evdi-1.12.0+dfsg/debian/control evdi-1.12.0+dfsg/debian/control
--- evdi-1.12.0+dfsg/debian/control 2022-11-01 16:56:26.0 +0100
+++ evdi-1.12.0+dfsg/debian/control 2023-01-20 18:24:04.0 +0100
@@ -2,12 +2,17 @@
 Section: misc
 Priority: optional
 Maintainer: Hanno Stock 
-Build-Depends: debhelper-compat (= 13), dh-dkms, dkms, dh-exec, libdrm-dev
+Build-Depends:
+ debhelper-compat (= 13),
+ dh-sequence-dkms,
+ dh-exec,
+ libdrm-dev,
 Standards-Version: 4.5.0
 Rules-Requires-Root: no
 Homepage: https://github.com/DisplayLink/evdi
 Vcs-Browser: https://salsa.debian.org/hansto-guest/evdi
 Vcs-Git: https://salsa.debian.org/hansto-guest/evdi.git
+Testsuite: autopkgtest-pkg-dkms
 
 Package: evdi-dkms
 Architecture: all
diff -Nru evdi-1.12.0+dfsg/debian/evdi-dkms.dkms 
evdi-1.12.0+dfsg/debian/evdi-dkms.dkms
--- evdi-1.12.0+dfsg/debian/evdi-dkms.dkms  2022-11-01 16:54:13.0 
+0100
+++ evdi-1.12.0+dfsg/debian/evdi-dkms.dkms  2023-01-20 18:34:37.0 
+0100
@@ -9,6 +9,7 @@
 PACKAGE_NAME="evdi"
 PACKAGE_VERSION="#MODULE_VERSION#"
 AUTOINSTALL=yes
+BUILD_EXCLUSIVE_CONFIG="CONFIG_I2C"
 
 MAKE[0]="make -C ${kernel_source_dir} 
M=${dkms_tree}/${PACKAGE_NAME}/${PACKAGE_VERSION}/build DKMS_BUILD=1"
 DEST_MODULE_LOCATION[0]="/kernel/drivers/gpu/drm/evdi"
diff -Nru evdi-1.12.0+dfsg/debian/rules evdi-1.12.0+dfsg/debian/rules
--- evdi-1.12.0+dfsg/debian/rules   2022-11-01 16:54:13.0 +0100
+++ evdi-1.12.0+dfsg/debian/rules   2023-01-20 18:20:52.0 +0100
@@ -7,7 +7,7 @@
 export DEB_BUILD_MAINT_OPTIONS=hardening=+bindnow
 
 %:
-   dh $@ --with dkms
+   dh $@
 
 override_dh_auto_install:
dh_install -p evdi-dkms -XLICENSE module/* 
usr/src/evdi-$(DEB_VERSION_UPSTREAM)/
diff -Nru evdi-1.12.0+dfsg/debian/source/lintian-overrides 
evdi-1.12.0+dfsg/debian/source/lintian-overrides
--- evdi-1.12.0+dfsg/debian/source/lintian-overrides2022-11-01 
16:54:13.0 +0100
+++ evdi-1.12.0+dfsg/debian/source/lintian-overrides2023-01-20 
18:27:15.0 +0100
@@ -2,4 +2,4 @@
 # the shared library
 dh-exec-subst-unknown-variable
 # Upstream does not provide signatures
-debian-watch-does-not-check-gpg-signature
+debian-watch-does-not-check-openpgp-signature
diff -Nru evdi-1.12.0+dfsg/debian/tests/control 
evdi-1.12.0+dfsg/debian/tests/control
--- evdi-1.12.0+dfsg/debian/tests/control   2022-11-01 16:54:13.0 
+0100
+++ evdi-1.12.0+dfsg/debian/tests/control   1970-01-01 01:00:00.0 
+0100
@@ -1,3 +0,0 @@
-Tests: dkms-build
-Restrictions: needs-root, allow-stderr, isolation-machine
-Depends: @, dkms
diff -Nru evdi-1.12.0+dfsg/debian/tests/dkms-build 
evdi-1.12.0+dfsg/debian/tests/dkms-build
--- evdi-1.12.0+dfsg/debian/tests/dkms-build2022-11-01 16:54:13.0 
+0100
+++ evdi-1.12.0+dfsg/debian/tests/dkms-build1970-01-01 01:00:00.0 
+0100
@@ -1,5 +0,0 @@
-#!/bin/sh
-export DEBIAN_FRONTEND=noninteractive
-KVER=$(uname -r)
-apt-get install -y "linux-headers-$KVER"
-/usr/lib/dkms/dkms-autopkgtest

Bug#1002485: Source package dependency broken in nodejs package

[Jérémy Lal]

Package: nodejs
Followup-For: Bug #1002485

It takes time to handle precise versioning of dependencies,
and you gave us the solution:
I'm sorry we didn't apply it in the latest security update.
Did all the tests pass with these changes ?

For debhelper-compat, that's a patch you have to carry in ubuntu, though.

Don't hesitate to ping me again in the future (bookworm...).

Bug#1022843: ifupdown: network down after systemctl restart

[Jeff King]

On Sat, Oct 29, 2022 at 10:33:26AM +, Oleg A. Arkhangelsky wrote:

> Since the unit type is oneshot, we can have multiple ExecStart statements.
> 
> Note that we have to use '--ignore-errors'. Otherwise if we have real
> hotplug interface that is not present at the moment of restart, `ifup`
> returns non-zero and systemd unit fail.
> 
> 
> diff --git a/debian/networking.service b/debian/networking.service
> index 593172b..7ad246b 100644
> --- a/debian/networking.service
> +++ b/debian/networking.service
> @@ -16,6 +16,7 @@ WantedBy=network-online.target
>  Type=oneshot
>  EnvironmentFile=-/etc/default/networking
>  ExecStart=/sbin/ifup -a --read-environment
> +ExecStart=/sbin/ifup -a --allow=hotplug --ignore-errors --read-environment

This has the minor downside that on system startup, we'll spend time
trying to bring up allow-hotplug interfaces, even if they're not
available. So on my system, for example, with:

  allow-hotplug eth0
  iface eth0 inet dhcp

  auto wlan0
  iface wlan0 inet manual
  wpa-roam /etc/wpa_supplicant/wpa_supplicant.conf

this introduces a 10-second lag to the boot process as the dhcp client
broadcasts over eth0, which has no cable plugged in (it's udhcpc in my
case, but I imagine it would be the same for any client).

It's definitely less bad than the problem you were fixing. But it makes
me wonder if the solution here is neglecting the reason that these
interfaces are marked allow-hotplug and not "auto" in the first place.

-Peff

Bug#1016963: u-boot on A20-MICRO

[Arne Ploese]

I was successfully able to install the SD image for stable and unstable
(daily with u-boot from 2023-01-18.

Then I upgraded stable to testing und updated u-boot to 2023.01+dfsg1.

Arne

Bug#1026169: dhcpcd5: Please rename source package to dhcpcd

[Benjamin Drung]

On Sun, 2023-01-08 at 14:18 +0200, Martin-Éric Racine wrote:
> On Thu, Dec 15, 2022 at 8:44 PM Martin-Éric Racine
>  wrote:
> > 
> > On Thu, Dec 15, 2022 at 8:30 PM Benjamin Drung  wrote:
> > > The source package name `dhcpcd5` does not reflect the reality any more.
> > > Debian stable ships version 7 and testing/unstable version 9, but the
> > > source package name indicates that is the version 5.
> > > 
> > > Please rename the source package from `dhcpcd5` back to `dhcpcd` and
> > > probably also the binary package.
> > 
> > I fully agree. I've been meaning to do that at the same time as I
> > upload 9.4.2, pending upstream release. Now that upstream has informed
> > me that the next release is unlikely to happen until some time next
> > month (too close to the freeze), I might do it during the Christmas
> > vacations instead.
> 
> I just uploaded a package that handles the binary transition to
> Mentors. Sponsors are welcome.
> 
> Beyond that, renaming the src package will be a tad more involved,
> since Git repositories on Salsa and on my development host need to be
> migrated to the new namespace, and the content of d/control and
> d/copyright upgraded to match.

Thanks. Let me know if you need help renaming the Git repositories on
Salsa.

-- 
Benjamin Drung
Debian & Ubuntu Developer

Bug#1027686: Rakudo transition is stuck ?

[Dominique Dumont]

Hi

Nothing is happening in rakudo transition [1], no package are rebuilt.

Is there a way to unblock this transition ?

All the best


[1] https://release.debian.org/transitions/html/rakudo.html

Bug#1029153: virtualbox: CVE-2023-21884 CVE-2023-21885 CVE-2023-21886 CVE-2023-21889 CVE-2023-21898 CVE-2023-21899

[Andres Salomon]

On Wed, 18 Jan 2023 17:28:47 +0100 =?UTF-8?Q?Moritz_M=C3=BChlenhoff?= 
 wrote:

> Source: virtualbox
> X-Debbugs-CC: t...@security.debian.org
> Severity: grave
> Tags: security
>
> Hi,
>
> The following vulnerabilities were published for virtualbox.
>
> Fixed in 7.0.6
>

Also fixed in 6.1.42. Bullseye-fasttrack currently has 6.1.40. I'm 
curious if you think the 7.0 series is stable enough for 
bullseye-fasttrack yet?

Bug#1029232: dask.distributed: broken by version mismatch with dask

[Diane Trout]

On Fri, 2023-01-20 at 07:57 +, Rebecca N. Palmer wrote:
> Package: python3-distributed
> Version: 2022.02.0+ds1-3
> Severity: serious
> 
> dask.distributed has been failing its autopkgtests since dask was 
> upgraded to 2022.12.1.

Yep.

Andreas did the upload of dask 2022.12.1 with out asking me about it
first. I've been desperately trying to get dask.distributed 2022.12.1
to build and run all it's tests since then.

I'm still not done.

Sadly because of the networking use dask.distributed is incompatible
with xdist and so I can't speed up the tests.

Bug#1019293: python3-pip: installs setup_requires into /tmp/.../overlay/local/bin but then adds /tmp/.../overlay/bin to PATH

[stefanor]

Hi Simon (2023.01.20_13:54:00_+)
> > That will use the posix_local scheme by default on Debian, which won't do
> > what pip expects, when it assumes the posix_prefix scheme to be used.
> > Probably selecting having pip explicitly select posix_prefix when
> > --prefix is supplied would make sense. I don't know what the pip
> > upstream will think about having to do that...
> 
> I think https://github.com/pypa/pip/pull/11623 might be the upstream
> solution for this?

Thanks for that, it looks like a step in the right direction, but I'm
afraid it doesn't solve your bug, yet, for a system-wide pip install.

SR

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272

Bug#1029288: please build tracker-miners with fanotify support

[Roderich Schupp]

Source: tracker-miners
Version: 3.4.3-1
Severity: wishlist
X-Debbugs-Cc: roderich.sch...@gmail.com

Recently I noticed that tracker-miner-fs uses its inotify backend

Jan 20 17:07:10 nuc8 tracker-miner-f[306583]: Monitor backend is Inotify

whereas I expected it to use the newer, more efficient fanotify backend
(running on a 6.1.x Linux kernel). The build log for the running version
(https://buildd.debian.org/status/fetch.php?pkg=tracker-
miners&arch=amd64&ver=3.4.3-1&stamp=1674159607&raw=0) shows:

Checking if "fanotify works without additional capabilities" runs: NO (1)

The reason seems to be this check: https://salsa.debian.org/gnome-team/tracker-
miners/-/blob/debian/master/meson.build#L179

According to fanotify_init(2), fanotify may be used without the CAP_SYS_ADMIN
capability (with reduced functionality) since kernel 5.13, but apparently the
build host (x86-conova-01.debian.org) was running an older kernel.

If I read https://salsa.debian.org/gnome-team/tracker-
miners/-/blob/debian/master/src/libtracker-miner/tracker-monitor.c#L379
correctly, tracker-miner-fs will simply fall back to the inotify backend
when initializing the fanotify backend fails (e.g. due to missing CAP_SYS_ADMIN
when running on older kernels).

Cheers, Roderich




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

Kernel: Linux 6.2.0-rc4 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Bug#1026231: debian-policy: document droppage of support for legacy locales

[Simon McVittie]

On Fri, 20 Jan 2023 at 09:54:21 -0700, Anthony Fok wrote:
> supposedly some older Chinese websites are still using "GBK" as
> encoding, probably something like:
> 
>  
> 
> which has less than 30,000 characters and thus a very limited subset
> of Unicode.  And, presumably not everyone has the know how to convert
> to UTF-8, the Chinese government wants those unable to at least change
> that meta tag to:
> 
>  

Sure, but neither of those actually require us to support GBK or GB
18030 as a system locale, only as something that iconv() (or whatever
browsers actually use, which is probably their own thing) can convert
into their preferred internal representation (which is almost certainly
UTF-8, UTF-16 or UCS-4).

Analogously, we've never supported using Windows-1252 (Microsoft's
legacy Latin-1 variant) as a system locale encoding in some hypothetical
locale like en_US.windows-1252, but HTML documents with
text/html;charset=windows-1252 still work fine.

> I have the feeling that many tech-savvy Chinese have already switched
> to UTF-8, but then perhaps in some circles there are lots of legacy
> GB2312/GBK documents or systems that made GB18030 a necessity, as an
> intermediate step to Unicode.

That doesn't seem so far away from how in some English-speaking circles
there are lots of legacy ISO-8859-1, ISO-8859-15 or (more likely)
Windows-1252 documents, and we can cope OK with those via transcoding,
even in UTF-8 system locales.

smcv

Bug#1016882: Update on the bug reported(reason for regeneration figured out)

[Andreas Beckmann]

On Thu, 11 Aug 2022 00:45:56 +0530 Tanmay Bora 
 wrote:

But now as REMAKE_INITRD is deprecated there should be some other method
for automatically regenerating the initrd after installing
broadcom-sta-dkms package or atleast the Debian wiki should be updated with
the additional note of manually regenerating the initrd after installing
the package.


That sounds like the postinst should call

dpkg-trigger --no-await update-initramfs

or you can simply add debian/broadcom-sta-dkms.triggers with the 
following line:


activate-noawait update-initramfs

to do that without creating a postinst script.
(both solutions untested)


Andreas

Bug#1026231: debian-policy: document droppage of support for legacy locales

[Adam Borowski]

On Fri, Jan 20, 2023 at 03:57:17PM +0200, Wouter Verhelst wrote:
> On Thu, Jan 19, 2023 at 11:47:42AM +, Simon McVittie wrote:
> > Preferring to use Unicode does seem to be the direction that all of
> > computing is going in, as a simplifying assumption - for example W3C
> > advice for HTML is "You should always use the UTF-8 character encoding"[1]
> > - and as we know, things that aren't tested usually don't work. So I
> > think the level of functionality for non-UTF-8 locales and encodings in
> > the software we package is going to decline over time, whether Debian
> > wants it to or not.
> 
> If the world's most populous country uses something that is not UTF-8, I
> think it's safe to say it's being tested, if only by people who will
> file bugs when things go awry.

And we do know there's not a single bug filed with a GB* locale within the
last 12 years.

There's far fewer reports from Chinese people than the population would
indicate: 0.75% of those with locale information, but that's still 3241
reports; I find it implausible that there's a non-negligible number of
users that go with GB* yet not a single of them gave a single bit of
feedback.

> If the PRC government *requires* a non-UTF-8 encoding for things sold to
> them, we would be doing our users who want to sell a product containing
> Debian to the PRC government a disservice by dropping support for it
> altogether.

It appears to me they require the character _set_ but not encoding: ie,
that all glyphs can be displayed, they can be entered from keyboard, etc.
The standard talks a lot about font support, etc.

> We don't have to ensure it works perfectly out of the box; just that
> support is achievable with a reasonable amount of work.

Our installer doesn't allow choosing such a locale, thus if indeed the
encoding not character set is legally required, then we'd need to change
so before the release.

But I don't expect that to be the case -- a few years ago I played with
Deepin and don't remember any weird encoding being used.  It would be good
to either check again, or ask one of their maintainers.

But for now, I gotta run.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Let's make a Debian conference in Yalta, Ukraine.
⢿⡄⠘⠷⠚⠋⠀
⠈⠳⣄

Bug#1027872: falcosecurity-libs: please switch to B-D: dh-sequence-dkms (or dh-dkms)

[Dima Kogan]

Hi. I was planning to get the new upstream release going, but I hit a
bug in their build system that I don't have time to fix. The bug: shared
objects are being built, but their "install" step tries to install
static ones.

I'm unlikely to have the time to fix this in the near future, so I'm
just going to upload the current release + your changes. Will do that
later today, hopefuly.

Bug#1029287: progress-linux-desktop: Depends: webext-ublock-origin but it is not installable

[Adrian Bunk]

Package: progress-linux-desktop
Version: 20221002-3
Severity: serious

The following packages have unmet dependencies:
 progress-linux-desktop : Depends: webext-ublock-origin but it is not 
installable


The transitional package webext-ublock-origin that depended on both
webext-ublock-origin-firefox and webext-ublock-origin-chromium was
removed.