Bug#1026056: swi-prolog breaks logol autopkgtest: Program exited with wrong status code

[olivier sallou]

Tests need to be run as root, or use a specific config file and use non
root writable directories.

Will try to change tests to do so.

Regarding issue itself,  programs compiled by swi prolog usually require
recompilation on swi prolog updates.

Will try to rebuild and check

Le mar. 13 déc. 2022, 22:03, Paul Gevers  a écrit :

> Source: swi-prolog, logol
> Control: found -1 swi-prolog/9.0.2+dfsg-1
> Control: found -1 logol/1.7.9+dfsg-5
> Severity: serious
> Tags: sid bookworm
> User: debian...@lists.debian.org
> Usertags: breaks needs-update
>
> Dear maintainer(s),
>
> With a recent upload of swi-prolog the autopkgtest of logol fails in
> testing when that autopkgtest is run with the binary packages of
> swi-prolog from unstable. It passes when run with only packages from
> testing. In tabular form:
>
> passfail
> swi-prolog from testing9.0.2+dfsg-1
> logol  from testing1.7.9+dfsg-5
> all others from testingfrom testing
>
> I copied some of the output at the bottom of this report. The issue
> *looks* similar to bug 1022253, but now on all architectures.
>
> Currently this regression is blocking the migration of swi-prolog to
> testing [1]. Due to the nature of this issue, I filed this bug report
> against both packages. Can you please investigate the situation and
> reassign the bug to the right package?
>
> More information about this bug and the reason for filing it can be found
> on
> https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation
>
> Paul
>
> [1] https://qa.debian.org/excuses.php?package=swi-prolog
>
>
> https://ci.debian.net/data/autopkgtest/testing/amd64/l/logol/29303003/log.gz
>
> calling logol with parameters -g 1799.logol -s 1799.fasta -dna
> log4j:ERROR setFile(null,true) call failed.
> java.io.FileNotFoundException: /var/log/logol/logol.log (Permission denied)
> at java.base/java.io.FileOutputStream.open0(Native Method)
> at java.base/java.io
> .FileOutputStream.open(FileOutputStream.java:293)
> at java.base/java.io
> .FileOutputStream.(FileOutputStream.java:235)
> at java.base/java.io
> .FileOutputStream.(FileOutputStream.java:155)
> at org.apache.log4j.FileAppender.setFile(FileAppender.java:294)
> at
> org.apache.log4j.FileAppender.activateOptions(FileAppender.java:165)
> at
> org.apache.log4j.config.PropertySetter.activate(PropertySetter.java:307)
> at
>
> org.apache.log4j.config.PropertySetter.setProperties(PropertySetter.java:172)
> at
>
> org.apache.log4j.config.PropertySetter.setProperties(PropertySetter.java:104)
> at
>
> org.apache.log4j.PropertyConfigurator.parseAppender(PropertyConfigurator.java:842)
> at
>
> org.apache.log4j.PropertyConfigurator.parseCategory(PropertyConfigurator.java:768)
> at
>
> org.apache.log4j.PropertyConfigurator.parseCatsAndRenderers(PropertyConfigurator.java:672)
> at
>
> org.apache.log4j.PropertyConfigurator.doConfigure(PropertyConfigurator.java:516)
> at
>
> org.apache.log4j.PropertyConfigurator.doConfigure(PropertyConfigurator.java:580)
> at
>
> org.apache.log4j.helpers.OptionConverter.selectAndConfigure(OptionConverter.java:526)
> at org.apache.log4j.LogManager.(LogManager.java:127)
> at org.apache.log4j.Logger.getLogger(Logger.java:117)
> at org.irisa.genouest.logol.Logol.(Unknown Source)
> For help, use option -h
> INFO org.irisa.genouest.logol.Logol  - Using configuration file:
> /usr/share/logol/prolog/logol.properties
> INFO org.irisa.genouest.logol.Logol  - option g called with 1799.logol
> INFO org.irisa.genouest.logol.Logol  - option s called with 1799.fasta
> INFO org.irisa.genouest.logol.Logol  - No maximum solutions defined,
> using defaults
> INFO org.irisa.genouest.logol.Logol  - option dna called
> INFO org.irisa.genouest.logol.Logol  - Start analyse to create grammar
> analyser
> Executing prolog for pre-analyse
> java.io.FileNotFoundException:
> /tmp/1799.logol.38da5a9d-c2ac-4a7d-8eb3-8c05b42f5c04.pre.res (No such
> file or directory)
> at java.base/java.io.FileInputStream.open0(Native Method)
> at java.base/java.io
> .FileInputStream.open(FileInputStream.java:216)
> at java.base/java.io
> .FileInputStream.(FileInputStream.java:157)
> at java.base/java.io.FileReader.(FileReader.java:75)
> at org.irisa.genouest.logol.Logol.loadVariables2Postpone(Unknown
> Source)
> at org.irisa.genouest.logol.Logol.generatePreAnalysis(Unknown
> Source)
> at org.irisa.genouest.logol.Logol.analyse(Unknown Source)
> at org.irisa.genouest.logol.Logol.execute(Unknown Source)
> at org.irisa.genouest.logol.Logol.main(Unknown Source)
> INFO org.irisa.genouest.logol.Logol  - Analyse in progress..
> WARN org.irisa.genouest.logol.SequenceAnalyser  - Path to suffix search
> tool is not set in system environment. Will try to execute directly bu

Bug#1025220: passenger: Passenger startup fails with nodejs applications using node versions later than 14.x

[Cool Fire]

Hi,

On Tue, 13 Dec 2022 20:23:11 -0300 Antonio Terceiro 
 wrote:

> These binaries have the attached patch applied, please try them (I'm
> assuming you are on amd64) and let me know.
>
> https://people.debian.org/~terceiro/tmp/passenger-bullseye/

Thank you for building the new packages. I've tested them with the 
debian nodejs package and the nodesource 14.x, 16.x, 18.x and 19.x 
repos, they all run the example nodejs application without any issues now.

Bug#1025274: RFS: tuxguitar/1.5.6+dfsg1-1 [QA] -- Multitrack guitar tablature editor and player

[Helmar Gerloni]

> ... wasn't the whole idea of Java to be arch independent?
That's true, but Tuxguitar comes with some audio modules written in C/C++ (see 
build-scripts/native-modules/).
I was able to cross compile them with aarch64-linux-gnu-gcc etc. on amd64. 
Next I will try to cross-build the whole package with sbuild (thanks for the 
links, Lourisvaldo).

> The package is marked as UNRELEASED in the changelog, thus explicitly not
> for upload.  I'll leave further review to someone with a clue about Java
> and Maven...
The main reason for marking the package as UNRELEASED is the unclear license 
of the included "Magic Sound Font v2.0"; see the discussion in #819332.
I have tried to contact the author by mail, but have not yet received a reply. 
I will try again, but if it is not possible to resolve this issue, we could 
omit the file. Tuxguitar also works with other soundbanks already included in 
Debian.

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

[наб]

Control: tags -1 + upstream fixed-upstream

The patch referenced above has landed as
  
https://git.kernel.org/pub/scm/utils/dash/dash.git/commit/?id=f0d57fded5b1a4b0aa6f0571a316cb9482ef3af8
which was subsequently tagged as v0.5.12.

I can independently confirm that upstream dash 0.5.12
doesn't suffer from this bug.

наб


signature.asc
Description: PGP signature

Bug#1026067: zutils: conffiles not removed: /etc/zutilsrc

[Paul Wise]

Package: zutils
Version: 1.12~rc1-1
Severity: normal
User: debian...@lists.debian.org
Usertags: obsolete-conffile adequate

The recent upgrade did not deal with obsolete conffiles properly.
Please use the dpkg-maintscript-helper support provided by
dh_installdeb to remove these obsolete conffiles on upgrade.

https://www.debian.org/doc/debian-policy/ch-files.html#s-config-files
https://manpages.debian.org/man/1/dh_installdeb

   $ p=zutils ; adequate $p ; dpkg-query -W -f='${Conffiles}\n' $p | grep 
obsolete
   
   zutils: obsolete-conffile /etc/zutilsrc
    /etc/zutilsrc 41acb0ec2ef62ab379ebdd90f99e8733 obsolete

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

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

Versions of packages zutils depends on:
ii  libc6   2.36-6
ii  libgcc-s1   12.2.0-9
ii  libstdc++6  12.2.0-9

Versions of packages zutils recommends:
ii  bzip2 1.0.8-5+b1
ii  lzip  1.23-4
ii  xz-utils  5.2.9-0.0
ii  zstd  1.5.2+dfsg-1

zutils suggests no packages.

-- no debconf information

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#1026066: rust-rav1e: depends on old rust-dav1d-sys 0.5

[Steve Langasek]

Package: librust-rav1e-dev
Version: 0.5.1-5
Severity: serious
Tags: sid
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu lunar

Hi Sebastian,

The librust-rav1e-dev package is uninstallable in unstable, because it
depends on (among others) librust-dav1d-sys-dev 0.5, but unstable now has
0.7:

 librust-rav1e-dev : Depends: librust-av-metrics-0.8-dev (>= 0.8.1-~~) but it 
is not installable
 Depends: librust-dav1d-sys-0.5+default-dev but it is not 
installable
 Depends: librust-v-frame-0.2+default-dev (>= 0.2.5-~~) but 
it is not installable
 Depends: librust-v-frame-0.2+serialize-dev (>= 0.2.5-~~) 
but it is not installable


-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Bug#1025274: RFS: tuxguitar/1.5.6+dfsg1-1 [QA] -- Multitrack guitar tablature editor and player

[Adam Borowski]

On Fri, Dec 09, 2022 at 02:10:32PM +0100, Helmar Gerloni wrote:
> Tuxguitar 1.5 is now built with Maven and comes with build scripts for Linux 
> on amd64 (x86_64), i386 (x86) and armv7hl. The differences between the build 
> scripts for amd64 and i386 are minor, and for many other architectures 
> supported by Debian there are no build scripts at all.

> So my idea was to use the upstream build scripts for amd64 for all 
> architectures and modify/patch them so that they hopefully work on all 
> architectures supported by Debian.

... wasn't the whole idea of Java to be arch independent?

> This is the reason why i removed all non-amd64 build scripts from the Debian 
> sources (among other things).
> But maybe this is not the right way, i don't know. Right now i only have 
> amd64 
> hardware available, so i can't build on other architectures (cross-compile 
> maybe, but that doesn't sound trivial).

While I do have a bunch of hardware to test, and qemu for the rest, I'm
afraid Maven issues are completely out of my expertise areas.  Thus, it
seems that someone else will need to help here.

> > Sounds like you missed a build dependency...
> I thought ${maven:CompileDepends} in debian/control handles this build 
> dependencies, but somehow it did not work.
> I added some more dependencies to the Build-Depends, so hopefully they are 
> complete now.

It builds on amd64 for me, yay!

The package is marked as UNRELEASED in the changelog, thus explicitly not
for upload.  I'll leave further review to someone with a clue about Java
and Maven...


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ Quis trollabit ipsos trollos?
⠈⠳⣄

Bug#819829: dash: "hash: Illegal option -v"

[наб]

Control: tags -1 + upstream
Control: forwarded -1 
https://lore.kernel.org/dash/20221214025113.c6lxog5v3wp4v...@tarta.nabijaczleweli.xyz/t/

The odd behaviour is due to the hash built-in doing the -r action and
then exiting as soon as it encountered the -r flag: "hash -r$anything",
for /any/ value of anything, is equivalent to "hash -r".

I've posted a patch to dash@, archived at forwarded-to,
which also removes the -v documentation
(it doesn't appear to have ever existed, at least insofar as git reaches).

наб


signature.asc
Description: PGP signature

Bug#1025736: nodejs: Always segfaults on riscv64

[Bo YU]

Source: nodejs
Version: 18.12.1+dfsg-2+0.riscv64.1
Followup-For: Bug #1025736

Hi David,

I can run nodejs(18.12.1+dfsg-2) on real riscv64 hardware:

```
vimer@unmatched10:~/build/01_nodejs$ nodejs --help
Usage: node [options] [ script.js ] [arguments]
   node inspect [options] [ script.js | host:port ] [arguments]

Options:
  -script read from stdin (default if 
no file name is
   provided, interactive mode if a tty)
  --   indicate the end of node options
  --abort-on-uncaught-exceptionaborting instead of exiting causes a 
core file to be
   generated for analysis
  --build-snapshot Generate a snapshot blob when the 
process exits. Currently
   only supported in the 
node_mksnapshot binary.
  -c, --check  syntax check script without executing
  --completion-bashprint source-able bash completion 
script
  -C, --conditions=... additional user conditions for 
conditional exports and
   imports
...

vimer@unmatched10:~/build/01_nodejs$ uname -a
Linux unmatched10 6.0.0-2-riscv64 #1 SMP Debian 6.0.3-1 (2022-10-21) riscv64 
GNU/Linux
vimer@unmatched10:~/build/01_nodejs$ apt-cache policy nodejs
nodejs:
  Installed: 18.12.1+dfsg-2
  Candidate: 18.12.1+dfsg-2
  Version table:
 *** 18.12.1+dfsg-2 100
100 /var/lib/dpkg/status
 18.10.0+dfsg-6 500
500 https://mirror.iscas.ac.cn/debian-ports sid/main riscv64 Packages
```

But I got the same result with you in qemu, hope this helps.

-- 
Regards,
--
  Bo YU



signature.asc
Description: PGP signature

Bug#985478: dash: unset OPTIND returns 2 (Illegal number)

[наб]

Control: tags -1 + upstream
Control: forwarded -1 
https://lore.kernel.org/dash/20221214023130.u7pn4ca6ma4ku...@tarta.nabijaczleweli.xyz/t/

Patch posted to dash@, archived at forwarded-to.

наб


signature.asc
Description: PGP signature

Bug#1026065: nodejs: ftbfs due to test cases

[Bo YU]

Source: nodejs
Version: 18.12.1+dfsg-2
Severity: important
Tags: ftbfs, patch
User: debian-ri...@lists.debian.org
Usertags: riscv64
X-Debbugs-Cc: debian-ri...@lists.debian.org

Dear Maintainer,

The package has a ftbfs issue due to test case, the full buildd log is
here:
https://buildd.debian.org/status/fetch.php?pkg=nodejs&arch=riscv64&ver=18.12.1%2Bdfsg-2&stamp=1670558058&raw=0

I have added the test cases failed to flag FLAKY to pass the test. 
And I have tested it riscv64 hardware.

btw, there is no problem to run nodejs on riscv64 about #1025736, but I
will comment detailed in the reportbug. please let me know if there is
any issue.

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

-- 
Regards,
--
  Bo YU

diff -Nru nodejs-18.12.1+dfsg/debian/patches/riscv/flaky_tests.patch 
nodejs-18.12.1+dfsg/debian/patches/riscv/flaky_tests.patch
--- nodejs-18.12.1+dfsg/debian/patches/riscv/flaky_tests.patch  2022-10-27 
20:10:45.0 +0800
+++ nodejs-18.12.1+dfsg/debian/patches/riscv/flaky_tests.patch  2022-11-10 
01:16:06.0 +0800
@@ -16,19 +16,23 @@
 +test-cpu-prof-exit: FLAKY
 +test-cpu-prof-kill: FLAKY
 +test-diagnostic-dir-cpu-prof: FLAKY
++test-debugger-auto-resume: FLAKY
 +test-debugger-preserve-breaks: FLAKY
 +test-cpu-prof-dir-relative: FLAKY
 +test-cpu-prof-drained: FLAKY
 +test-worker-prof: FLAKY
 +test-vm-timeout-escape-promise-module-2: FLAKY
-+
 --- a/test/parallel/parallel.status
 +++ b/test/parallel/parallel.status
-@@ -131,3 +131,7 @@
+@@ -131,3 +131,11 @@
  test-http-upgrade-advertise: PASS, FLAKY
  test-tls-client-mindhsize: PASS, FLAKY
  test-tls-write-error: PASS, FLAKY
 +
 +[$arch==riscv64]
 +test-fetch: PASS, FLAKY
++test-net-socket-connect-without-cb: PASS, FLAKY
++test-runner-inspect: PASS, FLAKY
++test-tcp-wrap-listen: PASS, FLAKY
 +test-wasm-web-api: PASS, FLAKY
++test-vm-timeout-escape-promise-module: PASS, FLAKY


signature.asc
Description: PGP signature

Bug#1026064: RM: haskell-blogliterately -- RoQA; not released since stretch; blocks 2 other removals

[Bastian Germann]

Source: haskell-blogliterately
Control: block 997972 by -1
Control: block 963737 by -1

haskell-blogliterately is obviously not maintained anymore and was not built 
for ages (last release: stretch).
I am going to reassign this removal request to ftp.debian.org within a few days 
if this is not commented on.

Bug#1021292: Fw: Re: Enabling branch protection on amd64 and arm64

[Wookey]

On 2022-12-13 22:37 +0100, Guillem Jover wrote:
> On Mon, 2022-12-12 at 04:28:29 +, Wookey wrote:
> As I think I mentioned previously, the problem is that we cannot
> currently add it even disabled by default, due to many packages using
> «hardening=+all» which has the same effect for these as the option
> being enabled by default.

Ah yes. Good point. That is unfortunate.
If you did point it out already, it had failed to sink in at my end.

> What I also mentioned, and as I was expecting there to be pushback on
> the new hardening feature, is to perhaps add versioned buildflags
> support. I'll post what I've got to debian-dpkg during this week.

OK, cheers.

Wookey
-- 
Principal hats:  Debian, Wookware, ARM
http://wookware.org/


signature.asc
Description: PGP signature

Bug#981405: Does it make sense to use the same file?

[Christoph Anton Mitterer]

Hey Russell

On Wed, 2022-12-14 at 08:45 +1100, Russell Coker wrote:
> I think this is an upstream bug for misusing an existing config file.

While I agree on that... I'm not sure whether it's good to have two
separate config files for more or less the same thing.
This might open up all kinds of problems... e.g. administratively
(accidentally having the same mapping in both files) but also in terms
of support (will tools that parse crypttab suddenly support only one of
both?), etc.


Would it perhaps be an option for systemd upstream to do something what
it already does in /etc/fstab, namely use the x-systemd.* namespace for
it's own options?

As long as it would do that an otherwise follow the syntax (especially
not adding any further columns) it could happily coexist with the
"native" cryptsetup format, and e.g. Debian's cryptsetup package could
ignore any such entries that have a x-systemd.* option it doesn't
understand (or generally all, if that's agreed upon).

The only other thing systemd would then need to consider (though
Guilhelm might know better if there's more) is that there is a quoting
format, in order to allow things like newlines/etc. within a field.


Cheers,
Chris.

Bug#1026063: O: haskell-pcre-light -- Portable regex library

[Bastian Germann]

Package: wnpp
X-Debbugs-Cc: pkg-haskell-maintain...@lists.alioth.debian.org

Joachim Breitner has emeritus status and the Haskell Group has not uploaded any 
version that would fix the open RC bugs.
So I orphan the package.

Bug#1026062: kded5: kded crashes with signal 11

[Tim Sattarov]

Package: kded5
Version: 5.100.0-1
Severity: normal
X-Debbugs-Cc: sti...@gmail.com

Dear Maintainer,

Starting with version 5.100.0-1 my local kded process started to crash and the
only way to restore it is to restart the service

systemctl  --user restart plasma-kded.service

It works for some time after restart and then crashes again.

Please see the logs from the crash attached.




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

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

Versions of packages kded5 depends on:
ii  libc6  2.36-6
ii  libkf5configcore5  5.100.1-1
ii  libkf5coreaddons5  5.100.0-1
ii  libkf5crash5   5.100.0-1
ii  libkf5dbusaddons5  5.100.0-1
ii  libkf5service-bin  5.100.0-1
ii  libkf5service5 5.100.0-1
ii  libqt5core5a   5.15.6+dfsg-5
ii  libqt5dbus55.15.6+dfsg-5
ii  libqt5gui5 5.15.6+dfsg-5
ii  libqt5widgets5 5.15.6+dfsg-5
ii  libstdc++6 12.2.0-9

kded5 recommends no packages.

kded5 suggests no packages.

-- no debconf information


kded.log.zst
Description: application/zstd

Bug#1011921: big5

[Dan Jacobson]

I am sorry. My mailer  converts it into utf-8. So you guys will just 
have to convert it back into Big 5 to continue the experiments.

Bug#1026061: bart: FTBFS randomly in bullseye (failing test)

[Santiago Vila]

Package: src:bart
Version: 0.6.00-3
Fixed: 0.8.00-3
Severity: serious
Tags: ftbfs

Dear maintainer:

During a rebuild of all packages in bullseye, your package failed to build:


[...]
 debian/rules binary-indep
dh binary-indep
   dh_update_autotools_config -i
   dh_autoreconf -i
   dh_auto_configure -i
   dh_auto_build -i
make -j2 "INSTALL=install --strip-program=true"
make[1]: Entering directory '/<>'
make MAKESTAGE=2 make[2]: Entering directory '/<>'
make[2]: warning: jobserver unavailable: using -j1.  Add '+' to parent 
make rule.
gcc -Wdate-time -D_FORTIFY_SOURCE=2 -MMD -MF 
/<>/src/.bart.d -iquote /<>/src/ 
-I/usr//include/ -I/usr//include -DFFTWTHREADS -DMAIN_LIST="avg, bench, 
bin, bitmask, cabs, caldir, calmat, carg, casorati, cc, ccapply, cdf97, 
circshift, conj, conv, copy, cpyphs, creal, crop, delta, ecalib, 
ecaltwo, estdelay, estdims, estshift, estvar, extract, fakeksp, fft, 
fftmod, fftrot, fftshift, filter, flatten, flip, fmac, homodyne, index, 
invert, itsense, join, looklocker, lrmatrix, mandelbrot, mip, moba, 
nlinv, noise, normalize, nrmse, nufft, ones, pattern, phantom, pics, 
pocsense, poisson, poly, repmat, reshape, resize, rmfreq, rof, rss, 
rtnlinv, sake, saxpy, scale, sdot, show, slice, spow, sqpics, squeeze, 
ssa, std, svd, tgv, threshold, toimg, traj, transpose, twixread, upat, 
var, vec, version, walsh, wave, wavelet, wavepsf, whiten, window, wshfl, 
zeros, zexp, ()" -include src/main.h -g -O2 
-ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -std=gnu11 -fopenmp -c -o 
/<>/src/bart.o /<>/src/bart.c


[... snipped ...]

gcc -Wdate-time -D_FORTIFY_SOURCE=2 -MMD -MF utests/.test_prox.d -iquote 
/<>/src/ -I/usr//include/ -I/usr//include -DFFTWTHREADS -g 
-O2 -ffile-prefix-map=/<>=. -fstack-protector-strong 
-Wformat -Werror=format-security -std=gnu11 -fopenmp -c -o 
utests/test_prox.o utests/test_prox.c
gcc -Wl,-z,relro -Wl,-z,now -rdynamic -rdynamic -g -O2 
-ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -std=gnu11 -fopenmp -Wdate-time 
-D_FORTIFY_SOURCE=2 -MMD -MF ./.test_prox.d -iquote 
/<>/src/ -I/usr//include/ -I/usr//include -DFFTWTHREADS 
-DUTESTS="call_test_thresh, call_test_auto_norm," -o test_prox 
utests/utest.c utests/test_prox.o lib/libiter.a lib/liblinops.a 
lib/libnum.a lib/libmisc.a lib/libnum.a lib/libmisc.a -L/usr//lib 
-lfftw3f -lfftw3f_threads  -L/usr//lib -llapacke -lblas  -lm

./test_linop_matrix  ./test_linop_matrix:  4/ 4 passed.
./test_linop ./test_linop:  3/ 3 passed.
./test_batchsvd  ./test_batchsvd:  2/ 2 passed.
./test_pattern   ./test_pattern:  1/ 1 passed.
./test_types ./test_types:  2/ 2 passed.
./test_misc  ./test_misc:  2/ 2 passed.
./test_moba  ./test_moba:  1/ 1 passed.
./test_nlop  ./test_nlop: 15/15 passed.
./test_nufft ERROR: ./test_nufft:  7/ 8 passed.
make[3]: *** [Makefile:685: utests-all] Error 1
make[3]: Leaving directory '/<>'
make[2]: *** [Makefile:273: utest] Error 2
make[2]: Leaving directory '/<>'
make[1]: *** [debian/rules:22: override_dh_auto_test] Error 2
make[1]: Leaving directory '/<>'
make: *** [debian/rules:16: binary-indep] Error 2
dpkg-buildpackage: error: debian/rules binary-indep subprocess returned 
exit status 2



Note: The failure happens randomly, but the failure rate is around 70%, 
which is why I'm using
a severity of "serious". In either case, I'm marking this as fixed in 
the bookworm version,

as the failures do not seem to happen there.


About the archive rebuild: The build was made using virtual machines 
from Hetzner,

with enough memory, enough disk, and either one or two CPUs, using a reduced
chroot with only build-essential packages (plus debhelper).

If you could not reproduce the bug please contact me privately, as I am 
willing
to provide ssh access to a virtual machine where the bug is fully 
reproducible.


If this is really a bug in one of the build-depends, please use reassign 
and affects,

so that this is still visible in the BTS web page for this package.

Thanks.

Bug#1004784: aiscm: FTBFS with ffmpeg 5.0

[Bastian Germann]

Is this fixed with 0.24.2? If so, please update the package.

Bug#887035: cron: Logging to STDOUT when in foreground mode

[Nick Reilingh]

On Thu, 28 Jan 2021 17:38:00 + prog+debian-bug-887...@posteo.org wrote:
> For the use case of containerized environments BusyBox already provides
> a cron applet with custom logging capabilities:
> 
> busybox crond -f -L /dev/stdout

I am working in a debian-based container and the busybox available via apt-get 
appears not to have crond available.

Dockerfile:
FROM debian

RUN apt-get update && apt-get install -y busybox

CMD ["bash"]

$ docker build -t test .
$ docker run --rm -it test
# busybox crond -f
crond: applet not found

Can you clarify how one can use busybox’s crond in a containerized environment?

Thank you,
Nick R.

Bug#1025268: Should mozjs102 in bookworm use the system icu?

[Jeremy Bicha]

On Thu, Dec 1, 2022 at 1:42 PM Adrian Bunk  wrote:
> The system icu 72 is no longer older than the icu 71 vendored
> in mozjs102, should mozjs102 in bookworm use the system icu?

It's possible for a newer mozjs to be backported to Debian 12, later
in Debian 12's life. In this case, it might be simpler for everyone if
mozjs was using the vendored ICU.

By the way, I am working on backporting mozjs102 to Ubuntu 22.04 LTS
now: https://launchpad.net/bugs/1993214

Thank you,
Jeremy Bicha

Bug#1026001: libpam-cap: file conflict with package libcap2-bin

[Christian Kastner]

On 2022-12-13 06:02, Christoph Anton Mitterer wrote:
> On installation there is a file conflict:
> Unpacking libpam-cap:amd64 (1:2.66-1) over (1:2.63-1) ...
> dpkg: error processing archive 
> /tmp/apt-dpkg-install-B9lzYA/08-libpam-cap_1%3a2.66-1_amd64.deb (--unpack):
>  trying to overwrite '/usr/share/man/man5/capability.conf.5.gz', which is 
> also in package libcap2-bin 1:2.63-1
> 
> Which is however resolved after libcap2-bin has been upgraded and
> when one tries to install the former again.
> 
> Guess a missing Replaces?

You guessed correct. Thanks for pointing this out. Fix will be uploaded
soon.

Best,
Christian

Bug#862907: dash: Incorrectly slurps script from stdin (POSIX compliance issue)

[наб]

Control: forwarded -1 
https://lore.kernel.org/dash/20221213221732.6mvv22u7ktdoz...@tarta.nabijaczleweli.xyz/t/

Looks like a trivial one-line fix to, quite literally,
read with count=1 if reading from the standard input stream;
patch posted to dash@, archived at forwarded-to.

наб


signature.asc
Description: PGP signature

Bug#1026059: geeqie: Missing JPEG XL support

[Andreas Rönnquist]

On Tue, 13 Dec 2022 22:22:16 +0100
"Davide G. Borin"  wrote:

>Package: geeqie
>Version: 1:2.0.1-5
>Severity: normal
>
>Dear Maintainer,
>  according to Geeqie website, it'd support JPEG XL image format, but Debian 
> packaged version doesn't.
>
>http://www.geeqie.org/help/GuideReferenceSupportedFormats.html
>
>

Thanks for your report - you are right, I'll add the jpeg XL support
(there's only a build-dep that needs to be added).

Last time I looked at this, jepg-xl was only available in experimental,
but since it has been uploaded to unstable too, so now there's no
reason to build geeqie without it. Thanks!

best
/Andreas
gus...@debian.org
gus...@librem.one

Bug#981405: Does it make sense to use the same file?

[Russell Coker]

Cryptsetup and systemd use different format options for /etc/crypttab.  If you 
add systemd specific options then cryptsetup gives error messages which 
surprise users.  Casual web searches on the topic don't make it obvious that 
there are 2 different programs doing quite different things with the same 
config file.

If systemd used /etc/systemd/blockcrypt.conf or something similar there 
wouldn't be any confusion in this regard and web searches would get more 
useful results.

I think this is an upstream bug for misusing an existing config file.

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

Bug#1026060: mpv: dvb playback does not work anymore

[Thomas Viehweger]

Package: mpv
Version: 0.35.0-3
Severity: important


mpv 'dvb://Das Erste HD' fails with

No protocol handler found to open URL dvb://Das Erste HD
The protocol is either unsupported, or was disabled at compile-time.

With mpv-0.34.1-1+b5 this was working.

Bug#1021292: Fw: Re: Enabling branch protection on amd64 and arm64

[Guillem Jover]

On Mon, 2022-12-12 at 04:28:29 +, Wookey wrote:
> The debian-devel thread continued but most responses were not copied
> to the bug (I've just realised). Possibly this means that you (guillem)
> didn't see most of the conversation.
> 
> The bottom line is the security team were very unenthusiastic about
> enabling this by default because it might produce unexpected changes
> on security uploads, which is fair enough.
> 
> Another suggestion was that it should be turned on for x32 too.
> 
> I was expecting (after that discussion) the 'branch' functionality to be
> included in the next dpkg upload, just not enabled by default, but it
> was not included in 1.21.12
> 
> Do you disagree or did this just get forgotten?

As I think I mentioned previously, the problem is that we cannot
currently add it even disabled by default, due to many packages using
«hardening=+all» which has the same effect for these as the option
being enabled by default.

What I also mentioned, and as I was expecting there to be pushback on
the new hardening feature, is to perhaps add versioned buildflags
support. I'll post what I've got to debian-dpkg during this week.

Thanks,
Guillem

Bug#1025220: passenger: Passenger startup fails with nodejs applications using node versions later than 14.x

[Cool Fire]

Hello,

On Tue, 13 Dec 2022 09:54:05 -0300 Antonio Terceiro 
 wrote:

> Please note that supporting nodejs from outside of the debian archive is
> not a priority.

That's entirely understandable.


On Tue, 13 Dec 2022 09:54:05 -0300 Antonio Terceiro 
 wrote:

> I'm not making any promises, but if you can identify the fix yourself
> and check whether it applies to the passenger version in stable (or do
> the necessary backporting) in a way that doesn't break usage with nodejs
> from stable, I could provide a stable update with that fix.

I've made some quick and dirty docker containers to validate that 
replacing the "GLOBAL" with "global" is really all that is needed to fix 
the issue, and that it does not break for deployments using the nodejs 
version from the debian repos: 
https://git.insomnia247.nl/coolfire/passenger-tests


As for actually writing the patch file needed for the package and how I 
would go about submitting that, a few pointers would be greatly 
appreciated if you can find the time.

Bug#1026039: lyx: LyX is listed as proprietary software in Gnome-software

[Pavel Sanda]

On Tue, 13 Dec 2022 17:50:03 +0100 Lorenzo Bertini  
wrote:
> LyX is listed on my system as proprietary software in gnome-software. Looking 
> online I found several people having this issue with other programs, and the 
> cause was always that the license couldn't be read by gnome-software properly.
> 
> Please ensure that gnome-software can properly read the license. If the bug 
> is not on our end, let me know and I will contact gnome-software developers.

Well, LyX installs it's licences where it should, i.e. into 
/usr/share/doc/lyx/copyright.
If there is something specific WRT gnome, we can do it but we need
gnome maintainers input... I don't use gnome personally so can't
even test it.

I CC maintainer of gnome-software if he has some hints for us.

Pavel

Bug#1026039: lyx: LyX is listed as proprietary software in Gnome-software

[Jeremy Bicha]

On Tue, Dec 13, 2022 at 4:19 PM Pavel Sanda  wrote:
>
> On Tue, 13 Dec 2022 17:50:03 +0100 Lorenzo Bertini 
>  wrote:
> > LyX is listed on my system as proprietary software in gnome-software. 
> > Looking online I found several people having this issue with other 
> > programs, and the cause was always that the license couldn't be read by 
> > gnome-software properly.
> >
> > Please ensure that gnome-software can properly read the license. If the bug 
> > is not on our end, let me know and I will contact gnome-software developers.
>
> Well, LyX installs it's licences where it should, i.e. into
> /usr/share/doc/lyx/copyright.
> If there is something specific WRT gnome, we can do it but we need
> gnome maintainers input... I don't use gnome personally so can't
> even test it.
>
> I CC maintainer of gnome-software if he has some hints for us.

The GNOME Software app prefers to use AppStream metadata.

https://wiki.debian.org/AppStream/Guidelines
https://www.freedesktop.org/software/appstream/docs/chap-Metadata.html

Thank you,
Jeremy Bicha

Bug#1017531: dash: for/while/if suppress errors from redirections with -e, POSIX violation

[наб]

It appears that dash has received its first tagged release ‒ 0.5.12 ‒
since 2020-06-01, just three days ago:
  https://git.kernel.org/pub/scm/utils/dash/dash.git/tag/?h=v0.5.12

This corresponds to the first period of activity since roughly the same
time-frame:
  
https://git.kernel.org/pub/scm/utils/dash/dash.git/diff/?id=dcf4ee38025a06e7392063f02f37afc0c08e0e2f^&id2=4bbf8721a3ac6401ced6a0454956801f6ba37256

The release includes a bunch of fixes, incl. for this bug.
Please consider pulling it in.

наб


signature.asc
Description: PGP signature

Bug#1026059: geeqie: Missing JPEG XL support

[Davide G. Borin]

Package: geeqie
Version: 1:2.0.1-5
Severity: normal

Dear Maintainer,
 according to Geeqie website, it'd support JPEG XL image format, but 
Debian packaged version doesn't.


http://www.geeqie.org/help/GuideReferenceSupportedFormats.html


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

Kernel: Linux 6.0.0-5-amd64 (SMP w/24 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:it

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

Versions of packages geeqie depends on:
ii  geeqie-common1:2.0.1-5
ii  libarchive13 3.6.0-1
ii  libc62.36-6
ii  libcairo21.16.0-6
ii  libdjvulibre21   3.5.28-2
ii  libexiv2-27  0.27.5-4
ii  libffmpegthumbnailer4v5  2.2.2+git20220218+dfsg-1+b1
ii  libgcc-s112.2.0-9
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-1
ii  libglib2.0-0 2.74.2-1
ii  libgspell-1-21.12.0-1+b1
ii  libgtk-3-0   3.24.35-3
ii  libheif1 1.13.0-1
ii  libjpeg62-turbo  1:2.1.2-1+b1
ii  liblcms2-2   2.13.1-1+b1
ii  liblua5.3-0  5.3.6-1+b1
ii  libopenjp2-7 2.5.0-1
ii  libpango-1.0-0   1.50.10+ds-1
ii  libpangocairo-1.0-0  1.50.10+ds-1
ii  libpoppler-glib8 22.08.0-2.1
ii  libraw20 0.20.2-2+b1
ii  libstdc++6   12.2.0-9
ii  libtiff5 4.4.0-6
ii  libwebp7 1.2.2-2+b2
ii  sensible-utils   0.0.17

Versions of packages geeqie recommends:
pn  cups-bsd | lpr   
pn  exiftran 
pn  exiv2
ii  imagemagick  8:6.9.11.60+dfsg-1.3+b4
ii  imagemagick-6.q16 [imagemagick]  8:6.9.11.60+dfsg-1.3+b4
ii  librsvg2-common  2.54.5+dfsg-1
pn  zenity   

Versions of packages geeqie suggests:
ii  gimp   2.99.14-2
pn  libjpeg-progs  
pn  xpaint 

-- no debconf information

Bug#870317: dash: "type" doesn't threat "--" specially (POSIX compliance issue)

[наб]

Control: tags -1 + upstream
Control: forwarded -1 
https://lore.kernel.org/dash/d7d04bbcf75c97c52726bf65e9ed4d9310ebdd51.1670966008.git.nabijaczlew...@nabijaczleweli.xyz/t/

I've reviewed all built-ins, and found that this affected
type and getopts. Patchset posted to dash@, archived at forwarded-to.

наб


signature.asc
Description: PGP signature

Bug#1026035: xen netback broken with 5.10.0-20-amd64 in s-p-u

[Salvatore Bonaccorso]

Source: linux
Source-Version: 5.10.158-2

Hi Adi,

On Tue, Dec 13, 2022 at 03:40:04PM +0100, Adi Kriegisch wrote:
> Source: linux
> Version: 5.10.158-1
> 
> Dear maintainers,
> 
> we just upgraded our xen test cluster's kernel to the latest kernel from
> s-p-u and noticed that network communication is broken. We do have a
> 'classic' setup with bridges in dom0. After upgrading dom0's kernel, no
> communication is possible for the domU.
> 
> We can see packets arrive at the domU and packets leave the domU; but they
> never arrive at the virtual interface in dom0 (rx counter stays at 0 and error
> counters stay at 0 too).
> 
> When migrating the domU back to the other server which has not been
> upgraded, the machine is reachable again.
> 
> If there is anything we can do to help fixing that issue, we'll gladly do
> that!
> 
> Thank you very much!

This is adressed with a subsequent upload which should hit the archive
soon and hopefully in time for the point release (I did miss to close
this bug with the upload, doing so manually to have proper version
tracking).

Regards,
Salvatore

Bug#1026058: rust-xmlparser: FTBFS: src/lib.rs - map_err_at (line 396)

[Aurelien Jarno]

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

Hi,

Your package fails to build with:

| running 6 tests
| test src/lib.rs - map_err_at (line 396) - compile ... FAILED
| test src/stream.rs - stream::Stream::consume_byte (line 181) ... ok
| test src/stream.rs - stream::Stream::advance (line 140) ... ok
| test src/lib.rs - (line 7) ... ok
| test src/stream.rs - stream::Stream::gen_text_pos_from (line 313) ... ok
| test src/stream.rs - stream::Stream::starts_with (line 159) ... ok
| 
| failures:
| 
|  src/lib.rs - map_err_at (line 396) stdout 
| error[E0433]: failed to resolve: use of undeclared type `Token`
|  --> src/lib.rs:399:25
|   |
| 5 | Error::InvalidToken(Token::SomeToken, 
stream.gen_error_pos_from(start), Some(e))
|   | ^ use of undeclared type `Token`
| 
| error[E0425]: cannot find value `stream` in this scope
|  --> src/lib.rs:397:13
|   |
| 3 | let start = stream.pos() - 2; // or any other number
|   | ^^ not found in this scope
| 
| error[E0425]: cannot find function `some_func` in this scope
|  --> src/lib.rs:398:1
|   |
| 4 | some_func().map_err(|e|
|   | ^ not found in this scope
| 
| error[E0433]: failed to resolve: use of undeclared type `Error`
|  --> src/lib.rs:399:5
|   |
| 5 | Error::InvalidToken(Token::SomeToken, 
stream.gen_error_pos_from(start), Some(e))
|   | ^ not found in this scope
|   |
| help: consider importing one of these items
|   |
| 2 | use std::error::Error;
|   |
| 2 | use std::fmt::Error;
|   |
| 2 | use std::io::Error;
|   |
| 
| error[E0425]: cannot find value `stream` in this scope
|  --> src/lib.rs:399:43
|   |
| 5 | Error::InvalidToken(Token::SomeToken, 
stream.gen_error_pos_from(start), Some(e))
|   |   ^^ not found in this scope
| 
| error: aborting due to 5 previous errors
| 
| Some errors have detailed explanations: E0425, E0433.
| For more information about an error, try `rustc --explain E0425`.
| Couldn't compile the test.
| 
| failures:
| src/lib.rs - map_err_at (line 396)
| 
| test result: FAILED. 5 passed; 1 failed; 0 ignored; 0 measured; 0 filtered 
out; finished in 8.96s

The full build log is available from:
  
https://buildd.debian.org/status/fetch.php?pkg=rust-xmlparser&arch=riscv64&ver=0.11.0-1%2Bb1&stamp=1670942978&raw=0
 
  
https://tests.reproducible-builds.org/debian/rbuild/unstable/amd64/rust-xmlparser_0.11.0-1.rbuild.log.gz

Regards
Aurelien

Bug#1026024: specutils: FTBFS, ModuleNotFoundError: No module named 'asdf_astropy.io'

[Ole Streicher]

Control: reassign -1 src:asdf-astropy 0.3.0-1
Control: affects -1 src:specutils

This is a bug in the current python3-asdf-astropy package that is 
incomplete. However, according to #1025434 the cause for the issue is 
probably in python3-installer.

Bug#1025959: Feedback regarding RFS: davmail/6.0.1.3390-2

[Geert Stappers]

On Mon, Dec 12, 2022 at 05:14:23PM +0100, Alexandre Rossi wrote:
> Hi,
> 
> > > The source builds the following binary packages:
> > > 
> > >   davmail - POP/IMAP/SMTP/CalDav/LDAP to Microsoft Exchange gateway - GUI
> > >   davmail-server - POP/IMAP/SMTP/CalDav/LDAP to Microsoft Exchange 
> > > gateway - headless
> > 
> > The -server  package is probably new.
> 
> That's why I need a sponsor.
 
Working on it   :-)

> > What about D.M.  upload privileges?
> 
> I have those, but because the -server package goes through NEW, it does not 
> apply.
> 
> Cheers and thanks,


Feedback:

 * The packaging git repo is not up to date
 * Systemd unit file `debian/davmail.service` is not installed
   in davmail-server  (Neither in davmail)
 * Script `debian/prepare-service` feels wrong
 if  keystore is a file
 then copy+chown keystore
 else remove keystore
   That doesn't make sense 


Request:

 * Add the release "davmail (6.0.1.3390-1.1)" to packaging git repo
 * Review / improve the  `prepare-service`
 * Make that `davmail-service` makes it into `davmail-server` package
 * Ping me


> Alexandre
 

Groeten
Geert Stappers
-- 
Silence is hard to parse

Bug#1026055: lapack breaks openturns autopkgtest: undefined reference to `ztrsyl3_' (and 3 more)

[Sébastien Villemot]

Control: block -1 by 1025699

Le mardi 13 décembre 2022 à 21:50 +0100, Paul Gevers a écrit :
> Source: lapack, openturns
> Control: found -1 lapack/3.11.0-2
> Control: found -1 openturns/1.20-5
> Severity: serious
> Tags: sid bookworm
> User: debian...@lists.debian.org
> Usertags: breaks needs-update
> 
> With a recent upload of lapack the autopkgtest of openturns fails in 
> testing when that autopkgtest is run with the binary packages of lapack 
> from unstable. It passes when run with only packages from testing. In 
> tabular form:
> 
> passfail
> lapack from testing3.11.0-2
> openturns  from testing1.20-5
> all others from testingfrom testing
> 
> I copied some of the output at the bottom of this report.
> 
> Currently this regression is blocking the migration of lapack to testing 
> [1]. Due to the nature of this issue, I filed this bug report against 
> both packages. Can you please investigate the situation and reassign the 
> bug to the right package?

Thanks Paul.

The problem is that atlas needs to be recompiled against lapack 3.11.0.
Which has been done in atlas 3.10.3-13. But atlas itself cannot migrate
to testing because of #1025699.

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



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

Bug#1026057: swi-prolog: autopkgtest regression on armel armhf and i386: Segmentation fault

[Paul Gevers]

Source: swi-prolog
Version: 9.0.2+dfsg-1
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

With a recent upload of swi-prolog the autopkgtest of swi-prolog fails 
in testing when that autopkgtest is run with the binary packages of 
swi-prolog from unstable on armel, armhf and i386. It passes when run 
with only packages from testing. In tabular form:


   passfail
swi-prolog from testing9.0.2+dfsg-1
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration to testing [1]. Can 
you please investigate the situation and fix it?


More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=swi-prolog

https://ci.debian.net/data/autopkgtest/testing/armel/s/swi-prolog/29272723/log.gz

% Checking your SWI-Prolog kit for common issues ...
% % Version: . 9.0.2
% Address bits:  32
% Architecture:  armv7l-linux
% Installed at:  /usr/lib/swi-prolog
% Cores: ... 16
% % Checking tcmalloc  ok
% Checking gmp . ok
% Loading library(archive) . ok
%   Supported filters: bzip2, compress, gzip, grzip, lrzip, lzip, lzma, 
lzop, none, rpm, uu, xz
%   Supported formats: 7zip, ar, cab, cpio, empty, gnutar, iso9660, lha, 
mtree, rar, raw, tar, xar, zip

% Loading library(cgi) . ok
% Loading library(crypt) ... ok
% Loading library(bdb) . ok
% Loading library(double_metaphone)  ok
% Loading library(filesex) . ok
% Loading library(http/http_stream)  ok
% Loading library(http/json) ... ok
% Loading library(http/jquery) . ok
Warning:   Cannot find jQuery (jquery.min.js)
% Loading library(isub)  ok
% Loading library(jpl) . ok
% Loading library(memfile) . ok
% Loading library(odbc)  ok
% Loading library(pce) . ok
% Loading library(pcre)  ok
% Loading library(pdt_console) . ok
% Loading library(porter_stem) . ok
% Loading library(process) . ok
% Loading library(protobufs) ... ok
% Loading library(editline)  ok
% Loading library(readline)  ok
% Loading library(readutil)  ok
% Loading library(rlimit) .. ok
% Loading library(semweb/rdf_db) ... ok
% Loading library(semweb/rdf_ntriples) . ok
% Loading library(semweb/turtle) ... ok
% Loading library(sgml)  ok
% Loading library(sha) . ok
% Loading library(snowball)  ok
% Loading library(socket) .. ok
% Loading library(ssl) . ok
Warning: library(sweep_link) ... NOT FOUND
Warning: See http://www.swi-prolog.org/build/issues/sweep_link.html
% Loading library(crypto) .. ok
% Loading library(syslog) .. ok
% Loading library(table) ... ok
% Loading library(time)  ok
% Loading library(tipc/tipc) ... ok
% Loading library(unicode) . ok
% Loading library(uri) . ok
% Loading library(uuid)  ok
% Loading library(zlib)  ok
% Loading library(yaml)  ok
Warning: Found 1 issues.
% SWI-Prolog test suite.
% To run all tests run ?- test.
% Running test set "syntax" ... done.
Running test set "write_test" .. done.
Running test set "format_test" . done.
Running test set "unify" .. done.
Running test set "occurs_check" .. done.
Running test set "unifiable" ... done.
Running test set "arithmetic" .. done.
Running test set "arithmetic_functions"  done.
Running test set "floattest"  done.
Running test set "gmp" 
... done.

Running test set "chars" .. done.
Running test set "wchars" .. done.
Running test set "depth_limit" . done.
Running test set "type_test"  done.
Running test set "meta" ... done.
Running test set "avar" .. done.
Running test set "gvar" . done.
Running test set "copy_term" .. done.
Running test set "term_hash"  done.
Running test set "cyclic" .. done.
Running test set "cleanup" . done.
Running test set "term" ..

Bug#1026056: swi-prolog breaks logol autopkgtest: Program exited with wrong status code

[Paul Gevers]

Source: swi-prolog, logol
Control: found -1 swi-prolog/9.0.2+dfsg-1
Control: found -1 logol/1.7.9+dfsg-5
Severity: serious
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainer(s),

With a recent upload of swi-prolog the autopkgtest of logol fails in 
testing when that autopkgtest is run with the binary packages of 
swi-prolog from unstable. It passes when run with only packages from 
testing. In tabular form:


   passfail
swi-prolog from testing9.0.2+dfsg-1
logol  from testing1.7.9+dfsg-5
all others from testingfrom testing

I copied some of the output at the bottom of this report. The issue 
*looks* similar to bug 1022253, but now on all architectures.


Currently this regression is blocking the migration of swi-prolog to 
testing [1]. Due to the nature of this issue, I filed this bug report 
against both packages. Can you please investigate the situation and 
reassign the bug to the right package?


More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=swi-prolog

https://ci.debian.net/data/autopkgtest/testing/amd64/l/logol/29303003/log.gz

calling logol with parameters -g 1799.logol -s 1799.fasta -dna
log4j:ERROR setFile(null,true) call failed.
java.io.FileNotFoundException: /var/log/logol/logol.log (Permission denied)
at java.base/java.io.FileOutputStream.open0(Native Method)
at java.base/java.io.FileOutputStream.open(FileOutputStream.java:293)
at java.base/java.io.FileOutputStream.(FileOutputStream.java:235)
at java.base/java.io.FileOutputStream.(FileOutputStream.java:155)
at org.apache.log4j.FileAppender.setFile(FileAppender.java:294)
at org.apache.log4j.FileAppender.activateOptions(FileAppender.java:165)
at 
org.apache.log4j.config.PropertySetter.activate(PropertySetter.java:307)
	at 
org.apache.log4j.config.PropertySetter.setProperties(PropertySetter.java:172)
	at 
org.apache.log4j.config.PropertySetter.setProperties(PropertySetter.java:104)
	at 
org.apache.log4j.PropertyConfigurator.parseAppender(PropertyConfigurator.java:842)
	at 
org.apache.log4j.PropertyConfigurator.parseCategory(PropertyConfigurator.java:768)
	at 
org.apache.log4j.PropertyConfigurator.parseCatsAndRenderers(PropertyConfigurator.java:672)
	at 
org.apache.log4j.PropertyConfigurator.doConfigure(PropertyConfigurator.java:516)
	at 
org.apache.log4j.PropertyConfigurator.doConfigure(PropertyConfigurator.java:580)
	at 
org.apache.log4j.helpers.OptionConverter.selectAndConfigure(OptionConverter.java:526)

at org.apache.log4j.LogManager.(LogManager.java:127)
at org.apache.log4j.Logger.getLogger(Logger.java:117)
at org.irisa.genouest.logol.Logol.(Unknown Source)
For help, use option -h
INFO org.irisa.genouest.logol.Logol  - Using configuration file: 
/usr/share/logol/prolog/logol.properties

INFO org.irisa.genouest.logol.Logol  - option g called with 1799.logol
INFO org.irisa.genouest.logol.Logol  - option s called with 1799.fasta
INFO org.irisa.genouest.logol.Logol  - No maximum solutions defined, 
using defaults

INFO org.irisa.genouest.logol.Logol  - option dna called
INFO org.irisa.genouest.logol.Logol  - Start analyse to create grammar 
analyser

Executing prolog for pre-analyse
java.io.FileNotFoundException: 
/tmp/1799.logol.38da5a9d-c2ac-4a7d-8eb3-8c05b42f5c04.pre.res (No such 
file or directory)

at java.base/java.io.FileInputStream.open0(Native Method)
at java.base/java.io.FileInputStream.open(FileInputStream.java:216)
at java.base/java.io.FileInputStream.(FileInputStream.java:157)
at java.base/java.io.FileReader.(FileReader.java:75)
at org.irisa.genouest.logol.Logol.loadVariables2Postpone(Unknown Source)
at org.irisa.genouest.logol.Logol.generatePreAnalysis(Unknown Source)
at org.irisa.genouest.logol.Logol.analyse(Unknown Source)
at org.irisa.genouest.logol.Logol.execute(Unknown Source)
at org.irisa.genouest.logol.Logol.main(Unknown Source)
INFO org.irisa.genouest.logol.Logol  - Analyse in progress..
WARN org.irisa.genouest.logol.SequenceAnalyser  - Path to suffix search 
tool is not set in system environment. Will try to execute directly but 
may fail if not in PATH of current user
Exception in thread "main" org.irisa.genouest.logol.GrammarException: 
ERROR: Coudld not execute program: Program exited with wrong status code

at org.irisa.genouest.logol.Logol.execute(Unknown Source)
at org.irisa.genouest.logol.Logol.main(Unknown Source)
ERROR org.irisa.genouest.logol.SequenceAnalyser  - Program exited with 
wrong status code: 127

autopkgtest [02:15:33]: test run-unit-test



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1025791: fsck.f2fs is unable to check mounted FS

[Michael Tokarev]

13.12.2022 19:56, Theodore Ts'o wrote:
..


I pushed "mjt" branch yesterday to the repository (without pristine-tar
and upstream pieces so far) which updates f2fs to 1.15 and adds minor
cleanups to d/rules. Please take a look.


Thanks!  The main thing I will note is that it appears that you
checked in f2fs-tools v1.15.0 as a squashed commit.  That is, the
signle commit d0ba994589b5 seems to be a delta between v1.14.0 and
v1.15.0.  What I've done instead is do a git fetch of the upstream git
repo[1] and then performed a "git merge v1.15.0".  This allows the
full upstream git history to be in the debian branch, which makes
future cherry-picks and merges to be easier.


I sure know about git and about upstream repository and about merging
with it. I maintain several packages myself this way, keeping all
upstream history in debian/upstream branch and merging with
debian/master. I especially verified that d/gbp.conf is listing
upstream-vcs-tag and that I do have proper tag fetched from the
upstream repository on git.kernel.org. And only after that I fired
up gbp import-orig --uscan -v, noticing it figured out the right
upstream tag.. It shouldn've done things like this, importing whole
1.15 as a single delta, that's definitely not something which was
intended. It's excellent you've noticed it, - it's definitely a
bug on my side and I yet to see how it ended up like that.
Thank you for spotting this!

(and now this has absolutely nothing to do with #1025791 anyway.. ;))

/mjt

Bug#1026020: python3-starlette: starlette.testclient requires module httpx

[Sandro Tosi]

On Tue, Dec 13, 2022 at 6:09 AM Timo Röhling  wrote:
> Presumbably, this dependency
> has been satisfied indirectly before, but I did not look into it
> further.

httpx is a new dependency with 0.23.1

On Tue, Dec 13, 2022 at 7:33 AM Piotr Ożarowski  wrote:
> httpx is used only in this test file and your package is invoking tests
> so even if we add it to Recommends or Suggests (it definitely will not
> go into Depends) you'll have to add it to ormar's Build-Depends

fully agree with this, you need to adjust ormar b-d packages;
starlette/testclient.py is not exactly part of the API exposed to
users of starlette, altho useful for testing purposes.

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Bug#1026055: lapack breaks openturns autopkgtest: undefined reference to `ztrsyl3_' (and 3 more)

[Paul Gevers]

Source: lapack, openturns
Control: found -1 lapack/3.11.0-2
Control: found -1 openturns/1.20-5
Severity: serious
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainer(s),

With a recent upload of lapack the autopkgtest of openturns fails in 
testing when that autopkgtest is run with the binary packages of lapack 
from unstable. It passes when run with only packages from testing. In 
tabular form:


   passfail
lapack from testing3.11.0-2
openturns  from testing1.20-5
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration of lapack to testing 
[1]. Due to the nature of this issue, I filed this bug report against 
both packages. Can you please investigate the situation and reassign the 
bug to the right package?


More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=lapack

https://ci.debian.net/data/autopkgtest/testing/amd64/o/openturns/29301955/log.gz

/usr/bin/ld: /lib/x86_64-linux-gnu/liblapacke.so.3: undefined reference 
to `ztrsyl3_'
/usr/bin/ld: /lib/x86_64-linux-gnu/liblapacke.so.3: undefined reference 
to `ctrsyl3_'
/usr/bin/ld: /lib/x86_64-linux-gnu/liblapacke.so.3: undefined reference 
to `dtrsyl3_'
/usr/bin/ld: /lib/x86_64-linux-gnu/liblapacke.so.3: undefined reference 
to `strsyl3_'

collect2: error: ld returned 1 exit status
autopkgtest [01:16:06]: test cxx-Ceres-test



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1026035: xen netback broken with 5.10.0-20-amd64 in s-p-u

[Adi Kriegisch]

Dear Diederik,

> > we just upgraded our xen test cluster's kernel to the latest kernel from
> > s-p-u and noticed that network communication is broken. We do have a
> > 'classic' setup with bridges in dom0. After upgrading dom0's kernel, no
> > communication is possible for the domU.
> > 
> > If there is anything we can do to help fixing that issue, we'll gladly do
> > that!
thank you very much for your help!
 
> https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#s4.2.2
>  describes a (relatively simple) way to test a patch.
> 
> I found in current master/6.1 branch 2 commits which may be relevant:
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?
> id=7dfa764e0223a324366a2a1fc056d4d9d4e95491
This patch did the trick; while digging through the source, I noticed that
this fix is already included in the patch for XSA-423[1][2] referenced at
the oss-sec list.
Obviously the patch for XSA-423v1 has been included in 5.10.158-1 while
XSA-423v2 is the most recent version of the patch. The difference between
the two versions of that patch is exactly the initialization of the variable
'err' that just fixes this issue.
 
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?
> id=9e624651859214fb2c4e442b059eba0aefcd0801
This patch does not seem to be necessary as the patch for XSA-424 does
alreay contain a different fix for this issue.

> You'd possibly need to backport it to the 5.10 code, but if you can do that 
> and test whether the updated kernel fixes the issue, that would be great.
Again: thank you very much for the quick response. I can confirm that the
issue is indeed fixed with the first patch; maybe updating to XSA-423v2 is
the more appropriate way to fix the issue.

all the best,
Adi

[1] https://seclists.org/oss-sec/2022/q4/174
[2] https://seclists.org/oss-sec/2022/q4/att-174/xsa423-linux.patch


signature.asc
Description: PGP signature

Bug#1026054: nvme-cli: udev rules files placement

[Daniel Vacek]

Package: nvme-cli
Version: 2.2.1-2
Severity: normal
X-Debbugs-Cc: neel...@gmail.com

Hi,

I believe the udev rules files belong to /lib/udev/rules.d
where all the other ones are instead of just /lib/udev

$ ll /lib/udev/7*
-rw-r--r-- 1 root root 1988 Dec  2 14:50 /lib/udev/70-nvmf-autoconnect.rules
-rw-r--r-- 1 root root  276 Dec  2 14:50 /lib/udev/71-nvmf-iopolicy-
netapp.rules

If I'm wrong, please, disregard this report.

Have a nice day,
Daniel


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

Kernel: Linux 6.0.0-5-rt-amd64 (SMP w/8 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 nvme-cli depends on:
ii  libc6 2.36-6
ii  libjson-c50.16-2
ii  libnvme1  1.2-2
ii  uuid-runtime  2.38.1-4
ii  zlib1g1:1.2.13.dfsg-1

Versions of packages nvme-cli recommends:
ii  pci.ids  0.0~2022.11.30-1

nvme-cli suggests no packages.

-- no debconf information

Bug#1026053: src:ruby-eventmachine: fails to migrate to testing for too long: FTBFS on amd64

[Paul Gevers]

Source: ruby-eventmachine
Version: 1.3~pre20201020-b50c135-6
Severity: serious
Control: close -1 1.3~pre20220315-df4ab006-3
Tags: sid bookworm
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 998097

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:ruby-eventmachine has been trying to 
migrate for 61 days [2]. Hence, I am filing this bug. Your package 
failed to build from source on amd64, already reported in bug 998097.


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=ruby-eventmachine



OpenPGP_signature
Description: OpenPGP digital signature

Bug#944757: endless-sky: please package Endless Sky 0.9.10

[Damyan Ivanov]

A quick update.

The package is more or less ready at 
 (-high-dpi at 
, probably 
needs a bit more work). However, the confusing copyright statements 
issue¹ is a show stopper.

Can you guys do something about it?

 ¹ https://github.com/endless-sky/endless-sky/issues/7711


-- Damyan

Bug#1022170: Update

[Rod Webster]

I have been able to resolve this issue on one PC by building deb files of
the 6.1 kernel from pristine sources from kernel.org with the PREEMPT_RT
patch applied.
The only change I made using xconfig was to enable the fully preemptible
kernel and set the following keys to permit building of the debs.

scripts/config --disable SYSTEM_REVOCATION_KEYS
scripts/config --disable DEBUG_INFO
scripts/config --enable DEBUG_INFO_NONE
scripts/config --set-str SYSTEM_TRUSTED_KEYS ""


Once this kernel and the R8168-dkms driver for my hardware was installed,
the issue appears to be resolved.

I also built Linuxcnc from source on Arch Linux where the issue was not
evident.

These two data points confirm in my mind the Debian implementation of the
Realtek network device drivers is buggy, certainly for the RT image and
probably for the default image.
I believe this will become a major support issue once Bookworm becomes the
stable release.
It would be great if the kernel team could review this and find a
resolution before then.

Rod Webster

VMN®

www.vmn.com.au

Ph: 1300 896 832

Mob: +61 435 765 611

Bug#1026027: graphical installer: using nano in a installer shell fails

[Cyril Brulebois]

Holger Wansing  (2022-12-13):
> I just noticed that nano cannot be used anymore in the installer shell
> (graphical installer):
> 
> - start the installer 
> - choose 'Graphical expert install'
> - 'Execute a shell'
> - call 'nano /etc/fstab'
> ---> Error opening terminal: xterm.
> 
> 
> This works in Bullseye installer, but fails in every bookworm dailies
> I have here (2022-01 - today).
> No problem in text installer.
> 
> Not sure, which package is responsible for this though (is this busybox?)

nano is shipped by nano-udeb, that error seems to come from ncurses
though (https://sources.debian.org/ is wonderful).


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


signature.asc
Description: PGP signature

Bug#1026027: graphical installer: using nano in a installer shell fails

[Philip Hands]

Holger Wansing  writes:

> - start the installer 
> - choose 'Graphical expert install'
> - 'Execute a shell'
> - call 'nano /etc/fstab'
> ---> Error opening terminal: xterm.

That would seem to be because $TERM is set to 'xterm', whereas there's
no terminfo file available for xterm.

Under /lib/terminfo/*/ we have:

  ansi  dumb  linux  screen  vt102

and there's also /usr/share/terminfo/b/bterm

In the F1-F3 consoles it's set to 'linux' (as expected), in the text
installer, TERM is set to 'bterm' -- these work.

So as a workaround, one can set e.g: TERM=bterm and then nano works in
the graphical install's shell.

On the 11.5 netinst I just tried out, in the Graphical Install's shell,
TERM=xterm so that's obviously not the cause of the issue, but the
difference would appear to be that it has:

  /usr/share/vte/termcap-0.0/xterm

So I guess the fix for this is either to make sure that that termcap
file gets installed again, or to set TERM in the Graphical Install's
shell to something like 'bterm' or 'vt102'.

I suspect restoring the termcap file is the correct fix.

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY

Bug#806717: Forwarding email with a long header causes longer than 998 byte lines

[Mikko Tuumanen]

I received an email with a x-ms-exchange-antispam-messagedata-0: header
and I tried to forward it with kmail.

That caused error message:
"The server said: maximum allowed line length is 998 octets, got 1702"

In the original message, the header was split into multiple lines like
this:

x-ms-exchange-antispam-messagedata-0:
 =?iso-8859-1?Q?X9nvzr27qYcmEJpSHcp6K5gWYoBjPRlTmpppdR4VrmwY1cP0Mp4QNB9+kY?=
 =?iso-8859-1?Q?ZWd5EsMdHUa4x0pKA1ObLVns8RuLFV3mCsHlMT31xBfLxra6jZ+p5hbSHx?=


But when the message was forwarded with kmail, the header 
turned into one too long line:

x-ms-exchange-antispam-messagedata-0: lwf7pdVSQS1T...


It seems that kmail has more than one header "fixing" problem.

Bug#1026052: lintian-brush: fixer unused-build-dependency-on-cdbs fails if there is no Build-Depends

[Santiago Vila]

Package: lintian-brush
Version: 0.144

Dear maintainer:

Running lintian-brush on a package not having any Build-Depends at all 
results in a KeyError:


Fixer 'unused-build-dependency-on-cdbs' failed to run.
Script 
/usr/share/lintian-brush/fixers/unused-build-dependency-on-cdbs.py 
failed with exit code: 1

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/lintian_brush/__init__.py", line 
419, in run

exec(code, global_vars)
  File 
"/usr/share/lintian-brush/fixers/unused-build-dependency-on-cdbs.py", 
line 23, in 

if new_depends != updater.source['Build-Depends']:
  File 
"/usr/lib/python3/dist-packages/debian/_deb822_repro/parsing.py", line 
1348, in __getitem__

v = self._paragraph.get_kvpair_element((item, 0))
  File 
"/usr/lib/python3/dist-packages/debian/_deb822_repro/parsing.py", line 
2215, in get_kvpair_element

return self._kvpair_elements[item]
KeyError: 'Build-Depends'


(BTW: The package is "hello-traditional", an example aimed to show the 
sort of things one would have to do if debhelper did not exist, so 
switching to debhelper is not an option).


Thanks.

Bug#997972: haskell-pandoc-citeproc has been deprecated upstream

[Bastian Germann]

Control: retitle -1 RM: haskell-pandoc-citeproc -- RoQA; not needed; upstream 
dead
Control: reassign -1 ftp.debian.org

I have just uploaded the last reverse dependencies pypandoc and pigx-rnaseq 
with changes to get rid of pandoc-citeproc.

Bug#976523: specified Architecture for this package

[YF X]

Hi,

This package seems has no architecture support other than amd64, the 
"LG_QUANTUM" flag
is architecture-specific, and there need upstream to add other architecture 
support.

Maybe we can change this package from "any" to amd64?


Yifan Xu

Bug#1026051: python-pyrdfa: CVE-2022-4396

[Moritz Mühlenhoff]

Source: python-pyrdfa
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerability was published for python-pyrdfa.

CVE-2022-4396[0]:
| ** UNSUPPORTED WHEN ASSIGNED ** A vulnerability was found in RDFlib
| pyrdfa3 and classified as problematic. This issue affects the function
| _get_option of the file pyRdfa/__init__.py. The manipulation leads to
| cross site scripting. The attack may be initiated remotely. The name
| of the patch is ffd1d62dd50d5f4190013b39cedcdfbd81f3ce3e. It is
| recommended to apply a patch to fix this issue. The identifier
| VDB-215249 was assigned to this vulnerability. NOTE: This
| vulnerability only affects products that are no longer supported by
| the maintainer.

https://github.com/RDFLib/pyrdfa3/pull/40
https://github.com/RDFLib/pyrdfa3/commit/ffd1d62dd50d5f4190013b39cedcdfbd81f3ce3e

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2022-4396
https://www.cve.org/CVERecord?id=CVE-2022-4396

Please adjust the affected versions in the BTS as needed.

Bug#1025140: diffutils: define SIGSEGV_FAULT_STACKPOINTER for loongarch

[Santiago Vila]

El 30/11/22 a las 8:54, zhangdandan escribió:

Package: diffutils
Version: 3.8-1
Severity: wishlist
Tags: patch
User: debian-de...@lists.debian.org
Usertags: loongarch64

Dear diffutils maintainers,

     I have defined SIGSEGV_FAULT_STACKPOINTER for loongarch.
     Please consider the patch attached.


Hello. I believe you need a similar change for m4.
Please submit a bug for m4 as well.

Thanks.

Bug#1026050: jquery-minicolors: CVE-2021-4243

[Moritz Mühlenhoff]

Source: jquery-minicolors
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerability was published for jquery-minicolors.

CVE-2021-4243[0]:
| A vulnerability was found in claviska jquery-minicolors up to 2.3.5.
| It has been rated as problematic. Affected by this issue is some
| unknown functionality of the file jquery.minicolors.js. The
| manipulation leads to cross site scripting. The attack may be launched
| remotely. Upgrading to version 2.3.6 is able to address this issue.
| The name of the patch is ef134824a7f4110ada53ea6c173111a4fa2f48f3. It
| is recommended to upgrade the affected component. VDB-215306 is the
| identifier assigned to this vulnerability.

https://github.com/claviska/jquery-minicolors/releases/tag/2.3.6
https://github.com/claviska/jquery-minicolors/commit/ef134824a7f4110ada53ea6c173111a4fa2f48f3

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2021-4243
https://www.cve.org/CVERecord?id=CVE-2021-4243

Please adjust the affected versions in the BTS as needed.

Bug#1026049: tracker.debian.org: package information out of date on numerous packages

[Vagrant Cascadian]

Package: tracker.debian.org
Severity: normal
X-Debbugs-Cc: Vagrant Cascadian 

I've recently noticed numerous package page information is out of date
for well over 24+ hours, for example:

  https://tracker.debian.org/pkg/guix

Shows an upload of 1.4.0~rc2-1 to unstable on 2022-12-11 in the "news"
section, but "versions" only lists 1.3.0-5 for unstable.

Sometimes this happens and I'd just sleep on it and it sorts itself out
by morning, but I've done that two nights in a row to no effect. :)


Similarly:

  https://tracker.debian.org/pkg/guile-gcrypt
  https://tracker.debian.org/pkg/guile-json
  https://tracker.debian.org/pkg/guile-ssh

"news" lists it as having migrated to testing, "versions" does not show
it in testing, and "testing migrations" lists it as 3 of 5 days old.

And for good measure:

  https://tracker.debian.org/pkg/u-boot-menu

Has a handful of discrepancies, e.g. "news" sees updates, the rest of
tracker does not reflect the changes...


I have definitely come to rely on the hugely useful tracker.debian.org
service, so a correspondingly huge thanks for maintaining it!


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1026048: redmine: CVE-2022-44030 CVE-2022-44637 CVE-2022-44031

[Moritz Mühlenhoff]

Source: redmine
X-Debbugs-CC: t...@security.debian.org
Severity: grave
Tags: security

Hi,

The following vulnerabilities were published for redmine.

CVE-2022-44030[0]:
| Redmine 5.x before 5.0.4 allows downloading of file attachments of any
| Issue or any Wiki page due to insufficient permission checks.
| Depending on the configuration, this may require login as a registered
| user.

https://www.redmine.org/projects/redmine/wiki/Security_Advisories

CVE-2022-44637[1]:
| Redmine before 4.2.9 and 5.0.x before 5.0.4 allows persistent XSS in
| its Textile formatter due to improper sanitization in Redcloth3
| Textile-formatted fields. Depending on the configuration, this may
| require login as a registered user.

https://www.redmine.org/projects/redmine/wiki/Security_Advisories

CVE-2022-44031[2]:
| Redmine before 4.2.9 and 5.0.x before 5.0.4 allows persistent XSS in
| its Textile formatter due to improper sanitization of the blockquote
| syntax in Textile-formatted fields.

https://www.redmine.org/projects/redmine/wiki/Security_Advisories

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2022-44030
https://www.cve.org/CVERecord?id=CVE-2022-44030
[1] https://security-tracker.debian.org/tracker/CVE-2022-44637
https://www.cve.org/CVERecord?id=CVE-2022-44637
[2] https://security-tracker.debian.org/tracker/CVE-2022-44031
https://www.cve.org/CVERecord?id=CVE-2022-44031

Please adjust the affected versions in the BTS as needed.

Bug#1025788: transition: numpy

[Graham Inggs]

Hi Sandro

On Mon, 12 Dec 2022 at 23:27, Sandro Tosi  wrote:
> thanks, numpy/1.23.5-2 has just been uploaded to unstable.

\o/

> thanks! on the same line, i'm planning on upgrading matplotlib
> (another foundation package) from 3.5.x in unstable to 3.6.x (latest
> upstream release). Do you want me to submit a transition bug report
> when ready?

Yes please.  Filing it now would be even better, then additional
information e.g. ETA, links to autopkgtest results, etc. can be added
as it becomes available.

Regards
Graham

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

[Soren Stoutner]

Agustin,

On Tuesday, December 13, 2022 11:14:22 AM MST Agustin Martin wrote:
> I modified installdeb-myspell to look for both, with qt6 version
> preferred. In policy document, I commented about qt5 version
> existence, but discouraging its use as it will disappear sooner. In
> theory it could be useful for stable backports, but since .bdic sid
> version should be usable unchanged in stable there is no real use for
> it.

Your script does make it easier for packages to automatically migrate to the 
current qwebengine_convert_dict location on Qt migrations.  However, without a 
meta package or an unversioned package each Hunspell dictionary source package 
would need to update their build-depends.

This may not be too big a deal as Qt doesn’t switch versions often.  However, 
it seems to me that the ideal would be to have a stable build-depends package 
and even a stable binary execution path for those who either choose not to use 
the provided script or who cannot because they need to modify the files first 
to 
work around the current bugs with qwebengine_convert_dict not supporting 
certain valid input files.

> $ /usr/lib/qt6/libexec/qwebengine_convert_dict
> Usage: qwebengine_convert_dict  
> 
> Just put what usage note and associated example shows, it is supposed
> to be more "stable". Noticed that qwebengine_convert_dict seems to
> accept any of both (and look for the other). In theory, a dic file may
> have no associated aff file (and be a plain wordlist), but just
> checked that even that requires an empty aff file.

Good catch.  For some reason I thought the documentation said to use the .aff 
file, but I see now that it was just working around my not using it 
idiomatically.


-- 
Soren Stoutner
so...@stoutner.com

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

Bug#1026047: pigx-rnaseq: NMU: Drop citeproc dependency

[Bastian Germann]

Package: pigx-rnaseq
Version: 0.1.0-1
Severity: important
Tags: patch

The package will not migrate because it historically has a dependency on pandoc-citeproc which is no longer necessary to 
build or run. A debdiff is attached. I am uploading a LowNMU based on it.diff -Nru pigx-rnaseq-0.1.0/debian/changelog pigx-rnaseq-0.1.0/debian/changelog
--- pigx-rnaseq-0.1.0/debian/changelog  2022-07-21 17:52:09.0 +0200
+++ pigx-rnaseq-0.1.0/debian/changelog  2022-12-13 19:23:15.0 +0100
@@ -1,3 +1,10 @@
+pigx-rnaseq (0.1.0-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop citeproc dependency (no longer required).
+
+ -- Bastian Germann   Tue, 13 Dec 2022 18:23:15 +
+
 pigx-rnaseq (0.1.0-1) unstable; urgency=medium
 
   * Team upload.
diff -Nru pigx-rnaseq-0.1.0/debian/control pigx-rnaseq-0.1.0/debian/control
--- pigx-rnaseq-0.1.0/debian/control2022-07-21 17:52:09.0 +0200
+++ pigx-rnaseq-0.1.0/debian/control2022-12-13 19:23:15.0 +0100
@@ -12,7 +12,6 @@
libjs-jquery-tablesorter ,
megadepth,
multiqc,
-   pandoc-citeproc,
python3-all,
python3-deeptools,
python3-htseq,
@@ -56,7 +55,6 @@
  libjs-jquery-tablesorter,
  megadepth,
  multiqc,
- pandoc-citeproc,
  python3:any,
  python3-deeptools,
  python3-htseq,

Bug#1026046: FTBFS: test failures on some architectures

[gregor herrmann]

Source: libdevel-mat-perl
Version: 0.49-1
Severity: important
Tags: upstream
Forwarded: https://rt.cpan.org/Ticket/Display.html?id=134117

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

According to https://buildd.debian.org/status/package.php?p=libdevel-mat-perl
the package has a test failure on at least i386 and mipsel64el but
maybe the architectures are just random.

There's also an upstream issue:
https://rt.cpan.org/Ticket/Display.html?id=134117

And failures on CPAN testers:
http://matrix.cpantesters.org/?dist=Devel-MAT+0.49


Can't call method "_more_saved" on an undefined value at 
/tmp/loop_over_bdir-419118-EAl5mw/Devel-MAT-0.49-0/blib/lib/Devel/MAT/Dumpfile.pm
 line 516.
t/02contexts.t ... 
Dubious, test returned 255 (wstat 65280, 0xff00)
No subtests run 

Cheers,
gregor

-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEE0eExbpOnYKgQTYX6uzpoAYZJqgYFAmOYxYpfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEQx
RTEzMTZFOTNBNzYwQTgxMDREODVGQUJCM0E2ODAxODY0OUFBMDYACgkQuzpoAYZJ
qgZcZA//SA59AIkGQjYT5VXZfjSVE3DNBz8dFpA47iTHqUH5ftP8xxd4FWo/lhxq
oT9gDUtm5EIDLhshJvanve87OeVSPhXbe6yOB2MZC8wAQCvp8HGgUSNffiL2kKsC
KZBaiRM36f9ZRxDGoTMfqAC8IrVX5t8UW/TA3+UnYCVpDIOpODSyZL7Prgvzejpy
cwLdTUVc1Jq8cS/0vrFk0MY+GbYAB3PXebdpn4glEsZOFJTvF4iQpmNA4i/e0j7S
ePnL+P+EdUkc+OVPLuoXweFnvh2d91/uEIW4qeQn3aZ/UfvvSSaS2t+3Xrvpqx11
YaVCWS19/PQYTX2kYma78PRsGUAEkRmenZlcz0p2EE9JyUfbL27XQOhIO/GZl2+z
d4yp7BL0eQK+h6rqoGzAm+FBWPxlIQaoI2epPK7r30zrlHJ+6RWdPn5P1QgYqT69
r12IbVCgc9VcId6DfUtT3oxdLjJBvEE/yEBA4qi9Lu7TB35rPHf4mbUKjUOrYmt1
kauvdo/DiGcxicJChzY0vjDJySAn5llmzzGMS32/OcC9sfvc83wpWMnoL/OkLmGx
B7EEjg6IJRwRHGSSQgTnCCLLXZlW5fINXvxzwacFI3goCb5w7MX+TEKOvD7r1t6e
UDFMTzSDB3u0/jdhwsRREdx10WRDVdkEeYoEzNgcmTLplauSQbA=
=uyZh
-END PGP SIGNATURE-

Bug#1024757: Editor: -key ignored

[Kristian Nielsen]

The root cause of this problem with openscad is this upstream bug in Qt:

  https://bugreports.qt.io/browse/QTBUG-95108

The symptoms are that in some keyboard layouts, the Qt::GroupSwitchModifier
is handled incorrectly, causing some keys to not respond correctly in
certain applications.

This bug was introduced in Qt 5.15.5, and has been fixed in Qt 5.15.7.

The bug can be reproduced by temporarily switching layout:

  setxkbmap -model pc105 -layout de -variant neo

and starting the "openscad" program; in the editor, the  does not
work.

I verified that installing libqt5gui5 version 5.15.7+dfsg-1+b1 from
experimental fixes the problem.

So this bug can be closed when Qt 5.15.7 goes into unstable.

 - Kristian.

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

[Agustin Martin]

El mar, 13 dic 2022 a las 18:43, Soren Stoutner () escribió:
>
> Can one of the Debian Qt/KDE maintainers weigh in on the feasibility of 
> either creating a meta package that depends on the most recent package that 
> includes qwebengine_convert_dict or creating an unversioned package that 
> installs qwebengine_convert_dict?  Also, either having 
> qwebengine_convert_dict being installed in an unversioned location or having 
> a symlink that is unversioned?  That would make it easier for Hunspell 
> language packages to build-depend on qwebengine_convert_dict and wouldn’t 
> require reworking all of those packages’ build scripts every time the version 
> of Qt in Debian changes.

I modified installdeb-myspell to look for both, with qt6 version
preferred. In policy document, I commented about qt5 version
existence, but discouraging its use as it will disappear sooner. In
theory it could be useful for stable backports, but since .bdic sid
version should be usable unchanged in stable there is no real use for
it.

> Regarding qwebengine_convert_dict expecting the .dic as a file entry, I am 
> not certain I understand what you are referring to.  This is how it builds on 
> my Debian testing system.  The .dic file must be in the same directory as the 
> .aff, but it isn’t specified (or at least doesn’t need to be specified) as a 
> file entry.

$ /usr/lib/qt6/libexec/qwebengine_convert_dict
Usage: qwebengine_convert_dict  

Just put what usage note and associated example shows, it is supposed
to be more "stable". Noticed that qwebengine_convert_dict seems to
accept any of both (and look for the other). In theory, a dic file may
have no associated aff file (and be a plain wordlist), but just
checked that even that requires an empty aff file.

-- 
Agustin

Bug#1026045: Pointer truncation issue in DLOPEN_LOCAL_SCAN patch

[Florian Weimer]

Package: exim4
Version: 4.96-9

We are trying to port Fedora to a more modern variant of C.

  
  

This tripped up our Exim builds, and I see the same warning in the Exim
builds for Debian.  This patch should fix it:

diff --git a/src/local_scan.c b/src/local_scan.c
index 6ea5d2db841dbf19..42fbe79d02d9e9f5 100644
--- a/src/local_scan.c
+++ b/src/local_scan.c
@@ -14,6 +14,7 @@ extern uschar *local_scan_path;/* Path to 
local_scan() library */
 
 #ifdef DLOPEN_LOCAL_SCAN
 #include 
+#include 
 static int (*local_scan_fn)(int fd, uschar **return_text) = NULL;
 static int load_local_scan_library(void);
 #endif

As I said on the Fedora bug

  exim: pointer truncation bug in downstream-only
  exim-4.96-dlopen-localscan.patch patch
  

I think it's harmless because it only happens in case of a configuration
problem, but I'd thought to file this bug nevertheless.

Thanks,
Florian

Bug#990560: Error message "Value too large for defined data type"

[Helge Deller]

tag: hppa, lfs, patch

This bug usually indicates that a 32-bit application uses
functions like readdir() which (by default on a 32bit platform)
can only handle 32-bit values for inode numbers.
You can overcome that issue by recompiling the code while providing
"-D_FILE_OFFSET_BITS=64" on the gcc command line.

In this specific case I suggest to add the "future=+lfs" option
to debian/rules  like this (copy/pasted here - may not apply cleanly but you 
get the idea):

--- debian/rules   2022-12-13 17:30:09.631676544 +
+++ debian/rules.org   2022-12-13 17:56:43.086922122 +
@@ -14,9 +14,9 @@

 # Workaround an issue with PIC/PIE on certain architectures (c.f., #942798)
 ifneq (,$(filter x32,$(DEB_HOST_ARCH)))
+  DEB_BUILD_MAINT_OPTIONS=hardening=+all,-pie future=+lfs
-  DEB_BUILD_MAINT_OPTIONS=hardening=+all,-pie
 else
+  DEB_BUILD_MAINT_OPTIONS=hardening=+all future=+lfs
-  DEB_BUILD_MAINT_OPTIONS=hardening=+all
 endif

This option enables large file support (LFS) generally. On 64-bit
platforms the aove future-flag is a no-op.

By the way, I think you couldn't reproduce the issue on i386, because
you probably didn't used a huge hard disc there. The issue only arises
sometimes if the searched/read file is above the 32-bit boundary on disc.

Dear subversion maintainers:
Please add the future option.

(I noticed that bug too, because for me "git" package failed to compile,
because it uses subversions in it's tests and subversion there ran into
this "Value too large" problem.)

Helge

Bug#1026044: libodsstream-dev: FTBFS for other packages

[GCS]

Source: libodsstream
Version: 0.9.0-1
Severity: serious
Justification: breaks unrelated software
Usertags: tiff4_5
Tags: sid bookworm ftbfs
Control: affects -1 src:beads

Hi,

During a rebuild of beads I realised it fails to build due to:
[ 64%] Building CXX object src/CMakeFiles/beads.dir/beads.cpp.o
cd beads-1.1.20/obj-x86_64-linux-gnu/src && /usr/bin/c++ -DQT_CORE_LIB
-DQT_GUI_LIB -DQT_NO_DEBUG -DQT_XML_LIB
-I"beads-1.1.20/src/\$beads-1.1.20/src/cimg"
-I/usr/include/include/libpng -I/usr/lib/x86_64-linux-gnu
-Ibeads-1.1.20/src/cimg -isystem /usr/include/odsstream -isystem
/usr/include/x86_64-linux-gnu/qt5 -isystem
/usr/include/x86_64-linux-gnu/qt5/QtCore -isystem
/usr/lib/x86_64-linux-gnu/qt5/mkspecs/linux-g++ -isystem
/usr/include/x86_64-linux-gnu/qt5/QtGui -isystem
/usr/include/x86_64-linux-gnu/qt5/QtXml -g -O2
-ffile-prefix-map=beads-1.1.20=. -fstack-protector-strong -Wformat
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2
-Dcimg_use_tiff -Dcimg_use_jpeg -Dcimg_use_zlib -Dcimg_use_png
-Dcimg_use_tiff -Dcimg_use_jpeg -Dcimg_use_zlib -Dcimg_use_png   -fPIC
-std=gnu++17 -MD -MT src/CMakeFiles/beads.dir/beads.cpp.o -MF
CMakeFiles/beads.dir/beads.cpp.o.d -o CMakeFiles/beads.dir/beads.cpp.o
-c beads-1.1.20/src/beads.cpp
[...]
In file included from beads-1.1.20/src/beads.cpp:22:
/usr/include/odsstream/odsdocwriter.h:26:10: fatal error:
quazip/quazip.h: No such file or directory
   26 | #include 
  |  ^
compilation terminated.

Quick check shows your package build depends on libquazip1-qt6-dev and
indeed it uses that headers and libraries. But your libodsstream-dev
package doesn't pull in that library development package to build with
for other packages.
Then the include will still fail due to using quazip/quazip.h as the
include path when it's QuaZip-Qt6-1.3/quazip/quazip.h (i.e. one more
directory deep).

Regards,
Laszlo/GCS
[1] 
https://salsa.debian.org/debichem-team/libodsstream/-/blob/master/debian/control#L11

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

[Fabian Grünbichler]

> Peter Green  hat am 13.12.2022 18:04 CET geschrieben:
> 
>  
> Sylvestre Ledru wrote:
> > clap should be updated to 4. I just didn't find the time to do it (if you 
> > want to give it a try ;)
> 
> I just took a look at this.
> 
> The new version of clap depends on new versions of clap_derive and clap_lex,
> the old version of clap builds fine with it's dependency on clap_lex bumped,
> but the same cannot be said for bumping clap_derive.
> 
> Possible ways forward.
> 
> 1. Package clap 4 without the derive feature, I think such a package would
> be of very limited utility.
> 2. Introduce a clat-derive-3 package.
> 3. Disable the derive feature in clap-3 and port the packages that use it
> to clap 4.
> 
> If my grepping is accurate I belive the following packages use the derive
> feature of clap 3 and would need to be ported.
> 
> Package: precious
> Package: rsass
> Package: rust-alacritty
> Package: rust-bkt
> Package: rust-cargo-c
> Package: rust-debcargo

debcargo always uses the same clap version as cargo (since it uses cargo as lib 
crate, and obviously we want to avoid a duplicate version in the dep tree). it 
seems 0.67 (to be released in two days together with rustc 1.66, on 2022-12-15) 
will upgrade to 0.4, so if we want to get that in we'd need clap 4.x packaged 
anyhow, but if we want to stay at 0.63 (current bookworm/sid version) or 0.66 
(current upstream release, I've prepared an update together with noctis, but 
not pushed it yet) we likely want clap 3.x with derive support in bookworm..

> Package: rust-filespooler
> Package: rust-resource-proof
> Package: rust-sequoia-sq
> Package: rust-tre-command
> 
> P.S. Jonas, I see you tagged this bug as affecting precious, but
> when I look at precious upstream it still seems to depend on clap 3

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

[Sebastian Andrzej Siewior]

On 2022-12-12 22:45:57 [-0500], Scott Kitterman wrote:
> 
> That doesn't sound too bad.  I'll see if I can find some time to work on the 
> split, but probably not until Wednesday or Friday.

So I managed to tell cmake to use the tfm library instead of the bundled
code and the testsuite fails now but I think this is due to the limit
in "our" libtfm. I noticed libclammspack/libclammspack.so which appears
to be the libmspack and I hope that this is a typo somewhere and we can
exclude the bundled library.

Then I had to throw up a little. It might me be nothing and I'm just
stupid and don't know things but there is a lot of rust code in
libclamav_rust/.cargo/vendor/

and it appears to me that they bundled a bunch of rust libraries. It
*might* be enough to just install librust-jpeg-decoder-dev as
dependency and then libclamav_rust/.cargo/vendor/jpeg-decoder will be
ignored but I just wanted point that out. I don't have any rust skills
at this time.

> Scott K

Sebastian

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

[Jonas Smedegaard]

Contol: retitle -1 rust-clap: please upgrade to v4

Quoting Peter Green (2022-12-13 18:04:28)
> If my grepping is accurate I belive the following packages use the derive
> feature of clap 3 and would need to be ported.
> 
> Package: precious
> Package: rsass
> Package: rust-alacritty
> Package: rust-bkt
> Package: rust-cargo-c
> Package: rust-debcargo
> Package: rust-filespooler
> Package: rust-resource-proof
> Package: rust-sequoia-sq
> Package: rust-tre-command
> 
> P.S. Jonas, I see you tagged this bug as affecting precious, but
> when I look at precious upstream it still seems to depend on clap 3

precious and rsass both have an upstream pending patch, and is expected
to switch to clap v4 with next upstream release.

rust-resource-proof use clap only for an example script not installed as
part of the Debian packaging, so should be relatively easy to patch
away.

 - Jonas

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

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

signature.asc
Description: signature

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

[Soren Stoutner]

Agustin,

You are correct that there are currently two copies in Debian, one that comes 
with the Qt 5 
packages and the other that comes with the Qt 6 packages.

Can one of the Debian Qt/KDE maintainers weigh in on the feasibility of either 
creating a 
meta package that depends on the most recent package that includes 
qwebengine_convert_dict or creating an unversioned package that installs 
qwebengine_convert_dict?  Also, either having qwebengine_convert_dict being 
installed in 
an unversioned location or having a symlink that is unversioned?  That would 
make it easier 
for Hunspell language packages to build-depend on qwebengine_convert_dict and 
wouldn’t 
require reworking all of those packages’ build scripts every time the version 
of Qt in Debian 
changes.

Regarding qwebengine_convert_dict expecting the .dic as a file entry, I am not 
certain I 
understand what you are referring to.  This is how it builds on my Debian 
testing system.  
The .dic file must be in the same directory as the .aff, but it isn’t specified 
(or at least doesn’t 
need to be specified) as a file entry.

$ /usr/lib/qt5/bin/qwebengine_convert_dict en_US.aff en_US.bdic
en_US.dic_delta not found.
Reading en_US.aff
Reading en_US.dic
Serializing...
Verifying...
Writing en_US.bdic
Success. Dictionary converted.

On Tuesday, December 13, 2022 1:52:20 AM MST Agustin Martin 
() wrote:
>> Note that Debian has a different path for qwebengine_convert_dict
>> (/usr/lib/qt5/bin/qwebengine_convert_dict) and that it expects .dic
>> file as entry, Fixed.
>
>Just noticed that it is also in package and path you set, there are
>two possibilities. Expect new dictionaries-common package soon.

-- 
Soren Stoutner
so...@stoutner.com


[1] mailto:agmar...@debian.org


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

Bug#1026043: ITP: ruby-faraday-multipart -- Perform multipart-post requests using Faraday

[Vinay]

package: wnpp
Severity: wishlist
Owner: Vinay Keshava

*Package Name  : ruby-faraday-multipart
 Version   : 1.0.4
 Upstream Author   : The Faraday Team
*URL   :https://github.com/lostisland/faraday-multipart
*License   : Expat
 Programming Lang  : Ruby
*Description   : Perform multipart-post requests using Faraday

 Multipart middleware converts a Faraday::Request#body Hash
 of key/value pairs into a multipart form request
.

This gem is required for the ruby-acme-client for Faraday 2.0 transition

- Vinay Keshava

Bug#1026042: trx: License is incompatible with that of up-coming ortp 5.2.0

[Dennis Filder]

Source: trx
Version: 0.5-4
Severity: important

With the recently released version 5.2 ortp has been relicensed to GNU
AGPL-3+.  Since your package is GPL-2 it is my understanding that it
may not link in ortp 5.2 until it is relicensed to either GPL-3 or
AGPL-3.

Please consult with the upstream developer whether they are open to
relicensing.  If they aren't you face the decision of whether to
maintain a fork of an older license-compatible version of ortp, remove
trx from Debian or work around this in some other way.  Ask on
debian-legal if you have questions about the details of license
compatibility and how to best handle this.

I may raise the severity to serious at some point as this may actually
be an RC bug.

Regards.

P.S.: I'm not subscribed to this bug, so CC me in every message I
should see.

Bug#1021686: zxing-cpp: FTBFS: error: static assertion failed: Cannot format an argument.

[Dennis Filder]

Control: tags -1 fixed-upstream

Upstream commit 3872abbb33ebb8d6c891baff33778aae04f0c546 fixes this for me[0].

Please upload a zxing-cpp 1.4.0 soon -- I need it in mediastreamer2
5.2 for linphone-desktop 5.0, and I'd rather not have to port back to
1.2 as the API has changed quite a bit since.

Regards.

(I'm not subscribed to this bug, so CC me in replies I should see.)

0: 
https://github.com/zxing-cpp/zxing-cpp/commit/3872abbb33ebb8d6c891baff33778aae04f0c546

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

[Peter Green]

Sylvestre Ledru wrote:

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


I just took a look at this.

The new version of clap depends on new versions of clap_derive and clap_lex,
the old version of clap builds fine with it's dependency on clap_lex bumped,
but the same cannot be said for bumping clap_derive.

Possible ways forward.

1. Package clap 4 without the derive feature, I think such a package would
   be of very limited utility.
2. Introduce a clat-derive-3 package.
3. Disable the derive feature in clap-3 and port the packages that use it
   to clap 4.

If my grepping is accurate I belive the following packages use the derive
feature of clap 3 and would need to be ported.

Package: precious
Package: rsass
Package: rust-alacritty
Package: rust-bkt
Package: rust-cargo-c
Package: rust-debcargo
Package: rust-filespooler
Package: rust-resource-proof
Package: rust-sequoia-sq
Package: rust-tre-command

P.S. Jonas, I see you tagged this bug as affecting precious, but
when I look at precious upstream it still seems to depend on clap 3

Bug#1026041: h5py: reduce Build-Depends

[Helmut Grohne]

Source: h5py
Version: 3.7.0-3
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability

h5py has lots of Build-Depends of which quite many pose issues to cross
compilation. It turns out that a fair number of them are easily
droppable. A first observation is that the documentation is already
split to an Arch:all -doc package and sphinx is only run during an
binary-indep build. Moving all of the sphinx dependencies to B-D-I means
that they become irrelevant to cross building. Only the clean target
needd a small modification to make that work. In a similar vein,
 annotated dependencies become irrelevant to cross building
and that turns out to work for pytest. Another issue is python3-all-dev.
It has to be rewritten as python3-all-dev:any + libpython3-all-dev. I'm
attaching a patch for your convenience. I couldn't resist also replacing
hard coded pkg-config calls and hope this is acceptable as well.

Helmut
diff --minimal -Nru h5py-3.7.0/debian/changelog h5py-3.7.0/debian/changelog
--- h5py-3.7.0/debian/changelog 2022-11-14 17:45:49.0 +0100
+++ h5py-3.7.0/debian/changelog 2022-12-13 17:44:24.0 +0100
@@ -1,3 +1,16 @@
+h5py (3.7.0-3.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Reduce Build-Depends: (Closes: #-1)
++ Declaratively request debhelper addons.
++ Clean docs without requiring sphinx.
++ Move sphinx dependencies to B-D-I.
++ Annotate pytest dependencies .
++ Multiarchify python Build-Depends.
+  * Don't hard code the build architecture pkg-config.
+
+ -- Helmut Grohne   Tue, 13 Dec 2022 17:44:24 +0100
+
 h5py (3.7.0-3) unstable; urgency=medium
 
   * Team upload.
diff --minimal -Nru h5py-3.7.0/debian/control h5py-3.7.0/debian/control
--- h5py-3.7.0/debian/control   2022-11-14 17:45:49.0 +0100
+++ h5py-3.7.0/debian/control   2022-12-13 16:42:51.0 +0100
@@ -6,25 +6,28 @@
 Priority: optional
 Build-Depends: cython3 (>= 0.29.15),
debhelper-compat (= 13),
-   dh-python,
+   dh-sequence-python3,
pybuild-plugin-pyproject,
dpkg-dev (>= 1.17.14),
libhdf5-dev,
libhdf5-mpi-dev (>= 1.10.6+repack-1),
-   libjs-mathjax,
liblzf-dev,
+   libpython3-all-dev,
mpi-default-dev,
pkg-config,
-   python3-all-dev,
+   python3-all-dev:any,
python3-cached-property,
python3-mpi4py (>= 3.0.3),
python3-numpy (>= 1.19.3),
python3-pkgconfig,
-   python3-pytest,
-   python3-pytest-mpi,
+   python3-pytest ,
+   python3-pytest-mpi ,
python3-setuptools,
python3-six,
python3-unittest2,
+Build-Depends-Indep:
+   dh-sequence-sphinxdoc ,
+   libjs-mathjax,
python3-sphinx 
 Standards-Version: 4.6.1
 Vcs-Browser: https://salsa.debian.org/science-team/h5py
diff --minimal -Nru h5py-3.7.0/debian/rules h5py-3.7.0/debian/rules
--- h5py-3.7.0/debian/rules 2022-11-14 17:45:49.0 +0100
+++ h5py-3.7.0/debian/rules 2022-12-13 16:29:57.0 +0100
@@ -4,6 +4,7 @@
 #export DH_VERBOSE = 1
 
 include /usr/share/dpkg/buildflags.mk
+include /usr/share/dpkg/buildtools.mk
 
 export DEB_BUILD_MAINT_OPTIONS = hardening=+all
 
@@ -23,7 +24,7 @@
 export OMPI_MCA_rmaps_base_oversubscribe=1
 
 %:
-   dh $@ --with python3,sphinxdoc --buildsystem=pybuild
+   dh $@ --buildsystem=pybuild
 
 override_dh_clean:
dh_clean
@@ -32,10 +33,7 @@
 override_dh_auto_clean:
dh_auto_clean -D $(BUILD_DIR_SERIAL) || /bin/true
dh_auto_clean -D $(BUILD_DIR_MPI) || /bin/true
-ifeq (,$(filter nodoc,$(DEB_BUILD_OPTIONS)))
-   $(MAKE) -C docs clean
-   $(MAKE) -C docs_api clean
-endif
+   rm -Rf docs/_build docs_api/_build
 
 override_dh_auto_configure:
mkdir $(BUILD_DIR_SERIAL); bash -O extglob -c "cp -ra 
./!($(BUILD_DIR_SERIAL)) $(BUILD_DIR_SERIAL)"
@@ -66,7 +64,7 @@
for DIR in $$(find .pybuild/cpython3*mpi -name build); do \
cp -r $(CURDIR)/debian/wrapper_module/h5py/* $$DIR/h5py/; \
done
-   cd $(BUILD_DIR_MPI)/lzf; $(CC) $(CPPFLAGS) $(CFLAGS) $(LDFLAGS) $(shell 
pkg-config --cflags --libs hdf5-mpi liblzf) -fPIC -shared lzf_filter.c -o 
liblzf_filter.so
+   cd $(BUILD_DIR_MPI)/lzf; $(CC) $(CPPFLAGS) $(CFLAGS) $(LDFLAGS) $(shell 
$(PKG_CONFIG) --cflags --libs hdf5-mpi liblzf) -fPIC -shared lzf_filter.c -o 
liblzf_filter.so
 
 # build serial build only for arch builds
 execute_after_dh_auto_build-arch: export http_proxy=127.0.0.1:9
@@ -76,7 +74,7 @@
for DIR in $$(find .pybuild/cpython3*serial -name build); do \
cp -r $(CURDIR)/debian/wrapper_module/h5py/* $$DIR/h5py/; \
done
-   cd $(BUILD_DIR_SERIAL)/lzf; $(CC) $(CPPFLAGS) $(CFLAGS) $(LDFLAGS) 
$(shell pkg-con

Bug#1026040: pdftoipe: Fix build with Poppler >= 22.09

[Nathan Pratta Teodosio]

Package: pdftoipe
Severity: wishlist
Tags: patch
X-Debbugs-Cc: nathan.teodo...@canonical.com

Hi, ipe-tools fails to build with Poppler 22.09.

The attached patch fixes the build (log available at [1]).

[1]: https://launchpad.net/~nteodosio/+archive/ubuntu/poppler/+build/24935610
diff -Nru ipe-tools-7.2.24.1/debian/changelog 
ipe-tools-7.2.24.1/debian/changelog
--- ipe-tools-7.2.24.1/debian/changelog 2022-10-16 21:05:46.0 -0300
+++ ipe-tools-7.2.24.1/debian/changelog 2022-12-13 13:45:51.0 -0300
@@ -1,3 +1,9 @@
+ipe-tools (1:7.2.24.1-3) unstable; urgency=medium
+
+  * Add patch to fix build with poppler 22.09.
+
+ -- Nathan Pratta Teodosio   Tue, 13 Dec 2022 
13:45:51 -0300
+
 ipe-tools (1:7.2.24.1-2) unstable; urgency=medium
 
   [ Sam Q ]
diff -Nru ipe-tools-7.2.24.1/debian/patches/build-with-poppler-22.09.patch 
ipe-tools-7.2.24.1/debian/patches/build-with-poppler-22.09.patch
--- ipe-tools-7.2.24.1/debian/patches/build-with-poppler-22.09.patch
1969-12-31 21:00:00.0 -0300
+++ ipe-tools-7.2.24.1/debian/patches/build-with-poppler-22.09.patch
2022-12-13 13:42:16.0 -0300
@@ -0,0 +1,33 @@
+From: Jonathan Chang 
+Date: Wed, 23 Nov 2022 16:22:50 -0800
+Subject: [PATCH] pdftoipe: fix for poppler >= 2.09
+Origin: https://github.com/otfried/ipe-tools/pull/55.patch
+
+---
+ pdftoipe/xmloutputdev.cpp | 8 
+ 1 file changed, 4 insertions(+), 4 deletions(-)
+
+diff --git a/pdftoipe/xmloutputdev.cpp b/pdftoipe/xmloutputdev.cpp
+index 291eb5f..17bac2a 100644
+--- a/pdftoipe/xmloutputdev.cpp
 b/pdftoipe/xmloutputdev.cpp
+@@ -149,15 +149,15 @@ void XmlOutputDev::stroke(GfxState *state)
+   writeColor("getTransformedLineWidth());
+ 
+-  double *dash;
+   double start;
+-  int length, i;
++  std::vector dash = state->getLineDash(&start);
++  int length = dash.size();
++  int i;
+ 
+-  state->getLineDash(&dash, &length, &start);
+   if (length) {
+ writePS(" dash=\"[");
+ for (i = 0; i < length; ++i)
+-  writePSFmt("%g%s", state->transformWidth(dash[i]), 
++  writePSFmt("%g%s", state->transformWidth(dash.at(i)),
+(i == length-1) ? "" : " ");
+ writePSFmt("] %g\"", state->transformWidth(start));
+   }
diff -Nru ipe-tools-7.2.24.1/debian/patches/series 
ipe-tools-7.2.24.1/debian/patches/series
--- ipe-tools-7.2.24.1/debian/patches/series2022-10-16 21:05:46.0 
-0300
+++ ipe-tools-7.2.24.1/debian/patches/series2022-12-13 13:45:51.0 
-0300
@@ -1,2 +1,3 @@
 build-with-poppler-22.03.patch
+build-with-poppler-22.09.patch
 cross.patch

Bug#1025791: fsck.f2fs is unable to check mounted FS

[Theodore Ts'o]

On Mon, Dec 12, 2022 at 09:41:38AM +0300, Michael Tokarev wrote:
> 
> I pushed "mjt" branch yesterday to the repository (without pristine-tar
> and upstream pieces so far) which updates f2fs to 1.15 and adds minor
> cleanups to d/rules. Please take a look.

Thanks!  The main thing I will note is that it appears that you
checked in f2fs-tools v1.15.0 as a squashed commit.  That is, the
signle commit d0ba994589b5 seems to be a delta between v1.14.0 and
v1.15.0.  What I've done instead is do a git fetch of the upstream git
repo[1] and then performed a "git merge v1.15.0".  This allows the
full upstream git history to be in the debian branch, which makes
future cherry-picks and merges to be easier.  

[1] git://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs-tools.git

I've then rebased the rest of your changes from the salsa/mjt branch
on top, and then added a commit to change the distribution from
"UNRELEASED" to "unstable".

After adding pristine-tar, "gbp buildpackage" seems to work just fine.
I'm in the middle of running a quick regression test using
"gce-xfstests -c f2fs/default -g auto".  If that is clean, I'll do a
formal signed build using dgit.

> This is a known issue. I've faced it a few times myself, though in
> my case I didn't want to add more work for ftp-masters and tried to
> avoid soname bump.

Yeah, unfortunately, the library communicates with its callers
(including the specification of the device name, etc.) in the global
variable:

struct f2fs_configuration c;

So unfortunately, there are soname bumps needed pretty much at every
single release, because the library API design was, well the sort
of thing you would expect for a flash FTL firmware programmer.  :-(

> So, let's process 1.15. I don't really care much about the lack
> of shared library at this time.  Please take a look.  I'm not the
> first-day Debian developer, but maybe there's something specific
> to this package or your habits which I didn't think about.

I think you did a great job!  I'll let you know how my regression test
works out.  (gce-xfstests is more of a kernel test than a userspace
test, but it's the best that we have for f2fs-tools)

 - Ted

Bug#1026039: lyx: LyX is listed as proprietary software in Gnome-software

[Lorenzo Bertini]

Package: lyx
Version: 2.3.6.1-1
Severity: normal
X-Debbugs-Cc: lorenzobertin...@gmail.com

Dear Maintainer,

LyX is listed on my system as proprietary software in gnome-software. Looking 
online I found several people having this issue with other programs, and the 
cause was always that the license couldn't be read by gnome-software properly.

Please ensure that gnome-software can properly read the license. If the bug is 
not on our end, let me know and I will contact gnome-software developers.

Thank you,

Lorenzo

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

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

Versions of packages lyx depends on:
ii  libc62.36-6
ii  libenchant-2-2   2.3.3-1
ii  libgcc-s112.2.0-9
ii  libmagic11:5.41-4
ii  libmythes-1.2-0  2:1.2.5-1
ii  libqt5core5a 5.15.6+dfsg-5
ii  libqt5gui5   5.15.6+dfsg-5
ii  libqt5svg5   5.15.6-2
ii  libqt5widgets5   5.15.6+dfsg-5
ii  libstdc++6   12.2.0-9
ii  lyx-common   2.3.6.1-1
ii  xdg-utils1.1.3-4.1
ii  zlib1g   1:1.2.13.dfsg-1

Versions of packages lyx recommends:
ii  atril [pdf-viewer]   1.26.0-2
ii  dvipng   1.15-1.1+b1
ii  evince [pdf-viewer]  43.1-2
ii  fonts-lyx2.3.6.1-1
ii  ghostscript  10.0.0~dfsg-8
ii  imagemagick  8:6.9.11.60+dfsg-1.3+b4
ii  imagemagick-6.q16 [imagemagick]  8:6.9.11.60+dfsg-1.3+b4
ii  poppler-utils22.08.0-2.1
ii  preview-latex-style  12.2-1
ii  psutils  1.17.dfsg-4
ii  texlive-fonts-recommended2022.20220923-2
ii  texlive-latex-extra  2022.20220923-3
ii  texlive-latex-recommended2022.20220923-2
ii  texlive-plain-generic2022.20220923-3
ii  texlive-science  2022.20220923-3

Versions of packages lyx suggests:
pn  chktex  
pn  gnuhtml2latex   
pn  groff   
ii  inkscape1.1.2-3+b1
pn  latex2rtf   
ii  librsvg2-bin2.54.5+dfsg-1
pn  libtiff-tools   
pn  linuxdoc-tools  
pn  noweb   
pn  rcs 
pn  sgmltools-lite  
ii  texlive-plain-generic [tex4ht]  2022.20220923-3
ii  texlive-xetex   2022.20220923-2
pn  writer2latex
pn  wv  

-- no debconf information

Bug#1026037: RFS: gnuit/4.9.5-4 [ITA] [RC] -- GNU Interactive Tools, a file browser/viewer and process viewer/killer

[Adam Borowski]

On Tue, Dec 13, 2022 at 04:26:51PM +0100, Josef Schneider wrote:
>  gnuit (4.9.5-4) unstable; urgency=medium
>  .
>* New maintainer (Closes: #1014171).
>* debian/control:
>  + Update to debhelper-compat version 13 (Closes: #965566).
>  + Standards-Version 4.6.1.
>  + Add Rules-Requires-Root: no.
>  + Add Depends on sensible-utils.
>  + Remove Build-Depends on autotools-dev.
>  + Change http to https.
>* debian/compat: Deleted.
>* debian/copyright:
>  + Update to dep5 format.
>  + Update licensing.
>* debian/rules:
>  + Update for debhelper-compat version 13 (Closes: #998945).
>  + Add configure command to correctly pass --host flag (Closes: #869489).
>* debian/patches: Add fix-printf-string.patch to fix FTBFS.
>* debian/watch: Update to version 4.
>* debian/source:
>  + Add format file.
>  + Add lintian-overrides to remove false positive warning.

Hi!
There's a dropping in /usr/bin : ".gitaction".

Looks good otherwise.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ Quis trollabit ipsos trollos?
⠈⠳⣄

Bug#1026002: FTBFS gcc: error: LinuxMachineDefines: linker input file not found: No such file or directory

[Thorsten Glaser]

# this is for a nōn-release architecture
severity 1026002 important
# this is a bug in the imake buildsystem, not xlax which merely uses it
reassign 1026002 xutils-dev
retitle 1026002 xutils-dev: imake support for riscv64 vanished?
affects 1026002 src:xlax
thanks

sun min dixit:

>xlax failed to build from source for architecture riscv64,it complains:
>gcc: warning: LinuxMachineDefines: linker input file unused because linking 
>not done
>gcc: error: LinuxMachineDefines: linker input file not found: No such file or 
>directory

This is something done by imake, which is in the xutils-dev package,
it merely affects all packages that use imake for building.

Please take this up with the xutils-dev maintainers but ideally,
first figure out which versions worked and which stopped to work.

Thanks,
//mirabilos
-- 
15:39⎜«mika:#grml» mira|AO: "mit XFree86® wär’ das nicht passiert" - muhaha
15:48⎜ also warum machen die xorg Jungs eigentlich alles
kaputt? :)15:49⎜ thkoehler: weil sie als Kinder nie den
gebauten Turm selber umschmeissen durften?  -- ~/.Xmodmap wonders…

Bug#805940: Proposal to close

[Jeremy Sowden]

If no one has any objections, I'm going to close this bug report for two
reasons.  Firstly, it relates to the transition from ulogd to ulogd2
which took place in Jessie, and so it shouldn't be relevant anymore.
Additionally, I believe that it was fixed by this change:

  --- a/debian/ulogd2.postinst
  +++ b/debian/ulogd2.postinst
  @@ -17,5 +17,17 @@ if [ -x "/etc/init.d/ulogd" ]; then
  update-rc.d -f ulogd remove >/dev/null
   fi

  +case "$1" in
  +configure)
  +   # Set ownership and permissions on /var/log/ulog for new installs or
  +   # upgrades from << 2.0.5-5
  +   if dpkg --compare-versions "$2" lt '2.0.5-5~'; then
  +   mkdir -p /var/log/ulog
  +   chown ulog:adm /var/log/ulog
  +   chmod u=rwx,g=rx,o= /var/log/ulog
  +   fi
  +   ;;
  +esac
  +
   #DEBHELPER#

which was introduced in 2.0.5-5 to fix:

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

J.


signature.asc
Description: PGP signature

Bug#731638: Proposal to close

[Jeremy Sowden]

If no one has any objections, I'm going to close this bug report for two
reasons.  Firstly, it relates to the transition from ulogd to ulogd2
which took place in Jessie, and so it shouldn't be relevant anymore.
Additionally, I believe that it was fixed by this change:

  --- a/debian/ulogd2.postinst
  +++ b/debian/ulogd2.postinst
  @@ -17,5 +17,17 @@ if [ -x "/etc/init.d/ulogd" ]; then
  update-rc.d -f ulogd remove >/dev/null
   fi

  +case "$1" in
  +configure)
  +   # Set ownership and permissions on /var/log/ulog for new installs or
  +   # upgrades from << 2.0.5-5
  +   if dpkg --compare-versions "$2" lt '2.0.5-5~'; then
  +   mkdir -p /var/log/ulog
  +   chown ulog:adm /var/log/ulog
  +   chmod u=rwx,g=rx,o= /var/log/ulog
  +   fi
  +   ;;
  +esac
  +
   #DEBHELPER#

which was introduced in 2.0.5-5 to fix:

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

J.


signature.asc
Description: PGP signature

Bug#1026035: xen netback broken with 5.10.0-20-amd64 in s-p-u

[Diederik de Haas]

On Tuesday, 13 December 2022 15:40:04 CET Adi Kriegisch wrote:
> Source: linux
> Version: 5.10.158-1
> 
> we just upgraded our xen test cluster's kernel to the latest kernel from
> s-p-u and noticed that network communication is broken. We do have a
> 'classic' setup with bridges in dom0. After upgrading dom0's kernel, no
> communication is possible for the domU.
> 
> If there is anything we can do to help fixing that issue, we'll gladly do
> that!

https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#s4.2.2
 describes a (relatively simple) way to test a patch.

I found in current master/6.1 branch 2 commits which may be relevant:

https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?
id=7dfa764e0223a324366a2a1fc056d4d9d4e95491

https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?
id=9e624651859214fb2c4e442b059eba0aefcd0801

You'd possibly need to backport it to the 5.10 code, but if you can do that 
and test whether the updated kernel fixes the issue, that would be great.

If you have any questions, feel free to ask them.

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

Bug#1026038: ITP: php-slim-psr7 -- PHP library that provides a strict PSR-7 implementation used by the Slim Framework

[William Desportes]

Package: wnpp
Owner: William Desportes 
Severity: wishlist


* Package name : php-slim-psr7
* Version : 1.6.0
* Upstream Author : Pierre Bérubé 
* URL : https://github.com/slimphp/Slim-Psr7
* License : MIT
* Programming Lang: PHP
* Description : php-slim-psr7 is a PHP library that provides a strict PSR-7 
implementation used by the Slim Framework

This library depends on #1026036

VCS-Git: https://salsa.debian.org/php-team/pear/php-slim-psr7

Bug#1026037: RFS: gnuit/4.9.5-4 [ITA] [RC] -- GNU Interactive Tools, a file browser/viewer and process viewer/killer

[Josef Schneider]

Package: sponsorship-requests
Severity: important

Dear mentors,

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

 * Package name : gnuit
   Version  : 4.9.5-4
   Upstream contact : Ian Beckwith
 * URL  :https://www.gnu.org/software/gnuit/
 * License  : MIT, GPL-3+, public-domain, GPL-2+, GFDL-NIV-1.3+
 * Vcs  :https://git.savannah.gnu.org/gitweb/?p=gnuit.git
   Section  : utils

The source builds the following binary packages:

  gnuit - GNU Interactive Tools, a file browser/viewer and process viewer/killer

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

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

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

  dget -xhttps://mentors.debian.net/debian/pool/main/g/gnuit/gnuit_4.9.5-4.dsc

Changes since the last upload:

 gnuit (4.9.5-4) unstable; urgency=medium
 .
   * New maintainer (Closes: #1014171).
   * debian/control:
 + Update to debhelper-compat version 13 (Closes: #965566).
 + Standards-Version 4.6.1.
 + Add Rules-Requires-Root: no.
 + Add Depends on sensible-utils.
 + Remove Build-Depends on autotools-dev.
 + Change http to https.
   * debian/compat: Deleted.
   * debian/copyright:
 + Update to dep5 format.
 + Update licensing.
   * debian/rules:
 + Update for debhelper-compat version 13 (Closes: #998945).
 + Add configure command to correctly pass --host flag (Closes: #869489).
   * debian/patches: Add fix-printf-string.patch to fix FTBFS.
   * debian/watch: Update to version 4.
   * debian/source:
 + Add format file.
 + Add lintian-overrides to remove false positive warning.

Regards,

--
Josef Schneider

GPG Fingerprint 3267 0331 DB61 A817 7D25 4D05 5A44 BC12 F2A8 E58F



OpenPGP_0x5A44BC12F2A8E58F.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1026036: ITP: php-fig-http-message-util -- PHP library with utility classes and constants to facilitate using PSR-7

[William Desportes]

Package: wnpp
Owner: William Desportes 
Severity: wishlist

* Package name : php-fig-http-message-util
* Version : 1.1.5
* Upstream Author : Matthew Weier O'Phinney 
* URL : https://github.com/php-fig/http-message-util
* License : MIT
* Programming Lang: PHP
* Description : php-fig-http-message-util is a PHP library with utility classes 
and constants to facilitate using PSR-7

This library is needed to package 
https://salsa.debian.org/php-team/pear/php-slim-psr7

VCS-Git: https://salsa.debian.org/php-team/pear/php-fig-http-message-util

Bug#1026028: Qualcomm NFA725A not working on firmware-linux-nonfree 20221109-4

[Tarek Saier]

Hi Salvatore,

thank you for the quick reply.
The firmware-atheros package was missing. Installing it fixed the issue.

Kind regards
Tarek

On Tue, Dec 13, 2022 at 3:04 PM Salvatore Bonaccorso  wrote:
>
> Control: tags -1 + moreinfo
>
> Hi,
>
> On Tue, Dec 13, 2022 at 02:12:24PM +0100, Tarek Saier wrote:
> > Package: firmware-linux-nonfree
> > Version: 20221109-4
> > Severity: important
> >
> > Dear Maintainer,
> >
> > same as the reporter of #1021157, I am also using a ThinkPad T14s Gen3
> > with the Qualcomm NFA725A wifi card ("Qualcomm Wi-Fi 6E NFA725A 11AX
> > (2x2) & Bluetooth(R) 5.0" reported in lshw as "QCNFA765 Wireless
> > Network Adapter").
> >
> > On a fresh install of Debian 12 from the current ISO
> > https://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/bookworm_di_alpha1+nonfree/amd64/iso-cd/
> > no wireless card is detected. After updating packages, installing
> > firmware-linux-nonfree, and rebooting, Debian tries to load firmware
> > (ath11k/WCN6855.hw2.1/amss.bin) but this fails.
> >
> > dmesg output:
> >   [2.635425] mhi mhi0: firmware: failed to load
> > ath11k/WCN6855/hw2.1/amss.bin (-2)
> >   [2.635435] firmware_class: See https://wiki.debian.org/Firmware
> > or information about missing firmware
> >   [2.635444] mhi mhi0: firmware: failed to load
> > ath11k/WCN6855/hw2.1/amss.bin (-2)
> >   [2.635448] mhi mhi0: Direct firmware load for
> > ath11k/WCN6855/hw2.1/amss.bin failed with error -2
> >   [2.635451] mhi mhi0: Error loading firmware: -2
> >   [2.635493] ath11k_pci :01:00.0: failed to power up mhi: -110
> >   [2.635499] ath11k_pci :01:00.0: failed to start mhi: -110
> >   [2.635506] ath11k_pci :01:00.0: failed to power up :-110
> >
> > Given that bug report #1021157 was closed with
> > - firmware-nonfree (20221012-1) unstable
> > and I am running
> > - firmware-nonfree 20221109-4 on testing
> > I assumed the card should work. If I'm missing something please let me know.
>
> The firmware is contained in the firmware-atheros package:
>
> firmware-atheros: /lib/firmware/ath11k/WCN6855/hw2.1/amss.bin
>
> Do you have that one installed as well?
>
> Regards,
> Salvatore

Bug#1014171: O: gnuit -- GNU Interactive Tools, a file browser/viewer and process viewer/killer

[Josef Schneider]

I intend to adopt the orphaned package gnuit.

--
Josef Schneider

GPG Fingerprint 3267 0331 DB61 A817 7D25 4D05 5A44 BC12 F2A8 E58F



OpenPGP_0x5A44BC12F2A8E58F.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1026035: xen netback broken with 5.10.0-20-amd64 in s-p-u

[Adi Kriegisch]

Source: linux
Version: 5.10.158-1

Dear maintainers,

we just upgraded our xen test cluster's kernel to the latest kernel from
s-p-u and noticed that network communication is broken. We do have a
'classic' setup with bridges in dom0. After upgrading dom0's kernel, no
communication is possible for the domU.

We can see packets arrive at the domU and packets leave the domU; but they
never arrive at the virtual interface in dom0 (rx counter stays at 0 and error
counters stay at 0 too).

When migrating the domU back to the other server which has not been
upgraded, the machine is reachable again.

If there is anything we can do to help fixing that issue, we'll gladly do
that!

Thank you very much!

-- Adi


signature.asc
Description: PGP signature

Bug#925309: Wrong prefix directory hardcoded in signed GRUB image

[Pascal Hambourg]

(CC'in Steve McIntyre and debian-efi)

On 24/03/2019 at 01:10, Colin Watson wrote:

On Fri, Mar 22, 2019 at 08:47:37PM +0100, Pascal Hambourg wrote:


grub-install installs this initial grub.cfg in the same location as the
signed image, i.e.
- /EFI/BOOT if the option --removable is present
- the directory derived from the --bootloader-id option if present
- the directory derived from $GRUB_DISTRIBUTOR defined in /etc/default/grub

The default value of $GRUB_DISTRIBUTOR is "Debian", so the default install
location is (EFI_PARTITION)/EFI/debian.

However when the signed image is installed in a different location, it still
looks for grub.cfg in (EFI_PARTITION)/EFI/debian instead of $cmdpath and
spawns the grub> shell unless grub.cfg is present in this location. In the
shell, $prefix is set to (EFI_PARTITION)/EFI/debian.

Shouldn't the prefix be initialized with $cmdpath instead of the hardcoded
path /EFI/debian ?


Possibly.  The prefix parameter given to grub-mkimage's -p option has to
be an actual path, not a variable reference.  In order to make it use
$cmdpath, we'd need another one of the arrangements we use for some of
the other pre-built images to use a config file embedded in a memdisk.


Upcoming grub2 2.06-3~deb11u5 brought an unexpected side-effect 
regarding bugs #925309 and #1017887.
An initial config file (memdisk)/grub.cfg is now embedded in the signed 
core image along with the font file.

The relevant part is:

elif [ -e $prefix/grub.cfg ]; then
source $prefix/grub.cfg
else
source $cmdpath/grub.cfg

So if /EFI/debian/grub.cfg does not exist, then /EFI//grub.cfg can 
now be used instead. This is a significant improvement.


However, two issues remain.

1) If /EFI/debian/grub.cfg exists, it is still used even if 
/EFI//grub.cfg also exists. This is an issue when installing 
multiple instances of GRUB for different Debian systems if one has the 
default ="debian". Is it conceivable to reverse the order and use 
$cmdpath/grub.cfg first ?


2) The file /EFI//BOOT${ARCH}.CSV always contains the name "debian" 
regardless of the identifier  specified by --bootloader-id on the 
grub-install command line or $GRUB_DISTRIBUTOR in /etc/default/grub. The 
name in this file is used by fb${ARCH}.efi run by shim when invoked as 
/EFI/BOOT/BOOT${ARCH}.efi (removable media path) to recreate an EFI boot 
variable for the instance, so the variable will be labelled "debian" 
instead of . Is it conceivable to replace "debian" with  in this 
file ?

Bug#1026034: diffoscope: failing autopkg tests

[Matthias Klose]

Package: src:diffoscope
Version: 228
Severity: serious
Tags: sid bookworm

diffoscope's autopkg tests fail in unstable with:

=== FAILURES ===
__ test_diff ___

differences = /tmp/autopkgtest-lxc.vxtjt4v9/downtmp/autopkgtest_tmp/tests/data/test1.html -- 
/tmp/autopkgtest-lxc.vxtjt4v9/downtmp/autopkgtest_tmp/tests/data/test2.html []>


def test_diff(differences):
assert_diff(differences, "html_expected_diff")
>   assert_diff(differences.details[0], "html_text_expected_diff")
E   IndexError: list index out of range

differences = /tmp/autopkgtest-lxc.vxtjt4v9/downtmp/autopkgtest_tmp/tests/data/test1.html -- 
/tmp/autopkgtest-lxc.vxtjt4v9/downtmp/autopkgtest_tmp/tests/data/test2.html []>


tests/comparators/test_html.py:46: IndexError

Bug#1024653: git: FTBFS on s390x due to test failure, incorrect /proc/cpuinfo parsing

[Helge Deller]

The same bug happens on hppa and sparc architecture as well, as can be seen in 
those logs:
https://buildd.debian.org/status/fetch.php?pkg=git&arch=hppa&ver=1%3A2.39.0-1&stamp=1670883297&raw=0
https://buildd.debian.org/status/fetch.php?pkg=git&arch=sparc64&ver=1%3A2.39.0-1&stamp=1670887934&raw=0

Isn't there a better way to get the number of processors
in perl?
According to
https://stackoverflow.com/questions/4586405/how-to-get-the-number-of-cpus-in-linux-using-c
I like the idea of using the:
getNumCpus method of Sys::CpuAffinity

even fixing this line in chainlint.pl:
do { local @ARGV='/proc/cpuinfo'; return scalar(grep(/^processor[\s\d]*:/, 
<>)); } if -r '/proc/cpuinfo';
to never return 0, but at minimum "1" would work.

Helge

Bug#1020560: diffutils: Missing LGPL-2.1+, GPL-2+ in d/copyright

[Bastian Germann]

Am 11.12.22 um 19:56 schrieb Santiago Vila:
What rule is being followed to use wildcards sometimes and sometimes not? This is a little bit crazy. How did you 
generate the file?


It is not generated. If you can come up with a better file that is fine.
This was just a helper because otherwise bugs about the copyright file will be 
ignored by most maintainer unfortunately.
I guess the rule was to use a wildcard when it is possible.
You can certainly list every file but then the copyright file will be much 
bigger.

And more important, because without this I can't take the file "as is": How am I supposed to update the file when 
authors release a new version?


You look at the diff and check for license/copyright changes.
At least this is what I do. I do not know of any good tool to do it.

Bug#1026033: kimageformat-plugins: Missing JPEG XL support

[Davide G. Borin]

Package: kimageformat-plugins
Version: 5.100.0-1
Severity: normal

Dear Maintainer,
 according to
 https://api.kde.org/frameworks/kimageformats/html/index.html
kimageformat can read and write JPEG XL images, but the plugin is not 
compiled in the Debian package.



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

Kernel: Linux 6.0.0-5-amd64 (SMP w/24 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:it

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

Versions of packages kimageformat-plugins depends on:
ii  libavif150.11.1-1
ii  libc62.36-6
ii  libgcc-s112.2.0-9
ii  libheif1 1.13.0-1
ii  libimath-3-1-29  3.1.5-1+b1
ii  libkf5archive5   5.100.0-2
ii  libopenexr-3-1-303.1.5-4
ii  libqt5core5a 5.15.6+dfsg-5
ii  libqt5gui5   5.15.6+dfsg-5
ii  libqt5printsupport5  5.15.6+dfsg-5
ii  libstdc++6   12.2.0-9

kimageformat-plugins recommends no packages.

kimageformat-plugins suggests no packages.

-- no debconf information

Bug#1026032: scribus: Patch for building against Poppler >= 22.09.

[Nathan Pratta Teodosio]

Package: scribus
Version: 1.5.8+dfsg-3
Severity: wishlist
Tags: patch
X-Debbugs-Cc: nathan.teodo...@canonical.com

Hi, I have observed that Scribus fails to build against Poppler 22.12.

I forward a patch that fixes that[1]. This time I double checked the
line endings. ;)

[1]: https://launchpad.net/~nteodosio/+archive/ubuntu/poppler/+build/24935155
From: Nathan Pratta Teodosio 
Description: Fix build with Poppler >=22.9.0
Origin: upstream, 
https://www.scribus.net/websvn/revision.php?repname=Scribus&rev=25139
git-svn-id: svn://scribus.net/trunk/Scribus@25140 
11d20701-8431-0410-a711-e3c959e3b870

--- a/scribus/plugins/import/pdf/slaoutput.cpp
+++ b/scribus/plugins/import/pdf/slaoutput.cpp
@@ -3628,16 +3628,11 @@ void SlaOutputDev::getPenState(GfxState *state)
m_lineJoin = Qt::BevelJoin;
break;
}
-   double lw = state->getLineWidth();
-   double *dashPattern;
-   int dashLength;
-   state->getLineDash(&dashPattern, &dashLength, &DashOffset);
-   QVector pattern(dashLength);
-   for (int i = 0; i < dashLength; ++i)
-   {
-   pattern[i] = dashPattern[i] / lw;
-   }
-   DashValues = pattern;
+   const auto& dashPattern = state->getLineDash(&DashOffset);
+   QVector pattern(dashPattern.size());
+   for (size_t i = 0; i < dashPattern.size(); ++i)
+   pattern[i] = dashPattern[i];
+   DashValues = pattern;
 }
 
 int SlaOutputDev::getBlendMode(GfxState *state)

Bug#1026031: /usr/bin/debianbts: WARNING debianbts Not implemented yet, sorry!

[Jakub Wilk]

Package: python3-debianbts
Version: 4.0.1

This package ships with /usr/bin/debianbts, but AFAICT it doesn't do anything:

   $ debianbts --help
   2022-12-13 15:27:44,211 WARNING debianbts Not implemented yet, sorry!

Please either make it do something useful or remove it.


-- System Information:
Architecture: i386

Versions of packages python3-debianbts depends on:
ii  python3-pysimplesoap  1.16.2-5
ii  python3   3.10.6-3

--
Jakub Wilk

Bug#1025902: Acknowledgement (tlp: Battery charge thresholds are ignored)

[Benedikt Ahrens]

Here is the relevant part of /etc/tlp.conf:


# Battery Care -- Charge thresholds
# Charging starts when the charge level is below the START_CHARGE_THRESH
value
# when the charger is connected. It stops when the STOP_CHARGE_THRESH
value is
# reached.
# Required hardware: Lenovo ThinkPads and select other laptop brands are
driven
# via specific plugins, the actual support status is shown by tlp-stat -b.
# For more explanations and vendor specific details refer to
#   https://linrunner.de/tlp/settings/battery.html
# Notes:
# - ThinkPads may require external kernel module(s), refer to the output of
#   tlp-stat -b
# - Vendor specific parameter value ranges are shown by tlp-stat -b
# - If your hardware supports a start *and* a stop threshold, you must
#   specify both, otherwise TLP will refuse to apply the single threshold
# - If your hardware supports only a stop threshold, set the start value
to 0

# BAT0: Primary / Main / Internal battery (values in %)
# Note: also use for batteries BATC, BATT and CMB0
# Default: 

#START_CHARGE_THRESH_BAT0=65
#STOP_CHARGE_THRESH_BAT0=75

# BAT1: Secondary / Ultrabay / Slice / Replaceable battery (values in %)
# Note: primary on some laptops
# Default: 

#START_CHARGE_THRESH_BAT1=65
#STOP_CHARGE_THRESH_BAT1=75

# Restore charge thresholds when AC is unplugged: 0=disable, 1=enable.
# Default: 0

#RESTORE_THRESHOLDS_ON_BAT=1

# Control battery care drivers: 0=disable, 1=enable.
# Default: 1 (all)

#NATACPI_ENABLE=1
#TPACPI_ENABLE=1
#TPSMAPI_ENABLE=1

Bug#1026030: python3-debianbts: doesn't verify server's TLS cert

[Jakub Wilk]

Package: python3-debianbts
Version: 4.0.1
Tags: security

This module doesn't verify the server's TLS certificate:

   >>> import debianbts
   >>> debianbts.set_soap_location("https://self-signed.badssl.com";)
   >>> debianbts.get_status(42)
   b'\r\n405 Not Allowed\r\n\r\n405 Not 
Allowed\r\nnginx/1.10.3 (Ubuntu)\r\n\r\n\r\n'
   Traceback (most recent call last):
 ...
 File "", line 1, in 
 File "/usr/lib/python3/dist-packages/debianbts/debianbts.py", line 240, in 
get_status
   reply = soap_client.call("get_status", method_el)
 File "/usr/lib/python3/dist-packages/pysimplesoap/client.py", line 257, in 
call
   response = SimpleXMLElement(self.xml_response, namespace=self.namespace,
 File "/usr/lib/python3/dist-packages/pysimplesoap/simplexml.py", line 56, 
in __init__
   self.__document = xml.dom.minidom.parseString(text)
 File "/usr/lib/python3.10/xml/dom/minidom.py", line 2000, in parseString
   return expatbuilder.parseString(string)
 File "/usr/lib/python3.10/xml/dom/expatbuilder.py", line 925, in 
parseString
   return builder.parseString(string)
 File "/usr/lib/python3.10/xml/dom/expatbuilder.py", line 223, in 
parseString
   parser.Parse(string, True)
   xml.parsers.expat.ExpatError: mismatched tag: line 6, column 2

The server in question doesn't have a valid certificate, so you should 
get a certificate error, not an XML parsing error.


For example, with urllib you get:

   >>> import urllib.request
   >>> urllib.request.urlopen("https://self-signed.badssl.com";)
   Traceback (most recent call last):
 ...
   urllib.error.URLError: 


-- System Information:
Architecture: i386

Versions of packages python3-debianbts depends on:
ii  python3-pysimplesoap  1.16.2-5
ii  python3   3.10.6-3

--
Jakub Wilk