Bug#960639: [Debian-med-packaging] Bug#960639: src:orthanc-imagej: Please add support to build against libjson-simple-java >= 3

[Sébastien Jodogne]

Hello,

I thank you much for your patch.

As far as I'm concerned, I don't have time to have a look at this
problem in the upstream project before several months. The Orthanc
project is indeed under heavy pressure because of the COVID crisis, and
ImageJ support is not urgent in this context.

Regarding Debian packaging, I'm currently focused on the C++ packages
related to Orthanc, which doesn't include the "orthanc-imagej" package
(Java).

I suggest thus two possibilities:

(1) Someone else integrates Gilles' patch, or

(2) orthanc-imagej is temporarily removed from unstable.

As written above, unfortunately, I won't have a look at these two
possibilities by myself right now. Any help from another Debian
maintainer is thus welcome, feel free to take care of the
"orthanc-imagej" package.

Kind Regards,
Sébastien-


On 15/05/20 00:23, Gilles Filippini wrote:
> Package: src:orthanc-imagej
> Version: 1.2+dfsg-1
> Severity: normal
> Tags: patch
>
> Hi,
> 
> I'd like to transition json-simple 3.1.1 to unstable, but orthanc-imagej is a 
> blocker since it builds against libjson-simple-java << 3 only.
> 
> The json-simple classes used by orthanc-imagej were deprecated in version 
> 2.0.0 [1]. There were removed in versions 3.x [2].
> 
> [1] 
> https://github.com/cliftonlabs/json-simple/blob/json-simple-2.0.0/README.txt
> [2] 
> https://github.com/cliftonlabs/json-simple/blob/json-simple-3.0.1/CHANGELOG
> 
> Please find attached a patch proposal to use the current json-simple classes. 
> I've tested that the package builds correctly against libjson-simple-java 
> version 2.3.0-1 from unstable and version 3.1.1-1~exp2 currently in 
> experimental. But I don't known how to test the package afterward.
> 
> Thanks in advance for considering.
> 
> _g.
> 
> -- System Information:
> Debian Release: buster/sid
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 5.6.0-1-amd64 (SMP w/4 CPU cores)
> 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
> 
>
>
> ___
> Debian-med-packaging mailing list
> debian-med-packag...@alioth-lists.debian.net
>
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging
>

-- 
Sébastien Jodogne
Mail: s.jodo...@orthanc-labs.com
Web: http://www.orthanc-labs.com/
Twitter: https://twitter.com/sjodogne

Bug#960369: fiona: FTBFS with GDAL 3.1.0 (test failures)

[Sebastiaan Couwenberg]

Control: tags -1 pending

The tests were already fixed upstream, those changes have been included
as a patch.

A new upload will follow once fontconfig is fixed to no longer cause the
build dependencies to be uninstallable.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#960649: RM: gfal2 [arm64] -- ROM; NBS

[Mattias Ellert]

Package: ftp.debian.org
Severity: normal

Hi!

According to https://packages.debian.org/sid/gfal2 the available
versions of the gfal2 binary package in unstable are:

ArchitectureVersion
all 2.17.3-1
arm64 (unofficial port) 2.6.8-1

The gfal2 binary package was changed from arch dependent (any) to
architecture independent (all) in version 2.10.2-1 (2015-12-02).

For some reason an old architecture dependent version of the binary
package seems to have been left behind in unstable for the arm64
architecture.

According to https://wiki.debian.org/ftpmaster_Removals Binary packages
no longer built from any source package ("NBS", i.e. "not built from
source") should be handles automatically and a removal request should
not be needed, but there seems to be some glitch here?

Mattias



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

Bug#960608: Bison 3.6.1 generates (internal) tokentype and (yyerror) function with same name: _error

[Akim Demaille]

Hi!

> Le 14 mai 2020 à 18:47, Chuan-kai Lin  a écrit :
> 
> Hi Akim,
> 
> I am forwarding a bug report that the libexplain and the fhist Debian
> packages fail to build with Bison 3.6.1.
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=960608
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/libexplain.html
> 
> I have also attached the build log with this email.  Can you look into
> this issue and see if it is a bug in Bison?  Thanks!

In the log file you sent, I see:

> libtool: compile:  gcc -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 
> -ffile-prefix-map=/build/1st/libexplain-1.4.D001=. -fstack-protector-strong 
> -Wformat -Werror=format-security -Wall -Wextra -Wl,--as-needed -I. -c 
> libexplain/acl_get_file_or_die.c -o libexplain/acl_get_file_or_die.o 
> >/dev/null 2>&1
> bison -y -d  libexplain/acl_grammar.y
> libexplain/acl_grammar.y:62.16-18: warning: POSIX yacc reserves %type to 
> nonterminals [-Wyacc]
>62 | %type  TAG
>   |^~~
> libexplain/acl_grammar.y:63.19-24: warning: POSIX yacc reserves %type to 
> nonterminals [-Wyacc]
>63 | %type  NUMBER
>   |   ^~
> libexplain/acl_grammar.y:66.18-22: warning: POSIX yacc reserves %type to 
> nonterminals [-Wyacc]
>66 | %type  PERMS
>   |  ^
> libexplain/acl_grammar.y:68.17-20: warning: POSIX yacc reserves %type to 
> nonterminals [-Wyacc]
>68 | %type  NAME
>   | ^~~~
> sed -e 's/[yY][yY]/acl_grammar_/g' -e '//d' -e \
>   '//d' -e '//d' y.tab.c > \
>   libexplain/acl_grammar.yacc.c
> sed -e 's/[yY][yY]/acl_grammar_/g' -e \
>   's/Y_TAB_H/libexplain_acl_grammar_YACC_H/g' y.tab.h > \
>   libexplain/acl_grammar.yacc.h

The last two lines are not coming from Bison, and they are smashing
both YYerror and yyerror to acl_grammar_error.  So of course, it fails.

I don't understand why this is done this way.  The grammar file should use
%define api.prefix {acl_grammar_}, or the build system should pass
-Dapi.prefix={acl_grammar_}, or the sed sequence should be less crude.
I would go for

s/yy/acl_grammar_/g; s/YY/ACL_GRAMMAR_/g;

But if this is not ok, and the package still wants to smash yy and YY
to the same string, you could *prepend* this to the sed grammar:

s/YYerror/yyerror_token/g;

so that yyerror becomes acl_grammar_error, and YYerror become
acl_grammar_error_token.  But of course next time we introduce another
symbol which differs by the case of the prefix, the problem will
be back.

Cheers!

Bug#960138: ITA: rtax -- Classification of sequence reads of 16S ribosomal RNA gene

[atzlinux 肖盛文]

Control: owner 960138 !

Control:retitle 960138 ITA: rtax -- Classification of sequence reads of
16S ribosomal RNA gene



-- 
肖盛文 Faris Xiao
微信：atzlinux
ＱＱ：909868357
铜豌豆 Linux 
基于 Debian 的 Linux 中文桌面操作系统：https://www.atzlinux.com



signature.asc
Description: OpenPGP digital signature

Bug#960648: RFS: gitid/0.3.1-1 [ITP] -- simple, minimal git identity management tool

[Luiserebii]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

* Package name : gitid
Version : 0.3.1-1
Upstream Author : Luiserebii 
* URL : https://github.com/Luiserebii/gitid
* License : GPL-3+
* Vcs : https://github.com/Luiserebii/gitid/tree/debian-pkg
Section : devel

It builds those binary packages:

gitid - simple, minimal git identity management tool

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


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

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

dget -x 
https://mentors.debian.net/debian/pool/main/g/gitid/gitid_0.3.1-1.dsc


Changes since the last upload:

* Initial release. Closes: #959992.

Regards,
Luiserebii

Bug#960647: RFS: lunar/2.2-7 -- Chinese Lunar Calendar conversion utility

[atzlinux 肖盛文]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

* Package name : lunar
Version : 2.2-7
Upstream Author : Fung F. Lee 
* URL :
https://web.archive.org/web/20051027042122/https://umunhum.stanford.edu/~lee/chicomp/chicomp.html
* License : GPL-2+
* Vcs : https://salsa.debian.org/chinese-team/lunar
Section : utils

It builds those binary packages:

lunar - Chinese Lunar Calendar conversion utility

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

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

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

dget -x https://mentors.debian.net/debian/pool/main/l/lunar/lunar_2.2-7.dsc

Changes since the last upload:

[ 肖盛文 ]
* d/rules:
- export DEB_BUILD_MAINT_OPTIONS = hardening=+all
- use patch to fix make clean error
* d/control:
- Bump Standards-Version: 4.5.0
- Bump debhelper-compat (= 13)
- Rules-Requires-Root: no
- New Uploaders: xiao sheng wen 
- update Vcs-Git Vcs-Browser url
* d/copyright:
- use /usr/share/common-licenses/GPL-2
- use https for copyright-format-uri
- add Files: * line
* d/watch:
- update to version 4
- use https for url
* update version and release time info in patch files

Regards,

-- 
肖盛文 Faris Xiao
微信：atzlinux
ＱＱ：909868357
铜豌豆 Linux 
基于 Debian 的 Linux 中文桌面操作系统：https://www.atzlinux.com




signature.asc
Description: OpenPGP digital signature

Bug#960562: [Aptitude-devel] Bug#960562: had to reinstall a package to avoid 'bullying'

[Axel Beckert]

Control: tag -1 + unreproducible moreinfo

Hi,

Sven Joachim wrote:
> On 2020-05-14 06:48 +0800, 積丹尼 Dan Jacobson wrote:
> 
> > Package: aptitude
> > Version: 0.8.12-3
> >
> > Odd, today I had to reinstall a package to get aptitude to stop trying
> > to get rid of it.
> 
> The package in question has been marked as automatically installed and
> there are no longer any reverse dependencies.

Yep, the "u" in "{pu}" hints that, so that's also my suspicion.

Unfortunately the bug report doesn't provide that information. And Dan
probably hasn't called aptitude-create-state-bundle before forcefully
fixing the situation. That oesn't leave a chance to investigate this
properly, i.e. we might never know what really caused it. :-/

> The easiest way to keep it would be "aptitude unmarkauto fdisk".

Correct.

> > # aptitude install fdisk
> > fdisk is already installed at the requested version (2.35.1-5)
> > fdisk is already installed at the requested version (2.35.1-5)
> > The following packages will be REMOVED:
> >   fdisk{pu}

Point is, I can't reproduce it:

# aptitude markauto zsh-dbgsym
# aptitude install zsh-dbgsym
zsh-dbgsym is already installed at the requested version (5.8-4)
zsh-dbgsym is already installed at the requested version (5.8-4)
No packages will be installed, upgraded, or removed.
0 packages upgraded, 0 newly installed, 0 to remove and 13 not upgraded.
Need to get 0 B of archives. After unpacking 0 B will be used.
# aptitude show zsh-dbgsym
Package: zsh-dbgsym
Version: 5.8-4
State: installed
Automatically installed: no
[...]

Same with fdisk:

# aptitude markauto fdisk
# aptitude install fdisk
fdisk is already installed at the requested version (2.35.1-5)
fdisk is already installed at the requested version (2.35.1-5)
No packages will be installed, upgraded, or removed.
0 packages upgraded, 0 newly installed, 0 to remove and 13 not upgraded.
Need to get 0 B of archives. After unpacking 0 B will be used.
# aptitude show fdisk
Package: fdisk
Version: 2.35.1-5
State: installed
Automatically installed: yes
[...] 

The only thing I currently can't explain is why this once results in
"Automatically installed: no" and once in "Automatically installed:
yes".

Since I have a non-standard aptitude config, I also tried in a clean
pbuilder chroot:

# apt install fdisk
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following NEW packages will be installed:
  fdisk libfdisk1
0 upgraded, 2 newly installed, 0 to remove and 0 not upgraded.
Need to get 416 kB of archives.
After this operation, 1063 kB of additional disk space will be used.
Get:1 http://debian.ethz.ch/debian sid/main amd64 libfdisk1 amd64 2.35.1-5 [231 
kB]
Get:2 http://debian.ethz.ch/debian sid/main amd64 fdisk amd64 2.35.1-5 [184 kB]
Fetched 416 kB in 0s (3948 kB/s)
debconf: delaying package configuration, since apt-utils is not installed
Selecting previously unselected package libfdisk1:amd64.
(Reading database ... 13343 files and directories currently installed.)
Preparing to unpack .../libfdisk1_2.35.1-5_amd64.deb ...
Unpacking libfdisk1:amd64 (2.35.1-5) ...
Selecting previously unselected package fdisk.
Preparing to unpack .../fdisk_2.35.1-5_amd64.deb ...
Unpacking fdisk (2.35.1-5) ...
Setting up libfdisk1:amd64 (2.35.1-5) ...
Setting up fdisk (2.35.1-5) ...
Processing triggers for libc-bin (2.30-8) ...
# aptitude markauto fdisk
# aptitude install fdisk
fdisk is already installed at the requested version (2.35.1-5)
fdisk is already installed at the requested version (2.35.1-5)
The following packages will be REMOVED:
  libfdisk1{u}
0 packages upgraded, 0 newly installed, 1 to remove and 0 not upgraded.
Need to get 0 B of archives. After unpacking 549 kB will be freed.
The following packages have unmet dependencies:
 fdisk : Depends: libfdisk1 (>= 2.33) but it is not going to be installed
The following actions will resolve these dependencies:

 Keep the following packages at their current version:
1) libfdisk1 [2.35.1-5 (now, unstable)]



Accept this solution? [Y/n/q/?]

Now this is even more confusing (still kinda explainable), but still
not the same.

> There might be some arguments for "aptitude install " to clear
> the automatic flag

Unsure, see above. I thought though, too, that it does not change the
flag.

> (IIRC apt and apt-get do that),

Correct. (And I'm annoyed by that behaviour.)

The only way I could reproduce this was to install it and saying in
the same command to mark it as automatically installed:

# aptitude install zsh-dbgsym\
The following packages will be REMOVED:
  zsh-dbgsym{u}
0 packages upgraded, 0 newly installed, 1 to remove and 13 not upgraded.
Need to get 0 B of archives. After unpacking 2066 kB will be freed.
Do you want to continue? [Y/n/?]
  
>From numerous other bug reports I know that Dan has a quite unique
aptitude configuration. (Also can be seen by the "p" in "{pu}" as that
indicates that Aptitude::Purge-Unused is being set.)

So my only explanation so 

Bug#960646: fail2ban: nftables fails with Error: Could not process rule: No such file or directory

[Allan Wind]

Package: fail2ban
Version: 0.10.2-2.1
Severity: normal

Dear Maintainer,

I have been using fail2ban for a long time with iptables-allports:

banaction = iptables-allports
banaction = iptables-allports

With over 50k+ IPs being banned I figured that I might benefit from the
perceived lower overhead of nftables so changed it to:

banaction = nftables-allports
banaction_allports = nftables-allports

fail2ban was immediately reporting errors when I started it:

2020-05-15T02:08:51.213+00:00 pawan fail2ban-server[21504]: 
fail2ban.utils  [21504]: Level 39 7f227a456760 -- exec: nft add 
set inet filter f2b-sshd \{ type ipv4_addr\; \}
nft insert rule inet filter INPUT meta l4proto tcp ip saddr @f2b-sshd 
reject
2020-05-15T02:08:51.213+00:00 pawan fail2ban-server[21504]: 
fail2ban.utils  [21504]: ERROR   7f227a456760 -- stderr: 'Error: 
Could not process rule: No such file or directory'
2020-05-15T02:08:51.213+00:00 pawan fail2ban-server[21504]: 
fail2ban.utils  [21504]: ERROR   7f227a456760 -- stderr: 'add 
set inet filter f2b-sshd { type ipv4_addr; }'
2020-05-15T02:08:51.213+00:00 pawan fail2ban-server[21504]: 
fail2ban.utils  [21504]: ERROR   7f227a456760 -- stderr: ' 
^^'
2020-05-15T02:08:51.213+00:00 pawan fail2ban-server[21504]: 
fail2ban.utils  [21504]: ERROR   7f227a456760 -- stderr: 'Error: 
Could not process rule: No such file or directory'
2020-05-15T02:08:51.213+00:00 pawan fail2ban-server[21504]: 
fail2ban.utils  [21504]: ERROR   7f227a456760 -- stderr: 'insert 
rule inet filter INPUT meta l4proto tcp ip saddr @f2b-sshd reject'
2020-05-15T02:08:51.213+00:00 pawan fail2ban-server[21504]: 
fail2ban.utils  [21504]: ERROR   7f227a456760 -- stderr: '  
   
^^'
2020-05-15T02:08:51.213+00:00 pawan fail2ban-server[21504]: 
fail2ban.utils  [21504]: ERROR   7f227a456760 -- returned 1

I found, through trial and error, that the issue appears to be
nftables_family = inet so I added action.d/nftables-common.local
file with:

[Init]
nftables_family = ip

Which seem to work.

Looked at the current upstream version and it's configuration file
is significantly different to the one that ships it buster to easily 
compare.  It does appear though, that they set to inet so not sure
what the deal is.

Happy to help,


/Allan

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

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

Versions of packages fail2ban depends on:
ii  lsb-base  10.2019051400
ii  python3   3.7.3-1

Versions of packages fail2ban recommends:
ii  iptables   1.8.2-4
ii  nftables   0.9.0-2
ii  python 2.7.16-1
ii  python3-pyinotify  0.9.6-1
ii  python3-systemd234-2+b1
ii  whois  5.4.3

Versions of packages fail2ban suggests:
ii  mailutils [mailx]   1:3.5-3
pn  monit   
ii  sqlite3 3.27.2-3
ii  syslog-ng-core [system-log-daemon]  3.19.1-5

-- Configuration Files:
/etc/fail2ban/fail2ban.conf changed:
[Definition]
loglevel = INFO
logtarget = SYSLOG
syslogsocket = auto
socket = /var/run/fail2ban/fail2ban.sock
pidfile = /var/run/fail2ban/fail2ban.pid
dbfile = /var/lib/fail2ban/fail2ban.sqlite3
dbpurgeage = 1d

/etc/fail2ban/filter.d/apache-common.conf changed:
[INCLUDES]
after = apache-common.local
[DEFAULT]

/etc/fail2ban/filter.d/postfix.conf changed:
[INCLUDES]
before = common.conf
[Definition]
_daemon = postfix/(submission/)?smtpd
failregex =
^%(__prefix_line)simproper command pipelining after \S+ from 
[^[]*\[\]:?$
^%(__prefix_line)slost connection after (AUTH|CONNECT) from 
.+\[\]$
^%(__prefix_line)sNOQUEUE: reject: RCPT from \S+\[\]: 450 4\.7\.1 
: Helo command rejected: Host not found; from=<> to=<> proto=ESMTP helo= *$
^%(__prefix_line)sNOQUEUE: reject: RCPT from \S+\[\]: 554 5\.7\.1 
.*$
^%(__prefix_line)sNOQUEUE: reject: VRFY from \S+\[\]: 550 5\.1\.1 
.*$
^%(__prefix_line)sSSL_accept error from .+\[\]: (-1|0)
^%(__prefix_line)swarning: .*\[\]: SASL LOGIN authentication 
failed: Invalid authentication mechanism
^%(__prefix_line)swarning: .+\[\]: SASL PLAIN authentication 
failed: Connection lost to authentication server
^%(__prefix_line)swarning: Connection concurrency limit exceeded: 
[0-9]+ from .+\[\] for service smtp$
^%(__prefix_line)swarning: non-SMTP command from.+\[\]:
^%(__prefix_line)swarning: numeric hostname: $
ignoreregex = 
 ^%(__prefix_line)slost connection after CONNECT from unknown\[unknown\]

/etc/fail2ban/filter.d/sshd.conf changed:

Bug#959798: [Pkg-javascript-devel] Bug#959798: libjs-webrtc-adapter ftbfs with node-grunt-babel 8.0 (using babel 7.4) in experimental

[Pirate Praveen]

On Thu, May 14, 2020 at 5:30 pm, Jonas Smedegaard  
wrote:

No, fails.

The package now checks unit tests during build, and switching to 
Babel 7

causes one of those to fail:

not ok 69 Log suppression "before each" hook for "does not call 
console.log by default"

  Cannot find module ./utils


I think it is a bug in node-browserify-lite (that is cannot handle code 
generated by babel 7). I can see utils.js is present in dist but it did 
not get bundled correctly. I could get the tests to pass when using 
webpack instead of browserify-lite.


With debian/webpack.config.js,

'use strict';
var path = require('path');
var config = {
 target: 'node',
 resolve: {
modules: ['/usr/share/nodejs', '/usr/lib/nodejs'],
 },
 resolveLoader: {
modules: ['/usr/share/nodejs'],
 },
 output: {
   libraryTarget: 'umd'
 },
 module: { rules: [ { use: [ 'babel-loader' ] } ] }
}
module.exports = config;

and calling webpack --config debian/webpack.config.js -n adapter -f umd 
dist/adapter_core5.js -o out/adapter.js


has passing tests. I have pushed my rough changes in babel7 branch. I 
don't use babel-loader here (just copied an old configuration), may be 
you can use babel-loader and pass src/js directly to webpack instead of 
babeljs.

Bug#960143: sagetex: FTBFS in unstable

[Norbert Preining]

Hi John,

> There are strange discrepancies in the tar files and one upload was
> rejected. I will retry.

I manually built a package and worked around the checksum discrepancies,
package is now accepted into unstable.

Norbert

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

Bug#953403: ITP: golang-k8s-sigs-structured-merge-diff -- Test cases and implementation for "server-side apply"

[Tong Sun]

On Thu, May 14, 2020 at 10:50 PM Tong Sun
 wrote:
>
> Oh, I realize why I stopped --
>
> I removed the `vendor` folder from the salsa repo, but when building, I'm 
> getting the following error:
>
> E: golang-k8s-sigs-structured-merge-diff source: 
> source-includes-file-in-files-excluded vendor/gopkg.in/yaml.v2/parserc.go
> E: golang-k8s-sigs-structured-merge-diff source: 
> source-includes-file-in-files-excluded vendor/gopkg.in/yaml.v2/readerc.go
> . . .
>
> and I wasn't able to and haven't found the solution yet.
>
> Would you quickly point me in the right direction please? thx a lot.

NVM, solved it now.

> On Wed, May 13, 2020 at 8:30 AM Tong Sun  
> wrote:
>>
>> Oh, I didn't know that anyone was depending on it.
>>
>> I'll get it packed in a day or two.
>>
>> thx
>>
>> On Wed, May 13, 2020 at 2:12 AM Shengjing Zhu  wrote:
>> >
>> > On Mon, Mar 9, 2020 at 11:42 AM Tong Sun
>> >  wrote:
>> > >
>> > > Package: wnpp
>> > > Severity: wishlist
>> > > Owner: Tong Sun 
>> > >
>> > > * Package name: golang-k8s-sigs-structured-merge-diff
>> > >   Version : 3.0.0-1
>> > >   Upstream Author : Kubernetes SIGs
>> > > * URL : 
>> > > https://github.com/kubernetes-sigs/structured-merge-diff
>> > > * License : Apache-2.0
>> > >   Programming Lang: Go
>> > >   Description : Implementation for "server-side apply"
>> > >
>> > > Structured Merge and Diff. It implements the Kubernetes "APPLY" 
>> > > operation,
>> > > apart from the PUT/PATCH operations.
>> > >
>> > > Dependency of github.com/google/go-containerregistry &
>> > > github.com/GoogleContainerTools/container-diff.
>> > >
>> >
>> > Are you still working on it? Since it's a tiny library, can I just take it?
>> >
>> > --
>> > Shengjing Zhu

Bug#953403: ITP: golang-k8s-sigs-structured-merge-diff -- Test cases and implementation for "server-side apply"

[Tong Sun]

Oh, I realize why I stopped --

I removed the `vendor` folder from the salsa repo, but when building, I'm
getting the following error:

E: golang-k8s-sigs-structured-merge-diff source:
source-includes-file-in-files-excluded vendor/gopkg.in/yaml.v2/parserc.go
E: golang-k8s-sigs-structured-merge-diff source:
source-includes-file-in-files-excluded vendor/gopkg.in/yaml.v2/readerc.go
. . .

and I wasn't able to and haven't found the solution yet.

Would you quickly point me in the right direction please? thx a lot.




On Wed, May 13, 2020 at 8:30 AM Tong Sun 
wrote:

> Oh, I didn't know that anyone was depending on it.
>
> I'll get it packed in a day or two.
>
> thx
>
> On Wed, May 13, 2020 at 2:12 AM Shengjing Zhu  wrote:
> >
> > On Mon, Mar 9, 2020 at 11:42 AM Tong Sun
> >  wrote:
> > >
> > > Package: wnpp
> > > Severity: wishlist
> > > Owner: Tong Sun 
> > >
> > > * Package name: golang-k8s-sigs-structured-merge-diff
> > >   Version : 3.0.0-1
> > >   Upstream Author : Kubernetes SIGs
> > > * URL :
> https://github.com/kubernetes-sigs/structured-merge-diff
> > > * License : Apache-2.0
> > >   Programming Lang: Go
> > >   Description : Implementation for "server-side apply"
> > >
> > > Structured Merge and Diff. It implements the Kubernetes "APPLY"
> operation,
> > > apart from the PUT/PATCH operations.
> > >
> > > Dependency of github.com/google/go-containerregistry &
> > > github.com/GoogleContainerTools/container-diff.
> > >
> >
> > Are you still working on it? Since it's a tiny library, can I just take
> it?
> >
> > --
> > Shengjing Zhu
>

Bug#960143: sagetex: FTBFS in unstable

[Norbert Preining]

> > Uploading in the a few minutes, after the binary build succeeded.
> 
> Just a ping in case you've moved on

There are strange discrepancies in the tar files and one upload was
rejected. I will retry.

Best

Norbert

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

Bug#960644: valgrind: Doesn't support D programming language demangling

[Witold Baryluk]

Package: valgrind
Version: 1:3.15.0-1
Severity: normal

It looks like valgrind doesn't support D programming language symbol
mangling (as emitted by DMD, GDC or LDC2 compilers);

==29535== valgrind: Unrecognised instruction at address 0x1b38db.
==29535==at 0x1B38DB: _D3rcu__T3RCUTSQn1AZQl6updateMFNbPQuZv (rcu.d:390)
==29535==by 0x1B2F6F: _D3rcu6writerFZv (rcu.d:96)
==29535==by 0x1B3230: _D3rcu4mainFAAyaZ9__lambda3FZv (rcu.d:600)
==29535==by 0x1E52B7: _D4core6thread8osthread6Thread3runMFZv (in 
/home/user/vps1/home/baryluk/Projekty/rcu.d/rcu)
==29535==by 0x1FE929: thread_entryPoint (in 
/home/user/vps1/home/baryluk/Projekty/rcu.d/rcu)
==29535==by 0x487DF26: start_thread (pthread_create.c:479)
==29535==by 0x49AD31E: clone (clone.S:95)

That is a bit unfortunate. Most of this compilers allow to emulate "C"
mangling in debug symbols (ldc2 -gc), but it interferes with other
things, and is not supported everywhere.

gdb and objdump do demangle D symbols very well. I hope valgrind could pick it 
up too?


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

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

Versions of packages valgrind depends on:
ii  libc6  2.30-8
ii  libc6-dbg  2.30-8

Versions of packages valgrind recommends:
ii  gdb   9.1-3
ii  valgrind-dbg  1:3.15.0-1

Versions of packages valgrind suggests:
pn  alleyoop  
ii  kcachegrind   4:19.08.1-1+b1
pn  valgrind-mpi  
pn  valkyrie  

-- no debconf information

Bug#960645: firefox: Please build with WebRTC pipewire support for GNOME Wayland

[Changwoo Ryu]

Package: firefox
Version: 76.0.1-1
Severity: normal

Hello,

Currently in Firefox, WebRTC screen capture works only on X11. In Wayland, 
only XWayland windows can be captured.

Wayland doesn't support screen capture by defaults but GNOME supports the 
feature
using pipewire. The pipewire support is already in Firefox source since version 
68 
(media/webrtc/trunk/webrtc/modules/desktop_capture/linux/base_capturer_pipewire.*)
but it is not built as a default.

Debian GNOME desktop is running on Wayland as defaults since buster, and its
default browser is Firefox. So I think the Debian Firefox package needs to be 
built with pipewire capture support.

In Fedora, pipewire support is enabled with this patch:
https://src.fedoraproject.org/rpms/firefox/blob/master/f/firefox-pipewire.patch


-- Package-specific info:


-- Addons package information

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

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

Versions of packages firefox depends on:
ii  debianutils 4.9.1
ii  fontconfig  2.13.1-4.1
ii  libatk1.0-0 2.36.0-2
ii  libc6   2.30-8
ii  libcairo-gobject2   1.16.0-4
ii  libcairo2   1.16.0-4
ii  libdbus-1-3 1.12.16-2
ii  libdbus-glib-1-20.110-5
ii  libevent-2.1-7  2.1.11-stable-1
ii  libffi7 3.3-4
ii  libfontconfig1  2.13.1-4
ii  libfreetype62.10.1-2
ii  libgcc-s1   10.1.0-1
ii  libgdk-pixbuf2.0-0  2.40.0+dfsg-4
ii  libglib2.0-02.64.2-1
ii  libgtk-3-0  3.24.20-1
ii  libnspr42:4.25-1
ii  libnss3 2:3.52-1
ii  libpango-1.0-0  1.44.7-4
ii  libstdc++6  10.1.0-1
ii  libvpx6 1.8.2-dmo1
ii  libx11-62:1.6.9-2+b1
ii  libx11-xcb1 2:1.6.9-2+b1
ii  libxcb-shm0 1.14-2
ii  libxcb1 1.14-2
ii  libxcomposite1  1:0.4.5-1
ii  libxdamage1 1:1.1.5-2
ii  libxext62:1.3.3-1+b2
ii  libxfixes3  1:5.0.3-2
ii  libxrender1 1:0.9.10-1
ii  libxt6  1:1.1.5-1+b3
ii  procps  2:3.3.16-4
ii  zlib1g  1:1.2.11.dfsg-2

Versions of packages firefox recommends:
ii  libavcodec58  10:4.2.2-dmo8

Versions of packages firefox suggests:
ii  fonts-lmodern  2.004.5-6
pn  fonts-stix | otf-stix  
ii  libcanberra0   0.30-7
ii  libgssapi-krb5-2   1.17-7
ii  libgtk2.0-02.24.32-4
ii  pulseaudio 13.0-5

-- no debconf information

Bug#960143: sagetex: FTBFS in unstable

[John Scott]

On Mon, 11 May 2020 19:57:52 +0900 Norbert Preining  
wrote:
> Uploading in the a few minutes, after the binary build succeeded.

Just a ping in case you've moved on

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

Bug#960591: mistral: please make the build reproducible

[Vagrant Cascadian]

On 2020-05-14, Chris Lamb wrote:
> Source: mistral
> Version: 10.0.0-1
> Severity: wishlist
> Tags: patch
...
> This is because some help output enumerated the constants in a Python
> set without a sort which does not have an implicitly deterministic
> ordering. Patch attached that applies a sort to the list.

empty patch?

live well,
  vagrant

Bug#960045: RFP: protonmail-bridge -- seamless mail encryption/decryption for ProtonMail

[Cyril Brulebois]

Hi,

ba...@debian.org  (2020-05-08):
> close 960045
> stop
> there is already an ITP
> ITP https://bugs.debian.org/959145
> RFP https://bugs.debian.org/960045

For the record, I'm only noticing your message now because I went back
to the BTS to see if there were any messages I could have missed… and
there was.

Mailing a close to control@ only doesn't really help anyone see what's
going on.

(Also, not sure why reportbug wnpp didn't find the existing ITP, but
that's another topic.)



Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#960643: gdc-10: manpage and gdc --help doesn't mention -fmain

[Witold Baryluk]

Package: gdc-10
Version: 10.1.0-1
Severity: normal

It is common to provide unittests for module in the module, but without
main, so the module can be used as a library.

For this reasons, to test just one module one need to provide a dummy main 
function when linking.

-fmain does this autoamtically in gdc.

This feature is also available in dmd (-main) and in ldc2 (--main, not
mentioned in the manpage, but shows in ldc2 --help).

So the option in gdc is there, it is just not mentioned in gdc --help or
in manpage, making it hard to find.


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

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

Versions of packages gdc-10 depends on:
ii  g++-10 10.1.0-1
ii  gcc-10-base10.1.0-1
ii  libc6  2.30-8
ii  libgmp10   2:6.2.0+dfsg-4
ii  libgphobos-10-dev  10.1.0-1
ii  libisl22   0.22.1-1
ii  libmpc31.1.0-1
ii  libmpfr6   4.0.2-1
ii  libzstd1   1.4.4+dfsg-3
ii  zlib1g 1:1.2.11.dfsg-2

gdc-10 recommends no packages.

gdc-10 suggests no packages.

-- no debconf information

Bug#960562: had to reinstall a package to avoid 'bullying'

[積丹尼 Dan Jacobson]

> "SJ" == Sven Joachim  writes:

SJ> There might be some arguments for "aptitude install " to clear
SJ> the automatic flag (IIRC apt and apt-get do that), but some people
SJ> probably rely on the current aptitude behavior not to do that.

Well like

   $ man aptitude
   forbid-version
   ...

   To revert the action, “aptitude install ” will
   remove the ban...


Also if the user really wants to keep the auto flag, then there seems to
also be these he can use:

   install...
   +
   Install .

   If the package was not installed, it is marked as manually 
installed, and the dependencies newly
   installed are marked with the automatic flag. If the package or 
the dependencies were already
   installed, the automatic flag is preserved. See the section 
about automatic installations in the
   documentation for more information.

   +M
   Install  and immediately mark it as automatically 
installed (note that if nothing depends
   on , this will cause it to be immediately removed).

Bug#960642: Mention command line equivalents

[積丹尼 Dan Jacobson]

Package: aptitude-doc-en
Version: 0.8.12-3
Severity: minor
File: /usr/share/doc/aptitude/html/en/ch02s02s06.html

That File mentions

 You can cancel the “automatic” flag at any time by pressing m...

OK, but do also mention command line equivalents!

Bug#960641: linux-image-5.5.0-0.bpo.2-amd64: alx Ethernet driver spams about four error messages per second

[Robert]

Package: src:linux
Version: 5.5.17-1~bpo10+1
Severity: normal
Tags: upstream

Dear Maintainer,

   * What led up to the situation?
Nothing in particular.  This is on a clean install .  The
Ethernet device seems to work fine, and it was used to install
Debian during the netinst process.  However, I did not perform
any tests for packet loss, etc.  For what it's worth,
these errors were also observed under the 'linux-lts 5.4.40-1'
and 5.6.12.arch1-1 kernels in Arch Linux.  This seems to
indicate a problem with the alx driver itself.  The manufacturer
lists alx as the driver for its device, but the alx page itself
does not include this particular device as being supported:

https://support.killernetworking.com/knowledge-base/linux-support/

https://wiki.linuxfoundation.org/networking/alx
   
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
add pci=noaer to the kernel command line 
1) edit /etc/default/grub and and add pci=noaer to the line starting 
with 
GRUB_CMDLINE_LINUX_DEFAULT. It will look like this:
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash pci=noaer"
2) run "sudo update-grub"
3) reboot

as described here in a
possibly related bug report:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1521173

NOTE: I reversed this change for the benefit of this bug report.

OR

'rmmod alx' after boot without disabling aer at boot
   
   * What was the outcome of this action?
The errors were suppressed, but the Ethernet card/port no longer
functions.
   
   * What outcome did you expect instead?
Not applicable.  This may be related to the following:

https://askubuntu.com/questions/1219203/error-from-alx-network-driver-since-installing-new-ssd-drive
and
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1521173

However, unlike the above, this problem happens all the time,
and does not seem to be triggered by a reboot, sleep, resume, or
installing new hardware.


-- Package-specific info:
** Version:
Linux version 5.5.0-0.bpo.2-amd64 (debian-ker...@lists.debian.org) (gcc version 
8.3.0 (Debian 8.3.0-6)) #1 SMP Debian 5.5.17-1~bpo10+1 (2020-04-23)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-5.5.0-0.bpo.2-amd64 
root=UUID=4b30d738-11dd-4ca6-ae26-8064f2276562 ro quiet

** Not tainted

** Kernel log:
[45676.899652] pcieport :00:1d.6: AER: Multiple Corrected error received: 
:05:00.0
[45676.899844] alx :05:00.0: AER: PCIe Bus Error: severity=Corrected, 
type=Data Link Layer, (Receiver ID)
[45676.899845] alx :05:00.0: AER:   device [1969:e0a1] error 
status/mask=0080/2000
[45676.899847] alx :05:00.0: AER:[ 7] BadDLLP   
[45676.900845] pcieport :00:1d.6: AER: Corrected error received: 
:05:00.0
[45676.900946] alx :05:00.0: AER: PCIe Bus Error: severity=Corrected, 
type=Data Link Layer, (Receiver ID)
[45676.900947] alx :05:00.0: AER:   device [1969:e0a1] error 
status/mask=0040/2000
[45676.900948] alx :05:00.0: AER:[ 6] BadTLP
[45681.882408] pcieport :00:1d.6: AER: Corrected error received: 
:05:00.0
[45681.882534] alx :05:00.0: AER: PCIe Bus Error: severity=Corrected, 
type=Data Link Layer, (Receiver ID)
[45681.882542] alx :05:00.0: AER:   device [1969:e0a1] error 
status/mask=0080/2000
[45681.882547] alx :05:00.0: AER:[ 7] BadDLLP   
[45681.883576] pcieport :00:1d.6: AER: Corrected error received: 
:05:00.0
[45681.883640] alx :05:00.0: AER: PCIe Bus Error: severity=Corrected, 
type=Data Link Layer, (Receiver ID)
[45681.883647] alx :05:00.0: AER:   device [1969:e0a1] error 
status/mask=0080/2000
[45681.883653] alx :05:00.0: AER:[ 7] BadDLLP   
[45681.889174] pcieport :00:1d.6: AER: Corrected error received: 
:05:00.0
[45681.889232] alx :05:00.0: AER: PCIe Bus Error: severity=Corrected, 
type=Data Link Layer, (Receiver ID)
[45681.889233] alx :05:00.0: AER:   device [1969:e0a1] error 
status/mask=0080/2000
[45681.889234] alx :05:00.0: AER:[ 7] BadDLLP   
[45681.889608] pcieport :00:1d.6: AER: Multiple Corrected error received: 
:05:00.0
[45681.889779] alx :05:00.0: AER: PCIe Bus Error: severity=Corrected, 
type=Data Link Layer, (Receiver ID)
[45681.889780] alx :05:00.0: AER:   device [1969:e0a1] error 
status/mask=0080/2000
[45681.889781] alx :05:00.0: AER:[ 7] BadDLLP   
[45681.890023] pcieport :00:1d.6: AER: Corrected error received: 
:05:00.0
[45681.895852] pcieport :00:1d.6: AER: Corrected error received: 
:05:00.0
[45681.895951] alx :05:00.0: AER: PCIe Bus Error: severity=Corrected, 
type=Data Link Layer, (Receiver ID)
[45681.895952] 

Bug#960301: firefox-esr: [regression] cannot find the microphone

[Mike Hommey]

On Thu, May 14, 2020 at 06:42:30PM +0200, Francesco Poli wrote:
> On Wed, 13 May 2020 14:31:58 +0900 Mike Hommey wrote:
> 
> [...]
> > Something else you could try is rebuild firefox-esr 68.8.0esr-1 with
> > this patch applied: 
> > https://salsa.debian.org/mozilla-team/firefox/-/commit/87df541b27a0b012e843978a0343f2918e0f2f58
> 
> I rebuilt firefox-esr/68.8.0esr-1, after modifying debian/rules as
> shown in the above mentioned patch.
> 
> I tested this patched version of firefox-esr, but the microphone was
> still unseen by the browser.

Can you test 68.8.0esr-1~deb10u1?
https://packages.debian.org/source/stable/firefox-esr

Mike

Bug#960638: [Pkg-shadow-devel] Bug#960638: login no longer needs to be essential

[Chris Hofstaedtler]

* Josh Triplett  [200515 00:21]:
> It should still have priority "required", and
> perhaps "Important: yes" so that apt makes sure the user doesn't remove
> it by accident, but it doesn't need "Essential: yes" anymore.

However, if you keep Important: yes, you'll discover that the Debian
tooling doesn't deal with this properly, and your package won't
migrate to testing. So ... I'd recommend avoiding Important: yes.

Chris

Bug#943162: linphone: Build-Depends on obsolete package python-pystache

[Daniel Schepler]

severity 943162 serious
thanks

With python-pystache now being removed from unstable, the Python2
removal bug becomes RC since that makes the Build-Depends of
src:linphone uninstallable.
-- 
Daniel Schepler

Bug#960301: firefox-esr: [regression] cannot find the microphone

[Javier Cantero]

On Thu, May 14, 2020 at 06:42:30PM +0200, Francesco Poli wrote:
> By looking at the bug log, I see that at least two other users confirm
> they also experience the issue.

BTW, I've tested the official Linux-64 bit Mozilla 68.8-esr binary[*],
and the microphone is working (at least in my use case). You could try
to recompile without the Debian additional patches and see if that
helps.

[*] https://www.mozilla.org/en-US/firefox/68.0esr/releasenotes/


-- 
   Saludos de Javier 




signature.asc
Description: PGP signature

Bug#958322: Info received (Bug#958322: Info received ())

[PICCA Frederic-Emmanuel]

OK, with the previous NMU it works, so we can unbrand without problem the lzf 
library 

Bug#960640: bash-completion: dh_bash-completion needs to record installed files for dh_missing

[Andreas Beckmann]

Package: bash-completion
Version: 1:2.10-1
Severity: important

Hi,

with dh_missing defaulting to --fail-missing in compat level 13,
dh_bash-completion needs to log the files it has installed s.t.
dh_missing does not wrongly report
  dh_missing: error: missing files, aborting

Please see the "Logging helpers and dh_missing" section from the
"PROGRAMMING" guide for debhelper (10.6.3+).
(in the debhelper package: /usr/share/doc/debhelper/PROGRAMMING.gz)


Andreas

Bug#960629: gnome-terminal: characters of the Fantasque fonts are displayed as hex

[Vincent Lefevre]

On 2020-05-14 22:25:24 +0200, Vincent Lefevre wrote:
> The characters of the Fantasque fonts (from fonts-fantasque-sans)
> are displayed as hex, i.e. a box with 4 hex digits.

This may be related to the issue I have with gucharmap:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=960633

which does not show any glyph from Fantasque Sans Mono, perhaps
due to the chosen font format (woff, which seems to be the case
only with Fantasque Sans Mono).

Concerning GNOME Terminal, I don't know how to find out which
font format is chosen.

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

Bug#960639: src:orthanc-imagej: Please add support to build against libjson-simple-java >= 3

[Gilles Filippini]

Package: src:orthanc-imagej
Version: 1.2+dfsg-1
Severity: normal
Tags: patch

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

I'd like to transition json-simple 3.1.1 to unstable, but orthanc-imagej is a 
blocker since it builds against libjson-simple-java << 3 only.

The json-simple classes used by orthanc-imagej were deprecated in version 2.0.0 
[1]. There were removed in versions 3.x [2].

[1] https://github.com/cliftonlabs/json-simple/blob/json-simple-2.0.0/README.txt
[2] https://github.com/cliftonlabs/json-simple/blob/json-simple-3.0.1/CHANGELOG

Please find attached a patch proposal to use the current json-simple classes. 
I've tested that the package builds correctly against libjson-simple-java 
version 2.3.0-1 from unstable and version 3.1.1-1~exp2 currently in 
experimental. But I don't known how to test the package afterward.

Thanks in advance for considering.

_g.

- -- System Information:
Debian Release: buster/sid
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.6.0-1-amd64 (SMP w/4 CPU cores)
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

-BEGIN PGP SIGNATURE-

iQEzBAEBCgAdFiEEoJObzArDE05WtIyR7+hsbH/+z4MFAl69xOcACgkQ7+hsbH/+
z4M05QgArerRja+IdHaKJdRugPYsdrg7UkATnA6+fdfZqZ556z0PEfspvQBMDUIO
fCUymwo0IozDmxNq5COn2w0AbExgwOTwsnf/Pg3t0xGw0AjdBsckvqS0P1H9APWz
m/uZHlFA8TZ2V1SPtoRK4HnE8Ru8K0ho1yexl1jSPenLFFaAWpPJK1Vib/M+2c+3
DKIjQQ2gW2g2N4+IHkinKW5KLuYr+4AErPNRP7VdVAxUcplYk1WpfRcbyMDhogTF
ZGK35Bew9eXc71Wg3WNPZSwM/RnD/sgx0MMeknOeJxtFgMt3CyoKWtWIALMuNq62
S0omjztsZNfsU6LcS+cUMvPLRteAOA==
=UUGZ
-END PGP SIGNATURE-
diff -Nru orthanc-imagej-1.2+dfsg/debian/changelog 
orthanc-imagej-1.2+dfsg/debian/changelog
--- orthanc-imagej-1.2+dfsg/debian/changelog2018-10-31 08:28:01.0 
+0100
+++ orthanc-imagej-1.2+dfsg/debian/changelog2020-05-14 23:29:49.0 
+0200
@@ -1,3 +1,10 @@
+orthanc-imagej (1.2+dfsg-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * tentative patch to build against json-simple 3
+
+ -- Gilles Filippini   Thu, 14 May 2020 23:29:49 +0200
+
 orthanc-imagej (1.2+dfsg-1) unstable; urgency=medium
 
   * New upstream version. (Closes: #912363)
diff -Nru orthanc-imagej-1.2+dfsg/debian/patches/json-simple-3.patch 
orthanc-imagej-1.2+dfsg/debian/patches/json-simple-3.patch
--- orthanc-imagej-1.2+dfsg/debian/patches/json-simple-3.patch  1970-01-01 
01:00:00.0 +0100
+++ orthanc-imagej-1.2+dfsg/debian/patches/json-simple-3.patch  2020-05-14 
23:29:49.0 +0200
@@ -0,0 +1,359 @@
+Description: Migrate away from deprecated json-simple 1.x classes
+ See json-simple 2.0.0 changelog:
+ > * Deprecated JSONParse and JSONValue in favor of Jsoner.
+ > * Deprecated JSONStreamAware and JSONAware in favor of Jsonable.
+ > * Deprecated JSONObject in favor of JsonObject.
+ > * Deprecated JSONArray in favor of JsonArray.
+ .
+ This patch uses the new json-simple Json* classes. It is compatible with
+ both 2.x and 3.x json-simple releases, with a few ajustments regarding
+ backward incompatible changes in json-simple 3.x:
+ - The package name, changed to com.github.cliftonlabs.json_simple
+ - The exception DeserializationExcetpion renamed as JsonException
+ These two changes are handled using place-holders @JSON_SIMPLE_PACKAGE@
+ and @JSON_EXCETPION@ which are substituted at build time by debian/rules.
+ .
+ With these tricks the package is compatible with json-simple 2.x and 3.x.
+Author: Gilles Filippini 
+Index: orthanc-imagej-1.2+dfsg/com/orthancserver/DicomDecoder.java
+===
+--- orthanc-imagej-1.2+dfsg.orig/com/orthancserver/DicomDecoder.java
 orthanc-imagej-1.2+dfsg/com/orthancserver/DicomDecoder.java
+@@ -28,7 +28,8 @@ import ij.process.ShortProcessor;
+ import ij.process.ColorProcessor;
+ import ij.io.FileInfo;
+ import ij.measure.Calibration;
+-import org.json.simple.*;
++import @JSON_SIMPLE_PACKAGE@.JsonObject;
++import @JSON_SIMPLE_PACKAGE@.JsonArray;
+ import java.util.List;
+ import java.util.ArrayList;
+ import java.util.Collections;
+@@ -92,10 +93,10 @@ public class DicomDecoder
+   };
+ 
+   private static void ExtractCalibration(ImagePlus image,
+- JSONObject tags)
++ JsonObject tags)
+   {
+-JSONObject rescaleIntercept = (JSONObject) tags.get("0028,1052");
+-JSONObject rescaleSlope = (JSONObject) tags.get("0028,1053");
++JsonObject rescaleIntercept = (JsonObject) tags.get("0028,1052");
++JsonObject rescaleSlope = (JsonObject) tags.get("0028,1053");
+ if (rescaleIntercept != null &&
+ rescaleSlope != null)
+ {
+@@ -108,9 +109,9 @@ public class DicomDecoder
+   }
+ 
+   private static void ExtractPixelSpacing(ImagePlus image,
+-  JSONObject 

Bug#960638: login no longer needs to be essential

[Josh Triplett]

Package: login
Version: 1:4.8.1-1
Severity: wishlist

Now that login no longer contains "su", it no longer needs to be an
essential package. A system that doesn't run any getty processes or
other means of logging in (such as a system using only ssh, or a chroot,
or a system with no interactive users at all) may not need to have the
login package installed. It should still have priority "required", and
perhaps "Important: yes" so that apt makes sure the user doesn't remove
it by accident, but it doesn't need "Essential: yes" anymore.

- Josh Triplett

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

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

Versions of packages login depends on:
ii  libaudit1   1:2.8.5-3+b1
ii  libc6   2.30-8
ii  libcrypt1   1:4.4.16-1
ii  libpam-modules  1.3.1-5
ii  libpam-runtime  1.3.1-5
ii  libpam0g1.3.1-5

login recommends no packages.

login suggests no packages.

-- no debconf information

Bug#960616: ITP: nextpnr -- FPGA place-and-route tool

[Nathaniel Graff]

> On May 14, 2020, at 2:51 PM, Serge Cohen  
> wrote:
> 
> Any intention/idea/knowledge about packaging also Project X-ray. Indeed there 
> are also quite some «small» FPGA boards based on Artix-7 which would be very 
> nice to be able to use through a completely open-source and packaged workflow 
> ?
> 
> Amongst others, the ZTEX boards or some digilent boards … relatively not so 
> expensive hardware with more powerful FPGA (including DSP, BRAM… slices).

Hi Serge!

Absolutely, I’m interested in moving on to packaging both Project Trellis and 
Project X-Ray and expanding the nextpnr package to include those targets.

Of course, we’ll just have to see how far my current momentum takes me. :)

Thanks,
Nate

Bug#958322: Info received ()

[PICCA Frederic-Emmanuel]

I am not sure at all of this in fact I red this closed bug 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=955456

I discovered that the NMU was not included in the git repository.

Bug#960636: deb-why-removed is very slow

[Jakub Wilk]

Package: devscripts
Version: 2.20.3

deb-why-removed is very slow. On my machine it takes nearly half a 
minute to query for one package:


  $ time deb-why-removed --no-refresh didjvu
  Date: Fri, 22 Nov 2019 22:24:20 +
  Ftpmaster: Scott Kitterman
  Suite: unstable
  Sources:
   didjvu_0.9-2
  Binaries:
   didjvu_0.9-2 [all]
  Reason: RoQA; RC buggy; python2-only 
(https://github.com/jwilk/didjvu/issues/13)
  Bug: 945177
  Also-Bugs: 936398 943695


  real  0m28.242s
  user  0m27.168s
  sys   0m1.010s

For comparison, with grep-dctrl, I can get the same information in a fraction 
of second:

  $ time grep-dctrl -F Sources,Binaries ' didjvu_' 
$XDG_CACHE_HOME/devscripts/deb-why-removed/removals-full.822
  Date: Fri, 22 Nov 2019 22:24:20 +
  Ftpmaster: Scott Kitterman
  Suite: unstable
  Sources:
   didjvu_0.9-2
  Binaries:
   didjvu_0.9-2 [all]
  Reason: RoQA; RC buggy; python2-only 
(https://github.com/jwilk/didjvu/issues/13)
  Bug: 945177
  Also-Bugs: 936398 943695
  Also-WNPP:


  real  0m0.394s
  user  0m0.368s
  sys   0m0.024s


-- System Information:
Architecture: i386

Versions of packages devscripts depends on:
ii  dpkg-dev  1.19.7
ii  fakeroot  1.24-1
ii  file  1:5.38-4
ii  gnupg 2.2.20-1
ii  gnupg22.2.20-1
ii  gpgv  2.2.20-1
ii  libfile-homedir-perl  1.004-1
ii  libfile-which-perl1.23-1
ii  libipc-run-perl   20200505.0-1
ii  libmoo-perl   2.004000-1
ii  libwww-perl   6.44-1
ii  patchutils0.3.4-2+b1
ii  sensible-utils0.0.12+nmu1
ii  wdiff 1.2.2-2+b1
ii  perl  5.30.0-10
ii  python3   3.8.2-3
ii  libc6 2.30-8

Versions of packages devscripts recommends:
ii  libdpkg-perl1.19.7

--
Jakub Wilk

Bug#960637: Description incorrectly mentions that package contains "su"

[Josh Triplett]

Package: login
Version: 1:4.8.1-1
Severity: normal

The description of the "login" package mentions that it contains "su",
but login no longer provides su (util-linux now provides it).

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

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

Versions of packages login depends on:
ii  libaudit1   1:2.8.5-3+b1
ii  libc6   2.30-8
ii  libcrypt1   1:4.4.16-1
ii  libpam-modules  1.3.1-5
ii  libpam-runtime  1.3.1-5
ii  libpam0g1.3.1-5

login recommends no packages.

login suggests no packages.

-- no debconf information

Bug#960621: firefox-l10n-it: all firefox-l10n-* don't work

[Luca Trevisani]

Package: firefox-l10n-it
Version: 76.0.1-1
Severity: important

Dear Maintainer,

i tried with all localization packages

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

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

Versions of packages firefox-l10n-it depends on:
ii  firefox  76.0.1-1

Versions of packages firefox-l10n-it recommends:
pn  hunspell-it  

firefox-l10n-it suggests no packages.

-- no debconf information

Bug#958322:

[PICCA Frederic-Emmanuel]

Hello, I tryed to unbrand the lzf library but it end up with failing unit tests

I do not know the internals of liblzf. 

Timo Röhling can you have a look at this issue ?

Cheers

Frederic

It seems that the embeded version of lzf and the one from your liblzf package
are different.



test_filter (bitshuffle.tests.test_h5filter.TestFilter) ... ERROR
test_with_block_size (bitshuffle.tests.test_h5filter.TestFilter) ... ERROR
test_with_compression (bitshuffle.tests.test_h5filter.TestFilter) ... ERROR
test_plugins (bitshuffle.tests.test_h5plugin.TestFilterPlugins) ... ERROR
test_regression (bitshuffle.tests.test_regression.TestAll) ... ok

==
ERROR: test_filter (bitshuffle.tests.test_h5filter.TestFilter)
--
Traceback (most recent call last):
  File 
"/<>/.pybuild/cpython3_3.8_bitshuffle/build/bitshuffle/tests/test_h5filter.py",
 line 26, in test_filter
f = h5py.File(fname)
  File "/usr/lib/python3/dist-packages/h5py/_debian_h5py_serial/_hl/files.py", 
line 387, in __init__
fid = make_fid(name, mode, userblock_size,
  File "/usr/lib/python3/dist-packages/h5py/_debian_h5py_serial/_hl/files.py", 
line 173, in make_fid
fid = h5f.open(name, flags, fapl=fapl)
  File "h5py/_debian_h5py_serial/_objects.pyx", line 54, in 
h5py._debian_h5py_serial._objects.with_phil.wrapper
  File "h5py/_debian_h5py_serial/_objects.pyx", line 55, in 
h5py._debian_h5py_serial._objects.with_phil.wrapper
  File "h5py/_debian_h5py_serial/h5f.pyx", line 88, in 
h5py._debian_h5py_serial.h5f.open
OSError: Unable to open file (unable to open file: name = 
'tmp_test_filters.h5', errno = 2, error message = 'No such file or directory', 
flags = 0, o_flags = 0)

==
ERROR: test_with_block_size (bitshuffle.tests.test_h5filter.TestFilter)
--
Traceback (most recent call last):
  File 
"/<>/.pybuild/cpython3_3.8_bitshuffle/build/bitshuffle/tests/test_h5filter.py",
 line 46, in test_with_block_size
f = h5py.File(fname)
  File "/usr/lib/python3/dist-packages/h5py/_debian_h5py_serial/_hl/files.py", 
line 387, in __init__
fid = make_fid(name, mode, userblock_size,
  File "/usr/lib/python3/dist-packages/h5py/_debian_h5py_serial/_hl/files.py", 
line 173, in make_fid
fid = h5f.open(name, flags, fapl=fapl)
  File "h5py/_debian_h5py_serial/_objects.pyx", line 54, in 
h5py._debian_h5py_serial._objects.with_phil.wrapper
  File "h5py/_debian_h5py_serial/_objects.pyx", line 55, in 
h5py._debian_h5py_serial._objects.with_phil.wrapper
  File "h5py/_debian_h5py_serial/h5f.pyx", line 88, in 
h5py._debian_h5py_serial.h5f.open
OSError: Unable to open file (unable to open file: name = 
'tmp_test_filters.h5', errno = 2, error message = 'No such file or directory', 
flags = 0, o_flags = 0)

==
ERROR: test_with_compression (bitshuffle.tests.test_h5filter.TestFilter)
--
Traceback (most recent call last):
  File 
"/<>/.pybuild/cpython3_3.8_bitshuffle/build/bitshuffle/tests/test_h5filter.py",
 line 68, in test_with_compression
f = h5py.File(fname)
  File "/usr/lib/python3/dist-packages/h5py/_debian_h5py_serial/_hl/files.py", 
line 387, in __init__
fid = make_fid(name, mode, userblock_size,
  File "/usr/lib/python3/dist-packages/h5py/_debian_h5py_serial/_hl/files.py", 
line 173, in make_fid
fid = h5f.open(name, flags, fapl=fapl)
  File "h5py/_debian_h5py_serial/_objects.pyx", line 54, in 
h5py._debian_h5py_serial._objects.with_phil.wrapper
  File "h5py/_debian_h5py_serial/_objects.pyx", line 55, in 
h5py._debian_h5py_serial._objects.with_phil.wrapper
  File "h5py/_debian_h5py_serial/h5f.pyx", line 88, in 
h5py._debian_h5py_serial.h5f.open
OSError: Unable to open file (unable to open file: name = 
'tmp_test_filters.h5', errno = 2, error message = 'No such file or directory', 
flags = 0, o_flags = 0)

==
ERROR: test_plugins (bitshuffle.tests.test_h5plugin.TestFilterPlugins)
--
Traceback (most recent call last):
  File 
"/<>/.pybuild/cpython3_3.8_bitshuffle/build/bitshuffle/tests/test_h5plugin.py",
 line 37, in test_plugins
f = h5py.File(fname)
  File "/usr/lib/python3/dist-packages/h5py/_debian_h5py_serial/_hl/files.py", 
line 387, in __init__
fid = make_fid(name, mode, userblock_size,
  File "/usr/lib/python3/dist-packages/h5py/_debian_h5py_serial/_hl/files.py", 
line 173, in make_fid
fid = h5f.open(name, flags, fapl=fapl)
  File "h5py/_debian_h5py_serial/_objects.pyx", line 54, in 
h5py._debian_h5py_serial._objects.with_phil.wrapper
  File "h5py/_debian_h5py_serial/_objects.pyx", line 55, in 

Bug#960635: RM: jazip -- RoM; obsolete

[Peter S Galbraith]

Package: ftp.debian.org
Severity: normal

Hi, jazip is a GUI to use either Zip drives or Jaz drives, manufactured
in the late 1990s to 2002.

Zip drives used removable disks that had capacities of 100 MB, then 250
MB, and then 750 MB.  Jaz drives used removable disks of 1GB capacity,
increased to 2GB in 1998.

 https://en.wikipedia.org/wiki/Zip_drive
 https://en.wikipedia.org/wiki/Jaz_drive

I can't imagine anyone using these anymore.  The last ones I owned used
a SCSI interface, which I have not had on a computer for a long time. I
would have no way to test or fix bugs. None are submitted because nobody
uses it.

It's time to remove this from Debian.

Thanks,
Peter

Bug#960620: openconnect: buffer overflow in certificate handling (CVE-2020-12823)

[Luca Boccassi]

On Thu, 2020-05-14 at 18:50 +0100, Luca Boccassi wrote:
> Package: openconnect
> Version: 6.00-1
> Severity: important
> Tags: security
> 
> Openconnect is affected by a buffer overflow in certificate handling,
> that goes back at least to 6.00-1 (old-old-stable).
> 
> Fixed upstream by:
> 
> https://gitlab.com/openconnect/openconnect/-/merge_requests/108

Dear security team,

I uploaded to old-old-stable on request from the LTS team. How would
you like to handle stable and old-stable?

-- 
Kind regards,
Luca Boccassi


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

Bug#960616: ITP: nextpnr -- FPGA place-and-route tool

[Serge Cohen]

Hi there,

This is great news, as a replacement for archne-pnr !

Any intention/idea/knowledge about packaging also Project X-ray. Indeed there 
are also quite some «small» FPGA boards based on Artix-7 which would be very 
nice to be able to use through a completely open-source and packaged workflow ?

Amongst others, the ZTEX boards or some digilent boards … relatively not so 
expensive hardware with more powerful FPGA (including DSP, BRAM… slices).

Cheers,

Serge.

> Le 14 mai 2020 à 19:19, Nathaniel Graff  a écrit :
> 
> Package: wnpp
> Owner: Nathaniel Graff 
> Severity: wishlist
> X-Debbugs-CC: debian-scie...@lists.debian.org
> 
> * Package name: nextpnr
>  Version : 0~2020507gitfaf07a
>  Upstream Author :
>   Claire Wolf 
>   David Shah 
>   Dan Gisselquist 
>   Serge Bazanski 
>   Miodrag Milanovic 
>   Eddie Hung 
> * URL : https://github.com/YosysHQ/nextpnr
> * License : ISC
>  Programming Lang: C++
>  Description : FPGA place-and-route tool
> 
> nextpnr is a vendor-neutral, timing-driven, FOSS FPGA place-and-route
> tool. It is the successor to arachne-pnr, which is no longer maintained.
> Including nextpnr in Debian will allow current users of yosys and
> fpga-icestorm to make use of the latest development on the YosysHQ FPGA
> toolchain for Lattice iCE40 FPGAs.
> 
> This initial packaging effort will create three binary packages:
> - nextpnr-generic
> - nextpnr-ice40
> - nextpnr-ice40-qt
> 
> These binary packages span two different FPGA architectures (a generic
> target and Lattice iCE40 FPGAs) and a version for iCE40 FPGAs which
> features a Qt GUI.
> 
> Since nextpnr can be extended to support additional FPGA architectures
> (unlike its predecessor arachne-pnr), future work can extend this
> initial effort to support FPGA architectures like Lattice ECP5 and
> Xilinx 7-Series FPGAs using Project Trellis and Project X-Ray.
> 
> Keith Packard has offered to sponsor the upload.
> 
> Ongoing packaging effort is taking place on Salsa:
> https://salsa.debian.org/nategraff-guest/nextpnr
> 



signature.asc
Description: Message signed with OpenPGP

Bug#960358: exim4-base: spec.txt, NFS and file locking

[Vincent Lefevre]

On 2020-05-14 18:16:43 +0200, Andreas Metzler wrote:
> On 2020-05-14 Vincent Lefevre  wrote:
> [...]
> > Yes, but I don't know what to do. Even though my mail to exim-users
> > was accepted [status=sent (250 OK id=1jYqvc-0001jm-6G)], I can't see
> > it on .
> 
> No worries, iirc exim-users is moderated for non-members. It should go
> through.

Indeed, it had to be approved (note that I subscribed before I posted,
but perhaps this is because this was my first post to the list).

The thread should be available there:

  https://lists.exim.org/lurker/message/20200513.125602.7be7983c.en.html

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

Bug#960634: nanopolish: FTBFS on ppc64el (as well as ppc64 and powerpc), enumerator conflict

[Barry Arndt]

Source: nanopolish
Version: 0.13.2-1
Severity: normal
Tags: ftbfs
Justification: fails to build from source (but built successfully in the 
past) on arch ppc64el
 
-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: ppc64el (ppc64le)
Kernel: Linux 5.4.0-3-powerpc64le (SMP w/80 CPU cores)

nanopolish FTBFS on ppc64el:
https://buildd.debian.org/status/fetch.php?pkg=nanopolish=ppc64el=0.13.2-1=1588529870=0
 



nanopolish-0.13.2/src/nanopolish_squiggle_read.h contains the following 
enumeration:
 
enum PoreType
{
PT_UNKNOWN = 0,
PT_R7,
PT_R9,
};
 
Enumerators PT_R7 and PT_R9 are both already defined elsewhere, which 
conflicts with this package and causes FTBFS in ppc64el.  (I'm not sure 
where PT_R7 and PT_R9 are already defined.  A quick grep of kernel source 
shows several in /usr/src/linux-xx/arch as well as /usr/lib.)
 
I verified that changing those names (PT_R7 and PT_R9) in the enumeration 
and corresponding code fixes the problem in ppc64el and allows it to build 
successfully.  Based on the build log files for ppc64 and powerpc, this 
change should fix FTBFS for those as well. 
 
I did not include a patch.  Since this problem could be fixed in several 
different ways, including the possibility of changing enumerator names, 
the maintainer might want it to match already established conventions.
 
A minor nit, removing the comma after PT_R9 would make the code a little 
more standard and match the rest of the enums in that .h file.
 
Barry Arndt
 

Bug#960633: gucharmap: does not show any glyph from Fantasque Sans Mono, due to chosen woff format?

[Vincent Lefevre]

Package: gucharmap
Version: 1:13.0.2-1
Severity: normal

gucharmap does not show any character from Fantasque Sans Mono
(provided by fonts-fantasque-sans 1.7.2~alpha.3~dfsg-2).

Note: Make sure that "Show only glyphs from this font" is ticked,
otherwise some special characters (from other fonts?) can be shown.

The output from strace shows that
/usr/share/fonts/woff/fantasque-sans/FantasqueSansMono-Regular.woff
is used, and perhaps gucharmap does not support this font format
(Web Open Font Format). But this font is also available in the
OpenType font format (.otf) and in TrueType font format (.ttf).
So the problem comes from gucharmap in any case.

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

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

Versions of packages gucharmap depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.36.0-1
ii  libatk1.0-0  2.36.0-2
ii  libc62.30-8
ii  libcairo21.16.0-4
ii  libglib2.0-0 2.64.2-1
ii  libgtk-3-0   3.24.20-1
ii  libgucharmap-2-90-7  1:13.0.2-1
ii  libpango-1.0-0   1.44.7-4
ii  libpangocairo-1.0-0  1.44.7-4

Versions of packages gucharmap recommends:
ii  yelp  3.36.0-1

gucharmap suggests no packages.

-- no debconf information

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

Bug#960503: xfonts-terminus: 50-enable-terminus.conf missing, fonts are not enabled

[Jochen Sprickerhof]

* Anton Zinoviev  [2020-05-14 23:21]:

On Wed, May 13, 2020 at 06:15:28PM +0200, Jochen Sprickerhof wrote:


I'm ok with that, except I found that I had to adopt the width of the otb
version by 0.85 to resemble the one of the pcf. Specifically I compared
Terminus:pixelsize=14 to ter-u14n_iso-8859-1.pcf.gz in the suckless terminal
st, setting cwscale=0.85 in the config. Is the different width on purpose?


I can not reproduce this.  First I tried

static char *font = "Terminus:pixelsize=14";

Then I tried

static char *font = 
"-xos4-terminus-medium-r-normal--14-140-72-72-c-80-iso10646-1";

In both case the st window is indentical and uses the font I requested.
In the second case, however, st prints twice the message "font weight
does not match".


Did you try it without xfonts-terminus installed (to not run into 
#960502)?

I just reproduced it in a fresh installed Debian testing Qemu:

Install using latest Bullseye Debian installer (with LxDE)
$ sudo apt build-dep stterm
$ sudo apt install fonts-terminus-otb
$ apt source stterm
$ cd stterm*
$ sed -i 's/Liberation 
Mono:pixelsize=12:antialias=true:autohint=true/Terminus:pixelsize=14/' 
config.def.h
$ make
$ ./st

$ sudo apt install xfonts-terminus
$ ./st

I've attached a screenshot of both terminals, you can see the different 
font width is reflected in the terminal width as well.


Cheers Jochen


signature.asc
Description: PGP signature

Bug#960632: src:plm: Please add support to build against libjson-simple-java >= 3

[Gilles Filippini]

Package: src:plm
Version: 2.6+repack-3
Severity: normal
Tags: patch

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

I'd like to transition json-simple 3.1.1 to unstable, but plm is a blocker 
since it builds against libjson-simple-java << 3 only.

The json-simple classes used by plm were deprecated in version 2.0.0 [1]. There 
were removed in versions 3.x [2].

[1] https://github.com/cliftonlabs/json-simple/blob/json-simple-2.0.0/README.txt
[2] https://github.com/cliftonlabs/json-simple/blob/json-simple-3.0.1/CHANGELOG

Please find attached a patch proposal to use the current json-simple classes. 
I've tested that the package builds correctly against libjson-simple-java 
version 2.3.0-1 from unstable and version 3.1.1-1~exp2 currently in 
experimental. But I don't known how to test the package afterward.

Thanks in advance for considering.

_g.

- -- System Information:
Debian Release: buster/sid
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.6.0-1-amd64 (SMP w/4 CPU cores)
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

-BEGIN PGP SIGNATURE-

iQEzBAEBCgAdFiEEoJObzArDE05WtIyR7+hsbH/+z4MFAl69t9gACgkQ7+hsbH/+
z4O/Ogf/TKcl0DykVQuRlbDexYENp672j8+2ux7ztFhFNUhS/zgB30Z1hZxXtRhk
QS++/PUSF0KleNtCK+d00Pjs4q9PzYrZhbyCz47fGukncjICF+wPr3cerrEy3w57
5iv5PF9B7u0Jbfjsuf5BOnRTFdCc+FvsqkB3BIg8kMmwJtSU/aAq5sJgw6VijIxU
wIJ9/QNUwYvUYlWPb/NQnGXyjX55b9SRNW+VeGB9OXUkRl2qlzpdeKLqBlXi2+bZ
d6Sy0p0FR88El+DyiOxFFUj9FO8iiQFrDBS2xhLcU3CknEjEctkJrX9K9fbWtMrr
a7Jf8TJl5BSzHrv17bRwZkddpMXwDg==
=SniR
-END PGP SIGNATURE-
diff -Nru plm-2.6+repack/debian/changelog plm-2.6+repack/debian/changelog
--- plm-2.6+repack/debian/changelog 2016-09-18 16:39:19.0 +0200
+++ plm-2.6+repack/debian/changelog 2020-05-14 18:05:12.0 +0200
@@ -1,3 +1,10 @@
+plm (2.6+repack-3.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Tentative patch to build against json-simple 3
+
+ -- Gilles Filippini   Thu, 14 May 2020 18:05:12 +0200
+
 plm (2.6+repack-3) unstable; urgency=medium
 
   * Add run-time dependencies on default-jdk, jython and jruby.
diff -Nru plm-2.6+repack/debian/patches/json-simple-3.patch 
plm-2.6+repack/debian/patches/json-simple-3.patch
--- plm-2.6+repack/debian/patches/json-simple-3.patch   1970-01-01 
01:00:00.0 +0100
+++ plm-2.6+repack/debian/patches/json-simple-3.patch   2020-05-14 
18:05:12.0 +0200
@@ -0,0 +1,595 @@
+Description: Migrate away from deprecated json-simple 1.x classes
+ See json-simple 2.0.0 changelog:
+ > * Deprecated JSONParse and JSONValue in favor of Jsoner.
+ > * Deprecated JSONStreamAware and JSONAware in favor of Jsonable.
+ > * Deprecated JSONObject in favor of JsonObject.
+ > * Deprecated JSONArray in favor of JsonArray.
+ .
+ This patch uses the new json-simple Json* classes. It is compatible with
+ both 2.x and 3.x json-simple releases, with a few ajustments regarding
+ backward incompatible changes in json-simple 3.x:
+ - The package name, changed to com.github.cliftonlabs.json_simple
+ - The exception DeserializationExcetpion renamed as JsonException
+ These two changes are handled using place-holders @JSON_SIMPLE_PACKAGE@
+ and @JSON_EXCETPION@ which are substituted at build time by debian/rules.
+ .
+ With these tricks the package is compatible with json-simple 2.x and 3.x.
+Author: Gilles Filippini 
+Index: plm-2.6+repack/src/plm/core/model/Course.java
+===
+--- plm-2.6+repack.orig/src/plm/core/model/Course.java
 plm-2.6+repack/src/plm/core/model/Course.java
+@@ -4,9 +4,9 @@ import java.io.IOException;
+ import java.util.ArrayList;
+ import java.util.Map;
+ 
+-import org.json.simple.JSONArray;
+-import org.json.simple.JSONObject;
+-import org.json.simple.JSONValue;
++import @JSON_SIMPLE_PACKAGE@.JsonArray;
++import @JSON_SIMPLE_PACKAGE@.JsonObject;
++import @JSON_SIMPLE_PACKAGE@.Jsoner;
+ 
+ /**
+  * Class to manage course data online
+@@ -50,7 +50,7 @@ public abstract class Course {
+  * A user password is set to push data, a teacher password to 
administrate course
+  */
+ public ServerAnswer create() {
+-JSONObject jsonObject = new JSONObject();
++JsonObject jsonObject = new JsonObject();
+ jsonObject.put("action", "new");
+ jsonObject.put("course", courseId);
+ jsonObject.put("password", password);
+@@ -72,7 +72,7 @@ public abstract class Course {
+  * and by exercise
+  */
+ public String refresh() {
+-JSONObject jsonObject = new JSONObject();
++JsonObject jsonObject = new JsonObject();
+ jsonObject.put("action", "refresh");
+ jsonObject.put("course", courseId);
+ jsonObject.put("teacher_password", teacherPassword);
+@@ -99,7 +99,7 @@ public abstract class Course {
+  * removed
+  */

Bug#960631: php-common: forces removal of previous PHP versions

[Ondřej Surý]

Control: severity -1 minor
Control: tags -1 +wontfix 

Well, yes, that’s intentional. See the changelog for 76 version for the 
background. If you think of any better solution that would not mix extensions 
from different PHP versions and break all the autopkgtests, I am listening.

Besides there has been always only one supported PHP version per Debian release.

Ondřej 
--
Ondřej Surý 

> On 14 May 2020, at 22:42, Thorsten Glaser  wrote:
> 
> Package: php-common
> Version: 2:76
> Severity: important
> 
> The installation of the new version wants to remove the copies of
> PHP 7.0, 7.1, 7.2 and 7.3 I’ve installed to be able to reproduce
> problems and ensure support for those older versions from my system.
> 
> -- System Information:
> Debian Release: bullseye/sid
>  APT prefers unreleased
>  APT policy: (500, 'unreleased'), (500, 'buildd-unstable'), (500, 
> 'unstable'), (100, 'experimental')
> Architecture: x32 (x86_64)
> Foreign Architectures: i386, amd64
> 
> Kernel: Linux 5.5.0-2-amd64 (SMP w/4 CPU cores)
> Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
> Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=C 
> (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/lksh
> Init: sysvinit (via /sbin/init)
> 
> Versions of packages php-common depends on:
> ii  psmisc  23.3-1
> ii  sed 4.7-1
> 
> php-common recommends no packages.
> 
> php-common suggests no packages.
> 
> -- no debconf information

Bug#952425: COVID-19 Pandemic Grant Donation

[Oxfam International]

Congratulations !!!
As part of our humanitarian support during this hard time of fighting the 
COVID-19 Pandemic your email address was selected for a $1.700,000.00 USD 
Grant Donation for charity and community support in your region. Please 
contact us for more information and send your details.
e-Mail:  projetgroup2...@gmail.com

Oxfam International

Bug#955211: release.debian.org: Transition r-base for 4.0.0

[Dirk Eddelbuettel]

On 4 April 2020 at 13:40, Dirk Eddelbuettel wrote:
| 
| On 4 April 2020 at 10:15, Sebastiaan Couwenberg wrote:
| | On 4/3/20 8:27 PM, Dirk Eddelbuettel wrote:
| | > Can the tracker sort by
| | >  - maintainer
| | >  - binary type
| | > to help ?
| | 
| | With the attached script you can create a dd-list from the tracker.
| | 
| |  transition-dd-list.pl -u
| | https://release.debian.org/transitions/html/r-api-4.0.html
| 
| Excellent, thank you!  I needed to add libmojolicious-perl but that was it.

It gets me packages by maintainer.  What is missing is 'binary-arch' vs
'binary-all' because, if I have this right, maintainers need to manually
upload binary-all package during the now started transition.  Correct?

Does anybody have a helper tool?

Dirk

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

Bug#960514: libgsl25: obsolete and harmful conflicts/replaces

[Dirk Eddelbuettel]

Hi Julien,

On 13 May 2020 at 15:25, Julien Cristau wrote:
| Hi Dirk,
| 
| On Wed, May 13, 2020 at 08:05:19 -0500, Dirk Eddelbuettel wrote:
| 
| > 
| > Hi Julien,
| > 
| > On 13 May 2020 at 14:43, Julien Cristau wrote:
| > | Package: libgsl25
| > | Version: 2.6+dfsg-2
| > | Severity: minor
| > | 
| > | libgsl25 has the following relationships:
| > | 
| > | Replaces: gsl, libgsl0 (<= 1.9-4), libgsl0ldbl (<= 1.16+dfsg-4)
| > | Conflicts: gsl, libgsl0, libgsl0ldbl
| > | 
| > | However it does not actually replace or conflict with any of these
| > | (neither did libgsl23) as far as I can tell.  Possibly since libgslcblas
| > | was moved to a separate package?
| > 
| > Possible. Some of these may be old. Do you think I should just remove them
| > now?  (GSL barely moves. This was an upstream release from late last summer
| > than lingered in experimental because I failed to trigger a transition [my
| > fault]).
| > 
| > If we knew what a good fix was I could make a quick upload. Suggestions
| > welcome :)
| > 
| I believe they date back to the days of libgsl.so.0, where the package
| was renamed but the SONAME stayed the same, a couple of times?  Since

I think it is worse in the sense that libgsl DOES have sonames but
libgslcblas from the same source package DOES NOT:

edd@rob:~/deb/gsl(master)$ pkg-config --libs gsl
-lgsl -lgslcblas -lm
edd@rob:~/deb/gsl(master)$ ls -l /usr/lib/x86_64-linux-gnu/libgsl*
-rw-r--r-- 1 root root 5135700 Nov 26  2018 /usr/lib/x86_64-linux-gnu/libgsl.a
-rw-r--r-- 1 root root  473986 Nov 26  2018 
/usr/lib/x86_64-linux-gnu/libgslcblas.a
lrwxrwxrwx 1 root root  20 Nov 26  2018 
/usr/lib/x86_64-linux-gnu/libgslcblas.so -> libgslcblas.so.0.0.0
lrwxrwxrwx 1 root root  20 Nov 26  2018 
/usr/lib/x86_64-linux-gnu/libgslcblas.so.0 -> libgslcblas.so.0.0.0
-rw-r--r-- 1 root root  260064 Nov 26  2018 
/usr/lib/x86_64-linux-gnu/libgslcblas.so.0.0.0
lrwxrwxrwx 1 root root  16 Nov 26  2018 /usr/lib/x86_64-linux-gnu/libgsl.so 
-> libgsl.so.23.1.0
lrwxrwxrwx 1 root root  16 Nov 26  2018 
/usr/lib/x86_64-linux-gnu/libgsl.so.23 -> libgsl.so.23.1.0
-rw-r--r-- 1 root root 2590704 Nov 26  2018 
/usr/lib/x86_64-linux-gnu/libgsl.so.23.1.0
edd@rob:~/deb/gsl(master)$

(From my Ubuntu 19.10 box so one release behind, but that _never_
changed. gslcblas always was 0.0.0.

| the current package no longer shares filenames with those old ones I
| think they can just be removed.  It's quite possible this still applies

I am not having my best day today. What exactly do you suggest by "they can
just be removed"?  Can you make it more explicit?

| to libgslcblas.so.0 though, in which case the libgslcblas0 package
| should probably keep its own Conflicts/Replaces.
| 
| > (And did you mean 'harmful' or 'harmless'?  What 'harm' is being done? Do
| > upgrades balk? A clean install just worked in Docker...)
| > 
| That was my mistake, I initially thought this is what caused the
| non-co-installability with libgsl23, but it's actually harmless, I
| retitled the bug to clarify.  Sorry for any confusion.

No worries, that is how I read it.

Thanks for all the help,  Dirk
 
| Cheers,
| Julien

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

Bug#960590: wolfssl: please make the libwolfssl.a file reproducible

[Felix Lechner]

Hi,

On Thu, May 14, 2020 at 4:00 AM Chris Lamb  wrote:
>
> This is because it used ar's "U" argument to deliberately inherit the
> build system's filesystem timestamps, umask, etc. I do not know why
> this was introduced and am assuming it is merely a debugging thing.

The U argument was added to fix this warning in Ubuntu:

ar: 'u' modifier ignored since 'D' is the default (see 'U') [1]

[1] 
https://github.com/wolfSSL/wolfssl/commit/1b9cff1c5d09adb0af858992e2a2df01b1d4dc58

The manpage for 'ar' says about 'D':

If binutils was configured with --enable-deterministic-archives, then
this mode is on by default.

I would like to ask upstream to revert [1], but Ubuntu is a
Debian-derivative. Should our binutils be built differently (or have
they changed since [1] was authored)?

Kind regards
Felix Lechner

Bug#960609: Cannot install dh-python from Sid

[Kyle Edwards]

On Thu, 2020-05-14 at 17:14 +0200, Matthias Klose wrote:
> most likely a broken mirror.

Thanks for the insight. Whom should I contact to get this fixed?

Bug#936465: Remove python-ecryptfs?

[Scott Talbert]

Does it make sense to just remove the python-ecrpyptfs bindings?  They 
don't seem to have any reverse dependencies and popcon is very low.


Thanks,
Scott

Bug#907240: Progress on a new packaging effort

[Nathaniel Graff]

Hi Reuben,

I’ve been working lately to package nextpnr for Debian, and after accidentally 
filing a duplicate ITP (https://bugs.debian.org/960616) I was pointed back to 
this one.

I’ve hosted my work on Salsa (https://salsa.debian.org/nategraff-guest/nextpnr) 
and Keith Packard is sponsoring my upload.

I’m happy to take ownership of this bug and/or onboard my fork into the Debian 
Electronics team.

Thanks,
Nate Graff

Bug#960631: php-common: forces removal of previous PHP versions

[Thorsten Glaser]

Package: php-common
Version: 2:76
Severity: important

The installation of the new version wants to remove the copies of
PHP 7.0, 7.1, 7.2 and 7.3 I’ve installed to be able to reproduce
problems and ensure support for those older versions from my system.

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

Kernel: Linux 5.5.0-2-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages php-common depends on:
ii  psmisc  23.3-1
ii  sed 4.7-1

php-common recommends no packages.

php-common suggests no packages.

-- no debconf information

Bug#960630: ant: CVE-2020-1945

[Salvatore Bonaccorso]

Source: ant
Version: 1.10.7-1
Severity: important
Tags: security upstream
Control: found -1 1.10.5-2
Control: found -1 1.9.9-1+deb9u1
Control: found -1 1.9.9-1

Hi,

The following vulnerability was published for ant.

CVE-2020-1945[0]:
| Apache Ant 1.1 to 1.9.14 and 1.10.0 to 1.10.7 uses the default
| temporary directory identified by the Java system property
| java.io.tmpdir for several tasks and may thus leak sensitive
| information. The fixcrlf and replaceregexp tasks also copy files from
| the temporary directory back into the build tree allowing an attacker
| to inject modified source files into the build process.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2020-1945
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-1945
[1] https://www.openwall.com/lists/oss-security/2020/05/13/1

Regards,
Salvatore

Bug#960629: gnome-terminal: characters of the Fantasque fonts are displayed as hex

[Vincent Lefevre]

Package: gnome-terminal
Version: 3.36.2-1
Severity: normal

The characters of the Fantasque fonts (from fonts-fantasque-sans)
are displayed as hex, i.e. a box with 4 hex digits.

This occurs both in the font chooser and in the termiinal window.

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

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

Versions of packages gnome-terminal depends on:
ii  dbus-user-session [default-dbus-session-bus]  1.12.16-2
ii  dbus-x11 [dbus-session-bus]   1.12.16-2
ii  dconf-gsettings-backend [gsettings-backend]   0.36.0-1
ii  gnome-terminal-data   3.36.2-1
ii  gsettings-desktop-schemas 3.36.1-1
ii  libatk1.0-0   2.36.0-2
ii  libc6 2.30-8
ii  libdconf1 0.36.0-1
ii  libglib2.0-0  2.64.2-1
ii  libgtk-3-03.24.20-1
ii  libpango-1.0-01.44.7-4
ii  libuuid1  2.35.1-5
ii  libvte-2.91-0 0.60.2-1
ii  libx11-6  2:1.6.9-2+b1

Versions of packages gnome-terminal recommends:
ii  gvfs   1.44.1-1
ii  nautilus-extension-gnome-terminal  3.36.2-1
ii  yelp   3.36.0-1

gnome-terminal suggests no packages.

-- no debconf information

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

Bug#960503: xfonts-terminus: 50-enable-terminus.conf missing, fonts are not enabled

[Anton Zinoviev]

On Wed, May 13, 2020 at 06:15:28PM +0200, Jochen Sprickerhof wrote:
> 
> I'm ok with that, except I found that I had to adopt the width of the otb
> version by 0.85 to resemble the one of the pcf. Specifically I compared
> Terminus:pixelsize=14 to ter-u14n_iso-8859-1.pcf.gz in the suckless terminal
> st, setting cwscale=0.85 in the config. Is the different width on purpose?

I can not reproduce this.  First I tried

static char *font = "Terminus:pixelsize=14";

Then I tried

static char *font = 
"-xos4-terminus-medium-r-normal--14-140-72-72-c-80-iso10646-1";

In both case the st window is indentical and uses the font I requested.  
In the second case, however, st prints twice the message "font weight 
does not match".

Anton Zinoviev

Bug#960628: ITP: filtlong -- quality filtering tool for long reads of genome sequences

[Andreas Tille]

Package: wnpp
Severity: wishlist

Subject: ITP: filtlong -- quality filtering tool for long reads of genome 
sequences
Package: wnpp
Owner: Andreas Tille 
Severity: wishlist

* Package name: filtlong
  Version : 0.2.0
  Upstream Author : Ryan Wick
* URL : https://github.com/rrwick/Filtlong
* License : GPL-3+
  Programming Lang: C
  Description : quality filtering tool for long reads of genome sequences
 Filtlong is a tool for filtering long reads by quality. It can take a
 set of long reads and produce a smaller, better subset. It uses both
 read length (longer is better) and read identity (higher is better) when
 choosing which reads pass the filter.

Remark: This package is maintained by Debian Med Packaging Team at
   https://salsa.debian.org/med-team/filtlong

Bug#960458: libreswan: CVE-2020-1763

[Salvatore Bonaccorso]

Hi

Merge request for debian/master at
https://salsa.debian.org/debian/libreswan/-/merge_requests/2/diffs

Regards,
Salvatore

Bug#953437: Upstream has a proposed fix

[Julien Puydt]

Hi,

upstream has tried to provide a fix for your problem on their latest
trunk branch : would you be able to give it a try?

Thanks,

JP

Bug#960627: gtk+3.0: Can update-icon-caches migrate to -noawait triggers?

[Niels Thykier]

Package: src:gtk+3.0
Severity: wishlist

Hi,

We are a group of people trying to reduce the number of maintscripts in
packages - partly for the sake of moving to more declarative approach,
but also some improvements and prototypes (like [InstallBootstrap]) are
harder to deploy/experiment with due to maintscripts.

For this reason, we would like to know if we can have dh_icons and
update-icon-caches move to a trigger based work flow which avoids
maintscripts in every package providing icons.

~Niels

[InstallBootstrap]:
https://wiki.debian.org/Teams/Dpkg/Spec/InstallBootstrap

Bug#960466: fonts-mathematica: does not download

[Adam Borowski]

Control: severity -1 grave
Control: found -1 20

On Wed, May 13, 2020 at 12:38:58AM +0200, Francesco Potortì wrote:
> Package: fonts-mathematica
> 
> the installation script hits a page not found error while downloading
> fonts from Wolfram

And that makes the package useless, also in [old*]stable.  Someone would
need to find out the new URL (if one exists) and update in all suites.

In 2017, when Mathematica 11 was released, I tried to upgrade.  Alas,
despite wasting a few hours searching, I failed to find where the fonts
are available.  Also, all support and community links are limited to
paid users only.

Thus, unless the new URL is found, there's nothing that can be done.
With the problem happening again in a future release cycle.


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

Bug#936146: archivemail - Python 3 porting

[Scott Talbert]

archivemail seems to be a good candidate to RM due to dead upstream. 
However, it still has a relatively high popcon, so people seem to be using 
it.


I'm willing to take a stab at porting to Python 3 if anyone is available 
to test it?  The port effort doesn't look that bad at first glance, but I 
don't use this package.


Scott

Bug#960626: Installation report: Debian Installer Bullseye Alpha 2 release on HP Notebook 17-by2054nb

[cyrille]

Package: installation-reports

 

Boot method: USB stick

Image version:
https://cdimage.debian.org/cdimage/bullseye_di_alpha2/amd64/iso-cd/debian-bullseye-DI-alpha2-amd64-netinst.iso

Date: 2020/05/13 22h GMT

 

 Machine: HP Notebook 17-by2054nb

Processor:Intel(R) Core(TM) i5-10210U CPU @ 1.60GHz

Memory:16GB

Partitions: 

 

Output of lspci -knn (or lspci -nn): 

 

(Retrieved from within the systemRescueCD environment)

 

00:00.0 Host bridge [0600]: Intel Corporation Device [8086:9b61] (rev 0c)

Subsystem: Hewlett-Packard Company Device [103c:865b]

00:02.0 VGA compatible controller [0300]: Intel Corporation UHD Graphics
[8086:9b41] (rev 02)

Subsystem: Hewlett-Packard Company UHD Graphics [103c:865b]

Kernel driver in use: i915

Kernel modules: i915

00:04.0 Signal processing controller [1180]: Intel Corporation Xeon E3-1200
v5/E3-1500 v5/6th Gen Core Processor Thermal Subsystem [8086:1903] (rev 0c)

Subsystem: Hewlett-Packard Company Xeon E3-1200 v5/E3-1500 v5/6th Gen Core
Processor Thermal Subsystem [103c:865b]

Kernel driver in use: proc_thermal

Kernel modules: processor_thermal_device

00:08.0 System peripheral [0880]: Intel Corporation Xeon E3-1200 v5/v6 /
E3-1500 v5 / 6th/7th/8th Gen Core Processor Gaussian Mixture Model
[8086:1911]

Subsystem: Hewlett-Packard Company Xeon E3-1200 v5/v6 / E3-1500 v5 /
6th/7th/8th Gen Core Processor Gaussian Mixture Model [103c:865b]

00:12.0 Signal processing controller [1180]: Intel Corporation Comet Lake
Thermal Subsytem [8086:02f9]

Subsystem: Hewlett-Packard Company Comet Lake Thermal Subsytem [103c:865b]

00:14.0 USB controller [0c03]: Intel Corporation Device [8086:02ed]

Subsystem: Hewlett-Packard Company Device [103c:865b]

Kernel driver in use: xhci_hcd

Kernel modules: xhci_pci

00:14.2 RAM memory [0500]: Intel Corporation Device [8086:02ef]

Subsystem: Hewlett-Packard Company Device [103c:865b]

00:15.0 Serial bus controller [0c80]: Intel Corporation Serial IO I2C Host
Controller [8086:02e8]

Subsystem: Hewlett-Packard Company Serial IO I2C Host Controller
[103c:865b]

Kernel driver in use: intel-lpss

Kernel modules: intel_lpss_pci

00:15.1 Serial bus controller [0c80]: Intel Corporation Device [8086:02e9]

Subsystem: Hewlett-Packard Company Device [103c:865b]

Kernel driver in use: intel-lpss

Kernel modules: intel_lpss_pci

00:16.0 Communication controller [0780]: Intel Corporation Comet Lake
Management Engine Interface [8086:02e0]

Subsystem: Hewlett-Packard Company Comet Lake Management Engine Interface
[103c:865b]

Kernel driver in use: mei_me

Kernel modules: mei_me

00:17.0 RAID bus controller [0104]: Intel Corporation 82801 Mobile SATA
Controller [RAID mode] [8086:282a]

Subsystem: Hewlett-Packard Company 82801 Mobile SATA Controller [RAID mode]
[103c:865b]

Kernel driver in use: ahci

Kernel modules: ahci

00:1c.0 PCI bridge [0604]: Intel Corporation Device [8086:02bc] (rev f0)

Kernel driver in use: pcieport

00:1d.0 PCI bridge [0604]: Intel Corporation Device [8086:02b0] (rev f0)

Kernel driver in use: pcieport

00:1d.1 PCI bridge [0604]: Intel Corporation Device [8086:02b1] (rev f0)

Kernel driver in use: pcieport

00:1d.4 PCI bridge [0604]: Intel Corporation Device [8086:02b4] (rev f0)

Kernel driver in use: pcieport

00:1f.0 ISA bridge [0601]: Intel Corporation Device [8086:0284]

Subsystem: Hewlett-Packard Company Device [103c:865b]

00:1f.3 Audio device [0403]: Intel Corporation Device [8086:02c8]

Subsystem: Hewlett-Packard Company Device [103c:865b]

Kernel driver in use: snd_hda_intel

Kernel modules: snd_hda_intel, snd_sof_pci

00:1f.4 SMBus [0c05]: Intel Corporation Device [8086:02a3]

Subsystem: Hewlett-Packard Company Device [103c:865b]

Kernel driver in use: i801_smbus

Kernel modules: i2c_i801

00:1f.5 Serial bus controller [0c80]: Intel Corporation Comet Lake SPI
(flash) Controller [8086:02a4]

Subsystem: Hewlett-Packard Company Comet Lake SPI (flash) Controller
[103c:865b]

Kernel driver in use: intel-spi

Kernel modules: intel_spi_pci

01:00.0 Display controller [0380]: Advanced Micro Devices, Inc. [AMD/ATI]
Topaz XT [Radeon R7 M260/M265 / M340/M360 / M440/M445 / 530/535 / 620/625
Mobile] [10... (rev c3)

Subsystem: Device [03ea:1af4]

Kernel driver in use: amdgpu

Kernel modules: amdgpu

02:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd.
RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [10ec:8168] (rev
15)

DeviceName: Hanksville Gbe Lan Connection

Subsystem: Hewlett-Packard Company RTL8111/8168/8411 PCI Express Gigabit
Ethernet Controller [103c:865b]

Kernel driver in use: r8169

Kernel modules: r8169

03:00.0 Network controller [0280]: Realtek Semiconductor Co., Ltd.
RTL8821CE 802.11ac PCIe Wireless Network Adapter [10ec:c821]

DeviceName: WLAN

Subsystem: Hewlett-Packard Company RTL8821CE 802.11ac PCIe Wireless Network
Adapter [103c:831a]

04:00.0 Non-Volatile memory controller [0108]: SK hynix BC501 NVMe Solid
State Drive 512GB [1c5c:1327]

Subsystem: SK hynix BC501 NVMe Solid State 

Bug#957253: fixed in gargoyle-free 2019.1.1-1

[Sylvain Beucler]

reopen 957253
thanks

I didn't actually build with GCC-10 and I suspect it won't.

There seem to be a transient issue with installing dependencies on
experimental right now, so I'll retry later.

Bug#955695: 1.5.2 has different error

[Hans-Christoph Steiner]

I'm trying to build Manas Kashyap's 1.5.2 update, and got a different
error.  And gradle/wrapper/gradle-wrapper.properties says gradle 5.2.1,
so it looks like they might have added some new gradle tricks

Included projects: [root project 'com.ibm.wala', project
':com.ibm.wala-repository', project ':com.ibm.wala.cast', project
':com.ibm.wala.cast.java', project ':com.ibm.wala.cast.test', project
':com.ibm.wala.core', project ':com.ibm.wala.dalvik', project
':com.ibm.wala.scandroid', project ':com.ibm.wala.shrike', project
':com.ibm.wala.tests.ide_feature', project
':com.ibm.wala.tests_feature', project ':com.ibm.wala.util', project
':com.ibm.wala_feature', project ':com.ibm.wala.cast.test:smoke_main',
project ':com.ibm.wala.cast.test:xlator_test', project
':com.ibm.wala.cast:cast']
Keep-alive timer started
Adding Debian repository to project 'com.ibm.wala'
Adding Debian repository to project 'com.ibm.wala-repository'
Adding Debian repository to project 'com.ibm.wala.cast'
Adding Debian repository to project 'com.ibm.wala.cast.java'
Adding Debian repository to project 'com.ibm.wala.cast.test'
Adding Debian repository to project 'com.ibm.wala.core'
Adding Debian repository to project 'com.ibm.wala.dalvik'
Adding Debian repository to project 'com.ibm.wala.scandroid'
Adding Debian repository to project 'com.ibm.wala.shrike'
Adding Debian repository to project 'com.ibm.wala.tests.ide_feature'
Adding Debian repository to project 'com.ibm.wala.tests_feature'
Adding Debian repository to project 'com.ibm.wala.util'
Adding Debian repository to project 'com.ibm.wala_feature'
Adding Debian repository to project 'smoke_main'
Adding Debian repository to project 'xlator_test'
Adding Debian repository to project 'cast'
Evaluating root project 'com.ibm.wala' using build file
'/build/wala-1.5.2/build.gradle'.
Compiling build file '/build/wala-1.5.2/build.gradle' using
SubsetScriptTransformer.
Compiling build file '/build/wala-1.5.2/build.gradle' using
BuildScriptTransformer.

FAILURE: Build failed with an exception.

* Where:
Build file '/build/wala-1.5.2/build.gradle' line: 35

* What went wrong:
A problem occurred evaluating root project 'com.ibm.wala'.
> Could not find method named() for arguments [test] on task set of type
org.gradle.api.internal.tasks.DefaultTaskContainer.

Bug#960625: binNMUs for reverted yaml-cpp ABI breakage

[Adrian Bunk]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu

#959201 were unintentional ABI changes in libyaml-cpp0.6
that are now reverted.

Some packages were built against the package with the broken ABI
and should be binNMUed:

# seem affected
# have binary dependencies on libyaml-cpp0.6 (>= 0.6.3)
nmu pdns_4.3.0-4 . ANY . unstable . -m "rebuild with yaml-cpp with bug 959201 
fixed"
nmu rivet_1.8.3-3 . ANY . unstable . -m "rebuild with yaml-cpp with bug 959201 
fixed"

# better safe than sorry
# were built with one of the broken yaml-cpp versions
nmu horizon-eda_1.1.0-1 . ANY . unstable . -m "rebuild with yaml-cpp with bug 
959201 fixed"
nmu librime_1.5.3+dfsg1-5 . ANY . unstable . -m "rebuild with yaml-cpp with bug 
959201 fixed"

Bug#960624: rename bug

[ml]

Package: rename

Version: 1.10


The rename command doesn't work from another directory, when there is a 
"^" (beginn-line) in the regular-expression.


# script beginn - - - - -
$ uname -a
Linux ftd2 4.15.0-3-amd64 #1 SMP Debian 4.15.17-1 (2018-04-19) x86_64 
GNU/Linux

$ rename -V
/usr/bin/rename using File::Rename version 1.10

$ mkdir test
$ cd test/
/test$ touch Film-filmtitle1.txt
/test$ cd ..
$ mkdir test2
$ cd test2

/test2$ rename -v -e 's/^Film-//eg' ~/skripte/test/*

/test2$ ls -l ~/skripte/test/*
-rw-r--r-- 1 ft ft 0 Mai 12 00:48 /./test/Film-filmtitle1.txt

/test2$ cd ../test

/test$ rename -v -e 's/^Film-//eg' *
Use of uninitialized value in substitution iterator at (eval 8) line 1.
Film-filmtitle1.txt renamed as filmtitle1.txt

/test$ ls -l *
-rw-r--r-- 1 ft ft 0 Mai 12 00:48 filmtitle1.txt

# script end - - - - -

In the script, the first rename command have no result/output,
the second rename command there is a result.

Bug#960562: had to reinstall a package to avoid 'bullying'

[Sven Joachim]

On 2020-05-14 06:48 +0800, 積丹尼 Dan Jacobson wrote:

> Package: aptitude
> Version: 0.8.12-3
>
> Odd, today I had to reinstall a package to get aptitude to stop trying
> to get rid of it.

The package in question has been marked as automatically installed and
there are no longer any reverse dependencies.  The easiest way to keep
it would be "aptitude unmarkauto fdisk".

> # aptitude install fdisk
> fdisk is already installed at the requested version (2.35.1-5)
> fdisk is already installed at the requested version (2.35.1-5)
> The following packages will be REMOVED:
>   fdisk{pu}

There might be some arguments for "aptitude install " to clear
the automatic flag (IIRC apt and apt-get do that), but some people
probably rely on the current aptitude behavior not to do that.

Cheers,
   Sven

Bug#960419: dh_link: Add option to check for identical file contents before replacing

[Niels Thykier]

Matthijs Kooijman:
> Package: debhelper
> Severity: wishlist
> 
> Hi,
> 
> in the openttd-opengfx package, I'm using dh_link to replace some
> upstream-installed files with symlinks. To prevent accidentally linking
> to the wrong file, I now explicitly diff the files before creating the
> link. It would be nice if dh_link could handle that.
> 
>[...]
> 
> Gr.
> 
> Matthijs
> 

Hi Matthijs,

Thanks for the proposal.

As far as I can tell, the underlying desire is to do some form of
deduplication.  If so, then I think this is similar to #888397 with an
expanded scope and a proposal for doing this via dh_link (rather than
dh_installdocs or a new helper).

~Niels

Bug#960609: Cannot install dh-python from Sid

[Kyle Edwards]

Package: python3-all
Severity: serious

When attempting to install python3-all:

$ apt-get update
$ apt-get install dh-python

I get the following error:

The following packages have unmet dependencies:
 python3-all : Depends: python3-distutils (>= 3.8.2-1~) but it is not
installable
E: Unable to correct problems, you have held broken packages.

Bug#960623: boost1.67 should build depend on libicu-dev (<< 64)

[Adrian Bunk]

Source: boost1.67
Version: 1.67.0-17
Severity: serious
Control: block 960193 by -1

Changing the icu version changes the libboost_regex ABI.

The libboost-regex*-icu* provides untangle icu transitions from boost
transitions, but reverse dependencies of libboost-regex1.67.0 in buster
depend on libboost-regex1.67.0 not libboost-regex1.67.0-icu63.

A build dependency on libicu-dev (<< 64) would prevent accidental
recompilation with a more recent icu, avoiding problems if people
would install the rebuilt libboost-regex1.67.0 on buster.

If wanted I can NMU this change.

Bug#960622: ruby-kramdown: new version available, deprecation warnings against ruby 2.7

[Daniel Kahn Gillmor]

Package: ruby-kramdown
Version: 1.17.0-4

Upstream appears to have version 2.2.1 available.   The current version
emits the following warnings with ruby 2.7+1:

/usr/lib/ruby/vendor_ruby/kramdown-rfc2629.rb:454: warning: Using the last 
argument as keyword parameters is deprecated; maybe ** should be added to the 
call
/usr/lib/ruby/2.7.0/open-uri.rb:13: warning: The called method `open' is 
defined here
/usr/lib/ruby/vendor_ruby/kramdown-rfc2629.rb:454: warning: calling URI.open 
via Kernel#open is deprecated, call URI.open directly or use URI#open

hopefully the new version resolves these warnings.

Regards,

--dkg


signature.asc
Description: PGP signature

Bug#914309: bugs.debian.org: Display won't turn back on after going to sleep

[Jesse Farrell]

This is also happening to me.  I have an HP EliteBook 6930p (running
bullseye) that, once it goes to sleep, looks and sounds like it's waking
up, but the screen remains black and I'm unable to SSH to it any more.

[excerpt from 'inxi -Fxxx']

System:
  Host: joethelion Kernel: 5.6.0-1-amd64 x86_64 bits: 64 compiler: gcc v:
9.3.0
  Desktop: Gnome 3.36.2 wm: gnome-shell dm: GDM3 3.34.1
  Distro: Debian GNU/Linux bullseye/sid
Machine:
  Type: Laptop System: Hewlett-Packard product: HP EliteBook 6930p v: F.0F
  serial:  Chassis: type: 10
  serial: 
  Mobo: Hewlett-Packard model: 30DB v: KBC Version 87.24
  serial:  BIOS: Hewlett-Packard v: 68PCU Ver.
F.0F
  date: 03/05/2009
Battery:
  ID-1: BAT0 charge: 49.4 Wh condition: 49.8/55.1 Wh (90%) volts: 12.5/10.8
  model: Hewlett-Packard Primary type: Li-ion serial: 07253 2009/03/26
  status: Unknown
CPU:
  Topology: Dual Core model: Intel Core2 Duo P8400 bits: 64 type: MCP
  arch: Penryn rev: A L2 cache: 3072 KiB
  flags: lm nx pae sse sse2 sse3 sse4_1 ssse3 bogomips: 9044
  Speed: 798 MHz min/max: 800/2267 MHz boost: enabled Core speeds (MHz): 1:
798
  2: 798
Graphics:
  Device-1: Intel Mobile 4 Series Integrated Graphics vendor:
Hewlett-Packard
  driver: i915 v: kernel bus ID: 00:02.0 chip ID: 8086:2a42
  Display: wayland server: X.Org 1.20.8 compositor: gnome-shell driver:
i915
  note: display driver n/a resolution: 1440x900~60Hz s-dpi: 96
  OpenGL: renderer: Mesa DRI Mobile Intel GM45 Express v: 2.1 Mesa 19.3.3
  direct render: Yes

Bug#956020: mydumper: diff for NMU version 0.9.5-1.2

[Adrian Bunk]

Control: tags 956020 + patch
Control: tags 956020 + pending

Dear maintainer,

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

cu
Adrian
diff -Nru mydumper-0.9.5/debian/changelog mydumper-0.9.5/debian/changelog
--- mydumper-0.9.5/debian/changelog	2020-03-14 22:15:00.0 +0200
+++ mydumper-0.9.5/debian/changelog	2020-05-08 20:14:50.0 +0300
@@ -1,3 +1,10 @@
+mydumper (0.9.5-1.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Link mydumper against libm. (Closes: #956020)
+
+ -- Adrian Bunk   Fri, 08 May 2020 20:14:50 +0300
+
 mydumper (0.9.5-1.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru mydumper-0.9.5/debian/patches/0001-Link-mydumper-against-libm.patch mydumper-0.9.5/debian/patches/0001-Link-mydumper-against-libm.patch
--- mydumper-0.9.5/debian/patches/0001-Link-mydumper-against-libm.patch	1970-01-01 02:00:00.0 +0200
+++ mydumper-0.9.5/debian/patches/0001-Link-mydumper-against-libm.patch	2020-05-08 20:14:50.0 +0300
@@ -0,0 +1,26 @@
+From 47b179ace22a2b4f4e5a3e783d6a79cc44a65708 Mon Sep 17 00:00:00 2001
+From: Adrian Bunk 
+Date: Fri, 8 May 2020 20:12:57 +0300
+Subject: Link mydumper against libm
+
+This is required due to mydumper.c using ceil().
+---
+ CMakeLists.txt | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/CMakeLists.txt b/CMakeLists.txt
+index ca9591f..ea4bb85 100644
+--- a/CMakeLists.txt
 b/CMakeLists.txt
+@@ -37,7 +37,7 @@ if (WITH_BINLOG)
+ else (WITH_BINLOG)
+   add_executable(mydumper mydumper.c server_detect.c g_unix_signal.c connection.c getPassword.c)
+ endif (WITH_BINLOG)
+-target_link_libraries(mydumper ${MYSQL_LIBRARIES} ${GLIB2_LIBRARIES} ${GTHREAD2_LIBRARIES} ${PCRE_PCRE_LIBRARY} ${ZLIB_LIBRARIES} stdc++)
++target_link_libraries(mydumper ${MYSQL_LIBRARIES} ${GLIB2_LIBRARIES} ${GTHREAD2_LIBRARIES} ${PCRE_PCRE_LIBRARY} ${ZLIB_LIBRARIES} stdc++ m)
+ 
+ 
+ add_executable(myloader myloader.c connection.c getPassword.c)
+-- 
+2.20.1
+
diff -Nru mydumper-0.9.5/debian/patches/series mydumper-0.9.5/debian/patches/series
--- mydumper-0.9.5/debian/patches/series	2018-12-19 11:17:53.0 +0200
+++ mydumper-0.9.5/debian/patches/series	2020-05-08 20:14:50.0 +0300
@@ -1,3 +1,4 @@
 0001-manpage-whatis-description.patch
 0002-dont-install-documentation-source.patch
 0005-fix-cmake-define-ssl
+0001-Link-mydumper-against-libm.patch

Bug#960573: python3-yt: h5py.File requires access mode to be specified

[Adrian Bunk]

Control: reassign -1 src:python3-yt 3.6.0-2
Control: severity -1 serious
Control: tags -1 ftbfs

On Thu, May 14, 2020 at 02:08:59PM +0800, Drew Parsons wrote:
> Package: python3-yt
> Version: 3.6.0-2
> Severity: normal
> 
> h5py is changing upstream to require the mode ('r', 'w', etc) to be
> specified when h5py.File is used.  The Debian version of h5py has
> already applied the upstream commits making this mandatory.
> 
> This affects yt in TestImageArray.test_image_array_hdf5 and test_h5_io,
> specifically write_hdf5 in yt/units/yt_array.py line 965
> 
> They seem to be write tests so probably you want h5py.File(filename, 'w')
>...

This is also a FTBFS:
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/yt.html

cu
Adrian

Bug#948244: https://unsplash.com/photos/1lfI7wkGWZ4?utm_source=unsplash_medium=referral_content=creditShareLink

[Victor Hugo Sánchez Gracida]

https://drive.google.com/file/d/10LwSnTSEk4fe6OrS8cl3kpiyLeLSzQLQ/view?usp=drivesdk

Enviado desde Outlook Mobile

Bug#960618: ITP: node-nouislider -- lightweight JavaScript range slider

[Xavier]

Le 14/05/2020 à 19:40, Xavier a écrit :
> Le 14/05/2020 à 19:25, Doug Torrance a écrit :
>> Package: wnpp
>> Severity: wishlist
>> Owner: Doug Torrance 
>>
>> * Package name: node-nouislider
>>   Version : 14.5.0
>>   Upstream Author : Léon Gersen
>> * URL : https://refreshless.com/nouislider/
>> * License : MIT
>>   Programming Lang: Javascript
>>   Description : lightweight JavaScript range slider
>>
>> noUiSlider is a lightweight range slider with multi-touch support and
>> a ton of features. It supports non-linear ranges, requires no
>> external dependencies, has keyboard support, and it works great in
>> responsive designs.
>>
>> Node.js is an event-based server-side JavaScript engine.
>>
>> I am interested in packaging noUiSlider as it is a dependency of the
>> Visualize package for Macaulay2, a computer algebra system for algebraic
>> geometry and commutative algebra I am currently working to get into
>> Debian.
>>
>> I intend to maintain noUiSlider under the umbrella of the Debian Javascript
>> Team.
> 
> Hi,
> 
> please join us on salsa.d.o/js-team and read our doc:
>  * https://wiki.debian.org/Javascript/Tutorial
>  * https://wiki.debian.org/Javascript/GroupSourcesTutorial
> 
> Cheers,
> Xavier

and (first): https://wiki.debian.org/Javascript

Bug#960618: ITP: node-nouislider -- lightweight JavaScript range slider

[Xavier]

Le 14/05/2020 à 19:25, Doug Torrance a écrit :
> Package: wnpp
> Severity: wishlist
> Owner: Doug Torrance 
> 
> * Package name: node-nouislider
>   Version : 14.5.0
>   Upstream Author : Léon Gersen
> * URL : https://refreshless.com/nouislider/
> * License : MIT
>   Programming Lang: Javascript
>   Description : lightweight JavaScript range slider
> 
> noUiSlider is a lightweight range slider with multi-touch support and
> a ton of features. It supports non-linear ranges, requires no
> external dependencies, has keyboard support, and it works great in
> responsive designs.
> 
> Node.js is an event-based server-side JavaScript engine.
> 
> I am interested in packaging noUiSlider as it is a dependency of the
> Visualize package for Macaulay2, a computer algebra system for algebraic
> geometry and commutative algebra I am currently working to get into
> Debian.
> 
> I intend to maintain noUiSlider under the umbrella of the Debian Javascript
> Team.

Hi,

please join us on salsa.d.o/js-team and read our doc:
 * https://wiki.debian.org/Javascript/Tutorial
 * https://wiki.debian.org/Javascript/GroupSourcesTutorial

Cheers,
Xavier

Bug#960589: src:i2p: Please add support to build against libjson-simple-java >= 3

[Gilles Filippini]

On Thu, 14 May 2020 12:38:36 +0200 Gilles Filippini  wrote:
> Package: src:i2p
> Version: 0.9.45-1
> Severity: normal
> Tags: patch
>
> Hi,
> 
> I'd like to transition json-simple 3.1.1 to unstable, but i2p is a blocker 
> since it builds against libjson-simple-java << 3 only.
> 
> The json-simple classes used by i2p were deprecated in version 2.0.0 [1]. 
> There were removed in versions 3.x [2].
> 
> [1] 
> https://github.com/cliftonlabs/json-simple/blob/json-simple-2.0.0/README.txt
> [2] 
> https://github.com/cliftonlabs/json-simple/blob/json-simple-3.0.1/CHANGELOG
> 
> Please find attached a patch proposal to use the current json-simple classes. 
> I've tested that the package builds correctly against libjson-simple-java 
> version 2.3.0-1 from unstable and version 3.1.1-1~exp2 currently in 
> experimental. But I don't known how to test the package afterward.
> 
> Thanks in advance for considering.

Updated patch fixing a few misunderstandings.

_g.
diff -Nru i2p-0.9.45/debian/changelog i2p-0.9.45/debian/changelog
--- i2p-0.9.45/debian/changelog 2020-04-12 16:50:00.0 +0200
+++ i2p-0.9.45/debian/changelog 2020-05-13 11:12:38.0 +0200
@@ -1,3 +1,10 @@
+i2p (0.9.45-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Tentative support for json-simple >= 3
+
+ -- Gilles Filippini   Wed, 13 May 2020 11:12:38 +0200
+
 i2p (0.9.45-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru i2p-0.9.45/debian/control i2p-0.9.45/debian/control
--- i2p-0.9.45/debian/control   2020-04-12 16:50:00.0 +0200
+++ i2p-0.9.45/debian/control   2020-05-13 11:12:38.0 +0200
@@ -17,7 +17,7 @@
  ,bash-completion
  ,gettext
  ,libgetopt-java
- ,libjson-simple-java (<< 3)
+ ,libjson-simple-java
  ,libgmp-dev (>= 2:5.0.5)
  ,libservice-wrapper-java
  ,po-debconf
diff -Nru i2p-0.9.45/debian/patches/0003-json-simple-3.patch 
i2p-0.9.45/debian/patches/0003-json-simple-3.patch
--- i2p-0.9.45/debian/patches/0003-json-simple-3.patch  1970-01-01 
01:00:00.0 +0100
+++ i2p-0.9.45/debian/patches/0003-json-simple-3.patch  2020-05-13 
11:12:38.0 +0200
@@ -0,0 +1,431 @@
+Description: Migrate away from deprecated json-simple 1.x classes
+ See json-simple 2.0.0 changelog:
+ > * Deprecated JSONParse and JSONValue in favor of Jsoner.
+ > * Deprecated JSONStreamAware and JSONAware in favor of Jsonable.
+ > * Deprecated JSONObject in favor of JsonObject.
+ > * Deprecated JSONArray in favor of JsonArray.
+ .
+ This patch uses the new json-simple Json* classes. It is compatible with
+ both 2.x and 3.x json-simple releases, with a few ajustments regarding
+ backward incompatible changes in json-simple 3.x:
+ - The package name, changed to com.github.cliftonlabs.json_simple
+ - The exception DeserializationExcetpion renamed as JsonException
+ These two changes are handled using place-holders @JSON_SIMPLE@ and
+ @JSON_EXCETPION@ which are substituted at build time by debian/rules.
+ .
+ With these tricks the package is compatible with json-simple 2.x and 3.x.
+Author: Gilles Filippini 
+Index: 
i2p-0.9.45/apps/i2pcontrol/java/com/thetransactioncompany/jsonrpc2/JSONRPC2Error.java
+===
+--- 
i2p-0.9.45.orig/apps/i2pcontrol/java/com/thetransactioncompany/jsonrpc2/JSONRPC2Error.java
 
i2p-0.9.45/apps/i2pcontrol/java/com/thetransactioncompany/jsonrpc2/JSONRPC2Error.java
+@@ -1,7 +1,7 @@
+ package com.thetransactioncompany.jsonrpc2;
+ 
+ 
+-import org.json.simple.JSONObject;
++import @JSON_SIMPLE@.JsonObject;
+ 
+ 
+ /** 
+@@ -220,7 +220,7 @@ public class JSONRPC2Error extends Excep
+* @see #toJSONObject
+*/
+   @Deprecated
+-  public JSONObject toJSON() {
++  public JsonObject toJSON() {
+   
+   return toJSONObject();
+   }
+@@ -231,9 +231,9 @@ public class JSONRPC2Error extends Excep
+*
+* @return A JSON object representing this error object.
+*/
+-  public JSONObject toJSONObject() {
++  public JsonObject toJSONObject() {
+   
+-  JSONObject out = new JSONObject();
++  JsonObject out = new JsonObject();
+   
+   out.put("code", code);
+   out.put("message", super.getMessage());
+Index: 
i2p-0.9.45/apps/i2pcontrol/java/com/thetransactioncompany/jsonrpc2/JSONRPC2Message.java
+===
+--- 
i2p-0.9.45.orig/apps/i2pcontrol/java/com/thetransactioncompany/jsonrpc2/JSONRPC2Message.java
 
i2p-0.9.45/apps/i2pcontrol/java/com/thetransactioncompany/jsonrpc2/JSONRPC2Message.java
+@@ -4,9 +4,11 @@ package com.thetransactioncompany.jsonrp
+ import java.util.HashMap;
+ import java.util.List;
+ import java.util.Map;
++import java.io.Writer;
++import java.io.IOException;
+ 
+-import org.json.simple.JSONAware;
+-import org.json.simple.JSONObject;
++import @JSON_SIMPLE@.Jsonable;
++import @JSON_SIMPLE@.JsonObject;
+ 
+ 
+ /**
+@@ -54,7 

Bug#960618: ITP: node-nouislider -- lightweight JavaScript range slider

[Doug Torrance]

On Thu, May 14, 2020 at 1:44 PM Xavier  wrote:
>
> Le 14/05/2020 à 19:40, Xavier a écrit :
> > Le 14/05/2020 à 19:25, Doug Torrance a écrit :
> >> Package: wnpp
> >> Severity: wishlist
> >> Owner: Doug Torrance 
> >>
> >> * Package name: node-nouislider
> >>   Version : 14.5.0
> >>   Upstream Author : Léon Gersen
> >> * URL : https://refreshless.com/nouislider/
> >> * License : MIT
> >>   Programming Lang: Javascript
> >>   Description : lightweight JavaScript range slider
> >>
> >> noUiSlider is a lightweight range slider with multi-touch support and
> >> a ton of features. It supports non-linear ranges, requires no
> >> external dependencies, has keyboard support, and it works great in
> >> responsive designs.
> >>
> >> Node.js is an event-based server-side JavaScript engine.
> >>
> >> I am interested in packaging noUiSlider as it is a dependency of the
> >> Visualize package for Macaulay2, a computer algebra system for algebraic
> >> geometry and commutative algebra I am currently working to get into
> >> Debian.
> >>
> >> I intend to maintain noUiSlider under the umbrella of the Debian Javascript
> >> Team.
> >
> > Hi,
> >
> > please join us on salsa.d.o/js-team and read our doc:
> >  * https://wiki.debian.org/Javascript/Tutorial
> >  * https://wiki.debian.org/Javascript/GroupSourcesTutorial
> >
> > Cheers,
> > Xavier
>
> and (first): https://wiki.debian.org/Javascript

Thanks for the note!  I found those pages already and I believe I've
been following the guidelines.  Please let me know if there's
something I missed!

I inquired on IRC the other day about getting a repository set up for
another Javascript package I'm working on (bootsidemenu.js -- see
#960097), and I was asked to go ahead and get the packaging work done
in my personal namespace on Salsa first before I send a RFS.  I hope
to have both packages ready for review in the next few days.

Thanks again!
Doug

Bug#960620: openconnect: buffer overflow in certificate handling (CVE-2020-12823)

[Luca Boccassi]

Package: openconnect
Version: 6.00-1
Severity: important
Tags: security

Openconnect is affected by a buffer overflow in certificate handling,
that goes back at least to 6.00-1 (old-old-stable).

Fixed upstream by:

https://gitlab.com/openconnect/openconnect/-/merge_requests/108

-- 
Kind regards,
Luca Boccassi


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

Bug#960617: popularity-contest: popcon fails to send data if USETOR=maybe and tor is not running

[Bill Allombert]

On Thu, May 14, 2020 at 08:22:11PM +0300, Michael Krylov wrote:
> Package: popularity-contest
> Version: 1.67
> Severity: normal
> 
> Dear Maintainer,
> 
> I have noticed that my recent submissions to popularity contest database
> have failed. After some further investigation and running
> 
> sudo bash -x /etc/cron.daily/popularity-contest
> 
> to see what is actually happening, I've noticed that it tries to use
> torify to send the submission:
> 
> /usr/bin/torify /usr/share/popularity-contest/popcon-upload -u 
> http://popcon.debian.org/cgi-bin/popcon.cgi -f 
> /var/log/popularity-contest.new.gpg
> 
> Although I have tor installed, I don't run it all the time, and only
> start it on demand.
> 
> For now, as a workaround, I set USETOR="no". 
> 
> I suggest that this script would check the `service tor status` before
> actually using torify if USETOR="maybe" and fail if USERTOR="yes".

Thanks for telling us about this problem. I will ask the authors of
the tor patch.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#960619: libzypp1702: Depends on cruft package libsolv0

[Daniel Schepler]

Package: libzypp1702
Version: 17.7.0-1+b1
Severity: serious

The current build of libzypp1702 (17.7.0-1+b1 on amd64) Depends on
libsolv0, while the current version of src:libsolv builds only
libsolv1.

This also cannot be resolved with a new binNMU: src:libzypp
Build-Depends on libsolv0-dev, while the current version of
src:libsolv builds only libsolv1-dev.
-- 
Daniel Schepler

Bug#960617: popularity-contest: popcon fails to send data if USETOR=maybe and tor is not running

[Michael Krylov]

Package: popularity-contest
Version: 1.67
Severity: normal

Dear Maintainer,

I have noticed that my recent submissions to popularity contest database
have failed. After some further investigation and running

sudo bash -x /etc/cron.daily/popularity-contest

to see what is actually happening, I've noticed that it tries to use
torify to send the submission:

/usr/bin/torify /usr/share/popularity-contest/popcon-upload -u 
http://popcon.debian.org/cgi-bin/popcon.cgi -f 
/var/log/popularity-contest.new.gpg

Although I have tor installed, I don't run it all the time, and only
start it on demand.

For now, as a workaround, I set USETOR="no". 

I suggest that this script would check the `service tor status` before
actually using torify if USETOR="maybe" and fail if USERTOR="yes".

Thanks in advance!

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

Kernel: Linux 4.19.0-9-686 (SMP w/4 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages popularity-contest depends on:
ii  debconf [debconf-2.0]  1.5.71
ii  dpkg   1.19.7

Versions of packages popularity-contest recommends:
ii  cron [cron-daemon]  3.0pl1-134+deb10u1
pn  default-mta | mail-transport-agent  
ii  gnupg   2.2.12-1+deb10u1

Versions of packages popularity-contest suggests:
ii  anacron   2.3-28
ii  tor   0.3.5.10-1
ii  torsocks  2.3.0-2

-- debconf information:
* popularity-contest/participate: true
  popularity-contest/submiturls:

Bug#960618: ITP: node-nouislider -- lightweight JavaScript range slider

[Doug Torrance]

Package: wnpp
Severity: wishlist
Owner: Doug Torrance 

* Package name: node-nouislider
  Version : 14.5.0
  Upstream Author : Léon Gersen
* URL : https://refreshless.com/nouislider/
* License : MIT
  Programming Lang: Javascript
  Description : lightweight JavaScript range slider

noUiSlider is a lightweight range slider with multi-touch support and
a ton of features. It supports non-linear ranges, requires no
external dependencies, has keyboard support, and it works great in
responsive designs.

Node.js is an event-based server-side JavaScript engine.

I am interested in packaging noUiSlider as it is a dependency of the
Visualize package for Macaulay2, a computer algebra system for algebraic
geometry and commutative algebra I am currently working to get into
Debian.

I intend to maintain noUiSlider under the umbrella of the Debian Javascript
Team.

Bug#960616: ITP: nextpnr -- FPGA place-and-route tool

[Nathaniel Graff]

Package: wnpp
Owner: Nathaniel Graff 
Severity: wishlist
X-Debbugs-CC: debian-scie...@lists.debian.org

* Package name: nextpnr
  Version : 0~2020507gitfaf07a
  Upstream Author :
   Claire Wolf 
   David Shah 
   Dan Gisselquist 
   Serge Bazanski 
   Miodrag Milanovic 
   Eddie Hung 
* URL : https://github.com/YosysHQ/nextpnr
* License : ISC
  Programming Lang: C++
  Description : FPGA place-and-route tool

nextpnr is a vendor-neutral, timing-driven, FOSS FPGA place-and-route
tool. It is the successor to arachne-pnr, which is no longer maintained.
Including nextpnr in Debian will allow current users of yosys and
fpga-icestorm to make use of the latest development on the YosysHQ FPGA
toolchain for Lattice iCE40 FPGAs.

This initial packaging effort will create three binary packages:
 - nextpnr-generic
 - nextpnr-ice40
 - nextpnr-ice40-qt

These binary packages span two different FPGA architectures (a generic
target and Lattice iCE40 FPGAs) and a version for iCE40 FPGAs which
features a Qt GUI.

Since nextpnr can be extended to support additional FPGA architectures
(unlike its predecessor arachne-pnr), future work can extend this
initial effort to support FPGA architectures like Lattice ECP5 and
Xilinx 7-Series FPGAs using Project Trellis and Project X-Ray.

Keith Packard has offered to sponsor the upload.

Ongoing packaging effort is taking place on Salsa:
 https://salsa.debian.org/nategraff-guest/nextpnr

Bug#960615: libbssolv-perl: Build-Depends on cruft package libsolv0-dev

[Daniel Schepler]

Source: libbssolv-perl
Version: 0.17-1
Severity: serious

The source package libbssolv-perl Build-Depends on libsolv0-dev,
whereas the current version of src:libsolv builds only libsolv1-dev.
-- 
Daniel Schepler

Bug#960608: Bison 3.6.1 generates (internal) tokentype and (yyerror) function with same name: _error

[Chuan-kai Lin]

Hi Akim,

I am forwarding a bug report that the libexplain and the fhist Debian
packages fail to build with Bison 3.6.1.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=960608
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/libexplain.html

I have also attached the build log with this email.  Can you look into
this issue and see if it is a bug in Bison?  Thanks!

Here is the explanation from Andreas Beckmann, who reported the bug:

At least two packages FTBFS with the latest bison with some yyerror related
error message. I had a short look into the libexplain failure and found the
following:

In libexplain/acl_grammar.yacc.c (generated from libexplain/acl_grammar.y),
these bits are new in 3.6.1 (they were not generated by 3.5.3):

...
  enum acl_grammar_tokentype
  {
acl_grammar_EMPTY = -2,
acl_grammar_EOF = 0, /* "end of file"  */
acl_grammar_error = 256, /* error  */
acl_grammar_UNDEF = 257, /* "invalid token"  */
...
  };
...
#define acl_grammar_EOF 0
#define acl_grammar_error 256
#define acl_grammar_UNDEF 257
...

and acl_grammar_error clashes with the existing (generated by 3.6.1 and
3.5.3, in acl_grammar.y this is yyerror())

...
static void
acl_grammar_error(const char *text)
{
...
}

which causes this error during compilation:

y.tab.c:152:27: error: expected identifier or '(' before numeric constant
libexplain/acl_grammar.y:128:1: note: in expansion of macro 'acl_grammar_error'
  128 | yyerror(const char *text)
  | ^
libexplain/acl_grammar.y: In function 'acl_grammar_errorf':
y.tab.c:152:27: error: called object is not a function or function pointer
libexplain/acl_grammar.y:155:5: note: in expansion of macro 'acl_grammar_error'
  155 | yyerror(buf);
  | ^
libexplain/acl_grammar.y: In function 'acl_grammar_parse':
y.tab.c:152:27: error: called object is not a function or function pointer
libexplain/acl_grammar.y:470:13: note: in expansion of macro 'acl_grammar_error'
  470 | yyerror
  | ^~~
y.tab.c:152:27: error: called object is not a function or function pointer
y.tab.c:1720:7: note: in expansion of macro 'acl_grammar_error'
y.tab.c:152:27: error: called object is not a function or function pointer
y.tab.c:1831:3: note: in expansion of macro 'acl_grammar_error'
At top level:
libexplain/acl_grammar.y:105:1: warning: 'result_append' defined but
not used [-Wunused-function]
  105 | result_append(const char *text)
  | ^

This does not look like it is an error in libexplain.
Mon May 11 13:28:49 UTC 2020  I: starting to build libexplain/unstable/amd64 on 
jenkins on '2020-05-11 13:28'
Mon May 11 13:28:49 UTC 2020  I: The jenkins build log is/was available at 
https://jenkins.debian.net/userContent/reproducible/debian/build_service/amd64_14/12752/console.log
Mon May 11 13:28:49 UTC 2020  I: Downloading source for 
unstable/libexplain=1.4.D001-9
--2020-05-11 13:28:50--  
http://deb.debian.org/debian/pool/main/libe/libexplain/libexplain_1.4.D001-9.dsc
Connecting to 78.137.99.97:3128... connected.
Proxy request sent, awaiting response... 200 OK
Length: 2184 (2.1K)
Saving to: ‘libexplain_1.4.D001-9.dsc’

 0K ..100%  190M=0s

2020-05-11 13:28:50 (190 MB/s) - ‘libexplain_1.4.D001-9.dsc’ saved [2184/2184]

Mon May 11 13:28:50 UTC 2020  I: libexplain_1.4.D001-9.dsc
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 3.0 (quilt)
Source: libexplain
Binary: explain, libexplain-doc, libexplain51, libexplain-dev
Architecture: any all
Version: 1.4.D001-9
Maintainer: Debian QA Group 
Homepage: http://libexplain.sourceforge.net/
Standards-Version: 4.4.0
Vcs-Browser: https://salsa.debian.org/debian/libexplain
Vcs-Git: https://salsa.debian.org/debian/libexplain.git
Build-Depends: bison, debhelper-compat (= 12), ghostscript, groff, libacl1-dev, 
libcap-dev [linux-any], libtool-bin, linux-libc-dev [linux-any], lsof 
[linux-any], netbase
Package-List:
 explain deb devel optional arch=any
 libexplain-dev deb libdevel optional arch=any
 libexplain-doc deb doc optional arch=all
 libexplain51 deb libs optional arch=any
Checksums-Sha1:
 e191e1e7f066f8cefca8d05c846c3a38931d8410 4770006 
libexplain_1.4.D001.orig.tar.gz
 051e4be36c618b454657db790a7a7920704ee513 43992 
libexplain_1.4.D001-9.debian.tar.xz
Checksums-Sha256:
 28863b65eccc74934e237cac41364cb3c1802c36c9e2318ed0417460fee83f80 4770006 
libexplain_1.4.D001.orig.tar.gz
 4ac59e45f82811b8fd0cf519149d224467f25ea212f161a5ac004241f502d543 43992 
libexplain_1.4.D001-9.debian.tar.xz
Files:
 8fabd3de196bde3ca941cd27c029ff8b 4770006 libexplain_1.4.D001.orig.tar.gz
 078b819d14486f28ebab03884dc6b658 43992 libexplain_1.4.D001-9.debian.tar.xz

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEfncpR22H1vEdkazLwpPntGGCWs4FAl1yplIACgkQwpPntGGC
Ws6jGg//ZreHxsvjOCNmKJ3RTjNwNEop3ml1HcRdd0YBVLB28zwOLTB6nAaxip6t

Bug#960301: firefox-esr: [regression] cannot find the microphone

[Francesco Poli]

On Wed, 13 May 2020 14:31:58 +0900 Mike Hommey wrote:

[...]
> Something else you could try is rebuild firefox-esr 68.8.0esr-1 with
> this patch applied: 
> https://salsa.debian.org/mozilla-team/firefox/-/commit/87df541b27a0b012e843978a0343f2918e0f2f58

I rebuilt firefox-esr/68.8.0esr-1, after modifying debian/rules as
shown in the above mentioned patch.

I tested this patched version of firefox-esr, but the microphone was
still unseen by the browser.
Hence, I would say that the patch does not change anything with respect
to the microphone bug.


By looking at the bug log, I see that at least two other users confirm
they also experience the issue.

Did you manage to reproduce the bug?
Have you found a fix or, at least, a workaround?
Could you please forward the bug report upstream?

Please let me know.
Thanks a lot for your time and dedication!


-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpUrrooYIoyd.pgp
Description: PGP signature

Bug#956701: RM: enigmail/2:2.0.8-5~deb9u1

[Daniel Kahn Gillmor]

Control: affects 956701 + src:enigmail

On Tue 2020-04-14 15:57:10 +0300, Adrian Bunk wrote:
> Package: release.debian.org
> Severity: normal
> Tags: stretch
> User: release.debian@packages.debian.org
> Usertags: rm
>
> enigmail is no longer installable with the thunderbird version
> now in stretch (#949736).
>
> Updating enigmail in stretch might be non-trivial due to the
> versioned dependency on gnupg.
>
> It is expected that shortly after the final non-LTS release of stretch
> there will be an LTS update of thunderbird in stretch with a version
> that can no longer be supported by enigmail:
> https://www.enigmail.net/index.php/en/home/news/70-2019-10-08-future-openpgp-support-in-thunderbird
>
> I do not see a better solution than removing the enigmail package
> that is already not installable in stretch.
>
> Daniel Kahn Gillmor Cc'ed, an ACK/NAK would be appreciated.

I'm fine with removing enigmail from stretch; i don't have the capacity
to support it that far back.  I would strongly recommend anyone using a
desktop environment to move to debian stable.

  --dkg


signature.asc
Description: PGP signature

Bug#959800: fontconfig: diff for NMU version 2.13.1-4.1

[Emilio Pozuelo Monfort]

Hi,

On 13/05/2020 15:19, Julien Cristau wrote:
> Control: tags 959800 + patch
> Control: tags 959800 + pending
> 
> Dear maintainer,
> 
> I've prepared an NMU for fontconfig (versioned as 2.13.1-4.1) and
> uploaded it to DELAYED/5. Please feel free to tell me if I
> should delay it longer.

Thanks Julien. Feel free to move it to DELAYED/0.

Cheers,
Emilio

Bug#960599: RFP: pdfslicer -- A simple application to extract, merge, rotate and reorder pages of PDF documents

[Michel Le Bihan]

Package: wnpp
Severity: wishlist

* Package name: pdfslicer
  Version : 1.8.5
  Upstream Author : Julián Unrrein 
* URL : https://junrrein.github.io/pdfslicer/
* License : GPLv3+
  Programming Lang: C++
  Description : A simple application to extract, merge, rotate and reorder
pages of PDF documents

Bug#960614: normaliz: version `LIBEANTIC_0_1_2' not found

[Doug Torrance]

Package: normaliz
Version: 3.8.3+ds-2
Severity: grave
Justification: renders package unusable

Dear Maintainer,

I am getting the following error message when running normaliz:

$ normaliz
normaliz: /usr/lib/x86_64-linux-gnu/libeanticxx.so.0: version 
`LIBEANTICXX_0_1_2' not found (required by normaliz)
normaliz: /usr/lib/x86_64-linux-gnu/libeantic.so.0: version `LIBEANTIC_0_1_2' 
not found (required by normaliz)
normaliz: /usr/lib/x86_64-linux-gnu/libeantic.so.0: version `LIBEANTIC_0_1_2' 
not found (required by /usr/lib/x86_64-linux-gnu/libnormaliz.so.3)
normaliz: /usr/lib/x86_64-linux-gnu/libeanticxx.so.0: version 
`LIBEANTICXX_0_1_2' not found (required by 
/usr/lib/x86_64-linux-gnu/libnormaliz.so.3)

This is also being reported by Debian Continuous Integration, e.g.:
https://ci.debian.net/data/autopkgtest/testing/amd64/n/normaliz/5446108/log.gz

This appears to be due to the recent upload of e-antic 0.1.5 to sid.

Bug#960358: exim4-base: spec.txt, NFS and file locking

[Andreas Metzler]

On 2020-05-14 Vincent Lefevre  wrote:
[...]
> Yes, but I don't know what to do. Even though my mail to exim-users
> was accepted [status=sent (250 OK id=1jYqvc-0001jm-6G)], I can't see
> it on .

No worries, iirc exim-users is moderated for non-members. It should go
through.

cu Andreas

Bug#956510: spirv-tools: change to shared libraries breaks dpkg-shlibdeps during the build of reverse dependencies

[Simon McVittie]

On Sun, 12 Apr 2020 at 11:04:38 +0200, Sebastian Ramacher wrote:
> libplacebo now manually links the libraries from spirv-tools
> (libSPIRV-Tools and libSPIRV-Tools-opt) to work-around #951988 and
> #955431. Since the switch to shared libraries, however, dpkg-shlibdeps
> is unable to produce the correct dependencies when linking those
> libraries.

Are these libraries intended to be a public API, or are they intended to be
a private implementation detail of the CLI tools?

If they're a private implementation detail, then libplacebo shouldn't be
linked to them, and they should either be statically linked into the
various CLI tools, or installed to a private directory with a RUNPATH
so that the CLI tools will find them (like the way /usr/bin/sudo links
to the private library libsudo_util.so.0).

If they're considered to be public libraries, then there are two options,
depending how stable they are:

If their API/ABI are totally unmanaged, then they should probably be
provided as static-only, with libplacebo binNMU'd to pick up new versions.

Or, if their API/ABI are managed, then they should have proper SONAMEs
(see upstream issues, as previously mentioned), and they should be
packaged like shared libraries, with a runtime library package per shared
library (or a single runtime library package if the upstream developer
guarantees that their SONAMEs all change in lockstep, like libglib2.0-0),
and one or more -dev packages. (See Policy §8 for details.)

smcv

Bug#960580: (no subject)

[Thomas Ward]

Tags: -1 + pending

Updated in VCS, but I have other things on my radar so at the moment I
can't push an update (E:OtherObligations).

Marking this as in-progress/pending regardless for now.

Bug#960613: golang-github-mailru-easyjson FTCBFS: doesn't honour DEB_BUILD_OPTIONS=nocheck

[Helmut Grohne]

Source: golang-github-mailru-easyjson
Version: 0.7.0-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

golang-github-mailru-easyjson fails to cross build from source. The
immediate failure is due to the golang-go dependency, for which there is
no agreed solution yet, so we ignore that issue here. Continuing from
there, it attempts running tests despite DEB_BUILD_OPTIONS=nocheck and
fails. So this bug only asks for fixing DEB_BUILD_OPTIONS=nocheck.
Please consider applying the attached patch and close this bug when
doing so.

Helmut
diff --minimal -Nru golang-github-mailru-easyjson-0.7.0/debian/changelog 
golang-github-mailru-easyjson-0.7.0/debian/changelog
--- golang-github-mailru-easyjson-0.7.0/debian/changelog2020-01-15 
01:13:06.0 +0100
+++ golang-github-mailru-easyjson-0.7.0/debian/changelog2020-05-14 
15:18:33.0 +0200
@@ -1,3 +1,10 @@
+golang-github-mailru-easyjson (0.7.0-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Honour DEB_BUILD_OPTIONS=nocheck. (Closes: #-1)
+
+ -- Helmut Grohne   Thu, 14 May 2020 15:18:33 +0200
+
 golang-github-mailru-easyjson (0.7.0-1) unstable; urgency=medium
 
   * Team upload.
diff --minimal -Nru golang-github-mailru-easyjson-0.7.0/debian/rules 
golang-github-mailru-easyjson-0.7.0/debian/rules
--- golang-github-mailru-easyjson-0.7.0/debian/rules2020-01-15 
01:13:06.0 +0100
+++ golang-github-mailru-easyjson-0.7.0/debian/rules2020-05-14 
15:08:48.0 +0200
@@ -3,7 +3,11 @@
 %:
dh $@ --buildsystem=golang --with=golang --builddirectory=build
 
+ifeq (,$(filter nocheck,$(DEB_BUILD_OPTIONS)))
 override_dh_auto_test: generate
+else
+override_dh_auto_test:
+endif
 
 PKG = github.com/mailru/easyjson
 BIN = $(CURDIR)/build/bin

Bug#960612: src:tika: Please add support to build against libjson-simple-java >= 3

[Gilles Filippini]

Package: src:tika
Version: 1.22-1
Severity: normal
Tags: patch

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

I'd like to transition json-simple 3.1.1 to unstable, but tika is a blocker 
since it builds against libjson-simple-java << 3 only.

The json-simple classes used by tika were deprecated in version 2.0.0 [1]. 
There were removed in versions 3.x [2].

[1] https://github.com/cliftonlabs/json-simple/blob/json-simple-2.0.0/README.txt
[2] https://github.com/cliftonlabs/json-simple/blob/json-simple-3.0.1/CHANGELOG

Please find attached a patch proposal to use the current json-simple classes. 
I've tested that the package builds correctly against libjson-simple-java 
version 2.3.0-1 from unstable and version 3.1.1-1~exp2 currently in 
experimental. But I don't known how to test the package afterward.

Thanks in advance for considering.

_g.

- -- System Information:
Debian Release: buster/sid
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.6.0-1-amd64 (SMP w/4 CPU cores)
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

-BEGIN PGP SIGNATURE-

iQEzBAEBCgAdFiEEoJObzArDE05WtIyR7+hsbH/+z4MFAl69ZgQACgkQ7+hsbH/+
z4On6gf+N9/6tHA9M/Rcd5LEYQFt078ti7bcR5dAH5YlXvTtjKRewmBm4p7gl+ts
R7EVnMOO1cRSjecrdzSlUGcInLVwRaDt+1cfC+jGHVq24Jw2U0/Tu9o2OQJvRGHn
nutlzh+o6YNJhfhukOHylXpe8/Jujidl8DMtcOjrAPsqsMle/wRcjNxrRKBMMXd2
Y9MRI6PS8LWFQim/A6rWd1BwhDQwjYt5E5TwjNPrdGoJOPjvDPdTKuBhho0qsN72
7GbAELAP3fbijiUiMvu9NgCrFLkbpse2VDGLjOl1DIoNdxgESVCEjFsJD/Kyr/0J
XkTAioERcub8zPyYfqZNmc0shIO3Tg==
=eJOf
-END PGP SIGNATURE-
diff -Nru tika-1.22/debian/changelog tika-1.22/debian/changelog
--- tika-1.22/debian/changelog  2019-08-05 11:41:25.0 +0200
+++ tika-1.22/debian/changelog  2020-05-14 15:14:44.0 +0200
@@ -1,3 +1,10 @@
+tika (1.22-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Tentative patch to build against json-simple >= 3
+
+ -- Gilles Filippini   Thu, 14 May 2020 15:14:44 +0200
+
 tika (1.22-1) unstable; urgency=medium
 
   * New upstream release
diff -Nru tika-1.22/debian/maven.rules tika-1.22/debian/maven.rules
--- tika-1.22/debian/maven.rules2019-08-05 11:14:12.0 +0200
+++ tika-1.22/debian/maven.rules1970-01-01 01:00:00.0 +0100
@@ -1,14 +0,0 @@
-
-com.fasterxml.jackson.core jackson-annotations * s/.*/2.x/ * *
-com.fasterxml.jackson.core jackson-core * s/.*/2.x/ * *
-com.fasterxml.jackson.core jackson-databind * s/.*/2.x/ * *
-s/com.github.openjson/org.json/ s/openjson/json/ * s/.*/debian/ * *
-s/org.codelibs/com.uwyn/ jhighlight * s/.*/debian/ * *
-org.bouncycastle s/bcmail-jdk15/bcmail/ * s/.*/debian/ * *
-org.bouncycastle s/bcmail-jdk15on/bcmail/ * s/.*/debian/ * *
-org.bouncycastle s/bcprov-jdk15/bcprov/ * s/.*/debian/ * *
-org.bouncycastle s/bcprov-jdk15on/bcprov/ * s/.*/debian/ * *
-s/biz.aQute/biz.aQute.bnd/ * * s/.*/debian/ * *
-org.apache.pdfbox pdfbox * s/.*/2.x/ * *
-org.apache.pdfbox pdfbox-tools * s/.*/2.x/ * *
-s/javax.annotation/org.apache.geronimo.specs/ 
s/javax.annotation-api/geronimo-annotation_1.3_spec/ * s/.*/debian/ * *
diff -Nru tika-1.22/debian/maven.rules.in tika-1.22/debian/maven.rules.in
--- tika-1.22/debian/maven.rules.in 1970-01-01 01:00:00.0 +0100
+++ tika-1.22/debian/maven.rules.in 2020-05-14 14:38:29.0 +0200
@@ -0,0 +1,15 @@
+
+com.fasterxml.jackson.core jackson-annotations * s/.*/2.x/ * *
+com.fasterxml.jackson.core jackson-core * s/.*/2.x/ * *
+com.fasterxml.jackson.core jackson-databind * s/.*/2.x/ * *
+s/com.github.openjson/org.json/ s/openjson/json/ * s/.*/debian/ * *
+s/org.codelibs/com.uwyn/ jhighlight * s/.*/debian/ * *
+org.bouncycastle s/bcmail-jdk15/bcmail/ * s/.*/debian/ * *
+org.bouncycastle s/bcmail-jdk15on/bcmail/ * s/.*/debian/ * *
+org.bouncycastle s/bcprov-jdk15/bcprov/ * s/.*/debian/ * *
+org.bouncycastle s/bcprov-jdk15on/bcprov/ * s/.*/debian/ * *
+s/biz.aQute/biz.aQute.bnd/ * * s/.*/debian/ * *
+org.apache.pdfbox pdfbox * s/.*/2.x/ * *
+org.apache.pdfbox pdfbox-tools * s/.*/2.x/ * *
+s/javax.annotation/org.apache.geronimo.specs/ 
s/javax.annotation-api/geronimo-annotation_1.3_spec/ * s/.*/debian/ * *
+s/com.googlecode.json-simple/@JSON_SIMPLE_MAVEN@/ json-simple * s/.*/debian/ * 
*
diff -Nru tika-1.22/debian/patches/14-json-simple-3.patch 
tika-1.22/debian/patches/14-json-simple-3.patch
--- tika-1.22/debian/patches/14-json-simple-3.patch 1970-01-01 
01:00:00.0 +0100
+++ tika-1.22/debian/patches/14-json-simple-3.patch 2020-05-14 
15:14:44.0 +0200
@@ -0,0 +1,48 @@
+Description: Migrate away from deprecated json-simple 1.x classes
+ See json-simple 2.0.0 changelog:
+ > * Deprecated JSONParse and JSONValue in favor of Jsoner.
+ > * Deprecated JSONStreamAware and JSONAware in favor of Jsonable.
+ > * Deprecated JSONObject in favor of JsonObject.
+ > * Deprecated JSONArray in