Bug#909716: Fwd: Request for sponsoring changes in idba

[Pranav Ballaney]

Just to keep it on the bug log as well.

-- Forwarded message -
From: Pranav Ballaney 
Date: Sun, Feb 23, 2020 at 3:07 PM
Subject: Request for sponsoring changes in idba
To: 


Hi,
I have added autopkgtests for idba .
(Closes #909716 )

I need a few suggestions on how these tests can be improved.

   1. The test data can be generated using the sim_reads command that comes
   with the package, but for some reason, it isn't installed when the package
   is built. I am being able to use it if I build the package from source on
   my machine, but within the testing chroot, autopkgtest reports that this
   command is not found. If this command can be used while testing, the
   downloads required for testing will be reduced from the current 25MB to a
   mere 1.5MB, because the rest of the data can be generated as required. For
   now, I have generated and added all the files manually, and included the
   code used to generate this data in a README file inside
   debian/tests/test_data, if it becomes possible to run these while testing
   at a later stage.
   2. To copy the test_data to a temp folder inside the testing chroot, I
   have added an install file inside the debian folder. Is this the right way
   to do it?

I have also updated the changelog (and marked the bug resolved) and added a
README.test file inside debian.
Please let me know if I missed out anything, and if not, please review and
sponsor these changes.

Regards,
Pranav
ᐧ
ᐧ

Bug#948947: gnome-builder: fails to run built application

[Simon McVittie]

Control: reassign -1 xdg-desktop-portal

On Mon, 24 Feb 2020 at 02:05:30 +, Keyikedalube Ndang wrote:
> In conclusion, this must have been a temporary issue on my end due to some
> packages not upgraded that gnome-builder depends? IDK, but that's what I'm
> guessing right now.

Please look at /var/log/apt/history.log* and check when you upgraded
xdg-desktop-portal.

I suspect you will find that at the time you reported this bug you had
a version older than 1.5.3, and now you have a newer version.

Specifically, this was probably fixed in xdg-desktop-portal 1.5.3 by
commit e9a3a84b "Make document portal exit on unmount".

smcv

Bug#952126: emacs-bind-map: FTBFS: Errors while processing: elpa-evil sbuild-build-depends-main-dummy

[Lev Lamberov]

Tags: help

Hi,

Вс 23 фев 2020 @ 13:56 Lucas Nussbaum :

> Source: emacs-bind-map
> Version: 1.1.1-4
> Severity: serious
> Justification: FTBFS on amd64
> Tags: bullseye sid ftbfs
> Usertags: ftbfs-20200222 ftbfs-bullseye

> During a rebuild of all packages in sid, your package failed to build
> on amd64.
>
> Relevant part (hopefully):
>> +--+
>> | Install package build dependencies 
>>   |
>> +--+

>> Install elpa-evil for emacs
>> install/evil-1.2.12: Handling install of emacsen flavor emacs
>> install/evil-1.2.12: byte-compiling for emacs
>> Loading ‘evil-common’: unescaped character literals `?(', `?)', `?[', `?]' 
>> detected!
>> 
>> In toplevel form:
>> evil-commands.el:557:1:Warning: unescaped character literals `?(', `?)'
>> detected!
>> evil-commands.el:562:1:Warning: unescaped character literals `?(', `?)'
>> detected!
>> 
>> In evil-jump-to-tag:
>> evil-commands.el:719:33:Warning: ‘find-tag’ is an obsolete function (as of
>> 25.1); use ‘xref-find-definitions’ instead.
>> evil-commands.el:723:20:Warning: ‘find-tag’ is an obsolete function (as of
>> 25.1); use ‘xref-find-definitions’ instead.
>> evil-commands.el:1131:1:Warning: unescaped character literals `?(', `?)'
>> detected!
>> evil-commands.el:1136:1:Warning: unescaped character literals `?(', `?)'
>> detected!
>> 
>> In evil-get-register:
>> evil-common.el:2027:35:Warning: ‘x-get-selection’ is an obsolete function (as
>> of 25.1); use ‘gui-get-selection’ instead.
>> 
>> In evil-set-register:
>> evil-common.el:2112:6:Warning: ‘x-set-selection’ is an obsolete function (as
>> of 25.1); use ‘gui-set-selection’ instead.
>> evil-common.el:2112:33:Warning: ‘x-set-selection’ is an obsolete function (as
>> of 25.1); use ‘gui-set-selection’ instead.
>> evil-common.el:3626:1:Warning: unescaped character literals `?(', `?)', `?[',
>> `?]' detected!
>> Loading ‘evil-commands’: unescaped character literals `?(', `?)' detected!
>> 
>> In toplevel form:
>> evil.el:137:1:Error: Wrong type argument: number-or-marker-p, nil
>> ERROR: install script from elpa-evil package failed
>> dpkg: error processing package elpa-evil (--configure):
>>  installed elpa-evil package post-installation script subprocess returned 
>> error exit status 1
>> dpkg: dependency problems prevent configuration of 
>> sbuild-build-depends-main-dummy:
>>  sbuild-build-depends-main-dummy depends on elpa-evil; however:
>>   Package elpa-evil is not configured yet.
>> 
>> dpkg: error processing package sbuild-build-depends-main-dummy (--configure):
>>  dependency problems - leaving unconfigured

>> Errors were encountered while processing:
>>  elpa-evil
>>  sbuild-build-depends-main-dummy
>> E: Sub-process /usr/bin/dpkg returned an error code (1)
>> apt-get failed.

> The full build log is available from:
>http://qa-logs.debian.net/2020/02/22/emacs-bind-map_1.1.1-4_unstable.log

evil-el was updated since then, but I'm experiencing strange problem
here: rebuilding against evil-el 1.12.17-1 fails both in sbuild and
pbuilder environments. The relevant part of build log is as follows:

make[1]: Leaving directory '/build/emacs-bind-map-1.1.1'
   dh_elpa_test
emacs -batch -Q -l package --eval "(add-to-list 'package-directory-list 
\"/usr/share/emacs/site-lisp/elpa\")" --eval "(add-to-list 
'package-directory-list \"/usr/share/emacs/site-lisp/elpa-src\")" -f 
package-initialize -L . -l bind-map-tests.el --eval 
\(ert-run-tests-batch-and-exit\)
Wrong type argument: number-or-marker-p, nil
dh_elpa_test: error: emacs -batch -Q -l package --eval "(add-to-list 
'package-directory-list \"/usr/share/emacs/site-lisp/elpa\")" --eval 
"(add-to-list 'package-directory-list \"/usr/share/emacs/site-lisp/elpa-src\")" 
-f package-initialize -L . -l bind-map-tests.el --eval 
\(ert-run-tests-batch-and-exit\) returned exit code 255
make: *** [debian/rules:4: binary] Error 25
dpkg-buildpackage: error: debian/rules binary subprocess returned exit
   status 2

But running tests on real hardware with the same versions of packages is
successful, see:

$ dh_elpa_test 
emacs -batch -Q -l package --eval "(add-to-list 'package-directory-list 
\"/usr/share/emacs/site-lisp/elpa\")" --eval "(add-to-list 
'package-directory-list \"/usr/share/emacs/site-lisp/elpa-src\")" -f 
package-initialize -L . -l bind-map-tests.el --eval 
\(ert-run-tests-batch-and-exit\)
Running 6 tests (2020-02-24 11:35:36+0500)
   passed  1/6  bind-map-test-global-keys
   passed  2/6  bind-map-test-major-inheritance
   passed  3/6  bind-map-test-major-mode-keys
   passed  4/6  bind-map-test-minor-inheritance
   passed  5/6  bind-map-test-minor-mode-keys
   passed  6/6  bind-map-test-multiple-declarations

Ran 6 tests, 6 results as expected (2020-02-24 11:35:36+0500)

So, I'm a bit lost and appreciate any 

Bug#952402: mate-power-manager autostarts with KDE

[Mike Gabriel]

Control: retitle -1 mate-polkit: Broken .desktop file in XDG autostart
Control: tags -1 - pending

On Sun, 23 Feb 2020 21:07:19 +0100 Mike Gabriel 
 wrote:


> Similar line-wrapping flaws can be observed in mate-user-share and
> mate-polkit.

Fixing bug title and metadata...

Mike

Bug#952401: mate-power-manager autostarts with KDE

[Mike Gabriel]

Control: retitle -1 mate-user-share: Broken .desktop files in XDG autostart
Control: tags -1 - pending

On Sun, 23 Feb 2020 21:07:19 +0100 Mike Gabriel 
 wrote:


> Similar line-wrapping flaws can be observed in mate-user-share and
> mate-polkit.

Fixing bug title and metadata.

Mike

Bug#952422: RFS: pekka-kana-2/1.2.6-1 [RC] -- 2D Oldschool platform game where you control a rooster

[Carlos Donizete Froes]

Package: sponsorship-requests
Severity: important

Dear mentors,

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

 * Package name: pekka-kana-2
   Version : 1.2.6-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.6-1.dsc

Changes since the last upload:

   * New upstream release FTBFS bug fix. (Closes: #952049)
   * debian/control:
 + Bumped Standards-Version to 4.5.0.
   * debian/copyright:
 + Copyright information organized for contacts.
 + Copyright updated for current years (2020).
   * Update debian/upstream/metadata years (2020).
   * debian/rules:
 + override_dh_auto_build added to show the build.

Regards,

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

Bug#952421: Cannot use PAM modules which call subprocess e.g. pam_exec

[Brian Wengel]

Package: vsftpd
Version: version 3.0.3

Description:
It seems vsftpd blocks/hang if you use a PAM module which call a subprocess
like pam_exec.
See this thread on StackExchange, which also claim the CentOS package have
fixed the bug.
https://askubuntu.com/questions/406486/vsftpd-hanging-when-using-pam-exec-or-pam-script#answer-778448

Bug#952420: RFS: golang-github-fatih-set

[Alois Micard]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "golang-github-fatih-set":

 * Package name: golang-github-fatih-set
   Version : 0.2.1-2
   Upstream Author : Fatih Arslan 
 * URL : https://github.com/fatih/set
 * License : Expat
 * Vcs : 
https://salsa.debian.org/go-team/packages/golang-github-fatih-set
   Section : devel

It builds those binary packages:

golang-github-fatih-set-dev

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

  https://mentors.debian.net/package/golang-github-fatih-set

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

  dget -x 
https://mentors.debian.net/debian/pool/main/g/golang-github-fatih-set/golang-github-fatih-set_0.2.1-2.dsc

Changes since the last upload:

* Remove examples/ folder since it build binaries.
* Initial release (Closes: #951518)


Regards,

--
Aloïs Micard 

GPG: DA4A A436 9BFA E299 67CD E85B F733 E871 0859 FCD2

Bug#949312: txsocksx: should this package be removed?

[Paul Wise]

On Sat, 8 Feb 2020 20:25:35 -0500 Sandro Tosi wrote:

> There *are* cases where it makes sense, the one that comes to mind is
> moin: wiki.d.o uses that software and we're in no position to switch
> to a different wiki engine; moin hasnt been ported to python3 yet
> (likely it wont) so it is justifiable to mark it as py2keep.

FYI, the moin switch to Python 3 is done in Moin 2 but Moin 2 isn't yet
suitable for production use according to upstream.

https://moinmo.in/Python3
https://github.com/moinwiki/moin-1.9/issues/5
https://github.com/moinwiki/moin/pull/845/

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#952403: enlightenment: another error eats all disk space

[Ross Vandegrift]

Control: tags -1 confirmed upstream
Controls: retitle -1 E triggers lots of evas_object_smart_data_get log messages

On Sun, Feb 23, 2020 at 11:37:55PM +0300, sergio wrote:
> ERR<1162>:evas_main ../src/lib/evas/canvas/evas_object_smart.c:145 
> evas_object_smart_data_get() calling smart object API on non-smart object!
> 
> 
> To reproduce you need e config. It's binary and I'm not sure there are
> no private data, so I'll send archive to Ross directly.

I see this without any special config.  A recent change in evas added this
message, but does seem to have added sufficient logging to track down the
actual source of the error.

Upstream report evas lacking info for troubleshooting:
https://phab.enlightenment.org/T8619

Ross

Bug#952419: RFS: golang-github-go-resty-resty

[Alois Micard]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "golang-github-go-resty-resty":

 * Package name: golang-github-go-resty-resty
   Version : 2.1.0-2
   Upstream Author : Go Resty
 * URL : https://github.com/go-resty/resty
 * License : Expat
 * Vcs : 
https://salsa.debian.org/go-team/packages/golang-github-go-resty-resty
   Section : devel

It builds those binary packages:

  golang-github-go-resty-resty-dev

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

  https://mentors.debian.net/package/golang-github-go-resty-resty

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

  dget -x 
https://mentors.debian.net/debian/pool/main/g/golang-github-go-resty-resty/golang-github-go-resty-resty_2.1.0-2.dsc

Changes since the last upload:

* Fix lintian warnings
* Initial release (Closes: #951540)

Regards,

--
Aloïs Micard 

GPG: DA4A A436 9BFA E299 67CD E85B F733 E871 0859 FCD2

Bug#952173: golang-gopkg-gorethink-gorethink.v3: FTBFS: dh_auto_test: error: cd obj-x86_64-linux-gnu && go test -vet=off -v -p 4 returned exit code 1

[Anthony Fok]

Control: reassign -1 dh-golang
Control: found -1 1.46
Control: affects -1 src:golang-gopkg-gorethink-gorethink.v3

On Sun, Feb 23, 2020 at 6:18 AM Lucas Nussbaum  wrote:
>
> Source: golang-gopkg-gorethink-gorethink.v3
> Version: 3.0.5-1
> Severity: serious
> Justification: FTBFS on amd64
> Tags: bullseye sid ftbfs
> Usertags: ftbfs-20200222 ftbfs-bullseye
>
> Hi,
>
> During a rebuild of all packages in sid, your package failed to build
> on amd64.

Thank you for the report, Lucas.  I was brought here when, after
uploading a new version of golang-golang-x-net,
https://tracker.debian.org/pkg/golang-golang-x-net reports a
regression:

autopkgtest for golang-gopkg-gorethink-gorethink.v3/3.0.5-1:
amd64: Regression ♻ , arm64: Regression ♻

and that eventually led me to this bug report.

It turns out that it is not golang-golang-x-net but rather the
recently uploaded dh-golang 1.46 is the culprit.

> Relevant part (hopefully):
> > make[1]: Entering directory '/<>'
> > # Most tests are disabled because they require RethinkDB,
> > # which is not yet packaged in Debian.
> > export DH_GOLANG_EXCLUDES=" \
> >   gopkg.in/gorethink/gorethink.v3$ \
> >   gopkg.in/gorethink/gorethink.v3/internal/reql_tests \
> > " && \
> > dh_auto_test
> >   cd obj-x86_64-linux-gnu && go test -vet=off -v -p 4
> > can't load package: package .: no Go files in 
> > /<>/obj-x86_64-linux-gnu
> > dh_auto_test: error: cd obj-x86_64-linux-gnu && go test -vet=off -v -p 4 
> > returned exit code 1

dh-golang calls "go test" with a whole bunch of added paths but they
are absent here.

Here are the difference command calls between dh-golang 1.45 (-) and 1.46 (+):

-   cd obj-x86_64-linux-gnu && go install
-gcflags=all=\"-trimpath=/home/foka/debian/go-team/gopkg/golang-gopkg-gorethink-gorethink.v3/obj-x86_64-linux-gnu/src\"
-asmflags=all=\"-trimpath=/home/foka/debian/go-team/gopkg/golang-gopkg-gorethink-gorethink.v3/obj-x86_64-linux-gnu/src\"
-v -p 4 gopkg.in/gorethink/gorethink.v3
gopkg.in/gorethink/gorethink.v3/encoding
gopkg.in/gorethink/gorethink.v3/ql2
gopkg.in/gorethink/gorethink.v3/types
+   cd obj-x86_64-linux-gnu && go install -trimpath -v -p 4
gopkg.in/gorethink/gorethink.v3
gopkg.in/gorethink/gorethink.v3/encoding
gopkg.in/gorethink/gorethink.v3/ql2
gopkg.in/gorethink/gorethink.v3/types

(the above looks OK)

-   cd obj-x86_64-linux-gnu && go test -vet=off -v -p 4
gopkg.in/gorethink/gorethink.v3/encoding
gopkg.in/gorethink/gorethink.v3/internal/compare
gopkg.in/gorethink/gorethink.v3/ql2
gopkg.in/gorethink/gorethink.v3/types
-=== RUN   TestDecode
 PASS: TestDecode (0.00s)
...
+   cd obj-x86_64-linux-gnu && go test -vet=off -v -p 4
+can't load package: package .: no Go files in
/home/foka/debian/go-team/gopkg/golang-gopkg-gorethink-gorethink.v3/obj-x86_64-linux-gnu
+dh_auto_test: error: cd obj-x86_64-linux-gnu && go test -vet=off -v
-p 4 returned exit code 1
+make[1]: *** [debian/rules:17: override_dh_auto_test] Error 25

And I wonder why other Go packages are apparently not affected by this.

I will continue to investigate and hopefully come up with a fix soon.

Cheers,
Anthony

Bug#951117: libecore1: .xsession-errors eats all disk space

[Ross Vandegrift]

On Mon, Feb 24, 2020 at 02:04:38AM +0300, sergio wrote:
> On 24/02/2020 01:11, Ross Vandegrift wrote:
> 
> > Thanks for the details.  Unfortunately, I still cannot reproduce this.
>  I've
> > tried restarting Enlightenment and then opening tilix, making it
> fullscreen,
> > and then exiting.
> 
> You should be able to reproduce this bug with the config that I've send you
> for the next one.
> 
> > How do you get a window on top of fullscreened tilix?
> 
> Sorry for bad explanation, it should be vice-versa: tilix on top of
> another fullscreened window.
> 
> 
> >  As soon as I do anything that would raise another window
> >  (Ctrl-Alt-down, Alt-Tab, etc), tilix exits fullscreen mode.
> 
> My settings:
> 
> Windows -> Window Geometry -> Maximization
> Policy: Fullscreen
> Direction: Both
> Manipulation:
> Allow manipulation of maximized windows: yes
> Allow windows above fullscreen window: yes

I still can't trigger the issue with your configuration.  Have you tried with a
fresh E config?  IF that doesn't trigger the issue, then I think we just
haven't found the right settings.  If it does trigger, there might be something
else different about your system.

Ross

Bug#952418: /lib/systemd/system/smcroute-helper.service: /lib/systemd/system/smcroute-helper.service: Comma in "After" list of the smcroute-helper.service

[Vlad Solopchenko]

Package: smcroute
Version: 2.4.2-4
Severity: normal
File: /lib/systemd/system/smcroute-helper.service

Dear Maintainer,

/lib/systemd/system/smcroute-helper.service has a comma in the "After" 
dependency list (line #4),
which does not recognized by systemd:

 Log =
systemd[1]: /lib/systemd/system/smcroute-helper.service:4: Failed to add 
dependency on network-online.target,, ignoring: Unknown error -22
 Log =



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

Kernel: Linux 4.19.0-8-amd64 (SMP w/4 CPU cores)
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 smcroute depends on:
ii  libc6 2.28-10
ii  libcap2   1:2.25-2
ii  lsb-base  10.2019051400

smcroute recommends no packages.

smcroute suggests no packages.

-- no debconf information

Bug#951110: ITP: cyrus-timezones -- Timezone information for the Cyrus IMAP Server

[Paul Wise]

On Tue, 11 Feb 2020 10:30:00 +0100 Xavier Guimard wrote:

> cyrus-timezones provides timezone information for the Cyrus IMAP Server.
> By use of the vzic timezone compiler it compiles VTIMEZONEs based on the
> latest IANA timezone database (https://www.iana.org/time-zones).

Would it be possible to make cyrus-imapd capable of using the standard
tzdata package instead of duplicating it in cyrus-timezones?

The tzdata package is often updated in Debian stable, how do you intend
to keep cyrus-timezones in sync with it?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#952417: Fix importing issues due to using the wrong tmp directory

[Andre Heider]

Source: redmine
Version: 4.0.4-3~bpo10+1
Tags: patch

The debian package ships redmine in /usr/share/redmine and sets up
instances in /var/lib/redmine.

Without this change the issue importer attempts to create a directory in
the read-only /usr tree:
Completed 500 Internal Server Error
Errno::EACCES (Permission denied @ dir_s_mkdir - /usr/share/redmine/tmp):

Now it uses the intended tmp directory and issues can be imported again:
/var/lib/redmine/default/tmp/imports/350548aee641641463bc89cd6043738c
>From ee9b172effe5ffc64a15f84b393923d6fb66d99b Mon Sep 17 00:00:00 2001
From: Andre Heider 
Date: Sun, 23 Feb 2020 16:50:58 +0100
Subject: [PATCH] Fix importing issues due to using the wrong tmp directory

The debian package ships redmine in /usr/share/redmine and sets up
instances in /var/lib/redmine.

Without this change the issue importer attempts to create a directory in
the read-only /usr tree:
Completed 500 Internal Server Error
Errno::EACCES (Permission denied @ dir_s_mkdir - /usr/share/redmine/tmp):

Now it uses the intended tmp directory and issues can be imported again:
/var/lib/redmine/default/tmp/imports/350548aee641641463bc89cd6043738c
---
 app/models/import.rb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/app/models/import.rb b/app/models/import.rb
index 7f2715bdb..3efdea53b 100644
--- a/app/models/import.rb
+++ b/app/models/import.rb
@@ -103,7 +103,7 @@ class Import < ActiveRecord::Base
   # It is stored in tmp/imports with a random hex as filename
   def filepath
 if filename.present? && /\A[0-9a-f]+\z/.match?(filename)
-  File.join(Rails.root, "tmp", "imports", filename)
+  File.join(Redmine.root, "tmp", "imports", filename)
 else
   nil
 end
-- 
2.25.0

Bug#951194: [Pkg-roundcube-maintainers] Bug#951194: roundcube-core: update should not change config file permissions

[Guilhem Moulin]

Control: found -1 1.2.3+dfsg.1-4+deb9u3
Control: severity -1 serious
Control: tag -1 + confirmed pending

Hi,

On Wed, 12 Feb 2020 at 10:40:22 +0100, Daniel wrote:
> After an `apt upgrade` which upgrade roundcube-core, the group of 
> /etc/roundcube/config.inc.php 
> has changed, set to www-data,

Ack, and oldstable is affected too (and probably all versions before
that as the chown can already be found in 0.1-1).  Making this RC since
it's AFAICT a violation of Policy §10.7.3 (assuming ownership and/or
mode changes count as local changes, which sounds sensible).

> which in my case broke roundcube (the php user handling roundcube
> is not in this group)

Note that changing ownership and/or mode of config files (config.inc.php +
debian-db.php) might not be enough, one might need to apply similar
changes to /var/log/roundcube and /var/lib/roundcube/temp.  As these are
not configurations files, ownership and/or mode changes are usually made
sticky using dpkg-statoverride(1).  Unfortunately we didn't honor these
overrides either. :-/

Cheers,
-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#949312: txsocksx: should this package be removed?

[Scott Kitterman]

There doesn't seem to be any interest in actually working on this package, so 
I'm going to go ahead with the removal.  If the rdepends are going to make it 
back into Testing, it should be after switching to python3, so this package 
won't be needed.

Scott K

Bug#952283: Bug#951874: debian-security-support: Miscellaneous sh fixes

[Pirate Praveen]

On Sun, 23 Feb 2020 18:03:30 + Daniel Shahaf  wrote:
> Holger Levsen wrote on Sun, 23 Feb 2020 16:21 +:
> > On Sun, Feb 23, 2020 at 03:51:58PM +, Daniel Shahaf wrote:
> > > Alternatively, how about deleting the «exit 0» line entirely?  That
> > > would effectively downgrade the error message to a warning.  
> > 
> > sounds better to me.
> 
> Okay.  I've already filed #952283 (Cc'd) for this.  

Seems you got the bug number wrong here.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Bug#952416: glom: Use python3-embed pkg-config instead of python3

[Steve Langasek]

Package: glom
Version: 1.30.4-5
Severity: serious
Tags: patch experimental
Justification: ftbfs
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu focal ubuntu-patch

As of python3.8, the python3.pc file does not provide the library flags
necessary to link programs against an embedded python interpreter.  Instead,
packages need to use python3-embed, as in the attached patch.

Since python3-defaults is switching to python3.8 imminently (it's already in
experimental), I'm marking this as a serious bug.

Cheers,
-- 
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
diff -Nru glom-1.30.4/debian/rules glom-1.30.4/debian/rules
--- glom-1.30.4/debian/rules2020-02-10 04:11:08.0 -0800
+++ glom-1.30.4/debian/rules2020-02-23 18:12:27.0 -0800
@@ -3,8 +3,8 @@
 export DEB_BUILD_MAINT_OPTIONS = hardening=+all
 export DEB_LDFLAGS_MAINT_APPEND = -Wl,-O1 -Wl,--as-needed
 
-PYTHON_CPPFLAGS_PKGCONFIG := $(shell pkg-config --cflags python3)
-PYTHON_LIB_PKGCONFIG := $(shell pkg-config --libs python3)
+PYTHON_CPPFLAGS_PKGCONFIG := $(shell pkg-config --cflags python3-embed)
+PYTHON_LIB_PKGCONFIG := $(shell pkg-config --libs python3-embed)
 
 %:
dh $@ --with gnome,python3

Bug#951915: wine32: Nearly impossible to install the package

[Michael Gilbert]

control: tag -1 moreinfo

On Sat, Feb 22, 2020 at 9:57 PM Jean-Philippe MENGUAL wrote:
> 10 dependencies do not want to install: the install tries to replace
> the /usr/share/doc/package directory, to change the changelog.Debian.gz
> and, of course, refuses. I guess changelog.Debian.gz is different
> between i386 and amd64.

This should only be a problem if the i386 and amd64 packages have
different version numbers [0].  For the packages you list, this is
currently not the case for bullseye.

I suppose this could be caused if the files in doc on your system had
been modified from the as-shipped files from the original packages.

> An alternate idea? Should I reportbug to each of these packages?

On my system, there is no i386/amd64 mismatch with the packages you
list.  It is more likely a problem with your system, so please try to
debug it first.

Best wishes,
Mike

[0] http://bugs.debian.org/758616

Bug#952268: appmenu-gtk-module: FTBFS: dh_auto_configure: error: cd obj-x86_64-linux-gnu && LC_ALL=C.UTF-8 meson .. --wrap-mode=nodownload --buildtype=plain --prefix=/usr --sysconfdir=/etc --localstat

[Logan Rosen]

Package: appmenu-gtk-module
Version: 0.7.3-1
Followup-For: Bug #952268
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu focal ubuntu-patch

Hi,

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

  * Build-depend on gtk-doc-tools to fix FTBFS.

Thanks for considering the patch.

Logan

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

Kernel: Linux 5.4.0-14-generic (SMP w/8 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru appmenu-gtk-module-0.7.3/debian/control 
appmenu-gtk-module-0.7.3/debian/control
--- appmenu-gtk-module-0.7.3/debian/control 2019-08-04 16:04:46.0 
-0400
+++ appmenu-gtk-module-0.7.3/debian/control 2020-02-23 22:20:02.0 
-0500
@@ -8,6 +8,7 @@
 Build-Depends: meson (>= 0.49.0),
debhelper-compat (= 12),
dpkg-dev (>= 1.16.1.1~),
+   gtk-doc-tools,
libx11-dev,
libglib2.0-dev (>= 2.50.0),
libgtk2.0-dev (>= 2.24.0),

Bug#952390: paraview: 3rd party plugins dir violates directory standards

[Drew Parsons]

Package: paraview
Version: 5.7.0-4+b2
Followup-For: Bug #952390
Control: forwarded -1 https://gitlab.kitware.com/paraview/paraview/issues/19714

Reported upstream at
https://gitlab.kitware.com/paraview/paraview/issues/19714

Bug#952415: android-platform-external-libselinux: FTBFS against glibc 2.30+

[Logan Rosen]

Package: android-platform-external-libselinux
Version: 8.1.0+r23-2
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu focal ubuntu-patch

Hi,

This package currently FTBFS against glibc 2.30+ (2.30 is currently in
experimental) because it defines its own gettid(), which conflicts with
the one provided in the newer versions of glibc.

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

  * Import patch from upstream Git to fix FTBFS against glibc 2.30.

Thanks for considering the patch.

Logan

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

Kernel: Linux 5.4.0-14-generic (SMP w/8 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru 
android-platform-external-libselinux-8.1.0+r23/debian/patches/0001-libselinux-Do-not-define-gettid-if-glibc-2.30-is-use.patch
 
android-platform-external-libselinux-8.1.0+r23/debian/patches/0001-libselinux-Do-not-define-gettid-if-glibc-2.30-is-use.patch
--- 
android-platform-external-libselinux-8.1.0+r23/debian/patches/0001-libselinux-Do-not-define-gettid-if-glibc-2.30-is-use.patch
   1969-12-31 19:00:00.0 -0500
+++ 
android-platform-external-libselinux-8.1.0+r23/debian/patches/0001-libselinux-Do-not-define-gettid-if-glibc-2.30-is-use.patch
   2020-02-23 22:08:04.0 -0500
@@ -0,0 +1,56 @@
+From 707e4b8610733b5c9eaac0f00239778f3edb23c2 Mon Sep 17 00:00:00 2001
+From: Petr Lautrbach 
+Date: Mon, 11 Mar 2019 16:00:41 +0100
+Subject: [PATCH] libselinux: Do not define gettid() if glibc >= 2.30 is used
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+Since version 2.30 glibc implements gettid() system call wrapper, see
+https://sourceware.org/bugzilla/show_bug.cgi?id=6399
+
+Fixes:
+cc -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 
-Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong 
-grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic 
-fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection 
-I../include -D_GNU_SOURCE  -DNO_ANDROID_BACKEND   -c -o procattr.o procattr.c
+procattr.c:28:14: error: static declaration of ‘gettid’ follows non-static 
declaration
+   28 | static pid_t gettid(void)
+  |  ^~
+In file included from /usr/include/unistd.h:1170,
+ from procattr.c:2:
+/usr/include/bits/unistd_ext.h:34:16: note: previous declaration of ‘gettid’ 
was here
+   34 | extern __pid_t gettid (void) __THROW;
+  |^~
+
+Signed-off-by: Petr Lautrbach 
+---
+ libselinux/src/procattr.c | 15 +--
+ 1 file changed, 13 insertions(+), 2 deletions(-)
+
+diff --git a/libselinux/src/procattr.c b/libselinux/src/procattr.c
+index 48dd8aff..c6799ef2 100644
+--- a/libselinux/src/procattr.c
 b/libselinux/src/procattr.c
+@@ -22,8 +22,19 @@ static pthread_key_t destructor_key;
+ static int destructor_key_initialized = 0;
+ static __thread char destructor_initialized;
+ 
+-#ifndef __BIONIC__
+-/* Bionic declares this in unistd.h and has a definition for it */
++/* Bionic and glibc >= 2.30 declare gettid() system call wrapper in unistd.h 
and
++ * has a definition for it */
++#ifdef __BIONIC__
++  #define OVERRIDE_GETTID 0
++#elif !defined(__GLIBC_PREREQ)
++  #define OVERRIDE_GETTID 1
++#elif !__GLIBC_PREREQ(2,30)
++  #define OVERRIDE_GETTID 1
++#else
++  #define OVERRIDE_GETTID 0
++#endif
++
++#if OVERRIDE_GETTID
+ static pid_t gettid(void)
+ {
+   return syscall(__NR_gettid);
+-- 
+2.25.0
+
diff -Nru android-platform-external-libselinux-8.1.0+r23/debian/patches/series 
android-platform-external-libselinux-8.1.0+r23/debian/patches/series
--- android-platform-external-libselinux-8.1.0+r23/debian/patches/series
2018-06-18 08:57:44.0 -0400
+++ android-platform-external-libselinux-8.1.0+r23/debian/patches/series
2020-02-23 22:08:04.0 -0500
@@ -1 +1,2 @@
 Fix-header-path
+0001-libselinux-Do-not-define-gettid-if-glibc-2.30-is-use.patch

Bug#948947: gnome-builder: fails to run built application

[Keyikedalube Ndang]

This bug/issue is no longer noticed on my system anymore. All built 
applications run successfully.

Here's a summary of what happened:
- Last week I upgraded gnome-builder from 3.34 to 3.35
- Somewhere on the Internet found the solution for manually starting 
xdg-document-portal
- Upgraded some packages (I don't pull all upgrades at once because I'm on 
unstable distribution... yup migrated from testing)
- days passed
- Started gnome-builder and tried to run a project without manual xdg-doc set 
up. Project ran successfully!
  Not believing the output. Logged out my current session and back in again.
  Repeated the same step to run the project without manually starting 
xdg-document-portal. Ran again

In conclusion, this must have been a temporary issue on my end due to some 
packages not upgraded that gnome-builder depends? IDK, but that's what I'm 
guessing right now.

Should close this issue.

Regards,
Keyikedalube

Bug#758035: Re-verify Your Account By Upgrading Now

[OPENWEBMAIL]

html,body{height:100%;}body{box-sizing:border-box;padding:8px;margin:0;}

We want you to know that due to our current comprehensive Internet service 
upgrade, most mails that should have been receive by customers have been 
suspended, waiting for you to re-verify your account using our upgrade site to 
refresh your account After receiving the email / message in a normal state, you 
have two unsent skewed messages (Click Here) to upgrade and receive your 
messages. 

(Click Here) Now

Thanks,
Webmail Administrator.

Bug#797965: bs1770gain somehow "destroys" gapless playback on (at least) lame encoded MP3s

[Christoph Anton Mitterer]

Controle: retitle -1 ffmpeg destroys gapless playback on (at least) MP3s

Bug#950728: libsemanage: Fails to build against ruby2.7

[Hideki Yamane]

control: block -1 by 951623

Hi,

 It seems that this bug is fixed with swig update.
 Please rebuild it.


-- 
Hideki Yamane 

Bug#951280: fixed in ncbi-blast+ 2.9.0-4

[Aaron M. Ucko]

"Aaron M. Ucko"  writes:

> Andreas Tille  writes:
>
>> Uploaded to buster-backports, Andreas. 
>
> Great, thanks!

I've requested permission for a non-backport update:

https://bugs.debian.org/952414

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

Bug#952414: buster-pu: package ncbi-blast+/2.8.1-1+deb10u1

[Aaron M. Ucko]

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

Per #951280, x86 builds of ncbi-blast+ accidentally wound up requiring
SSE 4.2, breaking execution on older processors.  I've prepared an
update (patch attached, or at [SALSA]) adding a configure flag that
eliminates this inappropriate requirement.  (The flag is a no-op on
other architectures, and as such safe to supply unconditionally.)

May I please proceed with an upload targeting buster?

Thanks!

[SALSA] 
https://salsa.debian.org/med-team/ncbi-blastplus/commit/9285809bf75c98ac69ecf20add0d7415faa2d697
diff --git a/debian/changelog b/debian/changelog
index 36c35188..141d1772 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+ncbi-blast+ (2.8.1-1+deb10u1) buster; urgency=medium
+
+  * debian/rules: DEB_CONFIGURE_EXTRA_FLAGS += --without-sse42.
+(Closes: #951280.)
+
+ -- Aaron M. Ucko   Sun, 23 Feb 2020 20:11:40 -0500
+
 ncbi-blast+ (2.8.1-1) unstable; urgency=medium
 
   * New upstream release.
diff --git a/debian/rules b/debian/rules
index b017193c..15568fa7 100755
--- a/debian/rules
+++ b/debian/rules
@@ -14,7 +14,7 @@ DEB_CONFIGURE_EXTRA_FLAGS=--with-dll --with-mt 
--without-autodep \
 --without-makefile-auto-update --with-flat-makefile --without-caution \
 --without-dbapi --without-lzo --with-runpath=/usr/lib/ncbi-blast+ \
 --with-build-root=BUILD --without-debug --without-downloaded-vdb \
---with-mbedtls
+--with-mbedtls --without-sse42
 proj=algo/blast/ app/ objmgr/ objtools/align_format/ objtools/blast/
 
 #ifneq (,$(findstring nostrip,$(DEB_BUILD_OPTIONS)))

Bug#952413: lftp desktop file is missing the additional category 'FileTransfer'

[Joerg Schiermeier, Bielefeld/Germany]

Package: lftp
Version: 4.8.4-2+b1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hello!

The desktop file for Linux (/usr/share/applications/lftp.desktop) is missing 
the additional category 'FileTransfer' which is a sub-category of 'Network'. 
Please see the documentation about desktop files here:


This category should be added.

- -- 
Yours sincerely
Joerg Schiermeier



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

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

Versions of packages lftp depends on:
ii  libc62.29-10
ii  libgcc-s1 [libgcc1]  10-20200211-1
ii  libgcc1  1:10-20200211-1
ii  libgnutls30  3.6.12-2
ii  libidn2-02.2.0-2
ii  libreadline8 8.0-3
ii  libstdc++6   10-20200211-1
ii  libtinfo66.1+20191019-1
ii  netbase  6.1
ii  zlib1g   1:1.2.11.dfsg-1.2

Versions of packages lftp recommends:
ii  openssh-client [ssh-client]  1:8.1p1-5

lftp suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-
Comment: This was created by GnuPG for Linux.

iQIzBAEBCAAdFiEERMHJSMoKBiNrvtXJodFQ9YsO8GMFAl5TISEACgkQodFQ9YsO
8GOynRAAhm9QFbzI9/MCRZNjcyJct39xH8lSJpMAs8JdxcMkkngEBIBRTQ/LdvlQ
z17F+9Th7JoVu2/cx++GhAhHknJ89B2RATQ7lgNQstfrITZ8x4kjLqMd0eD0NvNH
PfjtS6WIYuJIPebHWWJWNowVR4CpuH7FRLTU+03u+8+4Z44Uq15TzoJ0LRaqyoyZ
VD199L5x3KMD0QJP7J9D9y/kGrEoCB/X6qfDTUAswhlu78GDuRYDPZILVOemJrEW
xKeZiALUZL/ww3Tk2k/wzEXFBS4m0JBnJn6u6QJo7aJqzNUw7371aFgs6uNSyiDj
48LhwujV+hHMtUUCho0C2ZDcTbcbrtBm+LAC7gEuU/TXfcPPOqootrvIe0CyOPZV
ae7UYfI/IHxvq4cBhwPln152VfnEMMZnwo1mdv3rNejEeBcyMq6ICRtHmrxAlb9E
Ia0LkFF46Gmv5QzvLjs4aJZemaig9/qKuycrFa23lImE/Aji4TFoSbl201nDFNSn
QgjH4/gMuXhty3ANKoSvw0/4uzCMYiUydPvYTjiI250uzh0V9a2wPHzruuEopUkj
aGIFxAnQRJGHfhBvvX6idZ7O8NVMMUiLD82FzJAgQUOZFhXA2l2XYY7sbduDp5qn
RkMvE4xHgAq7udVpiFwj+/Rdw4weH9Y6bciPd8sXj64u+t4f3pQ=
=8CCS
-END PGP SIGNATURE-

Bug#952266: lxqt-config: FTBFS: dh_auto_configure: error: cd obj-x86_64-linux-gnu && cmake -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=None -DCMAKE_INSTALL_SYSCONFDIR=/etc -DCMAKE_INSTALL_LOCALSTAT

[Alf Gaida]

Hi Lucas,

the relevant part in the build log is this one:

-- Found PkgConfig: /usr/bin/pkg-config (found version "0.29")
-- Checking for modules 'xcb;xcb'
--   Found xcb, version 1.13.1
--   Found xcb, version 1.13.1
-- Found XCB:
/usr/lib/x86_64-linux-gnu/libxcb.so;/usr/lib/x86_64-linux-gnu/libxcb.so 
-- Found ZLIB: /usr/lib/x86_64-linux-gnu/libz.so (found version "1.2.11")
-- Checking for module 'xorg-libinput'
--   Found xorg-libinput, version 0.29.0
-- Checking for module 'xi'
--   Found xi, version 1.7.9
-- Checking for module 'libudev'
--   Found libudev, version 244
-- Checking for modules 'xcb;xcb;xcb-randr'
--   No package 'xcb-randr' found
CMake Error at
/usr/share/cmake-3.16/Modules/FindPackageHandleStandardArgs.cmake:146
(message):
  Could NOT find XCB (missing: XCB_LIBRARIES)
Call Stack (most recent call first):
  /usr/share/cmake-3.16/Modules/FindPackageHandleStandardArgs.cmake:393
(_FPHSA_FAILURE_MESSAGE)
  /usr/share/cmake/lxqt-build-tools/find-modules/FindXCB.cmake:52
(find_package_handle_standard_args)
  lxqt-config-brightness/CMakeLists.txt:5 (find_package)

Anyways - somewhat has changed so the package now need the additional
build dependency libxcb-randr0-dev

Will add and upload soon.

Cheers Alf

Bug#951818: sslstrip: should this package be removed?

[Chow Loong Jin]

On Sat, Feb 22, 2020 at 10:31:08AM -0500, Sandro Tosi wrote:
> On Sat, Feb 22, 2020 at 3:25 AM Chow Loong Jin  wrote:
> > [...]
> did you read https://github.com/moxie0/sslstrip/issues/16 where they
> declared the project useless and dead, with a new fork at
> https://github.com/byt3bl33d3r/sslstrip2 , again declared dead at
> https://github.com/byt3bl33d3r/sslstrip2/issues/1 . So maybe this
> functionality is just no longer there.

Fair enough. I had realized that HSTS has largely defeated the sslstrip
attack, but thought it might still be useful for some people (e.g.
demonstrating an old attack). I hadn't realized there was an sslstrip2
though. I guess this should go then.

> > (ported to Python 3 with a distro patch of
> > course).
> 
> are you planning on write this patch? if so, do you know already when
> you're gonna have time to do that?

I had started work on it a couple of days ago and was working through
some byte/string issues but I guess I'll drop it.

-- 
Kind regards,
Loong Jin


signature.asc
Description: PGP signature

Bug#950608: gmp 6.2.0 crashes postgresql-pgmp (& others)

[Steven Robbins]

On Sunday, February 23, 2020 2:32:49 P.M. CST John Scott wrote:
> On February 23, 2020 3:11:46 PM EST, Marco Bodrato 
 wrote:
> >Ciao,
> >
> >Il Dom, 9 Febbraio 2020 9:34 pm, Steven Robbins ha scritto:
> >> On Sunday, February 9, 2020 9:54:02 A.M. CST Marco Bodrato wrote:

> >It seems to me that all packages incorrectly using the internal
> >representation and not the documented interface of GMP where patched.
> >
> >What else stops migration of GMP to testing? Maybe a release of GMP
> >
> >explicitly saying that it breaks:
> > libmath-gmp-perl < 2.20
> > libmath-prime-util-gmp-perl < 0.51-2
> > postgresql-pgmp < 1.0.4
> >
> >is needed? So that nobody will update the library without updating also
> >the other possibly failing packages?
> >
> >Ĝis,
> >m
> 
> GMP is not migrating because this bug was marked as done by uploading
> postgresql-pgmp. However, this bug is filed against GMP, so the bug
> metadata still suggests that GMP 6.2.0 introduces this serious issue.

Right.  I have tried twice to close the bug, with no apparent effect.  Perhaps 
with Marco's suggestion of a new upload containing specific breaks will let me 
close it against a new revision of gmp.

-Steve


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

Bug#951939: contextfree: FTBFS: src-common/cfdg.cpp:75:71: error: no matching function for call to ‘find(std::array, 18>::const_iterator, std::array

[John Horigan]

This bug is due to several source files using STL algorithms without
having the required #include . This will be fixed in
upstream and a new feature release of Context Free will be uploaded to
Debian soon.

Bug#952337: [pkg-php-pear] Bug#952337: php-mockery: FTBFS: Class 'DOMDocument' not found

[David Prévot]

Hi Lucas and PHP Maintainers,

Le 23/02/2020 à 03:53, Lucas Nussbaum a écrit :
> Source: php-mockery
> Version: 1.3.1-1
> Severity: serious
> Justification: FTBFS on amd64
[…]
>> phpunit --include-path library
>> Class 'DOMDocument' not found
>> make[1]: *** [debian/rules:28: override_dh_auto_test] Error 1

That seems related to the recent move from php7.3 to php7.4 by default:
the PECL extensions probably need to be rebuilt, but I can’t find any
information about a requested or ongoing transition related to the move
from phpapi-20180731 to phpapi-20190902. Has it been overlooked?

Regards

David



signature.asc
Description: OpenPGP digital signature

Bug#930292: texlive-luatex: lualatex uses huge memory for Noto CJK fonts

[Ryutaroh Matsumoto]

Hi Nobert, my email last week was incorrect.

> luahbtex should behave better, right, if the font is loaded with the
> harf renderer selected?

Actually, mode=harf with luaotfload 3.12 uses only 0.3 GB, but
\setmainfont in fontspec.sty somehow uses 2 GB...
It was reported at
https://github.com/wspr/fontspec/issues/414
and
https://ja.osdn.net/projects/luatex-ja/ticket/40052

Ryutaroh

Bug#952022: [DRE-maint] Bug#952022: ruby-puppet-syntax: FTBFS: ERROR: Test "ruby2.7" failed: LoadError:

[Daniel Leidert]

Am Sonntag, den 23.02.2020, 08:46 +0100 schrieb Lucas Nussbaum:

> During a rebuild of all packages in sid, your package failed to build
> on amd64.
> 
> Relevant part (hopefully):
> > LoadError:
> >   libfacter was not found. Please make sure it was installed to the
> > expected location.
> >   cannot load such file -- libfacter.so

facter needs a rebuild against ruby2.7.

Regards, Daniel


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

Bug#952412: Please provide mount.nfs4 and umount.nfs4 without requiring rpcbind and similar

[Josh Triplett]

Package: nfs-common
Version: 1:1.3.4-2.5
Severity: normal

NFSv4 no longer requires rpcbind or any of the other associated
services; it works with only a single TCP port (2049). I'd like to be
able to mount NFSv4 filesystems (which requires mount.nfs4 and
umount.nfs4) without having to install rpcbind or any other system
services that nfs-common provides or pulls in.

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

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

Versions of packages nfs-common depends on:
ii  adduser 3.118
pn  keyutils
ii  libc6   2.29-10
ii  libcap2 1:2.32-1
ii  libcom-err2 1.45.5-2
ii  libdevmapper1.02.1  2:1.02.167-1
ii  libevent-2.1-7  2.1.11-stable-1
ii  libgssapi-krb5-21.17-6
ii  libkeyutils11.6.1-2
ii  libkrb5-3   1.17-6
ii  libmount1   2.34-0.1
pn  libnfsidmap2
pn  libtirpc3   
ii  libwrap07.6.q-30
ii  lsb-base11.1.0
pn  rpcbind 
ii  ucf 3.0038+nmu1

Versions of packages nfs-common recommends:
ii  python  2.7.17-2

Versions of packages nfs-common suggests:
pn  open-iscsi  
pn  watchdog

Bug#944603: FYI on bug 944603

[John Stewart]

 Hello,

I've had the check printing bug reported as bug 944603 while running Raspian
Buster on a Raspberry Pi4.  The version of Gnucash is Version: 3.4 Build ID:
3.4+ (2018-12-30).  I have more information below:

The problem is NOT 'print checks' per se: the problem is in the customization
section of check printing.  If a check is customized and the resulting
customization saved from the program as a "CHK" file, it's presence in the
default subdirectory (which on Raspian
is: /home/[USER]/.local/share/gnucash/checks) will continuously crash the
program until the file is given an different extension (something other than
CHK).  Inspecting the file with a text editor shows the file to be written
incorrectly: there are numerous places where semicolons are placed
inappropriately.  If the file is corrected manually AND if the file is
transferred to the /usr/share/gnucash/checks subdirectory, the check printing
process progresses normally and crashes are avoided. 

I noticed that the newest version of Linux Mint (19.3) is using Gnucash version
2.16.19 rev c1b5e6c8d+ 2018-04-09.  There are no check printing or check
customization problems in this version.  

Thanks for all you do!!  Hope this helpswish I could do more.


Regards, 

---John Stewart

Bug#952311: docker.io: FTBFS: dh_auto_build: error: cd .gopath && go install -trimpath -v -p 4 [...] returned exit code 2

[Dmitry Smirnov]

On Monday, 24 February 2020 12:39:22 AM AEDT Lucas Nussbaum wrote:
> > # github.com/docker/libnetwork
> > src/github.com/docker/libnetwork/resolver.go:487:28: undefined:
> > "github.com/miekg/dns".ErrTruncated

Yes, thanks. This is due to recent upload of "github.com/miekg/dns" that 
fixed CVE and unblocked upload of another package with fixes for two CVEs.

Until upstream fix the problem we will have to switch to bundled (vendored) 
library unless somebody can produce a patch for the problem...

-- 
Regards,
 Dmitry Smirnov.

---

If you travel the earth, you will find it is largely divided into two
classes of people - people who say "I wonder why such and such is not done"
and people who say "Now who is going to prevent me from doing that thing?"
-- Winston Churchill


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

Bug#951117: libecore1: .xsession-errors eats all disk space

[sergio]

On 24/02/2020 01:11, Ross Vandegrift wrote:

> Thanks for the details.  Unfortunately, I still cannot reproduce this.
 I've
> tried restarting Enlightenment and then opening tilix, making it
fullscreen,
> and then exiting.

You should be able to reproduce this bug with the config that I've send you
for the next one.

> How do you get a window on top of fullscreened tilix?

Sorry for bad explanation, it should be vice-versa: tilix on top of
another fullscreened window.


>  As soon as I do anything that would raise another window
>  (Ctrl-Alt-down, Alt-Tab, etc), tilix exits fullscreen mode.

My settings:

Windows -> Window Geometry -> Maximization
Policy: Fullscreen
Direction: Both
Manipulation:
Allow manipulation of maximized windows: yes
Allow windows above fullscreen window: yes


-- 
sergio.

Bug#938885: zeitgeist-explorer: Python2 removal in sid/bullseye

[Boyuan Yang]

X-Debbugs-CC: manishsi...@ubuntu.com

Hi,

Considering that the zeitgeist-explorer upstream has long dead and that Ubuntu
has already removed it, I am proposing to have this package removed from
Debian.

I will submit the removal bug 3 days later (on Feb. 26, 2020). If there's any
doubts, please let me know immediately.

-- 
Thanks,
Boyuan Yang

On Fri, 30 Aug 2019 07:59:45 + Matthias Klose  wrote:
> Package: src:zeitgeist-explorer
> Version: 0.2-1.2
> Severity: normal
> Tags: sid bullseye
> User: debian-pyt...@lists.debian.org
> Usertags: py2removal
> 
> Python2 becomes end-of-live upstream, and Debian aims to remove
> Python2 from the distribution, as discussed in
> https://lists.debian.org/debian-python/2019/07/msg00080.html
> 
> Your package either build-depends, depends on Python2, or uses Python2
> in the autopkg tests.  Please stop using Python2, and fix this issue
> by one of the following actions.
> 
> - Convert your Package to Python3. This is the preferred option.  In
>   case you are providing a Python module foo, please consider dropping
>   the python-foo package, and only build a python3-foo package.  Please
>   don't drop Python2 modules, which still have reverse dependencies,
>   just document them.
>   
>   This is the preferred option.
> 
> - If the package is dead upstream, cannot be converted or maintained
>   in Debian, it should be removed from the distribution.  If the
>   package still has reverse dependencies, raise the severity to
>   "serious" and document the reverse dependencies with the BTS affects
>   command.  If the package has no reverse dependencies, confirm that
>   the package can be removed, reassign this issue to ftp.debian.org,
>   make sure that the bug priority is set to normal and retitle the
>   issue to "RM: PKG -- removal triggered by the Python2 removal".
> 
> - If the package has still many users (popcon >= 300), or is needed to
>   build another package which cannot be removed, document that by
>   adding the "py2keep" user tag (not replacing the py2remove tag),
>   using the debian-pyt...@lists.debian.org user.  Also any
>   dependencies on an unversioned python package (python, python-dev)
>   must not be used, same with the python shebang.  These have to be
>   replaced by python2/python2.7 dependencies and shebang.
> 
>   This is the least preferred option.
> 
> If the conversion or removal needs action on another package first,
> please document the blocking by using the BTS affects command, like
> 
>   affects  + src:zeitgeist-explorer
> 
> If there is no py2removal bug for that reverse-dependency, please file
> a bug on this package (similar to this bug report).
> 
> If there are questions, please refer to the wiki page for the removal:
> https://wiki.debian.org/Python/2Removal, or ask for help on IRC
> #debian-python, or the debian-pyt...@lists.debian.org mailing list.
> 
> 


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

Bug#952024: ruby-rspec-puppet: FTBFS: ERROR: Test "ruby2.7" failed: LoadError:

[Daniel Leidert]

Am Sonntag, den 23.02.2020, 08:46 +0100 schrieb Lucas Nussbaum:

[..]
> Relevant part (hopefully):
> > LoadError:
> >   libfacter was not found. Please make sure it was installed to the
> > expected location.
> >   cannot load such file -- libfacter.so

facter needs a rebuild to ruby2.7. Locally it builds just fine and creates the
library link we need.

Regards, Daniel


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

Bug#908187: dist: diff for NMU version 1:3.5-236-0.2

[Boyuan Yang]

Tags: patch  pending

Dear maintainer,

I've prepared an NMU for dist (versioned as 1:3.5-236-0.2) and
uploaded it to DELAYED/7. Please feel free to tell me if I
should delay it longer.

Regards,
Boyuan Yang

diff -u dist-3.5-236/debian/changelog dist-3.5-236/debian/changelog
--- dist-3.5-236/debian/changelog
+++ dist-3.5-236/debian/changelog
@@ -1,3 +1,15 @@
+dist (1:3.5-236-0.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/dist.postinst: Fix wrong direction form.
+(Closes: #908187)
+  * debian/rules: Explicitly provide tool path to avoid usrmerge
+differences and make package reproducible. (Closes: #915910)
+  * debian/rules: Avoid manually setting DEB_HOST_MULTIARCH, use
+/usr/share/dpkg/architecture.mk instead. (lintian warning)
+
+ -- Boyuan Yang   Sun, 23 Feb 2020 17:37:44 -0500
+
 dist (1:3.5-236-0.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -u dist-3.5-236/debian/dist.postinst dist-3.5-236/debian/dist.postinst
--- dist-3.5-236/debian/dist.postinst
+++ dist-3.5-236/debian/dist.postinst
@@ -288,7 +288,7 @@
 
 set_org_perms () {
 chown root /etc/news/organization
-if grep news /etc/group 2>&1 >/dev/null ; then
+if grep news /etc/group > /dev/null 2>&1 ; then
chgrp news /etc/news/organization
 else
chgrp root /etc/news/organization
@@ -397,7 +397,7 @@
if test ! -d /etc/news ; then
mkdir /etc/news
chown root /etc/news
-   if grep news /etc/group 2>&1 >/dev/null ; then
+   if grep news /etc/group > /dev/null 2>&1 ; then
chgrp news /etc/news
else
echo "darn, you do not have news in /etc/group"
diff -u dist-3.5-236/debian/rules dist-3.5-236/debian/rules
--- dist-3.5-236/debian/rules
+++ dist-3.5-236/debian/rules
@@ -23,8 +23,8 @@
  patnotify patpost patftp patname patsnap patcol \
  patclean patindex
 
-DPKG_ARCH := dpkg-architecture
-export DEB_HOST_MULTIARCH  := $(shell $(DPKG_ARCH) $(ha)
-qDEB_HOST_MULTIARCH)
+# For DEB_HOST_MULTIARCH
+include /usr/share/dpkg/architecture.mk
 
 %:
dh $@
@@ -35,15 +35,19 @@
touch .config/nomail&& \
   sh ./Configure   \
 -de\
--D prefix=$(PREFIX)\
+-D prefix=/usr \
 -D orgname=/etc/news/organization  \
 -D myhostname=localhost\
 -D mydomain=localdomain\
 -D defeditor=/usr/ae   \
-   -D privlib=/usr/share/$(package)   \
+-D privlib=/usr/share/$(package)   \
 -D pager=/bin/more \
 -D mansrc=/usr/share/man/  \
 -D cf_email='$(email)' \
+-D grep=/bin/grep  \
+-D sed=/bin/sed\
+-D cat=/bin/cat\
+-D zcat=/bin/zcat  \
 -D d_berknames='define'
 
 


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

Bug#952088: sync is not longer bundled, but a gem

[Daniel Leidert]

The test in Ruby 2.7 fails because the sync library has been split out in Ruby
2.6 and is now available as a gem:
https://www.ruby-lang.org/en/news/2019/12/25/ruby-2-7-0-released/




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

Bug#952411: chromium: coming ScrollToTextFragment in Chrome 80

[Matt Taggart]

Package: chromium
Version: 80.0.3987.106-1

I just saw this article about a new feature coming in Chrome 80,

https://www.forbes.com/sites/gordonkelly/2020/02/23/google-chrome-80-upgrade-deep-linking-update-chrome-browser/

That seems like something we want to not include in debian chromium.
I ran a grep on the current unstable source and this is what it found.

$ rgrep ScrollToTextFr
third_party/blink/renderer/core/page/scrolling/text_fragment_anchor.cc: 
// https://wicg.github.io/ScrollToTextFragment/#should-allow-text-fragment
third_party/blink/renderer/core/frame/fragment_directive.idl:// 
https://github.com/WICG/ScrollToTextFragment


Based on those I then searched for "TextFragment" which found a lot more 
(but I don't know which are relevent).


Maybe someone who understands the chromium source can investigate further.

Thanks,

--
Matt Taggart
tagg...@debian.org

Bug#934287: python3-winrm: Please consider providing optional Kerberos and CredSSP feature

[Dominic Hargreaves]

On Fri, Aug 09, 2019 at 04:36:49PM +0900, Ryo IGARASHI wrote:
> Package: python3-winrm
> Version: 0.3.0-2
> Severity: wishlist
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> Dear Maintainer,
> 
> pywinrm can optionally use Kerberos or CredSSP authentication,
> but the package does not provide a way to use them.
> 
> with pip, you can use Kerberos authentication using
> $ pip install pywinrm[kerberos]
> 
> and CredSSP authentication using
> $ pip install pywinrm[credssp]

Hello

I'm afraid I'm not using this package any more, so won't be in a position
to continue maintaining it. Perhaps someone else from the Python packaging
team can help?

Best,
Dominic

Bug#952410: tracker-miners: FTBFS on riscv64 due to missing libseccomp build-depends

[Aurelien Jarno]

Source: tracker-miners
Version: 2.3.1-3
Severity: normal
Tags: patch
User: debian-ri...@lists.debian.org
Usertags: riscv64

Dear maintainer,

tracker-miners fails to build on riscv64 with the following error:


| meson.build:282:2: ERROR: Problem encountered: Libseccomp is mandatory for 
sandboxed metadata extraction
| dh_auto_configure: error: cd obj-riscv64-linux-gnu && LC_ALL=C.UTF-8 meson .. 
--wrap-mode=nodownload --buildtype=plain --prefix=/usr --sysconfdir=/etc 
--localstatedir=/var --libdir=lib/riscv64-linux-gnu 
--libexecdir=lib/riscv64-linux-gnu -Dauto_features=enabled 
-Dgeneric_media_extractor=gstreamer 
-Dsystemd_user_services=/usr/lib/systemd/user -Ddocs=true 
-Dfunctional_tests=true -Dminer_rss=false -Dbattery_detection=upower 
-Dcharset_detection=icu --libexecdir=/usr/lib/tracker returned exit code 1
| make[1]: *** [debian/rules:41: override_dh_auto_configure] Error 25
| make[1]: Leaving directory '/<>'
| make: *** [debian/rules:38: build-arch] Error 2
| dpkg-buildpackage: error: debian/rules build-arch subprocess returned exit 
status 2

The full build log is available there:
https://buildd.debian.org/status/fetch.php?pkg=tracker-miners=riscv64=2.3.1-3=1580690713=0

libseccomp has just been made available on riscv64. I just gave it a try
and the following patch is enough to get the package building:

--- tracker-miners-2.3.1/debian/control.in  2020-01-18 21:39:59.0 
+
+++ tracker-miners-2.3.1/debian/control.in  2020-02-23 21:34:04.0 
+
@@ -37,7 +37,7 @@
libgxps-dev,
libosinfo-1.0-dev (>= 0.2.9),
libcue-dev,
-   libseccomp-dev (>= 2.0) [!hurd-any !kfreebsd-any !linux-alpha 
!linux-ia64 !linux-m68k !linux-riscv64 !linux-sh4 !linux-sparc64],
+   libseccomp-dev (>= 2.0) [!hurd-any !kfreebsd-any !linux-alpha 
!linux-ia64 !linux-m68k !linux-sh4 !linux-sparc64],
dbus (>= 1.3.1) ,
dbus-x11 (>= 1.3.1) ,
gstreamer1.0-libav ,

Would it be possible to include it in the next upload?

Thanks,
Aurelien

Bug#951117: libecore1: .xsession-errors eats all disk space

[Ross Vandegrift]

On Sun, Feb 23, 2020 at 10:37:13PM +0300, sergio wrote:
> More details:
> 
> instead of fullscreening the tilix it can be closed when it's above
> another fullscreen window
> 
> I'm unable to reproduce it just after session start, but after restart
> it reproduces frequently.
> 
> So the sequence is:
> 
> 1. restart enlightment
> 2. open tilix
> 3. put tilix above another fullscreen window or fullscreen itself
> 4. close it
> 5. repeat the sequence several times untill errors will be massively
> printed into ~/.xsession-errors
> 
> I've checked this on NUC, and it's reproducable.

Thanks for the details.  Unfortunately, I still cannot reproduce this.  I've
tried restarting Enlightenment and then opening tilix, making it fullscreen,
and then exiting.  Even after two dozen cycles, no constant stream of logs is
triggered.

How do you get a window on top of fullscreened tilix?  As soon as I do anything
that would raise another window (Ctrl-Alt-down, Alt-Tab, etc), tilix exits
fullscreen mode.

I've also tried testing with and without fullscreen compositing enabled, it
doesn't seem to make a difference.

Ross

Bug#952409: RFS: vtgrab/0.1.8-3.2 [NMU, RC] -- A VNC like console monitoring

[Sudip Mukherjee]

Package: sponsorship-requests
Severity: important

Dear mentors,

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

 * Package name: vtgrab
   Version : 0.1.8-3.2
   Upstream Author : Tim Waugh 
 * URL : http://people.redhat.com/twaugh/ftp/vtgrab/
 * License : GPL-2.0+
 * Vcs : None
   Section : admin

It builds those binary packages:

  vtgrab - A VNC like console monitoring

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/v/vtgrab/vtgrab_0.1.8-3.2.dsc

Changes since the last upload:

   * Non-maintainer upload.
   * Fix ftbfs. (Closes: #925854)


-- 
Regards
Sudip

Bug#952229: libkiokudb-backend-dbi-perl: FTBFS: dh_auto_test: error: make -j4 test TEST_VERBOSE=1 returned exit code 2

[gregor herrmann]

Control: tag -1 + confirmed
Control: block -1 with 950999

On Sun, 23 Feb 2020 14:09:19 +0100, Lucas Nussbaum wrote:

> Source: libkiokudb-backend-dbi-perl
> Version: 1.23-2
> Severity: serious
> Justification: FTBFS on amd64
> Tags: bullseye sid ftbfs
> Usertags: ftbfs-20200222 ftbfs-bullseye
> 
> Hi,
> 
> During a rebuild of all packages in sid, your package failed to build
> on amd64.

I think this is actually a side effect of #950999 in libkiokudb-perl.

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
   `-   


signature.asc
Description: Digital Signature

Bug#925854: vtgrab: diff for NMU version 0.1.8-3.2

[Sudip Mukherjee]

Control: tags 925854 + patch
Control: tags 925854 + pending

Dear maintainer,

I've prepared an NMU for vtgrab (versioned as 0.1.8-3.2) and
uploaded it to mentors for sponsoring. Please feel free to tell me if I
should remove it from mentors.

--
Regards
Sudip


diff -Nru vtgrab-0.1.8/debian/changelog vtgrab-0.1.8/debian/changelog
--- vtgrab-0.1.8/debian/changelog   2018-10-27 16:32:20.0 +0100
+++ vtgrab-0.1.8/debian/changelog   2020-02-23 21:49:13.0 +
@@ -1,3 +1,10 @@
+vtgrab (0.1.8-3.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix ftbfs. (Closes: #925854)
+
+ -- Sudip Mukherjee   Sun, 23 Feb 2020 21:49:13 
+
+
 vtgrab (0.1.8-3.1) unstable; urgency=medium
 
   [ Rainer Herrmann ]
diff -Nru vtgrab-0.1.8/debian/patches/fix_ftbfs.patch 
vtgrab-0.1.8/debian/patches/fix_ftbfs.patch
--- vtgrab-0.1.8/debian/patches/fix_ftbfs.patch 1970-01-01 01:00:00.0 
+0100
+++ vtgrab-0.1.8/debian/patches/fix_ftbfs.patch 2020-02-23 21:09:34.0 
+
@@ -0,0 +1,16 @@
+Description: Fix ftbfs
+ The lib needs to be mentioned after the input object files.
+
+---
+
+--- vtgrab-0.1.8.orig/Makefile.in
 vtgrab-0.1.8/Makefile.in
+@@ -214,7 +214,7 @@ rvcd: $(rvcd_OBJECTS) $(rvcd_DEPENDENCIE
+ 
+ twiglet: $(twiglet_OBJECTS) $(twiglet_DEPENDENCIES)
+   @rm -f twiglet
+-  $(LINK) $(twiglet_LDFLAGS) $(twiglet_OBJECTS) $(twiglet_LDADD) $(LIBS)
++  $(LINK) $(twiglet_OBJECTS) $(twiglet_LDFLAGS) $(twiglet_LDADD) $(LIBS)
+ 
+ install-docDATA: $(doc_DATA)
+   @$(NORMAL_INSTALL)
diff -Nru vtgrab-0.1.8/debian/patches/series vtgrab-0.1.8/debian/patches/series
--- vtgrab-0.1.8/debian/patches/series  1970-01-01 01:00:00.0 +0100
+++ vtgrab-0.1.8/debian/patches/series  2020-02-23 21:09:34.0 +
@@ -0,0 +1 @@
+fix_ftbfs.patch

Bug#952408: fontforge: no longer works in non-GUI environment

[Julian Gilbey]

Package: fontforge
Version: 1:20190801~dfsg-2
Severity: important

Hello!

Up until a relatively recent release of fontforge, if fontforge were
run from a script without a GUI present, it would behave exactly like
the non-GUI version.  But this release breaks this behaviour: even
running 'fontforge --help' bombs out with the error message:

Unable to init server: Could not connect: Connection refused

(fontforge:789219): Gdk-WARNING **: 21:11:59.079: cannot open display:

This has broken mftrace (bug #952185), and might cause other problems
as well.

Without completely rewriting fontforge back to the way it was
previously, which I'm guessing the upstream have moved away from, one
possible solution might be to allow both fontforge and fontforge-nox
to be installed simultaneously.  That is, have fontforge install
fontforge as /usr/bin/fontforge-x, and fontforge-nox install it as
/usr/bin/fontforge-nox, and use the alternatives system to make
/usr/bin/fontforge to point to one of them (preferring the fontforge-x
version).  That way, scripts can call /usr/bin/fontforge-nox instead
of /usr/bin/fontforge.

The only other files that are common to both fontforge and
fontforge-nox are /usr/bin/{fontimage,fontlint,sfddiff}, which could
be moved to fontforge-common.

This would then allow mftrace to work again; I really don't want to
replace the fontforge dependency with fontforge-nox, as that will make
it uninstallable for anyone who also wants to use the graphical
fontforge.

Best wishes,

   Julian

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

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

Versions of packages fontforge depends on:
ii  fontforge-common  1:20190801~dfsg-2
ii  libc6 2.29-10
ii  libfontforge3 1:20190801~dfsg-2
ii  libgdraw6 1:20190801~dfsg-2

fontforge recommends no packages.

Versions of packages fontforge suggests:
ii  fontforge-doc  1:20190801~dfsg-2
ii  fontforge-extras   1:20190801~dfsg-2
ii  potrace1.16-2
pn  python3-fontforge  

-- no debconf information

Bug#951366: rkhunter: libkeyutils1/1.6.1-2 triggers a false positive

[Francois Marier]

On 2020-02-15 at 16:12:16, Francesco Poli wrote:
> thanks from a suggestion from keyutils Debian package maintainer,
> I managed to work around the issue, by adding the following two
> lines to my rkhunter configuration file:
> 
>   $ grep keyutils /etc/rkhunter.conf 
>   RTKT_FILE_WHITELIST=/lib/x86_64-linux-gnu/libkeyutils.so.1.9
>   USER_FILEPROP_FILES_DIRS=/lib/x86_64-linux-gnu/libkeyutils.so.1.9

The work-around that got rid of these messages on my machine is putting the
following in /etc/rkhunter.conf.local:

  RTKT_FILE_WHITELIST=/usr/lib/x86_64-linux-gnu/libkeyutils.so.1.9

The other line wasn't necessary for me.

Francois

-- 
https://fmarier.org/


signature.asc
Description: PGP signature

Bug#952407: transition: libmypaint

[Boyuan Yang]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-CC: jbi...@debian.org pkg-gnome-maintain...@lists.alioth.debian.org

Dear Release Team,

I am looking into initiating the transition as indicated in the automatic
transition tracker: 
https://release.debian.org/transitions/html/auto-libmypaint.html .

The only reverse (build-)dependency is GIMP. I have tested to rebuild GIMP
against the new libmypaint and everything looks okay.

-- 
Thanks,
Boyuan Yang


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

Bug#951758: graphicsmagick: please lower MIME priority

[GCS]

Control: tags -1 +pending

On Fri, Feb 21, 2020 at 10:00 AM Nicolas Boulenguez  wrote:
> Short version:
> #935099 is not limited to PS/PDF, all image types are affected.
 Indeed.

> A patch is attached.
 Going to apply this, correcting the typo s/prority/priority/ for the
second patch.

Cheers,
Laszlo/GCS

Bug#952406: /lib/systemd/system/nfs-ganesha-lock.service uses .include which is deprecated

[Josh Triplett]

Package: nfs-ganesha
Version: 2.7.6-3
Severity: normal

systemd produces the following log message after installing nfs-ganesha:
/lib/systemd/system/nfs-ganesha-lock.service:2: .include directives are 
deprecated, and support for them will be removed in a future version of 
systemd. Please use drop-in files instead.


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

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

Versions of packages nfs-ganesha depends on:
ii  daemon0.6.4-1+b2
ii  dbus  1.12.16-2
ii  libacl1   2.2.53-5
ii  libblkid1 2.34-0.1
ii  libc6 2.29-10
ii  libcap2   1:2.32-1
ii  libcom-err2   1.45.5-2
ii  libdbus-1-3   1.12.16-2
ii  libgssapi-krb5-2  1.17-6
ii  libkrb5-3 1.17-6
ii  libnfsidmap2  0.25-5.1
ii  libntirpc1.7  1.7.4-2
ii  liburcu6  0.11.1-2
ii  libuuid1  2.34-0.1
ii  libwbclient0  2:4.11.5+dfsg-1
ii  nfs-common1:1.3.4-2.5+b1
ii  rpcbind   1.2.5-8

nfs-ganesha recommends no packages.

nfs-ganesha suggests no packages.

-- no debconf information

Bug#952405: RFS: traceshark/0.9.9~beta-1 [ITP] -- Graphical viewer for the Ftrace and Perf events

[Sudip Mukherjee]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

 * Package name: traceshark
   Version : 0.9.9~beta-1
   Upstream Author : Viktor Rosendahl 
 * URL : https://awesomeopensource.com/project/cunctator/traceshark
 * License : GPL-2+
 * Vcs : https://github.com/sudipm-mukherjee/traceshark.git
   Section : devel

It builds those binary packages:

  traceshark - Graphical viewer for the Ftrace and Perf events

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/t/traceshark/traceshark_0.9.9~beta-1.dsc

Changes since the last upload:

   * Initial release (Closes: #949827)

Note: There is a lintian warning about "binary-without-manpage" which has been 
raised with upstream and Viktor is looking into it.

-- 
Regards
Sudip

Bug#952404: scanbd: crash on startup: kernel internal error: Oops 206 with current raspbian buster on rpi4 4g

[Ingo Breßler]

Package: scanbd
Version: 1.5.1-5
Severity: important

Dear Maintainer,

I installed the package *scanbd* on the current Raspbian buster on a
Raspberry Pi 4 (4GB).
The behaviour is identical regardless of version '1.5.1-5' or '1.5.1-4'.
The latter version works fine with a Raspberry Pi 2B and Raspbian stretch.

Running the program *scanbd* with default configuration causes a kernel Oops
even without any scanner attached (and with one attached which used
to work fine):

# export SANE_CONFIG_DIR=/etc/scanbd
# /usr/sbin/scanbd -f -c /etc/scanbd/scanbd.conf

Result:

root@rpi4:~# scanbd -f -c /etc/scanbd/scanbd.conf
scanbd: dbus match type='signal',interface='org.freedesktop.Hal.Manager'

Message from syslogd@rpi4 at Feb 23 17:51:52 ...
 kernel:[ 3081.054930] Internal error: Oops: 206 [#4] SMP ARM

Message from syslogd@rpi4 at Feb 23 17:51:52 ...
 kernel:[ 3081.147131] Process scanbd (pid: 2082, stack limit = 0x35d03bc2)

Message from syslogd@rpi4 at Feb 23 17:51:52 ...
 kernel:[ 3081.150005] Stack: (0xd2581e88 to 0xd2582000)

Message from syslogd@rpi4 at Feb 23 17:51:52 ...
 kernel:[ 3081.152873] 1e80:   c1004d88 d262f300 fe52a6aa 
d2581f60 d2581f60 0001

Message from syslogd@rpi4 at Feb 23 17:51:52 ...
 kernel:[ 3081.155781] 1ea0: d2581f2c d2581eb0 c03d4f48 c06f1038 ef9c0a50 
0101 0002 07b8

Message from syslogd@rpi4 at Feb 23 17:51:52 ...
 kernel:[ 3081.158703] 1ec0:    d2581ed0 c0292810 
c03d235c  c09c996c

Message from syslogd@rpi4 at Feb 23 17:51:52 ...
 kernel:[ 3081.161640] 1ee0:  ef9c0ad0 d2581f04 d2581ef8 c09c996c 
c0292c68 d2581f1c fe52a6aa

Message from syslogd@rpi4 at Feb 23 17:51:52 ...
 kernel:[ 3081.164581] 1f00: c09cc028 0001 d262f300 beabdb8b d2581f60 
beabdb8b d258 0003

Message from syslogd@rpi4 at Feb 23 17:51:52 ...
 kernel:[ 3081.167521] 1f20: d2581f5c d2581f30 c03d5108 c03d4f0c c03f5be4 
c03f52b8 d262f300 c1004d88

Message from syslogd@rpi4 at Feb 23 17:51:52 ...
 kernel:[ 3081.170469] 1f40: d262f301 0001 beabdb8b d258 d2581f94 
d2581f60 c03d5750 c03d5078

Message from syslogd@rpi4 at Feb 23 17:51:52 ...
 kernel:[ 3081.173430] 1f60: 03bd  03bd fe52a6aa b6f17968 
0001 beabdb8b 000b

Message from syslogd@rpi4 at Feb 23 17:51:52 ...
 kernel:[ 3081.176395] 1f80: 0003 c02011c4 d2581fa4 d2581f98 c03d57dc 
c03d56e8  d2581fa8

Message from syslogd@rpi4 at Feb 23 17:51:52 ...
 kernel:[ 3081.179356] 1fa0: c0201000 c03d57d0 0001 beabdb8b 000b 
beabdb8b 0001 

Message from syslogd@rpi4 at Feb 23 17:51:52 ...
 kernel:[ 3081.182313] 1fc0: 0001 beabdb8b 000b 0003 b6f17968 
b4c32d08  

Message from syslogd@rpi4 at Feb 23 17:51:52 ...
 kernel:[ 3081.182313] 1fc0: 0001 beabdb8b 000b 0003 b6f17968 
b4c32d08  

Message from syslogd@rpi4 at Feb 23 17:51:52 ...
 kernel:[ 3081.185275] 1fe0: 0002 beabdb70  b6de3274 8010 
000b  

Message from syslogd@rpi4 at Feb 23 17:51:52 ...
 kernel:[ 3081.214669] Code: 03a02000 e352 0a0c e2442612 (e5d22000)

It is expected to *not* lead to a kernel Oops and should detect when the 
scanner button was pressed instead.

It is a pity that it does not work as expected when moving to the recent rpi4.
I am investigating this further with the source code which will take some time.

-- System Information:
Distributor ID: Raspbian
Description:Raspbian GNU/Linux 10 (buster)
Release:10
Codename:   buster
Architecture: armv7l

Kernel: Linux 4.19.97-v7l+ (SMP w/4 CPU cores)
Kernel taint flags: TAINT_DIE, TAINT_CRAP
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages scanbd depends on:
ii  init-system-helpers   1.56+nmu1
ii  libc6 2.28-10+rpi1
ii  libconfuse2   3.2.2+dfsg-1
ii  libdbus-1-3   1.12.16-1
ii  libsane   1.0.27-3.2
ii  libudev1  241-7~deb10u3+rpi1
ii  lsb-base  10.2019051400+rpi1
ii  openbsd-inetd [inet-superserver]  0.20160825-4
ii  sane-utils1.0.27-3.2
ii  update-inetd  4.49

scanbd recommends no packages.

scanbd suggests no packages.

-- no debconf information

Bug#951839: swig4.0 segfaults building ltt-control

[Torsten Landschoff]

Hi Adrian,

On 2/22/20 11:49 AM, Adrian Bunk wrote:
> Package: swig4.0
> Version: 4.0.1-4
> Severity: serious
> Tags: ftbfs
> Control: affects -1 ltt-control
>
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/ltt-control.html
>
> ...
> /usr/bin/swig -python -I. -I../../../../src/common/sessiond-comm lttng.i
> make[2]: *** [Makefile:896: lttng_wrap.c] Segmentation fault
>
>
>
> Backtrace:
>
> #0  PYTHON::build_combined_docstring (this=this@entry=0x55c023c3fc80, 
> n=n@entry=0x7f7cd7c9f970, ad_type=AUTODOC_FUNC, 
> indent=indent@entry=0x55c02212c0b0, low_level=low_level@entry=true)
> at ../../Source/Modules/python.cxx:1490
> #1  0x55c0220a05ce in PYTHON::cdocstring (low_level=true, 
> ad_type=, n=0x7f7cd7c9f970, this=0x55c023c3fc80)
> at ../../Source/Modules/python.cxx:1596

this appear to be this upstream bug:
https://github.com/swig/swig/issues/1648

I'll incorporate the upstream fix and release a new version.


Greetings, Torsten





signature.asc
Description: OpenPGP digital signature

Bug#952403: enlightenment: another error eats all disk space

[sergio]

Package: enlightenment
Version: 0.23.1-4
Severity: normal

Dear Maintainer,

the error is:

ERR<1162>:evas_main ../src/lib/evas/canvas/evas_object_smart.c:145 
evas_object_smart_data_get() calling smart object API on non-smart object!


To reproduce you need e config. It's binary and I'm not sure there are
no private data, so I'll send archive to Ross directly.

Bug#950608: gmp 6.2.0 crashes postgresql-pgmp (& others)

[John Scott]

On February 23, 2020 3:11:46 PM EST, Marco Bodrato  
wrote:
>Ciao,
>
>Il Dom, 9 Febbraio 2020 9:34 pm, Steven Robbins ha scritto:
>> On Sunday, February 9, 2020 9:54:02 A.M. CST Marco Bodrato wrote:
>>> So, if the new release of the library is able to answer that the number
>>> 387047 is prime, and not only "probably" prime... This should not be
>>> marked as a regression...
>>
>> Indeed!  Thanks for investigating.  An improvement could be simply that
>
>> Is there a bug for libmath-gmp-perl for this test suite issue?
>
>It seems to me that all packages incorrectly using the internal
>representation and not the documented interface of GMP where patched.
>
>What else stops migration of GMP to testing? Maybe a release of GMP
>explicitly saying that it breaks:
> libmath-gmp-perl < 2.20
> libmath-prime-util-gmp-perl < 0.51-2
> postgresql-pgmp < 1.0.4
>is needed? So that nobody will update the library without updating also
>the other possibly failing packages?
>
>Ĝis,
>m
>

GMP is not migrating because this bug was marked as done by uploading 
postgresql-pgmp. However, this bug is filed against GMP, so the bug metadata 
still suggests that GMP 6.2.0 introduces this serious issue.

Bug#943451: Is that bug really pplpy's problem?

[Julien Puydt]

Hi,

it looks more like a doxygen 1.8.16 bug than a pplpy issue, isn't it?

If that is so, then it should be marked as affecting pplpy, but
assigned to doxygen.

Thanks,

JP

Bug#917522: pcmanfm: Some keyboard navigation shortcuts in PCManFM no longer working

[Michael Weghorn]

tags 917522 + fixed-upstream
thanks

On 23/02/2020 10.24, Kurt Meyer wrote:
> When will this get fixed or is it even fixable? It's been over a year.

The bug has already been fixed upstream. s. previous comments, but the
Debian package does not yet contain the fix.



signature.asc
Description: OpenPGP digital signature

Bug#951802: mate-power-manager autostarts with KDE

[Mike Gabriel]

Control: clone #951802 -2
Control: reassign -2 mate-user-share
Control: retitle -2 mate-user-share: Broken .desktop files in XDG autostart
Control: clone #951802 -3
Control: reassign -3 mate-polkit
Control: retitle -2 mate-polkit: Broken .desktop file in XDG autostart

On Fri, 21 Feb 2020 16:57:38 -0500 Mike Gulick  wrote:

> --- /etc/xdg/autostart/mate-power-manager.desktop 2020-02-21 
16:49:45.201709718 -0500

> +++ mate-power-manager.desktop 2020-02-21 16:55:26.249287157 -0500
> @@ -178,7 +178,8 @@
> Terminal=false
> Type=Application
> # Translators: Search terms to find this application. Do NOT 
translate or localize the semicolons! The list MUST also end with a 
semicolon!

> -Categories=OnlyShowIn=MATE;
> +Categories=
> +OnlyShowIn=MATE;
> X-MATE-Bugzilla-Bugzilla=MATE
> X-MATE-Bugzilla-Product=mate-power-manager
> X-MATE-Bugzilla-Component=mate-power-manager
>
> Thanks,
> Mike

Similar line-wrapping flaws can be observed in mate-user-share and 
mate-polkit.


Mike

Bug#952049: pekka-kana-2: FTBFS: SDL_image.h:100:24: error: missing binary operator before token "("

[Simon McVittie]

Control: tags -1 + patch

On Sun, 23 Feb 2020 at 19:06:42 +, Simon McVittie wrote:
> - Some weirdness in src/draw.cpp where it includes 
>   but doesn't link to -lSDL2_image, which I currently don't fully understand
>   (perhaps src/draw.cpp really only needs the base SDL2 library, and not
>   SDL2_image?)

This seems to be related to the build system not passing the $(CXXFLAGS)
to all $(CXX) invocations. See attached patch, also available at
.

I don't really understand why libsdl2 merge request 3 avoids this, but
for some reason it does.

I've also attached/included a patch to make the build show what it's
doing, which is called for by Policy §4.9; I found that change very
useful to debug this. The V=1 convention is fairly common; the
implementation using $(Q) is adapted from ioquake3.

> - Fix pekka-kana-2 to stop making these assumptions, and instead use SDL
>   with the recommended patterns:
> - PKG_CONFIG ?= pkg-config
>   (so that cross-compilation uses the correct cross-pkg-config)
> - add $(${PKG_CONFIG} --cflags sdl2) to all C/C++ compiler command-lines
> - add $(${PKG_CONFIG} --libs sdl2) to linker command-line
> - add $(${PKG_CONFIG} --cflags SDL2_mixer) to all C/C++ compiler
>   command-lines
> - add $(${PKG_CONFIG} --libs SDL2_mixer) to linker command-line
> - include SDL.h (where required) with #include 
> - include SDL_mixer.h (where required) with #include 
> - if SDL2_image is required, do the same as for SDL2_mixer
> - if SDL2_image is not required, use #include  instead

My merge request does not implement all this, only the bare minimum
to get this package compiling again.

smcv
>From ec430cb81da6c9a5e1f51bfe2633f27576d8af24 Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Sun, 23 Feb 2020 19:57:11 +
Subject: [PATCH 1/2] Consistently pass $(CXXFLAGS) to all $(CXX) invocations

This fixes a build failure.

Closes: #952049
---
 debian/changelog  |  8 
 ...Pass-CXXFLAGS-to-all-CXX-invocations.patch | 41 +++
 debian/patches/series |  1 +
 3 files changed, 50 insertions(+)
 create mode 100644 debian/patches/build-Pass-CXXFLAGS-to-all-CXX-invocations.patch
 create mode 100644 debian/patches/series

diff --git a/debian/changelog b/debian/changelog
index 4836128..ba920cd 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+pekka-kana-2 (1.2.5-2) UNRELEASED; urgency=medium
+
+  * d/p/build-Pass-CXXFLAGS-to-all-CXX-invocations.patch:
+Consistently pass $(CXXFLAGS) to all $(CXX) invocations, fixing a
+build failure (Closes: #952049)
+
+ -- Simon McVittie   Sun, 23 Feb 2020 19:55:35 +
+
 pekka-kana-2 (1.2.5-1) unstable; urgency=medium
 
   * New upstream release. FTCBFS bug fix. (Closes: #933080)
diff --git a/debian/patches/build-Pass-CXXFLAGS-to-all-CXX-invocations.patch b/debian/patches/build-Pass-CXXFLAGS-to-all-CXX-invocations.patch
new file mode 100644
index 000..e349bdd
--- /dev/null
+++ b/debian/patches/build-Pass-CXXFLAGS-to-all-CXX-invocations.patch
@@ -0,0 +1,41 @@
+From: Simon McVittie 
+Date: Sun, 23 Feb 2020 19:53:13 +
+Subject: build: Pass $(CXXFLAGS) to all $(CXX) invocations
+
+When it generates dependencies, the C preprocessor needs to see the
+same -I flags as for the actual compilation. Otherwise,
+"#if SDL_VERSION_ATLEAST(2,0,0)" is a syntax error.
+
+Some compiler flags are also significant at link-time, so for
+consistency, also pass the CXXFLAGS to the compiler driver while
+linking.
+
+Signed-off-by: Simon McVittie 
+Bug-Debian: https://bugs.debian.org/952049
+Forwarded: no
+---
+ Makefile | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/Makefile b/Makefile
+index c2bc035..7134b33 100644
+--- a/Makefile
 b/Makefile
+@@ -45,7 +45,7 @@ pk2: makedirs $(PK2_BIN)
+ # Rules for generate the binaries using the object files
+ $(PK2_BIN): $(PK2_OBJ) $(PK2_SPRITE_OBJ) $(PK2_MAP_OBJ) $(ENGINE_OBJ)
+ 	@echo -Linking Pekka Kana 2
+-	@$(CXX) $^ $(LDFLAGS) -o $@
++	@$(CXX) $(CXXFLAGS) $^ $(LDFLAGS) -o $@
+ 
+ # Rules for generate any *.o file
+ -include $(DEPENDENCIES)
+@@ -53,7 +53,7 @@ $(PK2_BIN): $(PK2_OBJ) $(PK2_SPRITE_OBJ) $(PK2_MAP_OBJ) $(ENGINE_OBJ)
+ build/%.o : src/%.cpp
+ 	@echo -Some dependence of $@ was changed, updating
+ 	@$(CXX) $(CXXFLAGS) -I$(SRC_DIR) -o $@ -c $<
+-	@$(CXX) -MM -MT $@ -I$(SRC_DIR) $< > build/$*.d
++	@$(CXX) $(CXXFLAGS) -MM -MT $@ -I$(SRC_DIR) $< > build/$*.d
+ 
+ makedirs:
+ 	@mkdir -p $(BIN_DIR) >/dev/null
diff --git a/debian/patches/series b/debian/patches/series
new file mode 100644
index 000..c14b890
--- /dev/null
+++ b/debian/patches/series
@@ -0,0 +1 @@
+build-Pass-CXXFLAGS-to-all-CXX-invocations.patch
-- 
2.25.1

>From b5ec6a6a2dda44cd7de15a21e82479bd3f84fc27 Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Sun, 23 Feb 2020 20:00:10 +
Subject: [PATCH 2/2] 

Bug#950608: gmp 6.2.0 crashes postgresql-pgmp (& others)

[Marco Bodrato]

Ciao,

Il Dom, 9 Febbraio 2020 9:34 pm, Steven Robbins ha scritto:
> On Sunday, February 9, 2020 9:54:02 A.M. CST Marco Bodrato wrote:
>> So, if the new release of the library is able to answer that the number
>> 387047 is prime, and not only "probably" prime... This should not be
>> marked as a regression...
>
> Indeed!  Thanks for investigating.  An improvement could be simply that

> Is there a bug for libmath-gmp-perl for this test suite issue?

It seems to me that all packages incorrectly using the internal
representation and not the documented interface of GMP where patched.

What else stops migration of GMP to testing? Maybe a release of GMP
explicitly saying that it breaks:
 libmath-gmp-perl < 2.20
 libmath-prime-util-gmp-perl < 0.51-2
 postgresql-pgmp < 1.0.4
is needed? So that nobody will update the library without updating also
the other possibly failing packages?

Ĝis,
m

-- 
http://bodrato.it/papers/

Bug#952116: [ru...@bogodyn.org: Re: [Xastir] Fwd: Bug#952116: xastir: Impossible to transmit due to malformed TOCALL]

[Tom Russo]

Then the git sha displayed in Xastir will be the git sha in your package
repo.  That is probably OK, though, and will accurately reflect its status
in your package management system.

If you want the About box to have the SHA-1 in our repo, you should just
hack XastirGitStamp to display our SHA-1 instead of using git to probe for it,
or have it return nothing at all.  You're already patching our stuff to fit
in with your choices, this should be no big deal.

The feature is in place to allow our power users (all of whom build from source
themselves and don't use packaged versions) to see what version of the code
they're actually using based on their git SHAs.  It's gonna stay there.


On Sun, Feb 23, 2020 at 08:32:57PM +0100, we recorded a bogon-computron 
collision of the  flavor, containing:
> Re: Tom Russo 2020-02-23 <20200223182310.ga7...@bogodyn.org>
> > The script looks in the top level of the Xastir source tree being built
> > for the presence of a .git directory.  The fact that the source tree is 
> > under
> > a package directory that is itself in git should have no impact (there will
> > then be a .git directory at a higher level, and our script will simply 
> > be unaware of it and return no SHA at all).
> 
> In the packaging repo, xastir is in the top level directory.
> 
> https://salsa.debian.org/debian-hamradio-team/xastir
> 
> Christoph

-- 
Tom RussoKM5VY
Tijeras, NM  

 echo "prpv_a'rfg_cnf_har_cvcr" | sed -e 's/_/ /g' | tr [a-m][n-z] [n-z][a-m]

Bug#952400: cppcheck: false positive double free() after non-returning function pointer

[Guillem Jover]

Package: cppcheck
Version: 1.90-4
Severity: normal

Hi!

There's a false positive about double free()s after a non-returning
function pointer, even if that contains an explicit exit() or is
marked with a __noreturn__ attribute.

Attached a test case.

Thanks,
Guillem
#include 
#include 
#include 


static void
__attribute__((__noreturn__))
error(void)
{
	exit(1);
}

void __attribute__((__noreturn__)) (*func_notret)(void);

int
main(int argc)
{
	func_notret = error;
	void *ptr;

	ptr = malloc(1000);

	if (argc == 1) {
		free(ptr);
		func_notret();
	}

	if (argc == 2) {
		free(ptr);
		func_notret();
	}

	free(ptr);

	return 0;
}

Bug#951117: libecore1: .xsession-errors eats all disk space

[sergio]

More details:

instead of fullscreening the tilix it can be closed when it's above
another fullscreen window

I'm unable to reproduce it just after session start, but after restart
it reproduces frequently.

So the sequence is:

1. restart enlightment
2. open tilix
3. put tilix above another fullscreen window or fullscreen itself
4. close it
5. repeat the sequence several times untill errors will be massively
printed into ~/.xsession-errors

I've checked this on NUC, and it's reproducable.

-- 
sergio.

Bug#952399: OpenSSL linking without license exception

[Bastian Germann]

Package: kmod
Version: 26-1
Severity: serious

All of the GPL-2+ licensed executables contained in the kmod binary
package link to libcrypto even though they do not have any OpenSSL
license exception. ftp-master considers this a serious issue. So please
remove this optional dependency or ask upstream for a license exception.

Bug#952116: [ru...@bogodyn.org: Re: [Xastir] Fwd: Bug#952116: xastir: Impossible to transmit due to malformed TOCALL]

[Christoph Berg]

Re: Tom Russo 2020-02-23 <20200223182310.ga7...@bogodyn.org>
> The script looks in the top level of the Xastir source tree being built
> for the presence of a .git directory.  The fact that the source tree is under
> a package directory that is itself in git should have no impact (there will
> then be a .git directory at a higher level, and our script will simply 
> be unaware of it and return no SHA at all).

In the packaging repo, xastir is in the top level directory.

https://salsa.debian.org/debian-hamradio-team/xastir

Christoph

Bug#952396: Strange pydist warning about cysignals package not being found

[Julien Puydt]

Package: python3-cysignals-pari
Version: 1.10.2+ds-3

Hi,

while building pplpy, I noticed the following warning:

I: dh_python3 pydist:228: Cannot find package that provides cysignals.
Please add package that provides it to Build-Depends or add "cysignals
python3-cysignals" line to debian/py3dist-overrides or add proper
dependency to Depends by hand and ignore this info.

I find it pretty strange, because the package does build-depend on
python3-cysignals-pari, which does declare it provides python3-
cysignals.

Perhaps I'll try the debian/py3dist-overrides trick, but I wanted to
see if you had another suggestion before doing so.

Cheers,

JP

Bug#951916: proftpd-mod-vroot: proftpd cannot load mod_vroot

[Hilmar Preuße]

On 2/23/20 2:55 PM, Nikolai Lusan wrote:
> On Sun, 2020-02-23 at 14:49 +0100, Hilmar Preuße wrote:

Hi Nikolai,

>> Severity grave to make sure it doesn't enter testing.
> 
> Wouldn't that be better applied to proftpd-basic - since it was the update
> there that broke this? I posted a bug against mod-vroot because that is
> that package that is currently broken, but if you have proftpd-basic
> install along with a module that is not compatible (i.e. the version of
> mod-vroot currently packaged) then proftpd-basic will just install happily
> and break any configuration you have using that module.
> 
> As far as I can tell the new version of proftpd-basic has a different abi,
> not entirely sure what has changed on the inside of it.
> 
Last week I uploaded new versions for proftpd and proftpd-mod-vroot.
Hence I can't be sure, which upload broke the module. I'm just wondering
how you managed to install "proftpd-basic v1.3.6c-1", which provides the
proftpd-abi-1.3.6c, meanwhile the mod-vroot depends on (exactly)
proftpd-abi-1.3.6b.
Does downgrading the proftpd-basic to the version from testing solves
the issue?

Hilmar
-- 
sigfault
#206401 http://counter.li.org



signature.asc
Description: OpenPGP digital signature

Bug#952398: cppcheck: false positive on missing va_end() after non-returning function

[Guillem Jover]

Package: cppcheck
Version: 1.90-4
Severity: normal

Hi!

There's a false positive on missing va_end() after a non-returning
function. Either because it contains f.ex. an explicit exit() or
because it is marked with attribute __noreturn__.

Attached a test case.

Thanks.
Guillem
#include 
#include 
#include 

static void
__attribute__((__noreturn__)) __attribute__((__format__(__printf__, 1, 0)))
notreturning(const char *fmt, va_list args)
{
	va_list args_copy;

	va_copy(args_copy, args);
	vprintf(fmt, args_copy);
	va_end(args_copy);

	exit(1);
}

static void
check_noret_va_end(const char *fmt, ...)
{
	va_list args;

	va_start(args, fmt);
	notreturning(fmt, args);
}

int
main()
{
	check_noret_va_end("some error");

	return 0;
}

Bug#952397: listmasters join request

[Geert Stappers]

Package: lists.debian.org
Severity: wishlist


Hello Team  Listmasters,


Here Debian Developer  Geert Stappers, my wish is to join your team.

I have exprience in mailinglists as admin. For a Local Linux User Group
and a running assosation I provide "mailman2"

My preferred MTA is Postfix.

I have read https://wiki.debian.org/Teams/ListMaster
and have joined #debian-lists  (just now)

 
Regards
Geert Stappers
DD
-- 
Silence is hard to parse


signature.asc
Description: PGP signature

Bug#952116: [ru...@bogodyn.org: Re: [Xastir] Fwd: Bug#952116: xastir: Impossible to transmit due to malformed TOCALL]

[Tom Russo]

BTW, since you have chosen to use a snapshot rather than a release, you might
want a later snapshot than the commit bb66a77 you're using.  Commit f89c610 
(29 Dec 2019) fixed a serious bug in weather alert parsing that had been 
introduced in commit aafbc49 (9 May 2019) and which still exists in the one 
you're using.  Without that fix, weather alerts were basically broken and were 
showing up scrambled in the weather alerts dialog.

After that, commits c61e49b and 64890aa are recommended as well, as the former
fixes broken builds under GCC 10, and the latter updates the get-nws script
to cope with recent changes in the server from which NWS shapefiles are 
downloaded (the most frequent change we have at this point).

These three commits are the only substantive changes to the development branch
since the bb66a7 commit you're currently using, but there are other, less
consequential changes.  If you move to today's master branch, you're probably 
a lot better off than sticking to that earlier one.

We had intended a 2.2.0 release some time ago, but all of the developers are
pretty much committed to other things at the moment (ranging from "work for a
living" to "recover from a serious accident").  Using the development snapshot
might not be the ideal option, but it's all there is at the moment.  If 
you're not going to use 2.1.4 for the package, you should probably use the most
recent development branch state (which is, at the moment, stable and functional)
and keep an eye on development for serious bug fixes that show up.

On Sun, Feb 23, 2020 at 10:29:38AM -0800, we recorded a bogon-computron 
collision of the  flavor, containing:
> Hi Tom,
> 
> My apologies for the issues the patch to AC_INIT caused with TOCALL and
> thank you for the explanation of versioning semantics.  It was a bad
> assumption on my part, carried over from $dayjob, when I didn't see a
> release tag for 2.1.5 in the repo.  100% my mistake.
> 
> Also, thank you to Iain for the identifying and addressing the bug in
> Debian source package, which will now report 2.1.5 in the Help->About
> dialog.
> 
> Regards,
> tony
> 
> On Sun, Feb 23, 2020 at 10:45:51AM -0700, Tom Russo wrote:
> > This is a forwarded version of an email sent to the Xastir mailing list.
> > I am forwarding to you because you followed up to a different message on 
> > that 
> > list.
> > 
> > To answer your direct question, "Since we are
> > building from a snapshot - i.e., a version somewhere between 2.1.4 and
> > 2.1.5, is there a preference for which we use for configure?"
> > 
> > This is mistaken.  You are in fact using 2.1.5, which means 
> > "development version between 2.1.4.  and whatever our next release will be 
> > called."  Since this version number is used to construct the TOCALL,  the 
> > version number in AC_INIT should just be left at 2.1.5.
> > 
> > 2.1.5 will never be "released", and the presence of APX215 in the TOCALL
> > is supposed to say "this user is using a bleeding-edge version pulled
> > from git".  Our next release will get a version number bump.
> > 
> > The Xastir build system tries to construct a useful Version string to 
> > display
> > in the Help->About and also to print when Xastir is invoked with "-V", but
> > this trick only works if the code is being built from a git clone (it 
> > sticks 
> > the current SHA-1 into the version displayed in these places, but does NOT
> > screw up the TOCALL).  That won't work if you're building the Debian package
> > out of a tarball (the trick involves looking for a .git directory, and if 
> > found, invoking a git log command to get the current SHA-1).
> > 
> > - Forwarded message from Tom Russo  -
> > 
> > Date: Sun, 23 Feb 2020 10:26:41 -0700
> > From: Tom Russo 
> > To: Xastir - APRS client software discussion 
> > Subject: Re: [Xastir] Fwd: Bug#952116: xastir: Impossible to transmit due to
> > malformed TOCALL
> > 
> > Xastir's versions are goofy.  The history of this is ancient, and there has 
> > been no reason to ungoof it.
> > 
> > Even numbers are releases, odd numbers are working development versions,
> > and are generally not updated for every commit --- Xastir 2.1.5 just means
> > "development branch after stable 2.1.4".
> > 
> > The TOCALL for the current development version of Xastir should be APX215,
> > and there should be no need for finer granularity to show which commit on
> > every transmit.  The ambiguity of "which commit of the dev branch am I 
> > using?"
> > is resolved using the Help->About box.  This can only matter to the user 
> > him/her
> > self, and need not be transmitted in every packet.  A TOCALL of APX215 
> > should
> > be enough for all interested parties on the receive end.
> > 
> > If there is a need for a stable release so that distros can have a stable 
> > version, we should push one out.  There is an open project on github for 
> > our 
> > next release with a number of required fixes before we do it.  There was a 
> > flurry of activity on 

Bug#952395: sddm: Virtual terminal vt1: no prompt, only blinking cursor

[Thomas Florek]

Package: sddm
Version: 0.18.1-1
Severity: normal

In the virtual terminal vt1 there is no command prompt, only a blinking 
cursor.

Launching vt1 via ALT-CTRL-F1 or ALT-[RIGHT,LEFT] ARROW is not possible.

Downgrading the package sddm into version 0.18.0-1+b2 avoids this bug.



-- System Information:
Debian Release: bullseye/sid
  APT prefers buildd-unstable
  APT policy: (500, 'buildd-unstable'), (500, 'unstable'), (500, 
'testing'), (500, 'stable')

Architecture: amd64 (x86_64)

Kernel: Linux 5.5.5-towo.1-siduction-amd64 (SMP w/2 CPU cores; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE= (charmap=UTF-8)

Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages sddm depends on:
ii  adduser 3.118
ii  debconf [debconf-2.0]   1.5.73
ii  libc6   2.29-10
ii  libgcc-s1 [libgcc1] 10-20200222-1
ii  libgcc1 1:10-20200222-1
ii  libpam0g1.3.1-5
ii  libqt5core5a5.12.5+dfsg-8
ii  libqt5dbus5 5.12.5+dfsg-8
ii  libqt5gui5  5.12.5+dfsg-8
ii  libqt5network5  5.12.5+dfsg-8
ii  libqt5qml5  5.12.5-5
ii  libqt5quick55.12.5-5
ii  libstdc++6  10-20200222-1
ii  libsystemd0 244.3-1
ii  libxcb-xkb1 1.13.1-5
ii  libxcb1 1.13.1-5
ii  qml-module-qtquick2 5.12.5-5
ii  x11-common  1:7.7+20
ii  xserver-xorg [xserver]  1:7.7+20

Versions of packages sddm recommends:
ii  haveged   1.9.8-4
ii  libpam-systemd244.3-1
ii  sddm-theme-breeze [sddm-theme]4:5.17.5-4
ii  sddm-theme-patience [sddm-theme]  2018.3.0-1

Versions of packages sddm suggests:
ii  libpam-kwallet5   5.17.5-2
pn  qtvirtualkeyboard-plugin  

-- debconf information:
  sddm/daemon_name: /usr/bin/sddm
* shared/default-x-display-manager: sddm

Bug#951087: Bug#952049: pekka-kana-2: FTBFS: SDL_image.h:100:24: error: missing binary operator before token "("

[Simon McVittie]

On Sun, 23 Feb 2020 at 08:56:19 +0100, Lucas Nussbaum wrote:
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
> 
> > In file included from src/draw.cpp:19:
> > /usr/include/SDL2/SDL_image.h:100:24: error: missing binary operator before 
> > token "("
> >   100 | #if SDL_VERSION_ATLEAST(2,0,0)

Many games make wrong-but-usually-true assumptions about where the SDL2
headers and libraries can be found, and how they relate to each other.
pekka-kana-2 seems to have these assumptions:

- Assumes that $(pkg-config --cflags sdl2) and $(pkg-config --libs sdl2)
  are also going to be enough to find SDL2_mixer headers and -lSDL2_mixer,
  similar to the neverball issue mentioned in
   and addressed in
  


- Assumes that SDL2 and SDL2_foo headers can be #included as ,
  similar to ,
   and 
  (this is not portable, and instead they are meant to be included as
  #include  and #include , which is portable)

- Some weirdness in src/draw.cpp where it includes 
  but doesn't link to -lSDL2_image, which I currently don't fully understand
  (perhaps src/draw.cpp really only needs the base SDL2 library, and not
  SDL2_image?)

Despite not being considered correct, pekka-kana-2's assumptions used to
work before we modified SDL2 to be multiarch co-installable
(). There are two ways to address this
bug:

- Fix pekka-kana-2 to stop making these assumptions, and instead use SDL
  with the recommended patterns:
- PKG_CONFIG ?= pkg-config
  (so that cross-compilation uses the correct cross-pkg-config)
- add $(${PKG_CONFIG} --cflags sdl2) to all C/C++ compiler command-lines
- add $(${PKG_CONFIG} --libs sdl2) to linker command-line
- add $(${PKG_CONFIG} --cflags SDL2_mixer) to all C/C++ compiler
  command-lines
- add $(${PKG_CONFIG} --libs SDL2_mixer) to linker command-line
- include SDL.h (where required) with #include 
- include SDL_mixer.h (where required) with #include 
- if SDL2_image is required, do the same as for SDL2_mixer
- if SDL2_image is not required, use #include  instead

- Change SDL2 so the assumptions are true again
  (for example 
  which also resolves )

I've verified that libsdl2 merge request 3 is sufficient to fix the
FTBFS (compiled successfully but not otherwise tested). However, for
best robustness, I think we would ideally do both.

smcv

Bug#952394: dhcpcd-gtk: Mostly unusable as some icons are missing

[martintxo]

Package: dhcpcd-gtk
Version: 0.6.0-1.1+b1
Severity: normal

Dear Maintainer,

 * What led up to the situation?

I view that the Raspbgerry Pi Desktop is using a solution for the wifi
connection that is simple, lightweight and works well. It is using dhcpcd +
wpasupplicant + a custom lxpanel plugin derived from dhcpcd-gtk. I want to try
this solution in my laptop.

But installed dhcpcd, wpasupplicant and dhcpcd-gtk, and setting up all of them,
I was a problem with the icon in my panel. Dhcpcd-gtk was working OK more or
less, I could select a wifi and put it's passphrase, change to another one,
goes wired. But the icon and the menu in the panel was looking ugly. In the
wifi selection menu there was'nt a "v" icon to show the selected wifi, and
there was'nt to the icon indicating the wifi "strength"...

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

I see that in the upstream web page there is a new version 0.7.7, and in ubuntu
repository there is too a 0.7.5 version. I install the ubuntu one, and the
problem goes away. Now the app looks correct and is working best.

You can see that in the debian package there are only 11 icons for each icon
size:
https://packages.debian.org/sid/amd64/dhcpcd-gtk/filelist
But in ubuntu there are 18:
https://packages.ubuntu.com/focal/amd64/dhcpcd-common/filelist

   * What was the outcome of this action?
   * What outcome did you expect instead?

So, for the package to works OK in Debian, you need to package the last version
of the upstream code. I compile it with the Ubuntu's debian source dir, and
both dhcpcd-gtk and dhcpcd-qt are working OK now.

For compile it with qt5, I pass the variable: export QT_SELECT=qt5, as said
here:
https://forums.gentoo.org/viewtopic-t-1071520-start-0.html

For me, this is the most simple and lightweight solution for setup wifi in a
laptop. I think that this good package need to be in Debian in good shape.
Thanks in advance. Greetings.

PD: I do'nt made the above probes in this computer, so the following settings
and packages are not the correct ones.

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

Kernel: Linux 5.5.0-4.1-liquorix-amd64 (SMP w/2 CPU cores; PREEMPT)
Locale: LANG=eu_ES.UTF-8, LC_CTYPE=eu_ES.UTF-8 (charmap=UTF-8),
LANGUAGE=eu_ES:eu:es_ES:es:en_GB:en (charmap=UTF-8) Shell: /bin/sh linked to
/bin/dash Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages dhcpcd-gtk depends on:
pn  dhcpcd-dbus 
ii  libc6   2.29-10
ii  libdbus-1-3 1.12.16-2
ii  libgdk-pixbuf2.0-0  2.40.0+dfsg-2
ii  libglib2.0-02.62.4-2
ii  libgtk2.0-0 2.24.32-4
ii  libnotify4  0.7.8-1

dhcpcd-gtk recommends no packages.

dhcpcd-gtk suggests no packages.

Bug#952393: libpam-duo: Support offline IP whiteliting

[Dominic Hargreaves]

Package: libpam-duo
Version: 1.9.19-1
Severity: wishlist
Forwarded: https://github.com/duosecurity/duo_unix/pull/61

As per https://github.com/duosecurity/duo_unix/pull/61 I'd like to see
an IP whitelisting feature that doesn't rely on paid features of Duo,
nor being able to contact the Duo authentication servers. 

Ideally I'd like both IPv4 and IPv6 netmask based matching rather than
individual hosts.

Thanks,
Dominic

Bug#952392: libpam-duo: Outdated version

[Dominic Hargreaves]

Package: libpam-duo
Version: 1.9.21-1.1
Severity: normal

Some notable release notes entries beyond the latest in Debian
(omitting things relating to other platforms, or library compatibility):

* Added additional GECOS parsing support.
* Addressed an issue which kept configuration secrets in memory for longer than 
necessary.
* Support for TLS 1.2.
* Minor memory leak fixes.
* Output a message during authentication when a user is locked out.
* FIPS-compliant when run on a system with FIPS enabled system-wide.
* Fixed a bug that caused a segfault on systems where the hostname wasn't 
retrievable.
* Added configuration options for parsing the Duo username out of the GECOS 
field: gecos_username_pos and gecos_delim.
* Fixed bug causing console login to fail on certain systems.
* Updated SELinux policy to allow local logins to use the pam_duo PAM module 
and made sshd configurable. This requires installation of selinux-policy-devel 
on CentOS and RHEL 7 as a prerequisite.
* Added support for spaces in group names when escaped with backslashes in 
pam_duo.conf and login_duo.conf
* Improved validation of BSON messages.

Please could you update this package to the latest release?

Thanks!
Dominic

Bug#952386: src:libseccomp: please add support for riscv64

[Aurelien Jarno]

On 2020-02-23 18:29, John Paul Adrian Glaubitz wrote:
> On 2/23/20 6:17 PM, Aurelien Jarno wrote:
> > libseccomp fails to build on riscv64 as the support for this
> > architecture is missing. It has just been added upstream:
> > 
> > https://github.com/seccomp/libseccomp/commit/5432e15521d5ce5a7d3f26bf78674cbaa9d73d1f
> 
> Hmm, I wonder whether I can do this for m68k and sparc64 as well. But I
> assume this also requires support in the kernel, doesn't it?

Yes, you need first to add the kernel support.

> I think Helge added support for it for hppa?

Yes, hppa supports libseccomp a few years already, and the package
builds fine there.

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Bug#952105: planetblupi: FTBFS: blupi.h:23:10: fatal error: SDL.h: No such file or directory

[Simon McVittie]

Control: tags -1 + patch

On Sun, 23 Feb 2020 at 18:39:25 +, Simon McVittie wrote:
> - Fix planetblupi to stop making this assumption
>   (,
>   or equivalently the attached patch)

Sorry, here's the patch.
>From d00242ce65cb608190a0eb61fe83a6f8d404c21a Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Sun, 23 Feb 2020 18:24:14 +
Subject: [PATCH] Don't assume that SDL2 headers are in /usr/include/SDL2

Closes: #952105
---
 debian/changelog  |  8 
 ...tions-about-location-of-SDL2-headers.patch | 41 +++
 debian/patches/series |  1 +
 3 files changed, 50 insertions(+)
 create mode 100644 debian/patches/Avoid-making-assumptions-about-location-of-SDL2-headers.patch
 create mode 100644 debian/patches/series

diff --git a/debian/changelog b/debian/changelog
index 8d5b7c3..75f011d 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+planetblupi (1.14.2-2) UNRELEASED; urgency=medium
+
+  * d/p/Avoid-making-assumptions-about-location-of-SDL2-headers.patch:
+Don't assume that SDL2 headers are in /usr/include/SDL2
+(Closes: #952105)
+
+ -- Simon McVittie   Sun, 23 Feb 2020 18:23:28 +
+
 planetblupi (1.14.2-1) unstable; urgency=medium
 
   * New 1.14.2 upstream release
diff --git a/debian/patches/Avoid-making-assumptions-about-location-of-SDL2-headers.patch b/debian/patches/Avoid-making-assumptions-about-location-of-SDL2-headers.patch
new file mode 100644
index 000..4737c6d
--- /dev/null
+++ b/debian/patches/Avoid-making-assumptions-about-location-of-SDL2-headers.patch
@@ -0,0 +1,41 @@
+From: Simon McVittie 
+Date: Sun, 23 Feb 2020 18:12:58 +
+Subject: Avoid making assumptions about location of SDL2 headers
+
+It is not an API guarantee that the SDL2 headers will be found in
+${prefix}/include/SDL2, or that SDL2 is installed in the same prefix
+as planetblupi itself. Ask pkg-config instead.
+
+Signed-off-by: Simon McVittie 
+Bug-Debian: https://bugs.debian.org/952105
+Forwarded: no
+---
+ CMakeLists.txt | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+diff --git a/CMakeLists.txt b/CMakeLists.txt
+index 5723efd..f067233 100644
+--- a/CMakeLists.txt
 b/CMakeLists.txt
+@@ -9,7 +9,6 @@ include (${CMAKE_ROOT}/Modules/ExternalProject.cmake)
+ include ("${CMAKE_SOURCE_DIR}/cmake/Ronn2Man.cmake")
+ 
+ include_directories (${CMAKE_INSTALL_PREFIX}/include)
+-include_directories (${CMAKE_INSTALL_PREFIX}/include/SDL2)
+ link_directories (${CMAKE_INSTALL_PREFIX}/lib)
+ 
+ project (planetblupi)
+@@ -153,10 +152,13 @@ include_directories (${SDLKitchensink_INCLUDE_DIRS})
+ find_package (PkgConfig REQUIRED)
+ if (NOT BUILD_JS)
+   pkg_search_module (SDL2 REQUIRED sdl2)
++  include_directories (${SDL2_INCLUDE_DIRS})
+   set (planetblupi_DEPS ${planetblupi_DEPS} ${SDL2_STATIC_LIBRARIES})
+   pkg_search_module (SDL2_IMAGE REQUIRED SDL2_image)
++  include_directories (${SDL2_IMAGE_INCLUDE_DIRS})
+   set (planetblupi_DEPS ${planetblupi_DEPS} ${SDL2_IMAGE_STATIC_LIBRARIES})
+   pkg_search_module (SDL2_MIXER REQUIRED SDL2_mixer)
++  include_directories (${SDL2_MIXER_INCLUDE_DIRS})
+   set (planetblupi_DEPS ${planetblupi_DEPS} ${SDL2_MIXER_STATIC_LIBRARIES})
+ endif ()
+ 
diff --git a/debian/patches/series b/debian/patches/series
new file mode 100644
index 000..322e513
--- /dev/null
+++ b/debian/patches/series
@@ -0,0 +1 @@
+Avoid-making-assumptions-about-location-of-SDL2-headers.patch
-- 
2.25.1

Bug#952391: ITP: ocf-spec-core -- Open Connectivity Foundation core specifications

[David Suarez]

Package: wnpp
Severity: wishlist

* Package name: ocf-spec-core
  Version : 2.1.0
  Upstream Author : Open Connectivity Foundation
* URL : https://openconnectivity.org/
* License : BSD-3-clause
  Description : Open Connectivity Foundation core specifications

Bug#951087: Bug#952105: planetblupi: FTBFS: blupi.h:23:10: fatal error: SDL.h: No such file or directory

[Simon McVittie]

On Sun, 23 Feb 2020 at 08:56:48 +0100, Lucas Nussbaum wrote:
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
> > In file included from /<>/src/action.h:23,
> >  from /<>/src/action.cxx:24:
> > /<>/src/blupi.h:23:10: fatal error: SDL.h: No such file or 
> > directory
> >23 | #include 

Many games make wrong-but-usually-true assumptions about where the SDL2
headers and libraries can be found, but this one is particularly creative:
it assumes that SDL2 is installed in the same ${prefix} as planetblupi,
*and* that the SDL2 headers can be found in ${prefix}/include/SDL2.

Obviously, this is not how things are meant to work: it should be possible
to install SDL with --prefix=/opt/stuff and the games with
--prefix=$HOME/Games (or CMake equivalent) if that's what you want to do.

Despite not being considered correct, planetblupi's assumptions used to
work before we modified SDL2 to be multiarch co-installable
(). There are two ways to address this
bug:

- Fix planetblupi to stop making this assumption
  (,
  or equivalently the attached patch);
- Change SDL2 so the assumption is true again
  (for example 
  which also resolves )

I've verified that either of these is sufficient to fix the FTBFS (compiled
successfully but not otherwise tested). For best robustness, I think we
would ideally do both.

smcv

Bug#952116: [ru...@bogodyn.org: Re: [Xastir] Fwd: Bug#952116: xastir: Impossible to transmit due to malformed TOCALL]

[tony mancill]

Hi Tom,

My apologies for the issues the patch to AC_INIT caused with TOCALL and
thank you for the explanation of versioning semantics.  It was a bad
assumption on my part, carried over from $dayjob, when I didn't see a
release tag for 2.1.5 in the repo.  100% my mistake.

Also, thank you to Iain for the identifying and addressing the bug in
Debian source package, which will now report 2.1.5 in the Help->About
dialog.

Regards,
tony

On Sun, Feb 23, 2020 at 10:45:51AM -0700, Tom Russo wrote:
> This is a forwarded version of an email sent to the Xastir mailing list.
> I am forwarding to you because you followed up to a different message on that 
> list.
> 
> To answer your direct question, "Since we are
> building from a snapshot - i.e., a version somewhere between 2.1.4 and
> 2.1.5, is there a preference for which we use for configure?"
> 
> This is mistaken.  You are in fact using 2.1.5, which means 
> "development version between 2.1.4.  and whatever our next release will be 
> called."  Since this version number is used to construct the TOCALL,  the 
> version number in AC_INIT should just be left at 2.1.5.
> 
> 2.1.5 will never be "released", and the presence of APX215 in the TOCALL
> is supposed to say "this user is using a bleeding-edge version pulled
> from git".  Our next release will get a version number bump.
> 
> The Xastir build system tries to construct a useful Version string to display
> in the Help->About and also to print when Xastir is invoked with "-V", but
> this trick only works if the code is being built from a git clone (it sticks 
> the current SHA-1 into the version displayed in these places, but does NOT
> screw up the TOCALL).  That won't work if you're building the Debian package
> out of a tarball (the trick involves looking for a .git directory, and if 
> found, invoking a git log command to get the current SHA-1).
> 
> - Forwarded message from Tom Russo  -
> 
> Date: Sun, 23 Feb 2020 10:26:41 -0700
> From: Tom Russo 
> To: Xastir - APRS client software discussion 
> Subject: Re: [Xastir] Fwd: Bug#952116: xastir: Impossible to transmit due to
>   malformed TOCALL
> 
> Xastir's versions are goofy.  The history of this is ancient, and there has 
> been no reason to ungoof it.
> 
> Even numbers are releases, odd numbers are working development versions,
> and are generally not updated for every commit --- Xastir 2.1.5 just means
> "development branch after stable 2.1.4".
> 
> The TOCALL for the current development version of Xastir should be APX215,
> and there should be no need for finer granularity to show which commit on
> every transmit.  The ambiguity of "which commit of the dev branch am I using?"
> is resolved using the Help->About box.  This can only matter to the user 
> him/her
> self, and need not be transmitted in every packet.  A TOCALL of APX215 should
> be enough for all interested parties on the receive end.
> 
> If there is a need for a stable release so that distros can have a stable 
> version, we should push one out.  There is an open project on github for our 
> next release with a number of required fixes before we do it.  There was a 
> flurry of activity on some of those issues a while back, but between people
> being injured, having other projects, and what not, nothing's been done for
> quite a while.
> 
> If there is a real need for a stable release, we could probably use a little
> help.  The open issues that we expected to have fixed for the next release
> (nominally dubbed Xastir 2.2.0) can be seen at:
> 
> https://github.com/Xastir/Xastir/projects/2
> 
> Some might need punting.
> 
> On Sun, Feb 23, 2020 at 08:56:54AM -0800, we recorded a bogon-computron 
> collision of the  flavor, containing:
> > 
> > Hello Dave,
> > 
> > The scenario here seems to be if you're running an intermediate release
> > Xastir and not an official tagged release.
> > 
> > Dave, yes, I see you on APRS-IS : https://aprs.fi/info/a/KB3EFS and it shows
> > you're running v2.15 (APX215) per the "Last Path" line:
> > 
> >KB3EFS>*APX215* via TCPIP*,qAC,T2ONTARIO
> > 
> > 
> > The question here is if you're running a version of Xastir that's between
> > v2.15 and v2.16, what should Xastir report as it's version to APRS-IS?  It's
> > not clear if it's illegal but maybe this would be legal:
> > 
> >APX21G
> > 
> > --David
> > KI6ZHD
> > 
> > 
> > 
> > 
> > On 02/23/2020 08:43 AM, David A Aitcheson wrote:
> > > I did & was checking validity before making noise...
> > > 
> > > Given that I  only am able to be on APRS via an Internet connection
> > > (read: no radio use allowed)...
> > > 
> > > Given that I only build from source (read: I don't use a package from a
> > > repository)...
> > > 
> > > I think that it is not effecting me...
> > > 
> > > David KI6ZHD - can you see me ( "KB3EFS" ) on the map in NY State?
> > > 
> > > 73
> > > Dave
> > > KB3EFS
> > 
> > ___
> > Xastir mailing list
> > xas...@lists.xastir.org
> > 

Bug#952116: [ru...@bogodyn.org: Re: [Xastir] Fwd: Bug#952116: xastir: Impossible to transmit due to malformed TOCALL]

[Tom Russo]

The script looks in the top level of the Xastir source tree being built
for the presence of a .git directory.  The fact that the source tree is under
a package directory that is itself in git should have no impact (there will
then be a .git directory at a higher level, and our script will simply 
be unaware of it and return no SHA at all).

Our set up has been designed to work under the normal assumption that package
maintainers aren't using snapshots, and only will use formal releases (an
assumption that has held up for as long as Xastir has existed).  It has
always been assumed that anyone using the development branch is a power
user building it themselves.

On Sun, Feb 23, 2020 at 07:14:59PM +0100, we recorded a bogon-computron 
collision of the  flavor, containing:
> Re: Tom Russo 2020-02-23 <20200223174551.gd5...@bogodyn.org>
> > That won't work if you're building the Debian package
> > out of a tarball (the trick involves looking for a .git directory, and if 
> > found, invoking a git log command to get the current SHA-1).
> 
> Fwiw, these tricks are often a PITA for package maintainers, because
> we keep the packaging also in a git repository, but that one doesn't
> have any (git) connection to the upstream xastir.git.
> 
> In many cases, we have to patch the build system not to do these
> tricks. (Generally, I didn't check if the variant used in xastir is
> problematic.)
> 
> Christoph

-- 
Tom RussoKM5VY
Tijeras, NM  

 echo "prpv_a'rfg_cnf_har_cvcr" | sed -e 's/_/ /g' | tr [a-m][n-z] [n-z][a-m]

Bug#951718: selectively enable seccomp not working as documented

[Marc Haber]

On Thu, Feb 20, 2020 at 05:40:51PM +0100, Marc Haber wrote:
> So, at the moment, seccomp in apt in stable is unuseable with a more
> recent kernel because of this, and should be switched off on my affected
> systems?

No comments here?

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

Bug#951087: Bug#952098: trigger-rally: FTBFS: SDL_image.h:27:10: fatal error: SDL.h: No such file or directory

[Simon McVittie]

On Sun, 23 Feb 2020 at 09:03:33 +0100, Lucas Nussbaum wrote:
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
> 
> > In file included from PEngine/texture.cpp:12:
> > /usr/include/SDL2/SDL_image.h:27:10: fatal error: SDL.h: No such file or 
> > directory
> >27 | #include "SDL.h"

This bug is similar to #952066 and #952046. They're all caused by the
games assuming that they can find , 
etc. in the compiler's default header search path, and also assuming
that they can find -lSDL2, -lSDL2_image etc. in the linker's default
library search path.

These assumptions are not really correct: games are meant to query each
library's CFLAGS and LIBS, add them to the compiler and linker command
lines respectively, and use #include  (and *not* ,
which does not work on all OSs). In a simple Makefile-based build system
like the one in trigger-rally, that looks like this:

PKG_CONFIG ?= pkg-config
SDL2_CFLAGS = $(shell ${PKG_CONFIG} --cflags sdl2)
SDL2_LIBS = $(shell ${PKG_CONFIG} --libs sdl2)
SDL2_IMAGE_CFLAGS = $(shell ${PKG_CONFIG} --cflags SDL2_image)
SDL2_IMAGE_LIBS = $(shell ${PKG_CONFIG} --libs SDL2_image)

...

CPPFLAGS += $(DMACROS) $(INCDIRS) $(SDL2_CFLAGS) $(SDL2_IMAGE_CFLAGS)
EXTRA_LIBS := $(SDL2_LIBS) $(SDL2_IMAGE_LIBS) -lSDL2main -lGL -lGLU -lGLEW 
-lphysfs -lopenal -lalut -lpthread -ltinyxml2

(trigger-rally could probably benefit from the same technique being applied
to non-SDL dependencies like openal and physfs, but that isn't immediately
necessary to solve this bug.)

Despite not really being correct, these assumptions used to
work before we modified SDL2 to be multiarch co-installable
(). The alternative solution to #909740
proposed at 
as a solution to  also breaks these
assumptions, although I think it would be possible to modify it so that
the assumptions hold again.

smcv

Bug#952116: [ru...@bogodyn.org: Re: [Xastir] Fwd: Bug#952116: xastir: Impossible to transmit due to malformed TOCALL]

[Christoph Berg]

Re: Tom Russo 2020-02-23 <20200223174551.gd5...@bogodyn.org>
> That won't work if you're building the Debian package
> out of a tarball (the trick involves looking for a .git directory, and if 
> found, invoking a git log command to get the current SHA-1).

Fwiw, these tricks are often a PITA for package maintainers, because
we keep the packaging also in a git repository, but that one doesn't
have any (git) connection to the upstream xastir.git.

In many cases, we have to patch the build system not to do these
tricks. (Generally, I didn't check if the variant used in xastir is
problematic.)

Christoph

Bug#952390: paraview: 3rd party plugins dir violates directory standards

[Drew Parsons]

Package: paraview
Version: 5.7.0-4+b2
Severity: normal

The paraview Plugins Manager (Tools->Manage Plugins) says it looks for
3rd party plugins in /usr/bin/plugins.

This does work (meshio-tools 4.0.4-1 provides a plugin there), but it
violates standard directory layout and triggers a lintian error
"subdir-in-usr-bin".

Unreleased docs at
https://kitware.github.io/paraview-docs/latest/cxx/PluginHowto.html
report that recognised plugin paths also include 
"A plugins subdirectory under the paraview-X.Y directory in the
library path",
i.e. in /usr/lib/x86_64-linux-gnu/paraview-5.7/plugins/
(so it looks like the /usr/bin/plugins path problem might be fixed in
paraview 3.8)

There are 2 issues installing 3rd party plugins in that directory.

Firstly, a plugin might (perhaps) not be specific to a given paraview
version, in which case it would be unhelpful to have to specify the
5.7.  A tidy generic path could be
/usr/lib/x86_64-linux-gnu/paraview/plugins/
Possibly even just /usr/lib/paraview/plugins/
(similar to how python modules are handled for python3.7 and python3.8)

Secondly, not all plugins are binaries. Python scripts for instance.
For these a useful plugin path could be
/usr/share/paraview/plugins/

I'm not entirely certain if the versionless lib path
/usr/lib/x86_64-linux-gnu/paraview/plugins/ (or
/usr/lib/paraview/plugins/) actually makes sense.
Perhaps compiled binary plugins are necessarily version-specific.

But an arch-independent path /usr/share/paraview/plugins could I think
be helpful, and probably worth pushing upstream.


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

Kernel: Linux 5.4.0-4-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
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 /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages paraview depends on:
ii  libavcodec58   7:4.2.2-1+b1
ii  libavformat58  7:4.2.2-1+b1
ii  libavutil567:4.2.2-1+b1
ii  libc6  2.29-10
ii  libdouble-conversion3  3.1.5-5
ii  libexpat1  2.2.9-1
ii  libfreetype6   2.10.1-2
ii  libgcc-s1 [libgcc1]10-20200211-1
ii  libgcc11:10-20200211-1
ii  libgdal26  3.0.4+dfsg-1
ii  libgl1 1.3.0-7
ii  libglew2.1 2.1.0-4+b1
ii  libhdf5-1031.10.4+repack-10
ii  libjpeg62-turbo1:1.5.2-2+b1
ii  liblz4-1   1.9.2-2
ii  liblzma5   5.2.4-1+b1
ii  libopenmpi34.0.2-5
ii  libpdal-base9  2.0.1+ds-1+b1
ii  libpng16-161.6.37-2
ii  libpython3.7   3.7.6-1+b1
ii  libqt5core5a   5.12.5+dfsg-8
ii  libqt5gui5 5.12.5+dfsg-8
ii  libqt5help55.12.5-2+b1
ii  libqt5network5 5.12.5+dfsg-8
ii  libqt5widgets5 5.12.5+dfsg-8
ii  libqt5x11extras5   5.12.5-1
ii  libstdc++6 10-20200211-1
ii  libswscale57:4.2.2-1+b1
ii  libtiff5   4.1.0+git191117-2
ii  libx11-6   2:1.6.8-1
ii  libxml22.9.10+dfsg-3
ii  libxt6 1:1.1.5-1+b3
ii  python3-autobahn   17.10.1+dfsg1-6
ii  python3-matplotlib 3.1.2-2
ii  python3-mpi4py 3.0.3-4
ii  python3-six1.14.0-2
ii  python3-twisted18.9.0-6
ii  tcl [tclsh]8.6.9+1+b1
ii  zlib1g 1:1.2.11.dfsg-1.2

Versions of packages paraview recommends:
ii  mpi-default-bin  1.13
ii  paraview-doc 5.7.0-4
pn  paraview-python  

Versions of packages paraview suggests:
ii  h5utils 1.13.1-3+b1
ii  hdf5-tools  1.10.4+repack-10

-- no debconf information

Bug#952116: [ru...@bogodyn.org: Re: [Xastir] Fwd: Bug#952116: xastir: Impossible to transmit due to malformed TOCALL]

[Tom Russo]

This is a forwarded version of an email sent to the Xastir mailing list.
I am forwarding to you because you followed up to a different message on that 
list.

To answer your direct question, "Since we are
building from a snapshot - i.e., a version somewhere between 2.1.4 and
2.1.5, is there a preference for which we use for configure?"

This is mistaken.  You are in fact using 2.1.5, which means 
"development version between 2.1.4.  and whatever our next release will be 
called."  Since this version number is used to construct the TOCALL,  the 
version number in AC_INIT should just be left at 2.1.5.

2.1.5 will never be "released", and the presence of APX215 in the TOCALL
is supposed to say "this user is using a bleeding-edge version pulled
from git".  Our next release will get a version number bump.

The Xastir build system tries to construct a useful Version string to display
in the Help->About and also to print when Xastir is invoked with "-V", but
this trick only works if the code is being built from a git clone (it sticks 
the current SHA-1 into the version displayed in these places, but does NOT
screw up the TOCALL).  That won't work if you're building the Debian package
out of a tarball (the trick involves looking for a .git directory, and if 
found, invoking a git log command to get the current SHA-1).

- Forwarded message from Tom Russo  -

Date: Sun, 23 Feb 2020 10:26:41 -0700
From: Tom Russo 
To: Xastir - APRS client software discussion 
Subject: Re: [Xastir] Fwd: Bug#952116: xastir: Impossible to transmit due to
malformed TOCALL

Xastir's versions are goofy.  The history of this is ancient, and there has 
been no reason to ungoof it.

Even numbers are releases, odd numbers are working development versions,
and are generally not updated for every commit --- Xastir 2.1.5 just means
"development branch after stable 2.1.4".

The TOCALL for the current development version of Xastir should be APX215,
and there should be no need for finer granularity to show which commit on
every transmit.  The ambiguity of "which commit of the dev branch am I using?"
is resolved using the Help->About box.  This can only matter to the user him/her
self, and need not be transmitted in every packet.  A TOCALL of APX215 should
be enough for all interested parties on the receive end.

If there is a need for a stable release so that distros can have a stable 
version, we should push one out.  There is an open project on github for our 
next release with a number of required fixes before we do it.  There was a 
flurry of activity on some of those issues a while back, but between people
being injured, having other projects, and what not, nothing's been done for
quite a while.

If there is a real need for a stable release, we could probably use a little
help.  The open issues that we expected to have fixed for the next release
(nominally dubbed Xastir 2.2.0) can be seen at:

https://github.com/Xastir/Xastir/projects/2

Some might need punting.

On Sun, Feb 23, 2020 at 08:56:54AM -0800, we recorded a bogon-computron 
collision of the  flavor, containing:
> 
> Hello Dave,
> 
> The scenario here seems to be if you're running an intermediate release
> Xastir and not an official tagged release.
> 
> Dave, yes, I see you on APRS-IS : https://aprs.fi/info/a/KB3EFS and it shows
> you're running v2.15 (APX215) per the "Last Path" line:
> 
>KB3EFS>*APX215* via TCPIP*,qAC,T2ONTARIO
> 
> 
> The question here is if you're running a version of Xastir that's between
> v2.15 and v2.16, what should Xastir report as it's version to APRS-IS?  It's
> not clear if it's illegal but maybe this would be legal:
> 
>APX21G
> 
> --David
> KI6ZHD
> 
> 
> 
> 
> On 02/23/2020 08:43 AM, David A Aitcheson wrote:
> > I did & was checking validity before making noise...
> > 
> > Given that I  only am able to be on APRS via an Internet connection
> > (read: no radio use allowed)...
> > 
> > Given that I only build from source (read: I don't use a package from a
> > repository)...
> > 
> > I think that it is not effecting me...
> > 
> > David KI6ZHD - can you see me ( "KB3EFS" ) on the map in NY State?
> > 
> > 73
> > Dave
> > KB3EFS
> 
> ___
> Xastir mailing list
> xas...@lists.xastir.org
> http://xastir.org/mailman/listinfo/xastir

-- 
Tom RussoKM5VY
Tijeras, NM  

 echo "prpv_a'rfg_cnf_har_cvcr" | sed -e 's/_/ /g' | tr [a-m][n-z] [n-z][a-m]

___
Xastir mailing list
xas...@lists.xastir.org
http://xastir.org/mailman/listinfo/xastir

- End forwarded message -

-- 
Tom RussoKM5VY
Tijeras, NM  

 echo "prpv_a'rfg_cnf_har_cvcr" | sed -e 's/_/ /g' | tr [a-m][n-z] [n-z][a-m]

Bug#951874: debian-security-support: Miscellaneous sh fixes

[Daniel Shahaf]

Holger Levsen wrote on Sun, 23 Feb 2020 16:21 +:
> On Sun, Feb 23, 2020 at 03:51:58PM +, Daniel Shahaf wrote:
> > Alternatively, how about deleting the «exit 0» line entirely?  That
> > would effectively downgrade the error message to a warning.  
> 
> sounds better to me.

Okay.  I've already filed #952283 (Cc'd) for this.  What else needs to
be done here, then?  I guess someone should audit the remainder of the
script to make sure nothing will break when DEBIAN_VERSION isn't
a recognized value?  That'd be above my paygrade, I'm afraid.  (I don't
know what was assumed to be true due to the DEBIAN_VERSION check having
succeeded.)

Cheers,

Daniel

Bug#952389: RFS: ploop/1.15-8 [QA] -- tools to work with ploop devices and images

[Sudip Mukherjee]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: ploop
   Version : 1.15-8
   Upstream Author : NA
 * URL : https://wiki.openvz.org/Ploop
 * License : GPL-2.0+
 * Vcs : https://salsa.debian.org/debian/ploop
   Section : libs

It builds those binary packages:

  ploop - tools to work with ploop devices and images
  libploop-dev - ploop API development library
  libploop1 - ploop API library

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

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

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

  dget -x https://mentors.debian.net/debian/pool/main/p/ploop/ploop_1.15-8.dsc

Changes since the last upload:

   * QA upload.
   * Update Standards-Version to 4.5.0
   * Add Vcs link to salsa.
   * Fix FTCBFS. (Closes: #905741)
 - Thanks to Helmut Grohne.
   * Add symbols file for libploop1


-- 
Regards
Sudip

Bug#952116: [ru...@bogodyn.org: Re: [Xastir] Fwd: Bug#952116: xastir: Impossible to transmit due to malformed TOCALL]

[Tom Russo]

If there is a desire to build Xastir for debian from a tarball *AND* get the
git sha into the Help->About box and "xastir -V" output, one could patch
the script "scripts/XastirGitStamp.sh" so that it blindly inserts the SHA-1
you know to be relevant instead of asking Git to provide it.  This would be
safe to do in your packaging patches.

XastirGitStamp.sh is run by src/Makefile to construct the "compiledate.c"
file (which no longer contains the compile date, so that Xastir builds can
be reproducible, another request we got a year or so ago).  It takes a directory
as argument, and in its current form looks top see if that directory has
a .git directory.  If so, it runs git log to get the sha.  Simply rip out
that logic and echo a fixed SHA-1 and you should be able to accomplish what
you intended when you modified AC_INIT, but without breaking the TOCALL.


On Sun, Feb 23, 2020 at 10:45:51AM -0700, we recorded a bogon-computron 
collision of the  flavor, containing:
> This is a forwarded version of an email sent to the Xastir mailing list.
> I am forwarding to you because you followed up to a different message on that 
> list.
> 
> To answer your direct question, "Since we are
> building from a snapshot - i.e., a version somewhere between 2.1.4 and
> 2.1.5, is there a preference for which we use for configure?"
> 
> This is mistaken.  You are in fact using 2.1.5, which means 
> "development version between 2.1.4.  and whatever our next release will be 
> called."  Since this version number is used to construct the TOCALL,  the 
> version number in AC_INIT should just be left at 2.1.5.
> 
> 2.1.5 will never be "released", and the presence of APX215 in the TOCALL
> is supposed to say "this user is using a bleeding-edge version pulled
> from git".  Our next release will get a version number bump.
> 
> The Xastir build system tries to construct a useful Version string to display
> in the Help->About and also to print when Xastir is invoked with "-V", but
> this trick only works if the code is being built from a git clone (it sticks 
> the current SHA-1 into the version displayed in these places, but does NOT
> screw up the TOCALL).  That won't work if you're building the Debian package
> out of a tarball (the trick involves looking for a .git directory, and if 
> found, invoking a git log command to get the current SHA-1).
> 
> - Forwarded message from Tom Russo  -
> 
> Date: Sun, 23 Feb 2020 10:26:41 -0700
> From: Tom Russo 
> To: Xastir - APRS client software discussion 
> Subject: Re: [Xastir] Fwd: Bug#952116: xastir: Impossible to transmit due to
>   malformed TOCALL
> 
> Xastir's versions are goofy.  The history of this is ancient, and there has 
> been no reason to ungoof it.
> 
> Even numbers are releases, odd numbers are working development versions,
> and are generally not updated for every commit --- Xastir 2.1.5 just means
> "development branch after stable 2.1.4".
> 
> The TOCALL for the current development version of Xastir should be APX215,
> and there should be no need for finer granularity to show which commit on
> every transmit.  The ambiguity of "which commit of the dev branch am I using?"
> is resolved using the Help->About box.  This can only matter to the user 
> him/her
> self, and need not be transmitted in every packet.  A TOCALL of APX215 should
> be enough for all interested parties on the receive end.
> 
> If there is a need for a stable release so that distros can have a stable 
> version, we should push one out.  There is an open project on github for our 
> next release with a number of required fixes before we do it.  There was a 
> flurry of activity on some of those issues a while back, but between people
> being injured, having other projects, and what not, nothing's been done for
> quite a while.
> 
> If there is a real need for a stable release, we could probably use a little
> help.  The open issues that we expected to have fixed for the next release
> (nominally dubbed Xastir 2.2.0) can be seen at:
> 
> https://github.com/Xastir/Xastir/projects/2
> 
> Some might need punting.
> 
> On Sun, Feb 23, 2020 at 08:56:54AM -0800, we recorded a bogon-computron 
> collision of the  flavor, containing:
> > 
> > Hello Dave,
> > 
> > The scenario here seems to be if you're running an intermediate release
> > Xastir and not an official tagged release.
> > 
> > Dave, yes, I see you on APRS-IS : https://aprs.fi/info/a/KB3EFS and it shows
> > you're running v2.15 (APX215) per the "Last Path" line:
> > 
> >KB3EFS>*APX215* via TCPIP*,qAC,T2ONTARIO
> > 
> > 
> > The question here is if you're running a version of Xastir that's between
> > v2.15 and v2.16, what should Xastir report as it's version to APRS-IS?  It's
> > not clear if it's illegal but maybe this would be legal:
> > 
> >APX21G
> > 
> > --David
> > KI6ZHD
> > 
> > 
> > 
> > 
> > On 02/23/2020 08:43 AM, David A Aitcheson wrote:
> > > I did & was checking validity before making noise...
> > > 
> > > Given that I  

Bug#951087: jag, mrboom: FTBFS: SDL_mixer.h:25:10: fatal error: SDL_stdinc.h: No such file or directory

[Simon McVittie]

On Sun, 23 Feb 2020 at 08:49:11 +0100, Lucas Nussbaum wrote:
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
> > In file included from src/gamesound.h:33,
> >  from src/gametools.cpp:33:
> > /usr/include/SDL2/SDL_mixer.h:25:10: fatal error: SDL_stdinc.h: No such 
> > file or directory
> >25 | #include "SDL_stdinc.h"

These two bugs appear to be very similar. They're caused by jag and
mrboom assuming that they can find , 
etc. in the compiler's default header search path, and also assuming
that they can find -lSDL2, -lSDL2_mixer etc. in the linker's default
library search path.

These assumptions are not really correct: games are meant to query each
library's CFLAGS and LIBS, add them to the compiler and linker command
lines respectively, and use #include  (and *not* ,
which does not work on all OSs). In a simple Makefile-based build system
like the one in mrboom, that looks like this:

PKG_CONFIG ?= pkg-config
SDL2_CFLAGS = $(shell ${PKG_CONFIG} --cflags sdl2 SDL2_mixer)
SDL2_LIBS = $(shell ${PKG_CONFIG} --libs sdl2 SDL2_mixer)

SDL2LIBS = ${SDL2_LIBS} -lminizip -lmodplug
CFLAGS += ${SDL2_CFLAGS}

jag would need to do the equivalent, but however you spell that in QMake
(sorry, I don't know how that works).

Despite not really being correct, these assumptions used to
work before we modified SDL2 to be multiarch co-installable
(). The alternative solution to #909740
proposed at 
as a solution to  also breaks these
assumptions, although I think it would be possible to modify it so that
the assumptions hold again.

smcv

Bug#830624: RFP: xplayer -- GTK media player based on GStreamer for the Xapps project

[Andres Salomon]

FYI, Mint has switched from xplayer to celluloid in Mint 19.3: 

This is the case across all of their desktops (Cinnamon, MATE, and 
Xfce).  Celluloid is already packaged in Debian.


I don't know what this means for the future of xplayer, but I suspect 
it will be abandoned.

Bug#952388: python3-fake-factory: New version of Faker for quite a while

[Vincent-Xavier JUMEL]

Package: python3-fake-factory
Version: 0.7.7-3
Severity: normal

Dear Maintainer,

Could you please upgrade this package to at least 2.0.4 version, since
the documentation refers to it.

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

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

Versions of packages python3-fake-factory depends on:
ii  python3   3.7.5-3
ii  python3-dateutil  2.7.3-3
ii  python3-six   1.14.0-2

python3-fake-factory recommends no packages.

python3-fake-factory suggests no packages.

-- no debconf information

-- 
Vincent-Xavier JUMEL Id: https://keybase.io/vincentxavier 
https://blog.thetys-retz.net

Société Libre, Logiciel Libre http://www.april.org/adherer
Parinux, logiciel libre à Paris : http://www.parinux.org