Bug#1016359: [edk2-devel] [Patch 1/2] OvmfPkg: Change default to disable MptScsi and PvScsi

[Gerd Hoffmann]

  Hi,

> A patch mentioned above set MPT_SCSI_ENABLE=FALSE, that removed
> support for LSI 53C1030 and SAS1068.
> These SCSI controllers were emulated  by VMware, Parallels and I guess
> VitualBox.
> This is generic setup for VMware VMs, as far as I remember.
> So the booting of such VMs (probably migrated from VMware  and others)
> was definitely broken.

Yes.  Problem is there is no maintainer for the driver.  There used to
be one, but the email address started bouncing.  So we updated
Maintainers.txt and flipped the switch to not build the unmaintained
drivers by default.

If debian is fine with shipping unmaintained software to its users you
can flip the config switches of course, at least as long as the drivers
are still in the tree.  The drivers are at risk of being removed though
in case we don't find a new maintainer within a year or two.

take care,
  Gerd

Bug#1025665: Recent Kerberos upgrade breaks DRM and Xorg startup on Raspberry Pi 4

[Sad Clouds]

Package: libk5crypto3
Version: 1.18.3-6+deb11u3

# uname -a
Linux rp4 5.10.0-19-arm64 #1 SMP Debian 5.10.149-2 (2022-10-21) aarch64
GNU/Linux

The following upgrade on Raspberry Pi 4 seems to break DRM and
Xorg no longer starts on Debian 11:

/var/log/apt/history.log
Start-Date: 2022-12-05  17:06:18
Commandline: apt dist-upgrade
Upgrade: libgssapi-krb5-2:arm64 (1.18.3-6+deb11u2, 1.18.3-6+deb11u3), 
libkrb5support0:arm64 (1.18.3-6+deb11u2, 1.18.3-6+deb11u3), libkrb5-3:arm64 
(1.18.3-6+deb11u2, 1.18.3-6+deb11u3), libk5crypto3:arm64 (1.18.3-6+deb11u2, 
1.18.3-6+deb11u3), vivaldi-stable:arm64 (5.5.2805.44-1, 5.5.2805.50-1)
End-Date: 2022-12-05  17:06:37

The following new kernel errors are logged:

[   96.222828] [drm:drm_atomic_helper_wait_for_dependencies [drm_kms_helper]] 
*ERROR* [PLANE:60:plane-3] flip_done timed out
[  106.463033] [drm:drm_atomic_helper_wait_for_flip_done [drm_kms_helper]] 
*ERROR* [CRTC:64:crtc-3] flip_done timed out
[  116.703323] [drm:drm_atomic_helper_wait_for_dependencies [drm_kms_helper]] 
*ERROR* [CRTC:64:crtc-3] flip_done timed out
[  126.943416] [drm:drm_atomic_helper_wait_for_dependencies [drm_kms_helper]] 
*ERROR* [CONNECTOR:32:HDMI-A-1] flip_done timed out
[  137.183538] [drm:drm_atomic_helper_wait_for_dependencies [drm_kms_helper]] 
*ERROR* [PLANE:60:plane-3] flip_done timed out

Downgrading the above set of packages resolves the issue:

# apt install libk5crypto3:arm64=1.18.3-6+deb11u2 
libkrb5support0:arm64=1.18.3-6+deb11u2 libkrb5-3:arm64=1.18.3-6+deb11u2 
libgssapi-krb5-2:arm64=1.18.3-6+deb11u2
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Suggested packages:
  krb5-doc krb5-user
Recommended packages:
  krb5-locales
The following packages will be DOWNGRADED:
  libgssapi-krb5-2 libk5crypto3 libkrb5-3 libkrb5support0
0 upgraded, 0 newly installed, 4 downgraded, 0 to remove and 0 not upgraded.
Need to get 681 kB of archives.
After this operation, 4,096 B of additional disk space will be used.
Do you want to continue? [Y/n] y
Get:1 http://deb.debian.org/debian bullseye/main arm64 libk5crypto3 arm64 
1.18.3-6+deb11u2 [114 kB]
Get:2 http://deb.debian.org/debian bullseye/main arm64 libkrb5support0 arm64 
1.18.3-6+deb11u2 [64.9 kB]
Get:3 http://deb.debian.org/debian bullseye/main arm64 libkrb5-3 arm64 
1.18.3-6+deb11u2 [346 kB]
Get:4 http://deb.debian.org/debian bullseye/main arm64 libgssapi-krb5-2 arm64 
1.18.3-6+deb11u2 [155 kB]
Fetched 681 kB in 1s (637 kB/s)   
dpkg: warning: downgrading libk5crypto3:arm64 from 1.18.3-6+deb11u3 to 
1.18.3-6+deb11u2
(Reading database ... 166394 files and directories currently installed.)
Preparing to unpack .../libk5crypto3_1.18.3-6+deb11u2_arm64.deb ...
Unpacking libk5crypto3:arm64 (1.18.3-6+deb11u2) over (1.18.3-6+deb11u3) ...
Setting up libk5crypto3:arm64 (1.18.3-6+deb11u2) ...
dpkg: warning: downgrading libkrb5support0:arm64 from 1.18.3-6+deb11u3 to 
1.18.3-6+deb11u2
(Reading database ... 166394 files and directories currently installed.)
Preparing to unpack .../libkrb5support0_1.18.3-6+deb11u2_arm64.deb ...
Unpacking libkrb5support0:arm64 (1.18.3-6+deb11u2) over (1.18.3-6+deb11u3) ...
Setting up libkrb5support0:arm64 (1.18.3-6+deb11u2) ...
dpkg: warning: downgrading libkrb5-3:arm64 from 1.18.3-6+deb11u3 to 
1.18.3-6+deb11u2
(Reading database ... 166394 files and directories currently installed.)
Preparing to unpack .../libkrb5-3_1.18.3-6+deb11u2_arm64.deb ...
Unpacking libkrb5-3:arm64 (1.18.3-6+deb11u2) over (1.18.3-6+deb11u3) ...
Setting up libkrb5-3:arm64 (1.18.3-6+deb11u2) ...
dpkg: warning: downgrading libgssapi-krb5-2:arm64 from 1.18.3-6+deb11u3 to 
1.18.3-6+deb11u2
(Reading database ... 166394 files and directories currently installed.)
Preparing to unpack .../libgssapi-krb5-2_1.18.3-6+deb11u2_arm64.deb ...
Unpacking libgssapi-krb5-2:arm64 (1.18.3-6+deb11u2) over (1.18.3-6+deb11u3) ...
Setting up libgssapi-krb5-2:arm64 (1.18.3-6+deb11u2) ...
Processing triggers for libc-bin (2.31-13+deb11u4) ...

Bug#1025493: firefox crashes instantly at start

[Felix Zielcke]

Am Dienstag, dem 06.12.2022 um 21:07 +0100 schrieb VA:
> Le 06/12/2022 à 19:37, Felix Zielcke a écrit :
> > I have exactly the same problem since Mesa 22.3.0 was uploaded to
> > unstable.
> > Downgrading all src:mesa packages to version 22.2.4 from testing
> > fixes
> > this for me.
> > I've got a Nvidia graphic card and use the Nvidia driver packages
> > from
> > Debian. It doestn't matter at all if nvidia-vaapi-driver is
> > installed
> > or removed/purged.
> 
> Seems mesa 22.3.0-2 fixed the problem for me. What about you?
> Maybe it was
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1025312

Thanks. Haven't seen that yet.
Yes it fixes it also for me.

Bug#1025664: rednotebook: Paste ’ with ' highlighted inserts at incorrect position

[Jeffrey Ratcliffe]

Package: rednotebook
Version: 2.27.1+ds-2
Severity: normal

Dear Maintainer,

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

   * What led up to the situation?
Typed "didn't"
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
Highlighted the ' and pasted ’
   * What was the outcome of this action?
The ’ character was inserted at the beginning of the word.
   * What outcome did you expect instead?
That the ’ character would be rather pasted over the highlighted ' character.


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

Kernel: Linux 6.0.0-5-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, 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 rednotebook depends on:
ii  gir1.2-gdkpixbuf-2.0  2.42.10+dfsg-1
ii  gir1.2-glib-2.0   1.74.0-2
ii  gir1.2-gtk-3.03.24.35-2
ii  gir1.2-gtksource-44.8.3-1
ii  gir1.2-pango-1.0  1.50.10+ds-1
ii  gir1.2-webkit2-4.02.38.2-1+b1
ii  python3   3.10.6-1
ii  python3-gi3.42.2-3
ii  python3-yaml  6.0-3+b1

Versions of packages rednotebook recommends:
ii  python3-enchant  3.2.2-1

rednotebook suggests no packages.

-- no debconf information

Bug#1025370: ntcard: ftbfs with nthash 2.3.0

[Andreas Tille]

Hi,

I'm considering reverting the version bump (shame on me I did not tested
ntcard before uploading).

Kind regards
Andreas.

-- 
http://fam-tille.de

Bug#1016332: librsb: FTBFS: gmake[3]: *** [Makefile:920: qtests] Error 1

[Rafael Laboissière]

* Michele Martone  [2022-12-05 15:31]:


In my 20221204@23:42 (yesterday) email I forgot to add that on my chroot 
setup, I can reproduce latex failing to compile the file I was attaching. 
In that setup I have a utf8x.def too, sized 8036 bytes and with md5sum 
21f7ac37aafb6cfeddbb196b8bfd6280 .


To the goal of fixing the librsb package: that test is the last one in 
`make tests`, and it it's just to make sure rsbtest can produce a buildable 
LaTeX file; it's nothing core or important, so sed'ing out that line 
seems the solution to me -- librsb itself is functional.


Ok, thanks, I applied the patch you suggested (s/utf8x//) and uploaded 
version 1.3.0.1+dfsg-3 of the package to unstable. So far, it built 
correctly on all official architectures for bookworm.


Let us see what will happen with the next automatic rebuild of all 
package in sid.


@Lucas: if the rebuild goes fine, will this bug report be automatically 
closed? Otherwise, is there a web page where the results can be tracked?


Best,

Rafael

Bug#1025663: qmake6: how should users query for QT_INSTALL_PLUGINS?

[Helmut Grohne]

Package: qmake6
Version: 6.3.1+dfsg-10
Severity: important
Control: affects -1 + src:fcitx-qt5
User: debian-cr...@lists.debian.org
Usertags: ftcbfs
X-Debbugs-Cc: debian-cr...@lists.debian.org

Hi,

we've hit an interesting issue with qmake for QT6. This almost certainly
is a pattern and I'll use fcitx-qt5 as an example.

fcitx-qt5 looks for a target Qt6::qmake and queries its LOCATION
property to be able to run it. Then it runs that with -query
QT_INSTALL_PLUGINS to locate the installation directory for plugins.
Unfortunately, what it gets is the build architecture one rather than
the host architecture one.

The crux of this is that /usr/bin/qmake6 cannot know about the host
architecture. That information is a parameter of the build and nothing
has passed this information along to it. It cannot just pull this
information out of nothing. So we basically have two options:

a) Make sure that Qt6::qmake's LOCATION resolves to something that
   includes the information of the host architecture somehow.
b) Declare that this method of querying qmake is unsupported and fix
   every package (including fcitx-qt5) in some other way.

For b), I have no clue what that other way would be. If someone knows,
that would be great. I also have little clue how frequent this pattern
is and how many packages we would have to fix. The expectation is "many"
from my experience with QT5.

The implications of a) are quite well understood, because that's the
route we opted for with QT5. It's a fairly involved route that took us
more than a year to work properly, but maybe we can speed up by learning
from earlier mistakes, so how does it work?

The qmake6 package gains new binaries /usr/bin/-qmake6. These
actually are shell scripts that wrap qmake6 and inject the information
about the host architecture into the command line. Then, we centrally
divert Qt6::qmake to this location and everything will magically work.
To get an idea how this works, install qt5-qmake and look at
/usr/bin/$(dpkg -qDEB_BUILD_GNU_TYPE)-qmake. That should be fairly
obvious. We're in a far better position than we started with QT5 as we
already have the necessary qmake6 vs qmake6-bin split in place in
exactly the way it needs to be. Also a number of client packages have
been switched from AC_PATH_PROG to AC_PATH_TOOL for locating qmake
already.

What we need now is a choice on which way we do it. The choice
essentially is:

a) Add architecture-specific qmake wrappers for QT6.
b) Declare that running qmake6 -query SOMEVAR is unsupported.

Patrick and Pino, what's your thoughts on this? If you feel like you
cannot make such a choice, let us figure out what information is
missing.

I have a preference for a) at this time, because it's changing one
package versus a rabbit hole. Do you agree?

Helmut

Bug#1025662: matrix-synapse: synapse_register_new_matrix_user fails on recent versions

[Russell Coker]

Package: matrix-synapse
Version: 1.72.0-1
Severity: normal
Tags: upstream

/usr/bin/synapse_register_new_matrix_user -u $1 -p $2 -a -k $PASS

I run the above command to create a new users, it's in a script that has been
working since April on one server and since 2020 on another.  Now it gives
the following error:

Traceback (most recent call last):
  File "/usr/bin/synapse_register_new_matrix_user", line 8, in 
sys.exit(main())
  File 
"/usr/lib/python3/dist-packages/synapse/_scripts/register_new_matrix_user.py", 
line 247, in main
elif config:
UnboundLocalError: local variable 'config' referenced before assignment


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

Kernel: Linux 5.10.0-19-amd64 (SMP w/2 CPU threads)
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: SELinux: enabled - Mode: Enforcing - Policy name: default

Versions of packages matrix-synapse depends on:
ii  adduser 3.118
ii  debconf [debconf-2.0]   1.5.77
ii  init-system-helpers 1.60
ii  libc6   2.36-5
ii  libgcc-s1   10.2.1-6
ii  libjs-jquery3.5.1+dfsg+~3.5.5-7
ii  libpython3-stdlib   3.9.2-3
ii  lsb-base11.1.0
ii  python3 3.9.2-3
ii  python3-attr20.3.0-1
ii  python3-bcrypt  3.2.0-1~bpo11+1
ii  python3-bleach  3.2.1-2.1
ii  python3-canonicaljson   1.6.2-1
ii  python3-cryptography3.3.2-1
ii  python3-distutils   3.9.2-1
ii  python3-frozendict  1.2-3~bpo11+1
ii  python3-ijson   3.1.4-1
ii  python3-importlib-metadata  1.6.0-2
ii  python3-jinja2  3.0.3-1~bpo11+1
ii  python3-jsonschema  3.2.0-3
ii  python3-lxml4.6.3+dfsg-0.1+deb11u1
ii  python3-matrix-common   1.3.0-2~bpo11+3
ii  python3-msgpack 1.0.0-6+b1
ii  python3-netaddr 0.7.19-5
ii  python3-openssl 20.0.1-1
ii  python3-packaging   20.9-2
ii  python3-phonenumbers8.12.1-1
ii  python3-pil 8.1.2+dfsg-0.3+deb11u1
ii  python3-prometheus-client   0.9.0-1
ii  python3-psycopg22.8.6-2
ii  python3-pyasn1  0.4.8-1
ii  python3-pyasn1-modules  0.2.1-1
ii  python3-pydantic1.10.2-1
ii  python3-pymacaroons 0.13.0-4
ii  python3-service-identity18.1.0-6
ii  python3-signedjson  1.1.1-2
ii  python3-sortedcontainers2.1.0-2
ii  python3-systemd 234-3+b4
ii  python3-treq18.6.0-0.2
ii  python3-twisted 20.3.0-7+deb11u1
ii  python3-typing-extensions   4.3.0-2
ii  python3-unpaddedbase64  2.1.0-2
ii  python3-yaml5.3.1-5

Versions of packages matrix-synapse recommends:
pn  matrix-synapse-ldap3  
pn  python3-pympler   

Versions of packages matrix-synapse suggests:
pn  python3-authlib  
ii  python3-jwt  1.7.1-2

-- Configuration Files:
/etc/matrix-synapse/homeserver.yaml changed [not included]

-- debconf information:
* matrix-synapse/report-stats: true
* matrix-synapse/server-name: coker.com.au

Bug#1024054: bullseye-pu: package mariadb-10.5 10.5.18-0+deb11u1

[Otto Kekäläinen]

> I assume there are no other changes in the new releases that might be
> relevant / interesting to users (and thus worthy of mentioning in the
> changelog)?

Misc bugfixes but nothing special to highlight, and nothing that is
known to fix any of the 5 bugs tracked at bugs.debian.org for
mariadb-10.5.

> Please go ahead.

Done.

Bug#1024735: klibc-utils: klibc sh segfault on invalid substitutions

[Christoph Anton Mitterer]

Just for the records, meanwhile I've also opened a proper ticket about
this over at BusyBox regarding the same bug in their sh at:

https://bugs.busybox.net/show_bug.cgi?id=15171

Bug#1024635: klibc-utils: klibc sh segfault on invalid substitutions

[Christoph Anton Mitterer]

Just for the records, meanwhile I've also opened a proper ticket about
this over at BusyBox regarding the same bug in their sh at:

https://bugs.busybox.net/show_bug.cgi?id=15171

Bug#1024735: [klibc] klibc sh segfault on invalid substitutions

[Christoph Anton Mitterer]

Hey Ben.

On Sun, 2022-11-27 at 17:51 +0100, Ben Hutchings wrote:
> I don't think I will work on this in klibc until there's a fix in
> upstream dash.  If you're still watching upstream dash, please let me
> know when there's a fix I can pick.

A patch has now been posted for dash at:
https://lore.kernel.org/dash/y47zlpwkqy+ji...@gondor.apana.org.au/
which is apparently scheduled to be merged into their git.

Cheers,
Chris.

Bug#1024635: dash: segfaults during runtime when executing a script with invalid syntax

[Christoph Anton Mitterer]

Control: tags -1 + patch

Hey.

For the records:

A patch (for dash) was posted at:
https://lore.kernel.org/dash/y47zlpwkqy+ji...@gondor.apana.org.au/
and is scheduled to be merged into upstream’s git.


Cheers,
Chris.

Bug#1025661: rust-plotters: invalid Uploaders field: missing comma between Jelmer Vernooij and Blair Noctis

[Paul Wise]

Source: rust-plotters
Version: 0.3.4-1
Severity: serious

rust-plotters 0.3.4-1 introduced an invalid Uploaders field, that is
missing a comma between Jelmer Vernooij and Blair Noctis.

   $ apt-cache showsrc rust-plotters | grep -E '^$|^Version|^Uploaders'
   Version: 0.3.4-1
   Uploaders: Jelmer Vernooij  Blair Noctis 
   
According to Debian policy 5.6.3 the Uploaders field must separate
individual uploaders using commas:

   List of the names and email addresses of co-maintainers of the
   package, if any.
   ...
   The format of each entry is the same as that of the Maintainer
   field, and multiple entries must be comma separated.
  
https://www.debian.org/doc/debian-policy/ch-controlfields.html#uploaders

This is causing the DDPO and BLS cron jobs to send error mails,
please fix it as soon as possible.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#1025660: xzgv: Exif Orientations 2 and 3 are handled incorrectly

[Tobias Hoffmann]

Package: xzgv
Version: 0.9.2-2+b1
Severity: normal
Tags: upstream patch

When using xzgv with --exif-orient, not all orientations are handled
correctly.

Test Images can be found here:
https://github.com/recurser/exif-orientation-examples

Rotation 2 and 3 are not currently not rotated correctly by xzgv.

The exif rotation is translated into xzgv's internal representation in
backend_get_orientation_from_file(), here:
https://sourceforge.net/p/xzgv/git/ci/master/tree/src/backend.c#l215

  static const ExifShort xzgv_orient[]={0,0,1,3,2,7,4,6,5};

The proposed fix is to swap the values at index 2 and 3, giving:

  static const ExifShort xzgv_orient[]={0,0,3,1,2,7,4,6,5};


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

Kernel: Linux 5.19.0 (SMP w/24 CPU threads; PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages xzgv depends on:
ii  libc62.36-5
ii  libexif120.6.22-3
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-1
ii  libglib2.0-0 2.74.2-1
ii  libgtk2.0-0  2.24.32-3
ii  libx11-6 2:1.8.1-2

xzgv recommends no packages.

xzgv suggests no packages.

-- no debconf information

Bug#1022573: lxqt-session is affected by procps transition

[陳昌倬]

On Tue, Dec 06, 2022 at 11:37:15PM +0100, Sebastian Ramacher wrote:
> On 2022-12-07 00:30:30 +0800, ChangZhuo Chen wrote:
> > Hi,
> > 
> > lxqt-session is also affected by procps transition, and there is
> > untested patch [0] available.
> 
> Please avoid an upload until we get the current lxqt situation settled.
> I'd prefer to not entangle lxqt with the procps transition.

No problem. We will wait for lxqt transition first.


-- 
ChangZhuo Chen (陳昌倬) czchen@{czchen,debian}.org
http://czchen.info/
Key fingerprint = BA04 346D C2E1 FE63 C790  8793 CC65 B0CD EC27 5D5B


signature.asc
Description: PGP signature

Bug#992592: lightdm fails to start after update to bullseye (missing '/var/lib/lightdm/data')

[наб]

Hi!

A friend just hit this on a fresh lightdm install on current sid;
she did apt install lightdm; dpkg-reconfigure lightdm,
and on restart she kept getting
  Could not enumerate user data directory /var/lib/lightdm/data: Error opening 
directory '/var/lib/lightdm/data': No such file or directory
from lightdm in the journal.

Inexplicably, repeating the steps from the postinst:
  mkdir -p /var/lib/lightdm
  chown lightdm:lightdm /var/lib/lightdm
  chmod 0750 /var/lib/lightdm
/and then/
  sudo -u lightdm mkdir /var/lib/lightdm/data
made lightdm go on until an unrelated X.org error killed it.

Adding just the latter to the presumably-run-by-the-postinst
bit may've worked as well, but we were hardly in a clinical
environment.

Best,
наб


signature.asc
Description: PGP signature

Bug#1023755: logcheck-database: New default rsyslog high-precision timestamp breaks most rules

[Mathias Gibbens]

On Tue, 2022-12-06 at 23:55 +, Richard Lewis wrote:
> On Tue, 6 Dec 2022 at 01:34, Richard Lewis
>  wrote:
> > I didnt do a proper patch yet
> 
> And now i have: 
> https://salsa.debian.org/debian/logcheck/-/merge_requests/15

  Thanks, Richard! I've made a few comments on that merge request. If
there's no other comments by the end of the week I'll plan to merge it
over the weekend.

  Also, you had commented

> In the replacement, I  we want the old prefix _first_ for future-
> proofing: rsyslog is being demoted in priority: it may still be
> pulled in as dependencies, more and more we will see systems without
> rsyslog installed at all - all the logging will be in the journal. 
> So to remain useful, logcheck will need to enable checking of the
> systemd journal as well as /var/log/syslog. And the journal lines are
> extracted by logcheck in the "old" format. So I think we should do
> this change with that in mind.

  I don't want to accidentally loose this -- could you make sure
there's a bug in the BTS to remind us to properly enable checking
systemd's journal?

Thanks,
Mathias


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

Bug#1025658: libboost-python1.74-dev: Python 3.11 changes break loading of boost-python using extensions

[Stuart Prescott]

Package: libboost-python1.74-dev
Version: 1.74.0-17+b2
Severity: serious
Tags: patch
Justification: Breaks reverse dependencies with Python 3.11
X-Debbugs-Cc: stu...@debian.org, debian-pyt...@lists.debian.org


Dear Maintainer,

Python 3.11 has changed some details around types and GC; boost's enum.cpp
needs modifying to cope. The result of this change is that trying to
load an extension compiled with Debian's boost 1.74 results in a C++
exception being thrown and, since not properly handled, the following
rather obscure error:

SystemError: initialization of $module raised unreported exception

Further details courtesy of Alastair McKinstry's debugging work are to
be found at

https://bugs.debian.org/1024911#14

So far, we've spotted this problem in:

cctbx: https://bugs.debian.org/1024859
ecflow: https://bugs.debian.org/1024911
python-pgmagick: https://bugs.debian.org/1023909

The attached patch is a (trivial) backport of the upstream change for
this:

https://github.com/boostorg/python/commit/a218babc8daee904a83f550fb66e5cb3f1cb3013

I've verified that the attached patch solves the Python 3.11 incompatibility
of python-pgmagick, allowing it to successfully build, meaning that it is
now able to load its boost-python extensions for the test suite.

regards
Stuart
Description: Tweak enum for python 3.11 compatibility
 Backport upstream patch for compatibility with python 3.11
Origin: 
https://github.com/boostorg/python/commit/a218babc8daee904a83f550fb66e5cb3f1cb3013
--- a/libs/python/src/object/enum.cpp
+++ b/libs/python/src/object/enum.cpp
@@ -119,7 +119,6 @@
 #if PY_VERSION_HEX < 0x0300
 | Py_TPFLAGS_CHECKTYPES
 #endif
-| Py_TPFLAGS_HAVE_GC
 | Py_TPFLAGS_BASETYPE,  /* tp_flags */
 0,  /* tp_doc */
 0,  /* tp_traverse */

Bug#1025657: init-system-helpers: Depends lead to full perl installation

[Luca Boccassi]

Control: tags -1 moreinfo

On Wed, 7 Dec 2022 01:26:15 +0100 Bastian Germann 
wrote:
> Package: init-system-helpers
> Severity: important
> Version: 1.65.2
> 
> init-system-helpers depends on "usrmerge | usr-is-merged". This in
turn depends on libfile-find-rule-perl
> which currently results in a complete perl installation for
`debootstrap --variant=minbase`.

That should install usr-is-merged, which has no dependencies. How did
you run debootstrap exactly? Which version?

-- 
Kind regards,
Luca Boccassi


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

Bug#1025617: [Pkg-rust-maintainers] Bug#1025617: rust-async-io: Please update to v1.12.0

[Peter Green]

> Please update to v1.12.0.

From checking upstream git, the only change in 1.12.0 is switching the windows 
backend from
"winapi" (which is in Debian) to "windows-sys" (which is not in Debian), 
upstream git
has since switched again and now uses rustix on all platforms.

I could make a patch to strip out the windows-sys support and upload 1.12.0 to 
Debian
but it seems a bit of a pointless excersize to make such a patch only to drop 
it again
when 1.13 is released.

Bug#686436: openafs-modules-dkms: Does not build with squeeze kernel: error: asm/errno.h: No such file or directory

[Diederik de Haas]

Control: tag -1 moreinfo

On Mon, 03 Sep 2012 14:24:47 -0700 Russ Allbery  wrote:
> Ben Hutchings  writes:
> > On Mon, Sep 03, 2012 at 12:21:06PM -0700, Russ Allbery wrote:
> > [...]
> >> linux-libc-dev maintainers, when upgrading to squeeze, there is
> >> currently nothing preventing linux-libc-dev from being upgraded to a
> >> version that uses multiarch paths in advance of upgrading any compiler
> >> to understand those paths, which results in a broken C compilation
> >> environment.  In this case, this affected dkms, since dkms runs a
> >> compiler from postinst scripts.
> 
> > linux-libc-dev is of course not used to build kernel modules.  But
> > perhaps openafs also needlessly rebuilds userland code every time the
> > kernel is upgraded.
> 
> The OpenAFS build system is rather complicated since it supports a ton of
> different kernels, not just Linux.  Part of it involves building a small C
> program which, in turn, is used to generate part of the build system.
> ...
> Anyway, I think the DKMS involvement is somewhat accidental and one can
> arrive at other problems than just DKMS postinst scripts by doing a
> partial upgrade.  The OpenAFS package just has a peculiarity that caused
> us to stumble across this.

Hi all,

There hasn't been a response to this bug in 10 years. It's about Debian 
Squeeze, gcc-4.7, kernel 2.6.32-5-686; all rather ancient stuff.

What should be done with this bug?

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

Bug#1025657: init-system-helpers: Depends lead to full perl installation

[Bastian Germann]

Package: init-system-helpers
Severity: important
Version: 1.65.2

init-system-helpers depends on "usrmerge | usr-is-merged". This in turn depends 
on libfile-find-rule-perl
which currently results in a complete perl installation for `debootstrap 
--variant=minbase`.

I do not really understand why those Depends are there in the first place. Can 
we get rid of them?
If not, please reassign this to usrmerge to get rid of the full perl 
installation and rely on perl-base instead.

Bug#1019700: mmc0: Timeout waiting for hardware cmd interrupt.

[Diederik de Haas]

Control: tag -1 moreinfo

Hi Hank,

On Tuesday, 13 September 2022 17:48:22 CET Hank Barta wrote:
> Package: src:linux
> Version: 5.19.6-1
> 
>* What led up to the situation?
> 
> Apparent inability to initialize/connect to the SD card H/W. This leads to
> the message below that is repeated about every 10s. It can manifest three
> ways.
> 
> 1. Failure to boot - continuous retries to read SD card.
> 2. If a USB SSD is connected, it can skip the SD card and boot from the SATA
> SSD. (That is the coneition as I prepare this report.)
> 3. Completes boot, message repeats and there are no /dev/mmc* entries and
> WiFi H/W is not recognozed.
> 4. Completes boot, messages are repeated but /dev/mmc entries are present
> and can mount/read an SD card. And WiFi appears to be working
> 5. Completes boot, no SD card timeout messages are reported and system
> operates normally.
> 
> ** Kernel log:
> [  723.735217] mmc0: sdhci: Timeout:   0x | Int stat: 0x00018000
> [  723.741743] mmc0: sdhci: Int enab:  0x00ff1003 | Sig enab: 0x00ff1003
> [  723.748270] mmc0: sdhci: ACmd stat: 0x | Slot int: 0x0001
> [  723.754797] mmc0: sdhci: Caps:  0x45ee6432 | Caps_1:   0xa525
> [  723.761324] mmc0: sdhci: Cmd:   0x0502 | Max curr: 0x00080008
> [  723.767851] mmc0: sdhci: Resp[0]:   0x01aa | Resp[1]:  0x
> [  723.774379] mmc0: sdhci: Resp[2]:   0x | Resp[3]:  0x
> [  723.780905] mmc0: sdhci: Host ctl2: 0x
> [  723.785404] mmc0: sdhci: ADMA Err:  0x | ADMA Ptr: 0x
> [  723.791930] mmc0: sdhci: 
> [  733.923993] mmc0: Timeout waiting for hardware cmd interrupt.
> [  733.929837] mmc0: sdhci:  SDHCI REGISTER DUMP ===
> [  733.936364] mmc0: sdhci: Sys addr:  0x | Version:  0x1002
> [  733.942892] mmc0: sdhci: Blk size:  0x | Blk cnt:  0x
> [  733.949420] mmc0: sdhci: Argument:  0x | Trn mode: 0x
> [  733.955946] mmc0: sdhci: Present:   0x1fff | Host ctl: 0x0001
> [  733.962473] mmc0: sdhci: Power: 0x000f | Blk gap:  0x0080
> [  733.969001] mmc0: sdhci: Wake-up:   0x | Clock:0xfa07
> [  733.975528] mmc0: sdhci: Timeout:   0x | Int stat: 0x00018000
> [  733.982055] mmc0: sdhci: Int enab:  0x00ff1003 | Sig enab: 0x00ff1003
> [  733.988582] mmc0: sdhci: ACmd stat: 0x | Slot int: 0x0001
> [  733.995109] mmc0: sdhci: Caps:  0x45ee6432 | Caps_1:   0xa525
> [  734.001636] mmc0: sdhci: Cmd:   0x0502 | Max curr: 0x00080008
> [  734.008163] mmc0: sdhci: Resp[0]:   0x01aa | Resp[1]:  0x
> [  734.014689] mmc0: sdhci: Resp[2]:   0x | Resp[3]:  0x
> [  734.021216] mmc0: sdhci: Host ctl2: 0x
> [  734.025716] mmc0: sdhci: ADMA Err:  0x | ADMA Ptr: 0x
> [  734.032242] mmc0: sdhci: 

The title of this bug and the above quoted part of the kernel log seems to be 
the same as the problem reported in https://bugs.debian.org/985630.

Do you agree?
Does that make this bug the same as the other one (and should therefor be 
merged)? The main reason I'm hesitant to merge them is that both bugs also 
describe other issues.
While the repeated messages aren't 'nice', they itself are harmless AFAICT.
But what you further described is more then just harmless.

Can you clarify? And while you're at it, also tell us whether the issue is the 
same or resolved or worse with f.e. a 6.0 kernel? It would be great if you 
could also try it with the 6.1-rcX kernel from Experimental.

Cheers,
  Diederik

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

Bug#985630: linux-image-5.10.0-4-rt-arm64: vc4.ko gives a false error messages with empty SD card slot

[Diederik de Haas]

On Friday, 10 June 2022 14:16:00 CET Diederik de Haas wrote:
> If I understand the forwarded thread correctly, the reported symptoms went
> completely away by updating firmware files from
> https://github.com/RPi-Distro/ firmware-nonfree/tree/master/brcm on
> 2021-03-29.
> Those files belong to the firmware-brcm80211 package and the latest version
> in the Debian archives is 20210818-1.
> Are the symptoms also gone with that updated Debian package?

There have been updates to both raspi-firmware and firmware-brcm80211 packages 
and it would be useful to know what the status is with those new versions.

> I also saw mentions of a potential fix wrt MMC, but I don't know if a fix
> was eventually merged (upstream).
> It would be useful to know whether a newer 5.10 kernel or (even better) the
> 5.18.2-1 kernel from Unstable changed anything wrt this bug if there was
> indeed (also) a kernel component to this issue.

And also if newer kernel versions changed the status of this bug.

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

Bug#1023755: logcheck-database: New default rsyslog high-precision timestamp breaks most rules

[Richard Lewis]

On Tue, 6 Dec 2022 at 01:34, Richard Lewis
 wrote:
> I didnt do a proper patch yet

And now i have:  https://salsa.debian.org/debian/logcheck/-/merge_requests/15

Bug#1025656: synchronous exception when using qemu-efi-aarch64 2022.11

[Simon John]

Package: qemu-efi-aarch64
Version: 2022.11-1

When I try to start a previously working aarch64 VM, or firstboot a new 
one, I get the error on the console:


synchronous exception at 0x000d6910354

Note that the installer works fine and I get just past the grub prompt 
before the crash. Guest is AlmaLinux 9.1 (beta or final).


If I point the VM at AAVMF_CODE.fd and AAVMF_VARS.fd extracted from the 
previous 2022.08 package, everything works fine.


If I downgrade the whole package to qemu-efi-aarch64_2022.08-1_all.deb 
everything works fine.


So whatever happened to those two files in the last three months is the 
culprit, nothing to do with the guest OS or qemu host.


Relevant virt-install flags are below (cpu model makes no difference, 
tried with a56 too, also tried with 1 vcpu):


--arch aarch64
--cpu cortex-a72
--boot loader=/usr/share/AAVM/AAVMF_CODE.fd,
loader_ro=yes,loader_type=pflash,
nvram.template=/usr/share/AAVMF/AAVMF_VARS.fd

It's a virt-7.1 machine type.

Libvirt 8.9.0-1
qemu-system-arm 7.1+dfsg-2+b3

Host is x86_64 Debian Sid, kernel:

6.0.0-5-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.0.10-2 (2022-12-01) x86_64

Regards.

--
Simon John

Bug#60377: "reset" broken for dumb terminals

[Ben Wong]

Package: ncurses-bin
Version: 6.3+20220423-2
Followup-For: Bug #60377
Control: tags -1 patch
Control: tags -1 patch

Dear Maintainer,

This is still a problem. It causes my VT340 serial terminal to hang,
but not immediately. It happens the next time a program tries to open
/dev/ttyUSB0, for example, getty after logging out. I presume this
hasn't been fixed because the bug only affects hardware terminals that
lack a carrier detect line (such as any DEC terminal connected via
DEC423 MMJ).

If anything, clocal ought to be asserted by default, not disabled.
However, I suggest that `reset` should do neither. The man page for
reset is clear on what it does and it does not mention clocal. I have
attached a patch which brings the program back into line with its
documentation.

Thank you,

--Ben



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

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

Versions of packages ncurses-bin depends on:
ii  libc6  2.36-6
ii  libtinfo6  6.3+20220423-2

ncurses-bin recommends no packages.

ncurses-bin suggests no packages.

-- no debconf information
--- reset_cmd.c.orig2021-10-02 11:08:44.0 -0700
+++ reset_cmd.c 2022-11-22 16:00:29.005361817 -0800
@@ -190,13 +190,14 @@
 
 /*
  * Reset the terminal mode bits to a sensible state.  Very useful after
- * a child program dies in raw mode.
+ * a child program dies in raw mode. Requires termios(3) to work. 
  */
 void
 reset_tty_settings(int fd, TTY * tty_settings, int noset)
 {
 GET_TTY(fd, tty_settings);
 
+ /* First reset any special characters to their default values */
 #ifdef TERMIOS
 #if defined(VDISCARD) && defined(CDISCARD)
 reset_char(VDISCARD, CDISCARD);
@@ -228,94 +229,38 @@
 reset_char(VWERASE, CWERASE);
 #endif
 
-tty_settings->c_iflag &= ~((unsigned) (IGNBRK
-  | PARMRK
-  | INPCK
-  | ISTRIP
-  | INLCR
-  | IGNCR
-#ifdef IUCLC
-  | IUCLC
-#endif
-#ifdef IXANY
-  | IXANY
-#endif
-  | IXOFF));
 
+/* Next, the reset command does the following
+ *
+ *   sets cooked and echo modes,
+ *   turns off cbreak and raw modes and
+ *   turns on newline translation on output.
+ *
+ * It does not mess with other settings, such as IXOFF and CLOCAL,
+ * as the correct values depend upon what type of terminal (and
+ * even what type of serial cable) is being used.
+ *
+ * Users who need a blunter instrument can try `stty sane` which
+ * makes presumptions about a "typical" setup.
+ */
+
+/* "Cooked" means: brkint ignpar istrip icrnl ixon opost isig icanon */
+/* Setting cooked automatically turns off "raw" and "cbreak" */  
 tty_settings->c_iflag |= (BRKINT
- | IGNPAR
- | ICRNL
- | IXON
-#ifdef IMAXBEL
- | IMAXBEL
-#endif
-   );
+  | IGNPAR
+  | ISTRIP
+  | ICRNL/* Input maps CR to NL */
+  | IXON);
 
-tty_settings->c_oflag &= ~((unsigned) (0
-#ifdef OLCUC
-  | OLCUC
-#endif
-#ifdef OCRNL
-  | OCRNL
-#endif
-#ifdef ONOCR
-  | ONOCR
-#endif
-#ifdef ONLRET
-  | ONLRET
-#endif
-#ifdef OFILL
-  | OFILL
-#endif
-#ifdef OFDEL
-  | OFDEL
-#endif
-#ifdef NLDLY
-  | NLDLY
-#endif
-#ifdef CRDLY
-  | CRDLY
-#endif
-#ifdef TABDLY
-  | TABDLY
-#endif
-#ifdef BSDLY
-  | BSDLY
-#endif
-#ifdef VTDLY
-  | VTDLY
-#endif
-#ifdef FFDLY
-  | FFDLY
-#endif
-  ));
+tty_settings->c_iflag &= ~(INLCR);   /* Input does not map NL to CR */
 
 tty_settings->c_oflag |= (OPOST
 #ifdef ONLCR
- | ONLCR
+  | ONLCR/* Output maps NL to CR-NL */
 #endif
-   );
+);
 
-tty_settings->c_cflag &= ~((unsigned) (CSIZE
-  

Bug#1025335: ansible-core: autopkgtests need to depend on python3-pytest-forked

[Lee Garrett]

On 06/12/2022 22:54, Scott Talbert wrote:



On December 2, 2022 2:54:19 PM EST, Lee Garrett  wrote:

On 02/12/2022 19:15, Scott Talbert wrote:

Source: ansible-core
Version: 2.14.0-1
Severity: important

ansible-core's autopkgtests need to add a Depends on python3-pytest-forked.

python3-pytest-xdist used to depend on -forked, but it no longer does.

See, for example:
https://ci.debian.net/data/autopkgtest/testing/amd64/a/ansible-core/28872265/log.gz


Thanks! Will update it in the next release.


Also, ansible needs to same update.  If you could make these updates in the 
relatively short term it would be appreciated.  pytest-xdist can't migrate 
otherwise.


And done. Thanks for catching it!



Thanks,
Scott

Bug#1025629: [Pkg-sugar-devel] Bug#1025629: Use of PolicyKit by Sugar

[Jonas Smedegaard]

Quoting James Cameron (2022-12-06 20:30:10)
> Sugar uses pkexec to elevate privilege to control backlight and get
> device serial number.  Processes are forked to run shell scripts.  The
> command line is prefixed with pkexec.
> 
> I don't know of any D-Bus use of PolicyKit, nor any use of the
> PyGObject API.
> 
> Hope that helps!

Great help.  Thanks!

 - Jonas

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

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

signature.asc
Description: signature

Bug#997222: libexplain: FTBFS in bullseye

[Håvard Flaget Aasen]

tir. 6. des. 2022 kl. 00:20 skrev Santiago Vila :
>
> Hi.
>
> I'm considering to make an upload to fix this in bullseye.
>
> Am I right to think that the termiox patch with the following changelog
> entry is also desirable to be able to build from bullseye+recent kernel?
>
>- Patch: termiox removed since kernel 5.12, from ALT Linux.
>

Yes, this still still seems to be the right thing to do.
I see that the release that resides in Sid/testing hasn't been pushed
to the correct repo on salsa. If it is of interest, the commit can be
found in my fork [1]

Regards,
Håvard

[1] 
https://salsa.debian.org/haava/libexplain/-/commit/cbda43b911408c6aae87321773ce1529526fba01

Bug#1025655: hovercraft: requires python3-setuptools

[Brendan M. Sleight]

Package: hovercraft
Version: 2.7-2
Severity: important
X-Debbugs-Cc: bms.deb...@barwap.com

Dear Maintainer,


fresh install, running hovercraft 

$ hovercraft planning_presentation.rst html 
Traceback (most recent call last):
  File "/usr/bin/hovercraft", line 33, in 
sys.exit(load_entry_point('hovercraft==2.7', 'console_scripts', 
'console_script')())
  File "/usr/bin/hovercraft", line 25, in importlib_load_entry_point
return next(matches).load()
  File "/usr/lib/python3.9/importlib/metadata.py", line 77, in load
module = import_module(match.group('module'))
  File "/usr/lib/python3.9/importlib/__init__.py", line 127, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
  File "", line 1030, in _gcd_import
  File "", line 1007, in _find_and_load
  File "", line 986, in _find_and_load_unlocked
  File "", line 680, in _load_unlocked
  File "", line 790, in exec_module
  File "", line 228, in _call_with_frames_removed
  File "/usr/share/hovercraft/hovercraft/__init__.py", line 6, in 
import pkg_resources
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 3243, 
in 
def _initialize_master_working_set():
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 3226, 
in _call_aside
f(*args, **kwargs)
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 3255, 
in _initialize_master_working_set
working_set = WorkingSet._build_master()
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 568, in 
_build_master
ws.require(__requires__)
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 886, in 
require
needed = self.resolve(parse_requirements(requirements))
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 772, in 
resolve
raise DistributionNotFound(req, requirers)
pkg_resources.DistributionNotFound: The 'setuptools' distribution was not found 
and is required by hovercraft


   * What outcome did you expect instead?
$ hovercraft planning_presentation.rst html

(No errors - what did happen after apt-get install python3-setuptools)



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

Kernel: Linux 5.10.0-19-amd64 (SMP w/12 CPU threads)
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 hovercraft depends on:
ii  libjs-impress  1.0.0-1
ii  libjs-sphinxdoc3.4.3-2
ii  python33.9.2-3
ii  python3-docutils   0.16+dfsg-4
ii  python3-lxml   4.6.3+dfsg-0.1+deb11u1
ii  python3-pkg-resources  52.0.0-4
ii  python3-pygments   2.7.1+dfsg-2.1
ii  python3-svg.path   3.0-2
ii  python3-watchdog   1.0.2-2

hovercraft recommends no packages.

hovercraft suggests no packages.

-- no debconf information

Bug#1025531: transition: elpi 1.16.8-1

[Sebastian Ramacher]

Control: tags -1 confirmed

On 2022-12-06 10:42:46 +0100, julien.pu...@gmail.com wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> X-Debbugs-Cc: jpu...@debian.org
> X-Debbugs-Cc: Debian OCaml Maintainers
> 
> 
> A new upstream version of elpi is out ; it requires rebuilding all
> depending packages:
> 
>  nmu coq-elpi_1.16.0-1+b2 . ANY . -m 'Rebuild because of upload of
> elpi=1.16.8-1'
>  dw coq-elpi_1.16.0-1+b2 . ANY . -m 'elpi >= 1.16.8-1'
>  nmu coq-hierarchy-builder_1.4.0-2+b4 . ANY . -m 'Rebuild because of
> upload of coq-elpi=1.16.0-1+b2'
>  dw coq-hierarchy-builder_1.4.0-2+b4 . ANY . -m 'coq-elpi >= 1.16.0-
> 1+b2'
>  nmu mathcomp-algebra-tactics_1.0.0-8+b4 . ANY . -m 'Rebuild because of
> upload of coq-elpi=1.16.0-1+b2'
>  dw mathcomp-algebra-tactics_1.0.0-8+b4 . ANY . -m 'coq-elpi >= 1.16.0-
> 1+b2'
>  nmu mathcomp-analysis_0.5.4-3+b4 . ANY . -m 'Rebuild because of upload
> of coq-hierarchy-builder=1.4.0-2+b4 coq-elpi=1.16.0-1+b2'
>  dw mathcomp-analysis_0.5.4-3+b4 . ANY . -m 'coq-hierarchy-builder >=
> 1.4.0-2+b4'
>  dw mathcomp-analysis_0.5.4-3+b4 . ANY . -m 'coq-elpi >= 1.16.0-1+b2'
> 
> 
> I'm waiting for the "go!" signal to upload elpi 1.16.8-1.

Please go ahead

Cheers
-- 
Sebastian Ramacher

Bug#1025654: bullseye-pu: package x4d-icons/1.2-2+deb11u1

[Santiago Vila]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu

Dear Release Managers:

I'd like to fix FTBFS bug #991067 in stable using the attached debdiff 
(not uploaded yet).


The way the FTBFS is fixed is the same I used in upload 1.2-5 which I 
did today for unstable (this upload replaces a previous workaround which 
merely fixed the ftbfs problem by dropping the eps files and thus losing 
functionality).


You will notice that I have decided to raise debhelper compatibility 
level. I am well aware that this should not be done lightly and without 
a good reason.


In this case I'm using the debhelper feature which (during build) 
creates a temporary $HOME directory in which we need to write a config 
file for imagemagick which overrides the one in /etc. This feature 
allows to fix the problem in a simple and effective way, so I believe 
this is justified (to be frank, I don't know how could it be fixed 
easily without this debhelper feature, so the ftbfs bug would probably 
remain unfixed in stable).


Thanks.diff -Nru x4d-icons-1.2/debian/changelog x4d-icons-1.2/debian/changelog
--- x4d-icons-1.2/debian/changelog  2019-03-12 05:38:09.0 +0100
+++ x4d-icons-1.2/debian/changelog  2022-12-06 17:50:00.0 +0100
@@ -1,3 +1,12 @@
+x4d-icons (1.2-2+deb11u1) bullseye; urgency=medium
+
+  * QA upload.
+  * Fix FTBFS problem with new imagemagick. Closes: #991067.
+  * The above patch requires raising debhelper compatibility level to 13,
+which should not be a problem because debhelper 13 is in bullseye.
+
+ -- Santiago Vila   Tue, 06 Dec 2022 17:50:00 +0100
+
 x4d-icons (1.2-2) unstable; urgency=medium
 
   * QA upload.
diff -Nru x4d-icons-1.2/debian/compat x4d-icons-1.2/debian/compat
--- x4d-icons-1.2/debian/compat 2014-05-03 07:01:56.0 +0200
+++ x4d-icons-1.2/debian/compat 1970-01-01 01:00:00.0 +0100
@@ -1 +0,0 @@
-9
diff -Nru x4d-icons-1.2/debian/control x4d-icons-1.2/debian/control
--- x4d-icons-1.2/debian/control2019-03-12 05:37:54.0 +0100
+++ x4d-icons-1.2/debian/control2022-12-06 17:50:00.0 +0100
@@ -2,7 +2,7 @@
 Section: graphics
 Priority: optional
 Maintainer: Debian QA Group 
-Build-Depends: debhelper (>= 9), imagemagick, faketime, librsvg2-bin, 
fonts-dejavu-core
+Build-Depends: debhelper-compat (= 13), imagemagick, faketime, librsvg2-bin, 
fonts-dejavu-core
 Standards-Version: 3.9.5
 Homepage: http://x4d.surgut.co.uk
 Vcs-Git: https://github.com/xnox/x4d.git
diff -Nru x4d-icons-1.2/debian/patches/020_fix_policy.patch 
x4d-icons-1.2/debian/patches/020_fix_policy.patch
--- x4d-icons-1.2/debian/patches/020_fix_policy.patch   1970-01-01 
01:00:00.0 +0100
+++ x4d-icons-1.2/debian/patches/020_fix_policy.patch   2022-12-06 
17:50:00.0 +0100
@@ -0,0 +1,29 @@
+Description: Override overly strict ImageMagick coder policy (#987504)
+ This creates a more permissive version of
+ /etc/ImageMagick-6/policy.xml and ensures it gets loaded after the
+ one from /etc.
+ .
+ It is done by means of a patch to make use of the debhelper-provided
+ $HOME visible by dh_auto_*.
+ .
+ The relevant code is at:
+ 
https://sources.debian.org/src/imagemagick/8:6.9.11.60+dfsg-1.3/magick/configure.c/#L860
+Author: Dennis Filder 
+Last-Updated: 2022-12-06
+
+--- a/generate.sh
 b/generate.sh
+@@ -33,6 +33,13 @@
+ generate XML '1.0' xml10
+ generate XML '1.1' xml11
+ 
++# this relies on debhelper providing a $HOME directory for us to write to
++imversion=$(convert -version|sed -n '/^Version: /s@Version: ImageMagick 
\([[:digit:]]\+\)\..*@ImageMagick-\1@p')
++polfile="/etc/${imversion}/policy.xml"
++mkdir "$HOME"/.magick
++sed -e '//s@"none"@"read|write"@' "$polfile" \
++> "$HOME"/.magick/policy.xml
++
+ /bin/ls Icons/*.svg | sed 's/-v\.svg//' | xargs -L1 -I{} convert -background 
none {}-v.svg {}.png
+ /bin/ls Icons/*.svg | sed 's/-v\.svg//' | xargs -L1 -I{} convert -background 
none {}-v.svg {}.gif
+ /bin/ls Icons/*.svg | sed 's/-v\.svg//' | xargs -L1 -I{} convert -background 
none {}-v.svg {}-v.eps
diff -Nru x4d-icons-1.2/debian/patches/series 
x4d-icons-1.2/debian/patches/series
--- x4d-icons-1.2/debian/patches/series 1970-01-01 01:00:00.0 +0100
+++ x4d-icons-1.2/debian/patches/series 2022-12-06 17:50:00.0 +0100
@@ -0,0 +1 @@
+020_fix_policy.patch

Bug#1025653: scalene: Homepage: points to an unmaintained(?) fork

[Adrian Bunk]

Source: scalene
Version: 1.4.1-1
Severity: minor

Homepage: https://github.com/emeryberger/scalene

But the code in unstable seems to be from the original
  https://github.com/plasma-umass/scalene
(this is also what debian/watch finds).

Bug#1022573: lxqt-session is affected by procps transition

[Sebastian Ramacher]

On 2022-12-07 00:30:30 +0800, ChangZhuo Chen wrote:
> Hi,
> 
> lxqt-session is also affected by procps transition, and there is
> untested patch [0] available.

Please avoid an upload until we get the current lxqt situation settled.
I'd prefer to not entangle lxqt with the procps transition.

Cheers
-- 
Sebastian Ramacher

Bug#1025012: zookeeper: starts but is completely unusable

[Christoph Anton Mitterer]

Hey Pierre.

On Tue, 2022-12-06 at 23:08 +0100, Pierre Gruet wrote:
> Thanks for the bug report (and the follow-up precisions you sent)!
> 
> Yet I fail to reproduce it on testing. I installed zookeeper and 
> zookeeperd on testing, then ran
> 
> $ /usr/share/zookeeper/bin/zkCli.sh
> specifying nothing about the classpath (it is already handled in the 
> MANIFEST.MF file of the zookeeper jar), and I could enter commands 
> (though with no prompt, as you say).

When you've started your zookeeper (I assume you also use the sysvinit
script, respectively the virtual systemd unit generated from that?),
what does your process' command line show, e.g.:
# ps ax | grep org.apache.zookeeper.server.quorum.QuorumPeerMain
   3156 ?Sl   167:08 /usr/bin/java -cp 
/etc/zookeeper/conf:/usr/share/java/zookeeper.jar:/usr/share/java/slf4j-log4j12.jar:/usr/share/java/log4j-1.2.jar
 -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.local.only=true 
-Dzookeeper.log.dir=/var/log/zookeeper -Dzookeeper.root.logger=INFO,ROLLINGFILE 
org.apache.zookeeper.server.quorum.QuorumPeerMain /etc/zookeeper/conf/zoo.cfg

Especially, which CLASSPATH (seems to be the -cp)?

Is your test system clustered (i.e. more than one ZK node?)?


> (However, I also get the hanging issue if I do not install
> zookeeperd.)

Well I guess that's clear, cause then nothing would have started
zookeeper?!



> I guess there is some difference in the versions of the dependencies 
> between stable and testing, as you underline that the dependencies
> come 
> from stable.

That would be quite surprising, IMO,.. cause the issue seems to be
quite clearly the missing CLASSPATH stuff.

I mean if there would be some other package, that is used to start the
java process... and that other package would have a different version
and thus be incompatible, I could imagine this.

But it seems as if zookeeper's sysvinit script does all on it's own and
simply execute java in the end.

So it's hard to imagine, that something interferes, and somehow breaks
the CLASSPATH there?!



> Concerning the SLF4J warning: in the past I already stumbled upon
> this 
> and visited the URI
> https://www.slf4j.org/codes.html#StaticLoggerBinder
> which is in the warning message.

Yeah, also stumbled over that via the error message.


>  Because of the last paragraph in the
> relevant section therein, I was unsure I should choose a SLF4J
> binding 
> as this would impose my choice to the end user. What do you think?

Well since that two infamous security holes, log4j has a somewhat
damaged reputation ;-) ... but apart from that I think this would make
the most sense here.

As I've said in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1025012#20 :

/usr/share/java/slf4j-log4j12.jar wasn't enough for me and I needed to
add /usr/share/java/log4j-1.2.jar to the CLASSPATH instead, in order to
get output to /var/log/zookeeper


> Finally, as:
> - I think there is a mismatch somewhere in the versions of the 
> dependencies between stable and testing;
> - I cannot reproduce on a system with dependencies fetched from
> testing 
> only,
> I would tend to discuss only the SLF4J issue and ignore the rest.
> 
> Please tell me what you think,

I think we should look into both, and at best split things apart.

I mean I can try to reproduce the whole thing on a sid or testing only
systemd an see whether it still fails to start, but right now I'd be
quite surprised why it wouldn't start because of that... and even *if*
that would be the reason, then bullseye to bookwork upgrades need to be
supported, and therefore the package (zookeeper) would need to have
correct versioned dependencies (*if* it's because of a incompatible
version of some dependency).


Thanks,
Chris.

Bug#1020387: dictionaries-common: Consensus regarding the packaging of the Qt WebEngine hunspell binary dictionaries

[Agustin Martin]

El dom, 4 dic 2022 a las 4:54, Soren Stoutner () escribió:
>
> I created an MR:
>
> https://salsa.debian.org/debian/dictionaries-common/-/merge_requests/5
>
> Please review and make sure I haven’t missed anything or misrepresented the 
> consensus.

Merged.

Will wait some days for possible new comments.

Bug#1025652: buster-pu: package nvidia-graphics-drivers-legacy-390xx/390.157-1~deb11u1

[Andreas Beckmann]

Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu

A huge bunch of CVEs has been fixed upstream in the supported branches
of the proprietary nvidia driver. This is probably related to the
release of an open source variant of the kernel module (with the
proprietary bits being restricted to a firmware blob).

So let's upload a new upstream release to stable.
This is a rebuild of the package from sid with no further changes.

Packaging changes include the addition some new substitutions that are
needed for the packaging of above mentioned open source kernel module
(and are included here in order to mimimize the diff between different
driver series maintained in different releases).

The changelog diff looks huge due to rewrapping of long lines, but
the relevant changelog entries are only

+nvidia-graphics-drivers-legacy-390xx (390.157-1~deb11u1) bullseye; 
urgency=medium
+
+  * Rebuild for bullseye.
+
+ -- Andreas Beckmann   Tue, 06 Dec 2022 23:15:45 +0100
+
+nvidia-graphics-drivers-legacy-390xx (390.157-1) unstable; urgency=medium
+
+  * New upstream legacy branch release 390.157 (2022-11-22).
+* Fixed CVE-2022-34670, CVE-2022-34674, CVE-2022-34675, CVE-2022-34677,
+  CVE-2022-34680, CVE-2022-42257, CVE-2022-42258, CVE-2022-42259.
+  https://nvidia.custhelp.com/app/answers/detail/a_id/5415
+  (Closes: #1025281)
+* Improved compatibility with recent Linux kernels.
+
+  [ Andreas Beckmann ]
+  * Refresh patches.
+  * Rename the internally used ARCH variable which might clash on externally
+set values.
+  * Use substitutions for ${nvidia-kernel} and friends (510.108.03-1).
+  * Try to compile a kernel module at package build time (510.108.03-1).
+
+ -- Andreas Beckmann   Sat, 03 Dec 2022 22:17:01 +0100
+
+nvidia-graphics-drivers-legacy-390xx (390.154-2) unstable; urgency=medium
+
+  * Backport nv_install_notifier changes from 418.30, acpi changes from
+430.09, 510.85.02 and 515.65.01, drm_frambuffer.h changes from 515.76 to
+fix kernel module build for Linux 6.0.
+
+ -- Andreas Beckmann   Thu, 20 Oct 2022 11:57:16 +0200

 debian/README.source   
  |  49 ++---
 debian/bug-control.mk  
  |   8 +-
 debian/build-module-packages.sh.in 
  |   2 +-
 debian/changelog   
  | 478 +++--
 debian/control 
  |  21 ++-
 debian/control.in  
  |  25 +--
 debian/control.kmod
  |   6 +-
 debian/control.md5sum  
  |   8 +-
 debian/gbp.conf
  |   2 +-
 debian/module/debian/control.modules.in.binary.in  
  |  21 +++
 debian/module/debian/control.template.binary.in
  |  21 ---
 debian/module/debian/patches/0001-backport-error-on-unknown-conftests.patch
  |  17 +-
 
debian/module/debian/patches/0002-backport-error-on-unknown-conftests-uvm-part.patch
 |   2 +-
 
debian/module/debian/patches/0003-backport-set_-memory-pages-_array-_uc-changes-from-5.patch
 |  10 +-
 debian/module/debian/patches/0004-fix-conftest-includes.patch  
  |  10 +-
 debian/module/debian/patches/arm-outer-sync.patch  
  |   4 +-
 debian/module/debian/patches/armhf-on-arm64-kernel.patch   
  |   4 +-
 debian/module/debian/patches/bashisms.patch
  |   2 +-
 debian/module/debian/patches/cc_version_check-gcc5.patch   
  |   2 +-
 debian/module/debian/patches/fragile-ARCH.patch
  |  36 
 debian/module/debian/patches/nvidia-drm-arm-cflags.patch   
  |   2 +-
 debian/module/debian/patches/series.in 
  |   6 +-
 debian/module/debian/patches/use-kbuild-compiler.patch 
  |  11 ++
 debian/module/debian/patches/use-kbuild-flags.patch
  |   2 +-
 debian/module/debian/rules.in  
  |  23 ++-
 debian/nvidia-alternative.postinst.in  
  |   8 +-
 debian/nvidia-kernel-dkms.dkms.in  
 

Bug#1025537: nfsd: Kernel Oops while serving NFS

[Olivier Mehani]

On Tue 06 Dec 2022 at 15:16:06 +0100, Diederik de Haas wrote:

What's the version of NFS you're using?


The clients are recent Linux hosts, and one Kodi 19.x. I don't specify a 
version in either their fstab or the server's exports.


From my reading of the manpages, it seems that the client will start 
from 4.2 and go down.


For the server, it _may_ vary due to the /etc/exports. I include mine 
below, as I'm not certain how to understand the `fsid` logic, though I 
think in my case it's a simple tree rooted at /.


/home   
192.168.103.0/24(rw,no_subtree_check,crossmnt,all_squash,anongid=999) 
:::::/64(rw,no_subtree_check,crossmnt,all_squash,anongid=999) 
192.168.42.0/24(rw,no_subtree_check,crossmnt,all_squash,anongid=999)
/data   
192.168.103.0/24(rw,no_subtree_check,crossmnt,all_squash,anongid=999) 
:::::/64(rw,no_subtree_check,crossmnt,all_squash,anongid=999) 
192.168.42.0/24(rw,no_subtree_check,crossmnt,all_squash,anongid=999)
/srv/debian-live
192.168.103.0/24(ro,async,subtree_check,no_root_squash) 
:::::/64(ro,async,subtree_check,no_root_squash) 
192.168.42.0/24(ro,async,subtree_check,no_root_squash)
/run/archiso/bootmnt
192.168.103.0/24(ro,async,subtree_check,no_root_squash) 
:::::/64(ro,async,subtree_check,no_root_squash) 
192.168.42.0/24(ro,async,subtree_check,no_root_squash)

Note that additional filesystems are mounted in subdirectories of /data.

--
Olivier Mehani 
PGP fingerprint: 4435 CF6A 7C8D DD9B E2DE  F5F9 F012 A6E2 98C6 6655
Confidentiality cannot be guaranteed on emails sent or received unencrypted.

Bug#933189: Split out the backlight helper?

[Sebastian Ramacher]

Control: found -1 liblxqt1 1.1.0-2
Control: severity -1 serious

Having these files in liblxqt1 is a violation of 8.2. and in the
specific case of the currently ongoing lxqt transition, some reverse
dependencies are now unable to migrated from unstable to testing as
liblxqt0 and liblxqt1 are not co-installable. Raising the severity
accordingly.

Cheers
-- 
Sebastian Ramacher

Bug#1024757: Editor: -key ignored

[Kristian Nielsen]

"Dr. Nikolaus Klepp"  writes:

> Ok, setting the keyboard layout to US makes  working again. Here 3x 
> :

Thanks for the additional test. That data point does suggest that the QT bug
is the root cause.

>> 3. It would be interesting to try to downgrade Qt to some 5.15.4 version and
>> see if that solves the problem. However, I'm not sure how feasible that is,

> This is a thing most likely to solve the problem, 'cause the update I
> dis on 5th November replaced QT 5.15.4 with 5.15.6. Is there an
> archive where I can get the old version?

You can try snapshots.debian.org:

  http://snapshot.debian.org/

The 5.15.6 version entered Unstable on November 29, so something like this
should be a recent snapshot that contains the 5.15.4 version:

  http://snapshot.debian.org/archive/debian/20220928T030933Z/

I'll see if I can get a definite confirmation that the QT bug is the root
cause, and then probably re-assign this bug to QT.

Thanks,

 - Kristian.

Bug#1025537: nfsd: Kernel Oops while serving NFS

[Olivier Mehani]

Ok, looks like v3, if I read this correctly.

[9:09:42] @supahwinch ~$ /usr/sbin/rpcinfo -p   

  130 ↵
   program vers proto   port  service
104   tcp111  portmapper
103   tcp111  portmapper
102   tcp111  portmapper
104   udp111  portmapper
103   udp111  portmapper
102   udp111  portmapper
151   udp   4002  mountd
151   tcp   4002  mountd
152   udp   4002  mountd
152   tcp   4002  mountd
153   udp   4002  mountd
153   tcp   4002  mountd
1000241   udp   4000  status
1000241   tcp   4000  status
133   tcp   2049  nfs
134   tcp   2049  nfs
1002273   tcp   2049  nfs_acl
1000211   udp  53497  nlockmgr
1000213   udp  53497  nlockmgr
1000214   udp  53497  nlockmgr
1000211   tcp  38889  nlockmgr
1000213   tcp  38889  nlockmgr
1000214   tcp  38889  nlockmgr
[9:09:44] @supahwinch ~$ sudo nfsstat –s

0s
Server rpc stats:
calls  badcalls   badfmt badauthbadclnt
447324 0  0  0  0

Server nfs v3:
null getattr  setattr  lookup   
access
4 0% 15575 3% 0 0% 399007   89% 8   
  0%
readlink read writecreate   
mkdir
9478  2% 630% 0 0% 0 0% 0   
  0%
symlink  mknodremove   rmdir
rename
0 0% 0 0% 0 0% 0 0% 0   
  0%
link readdir  readdirplus  fsstat   
fsinfo
0 0% 0 0% 23185 5% 0 0% 4   
  0%
pathconf commit
0 0% 0 0%


--
Olivier Mehani 
PGP fingerprint: 4435 CF6A 7C8D DD9B E2DE  F5F9 F012 A6E2 98C6 6655
Confidentiality cannot be guaranteed on emails sent or received unencrypted.

Bug#1025537: nfsd: Kernel Oops while serving NFS

[Olivier Mehani]

On Tue 06 Dec 2022 at 23:11:14 +0100, Diederik de Haas wrote:

The clients are recent Linux hosts, and one Kodi 19.x. I don't specify a
version in either their fstab or the server's exports.

Sorry, I meant the package version of the NFS server


Ah! No worries.

[9:12:04] @supahwinch ~$ dpkg -l *nfs*
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  knfs (no description 
available)
un  libnfs1  (no description 
available)
ii  libnfs13:amd64 4.0.0-1  amd64NFS client library 
(shared library)
un  libnfs4  (no description 
available)
un  libnfsidmap-dev  (no description 
available)
un  libnfsidmap-regex(no description 
available)
ii  libnfsidmap1:amd64 1:2.6.2-2amd64NFS idmapping library
un  libnfsidmap2 (no description 
available)
un  nfs-client   (no description 
available)
ii  nfs-common 1:2.6.2-2amd64NFS support files 
common to client and server
ii  nfs-kernel-server  1:2.6.2-2amd64support for NFS kernel 
server
un  nfs-server   (no description 
available)

And the relevant packages on one (ArchLinux) client:

[9:16:20] ~$ pacman -Qs nfs | grep local
...
local/gvfs-nfs 1.50.2-1 (gnome)
local/libnfs 5.0.2-1
local/nfs-utils 2.6.2-1
local/nfsidmap 2.6.2-1
local/qemu-block-nfs 7.1.0-10
local/unionfs-fuse 3.2-1

--
Olivier Mehani 
PGP fingerprint: 4435 CF6A 7C8D DD9B E2DE  F5F9 F012 A6E2 98C6 6655
Confidentiality cannot be guaranteed on emails sent or received unencrypted.

Bug#1025537: nfsd: Kernel Oops while serving NFS

[Diederik de Haas]

On Tuesday, 6 December 2022 23:10:32 CET Olivier Mehani wrote:
> >What's the version of NFS you're using?
> 
> The clients are recent Linux hosts, and one Kodi 19.x. I don't specify a
> version in either their fstab or the server's exports.

Sorry, I meant the package version of the NFS server

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

Bug#1025651: bullseye-pu: package nvidia-graphics-drivers-tesla-450/450.216.04-1~deb11u1

[Andreas Beckmann]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu

A huge bunch of CVEs has been fixed upstream in the supported branches
of the proprietary nvidia driver. This is probably related to the
release of an open source variant of the kernel module (with the
proprietary bits being restricted to a firmware blob).

So let's upload a new upstream release to stable.
This is a rebuild of the package from sid with no further changes.

Packaging changes include the addition some new substitutions that are
needed for the packaging of above mentioned open source kernel module
(and are included here in order to mimimize the diff between different
driver series maintained in different releases).

The changelog diff looks huge due to rewrapping of long lines, but
the relevant changelog entries are only

+nvidia-graphics-drivers-tesla-450 (450.216.04-1~deb11u1) bullseye; 
urgency=medium
+
+  * Rebuild for bullseye.
+
+ -- Andreas Beckmann   Tue, 06 Dec 2022 22:39:11 +0100
+
+nvidia-graphics-drivers-tesla-450 (450.216.04-1) unstable; urgency=medium
+
+  * New upstream Tesla release 450.203.03 (2022-11-22).
+* Fixed CVE-2022-34670, CVE-2022-34674, CVE-2022-34675, CVE-2022-34677,
+  CVE-2022-34679, CVE-2022-34680, CVE-2022-34682, CVE-2022-42254,
+  CVE-2022-42256, CVE-2022-42257, CVE-2022-42258, CVE-2022-42259,
+  CVE-2022-42260, CVE-2022-42261, CVE-2022-42262, CVE-2022-42263,
+  CVE-2022-42264.  (Closes: #1025283)
+  https://nvidia.custhelp.com/app/answers/detail/a_id/5415
+- Improved performance on GPUs which are experiencing a high number
+  of correctable ECC memory errors.
+* Improved compatibility with recent Linux kernels.
+  * New upstream Tesla release (amd64 only) 450.203.08 (2022-10-19).
+
+  [ Andreas Beckmann ]
+  * Refresh patches.
+  * Add missing #includes to fix kernel module build for ppc64el.
+  * Rename the internally used ARCH variable which might clash on externally
+set values.
+  * Use substitutions for ${nvidia-kernel} and friends (510.108.03-1).
+  * Try to compile a kernel module at package build time (510.108.03-1).
+
+ -- Andreas Beckmann   Tue, 06 Dec 2022 02:54:57 +0100
+
+nvidia-graphics-drivers-tesla-450 (450.203.03-2) unstable; urgency=medium
+
+  * Backport acpi changes from 510.85.02 and 515.65.01, drm_frambuffer.h
+changes from 515.76 to fix kernel module build for Linux 6.0.
+  * Add support for unversioned Tesla packages (tesla 510.85.02-1).
+
+ -- Andreas Beckmann   Fri, 21 Oct 2022 01:56:00 +0200

 debian/README.source   
  |  49 ++--
 debian/bug-control.mk  
  |   8 +-
 debian/build-module-packages.sh.in 
  |   2 +-
 debian/changelog   
  | 603 -
 debian/control 
  |  23 +-
 debian/control.in  
  |  27 +-
 debian/control.kmod
  |   6 +-
 debian/control.md5sum  
  |   8 +-
 debian/gbp.conf
  |   2 +-
 debian/libnvoptix1.lintian-overrides   
  |   2 +-
 debian/module/debian/control.modules.in.binary.in  
  |  21 ++
 debian/module/debian/control.template.binary.in
  |  21 --
 
debian/module/debian/patches/0009-backport-pci-dma-changes-from-470.129.06.patch
 |  12 +-
 debian/module/debian/patches/bashisms.patch
  |   2 +-
 debian/module/debian/patches/cc_version_check-gcc5.patch   
  |   2 +-
 debian/module/debian/patches/conftest-prefer-arch-headers.patch
  |   2 +-
 debian/module/debian/patches/conftest-verbose.patch
  |  21 +-
 debian/module/debian/patches/fragile-ARCH.patch
  |  36 +++
 debian/module/debian/patches/ppc64el.patch 
  |  19 ++
 debian/module/debian/patches/series.in 
  |   7 +-
 debian/module/debian/patches/use-kbuild-compiler.patch 
  |  11 +
 debian/module/debian/rules.in  
  |  23 +-
 debian/nvidia-alternative.postinst.in  
  |   8 +-
 debian/nvidia-kernel-dkms.dkms.in  
  |   2 +-
 debian/nvidia-kernel-source.README.Debian.in   
  |   8 +-
 debian/nvidia-kernel-source.install.in 
  | 

Bug#1025650: ftp.debian.org: Nmap Public Source License Version 0.94 - Is it DFSG-compliant?

[Samuel Henrique]

Package: ftp.debian.org
X-Debbugs-Cc: samuel...@debian.org
Severity: serious
Justification: Policy 2.1

Hello ftp-master team,

I'm opening this bug to request an official position of the team on
whether the NPSL license meets the DFSG requirements or not.

There's some divergence of opinions on the matter and I think the only
next step is to get an evaluation from the ftp-master team. FWIW I'm
currently on the opinion that the license should be considered free
due to its similarity with GPL2 (and copyleft licenses in general) but
Hilko (the other maintainer) is on the side of considering it non-free
due to a contamination issue. Sorry if I'm oversimplifying here,
Hilko. Both mine and Hilko's points are better written in the
references below.

Related discussions:
Thread on d-legal:
https://lists.debian.org/debian-legal/2022/09/msg0.html
Upstream discussion:
https://github.com/nmap/nmap/issues/2199

Please consider that upstream is usually quite responsive in that
Github issue and so we can make follow-up questions.

We need to make a decision to understand if the current nmap we are
shipping (in all our supported releases[0]) is DFSG-free or not. This
decision should be done ideally before the freeze so we can take any
required actions.

Thank you,

[0] At least one issue that I've seen raised is present in all
versions of nmap we ship (since the first iteration of NPSL), which
would mean even our package in oldstable and stable is non-free.

-- 
Samuel Henrique 

Bug#1025335: ansible-core: autopkgtests need to depend on python3-pytest-forked

[Scott Talbert]

On December 2, 2022 2:54:19 PM EST, Lee Garrett  wrote:
>On 02/12/2022 19:15, Scott Talbert wrote:
>> Source: ansible-core
>> Version: 2.14.0-1
>> Severity: important
>> 
>> ansible-core's autopkgtests need to add a Depends on python3-pytest-forked.
>> 
>> python3-pytest-xdist used to depend on -forked, but it no longer does.
>> 
>> See, for example:
>> https://ci.debian.net/data/autopkgtest/testing/amd64/a/ansible-core/28872265/log.gz
>
>Thanks! Will update it in the next release.

Also, ansible needs to same update.  If you could make these updates in the 
relatively short term it would be appreciated.  pytest-xdist can't migrate 
otherwise.

Thanks,
Scott

Bug#1025649: Acknowledgement (love: undefined symbol: PHYSFS_getSearchPath)

[Přemysl Vyhnal]

More information from love forums user pgimeno:

> [the example program provided above] works fine in my self-compiled Löve,
but in my case `nm -D /path/to/love | grep PHYSFS_unmount` displays one
result while on the Debian package version it doesn't.

On Tue, Dec 6, 2022 at 10:33 PM Debian Bug Tracking System <
ow...@bugs.debian.org> wrote:

> Thank you for filing a new Bug report with Debian.
>
> You can follow progress on this Bug here: 1025649:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1025649.
>
> This is an automatically generated reply to let you know your message
> has been received.
>
> Your message is being forwarded to the package maintainers and other
> interested parties for their attention; they will reply in due course.
>
> As you requested using X-Debbugs-CC, your message was also forwarded to
>   premysl.vyhnal+bugrep...@gmail.com
> (after having been given a Bug report number, if it did not have one).
>
> Your message has been sent to the package maintainer(s):
>  Debian Games Team 
>
> If you wish to submit further information on this problem, please
> send it to 1025...@bugs.debian.org.
>
> Please do not send mail to ow...@bugs.debian.org unless you wish
> to report a problem with the Bug-tracking system.
>
> --
> 1025649: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1025649
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>

Bug#1023550: transition: qcustomplot

[Sebastian Ramacher]

Hi Filippo

On 2022-12-01 17:55:42 +, Sudip Mukherjee wrote:
> Hi Filippo,
> 
> On Thu, Nov 24, 2022 at 09:59:49PM +0100, Filippo Rusconi wrote:
> > Greetings Sebastian,
> > 
> > On Thu, Nov 24, 2022 at 09:05:07PM +0100, Sebastian Ramacher wrote:
> > > Hi Filippo
> > 
> > [...]
> > 
> > > > > Thanks! Please go ahead with the transition.
> > > > 
> > > > I just uploaded the package to unstable. I have not closed the bug yet, 
> > > > waiting
> > > > to check that everything goes fine.
> > > 
> > > qcustomplot's autopkgtests are failing. Could you please take a look at
> > > them? Thanks
> > 
> > It is weeks that I monitor the salsa stuff, but I do not understand what 
> > these
> > tests mean. One example (bear with me):
> 
> The failures are because cmake could not find the library and so the
> variable 'QCustomPlot_LIBRARIES' was empty and so while linking it did not
> ask 'ld' to link with libqcustomplot. Please dont ask why.
> Try the attached patch which will explicitely ask cmake to find the library
> and save it to the variable. It worked in my schroot.

Are there any news regarding the autopkgtest regression?

Cheers

> 
> 
> -- 
> Regards
> Sudip

> diff -Nru qcustomplot-2.1.0+dfsg1/debian/changelog 
> qcustomplot-2.1.0+dfsg1/debian/changelog
> --- qcustomplot-2.1.0+dfsg1/debian/changelog  2022-11-25 10:01:09.0 
> +
> +++ qcustomplot-2.1.0+dfsg1/debian/changelog  2022-12-01 17:36:10.0 
> +
> @@ -1,3 +1,10 @@
> +qcustomplot (2.1.0+dfsg1-3.1) unstable; urgency=medium
> +
> +  * Non-maintainer upload.
> +  * Fix autopkgtest.
> +
> + -- Sudip Mukherjee   Thu, 01 Dec 2022 17:36:10 
> +
> +
>  qcustomplot (2.1.0+dfsg1-3) unstable; urgency=low
>  
>* Fix the autopkgtest by fixing the dependencies of libqcustomplot-dev: 
> when
> diff -Nru qcustomplot-2.1.0+dfsg1/debian/tests/buildtest-axis 
> qcustomplot-2.1.0+dfsg1/debian/tests/buildtest-axis
> --- qcustomplot-2.1.0+dfsg1/debian/tests/buildtest-axis   2022-11-25 
> 10:01:09.0 +
> +++ qcustomplot-2.1.0+dfsg1/debian/tests/buildtest-axis   2022-12-01 
> 16:27:01.0 +
> @@ -19,6 +19,7 @@
>  
>  FIND_PACKAGE(QCustomPlot REQUIRED)
>  FIND_PACKAGE(Qt5PrintSupport REQUIRED)
> +find_library(QCustomPlot_LIBRARIES QCustomPlot REQUIRED)
>  set(CMAKE_MODULE_PATH "\${CMAKE_CURRENT_SOURCE_DIR}/cMake")
>  
>  set(CMAKE_AUTOMOC ON)
> diff -Nru qcustomplot-2.1.0+dfsg1/debian/tests/buildtest-inter 
> qcustomplot-2.1.0+dfsg1/debian/tests/buildtest-inter
> --- qcustomplot-2.1.0+dfsg1/debian/tests/buildtest-inter  2022-11-25 
> 10:01:09.0 +
> +++ qcustomplot-2.1.0+dfsg1/debian/tests/buildtest-inter  2022-12-01 
> 17:26:26.0 +
> @@ -19,6 +19,7 @@
>  
>  FIND_PACKAGE(QCustomPlot REQUIRED)
>  FIND_PACKAGE(Qt5PrintSupport REQUIRED)
> +find_library(QCustomPlot_LIBRARIES QCustomPlot REQUIRED)
>  set(CMAKE_MODULE_PATH "\${CMAKE_CURRENT_SOURCE_DIR}/cMake")
>  
>  set(CMAKE_AUTOMOC ON)
> diff -Nru qcustomplot-2.1.0+dfsg1/debian/tests/buildtest-plot 
> qcustomplot-2.1.0+dfsg1/debian/tests/buildtest-plot
> --- qcustomplot-2.1.0+dfsg1/debian/tests/buildtest-plot   2022-11-25 
> 10:01:09.0 +
> +++ qcustomplot-2.1.0+dfsg1/debian/tests/buildtest-plot   2022-12-01 
> 17:26:40.0 +
> @@ -19,6 +19,7 @@
>  
>  FIND_PACKAGE(QCustomPlot REQUIRED)
>  FIND_PACKAGE(Qt5PrintSupport REQUIRED)
> +find_library(QCustomPlot_LIBRARIES QCustomPlot REQUIRED)
>  set(CMAKE_MODULE_PATH "\${CMAKE_CURRENT_SOURCE_DIR}/cMake")
>  
>  set(CMAKE_AUTOMOC ON)
> diff -Nru qcustomplot-2.1.0+dfsg1/debian/tests/buildtest-scroll 
> qcustomplot-2.1.0+dfsg1/debian/tests/buildtest-scroll
> --- qcustomplot-2.1.0+dfsg1/debian/tests/buildtest-scroll 2022-11-25 
> 10:01:09.0 +
> +++ qcustomplot-2.1.0+dfsg1/debian/tests/buildtest-scroll 2022-12-01 
> 17:26:50.0 +
> @@ -19,6 +19,7 @@
>  
>  FIND_PACKAGE(QCustomPlot REQUIRED)
>  FIND_PACKAGE(Qt5PrintSupport REQUIRED)
> +find_library(QCustomPlot_LIBRARIES QCustomPlot REQUIRED)
>  set(CMAKE_MODULE_PATH "\${CMAKE_CURRENT_SOURCE_DIR}/cMake")
>  
>  set(CMAKE_AUTOMOC ON)
> diff -Nru qcustomplot-2.1.0+dfsg1/debian/tests/buildtest-text 
> qcustomplot-2.1.0+dfsg1/debian/tests/buildtest-text
> --- qcustomplot-2.1.0+dfsg1/debian/tests/buildtest-text   2022-11-25 
> 10:01:09.0 +
> +++ qcustomplot-2.1.0+dfsg1/debian/tests/buildtest-text   2022-12-01 
> 17:27:05.0 +
> @@ -19,6 +19,7 @@
>  
>  FIND_PACKAGE(QCustomPlot REQUIRED)
>  FIND_PACKAGE(Qt5PrintSupport REQUIRED)
> +find_library(QCustomPlot_LIBRARIES QCustomPlot REQUIRED)
>  set(CMAKE_MODULE_PATH "\${CMAKE_CURRENT_SOURCE_DIR}/cMake")
>  
>  set(CMAKE_AUTOMOC ON)
> diff -Nru qcustomplot-2.1.0+dfsg1/debian/tests/control 
> qcustomplot-2.1.0+dfsg1/debian/tests/control
> --- qcustomplot-2.1.0+dfsg1/debian/tests/control  2022-11-25 
> 10:01:09.0 +
> +++ qcustomplot-2.1.0+dfsg1/debian/tests/control  2022-12-01 
> 17:35:46.0 

Bug#1025326: tigervnc-standalone-server: tigervnc-standalone-server: Upgrade of libgl1-mesa-dri to 22.3.0 breaks Xvnc

[Agustin Martin]

El lun, 5 dic 2022 a las 13:40, Agustin Martin () escribió:
>
> Hi,
>
> Looking at
>
> https://bugs.debian.org/1025312 [libgl1-mesa-dri: multiple packages
> FTBFS and have autopkgtest regressions running test programs under
> Xvfb] I noticed that this #1025326 bug report is mentioned as a
> possible duplicate of #1025312.

This should be fixed in libgl1-mesa-dri 22.3.0-2, already in sid. Please check.

Thanks,

-- 
Agustin

Bug#1025649: love: undefined symbol: PHYSFS_getSearchPath

[Premek]

Package: love
Version: 11.4-1
Severity: normal
X-Debbugs-Cc: premysl.vyhnal+bugrep...@gmail.com

Some love programs using FFI crash with the error message below.

$ cat main.lua
local ffi = require'ffi'
ffi.cdef("bool PHYSFS_unmount(const char *path);")
ffi.C.PHYSFS_unmount("xyz")

$ love .
Error: main.lua:3: /lib/x86_64-linux-gnu/libluajit-5.1.so.2: undefined symbol:
PHYSFS_unmount
stack traceback:
[love "boot.lua"]:345: in function <[love "boot.lua"]:341>
[C]: in function '__index'
main.lua:3: in main chunk
[C]: in function 'require'
[love "boot.lua"]:316: in function <[love "boot.lua"]:126>
[C]: in function 'xpcall'
[love "boot.lua"]:355: in function <[love "boot.lua"]:348>
[C]: in function 'xpcall'

Running the same program with love compiled from source does not print any
error.

More information:
https://love2d.org/forums/viewtopic.php?p=251062=4ce1bbcbc945046797d8d2112efb2e00#p251062



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

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

Versions of packages love depends on:
ii  libc62.35-4
ii  libfreetype6 2.10.4+dfsg-1+deb11u1
ii  libgcc-s112.2.0-3
ii  libluajit-5.1-2  2.1.0~beta3+dfsg-5.3
ii  libmodplug1  1:0.8.9.0-3
ii  libmpg123-0  1.31.1-1
ii  libogg0  1.3.4-0.1
ii  libopenal1   1:1.19.1-2
ii  libsdl2-2.0-02.24.2+dfsg-1
ii  libstdc++6   12.2.0-3
ii  libtheora0   1.1.1+dfsg.1-15
ii  libvorbisfile3   1.3.7-1
ii  zlib1g   1:1.2.11.dfsg-2+deb11u2

Versions of packages love recommends:
ii  binfmt-support  2.2.1-1
ii  systemd 247.3-7+deb11u1

love suggests no packages.

Bug#1016359: more info

[Thorsten Glaser]

Hi dann,

>OK, then I think there may be multiple conflated issues here. Let's
>focus on the original use case you described - a VM created with
>virt-manager using a SCSI controller doesn't work. You tried

Nonono, not quite.

The original use case: an *EFI* VM with a SCSI controller does not
work. This is what I reported.

>I just tried this on latest sid, and was able to reproduce. "lsilogic"
>does indeed not work.

Oh, interesting. That’s got to be a new/different bug. We were on
bullseye, not sid, in case that helps.

>I also didn't find a way to tell virt-manager to use anything other
>that "lsilogic". But, when I edited the XML and changed "lsilogic" to
>"virtio-scsi" (and ran virsh define), the system booted fine.

Yeah well virt-manager… it does have an XML editor built in, but
sometimes…

I did just test a BIOS case: I took an existing VM I had but was
not using (an OpenBSD VM), dropped the IDE disc, added an lsilogic
SCSI controller, added a SCSI disc with the same backing LV that
the IDE disc had, booted it, and it works. Also on bullseye.

>Thorsten - do you have reason that you prefer lsilogic to virtio-scsi?

Yes: I mostly run operating systems with no or insufficient support
for virtio over the hypervisor interface. (There’s also virtio over
PCI, but my inquiries to the qemu developers how to even access this
led to them eventually agreeing it probably isn’t even implemented
fully yet.)

In the specific case, it was a VM “appliance” imported from some
other virtualisation tools that had a preconfigured Windows, and
the other VM hosts all use lsilogic for that.

>Now, Vincent me too'd this bug to say that virtio-scsi wasn't working
>for them, but the version in bullseye did work. Thorsten reported
>using the version of ovmf that *is* in bullseye and wasn't using
>virtio-scsi. So whatever Vincent is/was seeing seems like a separate
>issue. If you are still having a problem Vincent, please report a
>separate issue.

I’m not too sure about this either.

I also had a grml-efi VM lying around, which incidentally already
had a virtio-scsi configured, so I did the same thing: drop the
SATA CD, re-add it as an SCSI HDD, change the boot order, start.
It switches from “the guest has not initialised the display yet”
to “viewer was disconnected” very quickly. (I also did a test
with the NIC in the boot order enabled, and it does netboot, so
the problem is with, again, SCSI.)

So I can state, with reasonable confidence, that EFI booting in
bullseye works with neither lsilogic nor virtio-scsi. This makes
it mostly unsuitable for running most Windows VMs.

bye,
//mirabilos
-- 
21:12⎜ sogar bei opensolaris haben die von der community so
ziemlich jeden mist eingebaut │ man sollte unices nich so machen das
desktopuser zuviel intresse kriegen │ das macht die code base kaputt
21:13⎜ linux war früher auch mal besser :D

Bug#1025646: bullseye-pu: package libapache2-mod-auth-mellon/0.17.0-1+deb11u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Tue, 2022-12-06 at 21:11 +0100, Thijs Kinkhorst wrote:
> I propose this upload to bullseye to fix a relatively minor security
> issue
> (open redirect) in libapache2-mod-auth-mellon.
> 

Please go ahead.

Regards,

Adam

Bug#937049: mini-buildd: Python2 removal in sid/bullseye

[Stephan Sürken]

Hi Bastian,

On Tue, 2022-11-29 at 21:09 +0100, Bastian Germann wrote:
> Why don't you move the experimental to unstable now?

well, some crucial tests (especially on upgrading) are unfortunately
still pending.

Uploading to unstable always marked "ok to use" in that respect, however...

> The unstable mini.buildd version is not usable but is now the last reverse 
> dependency of python-setuptools
> (sphinx and nuitka only have it as optional alternatives).

as it seems to cause big pain elsewhere, I will prepare the next upload
(within "days" ;) for unstable (with a blocking RC bug if need be).

Hth!

S


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

Bug#1013356: fzf: Bash completions not active by default

[Bastian Venthur]

Package: fzf
Version: 0.35.1-1
Followup-For: Bug #1013356
X-Debbugs-Cc: vent...@debian.org

I can confirm that this issue still exists, bash completion is only available
after you did:

fzf 


Cheers,

Bastian




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

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

-- no debconf information

Bug#1025648: cacti: CVE-2022-46169: Unauthenticated Command Injection

[Salvatore Bonaccorso]

Source: cacti
Version: 1.2.22+ds1-2
Severity: grave
Tags: security upstream
Justification: user security hole
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for cacti.

CVE-2022-46169[0]:
| Cacti is an open source platform which provides a robust and
| extensible operational monitoring and fault management framework for
| users. In affected versions a command injection vulnerability allows
| an unauthenticated user to execute arbitrary code on a server running
| Cacti, if a specific data source was selected for any monitored
| device. The vulnerability resides in the `remote_agent.php` file. This
| file can be accessed without authentication. This function retrieves
| the IP address of the client via `get_client_addr` and resolves this
| IP address to the corresponding hostname via `gethostbyaddr`. After
| this, it is verified that an entry within the `poller` table exists,
| where the hostname corresponds to the resolved hostname. If such an
| entry was found, the function returns `true` and the client is
| authorized. This authorization can be bypassed due to the
| implementation of the `get_client_addr` function. The function is
| defined in the file `lib/functions.php` and checks serval `$_SERVER`
| variables to determine the IP address of the client. The variables
| beginning with `HTTP_` can be arbitrarily set by an attacker. Since
| there is a default entry in the `poller` table with the hostname of
| the server running Cacti, an attacker can bypass the authentication
| e.g. by providing the header `Forwarded-For: TARGETIP`. This
| way the function `get_client_addr` returns the IP address of the
| server running Cacti. The following call to `gethostbyaddr` will
| resolve this IP address to the hostname of the server, which will pass
| the `poller` hostname check because of the default entry. After the
| authorization of the `remote_agent.php` file is bypassed, an attacker
| can trigger different actions. One of these actions is called
| `polldata`. The called function `poll_for_data` retrieves a few
| request parameters and loads the corresponding `poller_item` entries
| from the database. If the `action` of a `poller_item` equals
| `POLLER_ACTION_SCRIPT_PHP`, the function `proc_open` is used to
| execute a PHP script. The attacker-controlled parameter `$poller_id`
| is retrieved via the function `get_nfilter_request_var`, which allows
| arbitrary strings. This variable is later inserted into the string
| passed to `proc_open`, which leads to a command injection
| vulnerability. By e.g. providing the `poller_id=;id` the `id` command
| is executed. In order to reach the vulnerable call, the attacker must
| provide a `host_id` and `local_data_id`, where the `action` of the
| corresponding `poller_item` is set to `POLLER_ACTION_SCRIPT_PHP`. Both
| of these ids (`host_id` and `local_data_id`) can easily be
| bruteforced. The only requirement is that a `poller_item` with an
| `POLLER_ACTION_SCRIPT_PHP` action exists. This is very likely on a
| productive instance because this action is added by some predefined
| templates like `Device - Uptime` or `Device - Polling Time`. This
| command injection vulnerability allows an unauthenticated user to
| execute arbitrary commands if a `poller_item` with the `action` type
| `POLLER_ACTION_SCRIPT_PHP` (`2`) is configured. The authorization
| bypass should be prevented by not allowing an attacker to make
| `get_client_addr` (file `lib/functions.php`) return an arbitrary IP
| address. This could be done by not honoring the `HTTP_...` `$_SERVER`
| variables. If these should be kept for compatibility reasons it should
| at least be prevented to fake the IP address of the server running
| Cacti. This vulnerability has been addressed in both the 1.2.x and
| 1.3.x release branches with `1.2.23` being the first release
| containing the patch.


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-2022-46169
https://www.cve.org/CVERecord?id=CVE-2022-46169
[1] https://github.com/Cacti/cacti/security/advisories/GHSA-6p93-p743-35gf

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1025644: lintian: should not have the update-debian-copyright tag at all

[Louis-Philippe Véronneau]

On 2022-12-06 15 h 13, Russ Allbery wrote:

Thorsten Glaser  writes:


The update-debian-copyright tag gives bad advice:



N:   The most recent copyright year mentioned for files in ./debian lags
N:   behind the year in the timestamp for the most recent changelog
N:   entry.



This is a fully normal thing to have. You only update the copyright year
for something when *you* do something relevant for copyright law (that
is passing the threshold of originality) in that year.



Having this tag is misleading because it’ll lead to people bumping the
year because they don’t know better and just to silence lintian.


Yeah, and I'm also dubious that we should be telling people how to manage
their copyright notices at all.  Berne explicitly doesn't require
copyright notices.  Some licenses require them, but I'm not aware of a
license where one is required to update them with new years.  Some
projects use the approach of only updating the years when the files are
changed; others update all years on all files every year (the FSF does
this, for instance, based on legal advice from their lawyers).

This doesn't feel like something Lintian should have an opinion about.



I also agree with your reasoning and I would personally be for its 
removal. I think we should note this was a feature requested in #949201.


As such, I've proposed a MR to make this tag experimental for now. I 
guess if people care about it, they can try to improve it?


https://salsa.debian.org/lintian/lintian/-/merge_requests/431

--
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄



OpenPGP_0xE1E5457C8BAD4113.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1016359: more info

[dann frazier]

On Tue, Dec 06, 2022 at 07:25:27PM +, Thorsten Glaser wrote:
> Hi dann,
> 
> >  Could you confirm the last version that worked for you - perhaps
> 
> I have never booted an EFI system before; this VM was the first
> time for me, so I do not have a “last version” either way.
> 
> As I said, this does work with BIOS (or at least used to).

OK, then I think there may be multiple conflated issues here. Let's
focus on the original use case you described - a VM created with
virt-manager using a SCSI controller doesn't work. You tried
"lsilogic", but you assume based on a RH report that "virtio-scsi"
also does not work.

I just tried this on latest sid, and was able to reproduce. "lsilogic"
does indeed not work. I also didn't find a way to tell virt-manager to
use anything other that "lsilogic". But, when I edited the XML and
changed "lsilogic" to "virtio-scsi" (and ran virsh define), the system
booted fine.

Thorsten - do you have reason that you prefer lsilogic to virtio-scsi?
If not, I suggest just using virtio-scsi. I don't know why
virt-manager defaults to that - even virt-install seems to default to
virtio-scsi. I suggest someone take that up w/ the virt-manager
maintainer(s).

Now, Vincent me too'd this bug to say that virtio-scsi wasn't working
for them, but the version in bullseye did work. Thorsten reported
using the version of ovmf that *is* in bullseye and wasn't using
virtio-scsi. So whatever Vincent is/was seeing seems like a separate
issue. If you are still having a problem Vincent, please report a
separate issue.

  -dann

Bug#1007836: python-catalogue_2.1.0-1_amd64.changes REJECTED

[Andreas Tille]

Hi Thorsten,

Am Mon, Dec 05, 2022 at 07:04:38PM + schrieb Thorsten Alteholz:
> please mention the Apache license in your debian/copyright.

Fixed in new upload.

Thanks for checking
   Andreas. 

-- 
http://fam-tille.de

Bug#1025493: firefox crashes instantly at start

[VA]

Le 06/12/2022 à 19:37, Felix Zielcke a écrit :

I have exactly the same problem since Mesa 22.3.0 was uploaded to
unstable.
Downgrading all src:mesa packages to version 22.2.4 from testing fixes
this for me.
I've got a Nvidia graphic card and use the Nvidia driver packages from
Debian. It doestn't matter at all if nvidia-vaapi-driver is installed
or removed/purged.


Seems mesa 22.3.0-2 fixed the problem for me. What about you?
Maybe it was https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1025312

Bug#1025647: buster-pu: package libapache2-mod-auth-mellon/0.14.2-1+deb10u1

[Thijs Kinkhorst]

Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu

Hi,

I propose this upload to buster to fix a relatively minor security issue
(open redirect) in libapache2-mod-auth-mellon.

The changes are already in sid and bookworm for a longer time, and in
bullseye for the first part.


Cheers,
Thijs
diff -Nru libapache2-mod-auth-mellon-0.14.2/debian/changelog 
libapache2-mod-auth-mellon-0.14.2/debian/changelog
--- libapache2-mod-auth-mellon-0.14.2/debian/changelog  2019-03-22 
12:10:11.0 +
+++ libapache2-mod-auth-mellon-0.14.2/debian/changelog  2022-12-06 
15:39:13.0 +
@@ -1,3 +1,10 @@
+libapache2-mod-auth-mellon (0.14.2-1+deb10u1) buster; urgency=high
+
+  * Upload to fix security issues:
+- Open redirect in logout endpoint (CVE-2019-13038 CVE-2021-3639)
+
+ -- Thijs Kinkhorst   Tue, 06 Dec 2022 15:39:13 +
+
 libapache2-mod-auth-mellon (0.14.2-1) unstable; urgency=high
 
   * New upstream security release. (closes: #925197)
diff -Nru libapache2-mod-auth-mellon-0.14.2/debian/patches/CVE-2019-13038.patch 
libapache2-mod-auth-mellon-0.14.2/debian/patches/CVE-2019-13038.patch
--- libapache2-mod-auth-mellon-0.14.2/debian/patches/CVE-2019-13038.patch   
1970-01-01 00:00:00.0 +
+++ libapache2-mod-auth-mellon-0.14.2/debian/patches/CVE-2019-13038.patch   
2022-12-06 15:36:36.0 +
@@ -0,0 +1,29 @@
+From a52645391d08739a6a96df21e2506d3e57b888dc Mon Sep 17 00:00:00 2001
+From: Valentin 
+Date: Fri, 6 Sep 2019 13:30:36 +0300
+Subject: [PATCH] Fix open redirect CVE-2019-13038
+
+Resolves:
+https://github.com/latchset/mod_auth_mellon/issues/2
+
+The original reported redirect attack was:
+https://application.com/mellon/login?ReturnTo=http:www.malicious.com
+---
+ auth_mellon_util.c | 4 
+ 1 file changed, 4 insertions(+)
+
+diff --git a/auth_mellon_util.c b/auth_mellon_util.c
+index fd442f9..e53a98f 100644
+--- a/auth_mellon_util.c
 b/auth_mellon_util.c
+@@ -116,6 +116,10 @@ int am_validate_redirect_url(request_rec *r, const char 
*url)
+ 
+ /* Sanity check of the scheme of the domain. We only allow http and 
https. */
+ if (uri.scheme) {
++/* http and https schemes without hostname are invalid. */
++if (!uri.hostname) {
++return HTTP_BAD_REQUEST;
++}
+ if (strcasecmp(uri.scheme, "http")
+ && strcasecmp(uri.scheme, "https")) {
+ AM_LOG_RERROR(APLOG_MARK, APLOG_ERR, 0, r,
diff -Nru libapache2-mod-auth-mellon-0.14.2/debian/patches/CVE-2021-3639.patch 
libapache2-mod-auth-mellon-0.14.2/debian/patches/CVE-2021-3639.patch
--- libapache2-mod-auth-mellon-0.14.2/debian/patches/CVE-2021-3639.patch
1970-01-01 00:00:00.0 +
+++ libapache2-mod-auth-mellon-0.14.2/debian/patches/CVE-2021-3639.patch
2022-12-06 15:38:26.0 +
@@ -0,0 +1,44 @@
+From 42a11261b9dad2e48d70bdff7c53dd57a12db6f5 Mon Sep 17 00:00:00 2001
+From: AIMOTO Norihito 
+Date: Tue, 6 Jul 2021 22:57:24 +0200
+Subject: [PATCH] Prevent redirect to URLs that begin with '///'
+
+Visiting a logout URL like this:
+
https://rp.example.co.jp/mellon/logout?ReturnTo=///fishing-site.example.com/logout.html
+would have redirected the user to fishing-site.example.com
+
+With the patch, this URL would be rejected.
+
+Fixes: CVE-2021-3639
+---
+ auth_mellon_util.c | 10 ++
+ 1 file changed, 10 insertions(+)
+
+diff --git a/auth_mellon_util.c b/auth_mellon_util.c
+index 2f8c9c3..6a686db 100644
+--- a/auth_mellon_util.c
 b/auth_mellon_util.c
+@@ -927,6 +927,10 @@ int am_check_url(request_rec *r, const char *url)
+ {
+ const char *i;
+ 
++if (url == NULL) {
++return HTTP_BAD_REQUEST;
++}
++
+ for (i = url; *i; i++) {
+ if (*i >= 0 && *i < ' ') {
+ /* Deny all control-characters. */
+@@ -943,6 +947,12 @@ int am_check_url(request_rec *r, const char *url)
+ }
+ }
+ 
++if (strstr(url, "///") == url) {
++AM_LOG_RERROR(APLOG_MARK, APLOG_ERR, HTTP_BAD_REQUEST, r,
++  "URL starts with '///'");
++return HTTP_BAD_REQUEST;
++}
++
+ return OK;
+ }
+ 
diff -Nru libapache2-mod-auth-mellon-0.14.2/debian/patches/series 
libapache2-mod-auth-mellon-0.14.2/debian/patches/series
--- libapache2-mod-auth-mellon-0.14.2/debian/patches/series 2018-01-06 
12:58:18.0 +
+++ libapache2-mod-auth-mellon-0.14.2/debian/patches/series 2022-12-06 
15:39:01.0 +
@@ -0,0 +1,2 @@
+CVE-2019-13038.patch
+CVE-2021-3639.patch

Bug#1025646: bullseye-pu: package libapache2-mod-auth-mellon/0.17.0-1+deb11u1

[Thijs Kinkhorst]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu

Hi,

I propose this upload to bullseye to fix a relatively minor security issue
(open redirect) in libapache2-mod-auth-mellon.

The changes are already in sid and bookworm for a longer time.


Cheers,
Thijs
diff -Nru libapache2-mod-auth-mellon-0.17.0/debian/changelog 
libapache2-mod-auth-mellon-0.17.0/debian/changelog
--- libapache2-mod-auth-mellon-0.17.0/debian/changelog  2020-09-08 
12:56:41.0 +0200
+++ libapache2-mod-auth-mellon-0.17.0/debian/changelog  2022-12-06 
20:12:37.0 +0100
@@ -1,3 +1,10 @@
+libapache2-mod-auth-mellon (0.17.0-1+deb11u1) bullseye; urgency=medium
+
+  * Upload to fix security issue:
+- Open redirect in logout endpoint (CVE-2021-3639)
+
+ -- Thijs Kinkhorst   Tue, 06 Dec 2022 20:12:37 +0100
+
 libapache2-mod-auth-mellon (0.17.0-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru libapache2-mod-auth-mellon-0.17.0/debian/patches/CVE-2021-3639.patch 
libapache2-mod-auth-mellon-0.17.0/debian/patches/CVE-2021-3639.patch
--- libapache2-mod-auth-mellon-0.17.0/debian/patches/CVE-2021-3639.patch
1970-01-01 01:00:00.0 +0100
+++ libapache2-mod-auth-mellon-0.17.0/debian/patches/CVE-2021-3639.patch
2022-12-06 20:12:37.0 +0100
@@ -0,0 +1,44 @@
+From 42a11261b9dad2e48d70bdff7c53dd57a12db6f5 Mon Sep 17 00:00:00 2001
+From: AIMOTO Norihito 
+Date: Tue, 6 Jul 2021 22:57:24 +0200
+Subject: [PATCH] Prevent redirect to URLs that begin with '///'
+
+Visiting a logout URL like this:
+
https://rp.example.co.jp/mellon/logout?ReturnTo=///fishing-site.example.com/logout.html
+would have redirected the user to fishing-site.example.com
+
+With the patch, this URL would be rejected.
+
+Fixes: CVE-2021-3639
+---
+ auth_mellon_util.c | 10 ++
+ 1 file changed, 10 insertions(+)
+
+diff --git a/auth_mellon_util.c b/auth_mellon_util.c
+index 2f8c9c3..6a686db 100644
+--- a/auth_mellon_util.c
 b/auth_mellon_util.c
+@@ -927,6 +927,10 @@ int am_check_url(request_rec *r, const char *url)
+ {
+ const char *i;
+ 
++if (url == NULL) {
++return HTTP_BAD_REQUEST;
++}
++
+ for (i = url; *i; i++) {
+ if (*i >= 0 && *i < ' ') {
+ /* Deny all control-characters. */
+@@ -943,6 +947,12 @@ int am_check_url(request_rec *r, const char *url)
+ }
+ }
+ 
++if (strstr(url, "///") == url) {
++AM_LOG_RERROR(APLOG_MARK, APLOG_ERR, HTTP_BAD_REQUEST, r,
++  "URL starts with '///'");
++return HTTP_BAD_REQUEST;
++}
++
+ return OK;
+ }
+ 
diff -Nru libapache2-mod-auth-mellon-0.17.0/debian/patches/series 
libapache2-mod-auth-mellon-0.17.0/debian/patches/series
--- libapache2-mod-auth-mellon-0.17.0/debian/patches/series 2020-01-27 
14:32:39.0 +0100
+++ libapache2-mod-auth-mellon-0.17.0/debian/patches/series 2022-12-06 
20:12:37.0 +0100
@@ -0,0 +1 @@
+CVE-2021-3639.patch

Bug#1025644: lintian: should not have the update-debian-copyright tag at all

[Russ Allbery]

Thorsten Glaser  writes:

> The update-debian-copyright tag gives bad advice:

> N:   The most recent copyright year mentioned for files in ./debian lags
> N:   behind the year in the timestamp for the most recent changelog
> N:   entry.

> This is a fully normal thing to have. You only update the copyright year
> for something when *you* do something relevant for copyright law (that
> is passing the threshold of originality) in that year.

> Having this tag is misleading because it’ll lead to people bumping the
> year because they don’t know better and just to silence lintian.

Yeah, and I'm also dubious that we should be telling people how to manage
their copyright notices at all.  Berne explicitly doesn't require
copyright notices.  Some licenses require them, but I'm not aware of a
license where one is required to update them with new years.  Some
projects use the approach of only updating the years when the files are
changed; others update all years on all files every year (the FSF does
this, for instance, based on legal advice from their lawyers).

This doesn't feel like something Lintian should have an opinion about.

-- 
Russ Allbery (r...@debian.org)  

Bug#1025645: prelude-manager: Get error when trying to configure

[Tim McConnell]

Package: prelude-manager
Version: 5.2.0-2+b1
Severity: normal

Dear Maintainer,

I get this error when I try to run 'dpkg-reconfigure prelude-manager'
Configuring prelude-manager ├──┐
  │   
│
  │ An error occurred while installing the database:
  │
  │ ERROR 2002 (HY000): Can't connect to local server through socket
  │ '/run/mysqld/mysqld.sock' (111) . Your options are:
  │  * abort - Causes the operation to fail; you will need to
downgrade,
  │reinstall, reconfigure this package, or otherwise manually
intervene
  │to continue using it. This will usually also impact your ability
to
  │install other packages until the installation failure is
resolved.
  │  * retry - Prompts once more with all the configuration questions
  │(including ones you may have missed due to the debconf priority
  │setting) and makes another attempt at performing the operation.
  │  * retry (skip questions) - Immediately attempts the operation
again,
  │skipping all questions. This is normally useful only if you have
  │solved the underlying problem since the time the error occurred.
  │

and regardless of the option I try (other than abort) it fails. I'm
unsure what
to try to resolve this.


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

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

Versions of packages prelude-manager depends on:
ii  adduser3.129
ii  dbconfig-common2.0.22
ii  debconf [debconf-2.0]  1.5.80
ii  libc6  2.36-6
ii  libgnutls303.7.8-4
ii  libmaxminddb0  1.5.2-1
ii  libprelude28   5.2.0-5+b5
ii  libpreludedb7  5.2.0-2+b3
ii  libsnmp40  5.9.3+dfsg-1+b2
ii  libxml22.9.14+dfsg-1.1+b2
ii  ucf3.0043

Versions of packages prelude-manager recommends:
ii  default-mysql-client  1.0.8

prelude-manager suggests no packages.

-- debconf information:
  prelude-manager/mysql/method: Unix socket
  prelude-manager/db/app-user: prelude@localhost
  prelude-manager/remote/port: 3306
  prelude-manager/dbconfig-remove: true
  prelude-manager/dbconfig-reinstall: false
  prelude-manager/missing-db-package-error: abort
  prelude-manager/install-error: abort
  prelude-manager/database-type: mysql
  prelude-manager/internal/skip-preseed: false
* prelude-manager/dbconfig-install: false
  prelude-manager/dbconfig-upgrade: true
  prelude-manager/db/dbname: prelude
  prelude-manager/remote/host: localhost
  prelude-manager/upgrade-backup: true
  prelude-manager/mysql/authplugin: default
  prelude-manager/passwords-do-not-match:
  prelude-manager/internal/reconfiguring: false
  prelude-manager/purge: false
  prelude-manager/remove-error: abort
* prelude-manager/mysql/admin-user: root
  prelude-manager/upgrade-error: abort
  prelude-manager/remote/newhost:

Bug#1022565: file: [regression] OpenPGP file MIME type reverted to application/octet-stream

[Christoph Biedl]

Control: forwarded 1022565 
https://mailman.astron.com/pipermail/file/2022-December/000995.html

Paul Wise wrote...

> The detected MIME type of OpenPGP files is now application/octet-stream:

Ups. That's clearly a regression, and a rather weird one. Sent to upstream.

Christoph


signature.asc
Description: PGP signature

Bug#1025644: lintian: should not have the update-debian-copyright tag at all

[Thorsten Glaser]

Package: lintian
Version: 2.115.3
Severity: normal
X-Debbugs-Cc: t...@mirbsd.de

The update-debian-copyright tag gives bad advice:

N:   The most recent copyright year mentioned for files in ./debian lags behind
N:   the year in the timestamp for the most recent changelog entry.

This is a fully normal thing to have. You only update the copyright year
for something when *you* do something relevant for copyright law (that
is passing the threshold of originality) in that year.

Having this tag is misleading because it’ll lead to people bumping the
year because they don’t know better and just to silence lintian.


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

Kernel: Linux 5.10.0-19-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages lintian depends on:
ii  binutils2.39-8
ii  bzip2   1.0.8-5+b1
ii  diffstat1.64-1
ii  dpkg1.21.9+b1
ii  dpkg-dev1.21.9
ii  file1:5.41-4
ii  gettext 0.21-10
ii  gpg 2.2.40-1
ii  intltool-debian 0.35.0+20060710.6
ii  iso-codes   4.12.0-1
ii  libapt-pkg-perl 0.1.40+b2
ii  libarchive-zip-perl 1.68-1
ii  libberkeleydb-perl  0.64-2+b1
ii  libcapture-tiny-perl0.48-1
ii  libclass-xsaccessor-perl1.19-4+b1
ii  libclone-perl   0.46-1
ii  libconfig-tiny-perl 2.28-2
ii  libconst-fast-perl  0.014-2
ii  libcpanel-json-xs-perl  4.32-1+b1
ii  libdata-dpath-perl  0.58-1
ii  libdata-validate-domain-perl0.10-1.1
ii  libdata-validate-uri-perl   0.07-2
ii  libdevel-size-perl  0.83-2+b1
pn  libdigest-sha-perl  
ii  libdpkg-perl1.21.9
ii  libemail-address-xs-perl1.05-1+b1
ii  libencode-perl  3.19-1+b1
ii  libfile-basedir-perl0.09-2
ii  libfile-find-rule-perl  0.34-3
ii  libfont-ttf-perl1.06-2
ii  libhtml-html5-entities-perl 0.004-3
ii  libhtml-tokeparser-simple-perl  3.16-4
ii  libio-interactive-perl  1.023-2
ii  libipc-run3-perl0.048-2
ii  libjson-maybexs-perl1.004004-1
ii  liblist-compare-perl0.55-2
ii  liblist-someutils-perl  0.58-3
ii  liblist-utilsby-perl0.12-2
ii  libmldbm-perl   2.05-4
ii  libmoo-perl 2.005004-3
ii  libmoox-aliases-perl0.001006-2
ii  libnamespace-clean-perl 0.27-2
ii  libpath-tiny-perl   0.124-1
ii  libperlio-gzip-perl 0.20-1+b1
ii  libperlio-utf8-strict-perl  0.010-1
ii  libproc-processtable-perl   0.634-1+b2
ii  libregexp-wildcards-perl1.05-3
ii  libsereal-decoder-perl  5.001+ds-1+b1
ii  libsereal-encoder-perl  5.001+ds-2
ii  libsort-versions-perl   1.62-3
ii  libsyntax-keyword-try-perl  0.27-1+b1
ii  libterm-readkey-perl2.38-2+b1
ii  libtext-levenshteinxs-perl  0.03-5+b1
ii  libtext-markdown-discount-perl  0.13-2
ii  libtext-xslate-perl 3.5.9-1+b2
ii  libtime-duration-perl   1.21-1
ii  libtime-moment-perl 0.44-2+b1
ii  libtimedate-perl2.3300-2
ii  libunicode-utf8-perl0.62-1+b4
ii  liburi-perl 5.17-1
ii  libwww-mechanize-perl   2.15-1
ii  libwww-perl 6.67-1
ii  libxml-libxml-perl  2.0207+dfsg+really+2.0134-1+b1
ii  libyaml-libyaml-perl0.84+ds-1+b1
ii  lzip [lzip-decompressor]1.23-4
ii  lzop1.04-2
ii  man-db  2.11.1-1
ii  patchutils  0.4.2-1
ii  perl [libencode-perl]   5.36.0-4
ii  t1utils 1.41-4
ii  unzip   6.0-27
ii  xz-utils5.2.8-0.0

lintian recommends no packages.

Versions of packages lintian suggests:
pn  binutils-multiarch 
pn  libtext-template-perl  

-- no debconf information

Bug#1025643: RM: django-testscenarios -- ROM; deprecated, unmaintained upstream

[Antonio Terceiro]

Package: ftp.debian.org
Severity: normal

Please remove src:django-testscenarios from the archive. It's
unmaintained upstream, nothing else in the Debian archive depends on it.
I might not even work with the most recent version of Django, but we
don't know because there's nothing using it.

(I am looking after it both on Debian and upstream).


signature.asc
Description: PGP signature

Bug#1025642: RFS: d11amp/0.59-1 -- Simple MP3 player

[Thomas Dettbarn]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

* Package name : d11amp
Version : 0.59-1
Upstream contact : Thomas Dettbarn 
* URL : https://www.dettus.net/d11amp/
* License : BSD-2-Clause
* Vcs : https://github.com/dettus/d11amp/
Section : sound

The source builds the following binary packages:

d11amp - Simple MP3 player

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


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

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

dget -x 
https://mentors.debian.net/debian/pool/main/d/d11amp/d11amp_0.59-1.dsc


Changes for the initial release:

d11amp (0.59-1) unstable; urgency=low
.
* initial release.

Regards,


Thomas Dettbarn


P.S.: Mentors, I need guidance... I seem to have some lintian warnings 
left. Which

I do not understand. Could you have a look?

Bug#1025629: Use of PolicyKit by Sugar

[James Cameron]

Sugar uses pkexec to elevate privilege to control backlight and get
device serial number.  Processes are forked to run shell scripts.  The
command line is prefixed with pkexec.

I don't know of any D-Bus use of PolicyKit, nor any use of the
PyGObject API.

Hope that helps!

Bug#1017760: linux-image-5.10.0-17-amd64: No space for directory leaf checksum. Please run e2fsck -D.

[Thorsten Glaser]

severity 1017760 normal
retitle 1017760 linux: possible data corruption on µSD card, might be the 
hardware though?
thanks

Dixi quod…

>I have somewhat reason to at least suspect the µSD card this was
>installed on. But there was never anything in syslog/dmesg about
>it, so the Linux kernel clearly didn’t find fault with it at all.

I now have reasonable reason to suspect not the µSD card itself,
or, at least, not alone, but the µSD-to-SD adapter. One noname
behaved even worse, a different brand to the original one seems
to behave better.

>Suggestions how I can prove/disprove this welcome; I now swapped

Still that.

bye,
//mirabilos
-- 
22:20⎜ The crazy that persists in his craziness becomes a master
22:21⎜ And the distance between the craziness and geniality is
only measured by the success 18:35⎜ "Psychotics are consistently
inconsistent. The essence of sanity is to be inconsistently inconsistent

Bug#1016359: more info

[Thorsten Glaser]

Hi dann,

>  Could you confirm the last version that worked for you - perhaps

I have never booted an EFI system before; this VM was the first
time for me, so I do not have a “last version” either way.

As I said, this does work with BIOS (or at least used to).

bye,
//mirabilos
-- 
[...] if maybe ext3fs wasn't a better pick, or jfs, or maybe reiserfs, oh but
what about xfs, and if only i had waited until reiser4 was ready... in the be-
ginning, there was ffs, and in the middle, there was ffs, and at the end, there
was still ffs, and the sys admins knew it was good. :)  -- Ted Unangst über *fs

Bug#1025586: udisks2: dependency on transitional policykit-1 package

[Simon McVittie]

On Tue, 06 Dec 2022 at 15:17:27 +, Simon McVittie wrote:
> This package has a Depends and/or Build-Depends on the transitional
> package policykit-1, which has been separated into polkitd, pkexec and
> (deprecated) polkitd-pkla packages.

debian/tests/control also seems to have a reference to policykit-1, so
please remember to update that too.

smcv

Bug#1024054: bullseye-pu: package mariadb-10.5 10.5.18-0+deb11u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Sun, 2022-12-04 at 17:14 -0800, Otto Kekäläinen wrote:
> Hello!
> mariadb-10.5 (1:10.5.18-0+deb11u1) bullseye; urgency=medium
> 
>   * New upstream version 10.5.18.
>   * New upstream version 10.5.17. Includes security fixes for
> - CVE-2018-25032
> - CVE-2022-32081
> - CVE-2022-32082
> - CVE-2022-32084
> - CVE-2022-32089
> - CVE-2022-32091
>   * New upstream version 10.5.16. Includes security fixes for
> - CVE-2021-46669
> - CVE-2022-27376
> - CVE-2022-27377
> - CVE-2022-27378
> - CVE-2022-27379
> - CVE-2022-27380
> - CVE-2022-27381
> - CVE-2022-27382
> - CVE-2022-27383
> - CVE-2022-27384
> - CVE-2022-27386
> - CVE-2022-27387
> - CVE-2022-27444
> - CVE-2022-27445
> - CVE-2022-27446
> - CVE-2022-27447
> - CVE-2022-27448
> - CVE-2022-27449
> - CVE-2022-27451
> - CVE-2022-27452
> - CVE-2022-27455
> - CVE-2022-27456
> - CVE-2022-27457
> - CVE-2022-27458
> - CVE-2022-32083
> - CVE-2022-32085
> - CVE-2022-32086
> - CVE-2022-32087
> - CVE-2022-32088
> 

I assume there are no other changes in the new releases that might be
relevant / interesting to users (and thus worthy of mentioning in the
changelog)?

Please go ahead.

Regards,

Adam

Bug#1025641: runit: autopkgtest depends on transitional policykit-1 package

[Simon McVittie]

Source: runit
Version: 2.1.2-50
Severity: normal
User: pkg-utopia-maintain...@lists.alioth.debian.org
Usertags: policykit-1
Control: block 1025540 by -1

This package's autopkgtest-based test suite depends on the transitional
package policykit-1, which has been separated into polkitd, pkexec and
(deprecated) polkitd-pkla packages.

If the tests communicate with polkitd via D-Bus, please represent that
as a Depends on polkitd.

If the tests run /usr/bin/pkexec, please represent that as a Depends
on pkexec.

If the tests require legacy .pkla files to be processed, please represent
that as a Depends on polkitd-pkla (but note that this package will probably
be removed from testing/unstable after Debian 12 is released).

For packages that are expected to be backported to bullseye, it's OK to
use an alternative dependency: polkitd | policykit-1 and/or
pkexec | policykit-1.

This is part of a mass bug filing, see
.

Thanks,
smcv

Bug#1025640: python-dbusmock: autopkgtest depends on transitional policykit-1 package

[Simon McVittie]

Source: python-dbusmock
Version: 0.28.6-1
Severity: normal
User: pkg-utopia-maintain...@lists.alioth.debian.org
Usertags: policykit-1
Control: block 1025540 by -1

This package's autopkgtest-based test suite depends on the transitional
package policykit-1, which has been separated into polkitd, pkexec and
(deprecated) polkitd-pkla packages.

If the tests communicate with polkitd via D-Bus, please represent that
as a Depends on polkitd.

If the tests run /usr/bin/pkexec, please represent that as a Depends
on pkexec.

If the tests require legacy .pkla files to be processed, please represent
that as a Depends on polkitd-pkla (but note that this package will probably
be removed from testing/unstable after Debian 12 is released).

For packages that are expected to be backported to bullseye, it's OK to
use an alternative dependency: polkitd | policykit-1 and/or
pkexec | policykit-1.

This is part of a mass bug filing, see
.

Thanks,
smcv

Bug#1025639: firewalld: autopkgtest depends on transitional policykit-1 package

[Simon McVittie]

Source: firewalld
Version: 1.2.2-1
Severity: normal
User: pkg-utopia-maintain...@lists.alioth.debian.org
Usertags: policykit-1
Control: block 1025540 by -1

This package's autopkgtest-based test suite depends on the transitional
package policykit-1, which has been separated into polkitd, pkexec and
(deprecated) polkitd-pkla packages.

If the tests communicate with polkitd via D-Bus, please represent that
as a Depends on polkitd.

If the tests run /usr/bin/pkexec, please represent that as a Depends
on pkexec.

If the tests require legacy .pkla files to be processed, please represent
that as a Depends on polkitd-pkla (but note that this package will probably
be removed from testing/unstable after Debian 12 is released).

For packages that are expected to be backported to bullseye, it's OK to
use an alternative dependency: polkitd | policykit-1 and/or
pkexec | policykit-1.

This is part of a mass bug filing, see
.

Thanks,
smcv

Bug#1016359: more info

[dann frazier]

tag 1016359 + moreinfo
thanks

Hi Thorsten,

  Could you confirm the last version that worked for you - perhaps
testing some builds from snapshot.debian.org if you're unsure? If you
can provide the libvirt XML from your VM, that may be useful as well.

   -dann

Bug#1025638: ayatana-indicator-session: autopkgtest depends on transitional policykit-1 package

[Simon McVittie]

Source: ayatana-indicator-session
Version: 22.9.0-2
Severity: normal
User: pkg-utopia-maintain...@lists.alioth.debian.org
Usertags: policykit-1
Control: block 1025540 by -1

This package's autopkgtest-based test suite depends on the transitional
package policykit-1, which has been separated into polkitd, pkexec and
(deprecated) polkitd-pkla packages.

If the tests communicate with polkitd via D-Bus, please represent that
as a Depends on polkitd.

If the tests run /usr/bin/pkexec, please represent that as a Depends
on pkexec.

If the tests require legacy .pkla files to be processed, please represent
that as a Depends on polkitd-pkla (but note that this package will probably
be removed from testing/unstable after Debian 12 is released).

For packages that are expected to be backported to bullseye, it's OK to
use an alternative dependency: polkitd | policykit-1 and/or
pkexec | policykit-1.

This is part of a mass bug filing, see
.

Thanks,
smcv

Bug#1025637: debugpy: FTBFS in sid (test failures)

[Gianfranco Costamagna]

Source: debugpy
Version: 1.6.3+git20221103.a2a3328+ds-1
Severity: serious

Hello, as seen also in reproducible builds page, your package now FTBFS (test 
failures), probably due to newer Python3.11, even
though I'm not really sure about it.
Build log attached.

Gianfranco


debugpy.7z
Description: application/7z-compressed


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1025591: systemd-resolved: suggests transitional policykit-1 package

[Simon McVittie]

On Tue, 06 Dec 2022 at 18:20:09 +0100, Michael Biebl wrote:
> it appears this only covers debian/control.
> 
> While looking at the systemd package, I also noticed policykit-1 being used
> in debian/tests/control.
> 
> Are those dependencies excluded on purpose or just an omission?

Good catch, that wasn't an intentional exclusion: I was using

dak rm -R -n -b policykit-1

on the DD-accessible mirror of ftp-master, and that doesn't yet pay
attention to tests' dependencies (Testsuite-Triggers would be an upper
bound for what's needed). Looks like I have some more bugs to open...

smcv

Bug#1025493: firefox crashes instantly at start

[Felix Zielcke]

On Mon, 5 Dec 2022 20:31:02 +0100 VA  wrote:
> Package: firefox
> Version: 107.0.1-1
> Severity: important
> 
> It's not a broken profile, even when running "firefox --
ProfileManager" 
> or "firefox --safe-mode":
> 
> [GFX1-]: glxtest: VA-API test failed: failed to initialise VAAPI
connection.
> ATTENTION: default value of option mesa_glthread overridden by
environment.
> ATTENTION: default value of option mesa_glthread overridden by
environment.
> ATTENTION: default value of option mesa_glthread overridden by
environment.
> ExceptionHandler::GenerateDump cloned child 231737
> ExceptionHandler::SendContinueSignalToChild sent continue signal to
child
> ExceptionHandler::WaitForContinueSignal waiting for continue
signal...
> 
> 

I have exactly the same problem since Mesa 22.3.0 was uploaded to
unstable.
Downgrading all src:mesa packages to version 22.2.4 from testing fixes
this for me.
I've got a Nvidia graphic card and use the Nvidia driver packages from
Debian. It doestn't matter at all if nvidia-vaapi-driver is installed
or removed/purged. 

Bug#1025636: zulucrypt: dependency on transitional policykit-1 package

[Simon McVittie]

Source: zulucrypt
Version: 5.7.1-2
Severity: normal
User: pkg-utopia-maintain...@lists.alioth.debian.org
Usertags: policykit-1
Control: block 1025540 by -1

This package has a Depends and/or Build-Depends on the transitional
package policykit-1, which has been separated into polkitd, pkexec and
(deprecated) polkitd-pkla packages.

If this package communicates with polkitd via D-Bus, please represent that
as a Depends, Recommends or Suggests on polkitd, whichever is appropriate
for the strength of the requirement.

If this package runs /usr/bin/pkexec, please represent that as a Depends,
Recommends or Suggests on pkexec, whichever is appropriate for the strength
of the requirement.

If this package requires polkit at build-time (usually for the gettext
extensions polkit.its and polkit.loc), please build-depend on both
libpolkit-gobject-1-dev and polkitd, even if the package does not
actually depend on libpolkit-gobject-1 at runtime. This is because
the gettext extensions are currently in polkitd, but might be moved to
libpolkit-gobject-1-dev in future (see #955204). pkexec is usually not
required at build-time.

For packages that are expected to be backported to bullseye, it's OK to
use an alternative dependency: polkitd | policykit-1 and/or
pkexec | policykit-1.

This is part of a mass bug filing, see
.

Thanks,
smcv

Bug#1025635: x2gothinclient: dependency on transitional policykit-1 package

[Simon McVittie]

Source: x2gothinclient
Version: 1.5.0.1-8.1
Severity: normal
User: pkg-utopia-maintain...@lists.alioth.debian.org
Usertags: policykit-1
Control: block 1025540 by -1

This package has a Depends and/or Build-Depends on the transitional
package policykit-1, which has been separated into polkitd, pkexec and
(deprecated) polkitd-pkla packages.

If this package communicates with polkitd via D-Bus, please represent that
as a Depends, Recommends or Suggests on polkitd, whichever is appropriate
for the strength of the requirement.

If this package runs /usr/bin/pkexec, please represent that as a Depends,
Recommends or Suggests on pkexec, whichever is appropriate for the strength
of the requirement.

If this package requires polkit at build-time (usually for the gettext
extensions polkit.its and polkit.loc), please build-depend on both
libpolkit-gobject-1-dev and polkitd, even if the package does not
actually depend on libpolkit-gobject-1 at runtime. This is because
the gettext extensions are currently in polkitd, but might be moved to
libpolkit-gobject-1-dev in future (see #955204). pkexec is usually not
required at build-time.

For packages that are expected to be backported to bullseye, it's OK to
use an alternative dependency: polkitd | policykit-1 and/or
pkexec | policykit-1.

This is part of a mass bug filing, see
.

Thanks,
smcv

Bug#1022113: gpm: division by 0 in processMouse()

[Jakub Wilk]

* Axel Beckert , 2022-10-20 12:22:
I wonder how to fix this properly? Setting opt_scaley hardcoded to 1 
(or another sane value) in case it's 0


Yup, bumping opt_scaley from 0 to 1 should work.

--
Jakub Wilk

Bug#1025634: veyon: dependency on transitional policykit-1 package

[Simon McVittie]

Source: veyon
Version: 4.7.4+repack1-1
Severity: normal
User: pkg-utopia-maintain...@lists.alioth.debian.org
Usertags: policykit-1
Control: block 1025540 by -1

This package has a Depends and/or Build-Depends on the transitional
package policykit-1, which has been separated into polkitd, pkexec and
(deprecated) polkitd-pkla packages.

If this package communicates with polkitd via D-Bus, please represent that
as a Depends, Recommends or Suggests on polkitd, whichever is appropriate
for the strength of the requirement.

If this package runs /usr/bin/pkexec, please represent that as a Depends,
Recommends or Suggests on pkexec, whichever is appropriate for the strength
of the requirement.

If this package requires polkit at build-time (usually for the gettext
extensions polkit.its and polkit.loc), please build-depend on both
libpolkit-gobject-1-dev and polkitd, even if the package does not
actually depend on libpolkit-gobject-1 at runtime. This is because
the gettext extensions are currently in polkitd, but might be moved to
libpolkit-gobject-1-dev in future (see #955204). pkexec is usually not
required at build-time.

For packages that are expected to be backported to bullseye, it's OK to
use an alternative dependency: polkitd | policykit-1 and/or
pkexec | policykit-1.

This is part of a mass bug filing, see
.

Thanks,
smcv

Bug#1025633: ukui-biometric-auth: dependency on transitional policykit-1 package

[Simon McVittie]

Source: ukui-biometric-auth
Version: 1.2.2.1-1
Severity: normal
User: pkg-utopia-maintain...@lists.alioth.debian.org
Usertags: policykit-1
Control: block 1025540 by -1

This package has a Depends and/or Build-Depends on the transitional
package policykit-1, which has been separated into polkitd, pkexec and
(deprecated) polkitd-pkla packages.

If this package communicates with polkitd via D-Bus, please represent that
as a Depends, Recommends or Suggests on polkitd, whichever is appropriate
for the strength of the requirement.

If this package runs /usr/bin/pkexec, please represent that as a Depends,
Recommends or Suggests on pkexec, whichever is appropriate for the strength
of the requirement.

If this package requires polkit at build-time (usually for the gettext
extensions polkit.its and polkit.loc), please build-depend on both
libpolkit-gobject-1-dev and polkitd, even if the package does not
actually depend on libpolkit-gobject-1 at runtime. This is because
the gettext extensions are currently in polkitd, but might be moved to
libpolkit-gobject-1-dev in future (see #955204). pkexec is usually not
required at build-time.

For packages that are expected to be backported to bullseye, it's OK to
use an alternative dependency: polkitd | policykit-1 and/or
pkexec | policykit-1.

This is part of a mass bug filing, see
.

Thanks,
smcv

Bug#1025632: tuned: dependency on transitional policykit-1 package

[Simon McVittie]

Source: tuned
Version: 2.15.0-1.1
Severity: normal
User: pkg-utopia-maintain...@lists.alioth.debian.org
Usertags: policykit-1
Control: block 1025540 by -1

This package has a Depends and/or Build-Depends on the transitional
package policykit-1, which has been separated into polkitd, pkexec and
(deprecated) polkitd-pkla packages.

If this package communicates with polkitd via D-Bus, please represent that
as a Depends, Recommends or Suggests on polkitd, whichever is appropriate
for the strength of the requirement.

If this package runs /usr/bin/pkexec, please represent that as a Depends,
Recommends or Suggests on pkexec, whichever is appropriate for the strength
of the requirement.

If this package requires polkit at build-time (usually for the gettext
extensions polkit.its and polkit.loc), please build-depend on both
libpolkit-gobject-1-dev and polkitd, even if the package does not
actually depend on libpolkit-gobject-1 at runtime. This is because
the gettext extensions are currently in polkitd, but might be moved to
libpolkit-gobject-1-dev in future (see #955204). pkexec is usually not
required at build-time.

For packages that are expected to be backported to bullseye, it's OK to
use an alternative dependency: polkitd | policykit-1 and/or
pkexec | policykit-1.

This is part of a mass bug filing, see
.

Thanks,
smcv

Bug#1025631: timekpr-next: dependency on transitional policykit-1 package

[Simon McVittie]

Source: timekpr-next
Version: 0.5.2-1
Severity: normal
User: pkg-utopia-maintain...@lists.alioth.debian.org
Usertags: policykit-1
Control: block 1025540 by -1

This package has a Depends and/or Build-Depends on the transitional
package policykit-1, which has been separated into polkitd, pkexec and
(deprecated) polkitd-pkla packages.

If this package communicates with polkitd via D-Bus, please represent that
as a Depends, Recommends or Suggests on polkitd, whichever is appropriate
for the strength of the requirement.

If this package runs /usr/bin/pkexec, please represent that as a Depends,
Recommends or Suggests on pkexec, whichever is appropriate for the strength
of the requirement.

If this package requires polkit at build-time (usually for the gettext
extensions polkit.its and polkit.loc), please build-depend on both
libpolkit-gobject-1-dev and polkitd, even if the package does not
actually depend on libpolkit-gobject-1 at runtime. This is because
the gettext extensions are currently in polkitd, but might be moved to
libpolkit-gobject-1-dev in future (see #955204). pkexec is usually not
required at build-time.

For packages that are expected to be backported to bullseye, it's OK to
use an alternative dependency: polkitd | policykit-1 and/or
pkexec | policykit-1.

This is part of a mass bug filing, see
.

Thanks,
smcv

Bug#1025630: synaptic: dependency on transitional policykit-1 package

[Simon McVittie]

Source: synaptic
Version: 0.91.2
Severity: normal
User: pkg-utopia-maintain...@lists.alioth.debian.org
Usertags: policykit-1
Control: block 1025540 by -1

This package has a Depends and/or Build-Depends on the transitional
package policykit-1, which has been separated into polkitd, pkexec and
(deprecated) polkitd-pkla packages.

If this package communicates with polkitd via D-Bus, please represent that
as a Depends, Recommends or Suggests on polkitd, whichever is appropriate
for the strength of the requirement.

If this package runs /usr/bin/pkexec, please represent that as a Depends,
Recommends or Suggests on pkexec, whichever is appropriate for the strength
of the requirement.

If this package requires polkit at build-time (usually for the gettext
extensions polkit.its and polkit.loc), please build-depend on both
libpolkit-gobject-1-dev and polkitd, even if the package does not
actually depend on libpolkit-gobject-1 at runtime. This is because
the gettext extensions are currently in polkitd, but might be moved to
libpolkit-gobject-1-dev in future (see #955204). pkexec is usually not
required at build-time.

For packages that are expected to be backported to bullseye, it's OK to
use an alternative dependency: polkitd | policykit-1 and/or
pkexec | policykit-1.

This is part of a mass bug filing, see
.

Thanks,
smcv

Bug#1025629: sugar: dependency on transitional policykit-1 package

[Simon McVittie]

Source: sugar
Version: 0.119-1
Severity: normal
User: pkg-utopia-maintain...@lists.alioth.debian.org
Usertags: policykit-1
Control: block 1025540 by -1

This package has a Depends and/or Build-Depends on the transitional
package policykit-1, which has been separated into polkitd, pkexec and
(deprecated) polkitd-pkla packages.

If this package communicates with polkitd via D-Bus, please represent that
as a Depends, Recommends or Suggests on polkitd, whichever is appropriate
for the strength of the requirement.

If this package runs /usr/bin/pkexec, please represent that as a Depends,
Recommends or Suggests on pkexec, whichever is appropriate for the strength
of the requirement.

If this package requires polkit at build-time (usually for the gettext
extensions polkit.its and polkit.loc), please build-depend on both
libpolkit-gobject-1-dev and polkitd, even if the package does not
actually depend on libpolkit-gobject-1 at runtime. This is because
the gettext extensions are currently in polkitd, but might be moved to
libpolkit-gobject-1-dev in future (see #955204). pkexec is usually not
required at build-time.

For packages that are expected to be backported to bullseye, it's OK to
use an alternative dependency: polkitd | policykit-1 and/or
pkexec | policykit-1.

This is part of a mass bug filing, see
.

Thanks,
smcv

Bug#1025628: policycoreutils-gui: dependency on transitional policykit-1 package

[Simon McVittie]

Package: policycoreutils-gui
Version: 3.4-1
Severity: normal
User: pkg-utopia-maintain...@lists.alioth.debian.org
Usertags: policykit-1
Control: block 1025540 by -1

This package has a dependency on the transitional package policykit-1,
which has been separated into polkitd, pkexec and (deprecated)
polkitd-pkla packages.

If this package communicates with polkitd via D-Bus, please represent that
as a Depends, Recommends or Suggests on polkitd, whichever is appropriate
for the strength of the requirement.

If this package runs /usr/bin/pkexec, please represent that as a Depends,
Recommends or Suggests on pkexec, whichever is appropriate for the strength
of the requirement.

If this package requires polkit at build-time (usually for the gettext
extensions polkit.its and polkit.loc), please build-depend on both
libpolkit-gobject-1-dev and polkitd, even if the package does not
actually depend on libpolkit-gobject-1 at runtime. This is because
the gettext extensions are currently in polkitd, but might be moved to
libpolkit-gobject-1-dev in future (see #955204). pkexec is usually not
required at build-time.

For packages that are expected to be backported to bullseye, it's OK to
use an alternative dependency: polkitd | policykit-1 and/or
pkexec | policykit-1.

This is part of a mass bug filing, see
.

Thanks,
smcv

Bug#1025627: selinux-dbus: dependency on transitional policykit-1 package

[Simon McVittie]

Source: selinux-dbus
Version: 3.4-1
Severity: normal
User: pkg-utopia-maintain...@lists.alioth.debian.org
Usertags: policykit-1
Control: block 1025540 by -1

This package has a Depends and/or Build-Depends on the transitional
package policykit-1, which has been separated into polkitd, pkexec and
(deprecated) polkitd-pkla packages.

If this package communicates with polkitd via D-Bus, please represent that
as a Depends, Recommends or Suggests on polkitd, whichever is appropriate
for the strength of the requirement.

If this package runs /usr/bin/pkexec, please represent that as a Depends,
Recommends or Suggests on pkexec, whichever is appropriate for the strength
of the requirement.

If this package requires polkit at build-time (usually for the gettext
extensions polkit.its and polkit.loc), please build-depend on both
libpolkit-gobject-1-dev and polkitd, even if the package does not
actually depend on libpolkit-gobject-1 at runtime. This is because
the gettext extensions are currently in polkitd, but might be moved to
libpolkit-gobject-1-dev in future (see #955204). pkexec is usually not
required at build-time.

For packages that are expected to be backported to bullseye, it's OK to
use an alternative dependency: polkitd | policykit-1 and/or
pkexec | policykit-1.

This is part of a mass bug filing, see
.

Thanks,
smcv

Bug#1025626: libhamlib4: fails to set freq on TT Jupiter

[Ed Lawson]

Package: libhamlib4
Version: 4.5-2+b1
Severity: normal
X-Debbugs-Cc: elaw...@grizzy.com

Dear Maintainer,

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

   * What led up to the situation?
When using rigctl to set a freq on the Jupiter for 20M and below, the radio is
shifted to 160M band and the reported freq is 1062MHz.  There is no problem
with setting freq/bands above 20M.  All other functions of rigctl work OK. If I
set a freq above 20M band, everything returns to normal.
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
Tried changing comm setting and various config option via rigctl.
   * What was the outcome of this action?
Thee was no change in the behavior.
   * What outcome did you expect instead?

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


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

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

Versions of packages libhamlib4 depends on:
ii  libc6 2.36-6
ii  libusb-1.0-0  2:1.0.26-1

libhamlib4 recommends no packages.

libhamlib4 suggests no packages.

-- no debconf information

Bug#860013: Bug#824442: and conflict needs to be resolved

[Diederik de Haas]

On Tue, 11 Apr 2017 23:28:41 +0100 Ben Hutchings  wrote:
> Control: severity -1 important
> Control: severity 824442 important
> 
> On Tue, 2017-04-11 at 23:20 +0200, Aurelien Jarno wrote:
> > On 2017-04-11 03:35, Ben Hutchings wrote:
> > > Control: tag -1 moreinfo
> > > 
> > > On Mon, 10 Apr 2017 10:48:45 +0200 Aurelien Jarno 
> > > wrote:
> > > [...] 
> > > > Unfortunately I have been pointed on the libc-alpha mailing list that
> > > > it doesn't work if another file which includes 
> > > > (e.g. ) is included before . The problem is
> > > > that the __UAPI_DEF_IF_* constants are set to 1 in  > > > compat.h> even if  is not included.
> > > 
> > > [...]
> > > 
> > > Does this affect any real programs, or is this just theoretical (and
> > > therefore should be downgraded)?
> > 
> > It depends what do you mean by real program. I doubt it still affect
> > debian packages. The change has been introduced by kernel 4.5, and I
> > guess by now all the FTBFS have been fixed. At least for stretch, they
> > might be a few left in sid.
> 
> While the fix in the kernel is clearly incomplete, I think it must have
> worked for most programs.
> 
> > Now some of the fixes might not have reached upstream yet.
> > 
> > If we consider that acceptable, we can lower the severity of the bugs on
> > both the kernel and the glibc side.
> 
> Let's do that.

It has now been 5.5 years since the last message to this bug report.
What's the status? Should something be done?

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

Bug#1006179: [Pkg-clamav-devel] Bug#1006179: Bug#1006179: ClamAV 1.0.0 release candidate now available

[Sebastian Andrzej Siewior]

On 2022-10-30 14:44:16 [+], Scott Kitterman wrote:
> Looks like we'll also need to patch tomsfastmath, such upstream parched their 
> embedded copy:
> 
> https://github.com/Cisco-Talos/clamav/commit/17e52a09a91d8f6535014873ab6cb99c827b5e20

that needs we need to do mini transition for libtfm1 unless it can be
changed by the user. The transition shouldn't be a problem since we have
only one user…
Either way we need to get to it. I see what I manage this week.

> Scott K

Sebastian

Bug#1011921: big5

[Christoph Biedl]

Control: tags 1011921 moreinfo

積丹尼 Dan Jacobson wrote...

> $ file 111D2012841-01.txt
> 111D2012841-01.txt: ISO-8859 text, with CRLF line terminators

Hello,

as you noticed, your file is utf-8. Can you please re-send as don't have
a clue how to proceed?

Regards,

Christoph


signature.asc
Description: PGP signature

Bug#1025624: src:janus: fails to migrate to testing for too long: FTBFS on mipsel

[Paul Gevers]

Source: janus
Version: 1.0.4-1
Severity: serious
Control: close -1 1.1.0-1
Tags: sid bookworm ftbfs
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 60 days as having a Release Critical bug in 
testing [1]. Your package src:janus has been trying to migrate for 61 
days [2]. Hence, I am filing this bug. Your package failed to build from 
source on mipsel, where it built successfully in the past.


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


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


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


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


Paul

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



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1025623: should we deprecate DHOME, GROUPHOMES, LETTERHOMES?

[Marc Haber]

Package: adduser
Version: 3.129
Severity: minor

Hi,

I am wondering whether it is still worth to maintain DHOME, GROUPHOMES
and LETTERHOMES. Installations as big that they need this are likely ot
have a directory service.

If we settle on deprecating those features, there will be a deprecation
notice in bookworm with the actual code removed post-bookworm.

What do you think?

Greetings
Marc

Bug#1025622: lrig: Does not work with TT-538 (Jupiter)

[Ed Lawson]

Package: lrig
Version: flrig
Severity: important
X-Debbugs-Cc: elaw...@grizzy.com

Dear Maintainer,

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

   * What led up to the situation?
I was trying to use flrig with my Jupiter, but even though the config info
looks correct and as supplied by flrig, the program always says transceiver not
responding.  I can use hamlib so I know hardware is OK. Also flrig works
properly with a different radio (FT-857D).
   * What exactly did you do (or not do) that was effective (or
 ineffective)?

I tried all manner of config setting.
   * What was the outcome of this action?
Nothing enabled flrig to communicate with the Jupiter.
   * What outcome did you expect instead?

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


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

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