Bug#993428: nmu: libpdl-ccs-perl_1.23.16-1

[Bas Couwenberg]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu
X-Debbugs-Cc: pkg-perl-maintain...@lists.alioth.debian.org

Please rebuild this package to pick up the pdlapi-17 dependency:

nmu libpdl-ccs-perl_1.23.16-1 . ANY . unstable . -m "Rebuild with pdl (>= 
1:2.057)"

Kind Regards,

Bas

Bug#993427: nmu: libtfbs-perl_0.7.1-3

[Bas Couwenberg]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu
X-Debbugs-Cc: pkg-perl-maintain...@lists.alioth.debian.org

Please rebuild this package to pick up the pdlapi-17 dependency:

nmu libtfbs-perl_0.7.1-3 . ANY . unstable . -m "Rebuild with pdl (>= 1:2.057)"

Kind Regards,

Bas

Bug#993426: nmu: libpdl-vectorvalued-perl_1.0.10-1

[Bas Couwenberg]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu
X-Debbugs-Cc: pkg-perl-maintain...@lists.alioth.debian.org

Please rebuild this package to pick up the pdlapi-17 dependency:

nmu libpdl-vectorvalued-perl_1.0.10-1 . ANY . unstable . -m "Rebuild with pdl 
(>= 1:2.057)"

Kind Regards,

Bas

Bug#993425: nmu: libpdl-netcdf-perl_4.22-1

[Bas Couwenberg]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu
X-Debbugs-Cc: pkg-perl-maintain...@lists.alioth.debian.org

Please rebuild this package to pick up the pdlapi-17 dependency:

nmu libpdl-netcdf-perl_4.22-1 . ANY . unstable . -m "Rebuild with pdl (>= 
1:2.057)"

Kind Regards,

Bas

Bug#993424: nmu: libpdl-linearalgebra-perl_0.21-1

[Bas Couwenberg]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu
X-Debbugs-Cc: pkg-perl-maintain...@lists.alioth.debian.org

Please rebuild this package to pick up the pdlapi-17 dependency:

nmu libpdl-linearalgebra-perl_0.21-1 . ANY . unstable . -m "Rebuild with pdl 
(>= 1:2.057)"

Kind Regards,

Bas

Bug#993423: nmu: libpdl-io-matlab-perl_0.006-1

[Bas Couwenberg]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu
X-Debbugs-Cc: pkg-perl-maintain...@lists.alioth.debian.org

Please rebuild this package to pick up the pdlapi-17 dependency:

nmu libpdl-io-matlab-perl_0.006-1 . ANY . unstable . -m "Rebuild with pdl (>= 
1:2.057)"

Kind Regards,

Bas

Bug#993422: nmu: libpdl-io-hdf5-perl_1:0.75-1

[Bas Couwenberg]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu
X-Debbugs-Cc: pkg-perl-maintain...@lists.alioth.debian.org

Please rebuild this package to pick up the pdlapi-17 dependency:

nmu libpdl-io-hdf5-perl_1:0.75-1 . ANY . unstable . -m "Rebuild with pdl (>= 
1:2.057)"

Kind Regards,

Bas

Bug#893162: ITP: libhsts -- library for checking HSTS preload list

[Trent W. Buck]

Daniel Kahn Gillmor wrote:
> AIUI, future versions of wget will want to use something like libhsts
> to improve communications security for the user.

Note that (AFAIK):

  1. wget2 1.99 (in Debian 11) uses internal code to generate a persistent 
~/.wget-hsts.
 This does not require libhsts or any preload file (#893159).
 It means if you do

 wget2 http://google.com
 wget2 http://google.com

 The second call will remember HSTS learnt from the first one.
 This is better than nothing.

  2. libhsts IS the code from wget2.
 It was spun out into a separate library so wget1 could also use it.

  3. wget2 2.00 (releasing this week) needs libhsts;
 the functionality is no longer bundled as it was in 1.99.

 Without libhsts, wget2 2.00 can be built and packaged, but
 ~/.wget-hsts will be ignored (i.e. A REGRESSION!)

On that basis, I don't think #893159 should block #893162, since
~/.wget-hsts is useful even without a chromium preload file.

Bug#203623: HI

[Russell wilson]

 Hi. This is Russell Wilson from the United States. I really want to
communicate with you. Write back for more details.

Regards,

Russell Wilson

Bug#993154: Install successful but failed to load all basic software

[Guillem Jover]

Hi!

On Sat, 2021-08-28 at 12:19:55 +0800, beks...@westnet.com.au wrote:
> Package: dpkg

> Install to Raspberry Pi 4 (4G RAM)
> 
> Methodhttps://www.raspberrypi.org/forums/viewtopic.php?f=50=282839=3c56d720738b6f6768874193298c3c38
> install ran 26 August 2021 using images downloaded that day.
> Install ran fine BUT /usr/sbin/start-stop-daemon NOT installed. so
> dpkg aborts with a helpful error message.
> Had same problem about a month or so ago but did not have problem some
> months ago (shortly after the above guide came out)

Hmm, is the file /sbin/start-stop-daemon not present at all? Or is
it present but dpkg is just unable to find it? If the latter then you
should probably check whether your PATH environment variable contains
/usr/sbin and /sbin in it. If the former, then my first suspicion would
be on the messed up merged-/usr used by default by Debian. :/

Thanks,
Guillem

Bug#993177: RFS: dtkwidget/5.5.17.1-1~exp1 -- dtkwidget-examples is generated by dtkwidget

[clay stan]

Adam Borowski  于2021年8月31日周二 上午10:27写道：
>
> On Tue, Aug 31, 2021 at 09:12:52AM +0800, clay stan wrote:
> > Adam Borowski  于2021年8月30日周一 下午4:17写道：
> > > On Sat, Aug 28, 2021 at 08:12:20PM +0800, clay stan wrote:
> > > >  * Package name: dtkwidget
> > > >Version : 5.5.17.1-1~exp1
> > >
> > > >  dtkwidget (5.5.17.1-1~exp1) experimental; urgency=medium
> > > >  .
> > > >* New upstream version 5.5.17.1.
> > >
> > > Alas, this one needs its symbols updated.
> >
> > Are there any problems with the current symbols?
> > Compared with the previous version - 5.4.1-1~exp1, I have updated the
> > symbols file
> > And Lintian did not report any problems with symbols when I compiled it.
>
> Looks like your version of symbols is ok for gcc-10, but will fail for
> gcc-11.  I guess we can worry once gcc default is bumped.
>

Has rebuild and reupload to mentors.
After discussion, our team(pkg-deepin) decided to remove the symbols,
Because  all deepin packages are maintained by our team (pkg-deepin),
So symbols of dtk(deepin toolkit) projects are meaningless.

Thanks.

>
> Meow!
> --
> ⢀⣴⠾⠻⢶⣦⠀
> ⣾⠁⢠⠒⠀⣿⡁ If you ponder doing what Jesus did, remember than flipping tables
> ⢿⡄⠘⠷⠚⠋⠀ and chasing people with a whip is a prime choice.
> ⠈⠳⣄

Bug#993370: RFP: rg-el -- elpa-rg

[Nicholas D Steeves]

Control: owner -1 !
Control: retitle -1 ITP: rg-el -- elpa-rg: search tool for Emacs based on 
Ripgrep

> This ticket was actually requested by Nicholas, who's been working on
> packaging. I'm not sure how to make that an ITP for him, so I filed an
> RFP instead:
>
> https://salsa.debian.org/sten/rg-el
>

Thank you Antoine, much appreciated!

> Note that there are a *lot* of wrappers around ripgrep out
> there. Another commonly used one is deadgrep, which has a list of
> alternatives:
>
> https://github.com/Wilfred/deadgrep/blob/master/docs/ALTERNATIVES.md
>

Deadgrep would be my second choice (and is the second most popular on
MELPA), but also looks excellent :-)  Micah, I've CCed you since Antoine
mentioned you use Deadgrep, and because I'd be happy to answer any
questions you have about the process of debianising it.  I'm on holidays
so am working on this RFP in 30min sprints with a fairly scientific
method.  If you think the process might be interesting content for
Debian Planet, please let me know :-)

> I'm not actually sure why Nicholas picked rg.el.

I can update this bug with my rationale (from IRC) if you think it would
be useful to others.  P.S. I'm also curious if you'll end up enjoying
rg.el, or if you'll find it too fancy new school thing ;-)

Cheers,
Nicholas


signature.asc
Description: PGP signature

Bug#993343: OpenLDAP 2.5 FTBFS on GNU/Hurd: MAXPATHLEN undeclared

[Ryan Tandy]

The MAXPATHLEN failure has been fixed in the 2.5 branch. Still FTBFS 
though, the slapd code fails to compile on Hurd.


https://bugs.openldap.org/show_bug.cgi?id=9659

Bug#971324: zoneminder: uses deprecated libavresample

[peter green]

tags 971324 -bullseye
severity 971324 serious
thanks

The ffmpeg package no longer builds libavresample-dev, it is still present in
unstable as a cruft package but is completely gone from testing. So this
package's build-dependencies can no longer be satisfied in testing.

Bug#684431: python3-defaults: policy violation: dash in version number of native package

[Guillem Jover]

Control: user debian-d...@lists.debian.org
Control: usertags -1 dpkg-mismatch-source-vs-version-format

Hi!

On Wed, 2012-10-24 at 21:06:49 +0200, Matthias Klose wrote:
> tags 684431 + wontfix
> severity 684431 minor
> thanks

> these packages, and others like the gcc-4.x packages are split into the real 
> and
> the defaults packages and could be built from the same source again. I won't 
> use
> a version number which implies that this is a native package only.

This package uses a native source format, with a non-native version,
which is rather confusing (to unexperienced and experience packagers
alike) and subverts the semantics of both the source and version
formats. Which is a common source of accidental packaging bugs,
and makes handling of source packages more brittle by external tools.

This currently produces a lintian error, and with dpkg-dev 1.20.1 it
started producing warnings, but my intention is to eventually make
it error out, given the above.

Please, either use a non-native source format, or a native version,
so that these are coherent.

I do understand the appeal of the current usage in this package, as it
wants to represent the upstream versions faithfully. But there are
workable alternatives used by other similar default source packages:

  * Use a different revision separator, the common pattern would be to
use «+», but it could also be a string. This has the advantage
that it can be easily mapped and follows the current packaging
practice.
  * Use an independent version, and set the binary package versions
from debian/rules. For this package this would be more cumbersome
and probably confusing given the existing version scheme.
  * Switch to use a non-native source format.

Thanks,
Guillem

Bug#960268: Update to 3.1.0 or newer

[Paul W. Rankin]

On 2021-09-01 06:18, Nicholas D Steeves wrote:


Shipping a newer version with missing support for print output was a
functionality regression (within the context of the self-contained
Debian archive) that is, in my opinion, in no way appropriate for
Bullseye (Debian 11)--ditto for this year's Ubuntu LTS; It took me
longer than expected to find my notes on this!  Now that the two have
been released, and we're beginning a new cycle, I agree that now is the
time to ship a newer, more polished, yet with reduced functionality
version.


This is a mischaracterisation. The package never had print output. It 
could interface with an external tool directly for export, or it could 
convert Fountain to LaTeX, badly. But users still needed a full TeXLive 
installation and to interface with this (external tool) to create a PDF. 
A PDF created via LaTeX was always inferior to one created using an 
external tool directly.


The method of export to PDF was always via external tool, which has been 
improved in more recent versions.



But first, I'm going to file an RFP for Wrap, a Golang alternative to
Afterwriting that has a much more reasonable and manageable dependency
tree, and which I believe is a better fit for Debian due to its support
for non-English languages--it's been taking me far too long to get up 
to

speed with Golang packaging.  Sorry about that.  I also need to
apologise to Wrap's maintainer for missing that deadline :-$


Tying Fountain Mode to either Afterwriting or Wrap is not appropriate. 
It is designed to allow the user choice in which export tools (possibly 
multiple) to use. For example, I use Makefiles.

Bug#971328: nageru: uses deprecated libavresample

[peter green]

tags 971328 -bullseye
severity 971328 serious
thanks

The ffmpeg package no longer builds libavresample-dev, it is completely gone
from testing and while it is present in unstable as a cruft package, it is
uninstallable there due to dependency versions. So this package's
build-dependencies can no longer be satisfied in testing.

Bug#993421: sdl-kitchensink build-depends on removed package libavresample-dev

[peter green]

Source: sdl-kitchensink
Version: 1.0.9-2
Severity: serious
Tags: bookworm, sid

The ffmpeg package no longer builds libavresample-dev, it is completely gone
from testing and while it is present in unstable as a cruft package, it is
uninstallable there due to dependency versions. So this package's
build-dependencies can no longer be satisfied in testing.

Bug#993417: Installation failure on i386 system / Debian 11

[Craig Norborg]

I used software called "Rufus".   screen cap below of the options.  Same
exact drive when I did it with Ubuntu.

[image: image.png]

On Tue, Aug 31, 2021 at 6:29 PM Cyril Brulebois  wrote:

> Hi Craig,
>
> Craig Norborg  (2021-08-31):
> > Comments/Problems: I played around and could see the error
> > "/install.i386/vmlinuz not found".  Saw this in multiple places.
> >
> >  >   and ideas you had during the initial install.>  I was trying to
> > bring up a friends old machine with a decent OS, so I downloaded the
> > latest debian DVD image and put it on a thumb drive.   Would not
> > install.  Tried both the full install (shown above) and the live
> > image, both had issues.
>
> How did you deploy the downloaded image(s) to the thumb drive?
>
>
> Cheers,
> --
> Cyril Brulebois (k...@debian.org)
> D-I release manager -- Release team member -- Freelance Consultant
>

Bug#971322: sdl-kitchensink build-depends on removed package libavresample-dev

[peter green]

Source: sdl-kitchensink
Version: 1.0.9-2
Severity: serious
Tags: bookworm, sid

The ffmpeg package no longer builds libavresample-dev, it is completely gone
from testing and while it is present in unstable as a cruft package, it is
uninstallable there due to dependency versions. So this package's
build-dependencies can no longer be satisfied in testing.

Bug#971322: performous: uses deprecated libavresample

[peter green]

tags 971322 -bullseye
severity 971322 serious
thanks

The ffmpeg package no longer builds libavresample-dev, it is still present in
unstable as a cruft package but is completely gone from testing. So this
package's build-dependencies can no longer be satisfied in testing.

Bug#993390: virtuoso-opensource: FTBFS: Dkmarshal.c:50:11: fatal error: rpc/types.h: No such file or directory

[Boyuan Yang]

X-Debbugs-CC: sramac...@debian.org

Hi,

On Tue, 31 Aug 2021 18:41:01 +0200 Sebastian Ramacher 
wrote:
> Source: virtuoso-opensource
> Version: 7.2.5.1+dfsg1-0.1
> Severity: serious
> Tags: ftbfs sid bullseye
> Justification: fails to build from source (but built successfully in the
past)
> X-Debbugs-Cc: sramac...@debian.org
> 
> | libtool: compile:  gcc -DHAVE_CONFIG_H -I. -Wdate-time -D_FORTIFY_SOURCE=2
-fno-strict-aliasing -O2 -Wall -DNDEBUG -DPOINTER_64 -
I/<>/libsrc/Xml.new -DOPENSSL_NO_KRB5 -Dlinux -D_GNU_SOURCE -
DFILE64 -D_LARGEFILE64_SOURCE -I../../libsrc -g -O2 -ffile-prefix-
map=/<>=. -fstack-protector-strong -Wformat -Werror=format-
security -D_GNU_SOURCE -c Dkmem.c  -fPIC -DPIC -o .libs/libdksrv_la-Dkmem.o
> | Dkmarshal.c:50:11: fatal error: rpc/types.h: No such file or directory
> |    50 | # include 
> |   |   ^
> | compilation terminated.
> | make[5]: *** [Makefile:1169: libdksrv_la-Dkmarshal.lo] Error 1
> 
>
https://buildd.debian.org/status/fetch.php?pkg=virtuoso-opensource=arm64=7.2.5.1%2Bdfsg1-0.1%2Bb1=1630424102=0

Looks like a side effect of glibc/2.31-14 (Aug 17 2021):

  * debian/rules.d/build.mk: stop passing --enable-obsolete-rpc.

Also see
https://sources.debian.org/src/virtuoso-opensource/7.2.5.1+dfsg1-0.1/libsrc/Dk/Dkmarshal.c/#L49
:

##

#if defined (i386) || \
defined (_WIN64) || \
defined (_M_IX86) || \
defined (_M_ALPHA) || \
defined (mc68000) || \
defined (sparc) || \
defined (__x86_64) || \
defined (__alpha) || \
defined (__powerpc) || \
defined (mips) || \
defined (__OS2__) || \
defined (_IBMR2)
# define _IEEE_FLOATS
#elif defined (OPL_SOURCE)
# include 
#else
# include 
# include 
#endif

#

-- 
Thanks,
Boyuan Yang


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

Bug#971319: aubio: uses deprecated libavresample

[peter green]

tags 971319 -bullseye
severity 971319 serious
thanks

The ffmpeg package no longer builds libavresample-dev, it is still present in
unstable as a cruft package but is completely gone from testing. So this
package's build-dependencies can no longer be satisfied in testing.

Bug#993420: python-defaults: Mismatched source format vs source version

[Guillem Jover]

Source: python-defaults
Source-Version: 2.7.18-3
Severity: important
User: debian-d...@lists.debian.org
Usertags: dpkg-mismatch-source-vs-version-format

Hi!

This package uses a native source format, with a non-native version,
which is rather confusing (to unexperienced and experience packagers
alike) and subverts the semantics of both the source and version
formats. Which is a common source of accidental packaging bugs,
and makes handling of source packages more brittle by external tools.

This currently produces a lintian error, and with dpkg-dev 1.20.1 it
started producing warnings, but my intention is to eventually make
it error out, given the above.

Please, either use a non-native source format, or a native version,
so that these are coherent.

I do understand the appeal of the current usage in this package, as it
wants to represent the upstream versions faithfully. But there are
workable alternatives used by other similar default source packages:

  * Use a different revision separator, the common pattern would be to
use «+», but it could also be a string. This has the advantage
that it can be easily mapped and follows the current packaging
practice.
  * Use an independent version, and set the binary package versions
from debian/rules. For this package this would be more cumbersome
and probably confusing given the existing version scheme.
  * Switch to use a non-native source format.

Thanks,
Guillem

Bug#993417: Installation failure on i386 system / Debian 11

[Steve McIntyre]

Hi Craig,

On Tue, Aug 31, 2021 at 06:05:25PM -0600, Craig Norborg wrote:
>
>Package: installation-reports
>
>Boot method: USB stick
>Image version: 
>https://cdimage.debian.org/debian-cd/current/i386/iso-dvd/debian-11.0.0-i386-DVD-1.iso
>Date: 8/31/21 5:50PM MST
>Machine: Dell Dimension 8400
>Processor: Pentium 4
>Memory: 2Gb
>Partitions: ?
>Output of lspci -knn (or lspci -nn): ?
>
>Base System Installation Checklist:
>[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it
>
>Initial boot:   [ ]
>Detect network card:[ ]
>Configure network:  [ ]
>Detect media:   [ ]
>Load installer modules: [ ]
>Detect hard drives: [ ]
>Partition hard drives:  [ ]
>Install base system:[e ]
>Clock/timezone setup:   [ ]
>User/password setup:[ ]
>Install tasks:  [ ]
>Install boot loader:[e ]
>Overall install:[e ]
>
>Comments/Problems: I played around and could see the error 
>"/install.i386/vmlinuz not found".  Saw this in multiple places.
>
>  and ideas you had during the initial install.>
>
>I was trying to bring up a friends old machine with a decent OS, so I
>downloaded the latest debian DVD image and put it on a thumb drive. 
> Would not install.  Tried both the full install (shown above) and
>the live image, both had issues.
>
>I then went and downloaded a copy of ubuntu 17.04, and it installed
>fine, although it kind of sucks.  But, I'm assuming that if it would
>install ok, that Debian should have installed if it wasn't for the
>error.

I'm curious why the installation system is not finding things. Can you
explain exactly how you wrote the image to the USB drive please?

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
'There is some grim amusement in watching Pence try to run the typical
 "politician in the middle of a natural disaster" playbook, however
 incompetently, while Trump scribbles all over it in crayon and eats some
 of the pages.'   -- Russ Allbery

Bug#993417: Installation failure on i386 system / Debian 11

[Cyril Brulebois]

Hi Craig,

Craig Norborg  (2021-08-31):
> Comments/Problems: I played around and could see the error
> "/install.i386/vmlinuz not found".  Saw this in multiple places.
> 
>and ideas you had during the initial install.>  I was trying to
> bring up a friends old machine with a decent OS, so I downloaded the
> latest debian DVD image and put it on a thumb drive.   Would not
> install.  Tried both the full install (shown above) and the live
> image, both had issues.

How did you deploy the downloaded image(s) to the thumb drive?


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


signature.asc
Description: PGP signature

Bug#993419: user-mode-linux-doc: Mismatched source format vs source version

[Guillem Jover]

Source: user-mode-linux-doc
Source-Version: 20060501-3.1
Severity: important
User: debian-d...@lists.debian.org
Usertags: dpkg-mismatch-source-vs-version-format

Hi!

This package uses a native source format, with a non-native version,
which is rather confusing and subverts the semantics of both the
source and version formats.

This currently produces a lintian error, and with dpkg-dev 1.20.1 it
started producing warnings, but my intention is to eventually make
it error out, given the above, and because this is a common source of
this kind of accidental packaging bug.

Please, either use a non-native source format, or a native version,
so that these are coherent.

From the historical data in snapshot.debian.org, this would appear as
the build was done with a missing orig so dpkg-source considered it a
native format? I'd recommend switching to source format «3.0 (quilt)»
where this kind of accident cannot happen.

Thanks,
Guillem

Bug#993418: gdb-avr: Mismatched source format vs source version

[Guillem Jover]

Source: gdb-avr
Source-Version: 7.7-4.1
Severity: important
User: debian-d...@lists.debian.org
Usertags: dpkg-mismatch-source-vs-version-format

Hi!

This package uses a native source format, with a non-native version,
which is rather confusing and subverts the semantics of both the
source and version formats.

This currently produces a lintian error, and with dpkg-dev 1.20.1 it
started producing warnings, but my intention is to eventually make
it error out, given the above, and because this is a common source of
this kind of accidental packaging bug.

Please, either use a non-native source format, or a native version,
so that these are coherent.

From the historical data in snapshot.debian.org, this would appear as
the build was done with a missing orig so dpkg-source considered it a
native format? I'd recommend switching to source format «3.0 (quilt)»
where this kind of accident cannot happen.

Thanks,
Guillem

Bug#993416: netselect: Mismatched source format vs source version

[Guillem Jover]

Source: netselect
Source-Version: 0.3.ds1-29
Severity: important
User: debian-d...@lists.debian.org
Usertags: dpkg-mismatch-source-vs-version-format

Hi!

This package uses a native source format, with a non-native version,
which is rather confusing and subverts the semantics of both the
source and version formats.

This currently produces a lintian error, and with dpkg-dev 1.20.1 it
started producing warnings, but my intention is to eventually make
it error out.

Please, either use a non-native source format, or a native version,
so that these are coherent.

From the historical data in snapshot.debian.org, this would appear as
the build was done with a missing orig so dpkg-source considered it a
native format? I'd recommend switching to source format «3.0 (quilt)»
where this kind of accident cannot happen.

Thanks,
Guillem

Bug#993415: libpinyin: Switch from Berkeley DB to Kyotocabinet?

[Boyuan Yang]

Source: libpinyin
Version: 2.6.0-1
Severity: normal
Tags: sid bookworm
X-Debbugs-CC: czc...@debian.org alexep...@gmail.com

Dear Debian Input Method team members,

Currently libpinyin in Debian is using Berkeley DB (libdb-dev). After the
release of Debian 11, Debian has a release goal proposal to remove Berkeley DB
due to its problematic AGPLv3 license issue (for details, see
https://bugs.debian.org/987013 ).

It seems that libpinyin also supports Keyto Cabinet as DBM. I believe we
should consider switching to it to avoid dependency on Berkeley DB. It may
also solve some old problems such
as 
https://tests.reproducible-builds.org/debian/issues/unstable/berkeley_db_variation_requiring_further_investigation_issue.html
and
https://tests.reproducible-builds.org/debian/issues/unstable/randomness_in_files_generated_by_pinyin_gen_binary_files_issue.html
.

However, I am not sure what would users experience when database format is
switched (e.g., will all data previously stored in old db be lost? Is that a
severe issue?). Even with such side effect, I believe the benefit would be
more significant and we should perform the switch within current development
cycle.

P.S. I am also aware of https://github.com/libpinyin/libpinyin/issues/140 ,
and tkrzw is being reviewed by Debian FTP Masters at
https://ftp-master.debian.org/new/tkrzw_1.0.0+dfsg1-1.html .

-- 
Thanks,
Boyuan Yang


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

Bug#993414: php-ps: Mismatched source format vs source version

[Guillem Jover]

Source: php-ps
Source-Version: 1.4.1+pecl+nophp8+1.3.7-2
Severity: important
User: debian-d...@lists.debian.org
Usertags: dpkg-mismatch-source-vs-version-format

Hi!

This package uses a native source format, with a non-native version,
which is rather confusing and subverts the semantics of both the
source and version formats.

This currently produces a lintian error, and with dpkg-dev 1.20.1 it
started producing warnings, but my intention is to eventually make
it error out.

Please, either use a non-native source format, or a native version,
so that these are coherent.

From the historical data in snapshot.debian.org, this would appear as
the build was done with a missing orig so dpkg-source considered it a
native format?

Thanks,
Guillem

Bug#993413: python3.9-minimal: replace "which" by "command -v" in postinst script

[Vincent Lefevre]

Package: python3.9-minimal
Version: 3.9.7-1
Severity: minor

The /var/lib/dpkg/info/python3.9-minimal.postinst script gives the
following warning:

Setting up python3.9-minimal (3.9.7-1) ...
/usr/bin/which: this version of `which' is deprecated; use `command -v' in 
scripts instead.

due to

if which update-binfmts >/dev/null; then
update-binfmts --import python3.9
fi

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

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

Versions of packages python3.9-minimal depends on:
ii  libc6 2.31-17
ii  libexpat1 2.2.10-2
ii  libpython3.9-minimal  3.9.7-1
ii  zlib1g1:1.2.11.dfsg-2

Versions of packages python3.9-minimal recommends:
ii  python3.9  3.9.7-1

Versions of packages python3.9-minimal suggests:
ii  binfmt-support  2.2.1-1

-- no debconf information

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

Bug#993362: cloud.debian.org: cloud-init doesnt run dhclient for IPv6

[Noah Meyerhans]

On Tue, Aug 31, 2021 at 12:20:31PM +, Jeremy Stanley wrote:
> On 2021-08-31 10:54:02 + (+), Anton Scharnowski wrote:
> [...]
> > We run an OpenStack platform. The Issue leads to no IPv6 capabilty
> > on the VM until you manually execute a DHCPv6 request.
> [...]
> 
> As an aside, do note that whether IPv6 connectivity requires DHCPv6
> depends on how OpenStack is configured to deliver it. Not all
> OpenStack deployments rely on DHCPv6 to configure IPv6 addresses. It
> could instead communicate them to cloud-init via network_data.json
> in a configdrive, for example.

There are known issues with IPv6 configuration in the bullseye generic
cloud images.  See
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=991613 and the
attempted solution to it in
https://salsa.debian.org/cloud-team/debian-cloud-images/-/merge_requests/262
and the subsequent revert commit in
https://salsa.debian.org/cloud-team/debian-cloud-images/-/merge_requests/265

Part of the issue is that the network configuration framework used in
the cloud images (ifupdown) isn't very good at handling the various
different combinations of possible configurations options (IPv4-only,
dualstack, v6-only).  See #804396 ("if IPv6 configuration fails, then
IPv4 is not configured"), which is tagged wontfix, for example.

> Also this is probably not an OpenStack-specific problem, and would
> likely arise in other environments expecting to configure IPv6 via
> DHCP with the Bullseye cloud images.

It sort of is specific to OpenStack, at least within the context of the
cloud images.  The reason for that is that our OpenStack users expect to
be able to pass network configuration to instances via config drives,
which involves cloud-init.  In order to facilitate this, we let
cloud-init handle network configuration.  In other cloud environments,
network configuration is always provided by DHCP, and cloud-init is not
involved in network configuration.  This has let us implement a
workaround for ifupdown's inflexibility using some custom udev event
handlers.

A possible near-term solution to this situation might be to teach
cloud-init to generate interface config fragments with the "try_dhcp"
option that we use in other environments.  That would let cloud-init
continue to handle network configuration while also ensuring that the
right thing happens in various different environments.

Longer term, the solution is to stop relying on ifupdown.

noah

Bug#993208: js8call: TX broken

[Levente]

On 8/31/21 5:56 PM, Christoph Berg wrote:

js8call works here. It uses Qt for the audio handling (redirecting to
pulseaudio or jack), so I don't think anything in js8call is at fault
here, but rather some generic (Qt?) audio issue.

Does wsjtx work on that machine? I believe uses audio in a similar
way.


Hi Christoph,


Wsjtx has similar malfunction as js8call on my box.

This installation is an upgrade from previous release of Debian, more 
precisely MX Linux 19.4. At this point I think something was broken at 
the upgrade.


If you have some thoughts what to reinstall, I try it. If you don't, I 
install a fresh copy of bullseye, and see if I still have the issue.



Levente

Bug#993336: libclass-trait-perl: arch:all but depends on perlapi-5.32.0

[Alexander Zangerl]

On Tue, 31 Aug 2021 00:53:09 +0300, Niko Tyni writes:
>Package: libclass-trait-perl

i've requested removal of that package (#993410).

regards
az


-- 
Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + http://snafu.priv.at/
In German, a young lady has no sex, while a turnip has. Think what 
overwrought reverence that shows for the turnip, and what callous 
disrespect for the girl. -- Mark Twain


signature.asc
Description: Digital Signature

Bug#993412: netatalk: Switch to tracker 3

[Jeremy Bicha]

Source: netatalk
Version: 3.1.12~ds-8
Severity: serious
Control: block 993052 by -1

We have begun the transition from tracker 2 to tracker 3. Please
update your package for this transition.

Your salsa repo is not open for merge proposals, but you can grab the
top 3 commits from
https://salsa.debian.org/laney/netatalk/-/commits/wip/tracker3

Thanks,
Jeremy Bicha

Bug#993410: RM: libclass-trait-perl -- ROM; deprecated upstream, development ceased ages ago

[Alexander Zangerl]

Package: ftp.debian.org
Severity: normal


i'd like to request the removal of libclass-trait-perl from debian.
it's marked as deprecated and dead by upstream, and only libtm-perl needs it
and i've requested removal of that package, too.

Bug#993411: RM: libtm-perl -- ROM; ancient, buggy, development has ceased

[Alexander Zangerl]

Package: ftp.debian.org
Severity: normal


i'd like to request that libtm-perl be removed from debian.
upstream has stopped working on the code ages ago, it's somewhat incomplete
and buggy and not worth bothering with anymore. topicmaps as a concept are dead.

Bug#956283: installation-reports: kinda successful installation, but issues with firmware

[Holger Wansing]

Hi,

Bob McGowan  wrote (Mon, 30 Aug 2021 22:39:32 -0700):
> Package: installation-reports
> Followup-For: Bug #956283
> X-Debbugs-Cc: ramjr0...@gmail.com
> 
> Installation and reboot completed successfully, but running the new system 
> failed on login to the GUI, due to
> missing firmware.
> 
> I needed to install two firmware packages in order to successfully login 
> through the GUI:
> 
>   firmware-amd-graphics
>   firmware-misc-nonfree

Which image did you use?

If you used one of the official installation images, it is expected that
firmware is not installed automatically.

However, if you used an unofficial image with firmware included
(from 
https://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/ )
that should have happened automatically.
In this case, could you please provide us the installation logs (from
/var/log/installer on your installed system; sent compressed to this bug, 
please).


Holger


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#989705: Suspend to RAM hangs computer with nouveau driver and kernel 5.10.0-7-amd64 / 5.10.0-8-amd64

[Achille L]

Hello,

I suppose I have identified that the issue was related to the
activation of the config parameter CONFIG_INIT_ON_ALLOC_DEFAULT_ON=y
in Debian Kernel 5.10.0-8-amd64 from Debian Bullseye 11.0 (it was
disabled in the Debian kernel 4.19.0 from Debian Buster 10.11). This
parameter was activated in Debian with linux (5.8.3-1~exp1)
experimental on Mon, 24 Aug 2020 01:23:22 +0100 (see
https://metadata.ftp-master.debian.org/changelogs//main/l/linux/linux_5.10.46-4_changelog)

I discovered it bisecting (by hand) the diff of a working kernel
config file for Debian Kernel 5.10.0-8-amd64 (generated by me from
Debian kernel source code with make makeoldconfig using as template
the Debian kernel config-4.19.0-11-amd64) and the default kernel
config file from stock Debian Kernel 5.10.0-8-amd64 (see attachment);
the "hunk" of the diff that I detected was the number 151:

--- linux-source-5.10/.config   2021-08-13 17:24:22.386243765 +0200
+++ /boot/config-5.10.462021-08-01 10:27:12.0 +0200
@@ -9063,7 +9063,7 @@
 # Memory initialization
 #
 CONFIG_INIT_STACK_NONE=y
-CONFIG_INIT_ON_ALLOC_DEFAULT_ON=y
+# CONFIG_INIT_ON_ALLOC_DEFAULT_ON is not set
 # CONFIG_INIT_ON_FREE_DEFAULT_ON is not set
 # end of Memory initialization
 # end of Kernel hardening options

To verify this finding, I configured grub to start the kernel with the
parameter init_on_alloc=0:

# If you change this file, run 'update-grub' afterwards to update
# /boot/grub/grub.cfg.
# For full documentation of the options in this file, see:
#   info -f grub -n 'Simple configuration'

GRUB_DEFAULT=0
GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
GRUB_CMDLINE_LINUX_DEFAULT="no_console_suspend nouveau.debug=warn
init_on_alloc=0"
[...missing...]

After that, of course, I update the grub with kernel boot
configuration with the command:

update-grub2

The test with the stock Debian Bullseye (11.0) Kernel 5.10.0-8-amd64
was successful: I'm repeatedly able to suspend to ram and suspend to
disk with parameter init_on_alloc set to 0 with the same kernel that
freeze with init_on_alloc set to 1. I haven't deepened yet in kernel
source code, but in theory the kernel feature activated by this
parameter [1] (erase area of newly allocated memory) could have side
effects with the buffer handling/eviction of memory from video memory
to system memory during suspend to ram or suspend to disk.

You could give it a try, even if your GPU is two year younger then
mine (but they use the same nv50 kernel drm module).

Let me know.

[1] 
https://patchwork.kernel.org/project/linux-security-module/patch/20190626121943.131390-2-gli...@google.com/
--- linux-source-5.10/.config	2021-08-13 17:24:22.386243765 +0200
+++ /boot/config-5.10.46	2021-08-01 10:27:12.0 +0200
@@ -22,8 +22,8 @@
 CONFIG_INIT_ENV_ARG_LIMIT=32
 # CONFIG_COMPILE_TEST is not set
 CONFIG_LOCALVERSION=""
-# CONFIG_LOCALVERSION_AUTO is not set
-CONFIG_BUILD_SALT="5.10.0-8-amd64"
+CONFIG_LOCALVERSION_AUTO=y
+CONFIG_BUILD_SALT="4.19.0-11-amd64"
 CONFIG_HAVE_KERNEL_GZIP=y
 CONFIG_HAVE_KERNEL_BZIP2=y
 CONFIG_HAVE_KERNEL_LZMA=y
@@ -114,8 +114,7 @@
 CONFIG_TASK_DELAY_ACCT=y
 CONFIG_TASK_XACCT=y
 CONFIG_TASK_IO_ACCOUNTING=y
-CONFIG_PSI=y
-# CONFIG_PSI_DEFAULT_DISABLED is not set
+# CONFIG_PSI is not set
 # end of CPU/Task time and stats accounting
 
 CONFIG_CPU_ISOLATION=y
@@ -168,7 +167,7 @@
 CONFIG_CGROUP_PIDS=y
 CONFIG_CGROUP_RDMA=y
 CONFIG_CGROUP_FREEZER=y
-CONFIG_CGROUP_HUGETLB=y
+# CONFIG_CGROUP_HUGETLB is not set
 CONFIG_CPUSETS=y
 CONFIG_PROC_PID_CPUSET=y
 CONFIG_CGROUP_DEVICE=y
@@ -235,12 +234,11 @@
 CONFIG_KALLSYMS_ALL=y
 CONFIG_KALLSYMS_ABSOLUTE_PERCPU=y
 CONFIG_KALLSYMS_BASE_RELATIVE=y
-CONFIG_BPF_LSM=y
+# CONFIG_BPF_LSM is not set
 CONFIG_BPF_SYSCALL=y
 CONFIG_ARCH_WANT_DEFAULT_BPF_JIT=y
 # CONFIG_BPF_JIT_ALWAYS_ON is not set
 CONFIG_BPF_JIT_DEFAULT_ON=y
-CONFIG_BPF_UNPRIV_DEFAULT_OFF=y
 # CONFIG_BPF_PRELOAD is not set
 CONFIG_USERFAULTFD=y
 CONFIG_ARCH_HAS_MEMBARRIER_SYNC_CORE=y
@@ -321,7 +319,7 @@
 CONFIG_X86_MPPARSE=y
 # CONFIG_GOLDFISH is not set
 CONFIG_RETPOLINE=y
-CONFIG_X86_CPU_RESCTRL=y
+# CONFIG_X86_CPU_RESCTRL is not set
 # CONFIG_X86_EXTENDED_PLATFORM is not set
 CONFIG_X86_INTEL_LPSS=y
 CONFIG_X86_AMD_PLATFORM_DEVICE=y
@@ -376,11 +374,11 @@
 CONFIG_HPET_EMULATE_RTC=y
 CONFIG_DMI=y
 CONFIG_GART_IOMMU=y
-CONFIG_MAXSMP=y
-CONFIG_NR_CPUS_RANGE_BEGIN=8192
-CONFIG_NR_CPUS_RANGE_END=8192
-CONFIG_NR_CPUS_DEFAULT=8192
-CONFIG_NR_CPUS=8192
+# CONFIG_MAXSMP is not set
+CONFIG_NR_CPUS_RANGE_BEGIN=2
+CONFIG_NR_CPUS_RANGE_END=512
+CONFIG_NR_CPUS_DEFAULT=64
+CONFIG_NR_CPUS=512
 CONFIG_SCHED_SMT=y
 CONFIG_SCHED_MC=y
 CONFIG_SCHED_MC_PRIO=y
@@ -412,7 +410,7 @@
 CONFIG_MICROCODE=y
 CONFIG_MICROCODE_INTEL=y
 CONFIG_MICROCODE_AMD=y
-# CONFIG_MICROCODE_OLD_INTERFACE is not set
+CONFIG_MICROCODE_OLD_INTERFACE=y
 CONFIG_X86_MSR=m
 CONFIG_X86_CPUID=m
 # CONFIG_X86_5LEVEL is not set
@@ -423,7 +421,7 @@
 CONFIG_AMD_NUMA=y
 CONFIG_X86_64_ACPI_NUMA=y
 CONFIG_NUMA_EMU=y

Bug#993409: digikam: Please package digikam 7.3

[Eric Valette]

Package: digikam
Version: 4:7.1.0-2+b1
Severity: wishlist

Rebuilding is fine to cope with kdepim, but making an uptodate version is even 
better.


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

Kernel: Linux 5.10.61 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=fr_FR.UTF8, LC_CTYPE=fr_FR.UTF8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages digikam depends on:
ii  digikam-data  4:7.1.0-2
ii  digikam-private-libs  4:7.1.0-2+b1
ii  libc6 2.32-0experimental1
ii  libgcc-s1 11.2.0-3
ii  libkf5configcore5 5.85.0-2
ii  libkf5coreaddons5 5.85.0-2
ii  libkf5i18n5   5.85.0-2
ii  libmagick++-6.q16-8   8:6.9.11.60+dfsg-1.3
ii  libqt5core5a  5.15.2+dfsg-10
ii  libqt5gui55.15.2+dfsg-10
ii  libqt5sql55.15.2+dfsg-10
ii  libqt5sql5-mysql  5.15.2+dfsg-10
ii  libqt5sql5-sqlite 5.15.2+dfsg-10
ii  libqt5widgets55.15.2+dfsg-10
ii  libstdc++611.2.0-3
ii  perl  5.32.1-5

Versions of packages digikam recommends:
ii  ffmpegthumbs4:21.08.0-1
ii  firefox-esr [www-browser]   91.0.1esr-1
ii  google-chrome-stable [www-browser]  93.0.4577.63-1
ii  konqueror [www-browser] 4:21.08.0-1
ii  links2 [www-browser]2.23-1
ii  lynx [www-browser]  2.9.0dev.9-2
ii  w3m [www-browser]   0.5.3+git20210102-6

Versions of packages digikam suggests:
pn  digikam-doc 
ii  systemsettings  4:5.21.5-2

-- no debconf information

Bug#989727: RM: gnome-getting-started-docs -- ROM; archived upstream

[Gunnar Hjalmarsson]

On 2021-06-11 13:01, Gunnar Hjalmarsson wrote:

$ apt rdepends gnome-getting-started-docs
gnome-getting-started-docs
Reverse Depends:
   Depends: gnome (>= 3.36)
   Recommends: gnome-initial-setup

Those dependencies have been dropped in respective repo, but they
must make it to unstable before the removal can be accomplished.


Want to mention that those dependencies have been dropped in unstable 
and testing now.


--
Gunnar Hjalmarsson

Bug#960268: clone bug and split b/t import new version and restore print export

[Nicholas D Steeves]

clone 12345 -1
retitle -1 fountain-mode: restore print export functionality
unblock 960268 by 960269
thanks


signature.asc
Description: PGP signature

Bug#960268: Update to 3.1.0 or newer

[Nicholas D Steeves]

David Bremner  writes:

> Nicholas D Steeves  writes:
>
>> Package: elpa-fountain-mode
>> Severity: normal
>>
>> Fountain-mode is out of date.  I have not imported the new series yet,
>> because it drops support for exporting to PDF.  Afterwriting looks
>> like a viable replacement for this functionality.  Afterwriting 
>> functionality exposed to Emacs should at least be equivalent to Atom's 
>> implementation:
>>
>>   https://atom.io/packages/fountain
>
> Hi Nicholas;
>
> If PDF export is a dealbreaker for you maintaining the package, please
> orphan it; if no-one picks it up and updates it we can remove it per
> Paul's request.
>

Shipping a newer version with missing support for print output was a
functionality regression (within the context of the self-contained
Debian archive) that is, in my opinion, in no way appropriate for
Bullseye (Debian 11)--ditto for this year's Ubuntu LTS; It took me
longer than expected to find my notes on this!  Now that the two have
been released, and we're beginning a new cycle, I agree that now is the
time to ship a newer, more polished, yet with reduced functionality
version.

But first, I'm going to file an RFP for Wrap, a Golang alternative to
Afterwriting that has a much more reasonable and manageable dependency
tree, and which I believe is a better fit for Debian due to its support
for non-English languages--it's been taking me far too long to get up to
speed with Golang packaging.  Sorry about that.  I also need to
apologise to Wrap's maintainer for missing that deadline :-$

Paul, as communicated previously, the deadline for completing that work
was 2021-02-12 (https://release.debian.org/bullseye/freeze_policy.html),
and I wasn't able to learn Debian Golang packaging quickly enough.  To
give the ftpmasters time to review all the new dependencies would have
pushed the deadline closer to 2021-01-12 or even 2020-12-12.

Other than the RFP for Wrap, I'll update NEWS.Debian file to note the
regression and document the RFP bugs, and then the new Fountain-mode
release can be quickly prepared for upload.

Best,
Nicholas


signature.asc
Description: PGP signature

Bug#993407: npm: CVE-2021-39134

[Salvatore Bonaccorso]

Source: npm
Version: 7.5.2+ds-2
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for npm.

CVE-2021-39135[0]:
| `@npmcli/arborist`, the library that calculates dependency trees and
| manages the node_modules folder hierarchy for the npm command line
| interface, aims to guarantee that package dependency contracts will be
| met, and the extraction of package contents will always be performed
| into the expected folder. This is accomplished by extracting package
| contents into a project's `node_modules` folder. If the `node_modules`
| folder of the root project or any of its dependencies is somehow
| replaced with a symbolic link, it could allow Arborist to write
| package dependencies to any arbitrary location on the file system.
| Note that symbolic links contained within package artifact contents
| are filtered out, so another means of creating a `node_modules`
| symbolic link would have to be employed. 1. A `preinstall` script
| could replace `node_modules` with a symlink. (This is prevented by
| using `--ignore-scripts`.) 2. An attacker could supply the target with
| a git repository, instructing them to run `npm install --ignore-
| scripts` in the root. This may be successful, because `npm install
| --ignore-scripts` is typically not capable of making changes outside
| of the project directory, so it may be deemed safe. This is patched in
| @npmcli/arborist 2.8.2 which is included in npm v7.20.7 and above. For
| more information including workarounds please see the referenced GHSA-
| gmw6-94gg-2rc2.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2021-39135
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-39135
[1] https://github.com/npm/arborist/security/advisories/GHSA-2h3h-q99f-3fhc

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#991998: gparted segfaults if scrolling quickly the device dropdown list

[Mike Fleetwood]

Just by chance I came across this bug report.  I have confirmed the bug
and raised it upstream.

  GParted issue 165 - "GParted segfaults if scrolling quickly in the
device dropdown"
  https://gitlab.gnome.org/GNOME/gparted/-/issues/165

Thanks,
Mike Fleetwood (GParted Developer)

Bug#993406: bullseye-pu: package king/2.23.161103+dfsg1-4

[Pierre Gruet]

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

[ Reason ]
The package got a bug report (#992092, "contains a file with a non-free
"disparaging to Sun" license") with severity "serious" on August 11th.

The bug is linked to 12 icons, in the source package and that appear in the
GUI, that have a non-free license. Those icons have been present for a very
long time, presumably in jessie or even before.

The fix was uploaded to unstable on August 26th in version 2.23.161103+dfsg2-1
which is about to migrate to testing.

[ Impact ]
If the update is not approved, the user will have a software that is
definitely usable but with non-free icons in the GUI.

[ Tests ]
- The proposed package was successfully built in a bullseye chroot;
- I installed it on my machine running bullseye and I saw all the DFSG-free
  icons were successfully showing up. I tested a good part of the software
  functionalities and everything looks nice.

[ Risks ]
Nothing (build-)depends on king, so I guess the risks are extremely low.

[ 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 ]
- I have repacked without the non-free icons and included DFSG-free replacement
  icons created by me.
- inkscape is used to convert my .svg icons to .png that can be used by the
  software.
- d/rules and a patch have been updated to ensure the new icons can be included
  at build time.
- I added copyright information about the new DFSG-free icons in d.copyright.

[ Other info ]
Thank you for your help on this.

Best,

-- 
Pierre Gruet
diff -Nru king-2.23.161103+dfsg1/debian/changelog 
king-2.23.161103+dfsg2/debian/changelog
--- king-2.23.161103+dfsg1/debian/changelog 2020-12-04 15:54:20.0 
+0100
+++ king-2.23.161103+dfsg2/debian/changelog 2021-08-26 22:31:48.0 
+0200
@@ -1,3 +1,23 @@
+king (2.23.161103+dfsg2-1~deb11u1) bullseye; urgency=medium
+
+  * Team upload.
+  * Rebuild for bullseye, reverting changes of version 2.23.161103+dfsg2-1 that
+were not linked to bug #992092
+
+ -- Pierre Gruet   Thu, 26 Aug 2021 22:31:48 +0200
+
+king (2.23.161103+dfsg2-1) unstable; urgency=medium
+
+  * Team upload.
+  * New upstream version 2.23.161103+dfsg2
+  * Using new DFSG-free icons instead of the non-free ones (Closes: #992092)
+  * Raising Standards version to 4.6.0 (no change)
+  * Refreshing d/copyright
+  * Adding keywords in the debian/king.desktop file
+  * Marking Debian-specific patches as "Forwarded: not-needed"
+
+ -- Pierre Gruet   Thu, 26 Aug 2021 16:26:48 +0200
+
 king (2.23.161103+dfsg1-4) unstable; urgency=medium
 
   * Standards-Version: 4.5.1 (routine-update)
diff -Nru king-2.23.161103+dfsg1/debian/control 
king-2.23.161103+dfsg2/debian/control
--- king-2.23.161103+dfsg1/debian/control   2020-12-04 15:54:20.0 
+0100
+++ king-2.23.161103+dfsg2/debian/control   2021-08-26 22:28:58.0 
+0200
@@ -7,6 +7,7 @@
default-jdk,
javahelper,
ant,
+   inkscape,
libitext-java,
libjogl2-java
 Standards-Version: 4.5.1
diff -Nru king-2.23.161103+dfsg1/debian/copyright 
king-2.23.161103+dfsg2/debian/copyright
--- king-2.23.161103+dfsg1/debian/copyright 2020-12-04 15:54:20.0 
+0100
+++ king-2.23.161103+dfsg2/debian/copyright 2021-08-26 22:30:20.0 
+0200
@@ -18,6 +18,10 @@
 king*/doc/work/format-kinemage.pdf
 king*/1.x_src
 */buildnum.props
+king/doc/LICENSE-SUN
+king/resource/king/images/LICENSE
+king/resource/king/images/*16.gif
+king/resource/king/images/*24.gif
 
 Files: *
 Copyright: 2002-2011 Ian W. Davis ,
@@ -70,3 +74,433 @@
  On Debian systems the complete text of the Apache-2.0 license can be found at
  `/usr/share/common-licenses/Apache-2.0`.
 
+Files: debian/icons/*
+Copyright: 2021 Pierre Gruet 
+License: CC-BY-SA-4.0
+ CC Attribution-ShareAlike http://creativecommons.org/licenses/by-sa/4.0/
+ .
+ Attribution-ShareAlike 4.0 International
+ .
+ ===
+ .
+ Creative Commons Corporation ("Creative Commons") is not a law firm and
+ does not provide legal services or legal advice. Distribution of
+ Creative Commons public licenses does not create a lawyer-client or
+ other relationship. Creative Commons makes its licenses and related
+ information available on an "as-is" basis. Creative Commons gives no
+ warranties regarding its licenses, any material licensed under their
+ terms and conditions, or any related information. Creative Commons
+ disclaims all liability for damages resulting from their use to the
+ fullest extent possible.
+ .
+ Using Creative Commons Public 

Bug#993405: npm: CVE-2021-39135

[Salvatore Bonaccorso]

Source: npm
Version: 7.5.2+ds-2
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for npm.

CVE-2021-39135[0]:
| `@npmcli/arborist`, the library that calculates dependency trees and
| manages the node_modules folder hierarchy for the npm command line
| interface, aims to guarantee that package dependency contracts will be
| met, and the extraction of package contents will always be performed
| into the expected folder. This is accomplished by extracting package
| contents into a project's `node_modules` folder. If the `node_modules`
| folder of the root project or any of its dependencies is somehow
| replaced with a symbolic link, it could allow Arborist to write
| package dependencies to any arbitrary location on the file system.
| Note that symbolic links contained within package artifact contents
| are filtered out, so another means of creating a `node_modules`
| symbolic link would have to be employed. 1. A `preinstall` script
| could replace `node_modules` with a symlink. (This is prevented by
| using `--ignore-scripts`.) 2. An attacker could supply the target with
| a git repository, instructing them to run `npm install --ignore-
| scripts` in the root. This may be successful, because `npm install
| --ignore-scripts` is typically not capable of making changes outside
| of the project directory, so it may be deemed safe. This is patched in
| @npmcli/arborist 2.8.2 which is included in npm v7.20.7 and above. For
| more information including workarounds please see the referenced GHSA-
| gmw6-94gg-2rc2.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2021-39135
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-39135
[1] https://github.com/npm/arborist/security/advisories/GHSA-gmw6-94gg-2rc2

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#993404: mc: CVE-2021-36370

[Salvatore Bonaccorso]

Source: mc
Version: 3:4.8.26-1.1
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: found -1 3:4.8.22-1

Hi,

The following vulnerability was published for mc.

CVE-2021-36370[0]:
| An issue was discovered in Midnight Commander through 4.8.26. When
| establishing an SFTP connection, the fingerprint of the server is
| neither checked nor displayed. As a result, a user connects to the
| server without the ability to verify its authenticity.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2021-36370
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-36370
[1] 
https://github.com/MidnightCommander/mc/commit/9235d3c232d13ad7f973346077c9cf2eaa77dc5f

Regards,
Salvatore

Bug#993403: libobject-remote-perl: missing dependency on libstrictures-perl

[Niko Tyni]

Package: libobject-remote-perl
Version: 0.004001-1
Severity: serious
Tags: ftbfs sid bookworm

This package is missing a dependency on libstrictures-perl.

  % perl -e 'use Object::Remote'
  Can't locate strictures.pm in @INC (you may need to install the strictures 
module) (@INC contains: /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.32.1 
/usr/local/share/perl/5.32.1 /usr/lib/x86_64-linux-gnu/perl5/5.32 
/usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl-base 
/usr/lib/x86_64-linux-gnu/perl/5.32 /usr/share/perl/5.32 
/usr/local/lib/site_perl) at /usr/share/perl5/Object/Remote/Proxy.pm line 3.
 
Until recently this was masked by its dependency, libmoo-perl,
depending on libstrictures-perl, but that was removed in
libmoo-perl_2.005004-1.

The missing dependency causes test suite failures, making the package
fail to build from source and regress on ci.debian.net. The regressions
are blocking libmoo-perl_2.005004-1 from entering testing.

When this is fixed, libmoo-perl should declare a Breaks entry
on the old versions.
-- 
Niko Tyni   nt...@debian.org

Bug#993401: qemu: CVE-2021-3748: virtio-net: heap use-after-free in virtio_net_receive_rcu

[Salvatore Bonaccorso]

Source: qemu
Version: 1:6.1+dfsg-3
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for qemu, starting to track
it downstream for us, the reference comes from [1].

CVE-2021-3748[0]:
| virtio-net: heap use-after-free in virtio_net_receive_rcu

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2021-3748
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-3748
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1998514

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#861073: NMUing dpkg-cross

[Helmut Grohne]

Hi wookey,

you seem to be busy with non-dpkg-cross things and that's fine. The
package has a few filed bugs and other minor issues though and I'm
taking the liberty to NMU it in accordance with the LowNMU list you've
subscribed to. I'm attaching the full .debdiff of the performed changes.

Helmut
diff --minimal -Nru dpkg-cross-2.6.18+nmu1/config/cross-config.cache 
dpkg-cross-2.6.18+nmu2/config/cross-config.cache
--- dpkg-cross-2.6.18+nmu1/config/cross-config.cache2020-06-21 
21:30:02.0 +0200
+++ dpkg-cross-2.6.18+nmu2/config/cross-config.cache2021-08-28 
07:23:28.0 +0200
@@ -10,6 +10,11 @@
 # Common libc things - global until someone finds a reason not to
 ac_cv_func_malloc_0_nonnull=yes
 ac_cv_func_realloc_0_nonnull=yes
+
+# xorg variant of it
+test "$ac_cv_func_realloc_0_nonnull" = yes && xorg_cv_malloc0_returns_null=no
+test "$ac_cv_func_realloc_0_nonnull" = no && xorg_cv_malloc0_returns_null=yes
+
 # shadow
 ac_cv_func_setpgrp_void=yes
 
diff --minimal -Nru dpkg-cross-2.6.18+nmu1/debian/changelog 
dpkg-cross-2.6.18+nmu2/debian/changelog
--- dpkg-cross-2.6.18+nmu1/debian/changelog 2021-05-10 20:42:09.0 
+0200
+++ dpkg-cross-2.6.18+nmu2/debian/changelog 2021-08-28 07:23:28.0 
+0200
@@ -1,3 +1,22 @@
+dpkg-cross (2.6.18+nmu2) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+
+  [ Helmut Grohne ]
+  * Mark cross-config Multi-Arch: foreign.
+  * Reduce maintainer scripts:
++ Delete dpkg-cross.preinst.
++ Delete dpkg-cross.prerm.
++ Delete diversion cleanup from dpkg-cross.postinst.
+  * Declare compliance with policy 4.6.0.
++ Emit priority optional instead of extra in generated packages.
+  * cross-config: Set xorg_cv_malloc0_returns_null. (Closes: #861073)
+
+  [ YunQiang Su ]
+  * Support mips r6 dynamic linker. (Closes: #993059)
+
+ -- Helmut Grohne   Sat, 28 Aug 2021 07:23:28 +0200
+
 dpkg-cross (2.6.18+nmu1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff --minimal -Nru dpkg-cross-2.6.18+nmu1/debian/control 
dpkg-cross-2.6.18+nmu2/debian/control
--- dpkg-cross-2.6.18+nmu1/debian/control   2021-03-02 05:18:17.0 
+0100
+++ dpkg-cross-2.6.18+nmu2/debian/control   2021-08-28 07:23:28.0 
+0200
@@ -3,11 +3,12 @@
 Priority: optional
 Maintainer: Wookey 
 Build-Depends: cdbs, debhelper ( >=10 )
-Standards-Version: 4.5.1
+Standards-Version: 4.6.0
 Rules-Requires-Root: no
 
 Package: cross-config
 Architecture: all
+Multi-Arch: foreign
 Depends: ${misc:Depends}
 Breaks: dpkg-cross (<= 2.6.14)
 Replaces: dpkg-cross (<= 2.6.14)
diff --minimal -Nru dpkg-cross-2.6.18+nmu1/debian/dpkg-cross.postinst 
dpkg-cross-2.6.18+nmu2/debian/dpkg-cross.postinst
--- dpkg-cross-2.6.18+nmu1/debian/dpkg-cross.postinst   2016-07-12 
20:33:01.0 +0200
+++ dpkg-cross-2.6.18+nmu2/debian/dpkg-cross.postinst   2021-08-28 
07:23:28.0 +0200
@@ -23,32 +23,8 @@
 # installation fails and the `postinst' is called with `abort-upgrade',
 # `abort-remove' or `abort-deconfigure'.
 
-diverted="dpkg-buildpackage dpkg-shlibdeps"
-
 case "$1" in
 configure)
-# Remove diversion of dh_strip left from older versions of dpkg-cross
-if dpkg-divert --list /usr/bin/dh_strip | grep -q dpkg-cross; then
-# For some reason, dh_strip from older version of package is still
-# there at this point. Looks like dpkg does not delete file from
-# older version of a package if that file diverts another file ..
-# This causes funny things such as #237511 that don't seem to have
-# a good solution. Looks that the only way to make a sane upgrade
-# is to delete the file here - which is bad, I know, but IMHO
-# it's better than dpkg errors.
-test -e /usr/bin/dh_strip && test -e /usr/bin/dh_strip.orig &&
-rm -f /usr/bin/dh_strip
-dpkg-divert --package dpkg-cross --remove --rename \
---divert /usr/bin/dh_strip.orig \
-/usr/bin/dh_strip
-fi
-# dpkg-divert --package wibble --rename --remove /usr/bin/example
-for prog in $diverted; do
-if dpkg-divert --list /usr/bin/$prog | grep -q dpkg-cross; then
-dpkg-divert --package dpkg-cross --rename --remove \
-/usr/bin/$prog
-fi
-done
 if [ ! -f '/etc/dpkg-cross/cross-compile' ]; then
 cp /usr/share/dpkg-cross/cross-compile.sample 
/etc/dpkg-cross/cross-compile
 fi
diff --minimal -Nru dpkg-cross-2.6.18+nmu1/debian/dpkg-cross.preinst 
dpkg-cross-2.6.18+nmu2/debian/dpkg-cross.preinst
--- dpkg-cross-2.6.18+nmu1/debian/dpkg-cross.preinst2011-03-27 
08:14:10.0 +0200
+++ dpkg-cross-2.6.18+nmu2/debian/dpkg-cross.preinst1970-01-01 
01:00:00.0 +0100
@@ -1,46 +0,0 @@
-#! /bin/sh
-# preinst script for dpkg-cross
-#
-# see: dh_installdeb(1)
-
-set -e
-
-# summary of how this script can be called:
-#  

Bug#993400: mosquitto: CVE-2021-34434

[Salvatore Bonaccorso]

Source: mosquitto
Version: 2.0.11-1
Severity: important
Tags: security upstream
Forwarded: https://bugs.eclipse.org/bugs/show_bug.cgi?id=575324
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for mosquitto.

CVE-2021-34434[0]:
| In Eclipse Mosquitto versions 2.0 to 2.0.11, when using the dynamic
| security plugin, if the ability for a client to make subscriptions on
| a topic is revoked when a durable client is offline, then existing
| subscriptions for that client are not revoked.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2021-34434
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-34434
[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=575324

Regards,
Salvatore

Bug#993027: transition: knot 3.0 to 3.1

[Sebastian Ramacher]

On 2021-08-30 23:11:48 +0200, Sebastian Ramacher wrote:
> Control: tags -1 confirmed
> Control: forwarded -1 
> https://release.debian.org/transitions/html/auto-knot.html
> 
> On 2021-08-26 13:45:39 +, Jakub Ružička wrote:
> > Package: release.debian.org
> > Severity: normal
> > User: release.debian@packages.debian.org
> > Usertags: transition
> > 
> > Hello,
> > 
> > in order to update knot to latest 3.1.1, its only reverse dependency
> > knot-resolver needs to be updated to >= 5.4 which supports new
> > knot 3.1 API/ABI.
> > 
> > I've tested this in experimental - knot-resolver-5.4.1-1 built against
> > knot-3.1.1-3. Both packages have autopkgtests as well upstream tests
> > enabled.
> 
> Please go ahead

The upload included binaries for amd64 and all and won't be able to
migrate. Please perform a source-only upload.

Cheers

> 
> Cheers
> 
> > 
> > Ben file:
> > 
> > title = "knot";
> > is_affected = .depends ~ 
> > /\b(libknot12|libzscanner4|libknot11|libzscanner3)\b/;
> > is_good = .depends ~ /\b(libknot12|libzscanner4)\b/;
> > is_bad = .depends ~ /\b(libknot11|libzscanner3)\b/;
> > 
> > Thank you.
> > 
> > 
> > Cheers,
> > Jakub
> > 
> 
> -- 
> Sebastian Ramacher



-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#993399: libdatetimex-easy-perl: FTBFS: t/03-parse.t failure

[Niko Tyni]

Source: libdatetimex-easy-perl
Version: 0.089-2
Severity: serious
Tags: ftbfs sid bookworm patch
Forwarded: https://rt.cpan.org/Public/Bug/Display.html?id=137397

This package fails its test suite on current sid.

It broke with libdatetime-format-flexible-perl_0.34-1.

Petr Písař says in the upstream ticket that the libdatetimex-easy-perl
tests need to adapt and provides a patch there.

This is currently blocking the testing migration of the new
libdatetime-format-flexible-perl version because of regressions
on ci.debian.net.

>From 
>https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/libdatetimex-easy-perl.html

   #   Failed test at t/03-parse.t line 32.
   #  got: 'America/New_York'
   # expected: '-0500'
   # Looks like you failed 1 test of 18.
   
   [...]
   
   Test Summary Report
   ---
   t/01-basic.t   (Wstat: 0 Tests: 76 Failed: 0)
 TODO passed:   47-53
   t/03-parse.t   (Wstat: 256 Tests: 18 Failed: 1)
 Failed test:  6
 Non-zero exit status: 1
   Files=3, Tests=106,  3 wallclock secs ( 0.05 usr  0.02 sys +  2.17 cusr  
0.22 csys =  2.46 CPU)
   Result: FAIL
 
-- 
Niko Tyni   nt...@debian.org

Bug#975191: [Pkg-rust-maintainers] Bug#975191: re: rust-js-sys: FTBFS: dh_auto_test: error: /usr/share/cargo/bin/cargo build returned exit code 101

[Wolfgang Silbermayr]

On 8/31/21 4:25 PM, Bastian Germann wrote:
> On Wed, 2 Dec 2020 02:46:36 + peter green  wrote:
>>  > This will impact quite some other modules.
>>
>> I agree that the current autoremoval list looks pretty scary, so I decided
>> to do some
>> dependency analysis. It seems there are 5 source packages with direct or
>> indirect hard
>> dependencies on rust-js-sys.
>>
>> rust-www-sys
>> rust-ring
>> rust-rustls
>> rust-sct
>> rust-webpki
> 
> Hey,
> 
> I would like to get rustls migrating to bookworm but this is a blocker for it.
> Can you please state if you want to fix this or would like help with it? I
> guess importing the current version will do it.

Hi Bastian,

I'd be happy to support getting rustls to migrate as well.

After taking a look, "just" updating rust-js-sys to the latest version also
requires an update of the wasm-bindgen related crates to the latest version
(which currently is 0.2.76 across all of them):

wasm-bindgen-shared
wasm-bindgen-backend
wasm-bindgen-macro-support
wasm-bindgen-macro
wasm-bindgen

I did a quick test run updating all of these, and it basically works, once
`syn` got updated. For `syn`, we have an RFS note indicating that autopkgtests
don't work yet with the updated version and need some other packages such as
`insta` uploaded before. I didn't dig too deeply into that part, but we might
need to invest some additional work here.

Within the wasm-bindgen* group, I also stumbled over a few autopkgtest problems:

wasm-bindgen-macro-support has a few features that fail their tests, but I
expect that these tests simply aren't intended to be run with only a single
feature enabled. Would require some investigation and either fixing or marking
them as broken. The rest of the tests succeeds.

wasm-bindgen-macro requires wasm-bindgen to be available for the autopkgtest,
but it should be possible to handle that. In addition, it requires
wasm-bindgen-futures 0.4, some more about that below.

wasm-bindgen requires js-sys 0.3 to be available for the autopkgtest, but
again that can be handled.

js-sys requires wasm-bindgen-futures 0.4 for the autopkgtest as well.

Regarding wasm-bindgen-futures, that one has a dev dependency on
futures-channel-preview in a 0.3 alpha version. We can basically handle that,
but that crate received its last update about two years ago. At a quick look,
it seems to be a bootstrapping crate that might be intended to be replaced by
futures-channel which is available by now, but that didn't happen yet for
whichever reason. Might be a topic to investigate upstream. That one pulls in
futures-core 0.3, and thus requires an update of the futures ecosystem from
0.1 to 0.3 which by itself is a topic that is much larger than the
wasm-bindgen topic that I describe here. There was already some preparation
done by another team member, but I'm not sure when it was the last time
somebody took a thorough look at what they prepared.

I'd love to work on untangling these issues, but once I start working on such
a group of problematic packages, I usually discover blockers which stop my
undertaking, and due to being a DM, I need a DD to either grant me upload
access for the affected crates, or sponsor the upload for me, so it's quite
tedious to finish such a group of packages, with all the inconveniences that
come from the delays, such as packages failing to migrate for some time or
autopkgtests failing until the required dependencies become available. If it
was for me, we could go forward and upload the updates, but in the past it
didn't take long until we collected many reports about failing or skipped
autopkgtests.

That's what I can tell upfront from my quick evaluation, but speaking from
experience, I'd expect some unforeseen roadblock to show up when working on it.

I hope this quick analysis gives you some insight into the overall state, and
some idea where and how you would like to proceed. In case you need some
support working on a specific crate, let me know.

Best regards,
Wolfgang.

Bug#993330: polymake: FTBFS with Perl 5.34: error: ‘Perl_pp_keys’ was not declared in this scope

[Niko Tyni]

On Tue, Aug 31, 2021 at 10:48:41AM -0700, David Bremner wrote:
> Niko Tyni  writes:
> 
> > This package fails to build from source with Perl 5.34 (currently
> > in experimental). I don't presently understand why; I'm not aware of
> > changes to Perl_pp_keys or Perl_pp_rv2hv. So the root issue might also
> > be on the Perl side. At least it seems to reliably fail the same way.
> >
> 
> At least some of the build-deps [1] seem not to be rebuilt yet in
> experimental. Do you have an extra repo I should add?

Yes, see http://perl.debian.net/ .

> Alternatively you
> can try rebuilding against the polymake 4.4 in git [2].

Can do that but best not to block on me.

> [1]: libterm-readkey-perl libterm-readline-gnu-perl
> [2]: https://salsa.debian.org/bremner/polymake

-- 
Niko

Bug#992078: bullseye-pu: package libbluray/1:1.2.1-4+deb11u1

[Sebastian Ramacher]

On 2021-08-10 23:40:20 +0200, Sebastian Ramacher wrote:
> Package: release.debian.org
> Severity: normal
> Tags: bullseye
> User: release.debian@packages.debian.org
> Usertags: pu
> X-Debbugs-Cc: sramac...@debian.org
> 
> [ Reason ]
> The BDJ features of libbluray are currently broken due to an
> incompatibility with libasm-java from bullseye. This issue was reported
> as #991991 and is easily fixed by reverting to using the embedded copy
> of libasm.
> 
> [ Impact ]
> Users will be unable to play Blurays with BDJ.
> 
> [ Tests ]
> None, as I don't own a Bluray with BDJ.
> 
> [ Risks ]
> None, as far as I can tell. libbluray-bdj is known to work with the
> embedded copy of libasm.
> 
> [ 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 bullseye
>   [ ] the issue is verified as fixed in unstable
> 
> The issue is currently fixed in experimental and the fix will be
> available in unstable once bullseye is released.

The fix is now available in unstable (and bookworm) and I've also
uploaded 1:1.2.1-4+deb11u1 to bullseye.

Cheers

> 
> [ Changes ]
> Besides changing gbp's branch, the new version unapplies a
> Debian-specific patch and removes libasm-java from Build-Depends.
> Depends is automatically handled by javahelper.
> 
> Cheers
> -- 
> Sebastian Ramacher

> diff --git a/debian/changelog b/debian/changelog
> index 6ea2b74..40e3021 100644
> --- a/debian/changelog
> +++ b/debian/changelog
> @@ -1,3 +1,11 @@
> +libbluray (1:1.2.1-4+deb11u1) bullseye; urgency=medium
> +
> +  * debian/gbp.conf: Switch to bullseye branch
> +  * debian/: Switch to embedded libasm. The version from libasm-java is too
> +new. (Closes: #991991)
> +
> + -- Sebastian Ramacher   Sun, 08 Aug 2021 23:27:53 
> +0200
> +
>  libbluray (1:1.2.1-4) unstable; urgency=medium
>  
>* debian/patches:
> diff --git a/debian/control b/debian/control
> index 11142ed..1a885ba 100644
> --- a/debian/control
> +++ b/debian/control
> @@ -18,8 +18,7 @@ Build-Depends-Indep:
>   ant,
>   doxygen,
>   graphviz,
> - javahelper,
> - libasm-java
> + javahelper
>  Standards-Version: 4.5.1
>  Homepage: http://www.videolan.org/developers/libbluray.html
>  Vcs-Git: https://salsa.debian.org/multimedia-team/libbluray.git
> diff --git a/debian/gbp.conf b/debian/gbp.conf
> index 4f24002..e0f993f 100644
> --- a/debian/gbp.conf
> +++ b/debian/gbp.conf
> @@ -1,3 +1,4 @@
>  [DEFAULT]
>  pristine-tar = True
>  compression = bzip2
> +debian-branch = bullseye
> diff --git 
> a/debian/patches/0002-Use-system-asm-instead-of-embedded-copy.patch 
> b/debian/patches/0002-Use-system-asm-instead-of-embedded-copy.patch
> deleted file mode 100644
> index 54ad932..000
> --- a/debian/patches/0002-Use-system-asm-instead-of-embedded-copy.patch
> +++ /dev/null
> @@ -1,45 +0,0 @@
> -From: Sebastian Ramacher 
> -Date: Wed, 14 Jun 2017 20:22:27 +0200
> -Subject: Use system asm instead of embedded copy
> -
> 
> - src/libbluray/bdj/build.xml | 14 --
> - 1 file changed, 8 insertions(+), 6 deletions(-)
> -
> -diff --git a/src/libbluray/bdj/build.xml b/src/libbluray/bdj/build.xml
> -index 1753779..19163d1 100644
>  a/src/libbluray/bdj/build.xml
> -+++ b/src/libbluray/bdj/build.xml
> -@@ -21,17 +21,15 @@
> - 
> -  - description="compile the source " >
> -- --   bootclasspath="${bootclasspath}"
> --   source="${java_version_asm}" target="${java_version_asm}">
> --   
> --   
> --
> -  -bootclasspath="${bootclasspath}"
> -source="${java_version_bdj}" target="${java_version_bdj}">
> -
> -
> -+   
> -+   
> -+   
> -+   
> - 
> - 
> -  -@@ -39,6 +37,10 @@
> - 
> - 
> - 
> -+
> -+ value="/usr/share/java/asm.jar" />
> -+ value="/usr/share/java/asm-commons.jar" />
> -+
> - 
> -  basedir="${build}">
> -   
> diff --git a/debian/patches/series b/debian/patches/series
> index 89954be..16342b0 100644
> --- a/debian/patches/series
> +++ b/debian/patches/series
> @@ -1,3 +1,2 @@
>  0001-Do-not-download-image-from-the-web.patch
> -0002-Use-system-asm-instead-of-embedded-copy.patch
>  0003-Update-check-for-new-libudfread-pkg-config-file-name.patch




-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#993398: neutron: CVE-2021-40085: Arbitrary dnsmasq reconfiguration via extra_dhcp_opts

[Salvatore Bonaccorso]

Source: neutron
Version: 2:18.1.0-2
Severity: grave
Tags: security upstream
Justification: user security hole
Forwarded: https://launchpad.net/bugs/1939733
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: found -1 2:17.1.1-6

Hi,

The following vulnerability was published for neutron.

CVE-2021-40085[0]:
| An issue was discovered in OpenStack Neutron before 16.4.1, 17.x
| before 17.2.1, and 18.x before 18.1.1. Authenticated attackers can
| reconfigure dnsmasq via a crafted extra_dhcp_opts value.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2021-40085
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-40085
[1] https://launchpad.net/bugs/1939733
[2] https://www.openwall.com/lists/oss-security/2021/08/31/2

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#993397: libhostfile-manager-perl: FTBFS: You planned 65 tests but ran 64.

[Niko Tyni]

Source: libhostfile-manager-perl
Version: 0.09-1.1
Severity: serious
Tags: ftbfs sid bookworm

This package fails its test suite on current sid.

It probably broke with libtest-nowarnings-perl_1.06-1 which is already
in testing (not sure why autopkgtest regression checks didn't catch this.)
>From the Test-NoWarnings changelog:

  Made had_no_warnings turn off the checking at END time for use with
  done_testing based tests with no test count. Also added docs.

>From 
>https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/libhostfile-manager-perl.html

   # Looks like you planned 65 tests but ran 64.
   t/run.t .. 
   1..65
   ok 1 - use Hostfile::Manager;
   ok 2 - Hostfile::Manager->can('block')
   ok 3 - block
   ok 4 - Hostfile::Manager->can('new')
   ok 5 - ... and the constructor should succeed
   ok 6 - '... and the object it returns' isa 'Hostfile::Manager'
   ok 7 - Hostfile::Manager->can('disable_fragment')
   ok 8 - ... and fragment_enabled returns ok when fragment is indeed enabled
   ok 9 - ... and disable_fragment returns ok when fragment is newly disabled
   ok 10 - ... and fragment is indeed disabled
   ok 11 - Hostfile::Manager->can('enable_fragment')
   ok 12 - ... and enable_fragment returns ok when fragment is newly enabled
   ok 13 - ... and fragment is indeed enabled
   ok 14 - Hostfile::Manager->can('enable_fragment')
   ok 15 - ... and enable_fragment returns ok when fragment is newly enabled
   ok 16 - ... and fragment is indeed enabled
   ok 17 - ... and fragment only appears once
   ok 18 - ... and enable_fragment does not complain excessively when enabling 
missing fragment
   ok 19 - Hostfile::Manager->can('fragment_enabled')
   ok 20 - ... and fragment_enabled returns ok when fragment is indeed enabled
   ok 21 - ... and fragment_enabled returns not_ok when fragment is not enabled
   ok 22 - Hostfile::Manager->can('fragment_list')
   ok 23 - ... and fragment list matches expectation
   ok 24 - Hostfile::Manager->can('fragment_status_flag')
   ok 25 - ... and fragment_status_flag returns '+' when fragment is enabled 
and unmodified
   ok 26 - ... and fragment_status_flag returns '*' when fragment is enabled 
and modified
   ok 27 - ... and fragment_status_flag returns ' ' when fragment is disabled
   ok 28 - Hostfile::Manager->can('get_fragment')
   ok 29 - ... and get_fragment returns fragment content
   ok 30 - Hostfile::Manager->can('get_fragment')
   ok 31 - ... and get_fragment undef when fragment file missing
   ok 32 - Hostfile::Manager->can('hostfile')
   ok 33 - ... and hostfile should start out with content of file at 
hostfile_path
   ok 34 - ... and settings its value should NOT succeed
   ok 35 - ... and settings its value did not succeed
   ok 36 - hostfile should start out with content of file at hostfile_path
   ok 37 - Hostfile::Manager->can('hostfile')
   ok 38 - ... and hostfile should start out with content of file at 
hostfile_path, even when constructed with a different hostfile_path
   ok 39 - Hostfile::Manager->can('hostfile_path')
   ok 40 - ... and hostfile_path should start out with default value
   ok 41 - ... and setting its value should succeed
   ok 42 - Hostfile::Manager->can('load_hostfile')
   ok 43 - ... and load_hostfile indicates success
   ok 44 - ... and load_hostfile actually loaded the file
   ok 45 - Hostfile::Manager->can('load_hostfile')
   ok 46 - ... and load_hostfile chokes when hostfile missing
   ok 47 - Hostfile::Manager->can('load_hostfile')
   ok 48 - ... and load_hostfile indicates success
   ok 49 - ... and load_hostfile actually loaded the file
   ok 50 - Hostfile::Manager->can('path_prefix')
   ok 51 - ... and path_prefix should start out with default value
   ok 52 - ... and setting its value should succeed
   ok 53 - Hostfile::Manager->can('toggle_fragment')
   ok 54 - ... and fragment_enabled returns ok when fragment is enabled
   ok 55 - ... and toggle_fragment returns ok when fragment is newly toggled
   ok 56 - ... and fragment is disabled
   ok 57 - ... and toggle_fragment returns ok when fragment is newly toggled
   ok 58 - ... and fragment is enabled
   ok 59 - Hostfile::Manager->can('write_hostfile')
   ok 60 - ... and write_hostfile returns ok
   ok 61 - ... and hostfile written to t/fixtures/hosts/write_test
   ok 62 - Hostfile::Manager->can('write_hostfile')
   ok 63 - ... and write_hostfile chokes when trying to write to file without 
permissions
   ok 64 - ... and hostfile NOT written to t/fixtures/hosts/write_test
   Dubious, test returned 255 (wstat 65280, 0xff00)
   Failed 1/65 subtests 
   
   Test Summary Report
   ---
   t/run.t (Wstat: 65280 Tests: 64 Failed: 0)
 Non-zero exit status: 255
 Parse errors: Bad plan.  You planned 65 tests but ran 64.

-- 
Niko Tyni   nt...@debian.org

Bug#993396: bullseye-pu: package flatpak/1.10.3-0+deb11u1

[Simon McVittie]

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

[ Reason ]
Sync up with upstream to make future stable/security updates easier.
Fix a bug affecting users who set XDG_RUNTIME_DIR to an unusual value.

[ Impact ]
If not accepted, future stable/security updates will take longer to
prepare (backporting fixes to an old upstream release) or longer to
review (the first time we pull in a new upstream stable release, the diff
will look like this one).

Additionally, users with an unusual XDG_RUNTIME_DIR will find that Wayland,
Pipewire and similar protocols don't work in a Flatpak sandbox. Most users
of systemd-logind or elogind, or users who do not have an XDG_RUNTIME_DIR
at all, are unaffected by this. This was a regression in 1.8.5/1.10.0.

[ Tests ]
Flatpak has fairly thorough autopkgtests. They can't be run on
ci.debian.net due to conflicts between LXC and Flatpak containers,
but I run them under qemu-system-x86_64 before each upload. I've also
done some manual testing on bullseye GNOME desktop/laptop systems and
will continue to do so.

[ Risks ]
It's a high-visibility and security-sensitive package, but the code has
hardly changed since stable. All changes are backports from unstable
(either the development release 1.11.3, or post-release fixes in 1.11.3-2
which resulted from me testing 1.11.3 under autopkgtest).

[ 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
  - It's a filtered git diff rather than a debdiff, but I upload with
dgit, so what's in git has to match what's uploaded. I did a diff
between patched trees, because the majority of the upstream code
changes were previously in debian/patches.
  [x] the issue is verified as fixed in unstable

[ Changes ]
common/flatpak-run.c: Make sure user's custom XDG_RUNTIME_DIR is overwritten
with the one Flatpak sets up, as intended. Previously, the XDG_RUNTIME_DIR
inside the sandbox was only correct for users of systemd-logind or
elogind (Flatpak deliberately makes its path consistent with those),
or users who do not have that variable set at all.

tests/test-run.sh: Assert that the XDG_RUNTIME_DIR bug is fixed.

Other files: new upstream stable release (NEWS, version number,
Autotools noise).

[ Other info ]
I would like to keep tracking Flatpak stable releases in bullseye if
possible. From its security history and position at a sandbox boundary,
I expect to see CVEs during the lifetime of bullseye.

Thanks,
smcv

Bug#993395: libconfig-ini-perl: broken by libmixin-linewise-perl

[Niko Tyni]

Package: libconfig-ini-perl
Version: 1:0.025-1.1
Severity: serious
Tags: ftbfs fixed-upstream sid bookworm

As seen on ci.debian.net, this package fails its test suite with
libmixin-linewise-perl/0.110-1. The regression is currently blocking
libmixin-linewise-perl testing migration.

The issue is presumably fixed upstream in Config-INI:

0.027 2021-06-22 22:27:53-04:00 America/New_York
- require Mixin::Linewise v0.110 to cope with new error message

I haven't checked if this is only build time breakage, or if run time
is affected too. In the latter case libmixin-linewise-perl probably needs
to add a Breaks entry.

>From 
>https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/libconfig-ini-perl.html

   #   Failed test 'read_file on non-plain-file'
   #   at t/reader-err.t line 30.
   #   ''lib' is not readable at t/reader-err.t line 29.
   # '
   # doesn't match '(?^i:not a plain file)'
   
   #   Failed test 'can't read an unreadable file'
   #   at t/reader-err.t line 51.
   #   ''tempt6w8z' is not readable at t/reader-err.t line 50.
   # '
   # doesn't match '(?^:(?:couldn't|can't) read)'
   # Looks like you failed 2 tests of 9.
   t/reader-err.t . 
   1..9
   ok 1 - read_file without args
   ok 2 - read_file with non-existent file
   not ok 3 - read_file on non-plain-file
   not ok 4 - can't read an unreadable file
   ok 5 - read_string without args
   ok 6 - syntax error
   ok 7 - syntax error
   ok 8 - we can't read a UTF-8 file that starts with a BOM
   ok 9 - the error message mentions a BOM
   Dubious, test returned 2 (wstat 512, 0x200)
   Failed 2/9 subtests 

-- 
Niko Tyni   nt...@debian.org

Bug#993086: Please package new upstream

[Julien Puydt]

Hi

Le ven. 27 août 2021 à 12:37, Martin Quinson 
a écrit :

>
> sorry for the delay. I'm not very active in minetest these days, and I was
> buzy updating my other (numerous) outdated packages now that the freeze is
> over.
>
> An helping hand would be really welcome here. We could use salsa to
> collaborate in the update. Please push your changes there when you have
> some.
>

I finally found some time to open the tracker to see what needed to be
done... Only to see that the latest uploaded version wasn't on salsa.

Adrian, did you forget a git push --tags?

Cheers

J. Puydt

>

Bug#993145: qemu-system-x86_64: ../../util/qemu-sockets.c:1348: socket_sockaddr_to_address_unix: Assertion `salen >= sizeof(su->sun_family) + 1 && salen <= sizeof(struct sockaddr_un)' failed.

[Michael Tokarev]

31.08.2021 18:02, dann frazier wrote:


char device redirected to /dev/pts/14 (label charserial0)
about to fire assert: salen=2
qemu-system-x86_64: ../../util/qemu-sockets.c:1352: socket_sockaddr_to_address_unix: Assertion 
`salen >= sizeof(su->sun_family) + 1 && salen <= sizeof(struct sockaddr_un)' 
failed.
2021-08-31 15:01:18.082+: shutting down, reason=crashed


Thank you very much dann!
So this new assert() is wrong on both min and max sides. Oh well.. ;)

I cooked another patch to fix this, will upload it asap.

It is a fun one.. ;)

/mjt

Bug#993251: ruby-kramdown: Package kramdown vanished without notice or transitional package

[Salvatore Bonaccorso]

Hi,

On Tue, Aug 31, 2021 at 09:30:17PM +0530, Pirate Praveen wrote:
> On Sun, 29 Aug 2021 13:05:04 +0200 Axel Beckert  wrote:
> > Package: ruby-kramdown
> > Version: 2.3.1-2
> >
> > Hi,
> >
> > aptitude refused to upgrade ruby-kramdown initially, because I have the
> > package "kramdown" installed and it has a hard dependency on
> > "ruby-kramdown (= 2.3.0-5)".
> >
> > It seems that the package "kramdown" is no more built by the
> > ruby-kramdown source package. This opens a bunch of questions about this
> > questionable change:
> >
> > * Why is it removed at all?
> 
> This was removed in this commit when an older dsc was imported to the master
> branch
> https://salsa.debian.org/ruby-team/ruby-kramdown/-/commit/e940d097c25f7342bb73bfb815c36fc94b2988f1

I guess that change was though imported into the "wrong" brnach, in
the sense it was from the done security-update. Were any other unsable
changes lost?

Regards,
Salvatore

Bug#993394: transition: glibc 2.32

[Aurelien Jarno]

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

Dear release team,

I would like to get a transition slot for glibc 2.32. It has been built
successfully on all release architectures except mips*el, however I have
successfully built them manually on eller.d.o. It also builds fine on most
ports architectures.

As glibc is using symbol versioning, there is no soname change. That
said a few packages are using libc internal symbols and have to be
rebuilt for this transition:
- apitrace
- dante
- gcc-9 (s390x only)
- libnih
- libnss-db
- unscd
- zeek

Here is the corresponding ben file:
  title = "glibc";
  is_affected = .depends ~ /libc[0-9.]* \(<

Bug#993168: Security support ended for Xen 4.11 in Buster

[Holger Levsen]

Hi Hans,

On Sat, Aug 28, 2021 at 12:03:50PM +0200, Hans van Kranenburg wrote:
> For security-support-ended.deb10, this would be a line like:
> 
> xen 4.11.4+107-gef32c7afa2-1
> https://xenbits.xen.org/docs/4.11-testing/SUPPORT.html#release-support

thanks, I will address this shortly. (as in 2-3 days I suppose..)


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

If nothing saves us from death, may love at least save us from life.


signature.asc
Description: PGP signature

Bug#992696: [Pkg-freeipa-devel] Bug#992696: 389-ds: 389-DS no longer starts since bullseye due to libjemalloc.so.2 not found

[Adam Reece]

Hi Timo,

Thanks for your response.

I had spotted the Samba schema issue shortly after and took it out of the 
configuration already, but still had the same problem. Only by creating the 
symlink I mentioned this problem became resolved.

Does it matter that this system was an in-place upgrade from Buster? (Its 
original installation was Jessie and has been upgraded throughout releases.)


 * Adam Reece
 * Sven Co-op team

 * Email: a...@svencoop.com 
 * Web: www.svencoop.com 

On 31/08/2021 17:47, Timo Aaltonen wrote:

On 22.8.2021 15.15, Adam Reece wrote:


Aug 22 14:13:38 amun ns-slapd[14030]: [22/Aug/2021:14:13:38.279004946 +0200] - ERR - 
dse_read_one_file - The entry cn=schema in file 
/etc/dirsrv/slapd-amun.service/schema/60samba3.ldif (lineno: 1) is invalid, error code 20 
(Type or value exists) - object class sambaConfig: The name does not match the OID 
"1.3.6.1.4.1.7165.1.2.2.10". Another object class is already using the name or 
OID.
Aug 22 14:13:38 amun ns-slapd[14030]: [22/Aug/2021:14:13:38.280495362 +0200] - 
ERR - setup_internal_backends - Please edit the file to correct the reported 
problems and then restart the server.

That's your error.

The 389 packages didn't change since -2 and things work just fine on 
ci.debian.net and salsa (meaning the daemon starts), so I don't know how 389 
could be to blame here.

the libjemalloc thing is just noise, it's not a hard requirement AIUI.




OpenPGP_0x772BA858CF9CD88D.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#993393: sensible-utils: [INTL:de] updated German man page translation

[Helge Kreutzmann]

Package: sensible-utils
Version: 0.0.17
Severity: wishlist
Tags: patch l10n

Please find the updated German man page translation for sensible-utils
attached.

If you update your template, please use 
'msgfmt --statistics '
to check the po-files for fuzzy or untranslated strings.

If there are such strings, please contact me so I can update the 
German translation.

Greetings
Helge
# Translation of sensible-utils man page template to German
# Copyright (C) Helge Kreutzmann , 2011, 2017, 2021.
# This file is distributed under the same license as the sensible-utils package.
#
msgid ""
msgstr ""
"Project-Id-Version: sensible-utils man page 0.0.17\n"
"POT-Creation-Date: 2021-08-07 15:21+\n"
"PO-Revision-Date: 2021-08-31 20:41+0200\n"
"Last-Translator: Helge Kreutzmann \n"
"Language-Team: German \n"
"Language: de\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: utf-8\n"

#. type: TH
#: sensible-editor.man sensible-browser.man
#, no-wrap
msgid "SENSIBLE-EDITOR"
msgstr "SENSIBLE-EDITOR"

#. type: TH
#: sensible-editor.man
#, no-wrap
msgid "14 Nov 2018"
msgstr "14. Nov. 2018"

#. type: TH
#: sensible-editor.man sensible-browser.man sensible-pager.man
#: select-editor.man
#, no-wrap
msgid "Debian"
msgstr "Debian"

#. type: SH
#: sensible-editor.man sensible-browser.man sensible-pager.man
#: select-editor.man
#, no-wrap
msgid "NAME"
msgstr "NAME"

#. type: Plain text
#: sensible-editor.man
msgid "sensible-editor - sensible editing"
msgstr "sensible-editor - vernünftiges Bearbeiten"

#. type: SH
#: sensible-editor.man sensible-browser.man sensible-pager.man
#: select-editor.man
#, no-wrap
msgid "SYNOPSIS"
msgstr "ÜBERSICHT"

#. type: Plain text
#: sensible-editor.man
msgid "B [OPTIONS...]"
msgstr "B [OPTIONEN …]"

#. type: SH
#: sensible-editor.man sensible-browser.man sensible-pager.man
#: select-editor.man
#, no-wrap
msgid "DESCRIPTION"
msgstr "BESCHREIBUNG"

#. type: Plain text
#: sensible-editor.man
msgid ""
"B makes sensible decisions on which editor to call.  "
"Programs in Debian can use this script as their default editor."
msgstr ""
"B trifft vernünftige Entscheidungen, welcher Editor "
"aufgerufen wird. Programme in Debian können dieses Skript als ihren Standard-"
"Editor benutzen."

#. type: Plain text
#: sensible-editor.man
msgid "B try to do in the following order:"
msgstr "B versucht Folgendes in nachfolgender Reihenfolge:"

#. type: IP
#: sensible-editor.man
#, no-wrap
msgid "\\n[step]"
msgstr "\\n[step]"

#. type: Plain text
#: sensible-editor.man
msgid "if B environment variable exists, execute B"
msgstr ""
"Falls die Umgebungsvariable B existiert, führt es B aus."

#. type: IP
#: sensible-editor.man
#, no-wrap
msgid "\\n+[step]"
msgstr "\\n+[step]"

#. type: Plain text
#: sensible-editor.man
msgid "if B environment variable exists, execute B"
msgstr ""
"Falls die Umgebungsvariable B existiert, führt es B aus."

#. type: Plain text
#: sensible-editor.man
msgid ""
"source the contents of file I<~/.selected_editor> and, if B "
"environment variable exists execute B"
msgstr ""
"Es liest den Inhalt der Datei I<~/.selected_editor> ein und führt, falls die "
"Umgebungsvariable B existiert, B aus."

#. type: Plain text
#: sensible-editor.man
msgid "run B command"
msgstr "Es führt B aus."

#. type: Plain text
#: sensible-editor.man
msgid "finally run B command"
msgstr "Schließlich wird B ausgeführt."

#. type: SH
#: sensible-editor.man sensible-pager.man select-editor.man
#, no-wrap
msgid "SEE ALSO"
msgstr "SIEHE AUCH"

#. type: Plain text
#: sensible-editor.man
msgid "B(7)  for documentation of the EDITOR, VISUAL variables"
msgstr "B(7) für die Dokumentation der Variablen EDITOR, VISUAL"

#. type: Plain text
#: sensible-editor.man
msgid "B(1)  for changing a user's default editor."
msgstr "B(1) zum Ändern des Standards-Editors des Benutzers."

#. type: Plain text
#: sensible-editor.man
msgid "B(1)  for default system wide editor."
msgstr "B(1) für den systemweiten Vorgabe-Editor."

#. type: SH
#: sensible-editor.man
#, no-wrap
msgid "BUGS"
msgstr "FEHLER"

#. type: Plain text
#: sensible-editor.man
msgid ""
"This command is protected against trivial fork bomb, when user set "
"B wider loops are still possible."
msgstr ""
"Dieser Befehl ist gegen triviale Fork-Bomben geschützt. Wenn der Benutzer "
"B setzt, sind weitere Schleifen noch möglich."

#. type: SH
#: sensible-editor.man sensible-browser.man sensible-pager.man
#, no-wrap
msgid "STANDARD"
msgstr "STANDARD"

#. type: Plain text
#: sensible-editor.man sensible-browser.man sensible-pager.man
msgid ""
"Documentation of behavior of sensible-utils under a debian system is "
"available under section 11.4 of debian-policy usually installed under /usr/"
"share/doc/debian-policy (you might need to install debian-policy)"
msgstr ""
"Die Beschreibung des Verhaltens der Sensible-Utils in einem Debian-System "
"ist unter Abschnitt 11.4 der Debian-Policy erhältlich, die normalerweise "
"unter 

Bug#980185: closed by Debian FTP Masters (reply to Bastien Roucariès ) (Bug#980185: fixed in sensible-utils 0.0.15)

[Helge Kreutzmann]

Hello Bastien,
On Tue, Aug 24, 2021 at 09:54:09PM +, Debian Bug Tracking System wrote:
> If you fix them, either unfuzzy the German translation or, if you feel
> uncomfortable doing so (which is fine, if in doubt, do not unfuzzy
> yourself), please provide me de.po (after update of the template) and
> I will send  you the updated de.po back. I usually respond within 24
> hours.

This was meant seriously!

I'll file a new bug shortly doing the update.

Helge

-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
   Help keep free software "libre": http://www.ffii.de/


signature.asc
Description: PGP signature

Bug#993316: systemd: missing /lib/systemd/system/rpcbind.service file

[Niels Thykier]

Michael Biebl:
> Hi Niels
> 
> Am 31.08.21 um 18:07 schrieb Niels Thykier:
> 
>> My thought is that this is not something I want in dh_link - dh_link has
>> no business second guessing the link values it gets.  Since dh_link runs
>> after dh_installsystemd, then we cannot even rely on dh_installsystemd
>> to perform a fix up either.
> 
> Nod.
> 
>> Which begins to smell like that either people have to update their
>> dh_links calls/configuration OR we roll back the dh_installsystemd
>> change to move to /usr.  I am not particular fan of either.  :-/
>>
>> Nevertheless, I am inclined to do a rollback and then punt on the "/ ->
>> /usr" migration track for now.
> 
> I'll see if I can compile a list of possibly affected packages.
> If the number is low enough, I think updating the symlink manually is
> probably ok.
> 
> Regards,
> Michael
> 
> 

I appreciate it, but I think we should be careful here with the manual
update.  If consensus on debian-devel is that debhelper should roll this
back, then we will break these packages again.

I do not think that would make us popular... :-/

~Niels

Bug#993338: octave: Setting up octave fails due to missing libGL.so.1

[Sébastien Villemot]

Le lundi 30 août 2021 à 22:32 +, Witold Baryluk a écrit :
> Package: octave
> Version: 6.2.0-1
> Severity: serious
> Justification: Policy 3.5
> X-Debbugs-Cc: witold.bary...@gmail.com
> 
> Dear Maintainer,
> 
> when debootstrapping using live-build:
> 
> Setting up octave (6.2.0-1) ...
> /usr/bin/octave-cli: error while loading shared libraries: libGL.so.1: cannot 
> open shared object file: No such file or directory
> dpkg: error processing package octave (--configure):
>  installed octave package post-installation script subprocess returned error 
> exit status 127
> 
> 
> Mesa is installed later by apt. Pre-Depends maybe required? Also weird a
> bit that octave-cli requires OpenGL.

Policy §6.5 is clear about the fact that, when the postinst script is
called, dependencies are unpacked and configured (unless there are
circular dependencies, which I don’t think is the case here).

So if libgl1 is really unpacked after octave is configured, the bug
probably lies in dpkg.

Do you have a way of reproducing the problem?

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



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

Bug#915541: Removal of upstream "--will-cite" functionality has been reverted

[Ole Tange]

On Mon, Aug 30, 2021 at 8:26 AM Andreas Tille  wrote:
>
> since this issue becomes complex I'd like to bring up it at debian-legal
> list for advise.

In disagreements it often helps to first agree on what the parties
disagree on. That way you can put aside the parts you agree on. Maybe
this can also help here.

In the text below The Notice refers to the citation notice in GNU
Parallel version 20210722.

Do you believe the original source code of version 20210722 is GPLv3
compliant in your interpretation of the GPLv3? If no: What license (if
any) would give you the right to change the software?

Do you believe The Notice conflicts with the 4 freedoms of Free
Software? If so: please explain how.

Do you believe The Notice conflicts with the DFSG? If so: please explain how.

Do you believe The Notice breaks scripts - unattended or not? If so:
Provide a minimal working example that shows a script actually
breaking (don't assume it will break, instead show it actually
breaks).

Do you believe you can change the source code as much as you want and
still call it GNU Parallel? Do you believe you can make significant
changes and still call it GNU Parallel?

Are you aware that in academia it is tradition to cite research you build upon?

Are you aware citations are an important factor for some researchers
to have their contract extended?

Are you aware that GNU Parallel earlier tried only to have the
citation notice in the documentation, but researchers simply did not
read this, and thus forgot to cite - not because they did not want to
cite, but because they simply were not aware?

Are you aware there are plenty of alternatives, if you dislike GNU
Parallel (man parallel_alternatives)?


/Ole

Bug#993373: [PATCH 1/2] Populate with dummy test data

[Madie K. Mckeel]

This is derived (and slightly expanded) from the old-upstream revision
144.

---
 tests/check_fstab/a | 1 +
 tests/check_fstab/b | 1 +
 tests/check_fstab/c | 1 +
 tests/check_fstab/d | 1 +
 tests/check_fstab/e | 1 +
 5 files changed, 5 insertions(+)
 create mode 100644 tests/check_fstab/a
 create mode 12 tests/check_fstab/b
 create mode 12 tests/check_fstab/c
 create mode 100644 tests/check_fstab/d
 create mode 12 tests/check_fstab/e

diff --git a/tests/check_fstab/a b/tests/check_fstab/a
new file mode 100644
index 000..df3f5a7
--- /dev/null
+++ b/tests/check_fstab/a
@@ -0,0 +1 @@
+dummy file a
diff --git a/tests/check_fstab/b b/tests/check_fstab/b
new file mode 12
index 000..2e65efe
--- /dev/null
+++ b/tests/check_fstab/b
@@ -0,0 +1 @@
+a
\ No newline at end of file
diff --git a/tests/check_fstab/c b/tests/check_fstab/c
new file mode 12
index 000..c59d9b6
--- /dev/null
+++ b/tests/check_fstab/c
@@ -0,0 +1 @@
+d
\ No newline at end of file
diff --git a/tests/check_fstab/d b/tests/check_fstab/d
new file mode 100644
index 000..54519ff
--- /dev/null
+++ b/tests/check_fstab/d
@@ -0,0 +1 @@
+dummy file d
diff --git a/tests/check_fstab/e b/tests/check_fstab/e
new file mode 12
index 000..3410062
--- /dev/null
+++ b/tests/check_fstab/e
@@ -0,0 +1 @@
+c
\ No newline at end of file
--
2.31.1

Bug#993373: Subject: [PATCH 2/2] Fix use-after-free bug in realpath()

[Madie K. Mckeel]

The memory provided by `buf` is still reference by `path` and used after
the free call.  Delay the freeing until after using it.
---
 src/realpath.c | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/src/realpath.c b/src/realpath.c
index 1cf7eaf..9133605 100644
--- a/src/realpath.c
+++ b/src/realpath.c
@@ -64,6 +64,7 @@ private_realpath(const char *path, char *resolved_path, int 
maxreslth) {
char link_path[PATH_MAX+1];
int n;
char *buf = NULL;
+   char *oldbuf = NULL;

npath = resolved_path;

@@ -141,12 +142,19 @@ private_realpath(const char *path, char *resolved_path, 
int maxreslth) {

/* Insert symlink contents into path. */
m = strlen(path);
-   if (buf)
-   free(buf);
+   if (buf) {
+   /* Delay freeing of 'buf', as 'path' might
+* still be pointing to it. */
+   oldbuf = buf;
+   }
buf = xmalloc(m + n + 1);
memcpy(buf, link_path, n);
memcpy(buf + n, path, m + 1);
path = buf;
+   if (oldbuf) {
+   free(oldbuf);
+   oldbuf = NULL;
+   }
 #endif
}
*npath++ = '/';
--
2.31.1

Bug#960268: Update to 3.1.0 or newer

[David Bremner]

Nicholas D Steeves  writes:

> Package: elpa-fountain-mode
> Severity: normal
>
> Fountain-mode is out of date.  I have not imported the new series yet,
> because it drops support for exporting to PDF.  Afterwriting looks
> like a viable replacement for this functionality.  Afterwriting functionality 
> exposed to Emacs should at least be equivalent to Atom's implementation:
>
>   https://atom.io/packages/fountain

Hi Nicholas;

If PDF export is a dealbreaker for you maintaining the package, please
orphan it; if no-one picks it up and updates it we can remove it per
Paul's request.

d


signature.asc
Description: PGP signature

Bug#993373: Use-after-free bug in realpath()

[Madie K. Mckeel]

Package: pmount
Version: 0.9.23-6
Tags: patch

Dear Debian maintainers

I stumbled over a use-after-free bug in pmount.  It's in its realpath 
implementation when dealing with stacked symlinks, i.e. symlinks pointing to 
symlinks. (Ironically, pmount "switched to a [self-made] implementation of 
realpath, for security reasons", so that's that).

The bug is in realpath.c lines 144 to 149:
```
// while (symlink) {
// [...]
if (buf)
free(buf); // (1)
buf = xmalloc(m + n + 1);
memcpy(buf, link_path, n);
memcpy(buf + n, path, m + 1);  // (2)
path = buf;// (3)
// [...]
// }
```
This snippet is iterated in a while loop over the stacked symlinks, e.g. twice 
for a symlink pointing to a symlink pointing to a file. In this case `buf` is 
freed to early (1) as the memory region is still pointed to by `path` (3) and 
used afterwards (2).

A simple (but properly bad) fix is to delay the freeing as in the follow up 
message.  I don't fully understand all the pointer tricker going on in that 
function, so there might be better solutions.

Upstream of this package seams dead a long time ago and Fedora uses Debian as 
upstream, so a fix in Debian would at least hit two major Linux distributions 
and their derivative ecosystems and maybe even others.

Lastly, how to trigger this bug.  Run the test suite `make check` of pmount.  
Though you have to initialise the test data first (first follow up commit to 
this). The test_policy the fails.  On my system the `resolved_path` variable 
contained garbage at the end (probably copied from the invalid pointer 
reference) and `readlink()` failed with an error as such a file did not exist.

Bug#993338: octave: Setting up octave fails due to missing libGL.so.1

[Witold Baryluk]

Package: octave
Version: 6.2.0-1
Followup-For: Bug #993338
X-Debbugs-Cc: witold.bary...@gmail.com

Actually not mesa itself strictly, but rather 'libgl1' package needs to
be in Pre-Depends afaik.

Regards,
Witold

Bug#993330: polymake: FTBFS with Perl 5.34: error: ‘Perl_pp_keys’ was not declared in this scope

[David Bremner]

Niko Tyni  writes:

> This package fails to build from source with Perl 5.34 (currently
> in experimental). I don't presently understand why; I'm not aware of
> changes to Perl_pp_keys or Perl_pp_rv2hv. So the root issue might also
> be on the Perl side. At least it seems to reliably fail the same way.
>

At least some of the build-deps [1] seem not to be rebuilt yet in
experimental. Do you have an extra repo I should add?  Alternatively you
can try rebuilding against the polymake 4.4 in git [2].

[1]: libterm-readkey-perl libterm-readline-gnu-perl
[2]: https://salsa.debian.org/bremner/polymake


signature.asc
Description: PGP signature

Bug#993043: ensmallen: autopkgtest regression on arm64/i386/ppc64el

[Graham Inggs]

This appears to be fixed, at least on arm64 and ppc64el, by the upload
of armadillo/1:10.6.2+dfsg-1.

Bug#671296: sstp-client: changing back from ITP to RFP

[Jonathan Rubenstein]

Hi Lucas,
I thought I did what was necessary to package this software for debian, and I have .deb files out on the web-site. I will need some help to understand what is needed to meet the criteria for debian, and by the way; I don't mind doing the work. 


Regards,
- Eivind



> Hi Eivind,
>
> I think http://mentors.debian.net/intro-maintainers has all the info you
> need. Please let me know if you have further questions.
>
> Lucas


It seems like maybe this was misunderstood? Could there be an avenue 
forward to seeing sstp-client in Debian? It has my interest.


Jonathan Rubenstein

Bug#993316: systemd: missing /lib/systemd/system/rpcbind.service file

[Michael Biebl]

Hi Niels

Am 31.08.21 um 18:07 schrieb Niels Thykier:


My thought is that this is not something I want in dh_link - dh_link has
no business second guessing the link values it gets.  Since dh_link runs
after dh_installsystemd, then we cannot even rely on dh_installsystemd
to perform a fix up either.


Nod.


Which begins to smell like that either people have to update their
dh_links calls/configuration OR we roll back the dh_installsystemd
change to move to /usr.  I am not particular fan of either.  :-/

Nevertheless, I am inclined to do a rollback and then punt on the "/ ->
/usr" migration track for now.


I'll see if I can compile a list of possibly affected packages.
If the number is low enough, I think updating the symlink manually is 
probably ok.


Regards,
Michael




OpenPGP_signature
Description: OpenPGP digital signature

Bug#993145: 1:6.1+dfsg-3 update

[Michael Tokarev]

Control: reopen -1

31.08.2021 19:23, dann frazier wrote:

Here's an updated assert using 1:6.1+dfsg-3:

char device redirected to /dev/pts/8 (label charserial0)
qemu-system-x86_64: ../../util/qemu-sockets.c:1349:
socket_sockaddr_to_address_unix: Assertion `salen >=
sizeof(su->sun_family) + 1 && salen <= sizeof(struct sockaddr_un) +
su->sun_path[0] ? 1 : 0' failed.
2021-08-31 16:20:42.453+: shutting down, reason=crashed



Wow. So it is the other way 'round actually.. I suspected this much but
with much larger confidence I thought about the overflow thing.. *sigh*.

So this is an unnamed socket (aks socketpair?) Wow!..

I wonder what libvirt uses that for...

Thank you very much for the test!

/mjt

Bug#991463: fixed in knot-resolver 5.4.1-1

[Jakub Ružička]

> I've opened transition bug #993027

Got ack from RT, I've uploaded knot-3.1.1-4 into unstable to start the
transition.

Do I need to wait until the new knot built on all archs before uploading
depending knot-resolver-5.4.1-2 or is there a smart mechanism ensuring
build against correct/latest version?

> Yes, that I should fix the issue with the next (first) bullseye-point
> release after it's been fixed in unstable.

I've prepared knot-resolver-5.3.1-2+deb11u1 with the backport of
upstream fix in new debian/bullseye salsa branch:

https://salsa.debian.org/dns-team/knot-resolver/-/commits/debian/bullseye

Please review my changes before I attempt the bullseye upload as I'm new
to this process.


,
Jakub


OpenPGP_0xA4254072E373042C.asc
Description: OpenPGP public key

Bug#993392: kdenlive started depending on the breeze package

[Bohdan Horbeshko]

Package: kdenlive
Version: 20.12.3-1
Severity: minor

Dear Maintainer,

the breeze package is pretty heavy. Is it reasonable to depend on it
rather than recommend it?

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

Kernel: Linux 5.10.0-8-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_CRAP, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=ru_UA.UTF-8, LC_CTYPE=ru_UA.UTF-8 (charmap=UTF-8), 
LANGUAGE=ru_UA:ru
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages kdenlive depends on:
ii  ffmpeg 7:4.3.2-0+deb11u2
ii  gstreamer1.0-plugins-bad   1.18.4-3
ii  kded5  5.83.0-2
ii  kdenlive-data  20.12.3-1
ii  kinit  5.83.0-2
ii  kio5.83.0-2
ii  libc6  2.31-17
ii  libkf5archive5 5.83.0-2
ii  libkf5bookmarks5   5.83.0-2
ii  libkf5completion5  5.83.0-2
ii  libkf5configcore5  5.83.0-2
ii  libkf5configgui5   5.83.0-2
ii  libkf5configwidgets5   5.83.0-3
ii  libkf5coreaddons5  5.83.0-2
ii  libkf5crash5   5.83.0-2
ii  libkf5dbusaddons5  5.83.0-2
ii  libkf5declarative5 5.83.0-2
ii  libkf5filemetadata35.83.0-2
ii  libkf5guiaddons5   5.83.0-2
ii  libkf5i18n55.83.0-3
ii  libkf5iconthemes5  5.83.0-2
ii  libkf5itemviews5   5.83.0-2
ii  libkf5jobwidgets5  5.83.0-2
ii  libkf5kiocore5 5.83.0-2
ii  libkf5kiofilewidgets5  5.83.0-2
ii  libkf5kiogui5  5.83.0-2
ii  libkf5kiowidgets5  5.83.0-2
ii  libkf5newstuff55.83.0-2
ii  libkf5notifications5   5.83.0-3
ii  libkf5notifyconfig55.83.0-2
ii  libkf5purpose-bin  5.83.0-2
ii  libkf5purpose5 5.83.0-2
ii  libkf5service-bin  5.83.0-2
ii  libkf5service5 5.83.0-2
ii  libkf5solid5   5.83.0-2
ii  libkf5textwidgets5 5.83.0-2
ii  libkf5widgetsaddons5   5.83.0-2
ii  libkf5xmlgui5  5.83.0-2
ii  libmlt++3  6.26.1-1
ii  libmlt66.26.1-1
ii  libqt5concurrent5  5.15.2+dfsg-10
ii  libqt5core5a   5.15.2+dfsg-10
ii  libqt5dbus55.15.2+dfsg-10
ii  libqt5gui5 5.15.2+dfsg-10
ii  libqt5multimedia5  5.15.2-3
ii  libqt5network5 5.15.2+dfsg-10
ii  libqt5qml5 5.15.2+dfsg-8
ii  libqt5quick5   5.15.2+dfsg-8
ii  libqt5quickcontrols2-5 5.15.2+dfsg-4
ii  libqt5quickwidgets55.15.2+dfsg-8
ii  libqt5svg5 5.15.2-3
ii  libqt5widgets5 5.15.2+dfsg-10
ii  libqt5xml5 5.15.2+dfsg-10
ii  librttr-core0.9.6  0.9.6+dfsg1-4
ii  libstdc++6 11.2.0-3
ii  melt   6.26.1-1
ii  qml-module-qtgraphicaleffects  5.15.2-2
ii  qml-module-qtqml-models2   5.15.2+dfsg-8
ii  qml-module-qtquick-controls5.15.2-2
ii  qml-module-qtquick-controls2   5.15.2+dfsg-4
ii  qml-module-qtquick-dialogs 5.15.2-2
ii  qml-module-qtquick-layouts 5.15.2+dfsg-8
ii  qml-module-qtquick-window2 5.15.2+dfsg-8
ii  qml-module-qtquick25.15.2+dfsg-8

Versions of packages kdenlive recommends:
pn  breeze 
ii  dvdauthor  0.7.2-1+b3
ii  dvgrab 3.5+git20160707.1.e46042e-1+b1
ii  frei0r-plugins 1.7.0-1
ii  genisoimage9:1.1.11-3.2
pn  oxygen-icon-theme  
ii  recordmydesktop0.4.0-1+b1
ii  swh-plugins0.4.17-2

Versions of packages kdenlive suggests:
pn  khelpcenter  
ii  vlc  3.0.16-1+b1
ii  xine-ui  0.99.9-2

-- no debconf information

Bug#993339: Package: reprotest Debian Salsa reprotest fails due to different compile times

[Chris Talbot]

Hello!

On Tue, 2021-08-31 at 15:19 +, Holger Levsen wrote:
> Hi Chris,
> 
> thanks for your bugreport, but it seems to me that reprotest is not
> failing
> but rather producing failure results when rebuilding your package. Is
> that
> correct? If so, it's not a bug in reprotest... :)
> 

It is producing failure results when I am updating the package, i.e. I
have a new version and I update the Debian packaging. It fails the first
time, but it seems that if I rerun reprotest later, it will pass.

> On Mon, Aug 30, 2021 at 09:33:26PM -0400, Christopher Talbot wrote:
> > On Mon, 2021-08-30 at 18:00 -0700, Vagrant Cascadian wrote:
> > > Maybe when the job was first run, SOURCE_DATE_EPOCH was set to a
> > > date
> > > later than the file unpack times (e.g. maybe due to timezone?)...
> > > and
> > > thus wouldn't clamp the timestamps ... that might explain re-
> > > running
> > > the
> > > job later suceeding.
> > > 
> > > 
> > > live well,
> > >   vagrant
> > 
> > Unfortunately, I do not know enough about reprotest to know what
> > causes
> > it.
> > On a hunch, I also decided to rerun reprotest, and it worked this
> > time:
>  
> > https://salsa.debian.org/DebianOnMobile-team/vvmd/-/pipelines/283265
> > 
> > So it seems to be some sort of time/date dependent bug?
> 
> Vagrant suggested a possible explaination... see above :)
> 

Bug#992696: [Pkg-freeipa-devel] Bug#992696: 389-ds: 389-DS no longer starts since bullseye due to libjemalloc.so.2 not found

[Timo Aaltonen]

On 22.8.2021 15.15, Adam Reece wrote:


Aug 22 14:13:38 amun ns-slapd[14030]: [22/Aug/2021:14:13:38.279004946 +0200] - ERR - 
dse_read_one_file - The entry cn=schema in file 
/etc/dirsrv/slapd-amun.service/schema/60samba3.ldif (lineno: 1) is invalid, error code 20 
(Type or value exists) - object class sambaConfig: The name does not match the OID 
"1.3.6.1.4.1.7165.1.2.2.10". Another object class is already using the name or 
OID.
Aug 22 14:13:38 amun ns-slapd[14030]: [22/Aug/2021:14:13:38.280495362 +0200] - 
ERR - setup_internal_backends - Please edit the file to correct the reported 
problems and then restart the server.

That's your error.

The 389 packages didn't change since -2 and things work just fine on 
ci.debian.net and salsa (meaning the daemon starts), so I don't know how 
389 could be to blame here.


the libjemalloc thing is just noise, it's not a hard requirement AIUI.


--
t

Bug#993391: lxc: Unprivileged lxc example from README.Debian.gz gives AppArmor error "Failed to mount proc"

[pk1]

Package: lxc
Version: 1:4.0.6-2
Severity: important
X-Debbugs-Cc: pkoroau+...@gmail.com

Dear Maintainer,


On a pristine Debian 11 install, the example from "Unprivileged containers"
section of /usr/share/doc/lxc/README.Debian.gz gives "Failed to mount proc"
with an AppArmor error in dmesg, but lxc.apparmor.profile is unconfined.

reportbug said to test unstable's lxc 1:4.0.10-1, but that also fails with
a different error message.


$  cat test_config 
  lxc.idmap = u 0 10 65536
  lxc.idmap = g 0 10 65536
  lxc.mount.auto = proc:mixed sys:ro cgroup:mixed
  lxc.apparmor.profile = unconfined

$   systemd-run --scope --quiet --user --property=Delegate=yeslxc-start 
--logfile /dev/stderr -f test_config -n machine
lxc-start machine 20210830065007.367 ERRORutils - utils.c:safe_mount:1204 - 
Permission denied - Failed to mount "proc" onto "/proc"
lxc-start machine 20210830065007.367 ERRORconf - 
conf.c:lxc_mount_auto_mounts:681 - Permission denied - Failed to mount "proc" 
on "/proc" with flags 14
lxc-start machine 20210830065007.367 ERRORconf - conf.c:lxc_setup:3330 - 
Failed to setup first automatic mounts
lxc-start machine 20210830065007.367 ERRORstart - start.c:do_start:1218 - 
Failed to setup container "machine"
[snip]

# dmesg | tail
[snip unrelated]
[ 2127.458104] audit: type=1400 audit(1630306207.363:40): apparmor="DENIED" 
operation="mount" info="failed flags match" error=-13 
profile="/usr/bin/lxc-start" name="/proc/" pid=3286 comm="lxc-start" 
fstype="proc" srcname="proc" flags="rw, nosuid, nodev, noexec"


Could Debian's sysctl be related, as suggested on the LXC forum?
"At some point Debian introduced additional sysctl to restrict user namespaces
for unprivileged users, maybe they still do that and that’s what’s getting in
the way here?"
https://discuss.linuxcontainers.org/t/cannot-start-unprivileged-container-on-debian-11/12019/4


I also tried (umask 022 ; su -l non_root) per #946725 but that does not fix it.
This is also unrelated to #947863 because the config says unconfined.


-- System Information:
Debian Release: 11.0
Architecture: amd64 (x86_64)

Versions of packages lxc depends on:
ii  bridge-utils 1.7-1
ii  debconf [debconf-2.0]1.5.77
ii  dnsmasq-base [dnsmasq-base]  2.85-1
ii  iproute2 5.10.0-4
ii  iptables 1.8.7-1
ii  libc62.31-13
ii  libcap2  1:2.44-1
ii  libgcc-s110.2.1-6
ii  liblxc1  1:4.0.6-2
ii  libseccomp2  2.5.1-1
ii  libselinux1  3.1-3
ii  lsb-base 11.1.0

Versions of packages lxc recommends:
ii  apparmor   2.13.6-10
ii  debootstrap1.0.123
ii  dirmngr2.2.27-2
ii  gnupg  2.2.27-2
ii  libpam-cgfs1:4.0.6-2
ii  lxc-templates  3.0.4-5
ii  lxcfs  4.0.7-1
ii  openssl1.1.1k-1+deb11u1
ii  rsync  3.2.3-4
ii  uidmap 1:4.8.1-1
ii  wget   1.21-1+b1

Versions of packages lxc suggests:
ii  btrfs-progs  5.10.1-2
ii  lvm2 2.03.11-2.1
pn  python3-lxc  

-- debconf information excluded

Bug#993390: virtuoso-opensource: FTBFS: Dkmarshal.c:50:11: fatal error: rpc/types.h: No such file or directory

[Sebastian Ramacher]

Source: virtuoso-opensource
Version: 7.2.5.1+dfsg1-0.1
Severity: serious
Tags: ftbfs sid bullseye
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: sramac...@debian.org

| libtool: compile:  gcc -DHAVE_CONFIG_H -I. -Wdate-time -D_FORTIFY_SOURCE=2 
-fno-strict-aliasing -O2 -Wall -DNDEBUG -DPOINTER_64 
-I/<>/libsrc/Xml.new -DOPENSSL_NO_KRB5 -Dlinux -D_GNU_SOURCE 
-DFILE64 -D_LARGEFILE64_SOURCE -I../../libsrc -g -O2 
-ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -D_GNU_SOURCE -c Dkmem.c  -fPIC -DPIC -o 
.libs/libdksrv_la-Dkmem.o
| Dkmarshal.c:50:11: fatal error: rpc/types.h: No such file or directory
|50 | # include 
|   |   ^
| compilation terminated.
| make[5]: *** [Makefile:1169: libdksrv_la-Dkmarshal.lo] Error 1

https://buildd.debian.org/status/fetch.php?pkg=virtuoso-opensource=arm64=7.2.5.1%2Bdfsg1-0.1%2Bb1=1630424102=0

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#993384: KDE "global scale" parameter was root cause

[Simon Waters]

I rebuilt Kshisen from 18.04 under Bullseye and it had the same scaling issue.

Quick search around the web suggested  KDE "global scale" under display 
settings which was set to 125%, setting that to 100% restarting, and the tiles 
now render as expected.

Bug#993128: libvpx6: Unable to use camera or share screen on WebRTC conferences

[Sebastian Ramacher]

Control: tags -1 moreinfo

On 2021-08-27 12:10:14 -0300, Paulo Roberto Alves de Oliveira (aka kretcheu) 
wrote:
> Package: libvpx6
> Version: 1.10.0-1
> Severity: important
> Tags: a11y
> 
> Dear Maintainer,
> 
> When we try do use camera or share screen on WebRTC like, Jitsi, 
> GoogleMeeting, it's not working.
> 
> Running Chromium on terminal we can see many error messages:
> 
> ERROR:video_stream_encoder.cc(1729)] Failed to encode frame. Error code: -7
> 
> Downgrading to version 1.9.0-1 it's working again.

Could you please retry with 1.10.0-2 which is now available in unstable?

Cheers

> 
> Thank's
> 
> 
> -- System Information:
> Debian Release: bookworm/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads)
> Locale: LANG=pt_BR.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8), LANGUAGE not 
> set
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages libvpx6 depends on:
> ii  libc6  2.31-17
> 
> libvpx6 recommends no packages.
> 
> libvpx6 suggests no packages.
> 
> -- no debconf information
> 

-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#993377: kodi forget display video calibration after restart

[Henning Follmann]

On Tue, Aug 31, 2021 at 02:44:45PM +, Vasyl Gello wrote:
> Hi Henning!
> 
> So basically, you apply video calibration settings and after Kodi restart the 
> settings are reset to default?
> 
> Can you please post a screenshot of your settings so I can reproduce them in 
> my lab?


one postscript
I checked the file
.kodi/userdata/guisettings.xml

It is rewritten.
BUT!
I used diff on a before / after version of this file.
The  section is not changed. That is what I would expect.
I checked an backup of this file from before I upraded to
bullseye.
Clearly the  section is different and more what I
would expect to compensate for the overscan of the TV monitor.




-- 
Henning Follmann   | hfollm...@itcfollmann.com

Bug#993377: kodi forget display video calibration after restart

[Henning Follmann]

On Tue, Aug 31, 2021 at 02:44:45PM +, Vasyl Gello wrote:
> Hi Henning!
> 
> So basically, you apply video calibration settings and after Kodi restart the 
> settings are reset to default?
>
Very much so.
I have a overscan issue with the attached TV.
I use the expert System/Display tab.
Got to video calibration and use the arrow keys to move the corners into the 
visible
part of the TV screen.
This just works fine until you close kodi.
The next time you open kodi again the video is again to large for the screen.


> Can you please post a screenshot of your settings so I can reproduce them in 
> my lab?

I do not understand, there are really no settings to take a picture off.


> -- 
> Vasyl Gello
> ==
> Certified SolidWorks Expert
> 
> Mob.:+380 (98) 465 66 77
> 
> E-Mail: vasek.ge...@gmail.com
> 
> Skype: vasek.gello
> ==
> 호랑이는 죽어서 가죽을 남기고 사람은 죽어서 이름을 남긴다

-- 
Henning Follmann   | hfollm...@itcfollmann.com

Bug#993388: tcl8.6: nested dicts: with lappend you can duplicate and than remove intermediate values

[Davide Prina]

Package: tcl8.6
Version: 8.6.11+dfsg-1
Severity: normal
X-Debbugs-Cc: davide.pr...@gmail.com

Dear Maintainer,

I'm try to learning tk and I think I have found a bug.
I'm try to understand nested dict and I have done a very simple script:

--8<8<8<8<8<8<---
set Livello0 [dict create Livello 0]

dict set Livello0 MAP {A B C}
dict with Livello0 { lappend MAP D}

puts "Livello0: $Livello0"
puts "MAP [dict get $Livello0 MAP]"

dict with Livello0 { lappend MAP C {1 2}}

puts "Livello0: $Livello0"
puts "MAP [dict get $Livello0 MAP]"

dict with Livello0 MAP { lappend C {3}}

puts "Livello0: $Livello0"
puts "MAP [dict get $Livello0 MAP]"

if [dict exists $Livello0 MAP D] {puts "Exist"} else {puts "Non exist"}
--8<8<8<8<8<8<---

if I execute this script with tclsh I get the followin output:
--8<8<8<8<8<8<---
Livello0: Livello 0 MAP {A B C D}
MAP A B C D
Livello0: Livello 0 MAP {A B C D C {1 2}}
MAP A B C D C {1 2}
Livello0: Livello 0 MAP {A B C {1 2 3}}
MAP A B C {1 2 3}
Non exist
--8<8<8<8<8<8<---

Note that I have done an insert of C {1 2} and it has added
MAP {A B C D C {1 2}}
with C key present two time

when I have added a new item {3} in C
it has deleted the D key and replaced the two C keys with the last one

I have tryed to find an open bug on Tcl site without success.

Ciao
Davide

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

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

Versions of packages tcl8.6 depends on:
ii  libc6  2.31-17
ii  libtcl8.6  8.6.11+dfsg-1

tcl8.6 recommends no packages.

Versions of packages tcl8.6 suggests:
pn  tcl-tclreadline  

-- no debconf information

Bug#993387: ITP: r-cran-filelock -- Portable File Locking

[Nilesh Patra]

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

Subject: ITP: r-cran-filelock -- Portable File Locking
Package: wnpp
Owner: Nilesh Patra 
Severity: wishlist

* Package name: r-cran-filelock
  Version : 1.0.2
  Upstream Author : i-2021 Gábor Csárdi
* URL : https://cran.r-project.org/package=filelock
* License : MIT
  Programming Lang: GNU R
  Description : Portable File Locking
 Place an exclusive or shared lock on a file. It uses 'LockFile'
 on Windows and 'fcntl' locks on Unix-like systems.

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-cran-filelock

Bug#993373: Use-after-free bug in realpath()

[Antonin Décimo]

Hi Madie,

Last year I wrote a lot of patches for pmount, amongst which two
remove the bundled implementation of realpath and switch to the
"modern" interface

   char *realpath(const char *restrict path, NULL);

which has been supported by the libc for quite some time. The original
program (mount(8) from util-linux) from which the current
implementation was taken even dropped it in 2013.

Instead of the patch you send, why not drop it completely like I did?
https://github.com/MisterDA/pmount/commit/3f1c9229d828698c348e0f933d1438bbd32a9ed7
https://github.com/MisterDA/pmount/commit/391a9752df966a65afe35308c81e5db975f85a6d

I wasn't ready to release my updated pmount as the current head commit
is broken, and I haven't had time to fix it. I also need to convince
myself that the commit history looks good and that I haven't
introduced more bugs than I've fixed.

If you have some time to spare, please take a look!

I'm also afraid that the Debian package is unmaintained.

Best regards,

-- Antonin

Bug#993350: xsane: Scanimage detects scanner but Xsane won't start it

[Hans Georg Colle]

Scanimage fails starting the scan, too. The result of "scanimage -d
epson2:libusb:002:005 --format png -o /home/georg/unsinn.png" is
"scanimage: sane_start: Operation not supported".
Georg

Bug#993330: polymake: FTBFS with Perl 5.34: error: ‘Perl_pp_keys’ was not declared in this scope

[David Bremner]

Niko Tyni  writes:

> Source: polymake
> Version: 4.3-4
> Severity: normal
> User: debian-p...@lists.debian.org
> Usertags: perl-5.34-transition
>
> This package fails to build from source with Perl 5.34 (currently
> in experimental). I don't presently understand why; I'm not aware of
> changes to Perl_pp_keys or Perl_pp_rv2hv. So the root issue might also
> be on the Perl side. At least it seems to reliably fail the same way.

There is a new upstream release, which I should try packaging before we
get too far in debugging this.

d

Bug#993388: [Pkg-tcltk-devel] Bug#993388: tcl8.6: nested dicts: with lappend you can duplicate and than remove intermediate values

[Sergei Golovan]

Hi Davide,

As far as I can see, there's nothing wrong with Tcl here. You just
treat a list as a dict, hence the confusion. See this simpler example:

% set M {A B C D C {1 2}}
A B C D C {1 2}

Here, $M contains a list (actually, a string which can be interpreted
as a list). But we can try to interpret it as a dict:

% dict lappend M C 3
A B C {1 2 3}

Here, $M is reinterpreted as a dict, with odd items A, C, C as its
keys, and even items B, D, {1 2} as values. The problem is that there
is the duplicate key C, so Tcl had to drop one of its values (the last
one overwritten the first one upon creation of the dict). After that,
3 was appended to the list {1 2}.

Cheers!
-- 
Sergei Golovan

Bug#993316: systemd: missing /lib/systemd/system/rpcbind.service file

[Niels Thykier]

Michael Biebl:
> Am 30.08.21 um 18:31 schrieb Vincent Lefevre:
>> Package: systemd
>> Version: 247.9-1
>> Severity: critical
>> Justification: breaks unrelated software
>>
>> systemd provides a dangling symlink:
>>
>> $ ls -l /lib/systemd/system/portmap.service
>> lrwxrwxrwx 1 root root 15 2021-08-17 17:31:36
>> /lib/systemd/system/portmap.service -> rpcbind.service
>> $ ls -L /lib/systemd/system/portmap.service
>> ls: cannot access '/lib/systemd/system/portmap.service': No such file
>> or directory
> 
> This symlink is created via
> 
> dh_link lib/systemd/system/rpcbind.service
> lib/systemd/system/portmap.service
> 
> I wonder if debhelper can do something about this or if this is one of
> the cases where the package is best updated manually.
> 
> I suspect we have a few packages which create such aliasing symlinks via
> *.links files or explicit calls to dh_link
> 
> 
> Niels, what's your thought on this?
> 
> 
>> This breaks checkrestart:
> 
> [...]
> 
> Regards,
> Michael
> 

My thought is that this is not something I want in dh_link - dh_link has
no business second guessing the link values it gets.  Since dh_link runs
after dh_installsystemd, then we cannot even rely on dh_installsystemd
to perform a fix up either.

Which begins to smell like that either people have to update their
dh_links calls/configuration OR we roll back the dh_installsystemd
change to move to /usr.  I am not particular fan of either.  :-/

Nevertheless, I am inclined to do a rollback and then punt on the "/ ->
/usr" migration track for now.

~Niels