Bug#946855: Therion still fails on old proj dependency; loch fixed in upstream

[Benedikt Hallinger]

Thank you Olly for that insights.
In this case applying the patch would be good because currently the package 
therion is broken if one uses the „cs“ command.

> Am 17.12.2019 um 02:55 schrieb Olly Betts :
> 
>> On Mon, Dec 16, 2019 at 04:33:58PM +0100, Benedikt Hallinger wrote:
>> Hello, i just wanted to inform you that therion still fails with the proj 
>> issue[1] on my system when installing from the new package 5.4.4ds1-4.
>> 
>> Also the loch glx issue[2] was fixed recently in upstream (Olly did a patch 
>> on this in the last deb package which is obsoleted by Stachos upstream fix.
>> 
>> It would be nice to recompile the package including the latest
>> upstream sources, thank you!
> 
> We usually update to the latest upstream sources only when upstream make
> a release (since that's a strong signal that it's "ready").  If we start
> pulling arbitrary snapshots from upstream git where we have to worry
> about there being changes which might not yet be ready, so in between
> we would usually apply a targetted fix for a problem.
> 
> So we can probably apply the tiny patch from
> https://github.com/therion/therion/pull/151 but it would really make
> sense for upstream to make an actual release.
> 
> Cheers,
>Olly

Bug#946718: gbrowse: autopkgtest regression: Can't call method "features" on an undefined value

[gregor herrmann]

On Tue, 17 Dec 2019 08:35:40 +0100, Andreas Tille wrote:

> > https://ci.debian.net/data/autopkgtest/testing/amd64/g/gbrowse/3555081/log.gz
> > 
> > t/01.yeast.t ..
> > 1..7
> > not ok 1
> > # Failed test 1 in t/01.yeast.t at line 29
> > Can't call method "features" on an undefined value at t/01.yeast.t line 31.
> > Dubious, test returned 25 (wstat 6400, 0x1900)
> > Failed 7/7 subtests
> 
> The latest test log is:

> autopkgtest [15:25:16]: test autodep8-perl-recommends: 
> ---]
> autopkgtest [15:25:16]: test autodep8-perl-recommends:  - - - - - - - - - - 
> results - - - - - - - - - -
> autodep8-perl-recommends PASS (superficial)
> autopkgtest [15:25:16]:  summary
> autodep8-perl-build-deps FAIL non-zero exit status 1
> autodep8-perlPASS (superficial)
> autodep8-perl-recommends PASS (superficial)
> ...
> 
> 
> So the above issue seems to be solved.  However, the test is failing
> anyway - but I have no idea why?

Not sure which log you are referring to with "latest test log" as I
see the failure in all of them I found at ci.d.n. - Please note that
you are quoting only the last of the three test sections
(autodep8-perl-recommends), and the failure in the smoke test happens
in autodep8-perl-build-deps.

Anyway, looking at 
https://salsa.debian.org/med-team/gbrowse/blob/master/t/01.yeast.t#L26
my guess is that the tests need the sample_data directory; which is
there during build but not by default during autopkgtests because
there only t/ is copied to a new temporary directory.

What I would try (can't test right now) is:
- mkdir -p debian/tests/pkg-perl
- $EDITOR debian/tests/pkg-perl/smoke-files with:
  t/
  sample_data/

(Cf. https://perl-team.pages.debian.net/autopkgtest.html#smoke )


Hope this helps, happy to take a closer look in the evening.


Cheers,
gregor
  

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   BOFH excuse #352:  The cables are not the same length. 

Bug#936798: Please port KisSplice to Python3 (Was: Bug#936798: kissplice: Python2 removal in sid/bullseye)

[Andreas Tille]

On Wed, Oct 09, 2019 at 08:06:27AM +0200, Andreas Tille wrote:
> 
> > When would be the deadline for updating our debian KisSplice package before 
> > removal ?
> 
> There is no actual date.  Debian 11 will be released in 2021 so the
> current bug is not yet release critical.  You will be on the safe side
> if you get out KisSplice at the end of this year not only from a
> Debian point of view but also in general for other users who do not
> might want to run unsupported software like Python2.

The Debian Med team is currently an Advent bug squashing party.  You could help
us closing as much as possible bugs if you would be able to release before
Christmas. ;-)

Kind regards

 Andreas.

-- 
http://fam-tille.de

Bug#946718: gbrowse: autopkgtest regression: Can't call method "features" on an undefined value

[Andreas Tille]

Control: tags -1 help


Hi,

On Sat, Dec 14, 2019 at 04:16:36PM +0100, Paul Gevers wrote:
> [1] https://qa.debian.org/excuses.php?package=gbrowse
> 
> https://ci.debian.net/data/autopkgtest/testing/amd64/g/gbrowse/3555081/log.gz
> 
> t/01.yeast.t ..
> 1..7
> not ok 1
> # Failed test 1 in t/01.yeast.t at line 29
> Can't call method "features" on an undefined value at t/01.yeast.t line 31.
> Dubious, test returned 25 (wstat 6400, 0x1900)
> Failed 7/7 subtests

The latest test log is:

...
autopkgtest [15:25:15]: test autodep8-perl-recommends: 
/usr/share/pkg-perl-autopkgtest/runner runtime-deps-and-recommends
autopkgtest [15:25:15]: test autodep8-perl-recommends: [---
/usr/share/pkg-perl-autopkgtest/runtime-deps-and-recommends.d/syntax.t .. 
1..12
ok 1 - Package gbrowse is known to dpkg
ok 2 - Got status information for package gbrowse
ok 3 # skip gbrowse has Suggestions and no explicit skip list
ok 4 # skip gbrowse has Suggestions and no explicit skip list
ok 5 - Package gbrowse-data is known to dpkg
ok 6 - Got status information for package gbrowse-data
ok 7 - Got file list for package gbrowse-data
ok 8 # skip no perl modules to test in gbrowse-data
ok 9 - Package gbrowse-calign is known to dpkg
ok 10 - Got status information for package gbrowse-calign
ok 11 - Got file list for package gbrowse-calign
# Subtest: all modules in gbrowse-calign pass the syntax check
1..1
ok 1 - /usr/bin/perl -wc 
/usr/lib/x86_64-linux-gnu/perl5/5.30/Bio/Graphics/Browser2/CAlign.pm exited 
successfully
ok 12 - all modules in gbrowse-calign pass the syntax check
ok
All tests successful.
Files=1, Tests=12,  0 wallclock secs ( 0.02 usr  0.00 sys +  0.11 cusr  0.04 
csys =  0.17 CPU)
Result: PASS
autopkgtest [15:25:16]: test autodep8-perl-recommends: ---]
autopkgtest [15:25:16]: test autodep8-perl-recommends:  - - - - - - - - - - 
results - - - - - - - - - -
autodep8-perl-recommends PASS (superficial)
autopkgtest [15:25:16]:  summary
autodep8-perl-build-deps FAIL non-zero exit status 1
autodep8-perlPASS (superficial)
autodep8-perl-recommends PASS (superficial)
...


So the above issue seems to be solved.  However, the test is failing
anyway - but I have no idea why?

Any hint?

Kind regards

   Andreas.


-- 
http://fam-tille.de

Bug#909740: I am guessing #909740 is what is stopping from having a libsdl2-mixer-dev transition

[shirish शिरीष]

Hi all,

Please CC me when answering this mail, thank you.

I have been trying for sometime now to understand why libsdl2-mixer
isn't the default. I tried various things to find about it. For e.g.
the multimedia mailing lists [1] but as it tracks not just sdl2 but
various other multimedia packages so that didn't work. I tried
transitions [2] but even in that big list of planned transitions it
isn't mentioned anywhere. I then tried the wiki but there is no page
for either SDL or libsdl or anything but only an old document from
2012 [3] if the wiki is to be believed, maybe that needs to go a
massive change as well. The only thing which made any sense was this
bug which I tracked from the pkg-sdl-maintainers list [4] .

I also tried to use two methods to see which all packages depend upon
libsdl-mixer1.2 to see which will give me the results.

The first one I tried was -

$ aptitude why libsdl-mixer1.2

This gave so many packages I didn't know what to make of it.

Even apt-rdepends -b libsdl-mixer-1.2 gives so many options seems it
will be a long haul to do anything like that :(

1. https://lists.debian.org/debian-multimedia/2019/
2. https://release.debian.org/transitions/
3. https://wiki.debian.org/Teams/DebianSdlGroup
4. https://alioth-lists.debian.net/pipermail/pkg-sdl-maintainers/

-- 
  Regards,
  Shirish Agarwal  शिरीष अग्रवाल
  My quotes in this email licensed under CC 3.0
http://creativecommons.org/licenses/by-nc/3.0/
http://flossexperiences.wordpress.com

E493 D466 6D67 59F5 1FD0 930F 870E 9A5B 5869 609C

Bug#936270: calibre: plugins are now being ported to python3

[Norbert Preining]

Hi Eli,

> A little over an hour ago, Kovid has released Windows/Linux/macOS binary
> builds of a python3 version of calibre, and alerted the plugin developer
> community that it is time to start porting. Watch this space for updates:

Thanks, that are great news!

Best

Norbert

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

Bug#936270: calibre: plugins are now being ported to python3

[Eli Schwartz]

A little over an hour ago, Kovid has released Windows/Linux/macOS binary
builds of a python3 version of calibre, and alerted the plugin developer
community that it is time to start porting. Watch this space for updates:

https://www.mobileread.com/forums/showthread.php?t=325721

-- 
Eli Schwartz
Arch Linux Bug Wrangler and Trusted User



signature.asc
Description: OpenPGP digital signature

Bug#878599: git: [PATCH] Ship git-credential-libsecret

[Ville Skyttä]

On Tue, 17 Dec 2019 at 03:23, Jonathan Nieder  wrote:
> That said, I'd still welcome a git-libsecret (or git-secretservice)
> package, just like you're hinting.  Patches welcome.

Adjusted patch attached. It's untested and I'm not that familiar with
building Debian packages, so approach with care. I hope someone will
take it to completion from here.
From 00cbebce522ca7959aab62946796250d9794a1e0 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Ville=20Skytt=C3=A4?= 
Date: Tue, 17 Dec 2019 07:52:37 +0200
Subject: [PATCH] Ship git-libsecret

---
 debian/control   | 22 +++---
 debian/git-libsecret.install |  1 +
 debian/rules |  6 +-
 3 files changed, 25 insertions(+), 4 deletions(-)
 create mode 100644 debian/git-libsecret.install

diff --git a/debian/control b/debian/control
index e6be01c90a..716bda9e5f 100644
--- a/debian/control
+++ b/debian/control
@@ -5,7 +5,7 @@ Maintainer: Gerrit Pape 
 Uploaders: Jonathan Nieder , Anders Kaseorg 
 Build-Depends: libz-dev, gettext,
  libpcre2-dev | libpcre3-dev,
- libcurl4-gnutls-dev, libexpat1-dev,
+ libcurl4-gnutls-dev, libexpat1-dev, libsecret-1-dev,
  subversion, libsvn-perl, libyaml-perl,
  tcl, python,
  libhttp-date-perl | libtime-parsedate-perl,
@@ -33,7 +33,7 @@ Pre-Depends: ${misc:Pre-Depends}
 Recommends: ca-certificates, patch, less, ssh-client
 Suggests: gettext-base, git-daemon-run | git-daemon-sysvinit,
  git-doc, git-el, git-email, git-gui, gitk, gitweb,
- git-cvs, git-mediawiki, git-svn
+ git-cvs, git-mediawiki, git-svn, git-libsecret
 Replaces: gitweb (<< 1:1.7.4~rc1),
  git-core (<< 1:1.7.0.4-1.)
 Breaks: bash-completion (<< 1:1.90-1), gitweb (<< 1:1.7.4~rc1),
@@ -323,12 +323,28 @@ Description: fast, scalable, distributed revision control system (web interface)
  If libcgi-fast-perl is installed, gitweb can also be run over FastCGI
  (and served by nginx, for example).
 
+Package: git-libsecret
+Architecture: all
+Multi-Arch: foreign
+Depends: ${misc:Depends}, git (>> ${source:Upstream-Version}), git (<< ${source:Upstream-Version}-.)
+Description: fast, scalable, distributed revision control system (libsecret credential helper)
+ Git is popular version control system designed to handle very large
+ projects with speed and efficiency; it is used for many high profile
+ open source projects, most notably the Linux kernel.
+ .
+ Git falls in the category of distributed source code management tools.
+ Every Git working directory is a full-fledged repository with full
+ revision tracking capabilities, not dependent on network access or a
+ central server.
+ .
+ This package provides a helper for storing credentials using libsecret.
+
 Package: git-all
 Architecture: all
 Multi-Arch: foreign
 Depends: ${misc:Depends}, git (>> ${source:Upstream-Version}), git (<< ${source:Upstream-Version}-.),
  git-doc, git-el, git-cvs, git-mediawiki, git-svn,
- git-email, git-gui, gitk, gitweb
+ git-email, git-gui, gitk, gitweb, git-libsecret
 Recommends: git-daemon-run | git-daemon-sysvinit
 Description: fast, scalable, distributed revision control system (all subpackages)
  Git is popular version control system designed to handle very large
diff --git a/debian/git-libsecret.install b/debian/git-libsecret.install
new file mode 100644
index 00..d61ca822bc
--- /dev/null
+++ b/debian/git-libsecret.install
@@ -0,0 +1 @@
+debian/tmp/usr/lib/git-core/git-credential-libsecret* usr/lib/git-core
diff --git a/debian/rules b/debian/rules
index d5d81608d8..74b9fb82a1 100755
--- a/debian/rules
+++ b/debian/rules
@@ -63,6 +63,7 @@ build-stamp:
 override_dh_auto_build-arch: build-stamp
 	$(MAKE) -C contrib/subtree all $(OPTS)
 	ln -s contrib/subtree/git-subtree
+	$(MAKE) -C contrib/credential/libsecret all $(OPTS)
 
 override_dh_auto_test-arch:
 	test -z '$(TEST)' || \
@@ -90,6 +91,7 @@ override_dh_auto_clean:
 	$(MAKE) -C contrib/subtree clean $(OPTS)
 	$(MAKE) clean $(OPTS)
 	rm -f git-subtree
+	$(MAKE) -C contrib/credential/libsecret clean $(OPTS)
 
 override_dh_clean:
 	dh_clean -Xmailinfo.c.orig
@@ -98,11 +100,13 @@ override_dh_auto_install-arch:
 	# git
 	DESTDIR='$(GIT)' $(MAKE) install $(OPTS)
 	DESTDIR='$(GIT)' $(MAKE) -C contrib/subtree install $(OPTS)
+	install -m0755 contrib/credential/libsecret/git-credential-libsecret \
+	 '$(GIT)'/usr/lib/git-core/
 	install -d -m0755 '$(GIT)'/var/lib/git
 	rm -rf '$(GIT)'/usr/share/man
 	# don't include arch, cvs, p4, svn, email, gui tools, and gitk program
 	for i in git-archimport git-cvs git-p4 git-svn git-send-email \
-	 git-gui git-citool; do \
+	 git-gui git-citool git-credential-libsecret; do \
 	  rm -f '$(GIT)'/usr/lib/git-core/$$i*; \
 	done
 	rm -f '$(GIT)'/usr/bin/git-cvsserver
-- 
2.17.1

Bug#946872: thunderbird: Changing language to Swedish causes lightning xml parsing error

[Carsten Schoenert]

Hello Jonatan,

I've problems to readjust your described behavior.

Den 12/16/19 kl. 10:01 PM, skrev Jonatan Nyberg:
> Steps to reproduce:
> 
> Install thunderbird and lightning

Given by installed packages thunderbird and lightning.

> Open Thunderbird
> Open Options

I don't know what menu entry do you mean here? There is no menu option
'Options', I only know of 'Edit -> Preferences'.
Or do you mean 'Tools -> Add-Ons#?

> Change Language to Swedish

If you have installed the package 'thunderbird-sv-se' there is nothing
to active or to be selected within the Thunderbird menus to beeing able
to use this locale.

> Apply and restart
> 
> I am using Thinderbird with Debian Sid and the addon Lightning
> 
> Actual results:
> 
> Thunderbird didn't work properly, the status bar took up most of the
> screen and hade a lot of code in it.

I don't see any issues if I start Thunderbird from the CLI by
'LANG=sv-se thunderbird' to force the usage of Swedish locale. I've
written this email from a so started Thunderbird.

> Expected results:
> 
> The language to change to Swedish and work properly

Do you tried to start with some clean environment by deactivating all
Add-ons? Please note some hints written to the Debian Wiki how to check
things on your side before thinking about raising up an bug report.

https://wiki.debian.org/Thunderbird#Bug_Reporting_.2F_Issues

-- 
Regards
Carsten Schoenert

Bug#878599: git: [PATCH] Ship git-credential-libsecret

[Josh Triplett]

On December 16, 2019 3:17:28 PM PST, Jonathan Nieder  wrote:
>Hi,
>
>Josh Triplett wrote:
>
>> I would love to see git-credential-libsecret packaged.
>>
>> This patch would ship git-credential-libsecret in the git package,
>which
>> would add libsecret and its dependencies to the dependencies of git.
>> Since many people use the git package on servers, that might not be
>> welcome. (I personally wouldn't object, as those dependencies seem
>quite
>> small.)
>
>It seems you forgot to attach the patch.
>
>> It might also make sense to generate a separate
>git-credential-libsecret
>> binary package containing this binary.
>
>Yes, that's what I'd prefer: just "git-libsecret", in case we want to
>package any other libsecret-related helpers.  Or even
>"git-secretservice" or "git-gnome".
>
>Thanks for your work on this.
>
>Excited,
>Jonathan

I was responding to the previous patch provided in the bug, and discussing the 
alternate approach of a second package.

Bug#932208: Bug#946858: ruby-grib: Should this package be removed?

[Youhei SASAKI]

hi,

I'll upload ruby-grib ver. 0.4.0-3, depends eccodes instead of grib-api.

Thanks.

On Tue, 17 Dec 2019 03:07:37 +0900,
Boyuan Yang  wrote:
> 
> [1  ]
> Source: ruby-grib
> Severity: serious
> Version: 0.4.0-2
> X-Debbugs-CC: uwab...@gfd-dennou.org
> 
> Dear ruby-grib maintainers,
> 
> According to https://bugs.debian.org/932208 , one of the dependencies of ruby-
> grib, grib-api, will be removed from Debian very soon. In this case, is the
> package ruby-grib still relavent? Should we just have it removed from Debian?
> Please evaluate the current status. If a removal is indeed necessary, please
> consider filing a removal bug against FTP Masters.
> 
> Thanks and looking forward to your reply.

Bug#910822: golang-docker-credential-helpers: headless gnome-keyring failure

[Nye Liu]

On 12/16/2019 3:32 AM, Arnaud Rebillout wrote:

Actually, what is weird is that docker tries to use the secret service 
backend, even though it's not instructed to do so.


From the documentation at 
https://docs.docker.com/engine/reference/commandline/login/#credentials-store


You need to specify the credentials store in 
|$HOME/.docker/config.json| to tell the docker engine to use it. The 
value of the config property should be the suffix of the program to 
use (i.e. everything after |docker-credential-|).


So installing golang-docker-credential-helpers shouldn't have any 
consequence, until you add `"credsStore": "secretservice"` to 
`~/.docker/config.json`.


But what I observe is different: from the moment the credential 
helpers are installed, docker tries to use it, and fails of course if 
there's no display.


Am I missing something here? Should we open a bug upstream regarding 
this behavior?



Absolutely, yes, you should, and please reference it in issue #105


Please fix the dependencies for this package.

https://github.com/docker/docker-credential-helpers/issues/105#issuecomment-561573736


In this thread, some users suggest to add `pass` as a dependency of 
the golang-docker-credential-helpers.


I'm not sure it will work, because if you look at the code in 
docker-cli, at cli/config/credentials/default_store_linux.go, you will 
see that docker gives preference to pass over libsecret. I'm afraid 
that if we do that, we break all existing users that rely on libsecret.


Well, unless docker behaved as documented, but apparently it's more 
complicated, so I'm a bit reluctant. Adding "Suggests: pass" would be 
fine though...


It would be wonderful if debian and docker devs could work together to 
fix this for real, because the upstream docker behavior is clearly 
broken regardless, and I was unable to convince docker devs otherwise.

Bug#946855: Therion still fails on old proj dependency; loch fixed in upstream

[Olly Betts]

On Mon, Dec 16, 2019 at 04:33:58PM +0100, Benedikt Hallinger wrote:
> Hello, i just wanted to inform you that therion still fails with the proj 
> issue[1] on my system when installing from the new package 5.4.4ds1-4.
> 
> Also the loch glx issue[2] was fixed recently in upstream (Olly did a patch 
> on this in the last deb package which is obsoleted by Stachos upstream fix.
> 
> It would be nice to recompile the package including the latest
> upstream sources, thank you!

We usually update to the latest upstream sources only when upstream make
a release (since that's a strong signal that it's "ready").  If we start
pulling arbitrary snapshots from upstream git where we have to worry
about there being changes which might not yet be ready, so in between
we would usually apply a targetted fix for a problem.

So we can probably apply the tiny patch from
https://github.com/therion/therion/pull/151 but it would really make
sense for upstream to make an actual release.

Cheers,
Olly

Bug#946883: lightdm visits all home directories

[Chubb, Peter (Data61, Kensington NSW)]

Package: lightdm
Version: 1.26.0-6+b1
Severity: normal

Dear Maintainer,

We have many machines that automount home directories on demand; user
authentication is held in LDAP. lightdm as part of its operations seems to 
visit (and therefore cause an expensive and slow NFS mount) the home directory
of every user in LDAP, instead of only the user logging in.

This slows things down a lot for logging into a machine.

I'd expect lightdm not to touch any directory other than its own 
(for logging and config), and the 
currently logging in user's home directory.

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

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

Versions of packages lightdm depends on:
ii  adduser3.118
ii  dbus   1.12.16-2
ii  debconf [debconf-2.0]  1.5.73
ii  libaudit1  1:2.8.5-2+b1
ii  libc6  2.29-3
ii  libgcrypt201.8.5-3
ii  libglib2.0-0   2.62.3-2
ii  libpam-systemd [logind]244-3
ii  libpam0g   1.3.1-5
ii  libxcb11.13.1-2
ii  libxdmcp6  1:1.1.2-3
ii  lightdm-gtk-greeter [lightdm-greeter]  2.0.6-1
ii  lsb-base   11.1.0

Versions of packages lightdm recommends:
ii  xserver-xorg  1:7.7+20

Versions of packages lightdm suggests:
pn  accountsservice  
ii  upower   0.99.11-1
pn  xserver-xephyr   

-- Configuration Files:
/etc/lightdm/lightdm.conf changed [not included]

-- debconf information:
  lightdm/daemon_name: /usr/sbin/lightdm
* shared/default-x-display-manager: lightdm

-- 
Dr Peter Chubb Tel: +61 2 9490 5852  http://ts.data61.csiro.au/
Trustworthy Systems GroupCSIRO's Data61

Bug#921717: RFH: cyrus-imapd -- Cyrus mail system - IMAP support

[Xavier]

Control: retitle -1 RFH: cyrus-imapd -- Cyrus mail system - IMAP support

Hi,

I took over the maintenance of cyrus-imapd. However, I'd like some help
to maintain it.

Cheers,
Xavier

Bug#878599: git: [PATCH] Ship git-credential-libsecret

[Jonathan Nieder]

Josh Triplett wrote:

> I would love to see git-credential-libsecret packaged.
>
> This patch would ship git-credential-libsecret in the git package, which
> would add libsecret and its dependencies to the dependencies of git.
> Since many people use the git package on servers, that might not be
> welcome. (I personally wouldn't object, as those dependencies seem quite
> small.)
>
> It might also make sense to generate a separate git-credential-libsecret
> binary package containing this binary.

Oh!  Now I see what patch you're referring to:
https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=878599;filename=0001-Ship-git-credential-libsecret.patch.gz;msg=5

That said, I'd still welcome a git-libsecret (or git-secretservice)
package, just like you're hinting.  Patches welcome.

Sincerely,
Jonathan

Bug#946882: blk-availability.service: may fail or unmount filesystems too soon

[Rob Leslie]

Package: lvm2
Version: 2.03.02-3
Severity: grave
Justification: causes non-serious data loss

Dear Maintainer,

On systems upgraded from stretch and without the usrmerge package installed,
/sbin/blkdeactivate (ExecStop= of blk-availability.service) gives the
following error during system shutdown:

blkdeactivate[12003]: /sbin/blkdeactivate: line 345: /bin/sort: No such 
file or directory

Despite the error, I have not observed any adverse behavior.

However, on new installations or systems upgraded from stretch WITH the
usrmerge package installed, the error does not occur. Instead, filesystems
may be unmounted prematurely, for example those given as RequiresMountsFor=
in other units. I have observed data loss in this case where a required
mount was unmounted before the unit requiring it had properly saved its state
during shutdown.

I am not sure the best course of action to resolve this latter problem. Is it
necessary for blkdeactivate to be unmounting filesystems? Could the dependency
ordering be adjusted to avoid unmounting filesystems too soon?


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

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

Versions of packages lvm2 depends on:
ii  dmeventd  2:1.02.155-3
ii  dmsetup   2:1.02.155-3
ii  libaio1   0.3.112-3
ii  libblkid1 2.33.1-0.1
ii  libc6 2.28-10
ii  libdevmapper-event1.02.1  2:1.02.155-3
ii  libdevmapper1.02.12:1.02.155-3
ii  libreadline5  5.2+dfsg-3+b13
ii  libselinux1   2.8-1+b1
ii  libsystemd0   241-7~deb10u2
ii  libudev1  241-7~deb10u2
ii  lsb-base  10.2019051400

Versions of packages lvm2 recommends:
ii  thin-provisioning-tools  0.7.6-2.1

lvm2 suggests no packages.

-- Configuration Files:
/etc/lvm/lvm.conf changed [not included]

-- no debconf information

Bug#946879: git: please build package with libsecret credential helper

[Jonathan Nieder]

forcemerge 878599 946879
quit

Hi,

brian m. carlson wrote:

> It would be great if the libsecret credential helper could be built in
> its own package so that folks could easily use it.

Thanks!  I agree.

Bug#946837: vagrant: Does not work with virtualbox 6.1 from unstable

[Jeremy L. Gaddis]

A fix has been committed upstream:

  https://github.com/hashicorp/vagrant/commit/20ccf46

Bug#946881: translate-docformat: Please remove translate-docformat from Debian, package of questionable value

[Dimitri John Ledkov]

Package: translate-docformat
Version: 0.6-5
Severity: serious

Dear Maintainer,

This package is a trivial bash script, that mixes in together a
kitchensync of obsolete, bit-roted calls to web-browsers and various
xmlish/tex tools. It doesn't bring any additional value over using
existing tools directly, or better using their modern equivalents.

sgmltools-lite is orphaned and abandoned upstream and is to be removed
from Debian. And instead of porting this "app", I think it should go
as well.

No reverse dependencies, or build dependencies.

Regards,

Dimitri.

Bug#946880: newt: Please switch from sgmtools-lite to docbook-utils

[Dimitri John Ledkov]

Source: newt
Version: 0.52.21-3
Severity: serious

Dear Maintainer,

sgmtools-lite is orphaned, abandoned upstream, python2 application to
be removed from Debian shortly. newt is one of the remaining packages
using it.

Please switch to docbook-utils and upload immediately to unstable.
Patch is attached.

Regards,

Dimitri.
diff -Nru newt-0.52.21/debian/changelog newt-0.52.21/debian/changelog
--- newt-0.52.21/debian/changelog   2019-09-01 16:59:14.0 +0100
+++ newt-0.52.21/debian/changelog   2019-12-17 00:39:20.0 +
@@ -1,3 +1,10 @@
+newt (0.52.21-3.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Switch from orphaned sgmltools-lite to docbook-utils.
+
+ -- Dimitri John Ledkov   Tue, 17 Dec 2019 00:39:20 +
+
 newt (0.52.21-3) unstable; urgency=medium
 
   * Move to Standards-Version: 4.4.0
diff -Nru newt-0.52.21/debian/control newt-0.52.21/debian/control
--- newt-0.52.21/debian/control 2019-09-01 16:59:14.0 +0100
+++ newt-0.52.21/debian/control 2019-12-17 00:39:09.0 +
@@ -7,7 +7,7 @@
 Standards-Version: 4.4.0
 Homepage: https://pagure.io/newt
 Build-Depends: debhelper-compat (= 12),
- sgmltools-lite, 
+ docbook-utils, 
  automake (>= 1.16),
  libslang2-dev  (>=2.0.4-2), 
  libpopt-dev,
diff -Nru newt-0.52.21/debian/libnewt-dev.doc-base 
newt-0.52.21/debian/libnewt-dev.doc-base
--- newt-0.52.21/debian/libnewt-dev.doc-base2019-09-01 16:59:14.0 
+0100
+++ newt-0.52.21/debian/libnewt-dev.doc-base2019-12-17 00:38:39.0 
+
@@ -1,4 +1,4 @@
-build-tree/*/tutorial/t1.html
+build-tree/*/tutorial/index.html
 build-tree/*/tutorial/x100.html
 build-tree/*/tutorial/x197.html  
 build-tree/*/tutorial/x223.html
diff -Nru newt-0.52.21/debian/rules newt-0.52.21/debian/rules
--- newt-0.52.21/debian/rules   2019-09-01 16:59:14.0 +0100
+++ newt-0.52.21/debian/rules   2019-12-17 00:37:24.0 +
@@ -53,7 +53,7 @@
 
 override_dh_auto_build:
dh_auto_build
-   sgmltools --backend html tutorial.sgml
+   docbook2html -o tutorial tutorial.sgml
ar cqv libnewt_pic.a shared/*.o
 
 override_dh_auto_install:

Bug#946576: Mention the word "QR" in the one-line descriptions

[Javier Serrano Polo]

El dc 11 de 12 de 2019 a les 14:25 +0800, 積丹尼 Dan Jacobson va escriure:
> Now that QR codes are becoming more and more important,

ZBar is not only about QR codes.

> Else the user might not even know he has a QR code reader already
> installed, or downloadable.

There are better ways to achieve this.

smime.p7s
Description: S/MIME cryptographic signature

Bug#946879: git: please build package with libsecret credential helper

[brian m. carlson]

Package: git
Version: 1:2.24.1+next.20191209-1
Severity: wishlist

Currently, anyone who wants to store passwords with Git in a secure way
must build their own credential helpers from the files in
/usr/share/doc.  This leads users to use less secure ways of storing
passwords, such as using URLs with passwords in them or using the git
credential-store helper.

It would be great if the libsecret credential helper could be built in
its own package so that folks could easily use it.  The gnome-keyring
one is not required because it implements the libsecret API and so is
redundant.  If you wanted to create a generic package, you could also
add the netrc credential helper, although I believe that's no longer
required with recent versions of libcurl.

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

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

Versions of packages git depends on:
ii  git-man  1:2.24.1+next.20191209-1
ii  libc62.29-6
ii  libcurl3-gnutls  7.67.0-2
ii  liberror-perl0.17028-1
ii  libexpat12.2.9-1
ii  libpcre2-8-0 10.34-7
ii  perl 5.30.0-9
ii  zlib1g   1:1.2.11.dfsg-1+b1

Versions of packages git recommends:
ii  ca-certificates  20190110
ii  less 551-1
ii  openssh-client [ssh-client]  1:8.1p1-2
ii  patch2.7.6-6

Versions of packages git suggests:
ii  gettext-base  0.19.8.1-10
pn  git-cvs   
pn  git-daemon-run | git-daemon-sysvinit  
pn  git-doc   
pn  git-el
ii  git-email 1:2.24.1+next.20191209-1
pn  git-gui   
pn  git-mediawiki 
pn  git-svn   
pn  gitk  
pn  gitweb

-- no debconf information

-- 
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204


signature.asc
Description: PGP signature

Bug#946681: jool: Fix FTBFS with kernel >= 5.4

[Alberto Leiva]

Thank you. I'll have this upstreamed by version 4.0.7, which will
hopefully be released tomorrow.

On Fri, Dec 13, 2019 at 10:24 AM Paolo Pisati
 wrote:
>
> Package: jool
> Version: 4.0.6-1
> Severity: important
> Tags: patch
> User: ubuntu-de...@lists.ubuntu.com
> Usertags: origin-ubuntu focal ubuntu-patch
>
> Dear Maintainer,
>
> In Ubuntu, the attached patch was applied to achieve the following:
>
>   * Linux 5.4 compatibility (LP: #1856185)
>
>
> Thanks for considering the patch.
>
>
> -- System Information:
> Debian Release: buster/sid
>   APT prefers bionic-updates
>   APT policy: (500, 'bionic-updates'), (500, 'bionic-security'), (500, 
> 'bionic-proposed'), (500, 'bionic'), (100, 'bionic-backports')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 4.15.0-73-generic (SMP w/4 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: 
> LC_ALL set to C.UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) (ignored: LC_ALL 
> set to C.UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled

Bug#946829: Added upstream.

[Logan Gunthorpe]

I've also hit this issue.

Bug#946878: /usr/sbin/dovecot: sieve redirect fails with error message : Non-CRLF-terminated header, under CHUNKING: message abandoned

[Bertrand Cherrier]

Package: dovecot-core
Version: 1:2.3.4.1-5+deb10u1
Severity: normal
File: /usr/sbin/dovecot

Dear Maintainer,

After upgrading to buster, when sieve redirect was in action the sender
was vmail, and not the rewritten with SRS sender.
To work around this, the option submission_host = localhost was set in
protocol lmtp
This led to the error (in exim4) :
"Non-CRLF-terminated header, under CHUNKING: message abandoned"
The problem was fixed by upgrading dovecot packages to testing version 2.3.7.2 
with Pigeonhole 0.5.7.2
(This is why at the end of the file you have Versions of packages
dovecot-core 2.3.7.2 and not the buggy version 2.3.4.1)

Please do not hesitate if you need more information, it's my first bug
report !

Regards,

-- Package-specific info:

dovecot configuration
-
# 2.3.4.1 (f79e8e7e4): /etc/dovecot/dovecot.conf
# Pigeonhole version 0.5.4 ()
# OS: Linux 4.19.0-6-amd64 x86_64 Debian 10.2 ext4
# Hostname: hoth.linux.nc
auth_master_user_separator = *
auth_mechanisms = PLAIN LOGIN
dict {
  expire = db:/var/lib/dovecot/expire/expire.db
  quotadict = mysql:/etc/dovecot/dovecot-used-quota.conf
}
first_valid_uid = 5000
last_valid_uid = 5000
listen = *,[::]
log_path = /var/log/dovecot/dovecot.log
mail_debug = yes
mail_gid = 5000
mail_location = maildir:/home/mail/%Ld/%Ln/Maildir
mail_plugins = quota quota_clone
mail_uid = 5000
managesieve_notify_capability = mailto
managesieve_sieve_capability = fileinto reject envelope encoded-character 
vacation subaddress comparator-i;ascii-numeric relational regex imap4flags copy 
include variables body enotify environment mailbox date index ihave duplicate 
mime foreverypart extracttext vacation-seconds editheader vnd.dovecot.report 
imapsieve vnd.dovecot.imapsieve
namespace inbox {
  inbox = yes
  location = 
  mailbox Drafts {
auto = subscribe
special_use = \Drafts
  }
  mailbox Junk {
auto = subscribe
special_use = \Junk
  }
  mailbox Sent {
auto = subscribe
special_use = \Sent
  }
  mailbox Trash {
auto = subscribe
special_use = \Trash
  }
  prefix = 
  type = private
}
passdb {
  args = /etc/dovecot/dovecot-mysql.conf
  driver = sql
}
passdb {
  args = /etc/dovecot/master.password
  driver = passwd-file
  master = yes
}
plugin {
  antispam_backend = pipe
  auth_socket_path = /var/run/dovecot/auth-master
  expire = Trash 7 Trash/* 7 Junk 30
  expire_dict = proxy::expire
  imapsieve_mailbox1_before = file:/home/mail/sieve/global/learn-spam.sieve
  imapsieve_mailbox1_causes = COPY
  imapsieve_mailbox1_name = Junk
  imapsieve_mailbox2_before = file:/home/mail/sieve/global/learn-ham.sieve
  imapsieve_mailbox2_causes = COPY
  imapsieve_mailbox2_from = Junk
  imapsieve_mailbox2_name = *
  lmtp_rcpt_check_quota = yes
  quota = count:User quota
  quota_clone_dict = proxy::quotadict
  quota_rule = *:storage=250M
  quota_vsizes = yes
  quota_warning = storage=85%% quota-warning 85 %u
  quota_warning2 = storage=90%% quota-warning 90 %u
  quota_warning3 = storage=95%% quota-warning 95 %u
  sieve = 
file:/home/mail/%Ld/%Ln/sievescripts;active=/home/mail/%Ld/%Ln/sieve/dovecot.sieve
  sieve_before = /home/mail/sieve/global/spam-global.sieve
  sieve_dir = /home/mail/%Ld/%Ln/sieve
  sieve_extensions = +vacation-seconds +vacation +date +relational +editheader
  sieve_implicit_extensions = +vnd.dovecot.report
  sieve_max_redirects = 20
  sieve_pipe_bin_dir = /home/mail/sieve/global
  sieve_plugins = sieve_imapsieve sieve_extprograms
  sieve_redirect_envelope_from = sender
}
protocols = pop3 imap lmtp sieve
service auth {
  unix_listener auth-client {
mode = 0660
user = Debian-exim
  }
  unix_listener auth-master {
group = vmail
mode = 0666
user = vmail
  }
  unix_listener auth-userdb {
group = vmail
mode = 0660
user = vmail
  }
  unix_listener dovecot-auth {
group = Debian-exim
mode = 0666
user = Debian-exim
  }
}
service dict {
  unix_listener dict {
group = vmail
mode = 0660
user = vmail
  }
}
service imap-login {
  process_limit = 500
  service_count = 1
}
service imap {
  executable = imap postlogin
}
service lmtp {
  executable = lmtp -L
  inet_listener lmtp {
address = 127.0.0.1 ::1
port = 24
  }
  process_min_avail = 5
  unix_listener lmtp {
group = Debian-exim
mode = 0660
user = Debian-exim
  }
  user = vmail
}
service managesieve-login {
  inet_listener sieve {
port = 4190
  }
  service_count = 1
}
service pop3-login {
  service_count = 1
}
service pop3 {
  executable = pop3 postlogin
}
service postlogin {
  executable = script-login /usr/local/bin/postlogin.sh
  user = $default_internal_user
}
service quota-warning {
  executable = script /usr/local/bin/dovecot-quota-warning.sh
  unix_listener quota-warning {
group = vmail
mode = 0660
user = vmail
  }
}
ssl = required
ssl_cert = 
ii  dovecot-imapd 1:2.3.7.2-1
pn  dovecot-ldap  
ii  dovecot-lmtpd 1:2.3.7.2-1
pn  dovecot-lucene
ii  

Bug#946877: racket-common: scribble PDF rendering relies on 'open' command

[Philip Hands]

Package: racket-common
Version: 7.2+dfsg1-2
Severity: normal

Hi David,

If one loads a .scrbl file in drracket, one sees a button "Scribble PDF"
in the top bar, which when pressed generates an error complaining about
'open' not being found.

This is due to 'open' not being available in Debian (AFAIK it's an OS/X thing)

However there is 'gio open' (gio is from libglib2.0-bin) that does the same 
thing.

There is also xdg-open from xdg-utils that I thought was supposed to do
the same thing, but I notice that it seems to ignore my preference of
PDF viewer whereas gio gets it right (another bug to report).

The problem is here:

  
https://salsa.debian.org/bremner/racket/blob/master/share%2Fpkgs%2Fdrracket%2Fscribble%2Ftools%2Fdrracket-buttons.rkt#L67

replacing 'open' on that line with 'gio open' (while having libglib2.0-bin
installed) fixes this.

I guess that one would need a recommends, or one could make the error
message that results from gio not being available suggest installing
the package.

I'm afraid I've only looked at racket briefly so far, otherwise I'd
have tried to come up with a patch for you.

Anyway, thanks for packaging it -- It seems like a nice way to show my
kids functional programming.

Cheers, Phil.

P.S. the debsums error below is because I did the edit mentioned, to test
the fix.

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

Kernel: Linux 5.2.0-0.bpo.3-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

racket-common depends on no packages.

Versions of packages racket-common recommends:
ii  racket  7.2+dfsg1-2
ii  racket-doc  7.2+dfsg1-2
ii  sensible-utils  0.0.12

racket-common suggests no packages.

-- no debconf information

-- debsums errors found:
debsums: changed file 
/usr/share/racket/pkgs/drracket/scribble/tools/drracket-buttons.rkt (from 
racket-common package)

Bug#877783: spyne_2.13.11a0-0.1_source.changes REJECTED

[Russell Stuart]

On Mon, 2019-12-16 at 19:19 +0100, Bastian Germann wrote:
> Yes, I missed that. But maybe you have made up your mind now that
> spyne got auto-removed from testing.
> Isn't it better to have an alpha version in testing than no version
> at all?

As I said in my reply to the bug report, the "no version at all"
scenario seems unlikely to me even if Spyne for Python 3 doesn't get
released.  But it does seem like Spyne for Python 3 will be stable
before the bullseye deadlines hit. And I will upload it as soon as an I
am aware it has been released.

Regardless of what happens I use spyne in my day job, so I will
continue to package spyne for Debian.  Whether it ends up in Debian is
an open question, but I am a DD :)


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

Bug#946876: mingw32: Linking failure when using std::experimental::filesystem

[Ryan Pavlik]

Package: g++-mingw-w64-x86-64
Version: 8.3.0-6+21.3~deb10u1
Severity: normal
Tags: patch

Dear Maintainer,

I had some issues linking an application being built as C++14 and using the 
std::experimental::filesystem -
it mentioned unresolved "fs_err_concat" symbols. When researching it, I 
discovered this page,
which explained the exact message and contained a patch. 
https://patches-gcc.linaro.org/patch/12753/#22525

Apparently a change elsewhere removed a symbol that the experimental filesystem 
support was still using,
and my testing suggests that the Debian package lacks this patch.

I've added the patch to the Buster package here: 
https://salsa.debian.org/mingw-w64-team/gcc-mingw-w64/merge_requests/1
and I've confirmed that it applies and starts building - I didn't have the 
storage space to run the build
to completion locally.

The minimized test file is attached: the comment explains how to build and link 
as either C++17
(using std::filesystem - this works) or C++14 (using 
std::experimental::filesystem, produces the error)
I suspect newer upstream (e.g. not Buster) already contains the patch, but this 
test file should make it easy to check.

The error message is:

/usr/bin/x86_64-w64-mingw32-ld:
/usr/lib/gcc/x86_64-w64-mingw32/8.3-win32/libstdc++fs.a(path.o):(.text$_ZNSt12experimental10filesystem2v17__cxx1116filesystem_error11_M_gen_whatEv+0x639):
undefined reference to
`std::filesystem::fs_err_concat(std::__cxx11::basic_string, std::allocator > const&,
std::__cxx11::basic_string, std::allocator >
const&, std::__cxx11::basic_string,
std::allocator > const&)'

Thank you!

Ryan

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

Kernel: Linux 5.3.0-0.bpo.2-amd64 (SMP w/16 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), 
LANGUAGE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages g++-mingw-w64-x86-64 depends on:
ii  gcc-mingw-w64-base8.3.0-6+21.3~deb10u1
ii  gcc-mingw-w64-x86-64  8.3.0-6+21.3~deb10u1
ii  libc6 2.28-10
ii  libgcc1   1:8.3.0-6
ii  libgmp10  2:6.1.2+dfsg-4
ii  libisl19  0.20-2
ii  libmpc3   1.1.0-1
ii  libmpfr6  4.0.2-1
ii  libstdc++68.3.0-6
ii  zlib1g1:1.2.11.dfsg-1

g++-mingw-w64-x86-64 recommends no packages.

Versions of packages g++-mingw-w64-x86-64 suggests:
pn  gcc-8-locales  

-- no debconf information

/*
This builds and links:

$ x86_64-w64-mingw32-g++ -std=c++17 demo.cpp -o demo17.o -Wl,--no-undefined
-lstdc++fs

This fails to link:

$ x86_64-w64-mingw32-g++ -std=c++14 demo.cpp -o demo14.o -Wl,--no-undefined
-lstdc++fs

/usr/bin/x86_64-w64-mingw32-ld:
/usr/lib/gcc/x86_64-w64-mingw32/8.3-win32/libstdc++fs.a(path.o):(.text$_ZNSt12experimental10filesystem2v17__cxx1116filesystem_error11_M_gen_whatEv+0x639):
undefined reference to
`std::filesystem::fs_err_concat(std::__cxx11::basic_string, std::allocator > const&,
std::__cxx11::basic_string, std::allocator >
const&, std::__cxx11::basic_string,
std::allocator > const&)'
*/

// If the C++ macro is set to the version containing C++17, it must support
// the final C++17 package
#if __cplusplus >= 201703L
#include 
namespace fs = std::filesystem;
#else
#include 
namespace fs = std::experimental::filesystem;
#endif

bool is_reg_file(const std::string ) { return fs::is_regular_file(path); }
int main() {
(void)is_reg_file("/etc/os-release");
return 0;
}

Bug#933080: pekka-kana-2 FTCBFS: uses build architecture build tools

[Carlos Donizete Froes]

Hi,

New version pekka-kana-2/1.2.5-1 has been released where a standard set of
building flags has been added.[1]

[1] https://salsa.debian.org/games-team/pekka-kana-2

Thanks!

-- 
⢀⣴⠾⠻⢶⣦⠀ Carlos Donizete Froes [a.k.a coringao]
⣾⠁⢠⠒⠀⣿⡁ Debian Wiki: https://wiki.debian.org/coringao
⢿⡄⠘⠷⠚⠋⠀ GPG: 4096R/B638B780
⠈⠳⣄⠀⠀⠀  2157 630B D441 A775 BEFF  D35F FA63 ADA6 B638 B780


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

Bug#946875: RFS: pekka-kana-2/1.2.5-1 -- 2D Oldschool platform game where you control a rooster

[Carlos Donizete Froes]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "pekka-kana-2"

 * Package name: pekka-kana-2
   Version : 1.2.5-1
   Upstream Author : Janne Kivilahti (Piste Gamez) 
 * URL : https://pistegamez.net/game_pk2.html
 * License : BSD-2-Clause
 * Vcs : https://salsa.debian.org/games-team/pekka-kana-2
   Section : games

It builds those binary packages:

  pekka-kana-2 - 2D Oldschool platform game where you control a rooster
  pekka-kana-2-data - 2D Oldschool platform game where you control a rooster 
(data file)

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

  https://mentors.debian.net/package/pekka-kana-2

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

  dget -x 
https://mentors.debian.net/debian/pool/main/p/pekka-kana-2/pekka-kana-2_1.2.5-1.dsc

Changes since the last upload:

   * New upstream release. FTCBFS bug fix. (Closes: #933080)
   * debian/control:
 + Bumped Standards-Version to 4.4.1.
 + Set Rules-Requires-Root to no.
   * debian/copyright:
 + Added copyright information for contact.

Regards,

--
  Carlos Donizete Froes [a.k.a coringao]

Bug#878599: git: [PATCH] Ship git-credential-libsecret

[Jonathan Nieder]

Hi,

Josh Triplett wrote:

> I would love to see git-credential-libsecret packaged.
>
> This patch would ship git-credential-libsecret in the git package, which
> would add libsecret and its dependencies to the dependencies of git.
> Since many people use the git package on servers, that might not be
> welcome. (I personally wouldn't object, as those dependencies seem quite
> small.)

It seems you forgot to attach the patch.

> It might also make sense to generate a separate git-credential-libsecret
> binary package containing this binary.

Yes, that's what I'd prefer: just "git-libsecret", in case we want to
package any other libsecret-related helpers.  Or even
"git-secretservice" or "git-gnome".

Thanks for your work on this.

Excited,
Jonathan

Bug#939622: blender

[Matteo F. Vescovi]

Hi!

On 2019-12-15 at 23:51 (-03), Niv Sardi wrote:
> blender is pretty broken without subdiv, not sure having it broken
> waiting for the ITP is the best move here.

Feel free to advice for a better move, then.


-- 
Matteo F. Vescovi || Debian Developer
GnuPG KeyID: 4096R/0x8062398983B2CF7A


signature.asc
Description: PGP signature

Bug#945868: ros-rospkg: OS detection is wrong for Ubuntu, uses deprecated LSB instead of os-release

[Steve Langasek]

Thanks for the fix!

On Sun, Dec 01, 2019 at 02:36:41PM +0100, Jochen Sprickerhof wrote:
> Hi Steve,

> * Steve Langasek  [2019-11-29 19:35]:
> > In Ubuntu, the latest version of ros-rosdep was failing to build due to test
> > failures related to ros-rospkg, which was not properly detecting the
> > platform as Ubuntu.  Digging into this, I found that ros-rospkg was relying
> > on the lsb_release command to detect Debian and Ubuntu as platforms; but
> > lsb_release is not part of the base system, so this fails when the
> > additional lsb-release package is not installed.

> Thanks for bringing this to my attention, could you add a link to the
> failing log next time? I think I know where it fails, but it would be easier
> to verify with a log (and I wasn't able to find one).

Normally I would do this, but Launchpad doesn't keep old failure logs, and
once the bug was fixed in ros-rospkg in Ubuntu, the ros-rosdep package build
succeeded - so the log went away.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Bug#941633: synfigstudio crashes on almost every operation

[VA]

There you go, log as attachment. Let me know if I did something wrong.

I drew 2 rectangles and pressed ctrl-z -> segfault.
% LANG=C gdb --arg synfigstudio
GNU gdb (Debian 8.3.1-1) 8.3.1
Copyright (C) 2019 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from synfigstudio...
Reading symbols from /usr/lib/debug/.build-id/6d/56da46b9c5d5c54ba4eaf6f08e491fa1f40faf.debug...
(No debugging symbols found in /usr/lib/debug/.build-id/6d/56da46b9c5d5c54ba4eaf6f08e491fa1f40faf.debug)
(gdb) r
Starting program: /usr/bin/synfigstudio 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

   synfig studio -- starting up application...

[New Thread 0x71bed700 (LWP 3373)]
[New Thread 0x713ec700 (LWP 3374)]
synfig(3368) [23:32:35] info: Starting Subsystem "Sound"
No LADSPA plugins were found!

Check your LADSPA_PATH environment variable.
synfig(3368) [23:32:36] info: Starting Subsystem "Types"
synfig(3368) [23:32:36] info: Starting Subsystem "Rendering"
[New Thread 0x7fffddbb3700 (LWP 3375)]
[New Thread 0x7fffdd3b2700 (LWP 3376)]
[New Thread 0x7fffdcbb1700 (LWP 3377)]
[New Thread 0x7fffdc3b0700 (LWP 3378)]
[New Thread 0x7fffdbbaf700 (LWP 3379)]
[New Thread 0x7fffdb3ae700 (LWP 3380)]
[New Thread 0x7fffdabad700 (LWP 3381)]
[New Thread 0x7fffda3ac700 (LWP 3382)]
[New Thread 0x7fffd9bab700 (LWP 3383)]
[New Thread 0x7fffd93aa700 (LWP 3384)]
[New Thread 0x7fffd8ba9700 (LWP 3385)]
[New Thread 0x7fffd83a8700 (LWP 3386)]
synfig(3368) [23:32:36] info: rendering threads 12
synfig(3368) [23:32:36] info: Starting Subsystem "Modules"
synfig(3368) [23:32:36] info: Starting Subsystem "Layers"
synfig(3368) [23:32:36] info: Starting Subsystem "Targets"
synfig(3368) [23:32:36] info: Starting Subsystem "Importers"
synfig(3368) [23:32:36] info: Starting Subsystem "Cairo Importers"
synfig(3368) [23:32:36] warning: Cannot open ./synfig_modules.cfg
synfig(3368) [23:32:36] warning: Cannot open /home/user/.local/share/synfig/synfig_modules.cfg
synfig(3368) [23:32:36] info: Loading modules from /etc/synfig/synfig_modules.cfg
synfig(3368) [23:32:36] info: Loading modules from /etc/synfig/synfig_modules.cfg
synfig(3368) [23:32:36] info: Loading lyr_std..
synfig(3368) [23:32:36] info: Attempting to register "lyr_std"
synfig(3368) [23:32:36] info: Found module "lyr_std"
synfig(3368) [23:32:36] info: Success for "lyr_std"
synfig(3368) [23:32:36] info: Loading lyr_freetype..
synfig(3368) [23:32:36] info: Attempting to register "lyr_freetype"
synfig(3368) [23:32:36] info: Found module "lyr_freetype"
synfig(3368) [23:32:36] info: Initializing FreeType...
synfig(3368) [23:32:36] info: Success for "lyr_freetype"
synfig(3368) [23:32:36] info: Loading mod_geometry..
synfig(3368) [23:32:36] info: Attempting to register "mod_geometry"
synfig(3368) [23:32:36] info: Found module "mod_geometry"
synfig(3368) [23:32:36] info: Success for "mod_geometry"
synfig(3368) [23:32:36] info: Loading mod_gradient..
synfig(3368) [23:32:36] info: Attempting to register "mod_gradient"
synfig(3368) [23:32:36] info: Found module "mod_gradient"
synfig(3368) [23:32:36] info: Success for "mod_gradient"
synfig(3368) [23:32:36] info: Loading mod_particle..
synfig(3368) [23:32:36] info: Attempting to register "mod_particle"
synfig(3368) [23:32:36] info: Found module "mod_particle"
synfig(3368) [23:32:36] info: Success for "mod_particle"
synfig(3368) [23:32:36] info: Loading mod_example..
synfig(3368) [23:32:36] info: Attempting to register "mod_example"
synfig(3368) [23:32:37] info: Found module "mod_example"
synfig(3368) [23:32:37] info: Success for "mod_example"
synfig(3368) [23:32:37] info: Loading mod_gif..
synfig(3368) [23:32:37] info: Attempting to register "mod_gif"
synfig(3368) [23:32:37] info: Found module "mod_gif"
synfig(3368) [23:32:37] info: Success for "mod_gif"
synfig(3368) [23:32:37] info: Loading mod_imagemagick..
synfig(3368) [23:32:37] info: Attempting to register "mod_imagemagick"
synfig(3368) [23:32:37] info: Found module "mod_imagemagick"
synfig(3368) [23:32:37] info: Success for "mod_imagemagick"
synfig(3368) [23:32:37] info: Loading mod_magickpp..
synfig(3368) [23:32:37] info: Attempting to register "mod_magickpp"
synfig(3368) [23:32:37] info: Found module "mod_magickpp"
synfig(3368) [23:32:37] info: Success for "mod_magickpp"
synfig(3368) [23:32:37] info: 

Bug#946806: exim4-base: Smarthost with SMTPS (to port 465) is missing - requires recompilation

[Karl Schmidt]

On 12/16/19 12:25 PM, Andreas Metzler wrote:

On 2019-12-16 Karl Schmidt  wrote:

Package: exim4-base
Version: 4.92-8+deb10u3
Severity: normal




The use of SMTPS is rather standard these days - (thunderbird, k9
outlook etc.. ) all support this.



Without openSSL one can't have a smart-host transport with: driver =  smtps


Hello,

 From where did you get that idea? I cannot find any reference in the
specification about "protocol = smtps" being openssl-only.


Thanks ..

Turns out I was following an incorrect example --

They had
driver = smtps

Should be

driver = smtp
 protocol = smtps










A breadcrum for others: According to exim.org docs one must recompile
and change USE_OPENSSL=yes in Local/Makefile to USE_GNUTLS=yes



It could be there needs to be two packages - exim4-gnutl and exim4-openssl



At the very least the README.Debian should start out with which
version it is.

[...]

What info are you missing?

ametzler@argenau:~$ dpkg -s exim4-daemon-light
Package: exim4-daemon-light
[...]
  and includes support for TLS encryption
[...]

file:///usr/share/doc/exim4-base/README.Debian.html#TLS
  Both exim4-daemon-heavy and exim4-daemon-light support TLS/SSL using the 
GnuTLS library and STARTTLS.

cu Andreas





Karl Schmidt  EMail k...@lrak.net
3209 West 9th Street Ph (785) 979-8397
Lawrence, KS 66049

I think I admire a well made kitchen appliance more
than anything I've seen in an art museum. - kps

Bug#946874: llvm-toolchain-9: please include upstream patch D71028 for rust mips tests

[Ximin Luo]

Source: llvm-toolchain-9
Severity: normal
Tags: patch upstream

Dear Maintainer,

Please include this upstream patch which is already merged: 
https://reviews.llvm.org/D71028

It is needed for rustc mips to pass 
https://github.com/rust-lang/rust/issues/67167

I have confirmed that the raw diff applies cleanly to the current Debian 
package.

https://reviews.llvm.org/file/data/62pyj4rca74lyduv2gkr/PHID-FILE-267qlycncoogjurgx7hc/D71028.diff

(It does not apply cleanly to llvm-8, only 9 and upwards.)

X

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

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

Bug#946836: Build failure on powerpc architectures

[Dirk Eddelbuettel]

On 16 December 2019 at 22:04, Martin Maechler wrote:
| Oops, no!
| Tomas the expert has explained me why that would not be good enough,
| instead recommending a macro  (which would be "constant folded" i.e.,
| computed at compile time were available);
| If I conditionalize that .. in order to be back compatible outside of
| PPC_64,  I'd get
| 
| Index: src/main/arithmetic.c
| ===
| --- src/main/arithmetic.c(Revision 77583)
| +++ src/main/arithmetic.c(Arbeitskopie)
| @@ -176,8 +176,14 @@
|  #endif
|  }
| 
| +
|  #if HAVE_LONG_DOUBLE && (SIZEOF_LONG_DOUBLE > SIZEOF_DOUBLE)
| +# ifdef __PPC64__
| + // PowerPC 64 (when gcc has -mlong-double-128) breaks here ...
| +#  define q_1_eps (1 / LDBL_EPSILON)
| +# else
|  static LDOUBLE q_1_eps = 1 / LDBL_EPSILON;
| +# endif
|  #else
|  static double  q_1_eps = 1 / DBL_EPSILON;
|  #endif
| 
| -
| The above may work correctly  (I tried a version where I replaced
| __PPC64__  by  1such as to test with the gcc 9.2 (on my
| architecture).
| I'd be glad if you could confirm for  powerPC 64 ..
| then I think we could commit it.

Nice. I applied that, and prepare a 'local' package.  Sebastien, could you
test it to be sure?

Files are here:

   http://dirk.eddelbuettel.com/tmp/r-base/

As usual you can probably ignore the .deb files but it was simpler / cleaner
to copy the whole batch.

Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#943600: [Pkg-pascal-devel] Bug#943600: Bug#943600: Bug#943600: lazarus autopkgtest intermittedly fails due to EAccessViolation: Access violation

[Graham Inggs]

Hi Abou

2.0.6+dfsg-3, still fails intermittently on armhf in Ubuntu [1].
Did you try debugging on armhf in Debian?

Regards
Graham


[1] http://autopkgtest.ubuntu.com/packages/l/lazarus/focal/armhf

Bug#944426: [Pkg-pascal-devel] Bug#944426: Still not able to update

[Johann Glaser]

Hi Abou!

Am Montag, den 16.12.2019, 22:31 +0100 schrieb Abou Al Montacir:
> Hi Johann,
>
> Can you please provide the following information
>
> grep laz /var/lib/dpkg/diversions
>
> /var/lib/dpkg/info/lazarus-src-2.0.preinst
> /var/lib/dpkg/info/lazarus-src-2.0.postrm

Thanks for your help!

Please find three files attached.

> What package manager are you using (apt, aptitude, ...)?

I'm using "aptitude".

Bye
  Hansi

/usr/lib/lazarus/2.0.2/components/rtticontrols/runtimetypeinfocontrols.lpk
/usr/lib/lazarus/2.0.2/components/rtticontrols/runtimetypeinfocontrols.lpk.orig
lazarus-src-2.0
/usr/lib/lazarus/2.0.2/components/datetimectrls/datetimectrls.lpk
/usr/lib/lazarus/2.0.2/components/datetimectrls/datetimectrls.lpk.orig
lazarus-src-2.0
/usr/lib/lazarus/2.0.2/components/lazreport/source/addons/DialogControls/lr_dialogdesign.lpk
/usr/lib/lazarus/2.0.2/components/lazreport/source/addons/DialogControls/lr_dialogdesign.lpk.orig
lazarus-src-2.0
/usr/lib/lazarus/2.0.2/components/lazreport/source/addons/addfunction/lr_add_function.lpk
/usr/lib/lazarus/2.0.2/components/lazreport/source/addons/addfunction/lr_add_function.lpk.orig
lazarus-src-2.0
/usr/lib/lazarus/2.0.2/components/sparta/dockedformeditor/sparta_dockedformeditor.lpk
/usr/lib/lazarus/2.0.2/components/sparta/dockedformeditor/sparta_dockedformeditor.lpk.orig
lazarus-src-2.0
/usr/lib/lazarus/2.0.2/components/lazsvnpkg/lazsvnpkg.lpk
/usr/lib/lazarus/2.0.2/components/lazsvnpkg/lazsvnpkg.lpk.orig
lazarus-src-2.0
/usr/lib/lazarus/2.0.2/components/fpcunit/console/fpcunitconsolerunner.lpk
/usr/lib/lazarus/2.0.2/components/fpcunit/console/fpcunitconsolerunner.lpk.orig
lazarus-src-2.0
/usr/lib/lazarus/2.0.2/lcl/lclbase.lpk
/usr/lib/lazarus/2.0.2/lcl/lclbase.lpk.orig
lazarus-src-2.0
/usr/lib/lazarus/2.0.2/components/fpreport/design/lazfpreportdesign.lpk
/usr/lib/lazarus/2.0.2/components/fpreport/design/lazfpreportdesign.lpk.orig
lazarus-src-2.0
/usr/lib/lazarus/2.0.2/components/macfiles/macosfiles.lpk
/usr/lib/lazarus/2.0.2/components/macfiles/macosfiles.lpk.orig
lazarus-src-2.0
/usr/lib/lazarus/2.0.2/components/fpcunit/fpcunittestrunner.lpk
/usr/lib/lazarus/2.0.2/components/fpcunit/fpcunittestrunner.lpk.orig
lazarus-src-2.0
/usr/lib/lazarus/2.0.2/components/lazdebuggers/lazdebuggerfpgdbmi/lazdebuggerfpgdbmi.lpk
/usr/lib/lazarus/2.0.2/components/lazdebuggers/lazdebuggerfpgdbmi/lazdebuggerfpgdbmi.lpk.orig
lazarus-src-2.0
/usr/lib/lazarus/2.0.2/components/sqlite/sqlitelaz.lpk
/usr/lib/lazarus/2.0.2/components/sqlite/sqlitelaz.lpk.orig
lazarus-src-2.0
/usr/lib/lazarus/2.0.2/components/favorites/favorites.lpk
/usr/lib/lazarus/2.0.2/components/favorites/favorites.lpk.orig
lazarus-src-2.0
/usr/lib/lazarus/2.0.2/components/lazreport/source/lazreport.lpk
/usr/lib/lazarus/2.0.2/components/lazreport/source/lazreport.lpk.orig
lazarus-src-2.0
/usr/lib/lazarus/2.0.2/components/lazreport/source/addons/ZeosDB/lr_zeosdb.lpk
/usr/lib/lazarus/2.0.2/components/lazreport/source/addons/ZeosDB/lr_zeosdb.lpk.orig
lazarus-src-2.0
/usr/lib/lazarus/2.0.2/components/aggpas/lazarus/aggpaslcl.lpk
/usr/lib/lazarus/2.0.2/components/aggpas/lazarus/aggpaslcl.lpk.orig
lazarus-src-2.0
/usr/lib/lazarus/2.0.2/components/googleapis/lazgoogleapis.lpk
/usr/lib/lazarus/2.0.2/components/googleapis/lazgoogleapis.lpk.orig
lazarus-src-2.0
/usr/lib/lazarus/2.0.2/components/sqlite/sqlite3laz.lpk
/usr/lib/lazarus/2.0.2/components/sqlite/sqlite3laz.lpk.orig
lazarus-src-2.0
/usr/lib/lazarus/2.0.2/examples/dockmanager/package/easydockmgr.lpk
/usr/lib/lazarus/2.0.2/examples/dockmanager/package/easydockmgr.lpk.orig
lazarus-src-2.0
/usr/lib/lazarus/2.0.2/components/messagecomposer/messagecomposerpkg.lpk
/usr/lib/lazarus/2.0.2/components/messagecomposer/messagecomposerpkg.lpk.orig
lazarus-src-2.0
/usr/lib/lazarus/2.0.2/components/lazdebuggers/lazdebuggerlldb/lazdebuggerlldb.lpk
/usr/lib/lazarus/2.0.2/components/lazdebuggers/lazdebuggerlldb/lazdebuggerlldb.lpk.orig
lazarus-src-2.0
/usr/lib/lazarus/2.0.2/components/fpreport/lclfpreport.lpk
/usr/lib/lazarus/2.0.2/components/fpreport/lclfpreport.lpk.orig
lazarus-src-2.0
/usr/lib/lazarus/2.0.2/components/education/educationlaz.lpk
/usr/lib/lazarus/2.0.2/components/education/educationlaz.lpk.orig
lazarus-src-2.0
/usr/lib/lazarus/2.0.2/components/tachart/aggpas/tachartaggpas.lpk
/usr/lib/lazarus/2.0.2/components/tachart/aggpas/tachartaggpas.lpk.orig
lazarus-src-2.0
/usr/lib/lazarus/2.0.2/components/lazreport/source/addons/lrOfficeImport/lr_officeimport.lpk
/usr/lib/lazarus/2.0.2/components/lazreport/source/addons/lrOfficeImport/lr_officeimport.lpk.orig
lazarus-src-2.0
/usr/lib/lazarus/2.0.2/components/projecttemplates/projtemplates.lpk
/usr/lib/lazarus/2.0.2/components/projecttemplates/projtemplates.lpk.orig
lazarus-src-2.0
/usr/lib/lazarus/2.0.2/components/sparta/toolsapi/sparta_toolsapi.lpk
/usr/lib/lazarus/2.0.2/components/sparta/toolsapi/sparta_toolsapi.lpk.orig
lazarus-src-2.0
/usr/lib/lazarus/2.0.2/components/sparta/generics/sparta_generics.lpk

Bug#946873: RFS: wand/0.5.8-1 [ITA] -- Python interface for ImageMagick library (Python 3 build)

[Håvard Flaget Aasen]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "wand"

* Package name : wand
Version : 0.5.8-1
Upstream Author : Hong Minhee
* URL : https://github.com/emcconville/wand
* License : Expat
* Vcs : https://salsa.debian.org/debian/wand
Section : python

It builds those binary packages:

python3-wand - Python interface for ImageMagick library (Python 3 build)
pypy-wand - Python interface for ImageMagick library (PyPy build)
wand-doc - Python interface for ImageMagick library - documentation

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


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

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

dget -x https://mentors.debian.net/debian/pool/main/w/wand/wand_0.5.8-1.dsc

Changes since the last upload:

* New upstream version 0.5.8
* Add lintian-overrides for empty folder, docs/_themes/*
* Set myself as maintainer closes: #934012
* Add autopkgtest-pkg-python
* Change how testsuite is being disabled

Regards,

Bug#944426: [Pkg-pascal-devel] Bug#944426: Still not able to update

[Abou Al Montacir]

Hi Johann,
Can you please  provide the following information
grep laz /var/lib/dpkg/diversions
/var/lib/dpkg/info/lazarus-src-2.0.preinst/var/lib/dpkg/info/lazarus-src-
2.0.postrm
What package manager are you using (apt, aptitude, ...)?
On Mon, 2019-12-16 at 01:22 +0100, Johann Glaser wrote:
> Hi!
> The problem is still there for lazarus-src-2.0_2.0.6+dfsg-3_all.deb. Itwas
> actually also there for 2.0.6+dfsg-2 as well as 2.0.6+dfsg-1.
> The only thing which helps is forcing it, but it gives a huge load ofwarnings:
> # dpkg -i --force-all /var/cache/apt/archives/lazarus-src-2.0_2.0.6+dfsg-
> 3_all.deb(Reading database ... 528262 files and directories currently
> installed.)Preparing to unpack .../lazarus-src-2.0_2.0.6+dfsg-3_all.deb
> ...Unpacking lazarus-src-2.0 (2.0.6+dfsg-3) over (2.0.6+dfsg-2) ...dpkg:
> warning: overriding problem because --force enabled:dpkg: warning: trying to
> overwrite '/usr/lib/lazarus/2.0.6/components/IdeInspector/ideinspector.lpk',
> which is also in package lcl-units-2.0 2.0.6+dfsg-3dpkg: warning: overriding
> problem because --force enabled:dpkg: warning: trying to overwrite
> '/usr/lib/lazarus/2.0.6/components/IdeLazLogger/idelazlogger.lpk', which is
> also in package lcl-units-2.0 2.0.6+dfsg-3dpkg: warning: overriding problem
> because --force enabled:dpkg: warning: trying to overwrite
> '/usr/lib/lazarus/2.0.6/components/PascalScript/Source/pascalscript.lpk',
> which is also in package lcl-units-2.0 2.0.6+dfsg-3dpkg: warning: overriding
> problem because --force enabled:dpkg: warning: trying to overwrite
> '/usr/lib/lazarus/2.0.6/components/PascalScript/Source/pascalscriptfcl.lpk',
> which is also in package lcl-units-2.0 2.0.6+dfsg-3dpkg: warning: overriding
> problem because --force enabled:dpkg: warning: trying to overwrite
> '/usr/lib/lazarus/2.0.6/components/aarre/src/aarrebase.lpk', which is also in
> package lcl-units-2.0 2.0.6+dfsg-3dpkg: warning: overriding problem because --
> force enabled:dpkg: warning: trying to overwrite
> '/usr/lib/lazarus/2.0.6/components/activex/LazActiveX.lpk', which is also in
> package lcl-units-2.0 2.0.6+dfsg-3dpkg: warning: overriding problem because --
> force enabled:dpkg: warning: trying to overwrite
> '/usr/lib/lazarus/2.0.6/components/aggpas/lazarus/aggpaslcl.lpk', which is
> also in package lcl-units-2.0 2.0.6+dfsg-3dpkg: warning: overriding problem
> because --force enabled:dpkg: warning: trying to overwrite
> '/usr/lib/lazarus/2.0.6/components/anchordocking/anchordocking.lpk', which is
> also in package lcl-units-2.0 2.0.6+dfsg-3dpkg: warning: overriding problem
> because --force enabled:dpkg: warning: trying to overwrite
> '/usr/lib/lazarus/2.0.6/components/anchordocking/design/anchordockingdsgn.lpk'
> , which is also in package lcl-units-2.0 2.0.6+dfsg-3dpkg: warning: overriding
> problem because --force enabled:dpkg: warning: trying to overwrite
> '/usr/lib/lazarus/2.0.6/components/cairocanvas/cairocanvas_pkg.lpk', which is
> also in package lcl-units-2.0 2.0.6+dfsg-3dpkg: warning: overriding problem
> because --force enabled:dpkg: warning: trying to overwrite
> '/usr/lib/lazarus/2.0.6/components/chmhelp/packages/help/lhelpcontrolpkg.lpk',
> which is also in package lcl-units-2.0 2.0.6+dfsg-3dpkg: warning: overriding
> problem because --force enabled:dpkg: warning: trying to overwrite
> '/usr/lib/lazarus/2.0.6/components/chmhelp/packages/idehelp/chmhelppkg.lpk',
> which is also in package lcl-units-2.0 2.0.6+dfsg-3dpkg: warning: overriding
> problem because --force enabled:dpkg: warning: trying to overwrite
> '/usr/lib/lazarus/2.0.6/components/codetools/codetools.lpk', which is also in
> package lcl-units-2.0 2.0.6+dfsg-3dpkg: warning: overriding problem because --
> force enabled:dpkg: warning: trying to overwrite
> '/usr/lib/lazarus/2.0.6/components/codetools/ide/cody.lpk', which is also in
> package lcl-units-2.0 2.0.6+dfsg-3dpkg: warning: overriding problem because --
> force enabled:dpkg: warning: trying to overwrite
> '/usr/lib/lazarus/2.0.6/components/compilers/c/lazc.lpk', which is also in
> package lcl-units-2.0 2.0.6+dfsg-3dpkg: warning: overriding problem because --
> force enabled:dpkg: warning: trying to overwrite
> '/usr/lib/lazarus/2.0.6/components/customdrawn/customdrawn.lpk', which is also
> in package lcl-units-2.0 2.0.6+dfsg-3dpkg: warning: overriding problem because
> --force enabled:dpkg: warning: trying to overwrite
> '/usr/lib/lazarus/2.0.6/components/customform/demo/appforms.lpk', which is
> also in package lcl-units-2.0 2.0.6+dfsg-3dpkg: warning: overriding problem
> because --force enabled:dpkg: warning: trying to overwrite
> '/usr/lib/lazarus/2.0.6/components/customform/lazcustforms.lpk', which is also
> in package lcl-units-2.0 2.0.6+dfsg-3dpkg: warning: overriding problem because
> --force enabled:dpkg: warning: trying to overwrite
> '/usr/lib/lazarus/2.0.6/components/daemon/lazdaemon.lpk', which is also in
> package lcl-units-2.0 2.0.6+dfsg-3dpkg: warning: overriding problem because --
> 

Bug#946836: Build failure on powerpc architectures

[Martin Maechler]

On Mon, Dec 16, 2019 at 8:29 PM Martin Maechler
 wrote:
>
> Thank you, Dirk, for keeping me in the loop.  I'm happy if you test to
> see if the change works.
>
> As a matter of fact, I think a slightly different patch should be used
> rather than the one proposed.
> Given what I've learned in the meantime, I think I'd  rather use
>
> Index: src/main/arithmetic.c
> ===
> --- src/main/arithmetic.c(Revision 77566)
> +++ src/main/arithmetic.c(Arbeitskopie)
> @@ -176,8 +176,12 @@
>  #endif
>  }
>
> +
>  #if HAVE_LONG_DOUBLE && (SIZEOF_LONG_DOUBLE > SIZEOF_DOUBLE)
> -static LDOUBLE q_1_eps = 1 / LDBL_EPSILON;
> +# ifndef __PPC64__
> +static // PowerPC 64 (when gcc has -mlong-double-128) breaks when
> 'static' (gcc bug, there)
> +# endif
> +   LDOUBLE q_1_eps = 1 / LDBL_EPSILON;
>  #else
>  static double  q_1_eps = 1 / DBL_EPSILON;
>  #endif
>
>
> which would keep PowerPC 64 to use the high precision epsilon here,
> rather than the one to use when there is no long double present.
> Martin

Oops, no!
Tomas the expert has explained me why that would not be good enough,
instead recommending a macro  (which would be "constant folded" i.e.,
computed at compile time were available);
If I conditionalize that .. in order to be back compatible outside of
PPC_64,  I'd get

Index: src/main/arithmetic.c
===
--- src/main/arithmetic.c(Revision 77583)
+++ src/main/arithmetic.c(Arbeitskopie)
@@ -176,8 +176,14 @@
 #endif
 }

+
 #if HAVE_LONG_DOUBLE && (SIZEOF_LONG_DOUBLE > SIZEOF_DOUBLE)
+# ifdef __PPC64__
+ // PowerPC 64 (when gcc has -mlong-double-128) breaks here ...
+#  define q_1_eps (1 / LDBL_EPSILON)
+# else
 static LDOUBLE q_1_eps = 1 / LDBL_EPSILON;
+# endif
 #else
 static double  q_1_eps = 1 / DBL_EPSILON;
 #endif

-
The above may work correctly  (I tried a version where I replaced
__PPC64__  by  1such as to test with the gcc 9.2 (on my
architecture).
I'd be glad if you could confirm for  powerPC 64 ..
then I think we could commit it.

Martin

Bug#946872: thunderbird: Changing language to Swedish causes lightning xml parsing error

[Jonatan Nyberg]

Package: thunderbird
Version: 1:68.3.0-2
Severity: normal

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
Firefox/68.0

Steps to reproduce:

Install thunderbird and lightning
Open Thunderbird
Open Options
Change Language to Swedish
Apply and restart

I am using Thinderbird with Debian Sid and the addon Lightning

Actual results:

Thunderbird didn't work properly, the status bar took up most of the
screen and hade a lot of code in it.

Expected results:

The language to change to Swedish and work properly

Bug#946748: [Pkg-zfsonlinux-devel] Bug#946748: [zfsutils-linux] /etc/cron.d/zfsutils-linux leads to false error mails with systemd-cron

[Richard Laager]

On 12/15/19 2:09 AM, Dirk Heinrichs wrote:
> [ $(date +\%w) -eq 0 ] && [ -x /usr/lib/zfs-linux/scrub ] &&
> /usr/lib/zfs-linux/scrub
> 
> This first test of course always fails except on Sundays, leading to a
> non-zero exit code, which triggers systemd-cron's (correct) behaviour
> to send an error mail.
> 
> This doesn't happen if the entire command is rewritten as
> 
> if [ $(date +\%w) -eq 0 ] && [ -x /usr/lib/zfs-linux/scrub ]; then
> /usr/lib/zfs-linux/scrub; fi
As that guy who wrote it originally, I agree that is a proper
correction. This would be in line with what mdadm does (at least now).

-- 
Richard



signature.asc
Description: OpenPGP digital signature

Bug#698279: xfce4-panel: Clock panel shows nothing on hover; clock is blank on digital display

[Ralph Katz]

Package: xfce4-panel
Version: 4.12.2-1
Followup-For: Bug #698279

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear Maintainer,

Bug may be the same as #81798, Clock turns blank after changing format
settings.

Hovering over the clock area shows nothing on any display setting below.

Changing properties to:
- - digital blanks the clock panel area.
- - LCD   works fine to display time
- - analog  works fine to display time
- - fuzzy   works fine to display time
- - binary  works fine to display time

Tooltip format reverts to Custom Format and blank field after any other choice
is entered.

Thanks!



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

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

Versions of packages xfce4-panel depends on:
ii  exo-utils0.12.4-1
ii  libatk1.0-0  2.30.0-2
ii  libc62.28-10
ii  libcairo21.16.0-4
ii  libdbus-1-3  1.12.16-1
ii  libdbus-glib-1-2 0.110-4
ii  libexo-1-0   0.12.4-1
ii  libfontconfig1   2.13.1-2
ii  libfreetype6 2.9.1-3+deb10u1
ii  libgarcon-1-00.6.2-1
ii  libgdk-pixbuf2.0-0   2.38.1+dfsg-1
ii  libglib2.0-0 2.58.3-2+deb10u2
ii  libgtk2.0-0  2.24.32-3
ii  libice6  2:1.0.9-2
ii  libpango-1.0-0   1.42.4-7~deb10u1
ii  libpangocairo-1.0-0  1.42.4-7~deb10u1
ii  libpangoft2-1.0-01.42.4-7~deb10u1
ii  libsm6   2:1.2.3-1
ii  libwnck222.30.7-6
ii  libx11-6 2:1.6.7-1
ii  libxext6 2:1.3.3-1+b2
ii  libxfce4ui-1-0   4.12.1-3
ii  libxfce4util74.12.1-3
ii  libxfconf-0-24.12.1-1

xfce4-panel recommends no packages.

xfce4-panel suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQJIBAEBCgAyFiEEJQZ8vK6BnmDiW8fZyAJ5DhtfJxAFAl337aIUHHJhbHBoQHJh
bHBoa2F0ei5jb20ACgkQyAJ5DhtfJxAJ8w/9FCnmADLIFn83y8YVVWZalZa12oSl
Lbvy4rAi84ZLphaOUILgT+R6ppmrtxXGkzwf1Kc9iyZFZNJbG5GfDu5epRRdSAM3
7uR0KXqDsX6xWXvtPITM1f5ZKTx/+4J4NS1dUJRV9BArLOjHEnI/wM9EmoZ4mI2T
VFqvaxFkXvJDxEVdY4qgQgwIBy7CYOv1hTQh7NrrlcuT+V26najwgoYMNqKEBWTy
nQlK3jpOTwRrhw3h5Rf1x5t+4vfnHOHFJD8HaDMongWCFEpyl26gyDyGvIukaYrV
7iKv5/lA+2r5ChiH3NdHGDNNRJ1ZXA4fM3wU4536cQSGcshaONrKFi8E+d8iTgib
xL33fO+S8WtfydALjfpMVPc8qZE86slNHpBDtKsBIDbrKlOxEDw07xB21rd4KGg2
UMMfWGoA9qRI7i+ZYQF8OmNwjrEVEADv0xBev0QyoNsA0RSewCzRYJozwfb+4L5D
I8n4jwUMInnnLKQNf5EX0zQsFfS5wfCcw8iw4Z8NFNfC9A2DbIbiqB8cd8JlKeqM
+iFSYk2F0jUDEQfOCzaIBNf1QQFZQ4zRA0UiaO529l84OvXveOHvdaJGtdIvOmoD
m4XceE8QuJqw9iHoGbJgPY2nIny61db3BivWWWY59zqbmFWLZk37dWWaae4wn+5L
EibIFAUbML9NOu8=
=j/xW
-END PGP SIGNATURE-

Bug#943260: seqan: Python2 removal in sid/bullseye

[Andreas Tille]

Control: tags -1 help

Hi,

I tried to port seqan to Python3 ut it seems there are several test
failures.  I wonder whether we really need seqan since we have seqan2
and seqan3.  Everybody who is convinced that we need seqan is invited to
checkout Git and try to fix these issues.


52% tests passed, 46 tests failed out of 95

Total Test time (real) =   9.49 sec

The following tests FAILED:
  1 - test_demo_align_align (Failed)
  2 - test_demo_align_compute_alignment_stats (Failed)
  3 - test_demo_align_gaps_example (Failed)
  4 - test_demo_align_global_alignment_banded (Failed)
  5 - test_demo_align_global_alignment_unbanded (Failed)
  6 - test_demo_align_integrate_align (Failed)
  7 - test_demo_bam_io_bam_stream (Failed)
  8 - test_demo_find_finder_index (Failed)
  9 - test_demo_find_finder_online (Failed)
 10 - test_demo_graph_graph_algo_dijkstra (Failed)
 11 - test_demo_graph_algorithms_all_pairs_shortest_path (Failed)
 12 - test_demo_graph_algorithms_bellman_ford_algorithm (Failed)
 13 - test_demo_graph_algorithms_breadth_first_search (Failed)
 14 - test_demo_graph_algorithms_dag_shortest_path (Failed)
 15 - test_demo_graph_algorithms_depth_first_search (Failed)
 16 - test_demo_graph_algorithms_dijkstra (Failed)
 17 - test_demo_graph_algorithms_floyd_warshall_algorithm (Failed)
 18 - test_demo_graph_algorithms_ford_fulkerson_algorithm (Failed)
 19 - test_demo_graph_algorithms_kruskals_algorithm (Failed)
 20 - test_demo_graph_algorithms_prims_algorithm (Failed)
 21 - test_demo_graph_algorithms_strongly_connected_components (Failed)
 22 - test_demo_graph_algorithms_topological_sort (Failed)
 23 - test_demo_graph_algorithms_transitive_closure (Failed)
 24 - test_demo_index_index_begin_atEnd_representative (Failed)
 25 - test_demo_index_index_counting (Failed)
 26 - test_demo_index_index_finder (Failed)
 27 - test_demo_index_index_getOccurrences_getFrequency_range_getFibre 
(Failed)
 28 - test_demo_index_index_iterator (Failed)
 29 - test_demo_index_index_iterator_short (Failed)
 30 - test_demo_index_index_length_countSequences (Failed)
 31 - test_demo_index_index_mummy (Failed)
 32 - test_demo_index_index_open_save (Failed)
 33 - test_demo_index_index_textAt_indexText_saAt_indexRequire (Failed)
 34 - test_demo_input_output_record_reader (Failed)
 35 - test_demo_misc_enumerate_strings (Failed)
 36 - test_demo_modifier_modified_string (Failed)
 37 - test_demo_modifier_modified_string_mod_view (Failed)
 38 - test_demo_modifier_modified_string_nested (Failed)
 39 - test_demo_score_score (Failed)
 40 - test_demo_seeds_seeds_extension (Failed)
 41 - test_demo_seq_io_fai_index_example (Failed)
 42 - test_demo_seq_io_sequence_stream_read (Failed)
 43 - test_demo_sequence_string2 (Failed)
 44 - test_demo_sequence_stringset (Failed)
 78 - test_test_index_fm (SEGFAULT)
 79 - test_test_index_stree_iterators (SEGFAULT)
Errors while running CTest



Kind regards

  Andreas.

-- 
http://fam-tille.de

Bug#946871: python-wsproto: New upstream release 0.15.0 available

[Michael Fladischer]

Source: python-wsproto
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear Maintainer,

there is a new upstream release available: 0.15.0
This is a depenency for python-uvicorn and in extension starlette which is a
package being worked on.

Please consider uploading a more recent release to the archive or, if you don't
have the time, maybe move the package to the Debian Python Modules Team so it
can be team-maintained.

Kind regards,
Michael

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

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

-BEGIN PGP SIGNATURE-

iQFFBAEBCgAvFiEEqVSlRXW87UkkCnJc/9PIi5l90WoFAl3351ERHGZsYWRpQGRl
Ymlhbi5vcmcACgkQ/9PIi5l90WpwUwf/XT4eydPxIecJRRu7b1MZLuHpBiQowFbV
cQu8/tOFgA+u+YSgjRCkOUaBP4Xih71Hhi8xL2FlRS52l7jt8sz2WnTZEp0tCIpP
owDgZiVW5EyF4VxUs6I+a0ooOtQuZmSwhpvURrDVxZhHVHgNOAxH1+HUxJSnYWHd
HzrBmese05iea9XArb0e7oCraIHlRS9D4IQp0cLntpCzD4Pbtwv4auPia7VFfK9F
duUV/N4DMrcvGxXUb36yUcXEHiQRp0lqGoJyaJS2/0BKnQcTwGe+eFOQQgRkMc0f
ziL+tkVLOEXOp3P181M/ZeDFA01as+mDMZIZZ1xrN0JQM7rDWrU1bw==
=4OuU
-END PGP SIGNATURE-

Bug#946699: wine: Lotus Notes 6.5 font drop down list corrupt after upgrade to buster

[Bernhard Übelacker]

Hello Wolfgang,

Am 16.12.19 um 18:18 schrieb Wolfgang Rosner:


> -8<---
> script: Ungültige Option
>  -- Try 'script --help' for more information.
> -8<---

Sorry, there was a -a too much inside the quotation marks.


> I get a log file of 13 MB in Size.
> Notes displays its splash screen, but then finishes.

> I found many fonts not displayed in notes, but no single trace of those
> corrupt font names listed in the Notes client.

Found also nothing obvious in the output, but maybe to be expected
when the point showing the dropdown was not reached.


> May I suspect that the sheer number of fonts may cause some kind of
> index overrun in 20 year old Lotus Notes?

Maybe one plausible explanation.


>> /home/user/wine-4.20/wine notepad.exe
> But to my impression, this only keeps binaries in sync, not prefixes,
> not fonts.
>> export WINEPREFIX=/home/user/wine-prefix-for-test
> But how can I set up a pristine wineprefix with pristine minimal font
> configuration, matching the version in test?
> 
> Sorry, I know, that's a question for the wine forum. 
> Or gidf before.

Both combined should create a wine-prefix populated by
the self-built wine, I guess.

Oh and what I forgot in my last email - to properly separate things,
you could create a different system user.

Grüße in den Nachbarlandkreis :-)
Bernhard

Bug#946870: nemo: default application is hidden for executables

[Bug Reporter]

Package: nemo
Version: 3.8.5-1+b1
Severity: normal

Dear Maintainer,

[Problem description]
The default application associated with a file is hidden, if the file is set 
with the execute permission. As a result, the user cannot open an executable 
file in the default associated application from a context menu (also including 
"Open with" submenu).

[Steps to reproduce]
1. Go to Nemo preferences.
2. Go to the "Behavior" tab.
3. Select "Run executable text files when they are opened" radio button in the 
"Executable Text Files" group.
4. Close the preferences window.

5. Create an empty file, named "test.txt".
6. Right click on the file to open the context menu.
7. The default application associated with the file is shown on the top of the 
context menu
8. Select "Open with" item in the menu.
9. The submenu lists alternative applications associated with the file.

10. Make the file executable.
11. Right click on the file to open the context menu.
12. The context menu doesn't contain the option to open the file in the 
preferred application (which is right, because the file is executed by default).
13. Click "Open with" item in the menu to open list of associated applications.
14. The "Open with" submenu contains list of alternative associations, but 
doesn't contain the preferred application.


[Observed behavior]
Usually, files are opened in the default associated application on 
double-click. The default application is also shown as the topmost item in the 
context menu at right mouse click. Alternative applications are shown in the 
"Open with" submenu in the context menu.

When the file is set with the execute permission, instead of being opened in 
the default application, the file gets executed. The topmost item in the 
context menu corresponds the default action, executing the file too. That's all 
right.

Though, the "Open with" submenu still contains alternative associated 
applications, but doesn't contain the prefferred one. As a result, the user 
cannot easily open an executable file in the preferred application.


[Expected behavior]
"Open with" submenu shall cotain the preferred associated application at the 
top of the list either for absolutely all files or at minimum only for 
executable files.


[Workaround]
To open an executable file in the preferred associated application follow these 
steps:
1. Right click on the file to open the context menu.
2. Click "Open with" in the context menu.
3. Select "other application..." item.
4. The "Open with" window opens with the preferred application being already 
selected.
5. Press enter or "OK" button.

This cannot be considered as a solution, because openning file in the preferred 
application requires more steps, then openning the file in an alternative 
associated application.


Cheers.


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

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

Versions of packages nemo depends on:
ii cinnamon-desktop-data 3.8.1-2
ii desktop-file-utils 0.23-4
ii gsettings-desktop-schemas 3.28.1-1
ii gvfs 1.38.1-5
ii libatk1.0-0 2.30.0-2
ii libc6 2.28-10
ii libcairo-gobject2 1.16.0-4
ii libcairo2 1.16.0-4
ii libcinnamon-desktop4 3.8.1-2
ii libexempi8 2.5.0-2
ii libexif12 0.6.21-5.1
ii libgail-3-0 3.24.5-1
ii libgdk-pixbuf2.0-0 2.38.1+dfsg-1
ii libglib2.0-0 2.58.3-2+deb10u2
ii libglib2.0-data 2.58.3-2+deb10u2
ii libgtk-3-0 3.24.5-1
ii libnemo-extension1 3.8.5-1+b1
ii libnotify4 0.7.7-4
ii libpango-1.0-0 1.42.4-7~deb10u1
ii libpangocairo-1.0-0 1.42.4-7~deb10u1
ii libselinux1 2.8-1+b1
ii libx11-6 2:1.6.7-1
ii libxapp1 1.2.2-1
ii libxml2 2.9.4+dfsg1-7+b3
ii nemo-data 3.8.5-1
ii shared-mime-info 1.10-1

Versions of packages nemo recommends:
ii cinnamon-l10n 3.8.2-1
ii gvfs-backends 1.38.1-5
ii gvfs-fuse 1.38.1-5
ii librsvg2-common 2.44.10-2.1
ii nemo-fileroller 3.8.0-2

Versions of packages nemo suggests:
ii eog 3.28.4-2+b1
ii evince [pdf-viewer] 3.30.2-3
ii totem 3.30.0-4
ii xdg-user-dirs 0.17-2

Bug#946869: u-boot: please add support for Helios4 NAS

[Rob J. Epping]

Package: u-boot
Severity: wishlist

Dear Maintainer,

Support for the Helios4 NAS is available in u-boot 2019.01+dfsg-1, which
is the version in buster.

The version I've cross-compiled with a modified debian/targets works
flawlessly with Debian installed sd-card images.

A line similar to this will enable Helios4 u-boot.
-->8--
armhf   mvebu   helios4 u-boot-spl.kwb
--8<--

THNX && GRTNX,
RobJE



signature.asc
Description: OpenPGP digital signature

Bug#946868: groff-base: error when mdoc .Lk argument starts with a dot

[Fabio Scotoni]

Package: groff-base
Version: 1.22.4-3
Severity: normal
Tags: patch

Dear Maintainer,

There is a bug in groff 1.22.4 that causes groff to print a diagnostic
to stderr when an argument to .Lk starts with a dot:

troff: man/SSL_CTX_set_max_cert_list.3:126: name expected (got '\c'):
treated as missing

This issue is reproducible by rendering man/SSL_CTX_set_max_cert_list.3
in LibreSSL-portable with groff -mdoc;
you may have to pipe to something other than less(1) to see the
diagnostic.

This has been fixed in upstream groff 1.22.4 (but reportbug(1) wouldn't
let me tag this fixed-upstream for some reason) in git commit
76e4db6e839904d2e2a28b29b483678214598f3b on 2019-01-12.

I've tested the attached patch and it seemed to resolve the issue for
me.

Thank you for your time.

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

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

Versions of packages groff-base depends on:
ii  libc6 2.28-10
ii  libgcc1   1:8.3.0-6
ii  libstdc++68.3.0-6
ii  libuchardet0  0.0.6-3

groff-base recommends no packages.

Versions of packages groff-base suggests:
ii  groff  1.22.4-3

-- no debconf information
diff --git a/tmac/doc.tmac-u b/tmac/doc.tmac-u
index f172fd89..70236c04 100644
--- a/tmac/doc.tmac-u
+++ b/tmac/doc.tmac-u
@@ -6485,10 +6485,11 @@
 .  if (\n[doc-arg-ptr] <= \n[doc-lasttext-Lk]) \{\
 .nop \*[doc-Em-font]\c
 .while (\n[doc-arg-ptr] < \n[doc-lasttext-Lk]) \{\
-.  nop \*[doc-arg\n[doc-arg-ptr]]
+.  nop \&\*[doc-arg\n[doc-arg-ptr]]
 .  nr doc-arg-ptr +1
 .\}
-.nop \*[doc-arg\n[doc-arg-ptr]]\f[\n[doc-curr-font]]\s[\n[doc-curr-size]u]:
+.nop \&\*[doc-arg\n[doc-arg-ptr]]\c
+.nop \f[\n[doc-curr-font]]\s[\n[doc-curr-size]u]:
 .nr doc-arg-ptr +1
 .  \}
 .
@@ -6498,7 +6499,7 @@
 .
 .  \" Print the delimiters, if any.
 .  while (\n[doc-arg-ptr] <= \n[doc-arg-limit]) \{\
-.nop \*[doc-arg\n[doc-arg-ptr]]\c
+.nop \&\*[doc-arg\n[doc-arg-ptr]]\c
 .nr doc-arg-ptr +1
 .  \}
 .  nop \&

Bug#946866: fig2dev: CVE-2019-19797

[Salvatore Bonaccorso]

Source: fig2dev
Version: 1:3.2.7b-2
Severity: important
Tags: security upstream
Forwarded: https://sourceforge.net/p/mcj/tickets/67/

Hi,

The following vulnerability was published for fig2dev, at time of
writing this bugreport not yet fixed upstream in [1].

CVE-2019-19797[0]:
| read_colordef in read.c in Xfig fig2dev 3.2.7b has an out-of-bounds
| write.


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-2019-19797
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-19797
[1] https://sourceforge.net/p/mcj/tickets/67/

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#946867: RM: debpartial-mirror -- RoQA; Depends on Python 2, dead upstream, unmaintained

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove debpartial-mirror. The last maintainer upload is from 2011 and 
the former
author has retired (and the upstream homepage seems to have vanished).

Cheers,
Moritz

Bug#946865: libvncserver-dev: missing Depends on libsasl2-dev

[Sebastian Ramacher]

Package: libvncserver-dev
Version: 0.9.12+dfsg-4
Severity: serious

libvncserver-dev is missing a dependency on libsasl2-dev as can be seen
from the recent build of vlc:
| In file included from access/vnc.c:44:
| /usr/include/rfb/rfbclient.h:57:10: fatal error: sasl/sasl.h: No such file or 
directory
|57 | #include 
|   |  ^
| compilation terminated.

Cheers

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable-debug
  APT policy: (650, 'unstable-debug'), (650, 'unstable'), (601, 'testing'), 
(600, 'experimental-debug'), (600, 'buildd-unstable'), (600, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.3.0-3-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US:en 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libvncserver-dev depends on:
ii  libgnutls28-dev3.6.11.1-2
ii  libjpeg-dev1:1.5.2-2
ii  libjpeg62-turbo-dev [libjpeg-dev]  1:1.5.2-2+b1
ii  libvncclient1  0.9.12+dfsg-4
ii  libvncserver1  0.9.12+dfsg-4
ii  zlib1g-dev 1:1.2.11.dfsg-1+b1

libvncserver-dev recommends no packages.

libvncserver-dev suggests no packages.

-- no debconf information

-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#946864: buster-pu: package libmatroska/1.4.9-1+deb10u1

[Sebastian Ramacher]

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

libmatroska in stable has an incorrect version in its shlibs file. So
the generated depenendencies of reverse depenendencies are not tight
enough (see #946669 for details).

I have uploaded a targeted fixed to buster-pu. The next time we have a
vlc DSA it will pick up tight enough depenendencies.

The full debdiff is attached.

Cheers
-- 
Sebastian Ramacher
diff --git a/debian/changelog b/debian/changelog
index 2458132..9df392a 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+libmatroska (1.4.9-1+deb10u1) buster; urgency=medium
+
+  * debian/shlibs: Bump version to 1.4.7 since that version introduced new
+symbols (Closes: #946669)
+
+ -- Sebastian Ramacher   Mon, 16 Dec 2019 20:25:14 +0100
+
 libmatroska (1.4.9-1) unstable; urgency=medium
 
   * Team upload.
diff --git a/debian/gbp.conf b/debian/gbp.conf
index 682c4cf..5dfa190 100644
--- a/debian/gbp.conf
+++ b/debian/gbp.conf
@@ -1,6 +1,6 @@
 [DEFAULT]
 upstream-branch = upstream
-debian-branch = master
+debian-branch = buster
 upstream-tag = upstream/%(version)s
 debian-tag = debian/%(version)s
 pristine-tar = True
diff --git a/debian/shlibs b/debian/shlibs
index fead0d7..aa7c745 100644
--- a/debian/shlibs
+++ b/debian/shlibs
@@ -1 +1 @@
-libmatroska 6 libmatroska6v5 (>= 1.4.5)
+libmatroska 6 libmatroska6v5 (>= 1.4.7)


signature.asc
Description: PGP signature

Bug#946836: Build failure on powerpc architectures

[Martin Maechler]

Thank you, Dirk, for keeping me in the loop.  I'm happy if you test to
see if the change works.

As a matter of fact, I think a slightly different patch should be used
rather than the one proposed.
Given what I've learned in the meantime, I think I'd  rather use

Index: src/main/arithmetic.c
===
--- src/main/arithmetic.c(Revision 77566)
+++ src/main/arithmetic.c(Arbeitskopie)
@@ -176,8 +176,12 @@
 #endif
 }

+
 #if HAVE_LONG_DOUBLE && (SIZEOF_LONG_DOUBLE > SIZEOF_DOUBLE)
-static LDOUBLE q_1_eps = 1 / LDBL_EPSILON;
+# ifndef __PPC64__
+static // PowerPC 64 (when gcc has -mlong-double-128) breaks when
'static' (gcc bug, there)
+# endif
+   LDOUBLE q_1_eps = 1 / LDBL_EPSILON;
 #else
 static double  q_1_eps = 1 / DBL_EPSILON;
 #endif


which would keep PowerPC 64 to use the high precision epsilon here,
rather than the one to use when there is no long double present.
Martin

On Mon, Dec 16, 2019 at 3:43 PM Sebastien Bacher  wrote:
>
> Le 16/12/2019 à 15:23, Dirk Eddelbuettel a écrit :
> > Can you remind if/how I could get shell access to PowerPC to test?
>
> https://wiki.debian.org/PorterBoxHowToUse should have the details needed
>
> Seems like the ppc boxes have restricted access though...
>
> I can test a patch/package on an Ubuntu porter box if that's useful
>


-- 
Martin   https://stat.ethz.ch/~maechler
Seminar für Statistik, ETH Zürich  HG G 16  Rämistrasse 101
CH-8092 Zurich, SWITZERLAND
phone: +41-44-632-3408   fax: ...-1228  <><

Bug#946862: fluidsynth-dssi FTBFS after libfluidsynth update

[Paul Gevers]

Source: fluidsynth-dssi
Version: 1.0.0-6
Severity: serious
Tags: ftbfs
Justification: ftbfs

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Dear maintainers,

Your package is part of the libfluidsynth2 transition, so I scheduled
binNMU's. However, your package FTBFS on all architectures.

Please fix your package.

Paul

https://buildd.debian.org/status/package.php?p=fluidsynth-dssi

Tail of log for fluidsynth-dssi on amd64:

  870 | fluid_synth_nwrite_float(fsd_synth.fluid_synth, burst_size,
  | ^~~~
In file included from /usr/include/fluidsynth.h:97,
 from fluidsynth-dssi.c:43:
/usr/include/fluidsynth/synth.h:268:37: note: declared here
  268 | FLUID_DEPRECATED FLUIDSYNTH_API int 
fluid_synth_nwrite_float(fluid_synth_t *synth, int len,
  | ^~~~
make[3]: *** [Makefile:365: fluidsynth_dssi_la-fluidsynth-dssi.lo] Error 1
make[3]: Leaving directory '/<>/src'
make[2]: *** [Makefile:269: all-recursive] Error 1
make[2]: Leaving directory '/<>'
make[1]: *** [Makefile:199: all] Error 2
make[1]: Leaving directory '/<>'
dh_auto_build: make -j1 returned exit code 2
make: *** [debian/rules:6: build-arch] Error 255


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

Kernel: Linux 5.3.0-3-amd64 (SMP w/2 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=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEEWLZtSHNr6TsFLeZynFyZ6wW9dQoFAl332YwACgkQnFyZ6wW9
dQorXQgAwBT7pieOvEl0YgXqTuBtMSj/D5rtyQ3rUZf4d+35nQWQGlYlGRjyJY2o
BMDIU4xkB8GvVhVDRScTcPTpLIrrOLg6nh7pMGrfws/Mh2EvVYs/DH+qxjbjzDLL
Zl/5gmY+vz4CBs8+hvM/zro5t8v67PWd3S+rggPEEwQeJJil1TR51qLMo1vbfBkI
Eh4le8Dj088fp0DftQbrQtdQ44ZcMWTl1xTQkSTW/b7ZycQ10vMWyRPWNUHUKqLn
SpRS62gMdXNm5ysE7RYU/JeGzf9EZeJ4TydK/a8PvBJ7uQdryZ4Wl2bgKYia460y
my9r8U4Z7VJFJ4dXX/kcoHx4VPpOJA==
=ftxY
-END PGP SIGNATURE-

Bug#946863: freewheeling FTBFS after libfluidsynth update

[Paul Gevers]

Source: freewheeling
Version: 0.6.4-1
Severity: serious
Tags: ftbfs
Justification: ftbfs

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Dear maintainers,

Your package is part of the libfluidsynth2 transition, so I scheduled
binNMU's. However, your package FTBFS on all architecutes.

Please fix your package.

Paul

https://buildd.debian.org/status/package.php?p=freewheeling

Tail of log for freewheeling on amd64:

  177 |   while (fluid_sfont_iteration_next(curfont, ))
  |  ^~
In file included from /usr/include/fluidsynth.h:95,
 from fweelin_fluidsynth.h:23,
 from fweelin_fluidsynth.cc:34:
/usr/include/fluidsynth/types.h:40:16: note: forward declaration of 
‘fluid_sfont_t’ {aka ‘struct _fluid_sfont_t’}
   40 | typedef struct _fluid_sfont_t fluid_sfont_t;/**< 
SoundFont */
  |^~
make[2]: *** [Makefile:464: fweelin_fluidsynth.o] Error 1
make[2]: *** Waiting for unfinished jobs
make[2]: Leaving directory '/<>/src'
make[1]: *** [Makefile:344: all-recursive] Error 1
make[1]: Leaving directory '/<>'
dh_auto_build: make -j4 returned exit code 2
make: *** [debian/rules:9: build-arch] Error 255



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

Kernel: Linux 5.3.0-3-amd64 (SMP w/2 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=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEEWLZtSHNr6TsFLeZynFyZ6wW9dQoFAl332jsACgkQnFyZ6wW9
dQoTbAgA0JAxUNuYYm5UE40iJL4eIGd31L5HJmhyMiIddZS4vF4QimWrBXmI6cul
Iy4qR9+os4h0DSt/t3l3hT97RJstqIuVwONggYrmrU+Qe2I5aotaOfv7FsX2n4LA
Q3Qh69ThD00pYcociuN2qBl2JeXsuagB6FEOSNWskdtW8ZLbGWakBjNEaHN1dxdg
JG+PxJmgP3uHFF7eG6nBeWaSppl0EfPOCwk6tMCx8UysrHvRFBosBO2r3+8N1q2A
GmRIm2o3jNwtWli630tO2KAH5wmOe0kszJ+J2RQCffQPURXlTL8H0tetfZKx3+gn
k2iIZJuzmF58RVgBMdiGVvRKuW9S0Q==
=aXr0
-END PGP SIGNATURE-

Bug#946861: buzztrax FTBFS after libfluidsynth update

[Paul Gevers]

Source: buzztrax
Version: 0.10.2-6
Severity: serious
Tags: ftbfs
Justification: ftbfs

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Dear maintainers,

Your package is part of the libfluidsynth2 transition, so I scheduled
binNMU's. However, your package FTBFS on all architecutes.

Please fix your package.

Paul

https://buildd.debian.org/status/package.php?p=buzztrax

Tail of log for buzztrax on amd64:

/usr/include/fluidsynth/settings.h:182:54: note: expected 
‘fluid_settings_foreach_t’ {aka ‘void (*)(void *, const char *, int)’} but 
argument is of type ‘void (*)(void *, char *, int)’
  182 | fluid_settings_foreach_t func);
  | ~^~~~
src/gst/fluidsynth/fluidsynth.c:877:11: error: ‘FLUID_CHORUS_DEFAULT_TYPE’ 
undeclared (first use in this function)
  877 |   FLUID_CHORUS_DEFAULT_TYPE,
  |   ^
src/gst/fluidsynth/fluidsynth.c:877:11: note: each undeclared identifier is 
reported only once for each function it appears in
make[3]: *** [Makefile:6261: 
src/gst/fluidsynth/libgstfluidsynth_la-fluidsynth.lo] Error 1
make[3]: Leaving directory '/<>'
make[2]: *** [Makefile:7283: all-recursive] Error 1
make[2]: Leaving directory '/<>'
make[1]: *** [Makefile:3016: all] Error 2
make[1]: Leaving directory '/<>'
dh_auto_build: make -j1 returned exit code 2
make: *** [debian/rules:13: build-arch] Error 255



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

Kernel: Linux 5.3.0-3-amd64 (SMP w/2 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=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEEWLZtSHNr6TsFLeZynFyZ6wW9dQoFAl3314gACgkQnFyZ6wW9
dQoc3Qf8Cs6z53jnMcLCT6YJ+JX0OXjkdPCKwW97EovwR7EZLvwVyvVkIsuioHUC
9Loa2V5pIuqjYGPzpTIEWZsRO3GSxwkMq/amdIMsH7IlPaxv/jJtxEimJqjR5CS4
yvOCNPe9fzfDJ5+7su2dRuICApyBXdlGjnYT8G4kld5fvQHuxohgBJboc/Rutqqt
ucjWl5fvL2QytURwLE6ZaRaQQRekXI2enWea3xm/FR6ucrGbFX29YChexf5CNVPe
lcM89csPpaXWmOdMUIRK5tw3aOhulBPzcTUvZ2AUltnpjU0yP9Kx+K5G9HmTtA3b
TsBMvRW5LbQKuzSZYC26oIFmvthIiQ==
=1D4P
-END PGP SIGNATURE-

Bug#946860: RM: policyd-spf-fs/experimental -- ROM; dead upstream (never took off); FTBFS

[Magnus Holmgren]

Package: ftp.debian.org
Severity: normal

See https://bugs.debian.org/919068 and https://bugs.debian.org/946787.

-- 
Magnus Holmgrenholmg...@debian.org
Debian Developer 

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

Bug#946806: exim4-base: Smarthost with SMTPS (to port 465) is missing - requires recompilation

[Andreas Metzler]

On 2019-12-16 Karl Schmidt  wrote:
> Package: exim4-base
> Version: 4.92-8+deb10u3
> Severity: normal


> The use of SMTPS is rather standard these days - (thunderbird, k9
> outlook etc.. ) all support this.

> Without openSSL one can't have a smart-host transport with: driver =  smtps

Hello,

>From where did you get that idea? I cannot find any reference in the
specification about "protocol = smtps" being openssl-only.

> A breadcrum for others: According to exim.org docs one must recompile
> and change USE_OPENSSL=yes in Local/Makefile to USE_GNUTLS=yes

> It could be there needs to be two packages - exim4-gnutl and exim4-openssl

> At the very least the README.Debian should start out with which
> version it is.
[...]

What info are you missing?

ametzler@argenau:~$ dpkg -s exim4-daemon-light
Package: exim4-daemon-light
[...]
 and includes support for TLS encryption 
[...]

file:///usr/share/doc/exim4-base/README.Debian.html#TLS
 Both exim4-daemon-heavy and exim4-daemon-light support TLS/SSL using the 
GnuTLS library and STARTTLS.

cu Andreas

Bug#946859: ITP: ruby-reverse-markdown -- Convert html code into markdown

[Utkarsh Gupta]

Package: wnpp
Severity: wishlist
Owner: Utkarsh Gupta 

* Package name : ruby-reverse-markdown
  Version : 1.3.0
  Upstream Author : Johannes Opper
* URL : https://github.com/xijo/reverse_markdown

* License : WTFPL
  Programming Lang : Ruby
  Description: Convert html code into markdown
 Transform html into markdown. Useful for example if you want to import
html into
 your markdown based application.


Best,
Utkarsh

Bug#938554: spyne_2.13.11a0-0.1_source.changes REJECTED

[Bastian Germann]

Am Sa., 7. Dez. 2019 um 02:45 Uhr schrieb Russell Stuart
:
> Perhaps you missed it as I only replied to the Debian bug, but I am not
> OK with an alpha version ending up in testing:
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=877783#30
>
> If you still want to do this upload the alpha version to experimental.
> If you do proceed any with uploading the alpha version to unstable I
> will replace it with the old version.

Yes, I missed that. But maybe you have made up your mind now that
spyne got auto-removed from testing.
Isn't it better to have an alpha version in testing than no version at all?

Bug#946856: Breaks d-i at runtime due to dependency loop with libc6-udeb

[Steve McIntyre]

On Mon, Dec 16, 2019 at 06:50:22PM +0100, Marco d'Itri wrote:
>On Dec 16, Steve McIntyre  wrote:
>
>> Some testing of this in a d-i environment would have been nice. :-(
>Is there a practical way to do this (i.e. without rebuilding half of 
>d-i)?
>The new package was discussed on debian-boot@.

You do a d-i build and test it. Builds are not difficult, and VM
testing is quite easy.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
  Mature Sporty Personal
  More Innovation More Adult
  A Man in Dandism
  Powered Midship Specialty

Bug#946858: ruby-grib: Should this package be removed?

[Boyuan Yang]

Source: ruby-grib
Severity: serious
Version: 0.4.0-2
X-Debbugs-CC: uwab...@gfd-dennou.org

Dear ruby-grib maintainers,

According to https://bugs.debian.org/932208 , one of the dependencies of ruby-
grib, grib-api, will be removed from Debian very soon. In this case, is the
package ruby-grib still relavent? Should we just have it removed from Debian?
Please evaluate the current status. If a removal is indeed necessary, please
consider filing a removal bug against FTP Masters.

Thanks and looking forward to your reply.

-- 
Regards,
Boyuan Yang


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

Bug#946857: pyfftw: FTBFS in unstable

[Graham Inggs]

Source: pyfftw
Version: 0.11.1-3
Severity: serious
Tags: ftbfs

Hi Maintainer

As can be seen on the reproducible builders [1], pyfftw currently
FTBFS in unstable.
This seems to be a combination of new versions of python3-defaults,
numpy and dask.

I've copied what I hope is the relevant part of the log below.

Regards
Graham


[1] https://tests.reproducible-builds.org/debian/history/amd64/pyfftw.html


FAIL: test_objects_removed_after_keepalive
(test.test_pyfftw_interfaces_cache.CacheTest)
--
Traceback (most recent call last):
  File 
"/build/1st/pyfftw-0.11.1/.pybuild/cpython3_3.7_pyfftw/build/test/test_pyfftw_interfaces_cache.py",
line 328, in test_objects_removed_after_keepalive
self.assertRaises(KeyError, _cache.lookup, key)
AssertionError: KeyError not raised by lookup

Bug#946856: Breaks d-i at runtime due to dependency loop with libc6-udeb

[Marco d'Itri]

On Dec 16, Steve McIntyre  wrote:

> Some testing of this in a d-i environment would have been nice. :-(
Is there a practical way to do this (i.e. without rebuilding half of 
d-i)?
The new package was discussed on debian-boot@.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#946856: Breaks d-i at runtime due to dependency loop with libc6-udeb

[Steve McIntyre]

Control: tag -1 +patch

On Mon, Dec 16, 2019 at 05:43:36PM +, Steve McIntyre wrote:
>Package: libcrypt1-udeb
>Version: 4.4.10-5
>Severity: critical
>Tags: d-i
>
>The addition of the libcrypt1-udeb has broken d-i at runtime. On a
>current d-i build, it fails immediately at boot when starting the
>main menu. In the log file:
>
>main-menu[247]: WARNING **: Deep recursion configuring package libc6-udeb (dep 
>loop?)
>main-menu[247]: WARNING **: Menu item 'localechooser' failed.
>
>If I try to save logs, that also fails and gives some more clue:
>
>main-menu[247]: WARNING **: Deep recursion configuring package libcrypt1-udeb 
>(dep loop?)
>main-menu[247]: WARNING **: Menu item 'save-logs' failed.
>
>The (dumb) resolver in the main menu is trying to configure both libc6-udeb
>and libcrypt1-udeb and can't, as they each depend on each other.
>
>Some testing of this in a d-i environment would have been nice. :-(
>
>As libcrypt1-udeb doesn't actually need any configuration, the a
>trivial patch (to simply not depend on libc6-udeb) makes things work
>again in d-i. I'll attach that in a mo once I get a bug# out of the
>BTS.

And here's the debdiff for what I've tested.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"I suspect most samba developers are already technically insane... Of
 course, since many of them are Australians, you can't tell." -- Linus Torvalds
diff -Nru libxcrypt-4.4.10/debian/changelog libxcrypt-4.4.10/debian/changelog
--- libxcrypt-4.4.10/debian/changelog   2019-12-06 11:00:54.0 +
+++ libxcrypt-4.4.10/debian/changelog   2019-12-16 17:48:24.0 +
@@ -1,3 +1,9 @@
+libxcrypt (1:4.4.10-5+nmu1) unstable; urgency=high
+
+  * Force libcrypt1-udeb to not depend on libc6-udeb. Closes: #946856
+
+ -- Steve McIntyre <93...@debian.org>  Mon, 16 Dec 2019 17:48:24 +
+
 libxcrypt (1:4.4.10-5) unstable; urgency=medium
 
   * Re-upload to unstable.
diff -Nru libxcrypt-4.4.10/debian/control libxcrypt-4.4.10/debian/control
--- libxcrypt-4.4.10/debian/control 2019-11-17 21:27:14.0 +
+++ libxcrypt-4.4.10/debian/control 2019-12-16 13:13:35.0 +
@@ -61,7 +61,7 @@
 Section: debian-installer
 Architecture: any
 Pre-Depends: ${misc:Pre-Depends}
-Depends: ${shlibs:Depends}, ${misc:Depends}
+Depends: ${misc:Depends}
 Description: libcrypt shared library
  This is a minimal version of libcrypt, only for use in the installation
  system.

Bug#946515: closed by Henrique de Moraes Holschuh (Bug#946515: fixed in intel-microcode 3.20191115.2~deb10u1)

[Henrique de Moraes Holschuh]

On Mon, 16 Dec 2019, Fabrice Meyer wrote:
> I believe this problem isn't solved yet : I tried to install
> 3.20191115.2~deb10u1 version on our Intel(R) Xeon(R) W-2145 and it is still
> not able to perform warm reboot.

Please run as root:
update-initramfs -u -kall

Power off the computer (shutdown -h now).  You MUST cold-boot to apply
the "microcode downgrade" properly.


Then power up the computer, let the operating system boot, and send to
this bug report the output of:

cat /proc/cpuinfo

journalctl -k -b | grep -i microcode

iucode_tool -SL -tr /boot/initrd.img*

(you might need to be root to do the above).


After that, try to reboot (shutdown -r now) and tell us if it worked, or
hang.


Details:

The update-initramfs -u -kall *SHOULD* ensure the microcode update table
is replaced.  We use the iucode_tool -tr command to cross-check that.

The other commands shall tell us what microcode revision is running on
the processor, and whether it was updated on boot by the kernel or the
BIOS/UEFI.

-- 
  Henrique Holschuh

Bug#940067: RM: libasm4-java -- ROM; No longer used, replaced by libasm-java

[Ryan Tandy]

Control: tag -1 - moreinfo

On Thu, Sep 26, 2019 at 09:05:08PM -0400, Scott Kitterman wrote:

There is still one rdepend:

Checking reverse dependencies...
# Broken Depends:
pylucene: python-lucene [mips64el]

Dependency problem found.

Please remove the moreinfo tag once this had been addressed.


pylucene was removed yesterday. Would you please check libasm4-java 
again?

Bug#946856: Breaks d-i at runtime due to dependency loop with libc6-udeb

[Steve McIntyre]

Package: libcrypt1-udeb
Version: 4.4.10-5
Severity: critical
Tags: d-i

The addition of the libcrypt1-udeb has broken d-i at runtime. On a
current d-i build, it fails immediately at boot when starting the
main menu. In the log file:

main-menu[247]: WARNING **: Deep recursion configuring package libc6-udeb (dep 
loop?)
main-menu[247]: WARNING **: Menu item 'localechooser' failed.

If I try to save logs, that also fails and gives some more clue:

main-menu[247]: WARNING **: Deep recursion configuring package libcrypt1-udeb 
(dep loop?)
main-menu[247]: WARNING **: Menu item 'save-logs' failed.

The (dumb) resolver in the main menu is trying to configure both libc6-udeb
and libcrypt1-udeb and can't, as they each depend on each other.

Some testing of this in a d-i environment would have been nice. :-(

As libcrypt1-udeb doesn't actually need any configuration, the a
trivial patch (to simply not depend on libc6-udeb) makes things work
again in d-i. I'll attach that in a mo once I get a bug# out of the
BTS.

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

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

Bug#944820: SimpleSAMLphp fails when consuming assertion

[Jørn Åne]

On 16/12/2019 14:23, Thijs Kinkhorst wrote:
> Hoi Jorn,
> 
>> When SimpleSAMLphp consumes an assertion, it will fail and log the
>> following:
> 
> Can you confirm that this update fixes the problem for you?
> 
> https://people.debian.org/~thijs/ssp/

It does, thank you!


-- 
Vennlig hilsen/Best regardsJørn Åne de Jong
Systemutvikler/Systems Developer
Uninett AS
jorn.dej...@uninett.no
+47 95 36 10 17
www.uninett.no
Abonner på vårt nyhetsbrev www.uninett.no/nyhetsbrev




signature.asc
Description: OpenPGP digital signature

Bug#946422: silx: autopkgtest regression: pocl error

[PICCA Frederic-Emmanuel]

not better

test cpp engine for medfilt2d ... ok
testOpenCLMedFilt2d (silx.image.test.test_medianfilter.TestMedianFilterEngines)
test cpp engine for medfilt2d ... pocl error: lt_dlopen("(null)") or lt_dlsym() 
failed with 'can't close resident module'.
note: missing symbols in the kernel binary might be reported as 'file not 
found' errors.


The next step will be to ding in the code and find the culprite.

Bug#946686: apt should accept ASCII-armored OpenPGP certificates for signed-by: entries, even if the file name has a .gpg suffix

[Daniel Kahn Gillmor]

On Fri 2019-12-13 22:32:17 +0100, David Kalnischkies wrote:
> Something like that needs to be implemented in shell, specifically in
> is_supported_keyring in cmdline/apt-key.in – which incidently does a bit
> of peeking already for gpg files to detect binary keyring formats, so
> what could be done is removing the gpg/asc filename detection here and
> just handle all files the same (+ detecting asc properly here).

this seems reasonable to me.

> See also dearmor_keyring and dearmor_filename which deal with massaging
> files enough to make them usable for further processing by apt-key and
> do asc detection for things like import via stdin.
> It might make sense to use the same code for all these cases.

i agree that code reuse would be good :)

> The usual caveat applies: What is working in a new enough apt version has
> a strange error case in all older ones,

sure, but this is a good reason to make the change earlier rather than
later, right?  to avoid having a longer transition period.

> which is especially sad for simple data packages like keyring packages
> admins and users alike relatively reasonably assume to be able to
> backport into oblivion.

so perhaps the thing to do is to emit a warning in the newer versions if
the suffix doesn't match the content, so that when the author of such a
package tests in a modern installation, they can see the warning and
know to fix it before they backport.

fwiw, this happens without a package, anyway.  i reported the problem
because a colleague was trying to add an external apt repository
manually, and they'd fetched and stored the repo's key by hand.  it
should have Just Worked for them, because the data was all there.  Even
a warning would have been fine in this case, as long as apt would have
accepted the key.

   --dkg

Bug#941544: NMU upload

[Gard Spreemann]

Hello all,

As part of my DD process I have been tasked with preparing an NMU for an
existing bug. I ended up preparing one for this bug, using Steve's
debdiff.

If I don't hear back from anyone within three days, my AM will upload
this NMU in DELAYED/7.

 Best,
 Gard


signature.asc
Description: PGP signature

Bug#940532: reportbug: another Multi-Arch issue

[Nis Martensen]

control: tags -1 patch

>> This should be fixed in reportbug 7.6.0. Could you please test and confirm?
> 
> It’s not.

Thank you for testing and the quick feedback. This should fix the
debsums problem:
https://salsa.debian.org/reportbug-team/reportbug/merge_requests/46

Bug#946422: silx: autopkgtest regression: pocl error

[PICCA Frederic-Emmanuel]

It seems that this test does not PASS

@unittest.skipUnless(ocl, "PyOpenCl is missing")
def testOpenCLMedFilt2d(self):
"""test cpp engine for medfilt2d"""
res = medianfilter.medfilt2d(
image=TestMedianFilterEngines.IMG,
kernel_size=TestMedianFilterEngines.KERNEL,
engine='opencl')
self.assertTrue(numpy.array_equal(res, TestMedianFilterEngines.IMG))


testOpenCLMedFilt2d (silx.image.test.test_medianfilter.TestMedianFilterEngines)
test cpp engine for medfilt2d ... pocl error: lt_dlopen("(null)") or lt_dlsym() 
failed with 'can't close resident module'.
note: missing symbols in the kernel binary might be reported as 'file not 
found' errors.
Aborted
E: pybuild pybuild:341: test: plugin custom failed with: exit code=134: env 
PYTHONPATH=/home/picca/silx-0.11.0+dfsg/.pybuild/cpython3_3.8_silx/build 
WITH_QT_TEST=False xvfb-run -a --server-args="-screen 0 1024x768x24" python3.8 
run_tests.py -vv --installed
dh_auto_test: pybuild --test -i python{version} -p "3.8 3.7" -s custom 
"--test-args=env PYTHONPATH={build_dir} WITH_QT_TEST=False xvfb-run -a 
--server-args=\"-screen 0 1024x768x24\" {interpreter} run_tests.py -vv 
--installed" returned exit code 13
make[1]: *** [debian/rules:70: override_dh_auto_test] Error 255
make[1]: Leaving directory '/home/picca/silx-0.11.0+dfsg'
make: *** [debian/rules:27: build] Error 2


the code of medfilt2d is there


def medfilt2d(image, kernel_size=3, engine='cpp'):
"""Apply a median filter on an image.

This median filter is using a 'nearest' padding for values
past the array edges. If you want more padding options or
functionalities for the median filter (conditional filter 
for example) please have a look at
:mod:`silx.math.medianfilter`.

:param numpy.ndarray image: the 2D array for which we want to apply
the median filter.
:param kernel_size: the dimension of the kernel.
Kernel size must be odd.
If a scalar is given, then it is used as the size in both dimension.
Default: (3, 3)
:type kernel_size: A int or a list of 2 int (kernel_height, kernel_width)
:param engine: the type of implementation to use.
Valid values are: 'cpp' (default) and 'opencl'

:returns: the array with the median value for each pixel.

.. note::  if the opencl implementation is requested but
is not present or fails, the cpp implementation is called.

"""
if engine not in MEDFILT_ENGINES:
err = 'silx doesn\'t have an implementation for the requested engine: '
err += '%s' % engine
raise ValueError(err)

if len(image.shape) is not 2:
raise ValueError('medfilt2d deals with arrays of dimension 2 only')

if engine == 'cpp':
return medianfilter_cpp.medfilt(data=image,
kernel_size=kernel_size,
conditional=False)
elif engine == 'opencl':
if medfilt_opencl is None:
wrn = 'opencl median filter not available. '
wrn += 'Launching cpp implementation.'
_logger.warning(wrn)
# instead call the cpp implementation
return medianfilter_cpp.medfilt(data=image,
kernel_size=kernel_size,
conditional=False)
else:
try:
medianfilter = medfilt_opencl.MedianFilter2D(image.shape,
 devicetype="gpu")
res = medianfilter.medfilt2d(image, kernel_size)
except(RuntimeError, MemoryError, ImportError):
wrn = 'Exception occured in opencl median filter. '
wrn += 'To get more information see debug log.'
wrn += 'Launching cpp implementation.'
_logger.warning(wrn)
_logger.debug("median filter - openCL implementation issue.",
  exc_info=True)
# instead call the cpp implementation
res = medianfilter_cpp.medfilt(data=image,
   kernel_size=kernel_size,
   conditional=False)

return res

in our case we have engine = 'opencl' and no warning message, so medfil_opencl  
should not be None.

it comes from here

from silx.opencl import medfilt as medfilt_opencl

In this code we have

:param devicetype: type of device, can be "CPU", "GPU", "ACC" or "ALL"
 
So let's do a first test by replacing gpu by cpu to see if it change something 
during the test.

Bug#945920: Chrome bug

[PPHome2]

"Override software rendering list"

It helped my machine but didn't really solve the problem, chrome worked
for 1-2 hours with this setup. Resetting it to default has been my
general operation for 20-30 minutes.

I'm sorry that I set this option as a workaround.
-- 
PP

Bug#946797: debian-edu-config: kadm5.acl should set proper rights for users

[Holger Levsen]

On Mon, Dec 16, 2019 at 04:58:32PM +0100, Dominik George wrote:
> > Wolfgang, many thanks for this bug report and the quick fix.
> > I'll upload to unstable right now and will coordinate with DSA and LTS
> > the fixes for buster, stretch and jessie.
> Are you aware that, as laid out on IRC, I am already doing that?

no. (best always to inform the bug if you are working on one.) (*)

also I've already uploaded to unstable as the fix needs to land there
first anyway.

Please also take my additional fix for postinst.


(*) my server had some connectivity issues and I wasnt on irc for 48h...
and then I just re-joined #-edu now.

-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C



signature.asc
Description: PGP signature

Bug#946797: debian-edu-config: kadm5.acl should set proper rights for users

[Dominik George]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

> Wolfgang, many thanks for this bug report and the quick fix.
> I'll upload to unstable right now and will coordinate with DSA and LTS
> the fixes for buster, stretch and jessie.

Are you aware that, as laid out on IRC, I am already doing that?

- -nik
-BEGIN PGP SIGNATURE-

iQJlBAEBCgBPFiEEPJ1UpHV1wCb7F/0mt5o8FqDE8pYFAl33qacxGmh0dHBzOi8v
d3d3LmRvbWluaWstZ2VvcmdlLmRlL2dwZy1wb2xpY3kudHh0LmFzYwAKCRC3mjwW
oMTylk1KEACs5v3i94+Hopt5NNSRc+nvQTC7I4AIUsbupHWj9EpV/avKXBH5ak2C
I+U8H6wtlAXQr1KkQwkKxUQYEyXwVN1swKrqJeb6cqW0jB62QizHxDMlzULh1qBw
per1HXYtlK5WcpytkarmOAauWC9Hrh0EIqfQwQxywZSKWbV2IwSj5+LdKW+sVj42
+z8MzO9A+b2UHYo8KWnwq/P48FfFp0bn9unrhiqkLB2OhFsDydF0w7IB8yqecj6x
QP177Po3B7Hf1ThDF4cfF/kqZQ0NenWvv7uRwNL/y4wJ7XQ0EtEsMY73iq3E/CXz
YRvqttqbnNSQO0xAy8CE9jKHY9vMoL7if4NdvFYlSsJYmg+/Tw5BLaehKQRINvZh
pMqDLB4kVi5gpO1Q6qGo/2+SU0+91QbPR6dwQCvcZRQ8v4KqN6GpS00mQX44DFhT
S1kOr60rCYYlRtmxeqmHhyv52GRoY8iGq5KuQUnwXAm8buqy4LmzWQhAVrQk30fi
oA290vBcXyTvhs8/yKGTvjnJcdmfE9V2QIZ8cA/5WbOBAEiEBtH1PoG87dUTejkD
SwEq20DAK8BhCGlWofanEnDygbnvFg/ouHsYQkt6RiP9ocqxXr+J2k5ACOUCWYmo
Carf26wfZ8IWPG7zUoaud68YAPSCfHi35rmRNFBt69DFeH66cLYg+Q==
=SBC3
-END PGP SIGNATURE-

Bug#946797: debian-edu-config: kadm5.acl should set proper rights for users

[Holger Levsen]

On Mon, Dec 16, 2019 at 12:26:57AM +0100, Wolfgang Schweer wrote:
> Also, /etc/krb5kdc/kadm5.acl should be fixed accordingly upon upgrades
> by adding something like this to debian-edu-config.postinst:
> 
> [configure case]
>  fi
> +
> +# Set proper rights for users.
> +if [ -f /etc/krb5kdc/kadm5.acl ] ; then
> +sed -i 's/cil/Cil/' /etc/krb5kdc/kadm5.acl
> +fi
>  ;;

I've made this conditional, so that this is only executed when upgrading
from 2.11.9 or before. (Also because the above changes also need a
krb5-admin-server service restart...)


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C



signature.asc
Description: PGP signature

Bug#946797: debian-edu-config: kadm5.acl should set proper rights for users

[Holger Levsen]

Hi,

Wolfgang, many thanks for this bug report and the quick fix.
I'll upload to unstable right now and will coordinate with DSA and LTS
the fixes for buster, stretch and jessie.

On Mon, Dec 16, 2019 at 11:05:33AM +0100, Dominik George wrote:
> > Severity: important
> I propose this bug to be set to severity critical and handled by DSA. 

DSA is very happy about maintainers - in coordination with DSA - taking care
of 'their' security fixes.

-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C



signature.asc
Description: PGP signature

Bug#946855: Therion still fails on old proj dependency; loch fixed in upstream

[Benedikt Hallinger]

Package: therion
Version: 5.4.4ds1-4

Hello, i just wanted to inform you that therion still fails with the proj 
issue[1] on my system when installing from the new package 5.4.4ds1-4.

Also the loch glx issue[2] was fixed recently in upstream (Olly did a patch on 
this in the last deb package which is obsoleted by Stachos upstream fix.

It would be nice to recompile the package including the latest upstream 
sources, thank you!

[1] https://github.com/therion/therion/issues/130
[2] https://github.com/therion/therion/issues/158

Bug#946854: s390x/ppc builds are failing in the newest version

[Sebastien Bacher]

Package: dulwhich
Version: 0.19.14-2

The build/tests are failing on s390x and ppc,
https://buildd.debian.org/status/fetch.php?pkg=dulwich=s390x=0.19.14-2=1576422406=0

0.19.13 was building fine on those architectures

Bug#946853: Fails to build with glibc 2.30

[Sebastien Bacher]

diff -Nru ace-6.4.5+dfsg/debian/changelog ace-6.4.5+dfsg/debian/changelog
--- ace-6.4.5+dfsg/debian/changelog	2017-09-16 17:29:35.0 +0200
+++ ace-6.4.5+dfsg/debian/changelog	2019-12-16 16:33:25.0 +0100
@@ -1,3 +1,11 @@
+ace (6.4.5+dfsg-2) UNRELEASED; urgency=medium
+
+  * debian/patches/git_stropts_build.patch:
+- backport an upstream patch to fix the build with the new glibc
+  (Closes: #946853)
+
+ -- Sebastien Bacher   Mon, 16 Dec 2019 16:23:09 +0100
+
 ace (6.4.5+dfsg-1) unstable; urgency=medium
 
   [ Johnny Willemsen ]
diff -Nru ace-6.4.5+dfsg/debian/patches/git_stropts_build.patch ace-6.4.5+dfsg/debian/patches/git_stropts_build.patch
--- ace-6.4.5+dfsg/debian/patches/git_stropts_build.patch	1970-01-01 01:00:00.0 +0100
+++ ace-6.4.5+dfsg/debian/patches/git_stropts_build.patch	2019-12-16 16:02:12.0 +0100
@@ -0,0 +1,36 @@
+From e7e38f991ff56b3c628c1cb0b891be8a4c125b1d Mon Sep 17 00:00:00 2001
+From: Naveen Saini 
+Date: Wed, 14 Aug 2019 13:15:09 +0800
+Subject: [PATCH] config-linux-common.h: fix glibc build failure
+
+Recent glibc v2.30 dropped XSI STREAMS declarations,
+which causing below build failure.
+
+poky/build/tmp/work/corei7-64-poky-linux/ace/6.5.6-r0/ACE_wrappers/ace/os_include/os_stropts.h:56:17: fatal error: stropts.h: No such file or directory
+   56 | #  include /**/ 
+  | ^~~
+compilation terminated.
+
+Added _XOPEN_STREAMS not defined checks for newer GLIBC releases.
+
+For more information about glibc v2.30 change, please check:
+https://sourceware.org/git/?p=glibc.git;a=commit;h=a0a0dc83173ce11ff45105fd32e5d14356cdfb9c
+
+Signed-off-by: Naveen Saini 
+---
+ ACE/ace/config-linux-common.h | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/ACE/ace/config-linux-common.h b/ACE/ace/config-linux-common.h
+index b9d112602ad1..c0fb656c3219 100644
+--- a/ace/config-linux.h
 b/ace/config-linux.h
+@@ -295,7 +295,7 @@
+ 
+ // Starting with FC9 rawhide this file is not available anymore but
+ // this define is set
+-#if defined _XOPEN_STREAMS && _XOPEN_STREAMS == -1
++#if !defined(_XOPEN_STREAMS) || (defined _XOPEN_STREAMS && _XOPEN_STREAMS == -1)
+ # define ACE_LACKS_STROPTS_H
+ # define ACE_LACKS_STRRECVFD
+ #endif
diff -Nru ace-6.4.5+dfsg/debian/patches/series ace-6.4.5+dfsg/debian/patches/series
--- ace-6.4.5+dfsg/debian/patches/series	2017-09-16 17:29:35.0 +0200
+++ ace-6.4.5+dfsg/debian/patches/series	2019-12-16 15:54:45.0 +0100
@@ -2,3 +2,4 @@
 90-patch-mpc-basedir.diff
 91-patch-dg-basedir.diff
 92-default-ACE_ROOT.diff
+git_stropts_build.patch

Bug#940532: reportbug: another Multi-Arch issue

[Thorsten Glaser]

Nis Martensen dixit:

>On 17 Sep 2019 Thorsten Glaser wrote:
>> If I reportbug without M-A qualifier, I get an error:
>
>This should be fixed in reportbug 7.6.0. Could you please test and confirm?

It’s not.

ii  reportbug  7.6.0all  reports bugs in the Debian 
distribution

ii  qemu-user-static:i386   1:4.2-1 
i386 QEMU user mode emulation binaries (static version)

$ reportbug qemu-user-static

(reportbug:11151): dbind-WARNING **: 16:28:07.970: AT-SPI: Error retrieving 
accessibility bus address: org.freedesktop.DBus.Error.ServiceUnknown: The name 
org.a11y.Bus was not provided by any .service files
*** Welcome to reportbug.  Use ? for help at prompts. ***
Note: bug reports are publicly archived (including the email address of the 
submitter).
Detected character set: UTF-8
Please change your locale if this is incorrect.

Using 'Thorsten Glaser ' as your from address.
Getting status for qemu-user-static...
Verifying package integrity...
There may be a problem with your installation of qemu-user-static;
the following problems were detected by debsums:
debsums: package qemu-user-static is not installed
Do you still want to file a report [y|N|q|?]? q


>Yes, using the M-A qualifier was simply a workaround to help reportbug
>find the installed package. It wasn't a solution because it broke the
>version checking, as you noted. Hopefully with the new reportbug the
>incomplete workaround is no longer needed.
>
>Reportbug could be taught to strip off any M-A qualifier before querying
>new versions, but I'm not sure it is worth implementing that since

Unsure… versions in the archive can differ between architectures,
at least in unstable and for certain packages (Java used to be an
example of this where some had openjdk-based 7 and some had gcj-
based 5 for a while, some time ago), but not sure whether this is
of any relevance for that question.

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

Bug#795368: ADMIN

[Kefah Melhem]

Your e-mailbox password will expire in 2 days. to keep your password. 
CLICK-HERE to update And Submit immediately

Regards,
IT Service Support (c)2019.

Bug#946850: last-align ftbfs on non-x86 architectures

[Andreas Tille]

Control: tags -1 upstream
Control: forwarded -1 l...@cbrc.jp


Hi,

the Debian packaged version of last has received the bug report you can
read below.  We are building last on several architectures which was not
a problem for previous versions.  Is there any restriction to run last
only on x86 architectures from your point of view?

Kind regards and thanks for providing last as free software

 Andreas.

On Mon, Dec 16, 2019 at 03:47:11PM +0100, Matthias Klose wrote:
> Package: src:last-align
> Version: 1021-2
> Severity: serious
> Tags: sid bullseye
> 
> last-align ftbfs on non-x86 architectures, and I really didn't check if it's
> doing the right thing on i386 with the intrinsics ...
> 
> 
> In file included from GappedXdropAligner.hh:49,
>  from GappedXdropAligner.cc:49:
> mcf_simd.hh:7:10: fatal error: immintrin.h: No such file or directory
> 7 | #include 
>   |  ^
> compilation terminated.
> make[3]: *** [makefile:105: GappedXdropAligner.o] Error 1
> make[3]: Leaving directory '/<>/src'
> make[2]: *** [makefile:3: all] Error 2
> 
> ___
> Debian-med-packaging mailing list
> debian-med-packag...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging

-- 
http://fam-tille.de

Bug#946853: Fails to build with glibc 2.30

[Sebastien Bacher]

Package: ace
Version: 6.4.5+dfsg-1
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu focal ubuntu-patch

The issue has been reported upstream and fixed in
https://github.com/DOCGroup/ACE_TAO/pull/939

The incoming patches is used in Ubuntu and fixes the issue

Bug#874375: ebtables: 32 bit binary cannot communicate with 64 bit kernel on arm platform

[Shanker Wang]

Hi,

I tested on the platform where this bug happened with the following packages:

ebtables:armhf 2.0.10.4+snapshot20181205-3, and
Linux espressobin 4.19.20-mvebu64 #5.75 SMP PREEMPT Fri Feb 8 09:54:18 CET 2019 
aarch64 GNU/Linux

And I can confirm that the behavior is expected.

Cheers,

Miao Wang

> 2019年12月15日 04:26，Alberto Molina Coballes  写道：
> 
> Hi Wang and Tomáš,
> 
> When I adopted ebtables in 2018 and I was initially focused on putting the 
> package in shape, but this bug has remained unattended for too many time.
> 
> Now, installing i386 ebtables userspace tool on an amd64 kernel I can't 
> reproduce this bug.
> 
> I've tested both ebtables-legacy (provided by ebtables package) and 
> ebtables-nft (provided by iptables package) on buster and sid, so I think 
> that this bug has been solved at any moment since you reported on ebtables 
> 2.0.10.4-3.
> 
> ebtables versions tested:
> 
> buster:
> ebtables:i386 2.0.10.4+snapshot20181205-3 i386
> iptables 1.8.2-4
> linux-image-4.19.0-6-amd64 4.19.67-2+deb10u2
> 
> sid:
> ebtables:i386 2.0.11-1
> iptables 1.8.4-1 
> linux-image-5.3.0-3-amd64 5.3.15-1
> 
> In all the combinations tested the behaviour was the expected not the 
> reported in your bug. Please, reply this message with any other information 
> needed if the bug remains in other scenario.
> 
> Regards,
> 
> Alberto

Bug#924172: www.debian.org: differences under english/ between builds in stretch and buster

[Julien Cristau]

On Sun, Mar 10, 2019 at 02:17:50AM +0100, Cyril Brulebois wrote:
> 7. Changes related to image width/height attributes
> ===
> 
> 
> --- stretch/webwml/english/partners/2018/index.en.html
> +++ buster/webwml/english/partners/2018/index.en.html
> 
> -   class="partnerlogo" width=height=>
> +   class="partnerlogo">
> 
> --- stretch/webwml/english/partners/2019/index.en.html
> +++ buster/webwml/english/partners/2019/index.en.html
> 
> -   class="partnerlogo" width=height=>
> +   class="partnerlogo">
> 
> -   class="partnerlogo" width=height=>
> +   class="partnerlogo">
> 
> --- stretch/webwml/english/partners/index.en.html
> +++ buster/webwml/english/partners/index.en.html
> 
> -   class="partnerlogo" width=height=>
> +   class="partnerlogo">
> 
> -   class="partnerlogo" width=height=>
> +   class="partnerlogo">
> 
> For some reason, width/height were empty, and they seem to be stripped
> now? Progress, maybe, except that might be hiding the root issue?
> 
This change is from https://github.com/thewml/website-meta-language/pull/1

Cheers,
Julien

Bug#945055: linux: CPU runs at considerably higher temperatures

[Christoph Anton Mitterer]

I should perhaps add that there is some slight indication that this
might be graphics related.

Cause when I switch from the running X/Cinnamon (with the CPU at
average temperatures between 75-70°C, while top doesn't show really
much) to the virtual kernel console, temperatures go down drastically
(to around 56°C).


Cheers,
Chris.

Bug#946852: SSH probe in smokeping does not work

[Dawson, Kate]

Package: smokeping
Version: 2.7.3-2

The SSH plugin in smokeping calls ssh-keyscan and expects to look for rsa1 type 
keys on initialisation.  However ssh-keyscan no longer supports rsa1.
This causes smokeping to fail to start.
Upstream version of the SSH plugin has removed the dependancy on rsa1 keys

 
https://github.com/oetiker/SmokePing/commit/62ac9fda04b994bbf4f97d3dd1cf8b92cf279e71

[] Restarting smokeping (via systemctl): smokeping.serviceDec 16 14:51:43 
monitor systemd[1]: Starting Latency Logging and Graphing System...
Dec 16 14:51:44 monitor smokeping[7108]: ERROR: output of '/usr/bin/ssh-keyscan 
-t dsa,rsa,rsa1 127.0.0.1' does not match (?^i:^# \S+ SSH-)
Dec 16 14:51:44 monitor smokeping[7108]:  at (eval 57) line 1.
Dec 16 14:51:44 monitor systemd[1]: smokeping.service: Control process exited, 
code=exited, status=255/EXCEPTION
Dec 16 14:51:44 monitor systemd[1]: smokeping.service: Failed with result 
'exit-code'.
Dec 16 14:51:44 monitor systemd[1]: Failed to start Latency Logging and 
Graphing System.
Job for smokeping.service failed because the control process exited with error 
code.
See "systemctl status smokeping.service" and "journalctl -xe" for details.

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Bug#946851: hcxdumptool: Please update to latest version 6.0.0

[Sophie Brun]

Package: hcxdumptool
Severity: wishlist
User: de...@kali.org
Usertags: origin-kali

Upstream released the version 6.0.0
It would be nice to have latest version in Debian.

Thanks

Sophie

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

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

Versions of packages hcxdumptool depends on:
ii  libc6  2.29-3

hcxdumptool recommends no packages.

hcxdumptool suggests no packages.

Bug#946850: last-align ftbfs on non-x86 architectures

[Matthias Klose]

Package: src:last-align
Version: 1021-2
Severity: serious
Tags: sid bullseye

last-align ftbfs on non-x86 architectures, and I really didn't check if it's
doing the right thing on i386 with the intrinsics ...


In file included from GappedXdropAligner.hh:49,
 from GappedXdropAligner.cc:49:
mcf_simd.hh:7:10: fatal error: immintrin.h: No such file or directory
7 | #include 
  |  ^
compilation terminated.
make[3]: *** [makefile:105: GappedXdropAligner.o] Error 1
make[3]: Leaving directory '/<>/src'
make[2]: *** [makefile:3: all] Error 2

Bug#916111: ruby-sigar FTBFS with glibc 2.28

[Sebastien Bacher]

tags 916111 patch
user 916111 ubuntu-de...@lists.ubuntu.com
usertags 916111 origin-ubuntu focal ubuntu-patch

thank you

The attached patch fixes the issue


diff -Nru ruby-sigar-0.7.3/debian/changelog ruby-sigar-0.7.3/debian/changelog
--- ruby-sigar-0.7.3/debian/changelog	2015-09-09 17:59:41.0 +0200
+++ ruby-sigar-0.7.3/debian/changelog	2019-12-16 15:39:55.0 +0100
@@ -1,3 +1,11 @@
+ruby-sigar (0.7.3-2) UNRELEASED; urgency=medium
+
+  * debian/patches/github-glibc-buildfix.patch:
+- build fix for glibc 2.28, backported upstream proposed fix from
+  https://github.com/hyperic/sigar/pull/127 (Closes: #916111)
+
+ -- Sebastien Bacher   Mon, 16 Dec 2019 15:31:01 +0100
+
 ruby-sigar (0.7.3-1) unstable; urgency=medium
 
   * Team upload.
diff -Nru ruby-sigar-0.7.3/debian/control ruby-sigar-0.7.3/debian/control
--- ruby-sigar-0.7.3/debian/control	2015-09-09 17:59:41.0 +0200
+++ ruby-sigar-0.7.3/debian/control	2018-03-01 10:36:16.0 +0100
@@ -1,7 +1,8 @@
 Source: ruby-sigar
 Section: ruby
 Priority: optional
-Maintainer: Debian Ruby Extras Maintainers 
+Maintainer: Ubuntu Developers 
+XSBC-Original-Maintainer: Debian Ruby Extras Maintainers 
 Uploaders: Pirate Praveen 
 Build-Depends: debhelper (>= 7.0.50~), gem2deb (>= 0.7.4~)
 Standards-Version: 3.9.6
diff -Nru ruby-sigar-0.7.3/debian/patches/github-glibc-buildfix.patch ruby-sigar-0.7.3/debian/patches/github-glibc-buildfix.patch
--- ruby-sigar-0.7.3/debian/patches/github-glibc-buildfix.patch	1970-01-01 01:00:00.0 +0100
+++ ruby-sigar-0.7.3/debian/patches/github-glibc-buildfix.patch	2019-12-16 15:30:29.0 +0100
@@ -0,0 +1,28 @@
+From b4e27b0b3167aac9a0f3f08dd2b2a0c0c9c4d797 Mon Sep 17 00:00:00 2001
+From: Logan Rosen 
+Date: Fri, 11 Jan 2019 22:52:21 -0500
+Subject: [PATCH] Fix build with glibc 2.28
+https://github.com/hyperic/sigar/pull/127
+---
+ src/os/linux/linux_sigar.c | 5 +
+ 1 file changed, 5 insertions(+)
+
+diff --git a/src/os/linux/linux_sigar.c b/src/os/linux/linux_sigar.c
+index a3fd2301..de9c960c 100644
+--- a/src/os/linux/linux_sigar.c
 b/src/os/linux/linux_sigar.c
+@@ -23,8 +23,13 @@
+ #include 
+ #include 
+ #include 
++#include 
+ #include 
+ 
++#ifdef __GNU_LIBRARY__
++#include 
++#endif
++
+ #include "sigar.h"
+ #include "sigar_private.h"
+ #include "sigar_util.h"
+
diff -Nru ruby-sigar-0.7.3/debian/patches/series ruby-sigar-0.7.3/debian/patches/series
--- ruby-sigar-0.7.3/debian/patches/series	2015-09-09 17:59:41.0 +0200
+++ ruby-sigar-0.7.3/debian/patches/series	2019-12-16 14:24:50.0 +0100
@@ -1,2 +1,3 @@
 mips-TIOCGETC-undeclared.patch
 gnu89-inline.diff
+github-glibc-buildfix.patch

Bug#946848: Tuxguitar ftbfs with the new libfluidsynth

[gregor herrmann]

On Mon, 16 Dec 2019 15:33:20 +0100, Sebastien Bacher wrote:

> Le 16/12/2019 à 15:30, gregor herrmann a écrit :
> > The patch seems to have gone missing on the way to the BTS 
> Sorry, I sent it in another step so I could include the Closes: #
> reference in the patch :-)

Clever :)

And I saw the second mail just after sending my question; sorry for
the noise.


Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   BOFH excuse #431:  Borg implants are failing 

Bug#946836: Build failure on powerpc architectures

[Sebastien Bacher]

Le 16/12/2019 à 15:23, Dirk Eddelbuettel a écrit :
> Can you remind if/how I could get shell access to PowerPC to test?

https://wiki.debian.org/PorterBoxHowToUse should have the details needed

Seems like the ppc boxes have restricted access though...

I can test a patch/package on an Ubuntu porter box if that's useful

Bug#946848: Tuxguitar ftbfs with the new libfluidsynth

[Sebastien Bacher]

Le 16/12/2019 à 15:30, gregor herrmann a écrit :
> The patch seems to have gone missing on the way to the BTS 

Sorry, I sent it in another step so I could include the Closes: #
reference in the patch :-)