date:20230128

Control: tag -1 patch pending

Cyril Brulebois  (2023-01-29):
> If we really want not to use a bare /firmware, maybe /firmware-lookup?
> But having something specialized in hw-detect and something much more
> generic in preseed would look strange to me. I don't really mind either
> way.

This seems to work fine:
 - https://salsa.debian.org/installer-team/hw-detect/-/commits/non-free-firmware
 - https://salsa.debian.org/installer-team/preseed/-/commits/non-free-firmware

Test environments:

 - VM with a Realtek Wi-Fi USB dongle shared from the host, which
   requests firmware even if it doesn't *need* it at least for basic
   operations (incl. WPA2); installed by sharing the netinst image
   as a CD-ROM.
+ tested with default boot parameters
+ tested with firmware=never

 - Dell G3 15 pulling many firmware packages (iwlwifi, linux-free,
   misc-nonfree, realtek, sof-signed); installed using the netinst
   image deployed on a USB stick. [That's the one where iwlwifi also
   wants iwl-debug-yoyo.bin, which was blocklisted for bullseye, and
   that still works.]
+ tested with default boot parameters
+ tested with hw-detect/firmware-lookup=never

With “never”, since the firmware isn't really needed in the first case,
I had to pick one interface of the wired/wireless ones, like when using
default boot parameters; in the second case, the wired interface was
picked up automatically.

In both cases, the resulting sources.list correctly lists only main,
despite the netinst image's having local, main, non-free, and
non-free-firmware. firmware-linux-free is installed in both cases
(it's recommended by linux-image-$ABI).


If someone fancies different names, the time is now! Meeting with Steve
coming up in a few hours, I'll upload shortly after.


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


signature.asc
Description: PGP signature

Bug#1028994: [Pkg-mailman-hackers] Bug#1028994: mailman3: (autopkgtest) needs update for Python 3.11

2023-01-28 Thread Petter Reinholdtsen



[Sebastiaan Couwenberg]
> How is that going?
> 
> mailman3 is the last major blocker for testing migration of
> python3-defaults.

No idea what is going on, but thought it best to mention that mailman3
has been removed from testing because of this issue.
-- 
Happy hacking
Petter Reinholdtsen

Bug#1029672: RFP: django-model2puml -- Generator of project models structure in PlantUML class notation

2023-01-28 Thread Petter Reinholdtsen



I have asked upstream if they are interested in this,
https://github.com/sen-den/django-model2puml/issues/7 >

-- 
Happy hacking
Petter Reinholdtsen

Bug#1029932: Can no longer use 4k when mirroring to LG OLED TV

2023-01-28 Thread Josh Triplett

Package: gnome-settings-daemon
Version: 43.0-4
Severity: normal
X-Debbugs-Cc: j...@joshtriplett.org

I don't know if this issue lies in gnome-settings-daemon, mutter,
gnome-shell, the kernel, or somewhere else.

Some time in the last month or two, something changed such that I can no
longer use 4k with mirror mode over HDMI to an LG OLED TV (tested with
both C2 and G2). Instead, I'm limited to 2560x1440. If I use "join"
mode, I can set the TV to 4k, but mirror mode no longer allows 4k.

My laptop screen is 3840x2400. In the past, mirror mode worked at
3840x2160 and just letterboxed on the laptop screen.

ThinkPad X1 Carbon 9th gen. Intel graphics. Happy to provide more
information.


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

Kernel: Linux 6.1.0-2-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)

Versions of packages gnome-settings-daemon depends on:
ii  gnome-settings-daemon-common  43.0-4
ii  gsettings-desktop-schemas 43.0-1
ii  libasound21.2.8-1+b1
ii  libc6 2.36-8
ii  libcairo2 1.16.0-7
ii  libcanberra-gtk3-00.30-10
ii  libcanberra0  0.30-10
ii  libcolord21.4.6-2.1
ii  libcups2  2.4.2-1+b2
ii  libfontconfig12.14.1-3
ii  libgcr-base-3-1   3.41.1-1+b1
ii  libgdk-pixbuf-2.0-0   2.42.10+dfsg-1+b1
ii  libgeoclue-2-02.6.0-2
ii  libgeocode-glib-2-0   3.26.3-5
ii  libglib2.0-0  2.74.5-1
ii  libgnome-desktop-3-20 43.1-1
ii  libgtk-3-03.24.36-2
ii  libgudev-1.0-0237-2
ii  libgweather-4-0   4.2.0-1
ii  libmm-glib0   1.20.4-1
ii  libnm01.40.10-1
ii  libnotify40.8.1-1
ii  libnspr4  2:4.35-1
ii  libnss3   2:3.87-1
ii  libpam-systemd [logind]   252.4-2
ii  libpango-1.0-01.50.12+ds-1
ii  libpangocairo-1.0-0   1.50.12+ds-1
ii  libpolkit-gobject-1-0 122-2
ii  libpulse-mainloop-glib0   16.1+dfsg1-2+b1
ii  libpulse0 16.1+dfsg1-2+b1
ii  libspa-0.2-bluetooth  0.3.64-4
ii  libupower-glib3   0.99.20-2
ii  libwacom9 2.5.0-1
ii  libwayland-client01.21.0-1
ii  libx11-6  2:1.8.3-3
ii  libxext6  2:1.3.4-1+b1
ii  libxfixes31:6.0.0-2
ii  libxi62:1.8-1+b1
ii  pipewire-audio0.3.64-4

Versions of packages gnome-settings-daemon recommends:
pn  iio-sensor-proxy   
ii  pipewire-audio 0.3.64-4
ii  pkexec 122-2
ii  x11-xserver-utils  7.7+9+b1

Versions of packages gnome-settings-daemon suggests:
pn  usbguard  

-- no debconf information

Bug#1029931: pushpin: build-dependencies unsatisfiable on mips*, ppc64el and s390x.

2023-01-28 Thread Peter Michael Green


Package: pushpin
Version: 1.36.0-1
Severity: serious

The new version of pushpin added a dependency on jsonwebtoken,
unfortunately jsonwebtoken depends in ring, which is only available
on x86* and arm*. There is work upstream to make ring more
portable but it seems unlikely to feature in a stable release before
the bookworm freeze.

Not sure what can be done about this, I tried reverting the
upstream commit in question using a Debian patch, but it did not
seem to revert cleanly.

Bug#1014369: Regression: incorrect icon used in 0.8.0

2023-01-28 Thread Konomi

I'm also waiting for 0.8.1 to enter unstable so I can test if this bug
is resolved. It would be nice to have an update.

Bug#1027851: pytorch FTBFS with Python 3.11 as default version

2023-01-28 Thread M. Zhou

For reference, a 8 core + 16GB RAM configuration should be able to finish the
pytorch compilation timely. The build takes roughly an hour. My observation
is based on power9 -- on amd64 it should be something similar.


On Sun, 2023-01-29 at 11:09 +0800, Aron Xu wrote:
> On Fri, Jan 27, 2023 at 9:42 PM Andreas Tille  wrote:
> > 
> > Am Fri, Jan 27, 2023 at 08:21:46PM +0800 schrieb Aron Xu:
> > > On Fri, Jan 27, 2023 at 7:12 PM Andreas Tille  wrote:
> > > >   make: *** [debian/rules:83: binary] Terminated
> > > >   ninja: build stopped: interrupted by user.
> > > > 
> > > > could be a sign for this.  Was I to naive to assume Salsa CI could
> > > > manage a pytorch build and should we possibly switch this off again?
> > > > 
> > > 
> > > Not sure but by wild guess it could be caused by running for too long?
> > 
> > I do not think so.  Since I was aware that it will take long I have
> > adjusted the timeout from 1h (default) to 4h.  The log stops a bit after
> > 3h.  To my experience if timeout is the reason the log ends with this
> > information.
> > 
> 
> Then I guess it could be out-of-memory, the build process is hungry
> for RAM and a single cc1plus process can take at least up to 2GB
> memory during my quick observation.
> 
> Regards,
> Aron
>

Bug#1029930: buskill: Homepage URL is 404

2023-01-28 Thread Paul Wise

Package: buskill
Version: 0.6.0+git20221227.e1539d2-1
Severity: normal

The URL in the Homepage field is 404 Not Found.

Probably this is the right URL instead:

https://github.com/BusKill/buskill-app

Or potentially just the URL for the hardware:

https://www.buskill.in/

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#1029136: MariaDB configuration files not properly migrated on switch to unversioned packages

2023-01-28 Thread Otto Kekäläinen

Hi!

I managed now to reproduce this. The purge step is not relevant, but
simply the upgrade itself.


In clean Docker container with Debian unstable:

$ apt install -y mariadb-server-10.6
-> install successful

$ apt full-upgrade -y
-> does nothing

$ service mariadb restart
Stopping MariaDB database server: mariadbd.
Starting MariaDB database server: mariadbd.

$ apt install mariadb-server -y
The following packages will be REMOVED:
  mariadb-client-10.6 mariadb-client-core-10.6 mariadb-server-10.6
mariadb-server-core-10.6
The following NEW packages will be installed:
  mariadb-client mariadb-client-core mariadb-server mariadb-server-core pv

$ service mariadb restart
mariadb: unrecognized service

-> upgrade successful, but service stopped working - the service file
has no executable bit anymore.

$ dpkg -l | grep -iE 'maria|mysql|galera'
ii  galera-4  26.4.11-1+b2   amd64
Replication framework for transactional applications
ii  libdbd-mariadb-perl   1.22-1+b1  amd64Perl5
database interface to the MariaDB/MySQL databases
ii  libmariadb3:amd64 1:10.11.1-1amd64MariaDB
database client library
ii  mariadb-client1:10.11.1-1amd64MariaDB
database client binaries
rc  mariadb-client-10.6   1:10.6.11-2amd64MariaDB
database client binaries
ii  mariadb-client-core   1:10.11.1-1amd64MariaDB
database core client binaries
ii  mariadb-common1:10.11.1-1all  MariaDB
common configuration files
ii  mariadb-server1:10.11.1-1amd64MariaDB
database server binaries
rc  mariadb-server-10.6   1:10.6.11-2amd64MariaDB
database server binaries
ii  mariadb-server-core   1:10.11.1-1amd64MariaDB
database core server files
ii  mysql-common  5.8+1.1.0  all  MySQL
database common files, e.g. /etc/mysql/my.cnf

$ find /etc -name '*mariadb*' -type f -ls
-rw-r--r--   1 root root 6387 Jan 15 22:45 /etc/init.d/mariadb
-rw-r--r--   1 root root 1859 Jan 15 22:45 /etc/logrotate.d/mariadb
-rw-r--r--   1 root root 1126 Jan  8 01:45 /etc/mysql/mariadb.cnf
-rw-r--r--   1 root root  730 Jan  3 06:42
/etc/apparmor.d/usr.sbin.mariadbd
-rw-r--r--   1 root root  716 Jan  3 06:42
/etc/logcheck/ignore.d.paranoid/mariadb-server-10_6
-rw-r--r--   1 root root  716 Jan 15 22:45
/etc/logcheck/ignore.d.paranoid/mariadb-server
-rw-r--r--   1 root root 2153 Jan  3 06:42
/etc/logcheck/ignore.d.server/mariadb-server-10_6
-rw-r--r--   1 root root 2153 Jan 15 22:45
/etc/logcheck/ignore.d.server/mariadb-server
-rw-r--r--   1 root root 2153 Jan  3 06:42
/etc/logcheck/ignore.d.workstation/mariadb-server-10_6
-rw-r--r--   1 root root 2153 Jan 15 22:45
/etc/logcheck/ignore.d.workstation/mariadb-server

$ apt purge 'mariadb-*-10.6' -y
The following packages will be REMOVED:
  mariadb-client-10.6* mariadb-server-10.6*

$ find /etc -name '*mariadb*' -type f -ls
-rw-r--r--   1 root root 6387 Jan 15 22:45 /etc/init.d/mariadb
-rw-r--r--   1 root root 1859 Jan 15 22:45 /etc/logrotate.d/mariadb
-rw-r--r--   1 root root 1126 Jan  8 01:45 /etc/mysql/mariadb.cnf
-rw-r--r--   1 root root  730 Jan  3 06:42
/etc/apparmor.d/usr.sbin.mariadbd
-rw-r--r--   1 root root  716 Jan 15 22:45
/etc/logcheck/ignore.d.paranoid/mariadb-server
-rw-r--r--   1 root root 2153 Jan 15 22:45
/etc/logcheck/ignore.d.server/mariadb-server
-rw-r--r--   1 root root 2153 Jan 15 22:45
/etc/logcheck/ignore.d.workstation/mariadb-server

-> purge works as expected

Bug#1027851: pytorch FTBFS with Python 3.11 as default version

2023-01-28 Thread Aron Xu

On Fri, Jan 27, 2023 at 9:42 PM Andreas Tille  wrote:
>
> Am Fri, Jan 27, 2023 at 08:21:46PM +0800 schrieb Aron Xu:
> > On Fri, Jan 27, 2023 at 7:12 PM Andreas Tille  wrote:
> > >   make: *** [debian/rules:83: binary] Terminated
> > >   ninja: build stopped: interrupted by user.
> > >
> > > could be a sign for this.  Was I to naive to assume Salsa CI could
> > > manage a pytorch build and should we possibly switch this off again?
> > >
> >
> > Not sure but by wild guess it could be caused by running for too long?
>
> I do not think so.  Since I was aware that it will take long I have
> adjusted the timeout from 1h (default) to 4h.  The log stops a bit after
> 3h.  To my experience if timeout is the reason the log ends with this
> information.
>

Then I guess it could be out-of-memory, the build process is hungry
for RAM and a single cc1plus process can take at least up to 2GB
memory during my quick observation.

Regards,
Aron

Bug#1029929: msmtp-mta fails to purge when adduser is not installed

Package: msmtp-mta
Version: 1.8.22-1
Severity: serious

https://piuparts.debian.org/sid/fail/msmtp-mta_1.8.22-3.log

...
  Purging configuration files for msmtp-mta (1.8.22-3) ...
  /var/lib/dpkg/info/msmtp-mta.postrm: 8: deluser: not found
  dpkg: error processing package msmtp-mta (--purge):
   installed msmtp-mta package post-removal script subprocess returned error 
exit status 127
  Errors were encountered while processing:
   msmtp-mta



Similar to #1029799, but for the other binary package.

Bug#1029163: Acknowledgement (mariadb: FTBFS on armel, armhf, mipsel, mips64el: builds, but test suite fails in main.explain_json_format mismatches)

2023-01-28 Thread Otto Kekäläinen

Hi!

We have a MR at
https://salsa.debian.org/mariadb-team/mariadb-server/-/merge_requests/28
by Adrian (titled HACK), discussions and code snippets at
https://jira.mariadb.org/browse/MDEV-30411 and a new patch by Daniel
at https://patch-diff.githubusercontent.com/raw/MariaDB/server/pull/2448.patch.

What is your combined assessment of these, which one should I apply on
MariaDB 10.11.1-2 and upload to Debian tomorrow?

Bug#1029910: Fixing it

2023-01-28 Thread Peter Chubb



doing
  sudo service mailman3-web stop
  sudo /usr/share/mailman3-web/manage.py  makemigrations --merge
  sudo -u www-data usr/share/mailman3-web/manage.py  migrate
  sudo -u www-data usr/share/mailman3-web/manage.py  compress
  sudo -u www-data usr/share/mailman3-web/manage.py  collectstatic
  sudo service mailman3-web start

fixed it.
-- 
Dr Peter Chubbhttps://trustworthy.systems/
Trustworthy Systems GroupCSE, UNSW
Core hours: Mon 8am-3pm; Wed: 8am-5pm; Fri 8am-12pm.

Bug#1029927: Unable run removal scripts

2023-01-28 Thread Jérôme Charaoui


I've submitted a merge request on salsa to fix this issue:

https://salsa.debian.org/debian/dbconfig-common/-/merge_requests/9

Thanks!

Bug#1029848: hw-detect: decide how to configure firmware support

Steve McIntyre  (2023-01-29):
> >I'm proposing:
> > - “hw-detect/firmware” as template for hw-detect;
> 
> I was thinking "hw-detect/load_firmware" might be better - we may
> want/need more firmware questions yet, so let's leave the namespace
> open?

That's exactly what someone has already thought about, and used to
implement the “Load missing firmware from removable media?” prompt.

If we really want not to use a bare /firmware, maybe /firmware-lookup?
But having something specialized in hw-detect and something much more
generic in preseed would look strange to me. I don't really mind either
way.

> > - “firmware” or “fw” as an alias for shorter typing (“fw” feels like
> >   extremely short);
> 
> I'd just go for "firmware" here; "fw" might be confused with firewall
> (I see Andy had a similar thought).

Agreed, let's go with “firmware”.

> > - “never” value to skip firmware handling altogether, meaning
> >   skipping both mechanisms mentioned above.
> 
> Maybe, yeah. That's probably clearest. Then we'd default to "always".

That's the *spirit* of it but not the letter:
 - I'm implementing support for “never”.
 - I'm not implementing support “always”. It doesn't exist. It isn't
   specified. This isn't the value you're looking for! :)

More seriously, the template doesn't even come with a default value. I'm
using db_get and "$RET" = never to implement early exit, that's all.

> >That would leave us a rather important flexibility regarding other
> >behaviours that we might want to implement, depending on the use
> >cases that might get identified (#1029543), without having to make a
> >decision about those (names and associated semantic) right now.
> 
> Yup, good call. We can extend this more to add the nuanced options
> once we've got the basics - let's do it incrementally!

Thanks for confirming the approach!


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


signature.asc
Description: PGP signature

Bug#1029928: dials: autopkgtest failure on arm64/ppc64el

Source: dials
Version: 3.12.1+dfsg3-4
Severity: serious

https://ci.debian.net/data/autopkgtest/testing/arm64/d/dials/30737888/log.gz
https://ci.debian.net/data/autopkgtest/testing/ppc64el/d/dials/30737889/log.gz

...
== FAILURES ===
___ test_versus_brute_force 

def test_versus_brute_force():
"""Perform a regression test by comparing to indices generated by the 
brute
force method"""

# cubic, 50A cell, 1A radiation, 1 deg osciillation, everything ideal
a = 50.0
ub_beg = matrix.sqr((1.0 / a, 0.0, 0.0, 0.0, 1.0 / a, 0.0, 0.0, 0.0, 
1.0 / a))
axis = matrix.col((0, 1, 0))
r_osc = matrix.sqr(
r3_rotation_axis_and_angle_as_matrix(axis=axis, angle=1.0, deg=True)
)
ub_end = r_osc * ub_beg
uc = unit_cell((a, a, a, 90, 90, 90))
sg = space_group(space_group_symbols("P23").hall())
s0 = matrix.col((0, 0, 1))
wavelength = 1.0
dmin = 1.5

# get the full set of indices
indices = full_sphere_indices(unit_cell=uc, resolution_limit=dmin, 
space_group=sg)

# find the observed indices
ra = rotation_angles(dmin, ub_beg, wavelength, axis)
obs_indices, obs_angles = 
ra.observed_indices_and_angles_from_angle_range(
phi_start_rad=0.0 * math.pi / 180.0,
phi_end_rad=1.0 * math.pi / 180.0,
indices=indices,
)

# r = reeke_model(ub_beg, ub_end, axis, s0, dmin, 1.0)
# reeke_indices = r.generate_indices()

# now try the Reeke method to generate indices
r = ReekeIndexGenerator(ub_beg, ub_end, sg.type(), axis, s0, dmin, 
margin=1)
reeke_indices = r.to_array()

for oi in obs_indices:
>   assert tuple(map(int, oi)) in reeke_indices
E   assert (-30, 0, -10) in 
E+  where (-30, 0, -10) = tuple()
E+where  = map(int, (-30.0, 0.0, 
-10.0))

tests/algorithms/spot_prediction/test_reeke_index_generator.py:134: 
AssertionError
...
=== short test summary info 
FAILED 
tests/algorithms/spot_prediction/test_reeke_index_generator.py::test_versus_brute_force
= 1 failed, 820 passed, 531 skipped, 1 xfailed, 43 warnings in 1466.82s 
(0:24:26) =
autopkgtest [23:44:38]: test command1: ---]
autopkgtest [23:44:38]: test command1:  - - - - - - - - - - results - - - - - - 
- - - -
command1 FAIL non-zero exit status 1

Bug#1029927: Unable run removal scripts

2023-01-28 Thread Jérôme Charaoui


Package: dbconfig-common
Version: 2.0.22

Hello,

I would like to provide a dbconfig-common removal script, to remove an 
extra read-only database user account, by installing an executable at:


/usr/share/dbconfig-common/scripts/puppetdb/remove/pgsql

However, there is an error when the maintainer script is invoked via 
dbconfig-common:


running maintainer removal script hook...  remove": 1: Syntax 
error: Unterminated quoted string 



error encountered running maintainer removal hook: 



/usr/share/dbconfig-common/scripts/puppetdb/remove/pgsql existed 
with non-zero status


When I invoke the script manually, it works fine, so it seems to be a 
problem with dbconfig-common itself.



Thanks,

-- Jérôme

Bug#1029926: nagios-plugins-contrib: autopkgtest regression

Source: nagios-plugins-contrib
Version: 38.20230124
Severity: serious

https://ci.debian.net/data/autopkgtest/testing/amd64/n/nagios-plugins-contrib/30770474/log.gz

...
autopkgtest [00:15:02]: test command7: /usr/lib/nagios/plugins/check_ssl_cert 
-H www.debian.org
autopkgtest [00:15:02]: test command7: [---
SSL_CERT UNKNOWN www.debian.org: cannot find program: bc
autopkgtest [00:15:03]: test command7: ---]
autopkgtest [00:15:03]: test command7:  - - - - - - - - - - results - - - - - - 
- - - -
command7 FAIL non-zero exit status 3
...
autopkgtest [00:15:56]:  summary
command1 PASS
command2 PASS
command3 PASS
command4 PASS
command5 PASS
command6 PASS
command7 FAIL non-zero exit status 3
command8 PASS
command9 PASS

Bug#1029925: nut-monitor: exits by SIGABRTing

2023-01-28 Thread наб

Package: nut-monitor
Version: 2.8.0-7
Severity: normal

Dear Maintainer,

Every time I close the monitor window I see
-- >8 --
$ NUT-Monitor
Traceback (most recent call last):
  File "/bin/NUT-Monitor", line 326, in quit
self.disconnect_from_ups()
  File "/bin/NUT-Monitor", line 775, in disconnect_from_ups
self.gui_init_unconnected()
  File "/bin/NUT-Monitor", line 770, in gui_init_unconnected
self.__widgets["main_window"].adjustSize()
RuntimeError: wrapped C/C++ object of type QMainWindow has been deleted
Aborted
-- >8 --

I think I'm on a relatively normal set-up; happy to test whatever,
but neither python nor qt are my preferred brand of poison,
so dunno what I'd start with.

Best,
наб

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

Kernel: Linux 5.10.0-20-amd64 (SMP w/24 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_FIRMWARE_WORKAROUND, 
TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages nut-monitor depends on:
ii  python33.9.2-3
ii  python3-nut2.8.0-7
ii  python3-pyqt5  5.15.2+dfsg-3

nut-monitor recommends no packages.

nut-monitor suggests no packages.

-- no debconf information


signature.asc
Description: PGP signature

Bug#1029848: hw-detect: decide how to configure firmware support

2023-01-28 Thread Steve McIntyre

Hey kibi!

On Sat, Jan 28, 2023 at 08:09:58PM +0100, Cyril Brulebois wrote:
>Package: hw-detect
>Severity: important
>
>Hi,
>
>
># Context
>
>Quoting the text that was agreed to via the 2022 General Resolution
>about non-free firmware:
>
>We will include non-free firmware packages from the "non-free-firmware"
>section of the Debian archive on our official media (installer images
>and live images).
>
>This means that images built by debian-cd (like netinst) will have main
>and non-free-firmware packages available under /firmware, with metadata
>under /firmware/dep11, making it easy for hw-detect to:
>
> - Resolve firmware files (spotted as missing by looking at dmesg) into
>   firmware packages (if available), deploy those packages in the
>   installer environment, tweak apt-setup's default configuration, and
>   install those packages in the target environment.
>
>→ Implemented by check-missing-firmware (detection & deployment in
>  the installer environment) and install-firmware hooks (enabling
>  apt-setup/non-free-firmware if relevant, installing in target
>  environment).
>
> - Detect firmware packages based on modalias information (in case
>   missing firmware didn't trigger lines in dmesg), not deploying them
>   in the installer environment, but queuing them for installation in
>   the target environment (also tweaking apt-setup's default config).
>
>→ Implemented by install-firmware hooks.

Yup.

>(Implementation detail: There are two install-firmware hooks, one after
>base-installer, one before pkgsel.)
>
>
># Allowing for main-only
>
>The next sentence of the text that was agreed to is:
>
>The included firmware binaries will normally be enabled by default
>where the system determines that they are required, but where
>possible we will include ways for users to disable this at boot
>(boot menu option, kernel command line etc.).
>
>I'd like us to determine the following things:
> - the best name for an internal-only template for hw-detect;
> - the best alias for it, to be used e.g. on the Linux command line, to
>   save some typing;
> - what values it should support;
> - what semantics should be attached to those values.
>
>Even before working on non-free-firmware integration, there were many
>possible combinations. With the ongoing work, we aim at making it easy
>for most users to just get a successful installation, and I've proposed
>to streamline alternate use cases (see #1029543), so that we can focus
>on supporting maybe fewer things, but supporting them well.
>
>hw-detect already has a loop, the concept of searching for firmware on
>external media, the concept of asking, etc.
>
>It really doesn't make sense to me to have any kind of per-file,
>per-module, or per-package granularity. This would mean many prompts,
>possibly with way too many lines (see how many files iwlwifi can
>request), and wouldn't really help users make an informed decision.
>Extra templates would also mean more work for translators…
>
>Therefore, my current approach would be not to try and implement some
>yes/ask/no trichoice as originally envisioned, but to provide users
>wanting to avoid firmware altogether a way to do so.
>
>
>I'm proposing:
> - “hw-detect/firmware” as template for hw-detect;

I was thinking "hw-detect/load_firmware" might be better - we may
want/need more firmware questions yet, so let's leave the namespace
open?

> - “firmware” or “fw” as an alias for shorter typing (“fw” feels like
>   extremely short);

I'd just go for "firmware" here; "fw" might be confused with firewall
(I see Andy had a similar thought).

> - “never” value to skip firmware handling altogether, meaning skipping
>   both mechanisms mentioned above.

Maybe, yeah. That's probably clearest. Then we'd default to "always".

>That would leave us a rather important flexibility regarding other
>behaviours that we might want to implement, depending on the use cases
>that might get identified (#1029543), without having to make a decision
>about those (names and associated semantic) right now.

Yup, good call. We can extend this more to add the nuanced options
once we've got the basics - let's do it incrementally!

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"C++ ate my sanity" -- Jon Rabone

Bug#1029924: RM: rust-nom-locate [amd64 arm64 armel armhf i386 mips64el mipsel ppc64el s390x] -- NBS; only a binary-all package is now built

Package: ftp.debian.org
Severity: normal

The package switched from building several binary-any packages
to building one binary-all package, which needs cruft removal
of the stale binary-any packages.

Bug#1029641: tagging 1029641

2023-01-28 Thread Axel Beckert

Hi Adrian, hi Matthias,

Adrian Bunk wrote:
> On Sun, Jan 29, 2023 at 12:41:48AM +0100, Axel Beckert wrote:
> > # https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1029633#10
> > tags 1029641 + moreinfo
> > thanks
> 
> What info is missing here

There seems some strong disagreement on this request between you two.
Please discuss this topic first with each other at least bit and
preferably come to some consensus.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#1029409: RFS: quadrilateralcowboy/1~20160725-8 [ITP] -- first-person cyberpunk adventure game

2023-01-28 Thread James Addison

Package: sponsorship-requests
Followup-For: Bug #1029409

Control: reopen 1029409
Control: retitle 1029409 RFS: quadrilateralcowboy/1~20160725-1 [ITP] -- 
first-person cyberpunk adventure game

Package re-uploaded as quadrilateralcowboy/1~20160725-1 - thanks, bartm for 
following the changes (and temporary deletion).

Bug#791635: python-policy: Please require namespacing source python module packages

2023-01-28 Thread Scott Kitterman

Do we really have to have this argument again?  Let's not.  Please wontfix and 
let's move on.

Personally, I maintain 25 packages in the team that would need renaming.  I'm 
not sure how many total there are, but they'd all have to go through New again.

It'd be much simpler just to drop DPT or myself from uploaders and ignore this, 
so that's probably the path I would take.

Regardless, I don't think this is an appropriate use of FTP Team time/energy.

Also, as I've said before on this topic, every packaging rule is a barrier to 
entry for new contributors.  We really shouldn't add things that aren't needed.

Scott K

On January 29, 2023 12:57:37 AM UTC, Guillem Jover  wrote:
>Control: reopen -1
>Control: reassign -1 python3
>
>[ Sorry, resending, as the bug was archived so it ignored all the
>  control commands. ]
>
>This got closed due to the python-defaults package being removed from
>sid, reopening and reassigning where python-policy seems to be located
>now.
>
>On Tue, 2022-12-27 at 23:29:30 +, Debian Bug Tracking System wrote:
>> Date: Tue, 7 Jul 2015 03:11:06 +0200
>> From: Guillem Jover 
>> To: sub...@bugs.debian.org
>> Subject: python-policy: Please require namespacing source python module
>>  packages
>> Message-ID: <20150707011106.ga12...@gaara.hadrons.org>
>> User-Agent: Mutt/1.5.23 (2014-03-12)
>> X-Spam-Status: No, score=-6.6 required=4.0 tests=BAYES_00,FROMDEVELOPER,
>>  RCVD_IN_DNSWL_MED,RP_MATCHES_RCVD autolearn=ham autolearn_force=no
>>  version=3.4.0-bugs.debian.org_2005_01_02
>> 
>> Source: python-defaults
>> Source-Version: 2.7.9-1
>> Severity: wishlist
>> 
>> Hi!
>> 
>> Given recent ITP discussions [0] about lack of namespacing on python
>> module source package names, I think it would be really good to fix
>> this at the source, by mandating it in the python-policy. Attached is
>> a proposal wording.
>> 
>>   [0] #748383: ITP: bash8; #745347: ITP: releases; #790399: ITP: structlog
>> 
>> Thanks,
>> Guillem
>
>> === modified file 'debian/python-policy.sgml'
>> --- debian/python-policy.sgml2015-02-27 23:09:27 +
>> +++ debian/python-policy.sgml2015-07-06 19:58:13 +
>> @@ -513,7 +513,9 @@
>>to use this prefix for all packages with public modules as they may
>>be used by other packages in the future.  Python 3 modules must be
>>in a separate binary package prefixed with python3- to
>> -  preserve run time separation between python and python3.
>> +  preserve run time separation between python and python3.  When the
>> +  source package only produces python module binary packages, it must
>> +  also be prefixed with python-.
>>  
>>The binary package for module foo should preferably be named
>>python-foo, if the module name
>> 
>
>Thanks,
>Guillem
>

Bug#1026200: Please package LilyPond 2.24.0 if possible

2023-01-28 Thread Anthony Fok

Hi Jonas,

On Wed, Jan 25, 2023 at 2:44 PM Jonas Hahnfeld  wrote:
> Thanks for pushing to get guile-2.2 back into Debian and LilyPond
> 2.24.0 packaged for Debian Bookworm, much appreciated. Regarding
> maintenance of Guile 2.2, we are probably in this together since our
> official binaries use it as well...

Many thanks to Rob Browning for his blessings, and to the Debian FTP
Masters for asking me for more details, and let guile-2.2 back into
Debian 12 bookworm.

And thank you for offering to help with Guile 2.2 maintenance just in
case any problem arises!  I really hope LilyPond 2.26.0 and the rest
of the ecosystem (e.g. on Windows platform) will be ready for Guile
3.0 really soon.

And... lilypond 2.24.0-1 has entered Debian!  Though I already found a
bug when upgrading lilypond-doc due to /usr/share/info/lilypond
symlink conflict, my own fault for not testing it thoroughly enough
before upload.  Thanks to excellent commit messages in LilyPond, by
Kevin Barry in this case, I was able to find out the problem and fix
it in a jiffy: we had been running (in debian/rules) both "$(MAKE)
install-doc" and "$(MAKE) install-info", not knowing that it is not
only an unnecessary duplication, but also install-info's behaviour
changed.  Building 2.24.0-2 now, and keeping my fingers crossed.  :-)

> Another question for planning would be regarding Debian's freeze: What
> would be the last date that you could possibly pick up a bug fix
> release 2.24.1 of LilyPond? There are no concrete plans yet, but if you
> say that it is possible and somehow fits the schedule, we might go for
> it.

Great question!  I'm not entirely sure!
You likely know about about freeze schedule from

https://release.debian.org/bookworm/freeze_policy.html

but how it would exactly happen is a bit hard to say; there is always
uncertainty, but here is my interpretation:

According to that page, since the Soft Freeze starts on 2023-02-12,
I would say having 2.24.1 released before 2023-02-05 would be the
safest bet, giving me a day or two of leeway to get it built, tested
and uploaded, and then 5 days for migration to testing/bookworm before
2023-02-12.  Though maybe if I were to set "urgency=high" in
debian/changelog, the delay is supposedly reduced to 2 days, so
perhaps 2023-02-08?

That said, since 2023-02-12 is a "Soft Freeze", bug fix releases can
still go after 2023-02-12, though the delay to testing migration
becomes 10 days regardless of the urgency setting, so perhaps
2023-02-28 is the absolute latest for a bug fix release to make it
into bookworm before the 2023-03-12 Hard Freeze?

That said, bug fixes after 2023-03-12 is still possible (with a
minimum 20-day delay for migration to bookworm), but the lilypond
Debian package currently does not have any autopkgtest yet, so that
would require a manual review and unblock from the Release Managers.
I suppose I could try to add an autopkgtest for LilyPond by trying to
run "make test" but hopefully using the existing /usr/bin/lilypond
binary instead of recompiling the whole thing from source?  (Though
that's a possibility too...)  That might remove the need for manual
review.  I'm not sure.

Failing that, there will be "bookworm-backports" after the Debian 12
is released where we could backport future bug fixes.  Something like
that?

Thank you so much for your work on LilyPond!  It's always exciting to
have a new release as an end user, and it is amazing the amount of
dedication and great work that you and the rest of the LilyPond
development team put into such a complicated yet immensely useful
piece of software.  Kudos to you all!

Cheers,

Anthony

Bug#960993: Intent to NMU ocsinventory-agent to fix longstanding l10n bugs

2023-01-28 Thread gregor herrmann

On Sat, 28 Jan 2023 20:33:58 +0100, Helge Kreutzmann wrote:

> I intend to NMU ocsinventory-agent around 2023-02-14 to fix a 
> longstanding l10n bug[1]. The changelog would be something like the following:
> 
>  ocsinventory-agent (2:2.10.0-2.1) unstable; urgency=medium
>  .
>* Non-maintainer upload.
>* Update debconf template translation
>  - Spanish translation.
>Thanks to Camaleón (Closes: #960993)
> 
> Please tell me if you are currently preparing a new release yourself
> and would like me to skip the NMU.

I'm a bit confused about the state of the Spanish translation:
- There is #960993 still open, as you noticed;
- On the the other hand, there is the update in the newer #1003642
  which was included in 2:2.10.0-1

My guess is that #960993 is not relevant anymore and should be
closed, as it it was superceded by #1003642 which is already
apllied/closed.

But I might be missing something …


Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: Leonard Cohen: Traveling Light


signature.asc
Description: Digital Signature

Bug#791635: python-policy: Please require namespacing source python module packages

2023-01-28 Thread Guillem Jover

Control: reopen -1
Control: reassign -1 python3

[ Sorry, resending, as the bug was archived so it ignored all the
  control commands. ]

This got closed due to the python-defaults package being removed from
sid, reopening and reassigning where python-policy seems to be located
now.

On Tue, 2022-12-27 at 23:29:30 +, Debian Bug Tracking System wrote:
> Date: Tue, 7 Jul 2015 03:11:06 +0200
> From: Guillem Jover 
> To: sub...@bugs.debian.org
> Subject: python-policy: Please require namespacing source python module
>  packages
> Message-ID: <20150707011106.ga12...@gaara.hadrons.org>
> User-Agent: Mutt/1.5.23 (2014-03-12)
> X-Spam-Status: No, score=-6.6 required=4.0 tests=BAYES_00,FROMDEVELOPER,
>  RCVD_IN_DNSWL_MED,RP_MATCHES_RCVD autolearn=ham autolearn_force=no
>  version=3.4.0-bugs.debian.org_2005_01_02
> 
> Source: python-defaults
> Source-Version: 2.7.9-1
> Severity: wishlist
> 
> Hi!
> 
> Given recent ITP discussions [0] about lack of namespacing on python
> module source package names, I think it would be really good to fix
> this at the source, by mandating it in the python-policy. Attached is
> a proposal wording.
> 
>   [0] #748383: ITP: bash8; #745347: ITP: releases; #790399: ITP: structlog
> 
> Thanks,
> Guillem

> === modified file 'debian/python-policy.sgml'
> --- debian/python-policy.sgml 2015-02-27 23:09:27 +
> +++ debian/python-policy.sgml 2015-07-06 19:58:13 +
> @@ -513,7 +513,9 @@
> to use this prefix for all packages with public modules as they may
> be used by other packages in the future.  Python 3 modules must be
> in a separate binary package prefixed with python3- to
> -   preserve run time separation between python and python3.
> +   preserve run time separation between python and python3.  When the
> +   source package only produces python module binary packages, it must
> +   also be prefixed with python-.
>  
> The binary package for module foo should preferably be named
> python-foo, if the module name
> 

Thanks,
Guillem

Bug#1028841: gopacket: FTBFS with libpcap >= 1.10.2

2023-01-28 Thread Mathias Gibbens

Control: retitle -1 gopacket: FTBFS with libpcap >= 1.10.2
Control: tags -1 + confirmed
Control: forwarded -1 https://github.com/google/gopacket/issues/1088

  It appears that libpcap 1.10.2 introduced some change that is causing
the test failure. Manually downgrading to libpcap 1.10.1-4 from
snapshot.d.o allows the build to succeed. I've opened an issue with the
upstream project, as I don't possess the knowledge to properly fix
this.

Mathias


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

Bug#1029907: ITP: xdg-terminal-exec -- user default terminal execution utility

2023-01-28 Thread Jeremy Bicha

On Sat, Jan 28, 2023 at 7:18 PM Simon McVittie  wrote:
> I think a better route might be to get it into experimental for now, then
> when it seems like it has stabilized more, put it into unstable/trixie
> and potentially also bookworm-backports.

It's in the NEW queue targeted for experimental now.

The only place it's been packaged so far is the Arch Linux AUR:
https://repology.org/project/xdg-terminal-exec/versions

Thank you,
Jeremy Bicha

Bug#1029805: Cannot look-up eln file as no source file was found for

2023-01-28 Thread Dan Jacobson


I have no idea.
Please reassign it.
Thanks.

---


On 2023-01-29 05:17, Sven Joachim wrote:

On 2023-01-28 07:24 -0400, David Bremner wrote:


Dan Jacobson  writes:


Package: dh-elpa-helper
Version: 2.0.16
Severity: minor

I saw this:
Warning (comp): Cannot look-up eln file as no source file was found 
for

/usr/share/emacs/site-lisp/elpa/csv-mode-1.20/csv-mode.elc


Why do you think this is a bug in dh-elpa-helper?


It surely looks more like a bug in Emacs to me, but with Dan's usual
terseness it is hard to tell.  So, Dan:

- Does /usr/share/emacs/site-lisp/elpa/csv-mode-1.20/csv-mode.elc 
exist?

- Which version of elpa-csv-mode do you have installed, if any?

Cheers,
   Sven

Bug#1029923: gstreamer1.0-plugins-good: trying to overwrite libgstxingmux.so, which is also in package gstreamer1.0-plugins-ugly

2023-01-28 Thread Simon McVittie

Package: gstreamer1.0-plugins-good
Version: 1.22.0-3
Severity: serious
Justification: Policy 7.6.1

> Unpacking gstreamer1.0-plugins-good:amd64 (1.22.0-3) over (1.20.5-2) ...
> dpkg: error processing archive 
> /tmp/apt-dpkg-install-qofiMB/43-gstreamer1.0-plugins-good_1.22.0-3_amd64.deb 
> (--unpack):
>  trying to overwrite 
> '/usr/lib/x86_64-linux-gnu/gstreamer-1.0/libgstxingmux.so', which is also in 
> package gstreamer1.0-plugins-ugly:amd64 1.20.5-1

Presumably gstreamer1.0-plugins-good needs a versioned Breaks/Replaces
on gstreamer1.0-plugins-ugly (<< 1.22~) or similar?

smcv

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-security'), (500, 
'oldstable-debug'), (500, 'oldoldstable'), (500, 'buildd-unstable'), (500, 
'unstable'), (500, 'testing'), (500, 'stable'), (500, 'oldstable'), (1, 
'experimental-debug'), (1, 'buildd-experimental'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages gstreamer1.0-plugins-good depends on:
ii  gstreamer1.0-plugins-base 1.22.0-2
ii  libaa11.4p5-50
ii  libavc1394-0  0.5.4-5
ii  libbz2-1.01.0.8-5+b1
ii  libc6 2.36-8
ii  libcaca0  0.99.beta20-3
ii  libcairo-gobject2 1.16.0-7
ii  libcairo2 1.16.0-7
ii  libdv41.0.0-15
ii  libflac12 1.4.2+ds-2
ii  libgcc-s1 12.2.0-14
ii  libgdk-pixbuf-2.0-0   2.42.10+dfsg-1+b1
ii  libglib2.0-0  2.74.5-1
ii  libgstreamer-plugins-base1.0-01.22.0-2
ii  libgstreamer1.0-0 1.22.0-2
ii  libgudev-1.0-0237-2
ii  libiec61883-0 1.2.0-6
ii  libjack-jackd2-0 [libjack-0.125]  1.9.21~dfsg-2
ii  libjpeg62-turbo   1:2.1.2-1+b1
ii  libmp3lame0   3.100-6
ii  libmpg123-0   1.31.2-1
ii  liborc-0.4-0  1:0.4.33-2
ii  libpng16-16   1.6.39-2
ii  libpulse0 16.1+dfsg1-2+b1
ii  libraw1394-11 2.1.2-2
ii  libshout3 2.4.6-1+b1
ii  libsoup-3.0-0 3.2.2-1
ii  libsoup2.4-1  2.74.3-1
ii  libspeex1 1.2.1-1
ii  libstdc++612.2.0-14
ii  libtag1v5 1.13-1
ii  libtwolame0   0.4.0-2
ii  libv4l-0  1.22.1-5+b1
ii  libvpx7   1.12.0-1
ii  libwavpack1   5.6.0-1
ii  libx11-6  2:1.8.3-3
ii  libxdamage1   1:1.1.6-1
ii  libxext6  2:1.3.4-1+b1
ii  libxfixes31:6.0.0-2
ii  zlib1g1:1.2.13.dfsg-1

Versions of packages gstreamer1.0-plugins-good recommends:
ii  gstreamer1.0-x  1.22.0-2

gstreamer1.0-plugins-good suggests no packages.

-- no debconf information

Bug#1029922: apt-setup: remove duplicate, commented-out cdrom entries

Package: apt-setup
Severity: normal

After a regular installation from netinst, sources.list usually looks
like this:

# deb cdrom:[Debian GNU/Linux 12.0.0 _Sid_ - Unofficial amd64 NETINST with 
firmware 20230128-23:05]/ sid local main non-free non-free-firmware

#deb cdrom:[Debian GNU/Linux 12.0.0 _Sid_ - Unofficial amd64 NETINST with 
firmware 20230128-23:05]/ sid local main non-free non-free-firmware

deb http://deb.debian.org/debian/ sid main non-free-firmware
deb-src http://deb.debian.org/debian/ sid main non-free-firmware

# This system was installed using small removable media
# (e.g. netinst, live or single CD). The matching "deb cdrom"
# entries were disabled at the end of the installation process.
# For information about how to configure apt package sources,
# see the sources.list(5) manual.

It feels weird to have the commented out cdrom: entries twice, and I'm
tempted to remove one of those.

The first one comes from apt-setup's generators/01setup which retains
existing entries in sources.list, but commented out. The relevant code
has been around since forever (it was already present before the split
from svn), but I don't understand what purpose it serves, and I'm
inclined to just remove this. If the previous entries are useful, the
existing file can be saved elsewhere.

# add old file as comments
sed 's/^/# /' < $ROOT/etc/apt/sources.list | sed 's/^# # */# /' > $file


The second one is due to the finish-install hook that disables cdrom
entries in certain conditions, which also adds the informative text
at the bottom. That can be kept as is.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)<https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant

Bug#1029921: shaarli: Unable to fetch thumbnails, mkdir(): Permission denied

2023-01-28 Thread James Valleroy

Package: shaarli
Version: 0.12.1+dfsg-7
Severity: normal
X-Debbugs-Cc: jvalle...@mailbox.org

This issue was first opened at upstream issue tracker, but it only applies to 
the Debian package:

https://github.com/shaarli/Shaarli/issues/1911

It was also reported as an issue in FreedomBox:

https://salsa.debian.org/freedombox-team/freedombox/-/issues/2299

With debugging enabled, the error is shown in the Apache journal:

"GET /shaarli/admin/thumbnails HTTP/2.0" 200 2571 
"https://localhost:4430/shaarli/admin/configure;
[proxy_fcgi:error] [pid 17352:tid 17399] [client 10.0.2.2:38818] AH01071: Got 
error 'PHP message: ErrorException: mkdir(): Permission denied', referer 
https://localhost:4430/shaarli/admin/thumbnails

Shaarli uses php-arthurhoaro-web-thumbnailer, with the configuration in 
/usr/share/shaarli/inc/web-thumbnailer.json.
This has the cache path set to "cache/", so it is trying to create a folder 
"cache" in /usr/share/shaarli.

Here are some things I tried, in order to fix it:

# ln -s /var/cache/shaarli/cache/ /usr/share/shaarli/cache

Then in the journal I see:

"GET /shaarli/admin/thumbnails HTTP/2.0" 200 2571 
"https://localhost:4430/shaarli/admin/configure;
"PATCH /shaarli/admin/shaare/0/update-thumbnail HTTP/2.0" 200 1698 
"https://localhost:4430/shaarli/admin/thumbnails;
[core:alert] [pid 17352:tid 17399] [client 10.0.2.2:46634] 
/usr/share/shaarli/cache/thumb/.htaccess: Require not allowed here, referer 
https://localhost:4430/shaarli/admin/thumbnails
"GET 
/shaarli/cache/thumb/14dd5266c70789bdc806364df4586335/7fb845c39d194747d128e9e70664a2ca05d881ae125901.jpg
 HTTP/2.0" 500 743 "https://localhost:4430/shaarli/admin/thumbnails;

I tried deleting .htaccess, but it gets re-written each time.

What I can do instead, it remove all the contents of .htaccess, and then the 
thumbnails are working ok.
Next step: I will check if I can do this in the package build.

Bug#1029907: ITP: xdg-terminal-exec -- user default terminal execution utility

2023-01-28 Thread Simon McVittie

On Sat, 28 Jan 2023 at 16:41:28 -0500, Jeremy Bicha wrote:
> This solves a problem: currently you can use update-alternatives to
> choose a default terminal for a Debian system, but what happens when
> you have multiple users on the same Debian system with different
> preferences?

Another problem that it solves is that when there has been no sysadmin
configuration, the ideal default terminal is desktop-dependent, in order
to coordinate with the desktop environment's design and conventions.
If a GNOME user and a KDE/Plasma user share a desktop computer, and they
both launch a terminal app like mutt, the expected result in the absence
of any other configuration is that the GNOME user gets mutt displayed in
a gnome-terminal or maybe gnome-console window, while the KDE user gets
mutt displayed in a Konsole window. There is currently no possible target
for the x-terminal-emulator symlink that will give both users the expected
behaviour: one of them has to get the "wrong" terminal by default.

(I know Jeremy knows this, but other -devel readers might not be aware.)

If xdg-terminal-exec becomes the de facto standard in future, then we
can probably make it a high-priority alternative for x-terminal-emulator
(directly if it's command-line compatible, or via a script if it isn't).

> I don't think the "proposed specification" has been fully drafted yet.
> There is some discussion at
> https://gitlab.freedesktop.org/xdg/xdg-specs/-/issues/54
> and over the years in the xdg mailing list.

I haven't reviewed xdg-terminal-exec in detail, but at a high level it
seems a lot more promising than making terminals a special case of a
generic "intents" mechanism (which is a broad and vague topic which will
likely take a correspondingly long time to standardize), or standardizing
a D-Bus interface for terminals (which, as much as I like D-Bus as an
implementation for things like o.fd.Application, is not something that
the likes of xterm are ever likely to implement).

However, the fact that the spec hasn't been standardized or even
fully drafted makes me want to avoid adding xdg-terminal-exec to
unstable/bookworm at this late stage of the release cycle: if it gets
through NEW fast enough to be in bookworm and then the spec changes
incompatibly, we'll be stuck with an implementation of the old version
of the spec in Debian 12 for 3 years (+ LTS), which would be really
annoying for cross-distro compatibility, both for us and for upstream.

I think a better route might be to get it into experimental for now, then
when it seems like it has stabilized more, put it into unstable/trixie
and potentially also bookworm-backports.

> More recently, the alpha for glib 2.76 (part of GNOME 44 Alpha) now
> supports xdg-terminal-exec
...
> We might backport the glib feature to Debian
> Bookworm, but it is quite late in Bookworm's release process.

I would be more positive about backporting this change before bookworm
than I am about adding xdg-terminal-exec, because the GLib change is just
that *if* xdg-terminal-exec is found in PATH, then GLib checks for it
in preference to all the other terminals it knows about. If x-t-e is not
found in PATH, then the GLib change has no benefit but also does no harm.

(It also reshuffles the code around terminal selection in a way that
allows more terminals to be added to the list as a 1-line change, which
is a nice side benefit, and in particular would let us fall back to
x-terminal-emulator without causing a huge diffstat and semi-frequent
patch conflicts.)

> and GNOME Terminal 3.46.7 includes the necessary metadata file
...
> The metadata would also need to be added to other terminal emulator
> apps

This part is just the addition of X-ExecArg to the .desktop file, and
a symlink to it in /usr/share/xdg-terminals/, yes? If that's the case
then having this metadata in gnome-terminal and other terminal emulators
seems uncontroversial - it's potentially helpful and unlikely to cause
regressions or incompatibilities.

A summary for those who have not looked into this: X-ExecArg tells
xdg-terminal-exec how to invoke a terminal to run a specific command,
like the "-e" of "xterm -e vi ~/myfile". It's -e for any terminal that
can implement the Debian-specific x-terminal-emulator interface directly,
but some terminal implementations need a different argument like "--"
or no argument at all.

The semantics of running a terminal with its X-ExecArg are similar to
Debian Policy's x-terminal-emulator -e (option parsing stops after that
argument, and arguments are placed directly into an argv without word
splitting or a shell), which seems like the right design. The main reason
why X-ExecArg needs to be per-terminal metadata is that some terminal
emulators historically implemented "-e" as behaving more like "sh -c",
which is not compatible with the desired semantics, but cannot be changed
without a compat/API break (which terminal emulator authors are typically
unwilling to do) or a wrapper script. Using "--" as the

Bug#1029920: mention APT::Clean-Installed on autoclean part of man page

2023-01-28 Thread Dan Jacobson

Package: aptitude
Version: 0.8.13-5

autoclean is great, but it would be nice if there could be an optional
way to not have it delete .debs of installed versions.

Yes, most old .debs we don't want anymore,
except if that is the version we actually have installed.

I don't want to throw away a working .deb, and keep a non working .deb,
even if the latter is the current version upstream.

I just want to keep these
aptitude --disable-columns -F %p\ %v search ~U\|~o

out of the
aptitude -s autoclean list.

Wait, on man apt-get the autoclean section mentions APT::Clean-Installed
but that is missing from the corresponding man aptitude section, even
though it works the same way.

Therefore please simply also mention it on man aptitude, to save
users hours.

rgrep  Clean-I -l /usr/share/doc/aptitude/html/en/ finds none there, but
it is right on the apt-get man page, meaning it is important.

Bug#1028081: argus-server: Produces corrupted argus.out file

2023-01-28 Thread Marco d'Itri

Control: severity -1 grave

On Jan 06, Andrea Galli  wrote:

>To solve the issue I had to rebuild the debian package from source
> removing the default gcc -O2 optimization -- stripping it from CFLAGS and
> CXXFLAGS.
Building with -fno-strict-aliasing fixes this.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#1029917: r-cran-pbkrtest: Depends: r-cran-lme4 (>= 1.1.31) but it is not going to be installed

2023-01-28 Thread Dirk Eddelbuettel



On 29 January 2023 at 01:58, Adrian Bunk wrote:
| Package: r-cran-pbkrtest
| Version: 0.5.2-1
| Severity: serious
| 
| The following packages have unmet dependencies:
|  r-cran-pbkrtest : Depends: r-cran-lme4 (>= 1.1.31) but it is not going to be 
installed
|
| You might want to reconsider
| 
|* debian/patches/series: Disable no longer required lme4 version patch

Indeed. I read the upstream DESCRIPTION file the wrong way, the issue is
*still* not fixed upstream.  Sighs.

Will fix. Thanks for the heads up!

Dirk

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

Bug#1029641: tagging 1029641

On Sun, Jan 29, 2023 at 12:41:48AM +0100, Axel Beckert wrote:
> # https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1029633#10
> tags 1029641 + moreinfo
> thanks

What info is missing here for also covering the packages that are not 
already covered by built-using-field-on-arch-all-package because they 
are not listing Built-Using in debian/control?

The rationale from tags/b/built-using-field-on-arch-all-package.tag also 
applies to these packages.

cu
Adrian

Bug#1029918: spring needs hinting into testing

Package: release.debian.org
Severity: normal

Issues preventing migration:
∙ ∙ spring-javaai/arm64 has unsatisfiable dependency

Package: spring-javaai
Architecture: all
Depends:
...
 spring (>= ${source:Version}),

Package: spring
Architecture: amd64 i386

The package was removed from testing in October due to an RC bug
that is now fixed.

#563686 explains why this package is x86-only.

Bug#1029917: r-cran-pbkrtest: Depends: r-cran-lme4 (>= 1.1.31) but it is not going to be installed

Package: r-cran-pbkrtest
Version: 0.5.2-1
Severity: serious

The following packages have unmet dependencies:
 r-cran-pbkrtest : Depends: r-cran-lme4 (>= 1.1.31) but it is not going to be 
installed


You might want to reconsider

   * debian/patches/series: Disable no longer required lme4 version patch

Bug#1029916: q2-phylogeny/i386: Depends: python3-skbio but it is not installable

Package: q2-phylogeny
Version: 2022.11.1-2
Severity: serious

The following packages have unmet dependencies:
 q2-phylogeny : Depends: python3-skbio but it is not installable


python-skbio does FTBFS on 32bit.

Bug#1021739: nekohtml: CVE-2022-24839

2023-01-28 Thread tony mancill

On Sat, Jan 28, 2023 at 11:35:30PM +0100, David Prévot wrote:
> Hi,
> 
> Le Thu, Oct 13, 2022 at 09:17:02PM +0200, Moritz Mühlenhoff a écrit :
> > Source: nekohtml
> […]
> > The following vulnerability was published for nekohtml.
> > 
> > CVE-2022-24839[0]:
> 
> I prepared an upload (new upstream release) of this package in order to
> fix this RC-bug as part of the BSP currently happening in St-Cergue,
> Switzerland. A merge request has been submitted.
> 
> https://salsa.debian.org/java-team/nekohtml/-/merge_requests/1
> 
> Unless advised otherwise, I intend to upload the updated package
> tomorrow.

Please go ahead with the upload.

Thank you!


signature.asc
Description: PGP signature

Bug#1029915: mikutter: Depends: ruby-gtk3 (>= 3.4.9) but it is not going to be installed

Package: mikutter
Version: 5.0.4+dfsg1-1
Severity: serious

The following packages have unmet dependencies:
 mikutter : Depends: ruby-gtk3 (>= 3.4.9) but it is not going to be installed

Bug#1029831: debian-policy: Make required packages build-essential

2023-01-28 Thread Guillem Jover

On Sat, 2023-01-28 at 14:07:06 +0100, Ansgar wrote:
> Timo Röhling writes:
> > * Andreas Henriksson  [2023-01-28 12:50]:
> >>Policy is not a religion. Policy has many bugs. Policy is very outdated.
> >>[...]
> >>Here's an example you could follow:
> >>https://lists.debian.org/debian-policy/2022/12/msg00023.html
> > Your argument cuts both ways. Right now, Policy says that
> > the bugs are RC, and if you believe that should be different, why
> > don't you propose such a change and seek consensus yourself?
> 
> I don't think it does.  Policy doesn't specify what packages actually
> are build-essential; it only refers to an "informational list" in
> Section 4.2.

It does, but in a way that does not require encoding package names in
policy to leave breathing room to toolchain maintainers.

Policy says this:

  ,---
  It is not necessary to explicitly specify build-time relationships on
  a minimal set of packages that are always needed to compile, link and
  put in a Debian package a standard “Hello World!” program written in C
  or C++. The required packages are called *build-essential*, and an
  informational list can be found in "/usr/share/doc/build-
  essential/list" (which is contained in the "build-essential" package).
  [1]
  `---

With that footnote explaining the rationale:

  ,---
  [1] Rationale:

* This allows maintaining the list separately from the policy
  documents (the list does not need the kind of control that the
  policy documents do).

* Having a separate package allows one to install the build-
  essential packages on a machine, as well as allowing other
  packages such as tasks to require installation of the build-
  essential packages using the depends relation.

* The separate package allows bug reports against the list to be
  categorized separately from the policy management process in the
  BTS.
  `---

And further down it says this:

  ,---
  If build-time dependencies are specified, it must be possible to build
  the package and produce working binaries on a system with only
  essential and build-essential packages installed and also those
  required to satisfy the build-time relationships (including any
  implied relationships). […]
  `---

> I think discussion in #1027832 suggested that required packages should
> be build-essential as well. Maybe this should be made explicit, for
> example by changing
> 
> +---
> | The required packages are called build-essential, and an informational
> | list can be found in /usr/share/doc/build-essential/list (which is
> | contained in the build-essential package).
> +---[ Section 4.2 ]
> 
> to something like
> 
> +---
> | The required packages are called build-essential, and include packages
> | with Priority "required" and additional packages. An informational
> | list of additional packages can be found in
> | /usr/share/doc/build-essential/list (which is contained in the
> | build-essential package).
> +---
> 
> This only documents existing practice as practically all systems have
> required packages installed.

If the point of this proposal is to include tzdata by proxy, then that
makes no sense, because tzdata does not have the properties to keep
being a "required" package. And if Priority "required" packages are
a way to denote the pseudo-essential set via priorities (even though we
do not even mark depended libraries as such anymore, so it's at most a
subset) instead of the Essential:yes field and dependencies of those,
then this is already covered by the "essential" mention above.

So adding this would only confuse things more than help anything. And
would be only a definition hack to preserve tzdata in that set only
temporarily anyway.

Guillem

Bug#1029914: libmail-dmarc-perl FTBFS due to missing build (and runtime?) dependencies

Source: libmail-dmarc-perl
Version: 1.20211209-2
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/fetch.php?pkg=libmail-dmarc-perl=all=1.20211209-2=1674928751=0

...
   dh_auto_test -i
/usr/bin/perl Build test --verbose 1
Can't locate Config/Tiny.pm in @INC (you may need to install the Config::Tiny 
module) (@INC contains: lib /tmp/3SPCAxt2ay /<>/blib/lib 
/<>/blib/arch /etc/perl 
/usr/local/lib/x86_64-linux-gnu/perl/5.36.0 /usr/local/share/perl/5.36.0 
/usr/lib/x86_64-linux-gnu/perl5/5.36 /usr/share/perl5 
/usr/lib/x86_64-linux-gnu/perl-base /usr/lib/x86_64-linux-gnu/perl/5.36 
/usr/share/perl/5.36 /usr/local/lib/site_perl .) at lib/Mail/DMARC/Base.pm line 
8.
BEGIN failed--compilation aborted at lib/Mail/DMARC/Base.pm line 8.
Compilation failed in require at /usr/lib/x86_64-linux-gnu/perl-base/parent.pm 
line 16.
BEGIN failed--compilation aborted at lib/Mail/DMARC.pm line 10.
Compilation failed in require at /usr/lib/x86_64-linux-gnu/perl-base/parent.pm 
line 16.
BEGIN failed--compilation aborted at t/00.Dmarc.t line 343.
t/00.Dmarc.t . 
Dubious, test returned 2 (wstat 512, 0x200)
No subtests run 

#   Failed test 'use Mail::DMARC::Policy;'
#   at t/01.Policy.t line 10.
# Tried to use 'Mail::DMARC::Policy'.
# Error:  Can't locate URI.pm in @INC (you may need to install the URI 
module) (@INC contains: lib /<>/blib/lib 
/<>/blib/arch /etc/perl 
/usr/local/lib/x86_64-linux-gnu/perl/5.36.0 /usr/local/share/perl/5.36.0 
/usr/lib/x86_64-linux-gnu/perl5/5.36 /usr/share/perl5 
/usr/lib/x86_64-linux-gnu/perl-base /usr/lib/x86_64-linux-gnu/perl/5.36 
/usr/share/perl/5.36 /usr/local/lib/site_perl .) at 
lib/Mail/DMARC/Report/URI.pm line 8.
# BEGIN failed--compilation aborted at lib/Mail/DMARC/Report/URI.pm line 8.
# Compilation failed in require at lib/Mail/DMARC/Policy.pm line 9.
# BEGIN failed--compilation aborted at lib/Mail/DMARC/Policy.pm line 9.
# Compilation failed in require at t/01.Policy.t line 10.
# BEGIN failed--compilation aborted at t/01.Policy.t line 10.
Can't locate object method "new" via package "Mail::DMARC::Policy" at 
t/01.Policy.t line 12.
# Tests were run but no plan was declared and done_testing() was not seen.
# Looks like your test exited with 2 just after 1.
t/01.Policy.t  
not ok 1 - use Mail::DMARC::Policy;
Dubious, test returned 2 (wstat 512, 0x200)
Failed 1/1 subtests
...
Test Summary Report
---
t/00.Dmarc.t   (Wstat: 512 (exited 2) Tests: 0 
Failed: 0)
  Non-zero exit status: 2
  Parse errors: No plan found in TAP output
t/01.Policy.t  (Wstat: 512 (exited 2) Tests: 1 
Failed: 1)
  Failed test:  1
  Non-zero exit status: 2
  Parse errors: No plan found in TAP output
t/03.Base.t(Wstat: 65280 (exited 255) Tests: 1 
Failed: 1)
  Failed test:  1
  Non-zero exit status: 255
  Parse errors: No plan found in TAP output
t/04.PurePerl.t(Wstat: 512 (exited 2) Tests: 0 
Failed: 0)
  Non-zero exit status: 2
  Parse errors: No plan found in TAP output
t/06.Result.t  (Wstat: 65280 (exited 255) Tests: 2 
Failed: 1)
  Failed test:  1
  Non-zero exit status: 255
  Parse errors: No plan found in TAP output
t/10.Report.t  (Wstat: 512 (exited 2) Tests: 1 
Failed: 1)
  Failed test:  1
  Non-zero exit status: 2
  Parse errors: No plan found in TAP output
t/11.Report.Store.t(Wstat: 512 (exited 2) Tests: 1 
Failed: 1)
  Failed test:  1
  Non-zero exit status: 2
  Parse errors: No plan found in TAP output
t/12.Report.Store.SQL.t(Wstat: 512 (exited 2) Tests: 0 
Failed: 0)
  Non-zero exit status: 2
  Parse errors: No plan found in TAP output
t/13.Report.Aggregate.t(Wstat: 512 (exited 2) Tests: 0 
Failed: 0)
  Non-zero exit status: 2
  Parse errors: No plan found in TAP output
t/14.Report.Aggregate.Metadata.t   (Wstat: 512 (exited 2) Tests: 1 
Failed: 1)
  Failed test:  1
  Non-zero exit status: 2
  Parse errors: No plan found in TAP output
t/15.Report.Aggregate.Record.t (Wstat: 65280 (exited 255) Tests: 1 
Failed: 1)
  Failed test:  1
  Non-zero exit status: 255
  Parse errors: No plan found in TAP output
t/16.Report.Aggregate.Record.Auth_Results.t (Wstat: 65280 (exited 255) Tests: 3 
Failed: 1)
  Failed test:  1
  Non-zero exit status: 255
  Parse errors: No plan found in TAP output
t/17.Report.Aggregate.Schema.t (Wstat: 512 (exited 2) Tests: 0 
Failed: 0)
  Non-zero exit status: 2
  Parse errors: No plan found in TAP output
t/20.Report.URI.t  (Wstat: 65280 (exited 255) Tests: 1 
Failed: 1)
  Failed test:  1
  Non-zero exit status: 255
  Parse errors: No plan found in TAP output
t/21.Report.Send.t (Wstat: 65280 (exited 255) Tests: 1 
Failed: 1)
  Failed test:  1
  Non-zero exit status: 255

Bug#1029913: texlive-pictures: /usr/share/texlive/texmf-dist/scripts/epspdf/epspdf.tlu: /tmp write vulnerability

2023-01-28 Thread Frank Heckenbach

Package: texlive-pictures
Version: 2020.20210202-3
Severity: grave
File: /usr/share/texlive/texmf-dist/scripts/epspdf/epspdf.tlu

Classic /tmp write vulnerability: function dir_writable writes to
"/tmp/1" (and if this fails, "/tmp/2" etc.) without sufficient
checks.

Harmless demonstration:

% mkfifo /tmp/1
% epspdf /etc/hostname /dev/null # any non-empty input file will do

hangs indefinitely trying to write to the pipe (as can be seen using
strace).

That's already a bug (and incidentally the one that actually
happened to me), but it seems it can be turned into an exploit using
a symlink. Though on my system this seems to be mitigated due to
this kernel patch:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=30aba6656f61ed44cba445a3c0d38b296fa9e8f5

But on systems where the patch is not installed or not active, it
would be possible to get any other user, possibly root, that runs
this program to write "test" to a new file of the attacker's choice.
I don't know how to turn this into a more serious privilege
escalation, but that's just my lack of fanatsy and knowledge of e.g.
every possible file and subdirectory under /etc. In any case,
writing such a file is already transgressing privileges.

To avoid this, as usual for this kind of exploit, files written
under publicly writable directories such as /tmp must be opened with
O_CREAT|O_EXCL (whatever the equivalent in texlua is, if any), or a
subdirectory must be created since mkdir will fail if the target
exists already, even as a dangling symlink.

Bug#1029912: kati: Depends: golang-glog (= 0.0~git20160126.23def4e-5) but it is not installable

Package: kati
Version: 10.0.0+r32+git20220314.09dfa26c4e59-6
Severity: serious

The following packages have unmet dependencies:
 kati : Depends: golang-glog (= 0.0~git20160126.23def4e-5) but it is not 
installable


Depends is the wrong place for ${misc:Built-Using}.

Bug#1029911: rust-ureq FTBFS: error: unable to load build system class 'cargo': Can't locate String/ShellQuote.pm

Source: rust-ureq
Version: 2.6.2-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/fetch.php?pkg=rust-ureq=all=2.6.2-1=1674929287=0

...
dh clean --buildsystem cargo
   dh_auto_clean -O--buildsystem=cargo
dh_auto_clean: error: unable to load build system class 'cargo': Can't locate 
String/ShellQuote.pm in @INC (you may need to install the String::ShellQuote 
module) (@INC contains: /<>/debian/dh-cargo/lib /etc/perl 
/usr/local/lib/x86_64-linux-gnu/perl/5.36.0 /usr/local/share/perl/5.36.0 
/usr/lib/x86_64-linux-gnu/perl5/5.36 /usr/share/perl5 
/usr/lib/x86_64-linux-gnu/perl-base /usr/lib/x86_64-linux-gnu/perl/5.36 
/usr/share/perl/5.36 /usr/local/lib/site_perl) at 
/<>/debian/dh-cargo/lib/Debian/Debhelper/Buildsystem/cargo.pm line 
37.
BEGIN failed--compilation aborted at 
/<>/debian/dh-cargo/lib/Debian/Debhelper/Buildsystem/cargo.pm line 
37.
Compilation failed in require at (eval 3) line 1.
BEGIN failed--compilation aborted at (eval 3) line 1.

make: *** [debian/rules:15: clean] Error 25

Bug#995514: ping

2023-01-28 Thread Alexandre Detiste

still ITA, waiting for my DD procedure


pgpUXh9pwl3Di.pgp
Description: OpenPGP digital signature

Bug#1029910: python3-django-hyperkitty: Threading not working properly

2023-01-28 Thread Peter Chubb

Package: python3-django-hyperkitty
Version: 1.3.6-1
Severity: normal

Dear Maintainer,

In our mailman3+hyperkitty instance, at https://lists.sel4.systems/
archived threads don't seem to have the connections needed to see 
an enitre thread.

So visiting https://lists.sel4.systems/hyperkitty/list/devel@sel4.systems/ 
shows no recent threads (there have neen some!)

visiting 
https://lists.sel4.systems/hyperkitty/list/devel@sel4.systems/thread/4N2QCZBPB4CD6WAACHT6U3LM3BYGMECO/
 shows only the first message in a thread.

I'm pretty sure this used to work before the last mailman3+hyperkitty upgrade.

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

Kernel: Linux 6.1.0-1-cloud-amd64 (SMP w/1 CPU thread; PREEMPT)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.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 python3-django-hyperkitty depends on:
ii  fonts-glyphicons-halflings   1.009~3.4.1+dfsg-3
ii  libjs-bootstrap4 4.6.1+dfsg1-4
ii  libjs-sphinxdoc  5.3.0-2
ii  python3  3.11.1-1
ii  python3-dateutil 2.8.2-1
ii  python3-django   3:3.2.16-1
ii  python3-django-compressor2.4.1-2
ii  python3-django-extensions3.2.1-2
ii  python3-django-gravatar2 1.4.4-4
ii  python3-django-haystack  3.2.1-1
ii  python3-django-mailman3  1.3.8-1
ii  python3-django-q 1.3.9-4
ii  python3-djangorestframework  3.14.0-1
ii  python3-elasticsearch7.17.6-1
ii  python3-flufl.lock   5.0.1-4
ii  python3-mailmanclient3.3.3-1
ii  python3-mistune  2.0.4-1
ii  python3-networkx 2.8.8-1
ii  python3-robot-detection  0.4.0-3
ii  python3-tz   2022.7-1

Versions of packages python3-django-hyperkitty recommends:
ii  mailman3-web  0+20200530-2.1

python3-django-hyperkitty suggests no packages.

-- no debconf information

Bug#1026568: python-distutils-extra: FTBFS: AssertionError: "diff -x foo.pot -x '*.pyc' -Nur /tmp/tmp[1578 chars]n+\n" != ''

2023-01-28 Thread Didier 'OdyX' Raboud

Control: tags -1 +confirmed +help

Hello there from the St-Cergue BSP where I've taken a look at this RC bug.

I can confirm this still FTBFS, and doesn't in stable, so let's check why.

The crux of the issue is that python3-setuptools from 54.0.0
(https://setuptools.pypa.io/en/latest/history.html#v54-0-0) does _not_ build 
the .egg-info as single file, but _only_ as directory [0].

This has the direct consequence that all tests fail for either of these 
reasons:
* the .egg-info is not a file, and cannot be compared with the expected 
version
* the .egg-info directory is not cleaned in clean() , hence the snapshot-vs-
result directory comparison is always going to flag the .egg-info directory as 
resulting cruft.

I've trimmed down the report below with an example result, which clearly shows 
the above two things.

Btw, from the FTBFS build directory, the fastest way to reproduce this is to 
run:

 LC_ALL=C LANGUAGE= LANG=C PYTHONPATH=. python3.10 test/auto.py -v -k empty -f


So. python-distutils-extra is broken by src:setuptools which is not going to 
revert this. python3-distutils-extra has 34 reverse Build-Depends, including 
python-apt, which makes it a "key package". Even if the B-D from python-apt 
can be amended, I also identify unattended-upgrades, software-properties and 
command-not-found. It looks like this won't be easy to remove from testing; we 
need to fix it.

Suggestions on the angle to use to tackle this welcome!

Best,

OdyX


[0] Also, distutils is deprecated "soon", so all this should get nuked post-
bookworm, but that's a discussion for another time.

Le mardi, 20 décembre 2022, 18.23:15 h CET Lucas Nussbaum a écrit :
> Source: python-distutils-extra
> Version: 2.47
> Severity: serious
> Justification: FTBFS
> Tags: bookworm sid ftbfs
> User: lu...@debian.org
> Usertags: ftbfs-20221220 ftbfs-bookworm
> 
> Hi,
> 
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
> 
> Relevant part (hopefully):
> > make[1]: Entering directory '/<>'
> > # run tests with all supported python 2 and 3 versions
> > set -e; for python in `py3versions -s`; do \
> > 
> >   echo "-- Running tests with $python "; \
> >   LC_ALL=C LANGUAGE= LANG=C PYTHONPATH=. $python test/auto.py -v; \
> > 
> > done
> > -- Running tests with python3.11 
> > (...)
> > test_empty (__main__.T.test_empty)
> > empty source tree (just setup.py) ... FAIL
> > test_empty (__main__.T.test_empty)
> > empty source tree (just setup.py) ... FAIL

(...)

> > ==
> > FAIL: test_empty (__main__.T.test_empty)
> > empty source tree (just setup.py)
> > --
> > 
> > Traceback (most recent call last):
> >   File "/<>/test/auto.py", line 68, in test_empty
> >   
> > self.assertEqual(len(f), 1)
> > 
> > AssertionError: 4 != 1
> > 
> > ==
> > FAIL: test_empty (__main__.T.test_empty)
> > empty source tree (just setup.py)
> > --
> > 
> > Traceback (most recent call last):
> >   File "/<>/test/auto.py", line 43, in tearDown
> >   
> > self.assertEqual(cruft, '', 'no cruft after cleaning:\n' + cruft)
> > 
> > AssertionError: "diff -x foo.pot -x '*.pyc' -Nur /tmp/tmp[1578 chars]n+\n"
> > != '' - diff -x foo.pot -x '*.pyc' -Nur
> > /tmp/tmp56zs21t4/s/foo.egg-info/PKG-INFO
> > /tmp/tmp15hh51oe/foo.egg-info/PKG-INFO - ---
> > /tmp/tmp56zs21t4/s/foo.egg-info/PKG-INFO1970-01-01 
00:00:00.0
> > + - +++ /tmp/tmp15hh51oe/foo.egg-info/PKG-INFO  2022-12-20
> > 09:38:33.086490908 + - @@ -0,0 +1,8 @@
> > - +Metadata-Version: 2.1
> > - +Name: foo
> > - +Version: 0.1
> > - +Summary: Test suite package
> > - +Home-page: https://foo.example.com
> > - +Author: Martin Pitt
> > - +Author-email: martin.p...@example.com
> > - +License: GPL v2 or later
> > - diff -x foo.pot -x '*.pyc' -Nur
> > /tmp/tmp56zs21t4/s/foo.egg-info/SOURCES.txt
> > /tmp/tmp15hh51oe/foo.egg-info/SOURCES.txt - ---
> > /tmp/tmp56zs21t4/s/foo.egg-info/SOURCES.txt 1970-01-01 
00:00:00.0
> > + - +++ /tmp/tmp15hh51oe/foo.egg-info/SOURCES.txt   2022-12-20
> > 09:38:33.090490943 + - @@ -0,0 +1,5 @@
> > - +setup.py
> > - +foo.egg-info/PKG-INFO
> > - +foo.egg-info/SOURCES.txt
> > - +foo.egg-info/dependency_links.txt
> > - +foo.egg-info/top_level.txt
> > - \ No newline at end of file
> > - diff -x foo.pot -x '*.pyc' -Nur
> > /tmp/tmp56zs21t4/s/foo.egg-info/dependency_links.txt
> > /tmp/tmp15hh51oe/foo.egg-info/dependency_links.txt - ---
> > /tmp/tmp56zs21t4/s/foo.egg-info/dependency_links.txt1970-01-01
> > 00:00:00.0 + - +++
> > /tmp/tmp15hh51oe/foo.egg-info/dependency_links.txt  2022-12-20
> > 09:38:33.086490908 + - @@ -0,0 +1 @@
> > - +
> > - diff -x foo.pot -x '*.pyc' -Nur
> >

Bug#1021739: nekohtml: CVE-2022-24839

2023-01-28 Thread David Prévot

Hi,

Le Thu, Oct 13, 2022 at 09:17:02PM +0200, Moritz Mühlenhoff a écrit :
> Source: nekohtml
[…]
> The following vulnerability was published for nekohtml.
> 
> CVE-2022-24839[0]:

I prepared an upload (new upstream release) of this package in order to
fix this RC-bug as part of the BSP currently happening in St-Cergue,
Switzerland. A merge request has been submitted.

https://salsa.debian.org/java-team/nekohtml/-/merge_requests/1

Unless advised otherwise, I intend to upload the updated package
tomorrow.

Regards

taffit


signature.asc
Description: PGP signature

Bug#1029566: transition: shibboleth-sp

control: tags -1 moreinfo

On 2023-01-24 17:17:36 +0100, Ferenc Wágner wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> Dear Release Team,
> 
> When reporting #1028286 (transition: xml-security-c) I totally missed
> that one of the mentioned planned upper layer uploads is the
> shibboleth-sp 3.3 -> 3.4 upgrade, which, contrary to the xml-security-c
> transition, actually entails an SONAME change.  Since this wasn't
> explicit in the original bug, we decided to ask for your ACK again.
> As you can see in the autogenerated tracker at
> https://release.debian.org/transitions/html/auto-shibboleth-sp.html,
> there are only two reverse dependencies, both of which are internal to
> the Shibboleth ecosystem (thus maintained by us) and both build without
> changes against shibboleth-sp 3.4.1+dfsg-1.

What would be the consequences of postponing this transition to trixie?

Cheers

> 
> Ben file:
> 
> title = "shibboleth-sp";
> is_affected = .depends ~ "libshibsp10" | .depends ~ "libshibsp11";
> is_good = .depends ~ "libshibsp11";
> is_bad = .depends ~ "libshibsp10";
> 

-- 
Sebastian Ramacher

Bug#1017573: patch Re: ulmo broken by pandas 1.4+

2023-01-28 Thread Rebecca N. Palmer


Control: tags -1 patch
Control: unblock -1 by 1011225
(Block possibly added by mistake - these don't look related.)

This patch is now available as a Salsa merge request, and passed 
build+autopkgtest there.

Bug#1028374: libjna-java: JNA HelloWorld fails on aarch64

2023-01-28 Thread Alexandre Rossi

Hi,

> The update looks good to me and a rebuild of rdeps with ratt was
> successful.  Or more precisely, was successful for the packages that
> also build against 5.12.1.  So I have just uploaded to the archive.

Thanks a lot but looks like the fix was not complete.

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

Can you upload a version with the fix available in the bug report?

Do not hesitate if you need some help to prepare the upload.

Thanks a lot,

Alex

Bug#1029909: RFS: dmagnetic/0.36-1 -- Interpreter to play textadventures from Magnetic Scrolls in glorious ANSI Art

2023-01-28 Thread Thomas Dettbarn


Package: sponsorship-requests
Severity: normal

Dear mentors,

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

* Package name : dmagnetic
Version : 0.36-1
Upstream contact : Thomas Dettbarn 
* URL : https://www.dettus.net/dMagnetic/
* License : BSD-2-Clause
* Vcs : [fill in URL of packaging vcs]
Section : games

The source builds the following binary packages:

dmagnetic - Interpreter to play textadventures from Magnetic Scrolls in 
glorious ANSI Art


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


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

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

dget -x 
https://mentors.debian.net/debian/pool/main/d/dmagnetic/dmagnetic_0.36-1.dsc


Changes since the last upload:

dmagnetic (0.36-1) unstable; urgency=medium
.
* Minor bugfixes
* Backend engine can be encapsulated in a library
* HelloWorld example for interested frontend developers

Regards,
Thomas Dettbarn

P.S.: I am still looking for a sponsor for my other project "d11amp", 
the oldskool mp3 player...

Bug#663436: modprobe: does not seem to set module options for snd_hda_intel

2023-01-28 Thread Marco d'Itri

Do you have any feedback?
Can you still reproduce this on a modern system?

On Sep 17, Marco d'Itri  wrote:

> On May 02, Martin Steigerwald  wrote:
> 
> > Sorry. Still happens:
> Are you really sure that snd_hda_intel is loaded in the initramfs?
> In a normal configuration it would not be available there.
> 
> I did some tests with a different module which is available in the 
> initramfs and I am still unable to reproduce this:
> 
> #!/bin/bash
> kver=3.16-1-amd64
> opts+=(-m 256M)
> opts+=(-curses)
> opts+=(-kernel /boot/vmlinuz-$kver -initrd /boot/initrd.img-$kver \
>-append 'break=top')
> kvm "${opts[@]}"
> 
> Then at the console:
> /lib/systemd/systemd-udevd &
> echo 'options e1000 copybreak=16' > /etc/modprobe.d/test.conf
> echo add > /sys/devices/pci:00/:00:03.0/uevent
> cat /sys/module/e1000/parameters/copybreak
> 
> -- 
> ciao,
> Marco



-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#1028029: xscreensaver: contains non-free fonts

2023-01-28 Thread Jamie Zawinski

On Jan 6, 2023, at 1:50 AM, Bastian Germann  wrote:
> 
> But there is a version available at 
> https://sourceforge.net/projects/ocr-a-font/ that might be free.
> You can certainly replace it.

This one seems better than that one: https://tsukurimashou.osdn.jp/ocr.php.en

Annoyingly, the name changes from "OCR A Std" to "OCR A".

Bug#1011413: inn2: nnrpd as distributed does not support $modify_headers, recompiled does

2023-01-28 Thread Marco d'Itri

On May 24, Marco d'Itri  wrote:

> > Package: inn2
> > Version: 2.6.3-1+deb10u2
> Sorry, I have no plans to spend time debugging oldstable but please let 
> me know if this affects stable too.
Can you reproduce this on a modern system?

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#1029908: libjna-java: JNA HelloWorld fails on armhf

2023-01-28 Thread Alexandre Rossi

Package: libjna-java
Version: 5.13.0-1
Severity: normal
Tags: patch

Dear Maintainer,

When trying the JNA tutorial Helloworld on aarch64, it fails with the following
error message:

autopkgtest [12:34:07]: test helloworld: [---
Jan 28, 2023 12:34:09 PM com.sun.jna.Native loadNativeDispatchLibrary
INFO: Looking in /usr/lib/jni/libjnidispatch.system.so
Jan 28, 2023 12:34:09 PM com.sun.jna.Native loadNativeDispatchLibrary
INFO: Looking in /usr/lib/arm-linux-gnueabi/jni/libjnidispatch.system.so
Jan 28, 2023 12:34:09 PM com.sun.jna.Native extractFromResourcePath
INFO: Looking in classpath from 
jdk.internal.loader.ClassLoaders$AppClassLoader@19e0bfd for 
/com/sun/jna/linux-arm/libjnidispatch.so
Exception in thread "main" java.lang.UnsatisfiedLinkError: Native library 
(com/sun/jna/linux-arm/libjnidispatch.so) not found in resource path 
(debian/tests:/usr/share/java/jna.jar)
at 
com.sun.jna.Native.loadNativeDispatchLibraryFromClasspath(Native.java:1062)
at com.sun.jna.Native.loadNativeDispatchLibrary(Native.java:1018)
at com.sun.jna.Native.(Native.java:221)
at HelloWorld$CLibrary.(HelloWorld.java:8)
at HelloWorld.main(HelloWorld.java:14)
autopkgtest [12:34:09]: test helloworld: ---]

I succesfully tested a fix.

https://salsa.debian.org/niol/libjna-java/-/commit/c69675faa352652e95439f528d6a3e1fda0d90ed

Feel free to come back to me for a ready to upload package.

Cheers,

Alex

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

Kernel: Linux 6.1.0-2-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libjna-java depends on:
ii  libjna-jni  5.13.0-1

libjna-java recommends no packages.

libjna-java suggests no packages.

-- no debconf information

Bug#1029505: python3-minimal installs recommend package python3

2023-01-28 Thread Stefano Rivera

Tag: -1 + moreinfo unreproducible

Hi Ricardo (2023.01.23_09:39:34_-0400)
> # apt install python3-minimal
> Reading package lists... Done
> Building dependency tree... Done
> Reading state information... Done
> The following additional packages will be installed:
>   libmpdec3 libpython3.10-minimal libpython3.10-stdlib media-types python3.10 
> python3.10-minimal
> Suggested packages:
>   python3.10-venv python3.10-doc binfmt-support
> The following NEW packages will be installed:
>   libmpdec3 libpython3.10-minimal libpython3.10-stdlib media-types 
> python3-minimal python3.10 python3.10-minimal
> 0 upgraded, 7 newly installed, 0 to remove and 5 not upgraded.
> Need to get 5076 kB of archives.
> After this operation, 20.4 MB of additional disk space will be used.
> Do you want to continue? [Y/n] 

In a minimal chroot, I get:

# apt install python3-minimal
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following packages will be upgraded:
  python3-minimal
1 upgraded, 0 newly installed, 0 to remove and 18 not upgraded.
Need to get 25.7 kB of archives.
After this operation, 0 B of additional disk space will be used.
Get:1 http://deb.debian.org/debian unstable/main amd64 python3-minimal amd64 
3.11.1-2 [25.7 kB]
Fetched 25.7 kB in 0s (2065 kB/s)
debconf: delaying package configuration, since apt-utils is not installed
(Reading database ... 12792 files and directories currently installed.)
Preparing to unpack .../python3-minimal_3.11.1-2_amd64.deb ...
Unpacking python3-minimal (3.11.1-2) over (3.11.1-1) ...
Setting up python3-minimal (3.11.1-2) ...
root@first-ghost:~# dpkg -l python3.11
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name   Version  Architecture Description
+++-==---=
un  python3.11   (no description available)

You sure you don't have something else installed that's bringing it in?

SR

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

Bug#1028602: transition: gnustep-base, gnustep-gui

Control: tags -1 moreinfo

On 2023-01-13 15:15:10 +0200, Yavor Doganov wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> X-Debbugs-Cc: pkg-gnustep-maintain...@lists.alioth.debian.org
> Control: affects -1 + src:gnustep-base src:gnustep-gui
> 
> Dear Release team,
> 
> We would like your permission to carry out a GNUstep transition (two
> libraries simultaneously with one round of binNMUs):
> 
>   libgnustep-base1.28 -> 1.29
>   libgnustep-gui0.29  -> 0.30
> 
> I realise we are already late and in all likelihood we've missed the
> last bookworm train, which is rather unpleasant for us and GNUstep
> users but entirely our fault.

I am not quite sure what you mean with unpleasant. What would be
unpleasant for GNUstep users?

Cheers

> In case it's not possible to do it now
> (after tiff/poppler) then please have us in mind for the early stages
> of the trixie development cycle.
> 
> gnustep-base/1.29.0-1 is available in experimental, not yet built on
> mipsen, ppc64el and s390x.  But note that 1.28.1-2 was built in
> unstable on all release architectures; 1.29.0 is essentially the same
> except the version bump (the damage done was corrected; see #1028189).
> 
> gnustep-gui/0.30.0-1 is also available in experimental, not yet built
> on ppc64el and s390x but I do not expect any problems there.
> 
> While build-testing all rdeps on amd64, the following problems were
> observed:
> 
> agenda.app   #1028185  gnustep-gui bug, will be fixed with next upload
> gnustep-dl2  #1028577  fixed locally; needs a sourceful upload
> pantomime#1028578  likewise
> sope #1028579  patch sent to the BTS; needs a sourceful upload
> 
> In addition, gnustep-back will require a sourceful upload (that is
> always the case).
> 
> The automatic ben trackers at release.d.o look fine.
> 

-- 
Sebastian Ramacher

Bug#1029907: ITP: xdg-terminal-exec -- user default terminal execution utility

2023-01-28 Thread Jeremy Bicha

Package: wnpp
Severity: wishlist
Owner: jeremy.bi...@canonical.com
X-Debbugs-CC: debian-de...@lists.debian.org

Package Name: xdg-terminal-exec
Version: git snapshot
Upstream Author: Vladimir Kudrya
License: GPL-3+
Programming Lang: Shell

Description: user default terminal execution utility
 xdg-terminal-exec is an implementation of a proposed freedesktop.org
 specification for launching a user's default terminal app.

Other Info
--
I will maintain this with the Debian freedesktop.org team. Packaging is at
https://salsa.debian.org/freedesktop-team/xdg-terminal-exec

This solves a problem: currently you can use update-alternatives to
choose a default terminal for a Debian system, but what happens when
you have multiple users on the same Debian system with different
preferences?

I don't think the "proposed specification" has been fully drafted yet.
There is some discussion at
https://gitlab.freedesktop.org/xdg/xdg-specs/-/issues/54
and over the years in the xdg mailing list.

More recently, the alpha for glib 2.76 (part of GNOME 44 Alpha) now
supports xdg-terminal -exec and GNOME Terminal 3.46.7 includes the
necessary metadata file. We might backport the glib feature to Debian
Bookworm, but it is quite late in Bookworm's release process.

The metadata would also need to be added to other terminal emulator
apps and desktops that use glib would need to ship a metadata file
with their preferred terminal emulators.

There is no GUI way for users to override the preference; they would
need to add/edit the config file in their home directory manually.

More details in the README at https://github.com/Vladimir-csp/xdg-terminal-exec

Thanks,
Jeremy Bicha

Bug#1029906: mdevctl: Build depends on cruft package about to be removed: librust-log+serde-dev

2023-01-28 Thread Scott Kitterman

Package: mdevctl
Version: 1.2.0-3
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

librust-log+serde-dev is NBS cruft that is about to be removed, which
will cause the package to FTBFS.

Scott K

Bug#1027382: Please, minimize your build chroots

On 2023-01-28 20:44:50 +0100, Sebastian Ramacher wrote:
> On 2023-01-28 15:03:04 +0200, Adrian Bunk wrote:
> > On Sat, Jan 28, 2023 at 12:24:47PM +0100, Santiago Vila wrote:
> > >...
> > > * Those bugs are RC by definition and have been for a long time.
> > >...
> > 
> > Please provide a pointer where a release team member has said so 
> > explicitly in recent years.
> > 
> > In my experience they are usually saying that FTBFS that do not happen 
> > on the buildds of release architectures are usually not RC.
> 
> Indeed. We require that packages are buildable on the buildds. If they
> don't and they built before, they are RC buggy. For all other FTBFS
> bugs, please use severity important at most.

I am reminded that there are of course more nuances to this. But in my
opinion it's a reasonable default. For a counter example consider
packages that access the network during build (and FTBFS in a
environment without network access). They are considered to be RC buggy
even if the builds succeed on the buildds. So, if in doubt, please
contact the release team.

My personal opinion on the tzdata topic is that we are wasting developer
time with this academic issue. Currently tzdata is effectively
build-essential due to the setup of our buildds. As I see no efforts on
the debootstrap/buildd admin side to change the current situation, the
time wasted here could be better spent on fixing some of the 300ish RC
bugs that are currently affecting bookworm.

Cheers
-- 
Sebastian Ramacher

Bug#1012864: graphviz: new upstream version 2.44.0 is available

2023-01-28 Thread Antoine Beaupré

Control: retitle -1 

On 2022-06-15 22:01:54, Martin-Éric Racine wrote:
> Package: graphviz
> Version: 2.42.2-5
> Severity: important
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> A new upstream version 2.44.0 is available, you should consider packaging it.
>
> - -- System Information:
> Debian Release: 11.3
>   APT prefers stable-updates
>   APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
> 'stable-debug'), (500, 'stable')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 5.10.0-15-amd64 (SMP w/4 CPU threads)
> Locale: LANG=fi_FI.utf8, LC_CTYPE=fi_FI.utf8 (charmap=UTF-8), LANGUAGE=fi:en
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages graphviz depends on:
> ii  libann01.1.2+doc-7
> ii  libc6  2.31-13+deb11u3
> ii  libcdt52.42.2-5
> ii  libcgraph6 2.42.2-5
> ii  libexpat1  2.2.10-2+deb11u3
> ii  libgcc-s1  10.2.1-6
> ii  libgd3 2.3.0-2
> ii  libglib2.0-0   2.66.8-1
> ii  libgts-0.7-5   0.7.6+darcs121130-4+b1
> ii  libgvc62.42.2-5
> ii  libgvpr2   2.42.2-5
> ii  liblab-gamut1  2.42.2-5
> ii  libstdc++6 10.2.1-6
> ii  libx11-6   2:1.7.2-1
> ii  libxaw72:1.0.13-1.1
> ii  libxmu62:1.1.2-2+b3
> ii  libxt6 1:1.2.0-1
>
> Versions of packages graphviz recommends:
> pn  fonts-liberation  
>
> Versions of packages graphviz suggests:
> pn  graphviz-doc  
> ii  gsfonts   1:8.11+urwcyr1.0.7~pre44-4.5
>
> - -- no debconf information
>
> -BEGIN PGP SIGNATURE-
>
> iQIzBAEBCgAdFiEEyJACx3qL7GpObXOQrh+Cd8S017YFAmKqLKIACgkQrh+Cd8S0
> 17Z0fA//XMpYiZBvlcSm9KpO2W9TSpQ/DEcGdWX/A8ktrkejKX6YlP8Oy7OgMu+z
> 2ohHjnrEOoyqosfVgPeFF7Eb9x0+qtRx4FrPd4ET8d8jOVPdbgQbX+Vp8V+Wwon3
> 5FLiTimJy0uOqffP9L8r5PJyuiKogwaDNMasq9jXInavi0El/s8Q2teAuTNyDxMF
> aVA5oe8Uf7levIkgKOkO2A2+oEAr//plKcqKYwVJCCtj/ihdxxF6QswzlZTZfwDG
> 9IQcYbeIyckzI6u9R9AD32ADZdppdJPPzk3ReQb90At5l5qEZOhVOPkMAu8vD+aZ
> 1m1QdhMcxMMK8TT6bv1Fw1xRwBsKZlwxOfUJZp6gwcZu6saH4Dd/6YwwaL5X4Jjl
> zxpfHUVooID2ps0By7WfTs/ycgwjc+oeOs+caKkO6qIGQNmx3l+vut65sHFVJ1Kn
> V+PBJdIn0QKsNep8HAMmGG68BSkY6F7oySrN33S4+16Ww1kZRBQ+B0dGT+l+N7Op
> 9gLDIpAzFkIq3RVBqd9de0MG8ZAdVDfnoEDW/RgJVFFR4KQvxH5Ma8VC+ZUJOVEQ
> bSVuYPktFY3JRtz71gOIiy5K++bDHwXI5cIsuSRsLaGdOjjsZdtdscKqy/hFq3op
> 8z6pF7sy9RztzgpOh+4xoQdk3HoFNyCL20LIVRtNE5PtbCk7Ugg=
> =yzkX
> -END PGP SIGNATURE-

-- 
Isn't man but a blossom taken by the wind, and only the mountains and
the sea and the stars and this Land of the Gods real and everlasting?
   - James Clavell, Shōgun

Bug#1012864: graphviz: new upstream version 2.44.0 is available

2023-01-28 Thread Antoine Beaupré

Control: retitle -1 graphviz: new upstream version 7.0.0 is available

Hi!

It seems that this bug report is not quite up to date. According to the
upstream changelog I could find, 7.0.0 has been out since January:

https://gitlab.com/graphviz/graphviz/-/blob/main/CHANGELOG.md

In fact, even when this bug was filed in June, they were already at
4.0.0, so I'm a little confused as to why version 2.44.0, released in
2020-04-08, was documneted as a "new upstream version" in the original
bug.

Are we all looking at the same upstream here? :)

A.
-- 
Be yourself. Everyone else is already taken!
- Oscar Wilde

Bug#1029905: pushpin: Build depends on cruft packages to be removed: librust-clap+default-dev

2023-01-28 Thread Scott Kitterman

Package: pushpin
Version: 1.35.0-2
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

librust-clap+default-dev is cruft that is about to be removed makine the
package unbuildable.

Scott K

Bug#1029805: Cannot look-up eln file as no source file was found for

2023-01-28 Thread Sven Joachim

On 2023-01-28 07:24 -0400, David Bremner wrote:

> Dan Jacobson  writes:
>
>> Package: dh-elpa-helper
>> Version: 2.0.16
>> Severity: minor
>>
>> I saw this:
>> Warning (comp): Cannot look-up eln file as no source file was found for
>> /usr/share/emacs/site-lisp/elpa/csv-mode-1.20/csv-mode.elc
>
> Why do you think this is a bug in dh-elpa-helper?

It surely looks more like a bug in Emacs to me, but with Dan's usual
terseness it is hard to tell.  So, Dan:

- Does /usr/share/emacs/site-lisp/elpa/csv-mode-1.20/csv-mode.elc exist?
- Which version of elpa-csv-mode do you have installed, if any?

Cheers,
   Sven

Bug#1029843:

2023-01-28 Thread Alexander Dalm

instead of the overlapping there could simply be an issue with the parsing
of the "brcmfmac43340.To be filled by O.E.M.txt" file at the first space
character so a .To is file requested.
"To be filled by O.E.M." is the Manufacturer Name and "Z83" the Product
Name stored in my BIOS, there are some other files for devices like
brcmfmac43340.meegopad-t08.txt in the package firmware-brcm80211, I simply
renamed this file without any problems. Ubuntu, Linux Mint and Manjaro
require even the .bin file in Manufacturer-Vendor format. Not mentioning
the compressed .bin.xz and .txt.xz files with Kernel 6 in Arch Linux and
RebornOS.

Bug#1028638: libproxy1v5: Gajim 1.6.0-1 crashes in libproxy call

2023-01-28 Thread Didier 'OdyX' Raboud

Le vendredi, 27 janvier 2023, 17.50:40 h CET Martin a écrit :
> Control: tags -1 + patch
> 
> So far only good reports about the patch by Sebastian ,
> applied in experimental.

From the St-Cergue BSP; could confirm that the crash is fixed by installing 
libproxy1v5 from experimental. Looking forward to getting this fixed in 
unstable!

Best,
OdyX

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

Bug#1012841: [DSE-Dev] Bug#1012841: patch welcome

2023-01-28 Thread Christian Göttsche

control: tags -1 patch

Patches attached.

Included a bunch of modernizations; the ones critical for the
autopkgtest are 0013-Fix-brctl-patch-to-pass-neverallow-check.patch
and 0014-Add-autopkgtest-Closes-1012841.patch.
From 909f9bb0da70dcb219d42c126e426554342d87f1 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Christian=20G=C3=B6ttsche?= 
Date: Mon, 19 Sep 2022 21:09:00 +0200
Subject: [PATCH 02/14] Drop unused script

---
 debian/gen-deps.sh | 19 ---
 1 file changed, 19 deletions(-)
 delete mode 100755 debian/gen-deps.sh

diff --git a/debian/gen-deps.sh b/debian/gen-deps.sh
deleted file mode 100755
index f6ee0f1..000
--- a/debian/gen-deps.sh
+++ /dev/null
@@ -1,19 +0,0 @@
-#!/bin/bash
-cd /usr/share/selinux/default || exit 1
-
-SEP="my %Deps = ("
-semodule_deps base.pp a*pp backup.pp b[i-z]*pp [c-z]*pp | while read INPUT ; do
-  echo $INPUT | grep -q ^module
-  if [ "$?" = "0" ]; then
-MODULE=$(echo $INPUT|sed -e s/^module..//)
-  else
-echo $INPUT | grep -q "no dependencies"
-if [ "$?" = "1" -a "$INPUT" != "}" ]; then
-  echo -n "$SEP"
-  SEP=", "
-  echo -n " '$MODULE' => '$INPUT'"
-fi
-  fi
-done
-
-echo " );"
-- 
2.39.1

From 77cbd1f0551f51e8b147678a1ca1bc16c2b25d79 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Christian=20G=C3=B6ttsche?= 
Date: Mon, 19 Sep 2022 21:08:03 +0200
Subject: [PATCH 01/14] Bump to debhelper compat level 13

dh_missing --fail-missing is now the default.
---
 debian/compat  | 1 -
 debian/control | 2 +-
 debian/rules   | 4 
 3 files changed, 1 insertion(+), 6 deletions(-)
 delete mode 100644 debian/compat

diff --git a/debian/compat b/debian/compat
deleted file mode 100644
index b4de394..000
--- a/debian/compat
+++ /dev/null
@@ -1 +0,0 @@
-11
diff --git a/debian/control b/debian/control
index a83806f..fea4187 100644
--- a/debian/control
+++ b/debian/control
@@ -7,7 +7,7 @@ Homepage: https://github.com/SELinuxProject/refpolicy/releases
 Maintainer: Debian SELinux maintainers 
 Uploaders: Russell Coker 
 Standards-Version: 4.4.0
-Build-Depends: debhelper (>= 11)
+Build-Depends: debhelper-compat (= 13)
 Build-Depends-Indep: bzip2,
  checkpolicy (>= 3.3),
  gawk,
diff --git a/debian/rules b/debian/rules
index 5b86e70..79c6ffd 100755
--- a/debian/rules
+++ b/debian/rules
@@ -22,10 +22,6 @@ endif
 
 override_dh_auto_configure: $(patsubst %, conf-%-policy, $(FLAVOURS)) conf-docs conf-src
 
-override_dh_install:
-	dh_install
-	dh_missing --fail-missing
-
 override_dh_fixperms:
 	dh_fixperms
 	chmod +x $(CURDIR)/debian/selinux-policy-dev/usr/share/selinux/devel/include/support/segenxml.py
-- 
2.39.1

From 0a2c8769286321752fd51705b0161e2052695e76 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Christian=20G=C3=B6ttsche?= 
Date: Mon, 19 Sep 2022 21:43:57 +0200
Subject: [PATCH 05/14] Drop unused remove statement

rm: cannot remove 'selinux-policy-src/support/pyplate.pyc': No such file or directory
---
 debian/rules | 1 -
 1 file changed, 1 deletion(-)

diff --git a/debian/rules b/debian/rules
index 5147deb..056042e 100755
--- a/debian/rules
+++ b/debian/rules
@@ -164,7 +164,6 @@ install-src: conf-src
 	 $(CURDIR)/debian/tmp/etc/selinux/default/src/policy/build.conf
 	(cd $(CURDIR)/debian/tmp/etc/selinux/default/src/; mv policy selinux-policy-src;   \
 	  rm -rf selinux-policy-src/support/__pycache__/; \
-	  rm selinux-policy-src/support/pyplate.pyc; \
 	  find selinux-policy-src -type f -print0 | xargs -0r chmod 0644; \
 	  find selinux-policy-src -type d -print0 | xargs -0r chmod 0755; \
 	  TZ=UTC tar -cf - --sort=name --mtime="$(BUILD_DATE)" selinux-policy-src | gzip -9n > $(CURDIR)/debian/tmp/usr/src/selinux-policy-src.tar.gz)
-- 
2.39.1

From ab1fb89f23db846d99d8cbd854742b64c376c14b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Christian=20G=C3=B6ttsche?= 
Date: Mon, 19 Sep 2022 21:43:19 +0200
Subject: [PATCH 04/14] Drop usage of GZIP environment variable

gzip: warning: GZIP environment variable is deprecated; use an alias or script
---
 debian/rules | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/rules b/debian/rules
index 79c6ffd..5147deb 100755
--- a/debian/rules
+++ b/debian/rules
@@ -167,6 +167,6 @@ install-src: conf-src
 	  rm selinux-policy-src/support/pyplate.pyc; \
 	  find selinux-policy-src -type f -print0 | xargs -0r chmod 0644; \
 	  find selinux-policy-src -type d -print0 | xargs -0r chmod 0755; \
-	  TZ=UTC GZIP="-9n" tar zfc $(CURDIR)/debian/tmp/usr/src/selinux-policy-src.tar.gz --sort=name --mtime="$(BUILD_DATE)" selinux-policy-src)
+	  TZ=UTC tar -cf - --sort=name --mtime="$(BUILD_DATE)" selinux-policy-src | gzip -9n > $(CURDIR)/debian/tmp/usr/src/selinux-policy-src.tar.gz)
 	rm -rf   $(CURDIR)/debian/tmp/etc/selinux/default/src/
 	touch $@
-- 
2.39.1

From e5cd5cc7fe77d14d5b326ec7972891ed504ffb60 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Christian=20G=C3=B6ttsche?= 
Date: Mon, 19 Sep 2022 21:14:32 +0200
Subject: [PATCH 03/14]

Bug#1025579: libvirt-dbus: dependency on transitional policykit-1 package

2023-01-28 Thread Simon McVittie

>  libvirt-dbus (1.4.1-3) unstable; urgency=medium
>  .
>[ Andrea Bolognani ]
> ...
>* [a352731] Drop polkit rules in legacy pkla format
>  - Makes it possible to not install / uninstall polkitd-pkla

The change is valid, but this reasoning for why it was done seems like
a misunderstanding.

You can stop installing downstream-only .pkla rules and depend on
polkitd (>= new version) if you want to, but if you do that, then the
justification is "so we can stop putting effort into them" rather than
"to make it possible to avoid polkitd-pkla".

As of Debian 12, all packages that ship custom polkit policies should
provide at least the JavaScript version of those policies. If desired,
they can also provide .pkla versions of the policies, but that doesn't
require a dependency on polkitd-pkla: if polkitd-pkla isn't installed,
then the .pkla version just won't be used (and the package will be
relying on the JavaScript rules instead).

flatpak is an example of a package that installs both JavaScript rules
(from upstream) and a rewrite of those rules into .pkla syntax (added by
the Debian maintainer). It Recommends polkitd | policykit-1 and has no
dependency relationship with polkitd-pkla, which I believe is correct.

As a result, to be able to remove polkitd-pkla, it's sufficient
for packages with dependencies on policykit-1 to replace them with
dependencies on polkitd and/or pkexec.

Thanks,
smcv

Bug#1029842: ITP: randombytes -- Library generating fresh randomness

2023-01-28 Thread Sam Hartman

> "Jan" == Jan Mojzis  writes:

* Package name: randombytes
  Version : 20230126
  Upstream Author : Daniel J. Bernstein
* URL : https://randombytes.cr.yp.to/
* License : Public domain

Public domain is problematic  as a license.
At least under US copyright law, there are very few circumstances when
something can actually be public domain.
One example is software written by US government employees.
But I don't think any of those circumstances apply to this library.
So I'm not sure the license is okay.

I'll  also admit to being skepticle of the utility of such a library
given the getrandom() API in libc.

Bug#1028556: xfe: root mode is unavailable (pkexec or su; sudo not configured)

2023-01-28 Thread Joachim Wiedorn

Hello Michael,

I have tested all three methods at Debian Testing/Bookworm. 

The results / answers you can find at
https://sourceforge.net/p/xfe/bugs/266/.

I think the mode with pkexec should be disabled again. But
'su' works for me. You can try the same command as in xfe
defined: 'su -c xfe' or 'su -c /usr/bin/xfe' in an extra
terminal.

Have a nice day.
Joachim (Germany)


pgpiiZRQg_sSt.pgp
Description: Digitale Signatur von OpenPGP

Bug#1029831: debian-policy: Make required packages build-essential

2023-01-28 Thread Sam Hartman

Ansgar> +--- | The required packages are called build-essential, and
Ansgar> an informational | list can be found in
Ansgar> /usr/share/doc/build-essential/list (which is | contained in
Ansgar> the build-essential package).  +---[ Section 4.2 ]

Ansgar> to something like

Ansgar> +--- | The required packages are called build-essential, and
Ansgar> include packages | with Priority "required" and additional
Ansgar> packages. An informational | list of additional packages can
Ansgar> be found in | /usr/share/doc/build-essential/list (which is
Ansgar> contained in the | build-essential package).  +---

Ansgar> This only documents existing practice as practically all
Ansgar> systems have required packages installed.

I support this change and would second if submitted as a patch.


signature.asc
Description: PGP signature

Bug#1029850: linux: Driver not loaded for ST Microelectronics LSM6DS3TR-C accelerometer (acpi:SMO8B30:SMO8B30:)

2023-01-28 Thread Salvatore Bonaccorso

Hi Darrell,

On Sat, Jan 28, 2023 at 08:13:16PM +, Darrell Kavanagh wrote:
> Package: src:linux
> Version: 6.1.4-1
> Severity: normal
> File: linux
> X-Debbugs-Cc: darrell.kavan...@gmail.com
> 
> Dear Maintainer,
> 
> This is a convertable touchscreen tablet/laptop. The rotation sensor device 
> ST Microelectronics LSM6DS3TR-C does not work. It is detected via ACPI and the
> sysfs trees are created at 
> devices/pci:00/:00:17.1/i2c_designware.3/i2c-4/i2c-SMO8B30:00
> and devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:3c/SMO8B30:00 with
> symlinks bus/acpi/devices/SMO8B30:00 and bus/i2c/devices/i2c-SMO8B30:00, but
> no driver is loaded.
> 
> The device is identifying itself to the kernel with PNP id SMO8B30:
> physical_node:
>   modalias=acpi:SMO8B30:SMO8B30:
>   name=SMO8B30:00
>   uevent=MODALIAS=acpi:SMO8B30:SMO8B30:
>   waiting_for_supplier=0
> firmware_node:
>   hid=SMO8B30
>   modalias=acpi:SMO8B30:SMO8B30:
>   path=\_SB_.PCI0.I2C5.DEV_
>   status=15
>   uevent=MODALIAS=acpi:SMO8B30:SMO8B30:
>   uid=0
> 
> The kernel module for the appropriate driver (st_lsm6dsx_i2c) is not loaded 
> on boot.
> Modprobing it does not associate it with the device, as I would expect as
> the module does not provide an alias for the above acpi/pnp id.

Can you report this issue upstream? Gues to reach out are according to
get_maintainers.pl script:

Lorenzo Bianconi  (maintainer:ST LSM6DSx IMU IIO DRIVER)
Jonathan Cameron  (maintainer:IIO SUBSYSTEM AND DRIVERS)
Lars-Peter Clausen  (reviewer:IIO SUBSYSTEM AND DRIVERS)
linux-...@vger.kernel.org (open list:ST LSM6DSx IMU IIO DRIVER)
linux-ker...@vger.kernel.org (open list)

Please keep us in the loop.

Regards,
Salvatore

Bug#1029852: bugs.debian.org: please add support for non-free-firmware

Package: bugs.debian.org
Severity: important
Tags: patch

Hi,

Please add support for non-free-firmware to debbugs; it looks like at
least build-versions-db needs to be told about it. Prospective patch
attached.

Also filed as:
  https://github.com/dondelelcaro/debbugs/issues/2


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

Bug#1029851: ruby-globalid: CVE-2023-22799

2023-01-28 Thread Salvatore Bonaccorso

Source: ruby-globalid
Version: 0.6.0-1
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for ruby-globalid.

CVE-2023-22799[0]:
| Possible ReDoS based DoS vulnerability in GlobalID

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-22799
https://www.cve.org/CVERecord?id=CVE-2023-22799
[1] 
https://discuss.rubyonrails.org/t/cve-2023-22799-possible-redos-based-dos-vulnerability-in-globalid/82127
[2] 
https://github.com/rails/globalid/commit/3bc4349422e60f2235876a59dd415e98b072eb2b

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1029850: linux: Driver not loaded for ST Microelectronics LSM6DS3TR-C accelerometer (acpi:SMO8B30:SMO8B30:)

2023-01-28 Thread Darrell Kavanagh

Package: src:linux
Version: 6.1.4-1
Severity: normal
File: linux
X-Debbugs-Cc: darrell.kavan...@gmail.com

Dear Maintainer,

This is a convertable touchscreen tablet/laptop. The rotation sensor device 
ST Microelectronics LSM6DS3TR-C does not work. It is detected via ACPI and the
sysfs trees are created at 
devices/pci:00/:00:17.1/i2c_designware.3/i2c-4/i2c-SMO8B30:00
and devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:3c/SMO8B30:00 with
symlinks bus/acpi/devices/SMO8B30:00 and bus/i2c/devices/i2c-SMO8B30:00, but
no driver is loaded.

The device is identifying itself to the kernel with PNP id SMO8B30:
physical_node:
modalias=acpi:SMO8B30:SMO8B30:
name=SMO8B30:00
uevent=MODALIAS=acpi:SMO8B30:SMO8B30:
waiting_for_supplier=0
firmware_node:
hid=SMO8B30
modalias=acpi:SMO8B30:SMO8B30:
path=\_SB_.PCI0.I2C5.DEV_
status=15
uevent=MODALIAS=acpi:SMO8B30:SMO8B30:
uid=0

The kernel module for the appropriate driver (st_lsm6dsx_i2c) is not loaded on 
boot.
Modprobing it does not associate it with the device, as I would expect as
the module does not provide an alias for the above acpi/pnp id.

Many thanks,
Darrell Kavanagh
  

-- Package-specific info:
** Version:
Linux version 6.1.0-1-amd64 (debian-ker...@lists.debian.org) (gcc-12 (Debian 
12.2.0-13) 12.2.0, GNU ld (GNU Binutils for Debian) 2.39.90.20221231) #1 SMP 
PREEMPT_DYNAMIC Debian 6.1.4-1 (2023-01-07)

** Command line:
BOOT_IMAGE=/vmlinuz-6.1.0-1-amd64 
root=UUID=e38347fa-efd3-4975-94cd-9aeb6ed38eb8 ro fbcon=rotate:1 
video=DSI-1:panel_orientation=right_side_up quiet splash

** Not tainted

** Kernel log:
[   12.229920] audit: type=1400 audit(1674932970.531:4): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="nvidia_modprobe" pid=532 
comm="apparmor_parser"
[   12.229929] audit: type=1400 audit(1674932970.531:5): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="nvidia_modprobe//kmod" 
pid=532 comm="apparmor_parser"
[   12.232240] audit: type=1400 audit(1674932970.535:6): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="lsb_release" pid=531 
comm="apparmor_parser"
[   12.233497] typec port0: bound usb1-port1 (ops connector_ops [usbcore])
[   12.233547] typec port0: bound usb2-port1 (ops connector_ops [usbcore])
[   12.268728] audit: type=1400 audit(1674932970.571:7): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="system_tor" pid=537 
comm="apparmor_parser"
[   12.301480] audit: type=1400 audit(1674932970.603:8): apparmor="STATUS" 
operation="profile_load" profile="unconfined" 
name="/usr/lib/NetworkManager/nm-dhcp-client.action" pid=536 
comm="apparmor_parser"
[   12.301489] audit: type=1400 audit(1674932970.603:9): apparmor="STATUS" 
operation="profile_load" profile="unconfined" 
name="/usr/lib/NetworkManager/nm-dhcp-helper" pid=536 comm="apparmor_parser"
[   12.301493] audit: type=1400 audit(1674932970.603:10): apparmor="STATUS" 
operation="profile_load" profile="unconfined" 
name="/usr/lib/connman/scripts/dhclient-script" pid=536 comm="apparmor_parser"
[   12.301496] audit: type=1400 audit(1674932970.603:11): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="/{,usr/}sbin/dhclient" 
pid=536 comm="apparmor_parser"
[   12.319768] audit: type=1400 audit(1674932970.623:12): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="torbrowser_tor" pid=547 
comm="apparmor_parser"
[   12.335725] audit: type=1400 audit(1674932970.639:13): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="torbrowser_firefox" pid=544 
comm="apparmor_parser"
[   13.086036] input: ACPI Virtual Keyboard Device as 
/devices/virtual/input/input21
[   13.293077] typec port1: bound usb1-port6 (ops connector_ops [usbcore])
[   13.293128] typec port1: bound usb2-port4 (ops connector_ops [usbcore])
[   13.696538] mc: Linux media interface: v0.10
[   13.721402] alg: No test for fips(ansi_cprng) (fips_ansi_cprng)
[   13.767319] videodev: Linux video capture interface: v2.00
[   13.786939] input: HAILUCK CO.,LTD Duet 3 USB Composite Device as 
/devices/pci:00/:00:15.0/usb1/1-5/1-5:1.0/0003:17EF:60FA.0002/input/input22
[   13.843001] usb 1-4: Found UVC 1.00 device Intergrated Camera 2M (0bda:5609)
[   13.845807] hid-generic 0003:17EF:60FA.0002: input,hidraw1: USB HID v1.11 
Keyboard [HAILUCK CO.,LTD Duet 3 USB Composite Device] on 
usb-:00:15.0-5/input0
[   13.867017] input: HAILUCK CO.,LTD Duet 3 USB Composite Device Consumer 
Control as 
/devices/pci:00/:00:15.0/usb1/1-5/1-5:1.1/0003:17EF:60FA.0003/input/input23
[   13.869744] input: Intergrated Camera 2M: Intergra as 
/devices/pci:00/:00:15.0/usb1/1-4/1-4:1.0/input/input27
[   13.923738] input: HAILUCK CO.,LTD Duet 3 USB Composite Device Mouse as 
/devices/pci:00/:00:15.0/usb1/1-5/1-5:1.1/0003:17EF:60FA.0003/input/input24
[   13.925252] input: HAILUCK CO.,LTD Duet 3 USB Composite

Bug#1029349: xz-utils: Please include da.po based on translation from manpages-l10n

2023-01-28 Thread Sebastian Andrzej Siewior

control: forwarded -1 https://translationproject.org/domain/xz.html

On 2023-01-21 16:36:30 [+0100], Helge Kreutzmann wrote:
> Please kindly include the attached da.po and forward it to upstream so
> that it is included there in future versions as well.

upstream (xz) does not accept any translations. They are handled via the
translationproject and you Cc:ed Joe Hansen. So I think that this can be
counted as forwarded upstream.

Thank you, I will probably prepare a new release including this
translation.

Sebastian

Bug#837385: Bug#934822: ath9k-htc free firmware still an issue in free software distributions

2023-01-28 Thread Holger Wansing

Hi,

Am 28. Januar 2023 17:27:28 MEZ schrieb Cyril Brulebois :
>Holger Wansing  (2023-01-28):
>> now that there's massive work on making non-free firmware to work easily
>> in debian-installer and the distribution, would it be possible, to bring
>> the topic of ath9k-htc free firmware forward?
>> 
>> There are some longstanding bugreports for this (and related, some in
>> CC); is there any chance to get this finally fixed for bookworm?
>> 
>> Wouldn't it be a shame, if non-free firmware works flawlessly, while
>> this free firmware still stays an issue?
>
>If you look around in hw-detect or debian-cd repositories, you'll see that
>I'm working on main & non-free & main-non-free-firmware, soon to become
>main & non-free-firmware (once the move is complete). I don't have such
>hardware to confirm what happens at runtime though.

I did not find any mention of ath9k-htc firmware
in the list of packages you identified for this apptoach,
which mad me ask for this.
Sorry for the noise


Holger



-- 
Sent from /e/ OS on Fairphone3

Bug#1023563: linux-image-5.10.0-19-amd64: Ephemeral ports are reused too quickly, even when net.ipv4.tcp_tw_reuse = 0

2023-01-28 Thread Markus Wernig


Dear maintainer

I just installed linux-image-5.10.0-21-amd64 (5.10.162-1) and tested again.

The problem still exists.

The bug can be reproduced by constantly keeping the connection rate 
between the webserver and backend at around 15/sec. After some time 
(around 5 hours in my last test) the frontend starts reusing ephemeral 
ports even though it is configured not to.


Best

Markus

Bug#1027382: Please, minimize your build chroots

On 2023-01-28 15:03:04 +0200, Adrian Bunk wrote:
> On Sat, Jan 28, 2023 at 12:24:47PM +0100, Santiago Vila wrote:
> >...
> > * Those bugs are RC by definition and have been for a long time.
> >...
> 
> Please provide a pointer where a release team member has said so 
> explicitly in recent years.
> 
> In my experience they are usually saying that FTBFS that do not happen 
> on the buildds of release architectures are usually not RC.

Indeed. We require that packages are buildable on the buildds. If they
don't and they built before, they are RC buggy. For all other FTBFS
bugs, please use severity important at most.

Cheers
-- 
Sebastian Ramacher

Bug#1026204: tar FTBFS on armel, armhf, i386, hppa, powerpc and sparc64

2023-01-28 Thread Andreas Henriksson

Hello taffit,

On Sat, Jan 28, 2023 at 12:10:53PM +0100, David Prévot wrote:
> Hi,
> 
> Le Wed, Jan 18, 2023 at 01:24:37AM +0100, Helge Deller a écrit :
> > On Sat, 14 Jan 2023 20:38:38 +0100 Andreas Henriksson  
> > wrote:
> > > Here's a slightly different patch to implement basically the same thing
> > 
> > Yes, I like this patch better too.
> 
> Unfortunately, even if both patches allow me to build tar on i386, they
> also both lead to an FTBFS on amd64.

Thanks for the feedback. I ran short on time when looking at this and
tried to cheap out on just setting `-D_TIME_BITS=64` directly
which causes problems.

I generally have no clue when it comes to gnulib but I've now made
an attempt at backporting the `year2038` gnulib module that upstream
has enabled. I've pushed this here:
https://salsa.debian.org/debian/tar/-/commits/wip/bug1026204

This time I've build-tested both on a sid amd64 chroot and
a sid i386 chroot (on top of amd64).

Maybe there's a better/cleaner way of doing this backport.
I also have no idea if this impacts the output format of tar
in any incompatible way, but hopefully it doesn't since upstream
seems to now have it enabled by default in git atleast.

Hopefully someone finds this useful... I'm not confident enough to
actually upload this myself. Reviews welcome.

Also note that the debian gnulib package seems to have the year2038
stuff in largefile.m4 already, so maybe it would be better to try to
use that instead of the bundled m4 files in tar?!...
(That should hopefully also sort out anyones worry about shipping
generated (diff) files without source.)

Regards,
Andreas Henriksson

Bug#1029849: hw-detect: storing firmware information specifically

Package: hw-detect
Severity: important
X-Debbugs-Cc: debian-rele...@lists.debian.org

Hi,

Quoting the text that was agreed to via the 2022 General Resolution
about non-free firmware:

When the installer/live system is running we will provide
information to the user about what firmware has been loaded (both
free and non-free), and we will also store that information on the
target system such that users will be able to find it later. 

During the initial brainstorming, I think it was suggested to maybe
include some kind of informational message at the end of the
installation process, like “we installed this and that” or “yay,
you're entirely free”.

That would mean extra work on the translation side, wouldn't add much
value, so that looks like something we should *not* implement.


Regarding the letter of the text, and given hw-detect's code, it's
probably easy enough to keep a file around during the installation
process, with both package name and the component it was found in.

hw-detect already has some finish-install hooks, so it would only need
to generate something like /var/log/installer/firmware-packages from
it, with “$package $component” on each line?

And maybe “# no firmware packages” (with a leading # to signal a
comment), so that people can easily iterate over it if they so wish?


I don't think that's a blocker for the next d-i release, that might be
considered a blocker for Bookworm though; debian-release@ in Cc can
comment and raise severity if that's desired.

If one wanted not to work on this at all, one could make the case that
/var/log/installer/syslog can be used to determine whether/which
firmware packages were installed; the presence of non-free-firmware in
sources.list would be another indication. (That's why I don't think
that's a short-term blocker at all.) But building a 2-column table out
of existing information shouldn't be much work anyway…


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

Bug#1029670: node-browser-pack: puts relative path to prelude into source map

2023-01-28 Thread Thorsten Glaser

On Thu, 26 Jan 2023, Yadd wrote:

> could you try attached patch ? It keeps related paths where needed.

Tested now (only one build, but should suffice), and yes, it does
the job.

Thanks,
//mirabilos
-- 
15:41⎜ Somebody write a testsuite for helloworld :-)

Bug#1029848: hw-detect: decide how to configure firmware support