Bug#721197: RFP: minetest-mod-technic -- Minetest mod - Technic

[Phil Morrell]

I mainly want to note that this package is still desired and provide
information from the new ContentDB:

https://content.minetest.net/packages/RealBadAngel/technic/

#1 most popular mod by downloads

Required Dependencies
✓ basic_materials
✓ default (minetest-data)
✓ pipeworks

Optional Dependencies
✓ intllib
✓ mesecons
✓ moreblocks
✓ moreores
✓ unified_inventory
✓ unifieddyes
* bucket
* digiline_remote
* digilines
* mesecons_mvp
* mg
* screwdriver
* vector_extras

All required dependencies are packaged, which means the zip file from
ContentDB can be used as-is in the mod directory.


signature.asc
Description: PGP signature

Bug#934960: closed by Ondřej Nový (Bug#934960: fixed in pytest-mock 1.10.4-1)

[Paul Gevers]

Hi Ondřej,

On 24-08-2019 19:27, Debian Bug Tracking System wrote:
>  pytest-mock (1.10.4-1) unstable; urgency=medium
>  .
>* Team upload.
>* New upstream release (Closes: #904304).

Was this bug only an issue in the autopkgtest, or was it causing an
issue in pytest-mock? In the former case, a *versioned* test dependency
would have helped the system to pick the right combination for testing.
In the latter case, a *versioned* normal dependency is missing. If it's
a test issue only, you can either fix it with a new upload (preferred),
or tell me and I'm willing to help the system test the combination.

>* d/control: Remove ancient X-Python3-Version field
>* Use debhelper-compat instead of debian/compat.
>* Fix compatibility with newer Python, python-mock and pytest
>  (Closes: #934960).
>* Bump standards version to 4.4.0 (no changes).
>* Bump debhelper compat level to 12.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#935677: ganeti-2.16: Depends on to be removed packages (python2/python-ipaddr specifically)

[Scott Kitterman]

Package: ganeti-2.16
Version: 2.16.0-5
Severity: serious
Justification: Policy 2.5

As you may have heard, the plan is to remove python2 for the bullseye
release.  As part of that effort, the python teams are working on
removing as much of the python2 stack as early as we can.  As part of
that effort, I've asked to have my package python-ipaddr removed (since
it is python2 only).

This package depends on python-ipaddr and needs to be updated.

It doesn't appear to me that upstream supports python3 yet, so I don't
know what exactly to suggest for this release cycle.  For the short
term, you can probable switch to using python-ipaddress as the API is
almost identical.

Scott K

Bug#935676: ganeti-2.15: Depends on to be removed packages (python2/python-ipaddr specifically)

[Scott Kitterman]

Source: ganeti-2.15
Version: 2.15.2-15
Severity: serious
Justification: Policy 2.5

As you may have heard, the plan is to remove python2 for the bullseye
release.  As part of that effort, the python teams are working on
removing as much of the python2 stack as early as we can.  As part of
that effort, I've asked to have my package python-ipaddr removed (since
it is python2 only).

This package depends on python-ipaddr and needs to be updated.

It doesn't appear to me that upstream supports python3 yet, so I don't
know what exactly to suggest for this release cycle.  For the short
term, you can probable switch to using python-ipaddress as the API is
almost identical.

Scott K

Bug#927131: src:grr: Please port to python3

[Scott Kitterman]

On Mon, 15 Apr 2019 08:40:09 -0400 Scott Kitterman  
wrote:
> Package: src:grr
> Version: 3.1.0.2+dfsg-6
> Severity: important
> 
> Python2.7 will go out of upstream security support during the Bullseye
> development cycle.  It is not safe to assume it will be included in the
> next release, so if you want to be sure grr can stay in Debian, please port
> it to python3 (I see there are upstream commits for a python3 port, but no
> release yet).
> 
> Personally, I want to remove some packages I maintain, particularly python-
> ipaddr, which grr depends on during the Bullseye cycle, regardless of what
> happens to python2.7, so please update (python3 includes the ipaddress 
module,
> which was developed from ipaddr, in the standard library).
> 
> I'm aware there are complications in updating to a newer release.  I figure
> early notice is better than late.

Bumping to serious now that python-ipaddr removal has been requested.  If you 
have lost interest in the package, please let me know and I'll ask to have it 
removed.

Scott K

Bug#927132: src:hash-slinger: Please port to python3

[Scott Kitterman]

On Mon, 15 Apr 2019 08:45:59 -0400 Scott Kitterman  
wrote:
> Package: src:hash-slinger
> Version: 2.7-1
> Severity: important
> 
> Python2.7 will go out of upstream security support during the Bullseye
> development cycle.  It is not safe to assume it will be included in the
> next release, so if you want to be sure hash-slinger can stay in Debian,
> please port it to python3.  I see upstream suddendly did a new release
> after three years, so maybe an upstream port will appear.
> 
> Personally, I want to remove some packages I maintain, particularly python-
> ipaddr, which hash-slinger depends on during the Bullseye cycle, regardless 
of
> what happens to python2.7, so please update (python3 includes the ipaddress
> module, which was developed from ipaddr, in the standard library).

Bumping to serious now that python-ipaddr has been requested for removal.

Please let me know if you have lost interest in the package.  If so, I will 
ask for it to be removed.

Scott K

Bug#927135: src:rekall: Please update to python3 version

[Scott Kitterman]

On Mon, 15 Apr 2019 08:52:16 -0400 Scott Kitterman  
wrote:
> Package: src:rekall
> Version: 1.6.0+dfsg-2
> Severity: important
> 
> Python2.7 will go out of upstream security support during the Bullseye
> development cycle.  It is not safe to assume it will be included in the
> next release, so if you want to be sure rekall can stay in Debian, please
> update it to the python3 version available from upstream..
> 
> Personally, I want to remove some packages I maintain, particularly python-
> ipaddr, which rekall depends on during the Bullseye cycle, regardless of 
what
> happens to python2.7, so please update (python3 includes the ipaddress 
module,
> which was developed from ipaddr, in the standard library).

Bumping to serious as python-ipaddr has been requested for removal.

If you have lost interest in the package, please let me know so I can ask to 
have it removed.

Scott K

Bug#927136: src:zabbix-cli: Please update to python3

[Scott Kitterman]

On Mon, 15 Apr 2019 08:56:40 -0400 Scott Kitterman  
wrote:
> Package: src:zabbix-cli
> Version: 1.7.0-1
> Severity: important
> 
> Python2.7 will go out of upstream security support during the Bullseye
> development cycle.  It is not safe to assume it will be included in the
> next release, so if you want to be sure zabbix-cli can stay in Debian, 
please
> update it to the python3 version available from upstream..
> 
> Personally, I want to remove some packages I maintain, particularly python-
> ipaddr, which zabbix-cli depends on during the Bullseye cycle, regardless of
> what happens to python2.7, so please update (python3 includes the ipaddress
> module, which was developed from ipaddr, in the standard library).

Bumping to serious because python-ipaddr will be removed soon.  Upstream 
support python3.  Please update to a new version or ack that you've lost 
interest in the package and I'll ask to have it removed.

Scott K

Bug#935675: RM: criu -- RoQA; Obsolete libs (Python2)

[Scott Kitterman]

Package: ftp.debian.org
Severity: normal

Note that this package is currently maintained in experimental, so
unstable rm is ack'ed by the maintainer.  It will come back to unstable
later (with python3 support).

Scott K

Bug#935674: librust-blake2-rfc+clippy-dev/amd64 unsatisfiable Depends: librust-clippy-0.0.41+default-dev

[Steve Langasek]

Source: rust-blake2-rfc
Version: 0.2.18-2
Severity: serious
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu eoan

The rust-blake2-rfc package generates a binary package that appears to
depend on rust-clippy, but there is no rust-clippy package in the archive
(or in the new queue).

librust-blake2-rfc+clippy-dev/amd64 unsatisfiable Depends: 
librust-clippy-0.0.41+default-dev

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


signature.asc
Description: PGP signature

Bug#935673: rust-ring depends on out-of-date rust-untrusted

[Steve Langasek]

Source: rust-ring
Version: 0.14.6-1
Severity: serious
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu eoan

The rust-ring package is uninstallable, because it depends on a version of
rust-untrusted that is older than what's in unstable:

 librust-ring-dev : Depends: librust-untrusted-0.6+default-dev (>= 0.6.2-~~) 
but it is not installable

rust-untrusted is at version 0.7.0.  So rust-ring needs to be updated.

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


signature.asc
Description: PGP signature

Bug#935672: librust-backtrace+addr2line-dev/amd64 unsatisfiable Depends: librust-addr2line-0.9+std-dev

[Steve Langasek]

Source: rust-backtrace
Version: 0.3.34-1
Severity: serious
Affects: src:rust-addr2line
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu eoan

The rust-backtrace package depends on a newer rust-addr2line than is
available in the Debian archive.

librust-backtrace+addr2line-dev/amd64 unsatisfiable Depends: 
librust-addr2line-0.9+std-dev

Only rust-addr2line 0.7 is currently available.

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


signature.asc
Description: PGP signature

Bug#935671: librust-rle-decode-fast+bench-dev/amd64 unsatisfiable Depends: librust-criterion-0.2+default-dev

[Steve Langasek]

Source: rust-rle-decode-fast
Version: 1.0.1-1
Severity: serious
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu eoan

The rust-rle-decode-fast package generates two binary packages that appear
to depend on rust-criterion, but there is no rust-criterion package in the
archive (or in the new queue).

librust-rle-decode-fast+bench-dev/amd64 unsatisfiable Depends: 
librust-criterion-0.2+default-dev
librust-rle-decode-fast+criterion-dev/amd64 unsatisfiable Depends: 
librust-criterion-0.2+default-dev

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


signature.asc
Description: PGP signature

Bug#935640: running 'firehol restart' does not always reproduce ruleset

[Jerome BENOIT]

Hello Toni,

I guess that your issue is related to FireHOL issue #352:
https://github.com/firehol/firehol/issues/352

This issue seems to cause a lot of trouble.
It is related to the new iptable-{legacy,nft}.
FireHOL does not yet support iptable-nft.
In the last Debian package, FireHOL is forced to use the -legacy tools.
See the comment by FabioPedretti on Nov 8, 2018.

The issue seems to appear on at upgrade stage: on my own box, rebooting was 
sufficient.
I agree to say that the upgrade should be smoother.
Any idea on how to deal with this issue is welcome.

Cheers,
Jerome


-- 
Jerome BENOIT | calculus+at-rezozer^dot*net
https://qa.debian.org/developer.php?login=calcu...@rezozer.net
AE28 AE15 710D FF1D 87E5  A762 3F92 19A6 7F36 C68B



signature.asc
Description: OpenPGP digital signature

Bug#935670: gamemode: Unable to set the 'CPU govenor' and 'GPU Optimisations'

[Robert]

Package: gamemode
Version: 1.5~git20190722.4ecac89-1
Severity: normal
Tags: upstream

Dear Maintainer,

gamemode is not able to set the 'CPU govenor' and 'GPU Optimisations'.


Aug 25 05:29:21  /usr/bin/gamemoded[4352]: Adding game: 4836
[/usr/bin/env]
Aug 25 05:29:21  /usr/bin/gamemoded[4352]: Entering Game Mode...
Aug 25 05:29:21  /usr/bin/gamemoded[4352]: governor was initially set
to [powersave]
Aug 25 05:29:21  /usr/bin/gamemoded[4352]: Requesting update of
governor policy to performance
Aug 25 05:29:21  gamemoded[4352]: Error accessing
/usr/libexec/cpugovctl: No such file or directory
Aug 25 05:29:21  /usr/bin/gamemoded[4352]: External process failed
with exit code 127
Aug 25 05:29:21  /usr/bin/gamemoded[4352]: Output was:
Aug 25 05:29:21  /usr/bin/gamemoded[4352]: Failed to update cpu
governor policy
Aug 25 05:29:21  /usr/bin/gamemoded[4838]: Failed to execute external
process: /usr/libexec/gpuclockctl No such file or directory
Aug 25 05:29:21  /usr/bin/gamemoded[4352]: External process failed
with exit code 1
Aug 25 05:29:21  /usr/bin/gamemoded[4352]: Output was:
Aug 25 05:29:21  /usr/bin/gamemoded[4352]: Failed to call
gpuclockctl, could not get values!
Aug 25 05:29:21  /usr/bin/gamemoded[4352]: Requesting GPU
optimisations on device:1
Aug 25 05:29:21  gamemoded[4352]: Error accessing
/usr/libexec/gpuclockctl: No such file or directory
Aug 25 05:29:21  /usr/bin/gamemoded[4352]: External process failed
with exit code 127
Aug 25 05:29:21  /usr/bin/gamemoded[4352]: Output was:
Aug 25 05:29:21  /usr/bin/gamemoded[4352]: Failed to call
gpuclockctl, could not apply optimisations!
Aug 25 05:29:21  /usr/bin/gamemoded[4352]: Setting ioprio value...
Aug 25 05:29:21  /usr/bin/gamemoded[4352]: Addition requested for
already known client 4836 [/usr/bin/env].
-- This may happen due
to using exec or shell wrappers. You may want to
-- blacklist this
client so GameMode can see its final name here.
Aug 25 05:29:21  /usr/bin/gamemoded[4352]: Adding game: 4842
[/usr/bin/xargs]
Aug 25 05:29:21  /usr/bin/gamemoded[4352]: Setting ioprio value...
Aug 25 05:29:21  /usr/bin/gamemoded[4352]: Skipping ioprio on client
[4842,4842]: ioprio was (0) but we expected (4)
Aug 25 05:29:21  /usr/bin/gamemoded[4352]: Adding game: 4843
[/bin/readlink]
Aug 25 05:29:21  /usr/bin/gamemoded[4352]: Setting ioprio value...
Aug 25 05:29:21  /usr/bin/gamemoded[4352]: Skipping ioprio on client
[4843,4843]: ioprio was (0) but we expected (4)
Aug 25 05:29:21  /usr/bin/gamemoded[4352]: Removing game: 4843
[/bin/readlink]
Aug 25 05:29:21  /usr/bin/gamemoded[4352]: Setting ioprio value...
Aug 25 05:29:21  /usr/bin/gamemoded[4352]: Removing game: 4842
[/usr/bin/xargs]
Aug 25 05:29:21  /usr/bin/gamemoded[4352]: Setting ioprio value...
Aug 25 05:29:21  /usr/bin/gamemoded[4352]: Adding game: 4844
[/usr/bin/dirname]
Aug 25 05:29:21  /usr/bin/gamemoded[4352]: Setting ioprio value...
Aug 25 05:29:21  /usr/bin/gamemoded[4352]: Skipping ioprio on client
[4844,4844]: ioprio was (0) but we expected (4)
Aug 25 05:29:21  /usr/bin/gamemoded[4352]: Removing game: 4844
[/usr/bin/dirname]
Aug 25 05:29:21  /usr/bin/gamemoded[4352]: Setting ioprio value...
Aug 25 05:29:21  /usr/bin/gamemoded[4352]: Adding game: 4845
[/bin/chmod]
Aug 25 05:29:21  /usr/bin/gamemoded[4352]: Setting ioprio value...
Aug 25 05:29:21  /usr/bin/gamemoded[4352]: Skipping ioprio on client
[4845,4845]: ioprio was (0) but we expected (4)
Aug 25 05:29:21  /usr/bin/gamemoded[4352]: Removing game: 4845
[/bin/chmod]
Aug 25 05:29:21  /usr/bin/gamemoded[4352]: Setting ioprio value...
Aug 25 05:29:22  /usr/bin/gamemoded[4352]: Adding game: 4846
[/mnt/M4-CT256M4SSD2/spiele/steamapps/common/Tropico
6/Tropico6/Binaries/Linux/Tropico6-Linux-Shipping]
Aug 25 05:29:22  /usr/bin/gamemoded[4352]: Setting ioprio value...
Aug 25 05:29:22  /usr/bin/gamemoded[4352]: Skipping ioprio on client
[4846,4846]: ioprio was (0) but we expected (4)
Aug 25 05:29:22  /usr/bin/gamemoded[4352]: Adding game: 4861
[/bin/dash]
Aug 25 05:29:22  /usr/bin/gamemoded[4352]: Setting ioprio value...
Aug 25 05:29:22  /usr/bin/gamemoded[4352]: Skipping ioprio on client
[4861,4861]: ioprio was (0) but we expected (4)
Aug 25 05:29:22  /usr/bin/gamemoded[4352]: Adding game: 4862
[/bin/dash]
Aug 25 05:29:22  /usr/bin/gamemoded[4352]: Setting ioprio value...
Aug 25 05:29:22  /usr/bin/gamemoded[4352]: Skipping ioprio on client
[4862,4862]: ioprio was (0) but we expected (4)
Aug 25 05:29:26  /usr/bin/gamemoded[4352]: Removing expired game
[4862]...
Aug 25 05:29:26  /usr/bin/gamemoded[4352]: Removing game: 4862
[/bin/dash]
Aug 25 05:29:26  /usr/bin/gamemoded[4352]: Setting ioprio value...
Aug 25 05:29:26  /usr/bin/gamemoded[4352]: Could not inspect tasks
for client [4862]! Skipping ioprio optimisation.
Aug 25 05:29:26  /usr/bin/gamemoded[4352]: Removing expired game
[4861]...
Aug 25 05:29:26  /usr/bin/gamemoded[4352]: Removing game: 4861

Bug#934989: openjdk-11-jre: Performance of JDK11/12 is 10%-15% worse than JDK8

[tony mancill]

On Sun, Aug 18, 2019 at 04:54:52PM +0200, Erich Schubert wrote:
> Hi,
> 
> To reproduce the experiments, get the (older than what I used) ELKI
> standalone jar here:
> 
> https://elki-project.github.io/releases/release0.7.5/elki-bundle-0.7.5.jar
>
> (snip)
>
> A suitable command line is:
> 
> taskset -c 0 $JAVA_HOME/bin/java \
> -jar elki-bundle-0.7.5.jar \
> cli -time -dbc.in aloi-hsb-2x2x2.csv.gz \
> -algorithm clustering.DBSCAN -dbscan.minpts 20 -dbscan.epsilon 0.01 \
> -evaluator NoAutomaticEvaluation -resulthandler DiscardResultHandler
> 
> the "cli" command runs this headless; the "-time" parameter enables a
> minimal output of statistics. The last two parameter disable the
> (unnecessary for this purpose) evaluation and result output. tasksets forces
> this to use only the first CPU (except for the garbage collection,
> everything is single-threaded in this call).

I have been able to reproduce the "Java 8 is faster than Java 11"
results initially reporting using the ALOI datasets from [1].  However,
I have also seen Java 11 outperform Java 8 (by 4-5%) using the same
command-line invocation of ELKI against a different dataset [2].  This
isn't intended to refute your findings but to suggest that there could
be other factors.  Perhaps the performance difference depends on
specific aspects of the workload - e.g., whether there is more pressure
on the memory subsystem than CPU (or something like that).

Each of these are run on Debian sid (3) times on an otherwise quiet
system; the results below are representative (for all runs, JDK 11 was
faster on my system with this dataset):

#
# Java 8 
# OpenJDK 64-Bit Server VM (build 25.222-b10, mixed mode)
#
elki taskset -c 0 /usr/lib/jvm/java-8-openjdk-amd64/bin/java \
-jar elki-bundle-0.7.5.jar \
cli -time -dbc.in data/Range-Queries-Aggregates.csv \ 
-algorithm clustering.DBSCAN -dbscan.minpts 20 -dbscan.epsilon 1 \
-evaluator NoAutomaticEvaluation -resulthandler DiscardResultHandler
de.lmu.ifi.dbs.elki.datasource.FileBasedDatabaseConnection.load: 829 ms
de.lmu.ifi.dbs.elki.algorithm.clustering.DBSCAN.average-neighbors: 1.0
There are very few neighbors found. Epsilon may be too small.
de.lmu.ifi.dbs.elki.algorithm.clustering.DBSCAN.runtime: 513229 ms

#
# Java 11
# OpenJDK 64-Bit Server VM (build 11.0.4+11-post-Debian-1, mixed mode)
#
elki taskset -c 0 /usr/lib/jvm/java-11-openjdk-amd64/bin/java \
-jar elki-bundle-0.7.5.jar \
cli -time -dbc.in data/Range-Queries-Aggregates.csv \
-algorithm clustering.DBSCAN -dbscan.minpts 20 -dbscan.epsilon 1 \
-evaluator NoAutomaticEvaluation -resulthandler DiscardResultHandler
de.lmu.ifi.dbs.elki.datasource.FileBasedDatabaseConnection.load: 864 ms
de.lmu.ifi.dbs.elki.algorithm.clustering.DBSCAN.average-neighbors: 1.0
There are very few neighbors found. Epsilon may be too small.
de.lmu.ifi.dbs.elki.algorithm.clustering.DBSCAN.runtime: 490520 ms

So, this is to be continued...
In any event, thank you for bringing this benchmark to the list.

Cheers,
tony

[1] https://www.dbs.ifi.lmu.de/research/outlier-evaluation/input/ALOI.tar.gz
[2] http://archive.ics.uci.edu/ml/datasets/Query+Analytics+Workloads+Dataset


signature.asc
Description: PGP signature

Bug#935568: sphinx-issuetracker: should this package be removed?

[Sandro Tosi]

On Sat, Aug 24, 2019 at 12:59 PM Dmitry Shachnev  wrote:
>
> Hi Sandro!
>
> On Fri, Aug 23, 2019 at 10:46:30PM -0400, Sandro Tosi wrote:
> > Hello,
> > sphinx-issuetracker is currently incompatible with python3.7:
> > [...]
> >
> > It has no reverse-dependencies and it's currently one of the few r-deps of
> > python-debianbts.
> >
> > Should we just remove this package from Debian?
>
> I support the removal.
>
> However, there is one reverse build-dependency: src:migrate.

i checked on dak and it reports no rdeps, either binary or source:

```
$ dak rm -Rn -b python-sphinxcontrib.issuetracker
Will remove the following packages from unstable:

python-sphinxcontrib.issuetracker | 0.11-2 | all

Maintainer: Debian Python Modules Team


--- Reason ---

--

Checking reverse dependencies...
No dependency problem found.
```

> But it looks like use of issuetracker is actually patched away:
> https://sources.debian.org/src/migrate/0.12.0-3/debian/patches/disable_issuetracker.patch/
>
> Dear migrate maintainers (Cc'ed), can you please check if that
> build-dependency is still needed?

it's possible `migrate` used to depend on
python-sphinxcontrib.issuetracker but that's no longer the case, i
think?

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
G+: https://plus.google.com/u/0/+SandroTosi

Bug#935669: assaultcube-data: Outdated version makes assaultcube uninstallable

[Guillem Jover]

Package: assaultcube-data
Version: 1.1.0.4+repack1-2.1
Severity: serious

Hi!

The assaultcube package got updated to version 1.2.0.2.1-1, but the
matching assaultcube-data package has not been uploaded which makes
the former to be currently uninstallable in unstable.

Thanks,
Guillem

Bug#927104: criu: Please update to python3

[Scott Kitterman]

On Saturday, August 24, 2019 5:22:11 AM EDT Salvatore Bonaccorso wrote:
> Contorl: tags -1 + help
> 
> Hi
> 
> At the moment I'm somehow a bit time limited to work on src:criu, but
> not completely lost track. But if someone wants to help here and on
> the FTBFS bug then be my guest, will happily merge proposed changes.
> 
> In any case criu should not block the python2.7 removal, so feel free
> to request removal from unstable at any point it is needed for you.
> 
> I plan at the moment to keep it anyway updated in experimental, as it
> is still before uploading a new version to unstable at all.

I took a brief look at this.  I did not make progress on the FTBFS, so I'm 
unable to test anything, but I can make some suggestions on the Python bits.

At the very least, you'll need the following:

In debian/rules chang with python2 to python3

Add PYTHON="python3" to the install override

In debian control:

Build-depend on python3-all instead of python-all

Drop the depends on python-future and python-ipaddr
Change python-protobuf to python3-protobuf

More generally, there's a missing build-dep on pkg-config.

It looks like upstream supports python3, so that's at least a start.

Scott K

Bug#935243: Does not work with Thunderbird 6x (60+)

[martin f krafft]

Quoting "Mechtilde Stehmann", who wrote on 2019-08-24 at 20:21 Uhr +0200:
you find a new package version 2.3 in experimental. there is thunderbird 
(>=68), too.


Thank you so much! It's working again, though I now need to figure 
out a problem with Radicale.


--
.''`.   martin f. krafft  @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
 `-  Debian - when you have better things to do than fixing systems

a gourmet concerned about calories is like a punter eyeing the clock.


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Bug#935622: libgnuradio-osmosdr0.1.4: Gnuradio 3.8 does not load osmo/rtl blocks

[A. Maitland Bottoms]

Andre Offringa  writes:

> Package: libgnuradio-osmosdr0.1.4
> Version: 0.1.4-14+b10
> Severity: important
>
> Dear Maintainer,
>
> After gnuradio was recently upgraded to 3.8, the blocks provided by
> libgnuradio-osmosdr0.1.4 are no longer available in gnuradio. The gnuradio-
> companion just doesn't show the blocks, and saved gnuradio schemes that 
> include
> an rtl or osmo-source, show a 'Missing Block' instead of the osmo/rtl block,
> and hence no longer work.
>
> The files like /usr/share/gnuradio/grc/blocks/rtlsdr_source.xml are present on
> my system, but for some reason are not loaded by gnuradio-companion. No errors
> are shown when I start gnuradio-companion.
>
> Regards,
> André Offringa

Indeed. Many changes in gnuradio 3.8 - Python3 instead of Python2,
blocks defined in yaml with .yml files instead of .xml files.

This will happen with most gr-* packages. binnmu is not enough.

Lucky for us, there are two people updating gr-osmosdr,
https://github.com/mvaenskae/gr-osmosdr
https://github.com/igorauad/gr-osmosdr
and I will upload new Debian source package soon. (I am awaiting for
some dependencies to get through NEW processing, due to the API/ABI
bumps.)

I hope I can get the various gr-* packages and gqrx-sdr back working
again in Debian testing in time for the gnuradio conference, GRCon, next
month.

For Debian Bullseye, the gnuradio 3.7.x.x are scheduled to be removed
because of the end of Python 2 support. So - 3.8 and progress!

Thank you for your interest in gnuradio and Debian,
-Maitland

Bug#935668: RM: qtwebkit -- RoQA; Obsolete libs (Qt4), unmaintained, security nightmare

[Scott Kitterman]

Package: ftp.debian.org
Severity: normal

All rdepends have either been removed or have pending rm bugs.  We can
finally remove this.

Scott K

Bug#935004: cups-filters: print test page problem solved by upgrading to github version (1.25.1)

[frederik]

Sorry for the delay, I just ran 'sudo apt-get update' and 'sudo apt-get remove 
cups-filters' and 'sudo apt-get install cups cups-filters hplip 
printer-driver-gutenprint printer-driver-hpcups' and I saw that it is trying to 
install the same version of cups-filters as I had reported the bug in. Can you 
explain how I should install the version you uploaded to Debian Unstable? I 
don't often use Debian so I am not familiar with this process.

Also, is there a reason why you think the new version would fix the problem? 
Perhaps since my time is limited and no one else has reported this bug, we 
should regard it as a potential misconfiguration, or an issue that may have 
arisen from my trying to install and then uninstall the Github cups-filters 
package as I explained in my original report.

Thanks!

On Sun, Aug 18, 2019 at 05:27:29PM +0200, Didier 'OdyX' Raboud wrote:

Le dimanche, 18 août 2019, 01.13:46 h CEST frede...@ofb.net a écrit :

Package: cups-filters
Version: 1.21.6-5
Severity: normal

(resending due to email problems on Pi)

Dear Maintainer,

I get the following error when trying to print a test page on my inkjet (via
the web interface):

Print Test Page
Print Test Page HP_Photosmart_Plus_B210_series Error

Unable to print test page:

Unsupported format "text/plain".

I will try to attach the PPD.

The software works fine when I install the latest version of cups-filters
from GitHub. Here is something from error log


I have just uploaded 1.25.2 to Debian unstable; could you try this version,
from the Debian repos?

Cheers,
   OdyX

Bug#935667: RM: pyside-tools -- RoQA; Obsolete libs (Qt4/Python2), unmaintained, replaced for pyside2

[Scott Kitterman]

Package: ftp.debian.org
Severity: normal

Blocking the removal of pyside, which will shortly be the last blocker
for removal of qtwebkit.

Scott K

Bug#935579: cwltool: bad upstream test testing udocker, not cwltool

[Steve Langasek]

On Sat, Aug 24, 2019 at 11:48:58AM +0200, Michael Crusoe wrote:
> Hey Steve,

> I think this is fixed in my recent upload, let me know if it works for you.

There are no errors now about udocker on non-x86, but the autopkgtests are
now failing on all architectures in Debian and Ubuntu with this error:

 ERRORS 
__ ERROR collecting tests/test_trs.py __
ImportError while importing test module 
'/usr/lib/python3/dist-packages/cwltool/tests/test_trs.py'.
Hint: make sure your test modules/packages have valid Python names.
Traceback:
/usr/lib/python3/dist-packages/cwltool/tests/test_trs.py:3: in 
import mock
E   ModuleNotFoundError: No module named 'mock'

So it looks like a missing test dep.

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


signature.asc
Description: PGP signature

Bug#935666: RM: kde4libs -- RoQA; Obsolete libs (Qt4)

[Scott Kitterman]

Package: ftp.debian.org
Severity: normal

Everything that builds againt kde4libs either has been removed or has a
pending rm bug, so it's time for kde4libs.

Scott K

Bug#935665: RM: kde-l10n -- RoQA; Obsolete libs (Qt4)

[Scott Kitterman]

Package: ftp.debian.org
Severity: normal

All kde4libs rdepends have either been removed or have pending rm
requests, so it is time for kde-l10n to go as well.

Scott K

Bug#935664: RM: kde-runtime -- RoQA; Obsolete libs (Qt4)

[Scott Kitterman]

Package: ftp.debian.org
Severity: normal

KDE4 applications have either already been removed or have rm bugs
filed.  As part of Qt4 removal it's time to remove the core KDE4
packages.

Scott K

Bug#935663: RM: kdepimlibs -- RoQA; Obsolete libs (Qt4)

[Scott Kitterman]

Package: ftp.debian.org
Severity: normal

As part of Qt4 removal, it's time for pimlibs to go.  There are other rm
requests already for the remainng rdepends.

Scott K

Bug#875149: [qtcurve] Future Qt4 removal from Buster

[Scott Kitterman]

On Sat, 9 Sep 2017 23:07:54 +0200 Lisandro =?iso-8859-1?Q?
Dami=E1n_Nicanor_P=E9rez?= Meyer  wrote:
> Source: qtcurve
> Version: 1.8.18+git20160320-3d8622c-5
> Severity: wishlist
> User: debian-qt-...@lists.debian.org
> Usertags: qt4-removal
> 
> 
> Hi! As you might know we the Qt/KDE team are preparing to remove Qt4
> as [announced] in:
> 
> [announced] 

Please go ahead and drop the Qt4 parts of this package.  Almost all KDE4 apps 
have been removed and removal of kde4libs is imminent.

Scott K

Bug#935662: RM: qt-at-spi -- RoQA; Obsolete libs (Qt4)

[Scott Kitterman]

Package: ftp.debian.org
Severity: normal

We are well along in the process of removing Qt4 from Unstable.  This is
one of only a handful of packages left that build-depend on kdelibs5-dev
(the kde4libs development package - oddly numbered for historical
reasons).  I plan to go ahead and remove this since there will very
shortly be no packages left requiring accessibility support.

Scott K

Bug#935661: wicd-gtk: Recommends obsolete kde-runtime

[Scott Kitterman]

Package: wicd-gtk
Version: 1.7.4+tb2-6
Severity: important

The kde-runtime package, which wicd-gtk recommends, is about to be
removed from Debian as part of Qt4 removal.  Please drop the recommends.

Note that the current invocation in set.py won't work anyway, so I don't
plan to wait on this package for removing kde-runtime.

Scott K

Bug#935660: tortoisehg: Obsolete libs (python2) - depends python-pyqt5.qsci

[Scott Kitterman]

Source: tortoisehg
Version: 4.8.1-0.1
Severity: serious
Justification: Policy 2.5

We are in the process of removing python2 from Debian during the
bullseye release cycle.  This package is the last remaining dependency
of python-pyqt5.qsci.  Please update to python3 (I have not checked if
your upstream supports it).

Based on the other open RC bug, this package appears unmaintained.  If
no one responds, I expect that we'll file an RoQA rm bug soonish.

Scott K

Bug#875494: connectomeviewer: Qt4 removal form Buster

[Scott Kitterman]

On Mon, 11 Sep 2017 16:33:30 -0300 =?utf-8?q?
Lisandro_Dami=C3=A1n_Nicanor_P=C3=A9rez_Meyer?=  wrote:
> Source: connectomeviewer
> Version: 2.1.0-1.1
> Severity: minor
> User: debian-qt-...@lists.debian.org
> Usertags: qt4-removal
> 
> Note: this bug is being filled because your package recommends python-
qscintilla2.
> 
> Hi! As you might know we the Qt/KDE team are preparing to remove Qt4
> as announced in:
> 
> [announced]
> 

This is now in progress.  Upstream for this package seems dead (no commits in 
upstream git in nearly two years).  It seems likely the right answer is 
probably to remove the package.

This is the last package left in the archive that needs python-qscintilla2.

If no one indicates they are going to upload this without the python-
qscintilla2 Recommends (I have no idea if that even makes sense), then I'll 
file an QoRA rm bug soon.

Scott K

Bug#700870: building eapol_test

[Terry Burton]

Hi,

With eapol_test missing from Debian it is irksome to extend the
autopkgtests for the freeradius package to include testing of EAP
methods, and there are some good reasons to include such tests.

I have refreshed Matthew Newton's earlier patch against the latest
packaging source for wpa, and attached...

I've experienced no issues with building eapol_test from the upstream
repository over the last few years and this utility has been included
in the wpa_supplicant package of most RPM-based distributions for some
time. The utility is frequently used by those implementing AAA systems
and the upstream author is very responsive so I think that concerns
about the build quality of the tool are no longer founded.

Please could you review the decision to accept this patch to build an
eapol_test package (or roll it into the wpa_supplicant package)?


Many thanks,

Terry
diff --git a/debian/config/wpasupplicant/kfreebsd b/debian/config/wpasupplicant/kfreebsd
index 9bfc129..51834ad 100644
--- a/debian/config/wpasupplicant/kfreebsd
+++ b/debian/config/wpasupplicant/kfreebsd
@@ -191,7 +191,7 @@ CONFIG_HT_OVERRIDES=y
 CONFIG_VHT_OVERRIDES=y
 
 # Development testing
-#CONFIG_EAPOL_TEST=y
+CONFIG_EAPOL_TEST=y
 
 # Select control interface backend for external programs, e.g, wpa_cli:
 # unix = UNIX domain sockets (default for Linux/*BSD)
diff --git a/debian/config/wpasupplicant/linux b/debian/config/wpasupplicant/linux
index c12c17e..8be0243 100644
--- a/debian/config/wpasupplicant/linux
+++ b/debian/config/wpasupplicant/linux
@@ -191,7 +191,7 @@ CONFIG_HT_OVERRIDES=y
 CONFIG_VHT_OVERRIDES=y
 
 # Development testing
-#CONFIG_EAPOL_TEST=y
+CONFIG_EAPOL_TEST=y
 
 # Select control interface backend for external programs, e.g, wpa_cli:
 # unix = UNIX domain sockets (default for Linux/*BSD)
diff --git a/debian/control b/debian/control
index fa5e3d8..b43a30b 100644
--- a/debian/control
+++ b/debian/control
@@ -97,3 +97,13 @@ Description: Client support for WPA and WPA2 (IEEE 802.11i)
  association with IEEE 802.11i networks.
  .
  This is a udeb of wpasupplicant for use by the debian-installer.
+
+Package: eapoltest
+Architecture: any
+Depends: ${shlibs:Depends},
+ ${misc:Depends}
+Description: EAPoL testing utility
+ eapol_test allows testing EAP authentication methods without using
+ a full 802.1X connection. It is frequently used to test the EAP
+ configuration of RADIUS systems. It is an administrator tool and not
+ required for standard 802.1X authentication.
diff --git a/debian/eapoltest.install b/debian/eapoltest.install
new file mode 100644
index 000..d3fe2c3
--- /dev/null
+++ b/debian/eapoltest.install
@@ -0,0 +1 @@
+wpa_supplicant/eapol_test usr/bin/
diff --git a/debian/eapoltest.lintian-overrides b/debian/eapoltest.lintian-overrides
new file mode 100644
index 000..45ffdbc
--- /dev/null
+++ b/debian/eapoltest.lintian-overrides
@@ -0,0 +1,6 @@
+# We distribute the package under the terms of the BSD license due to the
+# openssl issue, tell lintian to not complain:
+eapoltest: possible-gpl-code-linked-with-openssl
+
+# These are numerous and unlikely to be fixed anytime soon, filter them out.
+eapoltest: hyphen-used-as-minus-sign
diff --git a/debian/eapoltest.manpages b/debian/eapoltest.manpages
new file mode 100644
index 000..1c02297
--- /dev/null
+++ b/debian/eapoltest.manpages
@@ -0,0 +1 @@
+wpa_supplicant/doc/docbook/eapol_test.8
diff --git a/debian/rules b/debian/rules
index 9f68be3..8b15405 100755
--- a/debian/rules
+++ b/debian/rules
@@ -56,6 +56,9 @@ override_dh_auto_build:
 	dh_auto_build --sourcedirectory=hostapd \
 	  --buildsystem=makefile
 	dh_auto_clean --sourcedirectory=src --buildsystem=makefile
+	# build eapol_test
+	dh_auto_build --sourcedirectory=wpa_supplicant \
+	  --buildsystem=makefile -- eapol_test
 
 override_dh_auto_clean:
 	dh_auto_clean --sourcedirectory=wpa_supplicant/doc/docbook \
@@ -91,6 +94,7 @@ override_dh_installchangelogs:
 	dh_installchangelogs --package=hostapd hostapd/ChangeLog
 	dh_installchangelogs --package=wpasupplicant wpa_supplicant/ChangeLog
 	dh_installchangelogs --package=wpagui wpa_supplicant/ChangeLog
+	dh_installchangelogs --package=eapoltest wpa_supplicant/ChangeLog
 ### end dh overrides
 
 %:

Bug#935659: RM: kopete -- RoQA; Obsolete libs - Qt4

[Scott Kitterman]

Package: ftp.debian.org
Severity: normal

The current unstable version is Qt4.  There is a Qt5 version in
experimental, but the maintainer has not yet concluded it's appropriate
to include in a future release.  Once the Qt5 version is ready, it can
be uploaded to unstable to re-introduce the package.  In the meantime,
it doesn't make sense to block further progress on removing Qt4.

Scott K

Bug#934816: tcl8.6-tdbc-mysql: built with libmariadbclient18, which doesn't exist any longer

[Andreas Beckmann]

Control: severity -1 normal

On Sat, 24 Aug 2019 17:11:10 +0200 =?UTF-8?B?T3R0byBLZWvDpGzDpGluZW4=?= 
 wrote:
> Increasing severity to 'serious' since this is one of the 5 packages
> what still depend on libmariadbclient18, which will soon be removed
> from unstable and then render this package uninstallable. Please
> rebuild and upload, so that the package will automatically be built
> and depend on newest libraries (including libmariadb3 which has
> replaced libmariadbclient18).

This is an alternative dependency, the package will not be
affected by libmariadbclient18 removal:

Package: tcl8.6-tdbc-mysql
Version: 1.1.0-2+b1
Architecture: amd64
Depends: libc6 (>= 2.14), tcl8.6, tcl8.6-tdbc (>= 1.0.5), libmariadb3 | 
libmariadbclient18 | libmysqlclient18 | libmysqlclient20


> debian-sid$ apt-rdepends -r libmariadbclient18

Instead of rdepends you should rather check what happens upon removal:


anbe@coccia:~$ dak rm -Rn -b libmariadbclient18
Will remove the following packages from unstable:

libmariadbclient18 | 1:10.3.13-1 | amd64, arm64, armel, armhf, i386, mips64el, 
mipsel, ppc64el, s390x

Maintainer: Debian MySQL Maintainers 

--- Reason ---

--

Checking reverse dependencies...
# Broken Depends:
dballe: libdballe7
mosquitto-auth-plugin: mosquitto-auth-plugin
mysql++: libmysql++3v5
quickfix: libquickfix16 [i386]
stardict: stardict-tools

Dependency problem found.


Andreas

Bug#910902: Please test again: my_print_defaults and Akonadi for a freash installation

[Andreas Beckmann]

On Sun, 4 Aug 2019 18:45:28 +0100 =?UTF-8?B?T3R0byBLZWvDpGzDpGluZW4=?=
 wrote:
> For some strange reason page https://tracker.debian.org/pkg/mariadb-10.3
> still says "Updating mariadb-10.3 introduces new bugs: #910902".
> 
> Do you Sandro have any ideas why that is?

I think that was because the bug was assigned to the arch:all
metapackage, that has a "buggy" cruft version in sid.
Should have been fixed by reassigning to mariadb-server-core-10.3 (done
a few minutes ago).

mariadb-server | 1:10.3.13-1  | unstable | all
mariadb-server | 1:10.3.15-1  | stable   | all
mariadb-server | 1:10.3.15-1  | testing  | all
mariadb-server | 1:10.3.17-1  | unstable | all


Andreas

Bug#935598: mpirun has detected an attempt to run as root. (Was: Bug#935598: phyml: autopkgtest regression: gzip: *.gz: No such file or directory)

[Andreas Tille]

Hi,

the issue with gzip is fixed in Git.  However I'm running into a
new issue

-- 
http://fam-tille.de

Bug#935658: RM: tora -- RoQA; Depends on qt4, unmaintained

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove tora. While it's ported to Qt5 upstream, the current
maintainer doesn't use it any longer and the current version in the
archive still relies on Qt4, which is scheduled for removal.

Cheers,
Moritz

Bug#875208: [tora] Future Qt4 removal from Buster

[Moritz Mühlenhoff]

On Sat, Aug 24, 2019 at 10:12:34PM +0200, Michael Meskes wrote:
> > > It's now the last one, so if I don't hear back soon that someone
> > > intends to 
> > > upgrade this to Qt5, I'll file for the rm.
> > 
> > Adding the primary uploader to CC.
> 
> I'm not using the tool anymore, nor do I have time to take care of it.
> The only reason why I didn't orphan it, is that somebody inb the group
> might be willing to, but apparently not. So in short, go ahead.

Ack, I've just filed a removal bug.

Cheers,
Moritz

Bug#935656: RM: qwbfsmanager -- RoQA; unmaintained, depends on qt4

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove qwbfsmanager. The version currently in the archive is 
unmaintained (last
maintainer upload in 2011, now orphaned) and depends on Qt 4. There's a new 
upstream
release on Github which is actually ported to Qt5, but it also depends on a new 
Qt
extension library (fresh). If someone wants to revive qwbfsmanager in the 
future,
that library would need to be packaged/uploaded beforehand.

Cheers,
Moritz

Bug#935657: Please port and switch this package to Python 3 or remove it from Debian

[Thomas Goirand]

Package: calendarserver
Version: 9.2+dfsg-1
Severity: serious

Hi,

We're trying to remove Python 2 from Bullseye. And I came across your package,
which is still py2 only.

Please switch it to Python 3. If that's not possible, then it's probably the
time for your package to get removed from Debian, unfortunately.

Cheers,

Thomas Goirand (zigo)

Bug#935501: Issue resolved

[Peda Bone]

Upgraded to Kernel 4.19.0-6-amd64 from Buster-Backports and no longer 
have the issue.

Bug#935655: stretch-pu: package liquidsoap/1.3.3-2+deb10u1

[Andreas Beckmann]

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

Hi,

I'd like to update liquidsoap in buster to smoothen some upgrade paths
from stretch. liquidsoap/buster Breaks+Replaces about 35 plugin packages
from stretch, but on some upgrade paths apt prefers to keep some old
packages including liquidsoap installed (noticed in piuparts). Adding
Conflicts: liquidsoap-plugin-ogg "improves" the scores given by apt to
ensure more cruft gets removed and no upgradable package is kept at an
old version (verified in piuparts).

There is no point in applying this HACK in sid, since direct
stretch->bullseye/sid upgrades skipping buster are not supported.


Andreas
diff -Nru liquidsoap-1.3.3/debian/changelog liquidsoap-1.3.3/debian/changelog
--- liquidsoap-1.3.3/debian/changelog   2018-09-04 20:35:40.0 +0200
+++ liquidsoap-1.3.3/debian/changelog   2019-08-24 20:36:44.0 +0200
@@ -1,3 +1,12 @@
+liquidsoap (1.3.3-2+deb10u1) buster; urgency=medium
+
+  * Non-maintainer upload.
+  * Add Conflicts: liquidsoap-plugin-ogg (<< 1.3) in addition to the existing
+Breaks to ensure removal of the obsolete plugin packages on more upgrade
+paths from stretch.
+
+ -- Andreas Beckmann   Sat, 24 Aug 2019 20:36:44 +0200
+
 liquidsoap (1.3.3-2) unstable; urgency=medium
 
   * Fix build errors on armel and mips*
diff -Nru liquidsoap-1.3.3/debian/control liquidsoap-1.3.3/debian/control
--- liquidsoap-1.3.3/debian/control 2018-09-04 20:35:40.0 +0200
+++ liquidsoap-1.3.3/debian/control 2019-08-24 20:36:12.0 +0200
@@ -155,6 +155,10 @@
  liquidsoap-plugin-voaacenc,
  liquidsoap-plugin-vorbis,
  liquidsoap-plugin-xmlplaylist
+Conflicts:
+# use Conflicts in addition to Breaks to slightly push apt's scores towards
+# removal of the obsolete ogg plugin package which has many rdepends
+ liquidsoap-plugin-ogg (<< 1.3),
 Description: audio streaming language
  Liquidsoap is a powerful tool for building complex audio streaming systems,
  typically targeting internet radios (e.g. icecast streams).

Bug#827196: Already fixed upstream

[Ernesto Domato]

Package: ocrfeeder
Version: 0.8.1-4
Followup-For: Bug #827196

Dear Maintainer,

This issue has been fixed upstream since Mar 18, 2018 [1]

Please consider packaging last version from the Git repository [2]

Thanks for all.
Ernesto

[1]
https://gitlab.gnome.org/GNOME/ocrfeeder/commit/f5f1b076993ec0ba94250f21051e049072c7e230
[2] https://gitlab.gnome.org/GNOME/ocrfeeder



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

Kernel: Linux 5.0.0-trunk-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=es_AR.UTF-8, LC_CTYPE=es_AR.UTF-8 (charmap=UTF-8), 
LANGUAGE=es_AR:es (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages ocrfeeder depends on:
ii  ghostscript   9.28~~rc1~dfsg-1
ii  gir1.2-goocanvas-2.0  2.0.4-1
ii  gir1.2-gtk-3.03.24.10-1
ii  gir1.2-gtkspell3-3.0  3.0.9-3
ii  iso-codes 4.3-1
ii  python2.7.16-1
ii  python-enchant2.0.0-1
ii  python-gi 3.32.2-1
ii  python-lxml   4.4.1-1
ii  python-pil6.1.0-1
ii  python-reportlab  3.5.23-1
ii  python-sane   2.8.3-1+b2
ii  tesseract-ocr 4.1.0-1

Versions of packages ocrfeeder recommends:
pn  unpaper  
ii  yelp 3.31.90-1

ocrfeeder suggests no packages.

-- no debconf information

Bug#935654: matrix-synapse: /etc/init.d/matrix-synapse stop doesn't work

[sergio]

Package: matrix-synapse
Version: 1.3.0-1~bpo10+1
Severity: normal

Dear Maintainer,

# /etc/init.d/matrix-synapse stop
doesn't work:

# lsof -i -n -sTCP:LISTEN | grep mat
python3 3831 matrix-synapse   10u  IPv6  51886  0t0  TCP [::1]:8448 (LISTEN)
python3 3831 matrix-synapse   11u  IPv4  51887  0t0  TCP *:8448 (LISTEN)
python3 3831 matrix-synapse   12u  IPv6  51888  0t0  TCP [::1]:8008 (LISTEN)
python3 3831 matrix-synapse   13u  IPv4  51889  0t0  TCP *:8008 (LISTEN)

Bug#935621: openstack-dashboard: incompatible with django 2.2

[Thomas Goirand]

Hi,

I'm very much aware of this issue, but can't find a way to fix it
myself. openstack_auth/views.py is using a login() function instead of
the now required LoginView class. I'm not skilled enough in Django to do
this myself, and upstream unfortunately doesn't feel it's urgent. Until
this is fixed, it's useless to work on anything else regarding Horizon
(I do believe I could fix the rest of the Django 2.2 related issues).

Cheers,

Thomas Goirand (zigo)

Bug#935650: netcat-openbsd: valid arguments disallowed

[Guilhem Moulin]

Control: retitle -1 netcat-openbsd: Unable to specify client socket for 
UNIX-domain datagram sockets
Control: found -1 1.187-1
Control: found -1 1.195-2

Hi,

On Sat, 24 Aug 2019 at 20:25:00 +, astian wrote:
> Looking at the patch I don't trust this is the only behaviour change.  I
> don't understand why this divergence from upstream was introduced and I
> wish it was reverted altogether.

The patch was added to support the following calls for consistency with
netcat-traditional:

nc -l -s 127.0.0.1 -p 12345 ## listen on AF_INET socket 
INADDR_LOOPBACK:12345
nc -l -p 12345  ## listen on AF_INET socket ADDR_ANY:12345

It'd be a regression to stop supporting these forms, or any of the
others from https://bugs.debian.org/897020#17 .

> But if that's not possible below is a patch that you can fold into the
> existing one.
> […]
> - } else if (argc == 1 && !pflag && !sflag) {
> + } else if (argc == 1 && !pflag && (!sflag || family == AF_UNIX)) {

In combination with ‘-U’ the ‘-s’ option only makes sense for datagrams,
no?  AFAICT it's a no-op for stream sockets; might make sense to error
out unless ‘-u’ is set.

As for your other patches, I'm personally not keen to further diverge
with upstream (especially when it comes to adding new flags/options) —
but hopefully they'll eventually pick up your fixes or address your
concerns ;-)

Thanks for the reports and patches!
-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#695069: cmus: remaining time is wrong when using ALSA PulseAudio sink

[Ryan Kavanagh]

control: tags -1 + moreinfo unreproducible

Hi Dominik,

I tried using your proposed ~/.cmus/autosave and couldn't reproduce the
bug. Have you noticed it with a particular format of audio file? Is it
still an issue with a current version of cmus?

Best
Ryan

-- 
|)|/  Ryan Kavanagh  | GPG: 4E46 9519 ED67 7734 268F
|\|\  https://rak.ac |  BD95 8F7B F8FC 4A11 C97A


signature.asc
Description: PGP signature

Bug#935564: Typo

[Jean-Francois Pirus]

Opps, should have said:

With kenel 5.2.0-2-amd64,  TX is  4184/KB/sec 
With kenel 4.19.0-5-amd64, TX is 39678/KB/sec

Bug#935653: [unattended-upgrades] /usr/bin/unattended-upgrade hogging cpu

[Riccardo Magliocchetti]

Package: unattended-upgrades
Version: 1.14
Severity: normal

--- Please enter the report below this line. ---

Hello,

I have /usr/bin/python3 /usr/bin/unattended-upgrade using 100% of a core calling 
stat in a very tight loop for no apparent good reason. It does so by holding the 
/var/lib/dpkg/lock-frontend lock.


Even after a kill -9, a new process shows the same behaviour.

Stracing it looks like it's in a loop calling stat for files that does not 
exists:

sudo strace -c -p 6778
strace: Process 6778 attached
strace: [ Process PID=6778 runs in x32 mode. ]
strace: [ Process PID=6778 runs in 64 bit mode. ]
^Cstrace: Process 6778 detached
% time seconds  usecs/call callserrors syscall
-- --- --- - - 
100,000,147692   1 77789 57944 stat
-- --- --- - - 
100.000,147692 77789 57944 total

Excerpt on actual calls:

stat("/var/lib/apt/lists/ftp.de.debian.org_debian_dists_sid_contrib_i18n_Translation-en", 
{st_mode=S_IFREG|0644, st_size=208649, ...}) = 0
stat("/var/lib/apt/lists/ftp.de.debian.org_debian_dists_sid_contrib_i18n_Translation-it", 
0x7ffd7bd40c80) = -1 ENOENT (File o directory non esistente)
stat("/var/lib/apt/lists/ftp.de.debian.org_debian_dists_sid_contrib_i18n_Translation-it.xz", 
0x7ffd7bd40c80) = -1 ENOENT (File o directory non esistente)
stat("/var/lib/apt/lists/ftp.de.debian.org_debian_dists_sid_contrib_i18n_Translation-it.bz2", 
0x7ffd7bd40c80) = -1 ENOENT (File o directory non esistente)
stat("/var/lib/apt/lists/ftp.de.debian.org_debian_dists_sid_contrib_i18n_Translation-it.lzma", 
0x7ffd7bd40c80) = -1 ENOENT (File o directory non esistente)
stat("/var/lib/apt/lists/ftp.de.debian.org_debian_dists_sid_contrib_i18n_Translation-it.gz", 
0x7ffd7bd40c80) = -1 ENOENT (File o directory non esistente)
stat("/var/lib/apt/lists/ftp.de.debian.org_debian_dists_sid_contrib_i18n_Translation-it.lz4", 
0x7ffd7bd40c80) = -1 ENOENT (File o directory non esistente)
stat("/var/lib/apt/lists/ftp.de.debian.org_debian_dists_sid_contrib_i18n_Translation-it.zst", 
0x7ffd7bd40c80) = -1 ENOENT (File o directory non esistente)

...


Thanks

--
Riccardo Magliocchetti
@rmistaken

http://menodizero.it

Bug#787034: Further details: .wav files causing problems

[Ryan Kavanagh]

control: tags -1 + unreproducible moreinfo

Hi Tim,

On Thu, May 28, 2015 at 09:58:28AM -0500, Tim Chase wrote:
> RIFF (little-endian) data, WAVE audio, Microsoft PCM, 16 bit, mono
> 44100 Hz

I am unable to reproduce this. I tried converted an mp3 file to WAV
using ffmpeg, and cmus was able to both add it to the library and play
it. Could you please let me know if this is still an issue with the
current version of cmus? In case I'm missing something, here are the
steps I took to generate the WAV file:

rak@zeta:/tmp$ ffmpeg -i test.mp3 test.wav
[...]
rak@zeta:/tmp$ file test.wav
test.wav: RIFF (little-endian) data, WAVE audio, Microsoft PCM, 16 bit,
stereo 44100 Hz
rak@zeta:/tmp$ xxd test.wav | head -3
: 5249 4646 c087 5102 5741 5645 666d 7420  RIFF..Q.WAVEfmt
0010: 1000  0100 0200 44ac  10b1 0200  D...
0020: 0400 1000 4c49 5354 b400  494e 464f  LISTINFO

Best,
Ryan

-- 
|)|/  Ryan Kavanagh  | GPG: 4E46 9519 ED67 7734 268F
|\|\  https://rak.ac |  BD95 8F7B F8FC 4A11 C97A


signature.asc
Description: PGP signature

Bug#874825: [Pkg-kde-extras] Bug#874825: [appmenu-qt] Future Qt4 removal from Buster

[Scott Kitterman]

On Saturday, August 24, 2019 1:12:04 PM EDT Reiner Herrmann wrote:
> There is a Qt5 port available at: https://launchpad.net/appmenu-qt5

I checked and it's dead.  Not even in Ubuntu.

Scott K

Bug#935652: RM: appmenu-qt -- ROM; Obsolete libs (Qt4), dead upstream, Qt5 port dead too

[Scott Kitterman]

Package: ftp.debian.org
Severity: normal

Time for this to go as part of Qt4 removal.

Scott K

Bug#935352: trimage: Qt4 removal from Bullseye

[Reiner Herrmann]

Control: tags -1 + fixed-upstream

The new upstream version 1.0.6 supports Qt5.


signature.asc
Description: PGP signature

Bug#935004: cups-filters: print test page problem solved by upgrading to github version (1.25.1)

[frederik]

I'm so sorry I will try to get around to that today

On Sat, Aug 24, 2019 at 08:21:21PM +0100, Brian Potkin wrote:

tags 935004 moreinfo
thanks


On Sun 18 Aug 2019 at 17:27:29 +0200, Didier 'OdyX' Raboud wrote:


I have just uploaded 1.25.2 to Debian unstable; could you try this version,
from the Debian repos?


Any news?

Cheers,

Brian.

Bug#935651: ITP: golang-github-jesseduffield-asciigraph -- Go package to make lightweight ASCII line graph without dependencies

[Dawid Dziurla]

Package: wnpp
Severity: wishlist
Owner: Dawid Dziurla 

* Package name: golang-github-jesseduffield-asciigraph
  Version : 0.4.1+git20190605.6d88e39-1
  Upstream Author : Jesse Duffield
* URL : https://github.com/jesseduffield/asciigraph
* License : BSD-3-clause
  Programming Lang: Go
  Description : Go package to make lightweight ASCII line graph without 
dependencies

 Go package to make lightweight ASCII line graphs.
 .
 This package is golang port of library
 asciichart (https://github.com/kroitor/asciichart).

This package is in the dependency tree of "lazydocker" (#935641)

Bug#935642: ITP: golang-github-acarl005-stripansi -- A little Go package for removing ANSI color escape codes from strings

[iuri]

Gentleman, please unsubscribe me for now. Best regards.

Em sáb, 24 de ago de 2019 17:27, Dawid Dziurla 
escreveu:

> Package: wnpp
> Severity: wishlist
> Owner: Dawid Dziurla 
>
> * Package name: golang-github-acarl005-stripansi
>   Version : 0.0~git20180116.5a71ef0-1
>   Upstream Author : Andy
> * URL : https://github.com/acarl005/stripansi
> * License : Expat
>   Programming Lang: Go
>   Description : A little Go package for removing ANSI color escape
> codes from strings
>
>  This Go package removes ANSI escape codes from strings.
>  .
>  Ideally, we would prevent these from appearing in any text we want to
>  process. However, sometimes this can't be helped, and we need to be able
>  to deal with that noise. This will use a regexp to remove those unwanted
>  escape codes.
>
> This package is in the dependency tree of "lazydocker" (#935641)
>
>

Bug#694077: Package review

[Lisandro Damián Nicanor Pérez Meyer]

please release it (dch -r), push it and I'll upload.

On Tue, 20 Aug 2019 at 09:07, Lisandro Damián Nicanor Pérez Meyer
 wrote:
>
> Hi!
>
> El mar., 20 ago. 2019 05:35, Jérôme Lebleu  escribió:
>>
>> Hi Lisandro,
>>
>> I am happy to read from you!
>>
>> Le 19/08/2019 à 21:42, Lisandro Damián Nicanor Pérez Meyer a écrit :
>> > I'm afraid it's failing to build from source:
>> >
>> > x86_64-linux-gnu/qt5 -isystem 
>> > /usr/include/x86_64-linux-gnu/qt5/QtMultimedia -isystem 
>> > /usr/include/x86_64-linux-gnu/qt5/QtGui -isystem 
>> > /usr/include/x86_64-linux-gnu/qt5/QtNetwork -isystem 
>> > /usr/include/x86_64-linux-gnu/qt5/QtScript -isystem 
>> > /usr/include/x86_64-linux-gnu/qt5/QtCore -I. -isystem /usr/include/libdrm 
>> > -I/usr/lib/x86_64-linux-gnu/qt5/mkspecs/linux-g++ -o qlcfixturedefcache.o 
>> > qlcfixturedefcache.cpp
>> > qlcfixturedef.cpp: In member function ‘QLCPhysical 
>> > QLCFixtureDef::physical() const’:
>> > qlcfixturedef.cpp:342:12: error: implicitly-declared 
>> > ‘QLCPhysical::QLCPhysical(const QLCPhysical&)’ is deprecated 
>> > [-Werror=deprecated-copy]
>> >   342 | return m_physical;
>> >   |^~
>> > In file included from qlcfixturedef.h:28,
>> >  from qlcfixturemode.h:29,
>> >  from qlcfixturedef.cpp:28:
>> > qlcphysical.h:78:18: note: because ‘QLCPhysical’ has user-provided 
>> > ‘QLCPhysical& QLCPhysical::operator=(const QLCPhysical&)’
>> >78 | QLCPhysical& operator=(const QLCPhysical& physical);
>> >   |  ^~~~
>> > cc1plus: all warnings being treated as errors
>> > make[3]: *** [Makefile:1206: qlcfixturedef.o] Error 1
>> > make[3]: *** Waiting for unfinished jobs
>> > make[3]: Leaving directory '/<>/engine/src'
>> > make[2]: *** [Makefile:90: sub-src-make_first-ordered] Error 2
>> > make[2]: Leaving directory '/<>/engine'
>> > make[1]: *** [Makefile:96: sub-engine-make_first-ordered] Error 2
>> > make[1]: Leaving directory '/<>'
>> > dh_auto_build: make -j2 returned exit code 2
>> > make: *** [debian/rules:14: build] Error 255
>> > dpkg-buildpackage: error: debian/rules build subprocess returned exit 
>> > status 2
>> > 
>> > Build finished at 2019-08-19T19:38:24Z
>> >
>> >
>> > Could it be the switch to gcc-9?
>>
>> Thanks for your report, I have just discovered that yesterday too. Yes
>> it should be the switch to gcc-9 as there were no errors before... I
>> have added -Wno-error=deprecated-copy for the moment to makes this
>> warnings not be errors. I will take the time as soon as possible to
>> report it upstream, if it is not meanwhile fixed. Is it also okay for a
>> first upload too?
>
>
> I think it is.



-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/

Bug#935650: netcat-openbsd: valid arguments disallowed

[astian]

Package: netcat-openbsd
Version: 1.203-1
Severity: normal
Control: tags -1 + patch

Dear Maintainer,

The debian-specific patch "use-flags-to-specify-listen-address.patch"
disallows the usage of "-s" in some valid cases.  For example, the
following should connect to the unix socket "target" and use "foo" as
its client socket:

  $ nc -U -s foo target
  usage: nc ...

Looking at the patch I don't trust this is the only behaviour change.  I
don't understand why this divergence from upstream was introduced and I
wish it was reverted altogether.  But if that's not possible below is a
patch that you can fold into the existing one.

By the way, when I was looking at netcat 2 weeks ago I found several
other issues.  I wrote to the upstream ML and was planning to report the
bugs to the Debian BTS afterwards but it seems upstream is not very
interested because there was no reply in 10+ days.  Anyway, in case you
want to fix any of these, of the upstream issues the ones that are most
relevant for the Debian "fork" are the following:
  - https://marc.info/?l=openbsd-bugs=156551733219405=2 (the
non-kernel part, obviously)
  - https://marc.info/?l=openbsd-bugs=156568806424551=2
  - https://marc.info/?l=openbsd-bugs=156551644519192=2
  - https://marc.info/?l=openbsd-bugs=156551645219193=2
  - https://marc.info/?l=openbsd-bugs=156551644219191=2

There's also this one, but here Debian unfortunately diverged so there's
less of a compelling reason to fix it:
  - https://marc.info/?l=openbsd-bugs=156551640819187=2

The remaining one is OpenBSD-specific.

In my Debian box I've been running a custom netcat package with all of
the above patched (some "provisionally", some with patches that differ
slightly for Linux), so feel free to ask if you want the patches.


Thanks.

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

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

Versions of packages netcat-openbsd depends on:
ii  libbsd0  0.9.1-2
ii  libc62.28-10

netcat-openbsd recommends no packages.

netcat-openbsd suggests no packages.

-- no debconf information

--- a/netcat.c
+++ b/netcat.c
@@ -511,7 +511,7 @@ main(int argc, char *argv[])
if (argc == 0 && lflag) {
uport = 
host = sflag;
-   } else if (argc == 1 && !pflag && !sflag) {
+   } else if (argc == 1 && !pflag && (!sflag || family == AF_UNIX)) {
if (family == AF_UNIX) {
host = argv[0];
uport = NULL;

Bug#875208: [Pkg-kde-extras] Bug#875208: [tora] Future Qt4 removal from Buster

[Scott Kitterman]

On Saturday, August 24, 2019 4:12:34 PM EDT Michael Meskes wrote:
> > > It's now the last one, so if I don't hear back soon that someone
> > > intends to
> > > upgrade this to Qt5, I'll file for the rm.
> > 
> > Adding the primary uploader to CC.
> 
> I'm not using the tool anymore, nor do I have time to take care of it.
> The only reason why I didn't orphan it, is that somebody inb the group
> might be willing to, but apparently not. So in short, go ahead.

Thanks.  rm bug filed.

Scott K

Bug#935649: RM: tora -- RoQA; Obsolet libs (Qt4)

[Scott Kitterman]

Package: ftp.debian.org
Severity: normal

Uses Qt4, so needs to go.  Maintainer agrees (see #875208).

Scott K

Bug#935647: ITP: golang-github-mcuadros-go-lookup -- Small library on top of reflect for make lookups to any Structs or Maps

[Dawid Dziurla]

Package: wnpp
Severity: wishlist
Owner: Dawid Dziurla 

* Package name: golang-github-mcuadros-go-lookup
  Version : 0.0~git20171110.5650f26-1
  Upstream Author : Máximo Cuadros
* URL : https://github.com/mcuadros/go-lookup
* License : Expat
  Programming Lang: Go
  Description : Small library on top of reflect for make lookups to any 
Structs or Maps

 Using a very simple DSL one can have
 access to any property,
 key or value of any value of Go.

This package is in the dependency tree of "lazydocker" (#935641)

Bug#935644: ITP: golang-github-jesseduffield-roll -- Simple(er) Rollbar client for Go

[Dawid Dziurla]

Package: wnpp
Severity: wishlist
Owner: Dawid Dziurla 

* Package name: golang-github-jesseduffield-roll
  Version : 0.0~git20190629.695be2e-1
  Upstream Author : Jesse Duffield
* URL : https://github.com/jesseduffield/roll
* License : Expat
  Programming Lang: Go
  Description : Simple(er) Rollbar client for Go

 Basic Rollbar client for Go that reports errors and logs
 messages. It automatically builds stack traces and also supports arbitrary
 traces. All errors and messages are sent to Rollbar synchronously.
 .
 roll is intentionally simple. For more advanced functionality, check
 out heroku/rollbar (https://github.com/heroku/rollbar).

This package is in the dependency tree of "lazydocker" (#935641)

Bug#935648: ITP: golang-github-openpeedeep-xdg -- Cross platform package that follows the XDG Standard

[Dawid Dziurla]

Package: wnpp
Severity: wishlist
Owner: Dawid Dziurla 

* Package name: golang-github-openpeedeep-xdg
  Version : 0.2.0-1
  Upstream Author : OpenPeeDeeP
* URL : https://github.com/OpenPeeDeeP/xdg
* License : BSD-3-clause
  Programming Lang: Go
  Description : Cross platform package that follows the XDG Standard

 Cross platform package that tries to follow XDG Standard
 when possible.
 .
 When creating XDG application the Vendor and Application names are
 appeneded to the end of the path to keep projects unique.
 chose to present an error message to the user.

This package is in the dependency tree of "lazydocker" (#935641)

Bug#935646: ITP: golang-github-jesseduffield-yaml -- YAML support for the Go language.

[Dawid Dziurla]

Package: wnpp
Severity: wishlist
Owner: Dawid Dziurla 

* Package name: golang-github-jesseduffield-yaml
  Version : 2.2.2+git20190702.b900b7e-1
  Upstream Author : Jesse Duffield
* URL : https://github.com/jesseduffield/yaml
* License : Apache-2.0
  Programming Lang: Go
  Description : YAML support for the Go language.

 Enables Go programs to comfortably encode and decode YAML values.
 It was developed within Canonical (https://www.canonical.com)
 as part of the juju (https://juju.ubuntu.com) project
 and is based on a pure Go port of the
 well-known libyaml (http://pyyaml.org/wiki/LibYAML) C library to parse and
 generate YAML data quickly and reliably.

This package is in the dependency tree of "lazydocker" (#935641)

Bug#935645: ITP: golang-github-jesseduffield-rollrus -- Logrus Rollbar Hook

[Dawid Dziurla]

Package: wnpp
Severity: wishlist
Owner: Dawid Dziurla 

* Package name: golang-github-jesseduffield-rollrus
  Version : 0.0~git20190701.dd028cb-1
  Upstream Author : Jesse Duffield
* URL : https://github.com/jesseduffield/rollrus
* License : Expat
  Programming Lang: Go
  Description : Logrus Rollbar Hook

 Rollrus is what happens when Logrus (https://github.com/sirupsen/logrus)
 meets Roll (https://github.com/stvp/roll).
 .
 When a .Error, .Fatal or .Panic logging function is called, report the
 details to rollbar via a Logrus hook.
 Delivery is synchronous to help ensure that logs are delivered.
 .
 If the error includes a StackTrace
 (https://godoc.org/github.com/pkg/errors#StackTrace), that StackTrace
 is reported to rollbar.

This package is in the dependency tree of "lazydocker" (#935641)

Bug#935643: ITP: golang-github-integrii-flaggy -- Idiomatic Go input parsing with subcommands, positional values, and flags

[Dawid Dziurla]

Package: wnpp
Severity: wishlist
Owner: Dawid Dziurla 

* Package name: golang-github-integrii-flaggy
  Version : 1.2.2-1
  Upstream Author : Eric Greer
* URL : https://github.com/integrii/flaggy
* License : Expat
  Programming Lang: Go
  Description : Idiomatic Go input parsing with subcommands, positional 
values, and flags

 Sensible and fast command-line flag parsing with excellent support
 for subcommands and positional values. Flags can be at any position.
 Flaggy has no required project or package layout like Cobra requires
 and no external dependencies!

This package is in the dependency tree of "lazydocker" (#935641)

Bug#935642: ITP: golang-github-acarl005-stripansi -- A little Go package for removing ANSI color escape codes from strings

[Dawid Dziurla]

Package: wnpp
Severity: wishlist
Owner: Dawid Dziurla 

* Package name: golang-github-acarl005-stripansi
  Version : 0.0~git20180116.5a71ef0-1
  Upstream Author : Andy
* URL : https://github.com/acarl005/stripansi
* License : Expat
  Programming Lang: Go
  Description : A little Go package for removing ANSI color escape codes 
from strings

 This Go package removes ANSI escape codes from strings.
 .
 Ideally, we would prevent these from appearing in any text we want to
 process. However, sometimes this can't be helped, and we need to be able
 to deal with that noise. This will use a regexp to remove those unwanted
 escape codes.

This package is in the dependency tree of "lazydocker" (#935641)

Bug#875208: [tora] Future Qt4 removal from Buster

[Michael Meskes]

> > It's now the last one, so if I don't hear back soon that someone
> > intends to 
> > upgrade this to Qt5, I'll file for the rm.
> 
> Adding the primary uploader to CC.

I'm not using the tool anymore, nor do I have time to take care of it.
The only reason why I didn't orphan it, is that somebody inb the group
might be willing to, but apparently not. So in short, go ahead.

Michael
-- 
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Meskes at (Debian|Postgresql) dot Org
Jabber: michael at xmpp dot meskes dot org
VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL

Bug#935641: ITP: lazydocker -- The lazier way to manage everything docker

[Dawid Dziurla]

Package: wnpp
Severity: wishlist
Owner: Dawid Dziurla 

* Package name: lazydocker
  Version : 0.7-1
  Upstream Author : Jesse Duffield
* URL : https://github.com/jesseduffield/lazydocker
* License : Expat
  Programming Lang: Go
  Description : The lazier way to manage everything docker

 A simple terminal UI for both docker and docker-compose, written
 in Go with the gocui (https://github.com/jroimartin/gocui) library.
 .
 Memorising docker commands is hard. Memorising aliases is slightly
 less hard. Keeping track of your containers across multiple terminal
 windows is near impossible. What if you had all the information
 you needed in one terminal window with every common command
 living one keypress away (and the ability to add custom commands
 as well). Lazydocker's goal is to make that dream a reality.

Project is relatively new, but has developed rapidly in recent months
and I think it would be nice to have this program packaged in Debian.

Bug#935640: running 'firehol restart' does not always reproduce ruleset

[Toni]

Package: firehol
Version: 3.1.6+ds-8
Severity: normal


Hi,

I am fiddling with my firehol rules, but am encountering a very
confusing behaviour. Initially, after system boot, the rules are created
with 'iptables'. When I run 'firehol restart', 'firehol' shows that all
chains are having only an "ACCEPT" policy and no rules, while all rules
are now only visible using 'iptables-legacy', which did not show any
rules earlier. This is very confusing, as the rules are also entirely
not the same.

In my opinion, firehol should only the 'iptables' command and not the
'iptables-legacy' command, if possible, but not change horses midway.


Cheers,
Toni


-- System Information:
Debian Release: 10.0
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'proposed-updates'), (90, 'testing'), (70, 
'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-5-amd64 (SMP w/12 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, 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

Versions of packages firehol depends on:
ii  firehol-common  3.1.6+ds-8
ii  lsb-base10.2019051400

Versions of packages firehol recommends:
ii  fireqos  3.1.6+ds-8

Versions of packages firehol suggests:
pn  firehol-doc
pn  firehol-tools  
pn  ulogd2 

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

-- no debconf information

Bug#935004: cups-filters: print test page problem solved by upgrading to github version (1.25.1)

[Brian Potkin]

tags 935004 moreinfo
thanks


On Sun 18 Aug 2019 at 17:27:29 +0200, Didier 'OdyX' Raboud wrote:

> I have just uploaded 1.25.2 to Debian unstable; could you try this version, 
> from the Debian repos?

Any news?

Cheers,

Brian.

Bug#929720: hkl: FTBFS: ../../hkl/ccan/generator/generator.h:23:2: error: #error Generators require coroutines

[PICCA Frederic-Emmanuel]

Hello,

I am wondering if the problem is not a gcc bug.

I tryed to deal with this issue, with the ccan upstream.

https://github.com/rustyrussell/ccan/issues/65

but I do not have the skills in order to fix it otherwise than applying the 
simple  one line fix

Here the patch I am applying i order to fix the build issue.
But it seems that it is not sufficient...

https://salsa.debian.org/science-team/hkl/blob/master/debian/patches/0001-889878-make-test-for-pointer-safe-makecontext-succee.patch


Cheers

Fred

Bug#935639: Abandoned upstream

[David Prévot]

Package: phpunit-dbunit
Version: 4.0.0-2
Severity: serious

[ Filled as an RC-bug by the maintainer to see the package auto-removed
  from testing. ]

Since this PHPUnit extension is abandoned upstream and nothing depends
on it in Debian, there is a priori little point to keep this package in
the next stable Debian release.

I intend to follow up with an RM request in a few months if nobody
objects (but feel free to beat me to it).

Regards

David

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

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

Versions of packages phpunit-dbunit depends on:
ii  php-common2:69
ii  php-symfony-yaml  4.3.3+dfsg-3
ii  php-xml   2:7.3+69
ii  php7.3-xml [php-xml]  7.3.8-1
ii  phpunit   8.2.4-1

phpunit-dbunit recommends no packages.

phpunit-dbunit suggests no packages.


signature.asc
Description: PGP signature

Bug#935637: postgresql-debversion: OPERATOR = declaration is missing HASHES and MERGES flags

[Felix Lechner]

Package: postgresql-debversion
X-Debbugs-CC: la...@debian.org, mat...@debian.org, and...@tao11.riddles.org.uk

Hi,

The current implementation of 'debversion' could be improved for
better performance on hash joins.

There's a missing HASHES property on the = operator declaration that's
stopping it being considered for hash joins. It's not just a matter of
changing one file, it needs a rename, an update script with some sql,
and a change to the default version.

It was discovered because the version is in Join Filter and not Hash
Cond. Also in a test case, the cost estimate for the hash join was sky
high, which suggests that the actual hashing did not do the work it
should be doing.

The queries that gave rise to this filing are located here:

https://salsa.debian.org/lintian/lintian/merge_requests/252

Credit for finding this bug belongs to RhodiumToad from #postgresql,
who was copied on this message. Thank you!

Kind regards,
Felix Lechner

Bug#935638: ferm: ipv6 example should include mdns / hostmon / dhcpv6-client

[Andrea Borgia]

Package: ferm
Version: 2.4-1
Severity: wishlist

Dear Maintainer,

please consider adding the following section to the ipv6 example:
# mDNS
proto udp dport mdns ACCEPT;

# Link-local multicast
proto (tcp udp) dport hostmon ACCEPT;

# DHCPv6
proto udp dport dhcpv6-client ACCEPT;
(right after ident)

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

Kernel: Linux 5.0.2-19.03.18.amdgpu (SMP w/4 CPU cores)
Locale: LANG=it_IT.utf8, LC_CTYPE=it_IT.utf8 (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 ferm depends on:
ii  debconf  1.5.73
ii  init-system-helpers  1.57
ii  iptables 1.8.3-2
ii  lsb-base 11.1.0
ii  perl 5.28.1-6

Versions of packages ferm recommends:
ii  libnet-dns-perl  1.20-1

ferm suggests no packages.

-- Configuration Files:
/etc/ferm/ferm.conf [Errno 13] Permesso negato: '/etc/ferm/ferm.conf'

-- debconf information:
* ferm/enable: true

Bug#935604: gimp: Crash during selection to drawing

[Stephane]

Hello Bernhard,

Le 24/08/2019 à 17:28, Bernhard Übelacker a écrit :

I tried to get some more information from the backtrace and think
it would look like shown below [1].

It would show at least that there was some issue with the communication
to the X-server and it points to xcb_io.c, line 260 [2]:

throw_thread_fail_assert("Unknown sequence "
 "number while "
 "processing queue",

If you can trigger that crash reliably, you could start gimp
from a terminal with this command:

 script -a ~/gimp_$(date +%Y-%m-%d_%H-%M-%S).log -c "gimp"

This will create a file gimp_*.log in your home directory
and contains all output written from gimp to the terminal and
might contain the assert message above and maybe
even some error before.


I'll try to reproduce the crash... but I did many other similar 
selections->path->paint_along after and no crash happened.

I'm not sure I'll succeed...


Regards.

--

--
Stephane

Bug#874855: [codequery] Future Qt4 removal from Buster

[Reiner Herrmann]

Control: tags -1 + patch

Dear maintainer,

Qt5 is already supported and can be easily enabled with the attached
patch (which also fixes #886193).

Kind regards,
  Reiner
diff -Nru codequery-0.21.1+dfsg1/debian/control codequery-0.21.1+dfsg1/debian/control
--- codequery-0.21.1+dfsg1/debian/control	2018-10-31 07:51:35.0 +0100
+++ codequery-0.21.1+dfsg1/debian/control	2019-08-24 20:27:14.0 +0200
@@ -5,8 +5,10 @@
 Build-Depends: debhelper (>= 11),
asciidoc,
cmake,
-   libqscintilla2-dev,
+   libqscintilla2-qt5-dev,
libsqlite3-dev,
+   qtbase5-dev,
+   qttools5-dev,
xmlto,
 Standards-Version: 4.2.1
 Homepage: https://github.com/ruben2020/codequery
diff -Nru codequery-0.21.1+dfsg1/debian/rules codequery-0.21.1+dfsg1/debian/rules
--- codequery-0.21.1+dfsg1/debian/rules	2018-10-31 07:47:54.0 +0100
+++ codequery-0.21.1+dfsg1/debian/rules	2019-08-24 20:27:14.0 +0200
@@ -11,7 +11,7 @@
 override_dh_auto_configure:
 	cat debian/*manpages | sed 's/$$/.txt/p' | xargs -n 1 a2x --attribute=footer-style=none --doctype manpage --format manpage
 	perl -pi -e 's/build/obj-$(DEB_HOST_GNU_TYPE)/' gui/codequery.qrc
-	dh_auto_configure
+	dh_auto_configure -- -DBUILD_QT5=YES
 
 override_dh_clean:
 	dh_clean


signature.asc
Description: PGP signature

Bug#929720: hkl: FTBFS: ../../hkl/ccan/generator/generator.h:23:2: error: #error Generators require coroutines

[Santiago Vila]

Greetings.

I can reproduce this bug, and I've put a bunch of failed build logs here:

https://people.debian.org/~sanvila/build-logs/hkl/

The bug happens "randomly", but in a very particular way: always in some
instances and never in the others.

I believe this may be some sort of Makefile bug which is related to
filesystem ordering or something similar, but I don't really know.

In either case, I could easily offer ssh access to a machine where
this happens to anybody interested in debugging the problem (please
contact me privately for details).

While we are at it: I'm still doing QA for buster, so I'd appreciate
(once we find a fix) if we could fix this in buster as well (it's a
FTBFS bug after all). I would be willing to help if required, either
by preparing an upload for stable, filing a release.debian.org bug, or
both.

Thanks.

Bug#930562: Not migrated to testing yet

[Gabriel Filion]

On 2019-08-23 11:07 p.m., tony mancill wrote:
> On Fri, Aug 23, 2019 at 04:44:07PM -0400, Gabriel Filion wrote:
> From the PTS page [1], I see the excuse as:

> [1] https://tracker.debian.org/pkg/trapperkeeper-webserver-jetty9-clojure

> testing migrations
> excuses:
> - 38 days old (5 needed)
> - Piuparts tested OK - 
> https://piuparts.debian.org/sid/source/t/trapperkeeper-webserver-jetty9-clojure.html
> - Checking build-dependency on amd64
> - Not built on buildd: arch all binaries uploaded by apoi...@dmesg.gr
> - Not considered
> 
> Starting with buster, uploads must be source only and the binary
> packages built on the buildds in order to migrate to testing.

ah! I had looked at this list of reasons for non-migration, but I
couldn't understand that there was anything wrong from that text (e.g.
it's just stating that it wasn't built by buildd but it's not mentioning
that this is the reason for the auto migration not happening, one has to
know this extra information to understand the implications).

thanks for the explanation!

> I'll have a look at uploading a source package.

many thanks!



signature.asc
Description: OpenPGP digital signature

Bug#935636: ITP: crypto-policies - unify the crypto policies used by different applications and libraries

[Hideki Yamane]

Package: wnpp
Severity: wishlist

* Package name: crypto-policies
  Version : 20190816~git
  Upstream Author : Red Hat, Inc.
* URL : https://gitlab.com/redhat-crypto/fedora-crypto-policies/
* License : LGPL-2.1+
  Programming Lang: Python
  Description: unify the crypto policies used by different applications and 
libraries

 "crypto-policies" is a utility to unify the crypto policies used by different
 applications and libraries. The current implementations works by setting the
 desired policy in /etc/crypto-policies/config. After this file is changed
 the script 'update-crypto-policies' should be executed, and the new policies
 will activate.
 .
 The supported back ends are:
  - GnuTLS
  - OpenSSL
  - NSS
  - BIND9
  - libkrb5
  - OpenSSH
  - Java (OpenJDK)
  - libssh

Bug#934928: win32-loader FTBFS on stable - any idea ?

[Adam D. Barratt]

On Sat, 2019-08-24 at 18:49 +0200, Didier 'OdyX' Raboud wrote:
> @Adam: I assume I need to bump the version number and upload again,
> right? 

Yep.

(I assume the changelog etc still end up generated as UTF-8.)

Regards,

Adam

Bug#935243: Does not work with Thunderbird 6x (60+)

[Mechtilde Stehmann]

Package: webext-tbsync
Version: 1.7-1
Followup-For: Bug #935243

Hello,

you find a new package version 2.3 in experimental. there is thunderbird
(>=68), too.

your feedback is welcome.

-- 
Mechtilde Stehmann
## Debian Developer
## PGP encryption welcome
## F0E3 7F3D C87A 4998 2899  39E7 F287 7BBA 141A AD7F



signature.asc
Description: OpenPGP digital signature

Bug#794410: (no subject)

[Quentin Stafford-Fraser]

I encountered this issue trying to install Buster on a Gigabyte Brix 
2807 - hanging at 11% trying to install 'discover'.


Changing the BIOS setting for OS type from Windows 7 to Windows 8 also 
fixed it for me.


Thanks all,
Quentin

Bug#935635: elpa-agda2-mode: please rebuild against dh_elpa >= 1.16

[David Bremner]

Package: elpa-agda2-mode
Severity: important

dh_elpa 1.16 fixes a minor security issue.

I'd do it myself, but agda is currently unbuildable for me.


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

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

Versions of packages elpa-agda2-mode depends on:
pn  agda-bin 
ii  emacsen-common   3.0.4
pn  libghc-agda-dev  

Versions of packages elpa-agda2-mode recommends:
ii  emacs  1:26.1+1-3.3
ii  emacs-gtk [emacs]  1:26.1+1-3.3

elpa-agda2-mode suggests no packages.

Bug#935634: RM: mosquitto-auth-plugin -- NBS; Upstream dead

[Adam Majer]

Package: ftp.debian.org
Severity: normal

Package fails to build from source with current dependencies.
Upstream closed upstream project for personal reasons

Bug#874844: [choreonoid] Future Qt4 removal from Buster

[Reiner Herrmann]

Control: tags -1 + fixed-upstream

Qt5 is supported upstream since 1.5.0.


signature.asc
Description: PGP signature

Bug#935633: [UDD] add index for 'lintian'

[Felix Lechner]

Package: qa.debian.org
Severity: wishlist
User: qa.debian@packages.debian.org
Usertag: udd

Dear UDD Maintainer,

Pursuant to advice from #postgresql, the 'lintian' table would benefit
from an additional index. Will you please create it?

For a sample command, please see below.

Kind regards,
Felix Lechner

10:23 < RhodiumToad> the index you want on lintian then is lintian
(package_type, package, package_version, package_arch, tag_type)
10:37 < lechner> I am going to foward your index recommendation to the
UDD maintainer. Would you please provide an exact command?
10:37 < RhodiumToad> create index on public.lintian (package_type,
package, package_version, package_arch, tag_type);
10:37 < RhodiumToad> optionally specify an index name between "index" and "on"
10:38 < RhodiumToad> (postgres will pick a name if you don't)

Bug#935632: libreoffice-l10n-in should recommend libreoffice-l10n-kn and libreoffice-l10n-ne

[Jonas Smedegaard]

Package: libreoffice-l10n-in
Version: 1:6.3.0-2
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Binary package libreoffice-l10n-in is missing these packages for
languages spoken in India:

libreoffice-l10n-kn

libreoffice-l10n-ne


Kind regards,

 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAl1hd28ACgkQLHwxRsGg
ASHTkw/7B5hXRoqMrZ3XzMVP/I9N9PhzDltF2qVTQZY9XdeS+TBDA0SuAiGwS4rl
dM8kAU8tON0jrawfYfdAIVwquABsna5aqx29YshZumgHBENuL+bf5UVhgLZeK+YB
Q26B7WGOHKjy4R3Mr1DsI1gn2W38ItE35QieH/4gCIQhRmWP4ZUg7RvbampS6SQN
Q6Mf4KX/OqxjDiRwwzJOggSQPJXEBe3MtPGkfiOMxBaX1uUDczpYgMlf+SeaJPbw
L8lFUMBvnWuTLf+eL6hTbK9SkpQjeJaeBYApmluV/PwIvDpKQszBPS335AnCxxYz
5M02R9dY8jyrc0GS7DbIdwY4DEmknRDNj9nVroWq8DUL8dy+5L9V7kmYMPoZCuDZ
PVCckUGaMikogLaeDkYvkbKxkoNQvRYddxEMpQgK74tqa6ZgjX9C68EeBXDSc+Wd
rbANQpyfIgwI0tLyUsldMzqohfSjyMSuzA3Ar4D377C0NBTmDUEu622nNqBsGooR
hUG5DnOVzYTpGLpCQxPBpNnxbKHA5nFy916m2PzwnXxcT1UvSXQQeltdeHAc4qC9
wW1is2xOKQSl49H58tyhziNDEHsnAAe4lWhB0VitXUpQ7NPo1OfTEBGkw6Kgc3xs
QpYjuTnyI4pT94Y/KZuxmeAOsF7UaVVv6/j3DIN2ly56lGEOBu0=
=kqT+
-END PGP SIGNATURE-

Bug#935631: RM: quicksynergy -- RoQA; dependent on to-be-removed synergy, unmaintained

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove quicksynergy. It's a GUI for synergy which is scheduled for 
removal
and unmaintained (last upload in 2014). It already missed Buster as well.

Cheers,
Moritz

Bug#874825: [appmenu-qt] Future Qt4 removal from Buster

[Reiner Herrmann]

There is a Qt5 port available at: https://launchpad.net/appmenu-qt5


signature.asc
Description: PGP signature

Bug#935608: [Boxer-devel] Bug#935608: boxer-data: autopkgtest sort of depends on arora which is not in bullseye

[Jonas Smedegaard]

Hi Paul,

Quoting Paul Gevers (2019-08-24 15:37:13)
> I was looking into the failure of your package on the ci.debian.org 
> infrastructure when run in testing. One of your autopkgtests tries in 
> an obscure way to install arora, which isn't available in bullseye (or 
> even buster). Could you please have a look and improve your 
> autopkgtest? Is it really needed to install package in your test to 
> test boxer-data? It is very much recommended to just make your 
> autopkgtest depend on required packages. Obviously if it's the purpose 
> of your package to install stuff, that doesn't work.
> 
> If fixing the test itself is too difficult for now, can you at least 
> mark the test with a skippable restriction and exit with exit code 77 
> when apt installation fails? Mind you, because of the current 
> behavior, your autopkgtest will never block a package that makes your 
> package regress, as the reference is already failing.

Thanks for reporting,

The very purpose of the autopkgtest is indeed to test install routines.

I am fixing this issue now, and similar issues related to changes 
Firefox locale packages.


 - Jonas

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

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


signature.asc
Description: signature

Bug#935568: sphinx-issuetracker: should this package be removed?

[Dmitry Shachnev]

Hi Sandro!

On Fri, Aug 23, 2019 at 10:46:30PM -0400, Sandro Tosi wrote:
> Hello,
> sphinx-issuetracker is currently incompatible with python3.7:
> [...]
>
> It has no reverse-dependencies and it's currently one of the few r-deps of
> python-debianbts.
>
> Should we just remove this package from Debian?

I support the removal.

However, there is one reverse build-dependency: src:migrate.
But it looks like use of issuetracker is actually patched away:
https://sources.debian.org/src/migrate/0.12.0-3/debian/patches/disable_issuetracker.patch/

Dear migrate maintainers (Cc'ed), can you please check if that
build-dependency is still needed?

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#709114: cmus crashes on external command

[Ryan Kavanagh]

control: tags -1 + unreproducible moreinfo

Hi Adam,

On Mon, May 20, 2013 at 06:40:53PM -0400, Adam C. Emerson wrote:
> I have a shell script called 'share'
> And when I highlight a track and hit 'w' cmus crashes instantly.

I am unable to reproduce this. Is it still an issue with the version of
cmus found in the archives?

Thanks,
Ryan

-- 
|)|/  Ryan Kavanagh  | GPG: 4E46 9519 ED67 7734 268F
|\|\  https://rak.ac |  BD95 8F7B F8FC 4A11 C97A


signature.asc
Description: PGP signature

Bug#935453: libconfig-model-tkui-perl breaks libconfig-model-itself-perl autopkgtest

[Dominique Dumont]

On vendredi 23 août 2019 21:37:34 CEST you wrote:
> - ./Build realclean; perl Build.PL
> - prove fails

Do'h.. I'm so used to type "perl -Ilib t/*.t" that I forgot to remove the '-
Ilib'. 

Now I can reproduce this issue.

Turns out that the issue can be fixed in t/load_write_itself.t. I'm going to 
patch this test in libconfig-model-itself-perl.

Then I'll try to find a better solution upstream.

All the best

-- 
https://github.com/dod38fr/config-model/ -o- http://search.cpan.org/~ddumont/
http://ddumont.wordpress.com/-o-   irc: dod at irc.debian.org

Bug#818691: cmus: Segmentation fault when playing or adding WMA files to Library

[Ryan Kavanagh]

control: tag -1 + moreinfo unreproducible

Hi Carlo,

On Sat, Mar 19, 2016 at 07:55:29PM +0100, Carlo Morelli wrote:
> as per the subject, segmentation fault error is shown (and program
> crashes) when tring to add Windows Media Audio files to the library in
> select view 5 and pressing "a" on a directory containing the .wma files.
> When adding mp3 files/dirs to the library, no problem at all.

I am unable to reproduce this bug with the current version of cmus.
Could you please confirm that it is still an issue?

Thanks,
Ryan

-- 
|)|/  Ryan Kavanagh  | GPG: 4E46 9519 ED67 7734 268F
|\|\  https://rak.ac |  BD95 8F7B F8FC 4A11 C97A


signature.asc
Description: PGP signature

Bug#934928: win32-loader FTBFS on stable - any idea ?

[Didier 'OdyX' Raboud]

Hi there Simon,

thanks for the detailed investigation.

Le samedi, 24 août 2019, 11.52:53 h CEST Simon McVittie a écrit :
> On Fri, 23 Aug 2019 at 18:35:59 +0200, Didier 'OdyX' Raboud wrote:
> > I have uploaded win32-loader to buster to fix the out-of-sync archive
> > keys, but it has now repeatedly failed to build from source on the buster
> > buildds:
> > 
> > https://buildd.debian.org/status/logs.php?pkg=win32-loader=0.9.4%2Bdeb
> > 10u1
> > 
> > I can't reproduce this in a local buster schroot, so I'm slightly at loss.
> 
> I can reproduce this by trying to rebuild 0.9.4 in sbuild (a buster
> schroot created with sbuild-createchroot, hosted on a buster VM, using
> vectis[1]) if that's any help? Presumably there is some difference
> between your buster schroot and the one sbuild would use. See below
> for a full package list.

Yep. The difference I finally found was that the buildds use LANG=C.UTF-8 and 
LC_ALL=C.UTF-8 whereas mine was not enforcing these (and so I was building 
with LC_ALL=POSIX).

By fixing this, I could reproducibly fail to build win32-loader :-)

> > Unable to convert processed string "نوشتن ممکن نیست: " to codepage 1256
> 
> That string appears to be part of the Farsi (fa) translation of nsis,
> found in "Contrib/Language files/Farsi.nlf" in nsis_3.04-1. It is indeed
> not possible to convert it to Windows codepage 1256: (…)
> 
> (I don't know whether converting this string to CP1256 is an appropriate
> thing to be doing.)
> 
> If that's the problem, maybe it would be possible to work around this by
> adjusting or disabling the Farsi translation, or by replacing the use of
> CP1256 with UTF-16 or something?

Hrm. For a stable upload, this seems to be enough to let the build go through:

--- a/debian/rules
+++ b/debian/rules
@@ -24,6 +24,10 @@ BUILT_USING_LIST := $(shell set -e; \
 
 NSIS_VERSION  := $(shell dpkg-query -f='$${Version}' -W nsis )
 
+# A non-UTF-8 locale is needed for the NSIS build to convert some language 
strings
+LC_ALL := POSIX
+export LC_ALL
+
 %:
dh $@
 
Any idea of a more targeted fix?

@Adam: I assume I need to bump the version number and upload again, right? 
(debdiff attached)

Cheers,
OdyXdiff -Nru win32-loader-0.9.4+deb10u1/debian/changelog win32-loader-0.9.4+deb10u2/debian/changelog
--- win32-loader-0.9.4+deb10u1/debian/changelog	2019-08-16 08:53:00.0 +0200
+++ win32-loader-0.9.4+deb10u2/debian/changelog	2019-08-24 18:44:18.0 +0200
@@ -1,3 +1,9 @@
+win32-loader (0.9.4+deb10u2) buster; urgency=medium
+
+  * Fix stable FTBFS through enforcing LC_ALL=POSIX
+
+ -- Didier Raboud   Sat, 24 Aug 2019 18:44:18 +0200
+
 win32-loader (0.9.4+deb10u1) buster; urgency=medium
 
   * Rebuild in stable to embed the latest debian-archive-keyring
diff -Nru win32-loader-0.9.4+deb10u1/debian/rules win32-loader-0.9.4+deb10u2/debian/rules
--- win32-loader-0.9.4+deb10u1/debian/rules	2019-08-16 08:53:00.0 +0200
+++ win32-loader-0.9.4+deb10u2/debian/rules	2019-08-24 18:44:18.0 +0200
@@ -24,6 +24,10 @@
 
 NSIS_VERSION  := $(shell dpkg-query -f='$${Version}' -W nsis )
 
+# A non-UTF-8 locale is needed for the NSIS build to convert some language strings
+LC_ALL := POSIX
+export LC_ALL
+
 %:
 	dh $@
 


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

Bug#801388: cmus fails to show tracks in library

[Ryan Kavanagh]

Control: tags -1 + moreinfo
Control: severity -1 normal

Hi himiko,

On Sat, Oct 10, 2015 at 12:00:08AM +1100, himiko wrote:
> * Installed CMUS, ":a ~/Music" to add my music folder, and track list
>   was empty
> * Empty track list 
> * All of the tracks to come up normally, as they do in screenshots

I am unable to reproduce this bug. Could you please specify which track
list was empty, and what you mean by "empty track list"? When I add a
directory to my library, it appears under the "tree view" (:view tree),
and under the "sorted view" (:view sorted).

Thanks,
Ryan

-- 
|)|/  Ryan Kavanagh  | GPG: 4E46 9519 ED67 7734 268F
|\|\  https://rak.ac |  BD95 8F7B F8FC 4A11 C97A


signature.asc
Description: PGP signature