Bug#958374: pd-tclpd FTCBFS: strips with the build architecture strip

[Helmut Grohne]

Source: pd-tclpd
Version: 0.3.0-3
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

pd-tclpd fails to cross build from source, because it strips with the
build architecture strip during make install. Beyond breaking cross
compilation, doing so also breaks DEB_BUILD_OPTIONS=nostrip as well as
generation of -dbgsym packages. Please consider applying the attached
patch to defer such stripping to dh_strip, which uses the correct strip
program.

Helmut
diff --minimal -Nru pd-tclpd-0.3.0/debian/changelog 
pd-tclpd-0.3.0/debian/changelog
--- pd-tclpd-0.3.0/debian/changelog 2018-07-09 13:07:03.0 +0200
+++ pd-tclpd-0.3.0/debian/changelog 2020-04-21 07:18:27.0 +0200
@@ -1,3 +1,10 @@
+pd-tclpd (0.3.0-3.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Defer stripping to dh_strip. (Closes: #-1)
+
+ -- Helmut Grohne   Tue, 21 Apr 2020 07:18:27 +0200
+
 pd-tclpd (0.3.0-3) unstable; urgency=medium
 
   * Use versioned dependency on puredata
diff --minimal -Nru pd-tclpd-0.3.0/debian/rules pd-tclpd-0.3.0/debian/rules
--- pd-tclpd-0.3.0/debian/rules 2018-07-09 13:07:03.0 +0200
+++ pd-tclpd-0.3.0/debian/rules 2020-04-21 07:18:26.0 +0200
@@ -26,7 +26,7 @@
$(empty)
 
 override_dh_auto_install:
-   dh_auto_install -- prefix=/usr pkglibdir=$(pkglibdir)
+   dh_auto_install -- prefix=/usr pkglibdir=$(pkglibdir) STRIP=true
 # fix permissions
find $(CURDIR)/debian/*/$(pkglibdir) -name "*.pd_linux" -exec \
chmod 0664 {} +

Bug#958373: pd-hexloader FTCBFS: strips with the build architecture strip

[Helmut Grohne]

Source: pd-hexloader
Version: 1.7-2
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

pd-hexloader fails to cross build from source, because it strips with
the build architecture strip during make install. Beyond breaking cross
compilation, doing so also breaks DEB_BUILD_OPTIONS=nostrip as well as
generation of -dbgsym packages. Please consider applying the attached
patch to defer such stripping to dh_strip, which uses the correct strip
program.

Helmut
diff --minimal -Nru pd-hexloader-1.7/debian/changelog 
pd-hexloader-1.7/debian/changelog
--- pd-hexloader-1.7/debian/changelog   2018-02-01 23:08:01.0 +0100
+++ pd-hexloader-1.7/debian/changelog   2020-04-21 06:38:36.0 +0200
@@ -1,3 +1,10 @@
+pd-hexloader (1.7-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Defer stripping to dh_strip. (Closes: #-1)
+
+ -- Helmut Grohne   Tue, 21 Apr 2020 06:38:36 +0200
+
 pd-hexloader (1.7-2) unstable; urgency=medium
 
   * Switched buildsystem from dh to cdbs
diff --minimal -Nru pd-hexloader-1.7/debian/rules pd-hexloader-1.7/debian/rules
--- pd-hexloader-1.7/debian/rules   2018-02-01 23:08:01.0 +0100
+++ pd-hexloader-1.7/debian/rules   2020-04-21 06:38:35.0 +0200
@@ -23,7 +23,7 @@
$(empty)
 
 override_dh_auto_install:
-   dh_auto_install -- prefix=/usr pkglibdir=$(pkglibdir)
+   dh_auto_install -- prefix=/usr pkglibdir=$(pkglibdir) STRIP=true
 # fix permissions
find $(CURDIR)/debian/*/$(pkglibdir) -name "*.pd_linux" -exec \
chmod 0664 {} +

Bug#958250: Use system libjsonparser-dev

[Yangfl]

Jonas Smedegaard  于2020年4月20日周一 下午7:29写道：
>
> Quoting Sebastian Ramacher (2020-04-20 13:20:59)
> > On 2020-04-20 13:07:40 +0200, Jonas Smedegaard wrote:
> > > Quoting Sebastian Ramacher (2020-04-20 12:51:09)
> > > > On 2020-04-20 09:06:51, Yangfl wrote:
> > > > > As libjsonparser-dev is now available, please consider linking
> > > > > against system library instead of bundled json.c.
> > > >
> > > > The last release of libjsonparser was in 2014. In the meantime, vlc's
> > > > copy has seen some fixes (more so in the master branch than the
> > > > current version in Debian). Are there any plans upstream to release a
> > > > new version of libjsonparser? I don't think switching vlc to an older
> > > > libjsonparser makes sense.
> > >
> > > Seems you are asking the wrong place: Upstream developers of
> > > libjsonparser propably don't follow this bugreport.
> > >
> > > Probably helpful to go the other way: Inform libjsonparser upstream (or
> > > at least Debian maintainers ot its package) about fixes existing
> > > downstream in VLC.
> >
> > Yangfl is the package maintainer of libjsonparser in Debian …
>
> Good point.
>
> Still, better to share issues with libjsonparser as a bugreport against
> libjsonparser rather than here.
>
>  - Jonas
>
I reviewed json.c in vlc and it seems an outdated version (1.0.0)
rather than 1.1.0. Some problems (like 'Fix check for
json_relaxed_commas') already fixed in 1.1.0 in another way. Other
fixes 
https://github.com/videolan/vlc/commits/master/modules/misc/webservices/json.c
are all minor but I will pick them into Debian package.

Bug#958371: tuned: with tuned enabled i lose network a few seconds after starting network transfers

[lachlan-00]

Source: tuned
Version: tuned breaks network/lan access under load
Severity: normal

Dear Maintainer,

i've set this box up to just be a copy/backup dump and i'm trying to copy the 
files over.

Every time i start the rsync the server disappears in under 30seconds. At first 
i thought it was a kernel panic or something weird but i plugged a monitor in 
and found out that it was just losing network completely.

I was just using ifupdown from /etc/network/interfaces but i've put network 
manager with the same result.

i found that disabling tuned fixes this problem immediately and i have not lost 
lan after disabling the daemon


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

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

Bug#958370: golang-github-dgrijalva-jwt-go-v3: Remove this package from archive

[Shengjing Zhu]

Source: golang-github-dgrijalva-jwt-go-v3
Severity: normal
Control: affects -1 go-cve-dictionary golang-github-go-kit-kit 
golang-github-azure-go-autorest golang-github-labstack-echo.v3 etcd 
goval-dictionary influxdb vuls golang-github-labstack-echo.v2

src:golang-github-dgrijalva-jwt-go/3.2.0-1 has been uploaded to archive
for a long time. It's time to retire this
golang-github-dgrijalva-jwt-go-v3 package.

The following packages have direct build-depends on
golang-github-dgrijalva-jwt-go-v3-dev:

# build-rdeps --old golang-github-dgrijalva-jwt-go-v3-dev
go-cve-dictionary
golang-github-go-kit-kit
golang-github-azure-go-autorest
golang-github-labstack-echo.v3
etcd
goval-dictionary
influxdb
vuls
golang-github-labstack-echo.v2

Following packages may have patch to use github.com/dgrijalva/jwt-go-v3
import path.

# https://codesearch.debian.net/search?q=jwt-go-v3=1=1
influxdb
golang-github-go-kit-kit
go-cve-dictionary
kubernetes
docker.io
golang-github-dgrijalva-jwt-go
vuls
goval-dictionary
gitlab-workhorse
golang-github-labstack-echo.v3
golang-github-labstack-echo.v2
golang-github-dgrijalva-jwt-go-v3
golang-github-azure-go-autorest
etcd

I plan to team upload above packages in next few days.

Thanks

Bug#955603: Please don't remove these drivers

[Scott Kitterman]

On April 21, 2020 1:09:47 AM UTC, Vlad  wrote:
>Please keep these drivers. They work as just fine, and many people
>still use them. They have not been dropped by upstream X.org, and there
>is no reason to drop them from Debian. Without these drivers, it will
>make running Debian desktop on this hardware impossible. One of the
>things that makes Debian great is the backward compatibility. It's very
>sad to see destructive actions like this being taken. Please don't just
>throw away all the work that people have put into these drivers over
>the years, and please don't orphan their users!

The removal was already done over 2 weeks ago.  At this point an interested 
party would have to package them and get them back in.

Scott K

Bug#958369: ltrace: reports wrong syscalls on x86_64

[Hazel Victoria Campbell]

Package: ltrace
Version: 0.7.3-6.1
Severity: important

Dear Maintainer,

ltrace reports wrong systemcalls on x86_64.

ltrace output:
% time seconds  usecs/call calls  function
-- --- --- - 
 73.18   77.943882 448173958 SYS_getegid32
 13.12   13.978116 448 31181 SYS_madvise1

correct output:
% time seconds  usecs/call calls  function
-- --- --- - 
 73.56   46.381433 413112122 futex
 13.138.279804 411 20120 restart_syscall

If you build the version from master @ 
https://gitlab.com/cespedes/ltrace/-/tree/ea8928dab8a0a1f549d0ed8ebc6ec563e9fa1159
(this is currently the latest commit)
and apply the pull request @
https://gitlab.com/cespedes/ltrace/-/merge_requests/1
(diff @ https://gitlab.com/cespedes/ltrace/-/merge_requests/1.diff

Then, it produces the expected output.

-- System Information:
Debian Release: 10.3
  APT prefers stable
  APT policy: (995, 'stable'), (994, 'stable-updates'), (950, 'testing'), (40, 
'unstable'), (30, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.4.0-0.bpo.2-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.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 ltrace depends on:
ii  libc62.30-4
ii  libelf1  0.176-1.1
ii  libselinux1  2.8-1+b1

ltrace recommends no packages.

ltrace suggests no packages.

-- no debconf information

Bug#661485: smartmontools: smartd-runner fails to send email to more than one recipient

[David Osolkowski]

This bug appears to still be present in version 6.6-1, the current in
buster. Additionally, Jawaad's proposed patch (no longer?) appears to
work, as it provides the multiple recipients space-delimited, where
mail wants them to be comma-delimited, at least for me. In
smartd-runner, I changed:

recipients="${@}"

to:

IFS=","
recipients="$*"

which appears to work, but I won't claim this is perfect. Maybe the
10mail script could be changed instead? Happy to help develop or test
an acceptable solution and get this bug closed after eight years.

Bug#958139: ITP: vim-gitgutter -- A Vim plugin which shows a git diff in the sign column

[James McCoy]

On Sat, Apr 18, 2020 at 10:24:28PM +0200, Raphael Medaer wrote:
> This Vim plugin shows a git diff in the 'gutter' (sign column). It shows
> which lines have been added, modified, or removed. You can also preview,
> stage, and undo individual hunks; and stage partial hunks. The plugin also
> provides a hunk text object.
> 
> FYI There is a (less popular) alternative: vim-signify
> 
> I would enjoy to maintain this package. Maybe in PkgVim team ?

Sure, I can add you to vim-team.

> I'm not looking for co-maintainer, but a mentor/sponsor for sure.
> I already created the Debian package.

I can try to answer questions, although there may be delays.  I have
limited time for Debian.

On Sun, Apr 19, 2020 at 01:22:53PM +0200, Raphael Medaer wrote:
> I pushed a first version of the package here: 
> https://salsa.debian.org/rmedaer/vim-gitgutter

>From a (very quick) initial look, I would highly suggest dropping the
use of vim-addon-manager and using dh-vim-addon instead.

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#952353: swiftsc: FTBFS: dh: error: unable to load addon python3: Can't locate Debian/Debhelper/Sequence/python3.pm in @INC (you may need to install the Debian::Debhelper::Sequence::python3 module)

[Logan Rosen]

Package: swiftsc
Version: 0.5-1.1
Followup-For: Bug #952353
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 dh-python to fix FTBFS due to missing python3.pm.

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-25-generic (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru swiftsc-0.5/debian/control swiftsc-0.5/debian/control
--- swiftsc-0.5/debian/control  2019-10-29 09:31:26.0 -0400
+++ swiftsc-0.5/debian/control  2020-04-20 22:04:15.0 -0400
@@ -2,7 +2,7 @@
 Section: python
 Priority: optional
 Maintainer: Kouhei Maeda 
-Build-Depends: debhelper (>= 8.0.0), pep8, python3-all, python3-setuptools, 
python3-requests, python3-magic, python3-pytest, python3-mock
+Build-Depends: debhelper (>= 8.0.0), dh-python, pep8, python3-all, 
python3-setuptools, python3-requests, python3-magic, python3-pytest, 
python3-mock
 Standards-Version: 3.9.4
 X-Python-Version: >= 2.6, >= 3.2
 Homepage: https://github.com/mkouhei/swiftsc

Bug#946695: foma: segfault on mis-use of "_"

[Kevin Ryde]

Oh, actually a commit from a fortnight ago might be relevant.  I'm not
well setup to try at this moment, but if so and all else good then can
go to fixed-upstream in the fullness of time.

https://github.com/mhulden/foma/commit/e20a453a318128973d75753f9ecbef0e6b82b23f

Bug#946695: foma: segfault on mis-use of "_"

[Kevin Ryde]

forwarded 946695 https://github.com/mhulden/foma/issues/77
thanks

Also looks a bit similar to https://github.com/mhulden/foma/issues/3

Bug#958367: RFP: scantailor-advanced -- interactive post-processing tool for scanned pages

[Rogério Brito]

Package: wnpp
Severity: wishlist

* Package name: scantailor-advanced
  Version : 1.0.14
  Upstream Author : Alexander Pozdnyakov 
* URL : https://github.com/4lex4/scantailor-advanced
* License : GPL-3+
  Programming Lang: C++
  Description : interactive post-processing tool for scanned pages

 Scan Tailor Advanced is an interactive post-processing tool for scanned
 pages.
 .
 It performs operations such as page splitting, deskewing, adding/
 removing borders, and others. You give it raw scans, and you get pages
 ready to be printed or assembled into a PDF or DJVU file.
 .
 Scanning, optical character recognition, and assembling multi-page
 documents are out of scope of this project.



Since the original ScanTailor package was never ported from Qt4, it was
removed from Debian and is not in our repositories anymore. This fork is
fully featured (so many additional features that I can't even start
listing), uses Qt5 and is actively maintained upstream.

I included some people that has worked (or work) on
scanning/document-related software in similar packages. Sorry if none of you
are interested. Just disregard this message, if that's the case.

I can help co-maintain this package, since I use an unofficial version of
it, but my C++ is a bit rusty (and I have never programmed with Qt before).
The basic packaging work is, of course, not really a huge problem, though.


Thanks,

Rogério Brito.

-- 
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC
http://cynic.cc/blog/ : github.com/rbrito : profiles.google.com/rbrito
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br

Bug#958368: Hard IO Hangs

[Rumen Telbizov]

Package: linux-image-4.19.0-8-amd64
Version: 4.19.98-1

Hello everyone,

We have recently migrated our fleet over to Debian 10.3 which runs kernel
4.19.98.
Since then we started noticing sporadic hard IO hangs. Any process
involving IO
would freeze in 'D' state. Processes that don't do IO would continue
functioning
normally.

After reboot there is absolutely nothing left in the logs.
To capture more of this we setup netconsole logging remotely and configured:

kernel.hung_task_panic=1
kernel.hung_task_timeout_secs=20

So far this issue has occurred across different hardware models as well
as EC2 virtual instances.

I attach here an example kernel trace after a recent panic and I hope that
someone might point us to the right direction if this issue has already been
fixes or maybe suggest a patch.

Thank you in advance,
-- 
Rumen Telbizov
Unix Systems Administrator 


iohang.log
Description: Binary data

Bug#958366: ITP: python3-cleo -- Create beautiful and testable command-line interfaces.

[Emmanuel Arias]

Package: wnpp
Severity: wishlist
Owner: Emmanuel Arias 

* Package name: python3-cleo
  Version : 0.8.1
  Upstream Author : Sébastien Eustace 
* URL : https://github.com/sdispater/cleo
* License : MIT
  Programming Lang: Python
  Description : Cleo allows you to create beautiful and testable 
command-line interfaces.
 
Create beautiful and testable command-line interfaces.
.
Cleo is mostly a higher level wrapper for CliKit, so a lot of the components and
utilities comes from it. Refer to its documentation for more information.
.
This package is need by poetry. This package can be under DPMT
umbrella.

Bug#958304: Can not make Epson L1800 work

[王钢林]

OK, it works. Thank you very much! :)

Best regards,

Gulfstream


在 2020/4/21 上午2:26, Didier 'OdyX' Raboud 写道:

Le lundi, 20 avril 2020, 18.59:31 h CEST wg...@china.com a écrit :

Hello, the epson-inkjet-printer-201312w need LSB which is abandoned by
Debian. So it is not be used in Debian 10. Would you please tell me how to
use the epson-inkjet-printer-201312w in Debian without LSB?

You need to talk to Epson :-) LSB is gone from Debian 10 for good reasons, and
they need to adapt.

The easiest way is most probably to install lsb-compat from stretch:

http://deb.debian.org/debian/pool/main/l/lsb/lsb-compat_9.20161125_amd64.deb

Regards,
 OdyX

Bug#847996: edid-decode: wrongly interprets 13-byte strings as non-conforming

[Валерий Заподовников]

https://bugs.freedesktop.org/show_bug.cgi?id=93777
Fxied in
https://git.linuxtv.org/edid-decode.git/commit/?id=9cb3744ac4f06ec7c66a3599a2caa2b94aa7a1d8
Please close. Also look into the other issue that is also fixed in
upstream, please update.

Bug#931297: Please support /usr/lib64/sane

[Gunnar Hjalmarsson]

I can't find that this bug is fixed, so I reopened it.

--
Gunnar Hjalmarsson
https://launchpad.net/~gunnarhj

Bug#944369: edid-decode crashes with division-by-zero for incorrect EDID

[Валерий Заподовников]

Actually the first part AND second parts of edid are correct, just use
latest edid-decode, all mistakes are gone.
Please update, maintainer... To latest commit!!!


For example this
https://git.linuxtv.org/edid-decode.git/commit/?id=cbd464b98411e93e83a144059bbeef64fadfe539
fixed
Made in: week 1 of 2002

edid-decode (hex):

00 ff ff ff ff ff ff 00 00 00 00 00 00 00 00 00
01 0c 01 03 80 50 2d 78 0a 0d c9 a0 57 47 98 27
12 48 4c 20 00 00 01 01 01 01 01 01 01 01 01 01
01 01 01 01 01 01 02 3a 80 18 71 38 2d 40 58 2c
45 00 dc 0b 11 00 00 1e 8c 0a d0 8a 20 e0 2d 10
10 3e 96 00 58 c2 21 00 00 18 00 00 00 7c 00 4d
59 20 48 44 54 56 0a 20 20 20 20 20 00 00 00 00
00 00 00 0a 2e 06 00 0a 20 20 20 20 20 20 01 75

02 03 1e 40 83 7f 40 05 40 48 10 05 04 01 02 06
15 11 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 20 20 20 20 20 20
20 20 20 20 20 20 00 00 00 ff 00 0a 20 20 20 20
20 20 20 20 20 20 20 20 00 00 00 1b 00 0a 20 20
20 20 20 20 20 20 20 20 20 20 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d8



Block 0, Base EDID:
  EDID Structure Version & Revision: 1.3
  Vendor & Product Identification:
Manufacturer: @@@
Model: 0
Made in: week 1 of 2002
  Basic Display Parameters & Features:
Digital display
Maximum image size: 80 cm x 45 cm
Gamma: 2.20
RGB color display
First detailed timing is preferred timing
  Color Characteristics:
Red  : 0.6250, 0.3398
Green: 0.2802, 0.5947
Blue : 0.1552, 0.0703
White: 0.2832, 0.2978
  Established Timings I & II:
DMT 0x04:   640x48059.940 Hz   4:331.469 kHz  25.175 MHz
  Standard Timings: none
  Detailed Timing Descriptors:
DTD 1:  1920x1080   60.000 Hz  16:967.500 kHz 148.500 MHz (476 mm x
267 mm)
 Hfront   88 Hsync  44 Hback 148 Hpol P
 Vfront4 Vsync   5 Vback  36 Vpol P
DTD 2:   720x48059.940 Hz   3:231.469 kHz  27.000 MHz (600 mm x
450 mm)
 Hfront   16 Hsync  62 Hback  60 Hpol N
 Vfront9 Vsync   6 Vback  30 Vpol N
Unknown Display Descriptor (0x7c): 00 7c 00 4d 59 20 48 44 54 56 0a 20
20 20 20 20 '.|.MY HDTV. '
Manufacturer-Specified Display Descriptor (0x00): 00 00 00 00 00 0a 2e
06 00 0a 20 20 20 20 20 20 '..  '
  Extension blocks: 1
Checksum: 0x75



Block 1, CTA-861 Extension Block:
  Revision: 3
  Basic audio support
  Native detailed modes: 0
  Speaker Allocation Data Block:
FL/FR - Front Left/Right
LFE1 - Low Frequency Effects 1
FC - Front Center
BL/BR - Back Left/Right
BC - Back Center
FLc/FRc - Front Left/Right of Center
RLC/RRC - Rear Left/Right of Center (Deprecated)
SiL/SiR - Side Left/Right
TpBL/TpBR - Top Back Left/Right
BtFL/BtFR - Bottom Front Left/Right
  Video Data Block:
  Video Data Block:
VIC  16:  1920x1080   60.000 Hz  16:967.500 kHz 148.500 MHz
VIC   5:  1920x1080i  60.000 Hz  16:933.750 kHz  74.250 MHz
VIC   4:  1280x72060.000 Hz  16:945.000 kHz  74.250 MHz
VIC   1:   640x48059.940 Hz   4:331.469 kHz  25.175 MHz
VIC   2:   720x48059.940 Hz   4:331.469 kHz  27.000 MHz
VIC   6:  1440x480i   59.940 Hz   4:315.734 kHz  27.000 MHz
VIC  21:  1440x576i   50.000 Hz   4:315.625 kHz  27.000 MHz
VIC  17:   720x57650.000 Hz   4:331.250 kHz  27.000 MHz
  Unknown CTA tag 0x00, length 0
  Unknown CTA tag 0x00, length 0
  Unknown CTA tag 0x00, length 0
  Unknown CTA tag 0x00, length 0
  Unknown CTA tag 0x00, length 0
  Unknown CTA tag 0x00, length 0
  Unknown CTA tag 0x00, length 0
  Unknown CTA tag 0x00, length 0
  Unknown CTA tag 0x00, length 0
  Unknown CTA tag 0x00, length 0
  Unknown CTA tag 0x00, length 0
  Unknown CTA tag 0x00, length 0
Checksum: 0xd8

Bug#957316: gtkatlantic: ftbfs with GCC-10

[Markus Koschany]

Hi,

Am 20.04.20 um 22:33 schrieb Sylvain Rochet:
> Hello,
> 
> On Fri, Apr 17, 2020 at 01:24:08PM +0200, Sylvain Rochet wrote:
>>
>> I am going to fix that upstream in a couple of days.
> 
> As promised, I just released GtkAtlantic 0.6.3 with build fix for 
> gcc-10, and while I was at it, to Debian/kFreeBSD.
> 
> Thank for the notification, automatic FTBFS notices on newer compilers 
> releases is quite a great feature pushing all the ecosystem forward to 
> perfection.
> 
> Sylvain

Thank you for preparing a new upstream release of gtkatlantic to fix
this issue! I have uploaded 0.6.3 to Debian unstable and the new version
should be available on all mirrors within 24 hours.

Cheers,

Markus



signature.asc
Description: OpenPGP digital signature

Bug#958365: prometheus-bird-exporter: none

[Ben Fiedler]

Package: prometheus-bird-exporter
Version: 1.2.2-1+b20
Severity: important

Dear Maintainer,

prometheus-bird-exporter currently depends on bird, which is however a problem
when using bird2, bird2 does not provide bird as a dependency (it explicitly
conflicts with bird actually).

Adding bird2 as acceptable dependency should fix this problem.

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

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

Versions of packages prometheus-bird-exporter depends on:
pn  bird   
ii  libc6  2.28-10

prometheus-bird-exporter recommends no packages.

prometheus-bird-exporter suggests no packages.

-- Configuration Files:
/etc/default/prometheus-bird-exporter changed:
ARGS="-web.listen-address 127.0.0.1:9324 -format.new -proto.ospf=False"

Bug#949617: modemmanager: please create a stable backport

[Martin]

On 2020-01-22 21:24, Martin wrote:
> If you don't have the time to do the backport or similar, I
> would do that backport myself, if there are no objections.

I assume, that there are no objections.

Bug#958127: Please don't have a hard Depends on binfmt-support

[Josh Triplett]

On Mon, Apr 20, 2020 at 11:17:54PM +0200, Sylvestre Ledru wrote:
> 
> Le 20/04/2020 à 22:32, Josh Triplett a écrit :
> > On Sat, Apr 18, 2020 at 09:32:19PM +0200, Sylvestre Ledru wrote:
> > > Hello,
> > > 
> > > Le 18/04/2020 à 20:56, Josh Triplett a écrit :
> > > > Package: llvm-11-runtime
> > > > Version: 1:11~++20200123111717+04fd2041561-1~exp1
> > > > Severity: normal
> > > > 
> > > > (This bug applies to all of the versioned llvm-runtime packages.)
> > > > 
> > > > Please consider dropping the hard Depends on binfmt-support, and
> > > > changing it to a Suggests. Having an interpreter installed for LLVM IR
> > > > does not necessarily imply wanting to automatically execute LLVM IR
> > > > using binfmt-support, and in fact seems like a relatively uncommon use
> > > > case compared to the primary usage of llvm-runtime. llvm-runtime gets
> > > > pulled in by any installation of llvm.
> > > To make sure I understand, it is "just" to remove one dependency?
> > > 
> > > (which is, afaik, quite small)
> > I'm not primarily concerned with the size of the dependency, but rather,
> > with the associated code that gets run as a result of installing it. I
> > don't want that enabled automatically just because I installed an LLVM
> > toolchain.
> 
> ok, I will fix that in the next upload!

Thank you!

- Josh Triplett

Bug#958364: Subject: RFS: libtpms/0.8.0~dev1-1 [ITP] -- TPM emulation library

[Seunghun Han]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

 * Package name: libtpms
   Version : 0.8.0~dev1-1
   Upstream Author : Stefan Berger 
 * URL : https://github.com/stefanberger/libtpms
 * License : BSD-3-clause
 * Vcs : https://salsa.debian.org/kkamagui-guest/libtpms
   Section : libs

It builds those binary packages:

  libtpms0 - TPM emulation library
  libtpms-dev - libtpms header files and man pages

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/libt/libtpms/libtpms_0.8.0~dev1-1.dsc

Changes since the last upload:

   * New maintainer (Closes: #958071)
   * Updated standards version to 4.5.0 in debian/control
   * Updated debhelper version to 12 in debian/control
   * Added Rules-Requires-Root to debian/control
   * Added Vcs-Browser and Vcs-Git to debian/control
   * Removed autotools-dev and dh-autoreconf from debian/control
   * Removed autotools-dev and parallel option from debian/rules
   * Converted debian/copyright to dep5-copyright format
   * Added debian/watch file
   * Added debian/libtpms.symbols file
   * Added debian/upstream/metadata file
   * Changed section of man pages from 1 to 3
   * Fixed typos and a long line warning in man pages
   * Set date of man pages to last changelog entry

Regards,

--
  Seunghun Han

Bug#936128: Bug #936128: apr: Python2 removal in sid/bullseye

[Andres Salomon]

tags 936128 + fixed-upstream
thanks


FYI, Python 3 incompatibilities are fixed upstream in the apr 1.7.0 
release:


https://svn.apache.org/viewvc/apr/apr/tags/1.7.0/build/gen-build.py?view=log

https://svn.apache.org/viewvc/apr/apr/tags/1.7.0/build/gen-build.py?r1=1795930=1834495_format=h

https://svn.apache.org/viewvc/apr/apr/tags/1.7.0/build/gen-build.py?r1=1834495=1846807_format=h

Bug#956255: pulseeffects: Version 4.7.2+ needs libboost 1.72+

[Jérémy Lal]

Package: src:pulseeffects
Followup-For: Bug #956255

Hi, as discussed in the issue you refer to,
one can revert the commit that introduces the incompatibility.

Done in pulseeffects repository (on master, i meant to MR but pushed too fast).

Jérémy

Bug#958362: pdfrw: fails with python 3.7+ -- abandoned upstream

[Johannes 'josch' Schauer]

Source: pdfrw
Version: 0.4-2
Severity: grave
Justification: renders package unusable

Hi,

the package fails with Python 3.7 and newer. Starting from Python 3.7,
StopIteration is a RuntimeError (see PEP 479). But pdfrw still uses
StopIteration:

https://github.com/pmaupin/pdfrw/issues/145
https://github.com/pmaupin/pdfrw/issues/199

This package recently got its python2 package removed but since tests
are disabled, nobody noticed that its tests fail with Python 3.7+:

https://github.com/pmaupin/pdfrw/issues/198
https://github.com/pmaupin/pdfrw/issues/197

Other upstream bugs indicating that the package is broken on Python3:

https://github.com/pmaupin/pdfrw/issues/193
https://github.com/pmaupin/pdfrw/issues/170

Upstream didn't close bugs for two years and the last commit was more
than two years ago. Upstream admits not having time at the moment here:

https://github.com/pmaupin/pdfrw/issues/195

And is looking for additional maintainers here:

https://github.com/pmaupin/pdfrw/issues/191

In this state, pdfrw should not be included in the next Debian stable
release.

Thanks!

cheers, josch



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

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

Bug#958363: texlive-latex-extra: Missing dependency on siunits.sty from invoice, invoice2, and other packages (see body for full list)

[Simon Ruggier]

Package: texlive-latex-extra
Version: 2018.20190227-2
Severity: normal

Dear Maintainer,

I upgraded to Buster recently, and noticed that the invoice.sty package no
longer works, with the following error:

(/usr/share/texlive/texmf-dist/tex/latex/invoice/invoice.sty
...

! LaTeX Error: File `siunitx.sty' not found.

A bit more investigation lead me to the following list of packages:
$ grep -rl --color 'Require.*\' /usr/share/texlive/ | xargs -n1 dpkg
-S
texlive-pictures: /usr/share/texlive/texmf-
dist/tex/latex/circuitikz/circuitikz.sty
texlive-latex-extra: /usr/share/texlive/texmf-
dist/tex/latex/invoice2/invoice2.sty
texlive-latex-extra: /usr/share/texlive/texmf-
dist/tex/latex/bankstatement/bankstatement.cls
texlive-latex-extra: /usr/share/texlive/texmf-
dist/tex/latex/invoice/invoice.sty
texlive-latex-extra: /usr/share/texlive/texmf-
dist/tex/latex/denisbdoc/denisbdoc.sty
texlive-latex-extra: /usr/share/texlive/texmf-
dist/tex/latex/gridslides/gridslides.sty
texlive-pictures: /usr/share/texlive/texmf-dist/tex/latex/tikz-palattice/tikz-
palattice.sty
texlive-latex-extra: /usr/share/texlive/texmf-
dist/tex/latex/currency/currency.sty
texlive-latex-extra: /usr/share/texlive/texmf-
dist/tex/latex/nomencl/nomencl.sty
texlive-latex-extra: /usr/share/texlive/texmf-
dist/tex/latex/typoaid/typoaid.sty
texlive-latex-extra: /usr/share/texlive/texmf-
dist/tex/latex/smartunits/smartunits.sty

I'm not sure what changed, but I assume the siunits package was moved to
texlive-science without updating the dependencies of texlive-latex-extra and
texlive-pictures. I can confirm that installing texlive-science was a
successful workaround for me.

Thanks,
Simon



-- Package-specific info:
IMPORTANT INFORMATION: We will only consider bug reports concerning
the packaging of TeX Live as relevant. If you have problems with
combination of packages in a LaTeX document, please consult your
local TeX User Group, the comp.text.tex user group, the author of
the original .sty file, or any other help resource. 

In particular, bugs that are related to up-upstream, i.e., neither
Debian nor TeX Live (upstream), but the original package authors,
will be closed immediately.

   *** The Debian TeX Team is *not* a LaTeX Help Desk ***

If you report an error when running one of the TeX-related binaries 
(latex, pdftex, metafont,...), or if the bug is related to bad or wrong
output, please include a MINIMAL example input file that produces the
error in your report.

Please run your example with
(pdf)latex -recorder ...
(or any other program that supports -recorder) and send us the generated
file with the extension .fls, it lists all the files loaded during
the run and can easily explain problems induced by outdated files in
your home directory.

Don't forget to also include minimal examples of other files that are 
needed, e.g. bibtex databases. Often it also helps
to include the logfile. Please, never send included pictures!

If your example file isn't short or produces more than one page of
output (except when multiple pages are needed to show the problem),
you can probably minimize it further. Instructions on how to do that
can be found at

http://www.minimalbeispiel.de/mini-en.html (english)

or 

http://www.minimalbeispiel.de/mini.html (german)

##
minimal input file


##
other files

##
 List of ls-R files

-rw-r--r-- 1 root root 1224 Apr  6 10:17 /var/lib/texmf/ls-R
lrwxrwxrwx 1 root root 29 Feb 28  2019 /usr/share/texmf/ls-R -> 
/var/lib/texmf/ls-R-TEXMFMAIN
lrwxrwxrwx 1 root root 31 Mar  1  2019 /usr/share/texlive/texmf-dist/ls-R -> 
/var/lib/texmf/ls-R-TEXLIVEDIST
lrwxrwxrwx 1 root root 31 Mar  1  2019 /usr/share/texlive/texmf-dist/ls-R -> 
/var/lib/texmf/ls-R-TEXLIVEDIST
##
 Config files
-rw-r--r-- 1 root root 475 Apr  5 18:44 /etc/texmf/web2c/texmf.cnf
lrwxrwxrwx 1 root root 33 Mar  1  2019 /usr/share/texmf/web2c/fmtutil.cnf -> 
/var/lib/texmf/fmtutil.cnf-DEBIAN
lrwxrwxrwx 1 root root 32 Mar  1  2019 /usr/share/texmf/web2c/updmap.cfg -> 
/var/lib/texmf/updmap.cfg-DEBIAN
-rw-r--r-- 1 root root 2763 Apr  6 10:17 
/var/lib/texmf/tex/generic/config/language.dat
##
 Files in /etc/texmf/web2c/
total 8
-rw-r--r-- 1 root root 283 Oct 20  2014 mktex.cnf
-rw-r--r-- 1 root root 475 Apr  5 18:44 texmf.cnf
##
 md5sums of texmf.d
ca40c66f144b4bafc3e59a2dd32ecb9c  /etc/texmf/texmf.d/00debian.cnf

-- System Information:
Debian Release: 10.2
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable'), (103, 'testing'), (102, 
'unstable'), (100, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-8-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), 

Bug#954427: mirror submission for debian.itsbrasil.net

[João Lima]

Hello Julien,

We have changed our configuration and successfully redone our
synchronization!

Thanks for your support!




Em seg., 20 de abr. de 2020 às 18:02, Julien Cristau 
escreveu:

> On Mon, Apr 20, 2020 at 15:53:36 -0300, João Lima wrote:
>
> > Hi Julien,
> >
> > Thanks for your response!
> > About Mirror origin:
> > Could you indicate some rsync servers for us to use here in Brazil?
> >
> You can use debian.c3sl.ufpr.br (generally the same as
> ftp.br.debian.org).
>
> > About DNS:
> > We use Cloudflare cloud as DNS. This Anycast network allows DNS
> resolution
> > at the network edge in each of cloudflare data centers across 200+
> cities,
> > resulting in unparalleled redundancy and 100% uptime.
> >
> Sounds good, thanks (our check is naive so doesn't know that).
>
> Cheers,
> Julien
>

Bug#958127: Please don't have a hard Depends on binfmt-support

[Sylvestre Ledru]

Le 20/04/2020 à 22:32, Josh Triplett a écrit :

On Sat, Apr 18, 2020 at 09:32:19PM +0200, Sylvestre Ledru wrote:

Hello,

Le 18/04/2020 à 20:56, Josh Triplett a écrit :

Package: llvm-11-runtime
Version: 1:11~++20200123111717+04fd2041561-1~exp1
Severity: normal

(This bug applies to all of the versioned llvm-runtime packages.)

Please consider dropping the hard Depends on binfmt-support, and
changing it to a Suggests. Having an interpreter installed for LLVM IR
does not necessarily imply wanting to automatically execute LLVM IR
using binfmt-support, and in fact seems like a relatively uncommon use
case compared to the primary usage of llvm-runtime. llvm-runtime gets
pulled in by any installation of llvm.

To make sure I understand, it is "just" to remove one dependency?

(which is, afaik, quite small)

I'm not primarily concerned with the size of the dependency, but rather,
with the associated code that gets run as a result of installing it. I
don't want that enabled automatically just because I installed an LLVM
toolchain.


ok, I will fix that in the next upload!

Cheers

S

Bug#949129: vcs-git outdated

[Martin]

Package: src:modemmanager
Followup-For: Bug #949129

Hi Mathieu, would you mind moving the modemmanager (and libmbim
and libqmi) git repositories to somewhere else than
https://salsa.debian.org/cyphermox-guest? Either a new team, or
an existing team, e.g. the "debian" team (but I'm not sure, if
you would have access to it).

If you don't have the time or energy at the moment to do it, I
can help out. I need modemmanager for a downstream project and
for that a better state in Debian would very helpful for me.
Which means, I can burn some time on it ;-)

Btw. I would also DEP-14ise the git branches, i.e.
master -> debian/master
upstream -> upstream/latest

Bug#954427: mirror submission for debian.itsbrasil.net

[Julien Cristau]

On Mon, Apr 20, 2020 at 15:53:36 -0300, João Lima wrote:

> Hi Julien,
> 
> Thanks for your response!
> About Mirror origin:
> Could you indicate some rsync servers for us to use here in Brazil?
> 
You can use debian.c3sl.ufpr.br (generally the same as
ftp.br.debian.org).

> About DNS:
> We use Cloudflare cloud as DNS. This Anycast network allows DNS resolution
> at the network edge in each of cloudflare data centers across 200+ cities,
> resulting in unparalleled redundancy and 100% uptime.
> 
Sounds good, thanks (our check is naive so doesn't know that).

Cheers,
Julien

Bug#958361: RFS: libonig/6.9.5-1 -- regular expressions library

[Jörg Frings-Fürst]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: libonig
   Version : 6.9.5-1
   Upstream Author :  (K.Kosako)
 * URL : https://github.com/kkos/oniguruma
 * License : BSD-2-clause
 * Vcs : None
   Section : libs

It builds those binary packages:

 libonig5- regular expressions library
 libonig-dev - regular expressions library — development files

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/libo/libonig/libonig_6.9.5-1.dsc

or from 

 git 
https://jff.email/cgit/libonig.git/?h=release%2Fdebian%2F6.9.5-1

Changes since the last upload:

   * New upstream release.
 - Refresh symbols file.
   * Declare compliance with Debian Policy 4.5.0 (No changes needed).
   * debian/copyright:
 - Add year 2020.
   * Remove unused patches:
 - debian/patches/0105-CVE-2019-13224.patch,
 - debian/patches/0110-CVE-2019-13225.patch.


CU
Jörg Frings-Fürst

-- 
New:
GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D
GPG key (long) : 09F89F3C8CA1D25D
GPG Key: 8CA1D25D
CAcert Key S/N : 0E:D4:56

Old pgp Key: BE581B6E (revoked since 2014-12-31).

Jörg Frings-Fürst
D-54470 Lieser


git:  https://jff.email/cgit/

Threema:  SYR8SJXB
Wire: @joergfringsfuerst
Skype:joergpenguin
Ring: jff
Telegram: @joergfringsfuerst


My wish list: 
 - Please send me a picture from the nature at your home.



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

Bug#945961: xz-utils: FTBFS: cannot stat 'debian/tmp/usr/lib/x86_64-linux-gnu/liblzma.so.*'

[Tiago Daitx]

On Thu, 9 Apr 2020 16:35:13 +0200 Sebastian Andrzej Siewior
 wrote:
> I suggested already something in [0]. Back then we were hoping for some
> feedback from the debhelper team.
> Now I was just asking if Jonathan is handling this and/or if we could
> also bump to current upstream version while at it.
>
> [0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=945961#10

As Dimitri pointed out we have also been affected by this but in
Ubuntu - we found it out recently when doing archive rebuilds on
Focal. The proposed fix in #10 does workaround the issue and it is not
necessary to change the build-arch rules as Dimitri suggested.

I do wonder if this is in fact a regression in debhelper. I tracked it
down to debhelper 12.4 to 12.5 and while I haven't been able to
pinpoint exactly what particular change there is causing it I believe
it is in how double colon rules are being interpreted. It seems the
debhelper changes somehow fail to detect the build-arch rules.

Unless someone knows enough perl to dig into debhelper changes between
12.4 and 12.5 and check if that is in fact a regression, I would
suggest to simply apply the proposed change in comment #10.

Thanks for your help =)

Tiago Daitx

Bug#955603: RM: xserver-xorg-input-aiptek -- ROM; unmaintained, obsolete, or both

[John Paul Adrian Glaubitz]

Hello!

> xserver-xorg-video-ast
> xserver-xorg-video-geode
> xserver-xorg-video-mach64
> xserver-xorg-video-neomagic
> xserver-xorg-video-r128
> xserver-xorg-video-savage
> xserver-xorg-video-siliconmotion
> xserver-xorg-video-sisusb
> xserver-xorg-video-tdfx
> xserver-xorg-video-trident

The r128 driver is actually required for older Apple hardware and
there was just a user reporting a missing video driver on his
iMac.

Would there be any problems if I maintained the driver myself if
necessary?

Adrian

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

Bug#956925: dpkg: dpkg-source: should fail before-build if patches can't be applied fully in v3-quilt

[Jiri Palecek]

Hi,

On 19. 04. 20 23:30, Guillem Jover wrote:

Control: ressign -1 libdpkg-perl
Control: merge 950142 -1

On Thu, 2020-04-16 at 21:31:21 +0200, Jiri Palecek wrote:

Package: dpkg
Version: 1.20.0+nmu2~1.gbpcd9614
Severity: normal
Tags: patch
while building some of my packages, I noticed they were built without
patches applied. Further investigation in the code showed that it was
caused by dpkg-source --before-build carrying on silently if the first
patch could't be applied, eg. when the series was partially applied, or
the patch itself was somehow defective. It seems this behaviour was a
legacy from package format 2 and IMHO is totally unneeded with quilt. I
therefore suggest to apply this patch, which I've used for several
months now without problems. It relegates the issue of deciding when to
apply patches to quilt.

Unfortunately that's not possible, as people expect to be able to
build packages w/o having used quilt to apply them, for example when
they store a source with patches applied in a VCS.


Without a .pc directory, I see. But then it could be special cased based
on the existence of the .pc directory - if it doesn't exist, try the
first patch, if it does, use quilt metadata, right?


Regards

    Jiri Palecek

Bug#958127: Please don't have a hard Depends on binfmt-support

[Josh Triplett]

On Sat, Apr 18, 2020 at 09:32:19PM +0200, Sylvestre Ledru wrote:
> Hello,
> 
> Le 18/04/2020 à 20:56, Josh Triplett a écrit :
> > Package: llvm-11-runtime
> > Version: 1:11~++20200123111717+04fd2041561-1~exp1
> > Severity: normal
> > 
> > (This bug applies to all of the versioned llvm-runtime packages.)
> > 
> > Please consider dropping the hard Depends on binfmt-support, and
> > changing it to a Suggests. Having an interpreter installed for LLVM IR
> > does not necessarily imply wanting to automatically execute LLVM IR
> > using binfmt-support, and in fact seems like a relatively uncommon use
> > case compared to the primary usage of llvm-runtime. llvm-runtime gets
> > pulled in by any installation of llvm.
> 
> To make sure I understand, it is "just" to remove one dependency?
> 
> (which is, afaik, quite small)

I'm not primarily concerned with the size of the dependency, but rather,
with the associated code that gets run as a result of installing it. I
don't want that enabled automatically just because I installed an LLVM
toolchain.

Bug#958359: RM: pytracer -- RoQA; Depends on Python 2, dead upstream, unmaintained

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove pytracer. It depends on Python 2, is dead upstream (last commit 
from 2013), there
are no reverse deps and the last maintainer upload was in 2010.

Cheers,
Moritz

Bug#958358: RM: moosic -- RoQA; Depends on Python 2, dead upstream, unmaintained

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove moosic. It depends on Python 2, is dead upstream (last release in 
2011)
and the last upload was in 2011.

Cheers,
Moritz

Bug#958360: RM: pylirc -- RoQA; Depends on Python, unmaintained

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove pylirc. It depends on Python 2, there are no reverse deps and
the last maintainer upload was in 2011.

Cheers,
Moritz

Bug#958318: src:python-setuptools: Incomplete debian/copyright

[Scott Kitterman]

Actually I was slightly wrong about the changes due to the upcoming policy 
change.  A copy of the license will still be needed in debian/copyright for

pkg_resources/_vendor/pyparsing.py:
setuptools/_vendor/pyparsing.py:
pkg_resources/_vendor/six.py:
setuptools/_vendor/six.py:

It's only the missing copyright attributions that wouldn't be a problem under 
the upcoming change.

Scott K

Bug#925754: Fixed in newer release of libopenshot / libopenshot-audio

[FeRD]

On Wed, 29 Jan 2020 10:08:55 +0100 Matthias Klose  wrote:
> libopenshot-audio 0.1.8 still fails to build

Quite right, sorry. libopenshot-audio-0.1.8 fixed building with GCC *less
than* 9,
but GCC9 coming along broke it again.

On Fedora / RPM Fusion we were building with commit 7001b68[1],
which was at the time an unreleased commit on the development branch.

However, since then both 0.1.9 and 0.2.0 have been released,
including fixes to build with GCC 9 and 10 respectively, IIRC.
(I know 0.2.0 builds with GCC 10 for sure, since I've done it myself.)

Current releases:

libopenshot-audio-0.2.0:
https://github.com/OpenShot/libopenshot-audio/archive/v0.2.0.tar.gz

libopenshot-0.2.5:
https://github.com/OpenShot/libopenshot/archive/v0.2.5.tar.gz

OpenShot 2.5.1 (openshot-qt):
https://github.com/OpenShot/openshot-qt/archive/v2.5.1.tar.gz


[1]:
https://github.com/OpenShot/libopenshot-audio/commit/7001b68787c0881a44bcafba98cccae509a31644

Bug#958355: libreswan FTCBFS: multiple issues

[Helmut Grohne]

Source: libreswan
Version: 3.29-2
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

libreswan fails to cross build from source, because it does not pass
cross tools to make. Using dh_auto_build mostly fixes that except that
the upstream makefiles hard code the build architecture pkg-config. The
attached patch addresses both issues and makes libreswan cross
buildable. Please consider applying it.

Helmut
diff --minimal -Nru libreswan-3.29/debian/changelog 
libreswan-3.29/debian/changelog
--- libreswan-3.29/debian/changelog 2019-08-20 00:57:33.0 +0200
+++ libreswan-3.29/debian/changelog 2020-04-20 19:55:15.0 +0200
@@ -1,3 +1,12 @@
+libreswan (3.29-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: (Closes: #-1)
++ Let dh_auto_build pass cross tools to make. (Closes: #-1)
++ cross.patch: Make pkg-config substitutable.
+
+ -- Helmut Grohne   Mon, 20 Apr 2020 19:55:15 +0200
+
 libreswan (3.29-2) unstable; urgency=medium
 
   * Release to unstable
diff --minimal -Nru libreswan-3.29/debian/patches/cross.patch 
libreswan-3.29/debian/patches/cross.patch
--- libreswan-3.29/debian/patches/cross.patch   1970-01-01 01:00:00.0 
+0100
+++ libreswan-3.29/debian/patches/cross.patch   2020-04-20 19:55:15.0 
+0200
@@ -0,0 +1,20 @@
+--- libreswan-3.29.orig/mk/config.mk
 libreswan-3.29/mk/config.mk
+@@ -231,7 +231,7 @@
+ # XXX: Don't add NSSFLAGS to USERLAND_CFLAGS for now.  It needs to go
+ # after -I$(top_srcdir)/include and fixing that is an entirely
+ # separate cleanup.
+-NSSFLAGS?=$(shell pkg-config --cflags nss)
++NSSFLAGS?=$(shell $(PKG_CONFIG) --cflags nss)
+ # We don't want to link against every library pkg-config --libs nss
+ # returns
+ NSS_LDFLAGS ?= -lnss3 -lnssutil3
+@@ -288,6 +288,8 @@
+ 
+ MAKE?=make
+ 
++PKG_CONFIG?=pkg-config
++
+ # Enable AddressSanitizer - see 
https://libreswan.org/wiki/Compiling_with_AddressSanitizer
+ # requires clang or gcc >= 4.8 and libasan. Do not combine with Electric 
Fence and do not
+ # run pluto with --leak-detective
diff --minimal -Nru libreswan-3.29/debian/patches/series 
libreswan-3.29/debian/patches/series
--- libreswan-3.29/debian/patches/series2019-08-20 00:57:33.0 
+0200
+++ libreswan-3.29/debian/patches/series2020-04-20 19:55:15.0 
+0200
@@ -3,3 +3,4 @@
 0003-update-README.nss-to-match-debian-defaults-for-IPSEC.patch
 0004-move-to-python3-scripts-are-compatible.patch
 0005-minor-Fix-spelling-and-grammar.patch
+cross.patch
diff --minimal -Nru libreswan-3.29/debian/rules libreswan-3.29/debian/rules
--- libreswan-3.29/debian/rules 2019-08-20 00:57:33.0 +0200
+++ libreswan-3.29/debian/rules 2020-04-20 19:55:13.0 +0200
@@ -22,7 +22,7 @@
 CV25519_AVAILABILITY=$(shell if grep -q SEC_OID_CURVE25519 
/usr/include/nss/secoidt.h; then echo true; else echo false; fi)
 
 override_dh_auto_build:
-   $(MAKE) programs \
+   dh_auto_build -- programs \
ARCH=$(DEB_HOST_ARCH) \
IPSECVERSION=$(DEB_VERSION_UPSTREAM) \
INC_USRLOCAL=/usr \

Bug#958357: espeakedit FTCBFS: does not pass cross tools to make

[Helmut Grohne]

Source: espeakedit
Version: 1.48.03-7
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

espeakedit fails to cross build from source, because it does not pass
cross tools to make. The easiest way of fixing that - using
dh_auto_build - makes espeakedit cross buildable. Please consider
applying the attached patch.

Helmut
diff --minimal -Nru espeakedit-1.48.03/debian/changelog 
espeakedit-1.48.03/debian/changelog
--- espeakedit-1.48.03/debian/changelog 2019-12-14 17:48:18.0 +0100
+++ espeakedit-1.48.03/debian/changelog 2020-04-20 21:36:57.0 +0200
@@ -1,3 +1,10 @@
+espeakedit (1.48.03-7.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Let dh_auto_build pass cross tools to make. (Closes: #-1)
+
+ -- Helmut Grohne   Mon, 20 Apr 2020 21:36:57 +0200
+
 espeakedit (1.48.03-7) unstable; urgency=medium
 
   [ Samuel Thibault ]
diff --minimal -Nru espeakedit-1.48.03/debian/rules 
espeakedit-1.48.03/debian/rules
--- espeakedit-1.48.03/debian/rules 2015-12-22 22:11:06.0 +0100
+++ espeakedit-1.48.03/debian/rules 2020-04-20 21:36:55.0 +0200
@@ -5,7 +5,7 @@
 
 override_dh_auto_build:
cp -f src/portaudio19.h src/portaudio.h
-   $(MAKE) -C src
+   dh_auto_build --sourcedirectory=src
 
 override_dh_installdocs:
dh_installdocs

Bug#958354: pd-syslog FTCBFS: strips with the build architecture strip

[Helmut Grohne]

Source: pd-syslog
Version: 0.1-2
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

pd-syslog fails to cross build from source, because it strips during
make install with the build architecture strip. Beyond breaking cross
compilation, doing so breaks DEB_BUILD_OPTIONS=nostrip as well as
generation of -dbgsym packages. Please consider applying the attached
patch to defer all stripping to dh_strip and thus fixing all mentioned
issues.

Helmut
diff --minimal -Nru pd-syslog-0.1/debian/changelog 
pd-syslog-0.1/debian/changelog
--- pd-syslog-0.1/debian/changelog  2018-02-01 23:40:04.0 +0100
+++ pd-syslog-0.1/debian/changelog  2020-04-20 22:14:04.0 +0200
@@ -1,3 +1,10 @@
+pd-syslog (0.1-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Defer stripping to dh_strip. (Closes: #-1)
+
+ -- Helmut Grohne   Mon, 20 Apr 2020 22:14:04 +0200
+
 pd-syslog (0.1-2) unstable; urgency=medium
 
   * Switched buildsystem from dh to cdbs
diff --minimal -Nru pd-syslog-0.1/debian/rules pd-syslog-0.1/debian/rules
--- pd-syslog-0.1/debian/rules  2018-02-01 23:40:04.0 +0100
+++ pd-syslog-0.1/debian/rules  2020-04-20 22:14:03.0 +0200
@@ -23,7 +23,7 @@
$(empty)
 
 override_dh_auto_install:
-   dh_auto_install -- prefix=/usr pkglibdir=$(pkglibdir)
+   dh_auto_install -- prefix=/usr pkglibdir=$(pkglibdir) STRIP=true
 # fix permissions
find $(CURDIR)/debian/*/$(pkglibdir) -name "*.pd_linux" -exec \
chmod 0664 {} +

Bug#958356: gkrellm-reminder FTCBFS: multiple issues

[Helmut Grohne]

Source: gkrellm-reminder
Version: 2.0.0-3
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

gkrellm-reminder fails to cross build from source, because it does not
pass cross tools to make. The easiest way of fixing that - using
dh_auto_build - does not suffice here, because the upstream Makefile
hard codes the build architecture pkg-config. It needs to be made
substitutable. Beyond that debian/rules uses install with the -s flag,
which uses the build architecture strip. Beyond breaking cross
compilation, doing so also breaks DEB_BUILD_OPTIONS=nostrip (#437032)
and generation of -dbgsym packages. The attached patch fixes all of that
including #437032. Please consider applying it.

Helmut
diff -u gkrellm-reminder-2.0.0/debian/control 
gkrellm-reminder-2.0.0/debian/control
--- gkrellm-reminder-2.0.0/debian/control
+++ gkrellm-reminder-2.0.0/debian/control
@@ -3,7 +3,7 @@
 Priority: optional
 Maintainer: Joerg Jaspert 
 Uploaders: Ricardo Mones 
-Build-Depends: debhelper (>> 5), libgtk2.0-dev, gkrellm
+Build-Depends: debhelper (>= 7), libgtk2.0-dev, gkrellm
 Standards-Version: 3.8.2
 
 Package: gkrellm-reminder
diff -u gkrellm-reminder-2.0.0/debian/changelog 
gkrellm-reminder-2.0.0/debian/changelog
--- gkrellm-reminder-2.0.0/debian/changelog
+++ gkrellm-reminder-2.0.0/debian/changelog
@@ -1,3 +1,13 @@
+gkrellm-reminder (2.0.0-3.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: (Closes: #-1)
++ Let dh_auto_build pass cross tools to make.
++ Make pkg-config substitutable.
++ Defer stripping to dh_strip.
+
+ -- Helmut Grohne   Mon, 20 Apr 2020 21:11:28 +0200
+
 gkrellm-reminder (2.0.0-3) unstable; urgency=low
 
   [ Luk Claes ]
diff -u gkrellm-reminder-2.0.0/debian/rules gkrellm-reminder-2.0.0/debian/rules
--- gkrellm-reminder-2.0.0/debian/rules
+++ gkrellm-reminder-2.0.0/debian/rules
@@ -2,7 +2,7 @@
 
 build: 
dh_testdir
-   $(MAKE)
+   dh_auto_build
 
 clean:
dh_testdir
@@ -16,7 +16,7 @@
dh_clean -k
dh_installdirs
install -d debian/gkrellm-reminder/usr/lib/gkrellm2/plugins
-   install -c -s -m 755 reminder.so \
+   install -c -m 755 reminder.so \
debian/gkrellm-reminder/usr/lib/gkrellm2/plugins
 
 
only in patch2:
unchanged:
--- gkrellm-reminder-2.0.0.orig/Makefile
+++ gkrellm-reminder-2.0.0/Makefile
@@ -1,5 +1,6 @@
-GTK_INCLUDE = `pkg-config gtk+-2.0 --cflags`
-GTK_LIB = `pkg-config gtk+-2.0 --libs`
+PKG_CONFIG ?= pkg-config
+GTK_INCLUDE = `$(PKG_CONFIG) gtk+-2.0 --cflags`
+GTK_LIB = `$(PKG_CONFIG) gtk+-2.0 --libs`
 
 CFLAGS = -O2 -Wall -fPIC $(GTK_INCLUDE) -I/usr/pkg/include
 

Bug#958352: xfig: autopkgtest needs update for new version of debhelper: hidden problem

[Paul Gevers]

Source: xfig
Version: 1:3.2.7b-2
Severity: serious
X-Debbugs-CC: debian...@lists.debian.org, debhel...@packages.debian.org
Tags: sid bullseye
User: debian...@lists.debian.org
Usertags: needs-update
Control: affects -1 src:debhelper

Dear maintainer(s),

With a recent upload of debhelper the autopkgtest of xfig fails in
testing when that autopkgtest is run with the binary packages of
debhelper from unstable. It passes when run with only packages from
testing. In tabular form:

   passfail
debhelper  from testing13
xfig   from testing1:3.2.7b-2
all others from testingfrom testing

I copied some of the output at the bottom of this report. I don't spot
anything in there, you may want to avoid redirecting to /dev/null during
testing.

Currently this regression is blocking the migration of debhelper to
testing [1]. Of course, debhelper shouldn't just break your autopkgtest
(or even worse, your package), but it seems to me that the change in
debhelper was intended and your package needs to update to the new
situation.

If this is a real problem in your package (and not only in your
autopkgtest), the right binary package(s) from debhelper should really
add a versioned Breaks on the unfixed version of (one of your)
package(s). Note: the Breaks is nice even if the issue is only in the
autopkgtest as it helps the migration software to figure out the right
versions to combine in the tests.

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

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

https://ci.debian.net/data/autopkgtest/testing/amd64/x/xfig/5068355/log.gz

autopkgtest [01:32:00]: test xfig-testsuite: [---
Running autoconf
Running dh_auto_configure
Building required test programs
Running testsuite
/bin/bash './testsuite' AUTOTEST_PATH='/usr/bin'
## --- ##
## xfig 3.2.7b test suite. ##
## --- ##

Rudimentary tests

  1: Report version  ok
  2: Validate desktop file   ok

Integration tests

  3: ignore too many comment lines, ticket #47   ok

Unit tests

  4: Allow coordinates equal to INT_MIN  FAILED
(testsuite.at:82)
  5: Test round_coords() FAILED
(testsuite.at:87)

## - ##
## Test results. ##
## - ##

ERROR: All 5 tests were run,
2 failed unexpectedly.
## -- ##
## testsuite.log was created. ##
## -- ##

Please send `tests/testsuite.log' and all information you think might help:

   To: 
   Subject: [xfig 3.2.7b] testsuite: 4 5 failed

You may investigate any problem if you feel able to do so, in which
case the test suite provides a good starting point.  Its output may
be found below `tests/testsuite.dir'.

make: *** [Makefile:618: installcheck-local] Error 1
autopkgtest [01:32:05]: test xfig-testsuite: ---]
autopkgtest [01:32:05]: test xfig-testsuite:  - - - - - - - - - -
results - - - - - - - - - -
xfig-testsuite   FAIL stderr: ERROR: All 5 tests were run,



signature.asc
Description: OpenPGP digital signature

Bug#958353: sleepd: fails to correctly read acpi subsystem version

[George Robbert]

Package: sleepd
Version: 2.10
Severity: normal
Tags: patch

Dear Maintainer,

When running with a newer kernel (4.19.0-8-amd64 from buster, though
this also occurs with 5.4.0-0.bpo.4-amd64 from backports), and without
upower installed, sleepd fails to start, complaining

ACPI subsystem 2018081 too is old, consider upgrading to 20011018.

It appears that with these kernels, /sys/module/acpi/parameters/acpica_version
no longer ends with a newline character.  This file actually contains
"20180810".  Note that the final '0' character is discarded.

It seems that acpi.c:get_acpi_file() is erroneously truncating the
last byte when reading acpi files.  This was never exposed earlier, as
the truncated byte was a newline, not part of the version number.

The following patch seems to fix the problem.


--- acpi.c.dist 2018-09-16 03:13:08.0 -0600
+++ acpi.c  2020-04-18 08:13:44.946652962 -0600
@@ -67,7 +67,8 @@
fd = open(file, O_RDONLY);
if (fd == -1) return NULL;
end = read(fd, buf, sizeof(buf));
-   buf[end-1] = '\0';
+   buf[end] = '\0';
close(fd);
return buf;
 }




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

Kernel: Linux 5.4.0-0.bpo.4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=ANSI_X3.4-1968) 
(ignored: LC_ALL set to C), LANGUAGE=en_US.UTF-8 (charmap=ANSI_X3.4-1968) 
(ignored: LC_ALL set to C)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages sleepd depends on:
ii  libc62.28-10
ii  libglib2.0-0 2.58.3-2+deb10u2
ii  libupower-glib3  0.99.10-1
ii  lsb-base 10.2019051400

Versions of packages sleepd recommends:
ii  pm-utils  1.4.1-18
pn  upower

sleepd suggests no packages.

-- Configuration Files:
/etc/default/sleepd changed:
PARAMS="-b 2 -s '/etc/acpi/sleep_suspend.sh sleep'"


-- no debconf information

Bug#958351: plasma-mediacenter: autopkgtest needs update for new version of debhelper: failure on warning

[Paul Gevers]

Source: plasma-mediacenter
Version: 5.7.5-1
Severity: serious
X-Debbugs-CC: debian...@lists.debian.org, debhel...@packages.debian.org
Tags: sid bullseye
User: debian...@lists.debian.org
Usertags: needs-update
Control: affects -1 src:debhelper

Dear maintainer(s),

With a recent upload of debhelper the autopkgtest of plasma-mediacenter
fails in testing when that autopkgtest is run with the binary packages
of debhelper from unstable. It passes when run with only packages from
testing. In tabular form:

   passfail
debhelper  from testing13
plasma-mediacenter from testing5.7.5-1
all others from testingfrom testing

I copied some of the output at the bottom of this report. You can
prevent failure on output to stderr by add the "allow-stderr"
restriction if you don't want such failures.

Currently this regression is blocking the migration of debhelper to
testing [1]. Of course, debhelper shouldn't just break your autopkgtest
(or even worse, your package), but it seems to me that the change in
debhelper was intended and your package needs to update to the new
situation.

If this is a real problem in your package (and not only in your
autopkgtest), the right binary package(s) from debhelper should really
add a versioned Breaks on the unfixed version of (one of your)
package(s). Note: the Breaks is nice even if the issue is only in the
autopkgtest as it helps the migration software to figure out the right
versions to combine in the tests.

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

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

https://ci.debian.net/data/autopkgtest/testing/amd64/p/plasma-mediacenter/5068495/log.gz

autopkgtest [01:39:03]: test testsuite: [---
dh_auto_test: warning: Compatibility levels before 10 are deprecated
(level 9 in use)
cd obj-x86_64-linux-gnu && make -j1 test ARGS\+=-j1
Running tests...
/usr/bin/ctest --force-new-ctest-process -j1
Test project
/tmp/autopkgtest-lxc.yfcatxg0/downtmp/build.Oe3/src/obj-x86_64-linux-gnu
Start 1: pmctest-medialibrarytest
1/9 Test #1: pmctest-medialibrarytest .   Passed   36.02 sec
Start 2: pmctest-singletonfactorytest
2/9 Test #2: pmctest-singletonfactorytest .   Passed0.02 sec
Start 3: pmctest-pmcmediatest
3/9 Test #3: pmctest-pmcmediatest .   Passed0.02 sec
Start 4: pmctest-mediatest
4/9 Test #4: pmctest-mediatest    Passed0.02 sec
Start 5: pmctest-mediacentertest
5/9 Test #5: pmctest-mediacentertest ..   Passed0.00 sec
Start 6: pmctest-itemcachetest
6/9 Test #6: pmctest-itemcachetest    Passed0.02 sec
Start 7: pmctest-pmcalbumtest
7/9 Test #7: pmctest-pmcalbumtest .   Passed0.02 sec
Start 8: pmctest-pmcartisttest
8/9 Test #8: pmctest-pmcartisttest    Passed0.02 sec
Start 9: pmctest-runtimedatatest
9/9 Test #9: pmctest-runtimedatatest ..   Passed0.02 sec

100% tests passed, 0 tests failed out of 9

Total Test time (real) =  36.16 sec
autopkgtest [01:39:39]: test testsuite: ---]
autopkgtest [01:39:40]: test testsuite:  - - - - - - - - - - results - -
- - - - - - - -
testsuiteFAIL stderr: dh_auto_test: warning: Compatibility
levels before 10 are deprecated (level 9 in use)
autopkgtest [01:39:40]: test testsuite:  - - - - - - - - - - stderr - -
- - - - - - - -
dh_auto_test: warning: Compatibility levels before 10 are deprecated
(level 9 in use)



signature.asc
Description: OpenPGP digital signature

Bug#958350: devscripts: autopkgtest needs update for new version of debhelper

[Paul Gevers]

Source: devscripts
Version: 2.20.2
Severity: serious
X-Debbugs-CC: debian...@lists.debian.org, debhel...@packages.debian.org
Tags: sid bullseye
User: debian...@lists.debian.org
Usertags: needs-update
Control: affects -1 src:debhelper

Dear maintainer(s),

With a recent upload of debhelper the autopkgtest of devscripts fails in
testing when that autopkgtest is run with the binary packages of
debhelper from unstable. It passes when run with only packages from
testing. In tabular form:

   passfail
debhelper  from testing13
devscripts from testing2.20.2
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration of debhelper to
testing [1]. Of course, debhelper shouldn't just break your autopkgtest
(or even worse, your package), but it seems to me that the change in
debhelper was intended and your package needs to update to the new
situation.

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

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

https://ci.debian.net/data/autopkgtest/testing/amd64/d/devscripts/5068354/log.gz

./test_package_lifecycle --installed
gpg: writing to '/tmp/gpg.H7gNz/secring.gpg'
gpg: armor header: Version: GnuPG v1
gpg: writing to '/tmp/gpg.H7gNz/pubring.gpg'
gpg: armor header: Version: GnuPG v1
gpg: using pgp trust model
/tmp/gpg.H7gNz/pubring.gpg
--
pub   rsa4096 2015-09-02 [SC]
  CF218F0E7EABF584B7E20402C77E2D6872543FAF
uid   [ unknown] uscan test key (no secret) 
sub   rsa4096 2015-09-02 [E]

test_debuild
ASSERT:standard output of debuild --no-conf --no-lintian
--preserve-envvar=PATH --preserve-envvar=PERL5LIB
--preserve-envvar=DEBFULLNAME --preserve-envvar=DEBEMAIL
--preserve-envvar=GNUPGHOME --set-envvar=NO_PKG_MANGLE=1 -k'uscan test
key (no secret) ' matches
/tmp/autopkgtest-lxc.8rtfp1uo/downtmp/build.7Up/src/test/package_lifecycle/debuild.txt\n
expected:<0> but was:<1>
10,11d9
< dh: warning: Compatibility levels before 10 are deprecated (level 9 in
use)
< dh_clean: warning: Compatibility levels before 10 are deprecated
(level 9 in use)
19d16
< dh: warning: Compatibility levels before 10 are deprecated (level 9 in
use)
22,27d18
< dh: warning: Compatibility levels before 10 are deprecated (level 9 in
use)
< dh_installdocs: warning: Compatibility levels before 10 are deprecated
(level 9 in use)
< dh_installchangelogs: warning: Compatibility levels before 10 are
deprecated (level 9 in use)
< dh_compress: warning: Compatibility levels before 10 are deprecated
(level 9 in use)
< dh_missing: warning: Compatibility levels before 10 are deprecated
(level 9 in use)
< dh_installdeb: warning: Compatibility levels before 10 are deprecated
(level 9 in use)
test_dscverify
test_dscextractControl
test_dscextractChangelog
test_debchange
test_list_unreleased
test_debuild2
ASSERT:standard output of debuild --no-conf --no-lintian
--preserve-envvar=PATH --preserve-envvar=PERL5LIB
--preserve-envvar=DEBFULLNAME --preserve-envvar=DEBEMAIL
--preserve-envvar=GNUPGHOME --set-envvar=NO_PKG_MANGLE=1 -k'uscan test
key (no secret) ' matches
/tmp/autopkgtest-lxc.8rtfp1uo/downtmp/build.7Up/src/test/package_lifecycle/debuild.txt\n
expected:<0> but was:<1>
10,11d9
< dh: warning: Compatibility levels before 10 are deprecated (level 9 in
use)
< dh_clean: warning: Compatibility levels before 10 are deprecated
(level 9 in use)
19d16
< dh: warning: Compatibility levels before 10 are deprecated (level 9 in
use)
22,27d18
< dh: warning: Compatibility levels before 10 are deprecated (level 9 in
use)
< dh_installdocs: warning: Compatibility levels before 10 are deprecated
(level 9 in use)
< dh_installchangelogs: warning: Compatibility levels before 10 are
deprecated (level 9 in use)
< dh_compress: warning: Compatibility levels before 10 are deprecated
(level 9 in use)
< dh_missing: warning: Compatibility levels before 10 are deprecated
(level 9 in use)
< dh_installdeb: warning: Compatibility levels before 10 are deprecated
(level 9 in use)
test_debuild_forcesign
ASSERT:standard output of debuild --no-conf --no-lintian
--preserve-envvar=PATH --preserve-envvar=PERL5LIB
--preserve-envvar=DEBFULLNAME --preserve-envvar=DEBEMAIL
--preserve-envvar=GNUPGHOME --set-envvar=NO_PKG_MANGLE=1 --force-sign
-k'uscan test key (no secret) ' matches
/tmp/autopkgtest-lxc.8rtfp1uo/downtmp/build.7Up/src/test/package_lifecycle/debuild.txt\n
expected:<0> but was:<1>
10,11d9
< dh: warning: Compatibility levels before 10 are deprecated (level 9 in
use)
< dh_clean: warning: Compatibility levels before 10 are deprecated
(level 9 in use)
19d16
< dh: warning: Compatibility levels before 10 are deprecated (level 9 in
use)
22,27d18
< dh: warning: Compatibility levels before 10 are deprecated (level 9 in
use)
< dh_installdocs: warning: 

Bug#958336: Updating the python-debian Uploaders list

[Mattia Rizzolo]

On Mon, Apr 20, 2020 at 01:57:01PM -0300, Adeo Simó wrote:
> I submitted the following before retiring:
> 
> https://salsa.debian.org/python-debian-team/python-debian/-/merge_requests/20

Oh, indeed.  I didn't look at salsa, only at the open bugs.  Thanks for
being proactive! :)

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#956672: rtkit activation fails, because service unit is installed at the wrong place

[Sedat Dilek]

Hi,

rtkit (0.13-3) entered Debian/testing and the systemd unit file is
still at the wrong place.

testing: /usr/lib/x86_64-linux-gnu/systemd/system/rtkit-daemon.service
buster: /lib/systemd/system/rtkit-daemon.service

Sometimes it needs 3+1 attempts :-).

Bonne chance,
- Sedat -

[1] https://packages.debian.org/bullseye/amd64/rtkit/filelist
[2] https://packages.debian.org/buster/amd64/rtkit/filelist

Bug#954676: pasdoc: FTBFS: dh_installman: error: Could not determine section for ./pasdoc.1

[Paul Gevers]

Dear Michalis,

On 30-03-2020 14:11, Michalis Kamburelis wrote:
> The PasDoc manpage in Debian is done using
> 
> help2man --output=pasdoc.1 --name="documentation tool for Pascal source code" 
> \
>  --no-info bin/pasdoc

I just uploaded a new version of pasdoc to the Debian archive, but in
the process I filed two bugs, one against debhelper (bug #958343) and
one against help2man (bug #958345). It turns out that a recent help2man
started to create invalid .TH lines in the produced man file. It seems
to be very much related to what pasdoc output on the first line.
Apparently that's a bit unconventional.

No need to adapt, as I work around it now, but you *may* want to be in
line with other programs.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#958349: spice: please enable build on riscv64

[Aurelien Jarno]

Source: spice
Version: 0.14.3-1
Severity: wishlist

Dear maintainer,

The spice package is currently not build on riscv64 as this architecture
is not declared in the Architecture: field. It happens it builds fine
and that the testsuite pass on this architecture.

Therefore would it be possible to enable the build on riscv64? For the
record, I used the patch below.

Thanks,
Aurelien

diff -Nru spice-0.14.3/debian/control spice-0.14.3/debian/control
--- spice-0.14.3/debian/control
+++ spice-0.14.3/debian/control
@@ -33,7 +33,7 @@
 
 Package: libspice-server1
 Section: libs
-Architecture: alpha amd64 arm64 armel armhf i386 mips64el mipsel ppc64el sh4 
x32
+Architecture: alpha amd64 arm64 armel armhf i386 mips64el mipsel ppc64el 
riscv64 sh4 x32
 Multi-Arch: same
 Pre-Depends: ${misc:Pre-Depends}
 Depends: ${misc:Depends}, ${shlibs:Depends}
@@ -55,7 +55,7 @@
 
 Package: libspice-server-dev
 Section: libdevel
-Architecture: alpha amd64 arm64 armel armhf i386 mips64el mipsel ppc64el sh4 
x32
+Architecture: alpha amd64 arm64 armel armhf i386 mips64el mipsel ppc64el 
riscv64 sh4 x32
 Multi-Arch: same
 Depends:
  libspice-protocol-dev (>= 0.14.0~),

Bug#958348: RM: slof -- ROM; obsolete, firmware now built directly in QEMU

[Aurelien Jarno]

Package: ftp.debian.org
Severity: normal

slof is a firmware for Power virtual machines that is now built directly
by the qemu package and shipped in qemu-system-data. This package is now
useless, has no reverse dependencies and therefore should be removed.

Bug#958347: RM: openbios -- ROM; obsolete, firmware now built directly in QEMU

[Aurelien Jarno]

Package: ftp.debian.org
Severity: normal

openbios is a firmware for PowerPC and Sparc virtual machines that is
now built directly built by the qemu package and shipped in
qemu-system-data. This package is now useless, has no reverse
dependencies and therefore should be removed.

Bug#946420: kpat is spamming with error messages

[yaros]

On Tue, 31 Dec 2019 15:23:00 +0100 =?UTF-8?Q?Bernhard_=c3=9cbelacker?= 
 wrote:
> Control: notfound -1 4:18.04.1-1
> Control: found -1 4:19.08.1-1
> Control: tags -1 unreproducible moreinfo
> 
> 
> 
> Hello Hans,
> I tried to reproduce inside a minimal plasma testing VM.
> But I could not see a noticeable amount of messages in 
> .xsession_errors while playing kpat.
> 
> If this is still visible on your system then
> some more information could help.
> - Which game have you played inside kpat?
> - Some example lines of the messages in .xsession_errors
> 
> Kind regards,
> Bernhard
> 
> 


Hello,

The same problem here. Patience -> Jukon. My father can generate 6 GB log in 
one day ;)

print-layout-end
moves 9
  move 0 from 0 to 1 (-1) Prio: 19
  move 0 from 4 to 2 (-1) Prio: 19
  move 0 from 5 to 2 (-1) Prio: -117
  move 0 from 6 to 4 (-1) Prio: 19
  move 0 from 6 to 5 (-1) Prio: 19
  move 0 from 6 to 7 (-1) Prio: 19
  move 0 from 7 to 2 (-1) Prio: -117
  move 5 from 7 to 0 (-1) Prio: 19
  move 0 from 8 to 0 (-1) Prio: 3
print-layout-begin
Play0: QD 6D 9D 8C QS KD QD 
Play1: |KD 2H 8S 5H TD 5D KS 
Play2: |JH 6S 3C 9H 8S 7H 6S 5H 7S 
Play3: |2D TS 5D 4D 7C 8C 7H 3H TS 
Play4: |8D 5C TD 9S 8D JD 4D 4C 3D TC 4S QC 6H 
Play5: |TC QS 3S 2D JS KC QH JS TH 4S QH JC TH 9C 8H 7C 9S 
Play6: |JH KC 3S 6C 5C KH QC 6H 7D 4H JD 
Play7: |KH 3D 9C 8H 7D 6C 7S 6D 5S 
Off: AD 4C 2C 3H AH 2S AS 
Deck: |5S |KS |4H |JC |2S |9D |9H |AD 
print-layout-end
moves 6
  move 0 from 0 to 1 (-1) Prio: 19
  move 0 from 3 to 6 (-1) Prio: 19
  move 0 from 4 to 2 (-1) Prio: 19
  move 0 from 7 to 4 (-1) Prio: -117
  move 1 from 7 to 2 (-1) Prio: -117
  move 0 from 8 to 0 (-1) Prio: 3
print-layout-begin
Play0: QD 6D 9D 8C QS 7H 
Play1: |KD 2H 8S 5H TD 
Play2: |JH 6S 3C 9H 
Play3: |2D TS 5D 4D 7C 8C 8S 7H 6S 5H 4C 3H 
Play4: |8D 5C TD 9S 8D JD 4D 4C TC 4S 
Play5: |TC QS 3S 2D JS 3C KC 4S 3D 
Play6: |JH KC 3S 6C 5C KH QC 6H 7D 4H 
Play7: |KH 3D 9C 8H 7D 6C 7S JC TH 9C JS TH QH 8H 
Off: 2C 2C 2H AH 2S AS 
Deck: |5S |KS |4H |JC |2S |9D |9H |AD |6D |5S |9S |6H |TS |7S |KS |QD |7C |JD 
|QH |QC |3H |AD |5D |KD 
print-layout-end
moves 6
  move from 3 out (at -1) Prio: 5
  move 0 from 3 to 4 (-1) Prio: -117
  move 3 from 3 to 0 (-1) Prio: -117
  move 5 from 3 to 2 (-1) Prio: 19
  move 0 from 5 to 4 (-1) Prio: -117
  move 0 from 8 to 0 (-1) Prio: 3
print-layout-begin
Play0: QD 6D 9D 8C 
Play1: |KD 2H 8S 5H 4C 3D 
Play2: |JH 6S 3C 9H 5H 4C 3H 
Play3: |2D TS 5D 4D 7C 8C 
Play4: |8D 5C TD 9S 8D JD 4D 3C 
Play5: |TC QS 3S 2D JS TH 9C 
Play6: |JH KC 3S 6C 5C KH QC 6H 
Play7: |KH 3D 9C 8H 7D 6C 7S JC JS TH 
Off: 2C AC AH AH 2S AS 
Deck: |5S |KS |4H |JC |2S |9D |9H |AD |6D |5S |9S |6H |TS |7S |KS |QD |7C |JD 
|QH |QC |3H |AD |5D |KD |8H |4H |4S |4S |2C |6S |TD |7H |QH |7D |KC |TC |8S |7H 
|2H |QS 
print-layout-end
moves 3
  move from 4 out (at -1) Prio: 5
  move 0 from 5 to 7 (-1) Prio: -117
  move 0 from 8 to 0 (-1) Prio: 3
print-layout-begin
Play0: QD 6D 9D 8C QS 7H KD QC JD TC 9H 8S 7H 6S 5H 4C 3D 
Play1: |KD 2H 8S TH 9C QC 5H TD 5D 4S 
Play2: |JH 6S 
Play3: |2D TS 5D 4D 3H 
Play4: |8D 5C TD 9S 8D JD 4D 
Play5: |TC QS 3S 2D 8C 7D 6C JS KC QH 4S 3D QH 
Play6: |JH KC 3S 6C 5C KH 7D 
Play7: KH JC JS TH 9C 8H 7S 6H 8H 7C 7C 
Off: AD 4C 3C 4H AH 2S AS 
Deck: |5S |KS |4H |JC |2S |9D |9H |AD |6D |5S |9S |6H |TS |7S |KS |QD 
print-layout-end
moves 7
  move 0 from 0 to 1 (-1) Prio: 3
  move 2 from 0 to 2 (-1) Prio: -117
  move 3 from 0 to 6 (-1) Prio: -117
  move 1 from 1 to 2 (-1) Prio: 19
  move 0 from 2 to 6 (1) Prio: 44
  move 0 from 3 to 1 (-1) Prio: 19
  move 0 from 8 to 0 (-1) Prio: 3
print-layout-begin
Play0: QD 6D 9D 8C QS KD 
Play1: |KD 2H 8S 5H TD 5D 
Play2: |JH 6S 3C 9H 8S 7H 6S 5H 4C 3H 
Play3: |2D TS 5D 4D 7C 8C 7H 
Play4: |8D 5C TD 9S 8D JD 4D 4C 3D TC 4S QC 
Play5: |TC QS 3S 2D JS KC QH JS TH 4S QH 
Play6: |JH KC 3S 6C 5C KH QC 6H 7D 4H JD 
Play7: |KH 3D 9C 8H 7D 6C 7S JC TH 9C 8H 7C 
Off: AD 3C 2C 3H AH 2S AS 
Deck: |5S |KS |4H |JC |2S |9D |9H |AD |6D |5S |9S |6H |TS |7S |KS |QD 
print-layout-end
moves 6
  move 1 from 2 to 1 (-1) Prio: -117
  move 3 from 2 to 3 (-1) Prio: -117
  move 0 from 4 to 0 (-1) Prio: 19
  move 0 from 6 to 4 (-1) Prio: 19
  move 4 from 7 to 5 (-1) Prio: 19
  move 0 from 8 to 0 (-1) Prio: 3
print-layout-begin
Play0: QD 6D 9D 8C QS 7H KD QC JD TC 9H 8S 7H 6S 5H 4C 3D QD 
Play1: |KD 2H 8S TH 9C QC 5H TD 5D 4S KS 
Play2: |JH 6S 7S 
Play3: |2D TS 5D 4D 3H TS 
Play4: |8D 5C TD 9S 8D JD 4D 6H 
Play5: |TC QS 3S 2D 8C 7D 6C JS KC QH 4S 3D QH 9S 
Play6: |JH KC 3S 6C 5C KH 7D 5S 
Play7: KH JC JS TH 9C 8H 7S 6H 8H 7C 7C 6D 
Off: AD 4C 3C 4H AH 2S AS 
Deck: |5S |KS |4H |JC |2S |9D |9H |AD 
print-layout-end
moves 6
  move 0 from 0 to 1 (-1) Prio: 19
  move 0 from 4 to 2 (-1) Prio: 19
  move 0 from 6 to 4 (-1) Prio: 19
  move 0 from 6 to 7 (-1) Prio: 19
  move 0 from 7 to 2 (-1) Prio: -117
  move 0 from 8 to 0 (-1) Prio: 3
print-layout-begin
Play0: QD 6D 9D 8C QS KD QD 
Play1: |KD 2H 8S 5H TD 5D KS 
Play2: |JH 6S 3C 9H 8S 7H 6S 5H 4C 3H 

Bug#958346: latex-coffee-stains: redefine $\alpha$

[Bill Allombert]

Package: latex-coffee-stains
Version: 6-1
Severity: important

Hello Barak,

coffee.sty redefines $\alpha$. breaks the rendering of the document.

$\alpha$ is displayed as  0.94008

I joins a TeX and the corresponding PDF file.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 
\documentclass{article}
\usepackage[bleed]{coffee}
\begin{document}
$\alpha$
$\beta$
$\gamma$
\end{document}


coffee.pdf
Description: Adobe PDF document

Bug#958177: proxytunnel: Update to recent sources from Github

[Sven Geuer]

Hello Julian,

thank you for accepting to my suggestions. I will keep working on the
package and come back to you when I think it is ready to be uploaded.

I also plan to ask the pkg-security-team [1] whether proxytunnel can be
maintained from within this group as I already maintain arno-iptables-
firewall from there.

Hope to come back to you soon.

Best,
Sven

[1] https://wiki.debian.org/Teams/pkg-security


Am Sonntag, den 19.04.2020, 14:14 +0100 schrieb Julian Gilbey:
> On Sun, Apr 19, 2020 at 02:07:42PM +0200, Sven Geuer wrote:
> > Package: proxytunnel
> > Version: 1.9.0+svn250-6+b2
> > Severity: wishlist
> > 
> > Hello Julian,
> > 
> > I am a long-time user of the proxytunnel package and DM of arno-
> > iptables-
> > firewall.
> > 
> > Recently it occured to me proxytunnel not having been updated for
> > quite some
> > time, as well as a Debian package as upstream on Soureceforge [1].
> > 
> > On Github I discovered continued sources [2] and eventually started
> > to work on
> > the package [3].
> > 
> > I am interested in preparing an up-to-date version of proxytunnel
> > for Debian.
> > Therefore, I'd like to ask whether you would accept me as a co-
> > maintainer. In
> > case you are not interested in maintaining the packet any more I
> > would be happy
> > to adopt it.
> > 
> > Let me know what you think about my proposal.
> > 
> > Regards,
> > Sven
> 
> Hi Sven,
> 
> That's a really kind offer!  I no longer use the package, and had
> forgotten to see whether it's up-to-date.  If you'd like to adopt it,
> you are welcome to, or if you'd prefer to be a co-maintainer for a
> while, that would be fine too.
> 
> Best wishes,
> 
>Julian
> 


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

Bug#956848: ncbi-blast+-legacy: Please provide /usr/bin/blastpgp.pl (including .pl extension)

[Andreas Tille]

Thanks again.  Applied an pushed.  Please feel free to directly
commit to Git.  I don't see any advantage to communicate via
BTW. :-)

Kind regards, Andreas.

On Mon, Apr 20, 2020 at 01:06:42PM -0400, Aaron M. Ucko wrote:
> "Aaron M. Ucko"  writes:
> 
> > I've attached a full patch.
> 
> Extended to cover calls to blastall, which is also a legacy entry point.
> (I left blast_msa_old's call as is, since it's untranslatable without
> the crucial -p argument, and nothing calls that subroutine anyway.)
> 
> -- 
> 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
> 

> --- a/example/tc_generic_method.pl
> +++ b/example/tc_generic_method.pl
> @@ -688,7 +688,7 @@ sub blast_msa
>  
>  
>  #_system ("formatdb -i $db");
> -if ($blast eq "blastp"){_system  ("blastall -i $infile -d $db -m7 
> -p blastp -o io");}
> +if ($blast eq "blastp"){_system  ("blastp -db $db -query $infile 
> -out io -outfmt 5 -seg yes");}
>  elsif ($blast eq "blastn"){_system  ("blastn -query $infile -db $db 
> -outfmt 5 -word_size 4 -out io");}
>  
>  _blast_type ("io");
> @@ -1183,7 +1183,7 @@ sub pg_is_installed
>   if ($r eq ""){$r=0;}
>   else {$r=1;}
>  
> - if ($r==0 && is_blast_package ($p)){return pg_is_installed 
> ("legacy_blast.pl");}
> + if ($r==0 && is_blast_package ($p)){return pg_is_installed ("blastn");}
>   else {return $r;}
>}
>}
> @@ -2597,7 +2597,7 @@ sub run_blast
>   _configuration ("blastall");
>   if ($method eq "blastp")
> {
> - $command="blastall -d $db -i $infile -o $outfile -m7 -p blastp";
> + $command="blastp -db $db -query $infile -out $outfile -outfmt 5 
> -seg yes";
> }
>   _system ($command);
> }
> @@ -2611,26 +2611,20 @@ sub run_blast
>   $cl_db=$db;
>   }
>  
> -##
>   ## BLAST+ provide different binaries names and CLI options
> - ## Use the 'legacy_blast.pl' to keep compatibility with old 
> blast commands
> - ##
> - $path=`which legacy_blast.pl 2>/dev/null`;  
> - $path=`dirname $path`; 
> - chomp($path);
>   if ($method eq "blastp"){
> - _configuration("legacy_blast.pl");
> - $command="legacy_blast.pl blastpgp --path $path -d 
> $cl_db -i $infile -o $outfile -m7 -j1";
> + _configuration("psiblast");
> + $command="psiblast -db $cl_db -query $infile 
> -num_iterations 1 -out $outfile -outfmt 5";
>   }
>   elsif ($method eq "psiblast")
> {
> - _configuration("legacy_blast.pl");
> - $command="legacy_blast.pl blastpgp --path $path -d $cl_db -i 
> $infile -o $outfile -m7 -j5";
> + _configuration("psiblast");
> + $command="psiblast -db $cl_db -query $infile -num_iterations 5 
> -out $outfile -outfmt 5";
> }
>   elsif ($method eq "blastn")
> {
> - _configuration("legacy_blast.pl");
> - $command="legacy_blast.pl blastall --path $path -p blastn -d 
> $cl_db -i $infile -o $outfile -m7 -W6";
> + _configuration("blastn");
> + $command="blastn -task blastn -db $cl_db -query $infile 
> -word_size 6 -out $outfile -outfmt 5";
> }
>   print "$command\n";
>   _system ($command);
> @@ -2859,7 +2853,7 @@ sub seq2tblastx_lib
>}
>  close (F);
>  _system ("formatdb -i infile -p F");
> -_system ("blastall -p tblastx -i infile -d infile -m 7 
> -S1>blast.output");
> +_system ("tblastx -db infile -query infile -out blast.output 
> -outfmt 5");
>  
>  ncbi_tblastx_xml2lib_file ("outfile", file2string ("blast.output"));
>  _temporary_dir ("unset",$mode, $method, "outfile",$outfile);
> @@ -2890,7 +2884,7 @@ sub seq2tblastpx_lib
>  close (F);
>  _system("t_coffee -other_pg seq_reformat -in infile -output 
> tblastx_db1 > tblastxdb");
>  _system ("formatdb -i tblastxdb -p T");
> -_system ("blastall -p blastp -i tblastxdb -d tblastxdb -m7 
> >blast.output");
> +_system ("blastp -db tblastxdb -query tblastxdb -out blast.output 
> -outfmt 5");
>  ncbi_tblastpx_xml2lib_file ("outfile", file2string ("blast.output"), %s);
>  _temporary_dir ("unset",$mode, $method, "outfile",$outfile);
>  myexit ($EXIT_SUCCESS);


-- 
http://fam-tille.de

Bug#958229: Please document whether trailing commas are allowed

[Josh Triplett]

On Sun, 19 Apr 2020 23:12:28 +0200 Guillem Jover  wrote:
> On Sun, 2020-04-19 at 13:45:17 -0700, Josh Triplett wrote:
> > Package: dpkg-dev
> > Version: 1.19.7
> > Severity: normal
> > File: /usr/share/man/man5/deb-control.5.gz
> 
> > The deb-control manpage seemed like the right place to look to find out
> > if Debian control files can have trailing commas in comma-separated
> > fields (such as Depends). However, it didn't mention whether this was
> > allowed.
> 
> That man pages documents the control file for binary packages.

Ah.

> > (I'm hoping that it is, as that would improve the quality of diffs.)
> 
> This got documented in deb-src-control(5) in 1.19.0, I think at a
> similar time when this got requested to be clarified in debian-policy.
> 
>   
> 

That helps, thank you.

> I'm wondering what gave this false lead?

I looked for documentation on the file named debian/control, and I
remembered that dpkg uses the deb- abbreviation for many things, so I
guessed `man deb-control` and found a manpage.

Would you consider adding a note at the top of deb-control stating
something like "Debian source packages support additional features in
control files, which get eliminated when translating into the more
restrictive format for binary packages described here. For the control
format in source packages, see deb-src-control."

> (I have a pending and unfinished branch somewhere to move all the
> dependency syntax into its own man page, perhaps that would have
> helper here?)

Possibly.

- Josh Triplett

Bug#956855: consider reducing toolchain bootstrap stages

[Aurelien Jarno]

Hi,

On 2020-04-15 22:58, Helmut Grohne wrote:
> Source: cross-toolchain-base
> Version: 45
> Severity: wishlist
> Tags: patch moreinfo
> 
> I'm not sure anymore who told me, but glibc has a build_many_glibcs.py
> script and it does the toolchain bootstrap dance with fewer stages than
> Debian (i.e. cross-toolchain-base and rebootstrap) does.

Yes, this is what upstream is doing for the build bots. It's also the
recommended sequence for bootstrapping a system.

> The current
> Debian toolchain bootstrap looks like this:
> 
>  * binutils
>  * linux-libc-dev
>  * gcc stage1 (bare metal)
>  * glibc stage1 (headers + stub libc.so)
>  * gcc stage2
>  * glibc stage2 (libc without systemtap and other optional features)
>  * gcc stage3 (libc-integrated cross compiler)
>  * gcc rtlibs (runtime libraries for the cross compiler)
> 
> The assertion is that we can skip glibc stage1 and gcc stage2 and go
> directly from gcc stage1 to glibc stage2.
> 
> I've implemented this in rebootstrap and it seems to work reasonably
> well for a number of architectures. I've not run it on the full test
> matrix yet. Some observations on rebootstrap:
>  * musl-linux-any already works like this since a while.
>  * hurd-any formerly needed libihash-dev for libpthread, but no longer
>does. This sequence also works on hurd-i386.
>  * I've had success with arm64, armel, armhf, m68k, mips (nobiarch),
>mipsel (nobiarch) and ppc64el thus far. Notably, these all lack
>multilibs and I'm still sorting out multilib issues.
>  * I cannot tell about kfreebsd-any, since they didn't manage to get the
>relevant kernel header source package back into unstable yet.
> 
> I've implemented this for cross-toolchain-base (patch attached) and a
> performed a successful testbuild. Using diffoscope to compare the
> resulting packages with the ones from the archive was not a useful thing
> to do as the build-ids changed.

Thanks a lot for working on that. I haven't tried it but that's great
news.

> So what do you think about going to fewer stages? I'd like to solicit
> explicit feedback from the involved parties:
> 
> gcc maintainers / Matthias:
>  * Do you have any objections to reducing stages?
>  * Should we delete gcc stage2?
>  * Should we rename gcc stage3 to gcc stage2?
> 
> glibc maintainers / Aurelien:
>  * Do you have any objections to reducing stages?

I have no objections for that. I am actually really in favor for that.
We have less chances to have issues if we stick to the upstream
recommended way of bootstrapping. And if we find issue, it will be
easier to fix them and get those fixes upstreamed.

>  * Should we delete glibc stage1?

Not immediately, we should keep it for a few weeks or months to make
sure all works as expected.

>  * Should we rename glibc stage2 to glibc stage1?

That's probably a good idea, in a second step.

>  * Should we maybe split stage2 into a number of profiles
>pkg.glibc.noselinux, pkg.glibc.noxen, pkg.glibc.noalphaev,
>pkg.glibc.noxcryptdep?

That's an option, I don't have a strong opinion at that point. I guess
that pkg.glibc.noalphaev and pkg.glibc.noxcryptdep can actually be
merged into a single profile to disable optimized builds. 

Aurelien

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


signature.asc
Description: PGP signature

Bug#958341: autopkgtest: unexpected test dependency resolver behavior

[Paul Gevers]

Hi Duck,

On 20-04-2020 19:46, Marc Dequènes (duck) wrote:
> So it seems autopkgtest is not running apt with the content of the
> Depends field but installing them one by one in specified order. As much
> as I understand it can be very useful to solve complex testing cases,
> this is not how our usual resolver works and I was unable to find
> anything about it in the documentation. From what I can see in #923468
> I'm not the only one not understanding that.
> 
> (unless I'm totally mistaken, it's late here) Could you document the
> exact behavior and give recommendations on how to set the Depends please?

autopkgtest generates a dummy package with your Depends field and asks
apt to install that.

Package: autopkgtest-satdep
Section: oldlibs
Priority: extra
Maintainer: autogenerated
Version: 0
Architecture: %s
Depends: %s
Description: satisfy autopkgtest test dependencies

The Depends string is processed here:
https://salsa.debian.org/ci-team/autopkgtest/-/blob/master/lib/adt_testbed.py#L891

So the magic is coming from the Dpkg::Deps deps_parse module. I don't
know what happens there.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#954427: mirror submission for debian.itsbrasil.net

[João Lima]

Hi Julien,

Thanks for your response!
About Mirror origin:
Could you indicate some rsync servers for us to use here in Brazil?

About DNS:
We use Cloudflare cloud as DNS. This Anycast network allows DNS resolution
at the network edge in each of cloudflare data centers across 200+ cities,
resulting in unparalleled redundancy and 100% uptime.






Em seg., 20 de abr. de 2020 às 12:11, Julien Cristau 
escreveu:

> Control: tag -1 moreinfo
>
> On Sat, Mar 21, 2020 at 01:25:09PM +, ITS Telecomunicacoes wrote:
> >  We would like to add our brazillian mirror to Debian list!
> >
> >  ## ITS Telecomunicacoes - Mirror Linux Debian
> >  http://debian.itsbrasil.net/debian
> >  https://debian.itsbrasil.net/debian
> >
> Hi,
>
> Thanks for mirroring Debian.
>
> while checking your mirror our script noticed the following issues:
>
> o we recommend mirrors not sync directly from service aliases such as
>   ftp..debian.org (only http is guaranteed to be available at
>   ftp..d.o sites).  Maybe change your config to sync from
>   the site currently backing the ftp..debian.org service you sync
>   from?
>
> o The nameservers for debian.itsbrasil.net are all in the same AS.  For
> reliability we
>   recommend having nameservers in more than one location.
>
> Cheers,
> Julien
>

Bug#956365: redmine: unmet dependencies

[duck]

Quack,

On 2020-04-21 02:18, Dragos Jarca wrote:


As u can see, I cannot downgrade rails, because of gitlab, that use
rails 6. I will not downgrade gitlab.


Except Rails 6 is in experimental, not unstable, so you cannot create an 
RC bug for it. Experimental is a playground to prepare big changes not 
something you should use for production.


See below, and your own link, you're asking for the impossible.


Pls. see https://www.redmine.org/issues/29914


Yes, that's far from over, so upgrading to 4.1 is not gonna solve 
anything. From others bug reports it seems 4.2 might have basic Rails 6 
support, but that would need to be tested.


So currently I just cannot solve your problem as there is no redmine 
version compatible with Rails 6 in the world. You would need to use a VM 
or container if you cannot use another machine.


Regards.
\_o<

--
Marc Dequènes

Bug#922430: Fixed.

[Victor]

Apologies for the long delay in responding to this bug, but it has been fix and 
the fix incorporated into LFT v3.91 which is available at 
pwhois.org/get/lft-3.91.tar.gz 

It would be great if the ports tree were updated to this version.

Thank you 

Bug#955042: redmine: drag and drop of attachments does not work due to used jQuery version

[duck]

Quack,

Thanks for providing all these info about the JQuery changes.
Using v3 has been done because v1.11 is very old, without upstream 
support, so that would mean handling all problems and security fixes by 
ourselves on the embedded copy and we did not want that. I made some 
fixes already but missed this one.


Regards.
\_o<

--
Marc Dequènes

Bug#958345: help2man generates invalid .TH line for pasdoc

[Paul Gevers]

Package: help2man
Version: 1.47.13
Severity: normal

Dear maintainer(s),

Recently pasdoc started to FTBFS (bug #954676) for what is apparently a
change in the output of help2man. dh_installman determines the section
based on the .TH line. The line of the installed pasdoc package on my
system reads (build with help2man 1.47.5):
"""
.TH PASDOC "1" "February 2018" "PasDoc 0.15.0 [2018-02-08|FPC
3.0.4|Linux|64]" "User Commands"
"""
while a call to $(help2man pasdoc) with help2man 1.47.13 has this:
"""
.TH PASDOC 0.15.0 [2018-02-08|FPC "1" "April 2020" "PasDoc 0.15.0
[2018-02-08|FPC 3.0.4|Linux|64]" "User Commands"
"""

man(7) says it should be:
.TH title section date source manual

Paul

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

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

Versions of packages help2man depends on:
ii  dpkg1.19.7
ii  install-info6.7.0.dfsg.2-5
ii  libc6   2.30-4
ii  liblocale-gettext-perl  1.07-4
ii  perl5.30.0-9

help2man recommends no packages.

help2man suggests no packages.

-- no debconf information



signature.asc
Description: OpenPGP digital signature

Bug#958344: Update bleachbit to 4.0.0

[Amr Ibrahim]

Package: bleachbit

Please update bleachbit to 4.0.0.

https://www.bleachbit.org/news/bleachbit-400

Bug#958304: Can not make Epson L1800 work

[Didier 'OdyX' Raboud]

Le lundi, 20 avril 2020, 18.59:31 h CEST wg...@china.com a écrit :
> Hello, the epson-inkjet-printer-201312w need LSB which is abandoned by
> Debian. So it is not be used in Debian 10. Would you please tell me how to
> use the epson-inkjet-printer-201312w in Debian without LSB?

You need to talk to Epson :-) LSB is gone from Debian 10 for good reasons, and 
they need to adapt.

The easiest way is most probably to install lsb-compat from stretch:

http://deb.debian.org/debian/pool/main/l/lsb/lsb-compat_9.20161125_amd64.deb

Regards,
OdyX

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

Bug#958343: /usr/bin/dh_installman: dh_installman doesn't fall back to using file extension when .TH line is incorrect

[Paul Gevers]

Package: debhelper
Version: 12.10
Severity: normal
File: /usr/bin/dh_installman

Dear Maintainers, Niels,

Recently pasdoc started to FTBFS (bug #954676) for what is apparently a
change in the output of help2man. However, I think it shouldn't FTBFS on
that, as the documentation of dh_installman reads:
"""
If your .TH or .Dt line is incorrect or missing, the program may guess
wrong based on the file extension.
"""

I have attached the output of $(help2man pasdc) on my system. The .TH
line doesn't obey the definition I found in man(7).

Paul


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

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

Versions of packages debhelper depends on:
ii  autotools-dev20180224.1
ii  dh-autoreconf19
ii  dh-strip-nondeterminism  1.8.0-1
ii  dpkg 1.19.7
ii  dpkg-dev 1.19.7
ii  dwz  0.13-5
ii  file 1:5.38-4
ii  libdebhelper-perl12.10
ii  libdpkg-perl 1.19.7
ii  man-db   2.9.1-1
ii  perl 5.30.0-9
ii  po-debconf   1.0.21

debhelper recommends no packages.

Versions of packages debhelper suggests:
ii  dh-make  2.202001

-- no debconf information
.\" DO NOT MODIFY THIS FILE!  It was generated by help2man 1.47.13.
.TH PASDOC 0.15.0 [2018-02-08|FPC "1" "April 2020" "PasDoc 0.15.0 
[2018-02-08|FPC 3.0.4|Linux|64]" "User Commands"
.SH NAME
PasDoc 0.15.0 [2018-02-08|FPC \- manual page for PasDoc 0.15.0 [2018-02-08|FPC 
3.0.4|Linux|64]
.SH SYNOPSIS
.B pasdoc
[\fI\,options\/\fR] [\fI\,files\/\fR]
.SH DESCRIPTION
PasDoc 0.15.0 [2018\-02\-08|FPC 3.0.4|Linux|64]
Documentation generator for Pascal source
.PP
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
.SS "Valid options are:"
.TP
\-?, \fB\-\-help\fR
Show this help
.TP
\fB\-\-version\fR
Show pasdoc version (and related info)
.TP
\fB\-v\fR, \fB\-\-verbosity\fR
Set log verbosity (0\-6) [2]
.TP
\fB\-D\fR, \fB\-\-define\fR
Define conditional
.TP
\fB\-R\fR, \fB\-\-description\fR
Read description from this file
.TP
\fB\-d\fR, \fB\-\-conditionals\fR
Read conditionals from this file
.TP
\fB\-I\fR, \fB\-\-include\fR
Includes search path
.TP
\fB\-S\fR, \fB\-\-source\fR
Read source filenames from file
.TP
\fB\-\-html\-help\-contents\fR
Read Contents for HtmlHelp from file
.TP
\fB\-H\fR, \fB\-\-header\fR
Include file as header for HTML output
.TP
\fB\-F\fR, \fB\-\-footer\fR
Include file as footer for HTML output
.TP
\fB\-\-html\-head\fR
Include file to use inside HTML 
.TP
\fB\-\-html\-body\-begin\fR
Include file to use right after HTML 
.TP
\fB\-\-html\-body\-end\fR
Include file to use right before HTML 
.TP
\fB\-N\fR, \fB\-\-name\fR
Name for documentation
.TP
\fB\-T\fR, \fB\-\-title\fR
Documentation title
.TP
\fB\-O\fR, \fB\-\-format\fR
Output format: html, simplexml, latex, latex2rtf or
htmlhelp
.TP
\fB\-E\fR, \fB\-\-output\fR
Output path
.TP
\fB\-X\fR, \fB\-\-exclude\-generator\fR
Exclude generator information
.TP
\fB\-\-include\-creation\-time\fR
Include creation time in the docs
.TP
\fB\-L\fR, \fB\-\-language\fR
Output language. Valid languages are:
ba: Bosnian (Codepage 1250)
br.1252: Brazilian (Codepage 1252)
br.utf8: Brazilian (Codepage UTF\-8)
bg: Bulgarian (Codepage UTF\-8)
ct: Catalan
gb2312: Chinese (Simple, gb2312)
hr: Croatian
dk: Danish
nl: Dutch
en: English
fr: French (iso\-8859\-15)
fr.utf8: French (UTF\-8)
de: German
id: Indonesian
it: Italian
jv: Javanese
pl.cp1250: Polish (Codepage CP1250)
pl.iso\-8859\-2: Polish (Codepage ISO 8859\-2)
ru.1251: Russian (Codepage 1251)
ru.utf8: Russian (Codepage UTF\-8)
ru.866: Russian (Codepage 866)
ru.koi8r: Russian (KOI\-8)
sk: Slovak (Codepage 1250)
es: Spanish
se: Swedish
hu.1250: Hungarian (Codepage 1250)
cz: Czech (Codepage 1250)
cz.iso\-8859\-2: Czech (Codepage ISO 8859\-2)
.TP
\fB\-\-staronly\fR
Parse only {**, (*** and //** style comments
.TP
\fB\-\-marker\fR
Parse only {, (* and // comments.
Overrides the staronly option, which is a shortcut
for '\-\-marker=**'
.TP
\fB\-\-marker\-optional\fR
Do not require the markers given in \fB\-\-marker\fR but remove
them from the comment if they exist.
.TP
\fB\-\-ignore\-leading\fR
Ignore leading  characters in comments.
.TP
\fB\-\-numericfilenames\fR
Causes the html generator to create numeric filenames
.TP
\fB\-M\fR, \fB\-\-visible\-members\fR
Include / Exclude class Members by visiblity
.TP
\fB\-\-write\-uses\-list\fR
Put uses list into output
.TP
\fB\-\-graphviz\-uses\fR
Write a GVUses.dot file 

Bug#957651: Upstream fix

[Harald Welte]

Upstream fix is available in https://gerrit.osmocom.org/c/osmo-bts/+/17916
-- 
- Harald Welte  http://www.sysmocom.de/
===
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Director: Harald Welte

Bug#957634: Upstream fix

[Harald Welte]

Upstream fix is available in https://gerrit.osmocom.org/c/openbsc/+/17917
-- 
- Harald Welte  http://www.sysmocom.de/
===
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Director: Harald Welte

Bug#931858: libreswan: please remove the dependency on systemd

[Antony Antony]

Package: libreswan
Version: 3.27-6
Severity: normal

Hi Stephen,

Thanks.  that is a good step. It would be nice to remove the build time 
dependency too.

On Fedora we can do something like the following.

make UNITDIR=%{_unitdir} TMPFILESDIR=%{_tmpfilesdir} INITSYSTEM=systemd base

if there is Debian equivalent, to get UNITDIR, in "rules" we can drop build 
time dependency to systemd.

upstream export UNITDIR since
https://github.com/libreswan/libreswan/commit/8150294b4b51a9476a99a8d7a23b30b0e7d937ae

regards,
-antony



On Sun, Apr 19, 2020 at 08:59:26PM +0200, Stephen Kitt wrote:
> Hi Antony,
> 
> On Sun, 19 Apr 2020 18:21:23 +0200, Antony Antony  wrote:
> > I came across this bug report and thought add my comment.
> > 
> > systemd dependency was added due to a bug, reported at.
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=875639 
> > 
> > which is cause by build time dependency
> > SYSTEMUNITDIR=$(shell pkg-config systemd --variable=systemdsystemunitdir) 
> > 
> > https://github.com/libreswan/libreswan/blob/7d9afc01c0d558f59103e56667cf9d227e12a28b/initsystems/systemd/Makefile#L5
> >  
> 
> Thanks for taking the time to reply. If the above is the reason that systemd
> was added, then the build-dependency is sufficient: the package needs systemd
> during the build, but not necessarily at runtime.
> 
> > to remove systemd dependency we may need a generic fix in upstream.
> 
> I think https://salsa.debian.org/debian/libreswan/-/merge_requests/1 should
> be sufficient...
> 
> Regards,
> 
> Stephen

Bug#957649: Upstream fix

[Harald Welte]

Upstream fix is available in https://gerrit.osmocom.org/c/osmo-bsc/+/17914
-- 
- Harald Welte  http://www.sysmocom.de/
===
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Director: Harald Welte

Bug#957652: Upstream fix

[Harald Welte]

Upstream fix is available in https://gerrit.osmocom.org/c/osmo-iuh/+/17915
-- 
- Harald Welte  http://www.sysmocom.de/
===
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Director: Harald Welte

Bug#958342: xc3sprog: reports incorrect device ID codes

[Kipp Cannon]

Package: xc3sprog
Version: 0+svn795+dfsg-1+b1
Severity: important

I am new to FPGA development, so I don't have the ability to test a variety
of configurations.  I have a Spartan-3E Starter Kit development board,
which has a built-in Xilinx "platform cable" interface.  I am using the
Xilinx platform cable firmware that ships with ISE 14.7, specifically I am
using the xusb_emb.hex file with md5sum 545ce982a72441822960fb66a28bde98.
The information available online implies to me that xc3sprog should work
with this development kit, but it does not.  The device IDs is reports are
nonsense, and without being able to identify the devices the software
cannot interact with them rendering it effectively non-functional.

What I get is

$ xc3sprog -c xpc_internal
XC3SPROG (c) 2004-2011 xc3sprog project $Rev$ OS: Linux
Free software: If you contribute nothing, expect nothing!
Feedback on success/failure/enhancement requests:
http://sourceforge.net/mail/?group_id=170565 
Check Sourceforge for updates:
http://sourceforge.net/projects/xc3sprog/develop

Cannot find device having IDCODE=1070607 Revision A
JTAG loc.:   0  IDCODE: 0x01070607  not found in 'built-in device list'.
JTAG loc.:   1  IDCODE: 0x03030707  not found in 'built-in device list'.
JTAG loc.:   2  IDCODE: 0x03070707  not found in 'built-in device list'.


The board does have 3 devices in the jtag chain, so that much is correct.

The "jtag" program from the urjtag package works correctly, it is
able to scan the jtag chain and program devices on it.  It reports the
following for the board so you can see what the device IDs should be:

jtag> cable xpc_int
firmware version = 0x0404 (1028)
cable CPLD version = 0x0006 (6)
jtag> detect
IR length: 22
Chain length: 3
Device Id: 01101110010010010011 (0x06E5E093)
  Manufacturer: Xilinx (0x093)
  Part(0):  XC2C64-VQ44 (0x6E5E)
  Stepping: 0
  Filename: /home/kipp/urjtag/share/urjtag/xilinx/xc2c64a-vq44/xc2c64a-vq44
Device Id: 01010100011010010011 (0x05046093)
  Manufacturer: Xilinx (0x093)
  Part(1):  xcf04s (0x5046)
  Stepping: 0
  Filename: /home/kipp/urjtag/share/urjtag/xilinx/xcf04s/xcf04s
Device Id: 00011110001010010011 (0x01C22093)
  Manufacturer: Xilinx (0x093)
  Part(2):  xc3s500e_fg320 (0x1C22)
  Stepping: 0
  Filename: 
/home/kipp/urjtag/share/urjtag/xilinx/xc3s500e_fg320/xc3s500e_fg320

-Kipp

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

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

Versions of packages xc3sprog depends on:
ii  libc62.30-4
ii  libftdi1-2   1.4-2+b2
ii  libgcc-s1 [libgcc1]  10-20200411-1
ii  libgcc1  1:10-20200411-1
ii  libstdc++6   10-20200411-1
ii  libusb-0.1-4 2:0.1.12-32
ii  libusb-1.0-0 2:1.0.23-2

xc3sprog recommends no packages.

xc3sprog suggests no packages.

-- no debconf information

Bug#954486: mirror submission for mirrors.ptisp.pt

[Eduardo Silvestre]

Hi Julien,

 fixed. Can you please check?

Melhores Cumprimentos | Best Regards, 
— 
Eduardo Silvestre 
ptisp | wherever internet can take you… 

edua...@ptisp.pt 
helpdesk: +351 249 739 099 
mobile: +351 91 536 46 43 
[ http://www.ptisp.pt/ | www.ptisp.pt ]

- Original Message -
From: "Julien Cristau" 
To: "Eduardo" , 954...@bugs.debian.org
Sent: Monday, April 20, 2020 4:13:44 PM
Subject: Re: Bug#954486: mirror submission for mirrors.ptisp.pt

Control: tag -1 moreinfo

On Sun, Mar 22, 2020 at 04:09:20AM +, Eduardo Silvestre wrote:
> Submission-Type: new
> Site: mirrors.ptisp.pt

Hi,

thanks for mirroring Debian.

While checking your mirror for inclusion, our script noticed the following 
issues:

o The tracefile at
  http://mirrors.ptisp.pt/debian/project/trace/mirrors.ptisp.pt
  is missing some required information.

  We expect at least the Maintainer and Upstream-mirror values to be filled in,
  and your tracefile is missing one or both of them.

o we recommend mirrors not sync directly from service aliases such as
  ftp..debian.org (only http is guaranteed to be available at
  ftp..d.o sites).  Maybe change your config to sync from
  the site currently backing the ftp..debian.org service you sync
  from?

Cheers,
Julien

Bug#957463: Upstream fix

[Harald Welte]

Upstream fix is available at https://gerrit.osmocom.org/c/libosmo-sccp/+/17911

-- 
- Harald Weltehttp://laforge.gnumonks.org/

"Privacy in residential applications is a desirable marketing option."
  (ETSI EN 300 175-7 Ch. A6)

Bug#958341: autopkgtest: unexpected test dependency resolver behavior

[duck]

Package: autopkgtest
Version: 5.13.1


Quack,

Our Ruby tool dh-make-ruby suggested a nice reformating/reordering of 
debian/tests/control and this seemingly benign change broke the world:

  https://salsa.debian.org/ruby-team/redmine/-/jobs/683636
Now i finally found out that reordering back certain dependencies fixed 
the problem (redmine- before redmine, so that redmine-sqlite is not 
dragged in when trying to test another database):

  https://salsa.debian.org/ruby-team/redmine/-/jobs/683699

So it seems autopkgtest is not running apt with the content of the 
Depends field but installing them one by one in specified order. As much 
as I understand it can be very useful to solve complex testing cases, 
this is not how our usual resolver works and I was unable to find 
anything about it in the documentation. From what I can see in #923468 
I'm not the only one not understanding that.


(unless I'm totally mistaken, it's late here) Could you document the 
exact behavior and give recommendations on how to set the Depends 
please?


Regards.
\_o<

--
Marc Dequènes

Bug#956365: redmine: unmet dependencies

[Dragos Jarca]

Hi

Thx for your answer.

root@omv:~# apt-get -t unstable install redmine
Reading package lists... Done
Building dependency tree
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 redmine : Depends: ruby-actionpack-xml-parser but it is not going to 
be installed
   Depends: ruby-roadie-rails (>= 1.3.0) but it is not going to 
be installed

E: Unable to correct problems, you have held broken packages.

root@***:~# apt-get -t unstable install redmine 
ruby-actionpack-xml-parser ruby-roadie-rails

Reading package lists... Done
Building dependency tree
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 ruby-actionpack-xml-parser : Depends: ruby-actionpack (< 2:6) but 
2:6.0.2.1+dfsg-3 is to be installed
  Depends: ruby-railties (< 2:6) but 
2:6.0.2.1+dfsg-3 is to be installed
 ruby-roadie-rails : Depends: ruby-railties (< 2:5.3) but 
2:6.0.2.1+dfsg-3 is to be installed

E: Unable to correct problems, you have held broken packages.

root@***:~# dpkg -l gitlab
Desired=Unknown/Install/Remove/Purge/Hold
| 
Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend

|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name   Version  Architecture Description
+++-==---==
ii  gitlab 12.9.2-4 all  git powered software 
platform to collaborate on code (non-omnibus)


As u can see, I cannot downgrade rails, because of gitlab, that use 
rails 6. I will not downgrade gitlab.


Pls. see https://www.redmine.org/issues/29914

Regards

On 20.04.2020 14:06, Marc Dequènes (duck) wrote:

Control: severity -1 normal
Control: tag -1 + unreproducible


Quack,

I just made a fresh install on today's unstable and cannot reproduce 
your installation problem.


Involed libraried are:
Setting up ruby-roadie-rails (1.3.0-2) ...
Setting up ruby-roadie (4.0.0-1) ...
Setting up ruby-actionpack-xml-parser (2.0.1-3) ...

So maybe something was amiss in unstable at the time, or your gitlab 
installation added local gems, but this worked when I uploaded and it 
works now too. Did you install gitlab using the package? Could you see 
if this still a problem now?


As for 4.1 I don't see the relationship. Anyway I need to wait in 
order to get buster-bpo in order and then either 4.1 or 4.2 would come 
in.


Regards.

Bug#956055: dpkg should use treat signatures from the DD_nu keyring as valid

[Taowa Munene-Tardif]

Hi Guillem,

On Mon, Apr 20, 2020 at 12:13:30AM +0200, Guillem Jover wrote:
> Hi!
> 
> On Mon, 2020-04-06 at 14:57:30 -0400, Taowa wrote:
> > Package: dpkg
> > Version: 1.19.7
> > Tags: patch
> 
> > --require-valid-signature currently uses the DD uploading and DM
> > keyrings (among others), it should also check against the DD
> > nonuploading keyring as they are treated like DMs as per [1,2].
> 
> Thanks for the patch! The change to the .pot should have gone instead
> to the man/dpkg-source.man (but that didn't trigger a git grep I guess
> due to the escaped «-» :/, I'll be moving to POD so that this kind of
> thing does not happen among other stuff :), I've fixed this locally.

Great, thanks :)
 
> I was wondering though how do you want it to be attributed when I
> commit to git? Say:
> 
>   Taowa Munene-Tardif 
> 
> or like in the From to the bug report?
> 
>   Taowa 
> 
> Something else? :)

Taowa Munene-Tardif  is my preference, but I hadn't
gotten around to sending email as taowa@d.o yet. Thanks for asking!
 
> (I'd recommend setting up git config user.email, committing patches to
> git and then using «git format-patch» so that you state clearly this
> kind of thing. :)
 
That seems like a much easier workflow, I'll keep it in mind for next
time.

Thanks again,
Taowa

-- 
Taowa Munene-Tardif
ta...@debian.org
taowa.ca
Montréal

Bug#877232: u-boot-rockchip: u-boot-spl-dtb.bin missing

[Heinrich Schuchardt]

On 4/20/20 7:10 PM, Vagrant Cascadian wrote:
> Control: tags 877232 moreinfo
>
> On 2017-09-29, Heinrich Schuchardt wrote:
>> On 09/29/2017 09:26 PM, Vagrant Cascadian wrote:
>>> On 2017-09-29, Heinrich Schuchardt wrote:
 usr/share/doc/u-boot-rockchip/README.rockchip.gz asks for copying
 u-boot-spl-dtb.bin to the SD card.

 File /usr/lib/u-boot/firefly-rk3399/spl/u-boot-spl-dtb.bin is not
 provided by the package.
>>>
>>> It's identical to u-boot-spl.bin, as of a few releases ago. I think
>>> the logic was to default to the dtb variant if the platform
>>> supports dtb, since that's what is actually needed in most cases.
>>>
>>>
 So either some documentation for RK3399 should be added or a file
 is missing.
>>>
>>> I'm guessing the upstream documentation needs a minor update. There
>>> are probably other README files in a similar situation.
> ...
>> Yes you are right this is the relevant command in U-Boot:
>> cmd_spl/u-boot-spl.bin := cp spl/u-boot-spl-dtb.bin spl/u-boot-spl.bin
>
> While README.rockchip still still contains references to
> u-boot-spl-dtb.bin, the README.Debian now documents using idbloader.img,
> which seems to be consistantly used across most rockchip platforms.
>
> Is that sufficient, or should this bug stay open?
>
>
> live well,
>   vagrant
>
Hello Vagrant,

thanks for caring. Please, close the issue.

Best regards

Heinrich

Bug#935035: u-boot: Olimex Teres-I support for builtin keyboard

[Vagrant Cascadian]

Control: tags 935035 moreinfo

On 2019-08-18, Jonas Smedegaard wrote:
> U-Boot supports the DIY laptop Olimex Teres-I, except the builtin
> keyboard is not detected.
...
> A working patchset is pushed to git branch wip-teres-i-keyboard:
> https://salsa.debian.org/debian/u-boot/tree/wip/teres-i-keyboard
...
> This patchset is not in mainline U-Boot, but I intent to propose it.

Any status update on mainline support? Is it still an issue with newer
u-boot packages in Debian?


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#958339: dh_shlibdeps: Generate lockstep dependencies within a source package

[Niels Thykier]

Control: forcemerge 942134 -1

On Mon, 20 Apr 2020 18:11:19 +0100 Simon McVittie  wrote:
> Package: debhelper
> Version: 13
> Severity: wishlist
> 
> We recently had some crash bugs reported against GNOME (#958017, #958025)
> which turned out to involve a minimal partial upgrade from stable to
> testing/unstable.
> 
> [...]
> 
> Does this seem a reasonable debhelper feature?
> 
> Thanks,
> smcv
> 
> 

I believe this is a duplicate of #942134, merging accordingly.  As
mentioned in #942134, I am fine with supporting it provided there was a
decent interface between debhelper and dpkg for this (and hopefully
there will be).

~Niels

Bug#956848: Bug#956850: Bug#956848: ncbi-blast+-legacy: Please provide /usr/bin/blastpgp.pl (including .pl extension)

[Andreas Tille]

Hi Aaron,

On Mon, Apr 20, 2020 at 10:52:40AM -0400, Aaron M. Ucko wrote:
> I've attached a full patch.

thanks a lot.  Patch commited to Git.

The test suite runs fine.  I admit I crafted the patch to let the test
suite of python-cogent pass.  This software has changed severely so I do
not have that external test.  We'll see how it works with your patch
and rely on user response if needed. ;-)

Thanks a lot

  Andreas.

-- 
http://fam-tille.de

Bug#958340: ITP: golang-github-client9-reopen -- freopen functionality for golang's io.Writers

[Pirate Praveen]

Package: wnpp
Severity: wishlist
Owner: Pirate Praveen 

* Package name : golang-github-client9-reopen
 Version : 1.0.0-1
 Upstream Author : Nick Galbreath
* URL : https://github.com/client9/reopen
* License : Expat
 Programming Lang: Go
 Description : freopen functionality for golang's io.Writers

Makes a standard os.File a "reopenable writer" and
allows SIGHUP signals to reopen log files, as needed
by logrotated.
This is inspired by the C/Posix freopen.

Bug#958327: charliecloud: cannot use ch-run

[Peter Wienemann]

Hi Christophe,

On 20.04.20 17:05, Christophe Trophime wrote:
> Trying to run  a test example with some mount directory (ie ch-run -h
> SRC:DST -w ./feelpp-v0.108-focal/ -- pwd)
> I end up with error like: ch-run[190638]: error (charliecloud.c:553)
> Same behaviour without -h nor -w options

this looks like this upstream issue:

https://github.com/hpc/charliecloud/issues/649

(i. e. a UID lookup failure).

Peter

Bug#955656: python-cobra: FTBFS: E ModuleNotFoundError: No module named 'matplotlib'

[Andreas Tille]

Hi Pierre,

a, now I've got it!  Great it runs now.  Uploaded thanks to
your hint, Andreas.

On Mon, Apr 20, 2020 at 06:24:00PM +0200, Pierre Gruet wrote:
> Hi Andreas,
> 
> Le 20/04/2020 à 12:08, Andreas Tille a écrit :
> > 
> > Thanks a lot for checking.  The issue is that we can not build the recent
> > upstream version as I wrote in
> > 
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=955656#10
> > 
> > Most probably that's *not* a problem of python-cobra but rather of
> > python2-sbml5 (I think Liubov in CC found this out but I simply forgot). 
> > If you have any spare resources could you please verify this?  Please
> > checkout latest Git
> > 
> >https://salsa.debian.org/med-team/python-cobra
> >
> 
> Sorry for maybe explaining things unclearly in my previous email, but what
> you suggest is what I did: I took your packaging of version 0.18.0-1 in
> Salsa, and I could build it without a problem in a sid chroot.
> Some test have ``xfail'' result, but none has ``fail''.
> 
> I understand the problem you showed in
> 
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=955656#10
> 
> means some module could not be loaded, but as I did not encounter this
> problem while building, I wrote to you this morning in order to try to
> understand the reason.
> 
> >
> > Kind regards and thanks again for your attempt to help
> > 
> > Andreas.
> > 
> 
> I hope this can help, or at least that we can understand the reason why we
> have different results at a 16-day interval.
> 
> All the best,
> Pierre
> 
> ___
> Debian-med-packaging mailing list
> debian-med-packag...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging

-- 
http://fam-tille.de

Bug#958313: libnitrokey: FTBFS on mipsel: symbol changes

[Szczepan Zalega | Nitrokey]

On 4/20/20 2:59 PM, Ivo De Decker wrote:
> package: src:libnitrokey
> version: 3.4.1-4
> severity: serious
> tags: ftbfs
> 
> A binnmu of libnitrokey on mipsel (to bring the versions in sync for
> multiarch) failed:
> 
> https://buildd.debian.org/status/package.php?p=libnitrokey
> 
> Note that only mipsel was rebuilt (because the binNMU version was lower), so
> it's possible that this issue isn't limited to mipsel.
> 

Hi!

I do not have much experience in this kind of errors, but for me from
the symbols diff it looks like the change comes from building with C++17
standard set (is it not now the default for GCC?). CMake has it set to
C++14 and units are built with it as far as I see, yet the C++17
prefixed symbol is shown:
```
-
(optional=templinst)_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_M_constructIPKcEEvT_S8_St20forward_iterator_tag@Base
3.4.1
+
_ZNSt6vectorIhSaIhEE17_M_realloc_insertIJhEEEvN9__gnu_cxx17__normal_iteratorIPhS1_EEDpOT_@Base
3.4.1-4+b1
```

-- 
Best regards,
Szczepan

Bug#958339: dh_shlibdeps: Generate lockstep dependencies within a source package

[Simon McVittie]

Package: debhelper
Version: 13
Severity: wishlist

We recently had some crash bugs reported against GNOME (#958017, #958025)
which turned out to involve a minimal partial upgrade from stable to
testing/unstable.

On one hand, partial upgrades from stable to testing/unstable need to
be at least vaguely supported (working well enough to run maintainer
scripts), because they will exist as transitional states during a full
upgrade (in particular, from oldstable to stable after the testing
distribution gets released) - so if particular combinations of packages
that can't work together are identified, then that's a bug, and in
principle we should fix it, either by tightening positive and negative
dependencies (mainly Depends and Breaks) or by changing code to make it
more tolerant.

On the other hand, arbitrary partial upgrades from stable to
testing/unstable are not feasible to support with finite developer
effort available, because there's a combinatorial explosion of possible
combinations of packages. So, pragmatically, we should not encourage
users to perform partial upgrades, and the majority of bugs of that
class will go undetected and unfixed.

One type of partial upgrade that is particularly problematic (which did
happen in the case of #958017) is if the user selects some but not all
of the binary packages built by a source package for upgrade. This is
not something that the upstream developers of a package are ever going
to support, and I don't think it's something that Debian should make any
attempt to support either, because it's very common for interdependent
binary packages from the same source to "know" that they are installed
with matching versions, and make use of assumptions or implementation
details that are outside the package's public interface.

pango in #958017 was a good example: the various libraries built by
src:pango1.0 share headers like pango/pango-fontset-private.h, and will
crash if they don't all agree on the struct layouts in those headers.

I've fixed this in src:pango1.0 (and several other GNOME libraries,
not uploaded yet) by adding a d/shlibs.local that gives the libraries
lockstep dependencies on each other, but I can't help thinking this is
something that debhelper could be doing for us.

Two implementation options spring to mind:
- generate a shlibs.local (possibly by altering an existing,
  hand-written shlibs.local) and pass that to dpkg-shlibdeps -L;
- postprocess the dpkg-shlibdeps output to convert
  LIBNAME (>= x) into LIBNAME (= ${binary:Version}) for each
  LIBNAME that is a binary package built by this source

Does this seem a reasonable debhelper feature?

Thanks,
smcv

Bug#877232: u-boot-rockchip: u-boot-spl-dtb.bin missing

[Vagrant Cascadian]

Control: tags 877232 moreinfo

On 2017-09-29, Heinrich Schuchardt wrote:
> On 09/29/2017 09:26 PM, Vagrant Cascadian wrote:
>> On 2017-09-29, Heinrich Schuchardt wrote:
>>> usr/share/doc/u-boot-rockchip/README.rockchip.gz asks for copying
>>> u-boot-spl-dtb.bin to the SD card.
>>> 
>>> File /usr/lib/u-boot/firefly-rk3399/spl/u-boot-spl-dtb.bin is not
>>> provided by the package.
>> 
>> It's identical to u-boot-spl.bin, as of a few releases ago. I think
>> the logic was to default to the dtb variant if the platform
>> supports dtb, since that's what is actually needed in most cases.
>> 
>> 
>>> So either some documentation for RK3399 should be added or a file
>>> is missing.
>> 
>> I'm guessing the upstream documentation needs a minor update. There
>> are probably other README files in a similar situation.
...
> Yes you are right this is the relevant command in U-Boot:
> cmd_spl/u-boot-spl.bin := cp spl/u-boot-spl-dtb.bin spl/u-boot-spl.bin

While README.rockchip still still contains references to
u-boot-spl-dtb.bin, the README.Debian now documents using idbloader.img,
which seems to be consistantly used across most rockchip platforms.

Is that sufficient, or should this bug stay open?


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#958304: Can not make Epson L1800 work

[wglxy]

Hello, the epson-inkjet-printer-201312w need LSB which is abandoned by Debian. 
So it is not be used in Debian 10. Would you please tell me how to use the 
epson-inkjet-printer-201312w in Debian without LSB?




Thank you very much!






Best regards,
Gulfstream

Bug#956848: ncbi-blast+-legacy: Please provide /usr/bin/blastpgp.pl (including .pl extension)

[Aaron M. Ucko]

"Aaron M. Ucko"  writes:

> I've attached a full patch.

Extended to cover calls to blastall, which is also a legacy entry point.
(I left blast_msa_old's call as is, since it's untranslatable without
the crucial -p argument, and nothing calls that subroutine anyway.)

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

--- a/example/tc_generic_method.pl
+++ b/example/tc_generic_method.pl
@@ -688,7 +688,7 @@ sub blast_msa
 
 
 #_system ("formatdb -i $db");
-if ($blast eq "blastp"){_system  ("blastall -i $infile -d $db -m7 -p blastp -o io");}
+if ($blast eq "blastp"){_system  ("blastp -db $db -query $infile -out io -outfmt 5 -seg yes");}
 elsif ($blast eq "blastn"){_system  ("blastn -query $infile -db $db -outfmt 5 -word_size 4 -out io");}
 
 _blast_type ("io");
@@ -1183,7 +1183,7 @@ sub pg_is_installed
 	if ($r eq ""){$r=0;}
 	else {$r=1;}
 
-	if ($r==0 && is_blast_package ($p)){return pg_is_installed ("legacy_blast.pl");}
+	if ($r==0 && is_blast_package ($p)){return pg_is_installed ("blastn");}
 	else {return $r;}
   }
   }
@@ -2597,7 +2597,7 @@ sub run_blast
 	_configuration ("blastall");
 	if ($method eq "blastp")
 	  {
-		$command="blastall -d $db -i $infile -o $outfile -m7 -p blastp";
+		$command="blastp -db $db -query $infile -out $outfile -outfmt 5 -seg yes";
 	  }
 	_system ($command);
 	  }
@@ -2611,26 +2611,20 @@ sub run_blast
 			$cl_db=$db;
 	}
 
-##
 		## BLAST+ provide different binaries names and CLI options
-		## Use the 'legacy_blast.pl' to keep compatibility with old blast commands
-		##
-		$path=`which legacy_blast.pl 2>/dev/null`;  
-		$path=`dirname $path`; 
-		chomp($path);
 	if ($method eq "blastp"){
-			_configuration("legacy_blast.pl");
-			$command="legacy_blast.pl blastpgp --path $path -d $cl_db -i $infile -o $outfile -m7 -j1";
+			_configuration("psiblast");
+			$command="psiblast -db $cl_db -query $infile -num_iterations 1 -out $outfile -outfmt 5";
 	}
 	elsif ($method eq "psiblast")
 	  {
-		_configuration("legacy_blast.pl");
-		$command="legacy_blast.pl blastpgp --path $path -d $cl_db -i $infile -o $outfile -m7 -j5";
+		_configuration("psiblast");
+		$command="psiblast -db $cl_db -query $infile -num_iterations 5 -out $outfile -outfmt 5";
 	  }
 	elsif ($method eq "blastn")
 	  {
-		_configuration("legacy_blast.pl");
-		$command="legacy_blast.pl blastall --path $path -p blastn -d $cl_db -i $infile -o $outfile -m7 -W6";
+		_configuration("blastn");
+		$command="blastn -task blastn -db $cl_db -query $infile -word_size 6 -out $outfile -outfmt 5";
 	  }
 	print "$command\n";
 	_system ($command);
@@ -2859,7 +2853,7 @@ sub seq2tblastx_lib
   }
 close (F);
 _system ("formatdb -i infile -p F");
-_system ("blastall -p tblastx -i infile -d infile -m 7 -S1>blast.output");
+_system ("tblastx -db infile -query infile -out blast.output -outfmt 5");
 
 ncbi_tblastx_xml2lib_file ("outfile", file2string ("blast.output"));
 _temporary_dir ("unset",$mode, $method, "outfile",$outfile);
@@ -2890,7 +2884,7 @@ sub seq2tblastpx_lib
 close (F);
 _system("t_coffee -other_pg seq_reformat -in infile -output tblastx_db1 > tblastxdb");
 _system ("formatdb -i tblastxdb -p T");
-_system ("blastall -p blastp -i tblastxdb -d tblastxdb -m7 >blast.output");
+_system ("blastp -db tblastxdb -query tblastxdb -out blast.output -outfmt 5");
 ncbi_tblastpx_xml2lib_file ("outfile", file2string ("blast.output"), %s);
 _temporary_dir ("unset",$mode, $method, "outfile",$outfile);
 myexit ($EXIT_SUCCESS);

Bug#934986: u-boot-sunxi for orange pi one

[Vagrant Cascadian]

Control: severity 934986 wishlist
Control: tags 934986 moreinfo

live well,
  vagrant

On 2019-08-17, Vagrant Cascadian wrote:
> On 2019-08-17, ronwirr...@safe-mail.net wrote:
>> Package: u-boot-sunxi
>> Version: 2018.05+dfsg-1
>
> That's a curious version to report against at this point in time;
> current debian buster/stable has 2019.01, stretch/oldstable has 2016.11,
> and experimental has 2019.07.
>
>
>> https://packages.debian.org/sid/armhf/u-boot-sunxi/filelist
>> Get orange pi one on the list.
>
> Are you able to test future versions on an ongoing basis? Please read:
>
>   https://wiki.debian.org/U-boot/
>
>
> There's both the orangepi_one (H3, armhf) target and the
> orangepi_one_plus (H6, arm64). Which do you have?
>
> If it's the orangepi_one, Adding to:
>
>   https://salsa.debian.org/debian/u-boot/blob/master/debian/targets
>
> # ronwirr...@safe-mail.net
> armhf sunxi   orangepi_oneu-boot-sunxi-with-spl.bin
>
>
> If it's the orangepi_one_plus model, you may also need to update
> arm-trusted-firmware and the u-boot-install-sunxi64 script.
>
> It should be possible to get into unstable soon, and maybe a debian
> buster/stable point release if you can do thorough testing.
>
> live well,
>   vagrant


signature.asc
Description: PGP signature

Bug#956922: ITP: fsverity -- Userspace utilities for fs-verity

[Romain Perier]

On Fri, Apr 17, 2020 at 07:55:17PM +0200, Romain Perier wrote:
> Bastien : why not , I am opened to suggestions.
> 
> Lucas: thanks for your proposal and your feedbacks. I will fix this and I
> will keep you in touch.
> 
> Regards,
> Romain

Hi,


Lucas: Everything should be fixed in
https://salsa.debian.org/rperier-guest/fsverity-utils. All the current
patches will be sent on upstream.

Thanks,
Regards,
Romain

> 
> Le ven. 17 avr. 2020 à 13:29, Bastien ROUCARIES 
> a écrit :
> 
> > On Thu, Apr 16, 2020 at 9:18 PM Romain Perier 
> > wrote:
> > >
> > > Package: wnpp
> > > Severity: wishlist
> > > Owner: Romain Perier 
> > >
> > > * Package name: fsverity
> > >   Version : 1.0
> > >   Upstream Author : Eric Biggers 
> > > * URL :
> > https://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/fsverity-utils.git
> > > * License : GPL
> > >   Programming Lang: C
> > >   Description : Userspace utilities for fs-verity
> > >
> > > This is fsverity, a userspace utility for fs-verity. fs-verity is a
> > Linux kernel
> > > feature that does transparent on-demand integrity/authenticity
> > verification of
> > > the contents of read-only files, using a hidden Merkle tree (hash tree)
> > associated
> > > with the file. The mechanism is similar to dm-verity, but implemented at
> > the file
> > > level rather than at the block device level. The fsverity utility allows
> > you to
> > > set up fs-verity protected files.
> > >
> > > This package will be helpful for handling the fsverity feature on a file
> > from
> > > userspace.
> > >
> > > I want to maintain this package. As DM, I need someone for the initial
> > upload.
> > > Packaging is currently hosted here
> > https://salsa.debian.org/rperier-guest/fsverity,
> > > and will be developed at https://salsa.debian.org/debian/fsverity
> >
> > I can. Do you plan also to support it under debian install (maybe also
> > dm-verify/dm-integrity)
> >
> > Bastien
> >


signature.asc
Description: PGP signature

Bug#958336: Updating the python-debian Uploaders list

[Adeo Simó]

I submitted the following before retiring:

https://salsa.debian.org/python-debian-team/python-debian/-/merge_requests/20

On Mon, Apr 20, 2020 at 1:33 PM Mattia Rizzolo  wrote:

> Source: python-debian
> Version: 0.1.37
> Severity: minor
> User: m...@qa.debian.org
> Usertags: mia-teammaint
>
> Adeodato Simó  has retired, so can't work on
> the python-debian package anymore (at least with this address).
>
> We are tracking their status in the MIA team and would like to ask you
> to remove them from the Uploaders list of the package so we can close
> that part of the file.
>
> (If the person is listed as Maintainer, what we are asking is to please
> step in as a new maintainer.)
>
> Thanks.
>
> --
> regards,
> Mattia Rizzolo
>
> GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
> More about me:  https://mapreri.org : :'  :
> Launchpad user: https://launchpad.net/~mapreri  `. `'`
> Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-
>

Bug#958027: CVE-2020-11868 affecting ntpsec?

[Moritz Muehlenhoff]

On Mon, Apr 20, 2020 at 11:39:14AM -0500, Richard Laager wrote:
> forwarded 958027 https://gitlab.com/NTPsec/ntpsec/issues/651
> 
> Two key upstream developers have said this does not affect NTPsec.

Thanks, I'll update the Debian Security Tracker.

Cheers,
Moritz

Bug#958338: ITP: libsub-handlesvia-perl -- alternative handles_via implementation for Moo, Moose, and more

[intrigeri]

Package: wnpp
Owner: intrigeri 
Severity: wishlist
X-Debbugs-CC: debian-p...@lists.debian.org

* Package name: libsub-handlesvia-perl
  Version : 0.013
  Upstream Author : Toby Inkster (TOBYINK) 
* URL : https://metacpan.org/release/Sub-HandlesVia
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : alternative handles_via implementation for Moo, Moose, and 
more

If you've used Moose's native attribute traits, or MooX::HandlesVia before,
you should have a fairly good idea what Sub::HandlesVia does.

Why re-invent the wheel? Well, this is an implementation that should work
okay with Moo, Moose, Mouse, and any other OO toolkit you throw at it. One
ring to rule them all, so to speak.

Also, unlike MooX::HandlesVia, it honours type constraints, plus it doesn't
have the limitation that it can't mutate non-reference values.

The package will be maintained under the umbrella of the Debian Perl Group.

It's a new dependency of recent libmoox-late-perl, which is in the
archive already.

Bug#958337: libxfont-dev: depend on x11proto-dev instead of x11proto-core-dev, x11proto-fonts-dev

[Jörg-Volker Peetz]

Package: libxfont-dev
Version: 1:2.0.3-1
Severity: wishlist

Dear Debian X Strike Force,

the dependency on x11proto-core-dev and x11proto-fonts-dev should be replaced by
dependency on x11proto-dev.

Regards,
Jörg.