date:20230831

Source: nsd
Version: 4.7.0-1
Severity: normal

Dear Maintainer,

I had purged nsd, but
-- >8 --
nsd:x:116:122::/var/lib/nsd:/usr/sbin/nologin
-- >8 --
and
-- >8 --
nsd:x:122:
-- >8 --

/var/lib/nsd doesn't exist, so accd'g to dh_sysuser(1),
nsd is safe to get killed, but clearly wasn't?

Best,
наб

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

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


signature.asc
Description: PGP signature

Bug#1050983: djbdns: leaves behind rbldns and tinydns users and groups

Source: djbdns
Version: 1:1.05-15
Severity: normal

Dear Maintainer,

I had purged these packages, and yet
-- >8 --
rbldns:x:117:123::/var/lib/rbldns:/usr/sbin/nologin
tinydns:x:996:996:Created by dh-sysuser for 
tinydns:/nonexistent:/usr/sbin/nologin
-- >8 --
and
-- >8 --
rbldns:x:123:
tinydns:x:996:
-- >8 --

Naturally, /nonexistent doesn't exist. Neither does /var/lib/rbldns.
Accd'g to dh_sysuser(1), this should mean the users are safe to delete
and should get deleted by dh-sysuser.
Clearly not!

Best,
наб

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

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


signature.asc
Description: PGP signature

Bug#1050982: pdns-recursor: leaves behind pdns user and group

# deluser pdns
info: Removing crontab ...
info: Removing user `pdns' ...
# rm -d /var/spool/powerdns
(apparently! find /etc/ /var/ /usr/ -name 'p*dns' returns empty now).

crontab -s didn't list pdns but deluser clearly did, so?


signature.asc
Description: PGP signature

Bug#1050982: pdns-recursor: leaves behind pdns user and group

Package: pdns-recursor
Version: 4.7.3-1+b1
Severity: normal

Dear Maintainer,

$ dpkg -l | grep pdns
$ id pdns
uid=113(pdns) gid=119(pdns) groups=119(pdns)

I'd just uninstalled pdns-recursor, so this is probably due to that.

Best,
наб

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

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

Versions of packages pdns-recursor depends on:
ii  adduser3.137
ii  dns-root-data  2023010101
ii  libc6  2.37-6
ii  libcap21:2.66-4
ii  libcurl4   8.2.1-2
ii  libfstrm0  0.6.1-1
ii  libgcc-s1  13.2.0-1
pn  liblua5.3-0
pn  libsnmp40  
pn  libsodium23
ii  libssl33.0.10-1
ii  libstdc++6 13.2.0-1
ii  libsystemd0254.1-3
ii  publicsuffix   20230209.2326-1

pdns-recursor recommends no packages.

pdns-recursor suggests no packages.


signature.asc
Description: PGP signature

Bug#1050981: xmonad: please set XDG_CURRENT_DESKTOP and use it to configure xdg-desktop-portal

Package: xmonad
Version: 0.17.1-1
Severity: normal
User: xdg-desktop-por...@packages.debian.org
Usertags: portals.conf

xdg-desktop-portal 1.17.x introduces a new way to select which portals will
be used for which desktop environments, modelled on mimeapps.list:

- each desktop environment should provide a file like
  /usr/share/xdg-desktop-portal/xmonad-portals.conf

- the filename is ${DESKTOP}-portals.conf where ${DESKTOP} is the desktop
  environment's entry in $XDG_CURRENT_DESKTOP (the same as the DesktopNames
  from /usr/share/{x,wayland-}sessions/*.desktop), folded to lower case

- sysadmins and users can override this via files named portals.conf or
  ${DESKTOP}-portals.conf in various locations like /etc/xdg-desktop-portal
  and ~/.config/xdg-desktop-portal

But as far as I can tell, XMonad doesn't set XDG_CURRENT_DESKTOP, so for
the purposes of this mechanism, it's not programmatically distinguishable
from any other desktop environment or window manager.

XDG_CURRENT_DESKTOP is also used in pre-existing freedesktop.org standards
like the OnlyShowIn/NotShowIn fields for .desktop files, and the ability to
provide a desktop-environment-specific mimeapps.list. Setting
XDG_CURRENT_DESKTOP would allow XMonad to participate in those
specifications.

The "GNOME Flashback (Xmonad)" session *does* set XDG_CURRENT_DESKTOP, but
to a value that is indistinguishable from the ordinary GNOME Flashback
session with the metacity window manager, and I don't know whether that's
the most appropriate thing for the purposes of desktop-specific
configuration or not.

To reproduce


* Start from a basic non-GUI virtual machine (I used autopkgtest-build-qemu)
* Ensure that a user account exists
* apt install lightdm xorg xmonad
* reboot
* Log in as the user account, selecting "XMonad" from the menu of
  possible X11 sessions
* In a ssh session as the same user, run:
  systemctl --user show-environment
* apt install gnome-session-flashback
* Repeat for the "GNOME Flashback (Xmonad)" session

(I couldn't work out how to open a shell in an otherwise unconfigured
XMonad session, but in any case it's the systemd activation environment
that matters here, more than `env`, because xdg-desktop-portal will
typically be run as a systemd user service.)

Expected result
===

XDG_CURRENT_DESKTOP should be set to a colon-separated sequence of
desktop environment names, most specific first. XMonad seems to be its
own thing rather than being based on another desktop environment or
window manager, so

XDG_CURRENT_DESKTOP=XMonad

would seem appropriate.

This would allow the XMonad session to have its own
desktop-environment-specific mimeapps.list or portals.conf(5), for
example /usr/share/xdg-desktop-portal/xmonad-portals.conf.

For XMonad's GNOME Flashback variant, I don't know whether
XDG_CURRENT_DESKTOP should be set to GNOME-Flashback:GNOME (exactly
the same as GNOME Flashback with metacity), or whether it would be better
to set it to something like XMonad-GNOME-Flashback:GNOME-Flashback:GNOME
so that XMonad's GNOME Flashback variant can have its own portal
configuration, mimeapps.list, OnlyShowIn/NotShowIn, etc. if it wants to
(in principle someone could develop a portal backend similar to
xdg-desktop-portal-gtk that works better with tiling window managers,
although I'm not aware of such a thing having been written).

Actual result
=

In the XMonad session, XDG_CURRENT_DESKTOP is unset.

This means that xdg-desktop-portal configuration can only be done via a
non-desktop-specific portals.conf, but that's not really something that a
non-opinionated distribution like Debian can usefully ship in a centralized
way, so each user of XMonad who wants a working xdg-desktop-portal will
have to configure it themselves.

At the moment, this is mitigated by xdg-desktop-portal (>= 1.17) having
been patched to fall back to xdg-desktop-portal-gtk as a last-resort
desktop-environment-specific backend, but hard-coding that implementation
isn't really something we should be doing centrally (and the idea was
rejected upstream), so I intend to remove that patch before trixie
is released.

For XMonad's GNOME Flashback variant, XDG_CURRENT_DESKTOP is currently set
to GNOME-Flashback:GNOME (exactly the same as GNOME Flashback with metacity),
so it will always use the same portal configuration, etc. as
gnome-session-flashback (see #1050799).

Suggested fix
=

Add a sequence of semicolon-separated desktop environment names to
/usr/share/xsessions/xmonad.desktop, most likely just "XMonad":

DesktopNames=XMonad;

(For example, icewm and windowmaker use "ICEWM" and "WindowMaker" in
their equivalent xsessions file.)

And then create a /usr/share/xdg-desktop-portal/xmonad-portals.conf
with whatever portal backends are desired for an XMonad session,
for example perhaps this:

[preferred]
default=gtk;

Please see portals.conf(5) or its source code

Bug#1050980: awesome: please set XDG_CURRENT_DESKTOP and use it to configure xdg-desktop-portal

Package: awesome
Version: 4.3-7
Severity: normal
User: xdg-desktop-por...@packages.debian.org
Usertags: portals.conf

xdg-desktop-portal 1.17.x introduces a new way to select which portals will
be used for which desktop environments, modelled on mimeapps.list:

- each desktop environment should provide a file like
  /usr/share/xdg-desktop-portal/awesome-portals.conf

- the filename is ${DESKTOP}-portals.conf where ${DESKTOP} is the desktop
  environment's entry in $XDG_CURRENT_DESKTOP (the same as the DesktopNames
  from /usr/share/{x,wayland-}sessions/*.desktop), folded to lower case

- sysadmins and users can override this via files named portals.conf or
  ${DESKTOP}-portals.conf in various locations like /etc/xdg-desktop-portal
  and ~/.config/xdg-desktop-portal

But as far as I can tell, awesome doesn't set XDG_CURRENT_DESKTOP, so for
the purposes of this mechanism, it's not programmatically distinguishable
from any other desktop environment or window manager.

XDG_CURRENT_DESKTOP is also used in pre-existing freedesktop.org standards
like the OnlyShowIn/NotShowIn fields for .desktop files, and the ability to
provide a desktop-environment-specific mimeapps.list. Setting
XDG_CURRENT_DESKTOP would allow awesome to participate in those
specifications.

To reproduce


* Start from a basic non-GUI virtual machine (I used autopkgtest-build-qemu)
* Ensure that a user account exists
* apt install lightdm xorg awesome
* reboot
* Log in as the user account, selecting "awesome" from the menu of
  possible X11 sessions
* Open a terminal and run:
  env | grep XDG_CURRENT_DESKTOP
  systemctl --user show-environment

(It's the systemd activation environment that matters here, more than
`env`, because xdg-desktop-portal will typically be run as a systemd
user service.)

Expected result
===

XDG_CURRENT_DESKTOP should be set to a colon-separated sequence of
desktop environment names, most specific first. awesome seems to be its
own thing rather than being based on another desktop environment or
window manager, so

XDG_CURRENT_DESKTOP=awesome

would seem appropriate.

This would allow the awesome session to have its own
desktop-environment-specific mimeapps.list or portals.conf(5), for
example /usr/share/xdg-desktop-portal/awesome-portals.conf.

Actual result
=

XDG_CURRENT_DESKTOP is unset.

This means that xdg-desktop-portal configuration can only be done via a
non-desktop-specific portals.conf, but that's not really something that a
non-opinionated distribution like Debian can usefully ship in a centralized
way, so each user of awesome who wants a working xdg-desktop-portal will
have to configure it themselves.

At the moment, this is mitigated by xdg-desktop-portal (>= 1.17) having
been patched to fall back to xdg-desktop-portal-gtk as a last-resort
desktop-environment-specific backend, but hard-coding that implementation
isn't really something we should be doing centrally (and the idea was
rejected upstream), so I intend to remove that patch before trixie
is released.

Suggested fix
=

Add a sequence of semicolon-separated desktop environment names to
/usr/share/xsessions/awesome.desktop, most likely just "awesome":

DesktopNames=awesome;

(For example, icewm and windowmaker use "ICEWM" and "WindowMaker" in
their equivalent xsessions file.)

And then create a /usr/share/xdg-desktop-portal/awesome-portals.conf
with whatever portal backends are desired for an awesome session,
for example perhaps this:

[preferred]
default=gtk;

Please see portals.conf(5) or its source code
https://github.com/flatpak/xdg-desktop-portal/blob/main/doc/portals-conf.rst
for full details.

Thanks,
smcv

-- 
This is part of a mass bug filing:
https://lists.debian.org/debian-devel/2023/08/msg00311.html

Bug#1050944: jtreg6: please make the build reproducible

2023-08-31 Thread tony mancill

On Thu, Aug 31, 2023 at 02:58:47PM -0700, Vagrant Cascadian wrote:
> On 2023-08-31, Chris Lamb wrote:
> > 2. The jtreg.jar file was being generated with 444 (read-only)
> > permissions. This meant that strip-determinism could not fixup the
> > file modification times of the files within that archive. It was
> > actually printing: "dh_strip_nondeterminism: warning: Ignoring unwritable
> > file: jtreg.jar".
> 
> Curious!
> 
> > --- a/debian/rules  2023-08-31 09:50:06.571624952 -0700
> > --- b/debian/rules  2023-08-31 10:08:31.850276393 -0700
> > @@ -33,3 +33,6 @@
> > # Generate the manpages
> > JT_HOME=./dist/jtreg/lib/ help2man --name="Regression Test Harness" 
> > --help-option="-help all" dist/jtreg/bin/jtdiff > jtdiff.1
> > JT_HOME=./dist/jtreg/lib/ help2man --name="Regression Test Harness" 
> > --help-option="-help all" dist/jtreg/bin/jtreg > jtreg.1
> > +
> > +execute_before_dh_strip_nondeterminism:
> > +   find  debian/ -type f -name jtreg.jar -print0 | xargs -0tr chmod +w
> 
> Maybe this should be restricted to only make it writeable to the user
> ... e.g. chmod u+w or similar?

Thank you for the patch and the suggestion.  I don't think it makes a
difference, because the jtreg.jar file ends with mod 644 in the binary
package, but I went with the following for symmetry:

execute_before_dh_strip_nondeterminism:
find  debian/ -type f -name jtreg.jar -print0 | xargs -0tr chmod u+w

execute_after_dh_strip_nondeterminism:
find  debian/ -type f -name jtreg.jar -print0 | xargs -0tr chmod u-w

diffoscope no longer reports differences between the built and rebuilt jar.

I intend to make a few more packaging changes before the upload, but you
can consider this bug pending.

Thanks,
tony


signature.asc
Description: PGP signature

Bug#1007213: please upgrade to Xpra 4

2023-08-31 Thread xwendekar

Also +1 to this. the debian xpra package was crashing fairly frequently 
on me (multiple times per day), always right after I closed a window. 
I'm now using the xpra 4 .deb from xpra.org and haven't had any issues

Bug#1050973: lastpass-cli: Please update to 1.3.5 upstream to fix certificate error

2023-08-31 Thread Chris Lamb

tags 1050973 + pending
thanks


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

Bug#1050979: debian-installer-12-netboot-amd64 Drive Order scrambled

2023-08-31 Thread Todd Morgan

Package: debian-installer-12-netboot-amd64 (20230607+deb12u1)
Net Installer:
https://deb.debian.org/debian/dists/bookworm/main/installer-amd64/current/images/netboot/mini.iso
Severity: high

Configured System:

HPE DL20
1x 480GB SSD
3x 960GB SSD

I am installing Debian Linux on servers using UEFI PXE and a preseed file
for a touchless installation. This has been our standard method for Debian
installs for years, starting with "buster." It has worked VERY reliably for
us.

When using the same method to install Debian 12, I am noticing that the
installer is detecting the drives out of order. It does not match what the
server BIOS or HPE ILO5 displays. With each PXE installation attempt the
ordering can vary. Looking in /dev/disk/by-path you can see the symlinks
differ between install attempts. Sometimes the order matches the PCI bus
reference and sometimes it's jumbled up.

This is an issue when you want to tell partman to use /dev/sda (the first
drive) for the installation and have grub installed properly on /dev/sda.
This is even worse when trying to do a software RAID1 via preseed. The
pairs of drives are not being selected in a predictable fashion.

Interestingly enough, after the installation is complete and the Debian 12
system is booted up, it always shows the drives in the proper order, 100%
of the time. But the boot media may or may not be the correct drive. This
is only an issue at install time.

This past week I performed dozens of PXE installs on a set of 3 servers.
Debian 11 had no problems. Only Debian 12 displayed this behavior on each
of the 3 servers. I tried updating firmware on all 3 servers so that it is
running the latest versions, but that had no effect.

Bug#1048039: xindy: Fails to build source after successful build

2023-08-31 Thread Preuße


Control: tags -1 + wontfix

On 13.08.2023 21:21, Lucas Nussbaum wrote:

Hi,


This package fails to build a source package after a successful build
(dpkg-buildpackage ; dpkg-buildpackage -S).

This is probably a clear violation of Debian Policy section 4.9 (clean target),
but this is filed as severity:minor for now, because a discussion on
debian-devel showed that we might want to revisit the requirement of a working
'clean' target.

That package has a weird build system and I'm now really willing to fix 
it. For now I tag the bug wontfix, in case it becomes an RC bug anybody 
else has to do that.


Sorry,
  Hilmar
--
sigfault



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1050978: dovecot-imapd: Error: Next message unexpectedly lost from mbox file /mnt/filling/mail/.../INBOX at 53591 (cached)

Package: dovecot-imapd
Version: 1:2.3.19.1+dfsg1-2.1
Severity: normal

Dear Maintainer,

neomutt suddenly started reporting 
-- >8 --
[00:36:25] SSL/TLS connection using TLS1.3 (ECDHE-RSA/AES-256-GCM/AEAD)
[00:36:26] Logging in...
[00:36:26] Error opening mailbox
-- >8 --
and in my journal I see
-- >8 --
Sep 01 00:23:44 tarta dovecot[1147629]: imap-login: Login: user=, 
method=PLAIN, rip=192.168.1.250, lip=192.168.1.250, mpid=1181955, TLS, 
session=
Sep 01 00:23:44 tarta dovecot[1147629]: imap(heniu)<1181955>: 
Error: Next message unexpectedly lost from mbox file 
/mnt/filling/mail/heniu/INBOX at 53591
(cached)
Sep 01 00:23:44 tarta dovecot[1147629]: imap(heniu)<1181955>: 
Panic: file istream.c: line 341 (i_stream_read_memarea): assertion failed: 
(old_size <= _stream->pos - _stream->skip)
Sep 01 00:23:44 tarta dovecot[1147629]: imap(heniu)<1181955>: 
Error: Raw backtrace: #0 test_subprocess_fork[0x7f418e976a20] -> #1 
backtrace_append[0x7f418e976c90] -> #2 backtrace_get[0x7f418e976e20] -> #3 
execvp_const[0x7f418e983f90] -> #4 i_syslog_fatal_handler[0x7f418e984900] -> #5 
i_panic[0x7f418e8da0a4] -> #6 i_fatal_status[0x7f418e8dbade] -> #7 
i_stream_read_copy_from_parent[0x7f418e990fa0] -> #8 
i_stream_read_memarea[0x7f418e9904f0] -> #9 
i_stream_read_copy_from_parent[0x7f418e990990] -> #10 
i_stream_create_binary_converter[0x7f418e95b6f0] -> #11 
i_stream_read_memarea[0x7f418e9904f0] -> #12 
i_stream_read_copy_from_parent[0x7f418e990990] -> #13 
i_stream_create_mail[0x7f418eb37690] -> #14 
i_stream_read_memarea[0x7f418e9904f0] -> #15 i_stream_read[0x7f418e990720] -> 
#16 i_stream_read_data[0x7f418e9907d0] -> #17 
message_get_body_size[0x7f418e9636f0] -> #18 
index_mail_init_stream[0x7f418eb254b0] -> #19 
mail_get_stream_because[0x7f418eaaddd0] -> #20 
index_mail_get_virtual_size[0x7f418eb270d0] -> #21 
mail_get_virtual_size[0x7f418eaa9540] -> #22 cmd_select[0x561b0c5aa070] -> #23 
imap_fetch_begin[0x561b0c5af170] -> #24 imap_fetch_more[0x561b0c5af550] -> #25 
cmd_fetch[0x561b0c5a3c00] -> #26 command_exec[0x561b0c5ac880] -> #27 
cmd_x_cancel[0x561b0c5b2510] -> #28 cmd_x_cancel[0x561b0c5b2510] -> #29 
client_handle_input[0x561b0c5b2880] -> #30 client_input[0x561b0c5b2d80] -> #31 
io_loop_call_io[0x7f418e99bc70] -> #32 
io_loop_handler_run_internal[0x7f418e99d970] -> #33 
io_loop_handler_run[0x7f418e99db00] -> #34 io_loop_run[0x7f418e99dcd0] -> #35 
master_service_run[0x7f418e90e180] -> #36 main[0x561b0c59ea00] -> #37 
__libc_init_first[0x7f418e6b7150] -> #38 __libc_start_main[0x7f418e6b7200] -> 
#39 _start[0x561b0c59f000]
Sep 01 00:23:44 tarta dovecot[1147629]: imap(heniu)<1181955>: 
Fatal: master: service(imap): child 1181955 killed with signal 6 (core dumps 
disabled - https://dovecot.org/bugreport.html#coredumps)
Sep 01 00:23:46 tarta dovecot[1147629]: imap-login: Login: user=, 
method=PLAIN, rip=192.168.1.250, lip=192.168.1.250, mpid=1182148, TLS, 
session=
-- >8 --

Following the instruxions at the link, I can repro by running the imap
handler under GDB, and typescript is attached.

Point of note:
  * 641 EXISTS
agrees with what opening the INBOX file directly in neomutt says.

doveadm force-resync doesn't do anything.
doveadm rebuild attachments crashes in the same way:
-- >8 --
$ doveadm -D rebuild attachments -u heniu ALL
Debug: Loading modules from directory: /usr/lib/dovecot/modules/doveadm
Debug: Skipping module doveadm_acl_plugin, because dlopen() failed: 
/usr/lib/dovecot/modules/doveadm/lib10_doveadm_acl_plugin.so: undefined symbol: 
acl_user_module (this is usually intentional, so just ignore this message)
Debug: Skipping module doveadm_quota_plugin, because dlopen() failed: 
/usr/lib/dovecot/modules/doveadm/lib10_doveadm_quota_plugin.so: undefined 
symbol: quota_user_module (this is usually intentional, so just ignore this 
message)
Debug: Module loaded: 
/usr/lib/dovecot/modules/doveadm/lib10_doveadm_sieve_plugin.so
Debug: Skipping module doveadm_fts_lucene_plugin, because dlopen() failed: 
/usr/lib/dovecot/modules/doveadm/lib20_doveadm_fts_lucene_plugin.so: undefined 
symbol: lucene_index_iter_deinit (this is usually intentional, so just ignore 
this message)
Debug: Skipping module doveadm_fts_plugin, because dlopen() failed: 
/usr/lib/dovecot/modules/doveadm/lib20_doveadm_fts_plugin.so: undefined symbol: 
fts_user_get_language_list (this is usually intentional, so just ignore this 
message)
Debug: Skipping module doveadm_mail_crypt_plugin, because dlopen() failed: 
/usr/lib/dovecot/modules/doveadm/libdoveadm_mail_crypt_plugin.so: undefined 
symbol: mail_crypt_box_get_pvt_digests (this is usually intentional, so just 
ignore this message)
Debug: Loading modules from directory: /usr/lib/dovecot/modules/doveadm
Debug: Skipping module doveadm_acl_plugin, because dlopen() failed: 
/usr/lib/dovecot/modules/doveadm/lib10_doveadm_acl_plugin.so: undefined symbol: 
acl_user_module (this is usually intentional, so just ignore this message)
Debug: Skipping module doveadm_quota_plugin, because

Bug#1050945: guile-3.0: make guile-2.0 guile-2.2 and guile-3.0 installable parallel

2023-08-31 Thread Rob Browning

Ilari Jääskeläinen  writes:

> Package: guile-3.0
> Version: 3.0.8-2
> Severity: wishlist

Hmm, I think they 2.2 and 3.0 already are, and anything older is no
longer supported?

Here I have:

  $ dpkg --status guile-2.2 guile-3.0 | grep Version
  Version: 2.2.7+1-9
  Version: 3.0.8-2

  $ guile-2.2
  GNU Guile 2.2.7
  Copyright (C) 1995-2019 Free Software Foundation, Inc.

  Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
  This program is free software, and you are welcome to redistribute it
  under certain conditions; type `,show c' for details.

  Enter `,help' for help.
  scheme@(guile-user)>

  $ guile-3.0
  GNU Guile 3.0.8
  Copyright (C) 1995-2021 Free Software Foundation, Inc.

  Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
  This program is free software, and you are welcome to redistribute it
  under certain conditions; type `,show c' for details.

  Enter `,help' for help.
  scheme@(guile-user)>

Thanks
-- 
Rob Browning

Bug#1038907: libcurl4-nss-dev: NSS support will be dropped in August 2023

binNMUs scheduled, after they're done, curl 8.2.1-2 (first version
without nss support) should migrate to testing.

#1050974 nmu: llvm-toolchain-14_1:14.0.6-13
https://bugs.debian.org/1050974

#1050976 nmu: llvm-toolchain-15_1:15.0.7-8
https://bugs.debian.org/1050976

#1050977 nmu: eg25-manager_0.4.6-1
https://bugs.debian.org/1050977

-- 
Samuel Henrique

Bug#1050436: upower: autopkgtest regression on i386: excessive precision?

2023-08-31 Thread Michael Biebl


On Thu, 24 Aug 2023 17:18:35 +0200 Paul Gevers  wrote:

Source: upower 1.90.2-4
Severity: serious
Tags: sid trixie
X-Debbugs-CC: b...@debian.org
User: debian...@lists.debian.org
Usertags: regression
Control: affects -1 src:libgudev

Dear maintainer(s),

With a recent upload of upower, the autopkgtest of upower fails on i386 
in testing when that autopkgtest is run with the binary packages of 
upower and libgudev from unstable. It passes when run with only packages 
from testing. In tabular form:


passfail
libgudev   from testing238-2
upower from testing1.90.2-4
all others from testingfrom testing

I copied some of the output at the bottom of this report. Looking at the 
error this *seems* to me the result of the excessive precision of i386, 
but I hope the i386 porter (in XDCC) can shed his light on that too.


Currently this regression is blocking the migration of libgudev to 
testing [1]. Due to the nature of this issue, I filed this bug report 
against both packages. Can you please investigate the situation and 
reassign the bug to the right package?


More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=libgudev

https://ci.debian.net/data/autopkgtest/testing/i386/u/upower/37102682/log.gz

208s ==
208s FAIL: test_battery_energy_charge_mixed 
(__main__.Tests.test_battery_energy_charge_mixed)

208s battery which reports both current charge and energy
208s --
208s Traceback (most recent call last):
208s   File "/usr/libexec/upower/integration-test.py", line 887, in 
test_battery_energy_charge_mixed
208s self.assertEqual(self.get_dbus_dev_property(bat0_up, 
'Percentage'), 40.0)

208s AssertionError: 40.01 != 40.0


Adrian, as i386 porter, could you have a look at this?


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1050977: nmu: eg25-manager_0.4.6-1

Package: release.debian.org
Control: affects -1 + src:eg25-manager
X-Debbugs-Cc: eg25-mana...@packages.debian.org
User: release.debian@packages.debian.org
Usertags: binnmu
X-Debbugs-Cc: samuel...@debian.org
Severity: normal

nmu eg25-manager_0.4.6-1 . ANY . unstable . -m "Rebuild against curl without 
NSS support"

-- 
Samuel Henrique

Bug#1050974: nmu: llvm-toolchain-14_1:14.0.6-13

Right, so gmail added breaklines, correct command is:

nmu llvm-toolchain-14_1:14.0.6-13 . all amd64 arm64 armel armhf i386 mips64el 
ppc64el s390x hurd-i386 sparc64 . unstable . -m "Rebuild against curl without 
NSS support"

Cheers,

-- 
Samuel Henrique

Bug#1050975: rustc FTCBF amd64 -> arm64: error: unrecognized command-line option ‘-mbranch-protection=standard’

2023-08-31 Thread Helmut Grohne

Source: rustc
Version: 1.66.0+dfsg1-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

rustc fails to cross build from source, because it frowards CFLAGS meant
for the host compiler to the build compiler. When cross compiling on
amd64 for arm64, CFLAGS now contain -mbranch-protection=standard. This
is not understood by an amd64 compiler. I'm attaching a patch to address
the matter.

Helmut
diff --minimal -Nru rustc-1.66.0+dfsg1/debian/changelog 
rustc-1.66.0+dfsg1/debian/changelog
--- rustc-1.66.0+dfsg1/debian/changelog 2023-06-27 17:12:20.0 +0200
+++ rustc-1.66.0+dfsg1/debian/changelog 2023-08-31 21:40:47.0 +0200
@@ -1,3 +1,10 @@
+rustc (1.66.0+dfsg1-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Do not pass host CFLAGS to the build compiler. (Closes: #-1)
+
+ -- Helmut Grohne   Thu, 31 Aug 2023 21:40:47 +0200
+
 rustc (1.66.0+dfsg1-1) unstable; urgency=medium
 
   * Upload to unstable
diff --minimal -Nru rustc-1.66.0+dfsg1/debian/rules 
rustc-1.66.0+dfsg1/debian/rules
--- rustc-1.66.0+dfsg1/debian/rules 2023-06-20 20:22:34.0 +0200
+++ rustc-1.66.0+dfsg1/debian/rules 2023-08-31 21:40:47.0 +0200
@@ -14,7 +14,11 @@
 LOCAL_RUST_VERSION := $(shell rustc --version --verbose | sed -ne 's/^release: 
//p')
 
 include /usr/share/dpkg/buildflags.mk
-export CFLAGS CXXFLAGS CPPFLAGS LDFLAGS
+export TARGET_CFLAGS = $(CFLAGS)
+export TARGET_CXXFLAGS = $(CXXFLAGS)
+export TARGET_CPPFLAGS = $(CPPFLAGS)
+export TARGET_LDFLAGS = $(LDFLAGS)
+unexport CFLAGS CXXFLAGS CPPFLAGS LDFLAGS
 export CARGO_HOME = $(CURDIR)/debian/cargo
 
 # Defines DEB_*_RUST_TYPE triples

Bug#1050976: nmu: llvm-toolchain-15_1:15.0.7-8

Package: release.debian.org
Control: affects -1 + src:llvm-toolchain-15
X-Debbugs-Cc: llvm-toolchain...@packages.debian.org
User: release.debian@packages.debian.org
Usertags: binnmu
X-Debbugs-Cc: samuel...@debian.org
Severity: normal

nmu llvm-toolchain-15_1:15.0.7-8 . all amd64 arm64 armel armhf i386 mips64el 
ppc64el s390x . unstable . -m "Rebuild against curl without NSS support"

-- 
Samuel Henrique

Bug#1050393: Unneeded dependency on "dconf-gsettings-backend | gsettings-backend"?

2023-08-31 Thread John Zaitseff

I wrote:

> The latest (Sid) version of emacs-common now depends on
> "dconf-gsettings-backend | gsettings-backend", which in turn
> eventually installs dbus-daemon -- which is problematic in a
> Debian build chroot environment.  Can that dependency be
> downgraded to Recommends or Suggests?

After a bit of digging around through the package source code, this
is as a result of using the binaries from the "pgtk" build of Emacs
for common binaries -- since "other builds' emacsclients cannot
connect to pgtk under Wayland".

Given that that is a good reason, IMHO, for using the binaries in
that way, feel free to close this bug report.  I'll just have to
live with installing dbus-daemon in chroot environments...

Yours truly,

John Zaitseff

-- 
John Zaitseff   ╭───╮   Email: j.zaits...@zap.org.au
The ZAP Group   │ Z │   GnuPG: 0x0D254111C4EE569B
Australia Inc.  ╰───╯   https://www.zap.org.au/~john/

Bug#1050974: nmu: llvm-toolchain-14_1:14.0.6-13

Package: release.debian.org
Control: affects -1 + src:llvm-toolchain-14
X-Debbugs-Cc: llvm-toolchain...@packages.debian.org
User: release.debian@packages.debian.org
Usertags: binnmu
X-Debbugs-Cc: samuel...@debian.org
Severity: normal

nmu llvm-toolchain-14_1:14.0.6-13 . all amd64 arm64 armel armhf i386
mips64el ppc64el s390x hurd-i386 sparc64 . unstable . -m "Rebuild
against curl without NSS support"

-- 
Samuel Henrique

Bug#1036751: RFS: mini-httpd/1.30-4 [ITA] -- Small HTTP server

2023-08-31 Thread Alexandru Mihail

Hello,
Gently pinging about my last mail.
Sorry for nagging; I think we both want this release finalized and to
crack a cold one admiring our work :)

> I've commited and pushed the changes to the remote I was using for
> the
> MR so far:
> commit:
> https://salsa.debian.org/alexandru_mihail/mini-httpd/-/commit/fc7c4f664dc1369b1bf5d46c8c9b7aa11de68407
> 
> 
> But I think I may have not commited where I was supposed to, granted
> you've already closed the MR. I've already created a GPG signed tag
> accessible at:
> https://salsa.debian.org/alexandru_mihail/mini-httpd/-/tags/debian%2F1.30-4
> 
> The commit is not visible in the previous MR:
> https://salsa.debian.org/debian/mini-httpd/-/merge_requests/2?
> 
> Is there something I've glanced over here ?
> Otherwhise, the commit & tag are per your requirements.

Have a great one Nicholas !

Alexandru 
> 


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

Bug#1050944: jtreg6: please make the build reproducible

2023-08-31 Thread Vagrant Cascadian

On 2023-08-31, Chris Lamb wrote:
> 2. The jtreg.jar file was being generated with 444 (read-only)
> permissions. This meant that strip-determinism could not fixup the
> file modification times of the files within that archive. It was
> actually printing: "dh_strip_nondeterminism: warning: Ignoring unwritable
> file: jtreg.jar".

Curious!

> --- a/debian/rules2023-08-31 09:50:06.571624952 -0700
> --- b/debian/rules2023-08-31 10:08:31.850276393 -0700
> @@ -33,3 +33,6 @@
>   # Generate the manpages
>   JT_HOME=./dist/jtreg/lib/ help2man --name="Regression Test Harness" 
> --help-option="-help all" dist/jtreg/bin/jtdiff > jtdiff.1
>   JT_HOME=./dist/jtreg/lib/ help2man --name="Regression Test Harness" 
> --help-option="-help all" dist/jtreg/bin/jtreg > jtreg.1
> +
> +execute_before_dh_strip_nondeterminism:
> + find  debian/ -type f -name jtreg.jar -print0 | xargs -0tr chmod +w

Maybe this should be restricted to only make it writeable to the user
... e.g. chmod u+w or similar?


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1050685: elpa-debian-el: Error when using debian-bug on certain binary package: (wrong-type-argument processp nil)

2023-08-31 Thread Manphiz

David Bremner  writes:

> Control: tag -1 unreproducible
>
> Xiyue Deng  writes:
>
>> Package: elpa-debian-el
>> Version: 37.10
>> Severity: normal
>> X-Debbugs-Cc: none, Xiyue Deng 
>>
>> I've encountered an error when using "M-x debian-bug" on certain binary
>> package, such as linux-image-6.4.0-3-amd64.  The error backtrace look
>> like this:
>>
>
> I can't duplicate this in testing. Maybe try with a minimal config to
> isolate some interaction with other addons?
>
> d

Hmm, indeed I cannot reproduce this with "emacs -Q" either.  Will see
what could have caused this.  Any tips on debugging?

Bug#1050812: u-boot-rockchip: Please add support for Pine64 Quartz64 devices

2023-08-31 Thread Vagrant Cascadian

On 2023-08-31, Christopher Obbard wrote:
> Let me rephrase myself. My suggestion is to ship in u-boot-rockchip U-Boot 
> for these devices
> *without* any closed bits and ship rkbin in non-free-firmware in 
> non-free-firmware.
>
> We need to simply combine those into an image file to flash to the device, 
> that could be done
> in flash-kernel (or as my original suggestion in a script in the image 
> building process but I am
> not fussy).
>
> So that script would "just" combine rkbin and the "open" parts of 
> u-boot-rockchip into idbloader.img and u-boot.itb.
> And once the DDR init and AT-F bits are merged into mainline, we can remove 
> those bits from flash-kernel
> and u-boot-rockchip package can be extended to use the mainline code.
>
> @Vagrant, does that sound like a solution which you'd be interested in? I 
> could
> try to carve out some time to post a patch for u-boot, flash-kernel and 
> package rkbin if so ;-).

That is definitely one approach, although we would need a
u-boot-rockchip-something variant that goes to "contrib" instead of
"main". Packages in "main" need to be functional without anything
outside of "main", and obviously missing the rkbin bits would be of
limited use. :)

There is at least one existing u-boot variant that need to move to
contrib for this very reason...

Another option would be to ship a u-boot-source.deb, which contains the
upstream sources, much like the linux-source package. Then you can maybe
ship u-boot-contrib and/or u-boot-non-free-firmware that builds the
source and can depend on rkbin.

I was so glad rk3328 and rk3399 and earlier rk3288 did not have these
sorts of issues, and was sad to see new ones for rk35xx ...

jo...@debian.org and I (mostly josch) hashed out some similar ideas for
an imx8* platform with similar issues (although the licensing ended up
being even worse than for rkbin such that it could not even go to
"non-free-firmware"):

  https://salsa.debian.org/debian/u-boot/-/merge_requests/29

live well,
  vagrant

signature.asc
Description: PGP signature

Bug#1050973: lastpass-cli: Please update to 1.3.5 upstream to fix certificate error

2023-08-31 Thread Alex Ford

Package: lastpass-cli
Version: 1.3.4
Severity: grave
Justification: renders package unusable

Dear Maintainer,

With the current version of the package, 1.3.4, lpass is broken due to an 
upstream certificate change. This has been addressed in the 1.3.5 release:

https://github.com/lastpass/lastpass-cli/issues/653

Please update to the 1.3.5 upstream release.

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

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

*** End of the template - remove these template lines ***


-- System Information:
Debian Release: bullseye/sid
  APT prefers focal-updates
  APT policy: (500, 'focal-updates'), (500, 'focal-security'), (500, 'focal'), 
(100, 'focal-backports')
Architecture: amd64 (x86_64)

Kernel: Linux 5.15.90.1-microsoft-standard-WSL2 (SMP w/8 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to 
en_US.UTF-8), LANGUAGE=C.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to 
en_US.UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Bug#1036437: please provide a simple example to reproduce the bug

2023-08-31 Thread Alexis Murzeau


Hi,

On 30/08/2023 17:30, Georges Khaznadar wrote:

Dear Alexis,

the bug about "import Gumshoe from "./gumshoe-patched.js";" is not due
to furo: it is due to the package python-sympy-doc.

When I modify the file /usr/share/doc/python-sympy-doc/html/index.html,
and replace
 
by
 
then, Firefox accepts to import Gumshoe seamlessly.


I've tried that on python-sympy-doc package with this line:
``

But with Firefox 117.0 and a local http server, there is another error 
in the console:

`Uncaught SyntaxError: ambiguous indirect export: default`.


That error can be fixed by changing the first line of furo.js
from this:
`import Gumshoe from "./gumshoe-patched.js";`

to this:
`import * as Gumshoe from "./gumshoe-patched.js";`

Then everything works (light/dark mode can be switched via a button on 
the page).


I've proposed upstream to do the change if that's ok for them:
https://github.com/pradyunsg/furo/discussions/717



As a side note (as you are the uploader of python-sumpy-doc, you might 
be interested), I found that the version of python-sumpy-doc in testing 
and unstable is missing many files in the html directory:


https://packages.debian.org/sid/all/python-sympy-doc/filelist

[...]
/usr/share/doc/python-sympy-doc/examples/notebooks/trace.ipynb
/usr/share/doc/python-sympy-doc/html/pics/consoleascii.png
/usr/share/doc/python-sympy-doc/html/pics/consoleunicode.png
/usr/share/doc/python-sympy-doc/html/pics/ipythonnotebook.png
/usr/share/doc/python-sympy-doc/html/pics/ipythonqtconsole.png
/usr/share/doc/python-sympy-doc/html/pics/pngview1.png
/usr/share/doc/python-sympy-doc/sympy-live.sh

In bookworm, all HTML files are there, so the issue is only in 
testing/unstable.




By the way, the file python-sympy-doc also misses a file version.json;
this file should be accessed properly only when one opens the file via a
http: service, like in:
 firefox http://localhost/doc/python-sympy-doc/html/index.html

Please can you check whether the bug you reported still exists when
furo.js is invoked with the type "module"?

Please be kind enough to send me another way to reproduce the bug you
saw, taking in account that
  
is the right way to use furo.js.

Best regards.   Georges



--
Alexis Murzeau
PGP: B7E6 0EBB 9293 7B06 BDBC  2787 E7BD 1904 F480 937F|



OpenPGP_0xE7BD1904F480937F.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1050972: open-vm-tools version 12.3.0 has been released - please rebase

2023-08-31 Thread John Wolfe

Package: open-vm-tools
Version: 2:12.3.0




Also affects 
project
 (?) Also 
affects 
distribution/package
Edit
Bug Description
open-vm-tools 12.3.0 was released on Aug. 31, 2023.


There are no new features in the open-vm-tools 12.3.0 release. This is 
primarily a maintenance release that addresses a few critical problems, 
including:


This release resolves CVE-2023-20900. For more information on this 
vulnerability and its impact on VMware products, see 
https://www.vmware.com/security/advisories/VMSA-2023-0019.html.

 -  A tools.conf configuration setting is available to temporaily direct Linux 
quiesced snaphots to restore pre open-vm-tools 12.2.0 behavior of ignoring file 
systems already frozen.

  - Building of the VMware Guest Authentication Service (VGAuth) using 
"xml-security-c" and "xerces-c" is being deprecated.

  - A number of Coverity reported issues have been addressed.

  - A number of GitHub issues and pull requests have been handled. Please see 
the Resolves Issues section of the Release Notes.

  - For issues resolved in this release, see the Resolved Issues section of the 
Release Notes.


For complete details, see: 
https://github.com/vmware/open-vm-tools/releases/tag/stable-12.3.0

Release Notes are available at 
https://github.com/vmware/open-vm-tools/blob/stable-12.3.0/ReleaseNotes.md

The granular changes that have gone into the 12.3.0 release are in the 
ChangeLog at 
https://github.com/vmware/open-vm-tools/blob/stable-12.3.0/open-vm-tools/ChangeLog


Please rebase open-vm-tools to release 12.3.0 on supported Debian releases as 
appropriate.


Note: 12.3.0 includes changes to better detect and configure the usage of OSS 
packages needed to build the containerInfo plugin. VMware has successfully 
built 12.3.0 on Ubuntu 23.04 without the use of the "grpc_1.51" patch in your 
open-vm-tools-package.

Bug#1050001: Unwinding directory aliasing [and 3 more messages] [and 1 more messages]

2023-08-31 Thread Luca Boccassi

On Wed, 30 Aug 2023 at 12:57, Ian Jackson
 wrote:
>
> On the burden of proof and the correctness of software:
>
> I'm afraid I see a pattern, where blanket statements are made which
> are only "mostly" or "roughly" or "generally" true.  But the
> discrepancies and details matter.  When we make computer systems, it's
> not good enough to if they're only "mostly" right.
>
> Every program is an unproven conjecture whose truth we end up relying
> on.  We need simple axioms, and rigorously correct reasoning.

Yes, and fact-free and evidence-free threads such as #1050001 go in
the exact opposite direction.

> Aliased usrmerge, when deployed, was a conjecture that was disputed:
> "usrmerge via directory aliasing functions correctly".

And it demonstrably does: it works beautifully and flawlessly on an
uncountable number of Debian, Ubuntu, Mint, Fedora, RHEL, CentOS,
Arch, SUSE, Yocto, Gentoo, etc. installations, for a decade in some of
those cases.

> Helmut Grohne writes ("Bug#1050001: Unwinding directory aliasing [and 3 more 
> messages]"):
> > In order to prefer Debian over something else, we want it to be similar
> > enough to make switching feasible while making it differ from others
> > enough to make switching worthwhile. Not having aliasing symlinks hardly
> > seems like an aspect that makes Debian more suitable to people. I guess
> > that you disagree with this and that is fine.
>
> Debian has historically been simply much more reliable.  That
> reliability doesn't come from one particular decision.  It comes from
> an aggregate of, on the whole, making better decisions.  That
> reliability is very valuable to our users and downstreams.  It's
> one of our our most compelling advantages.

It comes in the largest part from having reliable upstreams that can
use common, stable, reliable and proven interfaces, such as the
usr-merged filesystem layout which has been the de-facto standard
across the vast majority of Linux distros for the past decade.

> >  My impression has always been that the disagreement on the end
> > state was involving a minority.
>
> Well, if you disagree with aliased usrmerge and say you don't want it,
> you get abuse.  Even here, many abusive messages have been posted with
> impunity by persons with considerable status.

Sure, insofar as asking for evidence for outrageous and unproven
claims can be considered 'abuse'

> > > This argument is basically drawing together the common factor in the
> > > DEP-17 problem list.
> >
> > And that's precisely why I don't understand your argument. All of the
> > DEP-17 problems are supposed to go away. So it appears as if you cite a
> > list of problems that I expect to not be problems for much longer as a
> > reason for changing the end goal.
>
> DEP-17's list of *problems* forms a category: directory-aliasing-
> induced malfunctions.  But the DEP-17 *solutions* are ad-hoc, and many
> are only applicable to to malfunctions that occur during migration.

No, it's a list of potential bugs caused by dpkg being hopelessly
broken, and effective and demonstrably correct temporary workarounds
for them.

> > > Affected tooling includes not just our .debs, but also remote
> > > configuration management systems like Ansible, image construction
> > > (Dockerfiles), and 3rd-party software installation progrmas (including
> > > both 3rd-party .debs and 3rd-party script-based installation systems).
> >
> > I don't follow the reasoning. [...]
>
> Sam has posted a helpful set of examples of things that one might do,
> whose consequences with aliased directories are unclear.
>
> These are of course only examples.

Yes, they are only examples, more specifically evidence-free examples.
It would be trivial to demonstrate that Ansible/Puppet/whatever are
broken and don't work on Debian/Ubuntu/Fedora/RHEL/CentOS/Arch/etc,
but somehow evidence remains scarce. I wonder why.

> > > I would be much more convinced that all of this isn't a problem, if
> > > there existed, and had been formally adopted (eg by existing in some
> > > manual somewhere) a short and clear set of rules about what is and
> > > isn't allowed - not just rules for us within Debian, but rules for
> > > everyone, everywhere, referring to and modifying files.
> >
> > It appears to me that the empty set of rules (outside packaging) is too
> > simple for you to consider.
>
> "Packaging" is doing a lot of work there.  I find your comment rather
> tendentious, I'm afraid.
>
> I think we need a short and clear set of rules for what you can do
> with ansible, rsync, docker, etc. etc. etc., as well as just apt and
> dpkg.

Again, the rule is simple and short: vendor files go under /usr,
ignore legacy locations. Doesn't get any easier than that.

> > > > We already have the Debian Usr Merge Analysis Tool available at
> > > > https://salsa.debian.org/helmutg/dumat and its output at
> > > > https://subdivi.de/~helmut/dumat.yaml. As explained on d-d@l.d.o, I want
> > > > to turn those findings into automatic RC

Bug#1050971: ITP: u-root-cpu -- cpu command in Go, inspired by the Plan 9 cpu command

2023-08-31 Thread Raul Cheleguini

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

* Package name: u-root-cpu
  Version : 0.0
  Upstream Contact: Ron Minnich 
* URL : https://github.com/u-root/cpu
* License : BSD-3-clause
  Programming Lang: Go
  Description : cpu command in Go, inspired by the Plan 9 cpu command

The cpu command lets you log in from a local system to a remote system and see 
some or all of the files (how much is up to you) from the local system.

This is wonderfully convenient for embedded systems programmers. Because some or
all the files can come from your local machine, including binaries, the only 
thing you need installed on the remote machine is the cpu daemon itself.

Bug#1050113: unblock: rust-rustls-webpki/0.101.3-1.1

2023-08-31 Thread Peter Michael Green


Reopen 1050113
thanks


Bumped the hint to 0.101.3-2.

Testing migration was unfortunately interrupted by a security bug.
then some follow-up issues with the new upstream version uploaded
to fix the security bug.

Can you update the hint to 0.101.4-4?

Bug#1050970: open-vm-tools: CVE-2023-20900

2023-08-31 Thread Salvatore Bonaccorso

Source: open-vm-tools
Version: 2:12.2.5-1
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for open-vm-tools.

CVE-2023-20900[0]:
| VMware Tools contains a SAML token signature bypass vulnerability. A
| malicious actor with man-in-the-middle (MITM) network positioning
| between vCenter server and the virtual machine may be able to bypass
| SAML token signature verification, to perform VMware Tools Guest
| Operations.


If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-20900
https://www.cve.org/CVERecord?id=CVE-2023-20900
[1] https://www.openwall.com/lists/oss-security/2023/08/31/1
[2] 
https://github.com/vmware/open-vm-tools/commit/74b6d0d9000eda1a2c8f31c40c725fb0b8520b16

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

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

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

Bug#1050968: ITP: rkbin -- Pre-built Rockchip bootloader firmware binaries (for embedded targets)

Package: wnpp
Severity: wishlist
Owner: Christopher Obbard 
X-Debbugs-Cc: debian-de...@lists.debian.org, chris.obb...@collabora.com

  Package name: rkbin
  Version : 0.0.0~git20230726.b4558da
  Upstream Contact: Kever Yang 
  URL : https://github.com/rockchip-linux/rkbin
  License : Copyright © 2017-2023，Rockchip Electronics Co., Ltd. All 
rights reserved.
  Programming Lang: n/a; prebuilt firmware binaries
  Description : Pre-built Rockchip bootloader firmware binaries (for 
embedded targets)

This package contains the Rockchip bootloader firmware binaries, primarily
used for targets where no open-source versions is yet released.
The pre-built firmware consists of builds of Arm Trusted Firmware, OP-TEE
and U-Boot. There are also some closed-source tools in this repo, build for
amd64. These will be stripped from the upstream source package as I do
not (yet) see a need for these.

This package is required to build U-Boot for some embedded targets such as
rk3588, rk3566, rk3568. All of these will eventually have open-source
firmware, but it is still useful for new processors in the future where
U-Boot support will be merged long before the initial DRAM bringup and
trusted firmware.

I expect this package will go into non-free-firmware.

If anyone rejects having this kind of package in Debian, please do reply
to this message. I don't have any immediate plans to package this.

Bug#1050969: ITP: v-i -- An alternative Debian installer using vmdb2 and ansible

Package: wnpp
Severity: wishlist
Owner: Christopher Obbard 
X-Debbugs-Cc: debian-de...@lists.debian.org, chris.obb...@collabora.com

  Package name: v-i
  Version : 0.4
  Upstream Contact: Lars Wirzenius 
  URL : https://gitlab.com/larswirzenius/v-i
  License : GPL-3
  Programming Lang: Python, YAML
  Description : An alternative Debian installer using vmdb2 and ansible

v-i installs a very basic Debian onto a PC. It's entirely
non-interactive and unhelpful. The author wrote it so that repeated
installations would be less of a chore than using the official Debian
installer.

v-i uses vmdb2 to install onto bare metal hardware.
vmdb2 is a program to create a disk image virtual machines
with Debian, by the same author. It "installs Debian" to a file
representing a hard drive. It's basically debootstrap, except the
target is a disk image instead of a directory. It's used to create
Debian images for Raspberry Pis.

I'd like to package this as part of the installer-team, but I haven't
yet asked their permission or had any grace from them.

Bug#1050967: RFS: mesa/23.1.6-1~bpo12+1

2023-08-31 Thread Jérémy Viès

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for the package "mesa":

 * Package name : mesa
   Version  : 23.1.6
   Upstream contact : debia...@lists.debian.org, uploader
ab...@debian.org
 * URL  : https://mesa3d.org/
 * License  : MIT and more (see
https://docs.mesa3d.org/license.html)
 * Vcs  : https://salsa.debian.org/xorg-team/lib/mesa.git
   Section  : graphics

The source builds the following binary packages:

  mesa

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

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

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

  dget -
x https://mentors.debian.net/debian/pool/main/m/mesa/mesa_23.1.6-1~bpo12+1.dsc

Changes since the last upload:

* Rebuild for bookworm-backports.

Regards,

Bug#1050966: amiwm: please set XDG_CURRENT_DESKTOP and use it to configure xdg-desktop-portal

Package: amiwm
Version: 0.21pl2-2
Severity: normal
User: xdg-desktop-por...@packages.debian.org
Usertags: portals.conf

As well as being available as a window manager to integrate into some
larger environment, amiwm behaves like a very small desktop environment
in its own right, by providing a /usr/share/xsessions/amiwm.desktop
which can be selected on entry to a display manager such as lightdm.

xdg-desktop-portal 1.17.x introduces a new way to select which portals will
be used for which desktop environments, modelled on mimeapps.list:

- each desktop environment should provide a file like
  /usr/share/xdg-desktop-portal/amiwm-portals.conf

- the filename is ${DESKTOP}-portals.conf where ${DESKTOP} is the desktop
  environment's entry in $XDG_CURRENT_DESKTOP (the same as the DesktopNames
  from /usr/share/{x,wayland-}sessions/*.desktop), folded to lower case

- sysadmins and users can override this via files named portals.conf or
  ${DESKTOP}-portals.conf in various locations like /etc/xdg-desktop-portal
  and ~/.config/xdg-desktop-portal

But as far as I can tell, amiwm doesn't set XDG_CURRENT_DESKTOP, so for
the purposes of this mechanism, it's not programmatically distinguishable
from any other desktop environment or window manager.

XDG_CURRENT_DESKTOP is also used in pre-existing freedesktop.org standards
like the OnlyShowIn/NotShowIn fields for .desktop files, and the ability to
provide a desktop-environment-specific mimeapps.list. Setting
XDG_CURRENT_DESKTOP would allow amiwm to participate in those
specifications.

To reproduce


* Start from a basic non-GUI virtual machine (I used autopkgtest-build-qemu)
* Ensure that a user account exists
* apt install lightdm xorg amiwm
* reboot
* Log in as the user account, selecting "amiwm" from the menu of
  possible X11 sessions
* Open a terminal and run:
  env | grep XDG_CURRENT_DESKTOP
  systemctl --user show-environment

(It's the systemd activation environment that matters here, more than
`env`, because xdg-desktop-portal will typically be run as a systemd
user service.)

Expected result
===

XDG_CURRENT_DESKTOP should be set to a colon-separated sequence of
desktop environment names, most specific first. amiwm seems to be its
own thing rather than being based on another desktop environment, so

XDG_CURRENT_DESKTOP=amiwm

would seem appropriate.

This would allow the amiwm session to have its own
desktop-environment-specific mimeapps.list or portals.conf(5), for
example /usr/share/xdg-desktop-portal/amiwm-portals.conf.

Actual result
=

XDG_CURRENT_DESKTOP is unset.

This means that xdg-desktop-portal configuration can only be done via a
non-desktop-specific portals.conf, but that's not really something that a
non-opinionated distribution like Debian can usefully ship in a centralized
way, so each user of amiwm who wants a working xdg-desktop-portal will
have to configure it themselves.

At the moment, this is mitigated by xdg-desktop-portal (>= 1.17) having
been patched to fall back to xdg-desktop-portal-gtk as a last-resort
desktop-environment-specific backend, but hard-coding that implementation
isn't really something we should be doing centrally (and the idea was
rejected upstream), so I intend to remove that patch before trixie
is released.

Suggested fix
=

Add a sequence of semicolon-separated desktop environment names to
/usr/share/xsessions/amiwm.desktop, most likely just "amiwm":

DesktopNames=amiwm;

(For example, icewm and windowmaker use "ICEWM" and "WindowMaker" in
their equivalent xsessions file.)

And then create a /usr/share/xdg-desktop-portal/amiwm-portals.conf
with whatever portal backends are desired for an amiwm session,
for example perhaps this:

[preferred]
default=gtk;

Please see portals.conf(5) or its source code
https://github.com/flatpak/xdg-desktop-portal/blob/main/doc/portals-conf.rst
for full details.

Thanks,
smcv

-- 
This is part of a mass bug filing:
https://lists.debian.org/debian-devel/2023/08/msg00311.html

Bug#1050955: rpy2: please make the build reproducible

2023-08-31 Thread Dirk Eddelbuettel



On 31 August 2023 at 11:37, Chris Lamb wrote:
| Source: rpy2
| Version: 3.5.13-5
| Severity: normal
| 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
| rpy2 could not be built reproducibly.
| 
| This is because the testsuite generates a Rplots.pdf file which
| contains a build timestamp. This file is then installed directly into
| /usr/lib/python3/dist-packages — hence the increased severity of this
| bug.
| 
| Patch attached.

Will do -- and really appreciate the patch!  [ R tends to always use
Rplots.pdf as a fallback when plot() (or alike) are called but not device can
be opened. That can be on purpose -- testing / comparison happens on plots
too -- but it can be accidental. In that wrapping in xvfb is good. ]

I will wait a day or two as we tried hard to get rpy2 into testing. I added
it already to debian/rules and debian/changelog.

Dirk 
 
|   [0] https://reproducible-builds.org/
| 
| 
| Regards,
| 
| -- 
|   ,''`.
|  : :'  : Chris Lamb
|  `. `'`  la...@debian.org / chris-lamb.co.uk
|`-
| x[DELETED ATTACHMENT rpy2.diff.txt, plain text]

-- 
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#1050965: aewm++: please set XDG_CURRENT_DESKTOP and use it to configure xdg-desktop-portal

Package: aewm++
Version: 1.1.2-5.3
Severity: normal
User: xdg-desktop-por...@packages.debian.org
Usertags: portals.conf

As well as being available as a window manager to integrate into some
larger environment, aewm++ behaves like a very small desktop environment
in its own right, by providing a /usr/share/xsessions/aewm++.desktop
which can be selected on entry to a display manager such as lightdm.

xdg-desktop-portal 1.17.x introduces a new way to select which portals will
be used for which desktop environments, modelled on mimeapps.list:

- each desktop environment should provide a file like
  /usr/share/xdg-desktop-portal/aewm++-portals.conf

- the filename is ${DESKTOP}-portals.conf where ${DESKTOP} is the desktop
  environment's entry in $XDG_CURRENT_DESKTOP (the same as the DesktopNames
  from /usr/share/{x,wayland-}sessions/*.desktop), folded to lower case

- sysadmins and users can override this via files named portals.conf or
  ${DESKTOP}-portals.conf in various locations like /etc/xdg-desktop-portal
  and ~/.config/xdg-desktop-portal

But as far as I can tell, aewm++ doesn't set XDG_CURRENT_DESKTOP, so for
the purposes of this mechanism, it's not programmatically distinguishable
from any other desktop environment or window manager.

XDG_CURRENT_DESKTOP is also used in pre-existing freedesktop.org standards
like the OnlyShowIn/NotShowIn fields for .desktop files, and the ability to
provide a desktop-environment-specific mimeapps.list. Setting
XDG_CURRENT_DESKTOP would allow aewm++ to participate in those
specifications.

To reproduce


* Start from a basic non-GUI virtual machine (I used autopkgtest-build-qemu)
* Ensure that a user account exists
* apt install lightdm xorg aewm++
* reboot
* Log in as the user account, selecting "aewm++" from the menu of
  possible X11 sessions
* Open a terminal and run:
  env | grep XDG_CURRENT_DESKTOP
  systemctl --user show-environment

(It's the systemd activation environment that matters here, more than
`env`, because xdg-desktop-portal will typically be run as a systemd
user service.)

Expected result
===

XDG_CURRENT_DESKTOP should be set to a colon-separated sequence of
desktop environment names, most specific first. aewm++ seems to be based
on aewm, so maybe

XDG_CURRENT_DESKTOP=aewm++:aewm

would seem appropriate.

This would allow the aewm++ session to have its own
desktop-environment-specific mimeapps.list or portals.conf(5), for
example /usr/share/xdg-desktop-portal/aewm++-portals.conf.

Actual result
=

XDG_CURRENT_DESKTOP is unset.

This means that xdg-desktop-portal configuration can only be done via a
non-desktop-specific portals.conf, but that's not really something that a
non-opinionated distribution like Debian can usefully ship in a centralized
way, so each user of aewm++ who wants a working xdg-desktop-portal will
have to configure it themselves.

At the moment, this is mitigated by xdg-desktop-portal (>= 1.17) having
been patched to fall back to xdg-desktop-portal-gtk as a last-resort
desktop-environment-specific backend, but hard-coding that implementation
isn't really something we should be doing centrally (and the idea was
rejected upstream), so I intend to remove that patch before trixie
is released.

Suggested fix
=

Add a sequence of semicolon-separated desktop environment names to
/usr/share/xsessions/aewm++.desktop, perhaps:

DesktopNames=aewm++;aewm;

(For example, icewm and windowmaker use "ICEWM" and "WindowMaker" in
their equivalent xsessions file.)

And then create a /usr/share/xdg-desktop-portal/aewm++-portals.conf
with whatever portal backends are desired for a aewm++ session,
for example perhaps this:

[preferred]
default=gtk;

Please see portals.conf(5) or its source code
https://github.com/flatpak/xdg-desktop-portal/blob/main/doc/portals-conf.rst
for full details.

Thanks,
smcv

-- 
This is part of a mass bug filing:
https://lists.debian.org/debian-devel/2023/08/msg00311.html

Bug#1050964: blackbox: please set XDG_CURRENT_DESKTOP and use it to configure xdg-desktop-portal

Package: blackbox
Version: 0.70.1-39
Severity: normal
User: xdg-desktop-por...@packages.debian.org
Usertags: portals.conf

As well as being available as a window manager to integrate into some
larger environment, Blackbox behaves like a very small desktop environment
in its own right, by providing a /usr/share/xsessions/blackbox.desktop
which can be selected on entry to a display manager such as lightdm.

xdg-desktop-portal 1.17.x introduces a new way to select which portals will
be used for which desktop environments, modelled on mimeapps.list:

- each desktop environment should provide a file like
  /usr/share/xdg-desktop-portal/blackbox-portals.conf

- the filename is ${DESKTOP}-portals.conf where ${DESKTOP} is the desktop
  environment's entry in $XDG_CURRENT_DESKTOP (the same as the DesktopNames
  from /usr/share/{x,wayland-}sessions/*.desktop), folded to lower case

- sysadmins and users can override this via files named portals.conf or
  ${DESKTOP}-portals.conf in various locations like /etc/xdg-desktop-portal
  and ~/.config/xdg-desktop-portal

But as far as I can tell, Blackbox doesn't set XDG_CURRENT_DESKTOP, so for
the purposes of this mechanism, it's not programmatically distinguishable
from any other desktop environment or window manager.

XDG_CURRENT_DESKTOP is also used in pre-existing freedesktop.org standards
like the OnlyShowIn/NotShowIn fields for .desktop files, and the ability to
provide a desktop-environment-specific mimeapps.list. Setting
XDG_CURRENT_DESKTOP would allow Blackbox to participate in those
specifications.

To reproduce


* Start from a basic non-GUI virtual machine (I used autopkgtest-build-qemu)
* Ensure that a user account exists
* apt install lightdm xorg blackbox
* reboot
* Log in as the user account, selecting "Blackbox" from the menu of
  possible X11 sessions
* Open a terminal and run:
  env | grep XDG_CURRENT_DESKTOP
  systemctl --user show-environment

(It's the systemd activation environment that matters here, more than
`env`, because xdg-desktop-portal will typically be run as a systemd
user service.)

Expected result
===

XDG_CURRENT_DESKTOP should be set to a colon-separated sequence of
desktop environment names, most specific first. Blackbox seems to be its
own thing rather than being based on another desktop environment, so

XDG_CURRENT_DESKTOP=Blackbox

would seem appropriate.

This would allow the Blackbox session to have its own
desktop-environment-specific mimeapps.list or portals.conf(5), for
example /usr/share/xdg-desktop-portal/blackbox-portals.conf.

Actual result
=

XDG_CURRENT_DESKTOP is unset.

This means that xdg-desktop-portal configuration can only be done via a
non-desktop-specific portals.conf, but that's not really something that a
non-opinionated distribution like Debian can usefully ship in a centralized
way, so each user of Blackbox who wants a working xdg-desktop-portal will
have to configure it themselves.

At the moment, this is mitigated by xdg-desktop-portal (>= 1.17) having
been patched to fall back to xdg-desktop-portal-gtk as a last-resort
desktop-environment-specific backend, but hard-coding that implementation
isn't really something we should be doing centrally (and the idea was
rejected upstream), so I intend to remove that patch before trixie
is released.

Suggested fix
=

Add a sequence of semicolon-separated desktop environment names to
/usr/share/xsessions/blackbox.desktop, most likely just "Blackbox":

DesktopNames=Blackbox;

(For example, icewm and windowmaker use "ICEWM" and "WindowMaker" in
their equivalent xsessions file.)

And then create a /usr/share/xdg-desktop-portal/blackbox-portals.conf
with whatever portal backends are desired for a Blackbox session,
for example perhaps this:

[preferred]
default=gtk;

Please see portals.conf(5) or its source code
https://github.com/flatpak/xdg-desktop-portal/blob/main/doc/portals-conf.rst
for full details.

Thanks,
smcv

-- 
This is part of a mass bug filing:
https://lists.debian.org/debian-devel/2023/08/msg00311.html

Bug#1050963: evilwm: please set XDG_CURRENT_DESKTOP and use it to configure xdg-desktop-portal

Package: evilwm
Version: 1.4.2-1
Severity: normal
User: xdg-desktop-por...@packages.debian.org
Usertags: portals.conf

As well as being available as a window manager to integrate into some
larger environment, evilwm behaves like a very small desktop environment
in its own right, by providing a /usr/share/xsessions/evilwm.desktop
which can be selected on entry to a display manager such as lightdm.

xdg-desktop-portal 1.17.x introduces a new way to select which portals will
be used for which desktop environments, modelled on mimeapps.list:

- each desktop environment should provide a file like
  /usr/share/xdg-desktop-portal/evilwm-portals.conf

- the filename is ${DESKTOP}-portals.conf where ${DESKTOP} is the desktop
  environment's entry in $XDG_CURRENT_DESKTOP (the same as the DesktopNames
  from /usr/share/{x,wayland-}sessions/*.desktop), folded to lower case

- sysadmins and users can override this via files named portals.conf or
  ${DESKTOP}-portals.conf in various locations like /etc/xdg-desktop-portal
  and ~/.config/xdg-desktop-portal

But as far as I can tell, evilwm doesn't set XDG_CURRENT_DESKTOP, so for
the purposes of this mechanism, it's not programmatically distinguishable
from any other desktop environment or window manager.

XDG_CURRENT_DESKTOP is also used in pre-existing freedesktop.org standards
like the OnlyShowIn/NotShowIn fields for .desktop files, and the ability to
provide a desktop-environment-specific mimeapps.list. Setting
XDG_CURRENT_DESKTOP would allow evilwm to participate in those
specifications.

To reproduce


* Start from a basic non-GUI virtual machine (I used autopkgtest-build-qemu)
* Ensure that a user account exists
* apt install lightdm xorg evilwm
* reboot
* Log in as the user account, selecting "evilwm" from the menu of
  possible X11 sessions
* Open a terminal and run:
  env | grep XDG_CURRENT_DESKTOP
  systemctl --user show-environment

(It's the systemd activation environment that matters here, more than
`env`, because xdg-desktop-portal will typically be run as a systemd
user service.)

Expected result
===

XDG_CURRENT_DESKTOP should be set to a colon-separated sequence of
desktop environment names, most specific first. evilwm seems to be its
own thing rather than being based on another desktop environment, so

XDG_CURRENT_DESKTOP=evilwm

would seem appropriate.

This would allow the evilwm session to have its own
desktop-environment-specific mimeapps.list or portals.conf(5), for
example /usr/share/xdg-desktop-portal/evilwm-portals.conf.

Actual result
=

XDG_CURRENT_DESKTOP is unset.

This means that xdg-desktop-portal configuration can only be done via a
non-desktop-specific portals.conf, but that's not really something that a
non-opinionated distribution like Debian can usefully ship in a centralized
way, so each user of evilwm who wants a working xdg-desktop-portal will
have to configure it themselves.

At the moment, this is mitigated by xdg-desktop-portal (>= 1.17) having
been patched to fall back to xdg-desktop-portal-gtk as a last-resort
desktop-environment-specific backend, but hard-coding that implementation
isn't really something we should be doing centrally (and the idea was
rejected upstream), so I intend to remove that patch before trixie
is released.

Suggested fix
=

Add a sequence of semicolon-separated desktop environment names to
/usr/share/xsessions/evilwm.desktop, most likely just "evilwm":

DesktopNames=evilwm;

(For example, icewm and windowmaker use "ICEWM" and "WindowMaker" in
their equivalent xsessions file.)

And then create a /usr/share/xdg-desktop-portal/evilwm-portals.conf
with whatever portal backends are desired for an evilwm session,
for example perhaps this:

[preferred]
default=gtk;

Please see portals.conf(5) or its source code
https://github.com/flatpak/xdg-desktop-portal/blob/main/doc/portals-conf.rst
for full details.

Thanks,
smcv

-- 
This is part of a mass bug filing:
https://lists.debian.org/debian-devel/2023/08/msg00311.html

Bug#1050962: fvwm3: please set XDG_CURRENT_DESKTOP and use it to configure xdg-desktop-portal

Package: fvwm3
Version: 1.0.6a+ds-1
Severity: normal
User: xdg-desktop-por...@packages.debian.org
Usertags: portals.conf

xdg-desktop-portal 1.17.x introduces a new way to select which portals will
be used for which desktop environments, modelled on mimeapps.list:

- each desktop environment should provide a file like
  /usr/share/xdg-desktop-portal/fvwm-portals.conf

- the filename is ${DESKTOP}-portals.conf where ${DESKTOP} is the desktop
  environment's entry in $XDG_CURRENT_DESKTOP (the same as the DesktopNames
  from /usr/share/{x,wayland-}sessions/*.desktop), folded to lower case

- sysadmins and users can override this via files named portals.conf or
  ${DESKTOP}-portals.conf in various locations like /etc/xdg-desktop-portal
  and ~/.config/xdg-desktop-portal

But as far as I can tell, fvwm doesn't set XDG_CURRENT_DESKTOP, so for
the purposes of this mechanism, it's not programmatically distinguishable
from any other desktop environment or window manager.

XDG_CURRENT_DESKTOP is also used in pre-existing freedesktop.org standards
like the OnlyShowIn/NotShowIn fields for .desktop files, and the ability to
provide a desktop-environment-specific mimeapps.list. Setting
XDG_CURRENT_DESKTOP would allow fvwm to participate in those
specifications.

To reproduce


* Start from a basic non-GUI virtual machine (I used autopkgtest-build-qemu)
* Ensure that a user account exists
* apt install lightdm xorg fvwm3
* reboot
* Log in as the user account, selecting Fvwm 1 from the menu of
  possible X11 sessions
* Open a terminal and run:
  env | grep XDG_CURRENT_DESKTOP
  systemctl --user show-environment

(It's the systemd activation environment that matters here, more than
`env`, because xdg-desktop-portal will typically be run as a systemd
user service.)

Expected result
===

XDG_CURRENT_DESKTOP should be set to a colon-separated sequence of
desktop environment names, most specific first. fvwm seems to be its
own thing rather than being based on another desktop environment, so

XDG_CURRENT_DESKTOP=Fvwm

would seem appropriate.

This would allow the fvwm session to have its own
desktop-environment-specific mimeapps.list or portals.conf(5), for
example /usr/share/xdg-desktop-portal/fvwm-portals.conf.

Actual result
=

XDG_CURRENT_DESKTOP is unset.

This means that xdg-desktop-portal configuration can only be done via a
non-desktop-specific portals.conf, but that's not really something that a
non-opinionated distribution like Debian can usefully ship in a centralized
way, so each user of fvwm who wants a working xdg-desktop-portal will
have to configure it themselves.

At the moment, this is mitigated by xdg-desktop-portal (>= 1.17) having
been patched to fall back to xdg-desktop-portal-gtk as a last-resort
desktop-environment-specific backend, but hard-coding that implementation
isn't really something we should be doing centrally (and the idea was
rejected upstream), so I intend to remove that patch before trixie
is released.

Suggested fix
=

Normally my advice would be to add a sequence of semicolon-separated
desktop environment names to /usr/share/xsessions/fvwm3.desktop, perhaps
just "Fvwm":

DesktopNames=Fvwm;

(Some similar examples: icewm and windowmaker use "ICEWM" and
"WindowMaker" in their equivalent xsessions files.)

And then create a /usr/share/xdg-desktop-portal/fvwm-portals.conf
with whatever portal backends are desired for a fvwm session,
for example perhaps this:

[preferred]
default=gtk;

A complicating factor for fvwm is that fvwm, fvwm-crystal, fvwm1 and
fvwm3 are all variations of fvwm, so they can't all own the filename
/usr/share/xdg-desktop-portal/fvwm-portals.conf. One way to it would
either have to be in some shared package that they all depend on, or
managed non-exclusively somehow (alternatives?).

Or, if it's desirable to be able to distinguish between all these fvwm
variants, they could have a fully-qualified name in the xsessions/*.desktop
file:

DesktopNames=Fvwm3;Fvwm;

which would result in "XDG_CURRENT_DESKTOP=Fvwm3:Fvwm" in the environment,
and xdg-desktop-portal trying to load files like
/usr/share/xdg-desktop-portal/fvwm3-portals.conf, falling back to
/usr/share/xdg-desktop-portal/fvwm-portals.conf if those don't exist.

Please see portals.conf(5) or its source code
https://github.com/flatpak/xdg-desktop-portal/blob/main/doc/portals-conf.rst
for full details.

Thanks,
smcv

-- 
This is part of a mass bug filing:
https://lists.debian.org/debian-devel/2023/08/msg00311.html

Bug#1050949: Acknowledgement (routine-update had my rules for lunch)

2023-08-31 Thread Andreas Tille

Am Thu, Aug 31, 2023 at 07:53:35PM +0200 schrieb Maarten L. Hekkelman:
> I'm sorry, I messed up. This report should not have been sent. I used a
> wrong version of routine-update.

Does this mean we can close this bug report.  This can be done by
sending mail to

   1050949-d...@bugs.debian.org

No problem in any case for the report.  I'm quite interested in any
trouble the package might cause.

Kind regards
Andreas.

-- 
http://fam-tille.de

Bug#1050961: fvwm1: please set XDG_CURRENT_DESKTOP and use it to configure xdg-desktop-portal

Package: fvwm1
Version: 1.24r-57+b1
Severity: normal
User: xdg-desktop-por...@packages.debian.org
Usertags: portals.conf

xdg-desktop-portal 1.17.x introduces a new way to select which portals will
be used for which desktop environments, modelled on mimeapps.list:

- each desktop environment should provide a file like
  /usr/share/xdg-desktop-portal/fvwm-portals.conf

- the filename is ${DESKTOP}-portals.conf where ${DESKTOP} is the desktop
  environment's entry in $XDG_CURRENT_DESKTOP (the same as the DesktopNames
  from /usr/share/{x,wayland-}sessions/*.desktop), folded to lower case

- sysadmins and users can override this via files named portals.conf or
  ${DESKTOP}-portals.conf in various locations like /etc/xdg-desktop-portal
  and ~/.config/xdg-desktop-portal

But as far as I can tell, fvwm doesn't set XDG_CURRENT_DESKTOP, so for
the purposes of this mechanism, it's not programmatically distinguishable
from any other desktop environment or window manager.

XDG_CURRENT_DESKTOP is also used in pre-existing freedesktop.org standards
like the OnlyShowIn/NotShowIn fields for .desktop files, and the ability to
provide a desktop-environment-specific mimeapps.list. Setting
XDG_CURRENT_DESKTOP would allow fvwm to participate in those
specifications.

To reproduce


* Start from a basic non-GUI virtual machine (I used autopkgtest-build-qemu)
* Ensure that a user account exists
* apt install lightdm xorg fvwm1
* reboot
* Log in as the user account, selecting Fvwm 1 from the menu of
  possible X11 sessions
* Open a terminal and run:
  env | grep XDG_CURRENT_DESKTOP
  systemctl --user show-environment

(It's the systemd activation environment that matters here, more than
`env`, because xdg-desktop-portal will typically be run as a systemd
user service.)

Expected result
===

XDG_CURRENT_DESKTOP should be set to a colon-separated sequence of
desktop environment names, most specific first. fvwm seems to be its
own thing rather than being based on another desktop environment, so

XDG_CURRENT_DESKTOP=Fvwm

would seem appropriate.

This would allow the fvwm session to have its own
desktop-environment-specific mimeapps.list or portals.conf(5), for
example /usr/share/xdg-desktop-portal/fvwm-portals.conf.

Actual result
=

XDG_CURRENT_DESKTOP is unset.

This means that xdg-desktop-portal configuration can only be done via a
non-desktop-specific portals.conf, but that's not really something that a
non-opinionated distribution like Debian can usefully ship in a centralized
way, so each user of fvwm who wants a working xdg-desktop-portal will
have to configure it themselves.

At the moment, this is mitigated by xdg-desktop-portal (>= 1.17) having
been patched to fall back to xdg-desktop-portal-gtk as a last-resort
desktop-environment-specific backend, but hard-coding that implementation
isn't really something we should be doing centrally (and the idea was
rejected upstream), so I intend to remove that patch before trixie
is released.

Suggested fix
=

Normally my advice would be to add a sequence of semicolon-separated
desktop environment names to /usr/share/xsessions/fvwm1.desktop, perhaps
just "Fvwm":

DesktopNames=Fvwm;

(Some similar examples: icewm and windowmaker use "ICEWM" and
"WindowMaker" in their equivalent xsessions files.)

And then create a /usr/share/xdg-desktop-portal/fvwm-portals.conf
with whatever portal backends are desired for a fvwm session,
for example perhaps this:

[preferred]
default=gtk;

A complicating factor for fvwm is that fvwm, fvwm-crystal, fvwm1 and
fvwm3 are all variations of fvwm, so they can't all own the filename
/usr/share/xdg-desktop-portal/fvwm-portals.conf. One way to it would
either have to be in some shared package that they all depend on, or
managed non-exclusively somehow (alternatives?).

Or, if it's desirable to be able to distinguish between all these fvwm
variants, they could have a fully-qualified name in the xsessions/*.desktop
file:

DesktopNames=Fvwm1;Fvwm;

which would result in "XDG_CURRENT_DESKTOP=Fvwm1:Fvwm" in the environment,
and xdg-desktop-portal trying to load files like
/usr/share/xdg-desktop-portal/fvwm1-portals.conf, falling back to
/usr/share/xdg-desktop-portal/fvwm-portals.conf if those don't exist.

Please see portals.conf(5) or its source code
https://github.com/flatpak/xdg-desktop-portal/blob/main/doc/portals-conf.rst
for full details.

Thanks,
smcv

-- 
This is part of a mass bug filing:
https://lists.debian.org/debian-devel/2023/08/msg00311.html

Bug#1050960: fvwm-crystal: please set XDG_CURRENT_DESKTOP and use it to configure xdg-desktop-portal

Package: fvwm-crystal
Version: 3.4.1+dfsg-3
Severity: normal
User: xdg-desktop-por...@packages.debian.org
Usertags: portals.conf

xdg-desktop-portal 1.17.x introduces a new way to select which portals will
be used for which desktop environments, modelled on mimeapps.list:

- each desktop environment should provide a file like
  /usr/share/xdg-desktop-portal/fvwm-portals.conf

- the filename is ${DESKTOP}-portals.conf where ${DESKTOP} is the desktop
  environment's entry in $XDG_CURRENT_DESKTOP (the same as the DesktopNames
  from /usr/share/{x,wayland-}sessions/*.desktop), folded to lower case

- sysadmins and users can override this via files named portals.conf or
  ${DESKTOP}-portals.conf in various locations like /etc/xdg-desktop-portal
  and ~/.config/xdg-desktop-portal

But as far as I can tell, fvwm doesn't set XDG_CURRENT_DESKTOP, so for
the purposes of this mechanism, it's not programmatically distinguishable
from any other desktop environment or window manager.

XDG_CURRENT_DESKTOP is also used in pre-existing freedesktop.org standards
like the OnlyShowIn/NotShowIn fields for .desktop files, and the ability to
provide a desktop-environment-specific mimeapps.list. Setting
XDG_CURRENT_DESKTOP would allow fvwm to participate in those
specifications.

To reproduce


* Start from a basic non-GUI virtual machine (I used autopkgtest-build-qemu)
* Ensure that a user account exists
* apt install lightdm xorg fvwm-crystal
* reboot
* Log in as the user account, selecting Fvwm from the menu of
  possible X11 sessions
* Open a terminal and run:
  env | grep XDG_CURRENT_DESKTOP
  systemctl --user show-environment

(It's the systemd activation environment that matters here, more than
`env`, because xdg-desktop-portal will typically be run as a systemd
user service.)

Expected result
===

XDG_CURRENT_DESKTOP should be set to a colon-separated sequence of
desktop environment names, most specific first. fvwm seems to be its
own thing rather than being based on another desktop environment, so

XDG_CURRENT_DESKTOP=Fvwm

would seem appropriate.

This would allow the fvwm session to have its own
desktop-environment-specific mimeapps.list or portals.conf(5), for
example /usr/share/xdg-desktop-portal/fvwm-portals.conf.

Actual result
=

XDG_CURRENT_DESKTOP is unset.

This means that xdg-desktop-portal configuration can only be done via a
non-desktop-specific portals.conf, but that's not really something that a
non-opinionated distribution like Debian can usefully ship in a centralized
way, so each user of fvwm who wants a working xdg-desktop-portal will
have to configure it themselves.

At the moment, this is mitigated by xdg-desktop-portal (>= 1.17) having
been patched to fall back to xdg-desktop-portal-gtk as a last-resort
desktop-environment-specific backend, but hard-coding that implementation
isn't really something we should be doing centrally (and the idea was
rejected upstream), so I intend to remove that patch before trixie
is released.

Suggested fix
=

Normally my advice would be to add a sequence of semicolon-separated
desktop environment names to /usr/share/xsessions/fvwm-crystal.desktop,
perhaps just "Fvwm":

DesktopNames=Fvwm;

(Some similar examples: icewm and windowmaker use "ICEWM" and
"WindowMaker" in their equivalent xsessions files.)

And then create a /usr/share/xdg-desktop-portal/fvwm-portals.conf
with whatever portal backends are desired for a fvwm session,
for example perhaps this:

[preferred]
default=gtk;

A complicating factor for fvwm is that fvwm, fvwm-crystal, fvwm1 and
fvwm3 are all variations of fvwm, so they can't all own the filename
/usr/share/xdg-desktop-portal/fvwm-portals.conf. One way to it would
either have to be in some shared package that they all depend on, or
managed non-exclusively somehow (alternatives?).

Or, if it's desirable to be able to distinguish between all these fvwm
variants, they could have a fully-qualified name in the xsessions/*.desktop
file:

DesktopNames=FVWM-Crystal;Fvwm;

which would result in "XDG_CURRENT_DESKTOP=FVWM-Crystal:Fvwm" in the
environment, and xdg-desktop-portal trying to load files like
/usr/share/xdg-desktop-portal/fvwm-crystal-portals.conf, falling back to
/usr/share/xdg-desktop-portal/fvwm-portals.conf if those don't exist.

Please see portals.conf(5) or its source code
https://github.com/flatpak/xdg-desktop-portal/blob/main/doc/portals-conf.rst
for full details.

Thanks,
smcv

-- 
This is part of a mass bug filing:
https://lists.debian.org/debian-devel/2023/08/msg00311.html

Bug#1050959: fvwm: please set XDG_CURRENT_DESKTOP and use it to configure xdg-desktop-portal

Package: fvwm
Version: 1:2.7.0-2
Severity: normal
User: xdg-desktop-por...@packages.debian.org
Usertags: portals.conf

xdg-desktop-portal 1.17.x introduces a new way to select which portals will
be used for which desktop environments, modelled on mimeapps.list:

- each desktop environment should provide a file like
  /usr/share/xdg-desktop-portal/fvwm-portals.conf

- the filename is ${DESKTOP}-portals.conf where ${DESKTOP} is the desktop
  environment's entry in $XDG_CURRENT_DESKTOP (the same as the DesktopNames
  from /usr/share/{x,wayland-}sessions/*.desktop), folded to lower case

- sysadmins and users can override this via files named portals.conf or
  ${DESKTOP}-portals.conf in various locations like /etc/xdg-desktop-portal
  and ~/.config/xdg-desktop-portal

But as far as I can tell, fvwm doesn't set XDG_CURRENT_DESKTOP, so for
the purposes of this mechanism, it's not programmatically distinguishable
from any other desktop environment or window manager.

XDG_CURRENT_DESKTOP is also used in pre-existing freedesktop.org standards
like the OnlyShowIn/NotShowIn fields for .desktop files, and the ability to
provide a desktop-environment-specific mimeapps.list. Setting
XDG_CURRENT_DESKTOP would allow fvwm to participate in those
specifications.

To reproduce


* Start from a basic non-GUI virtual machine (I used autopkgtest-build-qemu)
* Ensure that a user account exists
* apt install lightdm xorg fvwm
* reboot
* Log in as the user account, selecting Fvwm from the menu of
  possible X11 sessions
* Open a terminal and run:
  env | grep XDG_CURRENT_DESKTOP
  systemctl --user show-environment

(It's the systemd activation environment that matters here, more than
`env`, because xdg-desktop-portal will typically be run as a systemd
user service.)

Expected result
===

XDG_CURRENT_DESKTOP should be set to a colon-separated sequence of
desktop environment names, most specific first. fvwm seems to be its
own thing rather than being based on another desktop environment, so

XDG_CURRENT_DESKTOP=Fvwm

would seem appropriate.

This would allow the fvwm session to have its own
desktop-environment-specific mimeapps.list or portals.conf(5), for
example /usr/share/xdg-desktop-portal/fvwm-portals.conf.

Actual result
=

XDG_CURRENT_DESKTOP is unset.

This means that xdg-desktop-portal configuration can only be done via a
non-desktop-specific portals.conf, but that's not really something that a
non-opinionated distribution like Debian can usefully ship in a centralized
way, so each user of fvwm who wants a working xdg-desktop-portal will
have to configure it themselves.

At the moment, this is mitigated by xdg-desktop-portal (>= 1.17) having
been patched to fall back to xdg-desktop-portal-gtk as a last-resort
desktop-environment-specific backend, but hard-coding that implementation
isn't really something we should be doing centrally (and the idea was
rejected upstream), so I intend to remove that patch before trixie
is released.

Suggested fix
=

Normally my advice would be to add a sequence of semicolon-separated
desktop environment names to /usr/share/xsessions/fvwm.desktop, perhaps
just "Fvwm":

DesktopNames=Fvwm;

(Some similar examples: icewm and windowmaker use "ICEWM" and
"WindowMaker" in their equivalent xsessions files.)

And then create a /usr/share/xdg-desktop-portal/fvwm-portals.conf
with whatever portal backends are desired for a fvwm session,
for example perhaps this:

[preferred]
default=gtk;

A complicating factor for fvwm is that fvwm, fvwm-crystal, fvwm1 and
fvwm3 are all variations of fvwm, so they can't all own the filename
/usr/share/xdg-desktop-portal/fvwm-portals.conf. One way to it would
either have to be in some shared package that they all depend on, or
managed non-exclusively somehow (alternatives?).

Or, if it's desirable to be able to distinguish between all these fvwm
variants, they could have a fully-qualified name in the xsessions/*.desktop
file:

DesktopNames=Fvwm2;Fvwm;

which would result in "XDG_CURRENT_DESKTOP=Fvwm2:Fvwm" in the environment,
and xdg-desktop-portal trying to load files like
/usr/share/xdg-desktop-portal/fvwm2-portals.conf, falling back to
/usr/share/xdg-desktop-portal/fvwm-portals.conf if those don't exist.

Please see portals.conf(5) or its source code
https://github.com/flatpak/xdg-desktop-portal/blob/main/doc/portals-conf.rst
for full details.

Thanks,
smcv

-- 
This is part of a mass bug filing:
https://lists.debian.org/debian-devel/2023/08/msg00311.html

Bug#1050958: afterstep: please set XDG_CURRENT_DESKTOP and use it to configure xdg-desktop-portal

Package: afterstep
Version: 3.6.1-11
Severity: normal
User: xdg-desktop-por...@packages.debian.org
Usertags: portals.conf

xdg-desktop-portal 1.17.x introduces a new way to select which portals will
be used for which desktop environments, modelled on mimeapps.list:

- each desktop environment should provide a file like
  /usr/share/xdg-desktop-portal/afterstep-portals.conf

- the filename is ${DESKTOP}-portals.conf where ${DESKTOP} is the desktop
  environment's entry in $XDG_CURRENT_DESKTOP (the same as the DesktopNames
  from /usr/share/{x,wayland-}sessions/*.desktop), folded to lower case

- sysadmins and users can override this via files named portals.conf or
  ${DESKTOP}-portals.conf in various locations like /etc/xdg-desktop-portal
  and ~/.config/xdg-desktop-portal

But as far as I can tell, Afterstep doesn't set XDG_CURRENT_DESKTOP, so for
the purposes of this mechanism, it's not programmatically distinguishable
from any other desktop environment or window manager.

XDG_CURRENT_DESKTOP is also used in pre-existing freedesktop.org standards
like the OnlyShowIn/NotShowIn fields for .desktop files, and the ability to
provide a desktop-environment-specific mimeapps.list. Setting
XDG_CURRENT_DESKTOP would allow Afterstep to participate in those
specifications.

To reproduce


* Start from a basic non-GUI virtual machine (I used autopkgtest-build-qemu)
* Ensure that a user account exists
* apt install lightdm xorg afterstep
* reboot
* Log in as the user account, selecting "Afterstep" from the menu of
  possible X11 sessions
* Open a terminal and run:
  env | grep XDG_CURRENT_DESKTOP
  systemctl --user show-environment

(It's the systemd activation environment that matters here, more than
`env`, because xdg-desktop-portal will typically be run as a systemd
user service.)

Expected result
===

XDG_CURRENT_DESKTOP should be set to a colon-separated sequence of
desktop environment names, most specific first. Afterstep seems to be its
own thing rather than being based on another desktop environment, so

XDG_CURRENT_DESKTOP=Afterstep

would seem appropriate.

This would allow the Afterstep session to have its own
desktop-environment-specific mimeapps.list or portals.conf(5), for
example /usr/share/xdg-desktop-portal/afterstep-portals.conf.

Actual result
=

XDG_CURRENT_DESKTOP is unset.

This means that xdg-desktop-portal configuration can only be done via a
non-desktop-specific portals.conf, but that's not really something that a
non-opinionated distribution like Debian can usefully ship in a centralized
way, so each user of Afterstep who wants a working xdg-desktop-portal will
have to configure it themselves.

At the moment, this is mitigated by xdg-desktop-portal (>= 1.17) having
been patched to fall back to xdg-desktop-portal-gtk as a last-resort
desktop-environment-specific backend, but hard-coding that implementation
isn't really something we should be doing centrally (and the idea was
rejected upstream), so I intend to remove that patch before trixie
is released.

Suggested fix
=

Add a sequence of semicolon-separated desktop environment names to
/usr/share/xsessions/afterstep.desktop, most likely just "Afterstep":

DesktopNames=Afterstep;

(For example, icewm and windowmaker use "ICEWM" and "WindowMaker" in
their equivalent xsessions file.)

And then create a /usr/share/xdg-desktop-portal/afterstep-portals.conf
with whatever portal backends are desired for an Afterstep session,
for example perhaps this:

[preferred]
default=gtk;

Please see portals.conf(5) or its source code
https://github.com/flatpak/xdg-desktop-portal/blob/main/doc/portals-conf.rst
for full details.

Thanks,
smcv

-- 
This is part of a mass bug filing:
https://lists.debian.org/debian-devel/2023/08/msg00311.html

Bug#1050957: borgbackup: NEWS.Debian file not installed into /usr/share/doc/borgbackup

2023-08-31 Thread Salvatore Bonaccorso

Source: borgbackup
Version: 1.2.5-4
Severity: normal
X-Debbugs-Cc: car...@debian.org

Hi Gianfranco

Thanks for adding a note in NEWS.Debian file for the compact and
CVE-2023-36811. Unfortunately the NEWS.Debian file is tough not
installed by dh_installchangelogs because it searches by default 

   debian/changelog
   debian/NEWS
   debian/package.changelog
   debian/package.NEWS

so it is then not added.

Regards,
Salvatore

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

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

Bug#1050956: weston: please set XDG_CURRENT_DESKTOP and use it to configure xdg-desktop-portal

Package: weston
Version: 12.0.1-1
Severity: normal
User: xdg-desktop-por...@packages.debian.org
Usertags: portals.conf

In addition to being available as a compositor that is part of
a more comprehensive desktop environment, weston behaves like
a small desktop environment in its own right, by providing a
/usr/share/wayland-sessions/weston.desktop which can be selected on
entry to a display manager such as gdm3.

xdg-desktop-portal 1.17.x introduces a new way to select which portals will
be used for which desktop environments, modelled on mimeapps.list:

- each desktop environment should provide a file like
  /usr/share/xdg-desktop-portal/weston-portals.conf

- the filename is ${DESKTOP}-portals.conf where ${DESKTOP} is the desktop
  environment's entry in $XDG_CURRENT_DESKTOP (the same as the DesktopNames
  from /usr/share/{x,wayland-}sessions/*.desktop), folded to lower case

- sysadmins and users can override this via files named portals.conf or
  ${DESKTOP}-portals.conf in various locations like /etc/xdg-desktop-portal
  and ~/.config/xdg-desktop-portal

But as far as I can tell, weston doesn't set XDG_CURRENT_DESKTOP, so for
the purposes of this mechanism, it's not programmatically distinguishable
from any other equally simple session.

XDG_CURRENT_DESKTOP is also used in pre-existing freedesktop.org standards
like the OnlyShowIn/NotShowIn fields for .desktop files, and the ability to
provide a desktop-environment-specific mimeapps.list. Setting
XDG_CURRENT_DESKTOP would allow weston to participate in those
specifications.

To reproduce


* Start from a basic non-GUI virtual machine (I used autopkgtest-build-qemu)
* Ensure that a user account exists and has a password
* apt install gdm3 weston
* reboot
* Log in as the user account, selecting Weston from the menu of
  possible X11/Wayland sessions before entering the password
* Open a terminal and run:
  systemctl --user show-environment

(It's the systemd activation environment that matters here, more than
`echo $XDG_CURRENT_DESKTOP`, because xdg-desktop-portal will typically be
run as a systemd user service.)

Expected result
===

XDG_CURRENT_DESKTOP should be set to a colon-separated sequence of
desktop environment names, most specific first. For Weston on its own
as a simple desktop environment,

XDG_CURRENT_DESKTOP=Weston

would seem appropriate?

This would allow the Weston session to have its own
desktop-environment-specific mimeapps.list or portals.conf(5), for
example /usr/share/xdg-desktop-portal/weston-portals.conf.

Actual result
=

XDG_CURRENT_DESKTOP is unset.

This means that xdg-desktop-portal configuration can only be done via a
non-desktop-specific portals.conf, but that's not really something that a
non-opinionated distribution like Debian can usefully ship in a centralized
way, so each user of Weston who wants a working xdg-desktop-portal will
have to configure it themselves.

At the moment, this is mitigated by xdg-desktop-portal (>= 1.17) having
been patched to fall back to xdg-desktop-portal-gtk as a last-resort
desktop-environment-specific backend, but hard-coding that implementation
isn't really something we should be doing centrally (and the idea was
rejected upstream), so I intend to remove that patch before trixie
is released.

Suggested fix
=

Add a sequence of semicolon-separated desktop environment names to
/usr/share/wayland-sessions/weston.desktop, most likely just "Weston":

DesktopNames=Weston;

And then create a /usr/share/xdg-desktop-portal/weston-portals.conf
with whatever portal backends are desired for a Weston session,
for example perhaps this:

[preferred]
default=gtk;

Please see portals.conf(5) or its source code
https://github.com/flatpak/xdg-desktop-portal/blob/main/doc/portals-conf.rst
for full details.

Thanks,
smcv

-- 
This is part of a mass bug filing:
https://lists.debian.org/debian-devel/2023/08/msg00311.html

Bug#1050955: rpy2: please make the build reproducible

2023-08-31 Thread Chris Lamb

Source: rpy2
Version: 3.5.13-5
Severity: normal
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
rpy2 could not be built reproducibly.

This is because the testsuite generates a Rplots.pdf file which
contains a build timestamp. This file is then installed directly into
/usr/lib/python3/dist-packages — hence the increased severity of this
bug.

Patch attached.

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


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
diff --git a/debian/rules b/debian/rules
index dee8be3..980d8a2 100755
--- a/debian/rules
+++ b/debian/rules
@@ -24,6 +24,9 @@ tarball:
 # Commented-out again 2023-05-24
 # override_dh_auto_test:
 
+execute_after_dh_auto_test:
+   find -type f -name Rplots.pdf -delete
+
 override_dh_installdocs:
dh_installdocs -a NEWS

Bug#1029203: r-cran-gfonts_0.2.0-1_amd64.changes REJECTED

2023-08-31 Thread Andreas Tille

Hi Thorsten,

Am Thu, Aug 31, 2023 at 06:00:09PM + schrieb Thorsten Alteholz:
> according to [1] the license of the Roboto font is Apache-2.
> Where did you find the information that it should be OFL?

I need to admit I do not remember any more where I've found OFL and I
simply trust your insight.

I've uploaded a fixed package.  As I wrote before fast processing would
help fixing a couple of RC bugs.

Thanks a lot for your work as ftpmaster

 Andreas.
 
>   Thorten
> 
> [1] https://fonts.google.com/specimen/Roboto/about

-- 
http://fam-tille.de

Bug#1050954: debootstrap is confused by "DIRECT" answer from Acquire::http::Proxy-Auto-Detect

2023-08-31 Thread Alexandre Detiste

Package: debootstrap
Version: 1.0.132
Severity: normal

The 'Proxy-Auto-Detect' allows the detection script to return 'DIRECT'
in case a proxy is not needed/not available at the moment.

deboostrap currently doesn't handle this answer well.



root@brix:/var/chroot# debootstrap bookworm bookworm   
http://ftp.be.debian.org/debian/
I: Using auto-detected proxy: DIRECT
I: Retrieving InRelease
I: Retrieving Release
E: Failed getting release file 
http://ftp.be.debian.org/debian/dists/bookworm/Release

https://manpages.debian.org/testing/apt/apt-transport-http.1.en.html


> The various APT configuration options support the special value DIRECT
> meaning that no proxy should be used.
> The environment variable no_proxy is also supported for the same purpose.

https://salsa.debian.org/installer-team/debootstrap/-/blob/master/debootstrap#L457


Greetings

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

Kernel: Linux 6.4.0-3-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_BE:fr
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages debootstrap depends on:
ii  wget  1.21.3-1+b2

Versions of packages debootstrap recommends:
pn  arch-test   
ii  debian-archive-keyring  2023.4
ii  gnupg   2.2.40-1.1

Versions of packages debootstrap suggests:
ii  binutils2.41-4
pn  squid-deb-proxy-client  
pn  ubuntu-archive-keyring  
ii  xz-utils5.4.1-0.2
ii  zstd1.5.5+dfsg2-1

-- no debconf information

Bug#1050953: emacslient fails to start when -n is specified

2023-08-31 Thread Wang Yizhen


Package: emacs
Version: 1:29.1+1-5
Severity: normal
X-Debbugs-Cc: wang1zhe...@gmail.com

Dear Maintainer,

I recently noticed a bug for the emacs package in sid.


After upgraded to emacs 29.1+1-5, I found that the emacsclient command 
is not working. More specifically, the following command hangs emacs in 
daemon forever and no emacs frame pops up:



```

emacsclient -c -a "" -n

```


However, `emacsclient -c -a ""` summons the emacs frame properly 
although it occupies the terminal.



Thanks for your help.


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

Kernel: Linux 5.15.90.4-microsoft-standard-WSL2 (SMP w/16 CPU threads)
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: unable to detect

Versions of packages emacs depends on:
ii  emacs-gtk  1:29.1+1-5

emacs recommends no packages.

emacs suggests no packages.

-- no debconf information

Bug#1050952: r-bioc-rhdf5lib: autopkgtest regression: Expected '1.10.8', got '1.10.10'

2023-08-31 Thread Gilles Filippini

Source: r-bioc-rhdf5lib
Version: 1.6.3+dfsg-1
Severity: serious
Justification: Test regression

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

See 
https://ci.debian.net/data/autopkgtest/unstable/amd64/r/r-bioc-rhdf5lib/37206202/log.gz.

> 69s - FAILED[data]: test_library_version.R<3--3>
> 69s  call| expect_identical(libver, "1.10.8")
> 69s  diff| Expected '1.10.8', got '1.10.10'

Please fix the testcases so that they won't fail each time the HDF5
release number is bumped.

Thanks in advance,
_g.

- -- System Information:
Debian Release: 11.7
Architecture: amd64 (x86_64)

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

-BEGIN PGP SIGNATURE-

iQEzBAEBCgAdFiEEoJObzArDE05WtIyR7+hsbH/+z4MFAmTw1b4ACgkQ7+hsbH/+
z4MVFAf/cmL8/oW3owSvrnYpqf68EwqR4stYB/NS+KOqtM/B5Ed2FYoUkxmgOhWG
9q9u1lkW0T0mMVlVMLKJlhKdfS/brQgk/Z+LYmc5sqTpvj5Re2C2DIW/XhyAsNxn
Nz7HiRURg4MOKd2F9Nq5iRoI8mVwgtiRiTI12Fne5QlAyXMBOGD4IBrgINOttiKT
LPkZgaO+jXN7nV9HOYkeFm2Jf8bRVEpS5t1ityuN+HVohl0YJ8ieqwzQFsKnAave
o1ag7xZ21iX6hF88ApfTlzBc6SdkRPBf0/AjNuAWnBz0UQHbYVSsKYtL1TshnPUN
virmPFskzmAa345AD6/BA/gyzMME6g==
=UnqI
-END PGP SIGNATURE-

Bug#1050949: Acknowledgement (routine-update had my rules for lunch)

2023-08-31 Thread Maarten L. Hekkelman

I'm sorry, I messed up. This report should not have been sent. I used a 
wrong version of routine-update.


-maarten

Op 31-08-2023 om 19:33 schreef Debian Bug Tracking System:

Thank you for filing a new Bug report with Debian.

You can follow progress on this Bug here: 1050949: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1050949.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
  Debian Med Packaging Team 

If you wish to submit further information on this problem, please
send it to 1050...@bugs.debian.org.

Please do not send mail to ow...@bugs.debian.org unless you wish
to report a problem with the Bug-tracking system.



--
Maarten L. Hekkelman
http://www.hekkelman.com/

Bug#1050256: [pkg-apparmor] Bug#1050256: autopkgtest fails on debci

2023-08-31 Thread Christian Boltz

Hello,

Am Donnerstag, 31. August 2023, 08:41:59 CEST schrieb Michael Biebl:
> What we found so far is, that the AppArmor policy of lxc breaks any 
> systemd service using PrivateNetwork=yes or PrivateIPC=yes when being
>  run under lxc (running under bookworm using the bookworm kernel). 
> I wonder what the best course of action is here.
> Should we disable the AA policy of lxc via a stable upload of the lxc
>  package until the root cause is found?
> 
> Unfortunately I know too little about AppArmor and lxc's AppArmor
> policy  and my attempts to ask around for help weren't successful so
> far. 

Two quick hints, but let me warn you that I'm not familiar with lxc and 
also didn't check the content of the lxc-autopkgtest-lxc-iomhit_* 
profile.

https://github.com/lxc/lxc/issues/4333 indicates that this issue was 
fixed in (much) a newer kernel - but that's probably not news to you 
since you wrote that comment ;-)


That said - the DENIED log entry translates to

unix send type=dgram,

You could try if adding this rule to the lxc-autopkgtest-lxc-iomhit_* 
profile helps - but if the issue is really on the kernel side, my hope is 
limited).

For testing, you could also try with a more broad
unix send,
or even
unix,
rule - but please don't add these broader rules to the production 
profile.


Regards,

Christian Boltz
-- 
you need a certificate, nobody knows how to do that securely (including
the CAs ;-) [Bernd Paysan, https://bugs.kde.org/show_bug.cgi?id=131083]


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

Bug#1050951: openbox: please set XDG_CURRENT_DESKTOP and use it to configure xdg-desktop-portal

Package: openbox
Version: 3.6.1-11
Severity: normal
User: xdg-desktop-por...@packages.debian.org
Usertags: portals.conf

In addition to being available as a window manager that is part of
a more comprehensive desktop environment like LXDE, openbox behaves
like a very small desktop environment in its own right, by providing a
/usr/share/xsessions/openbox.desktop which can be selected on entry to
a display manager such as lightdm.

xdg-desktop-portal 1.17.x introduces a new way to select which portals will
be used for which desktop environments, modelled on mimeapps.list:

- each desktop environment should provide a file like
  /usr/share/xdg-desktop-portal/openbox-portals.conf

- the filename is ${DESKTOP}-portals.conf where ${DESKTOP} is the desktop
  environment's entry in $XDG_CURRENT_DESKTOP (the same as the DesktopNames
  from /usr/share/{x,wayland-}sessions/*.desktop), folded to lower case

- sysadmins and users can override this via files named portals.conf or
  ${DESKTOP}-portals.conf in various locations like /etc/xdg-desktop-portal
  and ~/.config/xdg-desktop-portal

But as far as I can tell, openbox doesn't set XDG_CURRENT_DESKTOP, so for
the purposes of this mechanism, it's not programmatically distinguishable
from any other equally simple session.

XDG_CURRENT_DESKTOP is also used in pre-existing freedesktop.org standards
like the OnlyShowIn/NotShowIn fields for .desktop files, and the ability to
provide a desktop-environment-specific mimeapps.list. Setting
XDG_CURRENT_DESKTOP would allow openbox to participate in those
specifications.

To reproduce


* Start from a basic non-GUI virtual machine (I used autopkgtest-build-qemu)
* Ensure that a user account exists
* apt install lightdm xorg openbox
* reboot
* Log in as the user account, selecting "Openbox" from the menu of
  possible X11 sessions
* Open a terminal and run:
  systemctl --user show-environment

(It's the systemd activation environment that matters here, more than
`echo $XDG_CURRENT_DESKTOP`, because xdg-desktop-portal will typically be
run as a systemd user service.)

Expected result
===

XDG_CURRENT_DESKTOP should be set to a colon-separated sequence of
desktop environment names, most specific first. For Openbox on its own
as a simple desktop environment,

XDG_CURRENT_DESKTOP=Openbox

would seem appropriate.

This would allow the Openbox session to have its own
desktop-environment-specific mimeapps.list or portals.conf(5), for
example /usr/share/xdg-desktop-portal/openbox-portals.conf.

Actual result
=

XDG_CURRENT_DESKTOP is unset.

This means that xdg-desktop-portal configuration can only be done via a
non-desktop-specific portals.conf, but that's not really something that a
non-opinionated distribution like Debian can usefully ship in a centralized
way, so each user of openbox who wants a working xdg-desktop-portal will
have to configure it themselves.

At the moment, this is mitigated by xdg-desktop-portal (>= 1.17) having
been patched to fall back to xdg-desktop-portal-gtk as a last-resort
desktop-environment-specific backend, but hard-coding that implementation
isn't really something we should be doing centrally (and the idea was
rejected upstream), so I intend to remove that patch before trixie
is released.

Suggested fix
=

Add a sequence of semicolon-separated desktop environment names to
/usr/share/xsessions/openbox.desktop, most likely just "Openbox":

DesktopNames=Openbox;

(For example, icewm and windowmaker use "ICEWM" and "WindowMaker" in
their equivalent xsessions file.)

And then create a /usr/share/xdg-desktop-portal/openbox-portals.conf
with whatever portal backends are desired for an openbox session,
for example perhaps this:

[preferred]
default=gtk;

Please see portals.conf(5) or its source code
https://github.com/flatpak/xdg-desktop-portal/blob/main/doc/portals-conf.rst
for full details.

Thanks,
smcv

-- 
This is part of a mass bug filing:
https://lists.debian.org/debian-devel/2023/08/msg00311.html

Bug#1042822: med-fichier: Please upgrade to latest med-fichier version aka 5.0.0

2023-08-31 Thread Gilles Filippini

Christophe Trophime a écrit le 31/08/2023 à 18:57 :

- Original Message -

From: "Gilles Filippini" 
To: "Christophe Trophime" , 
1042...@bugs.debian.org
Sent: Thursday, August 31, 2023 6:47:36 PM
Subject: Re: Bug#1042822: med-fichier: Please upgrade to latest med-fichier 
version aka 5.0.0

Hi Christophe,

Christophe Trophime a écrit le 01/08/2023 à 14:35 :

Source: med-fichier
Version: Please upgrade to 5.0.0 version
Severity: normal

Dear Maintainer,

It would be great if med was upgraded to enable use a Salome 9.11 generated
mesh files.

Where is it downloadable from?

From https://www.salome-platform.org/?page_id=2430.

I take a quick look at the sources. It requires a more recent hdf5 version 
(1.12 if I rember correctly).

This would be unfortunate. I didn't plan to ship HDF5 1.12 because this 
release is (or will soon be) retired by the HDF Group:

https://portal.hdfgroup.org/display/support/Downloads

I thought that Salome 9.11 was build on top of med 5 but this is not the case.
The upgrade is not urgent.. Maybe we shall contact Salome upstream to now when 
they plan to upgrade to med 5
before moving on this issue.

Best
C

Thx,
_g.

Bug#1050950: openbox-gnome-session: please make XDG_CURRENT_DESKTOP different from full GNOME, and use it to configure xdg-desktop-portal

Package: openbox-gnome-session
Version: 3.6.1-11
Severity: normal
User: xdg-desktop-por...@packages.debian.org
Usertags: portals.conf

xdg-desktop-portal 1.17.x introduces a new way to select which portals will
be used for which desktop environments, modelled on mimeapps.list:

- each desktop environment should provide a file like
  /usr/share/xdg-desktop-portal/gnome-portals.conf

- the filename is ${DESKTOP}-portals.conf where ${DESKTOP} is the desktop
  environment's entry in $XDG_CURRENT_DESKTOP (the same as the DesktopNames
  from /usr/share/{x,wayland-}sessions/*.desktop), folded to lower case

- sysadmins and users can override this via files named portals.conf or
  ${DESKTOP}-portals.conf in various locations like /etc/xdg-desktop-portal
  and ~/.config/xdg-desktop-portal

But as far as I can tell, openbox-gnome-session sets
XDG_CURRENT_DESKTOP=GNOME, so for the purposes of this mechanism, it's
not programmatically distinguishable from a full GNOME session with GNOME
Shell. This is problematic, because gnome-portals.conf in gnome-session
selects portal implementations that are only appropriate for the full
GNOME session.

To reproduce


* Start from a basic non-GUI virtual machine (I used autopkgtest-build-qemu)
* Ensure that a user account exists
* # apt install lightdm xorg openbox-gnome-session
* # reboot
* Log in as the user account, selecting "GNOME/Openbox" from the menu of
  possible X11 sessions
* In a parallel ssh login as the same user:
  $ systemctl --user show-environment

(Normally I would say to use a shell inside the X11 environment, but
openbox-gnome-session doesn't currently work because it declares required
components that don't exist - I opened a separate RC bug.)

Expected result
===

XDG_CURRENT_DESKTOP should be set to a colon-separated sequence of
desktop environment names, most specific first. Because this seems to
be intended to behave like a variant of GNOME Flashback, which is itself
a variant of full GNOME, a good value might be:

XDG_CURRENT_DESKTOP=Openbox-GNOME:GNOME-Flashback:GNOME

This would allow the Openbox GNOME session variant to have its own
desktop-environment-specific mimeapps.list or portals.conf(5), for
example /usr/share/xdg-desktop-portal/openbox-gnome-portals.conf.

Actual result
=

XDG_CURRENT_DESKTOP is set to "GNOME", the same as a full GNOME Shell
session.

This means that xdg-desktop-portal will use xdg-desktop-portal-gnome for
all interfaces, but some of the functionality of xdg-desktop-portal-gnome
can only work when running under GNOME Shell.

Suggested fix
=

Fixing the RC bug I opened today (that openbox-gnome-session doesn't start)
will be a prerequisite for usefully fixing this. If it's resolved by
removing openbox-gnome-session, then obviously no further action is needed.

Assuming that openbox-gnome-session is kept, the solution for this bug
would be to add a sequence of semicolon-terminated desktop environment
names to /usr/share/xsessions/openbox-gnome.desktop, perhaps this:

DesktopNames=Openbox-GNOME;GNOME-Flashback;GNOME;

(Note that this is not the same separator as in $XDG_CURRENT_DESKTOP!
It's a semicolon here, as is standard for .desktop file syntax, but it's
a colon in the environment variable.)

And then create a /usr/share/xdg-desktop-portal/openbox-gnome-portals.conf
with whatever portal backends are desired for openbox-gnome-session;
or alternatively, rely on gnome-flashback to provide a
gnome-flashback-portals.conf that this session can fall back to (please
see #1050799 for more information).

Thanks,
smcv

-- 
This is part of a mass bug filing:
https://lists.debian.org/debian-devel/2023/08/msg00311.html

Bug#1050949: routine-update had my rules for lunch

2023-08-31 Thread Andreas Tille

Hi Maarten,

Am Thu, Aug 31, 2023 at 07:16:23PM +0200 schrieb Maarten L. Hekkelman:
> 
> However, running routine-update on this package removed the last two lines and
> the effect was that nothing was built anymore.

Could you please add the complete Git history of routine-update?
I can't reproduce the issue with libzeep as it is currently in
Salsa.

Please also mention

   apt policy lintian-brush

(which is called by routine-update and also changes things)

Thanks a lot for your bug report anyway
Andreas.

-- 
http://fam-tille.de

Bug#1050949: routine-update had my rules for lunch

2023-08-31 Thread Maarten L. Hekkelman

Package: routine-update
Severity: important

Dear Maintainer,

For my debian package I used the wiki page on SphinxDocumentation as inspiration
and added the following lines to my rules file:


override_dh_auto_build: export http_proxy=127.0.0.1:9
override_dh_auto_build: export https_proxy=127.0.0.1:9
override_dh_auto_build:
dh_auto_build

The reason to do this is that I wanted to have the http_proxy set while still
running the regular build (using cmake). My cmake setup builds the documentation
and this avoids sphinx to try to fetch resources from the internet.

However, running routine-update on this package removed the last two lines and
the effect was that nothing was built anymore.

Of course, the rules file is suboptimal, but simply removing the last two lines
makes it worse.

regards, -maarten

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

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

Bug#1050948: O: golang-github-hashicorp-go-azure-helpers -- various helpers and wrappers for working with Azure

2023-08-31 Thread Thorsten Alteholz


Package: wnpp
Severity: normal

I am no longer willing to spend any time for stuff related to Hashicorp.
Therefore I orphan this package now.

If you want to be the new maintainer, please see
https://www.debian.org/devel/wnpp/#howto-o for detailed instructions how
to adopt a package properly.

   Thorsten

Bug#1050947: O: golang-github-hashicorp-terraform-svchost -- handling of friendly hostnames for terraform

2023-08-31 Thread Thorsten Alteholz


Package: wnpp
Severity: normal

I am no longer willing to spend any time for stuff related to Hashicorp.
Therefore I orphan this package now.

If you want to be the new maintainer, please see
https://www.debian.org/devel/wnpp/#howto-o for detailed instructions how
to adopt a package properly.

   Thorsten

Bug#1050946: openbox-gnome-session: missing dependencies, not all RequiredComponents exist any more

Package: openbox-gnome-session
Version: 3.6.1-11
Severity: grave
Justification: renders package unusable

To reproduce


* Start from a basic non-GUI virtual machine (I used autopkgtest-build-qemu)
* Ensure that a user account exists
* # apt install lightdm xorg openbox-gnome-session
* # reboot
* Log in as the user account, selecting "GNOME/Openbox" from the menu of
  possible X11 sessions

Expected result
===

A basic GNOME-Flashback-like session with Openbox as window manager

Actual result
=

Aug 31 16:55:58 host gnome-session-binary[1795]: WARNING: Unable to find 
required component 'org.gnome.SettingsDaemon.A11ySettings'
...
Aug 31 16:55:58 host gnome-session-binary[1795]: WARNING: Unable to find 
required component 'org.gnome.SettingsDaemon.XSettings'
Aug 31 16:55:58 host gnome-session-binary[1795]: WARNING: Unable to find 
required component 'gnome-panel'
Aug 31 16:55:58 host gnome-session-binary[1795]: WARNING: Unable to find 
required component 'nautilus-classic'
Aug 31 16:55:58 host gnome-session-binary[1795]: WARNING: Unable to find 
required component 'gnome-flashback-services'

and the session fails with the GNOME Session "something went wrong"
full-screen dialog.

Root cause
==

/usr/share/gnome-session/sessions/openbox-gnome.session declares the
following as required components of a GNOME/Openbox session:

openbox;
org.gnome.SettingsDaemon.A11ySettings;
[some more pieces of gnome-settings-daemon]
org.gnome.SettingsDaemon.XSettings;
gnome-panel;
nautilus-classic;
gnome-flashback-services

but openbox-gnome-session does not have Depends or even Recommends on the
necessary packages to provide those components.

As a minimum, I think it needs to depend on gnome-settings-daemon,
gnome-panel and gnome-flashback, but I tried installing those packages
and that did not fix the failure to start.

gnome-settings-daemon no longer has Clipboard or Mouse plugins according
to gnome-flashback commits

and
.

nautilus-classic hasn't existed for 5
years according to gnome-flashback commit
.

I don't know what gnome-flashback-services is/was, but
gnome-session-flashback lists gnome-flashback as a required component
instead.

Thanks,
smcv

Bug#1050945: guile-3.0: make guile-2.0 guile-2.2 and guile-3.0 installable parallel

2023-08-31 Thread Ilari Jääskeläinen

Package: guile-3.0
Version: 3.0.8-2
Severity: wishlist
X-Debbugs-Cc: ijaaskelai...@outlook.com

Dear Maintainer, thanks.

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

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

*** End of the template - remove these template lines ***


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

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

Versions of packages guile-3.0 depends on:
hi  guile-3.0-libs  3.0.8-2

guile-3.0 recommends no packages.

Versions of packages guile-3.0 suggests:
pn  guile-3.0-doc  

-- no debconf information

Bug#1050944: jtreg6: please make the build reproducible

2023-08-31 Thread Chris Lamb

Source: jtreg6
Version: 6.2+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
jtreg6 could not be built reproducibly.

This was caused by two issues:

1. Due to the moving from Ant's build.xml to the Makefile-based build,
the build date embedded into the MANIFEST.MF file was being generated
from the system/build time. This requires a patch to the build system
to use SOURCE_DATE_EPOCH if available. (This hunk can go upstream.)

2. The jtreg.jar file was being generated with 444 (read-only)
permissions. This meant that strip-determinism could not fixup the
file modification times of the files within that archive. It was
actually printing: "dh_strip_nondeterminism: warning: Ignoring unwritable
file: jtreg.jar".

A patch for both issues is attached.

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


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/debian/patches/reproducible-build.patch   1969-12-31 16:00:00.0 
-0800
--- b/debian/patches/reproducible-build.patch   2023-08-31 10:04:38.116032765 
-0700
@@ -0,0 +1,29 @@
+Description: Make the build reproducible
+Author: Chris Lamb 
+Last-Update: 2023-08-31
+
+--- jtreg6-6.2+1.orig/make/Rules.gmk
 jtreg6-6.2+1/make/Rules.gmk
+@@ -55,6 +55,13 @@ $(CLASSDIR) $(BUILDDIR) $(BUILDDIR)/test
+ # default copyright; override as necessary
+ JAR_COPYRIGHT = -C $(TOPDIR) COPYRIGHT
+ 
++DATE_FMT = %B %d, %Y
++ifdef SOURCE_DATE_EPOCH
++BUILD_DATE ?= $(shell LC_ALL=C date -u -d "@$(SOURCE_DATE_EPOCH)" 
"$(DATE_FMT)" 2>/dev/null || LC_ALL=C date -u -r "$(SOURCE_DATE_EPOCH)" 
"$(DATE_FMT)" 2>/dev/null || LC_ALL=C date -u "$(DATE_FMT)")
++else
++BUILD_DATE ?= $(shell date "$(DATE_FMT)")
++endif
++
+ $(IMAGES_DIR)/%.jar: pkgsToFiles.sh
+   $(RM) $@ $(@:$(IMAGES_DIR)/%.jar=$(BUILDDIR)/jarData/%) 
+   $(MKDIR) -p $(@D)
+@@ -68,7 +75,7 @@ $(IMAGES_DIR)/%.jar: pkgsToFiles.sh
+ echo "$(@F:%.jar=%)-Build: $(BUILD_NUMBER)" ; \
+ echo "$(@F:%.jar=%)-BuildJavaVersion: `$(JDKJAVA) -fullversion 2>&1 | 
awk '{print $$NF}'  | \
+   sed -e 's|^"\(.*\)"$$|Java(TM) 2 SDK, Version \1|'`" ; \
+-echo "$(@F:%.jar=%)-BuildDate: `/bin/date +'%B %d, %Y'`" ; \
++echo "$(@F:%.jar=%)-BuildDate: $(BUILD_DATE)" ; \
+   ) \
+   > $(@:$(IMAGES_DIR)/%.jar=$(BUILDDIR)/jarData/%/manifest.txt)
+   sh pkgsToFiles.sh $(CLASSDIR) $($(@F:%.jar=PKGS.JAR.%)) > 
$(@:$(IMAGES_DIR)/%.jar=$(BUILDDIR)/jarData/%/includes.txt)
--- a/debian/patches/series 2023-08-31 09:50:06.571624952 -0700
--- b/debian/patches/series 2023-08-31 10:04:37.028021356 -0700
@@ -2,3 +2,4 @@
 launchers.patch
 add-jcommander-to-classpath.patch
 add-logger-to-classpath.patch
+reproducible-build.patch
--- a/debian/rules  2023-08-31 09:50:06.571624952 -0700
--- b/debian/rules  2023-08-31 10:08:31.850276393 -0700
@@ -33,3 +33,6 @@
# Generate the manpages
JT_HOME=./dist/jtreg/lib/ help2man --name="Regression Test Harness" 
--help-option="-help all" dist/jtreg/bin/jtdiff > jtdiff.1
JT_HOME=./dist/jtreg/lib/ help2man --name="Regression Test Harness" 
--help-option="-help all" dist/jtreg/bin/jtreg > jtreg.1
+
+execute_before_dh_strip_nondeterminism:
+   find  debian/ -type f -name jtreg.jar -print0 | xargs -0tr chmod +w

Bug#1042911: Breaks Emacs 29.1 upgrade: muse-split.el:41:2: Error: Cannot open load file: No such file or directory, assoc

2023-08-31 Thread Nicholas D Steeves

Control: block -1 by 1016558

Hi,

I'm just updating this bug to note the adopted muse-el package is just
about ready to upload (the ITA is also a pseudo-RFS bug), and I plan to
upload in the next few days.  If this update isn't enough to prevent
autoremoval...well, at least the package will be fixed very soon.

Regards,
Nicholas


signature.asc
Description: PGP signature

Bug#1042822: med-fichier: Please upgrade to latest med-fichier version aka 5.0.0

2023-08-31 Thread Christophe Trophime



- Original Message -
> From: "Gilles Filippini" 
> To: "Christophe Trophime" , 
> 1042...@bugs.debian.org
> Sent: Thursday, August 31, 2023 6:47:36 PM
> Subject: Re: Bug#1042822: med-fichier: Please upgrade to latest med-fichier 
> version aka 5.0.0

> Hi Christophe,
> 
> Christophe Trophime a écrit le 01/08/2023 à 14:35 :
>> Source: med-fichier
>> Version: Please upgrade to 5.0.0 version
>> Severity: normal
>> 
>> Dear Maintainer,
>> 
>> It would be great if med was upgraded to enable use a Salome 9.11 generated
>> mesh files.
> 
> Where is it downloadable from?

>From https://www.salome-platform.org/?page_id=2430.
I take a quick look at the sources. It requires a more recent hdf5 version 
(1.12 if I rember correctly).
I thought that Salome 9.11 was build on top of med 5 but this is not the case.
The upgrade is not urgent.. Maybe we shall contact Salome upstream to now when 
they plan to upgrade to med 5
before moving on this issue.

Best
C

> 
> Thx,
> _g.


smime.p7s
Description: S/MIME Cryptographic Signature

Bug#1050943: bladerf accesses the Internet during package build

2023-08-31 Thread Benjamin Drung

Package: bladerf
Version: 0.2023.02-1
Severity: serious
Tags: patch
Justification: Policy 4.9
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu mantic ubuntu-patch
X-Debbugs-Cc: bdr...@debian.org

Dear Maintainer,

bladerf 0.2023.02-1 fails to build from source on Ubuntu, because it
tries to access the Internet (see Debian policy 4.9):

```
python3 -m build --sdist --outdir=debian/tmp/ 
host/libraries/libbladeRF_bindings/python
* Creating venv isolated environment...
* Installing packages in isolated environment... (setuptools >= 40.8.0, wheel)
WARNING: The directory '/sbuild-nonexistent/.cache/pip' or its parent directory 
is not owned or is not writable by the current user. The cache has been 
disabled. Check the permissions and owner of that directory. If executing pip 
with sudo, you should use sudo's -H flag.
WARNING: Retrying (Retry(total=4, connect=None, read=None, redirect=None, 
status=None)) after connection broken by 
'NewConnectionError(': Failed to establish a new connection: [Errno -2] Name or 
service not known')': /simple/wheel/
WARNING: Retrying (Retry(total=3, connect=None, read=None, redirect=None, 
status=None)) after connection broken by 
'NewConnectionError(': Failed to establish a new connection: [Errno -2] Name or 
service not known')': /simple/wheel/
WARNING: Retrying (Retry(total=2, connect=None, read=None, redirect=None, 
status=None)) after connection broken by 
'NewConnectionError(': Failed to establish a new connection: [Errno -2] Name or 
service not known')': /simple/wheel/
WARNING: Retrying (Retry(total=1, connect=None, read=None, redirect=None, 
status=None)) after connection broken by 
'NewConnectionError(': Failed to establish a new connection: [Errno -2] Name or 
service not known')': /simple/wheel/
WARNING: Retrying (Retry(total=0, connect=None, read=None, redirect=None, 
status=None)) after connection broken by 
'NewConnectionError(': Failed to establish a new connection: [Errno -2] Name or 
service not known')': /simple/wheel/
ERROR: Could not find a version that satisfies the requirement wheel (from 
versions: none)
ERROR: No matching distribution found for wheel

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/build/__main__.py", line 375, in main
built = build_call(
^^^
  File "/usr/lib/python3/dist-packages/build/__main__.py", line 208, in 
build_package
out = _build(isolation, builder, outdir, distribution, config_settings, 
skip_dependency_check)
  

  File "/usr/lib/python3/dist-packages/build/__main__.py", line 145, in _build
return _build_in_isolated_env(builder, outdir, distribution, 
config_settings)
   
^^
  File "/usr/lib/python3/dist-packages/build/__main__.py", line 113, in 
_build_in_isolated_env
env.install(builder.build_system_requires)
  File "/usr/lib/python3/dist-packages/build/env.py", line 214, in install
_subprocess(cmd)
  File "/usr/lib/python3/dist-packages/build/env.py", line 79, in _subprocess
raise e
  File "/usr/lib/python3/dist-packages/build/env.py", line 76, in _subprocess
subprocess.run(cmd, check=True, stdout=subprocess.PIPE, 
stderr=subprocess.STDOUT)
  File "/usr/lib/python3.11/subprocess.py", line 571, in run
raise CalledProcessError(retcode, process.args,
subprocess.CalledProcessError: Command '['/tmp/build-env-c4ez2a0s/bin/python', 
'-Im', 'pip', 'install', '--use-pep517', '--no-warn-script-location', '-r', 
'/tmp/build-reqs-kxypfyca.txt']' returned non-zero exit status 1.

ERROR Command '['/tmp/build-env-c4ez2a0s/bin/python', '-Im', 'pip', 'install', 
'--use-pep517', '--no-warn-script-location', '-r', 
'/tmp/build-reqs-kxypfyca.txt']' returned non-zero exit status 1.
```

In Ubuntu, the attached patch was applied to achieve the following:

  * Use pybuild for building the Python3 bindings to avoid Internet access
(LP: #2033661)


Thanks for considering the patch.

-- 
Benjamin Drung
Debian & Ubuntu Developer
diff -Nru bladerf-0.2023.02/debian/control bladerf-0.2023.02/debian/control
--- bladerf-0.2023.02/debian/control2023-07-12 17:45:05.0 +0200
+++ bladerf-0.2023.02/debian/control2023-08-31 16:21:33.0 +0200
@@ -15,10 +15,8 @@
libusb2-dev [kfreebsd-any],
   pandoc [!kfreebsd-any],
pkg-config,
-  python3-build,
python3-dev,
-  python3-setuptools,
-  python3-venv
+  python3-setuptools
 Standards-Version: 4.6.2
 Rules-Requires-Root: no
 Section: comm
@@ -94,7 +92,7 @@
 Architecture: any
 Multi-Arch: foreign
 Depends: libbladerf-dev (= ${binary:Version}),
- python3, python3-cffi, ${python3:Depends},
+ python3-cffi, ${python3:Depends},
  ${misc:Depends}
 Description: Nuand bladeRF software-defined radio device (Python)

Bug#1050812: u-boot-rockchip: Please add support for Pine64 Quartz64 devices

Hi Diederik,

On Thu, 2023-08-31 at 17:46 +0100, Christopher Obbard wrote:
> Hi Diederik,
> 
> To stay on-topic here, I also have a Pine64 Quartz64 model A - I'd be happy 
> to be added as a board maintainer in Debian.
> 
> I didn't yet manage to build U-Boot mainline for it, see 
> https://lists.denx.de/pipermail/u-boot/2023-August/526625.html
> I still owe a reply on that topic to Jonas' suggestions, I will hope to get 
> to that next week.
> 
> 
> On Thu, 2023-08-31 at 17:50 +0200, Diederik de Haas wrote:
> > > Sorry, our mails collided and I didn't see your previous reply.
> > Ha! I thought about sending you a private mail about that, but chose not to 
> > as 
> > they weren't conflicting.
> 
> No problem, on-list is probably best anyway so it is archived ;-)
> 
> 
> > > On Thu, 2023-08-31 at 15:41 +0200, Diederik de Haas wrote:
> > > > On Thursday, 31 August 2023 14:14:38 CEST Christopher Obbard wrote:
> > > So far so good ;-). The only clarification I would like to make is the DDR
> > > init code is standalone, part of the TPL and is not anything to do with
> > > TF-A. It really is the first-stage boot code that runs after the maskrom.
> > > 
> > > We could use Rockchip's closed implementation of that OR U-Boot's
> > > implementation, it's only real job is to train the DDR and handoff to
> > > U-Boot SPL.
> > 
> > Thanks! Then it looks like I'm closer to understanding then I initially 
> > thought. It gives a 405 since yesterday, but I have been studying
> > https://opensource.rock-chips.com/wiki_Boot_option
> 
> Yeah, I also got stuck with the vendor documentation and eventually just *had 
> a go* and eventually manged to get things working ;-).
> 
> 
> > > To build U-Boot in Debian for these "new" targets we'd need to:
> > > 1) build and distribute U-Boot for these "new" targets without the 
> > > TPL/TF-A
> > 
> > AFAICT, TF-A for *rk356x* is really close to being mergeable? It appears to 
> > me 
> > that all that's needed is to "dot the i's" and the right people pushing the 
> > right 'buttons' (in the right sequence).
> > AFAIC we can wait for that to happen.
> 
> I'm not entirely sure about that. In any case, for the rk3588 in U-Boot 
> mainline we just boot
> with vendor TPL & leave out TF-A entirely ;-). Maybe that could even be 
> possible with this board,
> to just run without TF-A ?
> 
> If you want to do that, see how we do it for rk3588 here: 
> https://gitlab.collabora.com/hardware-enablement/rockchip-3588/u-boot/-/blob/rk3588-rock5b/.gitlab-ci.yml
> I don't know if it will work for Quartz64, but please try it and see. My 
> fingers are crossed.

Sorry, I was wrong. We set BL31 (which is TF-A from rkbin) and ROCKCHIP_TPL 
(which is TPL from rkbin)

e.g:
- export BL31=../rkbin/bin/rk35/rk3588_bl31_v1.27.elf
- export 
ROCKCHIP_TPL=../rkbin/bin/rk35/rk3588_ddr_lp4_2112MHz_lp5_2736MHz_v1.08.bin

That was misleading. Apologies.


> > The situation is different and therefor long(er) term when it comes to TF-A 
> > for 
> > rk3588 based devices. I'd like to see support for that in Debian 
> > 'eventually' 
> > too, but strictly speaking that's not the goal of this bug report.
> 
> Right, see my comment above. Maybe we can just ignore TF-A on these devices 
> *for now*
> until upstream is merged?

That was wrong. I believe we can use TF-A from rkbin and combine things into an 
image later.


> 
> > The tricky thing is TPL/DRAM training.
> 
> Right, that is common between all of these "modern" devices, so I am really 
> trying to
> not derail this into a rk3588 support thread, but that should be in a 
> separate bug report.
> In theory, if we skip TF-A, the only thing we need is TPL from rkbin for both 
> boards.


That was wrong. I believe we can use TF-A from rkbin and combine things into an 
image later.



> 
> > > 2) package rkbin for Debian in non-free-firmware (I will happily do that)
> > 
> > Thanks :-)
> > AFAIUI the tricky part is about combining u-boot from 'main' (which Vagrant 
> > likes to keep in 'main' and I'm inclined to agree) with rkbin from non-free-
> > firmware and *IF* that's allowed in 'main'. If not, what then?
> > Create an u-boot-nff package, with (exact?) the same contents as u-boot, 
> > but 
> > just in a different archive area? So that it can then be combined to create 
> > an 
> > u-boot-rockchip-nff package (in n-f-f)?
> 
> > > 3) have some scripts to collate the various bits into proper images (that
> > > probably should go inside the image-building tool rather than in a Debian
> > > package like flash-kernel, since it will be hopefully obsolete one day 
> > > :-))
> > 
> > My goal is to have all the parts *in* Debian as packages, so that I don't 
> > need 
> > to run a script to get/build u-boot for rk356x devices, but can just do 
> > `apt-get install `
> > 
> > So the image-building is just used to build/'assemble' the image ;-)
> 
> Let me rephrase myself. My suggestion is to ship in u-boot-rockchip U-Boot 
> for these devices
> *without* any

Bug#1050812: u-boot-rockchip: Please add support for Pine64 Quartz64 devices

Hi Diederik,

To stay on-topic here, I also have a Pine64 Quartz64 model A - I'd be happy to 
be added as a board maintainer in Debian.

I didn't yet manage to build U-Boot mainline for it, see 
https://lists.denx.de/pipermail/u-boot/2023-August/526625.html
I still owe a reply on that topic to Jonas' suggestions, I will hope to get to 
that next week.

On Thu, 2023-08-31 at 17:50 +0200, Diederik de Haas wrote:
> > Sorry, our mails collided and I didn't see your previous reply.
> Ha! I thought about sending you a private mail about that, but chose not to 
> as 
> they weren't conflicting.

No problem, on-list is probably best anyway so it is archived ;-)

> > On Thu, 2023-08-31 at 15:41 +0200, Diederik de Haas wrote:
> > > On Thursday, 31 August 2023 14:14:38 CEST Christopher Obbard wrote:
> > So far so good ;-). The only clarification I would like to make is the DDR
> > init code is standalone, part of the TPL and is not anything to do with
> > TF-A. It really is the first-stage boot code that runs after the maskrom.
> > 
> > We could use Rockchip's closed implementation of that OR U-Boot's
> > implementation, it's only real job is to train the DDR and handoff to
> > U-Boot SPL.
> 
> Thanks! Then it looks like I'm closer to understanding then I initially 
> thought. It gives a 405 since yesterday, but I have been studying
> https://opensource.rock-chips.com/wiki_Boot_option

Yeah, I also got stuck with the vendor documentation and eventually just *had a 
go* and eventually manged to get things working ;-).

> > To build U-Boot in Debian for these "new" targets we'd need to:
> > 1) build and distribute U-Boot for these "new" targets without the TPL/TF-A
> 
> AFAICT, TF-A for *rk356x* is really close to being mergeable? It appears to 
> me 
> that all that's needed is to "dot the i's" and the right people pushing the 
> right 'buttons' (in the right sequence).
> AFAIC we can wait for that to happen.

I'm not entirely sure about that. In any case, for the rk3588 in U-Boot 
mainline we just boot
with vendor TPL & leave out TF-A entirely ;-). Maybe that could even be 
possible with this board,
to just run without TF-A ?

If you want to do that, see how we do it for rk3588 here: 
https://gitlab.collabora.com/hardware-enablement/rockchip-3588/u-boot/-/blob/rk3588-rock5b/.gitlab-ci.yml
I don't know if it will work for Quartz64, but please try it and see. My 
fingers are crossed.

> The situation is different and therefor long(er) term when it comes to TF-A 
> for 
> rk3588 based devices. I'd like to see support for that in Debian 'eventually' 
> too, but strictly speaking that's not the goal of this bug report.

Right, see my comment above. Maybe we can just ignore TF-A on these devices 
*for now*
until upstream is merged?

> The tricky thing is TPL/DRAM training.

Right, that is common between all of these "modern" devices, so I am really 
trying to
not derail this into a rk3588 support thread, but that should be in a separate 
bug report.
In theory, if we skip TF-A, the only thing we need is TPL from rkbin for both 
boards.

> > 2) package rkbin for Debian in non-free-firmware (I will happily do that)
> 
> Thanks :-)
> AFAIUI the tricky part is about combining u-boot from 'main' (which Vagrant 
> likes to keep in 'main' and I'm inclined to agree) with rkbin from non-free-
> firmware and *IF* that's allowed in 'main'. If not, what then?
> Create an u-boot-nff package, with (exact?) the same contents as u-boot, but 
> just in a different archive area? So that it can then be combined to create 
> an 
> u-boot-rockchip-nff package (in n-f-f)?

> > 3) have some scripts to collate the various bits into proper images (that
> > probably should go inside the image-building tool rather than in a Debian
> > package like flash-kernel, since it will be hopefully obsolete one day :-))
> 
> My goal is to have all the parts *in* Debian as packages, so that I don't 
> need 
> to run a script to get/build u-boot for rk356x devices, but can just do 
> `apt-get install `
> 
> So the image-building is just used to build/'assemble' the image ;-)

Let me rephrase myself. My suggestion is to ship in u-boot-rockchip U-Boot for 
these devices
*without* any closed bits and ship rkbin in non-free-firmware in 
non-free-firmware.

We need to simply combine those into an image file to flash to the device, that 
could be done
in flash-kernel (or as my original suggestion in a script in the image building 
process but I am
not fussy).

So that script would "just" combine rkbin and the "open" parts of 
u-boot-rockchip into idbloader.img and u-boot.itb.
And once the DDR init and AT-F bits are merged into mainline, we can remove 
those bits from flash-kernel
and u-boot-rockchip package can be extended to use the mainline code.

@Vagrant, does that sound like a solution which you'd be interested in? I could
try to carve out some time to post a patch for u-boot, flash-kernel and package 
rkbin if so ;-).

> 
> > >

Bug#1042822: med-fichier: Please upgrade to latest med-fichier version aka 5.0.0

2023-08-31 Thread Gilles Filippini


Hi Christophe,

Christophe Trophime a écrit le 01/08/2023 à 14:35 :

Source: med-fichier
Version: Please upgrade to 5.0.0 version
Severity: normal

Dear Maintainer,

It would be great if med was upgraded to enable use a Salome 9.11 generated
mesh files.


Where is it downloadable from?

Thx,
_g.

Bug#1050942: FTBFS: Failed 1/1 test programs. 5/246 subtests failed.

2023-08-31 Thread Joao Eriberto Mota Filho

Package: blhc
Version: 0.13-5
Severity: serious
Tags: ftbfs upstream
Justification: fails to build from source
X-Debbugs-Cc: eribe...@debian.org, Simon Ruderich 

Dear Simon Ruderich,

Currently blhc fails to build from source in Debian Sid. This issue was
detected in Salsa[1].

[1] https://salsa.debian.org/debian/blhc/-/jobs/4635438

I also tested it in a fresh jail:

dh_auto_test
/usr/bin/perl Build test --verbose 1

#   Failed test './t/logs/arch-avr32 --color (output)'
#   at t/tests.t line 45.
#  got: 'Use of uninitialized value $os in pattern match (m//) at 
./bin/blhc line 1194.
# Use of uninitialized value $cpu in pattern match (m//) at ./bin/blhc line 
1198.
# Use of uninitialized value $cpu in pattern match (m//) at ./bin/blhc line 
1202.
# LDFLAGS missing (-Wl,-z,relro): gcc -o test test.o
# CFLAGS missing (-fstack-protector-strong): gcc -D_FORTIFY_SOURCE=2 -g -O2 
-Wformat -Wformat-security -Werror=format-security -Wall -c test.c
# LDFLAGS missing (-Wl,-z,relro): gcc -o test test.o
# '
# expected: 'CFLAGS missing (-fstack-protector-strong): gcc 
-D_FORTIFY_SOURCE=2 -g -O2 -Wformat -Wformat-security -Werror=format-security 
-Wall -c test.c
# '

#   Failed test './t/logs/arch-avr32 (output)'
#   at t/tests.t line 45.
#  got: 'Use of uninitialized value $os in pattern match (m//) at 
./bin/blhc line 1194.
# Use of uninitialized value $cpu in pattern match (m//) at ./bin/blhc line 
1198.
# Use of uninitialized value $cpu in pattern match (m//) at ./bin/blhc line 
1202.

[...]

# checking './t/logs/debian-hardening-wrapper'...
# HARDENING WRAPPER: no checks possible, aborting
# '

#   Failed test './t/logs/arch-i386 ./t/logs/arch-amd64 ./t/logs/arch-avr32 
./t/logs/ignore-flag --ignore-arch-flag i386:-fstack-protector-strong 
--ignore-arch-flag mipsel:-Werror=format-security (output)'
#   at t/tests.t line 45.
#  got: 'Use of uninitialized value $os in pattern match (m//) at 
./bin/blhc line 1194.
# Use of uninitialized value $cpu in pattern match (m//) at ./bin/blhc line 
1198.
# Use of uninitialized value $cpu in pattern match (m//) at ./bin/blhc line 
1202.

[...]

# CFLAGS missing (-O2): gcc -g -fstack-protector-strong -Wformat 
-Wformat-security -Werror=format-security -D_FORTIFY_SOURCE=2 -c test-c.c
# '

#   Failed test './t/logs/arch-i386 ./t/logs/arch-amd64 ./t/logs/arch-avr32 
./t/logs/ignore-line --ignore-arch-line "i386:gcc .+ -fPIE .+" 
--ignore-arch-line "mipsel:gcc .+ -Wl,-z,relro -Wl,-z,now .+" (output)'
#   at t/tests.t line 45.
#  got: 'Use of uninitialized value $os in pattern match (m//) at 
./bin/blhc line 1194.
# Use of uninitialized value $cpu in pattern match (m//) at ./bin/blhc line 
1198.
# Use of uninitialized value $cpu in pattern match (m//) at ./bin/blhc line 
1202.

[...]


# Looks like you failed 5 tests of 246.
t/tests.t ..
1..246
[...]
not ok 14 - ./t/logs/arch-avr32 --color (output)
[...]
not ok 164 - ./t/logs/arch-avr32 (output)
[...]
not ok 242 - ./t/logs/bad-ldflags ./t/logs/empty ./t/logs/arch-avr32 
./t/logs/debian-hardening-wrapper (output)
[...]
not ok 244 - ./t/logs/arch-i386 ./t/logs/arch-amd64 ./t/logs/arch-avr32 
./t/logs/ignore-flag --ignore-arch-flag i386:-fstack-protector-strong 
--ignore-arch-flag mipsel:-Werror=format-security (output)
[...]
not ok 246 - ./t/logs/arch-i386 ./t/logs/arch-amd64 ./t/logs/arch-avr32 
./t/logs/ignore-line --ignore-arch-line "i386:gcc .+ -fPIE .+" 
--ignore-arch-line "mipsel:gcc .+ -Wl,-z,relro -Wl,-z,now .+" (output)
Dubious, test returned 5 (wstat 1280, 0x500)
Failed 5/246 subtests 

Test Summary Report
---
t/tests.t (Wstat: 1280 (exited 5) Tests: 246 Failed: 5)
  Failed tests:  14, 164, 242, 244, 246
  Non-zero exit status: 5
Files=1, Tests=246,  3 wallclock secs ( 0.02 usr  0.00 sys +  2.46 cusr  0.37 
csys =  2.85 CPU)
Result: FAIL
Failed 1/1 test programs. 5/246 subtests failed.


Regards,

Eriberto

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

Kernel: Linux 6.1.0-11-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to 
C.UTF-8), LANGUAGE=C.UTF-8
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Versions of packages blhc depends on:
ii  libdpkg-perl  1.22.0

blhc recommends no packages.

blhc suggests no packages.

-- debconf-show failed

Bug#1050941: ITP: golang-github-muesli-mango -- mango is a man-page generator for the Go flag, pflag, cobra, coral, and kong packages

2023-08-31 Thread Scarlett Moore

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

* Package name: golang-github-muesli-mango
  Version : 0.2.0
  Upstream Author : Christian Muehlhaeuser 
* URL : https://github.com/muesli/mango
* License : Expat
  Programming Lang: Go-lang
  Description : mango is a man-page generator for the Go flag, pflag, 
cobra, coral, and kong packages

 mango is a man-page generator for the Go flag, pflag, cobra, coral, and
 kong packages. It extracts commands, flags, and arguments from your
 program and enables it to self-document.

 This is a dependency for mango-kong

 I will maintain the package under the golang packaging team.

Bug#1050940: linux: Enable Correctable Errors Collector RAS_CEC feature

2023-08-31 Thread Miguel Bernal Marin

Source: linux
Version: 6.5~rc7-1~exp1
Severity: wishlist
Tags: patch
X-Debbugs-Cc: miguel.bernal.ma...@linux.intel.com, jair.gonza...@linux.intel.com

Dear Maintainer,

Please enable the Reliability, Availability and Serviceability (RAS)
Correctable Errors Collector (RAS_CEC) feature on arch amd64/x86_64,
on Debian Trixie. 

RAS_CEC introduce a simple data structure for collecting correctable
errors along with accessors.

This is a small cache which collects correctable memory errors per 4K
page PFN and counts their repeated occurrence. Once the counter for a
PFN overflows, we try to soft-offline that page as we take it to mean
that it has reached a relatively high error count and would probably
be best if we don't use it anymore.

The error decoding is done with the decoding chain now and
mce_first_notifier() gets to see the error first and the CEC decides
whether to log it and then the rest of the chain doesn't hear about it -
basically the main reason for the CE collector - or to continue running
the notifiers.

When the CEC hits the action threshold, it will try to soft-offine the
page containing the ECC and then the whole decoding chain gets to see
the error.

To disable the Correctable Errors Collector, a kernel parameter is used:
>  ras=cec_disable

A MR was created with this proposal at:

https://salsa.debian.org/kernel-team/linux/-/merge_requests/827

Thanks,
Miguel Bernal Marin

Bug#1050777: The surf autopkgtests are failing with webkitgtk 2.41

2023-08-31 Thread Alberto Garcia

On Tue, Aug 29, 2023 at 05:09:32PM +0200, Sebastien Bacher wrote:
> And as a follow up it's not only an autopkgtest issue, surf fails to render
> any webpage on my Ubuntu mantic system with the new webkitgtk installed

This might be the same problem reported upstream here:

   https://bugs.webkit.org/show_bug.cgi?id=259858

Berto

Bug#1050798: plasma-workspace: please provide a kde-portals.conf for xdg-desktop-portal

Control: reassign -1 xdg-desktop-portal-kde
Control: affects -1 + plasma-workspace
Control: tags -1 + fixed-upstream
Control: forwarded -1 
https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/merge_requests/196,https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/merge_requests/218

On Tue, 29 Aug 2023 at 11:36:32 +0100, Simon McVittie wrote:
> xdg-desktop-portal 1.17.x (currently in experimental) introduces a new
> way to select which portals will be used for which desktop environments,
> modelled on mimeapps.list:
> 
> - each desktop environment should provide a file like
>   /usr/share/xdg-desktop-portal/kde-portals.conf

It looks as though KDE have chosen to ship this as part of
xdg-desktop-portal-kde. Please consider cherry-picking these two:

https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/merge_requests/196
https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/merge_requests/218

> plasma-workspace (and plasma-mobile?) should probably have at least a
> Recommends on xdg-desktop-portal-kde for this (see also #1019918).

If x-d-p-kde is responsible for providing kde-portals.conf, then I
think the desktop environments need some sort of dependency relationship
with it.

Thanks,
smcv

Bug#1050812: u-boot-rockchip: Please add support for Pine64 Quartz64 devices

2023-08-31 Thread Diederik de Haas

Hi Christopher,

On Thursday, 31 August 2023 15:54:49 CEST Christopher Obbard wrote:
> Sorry, our mails collided and I didn't see your previous reply.

Ha! I thought about sending you a private mail about that, but chose not to as 
they weren't conflicting.

> On Thu, 2023-08-31 at 15:41 +0200, Diederik de Haas wrote:
> > On Thursday, 31 August 2023 14:14:38 CEST Christopher Obbard wrote:
> So far so good ;-). The only clarification I would like to make is the DDR
> init code is standalone, part of the TPL and is not anything to do with
> TF-A. It really is the first-stage boot code that runs after the maskrom.
> 
> We could use Rockchip's closed implementation of that OR U-Boot's
> implementation, it's only real job is to train the DDR and handoff to
> U-Boot SPL.

Thanks! Then it looks like I'm closer to understanding then I initially 
thought. It gives a 405 since yesterday, but I have been studying
https://opensource.rock-chips.com/wiki_Boot_option

> To build U-Boot in Debian for these "new" targets we'd need to:
> 1) build and distribute U-Boot for these "new" targets without the TPL/TF-A

AFAICT, TF-A for *rk356x* is really close to being mergeable? It appears to me 
that all that's needed is to "dot the i's" and the right people pushing the 
right 'buttons' (in the right sequence).
AFAIC we can wait for that to happen.

The situation is different and therefor long(er) term when it comes to TF-A for 
rk3588 based devices. I'd like to see support for that in Debian 'eventually' 
too, but strictly speaking that's not the goal of this bug report.

The tricky thing is TPL/DRAM training.

> 2) package rkbin for Debian in non-free-firmware (I will happily do that)

Thanks :-)
AFAIUI the tricky part is about combining u-boot from 'main' (which Vagrant 
likes to keep in 'main' and I'm inclined to agree) with rkbin from non-free-
firmware and *IF* that's allowed in 'main'. If not, what then?
Create an u-boot-nff package, with (exact?) the same contents as u-boot, but 
just in a different archive area? So that it can then be combined to create an 
u-boot-rockchip-nff package (in n-f-f)?

> 3) have some scripts to collate the various bits into proper images (that
> probably should go inside the image-building tool rather than in a Debian
> package like flash-kernel, since it will be hopefully obsolete one day :-))

My goal is to have all the parts *in* Debian as packages, so that I don't need 
to run a script to get/build u-boot for rk356x devices, but can just do 
`apt-get install `

So the image-building is just used to build/'assemble' the image ;-)

> > https://salsa.debian.org/diederik/linux/-/tree/pine64/master-next

Just like the goal of that branch is to 'disappear' as all the needed parts 
have (then) become part of the official Debian kernel.
We're not there yet, but that is my goal (for the Trixie release).

Cheers,
  Diederik

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

Bug#1027687: netty: please package 4.1.86 or later

2023-08-31 Thread Andrius Merkys


Hello,

While working on packaging OpenStructure [1] I noticed it expects netty 
4.1.84 or later.


On Sun, 01 Jan 2023 23:13:48 +0100 Markus Koschany  wrote:

I have uploaded my preliminary packaging work to experimental in Git
but could not finish it yet.

What is missing? Maybe I could help speeding up the progress.

[1] https://bugs.debian.org/1002470

Best,
Andrius

Bug#1050932: wget2: -X and --exclude-directories do not work

2023-08-31 Thread Patrice Duroux

Hi,

Regarding https://gitlab.com/gnuwget/wget2/-/blob/master/NEWS

30.08.2019 Release 1.99.2 (beta)
[...]
   * Add -X/--exclude-directories and -I/--include-directories
[...]


a more recent version would improve this.

Regards,
Patrice

Bug#1050939: ovmf: AMD-SEV + TPM (swtpm) + vCPU > 6 = problem

2023-08-31 Thread Ján Máté

Package: ovmf
Version: 2022.11-6
Severity: important

After upgrading to Debian 12.x (from 11.x), some of my VMs are not booting 
anymore. It looks like the ovmf crashes even before loading the shim/bootloader 
from the virtual disk. The problem is somehow related to combination of: 
AMD-SEV + TPM (swtpm) and number of vCPUs configured for the quest OS.

I found a workaround to boot the problematic VMs, more precisely any (one) 
change from the list below allows to boot a VM:

- downgrade the ovmf to version ovmf_2020.11-2+deb11u1_all.deb (from bullseye)
- reduce the number of vCPUs to 6 or less (>6 does not work)
- remove the swtpm from the guest configuration
- disable the AMD-SEV functionality

After some testing, I am pretty sure that the problem is NOT related to:

- qemu-system-x86 version (both bookworm = 7.2+dfsg-7 and bookworm-backports = 
8.0.4+dfsg-1~bpo12+1 are affected)
- kernel version (both bookworm = 6.1.38-4 and bookworm-backports = 
6.4.4-3~bpo12+1 are affected)
- CPU configuration for the guest VM (tried multiple different configurations, 
and the result is the same)

and it looks like the issue is present also in the current debian testing (ovmf 
2023.05-1) - the only working version is ovmf_2020.11-2+deb11u1_all.deb (from 
bullseye).

The problematic libvirt XML (with reboot loop):


  test
  MY_UUID
  
  test VM
  16777216
  16777216
  

  
  8
  
hvm

/var/lib/libvirt/qemu/nvram/test_VARS.fd
  
  


  
  
qemu64
  
  
  destroy
  restart
  destroy
  
/usr/bin/kvm

  
  
  
  


  
  
  
  
  


  


  



  
  
  


  
  
  


  
  
  


  
  
  


  
  
  


  
  
  


  
  
  
  




  

  


  



  
  


  
  
47
1
0x0033
  


The same XML works after any of the following changes:

- reducing the vcpu number, for example:
6

- removing the swtpm definition:

  

  


- removing the AMD-SEV definition (which disables the AMD-SEV functionality):

  47
  1
  0x0033


- dowgrading the ovmf to ovmf_2020.11-2+deb11u1_all.deb (from bullseye), 
without any change in the XML


There is no any warning/error log in the corresponding 
/var/log/libvirt/qemu/test.log, dmesg or /var/log/syslog ...


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

Kernel: Linux 6.4.0-0.deb12.2-amd64 (SMP w/48 CPU threads; PREEMPT)
GNU C Library: libc-bin 2.36-9+deb12u1
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#1050938: RFS: libunistring/1.1-2 -- Unicode string library for C

2023-08-31 Thread Jörg Frings-Fürst

Package: sponsorship-requests
Severity: normal

Dear mentors,

I have the go for the libunistring transition[1]. 

So I am looking for a sponsor for my package "libunistring":

   Package name : libunistring
   Version  : 1.1-2
   Upstream contact : Bruno Haible 
   URL  : https://www.gnu.org/software/libunistring/
   License  : GPL-3+ or GFDL-NIV-1.2+,
  GPL-2+ with distribution exception, Expat and GPL-2+, 
  LGPL-3+ or GPL-2+, GPL-2+, FreeSoftware, X11, GPL-3+,
  GPL-2+ with distribution exception
   Vcs  : https://git.jff.email/cgit/libunistring.git
   Section  : libs

The source builds the following binary packages:

  libunistring-dev - Unicode string library for C - development files
  libunistring5 - Unicode string library for C

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/libu/libunistring/libunistring_1.1-2.dsc

or from

 git https://git.jff.email/cgit/libunistring.git/?h=release%2Fdebian%2F1.1-2

or

 git (old) https://jff.email/cgit/libunistring.git/?h=release%2Fdebian%2F1.1-2



Changes since the last upload:

 libunistring (1.1-2) unstable; urgency=medium
 .
   * Upload to unstable.

CU
Jörg


[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1043599

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


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


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

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

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






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

Bug#1050550: [Pkg-pascal-devel] RFA: winff -- graphical video and audio batch converter using ffmpeg or avconv

2023-08-31 Thread Peter B


On Thu, 31 Aug 2023 16:37:30 +0200 Bastian Germann  wrote:
> Hi Peter,
>
> It would be helpful to maintain the git repo, so if you are not already
> part of the Pascal Team, please consider joining. Otherwise, Paul might be
> so kind to add you as a member only to that single repo.
>
> Thanks,
> Bastian


Agreed. It would be very helpful if I could update the VCS.
I was about to mention this anyway.

I'd be happy to join the team.


Cheers,
Peter

Bug#1050937: protobuf: FTBFS: ModuleNotFoundError: No module named 'tzdata'

2023-08-31 Thread Bo YU

Source: protobuf
Version: 3.21.12-6
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

Dear Maintainer,

protobuf fails to build from source. From my build log on amd64:

```
Traceback (most recent call last):
  File "/usr/lib/python3.11/zoneinfo/_common.py", line 12, in load_tzdata
return resources.files(package_name).joinpath(resource_name).open("rb")
   ^
  File "/usr/lib/python3.11/importlib/resources/_common.py", line 22, in files
return from_package(get_package(package))

  File "/usr/lib/python3.11/importlib/resources/_common.py", line 53, in 
get_package
resolved = resolve(package)
   
  File "/usr/lib/python3.11/importlib/resources/_common.py", line 44, in resolve
return cand if isinstance(cand, types.ModuleType) else 
importlib.import_module(cand)
   
^
  File "/usr/lib/python3.11/importlib/__init__.py", line 126, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
   
  File "", line 1204, in _gcd_import
  File "", line 1176, in _find_and_load
  File "", line 1126, in _find_and_load_unlocked
  File "", line 241, in _call_with_frames_removed
  File "", line 1204, in _gcd_import
  File "", line 1176, in _find_and_load
  File "", line 1140, in _find_and_load_unlocked
ModuleNotFoundError: No module named 'tzdata'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/<>/python3/setup.py", line 324, in 
setup(
  File "/usr/lib/python3/dist-packages/setuptools/__init__.py", line 107, in 
setup
return distutils.core.setup(**attrs)
   ^
  File "/usr/lib/python3/dist-packages/setuptools/_distutils/core.py", line 
185, in setup
return run_commands(dist)
   ^^
  File "/usr/lib/python3/dist-packages/setuptools/_distutils/core.py", line 
201, in run_commands
dist.run_commands()
  File "/usr/lib/python3/dist-packages/setuptools/_distutils/dist.py", line 
969, in run_commands
self.run_command(cmd)
  File "/usr/lib/python3/dist-packages/setuptools/dist.py", line 1233, in 
run_command
super().run_command(command)
  File "/usr/lib/python3/dist-packages/setuptools/_distutils/dist.py", line 
988, in run_command
cmd_obj.run()
  File "/usr/lib/python3/dist-packages/setuptools/command/test.py", line 223, 
in run
self.run_tests()
  File "/usr/lib/python3/dist-packages/setuptools/command/test.py", line 226, 
in run_tests
test = unittest.main(
   ^^
  File "/usr/lib/python3.11/unittest/main.py", line 101, in __init__
self.parseArgs(argv)
  File "/usr/lib/python3.11/unittest/main.py", line 150, in parseArgs
self.createTests()
  File "/usr/lib/python3.11/unittest/main.py", line 161, in createTests
self.test = self.testLoader.loadTestsFromNames(self.testNames,
^^
  File "/usr/lib/python3.11/unittest/loader.py", line 220, in loadTestsFromNames
suites = [self.loadTestsFromName(name, module) for name in names]
 
  File "/usr/lib/python3.11/unittest/loader.py", line 220, in 
suites = [self.loadTestsFromName(name, module) for name in names]
  
  File "/usr/lib/python3.11/unittest/loader.py", line 191, in loadTestsFromName
return self.loadTestsFromModule(obj)
   ^
  File "/usr/lib/python3/dist-packages/setuptools/command/test.py", line 57, in 
loadTestsFromModule
tests.append(self.loadTestsFromName(submodule))
 ^
  File "/usr/lib/python3.11/unittest/loader.py", line 154, in loadTestsFromName
module = __import__(module_name)
 ^^^
  File 
"/<>/python3/google/protobuf/internal/well_known_types_test.py", 
line 56, in 
_TZ_JAPAN = zoneinfo.ZoneInfo('Japan')
^^
  File "/usr/lib/python3.11/zoneinfo/_common.py", line 24, in load_tzdata
raise ZoneInfoNotFoundError(f"No time zone found with key {key}")
zoneinfo._common.ZoneInfoNotFoundError: 'No time zone found with key Japan'
make[1]: *** [debian/rules:105: override_dh_auto_test-arch] Error 1
make[1]: Leaving directory '/<>'
make: *** [debian/rules:23: binary] Error 2
dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2
```

The full log you can get from riscv64 builder also:
https://buildd.debian.org/status/fetch.php?pkg=protobuf=riscv64=3.21.12-6%2Bb1=1693418596=0

-- 
Regards,
--
  Bo YU



signature.asc
Description: PGP signature

Bug#1050550: [Pkg-pascal-devel] RFA: winff -- graphical video and audio batch converter using ffmpeg or avconv

2023-08-31 Thread Bastian Germann


Hi Peter,

On Thu, 31 Aug 2023 09:40:40 +0200 Paul Gevers  wrote:
Feel free to ask question you have or if you need help. Ideally on the 
debian-pascal list about winff or freepascal building. If it's about 
generic packaging issues I request you seek help on debian-mentors.


It would be helpful to maintain the git repo, so if you are not already
part of the Pascal Team, please consider joining. Otherwise, Paul might be
so kind to add you as a member only to that single repo.

Thanks,
Bastian

Bug#1042906: ansible: please package new upstream version 8.x

2023-08-31 Thread Lee Garrett


Hi Dominik,

indeed! I'm currently letting the version of ansible/ansible-core in unstable 
linger a little bit longer to get some more testing, before pushing it as a 
stable-update. As soon as that is done, I'll package the latest for unstable again.


Greets,
Lee

On 02.08.23 17:13, Dominik George wrote:

Source: ansible
Version: 7.3.0+dfsg-1
Severity: wishlist

Hi Lee,

Ansible upstream is currently at 8.2.

In order to not having to resort to pip install, an update
of Debian's ansible package would be much appreciated.

Cheers,
Nik

Bug#1050806: O: debianutils -- Essential utilities specific to Debian

2023-08-31 Thread Ileana Dumitrescu


Hi,

I would like to become maintainer of debianutils. I believe I have the 
skills necessary including some experience using several of the scripts 
that debianutils ships. This is an essential package that I think should 
always have a maintainer, and I have a lot of time to devote to it.


I'm more of a cat person, but I will try to handle all of the dog's 
breakfasts :P


--
Ileana Dumitrescu

GPG Public Key: FA26 CA78 4BE1 8892 7F22 B99F 6570 EA01 146F 7354


OpenPGP_0x6570EA01146F7354.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1050934: rust-der-parser: Please upgrade to v0.8

2023-08-31 Thread Jonas Smedegaard

Source: rust-der-parser
Version: 6.0.1-3
Severity: normal
Tags: upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please upgrade (or separately package) newer upstream branch v0.8.

- - Jonas
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmTwnnQACgkQLHwxRsGg
ASGI3hAAhsoYPCCj37ZnH/4+Ihfvl9/Z+VTQdZl6O2jnWfEFvdTzt/5MckoWIaw5
xK/zFvgm1PqynhoJplqsgp/RaHaM13geu0D23hMfrHu3Jl1ihLg48Szk2Qz0L/gt
IzEbUR2EIzmgkMF/7LiDO4KF6DWNSorVaGAfUgB1pNepbhoQ1833lmj8FOM8dHGs
IRalyJuqbKsO4U/41IeMFkV2QllW0LMB4W7Tn2U8r5LQ19TcJoC6KWm7Tmt4/Mtz
mi9FhRK8kh5AaoN5iBtSXfWLaoCFyur+KzyymGNAEe8BWeHxovwp6Vg3TLknqsZB
KM+SwTCvQOdnaQADhKfYZw+Hh/d+Gy0IeW+sSQzc21qiTMZCauCev6UNT5Orijdh
Mo4YKA4O5kEOrDPtmTfpF/Km46KW/L6s05OivvgWm7ZZOTkLWhbldSTaAfkjEdah
p1KPxlrtt1Y2Pnq8UVCcbbevYitGWp9C2kecNFkDZXRffP8JdQyyKa6FFsL1H282
K3duRTz9Pw8iWRVP3lMUS8DsJMJ8zUqQ+SaEFcsLgrdMQ75g3cCuzAnl4pP2TjUc
bJqO6jjwI4o3e4ZCZeCpw974Yp2ILVANWNeCOZhtERUifBvVRcxrtdKS8BUkr9vI
bcQcm+xxx6hJhDpSBDv8QO1UA2afAKKncjB5+Qeoc6s6ObuK4QU=
=Nk/D
-END PGP SIGNATURE-

Bug#1050812: u-boot-rockchip: Please add support for Pine64 Quartz64 devices

Hi Diederik,

Sorry, our mails collided and I didn't see your previous reply.

On Thu, 2023-08-31 at 15:41 +0200, Diederik de Haas wrote:
> On Thursday, 31 August 2023 14:14:38 CEST Christopher Obbard wrote:
> > This is the case for some other devices (e.g. rk3588) currently where there
> > is support in U-Boot mainline but there is no arm-trusted-firmware support
> > _or_ DDR bringup in U-Boot as yet.
> 
> I do follow the linux-rockchip ML and it looks like kernel 6.6 is getting 
> rather interesting for rk3588 support.
> I'm less 'in the loop' wrt rk3588 on u-boot and TF-A although I did post this:
> https://forum.pine64.org/showthread.php?tid=14432=117094#pid117094

There are a few open pull requests from Rockchip to add support but it is likely
to take a while to be merged.

> I do expect for TF-A support to land upstream for rk3588 (eventually), but do 
> you know (or suspect) that DRAM init will be open sourced too?

I am not entirely sure of Rockchip's plans here.

I have added Kever to the thread who can hopefully suggest when DRAM init code
and TF-A support for various Rockchip processors will be submitted to mainline?

> Note that I don't _fully_ understand these things, so if what I'm saying 
> doesn't make any sense, feel free to point that out :-)

So far so good ;-). The only clarification I would like to make is the DDR init 
code
is standalone, part of the TPL and is not anything to do with TF-A. It really 
is the
first-stage boot code that runs after the maskrom.

We could use Rockchip's closed implementation of that OR U-Boot's 
implementation, it's
only real job is to train the DDR and handoff to U-Boot SPL.

> > It'd be great to get Debian running on some of this more recent Rockchip
> > hardware
> 
> I'm currently working on that. Although it's initially for Quartz64 Model A+B 
> and PineTab2 (all rk3566) devices, I don't see why it wouldn't be usable for 
> rk3588 devices too as (long as) they're all arm64.
> 
> AFAICT (now), I can just make 1 image as the only differentiator would be the 
> specific u-boot binary that needs to be put in place and I can just make an 
> instruction to `dd` the right u-boot binary onto sector 64 of the image file.
> 
> Thus https://github.com/Kwiboo/u-boot-build/#flashing with `/dev/mmcblk0` 
> replaced by my image file.

To build U-Boot in Debian for these "new" targets we'd need to:
1) build and distribute U-Boot for these "new" targets without the TPL/TF-A
2) package rkbin for Debian in non-free-firmware (I will happily do that)
3) have some scripts to collate the various bits into proper images (that 
probably
should go inside the image-building tool rather than in a Debian package like
flash-kernel, since it will be hopefully obsolete one day :-))

> 
> https://salsa.debian.org/diederik/linux/-/tree/pine64/master-next is the 
> kernel I (currently) use, which is based (and periodically rebased up) on the 
> Debian kernel (with the intend to 'upstream' it to Debian's kernel when 
> that's 
> appropriate).

Great! I am interested in bringing up more of these boards in Debian too.
I have some custom Debos recipes to build some images for these boards, but the
recipes really aren't yet ready to go anywhere until we get kernel and 
bootloader
sorted out.

Thanks!

Chris

Bug#1050933: aarch64: Miscompilation at O1 level (O0 is working)

2023-08-31 Thread Mathieu Malaterre

Package: g++-13
Version: 13.2.0-2
Forwarded: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110643
Affects: src:highway

I am getting some odd behavior for unit test of highway. I believe
there is some wrong-code generation using g++ + -O1.

Bug#1050932: wget2: -X and --exclude-directories do not work

2023-08-31 Thread Francesco Potortì

Package: wget2
Version: 1.99.1-2.2
Severity: normal
X-Debbugs-Cc: none, Francesco Potortì 

$ wget2 -X /cache evaal.aaloa.org
Unknown option '-X'

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

Kernel: Linux 6.0.0-6-amd64 (SMP w/24 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=it_IT.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 wget2 depends on:
ii  libc6 2.37-7
ii  libgpgme111.18.0-3+b1
ii  libpcre2-8-0  10.42-3
ii  libwget0  1.99.1-2.2

Versions of packages wget2 recommends:
ii  ca-certificates  20230311

wget2 suggests no packages.

-- no debconf information

Bug#1050812: u-boot-rockchip: Please add support for Pine64 Quartz64 devices

2023-08-31 Thread Diederik de Haas

On Thursday, 31 August 2023 14:14:38 CEST Christopher Obbard wrote:
> This is the case for some other devices (e.g. rk3588) currently where there
> is support in U-Boot mainline but there is no arm-trusted-firmware support
> _or_ DDR bringup in U-Boot as yet.

I do follow the linux-rockchip ML and it looks like kernel 6.6 is getting 
rather interesting for rk3588 support.
I'm less 'in the loop' wrt rk3588 on u-boot and TF-A although I did post this:
https://forum.pine64.org/showthread.php?tid=14432=117094#pid117094

I do expect for TF-A support to land upstream for rk3588 (eventually), but do 
you know (or suspect) that DRAM init will be open sourced too?

Note that I don't _fully_ understand these things, so if what I'm saying 
doesn't make any sense, feel free to point that out :-)

> It'd be great to get Debian running on some of this more recent Rockchip
> hardware

I'm currently working on that. Although it's initially for Quartz64 Model A+B 
and PineTab2 (all rk3566) devices, I don't see why it wouldn't be usable for 
rk3588 devices too as (long as) they're all arm64.

AFAICT (now), I can just make 1 image as the only differentiator would be the 
specific u-boot binary that needs to be put in place and I can just make an 
instruction to `dd` the right u-boot binary onto sector 64 of the image file.

Thus https://github.com/Kwiboo/u-boot-build/#flashing with `/dev/mmcblk0` 
replaced by my image file.

https://salsa.debian.org/diederik/linux/-/tree/pine64/master-next is the 
kernel I (currently) use, which is based (and periodically rebased up) on the 
Debian kernel (with the intend to 'upstream' it to Debian's kernel when that's 
appropriate).

Cheers,
  Diederik

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

Bug#1050931: cutefish-core: please provide a cutefish-portals.conf for xdg-desktop-portal