Bug#1019124: python3-requests-cache: Would you please upgrade to 0.9.6?

[Takahide Nojima]

Package: python3-requests-cache
Version: 0.9.1-1
Severity: wishlist
X-Debbugs-Cc: nozzy123no...@gmail.com

Dear Maintainer,

 I reported in #1018287. Now I've changed my mind that  #1018287 is not
a bug respecting your opinion, so I'll ask here to upgrade to 0.9.6 as
a wishlist.

 That dependency warning has been improved to 0.9.6 by the upstream.
I've checked after building the deb package simply using 0.9.6.

 In my Debian box,  "pip3 install --user" of dep package generates
noisy warnings at all times after I installed python3-requests-cache. I
guess the upstream of pip3 wants to fix the dependency of each python
package, so I'm grateful you upgrade python3-requests-cache  to 0.9.6.

 Thank you in advance,
Takahide Nojima

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

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

Versions of packages python3-requests-cache depends on:
ii  python3    3.10.6-1
ii  python3-appdirs    1.4.4-3
ii  python3-attr   22.1.0-1
ii  python3-cattr  1.10.0-1
ii  python3-requests   2.27.1+dfsg-1
ii  python3-url-normalize  1.4.3-2
ii  python3-urllib3    1.26.9-1

python3-requests-cache recommends no packages.

Versions of packages python3-requests-cache suggests:
pn  python-requests-cache-doc  
pn  python3-pymongo    
pn  python3-redis  

-- no debconf information

Bug#1019123: golang-github-bmatsuo-lmdb-go: flaky autopkgtest on s390x: segmentation violation

[Paul Gevers]

Source: golang-github-bmatsuo-lmdb-go
Version: 1.8.0+git20170215.a14b5a3-2
Severity: serious
User: debian...@lists.debian.org
Usertags: flaky

Dear maintainer(s),

I looked at the results of the autopkgtest of your package. I noticed 
that it regularly fails on s390x.


Because the unstable-to-testing migration software now blocks on
regressions in testing, flaky tests, i.e. tests that flip between
passing and failing without changes to the list of installed packages,
are causing people unrelated to your package to spend time on these
tests.

Don't hesitate to reach out if you need help and some more information
from our infrastructure.

Paul

=== RUN   TestTxn_Sub
fatal error: unexpected signal during runtime execution
[signal SIGSEGV: segmentation violation code=0x1 addr=0x3ff95a0 
pc=0x3ffbf098052]


runtime stack:
runtime.throw({0x11b7cc8, 0x2a})
/usr/lib/go-1.18/src/runtime/panic.go:992 +0x70
runtime.sigpanic()
/usr/lib/go-1.18/src/runtime/signal_unix.go:802 +0x2a4

goroutine 98 [syscall, locked to thread]:
runtime.cgocall(0x1169610, 0xc0001a15e8)
	/usr/lib/go-1.18/src/runtime/cgocall.go:157 +0x72 fp=0xc0001a15b8 
sp=0xc0001a1588 pc=0x1008472
github.com/bmatsuo/lmdb-go/lmdb._Cfunc_mdb_txn_begin(0x21de3f0, 0x0, 
0x0, 0xce8858)

_cgo_gotypes.go:885 +0x3a fp=0xc0001a15e0 sp=0xc0001a15b8 pc=0x115abaa
github.com/bmatsuo/lmdb-go/lmdb.beginTxn.func1(0xca6480, 0x0, 0x0, 
0xce8840)


/tmp/autopkgtest-lxc.sq0ugelt/downtmp/autopkgtest_tmp/obj-s390x-linux-gnu/src/github.com/bmatsuo/lmdb-go/lmdb/txn.go:99
 +0x108 fp=0xc0001a1620 sp=0xc0001a15e0 pc=0x11625b8
github.com/bmatsuo/lmdb-go/lmdb.beginTxn(0xca6480, 0x0, 0x0)

/tmp/autopkgtest-lxc.sq0ugelt/downtmp/autopkgtest_tmp/obj-s390x-linux-gnu/src/github.com/bmatsuo/lmdb-go/lmdb/txn.go:99
 +0x24e fp=0xc0001a1668 sp=0xc0001a1620 pc=0x116232e
github.com/bmatsuo/lmdb-go/lmdb.(*Env).run(0xca6480, 0x1, 0x0, 
0xc0001a1720)


/tmp/autopkgtest-lxc.sq0ugelt/downtmp/autopkgtest_tmp/obj-s390x-linux-gnu/src/github.com/bmatsuo/lmdb-go/lmdb/env.go:507
 +0x74 fp=0xc0001a16b0 sp=0xc0001a1668 pc=0x11615e4
github.com/bmatsuo/lmdb-go/lmdb.(*Env).Update(...)

/tmp/autopkgtest-lxc.sq0ugelt/downtmp/autopkgtest_tmp/obj-s390x-linux-gnu/src/github.com/bmatsuo/lmdb-go/lmdb/env.go:478
github.com/bmatsuo/lmdb-go/lmdb.TestTxn_Sub(0xc8a820)

/tmp/autopkgtest-lxc.sq0ugelt/downtmp/autopkgtest_tmp/obj-s390x-linux-gnu/src/github.com/bmatsuo/lmdb-go/lmdb/txn_test.go:594
 +0x11a fp=0xc0001a1768 sp=0xc0001a16b0 pc=0x114ed5a
testing.tRunner(0xc8a820, 0x11bacb0)
	/usr/lib/go-1.18/src/testing/testing.go:1439 +0x122 fp=0xc0001a17c0 
sp=0xc0001a1768 pc=0x10dfaf2

testing.(*T).Run.func1()
	/usr/lib/go-1.18/src/testing/testing.go:1486 +0x5e fp=0xc0001a17d8 
sp=0xc0001a17c0 pc=0x10e0c8e

runtime.goexit()
	/usr/lib/go-1.18/src/runtime/asm_s390x.s:742 +0x2 fp=0xc0001a17d8 
sp=0xc0001a17d8 pc=0x1079552

created by testing.(*T).Run
/usr/lib/go-1.18/src/testing/testing.go:1486 +0x442

goroutine 1 [chan receive]:
testing.(*T).Run(0xc8b520, {0x11aef56, 0xb}, 0x11bacb0)
/usr/lib/go-1.18/src/testing/testing.go:1487 +0x466
testing.runTests.func1(0xc8b520)
/usr/lib/go-1.18/src/testing/testing.go:1839 +0x8a
testing.tRunner(0xc8b520, 0xcb9cf8)
/usr/lib/go-1.18/src/testing/testing.go:1439 +0x122
testing.runTests(0xcc2048, {0x12a8c00, 0x49, 0x49}, 
{0xc0ba49c293d80f3a, 0x8bb2ccfada, 0x12c0e80})

/usr/lib/go-1.18/src/testing/testing.go:1837 +0x4d6
testing.(*M).Run(0xccc140)
/usr/lib/go-1.18/src/testing/testing.go:1719 +0x5fc
main.main()
_testmain.go:305 +0x1f8
FAILgithub.com/bmatsuo/lmdb-go/lmdb 4.701s


https://ci.debian.net/data/autopkgtest/testing/s390x/g/golang-github-bmatsuo-lmdb-go/25231180/log.gz

https://ci.debian.net/data/autopkgtest/testing/s390x/g/golang-github-bmatsuo-lmdb-go/24343061/log.gz

https://ci.debian.net/data/autopkgtest/testing/s390x/g/golang-github-bmatsuo-lmdb-go/23581708/log.gz


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1019122: casparcg-server: Move to main as the dependency on non-free fdk-aac is gone?

[Petter Reinholdtsen]

Package: casparcg-server
Version: 2.3.3+dfsg-2

The casparcg-server package ended up in contrib instead of main because
it depended on the non-free library fdk-aac.  As this dependency is no
longer present, perhaps the package should be moved to the main part of
the Debian archive?

-- 
Happy hacking
Petter Reinholdtsen

Bug#1019121: libpqtypes: flaky autopkgtest on arm64: table "libpq_array" does not exist

[Paul Gevers]

Source: libpqtypes
Version: 1.5.1-7
Severity: serious
User: debian...@lists.debian.org
Usertags: flaky

Dear maintainer(s),

I looked at the results of the autopkgtest of your package. I noticed 
that it regularly fails on arm64.


Because the unstable-to-testing migration software now blocks on
regressions in testing, flaky tests, i.e. tests that flip between
passing and failing without changes to the list of installed packages,
are causing people unrelated to your package to spend time on these
tests.

Don't hesitate to reach out if you need help and some more information
from our infrastructure.

Paul

Ran 125 tests - 1 failed
*** /tmp/pg_virtualenv.QzsWeE/log/postgresql-14-regress.log (last 100 
lines) ***
2022-09-02 13:57:21.320 CST [7664] LOG:  starting PostgreSQL 14.5 
(Debian 14.5-1) on aarch64-unknown-linux-gnu, compiled by gcc (Debian 
12.1.0-8) 12.1.0, 64-bit
2022-09-02 13:57:21.321 CST [7664] LOG:  listening on IPv6 address 
"::1", port 5433
2022-09-02 13:57:21.321 CST [7664] LOG:  listening on IPv4 address 
"127.0.0.1", port 5433
2022-09-02 13:57:21.321 CST [7664] LOG:  listening on Unix socket 
"/tmp/.s.PGSQL.5433"
2022-09-02 13:57:21.322 CST [7665] LOG:  database system was shut down 
at 2022-09-02 13:57:21 CST
2022-09-02 13:57:21.327 CST [7664] LOG:  database system is ready to 
accept connections
2022-09-02 13:57:23.522 CST [7685] debci@postgres ERROR:  table 
"libpq_array" does not exist
2022-09-02 13:57:23.522 CST [7685] debci@postgres STATEMENT:  DROP TABLE 
libpq_array
2022-09-02 13:57:23.525 CST [7685] debci@postgres ERROR:  type 
"public.complex" does not exist
2022-09-02 13:57:23.525 CST [7685] debci@postgres STATEMENT:  DROP TYPE 
public.complex
2022-09-02 13:57:23.525 CST [7685] debci@postgres ERROR:  type 
"public.simple" does not exist
2022-09-02 13:57:23.525 CST [7685] debci@postgres STATEMENT:  DROP TYPE 
public.simple


https://ci.debian.net/data/autopkgtest/testing/arm64/libp/libpqtypes/25613424/log.gz
https://ci.debian.net/data/autopkgtest/testing/arm64/libp/libpqtypes/24974038/log.gz
https://ci.debian.net/data/autopkgtest/testing/arm64/libp/libpqtypes/24648942/log.gz
https://ci.debian.net/data/autopkgtest/testing/arm64/libp/libpqtypes/24021115/log.gz
https://ci.debian.net/data/autopkgtest/testing/arm64/libp/libpqtypes/23016446/log.gz


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1018687: override: perl-modules-5.34:libs/optional perl-modules-5.36:libs/optional

[Russ Allbery]

Not an active member of the Perl team, but there's a Policy point here
that seemed worth clarifying.

Sean Whitton  writes:
> On Sun 28 Aug 2022 at 09:28PM -05, Daniel Lewart wrote:

>> Debian FTP Master(s) and Niko,
>>
>> Currently, perl-modules-5.34 and perl-modules-5.36 are libs/standard.
>>
>> However, Debian Policy 2.5 Priorities:
>> https://www.debian.org/doc/debian-policy/ch-archive.html#priorities
>> states:
>> "In particular, this means that C-like libraries will almost
>> never have a priority above optional, since they do not provide
>> functionality directly to users."
>>
>> Since perl-modules-5.xx are not standalone packages and are in
>> Section:libs, I consider this Policy to apply to them.

Well, speaking as a Policy Editor, the same argument does not apply to
Perl modules because Perl modules do not have the separate -dev package
split that is the reason for this statement in Policy.  Perl modules do
provide functionality directly to users.

That said, maybe this change is still correct, just not for that reason?

>> Please change perl-modules-5.34 and perl-modules-5.36 from:
>>   * Priority: standard
>> to:
>>   * Priority: optional
>>
>> perl 5.34.0 is Priority:standard" and Depends on perl-modules-5.34.
>> perl 5.36.0 is Priority:standard" and Depends on perl-modules-5.36.
>> Therefore, perl-modules-5.xx will still be pulled into Standard systems.

I think the stronger argument here is basically that the perl-modules
package is an internal implementation detail of the perl package, and
therefore only the perl package should have the higher standard priority.

I'm not sure it makes much difference in practice, and I'm curious what
problem Daniel ran into that motivated filing a bug report, but I think
that logic might make sense?  But I'm also not sure we should make changes
here just for the sake of making changes, so I'm curious about the
motivation and what problem this change would fix.

-- 
Russ Allbery (r...@debian.org)  

Bug#1018881: glibc: iconv not working properly on m68k and sh4

[John Paul Adrian Glaubitz]

Hello!

On 9/2/22 18:43, Aurelien Jarno wrote:

I ran a build on mitchy.debian.net and the file is correctly generated.
Is there anything different on the buildds?


The buildds use qemu-user while mitchy uses qemu-system. The issue might be
a result of the getdents issue in glibc [1]. I have uploaded a glibc package 
with
the patch set included to unreleased in any case.

Adrian


[1] https://sourceware.org/bugzilla/show_bug.cgi?id=23960


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

Bug#1019120: src:argyll: fails to migrate to testing for too long: uploader built arch:all binaries

[Paul Gevers]

Source: argyll
Version: 2.3.0+repack-1
Severity: serious
Control: close -1 2.3.1+repack-1
Tags: sid bookworm pending
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 60 days as having a Release Critical bug in 
testing [1]. Your package src:argyll has been trying to migrate for 61 
days [2]. Hence, I am filing this bug.


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.


Your package is only blocked because the arch:all binary package(s) 
aren't built on a buildd. Unfortunately the Debian infrastructure 
doesn't allow arch:all packages to be properly binNMU'ed. Hence, I will 
shortly do a no-changes source-only upload to DELAYED/15, closing this 
bug. Please let me know if I should delay or cancel that upload.


Paul

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



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1019119: src:horizon: fails to migrate to testing for too long: autopkgtest failure

[Paul Gevers]

Source: horizon
Version: 3:22.1.0-2
Severity: serious
Control: close -1 3:22.1.0-5
Tags: sid bookworm
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 1018787

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:horizon has been trying to migrate for 61 
days [2]. Hence, I am filing this bug. Migrating your package would 
introduce failing autopkgtests in testing, which I reported in bug 1018787.


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=horizon



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1017832: dh-lua causes FTBFS error with glibc 2.35 due to catchsegv removal

[Paul Gevers]

Hi Aurelien,

On Sat, 3 Sep 2022 11:36:07 +0200 Aurelien Jarno  wrote:

On 2022-08-21 11:49, Aurelien Jarno wrote:
> dh-lua uses catchsegv, a binary currently provided by libc-bin when
> executing the lua tests. This binary has been removed from glibc 2.35,
> causing debci [1] or FTBFS failures on packages using dh-lua.
> 
> I have attached a patch that stops wrapping test commands with

> catchsegv, fixing the debci and FTBFS issue. Could you please schedule
> an upload with this patch?

First of all, I am very sorry to be a bit pushy there. This is the last
fix needed before we can start the glibc 2.35 transition.


To be honest, I don't think you need to be sorry here. glibc is way to 
important to not be allowed to be pushy sometimes. Thanks for take so 
good care of it. I really appreciate all the preparation you do before 
uploading to unstable.



I have uploaded a NMU fixing this issue to DELAYED/15. Please find the
corresponding debdiff attached. Also please feel free to ask me to delay
or cancel this NMU.


With my Release Manager hat on, I think it's quite OK to speed this up 
10 days (and preferably the maintainers just ack the change and you drop 
the delay).


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1018690: override: python3-reportbug:python/optional

[Sean Whitton]

Hello,

On Sun 28 Aug 2022 at 10:45PM -05, Daniel Lewart wrote:

> Debian FTP Master(s) and Reportbug Maintainers,
>
> Currently, python3-reportbug is Priority: standard.
>
> It has only one reverse dependency: reportbug (Priority: standard).
>
> Debian Policy 2.5 Priorities:
> https://www.debian.org/doc/debian-policy/ch-archive.html#priorities
> states:
> "The priority of a package is determined solely by the functionality
> it provides directly to the user. The priority of a package should
> not be increased merely because another higher-priority package
> depends on it; ..."
>
> I think that applies in this case.
>
> Please change the python3-reportbug Priority from standard to optional.

This sounds right, but could the maintainers chime in?  Thanks.

-- 
Sean Whitton

Bug#1018689: override: python3:python/standard

[Sean Whitton]

control: tag -1 + moreinfo

On Sun 28 Aug 2022 at 10:33PM -05, Daniel Lewart wrote:

> Package: ftp.debian.org
> Severity: normal
> User: ftp.debian@packages.debian.org
> Usertags: override
> X-Debbugs-Cc: debian-b...@lists.debian.org, pyth...@packages.debian.org
>
> Debian FTP Master(s) and Matthias,
>
> Currently, python3 is Priority: optional.
>
> The following Buster packages have Priority: standard:
>   * python
>   * python-minimal
>   * python2.7
>   * python3-reportbug
>
> Now the following Priority:standard packages depend on python3
> (directly or indirectly):
>   * apt-listchanges
>   * python3-reportbug
>   * reportbug
>
> Therefore, I think that python3 should change from:
> Priority: optional
> to:
> Priority: standard

I don't think these dependency relationships bear directly on the issue?

Anyway, we need to hear from the package maintainers about this before
considering the change.

-- 
Sean Whitton

Bug#992474: override: bind9-libs:libs/optional

[Sean Whitton]

Hello,

On Sun 28 Aug 2022 at 07:42PM -05, Daniel Lewart wrote:

> Debian FTP Master(s) and Debian DNS Team,
>
> "Accepted bind9 1:9.18.6-1 (source amd64 all) into unstable, unstable":
> https://tracker.debian.org/news/1357381
> apparently reverted the Priority for bind9-libs from "optional" back
> to "standard".
>
> Please change the Priority for bind9-libs from "standard" back to "optional".

But bind9-libs is a separate source package, right?  Not sure how an
upload of bind9, then, could change its priority?

Anyway, we have to change each binary package and source package
separately, so please provide a list of all the changes required.

-- 
Sean Whitton

Bug#1018687: override: perl-modules-5.34:libs/optional perl-modules-5.36:libs/optional

[Sean Whitton]

Hello,

On Sun 28 Aug 2022 at 09:28PM -05, Daniel Lewart wrote:

> Package: ftp.debian.org
> Severity: normal
> User: ftp.debian@packages.debian.org
> Usertags: override
> X-Debbugs-Cc: debian-b...@lists.debian.org, p...@packages.debian.org
>
> Debian FTP Master(s) and Niko,
>
> Currently, perl-modules-5.34 and perl-modules-5.36 are libs/standard.
>
> However, Debian Policy 2.5 Priorities:
> https://www.debian.org/doc/debian-policy/ch-archive.html#priorities
> states:
> "In particular, this means that C-like libraries will almost
> never have a priority above optional, since they do not provide
> functionality directly to users."
>
> Since perl-modules-5.xx are not standalone packages and are in
> Section:libs, I consider this Policy to apply to them.
>
> Please change perl-modules-5.34 and perl-modules-5.36 from:
>   * Priority: standard
> to:
>   * Priority: optional
>
> perl 5.34.0 is Priority:standard" and Depends on perl-modules-5.34.
> perl 5.36.0 is Priority:standard" and Depends on perl-modules-5.36.
> Therefore, perl-modules-5.xx will still be pulled into Standard systems.

Can someone from the Perl team speak to this request, please?

-- 
Sean Whitton

Bug#1019118: linux: [regression] introduction of rtla binary package broke cross builds

[Johannes Schauer Marin Rodrigues]

Source: linux
Version: 5.19.6-1
Severity: normal
X-Debbugs-Cc: jo...@debian.org

Hi,

linux fails to cross build at least for arm64 but probably also for the
other architectures for which the new rtla binary package is built with
the following error message:

$ DEB_BUILD_OPTIONS=parallel=1 DEB_BUILD_PROFILES=cross sbuild -d unstable 
--build=amd64 --host=arm64 --no-run-lintian --no-run-autopkgtest linux_5.19.6-1
[...]
mkdir -p debian/build/build-tools/tools/tracing/rtla && env -u ABINAME -u ARCH 
-u FEATURESET -u FLAVOUR -u VERSION -u LOCALVERSION 
DISTRIBUTION_OFFICIAL_BUILD=1 DISTRIBUTOR="Debian" 
DISTRIBUTION_VERSION="5.19.6-1" KBUILD_BUILD_TIMESTAMP="Thu, 01 Sep 2022 
09:04:35 +0200" KBUILD_BUILD_VERSION_TIMESTAMP="Debian 5.19.6-1 (2022-09-01)" 
KBUILD_BUILD_USER="debian-kernel" KBUILD_BUILD_HOST="lists.debian.org" 
KBUILD_VERBOSE=1 /usr/bin/make KCFLAGS=-fdebug-prefix-map=/<>/= 
KBUILD_HOSTCFLAGS='-g -O2 -ffile-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2' HOSTCFLAGS='-g -O2 -ffile-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2' KBUILD_HOSTLDFLAGS='-Wl,-z,relro' -C 
debian/build/build-tools/tools/tracing/rtla -f 
/<>/debian/rules.d/tools/tracing/rtla/Makefile 
top_srcdir=/<> top_rulesdir=/<>/debian/rules.d 
OUTDIR=tools/tracing/rtla VERSION=5.19 KERNEL_ARCH=arm64
make[3]: Entering directory 
'/<>/debian/build/build-tools/tools/tracing/rtla'
echo '5.19' >VERSION
rsync -a /<>/tools/tracing/rtla/ .
rsync -a /<>/Documentation/tools/rtla/ Documentation/
/usr/bin/make EXTRA_CFLAGS='-g -O2 -fstack-protector-strong -Wformat 
-Werror=format-security -Wall -Wdate-time -D_FORTIFY_SOURCE=2 
-I/<>/tools/tracing/rtla 
-I/<>/debian/build/build-tools/tools/tracing/rtla -isystem 
/<>/debian/build/build-tools/include' EXTRA_LDFLAGS='-Wl,-z,relro'
make[4]: Entering directory 
'/<>/debian/build/build-tools/tools/tracing/rtla'

** NOTICE: libtraceevent version 1.5 or higher not found
**
** Consider installing the latest libtraceevent from your
** distribution, e.g., 'dnf install libtraceevent' on Fedora,
** or from source:
**
**  https://git.kernel.org/pub/scm/libs/libtrace/libtraceevent.git/ 
**

make[4]: Leaving directory 
'/<>/debian/build/build-tools/tools/tracing/rtla'
make[3]: Leaving directory 
'/<>/debian/build/build-tools/tools/tracing/rtla'
dh_testdir
dh_testroot
dh_prep
mkdir -p debian/build/build-tools/tools/tracing/rtla && env -u ABINAME -u ARCH 
-u FEATURESET -u FLAVOUR -u VERSION -u LOCALVERSION 
DISTRIBUTION_OFFICIAL_BUILD=1 DISTRIBUTOR="Debian" 
DISTRIBUTION_VERSION="5.19.6-1" KBUILD_BUILD_TIMESTAMP="Thu, 01 Sep 2022 
09:04:35 +0200" KBUILD_BUILD_VERSION_TIMESTAMP="Debian 5.19.6-1 (2022-09-01)" 
KBUILD_BUILD_USER="debian-kernel" KBUILD_BUILD_HOST="lists.debian.org" 
KBUILD_VERBOSE=1 /usr/bin/make KCFLAGS=-fdebug-prefix-map=/<>/= 
KBUILD_HOSTCFLAGS='-g -O2 -ffile-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2' HOSTCFLAGS='-g -O2 -ffile-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2' KBUILD_HOSTLDFLAGS='-Wl,-z,relro' -C 
debian/build/build-tools/tools/tracing/rtla -f 
/<>/debian/rules.d/tools/tracing/rtla/Makefile 
top_srcdir=/<> top_rulesdir=/<>/debian/rules.d 
OUTDIR=tools/tracing/rtla VERSION=5.19 KERNEL_ARCH=arm64 install 
DESTDIR=/<>/debian/rtla
make[3]: Entering directory 
'/<>/debian/build/build-tools/tools/tracing/rtla'
/usr/bin/make install
make[4]: Entering directory 
'/<>/debian/build/build-tools/tools/tracing/rtla'
/usr/bin/make -C Documentation/ install
make[5]: Entering directory 
'/<>/debian/build/build-tools/tools/tracing/rtla/Documentation'
rst2man --verbose rtla-osnoise-hist.rst > rtla-osnoise-hist.1
rst2man --verbose rtla-osnoise-top.rst > rtla-osnoise-top.1
rst2man --verbose rtla-osnoise.rst > rtla-osnoise.1
rst2man --verbose rtla-timerlat-hist.rst > rtla-timerlat-hist.1
rst2man --verbose rtla-timerlat-top.rst > rtla-timerlat-top.1
rst2man --verbose rtla-timerlat.rst > rtla-timerlat.1
rst2man --verbose rtla.rst > rtla.1
install -d -m 755 /<>/debian/rtla/usr/share/man/man1
install -m 644 rtla-osnoise-hist.1 rtla-osnoise-top.1 rtla-osnoise.1 
rtla-timerlat-hist.1 rtla-timerlat-top.1 rtla-timerlat.1 rtla.1 
/<>/debian/rtla/usr/share/man/man1
make[5]: Leaving directory 
'/<>/debian/build/build-tools/tools/tracing/rtla/Documentation'
mkdir -p /<>/debian/rtla/usr/bin
install rtla -m 755 /<>/debian/rtla/usr/bin
install: cannot stat 'rtla': No such file or directory
make[4]: *** [Makefile:108: install] Error 1
make[4]: Leaving directory 
'/<>/debian/build/build-tools/tools/tracing/rtla'
make[3]: *** [/<>/debian/rules.d/tools/tracing/rtla/Makefile:11: 
install] Error 2
make[3]: Leaving directory 
'/<>/debian/build/build-tools/tools/tracing/rtla'
make[2]: *** [debia

Bug#1019117: [GFX1-]: Couldn't sanitize RENDERER device: RENOIR

[Helge Kreutzmann]

Package: plasma-workspace
Version: 4:5.25.4-3
Severity: minor

After upgrading to kernel 5.19.x I see lots of 
Sep  2 17:53:24 twentytwo ksmserver[17269]: [GFX1-]: Couldn't sanitize RENDERER 
device: RENOIR
in my logs.

So far, I haven't observed a (visual) problem.

If this message is harmless, plesae add an appropriate logcheck entry.


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

Kernel taint flags: TAINT_WARN, TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to de_DE.UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages plasma-workspace depends on:
ii  dbus-user-session [default-dbus-session-bus]1.14.0-2
ii  dbus-x11 [dbus-session-bus] 1.14.0-2
ii  drkonqi 5.25.4-1
ii  frameworkintegration5.97.0-1
ii  gdb-minimal [gdb]   12.1-3
ii  init-system-helpers 1.64
ii  iso-codes   4.11.0-1
ii  kactivitymanagerd   5.25.4-1
ii  kded5   5.97.0-1
ii  kinit   5.97.0-1
ii  kio 5.97.0-1
ii  kpackagetool5   5.97.0-1
ii  kwin-common 4:5.25.4-2
ii  libappstreamqt2 0.15.5-1
ii  libc6   2.34-7
ii  libcolorcorrect54:5.25.4-3
ii  libcrypt1   1:4.4.28-2
ii  libegl1 1.5.0-1
ii  libfontconfig1  2.13.1-4.4
ii  libfreetype62.12.1+dfsg-3
ii  libgcc-s1   12.2.0-1
ii  libgl1  1.5.0-1
ii  libgps283.22-4
ii  libice6 2:1.0.10-1
ii  libicu7171.1-3
ii  libkf5activities5   5.97.0-1
ii  libkf5activitiesstats1  5.97.0-1
ii  libkf5archive5  5.97.0-1
ii  libkf5authcore5 5.97.0-1
ii  libkf5baloo55.97.0-1
ii  libkf5bookmarks55.97.0-1
ii  libkf5calendarevents5   5.97.0-1
ii  libkf5completion5   5.97.0-1
ii  libkf5config-bin5.97.0-2
ii  libkf5configcore5   5.97.0-2
ii  libkf5configgui55.97.0-2
ii  libkf5configwidgets55.97.0-1
ii  libkf5coreaddons5   5.97.0-1
ii  libkf5crash55.97.0-1
ii  libkf5dbusaddons5   5.97.0-1
ii  libkf5declarative5  5.97.0-1
ii  libkf5globalaccel-bin   5.97.0-1
ii  libkf5globalaccel5  5.97.0-1
ii  libkf5guiaddons55.97.0-1
ii  libkf5holidays5 1:5.97.0-1
ii  libkf5i18n5 5.97.0-1
ii  libkf5iconthemes5   5.97.0-1
ii  libkf5idletime5 5.97.0-1
ii  libkf5jobwidgets5   5.97.0-1
ii  libkf5kcmutils5 5.97.0+really5.97.0-2
ii  libkf5kiocore5  5.97.0-1
ii  libkf5kiofilewidgets5   5.97.0-1
ii  libkf5kiogui5   5.97.0-1
ii  libkf5kiowidgets5   5.97.0-1
ii  libkf5networkmanagerqt6 5.97.0-1
ii  libkf5newstuff5 5.97.0-1
ii  libkf5newstuffcore5 5.97.0-1
ii  libkf5newstuffwidgets5  5.97.0-1
ii  libkf5notifications55.97.0-1
ii  libkf5notifyconfig5 5.97.0-1
ii  libkf5package5  5.97.0-1
ii  libkf5parts55.97.0-1
ii  libkf5people5   5.97.0-1
ii  libkf5peoplewidgets55.97.0-1
ii  libkf5plasma5   

Bug#1018894: rescue-mode: mounts wrong btrfs subvolume

[Philip Hands]

Pascal Hambourg  writes:

> On 03/09/2022 at 06:32, Philip Hands wrote:
>> Ansgar  writes:
>> 
>>> Source: rescue
>>> Version: 1.85
>>> Severity: important
>>>
>>> I've installed a system using btrfs for the root filesystem with d-i
>>> (with disk encryption as well). As grub wasn't properly installed
>>> (not registered with EFI), I tried to use the rescue mode to reinstall
>>> grub.
>>>
>>> However, mounting the root filesystem failed: /target contained only a
>>> "@rootfs" subdirectory. So running a shell in the target fs failed.
>>> Manually mounting the filesystem with `-o subvol=@rootfs` worked.
>>>
>>> This was with Debian 11.4.
>
>> I just pushed 1.88 including this MR:
>> 
>>https://salsa.debian.org/installer-team/rescue/-/merge_requests/1
>> 
>> which seems like it ought to address the problem you're experiencing.
>
> If I understand correctly, the problem is in mounting a btrfs root 
> filesystem.

Ah, sorry, I saw btrfs and jumped to a conclusion without noticing the
rootfs bit -- you are quite right.

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


signature.asc
Description: PGP signature

Bug#968146: ITP: golang-github-johanneskaufmann-html-to-markdown -- Convert HTML to Markdown

[Mathias Gibbens]

Control: owner -1 !

  Thanks -- just wanted to double-check before I started working on it
to ensure I wasn't duplicating any work.

Mathias


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

Bug#968146: ITP: golang-github-johanneskaufmann-html-to-markdown -- Convert HTML to Markdown

[Tong Sun]

Sure, no problem. Go ahead Mathias. Thanks

On Sat, Sep 3, 2022 at 6:39 PM Mathias Gibbens  wrote:

> Hi!
>
>   I came across this ITP, as I'm working on another golang program that
> requires it. Do you have plans to upload this library to unstable in
> the near future? If not, would it be alright if I worked on this
> package?
>
> Thanks,
> Mathias
>

Bug#1018748: reportbug: override requests offer deprecated 'extra' priority option

[Sandro Tosi]

> Untested patch below.

thanks for your patch! it would be much more useful if you could test
your patch and report back if it works, instead of delegating this
work to the maintainers.

Thanks for your understanding

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

Bug#1019030: Updating the org-drill Uploaders list

[Nicholas D Steeves]

Dear Sebastian,

As the src:org-mode maintainer, I thought you would want to know about
this bug, because org-drill used to be part of src:org-mode.

Tobias Frost  writes:

> Source: org-drill
> Version: 2.7.0+20200412+dfsg1-2
> Severity: minor
> User: m...@qa.debian.org
> Usertags: mia-teammaint
>
> Thomas Koch  is no longer maintaining org-drill.
>
> We are tracking their status in the MIA team and would like to ask you
> to remove them from the Uploaders list of the package so we can close
> that part of the file.
>
> (If the person is listed as Maintainer, what we are asking is to please
> step in as a new maintainer.)
>
> Thanks.


Regards,
Nicholas


signature.asc
Description: PGP signature

Bug#1018922: kbibtex crashes on startup

[Arnout Boelens]

Looks like it might be a QT bug:

https://bugs.kde.org/show_bug.cgi?id=433084

Bug#1019107: linux-image-5.10.0-17-amd64: iwl4965: Hardware became unavailable during restart.

[Thorsten Glaser]

Package: src:linux
Version: 5.10.136-1
Severity: important
X-Debbugs-Cc: t...@mirbsd.de

My network just ceased working, and I can’t get it back up,
even with rmmod.

More log follows. Notes (more inline):

• those “Microcode SW error detected” seem to be normal,
  I’m getting those all the time (but please fix if possible)
• I did not use the ifb devices, just modprobed it to see if
  Debian ships the LKM

Sep  4 01:17:41 x61w wpa_supplicant[1764]: wlan0: WPA: Group rekeying completed 
with 38:10:d5:48:ea:c0 [GTK=TKIP]
Sep  4 01:27:41 x61w wpa_supplicant[1764]: wlan0: WPA: Group rekeying completed 
with 38:10:d5:48:ea:c0 [GTK=TKIP]
Sep  4 01:37:41 x61w wpa_supplicant[1764]: wlan0: WPA: Group rekeying completed 
with 38:10:d5:48:ea:c0 [GTK=TKIP]
Sep  4 01:47:41 x61w wpa_supplicant[1764]: wlan0: WPA: Group rekeying completed 
with 38:10:d5:48:ea:c0 [GTK=TKIP]
Sep  4 01:57:41 x61w wpa_supplicant[1764]: wlan0: WPA: Group rekeying completed 
with 38:10:d5:48:ea:c0 [GTK=TKIP]
Sep  4 02:01:16 x61w vmunix: [1306377.643847] iwl4965 :03:00.0: Microcode 
SW error detected.  Restarting 0x8200.
Sep  4 02:01:16 x61w vmunix: [1306377.643872] iwl4965 :03:00.0: Loaded 
firmware version: 228.61.2.24
Sep  4 02:01:16 x61w vmunix: [1306377.643909] iwl4965 :03:00.0: Start IWL 
Error Log Dump:
Sep  4 02:01:16 x61w vmunix: [1306377.643921] iwl4965 :03:00.0: Status: 
0x000213E4, count: 5
Sep  4 02:01:16 x61w vmunix: [1306377.644417] iwl4965 :03:00.0: Desc
  Time   data1  data2  line
Sep  4 02:01:16 x61w vmunix: [1306377.644429] iwl4965 :03:00.0: 
NMI_INTERRUPT_WDG(0x0004) 2996016142 0x0002 0x0243 208
Sep  4 02:01:16 x61w vmunix: [1306377.644435] iwl4965 :03:00.0: pc  
blink1  blink2  ilink1  ilink2  hcmd
Sep  4 02:01:16 x61w vmunix: [1306377.64] iwl4965 :03:00.0: 0x0046C 
0x04BE0 0x004C2 0x006DE 0x04C7C 0x218001C
Sep  4 02:01:16 x61w vmunix: [1306377.644451] iwl4965 :03:00.0: FH register 
values:
Sep  4 02:01:16 x61w vmunix: [1306377.644474] iwl4965 :03:00.0:   
FH49_RSCSR_CHNL0_STTS_WPTR_REG: 0X107cea00
Sep  4 02:01:16 x61w vmunix: [1306377.644498] iwl4965 :03:00.0:  
FH49_RSCSR_CHNL0_RBDCB_BASE_REG: 0X0102c310
Sep  4 02:01:16 x61w vmunix: [1306377.644520] iwl4965 :03:00.0: 
   FH49_RSCSR_CHNL0_WPTR: 0X00f0
Sep  4 02:01:16 x61w vmunix: [1306377.644541] iwl4965 :03:00.0:   
FH49_MEM_RCSR_CHNL0_CONFIG_REG: 0X80809000
Sep  4 02:01:16 x61w vmunix: [1306377.644565] iwl4965 :03:00.0:
FH49_MEM_RSSR_SHARED_CTRL_REG: 0X003c
Sep  4 02:01:16 x61w vmunix: [1306377.644587] iwl4965 :03:00.0:  
FH49_MEM_RSSR_RX_STATUS_REG: 0X0243
Sep  4 02:01:16 x61w vmunix: [1306377.644609] iwl4965 :03:00.0:   
FH49_MEM_RSSR_RX_ENABLE_ERR_IRQ2DRV: 0X
Sep  4 02:01:16 x61w vmunix: [1306377.644631] iwl4965 :03:00.0: 
 FH49_TSSR_TX_STATUS_REG: 0X07ff0002
Sep  4 02:01:16 x61w vmunix: [1306377.644658] iwl4965 :03:00.0: 
  FH49_TSSR_TX_ERROR_REG: 0X
Sep  4 02:01:16 x61w vmunix: [1306377.646845] iwl4965 :03:00.0: Can't stop 
Rx DMA.
Sep  4 02:01:16 x61w vmunix: [1306377.646932] ieee80211 phy0: Hardware restart 
was requested
Sep  4 02:01:31 x61w vmunix: [1306392.681230] iwl4965 :03:00.0: Microcode 
SW error detected.  Restarting 0x8200.
Sep  4 02:01:31 x61w vmunix: [1306392.681245] iwl4965 :03:00.0: Loaded 
firmware version: 228.61.2.24
Sep  4 02:01:31 x61w vmunix: [1306392.681270] iwl4965 :03:00.0: Start IWL 
Error Log Dump:
Sep  4 02:01:31 x61w vmunix: [1306392.681278] iwl4965 :03:00.0: Status: 
0x000213E4, count: 5
Sep  4 02:01:31 x61w vmunix: [1306392.681451] iwl4965 :03:00.0: Desc
  Time   data1  data2  line
Sep  4 02:01:31 x61w vmunix: [1306392.681462] iwl4965 :03:00.0: 
NMI_INTERRUPT_WDG(0x0004) 3011053406 0x0002 0x0243 208
Sep  4 02:01:31 x61w vmunix: [1306392.681469] iwl4965 :03:00.0: pc  
blink1  blink2  ilink1  ilink2  hcmd
Sep  4 02:01:31 x61w vmunix: [1306392.681477] iwl4965 :03:00.0: 0x0046C 
0x04BE0 0x004C2 0x006DE 0x04C84 0x296001C
Sep  4 02:01:31 x61w vmunix: [1306392.681484] iwl4965 :03:00.0: FH register 
values:
Sep  4 02:01:31 x61w vmunix: [1306392.681507] iwl4965 :03:00.0:   
FH49_RSCSR_CHNL0_STTS_WPTR_REG: 0X107cea00
Sep  4 02:01:31 x61w vmunix: [1306392.681529] iwl4965 :03:00.0:  
FH49_RSCSR_CHNL0_RBDCB_BASE_REG: 0X0102c310
Sep  4 02:01:31 x61w vmunix: [1306392.681552] iwl4965 :03:00.0: 
   FH49_RSCSR_CHNL0_WPTR: 0X0020
Sep  4 02:01:31 x61w vmunix: [1306392.681573] iwl4965 :03:00.0:   
FH49_MEM_RCSR_CHNL0_CONFIG_REG: 0X80809000
Sep  4 02:01:31 x61w vmunix: [1306392.681595] iwl4965 :03:00.0:
FH49_MEM_RSSR_SHARED_CTRL_REG: 0X003c
Sep  4 02:01:31 x61w vmunix: [1306392.681652] iwl4965 :03:00.0:  
FH49_MEM_RSSR_RX_STATUS_REG: 0X02430

Bug#1018979: haskell-devscripts: patch to not build docs during binary-arch build

[Steve Langasek]

Package: haskell-devscripts
Version: 0.16.27
Followup-For: Bug #1018979
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu kinetic ubuntu-patch
Control: tags -1 patch

The previous patch, tragically, generates empty packages.  Please find
attached a corrected patch which doesn't try to copy the package contents
from a non-existent directory.

-- 
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
diff -Nru haskell-devscripts-0.16.27/hlibrary.mk 
haskell-devscripts-0.16.27ubuntu3/hlibrary.mk
--- haskell-devscripts-0.16.27/hlibrary.mk  2022-07-29 14:16:53.0 
-0700
+++ haskell-devscripts-0.16.27ubuntu3/hlibrary.mk   2022-09-02 
13:47:46.0 -0700
@@ -112,8 +112,6 @@
 endif
 endif
 
-DEB_BUILD_DEPENDENCIES = build-arch
-
 # We call the shell for most things, so make our variables available to it
 export DEB_SETUP_BIN_NAME
 export CABAL_PACKAGE
@@ -175,13 +173,20 @@
 
 build/%-doc:: build-haddock-stamp
 
-# FIXME: For now, we have a single install recipe, which means we have
-# to build both arch and indep (haddock) artifacts, even if we need only
-# one of them. We should split the install recipe into two.
-debian/tmp-inst-%: $(DEB_SETUP_BIN_NAME) check-ghc-stamp build-haddock-stamp
+install-%-base::
perl -d:Confess -MDebian::Debhelper::Buildsystem::Haskell::Recipes=/.*/ 
\
-   -E 'install_recipe($$ARGV[0])' "$@"
-   ln --symbolic --force "$@" debian/tmp
+   -E 'install_recipe($$ARGV[0])' "$(patsubst 
install-%-base,debian/tmp-inst-%,$@)"
+   ln --symbolic --force "$(patsubst install-%-base,debian/tmp-inst-%,$@)" 
debian/tmp
+
+install-%-arch: $(DEB_SETUP_BIN_NAME) check-ghc-stamp install-%-base
+   :
+
+# FIXME: the install_recipe doesn't work for indep-only builds, so our
+# indep target depends on the arch target for now.
+install-%-indep: $(DEB_SETUP_BIN_NAME) check-ghc-stamp build-haddock-stamp 
install-%-base
+   :
+
+debian/tmp-inst-%:: $(DEB_SETUP_BIN_NAME) check-ghc-stamp build-haddock-stamp 
install-%-base
 
 dist-hugs: $(DEB_SETUP_BIN_NAME)
$(DEB_SETUP_BIN_NAME) configure --hugs --prefix=/usr -v2 \
@@ -190,47 +195,47 @@
 build/libhugs-$(CABAL_PACKAGE):: dist-hugs
$(DEB_SETUP_BIN_NAME) build --builddir=dist-hugs
 
-install/libghc-$(CABAL_PACKAGE)-dev:: debian/tmp-inst-ghc
+install/libghc-$(CABAL_PACKAGE)-dev:: install-ghc-arch
dh_haskell_install_ghc_registration --package=$(notdir $@)
-   dh_haskell_install_development_libs --package=$(notdir $@) 
--source-dir="$<"
+   dh_haskell_install_development_libs --package=$(notdir $@) 
--source-dir="debian/tmp-inst-ghc"
dh_haskell_provides_ghc --package=$(notdir $@)
dh_haskell_depends_cabal --package=$(notdir $@)
dh_haskell_extra_depends_ghc --package=$(notdir $@)
dh_haskell_shlibdeps --package=$(notdir $@)
dh_haskell_blurbs --package=$(notdir $@) --type=dev
 
-install/libghc-$(CABAL_PACKAGE)-prof:: debian/tmp-inst-ghc
-   dh_haskell_install_profiling_libs --package=$(notdir $@) 
--source-dir="$<"
+install/libghc-$(CABAL_PACKAGE)-prof:: install-ghc-arch
+   dh_haskell_install_profiling_libs --package=$(notdir $@) 
--source-dir="debian/tmp-inst-ghc"
dh_haskell_provides_ghc --package=$(notdir $@) 
--config-shipper="libghc-$(CABAL_PACKAGE)-dev"
dh_haskell_depends_cabal --package=$(notdir $@) 
--config-shipper="libghc-$(CABAL_PACKAGE)-dev"
dh_haskell_blurbs --package=$(notdir $@) --type=prof
 
-install/libghc-$(CABAL_PACKAGE)-doc:: debian/tmp-inst-ghc
-   dh_haskell_install_htmldocs --package=$(notdir $@) --source-dir="$<"
-   dh_haskell_install_haddock --package=$(notdir $@) --source-dir="$<"
+install/libghc-$(CABAL_PACKAGE)-doc:: install-ghc-indep
+   dh_haskell_install_htmldocs --package=$(notdir $@) 
--source-dir="debian/tmp-inst-ghc"
+   dh_haskell_install_haddock --package=$(notdir $@) 
--source-dir="debian/tmp-inst-ghc"
dh_haskell_depends_haddock --package=$(notdir $@)
dh_haskell_recommends_documentation_references --package=$(notdir $@)
dh_haskell_suggests --package=$(notdir $@)
dh_haskell_blurbs --package=$(notdir $@) --type=doc
 
-install/libghcjs-$(CABAL_PACKAGE)-dev:: debian/tmp-inst-ghcjs
+install/libghcjs-$(CABAL_PACKAGE)-dev:: install-ghcjs-arch
dh_haskell_install_ghc_registration --package=$(notdir $@)
-   dh_haskell_install_development_libs --package=$(notdir $@) 
--source-dir="$<"
+   dh_haskell_install_development_libs --package=$(notdir $@) 
--source-dir="debian/tmp-inst-ghcjs"
dh_haskell_provides_ghc --package=$(notdir $@)
dh_haskell_depends_cabal --package=$(notdir $@)
dh_haskell_extra_depends_ghc --package=$(notdir $@)
dh

Bug#1018894: rescue-mode: mounts wrong btrfs subvolume

[Nicholas D Steeves]

Pascal Hambourg  writes:
> On 03/09/2022 at 06:32, Philip Hands wrote:
>> Ansgar  writes:
>>
[snip]
>>>
>>> However, mounting the root filesystem failed: /target contained only a
>>> "@rootfs" subdirectory. So running a shell in the target fs failed.
>>> Manually mounting the filesystem with `-o subvol=@rootfs` worked.
>>>
>>> This was with Debian 11.4.
>
>> I just pushed 1.88 including this MR:
>> 
>>https://salsa.debian.org/installer-team/rescue/-/merge_requests/1
>> 
>> which seems like it ought to address the problem you're experiencing.
>
> If I understand correctly, the problem is in mounting a btrfs root 
> filesystem. However the change in rescue 1.88 addresses only mounting 
> extra filesystems such as /boot/efi or separate /usr.
>
> I guess that handling btrfs subvolumes or other root filesystem mount 
> options would require changes in the root file system selection step. I 
> do not see how it could be automated (rootflags are defined in the boot 
> loader configuration which may be located anywhere).

This can be automated with limitations, or semiautomated (with a menu),
like LVM.

First, the automated case: Currently DI statically sets the rootfs to be
"subvolume=@rootfs", which is a value unique to Debian.  The simple
thing to do is to detect that a device has been formatted to btrfs
before mounting, and then try to mount "-o subvol=@rootfs" as Ansgar
suggested.  One step more flexible is to have a Rescue policy of
something like only supporting read-write subvolumes with a name that
matches '.*\@rootfs.*', and that exist in the / of the volume.  Ie:
maxdepth=1.

To do more, we need a mechanism to detect [bootable] subvolumes and then
present a menu of candidates while excluding read-only snapshot and
non-bootable and irrelevant subvolumes.  Ie: Rather than try, and bail on
failure, create a whitelist and present that to the user.  A user with
poor subvolume hygiene may have thousands of read-only snapshots of
their rootfs, and it is not useful to overflow the terminal with a
selection menu of these almost entirely irrelevant items.

Would (/bin/mount AND /etc/fstab) be useful for this?  Ie: This may be
enough for Pascal's work to find everything else that is needed (other
than the subvolume=foo specification).  If the sysadmin/user botched
their fstab then this will fail; however, the discussion I had on
debian-boot (possibly on IRC) indicates that this is a non-issue,
because "rescue" is only expected to reinstall the bootloader.  What do
you think?

ISTM that the rescue media should test for an actual Debian installation
with something like:

  awk '{print $1}' < /MOUNTPOINT/etc/issue
  or perhaps
  grep 'ID\=debian' < /etc/os-release

as well as to test for /bin/mount, and /etc/fstab.  These days I'm not
sure what the minimally complete criteria would be...

At any rate, regarding the btrfs subvolume detection (ie: lvdisplay
equivalent, and no, not a PITA at all, this is the easy part.), there
are three approaches:

1. Use the "btrfs" tool, and parse its output
   * I can do this, but will need help/review for the DI idioms
   ! Prerequisite: mount the FS someplace temporary, or teach rescue how
   to remount /target.  Bind-mounting rootfs with *not* work.
2. Use `find` various btrfs-specific-type detection functions
   * I wrote these long ago, because I saw a future need for them
   * probably limit search depth to not waste time!
   ! Prerequisite: mount the FS someplace temporary,or teach rescue how
   to remount /target.  Bind-mounting rootfs will *not* work.
3. Write something that uses python-btrfs
   * Someone else can do this if it looks like it would be the most
   robust approach

For now, I also recommend declaring that a specific set and type of
layouts are supported.  When DI gains subvolume layout support, it may
be wise for it to exclusively support a particular schema. The
definition of supported configurations could of course be expanded in
the future.

The hard part: For example, when mounted without "-o subvol=@rootfs"
(ie: the "top-down admin view that I recommend using /btrfs-admin for on
a running system), a volume mounted at /MOUNTPOINT may contain the
following completely valid and bootable subvolumes/environments:

  @rootfs  # which is presumably Debian stable with a default installation
  @rootfs_buster # a RO snapshot made before upgrading to bullseye?
* This one is probably still bootable, with warnings
  @rootfs_sid # custom bootable subvolume probably created with
debootstrap
* Like a schroot with installed kernel...actually, with a separate
  /boot, a subvolume dedicated to a sid schroot may actually be bootable.
  @# Ubuntu
  rootfs   # Fedora


Given /\, the menu presented by Rescue should look something like like:
  ||
  \\sda1
  ||
   1) @rootfs
   2) @rootfs_sid

   Select a subvolume (and press Return/Enter): 

But a user may have customised things to look more like the

Bug#1019106: gnome-initial-setup: Needs updating for evolution-data-server 3.46

[Jeremy Bicha]

Source: gnome-initial-setup
Version: 42.2-1
Severity: serious
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: evolution-3.46

gnome-initial-setup needs to be updated for the big
evolution-data-server transition (which switches to libsoup3 and
librest 0.9).

This is done in the 43 version but the 43 version also requires the
GTK4 version of webkit2gtk (the 5.0 API) which is only built in
Experimental currently.

Therefore, my plan is for gnome-initial-setup to become temporarily
uninstallable in Unstable and removed from Testing until webkit2gtk
2.38 is uploaded to Unstable later this month. This allows us to
complete the rest of the transition.

Thank you,
Jeremy Bicha

Bug#1019090: librust-petgraph-dev: impossible to satisfy dependency

[Peter Michael Green]

There is a new upstream version of petgraph that uses the new version of 
fixedbitset, I suspect the most sensible way to fix this bug is 
uploading it and it has been prepared in debcargo-conf (initially 
byBlair Noctis with some further tweaking by myself)


However before I upload it, I wanted to check the reverse dependencies, 
I go started on doing so but rust-cargo-lock proved to be a fair bit of 
effort to update. I'll probablly look at the remaining packages soon, 
but if others want to take a look that is fine too.


rust-cargo-lock - update prepared in debcargo-conf (along with updates 
for gumdrop and gumdrop-derive which it depends on)

rust-lalrpop -update prepared in debcargo-conf
rust-rust-code-analysis - already broken and not in testing.
rust-tree-magic - update prepared in debcargo-conf
rust-tree-magic-mini - fixed upstream, but Debian packaging not 
investigated yet.

librust-ena+congruence-closure-dev - not investigated yet
librust-parking-lot-core+petgraph-dev - already depends on new version 
of petgraph

librust-parking-lot-core-0.4+petgraph-dev - not investigated yet
rust-code-analysis-cli - indirect depedency/built-using, already broken 
and not in testing.

Bug#1019061: gnuplot-data not available

[Vincent Lefevre]

Control: retitle -1 gnuplot and gnuplot-data not available
Control: reassign -1 src:gnuplot 5.4.4+dfsg1-1

This is actually a problem for the binary packages gnuplot-qt,
gnuplot-x11 and gnuplot-nox. The gnuplot metapackage is not
available either, while it is still mentioned at

  https://packages.debian.org/source/unstable/gnuplot

(but this one would not alone prevent an upgrade).

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

Bug#1019061: gnuplot-data not available

[Vincent Lefevre]

Control: severity -1 serious

Hi,

On 2022-09-03 15:51:49 +0200, alberto wrote:
> Dear Maintainer,
> 
> it looks like gnuplot-data is not available anymore (at least from version
> 5.4.4-gfsg1-1). This makes gnuplot (any flavour) uninstallable.
> 
> I'm surprised I could not find any report on this on the debian bugtracking
> system. Is there anything I'm missing about this package?

I've noticed the same issue for several days. I thought that this
was just temporary, but apparently, after 14 days, it isn't.

> In any case, if I'm not wrong, this "bug" (maybe just a delay in packaging
> the new version?) is far more than "important" because it makes the package
> unusable.

I agree. It is not installable. So this should be a RC bug.
I'm increasing the severity.

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

Bug#1019105: RFP: lossless-cut -- Swiss army knife of lossless video/audio editing

[Joao Eriberto Mota Filho]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: Mikael Finstad 

* Package name: lossless-cut
  Upstream Author : Mikael Finstad 
* URL : https://github.com/mifi/lossless-cut
* License : GPL-2
  Programming Lang: JavaScript
  Description : Swiss army knife of lossless video/audio editing

LosslessCut aims to be the ultimate cross platform FFmpeg GUI for extremely
fast and lossless operations on video, audio, subtitle and other related media
files. The main feature is lossless trimming and cutting of video and audio
files, which is great for saving space by rough-cutting your large video files
taken from a video camera, GoPro, drone, etc. It lets you quickly extract the
good parts from your videos and discard many gigabytes of data without doing a
slow re-encode and thereby losing quality. Or you can add a music or subtitle
track to your video without needing to encode. Everything is extremely fast
because it does an almost direct data copy, fueled by the awesome FFmpeg which
does all the grunt work.

Features

* Lossless cutting of most video and audio formats.
* Smart cut (experimental).
* Losslessly cut out parts of video/audio (for cutting away commercials
  etc.)
* Losslessly rearrange the order of video/audio segments.
* Lossless merge/concatenation of arbitrary files (with identical codecs
  parameters, e.g. from the same camera).
* Lossless stream editing:
- Combine arbitrary tracks from multiple files (ex. add music or
  subtitle track to a video file).
- Remove unneeded tracks.
- Replace or re-encode only some tracks.
- Extract all tracks from a file (extract video, audio, subtitle,
  attachments and other tracks from one file into separate files).
* Batch view for fast multi-file workflow.
* Keyboard shortcut workflow.
* Losslessly remux video/audio into a different container (file) format.
* Take full-resolution snapshots from videos in JPEG/PNG format, or export
  ranges of video frames to images.
* Manual input of cutpoint times.
* Apply a per-file timecode offset (and auto load timecode from file).
* Edit file metadata, per-track metadata and per-track disposition.
* Change rotation/orientation metadata in videos.
* View technical data about all tracks.
* Timeline zoom and frame/keyframe jumping for cutting around keyframes.
* Video thumbnails and audio waveform.
* Saves per project cut segments to project file.
* View FFmpeg last command log so you can modify and re-run recent commands
  on the command line.
* Undo/redo.
* Give labels to cut segments.
* Annotate segments with tags.
* Import/export segments: MP4/MKV chapter marks, Text file, YouTube, CSV,
  CUE, XML (DaVinci, Final Cut Pro) and more.
* MKV/MP4 embedded chapters marks editor.
* View subtitles.
* Customizable keyboard hotkeys.
* Black scene detection.
* Divide timeline into segments with length L or into N segments or even
  randomized segments!

Example lossless use cases

* Cut out commercials from a recorded TV show (and re-format from TS to
  MP4).
* Remove audio tracks from a file.
* Extract music track from a video and cut it to your needs.
* Add music to a video (or replace existing audio track).
* Combine audio and video tracks from separate recordings.
* Include an external subtitle into a video.
* Quickly change a H264/H265 MKV video to MOV or MP4 for playback on
  iPhone.
* Import a list of cut times from other tool as a EDL (edit decision list,
  CSV) and run these cuts with LosslessCut.
* Export a list of cut times as a CSV EDL and process these in another
  tool.
* Quickly cut a file by its MP4/MKV chapters.
* Quickly cut a YouTube video by its chapters (or music times from a
  comment).
* Change the language of a file's audio/subtitle tracks.
* Attach cover art to videos.
* Change author, title, GPS position, recording time of a video.
* Fix rotation of a video that has the wrong orientation flag set
- Great for rotating phone videos that come out the wrong way without
  actually re-encoding the video.
* Loop a video / audio clip X times quickly without re-encoding.
* Convert a video or parts of it into X image files (not lossless).


WARNING: Problem to package it for Debian: lossless-cut build depends of
 electron. See #842420.

Bug#984256: nextepc: diff for NMU version 0.3.10+nods-4.2

[Sudip Mukherjee]

Control: tags 984256 + pending
--

Dear maintainer,

I've prepared an NMU for nextepc (versioned as 0.3.10+nods-4.2) and
uploaded it to DELAYED/5. Please feel free to tell me if I
should delay it longer.

--
Regards
Sudip

diff -Nru nextepc-0.3.10+nods/debian/changelog 
nextepc-0.3.10+nods/debian/changelog
--- nextepc-0.3.10+nods/debian/changelog2021-02-06 16:02:21.0 
+
+++ nextepc-0.3.10+nods/debian/changelog2022-09-04 00:29:25.0 
+0100
@@ -1,3 +1,11 @@
+nextepc (0.3.10+nods-4.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix ftbfs with GCC-11. (Closes: #984256)
+- Thanks Steve for the patch.
+
+ -- Sudip Mukherjee   Sun, 04 Sep 2022 00:29:25 
+0100
+
 nextepc (0.3.10+nods-4.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru nextepc-0.3.10+nods/debian/patches/gcc-11.patch 
nextepc-0.3.10+nods/debian/patches/gcc-11.patch
--- nextepc-0.3.10+nods/debian/patches/gcc-11.patch 1970-01-01 
01:00:00.0 +0100
+++ nextepc-0.3.10+nods/debian/patches/gcc-11.patch 2022-09-04 
00:23:48.0 +0100
@@ -0,0 +1,27 @@
+Description: fix build failure with gcc-11.
+Author: Steve Langasek 
+Bug-Debian: https://bugs.debian.org/984256
+Last-Update: 2021-11-18
+
+Index: nextepc-0.3.10+nods/lib/core/test/testatomic.c
+===
+--- nextepc-0.3.10+nods.orig/lib/core/test/testatomic.c
 nextepc-0.3.10+nods/lib/core/test/testatomic.c
+@@ -100,7 +100,7 @@
+ 
+ static void test_casptr_equal_nonnull(abts_case *tc, void *data)
+ {
+-int a, b;
++int a = 0, b = 0;
+ void *target_ptr = &a;
+ void *old_ptr;
+ 
+@@ -111,7 +111,7 @@
+ 
+ static void test_casptr_notequal(abts_case *tc, void *data)
+ {
+-int a, b;
++int a = 0, b = 0;
+ void *target_ptr = &a;
+ void *old_ptr;
+ 
diff -Nru nextepc-0.3.10+nods/debian/patches/series 
nextepc-0.3.10+nods/debian/patches/series
--- nextepc-0.3.10+nods/debian/patches/series   2021-01-23 22:35:09.0 
+
+++ nextepc-0.3.10+nods/debian/patches/series   2022-09-04 00:23:48.0 
+0100
@@ -5,3 +5,4 @@
 0005-Set-install-dir-for-freediameter-libs.patch
 0006-Fix-big-endian-bug.patch
 0007-Patch-deprecated-sys-sysctl.h-problem.patch
+gcc-11.patch

Bug#1019104: ITP: golang-github-toorop-go-dkim -- DKIM package for golang

[Mathias Gibbens]

Package: wnpp
Severity: wishlist
Owner: Mathias Gibbens 
X-Debbugs-CC: debian-de...@lists.debian.org, debian...@lists.debian.org

* Package name: golang-github-toorop-go-dkim
  Version : 0.0~git20201103.e1cd1a0-1
  Upstream Author : Stéphane Depierrepont
* URL : https://github.com/toorop/go-dkim
* License : Expat
  Programming Lang: Go
  Description : DKIM package for golang
 This library provides tools for signing and verifying an email
according to RFC 6376.

This is a dependency for packaging golang-github-xhit-go-simple-mail
(ITP #1019103) and will be team-maintained within the Go Packaging
Team.


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

Bug#1019103: ITP: golang-github-xhit-go-simple-mail -- Package for sending email; supports keep alive, TLS and SSL

[Mathias Gibbens]

Package: wnpp
Severity: wishlist
Owner: Mathias Gibbens 
X-Debbugs-CC: debian-de...@lists.debian.org, debian...@lists.debian.org

* Package name: golang-github-xhit-go-simple-mail
  Version : 2.11.0-1
  Upstream Author : Santiago De la Cruz
* URL : https://github.com/xhit/go-simple-mail
* License : Expat and BSD-3-clause
  Programming Lang: Go
  Description : Package for sending email; supports keep alive, TLS and SSL
 Go Simple Mail is a simple and efficient package to send emails. It is
 well tested and documented.
 .
 Go Simple Mail can only send emails using an SMTP server. But the API
 is flexible and it is easy to implement other methods for sending
 emails using a local Postfix, an API, etc.

This is a dependency for packaging commentoplusplus (ITP #951557) and
will be team-maintained within the Go Packaging Team.


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

Bug#1019102: ITP: golang-github-adtac-go-akismet -- Go library for accessing the Akismet API

[Mathias Gibbens]

Package: wnpp
Severity: wishlist
Owner: Mathias Gibbens 
X-Debbugs-CC: debian-de...@lists.debian.org, debian...@lists.debian.org

* Package name: golang-github-adtac-go-akismet
  Version : 0.0~git20181220.0ca9e10-1
  Upstream Author : Adhityaa Chandrasekar
* URL : https://github.com/adtac/go-akismet
* License : Expat
  Programming Lang: Go
  Description : Library for accessing the Akismet API

 go-akismet is a Go client library for accessing the Akismet API
(v1.1).

This is a dependency for packaging commentoplusplus (ITP #951557) and
will be team-maintained within the Go Packaging Team.


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

Bug#951557: RFP: commento -- fast, bloat-free comments platform

[Mathias Gibbens]

Control: retitle -1 ITP: commentoplusplus -- Fast, bloat-free comments platform
Control: owner -1 !

  I use commento, and am interested in getting it included in Debian.
The upstream project seems to be abandoned, but there is an actively-
maintained fork of the project at
https://github.com/souramoo/commentoplusplus. Current targeted package
information:

* Package name: commentoplusplus
  Version : 1.8.7-1
  Upstream Author : Souradip Mookerjee
* URL : https://github.com/souramoo/commentoplusplus
* License : Expat
  Programming Lang: Go, Javascript
  Description : Fast, bloat-free comments platform

Thanks,
Mathias


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

Bug#1017959: RFP: meson-python -- Meson PEP 517 Python build backend

[Drew Parsons]

On 2022-09-03 20:08, Simon McVittie wrote:
Control: retitle -1 ITP: meson-python -- Meson PEP 517 Python build 
backend

Control: owner -1 !

On Tue, 23 Aug 2022 at 01:25:49 +0200, Drew Parsons wrote:

* Package name: meson-python
  Description : Meson PEP 517 Python build backend


I started looking at this because I've wondered whether to use it for
dbus-python. Work in progress:
https://salsa.debian.org/python-team/packages/meson-python
(not really tested yet, I don't yet have an upstream project that
needs it).


Great you've already got it started!


Co-maintainers welcome; Drew, would you be interested?


For myself, I feel fully loaded with packages, would be better if I can 
step back and let others pick it up.  I can help keep an eye on it 
though as a Team Member, can do uploads when there are critical 
problems.


Drew

Bug#968146: ITP: golang-github-johanneskaufmann-html-to-markdown -- Convert HTML to Markdown

[Mathias Gibbens]

Hi!

  I came across this ITP, as I'm working on another golang program that
requires it. Do you have plans to upload this library to unstable in
the near future? If not, would it be alright if I worked on this
package?

Thanks,
Mathias


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

Bug#1018717: orage: extra informations

[Unit 193]

Control: severity -1 normal
Control: forwarded -1 https://gitlab.xfce.org/apps/orage/-/issues/2

Howdy,

Thanks for providing some information and testing on unstable, I was about 
to close the bug report as it lacked any information and was clearly a 
FrankenDebian[0].


What you're seeing is due to the fact that orage doesn't yet support 
Wayland.  As orage's target is the Xfce desktop (as shown by being an Xfce 
app, and the description has it all over) this is somewhat to be expected 
as Xfce itself doesn't have support for Wayland.


This bug will likely be fixed in due time as different aspects of Xfce 
gain support for Wayland, and can be tracked on the upstream bug 
report[1].



[0]: https://wiki.debian.org/DontBreakDebian
[1]: https://gitlab.xfce.org/apps/orage/-/issues/2

~Unit 193
Unit193 @ Libera
Unit193 @ OFTC

Bug#1017063: fixed in gjs 1.73.1-2

[Paul Gevers]

Hi Jeremy,

On Sat, 13 Aug 2022 01:48:54 + Debian FTP Masters 
 wrote:

 gjs (1.73.1-2) unstable; urgency=medium
 .
   * Rebuild against latest mozjs91 (Closes: #1017063)


You forgot to enforce this with a *versioned* build dependency and now 
armhf got build with the old version.


But anyways. This smells a bit like an ABI breakage. Did something go 
wrong with mozjs91? And maybe we want to prevent issues during partial 
upgrades, then mozjs91 should break the old version of gjs.


Normally no-change rebuilds are handled as binNMU's by the Release Team, 
is there any particular reason why you didn't do that?


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1019100: dhcpcd5: dhcpcd fails to detect link-local IPv6 address if it has a 128-bit prefix

[Giorgos Skafidas]

Package: dhcpcd5
Version: 9.4.1-6
Severity: normal
Tags: ipv6
X-Debbugs-Cc: giorgos@skafidas.online

Dear Maintainer,

I use dhcpcd on two systems acting as routers to obtain IPv6 prefixes from ISPs 
and assign them to LAN interfaces.

Both systems use pppd (2.4.9-1+1.1+b1) to create PPPoE connections. Pppd uses a 
128-bit prefix length for the link-local address assigned to the PPPoE 
interface.

dhcpcd 9.4.1-6 hangs at "delaying DHCPv6 for LL address" indefinitely. 9.4.1-5 
works fine.

After trying other things, I manually added a /64 (rather than /128) link-local 
address to the PPPoE interface. Dhcpcd picked this up immediately and proceeded 
with DHCPv6 prefix delegation.

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

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

Versions of packages dhcpcd5 depends on:
ii  dhcpcd-base  9.4.1-6
ii  lsb-base 11.2

dhcpcd5 recommends no packages.

Versions of packages dhcpcd5 suggests:
pn  dhcpcd-gtk   
pn  openresolv | resolvconf  

-- no debconf information

Bug#1010578: currently FTBFS

[Paul Gevers]

Control: severity 1010578 serious

Hi,

As can be seen on 
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/osmo-mgw.html, 
this now happens to be the case.


Yes, it will probably be fixed, but it may take a while (see bug #1017441).

Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1012219: Please adjust StanHeaders to new version of (one)tbb

[Nilesh Patra]

Hi all,

On 9/3/22 22:06, Benjamin K Goodrich wrote:

Sorry for the late reply. I am told that StanHeaders can be built
successfully with oneTBB by setting environmental variables like
TBB_INC and TBB_LIB. On CRAN, we would like to use the version of TBB
that comes with the RcppParallel package
[...]


Thanks for the pointers, but
we are able to build cppparallel and stanheaders without problems as is. But 
the built package is
unusable as it uses "#include" statements that try to include files available 
in older tbb but
not in new onetbb, as observed in rstan compilation.

The problematic #include statment (and corresponding removed APIs) seems to be 
stemming from
"inst/include/stan/math/prim/core/init_threadpool_tbb.hpp"

On taking a deeper look, I observed that this is directly embedded from 
stan/math[1]
The current release of stanheaders contains an older copy of the math lib.
Going fwd, a patch had been added to stan/math to make it compatible with 
onetbb[2]
On cherry-picking a couple of changes from there, I am able to get rstan to 
compile.

I am not very sure if everything is good/works as expected (autopkgtests / CRAN 
tests seem
to pass, so that's a good indication), but I'd be thrilled to believe so.

[1]: https://github.com/stan-dev/math
[2]: 
https://github.com/stan-dev/math/commit/6f94b2a70d11276a53e5b5bc4100d3ffa524b96c

--
Best,
Nilesh


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1018214: rocksdb 6.11.4-3+deb11u1 flagged for acceptance

[Adam D Barratt]

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

Hi,

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

Thanks for your contribution!

Upload details
==

Package: rocksdb
Version: 6.11.4-3+deb11u1

Explanation: fix illegal instruction on arm64

Bug#1018162: fig2dev 3.2.8-3+deb11u1 flagged for acceptance

[Adam D Barratt]

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

Hi,

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

Thanks for your contribution!

Upload details
==

Package: fig2dev
Version: 3.2.8-3+deb11u1

Explanation: fix double free issue [CVE-2021-37529], denial of service issue 
[CVE-2021-37530]; stop misplacement of embedded eps images

Bug#963901: ITA: glm -- C++ library for OpenGL GLSL type-based mathematics

[Anton Gladky]

Hi Andrea,

thanks for taking care of this package! Really appreciate it.

Please, follow an advices given by Pierre and we will upload
the package, giving you permissions to upload it in the future.

It could also be good if you add salsa-CI to be sure that the package
is building aod passing all tests. It is also an additional tests for you,

Best regards

Anton


Am Fr., 2. Sept. 2022 um 22:13 Uhr schrieb Andrea Pappacoda <
and...@pappacoda.it>:

> Hi everyone!
>
> I've been wanting to adopt the glm package, maintained by the Science
> Team, since last September.
>
> I'm a DM, so I can't directly take ownership of the package nor push to
> Salsa. Could somebody please look at my changes, give me write access
> to the repo and possibly sponsor the first upload? You can find my
> changes here:
> 
>
> I've already asked this on IRC, and joostvb, while approving my changes
> in general, said that it would've been better to ask this on the
> mailing list.
>
> Thanks in advance :)
>
> --
> OpenPGP key: 66DE F152 8299 0C21 99EF  A801 A8A1 28A8 AB1C EE49
>
>
>

Bug#1018971: poppler: diff for NMU version 22.08.0-2.1

[Salvatore Bonaccorso]

Control: tags 1018971 + patch
Control: tags 1018971 + pending

Dear maintainer,

I've prepared an NMU for poppler (versioned as 22.08.0-2.1) and
uploaded it to DELAYED/5. Please feel free to tell me if I
should delay it longer.

Regards,
Salvatore
diff -Nru poppler-22.08.0/debian/changelog poppler-22.08.0/debian/changelog
--- poppler-22.08.0/debian/changelog	2022-08-21 19:13:33.0 +0200
+++ poppler-22.08.0/debian/changelog	2022-09-03 21:30:51.0 +0200
@@ -1,3 +1,10 @@
+poppler (22.08.0-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * JBIG2Stream: Fix crash on broken file (CVE-2022-38784) (Closes: #1018971)
+
+ -- Salvatore Bonaccorso   Sat, 03 Sep 2022 21:30:51 +0200
+
 poppler (22.08.0-2) unstable; urgency=medium
 
   * Team upload
diff -Nru poppler-22.08.0/debian/patches/JBIG2Stream-Fix-crash-on-broken-file.patch poppler-22.08.0/debian/patches/JBIG2Stream-Fix-crash-on-broken-file.patch
--- poppler-22.08.0/debian/patches/JBIG2Stream-Fix-crash-on-broken-file.patch	1970-01-01 01:00:00.0 +0100
+++ poppler-22.08.0/debian/patches/JBIG2Stream-Fix-crash-on-broken-file.patch	2022-09-03 21:29:13.0 +0200
@@ -0,0 +1,34 @@
+From: Albert Astals Cid 
+Date: Thu, 25 Aug 2022 00:14:22 +0200
+Subject: JBIG2Stream: Fix crash on broken file
+Origin: https://gitlab.freedesktop.org/poppler/poppler/-/commit/27354e9d9696ee2bc063910a6c9a6b27c5184a52
+Bug-Debian: https://bugs.debian.org/1018971
+Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2022-38784
+
+https://github.com/jeffssh/CVE-2021-30860
+
+Thanks to David Warren for the heads up
+---
+ poppler/JBIG2Stream.cc | 6 +-
+ 1 file changed, 5 insertions(+), 1 deletion(-)
+
+diff --git a/poppler/JBIG2Stream.cc b/poppler/JBIG2Stream.cc
+index 662276e547eb..9f70431de49e 100644
+--- a/poppler/JBIG2Stream.cc
 b/poppler/JBIG2Stream.cc
+@@ -1976,7 +1976,11 @@ void JBIG2Stream::readTextRegionSeg(unsigned int segNum, bool imm, bool lossless
+ for (i = 0; i < nRefSegs; ++i) {
+ if ((seg = findSegment(refSegs[i]))) {
+ if (seg->getType() == jbig2SegSymbolDict) {
+-numSyms += ((JBIG2SymbolDict *)seg)->getSize();
++const unsigned int segSize = ((JBIG2SymbolDict *)seg)->getSize();
++if (unlikely(checkedAdd(numSyms, segSize, &numSyms))) {
++error(errSyntaxError, getPos(), "Too many symbols in JBIG2 text region");
++return;
++}
+ } else if (seg->getType() == jbig2SegCodeTable) {
+ codeTables.push_back(seg);
+ }
+-- 
+2.37.2
+
diff -Nru poppler-22.08.0/debian/patches/series poppler-22.08.0/debian/patches/series
--- poppler-22.08.0/debian/patches/series	2022-08-21 19:13:33.0 +0200
+++ poppler-22.08.0/debian/patches/series	2022-09-03 21:29:22.0 +0200
@@ -1 +1,2 @@
 segfault-on-unset-catalog.patch
+JBIG2Stream-Fix-crash-on-broken-file.patch

Bug#1019099: rust-ahash - autopkgtest failure

[Peter Michael Green]

Package: rust-ahash
Version: 0.7.6-4
Severity: serious

The autopkgtest of rust-ahash is failing

https://ci.debian.net/data/autopkgtest/testing/amd64/r/rust-ahash/25673987/log.gz


Testing aeshash/u8
thread 'main' panicked at 'aes must be enabled', tests/bench.rs:20:5
stack backtrace:
0: std::panicking::begin_panic
  at /usr/src/rustc-1.59.0/library/std/src/panicking.rs:525:12
1: ahash::aeshash
  at ./tests/bench.rs:20:5
2: ahash::bench_ahash::{{closure}}::{{closure}}
  at ./tests/bench.rs:92:81
3: criterion::bencher::Bencher::iter
  at 
/tmp/tmp.wNUW0kfuKe/registry/criterion-0.3.5/src/bencher.rs:88:23
4: ahash::bench_ahash::{{closure}}
  at ./tests/bench.rs:89:54
5:  as 
criterion::routine::Routine>::bench::{{closure}}
  at 
/tmp/tmp.wNUW0kfuKe/registry/criterion-0.3.5/src/routine.rs:209:17
6: core::iter::adapters::map::map_fold::{{closure}}
  at 
/usr/src/rustc-1.59.0/library/core/src/iter/adapters/map.rs:84:28
7: core::iter::traits::iterator::Iterator::fold
  at 
/usr/src/rustc-1.59.0/library/core/src/iter/traits/iterator.rs:2171:21
8:  as 
core::iter::traits::iterator::Iterator>::fold
  at 
/usr/src/rustc-1.59.0/library/core/src/iter/adapters/map.rs:124:9
9: core::iter::traits::iterator::Iterator::for_each
  at 
/usr/src/rustc-1.59.0/library/core/src/iter/traits/iterator.rs:736:9
   10:  as 
alloc::vec::spec_extend::SpecExtend>::spec_extend
  at 
/usr/src/rustc-1.59.0/library/alloc/src/vec/spec_extend.rs:40:17
   11:  as 
alloc::vec::spec_from_iter_nested::SpecFromIterNested>::from_iter
  at 
/usr/src/rustc-1.59.0/library/alloc/src/vec/spec_from_iter_nested.rs:56:9
   12:  as 
alloc::vec::spec_from_iter::SpecFromIter>::from_iter
  at 
/usr/src/rustc-1.59.0/library/alloc/src/vec/spec_from_iter.rs:33:9
   13:  as 
core::iter::traits::collect::FromIterator>::from_iter
  at /usr/src/rustc-1.59.0/library/alloc/src/vec/mod.rs:2541:9
   14: core::iter::traits::iterator::Iterator::collect
  at 
/usr/src/rustc-1.59.0/library/core/src/iter/traits/iterator.rs:1745:9
   15:  as 
criterion::routine::Routine>::bench
  at 
/tmp/tmp.wNUW0kfuKe/registry/criterion-0.3.5/src/routine.rs:205:9
   16: criterion::routine::Routine::test
  at 
/tmp/tmp.wNUW0kfuKe/registry/criterion-0.3.5/src/routine.rs:18:9
   17: criterion::benchmark_group::BenchmarkGroup::run_bench
  at 
/tmp/tmp.wNUW0kfuKe/registry/criterion-0.3.5/src/benchmark_group.rs:339:21
   18: criterion::benchmark_group::BenchmarkGroup::bench_with_input
  at 
/tmp/tmp.wNUW0kfuKe/registry/criterion-0.3.5/src/benchmark_group.rs:269:9
   19: ahash::bench_ahash
  at ./tests/bench.rs:87:5
   20: ahash::benches
  at 
/tmp/tmp.wNUW0kfuKe/registry/criterion-0.3.5/src/macros.rs:71:17
   21: ahash::main
  at 
/tmp/tmp.wNUW0kfuKe/registry/criterion-0.3.5/src/macros.rs:127:17
   22: core::ops::function::FnOnce::call_once
  at /usr/src/rustc-1.59.0/library/core/src/ops/function.rs:227:5
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose 
backtrace.

error: test failed, to rerun pass '--bench ahash'
autopkgtest [16:38:41]: test 
librust-ahash+compile-time-rng-dev:compile-time-rng: ---]
autopkgtest [16:38:41]: test 
librust-ahash+compile-time-rng-dev:compile-time-rng:  - - - - - - - - - - 
results - - - - - - - - - -
librust-ahash+compile-time-rng-dev:compile-time-rng FAIL non-zero exit status 
101
autopkgtest [16:38:41]:  summary
rust-ahash:@ FAIL non-zero exit status 101
librust-ahash-dev:default FAIL non-zero exit status 101
librust-ahash-dev:std FAIL non-zero exit status 101
librust-ahash-dev:   FAIL non-zero exit status 101
librust-ahash+compile-time-rng-dev:compile-time-rng FAIL non-zero exit status 
101


Thanks to an annoyance with the way testing migration autopkgtests 
interact with skip-not-installable this is blocking the migration of the 
new version of rust-once-cell to testing. So we would appreciate a quick 
fix.

Bug#1019098: src:tbb: do not migrate. this source is deprecated in favor of src:onetbb

[M. Zhou]

Source: tbb
Version: 2020.3-2.1
Severity: serious

src:tbb: do not migrate. this source is deprecated in favor of
src:onetbb. The RM bug of src:tbb is filed at
https://bugs.debian.org/1014990

Bug#1019097: RFS: rrep/1.3.6-3 -- recursive pattern replacement utility

[Arno Onken]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: rrep
   Version : 1.3.6-3
   Upstream Author : Arno Onken 
 * URL : https://sourceforge.net/projects/rrep/
 * License : GFDL-1.3+, GPL-3+, permissive
 * Vcs : https://sourceforge.net/p/rrep/code/
   Section : utils

The source builds the following binary packages:

  rrep - recursive pattern replacement utility

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

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

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

  dget -x https://mentors.debian.net/debian/pool/main/r/rrep/rrep_1.3.6-3.dsc

Changes since the last upload:

 rrep (1.3.6-3) unstable; urgency=low
 .
   * Fixed spelling mistake and character omission.
   * Updated debhelper-compat-version to 13.
   * Updated watch-file-standard to 4.
   * Secured copyright-format-uri.
   * Updated Standards-Version to 4.6.1.
   * Declared no need for root privileges.
   * Added upstream metadata file.
   * Introduced check for GPG signature.
   * Removed trailing whitespaces.

Regards,
-- 
  Arno Onken

Bug#1006818: eye: (autopkgtest) failure on non-amd64

[Jonas Smedegaard]

Control: reassign -1 swi-prolog-core
Control: retitle -1 intermediary files embed arch-specific path
Control: affects -1 eye

Quoting Adrian Bunk (2022-08-20 23:16:06)
> On Sat, Mar 05, 2022 at 08:41:47PM +0100, Paul Gevers wrote:
> > Source: eye
> > Version: 19.0221.2026~ds-1
> > Severity: serious
> > User: debian...@lists.debian.org
> > Usertags: fails-always
> > 
> > Dear maintainer(s),
> > 
> > You package has an autopkgtest, great. However, it fails on all
> > architectures but amd64. Can you please investigate the situation and fix
> > it?
> >...
> > #   Failed test 'bare command, stderr'
> > #   at debian/tests/eye.pvm.t line 11.
> > #   '/usr/bin/eye.pvm: 3: exec:
> > /usr/lib/swi-prolog/bin/x86_64-linux/swipl: not found
> >...
> 
> The autopkgtest caught that the package is not functional on !amd64:
> 
> (buster_arm64-dchroot)bunk@amdahl:/tmp$ eye.pvm 
> /usr/bin/eye.pvm: 3: exec: /usr/lib/swi-prolog/bin/x86_64-linux/swipl: not 
> found
> (buster_arm64-dchroot)bunk@amdahl:/tmp$ 
> 
> Changing Architecture: from "all" to "any" might be a reasonable option.

In my understanding, this is a bug in SWI Prolog, in that when
generating a so-called "intermediate code file" it embeds an
arch-specific path to the interpreter instead of the arch-independent
symlink in PATH: /usr/bin/swipl

@Lev: What do you think?  Is it possible to patch SWI Prolog to embed an
architecture-agnostic path for executing intermediary files?


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

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

signature.asc
Description: signature

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

[Michael Tokarev]

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

There's a FTBFS issue with cifs-utils on bullseye, #993014.
This update address that FTBFS issue only, with no other
changes

[ Reason ]
The package fails to build from source when doing non-parallel
build (or actually when doing parallel build too, sometimes),
due to wrong ordering/dependencies in the upstream Makefile
system. The problem is that the install target is two-part,
and "second" part relies on mkdir done in "first" part, while
not enforcing it. This (usually) succeeds when doing parallel
build, but always fails when doing non-parallel build.

[ Impact ]
There's no other impact for the user besides the failure to
build from source.

[ Tests ]
The build succeeded when doing either parallel or non-parallel
build. Since there's no actual code changes, no other testing
is necessary.

[ Risks ]
There's no risks here, since there's no code changes done.
Only the build (ordering) fix, the same as applied to testing.

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

[ Changes ]

The changelog entry:

cifs-utils (2:6.11-3.1+deb11u2) bullseye; urgency=medium

  * Fix non-parallel build. Closes: #993014.

The fix adds an ordering/dependency rule to the Makefile,
which ensures that the mkdir is done first and files created
there only after that.

[ Other info ]

[ Debdiff ]

diff -Nru cifs-utils-6.11/debian/changelog cifs-utils-6.11/debian/changelog
--- cifs-utils-6.11/debian/changelog2022-05-10 23:12:42.0 +0300
+++ cifs-utils-6.11/debian/changelog2022-08-27 03:20:00.0 +0300
@@ -1,3 +1,9 @@
+cifs-utils (2:6.11-3.1+deb11u2) bullseye; urgency=medium
+
+  * Fix non-parallel build. Closes: #993014.
+
+ -- Michael Tokarev   Sat, 27 Aug 2022 02:20:00 +0200
+
 cifs-utils (2:6.11-3.1+deb11u1) bullseye-security; urgency=high
 
   * Non-maintainer upload by the Security Team.
diff -Nru cifs-utils-6.11/debian/patches/root_sbindir-hook.patch 
cifs-utils-6.11/debian/patches/root_sbindir-hook.patch
--- cifs-utils-6.11/debian/patches/root_sbindir-hook.patch  1970-01-01 
03:00:00.0 +0300
+++ cifs-utils-6.11/debian/patches/root_sbindir-hook.patch  2022-08-27 
03:20:00.0 +0300
@@ -0,0 +1,11 @@
+--- a/Makefile.am
 b/Makefile.am
+@@ -118,7 +118,7 @@
+ 
+ SUBDIRS = contrib
+ 
+-install-exec-hook:
++install-exec-hook: install-root_sbinPROGRAMS
+   (cd $(DESTDIR)$(ROOTSBINDIR) && ln -sf mount.cifs mount.smb3)
+ 
+ install-data-hook:
diff -Nru cifs-utils-6.11/debian/patches/series 
cifs-utils-6.11/debian/patches/series
--- cifs-utils-6.11/debian/patches/series   2022-05-10 23:12:42.0 
+0300
+++ cifs-utils-6.11/debian/patches/series   2022-08-27 03:20:00.0 
+0300
@@ -5,3 +5,4 @@
 0011-fix-regression-for-CVE-2021-20208.patch
 CVE-2022-27239-mount.cifs-fix-length-check-for-ip-op.patch
 mount.cifs-fix-verbose-messages-on-option-parsing.patch
+root_sbindir-hook.patch

Bug#1019095: promod3 FTBFS with multiarchified openstructure

[Adrian Bunk]

Source: promod3
Version: 3.2.1+ds-4
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/fetch.php?pkg=promod3&arch=amd64&ver=3.2.1%2Bds-4%2Bb1&stamp=1662229682&raw=0

...
CMake Error at cmake_support/FindOPENSTRUCTURE.cmake:37 (message):
  Could not find library ost_io.  Please specify the location of your
  OpenStructure installation with OST_ROOT
Call Stack (most recent call first):
  cmake_support/FindOPENSTRUCTURE.cmake:98 (find_OPENSTRUCTURE)
  CMakeLists.txt:106 (find_package)


-- Configuring incomplete, errors occurred!

Bug#1012219: Please adjust StanHeaders to new version of (one)tbb

[Benjamin K Goodrich]

Sorry for the late reply. I am told that StanHeaders can be built
successfully with oneTBB by setting environmental variables like
TBB_INC and TBB_LIB. On CRAN, we would like to use the version of TBB
that comes with the RcppParallel package

https://github.com/RcppCore/RcppParallel/pull/144

Although with the next release of StanHeaders we will not be able to
achieve that because not all packages are LinkingTo RcppParallel so we
have to build a similar TBB in the StanHeaders shared object. But on
Debian, if r-cran-rcppparallel switches to oneTBB, then it would be
fine if r-cran-stanheaders, r-cran-rstan, etc. depends on
r-cran-rcppparallel.

Bug#1009915: sysvinit: Please align with manpages-l10n and afterwards activate man page translations

[Thorsten Glaser]

On Sat, 3 Sep 2022, Helge Kreutzmann wrote:

> The upload of manpages-l10n (manpages-fr) was just accepted in
> unstable.

OK, thanks.

AIUI we now need another upload of src:sysvinit in which bin:bootlogd
gets a Replaces and Breaks on manpages-fr (<< 4.15.0-9~), correct?

I can do that this weekend, ceteris paribus, unless anyone shouts.

Where, though, are the other Replaces/Breaks? I cannot find any on
the 3.05-1 binary packages? These are needed for upgrade ordering…
… oh, the manpages for the other packages are just diverted? That
will do, I suppose?

bye,
//mirabilos
-- 
Infrastrukturexperte • tarent solutions GmbH
Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/
Telephon +49 228 54881-393 • Fax: +49 228 54881-235
HRB AG Bonn 5168 • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg


/⁀\ The UTF-8 Ribbon
╲ ╱ Campaign against  Mit dem tarent-Newsletter nichts mehr verpassen:
 ╳  HTML eMail! Also, https://www.tarent.de/newsletter
╱ ╲ header encryption!

Bug#1011401: mount: umount bash completion explodes awk on some paths

[наб]

Hi!

On Sat, Sep 03, 2022 at 07:43:26PM +0200, Andreas Henriksson wrote:
> On Sun, May 22, 2022 at 12:20:27AM +0200, наб wrote:
> > Package: mount
> > Version: 2.36.1-8+deb11u1
> > Severity: normal
> > 
> > Dear Maintainer,
> > 
> > I just got this:
> > nabijaczleweli@tarta:~/uwu/SunOS 2.0 (Tape) [Sun-2]/tape1$ sudo umount 
> > 04.awk: cmd. line:8: (FILENAME=- FNR=1) fatal: invalid regexp: Invalid 
> > range end: /^/home/nabijaczleweli/uwu/SunOS 2.0 (Tape) [Sun-2]/tape1/
> > dawk: cmd. line:8: (FILENAME=- FNR=1) fatal: invalid regexp: Invalid range 
> > end: /^/home/nabijaczleweli/uwu/SunOS 2.0 (Tape) [Sun-2]/tape1/
> 
> I have a gut feeling this is because of the awk implementation in use on
> your system. I think it would serve the bug report well if you could
> include this information (I'm guessing mawk).
> ie. `update-alternatives --query awk`

This had been the case in the past ‒ I even opened #956465 at one point ‒
where awk=mawk would either not work or explode for umount always,
which is why I switched back to awk=gawk:
-- >8 --
$ update-alternatives --query awk
Name: awk
Link: /usr/bin/awk
Slaves:
 awk.1.gz /usr/share/man/man1/awk.1.gz
 nawk /usr/bin/nawk
 nawk.1.gz /usr/share/man/man1/nawk.1.gz
Status: auto
Best: /usr/bin/gawk
Value: /usr/bin/gawk

Alternative: /usr/bin/gawk
Priority: 10
Slaves:
 awk.1.gz /usr/share/man/man1/gawk.1.gz
 nawk /usr/bin/gawk
 nawk.1.gz /usr/share/man/man1/gawk.1.gz

Alternative: /usr/bin/mawk
Priority: 5
Slaves:
 awk.1.gz /usr/share/man/man1/mawk.1.gz
 nawk /usr/bin/mawk
 nawk.1.gz /usr/share/man/man1/mawk.1.gz
-- >8 --

With set -x, when bing, I get this (trimmed to show texture):
-- >8 --
+++ findmnt -lno TARGET
+++ awk '{
if ($0 ~ "^"ENVIRON["HOME"]) {
homeless = $0
sub("^"ENVIRON["HOME"], "~", homeless)
gsub("[][(){}<>\",:;^&!$=?`|\\'\'' \t\f\n\r\v]", 
"&", homeless)
print homeless " "
}
if ($0 ~ "^"ENVIRON["PWD"]) {
reldir = $0
sub("^"ENVIRON["PWD"]"/?", "", reldir)
gsub("[][(){}<>\",:;^&!$=?`|\\'\'' \t\f\n\r\v]", 
"&", reldir)
print "./" reldir " "
print reldir " "
}
gsub("[][(){}<>\",:;^&!$=?`|\\'\'' \t\f\n\r\v]", "&")
print $0 " "
}'
awk: cmd. line:8: (FILENAME=- FNR=1) fatal: invalid regexp: Invalid range end: 
/^/home/nabijaczleweli/uwu/SunOS 2.0 (Tape) [Sun-2]/tape1/
+ local opt
-- >8 --

If I cunningly override awk=mawk by setting `awk() { mawk "$@"; }`,
I get no explicit error:
-- >8 -:
+++ findmnt -lno TARGET
+++ awk '{
if ($0 ~ "^"ENVIRON["HOME"]) {
homeless = $0
sub("^"ENVIRON["HOME"], "~", homeless)
gsub("[][(){}<>\",:;^&!$=?`|\\'\'' \t\f\n\r\v]", 
"&", homeless)
print homeless " "
}
if ($0 ~ "^"ENVIRON["PWD"]) {
reldir = $0
sub("^"ENVIRON["PWD"]"/?", "", reldir)
gsub("[][(){}<>\",:;^&!$=?`|\\'\'' \t\f\n\r\v]", 
"&", reldir)
print "./" reldir " "
print reldir " "
}
gsub("[][(){}<>\",:;^&!$=?`|\\'\'' \t\f\n\r\v]", "&")
print $0 " "
}'
+++ mawk '{
if ($0 ~ "^"ENVIRON["HOME"]) {
homeless = $0
sub("^"ENVIRON["HOME"], "~", homeless)
gsub("[][(){}<>\",:;^&!$=?`|\\'\'' \t\f\n\r\v]", 
"&", homeless)
print homeless " "
}
if ($0 ~ "^"ENVIRON["PWD"]) {
reldir = $0
sub("^"ENVIRON["PWD"]"/?", "", reldir)
gsub("[][(){}<>\",:;^&!$=?`|\\'\'' \t\f\n\r\v]", 
"&", reldir)
print "./" reldir " "
print reldir " "
}
gsub("[][(){}<>\",:;^&!$=?`|\\'\'' \t\f\n\r\v]", "&")
print $0 " "
}'
+ local opt
-- >8 --
but I also don't get any suggestions or completions.

So:
  gawk explodes
  mawk fails silently

Further analysis of line 8 shows that this is sufficient:
-- >8 --
~/uwu/SunOS 2.0 (Tape) [Sun-2]/tape1$ echo "$PWD" | gawk '{print ($0 ~ 
"^"ENVIRON["PWD"])}'
gawk: cmd. line:1: (FILENAME=- FNR=1) fatal: invalid regexp: Invalid range end: 
/^/home/nabijaczleweli/uwu/SunOS 2.0 (Tape) [Sun-2]/tape1/
~/uwu/SunOS 2.0 (Tape) [Sun-2]/tape1$ echo "$PWD" | mawk '{print ($0 ~ 
"^"ENVIRON["PWD"])}'
0
-- >8 --

Which I gamed down to:
-- >8 --
$ echo | gawk '{print ($0 ~ "[n-2]")}'
gawk: cmd. line:1: (FILENAME=- FNR=1) fatal: invalid regexp: Invalid range end: 
/[n-2]/
$ echo | mawk '{print ($0 ~ "[n-2]")}'
0

Bug#1019094: gjs constantly crashes instantly out of nowhere

[Tyler Magee Shields]

Package: gjs
Version: 1.73.1-1
Severity: important
Tags: upstream
X-Debbugs-Cc: tylermageeshie...@gmail.com

Dear Maintainer,

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

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

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


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

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

Versions of packages gjs depends on:
ii  gir1.2-gtk-3.0  3.24.34-3
ii  libc6   2.34-4
ii  libgcc-s1   12.1.0-8
ii  libgjs0g1.73.1-1
ii  libglib2.0-02.72.3-1+b1
ii  libstdc++6  12.1.0-8

gjs recommends no packages.

gjs suggests no packages.

-- no debconf information

Bug#1019007: rfkill(8): List options for supported device types

[Andreas Henriksson]

Control: tags -1 + upstream

Hello Tino Schmidt,

On Sat, Sep 03, 2022 at 09:16:42AM +0200, Tino Schmidt wrote:
> Package: rfkill
> Version: 2.33.1-0.1
> Severity: minor
> Tags: patch
[...]

Your suggested patch changes upstream provided files. Could you please
submit the patch directly to upstream for review/inclusion?

Please see
https://github.com/util-linux/util-linux/blob/master/Documentation/howto-contribute.txt

Note: You want to use the correct path in your patch (including
sys-utils) and also use "Signed-off-by" according to
https://wiki.linuxfoundation.org/dco

Regards,
Andreas Henriksson

Bug#1017959: RFP: meson-python -- Meson PEP 517 Python build backend

[Simon McVittie]

Control: retitle -1 ITP: meson-python -- Meson PEP 517 Python build backend
Control: owner -1 !

On Tue, 23 Aug 2022 at 01:25:49 +0200, Drew Parsons wrote:
> * Package name: meson-python
>   Description : Meson PEP 517 Python build backend

I started looking at this because I've wondered whether to use it for
dbus-python. Work in progress:
https://salsa.debian.org/python-team/packages/meson-python
(not really tested yet, I don't yet have an upstream project that
needs it).

Co-maintainers welcome; Drew, would you be interested?

smcv

Bug#1011401: mount: umount bash completion explodes awk on some paths

[Andreas Henriksson]

Hello,

On Sun, May 22, 2022 at 12:20:27AM +0200, наб wrote:
> Package: mount
> Version: 2.36.1-8+deb11u1
> Severity: normal
> 
> Dear Maintainer,
> 
> I just got this:
> nabijaczleweli@tarta:~/uwu/SunOS 2.0 (Tape) [Sun-2]/tape1$ sudo umount 
> 04.awk: cmd. line:8: (FILENAME=- FNR=1) fatal: invalid regexp: Invalid range 
> end: /^/home/nabijaczleweli/uwu/SunOS 2.0 (Tape) [Sun-2]/tape1/
> dawk: cmd. line:8: (FILENAME=- FNR=1) fatal: invalid regexp: Invalid range 
> end: /^/home/nabijaczleweli/uwu/SunOS 2.0 (Tape) [Sun-2]/tape1/


I have a gut feeling this is because of the awk implementation in use on
your system. I think it would serve the bug report well if you could
include this information (I'm guessing mawk).
ie. `update-alternatives --query awk`

If you can confirm the problem exists with one particular awk
implementation (e.g. mawk) and not another one (e.g. gawk which I think
is really the only think upstream considers as awk implementation if I
remember correctly), then it might be a good idea to bring this up
in a discussion with upstream (including this info).

> 
> As the prompt may suggest, I was in
>   /home/nabijaczleweli/uwu/SunOS 2.0 (Tape) [Sun-2]/tape1
> and trying to unmount "04.d" in that same directory,
> with the cursor after the dot.
> 
> Best,
> наб
> 
> -- System Information:
> Debian Release: 11.3
>   APT prefers stable-updates
>   APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
> 'stable-debug'), (500, 'stable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 5.10.0-14-amd64 (SMP w/24 CPU threads)
> Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_FIRMWARE_WORKAROUND, 
> TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
> Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
> LANGUAGE=en_GB:en
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> -- no debconf information

Regards,
Andreas Henriksson

Bug#1012162: [Pkg-javascript-devel] Bug#1012162: nodejs: Backports version for Bullseye

[Pirate Praveen]

On Sat, Sep 3 2022 at 09:44:22 PM +05:30:00 +05:30:00, Pirate Praveen 
 wrote:
I tried different babel options but none of them seems to be working 
for optional chaining operator transpiling. I tried target node 12 
for babel preset env, tried explicitly adding this plugin for 
optional chaining operator etc (by patching config/babel.config.js - 
adding top level preset as well as adding to overrides).


I succeeded in correctly transpiling node-yaml for node12 by using 
babeljs commandline, so this buys us more time to backport nodejs for 
gitlab.


https://salsa.debian.org/js-team/node-yaml/-/commit/cca188ba053175258e78f4afdf68f2cc80953d11

Looks like config/babel.config.js was never actually being used as 
babel.config.js should be in the root directory along with package.json

Bug#1019093: python-pgmagick FTBFS: error: no matches converting function ‘colorMapSize’ to type ‘unsigned int (class Magick::Image::*)()’

[Adrian Bunk]

Source: python-pgmagick
Version: 0.7.6-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/fetch.php?pkg=python-pgmagick&arch=amd64&ver=0.7.6-1%2Bb3&stamp=1662226834&raw=0

...
./src/_Image.cpp: In function ‘void __Image()’:
./src/_Image.cpp:385:82: error: no matches converting function ‘colorMapSize’ 
to type ‘unsigned int (class Magick::Image::*)()’
  385 | .def("colorMapSize", (unsigned int (Magick::Image::*)() 
)&Magick::Image::colorMapSize)
  | 
 ^~~~
In file included from ./src/_Image.cpp:6:
/usr/include/GraphicsMagick/Magick++/Image.h:908:21: note: candidates are: 
‘unsigned int Magick::Image::colorMapSize() const’
  908 | unsigned intcolorMapSize ( void ) const;
  | ^~~~
/usr/include/GraphicsMagick/Magick++/Image.h:907:21: note: 
‘void Magick::Image::colorMapSize(unsigned int)’
  907 | voidcolorMapSize ( const unsigned int entries_ );
  | ^~~~
error: command '/usr/bin/x86_64-linux-gnu-gcc' failed with exit code 1
E: pybuild pybuild:379: build: plugin distutils failed with: exit code=1: 
/usr/bin/python3 setup.py build 
dh_auto_build: error: pybuild --build -i python{version} -p 3.10 returned exit 
code 13
make: *** [debian/rules:8: binary-arch] Error 25

Bug#1018943: release-notes: document systemd packaging changes for Bookworm

[RL]

The following message is a courtesy copy of an article
that has been posted to gmane.linux.debian.devel.documentation as well.

Some thoughts on clarity - from a user pov, given that people reading
release-notes will not be familiar with details:

Luca Boccassi  writes:

> systemd-resolved has been split into a separate package.
> This new systemd-resolved package will not be installed automatically

s/This/The

> on upgrades. If you are using systemd-resolved, please install this

s/are/were
s/this/the

> new package manually

after manually i'd suggest adding "after the upgrade"

and does this change impact people who were using systemd-resolved and
are upgrading over ssh or other remote ways: will they be at risk of
losing their DNS until they install the new package?

>. By installing this package, systemd-resolved will
> take over control of /etc/resolv.conf automatically.

Found the above sentence a little cryptic - think the word "over" is
redundant. Ideally, i'd suggest what it needs is one sentence
explanation of what systemd-resolved is (its man page is a bit of a
jargon-fest - is it just "manages the settings in /etc/resolv.conf"?)

I think it might also help to explain what the debian "default" here is
(even if it didnt change): Is it that resolve.conf is managed "by hand"
unless network manager is installed?

> systemd-boot has been split into a separate package.
> This new systemd-boot package will not be installed automatically on
> upgrades. If you are using systemd-boot, please install this new
> package manually.

As above - "the new package" and "were using" (or - "if you want to use"
might be clearer (here and above)

> The default boot loader in Debian is grub2.

should this end "is still grub2, but systemd-boot can be used instead"?

and is grub2 the right package - on my (current stable) system, "apt
show grub2" tells me it is a transitional package that is going to be
removed - should it say "grub-pc" instead of grub2 here?

> If you have not set up systemd-boot manually, no action is required on
> your side.

"on your side" is not idiomatic/clear - better to end the sentence at
"no action is required".

but is "set up manually" different from "installed"? ("set up" sounds
like some positive action has been taken to edit configuration files,
and "manually" might even mean "not using apt" - but i'm not sure that
is what is meant...)

as above, can it explain (briefly) what a "boot loader" is for those
that don't know (like me) - and how do i tell which one i am using? is
there some reason to prefer systemd-boot over grub or vice-versa?

I'd suggest something like: "A bootloader is responsible for starting
the kernel when the system boots"?

(it says "bootloader" rather than "boot loader" in the description of
grub-pc - not sure which is standard)

And i suggest that this stanza needs to be _very_ explicit about whether
or not systems that were using systemd-boot will become unbootable until
the user installs the new systemd-boot package? (seems pretty important
to clarify to me, even if the answer is that there is no risk!).

> systemd-journal-gatewayd and systemd-journal-remote are now built
> without the --trust option, in order to be able to switch away from
> gnutls to openssl.

Does it need a new heading: "Changes to the systemd journal"? (I almost
missed this the first time i read it)

it's also not very transparent: what command is '--trust' an option for?
(i didnt see it in 'journalctl(1)') and what impact does removing it have?

Eg, is it saying that the systemd journal was using gnutls and is now
using openssl, or is it saying that this change will be done in the
future? (as a user, i'm not sure that such a change is important enough
for the release notes - seems more like something for debian/changelog,
but perhaps i am missing something?)


Thanks for considering

Bug#1019091: pytango must now build depend on cppzmq-dev

[Adrian Bunk]

On Sat, Sep 03, 2022 at 08:22:12PM +0300, Adrian Bunk wrote:
> Source: pytango
> Version: 9.3.4-2
> Severity: serious
> Tags: ftbfs
> 
> See #972785 for background.

I forgot to include the error message:

https://buildd.debian.org/status/fetch.php?pkg=pytango&arch=amd64&ver=9.3.4-2%2Bb2&stamp=1662225534&raw=0

...
In file included from /usr/include/tango/tango.h:146,
 from /<>/ext/attribute_event_info.cpp:13:
/usr/include/tango/event.h:41:10: fatal error: zmq.hpp: No such file or 
directory
   41 | #include 
  |  ^
compilation terminated.
...


cu
Adrian

Bug#1018977: bullseye-pu: package hydrapaper/2.0.2-1

[Francisco M Neto]

Hello!

On Sat, 2022-09-03 at 18:24 +0100, Adam D. Barratt wrote:
> On Sat, 2022-09-03 at 14:06 -0300, Francisco M Neto wrote:
> > Sent the package to mentors.d.n. Do you require an RFS?
> > 
> 
> That's up to you, but for complete clarity we (i.e. the Release Team)
> don't usually sponsor uploads for stable updates, unless we're involved
> in the package in some way.

Ahhh, understood. Thanks for the clarification! :)

> It looks like your previous hydrapaper uploads have all had the same
> sponsor, so maybe you could ask them?

Will do. 


Cheers!
--
Francisco


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

Bug#1019092: RFS: hydrapaper/2.0.2-1+deb11u1 [RC] -- Utility that sets background independently for each monitor

[Francisco M Neto]

Package: sponsorship-requests
Severity: important

Dear mentors,

I am looking for a sponsor for my package "hydrapaper". This particular package
is to be sent to Stable, because it contains an important bugfix (Bug#1010697),
(which is already in Unstable but release is still pretty far away). It has been
approved for bullseye-pu (See #1018977).

 * Package name: hydrapaper
   Version : 2.0.2-1+deb11u1
   Upstream Author : Gabriele Musco 
 * URL : https://gitlab.com/gabmus/HydraPaper
 * License : GPL-3+
 * Vcs : https://salsa.debian.org/fmneto-guest/hydrapaper
   Section : graphics

The source builds the following binary packages:

  hydrapaper - Utility that sets background independently for each monitor

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

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

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

  dget -x
https://mentors.debian.net/debian/pool/main/h/hydrapaper/hydrapaper_2.0.2-1+deb11u1.dsc

Changes since the last upload:

 hydrapaper (2.0.2-1+deb11u1) bullseye; urgency=medium
 .
   * debian/comtrol:
 - Added python3-pil to Depends: field (Closes: #1010697).

Regards,
-- 
  Francisco Mariano Neto


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

Bug#1005101: your mail

[Andreas Henriksson]

Hello David Barber,

Adding some hints of what I think is going on inline below

On Tue, Feb 08, 2022 at 02:15:25PM -0500, david barber wrote:
> Hi Chris,
> 
> Sorry, I'm not sure how to reply within the bug tracking system.this is
> my first.
> 
> 1) I'm using this debian live image: 2612133888 Jan 28 00:42
> debian-live-11.1.0-amd64-mate.iso
> 2) See below for results using both -w=never and --wipe=never on the USB
> stick.  -w reports as unsupported wipe mode (!) and --wipe=never seems to
> have no effect. (warning about ISO9660 comes up even though it was told to
> NEVER wipe).
> 
> My dd command was as follows:
> barbed2@vostro:/nas1/ISO-IMAGES$ dd if=debian-live-11.1.0-amd64-mate.iso |
> sudo dd of=/dev/sdf bs=4M status=progress oflag=direct
> 
> 
> === begin snip 
> root@vostro:/nas1/ISO-IMAGES# fdisk -w=never /dev/sde
> fdisk: unsupported wipe mode

This one is easy to explain. The syntax you're using is equivalent to:
`fdisk -w -= -e -v -e -r /dev/sde` (and the wipemode argument `/dev/sde`
does not match any of `auto`, `never` or `always) which is obviously not
what you really want. Thus you get the above error message.
(Additionally you're missing a target file but you never get that far
in the parsing.)

Hope this helps clear this one out.


> root@vostro:/nas1/ISO-IMAGES# fdisk --wipe=never /dev/sde

This one probably needs a bit deeper debugging to figure out.
I would normally use `fdisk --wipe never /dev/sde` naturally,
but you're not getting the previous error message so apparently
separating option and optarg using = seems to be accepted syntax.

Not sure what (if anything) goes wrong with this one.
You write "does not honour the --wipe option" and it would be helpful
if you could elaborate on what you expected and what happened.
(It's not obvious to me from the below example.)

Further investigation needed.

> 
> Welcome to fdisk (util-linux 2.36.1).
> Changes will remain in memory only, until you decide to write them.
> Be careful before using the write command.
> 
> The device contains 'iso9660' signature and it may remain on the device. It
> is recommended to wipe the device with wipefs(8) or fdisk --wipe, in order
> to avoid possible collisions.
> 
> Command (m for help):
> === end snip 
> 
> 
> Thanks again, pls let me know if there's anything else I can provide.
> 
> David

Regards,
Andreas Henriksson

PS. Using "reply all" in your mail user agent should do the right
thing when replying.

Bug#1018977: bullseye-pu: package hydrapaper/2.0.2-1

[Adam D. Barratt]

On Sat, 2022-09-03 at 14:06 -0300, Francisco M Neto wrote:
> Sent the package to mentors.d.n. Do you require an RFS?
> 

That's up to you, but for complete clarity we (i.e. the Release Team)
don't usually sponsor uploads for stable updates, unless we're involved
in the package in some way.

It looks like your previous hydrapaper uploads have all had the same
sponsor, so maybe you could ask them?

Regards,

Adam

Bug#1019091: pytango must now build depend on cppzmq-dev

[Adrian Bunk]

Source: pytango
Version: 9.3.4-2
Severity: serious
Tags: ftbfs

See #972785 for background.

Bug#1018065: On disappeared reactions and animated stickers

[Nicholas Guriev]

Thank you for the reproducer. I am investigating the issue. I noticed that
with the librlottie0-1 package of version 0.1+dfsg-2 tdesktop is able to
render all the stickers and the reactions there.

You can find the previous version of rLottie at the snapshot.d.o site.
https://snapshot.debian.org/package/rlottie/0.1%2Bdfsg-2/#librlottie0-1_0.1:2b:dfsg-2

I was trying to work around other crashes in the -3 revision. But apparently,
the regression seeped. 😓

Although, a certain thread in tdesktop still hangs after opening the channel.
This can be related to FFmpeg. I will apply the patch from your PR on GitHub.

On 03.09.2022 17:35:57 MSK you wrote:
> Unfortunately, I don't know how to export a sticker from Telegram, so cannot
> do it myself.

By the way, you can download any sticker from context menu on right-click,
with the item "Save as..." there.


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

Bug#1018977: bullseye-pu: package hydrapaper/2.0.2-1

[Francisco M Neto]

Sent the package to mentors.d.n. Do you require an RFS?

--
Francisco

On Sat, 2022-09-03 at 17:53 +0100, Adam D. Barratt wrote:
> Control: tags -1 -moreinfo +confirmed
> 
> On Sat, 2022-09-03 at 13:14 -0300, Francisco M Neto wrote:
> > Greetings
> > 
> > On Sat, 2022-09-03 at 14:20 +0100, Adam D. Barratt wrote:
> > > Control: tag -1 + moreinfo
> > > 
> > > [...]
> > > >   [X] attach debdiff against the package in stable
> > > > 
> > > 
> > > The debdiff is a _binary_ debdiff, between generated packages - the
> > > intent is for a source debdiff, i.e. between the two source
> > > packages /
> > > .dscs.
> > 
> > My mistake. Attached is the correct source debdiff.
> > 
> 
> Thanks. Please go ahead.
> 
> Regards,
> 
> Adam
> 



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

Bug#1018977: bullseye-pu: package hydrapaper/2.0.2-1

[Adam D. Barratt]

Control: tags -1 -moreinfo +confirmed

On Sat, 2022-09-03 at 13:14 -0300, Francisco M Neto wrote:
> Greetings
> 
> On Sat, 2022-09-03 at 14:20 +0100, Adam D. Barratt wrote:
> > Control: tag -1 + moreinfo
> > 
> > [...]
> > >   [X] attach debdiff against the package in stable
> > > 
> > 
> > The debdiff is a _binary_ debdiff, between generated packages - the
> > intent is for a source debdiff, i.e. between the two source
> > packages /
> > .dscs.
> 
>   My mistake. Attached is the correct source debdiff.
> 

Thanks. Please go ahead.

Regards,

Adam

Bug#1019004: U-Boot does not find ESP

[Heinrich Schuchardt]

On 9/3/22 18:25, Vagrant Cascadian wrote:

On 2022-09-03, Heinrich Schuchardt wrote:

U-Boot 2022.07 may not find EFI system partition where UEFI variables
are stored. This can lead to booting via UEFI to fail.


Just for clarity, this is not a regression from 2022.04?


The problem does not exist in 2022.04. It is specific to 2022.07

Best regards

Heinrich

Bug#1005765: dgit doesn't handle upstream files with CRLF well

[Ian Jackson]

Control: tags -1 moreinfo

I wrote:
> I think that if
>  - your upstream files have CRLF in the orig
>  - your upstream files have CRLF in your git tree
>  - you do not expect (or enable) line ending conversions in git
> then
>  - dgit will not complain
>  - the source package you produce will have files with CRLF
>  - everything should work

If you have a repro that demonstrates the contrary, please let us
know.  Typically a repro would consist of the following elements:

  * The precise git commit that you had as HEAD in your working tree

We need the git hash; hopefully I can obtain the data from salsa.

  * The precise contents of all relevant .origs

If they were already previously uploaded, we can get them from the
archive or snapshot.d.o.  Otherwise please supply their
sha256sums, as well as instructions for download or creation (eg
pristine-tar branch).

  * The precise dgit command line, and any configuration settings
applied to any of the relevant tools.

Ideally, a run with dgit -D would be helpful.


If you have a situation that doesn't match the criteria above, but you
think should be able to work, and currently doesn't, please also let
us know.

Thanks,
Ian.

-- 
Ian JacksonThese opinions are my own.  

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

Bug#968495: ITP: c-evo-dh -- C-evo: Distant Horizon, Empire building game

[Peter B]

Rebranding as c-evo-dh (fork of c-evo-nh)


* Package name    : c-evo-dh
  Version : 1.1
  Upstream Author : pe...@pblackman.plus.com
* URL : http://www.c-evo.org/ 
https://sourceforge.net/projects/c-evo-eh/
* License : GPL-2+, CC-BY-3.0, CC0-1.0, CC-BY-SA-3.0-US
  Programming Lang: FPC / Lazarus
  Description : Empire Building Game

Bug#1018191: libapreq2: CVE-2022-22728: multipart form parse memory corruption

[Salvatore Bonaccorso]

Hi,

On Sat, Sep 03, 2022 at 03:31:15PM +0200, Steinar H. Gunderson wrote:
> On Fri, Aug 26, 2022 at 09:07:06PM +0200, Salvatore Bonaccorso wrote:
> > The following vulnerability was published for libapreq2.
> > 
> > CVE-2022-22728[0]:
> > | A flaw in Apache libapreq2 versions 2.16 and earlier could cause a
> > | buffer overflow while processing multipart form uploads. A remote
> > | attacker could send a request causing a process crash which could lead
> > | to a denial of service attack.
> 
> Based on the description, I assume it is this one:
> 
> http://svn.apache.org/viewvc?view=revision&revision=1866760
> 
> I'm not sure if it counts as “buffer overflow”, but given that it only
> mentions DoS and not arbitrary code execution, NULL pointer dereference
> looks a lot like it. 2.13 appears vulnerable to me, given the description.
> 
> I don't use libapreq2 anymore, so anyone wanting to pick up the package
> would be more than welcome. Upstream homepage is now seemingly at:
> 
>   https://httpd.apache.org/apreq/

Thanks for having investigated this further. This is puzzling and
upstream has not yet answered on queries about isolating the fix. The
above would be already a couple of years old. And
https://bugs.gentoo.org/show_bug.cgi?id=CVE-2022-22728#c1 seems to
indicate there must be something in recent days about it. A diff
between libapreq2-2.16 and libapreq2-2.17 has in fact:

diff -urN libapreq2-2.16/CHANGES libapreq2-2.17/CHANGES
--- libapreq2-2.16/CHANGES  2021-03-10 14:46:30.0 +0100
+++ libapreq2-2.17/CHANGES  2022-08-18 11:19:04.0 +0200
@@ -1,6 +1,11 @@
 /** @page apreq_changes CHANGES
 //! brief List of major changes.

+@section v2_17 Changes with libapreq2-2.17 (released 25 August, 2022)
+
+- Multipart header parser [Yann Ylavic]
+  Rework apreq_parse_headers() to discard CRLF of folded values.
+
 @section v2_16 Changes with libapreq2-2.16 (released 17 March, 2021)

But maybe as you suggest we have to go back . Though it should be
something which still affects 2.16 upstream. and likely so not the
newley released 2.17.

Regards,
Salvatore

Bug#957392: juman: ftbfs with GCC-10

[Graham Inggs]

Control: severity -1 important

juman 7.0-3.5 build successfully on the buildds with GCC 12.
Therefore I am lowering the severity of this bug.

Bug#1019004: U-Boot does not find ESP

[Vagrant Cascadian]

On 2022-09-03, Heinrich Schuchardt wrote:
> U-Boot 2022.07 may not find EFI system partition where UEFI variables 
> are stored. This can lead to booting via UEFI to fail.

Just for clarity, this is not a regression from 2022.04?


> The following upstream patch fixes this:
>
> commit d5391bf02b9dc6a84fe33ba913caf70061909950
> efi_loader: ensure all block devices are probed

At a quick glance, this doesn't seem like a trivial cherry-pick, and
hopefully we can soon move to 2022.10 which should include this patch...


Thanks!


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1018977: bullseye-pu: package hydrapaper/2.0.2-1

[Francisco M Neto]

Greetings

On Sat, 2022-09-03 at 14:20 +0100, Adam D. Barratt wrote:
> Control: tag -1 + moreinfo
> 
> [...]
> >   [X] attach debdiff against the package in stable
> > 
> 
> The debdiff is a _binary_ debdiff, between generated packages - the
> intent is for a source debdiff, i.e. between the two source packages /
> .dscs.

My mistake. Attached is the correct source debdiff.

Thanks,
Francisco
diff -Nru hydrapaper-2.0.2/debian/changelog hydrapaper-2.0.2/debian/changelog
--- hydrapaper-2.0.2/debian/changelog	2020-11-08 19:42:35.0 +
+++ hydrapaper-2.0.2/debian/changelog	2022-09-02 19:10:14.0 +
@@ -1,3 +1,10 @@
+hydrapaper (2.0.2-1+deb11u1) bullseye; urgency=medium
+
+  * debian/comtrol:
+- Added python3-pil to Depends: field (Closes: #1010697).
+
+ -- Francisco M Neto   Fri, 02 Sep 2022 19:10:14 +
+
 hydrapaper (2.0.2-1) unstable; urgency=medium
 
   * New upstream version 2.0.2.
diff -Nru hydrapaper-2.0.2/debian/control hydrapaper-2.0.2/debian/control
--- hydrapaper-2.0.2/debian/control	2020-11-08 19:42:35.0 +
+++ hydrapaper-2.0.2/debian/control	2022-09-02 19:10:14.0 +
@@ -11,7 +11,7 @@
  python3-willow,
  libwnck-3-dev,
  libgtk-3-dev
-Standards-Version: 4.5.0
+Standards-Version: 4.5.1
 Homepage: https://gitlab.com/gabmus/HydraPaper
 Vcs-Browser: https://salsa.debian.org/fmneto-guest/hydrapaper
 Vcs-Git: https://salsa.debian.org/fmneto-guest/hydrapaper.git
@@ -23,6 +23,7 @@
  ${misc:Depends},
  ${python3:Depends},
  python3-gi,
+ python3-pil,
  gir1.2-handy-1,
  libhandy-1-0
 Description: Utility that sets background independently for each monitor
diff -Nru hydrapaper-2.0.2/debian/copyright hydrapaper-2.0.2/debian/copyright
--- hydrapaper-2.0.2/debian/copyright	2020-11-08 19:42:35.0 +
+++ hydrapaper-2.0.2/debian/copyright	2022-09-02 19:08:51.0 +
@@ -8,7 +8,7 @@
 License: GPL-3+
 
 Files: debian/*
-Copyright: 2020 Francisco M Neto 
+Copyright: 2022 Francisco M Neto 
 License: GPL-3+
 
 License: GPL-3+
diff -Nru hydrapaper-2.0.2/debian/hydrapaper.lintian-overrides hydrapaper-2.0.2/debian/hydrapaper.lintian-overrides
--- hydrapaper-2.0.2/debian/hydrapaper.lintian-overrides	1970-01-01 00:00:00.0 +
+++ hydrapaper-2.0.2/debian/hydrapaper.lintian-overrides	2022-09-02 19:10:14.0 +
@@ -0,0 +1,2 @@
+# Bug number is correct
+hydrapaper: improbable-bug-number-in-closes


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

Bug#1010527: RFS: c-evo-dh/1.1-1 [ITP] -- C-evo: Distant Horizon, Empire Building Game

[Peter B]

Dear mentors,

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

 * Package name    : c-evo-dh
   Version : 1.1-1
   Upstream Author : Peter 
 * URL : https://sourceforge.net/projects/c-evo-eh/
 * License : CC-BY-3.0, CC-BY-SA-3.0-US, GPL-2+, CC0-1.0
 * Vcs : https://salsa.debian.org/PeterB/c-evo-dh
   Section : games

The source builds the following binary packages:

  c-evo-dh - Empire Building Game, C-evo: Distant Horizon
  c-evo-gtk2 - Empire Building Game (GTK2), C-evo: Extended Horizon
  c-evo-qt5 - Empire Building Game  (Qt5), C-evo: Extended Horizon
  c-evo-stdai - Empire Building Game (AI module), C-evo: Extended Horizon
  c-evo-data - Empire Building Game (data files), C-evo: Extended Horizon
  c-evo-qt5-graphics-patch - Empire Building Game (qt5 graphics patch), C-evo: 
Extended Horizon

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

  https://mentors.debian.net/package/c-evo-dh/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/c/c-evo-dh/c-evo-dh_1.1-1.dsc

Changes for the initial release:

 c-evo-dh (1.1-1) unstable; urgency=medium
 .
   * Initial release for Debian. Closes: #968495



Package is Lintian clean and passes Salsa CI.

C-evo is a Civilization style game, inspired by Civ II.
Originally written in Delphi for Windows,
it has been ported to FPC/Lazarus for Linux.

It will appeal to players of FreeCiv who fancy a new challenge.
The UI may not be as slick as FreeCiv, but IMHO the gameplay is better.

This package is a fork of c-evo-nh
https://app.zdechov.net/c-evo/
The packaging is much cleaner now, with no patches or extra files,
but this means I am also the upstream author.

My changes focus on policy for debian packaging, stability, larger buttons,
support for larger maps and work on the QT5 version which is ongoing.



Regards,
--
  Peter Blackman

Bug#1018940: devhelp: Scrolling does not immediately update the view

[Evangelos Ribeiro Tzaras]

Some more information below.

On Fri, 02 Sep 2022 10:05:40 +0200 Evangelos Ribeiro Tzaras
 wrote:
> Package: devhelp
> Version: 43~beta-2
> Severity: normal
> 
> Dear Maintainer,
> 
> on my system devhelp does not scroll as it used to.
> If I try scrolling the view either using the mouse scroll wheel
> or by keyboard navigation using the up/down arrow the view will not update.
> 
> However if I click inside the view it will update by the previously scrolled
amount.
> 
> I'm using this in a GNOME (wayland) session.

and using AMD graphics (in case this is relevant)

> I'll follow up later with `WAYLAND_DEBUG=1`, maybe it contains something
pointing
> to the underlying issue.

[3487939.134] wl_callb...@53.done(30222081)
[3492764.387] wl_pointer@13.axis_source(0)
[3492764.402] wl_pointer@13.axis_discrete(0, 1)
[3492764.405] wl_poin...@13.axis(30226906, 0, 10.)
[3492764.409] wl_pointer@13.frame()
[3493389.382] wl_pointer@13.axis_source(0)
[3493389.400] wl_pointer@13.axis_discrete(0, 1)
[3493389.403] wl_poin...@13.axis(30227531, 0, 10.)
[3493389.407] wl_pointer@13.frame()
[3494088.416] wl_pointer@13.axis_source(0)
[3494088.432] wl_pointer@13.axis_discrete(0, 1)
[3494088.437] wl_poin...@13.axis(30228230, 0, 10.)
[3494088.440] wl_pointer@13.frame()
[3495337.607] wl_pointer@13.axis_source(0)
[3495337.624] wl_pointer@13.axis_discrete(0, 1)
[3495337.628] wl_poin...@13.axis(30229479, 0, 10.)
[3495337.631] wl_pointer@13.frame()
[3501268.617] wl_pointer@13.axis_source(0)
[3501268.640] wl_pointer@13.axis_discrete(0, 1)
[3501268.643] wl_poin...@13.axis(30235410, 0, 10.)
[3501268.646] wl_pointer@13.frame()

All of the above is scrolling (using the mouse)

[3533684.461] xdg_wm_b...@30.ping(30267826)
[3533684.490]  -> xdg_wm_b...@30.pong(30267826)
[3533684.496] wl_pointer@13.button(17474, 30267826, 272, 1)
[3533684.505] wl_pointer@13.frame()
[3533693.329]  -> wl_surface@38.attach(wl_buffer@52, 0, 0)
[3533693.342]  -> wl_surface@38.set_buffer_scale(1)
[3533693.346]  -> wl_surface@38.damage(391, 67, 589, 1033)
[3533693.351]  -> xdg_toplevel@41.set_min_size(290, 139)
[3533693.354]  -> xdg_toplevel@41.set_max_size(0, 0)
[3533693.357]  -> xdg_surface@40.set_window_geometry(20, 20, 960, 1080)
[3533693.371]  -> wl_surface@38.frame(new id wl_callback@53)
[3533693.379]  -> wl_surface@38.commit()
[3533693.897] wl_buffer@52.release()
[3533700.824] wl_display@1.delete_id(53)
[3533700.834] wl_callb...@53.done(30267843)
[3533700.945]  -> wl_surface@38.attach(wl_buffer@52, 0, 0)
[3533700.961]  -> wl_surface@38.set_buffer_scale(1)
[3533700.965]  -> wl_surface@38.damage(965, 67, 15, 1033)
[3533700.968]  -> xdg_toplevel@41.set_min_size(290, 139)
[3533700.970]  -> xdg_toplevel@41.set_max_size(0, 0)
[3533700.972]  -> xdg_surface@40.set_window_geometry(20, 20, 960, 1080)
[3533700.984]  -> wl_surface@38.frame(new id wl_callback@53)
[3533700.988]  -> wl_surface@38.commit()
[3533701.160] wl_buffer@52.release()
[3533708.721] wl_display@1.delete_id(53)


The surface will only get damaged/redrawn once I click (wl_pointer@13.button).

I've also tested epiphany-browser as I've suspected this might actually be a
webkit-gtk bug, but could not reproduce it there.


-- 
Cheers,

Evangelos
PGP: B938 6554 B7DD 266B CB8E 29A9 90F0 C9B1 8A6B 4A19

Bug#1018937: bug#1010407 erroneous check

[Andres Salomon]

Thanks for the report. This will be fixed in the next upload.

https://salsa.debian.org/chromium-team/chromium/-/commit/483025b5ff30fed9a2cb89a9634a9e91b9a8b2a6

On Sat, Sep 3, 2022 at 14:32, rp  wrote:

I am Raffaele Porta, from Italy. Debian user since 2005.

problem:

if ! grep -q sse3 /proc/cpuinfo; 

will match "ssse3" as well and that's maybe ok.

But sse3 string is NOT present in /proc/cpuinfo for any cpu (intel or 
amd), instead there is "pni" string (Prescott New Instructions) 
always present if sse3 support is present.

So, I think, this checks if cpu has support for ssse3, not sse3.

The matter is that AMD Athlon II x2 is sse3 capable (pni in 
/proc/cpuinfo) but not ssse3 and, with your test, chromium won't run 
on my AMD (and, i think, many other recent AMDs processors too).


Raffaele Porta, Italy.

Bug#1019000: pandoc: LaTeX Error: Environment Shaded undefined.

[Jonas Smedegaard]

Quoting Johannes Schauer Marin Rodrigues (2022-09-03 17:37:29)
> Quoting Jonas Smedegaard (2022-09-03 16:54:53)
> > If you want to explore stepwise what is happening between your
> > 
> >   echo ".. code-block:: none" | pandoc -o out.tex -frst
> > 
> > and my
> > 
> >   echo ".. code-block:: none" | pandoc -o out.pdf -frst
> > 
> > then you are probably helped by addding option "--standalone":
> > 
> >   echo ".. code-block:: none" | pandoc -o out.tex -frst --standalone
> 
> Bingo! Using the --standalone option to pandoc indeed made it generate the
> definition for the Highlighting and Verbatim environments.
> 
> Is there a way to tell pandoc to just give me the preamble
> that --standalone produces so that nothing breaks the next
> time pandoc is updated?

There is no command-line option for pandoc to get more finegrained
templating components.  If you want to programmatically query in more
detail, then you need to interact with the underlying Haskell library
"skylighting" as mentioned in my previous post (which it seems I
accidentally didn't cc you - sorry about that!).


> Anyways, not pandoc's fault, so closing this bug.

Happy that it got solved.  Have a nice weekend!


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

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

signature.asc
Description: signature

Bug#696185: [copyright-format] Use short names from SPDX

[Russ Allbery]

Simon McVittie  writes:

> Sorry, (c) seems very unlikely: earlier versions of SPDX had the same
> convention as DEP-5, but later versions moved to "GPL-2.0-only" and
> "GPL-2.0-or-later", which I think was the result of a request from the
> FSF to make it clearer whether the "or later" clause of the {A,L,}GPL
> family was allowed or excluded.

It was, yes.  The current SPDX identifiers for those licenses are a
political compromise that I wouldn't want to revisit if I were SPDX.

> I would personally be in favour of (b) as our long-term direction, but
> for now the status quo is basically a variation of (a): keep using the
> Debian-specific names where they exist, but where there is no
> Debian-specific name for a license, the SPDX name is as good a name as
> any other.

Agreed on both counts.

Fedora is adopting SPDX wholesale, so while we were dubious at first
whether SPDX had staying power, it looks like it does and is slowly
becoming the standard in free software.  In the long term, that's probably
the direction we want to go.  In the short term, I don't think there's a
huge hurry; there are minor advantages to aligning with them, but SPDX
still has a ton of work to do to absorb all of the licenses in Fedora,
which will help us when we're ready to do a switch.  (But I would
definitely use SPDX identifiers where there isn't a Debian standard to
follow, since it will make that switch easier.)

-- 
Russ Allbery (r...@debian.org)  

Bug#1019044: librust-once-cell-dev: impossible to satidfy dependency on librust-parking-lot-core-0.8-dev

[Jonas Smedegaard]

Control: severity -1 grave

Original content somehow got lost - let me try again...:

The binary package librust-once-cell-dev is impossible to install, as it
depends on missing package librust-parking-lot-core-0.8-dev.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

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

signature.asc
Description: signature

Bug#1019090: librust-petgraph-dev: impossible to satisfy dependency

[Jonas Smedegaard]

Package: librust-petgraph-dev
Version: 0.5.1-2
Severity: grave
Justification: renders package unusable

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512


nary package librust-petgraph-dev cannoy be installed, as it depends on
missing package librust-fixedbitset-0.2-dev.


-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmMTdHYACgkQLHwxRsGg
ASFgBhAAnr1YrSm7uazC0cXPfvvkUocVqWZxvJHuhSTUnoLNhkGKFEhc2xKwLeTy
oVUUzKaNc44YGtUBXJHgU2gXJ7FdR///PG/oXwJoIEILtlsRwBXCdDTgWXmFHn/Z
2NG6J+deddRYKNG7+B4V360e00t946W9CnWluy/ugk0xVnlzL+v5T4skQeOvGcBr
H6D6nNmAGqmre/IwB8q/PbSxEctKgqw4H5MiM0gVYwd7xCzpkqmsFwHOl2J3eMCJ
mFJDqYaaVwx3v4VW+zk5GDJvXAf8wSrz9sOcySkERSwVTiTQYAYW/21nFDv6x551
VXUW786hhbp+FAK0lJLMkDnKcS+Tl/VfnxIiebo60TdSPlX3iJYcrzvYSenmK2jp
S6obupY94cEYvaA+1Ae5wdc5rr0IylMwVPyII95fX5mp21gLvzzHHvF0Edi6AAhs
oYFFYdWMaQxKmLd6sWOPhDHa5kjYtfstk1T3uINutQWVH+KWFSpogyx+XG9VVE+k
mz6U6qKqhlhFd+bEBRJDdRa3k0JXROx7aYUOqzB963uH+49X4VD9z6Ng7j8PJIWk
BIgxxmdJCChStJa3qHRJHfB0nILg5dDQOFYYvgzS3mooOLnya6NVJN3tzhwEpHAt
HNO4VtaNBj6jcOSKaUgTzMKVsNoO2bXuD2Oa39a5Kky+EovXTe8=
=3XsI
-END PGP SIGNATURE-

Bug#1019054: [Pkg-phototools-devel] Bug#1019054: darktable: Darktable does not save Metadata in exported jpgs anymore, even author/copyright entries are gone!

[David Bremner]

Kerstin Hoef-Emden  writes:


> In oldstable, darktable saved all metadata upon export, even temperature of 
> the
> camera body etc. I expect those data either not to be lost, so I can choose
> which ones to delete/maintain with help of exiftool or that the metadata 
> editor
> offers the major spectrum of entries concerning camera settings including
> copyright.

It would be helpful if you can confirm that the problem is still present
in darktable 3.8.0-2~bpo11+1, available from bullseye-backports.

Bug#1019089: debootstrap: Please add new scripts to support suites byzantium and crimson from PureOS

[Carsten Schoenert]

Package: debootstrap
Version: 1.0.127
Severity: wishlist

Dear Maintainer,

the downstream distribution PureOS has created a new suite byzantium
(already a while ago) and recently also a new suite called crimson.

byzantium is targeting/following bullseye, and respective crimson is
the equivalent to the upcoming bookworm suite in Debian.

I've created a MR [1] on Salsa to make an adding of these two suite easy
and convenient.
It would be nice if this could be merge in, that would help working on
PureOS as it makes bootstrapping chroots more easy and working out of the
box.

[1] https://salsa.debian.org/installer-team/debootstrap/-/merge_requests/74

Thanks!

Regards
Carsten

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

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

Versions of packages debootstrap depends on:
ii  wget  1.21.3-1+b2

Versions of packages debootstrap recommends:
ii  arch-test   0.18-1
ii  debian-archive-keyring  2021.1.1
ii  gnupg   2.2.35-3

Versions of packages debootstrap suggests:
ii  binutils2.38.90.20220713-2
pn  squid-deb-proxy-client  
pn  ubuntu-archive-keyring  
ii  xz-utils5.2.5-2.1
ii  zstd1.5.2+dfsg-1

-- no debconf information

Bug#1019088: luarocks: always configured with x86_64 libraries even on other architectures

[Gergely Imreh]

Package: luarocks
Version: 2.4.2+dfsg-1.1
Severity: important

The luarocks package on this version sets up a number of "site_config.lua"
files that configures behaviour. Those files set the relevant library
paths to the "x86_64" ones even on other platforms, such as arm64, armhf 
(armv7).

Relevant lines from the configurations on the current arm64 machine that's 
being used::

> $ cat /usr/share/lua/*/luarocks/site_config.lua |grep x86
> site_config.LUAROCKS_EXTERNAL_DEPS_SUBDIRS={ bin="bin", lib={ "lib", 
> [[lib/x86_64-linux-gnu]] }, include="include" }
> site_config.LUAROCKS_RUNTIME_EXTERNAL_DEPS_SUBDIRS={ bin="bin", lib={ "lib", 
> [[lib/x86_64-linux-gnu]] }, include="include" }
> site_config.LUAROCKS_EXTERNAL_DEPS_SUBDIRS={ bin="bin", lib={ "lib", 
> [[lib/x86_64-linux-gnu]] }, include="include" }
> site_config.LUAROCKS_RUNTIME_EXTERNAL_DEPS_SUBDIRS={ bin="bin", lib={ "lib", 
> [[lib/x86_64-linux-gnu]] }, include="include" }
> site_config.LUAROCKS_EXTERNAL_DEPS_SUBDIRS={ bin="bin", lib={ "lib", 
> [[lib/x86_64-linux-gnu]] }, include="include" }
> site_config.LUAROCKS_RUNTIME_EXTERNAL_DEPS_SUBDIRS={ bin="bin", lib={ "lib", 
> [[lib/x86_64-linux-gnu]] }, include="include" }

> $ ls -1 /usr/share/lua/*/luarocks/site_config.lua
> /usr/share/lua/5.1/luarocks/site_config.lua
> /usr/share/lua/5.2/luarocks/site_config.lua
> /usr/share/lua/5.3/luarocks/site_config.lua

This prevents luarocks to install packages that require actual compilation in 
the system.
This can for example be tested with the `idn2` package, e.g. in an arm64 
environment:

> $ sudo apt install libidn2-0-dev
> ...
> $ luarocks install idn2
> Installing https://luarocks.org/idn2-0.1-0.src.rock
>
> Error: Could not find library file for IDN2
>   No file libidn2.a in /usr/lib
>   No file libidn2.a in /usr/lib/x86_64-linux-gnu
>   No file libidn2.so in /usr/lib
>   No file libidn2.so in /usr/lib/x86_64-linux-gnu
>   No file matching libidn2.so.* in /usr/lib
>   No file matching libidn2.so.* in /usr/lib/x86_64-linux-gnu
> You may have to install IDN2 in your system and/or pass IDN2_DIR or 
> IDN2_LIBDIR to the luarocks command.
> Example: luarocks install idn2 IDN2_DIR=/usr/local

^^^ As visible, luarocks is trying to use the x86_64 libraries.

Fixing up things in place with the following command enables proper 
compilation, not surprisingly:

> $ sudo sed -i 's/lib\/x86_64-linux-gnu/lib\/'`gcc -dumpmachine`'/' 
> /usr/share/lua/*/luarocks/site_config.lua

where "gcc -dumpmachine" inserts the correct gcc triplet for the given 
architecture,
after which the install succeeds:

> $ luarocks install idn2
> Installing https://luarocks.org/idn2-0.1-0.src.rock
> gcc -O2 -fPIC -I/usr/include/lua5.1 -c idn2/idn2.c -o idn2/idn2.o 
> -I/usr/include
> gcc -shared -o idn2.so -L/usr/local/lib idn2/idn2.o 
> -L/usr/lib/aarch64-linux-gnu -Wl,-rpath,/usr/lib/aarch64-linux-gnu: -lidn2
> idn2 0.1-0 is now installed in /usr/local (license: MIT)

This issue affects Debian versions where luarocks 2.x is used (ie. 
bullseye/stable and buster/oldstable as well,
which is still quite widely used).

The testing version of the package on luarocks 3.x is no longer affected.

-- System Information:
Debian Release: 11.4
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: arm64 (aarch64)

Kernel: Linux 5.10.124-linuxkit (SMP w/6 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_RANDSTRUCT
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages luarocks depends on:
ii  liblua5.1-0-dev [liblua5.1-dev]  5.1.5-8.1+b3
ii  lua-any  27
ii  lua5.1   5.1.5-8.1+b3
ii  unzip6.0-26+deb11u1
ii  wget 1.21-1+deb11u1
ii  zip  3.0-12

Versions of packages luarocks recommends:
ii  lua-sec  1.0-1

luarocks suggests no packages.

-- no debconf information

Bug#1019087: nautilus-nextcloud: Needs to be updated for Nautilus 43

[Jeremy Bicha]

Package: nautilus-nextcloud
Version: 3.5.4-1
Severity: important
Tags: bookworm sid patch
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: nautilus-43
Forwarded: https://github.com/nextcloud/desktop/pull/4870
X-Debbugs-CC: he...@debian.org

Nautilus 43 and python-nautilus 4 (both in Debian Experimental) have
made major changes to the Nautilus extension API.

Please upload the fix from the below merge proposal to allow
nautilus-nextcloud to work with both the old and new versions so that
the Nautilus 43 transition is smooth.

https://salsa.debian.org/owncloud-team/nextcloud-desktop/-/merge_requests/12

Thank you,
Jeremy Bicha

Bug#1019086: nautilus-owncloud: Needs to be updated for Nautilus 43

[Jeremy Bicha]

Package: nautilus-owncloud
Version: 2.6.3.14058+dfsg-1
Severity: important
Tags: bookworm sid patch
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: nautilus-43
Forwarded: https://github.com/owncloud/client/pull/10075

Nautilus 43 and python-nautilus 4 (both in Debian Experimental) have
made major changes to the Nautilus extension API.

Please upload the fix from the below merge proposal to allow
nautilus-owncloud to work with both the old and new versions so that
the Nautilus 43 transition is smooth.

https://salsa.debian.org/owncloud-team/owncloud-client/-/merge_requests/2

Thank you,
Jeremy Bicha

Bug#1019000: pandoc: LaTeX Error: Environment Shaded undefined.

[Jonas Smedegaard]

Control: tags -1 +unreproducible

Quoting Jonas Smedegaard (2022-09-03 16:21:21)
> Quoting Johannes Schauer Marin Rodrigues (2022-09-03 15:35:36)
> > so if you run this:
> > 
> > echo ".. code-block:: none" | pandoc -o out.tex -frst
> > 
> > then with the old pandoc 2.9.2.1 you get:
> > 
> > \begin{verbatim}
> > \end{verbatim}
> > 
> > and with pandoc 2.17.1.1 you get:
> > 
> > \begin{Shaded}
> > \begin{Highlighting}[]
> > \end{Highlighting}
> > \end{Shaded}
> 
> Thanks a lot - this makes it much easier to examine the issue further!

...but while the above minimal command demonstrates that "Shaded" gets
introduced in intermediary LaTeX code, this slightly different command
to generate a PDF from that same intermediary LaTeX code does not fail:

  echo ".. code-block:: none" | pandoc -o out.pdf -frst

I tested in a somewhat clean sid environment with this prepation:

  apt --no-install-recommends install pandoc texlive-latex-recommended lmodern


> > so for this to work with pandoc 2.17.1.1 we need some usepackage for
> > the Shaded environment.

I guess (but again I have *not* looked at your original external code,
so really I am only guessing here!) that the real issue might be that a
custom template is used and that custom template needs to be updated to
match newer pandoc processing.

To demonstrate that this is a bug in pandoc I will need to be able to
trigger it with a minimal failing code example.

If you agree that the bug may be in some custom template needing update,
then you can probably find help in comparing the output from older and
newer pandoc of this command:

  pandoc --print-default-template latex

If you want to explore stepwise what is happening between your

  echo ".. code-block:: none" | pandoc -o out.tex -frst

and my

  echo ".. code-block:: none" | pandoc -o out.pdf -frst

then you are probably helped by addding option "--standalone":

  echo ".. code-block:: none" | pandoc -o out.tex -frst --standalone


Kind regards,

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

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

signature.asc
Description: signature

Bug#1015758: ocaml-odoc: autopkgtests failures

[Gianfranco Costamagna]

Hello, ping?

G.

On Wed, 20 Jul 2022 18:42:32 +0200 Gianfranco Costamagna 
 wrote:

Source: ocaml-odoc
Version: 2.1.0+dfsg-1
Severity: serious

Hello, as said, the autopkgtests are now failing due to new ocaml or new ocaml 
libraries.

https://ci.debian.net/data/autopkgtest/unstable/amd64/o/ocaml-odoc/23587053/log.gz

Please have a look if the new upstream version is enough to fix it.


autopkgtest [04:42:43]: test odoc-on-odoc: [---
File series fully applied, ends at patch debian/patches/no-vendored-js-highlight
File "src/odoc/bin/main.ml", line 9, characters 51-64:
9 | let convert_syntax : Odoc_document.Renderer.syntax Arg.converter =
^
Error (alert deprecated): Cmdliner.Arg.converter
Use Arg.conv' function instead.
File "src/odoc/bin/main.ml", line 9, characters 51-64:
9 | let convert_syntax : Odoc_document.Renderer.syntax Arg.converter =
^
Error (alert deprecated): Cmdliner.Arg.converter
Use Arg.conv' function instead.
File "src/odoc/bin/main.ml", line 21, characters 60-73:
21 | let convert_directory ?(create = false) () : Fs.Directory.t Arg.converter =
  ^
Error (alert deprecated): Cmdliner.Arg.converter
Use Arg.conv' function instead.
File "src/odoc/bin/main.ml", line 73, characters 6-17:
73 |   Arg.env_var "ODOC_WARN_ERROR" ~doc:(doc ^ " See option $(opt).")
^^^
Error (alert deprecated): Cmdliner.Arg.env_var
Use Cmd.Env.info instead.
File "src/odoc/bin/main.ml", line 82, characters 14-25:
82 | let env = Arg.env_var "ODOC_PRINT_WARNINGS" ~doc in
^^^
Error (alert deprecated): Cmdliner.Arg.env_var
Use Cmd.Env.info instead.
File "src/odoc/bin/main.ml", line 217, characters 4-13:
217 | Term.info "compile"
   ^
Error (alert deprecated): Cmdliner.Term.info
Use Cmd.info instead.
File "src/odoc/bin/main.ml", line 113, characters 13-22:
113 |   val info : Term.info
^
Error (alert deprecated): Cmdliner.Term.info
Use Cmd.info instead.
File "src/odoc/bin/main.ml", line 236, characters 4-13:
236 | Term.info ~doc "support-files"
   ^
Error (alert deprecated): Cmdliner.Term.info
Use Cmd.info instead.
File "src/odoc/bin/main.ml", line 247, characters 4-13:
247 | Term.info ~doc "css"
   ^
Error (alert deprecated): Cmdliner.Term.info
Use Cmd.info instead.
File "src/odoc/bin/main.ml", line 288, characters 13-22:
288 |   let info = Term.info ~doc:"Link odoc files together" "link"

Bug#1019052: curl 7.74.0-1.3+deb11u3 flagged for acceptance

[Adam D Barratt]

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

Hi,

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

Thanks for your contribution!

Upload details
==

Package: curl
Version: 7.74.0-1.3+deb11u3

Explanation: reject cookies with "control bytes" [CVE-2022-35252]

Bug#1019064: Transition KDE PIM 22.08

[Patrick Franz]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-Cc: delta...@debian.org, debian-qt-...@lists.debian.org

Hi Release team,

we would like to request a transition for KDE PIM 22.08.

We have uploaded KDE PIM 22.08 to experimental, but since KDE PIM
does not provide ABI stability and some packages outside of
KDE PIM depend on it, we need a transition.

The packages depending on KDE PIM are:

* digikam
* kgpg
* kio-gdrive
* kjots
* kmymoney
* kraft
* zanshin

I've uploaded a fix for kjots to build against KDE PIM 22.08, but all
other packages should just need a rebuild.

Here is the Ben file:

---
title = "KDEPIM 22.08";

is_affected = .depends ~ /libkf5.*-22.04/ | .depends ~ /libkf5.*-22.08/;
is_good = .depends ~ /libkf5.*-22.08/;
is_bad = .depends ~ /libkf5.*-22.04/;
---

Thank you.


-- 
Med vänliga hälsningar

Patrick Franz

Bug#1019000: pandoc: LaTeX Error: Environment Shaded undefined.

[Jonas Smedegaard]

Quoting Johannes Schauer Marin Rodrigues (2022-09-03 15:35:36)
> Quoting Jonas Smedegaard (2022-09-03 11:41:22)
> > It would be helpful if you could isolate the problem, so that it is
> > possible to replicate with as minimal as possible code besides
> > Pandoc.
> 
> so if you run this:
> 
> echo ".. code-block:: none" | pandoc -o out.tex -frst
> 
> then with the old pandoc 2.9.2.1 you get:
> 
> \begin{verbatim}
> \end{verbatim}
> 
> and with pandoc 2.17.1.1 you get:
> 
> \begin{Shaded}
> \begin{Highlighting}[]
> \end{Highlighting}
> \end{Shaded}

Thanks a lot - this makes it much easier to examine the issue further!


> so for this to work with pandoc 2.17.1.1 we need some usepackage for
> the Shaded environment.
> 
> So lets see how to fix this from the latex side. You pointed out that
> the Shaded environment comes from framed.sty, so we try:
> 
> \documentclass{article}
> \usepackage{framed}
> \begin{document}
> \begin{Shaded}
> \begin{Highlighting}[]
> foobar
> \end{Highlighting}
> \end{Shaded}
> \end{document}
> 
> But we still get:
> 
> ! LaTeX Error: Environment Shaded undefined.
> 
> So how do I prepare my latex that was generated by recent pandoc so
> that it works?

One extra clue I just found is that apparently the tex chunk involving
"Shading" is not part of Pandoc templates but injected by Haskell
library skylighting:
https://github.com/Wandmalfarbe/pandoc-latex-template/issues/209#issuecomment-744068500


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

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

signature.asc
Description: signature

Bug#1019063: maxima: no Homepage field

[Jakub Wilk]

Source: maxima
Version: 5.46.0-3
Severity: wishlist

Please add

  Homepage: https://maxima.sourceforge.io/

to debian/control.

--
Jakub Wilk

Bug#1018873: live-build --firmware-chroot option is broken due to nvidia-tesla{-470,}-kernel-support

[Witold Barylulk]

Package: nvidia-tesla-kernel-support
Followup-For: Bug #1018873
X-Debbugs-Cc: witold.bary...@gmail.com

I am also hitting this issue for few weeks now when trying to build a iso
using live-build.

I tried explicitly telling live build to remove the
nvidia-tesla-kernel-support (by using nvidia-tesla-kernel-support- ), and
even setting a pat hold before package are installed, but still something
tries to install it and it fails.

My guess, is that something does recommend or suggest it, and the install
is attempted.

I do not install it explicitly in my package list, so that is the only
explanation.

It is rather annoying, and I do not see a way to workaround it.

I do not personally need Nvidia support, but live build does support
installing nvidia-kernel-dkms , so theoretically it is possible.

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

Kernel: Linux 5.19.0-rc5 (SMP w/32 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN, TAINT_UNSIGNED_MODULE, TAINT_SOFTLOCKUP
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)

Versions of packages nvidia-tesla-kernel-support depends on:
ii  nvidia-kernel-common  20220217+1
ii  nvidia-modprobe   515.48.07-1
pn  nvidia-tesla-alternative  
pn  nvidia-tesla-alternative--kmod-alias  

nvidia-tesla-kernel-support recommends no packages.

nvidia-tesla-kernel-support suggests no packages.

Bug#696185: [copyright-format] Use short names from SPDX

[Simon McVittie]

Please keep the subject line in place when replying to bugs, to give
readers some context (maintainers will often be seeing bug mail as a
single message among many unrelated messages).

On Sat, 03 Sep 2022 at 16:22:46 +0500, Akbarkhon Variskhanov wrote:
> FSF[1] as well as SPDX[2] request using the suffixes "-only" or
> "-or-later" with GNU licenses:
> 
> > Therefore, when you use SPDX license indicators, please use these:
> > GPL-2.0-only or GPL-2.0-or-later
> 
> DEP-5 uses the bare form, i.e. "GPL-3" or "GPL-3+". I added this
> difference to the wiki page.
> 
> What's not clear is how are we going to approach this discrepancy?
> Shall we a) ignore this, b) adopt SPDX/FSF naming, or c) suggest SPDX
> to stick to uniform naming convention, which is using "+" to denote
> later versions of a license?

Sorry, (c) seems very unlikely: earlier versions of SPDX had the same
convention as DEP-5, but later versions moved to "GPL-2.0-only" and
"GPL-2.0-or-later", which I think was the result of a request from the
FSF to make it clearer whether the "or later" clause of the {A,L,}GPL
family was allowed or excluded.

Forms like GPL-2.0, LGPL-3.0+ and so on are still listed in
https://spdx.org/licenses/ as deprecated equivalents of GPL-2.0-only,
LGPL-3.0-or-later and so on.

I would personally be in favour of (b) as our long-term direction,
but for now the status quo is basically a variation of (a): keep using
the Debian-specific names where they exist, but where there is no
Debian-specific name for a license, the SPDX name is as good a name as
any other.

> [2] https://spdx.dev/ids/

I believe the canonical reference for the SPDX license identifiers is
https://spdx.org/licenses/ which also lists all the deprecated forms.

smcv

Bug#1018191: libapreq2: CVE-2022-22728: multipart form parse memory corruption

[Steinar H. Gunderson]

On Fri, Aug 26, 2022 at 09:07:06PM +0200, Salvatore Bonaccorso wrote:
> The following vulnerability was published for libapreq2.
> 
> CVE-2022-22728[0]:
> | A flaw in Apache libapreq2 versions 2.16 and earlier could cause a
> | buffer overflow while processing multipart form uploads. A remote
> | attacker could send a request causing a process crash which could lead
> | to a denial of service attack.

Based on the description, I assume it is this one:

http://svn.apache.org/viewvc?view=revision&revision=1866760

I'm not sure if it counts as “buffer overflow”, but given that it only
mentions DoS and not arbitrary code execution, NULL pointer dereference
looks a lot like it. 2.13 appears vulnerable to me, given the description.

I don't use libapreq2 anymore, so anyone wanting to pick up the package
would be more than welcome. Upstream homepage is now seemingly at:

  https://httpd.apache.org/apreq/

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#1019062: opentracing-cpp: FTBFS on riscv64

[Eric Long]

Source: opentracing-cpp
Version: 1.6.0-2
Severity: normal
Tags: ftbfs patch
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: i...@hack3r.moe

Dear maintainer,

opentracing-cpp failed to build on riscv64 due to not linking libatomic:

```
[ 81%] Linking CXX executable ../../output/mocktracer_propagation_test
cd /<>/obj-riscv64-linux-gnu/mocktracer/test && /usr/bin/cmake -E 
cmake_link_script CMakeFiles/mocktracer_propagation_test.dir/link.txt 
--verbose=1
/usr/bin/c++ -g -O2 -ffile-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2 -Wall -Wextra -Wl,-z,relro -Wl,-z,now -rdynamic 
CMakeFiles/mocktracer_propagation_test.dir/propagation_test.cpp.o -o 
../../output/mocktracer_propagation_test  
-Wl,-rpath,/<>/obj-riscv64-linux-gnu/output 
../../output/libopentracing_mocktracer.so.1.6.0 
../../output/libopentracing.so.1.6.0 -ldl 
/usr/bin/ld: ../../output/libopentracing_mocktracer.so.1.6.0: undefined 
reference to `__atomic_exchange_1'
collect2: error: ld returned 1 exit status
make[3]: *** 
[mocktracer/test/CMakeFiles/mocktracer_tracer_factory_test.dir/build.make:102: 
output/mocktracer_tracer_factory_test] Error 1
make[3]: Leaving directory '/<>/obj-riscv64-linux-gnu'
make[2]: *** [CMakeFiles/Makefile2:1097: 
mocktracer/test/CMakeFiles/mocktracer_tracer_factory_test.dir/all] Error 2
make[2]: *** Waiting for unfinished jobs
/usr/bin/ld: ../../output/libopentracing_mocktracer.so.1.6.0: undefined 
reference to `__atomic_exchange_1'
collect2: error: ld returned 1 exit status
make[3]: *** 
[mocktracer/test/CMakeFiles/mocktracer_json_test.dir/build.make:102: 
output/mocktracer_json_test] Error 1
make[3]: Leaving directory '/<>/obj-riscv64-linux-gnu'
make[2]: *** [CMakeFiles/Makefile2:1151: 
mocktracer/test/CMakeFiles/mocktracer_json_test.dir/all] Error 2
/usr/bin/ld: ../../output/libopentracing_mocktracer.so.1.6.0: undefined 
reference to `__atomic_exchange_1'
collect2: error: ld returned 1 exit status
make[3]: *** 
[mocktracer/test/CMakeFiles/mocktracer_tracer_test.dir/build.make:102: 
output/mocktracer_tracer_test] Error 1
make[3]: Leaving directory '/<>/obj-riscv64-linux-gnu'
make[2]: *** [CMakeFiles/Makefile2:1070: 
mocktracer/test/CMakeFiles/mocktracer_tracer_test.dir/all] Error 2
/usr/bin/ld: ../../output/libopentracing_mocktracer.so.1.6.0: undefined 
reference to `__atomic_exchange_1'
collect2: error: ld returned 1 exit status
make[3]: *** 
[mocktracer/test/CMakeFiles/mocktracer_propagation_test.dir/build.make:102: 
output/mocktracer_propagation_test] Error 1
make[3]: Leaving directory '/<>/obj-riscv64-linux-gnu'
make[2]: *** [CMakeFiles/Makefile2:1124: 
mocktracer/test/CMakeFiles/mocktracer_propagation_test.dir/all] Error 2
make[2]: Leaving directory '/<>/obj-riscv64-linux-gnu'
make[1]: *** [Makefile:169: all] Error 2
make[1]: Leaving directory '/<>/obj-riscv64-linux-gnu'
dh_auto_build: error: cd obj-riscv64-linux-gnu && make -j4 "INSTALL=install 
--strip-program=true" VERBOSE=1 returned exit code 2
make: *** [debian/rules:6: binary-arch] Error 25
dpkg-buildpackage: error: debian/rules binary-arch subprocess returned exit 
status 2
```

Full buildd log: 
https://buildd.debian.org/status/fetch.php?pkg=opentracing-cpp&arch=riscv64&ver=1.6.0-3&stamp=1661892134&raw=0

I've attached a patch that fixes FTBFS on riscv64. Please let me know if I
missed anything.

Cheers,
Eric

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

Kernel: Linux 5.18.0-4-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Description: Link libatomic on riscv64 and fix FTBFS
Author: Eric Long 
Last-Update: 2022-09-03
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -155,6 +155,9 @@
   list(APPEND LIBRARIES ${CMAKE_DL_LIBS})
 endif()
 
+if (${CMAKE_SYSTEM_PROCESSOR} STREQUAL "riscv64")
+  list(APPEND LIBRARIES atomic)
+endif()
 
 if (BUILD_SHARED_LIBS)
   add_library(opentracing SHARED ${SRCS})

Bug#994540: transition: imagemagick

[Sebastian Ramacher]

Control: tags -1 confirmed

On 2022-07-15 14:03:24 +0200, Johannes Schauer Marin Rodrigues wrote:
> Hi Sebastian,
> 
> Quoting Sebastian Ramacher (2022-07-13 22:52:52)
> > On 2021-09-29 10:38:07 +0200, jo...@mister-muffin.de wrote:
> > > > Do all reverse dependencies build fine with the new Imagemagick version?
> > > > If not, have bugs been filed?
> > > 
> > > I have rebuilt all 399 source packages that have at least one binary 
> > > produced
> > > by src:imagemagick in their build dependency installation closure. Of 
> > > those, 16
> > > packages FTBFS with the imagemagick version form experimental but succeed 
> > > with
> > > the version from unstable. Of those, only one package (src:wand) is in 
> > > the list
> > > from https://release.debian.org/transitions/html/auto-imagemagick.html I 
> > > filed
> > > this failure as #995290 and will investigate the other 15 instances as 
> > > well.
> > > But since those source packages are not part of the transition, they 
> > > should
> > > probably not block this bug.
> > 
> > This transition completly dropped off my radar, sorry!
> > 
> > What's the current status of the preparations? Have the bugs been filed?
> 
> we had one build failure in src:wand which I fixed in imagemagick upload of
> 8:6.9.12.20+dfsg1-1.2 to experimental. See also #995290

Please go ahead

Cheers
-- 
Sebastian Ramacher