Bug#293272: cron: "@include common-session" in PAM config logs to auth.log

[Christian Weiske]

/etc/pam.d/common-session-noninteractive:
---
session [success=1 default=ignore] pam_succeed_if.so service in cron quiet 
use_uid
---


Works fine on Debian 12.

--
Regards/Mit freundlichen Grüßen
Christian Weiske

-=≡ Geeking around in the name of science since 1982 ≡=-

Bug#1056931: libgphoto2-6: Move files into /usr (incl. DEP17 P7 mitigation)

[Andreas Metzler]

On 2023-11-26 Chris Hofstaedtler  wrote:
[...]
> Please consider applying this patch at your earliest convenience.

Looks good to me, thanks!

@Ferenc: I can fix this via a Team upload, unless you do not want me to.

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'


signature.asc
Description: PGP signature

Bug#1057183: welcome message in 1.8~RC2-2 is always shown (+workaround)

[Alexander Zangerl]

Package: nmh
Version: 1.8~RC2-2
Severity: minor

the nmh code normally shows a 'welcome to the new version' banner/message
once, if it finds an nmh context file with an older nmh version.

however, with the release candidate version in bookworm that detection
logic fails...and the welcome doesn't go away and becomes very unwelcome.

workaround: add

Welcome: disable

to your ~/.mh_profile.

Bug#1055645: orphan-sysvinit-scripts: Please take over mdadm init script

[tito]

On Fri, 1 Dec 2023 02:41:21 +0100
Lorenzo  wrote:

> Control: tags -1 patch
> 
> Hello Matthew,
> 
> attached is a git patch that adds mdadm and mdadm-waitidle
> scripts.
> 
> On Thu, 9 Nov 2023 16:09:22 +0100
> Stephan Seitz  wrote:
> 
> > [...]
> 
> >   * Removing cron jobs in favour of systemd timers:
> > - daily checks also work if system is not always on (Closes:
> > #889978).
> I thought that anacron could handle this..
> 
> > 
> > Even the cronjob is gone.
> 
> sorry, the patch does not include cronjob since o-s-s does not have
> a way to handle it.

Couldn't it be appended to crontab?

> By the way I don't remember a project consensus for dropping
> cronjobs in favour of timers..
> 
> Best Regards,
> Lorenzo
> 

Hi,
shouldn't /etc/default/mdadm be moved also to o-s-s?
I bet it is the next file to be dropped after timers
 
Ciao,
Tito

Bug#1056556: Debugging techniques

[Johannes Schauer Marin Rodrigues]

Hi,

Quoting Dima Kogan (2023-12-01 05:11:19)
> Johannes Schauer Marin Rodrigues  writes:
> >> Would that work, though?
> > Yes. Did you try it and it did not work? What was the error message?
> 
> No :) I wanted to read about what it did first. I tried it just now,
> though. With the --included metapackage it has the same behavior as
> before: complains that it can't install libopencv-dev.

yes, which is why I said not to use --include when trying this.

> If I don't ask it to --install the problematic package, intending to
> manually poke apt, then I can't do that: the problematic package is
> nowhere to be found. It was originally on disk locally, but without
> --include, it was never copied into the bind mount.

Sure, you just have to do that yourself.

> I do want to have a metapackage: this allows the metapackage to be updated in
> the future, and have users be able to "apt update && apt upgrade".

Yes, I think you should keep the metapackage.

> I guess I could do this differently for testing. By making the metapackage
> available in an apt server, and using an undocumented option. That's a heavy
> lift though. If I was so expert to know to do these things, I probably
> wouldn't need to debug stuff in the first place

You don't need to use an undocumented option. Running
--chrooted-customize-hook=bash is nearly the same as running
--customize-hook='chroot "$1" bash' but the latter is much harder to type due
to quoting and special chars so I suggested to do the former. But nothing stops
you from sticking to the documented methods.

> > Yes, in the man page of apt_preferences it says: "The files have either no
> > or "pref" as filename extension". In one of my last mails to you I also
> > suggested you add:
> >
> > --setup-hook='{ echo "Package: XXX"; echo "Pin: origin \"YYY\""; echo
> > "Pin-Priority: 1"; } > "$1"/etc/apt/preferences.d/mypinnings.pref'
> >
> > Notice that I used the correct filename extension.
> 
> Yep. I liked my extension better, but didn't realize that the name was
> significant.

Maybe only try out different things *after* you have it working? ;)

> > Which apt command produced the error? I also don't think it was an error.
> > It was only a warning, right? Did you get it for "apt-get update" or for
> > "apt-get install"?
> 
> Great questions. I just tried it again:
> 
>   $ sudo apt update  
> 
>   
>   N: Ignoring file 'mypinnings.conf' in directory '/etc/apt/preferences.d/' 
> as it has an invalid filename extension
> 
> So I don't know what the answer is.

By default, mmdebstrap does not print the output of the commands it runs. It
does that though when something goes wrong. So if "apt install" fails, then you
get its output. In your case, you missed a "note" (not even a warning) in the
"apt update" output. You would've seen that if you had run mmdebstrap with the
--verbose option.

> But this felt undebuggable, and I wish I could figure this stuff without
> sinking many hours into it or asking you every time.

I still wonder what we can learn from all of this.

You initially suggested mmdebstrap to drop down to a shell and print a command
for the user to re-run. Lets assume that this were possible (I don't think it
is feasible). In that case, you still would not've known how to proceed or that
it is the apt pinning that is at fault. If you had known that it was apt
pinning (as we know now), then you could've just added this to your mmdebstrap
invocation to debug this:

--essential-hook='chroot "$1" apt-cache policy libopencv-dev'

But even if you had and you had seen that the pin priority was wrong, how could
you have proceeded? At that point (and before installing
tst-libopencv_1_arm64.deb via --include) you could've given yourself an
interactive shell by adding (and lets stick to the documented options this
time):

--essential-hook='chroot "$1" bash'

You could've then maybe figured out what was going on as you can then make
changes and run "apt-cache policy" until it looks good. But maybe you wouldn't
have know it because you still would not've seen the apt "note" from above
about the filename extension because even though you encountered an error, you
did not run mmdebstrap with --verbose and I think it is common practice to
increase the verbosity of a program first when something goes wrong.

So given all of this, I don't think your initial suggestion of adding a
facility to drop to a shell and re-run a command in shell would've fixed your
problem. It would not've given you the additional knowledge that apt pinning is
at fault, you still would have to do the bind-mount yourself manually (or would
you expect that bind mounting to be translated into a shell command as well?)
and you still would not've seen that apt "note" about your preferences file
name.

So I'm at a loss at what to take away from this situation for mmdebstrap.

I have no problem helping you with this and it doesn't bother me but I also
don't see 

Bug#1015293: wrong row targeted with "insert ... on duplicate" and "replace", leading to data corruption

[Otto Kekäläinen]

From: https://jira.mariadb.org/browse/MDEV-30046

The commit 
https://github.com/MariaDB/server/commit/703e73e221a42638f2f05379124b35c57482da93
was never in a pull request nor included on any branch, and `git log
-S MDEV-30046` does not yield any results from 10.5 branch, so I
assume this issue is still open (and thus will also continue to keep
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1015293 open).

Hence a fix for this in unlikely to be included in
https://salsa.debian.org/mariadb-team/mariadb-10.5/-/merge_requests/16

Bug#1057182: RM: syndie -- RoQA; Depends on i2p

[Salvatore Bonaccorso]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: syn...@packages.debian.org, Masayuki Hatta , 
t...@security.debian.org, car...@debian.org
Control: affects -1 + src:syndie

Hi

With the pending removal of i2p syndie needs to be removed along:

carnil@respighi:~$ dak rm --suite=unstable -n -R i2p
Will remove the following packages from unstable:

   i2p | 0.9.48-1.1 | source, all
   i2p-doc | 0.9.48-1.1 | all
i2p-router | 0.9.48-1.1 | all
libjbigi-jni | 0.9.48-1.1 | amd64, arm64, armel, armhf, i386, mips64el, 
ppc64el, riscv64, s390x

Maintainer: Masayuki Hatta 

--- Reason ---

--

Checking reverse dependencies...
# Broken Depends:
syndie: syndie

# Broken Build-Depends:
syndie: i2p-router

Dependency problem found.

So please remove syndie as well.

Regards,
Salvatore

Bug#1057181: RM: i2p -- RoQA; not in stable for several releases, security issues

[Salvatore Bonaccorso]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: i...@packages.debian.org, t...@security.debian.org, Masayuki 
Hatta , car...@debian.org
Control: affects -1 + src:i2p

Hi

i2p has missed some stable releases and has outstanding security
issues. Due to the type of package it seems as well reasonable that it
will catch up with new upstream versions in case it is again present
in unstable (which is not excluded).

syndie will need to be removed as well, will fill a separate request.

Regards,
Salvatore

Bug#1057180: bullseye-pu: package mariadb-10.5 1:10.5.23-0+deb11u1

[Otto Kekäläinen]

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

I propose that the latest version of MariaDB 10.5.23 be included in
the oldstable release update of Debian.

According to https://release.debian.org/ there is no planned point
release for Bullseye at the moment. It is however still too new for
LTS (https://wiki.debian.org/LTS). This might also go in as a security
upload. Deciding on the urgency and upload channel is not coupled to
the actual preparation of the upload, which I have in progress at
https://salsa.debian.org/mariadb-team/mariadb-10.5/-/merge_requests/16

I am filing this bug report for tracking purposes. The final version
and changelog and debdiff will be posted later.

Bug#1057179: bookworm-pu: package mariadb-10.6 1:10.11.6-0+deb12u1

[Otto Kekäläinen]

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

I propose that the latest version of MariaDB 10.11.6 be included in
the stable release update of Debian.

I am filing this bug report for tracking purposes. The final version
and changelog and debdiff will be posted later. Work-in-progress at
https://salsa.debian.org/mariadb-team/mariadb-server/-/merge_requests/60

Bug#1055951: RFS: multispeech/4.6.0-1 [ITP] -- Multilingual speech server for Emacspeak

[Igor B. Poretsky]

Hello Tobias,

> "Tobias" == Tobias Frost  writes:

Tobias> You should be able to just re-upload to mentors. If it does
Tobias> not allow that, remove the package manually from mentors,
Tobias> then re-upload. In the case a bot auto-close this RFS bug,
Tobias> just manually re-open it (do not file a new one)

Indeed, I've done it without a problem. Thus, I've re-uploaded all my
packages, not only Multispeech. And, since the issues listed are actual
for other my packages as well, I tried to address them their as well.

Tobias> On further iterations, you keep at -1 until this is
Tobias> sponsored.

But some things should be fixed on the upstream level. Of course, I can
do it with Debian patches, but is it a point when I am an upstream
developer myself? How should I act in this situation?

Best regards,
Igor.

Bug#1057178: FTBFS: unsatisfiable build-deps in testing on mdds and liborcus

[Rene Engelhard]

Source: libreoffice
Version: 4:7.5.9~rc1-1
Severity: serious
Tags: wontfix trixie

Hi,

apparently mdds 2.1/liborcus 0.19 migrated to testing even though
Build-Depends clearly say

   libmdds-dev (<< 2.1~),
   libmdds-dev (>= 2.0),

and

   liborcus-dev (<< 0.18~),
   liborcus-dev (>= 0.17.2),

and testings LO depending on liborcus-0.17.0. The latter is probably due
to the smooth transitions, but the former now causes this to be
unbuildable.

Filing for documentation purposes. Obviously fixed in sid, thankfully 
4:7.5.9~rc1-1
is the end of a branch.

Regards,

Rene

Bug#1057177: ITP: jaq -- A jq clone focussed on correctness, speed, and simplicity

[陳昌倬]

Package: wnpp
Severity: wishlist
Owner: ChangZhuo Chen (陳昌倬) 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: jaq
  Version : v1.2.0
  Upstream Contact: Michael Färber
* URL : https://github.com/01mf02/jaq
* License : Expat
  Programming Lang: Rust
  Description : A jq clone focussed on correctness, speed, and simplicity

 jaq is a clone of the JSON data processing tool jq. jaq aims to
 support a large subset of jq's syntax and operations.
 .
 jaq focuses on three goals:
 .
 Correctness: jaq aims to provide a more correct and predictable
 implementation of jq, while preserving compatibility with jq in most
 cases.
 .
 Performance: I created jaq originally because I was bothered by jq's
 long start-up time, which amounts to about 50ms on my machine. This can
 particularly show when processing a large number of small files. jaq
 starts up about 30 times faster than jq 1.6 and outperforms jq also on
 many other benchmarks.
 .
 Simplicity: jaq aims to have a simple and small implementation, in
 order to reduce the potential for bugs and to facilitate contributions.

The package will be maintained under the umbrella of the pkg-rust.

-- 
ChangZhuo Chen (陳昌倬) czchen@{czchen,debian}.org
Key fingerprint = BA04 346D C2E1 FE63 C790  8793 CC65 B0CD EC27 5D5B


signature.asc
Description: PGP signature

Bug#1056754: marked as done (bouncycastle: CVE-2023-33202)

[tony mancill]

On Thu, Nov 30, 2023 at 09:51:09PM +, Debian Bug Tracking System wrote:
> Subject: Bug#1056754: fixed in bouncycastle 1.77-1
> 
> Source: bouncycastle
> Version: 1.77-1
> Distribution: unstable
> Changed-By: Markus Koschany 
>* New upstream version 1.77. (Closes: #1049356)

Hi Markus,

Thank you for your efforts to get BC updated.

>* Remove backward-compatibility.patch. It is time to fix those issues
>  properly in our reverse-dependencies.

I agree completely.  And thank you for filing bugs for the r-deps that
need to be addressed.

Cheers,
tony

Bug#1056556: Debugging techniques

[Dima Kogan]

Johannes Schauer Marin Rodrigues  writes:

>> > mmdebstrap ... --variant=apt --chrooted-customize-hook=bash unstable 
>> > /dev/null
>> 
>> Would that work, though?
> Yes. Did you try it and it did not work? What was the error message?

No :) I wanted to read about what it did first. I tried it just now,
though. With the --included metapackage it has the same behavior as
before: complains that it can't install libopencv-dev.

If I don't ask it to --install the problematic package, intending to
manually poke apt, then I can't do that: the problematic package is
nowhere to be found. It was originally on disk locally, but without
--include, it was never copied into the bind mount.

I do want to have a metapackage: this allows the metapackage to be
updated in the future, and have users be able to "apt update && apt
upgrade".

I guess I could do this differently for testing. By making the
metapackage available in an apt server, and using an undocumented
option. That's a heavy lift though. If I was so expert to know to do
these things, I probably wouldn't need to debug stuff in the first place



>> In any case, I figured out my specific problem by creating a similar
>> scenario on a native arm64 box. I was naming the pinning file .conf
>> instead of .pref which apparently matters.
>
> Yes, in the man page of apt_preferences it says: "The files have either no or
> "pref" as filename extension". In one of my last mails to you I also suggested
> you add:
>
> --setup-hook='{ echo "Package: XXX"; echo "Pin: origin \"YYY\""; echo
> "Pin-Priority: 1"; } > "$1"/etc/apt/preferences.d/mypinnings.pref'
>
> Notice that I used the correct filename extension.

Yep. I liked my extension better, but didn't realize that the name was
significant.


>> On the arm64 box this produced a clear error message ("apt" told me to
>> rename the file). But with mmdebstrap there was no specific error at all, as
>> you saw. Any idea why?
>
> Which apt command produced the error? I also don't think it was an error. It
> was only a warning, right? Did you get it for "apt-get update" or for "apt-get
> install"?

Great questions. I just tried it again:

  $ sudo apt update  

  
  N: Ignoring file 'mypinnings.conf' in directory '/etc/apt/preferences.d/' as 
it has an invalid filename extension

So I don't know what the answer is. But this felt undebuggable, and I
wish I could figure this stuff without sinking many hours into it or
asking you every time.

Thanks for the help, as always.

Bug#1051803: ITS: freespace2

[Dmitry Smirnov]

On Wednesday, 29 November 2023 10:33:58 PM AEDT Alexandre Detiste wrote:
> There's only "debian/", can you also upload an "upstream" branch ?
> 
> I'd like to enable CI on this repository, so it should be self contained
> without need to fish .tgz from
> https://mentors.debian.net/debian/pool/non-free/f/freespace2/
> 
> Please also test that "gbp buildpackage" works with a fresh throwaway
> "gbp clone".

Thank you very much, both of you, for all the care and work that you've
dedicated to "freespace2".

I'm terribly sorry that I could not attend this package earlier. 
I'm working on it today as some changes should be made, IMHO.

I hope to finish before next week. I will take care of CI and I'm going
to add a README.source describing how to build for amd64 and i386 and
"mergechanges".

I recommend simplified build procedure without GBP:

  https://salsa.debian.org/onlyjob/notes/-/wikis/bp

IMHO it is too much hassle to import-orig when it comes to MUT
packages. We just have to make sure that "origtargz" works -- that is
the best way to obtain sources. 

-- 
All the best,
 Dmitry Smirnov
 GPG key : 4096R/52B6BBD953968D1B

---

Just as everyone in a tribe praying to a volcano god would reinforce the
idea that there is a volcano god, so begging politicians for favors
reinforces the idea that there is a rightful ruling class, that their
commands are "law," and that obedience to such "laws" is a moral
imperative.
 -- Larken Rose, The Most Dangerous Superstition


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

Bug#1057176: lintian: Take dpkg-build-api into account for Rules-Requires-Root

[Guillem Jover]

Package: lintian
Version: 2.116.3
Severity: wishlist

Hi!

Starting with dpkg 1.22.0, it implements a dpkg-build-api similar in
concept to the debhelper-compat levels.

You can check its documentation in the dpkg-build-api(7) and
dpkg-buildapi(1) manual pages.

It would be nice if lintian took this level into account when emitting
tags, to avoid false positives. In particular for Rules-Requires-Root,
which in level 1 defaults to value «no» instead of «binary-targets».

[ I've noticed I didn't update the deb-src-control(5) manual page,
  so I've done that locally now and will be part of the next dpkg
  release. ]

Thanks,
Guillem

Bug#622947: per-maintainer insights into migrations and transitions

[Paul Wise]

On Thu, 2023-11-30 at 14:14 +0100, Paul Gevers wrote:

> The tracker has been doing this for years now.

distro-tracker doesn't have per-maintainer pages
at all and neither does the QA excuses page AFAICT.

The DDPO kind of does, but doesn't list transitions etc.

The DMD kind of does too, but also no transitions etc.

So I suggest reopening this request.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#1055431: RFS: scala-mode-el/1:1.1.0+git20221025.5d7cf21-1 [RC] [Team] -- Emacs major mode for editing scala source code

[Xiyue Deng]

Nicholas D Steeves  writes:

> Xiyue Deng  writes:
>
>> Nicholas D Steeves  writes:
>>
>>
>>> Have you asked upstream to tag a release?
>>>
>>
>> Not before your review but done by now at [1]
>
> Thank you.  You may have heard that Debian is a distribution that
> privileges the stable release model...  When the human maintainer of a
> Debian package tracks stable releases, why is importing a snapshot
> justified?
>

There are about 3 years of newer commits since 1.1.0, and one of the
major changes is that it adds support of scala 3 syntax which is not yet
in a tagged release and would be good to have.  Also seeing the last
commit is from the end of last year, I sense that upstream may becoming
a bit dormant for the time being, which is why I prefer to package the
latest snapshot instead of waiting for a stable release.

> Also, do you use this package?
>

Not on a regular basis, but I do use it a bit once in a while as I try
to learn a bit of new programming languages every few months.

* Override clean rules in d/rules to fix building. (Closes:
#1052917)
>>>
>>> I believe you already know that
>>>
>>> override_dh_auto_clean:
>>>/bin/true
>>>
>>> is an incorrect approach.
>>>
>>
>> Indeed it was not ideal.  Upstream depends on Cask to generated the
>> scala-mode-pkg.el file that is used in the clean target to get the name
>> of the generated tarball, and indeed using this lazy approach is
>> incorrect.  I've now included the generated pkg file through a patch to
>> make this work in [2].
>
> Consistency is essential between an explanation (in a comment or
> changelog) and the work that was done.
>
> Statically defining package metadata is fine, but in this case you can't
> claim that you're generating the pkg.el file.

Oh yes it's generated using Cask following upstream practice.  I just
include it as a patch as we don't use Cask for Debian packaging.

> Either make the changelog and patch description consistent with what
> is actually happening, or change the implementation so that something
> is actually generated (there are multiple approaches here).  I think I
> tend to use makefile substvars for this.

Personally I prefer not to patch upstream source if not necessary,
otherwise we end up carrying the patch for the foreseeable future.
Though arguably in this case the scala-mode-pkg.el file needs to be
generated/patched which requires I use Cask locally, so it's more or
less the same effort.

And then I just realized: why not just host the scala-mode-pkg.el file
and substitute the version so that we don't need to update it manually
on each update?  This is now implemented at [1].

> Do you see what will happen when the package is updated to
> 1.1.1 or newer?  Also, why did you choose to set the version to "0.23"
> rather than "1.1.0"?

Well I didn't choose it (if I did I'd use 1.1.0 :) This is the version
specified in scala-mode.el[2].

> Did you verify that elpa package version is consistent with the
> upstream version of the Debian package in bin:elpa-scala-mode that is
> consumed by users (the binary package)?
>

I tried install it from stable.melpa.org and yeah it's being
installed as scala-mode-0.23 even if it's registered as version 1.1.0
there[3].  So it's consistent in a sense :P

Anyway, I have just made a pull request to update this upstream[4] so
hopefully the versioning will be sane.

* Modernize d/watch using special substitute strings.
>>>
>>> Ok, but why?
>>>
>>
>> I believe this provides a more robust way of detecting tags and should
>> be an encouraged practices.  From my own experience, when I find a
>> d/watch file that doesn't work I may search for other packages to learn
>> from existing practices, and some may not work well as different
>> upstream may follow different conventions.  The substitute strings use a
>> more robust and tested regexp that works most of the time, and promoting
>> its use may save people's time instead of working on an ad-hoc regexp.
>
> Sounds good!  This is the kind of rationale that should be in the
> changelog, so please add it there :) From now on, read your changelog
> and patche desriptions, and imagine I'm asking you "ok, but why" for
> each point.  Yes, rarely something is self-evident and/or an
> implementation detail, but most of the time you should say a few words
> explaining "why"--particularly when you want to find a sponsor quickly.
> My expectation is that you get better at this with each review, and that
> you will apply everything you learned to all pending sponsorship
> requests in addition to future ones.
>

Ack, and good suggestion!  I have slightly extended the entry with the
rationale[5].  PTAL.

* Add more metadata in d/upstream/metadata.
>>>
>>> https://github.com/hvesalai/emacs-scala-mode/commits/master
>>>
>>> is a git history log, not a changelog nor release notes.
>>>
>>
>> I thought the git history log may be considered an alternative form of a
>> Changelog.  Looks like I was 

Bug#1055645: orphan-sysvinit-scripts: Please take over mdadm init script

[Lorenzo]

Control: tags -1 patch

Hello Matthew,

attached is a git patch that adds mdadm and mdadm-waitidle
scripts.

On Thu, 9 Nov 2023 16:09:22 +0100
Stephan Seitz  wrote:

> [...]

>   * Removing cron jobs in favour of systemd timers:
> - daily checks also work if system is not always on (Closes:
> #889978).
I thought that anacron could handle this..

> 
> Even the cronjob is gone.

sorry, the patch does not include cronjob since o-s-s does not have
a way to handle it.
By the way I don't remember a project consensus for dropping
cronjobs in favour of timers..

Best Regards,
Lorenzo

From e5179d055f6958638b0319bba25562b3e6b77f5e Mon Sep 17 00:00:00 2001
From: Lorenzo Puliti 
Date: Fri, 1 Dec 2023 02:19:27 +0100
Subject: [PATCH] Add mdadm and mdadm-waitidle scripts

Add scripts dropped from mdadm 4.2+20230227-1 on 28 Feb 2023
---
 debian/copyright   |   8 +++
 lib/mapping|   2 +
 scripts/mdadm  | 100 +
 scripts/mdadm-waitidle |  60 
 scripts/mdadm-waitidle.md5sums |   1 +
 scripts/mdadm.md5sums  |   1 +
 6 files changed, 172 insertions(+)
 create mode 100755 scripts/mdadm
 create mode 100755 scripts/mdadm-waitidle
 create mode 100644 scripts/mdadm-waitidle.md5sums
 create mode 100644 scripts/mdadm.md5sums

diff --git a/debian/copyright b/debian/copyright
index 905292d..6746261 100644
--- a/debian/copyright
+++ b/debian/copyright
@@ -37,6 +37,14 @@ Copyright: 1997-2002, Remco Treffkorn
 License: BSD-3-clause
 Comment: Salsa debian-gps-team/pkg-gpsd 026301b71
 
+Files: scripts/mdadm*
+Copyright: 2001-2005 Mario Jou/3en 
+2005-2008 Martin F. Krafft 
+2018 Dimitri John Ledkov 
+2019  Felix Lechner  
+License: GPL-2+
+Comment: Salsa debian/mdadm 140efd48
+
 Files: scripts/network-manager
 Copyright: 2004 - 2016 Red Hat, Inc.
2005 - 2009 Novell, Inc.
diff --git a/lib/mapping b/lib/mapping
index c1b867d..c0cf8cb 100644
--- a/lib/mapping
+++ b/lib/mapping
@@ -9,6 +9,8 @@ dirsrv.service dirsrv
 dnscrypt-proxy.service dnscrypt-proxy
 firewalld.service firewalld
 gpsd.service gpsd
+mdadm-waitidle.service  mdadm-waitidle
+mdadm.service  mdadm
 nftables.service nftables
 pdns.service pdns
 rsyslog.service rsyslog
diff --git a/scripts/mdadm b/scripts/mdadm
new file mode 100755
index 000..0a9004f
--- /dev/null
+++ b/scripts/mdadm
@@ -0,0 +1,100 @@
+#!/bin/sh
+#
+# Start the MD monitor daemon for all active MD arrays if desired.
+# This script is not used under systemd.
+#
+# Copyright © 2001-2005 Mario Jou/3en 
+# Copyright © 2005-2009 Martin F. Krafft 
+# Distributable under the terms of the GNU GPL version 2.
+#
+### BEGIN INIT INFO
+# Provides:  mdadm
+# Required-Start:$local_fs $syslog
+# Required-Stop: $local_fs $syslog sendsigs 
+# Default-Start: 2 3 4 5
+# Default-Stop:  0 1 6
+# Short-Description: MD monitoring daemon
+# Description:   mdadm provides a monitor mode, in which it will scan for
+#problems with the MD devices. If a problem is found, the
+#administrator is alerted via email, or a custom script is
+#run.
+### END INIT INFO
+#
+set -eu
+
+MDADM=/sbin/mdadm
+MDMON=/sbin/mdmon
+RUNDIR=/run/mdadm
+PIDFILE=$RUNDIR/monitor.pid
+DEBIANCONFIG=/etc/default/mdadm
+
+test -x "$MDADM" || exit 0
+
+test -f /proc/mdstat || exit 0
+
+START_DAEMON=true
+test -f $DEBIANCONFIG && . $DEBIANCONFIG
+
+. /lib/lsb/init-functions
+
+is_true()
+{
+  case "${1:-}" in
+[Yy]es|[Yy]|1|[Tt]|[Tt]rue) return 0;;
+*) return 1;
+  esac
+}
+
+case "${1:-}" in
+  start)
+if [ -x /usr/bin/systemd-detect-virt ] && /usr/bin/systemd-detect-virt --quiet --container; then
+  log_daemon_msg "Not starting MD monitoring service in container"
+  log_end_msg 0
+  exit 0
+fi
+
+if is_true $START_DAEMON; then
+  log_daemon_msg "Starting MD monitoring service" "mdadm --monitor"
+  mkdir -p $RUNDIR
+  set +e
+  start-stop-daemon -S -p $PIDFILE -x $MDADM -- \
+--monitor --pid-file $PIDFILE --daemonise --scan ${DAEMON_OPTIONS:-}
+  log_end_msg $?
+  set -e
+fi
+if [ "$(echo $RUNDIR/md[0-9]*.pid)" != "$RUNDIR/md[0-9]*.pid" ]; then
+  log_daemon_msg "Restarting MD external metadata monitor" "mdmon --takeover --all"
+  set +e
+  $MDMON --takeover --all
+  log_end_msg $?
+  set -e
+fi
+;;
+  stop)
+if [ -f $PIDFILE ] ; then
+  log_daemon_msg "Stopping MD monitoring service" "mdadm --monitor"
+  set +e
+  start-stop-daemon -K -p $PIDFILE -x $MDADM
+  rm -f $PIDFILE
+  log_end_msg $?
+  set -e
+fi
+for file in $RUNDIR/md[0-9]*.pid ; do
+  [ ! -f "$file" ] && continue
+  ln -sf $file /run/sendsigs.omit.d/mdmon-${file##*/}
+done
+;;
+  status)
+status_of_proc -p $PIDFILE "$MDADM" "mdadm" && exit 0 || exit $?
+;;
+  restart|reload|force-reload)
+${0:-} 

Bug#1057175: transition: libsfml

[James Cowgill]

Package: release.debian.org
Control: affects -1 + src:libsfml
X-Debbugs-Cc: libs...@packages.debian.org
User: release.debian@packages.debian.org
Usertags: transition
Severity: normal

Hi,

libsfml needs a transition due to an ABI bump from 2.5 to 2.6. It's
currently in experimental and built everywhere except mips64el where
it's waiting to be built.

The rdeps are:

casparcg-server (in contrib)
dolphin-emu
extremetuxracer
libcsfml
marsshooter
python-sfml
seriousproton

I did a test rebuild against 2.6 and everything builds on amd64 except
for seriousproton which already FTBFS for other reasons and is not in
testing.

The auto-libsfml tracker looks correct to me.

Thanks,
James

Ben file:

title = "libsfml";
is_affected = .depends ~ "libsfml-audio2.5" | .depends ~ "libsfml-graphics2.5" 
| .depends ~ "libsfml-network2.5" | .depends ~ "libsfml-system2.5" | .depends ~ 
"libsfml-window2.5" | .depends ~ "libsfml-audio2.6" | .depends ~ 
"libsfml-graphics2.6" | .depends ~ "libsfml-network2.6" | .depends ~ 
"libsfml-system2.6" | .depends ~ "libsfml-window2.6";
is_good = .depends ~ "libsfml-audio2.6" | .depends ~ "libsfml-graphics2.6" | 
.depends ~ "libsfml-network2.6" | .depends ~ "libsfml-system2.6" | .depends ~ 
"libsfml-window2.6";
is_bad = .depends ~ "libsfml-audio2.5" | .depends ~ "libsfml-graphics2.5" | 
.depends ~ "libsfml-network2.5" | .depends ~ "libsfml-system2.5" | .depends ~ 
"libsfml-window2.5";

Bug#1054100: bullseye-pu: package iotop-c/1.23-1

[Boian Bonev]

On Wed, 2023-11-29 at 22:17 +, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On Tue, 2023-10-17 at 02:03 +, Boian Bonev wrote:
> > [ Reason ]
> > This update fixes 3 bugs in iotop-c:
> > - the program will busy loop after pressing ESC key, eating 100% on
> > one core
> > - pseudo graphs in ASCII mode display incorrect/garbage values
> > - the logic behind showing only IO active processes incorrectly hides
> > active ones
> 
> Please go ahead.

Uploaded, thanks!

With best regards,
b.

Bug#902498: gtk2-engines-cleanice: Should this package be removed?

[Boyuan Yang]

X-Debbugs-CC: stanislav.maslov...@gmail.com un...@debian.org

If there is no objection, I plan to convert this bug report to removal
request 28 days later (after Dec 28, 2023).

Thanks,
Boyuan Yang

On Wed, 27 Jun 2018 11:31:29 +0100 Simon McVittie  wrote:
> Source: gtk2-engines-cleanice
> Severity: normal
> User: debian...@lists.debian.org
> Usertags: proposed-removal
> 
> GTK+-2-only themes do not seem particularly useful now that the only
> supported web browsers in Debian (Firefox and Chromium) have switched
> to GTK+ 3, making it impractical to run a Debian desktop system without
> GTK+ 3.
> 
> (See also  and
> .)
> 
> This theme hasn't had an upstream release since 2007 and hasn't had
> activity in Debian since 2010, so it seems highly unlikely that it will
> be updated for GTK+ 3. Should it be removed from Debian?
> 
> If so, please reassign this bug to the archive administrators with
> control commands similar to these:
> 
> Control: severity xx normal
> Control: reassign xx ftp.debian.org
> Control: retitle xx RM: gtk2-engines-cleanice -- RoQA; obsolete, doesn't
support gtk3
> 
> (Replace RoQA with RoM if you are the maintainer.)
> 
> Conversely, if you think this package should remain in Debian, please
> close this bug. This would likely involve becoming its de facto upstream
> maintainer.
> 
> dak does not find any dependencies that would be broken by removing this.



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

Bug#1057174: python3-diagrams: depends on no longer available python3-typed-ast

[Andreas Beckmann]

Package: python3-diagrams
Version: 0.23.4-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package is no longer
installable in sid:

  The following packages have unmet dependencies:
   python3-diagrams : Depends: python3-typed-ast but it is not installable

python3-typed-ast has recently disappeared from sid:

https://bugs.debian.org/1051802


Cheers,

Andreas

Bug#983852: python-scrapy: please make the build reproducible

[Vagrant Cascadian]

On 2021-03-02, Chris Lamb wrote:
> Whilst working on the Reproducible Builds effort [0] we noticed that
> python-scrapy could not be built reproducibly.
>
> This is because it uses the current build year when building the
> documentation which, of course, changes depending which year you
> build the software.
>
> Patch attached that uses SOURCE_DATE_EPOCH [1] instead.

In the upstream pull request:

  https://github.com/scrapy/scrapy/pull/5019

It was suggested drop the practice of using the build year at all and
manually updating the year... though upstream did not go so far as to
actually do that as far as I can tell.

Perhaps a really simple patch with the most recent copyright year
hard-coded that needs to be updated alongside debian/copyright would be
acceptible? It could also check to make sure the most recent year
mentioned in debian/copyright matches the patch year, if you really
wanted to make sure they stayed in sync.

Alternately, going with the SOURCE_DATE_EPOCH patch for now until
upstream decides how to fix it?


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1057173: RM: claws-mail-gdata-plugin -- RoQA; NBS; gdata-plugin: dropped from release

[Andreas Beckmann]

Package: ftp.debian.org
Severity: normal

Please remove the cruft binary package claws-mail-gdata-plugin.

claws-mail  | 4.1.1-4   | unstable   | source
claws-mail  | 4.2.0-1   | unstable   | source, amd64, 
arm64, armel, armhf, i386, mips64el, ppc64el, riscv64, s390x
*** claws-mail-gdata-plugin | 4.1.1-4+b1| unstable   | amd64, arm64, armel, 
armhf, i386, mips64el, ppc64el, riscv64, s390x ***

claws-mail (4.2.0-1) unstable; urgency=medium

  * New upstream version 4.2.0
  * Remove the gdata-plugin: dropped from release
  ...

 -- Ricardo Mones   Wed, 22 Nov 2023 23:58:37 +0100


Andreas

Bug#1053246: Security support ended for Xen 4.14 in Bullseye

[Maximilian Engelhardt]

On Montag, 2. Oktober 2023 19:18:49 CET Santiago Ruano Rincón wrote:
> El 30/09/23 a las 00:09, Hans van Kranenburg escribió:
> > Package: debian-security-support
> > Version: 1:11+2023.05.04
> > Severity: normal
> > 
> > Hi,
> > 
> > Upstream security support for Xen 4.14 has ended recently. This also
> > means that security support for Debian Bullseye has ended.
> > 
> > The complexity of the software involved does not really allow for anyone
> > else than the upstream developers, with a deep understanding of the
> > inner workings of the hypervisor code, to apply/backport new patches.
> > 
> > For security-support-ended.deb11, this could be a line like:
> > 
> > xen 4.14.6-1 2023-09-21
> > https://xenbits.xen.org/docs/4.14-testing/SUPPORT.html#release-support
> > 
> > Note: This 4.14.6-1 package version is not visible for bullseye yet,
> > right now, in the archive. It was submitted for the bullseye point
> > release, and has just been accepted into it:
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1053177
> > 
> > Thanks,
> > Hans
> 
> Hello,
> 
> Could you please wait a little bit before moving forward. In the Debian
> bullseye LTS context, we would like to know if there are interest from
> LTS users, and look for help to maintain it. At least, partially.
> 
> Thank you,
> 
>  -- Santiago

Hi Santiago,

Any update on this?
As upstream security support for xen 4.14 has ended, the Debian xen team 
doesn't have the knowledge and resources to provide further security support.
So if there are people with the resources and knowledge to further provide 
security support for xen in bullseye it would be good to know this is 
happening.
But if not, it would also be good to inform our users that there is no longer 
security support for xen in bullseye.

Thanks,
Maxi


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

Bug#568601: [Pkg-netatalk-devel] Bug#568601: Can confirm this problem still exists

[Daniel Markstedt]

Hi Matijs,

This is not something we can address in the netatalk package itself, since 
you're using an Unstable netatalk package with a Stable Debian version. 
(Netatalk was dropped from Debian 12 Bookworm.)

See this upstream discussion for more details: 
https://github.com/Netatalk/netatalk/discussions/574


Best regards,
Daniel

On Thursday, November 30th, 2023 at 11:05 PM, Matijs van Zuijlen 
 wrote:


> 
> 
> Dear maintainer,
> 
> This problem still exists. I installed netatalk from testing on a Debian
> server running stable, and libgcrypt was not updated at the same time
> because the dependency in the netatalk package specifies '>= 1.10.0',
> 
> which matches the stable version 1.10.1, while testing's netatalk
> actually needs libgcrypt 1.10.2. This lead to a flood of errors in the
> logs. Updating the libgcrypt package to the testing version (1.10.2)
> fixed that problem.
> 
> As far as I can tell, the solution would be for the netatalk package to
> depend on (at least?) the libgcrypt version it was compiled with.
> 
> --
> Kind regards,
> Matijs van Zuijlen
> 
> --
> pkg-netatalk-devel mailing list
> pkg-netatalk-de...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-netatalk-devel

Bug#990862: infinipath-psm: reproducible builds: Embedded timestamps in libpsm_infinipath.so

[Vagrant Cascadian]

On 2021-07-09, Vagrant Cascadian wrote:
> From 88b66063c5f02ba48f2fc9cfa2ae6cc42c950cc8 Mon Sep 17 00:00:00 2001
> From: Vagrant Cascadian 
> Date: Fri, 9 Jul 2021 15:13:24 +
> Subject: [PATCH] Use the build date from SOURCE_DATE_EPOCH if set, falling
>  back to current time.
>
> https://reproducible-builds.org/docs/source-date-epoch/
> ---
>  Makefile   | 2 +-
>  buildflags.mak | 8 
>  ipath/Makefile | 2 +-
>  3 files changed, 10 insertions(+), 2 deletions(-)

I would like to propose an NMU with this patch applied in the near
future. Please let me know if there are objections.

live well,
  vagrant

> diff --git a/Makefile b/Makefile
> index d79c4bd..64d6f6b 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -270,7 +270,7 @@ ${TARGLIB}.so.${MAJOR}: ${TARGLIB}.so.${MAJOR}.${MINOR}
>  # file around.  Generate it such that the ident command can find it
>  # and strings -a | grep InfiniPath does a reasonable job as well.
>  ${TARGLIB}.so.${MAJOR}.${MINOR}: ${${TARGLIB}-objs}
> - date +'char psmi_infinipath_revision[] ="$$""Date: %F %R 
> ${rpm_extra_description}InfiniPath $$";' > ${lib_build_dir}/_revision.c
> + printf 'char psmi_infinipath_revision[] ="$$""Date: %s 
> ${rpm_extra_description} InfiniPath $$";\n' "$(BUILD_DATE)" > 
> ${lib_build_dir}/_revision.c
>   $(CC) -c $(BASECFLAGS) $(INCLUDES) _revision.c -o _revision.o
>   $(CC) $(LDFLAGS) -o $@ -Wl,-soname=${TARGLIB}.so.${MAJOR} -shared 
> -Wl,--unique='*fastpath*' \
>   ${${TARGLIB}-objs} _revision.o -L$(build_dir)/ipath $(LDLIBS)
> diff --git a/buildflags.mak b/buildflags.mak
> index 34fdf1c..be40c40 100644
> --- a/buildflags.mak
> +++ b/buildflags.mak
> @@ -96,3 +96,11 @@ endif
>  CFLAGS += $(BASECFLAGS) $(if $(filter $(CC),gcc),-Wno-strict-aliasing) \
>   $(if $(PSM_VALGRIND:0=),-DPSM_VALGRIND,-DNVALGRIND)
>  
> +# Use SOURCE_DATE_EPOCH for build date, falling back to current time
> +# https://reproducible-builds.org/docs/source-date-epoch/
> +DATE_FMT="+'%F %R'"
> +ifdef SOURCE_DATE_EPOCH
> +BUILD_DATE ?= $(shell date -u -d "@$(SOURCE_DATE_EPOCH)" "$(DATE_FMT)" 
> 2>/dev/null || date -u -r "$(SOURCE_DATE_EPOCH)" "$(DATE_FMT)" 2>/dev/null || 
> date -u "$(DATE_FMT)")
> +else
> +BUILD_DATE ?= $(shell date "$(DATE_FMT)")
> +endif
> diff --git a/ipath/Makefile b/ipath/Makefile
> index 8c2cc6e..e627b3d 100644
> --- a/ipath/Makefile
> +++ b/ipath/Makefile
> @@ -70,7 +70,7 @@ ${TARGLIB}.so.${MAJOR}: ${TARGLIB}.so.${MAJOR}.${MINOR}
>  # file around.  Generate it such that the ident command can find it
>  # and strings -a | grep InfiniPath does a reasonable job as well.
>  ${TARGLIB}.so.${MAJOR}.${MINOR}: ${${TARGLIB}-objs}
> - date +'static __attribute__ ((unused)) char __psc_infinipath_revision[] 
> ="$$""Date: %F %R ${rpm_extra_description}InfiniPath $$";' > _revision.c
> + printf 'static __attribute__ ((unused)) char 
> __psc_infinipath_revision[] ="$$""Date: %s ${rpm_extra_description}InfiniPath 
> $$";\n' "$(BUILD_DATE)" > _revision.c
>   $(CC) -c $(BASECFLAGS) $(INCLUDES) _revision.c -o _revision.o
>   $(CC) -o $@ -Wl,-soname=${TARGLIB}.so.${MAJOR} -shared \
>   -Wl,--unique='*fastpath*' \
> -- 
> 2.32.0


signature.asc
Description: PGP signature

Bug#1057172: baloo-kf5: Baloo Service Crashes After Enabling 'Index File Contents' Option

[Lucy]

Package: baloo-kf5
Version: 5.103.0-2
Severity: important
X-Debbugs-Cc: luc...@diplomats.com

Dear Maintainer,


Description:
Enabling the 'Index file contents' option in the Baloo service leads to
sporadic crashes.

Steps to Reproduce:

Access the Baloo settings.
Enable the 'Index file contents' option.

Observed Behavior:
After enabling the 'Index file contents' option, the Baloo service crashes
sporadically. The crash doesn't follow a consistent pattern and occurs
unpredictably. Below, I've included the debug information from DrKonqi for
further analysis.

Additional Information:
The system utilizes the BtrFS and XFS file systems. This information is
provided in case the choice of file systems might be relevant to the issue.

Expected Behavior:
Enabling the 'Index file contents' option should not cause the Baloo 
service to

crash. The service should function reliably and conduct the indexing of file
contents as intended.

Operating System: Debian GNU/Linux 12
KDE Plasma Version: 5.27.5
KDE Frameworks Version: 5.103.0
Qt Version: 5.15.8
Kernel Version: 6.1.0-13-amd64 (64-bit)
Graphics Platform: X11

-- System Information:
Debian Release: 12.2
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'proposed-updates'), (500, 'stable')

Architecture: amd64 (x86_64)

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

Versions of packages baloo-kf5 depends on:
ii init-system-helpers 1.65.2
ii kio 5.103.0-1
ii libc6 2.36-9+deb12u3
ii libkf5baloo5 5.103.0-2
ii libkf5balooengine5 5.103.0-2
ii libkf5configcore5 5.103.0-2
ii libkf5coreaddons5 5.103.0-1
ii libkf5crash5 5.103.0-1
ii libkf5dbusaddons5 5.103.0-1
ii libkf5filemetadata3 5.103.0-1
ii libkf5i18n5 5.103.0-1
ii libkf5idletime5 5.103.0-2
ii libkf5kiocore5 5.103.0-1
ii libkf5solid5 5.103.0-1
ii libqt5core5a 5.15.8+dfsg-11
ii libqt5dbus5 5.15.8+dfsg-11
ii libqt5gui5 5.15.8+dfsg-11
ii libqt5qml5 5.15.8+dfsg-3
ii libstdc++6 12.2.0-14

baloo-kf5 recommends no packages.

baloo-kf5 suggests no packages.

-- no debconf information

*** /home/lucy/baloo_file_crash.log
Application: baloo_file (baloo_file), signal: Segmentation fault

PID: 1876 (baloo_file)
UID: 1000 (lucy)
GID: 1000 (lucy)
Signal: 11 (SEGV)
Timestamp: Thu 2023-11-16 02:38:07 CET (2h 31min ago)
Command Line: /usr/lib/x86_64-linux-gnu/libexec/baloo_file
Executable: /usr/lib/x86_64-linux-gnu/libexec/baloo_file
Control Group: 
/user.slice/user-1000.slice/user@1000.service/background.slice/kde-baloo.service

Unit: user@1000.service
User Unit: kde-baloo.service
Slice: user-1000.slice
Owner UID: 1000 (lucy)
Boot ID: 9ca02c462c58460ebbfbac59d59a9cc3
Machine ID: 6db60355bc8e4fccb5a531dd67bc08d4
Hostname: june
Storage: 
/var/lib/systemd/coredump/core.baloo_file.1000.9ca02c462c58460ebbfbac59d59a9cc3.1876.170009868700.zst 
(present)

Size on Disk: 9.0M
Message: Process 1876 (baloo_file) of user 1000 dumped core.

Module libsystemd.so.0 from deb systemd-252.17-1~deb12u1.amd64
Module libudev.so.1 from deb systemd-252.17-1~deb12u1.amd64
Stack trace of thread 1876:
#0 0x7fbe9c2a9d3c __pthread_kill_implementation (libc.so.6 + 0x8ad3c)
#1 0x7fbe9c25af32 __GI_raise (libc.so.6 + 0x3bf32)
#2 0x7fbe9cfabb46 _ZN6KCrash19defaultCrashHandlerEi 
(libKF5Crash.so.5 + 0x5b46)

#3 0x7fbe9c25afd0 __restore_rt (libc.so.6 + 0x3bfd0)
#4 0x557d83358770 n/a (baloo_file + 0x13770)
#5 0x557d8335885d n/a (baloo_file + 0x1385d)
#6 0x557d83365bf1 n/a (baloo_file + 0x20bf1)
#7 0x7fbe9cadd6f0 _ZN7QObject5eventEP6QEvent (libQt5Core.so.5 + 
0x2dd6f0)
#8 0x7fbe9cab16cd 
_ZN16QCoreApplication15notifyInternal2EP7QObjectP6QEvent 
(libQt5Core.so.5 + 0x2b16cd)
#9 0x7fbe9cab4681 
_ZN23QCoreApplicationPrivate16sendPostedEventsEP7QObjectiP11QThreadData 
(libQt5Core.so.5 + 0x2b4681)

#10 0x7fbe9cb0a153 n/a (libQt5Core.so.5 + 0x30a153)
#11 0x7fbe9b11e7a9 g_main_context_dispatch (libglib-2.0.so.0 + 0x547a9)
#12 0x7fbe9b11ea38 n/a (libglib-2.0.so.0 + 0x54a38)
#13 0x7fbe9b11eacc g_main_context_iteration (libglib-2.0.so.0 + 0x54acc)
#14 0x7fbe9cb09836 
_ZN20QEventDispatcherGlib13processEventsE6QFlagsIN10QEventLoop17ProcessEventsFlagEE 
(libQt5Core.so.5 + 0x309836)
#15 0x7fbe9cab017b 
_ZN10QEventLoop4execE6QFlagsINS_17ProcessEventsFlagEE (libQt5Core.so.5 + 
0x2b017b)
#16 0x7fbe9cab82d6 _ZN16QCoreApplication4execEv (libQt5Core.so.5 + 
0x2b82d6)

#17 0x557d83353982 n/a (baloo_file + 0xe982)
#18 0x7fbe9c2461ca __libc_start_call_main (libc.so.6 + 0x271ca)
#19 0x7fbe9c246285 __libc_start_main_impl (libc.so.6 + 0x27285)
#20 0x557d83353b61 n/a (baloo_file + 0xeb61)

Stack trace of thread 3227:
#0 0x7fbe9c31b05f __GI___poll (libc.so.6 + 0xfc05f)
#1 0x7fbe9cfab150 n/a (libKF5Crash.so.5 + 

Bug#751341: Acknowledgement (debian/control missing VCS tags)

[Vagrant Cascadian]

Control: tags 751341 - patch

On 2014-06-11, Hans-Christoph Steiner wrote:
> diff --git a/debian/control b/debian/control
> index 60be58a..11c718a 100644
> --- a/debian/control
> +++ b/debian/control
> @@ -4,6 +4,8 @@ Priority: optional
>  Maintainer: Bastian Blank 
>  Build-Depends: debhelper (>> 7), libdebian-installer4-dev (>= 0.81~), 
> libdebconfclient0-dev (>= 0.40), autotools-dev, libbz2-dev, liblzma-dev, 
> zlib1g-dev
>  Standards-Version: 3.9.0
> +Vcs-Git: git://git.debian.org/users/waldi/cdebootstrap.git
> +Vcs-Browser: http://anonscm.debian.org/gitweb/?p=users/waldi/cdebootstrap.git
>  
>  Package: cdebootstrap
>  Architecture: any

While cdeboostrap still lacks Vcs-* headers, git.debian.org and
anonscm.debian.org no longer exist in the nine or so years that this bug
has gone unresolved... the patch no longer contains relevent
information. :(

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1056897: [3dprinter-general] Bug#1056897: FTBFS: Plater.cpp:5313: error: call of overloaded ‘load_files?=()=?UTF-8?Q?’ is ambiguous

[Aaron Rainbolt]

On 11/30/23 16:34, Gregor Riepl wrote:

Hi Aaron,

Simon is uploading the new packaging to the DELAYED/1 queue. It 
should arrive in the archive on November 30.


If you are a maintainer of slic3r-prusa, you can review the new 
packaging in the mean time and reject or fast-track it as you see fit.


Thanks a lot for this!
The NMU is building right now.

Unfortunately, it looks like a new issue cropped up that curiously 
didn't happen to me during testing: [1]


./tests/arrange/test_arrange.cpp:935: FAILED:
  REQUIRE_THAT( score, WithinRel(0., EPSILON) )
with expansion:
  -0.0 and 0 are within 0.01% of each other

Sounds like the EPSILON value is not appropriate for this test, or 
WithinRel has problems with negative zero (or near-zero).


Gah, looks like some arch-dependent glitch. Which explains why it didn't 
happen to either of us (we probably both used amd64 machines, I 
definitely did) and then the failure did happen upon publishing.


Thanks for your help, I'll try to help get the next fix in once it's ready.



I'll investigate this issue as soon as I can.

Regards,
Gregor

[1] 
https://buildd.debian.org/status/fetch.php?pkg=slic3r-prusa=arm64=2.6.1%2Bdfsg-4.1=1701382946=0



--
Aaron Rainbolt
Lubuntu Developer
Matrix: @arraybolt3:matrix.org
IRC: arraybolt3 on irc.libera.chat
GitHub: https://github.com/ArrayBolt3

Bug#1056897: [3dprinter-general] Bug#1056897: FTBFS: Plater.cpp:5313: error: call of overloaded ‘load_files?=()=?UTF-8?Q?’ is ambiguous

[Gregor Riepl]

Hi Aaron,

Simon is uploading the new packaging to the DELAYED/1 queue. It should 
arrive in the archive on November 30.


If you are a maintainer of slic3r-prusa, you can review the new 
packaging in the mean time and reject or fast-track it as you see fit.


Thanks a lot for this!
The NMU is building right now.

Unfortunately, it looks like a new issue cropped up that curiously 
didn't happen to me during testing: [1]


./tests/arrange/test_arrange.cpp:935: FAILED:
  REQUIRE_THAT( score, WithinRel(0., EPSILON) )
with expansion:
  -0.0 and 0 are within 0.01% of each other

Sounds like the EPSILON value is not appropriate for this test, or 
WithinRel has problems with negative zero (or near-zero).


I'll investigate this issue as soon as I can.

Regards,
Gregor

[1] 
https://buildd.debian.org/status/fetch.php?pkg=slic3r-prusa=arm64=2.6.1%2Bdfsg-4.1=1701382946=0

Bug#1052277: Bumping severity to serious

[Luca Boccassi]

Control: severity -1 serious

Hi,

As requested by Helmut, bumping severity of these bugs to important.
systemd.pc has just now been changed to point to
/usr/lib/systemd/system for the unit installation directory and the
affected packages will start to FTBFS.

-- 
Kind regards,
Luca Boccassi


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

Bug#1057171: libitext5-java: FTBFS with bouncycastle 1.77

[Markus Koschany]

Source: libitext5-java
Version: 5.5.13.3-2
Severity: serious
Tags: ftbfs sid
User: a...@debian.org
Usertags: bouncycastle-1.77
X-Debbugs-Cc: a...@debian.org

Dear maintainer,

libitext5-java fails to build from source with bouncycastle 1.77. The reason
is the removal of long deprecated methods. The (hopefully) relevant
error message from the build log.

BUILD FAILURE
[INFO] 
[INFO] Total time:  12.832 s
[INFO] Finished at: 2023-11-30T13:27:49+01:00
[INFO] 
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-
plugin:3.10.1:compile (default-compile) on project itextpdf: Compilation
failure: Compilation failure: 
[ERROR]
/<>/itext/src/main/java/com/itextpdf/text/pdf/security/PdfPKCS7.ja
va:[223,95] cannot find symbol
[ERROR]   symbol:   method getObject()
[ERROR]   location: class org.bouncycastle.asn1.ASN1TaggedObject
[ERROR]
/<>/itext/src/main/java/com/itextpdf/text/pdf/security/PdfPKCS7.ja
va:[246,109] cannot find symbol
[ERROR]   symbol:   method getObject()
[ERROR]   location: class org.bouncycastle.asn1.ASN1TaggedObject
[ERROR]
/<>/itext/src/main/java/com/itextpdf/text/pdf/security/PdfPKCS7.ja
va:[346,70] cannot find symbol
[ERROR]   symbol:   method getObject()
[ERROR]   location: variable tg of type org.bouncycastle.asn1.ASN1TaggedObject
[ERROR]
/<>/itext/src/main/java/com/itextpdf/text/pdf/security/PdfPKCS7.ja
va:[350,70] cannot find symbol
[ERROR]   symbol:   method getObject()
[ERROR]   location: variable tg of type org.bouncycastle.asn1.ASN1TaggedObject
[ERROR]
/<>/itext/src/main/java/com/itextpdf/text/pdf/security/PdfPKCS7.ja
va:[1286,28] cannot find symbol
[ERROR]   symbol:   method getObject()
[ERROR]   location: variable tag of type org.bouncycastle.asn1.ASN1TaggedObject
[ERROR]
/<>/itext/src/main/java/com/itextpdf/text/pdf/security/PdfPKCS7.ja
va:[1287,48] cannot find symbol
[ERROR]   symbol:   method getObject()
[ERROR]   location: variable tag of type org.bouncycastle.asn1.ASN1TaggedObject
[ERROR]
/<>/itext/src/main/java/com/itextpdf/text/pdf/security/Certificate
Util.java:[123,67] incompatible types: org.bouncycastle.asn1.ASN1IA5String
cannot be converted to org.bouncycastle.asn1.DERIA5String
[ERROR] -> [Help 1]
[ERROR] 


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

Bug#1057170: ssl-utils-clojure: FTBFS with bouncycastle 1.77

[Markus Koschany]

Source: ssl-utils-clojure
Version: 3.5.0-2
Severity: serious
Tags: ftbfs sid
User: a...@debian.org
Usertags: bouncycastle-1.77
X-Debbugs-Cc: a...@debian.org

Dear maintainer,

ssl-utils-clojure fails to build from source with bouncycastle 1.77. The reason
is the removal of long deprecated methods. The (hopefully) relevant
error message from the build log.


lein jar
Compiling 2 source files to /<>/target/classes
/<>/src/java/com/puppetlabs/ssl_utils/ExtensionsUtils.java:632:
error: cannot find symbol
return asn1ObjToObj(taggedObj.getObject());
 ^
  symbol:   method getObject()
  location: variable taggedObj of type ASN1TaggedObject
1 error
Compilation of Java sources(lein javac) failed.
make[1]: *** [debian/rules:19: override_dh_auto_build] Error 1
make[1]: Leaving directory '/<>'
make: *** [debian/rules:11: binary] Error 2
dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2
---
-



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

Bug#1041376: comskip: diff for NMU version 0.82.009+git20230112.d0cc422+ds.1-2.1

[Sebastian Ramacher]

Control: tags 1041376 + patch
Control: tags 1041376 + pending

Dear maintainer,

I've prepared an NMU for comskip (versioned as
0.82.009+git20230112.d0cc422+ds.1-2.1) and uploaded it to DELAYED/2.
Please feel free to tell me if I should delay it longer.

Cheers
-- 
Sebastian Ramacher
diff -Nru comskip-0.82.009+git20230112.d0cc422+ds.1/debian/changelog comskip-0.82.009+git20230112.d0cc422+ds.1/debian/changelog
--- comskip-0.82.009+git20230112.d0cc422+ds.1/debian/changelog	2023-01-13 11:35:18.0 +0100
+++ comskip-0.82.009+git20230112.d0cc422+ds.1/debian/changelog	2023-11-30 22:56:06.0 +0100
@@ -1,3 +1,10 @@
+comskip (0.82.009+git20230112.d0cc422+ds.1-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/patches: Fix build with ffmpeg 6 (Closes: #1041376)
+
+ -- Sebastian Ramacher   Thu, 30 Nov 2023 22:56:06 +0100
+
 comskip (0.82.009+git20230112.d0cc422+ds.1-2) unstable; urgency=medium
 
   [ Debian Janitor ]
diff -Nru comskip-0.82.009+git20230112.d0cc422+ds.1/debian/patches/ffmpeg-6.patch comskip-0.82.009+git20230112.d0cc422+ds.1/debian/patches/ffmpeg-6.patch
--- comskip-0.82.009+git20230112.d0cc422+ds.1/debian/patches/ffmpeg-6.patch	1970-01-01 01:00:00.0 +0100
+++ comskip-0.82.009+git20230112.d0cc422+ds.1/debian/patches/ffmpeg-6.patch	2023-11-30 22:54:14.0 +0100
@@ -0,0 +1,18 @@
+--- a/comskip.h
 b/comskip.h
+@@ -8,3 +8,15 @@
+ 
+ #define MAXWIDTH	8000
+ #define MAXHEIGHT	4800
++
++#if defined(__INTEL_COMPILER) && __INTEL_COMPILER < 1110 || defined(__SUNPRO_C)
++#define DECLARE_ALIGNED(n,t,v)  t __attribute__ ((aligned (n))) v
++#elif defined(__DJGPP__)
++#define DECLARE_ALIGNED(n,t,v)  t __attribute__ ((aligned (FFMIN(n, 16 v
++#elif defined(__GNUC__) || defined(__clang__)
++#define DECLARE_ALIGNED(n,t,v)  t __attribute__ ((aligned (n))) v
++#elif defined(_MSC_VER)
++#define DECLARE_ALIGNED(n,t,v)  __declspec(align(n)) t v
++#else
++#define DECLARE_ALIGNED(n,t,v)  t v
++#endif
diff -Nru comskip-0.82.009+git20230112.d0cc422+ds.1/debian/patches/series comskip-0.82.009+git20230112.d0cc422+ds.1/debian/patches/series
--- comskip-0.82.009+git20230112.d0cc422+ds.1/debian/patches/series	1970-01-01 01:00:00.0 +0100
+++ comskip-0.82.009+git20230112.d0cc422+ds.1/debian/patches/series	2023-11-30 22:52:13.0 +0100
@@ -0,0 +1 @@
+ffmpeg-6.patch

Bug#1057169: pdftk-java: FTBFS with bouncycastle 1.77

[Markus Koschany]

Source: pdftk-java
Version: 3.3.3-1
Severity: serious
Tags: ftbfs sid
User: a...@debian.org
Usertags: bouncycastle-1.77
X-Debbugs-Cc: a...@debian.org

Dear maintainer,

pdftk-java fails to build from source with bouncycastle 1.77. The reason
is the removal of long deprecated methods. The (hopefully) relevant
error message from the build log.

[javac]
/<>/java/com/gitlab/pdftk_java/com/lowagie/text/pdf/PdfPKCS7.java:
228: error: cannot find symbol
[javac] ASN1Sequence content =
(ASN1Sequence)((DERTaggedObject)signedData.getObjectAt(1)).getObject();
[javac]   
^
[javac]   symbol:   method getObject()
[javac]   location: class DERTaggedObject
[javac]
/<>/java/com/gitlab/pdftk_java/com/lowagie/text/pdf/PdfPKCS7.java:
261: error: cannot find symbol
[javac] DEROctetString rsaDataContent =
(DEROctetString)((DERTaggedObject)rsaData.getObjectAt(1)).getObject();
[javac]   
^
[javac]   symbol:   method getObject()
[javac]   location: class DERTaggedObject
[javac]
/<>/java/com/gitlab/pdftk_java/com/lowagie/text/pdf/PdfPKCS7.java:
297: error: cannot find symbol
[javac] ASN1Sequence sseq = (ASN1Sequence)tagsig.getObject();
[javac] ^
[javac]   symbol:   method getObject()
[javac]   location: variable tagsig of type ASN1TaggedObject
[javac] /<>/java/com/gitlab/pdftk_


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

Bug#1057168: jdeb: FTBFS with bouncycastle 1.77

[Markus Koschany]

Source: jdeb
Version: 1.9-1
Severity: serious
Tags: ftbfs sid
User: a...@debian.org
Usertags: bouncycastle-1.77
X-Debbugs-Cc: a...@debian.org

Dear maintainer,

jdeb fails to build from source with bouncycastle 1.77. The reason
is the removal of long deprecated methods. The (hopefully) relevant
error message from the build log.

ERROR] Failures: 
[ERROR]   PGPSignerTestCase.testClearSign:79->Assert.assertEquals:146-
>Assert.assertEquals:117 expected:<...[]
-END PGP SIGNAT...> but was:<...[Sek]
-END PGP SIGNAT...>
[INFO] 
[ERROR] Tests run: 90, Failures: 1, Errors: 0, Skipped: 0
[INFO] 
[INFO] 
[INFO] BUILD FAILURE
[INFO] 
[INFO] Total time:  14.039 s
[INFO] Finished at: 2023-11-30T13:32:26+01:00
[INFO] 
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-surefire-
plugin:2.22.3:test (default-test) on project jdeb: There are test failures.
[ERROR] 
[ERROR] Please refer to /<>/target/surefire-reports for the
individual test results.
[ERROR] Please refer to dump files (if any exist) [date].dump, [date]-
jvmRun[N].dump and [date].dumpstream.
[ERROR] -> [Help 1]
[ERROR] 
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e
switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR] 
[ERROR] For more information about the errors and possible solutions, please
read the following articles:
[ERROR] [Help 1]
http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException
dh_auto_test: error: /usr/lib/jvm/default-java/bin/java -noverify -cp
/usr/share/maven/boot/plexus-classworlds-2.x.jar -Dmaven.home=/usr/share/maven
-Dmaven.multiModuleProjectDirectory=/<> -
Dclassworlds.conf=/etc/maven/m2-debian.conf -
Dproperties.file.manual=/<>/debian/maven.properties
org.codehaus.plexus.classworlds.launcher.Launcher -s/etc/maven/settings-
debian.xml -Ddebian.dir=/<>/debian -
Dmaven.repo.local=/<>/debian/maven-repo --batch-mode test returned
exit code 1
make: *** [debian/rules:6: build] Error 25
dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2


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

Bug#1057167: libapache-poi-java: FTBFS with bouncycastle 1.77

[Markus Koschany]

Source: libapache-poi-java
Version: 4.0.1-4
Severity: serious
Tags: ftbfs sid
User: a...@debian.org
Usertags: bouncycastle-1.77
X-Debbugs-Cc: a...@debian.org

Dear maintainer,

libapache-poi-java fails to build from source with bouncycastle 1.77. The
reason is the removal of long deprecated methods. The (hopefully) relevant
error message from the build log.

ompile-ooxml:
[javac] Compiling 589 source files to /<>/build/ooxml-classes
[javac] Ignoring source, target and bootclasspath as release has been set
[javac]
/<>/src/ooxml/java/org/apache/poi/poifs/crypt/dsig/facets/XAdESXLS
ignatureFacet.java:235: error: cannot find symbol
[javac] ASN1OctetString keyHashOctetString =
(ASN1OctetString)derTaggedObject.getObject();
[javac]   
^
[javac]   symbol:   method getObject()
[javac]   location: variable derTaggedObject of type DERTaggedObject
[javac]
/<>/src/ooxml/java/org/apache/poi/poifs/crypt/dsig/facets/XAdESXLS
ignatureFacet.java:239: error: cannot find symbol
[javac] X500Name name =
X500Name.getInstance(derTaggedObject.getObject());
[javac]   
^
[javac]   symbol:   method getObject()
[javac]   location: variable derTaggedObject of type DERTaggedObject
[javac] Note: Some input files use or override a deprecated API.
[javac] Note: Recompile with -Xlint:deprecation for details.
[javac] Note:
/<>/src/ooxml/java/org/apache/poi/poifs/crypt/dsig/SignaturePart.j
ava uses unchecked or unsafe operations.
[javac] Note: Recompile with -Xlint:unchecked for details.
[javac] 2 errors

BUILD FAILED
/<>/build.xml:1133: Compile failed; see the compiler error output
for details.



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

Bug#1057166: pgpainless: FTBFS with bouncycastle 1.77

[Markus Koschany]

Source: pgpainless
Version: 1.3.16-2
Severity: serious
Tags: ftbfs sid
User: a...@debian.org
Usertags: bouncycastle-1.77
X-Debbugs-Cc: a...@debian.org

Dear maintainer,

pgpainless fails to build from source with bouncycastle 1.77. The reason
is the removal of long deprecated methods. The (hopefully) relevant
error message from the build log. It seems, in this case, just a test is
failing now.

Failures (1):
  JUnit Jupiter:CertifyCertificateTest:testKeyDelegation()
MethodSource [className =
'org.pgpainless.key.certification.CertifyCertificateTest', methodName =
'testKeyDelegation', methodParameterTypes = '']
=> org.pgpainless.exception.SignatureValidationException: Cannot verify
direct-key signature correctness
  
org.pgpainless.signature.consumer.SignatureValidator$17.verify(SignatureValidat
or.java:547)
  
org.pgpainless.signature.consumer.SignatureVerifier.verifyDirectKeySignature(Si
gnatureVerifier.java:328)
  
org.pgpainless.key.certification.CertifyCertificateTest.testKeyDelegation(Certi
fyCertificateTest.java:98)
   java.base/java.lang.reflect.Method.invoke(Method.java:568)
   java.base/java.util.ArrayList.forEach(ArrayList.java:1511)
   [...]
 Caused by: org.bouncycastle.openpgp.PGPException: signature is not a key
binding signature.
   org.bouncycastle.openpgp.PGPSignature.verifyCertification(Unknown
Source)
  
org.pgpainless.signature.consumer.SignatureValidator$17.verify(SignatureValidat
or.java:539)
   [...]

Test run finished after 44748 ms
[   240 containers found  ]
[ 0 containers skipped]
[   240 containers started]
[ 0 containers aborted]
[   240 containers successful ]
[ 0 containers failed ]
[   732 tests found   ]
[ 1 tests skipped ]
[   731 tests started ]
[ 0 tests aborted ]
[   730 tests successful  ]
[ 1 tests failed  ]





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

Bug#1057165: libitext-java: FTBFS with bouncycastle 1.77

[Markus Koschany]

Source: libitext-java
Version: 2.1.7-14
Severity: serious
Tags: ftbfs sid
User: a...@debian.org
Usertags: bouncycastle-1.77
X-Debbugs-Cc: a...@debian.org

Dear maintainer,

libitext-java fails to build from source with bouncycastle 1.77. The reason
is the removal of long deprecated methods. The (hopefully) relevant
error message from the build log.



compile:
[mkdir] Created dir: /<>/build/bin
[javac] /<>/ant/compile.xml:45: warning: 'includeantruntime'
was not set, defaulting to build.sysclasspath=last; set to false for repeatable
builds
[javac] Using javac -source 1.5 is no longer supported, switching to 7
[javac] Using javac -target 1.5 is no longer supported, switching to 7
[javac] Compiling 359 source files to /<>/build/bin
[javac] warning: [options] bootstrap class path not set in conjunction with
-source 7
[javac] warning: [options] source value 7 is obsolete and will be removed
in a future release
[javac] warning: [options] target value 7 is obsolete and will be removed
in a future release
[javac] warning: [options] To suppress warnings about obsolete options, use
-Xlint:-options.
[javac]
/<>/core/com/lowagie/text/pdf/MappedRandomAccessFile.java:58:
warning: [removal] AccessController in java.security has been deprecated and
marked for removal
[javac] import java.security.AccessController;
[javac] ^
[javac] /<>/core/com/lowagie/text/pdf/PdfPKCS7.java:356:
error: cannot find symbol
[javac] if (tag.getObject() instanceof ASN1Sequence) {
[javac]^
[javac]   symbol:   method getObject()
[javac]   location: variable tag of type ASN1TaggedObject
[javac] /<>/core/com/lowagie/text/pdf/PdfPKCS7.java:357:
error: cannot find symbol
[javac] seq = (ASN1Sequence)tag.getObject();
[javac]^
[javac]   symbol:   method getObject()
[javac]   location: variable tag of type ASN1TaggedObject
[javac] /<>/core/com/lowagie/text/pdf/PdfPKCS7.java:403:
error: cannot find symbol
[javac] ASN1Sequence content =
(ASN1Sequence)((DERTaggedObject)signedData.getObjectAt(1)).getObject();
[javac]   
^
[javac]   symbol:   method getObject()
[javac]   location: class DERTaggedObject
[javac] /<>/core/com/lowagie/text/pdf/PdfPKCS7.java:435:
error: cannot find symbol
[javac] DEROctetString rsaDataContent =
(DEROctetString)((DERTaggedObject)rsaData.getObjectAt(1)).getObject();
[javac]   
^
[javac]   symbol:   method getObject()
[javac]   location: class DERTaggedObject
[javac] /<>/core/com/lowagie/text/pdf/PdfPKCS7.java:488:
error: cannot find symbol
[javac] ASN1Sequence seqin =
(ASN1Sequence)tg.getObject();
[javac]  ^
[javac]   symbol:   method getObject()
[javac]   location: variable tg of type ASN1TaggedObject
[javac] /<>/core/com/lowagie/text/pdf/FontDetails.java:264:
warning: [removal] Integer(int) in Integer has been deprecated and marked for
removal
[javac] Integer codeKey = new Integer(code);
[javac]   ^
[javac]
/<>/core/com/lowagie/text/pdf/TrueTypeFontUnicode.java:144:
warning: [removal] Integer(int) in Integer has been deprecated and marked for
removal
[javac] inverseCmap.put(new
Integer(metrics[0]), code);
[javac] ^
[javac]
/<>/core/com/lowagie/text/pdf/TrueTypeFontUnicode.java:150:
warning: [removal] Integer(int) in Integer has been deprecated and marked for
removal
[javac] return inverseCmap == null ? null : (Integer)
inverseCmap.get(new Integer(code));
[javac] 
 
^
[javac]
/<>/core/com/lowagie/text/pdf/MappedRandomAccessFile.java:203:
warning: [removal] AccessController in java.security has been deprecated and
marked for removal
[javac] Boolean b = (Boolean) AccessController.doPrivileged(new
PrivilegedAction() {
[javac]   ^
[javac] Note: Some input files use or override a deprecated API.
[javac] Note: Recompile with -Xlint:deprecation for details.
[javac] Note: Some input files use unchecked or unsafe operations.
[javac] Note: Recompile with -Xlint:unchecked for details.
[javac] 5 errors
[javac] 9 warnings


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

Bug#1057164: python-aiohttp: CVE-2023-49082

[Salvatore Bonaccorso]

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

Hi,

The following vulnerability was published for python-aiohttp.

CVE-2023-49082[0]:
| aiohttp is an asynchronous HTTP client/server framework for asyncio
| and Python. Improper validation makes it possible for an attacker to
| modify the HTTP request (e.g. insert a new header) or even create a
| new HTTP request if the attacker controls the HTTP method. The
| vulnerability occurs only if the attacker can control the HTTP
| method (GET, POST etc.) of the request. If the attacker can control
| the HTTP version of the request it will be able to modify the
| request (request smuggling). This issue has been patched in version
| 3.9.0.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-49082
https://www.cve.org/CVERecord?id=CVE-2023-49082
[1] https://github.com/aio-libs/aiohttp/security/advisories/GHSA-qvrw-v9rv-5rjx
[2] 
https://github.com/aio-libs/aiohttp/commit/4075c653fb67a29740bf9ac050bb02d10a57343a

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1057162: jglobus: FTBFS with bouncycastle 1.77

[Markus Koschany]

Source: jglobus
Version: 2.1.0-8.1
Severity: serious
Tags: ftbfs sid
User: a...@debian.org
Usertags: bouncycastle-1.77
X-Debbugs-Cc: a...@debian.org

Dear maintainer,

jglobus fails to build from source with bouncycastle 1.77. The reason
is the removal of long deprecated methods. The (hopefully) relevant
error message from the build log.

[ERROR] COMPILATION ERROR :
[INFO] -
[ERROR] 
/<>/ssl-proxies/src/main/java/org/globus/gsi/proxy/ext/ProxyPolicy.java:[63,46]
 cannot find symbol
  symbol:   method getObject()
  location: class org.bouncycastle.asn1.DERTaggedObject
[INFO] 1 error

Bug#1057163: python-aiohttp: CVE-2023-49081

[Salvatore Bonaccorso]

Source: python-aiohttp
Version: 3.8.6-1
Severity: important
Tags: security upstream
Forwarded: https://github.com/aio-libs/aiohttp/pull/7835
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for python-aiohttp.

CVE-2023-49081[0]:
| aiohttp is an asynchronous HTTP client/server framework for asyncio
| and Python. Improper validation made it possible for an attacker to
| modify the HTTP request (e.g. to insert a new header) or create a
| new HTTP request if the attacker controls the HTTP version. The
| vulnerability only occurs if the attacker can control the HTTP
| version of the request. This issue has been patched in version
| 3.9.0.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-49081
https://www.cve.org/CVERecord?id=CVE-2023-49081
[1] https://github.com/aio-libs/aiohttp/security/advisories/GHSA-q3qx-c6g2-7pw2
[2] https://github.com/aio-libs/aiohttp/pull/7835
[3] 
https://github.com/aio-libs/aiohttp/commit/53476dfd4ef4fb1bb74a267714bbc39eda71b403
 

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1057161: RM: blender [s390x mips64el] -- RoQA; no longer supported on s390x, mips64el

[Sebastian Ramacher]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: blen...@packages.debian.org, sramac...@debian.org
Control: affects -1 + src:blender

blender no longer builds on s390x and mips64el. Please remove the
binaries built by blender on these architectures.

Cheers
-- 
Sebastian Ramacher

Bug#1053686: pandoc: cannot fulfill the build dependencies

[Scott Talbert]

On Sun, 26 Nov 2023, Scott Talbert wrote:


On Sat, 25 Nov 2023, Jonas Smedegaard wrote:


Quoting Scott Talbert (2023-11-25 19:09:39)

On Thu, 23 Nov 2023, Jonas Smedegaard wrote:


Quoting Ilias Tsitsimpis (2023-11-23 21:10:36)

On Fri, Nov 17, 2023 at 09:28AM, Ilias Tsitsimpis wrote:

On Thu, Nov 16, 2023 at 10:16PM, Jonas Smedegaard wrote:

Quoting John MacFarlane (2023-11-16 19:25:17)
Removing lua support would be most unfortunate!  If you need help 
from upstream in getting things to work, let me know.


I agree: Pandoc with its core scripting language disabled is a 
severely

crippled Pandoc.


Understood, but I am not really sure how to move forward, since 
Pandoc

doesn't fully support the latest Stackage LTS. I can help with
packaging/upgrade libraries if you can provide the right set of
libraries we need.


I uploaded the following packages:

* haskell-hslua-cli_v1.3.0-1,
* haskell-hslua-module-doclayout_v1.1.0-1
* haskell-hslua-module-zip_v1.1.0-1

I believe the next step is to update pandoc to 3.0.1, so we can then
package pandoc-lua-engine, pandoc-server and eventually pandoc-cli.

Jonas, how can I help move this forward? Pandoc is the last blocker 
to

finish the Haskell transition.


I think this will be the best way forward:

Haskell team introduces new source package haskell-pandoc.

When available, I can build package pandoc depending on it.

I really don't like breaking upstream project pandoc into two Debian
source packages like that, but I don't have the energy at the moment 
to
try fix dh-haskell (which I suspect will be similar work as I am 
doing

to dh-cargo currently).


I'm working on this (packaging haskell-pandoc).


And it's been uploaded, headed to NEW.


Jonas,

haskell-pandoc has been accepted into unstable, so I think you should be 
able to update src:pandoc to now build from the pandoc-cli hackage 
package.


This brings up an interesting question, though.  The pandoc-cli package 
versioning does not follow that of the pandoc package, so it's unclear how 
to best handle that with the existing numbering of src:pandoc and pandoc 
binary package.


Regards,
Scott

Bug#1057160: libgvnc-1.0-0: Scrolling performance severely degraded between 1.0.0-1 and 1.3.1-1

[Jon F]

Package: libgvnc-1.0-0
Version: 1.3.1-1
Severity: important
X-Debbugs-Cc: jon.ore...@gmail.com


I recently upgraded my Debian install from Bullseye to Bookworm and with that
came a newer libgvnc (1.3 instead of 1.0). The upgrade caused Vinagre to be
basically useless for what I'm doing (viewing a fullscreen java application)
 - the application basically consists of a big table and scrolling is now
insanely slow. It scrolls a little bit, then quickly gets slower and slower
until it stops completely, taking more than 10 seconds to recover. I have
done it while checking both htop and iftop and it's not caused by CPU or
bandwidth saturation. If I force Vinagre to use the older libgvnc
(using LD_LIBRARY_PATH), it works exactly as it used to. So that's what I
have resorted to for now.

libgvnc which works: 1.0.0 (Debian version 1.0.0-1)
libgvnc which does not work: 1.3.1 (Debian version 1.3.1-1)


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

Kernel: Linux 6.1.0-12-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=sv_SE.UTF-8, LC_CTYPE=sv_SE.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 libgvnc-1.0-0 depends on:
ii  libc62.36-9+deb12u1
ii  libgcrypt20  1.10.1-3
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-1+b1
ii  libglib2.0-0 2.74.6-2
ii  libgnutls30  3.7.9-2
ii  libpulse016.1+dfsg1-2+b1
ii  libsasl2-2   2.1.28+dfsg-10
ii  zlib1g   1:1.2.13.dfsg-1

libgvnc-1.0-0 recommends no packages.

libgvnc-1.0-0 suggests no packages.

-- no debconf information

Bug#1057151: clang-17: ClangTargets.cmake cannot find libclang-17.so.1

[Gianfranco Costamagna]

control: severity -1 serious

Hello, I can reproduce, something regressed between 17.0.5 and 17.0.6...

And I pushed a test to make sure we spot this in advance next time.

G.

On Thu, 30 Nov 2023 12:13:21 -0700 Cordell Bloor  wrote:

Package: clang-17
Version: 1:17.0.6-1
Severity: normal
X-Debbugs-Cc: c...@slerp.xyz, debian...@lists.debian.org

Dear Maintainer,

While attempting to update rocm-device-libs, I noticed that searching
for clang with find_package(Clang) will fail with an error. The
ClangTargets.cmake file expects libclang to be found at the path
"/usr/lib/llvm-17/lib/libclang-17.so.1", but the file is actually
installed to "/usr/lib/x86_64-linux-gnu/libclang-17.so.1".

The error encountred is:

```
CMake Error at /usr/lib/llvm-17/lib/cmake/clang/ClangTargets.cmake:833 
(message):
  The imported target "libclang" references the file

 "/usr/lib/llvm-17/lib/libclang-17.so.1"

  but this file does not exist.  Possible reasons include:

  * The file was deleted, renamed, or moved to another location.

  * An install or uninstall procedure did not complete successfully.

  * The installation package was faulty and contained

 "/usr/lib/llvm-17/lib/cmake/clang/ClangTargets.cmake"

  but not all the files it references.
```

The error can be reproduced with this minimal CMakeLists.txt:

```
cmake_minimum_required(VERSION 3.22)
project(example)
find_package(Clang)
```

Regards,
Cordell Bloor

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

Kernel: Linux 6.5.0-4-amd64 (SMP w/32 CPU threads; PREEMPT)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Versions of packages clang-17 depends on:
ii  binutils2.41-7
ii  libc6   2.37-12
ii  libc6-dev   2.37-12


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1056223: abydos autopkg tests fail with Python 3.12

[Julian Gilbey]

On Thu, Nov 30, 2023 at 04:53:23PM +0800, Shengjing Zhu wrote:
> X-Debbugs-CC: j...@debian.org
> Control: tags -1 patch
> [...]
> 
> More tests need to use assertAlmostEqual to compare floating numbers.
> Please see the merge request
> 
> https://salsa.debian.org/python-team/packages/abydos/-/merge_requests/1

Thanks Shengjing - that sounds perfect!  I'll take a look in detail
soon.

Best wishes,

   Julian

Bug#1057158: gnome-characters: Update for Unicode 15.1

[Jeremy Bícha]

Source: gnome-characters
Version: 43.1-1
Severity: important
Tags: bookworm

Annually, the Unicode Consortium releases a new Unicode standard with new emoji.

The default color emoji font in Debian GNOME 12 is
fonts-noto-color-emoji which is being updated to 2.042 to include
support for Unicode 15.1.

The GNOME Characters app should be updated to display the new emoji
from Unicode 15.1

Thank you,
Jeremy Bícha

Bug#1057157: bookworm-pu: package spyder/5.4.2+ds-5+deb12u1

[Julian Gilbey]

Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: spy...@packages.debian.org, Samuel Thibault 
Control: affects -1 + src:spyder

[ Reason ]
This is a patch for
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1054475

This bug prevents auto-detection of the environment language (using
the Python locale.getdefaultlocale() function) when Spyder is first
run.  After that, Spyder saves the language and uses that saved value
for future use; this setting can be changed in the Spyder preferences.
The upstream patch fixes the error that caused this bug by updating
the list of available translations.

The Debian bug was filed as "normal" severity.  It should probably be
"important", but I have not changed the severity.  (It is definitely
not more that "important", as the language can still be changed by the
user after Spyder has started in English.)  The reporter specifically
suggested that this should be fixed in stable, and with such a simple
patch, I tend to agree.

The patch I have used is the complete upstream patch, minus a minor
tweak to some function documentation.  This is a little larger than
the proposed patch in the Debian bug report, but it protects against
any other oversight in the list of translations.

[ Impact ]
When starting Spyder for the first time in a non-English locale, the
interface will be in English rather than the locale language, even if
a translation for that locale is provided by Spyder.

[ Tests ]
It appears that there are no tests for this piece of code (hence why
this bug was not caught automatically).  The package's autopkgtest
suite still passes, and the updated package has been manually tested
on a bookworm system to ensure that it no longer has this bug.

[ Risks ]
There seem to be few risks with this minor patch.

[ 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 ]
See the patch: it fixes the list of available translations and no
longer defaults to English if the list of translations is out of
date.

[ Other info ]
I have not yet uploaded the new version to ftp-master.d.o; I await
your approval before doing so.
diff -Nru spyder-5.4.2+ds/debian/changelog spyder-5.4.2+ds/debian/changelog
--- spyder-5.4.2+ds/debian/changelog2023-02-23 10:59:49.0 +
+++ spyder-5.4.2+ds/debian/changelog2023-11-30 20:22:17.0 +
@@ -1,3 +1,9 @@
+spyder (5.4.2+ds-5+deb12u1) stable; urgency=medium
+
+  * Fix interface language auto-configuration (closes: #1054475)
+
+ -- Julian Gilbey   Thu, 30 Nov 2023 20:22:17 +
+
 spyder (5.4.2+ds-5) unstable; urgency=medium
 
   * Fix translation-loading patch (see discussion at
diff -Nru spyder-5.4.2+ds/debian/patches/enable-i18n.patch 
spyder-5.4.2+ds/debian/patches/enable-i18n.patch
--- spyder-5.4.2+ds/debian/patches/enable-i18n.patch1970-01-01 
01:00:00.0 +0100
+++ spyder-5.4.2+ds/debian/patches/enable-i18n.patch2023-11-30 
20:22:17.0 +
@@ -0,0 +1,76 @@
+From: Carlos Cordoba 
+Date: Thu, 26 Oct 2023 13:52:55 -0500
+Subject: [PATCH] Backport PR #21451: Fix interface language auto-configuration
+Description:
+  Commit 7d99df57dc977ee00d92c959102409be1683df24
+  This bug prevented auto-configuration of the interface language when
+  Spyder is started for the first time.  (After that, the interface language
+  is stored in the preferences file and can be changed via the preferences
+  dialog.)
+  A minor cosmetic fix to the function documentation has been removed from
+  this patch.
+Last-Update: 2023-11-30
+Origin: upstream, https://github.com/spyder-ide/spyder/pull/21461
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1054475
+
+--- a/spyder/config/base.py
 b/spyder/config/base.py
+@@ -366,20 +366,24 @@
+ # This needs to be updated every time a new language is added to spyder, and 
is
+ # used by the Preferences configuration to populate the Language QComboBox
+ LANGUAGE_CODES = {
+-'en': u'English',
+-'fr': u'Français',
+-'es': u'Español',
+-'hu': u'Magyar',
+-'pt_BR': u'Português',
+-'ru': u'Русский',
+-'zh_CN': u'简体中文',
+-'ja': u'日本語',
+-'de': u'Deutsch',
+-'pl': u'Polski'
++'en': 'English',
++'fr': 'Français',
++'es': 'Español',
++'hu': 'Magyar',
++'pt_BR': 'Português',
++'ru': 'Русский',
++'zh_CN': '简体中文',
++'ja': '日本語',
++'de': 'Deutsch',
++'pl': 'Polski',
++'fa': 'Persian',
++'hr': 'Croatian',
++'te': 'Telugu',
++'uk': 'Ukrainian',
+ }
+ 
+ # Disabled languages because their translations are outdated or incomplete
+-DISABLED_LANGUAGES = ['hu', 'pl']
++DISABLED_LANGUAGES = ['fa', 'hr', 'hu', 'pl', 'te', 'uk']
+ 
+ 
+ def get_available_translations():
+@@ -400,14 +404,19 @@
+ 
+ # Check that there is a language code 

Bug#1055431: RFS: scala-mode-el/1:1.1.0+git20221025.5d7cf21-1 [RC] [Team] -- Emacs major mode for editing scala source code

[Nicholas D Steeves]

Xiyue Deng  writes:

> Nicholas D Steeves  writes:
>
>
>> Have you asked upstream to tag a release?
>>
>
> Not before your review but done by now at [1]

Thank you.  You may have heard that Debian is a distribution that
privileges the stable release model...  When the human maintainer of a
Debian package tracks stable releases, why is importing a snapshot
justified?

Also, do you use this package?

>>>* Override clean rules in d/rules to fix building. (Closes:
>>>#1052917)
>>
>> I believe you already know that
>>
>> override_dh_auto_clean:
>>/bin/true
>>
>> is an incorrect approach.
>>
>
> Indeed it was not ideal.  Upstream depends on Cask to generated the
> scala-mode-pkg.el file that is used in the clean target to get the name
> of the generated tarball, and indeed using this lazy approach is
> incorrect.  I've now included the generated pkg file through a patch to
> make this work in [2].

Consistency is essential between an explanation (in a comment or
changelog) and the work that was done.

Statically defining package metadata is fine, but in this case you can't
claim that you're generating the pkg.el file.  Either make the changelog
and patch description consistent with what is actually happening, or
change the implementation so that something is actually generated (there
are multiple approaches here).  I think I tend to use makefile substvars
for this.  Do you see what will happen when the package is updated to
1.1.1 or newer?  Also, why did you choose to set the version to "0.23"
rather than "1.1.0"?  Did you verify that elpa package version is
consistent with the upstream version of the Debian package in
bin:elpa-scala-mode that is consumed by users (the binary package)?

>>>* Modernize d/watch using special substitute strings.
>>
>> Ok, but why?
>>
>
> I believe this provides a more robust way of detecting tags and should
> be an encouraged practices.  From my own experience, when I find a
> d/watch file that doesn't work I may search for other packages to learn
> from existing practices, and some may not work well as different
> upstream may follow different conventions.  The substitute strings use a
> more robust and tested regexp that works most of the time, and promoting
> its use may save people's time instead of working on an ad-hoc regexp.

Sounds good!  This is the kind of rationale that should be in the
changelog, so please add it there :) From now on, read your changelog
and patche desriptions, and imagine I'm asking you "ok, but why" for
each point.  Yes, rarely something is self-evident and/or an
implementation detail, but most of the time you should say a few words
explaining "why"--particularly when you want to find a sponsor quickly.
My expectation is that you get better at this with each review, and that
you will apply everything you learned to all pending sponsorship
requests in addition to future ones.

>>>* Add more metadata in d/upstream/metadata.
>>
>> https://github.com/hvesalai/emacs-scala-mode/commits/master
>>
>> is a git history log, not a changelog nor release notes.
>>
>
> I thought the git history log may be considered an alternative form of a
> Changelog.  Looks like I was wrong except for projects that requires the
> same format across changelog/git history/release notes.  I've dropped
> that line in [3].

Thank you.  Re: "projects that requires the same format across
changelog/git history/release notes": Changelogs, NEWS files, and
release notes are three (or arguably two) distinct types of
documentation that are also distinct from VCS history.  This isn't a
superficial formatting or style thing, because they have different
audiences and purposes.  I think that the kind of changelog that you're
probably thinking of it when upstream takes git's shortlog history, puts
it in a file, and edits it so that it makes sense.

>>>* Update year and Upstream-Contact and add myself in d/copyright.
>>
>> Why did you add yourself?
>> https://en.wikipedia.org/wiki/Threshold_of_originality
>>
>> I'm happy to support your claim, but you'll need to work for it in more
>> than a "sweat of the brow"/mechanical sense.
>>
>
> To be honest, the only reason I did this is to suppress the
> "update-debian-copyright" lintian warning which is actually
> experimental.  I believe what I did was in the same nature as Sławomir
> did in 2020 though admittedly not to the same extent, so I've reverted
> this part in [4].

Cool.  Yeah, lintian has these tags: error, warning, info, pedantic,
experimental.  Which ones do you think are suggestions, and which one[s]
require a mandatory fix?  Note that suggestions are occasionally highly
opinionated and conflict with team policy.  As ever, it's not sufficient
to simply react to lintian: ie "lintian made me do it!".

>>>* Use xz compression in d/gbp.conf.
>>
>> Why is this useful when it has been the default since gbp 0.9.15?
>>
>
> I'm pretty sure that if I don't add this "git deborig" will create the
> tarball 

Bug#1057122: initscripts has an undeclared file conflict on /usr/lib/udev/hwclock-set

[Mark Hindley]

Helmut,

Thanks for this

On Tue, Nov 28, 2023 at 10:27:41AM +0100, Helmut Grohne wrote:
> Package: initscripts
> Version: 3.08-3~bpo12+1
> Severity: serious
> User: debian...@lists.debian.org
> Usertags: fileconflict
> Control: affects -1 + util-linux
> Tags: bookworm
> 
> initscripts has an undeclared file conflict. This may result in an
> unpack error from dpkg.
> 
> The file /usr/lib/udev/hwclock-set is contained in the packages
>  * initscripts/3.08-3~bpo12+1 as present in bookworm-backports
>  * util-linux/2.36.1-8+deb11u1 as present in bullseye|bullseye-security

Are the suites and versions reported here really the problematic ones?

I agree there is a conflict, but I think it is between
initscripts/3.08-3~bpo12+1 in bookworm-backports and util-linux-extra/2.38.1-5
in bookworm.

My proposed fix is attached. It reverts the transition of the hwclock machinery
to initscripts, since this is still present in bookworm src:util-linux.

Or, have I misunderstood?

Best wishes,

Mark

diff --git a/debian/control b/debian/control
index 551b7abc..02bfe1b5 100644
--- a/debian/control
+++ b/debian/control
@@ -99,15 +99,12 @@ Multi-Arch: foreign
 Depends:
  sysvinit-utils (>= 3.05-1),
  sysv-rc | file-rc | openrc,
- util-linux-extra,
  ${misc:Depends},
 Recommends:
  e2fsprogs,
  psmisc,
 Breaks: udev (<<  254.3-1),
-   util-linux-extra (<< 2.39.2-2.1~)
 Replaces: udev (<<  254.3-1),
- util-linux-extra (<< 2.39.2-2.1~)
 Description: scripts for initializing and shutting down the system
  The scripts in this package initialize a standard Debian
  system at boot time and shut it down at halt or reboot time.
diff --git a/debian/initscripts.postinst b/debian/initscripts.postinst
index 0074f2a3..eb126710 100755
--- a/debian/initscripts.postinst
+++ b/debian/initscripts.postinst
@@ -42,7 +42,7 @@ INITSCRIPTS="mountkernfs.sh mount-configfs brightness 
hostname.sh mountdevsubfs.
checkroot-bootclean.sh checkfs.sh mountall.sh mountall-bootclean.sh \
mountnfs.sh mountnfs-bootclean.sh bootmisc.sh urandom halt reboot \
udev umountroot umountfs umountnfs.sh sendsigs killprocs single motd \
-   bootlogs rc.local rmnologin hwclock.sh"
+   bootlogs rc.local rmnologin"
 
 for F in $INITSCRIPTS; do
if [ -x /etc/init.d/$F ]; then
diff --git a/debian/initscripts.postrm b/debian/initscripts.postrm
index 25bbb932..e53672dc 100755
--- a/debian/initscripts.postrm
+++ b/debian/initscripts.postrm
@@ -9,7 +9,7 @@ INITSCRIPTS="mountkernfs.sh mount-configfs brightness 
hostname.sh mountdevsubfs.
checkroot-bootclean.sh checkfs.sh mountall.sh mountall-bootclean.sh \
mountnfs.sh mountnfs-bootclean.sh bootmisc.sh urandom halt reboot \
udev umountroot umountfs umountnfs.sh sendsigs killprocs single motd \
-   bootlogs rc.local rmnologin hwclock.sh"
+   bootlogs rc.local rmnologin"
 
 case "$1" in
   purge)
diff --git a/debian/src/initscripts/Makefile b/debian/src/initscripts/Makefile
index 5da80089..b13eafa3 100644
--- a/debian/src/initscripts/Makefile
+++ b/debian/src/initscripts/Makefile
@@ -34,9 +34,6 @@ install:
$(INSTALL) -d $(DESTDIR)$(sbindir)/.
$(INSTALL) sbin/fsck.nfs $(DESTDIR)$(sbindir)/fsck.nfs
 
-   $(INSTALL_DATA) -Dt $(DESTDIR)/usr/lib/udev/rules.d 
usr/lib/udev/rules.d/hwclock.rules
-   $(INSTALL) usr/lib/udev/hwclock-set $(DESTDIR)/usr/lib/udev/hwclock-set
-
$(INSTALL) -d $(DESTDIR)/usr/share/man/man8
$(INSTALL_DATA) man/fsck.nfs.8 \
$(DESTDIR)/usr/share/man/man8/fsck.nfs.8
diff --git a/debian/src/initscripts/etc/default/hwclock 
b/debian/src/initscripts/etc/default/hwclock
deleted file mode 100644
index 44b04312..
--- a/debian/src/initscripts/etc/default/hwclock
+++ /dev/null
@@ -1,2 +0,0 @@
-# Settings for the hwclock init script.
-# See hwclock(5) for supported settings.
diff --git a/debian/src/initscripts/etc/init.d/hwclock.sh 
b/debian/src/initscripts/etc/init.d/hwclock.sh
deleted file mode 100644
index a9872b64..
--- a/debian/src/initscripts/etc/init.d/hwclock.sh
+++ /dev/null
@@ -1,57 +0,0 @@
-#!/bin/sh
-
-### BEGIN INIT INFO
-# Provides:  hwclock
-# Required-Start:
-# Required-Stop: mountdevsubfs
-# Should-Stop:   umountfs
-# Default-Start: S
-# Default-Stop:  0 6
-# Short-Description: Save system clock to hardware on shutdown.
-### END INIT INFO
-
-# Note: this init script and related code is only useful if you
-# run a sysvinit system, without NTP synchronization.
-
-if [ -e /run/systemd/system ] ; then
-exit 0
-fi
-
-unset TZ
-
-hwclocksh()
-{
-HCTOSYS_DEVICE=rtc0
-[ ! -x /sbin/hwclock ] && return 0
-[ ! -r /etc/default/rcS ] || . /etc/default/rcS
-[ ! -r /etc/default/hwclock ] || . /etc/default/hwclock
-
-. /lib/lsb/init-functions
-verbose_log_action_msg() { [ "$VERBOSE" = no ] || log_action_msg "$@"; }
-
-case "$1" in
-start)
-# start is handled by /usr/lib/udev/rules.d/85-hwclock.rules.
-  

Bug#1057155: vonsh REJECT on amd64

[Adrian Bunk]

Source: vonsh
Version: 1.0-0.1
Severity: serious
X-Debbugs-Cc: b...@debian.org

Reason:
Version check failed:
Your upload included the binary package vonsh, version 1.0-0.1, for amd64,
however testing already has version 1.0+b1.
Uploads to unstable must have a higher version than present in testing.

REJECT

Bug#983138: ypserv: /bin/sh symlink triggers differences in pwupdate

[Vagrant Cascadian]

Control: retitle 983138 ypserv: /bin/sh symlink triggers differences in pwupdate

On 2022-08-05, Vagrant Cascadian wrote:
> On 2022-08-05, Vagrant Cascadian wrote:
>> On 2022-08-05, Francesco P. Lovergine wrote:
>>> On Sun, Jul 17, 2022 at 01:52:46PM +0100, Simon McVittie wrote:
On Fri, 19 Feb 2021 at 14:38:09 -0800, Vagrant Cascadian wrote:
> The configure script sets the BASH variable to /bin/sh when run on a
> usrmerge system, resulting in the pwupdate script differing between
> builds:
>
>   
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/ypserv.html
>
>   ./usr/lib/yp/pwupdate
>
>   #!/bin/bash
>   vs.
>   #!/bin/sh
...
Regardless of whether this is RC or not, it would be great to have it fixed
for Debian 12. Vagrant's patch looks appropriate.

Thanks,
smcv
>>>
>>> The patch looks good enough to fix the pwupdate generation. In any case, the
>>> script seems currently POSIX compliant, so using /bin/bash or /bin/sh looks 
>>> indifferent.
>>
>> Given that it's the BASH variable, I figured using /bin/bash would make
>> more sense and allow consistent builds.
...
> From some local testing, this doesn't actually appear to be a usrmerge
> issue, but a /bin/sh -> /bin/bash vs. /bin/sh -> /bin/dash issue.

Updated bug title accordingly.


> I'm not sure why the reproducible builds infrastructure doesn't catch
> this, will look into it...

Apparently we had some misconfiguration that did not catch this, but it
is fixed now, and ypserv is again showing as unreproducible due to this
issue:

  
https://tests.reproducible-builds.org/debian/rb-pkg/trixie/amd64/diffoscope-results/ypserv.html


> Regardless, the patch would make the package build reproducibly, and
> would be great to apply.

I would like to perform an NMU fixing this in the near future, barring
any strong objections.

Apparently either BASH=/bin/sh or BASH=/bin/bash work, though the
current shipped package uses /bin/bash in /usr/lib/yp/pwupdate, so my
proposed patch to pass BASH=/bin/bash would result in the same behavior
as currently in the archive.

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1056191: usrmerge: provide more documentation for Debian Developers and system administrators

[Otto Kekäläinen]

> > > > Thus a third thing the README could advise on is how Debian Developers 
> > > > and
> > > > Debian sysadmins are advised to build CI systems and test upgrade paths 
> > > > for
> > > > the next 10 years as what worked in the past 10 years does not apply 
> > > > as-is
> > > > anymore.
> > > People using CI systems will get an updated debootstrap in the next
> > > point release and everything will be fine.
> >
> > Do you refer above to the next Bookworm point update (scheduled on Dec
> > 9th according to https://release.debian.org/) or do you mean in
> > general that all CI upgrades tests will start working after the next
> > point release of both Bookworm and Bullseye and Buster?
> >
> > I am currently struggling to grasp how I should get for example
> > MariaDB 10.5 / Buster to MariaDB 10.11 / Bookworm testing running
> > again as usrmerge 38 removed the workaround the CI was relying on.
> > Example of current CI run:
> > https://salsa.debian.org/mariadb-team/mariadb-server/-/jobs/4945062.
> > Are you saying that a point release of Buster is going to do something
> > that CI systems can continue to operate?
>
> Just create the chroot for the CI with --merged-usr and all will be
> fine. Debootstrap in Buster is not going to be updated to do it
> automatically, only in Bookworm/Bullseye.

I have been reading https://wiki.debian.org/UsrMerge and the
changelogs of various debootstrap versions[1] but I still don't get
this.

All the changelogs contain this version 1.0.102 referenced at
https://wiki.debian.org/UsrMerge. Why would debootstrap support
--merged-usr only Bookworm and Bullseye?

Isn't deboostrap new enough on all past versions[2] due to past point
upgrades? What is the commit/package you are referring to about 'next
point update'?

debootstrap (1.0.102) unstable; urgency=medium

  * Enable merged-/usr by default (Closes: #839046)
This is applied for buster and later.
  * Fix "debootstrap doesn't carry --components across --foreign/--second-stage"
(Closes: #877855)
  * Fix debian-common path with tarball and --second-stage (Closes: #897379)

 -- Hideki Yamane   Wed, 13 Jun 2018 22:00:11 +0900


[1]
https://tracker.debian.org/media/packages/d/debootstrap/changelog-1.0.133
https://tracker.debian.org/media/packages/d/debootstrap/changelog-1.0.128nmu2deb12u1
https://tracker.debian.org/media/packages/d/debootstrap/changelog-1.0.123deb11u1
https://tracker.debian.org/media/packages/d/debootstrap/changelog-1.0.114deb10u1

[2] 
https://packages.debian.org/search?keywords=debootstrap=names=all=all

Bug#1057154: pandoc: Disable Lua support on ppc* architectures

[Ilias Tsitsimpis]

Package: pandoc
Version: 2.17.1.1-3
Severity: normal

Hi Jonas,

As discussed on this [1] mail-thread on debian-haskell, GHC has a bug on
ppc* architectures [2], and we cannot build HsLua on these
architectures.

As a workaround, I propose we disable Pandoc's Lua scripting engine on
ppc* architectures. I believe Fedora has done the same [3].

[1] 
https://lists.debian.org/msgid-search/20231129074313.52gunbau7od3a...@iliastsi.net
[2] https://gitlab.haskell.org/ghc/ghc/-/issues/23034
[3] https://bugzilla.redhat.com/show_bug.cgi?id=2172771#c14

Best,

-- 
Ilias

Bug#1057153: freewheeling: please provide a debian/watch file

[Alexandre Detiste]

Source: freewheeling
Version: please add a debian/watch file
Severity: minor

A debian/watch file would reduce the manual
polling to see wether a new SDL2-compatible
version is available.

Greetings


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

Kernel: Linux 6.5.0-4-amd64 (SMP w/2 CPU threads; PREEMPT)
Kernel taint flags: TAINT_USER
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_BE:fr
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Bug#1038076: ocamlsdl: Is a language binding for an obsolete version of SDL

[Alexandre Detiste]

freetennis has been removed
& liquidsoap is being handled not to build with SDL anymore,
thus raising bug severity to autoremove this package from Trixie

Bug#636342: release.debian.org: provide a dd-list in the transition tracker

[Yves-Alexis Perez]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Thu, 2023-11-30 at 17:06 +0100, Sebastiaan Couwenberg wrote:
> The attached script can be used to generate a dd-list from the URL to 
> the transition tracker.
> 
> Kind Regards,
> 
> 
Hi Bas, I have to admit I was surprised to see a reply to my bug submission
from more than 12 years ago. But thanks, I guess?

Regards,
- -- 
Yves-Alexis
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmVo4X8ACgkQ3rYcyPpX
RFsXMAf/WrUsLPQw958f9kNcn9D/1yXc/ekH3d+Hi9CpJxNKLWVuqIX1UDHvredQ
yaMrYW4nlFP+/9LAgip8IlbC0rrTCQG0cQrQWouJ5NOpMciTFqnDzCP7HeqBH+l5
/acC3qEn8T6jhApHsaxp+p7J4/YL2l+aHZLFAcH79ZYFcaCaWsHEMm7DmLTRWU6s
YIhsq9iTXRobKJ+xEuCGz05/yz+mfn/kVVJBgYn7HCPjGxiYGvjHkdY4wzjyFadi
Yh+T2TF7kw14sMHvO9twFRtIscXo0mtHnjLhgZzWuRoB8bflKxxDdBscgxcx0w8Y
sd/B6wvV43AptRr31bzetMc8j5kMfg==
=nC7I
-END PGP SIGNATURE-

Bug#1056966: autorandr: Delegate udev rules install location to udev.pc

[Don Armstrong]

On Mon, 27 Nov 2023, Chris Hofstaedtler wrote:
> thanks for applying the patches from #1054477. I have now noticed that
> autorandr hard-codes the udev rules directory to /lib/udev/rules.d.
> I'm attaching a patch which delegates the path decision to udev.pc,
> merely by removing the argument to make.
> 
> In the near future udev.pc will change the path to
> /usr/lib/udev(/rules.d), and then your package can pick this up in a
> binNMU without further changes.


Thanks for the patch, I'll apply it shortly and upload it the next time
I do an upload (or when the udev rules change happens, whatever is
earlier).

-- 
Don Armstrong  https://www.donarmstrong.com

Science is a way of trying not to fool yourself. The first principle
is that you must not fool yourself, and you are the easiest person to
fool.
 -- Richard Feynman "What is and What Should be the Role of Scientific
Culture in Modern Society"; 1964

Bug#1057152: RFP: sacad -- Smart Automatic Cover Art Downloader

[Antoine Beaupre]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: debian-pyt...@lists.debian.org

* Package name: sacad
  Version : 2.7.5
  Upstream Contact: https://github.com/desbma
* URL : https://github.com/desbma/sacad/
* License : MPL-2
  Programming Lang: Python
  Description : Smart Automatic Cover Art Downloader

SACAD is a multi platform command line tool to download album covers
without manual intervention, ideal for integration in scripts, audio
players, etc.

SACAD also provides a second command line tool, sacad_r, to scan a
music library, read metadata from audio tags, and download missing
covers automatically, optionally embedding the image into audio audio
files.  Features

 * Can target specific image size, and find results for high resolution covers
 * Support JPEG and PNG formats
 * Customizable output: save image along with the audio files / in a different 
directory named by artist/album / embed cover in audio files...
 * Currently support the following cover sources:
   * Amazon CD (.com, .ca, .cn, .fr, .de, .co.jp and .co.uk variants)
   * Amazon digital music
   * CoverLib (site is dead)
   * Deezer
   * Discogs
   * Google Images (removed, too unreliable)
   * Last.fm
   * Itunes
 * Smart sorting algorithm to select THE best cover for a given query,
   using several factors: source reliability, image format, image
   size, image similarity with reference cover, etc.
 * Automatically crunch images with optipng, oxipng or jpegoptim (can
   save 30% of filesize without any loss of quality, great for
   portable players)
 * Cache search results locally for faster future search
 * Do everything to avoid getting blocked by the sources: hide
   user-agent and automatically take care of rate limiting
 * Automatically convert/resize image if needed
 * Multiplatform (Windows/Mac/Linux)

SACAD is designed to be robust and be executed in batch of thousands
of queries:

 * HTML parsing is done without regex but with the LXML library, which
   is faster, and more robust to page changes

 * When the size of an image reported by a source is not reliable
   (ie. Google Images), automatically download the first KB of the
   file to get its real size from the file header

 * Process several queries simultaneously (using asyncio), to speed up
   processing

 * Automatically reuse TCP connections (HTTP Keep-Alive), for better
   network performance

 * Automatically retry failed HTTP requests

 * Music library scan supports all common audio formats (MP3, AAC,
   Vorbis, FLAC..)

 * Cover sources page or API changes are quickly detected, thanks to
   high test coverage, and SACAD is quickly updated accordingly



There are no tools, as far as I know, to do this in Debian. A friend
used this to great effect to cleanup their local music library, while
in the meantime I did this by hand to much lesser effect...

Bug#1056951: ITP: elpa-lin -- Lin is a stylistic enhancement for Emacs’ built-in hl-line-mode

[Nicholas D Steeves]

Hi Dhavan,

Dhavan Vaidya  writes:

> I have begun packaging:
>
> https://salsa.debian.org/codingquark/elpa-lin
>
> Feedback welcome.

The salsa project/git repo path shouldn't have an "elpa-" prefix (that
prefix is used for the binary package[s]).  This source package is
currently named "lin".  Did you read our package name policy?

https://wiki.debian.org/Teams/DebianEmacsenTeam

Read about what a source package is in Policy §4, and about what a
binary package is in Policy §3.

https://www.debian.org/doc/debian-policy/

The package FTBFS in a clean schroot (looks like missing build-depends).

https://wiki.debian.org/FTBFS

There are a couple issues that lintian can help you identify, and I
recommend that you configure gbp and/or sbuild to run lintian by
default.

Best,
Nicholas


signature.asc
Description: PGP signature

Bug#1057151: clang-17: ClangTargets.cmake cannot find libclang-17.so.1

[Cordell Bloor]

Package: clang-17
Version: 1:17.0.6-1
Severity: normal
X-Debbugs-Cc: c...@slerp.xyz, debian...@lists.debian.org

Dear Maintainer,

While attempting to update rocm-device-libs, I noticed that searching
for clang with find_package(Clang) will fail with an error. The
ClangTargets.cmake file expects libclang to be found at the path
"/usr/lib/llvm-17/lib/libclang-17.so.1", but the file is actually
installed to "/usr/lib/x86_64-linux-gnu/libclang-17.so.1".

The error encountred is:

```
CMake Error at /usr/lib/llvm-17/lib/cmake/clang/ClangTargets.cmake:833 
(message):
  The imported target "libclang" references the file

 "/usr/lib/llvm-17/lib/libclang-17.so.1"

  but this file does not exist.  Possible reasons include:

  * The file was deleted, renamed, or moved to another location.

  * An install or uninstall procedure did not complete successfully.

  * The installation package was faulty and contained

 "/usr/lib/llvm-17/lib/cmake/clang/ClangTargets.cmake"

  but not all the files it references.
```

The error can be reproduced with this minimal CMakeLists.txt:

```
cmake_minimum_required(VERSION 3.22)
project(example)
find_package(Clang)
```

Regards,
Cordell Bloor

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

Kernel: Linux 6.5.0-4-amd64 (SMP w/32 CPU threads; PREEMPT)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Versions of packages clang-17 depends on:
ii  binutils2.41-7
ii  libc6   2.37-12
ii  libc6-dev   2.37-12
ii  libclang-common-17-dev  1:17.0.6-1
ii  libclang-cpp17  1:17.0.6-1
ii  libclang1-171:17.0.6-1
ii  libgcc-13-dev   13.2.0-7
ii  libgcc-s1   13.2.0-7
ii  libllvm17   1:17.0.6-1
ii  libobjc-13-dev  13.2.0-7
ii  libstdc++-13-dev13.2.0-7
ii  libstdc++6  13.2.0-7
ii  llvm-17-linker-tools1:17.0.6-1

Versions of packages clang-17 recommends:
ii  llvm-17-dev  1:17.0.6-1
ii  python3  3.11.4-5+b1

Versions of packages clang-17 suggests:
pn  clang-17-doc  
pn  wasi-libc 

-- no debconf information

Bug#1037135: please update to latest upstream version (>> 4.2.0) and confirm intent to maintain package

[Nicholas D Steeves]

Hi Dhavan,

Dhavan  writes:

> On Monday, 10 July 2023 at 03:19, Nicholas D Steeves  wrote:
>
>> You've got this! :) You're already using a gbp (git-buildpackage) style
>> git repository so this is very easy. Just use the Files-Excluded
>> feature of debian/control, and run "gbp import-orig --uscan".
>
> I have finally pushed the update! Hopefully the package is built properly. 

Yay!  Hopefully you tested that the package builds ;)  Yes, I confirm
that it appears to build fine on my system, but did you run lintian?  I
didn't investigate more deeply due to errors.

> I have verified that docs are indeed excluded.

Thank you for double checking.

> I can update `Uploader` section as well to reflect my new working email, but
> haven't pushed the change yet. Is it recommended that I do this(it probably
> is)?

As discussed previously a package whose human maintainer can't be
reached at the email address specified in Uploader (or Maintainer for
non-team packages) effectively doesn't have a human maintainer, so yeah,
this will need to be updated, but...

If you're working towards DM or DD privileges, and you only want to use
one GPG key for future non-sponsored uploads (ie: if you want upload
privileges) then you might want to reconsider the use of Proton Mail.
I've been notified of the issue a couple of times, so started a
discussion here to see what other people think:

  RFC: advise against using Proton Mail for Debian work?
  https://lists.debian.org/debian-devel/2023/11/threads.html

To be clear, yes, it's OK to use this email provider in Uploader for
sponsored uploads, and it works fine on the mailing lists :)  You can
wait until later for the rest, if you want, or you can start 

What I mean is that it can't be used for DM or DD uploads nor for voting.

Meanwhile, I now see that you have a third address:

  https://salsa.debian.org/codingquark/elpa-lin/-/blame/debian/debian/control#L5

> Any specific things I should consider?

Running lintian...
E: modus-themes source: license-problem-gfdl-invariants invariant part is: with 
no invariant sections, with the front-cover texts being â??a gnu manual,â?? and 
with the back-cover texts as in (a) below [doc/modus-themes.info]
E: modus-themes source: license-problem-gfdl-invariants invariant part is: with 
no invariant sections, with the front-cover texts being â??a gnu manual,â?? and 
with the back-cover texts as in (a) below [doc/modus-themes.org]
E: modus-themes source: source-ships-excluded-file doc/doclicense.texi 
[debian/copyright:5]
E: modus-themes source: source-ships-excluded-file doc/modus-themes.info 
[debian/copyright:5]
E: modus-themes source: source-ships-excluded-file doc/modus-themes.org 
[debian/copyright:5]

To be fair, it looks like your updated work wasn't pushed to salsa.  Do
you know about "gbp push" which pushes upstream branch+tag and
pristine-tar?

I: modus-themes source: out-of-date-standards-version 4.5.0 (released 
2020-01-20) (current is 4.6.2)
I: modus-themes source: repackaged-source-not-advertised [debian/copyright]

You can use "lintian-explain-tags repackaged-source-not-advertised" or
run lintian with "-i" or "--info" to learn about any of these.

https://wiki.debian.org/DebianMentorsFaq#What_does_.2BIBw-dfsg.2BIB0_or_.2BIBw-ds.2BIB0_in_the_version_string_mean.3F

Also, don't forgot to fix up the watch file to handle the repacked
suffix.  The solution for this is in the Debian wiki.

> Thanks for the hints, those helped me be super quick about the things.

You're welcome.  I didn't provide a complete solution the mentorship
process is supposed to cultivate problem solving, rather than
checklist-following (ie: robot work).  Some work should to automated
though.  For example, you should learn how to make lintian run
automatically when you build a package.

Best,
Nicholas

Bug#1055611: bookworm-pu: package oscrypto/1.3.0-1+deb12u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Wed, 2023-11-08 at 22:06 +0100, Santiago Vila wrote:
> This upload fixes FTBFS bug #1033822 in stable.
> It fixes also the autopkgtests, which are currently broken in stable.

Please go ahead.

Regards,

Adam

Bug#1053101: qemu-user-static: PIE and mmap()

[Richard Henderson]

On Fri, 24 Nov 2023 21:43:54 + Tj  wrote:

$ qemu-aarch64-static -strace sid-aarch64/usr/lib/ld-linux-aarch64.so.1 
--verify sid-aarch64/usr/bin/aarch64-linux-gnu-g++-13
482357 brk(NULL) = 0x005500042000
482357 
openat(AT_FDCWD,"sid-aarch64/usr/bin/aarch64-linux-gnu-g++-13",O_RDONLY|O_CLOEXEC)
 = 3
482357 read(3,0x2841280,832) = 832
482357 getcwd(0x5500041980,128) = 18
482357 
mmap(0x0040,937984,PROT_EXEC|PROT_READ,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,3,0)Segmentation
 fault (core dumped)



The crash is because the guest g++ executable overlaps the host qemu executable, and this 
mmap clobbers qemu itself.  There is some code in qemu that *attempts* to avoid this 
situation, but it *only* works when the main executable is the one with the conflict.


In this case, you're running the g++ executable indirectly, with ld-linux-aarch64.so.1 as 
the main executable, so qemu cannot see the conflict.


Solving this is only possible with complete separation of host and guest address spaces. 
QEMU does this by default when running 32-bit guest on 64-bit host, but we have no 
general-purpose solution for 64-bit guest.


You can avoid some of the problems with QEMU_RESERVED_VA=0x10, giving the guest a 
dedicated 40-bit address space, but that will cause other failures with applications that 
expect more virtual address space.


It is a long-term goal for QEMU to be able to provide a complete separate virtual address 
space, but that will not happen soon.

Bug#1055539: bookworm-pu: package opensc/0.23.0-0.3+deb12u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Wed, 2023-11-08 at 02:15 +0100, Bastian Germann wrote:
> opensc in bookworm is vulnerable for CVE-2023-4535, CVE-2023-40660,
> CVE-2023-40661.

Please go ahead.

Regards,

Adam

Bug#1055419: bookworm-pu: package pcs/0.11.5-1+deb12u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Sun, 2023-11-05 at 17:16 +0100, Valentin Vidic wrote:
> Running the 'crm resource move' command results in a Python
> stack trace due to missing arguments in a function call. The
> bug was introduced in version 0.11.5 and fixed upstream in
> 0.11.6.

Please go ahead.

Regards,

Adam

Bug#1055350: bookworm-pu: package exfatprogs/1.2.0-1+deb12u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Sat, 2023-11-04 at 18:05 +0100, Sven Hoexter wrote:
> https://security-tracker.debian.org/tracker/CVE-2023-45897
> Low priority security issue, out-of-bounds memory access
> in the exFAT fsck utility exfat2img helper.

Please go ahead.

Regards,

Adam

Bug#1055248: bookworm-pu: pipewire/0.3.65-3+deb12u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Thu, 2023-11-02 at 21:02 +0100, Dylan Aïssi wrote:
> Fix memory leak in pipewire-pulse #1015915.

Please go ahead.

Regards,

Adam

Bug#1055229: bookworm-pu: package redis/5:7.0.11-1+deb12u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Thu, 2023-11-02 at 10:27 -0400, Chris Lamb wrote:
>   redis (5:7.0.11-1+deb12u1) bookworm; urgency=medium
>   .
>     * Drop ProcSubset=pid hardening flag from the systemd unit files
> it causes
>   difficult-to-reproduce crashes with memory allocation errors. A
> big thanks
>   to Arnaud Rebillout  for the extensive
> investigation.
>   (Closes: #1055039)
>     * Update debian/gbp.conf for the debian/bookworm branch.
> 

Please go ahead.

Regards,

Adam

Bug#1057150: fonts-noto-color-emoji: Update for Unicode 15.1

[Jeremy Bícha]

Source: fonts-noto-color-emoji
Version: 2.038-1
Severity: important
Tags: bookworm

The Debian GNOME, KDE  and Cinnamon desktops include Google's color
emoji font by default. Annually, the Unicode Consortium releases a new
Unicode standard with new emoji. Internet communication platforms
quickly adopt the new emoji and it's important that those emoji also
work on the latest Debian Stable release.

Emojipedia provides a list of the emoji provided by this font.

Click the Show new link to see the new emoji. Click the changed link
to see other changes that were made in this release.
https://emojipedia.org/google/15.1/

Or see 
https://blog.emojipedia.org/googles-emoji-15-1-support-in-noto-color-emoji/

One other change not mentioned there is that the flag for Martinique
has been updated.

Thank you,
Jeremy Bícha

Bug#1057120: Fwd: Bug#1057120: gettext: FTBFS on amd64 in sid chroot due to failing autopoint-3 test

[Bruno Haible]

Santiago Vila wrote:
> FAIL: autopoint-3
> =
> 
> make[7]: warning: jobserver unavailable: using -j1.  Add '+' to parent make 
> rule.
> : error: macro names must be identifiers

To analyze this error, I would add a 'set -x' command in line 2
of gettext-tools/tests/autopoint-3, and retry the build.

> hello.c: In function 'main':
> hello.c:31:63: warning: implicit declaration of function 'getpid' 
> [-Wimplicit-function-declaration]
> 31 |   printf (_("This program is running as process number %d."), getpid 
> ());
>|   ^~

This warning was fixed by the gettext-tools/examples/hello-c/hello.c change in
https://git.savannah.gnu.org/gitweb/?p=gettext.git;a=commitdiff;h=eb0ded32dbcd7bf6ccffc038509983ccca52631b

Bruno

Bug#1057105: dolphin: Dolphin File Explorer Selects Multiple Folders When Opening One Folder

[Antonio]

Dear maintainer,
I confirm the same occasional problem with version 4:23.08.1-1 (Debian/Sid)

Thanks,
Antonio

Bug#1054393: dns-root-data: New IPs for b.root-servers-net 2023-11-27

[Imre Jonk]

The root hints as published by IANA have now been updated. I've
prepared a merge request here:
https://salsa.debian.org/dns-team/dns-root-data/-/merge_requests/2

Bug#1057052: Acknowledgement (amd64 install DVD 1 puts "contrib" component on target's sources.list)

[Adonay Felipe Nogueira]

For those wondering, my first message wasn't signed since my email 
client (Icedove, based on Thunderbird) no longer used Enigmail or the 
system's gpg-agent.


Here is a signed message as proof that I have sent the bug report.


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1057147: Acknowledgement (Does not look for config in ~/.config/dput/dput.cf)

[Ben Hutchings]

Control: tag -1 patch

I opened a merge request to fix this:


Ben.

-- 
Ben Hutchings
It is easier to write an incorrect program
than to understand a correct one.



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

Bug#1056533: testresources autopkg tests fail with Python 3.12

[Olivier Gayot]

Package: testresources
Followup-For: Bug #1056533
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu noble ubuntu-patch
Control: tags -1 patch

Dear Maintainer,

The testresources autopkgtest test-suite currently fails with Python
3.12 because it still uses unittest.TestCase.failIf.

failIf was a deprecated alias for assertFalse and was dropped from
Python 3.12.

Applying a patch from upstream allows the test-suite to pass with Python
3.12.

In Ubuntu, the attached patch was applied to achieve the following:


  * Fix test-suite so it can run with Python 3.12. (LP: #2045302)


Thanks for considering the patch.


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

Kernel: Linux 6.1.0-16-generic (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru testresources-2.0.1/debian/patches/python3.12.patch 
testresources-2.0.1/debian/patches/python3.12.patch
--- testresources-2.0.1/debian/patches/python3.12.patch 1970-01-01 
01:00:00.0 +0100
+++ testresources-2.0.1/debian/patches/python3.12.patch 2023-11-30 
18:59:39.0 +0100
@@ -0,0 +1,35 @@
+Description: Refactor failIf to assertFalse for Python 3.12 Compatibility
+ This commit replaces deprecated failIf calls with assertFalse in the
+ test_resourced_test_case.py file. The failIf method was removed in
+ Python 3.12 [1-3].
+ .
+ [1] https://docs.python.org/3.12/whatsnew/3.12.html#removed
+ [2] https://github.com/python/cpython/issues/89325
+ [3] https://github.com/python/cpython/pull/28268
+Author: Petr Vaněk 
+Origin: upstream, https://github.com/testing-cabal/testresources/pull/15
+Bug: https://launchpad.net/bugs/2045302
+Bug-Ubuntu: https://launchpad.net/bugs/2045302
+Bug-Debian: https://bugs.debian.org/1056533
+Applied-Upstream: 
https://github.com/testing-cabal/testresources/commit/7bb62a13fa1d28717c10f3152b5e8ea479c8e9d2
+Last-Update: 2023-11-30
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- a/testresources/tests/test_resourced_test_case.py
 b/testresources/tests/test_resourced_test_case.py
+@@ -129,7 +129,7 @@
+ self.resourced_case.resources = [("foo", self.resource_manager)]
+ self.resourced_case.setUpResources()
+ self.resourced_case.tearDownResources()
+-self.failIf(hasattr(self.resourced_case, "foo"))
++self.assertFalse(hasattr(self.resourced_case, "foo"))
+ 
+ def testTearDownResourcesStopsUsingResource(self):
+ # tearDownResources records that there is one less use of each
+@@ -158,5 +158,5 @@
+ self.assertEqual(self.resourced_case.foo, self.resource)
+ self.assertEqual(self.resource_manager._uses, 1)
+ self.resourced_case.tearDown()
+-self.failIf(hasattr(self.resourced_case, "foo"))
++self.assertFalse(hasattr(self.resourced_case, "foo"))
+ self.assertEqual(self.resource_manager._uses, 0)
diff -Nru testresources-2.0.1/debian/patches/series 
testresources-2.0.1/debian/patches/series
--- testresources-2.0.1/debian/patches/series   2022-10-17 12:22:49.0 
+0200
+++ testresources-2.0.1/debian/patches/series   2023-11-30 18:59:07.0 
+0100
@@ -1,2 +1,3 @@
 remove-non-deterministic-ftbfs-testBasicSortTests.patch
 python3.10.patch
+python3.12.patch

Bug#1054645:

[Fabio Pedretti]

forwarded 1054645 https://gitlab.freedesktop.org/mesa/mesa/-/issues/10228
thanks

Bug#1057140: libemf: FTBFS: error: #error Unknown CPU architecture

[Barak A. Pearlmutter]

Thanks.

Please feel free to just fix and upload stuff like this, push fix to salsa
git repo. I absolutely don't mind. If you don't I'll get to it in a few
days.

Bug#1057120: Fwd: Bug#1057120: gettext: FTBFS on amd64 in sid chroot due to failing autopoint-3 test

[Santiago Vila]

Hello.

I've received the report below from the Debian bug system.

To fix it, I tried applying the following two patches to the 0.21 version:

https://git.savannah.gnu.org/gitweb/?p=gettext.git;a=commit;h=95ac95545141d1d72638dd3995c0171d8ad34f77
https://git.savannah.gnu.org/gitweb/?p=gettext.git;a=commit;h=f23b7847990cb31b59729517314e5d0fb649f64e

but now it fails in this way:

FAIL: autopoint-3
=

make[7]: warning: jobserver unavailable: using -j1.  Add '+' to parent make 
rule.
: error: macro names must be identifiers
hello.c: In function 'main':
hello.c:31:63: warning: implicit declaration of function 'getpid' 
[-Wimplicit-function-declaration]
   31 |   printf (_("This program is running as process number %d."), getpid 
());
  |   ^~
make[8]: *** [Makefile:503: hello.o] Error 1
make[7]: *** [Makefile:539: all-recursive] Error 1
FAIL autopoint-3 (exit status: 1)

(This is on a Debian system running trixie/sid, which means glibc 2.37
and probably many other things).

Not sure what to do now.

Thanks.

 Mensaje reenviado 
Asunto: Bug#1057120: gettext: FTBFS on amd64 in sid chroot due to failing 
autopoint-3 test
Fecha: Thu, 30 Nov 2023 17:56:56 +1300
De: Vladimir Petko 
Responder a: Vladimir Petko , 
1057...@bugs.debian.org
Para: Debian Bug Tracking System 

Package: gettext
Version: 0.21-13
Severity: important
X-Debbugs-Cc: vladimir.pe...@canonical.com

Dear Maintainer,

When build the package in sid chroot with `sbuild -c sid-amd64` the package
fails to build from source due to the failure of autopoint-3 test:

--
SKIP lang-php (exit status: 77)

FAIL: autopoint-3
=

configure.ac:3: installing './compile'
configure.ac:3: installing './config.guess'
configure.ac:3: installing './config.sub'
Makefile.am: installing './depcomp'
FAIL autopoint-3 (exit status: 1)


Testsuite summary for gettext-tools 0.21

# TOTAL: 445
# PASS:  405
# SKIP:  39
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0

See tests/test-suite.log
Please report to bug-gett...@gnu.org

make[6]: *** [Makefile:2995: test-suite.log] Error 1
make[6]: Leaving directory '/<>/gettext-tools/tests'
make[5]: *** [Makefile:3103: check-TESTS] Error 2
make[5]: Leaving directory '/<>/gettext-tools/tests'
make[4]: *** [Makefile:6284: check-am] Error 2
make[4]: Leaving directory '/<>/gettext-tools/tests'
make[3]: *** [Makefile:2356: check-recursive] Error 1
make[3]: Leaving directory '/<>/gettext-tools'
make[2]: *** [Makefile:406: check-recursive] Error 1
make[2]: Leaving directory '/<>'
make[1]: *** [Makefile:708: check] Error 2
make[1]: Leaving directory '/<>'
dh_auto_test: error: make -j32 check "TESTSUITEFLAGS=-j32 --verbose" VERBOSE=1
returned exit code 2
make: *** [debian/rules:4: binary] Error 25
dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2
-

Also the package fails to build in Ubuntu[1]

[1] https://launchpadlibrarian.net/700220461/buildlog_ubuntu-noble-
amd64.gettext_0.21-13~1_BUILDING.txt.gz

[...]

Bug#1055571: cracklib2 tests fail with Python 3.12

[Olivier Gayot]

Package: cracklib2
Followup-For: Bug #1055571
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu noble ubuntu-patch
Control: tags -1 patch

Dear Maintainer,

When attempting to build src:cracklib2 against Python 3.12, the
build-time test-suite fails, making the package FTBFS.

The test-suite still uses unittest.TestCase.assertEquals() which was
a deprecated alias for unittest.TestCase.assertEqual() (without the s).
The alias was dropped from Python 3.12.

In Ubuntu, the attached patch was applied to achieve the following:


  * Fix build against Python 3.12. (LP: #2045290)


Thanks for considering the patch.


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

Kernel: Linux 6.1.0-16-generic (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru cracklib2-2.9.6/debian/patches/python3.12-support.patch 
cracklib2-2.9.6/debian/patches/python3.12-support.patch
--- cracklib2-2.9.6/debian/patches/python3.12-support.patch 1970-01-01 
01:00:00.0 +0100
+++ cracklib2-2.9.6/debian/patches/python3.12-support.patch 2023-11-30 
17:46:13.0 +0100
@@ -0,0 +1,77 @@
+Description: Fix build against Python 3.12
+ The build-time test suite still used the obsolete assertEquals function -
+ which was obsolete and got dropped from Python 3.12. Use the replacement
+ instead so we can build with Python 3.12.
+Author: Olivier Gayot 
+Bug-Ubuntu: https://launchpad.net/bugs/2045290
+Bug-Debian: https://bugs.debian.org/1055571
+Forwarded: https://github.com/cracklib/cracklib/pull/75
+Last-Update: 2023-11-30
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- a/python/test_cracklib.py
 b/python/test_cracklib.py
+@@ -76,41 +76,41 @@
+ def test_simple_lower(self):
+ for passwd in ['t' * i for i in range(
+ cracklib.MIN_LENGTH - cracklib.LOW_CREDIT)]:
+-self.assertEquals(
++self.assertEqual(
+ 1, cracklib.simple(passwd),
+ 'password {0} should be detected as too simple'.format(
+ passwd))
+-self.assertEquals(0, cracklib.simple(
++self.assertEqual(0, cracklib.simple(
+ 't' * (cracklib.MIN_LENGTH - cracklib.LOW_CREDIT)))
+ 
+ def test_simple_upper(self):
+ for passwd in ['T' * i for i in range(
+ cracklib.MIN_LENGTH - cracklib.UP_CREDIT)]:
+-self.assertEquals(
++self.assertEqual(
+ 1, cracklib.simple(passwd),
+ 'password {0} should be detected as too simple'.format(
+ passwd))
+-self.assertEquals(0, cracklib.simple(
++self.assertEqual(0, cracklib.simple(
+ 'T' * (cracklib.MIN_LENGTH - cracklib.UP_CREDIT)))
+ 
+ def test_simple_digit(self):
+ for passwd in ['1' * i for i in range(
+ cracklib.MIN_LENGTH - cracklib.DIG_CREDIT)]:
+-self.assertEquals(
++self.assertEqual(
+ 1, cracklib.simple(passwd),
+ 'password {0} should be detected as too simple'.format(
+ passwd))
+-self.assertEquals(0, cracklib.simple(
++self.assertEqual(0, cracklib.simple(
+ '1' * (cracklib.MIN_LENGTH - cracklib.DIG_CREDIT)))
+ 
+ def test_simple_other(self):
+ for passwd in ['#' * i for i in range(
+ cracklib.MIN_LENGTH - cracklib.OTH_CREDIT)]:
+-self.assertEquals(
++self.assertEqual(
+ 1, cracklib.simple(passwd),
+ 'password {0} should be detected as too simple'.format(
+ passwd))
+-self.assertEquals(0, cracklib.simple(
++self.assertEqual(0, cracklib.simple(
+ '#' * (cracklib.MIN_LENGTH - cracklib.OTH_CREDIT)))
+ 
+ def test_simple_combinations(self):
+@@ -119,11 +119,11 @@
+ cracklib.MIN_LENGTH -
+ cracklib.LOW_CREDIT -
+ cracklib.OTH_CREDIT)]:
+-self.assertEquals(
++self.assertEqual(
+ 1, cracklib.simple(passwd),
+ 'password {0} should be detected as too simple'.format(
+ passwd))
+-self.assertEquals(0, cracklib.simple(
++self.assertEqual(0, cracklib.simple(
+ testset[:(cracklib.MIN_LENGTH - cracklib.LOW_CREDIT -
+   cracklib.OTH_CREDIT)]))
+ 
diff -Nru cracklib2-2.9.6/debian/patches/series 
cracklib2-2.9.6/debian/patches/series
--- cracklib2-2.9.6/debian/patches/series   2022-11-29 08:26:33.0 
+0100
+++ 

Bug#1057149: gimp: Please add Conflicts+Replaces: gimp-dds

[Adrian Bunk]

Package: gimp
Version: 2.10.12-1
Severity: serious

gimp-dds was included in 2.10.10, and the old version of the
plugin in gimp-dds is also vulnerable to CVE-2023-1.

Please add[1]
  Conflicts: gimp-dds
  Replaces: gimp-dds
to get rid of the stale version of this plugin.

A fast upload would be appreciated so that I can also submit
this change for the next bookworm (and bullseye) point releases.

Thanks in advance


[1] https://lists.debian.org/deity/2023/11/msg00037.html

Bug#923851: Workaround

[Matthias Geiger]

On Fri, 27 Nov 2020 13:33:54 +0100 Philipp Marek  
wrote:

> For the convenience of others in this thread:
>
> I took Arch's package ([1], via [2], extracted it in /opt, and put a
> symlink in /usr/local/bin. Works fine with openjdk-11-jre-headless.
>
>
> (Perhaps something similar could be done to re-start the Java dependency
> loop referenced in the blocking bug[3]?)
>
>
>
> Ad 1: https://www.archlinux.org/packages/community/x86_64/ghidra/
> Ad 2: "wget
> https://www.archlinux.org/packages/community/x86_64/ghidra/download/;
> Ad 3: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=926714
>
>

While this shouldn't be done (frankendebian) you can get the .deb from 
the KaliLinux repositories.


You'll want ghidra and ghidra-date from here: 
http://ftp.halifax.rwth-aachen.de/kali/pool/main/g/ghidra/ for instance 
(amd64 and arm64 only).


They pull the upstream gradle binary in during the build and build the 
rest "regularly" form what I can tell. Like I said, you shouldn't 
install random debs unless you know exactly what you are doing,


but it works fine so far on my sid machine.

best,

--
Matthias Geiger 
Debian Maintainer
"Freiheit ist immer Freiheit des anders Denkenden" -- Rosa Luxemburg



OpenPGP_0x18BD106B3B6C5475.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1057148: python-dbusmock/0.30.0-1 autopkg tests are failing

[Matthias Klose]

Package: src:python-dbusmock
Version: 0.30.0-1
Severity: serious
Tags: sid trixie

python-dbusmock/0.30.0-1 autopkg tests are failing:

[...]
1428s autopkgtest [12:44:58]: test upstream: [---
1433s ...dbus-daemon[1749]: [session uid=1000 
pid=1749] Reloaded configuration
1433s dbus-daemon[1749]: [session uid=1000 pid=1749] Activating service 
name='org.TestSession' requested by ':1.0' (uid=1000 pid=1717 
comm="python3 test_api.py" label="unconfined")
1433s dbus-daemon[1749]: [session uid=1000 pid=1749] Successfully 
activated service 'org.TestSession'

1433s dbus-daemon[1749]: [session uid=1000 pid=1749] Reloaded configuration
1433s dbus-daemon[1749]: [session uid=1000 pid=1749] Reloaded configuration
1433s ..dbus-daemon[1749]: [session uid=1000 pid=1749] Reloaded 
configuration

1433s dbus-daemon[1749]: [session uid=1000 pid=1749] Reloaded configuration
1433s dbus-daemon[1749]: [session uid=1000 pid=1749] Reloaded configuration
1433s .dbus-daemon[1748]: [system] Reloaded configuration
1433s dbus-daemon[1748]: [system] Activating service 
name='org.TestSystem' requested by ':1.0' (uid=1000 pid=1717 
comm="python3 test_api.py" label="unconfined")
1433s dbus-daemon[1748]: [system] Successfully activated service 
'org.TestSystem'

1433s dbus-daemon[1748]: [system] Reloaded configuration
1433s dbus-daemon[1748]: [system] Reloaded configuration
1433s .dbus-daemon[1748]: [system] Reloaded configuration
1433s dbus-daemon[1748]: [system] Reloaded configuration
1433s dbus-daemon[1748]: [system] Reloaded configuration
1435s ...
1435s --
1435s Ran 42 tests in 6.080s
1435s
1435s OK
1435s Traceback (most recent call last):
1435s   File 
"/tmp/autopkgtest.gGVLMr/build.Dnb/src/tests/test_api_pytest.py", line 
14, in 

1435s import pytest
1435s ModuleNotFoundError: No module named 'pytest'
1435s autopkgtest [12:45:05]: test upstream: ---]

Bug#1057147: Does not look for config in ~/.config/dput/dput.cf

[Ben Hutchings]

Package: dput-ng
Version: 1.37
Severity: normal

dput now looks for its config in ~/.config/dput/dput.cf as well as
~/.dput.cf.  (The ~/.config prefix should also be overridable by
setting $XDG_CONFIG_HOME, but I haven't checked whether dput
implements that.)

Please add support for this alternate location.

Ben.

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

Kernel: Linux 6.5.0-4-amd64 (SMP w/12 CPU threads; PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.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 dput-ng depends on:
ii  python3   3.11.4-5+b1
ii  python3-dput  1.37

dput-ng recommends no packages.

Versions of packages dput-ng suggests:
pn  dput-ng-doc  
pn  python3-twitter  

-- debconf-show failed

Bug#636342: release.debian.org: provide a dd-list in the transition tracker

[Sebastiaan Couwenberg]

The attached script can be used to generate a dd-list from the URL to 
the transition tracker.


Kind Regards,

Bas

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

transition-dd-list.pl
Description: Perl program

Bug#1057118: RFP: anyrun -- A wayland native, highly customizable runner.

[Antoine Beaupré]

On 2023-11-30 13:06:19, Matthias Geiger wrote:

[...]

> looks packageable from a first glance with only gtk-layer-shell missing 
> for anyrun and anyrun-interface. An issue is gtk-layer-shell which 
> contains generated code; gtk-rs has the same issue but I resolved that 
> via re-generating the code. I pondered whether I should package 
> gtk-layer-shell but haven't found a use case so far. If someone wants to 
> package it they should take a look at gtk4-sys for instance and must (!) 
> regenerate the code the same way. Feel free to ask me about that.

Whoa, that's way better than I expected!

I guess lots of things are plugins in there so we could package the core
without having to fix all deps. For example, rink is its whole own app
that anyrun links with, but it would definitely need to be packaged
seperately as it's a calculator that we should (IMHO) really have on its
own in Debian as well...

a.

-- 
Vivre tous simplement pour que tous puissent simplement vivre.
- Gandhi

Bug#1057146: collectd: drop build-dependency on libdpdk-dev on i386

[Luca Boccassi]

Source: collectd

Dear Maintainer,

We are in the process of dropping i386 support from dpdk. Currently
src:collectd build-depends on libdpdk-dev on amd64 and i386 - please
drop the latter. We will need this for the upcoming dpdk 23.11
transition that we are preparing, and should happen within the next
couple of weeks.

We already checked that collectd builds correctly with dpdk 23.11, so
this change could be done immediately, and then the transition can be
done as a binmu, reducing the need to synchronize.

Thank you!

-- 
Kind regards,
Luca Boccassi


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

Bug#1057145: debootstrap: Sync hangs

[Андрей Маслов]

Package: debootstrap
Version: 1.0.123+deb11u1
Severity: normal
Tags: upstream
 
In case of using LDAP, mounting flash drives and so on, a hang may occur.
Using forward sync in debootstrap is not correctly.
Please, modify  command to  or similar to prevent waiting
overhead.
 
There is 816...@bugs.debian.org. But in this bug sync will not produce hanging.
If you cant use , add any check for LDAP or autofs.
Now on our server it is not possible to use debootstrap.
I have replaced   ->  to prevent hanging.
 
-- System Information:
Debian Release: 11.8
  APT prefers oldstable-updates
  APT policy: (500, 'oldstable-updates'), (500, 'oldstable-security'), (500,
'oldstable')
Architecture: amd64 (x86_64)
 
Kernel: Linux 5.10.0-26-amd64 (SMP w/12 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8), LANGUAGE not
set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
 
Versions of packages debootstrap depends on:
ii  wget  1.21-1+deb11u1
 
Versions of packages debootstrap recommends:
ii  arch-test               0.17-1
ii  debian-archive-keyring  2021.1.1+deb11u1
ii  gnupg                   2.2.27-2+deb11u2
 
Versions of packages debootstrap suggests:
pn  squid-deb-proxy-client  
pn  ubuntu-archive-keyring  
 
--
With all respect, Andrew

Bug#1057144: icedtea-netx: The manual pages are missing/corrupted.

[Daniel Vacek]

Package: icedtea-netx
Version: 1.8.8-2
Severity: normal
X-Debbugs-Cc: neel...@gmail.com

The files in /usr/share/icedtea-web/man/man1 are missing or wrong.

--nX


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

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

Versions of packages icedtea-netx depends on:
ii  default-jre  2:1.17-75
ii  librhino-java1.7.14-2.1
ii  libtagsoup-java  1.2.1+-1.1

icedtea-netx recommends no packages.

icedtea-netx suggests no packages.

-- no debconf information

Bug#1053565: RFS: openvpn3-client/20+dfsg-1 [ITP] -- virtual private network daemon (version 3)

[Marc Leeman]

>>   * Package name : openvpn3-client
> BTW, why it is named this way?
> Is it client-only now, without the server part?
> Previous package is named just "openvpn", it acts
> as both client or server (actually the two roles are
> symmetric, it can be both).  If new openvpn is like
> this, I suggest naming it just "openvpn3", without
> the -client part, since it is quite confusing.

> Or is there also -daemon (or -server) part?

Sorry, missed your e-mail.

This is not the same as the openvpn packages, this is a different
implementation from the same company.

At the moment, they have only released the client part.

This implementation has functionality for 2-factor authentication that
openvpn2 does not have.

The package that upstream releases is openvpn3-linux (source) or
openvpn3 (package). I have named it

openvpn3-client to

1. Make it clear that this is only the client part
2. Prepare for future releases that include a server part

There internal software structure is already split into different
parts; but they release a collapsed archive for the client only.

--
g. Marc

GPG: 827C FD74 BA46 8152 A041 F3A0 7A6A 4F17 5995 A65B

Bug#1057143: node-acorn: nodejs 18.19.0 seems to be expecting node-acorn 8.10.0

[Jérémy Lal]

Package: node-acorn
Version: 8.8.1+ds+~cs25.17.7-2
Severity: wishlist

Hi,

at the moment it seems there is no strong motivation for upgrading,
however, the fact nodejs expects acorn 8.10.0 means it will probably
use new features, if any.

So, no rush, but probably needed anytime soon.

Jérémy


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

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

Versions of packages node-acorn depends on:
ii  node-xtend  4.0.2-3
ii  nodejs  18.14.2+dfsg-1

node-acorn recommends no packages.

node-acorn suggests no packages.

-- no debconf information

Bug#1057142: linux-image-6.5.0-0.deb12.4-amd64-unsigned: The system does not boot OK, systemd is KO

[jp.po...@izzop.net]

Package: linux-image-6.5.0-0.deb12.4-amd64-unsigned
Severity: normal

Dear Maintainer,

   * What led up to the situation?
I upgrade a machine from bullseye to bookworm.
I install the lmast kernel (6.5)
The system does not boot correctly as systemd is KO
Even in "recovery mode" the system stay locked on the end od setting network.
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
I try the rescue mode which was ineffective.

I try a 6.4 kernel with the same problems ... the kernel 6.1.0-0.deb11.13-amd64
boots OK.

Regards

JP P

PS :
I have at least another system which cannot boot with 6.5 kernel (unless in
rescue mode) with looping message :
mdadm: nodevices listed in conf file were found

dropping to a shell
Busybox


That system boots OK in rescue mode with the 6.5 kernel.




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

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

Versions of packages linux-image-6.5.0-0.deb12.4-amd64-unsigned depends on:
ii  initramfs-tools [linux-initramfs-tool]  0.142
ii  kmod30+20221128-1
ii  linux-base  4.9

Versions of packages linux-image-6.5.0-0.deb12.4-amd64-unsigned recommends:
ii  apparmor 3.0.8-3
ii  firmware-linux-free  20200122-1

Versions of packages linux-image-6.5.0-0.deb12.4-amd64-unsigned suggests:
pn  debian-kernel-handbook  
ii  grub-pc 2.06-13+deb12u1
pn  linux-doc-6.5   

Bug#568601: Can confirm this problem still exists

[Matijs van Zuijlen]

Dear maintainer,

This problem still exists. I installed netatalk from testing on a Debian 
server running stable, and libgcrypt was not updated at the same time 
because the dependency in the netatalk package specifies '>= 1.10.0', 
which matches the stable version 1.10.1, while testing's netatalk 
actually needs libgcrypt 1.10.2. This lead to a flood of errors in the 
logs. Updating the libgcrypt package to the testing version (1.10.2) 
fixed that problem.


As far as I can tell, the solution would be for the netatalk package to 
depend on (at least?) the libgcrypt version it was compiled with.


--
Kind regards,
Matijs van Zuijlen

Bug#1057141: python3-pgmagick: Image annotate fails on bookworm as the default font no longer installed

[Justin Saunders]

Package: python3-pgmagick
Version: 0.7.6-1+b5
Severity: normal
X-Debbugs-Cc: j.jum...@gmail.com

Dear Maintainer,

The default font for pgmagick is not installed in bookworm, it is in
bullseye. This short program shows the issue.

import pgmagick

geo = pgmagick.Geometry(600, 600)
red = pgmagick.Color('red')
img = pgmagick.Image(geo, red)

img.fillColor('black')
img.annotate('This is a test', '+5+10')
img.write('test.png')

On bookworm this produces:

Traceback (most recent call last):
  File "//test.py", line 8, in 
img.annotate('This is a test', '+5+10')
RuntimeError: Magick: Unable to read font 
(/usr/share/fonts/type1/gsfonts/n019003l.pfb) reported by 
magick/annotate.c:1174 (RenderFreetype)

If you use one of the installed fonts with the font method this call
works.

Thanks

Justin

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

Kernel: Linux 5.15.0-89-generic (SMP w/2 CPU threads)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Versions of packages python3-pgmagick depends on:
ii  libboost-python1.74.0 [libboost-python1.74.0-py311]  1.74.0+ds1-21
ii  libc62.36-9+deb12u3
ii  libgcc-s112.2.0-14
ii  libgraphicsmagick++-q16-12   1.4+really1.3.40-4
ii  libstdc++6   12.2.0-14
ii  python3  3.11.2-1+b1

python3-pgmagick recommends no packages.

python3-pgmagick suggests no packages.

-- no debconf information

Bug#1055922: rmatrix: ABI change in Matrix 1.6-2

[Dirk Eddelbuettel]

Hi Graham

On 30 November 2023 at 07:54, Graham Inggs wrote:
| Hi Dirk
| 
| On Thu, 30 Nov 2023 at 00:51, Dirk Eddelbuettel  wrote:
| > Ping squared.
| >
| > If I don't hear from you I may just close this. I believe this (non-, to me)
| > issue has been taken care of.  If you think I am wrong please let me know.
| 
| I closed it on 2023-11-24 [1].  Where do you see it still open?

My bad: I don't. I just didn't see an explicit ack.

(General bts acks are filtered away by procmail to a different folder).  So
my bad and sorry for wasting your time.

I see you track it at Ubuntu too so all good.  r2u, which dominates of course
all r-(cran,bioc)-* packages for use on jammy had it long covered.

Cheers, Dirk

| 
| [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1055922#118

-- 
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#1032164: bouncycastle: inconsistency in debian/rules?

[Markus Koschany]

Hi,

On Tue, 28 Feb 2023 22:08:12 +0100 Thomas Uhle
 wrote:
> Source: bouncycastle
> Version: 1.72-1
> Severity: normal
> 
> Dear maintainers,
> 
> I wonder why in debian/rules the pom files were synchronized with the 
> ones from Maven having the suffix "-jdk18on" while for building the binary 
> packages still "ant/jdk15+.xml" is used instead of "ant/jdk18+.xml".

Good question. Perhaps the jdk18+ jar files were breaking some reverse-
dependencies in the past. The soon to be released 1.77 version of bouncycastle
will require updates of several of those reverse-dependencies. As soon as those
issues are fixed, we can rebuild everything with jdk18+ again.




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