Bug#1051125: RFS: a2d/2.0.0-1 [ITP] -- APRS to DAPNET portal

[Yogu NY3W]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

* Package name : a2d
   Version  : 2.0.0-1
   Upstream contact : Yogeswaran Umasankar  kd8...@gmail.com
* URL  : https://github.com/NGC2023/a2d
* License  : MIT License
* Vcs  : https://github.com/NGC2023/a2d
   Section  : hamradio

The source builds the following binary packages:

  a2d - APRS to DAPNET portal

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

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

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

  dget -x https://mentors.debian.net/debian/pool/main/a/a2d/a2d_2.0.0-1.dsc

Changes for the initial release:

a2d (2.0.0-1) unstable; urgency=medium
.
   * New features:
 - Added a Flask web app with a user-friendly UI for a2d.
 - UI now displays a2d status, system and memory status and message
logs.
 - Included light and dark modes for the UI to enhance user experience.
 - Enhanced security with PIN access protected by a Passphrase for the
UI.
 - Added back up and restore a2d configurations.
 - Added an Instructions section to guide users.
 - Implemented an automatic logout feature after 20 min of inactivity.
 - Introduced automated APRS fetch interval management.
 - Users can now access listen port, server name and manage SSL
certificates (self-signed and CA).
 - Introduced an option to select a2d default settings.
 - Implemented a factory reset feature for a2d, users can retain SSL
certificates.
 - Enhanced server status UI with all status including SSL and
certificate in use.
 - Added network health monitoring to track round trip time (RTT) to
APRS and DAPNET servers.
.
   * Bug fix:
 - Fixed an issue where the database was unnecessarily written in each
run.
 - Resolved database corruption in specific scenarios.
 - Prevented message loss due to frequent APRS fetch.
.
   * Improvements:
 - Implemented checks to prevent flooding bulk messages to DAPNET
during the first run.
 - Optimized data transfer from ARPS for enhanced efficiency.
 - Enhanced data transfer to DAPNET with improved error handling for
wrong credentials.
 - Boosted data processing speed by utilizing multiprocessing for
multicore access.
 - Replaced multiple system services with a single, resource-efficient
system service.
 - Transitioned from pip repository to apt repository for smoother deb
installation.
 - Enhanced session handling and included auto logout feature.
 - Included clear notifications and feedback messages in the UI based
on user interactions.

Regards,

-- 
  Yogeswaran Umasankar, NY3W

Bug#1042552: torbrowser-launcher: Fails to download the binary due to a broken link

[Roger Shimizu]

control: fixed -1 0.3.6-1~exp1
control: fixed -1 0.3.6-2~bpo11+1

On Sun, Jul 30, 2023 at 12:33 AM SIMONE DEIANA  wrote:
>
> Package: torbrowser-launcher
> Version: 0.3.3-6
> Severity: important
> X-Debbugs-Cc: bugreport.debian.acco...@simonedeiana.xyz
>
> Dear Maintainer,
>
> Currently the torbrowser-launcher package tries to download the tor browser
> binary using an outdated naming scheme.
>
> Instead of downloading from
> https://dist.torproject.org/torbrowser/12.5.1/tor-
> browser-linux64-12.5.1_ALL.tar.xz.asc it tries to download (and fails) from
> https://dist.torproject.org/torbrowser/12.5.1/tor-browser-linux64-12.5.1_en-
> US.tar.xz.asc
>
> This makes it completely impossible to use the package and urges an
> immediate fix.

I think you can use the version in backports (0.3.6-2~bpo11+1) to
workaround the problem.

Cheers,
Roger

Bug#1051124: libdex: Circular build dependency with sysprof makes bootstrap impossible

[John Paul Adrian Glaubitz]

Source: libdex
Version: 0.3.1-1
Severity: important

Hello!

Both src:libdex and src:sysprof have unconditional build dependencies on each 
other
meaning that's not possible to bootstrap gtk4 at the moment. This affects 
riscv64
and loong64.

Either libdex or sysprof need to be changed to have a build profile for 
bootstrapping
without the other.

Thanks,
Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#1050944: debhelper-compat level

[Vladimir Petko]

Hi,

 I apologise for my earlier comment being too vague and in the wrong
tone and mentioning a completely wrong (or misleading) thing. We do
openjdk security updates in -security pocket in Ubuntu and according
to security team FAQ[1] the updates are built with -release and
-security pockets. The updated debhelper is present in the backports
pocket which is not used by the security team for security updates.
This means that we are stuck with the older (11) debhelper version in
order to build security updates for bionic and up.

Best Regards,
 Vladimir.

[1] 
https://wiki.ubuntu.com/SecurityTeam/FAQ#How_are_the_.22-updates.22_and_.22-security.22_pockets_different.3F

On Sun, Sep 3, 2023 at 5:41 AM tony mancill  wrote:
>
> Hi Matthias,
>
> On Fri, Sep 01, 2023 at 07:19:15AM -0700, tony mancill wrote:
> > On Fri, Sep 01, 2023 at 07:04:05PM +1200, Vladimir Petko wrote:
> > >  The debhelper-compat was intentionally set to >=11 in order to
> > > support backports.
> >
> > Thank you for the reminder.  I can easily revert the change.  But to
> > make sure I understand the requirements, how far back do we want to
> > support backports of new uploads of jtreg6?
> >
> > Although it wasn't part of the buster release, debhelper 13.x is
> > available in old-old-stable (buster) backports [0,1], which is as far as
> > I looked before making the change.  Is jtreg6 needed for stretch, which
> > is currently in EOL ELTS [2]?
> >
> > Thank you,
> > tony
> >
> > [0] https://packages.debian.org/source/buster-backports/debhelper
> > [1] https://packages.debian.org/source/oldoldstable-backports/debhelper
> > [2] https://wiki.debian.org/DebianReleases
>
> Thank you for the upload.  As I mentioned to Vladimir above, I'd like to
> document the reason debhelper 13 is not backport friendly.  If you can
> give me a pointer or a brief explanation, I'll add it to README.source
> so it's clear to all.  (I assume it has to do with releases older than
> Debian buster or Ubuntu focal [3], since both of their backport suites
> already contain debhelper 13.)
>
> Also, there are build-deps of jtreg6, for example libhamcrest-java [4]
> that depend on debhelper-compat 13 and presumably need to be adjusted as
> well.
>
> Thanks,
> tony
>
> [3] 
> https://packages.ubuntu.com/search?suite=default=all=any=debhelper=sourcenames
> [4] 
> https://salsa.debian.org/java-team/libhamcrest-java/-/blob/master/debian/control#L10

Bug#1041508: tex-common: fmutil fails to rebuild formats

[Paul Gevers]

Control: severity -1 serious

Hi,

On Sat, 2 Sep 2023 23:47:19 +0200 =?UTF-8?B?UHJldcOfZSwgSGlsbWFy?= 
 wrote:
Sorry, for the trouble, I should have added a "Breaks" statement to 
texlive-binaries. Maybe it makes sense to do that now?


Yes and no. Adding the Breaks will prevent migration of texlive-binaries 
until texlive-extra migrates so it wouldn't fix anything in testing. 
Adding the Breaks will prevent partial upgrades (once it migrates to 
testing) to do the wrong thing, so yes, please add it.


I've just added an ignore hint for texlive-extra, as the 
r-bioc-biocstyle issue is clearly less of a problem than this one (and 
bug reports are filed).


Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1051104: marked as pending in sysprof

[John Paul Adrian Glaubitz]

Hi!

On Sat, 2023-09-02 at 20:20 +, Jeremy Bicha wrote:
> Bug #1051104 in sysprof reported by you has been fixed in the
> Git repository and is awaiting an upload. You can see the commit
> message below and you can check the diff of the fix at:
> 
> https://salsa.debian.org/gnome-team/sysprof/-/commit/277ed8cd349106e88bd118dc67c5f4d5bb6d5104
> 
> 
> Fix nogui build profile
> 
> Closes: #1051104
> 

Thanks for fixing this. Could you upload the package soonish, so I can
bootstrap sysprof and gtk4 on all Debian Ports architectures?

Thanks,
Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#1040963: src:starpu: fails to migrate to testing for too long: unsatisfiable dependency on armel, mipsel and s390x + segfault

[Paul Gevers]

Hi,

On Thu, 13 Jul 2023 11:18:41 +0200 Paul Gevers  wrote:
If you believe your package is unable to migrate to testing due to 
issues beyond your control, don't hesitate to contact the Release Team.


The only remaining issue (autopkgtest failures on armel and armhf) is 
caused due to bug 1043238 in libpfm4, which is triggered by bug 1036818 
in lxcfs. I'm going to let starpu migrate.


Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1043238: libpfm4: crashes on initialization on 32bit arm in autopkgtest CI

[Paul Gevers]

Hi,

On Mon, 7 Aug 2023 21:29:03 +0200 Samuel Thibault  
wrote:


> It seems that it is crashing because /proc/cpuinfo is empty, and thus
pfmlib_getl never allocates a buffer, and the trailing b[i] = '\0' thus
becomes bogus.

The empty /proc/cpuinfo is reported and being tracked in 1036818.

Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1051123: sensors-detect.8: some notes and editorial fixes for the manual

[Bjarni Ingi Gislason]

Package: lm-sensors
Version: 1:3.6.0-8
Severity: minor
Tags: patch

Dear Maintainer,

here are some remarks and editorial corrections for the man page.

The patch is in the attachment.

-.-

The difference between the formatted outputs can be seen with:

  nroff -man  > 
  nroff -man  > 
  diff -u  

and for groff, using

"printf '%s\n%s\n' '.kern 0' '.ss 12 0' | groff -man -Z - "

instead of "nroff -man"

  Add the option "-t", if the file contains a table.

  Read the output of "diff -u" with "less -R" or similar.

-.-.

  If "man" (man-db) is used to check the manual for warnings,
the following must be set:

  The option "-warnings=w"

  The environmental variable:

export MAN_KEEP_STDERR=yes (or any non-empty value)

  or

  (produce only warnings):

export MANROFFOPT="-ww -z"

export MAN_KEEP_STDERR=yes (or any non-empty value)

-.-

Input file is sensors-detect.8

Change -- in x--y to \(em (em-dash), or, if an
option, to \-\-

7:.I --auto

-.-.

Change a HYPHEN-MINUS (code 0x55, 2D) to a minus (\-), if in front of a
name for an option.

36:.IP "--auto"

-.-.

Wrong distance between sentences.

  Separate the sentences and subordinate clauses; each begins on a new
line.  See man-pages(7) ("Conventions for source file layout") and
"info groff" ("Input Conventions").

  The best procedure is to always start a new sentence on a new line,
at least, if you are typing on a computer.

Remember coding: Only one command ("sentence") on each (logical) line.

E-mail: Easier to quote exactly the relevant lines.

Generally: Easier to edit the sentence.

Patches: Less unaffected text.

Search for two adjacent words is easier, when they belong to the same line,
and the same phrase.

  The amount of space between sentences in the output can then be
controlled with the ".ss" request.

31:his/her wish. This can be useful if a given system has more than one
32:hardware monitoring chip. Some vendors are known to do this, most notably
37:Run in automatic, non-interactive mode. Assume default answers to all
38:questions. Note that this isn't necessarily safe as the internal logic may
39:lead to potentially dangerous probes being attempted. See the WARNING section
45:identify them. This means that it can access chips in a way these chips do
51:guarantee that sensors-detect will not lock or kill a specific system. So,
54:part of your system. Also, it is recommended to not force a detection step

-.-.

The name of a man page is typeset in bold and the section in roman
(see man-pages(7)).

13:or sensors, supported by libsensors(3), or more generally by the lm_sensors
58:sensors(1), libsensors(3)

-.-.

Start a sentence in parenthesis on a new line.

sensors-detect.8:47:damage (a rare case, thankfully.)

-.-.

Additional.

1) No empty line before a macro like 'SH' as it is included in the
macro.  Use a single full stop (.) in the first column to create an
(almost) empty line in the source.

2) "if can't affort" -> "if you can't affort"

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

Kernel: Linux 6.4.11-1 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 (charmap=ISO-8859-1), 
LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages lm-sensors depends on:
ii  libc62.37-7
ii  libsensors5  1:3.6.0-8
ii  perl 5.36.0-7
ii  sed  4.9-1

lm-sensors recommends no packages.

Versions of packages lm-sensors suggests:
pn  fancontrol  
pn  i2c-tools   
pn  read-edid   

-- no debconf information
--- sensors-detect.8	2023-09-03 00:45:12.0 +
+++ sensors-detect.8.new	2023-09-03 03:23:50.0 +
@@ -1,19 +1,21 @@
 .TH SENSORS-DETECT 8 "September 2013" "lm-sensors 3"
 .SH NAME
 sensors-detect \- detect hardware monitoring chips
-
+.
 .SH SYNOPSIS
-.B sensors-detect [
-.I --auto
-.B ]
-
+.BR sensors-detect " ["
+.BR \-\-auto " ]"
+.
 .SH DESCRIPTION
-sensors-detect is an interactive program that will walk you through the
+.B sensors-detect
+is an interactive program that will walk you through the
 process of scanning your system for various hardware monitoring chips,
-or sensors, supported by libsensors(3), or more generally by the lm_sensors
-tool suite.
+or sensors, supported by
+.BR libsensors (3),
+or more generally by the lm_sensors tool suite.
 
-sensors-detect will look for the following devices, in order:
+.B sensors-detect
+will look for the following devices, in order:
 .IP \(bu
 Sensors embedded in CPUs, south bridges and memory controllers.
 .IP \(bu
@@ -24,38 +26,55 @@ Hardware monitoring chips accessed throu
 Hardware monitoring chips reachable over the SMBus or more generally
 any I2C bus on your system.
 .PP
-As the last two detection steps can cause trouble on some systems, they
-are normally not attempted if the second detection step led to the
-discovery of a Super I/O chip with complete hardware monitoring 

Bug#1051122: neomutt integration

[martin f krafft]

Package: t-prot
Version: 3.4-4.1
Severity: wishlist

Please also link the rc file to `/etc/neomuttrc.d` if the directory 
exists.

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

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

Versions of packages t-prot depends on:
ii  debconf [debconf-2.0]   1.5.82
ii  liblocale-gettext-perl  1.07-5
ii  perl5.36.0-7

Versions of packages t-prot recommends:
ii  mutt  2.2.9-1+b1

Versions of packages t-prot suggests:
ii  postfix [mail-transport-agent]  3.8.1-2

-- debconf-show failed


-- 
 .''`.   martin f. krafft 
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
  `-  Debian - when you have better things to do than fixing systems

Bug#998408: "good password" advice in installer is still bad two years after this was reported

[Jonathan Kamens]

Nearly two years after Alejandro Colomar reported this issue, the Debian 
installer is still giving people this bad advice: "A good password will 
contain a mixture of letters, numbers and punctuation and should be 
changed at regular intervals."


Alejandro explained at length why this advice about what's /in/ the 
password is wrong, but he didn't address at all the other, perhaps even 
more significant reason why this is wrong: we now know, absolutely and 
unequivocally, that telling people to change their passwords regularly 
makes security worse rather than better.


I understand that Debian may not be the most security-focused Linux 
distribution, but can we please move Debian forward into the 21st 
Century on this issue, at least, by updating the messaging in the 
installer to give better advice?


Thank you.

Bug#1051121: debian-installer: TrackPad, ThinkPad X1 Carbon 6th Gen., slow and jerky during install

[Jonathan Kamens]

Source: debian-installer
Version: 20230607+deb12u1
Severity: normal

Dear Maintainer,

I recently installed Bookworm on a ThinkPad X1 Carbon 6th Gen. During
the installation the TrackPad was virtually unuseable. If I put my
finger on it and moved it very slowly I could get the pointer to go in
the direction I wanted, but the movement was very slow and
intermittent, e.g., I would move my finger slightly and then have to
wait several seconds for the mouse pointer to move at all in response.
I ended up doing the whole install with the keyboard.

The TrackPad works fine in GNOME now that the install is finished.

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

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

Bug#1051120: debian-installer: can't use YubiKey for secure drive encryption passphrase because enter clears form

[Jonathan Kamens]

Source: debian-installer
Version: 20230607+deb12u1
Severity: normal
Tags: a11y d-i

Dear Maintainer,

I keep my hard drive encryption passphrase in the "second slot" of my
YubiKey, so that I can use a long, random, secure encryption
passphrase. The YubiKey impersonates a USB keyboard, and when I press
its button for 2.5 seconds it simulates typing the passphrase followed
by hitting the Enter key.

On other installers where I use this approach, most notably the Ubuntu
installer, when the YubiKey hits the entire on the first of the two
passphrase entry fields, either it moves the cursor to the second
field, or it tells me the two fields don't match and makes me enter
the second one.

The Debian installer, however, *erases the contents of the first
passphrase field* when the YubiKey sends the Enter.

This means that to configure my encryption passphrase for Debian to
what's in my YubiKey, I had to:

* Take out my phone.
* Open my password manager.
* Search for and find the entry where the passphrase is stored.
* Make it visible in the password manager.
* Laboriously type the 32-character random passphrase character by
  character, hoping that I don't make any mistakes, complicated by the
  fact that there are some ambiguous characters in it.
* Repeat the feat a second time.

What should take a few seconds instead takes several painstaking
minutes.

TLDR The Enter key should not clear the passphrase field that has
already been entered.

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

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

Bug#998408: "good password" advice in installer is still bad two years after this was reported

[Jonathan Kamens]

Oh, I see now that the fact that the installer shouldn't recommend 
changing one's password regularly was also reported previously, in bug 
#868869.


On 9/2/23 22:04, Jonathan Kamens wrote:


Nearly two years after Alejandro Colomar reported this issue, the 
Debian installer is still giving people this bad advice: "A good 
password will contain a mixture of letters, numbers and punctuation 
and should be changed at regular intervals."


Alejandro explained at length why this advice about what's /in/ the 
password is wrong, but he didn't address at all the other, perhaps 
even more significant reason why this is wrong: we now know, 
absolutely and unequivocally, that telling people to change their 
passwords regularly makes security worse rather than better.


I understand that Debian may not be the most security-focused Linux 
distribution, but can we please move Debian forward into the 21st 
Century on this issue, at least, by updating the messaging in the 
installer to give better advice?


Thank you.

Bug#1051119: NM reports fake Wi-Fi BSSIDs

[Marco d'Itri]

Package: network-manager
Version: 1.44.0-1
Severity: important

"nmcli device wifi list" reports obviously fake BSSIDs for all networks 
to which I have not connected to:

IN-USE  BSSID  SSIDMODE   CHAN  RATE   SIGNAL  >
B4:4B:D6:..:..:..  (omitted)   Infra  2 65 Mbit/s  87  >
00:01:02:00:03:90  (omitted)   Infra  2 65 Mbit/s  77  >
00:01:02:00:03:91  WOW FI - FASTWEBInfra  2 65 Mbit/s  77  >
00:01:02:00:03:FD  (omitted)   Infra  2 65 Mbit/s  75  >
*   B4:4B:D6:..:..:..  (omitted)   Infra  3665 Mbit/s  59  >
00:01:02:00:03:B3  (omitted)  461  Infra  2 65 Mbit/s  57  >
00:01:02:00:03:8E  FRITZ!Box 7530 WB   Infra  2 65 Mbit/s  55  >
82:8F:34:..:..:..  Vodafone-WiFi   Infra  3 65 Mbit/s  54  >
00:01:02:00:03:93  TIM-29740309Infra  2 65 Mbit/s  35  >
00:01:02:00:03:96  (omitted)  045  Infra  2 65 Mbit/s  30  >
00:01:02:00:04:AE  Sala da pranzo.v,   Infra  2 65 Mbit/s  27  >
00:01:02:00:04:71  (omitted)   Infra  2 65 Mbit/s  25  >
00:01:02:00:04:BC  (omitted)   Infra  2 65 Mbit/s  25  >
00:01:02:00:04:A1  (omitted)   Infra  2 65 Mbit/s  20  >

(The real BSSIDs and the non-generic SSIDs have been elided for 
paranoia reasons.)

This breaks the Mozilla Location Services API (used, among others, by 
Firefox and Geoclue), which once it sees at least two of these 
00:01:02:00:03:* BSSIDs it will happily geolocate me either in Vietnam 
or (less frequently) in Germany.

I do not believe this to be a kernel issue because "iwlist scanning" 
properly reports the BSSIDs of all networks.


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

Kernel: Linux 6.4.0-2-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=it_IT.utf8, LC_CTYPE=it_IT.utf8 (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 network-manager depends on:
ii  adduser 3.137
ii  dbus [default-dbus-system-bus]  1.14.10-1
ii  dbus-broker [dbus-system-bus]   33-1
ii  libaudit1   1:3.1.1-1
ii  libbluetooth3   5.69-1
ii  libc6   2.37-7
ii  libcurl3-gnutls 8.2.1-2
ii  libglib2.0-02.77.2-1
ii  libgnutls30 3.8.1-4
ii  libjansson4 2.14-2
ii  libmm-glib0 1.20.6-2
ii  libndp0 1.8-1
ii  libnewt0.52 0.52.23-1+b1
ii  libnm0  1.44.0-1
ii  libpsl5 0.21.2-1
ii  libreadline88.2-1.3
ii  libselinux1 3.5-1
ii  libsystemd0 254.1-3
ii  libteamdctl01.31-1
ii  libudev1254.1-3
ii  policykit-1 123-1
ii  polkitd 123-1
ii  udev254.1-3

Versions of packages network-manager recommends:
ii  dnsmasq-base [dnsmasq-base]  2.89-1
ii  libpam-systemd   254.1-3
pn  modemmanager 
ii  ppp  2.4.9-1+1.1+b1
ii  wireless-regdb   2022.06.06-1
ii  wpasupplicant2:2.10-15

Versions of packages network-manager suggests:
ii  iptables   1.8.9-2
pn  libteam-utils  

Versions of packages network-manager is related to:
ii  isc-dhcp-client  4.4.3-P1-2

-- Configuration Files:
/etc/NetworkManager/NetworkManager.conf changed [not included]
/etc/NetworkManager/dispatcher.d/01-ifupdown changed [not included]

-- no debconf information

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#1050814: RFS: qbootctl/0.1.2-1 [ITP] -- utility to control Quacomm A/B boot slots

[Roger Shimizu]

Thanks, Dmitry, for the prompt fix/update!

On Sat, Sep 2, 2023 at 2:09 PM Dmitry Baryshkov  wrote:
>
> On Sat, 2 Sept 2023 at 11:23, Roger Shimizu  wrote:
> > Thanks for your ITP & RFS!
> >
> > Some nitpicking:
> > * debian/README.Debian:
> >   Please add more description, or remove this file.
>
> Ack. I've updated the package  to drop this file (and also to include
> the qbootctl.service file to mark the boot as successful
> automatically).
>
> > * debian/include/scsi/scsi_bsg_ufs.h
> >   This header is not upstreamed yet?
>
> This header comes from the Linux kernel itself. It is a part of uABI.
>
> >   Is it possible to use existing debian packaged header?
>
> Unfortunately, see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1050368

Above ticket is in pending status, so the next upload should fix the issue.
So please update this package accordingly then.

> > * Do you know whether this package works for QCOM LE / LU baseline systems?
>
> Most likely, the Linux kernel API and the bootloader are the same. But
> I don't think anybody tested it with LE / LU.

OK. We can test it easily when it hit Debian archive.

I'll upload it later.
But hope you can also fix the lintian in the future:

W: qbootctl: no-manual-page [usr/bin/qbootctl]
I: qbootctl: package-supports-alternative-init-but-no-init.d-script
[lib/systemd/system/qbootctl.service]
I: qbootctl: systemd-service-file-missing-documentation-key
[lib/systemd/system/qbootctl.service]

Thank you for your contribution to Debian!

Cheers,
Roger

>
> --
> With best wishes
> Dmitry

Bug#1050256: autopkgtest fails on debci

[Michael Biebl]

Control: severity -1 serious

I'm tentatively raising this to RC, mainly to make this issue more 
visible for other maintainers.





OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1050256: autopkgtest fails on debci

[Michael Biebl]

Hi everyone

Am 02.09.23 um 13:09 schrieb Antonio Terceiro:

On Fri, Sep 01, 2023 at 11:13:11PM +, Mathias Gibbens wrote:

   I don't think we have a good understanding of the root cause of this
issue. Initially we thought this was a known upstream issue with all-
but very recent versions of apparmor and a corresponding lxc profile
fix [0]. However, it appears this is a different issue that somehow
depends on the interaction of bookworm's versions of the kernel,
apparmor, and/or lxc.


Nod


   A minimal reproducer is to install bookworm and create a container
with a systemd service using a hardening option like
PrivateNetwork=yes. With the latest bookworm kernel (6.1.38-4), the
service will fail. But, grab a kernel from testing (6.4.11-1) and then
things work -- with no other changes required. I tried the "oldest"
kernel on snapshot.d.o post 6.1 series (6.3.1+1~exp1 [1]) and the
service works properly with that version as well. So, something changed
in the kernel (either upstream or in Debian's packaging) between 6.1
and 6.3 that "unbreaks" services within lxc containers.


Right, these are my findings as well.

I also tested downgrading apparmor to 2.13.6-10 (i.e. the version from 
oldstable) on a bookworm system.


This was also sufficient to unbreak lxc.

So it "looks" like apparmor 3.x makes assumptions about the kernel that 
are not fulfilled by the kernel 6.1.x in bookworm.



   Given that simply installing a newer kernel fixes things, I am
hesitant to start making changes to lxc until we actually understand
what's changed when running the newer kernel and how it's affecting
lxc's behavior.


My main concern is to "stop the bleeding" quickly, so to speak, 
especially/mainly for debci.


I guess we have three options here:
a/ upgrade the kernels to the one from backports as suggested by Antonio
b/ disable apparmor confinement for lxc on debci via some debci specific 
configuration
c/ disable apparmor confinement for lxc in bookworm via a stable upload 
of the lxc package



The MR I proposed is c/, as I don't know how to implement a/ or b/.

That said, I would be fine with a/ and b/ as well, as this would buy us 
time to investigate this issue without being under the pressure of 
causing debci failures.
Those debci failures are hard to debug and I would like to avoid having 
individual maintainers waste time on it.


Do the debci maintainers  / lxc maintainers / release team have any 
preference regarding a/, b/ and c/ ?



Michael



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1051118: RFS: srs-server/5.0.170 [ITP] -- simple, high-efficiency, real-time video server

[nmgchenhaibo]

Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for 
a sponsor for my package "srs-server":  * Package name : srs-server
Version  : 5.0.170Upstream contact : chenhaibo 
https://ossrs.io  * License 
 : Apache, BSD, GPL-2.0, LGPLv2.1 and GPLv2+, MPL-2.0, MIT and 
MulanPSL-2.0  * Vcs  : https://github.com/ossrs/srs.gitSection  
: video The source builds the following binary packages:   srs-server - 
simple, high-efficiency, real-time video server To access further information 
about this package, please visit the following URL:   
https://mentors.debian.net/package/srs-server/ Alternatively, you can download 
the package with 'dget' using this command:   dget -x 
https://mentors.debian.net/debian/pool/main/s/srs-server/srs-server_5.0.170.dsc 
Changes for the initial release:  srs-server (5.0.170) unstable; urgency=medium 
 .* Reintroduce srs-server to Debian.  There are far to many changes 
since srs-server 0.1.0 to mention them  here, see:  
https://github.com/ossrs/srs/blob/develop/trunk/doc/CHANGELOG.md  Many 
features have already been implemented, see:  
https://github.com/ossrs/srs/blob/develop/trunk/doc/Features.md  Many other 
things, such as Performance, Architecture, APIs and so on,  that can be 
found here:  https://github.com/ossrs/srs Regards, --chenhaibo

Bug#1051117: sensors-conf-convert.8: notes and an editorial correction for the man-page

[Bjarni Ingi Gislason]

Package: lm-sensors
Version: 1:3.6.0-8
Severity: minor
Tags: patch

Dear Maintainer,

here are some remarks and an editorial fix for the manual.

The patch is in the attachment.

-.-

The difference between the formatted outputs can be seen with:

  nroff -man  > 
  nroff -man  > 
  diff -u  

and for groff, using

"printf '%s\n%s\n' '.kern 0' '.ss 12 0' | groff -man -Z - "

instead of "nroff -man"

  Add the option "-t", if the file contains a table.

  Read the output of "diff -u" with "less -R" or similar.

-.-.

  If "man" (man-db) is used to check the manual for warnings,
the following must be set:

  The option "-warnings=w"

  The environmental variable:

export MAN_KEEP_STDERR=yes (or any non-empty value)

  or

  (produce only warnings):

export MANROFFOPT="-ww -z"

export MAN_KEEP_STDERR=yes (or any non-empty value)

-.-.

Input file is sensors-conf-convert.8

The name of a man page is typeset in bold and the section in roman
(see man-pages(7)).

24:sensors(1), libsensors(3)

-.-.

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

Kernel: Linux 6.4.11-1 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 (charmap=ISO-8859-1), 
LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages lm-sensors depends on:
ii  libc62.37-7
ii  libsensors5  1:3.6.0-8
ii  perl 5.36.0-7
ii  sed  4.9-1

lm-sensors recommends no packages.

Versions of packages lm-sensors suggests:
pn  fancontrol  
pn  i2c-tools   
pn  read-edid   

-- no debconf information
--- sensors-conf-convert.8	2023-09-03 00:26:57.0 +
+++ sensors-conf-convert.8.new	2023-09-03 00:30:51.0 +
@@ -21,7 +21,8 @@ The old configuration file is read from
 new one is written to the standard output.
 
 .SH SEE ALSO
-sensors(1), libsensors(3)
+.BR sensors (1),
+.BR libsensors (3)
 
 .SH AUTHOR
 Jean Delvare

Bug#1051116: maildrop: depends on libgcc1, which is no longer in the archive

[Vincent Lefevre]

Package: maildrop
Version: 2.9.3-2+b1
Severity: grave
Justification: renders package unusable

maildrop depends on libgcc1, which is no longer in the archive.
This can be checked on

  https://packages.debian.org/en/bullseye/maildrop

which says:

  dep: libgcc1 (>= 1:3.0) [not armel, armhf, i386, mipsel]
  Package not available

This means that some obsolete packages such as libgcc1 cannot be
removed before the upgrade to bookworm.

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

Kernel: Linux 5.10.0-25-amd64 (SMP w/1 CPU thread)
Locale: LANG=POSIX, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages maildrop depends on:
ii  courier-authlib  0.71.1-2
ii  libc62.31-13+deb11u6
ii  libcourier-unicode4  2.1.2-2
ii  libgcc-s1 [libgcc1]  10.2.1-6
ii  libgcc1  1:8.3.0-6
ii  libgdbm6 1.19-2
ii  libpcre3 2:8.39-13
ii  libstdc++6   10.2.1-6

Versions of packages maildrop recommends:
ii  postfix [mail-transport-agent]  3.5.18-0+deb11u1

maildrop suggests no packages.

-- no debconf information

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

Bug#1051115: isaset.8: some remarks and editorial corrections for the man-page

[Bjarni Ingi Gislason]

Package: lm-sensors
Version: 1:3.6.0-8
Severity: minor
Tags: patch

Dear Maintainer,

here are some notes and editorial fixes for the manual

The patch is in the attachment.

-.-

The difference between the formatted outputs can be seen with:

  nroff -man  > 
  nroff -man  > 
  diff -u  

and for groff, using

"printf '%s\n%s\n' '.kern 0' '.ss 12 0' | groff -man -Z - "

instead of "nroff -man"

  Add the option "-t", if the file contains a table.

  Read the output of "diff -u" with "less -R" or similar.

-.-.

  If "man" (man-db) is used to check the manual for warnings,
the following must be set:

  The option "-warnings=w"

  The environmental variable:

export MAN_KEEP_STDERR=yes (or any non-empty value)

  or

  (produce only warnings):

export MANROFFOPT="-ww -z"

export MAN_KEEP_STDERR=yes (or any non-empty value)

-.-.

Use a macro to change to the italic font, instead of \fI, if
possible (see man-pages(7)).
The macros have the italic corrections, but "\c" removes the "\/" part,
which is in the macro.
So "\/" must be added between the italic argument and the "\c" string.

  Or

add the italic corrections.

47:Four options must be provided to isaset. \fIaddrreg\fR contains the
48:ISA address of the address register for the chip to probe; \fIdatareg\fR
55:The \fIaddress\fR and \fIvalue\fR parameters are two integers between
56:0x00 and 0xFF. isaset will write value \fIvalue\fR to address \fIaddress\fR.
57:An optional \fImask\fR can be provided as a fifth parameter, preserving
62:be provided. \fIaddress\fR contains the ISA address of the register to
65:will write value \fIvalue\fR at this address.
66:An optional \fImask\fR can be provided as a third parameter, preserving

-.-.

Change a HYPHEN-MINUS (code 0x55, 2D) to a minus (\-), if in front of a
name for an option.

7:.RB [ -y ]
8:.RB [ -W | -L ]
17:.B -f
18:.RB [ -y ]
19:.RB [ -W | -L ]
31:.B -f
34:.B -y
40:.B -W
43:.B -L

-.-.

Wrong distance between sentences.

  Separate the sentences and subordinate clauses; each begins on a new
line.  See man-pages(7) ("Conventions for source file layout") and
"info groff" ("Input Conventions").

  The best procedure is to always start a new sentence on a new line,
at least, if you are typing on a computer.

Remember coding: Only one command ("sentence") on each (logical) line.

E-mail: Easier to quote exactly the relevant lines.

Generally: Easier to edit the sentence.

Patches: Less unaffected text.

Search for two adjacent words is easier, when they belong to the same line,
and the same phrase.

  The amount of space between sentences in the output can then be
controlled with the ".ss" request.

35:Disable interactive mode. By default, isaset will wait for a confirmation
36:from the user before messing with the ISA bus. When this flag is used, it
37:will perform the operation directly. This is mainly meant to be used in
47:Four options must be provided to isaset. \fIaddrreg\fR contains the
49:contains the address of the data register. Both addresses are integers 
between
50:0x and 0x3FFF. Usually, if the chip's base address is 0x0nn0, the
51:address register is at 0x0nn5 and the data register is at 0x0nn6. The most
56:0x00 and 0xFF. isaset will write value \fIvalue\fR to address \fIaddress\fR.
62:be provided. \fIaddress\fR contains the ISA address of the register to
63:write to; it is an integer between 0x and 0x. Basically, it is
64:the sum of the chip's base address and the chip register's address. isaset
79:Mark D. Studebaker, and the lm_sensors group

-.-.

Rephrase the beginning of a sentence, if it starts with a digit (see
a style manual).

50:0x and 0x3FFF. Usually, if the chip's base address is 0x0nn0, the
56:0x00 and 0xFF. isaset will write value \fIvalue\fR to address \fIaddress\fR.

-.-.

The name of a man page is set in bold type and the section in roman (see
man-pages(7)).

76:i2cset(8), isadump(8)

-.-.

Start a sentence in parenthesis on a new line.

isaset.8:46:.SH OPTIONS (I2C-like access mode)
isaset.8:60:.SH OPTIONS (flat address space mode)

-.-.

Additional.

Name of the command is typeset in bold, see man-pages(7).

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

Kernel: Linux 6.4.11-1 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 (charmap=ISO-8859-1), 
LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages lm-sensors depends on:
ii  libc62.37-7
ii  libsensors5  1:3.6.0-8
ii  perl 5.36.0-7
ii  sed  4.9-1

lm-sensors recommends no packages.

Versions of packages lm-sensors suggests:
pn  fancontrol  
pn  i2c-tools   
pn  read-edid   

-- no debconf information
--- isaset.8	2023-09-02 23:34:19.0 +
+++ isaset.8.new	2023-09-02 23:51:06.0 +
@@ -4,8 +4,8 @@ isaset \- set ISA registers
 
 .SH SYNOPSIS
 .B isaset
-.RB [ -y ]
-.RB [ -W | -L ]
+.RB [ \-y ]

Bug#1051086: general: networking misconfigured and unusable after bookworm upgrade

[Michael Biebl]

Control: reassign -1 network-manager

Am 02.09.23 um 16:51 schrieb D. R. Evans:


[Z:~] nmcli
enp12s0: connected to Wired connection enp11s0(eth0)


It appears you have a connection configuration named "Wired connection 
enp11s0(eth0)" which is applied to enp12s0.
This leads me to believe, that you don't have the connection 
configuration bound to a certain interface and as a result 
NetworkManager will pick the first one that is ready.



You should be able to find the configuration file in 
/etc/NetworkManager/system-connections/ under the above name.


Please attach this file to the bug report.
Or if this file is missing the output of
nmcli connection show Wired\ connection\ enp11s0(eth0)
(use tab completion to get the properly quoted file name)




OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#483677: still outdated

[cacatoes]

Hi,

It seems the current man page (the one provided upstream along with the 
code source) still is outdated.

i.e: `peer_exchange` isn't valid and has been replaced by protocol.pex

I haven't checked thoroughly, but the community has written this:
https://rtorrent-docs.readthedocs.io/en/latest/
and the Github wiki pages also contain some documentation.

So I guess the man page is doomed.

Bug#1051003: libgdbm6: trap divide error in libgdbm.so.6.0.0

[Nicolas Mora]

Hello,

On Fri, 01 Sep 2023 11:13:22 +0200 Schnitzi 
 wrote:


Journal-Output:
Aug 31 18:02:34 xyz dovecot[2451]: auth: Error: auth-worker: Aborted PASSV 
request for x...@xyz.xyz: Worker process died unexpectedly
Aug 31 18:02:34 xyz dovecot[2451]: auth-worker: Fatal: master: 
service(auth-worker): child 118182 killed with signal 8
Aug 31 18:02:34 xyz kernel: traps: auth[118182] trap divide error 
ip:7f7366d16f06 sp:7ffc44386580 error:0 in libgdbm.so.6.0.0[7f7366d12000+a000]



I don't know if the problem comes from gdbm or pam_shield yet. The 
pam_shield package, although orphaned, could be updated. The original 
pam-shield repository is archived [1], but there seems to be a more 
recent fork [2].


Could you test with h0tw1r3's 0.9.7 release [3] if the problem persist? 
If this fixes the problem, then updating pam-shield package would fix 
this issue.


/Nicolas

[1] https://github.com/jtniehof/pam_shield
[2] https://github.com/h0tw1r3/pam_shield
[3] https://github.com/h0tw1r3/pam_shield/releases/tag/0.9.7

Bug#1051114: isadump.8: Some notes and editorial fixes for the manual

[Bjarni Ingi Gislason]

Package: lm-sensors
Version: 1:3.6.0-8
Severity: minor
Tags: patch

Dear Maintainer,

here are some remarks and an editorial patch for the man-page.

The patch is in the attachment.

-.-

The difference between the formatted outputs can be seen with:

  nroff -man  > 
  nroff -man  > 
  diff -u  

and for groff, using

"printf '%s\n%s\n' '.kern 0' '.ss 12 0' | groff -man -Z - "

instead of "nroff -man"

  Add the option "-t", if the file contains a table.

  Read the output of "diff -u" with "less -R" or similar.

-.-.

  If "man" (man-db) is used to check the manual for warnings,
the following must be set:

  The option "-warnings=w"

  The environmental variable:

export MAN_KEEP_STDERR=yes (or any non-empty value)

  or

  (produce only warnings):

export MANROFFOPT="-ww -z"

export MAN_KEEP_STDERR=yes (or any non-empty value)

-.-.

Output from "mandoc -T lint isadump.8":

mandoc: isadump.8:113:81: STYLE: input text line longer than 80 bytes: the 
Debian GNU/Linux...

-.-.

Use a macro to change to the italic font, instead of \fI, if
possible (see man-pages(7)).
The macros have the italic corrections, but "\c" removes the "\/" part,
which is in the macro.
So "\/" must be added between the italic argument and the "\c" string.

53:At least two options must be provided to isadump. \fIaddrreg\fR contains the
54:ISA address of the address register for the chip to probe; \fIdatareg\fR
63:The \fIbank\fR and \fIbankreg\fR parameters are useful on the Winbond chips
65:\fIbank\fR is an integer between 0 and 31, and \fIbankreg\fR is an integer
72:mandatory. \fIaddress\fR contains the ISA address of the chip to probe;
74:If provided, \fIrange\fR is how many bytes should be read (must be a
78:The \fIbank\fR and \fIbankreg\fR parameters are useful on the National
80:\fIbank\fR is an integer between 0 and 31, and \fIbankreg\fR is an integer

-.-.

Change a HYPHEN-MINUS (code 0x55, 2D) to a minus (\-), if in front of a
name for an option.

7:.RB [ -y ]
8:.RB [ -W | -L ]
9:.RB [ "-k V1,V2..." ]
16:.B -f
17:.RB [ -y ]
18:.RB [ -W | -L ]
31:.B -f
34:.B -y
40:.B -k V1,V2...
46:.B -W
49:.B -L
95:isadump -f 0xecc0 16.

-.-.

Wrong distance between sentences.

  Separate the sentences and subordinate clauses; each begins on a new
line.  See man-pages(7) ("Conventions for source file layout") and
"info groff" ("Input Conventions").

  The best procedure is to always start a new sentence on a new line,
at least, if you are typing on a computer.

Remember coding: Only one command ("sentence") on each (logical) line.

E-mail: Easier to quote exactly the relevant lines.

Generally: Easier to edit the sentence.

Patches: Less unaffected text.

Search for two adjacent words is easier, when they belong to the same line,
and the same phrase.

  The amount of space between sentences in the output can then be
controlled with the ".ss" request.

25:bus. It is intended to probe any chip that lives on the ISA bus working with 
an
35:Disable interactive mode. By default, isadump will wait for a confirmation
36:from the user before messing with the ISA bus. When this flag is used, it
37:will perform the operation directly. This is mainly meant to be used in
42:the chip configuration mode. Most Super-I/O chips need this.
53:At least two options must be provided to isadump. \fIaddrreg\fR contains the
55:contains the address of the data register. Both addresses are integers 
between
56:0x and 0x3FFF. Usually, if the chip's base address is 0x0nn0, the
57:address register is at 0x0nn5 and the data register is at 0x0nn6. The most
67:for Super-I/O chips). The W83781D datasheet has more information on bank
72:mandatory. \fIaddress\fR contains the ISA address of the chip to probe;
75:multiple of 16). If the range isn't provided, it defaults to 256 bytes
82:range). See the PC87365 datasheet for more information on bank selection.
89:Dumping Super-I/O chips is typically a two-step process. First, you will have
92:This will select logical device 9 (correct value depend on the chip). At 0x60
96:This will dump the logical device registers. The correct range depends on
109:Frodo Looijaard, Mark D. Studebaker, and the lm_sensors group
113:the Debian GNU/Linux system. It was then reviewed and augmented by the 
lm_sensors

-.-.

Split lines longer than 80 characters into two or more lines.
Appropriate break points are the end of a sentence and a subordinate
clause; after punctuation marks.

isadump.8: line 113 length 81
the Debian GNU/Linux system. It was then reviewed and augmented by the 
lm_sensors

-.-.

Rephrase the beginning of a sentence, if it starts with a digit (see
a style manual).

56:0x and 0x3FFF. Usually, if the chip's base address is 0x0nn0, the

-.-.

The name of a man page is set in bold type and the section in roman (see
man-pages(7)).

106:i2cdump(8), isaset(8)

-.-.

Start a sentence in parenthesis on a new line.

isadump.8:26:address register and a data register (I2C-like access) or a flat 
range (of up
isadump.8:92:This 

Bug#1041508: tex-common: fmutil fails to rebuild formats

[Joerg Dorchain]

On Sat, Sep 02, 2023 at 10:06:54PM +0900, Norbert Preining wrote:
> 
> That file is buggy:
> 
>  \HINTstream0 %main text
>  \HINTstream\footins   
>\HINTsetstream\topins = %topinsert 
> -prefered 0
> +preferred 0
>{% 
>  \HINTafter = {}
>}
>\HINTsetstream\footins =%footnotes
> -prefered 255
> +preferred 255
>  ratio 0
>{%
>  \hsize=300pt
> 
> 
> The "prefered" needs to be changed to "preferred", then it works.

Confirmed.

Thank you for the quick fix/workaround.

Bye,

Joerg

Bug#1051113: firmware-linux: nouveau driver is showing errors in dmesg because of the outdated firmware

[Islam Bahnasy]

Package: firmware-linux
Version: 20230210-5
Severity: normal
X-Debbugs-Cc: ibahn...@proton.me

Dear Maintainer,

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

   * What led up to the situation?
dmesg is showing lots of nouveau errors:
[2.167271] nouveau :59:00.0: sec2: unhandled intr
0010
[2.204943] nouveau :59:00.0: DRM: VRAM: 2048 MiB
[2.204947] nouveau :59:00.0: DRM: GART: 536870912 MiB
[2.204951] nouveau :59:00.0: DRM: BIT table 'A' not
found
[2.204954] nouveau :59:00.0: DRM: BIT table 'L' not
found
[2.204956] nouveau :59:00.0: DRM: Pointer to TMDS table
not found
[2.204959] nouveau :59:00.0: DRM: DCB version 4.1
[2.207126] nouveau :59:00.0: DRM: MM: using COPY for
buffer copies
[2.207500] [drm] Initialized nouveau 1.3.1 20120801 for
:59:00.0 on minor 0
[   11.726815] nouveau :59:00.0: sec2: unhandled intr
0010
[   21.402157] nouveau :59:00.0: sec2: unhandled intr
0010
[   24.556318] nouveau :59:00.0: sec2: cmdq: timeout
waiting for queue ready
[   24.556335] nouveau :59:00.0: gr: init failed, -110
[   24.556360] nouveau :59:00.0: gr: fecs falcon already
acquired by gr!
[   24.556368] nouveau :59:00.0: gr: init failed, -16
[   24.585814] nouveau :59:00.0: gr: fecs falcon already
acquired by gr!
[   24.585819] nouveau :59:00.0: gr: init failed, -16
[   24.639802] nouveau :59:00.0: gr: fecs falcon already
acquired by gr!
[   24.639810] nouveau :59:00.0: gr: init failed, -16
[   24.673458] nouveau :59:00.0: gr: fecs falcon already
acquired by gr!
[   24.673466] nouveau :59:00.0: gr: init failed, -16
[   25.186063] nouveau :59:00.0: gr: fecs falcon already
acquired by gr!
[   25.186074] nouveau :59:00.0: gr: init failed, -16
[   25.217454] nouveau :59:00.0: gr: fecs falcon already
acquired by gr!
[   25.217464] nouveau :59:00.0: gr: init failed, -16
[  338.682054] nouveau :59:00.0: sec2: unhandled intr
0010
[  339.692460] nouveau :59:00.0: sec2: cmdq: timeout
waiting for queue ready
[  339.692474] nouveau :59:00.0: gr: init failed, -110
[  339.714536] nouveau :59:00.0: gr: fecs falcon already
acquired by gr!
[  339.714548] nouveau :59:00.0: gr: init failed, -16
[  339.762679] nouveau :59:00.0: gr: fecs falcon already
acquired by gr!
[  339.762684] nouveau :59:00.0: gr: init failed, -16
[  339.805312] nouveau :59:00.0: gr: fecs falcon already
acquired by gr!
[  339.805326] nouveau :59:00.0: gr: init failed, -16
[  340.615135] nouveau :59:00.0: gr: fecs falcon already
acquired by gr!
[  340.615141] nouveau :59:00.0: gr: init failed, -16
[  341.089123] nouveau :59:00.0: gr: fecs falcon already
acquired by gr!
[  341.089131] nouveau :59:00.0: gr: init failed, -16
[  341.121477] nouveau :59:00.0: gr: fecs falcon already
acquired by gr!
[  341.121483] nouveau :59:00.0: gr: init failed, -16
[ 1986.261705] nouveau :59:00.0: sec2: unhandled intr
0010
[ 1987.367790] nouveau :59:00.0: sec2: cmdq: timeout
waiting for queue ready
[ 1987.367808] nouveau :59:00.0: gr: init failed, -110
[ 1987.399021] nouveau :59:00.0: gr: fecs falcon already
acquired by gr!
[ 1987.399025] nouveau :59:00.0: gr: init failed, -16
[ 1987.946867] nouveau :59:00.0: gr: fecs falcon already
acquired by gr!
[ 1987.946873] nouveau :59:00.0: gr: init failed, -16
[ 1987.975781] nouveau :59:00.0: gr: fecs falcon already
acquired by gr!
[ 1987.975786] nouveau :59:00.0: gr: init failed, -16
[ 1988.065128] nouveau :59:00.0: gr: fecs falcon already
acquired by gr!
[ 1988.065133] nouveau :59:00.0: gr: init failed, -16
[ 1988.120611] nouveau :59:00.0: gr: fecs falcon already
acquired by gr!
[ 1988.120617] nouveau :59:00.0: gr: init failed, -16
[ 1988.152657] nouveau :59:00.0: gr: fecs falcon already
acquired by gr!
[ 1988.152665] nouveau :59:00.0: gr: init failed, -16
[ 1988.220397] nouveau :59:00.0: gr: fecs falcon already
acquired by gr!
[ 

Bug#1051112: planetblupi: FTBFS: /usr/bin/ld: /usr/lib/riscv64-linux-gnu/libSDL_kitchensink.so: undefined reference to `av_register_all'

[Aurelien Jarno]

Source: planetblupi
Version: 1.14.2-3
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

Dear maintainer,

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

| [100%] Linking CXX executable planetblupi
| /usr/bin/cmake -E cmake_link_script CMakeFiles/planetblupi.dir/link.txt 
--verbose=1
| /usr/bin/c++ -g -O2 -ffile-prefix-map=/<>=. 
-fstack-protector-strong -fstack-clash-protection -Wformat 
-Werror=format-security -fcf-protection -Wdate-time -D_FORTIFY_SOURCE=2 -Wall 
-std=c++11 -L/usr/lib -Wl,-z,relro -rdynamic 
CMakeFiles/planetblupi.dir/src/action.cxx.o 
CMakeFiles/planetblupi.dir/src/blupi.cxx.o 
CMakeFiles/planetblupi.dir/src/button.cxx.o 
CMakeFiles/planetblupi.dir/src/decblupi.cxx.o 
CMakeFiles/planetblupi.dir/src/decgoal.cxx.o 
CMakeFiles/planetblupi.dir/src/decio.cxx.o 
CMakeFiles/planetblupi.dir/src/decmap.cxx.o 
CMakeFiles/planetblupi.dir/src/decmove.cxx.o 
CMakeFiles/planetblupi.dir/src/decor.cxx.o 
CMakeFiles/planetblupi.dir/src/decstat.cxx.o 
CMakeFiles/planetblupi.dir/src/display.cxx.o 
CMakeFiles/planetblupi.dir/src/event.cxx.o 
CMakeFiles/planetblupi.dir/src/fifo.cxx.o 
CMakeFiles/planetblupi.dir/src/fix.cxx.o 
CMakeFiles/planetblupi.dir/src/fog.cxx.o 
CMakeFiles/planetblupi.dir/src/menu.cxx.o 
CMakeFiles/planetblupi.dir/src/misc.cxx.o 
CMakeFiles/planetblupi.dir/src/movie.cxx.o 
CMakeFiles/planetblupi.dir/src/obstacle.cxx.o 
CMakeFiles/planetblupi.dir/src/path.cxx.o 
CMakeFiles/planetblupi.dir/src/pixmap.cxx.o 
CMakeFiles/planetblupi.dir/src/platform/platform_sdl.cxx.o 
CMakeFiles/planetblupi.dir/src/progress.cxx.o 
CMakeFiles/planetblupi.dir/src/sound.cxx.o 
CMakeFiles/planetblupi.dir/src/text.cxx.o -o planetblupi  -lSDL2 -lSDL2_mixer 
-lSDL2 -lSDL2_image -lSDL2 -lSDL_kitchensink -lpthread -lSDL2_mixer 
-lSDL2_image -lSDL_kitchensink -lpthread 
| /usr/bin/ld: 
/usr/lib/gcc/x86_64-linux-gnu/13/../../../x86_64-linux-gnu/libSDL_kitchensink.so:
 undefined reference to `av_register_all'
| collect2: error: ld returned 1 exit status
| make[3]: *** [CMakeFiles/planetblupi.dir/build.make:486: planetblupi] Error 1
| make[3]: Leaving directory '/<>/obj-x86_64-linux-gnu'
| make[2]: *** [CMakeFiles/Makefile2:116: CMakeFiles/planetblupi.dir/all] Error 
2
| make[2]: Leaving directory '/<>/obj-x86_64-linux-gnu'
| make[1]: *** [Makefile:139: all] Error 2
| make[1]: Leaving directory '/<>/obj-x86_64-linux-gnu'
| dh_auto_build: error: cd obj-x86_64-linux-gnu && make -j12 "INSTALL=install 
--strip-program=true" VERBOSE=1 returned exit code 2
| make: *** [debian/rules:4: binary-arch] Error 25
| dpkg-buildpackage: error: debian/rules binary-arch subprocess returned exit 
status 2

A full build log on riscv64 is also available:
https://buildd.debian.org/status/fetch.php?pkg=planetblupi=riscv64=1.14.2-3=1693633255=0

Regards
Aurelien 

Bug#1051111: notmuch: FTBFS: 6 tests failed.

[Aurelien Jarno]

Source: notmuch
Version: 0.37-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

Dear maintainer,

notmuch fails to build from source due to testsuite issues. From my
build log on amd64:
| 
|   make -j12 test "TESTSUITEFLAGS=-j12 --verbose" VERBOSE=1
| make[1]: Entering directory '/<>'
| Use "make V=1" to see the verbose compile lines.
| CC -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 
-ffile-prefix-map=/<>=. -fstack-protector-strong 
-fstack-clash-protection -Wformat -Werror=format-security -fcf-protection 
test/arg-test.o
| CC -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 
-ffile-prefix-map=/<>=. -fstack-protector-strong 
-fstack-clash-protection -Wformat -Werror=format-security -fcf-protection 
test/hex-xcode.o
| CC -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 
-ffile-prefix-map=/<>=. -fstack-protector-strong 
-fstack-clash-protection -Wformat -Werror=format-security -fcf-protection 
test/random-corpus.o
| CC -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 
-ffile-prefix-map=/<>=. -fstack-protector-strong 
-fstack-clash-protection -Wformat -Werror=format-security -fcf-protection 
test/database-test.o
| CC -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 
-ffile-prefix-map=/<>=. -fstack-protector-strong 
-fstack-clash-protection -Wformat -Werror=format-security -fcf-protection 
test/parse-time.o
| CC -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 
-ffile-prefix-map=/<>=. -fstack-protector-strong 
-fstack-clash-protection -Wformat -Werror=format-security -fcf-protection 
test/smtp-dummy.o
| CXX -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 
-ffile-prefix-map=/<>=. -fstack-protector-strong 
-fstack-clash-protection -Wformat -Werror=format-security -fcf-protection 
test/symbol-test.o
| CXX -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 
-ffile-prefix-map=/<>=. -fstack-protector-strong 
-fstack-clash-protection -Wformat -Werror=format-security -fcf-protection 
test/make-db-version.o
| CXX -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 
-ffile-prefix-map=/<>=. -fstack-protector-strong 
-fstack-clash-protection -Wformat -Werror=format-security -fcf-protection 
test/ghost-report.o
| CC -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 
-ffile-prefix-map=/<>=. -fstack-protector-strong 
-fstack-clash-protection -Wformat -Werror=format-security -fcf-protection 
test/message-id-parse.o
| CC test/arg-test
| CC test/parse-time
| CC test/smtp-dummy
| CC test/hex-xcode
| CC test/message-id-parse
| CXX test/random-corpus
| CXX test/symbol-test
| CXX test/make-db-version
| CXX test/ghost-report
| Use "make V=1" to see the details for passing and known broken tests.
| INFO: using 2m timeout for tests
| 
| T030-config: Testing "notmuch config"
|  BROKEN Round trip config item with leading spaces
|  BROKEN Round trip config item with leading tab
| 
| T040-setup: Testing "notmuch setup"
|  FAIL   Create a new config interactively
|   --- T040-setup.2.config-with-comments   2023-09-01 08:05:51.105192140 
+
|   +++ T040-setup.2.new-notmuch-config 2023-09-01 08:05:51.105192140 
+
|   @@ -1,7 +1,3 @@
|   -# .notmuch-config - Configuration file for the notmuch mail system
|   -#
|   -# For more information about notmuch, see https://notmuchmail.org
|   -
|# Database configuration
|#
|# The only value supported here is 'path' which should be the top-level
|   @@ -12,7 +8,6 @@
|#
|[database]
|path=/path/to/maildir
|   -
|# User configuration
|#
|# Here is where you can let notmuch know how you would like to be
|   @@ -32,7 +27,6 @@
|name=Test Suite
|primary_email=test.su...@example.com
|other_email=another.su...@example.com
|   -
|# Configuration for "notmuch new"
|#
|# The following options are supported here:
|   @@ -49,7 +43,6 @@
|#
|[new]
|tags=foo;bar;
|   -
|# Search configuration
|#
|# The following option is supported here:
|   @@ -61,7 +54,6 @@
|#
|[search]
|exclude_tags=baz
|   -
|# Maildir compatibility configuration
|#
|# The following option is supported here:
| 
| T050-new: Testing "notmuch new" in several variations
|  BROKEN RFC822 group names are indexed
|  BROKEN Long directory names don't cause rescan
| add_file: A Xapian exception occurred
| A Xapian exception occurred finding/creating a directory: Term too long (> 
245): 
XDDIRENTRY2:zz.
| Note: A fatal error was encountered: A Xapian exception occurred
| add_file: A Xapian exception occurred
| A Xapian exception occurred finding/creating a directory: Term too long (> 
245): 

Bug#1051110: kimageformats: FTBFS: CMake Error at /usr/lib/x86_64-linux-gnu/cmake/Imath/ImathTargets.cmake:115

[Aurelien Jarno]

Source: kimageformats
Version: 5.107.0-3
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

Dear maintainer,

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

| -- Performing Test BSYMBOLICFUNCTIONS_AVAILABLE - Success
| -- Could not set up the appstream test. appstreamcli is missing.
| -- Found PkgConfig: /usr/bin/pkg-config (found version "1.8.1") 
| CMake Error at /usr/lib/x86_64-linux-gnu/cmake/Imath/ImathTargets.cmake:115 
(message):
|   The imported target "Imath::PyImath_Python3_11" references the file
| 
|  "/usr/lib/x86_64-linux-gnu/libPyImath_Python3_11-3_1.so.29.8.0"
| 
|   but this file does not exist.  Possible reasons include:
| 
|   * The file was deleted, renamed, or moved to another location.
| 
|   * An install or uninstall procedure did not complete successfully.
| 
|   * The installation package was faulty and contained
| 
|  "/usr/lib/x86_64-linux-gnu/cmake/Imath/ImathTargets.cmake"
| 
|   but not all the files it references.
| 
| Call Stack (most recent call first):
|   /usr/lib/x86_64-linux-gnu/cmake/Imath/ImathConfig.cmake:40 (include)
|   /usr/share/cmake-3.27/Modules/CMakeFindDependencyMacro.cmake:76 
(find_package)
|   /usr/lib/x86_64-linux-gnu/cmake/OpenEXR/OpenEXRConfig.cmake:47 
(find_dependency)
|   CMakeLists.txt:45 (find_package)
| 
| 
| -- Configuring incomplete, errors occurred!

A full build log on riscv64 is also available:
https://buildd.debian.org/status/fetch.php?pkg=kimageformats=riscv64=5.107.0-3=1693586471=0

It seems there is a missing build-dependency on python3-imath.

Regards
Aurelien

Bug#1041508: tex-common: fmutil fails to rebuild formats

[Preuße]

Control: block -1 by 1050807

On 02.09.2023 07:57, Emmanuel Charpentier wrote:

Hi,


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

* What led up to the situation?

routine upgrade of testing's tex-common

* What exactly did you do (or not do) that was effective (or
  ineffective)?



I guess you run Debian testing right?

The texlive-binaries recently migrated to testing, but the 
texlive-base/texlive-extra/texlive-lang did not due to #1050807. 
Therefore the fix for this issue did not enter testing yet.


Sorry, for the trouble, I should have added a "Breaks" statement to 
texlive-binaries. Maybe it makes sense to do that now?


Hilmar
--
sigfault



OpenPGP_signature
Description: OpenPGP digital signature

Bug#802539: closed by Julien Cristau (Re: Bug#802539: Please properly configure HTTPS in security.debian.org)

[Mario Xerxes Castelán Castro «Ksenia»]

I filled this bug when I was a kid. In the time it took you to do 
anything about this, I became an adult. You suck.

Bug#1051103: netatalk: Unknown error: 211 from macOS when trying to mount in 3.1.15~ds-2 or later

[Daniel Markstedt]

--- Original Message ---
On Saturday, September 2nd, 2023 at 12:18 PM, David Gilman 
 wrote:


>
>
> Package: netatalk
> Version: 3.1.15~ds-2
> Severity: important
> X-Debbugs-Cc: davidgilm...@gmail.com
>
> Dear Maintainer,
>
> After the update from 3.1.15~ds-1 to 3.1.15~ds-2 any attempt to mount an
> exported AFP share from macOS results in "Unknown error: 211" on the Mac
> side. This was not fixed in 3.1.15~ds-3.
>
> I was able to confirm the regression by downgrading from -3 to -2 to -1
> on the same setup to find that it was working on -1 and not -2.
>
> Note that my Debian side configuration is a bit of a monster, I am
> pinning netatalk from sid, but am otherwise on bookworm. The Mac is
> running macOS 13.5.1.
>
> I have attached some hopefully relevant system logs from the Mac.
>

Hi David,

Thank you for reporting the issue! I cannot reproduce the issue despite having 
the exact same environment (Bookworm pinned to Sid netatalk, macOS 13.5.1) so 
please help me work through a few troubleshooting steps.

Reading the changelog between ds-1 and ds-2, the only obvious functional 
difference is that we did away with the pam.d configuration override. I 
shouldn't have made a difference but you never know.

To understand what's happening on the netatalk side when macOS throws that 
error, would you be able to turn on debug level logs, and then capture syslog 
as the error is happening? That's the only sure way to know exactly what it 
gets hung on up.

For this purpose, please add or modify the log level line of the Global section 
of /etc/netatalk/afp.conf as per the below and then restart netatalk.

log level = default:debug

Also, it would be handy to know the contents of your /etc/netatalk/afp.conf and 
/etc/pam.d/netatalk files. Please scrub any private information as needed.

Sincerely,
Daniel

Bug#1050814: RFS: qbootctl/0.1.2-1 [ITP] -- utility to control Quacomm A/B boot slots

[Dmitry Baryshkov]

On Sat, 2 Sept 2023 at 11:23, Roger Shimizu  wrote:
> Thanks for your ITP & RFS!
>
> Some nitpicking:
> * debian/README.Debian:
>   Please add more description, or remove this file.

Ack. I've updated the package  to drop this file (and also to include
the qbootctl.service file to mark the boot as successful
automatically).

> * debian/include/scsi/scsi_bsg_ufs.h
>   This header is not upstreamed yet?

This header comes from the Linux kernel itself. It is a part of uABI.

>   Is it possible to use existing debian packaged header?

Unfortunately, see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1050368

> * Do you know whether this package works for QCOM LE / LU baseline systems?

Most likely, the Linux kernel API and the bootloader are the same. But
I don't think anybody tested it with LE / LU.

-- 
With best wishes
Dmitry

Bug#1051109: gtkpod: Intent to request removal from Debian

[Jeremy Bícha]

Source: gtkpod
Version: 2.1.5-10
Severity: serious

I intend to request removal of gtkpod from Debian soon. I no longer
wish for Anjuta to be included in Debian; there are much better
alternatives such as GNOME Builder. However, gtkpod uses libanjuta so
gtkpod is interfering with my being able to remove Anjuta from Debian.

Here are a list of select important bugs:
https://bugs.debian.org/993375
https://bugs.debian.org/1018127
https://bugs.debian.org/1018853

Thank you,
Jeremy Bícha

Bug#1051068: sysprof: Should mark test build dependencies as

[Jeremy Bícha]

Control: tags -1 moreinfo

On Sat, Sep 2, 2023 at 2:06 AM John Paul Adrian Glaubitz
 wrote:
> src:sysprof has multiple build dependencies in debian/control which are
> required for running the testsuite only but yet these build dependencies
> are not marked as  to allow the package to be bootstrapped on
> a new architecture.

I was unable to identify any build dependencies like that. Please
submit a merge proposal if you have specific improvements in mind.

Thank you,
Jeremy Bícha

Bug#1051108: anjuta: FTBFS: 1 failed unexpectedly

[Aurelien Jarno]

Source: anjuta
Version: 2:3.34.0-8
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

Dear maintainer,

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

| x - created directory gnucash/src/gnome-utils/test.
| x - extracting gnucash/src/gnome-utils/test/Makefile.am (text)
| x - removed lock directory _sh32349.
| ./gnucash.at:6: $abs_builddir/../projectparser --no-id -o output load gnucash 
\
|list
| 
/<>/plugins/am-project/tests/testsuite.dir/at-groups/10/test-source:
 line 1862: 2401173 Bus error   (core dumped) ( $at_check_trace; 
$abs_builddir/../projectparser --no-id -o output load empty12 move empty13 set 
0:2 instdir 'bindir' list save ) >> "$at_stdout" 2>> "$at_stderr" 5>&-
| stderr:
| stdout:
| ./properties.at:488: exit code was 135, expected 0
| 10. properties.at:1:  FAILED (properties.at:488)
| stderr:
| stdout:
| ./gnucash.at:8: diff -b output $srcdir/gnucash.lst
| 19. gnucash.at:1:  ok
| 
| ## - ##
| ## Test results. ##
| ## - ##
| 
| ERROR: All 19 tests were run,
| 1 failed unexpectedly.
| ## -- ##
| ## testsuite.log was created. ##
| ## -- ##
| 
| Please send `plugins/am-project/tests/testsuite.log' and all information you 
think might help:
| 
|To: 
|Subject: [Anjuta 3.34.0] testsuite: 10 failed
| 
| You may investigate any problem if you feel able to do so, in which
| case the test suite provides a good starting point.  Its output may
| be found below `plugins/am-project/tests/testsuite.dir'.
| 
| make[5]: *** [Makefile:636: check-local] Error 1
| make[5]: Leaving directory '/<>/plugins/am-project/tests'
| make[4]: *** [Makefile:498: check-am] Error 2
| make[4]: Leaving directory '/<>/plugins/am-project/tests'
| make[3]: *** [Makefile:1212: check-recursive] Error 1
| make[3]: Leaving directory '/<>/plugins/am-project'
| make[2]: *** [Makefile:527: check-recursive] Error 1
| make[2]: Leaving directory '/<>/plugins'
| make[1]: *** [Makefile:699: check-recursive] Error 1
| make[1]: Leaving directory '/<>'
| dh_auto_test: error: make -j12 check "TESTSUITEFLAGS=-j12 --verbose" 
VERBOSE=1 returned exit code 2
| make: *** [debian/rules:12: build-arch] Error 25
| dpkg-buildpackage: error: debian/rules build-arch subprocess returned exit 
status 2

A full build log on riscv64 is also available:
https://buildd.debian.org/status/fetch.php?pkg=anjuta=riscv64=2%3A3.34.0-8=1693376704=0

Regards
Aurelien

Bug#1051107: cog: FTBFS: ERROR: Dependency "epoxy" not found, tried pkgconfig

[Aurelien Jarno]

Source: cog
Version: 0.18.0-2
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

Dear maintainer,

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

| Run-time dependency libsoup-3.0 found: YES 3.4.2
| Run-time dependency wpe-1.0 found: YES 1.14.0
| Run-time dependency manette-0.2 found: YES 0.2.6
| Configuring cog-config.h using configuration
| Run-time dependency wpebackend-fdo-1.0 found: YES 1.14.2
| Run-time dependency epoxy found: NO (tried pkgconfig)
| 
| ../platform/common/meson.build:3:4: ERROR: Dependency "epoxy" not found, 
tried pkgconfig
| 
| A full log can be found at 
/<>/obj-x86_64-linux-gnu/meson-logs/meson-log.txt
|   cd obj-x86_64-linux-gnu && tail -v -n \+0 meson-logs/meson-log.txt
| ==> meson-logs/meson-log.txt <==
| Build started at 2023-09-02T20:09:58.358110

...

| Called: `/usr/bin/pkg-config --modversion epoxy` -> 1
| stderr:
| Package epoxy was not found in the pkg-config search path.
| Perhaps you should add the directory containing `epoxy.pc'
| to the PKG_CONFIG_PATH environment variable
| Package 'epoxy', required by 'virtual:world', not found
| ---
| CMake binary for 1 is cached as not found
| Dependency lookup for epoxy with method 'cmake' failed: CMake binary for 
machine 1 not found. Giving up.
| Run-time dependency epoxy found: NO (tried pkgconfig)
| 
| ../platform/common/meson.build:3:4: ERROR: Dependency "epoxy" not found, 
tried pkgconfig
| dh_auto_configure: error: cd obj-x86_64-linux-gnu && 
DEB_PYTHON_INSTALL_LAYOUT=deb LC_ALL=C.UTF-8 meson setup .. 
--wrap-mode=nodownload --buildtype=plain --prefix=/usr --sysconfdir=/etc 
--localstatedir=/var --libdir=lib/x86_64-linux-gnu -Dpython.bytecompile=-1 
returned exit code 1
| make: *** [debian/rules:6: binary-arch] Error 25
| dpkg-buildpackage: error: debian/rules binary-arch subprocess returned exit 
status 2

A full build log on riscv64 is also available:
https://buildd.debian.org/status/fetch.php?pkg=cog=riscv64=0.18.0-2=1693678320=0

Regards
Aurelien

Bug#1051106: libsdl1.2debian: Mark of the Ninja - Failure to render anything but a black screen

[Antoine Le Gonidec]

Package: libsdl1.2debian
Version: 1.2.64-5
Severity: normal
Tags: upstream

Initially reported on ./play.it forge[1], this has been triggered using the 
Linux build of Mark of the Ninja that used to be provided by Humble Bundle 
(markoftheninja_linux38_1380755375.zip).

[1]: https://forge.dotslashplay.it/play.it/games/-/issues/895

When using sdl12-compat to provide libSDL-1.2.so.0, the game fails to render 
anything but a black screen.

Ambient music can be heard in the background and the menu can be navigated 
using the keyboard (navigation sound effects are played as expected), so I 
guess this can be narrowed down to a rendering failure.

This does not happen when using a real libSDL-1.2.so.0, then the game menu is 
rendered with no problem.

This is not limited to the menu: I can blindly start a game and try moving 
around the character, then I hear the footsteps sound effect. Meanwhile the 
screen is still black.

Upstream bug report: https://github.com/libsdl-org/sdl12-compat/issues/315

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

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

Versions of packages libsdl1.2debian depends on:
ii  libc6  2.37-7
ii  libsdl2-2.0-0  2.28.3+dfsg-1

libsdl1.2debian recommends no packages.

libsdl1.2debian suggests no packages.

-- no debconf information

Bug#1051105: libx11-6: Segfault in libX11.so.6.4.0 when opening video with vlc player

[ardb]

Package: libx11-6
Version: 2:1.8.4-2+deb12u1
Severity: important
X-Debbugs-Cc: a...@interia.eu

It seems to happen with any mp4, mkv file.
System log:

Sep 02 21:38:11 hebel vlc[17577]: [7f1ef40049a0] gl gl: Initialized 
libplacebo v5.264.1 (API v264)
Sep 02 21:38:11 hebel vlc[17577]: libva info: VA-API version 1.17.0
Sep 02 21:38:11 hebel vlc[17577]: libva error: vaGetDriverNameByIndex() failed 
with unknown libva error, driver_name = (null)
Sep 02 21:38:11 hebel vlc[17577]: [7f1ef40049a0] glconv_vaapi_x11 gl error: 
vaInitialize: unknown libva error
Sep 02 21:38:11 hebel vlc[17577]: libva info: VA-API version 1.17.0
Sep 02 21:38:11 hebel vlc[17577]: libva info: Trying to open 
/usr/lib/x86_64-linux-gnu/dri/nvidia_drv_video.so
Sep 02 21:38:11 hebel vlc[17577]: libva info: Found init function 
__vaDriverInit_1_0
Sep 02 21:38:11 hebel kernel: av:h264:df0[17691]: segfault at d8 ip 
7f1f6b7862e0 sp 7f1efb72f188 error 4 in 
libX11.so.6.4.0[7f1f6b77+8b000] likely on CPU 0 (core 0, socket 0)
Sep 02 21:38:11 hebel kernel: Code: 2e 0f 1f 84 00 00 00 00 00 90 8b 47 1c c3 
66 66 2e 0f 1f 84 00 00 00 00 00 90 8b 47 74 c3 66 66 2e 0f 1f 84 00 00 00 00 
00 90 <48> 8b 87 d8 00 00 00 c3 0f 1f 84 00 00 00 00 00 48 63 f6 48 c1 e6


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

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

Versions of packages libx11-6 depends on:
ii  libc62.36-9+deb12u1
ii  libx11-data  2:1.8.4-2+deb12u1
ii  libxcb1  1.15-1

libx11-6 recommends no packages.

libx11-6 suggests no packages.

-- no debconf information

Bug#1051104: sysprof: Building with profile "pkg.sysprof.nogui" results in FTBFS

[John Paul Adrian Glaubitz]

Source: sysprof
Version: 45~rc-1
Severity: important

Hello!

Trying to build src:sysprof with the "pkg.sysprof.nogui" profile FTBFS with:

Run-time dependency glib-2.0 found: YES 2.77.2
Run-time dependency gio-2.0 found: YES 2.77.2
Run-time dependency gio-unix-2.0 found: YES 2.77.2
Did not find CMake 'cmake'
Found CMake: NO
Run-time dependency gtk4 found: NO (tried pkgconfig)

../meson.build:64:10: ERROR: Dependency "gtk4" not found, tried pkgconfig

A full log can be found at 
/<>/obj-x86_64-linux-gnu/meson-logs/meson-log.txt
cd obj-x86_64-linux-gnu && tail -v -n \+0 meson-logs/meson-log.txt

This means that breaking the gtk4 <=> sysprof build dependency circle is
currently not possible preventing a successful bootstrap of gtk4 on new
architectures such as loong64.

Thanks,
Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#1051103: netatalk: Unknown error: 211 from macOS when trying to mount in 3.1.15~ds-2 or later

[David Gilman]

Package: netatalk
Version: 3.1.15~ds-2
Severity: important
X-Debbugs-Cc: davidgilm...@gmail.com

Dear Maintainer,

After the update from 3.1.15~ds-1 to 3.1.15~ds-2 any attempt to mount an
exported AFP share from macOS results in "Unknown error: 211" on the Mac
side. This was not fixed in 3.1.15~ds-3.

I was able to confirm the regression by downgrading from -3 to -2 to -1
on the same setup to find that it was working on -1 and not -2.

Note that my Debian side configuration is a bit of a monster, I am
pinning netatalk from sid, but am otherwise on bookworm. The Mac is
running macOS 13.5.1.

I have attached some hopefully relevant system logs from the Mac.

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

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

Versions of packages netatalk depends on:
ii  init-system-helpers  1.65.2
ii  libacl1  2.3.1-3
ii  libavahi-client3 0.8-10
ii  libavahi-common3 0.8-10
ii  libc62.36-9+deb12u1
ii  libcrack22.9.6-5+b1
ii  libcrypt11:4.4.33-2
ii  libdb5.3 5.3.28+dfsg2-1
ii  libdbus-glib-1-2 0.112-3
ii  libevent-2.1-7   2.1.12-stable-8
ii  libgcrypt20  1.10.1-3
ii  libglib2.0-0 2.74.6-2
ii  libgssapi-krb5-2 1.20.1-2
ii  libkrb5-31.20.1-2
ii  libldap-2.5-02.5.13+dfsg-5
ii  libmariadb3  1:10.11.3-1
ii  libpam-modules   1.5.2-6
ii  libpam0g 1.5.2-6
ii  libssl3  3.0.9-1
ii  libtalloc2   2.4.0-f2
ii  libtdb1  1.4.8-2
ii  libtirpc31.3.3+ds-1
ii  libtracker-sparql-3.0-0  3.4.2-1
ii  libwrap0 7.6.q-32
ii  netbase  6.4
ii  perl 5.36.0-7

Versions of packages netatalk recommends:
pn  avahi-daemon  
pn  cracklib-runtime  
ii  dbus  1.14.8-2~deb12u1
ii  lsof  4.95.0-1
ii  procps2:4.0.2-3
ii  python3   3.11.2-1+b1
pn  python3-dbus  
pn  tracker   
pn  tracker-miner-fs  

Versions of packages netatalk suggests:
pn  quota  

-- Configuration Files:
/etc/netatalk/afp.conf changed [not included]

-- no debconf information
default 15:00:17.038995-0400mount_afp   Received configuration update 
from daemon (initial)
default 15:00:17.041529-0400mDNSResponder   [R264] 
DNSServiceCreateConnection START PID[1484](mount_afp)
default 15:00:17.041601-0400mDNSResponder   [R265] 
DNSServiceQueryRecord(1D000, 0, , ) 
STOP PID[1485](mount_afp)
default 15:00:17.059398-0400mount_afp   
networkd_settings_read_from_file initialized networkd settings by reading plist 
directly
default 15:00:17.061969-0400mount_afp   FindValidIPAddress - connect 
failed socket 0, optionValue 61
default 15:00:17.062087-0400mount_afp   Entering exit handler.
default 15:00:17.062105-0400mount_afp   Queueing exit procedure onto 
XPC queue. Any further messages sent will be discarded. activeSendTransactions=0
default 15:00:17.062532-0400mDNSResponder   [R267] 
DNSServiceCreateConnection STOP PID[1485](mount_afp)
default 15:00:17.062200-0400mount_afp   Cancelling XPC connection. Any 
further reply handler invocations will not retry messages
default 15:00:17.062227-0400mount_afp   Exiting exit handler.

Bug#1050100: gPodder not suggesting normalize-audio

[tony mancill]

On Sat, Aug 19, 2023 at 07:27:27PM +, paculino wrote:
> Package: gpodder
> Version: 3.11.1-1
> 
> When gPodder is started from terminal without package normalize-audio, this 
> is the error returned:
> $ gpodder
> 
> 1692466078.932185 [gpodder.extensions] ERROR: Cannot load normalize_audio 
> from /usr/share/gpodder/extensions/normalize_audio.py: Command not found: 
> normalize-ogg

Thank you for the bug report.

> Installing package normalize-audio fixes the errors with normalize-ogg, 
> although it is not included in the recommended or suggested packages. Since 
> some extensions rely on this, might the package normalize-audio be included 
> in the suggested packages like yt-dlp?

Good suggestion!  I will include this in the next upload.

Thanks!
tony

Bug#1050957: [ftpmas...@ftp-master.debian.org: Accepted borgbackup 1.2.6-2 (source) into unstable]

[Salvatore Bonaccorso]

Source: borgbackup
Source-Version: (1.2.6-2

- Forwarded message from Debian FTP Masters 
 -

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Fri, 01 Sep 2023 14:37:27 +0200
Source: borgbackup
Built-For-Profiles: noudeb
Architecture: source
Version: 1.2.6-2
Distribution: unstable
Urgency: medium
Maintainer: Debian Borg Collective 
Changed-By: Gianfranco Costamagna 
Changes:
 borgbackup (1.2.6-2) unstable; urgency=medium
 .
   * Rename NEWS file
   * Add back 7793.patch
Checksums-Sha1:
 1444e9d243a5dbd58aaf123b2eae0af3e07c93c5 2783 borgbackup_1.2.6-2.dsc
 4cfcf3784ab77bd96029fabbf58b2e066170071d 21296 borgbackup_1.2.6-2.debian.tar.xz
 b3d13f0e189c49314a9555b1bec0bf28bc56903d 11468 
borgbackup_1.2.6-2_source.buildinfo
Checksums-Sha256:
 1ccf6a555c530da1347587f8d97491f83cba645315a68bfc01caf98ab8d52d5c 2783 
borgbackup_1.2.6-2.dsc
 4952843d6b1f190609e414c6aab9cc40ff9e85710a4878571cbf2afd5914939b 21296 
borgbackup_1.2.6-2.debian.tar.xz
 bf1d4ab48e0678a787584bc993d2ed436b764d99de8c3b91e951032fd8836b12 11468 
borgbackup_1.2.6-2_source.buildinfo
Files:
 38a0546f44e058c7bd50c48e3be024e9 2783 admin optional borgbackup_1.2.6-2.dsc
 96d36d68a0dfa3beb187d2dd578209b1 21296 admin optional 
borgbackup_1.2.6-2.debian.tar.xz
 67b6a61ef50ed2e64f098699bbafbceb 11468 admin optional 
borgbackup_1.2.6-2_source.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEkpeKbhleSSGCX3/w808JdE6fXdkFAmTx2zcACgkQ808JdE6f
Xdmwfw//T11B2phG2kO8fIELApE5mMgW8PBSftVpKbYXVUJ/VzICdBbI6gfofTuz
/JCxoEOqrpD5sn8K0ZoufP0ZxTHbIAki4Ga0hPjQBU9MYib/3+m39+0e7WbXxfOl
gSZf/E8FfoO1drooHt8jSR60713kTjJFD9sM02JPaJE+vWFQbqbGr43YSs0C9Zc7
S18brGUkyhY2mFUfaHI6hDNam0b0kL0pTk0Ugp2+TubZLtfIuDfI7ITkA3HF858E
K/XcjbmKygcYIpBNhsB7+OMbBdswxD/YeXPMsIBpIsrkVjpWnLeCyxt6mR3FlySx
eBLZSRpljPp4pt6fjE5NYFX0+7QoXaECPFmDIDDJbUmvK83yydn8FCHMaBGAF5Gy
/Ef69VLyph4XfFFlWW1PrRItgF3jF0YTbHmH5GJuie8Gzh3WMwMbuIpAcUkve+eE
qTT14+ZDfH0fLZ9+f0KGVHZwOiOXNhJHcnS2NuUZEv3AbYaIDRQ7qVy4cMax+C17
Bm7QSlUjy2amhR0pLwwRBOylBqOgc5WVB2cEcy/6ssbqnmWb6Q0fOgCvLNTLQM0o
z3lt80lnDgoTKzmH9CnSmRwP2RhCwREIYcZUA/m7oQG2U3cz2cJWvDsGl5jSC0qN
KabzfDHPMzvFqOqYOkurAWq1efscZHj02iPwtgePmPaxO4RZ2h4=
=9ta9
-END PGP SIGNATURE-


- End forwarded message -

Bug#1051102: edac-utils: Errors when running edac-ctl --layout

[administrator]

Package: edac-utils
Version: 0.18+git12-gd98769e-1
Severity: normal
X-Debbugs-Cc: edacbu...@madez.de

Dear Maintainer,

running edac-ctl --layout on this machine with ecc memory gives errors:

$ sudo edac-ctl --layout
readline() on closed filehandle IN at /usr/sbin/edac-ctl line 514.
readline() on closed filehandle IN at /usr/sbin/edac-ctl line 514.
readline() on closed filehandle IN at /usr/sbin/edac-ctl line 514.
readline() on closed filehandle IN at /usr/sbin/edac-ctl line 514.
Use of uninitialized value $d in numeric ge (>=) at /usr/sbin/edac-ctl line 590.
Use of uninitialized value $d in sprintf at /usr/sbin/edac-ctl line 593.
Use of uninitialized value $pos[3] in join or string at /usr/sbin/edac-ctl line 
531.
Use of uninitialized value $size in sprintf at /usr/sbin/edac-ctl line 533.
Use of uninitialized value $pos[3] in join or string at /usr/sbin/edac-ctl line 
531.
Use of uninitialized value $size in sprintf at /usr/sbin/edac-ctl line 533.
Use of uninitialized value $pos[3] in join or string at /usr/sbin/edac-ctl line 
531.
Use of uninitialized value $size in sprintf at /usr/sbin/edac-ctl line 533.
Use of uninitialized value $pos[3] in join or string at /usr/sbin/edac-ctl line 
531.
Use of uninitialized value $size in sprintf at /usr/sbin/edac-ctl line 533.
Use of uninitialized value $pos[3] in join or string at /usr/sbin/edac-ctl line 
531.
Use of uninitialized value $size in sprintf at /usr/sbin/edac-ctl line 533.
Use of uninitialized value $pos[3] in join or string at /usr/sbin/edac-ctl line 
531.
Use of uninitialized value $size in sprintf at /usr/sbin/edac-ctl line 533.
+---+
|  mc0  |
|csrow0 |csrow1 |csrow2 |
| channel0  | channel1  | channel0  | channel1  | channel0  | channel1  |
Use of uninitialized value $d in subtraction (-) at /usr/sbin/edac-ctl line 621.
Use of uninitialized value $max_pos[3] in subtraction (-) at /usr/sbin/edac-ctl 
line 621.
+---+

0: | 0 MB  | 0 MB  | 0 MB  | 0 MB  | 0 MB  | 0 MB  |
+---+

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

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

Versions of packages edac-utils depends on:
ii  libc6  2.36-9+deb12u1
ii  libedac1   0.18+git12-gd98769e-1
ii  sysvinit-utils [lsb-base]  3.06-4

Versions of packages edac-utils recommends:
ii  dmidecode  3.4-1

edac-utils suggests no packages.

-- no debconf information

Bug#1043477: [ftpmas...@ftp-master.debian.org: Accepted php8.2 8.2.10-1 (source) into unstable]

[Salvatore Bonaccorso]

Source: php8.2
Source-Version: 8.2.10-1

This upload fixes as well #1043477, tracking bug for CVE-2023-3823 and
CVE-2023-3824.

- Forwarded message from Debian FTP Masters 
 -

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Sat, 02 Sep 2023 08:31:05 +0200
Source: php8.2
Architecture: source
Version: 8.2.10-1
Distribution: unstable
Urgency: medium
Maintainer: Debian PHP Maintainers 
Changed-By: Ondřej Surý 
Changes:
 php8.2 (8.2.10-1) unstable; urgency=medium
 .
   * New upstream version 8.2.10
   * Enable DTrace on all architectures
Checksums-Sha1:
 9fb1d06aa69fcadbc447f400afbd96368c2dcda6 5694 php8.2_8.2.10-1.dsc
 677c4f2c1091afdedb9455dac77ce2e8efc973c0 12041348 php8.2_8.2.10.orig.tar.xz
 852d4d8ab95c239a927ed2ad0b68822c5dafe5af 858 php8.2_8.2.10.orig.tar.xz.asc
 9231fdcd753025966bc280f3b34cc386373acdfc 69500 php8.2_8.2.10-1.debian.tar.xz
 65a037944703da7079f13300ff6089676ae7d0e9 32858 php8.2_8.2.10-1_amd64.buildinfo
Checksums-Sha256:
 c4a4fcafce9d2323cd0b9f7c17977d56e5db77688dbae27bc53bb07c773048e6 5694 
php8.2_8.2.10-1.dsc
 561dc4acd5386e47f25be76f2c8df6ae854756469159248313bcf276e282fbb3 12041348 
php8.2_8.2.10.orig.tar.xz
 7697adb0dbbc66d3edfa32cdca7dbd2c5d548974e6594eddc91fa23526c22a8c 858 
php8.2_8.2.10.orig.tar.xz.asc
 a8954e3cfa3199b6984511875702da260605c17266f55e951e19fddb4ca11240 69500 
php8.2_8.2.10-1.debian.tar.xz
 b0c6589d8bd3ae0feb7e8a2e55b414b1f3767de0b757410380ce6562f4c9fc74 32858 
php8.2_8.2.10-1_amd64.buildinfo
Files:
 ba4b051ada62d347bd40921bb612a4c3 5694 php optional php8.2_8.2.10-1.dsc
 7cf41ae950f76e031599129f7cac6719 12041348 php optional 
php8.2_8.2.10.orig.tar.xz
 44ea3744a42f39a86235b4efc7026181 858 php optional php8.2_8.2.10.orig.tar.xz.asc
 2e7fdad7613dd249bdf3aa809132ada9 69500 php optional 
php8.2_8.2.10-1.debian.tar.xz
 15d73db1556a5e75cb2064fc9b3455c3 32858 php optional 
php8.2_8.2.10-1_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEEw2Gx4wKVQ+vGJel9g3Kkd++uWcIFAmTy6oVfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEMz
NjFCMUUzMDI5NTQzRUJDNjI1RTk3RDgzNzJBNDc3RUZBRTU5QzIACgkQg3Kkd++u
WcK32hAAlcSes+txDocfhBc1/3b/HEU3/ybU/ifnJkjyWJxPVhytpaKqY2fBVXGv
aPf36viOY1lGP/wd3PAPvGHgxSN8AGXgsvo+Huful2ztyIVyUaTHFhPGzmZ+zMVx
CvN8hfN+RspUvV5B6klKUMA1vT8g2BryBJL3QbM8KW/mI+AMAPpBd/wEZOD+aIAc
/ri8WBxgCRTQh5NEs5ss7DIRiFmI0dbL41qQ67sej2ETntkFKdmcfGcxlmWENYcL
Zl7gzN/aJnTStXUG9tkvbnZrLLUnd7sOjLjTQvHj3CevHkEZq1xXoYYVd+x59tZQ
85qiWiTo5oVoBWIURKc0MGG8UeqyxX+ylp2oAp2cpqlTe96FBhqRkzzNirwq1M1r
lOhoxuJRuoosGt8nYAN+hv0jYEOj+X/sxcRspM09QN11um9sbeDjczOa49rOW5TN
jcbuPCYg0ftirCx+/Kmfe24AXKVg2xRRPRYvzNYDtwEw4MOmVtYMPtUz9LnGDZj1
lPAABxGT6ft79bm7BIaEOiazU08kujpNbW3hIZXcCsyg2/fTY8LKlHzQ5NlrNlKq
Bi99Sjf3A/C44F+/eCt4J1NfI0ZoZAiOIDGGlVvL5y2uQNNFqW5oh2rN3V2KazfI
chEkhCPzYx0kxeLzsyr1Uu+SzHwH0acDhZesV5ijhjsRtkmfqn0=
=LrF2
-END PGP SIGNATURE-


- End forwarded message -

Bug#1051101: rust-vm-memory: CVE-2023-41051

[Salvatore Bonaccorso]

Source: rust-vm-memory
Version: 0.12.0-2
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for rust-vm-memory.

CVE-2023-41051[0]:
| In a typical Virtual Machine Monitor (VMM) there are several
| components, such as boot loader, virtual device drivers, virtio
| backend drivers and vhost drivers, that need to access the VM
| physical memory. The vm-memory rust crate provides a set of traits
| to decouple VM memory consumers from VM memory providers. An issue
| was discovered in the default implementations of the
| `VolatileMemory::{get_atomic_ref, aligned_as_ref, aligned_as_mut,
| get_ref, get_array_ref}` trait functions, which allows out-of-bounds
| memory access if the `VolatileMemory::get_slice` function returns a
| `VolatileSlice` whose length is less than the function’s `count`
| argument. No implementations of `get_slice` provided in `vm_memory`
| are affected. Users of custom `VolatileMemory` implementations may
| be impacted if the custom implementation does not adhere to
| `get_slice`'s documentation. The issue started in version 0.1.0 but
| was fixed in version 0.12.2 by inserting a check that verifies that
| the `VolatileSlice` returned by `get_slice` is of the correct
| length. Users are advised to upgrade. There are no known workarounds
| for this issue.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-41051
https://www.cve.org/CVERecord?id=CVE-2023-41051
[1] 
https://github.com/rust-vmm/vm-memory/security/advisories/GHSA-49hh-fprx-m68g
[2] 
https://github.com/rust-vmm/vm-memory/commit/aff1dd4a5259f7deba56692840f7a2d9ca34c9c8

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1051100: libtommath: CVE-2023-36328

[Salvatore Bonaccorso]

Source: libtommath
Version: 1.2.0-6
Severity: important
Tags: security upstream
Forwarded: https://github.com/libtom/libtommath/pull/546
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for libtommath.

CVE-2023-36328[0]:
| Integer Overflow vulnerability in mp_grow in libtom libtommath
| before commit beba892bc0d4e4ded4d667ab1d2a94f4d75109a9, allows
| attackers to execute arbitrary code and cause a denial of service
| (DoS).


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-36328
https://www.cve.org/CVERecord?id=CVE-2023-36328
[1] https://github.com/libtom/libtommath/pull/546
[2] 
https://github.com/libtom/libtommath/commit/beba892bc0d4e4ded4d667ab1d2a94f4d75109a9

Please adjust the affected versions in the BTS as needed.

Regards,
Salvaotre

Bug#1050991: FTCBFS amd64 -> arm64 due to using host-arch flags for native builds and vice-versa

[Johannes Schauer Marin Rodrigues]

Hi,

Quoting Bastian Blank (2023-09-02 20:09:42)
> This is https://salsa.debian.org/kernel-team/linux/-/merge_requests/833 now.

thank you!

> > I had a look into debian/rules.d/tools/objtool/Makefile which seems to be
> > setting the flags for this but wasn't able to figure out a fitting solution
> > but maybe what is done with REALHOSTCC and REALHOSTLD has to be done with
> > to CFLAGS as well like REALHOSTCFLAGS? I need some advice here.
> 
> No idea.  This is already a workaround in a workaround.
> 
> > An ugly workaround that fixes both issues is to use the following in
> > debian/rules.real:
> > 
> > MAKE_CLEAN = $(setup_env) $(MAKE) KCFLAGS=-fdebug-prefix-map=$(CURDIR)/= 
> > KBUILD_HOSTCFLAGS='' HOSTCFLAGS='' KBUILD_HOSTLDFLAGS=''
> 
> We don't really care about all the tools built for the build
> environment.  Just the command line checker will go wild.
> 
> If it fixes the problem also the problem with subcmd, why not?

I'm not sure whether all of these tools are just for the build environment and
not shipped in any .deb. I also don't know whether, because flags are leaking
left and right, setting these variables to the empty string will have an effect
for tools that are meant to be shipped but get the wrong variables passed.

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1050991: FTCBFS amd64 -> arm64 due to using host-arch flags for native builds and vice-versa

[Bastian Blank]

On Fri, Sep 01, 2023 at 09:15:50AM +0200, Johannes Schauer Marin Rodrigues 
wrote:
> Helmut informed me that bugs that break bootstrap (rebootstrap fails to
> cross-build linux-libc-dev because of this bug) are usually filed with serious
> severity, so doing that now. Thanks!

Cross-building linux-libc-dev, by using the proper build profiles
pkg.linux.nokernel and pkg.linux.notools, does not even reach this code
paths.

Bastian

-- 
Ahead warp factor one, Mr. Sulu.

Bug#1050991: FTCBFS amd64 -> arm64 due to using host-arch flags for native builds and vice-versa

[Bastian Blank]

On Fri, Sep 01, 2023 at 08:36:53AM +0200, Johannes Schauer Marin Rodrigues 
wrote:
> diff -Nru linux-6.4.11/debian/rules.real linux-6.4.11/debian/rules.real
> --- linux-6.4.11/debian/rules.real  2023-08-17 09:05:43.0 +0200
> +++ linux-6.4.11/debian/rules.real  2023-09-01 06:43:41.0 +0200
> @@ -43,7 +43,10 @@
>  setup_env += DISTRIBUTION_OFFICIAL_BUILD=1 DISTRIBUTOR="$(DISTRIBUTOR)" 
> DISTRIBUTION_VERSION="$(SOURCEVERSION)" 
> KBUILD_BUILD_TIMESTAMP="$(SOURCE_DATE)" 
> KBUILD_BUILD_VERSION_TIMESTAMP="$(DISTRIBUTOR) $(SOURCEVERSION) 
> ($(SOURCE_DATE_UTC_ISO))" KBUILD_BUILD_USER="$(word 1,$(subst @, 
> ,$(MAINTAINER)))" KBUILD_BUILD_HOST="$(word 2,$(subst @, ,$(MAINTAINER)))"
>  setup_env += KBUILD_VERBOSE=$(if $(filter terse,$(DEB_BUILD_OPTIONS)),0,1)
>  
> -MAKE_CLEAN = $(setup_env) $(MAKE) KCFLAGS=-fdebug-prefix-map=$(CURDIR)/= 
> KBUILD_HOSTCFLAGS='$(CFLAGS) $(CPPFLAGS)' HOSTCFLAGS='$(CFLAGS) $(CPPFLAGS)' 
> KBUILD_HOSTLDFLAGS='$(LDFLAGS)'
> +CFLAGS_FOR_BUILD   ?= $(shell dpkg-architecture --host-arch 
> $(DEB_BUILD_ARCH) --force --command dpkg-buildflags --get CFLAGS)
> +CPPFLAGS_FOR_BUILD ?= $(shell dpkg-architecture --host-arch 
> $(DEB_BUILD_ARCH) --force --command dpkg-buildflags --get CPPFLAGS)
> +LDFLAGS_FOR_BUILD  ?= $(shell dpkg-architecture --host-arch 
> $(DEB_BUILD_ARCH) --force --command dpkg-buildflags --get LDFLAGS)
> +MAKE_CLEAN = $(setup_env) $(MAKE) KCFLAGS=-fdebug-prefix-map=$(CURDIR)/= 
> KBUILD_HOSTCFLAGS='$(CFLAGS_FOR_BUILD) $(CPPFLAGS_FOR_BUILD)' 
> HOSTCFLAGS='$(CFLAGS_FOR_BUILD) $(CPPFLAGS_FOR_BUILD)' 
> KBUILD_HOSTLDFLAGS='$(LDFLAGS_FOR_BUILD)'
>  MAKE_SELF := $(MAKE) -f debian/rules.real $(MAKEOVERRIDES)
>  MAKEOVERRIDES =

This is https://salsa.debian.org/kernel-team/linux/-/merge_requests/833
now.

> I had a look into debian/rules.d/tools/objtool/Makefile which seems to be
> setting the flags for this but wasn't able to figure out a fitting solution 
> but
> maybe what is done with REALHOSTCC and REALHOSTLD has to be done with to 
> CFLAGS
> as well like REALHOSTCFLAGS? I need some advice here.

No idea.  This is already a workaround in a workaround.

> Also, could you turn the "mkdir $*" into "mkdir -p $*" in the rule for
> objtool.real-% please? That would make it possible to do re-builds without
> cleaning first and my machine is super slow, thanks! :)

Fixed as well.

> 
> An ugly workaround that fixes both issues is to use the following in
> debian/rules.real:
> 
> MAKE_CLEAN = $(setup_env) $(MAKE) KCFLAGS=-fdebug-prefix-map=$(CURDIR)/= 
> KBUILD_HOSTCFLAGS='' HOSTCFLAGS='' KBUILD_HOSTLDFLAGS=''

We don't really care about all the tools built for the build
environment.  Just the command line checker will go wild.

If it fixes the problem also the problem with subcmd, why not?

Bastian

-- 
If there are self-made purgatories, then we all have to live in them.
-- Spock, "This Side of Paradise", stardate 3417.7

Bug#1051098: suggestion: dh-builtusing may simplify the packaging

[Nicolas Boulenguez]

Source: u-boot
Severity: wishlist
Tags: patch

Hello.

You may be interested in the dh-builtusing debhelper tool, which
generates the Built-Using field instead of explicit shell subcommands.

--- a/debian/control
+++ b/debian/control
@@ -7,6 +7,7 @@ Build-Depends:
  bc,
  bison,
  debhelper-compat (= 13),
+ dh-sequence-builtusing,
  flex,
  libpython3-dev:native [linux-any],
  libssl-dev,
@@ -167,7 +168,8 @@ Description: A boot loader for omap systems
 Package: u-boot-sunxi
 Architecture: armhf arm64
 Multi-Arch: same
-Built-Using: ${u-boot-sunxi:Built-Using}
+Built-Using: ${dh-builtusing:arm-trusted-firmware} [arm64],
+ ${dh-builtusing:crust-firmware} [arm64],
 Depends: ${misc:Depends}
 Recommends: u-boot-tools [arm64]
 Suggests: arm-trusted-firmware [arm64]
@@ -221,7 +223,7 @@ Description: A boot loader for marvell systems
 Package: u-boot-rockchip
 Architecture: armhf arm64
 Multi-Arch: same
-Built-Using: ${u-boot-rockchip:Built-Using}
+Built-Using: ${dh-builtusing:arm-trusted-firmware} [arm64]
 Depends: ${misc:Depends}
 Recommends: python3, u-boot-tools [arm64]
 Suggests: arm-trusted-firmware [arm64]
@@ -275,7 +277,7 @@ Package: u-boot-sifive
 Architecture: riscv64
 Multi-Arch: same
 Depends: ${misc:Depends}
-Built-Using: ${u-boot-sifive:Built-Using}
+Built-Using: ${dh-builtusing:opensbi}
 Description: A boot loader for SiFive systems
  Das U-Boot is a cross-platform bootloader for embedded systems,
  used as the default boot loader by several board vendors.  It is
--- a/debian/rules
+++ b/debian/rules
@@ -155,6 +155,6 @@ override_dh_clean:
find . -type d -name __pycache__ -delete
 
 override_dh_gencontrol:
-   dh_gencontrol -- $(dpkg-gencontrol_args) $(foreach package,\
+   dh_gencontrol -- $(foreach package,\
  u-boot-qemu $(subarchs),\
  '-V$(package):platforms=$(subst $() 
,$${Newline},$($(package)_platforms))')
--- a/debian/targets.mk
+++ b/debian/targets.mk
@@ -45,9 +45,6 @@ ifeq (${DEB_HOST_ARCH},arm64)
 
 # u-boot-rockchip
 
-  dpkg-gencontrol_args += "-Vu-boot-rockchip:Built-Using=$(shell dpkg-query 
-Wf \
-'$${source:Package} (= $${source:Version})' arm-trusted-firmware)"
-
   # Vagrant Cascadian 
   u-boot-rockchip_platforms += firefly-rk3399
   firefly-rk3399_assigns := BL31=/usr/lib/arm-trusted-firmware/rk3399/bl31.elf
@@ -139,9 +136,6 @@ ifeq (${DEB_HOST_ARCH},arm64)
   u-boot-sunxi_assigns = \
 SCP=$(or $(wildcard /usr/lib/crust-firmware/$(platform).bin),/dev/null)
 
-  dpkg-gencontrol_args += "-Vu-boot-sunxi:Built-Using=$(shell dpkg-query -Wf \
-'$${source:Package} (= $${source:Version})' arm-trusted-firmware)"
-
   u-boot-sunxi_platforms += a64-olinuxino
   a64-olinuxino_assigns := 
BL31=/usr/lib/arm-trusted-firmware/sun50i_a64/bl31.bin
   a64-olinuxino_targets := arch/arm/dts/sun50i-a64-olinuxino.dtb \
@@ -376,9 +370,6 @@ else ifeq (${DEB_HOST_ARCH},armhf)
 
 # u-boot-rockchip
 
-  # Silent a debhelper warning about an unused substvar.
-  dpkg-gencontrol_args += -Vu-boot-rockchip:Built-Using=
-
   # Vagrant Cascadian , 2GB and 4GB variants
   u-boot-rockchip_platforms += firefly-rk3288
   firefly-rk3288_targets := idbloader.img spl/u-boot-spl.bin u-boot.bin \
@@ -413,9 +404,6 @@ else ifeq (${DEB_HOST_ARCH},armhf)
 
 # u-boot-sunxi
 
-  # Silent a debhelper warning about an unused substvar.
-  dpkg-gencontrol_args += -Vu-boot-sunxi:Built-Using=
-
   # Christian Kastner 
   u-boot-sunxi_platforms += A10-OLinuXino-Lime
   A10-OLinuXino-Lime_targets := u-boot-sunxi-with-spl.bin uboot.elf
@@ -541,9 +529,6 @@ else ifeq (${DEB_HOST_ARCH},riscv64)
 
 # u-boot-sifive
 
-  dpkg-gencontrol_args += "-Vu-boot-sifive:Built-Using=$(shell dpkg-query -Wf \
-'$${source:Package} (= $${source:Version})' opensbi)"
-
   # Hector Oron 
   u-boot-sifive_platforms += sifive_unleashed
   sifive_unleashed_targets := u-boot.bin uboot.elf spl/u-boot-spl.bin 
u-boot.itb

Bug#1050974: binNMU: Rebuild against curl without NSS support

[Sebastian Ramacher]

Hi

On 2023-09-02 18:27:39 +0100, Samuel Henrique wrote:
> Hello Sebastian anb Paul,
> 
> > So let's not just rebuild those. Samuel, please file bugs against those
> > packages so that the maintainers fix the build dependencies.
> 
> I have filled bugs already, here's the current situation:
> 
> eg25-manager:
> https://bugs.debian.org/1043547
> Has been fixed in git already, so the next upload will have the correct B-D.
> 
> llvm-toolchain-14 and llvm-toolchain-15:
> https://bugs.debian.org/1043550
> https://bugs.debian.org/1043551
> 
> I have not explicitly asked for the B-D change for llvm, and I think
> doing it so will be a waste of time and effort, let me explain.
> Both llvm-toolchain-14 and llvm-toolchain-15 will be removed from the
> archive soon, see their ROM bugs:
> https://bugs.debian.org/1050069
> https://bugs.debian.org/1050070

Removing old llvm-toolchain versions usually takes month. For reference,
removal of llvm-toolchain-13 took a year (RM bug was filed in August
2022) and is still part of trixie.

> On top of that, those two packages have already been rebuilt for
> riscv64 (no binNMUs required there), whereas if we force another
> upload only to solve this, we will trigger a build for every arch and
> needlessly consume at the very least 77 hours of the riscv builders'
> time (while we are still rebuilding the archive for riscv, delaying it
> all).
> https://buildd.debian.org/status/logs.php?pkg=llvm-toolchain-14=riscv64
> https://buildd.debian.org/status/logs.php?pkg=llvm-toolchain-15=riscv64
> 
> Do you think that's a sensible compromise?
> I'm asking to proceed with binNMUs because eg25-manager has been fixed
> in git already and the llvm packages are about to be removed (although
> I want curl to migrate before that), also rebuilding them on riscv
> takes a lot of effort at a not-so-great time (no binNMUs required for
> riscv).

Please get those uploaded instead. We will rebuild
llvm-toolchain-{14,15} a bunch of times for transitions anyway. If
riscv64 buildds are not ready to cope with that, the architecture is not
ready to become a release architecture.

> Note: llvm-toolchain-16, which is going to be the new default, has
> already fixed the B-D and the package has been uploaded, so that's why
> there's no action for that one.

llvm-toolchain-16 can only become the default once its build is fixed on
mips64el. I have seen no progress in that direction, though.

Cheers
-- 
Sebastian Ramacher

Bug#1050944: debhelper-compat level

[tony mancill]

Hi Matthias,

On Fri, Sep 01, 2023 at 07:19:15AM -0700, tony mancill wrote:
> On Fri, Sep 01, 2023 at 07:04:05PM +1200, Vladimir Petko wrote:
> >  The debhelper-compat was intentionally set to >=11 in order to
> > support backports.
> 
> Thank you for the reminder.  I can easily revert the change.  But to
> make sure I understand the requirements, how far back do we want to
> support backports of new uploads of jtreg6?
> 
> Although it wasn't part of the buster release, debhelper 13.x is
> available in old-old-stable (buster) backports [0,1], which is as far as
> I looked before making the change.  Is jtreg6 needed for stretch, which
> is currently in EOL ELTS [2]?
> 
> Thank you,
> tony
> 
> [0] https://packages.debian.org/source/buster-backports/debhelper
> [1] https://packages.debian.org/source/oldoldstable-backports/debhelper
> [2] https://wiki.debian.org/DebianReleases

Thank you for the upload.  As I mentioned to Vladimir above, I'd like to
document the reason debhelper 13 is not backport friendly.  If you can
give me a pointer or a brief explanation, I'll add it to README.source
so it's clear to all.  (I assume it has to do with releases older than
Debian buster or Ubuntu focal [3], since both of their backport suites
already contain debhelper 13.)

Also, there are build-deps of jtreg6, for example libhamcrest-java [4]
that depend on debhelper-compat 13 and presumably need to be adjusted as
well.

Thanks,
tony

[3] 
https://packages.ubuntu.com/search?suite=default=all=any=debhelper=sourcenames
[4] 
https://salsa.debian.org/java-team/libhamcrest-java/-/blob/master/debian/control#L10


signature.asc
Description: PGP signature

Bug#1041508: tex-common: Installation fails if system is missing the set locale

[Samuel Henrique]

> According to https://tracker.debian.org/pkg/texlive-extra the new version 
> from unstable could migrate to
> testing tomorrow

This has happened now, every testing user is getting the following error:
"""
Building format(s) --all.
This may take some time...
fmtutil failed. Output has been stored in
/tmp/fmtutil.isqbK6Rx
Please include this file if you report a bug.

dpkg: error processing package tex-common (--configure):
 installed tex-common package post-installation script subprocess
returned error exit status 1
Errors were encountered while processing:
 tex-common
needrestart is being skipped since dpkg has failed
E: Sub-process /usr/bin/dpkg returned an error code (1)
"""

We might need to 0-day NMU this with high urgency so it fixes the
upgrade breakage, users will be very confused by this.

Cheers,


-- 
Samuel Henrique 

Bug#1050974: binNMU: Rebuild against curl without NSS support

[Samuel Henrique]

Hello Sebastian anb Paul,

> So let's not just rebuild those. Samuel, please file bugs against those
> packages so that the maintainers fix the build dependencies.

I have filled bugs already, here's the current situation:

eg25-manager:
https://bugs.debian.org/1043547
Has been fixed in git already, so the next upload will have the correct B-D.

llvm-toolchain-14 and llvm-toolchain-15:
https://bugs.debian.org/1043550
https://bugs.debian.org/1043551

I have not explicitly asked for the B-D change for llvm, and I think
doing it so will be a waste of time and effort, let me explain.
Both llvm-toolchain-14 and llvm-toolchain-15 will be removed from the
archive soon, see their ROM bugs:
https://bugs.debian.org/1050069
https://bugs.debian.org/1050070

On top of that, those two packages have already been rebuilt for
riscv64 (no binNMUs required there), whereas if we force another
upload only to solve this, we will trigger a build for every arch and
needlessly consume at the very least 77 hours of the riscv builders'
time (while we are still rebuilding the archive for riscv, delaying it
all).
https://buildd.debian.org/status/logs.php?pkg=llvm-toolchain-14=riscv64
https://buildd.debian.org/status/logs.php?pkg=llvm-toolchain-15=riscv64

Do you think that's a sensible compromise?
I'm asking to proceed with binNMUs because eg25-manager has been fixed
in git already and the llvm packages are about to be removed (although
I want curl to migrate before that), also rebuilding them on riscv
takes a lot of effort at a not-so-great time (no binNMUs required for
riscv).

Note: llvm-toolchain-16, which is going to be the new default, has
already fixed the B-D and the package has been uploaded, so that's why
there's no action for that one.

Thank you,

-- 
Samuel Henrique 

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

[Niels Thykier]

Control: owner -1
Control: retitle -1 ITA: debianutils -- Essential utilities

On Tue, 29 Aug 2023 13:35:05 +0200 Bastian Germann  wrote:

Package: wnpp

After I have made a dog's breakfast of debianutils' postinst and fixed it,
I do not feel inclined to maintain that essential package any longer.
I cannot afford the response time that it takes when people's chroots break.
So I orphan debianutils.

So please consider adopting if you want to take the chance and have a good
knowledge of the tools contained in debianutils.





Hi,

I am also interested in maintaining the package, retitling it to an ITA 
because there are adopters.


@Ileana: Would you be fine with co-maintaining it with me? We can use 
the existing git repo (https://salsa.debian.org/debian/debianutils) as 
packaging repo and coordinate our changes via that.


Best regards,
Niels

Bug#1051097: cyrus-imapd: autopkgtest failure because package is not installable

[Jeremy Bícha]

Source: cyrus-imapd
Version: 3.8.0-4
Severity: serious
X-Debbugs-CC: y...@debian.org

The autopkgtest for cyrus-imapd 3.8.0-4 is failing but 3.8.0-3 succeeded.

https://ci.debian.net/packages/c/cyrus-imapd/testing/amd64/

autogpktest log excerpt
=
Setting up cyrus-common (3.8.0-4) ...
 79s You must update cyrus-imapd to at least version 3.2.6-2+deb11u2~
 79s before updating it to version 3.6.x and run it, else your mailboxes
 79s may be corrupted
 79s dpkg: error processing package cyrus-common (--configure):
 79s  installed cyrus-common package post-installation script
subprocess returned error exit status 1
 79s dpkg: dependency problems prevent configuration of cyrus-imapd:
 79s  cyrus-imapd depends on cyrus-common (= 3.8.0-4); however:
 79s   Package cyrus-common is not configured yet.
 79s
 79s dpkg: error processing package cyrus-imapd (--configure):
 79s  dependency problems - leaving unconfigured
 79s dpkg: dependency problems prevent configuration of autopkgtest-satdep:
 79s  autopkgtest-satdep depends on cyrus-imapd; however:
 79s   Package cyrus-imapd is not configured yet.
 79s
 79s dpkg: error processing package autopkgtest-satdep (--configure):
 79s  dependency problems - leaving unconfigured
 79s Processing triggers for libc-bin (2.37-7) ...
 79s Errors were encountered while processing:
 79s  cyrus-common
 79s  cyrus-imapd
 79s  autopkgtest-satdep
 79s E: Sub-process /usr/bin/dpkg returned an error code (1)


Thank you,
Jeremy Bícha

Bug#1051096: nfoview: recommends a non-existent package

[paula]

Package: nfoview
Version: 1.29-2
Severity: serious
X-Debbugs-Cc: paula@cs.email

Dear Maintainer,

nfoview currently Recommends the package fonts-cascadia-code which is
not packaged in stable version of debian. This is a policy violation.

Please fix thank you.

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

Kernel: Linux 6.1.0-11-amd64 (SMP w/2 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 nfoview depends on:
ii  gir1.2-gtk-3.0  3.24.37-2
ii  python3 3.11.2-1+b1
ii  python3-gi  3.42.2-3+b1

Versions of packages nfoview recommends:
pn  fonts-cascadia-code  

nfoview suggests no packages.

-- no debconf information

Bug#1050974: binNMU: Rebuild against curl without NSS support

[Sebastian Ramacher]

On 2023-09-01 19:45:53 +0200, Paul Gevers wrote:
> Hi,
> 
> On 01-09-2023 14:25, Samuel Henrique wrote:
> > These packages have a build dependency on the virtual package
> > "libcurl4-dev", which is satisfiable by any variant of the curl
> > binaries (openssl, gnutls, nss).
> 
> Policy 7.5 [1] says that "To specify which of a set of real packages should
> be the default to satisfy a particular dependency on a virtual package, list
> the real package as an alternative before the virtual one." It's best
> practice to specify which real package should be used to avoid apt choosing
> it on the buildd. We had variation because of temporary non-installability
> in the past (IIRC), it's better to wait with building.
> 
> I must admit I though the requirement was stronger and you *had to* specify
> a real package before a virtual build dependency.

So let's not just rebuild those. Samuel, please file bugs against those
packages so that the maintainers fix the build dependencies.

Cheers

> 
> Paul
> 
> [1] 
> https://www.debian.org/doc/debian-policy/ch-relationships.html#virtual-packages-provides




-- 
Sebastian Ramacher

Bug#1051083: [Debian-med-packaging] Bug#1051083: Please fix autopkgtest regression with file 1.45

[Étienne Mollier]

Control: tag -1 + confirmed patch pending

Bonjour Cristoph,

Thanks for the heads up, I implemented a change in the spirit of
your suggestion.  I'll upload something to ease your transition
in not too long.

Bonne journée,  :)
-- 
  .''`.  Étienne Mollier 
 : :' :  gpg: 8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
 `. `'   sent from /dev/pts/2, please excuse my verbosity
   `-


signature.asc
Description: PGP signature

Bug#1051095: ".TE" is treated like an isolated "TE".

[Bjarni Ingi Gislason]

Package: codespell
Version: 2.2.5-1
Severity: minor

Dear Maintainer,

  this is from a man-page, where ".TE" is a call to a macro (end of table).

sensors.conf.5:118: TE ==> THE, BE, WE, TO
sensors.conf.5:373: TE ==> THE, BE, WE, TO


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

Kernel: Linux 6.4.11-1 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 (charmap=ISO-8859-1), 
LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages codespell depends on:
ii  python3  3.11.4-5+b1
ii  python3-chardet  5.2.0+dfsg-1

codespell recommends no packages.

codespell suggests no packages.

-- no debconf information

Bug#1051094: kde-baseapps: entire machine freezes with soft lockups at KDE login after upgrade to bookworm

[D. R. Evans]

Package: kde-baseapps
Version: 4:22.12.3+5.142
Severity: important

Dear Maintainer,

   * What led up to the situation?
   
Updated from bullseye to bookworm. No obvious errors during the upgrade.
   
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
 
Symptom: Usually KDE simply freezes during login. Sometimes it does allow me to
log in (very slowly) and open a terminal, but shortly thereafter, it freezes.

In addition, the machine starts to beep when it freezes, which indicates a soft 
lockup.

Looking in journalctl:

  root@zserver:~# journalctl | grep lockup
  Sep 01 11:14:31 zserver kernel: watchdog: BUG: soft lockup - CPU#7 stuck for 
45s! [akonadi_control:10618]
  Sep 01 11:14:31 zserver kernel:  ? softlockup_fn+0x70/0x70
  Sep 01 11:15:08 zserver kernel: watchdog: BUG: soft lockup - CPU#7 stuck for 
71s! [akonadi_control:10618]
  Sep 01 11:15:08 zserver kernel:  ? softlockup_fn+0x70/0x70
  Sep 01 11:15:31 zserver kernel: watchdog: BUG: soft lockup - CPU#7 stuck for 
101s! [akonadi_control:10618]
  Sep 01 11:15:31 zserver kernel:  ? softlockup_fn+0x70/0x70
  Sep 01 11:26:07 zserver kernel: watchdog: BUG: soft lockup - CPU#1 stuck for 
22s! [kalendarac:6891]
  Sep 01 11:26:07 zserver kernel:  ? lockup_detector_update_enable+0x50/0x50
  Sep 01 12:10:15 zserver kernel: watchdog: BUG: soft lockup - CPU#1 stuck for 
22s! [kaccess:59605]
  Sep 01 12:15:15 zserver kernel: watchdog: BUG: soft lockup - CPU#7 stuck for 
44s! [akonadi_followu:15090]
  Sep 01 12:15:15 zserver kernel:  ? softlockup_fn+0x70/0x70
  Sep 01 12:15:16 zserver kernel: watchdog: BUG: soft lockup - CPU#7 stuck for 
70s! [akonadi_followu:15090]
  Sep 01 12:15:16 zserver kernel:  ? softlockup_fn+0x70/0x70
  Sep 01 12:15:44 zserver kernel: watchdog: BUG: soft lockup - CPU#7 stuck for 
97s! [akonadi_followu:15090]
  Sep 01 12:15:44 zserver kernel:  ? softlockup_fn+0x70/0x70
  Sep 02 09:16:13 zserver kernel: watchdog: BUG: soft lockup - CPU#7 stuck for 
45s! [akonadi_akonote:14911]
  Sep 02 09:16:13 zserver kernel:  ? softlockup_fn+0x70/0x70
  Sep 02 09:16:13 zserver kernel: watchdog: BUG: soft lockup - CPU#7 stuck for 
71s! [akonadi_akonote:14911]
  Sep 02 09:16:13 zserver kernel:  ? softlockup_fn+0x70/0x70
  Sep 02 09:16:13 zserver kernel: watchdog: BUG: soft lockup - CPU#7 stuck for 
104s! [akonadi_akonote:14911]
  Sep 02 09:16:14 zserver kernel:  ? softlockup_fn+0x70/0x70
  Sep 02 09:16:14 zserver kernel: watchdog: BUG: soft lockup - CPU#7 stuck for 
130s! [akonadi_akonote:14911]
  Sep 02 09:16:14 zserver kernel:  ? softlockup_fn+0x70/0x70
  Sep 02 09:16:14 zserver kernel: watchdog: BUG: soft lockup - CPU#7 stuck for 
160s! [akonadi_akonote:14911]
  Sep 02 09:16:14 zserver kernel:  ? softlockup_fn+0x70/0x70
  Sep 02 09:16:14 zserver kernel:  ? softlockup_fn+0x70/0x70
  Sep 02 09:16:14 zserver kernel: watchdog: BUG: soft lockup - CPU#7 stuck for 
246s! [akonadi_akonote:14911]
  Sep 02 09:16:14 zserver kernel:  ? softlockup_fn+0x70/0x70
  Sep 02 09:16:31 zserver kernel: watchdog: BUG: soft lockup - CPU#7 stuck for 
272s! [akonadi_akonote:14911]
  root@zserver:~# 

which suggests a problem associated with akonadi, perhaps?

journalctl also says, for example:

Sep 02 09:16:28 zserver systemd[7328]: Started 
drkonqi-coredump-launcher@0-21521-0.service - Launch DrKonqi for a systemd
  80)  #612328  kde-plasma-desktop: System Settings, Appearance, Splash Screen, 
installation of "KSarboard Splash" fails │-coredump crash (PID 21521/UID 0).

I'm unsure how to actually find the coredump (if it still exists) or how to 
send it to you.

   * What was the outcome of this action?
   
I have been unable to find any way around this; KDE is therefore completely 
unsable here, after the upgrade to bookworm.

It worked fine prior to the upgrade.

   * What outcome did you expect instead?

I expected to be able to log in and use KDE as usual.


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

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

Versions of packages kde-baseapps depends on:
ii  dolphin 4:22.12.3-1
ii  kdialog 4:22.12.3-1
ii  keditbookmarks  22.12.3-1
ii  kfind   4:22.12.3-1
ii  konqueror   4:22.12.3-1
ii  konsole 4:22.12.3-1
ii  kwrite  4:22.12.3-1

kde-baseapps recommends no packages.

kde-baseapps suggests no packages.

-- no debconf information

Bug#1051093: sensors.conf.5: Some notes and editorial corrections for the man-page

[Bjarni Ingi Gislason]

Package: lm-sensors
Version: 1:3.6.0-8
Severity: minor
Tags: patch

Dear Maintainer,

here are some remarks and editorial fixes for the manual.

The patch is in the attachment.

-.-

The difference between the formatted outputs can be seen with:

  nroff -man  > 
  nroff -man  > 
  diff -u  

and for groff, using

"printf '%s\n%s\n' '.kern 0' '.ss 12 0' | groff -man -Z - "

instead of "nroff -man"

  Add the option "-t", if the file contains a table.

  Read the output of "diff -u" with "less -R" or similar.

-.-.

  If "man" (man-db) is used to check the manual for warnings,
the following must be set:

  The option "-warnings=w"

  The environmental variable:

export MAN_KEEP_STDERR=yes (or any non-empty value)

  or

  (produce only warnings):

export MANROFFOPT="-ww -z"

export MAN_KEEP_STDERR=yes (or any non-empty value)

-.-.

Change -- in x--y to \(em (em-dash), or, if an
option, to \-\-

279:.B sensors --bus-list

-.-.

Wrong distance between sentences.

  Separate the sentences and subordinate clauses; each begins on a new
line.  See man-pages(7) ("Conventions for source file layout") and
"info groff" ("Input Conventions").

  The best procedure is to always start a new sentence on a new line,
at least, if you are typing on a computer.

Remember coding: Only one command ("sentence") on each (logical) line.

E-mail: Easier to quote exactly the relevant lines.

Generally: Easier to edit the sentence.

Patches: Less unaffected text.

Search for two adjacent words is easier, when they belong to the same line,
and the same phrase.

  The amount of space between sentences in the output can then be
controlled with the ".ss" request.

N.B

  The number of lines affected is too large to be in the patch.


35:Each chip may have several features. For example, the LM78 monitors 7
36:voltage inputs, 3 fans and one temperature. Feature names are
37:standardized. Typical feature names are in0, in1, in2... for voltage
38:inputs, fan1, fan2, fan3... for fans and temp1, temp2, temp3... for
43:limit, alarm, etc. Sub\-feature names are standardized as well. For
46:(high limit) and in0_alarm (alarm flag). Which sub\-features are
67:statements are meant. A chip
70:statement. Example:
80:dashes. The first element is the chip type, the second element is
82:of the chip. Such chip descriptions are printed by sensors(1) as the
97:statement. This list isn't necessarily exhaustive as support for other
102:for every element. Note however that it wouldn't make any sense to specify
126:statement describes how a feature should be called. Features without a
128:statement are just called by their feature name. Applications can use this
129:to label the readings they present. Example:
135:The first argument is the feature name. The second argument is the feature
139:one displayed by "sensors" by default. Use "sensors \-u" to see the raw
140:feature names. Same applies to all other statement types below.
148:sensor is not connected). Example:
154:The only argument is the feature name. Please note that this does not 
disable
164:to a raw value again. This is most useful for voltage sensors, because
174:using two resistors of values 6.8 Ohm and 10 Ohm, respectively. See the
178:The first argument is the feature name. The second argument is an expression
180:`@' stands here for the raw value. This is the formula which will be applied
181:when reading values from the chip. The third argument is an expression that
183:`@' stands here for the real\-world value. This is the formula which will be
184:applied when writing values to the chip. The two formulas are obviously
190:it makes sense. For example, the above example would affect sub\-features
203:are substituted. You should be careful though to avoid circular references.
214:statement is used to write a sub\-feature value to the chip. Of course not
216:and alarm flags can not. Valid sub\-features are usually min/max limits.
229:The first argument is the feature name. The second argument is an expression
230:which determines the written value. If there is an applying
236:are substituted. You should be careful though to avoid circular references.
242:option. Typical graphical sensors applications do not care about these
252:adapters (which may change from moment to moment). Example:
258:The first argument is the bus number. It is the literal text
260:followed by a number. As there is a dash in this argument, it must
273:is referred to. Still, as a matter of good style, we suggest you place
285:statement is the configuration file it was defined in. This makes it
294:value is changed. Even if the driver does, it's still better to put
332:voltage value into the 0 \- 4.08 V range. Some use an inverting
333:amplifier, others use a positive reference voltage. This leads to
334:different computation formulas. Note that most users won't have to care
351:one motherboard to the next. For these chips, the driver usually
382:usually only support some of the types above. Please refer to the
392:limits 

Bug#1030835: Progress

[Jelmer Vernooij]

Status update:

ruff-macros: not touched yet
rustpython-common: packaged, waiting for lexical-parse-*
lexical-parse-integer: uploaded, in NEW
lexical-parse-float: waiting for lexical-parse-integer
python-libcst: uploaded, in NEW

libcst:

need to package rust crate; it'd be convenient if we could get
it from crates.io (https://github.com/Instagram/LibCST/issues/967),
but otherwise I'll just package a git snapshot

Cheers,

Jelmer

Bug#1051085: dpkg: dpkg-db-backup.timer stopped after upgrades

[Guillem Jover]

Hi!

On Sat, 2023-09-02 at 16:43:57 +0200, Sven Joachim wrote:
> Package: dpkg
> Version: 1.22.0
> Severity: normal

> Upgrading dpkg stops the dpkg-db-backup.timer, which seems rather
> undesirable, as it the timer remains inactive until the next reboot or
> until it is started manually:
[…]

Ah! Nice catch.

> It seems to me that commit 64a648e7db91 ("debian: Do not start the
> dpkg-db-backup timer during installation") was wrong.  Surely, it
> avoids the "dpkg-db-backup.service is a disabled or a static unit
> not running, not starting it." notice during upgrades, but the timer
> (not the service!) should still be (re-)started.

I considered adding also --no-stop-on-upgrade, but due to #932360 that
seemed bad, and afterwards for some reason thought the stop case was
needed for purge, but rechecking now that's handled by the
«deb-systemd-helper purge» action.

So I've locally added the option, and manual daemon-reload, and will
also add a temporary fixup for the start of the timer for that
specific version.

Thanks,
Guillem

Bug#1043238: libpfm4: crashes on initialization on 32bit arm in autopkgtest CI

[Samuel Thibault]

Hello,

Samuel Thibault, le lun. 07 août 2023 21:29:03 +0200, a ecrit:
> It seems that it is crashing because /proc/cpuinfo is empty, and thus
> pfmlib_getl never allocates a buffer, and the trailing b[i] = '\0' thus
> becomes bogus. The attached patch fixes this in my tests.

Could you upload this patch to Debian? It seems upstream does not really
track merge requests, and in the meanwhile the starpu Debian package
can't migrate to testing due to this crash.

Samuel
Cope with empty /proc/cpuinfo file

--- a/lib/pfmlib_common.c
+++ b/lib/pfmlib_common.c
@@ -791,7 +791,8 @@ pfmlib_getl(char **buffer, size_t *len,
if (c == '\n')
break;
}
-   b[i] = '\0';
+   if (c != EOF)
+   b[i] = '\0';
return c != EOF ? 0 : -1;
 }
 
--- a/lib/pfmlib_arm.c
+++ b/lib/pfmlib_arm.c
@@ -97,6 +97,8 @@ pfmlib_getcpuinfo_attr(const char *attr,
if (!strncmp(attr, buffer, attr_len))
break;
}
+   if (!value)
+   goto error;
strncpy(ret_buf, value, maxlen-1);
ret_buf[maxlen-1] = '\0';
ret = 0;

Bug#1051092: gir-rust-code-generator: FTBFS: error: failed to select a version for the requirement `toml = "^0.5"`

[Aurelien Jarno]

Source: gir-rust-code-generator
Version: 0.18.1-2
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

Dear maintainer,

gir-rust-code-generator fails to build from source. From my build log on
amd64:
| 
| debian cargo wrapper: rust_type, gnu_type: x86_64-unknown-linux-gnu, 
x86_64-linux-gnu
| debian cargo wrapper: running subprocess (['env', 'RUST_BACKTRACE=1', 
'/usr/bin/cargo', '-Zavoid-dev-deps', 'build', '--verbose', '--verbose', 
'-j12', '--target', 'x86_64-unknown-linux-gnu'],) {}
| error: failed to select a version for the requirement `toml = "^0.5"`
| candidate versions found which didn't match: 0.7.6
| location searched: directory source `/<>/debian/cargo_registry` 
(which is replacing registry `crates-io`)
| required by package `gir v0.0.1 (/<>)`
| perhaps a crate was updated and forgotten to be re-vendored?
| dh_auto_test: error: /usr/share/cargo/bin/cargo build returned exit code 101
| make: *** [debian/rules:16: binary-arch] Error 25
| dpkg-buildpackage: error: debian/rules binary-arch subprocess returned exit 
status 2

A full build log on riscv64 is also available:
https://buildd.debian.org/status/fetch.php?pkg=gir-rust-code-generator=riscv64=0.18.1-2=1693535398=0

Regards
Aurelien

Bug#1051091: giara: FTBFS: error: Expected string or translated string

[Aurelien Jarno]

Source: giara
Version: 1.0.1-2
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

Dear maintainer,

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

| [28/29] /usr/bin/blueprint-compiler batch-compile data/. ../data 
../data/ui/comment_box.blp ../data/ui/headerbar.blp 
../data/ui/choice_picker_popover_content.blp ../data/ui/login_view.blp 
../data/ui/headerbar_with_back_and_squeezer.blp ../data/ui/inbox_item_view.blp 
../data/ui/main_ui.blp ../data/ui/post_body.blp 
../data/ui/post_details_headerbar.blp ../data/ui/shortcutsWindow.blp 
../data/ui/image_viewer_window.blp ../data/ui/redditor_heading.blp 
../data/ui/subreddit_heading.blp ../data/ui/subreddit_view_headerbar.blp
| FAILED: data 
| /usr/bin/blueprint-compiler batch-compile data/. ../data 
../data/ui/comment_box.blp ../data/ui/headerbar.blp 
../data/ui/choice_picker_popover_content.blp ../data/ui/login_view.blp 
../data/ui/headerbar_with_back_and_squeezer.blp ../data/ui/inbox_item_view.blp 
../data/ui/main_ui.blp ../data/ui/post_body.blp 
../data/ui/post_details_headerbar.blp ../data/ui/shortcutsWindow.blp 
../data/ui/image_viewer_window.blp ../data/ui/redditor_heading.blp 
../data/ui/subreddit_heading.blp ../data/ui/subreddit_view_headerbar.blp
| error: Expected string or translated string
| at ../data/ui/headerbar.blp line 26 column 24:
|   26 |item { custom: profile; }
|  |   ^
| 
| error: Unexpected tokens
| at ../data/ui/headerbar.blp line 26 column 22:
|   26 |item { custom: profile; }
|  | ^
| 
| 2 errors
| ninja: build stopped: subcommand failed.
| dh_auto_build: error: cd obj-x86_64-linux-gnu && LC_ALL=C.UTF-8 ninja -j12 -v 
returned exit code 1
| make: *** [debian/rules:7: binary-arch] Error 25
| dpkg-buildpackage: error: debian/rules binary-arch subprocess returned exit 
status 2

A full build log on riscv64 is also available:
https://buildd.debian.org/status/fetch.php?pkg=giara=riscv64=1.0.1-2=1693562930=0

Regards
Aurelien

Bug#1051090: emacsql: FTBFS: 5 unexpected results

[Aurelien Jarno]

Source: emacsql
Version: 3.1.1+ds-1 
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

Dear maintainer,

emacsql fails to build from source with errors in the testsuite. From my
build log on amd64:

| Ran 24 tests, 19 results as expected, 5 unexpected (2023-09-01 08:04:24+, 
0.351282 sec)
| 
| 5 unexpected results:
|FAILED  emacsql-basic
|FAILED  emacsql-error
|FAILED  emacsql-foreign-key
|FAILED  emacsql-nul-character
|FAILED  emacsql-special-chars
| 
| dh_elpa_test: error: emacs -batch -Q -l package --eval "(add-to-list 
'package-directory-list \"/usr/share/emacs/site-lisp/elpa\")" --eval 
"(add-to-list 'package-directory-list \"/usr/share/emacs/site-lisp/elpa-src\")" 
-f package-initialize -L . -L tests --eval "(unless (and (getenv 
\"AUTOPKGTEST_TMP\") (file-directory-p (getenv \"AUTOPKGTEST_TMP\"))) (setq 
emacsql-sqlite-executable (concat default-directory 
\"sqlite/emacsql-sqlite\")))" -l tests/emacsql-compiler-tests.el -l 
tests/emacsql-external-tests.el --eval \(ert-run-tests-batch-and-exit\) 
returned exit code 1
| make: *** [debian/rules:4: binary-arch] Error 25
| dpkg-buildpackage: error: debian/rules binary-arch subprocess returned exit 
status 2

A full build log on riscv64 is also available:
https://buildd.debian.org/status/fetch.php?pkg=emacsql=riscv64=3.1.1%2Bds-1=1693407418=0

Regards
Aurelien

Bug#1051089: ruby-rails-assets-punycode: Depends on NBS libjs-punycode

[Jeremy Bícha]

Source: ruby-rails-assets-punycode
Version: 2.2.3+dfsg-1
Severity: serious

ruby-rails-assets-punycode depends on libjs-punycode but nothing
builds that package. It used to be provided by the same source
package.

https://salsa.debian.org/ruby-team/ruby-rails-assets-punycode/-/commit/615fdacd

Thank you,
Jeremy Bícha

Bug#1051088: nfs-common: Spurious additional words left behind in EXAMPLES section of nfs(5).

[James Youngman]

Package: nfs-common
Version: 1:2.6.2-4
Severity: minor
Tags: patch

There is a spurious phrase "mount option" at the beginning of the
EXAMPLES section.

This patch fixes it:

>From 0fbe8a874703124107e74f9a96a201ad3b89b60a Mon Sep 17 00:00:00 2001
From: James Youngman 
Date: Sat, 2 Sep 2023 12:45:18 +0100
Subject: [PATCH] Remove extraneous words left behind by commit 522837f.

---
 utils/mount/nfs.man | 1 -
 1 file changed, 1 deletion(-)

diff --git a/utils/mount/nfs.man b/utils/mount/nfs.man
index 7a410422..c9850f29 100644
--- a/utils/mount/nfs.man
+++ b/utils/mount/nfs.man
@@ -986,7 +986,6 @@ file. See
 .BR nfsmount.conf(5)
 for details.
 .SH EXAMPLES
-mount option.
 To mount using NFS version 3,
 use the
 .B nfs
--
2.39.2





-- Package-specific info:
-- rpcinfo --
   program vers proto   port  service
104   tcp111  portmapper
103   tcp111  portmapper
102   tcp111  portmapper
104   udp111  portmapper
103   udp111  portmapper
102   udp111  portmapper
-- /etc/default/nfs-common --
NEED_STATD=
STATDOPTS=
NEED_IDMAPD=
NEED_GSSD=
-- /etc/nfs.conf --
[general]
pipefs-directory=/run/rpc_pipefs
[nfsrahead]
[exports]
[exportfs]
[gssd]
[lockd]
[exportd]
[mountd]
manage-gids=y
[nfsdcld]
[nfsdcltrack]
[nfsd]
[statd]
[sm-notify]
[svcgssd]
-- /etc/nfs.conf.d/*.conf --
-- /etc/idmapd.conf --
[General]
Verbosity = 0
[Mapping]
Nobody-User = nobody
Nobody-Group = nogroup
-- /etc/fstab --
nas-fast:/home  /nas/home   nfs defaults,auto,nfsvers=4 
0 0
nas-fast:/home/james/nas/home/james nfs 
defaults,auto,nfsvers=4 0 0
nas-fast:/home/maeve/nas/home/maeve nfs 
defaults,auto,nfsvers=4,sync 0 0
nas-fast:/home/sneezy   /nas/home/sneezynfs 
defaults,auto,nfsvers=4,sync 0 0
## On kernel version 4.16.0-0.bpo.2-amd64 we seem to get system crashes on some 
NFS I/O with nfs4.
nas-fast:/nas/books   /nas/books
nfsdefaults,auto,nfsvers=4,sync 0 0
nas-fast:/nas/music   /nas/music
nfsdefaults,auto,nfsvers=4,sync 0 0
nas-fast:/nas/photo   /nas/photo
nfsdefaults,auto,nfsvers=4,sync 0 0
nas-fast:/nas/video /nas/video nfs4 defaults,proto=tcp,bg 0 0
nas-fast:/nas/video/Kids /nas/video/Kids nfs4 defaults,proto=tcp,bg 0 0
nas-fast:/nas/video/TV /nas/video/TV nfs4 defaults,proto=tcp,bg 0 0
nas-fast:/nas/video/TV/Comedy /nas/video/TV/Comedy nfs4 defaults,proto=tcp,bg 0 0
nas-fast:/nas/video/TV/Crime /nas/video/TV/Crime nfs4 defaults,proto=tcp,bg 0 0
nas-fast:/nas/video/TV/Documentary /nas/video/TV/Documentary nfs4 
defaults,proto=tcp,bg 0 0
nas-fast:/nas/video/TV/Drama /nas/video/TV/Drama nfs4 defaults,proto=tcp,bg 0 0
nas-fast:/nas/video/TV/Tech /nas/video/TV/Tech nfs4 defaults,proto=tcp,bg 0 0
nas-v6:/nas/video/movies /nas/video/movies nfs4 defaults,proto=tcp,bg 0 0
nas:/var/lib/libvirt/images /var/lib/libvirt/images/jupiter 
   nfs   defaults,auto,ro 0 0
nas-fast:/nas/install-files /nas/install-files nfs defaults,proto=tcp,bg 0 0
nas-fast:/nas/preservation /nas/preservation   nfs defaults,proto=tcp,bg 0 0
nas-fast:/nas/share /nas/share   nfs defaults,proto=tcp,bg 0 0
nas-fast:/nas/video/TV/Historical_Drama /nas/video/TV/Historical_Drama nfs4 
defaults,proto=tcp,bg 0 0
nas-fast:/nas/video/TV/Medical_Drama /nas/video/TV/Medical_Drama nfs4 
defaults,proto=tcp,bg 0 0
nas-fast:/nas/video/TV/Romantic_Comedy /nas/video/TV/Romantic_Comedy nfs4 
defaults,proto=tcp,bg 0 0
nas-fast:/nas/video/TV/SF_and_Fantasy /nas/video/TV/SF_and_Fantasy nfs4 
defaults,proto=tcp,bg 0 0
-- /proc/mounts --
nas-fast:/nas/music /nas/music nfs4 
rw,sync,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.10.1.2,local_lock=none,addr=10.10.1.1
 0 0
nas-fast:/nas/preservation /nas/preservation nfs4 
rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.10.1.2,local_lock=none,addr=10.10.1.1
 0 0
nas-fast:/nas/photo /nas/photo nfs4 
rw,sync,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.10.1.2,local_lock=none,addr=10.10.1.1
 0 0
nas-fast:/nas/video /nas/video nfs4 
rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.10.1.2,local_lock=none,addr=10.10.1.1
 0 0
nas-fast:/nas/books /nas/books nfs4 
rw,sync,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.10.1.2,local_lock=none,addr=10.10.1.1
 0 0
nas-fast:/nas/share /nas/share nfs4 

Bug#1051087: reportbug: linux-headers-amd64 from bullseye-backports cannot be installed (unmet dependencies)

[Laurent BRULET]

Package: linux-headers-amd64
Version: 6.1.27-1~bpo11+1
Severity: important
X-Debbugs-Cc: spm-deb...@lebernie.net

Dear Maintainer,

It seems that linux-headers-amd64 package (6.1.27-1~bpo11+1) from
bullseye-backports cannot be installed.  Because it depends on
linux-headers-6.1.0-0.deb11.9-amd64 (= 6.1.27-1~bpo11+1), which is not
installable.

As a consequence, DKMS modules are not built after an upgrade. Therefore
hardware devices depending on DKMS modules will not work anymore.

Steps to reproduce, starting with a fresh install of
debian-11.7.0-amd64-netinst.iso:

  * add the following APT source in /etc/apt/sources.list:
deb http://deb.debian.org/debian bullseye-backports main contrib non-free"
  * apt update
  * apt install -t bullseye-backports linux-image-amd64
-> ok: kernel 6.1 is successfully installed
  * apt install -r bullseye-backports linux-headers-amd64
-> not ok: installation fails with the following message:

  Some packages could not be installed. This may mean that you have
  requested an impossible situation or if you are using the unstable
  distribution that some required packages have not yet been created
  or been moved out of Incoming.
  The following information may help to resolve the situation:
  
  The following packages have unmet dependencies:
   linux-headers-amd64 : Depends: linux-headers-6.1.0-0.deb11.9-amd64 (= 
6.1.27-1~bpo11+1) but it is not installable
  E: Unable to correct problems, you have held broken packages.

I'm not totally sure it is actually a bug, please excuse me if I did something
wrong.

Regards,

LB.

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

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

Versions of packages linux-headers-amd64 depends on:
pn  linux-headers-5.10.0-22-amd64
pn  linux-headers-5.10.0-25-amd64
pn  linux-headers-6.1.0-0.deb11.9-amd64  

linux-headers-amd64 recommends no packages.

linux-headers-amd64 suggests no packages.

Bug#1051086: general: networking misconfigured and unusable after bookworm upgrade

[D. R. Evans]

Package: general
Severity: important

Dear Maintainer,

   * What led up to the situation?
   
Upgrade from bullseye to bookworm. Everything worked before the upgrade.   
   
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
 
Details of the original problem may be found at:
  https://lists.debian.org/debian-user/2023/09/msg00024.html
 
Extracting from that post:


  When I booted the machine after the upgrade [from bullseye to bookworm], no 
networking was working at all, on either interface, even though:




zserver# nmcli networking connectivity
full
zserver#



which was definitely a lie, as nothing was successfully going in or out of the 
machine.


Looking in more detail:



[Z:~] nmcli
enp12s0: connected to Wired connection enp11s0(eth0)
"Intel I210"
ethernet (igb), D8:50:E6:C2:76:03, hw, mtu 1500
ip4 default
inet4 209.97.232.18/24
route4 209.97.232.0/24 metric 100
route4 default via 209.97.232.1 metric 100
inet6 fe80::e0c1:20a:c535:873c/64
route6 fe80::/64 metric 1024

lo: connected (externally) to lo
"lo"
loopback (unknown), 00:00:00:00:00:00, sw, mtu 65536
inet4 127.0.0.1/8
inet6 ::1/128

enp11s0: disconnected
"Intel I210"
1 connection available
ethernet (igb), D8:50:E6:C2:76:02, hw, mtu 1500

enp13s0: unavailable
"Intel I210"
ethernet (igb), D8:50:E6:C2:76:04, hw, mtu 1500

enp14s0: unavailable
"Intel I210"
ethernet (igb), D8:50:E6:C2:76:05, hw, mtu 1500

DNS configuration:
servers: 127.0.0.1 209.97.224.2 209.97.224.3
interface: enp12s0



Somehow, it had got into a state where enp12s0 was connected to enp11s0 
(whatever that means), with the result that nothing worked.


So, after a bit of messing around with an increasing sense of desperation, I 
discovered that:




[Z:~] sudo nmcli connection down "Wired connection enp11s0(eth0)"

Connection 'Wired connection enp11s0(eth0)' successfully deactivated (D-Bus 
active path: /org/freedesktop/NetworkManager/ActiveConnection/2)


[Z:~] sudo nmcli connection up "Wired connection enp11s0(eth0)"

Connection successfully activated (D-Bus active path: 
/org/freedesktop/NetworkManager/ActiveConnection/4)




resulted in:



[Z:~] nmcli
enp11s0: connected to Wired connection enp11s0(eth0)
"Intel I210"
ethernet (igb), D8:50:E6:C2:76:02, hw, mtu 1500
ip4 default
inet4 209.97.232.18/24
route4 209.97.232.0/24 metric 101
route4 default via 209.97.232.1 metric 101
inet6 fe80::1ae1:dfcf:be36:f72f/64
route6 fe80::/64 metric 1024

enp12s0: connected to Wired connection enp12s0(eth1)
"Intel I210"
ethernet (igb), D8:50:E6:C2:76:03, hw, mtu 1500
inet4 192.168.0.1/24
route4 192.168.0.0/24 metric 100
inet6 fe80::d30e:86f6:ca86:8986/64
route6 fe80::/64 metric 1024

lo: connected (externally) to lo
"lo"
loopback (unknown), 00:00:00:00:00:00, sw, mtu 65536
inet4 127.0.0.1/8
inet6 ::1/128

enp13s0: unavailable
"Intel I210"
ethernet (igb), D8:50:E6:C2:76:04, hw, mtu 1500

enp14s0: unavailable
"Intel I210"
ethernet (igb), D8:50:E6:C2:76:05, hw, mtu 1500

DNS configuration:
servers: 127.0.0.1 209.97.224.2 209.97.224.3
interface: enp11s0



and indeed, everything was now working.



Skipping a bunch of stuff in the thread that started at 
https://lists.debian.org/debian-user/2023/09/msg00024.html, I eventually found 
that adding the lines:



nmcli connection down "Wired connection enp11s0(eth0)"
nmcli connection up "Wired connection enp11s0(eth0)"



did NOT fix the problem, even though when I entered those same commands 
manually post-boot, the network did begin to function properly. (That is, when 
I put those line in rc.local, then enp12s0 was still connected to enp11s0 at 
the end of the boot process.)

After considerable experimentation I found that the result was unchanged if I 
tried:



nmcli connection down "Wired connection enp11s0(eth0)"
sleep 10
nmcli connection up "Wired connection enp11s0(eth0)"



BUT, if I changed the sleep time to 20:

nmcli connection down "Wired connection enp11s0(eth0)"
sleep 20
nmcli connection up "Wired connection enp11s0(eth0)"



networking was function correctly post-boot.

This is all completely reproducible here.
 
   * What was the outcome of this action?
   
Without changing the networking either in rc.local (with a considerable delay 
between the commands) or manually folllowing compleion of the boot process, 
networking does not work. In particular nmcli says:


enp12s0: connected to Wired connection enp11s0(eth0) <-- this seems really 
weird
"Intel I210"
ethernet (igb), D8:50:E6:C2:76:03, hw, mtu 1500
ip4 default
inet4 

Bug#1051085: dpkg: dpkg-db-backup.timer stopped after upgrades

[Sven Joachim]

Package: dpkg
Version: 1.22.0
Severity: normal

Upgrading dpkg stops the dpkg-db-backup.timer, which seems rather
undesirable, as it the timer remains inactive until the next reboot or
until it is started manually:

,
| $ systemctl status dpkg-db-backup.timer 
| ● dpkg-db-backup.timer - Daily dpkg database backup timer
|  Loaded: loaded (/lib/systemd/system/dpkg-db-backup.timer; enabled; 
preset: enabled)
|  Active: active (waiting) since Sat 2023-09-02 13:42:29 CEST; 2h 39min ago
| Trigger: Sun 2023-09-03 00:00:00 CEST; 7h left
|Triggers: ● dpkg-db-backup.service
|Docs: man:dpkg(1)
| 
| Sep 02 13:42:29 turtle systemd[1]: Started dpkg-db-backup.timer - Daily dpkg 
database backup timer.
| $ sudo apt install --reinstall dpkg
| [...]
| $ systemctl status dpkg-db-backup.timer
| ○ dpkg-db-backup.timer - Daily dpkg database backup timer
|  Loaded: loaded (/lib/systemd/system/dpkg-db-backup.timer; enabled; 
preset: enabled)
|  Active: inactive (dead) since Sat 2023-09-02 16:22:46 CEST; 11s ago
|Duration: 2h 40min 16.665s
| Trigger: n/a
|Triggers: ● dpkg-db-backup.service
|Docs: man:dpkg(1)
|
| Sep 02 13:42:29 turtle systemd[1]: Started dpkg-db-backup.timer - Daily dpkg 
database backup timer.
| Sep 02 16:22:46 turtle systemd[1]: dpkg-db-backup.timer: Deactivated 
successfully.
| Sep 02 16:22:46 turtle systemd[1]: Stopped dpkg-db-backup.timer - Daily dpkg 
database backup timer.
`

It seems to me that commit 64a648e7db91 ("debian: Do not start the
dpkg-db-backup timer during installation") was wrong.  Surely, it
avoids the "dpkg-db-backup.service is a disabled or a static unit
not running, not starting it." notice during upgrades, but the timer
(not the service!) should still be (re-)started.


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

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

Versions of packages dpkg depends on:
ii  libbz2-1.0   1.0.8-5+b1
ii  libc62.37-7
ii  liblzma5 5.4.4-0.1
ii  libmd0   1.1.0-1
ii  libselinux1  3.5-1
ii  libzstd1 1.5.5+dfsg2-1
ii  tar  1.34+dfsg-1.2
ii  zlib1g   1:1.2.13.dfsg-3

dpkg recommends no packages.

Versions of packages dpkg suggests:
ii  apt2.7.3
pn  debsig-verify  

-- no debconf information

Bug#1051084: bookworm-pu: package kernelshark/2.2.1-1~deb12u1

[Sebastian Andrzej Siewior]

Package: release.debian.org
Control: affects -1 + src:kernelshark
User: release.debian@packages.debian.org
Usertags: pu
Tags: bookworm
Severity: normal

Upstream released a new version which contains two fixes:
- kernel-shark: Fix segfault in libkshark-tepdata
  
https://git.kernel.org/pub/scm/utils/trace-cmd/kernel-shark.git/commit/?id=9f2097c9669fb7d5f72351343f34fb86649d1365
- kernel-shark: Fix Capture if directory contains space
  
https://git.kernel.org/pub/scm/utils/trace-cmd/kernel-shark.git/commit/?id=e2dc994a60e539e2db3ea9dd58fb11bf18255051

The former is critical since a lot of traces are affected by this bug
which results in segfault of kernelshark. The latter is nice to have and
easy to review.
I didn't figure out why some traces are not affected and some are not.
Kurt tested the 2.2.1 version before reporting #1049866 and confirmed
that the problems are gone.
The 2.2.1 version has been uploaded to unstable and testing by Sudipm.
He also uploaded the 2.2.1 version to Bookworm-Backports. However given
the impact of the bug and code change I think it is best address it in
Bookworm. Otherwise every regular user has to figure out that it is
fixed in -bpo and enable it.

Besides the new upstream version, the update also contains an updated
package description. This package (kernelshark) is basically a fronted
for the output for the trace data recorded by trace-cmd and does not
contain the utility (as claimed by the package description).

I didn't do any additional changes compared to what is unstable. If this
update is approved then I would file a rm for the bpo version which is
superseded.

Sebastian
diff -Nru kernelshark-2.2.0/bin/kshark-su-record kernelshark-2.2.1/bin/kshark-su-record
--- kernelshark-2.2.0/bin/kshark-su-record	2023-01-21 11:42:13.0 +0100
+++ kernelshark-2.2.1/bin/kshark-su-record	2023-06-07 19:46:20.0 +0200
@@ -2,4 +2,4 @@
 
 xhost +si:localuser:root &>/dev/null
 
-pkexec kshark-record -o ${PWD}/trace.dat
+pkexec kshark-record -o "${PWD}/trace.dat"
diff -Nru kernelshark-2.2.0/CMakeLists.txt kernelshark-2.2.1/CMakeLists.txt
--- kernelshark-2.2.0/CMakeLists.txt	2023-01-21 11:42:13.0 +0100
+++ kernelshark-2.2.1/CMakeLists.txt	2023-06-07 19:46:20.0 +0200
@@ -7,7 +7,7 @@
 set(KS_APP_NAME "kernelshark")
 set(KS_VERSION_MAJOR 2)
 set(KS_VERSION_MINOR 2)
-set(KS_VERSION_PATCH 0)
+set(KS_VERSION_PATCH 1)
 set(KS_VERSION_STRING ${KS_VERSION_MAJOR}.${KS_VERSION_MINOR}.${KS_VERSION_PATCH})
 message("\n project: Kernel Shark: (version: ${KS_VERSION_STRING})\n")
 
diff -Nru kernelshark-2.2.0/debian/changelog kernelshark-2.2.1/debian/changelog
--- kernelshark-2.2.0/debian/changelog	2023-05-05 21:37:24.0 +0200
+++ kernelshark-2.2.1/debian/changelog	2023-09-02 15:29:41.0 +0200
@@ -1,3 +1,12 @@
+kernelshark (2.2.1-1~deb12u1) bookworm; urgency=medium
+
+  [ Sudip Mukherjee ]
+  * New upstream version 2.2.1 (Closes: #1049866)
+- Update links for version update.
+  * Fix package description. (Closes: #1028585)
+
+ -- Sebastian Andrzej Siewior   Sat, 02 Sep 2023 15:29:41 +0200
+
 kernelshark (2.2.0-2) unstable; urgency=medium
 
   * Fix symlink names. (Closes: #1035449)
diff -Nru kernelshark-2.2.0/debian/control kernelshark-2.2.1/debian/control
--- kernelshark-2.2.0/debian/control	2023-02-05 01:46:52.0 +0100
+++ kernelshark-2.2.1/debian/control	2023-08-16 22:00:24.0 +0200
@@ -29,9 +29,9 @@
 Depends: ${shlibs:Depends}, ${misc:Depends},
  trace-cmd (>= 2.9.3), fonts-freefont-ttf,
  pkexec
-Description: Utility for retrieving and analyzing function tracing in the kernel
- This package contains the trace-cmd utility. Trace-cmd makes it easy to
- retrieve and analyze function traces from the Linux kernel while it is running.
+Description: Utilities for graphically analyzing function tracing in the kernel
+ KernelShark is a front end reader of trace-cmd output. It reads a trace-cmd.dat
+ formatted file and produces a graph and list view of the data.
 
 Package: libkshark2
 Section: libs
diff -Nru kernelshark-2.2.0/debian/libkshark2.links kernelshark-2.2.1/debian/libkshark2.links
--- kernelshark-2.2.0/debian/libkshark2.links	2023-05-05 21:05:16.0 +0200
+++ kernelshark-2.2.1/debian/libkshark2.links	2023-08-16 21:55:47.0 +0200
@@ -1,2 +1,2 @@
-usr/lib/${DEB_HOST_MULTIARCH}/libkshark-gui.so.2.2.0 usr/lib/${DEB_HOST_MULTIARCH}/libkshark-gui.so.2
-usr/lib/${DEB_HOST_MULTIARCH}/libkshark-plot.so.2.2.0 usr/lib/${DEB_HOST_MULTIARCH}/libkshark-plot.so.2
+usr/lib/${DEB_HOST_MULTIARCH}/libkshark-gui.so.2.2.1 usr/lib/${DEB_HOST_MULTIARCH}/libkshark-gui.so.2
+usr/lib/${DEB_HOST_MULTIARCH}/libkshark-plot.so.2.2.1 usr/lib/${DEB_HOST_MULTIARCH}/libkshark-plot.so.2
diff -Nru kernelshark-2.2.0/src/libkshark-tepdata.c kernelshark-2.2.1/src/libkshark-tepdata.c
--- kernelshark-2.2.0/src/libkshark-tepdata.c	2023-01-21 11:42:13.0 +0100
+++ kernelshark-2.2.1/src/libkshark-tepdata.c	2023-06-07 19:46:20.0 +0200
@@ 

Bug#1051032: telegram-desktop: Duplicate telegram icon on Dash, with default icon and label "org.telegram"

[Nicholas Guriev]

Hello,

On Fri, 01 Sep 2023 22:00:02 +0800 Eni  wrote:
>   After upgrade telegram-desktop from 4.8.1+ds-2 to 4.9.3+ds-1, no matter 
> whether the
> telegram-desktop is pin to dash (in GNOME), if launch telegram, it will show 
> a default
> diamond icon with gears in dash, and if put pointer on it, it shows a label 
> with text
> "org.telegram", and the icon and name in the left of top panel shows a gears 
> icon and
> "org.telegram", not "Telegram Desktop".

This could have been related to shortening the dot desktop name in Ilya Fedin's
change. I will try to revert it and see what happens.

https://github.com/telegramdesktop/tdesktop/commit/0534a2fb6213a2c05e06c4a1f7668a9c31b6c326

>   I have compared the dot desktop file with previous version, only one line
> "DBusActivatable=true" is added in current version, is it the reason that 
> telegram not 
> matches the icon in dash?
> 
> $ desktop-file-validate /usr/share/applications/org.telegram.desktop.desktop 
> /usr/share/applications/org.telegram.desktop.desktop: error: file contains key
> "SingleMainWindow" in group "Desktop Entry", but keys extending the format 
> should start
> with "X-"
> 
> And desktop file contains one error, is it a problem?

The SingleMainWindow key is defined in version 1.5 of the Desktop Entry
Specification and it is designated for applications that do not spawn a new
window on launching from the menu. But the tool just do not support the latest
specification. So that is not the problem.

Bug#1042933: octave-statistics autopkg tests fail in unstable on amd64

[Sébastien Villemot]

Le jeudi 31 août 2023 à 15:12 +0200, Rafael Laboissière a écrit :
> * Rafael Laboissière  [2023-08-31 15:01]:
> 
> > * Sébastien Villemot  [2023-08-31 12:05]:
> > 
> > > Le jeudi 03 août 2023 à 08:33 +0200, Rafael Laboissière a écrit :
> > > > 
> > > > Just for the record, this is the offending unit test:
> > > > 
> > > > 308s [inst/ConfusionMatrixChart.m]
> > > > 308s >
> > > > 
> > > > /tmp/autopkgtest-lxc.9x_h6bvs/downtmp/build.BGX/src/inst/ConfusionMatrixChart.m
> > > > 308s * demo
> > > > 308s  ## Create a simple ConfusionMatrixChart Object
> > > > 308s
> > > > 308s  cm = ConfusionMatrixChart (gca, [1 2; 1 2], 
> > > > {"A","B"},{"XLabel","LABEL A"})
> > > > 308s  NormalizedValues = cm.NormalizedValues
> > > > 308s  ClassLabels = cm.ClassLabels
> > > > 308s * shared visibility_setting
> > > > 308s  visibility_setting = get (0, "DefaultFigureVisible");
> > > > 308s * test
> > > > 308s  set (0, "DefaultFigureVisible", "off");
> > > > 308s  cm = ConfusionMatrixChart (gca, [1 2; 1 2], 
> > > > {"A","B"},{"XLabel","LABEL A"});
> > > > 308s  assert (isa (cm, "ConfusionMatrixChart"), true);
> > > > 308s  set (0, "DefaultFigureVisible", visibility_setting);
> > > > 308s warning: Non-positive limit for logarithmic axis ignored
> > > > 308s ! test failed
> > > > 308s set: "cameratarget" must be finite
> > > > 308s shared variables visibility_setting = on
> > > > 308s 1 test, 0 passed, 0 known failure, 0 skipped
> > > > 
> > > > We have seen this problem already elsewhere. I will try to 
> > > > investigate it.
> > > 
> > > Did you get to a conclusion?
> > 
> > No progress on my side, sorry.
> 
> At any rate, the last autopkgtest run (on 2023-08-26) succeded: 
> https://ci.debian.net/data/autopkgtest/unstable/amd64/o/octave-statistics/37186503/log.gz
> 
> Should we close this bug report?

It seems that the failures are random. They also occurred on Ubuntu.
I’m going to apply the patch that was added there.

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



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

Bug#1050929: telegram-desktop: System window decorations disabled on Wayland after 4.9.3

[Nicholas Guriev]

Hello,

On Thu, 31 Aug 2023 09:18:21 -0400 z411  wrote:
> I use KDE Plasma under Wayland and I've always used the window system
> decorations option in order to make my desktop visually consistent.
> 
> But after updating to 4.9.3, this option has suddenly disappeared. I
> asked upstream and they said the option was still there but it was most
> probably disabled by the package maintainer, so I come here to humbly ask
> to re-enable it if possible.

Set the QT_QPA_PLATFORM environment variable to "xcb" value before running
Telegram Desktop. And the setting will reappear because of XWayland.
In genuine Wayland there is no such thing as system decorations.

   $ QT_QPA_PLATFORM=xcb telegram-desktop

For some reason, that's not default anymore.

Bug#1050381: Bug#1041789: RM: unison-2.51+4.13.1 -- RoQA; newer version packaged

[Stéphane Glondu]

Le 29/07/2023 à 22:57, Vincent Lefevre a écrit :

Is this version really needed?

/usr/share/doc/unison-2.52/NEWS.md.gz says:

## Changes in 2.52.0

Released 2022-03-12

* Feature negotiation, compatible with 2.51.
* New archive format (independent of ocaml version, based on umarshal)
  Upgrade is automatic.
* New wire protocol (independent of ocaml version, based on umarshal)
  New protocol is used if both sides are >= 2.52.0.
[...]

But you could check and decide later.


I wanted to check that unison-2.53 is indeed compatible with 
unison-2.52, which seems to be the case.


I'll wait for unison-2.53 and meta-unison to migrate to testing, and 
then I'll ask for the removal of unison-2.52.



Cheers,

--
Stéphane

Bug#1051076: dash: test does not support s1 < s2 or s1 > s2

[Gian Piero Carrubba]

severity 1051076 grave
thanks

Thinking about it, grave seems a more appropriate severity as the issue 
could cause data loss in case s2 happens to be the pathname of an 
existent file when using the form `test s1 > s2`.

Bug#1041508: tex-common: fmutil fails to rebuild formats

[Norbert Preining]

On Sat, 02 Sep 2023, Joerg Dorchain wrote:
> Indeed.

That file is buggy:

 \HINTstream0 %main text
 \HINTstream\footins   
   \HINTsetstream\topins = %topinsert 
-prefered 0
+preferred 0
   {% 
 \HINTafter = {}
   }
   \HINTsetstream\footins =%footnotes
-prefered 255
+preferred 255
 ratio 0
   {%
 \hsize=300pt


The "prefered" needs to be changed to "preferred", then it works.

@Hilmar, that should be fixed by a new checkout, or patching the above.

Best

Norbert

--
PREINING Norbert  https://www.preining.info
Mercari Inc. + IFMGA Guide + TU Wien + TeX Live
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Bug#1051083: Please fix autopkgtest regression with file 1.45

[Christoph Biedl]

Source: nutsqlite
Version: 2.0.6-3
Severity: important
X-Debbugs-Cc: debian.a...@manchmal.in-ulm.de

Bonjour,

the latest upstream version of the file package introduced a detection
of SQLite write-ahead shared memory files. As a result, the autopkgtest
of nutsqlite breaks when using that version (1:5.45-1, currently in
experimental).

autopkgtest log:
https://ci.debian.net/data/autopkgtest/unstable/amd64/n/nutsqlite/37303558/log.gz

Please change run-unit-test

| test "$(file nut.db-shm | awk '{print $2}')" = 'data'

to something that, for the time being, can handle both this and the
future output of file(1), the first one can go away in the future.

It might be something like (untested):

```
test "$(file nut.db-shm | awk '{print $2}')" = 'data' ||
test "$(file nut.db-wal | awk '{print $2, $3, $4, $5}')" = 'SQLite Write-Ahead 
Log shared memory,'
```

This regression will prevent the file package from migrating to testing,
so I'd appreciate if implementing this wouldn't take too long.

Regards,

Christoph


signature.asc
Description: PGP signature

Bug#1051082: drkonqi: Crash report wizard complete, but drkonqi then sits for hours without completing send

[Carl Fink]

Package: drkonqi
Version: 5.27.5-2
Severity: normal

Dear Maintainer,

I was trying to report a KWin crash using drkonqi. I answered all the many
questions the "KWin - The KDE Crash Handler" window (which I believe is
drkonqi) asked me, pressed Submit, and ... it has been sitting there 
spinning
the little cogwheel for about 10 hours now, without actually sending. 
Ideally,
it should actually send the error report. Or at least time out 
eventually, not

sit there literally overnight, presumably retrying some sort of operation.
(It's very opaque what is actually going on.)

I mean, reportbug itself is weirdly hard to use, but at least it detects 
a failure

to send and tells the user what is happening.

-- System Information:
Debian Release: 12.1
  APT prefers stable-updatesVersions of packages drkonqi depends on:
ii  init-system-helpers    1.65.2
ii  kio    5.103.0-1
ii  libc6  2.36-9+deb12u1
ii  libgcc-s1  12.2.0-14
ii  libkf5configcore5  5.103.0-2
ii  libkf5configgui5   5.103.0-2
ii  libkf5coreaddons5  5.103.0-1
ii  libkf5crash5   5.103.0-1
ii  libkf5i18n5    5.103.0-1
ii  libkf5idletime5    5.103.0-2
ii  libkf5jobwidgets5  5.103.0-1
ii  libkf5kiocore5 5.103.0-1
ii  libkf5kiogui5  5.103.0-1
ii  libkf5notifications5   5.103.0-1
ii  libkf5service-bin  5.103.0-1
ii  libkf5service5 5.103.0-1
ii  libkf5syntaxhighlighting5  5.103.0-3
ii  libkf5wallet-bin   5.103.0-1
ii  libkf5wallet5  5.103.0-1
ii  libkf5widgetsaddons5   5.103.0-1
ii  libkf5windowsystem5    5.103.0-1
ii  libkuserfeedbackcore1  1.2.0-2
ii  libqt5core5a   5.15.8+dfsg-11
ii  libqt5dbus5    5.15.8+dfsg-11
ii  libqt5gui5 5.15.8+dfsg-11
ii  libqt5network5 5.15.8+dfsg-11
ii  libqt5qml5 5.15.8+dfsg-3
ii  libqt5widgets5 5.15.8+dfsg-11
ii  libstdc++6 12.2.0-14
ii  libsystemd0    252.12-1~deb12u1
ii  qml-module-org-kde-syntaxhighlighting  5.103.0-3

Versions of packages drkonqi recommends:
ii  systemd-coredump  252.12-1~deb12u1

drkonqi suggests no packages.

-- no debconf information


  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'stable')

Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-11-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE 
not set

Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#1009768: s3fs-fuse: Please replace mime-support with media-types in Depends

[Charles Plessy]

Hello,

s3fs-fuse is one of the last packages holding the mime-support
transition; I intend to NMU it soon with to close this bug.

Have a nice day,

Charles

Le Sun, Apr 17, 2022 at 02:32:04PM +0900, Charles Plessy a écrit :
> Source: s3fs-fuse
> Severity: normal
> X-Debbugs-Cc: ple...@debian.org
> 
> Dear s3fs maintainers,
> 
> In the previous release cycle, I have split the `mime-support` package
> into two: `media-types` supplies /etc/mime.types and `mailcap` supplies
> the mailcap system.  `mime-support` is now a transitional package that
> I would like to remove from Debian.
> 
> May I ask you to replace mime-support with media-types in s3fs's Depends ?
> 
> Have a nice day,
> 
> Charles
> 
> --
> Charles Plessy Nagahama, Yomitan, Okinawa, Japan
> Tooting from work,   https://mastodon.technology/@charles_plessy
> Tooting from home, https://framapiaf.org/@charles_plessy

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

Bug#1051081: dart: binary-any FTBFS with recent jdupes

[Aurelien Jarno]

Source: dart
Version: 6.12.1+dfsg4-12
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

Dear maintainer,

dart fails to build from source when building only binary-any and not
binary-all. From my build log on amd64:

| make[1]: Leaving directory '/<>/.pybuild/cpython3_3.11/build'
|debian/rules execute_after_dh_auto_install
| make[1]: Entering directory '/<>'
| rm -f debian/tmp/usr/share/doc/dart/data/screencap/.KEEP
| make[1]: Leaving directory '/<>'
|dh_install -a -O--buildsystem=pybuild
|dh_installdocs -a -O--buildsystem=pybuild
|dh_installchangelogs -a -O--buildsystem=pybuild
|dh_python3 -a -O--buildsystem=pybuild
|dh_installsystemduser -a -O--buildsystem=pybuild
|dh_perl -a -O--buildsystem=pybuild
|debian/rules execute_before_dh_link
| make[1]: Entering directory '/<>'
| jdupes -rl debian/dart-doc/usr
| 
| could not stat dir debian/dart-doc/usr
| No duplicates found.
| make[1]: *** [debian/rules:40: execute_before_dh_link] Error 1
| make[1]: Leaving directory '/<>'
| make: *** [debian/rules:19: binary-arch] Error 2
| dpkg-buildpackage: error: debian/rules binary-arch subprocess returned exit 
status 2

A full build log on riscv64 is also available:
https://buildd.debian.org/status/fetch.php?pkg=dart=riscv64=6.12.1%2Bdfsg4-12=1693507283=0

The return value of jdupes changed after bookworm to no longer return
success when the given paths do not exist, which causes this failure in
binary-any builds.

A possible untested patch is:

--- dart-6.12.1+dfsg4/debian/rules
+++ dart-6.12.1+dfsg4/debian/rules
@@ -36,5 +36,5 @@
 -X.sdf -X.skel -X.urdf -X.vsk -X.world \
 -X.c3d -X.changelog -X.dof -X.path -X.tris
 
-execute_before_dh_link:
+execute_before_dh_link-indep:
jdupes -rl debian/dart-doc/usr

Regards
Aurelien

Bug#1051079:

[Adam Baxter]

Apologies - missed changing the version, I have also tested apt 2.7.3 in sid 
and got the same message.

Thanks,
Adam

Bug#1051080: texlive-binaries: Failed tex-common fmtutil trigger

[Marc Glisse]

Package: texlive-binaries
Version: 2023.20230311.66589-3
Severity: normal

Dear Maintainer,

today's `apt upgrade` which consisted of

The following NEW packages will be installed:
  luametatex
The following packages will be upgraded:
  context context-modules gir1.2-adw-1 gir1.2-gtk-4.0 gir1.2-packagekitglib-1.0 
gnome-control-center gnome-control-center-data gstreamer1.0-packagekit jekyll 
lcdf-typetools libadwaita-1-0
  libayatana-ido3-0.4-0 libfreetype-dev libfreetype6 libgtk-4-1 libgtk-4-bin 
libgtk-4-common libgtk-4-dev libgtk-4-media-gstreamer libkpathsea6 liblzma-dev 
liblzma5 libpackagekit-glib2-18
  libpackagekit-glib2-dev libptexenc1 libsndfile1 libsynctex2 libtexlua53-5 
libtexluajit2 menhir octave octave-common octave-doc packagekit 
packagekit-tools pigz python3-colorama
  python3-pyproject-api python3-requests-toolbelt python3-sphinx-rtd-theme 
qtcreator qtcreator-data qtcreator-doc sphinx-rtd-theme-common texlive-binaries 
xz-utils

ended with

Processing triggers for tex-common (6.18) ...
Running mktexlsr. This may take some time... done.
Running mtxrun --generate. This may take some time... done.
Running updmap-sys. This may take some time... done.
Running mktexlsr /var/lib/texmf ... done.
Building format(s) --all.
This may take some time...
fmtutil failed. Output has been stored in
/tmp/fmtutil.SshoHJZZ
Please include this file if you report a bug.

The full output is available at
https://geometrica.saclay.inria.fr/team/Marc.Glisse/tmp/fmtutil.SshoHJZZ
, but the relevant part seems to be about hitex:


fmtutil [INFO]: --- remaking hitex with hitex
fmtutil: running `hitex -ini   -jobname=hitex -progname=hitex -etex -ltx 
hitex.ini' ...
This is HiTeX, Version 3.141592653-2.6-2.0 (TeX Live 2023) (INITEX)
entering extended mode
(hitex.ini (etex.src (plain.tex Preloading the plain format: codes, registers,
parameters, fonts, more fonts, macros, math definitions, output routines,
hyphenation (hyphen.tex [skipping from \patterns to end-of-file...]))
(etexdefs.lib Skipping module "grouptypes"; Loading module "interactionmodes";
Skipping module "nodetypes"; Skipping module "iftypes";) (language.def
(hyphen.tex) (loadhyph-ka.tex T8M Georgian hyphenation patterns
(conv-utf8-t8m.tex) (hyph-ka.tex)) (loadhyph-nn.tex
EC Norwegian Nynorsk hyphenation patterns (conv-utf8-ec.tex) (hyph-nn.tex
(hyph-no.tex))) (loadhyph-eo.tex IL3 Esperanto hyphenation patterns
(conv-utf8-il3.tex) (hyph-eo.tex)) (loadhyph-hu.tex
EC Hungarian hyphenation patterns (conv-utf8-ec.tex) (hyph-hu.tex))
(loadhyph-it.tex ASCII Italian hyphenation patterns (hyph-it.tex))
(loadhyph-de-1996.tex EC German hyphenation patterns (reformed orthography)
(dehyphn.tex
New German Hyphenation Patterns `dehyphn' Rev.31 <2001-05-07> (WaS)))
(loadhyph-la-x-classic.tex
EC Classical Latin hyphenation patterns, v.2.0 2019-07-03
(hyph-la-x-classic.ec.tex)) (loadhyph-es.tex EC Spanish hyphenation patterns
(conv-utf8-ec.tex) (hyph-es.tex)) (loadhyph-tk.tex
EC Turkmen hyphenation patterns (conv-utf8-ec.tex) (hyph-tk.tex))
(loadhyph-bg.tex T2A Bulgarian hyphenation patterns (conv-utf8-t2a.tex)
(hyph-bg.tex
Bulgarian hyphenation patterns (options: --safe-morphology --standalone-tex, ve
rsion 21 October 2017))) (loadhyph-sk.tex EC Slovak hyphenation patterns
(conv-utf8-ec.tex) (hyph-sk.tex)) (loadhyph-mk.tex
MACEDONIAN Macedonian hyphenation patterns (hyph-mk.macedonian.tex))
(loadhyph-hi.tex No Hindi hyphenation patterns - only for Unicode engines)
(loadhyph-be.tex T2A Belarusian hyphenation patterns (conv-utf8-t2a.tex)
(hyph-be.tex)) (loadhyph-rm.tex ASCII Romansh hyphenation patterns (hyph-rm.tex
)) (loadhyph-la-x-liturgic.tex EC Liturgical Latin hyphenation patterns
(hyph-la-x-liturgic.ec.tex)) (loadhyph-cop.tex Coptic hyphenation patterns
(copthyph.tex)) (loadhyph-nl.tex EC Dutch hyphenation patterns
(conv-utf8-ec.tex) (hyph-nl.tex)) (loadhyph-en-gb.tex
ASCII Hyphenation patterns for British English (hyph-en-gb.tex))
(loadhyph-mr.tex No Marathi hyphenation patterns - only for Unicode engines)
(loadhyph-or.tex No Oriya hyphenation patterns - only for Unicode engines)
(loadhyph-ru.tex T2A Russian hyphenation patterns (ruhyphen.tex (catkoi.tex)
(koi2t2a.tex) (ruhyphal.tex) (cyryoal.tex) (hypht2.tex))) (loadhyph-gu.tex
No Gujarati hyphenation patterns - only for Unicode engines) (loadhyph-hy.tex
No Armenian hyphenation patterns - only for Unicode engines)
(loadhyph-sr-latn.tex EC Serbian hyphenation patterns in Latin script
(conv-utf8-ec.tex) (hyph-sh-latn.tex)) (loadhyph-cu.tex
No Church Slavonic hyphenation patterns - only for Unicode engines)
(loadhyph-ta.tex No Tamil hyphenation patterns - only for Unicode engines)
(loadhyph-pi.tex No Pali hyphenation patterns - only for Unicode engines)
(loadhyph-th.tex LTH Thai hyphenation patterns (conv-utf8-lth.tex) (hyph-th.tex
)) (loadhyph-kmr.tex EC Kurmanji hyphenation patterns (conv-utf8-ec.tex)
(hyph-kmr.tex)) (loadhyph-id.tex ASCII Indonesian hyphenation patterns
(hyph-id.tex)) (loadhyph-pa.tex
No 

Bug#1042038: mfem: diff for NMU version 4.5.2+ds-1.1

[Gianfranco Costamagna]

Control: tags 1042038 + patch
Control: tags 1042038 + pending

Dear maintainer,

I've prepared an NMU for mfem (versioned as 4.5.2+ds-1.1) and
uploaded it.


Regards.
From: Gianfranco Costamagna 
To:   1042...@bugs.debian.org
Cc:
Bcc: 
Subject: mfem: diff for NMU version 4.5.2+ds-1.1
Date: Sat, 02 Sep 2023 14:12:16 +0200
X-NMUDIFF-Version: 2.22.1ubuntu1

Control: tags 1042038 + patch
Control: tags 1042038 + pending

[Replace XX with correct value]

Dear maintainer,

I've prepared an NMU for mfem (versioned as 4.5.2+ds-1.1) and
uploaded it to DELAYED/XX. Please feel free to tell me if I
should delay it longer.

Regards.

diff -Nru mfem-4.5.2+ds/debian/changelog mfem-4.5.2+ds/debian/changelog
--- mfem-4.5.2+ds/debian/changelog	2023-03-28 10:25:56.0 +0200
+++ mfem-4.5.2+ds/debian/changelog	2023-09-02 14:09:24.0 +0200
@@ -1,3 +1,13 @@
+mfem (4.5.2+ds-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+
+  [ Amin Bandali  ]
+  * Add upstream patch to fix FTBFS with gcc-13 (Closes: #1042038)
+- debian/patches/fix-ftbfs-gcc-13.patch
+
+ -- Gianfranco Costamagna   Sat, 02 Sep 2023 14:09:24 +0200
+
 mfem (4.5.2+ds-1) unstable; urgency=medium
 
   * Initial release. (Closes: #1023223)
diff -Nru mfem-4.5.2+ds/debian/patches/fix-ftbfs-gcc-13.patch mfem-4.5.2+ds/debian/patches/fix-ftbfs-gcc-13.patch
--- mfem-4.5.2+ds/debian/patches/fix-ftbfs-gcc-13.patch	1970-01-01 01:00:00.0 +0100
+++ mfem-4.5.2+ds/debian/patches/fix-ftbfs-gcc-13.patch	2023-09-02 14:09:24.0 +0200
@@ -0,0 +1,53 @@
+From 314a32af2ee80af8c9af7d8ad71babd51851154c Mon Sep 17 00:00:00 2001
+From: David Dement 
+Origin: https://github.com/mfem/mfem/commit/314a32af2ee80af8c9af7d8ad71babd51851154c
+Date: Thu, 27 Apr 2023 10:33:51 -0400
+Subject: [PATCH] Fixes comilation errors when compiling with gcc-13 on Fedora
+ 38
+
+When compiling with gcc-13, types such as uint64_t are not defined.
+It is likely that  is included implicitly with older compiler
+versions.
+---
+ general/hash.hpp| 1 +
+ general/mem_manager.cpp | 1 +
+ mesh/vtk.hpp| 2 ++
+ 3 files changed, 4 insertions(+)
+
+diff --git a/general/hash.hpp b/general/hash.hpp
+index 86d987d8029..288d51288df 100644
+--- a/general/hash.hpp
 b/general/hash.hpp
+@@ -16,6 +16,7 @@
+ #include "array.hpp"
+ #include "globals.hpp"
+ #include 
++#include 
+ 
+ namespace mfem
+ {
+diff --git a/general/mem_manager.cpp b/general/mem_manager.cpp
+index 416a6ac6203..37b80c878ad 100644
+--- a/general/mem_manager.cpp
 b/general/mem_manager.cpp
+@@ -16,6 +16,7 @@
+ #include  // std::memcpy, std::memcmp
+ #include 
+ #include  // std::max
++#include 
+ 
+ // Uncomment to try _WIN32 platform
+ //#define _WIN32
+diff --git a/mesh/vtk.hpp b/mesh/vtk.hpp
+index a59bed27592..50eeea5bc78 100644
+--- a/mesh/vtk.hpp
 b/mesh/vtk.hpp
+@@ -12,6 +12,8 @@
+ #ifndef MFEM_VTK
+ #define MFEM_VTK
+ 
++#include 
++
+ #include "../fem/geom.hpp"
+ #include "../general/binaryio.hpp"
+ 
diff -Nru mfem-4.5.2+ds/debian/patches/series mfem-4.5.2+ds/debian/patches/series
--- mfem-4.5.2+ds/debian/patches/series	2023-03-01 14:14:12.0 +0100
+++ mfem-4.5.2+ds/debian/patches/series	2023-09-02 14:09:24.0 +0200
@@ -1,2 +1,3 @@
 static-no-shared-yes
 not-makefile
+fix-ftbfs-gcc-13.patch


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1050639: clamav 1.0.2+dfsg-1~deb12u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1050639 = bookworm pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bookworm.

Thanks for your contribution!

Upload details
==

Package: clamav
Version: 1.0.2+dfsg-1~deb12u1

Explanation: new upstream stable release; security fixes [CVE-2023-20197 
CVE-2023-20212]

Bug#1050638: clamav 0.103.9+dfsg-0+deb11u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1050638 = bullseye pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bullseye.

Thanks for your contribution!

Upload details
==

Package: clamav
Version: 0.103.9+dfsg-0+deb11u1

Explanation: new upstream stable release; fix denial of service vulnerability 
via HFS+ parser [CVE-2023-20197]

Bug#1050713: --overwrite and mixed team workflows, and split brain

[Ian Jackson]

For now I'm at least adding a cross-reference from --overwrite
(in dgit(1)) to --split-view=always.

I still think we may want more guidance in this area, but it's
complicated.  A lot of it depends on individual foibles and opinions
of the co-maintainers, so an opinionated workflow guide isn't the
right answer.

Ian.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.

Bug#1051079: apt: When failing to parse .sources files, give more information in error messages

[Adam Baxter]

Package: apt
Version: 2.6.1
Severity: normal
X-Debbugs-Cc: deb...@voltagex.org

Dear Maintainer,

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

   * What led up to the situation?

I've made some kind of mistake in a deb822 .sources file. apt or some component 
of it can't parse the file and errors out
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
Tried to write my own deb822 format file instead of just using sources.list and 
solving this hours ago :)

   * What was the outcome of this action?

$ apt update
E: Unable to parse package file /etc/apt/sources.list.d/grafana.sources (1)
E: The list of sources could not be read.

   * What outcome did you expect instead?

Either:
* Skipping the "bad" file and emitting a warning OR
* A precise error message - what is wrong at what line and character.


Note this also broke reportbug itself, see #1051077

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


-- Package-specific info:

-- apt-config dump --

APT "";
APT::Architecture "amd64";
APT::Build-Essential "";
APT::Build-Essential:: "build-essential";
APT::Install-Recommends "1";
APT::Install-Suggests "0";
APT::Sandbox "";
APT::Sandbox::User "_apt";
APT::Authentication "";
APT::Authentication::TrustCDROM "true";
APT::NeverAutoRemove "";
APT::NeverAutoRemove:: "^firmware-linux.*";
APT::NeverAutoRemove:: "^linux-firmware$";
APT::NeverAutoRemove:: "^linux-image-[a-z0-9]*$";
APT::NeverAutoRemove:: "^linux-image-[a-z0-9]*-[a-z0-9]*$";
APT::VersionedKernelPackages "";
APT::VersionedKernelPackages:: "linux-.*";
APT::VersionedKernelPackages:: "kfreebsd-.*";
APT::VersionedKernelPackages:: "gnumach-.*";
APT::VersionedKernelPackages:: ".*-modules";
APT::VersionedKernelPackages:: ".*-kernel";
APT::Never-MarkAuto-Sections "";
APT::Never-MarkAuto-Sections:: "metapackages";
APT::Never-MarkAuto-Sections:: "tasks";
APT::Move-Autobit-Sections "";
APT::Move-Autobit-Sections:: "oldlibs";
APT::Architectures "";
APT::Architectures:: "amd64";
APT::Compressor "";
APT::Compressor::. "";
APT::Compressor::.::Name ".";
APT::Compressor::.::Extension "";
APT::Compressor::.::Binary "";
APT::Compressor::.::Cost "0";
APT::Compressor::zstd "";
APT::Compressor::zstd::Name "zstd";
APT::Compressor::zstd::Extension ".zst";
APT::Compressor::zstd::Binary "zstd";
APT::Compressor::zstd::Cost "60";
APT::Compressor::zstd::CompressArg "";
APT::Compressor::zstd::CompressArg:: "-19";
APT::Compressor::zstd::UncompressArg "";
APT::Compressor::zstd::UncompressArg:: "-d";
APT::Compressor::lz4 "";
APT::Compressor::lz4::Name "lz4";
APT::Compressor::lz4::Extension ".lz4";
APT::Compressor::lz4::Binary "false";
APT::Compressor::lz4::Cost "50";
APT::Compressor::gzip "";
APT::Compressor::gzip::Name "gzip";
APT::Compressor::gzip::Extension ".gz";
APT::Compressor::gzip::Binary "gzip";
APT::Compressor::gzip::Cost "100";
APT::Compressor::gzip::CompressArg "";
APT::Compressor::gzip::CompressArg:: "-6n";
APT::Compressor::gzip::UncompressArg "";
APT::Compressor::gzip::UncompressArg:: "-d";
APT::Compressor::xz "";
APT::Compressor::xz::Name "xz";
APT::Compressor::xz::Extension ".xz";
APT::Compressor::xz::Binary "xz";
APT::Compressor::xz::Cost "200";
APT::Compressor::xz::CompressArg "";
APT::Compressor::xz::CompressArg:: "-6";
APT::Compressor::xz::UncompressArg "";
APT::Compressor::xz::UncompressArg:: "-d";
APT::Compressor::bzip2 "";
APT::Compressor::bzip2::Name "bzip2";
APT::Compressor::bzip2::Extension ".bz2";
APT::Compressor::bzip2::Binary "bzip2";
APT::Compressor::bzip2::Cost "300";
APT::Compressor::bzip2::CompressArg "";
APT::Compressor::bzip2::CompressArg:: "-6";
APT::Compressor::bzip2::UncompressArg "";
APT::Compressor::bzip2::UncompressArg:: "-d";
APT::Compressor::lzma "";
APT::Compressor::lzma::Name "lzma";
APT::Compressor::lzma::Extension ".lzma";
APT::Compressor::lzma::Binary "xz";
APT::Compressor::lzma::Cost "400";
APT::Compressor::lzma::CompressArg "";
APT::Compressor::lzma::CompressArg:: "--format=lzma";
APT::Compressor::lzma::CompressArg:: "-6";
APT::Compressor::lzma::UncompressArg "";
APT::Compressor::lzma::UncompressArg:: "--format=lzma";
APT::Compressor::lzma::UncompressArg:: "-d";
Dir "/";
Dir::State "var/lib/apt";
Dir::State::lists "lists/";
Dir::State::cdroms "cdroms.list";
Dir::State::extended_states "extended_states";
Dir::State::status "/var/lib/dpkg/status";
Dir::Cache "var/cache/apt";
Dir::Cache::archives "archives/";
Dir::Cache::srcpkgcache "srcpkgcache.bin";
Dir::Cache::pkgcache "pkgcache.bin";
Dir::Etc "etc/apt";
Dir::Etc::sourcelist "sources.list";
Dir::Etc::sourceparts "sources.list.d";
Dir::Etc::main "apt.conf";
Dir::Etc::netrc "auth.conf";
Dir::Etc::netrcparts "auth.conf.d";
Dir::Etc::parts "apt.conf.d";
Dir::Etc::preferences "preferences";
Dir::Etc::preferencesparts "preferences.d";
Dir::Etc::trusted "trusted.gpg";
Dir::Etc::trustedparts "trusted.gpg.d";
Dir::Etc::apt-listchanges-main "listchanges.conf";
Dir::Etc::apt-listchanges-parts "listchanges.conf.d";

Bug#1050709: tar-ignore debian/source/options

[Ian Jackson]

Control: clone -1 -2
Control: reassign -2 debhelper
Control: retitle -2 Please adjust debian/source/options

Hi.

FTR, I didn't intend to draw this bug to your attention as the
debhelper maintainer.  #1050709 was addressed to dgit maintainers
about about how to deal with this situation in dgit.

I suggested in dgit that we might do one or more of the following
(numbering addded):

| 1. File a bug or MR against debhelper
| 2. Somehow ask that dpkg-source do something about this, but what ?
| 3. Have dgit detect this situation and at least explain it to the user
| 4. Have dgit generate a non-roundtrippable source package
|(probably very hard and also undesirable)

I am working on (3).  (4) seems wrong.  As for (2), that's already
#908742 and #908747.

Since you've engaged, let me do (1) now, and clone this bug
and address you as debhelper maintainer:

The fundamental principle of operation of dgit is that the git tree[1]
is *identical*[2] to result of dpkg-source -x.

Niels Thykier writes ("Bug#1050709: tar-ignore debian/source/options"):
> So this is a common pattern in my packages although it sometimes appears 
> in d/s/local-options rather than d/s/options.

dgit refuses to work with d/s/local-options, because they cannot be
included in the source package.  In debhelper it seems that someone
moved the ignores to d/s/options, probably for this reason.

> Basically, the issue is when you have something you want to have 
> locally, not in git and also not in the archive.

That's fine.  The correct approach is to make dpkg-source and git
agree with each other.  The problem with plain tar-ignore is that it
ignores .gitignore, which *is* in your git tree and is not ignored by
git.

See https://bugs.debian.org/908747

> Here the "local" directory is listed both in .gitignore and in 
> "tar-ignore", because I do not want it in git nor in the archive when I 
> do an upload.

Yes, that makes sense.

> To solve this, I add `tar-ignore=...` (for native packages) to 
> debian/source/(local-)options.  However, if you add that option, you end 
> up with the entire *.git* directory in the tarball.  To avoid that, I 
> add the `tar-ignore` on its own to get the sane defaults back.

Please change this to --tar-ignore=.git.  I.e., I think,
`tar-ignore=.git` in d/s/options.

I think that will cause dpkg-source to do the right things.  I tested
this locally and it seems to fix the problem.

Patch attached.

> PS: Not sure if this problem is specific to native packages, which I 
> happen to maintain a lot of (relative to other maintainers).

It's somewhat worse with non-native packages because things are more
complicated and there's all the different git workflows, but the basic
issue is the same.

Thanks,
Ian.

[1] The git tree uploaded to the dgit git server and seen via "dgit
clone".  There are split view modes for handling some, but not all,
deviations from this principle, notably patches-unapplied git trees.

[2] Except that there is no .pc directory in the git tree.

>From a1d7a8a5ef09938b372d3ae28b954552f6dd9e8e Mon Sep 17 00:00:00 2001
From: Ian Jackson 
Date: Sat, 2 Sep 2023 12:40:40 +0100
Subject: [PATCH] Update d/s/options to use less broad tarignore syntax

---
 debian/source/options | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/source/options b/debian/source/options
index edbbfb5b..2ac64523 100644
--- a/debian/source/options
+++ b/debian/source/options
@@ -1,2 +1,2 @@
-tar-ignore
+tar-ignore=.git
 tar-ignore=debhelper/.idea
-- 
2.20.1


-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.

Bug#1041508: tex-common: fmutil fails to rebuild formats

[Joerg Dorchain]

On Sat, Sep 02, 2023 at 08:35:31PM +0900, Norbert Preining wrote:
> On Sat, 02 Sep 2023, Joerg Dorchain wrote:
> > (hiplainpage.tex
> > ! Missing { inserted.
> 
> Very strange. Works on my upstream TeX Live.
> 
> Can you show me
>   hiplainpage.tex
> ?
> You can find it with
>   kpsewhich hiplainpage.tex
> it should be in
>   /usr/share/texlive/texmf-dist/tex/hitex/base/hiplainpage.tex

Indeed.


% Copyright 2017-2022 Martin Ruckert, Hochschule Muenchen, Lothstrasse 64, 
80336 Muenchen
%
% Permission is hereby granted, free of charge, to any person obtaining a copy
% of this software and associated documentation files (the "Software"), to deal
% in the Software without restriction, including without limitation the rights
% to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
% copies of the Software, and to permit persons to whom the Software is
% furnished to do so, subject to the following conditions:
%
% The above copyright notice and this permission notice shall be
% included in all copies or substantial portions of the Software.
%
% THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
% IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
% FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
% COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
% WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT
% OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
% THE SOFTWARE.
%
% Except as contained in this notice, the name of the copyright holders shall
% not be used in advertising or otherwise to promote the sale, use or other
% dealings in this Software without prior written authorization from the
% copyright holders.

\ifhint
% Usefull settings for HINT files
  \pretolerance=1000
  \tolerance=2000
  \emergencystretch=16pt
  \overfullrule=0pt
% HINT page template for footnotes and topinserts
  \dimen0=1.25\hsize
  \advance\dimen0 by -9pt
  \dimen1=1.25\vsize
  \advance\dimen1 by -9pt
\HINTsetpage1 = basic 
  priority 10
  width  \dimen0
  height \dimen1 
{%
\maxdepth=4pt
\topskip=10pt
\HINTstream\topins %topinsert
\HINTstream0 %main text
\HINTstream\footins   
  \HINTsetstream\topins = %topinsert 
prefered 0
  {% 
\HINTafter = {}
  }
  \HINTsetstream\footins =%footnotes
prefered 255
ratio 0
  {%
\hsize=300pt
\count\footins=1000 % the magnification factor
\skip\footins=\bigskipamount % the extra space needed
\dimen\footins=\vsize % maximum height on the page
\HINTbefore = 
 {\vskip\skip\footins
 \footnoterule}
\HINTafter = {}
  }
}% end page template
\fi

Additional Info:
# dpkg -S /usr/share/texlive/texmf-dist/tex/hitex/base/hiplainpage.tex
texlive-formats-extra: 
/usr/share/texlive/texmf-dist/tex/hitex/base/hiplainpage.tex
# dpkg-query -W|grep texlive-formats-extra
texlive-formats-extra   2022.20230122-4

According to https://tracker.debian.org/pkg/texlive-extra the new version from 
unstable could migrate to
testing tomorrow

Best regards,

Joerg

Bug#1041508: tex-common: fmutil fails to rebuild formats

[Norbert Preining]

On Sat, 02 Sep 2023, Joerg Dorchain wrote:
> (hiplainpage.tex
> ! Missing { inserted.

Very strange. Works on my upstream TeX Live.

Can you show me
hiplainpage.tex
?
You can find it with
kpsewhich hiplainpage.tex
it should be in
/usr/share/texlive/texmf-dist/tex/hitex/base/hiplainpage.tex
(AFAIR)

I get proper formats build.

Thanks in advance

Norbert

--
PREINING Norbert  https://www.preining.info
Mercari Inc. + IFMGA Guide + TU Wien + TeX Live
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Bug#1050933: aarch64: Miscompilation at O1 level (O0 is working)

[Matthias Klose]

Control: tags -1 + moreinfo

upstream asks for a self-contained test case. Not sure if that's something you 
tried in https://bugs.debian.org/1050415

Bug#1051077: reportbug fails to execute if there is an invalid file in sources.list.d

[Adam Baxter]

Package: reportbug
Version: 12.0.0
Severity: normal
X-Debbugs-Cc: deb...@voltagex.org

Dear Maintainer,

   * What led up to the situation?
 Tried to add a deb822 format .sources file to my system, then launch 
reportbug
 
   * What was the outcome of this action?
 Reportbug crashed with 

Traceback (most recent call last):
  File "/usr/bin/reportbug", line 40, in 
from reportbug import utils
  File "/usr/lib/python3/dist-packages/reportbug/utils.py", line 100, in 

_apt_cache = apt.Cache()
 ^^^
  File "/usr/lib/python3/dist-packages/apt/cache.py", line 170, in __init__
self.open(progress)
  File "/usr/lib/python3/dist-packages/apt/cache.py", line 232, in open
self._cache = apt_pkg.Cache(progress)
  ^^^
apt_pkg.Error: E:Unable to parse package file 
/etc/apt/sources.list.d/grafana.sources (1), E:The list of sources could not be 
read.


   * What outcome did you expect instead?
 reportbug to still work and perhaps warn about the invalid file. 
 IMO reportbug needs to be hardened against these kind of situations

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


-- Package-specific info:
** Environment settings:
INTERFACE="text"

** /home/voltagex/.reportbugrc:
reportbug_version "12.0.0"
mode novice
ui text
realname "Adam Baxter"
email "deb...@voltagex.org"
no-cc
list-cc-me
smtphost reportbug.debian.org

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

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

Versions of packages reportbug depends on:
ii  apt2.6.1
ii  python33.11.2-1+b1
ii  python3-reportbug  12.0.0
ii  sensible-utils 0.0.17+nmu1

reportbug recommends no packages.

Versions of packages reportbug suggests:
pn  claws-mail
ii  debconf   1.5.82
pn  debsums   
pn  default-mta | postfix | exim4 | mail-transport-agent  
pn  dlocate   
pn  emacs-bin-common  
ii  file  1:5.44-3
ii  gnupg 2.2.40-1.1
pn  python3-urwid 
pn  reportbug-gtk 
pn  xdg-utils 

Versions of packages python3-reportbug depends on:
ii  apt2.6.1
ii  file   1:5.44-3
ii  python33.11.2-1+b1
ii  python3-apt2.6.0
ii  python3-debian 0.1.49
ii  python3-debianbts  4.0.1
ii  python3-requests   2.28.1+dfsg-1
ii  sensible-utils 0.0.17+nmu1

python3-reportbug suggests no packages.

-- no debconf information
Enabled: yes
Types: deb
URIs: https://apt.grafana.com
Suites: stable
Components: main
Signed-By:
-BEGIN PGP PUBLIC KEY BLOCK-

mQGNBGTnhmkBDADUE+SzjRRyitIm1siGxiHlIlnn6KO4C4GfEuV+PNzqxvwYO+1r
mcKlGDU0ugo8ohXruAOC77Kwc4keVGNU89BeHvrYbIftz/yxEneuPsCbGnbDMIyC
k44UOetRtV9/59Gj5YjNqnsZCr+e5D/JfrHUJTTwKLv88A9eHKxskrlZr7Un7j3i
Ef3NChlOh2Zk9Wfk8IhAqMMTferU4iTIhQk+5fanShtXIuzBaxU3lkzFSG7VuAH4
CBLPWitKRMn5oqXUE0FZbRYL/6Qz0Gt6YCJsZbaQ3Am7FCwWCp9+ZHbR9yU+bkK0
Dts4PNx4Wr9CktHIvbypT4Lk2oJEPWjcCJQHqpPQZXbnclXRlK5Ea0NVpaQdGK+v
JS4HGxFFjSkvTKAZYgwOk93qlpFeDML3TuSgWxuw4NIDitvewudnaWzfl9tDIoVS
Bb16nwJ8bMDzovC/RBE14rRKYtMLmBsRzGYHWd0NnX+FitAS9uURHuFxghv9GFPh
eTaXvc4glM94HBUAEQEAAbQmR3JhZmFuYSBMYWJzIDxlbmdpbmVlcmluZ0BncmFm
YW5hLmNvbT6JAdQEEwEKAD4WIQS1Oud7rbYwpoMEYAWWP6J3EEWFRQUCZOeGaQIb
AwUJA8JnAAULCQgHAgYVCgkICwIEFgIDAQIeAQIXgAAKCRCWP6J3EEWFRUiADACa
i+xytv2keEFJWjXNnFAx6/obnHRcXOI3w6nH/zL8gNI7YN5jcdQT2NYvKVYTb3fW
GuMsjHWgat5Gq3AtJrOKABpZ6qeYNPk0Axn/dKtOTwXjZ4pKX3bbUYvVfs0fCEZv
B0HHIj2wI9kgMpoTrkj22LE8layZTPOoQ+3/FbLzS8hN3CYZj25mHN7bpZq8EbV3
8FW9EU0HM0tg6CvoxkRiVqAuAC0KnVIZAdhD4dlYKuncq64nMvT1A5wxSYbnE+uf
mnWQQhhS6BOwRqN054yw1FrWNDFsvnOSHmr8dIiriv+aZYvx5JQFJ7oZP3LwdYyg
ocQcAJA8HFTIk3P6uJiIF/zdDzocgdKs+IYDoId0hxX7sGCvqdrsveq8n3m7uQiN
7FvSiV0eXIdV4F7340kc8EKiYwpuYSaZX0UWKLenzlUvD+W4pZCWtoXzPsW7PKUt
q1xdW0+NY+AGLCvSJCc5F4S5kFCObfBAYBbldjwwJFocdq/YOvvWYTPyV7kJeJS5
AY0EZOeGaQEMALNIFUricEIwtZiX7vSDjwxobbqPKqzdek8x3ud0CyYlrbGHy0k+
FDEXstjJQQ1s9rjJSu3sv5wyg9GDAUH3nzO976n/ZZvKPti3p2XU2UFx5gYkaaFV
D56yYxqGY0YU5ft6BG+RUz3iEPg3UBUzt0sCIYnG9+CsDqGOnRYIIa46fu2/H9Vu
8JvvSq9xbsK9CfoQDkIcoQOixPuI4P7eHtswCeYR/1LUTWEnYQWsBCf57cEpzR6t
7mlQnzQo9z4i/kp4S0ybDB77wnn+isMADOS+/VpXO+M7Zj5tpfJ6PkKch3SGXdUy
3zht8luFOYpJr2lVzp7n3NwB4zW08RptTzTgFAaW/NH2JjYI+rDvQm4jNs08Dtsp
nm4OQvBA9Df/6qwMEOZ9i10ixqk+55UpQFJ3nf4uKlSUM7bKXXVcD/odq804Y/K4

Bug#1041508: tex-common: fmutil fails to rebuild formats

[Joerg Dorchain]

On Sat, Sep 02, 2023 at 08:08:01PM +0900, Norbert Preining wrote:
> 
> Sorry, copied the wrong line. That worked,
> The format that failed to build was hitex AFAIR, that would be
>   /var/lib/texmf/web2c/hitex/hitex.log

No problem

Bye,

Joerg



This is HiTeX, Version 3.141592653-2.6-2.0 (TeX Live 2023) (INITEX)  2 SEP 2023 
12:16
entering extended mode
entering Prote mode
**hitex.ini 
(hitex.ini (etex.src (plain.tex Preloading the plain format: codes, registers,
\maxdimen=\dimen10
\hideskip=\skip10
\centering=\skip11
\p@=\dimen11
\z@=\dimen12
\z@skip=\skip12
\voidb@x=\box10

parameters,
\smallskipamount=\skip13
\medskipamount=\skip14
\bigskipamount=\skip15
\normalbaselineskip=\skip16
\normallineskip=\skip17
\normallineskiplimit=\dimen13
\jot=\dimen14
\interdisplaylinepenalty=\count23
\interfootnotelinepenalty=\count24
 fonts, more fonts,
\itfam=\fam4
\slfam=\fam5
\bffam=\fam6
\ttfam=\fam7
 macros,
\strutbox=\box11
\mscount=\count25
\tabs=\box12
\tabsyet=\box13
\tabsdone=\box14
 math definitions,
\rootbox=\box15
\p@renwd=\dimen15
 output routines,
\headline=\toks10
\footline=\toks11
\footins=\insert254
\topins=\insert253

hyphenation (hyphen.tex [skipping from \patterns to end-of-file...]))
\et@xinput=\read0
\et@xtoks=\toks12

(etexdefs.lib Skipping module "grouptypes"; Loading module "interactionmodes";
Skipping module "nodetypes"; Skipping module "iftypes";) (language.def
\lang@USenglish=\language0

(hyphen.tex)
\lang@welsh=\language1
 (loadhyph-cy.tex EC Welsh hyphenation patterns (conv-utf8-ec.tex)
(hyph-cy.tex))
\lang@swedish=\language2
 (loadhyph-sv.tex EC Swedish hyphenation patterns
(conv-utf8-ec.tex) (hyph-sv.tex))
\lang@marathi=\language3
 (loadhyph-mr.tex
No Marathi hyphenation patterns - only for Unicode engines)
\lang@sanskrit=\language4
 (loadhyph-sa.tex
No Sanskrit hyphenation patterns - only for Unicode engines)
\lang@kannada=\language5
 (loadhyph-kn.tex
No Kannada hyphenation patterns - only for Unicode engines)
\lang@malayalam=\language6
 (loadhyph-ml.tex
No Malayalam hyphenation patterns - only for Unicode engines)
\lang@dutch=\language7
 (loadhyph-nl.tex
EC Dutch hyphenation patterns (conv-utf8-ec.tex) (hyph-nl.tex))
\lang@swissgerman=\language8

(loadhyph-de-ch-1901.tex
EC Swiss-German hyphenation patterns (traditional orthography)
(conv-utf8-ec.tex) (hyph-de-ch-1901.tex
Swiss-German Hyphenation Patterns (Traditional Orthography) `dehyphts-x' 2021-0
2-26 (WL)))
\lang@german-x-2022-03-16=\language9
 (dehypht-x-2022-03-16.tex dehyph-exptl: using an 8-bit TeX engine.
(dehypht-x-2022-03-16.pat
German Hyphenation Patterns (Traditional Orthography) `dehypht-x' 2022-03-16 (W
L)))
\lang@pali=\language10
 (loadhyph-pi.tex No Pali hyphenation patterns - only for Unicode engines)
\lang@turkish=\language11

(loadhyph-tr.tex EC Turkish hyphenation patterns (conv-utf8-ec.tex)
(hyph-tr.tex))
\lang@gujarati=\language12
 (loadhyph-gu.tex
No Gujarati hyphenation patterns - only for Unicode engines)
\lang@esperanto=\language13
 (loadhyph-eo.tex
IL3 Esperanto hyphenation patterns (conv-utf8-il3.tex) (hyph-eo.tex))
\lang@schoolfinnish=\language14

(loadhyph-fi-x-school.tex EC Finnish hyphenation patterns for school
(conv-utf8-ec.tex) (hyph-fi-x-school.tex))
\lang@uppersorbian=\language15
 (loadhyph-hsb.tex
EC Upper Sorbian hyphenation patterns (conv-utf8-ec.tex) (hyph-hsb.tex))
\lang@ngerman-x-2022-03-16=\language16

(dehyphn-x-2022-03-16.tex dehyph-exptl: using an 8-bit TeX engine.
(dehyphn-x-2022-03-16.pat
German Hyphenation Patterns (Reformed Orthography, 2006) `dehyphn-x' 2022-03-16
 (WL)))
\lang@piedmontese=\language17
 (loadhyph-pms.tex ASCII Piedmontese hyphenation patterns (hyph-pms.tex))
\lang@turkmen=\language18
 (loadhyph-tk.tex EC Turkmen hyphenation patterns (conv-utf8-ec.tex)
(hyph-tk.tex))
\lang@kurmanji=\language19
 (loadhyph-kmr.tex EC Kurmanji hyphenation patterns
(conv-utf8-ec.tex) (hyph-kmr.tex))
\lang@macedonian=\language20
 (loadhyph-mk.tex
MACEDONIAN Macedonian hyphenation patterns (hyph-mk.macedonian.tex))
\lang@hungarian=\language21

(loadhyph-hu.tex EC Hungarian hyphenation patterns (conv-utf8-ec.tex)
(hyph-hu.tex))
\lang@assamese=\language22
 (loadhyph-as.tex
No Assamese hyphenation patterns - only for Unicode engines)
\lang@latin=\language23
 (loadhyph-la.tex
EC Latin hyphenation patterns (conv-utf8-ec.tex) (hyph-la.tex))
\lang@interlingua=\language24

(loadhyph-ia.tex ASCII Hyphenation patterns for Interlingua (hyph-ia.tex))
\lang@german=\language25

(loadhyph-de-1901.tex EC German hyphenation patterns (traditional orthography)
(dehypht.tex
German Traditional Hyphenation Patterns `dehypht' Version 3.2a <1999/03/03>
(Formerly known under the name `ghyph31' and `ghyphen'.)))
\lang@irish=\language26
 (loadhyph-ga.tex
EC Irish hyphenation patterns (conv-utf8-ec.tex) (hyph-ga.tex))
\lang@telugu=\language27

(loadhyph-te.tex No Telugu hyphenation patterns - only for Unicode engines)
\lang@georgian=\language28

(loadhyph-ka.tex T8M Georgian hyphenation patterns