Bug#1065533: RFP: libsdl2-pango -- pango extension for sdl2

[Jonathan Carter]

Package: wnpp
Severity: wishlist

* Package name: libsdl2-pango
  Version : 2.1.5 
  Upstream Contact: https://github.com/markuskimius
* URL : https://github.com/markuskimius/SDL2_Pango
* License : LGPL-2.1+ 
  Programming Lang: C
  Description : pango extension for sdl2

This is needed as a depencency for Tuxpaint.

Upstream contains an included debian directory with existing packaging that
likely just needs to be cleaned up / updated a bit for the archive.

Bug#1064139: Bug #1064139 ogre-1.12: FTBFS: error: ‘BuildFontAtlas’ is not a member of ‘ImGuiFreeType’

[Flavien Bridault]

Dear maintainer(s),

I took a look at the latest version of Ogre which is probably compatible 
with latest ImGui and it seems this line is no longer necessary. It was 
removed before the release 13.0.0 when upgrading to ImGUI 1.83 : 
https://github.com/OGRECave/ogre/commit/17b7481057b97662a3752ee605ea77a9eb0c57db


Patching should be then fairly easy...

I can offer my help again, like I did to upgrade to 1.14 
(https://lists.debian.org/debian-devel-games/2023/11/msg1.html), 
which whould really be the best option in the end... Maybe I will have 
an official answer this time ? I don't want to be sarcastic at all, but 
I strongly depend on Ogre to build sight and this is annoying to get no 
answer from the devel games team. And currently my package sight is 
currently marked for autoremoval because of this bug 
(https://tracker.debian.org/pkg/sight)


Kind regards,

--

*Dr. Flavien BRIDAULT*
Director of Software Development
IRCAD France & IRCAD Africa

flavien.brida...@ircad.fr 
Tél. : +33 (0)3 88 119 201
IRCAD France
http://www.ircad.fr/
http://www.ircad.africa/ 

Suivez l'IRCAD sur Facebook 



*IRCAD France*
Hôpitaux Universitaires - 1, place de l'Hôpital - 67091 Strasbourg Cedex 
- FRANCE




OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#965333: libvirt-daemon-system: Please make a separate package for apparmor profiles

[Mikhail Morfikov]

On 05/03/2024 10.53 pm, Andrea Bolognani wrote:

On Sun, Jul 19, 2020 at 08:08:15PM +0200, Mikhail Morfikov wrote:

Dear Maintainer,

Currently when the package is installed, it also installs files under
/etc/apparmor.d/ . There are two issues with this:

1) some people want to use their own profile (the local profile under
/etc/apparmor.d/local/ may not be an option for many reasons),
2) some of the names of the files are path based, and some users could use just
the exec/binary name (or whatever) for the profile/file name, which leads to
having two different sets of rules (two different apparmor profiles loaded at
the same time confining the same app).

The only way to fix this is to manually remove the provided apparmor profile
files after each package update, which is a little bit annoying.

Please reconsider creating a separate package for the apparmor profile files
(something similar to package_name-apparmor-profile), and just
suggest/recommend it in deps of the main package, so the user could decide
whether he wants the profiles to be installed in his system or not.


Hi Mikhail,

I am currently working on a big refactoring of the libvirt package,
which I thought could be the perfect opportunity to implement the
split that you're suggesting here.

However, looking at the contents of the archive, it seems that the
practice of shipping AppArmor profiles as separate package from the
software that they're intended for is far from widespread:

   $ apt-cache search -n apparmor
   apparmor - user-space parser utility for AppArmor
   apparmor-notify - AppArmor notification system
   apparmor-profiles - experimental profiles for AppArmor security policies
   apparmor-utils - utilities for controlling AppArmor
   dh-apparmor - AppArmor debhelper routines
   libapache2-mod-apparmor - changehat AppArmor library as an Apache module
   libapparmor-dev - AppArmor development libraries and header files
   libapparmor1 - changehat AppArmor library
   libpam-apparmor - changehat AppArmor library as a PAM module
   python3-apparmor - AppArmor Python3 utility library
   python3-libapparmor - AppArmor library Python3 bindings
   apparmor-profiles-extra - Extra profiles for AppArmor Security policies
   fwknop-apparmor-profile - FireWall KNock OPerator - Apparmor profile
   uwsgi-plugin-apparmor - apparmor plugin for uwsgi

If we exclude apparmor-profiles(-extra), which by definition don't
count as they are maintained separately from the corresponding
applications, the only example I can see is fwknop.

This gives me pause, and makes me not particularly keen on going down
such a lonesome path.

I'd like to understand your use case better though. Can you please
provide concrete examples of the problematic scenarios you've
mentioned in your original message, along with the steps that you
currently have to perform to work around them?

Thanks in advance!




Yes, I know that only few projects provide a separate package with apparmor
profiles.

I tried to change that by requesting people to do the change. But I failed,
so I stopped asking people to do this a long time ago.

Why I wanted the change?

Take a look for example at the thunderbird email client package. They ship
the apparmor profile for the app in the thunderbird package (I also asked them
to do the move, but no one cared, see #949649 from 23 Jan 2020 -- no one ever
answered).

So I use thunderbird and I have my own separate profile for this app because
I have different rules, aiming different security policy. Each time the
thunderbird package is updated, the apparmor profile is also installed, and
I have no option to forbid that. So the apparmor policy is rewritten, which
requires me to manually remove the newly installed thunderbird profile (the
physical file), remove non exising profiles from apparmor (aa-remove-unknown),
reload my own profile, update initramfs (since I load the apparmor policy during
initramfs phase).

Why to do this all the time when a package is updated? The solution is
simple -- not to force users to use the provided apparmor profile for the app
and allow them to decide.

That's why I tried to convince people to make a separate packages for apparmor
profiles, so users could decide whether they want the apparmor profile installed
in their systems or not.

Most of people don't even use apparmor, so they don't care whether the profile 
is
in the core package, or in some app-apparmor-profile package. But there are 
people
who use apparmor (and I use it extensively), for instance:

# aa-status | grep -v ^" "
apparmor module is loaded.
1042 profiles are loaded.
918 profiles are in enforce mode.
124 profiles are in complain mode.
0 profiles are in kill mode.
0 profiles are in unconfined mode.
406 processes have profiles defined.
94 processes are in enforce mode.
312 processes are in complain mode.
0 processes are unconfined but have a profile defined.
0 processes are in mixed mode.
0 processes are in kill mode.

That's a lot of profiles, 

Bug#1064617: Passwords should not be changed frequently

[Philip Hands]

Justin B Rye  writes:

> Philip Hands wrote:
>> Justin B Rye  writes:
...
>> 
>> The reason behind that structure was supposed to be that one definitely
>> needs _a_ password, but not necessarily a root password, so the password
>> advice applies to whichever password you'll decide to grant root access
>> to, which might not be set here.
>
> This template is specifically about the "Root password/passphrase";

Well, sort-of, except that the user's response (whether to leave this
blank or not) modifies what happens with the user account's permissions,
so it's also about explaining the way that logic works in the installer
and what that will do to the target system.

> probably I should have quoted the patch I was looking at, which starts
> with "One needs a password/passphrase that grants access to the 'root'
> (system administrative) account" but goes on to say "Alternatively,
> you can lock root's password by leaving this setting empty".

I'm intimately familiar with the patches you're reading, so I feel like
this comment suggests that we may be talking past one another somehow.

Cheers, Phil.
-- 
Philip Hands -- https://hands.com/~phil


signature.asc
Description: PGP signature

Bug#1065532: node-dompurify: please upgrade to new version

[Paul Gevers]

Source: node-dompurify
Version: 2.4.1+dfsg+~2.4.0-1
Severity: normal

Hi,

I'm the package maintainer of liferea and my upstream has embedded 
purify.js in his latest release (at version 3.0.6). Could you please 
update the package to avoid too much risk of unexpected behavior?


Paul

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

Kernel: Linux 6.6.15-amd64 (SMP w/4 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


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1031200: /usr/sbin/faxgetty: Re: hylafax-server: faxgetty.service doesn't work with iaxmodem

[Benoit Panizzon]

Package: hylafax-server
Version: 3:6.0.7-5
Followup-For: Bug #1031200

Dear Maintainer,

Experienced same issue and I'm not sure when it was introduced and what the 
exact cause ist but I
don't recall I experiencing it on the last reboot (probably several months ago)

But what I suspect the cause to be:

iaxmodem creates a link from /dev/ttyIAX to a dynamic /dev/pts device.

The faxgetty systemd script contains:

BindsTo=dev-%i.device
After=dev-%i.device

And if %i is a link and not a real device, udev never triggers an event and the 
device binding is never true.

Commenting out those two statements solved the issue for me for now.

-Benoit-

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

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

Versions of packages hylafax-server depends on:
ii  adduser  3.134
ii  bsd-mailx [mailx]8.1.2-0.20220412cvs-1
ii  debconf [debconf-2.0]1.5.82
ii  ghostscript  10.0.0~dfsg-11+deb12u3
ii  hylafax-client   3:6.0.7-5
ii  init-system-helpers  1.65.2
ii  libc62.36-9+deb12u4
ii  libcrypt11:4.4.33-2
ii  libgcc-s112.2.0-14
ii  libjbig0 2.1-6.1
ii  libpam0g 1.5.2-6+deb12u1
ii  libstdc++6   12.2.0-14
ii  libtiff-tools4.5.0-6+deb12u1
ii  libtiff6 4.5.0-6+deb12u1
ii  lsb-base 11.6
ii  psmisc   23.6-1
ii  sed  4.9-1
ii  sendmail-bin [mail-transport-agent]  8.17.1.9-2
ii  systemd  252.22-1~deb12u1
ii  sysvinit-utils [lsb-base]3.06-4
ii  zlib1g   1:1.2.13.dfsg-1

hylafax-server recommends no packages.

Versions of packages hylafax-server suggests:
pn  mgetty  
pn  psrip   

-- Configuration Files:
/etc/hylafax/hosts.hfaxd changed:
localhost


-- debconf information:
  hylafax-server/start_now: true
  hylafax-server/setup_failed:

-- debsums errors found:
debsums: changed file /lib/systemd/system/faxgetty@.service (from 
hylafax-server package)

Bug#1065531: apt forced libexpat1 to be removed before python3.11-minimal

[Andrey Rahmatullin]

Package: apt,python3.11-minimal
Severity: normal

Control: affects -1 python3-scrapy

During piuparts testing of python3-scrapy piuparts asked apt to remove packages
including python3* and libexpat1, and libexpat1 was removed before e.g.
python3.11-minimal which depends on it, with dpkg printing a warning about this
fact. But as prerm of python3.11-minimal needs libexpat1, prerm and the apt
transaction failed with "/usr/bin/python3: error while loading shared
libraries: libexpat.so.1: cannot open shared object file". The full log is
currently available at
https://piuparts.debian.org/sid/fail/python3-scrapy_2.11.1-1.log and I'm also
attaching it. The relevant part is the last one.

There are several additional things to note:

1. "python3.11-minimal depends on libexpat1" is not the only dependency problem
reported for the transaction, there are several other problems reported later,
all involving python3{,.11} subpackages.
2. This happened during the t64 transition, involved versions of src:expat and
src:python3-defaults are older than that while src:python3.11 (= 3.11.8-2) is
related to it.
3. piuparts asked apt to remove (among other packages) libssl3t64 and install
libssl3:amd64=3.1.5-1, but libssl3* aren't related to libexpat1,
python3.11-minimal also doesn't depend on them.


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

Kernel: Linux 6.7.7-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.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
Start: 2024-03-01 10:02:29 GMT

Package: python3-scrapy
Source: python-scrapy
Version: 2.11.1-1
Installed-Size: 1052
Maintainer: Debian Python Team 
Architecture: all
Depends: python3-lxml, python3-pydispatch, python3-cryptography (>= 36.0.0), 
python3-cssselect, python3-itemadapter, python3-itemloaders, python3-openssl, 
python3-packaging, python3-parsel (>= 1.8.1), python3-pkg-resources, 
python3-protego, python3-queuelib, python3-service-identity, 
python3-tldextract, python3-twisted, python3-w3lib, python3-zope.interface, 
python3:any
Recommends: ipython3, python3-brotli, python3-pil
Suggests: python3-boto3, python3-botocore, python-scrapy-doc (= 2.11.1-1)
Description: Python web scraping and crawling framework (Python 3)
Homepage: https://scrapy.org/
Description-md5: de81941edea93a8d65f470aa9a6bbc8a
Section: python
Priority: optional
Filename: pool/main/p/python-scrapy/python3-scrapy_2.11.1-1_all.deb
Size: 259188
MD5sum: 74540053503bba92acf4db683413d6c7
SHA256: 449a3cce5c5ebf1fe93141cecc0088e14a7f2997eacb20bf9dd14b27048e2edf

Executing: sudo env 
PYTHONPATH=/srv/piuparts.debian.org/lib/python3/dist-packages timeout -s INT -k 
5m 80m /srv/piuparts.debian.org/sbin/piuparts --scriptsdir 
/etc/piuparts/scripts-log-alternatives --scriptsdir /etc/piuparts/scripts 
--no-eatmydata --allow-database --warn-on-leftovers-after-purge --mirror 
'http://deb.debian.org/debian/ main' --tmpdir /srv/piuparts.debian.org/tmp 
--arch amd64 -b 
/srv/piuparts.debian.org/slave/basetgz/sid-merged-usr_amd64.tar.gz -d sid 
--no-upgrade-test --apt python3-scrapy=2.11.1-1
0m0.0s INFO: 
--
0m0.0s INFO: To quickly glance what went wrong, scroll down to the bottom of 
this logfile.
0m0.0s INFO: FAQ available at https://wiki.debian.org/piuparts/FAQ
0m0.0s INFO: The FAQ also explains how to contact us in case you think piuparts 
is wrong.
0m0.0s INFO: 
--
0m0.0s INFO: piuparts version 1.3.1~202401311836~1.3-2-g28295102 starting up.
0m0.0s INFO: Command line arguments: /srv/piuparts.debian.org/sbin/piuparts 
--scriptsdir /etc/piuparts/scripts-log-alternatives --scriptsdir 
/etc/piuparts/scripts --no-eatmydata --allow-database 
--warn-on-leftovers-after-purge --mirror 'http://deb.debian.org/debian/ main' 
--tmpdir /srv/piuparts.debian.org/tmp --arch amd64 -b 
/srv/piuparts.debian.org/slave/basetgz/sid-merged-usr_amd64.tar.gz -d sid 
--no-upgrade-test --apt python3-scrapy=2.11.1-1
0m0.0s INFO: Running on: Linux piu-slave-ubc-01 5.10.0-28-amd64 #1 SMP Debian 
5.10.209-2 (2024-01-31) x86_64
0m0.0s DEBUG: Created temporary directory 
/srv/piuparts.debian.org/tmp/tmpq3za2o4e
0m0.0s DEBUG: Unpacking 
/srv/piuparts.debian.org/slave/basetgz/sid-merged-usr_amd64.tar.gz into 
/srv/piuparts.debian.org/tmp/tmpq3za2o4e
0m0.0s DEBUG: Starting command: ['tar', '-C', 
'/srv/piuparts.debian.org/tmp/tmpq3za2o4e', '--auto-compress', '-xf', 
'/srv/piuparts.debian.org/slave/basetgz/sid-merged-usr_amd64.tar.gz']
0m0.6s DEBUG: Command ok: ['tar', '-C', 

Bug#1065530: ghostscript b-d not needed

[Matthias Klose]

Package: src:gnupg2
Version: 2.4.4-2
Severity: important

while working on the time64 bootstraps, I noticed that the b-d on 
ghostscript is unneeded, at least the build succeeds without it.


Please can you check if it can be removed, or if you could make it 
conditional with a build profile?

Bug#1065529: interimap: Testsuite fails with openssl 3.2

[Sebastian Andrzej Siewior]

Package: interimap
Version: 0.5.7-2
Severity: important
Tags: sid
control: affects -1 src:openssl
User: pkg-openssl-de...@lists.alioth.debian.org
Usertags: openssl-3.2

interimap's testsuite fails with OpenSSL 3.2, which is currently in
experimental, for the tests:

SSL_CAfile/$SSL_CERT_FILE... FAILED
TLS servername extension (SNI)... FAILED

Full log at
https://ci.debian.net/packages/i/interimap/unstable/amd64/43404948/

I'm currently puzzled where to look at. Could you please have a look?

Sebastian

Bug#1065416: [Cross-toolchain-base-devs] Bug#1065416: linux-libc-dev claims to provide linux-libc-dev-ARCH-cross, but it doesn't do that completely

[Bastian Blank]

Hi Helmut

On Tue, Mar 05, 2024 at 09:50:27AM +0100, Helmut Grohne wrote:
> The problem arises in the reverse sense. If a file does not exist in
> one, it is searched in the second and erroneously may be found. That may
> make tests pass that should not pass and typically causes a link failure
> later.

But you want /usr/include to be found.  Otherwise you would not be able
to use most of the libraries for cross compiling.

>  . While I do not have a concrete example at hand, I have seen this
> pattern repeatedly and generally favour moving stuff out of /usr/include
> to avoid this kind of confusion that causes difficult to debug problems.
> This also motivates #798955 (in addition to the problem with file
> conflicts).

In this case here, this would just find kernel headers for a different
version.  Those are essentially a headers only library, nothing is
available for linking.  And all the headers provided in /usr/include are
the same for all architectures.

So moving stuff out of /usr/include might be a good idea if the -dev
package is itself arch dependent.

> The one case I really do remember quite well is sanitizers. These should
> not be enabled in the earlier toolchain stages and failing to disable
> them tends to cause linker failures. I don't think it matches the
> concrete situation exactly though. You also make a good case in your
> followup reporting that gcc-13-cross actually builds.

Yep.  My problem is: I tested stuff, not everything of course, and did
not see any breakage.  Also I checked the values I know could influence
that and they say it is fine.  So at some point I have to assume it is
not broken, as exhaustive search is simply not possible.

The only statement in this bug report is now: it is located in a
different location, so it is broken.  No single piece of evidence is
shown, like broken builds or some other ways to see the brokeness.

Regards,
Bastian

-- 
A princess should not be afraid -- not with a brave knight to protect her.
-- McCoy, "Shore Leave", stardate 3025.3

Bug#1057548: cloud-init: FTBFS: failing tests

[Ross Vandegrift]

Control: tags -1 pending

On Mon, Feb 19, 2024 at 01:47:24PM -0800, Ross Vandegrift wrote:
> On Tue, Dec 05, 2023 at 11:04:12PM +0100, Santiago Vila wrote:
> > During a rebuild of all packages in unstable, your package failed to build:
> 
> I started updating to the latest upstream release, which fixes this FTBFS.  
> But
> I'm reluctant to push to the team repo, due to an issue with the network
> nocloud datasource.
> 
> With a local webserver hosting cloud-init seed data, cloud-init 23.4.3 never
> hits my local http server.  The same setup with 23.3.1 from sid works fine.
> Disk based nocloud seeds work fine with 23.4.3.

Upstream found and fixed this issue in 23.4.4  But before I could get to
packaging it, they also released 24.1.  I just pushed updates with the new
version to salsa.  The new version is working for me.

I don't have upload access for cloud-init - we can work out an upload at the
team meeting next week.

Ross

Bug#1065528: connman adds extra routes, which breaks network connectivity after installing k3s

[Sayan Naskar]

Package: connman
Version: 1.41-3
Severity: important
X-Debbugs-Cc: nascarsa...@gmail.com

Dear Maintainer,

I have a VM on which I installed Debian + LXQT desktop.
connman daemon adds extra routes to the machine, which normally works fine.
However, when I install k3s, it adds extra routes to the routing table, which 
affects the connectivity to and from the VM.
Any IP outside the local network (network CIDR for the VM) is not pingable / 
reachable.
I reported the issue on k3s, but later on debugged the issue to root cause to 
connman.
The original issue with some ip routes, journalctl logs, etc. can be found at 
https://github.com/k3s-io/k3s/issues/9625

The issue gets resolved after stopping the systemd unit service and rebooting.

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

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

Versions of packages connman depends on:
ii  dbus   1.14.10-1~deb12u1
ii  init-system-helpers1.65.2
ii  iptables   1.8.9-2
ii  libc6  2.36-9+deb12u4
ii  libdbus-1-31.14.10-1~deb12u1
ii  libglib2.0-0   2.74.6-2
ii  libgnutls303.7.9-2+deb12u1
ii  libreadline8   8.2-1.3
ii  libxtables12   1.8.9-2
ii  sysvinit-utils [lsb-base]  3.06-4

Versions of packages connman recommends:
ii  bluez  5.66-1+deb12u1
ii  ofono  1.31-3+b1
ii  wpasupplicant  2:2.10-12

Versions of packages connman suggests:
pn  connman-vpn  

-- no debconf information

Bug#1063596: flint: FTBFS on amd64: test segfault

[Paul Gevers]

Hi Julien,

On Sat, 24 Feb 2024 14:40:13 +0100 julien.pu...@gmail.com wrote:

A case of eigenbug where you compile three times and it only fails one?


If it's one in three that would be too much. For ci.d.n I'm having my 
"flaky" bug filing threshold between 1/5 and 1/8, but I think it should 
be below something like 1/20 to say it's acceptable if it's caused by 
the package itself. If not caused by the package itself, but toolchain 
issues, those really should get a decent bug and get fixed.


Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1065527: ITP: python-hypothesmith -- Hypothesis strategies for generating Python programs, something like CSmith

[Yogeswaran Umasankar]

Package: wnpp
Severity: wishlist
Owner: Yogeswaran Umasankar 
X-Debbugs-Cc: debian-de...@lists.debian.org, kd8...@gmail.com

* Package name: python-hypothesmith
  Version : 0.3.3
  Upstream Contact: Zac Hatfield-Dodds 
* URL : https://github.com/Zac-HD/hypothesmith
* License : MPL-2.0
  Programming Lang: Python
  Description : Hypothesis strategies for generating Python programs, 
something like CSmith

This package provides two Hypothesis strategies for generating
 Python source code. The generated code will always be syntatically
 valid, and is useful for testing parsers, linters, auto-formatters,
 and other tools that operate on source code. This is depends for other
 Python packages. I am planning to maintain it under DPT, need
 sponsorship.

Bug#1065395: spirv-llvm-translator-14: autopkgtest on s390x uses huge amount of disk space

[Paul Gevers]

Hi Andreas,

On 05-03-2024 10:16 a.m., Andreas Beckmann wrote:
But first I'd like to see the s390x build happen and your confirmation 
that this unbreaks the CI infrastructure. But at least ppc64 and sparc64 
built with 500MB instead of 40GB now ;-)

Feel free to block 15-17 temporarily, too.


Unfortunately the test still takes upto 33 GB at least (see below).

Paul
By the way, I just noticed this in the -14 log (judging from the name of 
the test I think that's intentional, but just checking (installing from 
the -16 package instead of the -14 one):
Get:2 http://deb.debian.org/debian unstable/main s390x spirv-headers all 
1.6.1+1.3.275.0-1 [118 kB]



root@ci-worker-s390x-01:~# while true ; do df -h /scratch/ | grep mapper 
; sleep 10 ; done
/dev/mapper/3600507630affd250004a  196G   27G  160G  15% 
/scratch
/dev/mapper/3600507630affd250004a  196G   27G  160G  15% 
/scratch
/dev/mapper/3600507630affd250004a  196G   27G  160G  15% 
/scratch
/dev/mapper/3600507630affd250004a  196G   27G  160G  15% 
/scratch
/dev/mapper/3600507630affd250004a  196G   27G  160G  15% 
/scratch
/dev/mapper/3600507630affd250004a  196G   27G  160G  15% 
/scratch
/dev/mapper/3600507630affd250004a  196G   27G  160G  15% 
/scratch
/dev/mapper/3600507630affd250004a  196G   27G  159G  15% 
/scratch
/dev/mapper/3600507630affd250004a  196G   28G  159G  15% 
/scratch
/dev/mapper/3600507630affd250004a  196G   28G  159G  15% 
/scratch
/dev/mapper/3600507630affd250004a  196G   28G  159G  15% 
/scratch
/dev/mapper/3600507630affd250004a  196G   28G  159G  15% 
/scratch
/dev/mapper/3600507630affd250004a  196G   29G  158G  16% 
/scratch
/dev/mapper/3600507630affd250004a  196G   29G  158G  16% 
/scratch
/dev/mapper/3600507630affd250004a  196G   29G  158G  16% 
/scratch
/dev/mapper/3600507630affd250004a  196G   29G  158G  16% 
/scratch
/dev/mapper/3600507630affd250004a  196G   29G  157G  16% 
/scratch
/dev/mapper/3600507630affd250004a  196G   29G  157G  16% 
/scratch
/dev/mapper/3600507630affd250004a  196G   30G  157G  16% 
/scratch
/dev/mapper/3600507630affd250004a  196G   30G  157G  16% 
/scratch
/dev/mapper/3600507630affd250004a  196G   28G  159G  15% 
/scratch
/dev/mapper/3600507630affd250004a  196G   28G  159G  15% 
/scratch
/dev/mapper/3600507630affd250004a  196G   28G  159G  15% 
/scratch
/dev/mapper/3600507630affd250004a  196G   28G  159G  15% 
/scratch
/dev/mapper/3600507630affd250004a  196G   29G  158G  16% 
/scratch
/dev/mapper/3600507630affd250004a  196G   34G  153G  19% 
/scratch
/dev/mapper/3600507630affd250004a  196G   44G  143G  24% 
/scratch
/dev/mapper/3600507630affd250004a  196G   53G  133G  29% 
/scratch
/dev/mapper/3600507630affd250004a  196G   62G  124G  34% 
/scratch
/dev/mapper/3600507630affd250004a  196G   70G  117G  38% 
/scratch
/dev/mapper/3600507630affd250004a  196G   28G  159G  15% 
/scratch
/dev/mapper/3600507630affd250004a  196G   28G  159G  15% 
/scratch
/dev/mapper/3600507630affd250004a  196G   28G  159G  15% 
/scratch
/dev/mapper/3600507630affd250004a  196G   29G  158G  16% 
/scratch
/dev/mapper/3600507630affd250004a  196G   27G  160G  15% 
/scratch
/dev/mapper/3600507630affd250004a  196G   27G  160G  15% 
/scratch
/dev/mapper/3600507630affd250004a  196G   27G  160G  15% 
/scratch
/dev/mapper/3600507630affd250004a  196G   27G  160G  15% 
/scratch
/dev/mapper/3600507630affd250004a  196G   27G  160G  15% 
/scratch


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1065526: knockpy: knock/knockpy.py: SyntaxWarning: invalid escape sequence

[Paul Wise]

Package: knockpy
Version: 7.0.0-1
Severity: normal
Usertags: warnings
User: debian-pyt...@lists.debian.org
Usertags: python3.12

Upgrading knockpy gives syntax warnings, probably due to Python 3.12:

   Preparing to unpack .../knockpy_7.0.0-1_all.deb ...
   Unpacking knockpy (7.0.0-1) over (6.1.0-1) ...
   Setting up knockpy (7.0.0-1) ...
   /usr/lib/python3/dist-packages/knock/knockpy.py:118: SyntaxWarning: invalid 
escape sequence '\/'
 pattern = "http(s)?:\/\/(.*\.%s)" % self.domain
   /usr/lib/python3/dist-packages/knock/knockpy.py:121: SyntaxWarning: invalid 
escape sequence '\.'
 if match and re.match("^[a-zA-Z0-9-\.]*$", match.groups()[1]):
   Processing triggers for man-db (2.12.0-3) ...

-- System Information:
Debian Release: trixie/sid
  APT prefers testing-debug
  APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 
'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 
'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental')
Architecture: amd64 (x86_64)

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

Versions of packages knockpy depends on:
ii  python33.11.6-1
ii  python3-bs44.12.3-1
ii  python3-dnspython  2.6.1-1
ii  python3-openssl23.2.0-1
ii  python3-requests   2.31.0+dfsg-1
ii  python3-tqdm   4.64.1-2

knockpy recommends no packages.

knockpy suggests no packages.

-- no debconf information

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#1065525: nut-server: Build with libsystemd to notify to systemd

[TSUCHIDA Fumiyasu]

Package: nut-server
Version: 2.8.1-3.1

Debian nut-server package does not have fully systemd support,
thus upsd(8) output the following message when starting from systemd:

```
Mar 03 20:04:33 hostname nut-server[1648]:0.009268upsnotify: failed 
to notify about state 2: no notification tech defined, will not spam more about 
it
```

Please add `Build-Depends: libsystemd-dev [linux-any]` to the `debian/control`
and add the following snipet to the `debian/rules`.

```
ifeq ($(DEB_HOST_ARCH_OS), linux)
  DEB_CONFIGURE_EXTRA_FLAGS+=--with-libsystemd
else
  DEB_CONFIGURE_EXTRA_FLAGS+=--without-libsystemd
endif
```

-- 
-- Name: SATOH Fumiyasu @ OSSTech Corp., Japan (fumiyas @ osstech co jp)
-- Business Home: https://www.OSSTech.co.jp/
-- GitHub Home: https://GitHub.com/fumiyas/
-- PGP Fingerprint: EE58 9CE7 A512 E5D8 1DAD  5627 6709 E8A8 C7DD 5305

Bug#1065524: reportbug-gtk: Inform user that they may need to join mailing list if requesting help

[Neal]

Package: reportbug-gtk
Version: 13.0.1
Severity: normal
X-Debbugs-Cc: tombrown9...@gmail.com

Dear Maintainer,

The second page of the app contains this message: "If you don't know what
package the bug is in, please contact debian-u...@lists.debian.org for
assistance." The people requiring help are also unlikely to realize that they
need to be subscribed to the mailing list to get an answer. For example me.
There really needs to be a link to the mailing list subscribe page. For example
you could change the sentence to:

"If you don't know what package the bug is in, please subscribe to the debian-
user mailing list here(hyperlink) and email debian-u...@lists.debian.org for
assistance. You should hear a response within a few days"

Thanks!


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

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

Versions of packages reportbug-gtk depends on:
ii  gir1.2-gtk-3.0 3.24.41-1
ii  gir1.2-gtksource-4 4.8.4-5+b1
ii  gir1.2-vte-2.910.75.91-2
ii  python3-gi 3.47.0-3
ii  python3-gi-cairo   3.47.0-3
ii  python3-gtkspellcheck  5.0.3-1
ii  reportbug  13.0.1

reportbug-gtk recommends no packages.

reportbug-gtk suggests no packages.

-- no debconf information

Bug#1057549: crowdsec: FTBFS: FAIL: TestOneShot/permission_denied

[Cyril Brulebois]

Cyril Brulebois  (2024-02-15):
> Is that problem still current? I cannot reproduce it with a brand new
> sid environment, freshly created via either `pbuilder --create` or
> `sbuild-createchroot`.

For the record, I did receive a proposal to get access to such a system
back then (thanks!), but I couldn't get to it just yet.

Not sure about this though, received today (2024-03-06) for 3 packages:

crowdsec 1.4.6-6 is marked for autoremoval from testing on 2024-03-05 


Cheers,
-- 
Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/


signature.asc
Description: PGP signature

Bug#1065523: kinfocenter: About this System page displays incorrect info

[Neal]

Package: kinfocenter
Version: 4:5.27.10-1
Severity: normal
X-Debbugs-Cc: nealheine...@gmail.com

Dear Maintainer,

The About this System page in System Settings shows that I am running Debian
GNU/Linux 12 when I am running Debian Testing.

Thanks!


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

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

Versions of packages kinfocenter depends on:
ii  kio   5.107.0-1+b1
ii  kpackagetool5 5.107.0-1+b1
ii  libc6 2.37-15
ii  libkf5authcore5   5.107.0-1+b1
ii  libkf5configcore5 5.107.0-1+b1
ii  libkf5configwidgets5  5.107.0-2+b1
ii  libkf5coreaddons5 5.107.0-1+b1
ii  libkf5i18n5   5.107.0-1+b1
ii  libkf5kiocore55.107.0-1+b1
ii  libkf5kiogui5 5.107.0-1+b1
ii  libkf5kiowidgets5 5.107.0-1+b1
ii  libkf5package55.107.0-1+b1
ii  libkf5quickaddons55.107.0-1+b1
ii  libkf5service-bin 5.107.0-1+b1
ii  libkf5service55.107.0-1+b1
ii  libkf5solid5  5.107.0-1+b1
ii  libkf5widgetsaddons5  5.107.0-1+b1
ii  libqt5core5a  5.15.10+dfsg-7
ii  libqt5dbus5   5.15.10+dfsg-7
ii  libqt5gui55.15.10+dfsg-7
ii  libqt5qml55.15.10+dfsg-2+b1
ii  libqt5widgets55.15.10+dfsg-7
ii  libstdc++614-20240201-3
ii  libusb-1.0-0  2:1.0.27-1
ii  plasma-workspace  4:5.27.10-3
ii  qml-module-org-kde-kirigami2  5.107.0-1+b1
ii  systemsettings4:5.27.10-1
ii  usb.ids   2024.01.30-1

Versions of packages kinfocenter recommends:
ii  aha0.5.1-3
ii  dmidecode  3.5-3
ii  pciutils   1:3.10.0-2+b1

Versions of packages kinfocenter suggests:
pn  samba 
pn  vulkan-tools  

-- no debconf information

Bug#1053004: CVE-2019-10784 and CVE-2023-40619

[Leandro Cunha]

Hi,

On Sat, Nov 11, 2023 at 2:53 PM Leandro Cunha  wrote:
>
> Hi,
>
> According to a survey carried out, it was found that the OpenSUSE
> people resolved these CVEs and started distributing the fork
> https://github.com/ReimuHakurei/phpPgAdmin. According to the links
> below:
> https://lists.opensuse.org/archives/list/security-annou...@lists.opensuse.org/message/4YEBNCIRQOKETS4R7J5GXRP3TKF2YKFJ/
> https://build.opensuse.org/request/show/1123216
>
> I'm working on doing the same for Debian, currently testing and
> reviewing the package. At the same time, the libphp-adodb package will
> receive an NMU to be compatible with PHP 8.2 according to the website
> https://adodb.org/dokuwiki/doku.php?id=v5:php_compatibility_status and
> https://bugs.debian.org/ cgi-bin/bugreport.cgi?bug=1053525.
>
> --
> Cheers,
> Leandro Cunha

Just to add that in addition to OpenSUSE Tumbleweed and Leap
15.5/15.6, we have FreeBSD, AUR and Gentoo currently distributing this
package from the same source as can be seen in the links below. The
next job would be to make it available through backports and I would
choose to remove this package from stable. But I would only leave
bookworm backports due to other bugs found (this CVEs too) and fixed
in 7.14.7.
I have to search about the status of backports to oldstable. But I'm
also studying the possibility of working with patches for these two
versions.

[1] https://repology.org/project/phppgadmin/versions
[2] https://software.opensuse.org/package/phpPgAdmin
[3] https://build.opensuse.org/package/show/home%3Aecsos%3Aserver/phpPgAdmin
[4] https://build.opensuse.org/package/show/openSUSE%3AFactory/phpPgAdmin
[5] https://www.freshports.org/databases/phppgadmin
[6] https://packages.gentoo.org/packages/dev-db/phppgadmin

-- 
Cheers,
Leandro Cunha
-BEGIN PGP PUBLIC KEY BLOCK-

mQINBF/gQ8gBEADHVKgoWsUWNGVvR6sMhBPUdBUEH+QALpr1QYXhetBfRwaY0HWN
pKgejHdxKO8H+kIhRMoh89CCKg3hAJ9LmOOTXkX7U5/Cya/zRMKk5zBD3rKIaugh
0XYT15Nz1jwL7TIDG25yPSloDtVgVXTep0ZzKsNYJjb4OAqa88cvUEJEhhqrldlR
gpNbkixEh5ituO8pMShEBWqLs3yt4Hr1VFWnTIm4dl/JLBHpexzubDOw/mKCTpNd
A1JGHTvce1wtJ2fMzCVzhEjd5pyjLZV/o8hVw2/ON/yXvpJuz0lV/hiW0M+cDcas
sKftErtsZpRy3wwXdkBcJt6soYuqfCHwgMfL2iC6mPviE8xWAHMOmhdC3wDskZpb
RcLfH5IMYajJAGRO/GCMcKKbq7WkEOeloivtg64xBlYuJf9aOcHKP/8R3EObiNp7
ubQAJtV3pEGD4mx1mhutFxDHB+CfnxE3dWvxZSV9y1n4UOzkDJ3kDx5Ee0MbRvJD
w6aXKc6dhYREgh7hLDcMFz+3LcBiZDLxI3g+SHe3Bl61vdsnPno+0HhCzvB+fL4S
eoy7Myfiunz9BrB2HPN+wNCT0YgV+Kv8QoDGzBwos5H1vUJSY4t59w6xoXAYUsAm
hjAM8s+rUtG40mcUWePd8kZtgE9IV1eQ+Qt8/SNpSdRnUunmIGl3JjHvEwARAQAB
tClMZWFuZHJvIEN1bmhhIDxsZWFuZHJvY3VuaGEwMTZAZ21haWwuY29tPokCTgQT
AQoAOBYhBLT5oBCvKN3HzFEPK8LZ4zKUW9A8BQJf4EPIAhsDBQsJCAcCBhUKCQgL
AgQWAgMBAh4BAheAAAoJEMLZ4zKUW9A8FjAQAKWYqiLpLUD+DLB+NSy3DI3rf9z3
k0vE7TLaEjdEM5CQWN+j4vBqMnAckdcARvSWPndTjp8K+mtFF4PyfhNbS64z/a7L
F3DdhmX73n7LKFG8Ow9NZwcrkmPwH5WcP7mXTh6R+6/+OSL/K85NB8MLlxQTJOni
julVax9JEZjwBaP2HLCu53Zq9gZcvJlXoAoTHyTxKdp8Mh8V+Qit26E78o9c6SQD
Dq9eyMRG8hYCRfreDjKceRkYHjECySlk+VoI1ssVs07Dqvxg6qSyP4RnW+1+W74C
s0yIyuC/eRJpMAf1PBQEOOrVcTfRfpN+go955t21yIAvT58vqotTM5eaqXYIQn/y
sC4lThZai/ZBZHxl5Mbv42WkkYdjisLQOCALIMBpj5nq4oh2C+kvMupcuBKfERgV
dguU51MzfQktKb6d5y777zYnDaFMQDD2IfiD/C7ln5A9LP/L54ixlA3uRmWx/yAx
/m+Zusws98j4Eq/jw5T54XW655m6lMCTE9WXLJkgxrRcEonHSllbgRSsToEmWq0Z
doxcnpagHdcGQzW+cu2VOGi1da73ZFmrn+ptJgc8cW2suO06IeArOi0TzIg7e65j
Xp2DbJCpFrfzEuBb1u71WvB8V2MkAfJZx/uZJPCA936B4HT8YGPEMzlQRIHI2Y9C
+DloyzlBLTS1EMKuuQINBF/gQ8gBEAC47o9u1Wm9jZ6RC+lfxEDEvVS7MmI5VzSy
q04rFttWwbKix13pc65aDlk47LxWrb84N3Gnf1E/OTsLTXqC7u5JZ7YJkC6CsPbo
D1sQkfCiJCFCTgf7dydEVt8ujS/Uu1kz86ufdRwaMRcvBZAORGdB58LEsLB65WN4
hLRYF7xvcxu6t7FGrIYereaxUAWLA2B/ZnCEdOY94w7s0uaPjHdf4lfHebuZ7T08
iG5ACDvKBjgaFArGfdNYWchXJgbOEg14bGj40/8LuBKQMZASiFSqLPZxoporK9FY
xBw+D080dUWWD5g868TZ3pkM3DXO9bdq22IBKqKOep8CnuKgoDpUvA8dTEY/UDCn
sdOlBUK/Y9zTGVmD/90cO/xkvkV78suqiBnwBSddPzVS0EuiWwrLGu8gaY4EyM/X
7khlbTcMgh4njzUCAE6Tq+TbXSxn86wuOybVY5Y+I99LNdsocI5SIn2nDh2IOi00
4dE/iwO2MatWIOLFBC7pw8Xv4UHZY+WIf3Y/6XjExpllhUkeB6BwZpTr1SXk+cug
q5Dj5i4aGn2LrvQJ57terqUWYyDUBFgXTc4SPOzT5og8CavBgHfrQoFwSnRZ2oyX
xtZhEDI5Pk2j1qTbOhXZ29po4rPNWHMq2HQgM0I+BqQndsoVdkPOFzS2wKkdXjCz
bNYcyanusQARAQABiQI2BBgBCgAgFiEEtPmgEK8o3cfMUQ8rwtnjMpRb0DwFAl/g
Q8gCGwwACgkQwtnjMpRb0Dzh6g//ZjXaWSzKmG5ZS6XJa/ZOokkE2hFOFusWX8Qa
hEwLAnTFEy02dLfV54rKwmu2jHPDKLhE+iYtusvytueZAzVRyQahv0RE4BH8Emqw
gQdBwyJ/L+QhUp/lMdJ6Hh/2ZSZmzU29U24vnY+U+haoB1fLnA3lXgOP59kMLGud
lERR2Vluuc7TcpzvcaRWgrQRU2vSrrBBEp6y07iVKbRM/9yhE/aHJahLbhKh2Dk9
WJvHPnhYJY5yU+Y5vTl3BiW5+EuzMBdPUawOWKhqCq9dswn0GL1g/vlt/bdU/6DO
jECQ6fssTAtDjRClXySsS3X0mh8y8qlGvMPB4anfvOy4+4nUV6IESdJftKn2SMGd
CA3MaQ+S7frWn5v7GIWSC9vumCsiu1JTOugLmbVmu5m5nFsyllavm/k9LtOtswuF
fHM/SlXLFuGBWU6XceqaM2dpP8i5jGz0vIGMhqoFNgXWGO1NhwR1rmeU1CMpnM5e
Wue4h/+mJiuEzuZcmzOcwq3HGMUXO0jZDgLEmlnenO9czhrLuGZaMXGdwnIk0G3O
+SqH36v7blnDh96RXpgaa+ifTHd0qKeoVXVwSq/9jNtHSQrI+NJcTpMhu73xtxhX
UFPr/31+IFLWepC5GDwdu/gQm5E6ntGyxE2p2v76pcjz7SGdXjPFZjqekBveEJuW
fNdY6Ns=
=rdCA
-END PGP PUBLIC KEY BLOCK-

Bug#1064852: incus: missing depends on iproute2

[Mathias Gibbens]

On Tue, 2024-03-05 at 14:19 +0100, Helmut Grohne wrote:
> debvm-create --include=incus
> # This should have created a file named rootfs.ext4.
> debvm-run

  Thanks for sharing that!

> Rather than adding debvm on top of your testing, I think adding
> autopkgtests with isolation-machine should get you more automatic
> coverage. Possibly such tests need to be explicitly allowed by debci
> folks and currently are only available on amd64.

  Yes, it would be nice to get better autopkgtest coverage for incus,
lxc, and lxcfs. I'll add it to my todo list for these packages. :)

Mathias


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

Bug#1059083: golang-github-azure-azure-sdk-for-go: package outdated, upstream now versions components independently

[Maytham Alsudany]

Hi Daniel,

On 29/02/2024 8:43 pm, Daniel Swarbrick wrote:

Hi Maytham,

On 29.02.24 12:16, Maytham Alsudany wrote:
Could we avoid bumping the epoch by suffixing the version with the 
git commit? e.g. for the case of azure-sdk-for-go, the next version 
would be 68.0.0+git20240229.d33ad0-1s


I did this kind of thing previously for 
golang-github-azure-go-autorest (14.2.0+git20220726.711dde1-1) since 
it was in the same situation. However, it has a bad smell IMHO, as 
there is little useful difference between 68.0.0+git20240229.d33ad0-1 
and 0.0~git20240229.d33ad0-1. It completely throws semantic versioning 
out the window.


Since the azure-go-autorest upstream seems to have more or less 
resumed vX.Y.Z tagging (albeit lower version numbers than before - 
most recent tag is "autorest/v0.11.29"), I would be more inclined to 
bump the epoch and make the Debian version number e.g. 1:0.11.29-1
They're trying to version the tracing, logging, and autorest components 
independently, but with the main functionality is the autorest 
submodule, so it makes sense to version using that tag.
All that remains is to determine which series of tags in 
azure-sdk-for-go is the "main" version number - and my gut feeling is 
that it's the "sdk/azcore/vX.Y.Z" series.


Probably azcore, since all the other modules depend on it AFAICS.

I still think it's better to use commits for versioning, since the 
modules are versioned independently and versions of submodules are 
released after azcore, meaning package maintainers need to either wait 
for the next azcore version, or prepare a orig tarball and add a +1 to 
the version.


Putting another idea out there: why don't we do what the JS team does 
(when vendoring packages), and just add all the submodule version 
numbers together?


Have you checked what other distros are doing, assuming that they 
package that project?


Other distros either don't package the project, or have v68.0.0.
https://repology.org/project/go:github-azure-azure-sdk-for-go/packages

Kind regards,
Maytham

Bug#900742: iw $dev scan

[Russell Coker]

To save everyone the trouble of looking the replacement command is
"iw $dev scan".

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

Bug#1065522: android-platform-external-nist-sip: FTBFS with default Java 21

[Vladimir Petko]

Source: android-platform-external-nist-sip
Version: 9.0.0+r35-1.1
Severity: important
Tags: ftbfs
User: debian-j...@lists.debian.org
Usertags: default-java21

Dear Maintainers,

The package android-platform-external-nist-sip ftbfs with default Java 21.
The relevant part of the build log:
---
./java/gov/nist/javax/sip/header/ims/PMediaAuthorizationList.java:41: error: 
removeLast() in SIPHeaderList cannot implement removeLast() in List
public class PMediaAuthorizationList extends SIPHeaderList 
{
   ^
  return type void is not compatible with PMediaAuthorization
  where E is a type-variable:
E extends Object declared in interface List
--
see [1]

[1] 
https://launchpadlibrarian.net/715414670/buildlog_ubuntu-noble-amd64.android-platform-external-nist-sip_9.0.0+r35-1.1_BUILDING.txt.gz


-- System Information:
Debian Release: trixie/sid
  APT prefers mantic-updates
  APT policy: (500, 'mantic-updates'), (500, 'mantic-security'), (500, 
'mantic'), (100, 'mantic-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.5.0-21-generic (SMP w/32 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#1065497: Please allow php-psr-log 3

[Sunil Mohan Adapa]

Control: tags -1 patch

On Tue, 5 Mar 2024 14:48:49 +0100 David =?iso-8859-1?Q?Pr=E9vot?= 
 wrote:

Package: php-klogger
Version: 1.2.2-2
Severity: important

Hi James, Sunil,

AFAICT, php-klogger is the only blocker preventing php-psr-log 3 upload
to unstable. php-psr-log 3 is available in experimental since 2021, and
recent php-psr-log will be needed for the php-monolog 3 transition.

Please, test your package with php-psr-log 3 and relax the versioned
dependency if you manage to make your package work with any php-psr-log
version, or upload to experimental a fix to make your packages work with
php-psr-log 3 (so we can easily upload it to unstable in sync with
php-psr-log 3).



I have patch available for making php-klogger depend on php-psr-log >= 3.0.

https://salsa.debian.org/php-team/pear/php-klogger/-/merge_requests/4

However, it does not work with php-psr-log 1.x anymore. So I don't know 
how the two packages can be uploaded together.


Thank you for bug report.

--
Sunil


OpenPGP_0x36C361440C9BC971.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#849712: motion: Motion starts but immediately exits when run as a daemon using systemd

[Sudip Mukherjee]

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

Marking this bug as important as the package is mostly unusable by a 
non-technical user.
The motion.service can only start if the user manually creates /var/log/motion 
folder.

Patch attached to fix this. The suggested change was already part of the
motion init script but was dropped when updating it to systemd service.
The old code can be seen at: 
https://sources.debian.org/src/motion/4.1.1-1.1/debian/motion.init/#L60

-- 
Regards
Sudip
diff -Nru motion-4.6.0/debian/changelog motion-4.6.0/debian/changelog
--- motion-4.6.0/debian/changelog   2023-11-12 19:17:59.0 +
+++ motion-4.6.0/debian/changelog   2024-03-05 22:24:01.0 +
@@ -1,3 +1,10 @@
+motion (4.6.0-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Create log folder if it does not exist. (Closes: #849712)
+
+ -- Sudip Mukherjee   Tue, 05 Mar 2024 22:24:01 
+
+
 motion (4.6.0-1) unstable; urgency=medium
 
   * New upstream release
diff -Nru motion-4.6.0/debian/motion.postinst 
motion-4.6.0/debian/motion.postinst
--- motion-4.6.0/debian/motion.postinst 2023-02-03 12:28:41.0 +
+++ motion-4.6.0/debian/motion.postinst 2024-03-05 22:24:01.0 +
@@ -24,8 +24,16 @@
 fi
 }
 
+add_log_if_missing() {
+if ! [ -d /var/log/motion ]; then
+ mkdir -m 02750 /var/log/motion
+ chown motion:adm /var/log/motion
+fi
+}
+
 add_group_if_missing
 add_user_if_missing
+add_log_if_missing
 
 db_stop
 

Bug#965333: libvirt-daemon-system: Please make a separate package for apparmor profiles

[Andrea Bolognani]

On Sun, Jul 19, 2020 at 08:08:15PM +0200, Mikhail Morfikov wrote:
> Dear Maintainer,
> 
> Currently when the package is installed, it also installs files under
> /etc/apparmor.d/ . There are two issues with this:
> 
> 1) some people want to use their own profile (the local profile under
> /etc/apparmor.d/local/ may not be an option for many reasons),
> 2) some of the names of the files are path based, and some users could use 
> just
> the exec/binary name (or whatever) for the profile/file name, which leads to
> having two different sets of rules (two different apparmor profiles loaded at
> the same time confining the same app).
> 
> The only way to fix this is to manually remove the provided apparmor profile
> files after each package update, which is a little bit annoying.
> 
> Please reconsider creating a separate package for the apparmor profile files
> (something similar to package_name-apparmor-profile), and just
> suggest/recommend it in deps of the main package, so the user could decide
> whether he wants the profiles to be installed in his system or not.

Hi Mikhail,

I am currently working on a big refactoring of the libvirt package,
which I thought could be the perfect opportunity to implement the
split that you're suggesting here.

However, looking at the contents of the archive, it seems that the
practice of shipping AppArmor profiles as separate package from the
software that they're intended for is far from widespread:

  $ apt-cache search -n apparmor
  apparmor - user-space parser utility for AppArmor
  apparmor-notify - AppArmor notification system
  apparmor-profiles - experimental profiles for AppArmor security policies
  apparmor-utils - utilities for controlling AppArmor
  dh-apparmor - AppArmor debhelper routines
  libapache2-mod-apparmor - changehat AppArmor library as an Apache module
  libapparmor-dev - AppArmor development libraries and header files
  libapparmor1 - changehat AppArmor library
  libpam-apparmor - changehat AppArmor library as a PAM module
  python3-apparmor - AppArmor Python3 utility library
  python3-libapparmor - AppArmor library Python3 bindings
  apparmor-profiles-extra - Extra profiles for AppArmor Security policies
  fwknop-apparmor-profile - FireWall KNock OPerator - Apparmor profile
  uwsgi-plugin-apparmor - apparmor plugin for uwsgi

If we exclude apparmor-profiles(-extra), which by definition don't
count as they are maintained separately from the corresponding
applications, the only example I can see is fwknop.

This gives me pause, and makes me not particularly keen on going down
such a lonesome path.

I'd like to understand your use case better though. Can you please
provide concrete examples of the problematic scenarios you've
mentioned in your original message, along with the steps that you
currently have to perform to work around them?

Thanks in advance!

-- 
Andrea Bolognani 
Resistance is futile, you will be garbage collected.


signature.asc
Description: PGP signature

Bug#1029675: faked daemon exits on SIGWINCH signal

[Anton Hvornum]

Most workarounds to the issue stipulates adding a docker workaround:
--ulimit nofile=1024:524288

This only works in some instances, and this might be obvious to others..
But if running for instance makepkg[1] inside a docker container the
issue will remain. Unless makepkg specifically was executed with ulimit.


For instance (in the docker image):
ulimit -n 1024 && makepkg -s

Otherwise the ulimit on docker itself has little to no effect.

[1] 
https://gitlab.archlinux.org/pacman/pacman/-/blob/e3dc296ba35d5039775c6e53decc7296b3bce396/scripts/makepkg.sh.in#L185-188

Bug#1064617: Passwords should not be changed frequently

[Justin B Rye]

Philip Hands wrote:
> Justin B Rye  writes:
>> It needs a small amount of rephrasing, but the most important problem
>> is that it starts by saying you need to set a password and then goes
>> on to suggest that you might not need to set a password.  Maybe that
>> can be fixed by rearranging things slightly...
>>
>>  Template: passwd/root-password
>>  Type: password
>>  # :sl1:
>>  _Description: Root password/passphrase:
>>   To allow direct password/passphrase-based access to the 'root'
>>   (system administrative) account you can set it up here.
>>   The results can be disastrous if a malicious or incompetent user
>>   obtains root access, so you should not set one that can be guessed,
>>   found in dictionaries, or easily associated with you.
>>   .
>>   Alternatively, you can lock root's password
>>   by leaving this setting empty, and
>>   instead use the system's initial user account
>>   (which will be set up in the next step)
>>   to become root. This will be enabled for you
>>   by adding that user to the 'sudo' group.
>>   .
>>   Note: what you type here will be hidden (unless you select to show it).
>>
>> Does this still feel like the same advice?
> 
> The reason behind that structure was supposed to be that one definitely
> needs _a_ password, but not necessarily a root password, so the password
> advice applies to whichever password you'll decide to grant root access
> to, which might not be set here.

This template is specifically about the "Root password/passphrase";
probably I should have quoted the patch I was looking at, which starts
with "One needs a password/passphrase that grants access to the 'root'
(system administrative) account" but goes on to say "Alternatively,
you can lock root's password by leaving this setting empty".

> I'm OK with the way you've phrased it, although my personal preference
> would be to simply drop the "disastrous" sentence if we use this
> version, because I think it breaks the straightforward flow of the text
> laying out the choice we're trying to get the user to make between the
> two available options. (I also rather doubt that anything we say at this
> point in the install will have the slightest influence on people's
> choice of password).

I can imagine people might be more likely to heed something shorter;
maybe it could be boiled down to

To allow direct password/passphrase-based access to the 'root'
(system administrative) account you can set it up here.
To protect your system you should not use one that can be guessed.

-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package

Bug#1065521: thunderbird timezone selector map highlights are wrong

[Daniel Kahn Gillmor]

Package: thunderbird
Version: 1:115.7.0-1

When i select a timezone in the dropdown list for Thunderbird, i expect
changing the timezone indicator to change the highlighted part of the
world map.

In practice, this doesn't happen.

Attached is a screenshot showing a region of the Pacific Ocean
highlighted while the selected TZ is America/Denver.

You can get this dialog box to pop up by going to calendar view,
editing a calendar entry, and clicking on the timezone for the start or
end of the event time.

--dkg



signature.asc
Description: PGP signature

Bug#1064617: Passwords should not be changed frequently

[Philip Hands]

Justin B Rye  writes:

> Holger Wansing wrote:
>> @d-l10n-english: hey guys, we would like to get a proposal reviewed, 
>> which aims to improve the root/user password screens in the installer.
>> 
>> Please find the related merge request at
>> 
>
> It needs a small amount of rephrasing, but the most important problem
> is that it starts by saying you need to set a password and then goes
> on to suggest that you might not need to set a password.  Maybe that
> can be fixed by rearranging things slightly...
>
>  Template: passwd/root-password
>  Type: password
>  # :sl1:
>  _Description: Root password/passphrase:
>   To allow direct password/passphrase-based access to the 'root'
>   (system administrative) account you can set it up here.
>   The results can be disastrous if a malicious or incompetent user
>   obtains root access, so you should not set one that can be guessed,
>   found in dictionaries, or easily associated with you.
>   .
>   Alternatively, you can lock root's password
>   by leaving this setting empty, and
>   instead use the system's initial user account
>   (which will be set up in the next step)
>   to become root. This will be enabled for you
>   by adding that user to the 'sudo' group.
>   .
>   Note: what you type here will be hidden (unless you select to show it).
>
> Does this still feel like the same advice?

The reason behind that structure was supposed to be that one definitely
needs _a_ password, but not necessarily a root password, so the password
advice applies to whichever password you'll decide to grant root access
to, which might not be set here.

I'm OK with the way you've phrased it, although my personal preference
would be to simply drop the "disastrous" sentence if we use this
version, because I think it breaks the straightforward flow of the text
laying out the choice we're trying to get the user to make between the
two available options. (I also rather doubt that anything we say at this
point in the install will have the slightest influence on people's
choice of password).

> Otherwise the only thing I see is:
>
>  Template: passwd/user-password
>  Type: password
>  # :sl1:
>  _Description: Choose a password/passphrase for the new user:
>   Make sure to select a strong password/passphrase, that cannot be guessed.
>
> No comma needed there.

Well done -- I kept noticing that, and somehow didn't get round to
fixing it. I've now deleted it, so thanks for pointing it out again. :-)

Cheers, Phil.
-- 
Philip Hands -- https://hands.com/~phil


signature.asc
Description: PGP signature

Bug#1063484: libuv1: CVE-2024-24806

[Salvatore Bonaccorso]

Hi Dominique,

On Sun, Mar 03, 2024 at 03:51:28PM +0100, Dominique Dumont wrote:
> On Thu, 29 Feb 2024 21:53:07 +0100 Salvatore Bonaccorso  
> wrote:
> > libuv1 is as well affected in bullseye and it's still supported. Can
> > you have a look as well at this version? 
> 
> The same patch (with a refresh) applies to bullseye. I can also prepare an 
> upload.

The debdiff for bookworm-security looks good to me. Please do upload
to security-master (and make sure to build with -sa as the orig
tarball is not yet on security-master for 1.44.2).

So we just need as well the bullseye-security one, as per above, can
you prepare this one as well.

Regards,
Salvatore

Bug#1065520: python3-nitime: package install Waring

[Greg Schmidt]

Package: python3-nitime
Version: 0.10.2-2
Severity: minor
X-Debbugs-Cc: g...@gwschmidt.com

Dear Maintainer,

syntax error found in doc string of 
usr/lib/python3/dist-packages/nitime/algorithms/event_related.py

Preparing to unpack .../8-python3-nitime_0.10.2-2_all.deb ...
Unpacking python3-nitime (0.10.2-2) over (0.10.2-1) ...
Setting up python3-nitime (0.10.2-2) ...
>>> /usr/lib/python3/dist-packages/nitime/algorithms/event_related.py:13: 
>>> SyntaxWarning: invalid escape sequence '\h'



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

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

Versions of packages python3-nitime depends on:
ii  python3 3.11.6-1
ii  python3-matplotlib  3.6.3-1+b2
ii  python3-numpy   1:1.24.2-2
ii  python3-scipy   1.11.4-6

Versions of packages python3-nitime recommends:
ii  python3-networkx  2.8.8-1
ii  python3-nibabel   5.2.1-1

python3-nitime suggests no packages.

-- no debconf information

Bug#1064824: node-d3: fails to export map and other functions

[Julian Gilbey]

On Tue, Mar 05, 2024 at 05:39:00PM +0530, Nilesh Patra wrote:
> On Mon, Mar 04, 2024 at 09:18:01PM +, Julian Gilbey wrote:
> [...]
> > (!) Conflicting re-exports
> > "index.js" re-exports "map" from both 
> > "../../../usr/share/nodejs/d3-array/src/index.js" and 
> > "../../../usr/share/nodejs/d3-collection/src/index.js" (will be ignored).
> > created dist/d3.min.js in 4.2s
> > -
> 
> I have pushed a commit to salsa that hopefully fixes this - can you please 
> try with the same and see if that
> helps you somewhat?

That's perfect, thanks!  And such a simple solution :-) (Though I
don't pretend to understand how the patch works!)  The taskflow
webserver now works exactly as intended (as far as I can tell).

> > So it's specifically "map" that is problematic, and I just happen to
> > have stumbled upon it: d3 v5 depends on d3-array version 1, but the
> > version of node-d3-array in unstable is 3.2.0+~cs5.0.6-2, and this is
> > causing the conflict.
> > 
> > I don't know the best way to fix this.  node-d3-array version was
> > upgraded from 1.2.4 to 3.x about two years ago, so d3 would have had
> > this bug since then, but I'm the first one to stumble upon it :-/
> >
> > Perhaps we could package node-d3-array-1 (version 1.2.4) and have
> > node-d3 build-depends on that?
> 
> I tried to embed it and realised it is creating an unholy mess. I got it 
> working eventually
> but it can open a can of worms sometime later. Maybe packaging the older 
> version
> would be the way to go if my fix above does not work.
> 
> I've added yadd to the thread for more qualified advice.

It might be a good idea to do this anyway, but given that no-one else
has noticed a problem in > 2 years suggests it's not worth the effort.

Best wishes,

   Julian

Bug#1065477: [Pkg-owncloud-maintainers] Bug#1065477: owncloud-client: Uploads to unstable must have a higher version than present in unstable.

[Sebastian Ramacher]

On 2024-03-05 16:01:10 +0100, Sebastian Ramacher wrote:
> Hi
> 
> On 2024-03-05 15:42:49 +0100, Pierre-Elliott Bécue wrote:
> > Hello,
> > 
> > Sebastian Ramacher  wrote on 05/03/2024 at 
> > 09:38:13+0100:
> > 
> > > Source: owncloud-client
> > > Version: 4.2.0.11670+dfsg-1.1
> > > Severity: serious
> > > Tags: ftbfs
> > > X-Debbugs-Cc: sramac...@debian.org
> > >
> > > Version check failed:
> > > Your upload included the binary package dolphin-owncloud, version 
> > > 4.2.0.11670+dfsg-1.1, for amd64,
> > > however unstable already has version 5.0.0-1+b1.
> > > Uploads to unstable must have a higher version than present in unstable.
> > >
> > > Cheers
> > 
> > owncloud-client has been uploaded far before in the past, and was
> > shipping dolphin-owncloud, nautilus-owncloud, et al.
> > 
> > In client v5, upstream removed these packages from the owncloud-client
> > source, and therefore they're now packaged through dedicated source
> > packages.
> > 
> > These ones are the latest uploads.
> > 
> > I'll upload the v5 version of owncloud-client source package which won't
> > ship dolphin-owncloud et al anymore.
> > 
> > It's what's been suggested to me, and therefore I can't see a bug here.
> > 
> > Could you give me a bit more intel aobut why this would be a serious
> > bug?
> 
> The uploads by the buidds fail to be included in the archive since the
> constraints are not satisfied. You can check the reject files for the
> changes files from owncloud-client on coccia.d.o.
> 
> You can also see on
> https://buildd.debian.org/status/package.php?p=owncloud-client=sid
> that the package is stuck in Uploaded state due to this issue.

FWIW, the dolphin-owncloud binary package is provided with a higher
version number by owncloud-client-desktop-shell-integration-dolphin. I
suppose the dolphin-owncloud package can just be dropped from
owncloud-client.

Cheers
-- 
Sebastian Ramacher

Bug#1065519: phosh-full: Phosh not booting on login or from cmd on OrangePi

[Evan Robinson]

Package: phosh-full
Version: 31
Severity: important
X-Debbugs-Cc: no-re...@ejrdesign.co.za

Dear Maintainer,

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

   * What led up to the situation?
Bought an OrangePi CM4 and booted the Debian Bookwork image from the SBC 
manufacturer.
Upgraded to Debian testing.
Ran 'apt get install phosh-full'
Rebooted and tried to login to the Phosh DM.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
Tried to login to the Phosh DM on the login page.

   * What was the outcome of this action?
Screen goes blank, saw a blinking cursor for about 5 - 10 sec, then the login 
screen loaded again.

   * What outcome did you expect instead?
To login to the OrangePi desktop andh ave it look like a phone layout due to 
Phosh.


-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: arm64 (aarch64)
Foreign Architectures: armhf

Kernel: Linux 5.10.160-rockchip-rk356x (SMP w/4 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages phosh-full depends on:
ii  avahi-daemon 0.8-13+b1
ii  cups-pk-helper   0.2.6-1+b1
ii  desktop-base 12.0.6+nmu1
ii  gnome-clocks 45.0-1
ii  gnome-console45.0-1
ii  gstreamer1.0-libav   1.22.10-1
ii  gstreamer1.0-plugins-ugly1.22.10-1
ii  libproxy1-plugin-networkmanager  0.4.18-2
ii  lollypop 1.4.37-1
ii  phosh-core   31
ii  phosh-pim31
ii  totem-plugins43.0-3

Versions of packages phosh-full recommends:
ii  chatty 0.8.1-1
pn  gnome-usage
pn  phosh-games
pn  phosh-plugins  

Versions of packages phosh-full suggests:
ii  phosh-phone  31

-- no debconf information

Here are some logs from journal:

Mar 05 20:33:30 orangepicm4 polkitd[842]: Registered Authentication Agent for 
unix-process:3164:26832 (system bus name :1.74 [/usr/bin/pkttyagen>
Mar 05 20:33:30 orangepicm4 brltty[537]: unsupported generic resource 
identifier: bluetooth:
Mar 05 20:33:30 orangepicm4 brltty[537]: brltty: unsupported generic resource 
identifier: bluetooth:
Mar 05 20:33:35 orangepicm4 brltty[537]: unsupported generic resource 
identifier: bluetooth:
Mar 05 20:33:35 orangepicm4 brltty[537]: brltty: unsupported generic resource 
identifier: bluetooth:
Mar 05 20:33:35 orangepicm4 systemd[1751]: mmsd-tng.service: Scheduled restart 
job, restart counter is at 24.
Mar 05 20:33:35 orangepicm4 systemd[1751]: Started mmsd-tng.service - 
Multimedia Messaging Service Daemon.
Mar 05 20:33:35 orangepicm4 mmsdtng[3180]: MMSD-TNG version 2.6.0, git version: 
2.6.0
Mar 05 20:33:35 orangepicm4 mmsdtng[3180]: Lost Dbus Connection! Exiting
Mar 05 20:33:35 orangepicm4 systemd[1751]: mmsd-tng.service: Main process 
exited, code=exited, status=1/FAILURE
Mar 05 20:33:35 orangepicm4 systemd[1751]: mmsd-tng.service: Failed with result 
'exit-code'.
Mar 05 20:33:37 orangepicm4 polkitd[842]: Operator of unix-session:2 
successfully authenticated as unix-user:orangepi to gain TEMPORARY authoriz>
Mar 05 20:33:37 orangepicm4 systemd[1]: Stopping getty@tty1.service - Getty on 
tty1...
Mar 05 20:33:37 orangepicm4 systemd[1]: getty@tty1.service: Deactivated 
successfully.
Mar 05 20:33:37 orangepicm4 systemd[1]: Stopped getty@tty1.service - Getty on 
tty1.
Mar 05 20:33:37 orangepicm4 systemd[1]: session-4.scope: Deactivated 
successfully.
Mar 05 20:33:37 orangepicm4 systemd-logind[848]: Session 4 logged out. Waiting 
for processes to exit.
Mar 05 20:33:37 orangepicm4 systemd[1]: Started phosh.service - Phosh, a shell 
for mobile phones.
Mar 05 20:33:37 orangepicm4 systemd-logind[848]: Removed session 4.
Mar 05 20:33:37 orangepicm4 polkitd[842]: Unregistered Authentication Agent for 
unix-process:unknown (system bus name :1.74, object path /org/fr>
Mar 05 20:33:37 orangepicm4 pulseaudio[1794]: ICE I/O error handler called
Mar 05 20:33:37 orangepicm4 (capsh)[3188]: pam_unix(login:session): session 
opened for user orangepi(uid=1000) by orangepi(uid=0)
Mar 05 20:33:37 orangepicm4 xfconfd[2063]: Name org.xfce.Xfconf lost on the 
message dbus, exiting.
Mar 05 20:33:37 orangepicm4 lightdm[1744]: pam_unix(lightdm-autologin:session): 
session closed for user orangepi
Mar 05 20:33:37 orangepicm4 org.gtk.vfs.Daemon[2093]: A connection to the bus 
can't be made
Mar 05 20:33:37 orangepicm4 kernel: [drm:vop2_plane_atomic_check] *ERROR* 
Unsupported linear format at Cluster0-win0
Mar 05 20:33:37 orangepicm4 kernel: [drm:vop2_plane_atomic_check] *ERROR* 
Unsupported linear format at Cluster0-win0
Mar 05 20:33:37 orangepicm4 systemd[1]: run-user-1000-gvfs.mount: Deactivated 
successfully.
Mar 05 20:33:37 orangepicm4 systemd-logind[848]: Session 2 

Bug#1064617: Passwords should not be changed frequently

[Justin B Rye]

Holger Wansing wrote:
> @d-l10n-english: hey guys, we would like to get a proposal reviewed, 
> which aims to improve the root/user password screens in the installer.
> 
> Please find the related merge request at
> 

It needs a small amount of rephrasing, but the most important problem
is that it starts by saying you need to set a password and then goes
on to suggest that you might not need to set a password.  Maybe that
can be fixed by rearranging things slightly...

 Template: passwd/root-password
 Type: password
 # :sl1:
 _Description: Root password/passphrase:
  To allow direct password/passphrase-based access to the 'root'
  (system administrative) account you can set it up here.
  The results can be disastrous if a malicious or incompetent user
  obtains root access, so you should not set one that can be guessed,
  found in dictionaries, or easily associated with you.
  .
  Alternatively, you can lock root's password
  by leaving this setting empty, and
  instead use the system's initial user account
  (which will be set up in the next step)
  to become root. This will be enabled for you
  by adding that user to the 'sudo' group.
  .
  Note: what you type here will be hidden (unless you select to show it).

Does this still feel like the same advice?

Otherwise the only thing I see is:

 Template: passwd/user-password
 Type: password
 # :sl1:
 _Description: Choose a password/passphrase for the new user:
  Make sure to select a strong password/passphrase, that cannot be guessed.
  ^
No comma needed there.
-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package

Bug#1065416: [Cross-toolchain-base-devs] Bug#1065416: linux-libc-dev claims to provide linux-libc-dev-ARCH-cross, but it doesn't do that completely

[Helmut Grohne]

Hi Bastian,

On Mon, Mar 04, 2024 at 11:04:22PM +0100, Bastian Blank wrote:
> > Arguably, a cross toolchain build should probably search
> > /usr/include/. I went back and forth a bit with Matthias
> > about whether we could add this and did not fully understand his
> > reasons, but there is one technical reason we want to avoid it for now.
> > We can have both libc6-dev:TARGET and libc6-dev-TARGET-cross installed
> > and these packages can have differing versions. When that happens and we
> > search both /usr//include and /usr/include/, we'd
> > mix two glibc versions with usually bad results (been there).
> 
> But this is a search path.  If a file exists in one, the second one is
> not found.  So nothing can happen even from version skew.

The problem arises in the reverse sense. If a file does not exist in
one, it is searched in the second and erroneously may be found. That may
make tests pass that should not pass and typically causes a link failure
later. While I do not have a concrete example at hand, I have seen this
pattern repeatedly and generally favour moving stuff out of /usr/include
to avoid this kind of confusion that causes difficult to debug problems.
This also motivates #798955 (in addition to the problem with file
conflicts).

> > The other aspect here is that it is not sufficient to add
> > /usr/include/ to the search path as you also need
> > /usr/include to get a complete linux kernel headers experience. We
> > definitely do not want to add /usr/include, because that is known to
> > misguide configure tests performed for the target architecture.
> 
> We are talking about the toolchain itself.  What configure tests could
> that be?  Or is that premature optimization of the gcc build?

The one case I really do remember quite well is sanitizers. These should
not be enabled in the earlier toolchain stages and failing to disable
them tends to cause linker failures. I don't think it matches the
concrete situation exactly though. You also make a good case in your
followup reporting that gcc-13-cross actually builds.

> You just said that the search path used during the build of the
> toolchain and the one for everything else are unrelated.  So you are
> free to create $BUILD/tmp-include with symlinks for asm, asm-generic,
> linux.
> 
> The toolchain as installed already finds all headers.  So I still don't
> see why we need this in the final system.

I find this argument fairly convincing and hope Matthias also does.

Thank you

Helmut

Bug#1064852: incus: missing depends on iproute2

[Helmut Grohne]

On Tue, Mar 05, 2024 at 12:00:15PM +, Mathias Gibbens wrote:
> to add iproute2. I would be interested to know more about what
> environment Incus is being used in that doesn't have the `ip` command
> available.

debvm-create --include=incus
# This should have created a file named rootfs.ext4.
debvm-run

>   My normal testing setup for Incus is a fresh, minimal expert install
> of sid via the netinst iso. During the install of the VM, I only
> install the base system and deselect the "standard system utilities"
> group. I do use DHCP, which looks like that might be responsible for
> pulling in iproute2 for me. If there's a way to create an even more
> minimal install, I'd be happy to incorporate that into my testing
> routine.

Turns out your minimal expert install is not so minimal. debvm tends to
give you a smaller but still functional installation. I think adding
--variant=important to debvm-create roughly gets you the minimal expert
installation, but creating the machine takes slightly longer and uses
more disk space of course.

Rather than adding debvm on top of your testing, I think adding
autopkgtests with isolation-machine should get you more automatic
coverage. Possibly such tests need to be explicitly allowed by debci
folks and currently are only available on amd64.

Helmut

Bug#1065516: kwartz-client: [INTL:nl] Dutch debconf templates translation

[Frans Spiesschaert]

 
 
Package: kwartz-client 
Severity: wishlist 
Tags: l10n patch 
 
 
 
Dear Maintainer, 
 
 
Please find attached the updated Dutch translation of kwartz-client
debconf messages. A draft has been posted to the debian-l10n-dutch mailing
list allowing for review. 
Please add it to your next package revision. 
It should be put as debian/po/nl.po in your package build tree. 
 

-- 
Kind regards,
Frans Spiesschaert



nl.po.gz
Description: application/gzip

Bug#1065515: minissdpd: [INTL:nl] Dutch debconf templates translation

[Frans Spiesschaert]

 
 
Package: minissdpd 
Severity: wishlist 
Tags: l10n patch 
 
 
 
Dear Maintainer, 
 
 
Please find attached the updated Dutch translation of minissdpd debconf
messages. A draft has been posted to the debian-l10n-dutch mailing list
allowing for review. 
Please add it to your next package revision. 
It should be put as debian/po/nl.po in your package build tree. 
 

-- 
Kind regards,
Frans Spiesschaert



nl.po.gz
Description: application/gzip

Bug#1065514: qpdfview FTCBFS: fails running lrelease and runs the build arch qmake6

[Helmut Grohne]

Source: qpdfview
Version: 0.5.0+ds-4
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

qpdfview fails to cross build from source. The immediate failure is
running lrelease, which requires a build dependency on qmake6:native.
While at it, I also enabled the use of the qmake6 build system that was
recently added to debhelper. I note that this does not make a cross
build succeed as it fails to locate a working moc. I think this is a
problem with the toolchain rather than qpdfview.

Helmut
diff --minimal -Nru qpdfview-0.5.0+ds/debian/changelog 
qpdfview-0.5.0+ds/debian/changelog
--- qpdfview-0.5.0+ds/debian/changelog  2024-01-19 21:28:53.0 +0100
+++ qpdfview-0.5.0+ds/debian/changelog  2024-03-05 18:08:04.0 +0100
@@ -1,3 +1,11 @@
+qpdfview (0.5.0+ds-4.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Improve cross building: Depend on qmake6:native and use qmake6
+buildsystem. (Closes: #-1)
+
+ -- Helmut Grohne   Tue, 05 Mar 2024 18:08:04 +0100
+
 qpdfview (0.5.0+ds-4) unstable; urgency=medium
 
   * d/control, rules: build using QT6.
diff --minimal -Nru qpdfview-0.5.0+ds/debian/control 
qpdfview-0.5.0+ds/debian/control
--- qpdfview-0.5.0+ds/debian/control2024-01-19 21:22:25.0 +0100
+++ qpdfview-0.5.0+ds/debian/control2024-03-05 18:08:04.0 +0100
@@ -3,6 +3,7 @@
 Priority: optional
 Maintainer: Louis-Philippe Véronneau 
 Build-Depends:
+ debhelper (>= 13.11.9~),
  debhelper-compat (= 13),
  libcups2-dev,
  libdjvulibre-dev,
@@ -14,6 +15,7 @@
  libsynctex-dev,
  pkg-config,
  qmake6,
+ qmake6:native,
  qt6-base-dev,
  qt6-tools-dev-tools,
  zlib1g-dev,
diff --minimal -Nru qpdfview-0.5.0+ds/debian/rules 
qpdfview-0.5.0+ds/debian/rules
--- qpdfview-0.5.0+ds/debian/rules  2024-01-19 21:28:45.0 +0100
+++ qpdfview-0.5.0+ds/debian/rules  2024-03-05 18:07:43.0 +0100
@@ -6,13 +6,11 @@
 export QT_SELECT := 6
 
 %:
-   dh $@ --buildsystem=qmake
+   dh $@ --buildsystem=qmake6
 
 override_dh_auto_configure:
/usr/lib/qt6/bin/lrelease qpdfview.pro
-   ln -s /usr/bin/qmake6 ./qmake
-   PATH=`pwd`:$(PATH) dh_auto_configure --buildsystem=qmake -- \
-   DEFINES+="_FILE_OFFSET_BITS=64" qpdfview.pro
+   dh_auto_configure -- DEFINES+="_FILE_OFFSET_BITS=64" qpdfview.pro
 
 override_dh_installchangelogs:
dh_installchangelogs CHANGES

Bug#1065513: apt: [INTL:nl] Dutch translation for the apt package

[Frans Spiesschaert]

 
 
Package: apt 
Severity: wishlist 
Tags: l10n patch 
 
 
 
Dear Maintainer, 
 
 
Please find attached the updated Dutch po file for the apt package. 
A draft has been posted to the debian-l10n-dutch mailing list allowing for
review. 
Please add it to your next package revision. 
It should be put as "po/nl.po" in your package build tree. 
 

-- 
Kind regards,
Frans Spiesschaert



nl.po.gz
Description: application/gzip

Bug#1065512: attr: [INTL:nl] Dutch translation for the attr package

[Frans Spiesschaert]

 
 
Package: attr 
Severity: wishlist 
Tags: l10n patch 
 
 
 
Dear Maintainer, 
 
 
Please find attached the updated Dutch po file for the attr package. 
A draft has been posted to the debian-l10n-dutch mailing list allowing for
review. 
Please add it to your next package revision. 
It should be put as "po/nl.po" in your package build tree. 
 

-- 
Kind regards,
Frans Spiesschaert



nl.po.gz
Description: application/gzip

Bug#1064617: Passwords should not be changed frequently

[Philip Hands]

Cyril Brulebois  writes:

> Philip Hands  (2024-03-05):
>> Cool, in that case I'll fix those two things and then use the result
>> for the MR[1], and if the openQA test runs look OK, will merge that.
>
> Only skimmed over it, but that looks sensible, thanks all.
>
> Is it worth getting d-l-english involved in a final review before
> getting that translated?  Contrary to a lot of not-so-critical l10n
> material, that particular screen is crucial, and I'd hate it if we
> wasted translator efforts due to a missed typo or obvious improvement.

I'm happy with doing that, and we might as well get it right given that
it's been ~12 years since the first bug, so a few more days makes no
odds.

I'm pretty sympathetic with the idea of simply dropping the password
advice (as just mentioned by Diederik) but it seems that Holger prefers
to keep it in -- either is fine with me.

BTW I don't know much about how the translation side of things works,
but given that there are many ways of getting the fine detail of this to
be incorrect in various ways, is there a standard method for adding
hints for translators, and should that be done?

Cheers, Phil.
-- 
Philip Hands -- https://hands.com/~phil


signature.asc
Description: PGP signature

Bug#1065511: dwarfutils: CVE-2024-2002

[Salvatore Bonaccorso]

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

Hi,

The following vulnerability was published for dwarfutils.

CVE-2024-2002[0]:
No description was found (try on a search engine)


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2024-2002
https://www.cve.org/CVERecord?id=CVE-2024-2002
[1] https://www.prevanders.net/dwarfbug.html#DW202402-002
[2] 
https://github.com/davea42/libdwarf-code/commit/404e6b1b14f60c81388d50b4239f81d461b3c3ad

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1065510: libnode108t64 is broken on !amd64

[Adrian Bunk]

Package: libnode108t64
Version: 18.19.1+dfsg-3.1
Severity: serious
Tags: ftbfs
X-Debbugs-Cc: Benjamin Drung , Steve Langasek 

Control: affects -1 src:thunderbird

https://buildd.debian.org/status/logs.php?pkg=thunderbird=1%3A115.8.1-1

...
 0:21.16 checking for nodejs... /usr/bin/node: error while loading shared 
libraries: libnode.so.108: cannot open shared object file: No such file or 
directory
...


This is due to:

$ cat debian/libnode108t64.install
usr/lib/libnode.so.* usr/lib/x86_64-linux-gnu/
$

Bug#1065509: mysql-8.0 ftbfs with test failure on 32bit time_t64

[Matthias Klose]

Package: src:mysql-8.0
Version: 8.0.36-1
Severity: serious
Tags: sid trixie

here seen on armhf:

[...]
[ 58%] main.compare w4  [ pass ]   2171
[ 58%] main.func_unixtime_32bitsw1  [ fail ]
Test ended at 2024-03-05 17:31:14

CURRENT_TEST: main.func_unixtime_32bits

CURRENT_TEST: main.func_unixtime_32bits
--- /<>/mysql-test/r/func_unixtime_32bits.result	2023-12-12 
21:09:36.0 +0300
+++ 
/<>/builddir/mysql-test/var/1/log/func_unixtime_32bits.reject 
2024-03-05 20:31:13.393008921 +0300

@@ -12,7 +12,7 @@
 2038-01-19 06:14:07
 select from_unixtime(2147483648);
 from_unixtime(2147483648)
-NULL
+2038-01-19 06:14:08
 select from_unixtime(0);
 from_unixtime(0)
 1970-01-01 03:00:00
@@ -32,26 +32,26 @@
 2147483647
 select unix_timestamp(from_unixtime(2147483648));
 unix_timestamp(from_unixtime(2147483648))
-NULL
+2147483648
 # check for invalid dates
 # bad year
 select unix_timestamp('2039-01-20 01:00:00');
 unix_timestamp('2039-01-20 01:00:00')
-0
+2179087200
 select unix_timestamp('1968-01-20 01:00:00');
 unix_timestamp('1968-01-20 01:00:00')
 0
 # bad month
 select unix_timestamp('2038-02-10 01:00:00');
 unix_timestamp('2038-02-10 01:00:00')
-0
+2149365600
 select unix_timestamp('1969-11-20 01:00:00');
 unix_timestamp('1969-11-20 01:00:00')
 0
 # bad day
 select unix_timestamp('2038-01-20 01:00:00');
 unix_timestamp('2038-01-20 01:00:00')
-0
+2147551200
 select unix_timestamp('1969-12-30 01:00:00');
 unix_timestamp('1969-12-30 01:00:00')
 0
@@ -71,7 +71,7 @@
 # check bad date, close to the boundary (we cut them off in the very end)
 select unix_timestamp('2038-01-19 07:14:07');
 unix_timestamp('2038-01-19 07:14:07')
-0
+2147487247
 # -- 1. func_time.test   END
 # -- 2. time_zone.test   BEGIN
 #
@@ -84,20 +84,20 @@
 unix_timestamp('2038-01-19 04:14:07'),
 unix_timestamp('2038-01-19 04:14:08');
 unix_timestamp('1970-01-01 01:00:00')	unix_timestamp('1970-01-01 
01:00:01')	unix_timestamp('2038-01-19 04:14:07') 
unix_timestamp('2038-01-19 04:14:08')

-0  1   2147483647  0
+0  1   2147483647  2147483648
 set time_zone=default;
 # -- 2. time_zone.test   END
 # -- 3. time_zone2.test   BEGIN
 select convert_tz('2038-01-19 04:14:08', '+01:00', 'UTC');
 convert_tz('2038-01-19 04:14:08', '+01:00', 'UTC')
-2038-01-19 04:14:08
+2038-01-19 03:14:08
 select convert_tz('2103-01-01 04:00:00', 'MET', 'UTC');
 convert_tz('2103-01-01 04:00:00', 'MET', 'UTC')
-2103-01-01 04:00:00
+2103-01-01 03:00:00
 Will work on a 64 bits time system, no-op on 32 bits time
 select convert_tz('3001-01-18 23:59:59', 'UTC', '+01:00');
 convert_tz('3001-01-18 23:59:59', 'UTC', '+01:00')
-3001-01-18 23:59:59
+3001-01-19 00:59:59
 Will not work, beyond range of UNIX timestamp support
 select convert_tz('3001-01-19 00:00:00', 'UTC', '+01:00');
 convert_tz('3001-01-19 00:00:00', 'UTC', '+01:00')
@@ -123,12 +123,12 @@
 (32536771199.999);
 SELECT a, FROM_UNIXTIME(a) FROM t1;
 a  FROM_UNIXTIME(a)
-32536771199.990NULL
-32536771199.990NULL
-32536771199.991NULL
-32536771199.992NULL
-32536771199.993NULL
-32536771199.994NULL
+32536771199.9903001-01-18 23:59:59.99
+32536771199.9903001-01-18 23:59:59.99
+32536771199.9913001-01-18 23:59:59.99
+32536771199.9923001-01-18 23:59:59.99
+32536771199.9933001-01-18 23:59:59.99
+32536771199.9943001-01-18 23:59:59.99
 32536771199.995NULL
 32536771199.996NULL
 32536771199.997NULL
@@ -148,7 +148,7 @@
 FROM_UNIXTIME(32536771199) AS c4,
 FROM_UNIXTIME(32536771199.999) AS c5;
 c1 c2  c3  c4  c5
-2038-01-19 03:14:07NULLNULLNULLNULL
+2038-01-19 03:14:07	2038-01-19 03:14:08	2038-01-19 03:14:08.00 
3001-01-18 23:59:59	NULL

 SET time_zone=default;
 SELECT
 FROM_UNIXTIME(2147483647) AS c1,
@@ -157,7 +157,7 @@
 FROM_UNIXTIME(32536771199) AS c4,
 FROM_UNIXTIME(32536771199.999) AS c5;
 c1 c2  c3  c4  c5
-2038-01-19 06:14:07NULLNULLNULLNULL
+2038-01-19 06:14:07	2038-01-19 06:14:08	2038-01-19 06:14:08.00 
3001-01-19 02:59:59	NULL

 SET sql_mode=time_truncate_fractional;
 SET time_zone='+00:00';
 SELECT
@@ -167,7 +167,7 @@
 FROM_UNIXTIME(32536771199) AS c4,
 FROM_UNIXTIME(32536771199.999) AS c5;
 c1 c2  c3  c4  c5
-2038-01-19 03:14:07NULL2038-01-19 03:14:07.99  NULLNULL
+2038-01-19 03:14:07	2038-01-19 03:14:08	2038-01-19 03:14:07.99 
3001-01-18 23:59:59	3001-01-18 23:59:59.99

 SET time_zone=default;
 SELECT
 FROM_UNIXTIME(2147483647) AS c1,
@@ -176,7 +176,7 @@
 FROM_UNIXTIME(32536771199) AS c4,
 FROM_UNIXTIME(32536771199.999) AS c5;
 c1 c2  c3  c4  c5
-2038-01-19 06:14:07NULL2038-01-19 06:14:07.99  NULLNULL
+2038-01-19 06:14:07	2038-01-19 06:14:08	2038-01-19 06:14:07.99 
3001-01-19 02:59:59	3001-01-19 02:59:59.99

 SET 

Bug#1064123: libgl1-mesa-dri: latest version crashes X, can't use mouse/keyboard

[Václav Ovsík]

I can confirm the problem on light system Fujitsu Futro S720
with Radeon HD 8280E (Kabini).

Downgrade mesa packages solved the problem
(
deb https://snapshot.debian.org/archive/debian/20240214T00Z/ sid main 
contrib non-free non-free-firmware
added to apt sources and then
aptitude -o Acquire::Check-Valid-Until=false
…
)

  Aptitude 0.8.13: log report
  Tue, Mar  5 2024 20:00:47 +0100
  
IMPORTANT: this log only lists intended actions; actions which fail
due to dpkg problems may not be completed.
  
  Will install 9 packages, and remove 0 packages.
  3869 kB of disk space will be freed
  
  [HOLD, DEPENDENCIES] libgtk2.0-common:amd64 2.24.33-3
  [HOLD, DEPENDENCIES] occt-misc:amd64 7.6.3+dfsg1-7
  [DOWNGRADE] libegl-mesa0:amd64 24.0.2-1 -> 23.3.5-1
  [DOWNGRADE] libgbm1:amd64 24.0.2-1 -> 23.3.5-1
  [DOWNGRADE] libgl1-mesa-dri:amd64 24.0.2-1 -> 23.3.5-1
  [DOWNGRADE] libglapi-mesa:amd64 24.0.2-1 -> 23.3.5-1
  [DOWNGRADE] libglx-mesa0:amd64 24.0.2-1 -> 23.3.5-1
  [DOWNGRADE] libxatracker2:amd64 24.0.2-1 -> 23.3.5-1
  [DOWNGRADE] mesa-va-drivers:amd64 24.0.2-1 -> 23.3.5-1
  [DOWNGRADE] mesa-vdpau-drivers:amd64 24.0.2-1 -> 23.3.5-1
  [DOWNGRADE] mesa-vulkan-drivers:amd64 24.0.2-1 -> 23.3.5-1
  

-- 
Zito
[   353.611] 
X.Org X Server 1.21.1.11
X Protocol Version 11, Revision 0
[   353.611] Current Operating System: Linux futro2 6.7.7-amd64 #1 SMP 
PREEMPT_DYNAMIC Debian 6.7.7-1 (2024-03-02) x86_64
[   353.611] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-6.7.7-amd64 
root=UUID=da2fd605-3371-4cba-b986-a2e2711eb69f ro
[   353.612] xorg-server 2:21.1.11-2 (https://www.debian.org/support) 
[   353.612] Current version of pixman: 0.42.2
[   353.612]Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[   353.612] Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[   353.612] (==) Log file: "/var/log/Xorg.0.log", Time: Tue Mar  5 19:51:19 
2024
[   353.613] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[   353.613] (==) No Layout section.  Using the first Screen section.
[   353.613] (==) No screen section available. Using defaults.
[   353.613] (**) |-->Screen "Default Screen Section" (0)
[   353.613] (**) |   |-->Monitor ""
[   353.614] (==) No monitor specified for screen "Default Screen Section".
Using a default monitor configuration.
[   353.614] (==) Automatically adding devices
[   353.614] (==) Automatically enabling devices
[   353.614] (==) Automatically adding GPU devices
[   353.614] (==) Automatically binding GPU devices
[   353.614] (==) Max clients allowed: 256, resource mask: 0x1f
[   353.614] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist.
[   353.614]Entry deleted from font path.
[   353.614] (==) FontPath set to:
/usr/share/fonts/X11/misc,
/usr/share/fonts/X11/100dpi/:unscaled,
/usr/share/fonts/X11/75dpi/:unscaled,
/usr/share/fonts/X11/Type1,
/usr/share/fonts/X11/100dpi,
/usr/share/fonts/X11/75dpi,
built-ins
[   353.614] (==) ModulePath set to "/usr/lib/xorg/modules"
[   353.614] (II) The server relies on udev to provide the list of input 
devices.
If no devices become available, reconfigure udev or disable 
AutoAddDevices.
[   353.614] (II) Loader magic: 0x55cdf6a59f00
[   353.614] (II) Module ABI versions:
[   353.614]X.Org ANSI C Emulation: 0.4
[   353.614]X.Org Video Driver: 25.2
[   353.614]X.Org XInput driver : 24.4
[   353.614]X.Org Server Extension : 10.0
[   353.616] (++) using VT number 7

[   353.616] (II) systemd-logind: logind integration requires -keeptty and 
-keeptty was not provided, disabling logind integration
[   353.619] (II) xfree86: Adding drm device (/dev/dri/card0)
[   353.619] (II) Platform probe for 
/sys/devices/pci:00/:00:01.0/drm/card0
[   353.628] (--) PCI:*(0@0:1:0) 1002:9837:1734:1202 rev 0, Mem @ 
0xc000/268435456, 0xd000/8388608, 0xfeb0/262144, I/O @ 
0xf000/256, BIOS @ 0x/131072
[   353.628] (II) LoadModule: "glx"
[   353.628] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so
[   353.631] (II) Module glx: vendor="X.Org Foundation"
[   353.631]compiled for 1.21.1.11, module version = 1.0.0
[   353.631]ABI class: X.Org Server Extension, version 10.0
[   353.631] (II) Applying OutputClass "Radeon" to /dev/dri/card0
[   353.631]loading driver: radeon
[   353.631] (==) Matched radeon as autoconfigured driver 0
[   353.631] (==) Matched ati as autoconfigured driver 1
[   353.631] (==) Matched modesetting as autoconfigured driver 2
[   353.631] (==) Matched fbdev as autoconfigured driver 3
[   353.631] (==) Matched vesa as autoconfigured driver 4
[   353.631] (==) Assigned the driver 

Bug#1064617: Passwords should not be changed frequently

[Holger Wansing]

Hi all,

Am 5. März 2024 19:28:25 MEZ schrieb Cyril Brulebois :
>Philip Hands  (2024-03-05):
>> Cool, in that case I'll fix those two things and then use the result
>> for the MR[1], and if the openQA test runs look OK, will merge that.
>
>Only skimmed over it, but that looks sensible, thanks all.
>
>Is it worth getting d-l-english involved in a final review before
>getting that translated? Contrary to a lot of not-so-critical l10n
>material, that particular screen is crucial, and I'd hate it if we
>wasted translator efforts due to a missed typo or obvious improvement.

Good idea.

@d-l10n-english: hey guys, we would like to get a proposal reviewed, 
which aims to improve the root/user password screens in the installer.

Please find the related merge request at


There was some (more) discussion / various attempts on finding
the correct wording, most of which can be found in



Maybe we should have put d-l10n-english into the loop earlier, sorry for not
doing that.


Holger


-- 
Sent from /e/ OS on Fairphone3

Bug#1065508: python3-markdown-it should recommend or suggest python3-linkify-it

[Jakub Wilk]

Package: python3-markdown-it
Version: 2.1.0-5

Please add python3-linkify-it to Recommends or Suggests, as it's needed 
for some functionality:


   >>> from markdown_it import MarkdownIt
   >>> md = MarkdownIt('gfm-like')
   >>> md.parse('foo')
   Traceback (most recent call last):
 File "", line 1, in 
 File "/usr/lib/python3/dist-packages/markdown_it/main.py", line 252, in 
parse
   self.core.process(state)
 File "/usr/lib/python3/dist-packages/markdown_it/parser_core.py", line 32, 
in process
   rule(state)
 File "/usr/lib/python3/dist-packages/markdown_it/rules_core/linkify.py", 
line 30, in linkify
   raise ModuleNotFoundError("Linkify enabled but not installed.")
   ModuleNotFoundError: Linkify enabled but not installed.


-- System Information:
Architecture: i386

Versions of packages python3-markdown-it depends on:
ii  python3-mdurl  0.1.2-1
ii  python3-typing-extensions  4.4.0-1
ii  python33.11.2-1+b1

--
Jakub Wilk

Bug#1064617: Passwords should not be changed frequently

[Diederik de Haas]

On Tuesday, 5 March 2024 19:28:25 CET Cyril Brulebois wrote:
> Philip Hands  (2024-03-05):
> > Cool, in that case I'll fix those two things and then use the result
> > for the MR[1], and if the openQA test runs look OK, will merge that.
> 
> Only skimmed over it, but that looks sensible, thanks all.
> 
> Is it worth getting d-l-english involved in a final review before
> getting that translated? Contrary to a lot of not-so-critical l10n
> material, that particular screen is crucial, and I'd hate it if we
> wasted translator efforts due to a missed typo or obvious improvement.

I had started a reply before I had to get out the door, so I'll just keep it 
to one suggestion, which may seem a bit 'radical':

How about getting rid of the password advise entirely from the d-i screen?

We could still make educational resources with f.e. tips on passwords/
passphrases in f.e. the wiki, but it's not the job or the (best) place to put 
such things in the d-i screens?

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

Bug#1064617: Passwords should not be changed frequently

[Cyril Brulebois]

Philip Hands  (2024-03-05):
> Cool, in that case I'll fix those two things and then use the result
> for the MR[1], and if the openQA test runs look OK, will merge that.

Only skimmed over it, but that looks sensible, thanks all.

Is it worth getting d-l-english involved in a final review before
getting that translated? Contrary to a lot of not-so-critical l10n
material, that particular screen is crucial, and I'd hate it if we
wasted translator efforts due to a missed typo or obvious improvement.


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


signature.asc
Description: PGP signature

Bug#1061754: python-json-log-formatter ftbfs with Python 3.12 as default

[Colin Watson]

Control: tag -1 moreinfo

On Mon, Jan 29, 2024 at 01:10:20PM +0100, Matthias Klose wrote:
> With python3-defaults from experimental, the package fails to build:
> 
> [...]
> = test session starts
> ==
> platform linux -- Python 3.12.1, pytest-7.4.4, pluggy-1.4.0
> cachedir: .tox/py312/.pytest_cache
> rootdir: /<>
> collected 29 items
> 
> tests.py ...FF
> 
> === FAILURES
> ===
> _ 
> JSONFormatterTest.test_message_and_time_and_extra_are_in_json_record_when_extra_is_provided
> _
> 
> self =  testMethod=test_message_and_time_and_extra_are_in_json_record_when_extra_is_provided>
> 
> def 
> test_message_and_time_and_extra_are_in_json_record_when_extra_is_provided(self):
> logger.info('Sign up', extra={'fizz': 'bazz'})
> json_record = json.loads(log_buffer.getvalue())
> expected_fields = set([
> 'message',
> 'time',
> 'fizz',
> ])
> >   self.assertEqual(set(json_record), expected_fields)
> E   AssertionError: Items in the first set but not the second:
> E   'taskName'

While it looks like this was fixed upstream in
https://github.com/marselester/json-log-formatter/commit/74f04ee4f6aa8e461fcb2d688459888b7279fc73
and I guess we could cherry-pick that, I also can't reproduce this
failure in current unstable with Python 3.12.  Can you still reproduce
this?

Thanks,

-- 
Colin Watson (he/him)  [cjwat...@debian.org]

Bug#1065507: RFS: netconsd/0.4-1 [ITP] -- Netconsole Daemon

[Michel Lind]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

 * Package name : netconsd
   Version  : 0.4-1
   Upstream contact : https://github.com/facebook/netconsd/issues
 * URL  : https://github.com/facebook/netconsd
 * License  : BSD-3-clause
 * Vcs  : https://salsa.debian.org/michel/netconsd
   Section  : admin

The source builds the following binary packages:

  netconsd - Netconsole Daemon

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/n/netconsd/netconsd_0.4-1.dsc

Changes for the initial release:

 netconsd (0.4-1) unstable; urgency=medium
 .
   * Initial release. (Closes: #1065462)

Regards,

-- 
Michel Lind (né Salim)
identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2


signature.asc
Description: PGP signature

Bug#1065505: ITP: parsyncfp2 -- Multihost parallel rsync wrapper

[Lucas Nussbaum]

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

* Package name: parsyncfp2
  Version : 2.59+git20240305.b2ef136
  Upstream Contact: Harry Mangalam 
* URL : https://github.com/hjmangalam/parsyncfp2/
* License : GPLv3
  Programming Lang: Perl
  Description : Multihost parallel rsync wrapper

Description: Multihost parallel rsync wrapper
 parsyncfp2 is a tool to efficiently transfer 10s of gigabytes across a network
 by running several instances of rsync in parallel. It aggregates files into
 chunks (or partitions) of a specified size, and then transfers each chunk
 using parallel runs of rsync. It needs to be installed only on the source end
 of the transfer.

A preliminary package is available at
https://salsa.debian.org/debian/parsyncfp2

Bug#1064898: /usr/bin/sshd: mktemp - literal X-s in /tmp directory names

[Csillag Tamás]

hi Colin,

On 2024-03-03 20:27, Colin Watson wrote:

On Tue, Feb 27, 2024 at 12:56:47PM +0100, Csillag Tamas wrote:

   * What led up to the situation?
 After upgrading to debian 12 I am seeing directories in /tmp 
like:

 ssh-XXnOKqkt, ssh-XXtGmfLV
   * What was the outcome of this action?
   * What outcome did you expect instead?
 These directories are created by sshd.
 In oldstable and OpenBSD the directories are as expected:
 ssh-LwxtSMoGSV, ssh-JPcQMaBN6s

 The regression might be only in openssh-portable?

As there are still 6 variable characters this might not be easily 
exploitable

security-wise and it used to be 10 just as in OpenBSD current.


This is the same as https://bugs.debian.org/1001186; it's fixed for the
next development release, but not yet for bookworm.

Since this doesn't appear to be immediately serious, my inclination is
to queue this up to fix along with the next bookworm openssh security
update (whenever that might be), but not to trouble the security team
with it right away.  Does that sound reasonable?


Okay that sounds reasonable to me.
It would be nice to have it in one of the next point releases if it is 
not too much trouble.


Regards,
 Tamás

Bug#1065504: RFS: shotwell/0.32.6-1 -- digital photo organizer

[Jörg Frings-Fürst]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name : shotwell
   Version  : 0.32.6-1
   Upstream contact : Jim Nelson 
 * URL  : https://wiki.gnome.org/Apps/Shotwell
 * License  : LGPL-2.1, BSD-3-Clause
 * Vcs  : https://git.jff.email/cgit/shotwell.git
   Section  : gnome

The source builds the following binary packages:

  shotwell - digital photo organizer
  shotwell-common - digital photo organizer - common files

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/s/shotwell/shotwell_0.32.6-1.dsc

or from 

 git https://git.jff.email/cgit/shotwell.git/?h=release%2Fdebian%2F0.36.6-1



Changes since the last upload:

 shotwell (0.32.6-1) unstable; urgency=medium
 .
   * New upstream release (Closes: #1064455).
 - debian/shotwell.install:
   + Install new shotwell-authenticator.
   * debian/copyright:
 - Add year 2024 to myself.
 - Refresh for the new release.
   * debian/control:
 - Add Build Depend python3-distutils.

CU
Jörg

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


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


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

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

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






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

Bug#1065503: llvm-18 ftbfs on armhf with libllvmlibc-18-dev enabled

[Matthias Klose]

Package: src:llvm-toolchain-18
Version: 1:18.1.0~rc2-4
Severity: important
Tags: sid trixie

llvm-18 ftbfs on armhf with libllvmlibc-18-dev enabled:

[...]
FAILED: 
libc/src/sys/mman/linux/CMakeFiles/libc.src.sys.mman.linux.mmap.dir/mmap.cpp.o 

"/<>/build-llvm/./bin/clang++" --target=arm-linux-gnueabihf 
-DLIBC_NAMESPACE=__llvm_libc_18_1_0_ -I"/<>/libc" -isystem 
"/<>/build-llvm/runtimes/runtimes-bins/libc/include" 
-fstack-protector-strong -Wformat -Werror=format-security 
-fno-stack-clash-protection -Wno-unused-command-line-argument 
-march=armv7-a -mfpu=vfpv3-d16 -D_LARGEFILE_SOURCE 
-D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64 -Wdate-time -D_FORTIFY_SOURCE=3 
-fPIC -fno-semantic-interposition -fvisibility-inlines-hidden 
-Werror=date-time -Werror=unguarded-availability-new -Wall -Wextra 
-Wno-unused-parameter -Wwrite-strings -Wcast-qual 
-Wmissing-field-initializers -Wimplicit-fallthrough 
-Wcovered-switch-default -Wno-noexcept-type -Wnon-virtual-dtor 
-Wdelete-non-virtual-dtor -Wsuggest-override -Wstring-conversion 
-Wmisleading-indentation -Wctad-maybe-unsupported -fdiagnostics-color 
-ffunction-sections -fdata-sections 
-fdebug-prefix-map=/<>/build-llvm/runtimes/runtimes-bins=../../../ 
-fdebug-prefix-map=/<>/= -no-canonical-prefixes 
-ffile-prefix-map=/<>/build-llvm/runtimes/runtimes-bins=../../../ 
-ffile-prefix-map=/<>/= -no-canonical-prefixes -O3 -DNDEBUG 
-std=gnu++17 -fpie -fno-builtin -fno-exceptions 
-fno-lax-vector-conversions -fno-unwind-tables 
-fno-asynchronous-unwind-tables -fno-rtti 
-ftrivial-auto-var-init=pattern -Wall -Wextra -Werror -Wconversion 
-Wno-sign-conversion -Wimplicit-fallthrough -Wwrite-strings -Wextra-semi 
-Wnewline-eof -Wnonportable-system-include-path -Wstrict-prototypes 
-Wthread-safety -Wglobal-constructors -DLIBC_COPT_PUBLIC_PACKAGING -MD 
-MT 
libc/src/sys/mman/linux/CMakeFiles/libc.src.sys.mman.linux.mmap.dir/mmap.cpp.o 
-MF 
libc/src/sys/mman/linux/CMakeFiles/libc.src.sys.mman.linux.mmap.dir/mmap.cpp.o.d 
-o 
libc/src/sys/mman/linux/CMakeFiles/libc.src.sys.mman.linux.mmap.dir/mmap.cpp.o 
-c '/<>/libc/src/sys/mman/linux/mmap.cpp'
/<>/libc/src/sys/mman/linux/mmap.cpp:44:59: error: implicit 
conversion loses integer precision: 'off_t' (aka 'long long') to 'long' 
[-Werror,-Wshorten-64-to-32]
   43 |   LIBC_NAMESPACE::syscall_impl(syscall_number, 
reinterpret_cast(addr),

  |   ~~
   44 |size, prot, flags, fd, offset);
  |   ^~
1 error generated.

Bug#1065445: pristine-tar: fails if upstream tarball top directory name is capitalised

[Julian Gilbey]

reassign 1065445 git-buildpackage
retitle 1065445 git-buildpackage: --pristine-tar fails if upstream tarball top 
directory name is not -
thanks

(See below for explanation.)

On Tue, Mar 05, 2024 at 07:41:02AM +, Julian Gilbey wrote:
> severity 1065445 important
> retitle 1065445 pristine-tar: fails if original tarball top directory name is 
> not -
> thanks
> 
> On Mon, Mar 04, 2024 at 08:53:21PM +, Julian Gilbey wrote:
> > Package: pristine-tar
> > Version: 1.50+nmu1
> > Severity: normal
> > 
> > I discovered that a package I was trying to use with pristine-tar
> > failed to work.  The cause of the issue seems to be that the upstream
> > tarball's top directory name is capitalised, but pristine-tar
> > regenerates a tarball with the name lowercased.
> > 
> > Steps to reproduce using git-buildpackage:
> > 1. Import the attached minimal working example into git using the command:
> >gbp import-dsc --pristine-tar hello_1.0-1.dsc
> >
> > 2. Change into the build directory:
> >cd hello
> > 
> > 3. Regenerate the original tar ball using pristine-tar, for example:
> >gbp buildpackage -S
> > 
> > 4. Return to the parent directory, then:
> > 
> > $ tar ztf hello_1.0.orig.tar.gz 
> > Hello-1.0/
> > Hello-1.0/Makefile
> > Hello-1.0/hello.c
> > $ tar ztf build-area/hello_1.0.orig.tar.gz 
> > hello-1.0/
> > hello-1.0/Makefile
> > hello-1.0/hello.c
> > 
> > Note the capitalisation has changed.  Also:
> > 
> > $ ls -l hello_1.0.orig.tar.gz build-area/hello_1.0.orig.tar.gz
> > -rw-r--r-- 1 jdg jdg 256 Mar  4 20:46 build-area/hello_1.0.orig.tar.gz
> > -rw-r--r-- 1 jdg jdg 175 Mar  4 20:00 hello_1.0.orig.tar.gz
> > 
> > Best wishes,
> > 
> >Julian
> 
> It turns out it's actually much more general than this: if the
> original tarball does not have a top directory named
> -
> then pristine-tar fails; it *always* creates a tarball with top
> directory called this, rather than using the name used by the original
> upstream tarball.  So pristine-tar fails on all such cases, including
> cases where mk-origtargz has been used to exclude some files.
> 
> Attached is a minimal example, hello2.
> 
>Julian

I checked pristine-tar directly on these examples, and it turns out
that it can handle these situations with no problems.  The problem
only emerges when git-buildpackage is being used, as in the example I
gave in the original bug report.  I don't know how gbp
import-orig/import-dsc --pristine-tar calls pristine-tar, but somehow
it appears to forget the top directory name of the original tarball,
leading to this problem.

I have reported this as a severity "important" bug because it may
silently (or not so silently) affect many packages.

Best wishes,

   Julian

Bug#1065446: pristine-tar: fails if upstream tarball contains an empty directory

[Julian Gilbey]

reassign 1065445 git-buildpackage
retitle 1065445 git-buildpackage: --pristine-tar fails if upstream tarball 
contains an empty directory
thanks

(See below for explanation.)

On Mon, Mar 04, 2024 at 09:20:02PM +, Julian Gilbey wrote:
> On Mon, Mar 04, 2024 at 08:53:25PM +, Julian Gilbey wrote:
> > Package: pristine-tar
> > Version: 1.50+nmu1
> > Severity: normal
> > 
> > I discovered that a package I was trying to use with pristine-tar
> > failed to work.  The cause of the issue seems to be that the upstream
> > tarball contains an empty directory, which is lost when regenerated by
> > pristine-tar.
> > 
> > Steps to reproduce using git-buildpackage:
> > 1. Import the attached minimal working example into git using the command:
> >gbp import-dsc --pristine-tar foobar_1.0-1.dsc
> > 
> > 2. Change into the build directory:
> >cd foobar
> > 
> > 3. Regenerate the original tar ball using pristine-tar, for example:
> >gbp buildpackage -S
> > 
> > 4. Return to the parent directory, then:
> > 
> > $ tar ztf foobar_1.0.orig.tar.gz
> > foobar-1.0/
> > foobar-1.0/foobar.c
> > foobar-1.0/Makefile
> > foobar-1.0/emptydir/
> > $ tar ztf build-area/foobar_1.0.orig.tar.gz
> > foobar-1.0/
> > foobar-1.0/Makefile
> > foobar-1.0/foobar.c
> > 
> > Note the empty directory has disappeared.  Also:
> > 
> > $ ls -l foobar_1.0.orig.tar.gz build-area/foobar_1.0.orig.tar.gz
> > -rw-r--r-- 1 jdg jdg 253 Mar  4 20:51 build-area/foobar_1.0.orig.tar.gz
> > -rw-r--r-- 1 jdg jdg 193 Mar  4 20:00 foobar_1.0.orig.tar.gz
> > 
> > Best wishes,
> > 
> >Julian
> 
> I forgot to attach the foobar package, here it is.
> 
>Julian

I checked pristine-tar directly on this example, and it turns out that
it can handle this situation with no problem, as long as the directory
tree has the empty directory present when pristine-tar gentar is
called.  The problem only emerges when git-buildpackage is being used,
as in the example I gave in the original bug report.  I presume that
this problem arises because git does not record the presence of empty
directories, so the resulting created tar file does not know about
them either.

Best wishes,

   Julian

Bug#1065502: gnome-shell-extension-arc-menu: Package short description truncated and its end is at the beginning of long description

[Beatrice Torracca]

Package: gnome-shell-extension-arc-menu
Severity: minor

Hi!

the package description currently in sid, has the short description truncated. 
It now reads " shell extension designed to replace the standard menu found in"

and the ending word "GNOME" went at the beginning of the long description which 
now starts with "GNOME Arc Menu is a GNOME shell extension ..."

I think some word-wrap went wrong.

Thanks,

beatrice

Bug#1064617: Passwords should not be changed frequently

[Philip Hands]

Holger Wansing  writes:

> Hi,
>
> Am 5. März 2024 15:01:21 MEZ schrieb Philip Hands :
>>Here are my latest attempts:
>
> "Be aware that that a ..."
> doubled "that"
>
> "... (unless you select to show it)"
> missing fullstop.

Well spotted - Thanks :-)

> Otherwise: looks good to me.

Cool, in that case I'll fix those two things and then use the result for
the MR[1], and if the openQA test runs look OK, will merge that.

Cheers, Phil.

[1] https://salsa.debian.org/installer-team/user-setup/-/merge_requests/7
-- 
Philip Hands -- https://hands.com/~phil


signature.asc
Description: PGP signature

Bug#1065396: ghostscript: Coordinate uploads for German man page transfer

[Helge Kreutzmann]

Hello Steven,
Am Mon, Mar 04, 2024 at 10:53:08PM -0600 schrieb Steven Robbins:
> On Monday, March 4, 2024 11:14:37 A.M. CST Helge Kreutzmann wrote:
> > Hello Steven,
> > 
> > Am Sun, Mar 03, 2024 at 10:25:45PM -0600 schrieb Steven Robbins:
> > > Thanks for the note!
> > > 
> > > On Sun, 3 Mar 2024 19:59:28 + Helge Kreutzmann 
> 
> > > > I will then add
> > > > Breaks: ghostscript (< > > > Replaces: ghostscript (< > > > 
> > > > In my debian/control. I'm a bit lost about the correct version,
> > > > though. So which version is best for "?"
> > > 
> > > I rarely deal with these situations, so I may be wrong, but
> > > I would think the best version is the new one:  10.02.1~dfsg-4.
> > 
> > Ideally it is the first version which stopped shipping the German man
> > pages. Maybe you can browse your git history? 
> 
> Git says 10.01.2~dfsg-1.
> 
> 
> > > OK.  You titled the bug "coordinate uploads ...".  Do we need to do them
> > > together - on the same day or something?
> > 
> > Well, this would be a good idea, to choose roughly the same day, to
> > avoid uninstallable situations for people living on unstable or testing.
> > 
> > I'm intending to prepare the next upstream release (and then
> > immediately the Debian release) on 2024-03-23.
> 
> OK.  Let me know when you do the upload and I'll do ghostscript immediately.

Great and thanks, I'll let you know once I'm in the process. Most
likeyl on 2024-03-23rd.

Greetings

Helge

-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
   Help keep free software "libre": http://www.ffii.de/


signature.asc
Description: PGP signature

Bug#1065501: qgis FTBFS: FAILED: src/crssync/CMakeFiles/synccrsdb

[Sebastiaan Couwenberg]

Control: tags -1 confirmed

On 3/5/24 4:44 PM, Adrian Bunk wrote:

https://buildd.debian.org/status/logs.php?pkg=qgis=3.34.4%2Bdfsg-3


Nothing we can do about that until the dependency chain has been rebuilt 
for the ongoing t64 transition.


The builds prior to the t64 transition succeeded.

Kind Regards,

Bas

--
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#1065501: qgis FTBFS: FAILED: src/crssync/CMakeFiles/synccrsdb

[Adrian Bunk]

Source: qgis
Version: 3.34.4+dfsg-3
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/logs.php?pkg=qgis=3.34.4%2Bdfsg-3

...
FAILED: src/crssync/CMakeFiles/synccrsdb 
/<>/debian/build/src/crssync/CMakeFiles/synccrsdb 
cd /<>/debian/build/src/crssync && 
/<>/debian/build/output/bin/crssync
Could not execute: INSERT INTO tbl_srs(srs_id, 
description,projection_acronym,ellipsoid_acronym,parameters,srid,auth_name,auth_id,is_geo,deprecated,srs_type)
 VALUES (63561, 'MSL UK & Ireland VORF08 depth','','','+vunits=m 
+no_defs',520003561,'EPSG','10150',0,0,'Vertical') [UNIQUE constraint failed: 
tbl_srs.srs_id/UNIQUE constraint failed: tbl_srs.srs_id]

Could not execute: INSERT INTO tbl_srs(srs_id, 
description,projection_acronym,ellipsoid_acronym,parameters,srid,auth_name,auth_id,is_geo,deprecated,srs_type)
 VALUES (63562, 'CD UK & Ireland VORF08 depth','','','+vunits=m 
+no_defs',520003562,'EPSG','10151',0,0,'Vertical') [UNIQUE constraint failed: 
tbl_srs.srs_id/UNIQUE constraint failed: tbl_srs.srs_id]

Could not execute: INSERT INTO tbl_srs(srs_id, 
description,projection_acronym,ellipsoid_acronym,parameters,srid,auth_name,auth_id,is_geo,deprecated,srs_type)
 VALUES (63563, 'ETRS89 + MSL UK & Ireland VORF08 
depth','longlat','longlat','+proj=longlat +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 
+vunits=m +no_defs',520003563,'EPSG','10156',0,0,'Compound') [UNIQUE constraint 
failed: tbl_srs.srs_id/UNIQUE constraint failed: tbl_srs.srs_id]

Could not execute: INSERT INTO tbl_srs(srs_id, 
description,projection_acronym,ellipsoid_acronym,parameters,srid,auth_name,auth_id,is_geo,deprecated,srs_type)
 VALUES (63564, 'ETRS89 + CD UK & Ireland VORF08 
depth','longlat','longlat','+proj=longlat +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 
+vunits=m +no_defs',520003564,'EPSG','10157',0,0,'Compound') [UNIQUE constraint 
failed: tbl_srs.srs_id/UNIQUE constraint failed: tbl_srs.srs_id]

Could not execute: INSERT INTO tbl_srs(srs_id, 
description,projection_acronym,ellipsoid_acronym,parameters,srid,auth_name,auth_id,is_geo,deprecated,srs_type)
 VALUES (63565, 'S34J-IRF','longlat','longlat','+proj=longlat +ellps=intl 
+no_defs',520003565,'EPSG','10158',1,0,'Geographic2d') [UNIQUE constraint 
failed: tbl_srs.srs_id/UNIQUE constraint failed: tbl_srs.srs_id]

Could not execute: INSERT INTO tbl_srs(srs_id, 
description,projection_acronym,ellipsoid_acronym,parameters,srid,auth_name,auth_id,is_geo,deprecated,srs_type)
 VALUES (63566, 'S34J reconstruction 
east-orientated','tmerc','tmerc','+proj=tmerc +lat_0=0 +lon_0=10.37 +k=1 
+x_0=-210327 +y_0=-6034310 +ellps=intl +units=m 
+no_defs',520003566,'EPSG','10160',0,0,'Projected') [UNIQUE constraint failed: 
tbl_srs.srs_id/UNIQUE constraint failed: tbl_srs.srs_id]

Could not execute: INSERT INTO tbl_srs(srs_id, 
description,projection_acronym,ellipsoid_acronym,parameters,srid,auth_name,auth_id,is_geo,deprecated,srs_type)
 VALUES (63567, 'JGD2011 / Japan Plane Rectangular CS I + JGD2011 (vertical) 
height','tmerc','tmerc','+proj=tmerc +lat_0=33 +lon_0=129.5 +k=0. +x_0=0 
+y_0=0 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m +vunits=m 
+no_defs',520003567,'EPSG','10162',0,0,'Compound') [UNIQUE constraint failed: 
tbl_srs.srs_id/UNIQUE constraint failed: tbl_srs.srs_id]

Could not execute: INSERT INTO tbl_srs(srs_id, 
description,projection_acronym,ellipsoid_acronym,parameters,srid,auth_name,auth_id,is_geo,deprecated,srs_type)
 VALUES (63568, 'JGD2011 / Japan Plane Rectangular CS II + JGD2011 (vertical) 
height','tmerc','tmerc','+proj=tmerc +lat_0=33 +lon_0=131 +k=0. +x_0=0 
+y_0=0 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m +vunits=m 
+no_defs',520003568,'EPSG','10163',0,0,'Compound') [UNIQUE constraint failed: 
tbl_srs.srs_id/UNIQUE constraint failed: tbl_srs.srs_id]

Could not execute: INSERT INTO tbl_srs(srs_id, 
description,projection_acronym,ellipsoid_acronym,parameters,srid,auth_name,auth_id,is_geo,deprecated,srs_type)
 VALUES (63569, 'JGD2011 / Japan Plane Rectangular CS III + JGD2011 (vertical) 
height','tmerc','tmerc','+proj=tmerc +lat_0=36 +lon_0=132.1667 
+k=0. +x_0=0 +y_0=0 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m +vunits=m 
+no_defs',520003569,'EPSG','10164',0,0,'Compound') [UNIQUE constraint failed: 
tbl_srs.srs_id/UNIQUE constraint failed: tbl_srs.srs_id]
...

Bug#1055989: emacs-gtk: emacs rejects font preference, falls back to "Purisa" font

[Christoph Reichenbach]

Dear David,

  my sincere apologies for missing your mail-- fortunately the most
recent update breakage reminded me to check the bug tracker again.

>> Emacs used the "Purisa" font as default font.  This font has the same Font
>> Foundry as "Terminus (TTF)" but is a "Comic Sans"-like special-purpose font
>> and unsuitable for normal operations.
>
> For me, it is Fantasque Sans Mono, but I agree it is not selecting the correct
> font. The selected font seems non-deterministic, possibly state
> dependent. After some various choices of Mono font, I ended up with
>
> Can you duplicate the problem for other fonts?  I tried 4 or 5 other
> monospaced fonts and they all seemed to work, at least in a fresh "emacs
> -Q".

  I had no trouble with the other monospaced fonts that I tried.

> I observed that choosing some non-existing font name (e.g. FooBar) had
> more or less the same effect. So maybe the issue is just that emacs
> cannot find "Terminus (TTF)". A wild guess would be the parens in the
> name causing the problem.

  My working assumption at the time of my investigation was that default
font selection searches for fonts with some hardcoded default values and
only applies some user-requested properties after it has already
selected the font.

  Basically, font selection (for the default font only-- other fonts
take a different code path) seems to follow the following steps, as far
as I understood it:

- Set hardcoded default font settings, including:
  - weight = regular
  - slant = ...?  (probably also regular)
- Apply user preferences for:
  - font foundry
  - font family
- Search for a font in the current font foundry that satisfies the
  current font family, weight, and slant requirements
- Apply user preferences for:
  - weight
  - slant
- Return the font

  This is greatly simplified-- the search step returns a list of
possible matches, for instance, and there are several selection
heuristics involved that I don't remember much about.


  If my interpretation is correct, then another workaround could be to
change "Terminus (TTF)" to report a "regular" weight that is identical
to its "medium" weight, but I have not had the time to figure out how to
try this.

> Apologies if this is covered already in your extensive report.

  Apologies for the verbosity of my earlier report; had I understood the
problem fully, I would have kept it shorter...

  All the best,

-- Christoph


signature.asc
Description: PGP signature

Bug#1064617: Passwords should not be changed frequently

[Holger Wansing]

Hi,

Am 5. März 2024 15:01:21 MEZ schrieb Philip Hands :
>Here are my latest attempts:

"Be aware that that a ..."
doubled "that"

"... (unless you select to show it)"
missing fullstop.

Otherwise: looks good to me.


Holger



-- 
Sent from /e/ OS on Fairphone3

Bug#1065477: [Pkg-owncloud-maintainers] Bug#1065477: owncloud-client: Uploads to unstable must have a higher version than present in unstable.

[Sebastian Ramacher]

Hi

On 2024-03-05 15:42:49 +0100, Pierre-Elliott Bécue wrote:
> Hello,
> 
> Sebastian Ramacher  wrote on 05/03/2024 at 
> 09:38:13+0100:
> 
> > Source: owncloud-client
> > Version: 4.2.0.11670+dfsg-1.1
> > Severity: serious
> > Tags: ftbfs
> > X-Debbugs-Cc: sramac...@debian.org
> >
> > Version check failed:
> > Your upload included the binary package dolphin-owncloud, version 
> > 4.2.0.11670+dfsg-1.1, for amd64,
> > however unstable already has version 5.0.0-1+b1.
> > Uploads to unstable must have a higher version than present in unstable.
> >
> > Cheers
> 
> owncloud-client has been uploaded far before in the past, and was
> shipping dolphin-owncloud, nautilus-owncloud, et al.
> 
> In client v5, upstream removed these packages from the owncloud-client
> source, and therefore they're now packaged through dedicated source
> packages.
> 
> These ones are the latest uploads.
> 
> I'll upload the v5 version of owncloud-client source package which won't
> ship dolphin-owncloud et al anymore.
> 
> It's what's been suggested to me, and therefore I can't see a bug here.
> 
> Could you give me a bit more intel aobut why this would be a serious
> bug?

The uploads by the buidds fail to be included in the archive since the
constraints are not satisfied. You can check the reject files for the
changes files from owncloud-client on coccia.d.o.

You can also see on
https://buildd.debian.org/status/package.php?p=owncloud-client=sid
that the package is stuck in Uploaded state due to this issue.

Cheers
-- 
Sebastian Ramacher

Bug#1065500: orc: liborc-0.4-dev-bin depends on both liborc-0.4-0 and liborc-0.4-0t64

[John David Anglin]

Source: orc
Version: 1:0.4.34-4.2
Severity: normal

Dear Maintainer,

See:
https://packages.debian.org/sid/liborc-0.4-dev-bin

Regards,
Dave Anglin

-- System Information:
Debian Release: trixie/sid
  APT prefers buildd-unstable
  APT policy: (500, 'buildd-unstable'), (500, 'unstable')
Architecture: hppa (parisc64)

Kernel: Linux 6.1.80+ (SMP w/4 CPU threads)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Bug#1065499: chromium: GPU acceleration broken on NXP iMX8M-Plus

[Ernesto Vigano']

Subject: chromium: chromium: GPU acceleration broken on NXP iMX8M-Plus
Package: chromium
X-Debbugs-Cc: gogimi4...@mcuma.com
Version: 122.0.6261.94-1~deb12u1
Severity: normal

Dear Maintainer,

I run chromium from a docker container with the following parameters
root@verdin-imx8mp-1422:/home/torizon# chromium --test-type
--allow-insecure-localhost --disable-notifications
--check-for-update-interval=31536 --kiosk
--disable-seccomp-filter-sandbox --use-gl=egl
--enable-features=UseOzonePlatform --ozone-platform=wayland
--no-sandbox https://webglsamples.org/fishtank/fishtank.html

My target is to see fishtank page with GPU acceleration (and so more
or less at 60 FPS, as NXP tech support told me).

I see the following log

[73699:73726:0305/140634.111003:ERROR:bus.cc(407)] Failed to connect
to the bus: Could not parse server address: Unknown address type
(examples of valid types are "tcp" and on UNIX "unix")
[73699:73726:0305/140634.111426:ERROR:bus.cc(407)] Failed to connect
to the bus: Could not parse server address: Unknown address type
(examples of valid types are "tcp" and on UNIX "unix")
[73699:73726:0305/140634.111958:ERROR:bus.cc(407)] Failed to connect
to the bus: Could not parse server address: Unknown address type
(examples of valid types are "tcp" and on UNIX "unix")
[73699:73726:0305/140634.112082:ERROR:bus.cc(407)] Failed to connect
to the bus: Could not parse server address: Unknown address type
(examples of valid types are "tcp" and on UNIX "unix")
[73699:73699:0305/140634.143052:ERROR:policy_logger.cc(157)]
:components/enterprise/browser/controller/chrome_browser_cloud_management_controller.cc(161)
Cloud management controller initialization aborted as CBCM is not
enabled. Please use the `--enable-chrome-browser-cloud-management`
command line flag to enable it if you are not using the official
Google Chrome build.
EGL: Warning: No default display support on wayland
[73757:73757:0305/140634.183403:ERROR:gl_display.cc(820)]
Initialization of all EGL display types failed.
[73757:73757:0305/140634.185130:ERROR:gl_ozone_egl.cc(26)]
GLDisplayEGL::Initialize failed.
EGL: Warning: No default display support on wayland
[73757:73757:0305/140634.186028:ERROR:gl_display.cc(820)]
Initialization of all EGL display types failed.
[73757:73757:0305/140634.186377:ERROR:gl_ozone_egl.cc(26)]
GLDisplayEGL::Initialize failed.
[73699:73726:0305/140634.191064:ERROR:bus.cc(407)] Failed to connect
to the bus: Could not parse server address: Unknown address type
(examples of valid types are "tcp" and on UNIX "unix")
[73699:73726:0305/140634.191256:ERROR:bus.cc(407)] Failed to connect
to the bus: Could not parse server address: Unknown address type
(examples of valid types are "tcp" and on UNIX "unix")
[73757:73757:0305/140634.198575:ERROR:viz_main_impl.cc(196)] Exiting
GPU process due to errors during initialization
[73699:73725:0305/140634.279714:ERROR:bus.cc(407)] Failed to connect
to the bus: Could not parse server address: Unknown address type
(examples of valid types are "tcp" and on UNIX "unix")
[73699:73723:0305/140634.279878:ERROR:bus.cc(407)] Failed to connect
to the bus: Could not parse server address: Unknown address type
(examples of valid types are "tcp" and on UNIX "unix")
[73699:73699:0305/140634.616027:ERROR:object_proxy.cc(576)] Failed to
call method: org.freedesktop.DBus.NameHasOwner: object_path=
/org/freedesktop/DBus: unknown error type:
[73699:73699:0305/140634.617028:ERROR:object_proxy.cc(576)] Failed to
call method: org.freedesktop.DBus.NameHasOwner: object_path=
/org/freedesktop/DBus: unknown error type:
[73699:73722:0305/140634.617718:ERROR:bus.cc(407)] Failed to connect
to the bus: Could not parse server address: Unknown address type
(examples of valid types are "tcp" and on UNIX "unix")
[73699:73803:0305/140634.665428:ERROR:object_proxy.cc(576)] Failed to
call method: org.freedesktop.DBus.Properties.Get: object_path=
/org/freedesktop/UPower: org.freedesktop.DBus.Error.ServiceUnknown:
The name org.freedesktop.UPower was not provided by any .service files
[73699:73803:0305/140634.667035:ERROR:object_proxy.cc(576)] Failed to
call method: org.freedesktop.UPower.GetDisplayDevice: object_path=
/org/freedesktop/UPower: org.freedesktop.DBus.Error.ServiceUnknown:
The name org.freedesktop.UPower was not provided by any .service files
[73699:73803:0305/140634.668695:ERROR:object_proxy.cc(576)] Failed to
call method: org.freedesktop.UPower.EnumerateDevices: object_path=
/org/freedesktop/UPower: org.freedesktop.DBus.Error.ServiceUnknown:
The name org.freedesktop.UPower was not provided by any .service files
[73699:73699:0305/140634.676476:ERROR:object_proxy.cc(576)] Failed to
call method: org.freedesktop.DBus.NameHasOwner: object_path=
/org/freedesktop/DBus: unknown error type:
[73699:73722:0305/140634.677364:ERROR:bus.cc(407)] Failed to connect
to the bus: Could not parse server address: Unknown address type
(examples of valid types are "tcp" and on UNIX "unix")
EGL: Warning: No default display 

Bug#1065477: [Pkg-owncloud-maintainers] Bug#1065477: owncloud-client: Uploads to unstable must have a higher version than present in unstable.

[Pierre-Elliott Bécue]

Hello,

Sebastian Ramacher  wrote on 05/03/2024 at 09:38:13+0100:

> Source: owncloud-client
> Version: 4.2.0.11670+dfsg-1.1
> Severity: serious
> Tags: ftbfs
> X-Debbugs-Cc: sramac...@debian.org
>
> Version check failed:
> Your upload included the binary package dolphin-owncloud, version 
> 4.2.0.11670+dfsg-1.1, for amd64,
> however unstable already has version 5.0.0-1+b1.
> Uploads to unstable must have a higher version than present in unstable.
>
> Cheers

owncloud-client has been uploaded far before in the past, and was
shipping dolphin-owncloud, nautilus-owncloud, et al.

In client v5, upstream removed these packages from the owncloud-client
source, and therefore they're now packaged through dedicated source
packages.

These ones are the latest uploads.

I'll upload the v5 version of owncloud-client source package which won't
ship dolphin-owncloud et al anymore.

It's what's been suggested to me, and therefore I can't see a bug here.

Could you give me a bit more intel aobut why this would be a serious
bug?
-- 
PEB


signature.asc
Description: PGP signature

Bug#1053502: mailman3-web: Package failed to install during upgrade from Debian 11 to 12

[arnaud]

Hi,

I had the «same issue» upgrading from debian 11 to 12, package 
mailman3-web failed in postconf.



What I found was:

With a config /etc/mailman3/mailman-web.py with this in it :
# EMAILNAME = 'localhost.local'
EMAILNAME = 'lists.example.com'

In /var/cache/debconf/config.dat I get

Name: mailman3-web/emailname
Template: mailman3-web/emailname
Value: #localhost.local
Owners: mailman3-web, unknown
Flags: seen

And then mailman3-web.postinst crashes when it tries to get 
mailman3-web/emailname variable.



I changed my config deleting the commented line, but I think the real 
issue is with get_config_option() in mailman3-web.config


It also worked by changing the sed regex in mailman3-web.config :
=>  s/^\s*$option\s*=\s*'\(.*\)'\s*$/\1/

Or by using python to get the config variable:
=> python3 -c "from importlib.machinery import 
SourceFileLoader;mail=SourceFileLoader('mailman-web','/etc/mailman3/mailman-web.py').load_module();print(mail.${option});"



Thanks for your work.
ArnAud.

Bug#1065421: extrepo-offline-data: Gitlab GPG key is expired

[Maximilian Stein]

Hello Juri,

Awesome, thanks!

Best
Maximilian

Bug#1065498: diffoscope: Crash on files without read permission

[rclobus]

Package: diffoscope
Version: 259
Severity: normal

Dear Maintainer,

I am able to crash diffoscope with a simple scenario:

sudo touch a b # Create 2 zero-byte files (owner=root)
sudo chmod go= a b # No access rights for group and others, default 
access for root
diffoscope a b # This is a regular user, who is not allowed to read 
these files


When the file does not have read permission for the current user, Python 
exists with


PermissionError: [Errno 13] Permission denied: 'a'

Expected behaviour:
* Skip this file and add it to the output as an inaccessible file 
(similar to how /dev/stdout is handled)


With kind regards,
Roland Clobus

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

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

Versions of packages diffoscope depends on:
ii  diffoscope-minimal  259

Versions of packages diffoscope recommends:
ii  7zip 23.01+dfsg-8
ii  aapt 1:14~beta1-2+b1
ii  abootimg 0.6-1.1
ii  acl  2.3.2-1
ii  androguard   3.4.0~a1-10
ii  apksigcopier 1.1.1-1
ii  apksigner31.0.2-1
ii  apktool  2.7.0+dfsg-7
ii  binutils-multiarch   2.42-3
ii  bzip21.0.8-5+b2
ii  caca-utils   0.99.beta20-4
ii  colord   1.4.6-5
ii  coreboot-utils   4.15~dfsg-4
ii  db-util  5.3.3
ii  default-jdk-headless 2:1.17-75
ii  device-tree-compiler 1.7.0-2
ii  dexdump  14.0.0+r15-1+b1
ii  docx2txt 1.4-5
ii  e2fsprogs1.47.0-2.3
ii  enjarify 1:1.0.3-5
ii  ffmpeg   7:6.1.1-2
ii  fontforge-extras 1:20230101~dfsg-1+b1
ii  fonttools4.46.0-1
ii  fp-utils 3.2.2+dfsg-32
ii  fp-utils-3.2.2 [fp-utils]3.2.2+dfsg-32
ii  genisoimage  9:1.1.11-3.4
ii  gettext  0.21-14+b1
ii  ghc  9.4.7-3
ii  ghostscript  10.02.1~dfsg-3
ii  giflib-tools 5.2.2-1
ii  gnumeric 1.12.56-2+b1
ii  gnupg-utils  2.2.40-1.1+b1
ii  gpg  2.2.40-1.1+b1
ii  hdf5-tools   1.10.10+repack-3.1
ii  html2text2.2.3-2
ii  imagemagick  8:6.9.12.98+dfsg1-5.1
ii  imagemagick-6.q16 [imagemagick]  8:6.9.12.98+dfsg1-5.1
ii  jsbeautifier 1.14.11-1
ii  libarchive-tools 3.7.2-1.1
ii  libxmlb-utils0.3.15-1
ii  llvm 1:16.0-57
ii  lz4 [liblz4-tool]1.9.4-1+b2
ii  lzip 1.24.1-1
ii  mono-utils   6.8.0.105+dfsg-3.5
ii  ocaml-nox4.14.1-1
ii  odt2txt  0.5-7
ii  oggvideotools0.9.1-6
ii  openssh-client   1:9.6p1-4
ii  openssl  3.1.5-1.1
ii  pgpdump  0.36-1
ii  poppler-utils22.12.0-2+b1
ii  procyon-decompiler   0.6.0-1
ii  python3-argcomplete  3.1.4-1
ii  python3-binwalk  2.3.4+dfsg1-4
ii  python3-debian   0.1.49
ii  python3-defusedxml   0.7.1-2
ii  python3-guestfs  1:1.52.0-2.1
ii  python3-jsondiff 2.0.0-2
ii  python3-pdfminer 20221105+dfsg-1
ii  python3-progressbar  2.5-4
ii  python3-pypdf4.0.2-1
ii  python3-pyxattr  0.8.1-1+b1
ii  python3-rpm  4.18.2+dfsg-2.1
ii  python3-tlsh 3.4.4+20151206-1.4+b5
ii  r-base-core  4.3.3-1
ii  radare2  5.5.0+dfsg-1.1
ii  rpm2cpio 4.18.2+dfsg-2.1
ii  sng  1.1.0-4
ii  sqlite3  3.45.1-1
ii  squashfs-tools   1:4.6.1-1
ii  tcpdump  4.99.4-3
ii  u-boot-tools 2024.01+dfsg-1
ii  unzip6.0-28
ii  wabt 1.0.34+dsfg2+~cs1.0.32-1
ii  xmlbeans 4.0.0-2
ii  xxd  2:9.1.0016-1
ii  xz-utils 5.6.0-0.2
ii  zip  3.0-13
ii  zstd 1.5.5+dfsg2-2

Versions of packages diffoscope 

Bug#1065497: Please allow php-psr-log 3

[David Prévot]

Package: php-klogger
Version: 1.2.2-2
Severity: important

Hi James, Sunil,

AFAICT, php-klogger is the only blocker preventing php-psr-log 3 upload
to unstable. php-psr-log 3 is available in experimental since 2021, and
recent php-psr-log will be needed for the php-monolog 3 transition.

Please, test your package with php-psr-log 3 and relax the versioned
dependency if you manage to make your package work with any php-psr-log
version, or upload to experimental a fix to make your packages work with
php-psr-log 3 (so we can easily upload it to unstable in sync with
php-psr-log 3).

TIA.

Cheers,

taffit


signature.asc
Description: PGP signature

Bug#1065496: mysql-8.0 builds with the embedded zlib library

[Matthias Klose]

Package: src:mysql-8.0
Version: 8.0.36-1
Severity: serious
Tags: sid trixie

mysql-8.0 builds with the embedded zlib library

[...]
-- Adding -DWITH_CURL=system
-- Adding -DWITH_EDITLINE=system
-- Adding -DWITH_ICU=system
-- Adding -DWITH_LIBEVENT=system
-- Adding -DWITH_LZ4=system
-- Adding -DWITH_PROTOBUF=system
-- Adding -DWITH_SSL=system
-- Adding -DWITH_ZSTD=system
-- Found WITH_FIDO=bundled on command line
-- ZLIB_VERSION (bundled) is 1.2.13
-- ZLIB_INCLUDE_DIR /PKGBUILDDIR/extra/zlib/zlib-1.2.13

it should not do that, please use the system zlib.

But building with the embedded zlib for time64:

[...]
DLZ4_DISABLE_DEPRECATE_WARNINGS -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE 
-D_LARGEFILE64_SOURCE=1 -D_USE_MATH_DEFINES -D__STDC_FORMAT_MACROS 
-D__STDC_LIMIT_MACROS -I/<>/builddir 
-I/<>/builddir/include -I/<> 
-I/<>/include -isystem 
/<>/builddir/extra/zlib/zlib-1.2.13 -isystem 
/<>/extra/zlib/zlib-1.2.13 -fno-omit-frame-pointer -g -O2 
-ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -fno-stack-clash-protection 
-fdebug-prefix-map=/<>=/usr/src/mysql-8.0-8.0.36-1build2 
-fdebug-prefix-map=/<>/=./ 
-fdebug-prefix-map=/<>/builddir=./obj -ffunction-sections 
-fdata-sections -O2 -g -DNDEBUG -fPIC   -D_LARGEFILE_SOURCE 
-D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64 -Wdate-time -D_FORTIFY_SOURCE=3 
-Wno-missing-profile -fvisibility=hidden -MD -MT 
extra/zlib/zlib-1.2.13/CMakeFiles/zlib_objlib.dir/gzclose.c.o -MF 
CMakeFiles/zlib_objlib.dir/gzclose.c.o.d -o 
CMakeFiles/zlib_objlib.dir/gzclose.c.o -c 
/<>/extra/zlib/zlib-1.2.13/gzclose.c

In file included from /usr/include/features.h:394,
 from 
/usr/include/arm-linux-gnueabihf/bits/libc-header-start.h:33,

 from /usr/include/stdio.h:28,
 from ../../../../extra/zlib/zlib-1.2.13/gzguts.h:21,
 from ../../../../extra/zlib/zlib-1.2.13/gzclose.c:6:
/usr/include/features-time64.h:26:5: error: #error "_TIME_BITS=64 is 
allowed only with _FILE_OFFSET_BITS=64"

   26 | #   error "_TIME_BITS=64 is allowed only with _FILE_OFFSET_BITS=64"
  | ^
make[4]: *** 
[extra/zlib/zlib-1.2.13/CMakeFiles/zlib_objlib.dir/build.make:135: 
extra/zlib/zlib-1.2.13/CMakeFiles/zlib_objlib.dir/gzclose.c.o] Error 1

make[4]: Leaving directory '/<>/builddir'
make[3]: *** [CMakeFiles/Makefile2:5761: 
extra/zlib/zlib-1.2.13/CMakeFiles/zlib_objlib.dir/all] Error 2

Bug#1065447: [Pkg-pascal-devel] Bug#1065447: unneeded libreoffice Build-Depends (libreoffice, ure-java, default-jre), -writer and -draw are enough

[Peter B]

Hi Rene,

Thanks for clarifying. Seems I can use libreoffice-draw-nogui, but need 
libreoffice-writer for now as you said.



Cheers,
Peter

Bug#1002789: closed by Debian FTP Masters (reply to Thomas Goirand ) (Bug#1002789: fixed in python-pycdlib 1.12.0+ds1-5)

[Santiago Vila]

El 5/3/24 a las 13:51, Lucas Nussbaum escribió:

I'm setting the severity to important since we know how to make it
build.


The bad thing is that this is not a condition which we can express via
Build-Depends.

Thomas: building a package should never involve adding a "secret sauce"
like this. This is what Debian Policy says about package building:

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

Note that it does *not* say "if build-time dependencies are specified and tmp
is bind-mounted as tmpfs" or anything like that.

Therefore, I still consider this to be a violation of a Policy "must" directive,
and I still expect that any and all tests which rely on conditions or properties
which may or may not hold in the building machine are buggy and must be 
disabled.

Thanks.

Bug#1065495: pekwm: debian/watch file fix

[Baempaieo]

Package: pekwm
Version: 0.1.18-1
Severity: important
Tags: patch

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

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

Versions of packages pekwm depends on:
ii  libc62.36-9+deb12u4
ii  libgcc-s112.2.0-14
ii  libjpeg62-turbo  1:2.1.5-2
ii  libpng16-16  1.6.39-2
ii  libstdc++6   12.2.0-14
ii  libx11-6 2:1.8.4-2+deb12u2
ii  libxext6 2:1.3.4-1+b1
ii  libxft2  2.3.6-1
ii  libxinerama1 2:1.1.4-3
ii  libxpm4  1:3.5.12-1.1+deb12u1
ii  libxrandr2   2:1.5.2-2+b1
ii  menu 2.1.49
ii  x11-utils7.7+5

pekwm recommends no packages.
--

Greetings,

According to the current issue under pekwm's package tracker (see:
https://tracker.debian.org/pkg/pekwm), it looks like the 'watch' file
isn't any able to retrieve any upstream version of the required package
(which, from what i have informed myself through the Debian Wiki page
for the 'debian/watch' entry, it's mainly an issue related to Github's
current changes- this having to adopt new methods to retrieve new
upstream versions).

As a way to contribute to the issue, the report has attached a brand new
'watch' file that should be working (this, by following the interested
Debian Wiki entries firsthand as a proper guideline) and retrieve the
current upstream version from the author's Github.

To note further, i have also tested the following file (again, by
following yet another Debian Wiki entry in regard) and it flags no
errors (sadly, i have no idea on how to attach 2 files via reportbug,
but i'll be glad to report the command's output in a reply- if asked).


I hope my contribution to the package will bring a great hand for this
wonderful distribution that is debian!
- Baempaieo
version=4
opts="\
searchmode=plain, \
filenamemangle=s%.*/v?@ANY_PACKAGE@%@PACKAGE@-$1.tar.xz%" \
https://api.github.com/repos/pekwm/pekwm/releases?per_page=50 \
https://api.github.com/repos/[^/]+/[^/]+/tarball/release-v?@ANY_VERSION@

Bug#1064282: poppler: NMU diff for 64-bit time_t transition

[Sune Stolborg Vuorela]

On Sunday, March 3, 2024 7:40:52 AM CET Steve Langasek wrote:
> (Particularly irrelevant for poppler, whose soname changes ~ monthly.)

Please note that the poppler frontends, that applications are supposed to be 
using does only very rarely change SONAME. the glib frontend haven't since 
it's introduction. Neither have the cpp frontend. The qt5 frontend has changed 
once. 

The Poppler Core library, which is meant to be a private shared thing between 
the frontends is changing SONAME monthly. But poppler core and the frontends 
are all in the same source, so it shouldn't affect anyone who behaves with 
poppler as documented. 

/Sune
 - who has been hacking on poppler over the last year and kept the api and abi 
of the frontends, but broken the internal api and abi multiple times.
-- 
I didn’t stop pretending when I became an adult, it’s just that when I was a 
kid I was pretending that I fit into the rules and structures of this world. 
And now that I’m an adult, I pretend that those rules and structures exist.
   - zefrank

Bug#1065494: libgtk-3-0t64: 64-bit time_t transition breaks gtk+3.0 immodule cache

[YOKOTA Hiroshi]

Package: libgtk-3-0t64
Version: 3.24.41-1.1
Severity: normal
X-Debbugs-Cc: yokota.h...@gmail.com, vor...@debian.org, 
debian-de...@lists.debian.org
Usertags: time-t

Dear Maintainer,

libgtk-3-0 package generates cache file
/usr/lib/${arch}/gtk-3.0/3.0.0/immodules.cache
when installing, and removes this cache file when removing the package.

This behavior is good in most cases, but not so good in 64-bit time_t
transition.
Because this behavior accidentally drops the cache file

If the cache file is missing, gtk3 immodules will not works.

Reinstall libgtk-3-0t64 package will rebuild the cache file, and immodules
works again.

libglib2.0-0t64 package had same bug, but fixed.
Please checkout there fix.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065022
https://salsa.debian.org/gnome-
team/glib/-/commit/55e33e4eb3165e66d9bf0f6598a6a59c9cedda4c


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

Kernel: Linux 6.7.7-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.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 libgtk-3-0t64 depends on:
ii  adwaita-icon-theme 46~beta-4
ii  hicolor-icon-theme 0.17-2
ii  libatk-bridge2.0-0t64  2.51.90-2
ii  libatk1.0-0t64 2.51.90-2
ii  libc6  2.37-15.1
ii  libcairo-gobject2  1.18.0-1+b1
ii  libcairo2  1.18.0-1+b1
ii  libcloudproviders0 0.3.5-1
ii  libcolord2 1.4.7-1
ii  libcups2t642.4.7-1.2+b1
ii  libepoxy0  1.5.10-1+b2
ii  libfontconfig1 2.15.0-1
ii  libfribidi01.0.13-3+b1
ii  libgdk-pixbuf-2.0-02.42.10+dfsg-3+b1
ii  libglib2.0-0t642.78.4-3
ii  libgtk-3-common3.24.41-1.1
ii  libharfbuzz0b  8.3.0-2
ii  libpango-1.0-0 1.52.0+ds-1
ii  libpangocairo-1.0-01.52.0+ds-1
ii  libpangoft2-1.0-0  1.52.0+ds-1
ii  libwayland-client0 1.22.0-2.1+b1
ii  libwayland-cursor0 1.22.0-2.1+b1
ii  libwayland-egl11.22.0-2.1+b1
ii  libx11-6   2:1.8.7-1
ii  libxcomposite1 1:0.4.5-1
ii  libxcursor11:1.2.1-1
ii  libxdamage11:1.1.6-1
ii  libxext6   2:1.3.4-1+b1
ii  libxfixes3 1:6.0.0-2
ii  libxi6 2:1.8.1-1
ii  libxinerama1   2:1.1.4-3
ii  libxkbcommon0  1.6.0-1
ii  libxrandr2 2:1.5.2-2+b1
ii  shared-mime-info   2.4-1

Versions of packages libgtk-3-0t64 recommends:
ii  libgtk-3-bin 3.24.41-1.1
ii  librsvg2-common  2.54.7+dfsg-2

Versions of packages libgtk-3-0t64 suggests:
ii  gvfs  1.53.90-3

Versions of packages libgtk-3-0t64 is related to:
pn  appmenu-gtk3-module   
pn  fcitx-frontend-gtk3   
pn  gcin-gtk3-immodule
pn  gtk-vector-screenshot 
pn  gtk3-engines-xfce 
pn  gtk3-im-libthai   
pn  hime-gtk3-immodule
ii  ibus-gtk3 1.5.29-1
pn  imhangul-gtk3 
ii  libcanberra-gtk3-module   0.30-12
pn  libcaribou-gtk3-module
pn  libgtk3-nocsd0
pn  maliit-inputcontext-gtk3  
pn  packagekit-gtk3-module
pn  scim-gtk-immodule 
pn  topmenu-gtk3  
pn  uim-gtk3  
pn  uim-gtk3-immodule 

-- no debconf information

Bug#1065493: libgtk2.0-0t64: 64-bit time_t transition breaks gtk+2.0 immodule cache

[YOKOTA Hiroshi]

Package: libgtk2.0-0t64
Version: 2.24.33-3.1
Severity: normal
X-Debbugs-Cc: yokota.h...@gmail.com, vor...@debian.org, 
debian-de...@lists.debian.org

Dear Maintainer,

libgtk2.0-0 package generates cache file
/usr/lib/${arch}/gtk-2.0/2.10.0/immodules.cache
when installing, and removes this cache file when removing the package.

This behavior is good in most cases, but not so good in 64-bit time_t
transition.
Because this behavior accidentally drops the cache file

If the cache file is missing, gtk2 immodules will not works.

Reinstall libgtk2.0-0t64 package will rebuild the cache file, and immodules
works again.

libglib2.0-0t64 package had same bug, but fixed.
Please checkout there fix.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065022
https://salsa.debian.org/gnome-
team/glib/-/commit/55e33e4eb3165e66d9bf0f6598a6a59c9cedda4c


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

Kernel: Linux 6.7.7-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.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 libgtk2.0-0t64 depends on:
ii  adwaita-icon-theme   46~beta-4
ii  gnome-icon-theme 3.12.0-5
ii  hicolor-icon-theme   0.17-2
ii  libatk1.0-0t64   2.51.90-2
ii  libc62.37-15.1
ii  libcairo21.18.0-1+b1
ii  libcups2t64  2.4.7-1.2+b1
ii  libfontconfig1   2.15.0-1
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-3+b1
ii  libglib2.0-0t64  2.78.4-3
ii  libgtk2.0-common 2.24.33-3.1
ii  libpango-1.0-0   1.52.0+ds-1
ii  libpangocairo-1.0-0  1.52.0+ds-1
ii  libpangoft2-1.0-01.52.0+ds-1
ii  libx11-6 2:1.8.7-1
ii  libxcomposite1   1:0.4.5-1
ii  libxcursor1  1:1.2.1-1
ii  libxdamage1  1:1.1.6-1
ii  libxext6 2:1.3.4-1+b1
ii  libxfixes3   1:6.0.0-2
ii  libxi6   2:1.8.1-1
ii  libxinerama1 2:1.1.4-3
ii  libxrandr2   2:1.5.2-2+b1
ii  libxrender1  1:0.9.10-1.1
ii  shared-mime-info 2.4-1

Versions of packages libgtk2.0-0t64 recommends:
ii  libgail-common   2.24.33-3.1
ii  libgtk2.0-bin2.24.33-3.1
ii  librsvg2-common  2.54.7+dfsg-2

Versions of packages libgtk2.0-0t64 suggests:
ii  gvfs  1.53.90-3

-- no debconf information

Bug#1002789: closed by Debian FTP Masters (reply to Thomas Goirand ) (Bug#1002789: fixed in python-pycdlib 1.12.0+ds1-5)

[Lucas Nussbaum]

Control: reopen 1002789
Control: found 1002789 1.12.0+ds1-5
Control: retitle 1002789 python-pycdlib: FTBFS during tests if /tmp is not a 
tmpfs
Control: severity 1002789 important

On 03/03/24 at 23:29 +0100, Thomas Goirand wrote:
> On 3/1/24 15:36, Lucas Nussbaum wrote:
> > Control: reopen 1002789
> > Control: found 1002789 1.12.0+ds1-5
> > 
> > Hi all,
> > 
> > Unfortunately, I can still reproduce this failure with version
> > 1.12.0+ds1-5, as shown in the attached build log.
> > Sorry about that.
> > 
> > Let us (Santiago or myself) know if it would be useful to provide a VM
> > to reproduce this issue.
> > 
> > Lucas
> 
> Hi Lucas,
> 
> How do you explain that the package builds fine on my laptop, and on the
> Debian buildd servers, as 1.12.0+ds1-6 (that only contains a cosmetic
> clean-up of .pytest_cache on clean, compared to -5) built find after I
> uploaded it? See:
> https://buildd.debian.org/status/package.php?p=python-pycdlib=sid
> 
> I'm therefore closing this bug again.
> 
> It's frustrating, I would have like to understand. Maybe something related
> to /tmp mounted as tmpfs vs a "real" partition?

Right, it looks like it only builds fine if /tmp is a tmpfs. Which looks
like a valid bug, isn't it? (I can reproduce the failure on my laptop
with /tmp on the same filesystem as the build dir, and then the failure
disapears if I mount -o bind /dev/shm /tmp).

Note that closing a bug just because you don't understand it does not
look right.

I'm setting the severity to important since we know how to make it
build.

Lucas

Bug#1065492: libnice: Please update to 0.1.22

[Jeremy Bícha]

Source: libnice
Version: 0.1.21-2
Severity: wishlist
X-Debbugs-CC: bi...@debian.org

In gstreamer 1.24's release notes, they recommend using libnice >= 0.1.22

https://gitlab.freedesktop.org/libnice/libnice/-/blob/0.1.22/NEWS

https://gstreamer.freedesktop.org/releases/1.24/

I do not have git commit permissions so please also review my "team
upload" before working on the new version.

https://salsa.debian.org/telepathy-team/libnice/-/merge_requests/5

Thank you,
Jeremy Bícha

Bug#1061516: Please add a sshd@.service template for socket activation

[Marco d'Itri]

On Mar 04, Colin Watson  wrote:

> Does this patch look workable?  It mostly just resurrects the template
> unit we used to ship, under a different name.
Looks good to me!

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#1065102: RFS: serioussam/1.10.6d+dfsg-1 [ITP] -- open source first person shooter developed by Croteam

[Alexander Pavlov]

Dear mentors.

I rewrote Debian patches to support the content of the demo version of
the game. The engine now supports the content of the demo version of
the game. When the game starts, the engine determines the installed
game content, and if it finds content from the demo version,
it turns on the mode for using the demo version of the content.


This allows games to be tested by anyone who does not have a copy
of the original game. A demo version of the game can be obtained
from many places.The most convenient way is to download using the
wget from the WebArchive. To install content from the demo version
of the game, open a terminal and run the following commands:

sudo apt install p7zip

wget https://archive.org/download/SeriousSamDemo/SeriousSamDemo.exe
wget
https://archive.org/download/SeriousSamPatches/serioussampatch105_usa.exe
7z x SeriousSamDemo.exe
7z x -y serioussampatch105_usa.exe
mkdir ~/.serioussam
cp -ax Disk1/* ~/.serioussam
rm -fr Disk1

wget https://archive.org/download/serioussamsedemo/SeriousSamSEDemo.exe
wget
https://archive.org/download/SeriousSamPatches/secondencounterpatch107_usa.exe
7z x SeriousSamSEDemo.exe
7z x -y secondencounterpatch107_usa.exe
mkdir ~/.serioussamse
cp -ax Disk1/* ~/.serioussamse
rm -fr Disk1

When you first launch the game, goto Menu -> Options -> Execute Addons
and select the default option. The demo version uses old settings scripts.
New ones you can take here: https://github.com/tx00100xt/SeriousSamClassic
Just rewrite the Scripts directory replacing the files.

I also added how to install the content of the demo version of the game
in README.Debian, README.source and manpages.

Best Regards,
Alexander Pavlov.

Bug#1065491: qtwebkit-opensource-src: Add support for loongarch64

[zhangdandan]

Source: qtwebkit-opensource-src
Version: 5.212.0~alpha4-33
Severity: wishlist
Tags: ftbfs
User: debian-loonga...@lists.debian.org
Usertags: loong64

Dear maintainers,

Compiling the qtwebkit-opensource-src failed for loong64 in the Debian 
Package Auto-Building environment.

The reason is the lack of loongarch64 support in qtwebkit-opensource-src.

I have added the patch(add loongarch64 support) to upstream, please see 
the pull-request https://github.com/qtwebkit/qtwebkit/pull/1096.

But the status of pull request from upstream is still open.

Reference to other architectures, I added the loongarch64 support to the 
qtwebkit-opensource-src source package.

Please consider the patch I attached.
If you have any questions, you can contact me at any time.

thanks,
Dandan Zhang

Description: Add loongarch64 support
Author: Dandan Zhang 
Forwarded: https://github.com/qtwebkit/qtwebkit/pull/1096
Last-Update: 2024-03-05

--- qtwebkit-opensource-src-5.212.0~alpha4.orig/CMakeLists.txt
+++ qtwebkit-opensource-src-5.212.0~alpha4/CMakeLists.txt
@@ -63,6 +63,8 @@ elseif (LOWERCASE_CMAKE_SYSTEM_PROCESSOR
 set(WTF_CPU_ARM64 1)
 elseif (LOWERCASE_CMAKE_SYSTEM_PROCESSOR MATCHES "alpha*")
 set(WTF_CPU_ALPHA 1)
+elseif (LOWERCASE_CMAKE_SYSTEM_PROCESSOR MATCHES "loongarch64")
+set(WTF_CPU_LOONGARCH64 1)
 elseif (LOWERCASE_CMAKE_SYSTEM_PROCESSOR MATCHES "^mips")
 set(WTF_CPU_MIPS 1)
 elseif (LOWERCASE_CMAKE_SYSTEM_PROCESSOR MATCHES "sh4")
--- qtwebkit-opensource-src-5.212.0~alpha4.orig/Source/JavaScriptCore/CMakeLists.txt
+++ qtwebkit-opensource-src-5.212.0~alpha4/Source/JavaScriptCore/CMakeLists.txt
@@ -1280,6 +1280,7 @@ if (WTF_CPU_ARM)
 elseif (WTF_CPU_ARM64)
 elseif (WTF_CPU_ALPHA)
 elseif (WTF_CPU_HPPA)
+elseif (WTF_CPU_LOONGARCH64)
 elseif (WTF_CPU_PPC)
 elseif (WTF_CPU_PPC64)
 elseif (WTF_CPU_PPC64LE)
--- qtwebkit-opensource-src-5.212.0~alpha4.orig/Source/WTF/wtf/Platform.h
+++ qtwebkit-opensource-src-5.212.0~alpha4/Source/WTF/wtf/Platform.h
@@ -80,6 +80,11 @@
 #endif
 #endif
 
+/* CPU(LOONGARCH64) - LoongArch 64-bit */
+#if defined(__loongarch64)
+#define WTF_CPU_LOONGARCH64 1
+#endif
+
 /* CPU(MIPS) - MIPS 32-bit and 64-bit */
 #if (defined(mips) || defined(__mips__) || defined(MIPS) || defined(_MIPS_) || defined(__mips64))
 #if defined(_ABI64) && (_MIPS_SIM == _ABI64)
@@ -713,7 +718,8 @@
 || CPU(MIPS64) \
 || CPU(PPC64) \
 || CPU(PPC64LE) \
-|| CPU(RISCV64)
+|| CPU(RISCV64) \
+|| CPU(LOONGARCH64)
 #define USE_JSVALUE64 1
 #else
 #define USE_JSVALUE32_64 1
--- qtwebkit-opensource-src-5.212.0~alpha4.orig/Source/WTF/wtf/dtoa/utils.h
+++ qtwebkit-opensource-src-5.212.0~alpha4/Source/WTF/wtf/dtoa/utils.h
@@ -49,7 +49,7 @@
 defined(__ARMEL__) || \
 defined(_MIPS_ARCH_MIPS32R2)
 #define DOUBLE_CONVERSION_CORRECT_DOUBLE_OPERATIONS 1
-#elif CPU(MIPS) || CPU(MIPS64) || CPU(PPC) || CPU(PPC64) || CPU(PPC64LE) || CPU(SH4) || CPU(S390) || CPU(S390X) || CPU(IA64) || CPU(ALPHA) || CPU(ARM64) || CPU(HPPA) || CPU(RISCV64)
+#elif CPU(MIPS) || CPU(MIPS64) || CPU(PPC) || CPU(PPC64) || CPU(PPC64LE) || CPU(SH4) || CPU(S390) || CPU(S390X) || CPU(IA64) || CPU(ALPHA) || CPU(ARM64) || CPU(HPPA) || CPU(RISCV64) || CPU(LOONGARCH64)
 #define DOUBLE_CONVERSION_CORRECT_DOUBLE_OPERATIONS 1
 #elif defined(_M_IX86) || defined(__i386__)
 #if defined(_WIN32)

Bug#1065471: wike shows a blank screen on PinePhonePro

[Jeremy Bícha]

On Tue, Mar 5, 2024 at 2:33 AM Russell Coker  wrote:
> I'll attach a screenshot when the bug is active.  It just shows a blank screen
> regardless of searches or a request for random page or main page.  Help text
> shows that the page in question is loaded just not displayed.

My first guess is that maybe webkit2gtk is not working on your system.

Thank you,
Jeremy Bícha

Bug#1065205: RFS: serioussam-vk/1.10.6d+dfsg-1 [ITP] -- Linux port of Serious Sam Classic with Vulkan support

[Alexander Pavlov]

Dear mentors.

I rewrote Debian patches to support the content of the demo version of the
game.
The engine now supports the content of the demo version of the game. When
the game starts,
the engine determines the installed game content, and if it finds content
from the demo version,
it turns on the mode for using the demo version of the content.

This allows games to be tested by anyone who does not have a copy of the
original game.
A demo version of the game can be obtained from many places.
The most convenient way is to download using the wget from the WebArchive.
To install content from the demo version of the game, open a terminal and
run the following commands:

sudo apt install p7zip

wget https://archive.org/download/SeriousSamDemo/SeriousSamDemo.exe
wget
https://archive.org/download/SeriousSamPatches/serioussampatch105_usa.exe
7z x SeriousSamDemo.exe
7z x -y serioussampatch105_usa.exe
mkdir ~/.serioussam-vk
cp -ax Disk1/* ~/.serioussam-vk
rm -fr Disk1

wget https://archive.org/download/serioussamsedemo/SeriousSamSEDemo.exe
wget
https://archive.org/download/SeriousSamPatches/secondencounterpatch107_usa.exe
7z x SeriousSamSEDemo.exe
7z x -y secondencounterpatch107_usa.exe
mkdir ~/.serioussamse-vk
cp -ax Disk1/* ~/.serioussamse-vk
rm -fr Disk1

When you first launch the game, goto Menu -> Options -> Execute Addons and
select the default option.
The demo version uses old settings scripts. New ones you can take here:
https://github.com/tx00100xt/SeriousSamClassic-VK
Just rewrite the Scripts directory replacing the files.

I also added how to install the content of the demo version of the game in
README.Debian, README.source and manpages.

Best Regards,
Alexander Pavlov.

Bug#1065490: mirror submission for mirror.leitecastro.com

[Tomas Leite Castro]

Package: mirrors
Severity: wishlist
User: mirr...@packages.debian.org
Usertags: mirror-submission

Submission-Type: new
Site: mirror.leitecastro.com
Archive-architecture: ALL amd64 arm64 armel armhf hurd-i386 hurd-amd64 i386 
mips mips64el mipsel powerpc ppc64el riscv64 s390x
Archive-http: /debian/
Archive-rsync: debian/
Maintainer: Tomas Leite Castro 
Country: PT Portugal
Location: Lisbon
Comment: This mirror is connected to a 20Gbps lagg and is IPv6 enabled. Syncs 
every hour from "syncproxy.eu.debian.org"




Trace Url: http://mirror.leitecastro.com/debian/project/trace/
Trace Url: 
http://mirror.leitecastro.com/debian/project/trace/ftp-master.debian.org
Trace Url: 
http://mirror.leitecastro.com/debian/project/trace/mirror.leitecastro.com

Bug#1064824: node-d3: fails to export map and other functions

[Nilesh Patra]

On Mon, Mar 04, 2024 at 09:18:01PM +, Julian Gilbey wrote:
> index.js → dist/d3.js...
> (!) Conflicting re-exports
> "index.js" re-exports "map" from both 
> "../../../usr/share/nodejs/d3-array/src/index.js" and 
> "../../../usr/share/nodejs/d3-collection/src/index.js" (will be ignored).
> created dist/d3.js in 1.9s
> 
> index.js → dist/d3.min.js...
> (!) Conflicting re-exports
> "index.js" re-exports "map" from both 
> "../../../usr/share/nodejs/d3-array/src/index.js" and 
> "../../../usr/share/nodejs/d3-collection/src/index.js" (will be ignored).
> created dist/d3.min.js in 4.2s
> -

I have pushed a commit to salsa that hopefully fixes this - can you please try 
with the same and see if that
helps you somewhat?

> So it's specifically "map" that is problematic, and I just happen to
> have stumbled upon it: d3 v5 depends on d3-array version 1, but the
> version of node-d3-array in unstable is 3.2.0+~cs5.0.6-2, and this is
> causing the conflict.
> 
> I don't know the best way to fix this.  node-d3-array version was
> upgraded from 1.2.4 to 3.x about two years ago, so d3 would have had
> this bug since then, but I'm the first one to stumble upon it :-/
>
> Perhaps we could package node-d3-array-1 (version 1.2.4) and have
> node-d3 build-depends on that?

I tried to embed it and realised it is creating an unholy mess. I got it 
working eventually
but it can open a can of worms sometime later. Maybe packaging the older version
would be the way to go if my fix above does not work.

I've added yadd to the thread for more qualified advice.

Best,
Nilesh


signature.asc
Description: PGP signature

Bug#1064852: incus: missing depends on iproute2

[Mathias Gibbens]

Control: tags -1 + pending

  It's easy enough to add iproute2 as a dependency, so I've done so.
Incus already has quite a number of dependencies, and I'd like to keep
that list as small as possible, which is why I was initially reluctant
to add iproute2. I would be interested to know more about what
environment Incus is being used in that doesn't have the `ip` command
available.

  My normal testing setup for Incus is a fresh, minimal expert install
of sid via the netinst iso. During the install of the VM, I only
install the base system and deselect the "standard system utilities"
group. I do use DHCP, which looks like that might be responsible for
pulling in iproute2 for me. If there's a way to create an even more
minimal install, I'd be happy to incorporate that into my testing
routine.

Mathias


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

Bug#1037139: gst-plugins-bad1.0: Please switch gstreamer1.0-wpe to the new 2.0 WPE API

[Alberto Garcia]

On Mon, Feb 12, 2024 at 11:53:00AM +, Alberto Garcia wrote:
> > gst-plugins-bad1.0 is buildable now. I am ready to do this mini
> > transition when you are, except that I see wpewebkit is on the
> > time_t transition list so we should let that transition complete
> > first.
> 
> Yes, let's do that, thanks.

libwpewebkit-2.0-dev is now in experimental in case you want to give
it a try. I'll upload it to unstable as soon as I verify that it
builds in all architectures and the time_t transition is finished.

Berto

Bug#1056243: django-assets autopkg tests fail with Python 3.12

[Emmanuel Arias]

Hi!

I worked on this package to fix py3.12 bug but I had some tests with the
tests. Also, I noted that upstream seems to be not active for the last 4
years (there are some PR trying to resolve py3.11 bugs). It has
webassets as b-depends that seems to be not active as well.

So, maybe is time to remove it from Debian?


-- 
cheers,
Emmanuel Arias

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  eam...@debian.org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: 13796755BBC72BB8ABE2AEB5 FA9DEC5DE11C63F1
 ⠈⠳⣄


signature.asc
Description: PGP signature

Bug#1065489: mongo-c-driver: FTBFS on armhf: format ‘%ld’ expects argument of type ‘long int’, but argument 4 has type ‘__suseconds64_t’ {aka ‘long long int’}

[Emanuele Rocca]

Source: mongo-c-driver
Version: 1.26.0-1.1
Severity: serious
Tags: ftbfs
User: debian-...@lists.debian.org
Usertags: time-t

Dear Maintainer,

mongo-c-driver fails to build from source on armhf. The failure may be
explained with the build flags introduced for the time64 migration,
which are on by default on armhf:

 -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64 
-Werror=implicit-function-declaration

[ 37%] Building C object 
src/libmongoc/CMakeFiles/mongoc_static.dir/src/mongoc/mongoc-error.c.o
cd /<>/obj-arm-linux-gnueabihf/src/libmongoc && /usr/bin/cc 
-DBSON_STATIC -DHAVE_STDARG_H -DHAVE_UNISTD_H -DKMS_MESSAGE_ENABLE_CRYPTO 
-DKMS_MESSAGE_ENABLE_CRYPTO_LIBCRYPTO -DKMS_MESSAGE_LITTLE_ENDIAN 
-DKMS_MSG_STATIC -DMCOMMON_NAME_PREFIX=_mongoc_mcommon -DMONGOC_COMPILATION 
-DMONGOC_STATIC -D_BSD_SOURCE -D_DEFAULT_SOURCE -D_XOPEN_SOURCE=700 
-I/<>/src/libmongoc/../kms-message/src 
-I/<>/obj-arm-linux-gnueabihf/src/libmongoc/src 
-I/<>/obj-arm-linux-gnueabihf/src/libmongoc/src/mongoc 
-I/<>/src/libmongoc/src 
-I/<>/src/libmongoc/src/mongoc 
-I/<>/src/libmongoc/../../src/common 
-I/<>/obj-arm-linux-gnueabihf/src/libmongoc/../../src 
-I/<>/obj-arm-linux-gnueabihf/src/libmongoc/../../src/common 
-I/<>/src/libbson/src 
-I/<>/obj-arm-linux-gnueabihf/src/libbson/src 
-I/<>/src/common 
-I/<>/obj-arm-linux-gnueabihf/src/common -g -O2 
-Werror=implicit-function-declaration -ffile-prefix-map=/<>=. 
-fstack-protector-strong -fstack-clash-protection -Wformat 
-Werror=format-security -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 
-D_TIME_BITS=64 -Wdate-time -D_FORTIFY_SOURCE=2 -std=c99 -Werror=implicit 
-Werror=return-type -Werror=incompatible-pointer-types -Werror=int-conversion 
-Werror=discarded-qualifiers -Werror=uninitialized -Werror -pedantic -Wall 
-Wempty-body -Wexpansion-to-defined -Wformat -Wformat-nonliteral 
-Wformat-security -Winit-self -Wmissing-include-dirs -Wredundant-decls -Wshadow 
-Wstrict-prototypes -Wswitch-default -Wswitch-enum -Wundef -Wuninitialized 
-Wno-strict-aliasing -fPIC -DUTF8PROC_EXPORTS -MD -MT 
src/libmongoc/CMakeFiles/mongoc_static.dir/src/mongoc/mongoc-error.c.o -MF 
CMakeFiles/mongoc_static.dir/src/mongoc/mongoc-error.c.o.d -o 
CMakeFiles/mongoc_static.dir/src/mongoc/mongoc-error.c.o -c 
/<>/src/libmongoc/src/mongoc/mongoc-error.c
/<>/src/libmongoc/src/mongoc/mongoc-log.c: In function 
‘mongoc_log_default_handler’:
/<>/src/libmongoc/src/mongoc/mongoc-log.c:215:21: error: format 
‘%ld’ expects argument of type ‘long int’, but argument 4 has type 
‘__suseconds64_t’ {aka ‘long long int’} [-Werror=format=]
  215 | "%s.%04ld: [%5d]: %8s: %12s: %s\n",
  | ^
  | |
  | long int
  | %04lld
  216 | nowstr,
  217 | tv.tv_usec / 1000L,
  | ~~
  ||
  |__suseconds64_t {aka long long int}
cc1: all warnings being treated as errors
make[3]: *** [src/libmongoc/CMakeFiles/mongoc_shared.dir/build.make:765: 
src/libmongoc/CMakeFiles/mongoc_shared.dir/src/mongoc/mongoc-log.c.o] Error 1

Bug#1065488: torbrowser-launcher should recommend libasound2

[Jakub Wilk]

Package: torbrowser-launcher
Version: 0.3.7-1

Tor Browser doesn't start if libasound2 is not installed:

$ 
~/.local/share/torbrowser/tbb/x86_64/tor-browser/Browser/start-tor-browser 
--verbose
XPCOMGlueLoad error for file 
/home/jwilk/.local/share/torbrowser/tbb/x86_64/tor-browser/Browser/libxul.so:
libasound.so.2: cannot open shared object file: No such file or directory
Couldn't load XPCOM.

Please add libasound2 to Recommends.

--
Jakub Wilk

Bug#1065487: new packaging repo based on tarballs

[Christian Kreidl]

Package: urjtag
Severity: wishlist

Dear Maintainer,

Since urjtag debian packages are really old I've invested some work in debian 
packaging.

I tried to get the already started packaging in
https://salsa.debian.org/electronics-team/urjtag
to work, but it failed since upstream git has the sources in a subdirectory
and the released tarballs differ from the git tag.

So I decided to base a new git packaging repo on tarballs only:
https://salsa.debian.org/ckreidl/urjtag
Keeping up with new versions should be straight forward.

Please feel free to copy the repo to electronics-team.

Thanks!
Christian

Bug#1065486: sbd: FTBFS due to hardcoded libaio SONAME used in dlopen()

[Guillem Jover]

Source: sbd
Source-Version: 1.5.2-1
Severity: serious
Tags: patch upstream

Hi!

For the time64 transition I've done a local SONAME bump. This will
make this package FTBFS (once the mass binNMUs are triggered) due to
its test suite hardcoding the libaio SONAME for a dlopen() call.

Because the package is already explicitly linking against -laio (which
I guess also means there's a missing Build-Depends here), we are
guaranteed to have libaio.so available, so we can use that to avoid
hardcoding the SONAME. Of course dlopen()ing a shared library like
this is dangerous as the code might use the wrong ABI and that might
go unnoticed at build time, so perhaps it might also be worth
investigating in the future whether the dlopen is really necessary at
all (the test case is already being linked also against -laio).

The attached patch fixes the build for me with the new libaio.

Thanks,
Guillem
Description: Do not hardcode libaio SONAME
 The SONAME might change, and then the dlopen() fails. This just happened now
 as part of the time64 transition. The package is already linking explicitly
 against -laio, thus libaio.so will be guaranteed to be present, so instead
 of hardcoding the current SONAME at this point in time, simply use libaio.so.
Author: Guillem Jover 
Last-Update: 2024-03-05

---
 tests/sbd-testbed.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- a/tests/sbd-testbed.c
+++ b/tests/sbd-testbed.c
@@ -154,9 +154,9 @@ init (void)
 orig_fopen= (orig_fopen_f_type)dlsym_fatal(RTLD_NEXT,"fopen");
 orig_fclose   = (orig_fclose_f_type)dlsym_fatal(RTLD_NEXT,"fclose");
 
-handle = dlopen("libaio.so.1",  RTLD_NOW);
+handle = dlopen("libaio.so",  RTLD_NOW);
 if (!handle) {
-fprintf(stderr, "Failed opening libaio.so.1\n");
+fprintf(stderr, "Failed opening libaio.so\n");
 exit(1);
 }
 orig_io_setup = (orig_io_setup_f_type)dlsym_fatal(handle,"io_setup");