Bug#965097: firejail: Firejail Disables U2F/WebAuthn By Default

[Reiner Herrmann]

Control: forwarded -1 https://github.com/netblue30/firejail/issues/3513

Hi Jeff,

On Wed, Jul 15, 2020 at 10:11:55PM -0700, Jeff Root wrote:
>* What fixed the problem?
> 
>I discovered that /etc/firejail/firejail.conf had
> 
> # Disable U2F in browsers, default enabled.
> # browser-disable-u2f yes
> 
>I uncommented that line, and changed it to "no" to solve the problem.
> 
>   I believe there are two problems here.  First, I don't see any reason why
> WebAuthn would be disabled by default.  I'm not aware of any reason that would
> improve security or usability.  Second, it was very difficult to understand
> this setting; the man page documents BROWSER_DISABLE_U2F, and explains how to
> _disable_ U2F, but not how to ENable U2F.  As Debian/upstream has it disabled
> by default, I think it would be better for the man page to show how to enable
> it, or preferably show how to enable it.  The documentation (and this is 
> likely
> an upstream issue) doesn't really describe how the profiles are used, what the
> config file is for, or how to override these settings.  (For example, there's 
> a
> command line argument to firejail, --nou2f, but no sign of how to _not_ 
> disable
> U2F.
> 
>   I would suggest that Debian change that default setting to "no" so that U2F
> works out of the box.

U2F is intentionally disabled by default.
The firefox profile (also a few others) currently contains:

> /etc/firejail/firefox-common.profile
> 43:?BROWSER_DISABLE_U2F: nou2f
> 52:?BROWSER_DISABLE_U2F: private-dev

With browser-disable-u2f disabled, this would also disable private-dev,
which would mean that the browser has access to the whole /dev directory
(instead of only whitelisted devices), which increases the potential
attack surface.

I think most users are currently not using U2F, so I'd like to keep the
default in sync with upstream.
But I agree that this topic and its documentation is currently
confusing, so I reported this upstream with the suggestion to improve
documentation.

Kind regards,
  Reiner


signature.asc
Description: PGP signature

Bug#966396: debhelper: should invoke perl as /usr/bin/perl

[Dominic Hargreaves]

On Thu, Jul 30, 2020 at 03:09:43PM +0200, mat...@debian.org wrote:
> On Mon, Jul 27, 2020 at 11:17:37PM +0100, Dominic Hargreaves wrote:
> > > > This smells like a bug in debhelper to me - perl policy says that perl
> > > > should be /usr/bin/perl in shebangs, and I think the same should apply
> > > > here. I'm amazed this hasn't bit us before, if I'm right (it's been like
> > > > this since at least 2009, and probably forever).
> > > > 
> > > > https://salsa.debian.org/debian/debhelper/-/blob/master/lib/Debian/Debhelper/Buildsystem/perl_build.pm#L44
> > > 
> > > Yes, that was the problem. After "perlbrew off" it works as expected. It 
> > > is an old problem indeed.
> > > 
> > Filing this as a bug, with a proposed patch at
> > https://salsa.debian.org/debian/debhelper/-/merge_requests/40
> 
> may I disagree?
> I'll admit I never had to do it with perl, but every time people insists
> on using full paths overrinding a program by hacking on PATH suddenly
> becomes much harder.

I'm not persuaded by this argument. Debhelper is invoking perl in order
to build Debian packages, whose contents must be compatible with
/usr/bin/perl. Anyone hacking on something needing to change /usr/bin/perl
is already going to need to deal with replacing /usr/bin/perl in order
to test anything properly.

> As usual, one would expect that their build system is sane, having a
> non-working (or whatever was the problem there) `perl` during a build is
> very much the fault of the person controlling that system, not of
> debhelper.

Not at all. Whilst release builds of packages should of course be built
in clean environments, this is not a reason to break developer workflows
when people happen to use a different perl for day to day activities.

Dominic.

Bug#966668: xfce4-weather-plugin: Still uses old bugzilla.xfce.org even though it has been replaced by gitlab.xfce.org

[Job Bautista]

Package: xfce4-weather-plugin
Version: 0.10.1-1+b1
Severity: minor
Tags: upstream

When the plugin reports that the API it uses is deprecated, it still directs 
people to file a bug to bugzilla.xfce.org, even though it has been made 
read-only since 29 May 2020.


-- System Information:
Distributor ID: Devuan
Description:Devuan GNU/Linux 4 (chimaera/ceres)
Release:testing/unstable
Codename:   n/a
Architecture: x86_64

Kernel: Linux 5.7.0-1-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=en_PH.UTF-8, LC_CTYPE=en_PH.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_PH:en
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages xfce4-weather-plugin depends on:
ii  libc62.31-2
ii  libgdk-pixbuf2.0-0   2.40.0+dfsg-5
ii  libglib2.0-0 2.64.4-1
ii  libgtk-3-0   3.24.20-1
ii  libpango-1.0-0   1.44.7-4
ii  libsoup2.4-1 2.70.0-1
ii  libxfce4panel-2.0-4  4.14.4-1
ii  libxfce4ui-2-0   4.14.1-1+b1
ii  libxfce4util74.14.0-1
ii  libxml2  2.9.10+dfsg-5+b1

xfce4-weather-plugin recommends no packages.

xfce4-weather-plugin suggests no packages.

-- no debconf information

signature.asc
Description: OpenPGP digital signature

Bug#966633: [debian-mysql] Bug#966633: libmariadb3: In Perl, doing a ping() after a disconnect() causes a segfault using DBD::mysql

[Dianne Skoll]

Hi, Otto,

> It would be best if you submitted your patch directly upstream at
>
https://github.com/mariadb-corporation/mariadb-connector-c/

Thank you; I have done that at
https://jira.mariadb.org/browse/CONC-487

However, given the developer's response on
https://jira.mariadb.org/browse/CONC-289 I don't know if they will accept
the patch.

> They have the best knowledge to assess if this change is OK or if it
> has potential regressions.

Well, the patch simply sets pointers to NULL after the memory that they
point to has been freed.  They already do that in one other place
(the memset call in mysql_close sets mysql->options.extension to NULL)
with a comment "/* Clear pointers for better safety */" so I hope that
they (and Debian) will accept the patch.

Regards,

Dianne.
better safety */" so I hope that
they (and Debian) will accept the patch.

Regards,

Dianne.

Bug#966676: O: vtun -- virtual tunnel over TCP/IP networks

[Rodrigo Carvalho]

Package: wnpp
Severity: normal

I intend to orphan the vtun package.

The package description is:
 VTun is the easiest way to create virtual tunnels over TCP/IP networks
 with traffic shaping and compression.
 .
 It supports IP, PPP, SLIP, Ethernet and other tunnel types.
 .
 VTun is easily and highly configurable, it can be used for various
 network tasks.
 .
 VTun requires the universal TUN/TAP kernel module which can be found at
 http://vtun.sourceforge.net/tun/index.html or in the 2.4 and newer Linux
 kernels.
 .
 Note: This program includes an "encryption" feature intended to protect the
 tunneled data as it travels across the network. However, the protocol it uses
 is known to be very insecure, and you should not rely on it to deter anyone
 but a casual eavesdropper. See the included README.Encryption file for more
 information.

Bug#966682: Wrong package description

[Alessandro Gandelli]

Package: paperwork-gtk-l10n-fr
Version: 1.3.1-2

Dear Maintainer,
the title of the package description is: "Gui for paperwork-backend -
English localization"
while the package is -fr.

Thanks and best regards,
Alessandro.

Bug#966681: ITP: golang-gonum-v1-plot :Provides an API for building and drawing plots in Go

[Nilesh Patra]

Package: wnpp
Severity: wishlist
Owner: Nilesh Patra 
X-Debbugs-CC: debian-de...@lists.debian.org


* Package name: golang-gonum-v1-plot
  Version : 0.7.0-1
  Upstream Author : 2013-2019 Ethan Burns 
 Steve McCoy 
 Dan Kortschak 
 James Bell 
 Sebastien Binet 
* URL : https://github.com/gonum/plot

* License : BSD-3-clause
  Programming Lang: Golang
  Description : repository for plotting and visualizing data (library)
 gonum/plot is the new, official fork of code.google.com/p/plotinum.
 It provides an API for building and drawing plots in Go. Note that
 this new API is still in flux and may change. See the wiki for some
 example plots.
 .
 gonum/plot is split into a few packages:
 .
  * The plot package provides simple interface for laying out a plot and
provides primitives for drawing to it.
  * The plotter package provides a standard set of Plotters which use the
primitives provided by the plot package for drawing lines, scatter
plots, box plots, error bars, etc. to a plot. You do not need to use
the plotter package to make use of gonum/plot, however: see the wiki
for a tutorial on making your own custom plotters.
  * The plotutil package contains a few routines that allow some common
plot types to be made very easily. This package is quite new so it is
not as well tested as the others and it is bound to change.
  * The vg package provides a generic vector graphics API that sits on
top of other vector graphics back-ends such as a custom EPS back-end,
draw2d, SVGo, X-Window and gopdf

Bug#965018: RFS: freetype-py/2.2.0-1 -- Freetype Python bindings for Python 3

[Gianfranco Costamagna]

control: tags -1 moreinfo
On Sat, 1 Aug 2020 10:25:24 +0200 Bastian Germann  wrote:
> On Wed, 29 Jul 2020 17:45:32 +0200 mat...@debian.org wrote:
> > That's the `clean` step that is failing, which is done outside of the
> > chroot.  That's responsability of whoever is calling `pdebuild` to
> > satisfy.
> > 
> > If you are sure your source is clean you may as well just skip cleaning
> > and not use pdebuild:
> > dpkg-source -b .
> > dpkg-source --after-build .
> > pbuilder b ../freetype-py_2.2.0-1.dsc
> > the above sequence should prove that nothing is at fault here.
> 
> The package builds fine with the given steps.
> 
> 


nack.
+Copyright 2010-2018 Adobe (http://www.adobe.com/), with Reserved Font Name 
'Source'. All Rights Reserved. Source is a trademark of Adobe in the United 
States and/or other countries.
+
+This Font Software is licensed under the SIL Open Font License, Version 1.1.

missing licenses

other stuff LGTM

G.

Bug#966690: [Python-modules-team] Bug#966690: afew: Package is outdated.

[Emmanuel Arias]

Hi!

I can review it.
But IMHO this is not the best way to make a new upstream release update.
In this case there are 56 files to review.

You can join to the DPMT and make the change directly.


Cheers,
Arias Emmanuel
@eamanu
http://eamanu.com

El sáb., 1 de ago. de 2020 a la(s) 19:15,  escribió:
>
> Subject: afew: Package is outdated.
> Package: afew
> X-Debbugs-Cc: deb...@fritzreichwald.de
> Version: 1.3.0-1
> Severity: normal
> Tags: patch
>
> Dear Maintainer,
>
> I just recognized that afew is outdated in debian.
> So i prepared
> https://salsa.debian.org/python-team/modules/afew/-/merge_requests/2 to
> fix this.
>
> Please contact me if there is something I should fix before you can
> merge it.
>
> Thanks!
>
> Best regards Fritz (fiete in IRC)
>
> ___
> Python-modules-team mailing list
> python-modules-t...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/python-modules-team

Bug#966297: UDD: mentors.debian.net schema change

[Lucas Nussbaum]

Hi Baptiste,

On 26/07/20 at 10:39 +0200, Baptiste BEAUPLAT wrote:
> Package: qa.debian.org
> User: qa.debian@packages.debian.org
> Usertags: udd
> 
> Hi,
> 
> mentors.debian.net has changed its framework and its database schema.
> The UDD importer named `mentors_gatherer.rb`[1] is not compatible with
> this new schema and will stop working.
> 
> See the new proposal for the mentors UDD tables (attached to this mail):
> 
> - mentors-core-schema.dot: The core schemas of mentors with all data
> tables (without internal django stuff)
> - mentors-useful-table-schema.dot: A proposal of tables that could be
> used by the UDD gatherer to import data from
> - mentors-udd-schema.dot: A proposal of tables that could be used by the
> UDD gatherer to import data to
> 
> Once we agree on the new schema for UDD for the mentors tables, I'll be
> happy to provide a patch for the gatherer and the schema.
> 
> Note that currently the password of udd postgresql mentors account lives
> in cleartext, in the gatherer, in the repository. Thus, I'm disabling
> immediately that access. I'll provide the new password but that will
> have to stay out of the repo.
> 
> [1]: https://salsa.debian.org/qa/udd/-/blob/master/udd/mentors_gatherer.rb

I think that it would be better if mentors.d.n would provide a JSON
export of its data that it useful for UDD.

Regarding data that should be replicated in UDD, I would prefer
something simpler that is enough, typically for DMD, to notify that
there's a new version waiting, but that still requires going to
mentors.d.n for details. I wonder if we should have more than one table,
that just describes the last upload for a given source or (source,user)
(it's not clear to me if several users can simultaneously upload
competing versions of the same source package).

Lucas


signature.asc
Description: PGP signature

Bug#966656: geany-plugin-doc: default configuration point to firefox as external browser

[Stanislav V. Vlasov]

Package: geany-plugin-doc
Version: 1.33+dfsg-1+b1
Severity: minor

Dear Maintainer,

I have chromium as default browser and expect to open any url in them.
Url from geany opened in firefox.
I think, setting 'sensible-browser' instead 'firefox' in default config is more 
useful.

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

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

Versions of packages geany-plugin-doc depends on:
ii  geany [geany-abi-18176]  1.33-1
ii  geany-plugins-common 1.33+dfsg-1+b1
ii  libc62.28-10
ii  libglib2.0-0 2.58.3-2+deb10u2
ii  libgtk-3-0   3.24.5-1

geany-plugin-doc recommends no packages.

geany-plugin-doc suggests no packages.

-- no debconf information

Bug#966660: ansible: CVE-2020-10744

[Salvatore Bonaccorso]

Source: ansible
Version: 2.9.9+dfsg-1
Severity: important
Tags: security upstream
X-Debbugs-Cc: Debian Security Team 

Hi,

The following vulnerability was published for ansible.

CVE-2020-10744[0]:
| An incomplete fix was found for the fix of the flaw CVE-2020-1733
| ansible: insecure temporary directory when running become_user from
| become directive. The provided fix is insufficient to prevent the race
| condition on systems using ACLs and FUSE filesystems. Ansible Engine
| 2.7.18, 2.8.12, and 2.9.9 as well as previous versions are affected
| and Ansible Tower 3.4.5, 3.5.6 and 3.6.4 as well as previous versions
| are affected.

Th CVE itself is for an incomplete fix for CVE-2020-1733 as noted.
Trying to get more information from Red Hat bugzilla[1] or upstream[2]
but so far I only know that it beeing tracked internally.

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2020-10744
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-10744
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1835566
[2] https://github.com/ansible/ansible/issues/69782

Regards,
Salvatore

Bug#966670: pixelmed FTBFS: iconv: illegal input sequence at position 19

[Adrian Bunk]

Source: pixelmed
Version: 20200416-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/fetch.php?pkg=pixelmed=all=20200416-1=1596210399=0

...
# native2ascii -encoding UTF8 
ApplicationEntityConfigurationDialog_el.utf-8_properties 
>ApplicationEntityConfigurationDialog_el.properties
iconv -f UTF8 -t ascii//TRANSLIT 
ApplicationEntityConfigurationDialog_el.utf-8_properties 
>ApplicationEntityConfigurationDialog_el.properties
iconv: illegal input sequence at position 19
make[3]: *** [../../../Makefile.common.mk:85: 
ApplicationEntityConfigurationDialog_el.properties] Error 1

Bug#941925: segfaults in testsuite

[Rafael Laboissière]

* Sébastien Villemot  [2019-10-07 18:19]:


Package: octave-vibes
Version: 0.2.0-3
Severity: important

Octave segfaults when executing the testsuite of octave-vibes (both at build 
time and in the autopkgtest).


This is not caused by the Octave 5 transition, the problem was already there 
with Octave 4.4.


Version 0.2.0-6 of octave-vibes builds fine on all architectures and the 
autopkgtest pass.  Can we close this bug report ?


Best,

Rafael Laboissière

Bug#908694: album-data: diff for NMU version 4.05-7.1

[Sudip Mukherjee]

Control: tags 908694 + patch
Control: tags 908694 + pending


Dear maintainer,

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

--
Regards
Sudip

diff -Nru album-data-4.05/debian/changelog album-data-4.05/debian/changelog
--- album-data-4.05/debian/changelog2016-04-05 17:02:39.0 +0100
+++ album-data-4.05/debian/changelog2020-08-01 15:43:30.0 +0100
@@ -1,3 +1,11 @@
+album-data (4.05-7.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Removed dependency on libjs-swfobject. (Closes: #908694)
+- Upstream has confirmed. (See: #964105)
+
+ -- Sudip Mukherjee   Sat, 01 Aug 2020 15:43:30 
+0100
+
 album-data (4.05-7) unstable; urgency=low
 
   * Change Vcs-Browser to use https.
diff -Nru album-data-4.05/debian/control album-data-4.05/debian/control
--- album-data-4.05/debian/control  2016-04-05 16:08:03.0 +0100
+++ album-data-4.05/debian/control  2020-08-01 15:41:25.0 +0100
@@ -10,7 +10,7 @@
 
 Package: album-data
 Architecture: all
-Depends: ${misc:Depends}, album, libjs-swfobject
+Depends: ${misc:Depends}, album
 Description: themes, plugins and translations for album
  Album is a perl script that can create HTML photo albums for your
  directories of images. This package provides themes, plugins and

Bug#966544: [Pkg-net-snmp-devel] Bug#966544: snmpd: extend option broken after update

[Axel Uhl]

Same here. snmpd broke over night, now my mrtg which is reporting, e.g., 
disk temperatures using a smartctl-based cannot be reported anymore, and 
I was wondering why this cron job now keeps flooding my inbox... All 
intranet, all very inconvenient. As others mentioned, a warning would 
have been nice. Now I need to compile from sources. What a hassle!


On Fri, 31 Jul 2020 12:32:05 +0900 Christian Balzer  wrote:


Hello Craig,

These issues, do they warrant utterly breaking things w/o any recourse
short of recompiling things for many, many users that use the extend
feature?
Especially given the fact that SNMP traffic tends to be on private
networks and the feature not being enabled by default in the config.

At the very least a "this will break things, abort now" missive during
upgrade would have been nice.

If upstream can't/won't fix this snmpd has lost it's usefulness for me in
the long run compared to other data collectors.

Regards,

Christian


On Fri, 31 Jul 2020 10:46:29 +1000 Craig Small  wrote:
> Hi James,
>   That would have been intentional, the EXTEND MIB has major security
> issues.
> 
>  - Craig
> 
> 
> On Thu, 30 Jul 2020 at 23:03, James Greig  wrote:
> 
> > Package: snmpd

> > Version: 5.7.3+dfsg-1.7+deb9u2
> > Severity: important
> >
> > Dear Maintainer,
> >
> > *** Reporter, please consider answering these questions, where appropriate
> > ***
> >
> > Updating snmpd from deb9u1 to deb9u2 via apt on any stretch system
> > breaks the ability to use 'extend' in snmpd.
> >
> > After updating on any stretch system and restarting snmpd this error will
> > appear:-
> >
> > Warning: Unknown token: extend
> >
> > It's likely the latest binary build of this package has not included
> > options to
> > enable extend and/or other extras.
> >
> > *** End of the template - remove these template lines ***
> >
> >
> > -- System Information:
> > Debian Release: 9.13
> >   APT prefers oldstable-updates
> >   APT policy: (500, 'oldstable-updates'), (500, 'oldstable')
> > Architecture: amd64 (x86_64)
> >




smime.p7s
Description: S/MIME Cryptographic Signature

Bug#966679: src:rust-csv: fails to migrate to testing for too long: autopkgtest regression

[Paul Gevers]

Source: rust-csv
Version: 1.1.1-1
Severity: serious
Control: close -1 1.1.3-1
Tags: sid bullseye
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 962803

Dear maintainer(s),

As recently announced [1], the Release Team now considers packages that
are out-of-sync between testing and unstable for more than 60 days as
having a Release Critical bug in testing. Your package src:rust-csv in
its current version in unstable has been trying to migrate for 60 days
[2]. Hence, I am filing this bug.

If a package is out of sync between unstable and testing for a longer
period, this usually means that bugs in the package in testing cannot be
fixed via unstable. Additionally, blocked packages can have impact on
other packages, which makes preparing for the release more difficult.
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that
hamper the migration of their package in a timely manner.

This bug will trigger auto-removal when appropriate. As with all new
bugs, there will be at least 30 days before the package is auto-removed.

I have immediately closed this bug with the version in unstable, so if
that version or a later version migrates, this bug will no longer affect
testing. I have also tagged this bug to only affect sid and bullseye, so
it doesn't affect (old-)stable.

If you believe your package is unable to migrate to testing due to
issues beyond your control, don't hesitate to contact the Release Team.

Paul

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




signature.asc
Description: OpenPGP digital signature

Bug#966683: Wrong package description

[Alessandro Gandelli]

Package: paperwork-gtk-l10n-en
Version: 1.3.1-2

Dear Maintainer,
the title of the package description is: "Gui for paperwork-backend -
French localization"
while the package is -en.

Thanks and best regards,
Alessandro.

Bug#966675: Moved

[Jim Paris]

It appears to have been split out of libguestfs-tools and into
https://github.com/libguestfs/virt-v2v, according to guestfs-hacking(1).

Jim

Bug#949826: buster-pu: package haproxy/1.8.19-1

[Salvatore Bonaccorso]

Hi Vincent,

On Sat, Aug 01, 2020 at 03:11:22PM +0200, Vincent Bernat wrote:
>  ❦ 31 juillet 2020 10:14 +02, Salvatore Bonaccorso:
> 
> >> > > > This needs to be rebased to the 1.8.19-1+deb10u1 which was released
> >> > > > as
> >> > > > DSA 4577-1 AFAICT.
> >> > > 
> >> > > Oh, sorry. Here is the updated patch.
> >> > 
> >> > Please go ahead.
> >> 
> >> Too late for buster 10.4 but actually this would need to be rebased to
> >> the 1.8.19-1+deb10u2 as there was another DSA for haproxy (but not
> >> including this CVE fix). So the version will be 1.8.19-1+deb10u3 by
> >> now.
> >> 
> >> If before the next point release will be another haproxy update this
> >> fix for the CVE can be included as well, IMHO.
> >
> > Did you saw the acknowledgement from vom Adam? Could you upload to
> > buster-proposed-updates?
> 
> Hello Salvatore,
> 
> I've just uploaded it.

Thank you!

Regards,
Salvatore

Bug#886884: zsh sometimes crashes when it receives a SIGQUIT signal

[Vincent Lefevre]

Package: zsh
Version: 5.8-5
Followup-For: Bug #886884

I've just reported the following issue in zsh-workers:

Ctrl-\ during completion makes zsh quit. To reproduce the problem
with "zsh -f" under Debian/unstable:

Run the following commands:

zstyle ':completion:*' menu select=long
autoload -U compinit
compinit

Then ';' followed by [Tab]. I get:

zsh: do you wish to see all 6124 possibilities (3062 lines)?

Type [Tab] again, then Ctrl-\. I get:

[...]
_gemlnstat
_generic  ^\zsh: quit (core dumped)  zsh -f

(with a backtrace).

This is the same kind of issue.

-- Package-specific info:

Packages which provide vendor completions:

Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name   VersionArchitecture Description
+++-==-==--===
ii  curl   7.68.0-1+b1amd64command line tool for 
transferring data with URL syntax
ii  meson  0.55.0-2   all  high-productivity build system
ii  ninja-build1.10.0-2   amd64small build system closest in 
spirit to Make
ii  pass   1.7.3-2all  lightweight directory-based 
password manager
ii  pulseaudio 13.0-5 amd64PulseAudio sound server
ii  qpdf   10.0.1-2   amd64tools for transforming and 
inspecting PDF files
ii  systemd245.7-1amd64system and service manager
ii  udev   245.7-1amd64/dev/ and hotplug management 
daemon
ii  vlc-bin3.0.11-4+b1amd64binaries from VLC
ii  youtube-dl 2020.06.16.1-1 all  downloader of videos from 
YouTube and other sites

The following files were modified:

/etc/systemd/journald.conf
/etc/systemd/logind.conf
/etc/systemd/system.conf

dpkg-query: no path found matching pattern /usr/share/zsh/vendor-functions/


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

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

Versions of packages zsh depends on:
ii  libc6   2.31-2
ii  libcap2 1:2.36-1
ii  libtinfo6   6.2-1
ii  zsh-common  5.8-5

Versions of packages zsh recommends:
ii  libgdbm6  1.18.1-5
ii  libncursesw6  6.2-1
ii  libpcre3  2:8.39-13

Versions of packages zsh suggests:
ii  zsh-doc  5.8-5

-- no debconf information

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

Bug#966672: ansible: CVE-2020-14332

[Salvatore Bonaccorso]

Source: ansible
Version: 2.9.9+dfsg-1
Severity: important
Tags: security upstream
X-Debbugs-Cc: Debian Security Team 

Hi,

The following vulnerability was published for ansible.

CVE-2020-14332[0]:
| module_args does not censor properly in --check mode

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2020-14332
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-14332
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1857805
[2] https://github.com/ansible/ansible/pull/71033

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#966575: grub-pc: error: symbol `grub_calloc' not found.

[Steve McIntyre]

>From conversation in IRC:

1. If the device(s) mentioned in grub-pc/install_devices multiselect
   don't exist when grub-install is run, it should stop and warn the
   user that there might be a problem

   DSA have this on a VM, for example:

   grub-pc grub-pc/install_devices 
multiselect/dev/disk/by-id/scsi-3600508b1001052395358323050350006

2. Warn if install_devices is empty?

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"You can't barbecue lettuce!" -- Ellie Crane

Bug#963286: libisnativec-java: diff for NMU version 5.3.20100629+fix-2.1

[Sudip Mukherjee]

Just for the records - I cancelled the NMU and uploaded it as "Team
upload" as discussed in
https://lists.debian.org/debian-java/2020/08/msg0.html.

-- 
Regards
Sudip

Bug#966011: gajim crashes at startup since v1.2

[debacle]

On 2020-08-01 12:16, Petr Gajdůšek wrote:
> According to https://dev.gajim.org/gajim/gajim/-/issues/10069 there is
> a table 'caps_cache' in sqlite DB ~/.local/share/gajim/logs.db that
> shouldn't be there (it's supposed to be only in
> ~/.cache/gajim/cache.db).
>
> Running 
> 
> sqlite3 ~/.local/share/gajim/logs.db "DROP TABLE caps_cache"
>
> did help.

Florian, could you try that and report whether it helped?

TIA!

Bug#964853: hw-probe: add support for running hw-probe once for the Debian installer

[Andrey Ponomarenko]

You'd better to use 'hw-probe -all -upload -minimal' to avoid uploading of 
unnecessary logs (including boot.log). The -probe option is currently broken as 
no one used it before (I'll try to fix it in 1.6 but it should be equivalent to 
the -minimal option).

Bug#955413: btrfs-progs: new mount-time checking causes systemd to timeout and boot failure

[Graham Cobb]

Package: btrfs-progs
Version: 5.7-1
Followup-For: Bug #955413

Thanks for looking into it. I agree with your analysis but the issue is real.
I think the long mount times tend to occur when there are large numbers of
subvolumes and other large trees.

Although the problem is not fixable in btrfs-progs, I think it needs a NEWS item
in btrfs-progs - otherwise many people who use btrfs disks will hit big 
problems after
their Debian upgrade with no idea what the problem is or how they can fix it.

I think including the NEWS text I proposed in the btrfs-progs package would
avoid problems for a significant percentage of existing Debian btrfs users.

Bug#966685: inchi FTCBFS: uses the build architecture compiler

[Helmut Grohne]

Source: inchi
Version: 1.03+dfsg-2
User: debian-cr...@lists.debian.org
Usertags: ftcbfs
Tags: patch upstream

inchi fails to cross build from source, because it uses the build
architecture compiler. dh_auto_build passes a cross compiler via the
standard variable CC, but inchi's makefile expects it in C_COMPILER and
two other variables. The attached patch reworks the makefile to pick up
CC by default while still honouring the users choice of C_COMPILER.
Please consider applying it.

Helmut
--- inchi-1.03+dfsg.orig/INCHI_API/gcc_so_makefile/makefile
+++ inchi-1.03+dfsg/INCHI_API/gcc_so_makefile/makefile
@@ -53,9 +53,14 @@
 endif
 INCHI_MAIN_PATHNAME = $(LIB_DIR)/$(INCHI_MAIN_NAME)
 
+# === C Compiler ===
+ifndef C_COMPILER
+  C_COMPILER = $(CC)
+endif
+
 # === Linker to create (Shared) InChI library 
 ifndef SHARED_LINK
-  SHARED_LINK = gcc -shared
+  SHARED_LINK = $(C_COMPILER) -shared
 endif
 
 # === Linker to create Main program =
@@ -65,7 +70,7 @@
  LINKER_CWD_PATH = -Wl,-R,""
   endif
   endif
-  LINKER = gcc -s $(LINKER_CWD_PATH)
+  LINKER = $(C_COMPILER) -s $(LINKER_CWD_PATH)
 endif
 
 ifndef P_LIBR
@@ -77,11 +82,6 @@
 endif
 
 
-# === C Compiler ===
-ifndef C_COMPILER
-  C_COMPILER = gcc
-endif
-
 # === C Compiler Options ===
 ifndef C_OPTIONS
   C_OPTIONS = `dpkg-buildflags --get CPPFLAGS` -ansi `dpkg-buildflags --get CFLAGS` -c

Bug#966686: please add build profiles noudeb and pkg.e2fsprogs.no-static to e2fsprogs

[Helmut Grohne]

Source: e2fsprogs
Version: 1.45.6-1
Severity: wishlist
Tags: patch

Hi Ted,

can I ask you to add more build profiles to e2fsprogs?

In the light of #966330, it would help a lot to have a
pkg.e2fsprogs.no-static profile as a workaround until the situation with
util-linux is sorted out. The profile would be useful beyond as it'd cut
down in build time.

I also suggest adding support for the standard noudeb profile. A number
of other packages already support it. Doing so here adds consistency to
the archive and again allows cutting down in build time.

The savings in build time are small. But if you build e2fsprogs ten
times a day (as we do on jenkins), that cost accumulates. It's a drop in
the bucket, but a relatively simple one.

Do you think that these features are worth their maintenance cost?

If you deem the cost inappropriate, please close the bug after tagging
it wontfix. There is no use in having it stick around.

In any case, I'm attaching a patch for your convenience.

Helmut
diff --minimal -Nru e2fsprogs-1.45.6/debian/changelog 
e2fsprogs-1.45.6/debian/changelog
--- e2fsprogs-1.45.6/debian/changelog   2020-03-21 04:49:33.0 +0100
+++ e2fsprogs-1.45.6/debian/changelog   2020-08-01 11:04:08.0 +0200
@@ -1,3 +1,10 @@
+e2fsprogs (1.45.6-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Add support for build profiles pkg.e2fsprogs.no-static and noudeb.
+
+ -- Helmut Grohne   Sat, 01 Aug 2020 11:04:08 +0200
+
 e2fsprogs (1.45.6-1) unstable; urgency=medium
 
   * New upstream release
diff --minimal -Nru e2fsprogs-1.45.6/debian/control 
e2fsprogs-1.45.6/debian/control
--- e2fsprogs-1.45.6/debian/control 2020-03-21 04:49:33.0 +0100
+++ e2fsprogs-1.45.6/debian/control 2020-08-01 10:59:29.0 +0200
@@ -33,6 +33,7 @@
  of the output will also be written to standard output.
 
 Package: e2fsck-static
+Build-Profiles: 
 Priority: optional
 Depends: ${misc:Depends}
 Recommends: sash | bash-static | zsh-static | busybox-static
@@ -132,6 +133,7 @@
  This package contains the development environment for the ss library.
 
 Package: e2fsprogs-udeb
+Build-Profiles: 
 Package-Type: udeb
 Section: debian-installer
 Priority: optional
diff --minimal -Nru e2fsprogs-1.45.6/debian/rules e2fsprogs-1.45.6/debian/rules
--- e2fsprogs-1.45.6/debian/rules   2020-03-21 04:49:33.0 +0100
+++ e2fsprogs-1.45.6/debian/rules   2020-08-01 11:04:08.0 +0200
@@ -68,7 +68,9 @@
 
 override_dh_auto_build:
$(MAKE) -C ${stdbuilddir} V=1 all
+ifeq (,$(filter pkg.e2fsprogs.no-static,$(DEB_BUILD_PROFILES)))
$(MAKE) -C ${stdbuilddir}/e2fsck V=1 e2fsck.static
+endif
if ! test -d debian/orig-gmo ; then \
mkdir debian/orig-gmo ; \
mv po/*.gmo po/*.po debian/orig-gmo ; \
@@ -96,9 +98,11 @@
   # static libs and .h files
$(MAKE) -C ${stdbuilddir} V=1 install-libs DESTDIR=${tmpdir} 
LDCONFIG=true
 
+ifeq (,$(filter pkg.e2fsprogs.no-static,$(DEB_BUILD_PROFILES)))
   # statically-linked fsck
${INSTALL_PROGRAM} ${stdbuilddir}/e2fsck/e2fsck.static ${tmpdir}/sbin
(cd debian/tmp/usr/share/man/man8 ; cp e2fsck.8 e2fsck.static.8)
+endif
 
 ifeq ($(DEB_HOST_ARCH_OS), hurd)
${INSTALL} -m 0644 misc/mke2fs-hurd.conf ${tmpdir}/etc/mke2fs.conf
@@ -110,10 +114,12 @@
dh_install
dh_missing --fail-missing
 
+ifeq (,$(filter noudeb,$(DEB_BUILD_PROFILES)))
 override_dh_lintian:
dh_lintian
$(INSTALL) -D -p -m644 debian/e2fsprogs-udeb.lintian-overrides \
debian/e2fsprogs-udeb/usr/share/lintian/overrides/e2fsprogs-udeb
+endif
 
 override_dh_installinfo:
   # HTML docs
@@ -151,13 +157,15 @@
patch debian/$$i.symbols < debian/$$i.tmp-patch; \
/bin/rm debian/$$i.tmp-patch; \
done
-   dh_makeshlibs --add-udeb=e2fsprogs-udeb
+   dh_makeshlibs $(if $(filter 
noudeb,$(DEB_BUILD_PROFILES)),,--add-udeb=e2fsprogs-udeb)
 
 override_dh_shlibdeps:
dh_shlibdeps -pe2fsprogs -l${stdbuilddir}/lib \
-- -Ldebian/e2fsprogs.shlibs.local
+ifeq (,$(filter noudeb,$(DEB_BUILD_PROFILES)))
dh_shlibdeps -pe2fsprogs-udeb -l${stdbuilddir}/lib \
-- -Ldebian/e2fsprogs-udeb.shlibs.local
+endif
 ifeq ($(SKIP_FUSE2FS),)
dh_shlibdeps -pfuse2fs -l${stdbuilddir}/lib \
-- -Ldebian/e2fsprogs.shlibs.local

Bug#966687: libselinux1-dev should be named libselinux-dev

[Helmut Grohne]

Package: libselinux1-dev
Version: 3.1-2
User: helm...@debian.org
Usertags: rebootstrap
Tags: patch

Development packages should not include a version. For that reason
libselinux1-dev also provides libselinux-dev. Downstream packages such
as sed correctly build depend on the unversioned libselinux-dev.

Unfortunately, there is no reliable way to determine which source
package provides libselinux-dev from looking at the .dsc files.
Therefore bootstrapping tools fail to figure out that libselinux needs
to be built for building sed. The information included in .dscs misses
provides. For packages that participate in the build closure of
essential, we need dependencies to target real packages.

Therefore libselinux-dev needs to become real. I think that renaming
libselinux1-dev to libselinux-dev and simultaneously switching the
provides to libselinux1-dev would do the trick with little risk of
disrupting others.

I'm attaching a patch for the proposed change. Do you see any
alternative solution?

Helmut
diff --minimal -Nru libselinux-3.1/debian/changelog 
libselinux-3.1/debian/changelog
--- libselinux-3.1/debian/changelog 2020-07-16 18:28:55.0 +0200
+++ libselinux-3.1/debian/changelog 2020-08-01 21:53:48.0 +0200
@@ -1,3 +1,10 @@
+libselinux (3.1-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Turn libselinux-dev real and make libselinux1-dev virtual. (Closes: #-1)
+
+ -- Helmut Grohne   Sat, 01 Aug 2020 21:53:48 +0200
+
 libselinux (3.1-2) unstable; urgency=medium
 
   [ Laurent Bigonville ]
diff --minimal -Nru libselinux-3.1/debian/control libselinux-3.1/debian/control
--- libselinux-3.1/debian/control   2020-07-16 18:28:55.0 +0200
+++ libselinux-3.1/debian/control   2020-08-01 21:52:30.0 +0200
@@ -58,7 +58,7 @@
  policy if necessary (e.g. to downgrade the policy format to an older
  version supported by the kernel) when loading policy.
 
-Package: libselinux1-dev
+Package: libselinux-dev
 Architecture: linux-any
 Depends: libselinux1 (= ${binary:Version}),
  libsepol1-dev (>= 3.1),
@@ -66,8 +66,8 @@
  ${misc:Depends}
 Section: libdevel
 Multi-Arch: same
-Provides: libselinux-dev
-Conflicts: libselinux-dev
+Provides: libselinux1-dev
+Conflicts: libselinux1-dev
 Description: SELinux development headers
  This package provides the  static libraries and header files
  needed for developing SELinux applications.  Security-enhanced Linux
diff --minimal -Nru libselinux-3.1/debian/libselinux-dev.install 
libselinux-3.1/debian/libselinux-dev.install
--- libselinux-3.1/debian/libselinux-dev.install1970-01-01 
01:00:00.0 +0100
+++ libselinux-3.1/debian/libselinux-dev.install2020-07-16 
18:28:55.0 +0200
@@ -0,0 +1,5 @@
+usr/include/selinux/*.h
+usr/lib/*/*.a
+usr/lib/*/*.so
+usr/lib/*/pkgconfig/*.pc
+usr/share/man/man3/*.3
diff --minimal -Nru libselinux-3.1/debian/libselinux1-dev.install 
libselinux-3.1/debian/libselinux1-dev.install
--- libselinux-3.1/debian/libselinux1-dev.install   2020-07-16 
18:28:55.0 +0200
+++ libselinux-3.1/debian/libselinux1-dev.install   1970-01-01 
01:00:00.0 +0100
@@ -1,5 +0,0 @@
-usr/include/selinux/*.h
-usr/lib/*/*.a
-usr/lib/*/*.so
-usr/lib/*/pkgconfig/*.pc
-usr/share/man/man3/*.3
diff --minimal -Nru libselinux-3.1/debian/libselinux1.symbols 
libselinux-3.1/debian/libselinux1.symbols
--- libselinux-3.1/debian/libselinux1.symbols   2020-07-16 18:28:55.0 
+0200
+++ libselinux-3.1/debian/libselinux1.symbols   2020-08-01 21:53:20.0 
+0200
@@ -1,5 +1,5 @@
 libselinux.so.1 libselinux1 #MINVER#
-* Build-Depends-Package: libselinux1-dev
+* Build-Depends-Package: libselinux-dev
  LIBSELINUX_1.0@LIBSELINUX_1.0 3.1~
  avc_add_callback@LIBSELINUX_1.0 3.1~
  avc_audit@LIBSELINUX_1.0 3.1~
diff --minimal -Nru libselinux-3.1/debian/tests/control 
libselinux-3.1/debian/tests/control
--- libselinux-3.1/debian/tests/control 2020-07-16 18:28:55.0 +0200
+++ libselinux-3.1/debian/tests/control 2020-08-01 21:53:44.0 +0200
@@ -1,5 +1,5 @@
 Tests: build
-Depends: build-essential, libselinux1-dev, pkg-config
+Depends: build-essential, libselinux-dev, pkg-config
 Restrictions: allow-stderr, superficial
 
 Test-Command: set -e ; for py in $(py3versions -r 2>/dev/null) ; do cd 
"$AUTOPKGTEST_TMP" ; echo "Testing with $py:" ; $py -c "import selinux; 
print(selinux)" ; done

Bug#966684: vfu FTCBFS again: uses the build architecture compiler

[Helmut Grohne]

Source: vfu
Version: 4.20-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

vfu fails to cross build from source again. Nothing ever initializes CXX
to a cross compiler. Please consider applying the attached patch to do
so.

Helmut
diff --minimal -Nru vfu-4.20/debian/changelog vfu-4.20/debian/changelog
--- vfu-4.20/debian/changelog   2020-07-29 03:46:19.0 +0200
+++ vfu-4.20/debian/changelog   2020-08-01 17:15:37.0 +0200
@@ -1,3 +1,10 @@
+vfu (4.20-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Let dpkg's buildtools.mk supply cross tools. (Closes: #-1)
+
+ -- Helmut Grohne   Sat, 01 Aug 2020 17:15:37 +0200
+
 vfu (4.20-1) unstable; urgency=medium
 
   * Update to new upstream release of 4.20.
diff --minimal -Nru vfu-4.20/debian/rules vfu-4.20/debian/rules
--- vfu-4.20/debian/rules   2020-07-25 20:34:10.0 +0200
+++ vfu-4.20/debian/rules   2020-08-01 17:13:22.0 +0200
@@ -1,6 +1,7 @@
 #!/usr/bin/make -f
 
 export DEB_BUILD_MAINT_OPTIONS+=hardening=+bindnow
+-include /usr/share/dpkg/buildtools.mk
 export CCDEF=$(shell dpkg-buildflags --get CFLAGS) $(shell dpkg-buildflags 
--get CPPFLAGS)
 export LDDEF=$(shell dpkg-buildflags --get LDFLAGS)
 RANLIB?=gcc-ranlib

Bug#966689: debhelper: --reload-all-buildenv-variables does not seem to work correctly

[Guillem Jover]

Package: debhelper
Version: 13.2
Severity: normal

Hi!

On Fri, 2020-07-31 at 08:44:56 +0200, Harald Welte wrote:
> I've been unsuccessful in having different 'hardening' settings for different
> parts of the build process of one package.  In this specific example,
> part of the build is Linux host programs, where "hardening=+all" should be
> enabled.  The other part of the same package build is cross-compiling USB 
> device
> firmware using gcc-arm-none-eabi.  As the target does not support stack 
> smashing
> protection, I need to specify hardening=-stackprotector

> The specific package in question can be found at
> https://build.opensuse.org/package/show/network:osmocom:nightly/simtrace2
> a build log showing the problem when hardening=+all is enabled for the full 
> project:
> https://build.opensuse.org/build/network:osmocom:nightly/xUbuntu_20.04/x86_64/simtrace2/_log

(I could not access this, it seems to require login.)

> I've so far tried:
> * introducing override_dh_autobuild which depends on different Makefile 
> targets
> * use target-specific 'export' statements
> * pass DEB_BUILD_MAINT_OPTIONS as make variable to explicit 'make fw' and 
> 'make utils'
> * some other variations of the above

If you are using the dh sequencer, then the build flags (CFLAGS, etc.
which are influenced by DEB_BUILD_MAINT_OPTIONS) are set by dh itself
(via the Dpkg::BuildFlags perl module) and by the various dh_auto_*
tools, any other command will inherit the flags from the environment.

Having checked the debhelper code now, it seems that you'd be supposed
to pass --reload-all-buildenv-variables to dh_auto_build (f.ex.), but
that seems buggy as set_buildflags() will also not reset flag variables
if they already exist in the environment, which is going to be the case
here as dh has already set them up.

> How to best solve this?

I think this needs to be fixed in debhelper. :)

Thanks,
Guillem

Bug#957910: vifm: ftbfs with GCC-10

[Reiner Herrmann]

Control: tags -1 + fixed-upstream

Hi,

this issue has been fixed in upstream commit:
  https://github.com/vifm/vifm/commit/0205c8d76bd33228b33bcceb6afffa2a77925c76

Regards,
  Reiner


signature.asc
Description: PGP signature

Bug#966674: dh-make-golang: go test TestSnapshotVersion always fails on reproducible builds2

[Roger Shimizu]

Package: dh-make-golang
Version: 0.3.3-1
Severity: normal

Dear Maintainer,

go test TestSnapshotVersion always fails on reproducible builds2.
(although 1st build, rbuild, always passes)

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/dh-make-golang.html

error log (build2):
=== RUN   TestSnapshotVersion
TestSnapshotVersion: version_test.go:51: got "0.0~git20150419.7a77fff", 
want "0.0~git20150420."
2020/07/25 23:00:42 Found latest tag "v1"
2020/07/25 23:00:42 WARNING: Latest tag "v1" is not a valid SemVer version
2020/07/25 23:00:42 Latest tag "v1" matches master
2020/07/25 23:00:42 Found latest tag "v1"
2020/07/25 23:00:42 WARNING: Latest tag "v1" is not a valid SemVer version
2020/07/25 23:00:42 INFO: master is ahead of "v1" by 1 commits
TestSnapshotVersion: version_test.go:81: got "1", want "1+git20150507.1."
2020/07/25 23:00:42 Found latest tag "v1"
2020/07/25 23:00:42 WARNING: Latest tag "v1" is not a valid SemVer version
2020/07/25 23:00:42 INFO: master is ahead of "v1" by 2 commits
TestSnapshotVersion: version_test.go:101: got "1", want "1+git20150508.2."
--- FAIL: TestSnapshotVersion (0.07s)


rbuild log (1st build) of same version:
=== RUN   TestSnapshotVersion
2021/08/28 05:22:38 Found latest tag "v1"
2021/08/28 05:22:38 WARNING: Latest tag "v1" is not a valid SemVer version
2021/08/28 05:22:38 Latest tag "v1" matches master
2021/08/28 05:22:38 Found latest tag "v1"
2021/08/28 05:22:38 WARNING: Latest tag "v1" is not a valid SemVer version
2021/08/28 05:22:38 INFO: master is ahead of "v1" by 1 commits
TestSnapshotVersion: version_test.go:81: got "1", want "1+git20150507.1."
2021/08/28 05:22:38 Found latest tag "v1"
2021/08/28 05:22:38 WARNING: Latest tag "v1" is not a valid SemVer version
2021/08/28 05:22:38 INFO: master is ahead of "v1" by 2 commits
TestSnapshotVersion: version_test.go:101: got "1", want "1+git20150508.2."
--- PASS: TestSnapshotVersion (0.06s)

Bug#966677: ITP: libmobi -- C library for handling Mobipocket/Kindle ebook format documents

[Bartek Fabiszewski]

Package: wnpp
Severity: wishlist
Owner: Bartek Fabiszewski 

* Package name: libmobi
  Version : 0.6
  Upstream Author : Bartek Fabiszewski 
* URL : https://github.com/bfabiszewski/libmobi
* License : LGPL
  Programming Lang: C
  Description : C library for handling Mobipocket/Kindle ebook format 
document

The library handles .prc, .mobi, .azw; .azw3, .azw4, some .pdb documents.
It allows one to read and parse documents, recreate source files of ebook
documents and dictionaries. It is also possible to edit document's metadata.
It handles encrypted files.
The package also contains tools:
- mobitool allows one to extract resources, decompile, analyze and convert
 documents;
- mobimeta allows one to edit document's metadata.

I am the author of the library. I've prepared debian packages for the
library and its tools.
I don't know any other libraries providing this functionality.
I plan to maintain the package myself.
I will need help from a sponsor.

Bug#966504: emacs-ivy: should suggest not recommend elpa-smex

[Nicholas D Steeves]

Control: severity -1 minor

Hi Sean!

Sean Whitton  writes:

> Package: emacs-ivy
> Version: 0.13.0-1
>
> Hello,
>
> On Fri 24 Jul 2020 at 11:49PM GMT, Debian FTP Masters wrote:
>
>> Changes:
>>  emacs-ivy (0.13.0-1) unstable; urgency=medium
>>  .
>>[...]
>>* Add elpa-smex to elpa-counsel's Recommends.  The way it presents one's
>>  recently and most frequently used commands at the top of the
>>  candidates list is a wonderful productivity-enhancing feature.  See
>>  the docs to learn how to use Counsel to enable this for the M-x
>>  interface.
>
> Based on your description here, should probably be Suggests: not
> Recommends:, given that Recommends: is for packages where it would be
> highly unusual not to use ivy with them.

Please note that changelog entry says "Add…to elpa-counsel's
Recommends".  Strictly speaking I upgraded it from an Enhances to a
Recommends.  I agree that it would be an incorrect interpretation of
Policy to add it to elpa-ivy's Recommends.

Elpa-counsel is an "everything and the kitchen sink" type package; it
exists specifically to add a bundle of productivity-enhancing
functionality to Ivy, and it's unlikely that any one user would use more
than ~30% of it.  By far, Counsel's most useful feature is its
Smex-to-Ivy integration via counsel-M-x, and Smex is automatically
enabled for counsel-M-x when it is found.  Without it, counsel-M-x
offers negligible advantages to the built-in `execute-extended-command`.
Counsel-M-x is also the only function that is useful to the majority of
Counsel users; however, the user must opt-in by rebinding "M-x" to
`counsel-M-x`.  This fact is documented upstream and in Debian-provided
docs.

See also how few users install Counsel vs Ivy:
  https://qa.debian.org/popcon.php?package=emacs-ivy

While I agree that dependency bloat should be avoided, I do not believe
that this is an example of such bloat, and I'm sad that by now you don't
trust me to make carefully reasoned decisions.  Given that Policy states
"should" and not "must", I am asserting my prerogative as maintainer of
the package: that this Recommends is justified and Policy-compliant, and
that this action benefits the majority of Counsel users.  Users who
detest Smex can uninstall it and 'apt-mark hold smex'; meanwhile, the
vast majority of Ivy users do not install Counsel.  My deduction, hope,
and belief is that users who rebind "M-x" will be pleasantly surprised,
will tell their friends/colleagues about it, and that this will manifest
in the popcon stats in the same way that that most of my
user-friendliness, discoverability, and documentation enhancements seem
to have correlated to an increased rate of growth in other packages.

On a related topic, do you think that users would be better served by
documenting this feature in elpa-counsel's long description, or by
leaving it as something to be discovered in /usr/share/docs?  I confess
that I'm biased towards the latter, because my experience was "wow, it's
like it read my mind!  ".  It's an interesting question, you
know?  eg: Is perfect documentation 100% comprehensive, or should it
leave room for the joy of discovery?  P.S. Thank you for maintaining
Smex; it has become one of my favourite elpa-packages.  That said, the
only reason I learned of it was because I read an Ivy-related thread
somewhere (along the lines of "getting the full abo-abo experience").
Frankly, I'm shocked that it's not more well known, and believe that
part of the value that Debian provides (vs MELPA) is the following
function: we can boost the visibility of genuinely novel and useful
packages that have not yet gained a foothold in the general
consciousness, thus encouraging upstream development and fostering
motivation in the more general FLOSS community.

Cheers,
Nicholas


signature.asc
Description: PGP signature

Bug#957188: patch to fix linking with gcc-10

[arnold metselaar]

Dear maintainer,

Attached is a patch to make gimp-lqr-plugin and wavelet-denoise-0.3.1 link
properly with gcc-10.

suggested changelog entry

lqr/gimp-lqr-plugin/src/interface_aux.c,
lqr/gimp-lqr-plugin/src/interface_I.c: declare variables as extern that
would otherwise clash with those in lqr/gimp-lqr-plugin/src/interface.c

wavelet-denoise/wavelet-denoise-0.3.1/src/interface.h,
wavelet-denoise/wavelet-denoise-0.3.1/src/plugin.h: declare global
variables as extern
wavelet-denoise/wavelet-denoise-0.3.1/src/interface.c,
wavelet-denoise/wavelet-denoise-0.3.1/src/plugin.c: add some global
variables now declared extern in the corresponding header files

Kind regards,
Arnold Metselaar
diff --git a/lqr/gimp-lqr-plugin/src/interface_I.c b/lqr/gimp-lqr-plugin/src/interface_I.c
index 2719167..dbe2717 100644
--- a/lqr/gimp-lqr-plugin/src/interface_I.c
+++ b/lqr/gimp-lqr-plugin/src/interface_I.c
@@ -73,10 +73,10 @@ static void callback_alarm_triggered (GtkWidget * size_entry, gpointer data);
 
 gint dialog_I_response = GTK_RESPONSE_OK;
 
-PlugInUIVals *ui_state;
-PlugInVals *state;
-PlugInDialogVals *dialog_state;
-gboolean features_are_sensitive;
+extern PlugInUIVals *ui_state;
+extern PlugInVals *state;
+extern PlugInDialogVals *dialog_state;
+extern gboolean features_are_sensitive;
 InterfaceIData interface_I_data;
 //volatile sig_atomic_t interface_locked = 0;
 
diff --git a/lqr/gimp-lqr-plugin/src/interface_aux.c b/lqr/gimp-lqr-plugin/src/interface_aux.c
index 6461757..ceed0d9 100644
--- a/lqr/gimp-lqr-plugin/src/interface_aux.c
+++ b/lqr/gimp-lqr-plugin/src/interface_aux.c
@@ -49,11 +49,11 @@ static void callback_dialog_aux_response (GtkWidget * dialog, gint response_id,
 
 gint dialog_aux_response = GTK_RESPONSE_OK;
 
-PlugInUIVals *ui_state;
-PlugInVals *state;
-PlugInDialogVals *dialog_state;
+extern PlugInUIVals *ui_state;
+extern PlugInVals *state;
+extern PlugInDialogVals *dialog_state;
 
-GtkWidget *dlg;
+extern GtkWidget *dlg;
 
 /***  Public functions  ***/
 
diff --git a/wavelet-denoise/wavelet-denoise-0.3.1/src/interface.c b/wavelet-denoise/wavelet-denoise-0.3.1/src/interface.c
index 170894b..2f95572 100644
--- a/wavelet-denoise/wavelet-denoise-0.3.1/src/interface.c
+++ b/wavelet-denoise/wavelet-denoise-0.3.1/src/interface.c
@@ -16,8 +16,36 @@
 #include "plugin.h"
 #include "interface.h"
 
+/* Global variables declared in interface.h */
+/* colour mode frame */
+GtkWidget *fr_mode, *mode_radio[3], *mode_vbox;
+GSList *mode_list;
+
+/* preview select frame */
+GtkWidget *fr_preview, *preview_radio[3], *preview_vbox, *preview_check;
+GSList *preview_list;
+
+/* channel select frame */
+GtkWidget *fr_channel, *channel_radio[4], *channel_vbox;
+GSList *channel_list;
+
+/* threshold frame */
+GtkWidget *fr_threshold, *thr_label[2], *thr_spin[2];
+GtkWidget *thr_hbox[2], *thr_vbox, *thr_scale[2];
+GtkObject *thr_adj[2];
+
+/* reset buttons */
+GtkWidget *reset_button[2], *reset_hbox, *reset_align, *reset_button_icon[2];
+
+/* dialog */
+GtkWidget *dialog, *dialog_hbox, *dialog_vbox, *frame_hbox, *dialog_aspect;
+GtkWidget *preview, *preview_reset, *preview_hbox, *preview_reset_icon;
+
 GtkWidget **radios_labels[] = { channel_radio, thr_label };
 
+char **names;
+
+
 gboolean
 user_interface (GimpDrawable * drawable)
 {
diff --git a/wavelet-denoise/wavelet-denoise-0.3.1/src/interface.h b/wavelet-denoise/wavelet-denoise-0.3.1/src/interface.h
index f0ce8ad..0f5430e 100644
--- a/wavelet-denoise/wavelet-denoise-0.3.1/src/interface.h
+++ b/wavelet-denoise/wavelet-denoise-0.3.1/src/interface.h
@@ -14,29 +14,29 @@
  */
 
 /* colour mode frame */
-GtkWidget *fr_mode, *mode_radio[3], *mode_vbox;
-GSList *mode_list;
+extern GtkWidget *fr_mode, *mode_radio[3], *mode_vbox;
+extern GSList *mode_list;
 
 /* preview select frame */
-GtkWidget *fr_preview, *preview_radio[3], *preview_vbox, *preview_check;
-GSList *preview_list;
+extern GtkWidget *fr_preview, *preview_radio[3], *preview_vbox, *preview_check;
+extern GSList *preview_list;
 
 /* channel select frame */
-GtkWidget *fr_channel, *channel_radio[4], *channel_vbox;
-GSList *channel_list;
+extern GtkWidget *fr_channel, *channel_radio[4], *channel_vbox;
+extern GSList *channel_list;
 
 /* threshold frame */
-GtkWidget *fr_threshold, *thr_label[2], *thr_spin[2];
-GtkWidget *thr_hbox[2], *thr_vbox, *thr_scale[2];
-GtkObject *thr_adj[2];
+extern GtkWidget *fr_threshold, *thr_label[2], *thr_spin[2];
+extern GtkWidget *thr_hbox[2], *thr_vbox, *thr_scale[2];
+extern GtkObject *thr_adj[2];
 
 /* reset buttons */
-GtkWidget *reset_button[2], *reset_hbox, *reset_align, *reset_button_icon[2];
+extern GtkWidget *reset_button[2], *reset_hbox, *reset_align, *reset_button_icon[2];
 
 /* dialog */
-GtkWidget *dialog, *dialog_hbox, *dialog_vbox, *frame_hbox, *dialog_aspect;
-GtkWidget *preview, *preview_reset, *preview_hbox, *preview_reset_icon;
+extern GtkWidget *dialog, *dialog_hbox, *dialog_vbox, *frame_hbox, *dialog_aspect;
+extern GtkWidget *preview, *preview_reset, 

Bug#966675: virt-v2v missing from package

[Jim Paris]

Package: libguestfs-tools
Version: 1:1.42.0-6
Severity: normal

Hi,

/usr/bin/virt-v2v is present in libguestfs-tools 1:1.40.2-2 in buster:
  https://packages.debian.org/buster/amd64/libguestfs-tools/filelist

But it is missing from libguestfs-tools 1:1.42.0.6 in bullseye:
  https://packages.debian.org/bullseye/amd64/libguestfs-tools/filelist

I see nothing in the changelog; was it removed by accident?
virt-p2v was split out, but virt-v2v doesn't exist in that package either.

Jim

-- System Information:
Debian Release: 10.4
  APT prefers stable
  APT policy: (200, 'stable'), (80, 'testing'), (50, 'unstable'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.2.0-2-amd64 (SMP w/16 CPU cores)
Locale: LANG=POSIX, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en@quot:en@boldquot:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libguestfs-tools depends on:
ii  curl   7.64.0-4+deb10u1
ii  libc6  2.29-7
ii  libconfig9 1.5-0.4
ii  libcrypt1  1:4.4.10-10
ii  libfuse2   2.9.9-2
ii  libguestfs-perl1:1.42.0-6
ii  libguestfs01:1.42.0-6
ii  libintl-perl   1.26-2
ii  libjansson42.12-1
ii  liblzma5   5.2.4-1
ii  libpcre3   2:8.39-12
ii  libreadline8   8.0-3
ii  libstring-shellquote-perl  1.04-1
ii  libsys-virt-perl   6.3.0-1
ii  libtinfo6  6.1+20181013-2+deb10u2
ii  libvirt0   6.4.0-2
ii  libwin-hivex-perl  1.3.18-2+b3
ii  libxml22.9.4+dfsg1-7+b3

Versions of packages libguestfs-tools recommends:
ii  gnupg 2.2.19-1
ii  virt-p2v  1.42.0-2

libguestfs-tools suggests no packages.

-- no debconf information

Bug#879151: debian-ports support when setting up sources.list

[jhcha54008]

Hi,

Le jeudi 30 juillet à 13h 29mn 40s (+0200), наб a écrit :
> 
> On Thu, Jul 30, 2020 at 11:44:33AM +0200, jhcha54008 wrote:
> > -   log "Debian-Ports architecture detected"
> Why is this line removed from the log now?

Oops, you are right, this line should be kept !

> > +   is_ports_architecture=$(cat /usr/lib/choose-mirror/port_architecture)
> Is there any good reason for this to be a subshell instead of read(1)?

This syntax is in use elsewhere in the same file (line 48).
Yes, it may be tempting to spare one shell sublevel and write

read is_ports_architecture < /usr/lib/choose-mirror/port_architecture

Unfortunately, this fails with a return code of 1 : EOF is reached
before the end of the line (as there is no new line at the end of
the file). As a result, the whole script fails (because of option :
set -e)

> наб

Thank you for your help and your corrections to this patch
proposal !

Regards,
JH Chatenet

Bug#879151: debian-ports support when setting up sources.list

[John Paul Adrian Glaubitz]

Hi!

On 8/2/20 12:16 AM, jhcha54008 wrote:
>>> +   is_ports_architecture=$(cat /usr/lib/choose-mirror/port_architecture)
>> Is there any good reason for this to be a subshell instead of read(1)?
> 
> This syntax is in use elsewhere in the same file (line 48).
> Yes, it may be tempting to spare one shell sublevel and write
> 
> read is_ports_architecture < /usr/lib/choose-mirror/port_architecture

Btw, it should be "ports_architecture", not "port_architecture", as it's
"Debian Ports".

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#966690: afew: Package is outdated.

[debian]

Subject: afew: Package is outdated.
Package: afew
X-Debbugs-Cc: deb...@fritzreichwald.de
Version: 1.3.0-1
Severity: normal
Tags: patch

Dear Maintainer,

I just recognized that afew is outdated in debian.
So i prepared
https://salsa.debian.org/python-team/modules/afew/-/merge_requests/2 to
fix this.

Please contact me if there is something I should fix before you can
merge it.

Thanks!

Best regards Fritz (fiete in IRC)

Bug#966301: guile oom test fails on ppc64el

[Rob Browning]

Matthias Klose  writes:

> https://buildd.debian.org/status/fetch.php?pkg=guile-2.2=ppc64el=2.2.7%2B1-5.1=1595497537=0
>
> Apparently this is known, and already reported by Debian:
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=+29464
> but no update since 2017.
>
> For some reason the test succeeds on the Ubuntu buildds.

I believe we originally avoided this via 

  # https://debbugs.gnu.org/29464
  export DEB_CFLAGS_MAINT_APPEND += -fno-stack-protector

in debian/rules.  I wonder if that doesn't avoid the problem anymore, or
somehow the option's no longer making it all the way through.

Thanks
-- 
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

Bug#966692: stunnel4: FTBFS because of test hang

[Michał Mirosław]

Source: stunnel4
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: Michał Mirosław 

The bug #955710 turns out to be only partially fixed. Now without a binary
to exec the test runtime doesn't hang. When the binary is correct, though,
it still can't stop asking the pipe for more data after EOF.

$ dpkg-buildpackage -b
[...]
env TEST_STUNNEL=.../stunnel4-5.56+dfsg/src/stunnel debian/tests/runtime
Found the certificate at debian/tests/certs/certificate.pem and the private key 
at debian/tests/certs/key.pem
Using the /tmp/AgCSdk8YKw temporary directory
About to get the stunnel version information 
Got stunnel version 5.56 
^Cmake[1]: *** [debian/rules:32: execute_before_dh_auto_test] Interrupt
make: *** [debian/rules:106: binary] Error 1

From the manual run under strace:

$ TEST_STUNNEL=src/stunnel strace -f -o /tmp/log debian/tests/runtime

I can see (excerpt):

11715 read(5,  
11715 <... read resumed> "stunnel 5.56 on x86_64-pc-linux-"..., 8192) = 95
[more reads]
11715 read(5, "TIMEOUTbusy= 300 sec"..., 8192) = 178
11715 epoll_wait(3,  
11715 <... epoll_wait resumed> [{EPOLLHUP, {u32=5, u64=4294967301}}], 64, 
59743) = 1
11715 epoll_ctl(3, EPOLL_CTL_MOD, 5, {EPOLLIN, {u32=5, u64=4294967301}} 

[11716 +++ exited with 0 +++]
11715 <... epoll_ctl resumed> ) = 0
11715 --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=11716, 
si_uid=1000, si_status=0, si_utime=0, si_stime=0} ---
11715 write(4, "\1\0\0\0\0\0\0\0", 8)   = 8
11715 rt_sigreturn({mask=[]})   = 0
11715 epoll_wait(3, [{EPOLLHUP, {u32=5, u64=4294967301}}, {EPOLLIN, {u32=4, 
u64=4294967300}}], 64, 59743) = 2
11715 epoll_ctl(3, EPOLL_CTL_MOD, 5, {EPOLLIN, {u32=5, u64=4294967301}}) = 0
11715 read(4, "\1\0\0\0\0\0\0\0", 8)= 8
11715 wait4(-1, [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], 
WNOHANG|WSTOPPED|WCONTINUED, NULL) = 11716
11715 wait4(-1, 0x7ffc665c7904, WNOHANG|WSTOPPED|WCONTINUED, NULL) = -1 ECHILD 
(No child processes)
11715 wait4(-1, 0x7ffc665c76b4, WNOHANG, NULL) = -1 ECHILD (No child processes)
11715 epoll_wait(3, [{EPOLLHUP, {u32=5, u64=4294967301}}], 64, 59743) = 1
11715 epoll_ctl(3, EPOLL_CTL_MOD, 5, {EPOLLIN, {u32=5, u64=4294967301}}) = 0
11715 epoll_wait(3, [{EPOLLHUP, {u32=5, u64=4294967301}}], 64, 59743) = 1
11715 epoll_ctl(3, EPOLL_CTL_MOD, 5, {EPOLLIN, {u32=5, u64=4294967301}}) = 0
11715 epoll_wait(3, [{EPOLLHUP, {u32=5, u64=4294967301}}], 64, 59743) = 1
11715 epoll_ctl(3, EPOLL_CTL_MOD, 5, {EPOLLIN, {u32=5, u64=4294967301}}) = 0
11715 read(5, "", 8192) = 0
11715 write(1, "Got stunnel version 5.56\n", 25) = 25
11715 epoll_wait(3, [{EPOLLHUP, {u32=5, u64=4294967301}}], 64, 59743) = 1
11715 epoll_ctl(3, EPOLL_CTL_MOD, 5, {EPOLLIN, {u32=5, u64=4294967301}}) = 0
11715 read(5, "", 8192) = 0
[last 3 lines repeated forever]

-- System Information:
Debian Release: 10.5
  APT prefers stable-debug
  APT policy: (900, 'stable-debug'), (900, 'proposed-updates'), (900, 
'stable'), (800, 'testing'), (700, 'unstable'), (600, 'experimental'), (540, 
'oldstable'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 
'proposed-updates-debug'), (1, 'experimental-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.7.10mq+ (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=pl_PL.UTF-8, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

-- no debconf information


test-runtime.strace.log.gz
Description: application/gzip

Bug#966544: snmpd: extend option broken after update

[James Greig]

Hi,

Well, hopefully LTS can fix this for those of us that are using oldstable 
(stretch).  It almost seems like someone broke production on the oldstable 
version, then said, "don't worry - we've fixed it on unstable" (a version no 
one is using in production), then walked away :) 

Current work around is to either apt-mark snmpd before you upgrade if you 
haven't already broken it OR to run something like apt install 
snmpd=5.7.3+dfsg-1.7+deb9u1 libsnmp30=5.7.3+dfsg-1.7+deb9u1 to force the 
downgrade.

Kind regards

James Greig

Bug#966678: security.debian.org: invalid save permissions

[Sean]

Package: security.debian.org
Severity: normal

Dear Maintainer,


   * What led up to the situation? i was trying to save a file into to a system
directory by using browser option available when right-clicking 'Raw' on a
Github page called 'save link as'. The desired directory was ect/udev/rules.d/.
   * What exactly did you do (or not do) that was effective (or
 ineffective)? i tried to save and wasn't allowed by a popup wich was
titled 'invalid save permissions'.
   * What was the outcome of this action? the popup forced me to sake OK. So
ended my attempt to do this a step included in setting up YubiKey
authenticator.
   * What outcome did you expect instead? To save the file in the directory
since I am the root user! I also have this issue in terminal, when i put in a
command that can't run without a password, it tells me im not a root user or
something. There is only one user choice set up on the PC.




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

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

Bug#966680: src:acpica-unix: fails to migrate to testing for too long: FTBFS on s390x

[Paul Gevers]

Source: acpica-unix
Version: 20190509-1
Severity: serious
Control: close -1 20200528-1
Tags: sid bullseye
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

As recently announced [1], the Release Team now considers packages that
are out-of-sync between testing and unstable for more than 60 days as
having a Release Critical bug in testing. Your package src:acpica-unix
in its current version in unstable has been trying to migrate for 60
days [2]. Hence, I am filing this bug.

If a package is out of sync between unstable and testing for a longer
period, this usually means that bugs in the package in testing cannot be
fixed via unstable. Additionally, blocked packages can have impact on
other packages, which makes preparing for the release more difficult.
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that
hamper the migration of their package in a timely manner.

This bug will trigger auto-removal when appropriate. As with all new
bugs, there will be at least 30 days before the package is auto-removed.

I have immediately closed this bug with the version in unstable, so if
that version or a later version migrates, this bug will no longer affect
testing. I have also tagged this bug to only affect sid and bullseye, so
it doesn't affect (old-)stable.

If you believe your package is unable to migrate to testing due to
issues beyond your control, don't hesitate to contact the Release Team.

Paul

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




signature.asc
Description: OpenPGP digital signature

Bug#964105: RFH: album-data -- themes, plugins and translations for album

[Sudip Mukherjee]

On Wed, Jul 01, 2020 at 12:22:59PM -0700, David Ljung Madison wrote:
> Package: wnpp
> Severity: important
> 
> The package 'album-data' is a data package for 'album'
> 
> I am the author of album and album-data.
> 
> It has an incorrect dependency on "libjs-swfobject" which I recently
> noticed because, since libjs-swfobject has been removed, has caused
> album-data to also be removed.
> 
> album-data does not depend on libjs-swfobject.

fyi, I have done a NMU and removed this dependency.

--
Regards
Sudip

Bug#966673: fusiondirectory: no base-dn, no connect

[K Martinen]

Source: fusiondirectory
Severity: important

Dear Maintainer,

What i tried to make it work:

- setup.php started from remote PC with firefox (ublock, PrivacyBadger Off).
- states php-mbstring missing.
- installed php-mbstring. reload, no success.
- rebootet and tried again, no success.
- manually activated php-mbstring. success.
- base-dn field is not valid (greyed out) not selectable.
- No connection to ldap-server (on local host).
- no progress possible. Giving up.


-- System Information:
Debian Release: 9.13
  APT prefers oldstable-updates
  APT policy: (500, 'oldstable-updates'), (500, 'oldstable')
Architecture: i386 (i686)

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

Bug#966688: xxdiff: A source-only upload is needed for testing migration

[Boyuan Yang]

Source: xxdiff
Version: 1:4.0.1+hg487+dfsg-1
Tags: sid
Severity: important

Dear Debian xxdiff maintainers,

As seen in Britney testing migration excuses [1], this package needs another
source-only upload to be able to migrate to Testing. Please consider making
another upload.

Besides, it seems that the python team has shifted its plan and allow packages
that depends on python2 to stay in Debian 11 but any package that (build-
)depends on /usr/bin/python will have to be eliminated or migrated to use
/usr/bin/python2. I believe it is worthwhile to provide a patch to avoid the
usage of /usr/bin/python in xxdiff-scripts.

-- 
Regards,
Boyuan Yang

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


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

Bug#966691: emacs-gtk: Segmentation fault with libx11-6 v. 2:1.6.10-1

[Domenico Cufalo]

Package: emacs-gtk
Version: 1:26.3+1-2
Severity: grave
Justification: renders package unusable

Dear Maintainer,

   * What led up to the situation?

Upgrade to v. 2:1.6.10-1 of libx11-6 (and related packages)

   * What was the outcome of this action?

Segmentation fault of emacs-gtk:

[1] 3915
Fatal error 11: Segmentation fault
Backtrace:
emacs-gtk[0x5111be]
emacs-gtk[0x4f6ead]
emacs-gtk[0x50f63e]
emacs-gtk[0x50f86d]
emacs-gtk[0x50f8e9]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x14140)[0x7f3e63809140]
emacs-gtk[0x4d94b0]
emacs-gtk[0x4d9897]
emacs-gtk[0x4da4df]
emacs-gtk[0x56dc2c]
emacs-gtk[0x5a74c0]
emacs-gtk[0x56dbab]
emacs-gtk[0x5a74c0]
emacs-gtk[0x56dbab]
emacs-gtk[0x56f90b]
emacs-gtk[0x56dc2c]
emacs-gtk[0x5a74c0]
emacs-gtk[0x56dbab]
emacs-gtk[0x5a74c0]
emacs-gtk[0x56dbab]
emacs-gtk[0x5a74c0]
emacs-gtk[0x56dbab]
emacs-gtk[0x5a74c0]
emacs-gtk[0x56dbab]
emacs-gtk[0x5a74c0]
emacs-gtk[0x570726]
emacs-gtk[0x56fcc6]
emacs-gtk[0x571c1c]
emacs-gtk[0x56cd7e]
emacs-gtk[0x4f8470]
emacs-gtk[0x56cced]
emacs-gtk[0x4f71f8]
emacs-gtk[0x4fc2b3]
emacs-gtk[0x4fc5f8]
emacs-gtk[0x41a5c2]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xea)[0x7f3e63529cca]
emacs-gtk[0x41b29a]
[1]+  Doneexport LANG=C
Segmentation fault

Reverting libx11-6, libx11-data and libx11-xcb1 to previous version
(2:1.6.9-2+b1) solves the issue.

Best regards and thank you so much,

Domenico



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

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

Versions of packages emacs-gtk depends on:
ii  emacs-bin-common   1:26.3+1-2
ii  emacs-common   1:26.3+1-2
ii  libacl12.2.53-8
ii  libasound2 1.2.2-2.3
ii  libc6  2.31-2
ii  libcairo2  1.16.0-4
ii  libdbus-1-31.12.20-1
ii  libfontconfig1 2.13.1-4.2
ii  libfreetype6   2.10.2+dfsg-3
ii  libgdk-pixbuf2.0-0 2.40.0+dfsg-5
ii  libgif75.1.9-1
ii  libglib2.0-0   2.64.4-1
ii  libgnutls303.6.14-2+b1
ii  libgpm21.20.7-6
ii  libgtk-3-0 3.24.20-1
ii  libice62:1.0.9-2
ii  libjpeg62-turbo1:2.0.5-1
ii  liblcms2-2 2.9-4+b1
ii  libm17n-0  1.8.0-2
ii  libmagickcore-6.q16-6  8:6.9.11.24+dfsg-1
ii  libmagickwand-6.q16-6  8:6.9.11.24+dfsg-1
ii  libotf00.9.13-7
ii  libpango-1.0-0 1.44.7-4
ii  libpng16-161.6.37-2
ii  librsvg2-2 2.48.7-1
ii  libselinux13.1-2
ii  libsm6 2:1.2.3-1
ii  libsystemd0245.7-1
ii  libtiff5   4.1.0+git191117-2
ii  libtinfo6  6.2-1
ii  libx11-6   2:1.6.10-1
ii  libxext6   2:1.3.3-1+b2
ii  libxfixes3 1:5.0.3-2
ii  libxft22.3.2-2
ii  libxml22.9.10+dfsg-5+b1
ii  libxpm41:3.5.12-1
ii  libxrender11:0.9.10-1
ii  zlib1g 1:1.2.11.dfsg-2

emacs-gtk recommends no packages.

Versions of packages emacs-gtk suggests:
pn  emacs-common-non-dfsg  

-- no debconf information

Bug#957896: uget: ftbfs with GCC-10

[Reiner Herrmann]

Control: tags -1 + fixed-upstream

Hi,

this issue has been fixed in upstream commit:
  
https://sourceforge.net/p/urlget/uget2/ci/14890943c52e0a5cd2a87d8a1c51cbffebee7cf9/

Regards,
  Reiner


signature.asc
Description: PGP signature

Bug#963475: Could not parse device path: Invalid argument

[Michel Le Bihan]

Hello,

I tested Fedora Workstation Live 32 on another machine and there also
`efibootmgr -v` worked correctly while on Debian testing it produced
the error.

Michel Le Bihan

Bug#966693: RFP: veloren -- multiplayer voxel RPG

[Francisco Vilmar Cardoso Ruviaro]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: francisco.ruvi...@riseup.net

* Package name: veloren
  Version : 0.6.0
  Upstream Author : Project Veloren
* URL : https://gitlab.com/veloren/veloren
* License : GPL-3+
  Programming Lang: Rust
  Description : multiplayer voxel RPG

Veloren is a multiplayer voxel RPG written in Rust. It is inspired by games such
as Cube World, Legend of Zelda: Breath of the Wild, Dwarf Fortress and 
Minecraft.

Bug#965018: RFS: freetype-py/2.2.0-1 -- Freetype Python bindings for Python 3

[Bastian Germann]

On Wed, 29 Jul 2020 17:45:32 +0200 mat...@debian.org wrote:
> That's the `clean` step that is failing, which is done outside of the
> chroot.  That's responsability of whoever is calling `pdebuild` to
> satisfy.
> 
> If you are sure your source is clean you may as well just skip cleaning
> and not use pdebuild:
> dpkg-source -b .
> dpkg-source --after-build .
> pbuilder b ../freetype-py_2.2.0-1.dsc
> the above sequence should prove that nothing is at fault here.

The package builds fine with the given steps.

Bug#966655: orthanc: using tzdata but missing dependency on it?

[Gianfranco Costamagna]

Source: orthanc
Version: 1.7.2+dfsg-1
Severity: serious
tags: patch

Hello, looks like orthanc fails to build from source (testsuite error) when 
tzdata is not installed in the chroot.

I'm not sure if this is an essential package or not, but looks like it can be 
removed, or not be available on some chroots


this is an example of failure

mkdir -p /<>/debian/tmp/locale/
localedef -f UTF-8 -i en_US /<>/debian/tmp/locale/en_US.UTF-8/
( cd Build; LOCPATH=/<>/debian/tmp/locale/ ./UnitTests )
E0731 17:53:29.829350 OrthancException.h:76] Internal error: On UNIX-like 
systems, the file /etc/localtime must be present on the filesystem (install 
"tzdata" package on Debian)
terminate called after throwing an instance of 'Orthanc::OrthancException'
Aborted (core dumped)
make[1]: *** [debian/rules:73: override_dh_auto_test] Error 134


I think adding it as explicit dependency might solve some headaches.

G.

Bug#966575: grub-pc: error: symbol `grub_calloc' not found.

[cacatoes]

Hello,

My case was indeed a disk switch from USB to internal.

I probably had invoked directly grub-install (dunno if it'd make sense
to warn about the mismatch with debconf there?), now I know I should
rather use dpkg-reconfigure instead.

# debconf-get-selections |grep 'grub-pc/install_devices'
grub-pc grub-pc/install_devices_disks_changed   multiselect
/dev/disk/by-id/usb-KINGSTON_SA400S37240G_AB12362D-0:0
grub-pc grub-pc/install_devices_failed_upgrade  boolean true
grub-pc grub-pc/install_devices_failed  boolean false
grub-pc grub-pc/install_devices_empty   boolean false
grub-pc grub-pc/install_devices multiselect
/dev/disk/by-id/usb-KINGSTON_SA400S37240G_AB12362D-0:0

# ls /dev/disk/by-id/usb-KINGSTON_SA400S37240G_AB12362D-0:0
ls: impossible d'accéder à
'/dev/disk/by-id/usb-KINGSTON_SA400S37240G_AB12362D-0:0': Aucun
fichier ou dossier de ce type

# ls /dev/disk/by-id/ata-KINGSTON_SA400S37240G_50026B7683315755 
/dev/disk/by-id/ata-KINGSTON_SA400S37240G_50026B7683315755@

# dpkg-reconfigure grub-pc

# debconf-get-selections |grep 'grub-pc/install_devices'
grub-pc grub-pc/install_devices_failed  boolean false
grub-pc grub-pc/install_devices multiselect
/dev/disk/by-id/ata-KINGSTON_SA400S37240G_50026B7683315755
grub-pc grub-pc/install_devices_disks_changed   multiselect
/dev/disk/by-id/ata-KINGSTON_SA400S37240G_50026B7683315755
grub-pc grub-pc/install_devices_empty   boolean false
grub-pc grub-pc/install_devices_failed_upgrade  boolean true

Thanks for the explanations!

Bug#966649: UDD: 'upload_history' importer broken; needs porting to Python3

[Lucas Nussbaum]

Package: qa.debian.org
User: qa.debian@packages.debian.org
Usertags: udd

Hi,

The upload_history importer works as follows:

1) /srv/udd.debian.org/email-archives/debian-devel-changes/ contains a copy
of the email archives, copied manually from master.debian.org. The
latest emails are received directly on ullmann, to 
/srv/udd.debian.org/email-archives/debian-devel-changes/debian-devel-changes.current
This part is about OK. It would be better if DSA provided a way to
access those archives from ullmann without having to copy them from time
to time.

2) When started, the importer first runs 'make' in 
/srv/udd.debian.org/upload-history/. This:
2.1) updates local copies of keyrings
2.2) using 'munge_ddc.py', converts email archives into summarized versions, 
stored as, e.g.:
/srv/udd.debian.org/upload-history/debian-devel-changes.201209.gz.out

3) then the importer reads *.out and import them into postgres.

'munge_ddc.py' has the following issues:
- it's not version-controlled
- it doesn't support xz email archives, so it's broken for recent
  archives
- it's python2 (but the lzma module is python3-only)

Help would be welcomed to port it to python3 and resolve the other
issues. Also, the data files around the upload_history gatherer should
probably be reorganized with a cleaner separation between code (that
should be versioned in UDD) and data.

Lucas

Bug#966650: agda-stdlib misses all those .agdai files

[Helmut Grohne]

Package: agda-stdlib
Version: 1.3-1
Severity: important

The latest agda-stdlib update misses out all those *.agdai compiled
files. 1.1-1 still contained them. When you type check agda files as a
regular user, you are now faced with this:

| Checking Function.Core (/usr/share/agda-stdlib/Function/Core.agda).
| Failed to write interface /usr/share/agda-stdlib/Function/Core.agdai.
| /usr/share/agda-stdlib/Function.agda:11,1-33
| /usr/share/agda-stdlib/Function/Core.agdai: openBinaryFile:
| permission denied (Permission denied)

Very similar to Python byte compilation, agda tries to compile the
system files and gives up as it cannot write the compiled interface
files. I'm unsure why they went missing as they are generated during
build (as can be seen in the build log).

Helmut

Bug#966651: libgc-dev: missing dependency on libatomic-ops-dev

[Helmut Grohne]

Package: libgc-dev
Version: 1:8.0.4-1
Severity: serious
Justification: undeclared dependency
Tags: patch

bdw-gc.pc includes -latomic_ops on some architectures. However, the
binary package misses the required dependency on libatomic-ops-dev to
allow for such a use. I'm attaching a patch for your convenience.

Helmut
diff --minimal -Nru libgc-8.0.4/debian/changelog libgc-8.0.4/debian/changelog
--- libgc-8.0.4/debian/changelog2020-07-22 02:37:12.0 +0200
+++ libgc-8.0.4/debian/changelog2020-07-31 22:02:10.0 +0200
@@ -1,3 +1,10 @@
+libgc (1:8.0.4-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix missing libgc-dev -> libatomic-ops-dev dependency. (Closes: #-1)
+
+ -- Helmut Grohne   Fri, 31 Jul 2020 22:02:10 +0200
+
 libgc (1:8.0.4-1) unstable; urgency=medium
 
   * Team upload.
diff --minimal -Nru libgc-8.0.4/debian/control libgc-8.0.4/debian/control
--- libgc-8.0.4/debian/control  2020-04-07 11:13:30.0 +0200
+++ libgc-8.0.4/debian/control  2020-07-31 21:59:44.0 +0200
@@ -35,7 +35,7 @@
 Package: libgc-dev
 Architecture: any
 Section: libdevel
-Depends: ${misc:Depends}, libgc1 (= ${binary:Version}), libc-dev
+Depends: ${misc:Depends}, libgc1 (= ${binary:Version}), libc-dev, 
${atomic:Depends}
 Multi-Arch: same
 Description: conservative garbage collector for C (development)
  Boehm-Demers-Weiser's GC is a garbage collecting storage allocator that is
diff --minimal -Nru libgc-8.0.4/debian/rules libgc-8.0.4/debian/rules
--- libgc-8.0.4/debian/rules2020-04-07 11:03:33.0 +0200
+++ libgc-8.0.4/debian/rules2020-07-31 22:02:10.0 +0200
@@ -45,3 +45,6 @@
 
 override_dh_installchangelogs:
dh_installchangelogs ChangeLog
+
+override_dh_gencontrol:
+   dh_gencontrol -- -Vatomic:Depends=$$(grep -q '[-]latomic_ops' 
debian/libgc-dev/usr/lib/*/pkgconfig/*.pc && echo libatomic-ops-dev)

Bug#964312: Update

[joerg]

Hello 


I applied the patch provided on
http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=ba3e771a42c29ee02c34e7769cfc1b2dbc5c760a


This patch fixes the issue for me. 

Best Regards 


 Joerg

Bug#966011: gajim crashes at startup since v1.2

[Petr Gajdůšek]

Hello,

According to https://dev.gajim.org/gajim/gajim/-/issues/10069 there is
a table 'caps_cache' in sqlite DB ~/.local/share/gajim/logs.db that
shouldn't be there (it's supposed to be only in
~/.cache/gajim/cache.db).

Running 

sqlite3 ~/.local/share/gajim/logs.db "DROP TABLE caps_cache"

did help.

Cheers,
Petr

Bug#959071: Acknowledgement (xserver-xephyr: Xephyr and Xnest: AltGr combined keystrokes do not work while using German keyboard layout)

[Adrian Immanuel Kieß]

Dear Maintainer,

my reported bug is fixable running Xephyr like this:

$ Xephyr -xkb-model de

or issuing 

$ setxkbmap de

after logging in to the remote machine via XDM in a shell inside X
windows.

Thank you very much.

Sincereley,

Adrian Kieß


-- 
With many greetings from Leipzig, Germany.
Adrian Immanuel Kieß 

Gothaer Straße 34
D-04155 Leipzig

 — < adr...@kiess.onl >

--SYSTEM--
echo "Your fortune cookie: " && /usr/games/fortune -c -s de
> (zitate) % Wir mögen die Welt kennen lernen, wie wir wollen, sie wird immer 
> eine Tag- und eine Nachtseite behalten. -- Johann Wolfgang von Goethe

echo "g6.lan.dac uptime: " && /usr/bin/uptime
> 12:35:47 up 3 days, 7:29, 9 users, load average: 0.80, 0.48, 0.41

Bug#966661: libghc-propellor-doc: Depends on missing haddock-interface-33

[Ilias Tsitsimpis]

Package: libghc-propellor-doc
Version: 5.10.2-1
Severity: grave
Justification: renders package unusable

Dear maintainer,

This package should be rebuild against the latest ghc (8.8.3) available
on unstable.

Thanks,

-- 
Ilias

Bug#966662: libghc-curry-base-doc: Depends on missing haddock-interface-33

[Ilias Tsitsimpis]

Package: libghc-curry-base-doc
Version: 1.1.1-2
Severity: grave
Justification: renders package unusable

Dear maintainer,

This package should be rebuild against the latest ghc (8.8.3) available
on unstable.

Thanks,

-- 
Ilias

Bug#444969: clusterssh: xinerama awareness

[Samuel Thibault]

Control: severity -1 normal

Hello,

Torsten Neumann, le mar. 02 oct. 2007 12:46:01 +0200, a ecrit:
> It would be nice if -G option uses multiple screens if they are available.

I don't know what the -G option used to be, but it would be useful that
clusterssh takes care of the layout of multiple screens. My current set
up is as attached, and clusterssh puts windows on the bottom left part
of the virtual desktop, thus invisible and unreachable.

Also, it puts windows across screen boundaries, making reading the text
harder.

For both issues, a fix would be for clusterssh to detect xinerama,
and when available, iterate putting windows over the xinerama screens
instead of iterating putting windows over the virtual desktop.

Samuel

Bug#966648: eboard: Split zseal into a separate package

[Asher Gordon]

Package: eboard
Version: 1.1.3-0.3
Severity: wishlist
X-Debbugs-Cc: Asher Gordon 

Dear Maintainer,

Currently, eboard ships with zseal (the timeseal implementation included
with eboard) as /usr/share/games/eboard/timeseal.Linux. However, zseal
is useful without eboard, for use with XBoard for example. So I think it
would be better to split zseal into a separate package.

Note that zseal is included in the upstream eboard distribution
(https://github.com/fbergo/eboard) and it also has its own repository
(https://github.com/fbergo/zseal). At the time of this writing, zseal.c
in both repositories are effectively the same.

I think it would be simplest to build a separate zseal binary package
from the eboard source package. Then, the eboard binary package could
Recommend zseal and install a symlink (or wrapper script to avoid
dangling links) that points to the zseal binary in
/usr/share/games/eboard/timeseal.Linux. Other chess clients (like
XBoard) could then Recommend (or perhaps Suggest) zseal as well.

Also, I think that a symlink should be installed in /usr/bin/timeseal
that points to zseal, since timeseal is the more commonly known name. I
think this should either be done by the zseal package itself, or a
separate package, timeseal, that depends on zseal (and zseal could
Recommend or Suggest timeseal). Personally, I think the second way is
better, because users looking for the timeseal binary would find it in
the timeseal package. Then maybe it would be better for chess clients to
Recommend or Suggest the timeseal package, rather than zseal.

I have limited experience with Debian package development, but I'll try
to do some of this myself if I can find the time.

Thanks,
Asher

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

Kernel: Linux 5.7.0-1-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
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 eboard depends on:
ii  libatk1.0-0  2.36.0-2
ii  libc62.31-2
ii  libcairo21.16.0-4
ii  libfontconfig1   2.13.1-4.2
ii  libfreetype6 2.10.2+dfsg-3
ii  libgcc-s1 [libgcc1]  10.1.0-6
ii  libgdk-pixbuf2.0-0   2.40.0+dfsg-5
ii  libglib2.0-0 2.64.4-1
ii  libgstreamer1.0-01.16.2-2
ii  libgtk2.0-0  2.24.32-4
ii  libpango-1.0-0   1.44.7-4
ii  libpangocairo-1.0-0  1.44.7-4
ii  libpangoft2-1.0-01.44.7-4
ii  libpng16-16  1.6.37-2
ii  libstdc++6   10.1.0-6
ii  zlib1g   1:1.2.11.dfsg-2

Versions of packages eboard recommends:
ii  xfonts-75dpi  1:1.0.4+nmu1

Versions of packages eboard suggests:
ii  gnuchess  6.2.5-1

-- no debconf information

-- 
If for every rule there is an exception, then we have established that there
is an exception to every rule.  If we accept "For every rule there is an
exception" as a rule, then we must concede that there may not be an exception
after all, since the rule states that there is always the possibility of
exception, and if we follow it to its logical end we must agree that there
can be an exception to the rule that for every rule there is an exception.
-- Bill Boquist
   
I prefer to send and receive mail encrypted. Please send me your
public key, and if you do not have my public key, please let me
know. Thanks.

GPG fingerprint: 38F3 975C D173 4037 B397  8095 D4C9 C4FC 5460 8E68


signature.asc
Description: PGP signature

Bug#966582: thunderbird: Thunderbird user interface is inconrrectly displayed

[Carsten Schoenert]

Hello Gustavo,

Am 31.07.20 um 08:49 schrieb Gustavo Gutiérrez:

Hello Carsten!

My bad, too many years using other distributions embedded with a "store" 
to install software...


What I actually meant by "store" was the Software app (Gnome software) 
that is delivered by default within Debian. I installed Thunderbird from 
there:


o.k. I see.
I've tried to readjust your case in a Buster installation, it was 
working without problems. So your user profile is causing problems or 
some other Add-On.


This is important, if I don't change the language after installing it, 
Thunderbird works just fine but if I add more languages and select e.g. 
English UK or Spanish Spain, the UI breaks, the only way I found out to 
fix it back was to delete the folder ".thunderbird" that gets created in 
my home folder every time I open Thunderbird.


The question is how do you install other languages?
My guess would be you install XPI packages you search through the Add-On 
managing. This should and must work, if not in 90% of such or similar 
cases your user profile is somehow broken. If you use such external 
package you are on your own, Debian can't support such use cases


You can of course do this, but for languages Debian is providing 
language specific packages you just need to install through the 
preferred package managers (e.g. apt, aptitude, synaptics, ...). You 
will never have to deal with updates of these packages manually as this 
is done automatically once you (or some automatic way) install a newer 
version of Thunderbird.


After battling a little bit, I gave up upon using Software app in order 
to install TB and finally install Snap store to  install their Snap, I 
don't like that way but I needed to get back to work asap. Thunderbird 
is stable in Debian when installed from the Snap store.


It's also very stable if you install it from the Debian archive. ;) Bug 
reports happen just once per month approximately.
For packages from the Snap repositories the Debian package maintainers 
can't say anything about their quality nor possible side effects due 
different behavior on some corner cases. If a user is using Snapd 
packages and has problems the user needs to get in contact with the 
snapd package maintainers. That's not the case here.


I wish I can get you a screen capture but that wouhttps://wiki.debian.org/Thunderbird#Bug_Reporting_.2F_Issuesld mean I have to 
uninstall TB then reinstall it using GSoftware, change languages and 
restart TB, that would be inconvenient tonight but I will gladly do it 
during the weekend.


Not needed, you have locally all tools available to check the current state.

First you should make a backup of user TB profile or of the complete 
folder that holds all user profiles. The name of the correct folder is 
depending on the age of the used folder. And if I talk about Thunderbird 
then of course I mean Thunderbird from the Debian archive. So maybe you 
need to hide the Snapd of Thunderbird if you want to use this.


Debian has used a rebranded Thunderbird version for a long time that was 
called Icedove. So the folder you need to to look for is called 
'.icedove' or '.thunderbird' and you will find it within your $HOME.


The simplest thing you can do is

 $ cp -a .icedove .icedove-bkp-$(date '+%Y%m%d-%H:%M:%S')

in case your base folder is named .icedove and .thunderbird is a symlink 
to this folder.

Othwerwise you need to make a backup of the folder .thunderbird.

 $ cp -a .thunderbird .thunderbird-bkp-$(date '+%Y%m%d-%H:%M:%S')

Next I would remove possible locally installed language packages from 
you user profile. Exit Thunderbird so it's not running any more.


Check if you have installed some language package for Thunderbird. Looks 
in my case like this:



$ dpkg -l | grep thunderbird
ii  thunderbird   1:78.1.0-1
   amd64mail/news client with RSS, chat and integrated spam filter 
support
ii  thunderbird-l10n-de   1:78.1.0-1
   all  German language package for Thunderbird


Have a look at the required package you need to install and install the 
package if required.



$ LANG= apt search thunderbird-l10n
Sorting... Done
Full Text Search... Done
thunderbird-l10n-all/testing,testing 1:68.10.0-1 all
  All language packages for Thunderbird (meta)

thunderbird-l10n-ar/testing,testing 1:68.10.0-1 all
  Arabic language package for Thunderbird

thunderbird-l10n-ast/testing,testing 1:68.10.0-1 all
  Asturian language package for Thunderbird
... [snip]


In case you have sudo running:

$ sudo apt thunderbird-l10n-de


Otherwise you need to become root and install then the package.

That's basically all you need to do, given the information from your 
issue report you are running locally LANG=es_MX.UTF-8, you will need to 
install the package thunderbird-l10n-es-es.


Restart Thunderbird and you should see the UI in Spain.

If not that something in your 

Bug#955413: btrfs-progs: new mount-time checking causes systemd to timeout and boot failure

[Adam Borowski]

(Sorry for the delay -- I investigated the cause but somehow failed to post
here.  Recently someone on the mailing list reported it also, with same
conclusion.)

On Tue, Mar 31, 2020 at 01:20:48PM +0100, Graham Cobb wrote:
> Package: btrfs-progs
> Version: 5.3.1-1

> The new checks at mount time cause mount times for large filesystems to be 
> much
> longer. My roughly 10TB filesystem now takes over 90 seconds to mount.

90 seconds for 10TB sounds like something is terribly wrong in your case. 
I currently have only one spinning rust array, of 3 disks 7TB, and it
completes mount in around a second.

But, there are folks with massive arrays with mount times of several minutes
or tent of minutes, so the issue is real.

> Unfortunately, this is longer than the default systemd mount timer and systemd
> assumes the mount has failed (and, in fact, cancels it). If the mount is not
> marked with "nofail" this causes boot to fail and to drop into the rescue
> console.

How can a mount be "cancelled"?  The syscall provides no way to abort a
mount attempt -- it either succeeds or fails, with no possible timeouts on
userspace side.

I'm not experienced at debugging systemd issues, but it appears to me that
systemd has a separate thread doing the mount() call, reports timeout
despite the call being still in progress, then upon successful mount
_unmounts_ the filesystem again.


From: Christoph Anton Mitterer 
} We see that, too, at the institute... any larger (few TB) filesystems
} in /etc/fstab make systemd cause the system to fail at boot... leaving
} it a state with no remote resuce (ssh) being possible.
}
} Since such filesystems would mount just fine... I would rather say that
} this functionality is a severe bug.

They do mount successfully with a manual mount, so do they with initscripts.
The timeout is done on systemd side, with the kernel doing as expected.

Also, it can't be fixed in btrfs-progs, as no code in this package is run at
mount time.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ in the beginning was the boot and root floppies and they were good.
⢿⡄⠘⠷⠚⠋⠀   --  on #linux-sunxi
⠈⠳⣄

Bug#966666: kdepim-runtime: CVE-2020-15954

[Salvatore Bonaccorso]

Source: kdepim-runtime
Version: 4:20.04.1-1
Severity: important
Tags: security upstream
X-Debbugs-Cc: Debian Security Team 
Control: clone -1 -2
Control: reassign -2 src:kmail-account-wizard 4:20.04.1-1
Control: retitle -2 kmail-account-wizard: CVE-2020-15954

Hi,

The following vulnerability was published for
kdepim-runtime/kmail-account-wizard.

CVE-2020-15954[0]:
| KDE KMail 19.12.3 (aka 5.13.3) engages in unencrypted POP3
| communication during times when the UI indicates that encryption is in
| use.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2020-15954
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-15954
[1] https://bugs.kde.org/show_bug.cgi?id=423426

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#966575: grub-pc: error: symbol `grub_calloc' not found.

[Steve McIntyre]

[ Dropping the CC to Chad here ]

On Sat, Aug 01, 2020 at 02:36:25PM +0100, Colin Watson wrote:
>On Sat, Aug 01, 2020 at 01:52:41PM +0100, Steve McIntyre wrote:
>>  * Do we need to scan? if grub is installed and doing an upgrade and
>>there is only one disk of an appropriate type (BIOS with DOS, or
>>UEFI with GPT), then always install there?
>
>Possibly.  I'd still be inclined to have a scan as a guard-rail in that
>case, since we'd need to have the code anyway, and the point is to try
>to discover the disk that the system booted from so by definition it
>must have GRUB there if it's to be valid.

Nod. Of course, it's a guess at best - we have ~no way to know *for
sure* which disk we actually booted off. It would be lovely if we did,
but there's no protocol for grub to pass on that information that I
can see.

>>  * (Maybe) we could add an option for grub-pc to always grub-install
>>to *all* the BIOS-visible disks? Yes, I know there's a potential
>>for breakage there with multi-boot systems. Maybe only do this on
>>systems where os-prober has not found anything but the Debian
>>installation?
>
>One concern I have is filtering out things like optical drives, which
>are BIOS-visible but not sensible grub-install targets.  I'm also
>slightly reluctant to add more invocations of os-prober while it's as
>slow as it can sometimes be.  I do see the utility of this though.

Nod. Can we not rely on os-prober already having been run once and use
that data? (Sorry, not sure of the ordering here.)

>>  * If we do add the code to scan boot sectors, maybe check all the
>>BIOS-visible disks and flag any that look like they have GRUB, but
>>are not our version? (Not sure how feasible this is without
>>digging!)
>
>Unfortunately I believe this to be essentially infeasible.  As an
>illustration, this is the scan code which exists in the current postinst
>to support migration from GRUB Legacy, and believe me I didn't resort to
>this horror before trying to find more sensible alternatives:
>
>  # In order to determine whether we accidentally ran grub-install without
>  # upgrade-from-grub-legacy on versions older than 1.98+20100617-1, we need
>  # to be able to scan a disk to determine whether GRUB 2 was installed in its
>  # boot sector.  This is specific to i386-pc (but that's the only platform
>  # where we need it).
>  scan_grub2()
>  {
>if ! dd if="$1" bs=512 count=1 2>/dev/null | grep -aq GRUB; then
>  # No version of GRUB is installed.
>  return 1
>fi
>  
># The GRUB boot sector always starts with a JMP instruction.
>initial_jmp="$(dd if="$1" bs=2 count=1 2>/dev/null | od -Ax -tx1 | \
>   head -n1 | cut -d' ' -f2,3)"
>[ "$initial_jmp" ] || return 1
>initial_jmp_opcode="${initial_jmp%% *}"
>[ "$initial_jmp_opcode" = eb ] || return 1
>initial_jmp_operand="${initial_jmp#* }"
>case $initial_jmp_operand in
>  47|4b|4c|63)
># I believe this covers all versions of GRUB 2 up to the package
># version where we gained a more explicit mechanism.  GRUB Legacy
># always had 48 here.
>return 0
>  ;;
>esac
>  
>return 1
>  }
>
>The actual package version does get embedded in the boot loader, but
>only in the "normal" module, not anywhere that could be usefully
>discovered by a scan.  Otherwise the best we could do would basically be
>a big list of signatures, which I'm not enthusiastic about.

Argh, yes. Basically what I expected, I'll be honest. Oh, hmmm -
that's the boot sector. Could we pick up on more from the embedded
binary "stage 1.5" lump? This is getting hairy, maybe, but
could/should be a wider thing to go upstream?

>>  * For UEFI, I'd love to switch to using the monolithic GRUB image
>>even for non-signed use. It makes a lot of the issues go away if
>>~all the modules necessary for boot are always built-in.
>
>I think I agree, though we should take that to a separate bug; I'd like
>to keep this one for the BIOS situation.

Agreed. Just something I thought to mention while it was in my
head. :-)

>>  * Finally, we should also stop using debconf as a registry like we
>>are. It's annoying the DSA folks (at least). By all means use
>>debconf to help manage things, but we should be storing the lasting
>>config in a config file that people can edit. We already store some
>>of our stuff in /etc/default/grub, let's push more of our config
>>there?
>
>Agreed in general terms; this has been on my to-do list for a long time.
>Of course we need to consider the migration path carefully.  In terms of
>specifics, I'm not sure I want to extend /etc/default/grub for this,
>though; that has configuration file management issues, and generally I
>don't really want to overload the upstream grub-mkconfig configuration
>file with packaging-specific things for grub-install.  I'd be inclined
>to go for /etc/default/grub-pc instead, or maybe something under
>/etc/grub/.

Sure. 

Bug#966654: libgpiod: symbol mismatches with gcc-10/O3 optimization

[Gianfranco Costamagna]

Source: libgpiod
Version: 1.5.1-1
Severity: serious
tags: patch

Hello, looks like some symbols are disappearing when built with -O3 
optimization level, and some other
changed in armhf and ppc64el (probably due to gcc-10)

the following patch seems to be enough to make everybody happy, by making some 
symbols optional.
thanks for considering it

G.


--- libgpiod-1.5.1/debian/changelog 2020-07-01 05:27:41.0 +0200
+++ libgpiod-1.5.1/debian/changelog 2020-07-31 20:08:33.0 +0200
@@ -1,3 +1,9 @@
+libgpiod (1.5.1-1.1) unstable; urgency=medium
+
+  * Refresh symbols (Closes: #-1)
+
+ -- Gianfranco Costamagna   Fri, 31 Jul 2020 
20:08:33 +0200
+
 libgpiod (1.5.1-1) unstable; urgency=medium
 
   * Import new upstream release
diff -Nru libgpiod-1.5.1/debian/libgpiod2.symbols 
libgpiod-1.5.1/debian/libgpiod2.symbols
--- libgpiod-1.5.1/debian/libgpiod2.symbols 2020-07-01 05:27:19.0 
+0200
+++ libgpiod-1.5.1/debian/libgpiod2.symbols 2020-07-31 20:08:33.0 
+0200
@@ -99,6 +99,8 @@
  gpiod_line_update@Base 1.1
  gpiod_version_string@Base 1.1
 libgpiodcxx.so.1 libgpiod2 #MINVER#
+ (c++|optional)"std::_Function_base::~_Function_base()@Base" 1.5.1
+ (c++|optional)"std::_Function_base::~_Function_base()@Base" 1.5.1
  (c++)"gpiod::line_request::FLAG_ACTIVE_LOW@Base" 1.1
  (c++)"gpiod::line_request::FLAG_OPEN_DRAIN@Base" 1.1
  (c++)"gpiod::line_request::FLAG_OPEN_SOURCE@Base" 1.1
@@ -209,7 +211,7 @@
  (c++)"std::system_error::system_error(int, std::_V2::error_category const&, 
std::__cxx11::basic_string, std::allocator > 
const&)@Base" 1.1
  (c++)"std::system_error::system_error(std::error_code, char const*)@Base" 1.1
  (c++)"std::system_error::system_error(int, std::_V2::error_category const&, 
std::__cxx11::basic_string, std::allocator > 
const&)@Base" 1.1
- (c++)"std::_Function_base::_Base_manager, 
std::allocator > const&)>::_M_manager(std::_Any_data&, std::_Any_data 
const&, std::_Manager_operation)@Base" 1.1
+ (c++|optional)"std::_Function_base::_Base_manager, 
std::allocator > const&)>::_M_manager(std::_Any_data&, std::_Any_data 
const&, std::_Manager_operation)@Base" 1.1
  (c++|arch= !armel !riscv64)"std::_Sp_counted_ptr::_M_dispose()@Base" 1.1
  (c++|arch= !armel 
!riscv64)"std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_destroy()@Base" 
1.1
  (c++)"std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_release()@Base" 
1.4.1
@@ -219,8 +221,8 @@
  (c++|optional|arch-bits=32)"std::vector 
>::_M_default_append(unsigned int)@Base" 1.5.1
  (c++|optional)"void std::__cxx11::basic_string, 
std::allocator >::_M_construct(char const*, char const*, 
std::forward_iterator_tag)@Base" 1.1
  (c++|optional)"std::_Rb_tree, 
std::_Select1st >, std::less, 
std::allocator > >::_M_get_insert_unique_pos(int 
const&)@Base" 1.1
- (c++|arch=amd64 arm64 ppc64el mips64el riscv64)"std::_Rb_tree, std::_Select1st >, 
std::less, std::allocator > 
>::_M_get_insert_hint_unique_pos(std::_Rb_tree_const_iterator >, int const&)@Base" 1.1
- (c++)"std::_Rb_tree, 
std::_Select1st >, std::less, 
std::allocator > 
>::_M_erase(std::_Rb_tree_node >*)@Base" 1.1
+ (c++|optional|arch=amd64 arm64 ppc64el mips64el riscv64)"std::_Rb_tree, std::_Select1st >, 
std::less, std::allocator > 
>::_M_get_insert_hint_unique_pos(std::_Rb_tree_const_iterator >, int const&)@Base" 1.1
+ (c++|optional)"std::_Rb_tree, 
std::_Select1st >, std::less, 
std::allocator > 
>::_M_erase(std::_Rb_tree_node >*)@Base" 1.1
  (c++|arch= !armel !riscv64)"typeinfo for 
std::_Mutex_base<(__gnu_cxx::_Lock_policy)2>@Base" 1.1
  (c++|arch= !armel !riscv64)"typeinfo for 
std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>@Base" 1.1
  (c++|arch= !armel !riscv64)"typeinfo name for 
std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>@Base" 1.4
@@ -235,6 +237,6 @@
  (c++|arch= armel riscv64)"typeinfo name for __gnu_cxx::__mutex@Base" 1.2
  (c++|arch= armel riscv64)"typeinfo name for 
std::_Mutex_base<(__gnu_cxx::_Lock_policy)1>@Base" 1.2
  (c++|arch= armel riscv64)"typeinfo name for 
std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)1>@Base" 1.2
- (c++|arch= i386 armel mipsel armhf s390x)"std::map, 
std::allocator > 
>::map(std::initializer_list >, std::less 
const&, std::allocator > const&)@Base" 1.3
+ (c++|optional|arch= i386 armel mipsel armhf s390x)"std::map, std::allocator > 
>::map(std::initializer_list >, std::less 
const&, std::allocator > const&)@Base" 1.3
  (c++|arch= !armel 
!riscv64)"std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_release()@Base" 
1.4.1
  (c++|arch= !armel !riscv64)"typeinfo name for 
std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>@Base" 1.4.1

Bug#966622: general: lock_screen causes blank screen which is onlyresolved with full power off using button

[Gordan White]

 

Package: general
Severity: normal

Dear Maintainer,


* What led up to the situation? i installed the debian xfce package and it was had the issue
* What exactly did you do (or not do) that was effective (or
ineffective)? i downloaded some packages from synaptic which sounded appropriate
* What was the outcome of this action? it didn't work
* What outcome did you expect instead? i though it'd work.





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

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

Sent: Friday, July 31, 2020 at 4:37 PM
From: "Sean" 
To: "Debian Bug Tracking System" 
Subject: Bug#966622: general: lock_screen causes blank screen which is onlyresolved with full power off using button

Package: general
Severity: normal

Dear Maintainer,

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

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

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



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

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

Bug#966659: libghc-monad-gen-doc: Depends on missing haddock-interface-33

[Ilias Tsitsimpis]

Package: libghc-monad-gen-doc
Version: 0.3.0.1-1
Severity: grave
Justification: renders package unusable

This package should be rebuild against the latest ghc (8.8.3) available
on unstable.

Alternatively, since this package looks unmaintained (last upstream
upload at 2014), is not part of Stackage and has no rev dependencies, we
may consider removing it.

Thanks,

-- 
Ilias

Bug#966633: [debian-mysql] Bug#966633: libmariadb3: In Perl, doing a ping() after a disconnect() causes a segfault using DBD::mysql

[Otto Kekäläinen]

Hello!

Thanks for reporting!

It would be best if you submitted your patch directly upstream at
https://github.com/mariadb-corporation/mariadb-connector-c/

They have the best knowledge to assess if this change is OK or if it
has potential regressions.

Bug#966544: snmpd: extend option broken after update

[Salvatore Bonaccorso]

Hi Felix and all,

On Fri, Jul 31, 2020 at 03:36:54PM +0200, Felix Sperling wrote:
> Hi,
> 
> we were also effected from the update 5.7.3+dfsg-1.7+deb9u2 causing lots of
> broken icinga checks.
> 
> Our workaround is pinning 5.7.3+dfsg-1.7+deb9u1.
> 
> What's unclear from the solution if 5.8 also will be available in stretch
> and buster which we need. Otherwise it would be great to enable extend in
> 5.7.3 for those versions.

5.8+dfsg-5 cannot go to buster and stretch, so this is not an option.
For buster the update the maintainer (Craig Small) is planning for the
security update is mirroring what went into unstable.

As 5.7.3+dfsg-1.7+deb9u2 went out as DLA 2299-1, I'm looping in here
the LTS team. LTS team: Would suggest to issue a regression update for
the DLA and revisit the fix for CVE-2020-15862 to do the same, not to
disable EXTEND-MIB completely but making it read-only.

Hope this helps so far,

Regards,
Salvatore

Bug#957563: mpg321: ftbfs with GCC-10

[Joachim Reichel]

NMU uploaded to delayed/10.

Basically mpg321_common.diff plus an additional fix for another FTBFS related
to circular build dependencies. Updated diff attached.

Best regards,
  Joachim
diff -Nru mpg321-0.3.2/debian/changelog mpg321-0.3.2/debian/changelog
--- mpg321-0.3.2/debian/changelog	2019-03-13 15:59:02.0 +0100
+++ mpg321-0.3.2/debian/changelog	2020-07-23 17:22:42.0 +0200
@@ -1,3 +1,15 @@
+mpg321 (0.3.2-3.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Export CFLAGS to make them take effect.
+  * Add -Wno-error=format-security to CFLAGS to disable the default from
+dpkg-buildflags as workaround for some build error.
+  * Add -fcommon to CFLAGS (Closes: #957563).
+  * Remove circular build dependencies around build-stamp which make the
+package FTBFS in clean environments.
+
+ -- Joachim Reichel   Thu, 23 Jul 2020 17:22:42 +0200
+
 mpg321 (0.3.2-3) unstable; urgency=medium
 
   * Fix compilation error
diff -Nru mpg321-0.3.2/debian/rules mpg321-0.3.2/debian/rules
--- mpg321-0.3.2/debian/rules	2012-05-01 08:53:43.0 +0200
+++ mpg321-0.3.2/debian/rules	2020-07-23 17:22:42.0 +0200
@@ -4,7 +4,7 @@
 #export DH_VERBOSE=1
 
 
-CFLAGS = $(shell dpkg-buildflags --get CFLAGS) -Wall -Wunused
+export CFLAGS = $(shell dpkg-buildflags --get CFLAGS) -Wall -Wunused -Wno-error=format-security -fcommon 
 
 MPG321_ARCH = $(shell dpkg-architecture -qDEB_BUILD_ARCH_OS)
 
@@ -24,15 +24,14 @@
 endif
 	touch configure-stamp
 
-build: configure-stamp build-arch build-indep
-build-arch: build-stamp
-build-indep: build-stamp
-build-stamp: build install
+build: build-arch build-indep
+build-arch: configure-stamp
+build-indep: configure-stamp
 
 clean:
 	dh_testdir
 	dh_testroot
-	rm -f build-stamp configure-stamp
+	rm -f configure-stamp
 
 	# Add here commands to clean up after the build process.
 	[ ! -f Makefile ] || $(MAKE) distclean

Bug#966655: [Debian-med-packaging] Bug#966655: orthanc: using tzdata but missing dependency on it?

[Sébastien Jodogne]

Hello,

Thanks for your report. Unfortunately, as long as orthanc-1.7.2+dfsg-2
is pending in the NEW queue [1], no further patch can be applied.

Kind Regards,
Sébastien-

[1] https://ftp-master.debian.org/new.html


On 1/08/20 11:08, Gianfranco Costamagna wrote:
> Source: orthanc
> Version: 1.7.2+dfsg-1
> Severity: serious
> tags: patch
> 
> Hello, looks like orthanc fails to build from source (testsuite error) when 
> tzdata is not installed in the chroot.
> 
> I'm not sure if this is an essential package or not, but looks like it can be 
> removed, or not be available on some chroots
> 
> 
> this is an example of failure
> 
> mkdir -p /<>/debian/tmp/locale/
> localedef -f UTF-8 -i en_US /<>/debian/tmp/locale/en_US.UTF-8/
> ( cd Build; LOCPATH=/<>/debian/tmp/locale/ ./UnitTests )
> E0731 17:53:29.829350 OrthancException.h:76] Internal error: On UNIX-like 
> systems, the file /etc/localtime must be present on the filesystem (install 
> "tzdata" package on Debian)
> terminate called after throwing an instance of 'Orthanc::OrthancException'
> Aborted (core dumped)
> make[1]: *** [debian/rules:73: override_dh_auto_test] Error 134
> 
> 
> I think adding it as explicit dependency might solve some headaches.
> 
> G.

Bug#966663: ansible: CVE-2020-1736

[Salvatore Bonaccorso]

Source: ansible
Version: 2.9.9+dfsg-1
Severity: important
Tags: security upstream
Forwarded: https://github.com/ansible/ansible/issues/67794
X-Debbugs-Cc: Debian Security Team 

Hi,

The following vulnerability was published for ansible.

CVE-2020-1736[0]:
| A flaw was found in Ansible Engine when a file is moved using
| atomic_move primitive as the file mode cannot be specified. This sets
| the destination files world-readable if the destination file does not
| exist and if the file exists, the file could be changed to have less
| restrictive permissions before the move. This could lead to the
| disclosure of sensitive data. All versions in 2.7.x, 2.8.x and 2.9.x
| branches are believed to be vulnerable.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2020-1736
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-1736
[1] https://github.com/ansible/ansible/issues/67794

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#966575: grub-pc: error: symbol `grub_calloc' not found.

[Steve McIntyre]

On Fri, Jul 31, 2020 at 11:49:06PM +0100, Colin Watson wrote:

...

>It looks like the base VM image provided by bento/debian-10 hardcodes
>some details of how it was built that don't carry over to other systems
>booting the same image, and this causes problems.
>
>debian/buster64 has a similar problem, but with different details.  It
>has:
>
>  vagrant@buster:~$ sudo debconf-show grub-pc | grep grub-pc/install_devices:
>  * grub-pc/install_devices: /dev/vda

Ah!

>> I'm using the (admittedly insecure) solution  of "sudo apt-mark hold grub*"
>> shown here: https://askubuntu.com/a/1263204
>
>As several comments there note, a better fix is "sudo dpkg-reconfigure
>grub-pc".

Definitely!

>This is in some ways the most interesting subtype of this bug, because
>it's one we can easily reproduce!  It falls into the category of "error
>in a cloning process"; but it also makes it relatively straightforward
>to experiment with ways to mitigate the problem further.
>
>We could at minimum make this be an upgrade error in the noninteractive
>case, ensuring that it doesn't touch modules if the target device is
>just plain missing: the upgrade error might be a bit rough for some
>people, but it would be better than a boot failure.
>
>A refinement of this might be that if the system only has one disk, and
>that disk appears to have GRUB installed on it (by relatively crude boot
>sector scanning), then we could assume that this is the common case of a
>disk having been swapped out and automatically change
>grub-pc/install_devices to point to that instead.  With appropriate
>guard rails, I think that could help quite a lot of the people affected
>by this sort of problem.

Yes, definitely. Let's have a chat about how to do stuff. I was
thinking about some topics here:

 * Do we need to scan? if grub is installed and doing an upgrade and
   there is only one disk of an appropriate type (BIOS with DOS, or
   UEFI with GPT), then always install there?

 * (Maybe) we could add an option for grub-pc to always grub-install
   to *all* the BIOS-visible disks? Yes, I know there's a potential
   for breakage there with multi-boot systems. Maybe only do this on
   systems where os-prober has not found anything but the Debian
   installation?

 * If we do add the code to scan boot sectors, maybe check all the
   BIOS-visible disks and flag any that look like they have GRUB, but
   are not our version? (Not sure how feasible this is without
   digging!)

 * For UEFI, I'd love to switch to using the monolithic GRUB image
   even for non-signed use. It makes a lot of the issues go away if
   ~all the modules necessary for boot are always built-in.

 * Finally, we should also stop using debconf as a registry like we
   are. It's annoying the DSA folks (at least). By all means use
   debconf to help manage things, but we should be storing the lasting
   config in a config file that people can edit. We already store some
   of our stuff in /etc/default/grub, let's push more of our config
   there?


-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
< sladen> I actually stayed in a hotel and arrived to find a post-it
  note stuck to the mini-bar saying "Paul: This fridge and
  fittings are the correct way around and do not need altering"

Bug#957642: openrc: ftbfs with GCC-10

[Kentaro Hayashi]

control tags -1 fixed-upstream

Hi,
It seems that this issue was already fixed in upstream.

0.42.1 was released from upstream - which is newer than 
packaged in Debian (0.42-1), but this fix is not included yet.
so we need a patch to fix it.

Here is the link to upstream fix.
https://github.com/OpenRC/openrc/commit/375ef42393f3dc6edbaa2cb70c79b2366072db38

Regards,


-- 
Kentaro Hayashi 

Bug#957068: cavezofphear: ftbfs with GCC-10

[Reiner Herrmann]

Control: tags -1 + patch

Hi,

the attached patches fixes the FTBFS with GCC 10.

Regards,
  Reiner
diff -Nru cavezofphear-0.5.1/debian/patches/gcc10.patch cavezofphear-0.5.1/debian/patches/gcc10.patch
--- cavezofphear-0.5.1/debian/patches/gcc10.patch	1970-01-01 01:00:00.0 +0100
+++ cavezofphear-0.5.1/debian/patches/gcc10.patch	2020-08-01 15:44:47.0 +0200
@@ -0,0 +1,26 @@
+Author: Reiner Herrmann 
+Description: Fix FTBFS with GCC 10
+Bug-Debian: https://bugs.debian.org/957068
+
+--- a/src/frame.c
 b/src/frame.c
+@@ -26,7 +26,7 @@
+ void sigint_handler();
+ void sigwinch_handler();
+ 
+-int need_refresh;
++extern int need_refresh;
+ 
+ void curses_start(void)
+ {
+--- a/src/editor.c
 b/src/editor.c
+@@ -24,7 +24,7 @@
+ #include "common.h"
+ #include "proto.h"
+ 
+-char map[MAP_YSIZE][MAP_XSIZE];
++extern char map[MAP_YSIZE][MAP_XSIZE];
+ int lock;
+ int last_obj;
+ 
diff -Nru cavezofphear-0.5.1/debian/patches/series cavezofphear-0.5.1/debian/patches/series
--- cavezofphear-0.5.1/debian/patches/series	1970-01-01 01:00:00.0 +0100
+++ cavezofphear-0.5.1/debian/patches/series	2020-08-01 15:44:47.0 +0200
@@ -0,0 +1 @@
+gcc10.patch


signature.asc
Description: PGP signature

Bug#966671: coturn: unlimited number of /var/log/turn_*.log are created

[sergio]

Package: coturn
Version: 4.5.1.1-1.1+deb10u1
Severity: serious
Justification: Policy 10.8

Dear Maintainer,

An unlimited number of /var/log/turn_*.log are created.

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

Kernel: Linux 4.19.0-9-amd64 (SMP w/2 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: sysvinit (via /sbin/init)

Versions of packages coturn depends on:
ii  adduser  3.118
ii  libc62.28-10
ii  libevent-core-2.1-6  2.1.8-stable-4
ii  libevent-extra-2.1-6 2.1.8-stable-4
ii  libevent-openssl-2.1-6   2.1.8-stable-4
ii  libevent-pthreads-2.1-6  2.1.8-stable-4
ii  libhiredis0.14   0.14.0-3
ii  libmariadb3  1:10.3.22-0+deb10u1
ii  libpq5   11.7-0+deb10u1
ii  libsqlite3-0 3.27.2-3
ii  libssl1.11.1.1d-0+deb10u3
ii  lsb-base 10.2019051400
ii  sqlite3  3.27.2-3
ii  telnet [telnet-client]   0.17-41.2

coturn recommends no packages.

-- Configuration Files:
/etc/default/coturn changed:
TURNSERVER_ENABLED=1

/etc/turnserver.conf changed:
no-tlsv1
no-tlsv1_1
listening-ip=
external-ip=
realm=domain.tld
denied-peer-ip=10.0.0.0-10.255.255.255
denied-peer-ip=192.168.0.0-192.168.255.255
denied-peer-ip=172.16.0.0-172.31.255.255
allowed-peer-ip=10.8.0.0-10.8.255.255
use-auth-secret
static-auth-secret=
user-quota=16
syslog
mobility
cert=/etc/ssl/localcerts/domain.tld-cert.pem
pkey=/etc/ssl/localcerts/domain.tld-key.pem
cipher-list="CHACHA20:AESGCM:!AES128"
dh2066
no-cli
cli-password=pass


-- no debconf information

Bug#963338: sagemath: FTBFS: RuntimeError: Aborted

[Jerome BENOIT]

Thanks for the report. Meanwhile the Sagemath Debian team take a summer break. 
Cheers, Jerome
-- 
Jerome BENOIT | calculus+at-rezozer^dot*net
https://qa.debian.org/developer.php?login=calcu...@rezozer.net
AE28 AE15 710D FF1D 87E5  A762 3F92 19A6 7F36 C68B



signature.asc
Description: OpenPGP digital signature

Bug#963338: sagemath: FTBFS: RuntimeError: Aborted

[Tobias Hansen]

Control: tags 963338 + help

Just yesterday I just did a test build of vanilla sage (not the Debian package) 
9.2.beta6 with the python 3.8 patch from [1] and Debian's python 3.8 to see if 
the file handle leak that happens during parallel builds of the Debian package 
also happens there. It didn't. I don't know how to debug this.

Best,
Tobias

[1] https://trac.sagemath.org/ticket/27754

On 8/1/20 10:43 AM, Jerome BENOIT wrote:
> Thanks for the report. Meanwhile the Sagemath Debian team take a summer 
> break. Cheers, Jerome

Bug#966657: json-c: please make the build reproducible

[Nicolas Mora]

Thanks Chris!

Le 20-08-01 à 06 h 11, Chris Lamb a écrit :
> 
> This is because it used the full, absolute path name as an (sanitised)
> input to a filename, resulting in the binary package containing
> 

I've already added the following patch [1] in last release 0.15-1
This patch sets the following doxygen value:
FULL_PATH_NAMES= NO

According to the documentation, both our patches are incompatible:

# This tag requires that the tag FULL_PATH_NAMES is set to YES.

I made that patch for the reproducibility as well although yours may be
better. What do you think?

[1] -
https://sources.debian.org/src/json-c/0.15-1/debian/patches/0002-doxygen.patch/



signature.asc
Description: OpenPGP digital signature

Bug#966647: libetpan: CVE-2020-15953

[Salvatore Bonaccorso]

Source: libetpan
Version: 1.9.4-2
Severity: important
Tags: security upstream
Forwarded: https://github.com/dinhvh/libetpan/issues/386
X-Debbugs-Cc: Debian Security Team 

Hi,

The following vulnerability was published for libetpan.

CVE-2020-15953[0]:
| LibEtPan through 1.9.4, as used in MailCore 2 through 0.6.3 and other
| products, has a STARTTLS buffering issue that affects IMAP, SMTP, and
| POP3. When a server sends a "begin TLS" response, the client reads
| additional data (e.g., from a meddler-in-the-middle attacker) and
| evaluates it in a TLS context, aka "response injection."


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2020-15953
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-15953
[1] https://github.com/dinhvh/libetpan/issues/386

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#966652: coreutils: chmod/chgrp/chown causes ctime change even when no change needed

[E Harris]

Package: coreutils
Version: 8.30-3
Severity: normal
Tags: upstream

GNU chmod/chgrp/chown have an issue that causes the ctime to change on every
file, even when no change to the mode/ownership was made.  This is a problem
for backup and file-integrity checking software that uses the ctime (since 
it cannot be trivially reset to hide a file change, unlike mtime) to detect
if changes might have been made to a file.

> stat test
  File: test
  Size: 0   Blocks: 0  IO Block: 4096   regular empty file
Device: fd05h/64773dInode: 10424846Links: 1
Access: (0640/-rw-r-)  Uid: ( 1000/ user)   Gid: ( 1000/ user)
Access: 2020-08-01 02:06:51.555950597 -0500
Modify: 2020-08-01 02:06:51.555950597 -0500
Change: 2020-08-01 02:32:00.176824460 -0500
 Birth: -
> chmod -c g+r test
> stat test
  File: test
  Size: 0   Blocks: 0  IO Block: 4096   regular empty file
Device: fd05h/64773dInode: 10424846Links: 1
Access: (0640/-rw-r-)  Uid: ( 1000/ user)   Gid: ( 1000/ user)
Access: 2020-08-01 02:06:51.555950597 -0500
Modify: 2020-08-01 02:06:51.555950597 -0500
Change: 2020-08-01 02:34:09.273579189 -0500
 Birth: -

You can see that the -c option did not report that the file was changed,
since the g+r bit was already set, however the ctime still did change.

Similar results occur when using chown and chgrp.

chmod/chown/chgrp are very commonly used with -R to ensure that an entire
directory tree has ownership and permissions set correctly, but with this
bug also causes every file in that tree to now be considered "changed" even
when most or all may not actually have been.

If these utilities were just blindly setting the mode/owner of files, then
this behavior might be able to be justified.  But since these utilities
already have a -c flag, and actually do the necessary work/stat beforehand
to see if a change is needed, I can't see any reason why it should still be 
causing a ctime change on files that do not require any changes.

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

Kernel: Linux 4.19.0-9-amd64 (SMP w/4 CPU cores)
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= 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages coreutils depends on:
ii  libacl1  2.2.53-4
ii  libattr1 1:2.4.48-4
ii  libc62.28-10
ii  libselinux1  2.8-1+b1

coreutils recommends no packages.

coreutils suggests no packages.

-- no debconf information

Bug#966664: ERROR: libx11-dev-1.6.10-r0: trying to overwrite usr/include/X11/extensions/XKBgeom.h owned by xorgproto-2018.4-r0.

[jervy escoto]

Package: libx11-dev
Version: 1.6.10-r0
Severity: serious
Justification: fails to install

Hi

When trying to install libx11-dev, I get the following error:

 (80/129) Installing libx11-dev (1.6.10-r0)
ERROR: libx11-dev-1.6.10-r0: trying to overwrite
usr/include/X11/extensions/XKBgeom.h owned by xorgproto-2018.4-r0.


Regards,
Jervy

Bug#955469: initramfs-tools-core: Enable zstandard support

[Sedat Dilek]

On Sat, Aug 1, 2020 at 12:27 AM Norbert Lange  wrote:
>
> Am Fr., 31. Juli 2020 um 16:48 Uhr schrieb Sedat Dilek 
> :
> >
> > Just FYI:
> >
> > Version 10 was now accepted in .
> >
> > Let's hope this will get into upcoming Linux v5.9.
> >
> > - Sedat -
> >
> > [1] https://github.com/terrelln/linux/commits/zstd-v10
> > [2] 
> > https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/log/?h=x86/boot
>
> Thanks,
>
> I updated the patch, and made a merge request there:
> https://salsa.debian.org/kernel-team/initramfs-tools/-/merge_requests
>

Hi Norbert,

Thank you, too.

You mean [1]?

[ mkinitramfs ]

+zstd) compress="zstd -q -19 -T0" ;;

>From my kernel build-log:

{ cat arch/x86/boot/compressed/vmlinux.bin
arch/x86/boot/compressed/vmlinux.relocs | zstd -22 --ultra; printf
\014\015\315\001; } > arch/x86/boot/compressed/vmlinux.bin.zst

Thus I have analog here:

root# diff -uprN /usr/sbin/mkinitramfs.orig /usr/sbin/mkinitramfs
--- /usr/sbin/mkinitramfs.orig  2020-04-28 05:56:17.0 +0200
+++ /usr/sbin/mkinitramfs   2020-07-09 10:35:35.119280519 +0200
@@ -189,6 +189,7 @@ xz) compress="xz --check=crc32"
# If we're not doing a reproducible build, enable multithreading
test -z "${SOURCE_DATE_EPOCH}" && compress="$compress --threads=0"
;;
+zstd)  compress="zstd -22 --ultra -v" ;;
 bzip2|lzma|lzop)
# no parameters needed
;;

Regards,
- Sedat -


[1] 
https://salsa.debian.org/kernel-team/initramfs-tools/-/merge_requests/33/diffs?commit_id=e94f410c71e90598b4fabca3970c7f282b5bd0a0

Bug#966669: freecad: PDF Export gives a blank document, Print Preview do the same

[Marcelo Luiz de Laia]

Package: freecad
Version: 0.18.4+dfsg2-5
Severity: minor

Dear Maintainer,

I have noticed for awhile that I cannot export any of my new models to PDF. I
don't get an error of any kind, and there is a PDF file written, but its a
single blank page. The "Print preview" command opens the print preview window,
but it is blank.



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

Kernel: Linux 5.7.0-1-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_CRAP, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=pt_BR.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8), 
LANGUAGE=pt_BR:pt:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages freecad depends on:
ii  freecad-python3  0.18.4+dfsg2-5

Versions of packages freecad recommends:
ii  calculix-ccx  2.11-1+b3
ii  graphviz  2.42.2-4

Versions of packages freecad suggests:
pn  povray  

-- no debconf information

Bug#957247: galculator: ftbfs with GCC-10

[Kentaro Hayashi]

control: tags -1 patch

Hi, I've attached a patch.

I've also send PR for upstream.

https://github.com/galculator/galculator/pull/45
>From 501a9e3feeb2e56889c0ff98ab6d0ab20348ccd6 Mon Sep 17 00:00:00 2001
From: Kentaro Hayashi 
Date: Sat, 1 Aug 2020 22:25:37 +0900
Subject: [PATCH] Fix multiple definition of `prefs` compile error with GCC-10

This commit fixes the following error:

  libtool: link: gcc -pthread -I/usr/include/gtk-3.0 -I/usr/include/at-spi2-atk/2.0 -I/usr/include/at-spi-2.0 -I/usr/include/dbus-1.0 -I/usr/lib/x86_64-linux-gnu/dbus-1.0/include -I/usr/include/gtk-3.0 -I/usr/include/gio-unix-2.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/fribidi -I/usr/include/harfbuzz -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/uuid -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/libmount -I/usr/include/blkid -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -g -O2 -fdebug-prefix-map=/workspace/galculator-2.1.4=. -fstack-protector-strong -Wformat -Werror=format-security -Wall -Wl,-z -Wl,relro -o galculator galculator-main.o galculator-math_functions.o galculator-display.o galculator-general_functions.o galculator-calc_basic.o galculator-config_file.o galculator-callbacks.o galculator-ui.o galculator-flex_parser.o -Wl,--export-dynamic  -Wl,--as-n
 eeded -lgtk-3 -lgdk-3 -lpangocairo-1.0 -lpango-1.0 -lharfbuzz -latk-1.0 -lcairo-gobject -lcairo -lgdk_pixbuf-2.0 -lgio-2.0 -lgobject-2.0 -lglib-2.0 -lm -lquadmath -pthread
/usr/bin/ld: galculator-config_file.o:./src/config_file.c:42: multiple definition of `prefs'; galculator-main.o:./src/main.c:52: first defined here
  collect2: error: ld returned 1 exit status

Signed-off-by: Kentaro Hayashi 
---
 src/main.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/main.c b/src/main.c
index 10d0868..d22fea0 100644
--- a/src/main.c
+++ b/src/main.c
@@ -49,7 +49,7 @@
 
 #define MASK_NUMLOCK GDK_MOD2_MASK
 
-s_preferences		prefs;
+extern s_preferences		prefs;
 s_current_status 	current_status = {0, 0, 0, 0, FALSE, FALSE, TRUE};
 s_arraymemory;
 s_constant 			*constant;
-- 
2.28.0

Bug#966575: grub-pc: error: symbol `grub_calloc' not found.

[Colin Watson]

On Sat, Aug 01, 2020 at 01:52:41PM +0100, Steve McIntyre wrote:
>  * Do we need to scan? if grub is installed and doing an upgrade and
>there is only one disk of an appropriate type (BIOS with DOS, or
>UEFI with GPT), then always install there?

Possibly.  I'd still be inclined to have a scan as a guard-rail in that
case, since we'd need to have the code anyway, and the point is to try
to discover the disk that the system booted from so by definition it
must have GRUB there if it's to be valid.

>  * (Maybe) we could add an option for grub-pc to always grub-install
>to *all* the BIOS-visible disks? Yes, I know there's a potential
>for breakage there with multi-boot systems. Maybe only do this on
>systems where os-prober has not found anything but the Debian
>installation?

One concern I have is filtering out things like optical drives, which
are BIOS-visible but not sensible grub-install targets.  I'm also
slightly reluctant to add more invocations of os-prober while it's as
slow as it can sometimes be.  I do see the utility of this though.

>  * If we do add the code to scan boot sectors, maybe check all the
>BIOS-visible disks and flag any that look like they have GRUB, but
>are not our version? (Not sure how feasible this is without
>digging!)

Unfortunately I believe this to be essentially infeasible.  As an
illustration, this is the scan code which exists in the current postinst
to support migration from GRUB Legacy, and believe me I didn't resort to
this horror before trying to find more sensible alternatives:

  # In order to determine whether we accidentally ran grub-install without
  # upgrade-from-grub-legacy on versions older than 1.98+20100617-1, we need
  # to be able to scan a disk to determine whether GRUB 2 was installed in its
  # boot sector.  This is specific to i386-pc (but that's the only platform
  # where we need it).
  scan_grub2()
  {
if ! dd if="$1" bs=512 count=1 2>/dev/null | grep -aq GRUB; then
  # No version of GRUB is installed.
  return 1
fi
  
# The GRUB boot sector always starts with a JMP instruction.
initial_jmp="$(dd if="$1" bs=2 count=1 2>/dev/null | od -Ax -tx1 | \
   head -n1 | cut -d' ' -f2,3)"
[ "$initial_jmp" ] || return 1
initial_jmp_opcode="${initial_jmp%% *}"
[ "$initial_jmp_opcode" = eb ] || return 1
initial_jmp_operand="${initial_jmp#* }"
case $initial_jmp_operand in
  47|4b|4c|63)
# I believe this covers all versions of GRUB 2 up to the package
# version where we gained a more explicit mechanism.  GRUB Legacy
# always had 48 here.
return 0
  ;;
esac
  
return 1
  }

The actual package version does get embedded in the boot loader, but
only in the "normal" module, not anywhere that could be usefully
discovered by a scan.  Otherwise the best we could do would basically be
a big list of signatures, which I'm not enthusiastic about.

>  * For UEFI, I'd love to switch to using the monolithic GRUB image
>even for non-signed use. It makes a lot of the issues go away if
>~all the modules necessary for boot are always built-in.

I think I agree, though we should take that to a separate bug; I'd like
to keep this one for the BIOS situation.

>  * Finally, we should also stop using debconf as a registry like we
>are. It's annoying the DSA folks (at least). By all means use
>debconf to help manage things, but we should be storing the lasting
>config in a config file that people can edit. We already store some
>of our stuff in /etc/default/grub, let's push more of our config
>there?

Agreed in general terms; this has been on my to-do list for a long time.
Of course we need to consider the migration path carefully.  In terms of
specifics, I'm not sure I want to extend /etc/default/grub for this,
though; that has configuration file management issues, and generally I
don't really want to overload the upstream grub-mkconfig configuration
file with packaging-specific things for grub-install.  I'd be inclined
to go for /etc/default/grub-pc instead, or maybe something under
/etc/grub/.

-- 
Colin Watson (he/him)  [cjwat...@debian.org]

Bug#966657: json-c: please make the build reproducible

[Chris Lamb]

Source: json-c
Version: 0.15-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: buildpath
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0] we noticed that
json-c could not be built reproducibly.

This is because it used the full, absolute path name as an (sanitised)
input to a filename, resulting in the binary package containing

  
/usr/share/doc/libjson-c-dev/html/md__build_1st_json-c-0_815_issues_closed_for_0_813.html
^^
or

  
/usr/share/doc/libjson-c-dev/html/md__build_2_json-c-0_815_2nd_issues_closed_for_0_813.html


(etc. etc.)


Patch attached.

 [0] https://reproducible-builds.org/


Regards,

--
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   ` a/debian/patches/0004-reproducible-build.patch  1970-01-01 
01:00:00.0 +0100
--- b/debian/patches/0004-reproducible-build.patch  2020-08-01 
11:08:07.910487246 +0100
@@ -0,0 +1,15 @@
+Description: Make the build reproducible
+Author: Chris Lamb 
+Last-Update: 2020-08-01
+
+--- json-c-0.15.orig/doc/Doxyfile.in
 json-c-0.15/doc/Doxyfile.in
+@@ -152,7 +152,7 @@ FULL_PATH_NAMES= NO
+ # will be relative from the directory where doxygen is started.
+ # This tag requires that the tag FULL_PATH_NAMES is set to YES.
+ 
+-STRIP_FROM_PATH=
++STRIP_FROM_PATH= @CMAKE_SOURCE_DIR@
+ 
+ # The STRIP_FROM_INC_PATH tag can be used to strip a user-defined part of the
+ # path mentioned in the documentation of a class, which tells the reader which
--- a/debian/patches/series 2020-08-01 11:03:18.119435139 +0100
--- b/debian/patches/series 2020-08-01 11:05:35.281217833 +0100
@@ -2,3 +2,4 @@
 0002-doxygen.patch
 0001-CMakeLists-use-GNUInstallDirs.patch
 #608.patch
+0004-reproducible-build.patch
--- a/doc/Doxyfile.in   2020-08-01 11:03:18.119435139 +0100
--- b/doc/Doxyfile.in   2020-08-01 11:08:06.946479160 +0100
@@ -152,7 +152,7 @@
 # will be relative from the directory where doxygen is started.
 # This tag requires that the tag FULL_PATH_NAMES is set to YES.
 
-STRIP_FROM_PATH=
+STRIP_FROM_PATH= @CMAKE_SOURCE_DIR@
 
 # The STRIP_FROM_INC_PATH tag can be used to strip a user-defined part of the
 # path mentioned in the documentation of a class, which tells the reader which

Bug#965057: transition: libgc

[Sebastian Ramacher]

Control: block -1 by 966300 966301

On 2020-07-21 23:07:09 +0200, Sebastian Ramacher wrote:
> Control: forwarded -1 
> https://release.debian.org/transitions/html/auto-libgc.html
> Control: tags -1 + confirmed
> 
> On 2020-07-15 12:14:06 +0200, Matthias Klose wrote:
> > Package: release.debian.org
> > Severity: normal
> > User: release.debian@packages.debian.org
> > Usertags: transition
> > 
> > Packages build ok with the libgc from experimental, except for guile. Filed
> > patches to fix the guile builds with make 4.3, however guile-2.0 fails 
> > tests on
> > amd64.  guile-2.0 could be removed from testing, only has three rdeps on 
> > leaf
> > packages.
> 
> guile-2.0 has no reverse dependencies in testing anymore, so I've added
> a removal hint. Are you going to take care of guile-2.2?
> 
> Please go ahead with the upload to unstable.

This transition is currently blocked by build failures of guile-2.2 and
guile-3.0 on ppc64el.

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#966657: json-c: please make the build reproducible

[Chris Lamb]

forwarded 966657 https://github.com/json-c/json-c/pull/653
thanks

I've forwarded this upstream here:

  https://github.com/json-c/json-c/pull/653


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

Bug#956975: Removing acfax (acfax: ftbfs with GCC-10)

[Christoph Berg]

Control: clone -1 -2
Control: reassign -2 ftp.debian.org
Control: severity -2 normal
Control: retitle -2 RM: acfax -- RoM: obsolete and buggy

Re: To 956...@bugs.debian.org
> I believe acfax has long reached the end of its usefulness. The build
> log is full of ugly warnings, the last upstream release was in 1998,
> the Debian release number has reached an impressive -17, and the
> program doesn't even start because it wants to open /dev/dsp which is
> long gone.
> 
> I suspect qsstv is a modern replacement, but I'm not an active
> fax/sstv user so can't say for sure.
> 
> I'll request removal from unstable shortly if I don't get any
> objections.

Doing so now: Please remove acfax from unstable.

Thanks,
Christoph

Bug#966665: ITP: node-enquirer -- Stylish cli prompts that are user-friendly, intuitive and easy to create

[Kartik Kulkarni]

Package: wnpp
Severity: wishlist
Owner: Kartik Kulkarni 
X-Debbugs-CC: d...@jones.dk

* Package name: node-enquirer
  Version : 2.3.6
  Upstream Author : Jon Schlinkert (https://github.com/jonschlinkert)
* URL : https://github.com/enquirer/enquirer
* License : Expat
  Programming Lang: JavaScript
  Description : Stylish cli prompts that are user-friendly,
intuitive and easy to create

  Enquirer is fast, easy to use, and lightweight
  for small projects, while also being powerful
  and customizable enough for the most advanced use cases.
  .
  It is easy to implement and advanced features can be
  added using Pluggable plugins.
  .
  Node.js is an event-based server-side JavaScript engine.

  This package is a transitive dependency of eslint and needs to be
  packaged for the packaging of eslint.
  .
  This package will be maintained in the javascript team.

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

[Job Bautista]

Just in case someone wonders if this is being worked on, MZ uploaded a 0.9.12-1 
package at mentors.debian.net[1]. He's just waiting for a sponsor to upload it 
to the main archive. If you want, you can dget the dsc file and build the 
package yourself.

Regards,

Job Bautista

[1]: https://mentors.debian.net/package/endless-sky/

signature.asc
Description: OpenPGP digital signature

Bug#966297: UDD: mentors.debian.net schema change

[Baptiste BEAUPLAT]

On 8/1/20 9:01 AM, Lucas Nussbaum wrote:
> Hi Baptiste,
> 
> I think that it would be better if mentors.d.n would provide a JSON
> export of its data that it useful for UDD.

Would a JSON rest api work?

UDD could fetch something like https://mentors.debian.net/api/uploads/
and retrieve all information needed.

> Regarding data that should be replicated in UDD, I would prefer
> something simpler that is enough, typically for DMD, to notify that
> there's a new version waiting, but that still requires going to
> mentors.d.n for details. I wonder if we should have more than one table,
> that just describes the last upload for a given source or (source,user)
> (it's not clear to me if several users can simultaneously upload
> competing versions of the same source package).

Yes, several users can upload the same package using different version
and distributions.

From what I can see in the DMD page, it fetches from UDD's tables:

- package name
- version
- distribution
- uploaded date

From that, distribution is actually unused. So fetching the list of all
uploads and storing that into a single table sould be sufficient.

-- 
Baptiste BEAUPLAT - lyknode



signature.asc
Description: OpenPGP digital signature

Bug#966575: grub-pc: error: symbol `grub_calloc' not found.

[Colin Watson]

On Sat, Aug 01, 2020 at 01:32:33PM +0200, Miklos Quartus wrote:
> I am reporting this bug here

Please could you file this as a *new* bug report, *not* as a followup to
#966575 which I would much rather keep for just the more common BIOS
case?  Ideally you would do this by typing "reportbug grub-efi-amd64"
and following the prompts from there; this will automatically include
some more information about your system that you haven't yet provided.

If reportbug doesn't work for some reason, you can send email to
sub...@bugs.debian.org with this paragraph at the top of your email:

Package: grub-efi-amd64
Version: 2.02+dfsg1-20+deb10u2

... and we can ask for more information from there.

-- 
Colin Watson (he/him)  [cjwat...@debian.org]