Bug#989926: purging fails when removing users

[Peter Palfrader]

Package: onionbalance
Version: 0.2.0-3
Severity: important

[This is actually 0.2.0-3~bpo10+1 ]

The onionbalance package tries to remove the role user on purge.
Whether or not that is even desirable is a different question (I am of
the strong opinion that users should not be removed).

However, it fails even at that.

First time purging:

} Removing user `onionbalance' ...
} Warning: group `onionbalance' has no more members.
} userdel: user onionbalance is currently used by process 2689
} /usr/sbin/deluser: `/usr/sbin/userdel onionbalance' returned error code 8. 
Exiting.
} dpkg: error processing package onionbalance (--purge):


So I make sure that no processes are run by that user, but now:

} /usr/sbin/deluser: The user `onionbalance' is not a member of group 
`debian-tor'.
} dpkg: error processing package onionbalance (--purge):

And the package can no longer be purged.  (without modifying the maintainer 
script.)

I'd get rid of the whole deluser stuff.
-- 
|  .''`.   ** Debian **
  Peter Palfrader   | : :' :  The  universal
 https://www.palfrader.org/ | `. `'  Operating System
|   `-https://www.debian.org/

Bug#511094: Uang 3 juta

[Muhammad Istamil Chaca tia]

chacatiamuhammadista...@gmail.com

Bug#987441: bug in Debian 11 RC Installer

[Luna Jernberg]

Hey!
This is now fixed in RC2 just tested :)
So this bug can be closed

On Mon, May 3, 2021 at 8:00 AM Luna Jernberg  wrote:

> Yeah, did not think about changing it to English, but yeah looks like it
> can be that, works in the text mode installer however
>
> On Mon, May 3, 2021 at 7:55 AM Cyril Brulebois  wrote:
>
>> Luna Jernberg  (2021-05-03):
>> > Gets stuck before it tries to download package from the mirrors
>>
>> Thanks, Luna.
>>
>> This is Swedish, right?
>>
>> It seems very likely to be yet another occurrence of this bug, that
>> usually triggers a title getting displayed but nothing else:
>>   https://bugs.debian.org/987587
>>
>> I'm currently working on it.
>>
>> Thanks for your report (we usually prefer people use reportbug to submit
>> bug reports, but your mail to the list was fine, especially since this
>> issue can easily be associated with existing reports).
>>
>>
>> Cheers,
>> --
>> Cyril Brulebois (k...@debian.org)
>> D-I release manager -- Release team member -- Freelance Consultant
>>
>

Bug#989912: libregexp-pattern-license-perl: No deterministic results are provided

[Jonas Smedegaard]

Quoting Walter Lozano (2021-06-16 04:12:23)
> On 6/15/21 9:17 PM, Jonas Smedegaard wrote:
> > Quoting Walter Lozano (2021-06-15 20:42:53)
> >> As as user of licensecheck I found it does not provide 
> >> deterministic results on some circumstances. And example of this is 
> >> gnutls28/m4/ax_code_coverage.m4 which is detected as UNKNOWN or 
> >> LGPL.
> >>
> >> After some debugging I found that the root cause could be in 
> >> libregexp-pattern-license-perl, I have proposed a fix which you 
> >> can find in
> >>
> >> https://salsa.debian.org/perl-team/modules/packages/libregexp-pattern-license-
> >> perl/-/merge_requests/1
> >>
> >> I hope you can help me to clarify this issue.
> > Great - thanks a lot!
> >
> > I suspect that this might be bug#982849.
> 
> Yes, it looks exactly the same issue I faced. I hope you can confirm 
> and fix it

I will certainly do that.


> > Please keep all conversation about the bug here - *not* at salsa.
> 
> Perfect, I will do that. To be honest I was not sure how to submit the 
> proposed fix, I also tried to submitted directly to
> 
> https://salsa.debian.org/build-common-team/regexp-pattern-license
> 
> but I was not able to see a way to send a MR.
> 
> Please advice what is the best way to contribute.

Sorry, I am aware that reporting issues can be confusing, and am happy 
that you figured out _some_ way to get your findings across.

I use salsa.debian.org as a place to publicly store the git repo but 
*not* to track issues or negotiate change proposals or run continuous 
integration tests or any other of the many things that Gitlab can do.

I use bugs.debian.org to track issues.

Best way to report and discuss issues is to use bugs.debian.org, and 
best way to propose a change is to attach a patch to an email sent to an 
issue tracked in bugs.debian.org.

As you are already aware, some parts of Licensecheck is maintained in 
other libraries.  Git repos exist separately for Debian packaging and 
upstream development of these libraries, but that should not matter for 
issue tracking.

E.g. https://metacpan.org/dist/App-Licensecheck/view/bin/licensecheck 
and https://metacpan.org/dist/App-Licensecheck links to 
https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=licensecheck for issue 
reporting, and https://www.debian.org/Bugs/Reporting covers issue 
reporting in Debian.

I find it unhelpful that salsa.debian.org by default enables duplicate 
issue tracking services, and I disable those to limit the risk of 
confusion - but sometimes I forget that, and also sometimes others that 
I collaborate with may disagree and (re)enable them.

If you have suggestions for ways I could maybe improve communicating how 
to best report issues, then please do share.


Kind regards,

 - Jonas

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

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

signature.asc
Description: signature

Bug#989924: ITP: dde-session-ui -- dde-session-ui module for Deepin Desktop Environment

[clay stan]

Package: wnpp
Severity: wishlist
Owner: Clay Stan 

* Package name: dde-session-ui
  Version : 5.4.6
  Upstream Author : Deepin Technology Co., Ltd.
* URL : https://github.com/linuxdeepin/dde-session-ui
* License : GPLv3
  Programming Lang: C++
  Description : dde-session-ui module for Deepin Desktop Environment

This project include those sub-project:
 * dde-shutdown: User interface of shutdown.
 * dde-lock: User interface of lock screen.
 * dde-lockservice: The back-end service of locking screen.
 * lightdm-deepin-greeter: The user interface when you login in.
 * dde-switchtogreeter: The tools to switch the user to login in.
 * dde-lowpower: The user interface of reminding low power.
 * dde-osd: User interface of on-screen display .
 * dde-hotzone: User interface of setting hot zone.

I intend to co-maintain this package inside pkg-deepin team.

Bug#989925: ITP: dde-file-manager -- File manager for Deepin Desktop Environment

[clay stan]

Package: wnpp
Severity: wishlist
Owner: Clay Stan 

* Package name: dde-file-manager
  Version : 5.2.0.85
  Upstream Author : Deepin Technology Co., Ltd.
* URL : https://github.com/linuxdeepin/dde-file-manager
* License : GPL-3+
  Programming Lang: C++
  Description : File manager for Deepin Desktop Environment

File manager front end of Deepin OS.

I intend to co-maintain this package inside pkg-deepin team.

Bug#989923: Tests fail when server is running 24x80 terminal

[Robert Ancell]

Package: notcurses
Version: 2.3.4+dfsg.1-2

This package is failing to build on Ubuntu due to the tests failing as the
terminal size is too small:
 notcurses 2.3.4 by nick black et al on XTerm [34m
  20 rows 76 cols (23.75KiB) 48B crend 8 colors
  compiled with gcc-10.3.0, 16B little-endian cells
  terminfo from ncurses 6.2.20201114
  avformat 58.45.100 avutil 56.51.100 swscale 5.7.100
...
At least an 76x24 terminal is required (current: 76x20)

This is due to the -m2 that is passed to notcurses-demo. If that is changed
to a -m0,2,0,2 (i.e. only have left and right margins) then the tests pass
as the height of the terminal is high enough. I'm not sure if these tests
are being run on the Debian build servers, and if they are why they pass
there.

Please consider changing the test to avoid this issue, thanks!

See https://launchpad.net/bugs/1932103 for the Ubuntu bug.

Bug#989834: konsole: Only possible to select the smallest available size for OpenType Bitmap fonts

[Norbert Preining]

Hi,

On Mon, 14 Jun 2021, Tim Small wrote:
> When selecting a bitmap font via Konsole -> Settings -> Configure
> Konsole -> Profiles -> Edit -> Appearance -> Font -> Choose, only the
> smallest font size is displayed for OpenType bitmap fonts.

I can confirm. 
But I am not sure whether this is a konsole problem or a font-config or
or whatever layer it is.

Could you please report this upstream to the kde bug tracker, thanks.

Best

Norbert

--
PREINING Norbert  https://www.preining.info
Fujitsu Research  +  IFMGA Guide  +  TU Wien  +  TeX Live  + Debian Dev
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Bug#989831: konsole: Bitmap fonts rendered incorrectly if display scaling is enabled

[Norbert Preining]

On Mon, 14 Jun 2021, Tim Small wrote:
> When a bitmap font is selected, and display scaling is also enabled (KDE
> -> System Settings -> Display Configuration -> Global scale != 100%),
> then the fonts are rendered at their unscaled size (this is expected for
> bitmap fonts), but instead each character is rendered with large amounts
> of surrounding space.
> 
> T h e   e f f e c t   i s   a   b i t   l i k e   t h i s ,  a n d   i s
> 
> n o t   u s a b l e .
> 
> I'm not sure if this is a konsole thing, or a qt/kde thing.

But isn't that what you are asking for by setting a global scale to != 100
???

I guess what happens is
- compute the box that the text would fill
- scale to to global scale
- set the text within the bigger box

Now that the bitmap fonts cannot be scaled, they are just equally spaced
out to fill the requested size.

I am not sure, but this is somehow what I would expect when using
unscalable fonts.

> p.s. I've tagged this as a11y because I use bitmap fonts AND high dpi
> displays to avoid chronic eye strain (without which I am limited to

I understand hidpi, but why bitmap fonts? vector fonts are also
converted to bitmaps and mostly at better quality, so they should
provide better readability and less strain.

Best

Norbert

--
PREINING Norbert  https://www.preining.info
Fujitsu Research  +  IFMGA Guide  +  TU Wien  +  TeX Live  + Debian Dev
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Bug#989908: konsole: not working fine when gitfm is called

[Norbert Preining]

Hi

First of all, could you please provide the information we asked you to:

On Tue, 15 Jun 2021, vimuser wrote:
> *** Reporter, please consider answering these questions, where appropriate ***
> 
>* What led up to the situation?
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
>* What was the outcome of this action?
>* What outcome did you expect instead?
> 
> *** End of the template - remove these template lines ***
> 
> * What led up to the situation?
> using konsole


I had to hunt down what gitfm is, in which package it is, and after that
it worked if you use a correct config file.

I have TERM=xterm-color256 and this copied
/usr/share/gnuit/gnuitrc.xterm-color
to
~/.gnuitrc.xterm-256color
and with that gitfm worked without any problems.

Thus, I consider this bug closed at least in the current version.

Norbert

--
PREINING Norbert  https://www.preining.info
Fujitsu Research  +  IFMGA Guide  +  TU Wien  +  TeX Live  + Debian Dev
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Bug#989922: thunderbird: testing: no external https images; NS_ERROR_NET_INADEQUATE_SECURITY?

[Aaron M. Ucko]

Package: thunderbird
Version: 1:78.11.0-1
Severity: important
X-Debbugs-Cc: team+pkg-mozi...@tracker.debian.org

The recent Thunderbird upgrade from 1:78.11.0-1~deb10u1 to 1:78.11.0-1
in testing broke loading of secure (https) external images.  I'd
expected this upgrade to be a formality; seeing as it evidently wasn't,
I suspect fallout from building against libnss3 2:3.66-1 but then
running against 2:3.61-1, and have copied the pkg-mozilla team
accordingly.

I see a new NS_ERROR_NET_INADEQUATE_SECURITY complaint at startup
concerning https://live.thunderbird.net/, and error console messages of
the form " : server does not support RFC 5746, see CVE-2009-3555"
though I'm not entirely certain the latter are new because I don't
normally have occasion to consult the error console. ;-)

Could you please take a look?

Thanks!

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

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

Versions of packages thunderbird depends on:
ii  debianutils  4.11.2
ii  fontconfig   2.13.1-4.2
ii  libatk1.0-0  2.36.0-2
ii  libbotan-2-172.17.3+dfsg-2
ii  libbz2-1.0   1.0.8-4
ii  libc62.31-12
ii  libcairo-gobject21.16.0-5
ii  libcairo21.16.0-5
ii  libdbus-1-3  1.12.20-2
ii  libdbus-glib-1-2 0.110-6
ii  libevent-2.1-7   2.1.12-stable-1
ii  libffi7  3.3-6
ii  libfontconfig1   2.13.1-4.2
ii  libfreetype6 2.10.4+dfsg-1
ii  libgcc-s110.2.1-6
ii  libgdk-pixbuf-2.0-0  2.42.2+dfsg-1
ii  libglib2.0-0 2.66.8-1
ii  libgtk-3-0   3.24.24-4
ii  libicu67 67.1-6
ii  libjson-c5   0.15-2
ii  libnspr4 2:4.29-1
ii  libnss3  2:3.61-1
ii  libpango-1.0-0   1.46.2-3
ii  libstdc++6   10.2.1-6
ii  libvpx6  1.9.0-1
ii  libx11-6 2:1.7.1-1
ii  libx11-xcb1  2:1.7.1-1
ii  libxcb-shm0  1.14-3
ii  libxcb1  1.14-3
ii  libxext6 2:1.3.3-1.1
ii  libxrender1  1:0.9.10-1
ii  psmisc   23.4-2
ii  x11-utils7.7+5
ii  zlib1g   1:1.2.11.dfsg-2

Versions of packages thunderbird recommends:
ii  hunspell-en-us [hunspell-dictionary]  1:2019.10.06-1

Versions of packages thunderbird suggests:
ii  apparmor  2.13.6-10
ii  fonts-lyx 2.3.6-1
ii  libgssapi-krb5-2  1.18.3-5
ii  libgtk2.0-0   2.24.33-2

-- no debconf information

Bug#989912: libregexp-pattern-license-perl: No deterministic results are provided

[Walter Lozano]

Hi Jonas,

On 6/15/21 9:17 PM, Jonas Smedegaard wrote:

Hi Walter,

Quoting Walter Lozano (2021-06-15 20:42:53)

Package: libregexp-pattern-license-perl
Version: 3.2.0-1
Severity: normal

Dear Maintainer,

As as user of licensecheck I found it does not provide deterministic results on
some circumstances. And example of this is gnutls28/m4/ax_code_coverage.m4
which is detected as UNKNOWN or LGPL.

After some debugging I found that the root cause could be in libregexp-pattern-
license-perl, I have proposed a fix which you can find in

https://salsa.debian.org/perl-team/modules/packages/libregexp-pattern-license-
perl/-/merge_requests/1

I hope you can help me to clarify this issue.

Great - thanks a lot!

I suspect that this might be bug#982849.


Yes, it looks exactly the same issue I faced. I hope you can confirm and 
fix it



Please keep all conversation about the bug here - *not* at salsa.


Perfect, I will do that. To be honest I was not sure how to submit the 
proposed fix, I also tried to submitted directly to


https://salsa.debian.org/build-common-team/regexp-pattern-license

but I was not able to see a way to send a MR.

Please advice what is the best way to contribute.

Thanks in advance.

Regards,

Walter

Bug#987181: RFS: cpufetch/0.97-1 -- Simple yet fancy CPU architecture fetching tool

[clay stan]

You are right. I have rebuild and uploaded to mentors.
https://mentors.debian.net/package/cpufetch

You can download the package with dget using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/c/cpufetch/cpufetch_0.98-1.dsc

Thanks.

Thomas Goirand  于2021年6月16日周三 上午7:09写道：
>
> On 6/15/21 2:37 PM, Tobias Frost wrote:
> > On Tue, Jun 15, 2021 at 02:12:20PM +0800, clay stan wrote:
> >> Tobias Frost  于2021年6月9日周三 上午2:03写道：
> >>>
> >> Add arm64 now.
> >
> > (Well, arm64 is clearly wrong…)
> >
> > I'd suggest just to (try) build for  "any" architecture. Even if the arch 
> > is not
> > supported, worst case that build fails. (Which is not a problem at all, 
> > especially
> > as this package is tiny and almost builds instantly.)
> >
> > With your hardcoded list you very likely miss some archs where cpufetch 
> > might work too.
> > The kfreebsd ports as an example.
> >
> > Just don't have artifical limits, please.
>
> Yeah, I agree with Tobias. Anyways, the Debian buildd system is capable
> of coping gracefully with failures on some arch: cpufetch just wont be
> available where it fails to build. So just let the buildd system do its
> job...
>
> Cheers,
>
> Thomas Goirand (zigo)

Bug#989921: ITP: golang-github-mb0-glob -- A configurable globbing and matching algorithm for go

[Arthur Diniz]

Package: wnpp
Severity: wishlist
Owner: Arthur Diniz 

* Package name: golang-github-mb0-glob
  Version : 0.0~git20160210.1eb79d2-1
  Upstream Author : Martin Schnabel
* URL : https://github.com/mb0/glob
* License : BSD-3-clause
  Programming Lang: Go
  Description : A configurable globbing and matching algorithm for go

 Configurable globbing and matching algorithm for go.
 .
 The package is based on the globbing and matching code from package
 path/filepath.

Bug#989920: jabberd2: ignores sm.d directory for realms

[Logan Rosen]

Package: jabberd2
Version: 2.7.0-1ubuntu1
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu impish

Hi,

This bug report was also filed in Ubuntu and can be found at
https://launchpad.net/bugs/1043637
The description, from Brian J. Murrell, follows:

The jabberd2 package includes an sm.d subdirectory of /etc/jabberd2/ where one 
is suppose to be able to configure additional realms/domains to be serviced by 
the jabberd2 instance.  This directory is completely ignored by the current 
startup scripts.  Pity.

Brian's proposed patch to debian/component.d/30sm is available here: 
https://bugs.launchpad.net/ubuntu/+source/jabberd2/+bug/1043637/+attachment/3283702/+files/30sm.patch

Thanks,
Logan

Bug#989919: login: consider setting PAM's user_readenv=1

[Christoph Anton Mitterer]

Package: login
Version: 1:4.8.1-1
Severity: wishlist


Hi.

Would it make sense to set PAM env’s user_readenv=1 in /etc/pam.d/login?
That would allow users to have a .pam_environment read, which would seem
a proper location for things like PATH, rather than .profile or .bashrc.


Cheers,
Chris.

Bug#989912: libregexp-pattern-license-perl: No deterministic results are provided

[Jonas Smedegaard]

Hi Walter,

Quoting Walter Lozano (2021-06-15 20:42:53)
> Package: libregexp-pattern-license-perl
> Version: 3.2.0-1
> Severity: normal
> 
> Dear Maintainer,
> 
> As as user of licensecheck I found it does not provide deterministic results 
> on
> some circumstances. And example of this is gnutls28/m4/ax_code_coverage.m4
> which is detected as UNKNOWN or LGPL.
> 
> After some debugging I found that the root cause could be in 
> libregexp-pattern-
> license-perl, I have proposed a fix which you can find in
> 
> https://salsa.debian.org/perl-team/modules/packages/libregexp-pattern-license-
> perl/-/merge_requests/1
> 
> I hope you can help me to clarify this issue.

Great - thanks a lot!

I suspect that this might be bug#982849.

Please keep all conversation about the bug here - *not* at salsa.


 - Jonas

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

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

signature.asc
Description: signature

Bug#989917: docker.io: docker "buildx" not found

[Elana Hashman]

Control: reassign -1 wnpp
Control: retitle -1 RFP: docker-buildx -- docker CLI plugin for BuildKit

* Package name: docker-buildx
  Version: 0.5.1
  Upstream Author: https://github.com/docker/buildx/blob/master/AUTHORS
* URL: https://github.com/docker/buildx
* License: Apache 2.0
  Description: Docker CLI plugin for extended build capabilities with BuildKit

On Tue, Jun 15, 2021 at 03:53:47PM -0700, Tianon Gravi wrote:
> 
> That'd be because it's not actually part of Docker proper; it just
> happens to be part of the releases Docker, Inc makes:
> 
> https://github.com/docker/buildx
> 
> It's a separate binary that can be placed in the appropriate place to
> be picked up and invoked by the Docker client, so I guess this should
> be converted to RFP or ITP depending on your level of interest in
> getting it into Debian. :)

I'm guilty of having too many ITPs assigned to me that I haven't gotten around
to, filing as an RFP.

- e


signature.asc
Description: PGP signature

Bug#989918: unblock: aeskeyfind/1:1.0-11

[Samuel Henrique]

Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: samuel...@debian.org
Severity: normal

Please unblock package aeskeyfind

[ Reason ]
The recent introduction of integration tests, thanks to Jan Gru <
j4n...@gmail.com> uncovered two critical issues with aeskeyfind:
1. A somewhat recent regression caused by compiler's change and
aeskeyfind's code with undefined behavior
2. Failure to retrieve AES keys on a non-corrupted memory dump for archs
arm64, armhf and ppc64el (integration tests only pass for amd64 and i386).

Problem 1 is fixed by a patch provided by Adrian Bunk  and
problem 2 is mitigated by disabling the other archs (restricting it to
amd64 and i386).

More details at the bugreport:
https://bugs.debian.org/989179

[ Impact ]
aeskeyfind will fail to fulfill its only purpose of finding AES keys on
memory dumps.

[ Tests ]
The new integration tests allowed us to identify the issues in the first
place.

[ Risks ]
Since aeskeyfind is also used to recover AES keys out of corrupted memory
dumps, it **could** be possible that our fix for the non-corrupted scenario
broke the detection for corrupted dumps. I'm very confident that this
cannot be the case because of the way aeskeyfind looks for keys; without
the fix it was still possible to retrieve the key by making use of the
threshold (-t 50) parameter (which tweaks the heuristics of the algorithm).
The fix allows us to use the default threshold value (-t 10) which means
the algorithm gets the key with more confidence.

[ 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 testing

unblock aeskeyfind/1:1.0-11


aeskeyfind_1.0-11.debdiff
Description: Binary data

Bug#506033: libscotchmetis-dev: Please add METIS_PartMesh* functions

[Drew Parsons]

On 2021-06-16 01:00, Drew Parsons wrote:


In regards to METIS_WPartGraphRecursive, METIS_WPartGraphKway in
FreeFoam, these were dropped when FreeFOAM rebranded as OpenFOAM,
which uses only METIS_PartGraphRecursive, METIS_PartGraphKway.


More precisely, FreeFOAM was a fork of OpenFOAM, now abandoned, which 
aimed to provide a cmake build system instead of wmake. FreeFOAM never 
pulled the OpenFOAM patches that removed the use of Metis v3 API.

Bug#987181: RFS: cpufetch/0.97-1 -- Simple yet fancy CPU architecture fetching tool

[Thomas Goirand]

On 6/15/21 2:37 PM, Tobias Frost wrote:
> On Tue, Jun 15, 2021 at 02:12:20PM +0800, clay stan wrote:
>> Tobias Frost  于2021年6月9日周三 上午2:03写道：
>>>
>> Add arm64 now.
> 
> (Well, arm64 is clearly wrong…)
> 
> I'd suggest just to (try) build for  "any" architecture. Even if the arch is 
> not
> supported, worst case that build fails. (Which is not a problem at all, 
> especially
> as this package is tiny and almost builds instantly.)
> 
> With your hardcoded list you very likely miss some archs where cpufetch might 
> work too.
> The kfreebsd ports as an example.
> 
> Just don't have artifical limits, please.

Yeah, I agree with Tobias. Anyways, the Debian buildd system is capable
of coping gracefully with failures on some arch: cpufetch just wont be
available where it fails to build. So just let the buildd system do its
job...

Cheers,

Thomas Goirand (zigo)

Bug#506033: libscotchmetis-dev: Please add METIS_PartMesh* functions

[Drew Parsons]

Package: libscotchmetis-dev
Followup-For: Bug #506033
Control: forwarded -1 
https://gitlab.inria.fr/scotch/scotch/-/issues/9#note_532579

In regards to METIS_WPartGraphRecursive, METIS_WPartGraphKway in
FreeFoam, these were dropped when FreeFOAM rebranded as OpenFOAM,
which uses only METIS_PartGraphRecursive, METIS_PartGraphKway. 

ie. Metis v5 compatibility is suitable for OpenFOAM (which also does
not use METIS_PartMesh* )

Bug#989917: docker.io: docker "buildx" not found

[Tianon Gravi]

On Tue, 15 Jun 2021 at 15:50, Elana Hashman  wrote:
> I can't find any patches or files under debian/copyright suggesting this
> functionality was patched out of the docker.io package.

That'd be because it's not actually part of Docker proper; it just
happens to be part of the releases Docker, Inc makes:

https://github.com/docker/buildx

It's a separate binary that can be placed in the appropriate place to
be picked up and invoked by the Docker client, so I guess this should
be converted to RFP or ITP depending on your level of interest in
getting it into Debian. :)

♥,
- Tianon
  4096R / B42F 6819 007F 00F8 8E36  4FD4 036A 9C25 BF35 7DD4

Bug#989917: docker.io: docker "buildx" not found

[Elana Hashman]

Package: docker.io
X-Debbugs-Cc: ehash...@debian.org
Version: 20.10.5+dfsg1-1+b3
Severity: important

When I try to run the `docker buildx build` command, even with experimental
features enabled, it fails:

ehashman@fedora:~$ docker buildx build
docker: 'buildx' is not a docker command.
See 'docker --help'
ehashman@fedora:~$ DOCKER_CLI_EXPERIMENTAL=enabled docker buildx build
docker: 'buildx' is not a docker command.
See 'docker --help'

I can't find any patches or files under debian/copyright suggesting this
functionality was patched out of the docker.io package.

The docker documentation suggests that this is included in the Docker system
packages,[1] and so I have encountered projects that assume it will be
available so long as experimental CLI features are enabled.[2] As far as I can
tell, buildx doesn't appear to be available either as part of the docker.io
Debian package nor as a separate package on Debian (e.g. docker-buildx or
similar).

Thanks in advance for the help!

- e

[1]: https://docs.docker.com/buildx/working-with-buildx/#install
[2]: https://github.com/kubernetes/kubernetes/issues/102822

-- System Information:
Debian Release: 11.0
  APT prefers testing-security
  APT policy: (500, 'testing-security'), (500, 'testing')
Architecture: amd64 (x86_64)

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

Versions of packages docker.io depends on:
ii  adduser  3.118
ii  containerd   1.4.5~ds1-1+b2
ii  init-system-helpers  1.60
ii  iptables 1.8.7-1
ii  libc62.31-12
ii  libdevmapper1.02.1   2:1.02.175-2.1
ii  libsystemd0  247.3-5
ii  lsb-base 11.1.0
ii  runc 1.0.0~rc93+ds1-5+b1
ii  tini 0.19.0-1

Versions of packages docker.io recommends:
ii  apparmor 2.13.6-10
ii  ca-certificates  20210119
ii  cgroupfs-mount   1.4
ii  git  1:2.30.2-1
ii  needrestart  3.5-4
ii  xz-utils 5.2.5-2

Versions of packages docker.io suggests:
pn  aufs-tools 
pn  btrfs-progs
ii  debootstrap1.0.123
ii  docker-doc 20.10.5+dfsg1-1
ii  e2fsprogs  1.46.2-1
pn  rinse  
pn  rootlesskit
pn  xfsprogs   
pn  zfs-fuse | zfsutils-linux  

-- no debconf information


signature.asc
Description: PGP signature

Bug#989909: mate-terminal: it ceashes unexpectly when gitfm is in use

[Mike Gabriel]

Hi,

On  Di 15 Jun 2021 19:22:18 CEST, vimuser wrote:


Package: mate-terminal
Version: 1.16.3-1
Severity: important

Dear Maintainer,

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


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

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

it crashes unexpectly when gitfm is in use


Please explain in more depth what you do exactly before the crash.

Also, please note that you reported this bug against a very older  
version of mate-terminal (1.16.3-1). I suppose you are in Debian 9.  
Please don't expect two much functionality support for this without a  
proper bug description and debugging help if needed.


Mike
--

DAS-NETZWERKTEAM
c\o Technik- und Ökologiezentrum Eckernförde
Mike Gabriel, Marienthaler Str. 17, 24340 Eckernförde
mobile: +49 (1520) 1976 148
landline: +49 (4351) 850 8940

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de



pgpFJ8deCtlvV.pgp
Description: Digitale PGP-Signatur

Bug#907576: . dream -- A Software Digital Radio Mondiale Receiver

[GMiller]

Hello Christoph

>Re: GMiller > For the subject project, I have encountered a roadblock while 
>attempting to use the 'Salsa Web Terminal'. I filed Gitlab Issue 233 (see 
>attachments) seeking information to prepare a 'gitlab-webide.yml' file (I 
>searched but could find no documentation on it). The response to 233 >says "To 
>upload designs, you'll need to enable LFS and have an admin enable hashed 
>storage".

>>Sorry, I can help you with packaging hamradio software, but please use a 
>>normal editor like everyone else. There is no need to bother with funky web 
>>stuff, especially if it doesn't work out of the box. Christoph

I am not sure I understand your comment. Are you saying in effect, don't use a 
Salsa IDE to build/test the project? Instead use an IDE on my local machine to 
build/test and develop any code changes? Is that how most Salsa projects are 
doing it?

Thanks for your patience

Garie Miller wb9awa

Sent with [ProtonMail](https://protonmail.com/) Secure Email.

Bug#989833: thunar: Thunar does not auto-refresh when directory contents are changed

[sudoer]

You are correct; I am using only a local filesystem. I am unfamiliar
with gio/gvfs, so if the issue is with them, I'll have to look into how
they work.

I tried the test you suggested: I ran 'thunar -q' from a terminal, then
ran a new thunar instance from the same terminal. I then navigated to an
empty directory, created an empty file using thunar, then deleted said
file using thunar. The results are the same; the file still appears
until the reload button is pressed. Unfortunately, there was no terminal
output, so it seems we're still in the dark.

I may dig through the source code to see if I can pinpoint what's going
on, but it's been a long while since I've done any programming, so I
might not be able to figure it out.

Bug#961183: metis: providing a 64-bit build

[Drew Parsons]

Package: metis
Followup-For: Bug #961183

Hi Fred, I guess the simple reason why there's no pkgconfig for Metis
is that upstream does not provide one.

We could add one ourselves easily enough.  But SCOTCH-Metis
compatibility would want to be taken into consideration.  Historically
SCOTCH-Metis never had full compatibility (#506033, #653647), but
they're about to make a new release expected to address that.

Bug#979665: [Pkg-rust-maintainers] Bug#979665: Please package libstd-rust-dev-emscripten

[Matt Corallo]

I'm not exactly an expert on the subject, but my understanding roughly matches yours. wasi is newer and not yet 100% 
feature complete, but once it is my understanding is that it should/will be a much better replacement for emscripten.


Matt

On 6/15/21 16:36, Ximin Luo wrote:

Thanks for the update.

Is there much point supporting rust emscripten at all? Apart from this 
C-linking thing that is now apparently fixed, what is the actual advantage (or 
even, point) of it?

 From what I understand from [1] it seems that emscripten does for C what 
wasm32-wasi and/or web-sys, js-sys already does for rust?

X

[1] 
https://stackoverflow.com/questions/64690937/what-is-the-difference-between-emscripten-and-clang-in-terms-of-webassembly-comp

Matt Corallo:

This is no longer the case. As of https://github.com/rust-lang/rust/pull/79998 
(rustc 1.51) you can now link C and rust code with the wasm32-wasi target.

On 1/9/21 16:16, Matt Corallo wrote:

Package: src:rustc
Version: 1.48.0+dfsg1-2

Due to issues with the way rustc interacts with LLVM-wasm [1], building rust 
packages with --target=wasm-unknown-{wasi,unknown} is not practical if any C 
code is to be used in the same binary (which is common). Instead, 
wasm-unknown-emscripten is the only option, however not librust-std is packaged 
for emscripten. rustup's emscripten is broken on debian testing due to them 
shipping their own LLVM, so that is also not a practical solution for most 
users wishing to link C and rust code in any context, let alone WASM.


[1] https://github.com/rustwasm/team/issues/291


___
Pkg-rust-maintainers mailing list
pkg-rust-maintain...@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-rust-maintainers

Bug#979665: [Pkg-rust-maintainers] Bug#979665: Please package libstd-rust-dev-emscripten

[Ximin Luo]

Thanks for the update.

Is there much point supporting rust emscripten at all? Apart from this 
C-linking thing that is now apparently fixed, what is the actual advantage (or 
even, point) of it?

>From what I understand from [1] it seems that emscripten does for C what 
>wasm32-wasi and/or web-sys, js-sys already does for rust?

X

[1] 
https://stackoverflow.com/questions/64690937/what-is-the-difference-between-emscripten-and-clang-in-terms-of-webassembly-comp
 

Matt Corallo:
> This is no longer the case. As of 
> https://github.com/rust-lang/rust/pull/79998 (rustc 1.51) you can now link C 
> and rust code with the wasm32-wasi target.
> 
> On 1/9/21 16:16, Matt Corallo wrote:
>> Package: src:rustc
>> Version: 1.48.0+dfsg1-2
>>
>> Due to issues with the way rustc interacts with LLVM-wasm [1], building rust 
>> packages with --target=wasm-unknown-{wasi,unknown} is not practical if any C 
>> code is to be used in the same binary (which is common). Instead, 
>> wasm-unknown-emscripten is the only option, however not librust-std is 
>> packaged for emscripten. rustup's emscripten is broken on debian testing due 
>> to them shipping their own LLVM, so that is also not a practical solution 
>> for most users wishing to link C and rust code in any context, let alone 
>> WASM.
>>
>>
>> [1] https://github.com/rustwasm/team/issues/291
> 
> ___
> Pkg-rust-maintainers mailing list
> pkg-rust-maintain...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-rust-maintainers


-- 
GPG: ed25519/56034877E1F87C35
https://github.com/infinity0/pubkeys.git

Bug#881901: #971: "management tunnel " ignores port

[OpenVPN Trac instance]

#971: "management tunnel " ignores port
-+-
 Reporter:  berni|   Owner:  (none)
 Type:  Bug / Defect |  Status:  new
 Priority:  minor|   Milestone:
Component:  Management   | Version:  OpenVPN 2.4.4
 Severity:  Not set (select this |  (Community Ed)
  one, unless your'e a OpenVPN   |  Resolution:
  developer) |
 Keywords:   |
-+-

Comment (by vetco):

 I'd just like to contribute that we would also like to use this feature,
 we have a VPN client that wants to know what connection is being used, the
 easiest way would be to connect to the management on the server and list
 the connection IP. This can't be done from the client daemon because it
 thinks it's IP is 192.168.*.*

-- 
Ticket URL: 
OpenVPN Community 
OpenVPN is a layer 2/3 SSL VPN

Bug#989916: unblock: gcc-mingw-w64/24.2

[Stephen Kitt]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Dear release team,

This is a pre-upload unblock request for gcc-mingw-w64, to fix a
regression affecting gcov support and profile-guided optimisation,
both of which are completely broken.

The proposed debdiff is attached.

unblock gcc-mingw-w64/24.2

Regards,

Stephen


-- System Information:
Debian Release: 10.9
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-debug'), (500, 'stable'), 
(100, 'unstable-debug'), (100, 'testing-debug'), (100, 'unstable'), (100, 
'testing'), (1, 'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, arm64

Kernel: Linux 4.19.0-12-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
commit 332aa0b9869ab48e4a4d80710d89c58c60b33c07
Author: Stephen Kitt 
Date:   Tue Jun 15 22:18:31 2021 +0200

Fix gcov handling

When gcov is supported in a cross-compiler setup, GCC assumes that
either the headers are present and shared with the host, or present
and set up in a sysroot, or absent. We have headers which aren’t
shared and aren’t in a sysroot, so we need to tell GCC where they are
*without* specifying them as an argument to --with-headers (the latter
must only be enabled).

Closes: #989682
LP: #1883933, #1920988

diff --git a/debian/changelog b/debian/changelog
index ace01f8..348b62a 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+gcc-mingw-w64 (24.2) unstable; urgency=medium
+
+  * Fix gcov handling: we need to tell GCC that we have headers, without
+telling it where, and then we need to correct its default assumption
+about where they are. Closes: #989682. LP: #1883933, #1920988.
+
+ -- Stephen Kitt   Sat, 12 Jun 2021 18:54:10 +0200
+
 gcc-mingw-w64 (24.1) unstable; urgency=medium
 
   * Update gcc-mingw-w64-base’s README.Debian with the switch to Dwarf2.
diff --git a/debian/patches/gcov.patch b/debian/patches/gcov.patch
index 4e9e610..5113282 100644
--- a/debian/patches/gcov.patch
+++ b/debian/patches/gcov.patch
@@ -1,10 +1,17 @@
-Description: Add __gcov_exit for gcov fallback
+Description: Fix gcov build issues
 Author: Stephen Kitt 
 
 When gcov is not supported on the target, gcc uses a fallback
 do-nothing implementation. That’s missing a __gcov_exit()
 implementation, causing linking errors.
 
+When gcov is supported in a cross-compiler setup, GCC assumes that
+either the headers are present and shared with the host, or present
+and set up in a sysroot, or absent. We have headers which aren’t
+shared and aren’t in a sysroot, so we need to tell GCC where they are
+*without* specifying them as an argument to --with-headers (the latter
+must only be enabled).
+
 --- a/src/libgcc/libgcov-driver.c
 +++ b/src/libgcc/libgcov-driver.c
 @@ -31,6 +31,7 @@
@@ -15,3 +22,14 @@ implementation, causing linking errors.
  #endif
  
  #else /* inhibit_libc */
+--- a/src/gcc/configure.ac
 b/src/gcc/configure.ac
+@@ -2268,7 +2268,7 @@
+   if test "x$with_build_sysroot" != "x"; then
+ target_header_dir="${with_build_sysroot}${native_system_header_dir}"
+   elif test "x$with_sysroot" = x; then
+-target_header_dir="${test_exec_prefix}/${target_noncanonical}/sys-include"
++target_header_dir="${test_exec_prefix}/${target_noncanonical}/include"
+   elif test "x$with_sysroot" = xyes; then
+ 
target_header_dir="${test_exec_prefix}/${target_noncanonical}/sys-root${native_system_header_dir}"
+   else
diff --git a/debian/patches/series1 b/debian/patches/series1
index eca45ad..89c05d4 100644
--- a/debian/patches/series1
+++ b/debian/patches/series1
@@ -1,2 +1,3 @@
 disable-multilib.patch
 reproducible-sort.patch
+gcov.patch
diff --git a/debian/patches/series2 b/debian/patches/series2
index 479f603..8c7122b 100644
--- a/debian/patches/series2
+++ b/debian/patches/series2
@@ -1,3 +1,2 @@
 reproducible-s-oscons.patch
-gcov.patch
 vmov-alignment.patch
diff --git a/debian/rules b/debian/rules
index fd0b6d7..b71f935 100755
--- a/debian/rules
+++ b/debian/rules
@@ -217,9 +217,9 @@ CONFFLAGS = \
--libdir=/$(PF)/$(libdir) \
--enable-libstdcxx-time=yes \
--with-tune=generic
-# Tell GCC where the headers are (this enables gcov)
+# Tell GCC we have headers (this enables gcov)
 CONFFLAGS += \
-   --with-headers=/usr/$$target/include
+   --with-headers
 # MinGW-w64 flags
 # version-specific-runtime-libs puts target-specific libraries in
 # /usr/lib/gcc rather than /usr/$(target)

Bug#951764: openjdk-11: Crash with qemu-s390x-static

[Thorsten Glaser]

On Fri, 21 Feb 2020, Michael R. Crusoe wrote:

> Installing openjdk-11-jre-headless:s390x in a s390x chroot on an amd64
> host with qemu-s390x-static produces the following crash:
[…]

This is almost certainly #986022 in qemu-user-static.

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

*

Mit unserem Consulting bieten wir Unternehmen maßgeschneiderte Angebote in
Form von Beratung, Trainings sowie Workshops in den Bereichen
Softwaretechnologie, IT Strategie und Architektur, Innovation und Umsetzung
sowie Agile Organisation.

Besuchen Sie uns auf https://www.tarent.de/consulting .
Wir freuen uns auf Ihren Kontakt.

*

Bug#989915: RFS: minidb/2.0.5-1 -- simple SQLite3-based store for Python objects

[Maxime Werlen]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: minidb
   Version : 2.0.5-1
   Upstream Author : Thomas Perl 
 * URL : https://thp.io/2010/minidb/
 * License : ISC
 * Vcs : https://salsa.debian.org/mwerlen/minidb
   Section : python

It builds those binary packages:

  python3-minidb - simple SQLite3-based store for Python objects

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/m/minidb/minidb_2.0.5-1.dsc

Changes since the last upload:

 minidb (2.0.5-1) experimental; urgency=medium
 .
   * New upstream release
   * Clean README of status buttons
   * Upstream renamed README to README.md
   * Bump standards version
   * Update copyright years
   * Add a Vcs-Browser field
   * Update uscan config file version
   * Bump to compat 13 and use debhelper-compat virtual package
   * Add an explicit Rules-Requires-Root field (value no)

Regards,
-- 
  Maxime Werlen

Bug#989914: inotify-tools: Invalid licensing GPL-2.1+ in debian/copyright

[Joao Eriberto Mota Filho]

Package: inotify-tools
Version: 3.14-8.1
Severity: important
X-Debbugs-Cc: eribe...@debian.org

Dear Maintainer,

I noticed in debian/copyright some paragraphs listing "GPL-2.1+" as licensing.
The full text used for this license was from GPL-2.

No more comments.

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

Bug#989551: linux-image-5.10.0-7-amd64: linux-image-5.10.0.7-amd64 hang on boot. Shows symbols: '^@^@^@' and nothing else. Debian testing.

[Salvatore Bonaccorso]

Hi,

On Tue, Jun 15, 2021 at 10:05:29AM +0300, Михаил Осипов wrote:
> Sorry, missed this message. Here are the logs. Several boots with and
> without recovery mode. Last one with old kernel.

Thanks for provinding those, much appreciated and it helps. So from
the boot logs this might be amdgpu related. Am I correct, you can
reach the host after bootup via a SSH login?

Would you be able to:

- Test directly upstream both 5.10.28, 5.10.40 (and 5.10.44 to be
  relased tomorrow)?
- If triggerable between 5.10.28 and 5.10.44: bisect to find the
  introducing upstream commit?

Some indication on how to build:

https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html

and

https://wiki.debian.org/DebianKernel/GitBisect

Regards,
Salvatore

Bug#920562: ca-certificates-java: postinst fails under qemu-aarch64-static ⇒ is a qemu issue

[Thorsten Glaser]

reassign 920562 qemu-user-static
forcemerge 986022 920562
thanks

This is pretty much the same issue, just for arm64 emulation.

bye,
//mirabilos
-- 
Gestern Nacht ist mein IRC-Netzwerk explodiert. Ich hatte nicht damit
gerechnet, darum bin ich blutverschmiert… wer konnte ahnen, daß SIE so
reagier’n… gestern Nacht ist mein IRC-Netzwerk explodiert~~~
(as of 2021-06-15 The MirOS Project temporarily reconvenes on OFTC)

Bug#988234: unblock: acorn/8.0.5+ds+~cs19.19.27-2

[Yadd]

Control: tags -1 - moreinfo

Control: retitle -1 unblock: acorn/8.0.5+ds+~cs19.19.27-3

Le 15/06/2021 à 20:59, Paul Gevers a écrit :
> Control: tag -1 moreinfo
> 
> Hi Yadd,
> 
> On Thu, 20 May 2021 11:29:15 +0200 Paul Gevers  wrote:
>> Control: tag -1 confirmed moreinfo
>>
>> Hi Yadd,
>>
>> On 08-05-2021 13:30, Yadd wrote:
>>> [ Reason ]
>>> Buster to Bullseye transition needs a real node-acorn package (#986134)
>>
>> I pinged ftp on IRC some days ago, but the package didn't land yet. We
>> need the package in the archive to unblock. Please remove the moreinfo
>> tag once you receive the notification that the package is processed.
> 
> I noticed that you removed the moreinfo tag, but because you had to
> traverse NEW we now have:
> Not built on buildd: arch all binaries uploaded by x.guim...@free.fr, a
> new source-only upload is needed to allow migration
> 
> We can't sensibly binNMU arch:all packages. Can you do an no-change
> source-only upload to have the binaries build on the buildd please? If
> not, shout and I can have a stab at it.
> 
> Paul

Done, sorry for that

Cheers,
Yadd

Bug#989913: ITP: golang-github-zmap-rc2 -- RC2 library in Go

[Peymaneh Nejad]

Package: wnpp
Severity: wishlist
Owner: Peymaneh Nejad 

* Package name: golang-github-zmap-rc2
  Version : 0.0~git20190804.abaa705-1
  Upstream Author : The ZMap Project
* URL : https://github.com/zmap/rc2
* License : Apache-2.0
  Programming Lang: Go
  Description : RC2 library in Go
 A crypto/cipher cipher.Block interface, just like AES. 

Dependency of github.com/smallstep/zcrypto, which is a dependency of 
github.com/smallstep/cli, which is a dependency of the caddy webserver

Bug#989744: libqt5core5a: 5.15.2+dfsg-7 breaks MIME subclassing logic (which breaks some features in e.g. Dolphin)

[Dennis Filder]

On Tue, Jun 15, 2021 at 09:41:39PM +0300, Dmitry Shachnev wrote:

> Following what Lisandro said, I will not upload the revert to unstable.
>
> Dennis, please contact the upstream Qt developers, and if they revert that
> part of the patch or change the code to make your use case work, I will be
> happy to backport those fixes to our package.

Not necessary.  In the meantime I figured out what the XDG people want
you to do if you wish to associate an application with every MIME
type: associate it with "application/octet-stream" (to which every
other MIME type is implicitly subclassed) and
"application/x-zerosize".  Looking at it from very far away it even
makes sense somewhat.

So, for all I know this can be closed.

Regards,
Dennis.

Bug#989839: Bug#989843: thunderbird: Problem loading page: NS_ERROR_NET_INADEQUATE_SECURITY

[Carsten Schoenert]

Control: tags 989839 severity important
Control: tags 989843 severity important
Control: merge 989843 989839
thanks

Hello *,

decreasing the severity as Thunderbird isn't *completely* unusable.

Am 14.06.21 um 19:31 schrieb Todor Tsankov:
> Dear Maintainer,
> 
> Since the update to 78.11.0 Thunderbird cannot load various webpages. To
> reproduce the error, try to do a search in the Add-ons Manager (type
> something in the search box and press Enter).
> 
> The error message is
> 
> "The website tried to negotiate an inadequate level of security.
> ...
> Error code: NS_ERROR_NET_INADEQUATE_SECURITY"
> 
> There is perhaps a more useful error message in the error console:
> 
> addons.thunderbird.net : server does not support RFC 5746, see CVE-2009-3555

Well, both messages are almost enough information to step into an
analysis and search for data on various internet web sites.

There are quite some web resources out there that explain what's going
wrong here (beside we don't know exactly why). I'm quoting from
https://support.mozilla.org/en-US/questions/1312785

-%<-

> NS_ERROR_NET_INADEQUATE_SECURITY indicates that the server initiates
> a HTTP/2 connection, but Firefox detects an invalid TLS configuration
> in the server response (server negotiated HTTP/2 with blacklisted
> cipher suites). This is likely not an issue with the certificate, but
> this is a problem with the server setup and there are invalid cipher
> suites for HTTP/2 claimed (INADEQUATE_SECURITY).>
> http://httpwg.org/specs/rfc7540.html#TLSUsage There might also be
> other software that acts as a MITM and is interfering. When HTTP/2 is
> enabled and used then the requirements are much stricter than with
> HTTP/1.1 You can get the NS_ERROR_NET_INADEQUATE_SECURITY error
> message in case the server isn't configured properly.>
> A workaround to fix this ANNOYING issue is;
> network.http.spdy.enabled.http2 = false in about:config

->%-

So, to recap:
The server is sending over a HTTP/2 connection, but Thunderbird, or more
precisely the NSS3 library (depending on the configuration of
Thunderbird) is detecting some invalid TLS data and is
stopping the communication by presenting this message about
NS_ERROR_NET_INADEQUATE_SECURITY because the settings are that strict to
not going further.

> The problem also appears when trying to load other pages or using
> certain add-ons (for example, calendar-google-provider).
> 
> The problem goes away if one sets network.http.spdy.enforce-tls-profile
> to false in the preferences. This makes me think that there is an issue
> with the TLS library.

This isn't a problem solution, it's a workaround that disables the TLS
validation check. And if Thunderbird is instructed to ignore any
security settings related to SSL/TLS it's not really surprising that the
previously seen issues seems to have gone.

Currently I've no real idea what's the reason why 78.11.0 is working
differently than the previous version 78.10.x.
And further more it's also possible that the external resources have a
real problem regarding the TLS settings. This needs clarification and
analysis of the underlying data flow.

Both Thunderbird versions 78.10.x and 78.11.x are using the same
underlying libnss3 version, that hasn't changed since 2021-02-18. That's
the main difference to the Thunderbird version in stable-security, there
we use the internal shipped NSS3 source to build the packages and so far
we haven't seen bug reports from stable users.

The build checks for a minimum required NSS3 version.

> 0:10.34 checking for nss >= 3.53.1... yes

In the archive we have 3.61 so it's clear the check is passing. The
upstream source for Thunderbird 78.11.0 comes with NSS3 version 3.51.1
and this hasn't changed since the introducing of Thunderbird ESR series
78.x.

In can currently only think of some other different internal behavior of
78.11.0 together with NSS3 from the system.
The changelog from Mozilla for 78.11.0 isn't giving any hint that some
upstream modification might be the reason for the different behavior.

Closed bug reports between 78.10.2 and 78.11.0

> https://bugzilla.mozilla.org/buglist.cgi?bug_id=1709046%2C1697252%2C1712469%2C1700279%2C1695592%2C1709492%2C1704161%2C1707569%2C1712610%2C1712632%2C1712293

Closed bug reports between 78.10.1 and 78.10.2

> https://bugzilla.mozilla.org/buglist.cgi?bug_id=1673241%2C1701924%2C1709261%2C1654893%2C1658216%2C1701908%2C1707408%2C1702582%2C1697075%2C1707021%2C1691297%2C1701356%2C1710290%2C1692616%2C1671051%2C1686984%2C1681131%2C1673277%2C1679713%2C1704435

So to work around the problems users can do the following modification
to their profile settings.

Set network.http.spdy.enforce-tls-profile = false

If this isn't working this setting can set to false also

set network.http.spdy.enabled.http2 = false

But please note!
This decreases the transport security and should later get get reset to
the default, if not Thunderbird will use the insecure setting for ever!

-- 
Regards
Car

Bug#988234: unblock: acorn/8.0.5+ds+~cs19.19.27-2

[Paul Gevers]

Control: tag -1 moreinfo

Hi Yadd,

On Thu, 20 May 2021 11:29:15 +0200 Paul Gevers  wrote:
> Control: tag -1 confirmed moreinfo
> 
> Hi Yadd,
> 
> On 08-05-2021 13:30, Yadd wrote:
> > [ Reason ]
> > Buster to Bullseye transition needs a real node-acorn package (#986134)
> 
> I pinged ftp on IRC some days ago, but the package didn't land yet. We
> need the package in the archive to unblock. Please remove the moreinfo
> tag once you receive the notification that the package is processed.

I noticed that you removed the moreinfo tag, but because you had to
traverse NEW we now have:
Not built on buildd: arch all binaries uploaded by x.guim...@free.fr, a
new source-only upload is needed to allow migration

We can't sensibly binNMU arch:all packages. Can you do an no-change
source-only upload to have the binaries build on the buildd please? If
not, shout and I can have a stab at it.

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#989912: libregexp-pattern-license-perl: No deterministic results are provided

[Walter Lozano]

Package: libregexp-pattern-license-perl
Version: 3.2.0-1
Severity: normal

Dear Maintainer,

As as user of licensecheck I found it does not provide deterministic results on
some circumstances. And example of this is gnutls28/m4/ax_code_coverage.m4
which is detected as UNKNOWN or LGPL.

After some debugging I found that the root cause could be in libregexp-pattern-
license-perl, I have proposed a fix which you can find in

https://salsa.debian.org/perl-team/modules/packages/libregexp-pattern-license-
perl/-/merge_requests/1

I hope you can help me to clarify this issue.

Thanks in advance.



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

Kernel: Linux 5.8.0-53-generic (SMP w/8 CPU cores)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libregexp-pattern-license-perl depends on:
ii  libre-engine-re2-perl  0.13-5
ii  perl   5.30.0-9ubuntu0.2

libregexp-pattern-license-perl recommends no packages.

libregexp-pattern-license-perl suggests no packages.

-- no debconf information

Bug#989744: libqt5core5a: 5.15.2+dfsg-7 breaks MIME subclassing logic (which breaks some features in e.g. Dolphin)

[Dmitry Shachnev]

Hi all,

On Mon, Jun 14, 2021 at 09:41:13AM -0300, Lisandro Damián Nicanor Pérez Meyer 
wrote:
> Now I understand your use case, but it really sounds more like a hack
> than the proper way of doing things.
>
> In my point of view you should reach KDE devs, explain them why you
> need this functionality and convince them to support it. My guess is
> that a flag in dolphin's config in order to get you all the options
> would be just enough.

Following what Lisandro said, I will not upload the revert to unstable.

Dennis, please contact the upstream Qt developers, and if they revert that
part of the patch or change the code to make your use case work, I will be
happy to backport those fixes to our package.

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#989901: postfix: ipv6 CIDR not correct in mynetwork documentation

[tootai]

Package: postfix
Version: 3.4.14-0+deb10u1
Severity: normal

Dear Maintainer,

postfix documentation say ipv6 addresses has to be given in the form of 
[::1]/128 [fe80::]/10 [2001:240:587::]/64 which is false a least
when using a file like 

root@wwwmail10:/etc/postfix# postconf mynetworks
mynetworks = hash:/etc/postfix/allowed-networks

and /etc/postfix/allowed-networks

[::1]/128
[fe80::]/10
[2001:240:587::]/64 

In this case we receive a rely access denied

if we change to something like

2001:240:587::1

it's working but CIDR no more available.


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

Kernel: Linux 4.19.0-16-amd64 (SMP w/2 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages postfix depends on:
ii  adduser3.118
ii  cpio   2.12+dfsg-9
ii  debconf [debconf-2.0]  1.5.71
ii  dpkg   1.19.7
ii  e2fsprogs  1.44.5-1+deb10u3
ii  libc6  2.28-10
ii  libdb5.3   5.3.28+dfsg1-0.5
ii  libicu63   63.1-6+deb10u1
ii  libsasl2-2 2.1.27+dfsg-1+deb10u1
ii  libssl1.1  1.1.1d-0+deb10u6
ii  lsb-base   10.2019051400
ii  netbase5.6
ii  ssl-cert   1.0.39

Versions of packages postfix recommends:
ii  python3  3.7.3-1

Versions of packages postfix suggests:
ii  bsd-mailx [mail-reader]8.1.2-0.20180807cvs-1
ii  dovecot-core [dovecot-common]  1:2.3.4.1-5+deb10u6
ii  libsasl2-modules   2.1.27+dfsg-1+deb10u1
ii  mutt [mail-reader] 1.10.1-2.1+deb10u5
pn  postfix-cdb
pn  postfix-doc
pn  postfix-ldap   
pn  postfix-lmdb   
pn  postfix-mysql  
pn  postfix-pcre   
pn  postfix-pgsql  
ii  postfix-sqlite 3.4.14-0+deb10u1
ii  procmail   3.22-26
pn  resolvconf 
ii  sasl2-bin  2.1.27+dfsg-1+deb10u1
pn  ufw

-- debconf information excluded

Bug#989911: unblock: procmeter3/3.6-3

[Josue Ortega]

Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: unblock

Dear Release Team,

Please consider to unblock procmeter3/3.6-3, this new revision
fixes a serious bug that renders procmeter3 unusable.
Here is the changelog:

procmeter3 (3.6-3) unstable; urgency=medium

* Add patch debian/patches/00-fix-undef-symbol-minor in order to use specific
header file for definition of Linux kernel 'major' and 'minor'
macros. Closes: #932008

-- Josue Ortega   Sat, 05 Jun 2021 21:42:08 -0600

I have attached the debdiff

Cheers

--Josuediff -Nru procmeter3-3.6/debian/changelog procmeter3-3.6/debian/changelog
--- procmeter3-3.6/debian/changelog	2019-01-05 12:04:01.0 -0600
+++ procmeter3-3.6/debian/changelog	2021-06-05 21:42:08.0 -0600
@@ -1,3 +1,11 @@
+procmeter3 (3.6-3) unstable; urgency=medium
+
+  * Add patch debian/patches/00-fix-undef-symbol-minor in order to use specific
+header file for definition of Linux kernel 'major' and 'minor'
+macros. Closes: #932008
+
+ -- Josue Ortega   Sat, 05 Jun 2021 21:42:08 -0600
+
 procmeter3 (3.6-2) unstable; urgency=medium
 
   * Add co-maintainer.
diff -Nru procmeter3-3.6/debian/patches/00-fix-undef-symbol-minor.patch procmeter3-3.6/debian/patches/00-fix-undef-symbol-minor.patch
--- procmeter3-3.6/debian/patches/00-fix-undef-symbol-minor.patch	1969-12-31 18:00:00.0 -0600
+++ procmeter3-3.6/debian/patches/00-fix-undef-symbol-minor.patch	2021-06-05 21:42:08.0 -0600
@@ -0,0 +1,15 @@
+Description: Use specific header file for definition of Linux kernel 'major' and
+'minor' macros (due to compilation warning). 
+Origin: https://www.gedanken.org.uk/viewvc/procmeter3/trunk/modules/stat-disk.c?view=patch&r1=407&r2=406&pathrev=407
+Last-Update: 2021-06-05
+
+--- a/modules/stat-disk.c
 b/modules/stat-disk.c
+@@ -25,6 +25,7 @@
+ #include 
+ 
+ #include 
++#include 
+ 
+ #include "procmeter.h"
+ 
diff -Nru procmeter3-3.6/debian/patches/series procmeter3-3.6/debian/patches/series
--- procmeter3-3.6/debian/patches/series	2019-01-05 12:04:01.0 -0600
+++ procmeter3-3.6/debian/patches/series	2021-06-05 21:42:08.0 -0600
@@ -2,6 +2,7 @@
 #locations.patch
 #lib_loc.patch
 #modules.patch
+00-fix-undef-symbol-minor.patch
 examples.patch
 #include.patch
 dont-override-flags.patch


signature.asc
Description: PGP signature

Bug#989864: unblock: distro-info-data/0.48

[stefanor]

Control: retitle -1 unblock: distro-info-data/0.49

And we have unrelated change, tweaking Ubuntu EoL dates. With test
coverage:

 distro-info-data (0.49) unstable; urgency=medium
  .
* Move Ubuntu EoLs off weekends.
* Validate that Ubuntu EoLs occur during the week.

Updated debdiff against testing, attached.

unblock distro-info-data/0.49

SR

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272
diff -Nru distro-info-data-0.47/debian/changelog 
distro-info-data-0.49/debian/changelog
--- distro-info-data-0.47/debian/changelog  2021-04-22 10:30:18.0 
-0400
+++ distro-info-data-0.49/debian/changelog  2021-06-15 13:46:40.0 
-0400
@@ -1,6 +1,21 @@
+distro-info-data (0.49) unstable; urgency=medium
+
+  * Move Ubuntu EoLs off weekends.
+  * Validate that Ubuntu EoLs occur during the week.
+
+ -- Stefano Rivera   Tue, 15 Jun 2021 13:46:40 -0400
+
+distro-info-data (0.48) unstable; urgency=medium
+
+  * Correct typo in changelog.
+  * Set a release date for Debian bullseye (and bookworm creation), based on
+the release team's tentative estimate.
+
+ -- Stefano Rivera   Mon, 14 Jun 2021 17:47:09 -0400
+
 distro-info-data (0.47) unstable; urgency=medium
 
-  * Add Ubuntu 21.04, Impish Indri.
+  * Add Ubuntu 21.10, Impish Indri.
 
  -- Stefano Rivera   Thu, 22 Apr 2021 10:30:18 -0400
 
diff -Nru distro-info-data-0.47/debian.csv distro-info-data-0.49/debian.csv
--- distro-info-data-0.47/debian.csv2021-04-22 10:30:18.0 -0400
+++ distro-info-data-0.49/debian.csv2021-06-15 13:46:40.0 -0400
@@ -14,8 +14,8 @@
 8,Jessie,jessie,2013-05-04,2015-04-25,2018-06-17,2020-06-30,2022-06-30
 9,Stretch,stretch,2015-04-25,2017-06-17,2020-07-06,2022-06-30
 10,Buster,buster,2017-06-17,2019-07-06,2022-07-06,2024-06-30
-11,Bullseye,bullseye,2019-07-06
-12,Bookworm,bookworm,2021-08-01
+11,Bullseye,bullseye,2019-07-06,2021-07-31,2024-07-31
+12,Bookworm,bookworm,2021-07-31
 13,Trixie,trixie,2023-08-01
 ,Sid,sid,1993-08-16
 ,Experimental,experimental,1993-08-16
diff -Nru distro-info-data-0.47/ubuntu.csv distro-info-data-0.49/ubuntu.csv
--- distro-info-data-0.47/ubuntu.csv2021-04-22 10:30:18.0 -0400
+++ distro-info-data-0.49/ubuntu.csv2021-06-15 13:46:40.0 -0400
@@ -22,7 +22,7 @@
 14.10,Utopic Unicorn,utopic,2014-04-17,2014-10-23,2015-07-23
 15.04,Vivid Vervet,vivid,2014-10-23,2015-04-23,2016-02-04
 15.10,Wily Werewolf,wily,2015-04-23,2015-10-22,2016-07-28
-16.04 LTS,Xenial 
Xerus,xenial,2015-10-22,2016-04-21,2021-04-21,2021-04-21,2024-04-21
+16.04 LTS,Xenial 
Xerus,xenial,2015-10-22,2016-04-21,2021-04-21,2021-04-21,2024-04-23
 16.10,Yakkety Yak,yakkety,2016-04-21,2016-10-13,2017-07-20
 17.04,Zesty Zapus,zesty,2016-10-13,2017-04-13,2018-01-13
 17.10,Artful Aardvark,artful,2017-04-13,2017-10-19,2018-07-19
@@ -32,5 +32,5 @@
 19.10,Eoan Ermine,eoan,2019-04-18,2019-10-17,2020-07-17
 20.04 LTS,Focal 
Fossa,focal,2019-10-17,2020-04-23,2025-04-23,2025-04-23,2030-04-23
 20.10,Groovy Gorilla,groovy,2020-04-23,2020-10-22,2021-07-22
-21.04,Hirsute Hippo,hirsute,2020-10-22,2021-04-22,2022-01-22
+21.04,Hirsute Hippo,hirsute,2020-10-22,2021-04-22,2022-01-20
 21.10,Impish Indri,impish,2021-04-22,2021-10-14,2022-07-14
diff -Nru distro-info-data-0.47/validate-csv-data 
distro-info-data-0.49/validate-csv-data
--- distro-info-data-0.47/validate-csv-data 2021-04-22 10:30:18.0 
-0400
+++ distro-info-data-0.49/validate-csv-data 2021-06-15 13:46:40.0 
-0400
@@ -21,6 +21,7 @@
 
 import csv
 import sys
+from datetime import date
 
 from lib.tools import convert_date, main
 
@@ -142,6 +143,17 @@
 )
 error(filename, csvreader.line_num, msg, date1, date2)
 failures += 1
+# Check that Ubuntu EOL lands on a weekday
+if distro == 'ubuntu':
+for column, eol_date in row.items():
+if not column.startswith('eol'):
+continue
+if not eol_date:
+continue
+if eol_date.weekday() > 5 and eol_date >= date(2021, 1, 1):
+msg = '%s for %s lands on a weekend (%s)'
+error(filename, csvreader.line_num, msg, column,
+  row['codename'], date)
 
 return failures == 0
 

Bug#989910: ipwatchd-gnotify FTCBFS: builds for the build architecture

[Helmut Grohne]

Source: ipwatchd-gnotify
Version: 1.0.1-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

ipwatchd-gnotify fails to cross build from source, because it does not
pass cross tools to make. The easiest way of fixing that - using
dh_auto_build - does not fully make it cross buildable, because
src/Makefile hard codes the build architecture pkg-config. After making
it substitutable, ipwatchd-gnotify cross builds successfully. Please
consider applying the attached patch.

Helmut
diff --minimal -Nru ipwatchd-gnotify-1.0.1/debian/changelog 
ipwatchd-gnotify-1.0.1/debian/changelog
--- ipwatchd-gnotify-1.0.1/debian/changelog 2011-07-24 22:36:26.0 
+0200
+++ ipwatchd-gnotify-1.0.1/debian/changelog 2021-06-15 19:41:26.0 
+0200
@@ -1,3 +1,12 @@
+ipwatchd-gnotify (1.0.1-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: (Closes: #-1)
++ Let dh_auto_build pass cross tools to make.
++ cross.patch: Make pkg-config substitutable.
+
+ -- Helmut Grohne   Tue, 15 Jun 2021 19:41:26 +0200
+
 ipwatchd-gnotify (1.0.1-1) unstable; urgency=low
 
   * Updated to upstream release 1.0.1
diff --minimal -Nru ipwatchd-gnotify-1.0.1/debian/patches/cross.patch 
ipwatchd-gnotify-1.0.1/debian/patches/cross.patch
--- ipwatchd-gnotify-1.0.1/debian/patches/cross.patch   1970-01-01 
01:00:00.0 +0100
+++ ipwatchd-gnotify-1.0.1/debian/patches/cross.patch   2021-06-15 
19:41:26.0 +0200
@@ -0,0 +1,16 @@
+--- ipwatchd-gnotify-1.0.1.orig/src/Makefile
 ipwatchd-gnotify-1.0.1/src/Makefile
+@@ -3,9 +3,10 @@
+ 
+ CC= gcc
+ CFLAGS= -g -Wall -O2
+-GTK_CFLAGS=`pkg-config --cflags gtk+-2.0`
+-LIBNOTIFY_CFLAGS=`pkg-config --cflags libnotify`
+-LIBNOTIFY_LIBS=`pkg-config --libs libnotify`
++PKG_CONFIG?=pkg-config
++GTK_CFLAGS=`$(PKG_CONFIG) --cflags gtk+-2.0`
++LIBNOTIFY_CFLAGS=`$(PKG_CONFIG) --cflags libnotify`
++LIBNOTIFY_LIBS=`$(PKG_CONFIG) --libs libnotify`
+ 
+ all: ipwatchd-gnotify.c ipwatchd-gnotify.h
+   $(CC) $(CFLAGS) $(GTK_CFLAGS) $(LIBNOTIFY_CFLAGS) ipwatchd-gnotify.c -o 
ipwatchd-gnotify $(LIBNOTIFY_LIBS)
diff --minimal -Nru ipwatchd-gnotify-1.0.1/debian/patches/series 
ipwatchd-gnotify-1.0.1/debian/patches/series
--- ipwatchd-gnotify-1.0.1/debian/patches/series1970-01-01 
01:00:00.0 +0100
+++ ipwatchd-gnotify-1.0.1/debian/patches/series2021-06-15 
19:41:26.0 +0200
@@ -0,0 +1 @@
+cross.patch
diff --minimal -Nru ipwatchd-gnotify-1.0.1/debian/rules 
ipwatchd-gnotify-1.0.1/debian/rules
--- ipwatchd-gnotify-1.0.1/debian/rules 2011-07-24 22:29:25.0 +0200
+++ ipwatchd-gnotify-1.0.1/debian/rules 2021-06-15 19:41:24.0 +0200
@@ -9,7 +9,7 @@
 
 build-stamp: 
dh_testdir
-   $(MAKE) -C src
+   dh_auto_build --sourcedirectory=src
touch $@
 
 # Added just to remove lintian warning debian-rules-missing-recommended-target

Bug#989909: mate-terminal: it ceashes unexpectly when gitfm is in use

[vimuser]

Package: mate-terminal
Version: 1.16.3-1
Severity: important

Dear Maintainer,

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

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

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

it ceashes unexpectly when gitfm is in use

-- System Information:
Debian Release: 9.13
  APT prefers oldstable
  APT policy: (500, 'oldstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.9.0-15-amd64 (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE= 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages mate-terminal depends on:
ii  gsettings-desktop-schemas  3.22.0-1
ii  libatk1.0-02.22.0-1
ii  libc6  2.24-11+deb9u4
ii  libcairo-gobject2  1.14.8-1+deb9u1
ii  libcairo2  1.14.8-1+deb9u1
ii  libdconf1  0.26.0-2+b1
ii  libgdk-pixbuf2.0-0 2.36.5-2+deb9u2
ii  libglib2.0-0   2.50.3-2+deb9u2
ii  libgnutls303.5.8-5+deb9u5
ii  libgtk-3-0 3.22.11-1
ii  libice62:1.0.9-2
ii  libpango-1.0-0 1.40.5-1
ii  libpangocairo-1.0-01.40.5-1
ii  libpcre2-8-0   10.22-3
ii  libsm6 2:1.2.2-1+b3
ii  libvte-2.91-0  0.46.1-1
ii  libx11-6   2:1.6.4-3+deb9u4
ii  mate-desktop-common1.16.2-2
ii  mate-terminal-common   1.16.3-1
ii  zlib1g 1:1.2.8.dfsg-5

mate-terminal recommends no packages.

mate-terminal suggests no packages.

-- no debconf information

Bug#989908: konsole: not working fine when gitfm is called

[vimuser]

Package: konsole
Version: 4:16.12.0-4
Severity: important

Dear Maintainer,

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

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

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

* What led up to the situation?
using konsole


-- System Information:
Debian Release: 9.13
  APT prefers oldstable
  APT policy: (500, 'oldstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.9.0-15-amd64 (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE= 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages konsole depends on:
ii  kio   5.28.0-2
ii  konsole-kpart 4:16.12.0-4
ii  libc6 2.24-11+deb9u4
ii  libkf5completion5 5.28.0-1
ii  libkf5configcore5 5.28.0-2+deb9u1
ii  libkf5configgui5  5.28.0-2+deb9u1
ii  libkf5configwidgets5  5.28.0-2
ii  libkf5coreaddons5 5.28.0-2
ii  libkf5crash5  5.28.0-1
ii  libkf5dbusaddons5 5.28.0-1
ii  libkf5i18n5   5.28.0-2
ii  libkf5iconthemes5 5.28.0-2
ii  libkf5kiowidgets5 5.28.0-2
ii  libkf5notifyconfig5   5.28.0-1
ii  libkf5widgetsaddons5  5.28.0-3
ii  libkf5windowsystem5   5.28.0-2
ii  libkf5xmlgui5 5.28.0-1
ii  libqt5core5a  5.7.1+dfsg-3+deb9u3
ii  libqt5gui55.7.1+dfsg-3+deb9u3
ii  libqt5widgets55.7.1+dfsg-3+deb9u3
ii  libstdc++66.3.0-18+deb9u1

konsole recommends no packages.

konsole suggests no packages.

-- no debconf information

Bug#989907: debspawn filesystems are non-minimal/fat by default

[Helmut Grohne]

Package: debspawn
Version: 0.5.0-1
Severity: wishlist

I looked into why the .tar.zst images for debspawn are so big. Indeed,
they contain a lot of stuff that does not belong there. Examples
include:

 * dmidecode
 * fdisk
 * ifupdown
 * init
 * isc-dhcp-client
 * kmod
 * nftables
 * rsyslog
 * systemd
 * tasksel
 * vim-tiny

When one passes --variant buildd to debspawn create, the size is much
smaller. When doing so, one has to pass --variant buildd to every
debspawn build and debspawn login invocation. That's quite annoying.
Given that debspawn's primary use is building, how about defaulting the
variant to buildd?

Helmut

Bug#989906: openssh-server: With GSSAPIKeyExchage "yes" openssh presents poor quality key exchange methods

[John Hughes]

Package: openssh-server
Version: 1:7.9p1-10+deb10u2
Severity: important

Dear Maintainer,


What did I do?

   * Configured GSSAPIKeyExchange "yes", because it's a good idea and
 the automatic updating of renewed credentials it allows is very,
 very useful.

What happened?

   * When connecting to the OpenSSH server I see some quite horrible key
 exchange methods proposed and accepted:

 debug1: Offering GSSAPI proposal: 
gss-gex-sha1-toWM5Slw5Ew8Mqkay+al2g==,gss-group1-sha1-toWM5Slw5Ew8Mqkay+al2g==,gss-group14-sha1-toWM5Slw5Ew8Mqkay+al2g==,gss-gex-sha1-eipGX3TCiQSrx573bT1o1Q==,gss-group1-sha1-eipGX3TCiQSrx573bT1o1Q==,gss-group14-sha1-eipGX3TCiQSrx573bT1o1Q==
 debug1: SSH2_MSG_KEXINIT sent
 debug1: SSH2_MSG_KEXINIT received
 debug1: kex: algorithm: gss-gex-sha1-toWM5Slw5Ew8Mqkay+al2g==

   * What outcome did you expect instead?

 Something more modern?

Some security scanners have started reporting at least
gss-gex-sha1-toWM5Slw5Ew8Mqkay+al2g== as a vulnerability, e.g. Qualys calls it
"QID 38739: Deprecated SSH Cryptographic Settings"

https://qualys-secure.force.com/customer/s/article/06407

As far as I can tell there is no way of configuring openssh to avoid using
gss-gex-sha1-toWM5Slw5Ew8Mqkay+al2g==.


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

Kernel: Linux 4.19.0-14-amd64 (SMP w/4 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages openssh-server depends on:
ii  adduser3.118
ii  debconf [debconf-2.0]  1.5.71
ii  dpkg   1.19.7
ii  libaudit1  1:2.8.4-3
ii  libc6  2.28-10
ii  libcom-err21.44.5-1+deb10u3
ii  libgssapi-krb5-2   1.17-3+deb10u1
ii  libkrb5-3  1.17-3+deb10u1
ii  libpam-modules 1.3.1-5
ii  libpam-runtime 1.3.1-5
ii  libpam0g   1.3.1-5
ii  libselinux12.8-1+b1
ii  libssl1.1  1.1.1d-0+deb10u6
ii  libsystemd0241-7~deb10u7
ii  libwrap0   7.6.q-28
ii  lsb-base   10.2019051400
ii  openssh-client 1:7.9p1-10+deb10u2
ii  openssh-sftp-server1:7.9p1-10+deb10u2
ii  procps 2:3.3.15-2
ii  ucf3.0038+nmu1
ii  zlib1g 1:1.2.11.dfsg-1

Versions of packages openssh-server recommends:
ii  libpam-systemd [logind]  241-7~deb10u7
ii  ncurses-term 6.1+20181013-2+deb10u2
ii  xauth1:1.0.10-1

Versions of packages openssh-server suggests:
pn  molly-guard   
pn  monkeysphere  
pn  rssh  
pn  ssh-askpass   
pn  ufw   

-- debconf information excluded

Bug#989350: Processed: your mail

[Francisco M Neto]

control: reassign 989350 wnpp
thanks

Hello!

On 2021-06-15 07:40, Andrei POPESCU wrote:
> On Lu, 14 iun 21, 21:51:03, Debian Bug Tracking System wrote:
> > Processing commands for cont...@bugs.debian.org:
> >
> > > reassign 989350 elementary-theme
> > Bug #989350 [wnpp] ITP: elementary-theme -- GTK stylesheet from elementary 
> > OS
>
> Any particular reason to do this?
>
> ITPs should always be assigned to 'wnpp' and closed on first upload with
> a 'Closes:' entry in the changelog.

After opening the ITP I realized it would be more appropriate to
change the package's name to "elementary-theme". When I uploaded it to
mentors.d.o, it complained about "closing bugs in a wrong way". I
assumed I'd have to reassign it to 'elementary-theme' (which causes no
errors in mentors.d.o) but I may have misinterpreted the requirements of
ITPs.

I'm reassigning it to wnpp now.

Thanks for noticing that :)

Cheers,
Francisco

--
[]'s
|
Francisco M Neto|
 | 3E58 1655 9A3D 5D78 9F90
| CFF1 D30B 1694 D692 FBF0


signature.asc
Description: PGP signature

Bug#907541: [openjdk-8] Bind to a multicast address fails

[Thorsten Glaser]

Hi Andre,

> This was supposed to be fixed upstream in Java 12:
> https://bugs.openjdk.java.net/browse/JDK-8210493
> 
> However it was taken back again (see last comment in that issue) and is now
> supposedly fixed in java 13:
> https://bugs.openjdk.java.net/browse/JDK-8215294
> https://bugs.openjdk.java.net/browse/JDK-8216417

thanks for this information bundle, it helps tremendously.

> As far as I am aware, it works with current Java versions in Debian (>= 13).
> 
> I am not sure if Debian actually wants to carry this for the versions <13, as
> the patch somehow introduced other issues (see the upstream bug-reports).

As far as I understand, the original patch indeed introduced issues,
so it’s probably not something we want to have in 8 and 11. The fix
in 13+ is not backportable because they basically rewrote the entire
socket classes’ implementations.

I guess this won’t be fixed in 8 and, more importantly, 11 currently.

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

*

Mit dem tarent-Newsletter nichts mehr verpassen: www.tarent.de/newsletter

*

Bug#989373:

[Aron Xu]

Control: severity -1 important

I'm downgrading this bug to important temporarily to avoid this
package to be removed from bullseye.

Since we are late in the release freeze, we cannot guarantee the fix
to land in time for bullseye, but if that fails let's push a fix in
-updates as soon as the release comes out.

Regards,
Aron

Bug#989905: please provide /var/empty or /var/run/empty

[Nicholas D Steeves]

Package: base-files
Version: 10.1
Severity: normal

Dear base-files maintainer,

I you will agree that it would be useful to provide /var/empty or
/var/run/empty.

Recently I became aware of #985459, and thought to myself "why not
just use /var/empty?" as a way to defend against cases where root may
have user-specific Emacs libraries installed to $HOME?  Seconds of
investigation later I was surprised to learn that Debian doesn't have
one.  This directory is present on Fedora, RedHat, CentOS, SUSE, Arch,
FreeBSD, and possibly more.  The FHS is silent about /var/empty, but I
have been unable to discover why.

In addition to helping to solve bugs like the one noted above, it
seems like /var/empty could be useful in a CI or reprobuilds context.
In the BSD world it was/is used for chroots, but of course this is
becoming less relevant with their "jails" and this use will become
less relevant as Linux namespace isolation becomes stronger.

RPM-using distributions also use it for /var/empty/sshd where we use
/var/run/sshd, so I wonder if /var/run/empty would be more appropriate
in a Debian context?  In operating systems that create per-server
directories for use as chroots, /var/empty contains only directories.
If /var/empty is not an immutable truly empty directory, and/or
contains per-server subdirs, then a note in Policy to the effect of
"/var/empty may contain directory trees, consisting only of
directories, and must not contain any files anywhere".  Considering
this, an immutable and empty /var/run/empty seems like a cleaner
solution.

The regression potential appears to be negligible to nil.

/var/empty should probably be chmod 755.  I do not believe there are
any security risks introduced by this proposal, but I think it would
be neat if dpkg could tighten permissions to 555 or maybe even set the 
immutable bit after a package has been successfully installed.

Thank you for your consideration :-)
Nicholas

Bug#986031: ogmrip: diff for NMU version 1.0.1-3.1

[Adrian Bunk]

Control: tags 986031 + pending

Dear maintainer,

I've prepared an NMU for ogmrip (versioned as 1.0.1-3.1) and uploaded
it to DELAYED/2. Please feel free to tell me if I should cancel it.

cu
Adrian
diff -Nru ogmrip-1.0.1/debian/changelog ogmrip-1.0.1/debian/changelog
--- ogmrip-1.0.1/debian/changelog	2020-04-15 22:48:47.0 +0300
+++ ogmrip-1.0.1/debian/changelog	2021-06-15 18:53:43.0 +0300
@@ -1,3 +1,11 @@
+ogmrip (1.0.1-3.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add patches from Bernhard Übelacker to fix crashes with
+recent glib and libdvdread. (Closes: #986031)
+
+ -- Adrian Bunk   Tue, 15 Jun 2021 18:53:43 +0300
+
 ogmrip (1.0.1-3) unstable; urgency=medium
 
   * Team upload
diff -Nru ogmrip-1.0.1/debian/patches/iso-file-segfault.patch ogmrip-1.0.1/debian/patches/iso-file-segfault.patch
--- ogmrip-1.0.1/debian/patches/iso-file-segfault.patch	1970-01-01 02:00:00.0 +0200
+++ ogmrip-1.0.1/debian/patches/iso-file-segfault.patch	2021-06-15 18:52:48.0 +0300
@@ -0,0 +1,14 @@
+Bug-Debian: https://bugs.debian.org/986031
+Last-Update: 2021-04-11
+
+--- ogmrip-1.0.1.orig/libogmdvd/ogmdvd-disc.c
 ogmrip-1.0.1/libogmdvd/ogmdvd-disc.c
+@@ -222,7 +222,7 @@ dvd_reader_get_menu_size (dvd_reader_t *
+ 
+   file = DVDOpenFile (reader, vts, DVD_READ_MENU_VOBS);
+   size = DVDFileSize (file);
+-  DVDCloseFile (file);
++  if (file) DVDCloseFile (file);
+ 
+   size *= DVD_VIDEO_LB_LEN;
+ #else /* HAVE_DVD_FILE_SIZE */
diff -Nru ogmrip-1.0.1/debian/patches/series ogmrip-1.0.1/debian/patches/series
--- ogmrip-1.0.1/debian/patches/series	2020-04-15 22:46:52.0 +0300
+++ ogmrip-1.0.1/debian/patches/series	2021-06-15 18:53:43.0 +0300
@@ -1,3 +1,5 @@
 01_libdvdread4.diff
 02_configure.diff
 enchant2.patch
+slashes-to-dashes.patch
+iso-file-segfault.patch
diff -Nru ogmrip-1.0.1/debian/patches/slashes-to-dashes.patch ogmrip-1.0.1/debian/patches/slashes-to-dashes.patch
--- ogmrip-1.0.1/debian/patches/slashes-to-dashes.patch	1970-01-01 02:00:00.0 +0200
+++ ogmrip-1.0.1/debian/patches/slashes-to-dashes.patch	2021-06-15 18:52:42.0 +0300
@@ -0,0 +1,304 @@
+Bug-Debian: https://bugs.debian.org/986031
+Last-Update: 2021-04-11
+
+--- ogmrip-1.0.1.orig/libogmrip-gtk/ogmrip-gconf-settings.c
 ogmrip-1.0.1/libogmrip-gtk/ogmrip-gconf-settings.c
+@@ -63,10 +63,10 @@ my_gconf_concat_dir_and_key (const gchar
+ 
+   strcpy (retval, dir);
+ 
+-  if (dir[dirlen-1] == '/')
++  if (dir[dirlen-1] == '-')
+   {
+ /* dir ends in slash, strip key slash if needed */
+-if (*key == '/')
++if (*key == '-')
+   ++key;
+ 
+ strcpy (retval + dirlen, key);
+@@ -76,9 +76,9 @@ my_gconf_concat_dir_and_key (const gchar
+ /* Dir doesn't end in slash, add slash if key lacks one. */
+ gchar* dest = retval + dirlen;
+ 
+-if (*key != '/')
++if (*key != '-')
+ {
+-  *dest = '/';
++  *dest = '-';
+   ++dest;
+ }
+   
+--- ogmrip-1.0.1.orig/libogmrip-gtk/ogmrip-lavc-options.c
 ogmrip-1.0.1/libogmrip-gtk/ogmrip-lavc-options.c
+@@ -39,25 +39,25 @@
+ #define OGMRIP_IS_LAVC_DIALOG(obj)   (G_TYPE_CHECK_INSTANCE_TYPE ((obj), OGMRIP_TYPE_LAVC_DIALOG))
+ #define OGMRIP_IS_LAVC_DIALOG_CLASS(obj) (G_TYPE_CHECK_CLASS_TYPE ((klass), OGMRIP_TYPE_LAVC_DIALOG))
+ 
+-#define OGMRIP_LAVC_KEY_CMP OGMRIP_LAVC_SECTION "/" OGMRIP_LAVC_PROP_CMP
+-#define OGMRIP_LAVC_KEY_PRECMP  OGMRIP_LAVC_SECTION "/" OGMRIP_LAVC_PROP_PRECMP
+-#define OGMRIP_LAVC_KEY_SUBCMP  OGMRIP_LAVC_SECTION "/" OGMRIP_LAVC_PROP_SUBCMP
+-#define OGMRIP_LAVC_KEY_DIA OGMRIP_LAVC_SECTION "/" OGMRIP_LAVC_PROP_DIA
+-#define OGMRIP_LAVC_KEY_PREDIA  OGMRIP_LAVC_SECTION "/" OGMRIP_LAVC_PROP_PREDIA
+-#define OGMRIP_LAVC_KEY_KEYINT  OGMRIP_LAVC_SECTION "/" OGMRIP_LAVC_PROP_KEYINT
+-#define OGMRIP_LAVC_KEY_BUF_SIZEOGMRIP_LAVC_SECTION "/" OGMRIP_LAVC_PROP_BUF_SIZE
+-#define OGMRIP_LAVC_KEY_MIN_RATEOGMRIP_LAVC_SECTION "/" OGMRIP_LAVC_PROP_MIN_RATE
+-#define OGMRIP_LAVC_KEY_MAX_RATEOGMRIP_LAVC_SECTION "/" OGMRIP_LAVC_PROP_MAX_RATE
+-#define OGMRIP_LAVC_KEY_STRICT  OGMRIP_LAVC_SECTION "/" OGMRIP_LAVC_PROP_STRICT
+-#define OGMRIP_LAVC_KEY_DC  OGMRIP_LAVC_SECTION "/" OGMRIP_LAVC_PROP_DC
+-#define OGMRIP_LAVC_KEY_MBD OGMRIP_LAVC_SECTION "/" OGMRIP_LAVC_PROP_MBD
+-#define OGMRIP_LAVC_KEY_QNS OGMRIP_LAVC_SECTION "/" OGMRIP_LAVC_PROP_QNS
+-#define OGMRIP_LAVC_KEY_VB_STRATEGY OGMRIP_LAVC_SECTION "/" OGMRIP_LAVC_PROP_VB_STRATEGY
+-#define OGMRIP_LAVC_KEY_LAST_PRED   OGMRIP_LAVC_SECTION "/" OGMRIP_LAVC_PROP_LAST_PRED
+-#define OGMRIP_LAVC_KEY_PREME   OGMRIP_LAVC_SECTION "/" OGMRIP_LAVC_PROP_PREME
+-#define OGMRIP_LAVC_KEY_VQCOMP  OGMRIP_LAVC_SECTION "/" OGMRIP_LAVC_PROP_VQCOMP
+-#define OGMRIP_LAVC_KEY_MV0 OGMRIP_LAVC_SECTION "/" OGMRIP_LAVC_PROP_MV0
+-#define OGMRIP_LAVC_KEY_V4MVOGMRIP_LAVC_SECTION "/" OGMRIP_LAVC_PROP_V4MV
++#define OGMRIP_LAVC_KEY_CMP OGMRIP_LAVC_SECTION "-" OGMRIP_LAVC

Bug#989530: buster-pu: package mupdf/1.14.0+ds1-4+deb10u3

[Adam D. Barratt]

Control: reopen -1

On Tue, 2021-06-15 at 12:01 +0200, Bastian Germann wrote:
> The package was uploaded to buster-pu.

Whilst that's true, the bug should remain open until the package is
actually in stable, at which point we (SRM) will close it.

Regards,

Adam

Bug#989597: release.debian.org: upgrade issue: non-coinstallability of libgdal20 and libgdal28

[Sebastiaan Couwenberg]

On 6/15/21 3:55 PM, Sebastian Ramacher wrote:
> On 2021-06-15 13:18:23, Sebastiaan Couwenberg wrote:
>> On 6/15/21 1:00 PM, Sebastian Ramacher wrote:
>>> If neither you as maintainer nor upstream care about upgrade without
>>> data loss, I don't think postgis is suitable to be included in a stable
>>> release. Best option moving forward is to get postgis and its reverse
>>> dependencies removed from bullseye.
>>
>> Removing postgis during distribution upgrade does not cause data loss.
>> Don't try to make this issue bigger than it is.
> 
> Again: how are users supposed to upgrade their postgis installation
> while retaining their data? So far I only found upstream's instructions
> which you told me are "shit". There are also not instructions or hints
> included in the release notes for bullseye.

Upgrading postgis is not supported and has never been. Stop trying to
make that happen without upstream commitment. It may be news to you or
some users of postgis, but it's not a new thing. Don't expect me to be
willing to spend time on an ancient issue.

Options for a working postgis database after distribution upgrade
include recreating the databases by running your ETL process on the new
cluster after upgrade, or using symlink hacks to workaround the
version-in-extension-filename issue:

 http://blog.cleverelephant.ca/2016/08/postgis-upgrade.html

The hard upgrade procedure from the upstream docs may be an option too:

 http://postgis.net/docs/manual-3.1/postgis_administration.html#upgrading

In my experience, recreating the database is the simplest solution.

> If I am not mistaken, Andreas proposed in another thread to introduce a
> postgis-2.5-built-against-postgresql-13 package to help with the
> upgrades. Would this be a viable option?

No. I'm not going to maintain multiple versions of postgis.

> We're trying to find solutions here to help user's with their postgis
> upgrades. After all, this discussion started after a user experienced
> issues. If we cannot provide users of the postgis package with an
> upgrade path, then yes, this is a grave bug. It needs to be dealt with.
> "Don't bother" and "it's shit" is not good enough.

Stop bothering with postgis. It's not worth our time, not yours, and not
mine. We don't get paid enough for that.

> One of the judgment calls we as maintainers have to make is whether a
> piece of software is suitable for a Debian stable release and if we can
> support upgrades from one stable to the next one. The information that I
> got so far from you, is that postgis does not care about the second
> part. I'd love to be convinced otherwise.

Not having postgis in stable will hurt users more than the terrible
upgrade experience it has always had.

It will be one less package I have to maintain in Debian, I can just
chuck in my personal repo and not bother any further. Perhaps I should
do that with all the GIS packages, leave it to someone else to deal with
all the bullshit in Debian. With every interaction about this postgis
issue, I lose ever more motivation to work on any of the other issues as
well. In case you hadn't noticed, there is a distinct lack of other
people working on these packages. You are doing its users a disservice
on your path of alienating its only active contributor. With postgis you
may find Myon willing to work on it, but with the other packages like
gdal you don't have that luxury.

Stop hammering on this postgis issue, you won't get me to work on it.

Kind Regards,

Bas

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

Bug#989823: meson: autopkgtest crossbuild is always skipped

[Jussi Pakkanen]

On Mon, 14 Jun 2021 at 09:15, Helmut Grohne  wrote:

> The autopkgtest "crossbuild" is always skipped. It starts with checking
> whether a command g++-arm-linux-gnueabhihf exists and exits 0 when it
> doesn't. That command never exists as it is called
> arm-linux-gnueabhihf-g++. Also exit code 0 is wrong. A skip should use
> exit code 77. An easier solution anyhow is using the
> skip-not-installable restriction. Please consider applying the attached
> patch.

Thanks. I'll add this to the next release. It should be in a few
weeks, unless there is a need to get a fix for this out sooner.

Bug#989902: Xfce Terminal Emulator v0.8.7.4 -- Hidden options

[null data]

Package: xfce4-terminal
Version: 0.8.7.4-2
-
Distributor ID: Debian
Description: Debian GNU/Linux 10 (buster)
Release: 10
Codename: buster
Update: 10.9
Kernel: 4.19.0-5-amd64

Issue:
===
Xfce Terminal Emulator v0.8.7.4 -- Hidden options


Reference: https://docs.xfce.org/apps/terminal/4.14/advanced

MiscHighlightUrls
-- This setting controls whether URLs – both hyperlinks and email addresses – 
will be highlighted in the text displayed in a terminal window. If you change 
this option to FALSE, URLs won't be highlighted anymore and you will no longer 
be able to middle-click the URL to open it in the preferred application.
*

Applying the "Hidden option" MiscHighlightUrls=FALSE does NOT remove the 
underscoring of URLS appearing in the terminal window.

file edited : /home/$USER/.config/xfce4/terminal/terminalrc

-- Debian Bug report logs: Bugs in package Xfce Terminal Emulator in stable
-- No reports found!

Please advise. Thank you.

Bug#989900: ITP: dnf-plugins-core -- Core plugins for DNF, the Dandified Yum package manager

[Aron Xu]

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


* Package name: dnf-plugins-core
  Version : 4.0.21
  Upstream Author : DNF-PLUGINS-CORE authors and contributors
* URL : https://github.com/rpm-software-management
* License : GPL-2+
  Programming Lang: Python
  Description :
This package enhances DNF with builddep, config-manager, copr, debug,
debuginfo-install, download, needs-restarting, groups-manager, repoclosure,
repograph, repomanage, reposync, changelog and repodiff commands.
.
Additionally provides generate_completion_cache passive plugin.

Note, the initial purpose of packaging these dnf plugins are not meant
to make dnf more useful to install RPM packages on Debian, but rather
it enables the downloading and mirroring of Yum repositories on Debian
based systems.

Bug#989899: unblock: libpod/3.0.1+dfsg1-3

[Reinhard Tartler]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: debian...@lists.debian.org, siret...@debian.org

Please unblock package libpod/3.0.1+dfsg1-3

[ Reason ]

When using rootless podman, a major feature compared to docker.io,
non-trivial network configurations exhibit network connectivity
issues that manifest in 'Recv failure: Connection reset by peer' errors

This was reported and tracked in #989803, and upstream at
https://github.com/containers/podman/issues/9532

A minimal test-case for this issue is discussed at
https://stackoverflow.com/questions/67049585/how-to-publish-ports-in-user-defined-network-in-rootless-podman

I've identified the patch that was backported to podman 3.0 and 3.1, and
included it as a distribution patch.

[ Impact ]

Podman has two major modes of operation: running with root priviledges
(rootful, similar to docker), and rootless. This patch does not affect rootful
podman, but is limited to rootless podman where it has to setup appropriate
network namespaces and networking using slirp4netns.

[ Tests ]

Alexander Reichle-Schmehl was so good to manually build the package from source
and confirms that the issue is fixed,
cf. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989803#20

[ Risks ]

This is a leaf package, and therefore is very unlikely to affect other
packages. The patch is minimal, focus, and well-understood upstream.

For your reviewing convenience, you might find it easier to review the quilt
patch at 
https://salsa.debian.org/debian/libpod/-/blob/master/debian/patches/networking-lookup-child-IP-in-networks.patch

Thank you for considering


unblock libpod/3.0.1+dfsg1-3


Full debdiff below:

siretart@x1:/srv/scratch/packages/containers/libpod$ git diff 
debian/3.0.1+dfsg1-2
diff --git a/debian/changelog b/debian/changelog
index 7ec3e362d..88f7f1480 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+libpod (3.0.1+dfsg1-3) unstable; urgency=medium
+
+  * Add networking-lookup-child-IP-in-networks.patch, fixes rootless
+connection issue "Connection reset by peer", Closes: #989803
+
+ -- Reinhard Tartler   Sun, 13 Jun 2021 18:28:49 -0400
+
 libpod (3.0.1+dfsg1-2) unstable; urgency=medium

   * Prefer crun over runc, Closes: #985379
diff --git a/debian/patches/networking-lookup-child-IP-in-networks.patch 
b/debian/patches/networking-lookup-child-IP-in-networks.patch
new file mode 100644
index 0..d1444c0e6
--- /dev/null
+++ b/debian/patches/networking-lookup-child-IP-in-networks.patch
@@ -0,0 +1,83 @@
+commit 0ba1942f261158b9526310aac7ee5f183a109440
+Author: Giuseppe Scrivano 
+Date:   Fri Jan 22 13:54:24 2021 +0100
+
+networking: lookup child IP in networks
+
+if a CNI network is added to the container, use the IP address in that
+network instead of hard-coding the slirp4netns default.
+
+commit 5e65f0ba30f3fca73f8c207825632afef08378c1 introduced this
+regression.
+
+Closes: https://github.com/containers/podman/issues/9065
+
+Signed-off-by: Giuseppe Scrivano 
+
+--- a/libpod/networking_linux.go
 b/libpod/networking_linux.go
+@@ -559,13 +559,25 @@
+   }
+   }
+
++  childIP := slirp4netnsIP
++outer:
++  for _, r := range ctr.state.NetworkStatus {
++  for _, i := range r.IPs {
++  ipv4 := i.Address.IP.To4()
++  if ipv4 != nil {
++  childIP = ipv4.String()
++  break outer
++  }
++  }
++  }
++
+   cfg := rootlessport.Config{
+   Mappings:  ctr.config.PortMappings,
+   NetNSPath: netnsPath,
+   ExitFD:3,
+   ReadyFD:   4,
+   TmpDir:ctr.runtime.config.Engine.TmpDir,
+-  ChildIP:   slirp4netnsIP,
++  ChildIP:   childIP,
+   }
+   cfgJSON, err := json.Marshal(cfg)
+   if err != nil {
+--- a/test/system/500-networking.bats
 b/test/system/500-networking.bats
+@@ -98,6 +98,7 @@
+ # "network create" now works rootless, with the help of a special container
+ @test "podman network create" {
+ skip_if_remote "FIXME: pending #7808"
++myport=54322
+
+ local mynetname=testnet-$(random_string 10)
+ local mysubnet=$(random_rfc1918_subnet)
+@@ -115,6 +116,27 @@
+ is "$output" ".* inet ${mysubnet}\.2/24 brd ${mysubnet}\.255 " \
+"sdfsdf"
+
++run_podman run --rm -d --network $mynetname -p 127.0.0.1:$myport:$myport \
++   $IMAGE nc -l -n -v -p $myport
++cid="$output"
++
++# emit random string, and check it
++teststring=$(random_string 30)
++echo "$teststring" | nc 127.0.0.1 $myport
++
++run_podman logs $cid
++# Sigh. We can't check line-by-line, because 'nc' output order is
++# unreliable. We usually get the 'connect to' line before the random
++# string, but sometimes we get it after. So, just do substring check

Bug#989597: release.debian.org: upgrade issue: non-coinstallability of libgdal20 and libgdal28

[Sebastian Ramacher]

On 2021-06-15 13:18:23, Sebastiaan Couwenberg wrote:
> On 6/15/21 1:00 PM, Sebastian Ramacher wrote:
> > If neither you as maintainer nor upstream care about upgrade without
> > data loss, I don't think postgis is suitable to be included in a stable
> > release. Best option moving forward is to get postgis and its reverse
> > dependencies removed from bullseye.
> 
> Removing postgis during distribution upgrade does not cause data loss.
> Don't try to make this issue bigger than it is.

Again: how are users supposed to upgrade their postgis installation
while retaining their data? So far I only found upstream's instructions
which you told me are "shit". There are also not instructions or hints
included in the release notes for bullseye.

If I am not mistaken, Andreas proposed in another thread to introduce a
postgis-2.5-built-against-postgresql-13 package to help with the
upgrades. Would this be a viable option?

We're trying to find solutions here to help user's with their postgis
upgrades. After all, this discussion started after a user experienced
issues. If we cannot provide users of the postgis package with an
upgrade path, then yes, this is a grave bug. It needs to be dealt with.
"Don't bother" and "it's shit" is not good enough.

One of the judgment calls we as maintainers have to make is whether a
piece of software is suitable for a Debian stable release and if we can
support upgrades from one stable to the next one. The information that I
got so far from you, is that postgis does not care about the second
part. I'd love to be convinced otherwise.

Cheers
-- 
Sebastian Ramacher

Bug#989107: 989107 is forwarded

[Andrius Merkys]

Control: forwarded -1 
https://salsa.debian.org/go-team/packages/golang-github-jmoiron-sqlx/-/merge_requests/2

Hello,

I have uploaded my packaging attempts for v1.3.4 to experimental.
Packaging is on Salsa, branch 'experimental'.

Andrius

Bug#989839: gmail problem

[Frank McCormick]

This will fix the problem tgemporarily. Discovered by some folks over at 
the Mozilla-Thunderbird forum.


Type into the search bar: network.http.spdy.enabled.http2 Double-click 
the entry to toggle from true to false


I have no idea whether this has any side effects, but it will
allow a connection to gmail.

Bug#989898: MariaDB crashes with "Crash: WSREP: invalid state ROLLED_BACK (FATAL)"

[Galatoulas Emmanuel]

Package: mariadb-server-10.3
Version: 1:10.3.29-0+deb10u1

Upgrading MariaDB to version 10.3.29 (from version 10.3.27)  via the 
buster-proposed-updates repository we encounter repeatedly the following error, 
affecting our Galera Clusters (one with 3 nodes and one with 5 nodes, plus the 
corresponding Maxscale proxy for each) (a more extended log is attached).

--
2021-06-13  9:10:54 0 [Note] WSREP: Member 1.0 (mydb8) synced with group.
2021-06-13 14:16:41 0 [ERROR] WSREP: invalid state ROLLED_BACK (FATAL)
 at galera/src/replicator_smm.cpp:abort_trx():727
2021-06-13 14:16:41 0 [ERROR] WSREP: cancel commit bad exit: 7 578781947
210613 14:16:41 [ERROR] mysqld got signal 6 ;


This seems to be the bug reported here: 
https://jira.mariadb.org/browse/MDEV-25114 affecting Galera for version 10.3.28 
but not yet reported for version 10.3.29. 

The installed MariaDB related packages:
libmariadb3 :  1:10.3.29-0+deb10u1
mariadb-backup:1:10.3.29-0+deb10u1
mariadb-client-10.3:   1:10.3.29-0+deb10u1
mariadb-client-core-10.3:  1:10.3.29-0+deb10u1
mariadb-common:1:10.3.29-0+deb10u1
mariadb-server-10.3:  1:10.3.29-0+deb10u1
mariadb-server-core-10.3:  1:10.3.29-0+deb10u1
maxscale:  2.5.13~buster-1

Kernel running:
Linux  4.19.0-14-amd64 #1 SMP Debian 4.19.171-2 (2021-01-30) x86_64 GNU/Linux

Debian version running:
 cat /etc/os-release
PRETTY_NAME="Debian GNU/Linux 10 (buster)"
NAME="Debian GNU/Linux"
VERSION_ID="10"
VERSION="10 (buster)"

cat /etc/debian_version
Point Release: 10.9

libc6 version:
libc6:  2.28-10

With kind regards

Emmanuel Galatoulas
CTI-Diophantus, Greece2021-06-13  9:10:52 0 [Note] WSREP: Member 1.0 (mydb8) requested state transfer 
from 'XXX.XXX.XXX.XXX,'. Selected 3.0 (mydb9)(SYNCED) as donor.
2021-06-13  9:10:52 0 [Note] WSREP: 3.0 (mydb9): State transfer to 1.0 (mydb8) 
complete.
2021-06-13  9:10:52 0 [Note] WSREP: Member 3.0 (mydb9) synced with group.
2021-06-13  9:10:54 0 [Note] WSREP: (bc6b5ce8, 'tcp://0.0.0.0:4567') turning 
message relay requesting off
2021-06-13  9:10:54 0 [Note] WSREP: 1.0 (mydb8): State transfer from 3.0 
(mydb9) complete.
2021-06-13  9:10:54 0 [Note] WSREP: Member 1.0 (mydb8) synced with group.
2021-06-13 14:16:41 0 [ERROR] WSREP: invalid state ROLLED_BACK (FATAL)
 at galera/src/replicator_smm.cpp:abort_trx():727
2021-06-13 14:16:41 0 [ERROR] WSREP: cancel commit bad exit: 7 578781947
210613 14:16:41 [ERROR] mysqld got signal 6 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.

Bug#989833: thunar: Thunar does not auto-refresh when directory contents are changed

[Yves-Alexis Perez]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Mon, 2021-06-14 at 08:13 -0500, sudoer wrote:
> Seeing as there are no other bug reports for an issue this big, it makes
> me think that only my system is affected. I can record my screen to show
> the behavior of this bug, if needed.

Hi,

indeed, it looks that something is odd on your system. I assume you're testing
on a regular, local filesystem and not on a remote filesystem?

Thunar relies on gio/gvfs for all filesystems operations, so maybe there's
something fishy here.

You can try to quit all thunar instances (run thunar -q) then run Thunar from
a terminal in case something is shown on the output.

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

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmDIqncACgkQ3rYcyPpX
RFveYAgAp1s++rl82LTUGnPP+3xFnlNAB0RbvOOG1aPbCNWLwLm9m8UcF4p8kKnz
sAdFTWbdm9S6KdipQKuY0QqV7upp4y6izSv717m/+ZPE6XqeGttSl/LZ57yiObM8
jRzg2+DVoVWngOS+RH+HSzI6W4GiJ35ZzlH6toyVW4dDcBDqV2c73pJIUMbzRgCV
Xbxc3P9/8rzUEh7vO5FPrEnlK8GTS2v749bRWLCIsxfLuPcKUeTV8XW1alXCRRq8
B/qDxmKnpKlfGs0Nf1HGDBlv/CIHlbeWncOjWhDFUUNiQu69KdeymF5tIEO2tehw
Y7PGWteBVqwyop8SLzEq3UhMdcYddQ==
=g73v
-END PGP SIGNATURE-

Bug#989885: nvidia-driver: package should recommend libnvidia-encode1

[Andrea Pappacoda]

Package: nvidia-driver
Version: 460.73.01-1
Severity: wishlist

libnvidia-encode1 contains the library needed to use NVENC, used to encode
videos on the GPU, and depends on libnvcuvid1, needed for NVDEC, the video
decoder.
They are part of the Nvidia driver, and some users, especially inexperienced
ones, would expect to have support for them after installing the nvidia-driver
package.
Another solution would be to just mark it as suggested by nvidia-driver, so
that it is easier to find.

-- Package-specific info:
uname -a:
Linux tachi-debian-1070 5.10.31 #1 SMP PREEMPT Thu Apr 22 19:21:16 CEST 2021 
x86_64 GNU/Linux

/proc/version:
Linux version 5.10.31 (tachi@tachi-debian-1070) (gcc (Debian 10.2.1-6) 10.2.1 
20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 SMP PREEMPT Thu Apr 22 
19:21:16 CEST 2021

/proc/driver/nvidia/version:
NVRM version: NVIDIA UNIX x86_64 Kernel Module 460.73.01 Thu Apr 1 21:40:36 UTC 
2021
GCC version: gcc version 10.2.1 20210110 (Debian 10.2.1-6)

lspci 'display controller [030?]':
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GP104 [GeForce GTX 
1070] [10de:1b81] (rev a1) (prog-if 00 [VGA controller])
Subsystem: Gigabyte Technology Co., Ltd GP104 [GeForce GTX 1070] [1458:3701]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- 
SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: nvidia
Kernel modules: nvidia

dmesg:

Device node permissions:
crw-rw+ 1 root video 226, 0 Jun 15 09:05 /dev/dri/card0
crw-rw+ 1 root render 226, 128 Jun 15 09:05 /dev/dri/renderD128
crw-rw-rw- 1 root root 195, 254 Jun 15 09:05 /dev/nvidia-modeset
crw-rw-rw- 1 root root 195, 0 Jun 15 09:05 /dev/nvidia0
crw-rw-rw- 1 root root 195, 255 Jun 15 09:05 /dev/nvidiactl

/dev/dri/by-path:
total 0
lrwxrwxrwx 1 root root 8 Jun 15 09:05 pci-:01:00.0-card -> ../card0
lrwxrwxrwx 1 root root 13 Jun 15 09:05 pci-:01:00.0-render -> ../renderD128
video:x:44:tachi

OpenGL and NVIDIA library files installed:
-rw-r--r-- 1 root root 1188 Feb 15 2020 /etc/X11/xorg.conf
lrwxrwxrwx 1 root root 15 May 5 2020 /etc/alternatives/glx -> /usr/lib/nvidia
lrwxrwxrwx 1 root root 49 May 3 18:22 
/etc/alternatives/glx--libEGL.so-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libEGL.so
lrwxrwxrwx 1 root root 49 May 5 2020 
/etc/alternatives/glx--libEGL.so.1-i386-linux-gnu -> 
/usr/lib/mesa-diverted/i386-linux-gnu/libEGL.so.1
lrwxrwxrwx 1 root root 51 May 5 2020 
/etc/alternatives/glx--libEGL.so.1-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libEGL.so.1
lrwxrwxrwx 1 root root 48 May 3 18:22 
/etc/alternatives/glx--libGL.so-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so
lrwxrwxrwx 1 root root 48 May 3 18:22 
/etc/alternatives/glx--libGL.so-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so
lrwxrwxrwx 1 root root 48 May 5 2020 
/etc/alternatives/glx--libGL.so.1-i386-linux-gnu -> 
/usr/lib/mesa-diverted/i386-linux-gnu/libGL.so.1
lrwxrwxrwx 1 root root 48 May 5 2020 
/etc/alternatives/glx--libGL.so.1-i386-linux-gnu -> 
/usr/lib/mesa-diverted/i386-linux-gnu/libGL.so.1
lrwxrwxrwx 1 root root 50 May 5 2020 
/etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1
lrwxrwxrwx 1 root root 50 May 5 2020 
/etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1
lrwxrwxrwx 1 root root 55 May 5 2020 
/etc/alternatives/glx--libGLESv1_CM.so.1-i386-linux-gnu -> 
/usr/lib/mesa-diverted/i386-linux-gnu/libGLESv1_CM.so.1
lrwxrwxrwx 1 root root 55 May 5 2020 
/etc/alternatives/glx--libGLESv1_CM.so.1-i386-linux-gnu -> 
/usr/lib/mesa-diverted/i386-linux-gnu/libGLESv1_CM.so.1
lrwxrwxrwx 1 root root 57 May 5 2020 
/etc/alternatives/glx--libGLESv1_CM.so.1-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv1_CM.so.1
lrwxrwxrwx 1 root root 57 May 5 2020 
/etc/alternatives/glx--libGLESv1_CM.so.1-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv1_CM.so.1
lrwxrwxrwx 1 root root 52 May 5 2020 
/etc/alternatives/glx--libGLESv2.so.2-i386-linux-gnu -> 
/usr/lib/mesa-diverted/i386-linux-gnu/libGLESv2.so.2
lrwxrwxrwx 1 root root 52 May 5 2020 
/etc/alternatives/glx--libGLESv2.so.2-i386-linux-gnu -> 
/usr/lib/mesa-diverted/i386-linux-gnu/libGLESv2.so.2
lrwxrwxrwx 1 root root 54 May 5 2020 
/etc/alternatives/glx--libGLESv2.so.2-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv2.so.2
lrwxrwxrwx 1 root root 54 May 5 2020 
/etc/alternatives/glx--libGLESv2.so.2-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv2.so.2
lrwxrwxrwx 1 root root 42 May 5 2020 
/etc/alternatives/glx--libGLX_indirect.so.0-i386-linux-gnu -> 
/usr/lib/i386-linux-gnu/libGLX_nvidia.so.0
lrwxrwxrwx 1 root root 42 May 5 2020 
/etc/alternatives/glx--libGLX_indirect.so.0-i386-linux-gnu -> 
/usr/lib/i386-linux-gnu/libGLX_nvidia.so.0
lrwxrwxrwx 1 root ro

Bug#960676: autofs: update service file

[Mike Gabriel]

Hi Jörg,

On  Di 15 Jun 2021 10:47:53 CEST, Jörg Behrmann wrote:


Package: autofs
Version: 5.1.7-1
Followup-For: Bug #960676

The current upstream version of autofs provides a sample service  
file that for

Debian would look like this


[Unit]
Description=Automounts filesystems on demand
After=network.target ypbind.service sssd.service  
network-online.target remote-fs.target rpc-statd.service  
rpcbind.service

Wants=network-online.target rpc-statd.service rpcbind.service

[Service]
Type=notify
EnvironmentFile=-/etc/default/autofs
ExecStart=/usr/sbin/automount $OPTIONS --systemd-service --dont-check-daemon
ExecReload=/usr/bin/kill -HUP $MAINPID
KillMode=process
TimeoutSec=180

[Install]
WantedBy=multi-user.targe


It would be great if you could change the service file to this. While those
options are not documented in the man page, they are visible in the  
help output

of the automount command.

Changing the service file would make the service more robust.


thanks for your contribution. To make an update possible for Debian  
bullseye (we are in deep freeze), I need a more dramatic description  
of things that might go wrong with the current .service file.


Please explain the opposite of "robust" with concrete observations  
(i.e. bugs).


Furthermore, have you tested the proposed service file with  
autofs-ldap??? With autofs-ldap we still have a nasty race condition  
that leaves autofs non-function if it starts before nslcd (libnss LDAP  
caching daemon).


Thanks+Greets,
Mike
--

DAS-NETZWERKTEAM
c\o Technik- und Ökologiezentrum Eckernförde
Mike Gabriel, Marienthaler Str. 17, 24340 Eckernförde
mobile: +49 (1520) 1976 148
landline: +49 (4351) 850 8940

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de



pgpK795q3XBk2.pgp
Description: Digitale PGP-Signatur

Bug#989897: allow creating named containers

[Pirate Praveen]

Package: debspawn
Version: 0.5.0-1
Severity: wishlist

I'd like to use debspawn similar to schroot, ie, create a sid 
environment in stable for local experiments (debspawn login 
--persistent) in parallel to the clean build. So I want to create 
debian-sid for local container and sid just for clean builds.


schroot often has problems when using sid from ubuntu host so I'd like 
to use debspawn instead.

Bug#989599: upgrade issue: apt: fails to upgrade guile-2.2-libs from buster to bullseye

[Andreas Beckmann]

Followup-For: Bug #989599

Hi,

a possible solution would be to rename libgc1 to libgc1a (or similar).
To avoid needing a full transition, I've added a transitional package
libgc1. After rebuilding guile-2.2 and guile-3.0 against libgc1a
upgrades start to go smooth - libgc1c2 from buster gets removed, the
transitional libgc1 is not needed and libgc1a gets installed along with
guile-2.2-libs being upgraded.

This has not been discussed with the libgc maintainers (nor does there
exist a bug, yet).

I still think reusing 'libgc1' was a very bad decision (maybe the soname
should have been bumped if there were symbols gone?), and it has
uncovered a problem in apt handling swapping real/virtual
Package/Conflicts on the same name pair.

(the diff still needs the transitional package description and the
changelog entry to be adjusted)

Andreas
diff -Nru libgc-8.0.4/debian/changelog libgc-8.0.4/debian/changelog
--- libgc-8.0.4/debian/changelog2020-12-06 12:44:00.0 +0100
+++ libgc-8.0.4/debian/changelog2021-04-13 15:46:44.0 +0200
@@ -1,3 +1,11 @@
+libgc (1:8.0.4-3.1) UNRELEASED; urgency=medium
+
+  * Rename libgc1 to libgc1a.
+Downgrade the Conflicts: libgc1c2 to Breaks for smoother upgrades from
+buster.  (Closes: #-1)
+
+ -- Andreas Beckmann   Tue, 13 Apr 2021 15:46:44 +0200
+
 libgc (1:8.0.4-3) unstable; urgency=medium
 
   * Fix cross/native difference: explicitly disable usage of
diff -Nru libgc-8.0.4/debian/control libgc-8.0.4/debian/control
--- libgc-8.0.4/debian/control  2020-12-06 12:44:00.0 +0100
+++ libgc-8.0.4/debian/control  2021-04-13 15:46:44.0 +0200
@@ -12,12 +12,31 @@
 #Vcs-Git: git://anonscm.debian.org/collab-maint/libgc.git
 #Vcs-Browser: https://anonscm.debian.org/cgit/collab-maint/libgc.git
 
-Package: libgc1
+Package: libgc1a
 Architecture: any
 Pre-Depends: ${misc:Pre-Depends}
 Depends: ${misc:Depends}, ${shlibs:Depends}
-Conflicts: libgc1c2
-Replaces: libgc1c2
+Breaks: libgc1c2 (<< 1:8.0.4-1), libgc1 (<< 1:8.0.4-3.1~)
+Replaces: libgc1c2 (<< 1:8.0.4-1), libgc1 (<< 1:8.0.4-3.1~)
+#Provides: libgc1 (= ${binary:Version})
+Multi-Arch: same
+Description: conservative garbage collector for C and C++
+ Boehm-Demers-Weiser's GC is a garbage collecting storage allocator that is
+ intended to be used as a plug-in replacement for C's malloc or C++'s new().
+ .
+ It allows you to allocate memory basically as you normally would without
+ explicitly deallocating memory that is no longer useful. The collector
+ automatically recycles memory when it determines that it can no longer be
+ used.
+ .
+ This version of the collector is thread safe, has C++ support and uses the
+ defaults for everything else. However, it does not work as a drop-in malloc(3)
+ replacement.
+
+Package: libgc1
+Architecture: any
+Pre-Depends: ${misc:Pre-Depends}
+Depends: ${misc:Depends}, libgc1a (= ${binary:Version})
 Multi-Arch: same
 Description: conservative garbage collector for C and C++
  Boehm-Demers-Weiser's GC is a garbage collecting storage allocator that is
@@ -35,7 +54,8 @@
 Package: libgc-dev
 Architecture: any
 Section: libdevel
-Depends: ${misc:Depends}, libgc1 (= ${binary:Version}), libc-dev, 
${atomic:Depends}
+Depends: ${misc:Depends}, libgc1a (= ${binary:Version}), libc-dev, 
${atomic:Depends}
+Breaks: libgc1c2 (<< 1:8.0.4-1)
 Multi-Arch: same
 Description: conservative garbage collector for C (development)
  Boehm-Demers-Weiser's GC is a garbage collecting storage allocator that is
@@ -50,4 +70,4 @@
  defaults for everything else. However, it does not work as a drop-in malloc(3)
  replacement.
  .
- This package is required to compile and link programs that use libgc1c2.
+ This package is required to compile and link programs that use libgc1a.
diff -Nru libgc-8.0.4/debian/libgc1.docs libgc-8.0.4/debian/libgc1.docs
--- libgc-8.0.4/debian/libgc1.docs  2013-12-23 13:29:50.0 +0100
+++ libgc-8.0.4/debian/libgc1.docs  1970-01-01 01:00:00.0 +0100
@@ -1 +0,0 @@
-doc/README.environment
diff -Nru libgc-8.0.4/debian/libgc1.install libgc-8.0.4/debian/libgc1.install
--- libgc-8.0.4/debian/libgc1.install   2013-12-23 13:29:50.0 +0100
+++ libgc-8.0.4/debian/libgc1.install   1970-01-01 01:00:00.0 +0100
@@ -1 +0,0 @@
-usr/lib/*/libgc*.so.*
diff -Nru libgc-8.0.4/debian/libgc1.symbols libgc-8.0.4/debian/libgc1.symbols
--- libgc-8.0.4/debian/libgc1.symbols   2020-10-27 14:07:51.0 +0100
+++ libgc-8.0.4/debian/libgc1.symbols   1970-01-01 01:00:00.0 +0100
@@ -1,720 +0,0 @@
-# SymbolsHelper-Confirmed: 1:8.0 arm64 armel armhf hppa hurd-i386 mips64el 
mipsel powerpc ppc64 ppc64el s390x sh4 sparc64
-libgc.so.1 libgc1 #MINVER#
- GC_FirstDLOpenedLinkMap@Base 1:7.2d
- (arch=kfreebsd-amd64 kfreebsd-i386)GC_FreeBSDGetDataStart@Base 1:7.2d
- (arch=sparc sparc64)GC_SysVGetDataStart@Base 1:7.2d
- GC_abort_on_oom@Base 1:8.0
- (arch=!nios2 !sh4)GC_acquire_mark_lock@Base 1:8.0
- (arch=!nios2 !sh4)GC_active_count@Base 1:8.0
- GC_add_ext_desc

Bug#989890: debspawn: make caching of downloaded .debs optional

[Pirate Praveen]

On Tue, 15 Jun 2021 13:28:21 +0200 Helmut Grohne  
wrote:

> Package: debspawn
> Version: 0.5.0-1
> Severity: wishlist
>
> Hi,
>
> thanks for fixing all of the bugs I reported. I was looking into
> debspawn again and noticed that there is no way to opt out of caching
> downloaded .debs locally. One can cache the directory for caching 
them,

> but not disable it.
>
> Why would one want to do that? If your system resides on a SSD, 
writes

> reduce the lifetime of your disk. Partially, one can avoid writes
> incurred by debspawn by mounting a tmpfs on /var/tmp/debspawn (or 
moving
> it to a tmpfs-based /tmp). The writes to the aptcache cannot be 
avoided
> that way. My local network has a fast mirror, so downloading them 
over
> and over again is not too bad. Quite to the contrary, the cache can 
be

> shared by multiple hosts.

Also if I already have apt-cacher-ng setup, I don't want debspawn also 
to duplicate a cache. May be it should use auto-apt-proxy to check if 
there is an apt-cacher-ng setup and disable it automatically if it 
detects one.

Bug#989896: clipman doesn't show the most recent entries

[Michael Deegan]

Package: xfce4-clipman-plugin
Version: 2:1.6.1-1
Severity: normal

Now running a mostly-bullseye system, I noticed to my dismay that
xfce4-clipman-plugin (and xfce4-clipman itself) no longer show the most
recent clipboard entries.

Hopefully the attached screenshot demonstrates the issue, the result of
selecting 1 through 20 in a terminal, and taking screenshots (not attached)
after 10 and 15. Maximum items is set to 10 here. Selection sync and history
order reversal are both enabled.

Oh, I was about to hit Send on this report when I found 
https://gitlab.xfce.org/panel-plugins/xfce4-clipman-plugin/-/issues/33
which is likely the same bug.

-- System Information:
Debian Release: 10.9
  APT prefers testing-debug
  APT policy: (500, 'testing-debug'), (500, 'stable-updates'), (500, 
'stable-debug'), (500, 'proposed-updates-debug'), (500, 'stable'), (500, 
'oldstable'), (480, 'testing'), (470, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages xfce4-clipman-plugin depends on:
ii  libc62.31-12
ii  libgdk-pixbuf2.0-0   2.40.2-2
ii  libglib2.0-0 2.66.8-1
ii  libgtk-3-0   3.24.24-4
ii  libqrencode4 4.0.2-1
ii  libx11-6 2:1.7.1-1
ii  libxfce4panel-2.0-4  4.16.2-1
ii  libxfce4ui-2-0   4.16.0-1
ii  libxfce4util74.16.0-1
ii  libxfconf-0-34.16.0-2
ii  libxtst6 2:1.2.3-1
ii  xfce4-clipman2:1.6.1-1

xfce4-clipman-plugin recommends no packages.

xfce4-clipman-plugin suggests no packages.

-- debconf-show failed

Bug#987181: RFS: cpufetch/0.97-1 -- Simple yet fancy CPU architecture fetching tool

[Tobias Frost]

On Tue, Jun 15, 2021 at 02:12:20PM +0800, clay stan wrote:
> Tobias Frost  于2021年6月9日周三 上午2:03写道：
> >
> Add arm64 now.

(Well, arm64 is clearly wrong…)

I'd suggest just to (try) build for  "any" architecture. Even if the arch is not
supported, worst case that build fails. (Which is not a problem at all, 
especially
as this package is tiny and almost builds instantly.)

With your hardcoded list you very likely miss some archs where cpufetch might 
work too.
The kfreebsd ports as an example.

Just don't have artifical limits, please.

-- 
tobi

Bug#962480: libnghttp2-dev: please include libnghttp2_asio

[Alexander GQ Gerasiov]

Package: nghttp2
Followup-For: Bug #962480

Dear Maintainer,

https://salsa.debian.org/debian/nghttp2/-/merge_requests/3

Bug#989895: installation-reports

[Peter Ehlert]

Package: installation-reports

Boot method: USB stick
Image version: 
https://cdimage.debian.org/cdimage/bullseye_di_rc2/amd64/iso-cd/debian-bullseye-DI-rc2-amd64-netinst.iso

Date: 2021-06-15 04-39-41 Pacific

Machine: HP Z620 Workstation
Processor: 2x 8-Core model: Intel Xeon E5-2660
Memory: 62.83 GiB
Partitions:
df: /run/user/1000/doc: Operation not permitted
Filesystem Type 1K-blocks    Used Available Use% Mounted on
udev   devtmpfs  32916004   0  32916004   0% /dev
tmpfs  tmpfs  6587784    1852   6585932   1% /run
/dev/sdc11 ext4  19046484 3832116  14221500  22% /
tmpfs  tmpfs 32938908   51320  32887588   1% /dev/shm
tmpfs  tmpfs 5120   4  5116   1% /run/lock
/dev/sdc13 ext4  14102852   56084  13308568   1% /home
tmpfs  tmpfs  6587780  88   6587692   1% /run/user/1000

Output of lspci -knn:
    00:00.0 Host bridge [0600]: Intel Corporation Xeon E5/Core i7 DMI2 
[8086:3c00] (rev 07)

    Subsystem: Hewlett-Packard Company Xeon E5/Core i7 DMI2 [103c:158a]
00:01.0 PCI bridge [0604]: Intel Corporation Xeon E5/Core i7 IIO PCI 
Express Root Port 1a [8086:3c02] (rev 07)

    Kernel driver in use: pcieport
00:02.0 PCI bridge [0604]: Intel Corporation Xeon E5/Core i7 IIO PCI 
Express Root Port 2a [8086:3c04] (rev 07)

    Kernel driver in use: pcieport
00:03.0 PCI bridge [0604]: Intel Corporation Xeon E5/Core i7 IIO PCI 
Express Root Port 3a in PCI Express Mode [8086:3c08] (rev 07)

    Kernel driver in use: pcieport
00:05.0 System peripheral [0880]: Intel Corporation Xeon E5/Core i7 
Address Map, VTd_Misc, System Management [8086:3c28] (rev 07)
    Subsystem: Hewlett-Packard Company Xeon E5/Core i7 Address Map, 
VTd_Misc, System Management [103c:158a]
00:05.2 System peripheral [0880]: Intel Corporation Xeon E5/Core i7 
Control Status and Global Errors [8086:3c2a] (rev 07)
    Subsystem: Hewlett-Packard Company Xeon E5/Core i7 Control Status 
and Global Errors [103c:158a]
00:05.4 PIC [0800]: Intel Corporation Xeon E5/Core i7 I/O APIC 
[8086:3c2c] (rev 07)

    Subsystem: Intel Corporation Xeon E5/Core i7 I/O APIC [8086:3c2c]
00:11.0 PCI bridge [0604]: Intel Corporation C600/X79 series chipset PCI 
Express Virtual Root Port [8086:1d3e] (rev 05)

    Kernel driver in use: pcieport
00:16.0 Communication controller [0780]: Intel Corporation C600/X79 
series chipset MEI Controller #1 [8086:1d3a] (rev 05)
    Subsystem: Hewlett-Packard Company C600/X79 series chipset MEI 
Controller [103c:158a]

    Kernel driver in use: mei_me
    Kernel modules: mei_me
00:16.2 IDE interface [0101]: Intel Corporation C600/X79 series chipset 
IDE-r Controller [8086:1d3c] (rev 05)
    Subsystem: Hewlett-Packard Company C600/X79 series chipset IDE-r 
Controller [103c:158a]

    Kernel driver in use: ata_generic
    Kernel modules: ata_generic
00:16.3 Serial controller [0700]: Intel Corporation C600/X79 series 
chipset KT Controller [8086:1d3d] (rev 05)
    Subsystem: Hewlett-Packard Company C600/X79 series chipset KT 
Controller [103c:158a]

    Kernel driver in use: serial
00:19.0 Ethernet controller [0200]: Intel Corporation 82579LM Gigabit 
Network Connection (Lewisville) [8086:1502] (rev 05)

    DeviceName: Onboard LAN
    Subsystem: Hewlett-Packard Company 82579LM Gigabit Network 
Connection (Lewisville) [103c:158a]

    Kernel driver in use: e1000e
    Kernel modules: e1000e
00:1a.0 USB controller [0c03]: Intel Corporation C600/X79 series chipset 
USB2 Enhanced Host Controller #2 [8086:1d2d] (rev 05)
    Subsystem: Hewlett-Packard Company C600/X79 series chipset USB2 
Enhanced Host Controller [103c:158a]

    Kernel driver in use: ehci-pci
    Kernel modules: ehci_pci
00:1b.0 Audio device [0403]: Intel Corporation C600/X79 series chipset 
High Definition Audio Controller [8086:1d20] (rev 05)
    Subsystem: Hewlett-Packard Company C600/X79 series chipset High 
Definition Audio Controller [103c:158a]

    Kernel driver in use: snd_hda_intel
    Kernel modules: snd_hda_intel
00:1c.0 PCI bridge [0604]: Intel Corporation C600/X79 series chipset PCI 
Express Root Port 2 [8086:1d12] (rev b5)

    Kernel driver in use: pcieport
00:1c.5 PCI bridge [0604]: Intel Corporation C600/X79 series chipset PCI 
Express Root Port 5 [8086:1d18] (rev b5)

    Kernel driver in use: pcieport
00:1c.6 PCI bridge [0604]: Intel Corporation C600/X79 series chipset PCI 
Express Root Port 3 [8086:1d14] (rev b5)

    Kernel driver in use: pcieport
00:1c.7 PCI bridge [0604]: Intel Corporation C600/X79 series chipset PCI 
Express Root Port 4 [8086:1d16] (rev b5)

    Kernel driver in use: pcieport
00:1d.0 USB controller [0c03]: Intel Corporation C600/X79 series chipset 
USB2 Enhanced Host Controller #1 [8086:1d26] (rev 05)
    Subsystem: Hewlett-Packard Company C600/X79 series chipset USB2 
Enhanced Host Controller [103c:158a]

    Kernel driver in use: ehci-pci
    Kernel modules: ehci_pci
00:1e.0 PCI bridge [0604]: Intel Corporation 82801 PCI Bridge 
[8086:244

Bug#989894: ITP: (reintroduce) ghextris -- A Tetris-like game on a hexagonal grid

[plugwash]

Package: wnpp
Severity: wishlist
Owner: plugwash 

* Package name: ghextris
  Version : 0.9.0
  Upstream Author : Mikko Rauhala
* URL : http://mjr.iki.fi/software/ghextris
* License : GPLv2+
  Programming Lang: Python
  Description : A Tetris-like game on a hexagonal grid

The object of the game is basically the same as in Tetris; use the pieces 
that fall down from the top of the game area to construct fully filled lines, 
which will then disappear to make room for more pieces. The twist is that the 
pieces are composed of hexagonal blocks, so your visualization skills will get
an extra workout. 

ghextris was in Debian from Sarge through to Stretch, but was removed due
to dependencies on obsolete gnome2 related libraries. I have ported it to a
more modern python3/python3-gi/gtk3/glade technology stack and intend to
reintrouce it.

I intend to keep the package within the games team,

Bug#989893: unblock: joblib/0.17.0-4

[Graham Inggs]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package joblib

[ Reason ]
joblib/0.17.0-3 fails its autopkgtests on s390x, a big-endian architecture

[ Impact ]
As per upstream issue #1123 [1], joblib.load() on a big-endian system
of a file written on a little-endian system will fail, and vice versa.

[ Tests ]
joblib/0.17.0-3 4's autopkgtests now pass on all architectures [1]

[ Risks ]
Low, the patch is a targeted fix merged upstream

[ 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 testing

[ Other info ]

[1] https://github.com/joblib/joblib/issues/1123
[2] https://ci.debian.net/packages/j/joblib/


joblib-0.17.0-3-vs-4.debdiff
Description: Binary data

Bug#989892: missing some tycho plugins

[Joseph Nahmias]

Package: libtycho-java
Version: 2.3.0-1
Severity: normal

Hello,

Thank you for maintaining tycho in Debian and packaging v2.3.0 in
experimental.  I am trying to package DBeaver for Debian, which uses
tycho. However, it seems that the tycho package is missing some of the
plugins; specifically: tycho-p2-director-plugin and tycho-surefire-plugin.
It would be great if you could include them in the next version of the
package.

Much appreciated,
--Joe

Bug#986822: BUG#986822 Broadwell SST CATPT Sound module

[Dekks Herton]

Hi Vincent

I'll kill the pipewire server, i would uninstall the packages but they are
hard deps for gnome now.

Is the fw file catpt is trying to load the correct one? Is there new fw
files that come with catpt that have been forgotten?
Is there a listiing for the error codes -110 and -2, are they missing files
or read permission issues?

Regards.




On Sun, 13 Jun 2021 at 18:08, Vincent Blut  wrote:

> Hi,
>
> Le 2021-06-05 08:31, Dekks Herton a écrit :
> > Hi
> >
> > Additional alsa-info script output
>
> From a quick look, alsa-info reports that you're running both PipeWire and
> PulseAudio sound servers. While it may not be the root cause of your issue,
> if you want to stick with the former, please disable the latter:
> $ sudo systemctl --user disable --now pulseaudio.service pulseaudio.socket
>
> Note though that using PipeWire as a substitute to PulseAudio/JACK/ALSA in
> Debian 11 is considered experimental.
>
> Cheers,
> Vincent
>

Bug#989891: unblock: libgee-0.8/0.20.4-1

[Graham Inggs]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package libgee-0.8

[ Reason ]
libgee-0.8/0.20.3-1 in testing currently FTBFS against the current
valac (#988020)

[ Impact ]
libgee-0.8 is not able to be updated in testing

[ Tests ]
libgee-0.8 has no autopkgtests, but a test suite is run during the build

[ Risks ]
Low, the changes in upstream 0.20.4 seem to be documentation fixes and
compatibility with the new valac only.  0.20.4-1 has been in unstable
for 3 months, and was part of the Ubuntu 21.04 release with no new
bugs filed.

[ Checklist ]
  [ ] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [ ] attach debdiff against the package in testing

[ Other info ]
The debdiff is very large and contains numerous generated .c files.
As can be seen in upstream's recent commits [1], the only changes
since 0.20.3 were:

* Various English and typo fixes in the documentation [2]
* Replace Memory.dup() with GLib.malloc() and Memory.copy() [3]
* Remove invalid usage of type-argument for
Gee.Future.SourceFuncArrayElement [4]
* Release 0.20.4 [5]


[1] https://gitlab.gnome.org/GNOME/libgee/-/commits/master
[2] 
https://gitlab.gnome.org/GNOME/libgee/-/commit/8b76b8cd0d1dafcf0a48048e6742a34d2c5e15c2
[3] 
https://gitlab.gnome.org/GNOME/libgee/-/commit/63d2b88e2652606b0571ff94c620949a6969b1fb
[4] 
https://gitlab.gnome.org/GNOME/libgee/-/commit/2ba2faf0140fdc0428a9b6b92669aa2daa9fc98c
[5] 
https://gitlab.gnome.org/GNOME/libgee/-/commit/db2efd468d32832ed787165ddda555706d888aca

Bug#989890: debspawn: make caching of downloaded .debs optional

[Helmut Grohne]

Package: debspawn
Version: 0.5.0-1
Severity: wishlist

Hi,

thanks for fixing all of the bugs I reported. I was looking into
debspawn again and noticed that there is no way to opt out of caching
downloaded .debs locally. One can cache the directory for caching them,
but not disable it.

Why would one want to do that? If your system resides on a SSD, writes
reduce the lifetime of your disk. Partially, one can avoid writes
incurred by debspawn by mounting a tmpfs on /var/tmp/debspawn (or moving
it to a tmpfs-based /tmp). The writes to the aptcache cannot be avoided
that way. My local network has a fast mirror, so downloading them over
and over again is not too bad. Quite to the contrary, the cache can be
shared by multiple hosts.

One relatively simple way I see here is to reserve a special value for
the APTCacheDir setting for disabling the cache. It seems like toml
doesn't have any equivalent to None or null and the suggestion is to
skip the field in such a case. Unfortunately, that case already has the
semantics of using the default value. Since all valid values of
APTCacheDir should start with a slash, maybe "disabled" works?

Helmut

Bug#989597: release.debian.org: upgrade issue: non-coinstallability of libgdal20 and libgdal28

[Sebastiaan Couwenberg]

On 6/15/21 1:00 PM, Sebastian Ramacher wrote:
> If neither you as maintainer nor upstream care about upgrade without
> data loss, I don't think postgis is suitable to be included in a stable
> release. Best option moving forward is to get postgis and its reverse
> dependencies removed from bullseye.

Removing postgis during distribution upgrade does not cause data loss.
Don't try to make this issue bigger than it is.

As an RM you should know that stable releases include a lot more
packages which have issues more severe than this one for postgis.

Your attempt to force my hand is with threats of removal from stable are
not appreciated.

Kind Regards,

Bas

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

Bug#982433: rmdir: failed to remove '/var/cache/app-info/': Directory not empty

[Petter Reinholdtsen]

Control: reassign -1 appstream
Control: found -1 0.14.0-2
Control: affects -1 isenkram-cli

[積丹尼 Dan Jacobson]
> [INSTALL, DEPENDENCIES] appstream:amd64 0.14.0-2
> [INSTALL, DEPENDENCIES] gir1.2-appstream-1.0:amd64 0.14.0-2
> [INSTALL, DEPENDENCIES] libappstream4:amd64 0.14.0-2
> [INSTALL, DEPENDENCIES] liblmdb0:amd64 0.9.24-1
> [INSTALL, DEPENDENCIES] libstemmer0d:amd64 2.1.0-1
> [INSTALL, DEPENDENCIES] libyaml-0-2:amd64 0.2.2-1
> [INSTALL] isenkram-cli:amd64 0.45

Right.  I suspect appstream might be the source of this, reassigning.
Please send the issue back if this was wrong.

-- 
Happy hacking
Petter Reinholdtsen

Bug#989597: release.debian.org: upgrade issue: non-coinstallability of libgdal20 and libgdal28

[Sebastian Ramacher]

On 2021-06-15 06:05:28, Sebastiaan Couwenberg wrote:
> On 6/14/21 9:55 PM, Sebastian Ramacher wrote:
> > On 2021-06-14 13:49:47 +0200, Sebastiaan Couwenberg wrote:
> >> On 6/14/21 1:30 PM, Andreas Beckmann wrote:
> >>> On 14/06/2021 10.06, Sebastiaan Couwenberg wrote:
>  What actual problems do are solved by making them co-installable?
> 
>  So far the only actualy problem that has been identified is the need for
>  `apt full-upgrade` twice when the Breaks/Replaces on libgdal20 is not
>  present.
> >>>
> >>> apt currently fails to find an upgrade path for libmrpt-dev (logfile
> >>> attached, no bug filed, yet). The only solution I could find so far was
> >>> the big hammer: adding a Breaks against libopencv-core3.2 (or similar)
> >>> to gcc-10-base.
> >>> With a co-installable libgdal20/libgdal28 this is gone because the huge
> >>> dependency trees no longer conflict with each other.
> >>>
> >>> Co-installable libgdal20/28 solves a lot of buster->bullseye upgrade
> >>> issues. So I can concentrate on fixing the remaining incomplete
> >>> (unversioned) python (2) removal bits. ;-)
> >>
> >> If co-installable libgdal is a must, then I'd rather drop gdal-data and
> >> move its content back to libgdal28 with an override for the
> >> big-usr-share lintian issue. That's how it was a long time ago:
> >>
> >>  
> >> https://salsa.debian.org/debian-gis-team/gdal/-/commit/140ab452687b2a6d92f3b760379fbbd81f80794a
> >>
> >> I'm not in favor of either option, though.
> > 
> > Not having libgdal20 and libgdal28 co-installable makes it unneccessarly
> > hard to upgrade all of libgdal's reverse dependencies that also bumped
> > SONAMEs.  That set of packages includes at least opencv, pdal, qgis,
> > vtk7, otb, mapnik, openscenegraph and gazebo. And then there are
> > probably even more that are reverse dependencies of those packages which
> > bumped SONAME.  So this issues affects many many packages and is not
> > only related to postgis.
> 
> Again, postgis database upgrades have never been supported. You're
> wasting your time on that.
> 
> >From the many other packages I haven't seen other issues other than the
> partial upgrade with monteverdi which is fixed with Breaks/Replaces.
> 
> I really need more concrete cases to justify changes to gdal that I
> don't like but will have to maintain.

If neither you as maintainer nor upstream care about upgrade without
data loss, I don't think postgis is suitable to be included in a stable
release. Best option moving forward is to get postgis and its reverse
dependencies removed from bullseye.

Cheers

> 
> > In any case, all these options seem rather unsatisfying and fragile.
> > Manually building specific postgis versions against specific postgresql
> > versions seems like a recipe for desaster. If one screws up any of the
> > steps, one can only hope for a backup and needs to start over. libgdal's
> > co-installablity issue makes that even more brittle then necessary if
> > not impossible.
> 
> As said before, upgrade support of postgis is shit. Upstream does not
> take that use case very seriously, although some of the postgis
> developers are as unhappy with that as we are.
> 
> I don't have the time, energy, nor knowledge required to fix this
> upstream. So I've just been recreating my postgis databases in the new
> cluster after every distribution upgrade.
> 
> > To be honest, from a package in Debian I would expect more. This is a
> > frustrating upgrade experience. And even if we cannot fix postgis
> > upgrades in time, having libgdal20 and libgdal28 not co-installable,
> > makes it only more painful for our users. So I'd say, yes, libgdal20 and
> > libgdal28 co-installablity is a must.
> > 
> >> We can also drop the Breaks from gdal-data, and have libgdal20 be broken
> >> for the bits that use it. It will help with the dependency resolution.
> > 
> > If a non-function libgdal20 would mean that even if if installed, it's
> > completely useless for the cases above, then no, that's not an option.
> 
> The scope of how broken libgdal20 is without all of the data files it
> expects is difficult to determine. The data files are considered a hard
> dependency, hence the Breaks on libgdal20 due to the changes for PROJ 6.
> 
> Kind Regards,
> 
> Bas
> 
> -- 
>  GPG Key ID: 4096R/6750F10AE88D4AF1
> Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1
> 

-- 
Sebastian Ramacher

Bug#989889: libjs-pdf: Icons not displayed when using pdf.js in qutebrowser

[Johannes Broedel]

Package: libjs-pdf
Version: 2.6.347+dfsg-3
Severity: important
X-Debbugs-Cc: johannes.broe...@web.de

Dear Maintainer,

when running pdf.js in qutebrowser to display any .pdf files, no icons
are displayed, neither on the left hand side nor on the right hand side
(printing, full screen etc.). However, when hovering the mouse, the
background color of what should be the icons is modified. 

Starting qutebrowser from the command line, the following error message
is thrown (by qutebrowser, when opening the pdf with pdf.js): 

WARNING: pdfjs resource requested but not found: 
web/images/toolbarButton-print.svg
ERROR: NotFoundError while handling qute://* URL

In other words, the .svg graphics for the icon are not available. They
are, however, available on git for pdf.js, but seem to not be included
in the Debian package. 

I couldn't find the appropriate files in any other package libjs-pdf
depends upon, so I believe they should be included in the package?

Best regards, 
Johannes



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

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

Versions of packages libjs-pdf depends on:
ii  pdf.js-common  2.6.347+dfsg-3

libjs-pdf recommends no packages.

libjs-pdf suggests no packages.

-- no debconf information

Bug#989888: gnuradio-dev,gnuradio: ships files already in gr-soapy

[Andreas Beckmann]

Package: gnuradio-dev,gnuradio
Version: 3.9.2.0-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'sid' to 'experimental'.
It installed fine in 'sid', then the upgrade to 'experimental' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces

>From the attached log (scroll to the bottom...):

  Selecting previously unselected package gnuradio.
  Preparing to unpack .../113-gnuradio_3.9.2.0-1_amd64.deb ...
  Unpacking gnuradio (3.9.2.0-1) ...
  dpkg: error processing archive 
/tmp/apt-dpkg-install-E5LhJj/113-gnuradio_3.9.2.0-1_amd64.deb (--unpack):
   trying to overwrite '/usr/share/gnuradio/grc/blocks/soapy_sink.block.yml', 
which is also in package gr-soapy 2.1.3.1-1

  Selecting previously unselected package gnuradio-dev:amd64.
  Preparing to unpack .../170-gnuradio-dev_3.9.2.0-1_amd64.deb ...
  Unpacking gnuradio-dev:amd64 (3.9.2.0-1) ...
  dpkg: error processing archive 
/tmp/apt-dpkg-install-E5LhJj/170-gnuradio-dev_3.9.2.0-1_amd64.deb (--unpack):
   trying to overwrite '/usr/lib/x86_64-linux-gnu/libgnuradio-soapy.so', which 
is also in package gr-soapy 2.1.3.1-1
  Errors were encountered while processing:
   /tmp/apt-dpkg-install-E5LhJj/113-gnuradio_3.9.2.0-1_amd64.deb
   /tmp/apt-dpkg-install-E5LhJj/170-gnuradio-dev_3.9.2.0-1_amd64.deb


cheers,

Andreas


gr-soapy=2.1.3.1-1_gnuradio-dev=3.9.2.0-1.log.gz
Description: application/gzip

Bug#989887: /lib/systemd/system/netdata.service: systemd request to update out of date service file

[Guillaume Clercin]

Package: netdata-core
Version: 1.29.3-4
Severity: normal
File: /lib/systemd/system/netdata.service

Dear Maintainer,

systemd reports an obsolete value used in /lib/systemd/system/netdata.service.

# journalctl -b -u netdata
[...]
juin 04 13:10:17 kazoo systemd[1]: /lib/systemd/system/netdata.service:55: 
Standard output type syslog+console is obsolete, automatically updating to 
journal+console. Please update your unit file, and consider removing the 
setting altogether.
juin 04 13:10:17 kazoo systemd[1]: /lib/systemd/system/netdata.service:56: 
Standard output type syslog+console is obsolete, automatically updating to 
journal+console. Please update your unit file, and consider removing the 
setting altogether.
[...]

Best regards,
Guillaume

-- System Information:
Debian Release: 11.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)

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

Versions of packages netdata-core depends on:
ii  init-system-helpers  1.60
ii  libc62.31-12
ii  libcap2  1:2.44-1
ii  libcap2-bin  1:2.44-1
ii  libgcc-s110.2.1-6
ii  libjson-c5   0.15-2
ii  libjudydebian1   1.0.5-5+b2
ii  liblz4-1 1.9.3-2
ii  libmnl0  1.0.4-3
ii  libnetfilter-acct1   1.0.3-3
ii  libprotobuf233.12.4-1
ii  libsnappy1v5 1.1.8-1
ii  libssl1.11.1.1k-1
ii  libstdc++6   10.2.1-6
ii  libuuid1 2.36.1-7
ii  libuv1   1.40.0-1
ii  lsb-base 11.1.0
ii  zlib1g   1:1.2.11.dfsg-2

Versions of packages netdata-core recommends:
ii  curl  7.74.0-1.2

Versions of packages netdata-core suggests:
pn  apcupsd 
pn  hddtemp 
ii  iproute25.10.0-4
ii  iw  5.9-3
ii  lm-sensors  1:3.6.0-7
pn  nc  

-- no debconf information

Bug#960676: autofs: update service file

[Jörg Behrmann]

On Tue, Jun 15, 2021 at 09:00:36AM +, Mike Gabriel wrote:
> thanks for your contribution. To make an update possible for Debian bullseye
> (we are in deep freeze), I need a more dramatic description of things that
> might go wrong with the current .service file.
>
> Please explain the opposite of "robust" with concrete observations (i.e.
> bugs).
>
> Furthermore, have you tested the proposed service file with autofs-ldap???
> With autofs-ldap we still have a nasty race condition that leaves autofs
> non-function if it starts before nslcd (libnss LDAP caching daemon).
> 

I'm not sure I can help you with the latter, since we use sssd and have never
experienced any issues in that regard.

I'm currently debugging a race condition with another service that only depends
on autofs where a single autofs mountpoint doesn't work but all the others (all
backed via LDAP) are. The service in question usually starts at the same second
as autofs. Since notify will notify readiness when the service thinks it's ready
instead of at fork time, my hope is that it will go away if autofs is actually
ready, when it is shown as such. Just spitballing here, but maybe that's
the issue with nslcd for you, too? Unfortunately nslcd doesn't doesn't have
notification support, but I once worked around a similar issue with autofs data
in NIS by busy looping in ExecStartPre= until NIS was actually
working. Fortunately, with sssd this was no longer an issue. :)

And as a nit: the /var/run path was a log nuisance for a long time and the only
reason this has stopped, is because the systemd package now carries a patch to
silence the warning, because it was apparently easier to do that than fix the
service files all over Debian.

Since the autofs package is built without --with-systemd, the above service file
cannot be used out of the box. I'll rebuild autofs for my machines and will let
you know whether it fixes my issue, but even if it doesn't it would be a
positive change for all people using autofs on systemd.

I completely understand that this probably can't make it into bullseye, but
maybe for bookworm we can use the service file, that upstream has been shipping
since end of October 2018. :)


signature.asc
Description: PGP signature

Bug#966301: guile oom test fails (but currently not on buildds)

[Dylan Aïssi]

Le mar. 15 juin 2021 à 09:02, Rob Browning  a écrit :
>
> I'm fairly uneasy with disabling them all, if that's what we're
> currently doing.  I'll plan to take a look and/or talk to upstream soon,
> though I might not get to it in depth until the weekend.
>

I agree it would be better to skip specific tests instead to ignore
failures for all tests.
I did not propose a debdiff to skip only test-out-of-memory for all
arches because it would re-enable other failing tests for other
arches. I did not want to introduce new FTBFS at this step of freeze.

I let you deal with it :-)

Best,
Dylan

Bug#989886: libyang: autopkgtest regression

[Graham Inggs]

Source: libyang
Version: 1.0.184-2
Severity: serious
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: regression

Hi Maintainer

The autopkgtest of libyang fails in testing where it succeeded in the past [1].
The current failure seems to be due python3-yang being dropped:

E: Unable to locate package python3-yang
command1 FAIL badpkg
blame: libyang
badpkg: Test dependencies are unsatisfiable. A common reason is that
your testbed is out of date with respect to the archive, and you need
to use a current testbed or run apt-get update or use -U.

This regression also prevents libyang/1.0.225-1 from migrating to testing.

Regards
Graham


[1] https://ci.debian.net/packages/liby/libyang/testing/amd64/

Bug#980271: #980271 installation-reports: Toshiba Tecra 8000 Installation report Bullseye

[Philip Hands]

Holger Wansing  writes:

> I have verified that on a current testing installation system, there is
> still /etc/pcmciautils/ existing, and no /etc/pcmcia/.
>
> So re-assigning to pcmciautils package.
>
> Also, I attached a patch, which should hopefully fix this for the udeb.

Applying your patch, and enabling salsa-CI/branch2repo gives this:

  
https://salsa.debian.org/philh/pcmciautils/-/commit/b3d9a17f90201ca39e0e5374f79a59c0fd74b98c

which launches this pipeline:

  https://salsa.debian.org/philh/pcmciautils/-/pipelines/262209

resulting in this mini-iso:

  
https://salsa.debian.org/installer-team/debian-installer/-/jobs/1704435/artifacts/file/public/gtk-mini.iso

which is able to load the pcmciautils udeb from here:

  
https://salsa.debian.org/installer-team/branch2repo/-/jobs/1704433/artifacts/browse/public/

which when tested under openQA ends up showing us that it now includes
the right path:

  https://openqa.debian.net/tests/7562#step/complete_install/38

while the same check against the daily builds does not:

  https://openqa.debian.net/tests/7576#step/complete_install/38

(you're looking for the "Result: ..." bit in the middle of the screen,
which shows the output from running `ls -ld /etc/pcm*`)

HTH

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

Bug#989559: ***SPAM*** Re: Bug#989559 closed by Peter Palfrader (Bug#989559 fixed in mirrors)

[Rudi]

Great,


Thank you very much!


On 2021/06/15 11:20, Peter Palfrader wrote:

https://mirror-master.debian.org/status/mirror-info/mirror.hostafrica.co.za.html
shows your mirror is mostly working, so its score is steadily rising.

When the score hits 50, your mirror will be listed in
https://mirror-master.debian.org/status/Mirrors.masterlist
and then, when the website gets rebuilt next time (which should happen at
least daily), your mirror should end up onwww.debian.org

--

Bug#989885: nvidia-driver: package should recommend libnvidia-encode1

[Andreas Beckmann]

On 15/06/2021 10.53, Andrea Pappacoda wrote:

libnvidia-encode1 contains the library needed to use NVENC, used to encode
videos on the GPU, and depends on libnvcuvid1, needed for NVDEC, the video
decoder.
They are part of the Nvidia driver, and some users, especially inexperienced
ones, would expect to have support for them after installing the nvidia-driver
package.


Of course we can add that ;-)
Do we have software in Debian (probably contrib or non-free) that is 
capable of using it?
I didn't add dependencies yet for several libraries that are bundled 
with the driver because there are no known consumers. (E.g. 
libnvidia-fbc1 has in its description: "NvFBCOpenGL is a private API 
that is only available to approved partners for use in remote graphics 
scenarios.")


Andreas

Bug#907576: . dream --A Software Digital Radio Mondiale Receiver

[Christoph Berg]

Re: GMiller
> For  the subject project, I have encountered a roadblock while attempting to 
> use the 'Salsa Web Terminal'. I filed Gitlab Issue 233 (see attachments) 
> seeking information to prepare a 'gitlab-webide.yml' file (I searched but 
> could find no documentation on it). The response to 233 says "To upload 
> designs, you'll need to enable LFS and have an admin enable hashed storage".

Sorry, I can help you with packaging hamradio software, but please use
a normal editor like everyone else. There is no need to bother with
funky web stuff, especially if it doesn't work out of the box.

Christoph

Bug#989559: closed by Peter Palfrader (Bug#989559 fixed in mirrors)

[Peter Palfrader]

On Tue, 15 Jun 2021, Rudi wrote:

> Hi,
> 
> 
> When will our site be listed on the mirrors page,
> https://www.debian.org/mirror/list ?

https://mirror-master.debian.org/status/mirror-info/mirror.hostafrica.co.za.html
shows your mirror is mostly working, so its score is steadily rising.

When the score hits 50, your mirror will be listed in
https://mirror-master.debian.org/status/Mirrors.masterlist
and then, when the website gets rebuilt next time (which should happen at
least daily), your mirror should end up on www.debian.org

Cheers,

-- 
|  .''`.   ** Debian **
  Peter Palfrader   | : :' :  The  universal
 https://www.palfrader.org/ | `. `'  Operating System
|   `-https://www.debian.org/

Bug#989884: isenkram-cli: isenkram-autoinstall-firmware doesn't find any firmware packages

[Petter Reinholdtsen]

Control: severity -1 important

[Cyril Brulebois]
> Justification: doesn't fullfil its purpose out of the box

Thank you for the feedback.  The severity seem to be based on the
misunderstanding that the purpose of isenkram-cli is to provide
isenkram-autoinstall-firmware, while it actually is to provide
isenkram-lookup and friends, so I set it to important which reflect the
importance of the isenkram-autoinstall-firmware script.

When that is said, the bugs you found should be fixed and I am having a
look at your patches.

> Finally, I haven't seen this return anything:
>
> appstreamlookup() {
> fwfile="$1"
> appstreamcli what-provides firmware:runtime "$fwfile" | \
>   awk '/Package:/ { print $2}'
> }
>
> I'm no appstream expert though, so I have no idea whether that's an
> appstreamcli limitation, a usage problem from the caller side, and/or
> some requirements that aren't met on the setup side. It's still a little
> surprising to me as both code and comments suggest appstream is the
> preferred way to get the information…

I am not an appstream expert either, but lets bring "my" expert Matthias
Klumpp into the loop.  Perhaps he got a clue what is going wrong here?

I ran this test on a few of my machines, and it provide several matches:

  for f in $(find /lib/firmware/ -type f |sed s%/lib/firmware/%%); do
appstreamcli what-provides firmware:runtime $f
  done

-- 
Happy hacking
Petter Reinholdtsen

Bug#989559: ***SPAM*** Bug#989559 closed by Peter Palfrader (Bug#989559 fixed in mirrors)

[Rudi]

Hi,


When will our site be listed on the mirrors page, 
https://www.debian.org/mirror/list ?


On 2021/06/08 10:42, Debian Bug Tracking System wrote:

This is an automatic notification regarding your Bug report
which was filed against the mirrors package:

#989559: mirror submission for mirror.hostafrica.co.za

It has been closed by Peter Palfrader .

Their explanation is attached below along with your original report.
If this explanation is unsatisfactory and you have not received a
better one in a separate message then please contact Peter Palfrader 
 by
replying to this email.



--

Bug#960676: autofs: update service file

[Jörg Behrmann]

Package: autofs
Version: 5.1.7-1
Followup-For: Bug #960676

The current upstream version of autofs provides a sample service file that for
Debian would look like this

> [Unit]
> Description=Automounts filesystems on demand
> After=network.target ypbind.service sssd.service network-online.target 
> remote-fs.target rpc-statd.service rpcbind.service
> Wants=network-online.target rpc-statd.service rpcbind.service
>
> [Service]
> Type=notify
> EnvironmentFile=-/etc/default/autofs
> ExecStart=/usr/sbin/automount $OPTIONS --systemd-service --dont-check-daemon
> ExecReload=/usr/bin/kill -HUP $MAINPID
> KillMode=process
> TimeoutSec=180
>
> [Install]
> WantedBy=multi-user.targe

It would be great if you could change the service file to this. While those
options are not documented in the man page, they are visible in the help output
of the automount command.

Changing the service file would make the service more robust.

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

Kernel: Linux 5.10.0-5-amd64 (SMP w/6 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages autofs depends on:
ii  init-system-helpers  1.60
ii  libc62.31-12
ii  libnsl2  1.3.0-2
ii  libtirpc31.3.1-1
ii  libxml2  2.9.10+dfsg-6.7
ii  ucf  3.0043

Versions of packages autofs recommends:
ii  e2fsprogs   1.46.2-1
ii  kmod28-1
ii  nfs-common  1:1.3.4-5

autofs suggests no packages.

-- no debconf information