Bug#1038155: zfs-linux: Provide a package based on OpenZFS master branch (a.k.a. 2.1.99)

[Damiano Albani]

Package: zfs-linux
Severity: wishlist
X-Debbugs-Cc: damiano.alb...@gmail.com

Dear Maintainer,

Ubuntu recently started using the master branch of OpenZFS (a.k.a. 2.1.99)
for ZFS packages in Mantic: 
https://launchpad.net/ubuntu/+source/zfs-linux/2.1.99-0ubuntu4.

Would Debian consider such a move as well?
My understanding is that Debian tends to be more conservative(?) than Ubuntu
in that regard, so maybe have this 2.1.99 package in Debian Experimental?
(I don't know much about the whole Debian packaging rules, so I hope it makes 
sense.)

As you problably already know, it is *already* possible to build Debian
packages from the master branch of OpenZFS: see 
https://openzfs.github.io/openzfs-docs/Developer%20Resources/Building%20ZFS.html.
While this package definition maintained by OpenZFS works totally fine,
it produces packages named like "openzfs-zfs-dkms", "openzfs-zfsutils", etc,
which is not compatible with Debian packages depending on "zfsutils-linux"
for example.

So is it something that you would consider?
Thanks!

Best Regards,

-- 
Damiano Albani

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

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

Bug#1037974: ddcci-dkms: code fails to build and package fails to install with Linux 6.3 headers

[Andreas Beckmann]

Control: clone -1 -2
Control: reassign -2 src:dkms
Control: severity -2 wishlist
Control: retite -2 dkms: add directive to ignore module build failures

On 15/06/2023 22.27, Stephen Kitt wrote:

  * The package should not fail to install when the module build fails.
    This might be a problem in dkms itself, or in ddcci's integration.


First of all, I find it a great improvement in dkms that it signals 
failure to build a module by exiting with an error (instead of returning 
0 after printing "module failed to build" which easily gets lost in the 
upgrade log.) Of course this causes previously unseen failures during 
the upgrade phase. (Instead of missing root file system or accelerated 
graphics after a reboot in case of a "required" module.) Maybe annoying 
in case of "optional" modules.


From a QA perspective I definitively want to see these as failures.


This is the more interesting issue, but see #1029063. Admittedly the absence
of a ddcci module is unlikely to ever prevent a system from booting, so
perhaps we could have a way of telling dkms that build failures in a given
module shouldn’t be treated as errors. Andreas, what do you think?


That's an interesting idea. Yes, that sounds like a useful feature. I'm 
not sure if it should be enabled by default in dkms.conf of the module 
or the local admin should rather create /etc/dkms/$module.conf with an 
override directive in there.

How should we call such a directive?
Maybe BUILD_FAILURE_IS_FATAL, default: yes.
With my QA hat on, I want a global override for that: 
BUILD_FAILURE_IS_ALWAYS_FATAL, default no.


Next question: do we want to ignore such a build failure only for 
unknown kernels (newer than the last successfully tested version) or 
always? Sometimes backporting fixes to a stable kernel breaks modules 
(see e.g. lttng-modules-dkms in (old-)old-stable).


Does anyone want to open an issue at the dkms github project, s.t. more 
people can throw in their ideas?

(We'll probably test that in Debian first before upstreaming a solution.)


Andreas

Bug#1038121: tracker.debian.org: debian/patches check vs. single-debian-patch in debian/source/local-options

[Raphael Hertzog]

Hello,

On Thu, 15 Jun 2023, Thorsten Glaser wrote:
> Unsure if this is the right pseudopackage; if not, please reassign.
> 
> The “new” Debian tracker shows:
> 
>  debian/patches: 1 patch to forward upstream
> 
> The package however uses the single-debian-patch mechanism
> to let a diff be autogenerated from the patched source in
> VCS. This is therefore not a diff that could possibly be
> forwarded, and possibly contains Debian-local diffs only.
> 
> (This is basically using 3.0 (quilt) like 1.0, and very valid.)

The tracker uses data exported by UDD so I believe that it's up
to UDD to not mark that patch as to be forwarded... but UDD is doing
its analysis based on the pseudo-headers available in the patch.

So maybe it's dpkg-source that needs to be tweaked so that such patches
have a field "Forwarded: not-needed" and an explanation that the patch
is an auto-generated mess that can't be forwarded as is.

Can you name a sample package affected by this please?

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Bug#1037925: icingacli: Icinga is not compatible with php8.2

[Gabriel Rolland]

Package: icingaweb2
Version: 2.11.4-2
Followup-For: Bug #1037925

The welcome page is ok, when I try to login (both with correct and wrong 
credentials) I get the following error:

[Fri Jun 16 09:15:59.873332 2023] [proxy_fcgi:error] [pid 1086065] [client 
192.168.111.3:57572] AH01071: Got error 'PHP message: PHP Deprecated:  Creation 
of dynamic property Zend_Validate_NotEmpty::$zfBreakChainOnFailure is 
deprecated in /usr/share/icingaweb2/library/vendor/Zend/Form/Element.php on 
line 2176; 
PHP message: PHP Stack trace:; PHP message: PHP   1. {main}() 
/usr/share/icingaweb2/public/index.php:0; PHP message: PHP   2. require_once() 
/usr/share/icingaweb2/public/index.php:4; PHP message: PHP   3. 
Icinga\\Application\\Web->dispatch() 
/usr/share/icingaweb2/library/Icinga/Application/webrouter.php:105; PHP 
message: PHP   4. Zend_Controller_Front->dispatch($request = class 
Icinga\\Web\\Request { protected $_dispatched = TRUE; protected $_module = 
'default'; protected $_moduleKey = 'module'; protected $_controller = 
'authentication'; protected $_controllerKey = 'controller'; protected $_action 
= 'login'; protected $_actionKey = 'action'; protected $_params = ['controller' 
=> 'authentication', 'action' => 'login', 'module' => 'default']; protected 
$_paramSources = [0 => '_GET', 1 => '_POST']; protected $_requestUri = 
'/icingaweb2/authentication/login'; protected $_baseUrl = '/icingaweb2'; 
protected $_basePath = NULL; protected $_pathInfo = '/authentication/login'; 
protected $_rawBody = NULL; protected $_aliases = []; protected $response = 
NULL; protected $uniqueId = NULL; protected $url = class Icinga\\Web\\Url { 
protected $external = NULL; protected $params = class Icinga\\Web\\UrlParams { 
... }; protected $anchor = ''; protected $path = 'authentication/login'; 
protected $basePath = '/icingaweb2'; prote...; PHP message: PHP   5. 
Icinga\\Web\\Controller\\Dispatcher->dispatch($request = class 
Icinga\\Web\\Request { protected $_dispatched = TRUE; protected $_module = 
'default'; protected $_moduleKey = 'module'; protected $_controller = 
'authentication'; protected $_controllerKey = 'controller'; protected $_action 
= 'login'; protected $_actionKey = 'action'; protected $_params = ['controller' 
=> 'authentication', 'action' => 'login', 'module' => 'default']; protected 
$_paramSources = [0 => '_GET', 1 => '_POST']; protected $_requestUri = 
'/icingaweb2/authentication/login'; protected $_baseUrl = '/icingaweb2'; 
protected $_basePath = NULL; protected $_pathInfo = '/authentication/login'; 
protected $_rawBody = NULL; protected $_aliases = []; protected $response = 
NULL; protected $uniqueId = NULL; protected $url = class Icinga\\Web\\Url { 
protected $external = NULL; protected $params = class Icinga\\Web\\UrlParams { 
... }; protected $anchor = ''; protected $path = 'authentication/login'; 
protected $basePath = '/icingaw...; PHP message: PHP   6. 
Zend_Controller_Action->dispatch($action = 'loginAction') 
/usr/share/icingaweb2/library/Icinga/Web/Controller/Dispatcher.php:76; PHP 
message: PHP   7. Icinga\\Controllers\\AuthenticationController->loginAction() 
/usr/share/icingaweb2/library/vendor/Zend/Controller/Action.php:507; PHP 
message: PHP   8. Icinga\\Web\\Form->handleRequest($request = *uninitialized*) 
/usr/share/icingaweb2/application/controllers/AuthenticationController.php:94; 
PHP message: PHP   9. Icinga\\Web\\Form->isValid($formData = ['username' => 
'resnovae', 'password' => '', 'rememberme' => '0', 'redirect' => '', 
'formUID' => 'form_login', 'CSRFToken' => 
'1530655134|ac3b0c824f1d627372153d4463a60b6bba41e0da69cd2bbf2c59de4ed556405a', 
'btn_submit' => 'Accedi']) 
/usr/share/icingaweb2/library/Icinga/Web/Form.php:1173; PHP message: PHP  10. 
Zend_Form->isValid($data = ['username' => 'resnovae', 'password' => '', 
'rememberme' => '0', 'redirect' => '', 'formUID' => 'form_login', 'CSRFToken' 
=> 
'1530655134|ac3b0c824f1d627372153d4463a60b6bba41e0da69cd2bbf2c59de4ed556405a', 
'btn_submit' => 'Accedi']) 
/usr/share/icingaweb2/library/Icinga/Web/Form.php:1297; PHP message: PHP  11. 
Zend_Form_Element->isValid($value = 'resnovae', $context = ['username' => 
'resnovae', 'password' => '', 'rememberme' => '0', 'redirect' => '', 
'formUID' => 'form_login', 'CSRFToken' => 
'1530655134|ac3b0c824f1d627372153d4463a60b6bba41e0da69cd2bbf2c59de4ed556405a', 
'btn_submit' => 'Accedi']) 
/usr/share/icingaweb2/library/vendor/Zend/Form.php:2280; PHP message: PHP  12. 
Zend_Form_Element->getValidators() 
/usr/share/icingaweb2/library/vendor/Zend/Form/Element.php:1389; PHP message: 
PHP  13. Zend_Form_Element->_loadValidator($validator = ['validator' => 
'NotEmpty', 'breakChainOnFailure' => TRUE, 'options' => []]) 
/usr/share/icingaweb2/library/vendor/Zend/Form/Element.php:1291; PHP message: 
PHP Deprecated:  Creation of dynamic property 
Zend_Validate_NotEmpty::$zfBreakChainOnFailure is deprecated in 
/usr/share/icingaweb2/library/vendor/Zend/Form/Element.php on line 2176; PHP 

Bug#1038156: dkms: add directive to ignore module build failures

[Andreas Beckmann]

Let's continue discussion of that dkms wishlist feature in this bug.

Andreas

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

[Alexandru Mihail]

Hello again Nicholas,
I hope this mail finds you well.

> > remember the original NCSA httpd licence. P.S. It feels like
> > archaeology to find missing documentation for something from the > > dawn of

Eureka ! 
I present the original NCSA httpd license in its purest form after some 
software archeology:
https://web.archive.org/web/20060830015540/http://hoohoo.ncsa.uiuc.edu/docs-1.5/Copyright.html

(NCSA HTTPd Development Team / ht...@ncsa.uiuc.edu / Last Modified 08-01-95)
== LICENSE START ===
NCSA HTTPd Server
Software Development Group
National Center for Supercomputing Applications
University of Illinois at Urbana-Champaign
605 E. Springfield, Champaign IL 61820
ht...@ncsa.uiuc.edu

Copyright (C) 1995, Board of Trustees of the University of Illinois

NCSA HTTPd software, both binary and source (hereafter, Software) is 
copyrighted by The Board of Trustees of the University of Illinois (UI), and 
ownership remains with the UI.

The UI grants you (hereafter, Licensee) a license to use the Software for 
academic, research and internal business purposes only, without a fee. Licensee 
may distribute the binary and source code (if released) to third parties 
provided that the copyright notice and this statement appears on all copies and 
that no charge is associated with such copies.

Licensee may make derivative works. However, if Licensee distributes any 
derivative work based on or derived from the Software, then Licensee will (1) 
notify NCSA regarding its distributing of the derivative work, and (2) clearly 
notify users that such derivative work is a modified version and not the 
original NCSA HTTPd Server software distributed by the UI by including a 
statement such as the following:

"Portions developed at the National Center for Supercomputing Applications 
at the University of Illinois at Urbana-Champaign." 

Any Licensee wishing to make commercial use of the Software should contact the 
UI, c/o NCSA, to negotiate an appropriate license for such commercial use. 
Commercial use includes (1) integration of all or part of the source code into 
a product for sale or license by or on behalf of Licensee to third parties, or 
(2) distribution of the binary code or source code to third parties that need 
it to utilize a commercial product sold or licensed by or on behalf of Licensee.

Any commercial company wishing to use the software as their commercial World 
Wide Web server and are not redistributing the software need not commercially 
license the software but can use it free of charge.

UI MAKES NO REPRESENTATIONS ABOUT THE SUITABILITY OF THIS SOFTWARE FOR ANY 
PURPOSE. IT IS PROVIDED "AS IS" WITHOUT EXPRESS OR IMPLIED WARRANTY. THE UI 
SHALL NOT BE LIABLE FOR ANY DAMAGES SUFFERED BY THE USERS OF THIS SOFTWARE.

By using or copying this Software, Licensee agrees to abide by the copyright 
law and all other applicable laws of the U.S. including, but not limited to, 
export control laws, and the terms of this license. UI shall have the right to 
terminate this license immediately by written notice upon Licensee's breach of, 
or non-compliance with, any of its terms. Licensee may be held legally 
responsible for any copyright infringement that is caused or encouraged by 
Licensee's failure to abide by the terms of this license. 

== LICENSE END =

Should we include a mention of this under debian/copyright stating
something along the lines of 'parts of mini_httpd.c under NCSA HTTPD
and include a copy of the license somewhere?
As far as I could dig, this is the license which should be attributed in our 
case. This is the 1.15 htttpd license, and with 99.% certainty, this was 
the chunk of code still found  in mini_httpd.c. The logic is, NCSA httpd had, 
historically, two licenses (chronologically): one open and one proprietary. 
mini_httpd is a fork of the open one, that we can be sure of. I think there is 
little reason to involve debian-legal at this point.
What's your opinion here?

Kind regards,
Alexandru

--- Original Message ---
On Monday, June 12th, 2023 at 9:27 PM, Alexandru Mihail 
 wrote:


> Hello again,
> 
> > I hope that the forests aren't burning, wherever you are.
> > 
> > Take care,
> 
> 
> Oh damn, I really hope you and your family are going to be safe if you're 
> facing wildfires near you..
> Here in Eastern Europe it's not really that much of an issue, thankfully.
> 
> > remember the original NCSA httpd licence. P.S. It feels like
> > archaeology to find missing documentation for something from the dawn of
> > the Web! Also, it's a mystery to me what license the original httpd
> > was.
> 
> It's pretty much a mistery to me too, seems like the original "License" if 
> you could call it that is nothing more than:
> "
> Copyright (C) 2022 by Jef Poskanzer j...@mail.acme.com.
> 
> All rights reserved.
> 
> You may use this software however you like as long as you keep my name on it 

Bug#1038158: Uses /etc/nullmailer/../mailname instead of /etc/mailname; misleading message

[Andras Korn]

Package: nullmailer
Version: 1:2.2-3+b1
Severity: normal

Hi,

I began using a revision tracking system for some configfiles. This involved 
replacing /etc/nullmailer with a symlink to a directory within the local 
working copy.

I noticed that locally generated mail was suddenly referencing literal 
"defaulthost".

I tried to create /etc/nullmailer/me with the correct hostname in it, but this 
didn't help. I attached strace to cron in an attempt to see what was going on 
and found this:

openat(AT_FDCWD, "/etc/nullmailer/me", O_RDONLY) = 
3/etc/nullmailer/me>
read(3/etc/nullmailer/me>, 
"my-correct-hostname-here\n", 4096) = 27
close(3/etc/nullmailer/me>) = 0  
write(2>, "Warning: On Debian systems, nullmailer's 'me' 
is disregarded; please use '/etc/mailname' instead.\n", 98) = 98
getuid()= 0
geteuid()   = 0
openat(AT_FDCWD, "/etc/nullmailer/../mailname", O_RDONLY) = -1 ENOENT (No such 
file or directory)

So, while nullmailer prints a message instructing me to fill /etc/mailname, it 
doesn't actually use /etc/mailname but /etc/nullmailer/../mailname, which 
doesn't necessarily exist and isn't necessarily the correct file if 
/etc/nullmailer is a symlink.

Also, printing messages to /dev/console isn't terribly useful in the case of 
remote headless servers.

I suggest the following changes:

1. in order to avoid violating the principle of least surprise, don't disregard 
/etc/nullmailer/me. If it's there, the admin put it there for a reason.

2. if /etc/nullmailer/me doesn't exist, default to "/etc/mailname", not 
"/etc/nullmailer/../mailname".

3. if these two changes are made, the message becomes unnecessary and can be a 
simple README.Debian item.

4. if you must print a message, log it to syslog instead of (or, if you insist, 
in addition to) writing it to /dev/console. However, can't writing to 
/dev/console block e.g. due to flow control on the terminal device? If so, I'd 
leave /dev/console alone.

Best regards,

András

-- 
 Mishearing the voices in his head, our hero wonders how he's supposed
  to kill the mall.

Bug#1037925: icingaweb2: SOLVED

[Gabriel Rolland]

Package: icingaweb2
Version: 2.11.4-2
Followup-For: Bug #1037925

Removing the .ini files I ran the wizard again.
I also dropped the MySQL table so he could recreate it, and that solved the 
problem.

Bug#1038160: googletest build fails on some 32bit architectures

[Matthias Klose]

Package: src:googletest
Version: 1.13.0-2
Severity: serious
Tags: sid trixie

according to
https://buildd.debian.org/status/package.php?p=googletest

this build fails at least on armel and i386, making googletest uninstallable on 
these architectures.


Looking at
https://buildd.debian.org/status/package.php?p=googletest&suite=experimental

these already failed in experimental back in January 2023.

I don't have much sympathy for uploading that to unstable without addressing 
these issues for about half a year, causing issues with other package builds. 
googletest is now uninstallable on these architectures.

Bug#1038161: ITP: xnvme -- Cross-platform libraries and tools for efficient I/O and low-level control.

[Simon A. F. Lund]

Package: wnpp
Severity: wishlist
Owner: "Simon A. F. Lund" 
X-Debbugs-Cc: debian-de...@lists.debian.org, o...@safl.dk

* Package name: xnvme
  Version : 0.7.0
  Upstream Author : Simon A. F. Lund 
* URL : https://xnvme.io/
* License : BSD
  Programming Lang: C
  Description : Cross-platform libraries and tools for efficient I/O and 
low-level control.

xNVMe provides a library to program storage devices efficiently from
user space and tools to interact with them. xNVMe is strongly motivated
by the emergence of storage devices providing I/O commands beyond those
of read/write. This is the "NVMe" part of the name.

The data plane or I/O layer is a minimal-cost abstraction on top of
sync-io with thread pools, POSIX aio, Linux libaio, io_uring,
io_uring_cmd, to name the most popular interfaces available via xNVMe on
Linux.

A control plane or Admin layer provides flexibility and low-level
control via APIs for admin commands and device management. On Linux,
these are implemented using interfaces such as ioctl(), io_uring_cmd,
and vfio-pci.

This is one key value point of xNVMe, providing a unified I/O and Admin
API interface for storage devices on top of the myriad of interfaces
available on todays operating systems.

On top of these are command-line utilities, including "zoned" and "kvs".
These provide NVMe-command-set interaction available at the fingertips
of the command-line.

The command-line utilities are related to those of nvme-cli. In this
area we are actively working on combining the efforts on the
command-line interface. On the library-side, then xNVMe is related to
the before-mentioned I/O libraries, which it encapsulates. However, it
goes beyond serving an abstraction on top, such that applications
implemented using xNVMe can run on platforms other than Linux.

Afaik. Then xNVMe is the only library providing a cross-platform storage
programming interface. Supporting "traditional" storage and optimized
for NVMe. This is the "x" part of the name for "cross" platform.

I plan to maintain the package as part of the release process of xNVMe itself,
thus making it an integral part of the CI to build, test, and verify the
package in "lockstep" with the development of xNVMe.

I am seeking help/guidance, possibly from a sponsor / co-maintainer.

Bug#1038162: amrhf/armel executables produced with EABI Version4 instead of 5

[Emanuele Rocca]

Package: tcc
Version: 0.9.27+git20200814.62c30a4a-1
Severity: wishlist

Hi,

executables compiled on armhf and armel target the ARM ABI Version4.

Since Debian 10 (Buster), the baseline was updated to Version 5: it
would be great if tcc could target Version 5 too.

ema@eniac:~
$ readelf -h /tmp/armel | grep Flags
  Flags: 0x4000202, Version4 EABI, 
ema@eniac:~
$ readelf -h /tmp/armhf | grep Flags
  Flags: 0x4000402, Version4 EABI, 

Bug#1037559: systemd-networkd-wait-online waits undefinitely if no networkd managed interfaces

[Wolfgang Bumiller]

On Wed, 14 Jun 2023 22:08:41 +0800 Yangfl  wrote:
> On Wed, 14 Jun 2023 09:42:06 +0100 Luca Boccassi  wrote:
> > Control: tags -1 moreinfo
> >
> > On Wed, 14 Jun 2023 01:10:16 -0700 Mo  wrote:
> > > Package: systemd
> > > Version: 252.6-1
> > > Severity: normal
> > > Tags: newcomer
> > > X-Debbugs-Cc: ali...@outlook.com
> > >
> > > Dear Maintainer,
> > >
> > > after upgrade to debian 12 from debian 11, the system boots using
> > almost ~2min
> > > to prompt login.
> > >
> > > after check for systemd-analyze, get info:
> > >
> > > root@vm:~# systemd-analyze time
> > > Startup finished in 2.246s (kernel) + 2min 3.788s (userspace) = 2min
> > 6.035s
> > > graphical.target reached after 2min 3.610s in userspace.
> > >
> > > root@vm:~# systemd-analyze blame
> > > 2min 189ms systemd-networkd-wait-online.service
> > > 4.253s kdump-tools.service
> > > 1.910s apparmor.service
> > > 1.267s ifupdown-pre.service
> > > ...
> > >
> > > in my machine there is not using systemd-networked, and no interfaces
> > managed by
> > > networkd.
> >
> > Then why is systemd-networkd-wait-online being pulled in? Did you
> > enable it or one of the targets that pull it in? If it's not in use as
> > you say, it should not run in the first place.
> >
> > --
> > Kind regards,
> > Luca Boccassi
> 
> (On behalf of ali...@outlook.com as he is facing some network problem)
> 
> Thanks for your hint, this problem original happened in my cloud
> machine, so I checked again.

On first boot systemd uses presets (systemd.preset(5)) to configure the
enable/disable state of services. By default, systemd-networkd.service
is enabled via presets and this pulls in
systemd-networkd-wait-online.service automatically as well, while
ifupdown provides an `ifupdown-wait-online.service` alternative which
also satisfies `network-online.target`.

Given that debian defaults to ifupdown, I wonder if debian's systemd
packaging should by default set the systemd-networkd.service preset
state to disabled? (It'll only affect first boots and explicit calls to
`systemctl preset`).

In any case, container providers may want to deal with this either in
their templates or when starting up containers.
We also ran into this with bookworm templates in Proxmox VE and generate
a preset file[1] for this now to debian containers.

[1] 
https://git.proxmox.com/?p=pve-container.git;a=commit;h=e11806e0de064e6570d40e7c04bc4656687b2c62

Bug#1038163: rsyslog: make logcheck ignore file to match the new record format

[Alex Volkov]

Package: rsyslog
Version: 8.2302.0-1
Severity: normal

Dear Maintainer,

the included /etc/logcheck/ignore.d.server/rsyslog still uses the old
log line format, while the new "high-precision time" format is the default now.

-- System Information:
Debian Release: 12.0
  APT prefers stable-security
  APT policy: (991, 'stable-security'), (991, 'stable'), (99, 'testing'), (90, 
'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.1.27-bootes0-p-1000 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages rsyslog depends on:
ii  libc6  2.36-9
ii  libelogind0 [libsystemd0]  246.10-1debian1
ii  libestr0   0.1.11-1
ii  libfastjson4   1.2304.0-1
ii  liblognorm52.0.6-4
ii  libuuid1   2.38.1-5+b1
ii  libzstd1   1.5.4+dfsg2-5
ii  zlib1g 1:1.2.13.dfsg-1

Versions of packages rsyslog recommends:
ii  logrotate  3.21.0-1

Versions of packages rsyslog suggests:
ii  rsyslog-doc   8.2302.0+dfsg-1
pn  rsyslog-gssapi
pn  rsyslog-mongodb   
pn  rsyslog-mysql | rsyslog-pgsql 
pn  rsyslog-openssl | rsyslog-gnutls  
pn  rsyslog-relp  

-- Configuration Files:
/etc/logrotate.d/rsyslog changed [not included]

-- no debconf information

Bug#1038164: RFP: container-selinux -- SELinux policy module for containers

[Sam Morris]

Package: wnpp
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

  Package name: container-selinux
  URL : https://github.com/containers/container-selinux
  License : GPL
  Description : SELinux policy confinement of containers

This package is needed for podman/buildah to work on systems where
SELinux is running.

Unless it's installed, the user has to manally disable container
labelling in containers.conf, or disable SELinux.



-BEGIN PGP SIGNATURE-

iIgEARYIADAWIQTWOGqGn6HETecdzqZOEaKLhlAYigUCZIwm4xIcc2FtQHJvYm90
cy5vcmcudWsACgkQThGii4ZQGIoKPgD+OHE7MjhotfAhTnNkM74pZGPzke033Rxb
OynaiRzwQ9gA/0imgNQhyIcaY5nfECbpiy4HiT5nZXVSkW2grAxCFsEG
=B1D/
-END PGP SIGNATURE-

Bug#1038165: c-ares FTCBFS: --enable-tests fails configure

[Helmut Grohne]

Source: c-ares
Version: 1.19.1-2
Tags: patch
Severity: important
User: debian-cr...@lists.debian.org
Usertags: ftcbfs
User: helm...@debian.org
Usertags: rebootstrap

Hi,

your c-ares upload breaks cross building, because --enable-testing hard
fails cross builds at configure time. This should be disabled as cross
builds pass DEB_BUILD_OPTIONS=nocheck. I'm attaching a patch for your
convenience. Please allow me to bump the severity of this cross build
failure to important, because it breaks architecture cross bootstrap for
all architectures.

Helmut
diff --minimal -Nru c-ares-1.19.1/debian/changelog 
c-ares-1.19.1/debian/changelog
--- c-ares-1.19.1/debian/changelog  2023-06-14 20:11:59.0 +0200
+++ c-ares-1.19.1/debian/changelog  2023-06-16 06:40:54.0 +0200
@@ -1,3 +1,10 @@
+c-ares (1.19.1-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Honour DEB_BUILD_OPTIONS=nocheck. (Closes: #-1)
+
+ -- Helmut Grohne   Fri, 16 Jun 2023 06:40:54 +0200
+
 c-ares (1.19.1-2) unstable; urgency=medium
 
   * upload to unstable
diff --minimal -Nru c-ares-1.19.1/debian/rules c-ares-1.19.1/debian/rules
--- c-ares-1.19.1/debian/rules  2023-06-14 20:04:09.0 +0200
+++ c-ares-1.19.1/debian/rules  2023-06-16 06:40:53.0 +0200
@@ -7,4 +7,4 @@
dh $@
 
 override_dh_auto_configure:
-   dh_auto_configure -- --enable-shared --enable-symbol-hiding 
--enable-tests
+   dh_auto_configure -- --enable-shared --enable-symbol-hiding --$(if 
$(filter nocheck,$(DEB_BUILD_OPTIONS)),dis,en)able-tests

Bug#1038166: php-imagick: on upgrades /etc/php/7.4/mods-available/imagick.ini is left behind

[Michael Prokop]

Package: php-imagick
Version: 3.7.0-4
Severity: important

Hi,

this might be related to #951847, I stumbled upon this behavior
during an upgrade of a Debian system from bullseye to bookworm,
where only file /etc/php/7.4/mods-available/imagick.ini is left
behind.

System based on bullseye looking as follows:

| # ls -la /etc/php/7.4/mods-available/
| total 92
| drwxr-xr-x 2 root root 4096 Jun 16 09:15 .
| drwxr-xr-x 5 root root 4096 Jun 16 09:15 ..
| -rw-r--r-- 1 root root   74 Jun  9 16:51 calendar.ini
| -rw-r--r-- 1 root root   71 Jun  9 16:51 ctype.ini
| -rw-r--r-- 1 root root   70 Jun  9 16:51 exif.ini
| -rw-r--r-- 1 root root   69 Jun  9 16:51 ffi.ini
| -rw-r--r-- 1 root root   74 Jun  9 16:51 fileinfo.ini
| -rw-r--r-- 1 root root   69 Jun  9 16:51 ftp.ini
| -rw-r--r-- 1 root root   73 Jun  9 16:51 gettext.ini
| -rw-r--r-- 1 root root   71 Jun  9 16:51 iconv.ini
| -rw-r--r-- 1 root root   60 Mar  5  2021 imagick.ini
| -rw-r--r-- 1 root root   68 Jun  9 16:51 json.ini
| -rw-r--r-- 1 root root   79 Jun  9 16:51 opcache.ini
| -rw-r--r-- 1 root root   69 Jun  9 16:51 pdo.ini
| -rw-r--r-- 1 root root   70 Jun  9 16:51 phar.ini
| -rw-r--r-- 1 root root   71 Jun  9 16:51 posix.ini
| -rw-r--r-- 1 root root   76 Jun  9 16:51 readline.ini
| -rw-r--r-- 1 root root   71 Jun  9 16:51 shmop.ini
| -rw-r--r-- 1 root root   73 Jun  9 16:51 sockets.ini
| -rw-r--r-- 1 root root   73 Jun  9 16:51 sysvmsg.ini
| -rw-r--r-- 1 root root   73 Jun  9 16:51 sysvsem.ini
| -rw-r--r-- 1 root root   73 Jun  9 16:51 sysvshm.ini
| -rw-r--r-- 1 root root   75 Jun  9 16:51 tokenizer.ini
| # cat /etc/php/7.4/mods-available/imagick.ini
| ; configuration for php imagick module
| extension=imagick.so

Then after upgrading the system to bookworm and applying
configuration file cleanup:

| # dpkg -l | grep php
| ii  php-common  2:93 all  
Common files for PHP packages
| ii  php-imagick 3.7.0-4  amd64
Provides a wrapper to the ImageMagick library
| rc  php7.4-cli  7.4.33-1+deb11u4 amd64
command-line interpreter for the PHP scripting language
| rc  php7.4-common   7.4.33-1+deb11u4 amd64
documentation, examples and common module for PHP
| rc  php7.4-json 7.4.33-1+deb11u4 amd64
JSON module for PHP
| rc  php7.4-opcache  7.4.33-1+deb11u4 amd64
Zend OpCache module for PHP
| rc  php7.4-phpdbg   7.4.33-1+deb11u4 amd64
server-side, HTML-embedded scripting language (PHPDBG binary)
| rc  php7.4-readline 7.4.33-1+deb11u4 amd64
readline module for PHP
| ii  php8.2-cli  8.2.7-1~deb12u1  amd64
command-line interpreter for the PHP scripting language
| ii  php8.2-common   8.2.7-1~deb12u1  amd64
documentation, examples and common module for PHP
| ii  php8.2-imagick  3.7.0-4  amd64
Provides a wrapper to the ImageMagick library
| ii  php8.2-opcache  8.2.7-1~deb12u1  amd64
Zend OpCache module for PHP
| ii  php8.2-phpdbg   8.2.7-1~deb12u1  amd64
server-side, HTML-embedded scripting language (PHPDBG binary)
| ii  php8.2-readline 8.2.7-1~deb12u1  amd64
readline module for PHP
| # dpkg --purge php7.4-cli php7.4-common php7.4-json php7.4-opcache 
php7.4-phpdbg php7.4-readline
| [...]

Then only `/etc/php/7.4/mods-available/imagick.ini` is left behind:

| # ls -la /etc/php/7.4/mods-available/
| total 12
| drwxr-xr-x 2 root root 4096 Jun 16 09:25 .
| drwxr-xr-x 3 root root 4096 Jun 16 09:25 ..
| -rw-r--r-- 1 root root   60 Mar  5  2021 imagick.ini
|
| # ls -la /etc/php/7.4/mods-available/imagick.ini
| -rw-r--r-- 1 root root 60 Mar  5  2021
| /etc/php/7.4/mods-available/imagick.ini
| # dpkg -S /etc/php/7.4/mods-available/imagick.ini
| php-imagick: /etc/php/7.4/mods-available/imagick.ini

Something feels wrong here?

FTR:

| # apt-cache policy php-imagick php8.2-imagick
| php-imagick:
|   Installed: 3.7.0-4
|   Candidate: 3.7.0-4
|   Version table:
|  *** 3.7.0-4 500
| 500 http://deb.debian.org/debian bookworm/main amd64 Packages
| 100 /var/lib/dpkg/status
| php8.2-imagick:
|   Installed: 3.7.0-4
|   Candidate: 3.7.0-4
|   Version table:
|  *** 3.7.0-4 500
| 500 http://deb.debian.org/debian bookworm/main amd64 Packages
| 100 /var/lib/dpkg/status
|
| # dpkg -L php-imagick
| /.
| /usr
| /usr/share
| /usr/share/doc
| /usr/share/doc/php-imagick
| /usr/share/doc/php-imagick/changelog.Debian.gz
| /usr/share/doc/php-imagick/copyright
| /etc/php/7.4/mods-available/imagick.ini
|
| # cat /var/lib/dpkg/info/php-imagick.list
| /.
| /usr
| /usr/share
| /usr/share/doc
| /usr/share/doc/php-imagick
| /usr/share/doc/php-imagick/changelog.Debian.gz
| /usr/share/doc/php-im

Bug#1038132: You’re Right

[Adrian Bunk]

On Thu, Jun 15, 2023 at 01:30:36PM -0700, Soren Stoutner wrote:
> You’re right.  In my testing, it currently fails with this error using sbuild 
> based on an unstable environment, but succeeds using sbuild in a testing 
> environment.  At this time, both unstable and testing have the same 
> versions 
> of GCC (4:12.2.0-3) and FFmpeg (7:5.1.3-1), so it is something else that has 
> recently changed in unstable that is causing the problem.

The error message is from gas, the relevant change is likely binutils 
which is now a snapshot from the upstream git master branch.

cu
Adrian

Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var

[Sean Whitton]

Hello,

On Tue 13 Jun 2023 at 05:58PM +01, Mark Hindley wrote:

> There is a new upstream version of elogind[1] that is already packaged in
> Devuan[2] although that uncovered up an upstream issue that I am waiting to be
> resolved[3]. So, maybe by the end of this month?
>
> However, that is only considering whether the packaging and dependencies can 
> be
> made to work (like Simon McVittie, I think they probably can).
>
> I remain much less convinced that there is a consensus for requiring packages 
> to
> use tmpfiles.d(5) for /var, /tmp and maybe /etc. The recent thread on
> debian-devel demonstrated a range of opinion. Thorsten and Bill have just 
> raised
> valid points about chroots.
>
> So, whilst I am happy to test the dependency changes in elogind, enshrining 
> this
> as a 'should' in the Policy now seems, at least, premature.

Cool, thank you.  This will simplify resolving this bug.

> Reading the proposed text as somebody who is particularly interested
> in non-systemd systems, I am struck by the inconsistency between
>
>   Init systems other than ``systemd`` should allow providing the same
>   functionality as appropriate for each system, for example managing the
>   directories from the init script shipped by the package.
>
> and the fact that we no longer expect packages to include init scripts 
> alongside
> their systemd units and even accept their removal, even if other interested
> people offer to maintain them and provide tested patches.

I'm sympathetic, though, this in itself is not a Policy issue.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1038163: rsyslog: make logcheck ignore file to match the new record format

[Michael Biebl]

Am 16.06.23 um 11:31 schrieb Alex Volkov:

Package: rsyslog
Version: 8.2302.0-1
Severity: normal

Dear Maintainer,

the included /etc/logcheck/ignore.d.server/rsyslog still uses the old
log line format, while the new "high-precision time" format is the default now.



I don't use logcheck so will require a patch for this.

Otherwise the only thing I can do is to remove the (broken) logcheck rules.

Michael


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1038105: upgrade-reports: resume from suspend/hibernate broken by upgrade from bullseye to bookworm

[Jeffrey Mark Siskind]

I have more information.

As per the suggestion of mooff , I noticed

qobi@sapiencia>ls -l /etc/modprobe.d/nvidia-options.conf
lrwxrwxrwx 1 root root 45 Sep  7  2022 /etc/modprobe.d/nvidia-options.conf -> 
/etc/alternatives/nvidia--nvidia-options.conf
qobi@sapiencia>ls -l /etc/alternatives/nvidia--nvidia-options.conf
lrwxrwxrwx 1 root root 49 Sep  7  2022 
/etc/alternatives/nvidia--nvidia-options.conf -> 
/etc/nvidia/nvidia-525.105.17/nvidia-options.conf

So I moved /etc/nvidia/nvidia-525.105.17/nvidia-options.conf to
/etc/nvidia/nvidia-525.105.17/nvidia-options.conf.orig and edited 
/etc/nvidia/nvidia-525.105.17/nvidia-options.conf to add

options nvidia-current NVreg_PreserveVideoMemoryAllocations=1

This prevented the machine from properly suspending/hibernating in the first
place. I know this because the Lenovo P71 has a red LED on the lid that is on
when the machine is running and pulsates when it is in
suspend/hibernation. Before I made the change it would pulsate when the lid
was closed. But after I made the change, th LED would stay on. But when I
would open the lid the screen would show the pasword request, and the mouse
would work, but the keyboard would no longer work. I would need to power cycle.

Searching the web, I found

https://unix.stackexchange.com/questions/743506/pop-os-22-04-with-nvidia-driver-525-fails-to-suspend-on-a-hybrid-laptop

So I tried changing /etc/nvidia/nvidia-525.105.17/nvidia-options.conf to
instead add

options nvidia-current NVreg_PreserveVideoMemoryAllocations=1 
NVreg_TemporaryFilePath=/var/tmp

I also did

sudo update-initramfs -u

But I observed the same behaviour where the LED would stay on when closing the
lid and the keyboard wouldn't work when opening the lid.

So I backed out the change and am back in a state where it appears to
suspend/hibernate (because the LED pulsates) but 30% of the time it properly
resumes and 70% of the time it does not (the disk light flashes a few times,
the screen is blank, and no response when using the keyboard or mouse.

I dont know if I should try putting it in

/etc/modprobe.d/nvidia-power-management.conf

instead. I haven't tried that yet.

Jeff (http: //engineering.purdue.edu/~qobi)

Bug#1038163: rsyslog: make logcheck ignore file to match the new record format

[Michael Biebl]

Am 16.06.23 um 12:10 schrieb Michael Biebl:

Am 16.06.23 um 11:31 schrieb Alex Volkov:

Package: rsyslog
Version: 8.2302.0-1
Severity: normal

Dear Maintainer,

the included /etc/logcheck/ignore.d.server/rsyslog still uses the old
log line format, while the new "high-precision time" format is the 
default now.



I don't use logcheck so will require a patch for this.

Otherwise the only thing I can do is to remove the (broken) logcheck rules.


Such a patch would should ideally support old and new timestamp format.



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1038107: upgrade-reports: bt Sony WM-1000XM4 issue upon upgrade from bullseye to bookworm

[Jeffrey Mark Siskind]

I have more information.

Output Device Headset - WF-1000XM4 gives stereo for all 4 options.

Output Device Handsfree - WF-1000XM4 gives mono for all 4 options.

While clicking Test for Output Device Handsfree - WF-1000XM4 gives noise for
all 3 options, it actually does work, when I tried Google Meet inside Google
Chrome. And I am able to simultaneously select

   Output Device Handsfree - WF-1000XM4
   Input Device Handsfree - WF-1000XM4

and get audio input and output in Google Meet inside Google Chrome.

I haven't tried all 3 codec options yet.

I haven't tried other programs yet.

Still, under buster and bullseye, I was able to get stereo audio output
simultaneous with audio input with Sony WF-1000XM4 bt. Now, I can only get
mono audio output simultaenous with audio input.

Jeff (http: //engineering.purdue.edu/~qobi)

Bug#1038166: php-imagick: on upgrades /etc/php/7.4/mods-available/imagick.ini is left behind

[Ondřej Surý]

You have just removed but not purged the php7.4 packages, so that’s expected.

--
Ondřej Surý  (He/Him)

> On 16. 6. 2023, at 11:39, Michael Prokop  wrote:
> 
> Package: php-imagick
> Version: 3.7.0-4
> Severity: important
> 
> Hi,
> 
> this might be related to #951847, I stumbled upon this behavior
> during an upgrade of a Debian system from bullseye to bookworm,
> where only file /etc/php/7.4/mods-available/imagick.ini is left
> behind.
> 
> System based on bullseye looking as follows:
> 
> | # ls -la /etc/php/7.4/mods-available/
> | total 92
> | drwxr-xr-x 2 root root 4096 Jun 16 09:15 .
> | drwxr-xr-x 5 root root 4096 Jun 16 09:15 ..
> | -rw-r--r-- 1 root root   74 Jun  9 16:51 calendar.ini
> | -rw-r--r-- 1 root root   71 Jun  9 16:51 ctype.ini
> | -rw-r--r-- 1 root root   70 Jun  9 16:51 exif.ini
> | -rw-r--r-- 1 root root   69 Jun  9 16:51 ffi.ini
> | -rw-r--r-- 1 root root   74 Jun  9 16:51 fileinfo.ini
> | -rw-r--r-- 1 root root   69 Jun  9 16:51 ftp.ini
> | -rw-r--r-- 1 root root   73 Jun  9 16:51 gettext.ini
> | -rw-r--r-- 1 root root   71 Jun  9 16:51 iconv.ini
> | -rw-r--r-- 1 root root   60 Mar  5  2021 imagick.ini
> | -rw-r--r-- 1 root root   68 Jun  9 16:51 json.ini
> | -rw-r--r-- 1 root root   79 Jun  9 16:51 opcache.ini
> | -rw-r--r-- 1 root root   69 Jun  9 16:51 pdo.ini
> | -rw-r--r-- 1 root root   70 Jun  9 16:51 phar.ini
> | -rw-r--r-- 1 root root   71 Jun  9 16:51 posix.ini
> | -rw-r--r-- 1 root root   76 Jun  9 16:51 readline.ini
> | -rw-r--r-- 1 root root   71 Jun  9 16:51 shmop.ini
> | -rw-r--r-- 1 root root   73 Jun  9 16:51 sockets.ini
> | -rw-r--r-- 1 root root   73 Jun  9 16:51 sysvmsg.ini
> | -rw-r--r-- 1 root root   73 Jun  9 16:51 sysvsem.ini
> | -rw-r--r-- 1 root root   73 Jun  9 16:51 sysvshm.ini
> | -rw-r--r-- 1 root root   75 Jun  9 16:51 tokenizer.ini
> | # cat /etc/php/7.4/mods-available/imagick.ini
> | ; configuration for php imagick module
> | extension=imagick.so
> 
> Then after upgrading the system to bookworm and applying
> configuration file cleanup:
> 
> | # dpkg -l | grep php
> | ii  php-common  2:93 all  
> Common files for PHP packages
> | ii  php-imagick 3.7.0-4  amd64
> Provides a wrapper to the ImageMagick library
> | rc  php7.4-cli  7.4.33-1+deb11u4 amd64
> command-line interpreter for the PHP scripting language
> | rc  php7.4-common   7.4.33-1+deb11u4 amd64
> documentation, examples and common module for PHP
> | rc  php7.4-json 7.4.33-1+deb11u4 amd64
> JSON module for PHP
> | rc  php7.4-opcache  7.4.33-1+deb11u4 amd64
> Zend OpCache module for PHP
> | rc  php7.4-phpdbg   7.4.33-1+deb11u4 amd64
> server-side, HTML-embedded scripting language (PHPDBG binary)
> | rc  php7.4-readline 7.4.33-1+deb11u4 amd64
> readline module for PHP
> | ii  php8.2-cli  8.2.7-1~deb12u1  amd64
> command-line interpreter for the PHP scripting language
> | ii  php8.2-common   8.2.7-1~deb12u1  amd64
> documentation, examples and common module for PHP
> | ii  php8.2-imagick  3.7.0-4  amd64
> Provides a wrapper to the ImageMagick library
> | ii  php8.2-opcache  8.2.7-1~deb12u1  amd64
> Zend OpCache module for PHP
> | ii  php8.2-phpdbg   8.2.7-1~deb12u1  amd64
> server-side, HTML-embedded scripting language (PHPDBG binary)
> | ii  php8.2-readline 8.2.7-1~deb12u1  amd64
> readline module for PHP
> | # dpkg --purge php7.4-cli php7.4-common php7.4-json php7.4-opcache 
> php7.4-phpdbg php7.4-readline
> | [...]
> 
> Then only `/etc/php/7.4/mods-available/imagick.ini` is left behind:
> 
> | # ls -la /etc/php/7.4/mods-available/
> | total 12
> | drwxr-xr-x 2 root root 4096 Jun 16 09:25 .
> | drwxr-xr-x 3 root root 4096 Jun 16 09:25 ..
> | -rw-r--r-- 1 root root   60 Mar  5  2021 imagick.ini
> |
> | # ls -la /etc/php/7.4/mods-available/imagick.ini
> | -rw-r--r-- 1 root root 60 Mar  5  2021
> | /etc/php/7.4/mods-available/imagick.ini
> | # dpkg -S /etc/php/7.4/mods-available/imagick.ini
> | php-imagick: /etc/php/7.4/mods-available/imagick.ini
> 
> Something feels wrong here?
> 
> FTR:
> 
> | # apt-cache policy php-imagick php8.2-imagick
> | php-imagick:
> |   Installed: 3.7.0-4
> |   Candidate: 3.7.0-4
> |   Version table:
> |  *** 3.7.0-4 500
> | 500 http://deb.debian.org/debian bookworm/main amd64 Packages
> | 100 /var/lib/dpkg/status
> | php8.2-imagick:
> |   Installed: 3.7.0-4
> |   Candidate: 3.7.0-4
> |   Version table:
> |  *** 3.7.0-4 500
> | 500 http://deb.debian.org/debian bookworm/main amd64 Packages
> | 100 /var/lib/dpkg/status
> |
> | # dpkg -L php-imagick
> | 

Bug#1037074: [Pkg-utopia-maintainers] Bug#1037074: upower.service failed to start with exit-code

[Michael Biebl]

Am 03.06.23 um 13:31 schrieb Michael Müller:


A direct execute brings this error:
/usr/libexec/upowerd: symbol lookup error: /usr/libexec/upowerd: undefined 
symbol: g_udev_device_get_sysfs_attr_uncached


...


ii  libgudev-1.0-0   1:230-3


Looking at the symbols file of libgudev, I see

 g_udev_device_get_sysfs_attr_as_boolean_uncached@Base 234

The generated dependency is too weak, due to the missing epoch, i.e. 
1:230-3 > 234.


This epoch is only applied to the Ubuntu build though.
Do you by any chance have libgudev installed from a Ubuntu archive?

https://packages.ubuntu.com/search?keywords=libgudev-1.0-0&searchon=names&suite=all§ion=all

vs

https://packages.debian.org/unstable/libgudev-1.0-0



Mixing Debian and Ubuntu packages is not a supported configuration.


Michael


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1037074: [Pkg-utopia-maintainers] Bug#1037074: upower.service failed to start with exit-code

[Michael Biebl]

Am 16.06.23 um 12:27 schrieb Michael Biebl:

Am 03.06.23 um 13:31 schrieb Michael Müller:


A direct execute brings this error:
/usr/libexec/upowerd: symbol lookup error: /usr/libexec/upowerd: 
undefined symbol: g_udev_device_get_sysfs_attr_uncached


...


ii  libgudev-1.0-0   1:230-3


Looking at the symbols file of libgudev, I see

  g_udev_device_get_sysfs_attr_as_boolean_uncached@Base 234

The generated dependency is too weak, due to the missing epoch, i.e. 
1:230-3 > 234.


This epoch is only applied to the Ubuntu build though.
Do you by any chance have libgudev installed from a Ubuntu archive?

https://packages.ubuntu.com/search?keywords=libgudev-1.0-0&searchon=names&suite=all§ion=all

vs

https://packages.debian.org/unstable/libgudev-1.0-0



Mixing Debian and Ubuntu packages is not a supported configuration.



This epoch that is applied to the Ubuntu build would also explain, why 
the package was not updated when you upgraded to bookworm.


If you have installed packages from the Ubuntu archive, you might 
consider reverting this.


Michael



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1003010: fonts-liberation2: please Provides fonts-liberation

[Fabian Greffrath]

Hi there,

sorry for the late reply!

Am Sonntag, dem 02.01.2022 um 20:44 +0200 schrieb Martin-Éric Racine:
> It would be desirable for fonts-liberation2 to Provides fonts-
> liberation so as to avoid installing two versions of essentially the
> same font.

First, strictly speaking fonts-liberation and fonts-liberation2 aren't
only two versions of the same font, but in fact tw different fonts.
Apart from the fact that both get installed into two different
locations in the file system (obviously), the v1 package contains one
more font family than the v2 package, i.e. Sans Narrow.

Second, what causes the situation that both fonts are installed at the
same time? Is it package dependencies and if yes, which packages cause
this? Because, well apart from Sans Narrow, there is no technical
reason to have both versions installed at the same time.

Cheers,

 - Fabian



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

Bug#1038167: RM: gnome-system-log -- ROM; unmaintained upstream, obsoleted by gnome-logs

[Simon McVittie]

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

gnome-system-log was marked as deprecated in 2014 (see #902973) and has
been superseded by gnome-logs. There are no reverse dependencies.

After the exact same version was released in Debian 10, 11 and 12,
I think it's time we remove it before Debian 13.

smcv

Bug#1038168: glom: unmaintained upstream

[Simon McVittie]

Source: glom
Severity: important
Tags: upstream wontfix

http://www.glom.org redirects to https://gitlab.gnome.org/Archive/glom
which has been archived, meaning that no more releases are possible and
bugs will not be fixed.

Bug#1038035: grub2: Depends on SDL 1.2

[Julian Andres Klode]

ControL tag -1 patch
Control: forwarded -1 
https://lists.gnu.org/archive/html/grub-devel/2023-06/msg00106.html

On Thu, Jun 15, 2023 at 04:09:57PM +0200, Julian Andres Klode wrote:
> Control: tag -1 confirmed upstream
> 
> On Thu, Jun 15, 2023 at 12:45:14PM +0100, Simon McVittie wrote:
> > Source: grub2
> > Tags: trixie sid
> > User: pkg-sdl-maintain...@lists.alioth.debian.org
> > Usertags: libsdl1.2
> > 
> > This package has a Depends or Build-Depends on SDL version 1.2, which
> > is unmaintained upstream. This is presumably only for grub-emu.
> > 
> > If possible, please port this package to SDL 2 and close this bug. There
> > is a migration guide at ,
> > and examples of successful ports from SDL 1.2 to SDL 2 can be found in
> > the commit history of packages like darkplaces and ioquake3.
> > 
> > If it is not possible to port to SDL 2, please test the package with
> > libsdl1.2-compat-shim (preferably version 1.2.64 or later), and leave
> > this bug open to track the package as still using SDL 1.2 APIs.
> > 
> > libsdl1.2-compat-shim is a compatibility layer that provides the SDL 1.2
> > API/ABI by using SDL 2: it has already replaced the "classic" SDL 1.2
> > library in some other distributions like Fedora and Arch, and my intention
> > is to do the same in Debian during the trixie release cycle.
> > 
> > The interesting scenarios to test with libsdl1.2-compat-shim are:
> > 
> > 1. Install libsdl1.2-compat-shim and run the program in an X11 environment,
> >such as "GNOME on Xorg" or XFCE.
> >($XDG_RUNTIME_DIR/wayland-* should not exist)
> > 2. Install libsdl1.2-compat-shim and run the program in a Wayland
> >environment such as GNOME's default mode, using Xwayland.
> >($XDG_RUNTIME_DIR/wayland-* should exist)
> > 3. Install libsdl1.2-compat-shim and run the program in a Wayland
> >environment, but this time with environment variable
> >SDL_VIDEODRIVER=wayland so that it uses the native Wayland interface
> >(this is not currently the default for SDL 2).
> > 4. Install libsdl1.2-compat-dev and recompile the package.
> 
> It works with the preload, so my preference right now is to rebuild with
> the compat -dev package for now, and try to solve SDL 2 upstream.

I just wrote a patch this morning to fix it:

https://lists.gnu.org/archive/html/grub-devel/2023-06/msg00106.html

-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en

Bug#1038166: php-imagick: on upgrades /etc/php/7.4/mods-available/imagick.ini is left behind

[Michael Prokop]

Hi,

* Ondřej Surý [Fri Jun 16, 2023 at 12:26:39PM +0200]:

> You have just removed but not purged the php7.4 packages, so that’s expected.

As stated, those are all php* packages that exist(ed) on the system:

> > | # dpkg -l | grep php
> > | ii  php-common  2:93 all  
> > Common files for PHP packages
> > | ii  php-imagick 3.7.0-4  amd64
> > Provides a wrapper to the ImageMagick library
> > | rc  php7.4-cli  7.4.33-1+deb11u4 amd64
> > command-line interpreter for the PHP scripting language
> > | rc  php7.4-common   7.4.33-1+deb11u4 amd64
> > documentation, examples and common module for PHP
> > | rc  php7.4-json 7.4.33-1+deb11u4 amd64
> > JSON module for PHP
> > | rc  php7.4-opcache  7.4.33-1+deb11u4 amd64
> > Zend OpCache module for PHP
> > | rc  php7.4-phpdbg   7.4.33-1+deb11u4 amd64
> > server-side, HTML-embedded scripting language (PHPDBG binary)
> > | rc  php7.4-readline 7.4.33-1+deb11u4 amd64
> > readline module for PHP
> > | ii  php8.2-cli  8.2.7-1~deb12u1  amd64
> > command-line interpreter for the PHP scripting language
> > | ii  php8.2-common   8.2.7-1~deb12u1  amd64
> > documentation, examples and common module for PHP
> > | ii  php8.2-imagick  3.7.0-4  amd64
> > Provides a wrapper to the ImageMagick library
> > | ii  php8.2-opcache  8.2.7-1~deb12u1  amd64
> > Zend OpCache module for PHP
> > | ii  php8.2-phpdbg   8.2.7-1~deb12u1  amd64
> > server-side, HTML-embedded scripting language (PHPDBG binary)
> > | ii  php8.2-readline 8.2.7-1~deb12u1  amd64
> > readline module for PHP

And I purged all of the php7.4 ones (as stated):

| root@d17a279d1015:/# dpkg -l | grep php
| ii  php-common  2:93 all  
Common files for PHP packages
| ii  php-imagick 3.7.0-4  amd64
Provides a wrapper to the ImageMagick library
| rc  php7.4-cli  7.4.33-1+deb11u4 amd64
command-line interpreter for the PHP scripting language
| rc  php7.4-common   7.4.33-1+deb11u4 amd64
documentation, examples and common module for PHP
| rc  php7.4-json 7.4.33-1+deb11u4 amd64
JSON module for PHP
| rc  php7.4-opcache  7.4.33-1+deb11u4 amd64
Zend OpCache module for PHP
| rc  php7.4-phpdbg   7.4.33-1+deb11u4 amd64
server-side, HTML-embedded scripting language (PHPDBG binary)
| rc  php7.4-readline 7.4.33-1+deb11u4 amd64
readline module for PHP
| ii  php8.2-cli  8.2.7-1~deb12u1  amd64
command-line interpreter for the PHP scripting language
| ii  php8.2-common   8.2.7-1~deb12u1  amd64
documentation, examples and common module for PHP
| ii  php8.2-imagick  3.7.0-4  amd64
Provides a wrapper to the ImageMagick library
| ii  php8.2-opcache  8.2.7-1~deb12u1  amd64
Zend OpCache module for PHP
| ii  php8.2-phpdbg   8.2.7-1~deb12u1  amd64
server-side, HTML-embedded scripting language (PHPDBG binary)
| ii  php8.2-readline 8.2.7-1~deb12u1  amd64
readline module for PHP
| root@d17a279d1015:/# dpkg --purge php7.4-cli php7.4-common php7.4-json 
php7.4-opcache php7.4-phpdbg php7.4-readline
| (Reading database ... 11733 files and directories currently installed.)
| Purging configuration files for php7.4-cli (7.4.33-1+deb11u4) ...
| Purging configuration files for php7.4-common (7.4.33-1+deb11u4) ...
| Purging configuration files for php7.4-json (7.4.33-1+deb11u4) ...
| dpkg: warning: while removing php7.4-json, directory 
'/etc/php/7.4/mods-available' not empty so not removed
| Purging configuration files for php7.4-opcache (7.4.33-1+deb11u4) ...
| Purging configuration files for php7.4-phpdbg (7.4.33-1+deb11u4) ...
| dpkg: warning: while removing php7.4-phpdbg, directory '/etc/php/7.4' not 
empty so not removed
| Purging configuration files for php7.4-readline (7.4.33-1+deb11u4) ...
| root@d17a279d1015:/# dpkg -l | grep php
| ii  php-common  2:93 all  
Common files for PHP packages
| ii  php-imagick 3.7.0-4  amd64
Provides a wrapper to the ImageMagick library
| ii  php8.2-cli  8.2.7-1~deb12u1  amd64
command-line interpreter for the PHP scripting language
| ii 

Bug#1038068: linux-image-6.3.0-1-amd64: vlc+dvb freezes when changing channels (systemd-shutdown hangs then due to VLC)

[Holger Schröder]

I have a similar problem with VDR. When you start the service vdr
immediate freeze. A normal reboot of the system is no longer possible.
The computer hangs on the service vdr.


Regards Holger...

Bug#1038169: RM: python-dicompylercore [s390x] -- ROM; FTBFS on big endian architectures

[Bas Couwenberg]

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

Please remove python-dicompylercore from s390x where it FTBFS due to test 
failures:

 https://github.com/dicompyler/dicompyler-core/issues/368

Kind Regards,

Bas

Bug#1038170: ceferino: Depends on SDL 1.2

[Simon McVittie]

Source: ceferino
Tags: trixie sid
User: pkg-sdl-maintain...@lists.alioth.debian.org
Usertags: libsdl1.2

This package has a Depends or Build-Depends on SDL version 1.2, which
is unmaintained upstream.

If possible, please port this package to SDL 2 and close this bug. There
is a migration guide at ,
and examples of successful ports from SDL 1.2 to SDL 2 can be found in
the commit history of packages like darkplaces and ioquake3.

If it is not possible to port to SDL 2, please test the package with
libsdl1.2-compat-shim (preferably version 1.2.64 or later), and leave
this bug open to track the package as still using SDL 1.2 APIs.

libsdl1.2-compat-shim is a compatibility layer that provides the SDL 1.2
API/ABI by using SDL 2: it has already replaced the "classic" SDL 1.2
library in some other distributions like Fedora and Arch, and my intention
is to do the same in Debian during the trixie release cycle.

It is *not* necessary to change dependencies from libsdl1.2debian to
libsdl1.2-compat-shim, or from libsdl1.2-dev to libsdl1.2-compat-dev.
My intention is to make a future version of sdl12-compat take over
the old package names, to minimize the changes that are required in
dependent packages.

The interesting scenarios to test with libsdl1.2-compat-shim are:

1. Install libsdl1.2-compat-shim and run the program in an X11 environment,
   such as "GNOME on Xorg" or XFCE.
   ($XDG_RUNTIME_DIR/wayland-* should not exist)
2. Install libsdl1.2-compat-shim and run the program in a Wayland
   environment such as GNOME's default mode, using Xwayland.
   ($XDG_RUNTIME_DIR/wayland-* should exist)
3. Install libsdl1.2-compat-shim and run the program in a Wayland
   environment, but this time with environment variable
   SDL_VIDEODRIVER=wayland so that it uses the native Wayland interface
   (this is not currently the default for SDL 2).
4. Install libsdl1.2-compat-dev and recompile the package.

Note that using libsdl1.2-compat and LD_LIBRARY_PATH is not sufficient if
the package contains programs that are setgid games. See

for more information.

If any of those fail, please report it as a bug in the
libsdl1.2-compat-shim or libsdl1.2-compat-dev package as appropriate,
with "affects" pointing to the program that is affected.

Thanks,
smcv

-- 
This bug report is part of a mass-bug-filing:

Bug#1038171: cheesecutter: Depends on SDL 1.2

[Simon McVittie]

Source: cheesecutter
Tags: trixie sid
User: pkg-sdl-maintain...@lists.alioth.debian.org
Usertags: libsdl1.2

This package has a Depends or Build-Depends on SDL version 1.2, which
is unmaintained upstream.

If possible, please port this package to SDL 2 and close this bug. There
is a migration guide at ,
and examples of successful ports from SDL 1.2 to SDL 2 can be found in
the commit history of packages like darkplaces and ioquake3.

If it is not possible to port to SDL 2, please test the package with
libsdl1.2-compat-shim (preferably version 1.2.64 or later), and leave
this bug open to track the package as still using SDL 1.2 APIs.

libsdl1.2-compat-shim is a compatibility layer that provides the SDL 1.2
API/ABI by using SDL 2: it has already replaced the "classic" SDL 1.2
library in some other distributions like Fedora and Arch, and my intention
is to do the same in Debian during the trixie release cycle.

It is *not* necessary to change dependencies from libsdl1.2debian to
libsdl1.2-compat-shim, or from libsdl1.2-dev to libsdl1.2-compat-dev.
My intention is to make a future version of sdl12-compat take over
the old package names, to minimize the changes that are required in
dependent packages.

The interesting scenarios to test with libsdl1.2-compat-shim are:

1. Install libsdl1.2-compat-shim and run the program in an X11 environment,
   such as "GNOME on Xorg" or XFCE.
   ($XDG_RUNTIME_DIR/wayland-* should not exist)
2. Install libsdl1.2-compat-shim and run the program in a Wayland
   environment such as GNOME's default mode, using Xwayland.
   ($XDG_RUNTIME_DIR/wayland-* should exist)
3. Install libsdl1.2-compat-shim and run the program in a Wayland
   environment, but this time with environment variable
   SDL_VIDEODRIVER=wayland so that it uses the native Wayland interface
   (this is not currently the default for SDL 2).
4. Install libsdl1.2-compat-dev and recompile the package.

Note that using libsdl1.2-compat and LD_LIBRARY_PATH is not sufficient if
the package contains programs that are setgid games. See

for more information.

If any of those fail, please report it as a bug in the
libsdl1.2-compat-shim or libsdl1.2-compat-dev package as appropriate,
with "affects" pointing to the program that is affected.

Thanks,
smcv

-- 
This bug report is part of a mass-bug-filing:

Bug#1038172: chroma: Depends on SDL 1.2

[Simon McVittie]

Source: chroma
Tags: trixie sid
User: pkg-sdl-maintain...@lists.alioth.debian.org
Usertags: libsdl1.2

This package has a Depends or Build-Depends on SDL version 1.2, which
is unmaintained upstream.

If possible, please port this package to SDL 2 and close this bug. There
is a migration guide at ,
and examples of successful ports from SDL 1.2 to SDL 2 can be found in
the commit history of packages like darkplaces and ioquake3.

If it is not possible to port to SDL 2, please test the package with
libsdl1.2-compat-shim (preferably version 1.2.64 or later), and leave
this bug open to track the package as still using SDL 1.2 APIs.

libsdl1.2-compat-shim is a compatibility layer that provides the SDL 1.2
API/ABI by using SDL 2: it has already replaced the "classic" SDL 1.2
library in some other distributions like Fedora and Arch, and my intention
is to do the same in Debian during the trixie release cycle.

It is *not* necessary to change dependencies from libsdl1.2debian to
libsdl1.2-compat-shim, or from libsdl1.2-dev to libsdl1.2-compat-dev.
My intention is to make a future version of sdl12-compat take over
the old package names, to minimize the changes that are required in
dependent packages.

The interesting scenarios to test with libsdl1.2-compat-shim are:

1. Install libsdl1.2-compat-shim and run the program in an X11 environment,
   such as "GNOME on Xorg" or XFCE.
   ($XDG_RUNTIME_DIR/wayland-* should not exist)
2. Install libsdl1.2-compat-shim and run the program in a Wayland
   environment such as GNOME's default mode, using Xwayland.
   ($XDG_RUNTIME_DIR/wayland-* should exist)
3. Install libsdl1.2-compat-shim and run the program in a Wayland
   environment, but this time with environment variable
   SDL_VIDEODRIVER=wayland so that it uses the native Wayland interface
   (this is not currently the default for SDL 2).
4. Install libsdl1.2-compat-dev and recompile the package.

Note that using libsdl1.2-compat and LD_LIBRARY_PATH is not sufficient if
the package contains programs that are setgid games. See

for more information.

If any of those fail, please report it as a bug in the
libsdl1.2-compat-shim or libsdl1.2-compat-dev package as appropriate,
with "affects" pointing to the program that is affected.

Thanks,
smcv

-- 
This bug report is part of a mass-bug-filing:

Bug#1038173: circuslinux: Depends on SDL 1.2

[Simon McVittie]

Source: circuslinux
Tags: trixie sid
User: pkg-sdl-maintain...@lists.alioth.debian.org
Usertags: libsdl1.2

This package has a Depends or Build-Depends on SDL version 1.2, which
is unmaintained upstream.

If possible, please port this package to SDL 2 and close this bug. There
is a migration guide at ,
and examples of successful ports from SDL 1.2 to SDL 2 can be found in
the commit history of packages like darkplaces and ioquake3.

If it is not possible to port to SDL 2, please test the package with
libsdl1.2-compat-shim (preferably version 1.2.64 or later), and leave
this bug open to track the package as still using SDL 1.2 APIs.

libsdl1.2-compat-shim is a compatibility layer that provides the SDL 1.2
API/ABI by using SDL 2: it has already replaced the "classic" SDL 1.2
library in some other distributions like Fedora and Arch, and my intention
is to do the same in Debian during the trixie release cycle.

It is *not* necessary to change dependencies from libsdl1.2debian to
libsdl1.2-compat-shim, or from libsdl1.2-dev to libsdl1.2-compat-dev.
My intention is to make a future version of sdl12-compat take over
the old package names, to minimize the changes that are required in
dependent packages.

The interesting scenarios to test with libsdl1.2-compat-shim are:

1. Install libsdl1.2-compat-shim and run the program in an X11 environment,
   such as "GNOME on Xorg" or XFCE.
   ($XDG_RUNTIME_DIR/wayland-* should not exist)
2. Install libsdl1.2-compat-shim and run the program in a Wayland
   environment such as GNOME's default mode, using Xwayland.
   ($XDG_RUNTIME_DIR/wayland-* should exist)
3. Install libsdl1.2-compat-shim and run the program in a Wayland
   environment, but this time with environment variable
   SDL_VIDEODRIVER=wayland so that it uses the native Wayland interface
   (this is not currently the default for SDL 2).
4. Install libsdl1.2-compat-dev and recompile the package.

Note that using libsdl1.2-compat and LD_LIBRARY_PATH is not sufficient if
the package contains programs that are setgid games. See

for more information.

If any of those fail, please report it as a bug in the
libsdl1.2-compat-shim or libsdl1.2-compat-dev package as appropriate,
with "affects" pointing to the program that is affected.

Thanks,
smcv

-- 
This bug report is part of a mass-bug-filing:

Bug#1038174: crack-attack: Depends on SDL 1.2

[Simon McVittie]

Source: crack-attack
Tags: trixie sid
User: pkg-sdl-maintain...@lists.alioth.debian.org
Usertags: libsdl1.2

This package has a Depends or Build-Depends on SDL version 1.2, which
is unmaintained upstream.

If possible, please port this package to SDL 2 and close this bug. There
is a migration guide at ,
and examples of successful ports from SDL 1.2 to SDL 2 can be found in
the commit history of packages like darkplaces and ioquake3.

If it is not possible to port to SDL 2, please test the package with
libsdl1.2-compat-shim (preferably version 1.2.64 or later), and leave
this bug open to track the package as still using SDL 1.2 APIs.

libsdl1.2-compat-shim is a compatibility layer that provides the SDL 1.2
API/ABI by using SDL 2: it has already replaced the "classic" SDL 1.2
library in some other distributions like Fedora and Arch, and my intention
is to do the same in Debian during the trixie release cycle.

It is *not* necessary to change dependencies from libsdl1.2debian to
libsdl1.2-compat-shim, or from libsdl1.2-dev to libsdl1.2-compat-dev.
My intention is to make a future version of sdl12-compat take over
the old package names, to minimize the changes that are required in
dependent packages.

The interesting scenarios to test with libsdl1.2-compat-shim are:

1. Install libsdl1.2-compat-shim and run the program in an X11 environment,
   such as "GNOME on Xorg" or XFCE.
   ($XDG_RUNTIME_DIR/wayland-* should not exist)
2. Install libsdl1.2-compat-shim and run the program in a Wayland
   environment such as GNOME's default mode, using Xwayland.
   ($XDG_RUNTIME_DIR/wayland-* should exist)
3. Install libsdl1.2-compat-shim and run the program in a Wayland
   environment, but this time with environment variable
   SDL_VIDEODRIVER=wayland so that it uses the native Wayland interface
   (this is not currently the default for SDL 2).
4. Install libsdl1.2-compat-dev and recompile the package.

Note that using libsdl1.2-compat and LD_LIBRARY_PATH is not sufficient if
the package contains programs that are setgid games. See

for more information.

If any of those fail, please report it as a bug in the
libsdl1.2-compat-shim or libsdl1.2-compat-dev package as appropriate,
with "affects" pointing to the program that is affected.

Thanks,
smcv

-- 
This bug report is part of a mass-bug-filing:

Bug#1038175: crimson: Depends on SDL 1.2

[Simon McVittie]

Source: crimson
Tags: trixie sid
User: pkg-sdl-maintain...@lists.alioth.debian.org
Usertags: libsdl1.2

This package has a Depends or Build-Depends on SDL version 1.2, which
is unmaintained upstream.

If possible, please port this package to SDL 2 and close this bug. There
is a migration guide at ,
and examples of successful ports from SDL 1.2 to SDL 2 can be found in
the commit history of packages like darkplaces and ioquake3.

If it is not possible to port to SDL 2, please test the package with
libsdl1.2-compat-shim (preferably version 1.2.64 or later), and leave
this bug open to track the package as still using SDL 1.2 APIs.

libsdl1.2-compat-shim is a compatibility layer that provides the SDL 1.2
API/ABI by using SDL 2: it has already replaced the "classic" SDL 1.2
library in some other distributions like Fedora and Arch, and my intention
is to do the same in Debian during the trixie release cycle.

It is *not* necessary to change dependencies from libsdl1.2debian to
libsdl1.2-compat-shim, or from libsdl1.2-dev to libsdl1.2-compat-dev.
My intention is to make a future version of sdl12-compat take over
the old package names, to minimize the changes that are required in
dependent packages.

The interesting scenarios to test with libsdl1.2-compat-shim are:

1. Install libsdl1.2-compat-shim and run the program in an X11 environment,
   such as "GNOME on Xorg" or XFCE.
   ($XDG_RUNTIME_DIR/wayland-* should not exist)
2. Install libsdl1.2-compat-shim and run the program in a Wayland
   environment such as GNOME's default mode, using Xwayland.
   ($XDG_RUNTIME_DIR/wayland-* should exist)
3. Install libsdl1.2-compat-shim and run the program in a Wayland
   environment, but this time with environment variable
   SDL_VIDEODRIVER=wayland so that it uses the native Wayland interface
   (this is not currently the default for SDL 2).
4. Install libsdl1.2-compat-dev and recompile the package.

Note that using libsdl1.2-compat and LD_LIBRARY_PATH is not sufficient if
the package contains programs that are setgid games. See

for more information.

If any of those fail, please report it as a bug in the
libsdl1.2-compat-shim or libsdl1.2-compat-dev package as appropriate,
with "affects" pointing to the program that is affected.

Thanks,
smcv

-- 
This bug report is part of a mass-bug-filing:

Bug#1038176: criticalmass: Depends on SDL 1.2

[Simon McVittie]

Source: criticalmass
Tags: trixie sid
User: pkg-sdl-maintain...@lists.alioth.debian.org
Usertags: libsdl1.2

This package has a Depends or Build-Depends on SDL version 1.2, which
is unmaintained upstream.

If possible, please port this package to SDL 2 and close this bug. There
is a migration guide at ,
and examples of successful ports from SDL 1.2 to SDL 2 can be found in
the commit history of packages like darkplaces and ioquake3.

If it is not possible to port to SDL 2, please test the package with
libsdl1.2-compat-shim (preferably version 1.2.64 or later), and leave
this bug open to track the package as still using SDL 1.2 APIs.

libsdl1.2-compat-shim is a compatibility layer that provides the SDL 1.2
API/ABI by using SDL 2: it has already replaced the "classic" SDL 1.2
library in some other distributions like Fedora and Arch, and my intention
is to do the same in Debian during the trixie release cycle.

It is *not* necessary to change dependencies from libsdl1.2debian to
libsdl1.2-compat-shim, or from libsdl1.2-dev to libsdl1.2-compat-dev.
My intention is to make a future version of sdl12-compat take over
the old package names, to minimize the changes that are required in
dependent packages.

The interesting scenarios to test with libsdl1.2-compat-shim are:

1. Install libsdl1.2-compat-shim and run the program in an X11 environment,
   such as "GNOME on Xorg" or XFCE.
   ($XDG_RUNTIME_DIR/wayland-* should not exist)
2. Install libsdl1.2-compat-shim and run the program in a Wayland
   environment such as GNOME's default mode, using Xwayland.
   ($XDG_RUNTIME_DIR/wayland-* should exist)
3. Install libsdl1.2-compat-shim and run the program in a Wayland
   environment, but this time with environment variable
   SDL_VIDEODRIVER=wayland so that it uses the native Wayland interface
   (this is not currently the default for SDL 2).
4. Install libsdl1.2-compat-dev and recompile the package.

Note that using libsdl1.2-compat and LD_LIBRARY_PATH is not sufficient if
the package contains programs that are setgid games. See

for more information.

If any of those fail, please report it as a bug in the
libsdl1.2-compat-shim or libsdl1.2-compat-dev package as appropriate,
with "affects" pointing to the program that is affected.

Thanks,
smcv

-- 
This bug report is part of a mass-bug-filing:

Bug#1038177: critterding: Depends on SDL 1.2

[Simon McVittie]

Source: critterding
Tags: trixie sid
User: pkg-sdl-maintain...@lists.alioth.debian.org
Usertags: libsdl1.2

This package has a Depends or Build-Depends on SDL version 1.2, which
is unmaintained upstream.

If possible, please port this package to SDL 2 and close this bug. There
is a migration guide at ,
and examples of successful ports from SDL 1.2 to SDL 2 can be found in
the commit history of packages like darkplaces and ioquake3.

If it is not possible to port to SDL 2, please test the package with
libsdl1.2-compat-shim (preferably version 1.2.64 or later), and leave
this bug open to track the package as still using SDL 1.2 APIs.

libsdl1.2-compat-shim is a compatibility layer that provides the SDL 1.2
API/ABI by using SDL 2: it has already replaced the "classic" SDL 1.2
library in some other distributions like Fedora and Arch, and my intention
is to do the same in Debian during the trixie release cycle.

It is *not* necessary to change dependencies from libsdl1.2debian to
libsdl1.2-compat-shim, or from libsdl1.2-dev to libsdl1.2-compat-dev.
My intention is to make a future version of sdl12-compat take over
the old package names, to minimize the changes that are required in
dependent packages.

The interesting scenarios to test with libsdl1.2-compat-shim are:

1. Install libsdl1.2-compat-shim and run the program in an X11 environment,
   such as "GNOME on Xorg" or XFCE.
   ($XDG_RUNTIME_DIR/wayland-* should not exist)
2. Install libsdl1.2-compat-shim and run the program in a Wayland
   environment such as GNOME's default mode, using Xwayland.
   ($XDG_RUNTIME_DIR/wayland-* should exist)
3. Install libsdl1.2-compat-shim and run the program in a Wayland
   environment, but this time with environment variable
   SDL_VIDEODRIVER=wayland so that it uses the native Wayland interface
   (this is not currently the default for SDL 2).
4. Install libsdl1.2-compat-dev and recompile the package.

Note that using libsdl1.2-compat and LD_LIBRARY_PATH is not sufficient if
the package contains programs that are setgid games. See

for more information.

If any of those fail, please report it as a bug in the
libsdl1.2-compat-shim or libsdl1.2-compat-dev package as appropriate,
with "affects" pointing to the program that is affected.

Thanks,
smcv

-- 
This bug report is part of a mass-bug-filing:

Bug#1038178: crossfire-client: Depends on SDL 1.2

[Simon McVittie]

Source: crossfire-client
Tags: trixie sid
User: pkg-sdl-maintain...@lists.alioth.debian.org
Usertags: libsdl1.2

This package has a Depends or Build-Depends on SDL version 1.2, which
is unmaintained upstream.

If possible, please port this package to SDL 2 and close this bug. There
is a migration guide at ,
and examples of successful ports from SDL 1.2 to SDL 2 can be found in
the commit history of packages like darkplaces and ioquake3.

If it is not possible to port to SDL 2, please test the package with
libsdl1.2-compat-shim (preferably version 1.2.64 or later), and leave
this bug open to track the package as still using SDL 1.2 APIs.

libsdl1.2-compat-shim is a compatibility layer that provides the SDL 1.2
API/ABI by using SDL 2: it has already replaced the "classic" SDL 1.2
library in some other distributions like Fedora and Arch, and my intention
is to do the same in Debian during the trixie release cycle.

It is *not* necessary to change dependencies from libsdl1.2debian to
libsdl1.2-compat-shim, or from libsdl1.2-dev to libsdl1.2-compat-dev.
My intention is to make a future version of sdl12-compat take over
the old package names, to minimize the changes that are required in
dependent packages.

The interesting scenarios to test with libsdl1.2-compat-shim are:

1. Install libsdl1.2-compat-shim and run the program in an X11 environment,
   such as "GNOME on Xorg" or XFCE.
   ($XDG_RUNTIME_DIR/wayland-* should not exist)
2. Install libsdl1.2-compat-shim and run the program in a Wayland
   environment such as GNOME's default mode, using Xwayland.
   ($XDG_RUNTIME_DIR/wayland-* should exist)
3. Install libsdl1.2-compat-shim and run the program in a Wayland
   environment, but this time with environment variable
   SDL_VIDEODRIVER=wayland so that it uses the native Wayland interface
   (this is not currently the default for SDL 2).
4. Install libsdl1.2-compat-dev and recompile the package.

Note that using libsdl1.2-compat and LD_LIBRARY_PATH is not sufficient if
the package contains programs that are setgid games. See

for more information.

If any of those fail, please report it as a bug in the
libsdl1.2-compat-shim or libsdl1.2-compat-dev package as appropriate,
with "affects" pointing to the program that is affected.

Thanks,
smcv

-- 
This bug report is part of a mass-bug-filing:

Bug#1038179: crrcsim: Depends on SDL 1.2

[Simon McVittie]

Source: crrcsim
Tags: trixie sid
User: pkg-sdl-maintain...@lists.alioth.debian.org
Usertags: libsdl1.2

This package has a Depends or Build-Depends on SDL version 1.2, which
is unmaintained upstream.

If possible, please port this package to SDL 2 and close this bug. There
is a migration guide at ,
and examples of successful ports from SDL 1.2 to SDL 2 can be found in
the commit history of packages like darkplaces and ioquake3.

If it is not possible to port to SDL 2, please test the package with
libsdl1.2-compat-shim (preferably version 1.2.64 or later), and leave
this bug open to track the package as still using SDL 1.2 APIs.

libsdl1.2-compat-shim is a compatibility layer that provides the SDL 1.2
API/ABI by using SDL 2: it has already replaced the "classic" SDL 1.2
library in some other distributions like Fedora and Arch, and my intention
is to do the same in Debian during the trixie release cycle.

It is *not* necessary to change dependencies from libsdl1.2debian to
libsdl1.2-compat-shim, or from libsdl1.2-dev to libsdl1.2-compat-dev.
My intention is to make a future version of sdl12-compat take over
the old package names, to minimize the changes that are required in
dependent packages.

The interesting scenarios to test with libsdl1.2-compat-shim are:

1. Install libsdl1.2-compat-shim and run the program in an X11 environment,
   such as "GNOME on Xorg" or XFCE.
   ($XDG_RUNTIME_DIR/wayland-* should not exist)
2. Install libsdl1.2-compat-shim and run the program in a Wayland
   environment such as GNOME's default mode, using Xwayland.
   ($XDG_RUNTIME_DIR/wayland-* should exist)
3. Install libsdl1.2-compat-shim and run the program in a Wayland
   environment, but this time with environment variable
   SDL_VIDEODRIVER=wayland so that it uses the native Wayland interface
   (this is not currently the default for SDL 2).
4. Install libsdl1.2-compat-dev and recompile the package.

Note that using libsdl1.2-compat and LD_LIBRARY_PATH is not sufficient if
the package contains programs that are setgid games. See

for more information.

If any of those fail, please report it as a bug in the
libsdl1.2-compat-shim or libsdl1.2-compat-dev package as appropriate,
with "affects" pointing to the program that is affected.

Thanks,
smcv

-- 
This bug report is part of a mass-bug-filing:

Bug#1038180: csmash: Depends on SDL 1.2

[Simon McVittie]

Source: csmash
Tags: trixie sid
User: pkg-sdl-maintain...@lists.alioth.debian.org
Usertags: libsdl1.2

This package has a Depends or Build-Depends on SDL version 1.2, which
is unmaintained upstream.

If possible, please port this package to SDL 2 and close this bug. There
is a migration guide at ,
and examples of successful ports from SDL 1.2 to SDL 2 can be found in
the commit history of packages like darkplaces and ioquake3.

If it is not possible to port to SDL 2, please test the package with
libsdl1.2-compat-shim (preferably version 1.2.64 or later), and leave
this bug open to track the package as still using SDL 1.2 APIs.

libsdl1.2-compat-shim is a compatibility layer that provides the SDL 1.2
API/ABI by using SDL 2: it has already replaced the "classic" SDL 1.2
library in some other distributions like Fedora and Arch, and my intention
is to do the same in Debian during the trixie release cycle.

It is *not* necessary to change dependencies from libsdl1.2debian to
libsdl1.2-compat-shim, or from libsdl1.2-dev to libsdl1.2-compat-dev.
My intention is to make a future version of sdl12-compat take over
the old package names, to minimize the changes that are required in
dependent packages.

The interesting scenarios to test with libsdl1.2-compat-shim are:

1. Install libsdl1.2-compat-shim and run the program in an X11 environment,
   such as "GNOME on Xorg" or XFCE.
   ($XDG_RUNTIME_DIR/wayland-* should not exist)
2. Install libsdl1.2-compat-shim and run the program in a Wayland
   environment such as GNOME's default mode, using Xwayland.
   ($XDG_RUNTIME_DIR/wayland-* should exist)
3. Install libsdl1.2-compat-shim and run the program in a Wayland
   environment, but this time with environment variable
   SDL_VIDEODRIVER=wayland so that it uses the native Wayland interface
   (this is not currently the default for SDL 2).
4. Install libsdl1.2-compat-dev and recompile the package.

Note that using libsdl1.2-compat and LD_LIBRARY_PATH is not sufficient if
the package contains programs that are setgid games. See

for more information.

If any of those fail, please report it as a bug in the
libsdl1.2-compat-shim or libsdl1.2-compat-dev package as appropriate,
with "affects" pointing to the program that is affected.

Thanks,
smcv

-- 
This bug report is part of a mass-bug-filing:

Bug#1038181: cuyo: Depends on SDL 1.2

[Simon McVittie]

Source: cuyo
Tags: trixie sid
User: pkg-sdl-maintain...@lists.alioth.debian.org
Usertags: libsdl1.2

This package has a Depends or Build-Depends on SDL version 1.2, which
is unmaintained upstream.

If possible, please port this package to SDL 2 and close this bug. There
is a migration guide at ,
and examples of successful ports from SDL 1.2 to SDL 2 can be found in
the commit history of packages like darkplaces and ioquake3.

If it is not possible to port to SDL 2, please test the package with
libsdl1.2-compat-shim (preferably version 1.2.64 or later), and leave
this bug open to track the package as still using SDL 1.2 APIs.

libsdl1.2-compat-shim is a compatibility layer that provides the SDL 1.2
API/ABI by using SDL 2: it has already replaced the "classic" SDL 1.2
library in some other distributions like Fedora and Arch, and my intention
is to do the same in Debian during the trixie release cycle.

It is *not* necessary to change dependencies from libsdl1.2debian to
libsdl1.2-compat-shim, or from libsdl1.2-dev to libsdl1.2-compat-dev.
My intention is to make a future version of sdl12-compat take over
the old package names, to minimize the changes that are required in
dependent packages.

The interesting scenarios to test with libsdl1.2-compat-shim are:

1. Install libsdl1.2-compat-shim and run the program in an X11 environment,
   such as "GNOME on Xorg" or XFCE.
   ($XDG_RUNTIME_DIR/wayland-* should not exist)
2. Install libsdl1.2-compat-shim and run the program in a Wayland
   environment such as GNOME's default mode, using Xwayland.
   ($XDG_RUNTIME_DIR/wayland-* should exist)
3. Install libsdl1.2-compat-shim and run the program in a Wayland
   environment, but this time with environment variable
   SDL_VIDEODRIVER=wayland so that it uses the native Wayland interface
   (this is not currently the default for SDL 2).
4. Install libsdl1.2-compat-dev and recompile the package.

Note that using libsdl1.2-compat and LD_LIBRARY_PATH is not sufficient if
the package contains programs that are setgid games. See

for more information.

If any of those fail, please report it as a bug in the
libsdl1.2-compat-shim or libsdl1.2-compat-dev package as appropriate,
with "affects" pointing to the program that is affected.

Thanks,
smcv

-- 
This bug report is part of a mass-bug-filing:

Bug#1038182: cytadela: Depends on SDL 1.2

[Simon McVittie]

Source: cytadela
Tags: trixie sid
User: pkg-sdl-maintain...@lists.alioth.debian.org
Usertags: libsdl1.2

This package has a Depends or Build-Depends on SDL version 1.2, which
is unmaintained upstream.

If possible, please port this package to SDL 2 and close this bug. There
is a migration guide at ,
and examples of successful ports from SDL 1.2 to SDL 2 can be found in
the commit history of packages like darkplaces and ioquake3.

If it is not possible to port to SDL 2, please test the package with
libsdl1.2-compat-shim (preferably version 1.2.64 or later), and leave
this bug open to track the package as still using SDL 1.2 APIs.

libsdl1.2-compat-shim is a compatibility layer that provides the SDL 1.2
API/ABI by using SDL 2: it has already replaced the "classic" SDL 1.2
library in some other distributions like Fedora and Arch, and my intention
is to do the same in Debian during the trixie release cycle.

It is *not* necessary to change dependencies from libsdl1.2debian to
libsdl1.2-compat-shim, or from libsdl1.2-dev to libsdl1.2-compat-dev.
My intention is to make a future version of sdl12-compat take over
the old package names, to minimize the changes that are required in
dependent packages.

The interesting scenarios to test with libsdl1.2-compat-shim are:

1. Install libsdl1.2-compat-shim and run the program in an X11 environment,
   such as "GNOME on Xorg" or XFCE.
   ($XDG_RUNTIME_DIR/wayland-* should not exist)
2. Install libsdl1.2-compat-shim and run the program in a Wayland
   environment such as GNOME's default mode, using Xwayland.
   ($XDG_RUNTIME_DIR/wayland-* should exist)
3. Install libsdl1.2-compat-shim and run the program in a Wayland
   environment, but this time with environment variable
   SDL_VIDEODRIVER=wayland so that it uses the native Wayland interface
   (this is not currently the default for SDL 2).
4. Install libsdl1.2-compat-dev and recompile the package.

Note that using libsdl1.2-compat and LD_LIBRARY_PATH is not sufficient if
the package contains programs that are setgid games. See

for more information.

If any of those fail, please report it as a bug in the
libsdl1.2-compat-shim or libsdl1.2-compat-dev package as appropriate,
with "affects" pointing to the program that is affected.

Thanks,
smcv

-- 
This bug report is part of a mass-bug-filing:

Bug#1038183: d1x-rebirth: Depends on SDL 1.2

[Simon McVittie]

Source: d1x-rebirth
Tags: trixie sid
User: pkg-sdl-maintain...@lists.alioth.debian.org
Usertags: libsdl1.2

This package has a Depends or Build-Depends on SDL version 1.2, which
is unmaintained upstream.

If possible, please port this package to SDL 2 and close this bug. There
is a migration guide at ,
and examples of successful ports from SDL 1.2 to SDL 2 can be found in
the commit history of packages like darkplaces and ioquake3.

If it is not possible to port to SDL 2, please test the package with
libsdl1.2-compat-shim (preferably version 1.2.64 or later), and leave
this bug open to track the package as still using SDL 1.2 APIs.

libsdl1.2-compat-shim is a compatibility layer that provides the SDL 1.2
API/ABI by using SDL 2: it has already replaced the "classic" SDL 1.2
library in some other distributions like Fedora and Arch, and my intention
is to do the same in Debian during the trixie release cycle.

It is *not* necessary to change dependencies from libsdl1.2debian to
libsdl1.2-compat-shim, or from libsdl1.2-dev to libsdl1.2-compat-dev.
My intention is to make a future version of sdl12-compat take over
the old package names, to minimize the changes that are required in
dependent packages.

The interesting scenarios to test with libsdl1.2-compat-shim are:

1. Install libsdl1.2-compat-shim and run the program in an X11 environment,
   such as "GNOME on Xorg" or XFCE.
   ($XDG_RUNTIME_DIR/wayland-* should not exist)
2. Install libsdl1.2-compat-shim and run the program in a Wayland
   environment such as GNOME's default mode, using Xwayland.
   ($XDG_RUNTIME_DIR/wayland-* should exist)
3. Install libsdl1.2-compat-shim and run the program in a Wayland
   environment, but this time with environment variable
   SDL_VIDEODRIVER=wayland so that it uses the native Wayland interface
   (this is not currently the default for SDL 2).
4. Install libsdl1.2-compat-dev and recompile the package.

Note that using libsdl1.2-compat and LD_LIBRARY_PATH is not sufficient if
the package contains programs that are setgid games. See

for more information.

If any of those fail, please report it as a bug in the
libsdl1.2-compat-shim or libsdl1.2-compat-dev package as appropriate,
with "affects" pointing to the program that is affected.

Thanks,
smcv

-- 
This bug report is part of a mass-bug-filing:

Bug#1038184: d2x-rebirth: Depends on SDL 1.2

[Simon McVittie]

Source: d2x-rebirth
Tags: trixie sid
User: pkg-sdl-maintain...@lists.alioth.debian.org
Usertags: libsdl1.2

This package has a Depends or Build-Depends on SDL version 1.2, which
is unmaintained upstream.

If possible, please port this package to SDL 2 and close this bug. There
is a migration guide at ,
and examples of successful ports from SDL 1.2 to SDL 2 can be found in
the commit history of packages like darkplaces and ioquake3.

If it is not possible to port to SDL 2, please test the package with
libsdl1.2-compat-shim (preferably version 1.2.64 or later), and leave
this bug open to track the package as still using SDL 1.2 APIs.

libsdl1.2-compat-shim is a compatibility layer that provides the SDL 1.2
API/ABI by using SDL 2: it has already replaced the "classic" SDL 1.2
library in some other distributions like Fedora and Arch, and my intention
is to do the same in Debian during the trixie release cycle.

It is *not* necessary to change dependencies from libsdl1.2debian to
libsdl1.2-compat-shim, or from libsdl1.2-dev to libsdl1.2-compat-dev.
My intention is to make a future version of sdl12-compat take over
the old package names, to minimize the changes that are required in
dependent packages.

The interesting scenarios to test with libsdl1.2-compat-shim are:

1. Install libsdl1.2-compat-shim and run the program in an X11 environment,
   such as "GNOME on Xorg" or XFCE.
   ($XDG_RUNTIME_DIR/wayland-* should not exist)
2. Install libsdl1.2-compat-shim and run the program in a Wayland
   environment such as GNOME's default mode, using Xwayland.
   ($XDG_RUNTIME_DIR/wayland-* should exist)
3. Install libsdl1.2-compat-shim and run the program in a Wayland
   environment, but this time with environment variable
   SDL_VIDEODRIVER=wayland so that it uses the native Wayland interface
   (this is not currently the default for SDL 2).
4. Install libsdl1.2-compat-dev and recompile the package.

Note that using libsdl1.2-compat and LD_LIBRARY_PATH is not sufficient if
the package contains programs that are setgid games. See

for more information.

If any of those fail, please report it as a bug in the
libsdl1.2-compat-shim or libsdl1.2-compat-dev package as appropriate,
with "affects" pointing to the program that is affected.

Thanks,
smcv

-- 
This bug report is part of a mass-bug-filing:

Bug#1038185: dangen: Depends on SDL 1.2

[Simon McVittie]

Source: dangen
Tags: trixie sid
User: pkg-sdl-maintain...@lists.alioth.debian.org
Usertags: libsdl1.2

This package has a Depends or Build-Depends on SDL version 1.2, which
is unmaintained upstream.

If possible, please port this package to SDL 2 and close this bug. There
is a migration guide at ,
and examples of successful ports from SDL 1.2 to SDL 2 can be found in
the commit history of packages like darkplaces and ioquake3.

If it is not possible to port to SDL 2, please test the package with
libsdl1.2-compat-shim (preferably version 1.2.64 or later), and leave
this bug open to track the package as still using SDL 1.2 APIs.

libsdl1.2-compat-shim is a compatibility layer that provides the SDL 1.2
API/ABI by using SDL 2: it has already replaced the "classic" SDL 1.2
library in some other distributions like Fedora and Arch, and my intention
is to do the same in Debian during the trixie release cycle.

It is *not* necessary to change dependencies from libsdl1.2debian to
libsdl1.2-compat-shim, or from libsdl1.2-dev to libsdl1.2-compat-dev.
My intention is to make a future version of sdl12-compat take over
the old package names, to minimize the changes that are required in
dependent packages.

The interesting scenarios to test with libsdl1.2-compat-shim are:

1. Install libsdl1.2-compat-shim and run the program in an X11 environment,
   such as "GNOME on Xorg" or XFCE.
   ($XDG_RUNTIME_DIR/wayland-* should not exist)
2. Install libsdl1.2-compat-shim and run the program in a Wayland
   environment such as GNOME's default mode, using Xwayland.
   ($XDG_RUNTIME_DIR/wayland-* should exist)
3. Install libsdl1.2-compat-shim and run the program in a Wayland
   environment, but this time with environment variable
   SDL_VIDEODRIVER=wayland so that it uses the native Wayland interface
   (this is not currently the default for SDL 2).
4. Install libsdl1.2-compat-dev and recompile the package.

Note that using libsdl1.2-compat and LD_LIBRARY_PATH is not sufficient if
the package contains programs that are setgid games. See

for more information.

If any of those fail, please report it as a bug in the
libsdl1.2-compat-shim or libsdl1.2-compat-dev package as appropriate,
with "affects" pointing to the program that is affected.

Thanks,
smcv

-- 
This bug report is part of a mass-bug-filing:

Bug#1038186: dd2: Depends on SDL 1.2

[Simon McVittie]

Source: dd2
Tags: trixie sid
User: pkg-sdl-maintain...@lists.alioth.debian.org
Usertags: libsdl1.2

This package has a Depends or Build-Depends on SDL version 1.2, which
is unmaintained upstream.

If possible, please port this package to SDL 2 and close this bug. There
is a migration guide at ,
and examples of successful ports from SDL 1.2 to SDL 2 can be found in
the commit history of packages like darkplaces and ioquake3.

If it is not possible to port to SDL 2, please test the package with
libsdl1.2-compat-shim (preferably version 1.2.64 or later), and leave
this bug open to track the package as still using SDL 1.2 APIs.

libsdl1.2-compat-shim is a compatibility layer that provides the SDL 1.2
API/ABI by using SDL 2: it has already replaced the "classic" SDL 1.2
library in some other distributions like Fedora and Arch, and my intention
is to do the same in Debian during the trixie release cycle.

It is *not* necessary to change dependencies from libsdl1.2debian to
libsdl1.2-compat-shim, or from libsdl1.2-dev to libsdl1.2-compat-dev.
My intention is to make a future version of sdl12-compat take over
the old package names, to minimize the changes that are required in
dependent packages.

The interesting scenarios to test with libsdl1.2-compat-shim are:

1. Install libsdl1.2-compat-shim and run the program in an X11 environment,
   such as "GNOME on Xorg" or XFCE.
   ($XDG_RUNTIME_DIR/wayland-* should not exist)
2. Install libsdl1.2-compat-shim and run the program in a Wayland
   environment such as GNOME's default mode, using Xwayland.
   ($XDG_RUNTIME_DIR/wayland-* should exist)
3. Install libsdl1.2-compat-shim and run the program in a Wayland
   environment, but this time with environment variable
   SDL_VIDEODRIVER=wayland so that it uses the native Wayland interface
   (this is not currently the default for SDL 2).
4. Install libsdl1.2-compat-dev and recompile the package.

Note that using libsdl1.2-compat and LD_LIBRARY_PATH is not sufficient if
the package contains programs that are setgid games. See

for more information.

If any of those fail, please report it as a bug in the
libsdl1.2-compat-shim or libsdl1.2-compat-dev package as appropriate,
with "affects" pointing to the program that is affected.

Thanks,
smcv

-- 
This bug report is part of a mass-bug-filing:

Bug#1038187: desmume: Depends on SDL 1.2

[Simon McVittie]

Source: desmume
Tags: trixie sid
User: pkg-sdl-maintain...@lists.alioth.debian.org
Usertags: libsdl1.2

This package has a Depends or Build-Depends on SDL version 1.2, which
is unmaintained upstream.

If possible, please port this package to SDL 2 and close this bug. There
is a migration guide at ,
and examples of successful ports from SDL 1.2 to SDL 2 can be found in
the commit history of packages like darkplaces and ioquake3.

If it is not possible to port to SDL 2, please test the package with
libsdl1.2-compat-shim (preferably version 1.2.64 or later), and leave
this bug open to track the package as still using SDL 1.2 APIs.

libsdl1.2-compat-shim is a compatibility layer that provides the SDL 1.2
API/ABI by using SDL 2: it has already replaced the "classic" SDL 1.2
library in some other distributions like Fedora and Arch, and my intention
is to do the same in Debian during the trixie release cycle.

It is *not* necessary to change dependencies from libsdl1.2debian to
libsdl1.2-compat-shim, or from libsdl1.2-dev to libsdl1.2-compat-dev.
My intention is to make a future version of sdl12-compat take over
the old package names, to minimize the changes that are required in
dependent packages.

The interesting scenarios to test with libsdl1.2-compat-shim are:

1. Install libsdl1.2-compat-shim and run the program in an X11 environment,
   such as "GNOME on Xorg" or XFCE.
   ($XDG_RUNTIME_DIR/wayland-* should not exist)
2. Install libsdl1.2-compat-shim and run the program in a Wayland
   environment such as GNOME's default mode, using Xwayland.
   ($XDG_RUNTIME_DIR/wayland-* should exist)
3. Install libsdl1.2-compat-shim and run the program in a Wayland
   environment, but this time with environment variable
   SDL_VIDEODRIVER=wayland so that it uses the native Wayland interface
   (this is not currently the default for SDL 2).
4. Install libsdl1.2-compat-dev and recompile the package.

Note that using libsdl1.2-compat and LD_LIBRARY_PATH is not sufficient if
the package contains programs that are setgid games. See

for more information.

If any of those fail, please report it as a bug in the
libsdl1.2-compat-shim or libsdl1.2-compat-dev package as appropriate,
with "affects" pointing to the program that is affected.

Thanks,
smcv

-- 
This bug report is part of a mass-bug-filing:

Bug#1038188: devil: Depends on SDL 1.2

[Simon McVittie]

Source: devil
Tags: trixie sid
User: pkg-sdl-maintain...@lists.alioth.debian.org
Usertags: libsdl1.2

This package has a Depends or Build-Depends on SDL version 1.2, which
is unmaintained upstream.

If possible, please port this package to SDL 2 and close this bug. There
is a migration guide at ,
and examples of successful ports from SDL 1.2 to SDL 2 can be found in
the commit history of packages like darkplaces and ioquake3.

If it is not possible to port to SDL 2, please test the package with
libsdl1.2-compat-shim (preferably version 1.2.64 or later), and leave
this bug open to track the package as still using SDL 1.2 APIs.

libsdl1.2-compat-shim is a compatibility layer that provides the SDL 1.2
API/ABI by using SDL 2: it has already replaced the "classic" SDL 1.2
library in some other distributions like Fedora and Arch, and my intention
is to do the same in Debian during the trixie release cycle.

It is *not* necessary to change dependencies from libsdl1.2debian to
libsdl1.2-compat-shim, or from libsdl1.2-dev to libsdl1.2-compat-dev.
My intention is to make a future version of sdl12-compat take over
the old package names, to minimize the changes that are required in
dependent packages.

The interesting scenarios to test with libsdl1.2-compat-shim are:

1. Install libsdl1.2-compat-shim and run the program in an X11 environment,
   such as "GNOME on Xorg" or XFCE.
   ($XDG_RUNTIME_DIR/wayland-* should not exist)
2. Install libsdl1.2-compat-shim and run the program in a Wayland
   environment such as GNOME's default mode, using Xwayland.
   ($XDG_RUNTIME_DIR/wayland-* should exist)
3. Install libsdl1.2-compat-shim and run the program in a Wayland
   environment, but this time with environment variable
   SDL_VIDEODRIVER=wayland so that it uses the native Wayland interface
   (this is not currently the default for SDL 2).
4. Install libsdl1.2-compat-dev and recompile the package.

Note that using libsdl1.2-compat and LD_LIBRARY_PATH is not sufficient if
the package contains programs that are setgid games. See

for more information.

If any of those fail, please report it as a bug in the
libsdl1.2-compat-shim or libsdl1.2-compat-dev package as appropriate,
with "affects" pointing to the program that is affected.

Thanks,
smcv

-- 
This bug report is part of a mass-bug-filing:

Bug#1038189: dgen: Depends on SDL 1.2

[Simon McVittie]

Source: dgen
Tags: trixie sid
User: pkg-sdl-maintain...@lists.alioth.debian.org
Usertags: libsdl1.2

This package has a Depends or Build-Depends on SDL version 1.2, which
is unmaintained upstream.

If possible, please port this package to SDL 2 and close this bug. There
is a migration guide at ,
and examples of successful ports from SDL 1.2 to SDL 2 can be found in
the commit history of packages like darkplaces and ioquake3.

If it is not possible to port to SDL 2, please test the package with
libsdl1.2-compat-shim (preferably version 1.2.64 or later), and leave
this bug open to track the package as still using SDL 1.2 APIs.

libsdl1.2-compat-shim is a compatibility layer that provides the SDL 1.2
API/ABI by using SDL 2: it has already replaced the "classic" SDL 1.2
library in some other distributions like Fedora and Arch, and my intention
is to do the same in Debian during the trixie release cycle.

It is *not* necessary to change dependencies from libsdl1.2debian to
libsdl1.2-compat-shim, or from libsdl1.2-dev to libsdl1.2-compat-dev.
My intention is to make a future version of sdl12-compat take over
the old package names, to minimize the changes that are required in
dependent packages.

The interesting scenarios to test with libsdl1.2-compat-shim are:

1. Install libsdl1.2-compat-shim and run the program in an X11 environment,
   such as "GNOME on Xorg" or XFCE.
   ($XDG_RUNTIME_DIR/wayland-* should not exist)
2. Install libsdl1.2-compat-shim and run the program in a Wayland
   environment such as GNOME's default mode, using Xwayland.
   ($XDG_RUNTIME_DIR/wayland-* should exist)
3. Install libsdl1.2-compat-shim and run the program in a Wayland
   environment, but this time with environment variable
   SDL_VIDEODRIVER=wayland so that it uses the native Wayland interface
   (this is not currently the default for SDL 2).
4. Install libsdl1.2-compat-dev and recompile the package.

Note that using libsdl1.2-compat and LD_LIBRARY_PATH is not sufficient if
the package contains programs that are setgid games. See

for more information.

If any of those fail, please report it as a bug in the
libsdl1.2-compat-shim or libsdl1.2-compat-dev package as appropriate,
with "affects" pointing to the program that is affected.

Thanks,
smcv

-- 
This bug report is part of a mass-bug-filing:

Bug#1038190: din: Depends on SDL 1.2

[Simon McVittie]

Source: din
Tags: trixie sid
User: pkg-sdl-maintain...@lists.alioth.debian.org
Usertags: libsdl1.2

This package has a Depends or Build-Depends on SDL version 1.2, which
is unmaintained upstream.

If possible, please port this package to SDL 2 and close this bug. There
is a migration guide at ,
and examples of successful ports from SDL 1.2 to SDL 2 can be found in
the commit history of packages like darkplaces and ioquake3.

If it is not possible to port to SDL 2, please test the package with
libsdl1.2-compat-shim (preferably version 1.2.64 or later), and leave
this bug open to track the package as still using SDL 1.2 APIs.

libsdl1.2-compat-shim is a compatibility layer that provides the SDL 1.2
API/ABI by using SDL 2: it has already replaced the "classic" SDL 1.2
library in some other distributions like Fedora and Arch, and my intention
is to do the same in Debian during the trixie release cycle.

It is *not* necessary to change dependencies from libsdl1.2debian to
libsdl1.2-compat-shim, or from libsdl1.2-dev to libsdl1.2-compat-dev.
My intention is to make a future version of sdl12-compat take over
the old package names, to minimize the changes that are required in
dependent packages.

The interesting scenarios to test with libsdl1.2-compat-shim are:

1. Install libsdl1.2-compat-shim and run the program in an X11 environment,
   such as "GNOME on Xorg" or XFCE.
   ($XDG_RUNTIME_DIR/wayland-* should not exist)
2. Install libsdl1.2-compat-shim and run the program in a Wayland
   environment such as GNOME's default mode, using Xwayland.
   ($XDG_RUNTIME_DIR/wayland-* should exist)
3. Install libsdl1.2-compat-shim and run the program in a Wayland
   environment, but this time with environment variable
   SDL_VIDEODRIVER=wayland so that it uses the native Wayland interface
   (this is not currently the default for SDL 2).
4. Install libsdl1.2-compat-dev and recompile the package.

Note that using libsdl1.2-compat and LD_LIBRARY_PATH is not sufficient if
the package contains programs that are setgid games. See

for more information.

If any of those fail, please report it as a bug in the
libsdl1.2-compat-shim or libsdl1.2-compat-dev package as appropriate,
with "affects" pointing to the program that is affected.

Thanks,
smcv

-- 
This bug report is part of a mass-bug-filing:

Bug#1038191: dosbox: Depends on SDL 1.2

[Simon McVittie]

Source: dosbox
Tags: trixie sid
User: pkg-sdl-maintain...@lists.alioth.debian.org
Usertags: libsdl1.2

This package has a Depends or Build-Depends on SDL version 1.2, which
is unmaintained upstream.

If possible, please port this package to SDL 2 and close this bug. There
is a migration guide at ,
and examples of successful ports from SDL 1.2 to SDL 2 can be found in
the commit history of packages like darkplaces and ioquake3.

If it is not possible to port to SDL 2, please test the package with
libsdl1.2-compat-shim (preferably version 1.2.64 or later), and leave
this bug open to track the package as still using SDL 1.2 APIs.

libsdl1.2-compat-shim is a compatibility layer that provides the SDL 1.2
API/ABI by using SDL 2: it has already replaced the "classic" SDL 1.2
library in some other distributions like Fedora and Arch, and my intention
is to do the same in Debian during the trixie release cycle.

It is *not* necessary to change dependencies from libsdl1.2debian to
libsdl1.2-compat-shim, or from libsdl1.2-dev to libsdl1.2-compat-dev.
My intention is to make a future version of sdl12-compat take over
the old package names, to minimize the changes that are required in
dependent packages.

The interesting scenarios to test with libsdl1.2-compat-shim are:

1. Install libsdl1.2-compat-shim and run the program in an X11 environment,
   such as "GNOME on Xorg" or XFCE.
   ($XDG_RUNTIME_DIR/wayland-* should not exist)
2. Install libsdl1.2-compat-shim and run the program in a Wayland
   environment such as GNOME's default mode, using Xwayland.
   ($XDG_RUNTIME_DIR/wayland-* should exist)
3. Install libsdl1.2-compat-shim and run the program in a Wayland
   environment, but this time with environment variable
   SDL_VIDEODRIVER=wayland so that it uses the native Wayland interface
   (this is not currently the default for SDL 2).
4. Install libsdl1.2-compat-dev and recompile the package.

Note that using libsdl1.2-compat and LD_LIBRARY_PATH is not sufficient if
the package contains programs that are setgid games. See

for more information.

If any of those fail, please report it as a bug in the
libsdl1.2-compat-shim or libsdl1.2-compat-dev package as appropriate,
with "affects" pointing to the program that is affected.

Thanks,
smcv

-- 
This bug report is part of a mass-bug-filing:

Bug#1038192: dossizola: Depends on SDL 1.2

[Simon McVittie]

Source: dossizola
Tags: trixie sid
User: pkg-sdl-maintain...@lists.alioth.debian.org
Usertags: libsdl1.2

This package has a Depends or Build-Depends on SDL version 1.2, which
is unmaintained upstream.

If possible, please port this package to SDL 2 and close this bug. There
is a migration guide at ,
and examples of successful ports from SDL 1.2 to SDL 2 can be found in
the commit history of packages like darkplaces and ioquake3.

If it is not possible to port to SDL 2, please test the package with
libsdl1.2-compat-shim (preferably version 1.2.64 or later), and leave
this bug open to track the package as still using SDL 1.2 APIs.

libsdl1.2-compat-shim is a compatibility layer that provides the SDL 1.2
API/ABI by using SDL 2: it has already replaced the "classic" SDL 1.2
library in some other distributions like Fedora and Arch, and my intention
is to do the same in Debian during the trixie release cycle.

It is *not* necessary to change dependencies from libsdl1.2debian to
libsdl1.2-compat-shim, or from libsdl1.2-dev to libsdl1.2-compat-dev.
My intention is to make a future version of sdl12-compat take over
the old package names, to minimize the changes that are required in
dependent packages.

The interesting scenarios to test with libsdl1.2-compat-shim are:

1. Install libsdl1.2-compat-shim and run the program in an X11 environment,
   such as "GNOME on Xorg" or XFCE.
   ($XDG_RUNTIME_DIR/wayland-* should not exist)
2. Install libsdl1.2-compat-shim and run the program in a Wayland
   environment such as GNOME's default mode, using Xwayland.
   ($XDG_RUNTIME_DIR/wayland-* should exist)
3. Install libsdl1.2-compat-shim and run the program in a Wayland
   environment, but this time with environment variable
   SDL_VIDEODRIVER=wayland so that it uses the native Wayland interface
   (this is not currently the default for SDL 2).
4. Install libsdl1.2-compat-dev and recompile the package.

Note that using libsdl1.2-compat and LD_LIBRARY_PATH is not sufficient if
the package contains programs that are setgid games. See

for more information.

If any of those fail, please report it as a bug in the
libsdl1.2-compat-shim or libsdl1.2-compat-dev package as appropriate,
with "affects" pointing to the program that is affected.

Thanks,
smcv

-- 
This bug report is part of a mass-bug-filing:

Bug#1038193: edgar: Depends on SDL 1.2

[Simon McVittie]

Source: edgar
Tags: trixie sid
User: pkg-sdl-maintain...@lists.alioth.debian.org
Usertags: libsdl1.2

This package has a Depends or Build-Depends on SDL version 1.2, which
is unmaintained upstream.

If possible, please port this package to SDL 2 and close this bug. There
is a migration guide at ,
and examples of successful ports from SDL 1.2 to SDL 2 can be found in
the commit history of packages like darkplaces and ioquake3.

If it is not possible to port to SDL 2, please test the package with
libsdl1.2-compat-shim (preferably version 1.2.64 or later), and leave
this bug open to track the package as still using SDL 1.2 APIs.

libsdl1.2-compat-shim is a compatibility layer that provides the SDL 1.2
API/ABI by using SDL 2: it has already replaced the "classic" SDL 1.2
library in some other distributions like Fedora and Arch, and my intention
is to do the same in Debian during the trixie release cycle.

It is *not* necessary to change dependencies from libsdl1.2debian to
libsdl1.2-compat-shim, or from libsdl1.2-dev to libsdl1.2-compat-dev.
My intention is to make a future version of sdl12-compat take over
the old package names, to minimize the changes that are required in
dependent packages.

The interesting scenarios to test with libsdl1.2-compat-shim are:

1. Install libsdl1.2-compat-shim and run the program in an X11 environment,
   such as "GNOME on Xorg" or XFCE.
   ($XDG_RUNTIME_DIR/wayland-* should not exist)
2. Install libsdl1.2-compat-shim and run the program in a Wayland
   environment such as GNOME's default mode, using Xwayland.
   ($XDG_RUNTIME_DIR/wayland-* should exist)
3. Install libsdl1.2-compat-shim and run the program in a Wayland
   environment, but this time with environment variable
   SDL_VIDEODRIVER=wayland so that it uses the native Wayland interface
   (this is not currently the default for SDL 2).
4. Install libsdl1.2-compat-dev and recompile the package.

Note that using libsdl1.2-compat and LD_LIBRARY_PATH is not sufficient if
the package contains programs that are setgid games. See

for more information.

If any of those fail, please report it as a bug in the
libsdl1.2-compat-shim or libsdl1.2-compat-dev package as appropriate,
with "affects" pointing to the program that is affected.

Thanks,
smcv

-- 
This bug report is part of a mass-bug-filing:

Bug#1038194: einstein: Depends on SDL 1.2

[Simon McVittie]

Source: einstein
Tags: trixie sid
User: pkg-sdl-maintain...@lists.alioth.debian.org
Usertags: libsdl1.2

This package has a Depends or Build-Depends on SDL version 1.2, which
is unmaintained upstream.

If possible, please port this package to SDL 2 and close this bug. There
is a migration guide at ,
and examples of successful ports from SDL 1.2 to SDL 2 can be found in
the commit history of packages like darkplaces and ioquake3.

If it is not possible to port to SDL 2, please test the package with
libsdl1.2-compat-shim (preferably version 1.2.64 or later), and leave
this bug open to track the package as still using SDL 1.2 APIs.

libsdl1.2-compat-shim is a compatibility layer that provides the SDL 1.2
API/ABI by using SDL 2: it has already replaced the "classic" SDL 1.2
library in some other distributions like Fedora and Arch, and my intention
is to do the same in Debian during the trixie release cycle.

It is *not* necessary to change dependencies from libsdl1.2debian to
libsdl1.2-compat-shim, or from libsdl1.2-dev to libsdl1.2-compat-dev.
My intention is to make a future version of sdl12-compat take over
the old package names, to minimize the changes that are required in
dependent packages.

The interesting scenarios to test with libsdl1.2-compat-shim are:

1. Install libsdl1.2-compat-shim and run the program in an X11 environment,
   such as "GNOME on Xorg" or XFCE.
   ($XDG_RUNTIME_DIR/wayland-* should not exist)
2. Install libsdl1.2-compat-shim and run the program in a Wayland
   environment such as GNOME's default mode, using Xwayland.
   ($XDG_RUNTIME_DIR/wayland-* should exist)
3. Install libsdl1.2-compat-shim and run the program in a Wayland
   environment, but this time with environment variable
   SDL_VIDEODRIVER=wayland so that it uses the native Wayland interface
   (this is not currently the default for SDL 2).
4. Install libsdl1.2-compat-dev and recompile the package.

Note that using libsdl1.2-compat and LD_LIBRARY_PATH is not sufficient if
the package contains programs that are setgid games. See

for more information.

If any of those fail, please report it as a bug in the
libsdl1.2-compat-shim or libsdl1.2-compat-dev package as appropriate,
with "affects" pointing to the program that is affected.

Thanks,
smcv

-- 
This bug report is part of a mass-bug-filing:

Bug#1038195: enemylines3: Depends on SDL 1.2

[Simon McVittie]

Source: enemylines3
Tags: trixie sid
User: pkg-sdl-maintain...@lists.alioth.debian.org
Usertags: libsdl1.2

This package has a Depends or Build-Depends on SDL version 1.2, which
is unmaintained upstream.

If possible, please port this package to SDL 2 and close this bug. There
is a migration guide at ,
and examples of successful ports from SDL 1.2 to SDL 2 can be found in
the commit history of packages like darkplaces and ioquake3.

If it is not possible to port to SDL 2, please test the package with
libsdl1.2-compat-shim (preferably version 1.2.64 or later), and leave
this bug open to track the package as still using SDL 1.2 APIs.

libsdl1.2-compat-shim is a compatibility layer that provides the SDL 1.2
API/ABI by using SDL 2: it has already replaced the "classic" SDL 1.2
library in some other distributions like Fedora and Arch, and my intention
is to do the same in Debian during the trixie release cycle.

It is *not* necessary to change dependencies from libsdl1.2debian to
libsdl1.2-compat-shim, or from libsdl1.2-dev to libsdl1.2-compat-dev.
My intention is to make a future version of sdl12-compat take over
the old package names, to minimize the changes that are required in
dependent packages.

The interesting scenarios to test with libsdl1.2-compat-shim are:

1. Install libsdl1.2-compat-shim and run the program in an X11 environment,
   such as "GNOME on Xorg" or XFCE.
   ($XDG_RUNTIME_DIR/wayland-* should not exist)
2. Install libsdl1.2-compat-shim and run the program in a Wayland
   environment such as GNOME's default mode, using Xwayland.
   ($XDG_RUNTIME_DIR/wayland-* should exist)
3. Install libsdl1.2-compat-shim and run the program in a Wayland
   environment, but this time with environment variable
   SDL_VIDEODRIVER=wayland so that it uses the native Wayland interface
   (this is not currently the default for SDL 2).
4. Install libsdl1.2-compat-dev and recompile the package.

Note that using libsdl1.2-compat and LD_LIBRARY_PATH is not sufficient if
the package contains programs that are setgid games. See

for more information.

If any of those fail, please report it as a bug in the
libsdl1.2-compat-shim or libsdl1.2-compat-dev package as appropriate,
with "affects" pointing to the program that is affected.

Thanks,
smcv

-- 
This bug report is part of a mass-bug-filing:

Bug#1038196: enemylines7: Depends on SDL 1.2

[Simon McVittie]

Source: enemylines7
Tags: trixie sid
User: pkg-sdl-maintain...@lists.alioth.debian.org
Usertags: libsdl1.2

This package has a Depends or Build-Depends on SDL version 1.2, which
is unmaintained upstream.

If possible, please port this package to SDL 2 and close this bug. There
is a migration guide at ,
and examples of successful ports from SDL 1.2 to SDL 2 can be found in
the commit history of packages like darkplaces and ioquake3.

If it is not possible to port to SDL 2, please test the package with
libsdl1.2-compat-shim (preferably version 1.2.64 or later), and leave
this bug open to track the package as still using SDL 1.2 APIs.

libsdl1.2-compat-shim is a compatibility layer that provides the SDL 1.2
API/ABI by using SDL 2: it has already replaced the "classic" SDL 1.2
library in some other distributions like Fedora and Arch, and my intention
is to do the same in Debian during the trixie release cycle.

It is *not* necessary to change dependencies from libsdl1.2debian to
libsdl1.2-compat-shim, or from libsdl1.2-dev to libsdl1.2-compat-dev.
My intention is to make a future version of sdl12-compat take over
the old package names, to minimize the changes that are required in
dependent packages.

The interesting scenarios to test with libsdl1.2-compat-shim are:

1. Install libsdl1.2-compat-shim and run the program in an X11 environment,
   such as "GNOME on Xorg" or XFCE.
   ($XDG_RUNTIME_DIR/wayland-* should not exist)
2. Install libsdl1.2-compat-shim and run the program in a Wayland
   environment such as GNOME's default mode, using Xwayland.
   ($XDG_RUNTIME_DIR/wayland-* should exist)
3. Install libsdl1.2-compat-shim and run the program in a Wayland
   environment, but this time with environment variable
   SDL_VIDEODRIVER=wayland so that it uses the native Wayland interface
   (this is not currently the default for SDL 2).
4. Install libsdl1.2-compat-dev and recompile the package.

Note that using libsdl1.2-compat and LD_LIBRARY_PATH is not sufficient if
the package contains programs that are setgid games. See

for more information.

If any of those fail, please report it as a bug in the
libsdl1.2-compat-shim or libsdl1.2-compat-dev package as appropriate,
with "affects" pointing to the program that is affected.

Thanks,
smcv

-- 
This bug report is part of a mass-bug-filing:

Bug#1038197: enigma: Depends on SDL 1.2

[Simon McVittie]

Source: enigma
Tags: trixie sid
User: pkg-sdl-maintain...@lists.alioth.debian.org
Usertags: libsdl1.2

This package has a Depends or Build-Depends on SDL version 1.2, which
is unmaintained upstream.

If possible, please port this package to SDL 2 and close this bug. There
is a migration guide at ,
and examples of successful ports from SDL 1.2 to SDL 2 can be found in
the commit history of packages like darkplaces and ioquake3.

If it is not possible to port to SDL 2, please test the package with
libsdl1.2-compat-shim (preferably version 1.2.64 or later), and leave
this bug open to track the package as still using SDL 1.2 APIs.

libsdl1.2-compat-shim is a compatibility layer that provides the SDL 1.2
API/ABI by using SDL 2: it has already replaced the "classic" SDL 1.2
library in some other distributions like Fedora and Arch, and my intention
is to do the same in Debian during the trixie release cycle.

It is *not* necessary to change dependencies from libsdl1.2debian to
libsdl1.2-compat-shim, or from libsdl1.2-dev to libsdl1.2-compat-dev.
My intention is to make a future version of sdl12-compat take over
the old package names, to minimize the changes that are required in
dependent packages.

The interesting scenarios to test with libsdl1.2-compat-shim are:

1. Install libsdl1.2-compat-shim and run the program in an X11 environment,
   such as "GNOME on Xorg" or XFCE.
   ($XDG_RUNTIME_DIR/wayland-* should not exist)
2. Install libsdl1.2-compat-shim and run the program in a Wayland
   environment such as GNOME's default mode, using Xwayland.
   ($XDG_RUNTIME_DIR/wayland-* should exist)
3. Install libsdl1.2-compat-shim and run the program in a Wayland
   environment, but this time with environment variable
   SDL_VIDEODRIVER=wayland so that it uses the native Wayland interface
   (this is not currently the default for SDL 2).
4. Install libsdl1.2-compat-dev and recompile the package.

Note that using libsdl1.2-compat and LD_LIBRARY_PATH is not sufficient if
the package contains programs that are setgid games. See

for more information.

If any of those fail, please report it as a bug in the
libsdl1.2-compat-shim or libsdl1.2-compat-dev package as appropriate,
with "affects" pointing to the program that is affected.

Thanks,
smcv

-- 
This bug report is part of a mass-bug-filing:

Bug#1038198: epiphany: Depends on SDL 1.2

[Simon McVittie]

Source: epiphany
Tags: trixie sid
User: pkg-sdl-maintain...@lists.alioth.debian.org
Usertags: libsdl1.2

This package has a Depends or Build-Depends on SDL version 1.2, which
is unmaintained upstream.

If possible, please port this package to SDL 2 and close this bug. There
is a migration guide at ,
and examples of successful ports from SDL 1.2 to SDL 2 can be found in
the commit history of packages like darkplaces and ioquake3.

If it is not possible to port to SDL 2, please test the package with
libsdl1.2-compat-shim (preferably version 1.2.64 or later), and leave
this bug open to track the package as still using SDL 1.2 APIs.

libsdl1.2-compat-shim is a compatibility layer that provides the SDL 1.2
API/ABI by using SDL 2: it has already replaced the "classic" SDL 1.2
library in some other distributions like Fedora and Arch, and my intention
is to do the same in Debian during the trixie release cycle.

It is *not* necessary to change dependencies from libsdl1.2debian to
libsdl1.2-compat-shim, or from libsdl1.2-dev to libsdl1.2-compat-dev.
My intention is to make a future version of sdl12-compat take over
the old package names, to minimize the changes that are required in
dependent packages.

The interesting scenarios to test with libsdl1.2-compat-shim are:

1. Install libsdl1.2-compat-shim and run the program in an X11 environment,
   such as "GNOME on Xorg" or XFCE.
   ($XDG_RUNTIME_DIR/wayland-* should not exist)
2. Install libsdl1.2-compat-shim and run the program in a Wayland
   environment such as GNOME's default mode, using Xwayland.
   ($XDG_RUNTIME_DIR/wayland-* should exist)
3. Install libsdl1.2-compat-shim and run the program in a Wayland
   environment, but this time with environment variable
   SDL_VIDEODRIVER=wayland so that it uses the native Wayland interface
   (this is not currently the default for SDL 2).
4. Install libsdl1.2-compat-dev and recompile the package.

Note that using libsdl1.2-compat and LD_LIBRARY_PATH is not sufficient if
the package contains programs that are setgid games. See

for more information.

If any of those fail, please report it as a bug in the
libsdl1.2-compat-shim or libsdl1.2-compat-dev package as appropriate,
with "affects" pointing to the program that is affected.

Thanks,
smcv

-- 
This bug report is part of a mass-bug-filing:

Bug#1038199: etw: Depends on SDL 1.2

[Simon McVittie]

Source: etw
Tags: trixie sid
User: pkg-sdl-maintain...@lists.alioth.debian.org
Usertags: libsdl1.2

This package has a Depends or Build-Depends on SDL version 1.2, which
is unmaintained upstream.

If possible, please port this package to SDL 2 and close this bug. There
is a migration guide at ,
and examples of successful ports from SDL 1.2 to SDL 2 can be found in
the commit history of packages like darkplaces and ioquake3.

If it is not possible to port to SDL 2, please test the package with
libsdl1.2-compat-shim (preferably version 1.2.64 or later), and leave
this bug open to track the package as still using SDL 1.2 APIs.

libsdl1.2-compat-shim is a compatibility layer that provides the SDL 1.2
API/ABI by using SDL 2: it has already replaced the "classic" SDL 1.2
library in some other distributions like Fedora and Arch, and my intention
is to do the same in Debian during the trixie release cycle.

It is *not* necessary to change dependencies from libsdl1.2debian to
libsdl1.2-compat-shim, or from libsdl1.2-dev to libsdl1.2-compat-dev.
My intention is to make a future version of sdl12-compat take over
the old package names, to minimize the changes that are required in
dependent packages.

The interesting scenarios to test with libsdl1.2-compat-shim are:

1. Install libsdl1.2-compat-shim and run the program in an X11 environment,
   such as "GNOME on Xorg" or XFCE.
   ($XDG_RUNTIME_DIR/wayland-* should not exist)
2. Install libsdl1.2-compat-shim and run the program in a Wayland
   environment such as GNOME's default mode, using Xwayland.
   ($XDG_RUNTIME_DIR/wayland-* should exist)
3. Install libsdl1.2-compat-shim and run the program in a Wayland
   environment, but this time with environment variable
   SDL_VIDEODRIVER=wayland so that it uses the native Wayland interface
   (this is not currently the default for SDL 2).
4. Install libsdl1.2-compat-dev and recompile the package.

Note that using libsdl1.2-compat and LD_LIBRARY_PATH is not sufficient if
the package contains programs that are setgid games. See

for more information.

If any of those fail, please report it as a bug in the
libsdl1.2-compat-shim or libsdl1.2-compat-dev package as appropriate,
with "affects" pointing to the program that is affected.

Thanks,
smcv

-- 
This bug report is part of a mass-bug-filing:

Bug#1038201: firewalld: Firewalld not forwarding packets from private LAN servers

[Gerard Monells]

Package: firewalld
Version: 1.3.0-1
Severity: important
X-Debbugs-Cc: gerard.mone...@gmail.com

Dear Maintainer,

I created one Debian Bookworm server for usage as gateway for an internal 
network, using firewalld.
In Debian Bullseye was as easy as install package firewalld (unchanged config) 
and:

```
sudo firewall-cmd --zone=external --add-interface=enp0s3 --permanent
sudo firewall-cmd --zone=internal --add-interface=enp0s8 --permanent
sudo firewall-cmd --reload
```

Considering enp0s3 as the "public" interface, and enp0s8 as the "private".
I have no more rules for the sake of brevity, at this moment.

Any server on the private network (only one interface, same network as enp0s8 
10.0.0.0/24) was able to
do an `apt update` or a `curl http://www.debian.org/`. Packages were forwarded 
and masqueraded by
firewalld nftables rules, but after doing the same gateway build in Bookworm, 
logs are filled with
"filter_FWD_internal_REJECT" messages (`sudo firewall-cmd --set-log-denied=all` 
and `sudo journalctl -x -e`).

I tried to repeat the build using Bullseye and backports (only changes 
firewalld version
from 0.9.3-2 to 1.3.0-1~bpo11+1), and start failed as described, so this is not 
a nftables issue,
but a firewalld issue. Same failure with Bookworm using Sid packages (version 
1.3.3-1)

Firewalld internal and external zone are identical (`sudo firewall-cmd 
--zone=internal --list-all`) in
all scenarios, so the issue is not coming from firewalld usage or configuration.



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

Kernel: Linux 6.1.0-9-amd64 (SMP w/1 CPU thread; PREEMPT)
Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.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 firewalld depends on:
ii  dbus  1.14.6-1
ii  gir1.2-glib-2.0   1.74.0-3
ii  gir1.2-nm-1.0 1.42.4-1
ii  polkitd   122-3
ii  python3   3.11.2-1+b1
ii  python3-dbus  1.3.2-4+b1
ii  python3-firewall  1.3.0-1
ii  python3-gi3.42.2-3+b1
ii  python3-nftables  1.0.6-2

Versions of packages firewalld recommends:
ii  ipset   7.17-1
ii  iptables1.8.9-2
ii  python3-cap-ng  0.8.3-1+b3

firewalld suggests no packages.

-- Configuration Files:
/etc/firewalld/firewalld.conf [Errno 13] Permiso denegado: 
'/etc/firewalld/firewalld.conf'
/etc/firewalld/lockdown-whitelist.xml [Errno 13] Permiso denegado: 
'/etc/firewalld/lockdown-whitelist.xml'

-- no debconf information

Bug#1038200: zabbix-agent2 regression: PostgreSQL support moved to separate repository between 6.0.7 and 6.0.14

[Magnus Holmgren]

Package: zabbix-agent2
Version: 1:6.0.14+dfsg-1~bpo11+1
Severity: important

I just upgraded zabbix-agent2 from bullseye-backports, and found that all the 
pgsql items became unsupported.
I don't know if you noticed, but it turns out upstream thought it was a good 
idea to remove the built-in
PostgreSQL support and put it in a separate plugin with its own repository
(https://git.zabbix.com/projects/AP/repos/postgresql/browse) on a stable branch.

Since zabbix-agent2 didn't become part of an official Debian release until 
after this regression happened,
I suppose this should probably rather be a wishlist bug against wnpp, but I 
thought I'd let you know in
this manner. I could package the plugin if you like.

-- 
Magnus Holmgren
holmg...@debian.org
magnus.holmg...@milientsoftware.com

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

Kernel: Linux 5.10.0-21-amd64 (SMP w/4 CPU threads)
Locale: LANG=sv_SE.UTF-8, LC_CTYPE=sv_SE.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 zabbix-agent2 depends on:
ii  adduser  3.118
ii  init-system-helpers  1.60
ii  libc62.31-13+deb11u6
ii  libpcre2-8-0 10.36-2+deb11u1
ii  libsqlite3-0 3.34.1-3
ii  libssl1.11.1.1n-0+deb11u5
ii  lsb-base 11.1.0
ii  zlib1g   1:1.2.11.dfsg-2+deb11u2

zabbix-agent2 recommends no packages.

Versions of packages zabbix-agent2 suggests:
ii  logrotate  3.18.0-2+deb11u1

-- Configuration Files:
/etc/zabbix/zabbix_agent2.conf changed [not included]

-- no debconf information

Bug#1034856: dstat: autopkgtest regression on multiple archs: TypeError: '<' not supported between instances of 'dict' and 'int'

[Emanuele Rocca]

Hi Paul,

On 2023-04-25 10:03, Paul Gevers wrote:
> Your package has an autopkgtest, great. However, it fails since April 2023
> on arm64, i386, ppc64el and s390x. Can you please investigate the situation
> and fix it? I copied some of the output at the bottom of this report.

The reality of the situation is that dstat is fairly buggy. Still usable
in many cases, but far from perfect. Unfortunately the project is not
maintained upstream since several years [1], and fixing the outstanding
issues is not trivial. All my hopes are now on dool, which seems to be a
promising replacement and is currently being packaged [2].

ciao,
  ema

[1] https://github.com/dstat-real/dstat/issues/170
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1032875

Bug#775125: wayland idle time

[Russell Coker]

The package swayidle has code to detect idle time, the source has little in 
the way of comments and is difficult to understand.

swayidle -w timeout 5 'echo 5' timeout 10 'echo 10' resume 'echo resume' \ 
before-sleep 'echo before-sleep'

A command-line like the above will display messages on 5 seconds and 10 
seconds of idle time and display "resume" when there is keyboard or mouse 
input.  That could be changed to have kill -USR1 and kill -USR2 and use them 
as the signals for the system being idle or in-use.  If BOINC took those 
signals then the local user/sysadmin could script things to work with X11, 
terminal logins, etc.  The current code only works with X11 and even that code 
has issues.

If signals aren't considered a good way of doing it then there could be a flag 
file or some other method.

As an aside to run swayidle as root you need to set this environment variable 
WAYLAND_DISPLAY=../$REALUID/wayland-0 where REALUID is the UID of the user 
with the graphical login.

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/

Bug#940319:

[c . buhtz]

Hello,

I try to learn here and that is why I asked.

Do I get it right that the problem is that BIT do write and read from 
the users home folder. And that is not possible or not recommended on 
Debian's own build and test system. Am I right so far?


To my knowledge as upstream maintainer this problem is not solved in 
upstream.


So how do you do it on the Debian side? Does our BIT still write to 
Debians build system's users home folder or not?

If not, how did you solved or worked around it?

Thanks for your reply.

Kind
Christian Buhtz

Bug#963849:

[c . buhtz]

Dear Felix,

can you please try to reproduce the problem with a newer release.
Debian 12 now has 1.3.3 on board which is the latest upstream version. 
This version is also available via an Ubuntu PPA or directly via git 
clone.


Feel free to ask if you need further help with installing.

Kind
Christian Buhtz

Bug#1038135: diesel

[matthias . geiger1024]

Hi Steve.

I took over maintaining diesel shortly before the freeze as itself and related 
packages had some RC bugs. After getting diesel 2.0.3 uploaded I discovered the 
mysql-client-sys mess. It is on my to-do list to properly fix it; as plugwash 
pointed out in #1036076 this might be a hassle. Once I finished the gtk-rs and 
zbus transition I will look into it. 

regards,
---
Matthias Geiger (werdahias)
-BEGIN PGP PUBLIC KEY BLOCK-

mQINBGJGNsQBEADCVylaCtYtBQW4NmDrZOIizSrVlv5ZJ5WJ128MAblWk3fRFPya
Cs/klkTT58ehBSr61sXVP+NpkF7MWOBu2CNg66U40a/Eb+v4poxNaIjXKvQtf51S
y5yGwmTc7IJg8HuohT7K3/pcsEt0jvYSwvvDFUIz5WdOR5RmB7WkDRGh8Zaior3z
tzx6AKhx/aXmAc/i4BDavDxZeFC0d79H3S1+TvFsvhyIZXIFTB0sTzWreZZxSOjk
Mz6xxgWGdc27lsbZbKU7N+c+GnWrRlTjimU1AfPLJQgehIejR9pSyZ2Y5BAqB7Qr
f8Tvc8jc1kDx473sUUla6ELEuJMIISK1qam/B7buxZ1r/ngWRiQsqAHznm7OYk69
ttXBeHxS1b+HrcJMWfROkzsTuG6G//axMCb6x0MuyOgLXk87aDnDx1fPn62R+tq7
T4JvW51TSnlNNh75zA+8w3UzDHy2By0H6NSfiLerNnF7LGCXk7AiwQsaplrEjo/1
/4NraAqy1eO69SyozSiRuuA5KemlyPwJokpp2HMJX3cry2J7lV0+wnaaorQzz5Fi
7gRRlqXrOGwEcEG6i62VbIv2VW3Zy+qjaD3HRWXfKXXjpXske41Trv2qPI2/kGtJ
TRWSWdTQ42oYOaEg/KUh0GnEoZerj50JC1qGmwElKYgd+2XQ8qR7uIB5qQARAQAB
tDFNYXR0aGlhcyBHZWlnZXIgPG1hdHRoaWFzLmdlaWdlcjEwMjRAdHV0YW5vdGEu
ZGU+iQJUBBMBCgA+FiEEwuGmy/3s5RGopBdtGL0QaztsVHUFAmJGNsQCGwMFCQPC
ZwAFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AACgkQGL0QaztsVHVMxQ/+M5JEQ5wk
DDblHGUlK8IBnPM5peuDrMdQAsOQ5nSv90gl4z4HkRgomS70xMpvoS+g/8hPym4G
PXpSFJsZWjFevACWMzZO84pqJhPaFnmjh3utkkiblNf8Wi350K+luAlRvT1FVD6i
HM6kOxU0P9t9+PU38FH299oRw2qEqDw5Wx+Hrnp4gaGv1mssvAMiXeaaPGx4KSz8
sNXADHJDo78U6RGJM/rSng/8M7zd3c6E8MIH958mlWjUb8T10AZ/otH3nFSRIfds
5MdnnrsKAK3DMW4RanRWHPvTsICDDkuRvigd32waQRdZeA3dNbPxM6tKDL9GEH8Q
AnkShJ7VmTXP9CV20vj15mleoeDMgqhX5KEOsc3DMnKcVqdb9CzHj6jNSFUverk1
bBNaJpIiWwtwjueR4Hgdof80AAgRin4YnWaOaPTSusrKyN8dCRVcRIbauVooWLil
q2OrWftDVmmNciwoHr5/WDPNgkv9DAgY+DX8Y8LMWAkXgpB0KniiQaLzrW34zjnP
ALTLTIvNid6YX8KOY6KhAVWfVdMC5j6GEGfbfyMLz63YPxA9Q1Af6oXS8MbdHyBw
JV8ns2xm5fD2vZVw6JI1e8AMMDjH2fAqmH23MG0fN0zd2NUToHmvhX9APSzJIbET
doFPn/mI/az4Oh24WHf3Ozr+XEDyWcyy1y+5Ag0EYkY2xAEQANL26Ixtq1QMUM+5
MHl2FK4foRODoKHe4ZzdOAumUBPJE/pxGVlVxCqzC+LUeFvA8LTYCt1B60yRveYR
4mmPTA7nAerG2m4aQPeIfzz6HXWkiu9mzgxqjhPxitiMR5f1du1rAWGPZxSkhdW6
fDWT4PkHoY78jbQXWYEnV85rwtZIZIduHGKWzyxln3qjrefmB04QkPJ2BDOsRTtD
YeNddHAvcgZtyepqZka9lpowQTY6TXwM8uYArEa7Hll/4r9rcvkVQUxf8jqYpZ3v
PLSzvvaDouH7WAg5nUaTeWAQdSq108rNRSTgScLZWjwmhFBA46RneRpij2OJ0lW4
QqFTlldjWXzgGj6u4nbXrSERGaPwyLGIkHoKbnTAm7791d/Y5UQImuPb1tIg5Pf7
OhtyWw3bstVDa5MvIUuGpi5yKPirhrtAfdZ3H2/HR814JuL2BYdjyCuR/Sj/lZTx
+gJ0bm+Llr0KZDhjKMeWaqVqsD4bybgEe4d3zE4sj9GZ0tNUvXfPaRGY6tgh9sgT
Iy28vnyYpFX+oSIZXRreDpfzyjDhvNbB+AFsPN5OXqaBpmu/378T5nRpUj/qbqEZ
EsloCbAmgHfvIysQWYdJ+63S3ZqpbEQRa4Y7DeybaLi8xTMfdWa19T7vQY3mVWn5
ZooycK4fkbedu19+5l8zfhR7oWyBABEBAAGJAjwEGAEKACYWIQTC4abL/ezlEaik
F20YvRBrO2xUdQUCYkY2xAIbDAUJA8JnAAAKCRAYvRBrO2xUdRuPD/4tdAf8nxsA
upo5O99E4AS59OTXPQuVgt1U2Z7ssDvZ3O6qbZvIBWQ0NqnCsprCt71M6cWC2dkq
WUs3oRRu4IzuB4LErcTr597k+iltJ60rhDL/hxSumToH6FSX1w8EWJVg3xgP4U39
HSx6QOlZ3bTgd9dS5S46jOptIYzX5wYkNzyMj1hbmTg0lVyMtWjqfCLNmF3EzGGC
BLR3tMOxZURrxx8tL48iJlFyxJG3XahoyxDSNepo5HZ+AUnNq2TJPoPJQfb1/GB/
/LycKSXWgblyWuGRlgoCE1JcdwuRM5hI2xugZQrhgZaPUBch1MSoiIqwgR1A8NPL
iypUPnwG4vEaVbMtem7OUghsx+fYwuGq0T7/ezjyVRv86U2gU1bmbxojct1AXSCT
FCCR3Y8QAHV9o8U/eZ1XzcEZsXFd6siO5nEBl9HaTHh5gWDrk/molP85S7Y9JIBP
wZygBjWOPCCkFlIuiPQlXsJezVu93ydz7uCNIJfHv30oVedcYHN1Wr7B/1j8wXMy
wqW4Nw54yZ8zaJIo01Khym6cFFVXoAUZa+5QRvSmjnm1Go+ZwZA9i7zo/6LLSpeR
04+4a1Daysk0fTf+DscrxQbUBZX17e1n/EtLS8/pp+Xb/k1JK1iiNcdpfLJ7RNik
GX00szhWs5riRMzIibFDsE/FyYVNX2VHQg==
=onWA
-END PGP PUBLIC KEY BLOCK-

Bug#1033829:

[c . buhtz]

Hello,

upstream maintainer here.

I just want to inform. I don't know how Debian would handle this 
usually.


The problem is fixed in upstream but unreleased. And this NMU tries to 
backport the fix.
The next Debian release will come in around 2 years. Until then upstream 
will do a new release.


Because of that and to my understanding there is no need anymore for 
that NMU and it can be removed from the system.


Kind
Christian

Bug#1029586: apt: "apt-cache rdepends --installed" false positives

[Vincent Lefevre]

On 2023-01-25 12:52:45 +0100, Julian Andres Klode wrote:
> Documentation for apt patterns only lives in apt-patterns(7) and
> not referenced elsewhere. Patterns work in apt-cache show, apt show,
> apt list, and apt install-like commands (including in apt-get).

On this point, I was not aware of this man page. Indeed, it is not
referenced at all by the apt(8) man page. It should be at least in
the "SEE ALSO" section. Ditto for the other concerned man pages.

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

Bug#1028631: media-types: rss is associated with application/x-rss+xml instead of application/rss+xml

[Charles Plessy]

Le Thu, May 18, 2023 at 02:54:10PM +0200, Patrice Duroux a écrit :
> 
> Maybe it should be redirected to the members of the RSS Advisory Board, right?
> I think that I'm not a relevant contact to apply for such a media type. I will
> not be able to exchange and provide additional information.

Hi Patrice,

you can also submit a media type on behalf of others. I did it for
text/gff3.  If you can not contact the members of the RSS Advisory
Board (which seems inactive), I think that you have good grounds to fill
the registration form by yourself.

> Also, if the content of etc/mime.types is based on the IANA one[1], then why 
> it
> provides this 'application/x-rss+XML' entry? What for?

It looks like somebody convinced the previous maintainer to remove
application/rss+XML in favour of the unregistered one!

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

10 years later, that surely does not look like it was the best choice…

But please give a try to the IANA registration.  It is way easier than
10 years ago.

Have a nice day,

Charles

-- 
Charles Plessy Nagahama, Yomitan, Okinawa, Japan
Debian Med packaging team http://www.debian.org/devel/debian-med
Tooting from work,   https://fediscience.org/@charles_plessy
Tooting from home, https://framapiaf.org/@charles_plessy

Bug#1038133: Accepted libx11 2:1.8.6-1 (source) into unstable

[Salvatore Bonaccorso]

Source: libx11
Source-Version: 2:1.8.6-1

- Forwarded message from Debian FTP Masters 
 -

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Fri, 16 Jun 2023 14:36:12 +0200
Source: libx11
Architecture: source
Version: 2:1.8.6-1
Distribution: unstable
Urgency: medium
Maintainer: Debian X Strike Force 
Changed-By: Julien Cristau 
Changes:
 libx11 (2:1.8.6-1) unstable; urgency=medium
 .
   * Team upload.
   * New upstream release
 - InitExt.c: Add bounds checks for extension request, event, & error codes
   (CVE-2023-3138)
Checksums-Sha1:
 c3ece1c881490073629618f1a62571d0a11e91d7 2509 libx11_1.8.6-1.dsc
 d1ae1bcdb93b4bc943fda2b1fa424519f4aa1e16 3193457 libx11_1.8.6.orig.tar.gz
 a4cb1b03b9dfb470237c3f7b3fdf19a0f61acc60 801 libx11_1.8.6.orig.tar.gz.asc
 581f38c1f8e9ce1ffa8e8c067453d9b29fc09baa 73485 libx11_1.8.6-1.diff.gz
Checksums-Sha256:
 12d0bad855f51aa4ee6286f1c88acf6395fe6ea94b5416f79c664631bf5b83a8 2509 
libx11_1.8.6-1.dsc
 5ff0d26c94d82ebb94a944b9f1f55cd01b9713fd461fe93f62f3527ce14ad94e 3193457 
libx11_1.8.6.orig.tar.gz
 20b9fb0b6d80411dee9b6c3e2b5821ba0f26e59d1ac4c3e715e9d93679895126 801 
libx11_1.8.6.orig.tar.gz.asc
 7ddc8c5f32c4292fd7f525a75301d77d3010467639ce9f217416dc9031da97a5 73485 
libx11_1.8.6-1.diff.gz
Files:
 53cafd8cabc339841a67b7f0d4faf8ac 2509 x11 optional libx11_1.8.6-1.dsc
 9767ee0c5819e35142835da61b923421 3193457 x11 optional libx11_1.8.6.orig.tar.gz
 8599583071c79ac9bed437ff110960e1 801 x11 optional libx11_1.8.6.orig.tar.gz.asc
 8b00a91d766e6cdcfcdccfc403bb00ff 73485 x11 optional libx11_1.8.6-1.diff.gz

-BEGIN PGP SIGNATURE-

iQJIBAEBCgAyFiEEVXgdqzTmGgnvuIvhnbAjVVb4z60FAmSMV6IUHGpjcmlzdGF1
QGRlYmlhbi5vcmcACgkQnbAjVVb4z60QJA//Ym0v7RoQECMz4q8FWLZoCEO7x5Ip
n4HLEMfw1VXBvqjwEAo6VEyHaUtuDpSVoP4DiGkX4za0XtoieXwc7uwjAocyj6K3
3wPmcmYMm8b8gPSFBbB3qmyNX6CLehHbMdarRbiR3lb6f9e1XoJ8IpuaW0pcjLwz
VGvrp1SdI6yfFQmHvUokzh1SrLABFiLhJuz8twxBamjvZ6XtZeICKAB0MkkoQ2Sx
xYMlRxSOueb6mB5EWBBizWbU2y+4Gpy8AVFgmNb5v5AIm1SeYd1QzTN5agpuaimh
P4QqGMZ/Z4kl3Po3AYOd6dHauEOhCecZinnWHgE7siTjOgrDzvkWLI5zXmfRsxTD
SCaGJdUgAPgcIs7xLC3GM5OADdv+LvssHVS0VzynkuhoJSjQtCRL0pvGN2hc4luj
/0Auw1kRAgp2Rfsb53akldt9MIKmwlZjax/LRUp1GGDo3BoTVhxNrRVtrRFBQoVj
g+ZHSkT3Qbv6Z7nTu9I9IiFXR/PmUm4Q1vZ8DfRQQcLRwAXWFM9av/CBm8dJcqOP
iB3mYVvApGDUieqUqhPpSKaqf5DVZ/moNdTMuiupO17BWBkZD+QQ/f+ZQAKBfuAU
vgsw/iMeBSC92OZsu5PFiRkeaB2x36Ntt6/rz2p9UbWsni718qMEP5G/eHqvuP6c
sPGd+MdTTE4F+PY=
=R03w
-END PGP SIGNATURE-


- End forwarded message -

Bug#1038202: gvfs: "Message is already in session queue" when mount davs, seemed fixed 1.50.4, needs backport to stable?

[Marcus Hanisch]

Package: gvfs
Version: 1.50.3-1
Severity: important
Tags: upstream

Dear Maintainer,

this is my first debian bug report. I am sorry, if something is not correct :) 

   * What led up to the situation?
 * tried to mount a davs share (simple apache mod_dav vhost), getting 
"Message is already in session queue" error. 
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
 * gio mount davs://my.webdav/share/ ~/mnt
   * What was the outcome of this action?
 * error massage above
   * What outcome did you expect instead?
 * davs should be mounted

There exists an issue on gnome gitlab gvfs project, 
https://gitlab.gnome.org/GNOME/gvfs/-/issues/636
It seems to be fixed in 1.50.4, so it probably need a backport to 1.50.3 in 
debian stable (bookworm)

Thank you a lot!
Marcus


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

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

Versions of packages gvfs depends on:
ii  gvfs-common   1.50.3-1
ii  gvfs-daemons  1.50.3-1
ii  gvfs-libs 1.50.3-1
ii  libc6 2.36-9
ii  libglib2.0-0  2.74.6-2

gvfs recommends no packages.

Versions of packages gvfs suggests:
ii  gvfs-backends  1.50.3-1

-- no debconf information

Bug#1038203: iptables-netflow-dkms: module fails to build for Linux 6.4: error: implicit declaration of function 'register_sysctl_paths'

[Andreas Beckmann]

Package: iptables-netflow-dkms
Version: 2.6-5
Severity: important
Tags: sid trixie
User: debian...@lists.debian.org
Usertags: piuparts

Running the pre_build script:
Module version: 2.6
Kernel version: 6.1.20 (uname)
Kernel sources: /lib/modules/6.4.0-0-amd64/build (dkms)
! Warning: uname kernel version (6.1.20) and dkms version of kernel source 
(6.4.0-0-amd64) doesn't match!
!   You may try to specify only kernel source tree with 
--kdir=/lib/modules/6.4.0-0-amd64/build
!   and configure will pick up version properly.
! Assuming you want to build for 6.4.0-0-amd64
Checking for presence of include/linux/netfilter.h... No
Checking for presence of include/linux/llist.h... No
Checking for presence of include/linux/grsecurity.h... No
Iptables binary version: no iptables binary found
Xtables version: 1.8.9 (detected from pkg-config)
Check for working gcc: Yes (gcc-12)
Checking for presence of xtables.h... Yes (using ipt-inc)
Iptables include flags: -I/usr/include (user specified)
Iptables module path: /usr/lib/x86_64-linux-gnu/xtables (user specified)
Searching for net-snmp-config... No.
Searching for net-snmp agent... No.
 Assuming you don't want net-snmp agent support.
 Otherwise do:  apt-get install snmpd libsnmp-dev
Checking for DKMS... Yes.
Creating Makefile.. done.

  If you need some options enabled run ./configure --help
  Now run: make all install


I think you can get rid of the mismatch warning by replacing
'--from-dkms-conf=...' with '--kdir=...' in dkms.conf (PRE_BUILD
directive).


DKMS make.log for ipt-netflow-2.6 for kernel 6.4.0-0-amd64 (x86_64)
Fri Jun 16 13:15:58 UTC 2023
./gen_compat_def > compat_def.h
Test symbol xt_family linux/netfilter_ipv4/ip_tables.h  declared
Test struct timeval linux/ktime.h  undeclared
Test struct proc_ops linux/proc_fs.h  declared
Test symbol synchronize_sched linux/rcupdate.h  undeclared
Test symbol nf_bridge_info_get linux/netfilter_bridge.h  declared
Test struct vlan_dev_priv linux/if_vlan.h  declared
Test member nf_ct_event_notifier.ct_event net/netfilter/nf_conntrack_ecache.h  
declared
Compiling 2.6 for kernel 6.4.0-0-amd64
make -C /lib/modules/6.4.0-0-amd64/build M=/var/lib/dkms/ipt-netflow/2.6/build 
modules
make[1]: warning: jobserver unavailable: using -j1.  Add '+' to parent make 
rule.
make[1]: Entering directory '/usr/src/linux-headers-6.4.0-0-amd64'
  CC [M]  /var/lib/dkms/ipt-netflow/2.6/build/ipt_NETFLOW.o
/var/lib/dkms/ipt-netflow/2.6/build/ipt_NETFLOW.c:96:4: warning: #warning 
"Requested physdev is not compiled." [-Wcpp]
   96 | #  warning "Requested physdev is not compiled."
  |^~~
/var/lib/dkms/ipt-netflow/2.6/build/ipt_NETFLOW.c: In function 'nf_seq_show':
/var/lib/dkms/ipt-netflow/2.6/build/ipt_NETFLOW.c:762:60: warning: format '%lu' 
expects argument of type 'long unsigned int', but argument 3 has type 's64' 
{aka 'long long int'} [-Wformat=]
  762 | seq_printf(seq, " Flows selected %lu, discarded 
%lu.",
  |  ~~^
  ||
  |long 
unsigned int
  |  %llu
  763 | atomic64_read(&flows_selected),
  | ~~
  | |
  | s64 {aka long long int}
/var/lib/dkms/ipt-netflow/2.6/build/ipt_NETFLOW.c:762:75: warning: format '%lu' 
expects argument of type 'long unsigned int', but argument 4 has type 's64' 
{aka 'long long int'} [-Wformat=]
  762 | seq_printf(seq, " Flows selected %lu, discarded 
%lu.",
  | 
~~^
  | 
  |
  | 
  long unsigned int
  | 
%llu
  763 | atomic64_read(&flows_selected),
  764 | atomic64_read(&flows_observed) - 
atomic64_read(&flows_selected));
  | 
~~~
  ||
  |s64 {aka 
long long int}
/var/lib/dkms/ipt-netflow/2.6/build/ipt_NETFLOW.c:766:60: warning: format '%lu' 
expects argument of type 'long unsigned int', but argument 3 has type 's64' 
{aka 'long long int'} [-Wformat=]
  766 | seq_printf(seq, " Flows selected %lu.", 
atomic64_read(&flows_selected));
  |  ~~^
~~
  | 

Bug#1038204: tomcat10 complains about old Apache Tomcat Native library

[Jose Miguel Goncalves]

Package: tomcat10
Version: 10.1.6-1
Severity: normal

Dear Maintainer,

After installing tomcat10 in bookworm I see the following log message when I 
start the service:

INFO [main] org.apache.catalina.core.AprLifecycleListener.lifecycleEvent An 
older version [1.2.35] of the Apache Tomcat Native library is installed, while 
Tomcat recommends a minimum version of [2.0.1]

Please consider upgrading the libtcnative-1 package as recommended by the 
Tomcat developers.

Best regards,
José Gonçalves 

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

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

Versions of packages tomcat10 depends on:
ii  lsb-base11.6
ii  systemd [systemd-tmpfiles]  252.6-1
ii  sysvinit-utils [lsb-base]   3.06-4
ii  tomcat10-common 10.1.6-1
ii  ucf 3.0043+nmu1

Versions of packages tomcat10 recommends:
ii  libtcnative-1  1.2.35-1

Versions of packages tomcat10 suggests:
ii  tomcat10-admin 10.1.6-1
ii  tomcat10-docs  10.1.6-1
pn  tomcat10-examples  
pn  tomcat10-user  

-- no debconf information

Bug#1038205: ITP: basis-universal -- Basis Universal GPU Texture Codec

[Gürkan Myczko]

Package: wnpp
Severity: wishlist
Owner: Gürkan Myczko 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: basis-universal
  Version : 1.16.4
  Upstream Authors: Binomial LLC
  URL : https://github.com/BinomialLLC/basis_universal
* License : Apache-2.0
  Description : Basis Universal GPU Texture Codec
 This is a "supercompressed" GPU texture data interchange system that 
supports
 two highly compressed intermediate file formats (.basis or the .KTX2 
open
 standard from the Khronos Group) that can be quickly transcoded to a 
very wide

 variety of GPU compressed and uncompressed pixel formats: ASTC 4x4
 L/LA/RGB/RGBA, PVRTC1 4bpp RGB/RGBA, PVRTC2 RGB/RGBA, BC7 mode 6 RGB,
 BC7 mode 5 RGB/RGBA, BC1-5 RGB/RGBA/X/XY, ETC1 RGB, ETC2 RGBA, ATC 
RGB/RGBA,

 ETC2 EAC R11 and RG11, FXT1 RGB, and uncompressed raster image formats
 /565/.

Bug#1038206: ITP: jpeg-compressor-cpp -- jpeg compression library

[Matthias Geiger]

Package: wnpp
Severity: wishlist
Owner: Matthias Geiger 
X-Debbugs-Cc: debian-de...@lists.debian.org, t...@debian.org, 
matthias.geiger1...@tutanota.de

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: jpeg-compressor-cpp
  Version : 104
  Upstream Contact: Rich Geldreich 
* URL : https://github.com/richgel999/jpeg-compressor
* License : Public Domain or Apache 2.0
  Programming Lang: C/C++
  Description : jpeg compression library

I intend to package jpeg-compressor. It's needed for ppsspp where it's embedded 
as 3rdparty library.
The package just consists of four headers, so it's fairly minimal. It wil be 
maintained under the 
collaborative debian/ space on salsa. tar has kindly agreed to sponsor the 
initial upload.

thanks,

werdahias

-BEGIN PGP SIGNATURE-

iQJUBAEBCgA+FiEEwuGmy/3s5RGopBdtGL0QaztsVHUFAmSMak0gHG1hdHRoaWFz
LmdlaWdlcjEwMjRAdHV0YW5vdGEuZGUACgkQGL0QaztsVHV67g/7BwffKtkOtv1B
J5jMu9egRsFpi8MbqywvibJVVMFSBHIaEA/RO6OI1bk+nm6E4+8wNMC7Cr+fy6FL
rBaXIgP0/gg4bVRqJ+H6boxzimPcMPoymmIaNqmPV9VBzNL0dDwRndLy3T0ihivk
QBNt3umhWcgKz/2MjA8+fqUPIHQanIQgnqEqAeLzJvMMYHOgFeijkAbwLCDYC1qL
WjS28ODf5qP52Wn6Gql34Obf6iV3BYb9XKlCkeUN/ZPGtHIs6WjVLUVDIHrua1gW
yGXD1bHV4B9hyT9z4W8H/85G+lwalEVamfm59hHM6JXG9hN0Zp3xG6uHlov8ivUD
vUWB/DLY/0fZq4N5o7b8xMzDXSNP5mPgA9J9a5aWGdANSGXCOrb8N/m/ZKXS+LlL
Rpqg0oxqLrFZTmvIzZnNbN/ooviKvLrHrHVQq9eY+VpAOoU/IvFUUgNqXq6y9nq5
i6HFd8c4ZN3HsvJfdupap/BYLr6QrtiZ47mppne7pkxadhIGyn7kWokG7ckAZZC8
SAD/IbnRko7J/Jn++AR8DbCGLJbbzshxnXjXtd7gcQ1aByZUzY8D5Loyy5TBDqwM
W6cXt8knxGKPUP5FLN2YAE6x9yFqmo0dSjCV6cNa9EH1jQsOfCKeeWJqfDnZvvyi
txp1K1n9y3DHu2DCp+XTRxLvJQmZuok=
=+I09
-END PGP SIGNATURE-

Bug#1031115: Update gnome-shell-extension-weather to 121 to support GNOME 44

[Amr Ibrahim]

Hello,

Please update gnome-shell-extension-weather to 121 to support GNOME 44.

Best,
Amr

Bug#1038207: tp-smapi-dkms: module fails to build for Linux 6.4: error: macro "DEFINE_SEMAPHORE" requires 2 arguments, but only 1 given

[Andreas Beckmann]

Package: tp-smapi-dkms
Version: 0.43-3
Severity: important
Tags: sid trixie
User: debian...@lists.debian.org
Usertags: piuparts


DKMS make.log for tp_smapi-0.43 for kernel 6.4.0-0-amd64 (x86_64)
Fri Jun 16 14:10:47 UTC 2023
make: Entering directory '/usr/src/linux-headers-6.4.0-0-amd64'
  CC [M]  /var/lib/dkms/tp_smapi/0.43/build/thinkpad_ec.o
  CC [M]  /var/lib/dkms/tp_smapi/0.43/build/tp_smapi.o
  CC [M]  /var/lib/dkms/tp_smapi/0.43/build/hdaps.o
/var/lib/dkms/tp_smapi/0.43/build/thinkpad_ec.c:94:42: error: macro 
"DEFINE_SEMAPHORE" requires 2 arguments, but only 1 given
   94 | static DEFINE_SEMAPHORE(thinkpad_ec_mutex);
  |  ^
In file included from /var/lib/dkms/tp_smapi/0.43/build/thinkpad_ec.c:45:
/usr/src/linux-headers-6.4.0-0-common/include/linux/semaphore.h:34: note: macro 
"DEFINE_SEMAPHORE" defined here
   34 | #define DEFINE_SEMAPHORE(_name, _n) \
  |
/var/lib/dkms/tp_smapi/0.43/build/thinkpad_ec.c:94:8: error: type defaults to 
'int' in declaration of 'DEFINE_SEMAPHORE' [-Werror=implicit-int]
   94 | static DEFINE_SEMAPHORE(thinkpad_ec_mutex);
  |^~~~
/var/lib/dkms/tp_smapi/0.43/build/thinkpad_ec.c: In function 'thinkpad_ec_lock':
/var/lib/dkms/tp_smapi/0.43/build/thinkpad_ec.c:112:35: error: 
'thinkpad_ec_mutex' undeclared (first use in this function); did you mean 
'thinkpad_ec_lock'?
  112 | ret = down_interruptible(&thinkpad_ec_mutex);
  |   ^
  |   thinkpad_ec_lock
/var/lib/dkms/tp_smapi/0.43/build/thinkpad_ec.c:112:35: note: each undeclared 
identifier is reported only once for each function it appears in
/var/lib/dkms/tp_smapi/0.43/build/thinkpad_ec.c: In function 
'thinkpad_ec_try_lock':
/var/lib/dkms/tp_smapi/0.43/build/thinkpad_ec.c:126:30: error: 
'thinkpad_ec_mutex' undeclared (first use in this function); did you mean 
'thinkpad_ec_lock'?
  126 | return down_trylock(&thinkpad_ec_mutex);
  |  ^
  |  thinkpad_ec_lock
/var/lib/dkms/tp_smapi/0.43/build/thinkpad_ec.c: In function 
'thinkpad_ec_unlock':
/var/lib/dkms/tp_smapi/0.43/build/thinkpad_ec.c:138:13: error: 
'thinkpad_ec_mutex' undeclared (first use in this function); did you mean 
'thinkpad_ec_lock'?
  138 | up(&thinkpad_ec_mutex);
  | ^
  | thinkpad_ec_lock
/var/lib/dkms/tp_smapi/0.43/build/thinkpad_ec.c: In function 
'thinkpad_ec_try_lock':
/var/lib/dkms/tp_smapi/0.43/build/thinkpad_ec.c:127:1: error: control reaches 
end of non-void function [-Werror=return-type]
  127 | }
  | ^
/var/lib/dkms/tp_smapi/0.43/build/thinkpad_ec.c: At top level:
/var/lib/dkms/tp_smapi/0.43/build/thinkpad_ec.c:94:8: warning: 
'DEFINE_SEMAPHORE' defined but not used [-Wunused-variable]
   94 | static DEFINE_SEMAPHORE(thinkpad_ec_mutex);
  |^~~~
cc1: some warnings being treated as errors
make[1]: *** [/usr/src/linux-headers-6.4.0-0-common/scripts/Makefile.build:257: 
/var/lib/dkms/tp_smapi/0.43/build/thinkpad_ec.o] Error 1
make[1]: *** Waiting for unfinished jobs
/var/lib/dkms/tp_smapi/0.43/build/tp_smapi.c:115:36: error: macro 
"DEFINE_SEMAPHORE" requires 2 arguments, but only 1 given
  115 | static DEFINE_SEMAPHORE(smapi_mutex);
  |^
In file included from 
/usr/src/linux-headers-6.4.0-0-common/include/linux/fs.h:25,
 from 
/usr/src/linux-headers-6.4.0-0-common/include/linux/proc_fs.h:10,
 from /var/lib/dkms/tp_smapi/0.43/build/tp_smapi.c:41:
/usr/src/linux-headers-6.4.0-0-common/include/linux/semaphore.h:34: note: macro 
"DEFINE_SEMAPHORE" defined here
   34 | #define DEFINE_SEMAPHORE(_name, _n) \
  |
/var/lib/dkms/tp_smapi/0.43/build/tp_smapi.c:115:8: error: type defaults to 
'int' in declaration of 'DEFINE_SEMAPHORE' [-Werror=implicit-int]
  115 | static DEFINE_SEMAPHORE(smapi_mutex);
  |^~~~
/var/lib/dkms/tp_smapi/0.43/build/tp_smapi.c: In function 
'store_battery_start_charge_thresh':
/var/lib/dkms/tp_smapi/0.43/build/tp_smapi.c:780:15: error: 'smapi_mutex' 
undeclared (first use in this function)
  780 | down(&smapi_mutex);
  |   ^~~
/var/lib/dkms/tp_smapi/0.43/build/tp_smapi.c:780:15: note: each undeclared 
identifier is reported only once for each function it appears in
/var/lib/dkms/tp_smapi/0.43/build/tp_smapi.c: In function 
'store_battery_stop_charge_thresh':
/var/lib/dkms/tp_smapi/0.43/build/tp_smapi.c:822:15: error: 'smapi_mutex' 
undeclared (first use in this function)
  822 | down(&smapi_mutex);
  |   ^~~
/var/lib/dkms/tp_smapi/0.43/build/tp_smapi.c: At top level:
/var/lib/dkms/tp_smapi/0.43/build/tp_smapi.c:115:8: warning: 'DEFINE_SEMAPHORE' 
defined but not used [-Wunused-variable]
  115 | static DEFINE_SEMAPHORE(smapi_mute

Bug#1031115: Update gnome-shell-extension-weather to 121 to support GNOME 44

[Jeremy Bícha]

On Fri, Jun 16, 2023 at 10:09 AM Amr Ibrahim  wrote:
> Please update gnome-shell-extension-weather to 121 to support GNOME 44.

Please open a separate bug for separate issues.

If you file that bug, could you use a user and usertag for gnome-shell
44 as was done with https://bugs.debian.org/1037163 ?

That allows us to use a tracker like
https://udd.debian.org/cgi-bin/bts-usertags.cgi?user=pkg-gnome-maintain...@lists.alioth.debian.org&tag=gnome-shell-44
to figure out what the blockers are for getting GNOME Shell 44 into
Unstable.

Thank you,
Jeremy Bícha

Bug#1038208: webext-keepassxc-browser: Please push from experimental to unstable

[Amr Ibrahim]

Package: webext-keepassxc-browser
Version: 1.8.6+repack1-1
Severity: normal

Hallo Bruno,

Please push keepassxc-browser from experimental to unstable.

Best,
Amr


-- System Information:
Debian Release: 12.0
  APT prefers testing
  APT policy: (500, 'testing'), (100, 'unstable'), (50, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-9-amd64 (SMP w/8 CPU threads; PREEMPT)
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

Versions of packages webext-keepassxc-browser depends on:
ii  keepassxc  2.7.4+dfsg.1-2

Versions of packages webext-keepassxc-browser recommends:
ii  chromium  114.0.5735.133-1
ii  firefox   114.0-1

webext-keepassxc-browser suggests no packages.

-- no debconf information

Bug#1020533: dpkg should use /var/lib/dpkg/arch to determine native arch when running chrootless

[Johannes Schauer Marin Rodrigues]

Hi Guillem,

Quoting Guillem Jover (2022-10-10 12:23:58)
> On Thu, 2022-09-22 at 22:13:34 +0200, Johannes Schauer Marin Rodrigues wrote:
> As mentioned on IRC, the problem here (and on #825385) is indeed that dpkg
> considers its own arch the native one, and when operating on a cross-arch
> chroot, that goes wrong, both in dependency resolution and when outputting
> arch-qualified package names for example.
> 
> Fixing this properly is tricky though, because there are multiple
> requirements in tension here:
> 
>   * The external dpkg should be able to tell what's the arch for the
> internal one w/o having to execute anything (that it might not be
> able to run anyway).
>   * Setting a file on the database means either requiring a dpkg
> maintscript (for the bootstrap phase) which we are trying to get
> rid of, or offloading this to the bootstrappers (even worse), it
> also means it could be modified w/o dpkg noticing, which can break
> dependency resolution from an existing system.
>   * Shipping a file with the arch would seem like the best option (as
> that is checksummed) and not in the db, but that means then, that
> pathname under /usr needs to be selectable too at run-time, as
> that encodes configure-time vendor-specific fsys layout.
>   * Setting that directory from the config file is currently
> problematic as dpkg does not have a way to specify a different
> config directory.
>   * Perhaps just adding a new --foodir option to dpkg could be enough
> for now, if the inner dpkg uses a different pathname, in the
> same way if it uses a different database pathname.
>   * But then only specifying the db pathname would no longer be
> enough, and dependency resolution and arch-qualifying would still
> be wrong. :/
>   * But then if the file does not exist (or cannot be found in the
> «right» place) it could still fallback to the currently running
> native arch, but that looks flaky (not worse than now, though,
> but not ideal). :/
> 
> I guess I can prototype something with the --foodir idea though, but that's
> still rather meh.

once you have a prototype (even if it's not release-ready) feel free to share
it, because our CI setup is able to apply patches to source packages. So if you
have something that we can test, just send it over and we'll build a patched
dpkg to run this with our scripts.

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1038205: ITP: basis-universal -- Basis Universal GPU Texture Codec

[Johannes Schauer Marin Rodrigues]

Hi,

On Fri, 16 Jun 2023 15:49:46 +0200 =?UTF-8?Q?G=C3=BCrkan_Myczko?= 
 wrote:
> * Package name: basis-universal

I think this is a really bad package name. There is nothing like a basis or
universal about this package for the average Debian system. This name sounds
like it belongs into the same category as base-files or base-passwd.

Other distros like gentoo [1] put this package in the games category to give
some more context to the name. As we do not have this mechanism in Debian I
think that context should be in the package name. Maybe include that this is
about GPU textures?

Thanks!

cheers, josch

[1] https://packages.gentoo.org/packages/games-util/basis_universal

signature.asc
Description: signature

Bug#1038210: please provide a way to use UCRT instead of MSVCRT

[Sébastien Villemot]

Source: gcc-mingw-w64
Version: 25.2
Severity: wishlist

Dear Maintainer,

Recent versions of Windows ship a newer C runtime, UCRT, meant to supersede the
historical one, MSVCRT.

In particular, the MSYS2 project now produces packages compiled against UCRT
and considers them as the recommended ones:
https://www.msys2.org/docs/environments/

Currently, MinGW cross-compilers in Debian produce binaries linked against
MSVCRT. It would be nice if there was an easy and supported way of producing
binaries linked against UCRT.

As I understand it, there are two ways of achieving this:

1. at compile time of src:gcc-mingw-w64, by passing option
   --with-default-msvcrt=ucrt

2. at runtime, by passing a modified specs file to the cross-compiler (more
   specifically, replacing -lmsvcrt by -lucrt in the libgcc section)

Option 2 already works with the current version of src:gcc-mingw-w64. But it
would be better if there was an easier and less tricky way of achieving the
same (for example by providing different package flavours; or by providing a
specs file explictly designed for that purpose, possibly activated by the
alternatives system).

Thanks for your work,

--
⢀⣴⠾⠻⢶⣦⠀  Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁  Debian Developer
⢿⡄⠘⠷⠚⠋⠀  https://sebastien.villemot.name
⠈⠳⣄  https://www.debian.org

Bug#1038166: php-imagick: on upgrades /etc/php/7.4/mods-available/imagick.ini is left behind

[Ondřej Surý]

> 
> On 16. 6. 2023, at 13:19, Michael Prokop  wrote:
> 
> And I purged all of the php7.4 one

You did not. The rc at the beginning of the line means exactly that.

ondrej@calcifer:~$ dpkg -l php7.4-memcached
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/tri>
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version >
+++-->
rc  php7.4-memcached 3.1.5+2.2.0-9+0~20210228.30+debian11~1.g>

ondrej@calcifer:~$ sudo dpkg --purge php7.4-memcached
(Reading database ... 309586 files and directories currently installed.)
Purging configuration files for php7.4-memcached 
(3.1.5+2.2.0-9+0~20210228.30+debian11~1.gbp2db493) ...


ondrej@calcifer:~$ dpkg -l php7.4-memcached
dpkg-query: no packages found matching php7.4-memcached
ondrej@calcifer:~$

--
Ondřej Surý  (He/Him)

Bug#1038210: please provide a way to use UCRT instead of MSVCRT

[Sébastien Villemot]

Le vendredi 16 juin 2023 à 16:42 +0200, Sébastien Villemot a écrit :
> 2. at runtime, by passing a modified specs file to the cross-compiler (more
>specifically, replacing -lmsvcrt by -lucrt in the libgcc section)

Actually I realize that this solution probably does not work very
reliably, in particular for C++ programs (because libstdc++ would still
be built against MSVCRT).

So the only reliable solution may be to provide different binary
packages with cross-compilers for UCRT.

-- 
⢀⣴⠾⠻⢶⣦⠀  Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁  Debian Developer
⢿⡄⠘⠷⠚⠋⠀  https://sebastien.villemot.name
⠈⠳⣄  https://www.debian.org



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

Bug#1038001: librem-ec-acpi-dkms: Patch available upstream

[Dylan Thurston]

Package: librem-ec-acpi-dkms
Version: 0.9.1-4
Followup-For: Bug #1038001
X-Debbugs-Cc: d...@bostoncoop.net

There's a patch for this upstream:
https://source.puri.sm/nicole.faerber/librem-ec-acpi-dkms/-/commit/cec8c0e8bf1532c9c605f60bb02a2ef0f98e5d77

--Dylan Thurston


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

Kernel: Linux 6.1.0-9-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.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 librem-ec-acpi-dkms depends on:
ii  dkms  3.0.11-2

librem-ec-acpi-dkms recommends no packages.

librem-ec-acpi-dkms suggests no packages.

-- no debconf information

Bug#1038139: debci-worker: Process leaks authentication data via amqp-tools

[Antonio Terceiro]

On Thu, Jun 15, 2023 at 10:48:57PM +0200, Christian Kastner wrote:
> 
> Package: debci
> Version: 3.6
> Severity: serious
> Tags: security
> X-Debbugs-Cc: Debian Security Team 
> 
> Hi,
> 
> When using authentication in AMQP connections, the username and password
> supplied in the --url option to amqp-consume resp. amqp-publish are
> exposed in the proces list, see #1037322:
> 
>   $ pgrep -a ampq-consume
>   62287 amqp-consume --url amqp://user:pass@192.168.0.1 --queue=myqueue
> 
> A patch has been accepted upstream to read the username and password
> from a file. I assume this will make its way into ampq-tools soon.
> 
> Unless I'm mistaken, debci will need to be updated for this, e.g. by
> adding a debci_amqp_pwfile config option + NEWS entry suggesting that
> people migrate to this new option. I'd be happy to file an MR for this,
> once ampq-tools has been fixed.

Note that the variable where you inserted a username and password is
calle debci_amqp_server, and was never supposed to be used for putting a
password in plain text. For the c.d.n deployment we use SSL client
certificates for authentication, and that's why the variables
debci_amqp_cacert, debci_amqp_cert, debci_amqp_key are there.

IMO that is no different from any other program that takes a url as a
command line parameter: you can pass a URL containing a username and
password, but then that's on you.


signature.asc
Description: PGP signature

Bug#337676: viruskiller: Highscores are not saved

[Tassia Camoes Araujo]

Hello Artur and Jose,

I have just tested the viruskiller version 1.03-1+dfsg1-2 and my scores
are not saved, so I'm considering the bug as reproducible. It seems all
3 levels of high scores are placeholder lists with the same names of
players, random points, and all with 100 kills.

One thing to notice is that at some point in the gameplay my scores
always go negative, so it might be simply that I could not displace any
of those fake players from the list because my points were not high
enough. But the fact that my own higher scores are not saved seems to be
a functional bug IMHO.

If anyone else is willing to dig into this, I hope this helps!
Cheers,

Tassia.

Bug#1038211: RM: dpdk/experimental [armhf] -- ROM; architecture support removed

[Luca Boccassi]

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

Dear FTP Team,

We no longer support DPDK on armhf, and it was removed from unstable
and bookworm. But there is a leftover in experimental, please remove
it.

-- 
Kind regards,
Luca Boccassi


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

Bug#1037925: I also get this on Arm64/aarch64

[Ralph Aichinger]

Just wanted to chime in, that I get this same bug on arm64.
Same warnings when I try to icingaweb2 setup flow.

I would love to do the 
Removing the .ini files I ran the wizard again.
workaround, but I don't understand which .ini files
I should remove, and if I should do something else in
addition (downgrade PHP?).

Ralph

ii  libapache2-mod-php8.2 8.2.5-2  arm64server-side, HTML-embedded 
scripting language (Apache 2 module)
ii  php   2:8.2+93 all  server-side, HTML-embedded 
scripting language (default)
ii  php-common2:93 all  Common files for PHP 
packages
ii  php-curl  2:8.2+93 all  CURL module for PHP 
[default]
ii  php-gd2:8.2+93 all  GD module for PHP [default]
ii  php-icinga2.11.4-2 all  PHP library to communicate 
with and use Icinga
ii  php-imagick   3.7.0-4  arm64Provides a wrapper to the 
ImageMagick library
ii  php-intl  2:8.2+93 all  Internationalisation module 
for PHP [default]
ii  php-json  2:8.2+93 all  JSON module for PHP 
[default]
ii  php-ldap  2:8.2+93 all  LDAP module for PHP 
[default]
ii  php-mbstring  2:8.2+93 all  MBSTRING module for PHP 
[default]
ii  php-mysql 2:8.2+93 all  MySQL module for PHP 
[default]

ii  icinga-php-library   0.10.1-1 all  Icinga PHP Library 
for Icinga Web 2
ii  icinga-php-thirdparty0.11.0-2 all  Icinga PHP 
Thirdparty libraries for Icinga Web 2
ii  icinga2  2.13.6-2 arm64host and network 
monitoring system
ii  icinga2-bin  2.13.6-2 arm64host and network 
monitoring system - daemon
ii  icinga2-common   2.13.6-2 all  host and network 
monitoring system - common files
ii  icinga2-doc  2.13.6-2 all  host and network 
monitoring system - documentation
ii  icingacli2.11.4-2 all  simple CLI tool for 
Icingaweb2 and its modules
ii  icingaweb2   2.11.4-2 all  simple and 
responsive web interface for Icinga
ii  icingaweb2-common2.11.4-2 all  simple and 
responsive web interface for Icinga - common files
ii  icingaweb2-module-doc2.11.4-2 all  simple and 
responsive web interface for Icinga - documentation module
ii  icingaweb2-module-monitoring 2.11.4-2 all  simple and 
responsive web interface for Icinga - monitoring module
un  icingaweb2-module-setup(no description 
available)

Bug#1038212: Aggiornamento a Debian 12 interrotto

[Joe Fiallo]

Package:    libsasl2-2

Version:    /stable 2.1.28+dfsg-10 arm64 [aggiornabile da: 
2.1.27+dfsg-2.1+deb11u1]


Durante l'aggiornamento da Debian 11.7   a 12.0  la procedura di 
full-upgrade si interrompe.


Il package che non si può aggiornare è  libsasl2-2



Il tentativo di proseguire con "apt --fix-broken install"

produce il seguente output

Preparativi per estrarre .../libsasl2-2_2.1.28+dfsg-10_arm64.deb...
dpkg: errore nell'elaborare l'archivio 
/var/cache/apt/archives/libsasl2-2_2.1.28+dfsg-10_arm64.deb (--unpack):
 il file dei trigger "ci" contiene una direttiva "bct{vate-noaw��0" 
sconosciuta

Si sono verificati degli errori nell'elaborazione:
 /var/cache/apt/archives/libsasl2-2_2.1.28+dfsg-10_arm64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)

Il sistema con aggiornamento parziale risponde a uname:

Linux pigreco4 6.1.21-v8+ #1642 SMP PREEMPT Mon Apr  3 17:24:16 BST 2023 
aarch64 GNU/Linux




Grazie per la vostra importante attività


Joe

Bug#1038213: please drop transitional package afl from src:aflplusplus

[Holger Levsen]

Package: afl
Version: 4.04c-4
Severity: normal
user: qa.debian@packages.debian.org
usertags: transitional

Please drop the transitional package afl (from the source package aflplusplus) 
for trixie, as it has been released with bullseye and bookworm already.


Description: transitional dummy package for afl to afl++
Package: afl
Version: 2.68c-1
Version: 4.04c-4

Thanks for maintaining aflplusplus!


-- 
cheers,
Holger

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

The past is over.


signature.asc
Description: PGP signature

Bug#1038214: please drop transitional package afl++-clang from src:aflplusplus

[Holger Levsen]

Package: afl++-clang
Version: 4.04c-4
Severity: normal
user: qa.debian@packages.debian.org
usertags: transitional

Please drop the transitional package afl++-clang (from the source package 
aflplusplus) for trixie, as it has been released with bullseye and bookworm 
already.


Description: instrumentation-driven fuzzer for binary formats - clang support
Description: transitional dummy package for afl++-clang to afl++
Package: afl++-clang
Version: 2.68c-1+b1
Version: 4.04c-4

Thanks for maintaining aflplusplus!


-- 
cheers,
Holger

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

"I know what you're thinking" used to be an idiom but now it's a business model.


signature.asc
Description: PGP signature

Bug#1038215: please drop transitional package afl-clang from src:aflplusplus

[Holger Levsen]

Package: afl-clang
Version: 4.04c-4
Severity: normal
user: qa.debian@packages.debian.org
usertags: transitional

Please drop the transitional package afl-clang (from the source package 
aflplusplus) for trixie, as it has been released with bullseye and bookworm 
already.


Description: transitional dummy package for afl-clang to afl++-clang
Package: afl-clang
Version: 2.68c-1
Version: 4.04c-4

Thanks for maintaining aflplusplus!


-- 
cheers,
Holger

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

Make earth cool again.


signature.asc
Description: PGP signature

Bug#1038216: please drop transitional package afl-doc from src:aflplusplus

[Holger Levsen]

Package: afl-doc
Version: 4.04c-4
Severity: normal
user: qa.debian@packages.debian.org
usertags: transitional

Please drop the transitional package afl-doc (from the source package 
aflplusplus) for trixie, as it has been released with bullseye and bookworm 
already.


Description: transitional dummy package for afl-doc to afl++-doc
Package: afl-doc
Version: 2.68c-1
Version: 4.04c-4

Thanks for maintaining aflplusplus!


-- 
cheers,
Holger

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

The upcoming clima apocalypse is the big elephant in every room now.


signature.asc
Description: PGP signature

Bug#1038218: please drop transitional package apertium-ca-it from src:apertium-cat-ita

[Holger Levsen]

Package: apertium-ca-it
Version: 0.2.2-1
Severity: normal
user: qa.debian@packages.debian.org
usertags: transitional

Please drop the transitional package apertium-ca-it (from the source package 
apertium-cat-ita) for trixie, as it has been released with bullseye and 
bookworm already.


Description: Transitional dummy package for apertium-cat-ita
Package: apertium-ca-it
Version: 0.2.1-3
Version: 0.2.2-1

Thanks for maintaining apertium-cat-ita!


-- 
cheers,
Holger

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

Some people say that the climate crisis  is something that we all have created,
but  that is not true,  because if everyone is guilty  then no one is to blame.
And someone is to blame.  Some people, some companies,  some decision-makers in
particular, have known exactly what priceless values they have been sacrificing
to continue making unimaginable amounts of money. (Greta Thunberg)


signature.asc
Description: PGP signature

Bug#1038217: please drop transitional package apertium-af-nl from src:apertium-afr-nld

[Holger Levsen]

Package: apertium-af-nl
Version: 0.3.0-3
Severity: normal
user: qa.debian@packages.debian.org
usertags: transitional

Please drop the transitional package apertium-af-nl (from the source package 
apertium-afr-nld) for trixie, as it has been released with bullseye and 
bookworm already.


Description: Transitional dummy package for apertium-afr-nld
Package: apertium-af-nl
Version: 0.3.0-2
Version: 0.3.0-3

Thanks for maintaining apertium-afr-nld!


-- 
cheers,
Holger

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

I have a joke about trickle down economics. 99% of you won’t ever get it.


signature.asc
Description: PGP signature

Bug#1038219: please drop transitional package apertium-en-ca from src:apertium-eng-cat

[Holger Levsen]

Package: apertium-en-ca
Version: 1.0.1-5
Severity: normal
user: qa.debian@packages.debian.org
usertags: transitional

Please drop the transitional package apertium-en-ca (from the source package 
apertium-eng-cat) for trixie, as it has been released with bullseye and 
bookworm already.


Description: Transitional dummy package for apertium-eng-cat
Package: apertium-en-ca
Version: 1.0.1-4
Version: 1.0.1-5

Thanks for maintaining apertium-eng-cat!


-- 
cheers,
Holger

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

All data, over time, approaches deleted, or public. (@quinnnorton)


signature.asc
Description: PGP signature