Bug#1025732: src:genimage: fails to migrate to testing for too long: FTBFS (testsuite fails) on 32 bits systems

[Paul Gevers]

Source: genimage
Version: 15-3
Severity: serious
Control: close -1 16-1
Tags: sid bookworm ftbfs
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

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


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


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


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


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


Paul

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



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1025690: [Pkg-rust-maintainers] Bug#1025690: rust-clap-3: please upgrade to v4

[Sylvestre Ledru]

Le 07/12/2022 à 23:20, Blair Noctis a écrit :

$ dev/list-rdeps.sh clap
Versions of rust-clap in unstable:
   librust-clap-dev 3.2.23-1

Versions of rdeps of rust-clap in unstable, that also exist in testing:
   librust-bat-dev  0.22.1-1 depends on
 librust-clap-3+default-dev (>= 3.2.20-~~),
   librust-bindgen+clap-dev 0.60.1-2 depends on 
librust-clap-3+default-dev,
   librust-cargo-binutils-dev   0.3.5-2  depends on
 librust-clap-2+default-dev (>= 2.33-~~),
   librust-cargo-c-dev  0.9.11-1 depends on 
librust-clap-3+cargo-dev (>= 3.1-~~), librust-clap-3+color-dev (>= 3.1-~~), 
librust-clap-3+default-dev (>= 3.1-~~), librust-clap-3+derive-dev (>= 3.1-~~),
   librust-cargo-dev0.63.1-2 depends on
 librust-clap-3+default-dev (>= 3.1.0-~~),
   librust-cbindgen+clap-dev0.24.3-2 depends on
 librust-clap-3+default-dev (>= 3.1-~~),
   librust-clap-complete-dev3.1.1-2  depends on
 librust-clap-3+std-dev (>= 3.1.0-~~),
   librust-clap-complete-fig-dev3.1.0-1+b1   depends on
 librust-clap-3+std-dev (>= 3.1.0-~~),
   librust-criterion-dev0.3.6-3  depends on
 librust-clap-2-dev (>= 2.33),
   librust-debcargo-dev 2.6.0-1  depends on 
librust-clap-3+cargo-dev, librust-clap-3+default-dev, 
librust-clap-3+derive-dev,
   librust-dotenv+clap-dev  0.15.0-2+b4  depends on 
librust-clap-2+default-dev,
   librust-filespooler-dev  1.2.2-2  depends on 
librust-clap-3+derive-dev (>= 3.1-~~), librust-clap-3+std-dev (>= 3.1-~~),
   librust-git-absorb-dev   0.6.7-1  depends on
 librust-clap-2+default-dev (>= 2.33-~~),
   librust-hexyl-dev0.8.0-2+b3   depends on 
librust-clap-2+color-dev, librust-clap-2+default-dev, 
librust-clap-2+suggestions-dev, librust-clap-2+wrap-help-dev,
X librust-rav1e-dev0.5.1-5  depends on  
   librust-clap-2+color-dev,
   librust-resource-proof-dev   1.0.39-4 depends on 
librust-clap-3+default-dev, librust-clap-3+derive-dev,
   librust-sequoia-wot-dev  0.2.0-1+b2   depends on 
librust-clap-2+default-dev (>= 2.33-~~), librust-clap-2+wrap-help-dev (>= 
2.33-~~),
   librust-structopt+color-dev  0.3.26-2 depends on
 librust-clap-2+color-dev (>= 2.33-~~),
   librust-structopt+debug-dev  0.3.26-2 depends on
 librust-clap-2+debug-dev (>= 2.33-~~),
   librust-structopt+default-dev0.3.26-2 depends on
 librust-clap-2+default-dev (>= 2.33-~~),
   librust-structopt-dev0.3.26-2 depends on
 librust-clap-2-dev (>= 2.33-~~),
   librust-structopt+doc-dev0.3.26-2 depends on
 librust-clap-2+doc-dev (>= 2.33-~~),
   librust-structopt+no-cargo-dev   0.3.26-2 depends on
 librust-clap-2+no-cargo-dev (>= 2.33-~~),
   librust-structopt+suggestions-dev0.3.26-2 depends on
 librust-clap-2+suggestions-dev (>= 2.33-~~),
   librust-structopt+wrap-help-dev  0.3.26-2 depends on
 librust-clap-2+wrap-help-dev (>= 2.33-~~),
   librust-structopt+yaml-dev   0.3.26-2 depends on
 librust-clap-2+yaml-dev (>= 2.33-~~),

Source packages in unstable whose autopkgtests are triggered by rust-clap:
   rust-addr2line   0.18.0-1 triggered 
by librust-clap-dev=3.2.23-1
   rust-bindgen 0.60.1-2 triggered 
by librust-clap-dev=3.2.23-1
   rust-clap-complete   3.1.1-2  triggered 
by librust-clap-dev=3.2.23-1
   rust-exacl   0.9.0-2  triggered 
by librust-clap-dev=3.2.23-1
   rust-hdrhistogram7.5.0-1  triggered 
by librust-clap-dev=3.2.23-1
   rust-stderrlog   0.5.3-1  triggered 
by librust-clap-dev=3.2.23-1
   rust-zstd0.11.2-1 triggered 
by librust-clap-dev=3.2.23-1


We can expect a steady (read: slow) upgrade.


I uploaded clap3 to help with this.
clap should be updated to 4. I just didn't find the time to do it (if you want 
to give it a try ;)

Cheers
Sylvestre

Bug#1025588: osmnx: FTBFS with Shapely 2.0

[Sebastiaan Couwenberg]

Control: tags -1 fixed-upstream

On 12/6/22 16:18, Bas Couwenberg wrote:

The attached patch fixes the issue.


The patch has been applied upstream:


https://github.com/gboeing/osmnx/commit/c1ca82daf3ac64a274ec50f7826ba42ccac00c8e

Kind Regards,

Bas

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

Bug#1025731: libghc-pcre-light-doc: depends on non-existing haddock-interface-35

[Ralf Treinen]

Package: libghc-pcre-light-doc
Version: 0.4.1.0-1
Severity: serious

libghc-pcre-light-doc cannot be installed since it depends on
haddock-interface-35 which does not exist in sid.

-Ralf.

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

[Fab Stz]

Hello,

Not sure this fits your issue and if this could work.

I used to produce android-builds that are sort of 'target' builds (and not 
host builds). There is a specific qmake to be called when building with a 
target-build. That qmake is in the bin directory of the target build. And that 
qmake uses the "target_qt.conf" file which should contain the path you expect.

However, for now, not all path are there and especially the Plugins dir isn't 
there. They will be once this is merged:

https://codereview.qt-project.org/c/qt/qtbase/+/436758/19/cmake/
QtQmakeHelpers.cmake

Maybe a solution could be to run qmake by specifying your own target_qt.conf 
that has the values you need ?

Regards
Fab


On Wed, 7 Dec 2022 08:04:54 +0100 Helmut Grohne  wrote:
> Package: qmake6
> Version: 6.3.1+dfsg-10
> Severity: important
> Control: affects -1 + src:fcitx-qt5
> User: debian-cr...@lists.debian.org
> Usertags: ftcbfs
> X-Debbugs-Cc: debian-cr...@lists.debian.org
> 
> Hi,
> 
> we've hit an interesting issue with qmake for QT6. This almost certainly
> is a pattern and I'll use fcitx-qt5 as an example.
> 
> fcitx-qt5 looks for a target Qt6::qmake and queries its LOCATION
> property to be able to run it. Then it runs that with -query
> QT_INSTALL_PLUGINS to locate the installation directory for plugins.
> Unfortunately, what it gets is the build architecture one rather than
> the host architecture one.
> 
> The crux of this is that /usr/bin/qmake6 cannot know about the host
> architecture. That information is a parameter of the build and nothing
> has passed this information along to it. It cannot just pull this
> information out of nothing. So we basically have two options:
> 
> a) Make sure that Qt6::qmake's LOCATION resolves to something that
>includes the information of the host architecture somehow.
> b) Declare that this method of querying qmake is unsupported and fix
>every package (including fcitx-qt5) in some other way.
> 
> For b), I have no clue what that other way would be. If someone knows,
> that would be great. I also have little clue how frequent this pattern
> is and how many packages we would have to fix. The expectation is "many"
> from my experience with QT5.
> 
> The implications of a) are quite well understood, because that's the
> route we opted for with QT5. It's a fairly involved route that took us
> more than a year to work properly, but maybe we can speed up by learning
> from earlier mistakes, so how does it work?
> 
> The qmake6 package gains new binaries /usr/bin/-qmake6. These
> actually are shell scripts that wrap qmake6 and inject the information
> about the host architecture into the command line. Then, we centrally
> divert Qt6::qmake to this location and everything will magically work.
> To get an idea how this works, install qt5-qmake and look at
> /usr/bin/$(dpkg -qDEB_BUILD_GNU_TYPE)-qmake. That should be fairly
> obvious. We're in a far better position than we started with QT5 as we
> already have the necessary qmake6 vs qmake6-bin split in place in
> exactly the way it needs to be. Also a number of client packages have
> been switched from AC_PATH_PROG to AC_PATH_TOOL for locating qmake
> already.
> 
> What we need now is a choice on which way we do it. The choice
> essentially is:
> 
> a) Add architecture-specific qmake wrappers for QT6.
> b) Declare that running qmake6 -query SOMEVAR is unsupported.
> 
> Patrick and Pino, what's your thoughts on this? If you feel like you
> cannot make such a choice, let us figure out what information is
> missing.

Bug#1022574: samba: Kerberos 22H2 Samba problem in Debian stable | Backports Version or Stable Update?

[Michael Tokarev]

07.12.2022 23:56, Tom Weber wrote:
..

Hitting the Problem with 22H2 i upgraded samba today to your provided packages 
on bullseye.


Tom, I strongly suggest you to upgrade to bullseye-backports (4.17), it
is in *significantly* better shape and is actually supported (upstream
and by me). 4.13 in bullseye lacks many bugfixes, is not supported
upstream and is only supported by me in a "lazy" manner.

Thanks!

/mjt

Bug#1022202: failed to validate module [usbserial] BTF: -22

[Brilliantov Kirill Vladimirovich]

Hello!
package linux-image-6.0.0-5-amd64 6.0.10-2
```
$ uname -r
6.0.0-5-amd64
```
At connect RS232-USB adapter dmesg contain follow lines
```
.
[  792.056242] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[  792.056249] usb 1-2: Product: TTL232R-3V3
[  792.056255] usb 1-2: Manufacturer: FTDI
[  792.056260] usb 1-2: SerialNumber: FTHEC1HL
[  792.085092] BPF:  type_id=75 bits_offset=128
[  792.085106] BPF:
[  792.085111] BPF: Invalid name
[  792.085116] BPF:
[  792.085122] failed to validate module [usbserial] BTF: -22
[ 1372.750421] rmi4_f12 rmi4-00.fn12: Failed to read object data. Code: -6.
...
```

Bug#1013731: linux-image-5.10.0-13-amd64: 5.10.0-13-amd64 RTL8153 power management kernel hang

[Ian Turner]

On 12/6/22 03:43, Renato Gallo wrote:

have you tried with 6.0 ?
Can you clarify to whom your question is addressed? If to me, I haven't 
done any further troubleshooting since opening this issue.

Bug#1020328: Acknowledgement (Native systemd units)

[Trent W. Buck]

On Wed 07 Dec 2022 23:46:43 +, Richard Lewis wrote:
> I have been studying and experimenting - and learning a lot.
> For exim4, i found ⋯

I slurped your exim notes into my repo.
I probably won't do any actual testing with exim myself :-)


https://github.com/cyberitsolutions/prisonpc-systemd-lockdown/commits/main/systemd/system/0-EXAMPLES/30-allow-mail-exim.conf

I was indeed originally plannign to push it into Debian as a kind of "apt 
install increased-hardening" package.
But I ran into enough nitpicking and static, my current approach is to instead 
try to work on individual packages, and
try to push upstreams to be more hardened by default.

e.g. SyscallFilters=@foo isn't backwards-compatible with old systemd, so
you can't use it if you don't know a minimum systemd version.

e.g. Architecture=native works fine until someone does something like "apt 
install curl:armhf".

e.g. the whole "if you call /usr/sbin/sendmail, everything becomes messy"

> - whether the unit is 'oneshot' - if so the unit needs to ensure exim has
> delivered the mail before the script exits - adding a small 'sleep' is
> enough - i think otherwise systemd gets confused about what process to
> monitor if the script causes exim to launch.

That doesn't sound right, but I suppose it's possible.
KillMode=process might trigger that.

> - whether or not the unit runs as root or a different user. With User=root
> you can get away with more hardening directives, but i think better to
> continue running as a non-root user

I think you'll find this is just because User=root implicitly disables a bunch 
of the settings.
If you set User=root, then "systemctl daemon-reload" then "systemd-analyze 
security foo.service",
you will see a bunch of stuff like:

Service runs as root, option does not matter
Service runs as root, option does not apply

PS: "systemd-analyze syscall-filter" is a good thing to look at when dealing 
with chown/seteuid.

Bug#592276: evolution freezes when importing large backup

[tomas k]

Package: evolution
Version: 3.38.3-1
Followup-For: Bug #592276
X-Debbugs-Cc: foren...@wi.rr.com

Dear Maintainer,


I upgraded evolution with a routine system upgrade, to upgrade with new 
packages. 
The upgraded version uses a different mail format. I expected the existing email
tree to be converted to the new format.

No such luck. The upgrade just blew the tree away. But I made a full backup 
before the upgrade
just in case. The backup is in the old format. When I try to import it, the 
machine freezes
with a message in the bottom bar that it is scanning a certain directory.

After 2 to 3 minutes, a dialog box pops up saying that evolution has stopped 
responding.
If I click "Wait", and go do something else for a while, when I come back, the 
dialog is
back in a few seconds, with the same message in the bottom bar, scanning 
directory
such and such. But it's the same directory in the message as before.

The laptop is one of the fastest Lenovo from 2016, so processor power 
shouldn't be an issue. The drive is a SSD, so it's fast too: 450MB/s

Diagnostics show no problem with memory (memtrester run 10 cycles), or 
anything else. I think hardware error is not an issue. If I leave 
it running overnight, it's the same the next night. 

Never had this problem before. So, I think it can be traced to
the new mail format and the conversion neccesary of the backup
file data. It appears to import the raw data in the backup, but it
fails somewhere  after that.

The backup is huge (100-150MB), and I haven't archived anything
ever (5-7years). And, the trash might have been quite loaded, as 
I have emptied it only once. I'd say there are at least 
20,000 messages in the backup. 

I don't know if that matters.  

I've tried purging evolution and reinstalling. Same problem.

I'm experienced with Debian, since woody. But I cannot solve
this problem. Thank you for all the help.


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

Kernel: Linux 5.18.0-0.bpo.1-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 evolution depends on:
ii  dbus   1.12.20-2
ii  evolution-common   3.38.3-1
ii  evolution-data-server  3.38.3-1
ii  libc6  2.31-13+deb11u4
ii  libcamel-1.2-623.38.3-1
ii  libclutter-gtk-1.0-0   1.8.4-4
ii  libecal-2.0-1  3.38.3-1
ii  libedataserver-1.2-25  3.38.3-1
ii  libevolution   3.38.3-1
ii  libglib2.0-0   2.66.8-1
ii  libgtk-3-0 3.24.24-4+deb11u2
ii  libical3   3.0.9-2
ii  libnotify4 0.7.9-3
ii  libsoup2.4-1   2.72.0-2
ii  libwebkit2gtk-4.0-37   2.36.7-1~deb11u1
ii  libxml22.9.10+dfsg-6.7+deb11u2
ii  psmisc 23.4-2

Versions of packages evolution recommends:
ii  evolution-plugin-bogofilter  3.38.3-1
ii  evolution-plugin-pstimport   3.38.3-1
ii  evolution-plugins3.38.3-1
ii  yelp 3.38.3-1

Versions of packages evolution suggests:
pn  evolution-ews   
pn  evolution-plugins-experimental  
ii  gnupg   2.2.27-2+deb11u2
ii  network-manager 1.30.6-1+deb11u1

-- no debconf information

Bug#1025730: initramfs-tools-core: configure_networking timeout causes entire init script to die

[Paul Aurich]

Package: initramfs-tools-core
Version: 0.142
Severity: normal

configure_networking tries to source /run/net-*.conf files at the end of its
run.  If the networking timed out, no files exist. If the shell is also dash,
the '.' operator failing to find any file to source causes the entire shell to
exit, regardless of 'set -e' or not.

Naturally, this causes problems since the calling init script is
unceremoniously killed off in the middle of execution. I'd prefer if the init
script continued running, so it has an opportunity to retry the networking or
take other actions.

(I've encountered a few circumstances where configure_networking times out
before the network and DHCP are functional after a power outage.)


Just a brief demonstration of the surprising-to-me(-and-of-course-documented)
behavior:

paul@haley ~ % cat repro.sh
#!/bin/sh

. /nonexistent
echo hello
paul@haley ~ % dash ./repro.sh
./repro.sh: 3: .: cannot open /nonexistent: No such file
paul@haley ~ % sh ./repro.sh
./repro.sh: 3: .: cannot open /nonexistent: No such file
paul@haley ~ % bash ./repro.sh
./repro.sh: line 3: /nonexistent: No such file or directory
hello
paul@haley ~ %


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

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

Versions of packages initramfs-tools-core depends on:
ii  coreutils9.1-1
ii  cpio 2.13+dfsg-7.1
ii  e2fsprogs1.46.6~rc1-1+b1
ii  klibc-utils  2.0.11-1
ii  kmod 30+20220905-1
ii  logsave  1.46.6~rc1-1+b1
ii  udev 252.2-2

Versions of packages initramfs-tools-core recommends:
ii  busybox  1:1.35.0-4
ii  zstd 1.5.2+dfsg-1

Versions of packages initramfs-tools-core suggests:
ii  bash-completion  1:2.11-6

-- no debconf information

Bug#1025729: evolution-data-server: Gmail OAuth2: "Access blocked: GNOME Evolution’s request is invalid"

[James Taylor]

Package: evolution-data-server
Version: 3.30.5-1+deb10u2
Severity: important

Dear Maintainer,

Google deprecated a type of OAuth flow in Feb 28, 2022. This was fixed and 
addressed upstream
shortly after at 
https://gitlab.gnome.org/GNOME/evolution-data-server/-/issues/388 and
the fix was included in version 3.44.2. However, Google has recently begun 
blocking
the old format. My Oauth2 token expired December 7th, 2022 so I can no longer 
access
my gmail account from evolution. A suitably recent version is available in 
Testing.

But the software is now partially unusable for the stable releases. I hope this 
is the
right channel for this. I wanted to note this upstream bug down here so you are 
aware
of the need to include the fixes in stable and oldstable.

Reproducing: Attempt to log in to a gmail account using OAuth2


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

Kernel: Linux 4.19.0-22-amd64 (SMP w/4 CPU cores)
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=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages evolution-data-server depends on:
ii  evolution-data-server-common  3.30.5-1+deb10u2
ii  gnome-keyring 3.28.2-5
ii  libc6 2.28-10+deb10u2
ii  libcamel-1.2-62   3.30.5-1+deb10u2
ii  libcanberra-gtk3-00.30-7
ii  libcanberra0  0.30-7
ii  libdb5.3  5.3.28+dfsg1-0.5
ii  libebackend-1.2-103.30.5-1+deb10u2
ii  libebook-1.2-19   3.30.5-1+deb10u2
ii  libebook-contacts-1.2-2   3.30.5-1+deb10u2
ii  libecal-1.2-193.30.5-1+deb10u2
ii  libedata-book-1.2-25  3.30.5-1+deb10u2
ii  libedata-cal-1.2-29   3.30.5-1+deb10u2
ii  libedataserver-1.2-23 3.30.5-1+deb10u2
ii  libedataserverui-1.2-23.30.5-1+deb10u2
ii  libgcr-base-3-1   3.28.1-1
ii  libgcr-ui-3-1 3.28.1-1
ii  libgdata220.17.9-3
ii  libglib2.0-0  2.58.3-2+deb10u4
ii  libgoa-1.0-0b 3.30.1-2
ii  libgtk-3-03.24.5-1
ii  libgweather-3-15  3.28.2-2
ii  libical3  3.0.4-3
ii  libldap-2.4-2 2.4.47+dfsg-3+deb10u7
ii  libpango-1.0-01.42.4-8~deb10u1
ii  libsecret-1-0 0.18.7-1
ii  libsoup2.4-1  2.64.2-2
ii  libxml2   2.9.4+dfsg1-7+deb10u5

evolution-data-server recommends no packages.

Versions of packages evolution-data-server suggests:
ii  evolution  3.30.5-1.1

-- no debconf information

Bug#917868: xfce4-pulseaudio-plugin: Notifications when volume changes causes plugin to temporarily freeze

[Diego Ongaro]

I ran into this same problem when my notifications daemon was not
loading correctly. That was due to #899377 because I had
plasma-workspace installed. It also caused similar stalls with
nm-applet.

Once I had notifications working (and I verified that with
notify-send), I was able to re-enable the "Show notifications when
volume changes" and it worked fine.

Hope this helps someone,
Diego

Bug#1019700: testing with 6.1 kernel

[Hank Barta]

On Wed, Dec 7, 2022 at 8:34 PM Hank Barta  wrote:

> I tested with the 6.1 kernel from testing.
>

The kernel was from experimental, not testing. Apologies for the error.

-- 
Beautiful Sunny Winfield

Bug#1019700: testing with 6.1 kernel

[Hank Barta]

I tested with the 6.1 kernel from testing.

hbarta@boson:~$ uname -a
Linux boson 6.1.0-0-arm64 #1 SMP Debian 6.1~rc7-1~exp1 (2022-12-01) aarch64
GNU/Linux
hbarta@boson:~$

The problem seems to be worse. It manifests with every cold boot (4 tries.)
I was only able to test one warm boot immediately following installation of
6.1 (and shutting down 6.0) and the issue manifested then also. I was
unable to further test warm boot because the system never completed
shutdown even after waiting 10 minutes. Inserting an SD card got the
following message (from dmesg)

[   46.858495] mmc1: new high speed SDIO card at address 0001

That message was followed by a single block from the timeout message
referencing mmc1 and which seemed not to be repeated. The /dev/ entry for
the SD card was never created.

Update: While composing this message it did complete a shutdown and reboot.
Unfortunately the SD card was (sort of) bootable and the system tried to
boot from it and hung, forcing a power cycle and cold boot. On this
subsequent cold boot the timeout did not manifest. A subsequent warm boot
also did not manifest. The third warm boot *did* manifest the timeout.

best,

-- 
Beautiful Sunny Winfield

Bug#1017780: Version bump: 1.4.230

[Chris Knadle]

Diederik de Haas:

Hi Chris,

On Wednesday, 7 December 2022 10:13:00 CET Chris Knadle wrote:

So I'd suggest skipping 1.4 altogether and go straight for 1.5.
You _could_ now release a development snapshot (to Experimental?),
especially if the package needs to go through NEW and then the update to
the 1.5 released version should be (relatively) small (I'd guess).


I want to release Mumble 1.5 when possible ... but this isn't about
releasing to Unstable vs Experimental --


The reason I mentioned Experimental is that you can use that to get things
through NEW if needed, while not blocking potential updates for Unstable/
Testing/Bookworm. Mostly because one doesn't know how long that'll take.


I'm aware of Experimental, I believe I've uploaded to Experimental before. It's 
a worthwhile thought for aa release that may not be fitting (yet) for Unstable, 
which the current Mumble 1.5 would theoretically fit that because it's not 
released yet. Keep in mind -- any release to Experimental cannot be uploaded to 
Unstable with the same version #. i.e. anything in Experimental is strictly a 
work-in-progress. I believe once a package is released to Unstable with a higher 
version # than that of Experimental, the Experimental version is removed.



it's about the fact that there
isn't a 1.5 source tarball to work from to do any release at all.


With snapshot I did mean using 'some' upstream git commit, like current HEAD.
I'll try to find an example of that as I *know* they exist.


Yes, I know. Many upstream packages that are in Git can be exported directly to 
a tarball and then built as a Debian package. Mumble is NOT one of those. 
Mumble's Git repo has submodules that are considered separate such that "git 
archive" won't export the submodules, and the code won't build without them. 
Also the submodules contain files that have restrictive copyright, making them 
unreleasable. So the process of /building/ a releasable tarball from several 
"git archive" operations, extraction, file deletion, re-tarring is messy with 
Mumble when trying to export it from Git.


  -- Chris

--
Chris Knadle
chris.kna...@coredump.us

Bug#1025720: emacs: systemd user unit runs automatically, even when disabled

[Rob Browning]

Ross Vandegrift  writes:

> Should the systemd user unit be started by default?  The changelog indicates 
> no
> (see 1:28.1+1-4) and dh_installsystemduser is invoked with
> --no-enable.

That's correct, i.e. it shouldn't.

> But it starts on my system without (as far as I recall) me enabling
> it.
>
>
> What's the appropriate way to disable it?  `systemctl --user disable --now
> emacs.server` only lasts until I reboot.  Masking it works.
>
> I've noticed that even after disabling, status shows it's enabled:
>   $ systemctl --user disable --now emacs.service
>   $ systemctl --user status emacs.service | head -n 3
>   ○ emacs.service - Emacs text editor
>Loaded: loaded (/usr/lib/systemd/user/emacs.service; enabled; preset: 
> enabled)
>Active: inactive (dead) since Wed 2022-12-07 15:03:03 PST; 4s ago
>
> I don't really understand how systemd user stuff works - 
> ~/.config/systemd/user
> is empty (until masking), but I don't know if that's informative.

I suspect you're having the same problem I was, which I believe is
caused by the fact that earlier versions of the package (in untable)
didn't have --no-enable, and the auto-run behavior seems to be sticky.

I "fixed" it here by purging and reinstalling emacs-common, but I'd hope
there's a better way.  If so, I'd be happy to consider adding some notes
to a suitable /usr/share/doc file, and/or trying to automate a fix.

Though if the fix isn't simple, I might hesitate attempting to automate
it, since the problem (I hope) only existed somewhat briefly in
unstable.

Thanks for  the report, and sorry for the trouble.
-- 
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

Bug#1025432: LXD - suggestion to moving dnsmasq to recommended dependencie

[Mathias Gibbens]

  Thanks for filing the bug!

  I'm planning to take a look at this over the weekend.

Mathias


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

Bug#1025728: rpki-trust-anchors: [INTL:pt_BR] Brazilian Portuguese debconf templates translation

[Paulo Henrique de Lima Santana]

Package: rpki-trust-anchors
Tags: l10n patch
Severity: wishlist

Hello,

Could you please update this Brazilian Portuguese translation?

Attached you will find the file pt_BR.po. It is UTF-8 encoded and
tested with msgfmt and podebconf-display-po.

Kind regards.


--
Paulo Henrique de Lima Santana (phls)
Belo Horizonte - Brasil
Debian Developer
Site: http://phls.com.br
GPG ID: 0443C450


pt_BR.po.gz
Description: application/gzip


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1025727: mysqmail: [INTL:pt_BR] Brazilian Portuguese debconf templates translation

[Paulo Henrique de Lima Santana]

Package: mysqmail
Tags: l10n patch
Severity: wishlist

Hello,

Could you please update this Brazilian Portuguese translation?

Attached you will find the file pt_BR.po. It is UTF-8 encoded and
tested with msgfmt and podebconf-display-po.

Kind regards.

--
Paulo Henrique de Lima Santana (phls)
Belo Horizonte - Brasil
Debian Developer
Site: http://phls.com.br
GPG ID: 0443C450


pt_BR.po.gz
Description: application/gzip


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1025726: libguestfs: [INTL:pt_BR] Brazilian Portuguese debconf templates translation

[Paulo Henrique de Lima Santana]

Package: libguestfs
Tags: l10n patch
Severity: wishlist

Hello,

Could you please update this Brazilian Portuguese translation?

Attached you will find the file pt_BR.po. It is UTF-8 encoded and
tested with msgfmt and podebconf-display-po.

Kind regards.

--
Paulo Henrique de Lima Santana (phls)
Belo Horizonte - Brasil
Debian Developer
Site: http://phls.com.br
GPG ID: 0443C450


pt_BR.po.gz
Description: application/gzip


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1025725: colplot: [INTL:pt_BR] Brazilian Portuguese debconf templates translation

[Paulo Henrique de Lima Santana]

Package: colplot
Tags: l10n patch
Severity: wishlist

Hello,

Could you please update this Brazilian Portuguese translation?

Attached you will find the file pt_BR.po. It is UTF-8 encoded and
tested with msgfmt and podebconf-display-po.

Kind regards.


--
Paulo Henrique de Lima Santana (phls)
Belo Horizonte - Brasil
Debian Developer
Site: http://phls.com.br
GPG ID: 0443C450


pt_BR.po.gz
Description: application/gzip


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1025618: cloud-init and firewalld systemd unit files have ordering cycles

[Ross Vandegrift]

Control: forwarded -1 
https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1956629

Hi Guillaume,

On Tue, Dec 06, 2022 at 06:26:26PM +0100, Guillaume Knispel wrote:
> firewalld and cloud-init have ordering cycles between their systemd unit
> files, leading to more or less broken boot results when both are installed
> and active, because at each boot systemd decides to skip a
> non-deterministically choosen service (not necessarily cloud-init or
> firewalld) to break the cycle.

Thanks for bringing this to our attention.  There's a few useful
discussions:

https://github.com/firewalld/firewalld/issues/414
https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1956629

>From my quick read: Michael Biebl proposes dropping network-pre.target
from cloud-init's After=, and replacing it with each of the config
backends that cloud-init supports.  This sounds pretty reasonable, but
also like something that upstream should address first.

Should we consider adding "Conflicts: firewalld" to cloud-init before
the freeze?  That's not optimal of course, but it'd prevent a user from
ending up in this situation for now.

Thanks,
Ross

Bug#1025724: b43-fwcutter: [INTL:pt_BR] Brazilian Portuguese debconf templates translation

[Paulo Henrique de Lima Santana]

Package: b43-fwcutter
Tags: l10n patch
Severity: wishlist

Hello,

Could you please update this Brazilian Portuguese translation?

Attached you will find the file pt_BR.po. It is UTF-8 encoded and
tested with msgfmt and podebconf-display-po.

Kind regards.

--
Paulo Henrique de Lima Santana (phls)
Belo Horizonte - Brasil
Debian Developer
Site: http://phls.com.br
GPG ID: 0443C450


pt_BR.po.gz
Description: application/gzip


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1025723: qpsmtpd: [INTL:pt_BR] Brazilian Portuguese debconf templates translation

[Paulo Henrique de Lima Santana]

Package: qpsmtpd
Tags: l10n patch
Severity: wishlist

Hello,

Could you please update this Brazilian Portuguese translation?

Attached you will find the file pt_BR.po. It is UTF-8 encoded and
tested with msgfmt and podebconf-display-po.

Kind regards.


--
Paulo Henrique de Lima Santana (phls)
Belo Horizonte - Brasil
Debian Developer
Site: http://phls.com.br
GPG ID: 0443C450


pt_BR.po.gz
Description: application/gzip


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1025706: example patch

[Scott Moser]

Attached is a debdiff against 1.0.3-3 that is "working for me" so far.
diff --git a/debian/changelog b/debian/changelog
index b641b61..33801af 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+squashfuse (0.1.105-1) unstable; urgency=medium
+
+  * New upstream release.
+  * Link against libfuse3 rather than libfuse2 (Closes: #1025706).
+  * debian/patches/* - drop patches.
+
+ -- Scott Moser   Wed, 07 Dec 2022 16:33:06 -0500
+
 squashfuse (0.1.103-3) unstable; urgency=medium
 
   * Fix "Switch from deprecated  to "
diff --git a/debian/control b/debian/control
index 1b0f6f7..ea84c4f 100644
--- a/debian/control
+++ b/debian/control
@@ -3,7 +3,7 @@ Section: utils
 Priority: optional
 Maintainer: Scarlett Moore 
 Build-Depends: debhelper-compat (= 13),
-   libfuse-dev,
+   libfuse3-dev,
liblz4-dev,
liblzma-dev,
liblzo2-dev,
diff --git a/debian/libfuseprivate0.install b/debian/libfuseprivate0.install
deleted file mode 100644
index d6268cc..000
--- a/debian/libfuseprivate0.install
+++ /dev/null
@@ -1 +0,0 @@
-usr/lib/*/libfuseprivate.so.*
diff --git a/debian/libsquashfuse-dev.install b/debian/libsquashfuse-dev.install
index b2eb5cd..f21b6a1 100644
--- a/debian/libsquashfuse-dev.install
+++ b/debian/libsquashfuse-dev.install
@@ -2,3 +2,4 @@ usr/include/
 usr/lib/*/*.a
 usr/lib/*/*.so
 usr/lib/*/pkgconfig/squashfuse.pc
+usr/lib/*/pkgconfig/squashfuse_ll.pc
diff --git a/debian/libsquashfuse0.install b/debian/libsquashfuse0.install
index 3ef587c..7f296f1 100644
--- a/debian/libsquashfuse0.install
+++ b/debian/libsquashfuse0.install
@@ -1,3 +1,2 @@
-usr/lib/*/libfuseprivate.so.*
 usr/lib/*/libsquashfuse.so.*
 usr/lib/*/libsquashfuse_ll.so.*
diff --git a/debian/libsquashfuse0.symbols b/debian/libsquashfuse0.symbols
index c755067..b3b0383 100644
--- a/debian/libsquashfuse0.symbols
+++ b/debian/libsquashfuse0.symbols
@@ -1,11 +1,3 @@
-libfuseprivate.so.0 libsquashfuse0 #MINVER#
-* Build-Depends-Package: libsquashfuse-dev
- sqfs_enoattr@Base 0.0.0
- sqfs_listxattr@Base 0.0.0
- sqfs_makedev@Base 0.0.0
- sqfs_opt_proc@Base 0.0.0
- sqfs_stat@Base 0.0.0
- sqfs_usage@Base 0.0.0
 libsquashfuse.so.0 libsquashfuse0 #MINVER#
 * Build-Depends-Package: libsquashfuse-dev
  sqfs_block_cache_init@Base 0.0.0
@@ -79,12 +71,6 @@ libsquashfuse.so.0 libsquashfuse0 #MINVER#
  sqfs_stack_size@Base 0.0.0
  sqfs_stack_top@Base 0.0.0
  sqfs_swap16@Base 0.0.0
- sqfs_swapin16@Base 0.0.0
- sqfs_swapin16_internal@Base 0.0.0
- sqfs_swapin32@Base 0.0.0
- sqfs_swapin32_internal@Base 0.0.0
- sqfs_swapin64@Base 0.0.0
- sqfs_swapin64_internal@Base 0.0.0
  sqfs_swapin_base_inode@Base 0.0.0
  sqfs_swapin_dev_inode@Base 0.0.0
  sqfs_swapin_dir_entry@Base 0.0.0
@@ -127,10 +113,148 @@ libsquashfuse.so.0 libsquashfuse0 #MINVER#
  sqfs_xattr_value_size@Base 0.0.0
 libsquashfuse_ll.so.0 libsquashfuse0 #MINVER#
 * Build-Depends-Package: libsquashfuse-dev
- fusefs_main@Base 0.1.103
+ alarm_tick@Base 0.0.0
+ setup_idle_timeout@Base 0.0.0
+ sqfs_block_cache_init@Base 0.0.0
+ sqfs_block_dispose@Base 0.0.0
+ sqfs_block_read@Base 0.0.0
+ sqfs_blockidx_add@Base 0.0.0
+ sqfs_blockidx_blocklist@Base 0.0.0
+ sqfs_blockidx_init@Base 0.0.0
+ sqfs_blocklist_count@Base 0.0.0
+ sqfs_blocklist_init@Base 0.0.0
+ sqfs_blocklist_next@Base 0.0.0
+ sqfs_cache_add@Base 0.0.0
+ sqfs_cache_destroy@Base 0.0.0
+ sqfs_cache_get@Base 0.0.0
+ sqfs_cache_init@Base 0.0.0
+ sqfs_cache_invalidate@Base 0.0.0
+ sqfs_compression@Base 0.0.0
+ sqfs_compression_name@Base 0.0.0
+ sqfs_compression_supported@Base 0.0.0
+ sqfs_data_block_read@Base 0.0.0
+ sqfs_data_cache@Base 0.0.0
+ sqfs_data_header@Base 0.0.0
+ sqfs_decompressor_get@Base 0.0.0
+ sqfs_dentry_init@Base 0.0.0
+ sqfs_dentry_inode@Base 0.0.0
+ sqfs_dentry_inode_num@Base 0.0.0
+ sqfs_dentry_is_dir@Base 0.0.0
+ sqfs_dentry_mode@Base 0.0.0
+ sqfs_dentry_name@Base 0.0.0
+ sqfs_dentry_name_size@Base 0.0.0
+ sqfs_dentry_next_offset@Base 0.0.0
+ sqfs_dentry_offset@Base 0.0.0
+ sqfs_dentry_type@Base 0.0.0
+ sqfs_destroy@Base 0.0.0
+ sqfs_dir_lookup@Base 0.0.0
+ sqfs_dir_next@Base 0.0.0
+ sqfs_dir_open@Base 0.0.0
+ sqfs_divceil@Base 0.0.0
+ sqfs_enoattr@Base 0.0.0
+ sqfs_export_inode@Base 0.0.0
+ sqfs_export_ok@Base 0.0.0
+ sqfs_fd_close@Base 0.0.0
+ sqfs_fd_open@Base 0.0.0
+ sqfs_frag_block@Base 0.0.0
+ sqfs_frag_entry@Base 0.0.0
+ sqfs_hash_add@Base 0.0.0
+ sqfs_hash_destroy@Base 0.0.0
+ sqfs_hash_get@Base 0.0.0
+ sqfs_hash_init@Base 0.0.0
+ sqfs_hash_remove@Base 0.0.0
+ sqfs_id_get@Base 0.0.0
+ sqfs_init@Base 0.0.0
+ sqfs_inode_get@Base 0.0.0
+ sqfs_inode_root@Base 0.0.0
+ sqfs_listxattr@Base 0.0.0
+ sqfs_ll_add_direntry@Base 0.0.0
  sqfs_ll_daemonize@Base 0.1.103
  sqfs_ll_destroy@Base 0.1.103
  sqfs_ll_iget@Base 0.1.103
  sqfs_ll_init@Base 0.1.103
  sqfs_ll_inode@Base 0.1.103
+ sqfs_ll_mount@Base 0.0.0
+ sqfs_ll_op_create@Base 0.0.0
+ sqfs_ll_op_forget@Base 0.0.0
+ sqfs_ll_op_getattr@Base 0.0.0
+ sqfs_ll_op_getxattr@Base 0.0.0
+ 

Bug#1025433: [Emc-developers] Bug#1025433: Copyright issue

[Adam Ant]

 

 
 

Sent: Monday, December 05, 2022 at 2:32 PM
From: "andy pugh" 
To: "Adam Ant" , 1025...@bugs.debian.org, "EMC developers" 
Cc: sub...@bugs.debian.org
Subject: Re: [Emc-developers] Bug#1025433: Copyright issue



 
 


On Mon, 5 Dec 2022 at 14:14, Adam Ant  wrote:

Source: linuxcnc

src/rtapi/procfs_macros.h incorrectly attributes copyright.

The original file can be found here:
http://svn.savannah.gnu.org/viewvc/rtai/magma/base/include/rtai_proc_fs.h?view=markup

 

At what point does a file become a new file? The file in LinuxCNC appears to be a sub-set of an original file contributed to RTAI by Erwin Roll.

 

The correct course of action is to ask Paolo Mantegazza rather than debating symantics.

You can not just pull substantial chunks of code from one source and then claim that you wrote it.

Bug#1024686: gkrellm: Crashes since reboot

[Bernhard Übelacker]

Hello Nicolas,
the given backtrace points to below source locations.

Does starting gkrellm from a terminal maybe give some more output?



 Module /home/nicolas/.gkrellm2/plugins/gkrellflynn.so without build-id.
 Module /home/nicolas/.gkrellm2/plugins/gkrellflynn.so


Maybe you could also temporarily disable or move this
gkrellm plugin to some safe directory.
It might be built against a different gkrellm/glib version?


Kind regards,
Bernhard


0xb77cba94 in g_source_callback_ref at ../../../glib/gmain.c:1718
0xb77d03c0 in g_main_dispatch at ../../../glib/gmain.c:3420
0xb77d0819 in g_main_context_iterate at ../../../glib/gmain.c:4238
0xb77d0b31 in g_main_loop_run at ../../../glib/gmain.c:4438
0xb7b24af5 in IA__gtk_main at ../../../../gtk/gtkmain.c:1270
0x0042f027 in main at main.c:2344

   0xb77cba94 :lock addl $0x1,(%eax)

https://sources.debian.org/src/glib2.0/2.74.1-2/glib/gmain.c/#L1718

1713 static void
1714 g_source_callback_ref (gpointer cb_data)
1715 {
1716   GSourceCallback *callback = cb_data;
1717
1718   g_atomic_int_inc (>ref_count);
1719 }

Bug#1020328: Acknowledgement (Native systemd units)

[Richard Lewis]

On Wed, 9 Nov 2022, 08:37 Trent W. Buck,  wrote:

> My old (Debian 9) notes about different techniques are here:
>
> https://github.com/cyberitsolutions/prisonpc-systemd-lockdown/tree/main/systemd/system/0-EXAMPLES
>
>

This is an amazing resource! (did you consider trying to introduce it into
a debian package somehow?)

I have been studying and experimenting - and learning a lot.

For exim4, i found that it depends on
- whether the unit is 'oneshot' - if so the unit needs to ensure exim has
delivered the mail before the script exits - adding a small 'sleep' is
enough - i think otherwise systemd gets confused about what process to
monitor if the script causes exim to launch.
- whether or not the unit runs as root or a different user. With User=root
you can get away with more hardening directives, but i think better to
continue running as a non-root user

This all makes me want to abandon exim for postfix but exim is still
debian's default.

I think this is consistent with what you found for other mtas, but for
future reference and to help people searching for how to use exim in a
systemd unit, ive been using the following with exim:


ExecStart=/usr/sbin/logcheck
ExecStart=sleep 0.1s

User=logcheck
UMask=0066

ProtectSystem=strict
ReadWritePaths=/var/lib/logcheck

# for exim - probably debian should allow all of /var/spool and /var/log
here
ReadWritePaths=-/var/spool/exim4 -/var/mail -/var/log/exim4

# ProtectHome=true is possible, but the message will be
# frozen as exim wants to cd to $HOME (for .forward)
ProtectHome=read-only
PrivateTmp=true
PrivateMounts=true


DevicePolicy=strict

# *cannot set: PrivateDevices=true
DeviceAllow=/dev/stdout w
DeviceAllow=/dev/stdin r
DeviceAllow=/dev/stderr w
DeviceAllow=/dev/null rw
ProtectProc=invisible
ProcSubset=pid
RemoveIPC=true
ProtectControlGroups=true
AmbientCapabilities=

# exim needs to change ownership of mail - both when it
# receives the mail and when it delivers it to the local user
# see capabilities(7)
CapabilityBoundingSet=CAP_SETGID
CapabilityBoundingSet=CAP_SETUID
CapabilityBoundingSet=CAP_FSETID
CapabilityBoundingSet=CAP_CHOWN
CapabilityBoundingSet=CAP_DAC_OVERRIDE
CapabilityBoundingSet=CAP_FOWNER

# Anything that implies NoNewPrivileges cannot be set
# cannot set: NoNewPrivileges=yes
# cannot set: DynamicUser=yes
# cannot set: PrivateUsers=true
# *cannot set: RestrictNamespaces=true
# *cannot set: LockPersonality=true
# *cannot set: ProtectKernelModules=true
# *cannot set: ProtectKernelLogs=true
# *cannot set: ProtectHostname=true
# *cannot set: ProtectClock=true
# *cannot set: RestrictRealtime=true
# *cannot set: MemoryDenyWriteExecute=true
# *cannot set - and would break remote delivery:
RestrictAddressFamilies=AF_INET AF_INET6
# *cannot set: RestrictSUIDSGID=true
# *cannot set:  SystemCallArchitectures=native
# *cannot set: SystemCallFilter=@system-service
# cannot set (due to chown): SystemCallFilter=~@privileged
# directives with a * can be set if we use User=root instead of
User=logcheck
-

This still needs the tmpfiles.d dropin from your earlier email. However, i
wonder if it is better to make logcheck use a single dir for both the
lockfile (currently /run/lock/logcheck) and the scratch dir ( currently
created in /tmp each time) and then we could use a single
RuntimeDirectory=logcheck with RuntimeDirectoryPreserve=yes (to ensure it
is not deleted and no clashes if logcheck dies it would retain the current
code in logcheck to use a random subdir and delete it on success)

Bug#1025722: duck fails with 'Can't close(GLOB(0x558bebc05958)) filehandle: 'Is a directory' at /usr/share/duck/lib/checks/patch_files.pm line 101'

[gregor herrmann]

Package: duck
Version: 0.14.0
Severity: grave
Justification: renders package unusable
X-Debbugs-Cc: p...@packages.debian.org

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

As of today, duck (called in any source package directory) fails with

Can't close(GLOB(0x558bebc05958)) filehandle: 'Is a directory' at 
/usr/share/duck/lib/checks/patch_files.pm line 101'

92  # iterate over all patchdirs, process all files found
93  foreach my $patchdir (@patchdirs) {
94  my $dirhandle = dir($patchdir)->open;
95  
96  while (my $patchfile = $dirhandle->read) {
97  open my $pf, "<", $patchdir . "/" . $patchfile;
98  
99  my @pf_raw = <$pf>;
   100  
   101  close($pf);

This may or may not be caused by a recent change in src:perl [0], hence
cc'in the perl maintainers


Cheers,
gregor

[0]

perl (5.36.0-5) unstable; urgency=medium

  * Backported upstream changes:
+ only clear the stream error state in readline() for glob()
  (Closes: #1016369)
…

 -- Niko Tyni   Tue, 06 Dec 2022 11:43:06 +0200


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

Kernel: Linux 6.0.0-4-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=C, LC_CTYPE=de_AT.utf8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages duck depends on:
ii  devscripts   2.22.2
ii  dpkg-dev 1.21.12
ii  libconfig-inifiles-perl  3.03-1
ii  libconfig-simple-perl4.59-6.1
ii  libdomain-publicsuffix-perl  0.19-2
ii  libfile-which-perl   1.27-2
ii  libmailtools-perl2.21-2
ii  libnet-dns-perl  1.35-1
ii  libparallel-forkmanager-perl 2.02-1
ii  libparse-debcontrol-perl 2.005-6
ii  libpath-class-perl   0.37-4
ii  libregexp-common-email-address-perl  1.01-6
ii  libregexp-common-perl2017060201-3
ii  libstring-similarity-perl1.04-3+b1
ii  libwww-curl-perl 4.17-8+b1
ii  libxml-xpath-perl1.48-1
ii  libyaml-libyaml-perl 0.84+ds-1+b1
ii  lynx 2.9.0dev.10-1+b1
ii  perl 5.36.0-5
ii  publicsuffix 20220811.1734-1

duck recommends no packages.

Versions of packages duck suggests:
ii  brz [bzr]   3.3.1-1
ii  git 1:2.38.1-1
ii  mercurial   6.3.1-2
ii  subversion  1.14.2-4+b1

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEE0eExbpOnYKgQTYX6uzpoAYZJqgYFAmORJZlfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEQx
RTEzMTZFOTNBNzYwQTgxMDREODVGQUJCM0E2ODAxODY0OUFBMDYACgkQuzpoAYZJ
qgaZtw//QqED5auXM1gfiGMwnS/OjU6jPnHjZ6kKu8QM12jH35Pgv8+TMvOePliR
6cLLHA4+GooqUBLrBLIJSw49YzSuxV2SxesjD9RsKHRsLkeqOaAU4kAS1CnW1POp
qNZP7/qNjmOl0B7xeQEljehseILWgFmGEe3selRI0maHHwSLnMr0YmPN36kg3s0X
/8qPh0xOUrbrooeAH76rcOqapnA2RKoGq7SvuY4cmLvIz/SwHq18CADaMNFvW1u3
RRq8orKf7DXWkAoBIRfFg1HYBppYGWA4yn3k5GwRxS9/YYdDTOoYrDFbGQTFhnpZ
T+KSx1DaTPum6A3MkXgdSB+OFUlxzbvrt7y+ULz6+ZHe3kaqjPHMe6i1cjPnhD+s
nLZ7n5f67f0oZq7zHRTANIASCEWs+Xp2fuwGzs910A80LUUwe9vvNkEx6WEf7QdS
yAbChHZhkIfFI1B5Bh/dYdxklfmkj5KrfFCKaLChLKbEr3EgC3LdwI5sNvOuWu+7
EgyzntYCPg1BvmFE1cZYzcCmAfvF9OOEd7Om16j1Z1e/ydHycWJcm0OrROcZDroK
e2ZIcxE9B4lpSCVVyE0PeDjgqlEFLalI5EyJhktFz14kWOj6wdJ1ekufWRtw+N8R
sw87whJFSxgKZ4m4NtWWTVwpTCIxl36GyasLKv7/sNqZUSh2+1Q=
=P4E5
-END PGP SIGNATURE-

Bug#1025701: ovmf: does not recognise virtio-scsi controller

[Vincent Danjean]

  Hi,

Le 07/12/2022 à 22:26, dann frazier a écrit :

On Wed, Dec 7, 2022 at 10:36 AM Vincent Danjean  wrote:

   ovmf in sid does not allow one to boot over a virtio-scsi contrôleur.
My disques are not seen anymore (not even in the EFI menus).
Downgrading to 2020.11-2+deb11u1 fixes the issue.


Thanks for opening this new issue! As I mentioned in #1016359, I had
no problems booting a VM w/ virtio-scsi in sid, so this seems like it
may be config-specific. Can you provide me with a way to reproduce
this - e.g. your libvirt XML?


Here is.

  Regards,
Vincent



  visio
  d76aaa5d-3ffd-45c7-9803-3c1edcf57dc4
  
http://libosinfo.org/xmlns/libvirt/domain/1.0;>
  http://debian.org/debian/10"/>

  
  4194304
  4194304
  2
  
hvm
/usr/share/OVMF/OVMF_CODE.fd
/var/lib/libvirt/qemu/nvram/visio_VARS.fd

  
  



  
  
  



  
  destroy
  restart
  destroy
  


  
  
/usr/bin/qemu-system-x86_64

  
  
  
  


  
  
  
  
  


  


  



  
  
  


  
  
  


  
  


  
  
  


  
  
  


  
  
  


  
  
  


  
  
  


  
  
  


  


  


  
  
  


  
  
  
  


  

  


  


  
  


  
  


  




  
  


  



  
  


  


  


  


  


  


  /dev/urandom
  

  

Bug#1025721: RFS: dh-runit/2.15.1 -- debhelper add-on to handle runit runscripts

[Lorenzo Puliti]

Package: sponsorship-requests
Severity: normal
X-Debbugs-Cc: plore...@disroot.org

Dear mentors,

I am looking for a sponsor for my package "dh-runit":

 * Package name : dh-runit
   Version  : 2.15.1
   Upstream contact : Lorenzo Puliti 
 * URL  : https://salsa.debian.org/debian/dh-runit
 * License  : GPL-3+
 * Vcs  : https://salsa.debian.org/debian/dh-runit
   Section  : admin

The source builds the following binary packages:

  dh-runit - debhelper add-on to handle runit runscripts
  runit-helper - dh-runit implementation detail

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

  https://mentors.debian.net/package/dh-runit/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/d/dh-runit/dh-runit_2.15.1.dsc

Git repo:

  https://salsa.debian.org/debian/dh-runit/-/tree/next

Changes since the last upload:

 dh-runit (2.15.1) experimental; urgency=medium
 .
   * Remove duplicate metafiles
   * update tests for metafiles

Regards,
-- 
  Lorenzo Puliti

Bug#1025719: logcheck: please enable checking of the system journal by default

[Richard Lewis]

Package: logcheck
Version: 1.3.24
Tags: patch
X-Debbugs-Cc: richard.lewis.deb...@googlemail.com

logcheck should check the systemd journal by default.

Support is available, but not currently enabled by default.
To enable support you should (as root):
a) touch /var/lib/logcheck/offset.journal
b) chown logcheck /var/lib/logcheck/offset.journal
c) echo journal > /etc/logcheck/logcheck.logfiles.d/journal.logfiles
d) run logcheck as normal

(a) and (b) are needed to work round a bug in logcheck: the first time
logcheck checks the journal it attempts to check every single line ever
written to the journal, which is likely to be result in logcheck being
killed by the OOM-killer. Creating the files in /var/lib means only new
lines are checked. The attached patch fixes this by making logcheck only
check the most recent 5 hours if the offset file is not present.

In addition to this patch, logcheck should
- move 'rsyslog | system-log-daemon' from 'depends' to 'suggests'
- ship a file /etc/logcheck/logcheck.logfiles.d/journal.logfiles
   containing the word 'journal'
- there is no need to remove the existing /etc/logcheck/logcheck.logfiles
   but the comments could be updated - the 'default' is no longer to use
 the syslog at all
- add an entry in NEWS.Debian
(if no-one else does, i'll send as a MR once the other MRs are merged/closed)


What about non-systemd systems?
---
This setting should not affect non-systemd systems (untested).

inside logcheck, logoutput() already knows to do nothing if journalctl is not in
the $PATH but i dont know what happens if a system has journalctl installed but
the journal is not running: journalctl may still work or the user may get an 
error
on every invocation of logcheck.

We could easily patch logcheck to deal with this if it is an issue (I dont know
how to check whether the journal is not being used, but there are other options
including not reporting errors or not attempting to check the journal if systemd
is not running)

Of course, such systems are increasingly non-standard and a user who has opted 
out
of systemd or its journal will presumably be easily capable of editing
/etc/logcheck/logcheck.logfiles.d/journal.logfiles to turn off journal checking 
if
they want.


Why systemd should be considered the default


For bookworm, my understanding is:
- the default is for logging to primarily happen via the systemd journal
writing log entries into /var/log/journal
- the journal will duplicate these messages into /var/log/syslog only
   if a) system-log-daemon (provided by rsyslog and other packages) is installed
 and b) the user does not disable this feature by setting 
ForwardToSyslog=no
 in /etc/systemd/journald.conf
- (I _think_ i saw the systemd maintainers suggest on debian-devel that either 
they
   or upstream will turn off the forwarding at some point, but this has not yet 
been done.) 
- rsyslog is demoted to priority:optional (stated by the maintainer here
   https://bugs.debian.org/cgi-bin/bugreport.cgi?att=0;bug=1023596;msg=15
   - I was not able to find this in rsyslog's changelog, but it seems to be the
   case in unstable today (7 Dec 2022)
- no other package providing system-log-daemon has been increased to priority
 higher than optional (checked in unstable using aptitude)

therefore, new bookworm installations will only have logging via the journal
unless the user requested a syslog - (tens of package depend on rsyslog).


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

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

Versions of packages logcheck depends on:
ii  adduser3.118
ii  exim4-daemon-light [mail-transport-agent]  4.94.2-7
ii  lockfile-progs 0.1.18
ii  logtail1.3.24+local6
ii  mime-construct 1.11+nmu3

Versions of packages logcheck recommends:
ii  logcheck-database  1.3.24+local6
diff --git a/src/logcheck b/src/logcheck
index e887fb09..cb623671 100755
--- a/src/logcheck
+++ b/src/logcheck
@@ -455,6 +455,12 @@ logoutput() {
offsettime=""
if [ -f "$offsetfile" ]; then

offsettime="--since=@$(stat -c %Y "$offsetfile")"
+   else
+   echo "This is 
the first time logcheck has checked output in the systemd journal." \
+  

Bug#1025720: emacs: systemd user unit runs automatically, even when disabled

[Ross Vandegrift]

Package: emacs
Version: 1:28.2+1-8
Severity: normal
X-Debbugs-Cc: rvandegr...@debian.org

Hello,

Should the systemd user unit be started by default?  The changelog indicates no
(see 1:28.1+1-4) and dh_installsystemduser is invoked with --no-enable.  But it
starts on my system without (as far as I recall) me enabling it.


What's the appropriate way to disable it?  `systemctl --user disable --now
emacs.server` only lasts until I reboot.  Masking it works.

I've noticed that even after disabling, status shows it's enabled:
  $ systemctl --user disable --now emacs.service
  $ systemctl --user status emacs.service | head -n 3
  ○ emacs.service - Emacs text editor
   Loaded: loaded (/usr/lib/systemd/user/emacs.service; enabled; preset: 
enabled)
   Active: inactive (dead) since Wed 2022-12-07 15:03:03 PST; 4s ago

I don't really understand how systemd user stuff works - ~/.config/systemd/user
is empty (until masking), but I don't know if that's informative.

Thanks,
Ross

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

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

Versions of packages emacs depends on:
ii  emacs-lucid  1:28.2+1-8

emacs recommends no packages.

emacs suggests no packages.

-- no debconf information

Bug#710523: i18nspector: Please i18n man page

[Jakub Wilk]

* Helge Kreutzmann , 2022-11-06 09:25:
Please add a framework for providing localized man pages, possibly 
using po4a or similar tools.


I don't plan to add such a framework upstream, at least for the time 
being. Of course, the Debian maintainer is free to implement it on his 
own if he wishes so. :)


Is this still the case (see also below)?


I'd expect that i18nspector users know English, so this doesn't sound to 
me like a good investment.


Moreover, I no longer have any use for i18nspector, so my motivation to 
hack on it has dropped to near-zero. I don't plan to add any new 
features.  Sorry!


--
Jakub Wilk

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

[dann frazier]

tag 1025656 + confirmed
thanks

Thank you for the bug report. Something does seem to be wrong with the
qemu-efi-aarch64. I'll see if I can find the cause through bisection.

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

[Hank Barta]

Hi Diederik,

This may not be the same bug. The one you referenced was provoked when the
SD card slot was empty and could be suppressed by putting a card in the
slot. Also that bug was fixed and the work around was no longer necessary.
The one I experienced could happen with the SD card in place and at various
times, the SD card would be recognized or would not be recognized (when a
card was in place and the timeout was reported.) Let me clarify the
situations I encountered while testing. Again, I performed testing while
booting from a USB connected SSD.

* Normal boot, no timeout reported and SD card recognized.
* Timeout reported following boot and SD card recognized and working.
* Timeout reported and SD card not recognized.

Repeating the boot process could result in any of the three conditions and
it did not seem to matter if a warm or cold boot was involved.

I have updated my test install to the 6.0 kernel, identified as

hbarta@boson:~$ uname -a
Linux boson 6.0.0-5-arm64 #1 SMP Debian 6.0.10-1 (2022-11-26) aarch64
GNU/Linux
hbarta@boson:~$

I rebooted and power cycled several times and was ready to declare this
fixed, but the most recent reboot is den=monstrating the issue - e.g. MMC
timeouts and no SD card in /dev. I inserted an SD card in the slot and the
timeout messages are continuing after the card is initialized.

[  274.788978] mmc1: new ultra high speed DDR50 SDHC card at address 
[  274.805432] mmcblk1: mmc1: SL16G 14.8 GiB
[  274.837154]  mmcblk1: p1 p2
[  281.828861] mmc0: Timeout waiting for hardware cmd interrupt.
[  281.836160] mmc0: sdhci:  SDHCI REGISTER DUMP ===
[  281.844122] mmc0: sdhci: Sys addr:  0x | Version:  0x9902
[  281.852082] mmc0: sdhci: Blk size:  0x | Blk cnt:  0x
[  281.860026] mmc0: sdhci: Argument:  0x0c00 | Trn mode: 0x
[  281.867973] mmc0: sdhci: Present:   0x01ff0001 | Host ctl: 0x0001
[  281.875905] mmc0: sdhci: Power: 0x000f | Blk gap:  0x
[  281.883839] mmc0: sdhci: Wake-up:   0x | Clock:0x7187
[  281.891779] mmc0: sdhci: Timeout:   0x | Int stat: 0x00018000
[  281.899716] mmc0: sdhci: Int enab:  0x00ff0003 | Sig enab: 0x00ff0003
[  281.907658] mmc0: sdhci: ACmd stat: 0x | Slot int: 0x0001
[  281.915602] mmc0: sdhci: Caps:  0x | Caps_1:   0x
[  281.923543] mmc0: sdhci: Cmd:   0x341a | Max curr: 0x0001
[  281.931481] mmc0: sdhci: Resp[0]:   0x | Resp[1]:  0x
[  281.939414] mmc0: sdhci: Resp[2]:   0x | Resp[3]:  0x
[  281.947338] mmc0: sdhci: Host ctl2: 0x
[  281.953232] mmc0: sdhci: 

I'm not sure if this matters, but when the timeouts are reported, orderly
shutdown takes several minutes longer than normal but eventually completes.

best,


On Tue, Dec 6, 2022 at 6:10 PM Diederik de Haas 
wrote:

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

Bug#1025435: u-boot-menu: no way to specify unversioned FDT path if versioned default path is present

[Vagrant Cascadian]

Control: tags 1025435 patch

On 2022-12-04, Nicolas Frattaroli wrote:
> On Sonntag, 4. Dezember 2022 18:20:38 CET Jonas Smedegaard wrote:
>> Quoting Nicolas Frattaroli (2022-12-04 18:03:30)
>> > u-boot-update should check as the very first thing for FDT
>> > line generation whether the path begin with an /, and if
>> > it does, the file exists, and U_BOOT_FDT_DIR is either
>> > default or empty (which gets set to default) make it use
>> > the U_BOOT_FDT file as-is.
>> > 
>> > This would allow for packages to provide supplemental device trees
>> > without replacing the whole kernel.
...
> A more concrete example is this defaults file:
>
>  
> U_BOOT_FDT=/usr/lib/devicetrees-plebian-quartz64/rockchip/rk3566-soquartz-blade.dtb
>  U_BOOT_FDT_DIR=""
>
> The expected output would be an fdt line in extlinux.conf with
>
>  fdt /usr/lib/devicetrees-plebian-quartz64/rockchip/rk3566-soquartz-blade.dtb
>
> even if /usr/lib/linux-image-$KERNELVERSION exists.
...
> The idea behind shipping Debian's kernel package rather than my own
> is that I don't want my users to be left stranded with an out of
> date kernel should I die in a tragic blimp accident.
>
> Here's a (somewhat untested in this iteration) patch:
>
> ---
> diff --git a/u-boot-update b/u-boot-update
> index 69da211..e5ffb22 100755
> --- a/u-boot-update
> +++ b/u-boot-update
> @@ -182,7 +182,10 @@ do
>   else
>   _INITRD=""
>   fi
> - if [ -e "${_BOOT_PATH}${U_BOOT_FDT_DIR}${_VERSION}/${U_BOOT_FDT}" ] && 
> [ -n "${U_BOOT_FDT}" ]
> + if [ -e ${U_BOOT_FDT} ] && [ -n "${U_BOOT_FDT}" ] && [ "/" = $(echo 
> "${U_BOOT_FDT}" | head -c1) ]

Should have quotes consistently:
  
if [ -e "${U_BOOT_FDT}" ] ...

> + then
> + _FDT="fdt ${U_BOOT_FDT}"
> + elif [ -e "${_BOOT_PATH}${U_BOOT_FDT_DIR}${_VERSION}/${U_BOOT_FDT}" ] 
> && [ -n "${U_BOOT_FDT}" ]
>   then
>   _FDT="fdt ${U_BOOT_FDT_DIR}${_VERSION}/${U_BOOT_FDT}"
>   elif [ -d "${_BOOT_PATH}${U_BOOT_FDT_DIR}${_VERSION}/" ]

The patch works for me, both with and without U_BOOT_FDT
specified... e.g. it doesn't break default behavior.

Only thing missing is a commit message for the patch. :)

Would love to push it and get a new version uploaded soon!

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1024850: bullseye-pu: package spf-engine/2.9.2-1

[Scott Kitterman]

On Wednesday, December 7, 2022 3:23:36 PM EST Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On Sat, 2022-11-26 at 14:21 -0500, Scott Kitterman wrote:
> > Currently the pyspf-milter fails to start due to a leftover, invalid
> > import statement.  This fixes it, backported from the upstream fix.
> > There is no risk of regression since the milter binary doesn't work
> > at
> > all.
> 
> Please go ahead.
> 
> Regards,
> 
> Adam

Uploaded.

Thanks,

Scott K

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

Bug#1025690: rust-clap-3: please upgrade to v4

[Blair Noctis]

> $ dev/list-rdeps.sh clap
> Versions of rust-clap in unstable:
>   librust-clap-dev 3.2.23-1
> 
> Versions of rdeps of rust-clap in unstable, that also exist in testing:
>   librust-bat-dev  0.22.1-1 depends 
> on librust-clap-3+default-dev (>= 3.2.20-~~), 
>   librust-bindgen+clap-dev 0.60.1-2 depends 
> on librust-clap-3+default-dev, 
>   librust-cargo-binutils-dev   0.3.5-2  depends 
> on librust-clap-2+default-dev (>= 2.33-~~), 
>   librust-cargo-c-dev  0.9.11-1 depends 
> on librust-clap-3+cargo-dev (>= 3.1-~~), librust-clap-3+color-dev (>= 
> 3.1-~~), librust-clap-3+default-dev (>= 3.1-~~), librust-clap-3+derive-dev 
> (>= 3.1-~~), 
>   librust-cargo-dev0.63.1-2 depends 
> on librust-clap-3+default-dev (>= 3.1.0-~~), 
>   librust-cbindgen+clap-dev0.24.3-2 depends 
> on librust-clap-3+default-dev (>= 3.1-~~), 
>   librust-clap-complete-dev3.1.1-2  depends 
> on librust-clap-3+std-dev (>= 3.1.0-~~), 
>   librust-clap-complete-fig-dev3.1.0-1+b1   depends 
> on librust-clap-3+std-dev (>= 3.1.0-~~), 
>   librust-criterion-dev0.3.6-3  depends 
> on librust-clap-2-dev (>= 2.33), 
>   librust-debcargo-dev 2.6.0-1  depends 
> on librust-clap-3+cargo-dev, librust-clap-3+default-dev, 
> librust-clap-3+derive-dev, 
>   librust-dotenv+clap-dev  0.15.0-2+b4  depends 
> on librust-clap-2+default-dev, 
>   librust-filespooler-dev  1.2.2-2  depends 
> on librust-clap-3+derive-dev (>= 3.1-~~), librust-clap-3+std-dev (>= 
> 3.1-~~), 
>   librust-git-absorb-dev   0.6.7-1  depends 
> on librust-clap-2+default-dev (>= 2.33-~~), 
>   librust-hexyl-dev0.8.0-2+b3   depends 
> on librust-clap-2+color-dev, librust-clap-2+default-dev, 
> librust-clap-2+suggestions-dev, librust-clap-2+wrap-help-dev, 
> X librust-rav1e-dev0.5.1-5  depends 
> on librust-clap-2+color-dev, 
>   librust-resource-proof-dev   1.0.39-4 depends 
> on librust-clap-3+default-dev, librust-clap-3+derive-dev, 
>   librust-sequoia-wot-dev  0.2.0-1+b2   depends 
> on librust-clap-2+default-dev (>= 2.33-~~), librust-clap-2+wrap-help-dev 
> (>= 2.33-~~), 
>   librust-structopt+color-dev  0.3.26-2 depends 
> on librust-clap-2+color-dev (>= 2.33-~~), 
>   librust-structopt+debug-dev  0.3.26-2 depends 
> on librust-clap-2+debug-dev (>= 2.33-~~), 
>   librust-structopt+default-dev0.3.26-2 depends 
> on librust-clap-2+default-dev (>= 2.33-~~), 
>   librust-structopt-dev0.3.26-2 depends 
> on librust-clap-2-dev (>= 2.33-~~), 
>   librust-structopt+doc-dev0.3.26-2 depends 
> on librust-clap-2+doc-dev (>= 2.33-~~), 
>   librust-structopt+no-cargo-dev   0.3.26-2 depends 
> on librust-clap-2+no-cargo-dev (>= 2.33-~~), 
>   librust-structopt+suggestions-dev0.3.26-2 depends 
> on librust-clap-2+suggestions-dev (>= 2.33-~~), 
>   librust-structopt+wrap-help-dev  0.3.26-2 depends 
> on librust-clap-2+wrap-help-dev (>= 2.33-~~), 
>   librust-structopt+yaml-dev   0.3.26-2 depends 
> on librust-clap-2+yaml-dev (>= 2.33-~~), 
> 
> Source packages in unstable whose autopkgtests are triggered by rust-clap:
>   rust-addr2line   0.18.0-1 triggered 
> by librust-clap-dev=3.2.23-1
>   rust-bindgen 0.60.1-2 triggered 
> by librust-clap-dev=3.2.23-1
>   rust-clap-complete   3.1.1-2  triggered 
> by librust-clap-dev=3.2.23-1
>   rust-exacl   0.9.0-2  triggered 
> by librust-clap-dev=3.2.23-1
>   rust-hdrhistogram7.5.0-1  triggered 
> by librust-clap-dev=3.2.23-1
>   rust-stderrlog   0.5.3-1  triggered 
> by librust-clap-dev=3.2.23-1
>   rust-zstd0.11.2-1 triggered 
> by librust-clap-dev=3.2.23-1

We can expect a steady (read: slow) upgrade.

-- 
Sdrager,
Blair Noctis


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1025311: solvespace: missing builds on mipsel and mips64el

[Ryan Pavlik]

Thanks for this advice on how to fix it better and unblock migration!

I've pushed an updated revision to both mentors and salsa. I'll reach
out to the science team for review and sponsorship.

On Fri, Dec 2, 2022 at 6:15 AM Graham Inggs  wrote:
>
> Source: solvespace
> Version: 3.1+ds1-2
> Severity: serious
> Tags: ftbfs
>
> Hi Maintainer
>
> The upload of solvespace 3.1+ds1-2 includes the change 'Drop s390x
> architecture due to test failures' [1], however the way this was done
> didn't only drop s390x, but also mipsel, mips64el, riscv64 and several
> other ports.  The missing builds on mipsel and mips64el now prevent
> migration of solvespace to testing.
>
> Seeing that solvespace builds fine on s390x, if the failing tests
> cannot be fixed, you could skip them on s390x only.  See my proposed
> debian/tests/control file below.  You could also try asking on
> debian-s...@lists.debian.org for help.
>
> Regards
> Graham
>
>
> [1] 
> https://salsa.debian.org/science-team/solvespace/-/commit/660e95c1d4583e078e31c5f91e7cd57f1aa1c7d1
>
>
> Tests: htmlmesh stlmesh surfaces
> Restrictions: allow-stderr
> Depends: solvespace, findutils, grep
> Architecture: !s390x
>
> Tests: thumbnail view wireframe
> Restrictions: allow-stderr
> Depends: solvespace, findutils, grep
>

Bug#1025718: RFS: runit/2.1.2-51 -- system-wide service supervision

[Lorenzo Puliti]

Package: sponsorship-requests
Severity: normal
X-Debbugs-Cc: plore...@disroot.org

Dear mentors,

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

 * Package name : runit
   Version  : 2.1.2-51
   Upstream contact : Gerrit Pape 
 * URL  : http://smarden.org/runit/
 * License  : CC0-1.0, BSD-3-clause, GPL-3+
 * Vcs  : https://salsa.debian.org/debian/runit
   Section  : admin

The source builds the following binary packages:

  runit - system-wide service supervision
  runit-run - service supervision (systemd and sysv integration)
  runit-systemd - transitional package for runit-systemd users
  getty-run - runscripts to supervise getty processes
  runit-init - system-wide service supervision (as init system)

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

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

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

  dget -x https://mentors.debian.net/debian/pool/main/r/runit/runit_2.1.2-51.dsc

Git repo:

  https://salsa.debian.org/debian/runit/-/tree/next

Changes since the last upload:

 runit (2.1.2-51) experimental; urgency=medium
 .
   * Improve readability of stage 1 (Closes: #1022814)
+ thanks to András Korn
   * Don't skip rcS boot scripts in stage 1 (Closes: #1023358)
   * Improve check for default-syslog (Closes: #1023476)
+ thanks to András Korn
   * runit: suggests ucspi-unix
   * invoke-run: use env instead of conf for chpst envdir
   * cpsv:
  - merge make_svlinks functionality into cpsv
  - temporary keep make_svlinks for backward compatibility
  - simplify syntax check
  - fallback on bin file for sync
  - configurable stock directory with CPSV_SOURCE
  - use CPSV_DEST instead of CPSV_DIR
  - more accurate diff
  - more accurate list output
  - use less ambiguous syntax
  - update manpage
   * Add source directory for cpsv
   * runit NEWS, changes in cpsv and invoke-run
   * runit-systemd NEWS, recommend removal
   * d/tests: update tests dependency (Closes: #1025641)

Regards,
-- 
  Lorenzo Puliti

Bug#1025705: util-linux: internal error

[Chris Hofstaedtler]

Control: reassign 1025705 e2fsprogs

* Francesco Potortì :
> # fsck -fy /backup/
> fsck from util-linux 2.38.1
> e2fsck 1.46.6-rc1 (12-Sep-2022)
... 
> Internal error: couldn't find dir_info for 8520768.
> e2fsck: aborted
...

e2fsck is in e2fsprogs, not util-linux. Reassigning.

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

[Itaï BEN YAACOV]

Yes, it is.  So it was a mesa bug, sorry about this.

Cheers,
Itaï

Le mardi 06 décembre 2022 à 22:33 +0100, Agustin Martin a écrit :
> El lun, 5 dic 2022 a las 13:40, Agustin Martin
> () escribió:
> > 
> > Hi,
> > 
> > Looking at
> > 
> > https://bugs.debian.org/1025312 [libgl1-mesa-dri: multiple packages
> > FTBFS and have autopkgtest regressions running test programs under
> > Xvfb] I noticed that this #1025326 bug report is mentioned as a
> > possible duplicate of #1025312.
> 
> This should be fixed in libgl1-mesa-dri 22.3.0-2, already in sid.
> Please check.
> 
> Thanks,
> 

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

[dann frazier]

On Wed, Dec 07, 2022 at 11:22:10AM -0500, James Bottomley wrote:
> On Wed, 2022-12-07 at 17:04 +0100, Ard Biesheuvel wrote:
> > On Wed, 7 Dec 2022 at 17:02, Gerd Hoffmann  wrote:
> > > 
> > > On Wed, Dec 07, 2022 at 09:14:39AM -0500, James Bottomley wrote:
> > > > On Wed, 2022-12-07 at 15:09 +0100, Ard Biesheuvel wrote:
> > > > > So at some point, these drivers will be removed rather than
> > > > > kept
> > > > > alive by the core team unless someone steps up.
> > > > 
> > > > How important is keeping them alive?
> > > 
> > > Most common use case is probably bootimg images created on other
> > > hypervisors on qemu.  Otherwise there is little reason to use
> > > something which is not virtio-scsi.
> > > 
> > > > I can volunteer to "maintain" them which I anticipate won't be
> > > > much effort (plus I'm used to looking after obsolete SCSI
> > > > equipment).  The hardware is obsolete, so the mechanics of their
> > > > emulation isn't going to change, the only potential risk is
> > > > changes in the guest to host transmission layer that breaks
> > > > something.
> > > 
> > 
> > Thanks James, that would be very helpful.
> > 
> > > Yes, I don't expect it being much effort, but knowing oldish scsi
> > > stuff certainly helps understanding the driver code if needed.  If
> > > you want step up sent a patch updating Maintainers.txt accordingly.
> > > 
> > 
> > Having the informed opinion of a domain expert should allow us to
> > diagnose issued related to these drivers with more confidence, and
> > also give us insight in how obsolete those drivers actually are.
> > 
> > I can send the patch if you prefer.
> 
> Sure, who can resist someone else doing all the work.
> 
> I note we do have a maintained LSI driver: OvmfPkg/LsiScsiDxe.  It
> seems to be based on the 53c896 which is really only a marginal subset
> of the 1030 ... if I'm remembering correctly the 1030 did Low Voltage
> Differential (so a faster SCSI Parallel bus), but since that's a SCSI
> Bus protocol, it should have no real impact on the utility of the
> emulation.  Is the LsiScsiDxe usable by Debian?

I tried it, but it doesn't seem to enumerate any blk devices.
The driver loads and reports that it is managing a device:

Shell> drivers
T   D
D   Y C I
R   P F A
V  VERSION  E G G #D #C DRIVER NAME IMAGE NAME
==  = = = == == === ==
[...]
6E 0010 D - -  1  - LSI 53C895A SCSI Controller Driver  LsiScsiDxe
[...]

But no blk devices. Using the same VM config and just swapping the
controller from lsilogic to virtio-scsi, yields the expected blk
devices.

To be clear, I'm unaware of OVMF ever working with this device in
Debian.

  -dann

Bug#1025717: cross-toolchain-base-mipsen FTBFS: install: cannot change owner and permissions

[Adrian Bunk]

Source: cross-toolchain-base-mipsen
Version: 22
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/fetch.php?pkg=cross-toolchain-base-mipsen=all=22=1670437077=0

...
dh_installdirs -plinux-libc-dev-mips-cross \
  usr/share/doc/linux-libc-dev-mips-cross \
  usr/share/lintian/overrides \
  usr/mips-linux-gnu
install: cannot change owner and permissions of 
‘debian/linux-libc-dev-mips-cross/usr/share/doc/linux-libc-dev-mips-cross’: 
Operation not permitted
install: cannot change owner and permissions of 
‘debian/linux-libc-dev-mips-cross/usr/share/lintian/overrides’: Operation not 
permitted
install: cannot change owner and permissions of 
‘debian/linux-libc-dev-mips-cross/usr/mips-linux-gnu’: Operation not permitted
dh_installdirs: error: install -m0755 -o 0 -g 0 -d 
debian/linux-libc-dev-mips-cross/usr/share/doc/linux-libc-dev-mips-cross 
debian/linux-libc-dev-mips-cross/usr/share/lintian/overrides 
debian/linux-libc-dev-mips-cross/usr/mips-linux-gnu returned exit code 1
make: *** [debian/rules:162: stamp-dir/install-linux.mips] Error 25

Bug#1025716: bullseye-pu: package mutt/2.0.5-4.1+deb11u2

[Salvatore Bonaccorso]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: m...@packages.debian.org, Marc Haber 
, "Kevin J. McCarthy" , Antonio 
Radici , car...@debian.org
Control: affects -1 + src:mutt

Hi Stable release managers,

[ Reason ]
mutt in bullseye (fixed in unstable already) is affected by #1024427,
mutt segfaults in pgp_gpgme_extract_keys(). The bug #1024427 attaches
a test mailbox (originally from debian-mentors list) to verify the
fix.

[ Impact ]
mutt crash if user opens problemac mail triggering the issue.

[ Tests ]
Explicitly tested agains the testcase attached in #bug1024427.

[ Risks ]
Patches are taken from upstream, with upstream indicating to them in
https://bugs.debian.org/1024427#10

[ Checklist ]
  [x] *all* changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in (old)stable
  [x] the issue is verified as fixed in unstable

[ Changes ]
Adds the three patches from upstream. Quoting upstream: The first is
just a cleaned up version of the patch you tested. The second fixes a
bug in the same function when used with older versions of gpgme. The
last fixes a similar potential key->uid dereference bug elsewhere in
the gpgme code.

[ Other info ]
None.

Regards,
Salvatore
diff -Nru mutt-2.0.5/debian/changelog mutt-2.0.5/debian/changelog
--- mutt-2.0.5/debian/changelog 2022-04-23 14:44:09.0 +0200
+++ mutt-2.0.5/debian/changelog 2022-12-07 22:39:58.0 +0100
@@ -1,3 +1,12 @@
+mutt (2.0.5-4.1+deb11u2) bullseye; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix gpgme crash when listing keys in a public key block (Closes: #1024427)
+  * Fix public key block listing for old versions of gpgme
+  * Add a check for key->uids in create_recipient_set
+
+ -- Salvatore Bonaccorso   Wed, 07 Dec 2022 22:39:58 +0100
+
 mutt (2.0.5-4.1+deb11u1) bullseye; urgency=medium
 
   * Non-maintainer upload.
diff -Nru mutt-2.0.5/debian/patches/series mutt-2.0.5/debian/patches/series
--- mutt-2.0.5/debian/patches/series2022-04-23 14:44:09.0 +0200
+++ mutt-2.0.5/debian/patches/series2022-12-07 22:39:58.0 +0100
@@ -15,3 +15,6 @@
 upstream/985152-body-color-slowness.patch
 upstream/Fix-seqset-iterator-when-it-ends-in-a-comma.patch
 upstream/Fix-uudecode-buffer-overflow.patch
+upstream/Fix-gpgme-crash-when-listing-keys-in-a-public-key-bl.patch
+upstream/Fix-public-key-block-listing-for-old-versions-of-gpg.patch
+upstream/Add-a-check-for-key-uids-in-create_recipient_set.patch
diff -Nru 
mutt-2.0.5/debian/patches/upstream/Add-a-check-for-key-uids-in-create_recipient_set.patch
 
mutt-2.0.5/debian/patches/upstream/Add-a-check-for-key-uids-in-create_recipient_set.patch
--- 
mutt-2.0.5/debian/patches/upstream/Add-a-check-for-key-uids-in-create_recipient_set.patch
   1970-01-01 01:00:00.0 +0100
+++ 
mutt-2.0.5/debian/patches/upstream/Add-a-check-for-key-uids-in-create_recipient_set.patch
   2022-12-07 22:39:58.0 +0100
@@ -0,0 +1,30 @@
+From b254f2fb44f994c48e2491adaf03d97d3c628283 Mon Sep 17 00:00:00 2001
+From: Kevin McCarthy 
+Date: Tue, 1 Nov 2022 20:22:06 -0700
+Subject: [PATCH] Add a check for key->uids in create_recipient_set.
+
+For gpgme < 1.11.0, it used this function to create the encryption key
+list.  The '!' was interpreted differently back then, and it
+apparently didn't check if the returned key had any uids before
+referencing it.  Add a check to prevent a segv as in the public key
+block fix.
+---
+ crypt-gpgme.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/crypt-gpgme.c b/crypt-gpgme.c
+index bf120ab50fc2..fdf44af4fe3d 100644
+--- a/crypt-gpgme.c
 b/crypt-gpgme.c
+@@ -915,7 +915,7 @@ static gpgme_key_t *create_recipient_set (const char 
*keylist, int use_smime)
+ buf[i-1] = 0;
+ 
+ err = gpgme_get_key (context, buf, , 0);
+-if (! err)
++if (! err && key->uids)
+   key->uids->validity = GPGME_VALIDITY_FULL;
+ buf[i-1] = '!';
+   }
+-- 
+2.38.1
+
diff -Nru 
mutt-2.0.5/debian/patches/upstream/Fix-gpgme-crash-when-listing-keys-in-a-public-key-bl.patch
 
mutt-2.0.5/debian/patches/upstream/Fix-gpgme-crash-when-listing-keys-in-a-public-key-bl.patch
--- 
mutt-2.0.5/debian/patches/upstream/Fix-gpgme-crash-when-listing-keys-in-a-public-key-bl.patch
   1970-01-01 01:00:00.0 +0100
+++ 
mutt-2.0.5/debian/patches/upstream/Fix-gpgme-crash-when-listing-keys-in-a-public-key-bl.patch
   2022-12-07 22:39:58.0 +0100
@@ -0,0 +1,54 @@
+From 48b6ea32e21db8b580cd3ca8c346c3e2c22756f6 Mon Sep 17 00:00:00 2001
+From: Kevin McCarthy 
+Date: Mon, 31 Oct 2022 15:02:57 -0700
+Subject: [PATCH] Fix gpgme crash when listing keys in a public key block.
+
+The gpgme code handling classic application/pgp assumed each key would
+have a uid.  Change it to check for a missing uid list.
+
+Also change it to list every uid 

Bug#1025715: Qt/KDE Team release plans for bookworm

[Aurélien COUDERC]

Package: release.debian.org
Severity: normal
X-Debbugs-Cc: Debian Qt/KDE Maintainers 

Dear Release Team,

with the freeze approaching the Qt/KDE Team has put up a document [0]
to share our release goals for the Qt and KDE stack for bookworm. We’d
like to encourage you to have a look at it.

As a quick summary, we target the following versions for bookworm :
- Qt 5 : 5.15.7
- Qt 6 : 6.4.2
- KDE Frameworks (libs) : 5.101
- Plasma (desktop) : 5.27.2
- KDE Gear (apps) 22.12.2

These targets should be mostly uneventful for all but Plasma.

For Plasma, version 5.27.0 will be released on Feb 14. so 2 days after
the beginning of the soft freeze.
What I would like to do is upload the 5.27 beta to unstable when it’s
released on Jan 19. and then consider the official 5.27.0 as a « small
update » on top of 5.27 beta that would be suitable for upload during the
soft freeze period.

It’s usually the case that between beta and .0 releases of Plasma the
changes are fixes targetted at bugs raised during the beta period. So I
think it’s not too far fetched of an interpretation.

It’s particularly important that we get Plasma 5.27 into bookworm
because this will be the last upstream release based on Qt 5 and we
expect it to receive important fixes for a long time, unlike our current
5.26.x which is more of an interim release and won’t get upstream fixes
after the last 5.26.5 point release on Jan 3.

Feedback welcome.


[0] https://wiki.debian.org/PkgQtKde/BookwormReleasePlans


Cheers,
--
Aurélien for the Qt/KDE Team

Bug#1025701: virtio-scsi (was Re: Bug#1016359: more info)

[Thorsten Glaser]

Dixi quod…

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


Vincent Danjean dixit:

>Downgrading to 2020.11-2+deb11u1 fixes the issue.


This led me to reinvestigate. Turns out that OVMF cannot boot
when the ISO image is added as a read-only SCSI disc to the
system, as opposed to a read-write one.

So I have to change my earlier statement to:

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

I agree that the virtio-scsi bug should be split from the lsilogic
bug, especially as the former seems to be a regression against
bullseye while the latter is a missing functionality.

Thanks,
//mirabilos
-- 
“ah that reminds me, thanks for the stellar entertainment that you and certain
other people provide on the Debian mailing lists │ sole reason I subscribed to
them (I'm not using Debian anywhere) is the entertainment factor │ Debian does
not strike me as a place for good humour, much less German admin-style humour”

Bug#1025714: octave-vrml: FTBFS randomly in sid (dpkg-gencontrol failure)

[Santiago Vila]

Package: src:octave-vrml
Version: 1.0.13-7
Tags: ftbfs

Dear Maintainer:

Today I tried to build this package from source and this is what happened:

   dh_missing -i -O--buildsystem=octave
   dh_octave_substvar -i -O--buildsystem=octave
   dh_installdeb -i -O--buildsystem=octave
   dh_gencontrol -i -O--buildsystem=octave
dpkg-gencontrol: error: bad line in substvars file 
debian/octave-vrml.substvars at line 2
dh_gencontrol: error: dpkg-gencontrol -poctave-vrml -ldebian/changelog 
-Tdebian/octave-vrml.substvars -Pdebian/octave-vrml returned exit code 255

dh_gencontrol: error: Aborting due to earlier error
make: *** [debian/rules:7: binary-indep] Error 2
dpkg-buildpackage: error: debian/rules binary-indep subprocess returned 
exit status 2


The file debian/octave-vrml.substvars seems in fact to be broken:

octave:Depends=octave (>= 7.3.0), octave-linear-algebra, 
octave-miscellaneous, octave-statistics

, octave-struct
octave:Upstream-Description=3D graphics using VRML
misc:Depends=
misc:Pre-Depends=


After getting this build failure for the first time I tried to build it 
more times to be sure and it failed most of the time, but not always, so 
be warned that the bug is random and you might have to try several times 
before getting a build failure.


For what is worth: The failure also happens here, so I'm quite confident 
that my build environment is not to blame:


https://tests.reproducible-builds.org/debian/logs/unstable/amd64/octave-vrml_1.0.13-7.build2.log.gz

[ I'm using X-debbugs-cc with debhelper maintainers in case they have 
something to say about this ].


Thanks.

Bug#1025713: isenkram FTBFS: error: version numbers in d/changelog and isenkram/__init__.py do not match

[Adrian Bunk]

Source: isenkram
Version: 0.48+nmu1
Severity: serious
Tags: ftbfs
X-Debbugs-Cc: Bastian Germann 

https://buildd.debian.org/status/fetch.php?pkg=isenkram=all=0.48%2Bnmu1=1669982912=0

...
   debian/rules override_dh_auto_build
make[1]: Entering directory '/<>'

error: version numbers in d/changelog and isenkram/__init__.py do not match

make[1]: *** [debian/rules:6: override_dh_auto_build] Error 1

Bug#1025701: ovmf: does not recognise virtio-scsi controller

[dann frazier]

On Wed, Dec 7, 2022 at 10:36 AM Vincent Danjean  wrote:
>
> Package: ovmf
> Version: 2022.11-1
> Severity: normal
>
>   Hi,
>
>   I was thinking my bug was #1016359, but with the additionnal
> info, it is a different one. So, I'm opening this bug as asked.
>
>   ovmf in sid does not allow one to boot over a virtio-scsi contrôleur.
> My disques are not seen anymore (not even in the EFI menus).
> Downgrading to 2020.11-2+deb11u1 fixes the issue.

Thanks for opening this new issue! As I mentioned in #1016359, I had
no problems booting a VM w/ virtio-scsi in sid, so this seems like it
may be config-specific. Can you provide me with a way to reproduce
this - e.g. your libvirt XML?

  -dann

Bug#1025712: marble: autopkgtest regression in 22.08.3-{1,2}

[Adrian Bunk]

Source: marble
Version: 4:22.08.3-2
Severity: serious
X-Debbugs-Cc: Sandro Knauß 

https://ci.debian.net/packages/m/marble/testing/amd64/

...
autopkgtest [22:10:52]: test acc: [---
cc1: warning: command-line option ‘-std=c++11’ is valid for C++/ObjC++ but not 
for C
cc1: warning: command-line option ‘-std=c++11’ is valid for C++/ObjC++ but not 
for C
Can't "next" outside a loop block at /usr/bin/abi-compliance-checker line 10171.
dh_acc: error: abi-compliance-checker -q -l libmarble-dev -v1 4:22.08.3-1 -dump 
debian/libmarble-dev.acc -dump-path 
debian/libmarble-dev/usr/lib/x86_64-linux-gnu/dh-acc/libmarble-dev_4:22.08.3-1.abi.tar.gz
 returned exit code 5
autopkgtest [22:11:17]: test acc: ---]
autopkgtest [22:11:17]: test acc:  - - - - - - - - - - results - - - - - - - - 
- -
acc  FAIL non-zero exit status 25
...

Bug#927255: powerpc-utils is uninstallable

[Lance Albertson]

On Thu, Dec 1, 2022 at 9:48 AM John Paul Adrian Glaubitz <
glaub...@physik.fu-berlin.de> wrote:

> Hi Lance!
>
> On 12/1/22 17:54, Lance Albertson wrote:
> > Unfortunately this is a major issue when trying to get a system
> installed using the
> > debian-installer. I am trying to support ppc64 (Big Endian) for our
> users, and Debian
> > is the only platform that still provides a modern ppc64 environment.
>
> Thanks for the praise ;-). It is possible partially through the support of
> OSUOSL ;-).
>
> > I've created my own netboot install images using the latest sid
> environment, and I am
> > unable to work around this and get a system installed. While the
> solution above works
> > for debootstrap itself, it makes it impossible to get a system installed.
> >
> > Could you change pmac-utils to Suggests instead of Depends? That way it
> should get things
> > working again. AFAIK this isn't a hard requirement anymore on ppc64 at
> least.
>
> Yes, I will demote the package to Suggests or even remove it. I don't
> think it's necessary
> anymore.
>

Any idea when you'll be able to get this pushed out?

Thanks!

-- 
Lance Albertson
Director
Oregon State University | Open Source Lab

Bug#1025711: marble:

[Adrian Bunk]

Source: marble
Version: 4:22.08.3-2
Severity: serious
Tags: ftbfs
X-Debbugs-Cc: Sandro Knauß 

https://buildd.debian.org/status/package.php?p=marble=sid

Build-Depends: qtwebengine5-dev (>= 5.14.0~) [all amd64 arm64 armhf i386 
mips64el mipsel]

I suspect "all" might be interpreted as "binary-all" by some tools,
but as "all architectures" by other tools.

It might work better to write this as (untested):
Build-Depends: qtwebengine5-dev (>= 5.14.0~) [amd64 arm64 armhf i386 mips64el 
mipsel]
Build-Depends-Indep: qtwebengine5-dev (>= 5.14.0~)

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

[Sad Clouds]

Please close this bug, I was mistaken. The issue seems to be related to
something else. I have just upgraded again to the latest Kerberos
binaries and cannot reproduce the original issue. Could me intermittent
hardware fault which coincided with recent package upgrade activity.

Bug#1022574: samba: Kerberos 22H2 Samba problem in Debian stable | Backports Version or Stable Update?

[Tom Weber]

Am 02.11.22 um 08:39 schrieb Michael Tokarev:

24.10.2022 15:47, Samuel Wolf wrote:

Yes it is possible, more, it is trivial to _patch_ it. But it is not that easy
to make the resulting binaries into the archive.


Samuel, care to test a bullseye 4.13 samba patched with this 22H2 kerberos 
thing?
I don't have a test environment here, setting it up is quite a bit of work, - 
I'll
need several virtual machines with different OSes, including win 22H2..

I prepared bullseye samba build, if you (or anyone else) have a way to test 
them,
please do.

http://www.corpit.ru/mjt/packages/samba/debian-11-bullseye-test/ , in 
particular,
http://www.corpit.ru/mjt/packages/samba/debian-11-bullseye-test/samba-4.13/samba_4.13.13+dfsg-1~deb11u5a/
In an apt/sources.list form, it is:

deb http://www.corpit.ru/mjt/packages/samba debian-11-bullseye-test/samba-4.13/

(the trailing slash is important!).  This is a temporary repository signed with
my GPG key I use for Debian packaging.

There are 2 changes in this release compared with current 
4.13.13+dfsg-1~deb11u5:

  samba (2:4.13.13+dfsg-1~deb11u5a) bullseye-test; urgency=medium

    * CVE-2022-3437-des3-overflow-v4a-4.13.patch
  Closes: CVE-2022-3437 (Heimdal unwrap_des/unwrap_des3 buffer overflow)
    * windows11-22h2-kerrberos-kdc-avoid-re-encoding-KDC-REQ-BODY.patch
  Closes: #1022574, incorrect AD DC behavior with Windows11 22H2

If everything goes well, I'll try to push this one to bullseye-security.


Hitting the Problem with 22H2 i upgraded samba today to your provided packages 
on bullseye.

So far all seems to work - quick tests with 7/10/11/2016

thanks for your work!
  Tom

Bug#1024757: Editor: -key ignored

[Dr. Nikolaus Klepp]

Anno domini 2022 Tue, 06 Dec 23:20:06 +0100
 Kristian Nielsen scripsit:
> [...]
> The 5.15.6 version entered Unstable on November 29, so something like this
> should be a recent snapshot that contains the 5.15.4 version:
>
>   http://snapshot.debian.org/archive/debian/20220928T030933Z/
>
> I'll see if I can get a definite confirmation that the QT bug is the root
> cause, and then probably re-assign this bug to QT.

Thank you for the link. Reverting to the old version solves the problem.

Nik

> Thanks,
>
>  - Kristian.
>



--
Please do not email me anything that you are not comfortable also sharing with 
the NSA, CIA ...

Bug#1016359: more info

[Vincent Danjean]

  Hi,

Le 07/12/2022 à 17:13, Thorsten Glaser a écrit :

OK. I’ll leave the lead for that to Vincent, but feel free to
keep me in Cc on that one; I probably can dig a little deeper
in the failing build with a bit more time.


I filled a new bug: #1025701

  Regards
Vincent

Bug#1025710: bullseye-pu: package awstats/7.8-2+deb11u1

[Salvatore Bonaccorso]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: awst...@packages.debian.org, car...@debian.org
Control: affects -1 + src:awstats

Hi Stable release managers,

awstats is prone to a XSS vulnerability, but it does not warrant a
DSA. Following the QA upload to unstable (which should migrate in two
days), I would like to propose the change as well for stable and have
it included in the next point release.

CVE-2022-46391 is assigned to the issue (Cf. #1025410)
https://github.com/eldy/AWStats/pull/226

[ Impact ]
Issue remains open, but might be cherry-picked as well for furture
upload via security or in the next point release.

[ Tests ]
None specific

[ Risks ]
It is a targetted fix for the reporte XSS vulnerability.

[ Checklist ]
  [x] *all* changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [X] attach debdiff against the package in (old)stable
  [x] the issue is verified as fixed in unstable

[ Changes ]

   * fix cross site scripting (CVE-2022-46391) (Closes: #1025410)

[ Other info ]
Nothing I'm aware of.

Regards,
Salvatore
diff -Nru awstats-7.8/debian/changelog awstats-7.8/debian/changelog
--- awstats-7.8/debian/changelog2021-02-02 08:56:57.0 +0100
+++ awstats-7.8/debian/changelog2022-12-07 21:47:25.0 +0100
@@ -1,3 +1,10 @@
+awstats (7.8-2+deb11u1) bullseye; urgency=medium
+
+  * QA upload.
+  * fix cross site scripting (CVE-2022-46391) (Closes: #1025410)
+
+ -- Salvatore Bonaccorso   Wed, 07 Dec 2022 21:47:25 +0100
+
 awstats (7.8-2) unstable; urgency=high
 
   * QA upload.
diff -Nru awstats-7.8/debian/patches/fix-cross-site-scripting.patch 
awstats-7.8/debian/patches/fix-cross-site-scripting.patch
--- awstats-7.8/debian/patches/fix-cross-site-scripting.patch   1970-01-01 
01:00:00.0 +0100
+++ awstats-7.8/debian/patches/fix-cross-site-scripting.patch   2022-12-07 
21:47:25.0 +0100
@@ -0,0 +1,29 @@
+From: rekter0 <58881147+rekt...@users.noreply.github.com>
+Date: Mon, 7 Nov 2022 15:12:03 +0100
+Subject: fix cross site scripting
+Origin: 
https://github.com/eldy/AWStats/commit/38682330e1ec3f3af95f9436640358b2d9e4a965
+Bug: https://github.com/eldy/AWStats/pull/226
+Bug-Debian: https://bugs.debian.org/1025410
+Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2022-46391
+
+xss due to printing response from Net::XWhois without proper checks
+---
+ wwwroot/cgi-bin/plugins/hostinfo.pm | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/wwwroot/cgi-bin/plugins/hostinfo.pm 
b/wwwroot/cgi-bin/plugins/hostinfo.pm
+index 95b2c20b7b91..1f0ac699459d 100644
+--- a/wwwroot/cgi-bin/plugins/hostinfo.pm
 b/wwwroot/cgi-bin/plugins/hostinfo.pm
+@@ -181,7 +181,7 @@ sub BuildFullHTMLOutput_hostinfo {
+ 
+   _head("Full Whois Field",0,0,'whois');
+   if ($w && $w->response()) {
+-  print "".($w->response())."\n";
++  print "".CleanXSS($w->response())."\n";
+   }
+   else {
+   print "The Whois command failed.Did the 
server running AWStats is allowed to send WhoIs queries (If a firewall is 
running, port 43 should be opened from inside to outside) ?\n";
+-- 
+2.38.1
+
diff -Nru awstats-7.8/debian/patches/series awstats-7.8/debian/patches/series
--- awstats-7.8/debian/patches/series   2021-02-02 08:56:57.0 +0100
+++ awstats-7.8/debian/patches/series   2022-12-07 21:47:25.0 +0100
@@ -11,3 +11,4 @@
 2008_twitter.patch
 2009_googlesearch.patch
 0013-Only-look-for-configuration-in-dedicated-awstats-dir.patch
+fix-cross-site-scripting.patch

Bug#946268: Please add support for custom entries

[Vagrant Cascadian]

Control: tags 946268 -patch

On 2019-12-24, Andrei POPESCU wrote:
> On Ma, 17 dec 19, 19:49:37, andreimpope...@gmail.com wrote:
>> Additionally, if the variable is always set the checks must be changed 
>> slightly, otherwise the script would always error out.
>
> If I'm being a little bit paranoid about checks on the file I figured I 
> might as well issue a message in case the file is a symlink.
>
> Updated patch attached.

This patch seems to have gotten lost along the way at some point and no
longer applies ...

Would you be able to rebase it again? :)


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1025700: bullseye-pu: package virglrenderer/0.8.2-5+deb11u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Wed, 2022-12-07 at 18:02 +0100, Tobias Frost wrote:
> I'm currently preparing a security update for virglrenderer for LTS
> and figured out that there is one of the fixed CVEs is not adressed
> in bullseye
> yet.
> 
> The CVE fixed is CVE-2022-0135: (#1009073)
> 
[...]
>  An out-of-bounds write issue was found in the VirGL virtual OpenGL
> renderer
>  (virglrenderer). This flaw allows a malicious guest to create a
> specially
>  crafted virgil resource and then issue a VIRTGPU_EXECBUFFER ioctl,
> leading to a
>  denial of service or possible code execution.
> 

Please go ahead.

Regards,

Adam

Bug#1025601: bullseye-pu: package leptonlib/1.79.0-1.1+deb11u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Tue, 2022-12-06 at 16:26 +0100, Helmut Grohne wrote:
> CVE-2022-38266 is a low impact vulnerability where leptonlib would
> crash
> with arithmetic exceptions on certain JPEG files. Since this is only
> DoS, it does not go via bullseye-security.
> 

and thus:

+leptonlib (1.79.0-1.1+deb11u1) bullseye-security; urgency=medium

should use "bullseye" as the distribution.

Please go ahead.

Regards,

Adam

Bug#1025414: bullseye-pu: package node-hawk/8.0.1+dfsg-2+deb11u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Sun, 2022-12-04 at 11:42 +0100, Yadd wrote:
> node-hawk used a regular expression to parse `Host` HTTP header
> (`Hawk.utils.parseHost()`), which was subject to regular expression
> DoS attack
> (CVE-2022-29167).
> 

Please go ahead.

Regards,

Adam

Bug#1025387: bullseye-pu: package node-qs/6.9.4+ds-1+deb11u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Sat, 2022-12-03 at 20:25 +0100, Yadd wrote:
> node-qs is vulnerable to prototype pollution, this affects web
> applications using node-express (CVE-2022-24999)
> 

Please go ahead.

Regards,

Adam

Bug#1025329: bullseye-pu: package cwltool/3.0.20210124104916-3+deb11u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Fri, 2022-12-02 at 16:33 +0100, Michael R. Crusoe wrote:
> cwltool is not usable without the python3-distutils package also
> installed. This is rare, but can happen on fresh Debian installs.
> 
> I discovered this today while testing instructions for WSL2 users.
> 

Please go ahead.

Regards,

Adam

Bug#1025323: bullseye-pu: package nano/5.4-2+deb11u2

[Adam D. Barratt]

Control: tags -1 + confirmed d-i

On Fri, 2022-12-02 at 15:42 +0100, Jordi Mallach wrote:
> I'm requesting the acceptance of a new nano update for stable,
> with 3 additional upstream patches that fix two crash conditions
> and a data-loss condition.
> 

Please go ahead.

Regards,

Adam

Bug#1025205: bullseye-pu: package mplayer/2:1.4+ds1-1+deb11u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Wed, 2022-11-30 at 22:42 +0100, Moritz Muehlenhoff wrote:
> This updates fixes various minor crashes in mplayer, which
> don't warrant a DSA by itself. I've run the PoCs against
> the updated build where applicable and also tested various
> random media files.
> 
> Note this isn't fixed in unstable, since mplayer FTBFSes
> with ffmpeg 5.0 and won't be in bookworm (#1005899).
> 

Please go ahead.

Regards,

Adam

Bug#1025137: bullseye-pu: package g810-led/0.4.2-1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Wed, 2022-11-30 at 08:32 +0100, Stephen Kitt wrote:
> g810-led has a security issue in stable; it leaves /dev/input/eventXX
> device nodes world-readable and writable (CVE-2022-46338). The issue
> is marked no-dsa, but I would like to provide a fix in the next
> point-release. The fix is already in unstable (0.4.2-3).
> 
> The attached debdiff fixes the issue by patching the udev rules file:
> the affected device nodes have their mode set to 660 instead of 666,
> and uaccess is used to provide access to the user at the console. I
> own relevant hardware and have verified the fix myself on a multi-
> user
> system.
> 

Please go ahead.

Regards,

Adam

Bug#1025083: bullseye-pu: package omnievents/1:2.6.2-5.1+deb11u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Tue, 2022-11-29 at 14:58 -0300, Guilherme de Paula Xavier
Segundoomnievents enables CORBA applications to communicate through 
> asynchronous
> broadcast channels rather than direct method calls.
> 
> omnievents-doc is a package that can be installed as a suggestion of
> omnievents containing the documentation of package, but which cannot
> be fully
> used due to broken symlink.
> 

Please go ahead.

Regards,

Adam

Bug#1025010: bullseye-pu: package jtreg6/6.1+2-1~deb11u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Mon, 2022-11-28 at 20:35 +0100, Moritz Muehlenhoff wrote:
> openjdk bumped the requirements for the test suite within
> their 11.x branch (which is what we ship in Bullseye), it
> now needs jtreg6.
> 

"Yay". Please go ahead.

Regards,

Adam

Bug#1024745: bullseye-pu: package node-xmldom/0.5.0-1+deb11u2

[Adam D. Barratt]

Control: tags -1 + confirmed

On Thu, 2022-11-24 at 09:26 +0100, Yadd wrote:
> node-xmldom is vulnerable: it doesn't verify that root element is
> uniq
> (#1024736, CVE-2022-39353)
> 

Please go ahead.

Regards,

Adam

Bug#1024850: bullseye-pu: package spf-engine/2.9.2-1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Sat, 2022-11-26 at 14:21 -0500, Scott Kitterman wrote:
> Currently the pyspf-milter fails to start due to a leftover, invalid
> import statement.  This fixes it, backported from the upstream fix.
> There is no risk of regression since the milter binary doesn't work
> at
> all.
> 

Please go ahead.

Regards,

Adam

Bug#1024805: bullseye-pu: package libvirt/7.0.0-3+deb11u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Fri, 2022-11-25 at 15:19 +0100, Guido Günther wrote:
> Fix lxc container reboots and shutdown (#983871, #991773).
> 

Please go ahead.

Regards,

Adam

Bug#848578: [PATCH] ts: Enable UTF-8 binary mode for input and output processing (Closes: #848578)

[Nicolas Schier]

Dear Joey,

On Fri 07 Oct 2022 20:14:29 GMT, Nicolas Schier wrote:
> Enable UTF-8 compatible processing of input and output to correctly 
> output e.g.
> timestamps containing non-latin letters (cp. [1]).
> 
> [1]: https://bugs.debian.org/848578
> 
> Signed-off-by: Nicolas Schier 
> ---
>  ts | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/ts b/ts
> index af23cf7..fbd5b1a 100755
> --- a/ts
> +++ b/ts
> @@ -54,6 +54,11 @@ use strict;
>  use POSIX q{strftime};
>  no warnings 'utf8';
>  
> +# Ensure that text read or printed are converted from/to UTF-8.
> +binmode STDIN, ':utf8';
> +binmode STDOUT, ':utf8';
> +binmode STDERR, ':utf8';
> +
>  $|=1;
>  
>  my $rel=0;
> -- 
> 2.30.2

Are there chances that you still apply such patches?  After your call 
for adoption: Is there some new maintainer for moreutils already 
available?

Kind regards,
Nicolas

-- 
epost|xmpp: nico...@fjasle.eu  irc://oftc.net/nsc
↳ gpg: 18ed 52db e34f 860e e9fb  c82b 7d97 0932 55a0 ce7f
 -- frykten for herren er opphav til kunnskap --


signature.asc
Description: PGP signature

Bug#1019096: bullseye-pu: package cifs-utils/2:6.11-3.1+deb11u2

[Adam D. Barratt]

Control: tags -1 + confirmed

On Sat, 2022-09-03 at 22:12 +0300, Michael Tokarev wrote:
> There's a FTBFS issue with cifs-utils on bullseye, #993014.
> This update address that FTBFS issue only, with no other
> changes
> 
> [ Reason ]
> The package fails to build from source when doing non-parallel
> build (or actually when doing parallel build too, sometimes),
> due to wrong ordering/dependencies in the upstream Makefile
> system. The problem is that the install target is two-part,
> and "second" part relies on mkdir done in "first" part, while
> not enforcing it. This (usually) succeeds when doing parallel
> build, but always fails when doing non-parallel build.
> 

Please go ahead; sorry for the delay.

Regards,

Adam

Bug#1017723: bullseye-pu: package nftables/0.9.8-3.2

[Adam D. Barratt]

Control: tags -1 + confirmed

On Sun, 2022-09-04 at 15:09 +0100, Jeremy Sowden wrote:
> On 2022-09-03, at 14:53:45 +0100, Adam D. Barratt wrote:
> > On Fri, 2022-08-19 at 16:05 +0100, Jeremy Sowden wrote:
> > > The related nftables bug is:
> > > 
> > >   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1017359
> > > 
> > > [ Reason ]
> > > nftables uses a fixed-size array containing the locations of the
> > > expressions within each rule that it sends to the kernel to
> > > provide
> > > more informative error-reporting.  If the rule is rejected by the
> > > kernel, the kernel will provide an ID for the expression which
> > > was
> > > responsible, and nftables will use this to highlight it when
> > > outputting the rule in the error message:
> > > 
> > >  # nft add rule t c iif lo reject with icmp 255
> > >  Error: Could not process rule: Invalid argument
> > >  add rule t c iif lo reject with icmp 255
> > >  ^^
> > > 
> > > There is an off-by-one error in the bounds-checking used before
> > > adding the details of an expression to this array.  The result of
> > > this is that if a rule contains enough expressions, nftables will
> > > write past the end of the array leading to memory-corruption and
> > > possibly crashes.
> > 
> > The debdiff is somewhat confusing.
> > 
> > +nftables (0.9.8-3.2) unstable; urgency=medium
> > 
> > This is an upload to bullseye, not unstable. Additionally, the
> > version
> > should be 0.9.8-3.1+deb11u1.
> > 
> > + -- Sven Auhagen   Sat, 16 Jul 2022
> > 11:29:27 +0200
> > 
> > Who is this? It's obviously not you, but also doesn't appear to be
> > related to the nftables bug report you mentioned.
> 
> Whoops.  Silly mistakes.  Still learning the ropes.  I've amended the
> change-log entry.
> 

+It fixes a one off for the check for NFT_NLATTR_LOC_MAX

s/one off/off by one/

Please go ahead; sorry for the delay.

Regards,

Adam

Bug#1020303: bullseye-pu: package modsecurity-apache/2.9.3-3+deb11u2

[Adam D. Barratt]

On Mon, 2022-09-19 at 19:25 +0200, Alberto Gonzalez Iniesta wrote:
> modsecurity-crs has been released today [1]. It fixes a security
> issue,
> here is the announcement:
> 
> CVE-2022-39956 - Content-Type or Content-Transfer-Encoding MIME
> header fields
> abuse
> 
[...]
> Important: The mitigation against these vulnerabilities depends on
> the
> installation of the latest ModSecurity version (v2.9.6/v3.0.8) or an
> updated
> version with backports of the security fixes in these versions.
> If you fail to update ModSecurity, the webserver / engine will refuse
> to start
> with the following error message: "Error creating rule: Unknown
> variable:
> MULTIPART_PART_HEADERS".
> 
[...]
> As you may see in [1] a newer modsecurity is needed in other to apply
> this fix. We, modsecurity packaging team, are preparing a patched
> version of both modsecurity-apache (this bug report) and
> libmodsecurity3
> (coming up). After that we'll upload the updated modsecurity-crs.
> 

Apologies for the delay in getting back to you.

It's not entirely clear to me from the above, but what happens if this
modsecurity-apache update gets into a point release but the
libmodsecurity3 update does not? You mention the latter as "coming up"
above, but I can't see a request for it.

Regards,

Adam

Bug#1025709: src:ruby-grape: unsatisfied build dependency in testing: ruby-grape-entity

[Paul Gevers]

Source: ruby-grape
Version: 1.6.2-2
Severity: serious
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: edos-uninstallable

Dear maintainer(s),

Dose [1] is reporting a build issue with your package, it's missing a
build dependency. Obviously your build dependencies shouldn't be
removed from testing, but unfortunately there are multiple scenarios
where that can happen nevertheless. To uphold our social contract,
Debian requires that packages can be rebuild from source in the suite
we are shipping them, so currently this is a serious issue with your
package in testing.

Can you please investigate the situation and figure out how to resolve
it? Regularly, if the build dependency is available in unstable,
helping the maintainer of your Build-Depends to enable migration to
testing is a great way to solve the issue. If your build dependency is
gone from unstable and testing, you'll have to fix the build process
in some other way.

Paul

Note: this bug report was sent after some quick manual checks using a
template. Please reach out to me if you believe I made a mistake in my
process.

[1] https://qa.debian.org/dose/debcheck/src_testing_main/latest/amd64.html



OpenPGP_signature
Description: OpenPGP digital signature

Bug#946966: Fix some minor issues and improve the code slightly

[Vagrant Cascadian]

On 2022-12-07, Vagrant Cascadian wrote:
> On 2019-12-18, Andrei POPESCU wrote:
>> Attached patch fixes some issues reported by shellcheck
>
> Thanks for the patch!
>
> I will try and merge some of the changes...

Actually, most of the changes appear to be merged already.

  
>> as well as make some minor optimizations (use bash code instead of
>> external programs where this makes sense).
>
> This is not bash code though, so the bashisms are not appropriate...

It *was* originally bash code, but switched more recently to /bin/sh...


>> @@ -202,12 +202,12 @@ label l${_NUMBER}r
>>  linux ${_BOOT_DIRECTORY}/${_KERNEL}
>>  ${_INITRD}
>>  ${_FDT}
>> -append ${U_BOOT_ROOT} $(echo ${U_BOOT_PARAMETERS} | sed -e 's| 
>> quiet||') single
>> +append ${U_BOOT_ROOT} ${U_BOOT_PARAMETERS# quiet} single
>
> Will have to take another look at this one, but it sure *looks*
> cleaner. :)

This seems to be the only thing outstanding... which I'll try to
remember to test.


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1025708: bullseye-pu: package debootstrap/1.0.123+deb11u2

[Luca Boccassi]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-CC: dimitri.led...@canonical.com debian-b...@lists.debian.org 
debian-wb-t...@lists.debian.org

Dear release team,

An improvement to reduce the number of dependencies pulled down by the
usr-merged debootstrapped image has been available in unstable,
bookworm and bullseye-backports for a while. I'd like to make this
improvement available in bullseye as well, as it saves ~50MB on a
minbase image. See:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1025657

I have tested this locally and seems to work as expected.

Debdiff attached. It also enables usrmerge on hurd.

-- 
Kind regards,
Luca Boccassi
diff -Nru debootstrap-1.0.123+deb11u1/debian/changelog debootstrap-1.0.123+deb11u2/debian/changelog
--- debootstrap-1.0.123+deb11u1/debian/changelog	2022-07-28 12:04:03.0 +0100
+++ debootstrap-1.0.123+deb11u2/debian/changelog	2022-12-07 15:31:02.0 +
@@ -1,3 +1,19 @@
+debootstrap (1.0.123+deb11u2) bullseye; urgency=medium
+
+  * Non-maintainer upload.
+
+  [ Samuel Thibault ]
+  * Enable usrmerge on hurd-i386 too
+
+  [ Ansgar ]
+  * debootstrap: optionally exclude specific dependencies
+  * debian-common: exclude usrmerge when installing usr-is-merged
+
+  [ Tianon Gravi ]
+  * Apply "EXCLUDE_DEPENDENCY" during "resolve_deps" (Closes: #1025657)
+
+ -- Luca Boccassi   Wed, 07 Dec 2022 15:31:02 +
+
 debootstrap (1.0.123+deb11u1) bullseye; urgency=medium
 
   * Non-maintainer upload.
diff -Nru debootstrap-1.0.123+deb11u1/debootstrap debootstrap-1.0.123+deb11u2/debootstrap
--- debootstrap-1.0.123+deb11u1/debootstrap	2022-07-28 11:55:11.0 +0100
+++ debootstrap-1.0.123+deb11u2/debootstrap	2022-12-07 15:30:03.0 +
@@ -41,6 +41,7 @@
 UNPACK_TARBALL=""
 ADDITIONAL=""
 EXCLUDE=""
+EXCLUDE_DEPENDENCY=""
 VERBOSE=""
 CERTIFICATE=""
 CHECKCERTIF=""
diff -Nru debootstrap-1.0.123+deb11u1/functions debootstrap-1.0.123+deb11u2/functions
--- debootstrap-1.0.123+deb11u1/functions	2022-07-28 11:55:40.0 +0100
+++ debootstrap-1.0.123+deb11u2/functions	2022-12-07 15:30:03.0 +
@@ -1361,7 +1361,6 @@
 
 	local link_dir
 	case $ARCH in
-	hurd-*)	return 0 ;;
 	amd64)	link_dir="lib32 lib64 libx32" ;;
 	i386)	link_dir="lib64 libx32" ;;
 	mips|mipsel)
@@ -1555,6 +1554,9 @@
 NEWPKGS="$NEWPKGS $("$PKGDETAILS" GETDEPS "$pkgdest" $PKGS)"
 			done
 		done
+		if [ -n "${EXCLUDE_DEPENDENCY:-}" ]; then
+			NEWPKGS="$(without "$NEWPKGS" "$EXCLUDE_DEPENDENCY")"
+		fi
 		PKGS=$(echo "$PKGS $NEWPKGS" | tr ' ' '\n' | sort | uniq)
 		local REALPKGS=""
 		for s in $SUITE $EXTRA_SUITES; do
diff -Nru debootstrap-1.0.123+deb11u1/scripts/debian-common debootstrap-1.0.123+deb11u2/scripts/debian-common
--- debootstrap-1.0.123+deb11u1/scripts/debian-common	2022-07-28 11:55:40.0 +0100
+++ debootstrap-1.0.123+deb11u2/scripts/debian-common	2022-12-07 15:30:03.0 +
@@ -52,6 +52,7 @@
 			;;
 		*)
 			required="$required usr-is-merged"
+			EXCLUDE_DEPENDENCY="$EXCLUDE_DEPENDENCY usrmerge"
 			;;
 	esac
 }


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

Bug#1025707: ITP: ruby-oedipus-lex -- Lexer generator in the same family as Rexical and Rex

[Lucas Kanashiro]

Package: wnpp
Severity: wishlist

* Package name: ruby-oedipus-lex
  Version: 2.6.0
  Upstream Author:  Ryan Davis 
* URL: https://github.com/seattlerb/oedipus_lex
* License:    Expat
  Programming Lang:   Ruby
  Description:   Lexer generator in the same family as 
Rexical and Rex


 Oedipus Lex is a lexer generator in the same family as Rexical and
 Rex. Oedipus Lex is a independent lexer fork of Rexical. Rexical was
 in turn a fork of Rex. We've been unable to contact the author of rex
 in order to take it over, fix it up, extend it, and relicense it to
 MIT. So, Oedipus was written clean-room in order to bypass licensing
 constraints (and because bootstrapping is fun).
 .
 Oedipus brings a lot of extras to the table and at this point is only
 historically related to rexical. The syntax has changed enough that
 any rexical lexer will have to be tweaked to work inside of oedipus.
 At the very least, you need to add slashes to all your regexps.
 .
 Oedipus, like rexical, is based primarily on generating code much like
 you would a hand-written lexer. It is _not_ a table or hash driven
 lexer. It uses StrScanner within a multi-level case statement. As such,
 Oedipus matches on the _first_ match, not the longest (like lex and
 its ilk).

This package is needed by ruby-rubocop-ast which is a dependency of 
rubocop. It will be maintained under the Ruby team's umbrella.


--
Lucas Kanashiro

Bug#946966: Fix some minor issues and improve the code slightly

[Vagrant Cascadian]

On 2019-12-18, Andrei POPESCU wrote:
> Attached patch fixes some issues reported by shellcheck

Thanks for the patch!

I will try and merge some of the changes...

> as well as make some minor optimizations (use bash code instead of
> external programs where this makes sense).

This is not bash code though, so the bashisms are not appropriate...


> diff --git a/u-boot-update b/u-boot-update
> index 2cfe3ca..2a25531 100755
> --- a/u-boot-update
> +++ b/u-boot-update
> @@ -103,10 +103,10 @@ EOF
>   done < /etc/fstab
>  fi
>  
> -# if not in fsrab, try from current kernel arguments
> +# if not in fstab, try from current kernel arguments
>  if [ -z "${U_BOOT_ROOT}" ]
>  then
> - for param in `cat /proc/cmdline`
> + for param in $(< /proc/cmdline)

I'd probably prefer $(cat /proc/cmdline) ... just for clarity.


> @@ -176,7 +176,7 @@ do
>   _FDT=""
>   fi
>  
> - if echo ${U_BOOT_ALTERNATIVES} | grep -q default
> + if [[ "${U_BOOT_ALTERNATIVES}" == *default* ]]

Requires bash.


> @@ -191,7 +191,7 @@ label l${_NUMBER}
>  
>   fi
>  
> - if echo ${U_BOOT_ALTERNATIVES} | grep -q recovery
> + if [[ "${U_BOOT_ALTERNATIVES}" == *recovery* ]]

Also requires bash.


> @@ -202,12 +202,12 @@ label l${_NUMBER}r
>   linux ${_BOOT_DIRECTORY}/${_KERNEL}
>   ${_INITRD}
>   ${_FDT}
> - append ${U_BOOT_ROOT} $(echo ${U_BOOT_PARAMETERS} | sed -e 's| 
> quiet||') single
> + append ${U_BOOT_ROOT} ${U_BOOT_PARAMETERS# quiet} single

Will have to take another look at this one, but it sure *looks*
cleaner. :)


> - _NUMBER="$((${_NUMBER} + 1))"
> + _NUMBER="$((_NUMBER + 1))"

This looks like a typo? or maybe bash syntax?


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#955208: rustup was published to crates.io; I'd be great to have it packaged in Debian

[Fabian Grünbichler]

> Hello there,
> 
> two years ago, Ximin stated that rustup cannot enter Debian until either
> 
> - https://github.com/rust-lang/rustup/issues/835 OR
> - https://salsa.debian.org/rust-team/debcargo/-/merge_requests/22
> 
> is fixed. The thing is that the first issue was closed in between. Is
> there any hope that we could get rustup as a package, please?

Unfortunately, that issue was just closed as WONTFIX, not because rustup
is actually published on crates.io now ;)

> My motivation is that I want to hack on a project that won't compile
> if rustup is not installed, and I don't like installing anything out
> of dpkg.

There are still some efforts to package it, but I am not sure whether
they will be done in time for the bookworm freeze.

see

https://salsa.debian.org/rust-team/debcargo/-/issues/34
https://crates.io/crates/rustup-private-download

Bug#1023684: odb build depends on gcc-10 that should not be in bookworm

[Adrian Bunk]

Control: tags -1 patch

On Tue, Nov 08, 2022 at 08:50:12PM +0200, Adrian Bunk wrote:
> Source: odb
> Version: 2.4.0-15
> Severity: serious
> Control: block 1023666 by -1
> 
> Please switch to gcc-12 that is default in bookworm.

The following commits make odb build with gcc-12:
https://git.codesynthesis.com/cgit/odb/odb/commit/?id=61d80f051293a7449a09081f60f48b8377bfbbad
https://git.codesynthesis.com/cgit/odb/odb/commit/?id=47035c0f72efd99a2210cd45db6e42423fb74533

cu
Adrian

Bug#1025706: squashfuse: link against fuse3

[Scott Moser]

Package: squashfuse
Version: 0.1.103-3
Severity: normal

Dear Maintainer,

squashfuse should be built against libfuse3 rather than libfuse2.
The current/supported version of libfuse is 3 and squashfuse supports
linking and running with libfuse3.

There are some existing issues that are fixed by using libfuse3 [1] and
it is surely a better upstream support path.

[1] https://github.com/vasi/squashfuse/issues/80


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

Kernel: Linux 5.15.0-53-generic (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_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 squashfuse depends on:
ii  libc6   2.35-0ubuntu3.1
ii  libfuse22.9.9-5ubuntu3.1
ii  libsquashfuse0  0.1.103-3

squashfuse recommends no packages.

squashfuse suggests no packages.

-- no debconf information

Bug#1021651: fixed in evolution-ews 3.38.3-1+deb11u1

[Adam D. Barratt]

Control: reopen -1
Control: tags -1 + pending

On Wed, 2022-12-07 at 19:02 +, Debian FTP Masters wrote:
> Source: evolution-ews
> Source-Version: 3.38.3-1+deb11u1
> Done: Claudius Heine 
> 
> We believe that the bug you reported is fixed in the latest version
> of
> evolution-ews, which is due to be installed in the Debian FTP
> archive.

*Do* *not* close release.debian.org bugs in uploads.

This p-u bug tracking the upload stays open until the the update is in
stable (i.e. after a point release), at which point we (the Release
Team) will close it.

Regards,

Adam

Bug#1025705: util-linux: internal error

[Francesco Potortì]

Package: util-linux
Version: 2.38.1-4
Severity: normal
X-Debbugs-Cc: none, Francesco Potortì 
File: /sbin/fsck

Dear Maintainer,

# fsck -fy /backup/
fsck from util-linux 2.38.1
e2fsck 1.46.6-rc1 (12-Sep-2022)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Invalid inode number for '.' in directory inode 8520768.
Fix? yes

Entry '.' in <8520768> (8520768) has an incorrect filetype (was 2, should be 1).
Fix? yes

Internal error: couldn't find dir_info for 8520768.
e2fsck: aborted

Unfortunately, I am not able to dig deeper, and I'll try to solve the problem 
as soon as possible by running fsck again...

-- 
Francesco Potortì (ricercatore)Mobile: +39.348.8283.107  
ISTI - Area della ricerca CNR  Skype:  wnlabisti 
via G. Moruzzi 1, I-56124 Pisa Web:http://fly.isti.cnr.it
(gate 20, 1st floor, room C71) ISPIN:  https://ieee-jispin.org/


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

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

Versions of packages util-linux depends on:
ii  libblkid1 2.38.1-4
ii  libc6 2.36-6
ii  libcap-ng00.8.3-1+b2
ii  libcrypt1 1:4.4.33-1
ii  libmount1 2.38.1-4
ii  libpam0g  1.5.2-5
ii  libselinux1   3.4-1+b3
ii  libsmartcols1 2.38.1-4
ii  libsystemd0   252.2-1
ii  libtinfo6 6.3+20220423-2
ii  libudev1  252.2-1
ii  libuuid1  2.38.1-4
ii  util-linux-extra  2.38.1-4
ii  zlib1g1:1.2.11.dfsg-4.1

Versions of packages util-linux recommends:
ii  sensible-utils  0.0.17

Versions of packages util-linux suggests:
ii  dosfstools  4.2-1
ii  kbd 2.5.1-1
pn  util-linux-locales  

-- debconf information:
  util-linux/noauto-with-nonzero-passnum:

Bug#1024054: mariadb-10.5 10.5.18-0+deb11u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1024054 = 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: mariadb-10.5
Version: 10.5.18-0+deb11u1

Explanation: new upstream stable release; security fixes [CVE-2018-25032 
CVE-2021-46669 CVE-2022-27376 CVE-2022-27377 CVE-2022-27378 CVE-2022-27379 
CVE-2022-27380 CVE-2022-27381 CVE-2022-27382 CVE-2022-27383 CVE-2022-27384 
CVE-2022-27386 CVE-2022-27387 CVE-2022-27444 CVE-2022-27445 CVE-2022-27446 
CVE-2022-27447 CVE-2022-27448 CVE-2022-27449 CVE-2022-27451 CVE-2022-27452 
CVE-2022-27455 CVE-2022-27456 CVE-2022-27457 CVE-2022-27458 CVE-2022-32081 
CVE-2022-32082 CVE-2022-32083 CVE-2022-32084 CVE-2022-32085 CVE-2022-32086 
CVE-2022-32087 CVE-2022-32088 CVE-2022-32089 CVE-2022-32091]

Bug#1025173: libdatetime-timezone-perl 2.47-1+2022g flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1025173 = 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: libdatetime-timezone-perl
Version: 2.47-1+2022g

Explanation: update included data

Bug#1025646: libapache2-mod-auth-mellon 0.17.0-1+deb11u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1025646 = 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: libapache2-mod-auth-mellon
Version: 0.17.0-1+deb11u1

Explanation: fix open redirect issue [CVE-2021-3639]

Bug#1025553: core-async-clojure 1.3.610-5+deb11u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1025553 = 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: core-async-clojure
Version: 1.3.610-5+deb11u1

Explanation: fix build failures in test suite

Bug#1025204: speech-dispatcher 0.10.2-2+deb11u2 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1025204 = 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: speech-dispatcher
Version: 0.10.2-2+deb11u2

Explanation: reduce espeak buffer size to avoid synth artifacts

Bug#1021651: evolution-ews 3.38.3-1+deb11u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1021651 = 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: evolution-ews
Version: 3.38.3-1+deb11u1

Explanation: fix retrieval of user certificates of contacts

Bug#1023981: onionshare 2.2-3+deb11u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1023981 = 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: onionshare
Version: 2.2-3+deb11u1

Explanation: fix denial of service issue [CVE-2022-21689], HTML injection issue 
[CVE-2022-21690]

Bug#1025704: neomutt: Segfault when resuming postponed message from cmdline

[Uwe Kleine-König]

Package: neomutt
Version: 20220429+dfsg1-4
Severity: normal
Tags: patch upstream fixed-upstream
X-Debbugs-Cc: uklei...@debian.org
Control: forwarded -1 https://github.com/neomutt/neomutt/issues/3268

Hello,

under some condition, calling

neomutt -p

segfaults.

See the upstream bug report for some more details. It's fixed upstream
in:


https://github.com/neomutt/neomutt/commit/d03cc941019fc030ac99ce3826e8a1648dc4c779

Best regards
Uwe

-- Package-specific info:
NeoMutt 20220429
Copyright (C) 1996-2022 Michael R. Elkins and others.
NeoMutt comes with ABSOLUTELY NO WARRANTY; for details type 'neomutt -vv'.
NeoMutt is free software, and you are welcome to redistribute it
under certain conditions; type 'neomutt -vv' for details.

System: Linux 6.0.0-4-amd64 (x86_64)
ncurses: ncurses 6.3.20220423 (compiled with 6.3.20220423)
libidn: 1.41 (compiled with 1.41)
GPGME: 1.18.0
GnuTLS: 3.7.8
libnotmuch: 5.6.0
storage: tokyocabinet

Configure options: --build=x86_64-linux-gnu --prefix=/usr 
{--includedir=${prefix}/include} {--mandir=${prefix}/share/man} 
{--infodir=${prefix}/share/info} --sysconfdir=/etc --localstatedir=/var 
--disable-option-checking --disable-silent-rules 
{--libdir=${prefix}/lib/x86_64-linux-gnu} --runstatedir=/run 
--disable-maintainer-mode --disable-dependency-tracking --mandir=/usr/share/man 
--libexecdir=/usr/libexec --with-mailpath=/var/mail --gpgme --lua --notmuch 
--with-ui --gsasl --gnutls --gss --idn --mixmaster --tokyocabinet --sqlite 
--autocrypt --pkgconf

Compilation CFLAGS: -g -O2 
-ffile-prefix-map=/build/neomutt-F8xOKh/neomutt-20220429+dfsg1=. 
-fstack-protector-strong -Wformat -Werror=format-security -std=c99 
-D_ALL_SOURCE=1 -D_GNU_SOURCE=1 -D__EXTENSIONS__ -I/usr/include/lua5.4 
-I/usr/include -DNCURSES_WIDECHAR -I/usr/include/p11-kit-1 -isystem 
/usr/include/mit-krb5

Default options:
  +attach_headers_color +compose_to_sender +compress +cond_date +debug 
  +encrypt_to_self +forgotten_attachments +forwref +ifdef +imap +index_color 
  +initials +limit_current_thread +multiple_fcc +nested_if +new_mail +nntp +pop 
  +progress +quasi_delete +regcomp +reply_with_xorig +sensible_browser +sidebar 
  +skip_quoted +smtp +status_color +timeout +tls_sni +trash 

Compile options:
  +autocrypt +fcntl -flock -fmemopen +futimens +getaddrinfo +gnutls +gpgme 
  +gsasl +gss +hcache -homespool +idn +inotify -locales_hack +lua +mixmaster 
  +nls +notmuch -openssl +pgp +regex -sasl +smime +sqlite +sun_attachment 

MAILPATH="/var/mail"
MIXMASTER="mixmaster"
PKGDATADIR="/usr/share/neomutt"
SENDMAIL="/usr/sbin/sendmail"
SYSCONFDIR="/etc"

To learn more about NeoMutt, visit: https://neomutt.org
If you find a bug in NeoMutt, please raise an issue at:
https://github.com/neomutt/neomutt/issues
or send an email to: 

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

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

Versions of packages neomutt depends on:
ii  libc6 2.36-5
ii  libgnutls30   3.7.8-4
ii  libgpg-error0 1.46-1
ii  libgpgme111.18.0-1
ii  libgsasl182.2.0-1
ii  libgssapi-krb5-2  1.20.1-1
ii  libidn12  1.41-1
ii  liblua5.4-0   5.4.4-3
ii  libncursesw6  6.3+20220423-2
ii  libnotmuch5   0.37-1
ii  libsqlite3-0  3.40.0-1
ii  libtinfo6 6.3+20220423-2
ii  libtokyocabinet9  1.4.48-15
ii  sensible-utils0.0.17

Versions of packages neomutt recommends:
ii  locales  2.36-5
ii  mailcap  3.70+nmu1

Versions of packages neomutt suggests:
ii  aspell 0.60.8-4+b1
ii  ca-certificates20211016
ii  exim4-daemon-light [mail-transport-agent]  4.96-9
ii  gnupg  2.2.40-1
ii  ispell 3.4.05-1
pn  mixmaster  
ii  openssl3.0.7-1
pn  urlview

Versions of packages neomutt is related to:
ii  neomutt  20220429+dfsg1-4

-- no debconf information

Bug#1012333: u-boot-menu: add support for using config fragments

[Vagrant Cascadian]

On 2022-11-01, Arnaud Ferraris wrote:
> Le 23/09/2022 à 19:22, Vagrant Cascadian a écrit :
>> On 2022-09-23, Arnaud Ferraris wrote:
>>> On Sat, 10 Sep 2022 10:18:39 -0700 Vagrant Cascadian
>>>  wrote:
 On 2022-06-04, Jonas Smedegaard wrote:
> Quoting Arnaud Ferraris (2022-06-04 16:39:03)
>> Currently u-boot-menu makes use of a single configuration file
>> one has to edit in order to change the default options. It could
>> be useful to use config fragments containing only one (or more)
>> variables, so that different packages could change different
>> config options (for example, one fragment could modify the
>> default cmdline, while another one could change the DTB folder).
>
> Thanks, that sounds like a useful feature indeed.
>
> Seems more sensible for me, however, to implement this using debconf.
>
> Otherwise, installation and removal of a package would need to trigger
> u-boot-menu, and u-boot-menu would need to specially examine such
> cofigfile snippets to skip snippets belonging to removed but not purged
> packages.

 Well, you could implement configuration files snippets directory outside
 of /etc (e.g. /usr/share/u-boot-menu/snippet.d or something like that),
 which would avoid this problem. u-boot-menu could have a dpkg trigger
 that for when files in this directory change.
>>>
>>> I quite like this approach, thanks for the suggestion!
>>>
>>> Do you think allowing both /etc/u-boot-menu.d (aimed solely at
>>> end-users) and /usr/share/u-boot-menu/conf.d (for other packages and/or
>>> derivatives), with a dpkg trigger only on the latter, would make sense?
>>> Or should we aim only for the /usr/share... approach?
>> 
>> I think it's reasonable, though you'd have to encourage packages to
>> *not* use /etc/u-boot-menu*.d, maybe documenting it in
>> README.Debian...
>
> I added some notes about this in both the manpage and a (new) README.Debian
>
>> 
>> I could see a preference order being /etc/default/u-boot which is
>> overidden by /usr/share/u-boot-menu/conf.d which is overridden by
>> /etc/u-boot-menu.d (or /etc/u-boot-menu/conf.d ?).
>
> Yes, that makes the most sense to me (I also used 
> /etc/u-boot-menu/conf.d instead of /etc/u-boot-menu.d for consistency).
>
>> 
>> A fancy implementation might allow /etc to override /usr/share if the
>> filenames match, but that might be more complicated than it's
>> worth. Jonas knows I've fallen into that rabbit hole in packages of the
>> ancient past... :)
>
> Hmm, I don't think that's worth the hassle as it would add *a lot* of 
> complexity for very little gain IMHO.
>
>> 
>> 
 That seems a lot simpler than introducing the complexity of debconf
 generated configuration files...
>>>
>>> Indeed, so far my experiments with debconf for solving this matter have
>>> been sub-optimal at best.
>>>
>>> I'll update my patch in the next few days and submit it asap.
>
> Updated patch attached, as always comments and suggestions are welcome :)

Looks good to me! Even uses dpkg-triggers properly. :)

Thanks!

I'll merge this and take a look at anything else that needs
poking at and maybe upload soon...

live well,
  vagrant


> From 2949907b16bff2857cff0fb713967d264feb6567 Mon Sep 17 00:00:00 2001
> From: Arnaud Ferraris 
> Date: Tue, 1 Nov 2022 13:33:22 +0100
> Subject: [PATCH] u-boot-update: allow using config fragments
>
> In order to allow other packages and/or derivative distros to configure
> specific aspects of `u-boot-menu` it can be useful to allow using config
> fragments. This patch therefore implements loading config files from
> `/usr/share/u-boot-menu/conf.d` (to be used by other packages) and
> `/etc/u-boot-menu.d` (to be used by end-users, taking priority over
> files under the preceding location), overriding the values loaded from
> the default configuration file.
>
> This commit also adds a dpkg trigger so any modification of files under
> `/usr/share/u-boot-menu/conf.d` will result in `u-boot-update` being
> automatically run.
> ---
>  debian/README.Debian| 32 
>  debian/u-boot-menu.postinst |  8 
>  debian/u-boot-menu.triggers |  1 +
>  u-boot-update   |  9 +
>  u-boot-update.8 | 16 +++-
>  5 files changed, 65 insertions(+), 1 deletion(-)
>  create mode 100644 debian/README.Debian
>  create mode 100755 debian/u-boot-menu.postinst
>  create mode 100644 debian/u-boot-menu.triggers
>
> diff --git a/debian/README.Debian b/debian/README.Debian
> new file mode 100644
> index 000..f502387
> --- /dev/null
> +++ b/debian/README.Debian
> @@ -0,0 +1,32 @@
> +Configuration files handling
> +
> +
> +Configuration files are read from the following locations, ordered by 
> priority:
> +1. /etc/default/u-boot
> +2. /usr/share/u-boot-menu/conf.d/*.conf
> +3. /etc/u-boot-menu/conf.d/*.conf
> +
> +Each configuration file can contain one or more 

Bug#1025703: bullseye-pu: package libexplain/1.4.D001-11+deb11u1

[Santiago Vila]

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

Dear Release Managers:

I'd like to make this QA upload to fix FTBFS bug #997222 in bullseye, 
plus allow compilation with kernels slightly newer than the one in 
bullseye (for example bullseye-backports).


The two patches are taken verbatim from bookworm/sid, where this was 
fixed one year ago.


debdiff attached

Thanks.diff -Nru libexplain-1.4.D001/debian/changelog 
libexplain-1.4.D001/debian/changelog
--- libexplain-1.4.D001/debian/changelog2021-06-09 22:23:28.0 
+0200
+++ libexplain-1.4.D001/debian/changelog2022-12-07 19:10:00.0 
+0100
@@ -1,3 +1,12 @@
+libexplain (1.4.D001-11+deb11u1) bullseye; urgency=medium
+
+  * QA upload.
+  * Apply two patches from bookworm to build with newer kernels:
+  - Patch: Linux 5.11 no longer has if_frad.h, from Ubuntu. Closes: #997222
+  - Patch: termiox removed since kernel 5.12, from ALT Linux.
+
+ -- Santiago Vila   Wed, 07 Dec 2022 19:10:00 +0100
+
 libexplain (1.4.D001-11) unstable; urgency=medium
 
   * QA upload.
diff -Nru libexplain-1.4.D001/debian/patches/linux5.11.patch 
libexplain-1.4.D001/debian/patches/linux5.11.patch
--- libexplain-1.4.D001/debian/patches/linux5.11.patch  1970-01-01 
01:00:00.0 +0100
+++ libexplain-1.4.D001/debian/patches/linux5.11.patch  2022-12-06 
01:00:47.0 +0100
@@ -0,0 +1,33 @@
+From: Graham Inggs 
+Date: Tue, 16 Nov 2021 20:09:45 +0100
+Subject: Linux 5.11 no longer has if_frad.h
+
+Bug-Debian: https://bugs.debian.org/997222
+Last-Update: 2021-06-20
+---
+ libexplain/iocontrol/siocadddlci.c | 2 +-
+ libexplain/iocontrol/siocdeldlci.c | 2 +-
+ 2 files changed, 2 insertions(+), 2 deletions(-)
+
+--- a/libexplain/iocontrol/siocadddlci.c
 b/libexplain/iocontrol/siocadddlci.c
+@@ -25,7 +25,7 @@
+ #include 
+ 
+ 
+-#ifdef SIOCADDDLCI
++#if defined(SIOCADDDLCI) && defined(HAVE_LINUX_IF_FRAD_H)
+ 
+ static void
+ print_data(const explain_iocontrol_t *p, explain_string_buffer_t *sb,
+--- a/libexplain/iocontrol/siocdeldlci.c
 b/libexplain/iocontrol/siocdeldlci.c
+@@ -26,7 +26,7 @@
+ #include 
+ 
+ 
+-#ifdef SIOCDELDLCI
++#if defined(SIOCDELDLCI) && defined(HAVE_LINUX_IF_FRAD_H)
+ 
+ static void
+ print_data(const explain_iocontrol_t *p, explain_string_buffer_t *sb,
diff -Nru libexplain-1.4.D001/debian/patches/series 
libexplain-1.4.D001/debian/patches/series
--- libexplain-1.4.D001/debian/patches/series   2021-06-09 22:03:05.0 
+0200
+++ libexplain-1.4.D001/debian/patches/series   2022-12-06 01:00:52.0 
+0100
@@ -11,3 +11,5 @@
 sanitize-bison.patch
 gcc-10.patch
 typos.patch
+linux5.11.patch
+termiox-no-more-exists-since-kernel-5.12.patch
diff -Nru 
libexplain-1.4.D001/debian/patches/termiox-no-more-exists-since-kernel-5.12.patch
 
libexplain-1.4.D001/debian/patches/termiox-no-more-exists-since-kernel-5.12.patch
--- 
libexplain-1.4.D001/debian/patches/termiox-no-more-exists-since-kernel-5.12.patch
   1970-01-01 01:00:00.0 +0100
+++ 
libexplain-1.4.D001/debian/patches/termiox-no-more-exists-since-kernel-5.12.patch
   2022-12-06 01:00:52.0 +0100
@@ -0,0 +1,26 @@
+From: Håvard Flaget Aasen 
+Date: Tue, 16 Nov 2021 20:12:31 +0100
+Subject: termiox no more exists since kernel 5.12
+
+https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v5.12=c762a2b846b619c0f92f23e2e8e16f70d20df800
+
+Origin: 
https://packages.altlinux.org/en/sisyphus/srpms/libexplain/patches/libexplain-1.4-remove-termiox.patch
+---
+ libexplain/buffer/termiox.h | 6 +-
+ 1 file changed, 5 insertions(+), 1 deletion(-)
+
+--- a/libexplain/buffer/termiox.h
 b/libexplain/buffer/termiox.h
+@@ -21,7 +21,11 @@
+ 
+ #include 
+ 
+-struct termiox; /* forward */
++/* make termiox empty
++   no more defined in Linux kernel since 5.12:
++   
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v5.12=c762a2b846b619c0f92f23e2e8e16f70d20df800
++ */
++struct termiox {};
+ 
+ /**
+   * The explain_buffer_termiox function may be used

Bug#1025702: gimp: Failed dum text editing

[cxtbs]

Package: gimp
Version: 2.10.22-4
Severity: normal
X-Debbugs-Cc: chtabs2...@gmail.com

Dear Maintainer,

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

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

Versions of packages gimp depends on:
ii  gimp-data2.10.22-4
ii  graphviz 2.42.2-5
ii  libaa1   1.4p5-48
ii  libbabl-0.1-01:0.1.82-1
ii  libbz2-1.0   1.0.8-4
ii  libc62.31-13+deb11u5
ii  libcairo21.16.0-5
ii  libfontconfig1   2.13.1-4.2
ii  libfreetype6 2.10.4+dfsg-1+deb11u1
ii  libgcc-s110.2.1-6
ii  libgdk-pixbuf-2.0-0  2.42.2+dfsg-1+deb11u1
ii  libgegl-0.4-01:0.4.26-2
ii  libgexiv2-2  0.12.1-1
ii  libgimp2.0   2.10.22-4
ii  libglib2.0-0 2.66.8-1
ii  libgs9   9.53.3~dfsg-7+deb11u2
ii  libgtk2.0-0  2.24.33-2
ii  libgudev-1.0-0   234-1
ii  libharfbuzz0b2.7.4-1
ii  libheif1 1.11.0-1
ii  libilmbase25 2.5.4-1
ii  libjpeg62-turbo  1:2.0.6-4
ii  libjson-glib-1.0-0   1.6.2-1
ii  liblcms2-2   2.12~rc1-2
ii  liblzma5 5.2.5-2.1~deb11u1
ii  libmng1  1.0.10+dfsg-3.1+b5
ii  libmypaint-1.5-1 1.6.0-2
ii  libopenexr25 2.5.4-2
ii  libopenjp2-7 2.4.0-3
ii  libpango-1.0-0   1.46.2-3
ii  libpangocairo-1.0-0  1.46.2-3
ii  libpangoft2-1.0-01.46.2-3
ii  libpng16-16  1.6.37-3
ii  libpoppler-glib8 20.09.0-3.1+deb11u1
ii  librsvg2-2   2.50.3+dfsg-1
ii  libstdc++6   10.2.1-6
ii  libtiff5 4.2.0-1+deb11u1
ii  libwebp6 0.6.1-2.1
ii  libwebpdemux20.6.1-2.1
ii  libwebpmux3  0.6.1-2.1
ii  libwmf0.2-7  0.2.8.4-17
ii  libx11-6 2:1.7.2-1
ii  libxcursor1  1:1.2.0-2
ii  libxext6 2:1.3.3-1.1
ii  libxfixes3   1:5.0.3-2
ii  libxmu6  2:1.1.2-2+b3
ii  libxpm4  1:3.5.12-1
ii  xdg-utils1.1.3-4.1
ii  zlib1g   1:1.2.11.dfsg-2+deb11u2

Versions of packages gimp recommends:
ii  ghostscript  9.53.3~dfsg-7+deb11u2

Versions of packages gimp suggests:
ii  gimp-data-extras  1:2.0.2-1.1
pn  gimp-help-en | gimp-help  
ii  gvfs-backends 1.46.2-1
ii  libasound21.2.4-1.1

```
GNU Image Manipulation Program version 2.10.22
git-describe: GIMP_2_10_20-217-g0c8a7891f7
Build: unknown rev 0 for linux
# C compiler #
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/10/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa:hsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian
10.2.1-6' --with-bugurl=file:///usr/share/doc/gcc-10/README.Bugs --enable-
languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,m2 --prefix=/usr --with-gcc-
major-version-only --program-suffix=-10 --program-prefix=x86_64-linux-gnu-
--enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-
included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls
--enable-bootstrap --enable-clocale=gnu --enable-libstdcxx-debug --enable-
libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib
--enable-libphobos-checking=release --with-target-system-zlib=auto --enable-
objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i686 --with-
abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-
none=/build/gcc-10-Km9U7s/gcc-10-10.2.1/debian/tmp-nvptx/usr,amdgcn-
amdhsa=/build/gcc-10-Km9U7s/gcc-10-10.2.1/debian/tmp-gcn/usr,hsa --without-
cuda-driver --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu --with-build-
config=bootstrap-lto-lean --enable-link-mutex
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 10.2.1 20210110 (Debian 10.2.1-6)

# Libraries #
using babl version 0.1.82 (compiled against version 0.1.86)
using GEGL version 0.4.26 (compiled against version 0.4.28)
using GLib version 2.66.8 (compiled against version 2.66.8)
using GdkPixbuf version 2.42.2 (compiled against version 2.42.2)
using GTK+ version 2.24.33 (compiled against version 2.24.33)
using Pango version 1.46.2 (compiled against version 1.46.2)
using Fontconfig version 2.13.1 (compiled against version 2.13.1)
using Cairo version 1.16.0 (compiled against version 1.16.0)

```
> fatal error: Ошибка сегментирования

Bug#1019254: kexec-tools: FTBFS on riscv64

[Khalid Aziz]

On 9/6/22 05:24, Eric Long wrote:

Source: kexec-tools
Version: 1:2.0.24-1
Severity: serious
Tags: ftbfs patch
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: i...@hack3r.moe

Dear maintainer,

I am currently porting packages to riscv64 platform. kexec-tools failed to
build on riscv64 as shown in logs below:

```
configure:3425: checking build system type
configure:3440: result: riscv64-unknown-linux-gnu
configure:3460: checking host system type
configure:3474: result: riscv64-unknown-linux-gnu
configure:3494: checking target system type
configure:3508: result: riscv64-unknown-linux-gnu
configure:3576: error: unsupported architecture riscv64
```

Full buildd log: 
https://buildd.debian.org/status/fetch.php?pkg=kexec-tools=riscv64=1%3A2.0.24-1=1649802148=0

There is a patch from openSUSE [1] that fixes build on riscv64. Tested on my
QEMU riscv64 sbuild and it works fine. Can you please apply this to Debian
package as well?

Please let me know if I missed anything.

Best regards,
Eric


I am updating kexec-tools package to 2.0.25. I am going to hold off on 
pulling riscv64 support in. That is a fairly substantial patch. I would 
like to give it some soak time in upstream before pulling it into debian 
package.


Thanks,
Khalid