Bug#931047: linux-image-4.19.0-4-amd64: bridge igmp snooping is throughly broken

2019-06-25 Thread Anton Ivanov
Package: linux-image-4.19.0-4-amd64
Version: linux-image-4.19.0-4-amd64
Severity: minor

Dear Maintainer,

The multicast/igmp snooping code in the linux bridge is throughly broken:

1. If a program binds to a v4 multicast group a v6 entry is created in the 
bridge mdb instead
2. As a result multicast appears to be flooded instead of limited to the ports 
for which there is a known igmp join.

The end result is that it sort-a works, but is not anywhere near correct or 
performing.

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

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



Bug#931048: linux-image-4.19.0-4-amd64: bridge MAC learning is broken

2019-06-25 Thread Anton Ivanov
Package: src:linux
Version: 4.19.28-1
Severity: normal
File: linux-image-4.19.0-4-amd64

Dear Maintainer,

Bridge MAC learning is completely broken at present. 

How to reproduce:
1. Build one or more MINIMAL vms or connect machines with MINIMAL installs to 
interfaces which join to a Linux bridge
2. Observe the bridge fdb using the bridge utility or brctl. 
3. Run traffic.

Obvious issues:

1. MACs expire even if there are gigabytes of traffic flowing to/from them. The 
refresh if used is completely broken
2. MACs are not immediately reinstated into the forwarding database if there is 
traffic upon expiry

Observations:

This seems to be a result of learning being tightly bound with the idea of 
neighbour and neighbour discovery code. MACs
are learned instantaneously if one of the hosts issues a multicast join - f.e. 
performs IPv6 neighbour discovery or runs
avahi. If either one of these is not present the bridge code does not function 
as it should. While as an idea this is good
it should not completely replace learning from unicast traffic.

-- Package-specific info:
** Version:
Linux version 4.19.0-4-amd64 (debian-ker...@lists.debian.org) (gcc version 
8.3.0 (Debian 8.3.0-2)) #1 SMP Debian 4.19.28-1 (2019-03-12)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-4.19.0-4-amd64 
root=UUID=3db3d925-a3d9-4c1d-b63d-c087261f1fb2 ro quiet

** Tainted: WE (8704)
 * Taint on warning.
 * Unsigned module has been loaded.

** Kernel log:
Unable to read kernel log; any relevant messages should be attached

** Model information
sys_vendor: System manufacturer
product_name: System Product Name
product_version: System Version
chassis_vendor: Default string
chassis_version: Default string
bios_vendor: American Megatrends Inc.
bios_version: 0409
board_vendor: ASUSTeK COMPUTER INC.
board_name: PRIME B450M-A
board_version: Rev X.0x

** Loaded modules:
cfg80211(E)
bnep(E)
nfnetlink_queue(E)
nfnetlink_log(E)
nfnetlink(E)
bluetooth(E)
drbg(E)
ansi_cprng(E)
ecdh_generic(E)
squashfs(E)
loop(E)
ufs(E)
qnx4(E)
hfsplus(E)
hfs(E)
minix(E)
ntfs(E)
msdos(E)
jfs(E)
xfs(E)
dm_mod(E)
cpuid(E)
uas(E)
usb_storage(E)
xt_nat(E)
xt_tcpudp(E)
xt_conntrack(E)
iptable_nat(E)
nf_nat_ipv4(E)
nf_nat(E)
nf_conntrack(E)
nf_defrag_ipv6(E)
nf_defrag_ipv4(E)
ip6table_filter(E)
ip6_tables(E)
nfsv3(E)
rpcsec_gss_krb5(E)
nfsv4(E)
dns_resolver(E)
nfs(E)
fscache(E)
iptable_filter(E)
veth(E)
bridge(E)
8021q(E)
garp(E)
mrp(E)
stp(E)
llc(E)
fuse(E)
tun(E)
binfmt_misc(E)
nls_ascii(E)
eeepc_wmi(E)
asus_wmi(E)
nls_cp437(E)
sparse_keymap(E)
rfkill(E)
wmi_bmof(E)
vfat(E)
fat(E)
edac_mce_amd(E)
uvcvideo(E)
videobuf2_vmalloc(E)
videobuf2_memops(E)
videobuf2_v4l2(E)
kvm_amd(E)
videobuf2_common(E)
ccp(E)
amdkfd(E)
videodev(E)
rng_core(E)
media(E)
snd_usb_audio(E)
joydev(E)
snd_usbmidi_lib(E)
kvm(E)
snd_rawmidi(E)
evdev(E)
snd_seq_device(E)
irqbypass(E)
efi_pstore(E)
crct10dif_pclmul(E)
crc32_pclmul(E)
snd_hda_codec_realtek(E)
snd_hda_codec_generic(E)
amdgpu(E)
ghash_clmulni_intel(E)
snd_hda_codec_hdmi(E)
efivars(E)
snd_hda_intel(E)
pcspkr(E)
chash(E)
snd_hda_codec(E)
gpu_sched(E)
snd_hda_core(E)
ttm(E)
snd_hwdep(E)
k10temp(E)
sp5100_tco(E)
snd_pcm_oss(E)
snd_mixer_oss(E)
drm_kms_helper(E)
snd_pcm(E)
snd_timer(E)
drm(E)
snd(E)
soundcore(E)
sg(E)
wmi(E)
video(E)
button(E)
pcc_cpufreq(E)
acpi_cpufreq(E)
hwmon_vid(E)
parport_pc(E)
nfsd(E)
auth_rpcgss(E)
ppdev(E)
nfs_acl(E)
lockd(E)
lp(E)
grace(E)
parport(E)
sunrpc(E)
efivarfs(E)
ip_tables(E)
x_tables(E)
autofs4(E)
ext4(E)
crc16(E)
mbcache(E)
jbd2(E)
fscrypto(E)
ecb(E)
btrfs(E)
zstd_decompress(E)
zstd_compress(E)
xxhash(E)
raid10(E)
raid456(E)
async_raid6_recov(E)
async_memcpy(E)
async_pq(E)
async_xor(E)
async_tx(E)
xor(E)
raid6_pq(E)
libcrc32c(E)
crc32c_generic(E)
raid0(E)
multipath(E)
linear(E)
raid1(E)
md_mod(E)
sd_mod(E)
hid_generic(E)
usbhid(E)
hid(E)
crc32c_intel(E)
aesni_intel(E)
aes_x86_64(E)
crypto_simd(E)
cryptd(E)
glue_helper(E)
ahci(E)
mptsas(E)
xhci_pci(E)
libahci(E)
igb(E)
mptscsih(E)
r8169(E)
i2c_piix4(E)
xhci_hcd(E)
realtek(E)
mptbase(E)
i2c_algo_bit(E)
libphy(E)
libata(E)
scsi_transport_sas(E)
dca(E)
usbcore(E)
usb_common(E)
scsi_mod(E)
gpio_amdpt(E)
gpio_generic(E)

** PCI devices:
00:00.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Device 
[1022:15d0]
Subsystem: ASUSTeK Computer Inc. Device [1043:876b]
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- 

00:01.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Device 
[1022:1452]
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: 
Kernel driver in use: pcieport

00:01.2 PCI bridge [0604]: Advanced Micro Devices, Inc. [A

Bug#928882: unblock: [pre-approval] ghc/8.4.4+dfsg1-3

2019-06-25 Thread Emanuele Olivetti
Dear Ilias,

I am very happy to announce that git-annex v.7.20190129-3+b1 for armel
works perfectly on my QNAP TS-219P (armv5tel)!

I ran the extensive test suite within git-annex, with "git-annex test" and
all the 227 tests passed without error - here is the last line of that
execution:

All 227 tests passed (1699.83s)

Please find attached entire (compressed) log of >2k lines, captured with
"nohup git-annex test 2>&1 > git-annex-test.output &".

And here follows the transcript of the installation of git-annex from sid,
confirming that it's the version you generated:

drakestail:/tmp/test# apt install -t sid git-annex
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following additional packages will be installed:
  aria2 git git-man git-remote-gcrypt libaria2-0 libcom-err2 libcomerr2
libcurl3-gnutls liberror-perl libgssapi-krb5-2 libk5crypto3 libkrb5-3
libkrb5support0 libpcre2-8-0 nocache
Suggested packages:
  git-daemon-run | git-daemon-sysvinit git-doc git-el git-email git-gui
gitk gitweb git-cvs git-mediawiki git-svn xdot bup adb tor magic-wormhole
tahoe-lafs uftp youtube-dl rclone krb5-doc krb5-user
The following NEW packages will be installed:
  aria2 git git-annex git-man git-remote-gcrypt libaria2-0 libcom-err2
liberror-perl libpcre2-8-0 nocache
The following packages will be upgraded:
  libcomerr2 libcurl3-gnutls libgssapi-krb5-2 libk5crypto3 libkrb5-3
libkrb5support0
6 upgraded, 10 newly installed, 0 to remove and 869 not upgraded.
Need to get 20.9 MB of archives.
After this operation, 111 MB of additional disk space will be used.
Do you want to continue? [Y/n]
Get:1 http://ftp.it.debian.org/debian sid/main armel libcom-err2 armel
1.45.2-1 [68.9 kB]
Get:2 http://ftp.it.debian.org/debian sid/main armel libcomerr2 armel
1.45.2-1 [65.5 kB]
Get:3 http://ftp.it.debian.org/debian buster/main armel libaria2-0
armel 1.34.0-4 [916 kB]
Get:4 http://ftp.it.debian.org/debian buster/main armel aria2 armel
1.34.0-4 [362 kB]
Get:5 http://ftp.it.debian.org/debian buster/main armel
libgssapi-krb5-2 armel 1.17-3 [136 kB]
Get:6 http://ftp.it.debian.org/debian buster/main armel libkrb5-3 armel
1.17-3 [319 kB]
Get:7 http://ftp.it.debian.org/debian buster/main armel libk5crypto3
armel 1.17-3 [118 kB]
Get:8 http://ftp.it.debian.org/debian buster/main armel libkrb5support0
armel 1.17-3 [62.2 kB]
Get:9 http://ftp.it.debian.org/debian buster/main armel libcurl3-gnutls
armel 7.64.0-4 [292 kB]
Get:10 http://ftp.it.debian.org/debian buster/main armel libpcre2-8-0
armel 10.32-5 [185 kB]
Get:11 http://ftp.it.debian.org/debian buster/main armel liberror-perl
all 0.17027-2 [30.9 kB]
Get:12 http://ftp.it.debian.org/debian buster/main armel git-man all
1:2.20.1-2 [1,619 kB]
Get:13 http://ftp.it.debian.org/debian buster/main armel git armel
1:2.20.1-2 [4,402 kB]
Get:14 http://ftp.it.debian.org/debian sid/main armel git-annex armel
7.20190129-3+b1 [12.3 MB]
Get:15 http://ftp.it.debian.org/debian buster/main armel
git-remote-gcrypt all 1.2-1 [15.8 kB]
Get:16 http://ftp.it.debian.org/debian buster/main armel nocache armel
1.1-1 [17.7 kB]
Fetched 20.9 MB in 3s (5,498 kB/s)
Reading changelogs... Done
(Reading database ... 100879 files and directories currently installed.)
Preparing to unpack .../libcomerr2_1.45.2-1_armel.deb ...
Unpacking libcomerr2:armel (1.45.2-1) over (1.43.4-2) ...
Selecting previously unselected package libcom-err2:armel.
Preparing to unpack .../libcom-err2_1.45.2-1_armel.deb ...
Unpacking libcom-err2:armel (1.45.2-1) ...
Setting up libcom-err2:armel (1.45.2-1) ...
Selecting previously unselected package libaria2-0:armel.
(Reading database ... 100882 files and directories currently installed.)
Preparing to unpack .../00-libaria2-0_1.34.0-4_armel.deb ...
Unpacking libaria2-0:armel (1.34.0-4) ...
Selecting previously unselected package aria2.
Preparing to unpack .../01-aria2_1.34.0-4_armel.deb ...
Unpacking aria2 (1.34.0-4) ...
Preparing to unpack .../02-libgssapi-krb5-2_1.17-3_armel.deb ...
Unpacking libgssapi-krb5-2:armel (1.17-3) over (1.15-1+deb9u1) ...
Preparing to unpack .../03-libkrb5-3_1.17-3_armel.deb ...
Unpacking libkrb5-3:armel (1.17-3) over (1.15-1+deb9u1) ...
Preparing to unpack .../04-libk5crypto3_1.17-3_armel.deb ...
Unpacking libk5crypto3:armel (1.17-3) over (1.15-1+deb9u1) ...
Preparing to unpack .../05-libkrb5support0_1.17-3_armel.deb ...
Unpacking libkrb5support0:armel (1.17-3) over (1.15-1+deb9u1) ...
Preparing to unpack .../06-libcurl3-gnutls_7.64.0-4_armel.deb ...
Unpacking libcurl3-gnutls:armel (7.64.0-4) over (7.52.1-5+deb9u9) ...
Selecting previously unselected package libpcre2-8-0:armel.
Preparing to unpack .../07-libpcre2-8-0_10.32-5_armel.deb ...
Unpacking libpcre2-8-0:armel (10.32-5) ...
Selectin

Bug#930887: [Debian-ha-maintainers] Bug#930887: CVE-2019-10153

2019-06-25 Thread wferi
Valentin Vidić  writes:

> On Mon, Jun 24, 2019 at 02:03:11PM +0200, wf...@niif.hu wrote:
>
>> According to https://security-tracker.debian.org/tracker/CVE-2019-10153,
>> the vulnerable code is not present in stretch.  However, I don't
>> understand why this does not count:
>> 
>> https://salsa.debian.org/ha-team/fence-agents/blob/debian/4.0.25-1/fence/agents/rhevm/fence_rhevm.py#L124
>> 
>> Also, according to http://pycurl.io/docs/latest/unicode.html#unicode the
>> URL conversion to ASCII can fail even when it's implicit, though that
>> probably isn't user controllable, thus may not count.
>
> I suppose the upstream marked it for 4.3.3

https://bugzilla.redhat.com/show_bug.cgi?id=1716286 is more general,
mentioning "fence-agents prior to version 4.3.4"

> but we can make a fix for stretch to be on the safe side?

I think so, but I may overlook something.  Also, I find the switch to
UTF-8 decoding a somewhat unsatisfactory fix: is it wise to depend on
the result being correctly UTF-8 encoded?  If anything goes wrong, an
exception is thrown all the same, it depends on the server.  It may be
desirable, though, I don't know a thing about rhevm.
-- 
Feri



Bug#914577: ITP: dropwatch -- A tool for detecting and diagnosing packets being dropped

2019-06-25 Thread Alexandros Kosiaris
Package: wnpp
Followup-For: Bug #914577
Owner: Alexandros Kosiaris 



Bug#929834: Buster/XFCE unlock screen is blank

2019-06-25 Thread Yves-Alexis Perez
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

control: affects -1 xserver-xorg-core

On Sat, 2019-06-22 at 17:34 -0400, John Franklin wrote:
> I've been suffering from this bug in a clean Buster system, too.  A
> solution noted in another bug tracker is to explicitly tell X.org to
> use the intel driver.  Apparently, it uses the fbdev driver by default.
> (Sorry, I don't have a reference to other bug handy.) 

Hi John,

it uses the modesetting DDX driver by default, not fbdev, but it's good to
know that changing to the intel DDX workarounds the issue.

Regards
- -- 
Yves-Alexis
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAl0Rzk4ACgkQ3rYcyPpX
RFsKGggAgv9hw7Cen7bEiCpPU87DniXPvJ+5NsszICoQXal7YBet/RMBpyYSoujo
7G32lLpazDO1s+f8TGReCx/JopjLsZgLVxtL6tOCBLFFBzfRTG8HnoQpwJrITwWU
pPbp3e+shd5I6yKPqdv+ZoBG8Eq58poPgrzJbJXLRN3vMAafChl0C+b/N4NYUBuJ
HIaz1qkKuoU3ZDtnMdNrIbsfHr/baO9B1Dht5/0TO3WHgd5UIRIuOqNgi4LnJxVF
QOQJEYtJSWSZdJGVBGhP9/qxAPI69j/NgEYL1L4ITYb5YrDbPNJUbxBBw3G3nG2Z
4cbF9eOmWAqn4iD8EfoWA4p/i3fuCQ==
=XzOA
-END PGP SIGNATURE-



Bug#931049: ITP: r-cran-getoptlong -- GNU R parsing command-Line arguments and variable interpolation

2019-06-25 Thread Andreas Tille
Package: wnpp
Severity: wishlist

Subject: ITP: r-cran-getoptlong -- GNU R parsing command-Line arguments and 
variable interpolation
Package: wnpp
Owner: Andreas Tille 
Severity: wishlist

* Package name: r-cran-getoptlong
  Version : 0.1.7
  Upstream Author : Zuguang Gu
* URL : https://cran.r-project.org/package=GetoptLong
* License : MIT
  Programming Lang: GNU R
  Description : GNU R parsing command-Line arguments and variable 
interpolation
 This is yet another command-line argument parser which wraps the
 powerful Perl module Getopt::Long and with some adaptation for easier use
 in R. It also provides a simple way for variable interpolation in R.

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-cran-getoptlong



Bug#931050: ITP: r-cran-clue -- GNU R cluster ensembles

2019-06-25 Thread Andreas Tille
Package: wnpp
Severity: wishlist

Subject: ITP: r-cran-clue -- GNU R cluster ensembles
Package: wnpp
Owner: Andreas Tille 
Severity: wishlist

* Package name: r-cran-clue
  Version : 0.3
  Upstream Author : Kurt Hornik,
* URL : https://cran.r-project.org/package=clue
* License : GPL-2
  Programming Lang: GNU R
  Description : GNU R cluster ensembles
 Cluster ensembles are collections of individual solutions to a given
 clustering problem which are useful or necessary to consider in a wide
 range of applications.  The R package~\pkg{clue} provides an
 extensible computational environment for creating and analyzing
 cluster ensembles, with basic data structures for representing
 partitions and hierarchies, and facilities for computing on these,
 including methods for measuring proximity and obtaining consensus and
 'secondary' clusterings.

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-cran-clue



Bug#930988: libtifiles FTCBFS: Missing dependency tfdocgen

2019-06-25 Thread Lionel Debroux
Hi,

This is upstream for tfdocgen, libti*(2), gfm and tilp2 :)

> > libtifiles fails to cross build because its dependency, tfdocgen
> > package, is missing. Using tfdocgen:native instead of tfdocgen to
> > cross-build can solve this problem.
>
> Did you look into whether we can instead mark tfdocgen Multi-Arch:
> foreign? I suspect that every build-rdep will need the native version.
> If so, marking tfdocgen means we can fix four packages with one
> upload. The tricky question is whether the marking is actually
> correct. Deciding will involve knowlegde of what precisely tfdocgen
> does, so this likely needs help from the relevant package maintainer.
tfdocgen is a simple HTML documentation generator, which supports a
Doxygen-like (but not Doxygen-compatible) syntax for C/C++ code, and
maybe other languages which supports /** */ comments, I haven't tried.
It was written by the previous maintainer over a decade ago, I have
barely modified it. The files it produces are packaged in the -dev packages.


Bye,
Lionel Debroux.



Bug#931044: installing python3.4 fails

2019-06-25 Thread Christoph Berg
Re: Andreas Bießmann 2019-06-25 
<12977de3-730f-e342-ec86-b574439e7...@biessmann.de>
> Setting up python3.4 (3.4.2-1+deb8u3) ...
>   File "/usr/lib/python3.4/http/client.py", line 1014
> raise InvalidURL(f"URL can't contain control characters. {url!r} "
>  ^
> SyntaxError: invalid syntax

Looks like the fix for this:

   * CVE-2019-9740, CVE-2019-9947
 Issue #30458: Disallow control chars in http URLs in urllib.urlopen.

Roberto?

Christoph



Bug#930223: need help with building node-dagre-d3-renderer with webpack

2019-06-25 Thread Pirate Praveen
Control: tag -1 help

On Sat, 08 Jun 2019 20:48:32 +0500 Pirate Praveen
 wrote:> This library is a dependency of
gitlab. Since it uses babel and webpack
> to generate ES5 code, it is not suitable for embedding.

With node-d3 in NEW/salsa (#801765), I get this error. d3-format and
d3-scale is embedded in node-d3 and installed in
/usr/lib/nodejs/d3/node_modules. Because of missing ES modules in
node-d3-format (#930920) we cannot use the packaged version.


ERROR in /usr/lib/nodejs/d3/index.js
Module not found: Error: Can't resolve 'd3-format' in
'/usr/lib/nodejs/d3'
 @ /usr/lib/nodejs/d3/index.js 13:0-26
 @ ./lib/render.js
 @ ./index.js

ERROR in /usr/lib/nodejs/d3/index.js
Module not found: Error: Can't resolve 'd3-scale' in
'/usr/lib/nodejs/d3'
 @ /usr/lib/nodejs/d3/index.js 23:0-25
 @ ./lib/render.js
 @ ./index.js


I tried this patch (also tried /usr/lib/nodejs/d3/node_modules instead
of just node_modules), but webpack still fails. Upstream used webpack 4,
we have webpack 3.5.6, but that should not be an issue for resolving I
think.

$ cat debian/patches/use-modules-embedded-in-d3.patch
--- a/webpack.config.babel.js
+++ b/webpack.config.babel.js
@@ -15,7 +15,7 @@
   },

   resolve: {
-modules: ['/usr/lib/nodejs'],
+modules: ['/usr/lib/nodejs', 'node_modules'],
   },

   resolveLoader: {

The easiest fix would be updating node-d3-format, but it is not team
maintained any more (result of an accidental hijack from me). Other
option would be to fix webpack configuration. Hope someone can help here.



signature.asc
Description: OpenPGP digital signature


Bug#931051: firejail hangs on strace with the firefox or waterfox profile

2019-06-25 Thread Vincent Lefevre
Package: firejail
Version: 0.9.58.2-2
Severity: important

firejail hangs on strace with the firefox or waterfox profile.
Example with the ls command (which is simpler than a web browser):

zira:~> /usr/bin/firejail --allow-debuggers --profile=firefox strace /bin/ls
Reading profile /etc/firejail/firefox.profile
Reading profile /etc/firejail/firefox-common.profile
Reading profile /etc/firejail/disable-common.inc
Reading profile /etc/firejail/disable-interpreters.inc
Reading profile /etc/firejail/disable-programs.inc
Reading profile /etc/firejail/whitelist-common.inc
Reading profile /etc/firejail/whitelist-var-common.inc
Warning: networking feature is disabled in Firejail configuration file
Parent pid 2285, child pid 2286
Warning: An abstract unix socket for session D-BUS might still be available. 
Use --net or remove unix from --protocol set.
Post-exec seccomp protector enabled
Seccomp list in: 
@clock,@cpu-emulation,@debug,@module,@obsolete,@raw-io,@reboot,@resources,@swap,acct,add_key,bpf,fanotify_init,io_cancel,io_destroy,io_getevents,io_setup,io_submit,ioprio_set,kcmp,keyctl,mount,name_to_handle_at,nfsservctl,ni_syscall,open_by_handle_at,personality,pivot_root,process_vm_readv,ptrace,remap_file_pages,request_key,setdomainname,sethostname,syslog,umount,umount2,userfaultfd,vhangup,vmsplice,
 check list: @default-keep, prelist: 
adjtimex,clock_adjtime,clock_settime,settimeofday,modify_ldt,lookup_dcookie,perf_event_open,process_vm_writev,delete_module,finit_module,init_module,_sysctl,afs_syscall,create_module,get_kernel_syms,getpmsg,putpmsg,query_module,security,sysfs,tuxcall,uselib,ustat,vserver,ioperm,iopl,kexec_load,kexec_file_load,reboot,set_mempolicy,migrate_pages,move_pages,mbind,swapon,swapoff,acct,add_key,bpf,fanotify_init,io_cancel,io_destroy,io_getevents,io_setup,io_submit,ioprio_set,kcmp,keyctl,mount,name_to_handle_at,nfsservctl,open_by_handle_at,personality,pivot_root,process_vm_readv,ptrace,remap_file_pages,request_key,setdomainname,sethostname,syslog,umount2,userfaultfd,vhangup,vmsplice,
Child process initialized in 78.27 ms

and nothing else occurs. This makes impossible to try to see why
some application does not work in firejail.

Ditto when using --profile=/etc/firejail/firefox.profile directly
(as given as an example for --allow-debuggers in the firejail(1)
man page).

No problems with the default profile or without strace.

-- System Information:
Debian Release: 10.0
  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 4.19.0-5-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=POSIX, LC_CTYPE=en_US.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 firejail depends on:
ii  libapparmor1  2.13.2-10
ii  libc6 2.28-10

Versions of packages firejail recommends:
ii  firejail-profiles  0.9.58.2-2
ii  iproute2   4.20.0-2
ii  iptables   1.8.2-4
ii  xauth  1:1.0.10-1
ii  xpra   2.4.3+dfsg1-1

firejail suggests no packages.

-- no debconf information



Bug#931053: ITP: r-cran-cowplot -- GNU R streamlined plot theme and plot annotations for 'ggplot2'

2019-06-25 Thread Andreas Tille
Package: wnpp
Severity: wishlist

Subject: ITP: r-cran-cowplot -- GNU R streamlined plot theme and plot 
annotations for 'ggplot2'
Package: wnpp
Owner: Andreas Tille 
Severity: wishlist

* Package name: r-cran-cowplot
  Version : 0.9.4
  Upstream Author : Claus O. Wilke,
* URL : https://cran.r-project.org/package=cowplot
* License : GPL-2
  Programming Lang: GNU R
  Description : GNU R streamlined plot theme and plot annotations for 
'ggplot2'
 Some helpful extensions and modifications to the 'ggplot2'
 package. In particular, this package makes it easy to combine multiple
 'ggplot2' plots into one and label them with letters, e.g. A, B, C, etc.,
 as is often required for scientific publications. The package also provides
 a streamlined and clean theme that is used in the Wilke lab, hence the
 package name, which stands for Claus O. Wilke's plot package.

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-cran-cowplot



Bug#931052: unblock: webkit2gtk/2.24.2-2

2019-06-25 Thread Alberto Garcia
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package webkit2gtk

Upstream WebKitGTK has recently stopped supporting i386 CPUs without
SSE2 extensions, as other browsers (Chromium, Firefox) already did a
few years ago.

There is at least one bug report (#930932, opened two days ago) from a
user that cannot run Zenity on a machine with an Athlon XP CPU because
of this, and some hours ago bug #930935 was filed against webkit2gtk.

WebKit generates SSE2 instructions with its JIT compiler, and the
build scripts also force gcc to pass the -msse2 compilation flags.

This upload disables the JIT compiler and enables the CLoop JavaScript
interpreter, which is slower but works on all CPUs. It also removes
the gcc SSE2 flags. Only the i386 build is affected by these changes.

Debdiff attached.

Note: the changelog includes the list of CVEs from the latest security
advisory, published shortly after the previous release. This is purely
informative and has no effects on the package.

unblock webkit2gtk/2.24.2-2

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

Kernel: Linux 4.9.0-9-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), 
LANGUAGE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
diff -Nru webkit2gtk-2.24.2/debian/changelog webkit2gtk-2.24.2/debian/changelog
--- webkit2gtk-2.24.2/debian/changelog  2019-05-17 17:40:52.0 +0300
+++ webkit2gtk-2.24.2/debian/changelog  2019-06-24 16:34:09.0 +0300
@@ -1,3 +1,26 @@
+webkit2gtk (2.24.2-2) unstable; urgency=high
+
+  * The WebKitGTK security advisory WSA-2019-0003 lists the following
+security fixes in the latest versions of WebKitGTK+:
++ CVE-2019-8571, CVE-2019-8583, CVE-2019-8586, CVE-2019-8594,
+  CVE-2019-8609, CVE-2019-8611, CVE-2019-8622 and CVE-2019-8623
+  (fixed in 2.24.0).
++ CVE-2019-6237, CVE-2019-8584, CVE-2019-8587, CVE-2019-8596,
+  CVE-2019-8597, CVE-2019-8601, CVE-2019-8608, CVE-2019-8610 and
+  CVE-2019-8619 (fixed in 2.24.1).
++ CVE-2019-8595, CVE-2019-8607 and CVE-2019-8615 (fixed in 2.24.2).
+  * Use the CLoop Javascript interpreter in i386 and stop telling gcc to
+use SSE2 instructions (Closes: #930935).
++ debian/rules:
+  - Build with -DENABLE_JIT=OFF -DENABLE_C_LOOP=ON and stop using
+-msse2 -mfpmath=sse.
++ debian/patches/dont-detect-sse2.patch:
+  - Don't check for SSE2 support.
++ debian/NEWS:
+  - Remove item about the requirement to have an SSE2-capable CPU.
+
+ -- Alberto Garcia   Mon, 24 Jun 2019 16:34:09 +0300
+
 webkit2gtk (2.24.2-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru webkit2gtk-2.24.2/debian/NEWS webkit2gtk-2.24.2/debian/NEWS
--- webkit2gtk-2.24.2/debian/NEWS   2019-05-17 17:40:52.0 +0300
+++ webkit2gtk-2.24.2/debian/NEWS   2019-06-24 16:34:09.0 +0300
@@ -1,12 +1,3 @@
-webkit2gtk (2.24.1-2) unstable; urgency=high
-
-  Since version 2.24.0, i386 builds of WebKitGTK require an SSE2-capable
-  CPU. This instruction set was first introduced with the Pentium 4 in
-  year 2000. Support for older processors was dropped in WebKitGTK
-  upstream and is unfortunately not expected to come back.
-
- -- Alberto Garcia   Fri, 10 May 2019 15:40:28 +0300
-
 webkit2gtk (2.20.0-2) unstable; urgency=medium
 
   webkit2gtk 2.20.0 contains a security feature named Gigacage that
diff -Nru webkit2gtk-2.24.2/debian/patches/dont-detect-sse2.patch 
webkit2gtk-2.24.2/debian/patches/dont-detect-sse2.patch
--- webkit2gtk-2.24.2/debian/patches/dont-detect-sse2.patch 1970-01-01 
02:00:00.0 +0200
+++ webkit2gtk-2.24.2/debian/patches/dont-detect-sse2.patch 2019-06-24 
16:34:09.0 +0300
@@ -0,0 +1,24 @@
+From: Alberto Garcia 
+Subject: Don't check for SSE2 support on i386
+Bug-Debian: https://bugs.debian.org/930935
+Forwarded: no
+Index: webkitgtk/Source/cmake/WebKitCompilerFlags.cmake
+===
+--- webkitgtk.orig/Source/cmake/WebKitCompilerFlags.cmake
 webkitgtk/Source/cmake/WebKitCompilerFlags.cmake
+@@ -144,15 +144,6 @@ if (COMPILER_IS_GCC_OR_CLANG)
+ if (CMAKE_COMPILER_IS_GNUCXX)
+ WEBKIT_PREPEND_GLOBAL_COMPILER_FLAGS(-Wno-expansion-to-defined)
+ endif ()
+-
+-# Force SSE2 fp on x86 builds.
+-if (WTF_CPU_X86 AND NOT CMAKE_CROSSCOMPILING)
+-WEBKIT_PREPEND_GLOBAL_COMPILER_FLAGS(-msse2 -mfpmath=sse)
+-include(DetectSSE2)
+-if (NOT SSE2_SUPPORT_FOUND)
+-message(FATAL_ERROR "SSE2 support is required to compile WebKit")
+-endif ()
+-endif ()
+ endif ()
+ 
+ if (COMPILER_IS_GCC_OR_CLANG AND NOT MSVC)
diff -Nru webkit2gtk-2.24.2/debian/patches/series 
webkit2gtk-2.24.2/debian/patches/series
--- webkit2gtk-2.24.2/debian/patches/series 201

Bug#930223: need help with building node-dagre-d3-renderer with webpack

2019-06-25 Thread Pirate Praveen



Control: tag -1 -help

On Tue, 25 Jun, 2019 at 1:22 PM, Pirate Praveen 
 wrote:

The easiest fix would be updating node-d3-format, but it is not team
maintained any more (result of an accidental hijack from me). Other
option would be to fix webpack configuration. Hope someone can help 
here.


While looking for something else in package.json, I realized, there was 
a line excluding node_modules and there was two places I needed to 
update. With the following patch, webpack is successful.


--- a/webpack.config.babel.js
+++ b/webpack.config.babel.js
@@ -15,7 +15,7 @@
  },

  resolve: {
-modules: ['/usr/lib/nodejs'],
+modules: ['/usr/lib/nodejs','node_modules'],
  },

  resolveLoader: {
@@ -26,7 +26,6 @@
rules: [
  {
test: /\.js$/,
-exclude: /node_modules/,
use: {
  loader: 'babel-loader'
}
@@ -49,7 +48,7 @@
  },

  resolve: {
-modules: ['/usr/lib/nodejs'],
+modules: ['/usr/lib/nodejs','node_modules'],
  },

  resolveLoader: {
@@ -60,7 +59,6 @@
rules: [
  {
test: /\.js$/,
-exclude: /node_modules/,
use: {
  loader: 'babel-loader'
}



Bug#930935: webkit2gtk: Baseline violation on i386

2019-06-25 Thread Alberto Garcia
On Mon, Jun 24, 2019 at 04:48:43PM +0300, Alberto Garcia wrote:

> If no one has anything to say I'll upload it today. This should work
> on all i386 CPUs, and we can later discuss if it's worth thinking of
> a solution for SSE2-capable machines.

Uploaded, unblock request at #931052

I don't have an Athlon XP myself but I can reproduce the bug (and
verify that the fix works) emulating a Pentium 3 with QEMU.

Berto



Bug#892232: bug#32384: Bug#892232: guile-2.2: FTBFS on alpha: test-conversion fails

2019-06-25 Thread Ludovic Courtès
Hi all,

Rob Browning  skribis:

> [Please preserve 892232-forwar...@bugs.debian.org in relevant replies.]
>
> test-conversion appears to be failing on alpha hosts as reported below,
> and seen here: 
> https://buildd.debian.org/status/fetch.php?pkg=guile-2.2&arch=alpha&ver=2.2.4%2B1-1&stamp=1533027639&raw=0

I’m afraid there’s not much we can do.  Unless someone with access to an
Alpha machine can debug the issue, I’d close it as “wontfix”.

WDYT?

Thanks,
Ludo’.



Bug#929527: Bug#914694

2019-06-25 Thread Thomas Lamprecht
Don't want to nag to much but is there any news regarding this?
Buster is planned to release pretty soon (<2 weeks) and iptables
is quite a important package, IMO. Maybe it went under my radar
but I saw no unblock request on d.o release list.

For now I just used update-alternative to use the legacy variants,
which work fine here, but if my understanding is correct then this
package (version?) could be thrown out of Buster if it still has RC
bug so close to the planned release, I mean iptables may be an
exception as it's quite relevant and still used by a lot but still.



Bug#902343: osifont

2019-06-25 Thread Gürkan Myczko

Hi Kurt and Martin

Kurt: please go ahead. How's progress? haven't found it on salsa.d.o? If 
you're on irc, there's #debian-fonts


Martin: I don't think it's similar at all, so I don't see any objections 
to have that ISO standardized isofont

in Debian.

Cheers,



Bug#925906: sqlite3: FTCBFS: configure fails to find readline.h

2019-06-25 Thread Yuriy M. Kaminskiy
Control: tag -1 - moreinfo

On 25.06.2019 07:03, Helmut Grohne wrote:

> On Thu, Mar 28, 2019 at 01:14:13PM +0300, Yuriy M. Kaminskiy wrote:
>> When cross-building sqlite3, it fails to detect readline: while
>> actual code wants only  (see src/shell.c.in),
>> but configure.ac checks for ;
> 
> I am unable to reproduce this issue. The public autobuilder cannot
> reproduce it either: http://crossqa.debian.net/src/sqlite3 This is using
> sbuild for performing the build. How does your build environment differ
> to make sqlite3 fail? Please remove the moreinfo tag when providing an
> answer.

I built for armhf on i386/stretch host with pbuilder.

Relevant lines from
http://crossqa.debian.net/build/sqlite3_3.27.2-3_armhf_20190622023957.log
(with mysteriously successful readline.h detection)

checking for library containing readline... no
checking for library containing tgetent... -lncurses
checking for readline in -lreadline... yes
checking for readline.h... (cached) yes

Relevant lines from my (with failing readline.h detection):

checking for library containing readline... no
checking for library containing tgetent... -ltermcap
checking for readline in -lreadline... yes
checking readline.h usability... no
checking readline.h presence... no
checking for readline.h... no

I have no idea what triggers difference (why there are no "checking
readline.h (usability|presence)... " [that is expected to be emitted by 
AC_CHECK_HEADER] in autobuilder log? where that "(cached) yes" comes from?)

FWIW, here are relevant lines from stretch-backports buildd
https://buildd.debian.org/status/fetch.php?pkg=sqlite3&arch=armhf&ver=3.27.2-3%7Ebpo9%2B1&stamp=1560524760&raw=0

(native build, *NOT* cross-compiled)

checking for library containing readline... no
checking for library containing tgetent... -ltermcap
checking for readline in -lreadline... yes
checking readline.h usability... no
checking readline.h presence... no
checking for readline.h... no
checking for /usr/include/readline.h... no
checking for /usr/include/readline/readline.h... yes

(Note: there are /(usability|presence)/ lines here; also note that it also 
fails to find readline.h, and fallbacks to below code [which is disabled for 
cross-builds])

>> @@ -548,12 +548,12 @@ if test x"$with_readline" != xno; then
>>  [with_readline_inc=$withval],
>>  [with_readline_inc="auto"])
>>  if test "x$with_readline_inc" = xauto; then
>> -AC_CHECK_HEADER(readline.h, [found="yes"], [
>> +AC_CHECK_HEADER(readline/readline.h, [found="yes"], [
>>  found="no"
>>  if test "$cross_compiling" != yes; then
> 
> From here it becomes irrelevant to cross building. The changed lines
> are not executed during a cross build.

They are still wrong/inconsistent: shell.c wants readline/readline.h,
while they looks for readline.h

>>  for dir in /usr /usr/local /usr/local/readline 
>> /usr/contrib /mingw; do
>> -for subdir in include include/readline; 
>> do
>> -
>> AC_CHECK_FILE($dir/$subdir/readline.h, found=yes)
>> +for subdir in include; do
>> +
>> AC_CHECK_FILE($dir/$subdir/readline/readline.h, found=yes)
>>  if test "$found" = "yes"; then
>>  
>> TARGET_READLINE_INC="-I$dir/$subdir"
>>  break
>>
> 
> Helmut
> 



Bug#849811: perfectly builds from source

2019-06-25 Thread Gürkan Myczko

Hi Dominik and Pabs,

It builds just fine for me,
fontmake -i -o otf -g Apropal.glyphs

Dominik: shall I add you to maintainers, or will you want to do it? 
(I've retitled it to ITP from RFP),

but if you insist it's yours.

Cheers,



Bug#931054: ITP: r-cran-cowplot -- GNU R streamlined plot theme and plot annotations for 'ggplot2'

2019-06-25 Thread Andreas Tille
Package: wnpp
Severity: wishlist

Subject: ITP: r-cran-cowplot -- GNU R streamlined plot theme and plot 
annotations for 'ggplot2'
Package: wnpp
Owner: Andreas Tille 
Severity: wishlist

* Package name: r-cran-cowplot
  Version : 0.9.4
  Upstream Author : Claus O. Wilke,
* URL : https://cran.r-project.org/package=cowplot
* License : GPL-2
  Programming Lang: GNU R
  Description : GNU R streamlined plot theme and plot annotations for 
'ggplot2'
 Some helpful extensions and modifications to the 'ggplot2'
 package. In particular, this package makes it easy to combine multiple
 'ggplot2' plots into one and label them with letters, e.g. A, B, C, etc.,
 as is often required for scientific publications. The package also provides
 a streamlined and clean theme that is used in the Wilke lab, hence the
 package name, which stands for Claus O. Wilke's plot package.

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-cran-cowplot



Bug#931044: CVE-2019-9740-CVE-2019-9947.diff

2019-06-25 Thread Olivier Bonvalet
Hi,

in the patch CVE-2019-9740-CVE-2019-9947.diff, the code use "formatted
string literals", which is a Python 3.6 feature.



Bug#931039: dh-strip-nondeterminism: Does not appear to clamp timestamps in PNG files (was: "Re: debhelper: something in the dh sequencer changes the tIME chunk of installed PNGs")

2019-06-25 Thread Chris Lamb
retitle 931039 dh-strip-nondeterminism: Does not appear to clamp timestamps in 
PNG files
thanks

Hi,

> While I’m sure the reproducible builds people appreciate
> limiting the mtime, raising it is not done otherwise.

Yes, it is curious why strip-nondeterminism is not "clamping" the
timestamps here, in other words only changing them to the changelog
date if they are newer than this time.

(Just as an aside, how come the tests fail? Are they looking
specifically for these timestamps or is it just that the files have
been changed at all?)


Best wishes,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-



Bug#930932: zenity: Zenity crashes out on Athlon XP CPU.

2019-06-25 Thread Alberto Garcia
On Tue, Jun 25, 2019 at 09:04:25AM +1000, Iris (Delta) wrote:

> If you do still intend to test any packages on Athlon XP era
> hardware I would be happy to help.

This is a test build of webkit2gtk 2.24.2-2 backported for stretch:

https://people.debian.org/~berto/webkit2gtk/

If you can test them on your system I'd appreciate it!

The SHA256 sums are signed by me.

Berto



Bug#931055: ITP: r-bioc-complexheatmap -- make complex heatmaps using GNU R

2019-06-25 Thread Andreas Tille
Package: wnpp
Severity: wishlist

Subject: ITP: r-bioc-complexheatmap -- make complex heatmaps using GNU R
Package: wnpp
Owner: Andreas Tille 
Severity: wishlist

* Package name: r-bioc-complexheatmap
  Version : 2.0.0
  Upstream Author : Zuguang Gu
* URL : https://bioconductor.org/packages/ComplexHeatmap/
* License : MIT
  Programming Lang: GNU R
  Description : make complex heatmaps using GNU R
 Complex heatmaps are efficient to visualize associations
 between different sources of data sets and reveal potential patterns.
 Here the ComplexHeatmap package provides a highly flexible way to arrange
 multiple heatmaps and supports various annotation graphics.

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-bioc-complexheatmap



Bug#928882: unblock: [pre-approval] ghc/8.4.4+dfsg1-3

2019-06-25 Thread Ilias Tsitsimpis
On Tue, Jun 25, 2019 at 09:24AM, Emanuele Olivetti wrote:
> I am very happy to announce that git-annex v.7.20190129-3+b1 for armel
> works perfectly on my QNAP TS-219P (armv5tel)!

Great news! Thank you for helping us out with this.

Best,

-- 
Ilias



Bug#931044: Quick workaround

2019-06-25 Thread jens persson
A quick workaround to get our old environments to work was to remove the
f:s on line 1014 and 1015 in /usr/lib/python3.4/http/client.py as:
raise InvalidURL("URL can't contain control characters. {url!r}
"
 "(found at least {match.group()!r})")

This will give bad error messages but allow things to work.

/jp

-- 
jens persson

Mäster Olofsväg 24
S-224 66 LUND;SWEDEN


Bug#928882: unblock: [pre-approval] ghc/8.4.4+dfsg1-3

2019-06-25 Thread Ilias Tsitsimpis
Hey Paul,

It looks like everything has been rebuilt without errors. Moreover,
git-annex now works, so I assume that the problem has been resolved.

Could you please unblock ghc/8.4.4+dfsg1-3 as well as every Haskell
package that was rebuilt on armel? One exception to the above is the
taffybar package, which has a newer version in unstable than in testing,
and was on my binNMU list by mistake. Thankfully, this is a leaf package
(no other Haskell libraries depend on it) so it is safe to first allow
all other packages to migrate to testing and then binNMU it directly on
testing.

Please let me know if there is anything else I can do to help.

Cheers,

-- 
Ilias



Bug#931056: debian-installer: keyboard setup skipped when using initrd preseeding

2019-06-25 Thread Christian Rudolph

Package: debian-installer
Version: 20190410
Severity: normal
Tags: d-i

Dear Maintainer,

when installing debian using initrd preseeding, keyboard setup gets
skipped completely.
After some debugging and code reading I found out that the root cause
is the /var/run/auto-install.active file, which doesn't get updated when
using plain initrd preseeding. The file-preseed.postinst and
network-preseed.postinst installation steps both update the file
correctly.

My additional boot options were auto=true and keymap=de. Manually adding
file=file:///preseed.cfg fixed this issue.

This behavior is unexpected, because preseeding succeeds successfully in
every other aspect.

Kind regards,

Christian

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

Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)

Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

-- no debconf information



Bug#905226: Acknowledgement (openssh-server: SSH AuthorizedKeysCommand hangs when output is too large)

2019-06-25 Thread Moritz Muehlenhoff
On Mon, Aug 06, 2018 at 12:04:46PM +0200, Dennis Schridde wrote:
> I confirm that the patch [1] to the upstream bug report [2] solves the issue 
> for us.

JFTR, we've also run into this at work at the Wikimedia Foundations's 
Phabricator
installation (https://phabricator.wikimedia.org/T224677) and can confirm
that the attached patch fixes it.

Colin, from my PoV this seems suitable for an update shipped in
a Stretch point release. I'd be happy to take care of an upload and
interacting with SRMs if you agree.

Cheers,
Moritz

diff -Naur openssh-7.4p1.orig/debian/patches/fix-deadlock-in-keys-principals-command.patch openssh-7.4p1/debian/patches/fix-deadlock-in-keys-principals-command.patch
--- openssh-7.4p1.orig/debian/patches/fix-deadlock-in-keys-principals-command.patch	1970-01-01 01:00:00.0 +0100
+++ openssh-7.4p1/debian/patches/fix-deadlock-in-keys-principals-command.patch	2019-06-25 11:04:11.723638028 +0200
@@ -0,0 +1,37 @@
+From ddd3d34e5c7979ca6f4a3a98a7d219a4ed3d98c2 Mon Sep 17 00:00:00 2001
+From: "d...@openbsd.org" 
+Date: Fri, 30 Dec 2016 22:08:02 +
+Subject: [PATCH] upstream commit
+
+fix deadlock when keys/principals command produces a lot of
+output and a key is matched early; bz#2655, patch from jboning AT gmail.com
+
+Upstream-ID: e19456429bf99087ea994432c16d00a642060afe
+---
+ auth2-pubkey.c | 8 +++-
+ 1 file changed, 7 insertions(+), 1 deletion(-)
+
+diff --git a/auth2-pubkey.c b/auth2-pubkey.c
+index 20f3309e1..70c021589 100644
+--- a/auth2-pubkey.c
 b/auth2-pubkey.c
+@@ -727,6 +727,9 @@ match_principals_command(struct passwd *user_pw, const struct sshkey *key)
+ 
+ 	ok = process_principals(f, NULL, pw, cert);
+ 
++	fclose(f);
++	f = NULL;
++
+ 	if (exited_cleanly(pid, "AuthorizedPrincipalsCommand", command) != 0)
+ 		goto out;
+ 
+@@ -1050,6 +1053,9 @@ user_key_command_allowed2(struct passwd *user_pw, Key *key)
+ 
+ 	ok = check_authkeys_file(f, options.authorized_keys_command, key, pw);
+ 
++	fclose(f);
++	f = NULL;
++
+ 	if (exited_cleanly(pid, "AuthorizedKeysCommand", command) != 0)
+ 		goto out;
+ 
diff -Naur openssh-7.4p1.orig/debian/patches/series openssh-7.4p1/debian/patches/series
--- openssh-7.4p1.orig/debian/patches/series	2019-03-01 17:19:28.0 +0100
+++ openssh-7.4p1/debian/patches/series	2019-06-25 11:06:56.429841721 +0200
@@ -44,3 +44,4 @@
 have-progressmeter-force-update-at-beginning-and-end-transfer.patch
 check-filenames-in-scp-client.patch
 scp-handle-braces.patch
+fix-deadlock-in-keys-principals-command.patch


Bug#930223: [Pkg-javascript-devel] need help with building node-dagre-d3-renderer with webpack

2019-06-25 Thread Pirate Praveen



Control: tag -1 help

On Tue, 25 Jun, 2019 at 1:49 PM, Pirate Praveen 
 wrote:
While looking for something else in package.json, I realized, there 
was a line excluding node_modules and there was two places I needed 
to update. With the following patch, webpack is successful.


Now there is another error (tried replacing commonjs2 with commonjs, 
also tried with nodejs 12),


  dh_auto_test --buildsystem=nodejs
/usr/bin/node -e require\(\".\"\)
/<>/dist/dagre-d3.core.js:950
function (node, name, id, index, group, timing) {
^

SyntaxError: Unexpected token (
   at new Script (vm.js:79:7)
   at createScript (vm.js:251:10)
   at Object.runInThisContext (vm.js:303:10)
   at Module._compile (internal/modules/cjs/loader.js:657:28)
   at Object.Module._extensions..js 
(internal/modules/cjs/loader.js:700:10)

   at Module.load (internal/modules/cjs/loader.js:599:32)
   at tryModuleLoad (internal/modules/cjs/loader.js:538:12)
   at Function.Module._load (internal/modules/cjs/loader.js:530:3)
   at Module.require (internal/modules/cjs/loader.js:637:17)
   at require (internal/modules/cjs/helpers.js:22:18)
dh_auto_test: /usr/bin/node -e require\(\".\"\) returned exit code 1



Bug#931039: dh-strip-nondeterminism: Does not appear to clamp timestamps in PNG files

2019-06-25 Thread Chris Lamb
forwarded 931039 
https://salsa.debian.org/reproducible-builds/strip-nondeterminism/issues/7
thanks

I've forwarded this upstream here:

  https://salsa.debian.org/reproducible-builds/strip-nondeterminism/issues/7


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-



Bug#930223: [Pkg-javascript-devel] need help with building node-dagre-d3-renderer with webpack

2019-06-25 Thread Pirate Praveen




On Tue, 25 Jun, 2019 at 3:07 PM, Pirate Praveen 
 wrote:
Now there is another error (tried replacing commonjs2 with commonjs, 
also tried with nodejs 12),


  dh_auto_test --buildsystem=nodejs
/usr/bin/node -e require\(\".\"\)
/<>/dist/dagre-d3.core.js:950
function (node, name, id, index, group, timing) {
^

SyntaxError: Unexpected token (
   at new Script (vm.js:79:7)
   at createScript (vm.js:251:10)
   at Object.runInThisContext (vm.js:303:10)
   at Module._compile (internal/modules/cjs/loader.js:657:28)
   at Object.Module._extensions..js 
(internal/modules/cjs/loader.js:700:10)

   at Module.load (internal/modules/cjs/loader.js:599:32)
   at tryModuleLoad (internal/modules/cjs/loader.js:538:12)
   at Function.Module._load (internal/modules/cjs/loader.js:530:3)
   at Module.require (internal/modules/cjs/loader.js:637:17)
   at require (internal/modules/cjs/helpers.js:22:18)
dh_auto_test: /usr/bin/node -e require\(\".\"\) returned exit code 1


Same error when changing package.json#main to dist/dagre-d3.js (umd 
format).




Bug#931044: Quick workaround

2019-06-25 Thread Peppo Brambilla
I fixed is as follows:

root@woody:/usr/lib/python3.4/http# diff -c3  client.py.orig client.py
*** client.py.orig  2019-06-21 03:20:41.0 +0200
--- client.py   2019-06-25 09:12:35.0 +0200
***
*** 1011,1018 
  # Prevent CVE-2019-9740.
  match = _contains_disallowed_url_pchar_re.search(url)
  if match:
! raise InvalidURL(f"URL can't contain control characters. {url!r} "
!  f"(found at least {match.group()!r})")
  request = '%s %s %s' % (method, url, self._http_vsn_str)
  
  # Non-ASCII characters should have been eliminated earlier
--- 1011,1018 
  # Prevent CVE-2019-9740.
  match = _contains_disallowed_url_pchar_re.search(url)
  if match:
! raise InvalidURL("URL can't contain control characters. {!r} 
".format(url) + 
!  "(found at least {!r})".format(match.group()))
  request = '%s %s %s' % (method, url, self._http_vsn_str)
  
  # Non-ASCII characters should have been eliminated earlier

Cheers -- Peppo

On Tue, 25 Jun 2019 11:09:28 +0200 jens persson  wrote:

> A quick workaround to get our old environments to work was to remove the
> f:s on line 1014 and 1015 in /usr/lib/python3.4/http/client.py as:
> raise InvalidURL("URL can't contain control characters. {url!r}
> "
> "(found at least {match.group()!r})")
>
> This will give bad error messages but allow things to work.
>
> /jp
>
> --
> jens persson
> 
> Mäster Olofsväg 24
> S-224 66 LUND;SWEDEN

-- 
Peppo Brambilla
Universitaet Bern, Institut fuer Informatik
Neubrueckstr. 10, CH-3012 Bern 
Tel +41 31 631 3310



Bug#930648: exim4-daemon-heavy: Weird leakage of unrelated data like /etc/aliases into /var/spool/exim4/input/*-H

2019-06-25 Thread Bjoern Buerger
* Andreas Metzler (ametz...@bebt.de) [190621 09:58]:
> On 2019-06-19 Bjoern Buerger  wrote:
> > * Andreas Metzler (ametz...@bebt.de) [190618 19:15]:
> [...] 
> > > Could you try
> > > a) disabling BDAT (set chunking_advertise_hosts = )
> > > b) try a backport of sa-exim 4.2.1-17?
> 
> > > See #879687.
> 
> > We could give it a try, but I don't see the point.
> 
> Did you test it yet?

We are testing it now. I wanted to check first, if this 
might be a onetime error. But yesterday it happened again. 

chunking_advertise_hosts is now disabled, 
sa-exim is 4.2.1-17. 

Now, we need to wait again. Last time it took ~7 days.

Bjørn

-- 
Pengutronix e.K.  | Bjørn Bürger|
Industrial Linux Solutions| https://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim | Phone: +49-5121-206917-5002 |
Amtsgericht Hildesheim, HRA 2686  | Fax:   +49-5121-206917- |



Bug#931057: python3: Error while upgrading python3.4

2019-06-25 Thread mediaf
Package: python3
Version: 3.4.2-2
Severity: normal

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

I have done apt update, apt ugrade and I received this message :

Paramétrage de python3.4 (3.4.2-1+deb8u3) ...
  File "/usr/lib/python3.4/http/client.py", line 1014
raise InvalidURL(f"URL can't contain control characters. {url!r} "
 ^
SyntaxError: invalid syntax
dpkg: erreur de traitement du paquet python3.4 (--configure) :
 le sous-processus script post-installation installé a retourné une erreur de
sortie d'état 1
dpkg: des problèmes de dépendances empêchent la configuration de python3 :
 python3 dépend de python3.4 (>= 3.4.2-0) ; cependant :
 Le paquet python3.4 n'est pas encore configuré.

dpkg: erreur de traitement du paquet python3 (--configure) :
 problèmes de dépendances - laissé non configuré
Des erreurs ont été rencontrées pendant l'exécution :
 python3.4
 python3



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

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

Versions of packages python3 depends on:
ii  dh-python  1.2014-2
ii  libpython3-stdlib  3.4.2-2
ii  python3-minimal3.4.2-2
ih  python3.4  3.4.2-1+deb8u3

python3 recommends no packages.

Versions of packages python3 suggests:
pn  python3-doc   
pn  python3-tk
pn  python3-venv  

-- no debconf information



Bug#930935: webkit2gtk: Baseline violation on i386

2019-06-25 Thread Adrian Bunk
On Tue, Jun 25, 2019 at 10:16:48AM +0200, Alberto Garcia wrote:
> On Mon, Jun 24, 2019 at 04:48:43PM +0300, Alberto Garcia wrote:
> 
> > If no one has anything to say I'll upload it today. This should work
> > on all i386 CPUs, and we can later discuss if it's worth thinking of
> > a solution for SSE2-capable machines.
> 
> Uploaded, unblock request at #931052
> 
> I don't have an Athlon XP myself but I can reproduce the bug (and
> verify that the fix works) emulating a Pentium 3 with QEMU.

Thanks a lot!

> Berto

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed



Bug#931058: linux: enable CONFIG_USB_DUMMY_HCD=m for simulating USB UDCs for USB gadgets

2019-06-25 Thread Paul Wise
Package: src:linux
Severity: wishlist

I would like the CONFIG_USB_DUMMY_HCD=m option to be enabled, so that I
can experiment with USB gadgets on x86 desktop systems where a USB UDC
is not available. The other gadget-related config options are already
enabled in the Debian version of the Linux kernel. More info about
using dummy-hcd for experimenting with USB gadgets here:

https://www.collabora.com/news-and-blog/blog/2019/06/24/using-dummy-hcd/

-- 
bye,
pabs

https://wiki.debian.org/PaulWise



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


Bug#931060: ionit.service creates a systemd dependency loop

2019-06-25 Thread Benjamin Drung
Package: ionit
Version: 0.3.2+really0.2.1-1
Severity: serious
Tags: patch upstream

Letting ionit.service run before systemd-udev-trigger.service (fix for
Deiban bug #919690) introduces a dependency loop:

systemd[1]: systemd-udev-trigger.service: Found ordering cycle on
ionit.service/start
systemd[1]: systemd-udev-trigger.service: Found dependency on
local-fs.target/start
systemd[1]: systemd-udev-trigger.service: Found dependency on
local-fs-pre.target/start
systemd[1]: systemd-udev-trigger.service: Found dependency on
multipathd.service/start

systemd will break the loop where the dependency is required for correct
booting.

-- 
Benjamin Drung
System Developer
Debian & Ubuntu Developer

1&1 IONOS Cloud GmbH | Greifswalder Str. 207 | 10405 Berlin | Germany
E-mail: benjamin.dr...@cloud.ionos.com | Web: www.ionos.de

Head Office: Berlin, Germany
District Court Berlin Charlottenburg, Registration number: HRB 125506 B
Executive Management: Christoph Steffens, Matthias Steinberg, Achim
Weiss

Member of United Internet



Bug#930484: e2fsck corrupts sparse files with -E bmap2extent

2019-06-25 Thread Florian Zumbiehl
Hi,

[...]
> In my mind, this is why Debian Backports exists.  If you want the
> latest bug fixes (including one whhich avoids data corruption when
> doing off-line shrinks using resize2fs), and/or you are doing anything
> at all exotic, my only recommendation is to use the Debian Backports
> version of e2fsprogs.

Well, the big problem with that argument is that it presumes people know
what's exotic? The man page doesn't say it's exotic. The program doesn't
warn you that what you are doing is exotic. The only person who kinda knows
what's exotic is you. But you don't do what would be necessary to make
users aware of it. Plus, I don't even see how you would really know, given
that there probably is no telemetry in e2fsck.

Now that I had noticed by pure luck that a file had been corrupted during a
recent conversion, I went back and found files that were corrupted during
conversions that I did four years ago. Now, that was before you were aware
of the bug, so nothing you could have done to prevent that, but it shows
how long the damage caused by this bug can stay undiscovered/how difficult
it is for you to have an accurate view of the impact of this bug.

> Bottom line, for *this* particular bug (as opposed to the various
> resize2fs shrink fixes) preparing an update to 1.43.4-2 is pretty
> simple.

Now, I don't know any details about this other bug, but simply bailing out
in the risky case presumably shouldn't be that difficult either?! I mean, I
can see why you wouldn't want to spend lots of time porting fixes to old
versions that they don't readily apply on, and I wouldn't really see any
value in that anyway. But preventing damage does not require porting the
fix, bailing out does the job as well?!

>  And if I had any optimism that the Release Team would be
> willing to take a very late update to Debian Stretch at the point when
> it's just about become oldstable, I might even be willing to do the
> upload.  But it's not something where I'm feeling particularly
> motivated to convince the release team that this is a change they
> should be taking, and respinning the Stretch installer at this point.

That reads more like you think the bug actually should be fixed, but the
Release Team is likely to create tons of unnecessary work, and possibly
preventing it anyway, that you don't feel like wasting your time with that?

What is the problem with respinning the installer? That sounds like
something that should be automated?! But also, fixing this only in the
non-installer package sure would be better than nothing, if fixing the
installer is a big problem.

Regards, Florian



Bug#931062: unblock: ionit/0.3.2+really0.2.1-2

2019-06-25 Thread Benjamin Drung
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package ionit

The ionit.service fix for bug #919690 introduced a systemd dependency
loop. systemd will break the loop at a (random?) place which can make
boot behave incorrectly.

I fixed the dependency loop in ionit 0.3.2+really0.2.1-2. A debdiff is
attached.

unblock ionit/0.3.2+really0.2.1-2

-- 
Benjamin Drung
System Developer
Debian & Ubuntu Developer

1&1 IONOS Cloud GmbH | Greifswalder Str. 207 | 10405 Berlin | Germany
E-mail: benjamin.dr...@cloud.ionos.com | Web: www.ionos.de

Head Office: Berlin, Germany
District Court Berlin Charlottenburg, Registration number: HRB 125506 B
Executive Management: Christoph Steffens, Matthias Steinberg, Achim
Weiss

Member of United Internet
diff -Nru ionit-0.3.2+really0.2.1/debian/changelog 
ionit-0.3.2+really0.2.1/debian/changelog
--- ionit-0.3.2+really0.2.1/debian/changelog2019-06-20 15:36:08.0 
+0200
+++ ionit-0.3.2+really0.2.1/debian/changelog2019-06-25 13:18:08.0 
+0200
@@ -1,3 +1,10 @@
+ionit (0.3.2+really0.2.1-2) unstable; urgency=medium
+
+  * Drop After=local-fs.target from ionit.service to break dependency loop
+(Closes: #931060)
+
+ -- Benjamin Drung   Tue, 25 Jun 2019 13:18:08 
+0200
+
 ionit (0.3.2+really0.2.1-1) unstable; urgency=medium
 
   * Run ionit.service before systemd-modules-load.service
diff -Nru 
ionit-0.3.2+really0.2.1/debian/patches/Drop-After-local-fs.target-from-ionit.service.patch
 
ionit-0.3.2+really0.2.1/debian/patches/Drop-After-local-fs.target-from-ionit.service.patch
--- 
ionit-0.3.2+really0.2.1/debian/patches/Drop-After-local-fs.target-from-ionit.service.patch
  1970-01-01 01:00:00.0 +0100
+++ 
ionit-0.3.2+really0.2.1/debian/patches/Drop-After-local-fs.target-from-ionit.service.patch
  2019-06-25 13:16:16.0 +0200
@@ -0,0 +1,45 @@
+From ce7c305312bb68319784e2d693955297138c273a Mon Sep 17 00:00:00 2001
+From: Benjamin Drung 
+Date: Tue, 25 Jun 2019 12:00:24 +0200
+Subject: [PATCH] Drop After=local-fs.target from ionit.service
+
+Letting `ionit.service` run before `systemd-udev-trigger.service`
+introduces a dependency loop:
+
+```
+systemd[1]: systemd-udev-trigger.service: Found ordering cycle on 
ionit.service/start
+systemd[1]: systemd-udev-trigger.service: Found dependency on 
local-fs.target/start
+systemd[1]: systemd-udev-trigger.service: Found dependency on 
local-fs-pre.target/start
+systemd[1]: systemd-udev-trigger.service: Found dependency on 
multipathd.service/start
+```
+
+`systemd-udev-trigger.service` runs before `multipathd.service` which
+runs before `local-fs-pre.target` which runs before `local-fs.target`.
+`ionit.service` wants to run before `systemd-udev-trigger.service` but
+after `local-fs.target`.
+
+Therefore drop `After=local-fs.target` from `ionit.service` to break the
+dependency loop. `/etc` and `/usr` is probably mounted inside the initrd
+already.
+
+Bug-Debian: https://bugs.debian.org/931060
+Signed-off-by: Benjamin Drung 
+---
+ ionit.service | 1 -
+ 1 file changed, 1 deletion(-)
+
+diff --git a/ionit.service b/ionit.service
+index 8f56106..4c4e1c8 100644
+--- a/ionit.service
 b/ionit.service
+@@ -2,7 +2,6 @@
+ Description=Render configuration files from Jinja templates
+ Documentation=man:ionit(1)
+ DefaultDependencies=no
+-After=local-fs.target
+ Before=ferm.service network-pre.target openibd.service shutdown.target 
sysinit.target systemd-modules-load.service systemd-udev-trigger.service
+ Wants=network-pre.target
+ RequiresMountsFor=/usr
+-- 
+2.20.1
+
diff -Nru ionit-0.3.2+really0.2.1/debian/patches/series 
ionit-0.3.2+really0.2.1/debian/patches/series
--- ionit-0.3.2+really0.2.1/debian/patches/series   2019-06-20 
13:54:04.0 +0200
+++ ionit-0.3.2+really0.2.1/debian/patches/series   2019-06-25 
13:16:39.0 +0200
@@ -1,2 +1,3 @@
 Run-ionit.service-before-systemd-modules-load.service.patch
 Run-ionit.service-before-systemd-udev-trigger.service.patch
+Drop-After-local-fs.target-from-ionit.service.patch


Bug#931061: crossbuild-essential-ARCH shouldn't depend on all

2019-06-25 Thread Evgeny Golyshev
Source: build-essential
Version: 12.6
Severity: wishlist
Tags: patch

The following packages
* crossbuild-essential-amd64
* crossbuild-essential-armel
* crossbuild-essential-arm64
* crossbuild-essential-armhf
* crossbuild-essential-i386
* crossbuild-essential-mips
* crossbuild-essential-mipsel
* crossbuild-essential-mips64el
* crossbuild-essential-powerpc
* crossbuild-essential-ppc64el
* crossbuild-essential-s390x

should depend on all architectures _except_ its own one. For example,
crossbuild-essential-arm64 should depend on amd64, armel, armhf, i386,
mips, mipsel, mips64el, powerpc, ppc64el, s390x but _not_ on arm64.
Otherwise, the package will be available for the arm64 architecture
but installing of the package will lead to

The following packages have unmet dependencies:
 crossbuild-essential-arm64 : Depends: gcc-aarch64-linux-gnu (>= 7.2)
but it is not installable
  Depends: g++-aarch64-linux-gnu (>= 7.2)
but it is not installable
E: Unable to correct problems, you have held broken packages.

I'm attaching the patch which solves the problem.

--
Evgeny Golyshev
--- a/debian/control	2019-03-01 15:05:10.0 +0300
+++ b/debian/control	2019-06-25 13:16:43.794744574 +0300
@@ -51,7 +51,7 @@
  package depends on.
 
 Package: crossbuild-essential-arm64
-Architecture: all
+Architecture: amd64 armel armhf i386 mips mipsel mips64el powerpc ppc64el s390x
 Depends: ${cross-essential}, ${misc:Depends}
 Description: Informational list of cross-build-essential packages
  If you do not plan to cross build Debian packages, you don't need
@@ -70,7 +70,7 @@
  package depends on.
 
 Package: crossbuild-essential-armel
-Architecture: all
+Architecture: amd64 arm64 armhf i386 mips mipsel mips64el powerpc ppc64el s390x
 Depends: ${cross-essential}, ${misc:Depends}
 Description: Informational list of cross-build-essential packages
  If you do not plan to cross build Debian packages, you don't need
@@ -89,7 +89,7 @@
  package depends on.
 
 Package: crossbuild-essential-armhf
-Architecture: all
+Architecture: amd64 arm64 armel i386 mips mipsel mips64el powerpc ppc64el s390x
 Depends: ${cross-essential}, ${misc:Depends}
 Description: Informational list of cross-build-essential packages
  If you do not plan to cross build Debian packages, you don't need
@@ -108,7 +108,7 @@
  package depends on.
 
 Package: crossbuild-essential-i386
-Architecture: all
+Architecture: amd64 arm64 armel armhf mips mipsel mips64el powerpc ppc64el s390x
 Depends: ${cross-essential}, ${misc:Depends}
 Description: Informational list of cross-build-essential packages
  If you do not plan to cross build Debian packages, you don't need
@@ -127,7 +127,7 @@
  package depends on.
 
 Package: crossbuild-essential-mips
-Architecture: all
+Architecture: amd64 arm64 armel armhf i386 mipsel mips64el powerpc ppc64el s390x
 Depends: ${cross-essential}, ${misc:Depends}
 Description: Informational list of cross-build-essential packages
  If you do not plan to cross build Debian packages, you don't need
@@ -146,7 +146,7 @@
  package depends on.
 
 Package: crossbuild-essential-mipsel
-Architecture: all
+Architecture: amd64 arm64 armel armhf i386 mips mips64el powerpc ppc64el s390x
 Depends: ${cross-essential}, ${misc:Depends}
 Description: Informational list of cross-build-essential packages
  If you do not plan to cross build Debian packages, you don't need
@@ -165,7 +165,7 @@
  package depends on.
 
 Package: crossbuild-essential-mips64el
-Architecture: all
+Architecture: amd64 arm64 armel armhf i386 mips mipsel powerpc ppc64el s390x
 Depends: ${cross-essential}, ${misc:Depends}
 Description: Informational list of cross-build-essential packages
  If you do not plan to cross build Debian packages, you don't need
@@ -184,7 +184,7 @@
  package depends on.
 
 Package: crossbuild-essential-powerpc
-Architecture: all
+Architecture: amd64 arm64 armel armhf i386 mips mipsel mips64el ppc64el s390x
 Depends: ${cross-essential}, ${misc:Depends}
 Description: Informational list of cross-build-essential packages
  If you do not plan to cross build Debian packages, you don't need
@@ -203,7 +203,7 @@
  package depends on.
 
 Package: crossbuild-essential-ppc64el
-Architecture: all
+Architecture: amd64 arm64 armel armhf i386 mips mipsel mips64el powerpc s390x
 Depends: ${cross-essential}, ${misc:Depends}
 Description: Informational list of cross-build-essential packages
  If you do not plan to cross build Debian packages, you don't need
@@ -222,7 +222,7 @@
  package depends on.
 
 Package: crossbuild-essential-s390x
-Architecture: all
+Architecture: amd64 arm64 armel armhf i386 mips mipsel mips64el powerpc ppc64el
 Depends: ${cross-essential}, ${misc:Depends}
 Description: Informational list of cross-build-essential packages
  If you do not plan to cross build Debian packages, you don't need


Bug#931063: dpkg: error processing package python3.4 (--configure):

2019-06-25 Thread Larry Kraemer
Package: upgrade-reports
Severity: important

Dear Maintainer,

I executed the following this morning:
sudo apt-get update
sudo apt-get upgrade

and I got these error statements:
Setting up python3.4 (3.4.2-1+deb8u3) ...
  File "/usr/lib/python3.4/http/client.py", line 1014
raise InvalidURL(f"URL can't contain control characters. {url!r} "
..^
SyntaxError: invalid syntax
dpkg: error processing package python3.4 (--configure);
 subprocess installed post-installation script returned error exit status 1



-- System Information:
Debian Release: 8.11
  APT prefers oldstable-updates
  APT policy: (500, 'oldstable-updates'), (500, 'oldstable')
Architecture: i386 (i686)

Kernel: Linux 3.16.0-8-686-pae (SMP w/2 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)



Bug#930223: [Pkg-javascript-devel] need help with building node-dagre-d3-renderer with webpack

2019-06-25 Thread Pirate Praveen




On Tue, 25 Jun, 2019 at 3:13 PM, Pirate Praveen 
 wrote:
Same error when changing package.json#main to dist/dagre-d3.js (umd 
format).


To confirm it is not a browser only library, I downloaded the 
dagre-d3-renderer dist.tarball from npmjs.com and the require command 
succeeds there.




Bug#930998: RM: ompl/1.4.2+ds1-3

2019-06-25 Thread Leopold Palomo-Avellaneda
Just some clarifications:


As Jochen said:

> Reason: The package in testing is RC buggy with #930507. Leo pushed a
> new -3 revision over a week ago to unstable but expressed in

> https://lists.debian.org/debian-release/2019/06/msg00526.html
> 
> that he is not 'very happy with the patches'. 

he missed the final sentence ... but "they are valid". When I was saying that I
was not happy I asked three possible options and I didn't receive any answer. I
just create another set of patch different from upstream to solve the same and I
don't think that it was a good idea (not follow Upstream solving the same). And
the most formal solution should be to use the Depends field of pkg-config.

The bug mentioned the dependencies of the pkgfile about the includes and that
was solved. The problem has been that I introduce a more strong dependency
(libode-dev)

After discussing the state
> in #debian-release today, I had a look at the -3 version and tested it
> using
> 
> http://ompl.kavrakilab.org/RigidBodyPlanningWithIntegrationAndControls_8cpp_source.html
> 
> and
> 
> g++ $(pkg-config --cflags --libs ompl) -o 
> RigidBodyPlanningWithIntegrationAndControls 
> RigidBodyPlanningWithIntegrationAndControls.cpp
> 
> I found that that libompl-dev was still missing dependencies, i.e.
> libode-dev and boost.

boost is added, Jochen do it. But libode no. I just solved the pkg issue but I
didn't pay attention that that changed brought the libode-dev. You only need
libode if you use one extension. For instance, the example that Jochen mentioned
generate:

 g++ -I/usr/include/eigen3 -lompl /usr/lib/x86_64-linux-gnu/libode.so
/usr/lib/x86_64-linux-gnu/libboost_serialization.so
/usr/lib/x86_64-linux-gnu/libboost_filesystem.so
/usr/lib/x86_64-linux-gnu/libboost_system.so -lpthread -o
RigidBodyPlanningWithIntegrationAndControls
RigidBodyPlanningWithIntegrationAndControls.cpp

if I drop the ode part (/usr/lib/x86_64-linux-gnu/libode.so) the program
compiles and links perfectly, and runs. If I uninstall libode-dev the program
works (and builds without the libode.so). Only needs libode-dev because
pkg-config add that flag. And it added because if you use the ode extension in
theory you need to link against it, but it's not clear to me. libompl is linked
against ode because that extension, but if you don't use any ode symbols I think
that you don't need to link against it.

> Given that the deadline for change in buster passed and the package would need
> more review to get fixed, I propose to drop it from the buster release.

It's a pity and a sad thing to me. I have been working with this package and
tried to keep it in a good shape and now because a last time bug, bad resolved
and with a simple solution (change Suggest to depends of libode-dev) it's out of
buster.

I have pushed a new version replacing my patches with an adaptation of upstream
patches to solve the problem from here:

https://bitbucket.org/ompl/ompl/commits/e3855102b037643a9625ff6694bb2f559eecb411

Here my patches:

https://salsa.debian.org/science-team/ompl/blob/master/debian/patches/0002-Patch-from-upstream-to-add-include-dirs.patch

https://salsa.debian.org/science-team/ompl/blob/master/debian/patches/0003-Patch-from-upstream-to-add-include-dirs-to-pkg-confi.patch

https://salsa.debian.org/science-team/ompl/blob/master/debian/patches/0004-Patch-from-upstream-to-add-include-dirs-to-pkg-confi.patch


Leopold


-- 
--
Linux User 152692 GPG: 05F4A7A949A2D9AA
Catalonia
-
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?



Bug#931063: dpkg: error processing package python3.4 (--configure):

2019-06-25 Thread Bas Couwenberg

Should be fixed soon, see the thread on the lts list:

 https://lists.debian.org/debian-lts/2019/06/msg00025.html

Kind Regards,

Bas



Bug#931064: unblock: grub2/2.02+dfsg1-20

2019-06-25 Thread Steve McIntyre
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package grub2

While testing the Buster d-i RC2 build yesterday, I realised that we
hadn't *quite* finished all the packaging changes for Secure Boot. At
the moment, only the signed grub packages on amd64 Recommend:
shim-signed, but we also want that for i386 and arm64 too, as this
Recommend: is what causes shim-signed etc. to be pulled in at
installation time.

At the point when we first did this signing-template work, we didn't
*have* a shim-signed package on the other arches, so it didn't make
sense at the time.

I've made a tiny 1-line patch to just the signing-template and
uploaded. Ansgar says he'll prod the signing queue tonight to make the
-signed packages appear then.

Here's the trivial debdiff, excluding some noise in .bzrignore and
.gitignore files:

diff -Nru --exclude '.*ignore' grub2-2.02+dfsg1/debian/changelog 
grub2-2.02+dfsg1/debian/changelog
--- grub2-2.02+dfsg1/debian/changelog   2019-06-14 19:04:01.0 +0100
+++ grub2-2.02+dfsg1/debian/changelog   2019-06-25 10:11:12.0 +0100
@@ -1,3 +1,13 @@
+grub2 (2.02+dfsg1-20) unstable; urgency=medium
+
+  [ Steve McIntyre ]
+  * Make all the signed EFI arches have a Recommends: from
+grub-efi-ARCH-signed to shim-signed, not just amd64.
+Closes: #931038
+  * Add myself to Uploaders
+
+ -- Steve McIntyre <93...@debian.org>  Tue, 25 Jun 2019 10:11:12 +0100
+
 grub2 (2.02+dfsg1-19) unstable; urgency=medium
 
   [ Colin Watson ]
diff -Nru --exclude '.*ignore' grub2-2.02+dfsg1/debian/control 
grub2-2.02+dfsg1/debian/control
--- grub2-2.02+dfsg1/debian/control 2019-06-14 19:04:01.0 +0100
+++ grub2-2.02+dfsg1/debian/control 2019-06-25 10:09:06.0 +0100
@@ -2,7 +2,7 @@
 Section: admin
 Priority: optional
 Maintainer: GRUB Maintainers 
-Uploaders: Felix Zielcke , Jordi Mallach , 
Colin Watson , Ian Campbell 
+Uploaders: Felix Zielcke , Jordi Mallach , 
Colin Watson , Ian Campbell , Steve 
McIntyre <93...@debian.org>
 Build-Depends: debhelper (>= 10~),
  patchutils,
  python,
diff -Nru --exclude '.*ignore' 
grub2-2.02+dfsg1/debian/signing-template/control.in 
grub2-2.02+dfsg1/debian/signing-template/control.in
--- grub2-2.02+dfsg1/debian/signing-template/control.in 2019-06-14 
19:04:01.0 +0100
+++ grub2-2.02+dfsg1/debian/signing-template/control.in 2019-06-25 
10:08:26.0 +0100
@@ -12,7 +12,7 @@
 Package: @pkg_signed@
 Architecture: @arch@
 Depends: grub-common (= @version_binary@)
-Recommends: shim-signed [amd64]
+Recommends: shim-signed
 Built-Using: grub2 (= @version_binary@)
 Description: GRand Unified Bootloader, version 2 (@arch@ UEFI signed by Debian)
  GRUB is a portable, powerful bootloader.  This version of GRUB is based on a


unblock grub2/2.02+dfsg1-20
unblock grub-efi-amd64-signed/1+2.02+dfsg1+20
unblock grub-efi-arm64-signed/1+2.02+dfsg1+20
unblock grub-efi-ia32-signed/1+2.02+dfsg1+20

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

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



Bug#870814: show message if unable to play video

2019-06-25 Thread Alberto Garcia
On Fri, Aug 25, 2017 at 10:21:36PM +0800, 積丹尼 Dan Jacobson wrote:

> OK I installed all the packages libwebkit2gtk-4.0-37 suggests, and
> recommends, and can finally play the video. (But with no sound...).
> 
> Anyway, most browsers say "plugin cannot be used" instead of the
> black screen we discussed.

I cannot reproduce the original problem anymore, does it still happen
to you?

Berto



Bug#931017: dkms: "install" loads modules immediately, and loads more than the newly installed modules

2019-06-25 Thread Raphael Hertzog
Control: forwarded -1 https://github.com/dell/dkms/issues/85

On Mon, 24 Jun 2019, Raphaël Hertzog wrote:
> The reason is that "dkms install" runs this:
> find /sys/devices -name modalias -print0 | xargs -0 cat | xargs modprobe -a 
> -b -q

This was added in this commit:
https://github.com/dell/dkms/commit/f5bfb12fef1fc06e56355cdba500eaa98d4e6aa8

The rationale given there does not apply at all to Debian where
the modules are built/installed as soon as the DKMS package is installed
and not only on next reboot...

So we can likely just patch this out until upstream provides a way
to disable this code.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/



Bug#931044: installing python3.4 fails

2019-06-25 Thread Paul Boddie
Package: python3.4
Version: 3.4.2-1+deb8u3
Followup-For: Bug #931044

The following fix could be applied to the faulty Python standard library file
ultimately used by the /var/lib/dpkg/info/python3.4.postinst script:

--- /usr/lib/python3.4/http/client.py   2019-06-25 14:41:35.0 +0200
+++ /usr/lib/python3.4/http/client.py   2019-06-25 14:41:55.0 +0200
@@ -1011,8 +1011,9 @@
 # Prevent CVE-2019-9740.
 match = _contains_disallowed_url_pchar_re.search(url)
 if match:
-raise InvalidURL(f"URL can't contain control characters. {url!r} "
- f"(found at least {match.group()!r})")
+raise InvalidURL("URL can't contain control characters. {url!r} "
+ "(found at least {group!r})"
+ .format(url=url, group=match.group()))
 request = '%s %s %s' % (method, url, self._http_vsn_str)

 # Non-ASCII characters should have been eliminated earlier

Sorry to provide this patch inline, but I am using the textual bug reporting
interface! I imagine that this regression has occurred because someone has
applied the noted vulnerability countermeasure without backporting it to the
syntax understood by Python 3.5 or earlier.

I hope this helps others experiencing the same problem.

Paul

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

Kernel: Linux 3.16.0-9-586
Locale: LANG=en_GB.ISO-8859-15, LC_CTYPE=en_GB.ISO-8859-15 (charmap=ISO-8859-15)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages python3.4 depends on:
ii  libpython3.4-stdlib  3.4.2-1+deb8u3
ii  mime-support 3.58
ii  python3.4-minimal3.4.2-1+deb8u3

python3.4 recommends no packages.

Versions of packages python3.4 suggests:
ii  binutils2.25-5+deb8u1
pn  python3.4-doc   
pn  python3.4-venv  

-- no debconf information



Bug#852032: libjavascriptcoregtk-4.0-18: Segmentation fault in LLIntAssembly.h:2610 on powerpc64

2019-06-25 Thread Alberto Garcia
On Mon, Jan 23, 2017 at 11:14:16AM +0100, Alberto Garcia wrote:
> webkit2gtk itself builds fine, seed-webkit2 is what fails:

I wanted to test this with the latest versions of WebKitGTK, but I
don't seem to have access to any porterbox with ppc64 (only ppc64el,
in which things work fine).

Is this still a thing? Do we still care about ppc64? I'll close the
bug otherwise.

Berto



Bug#931065: ITP: r-bioc-all -- Bioconductor data package used by several bioc tools

2019-06-25 Thread Andreas Tille
Package: wnpp
Severity: wishlist

Subject: ITP: r-bioc-all -- Bioconductor data package used by several bioc tools
Package: wnpp
Owner: Andreas Tille 
Severity: wishlist

* Package name: r-bioc-all
  Version : 1.26.0
  Upstream Author : Xiaochun Li
* URL : https://bioconductor.org/packages/data/experiment/ALL/
* License : Artistic-2.0
  Programming Lang: GNU R
  Description : Bioconductor data package used by several bioc tools
 Data of T- and B-cell Acute Lymphocytic Leukemia from the Ritz
 Laboratory at the DFCI (includes Apr 2004 versions)

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-bioc-all



Bug#716467: Fix available

2019-06-25 Thread Jeremy Sowden
The crash was the result of passing a null pointer to strlen when
allocating memory for the PID file:

/* we can theoretically live without a config file */
home = getenv("HOME");
if (home) {
config.file = calloc(1, strlen(home) + 9);
sprintf(config.file, "%s/.wmixrc", home);
}

/* handle writing PID file, silently ignore if we can't do it */
pid = calloc(1, strlen(home) + 10);
sprintf(pid, "%s/.wmix.pid", home);
fp = fopen(pid, "w");
if (fp) {
fprintf(fp, "%d\n", getpid());
fclose(fp);
}
free(pid);

This was fixed in a later release, 3.3, which has since packaged and
uploaded to the archive:

  $ apt-cache policy wmix
  wmix:
Installed: 3.3-1
Candidate: 3.3-1
Version table:
   *** 3.3-1 990
  990 http://mirror.ox.ac.uk/debian testing/main amd64 Packages
  990 http://ftp.uk.debian.org/debian testing/main amd64 Packages
  990 http://ftp.debian.org/debian testing/main amd64 Packages
   99 http://mirror.ox.ac.uk/debian unstable/main amd64 Packages
   99 http://ftp.uk.debian.org/debian unstable/main amd64 Packages
   99 http://ftp.debian.org/debian unstable/main amd64 Packages
  100 /var/lib/dpkg/status
   3.1-5.1 900
  900 http://mirror.ox.ac.uk/debian stable/main amd64 Packages
  900 http://ftp.uk.debian.org/debian stable/main amd64 Packages
  900 http://ftp.debian.org/debian stable/main amd64 Packages

J.


signature.asc
Description: PGP signature


Bug#931066: xserver-xorg-core: X crash - libfb

2019-06-25 Thread MaXaMaR
Package: server-xorg-core
Version: 2:1.20.4-1
Severity: grave

Hello I have a similar to 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911680 
 bug I think, also in 
VM which is KVM (Proxmox) with AMD RX590 PCI passthru.
Happens on latest sid & experimental 5.0 kernels, also in latest Ubuntu 19.04 & 
19.10.
Previously it worked ok in ESXI, Xen with Ubuntu.
It works in KVM Windows 10.

Or is it amdgpu bug?

Thanks.

root@dev:/var/log# cat Xorg.0.log
[   131.766]
X.Org  X Server 1.20.4
X Protocol Version 11, Revision 0
[   131.766] Build Operating System: Linux 4.9.0-8-amd64 x86_64 Debian
[   131.766] Current Operating System: Linux dev 5.0.0-trunk-amd64 #1 SMP 
Debian 5.0.2-1~exp1 (2019-03-18) x86_64
[   131.766] Kernel command line: BOOT_IMAGE=/vmlinuz-5.0.0-trunk-amd64 
root=UUID=e4607c3b-74e7-45bf-be63-5cc5d816194d ro quiet
[   131.766] Build Date: 05 March 2019  08:11:12PM
[   131.766] xorg-server 2:1.20.4-1 (https://www.debian.org/support 
)
[   131.766] Current version of pixman: 0.36.0
[   131.766]Before reporting problems, check http://wiki.x.org 

to make sure that you have the latest version.
[   131.766] Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[   131.767] (==) Log file: "/var/log/Xorg.0.log", Time: Tue Jun 25 13:48:04 
2019
[   131.767] (++) Using config file: "/root/xorg.conf.new"
[   131.767] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[   131.767] (==) ServerLayout "X.org  Configured"
[   131.767] (**) |-->Screen "Screen0" (0)
[   131.767] (**) |   |-->Monitor "Monitor0"
[   131.768] (**) |   |-->Device "Card0"
[   131.768] (**) |-->Screen "Screen1" (1)
[   131.768] (**) |   |-->Monitor "Monitor1"
[   131.768] (**) |   |-->Device "Card1"
[   131.768] (**) |-->Screen "Screen2" (2)
[   131.768] (**) |   |-->Monitor "Monitor2"
[   131.768] (**) |   |-->Device "Card2"
[   131.768] (**) |-->Input Device "Mouse0"
[   131.768] (**) |-->Input Device "Keyboard0"
[   131.768] (==) Automatically adding devices
[   131.768] (==) Automatically enabling devices
[   131.768] (==) Automatically adding GPU devices
[   131.768] (==) Max clients allowed: 256, resource mask: 0x1f
[   131.768] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist.
[   131.768]Entry deleted from font path.
[   131.768] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist.
[   131.768]Entry deleted from font path.
[   131.768] (**) FontPath set to:
/usr/share/fonts/X11/misc,
/usr/share/fonts/X11/100dpi/:unscaled,
/usr/share/fonts/X11/75dpi/:unscaled,
/usr/share/fonts/X11/Type1,
/usr/share/fonts/X11/100dpi,
/usr/share/fonts/X11/75dpi,
built-ins,
/usr/share/fonts/X11/misc,
/usr/share/fonts/X11/100dpi/:unscaled,
/usr/share/fonts/X11/75dpi/:unscaled,
/usr/share/fonts/X11/Type1,
/usr/share/fonts/X11/100dpi,
/usr/share/fonts/X11/75dpi,
built-ins
[   131.768] (**) ModulePath set to "/usr/lib/xorg/modules"
[   131.768] (WW) Hotplugging is on, devices using drivers 'kbd', 'mouse' or 
'vmmouse' will be disabled.
[   131.768] (WW) Disabling Mouse0
[   131.768] (WW) Disabling Keyboard0
[   131.768] (II) Loader magic: 0x55f57d015e20
[   131.769] (II) Module ABI versions:
[   131.769]X.Org  ANSI C Emulation: 0.4
[   131.769]X.Org  Video Driver: 24.0
[   131.769]X.Org  XInput driver : 24.1
[   131.769]X.Org  Server Extension : 10.0
[   131.769] (--) using VT number 3

[   131.769] (II) systemd-logind: logind integration requires -keeptty and 
-keeptty was not provided, disabling logind integration
[   131.771] (II) xfree86: Adding drm device (/dev/dri/card0)
[   131.771] (II) xfree86: Adding drm device (/dev/dri/card1)
[   131.799] (--) PCI:*(0@0:1:0) 1234::1af4:1100 rev 2, Mem @ 
0xf000/16777216, 0xfea14000/4096, BIOS @ 0x/131072
[   131.799] (--) PCI: (1@0:0:0) 1002:67df:1da2:e366 rev 225, Mem @ 
0x6/8589934592, 0x8/2097152, 0xfe80/262144, I/O @ 
0x5000/256, BIOS @ 0x/131072
[   131.799] (II) "glx" will be loaded. This was enabled by default and also 
specified in the config file.
[   131.799] (II) LoadModule: "glx"
[   131.799] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so
[   131.801] (II) Module glx: vendor="X.Org  Foundation"
[   131.801]compiled for 1.20.4, module version = 1.0.0
[   131.801]ABI class: X.Org  Server Extension, version 10.0
[   131.801] (II) LoadModule: "amdgpu"
[   131.801] (II) Loading /usr/lib/xorg/modules/drivers/amdgpu_drv.so
[   131.801] (II) Module amdgpu: vendor="X.Org

Bug#931067: ITP: r-bioc-consensusclusterplus -- GNU R determining cluster count and membership

2019-06-25 Thread Andreas Tille
Package: wnpp
Severity: wishlist

Subject: ITP: r-bioc-consensusclusterplus -- GNU R determining cluster count 
and membership
Package: wnpp
Owner: Andreas Tille 
Severity: wishlist

* Package name: r-bioc-consensusclusterplus
  Version : 1.48.0
  Upstream Author : Matt Wilkerson , Peter Waltman
* URL : https://bioconductor.org/packages/ConsensusClusterPlus/
* License : GPL-2
  Programming Lang: GNU R
  Description : GNU R determining cluster count and membership
 ConsensusClusterPlus is a BioCOnductor package providing an algorithm
 for determining cluster count and membership by stability evidence in
 unsupervised analysis.

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-bioc-consensusclusterplus



Bug#931068: zenity: Window icon is not displayed under Wayland

2019-06-25 Thread Yvan Masson

Package: zenity
Version: 3.30.0-2
Severity: normal

Dear Maintainer,

Window icon (which can be chosen with --window-icon) does not work when 
using Wayland, but works using Gnome. You can test with the following 
command (assuming this icon exists on your system):


$ zenity --info 
--window-icon=/usr/share/icons/Adwaita/16x16/actions/call-start.png


Do not hesitate to ask if you want me to submit this bug report upstream.

Also, it seems the issue also exists with Yad (a Zenity fork), as I 
already reported in #926736.


Regards,
Yvan

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

Kernel: Linux 4.19.0-5-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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages zenity depends on:
ii  libc6 2.28-10
ii  libgdk-pixbuf2.0-02.38.1+dfsg-1
ii  libglib2.0-0  2.58.3-2
ii  libgtk-3-03.24.5-1
ii  libnotify40.7.7-4
ii  libpango-1.0-01.42.4-6
ii  libwebkit2gtk-4.0-37  2.24.2-1
ii  libx11-6  2:1.6.7-1
ii  zenity-common 3.30.0-2

zenity recommends no packages.

zenity suggests no packages.

-- no debconf information



Bug#931070: Man page shows less options than "help" command

2019-06-25 Thread 積丹尼 Dan Jacobson
Package: anbox
Version: 0.0~git20190124-1
File: /usr/share/man/man1/anbox.1.gz

$ anbox help
reveals a "check-features" command not mentioned on the man page.
There may be more too.



Bug#931069: Indicate if monitor has been turned "--off"

2019-06-25 Thread 積丹尼 Dan Jacobson
Package: x11-xserver-utils
Version: 7.7+8
Severity: wishlist
File: /usr/bin/xrandr

If one does
$ xrandr --output LVDS-1 --off
the output of
$ xrandr
or
$ xrandr --verbose
does not reflect the change.

We have made that screen totally black but xrandr doesn't mention the
fact one single bit.

Sure, the screen is 1366x768 pixels and not 1366x767 pixels, so it tells
us that very precisely. But wouldn't you think it would mention that by
the way current status is "--off"?



Bug#716463: Patch

2019-06-25 Thread Jeremy Sowden
This crash involves calling /usr/lib/wmcoincoin/wmcoincoin_player
directly with an empty environment.  Under those circumstances
XOpenDisplay returns NULL:

   disp  = XOpenDisplay(NULL);

   if (argc == 1) {
 printf("kikou je suis un player pourri\n");
 printf("mes options toutes plus nazes les unes que les autres sont:\n");
 printf(" wmcoincoin_player uneimagepour voir une image\n");
 printf(" wmcoincoin_player -z unchiffre uneimage  pour voir une image avec 
un certain facteur de zoom\n");
 printf(" wmcoincoin_player -i uneimage pour connaitres les dimensions 
d'une image\n");
 printf(" wmcoincoin_player -s uneimage le stack-mode (pour 
debeuggai)\n");
 printf(" le dernier argument, optionel, est l'id de la fenetre a 
utiliser\n");
 exit(0);
   }
   if (argc >= 3 && strcmp(argv[1], "-i") == 0) {
 query_mode = 1;
 argc--; argv++;
   }
   if (argc >= 3 && strcmp(argv[1], "-s") == 0) {
 stack_mode = 1;
 argc--; argv++;
   }
   if (argc >= 3 && strcmp(argv[1], "-z") == 0) {
 prefs.zoom = atof(argv[2]);
 argc-=2; argv += 2;
   }
   if (argc == 2) {
 fname  = argv[1];
 if (!query_mode) {
   vis   = DefaultVisual(disp, DefaultScreen(disp));
   depth = DefaultDepth(disp, DefaultScreen(disp));
   cm= DefaultColormap(disp, DefaultScreen(disp));
   win   = XCreateSimpleWindow(disp, DefaultRootWindow(disp), 0, 0, 10, 10,
   0, 0, 0);
   XSelectInput(disp, win, ButtonPressMask | ButtonReleaseMask |
ButtonMotionMask | PointerMotionMask);
 }
   } else {
 XWindowAttributes attr;
 unsigned long lwin;
 sscanf(argv[2],"0x%lx",&lwin); win = lwin;
 //printf("win=%08lx\n", lwin);
 fname = argv[1];

which leads to a NULL-pointer being passed to XGetWindowAttributes:

 XGetWindowAttributes(disp, win, &attr);
 vis = attr.visual;
 depth = attr.depth;
 cm = attr.colormap;
   }

However, wmcoincoin_player is not supposed to be run like this.  It is
intended to be execked by wmcoincoin once the application is up and
running, which implies that the environment is correctly set up.

I've attached a fix.

J.
From 94bb12f2c1ba22d4d09fce286e4305f8c36e4155 Mon Sep 17 00:00:00 2001
From: Jeremy Sowden 
Date: Tue, 25 Jun 2019 14:01:38 +0100
Subject: [PATCH] If XOpenDisplay return NULL, exit.

---
 platypus/wmcoincoin_player.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/platypus/wmcoincoin_player.c b/platypus/wmcoincoin_player.c
index b11239ad15fa..06cb04bbe93f 100644
--- a/platypus/wmcoincoin_player.c
+++ b/platypus/wmcoincoin_player.c
@@ -104,6 +104,9 @@ main (int argc, char **argv)
init_anim();
 
disp  = XOpenDisplay(NULL);
+   if (disp == NULL)
+ return 1;
+
if (argc == 1) {
  printf("kikou je suis un player pourri\n");
  printf("mes options toutes plus nazes les unes que les autres sont:\n");
-- 
2.20.1



signature.asc
Description: PGP signature


Bug#929467: RFS: tfortune-1.0.0 [ITP]

2019-06-25 Thread Andre Noll
On Wed, Jun 19, 14:01, Adam Borowski wrote
> > Both issues have been fixed in v2 of the t/tfortunes branch which
> > I've just pushed out.  This branch also contains two new commits
> > which fix a gcc warning and a harmless memory leak.
> 
> Uploaded, with some changes.

Thanks a bunch for fixing my mistakes!

> > PS: I shall be offline until next Tuesday.
> 
> To skip the wait, I applied some fixes myself.  They are: a bogus
> day-of-week (which our tools detect and complain about) and the data package
> not being Arch:all.  Here's the diff:

[snip]

I've applied your patch and folded in the fixes into the existing
commit. See the v2 -> v3 section of the modified commit message.

Thanks again
Andre
-- 
Max Planck Institute for Developmental Biology
Max-Planck-Ring 5, 72076 Tübingen, Germany. Phone: (+49) 7071 601 829
http://people.tuebingen.mpg.de/maan/


signature.asc
Description: PGP signature


Bug#931071: hard-coded path in icebox_vlog

2019-06-25 Thread Lars Dölle
Package: fpga-icestorm
Version: 0~20181109git9671b76-1

Hi,

thank you very much for maintaining the icestorm package.

As the subject says, icebox_vlog contains a hard-coded path
in line 386 making the program fail to find the chipdb.

|with open("/usr/local/share/icebox/chipdb-%s.txt" % ic.device, "r") as f:

Kind regards

  Lars Dölle



Bug#931073: ITP: r-cran-ggdendro -- GNU R create dendrograms and tree diagrams using 'ggplot2'

2019-06-25 Thread Andreas Tille
Package: wnpp
Severity: wishlist

Subject: ITP: r-cran-ggdendro -- GNU R create dendrograms and tree diagrams 
using 'ggplot2'
Package: wnpp
Owner: Andreas Tille 
Severity: wishlist

* Package name: r-cran-ggdendro
  Version : 0.1
  Upstream Author : Andrie de Vries,
* URL : https://cran.r-project.org/package=ggdendro
* License : GPL-2
  Programming Lang: GNU R
  Description : GNU R create dendrograms and tree diagrams using 'ggplot2'
 This is a set of tools for dendrograms and
 tree plots using 'ggplot2'.  The 'ggplot2' philosophy is to
 clearly separate data from the presentation.
 Unfortunately the plot method for dendrograms plots
 directly to a plot device without exposing the data.
 The 'ggdendro' package resolves this by making available
 functions that extract the dendrogram plot data. The package
 provides implementations for tree, rpart, as well as diana and agnes
 cluster diagrams.

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-cran-ggdendro



Bug#931072: ITP: fonts-havana -- Old communism style script font from Poland

2019-06-25 Thread Gürkan Myczko

Package: wnpp
Severity: wishlist

* Package name: fonts-havana
  Version : 1.0
  Upstream Authors: Stowarzyszenie Kulturotwórcze Miastodwa
* URL : https://kroje.org/en/fonts/havana/
* License : OFL-1.1
  Description : Old communism style script font from Poland
 This font is inspired by Warsaw neon signs from before 1989. Just like 
the
 lettering of that period, the “Havava” design is detail oriented, 
coherent
 and sophisticated. Some letters are directly drawn from specific signs 
–
 letters “K” and “m” from “Kosmetyki” or letter “t” from “Mister” sign. 
The

 font’s name itself refers to a former cafe “Havana” in Warsaw.

Package will be availabe at http://phd-sid.ethz.ch/debian/fonts-havana/



Bug#931039: dh-strip-nondeterminism: Does not appear to clamp timestamps in PNG files (was: "Re: debhelper: something in the dh sequencer changes the tIME chunk of installed PNGs")

2019-06-25 Thread Thorsten Glaser
Hi Chris,

>I've forwarded this upstream here:

thanks! I did not want to get too deep into yak shaving in the
dark hours of the night as I had something to do with a deadline,
so I’ve only seen that something in dh did it.

>(Just as an aside, how come the tests fail? Are they looking

No, I just said this might make tests in packages fail, or
something worse, like embedding PNGs into output of programs
causing them to not be reproducible any more.

I just found them by diffing the two MuseScore builds.

bye,
//mirabilos
-- 
15:41⎜ Somebody write a testsuite for helloworld :-)



Bug#931074: ITP: r-cran-logging -- GNU R logging package

2019-06-25 Thread Andreas Tille
Package: wnpp
Severity: wishlist

Subject: ITP: r-cran-logging -- GNU R logging package
Package: wnpp
Owner: Andreas Tille 
Severity: wishlist

* Package name: r-cran-logging
  Version : 0.9
  Upstream Author : Mario Frasca,
* URL : https://cran.r-project.org/package=logging
* License : GPL-3
  Programming Lang: GNU R
  Description : GNU R logging package
 Pure R implementation of the ubiquitous log4j package. It offers
 hierarchic loggers, multiple handlers per logger, level based filtering,
 space handling in messages and custom formatting.

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-cran-logging



Bug#931075: ITP: r-cran-lasso2 -- GNU R L1 constrained estimation aka `lasso'

2019-06-25 Thread Andreas Tille
Package: wnpp
Severity: wishlist

Subject: ITP: r-cran-lasso2 -- GNU R L1 constrained estimation aka `lasso'
Package: wnpp
Owner: Andreas Tille 
Severity: wishlist

* Package name: r-cran-lasso2
  Version : 1.2
  Upstream Author : Justin Lokhorst, Bill Venables and Berwin Turlach;
* URL : https://cran.r-project.org/package=lasso2
* License : GPL-2+
  Programming Lang: GNU R
  Description : GNU R L1 constrained estimation aka `lasso'
 Routines and documentation for solving regression problems
 while imposing an L1 constraint on the estimates, based on
 the algorithm of Osborne et al. (1998).

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-cran-lasso2



Bug#930012: gcc-8: ICE building firefox 68.0~b6-2 on s390x and i386

2019-06-25 Thread Olivier Tilloy
Workaround submitted upstream:
https://bugs.chromium.org/p/skia/issues/detail?id=9202



Bug#870814: show message if unable to play video

2019-06-25 Thread 積丹尼 Dan Jacobson
Currently going to
$ /usr/lib/x86_64-linux-gnu/webkit2gtk-4.0/MiniBrowser https://www.youtube.com/
and trying to play a video now shows a message with a link to
https://www.youtube.com/supported_browsers
so I suppose this is an improvement.



Bug#931076: systemd: __main__.SeccompTest is failing on Ubuntu CI

2019-06-25 Thread Dan Streetman
Package: systemd
Version: 240-6ubuntu5.1
Severity: normal

Dear Maintainer,

Upstream systemd CI is broken on Ubuntu due to a recent upstream change.  The 
d/t/boot-and-services test needs to be fixed to account for the new upstream 
change.

This is reported upstream at:
https://github.com/systemd/systemd/issues/12709

This is reported for Ubuntu at:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1831296

Since upstream systemd CI uses the debian test packaging from experimental, 
this has to be corrected in that repo.  Merge request is open here:
https://salsa.debian.org/systemd-team/systemd/merge_requests/33

Please consider merging.  Thanks.



Bug#870814: show message if unable to play video

2019-06-25 Thread Alberto Garcia
On Tue, Jun 25, 2019 at 11:28:54PM +0800, 積丹尼 Dan Jacobson wrote:
> Currently going to
> $ /usr/lib/x86_64-linux-gnu/webkit2gtk-4.0/MiniBrowser 
> https://www.youtube.com/
> and trying to play a video now shows a message with a link to
> https://www.youtube.com/supported_browsers
> so I suppose this is an improvement.

Does installing gstreamer1.0-libav allow you to play the video?

If so, I propose to recommend that package and close this bug with
that. What do you think?

Berto



Bug#870814: show message if unable to play video

2019-06-25 Thread 積丹尼 Dan Jacobson
It still says "your browser does not recognize any of the video formats 
available."



Bug#931068: zenity: Window icon is not displayed under Wayland

2019-06-25 Thread Simon McVittie
On Tue, 25 Jun 2019 at 15:47:13 +0200, Yvan Masson wrote:
> Window icon (which can be chosen with --window-icon) does not work when
> using Wayland, but works using Gnome.

Wayland is a protocol, not an implementation.

What is the environment in which this doesn't work for you? Is it Weston,
or GNOME Shell 3.30 in Wayland mode, or KDE in Wayland mode, or Sway,
or something else?

What is the environment in which this does work for you? Is it GNOME Shell
3.30 in Wayland mode, or GNOME Shell 3.30 in Xorg mode, or something else?

The results I get are:

- GNOME Shell 3.30 in Xorg mode: chosen icon appears in top bar and dash
  (sidebar in overview)
- GNOME Shell 3.30 in Wayland mode: a "broken image" icon appears instead

smcv



Bug#870814: show message if unable to play video

2019-06-25 Thread Alberto Garcia
On Tue, Jun 25, 2019 at 11:55:46PM +0800, 積丹尼 Dan Jacobson wrote:
> It still says "your browser does not recognize any of the video formats 
> available."

With gstreamer1.0-libav installed ? What video are you exactly trying
to play ?

Berto



Bug#925906: sqlite3: FTCBFS: configure fails to find readline.h

2019-06-25 Thread Helmut Grohne
Control: clone -1 -2
Control: reassign -2 cross-config
Control: retitle -2 drop ac_cv_header_readline_h from cross-config.cache
Control: tags -2 =
Control: block -2 by -1

Thank you for the quick followup with details!

On Tue, Jun 25, 2019 at 11:43:01AM +0300, Yuriy M. Kaminskiy wrote:
> I built for armhf on i386/stretch host with pbuilder.

Important bit. I think pbuilder does not inject cross-config. This could
be a feature, because cross-configs are wrong sometimes.

> Relevant lines from
> http://crossqa.debian.net/build/sqlite3_3.27.2-3_armhf_20190622023957.log
> (with mysteriously successful readline.h detection)
> 
> checking for library containing readline... no
> checking for library containing tgetent... -lncurses
> checking for readline in -lreadline... yes
> checking for readline.h... (cached) yes

Please observe:  
This variable is injected by some cache. Likely from the cross-config
package split off dpkg-cross.

So cross-config was working around the bug and you fix it at the root
now. We should drop the workaround from cross-config:
https://sources.debian.org/src/dpkg-cross/2.6.15-3/config/cross-config.cache/#L242

Thank you for lifting this mystery. Given your explanations, I fully
agree with your patch now.

Helmut



Bug#870814: show message if unable to play video

2019-06-25 Thread 積丹尼 Dan Jacobson
AG> With gstreamer1.0-libav installed ? What video are you exactly trying
AG> to play ?

Yes.
The first one that youtube shows me.
So OK, give me a youtube movie url that plays for you and I'll try it.



Bug#931052: unblock: webkit2gtk/2.24.2-2

2019-06-25 Thread Alberto Garcia
On Tue, Jun 25, 2019 at 11:04:59AM +0300, Alberto Garcia wrote:

> This upload disables the JIT compiler and enables the CLoop
> JavaScript interpreter, which is slower but works on all CPUs. It
> also removes the gcc SSE2 flags. Only the i386 build is affected by
> these changes.

I realized that this is not accurate: in this particular version of
webkit2gtk the JIT compiler is already disabled for i386 (work is
being done upstream to have it enabled back again), so in practice
this line is a no-op because these are already the current values:

> + EXTRA_CMAKE_ARGUMENTS += -DENABLE_JIT=OFF -DENABLE_C_LOOP=ON

I would still keep that line because it will be necessary as soon as
upstream brings back JIT support for x86.

This patch still removes -msse2 -mfpmath=sse from CFLAGS, and that's
what makes the package work in non-SSE2 CPUs.

Berto



Bug#931078: A patch for LIRC with kernel 4.19 and gpio-ir for Raspbian Buster

2019-06-25 Thread Takashi Kanamaru
Package: lirc
Version: 0.10.1-5.2
Severity: important

Dear Maintainer,

When using kernel 4.19.X and LIRC on Raspberry Pi with Raspbian Buster,
gpio-ir should be used because lirc_dev is not officially installed.

However, pulse-space sequences generated by gpio-ir is slightly
different from that of lirc_dev.

Therefore, irrecord, mode2, irw do not work correctly with kernel 4.19
and gpio-ir
on Raspberry Pi.

I created a patch to modify the above problem.
This patch also works with earlier kernel and lirc_dev.
https://github.com/neuralassembly/raspi/blob/master/lirc-gpio-ir-0.10.patch

Could you please merge this patch into the deb package of LIRC?

You can see the discussions in the following URL.
https://www.raspberrypi.org/forums/viewtopic.php?f=28&t=235256

Sincerely,

Takashi Kanamaru



Bug#931079: ITP: mimalloc -- compact general purpose allocator with excellent performance

2019-06-25 Thread Gürkan Myczko

Package: wnpp
Severity: wishlist

* Package name: mimalloc
  Version : for-experimental
  Upstream Authors: Microsoft Corporation, Daan Leijen
* URL : https://github.com/microsoft/mimalloc
* License : MIT
  Description : compact general purpose allocator with excellent 
performance
 This is a general purpose allocator with excellent performance 
characteristics.
 Initially developed by Daan Leijen for the run-time systems of the Koka 
and

 Lean languages.
 .
 It is a drop-in replacement for malloc and can be used in other 
programs

 without code changes.

Package will be availabe at http://phd-sid.ethz.ch/debian/mimalloc/



Bug#931080: asciiflowqt: Wish for new package: asciiflowqt

2019-06-25 Thread georg
Package: asciiflowqt
Version: v0.3.3
Severity: wishlist

Dear Maintainer,

i would like to add asciiflowqt to debian. It has already a debian branch with
debian packaging.

The URL is:
https://github.com/schorsch1976/AsciiFlowQT

It is a offline ascii art editor. It is mostly used for programming issues to
document structure in an header or source as a comment.

Features:
=
- Export and Import ascii to/from the clipboard
- Export and Import ascii to/from a file
- Move parts of the ascii art
- draw rectangles
- resize rectangles
- draw class diagramms
- draw arrows
- draw lines
- draw freehand
- add text to any position
- undo and redo any change
- practicly unlimited space. The drawing area grows when you move out of it.

Licence
===
GPL-3.0

Used Libraries:
===
QT-5



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

Kernel: Linux 4.19.0-5-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_CRAP
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash



Bug#931081: libyubikey-udev: missing Breaks+Replaces: libykpers-1-1 (<< 1.19.3)

2019-06-25 Thread Andreas Beckmann
Package: libyubikey-udev
Version: 1.19.3-3
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'stretch'.
It installed fine in 'stretch', then the upgrade to 'buster' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces

>From the attached log (scroll to the bottom...):

  Preparing to unpack .../libyubikey-udev_1.19.3-3_all.deb ...
  Unpacking libyubikey-udev (1.19.3-3) ...
  dpkg: error processing archive 
/var/cache/apt/archives/libyubikey-udev_1.19.3-3_all.deb (--unpack):
   trying to overwrite '/lib/udev/rules.d/69-yubikey.rules', which is also in 
package libykpers-1-1:amd64 1.17.3-1
  Errors were encountered while processing:
   /var/cache/apt/archives/libyubikey-udev_1.19.3-3_all.deb

The version (<< 1.19.3) is based on this changelog entry in 1.19.3-1:
  * Replace custom udev rules with libu2f-udev.
Also drop build dependency on udev


cheers,

Andreas


libykpers-1-1=1.17.3-1_libyubikey-udev=1.19.3-3.log.gz
Description: application/gzip


Bug#931082: netgen: Dead link in man 1 netgen

2019-06-25 Thread Sebastian Bachmann
Package: netgen
Version: 6.2.1804+dfsg1-3
Severity: minor

Dear Maintainer!

The manpage of netgen contains a link to http://www.mathcces.rwth-
aachen.de/netgen/doku.php which appears to be dead.
As far as I understand, the homepage of netgen is now https://ngsolve.org/

When greping for the URL in the netgen repo at sala.debian.org, I find other
occurences too:

$ git grep rwth-aachen.de
debian/manpages/netgen.sgml:Homepage: http://www.mathcces.rwth-
aachen.de/netgen/doku.php
debian/manpages/ng_stl.1:Homepage: http://www.mathcces.rwth-
aachen.de/netgen/doku.php
debian/manpages/ng_vol.1:Homepage: http://www.mathcces.rwth-
aachen.de/netgen/doku.php
doc/ng4.tex:Aachen University, Germany (http://www.mathcces.rwth-
aachen.de/netgen).
doc/ng4.tex:http://www.mathcces.rwth-aachen.de/netgen

best regards
Sebastian Bachmann



-- System Information:
Debian Release: 10.0
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (500, 
'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages netgen depends on:
ii  libc62.28-10
ii  libgcc1  1:8.3.0-6
ii  libgl1   1.1.0-1
ii  libglu1-mesa [libglu1]   9.0.0-2.1+b3
ii  libmetis55.1.0.dfsg-5+b2
ii  libnglib-6.2.18046.2.1804+dfsg1-3
ii  libocct-data-exchange-7.37.3.0+dfsg1-5
ii  libocct-foundation-7.3   7.3.0+dfsg1-5
ii  libocct-modeling-algorithms-7.3  7.3.0+dfsg1-5
ii  libocct-modeling-data-7.37.3.0+dfsg1-5
ii  libocct-ocaf-7.3 7.3.0+dfsg1-5
ii  libocct-visualization-7.37.3.0+dfsg1-5
ii  libopenmpi3  3.1.3-11
ii  libpython3.7 3.7.3-2
ii  libstdc++6   8.3.0-6
ii  libtcl8.68.6.9+dfsg-2
ii  libtk8.6 8.6.9-2
ii  libx11-6 2:1.6.7-1
ii  libxmu6  2:1.1.2-2+b3
ii  tix  8.4.3-10
ii  zlib1g   1:1.2.11.dfsg-1

netgen recommends no packages.

Versions of packages netgen suggests:
pn  netgen-doc  

-- no debconf information



Bug#931064: unblock: grub2/2.02+dfsg1-20

2019-06-25 Thread Ivo De Decker
Control: tags -1 confirmed d-i

Hi,

On Tue, Jun 25, 2019 at 01:33:50PM +0100, Steve McIntyre wrote:
> Subject: unblock: grub2/2.02+dfsg1-20

Unblocked. Still needs the unblock u-deb (kibi Cc'ed).

Thanks,

Ivo



Bug#930988: libtifiles FTCBFS: Missing dependency tfdocgen

2019-06-25 Thread Helmut Grohne
Hi Lionel,

On Tue, Jun 25, 2019 at 09:43:24AM +0200, Lionel Debroux wrote:
> tfdocgen is a simple HTML documentation generator, which supports a
> Doxygen-like (but not Doxygen-compatible) syntax for C/C++ code, and
> maybe other languages which supports /** */ comments, I haven't tried.
> It was written by the previous maintainer over a decade ago, I have
> barely modified it. The files it produces are packaged in the -dev packages.

Thank you for chiming in. So do you confirm that tfdocgen consumes only
textual formats (source code with comment markup) and produces only
textual formats (html) and that the behaviour and output is independent
of the processor architecture being executed on?

If so, the tfdocgen package meets the requirements for being marked
Multi-Arch: foreign and should be thus marked. Any :native annotations
on tfdocgen should be reverted in this case.

You can confirm by sending the following paragraph to
cont...@bugs.debian.org:

reassign 930985 tfdocgen
reassign 930986 tfdocgen
reassign 930987 tfdocgen
reassign 930988 tfdocgen
forcemerge 930985 930986 930987 930988
retitle 930985 mark tfdocgen Multi-Arch: foreign
tags 930985 =
affects 930985 = src:libticables src:libticalcs src:libticonv src:libtifiles
user debian-cr...@lists.debian.org
usertags 930985 ftcbfs
thanks

Helmut



Bug#931039: dh-strip-nondeterminism: Does not appear to clamp timestamps in PNG files (was: "Re: debhelper: something in the dh sequencer changes the tIME chunk of installed PNGs")

2019-06-25 Thread Chris Lamb
Hi Thorsten,

> thanks! I did not want to get too deep into yak shaving in the
> dark hours of the night

Absolutely nothing to apologise for. It's far better the report exists
rather than it falling between the cracks and not being reported, even
if it requires a quick 'n' easy reassign (thanks Niels).

> >(Just as an aside, how come the tests fail? Are they looking
> 
> No, I just said this might make tests in packages fail, or
> something worse, like embedding PNGs into output of programs
> causing them to not be reproducible any more.

I can see how it may make tests fail if they were naively comparing
checksums or similar, but I'm not sure how this could make a package
not reproducible. As in, we would surely just be moving from one set
timestamp (the "original") to another timestamp (taken from the
changelog in this particular case), both of which are fixed between
builds of the same version.


Best wishes,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org 🍥 chris-lamb.co.uk
   `-



Bug#931043: unblock: expat/2.2.6-2

2019-06-25 Thread Ivo De Decker
Control: tags -1 d-i

Hi,

On Tue, Jun 25, 2019 at 06:59:09AM +0200, Salvatore Bonaccorso wrote:
> Please unblock package expat, it fixes CVE-2018-20843 and got fixed by
> Laszlo cherry-picking the upstream fix. The issue is tracked as
> #931031 in the BTS:
> 
> > expat (2.2.6-2) unstable; urgency=high
> > 
> >   * Fix extraction of namespace prefix from XML name (CVE-2018-20843)
> > (closes: #931031).
> > 
> >  -- Laszlo Boszormenyi (GCS)   Mon, 24 Jun 2019 21:18:31 
> > +
> 
> unblock expat/2.2.6-2

I'm fine with this, but expat has a udeb, so this needs a d-i ack. Kibi Cc's
(and diff quoted below for easy review).

Thanks,

Ivo


> diff -Nru expat-2.2.6/debian/changelog expat-2.2.6/debian/changelog
> --- expat-2.2.6/debian/changelog  2018-08-15 17:18:15.0 +0200
> +++ expat-2.2.6/debian/changelog  2019-06-24 23:18:31.0 +0200
> @@ -1,3 +1,10 @@
> +expat (2.2.6-2) unstable; urgency=high
> +
> +  * Fix extraction of namespace prefix from XML name (CVE-2018-20843)
> +(closes: #931031).
> +
> + -- Laszlo Boszormenyi (GCS)   Mon, 24 Jun 2019 21:18:31 
> +
> +
>  expat (2.2.6-1) unstable; urgency=medium
>  
>* New upstream release.
> diff -Nru 
> expat-2.2.6/debian/patches/Fix_extraction_of_namespace_prefix_from_XML_name.patch
>  
> expat-2.2.6/debian/patches/Fix_extraction_of_namespace_prefix_from_XML_name.patch
> --- 
> expat-2.2.6/debian/patches/Fix_extraction_of_namespace_prefix_from_XML_name.patch
>  1970-01-01 01:00:00.0 +0100
> +++ 
> expat-2.2.6/debian/patches/Fix_extraction_of_namespace_prefix_from_XML_name.patch
>  2019-06-24 23:18:31.0 +0200
> @@ -0,0 +1,23 @@
> +From 11f8838bf99ea0a6f0b76f9760c43704d00c4ff6 Mon Sep 17 00:00:00 2001
> +From: Sebastian Pipping 
> +Date: Wed, 12 Jun 2019 15:42:22 +0200
> +Subject: [PATCH] xmlparse.c: Fix extraction of namespace prefix from XML name
> + (#186)
> +
> +---
> + expat/lib/xmlparse.c | 2 +-
> + 1 file changed, 1 insertion(+), 1 deletion(-)
> +
> +diff --git a/expat/lib/xmlparse.c b/expat/lib/xmlparse.c
> +index 30d55c5c..737d7cd2 100644
> +--- a/expat/lib/xmlparse.c
>  b/expat/lib/xmlparse.c
> +@@ -6080,7 +6080,7 @@ setElementTypePrefix(XML_Parser parser, ELEMENT_TYPE 
> *elementType)
> +   else
> + poolDiscard(&dtd->pool);
> +   elementType->prefix = prefix;
> +-
> ++  break;
> + }
> +   }
> +   return 1;
> diff -Nru expat-2.2.6/debian/patches/series expat-2.2.6/debian/patches/series
> --- expat-2.2.6/debian/patches/series 1970-01-01 01:00:00.0 +0100
> +++ expat-2.2.6/debian/patches/series 2019-06-24 23:18:31.0 +0200
> @@ -0,0 +1 @@
> +Fix_extraction_of_namespace_prefix_from_XML_name.patch



Bug#931066: Info

2019-06-25 Thread MaXaMaR
It seems to involve mesa package.
I have recompiled radeonsi_dri.so, maybe now someone can make sense out of it.

(EE) Backtrace:
(EE) 0: /usr/lib/xorg/Xorg (OsLookupColor+0x139) [0x5609d99fc889]
(EE) 1: /lib/x86_64-linux-gnu/libpthread.so.0 (funlockfile+0x50) 
[0x7fe8a6ea0f8f]
(EE) 2: /lib/x86_64-linux-gnu/libc.so.6 (memcpy+0x2d7) [0x7fe8a6d5a387]
(EE) 3: /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so (si_buffer_subdata+0xa4) 
[0x7fe8a5524098]
(EE) 4: /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so (pipe_buffer_write+0x46) 
[0x7fe8a54d3233]
(EE) 5: /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so 
(si_pm4_upload_indirect_buffer+0x193) [0x7fe8a54d3ac7]
(EE) 6: /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so (si_init_config+0x775) 
[0x7fe8a54ebeab]
(EE) 7: /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so 
(si_init_state_functions+0x301) [0x7fe8a54eb479]
(EE) 8: /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so (si_create_context+0x648) 
[0x7fe8a54d0ed9]
(EE) 9: /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so 
(radeonsi_screen_create_impl+0xf57) [0x7fe8a54d2d93]
(EE) 10: /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so 
(amdgpu_winsys_create+0x472) [0x7fe8a559de54]
(EE) 11: /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so 
(radeonsi_screen_create+0x71) [0x7fe8a54d2faf]
(EE) 12: /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so 
(pipe_radeonsi_create_screen+0x24) [0x7fe8a53e6a57]
(EE) 13: /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so 
(pipe_loader_drm_create_screen+0x3a) [0x7fe8a54c787c]
(EE) 14: /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so 
(pipe_loader_create_screen+0x52) [0x7fe8a54c6bd5]
(EE) 15: /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so (dri2_init_screen+0xcd) 
[0x7fe8a53ee2e2]
(EE) 16: /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so 
(driCreateNewScreen2+0x1ed) [0x7fe8a53e7d7e]
(EE) 17: /lib/x86_64-linux-gnu/libgbm.so.1 (gbm_format_get_name+0x189e) 
[0x7fe8a6455d0e]
(EE) 18: /lib/x86_64-linux-gnu/libgbm.so.1 (gbm_format_get_name+0x1c23) 
[0x7fe8a64563b3]
(EE) 19: /lib/x86_64-linux-gnu/libgbm.so.1 (gbm_create_device+0x57) 
[0x7fe8a64525e7]
(EE) unw_get_proc_name failed: no unwind info found [-10]
(EE) 20: /usr/lib/xorg/modules/drivers/amdgpu_drv.so (?+0x0) [0x7fe8a646d650]
(EE) 21: /usr/lib/xorg/Xorg (InitOutput+0xbac) [0x5609d98deb5c]
(EE) 22: /usr/lib/xorg/Xorg (InitFonts+0x1cf) [0x5609d98a17df]
(EE) 23: /lib/x86_64-linux-gnu/libc.so.6 (__libc_start_main+0xeb) 
[0x7fe8a6cc6b6b]
(EE) 24: /usr/lib/xorg/Xorg (_start+0x2a) [0x5609d988b67a]
(EE)
(EE) Illegal instruction at address 0x7fe8a6d5a2c7



Bug#931083: ocfs2-tools FTCBFS: broken, outdated, embedded copies of PKG_PROG_PKG_CONFIG and AM_PATH_GLIB_2_0

2019-06-25 Thread Helmut Grohne
Source: ocfs2-tools
Version: 1.8.5-7
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

ocfs2-tools fails to cross build from source, because it uses broken,
outdated, embedded copies of PKG_PROG_PKG_CONFIG and AM_PATH_GLIB_2_0.
Please remove these copies. Alternatively, please update and register
them with the security tracker. This bug report comes without a patch,
because it is already fixed in pkg-config and glib2.0 respectively.
ocfs2-tools just happens to have a copy of the bug.

Helmut



Bug#930803: new program: runcached

2019-06-25 Thread Nicolas Schier
tags -1 + moreinfo
thanks

Hi András,

> I just wrote this script:
> https://gist.github.com/akorn/51ee2fe7d36fa139723c851d87e56096 and thought
> it might be a good addition to moreutils.
> 
> It caches the stdout, stderr and exit status of arbitrary commands for a
> configurable length of time, returning data from cache on subsequent
> invocations if the cache is still fresh.

thanks for your suggestion; I think it's quite an interesting idea!
And you made me curious:  which commands are you running through
'runcached'?  All programs I thought of have their basic functionality
based on side-effects as file system or network access.

> It currently has semi-esoteric dependencies: it's written in zsh and uses
> chpst from the runit package for locking. If you're willing to include the
> script I can change it to use flock(1) instead, but I'm not rewriting it in
> POSIX sh.

Adding new scripts to the moreutils collection is usually done by
forwarding to the upstream maintainer (Joey Hess ) and
asking for script inclusion.  But, as Joey keeps more than just one eye
on cross platform compatibility, I expect non-POSIX implementations to
be rejected.  Do you keep your non-POSIX statement?

Did you think about the license you want to stick it to? GPL2+?

Kind regards,
Nicolas

-- 
epost: nico...@fjasle.eu   irc://oftc.net/nsc
↳ gpg: 18ed 52db e34f 860e e9fb  c82b 7d97 0932 55a0 ce7f
 -- frykten for herren er opphav til kunnskap --


signature.asc
Description: PGP signature


Bug#931084: unblock: netdata/1.12.2-2

2019-06-25 Thread Daniel Baumann
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package netdata.

First, I'm sorry.. I'm terribly late with this and there's no excuse for
that.

Second, I seem to have miscalculated the
'last-possible-point-in-time-to-upload-to-unstable-and-migrate-to-testing-before-full-freeze'
by one hour on 2019-02-27. so netdata 1.12.2-2 which was supposed to be
the one for buster just didn't make it in time into testing before the
freeze on 2019-03-12. If I didn't make that mistake, netdata 1.12-2-2
would have migrated on its own.

Now, netdata 1.12.0-1..1.12.2-2 fixes two important things:

a) the web frontend as well as the documentation has been fixed to not
   spy on its users (via googleanalytics).

b) opt-out to send telemetry to upstream

Preferably, netdata 1.12.2-2 could be allowed to migrate to testing. If
that's not possible, both should be fixed through stable updates for
buster r1 which I'd like to avoid the extra-work for everyone.

Would you mind allow netdata to migrate at this point?

(debdiff of debian/ is attached)

Regards,
Daniel
diff -Naurp debian_1.12.0-1/changelog debian_1.12.2-2/changelog
--- debian_1.12.0-1/changelog	2019-06-25 20:27:42.597478366 +0200
+++ debian_1.12.2-2/changelog	2019-06-25 20:28:01.646098056 +0200
@@ -1,3 +1,47 @@
+netdata (1.12.2-2) unstable; urgency=medium
+
+  [ Federico Ceratto ]
+  * Add patch to remove Sign In button
+
+  [ Daniel Baumann ]
+  * When disabling the 'Sign In' button on the right side, only turn it
+off in the javascript and keep the html unmodified.
+  * Sorting patch series.
+
+ -- Daniel Baumann   Sat, 02 Mar 2019 16:46:44 +0100
+
+netdata (1.12.2-1) unstable; urgency=medium
+
+  * Merging upstream version 1.12.2.
+
+ -- Daniel Baumann   Thu, 28 Feb 2019 22:18:45 +0100
+
+netdata (1.12.1-2) unstable; urgency=medium
+
+  * Downgrading nodejs depends in netdata-plugins-nodejs to recommends as
+not all architectures have nodejs at the moment.
+
+ -- Daniel Baumann   Wed, 27 Feb 2019 22:09:05 +0100
+
+netdata (1.12.1-1) unstable; urgency=medium
+
+  [ Lennart Weller ]
+  * Add patch to remove Google Analytics from generated docs
+
+  [ Daniel Baumann ]
+  * Rediffing remove-googleanalytics.patch.
+  * Opting out by default from sending anonymous statistics (Closes: #923114).
+  * Merging upstream version 1.12.1.
+  * Refreshing remove-googleanalytics.patch for new upstream version.
+  * Updating lintian overrides.
+  * Removing currently usless depends on bash as it's still an essential
+package.
+  * Adding missing GPL-3-only license stanza in copyright file.
+  * Debranding license references in copyright.
+  * Updating TODO file.
+
+ -- Daniel Baumann   Sun, 24 Feb 2019 21:32:56 +0100
+
 netdata (1.12.0-1) unstable; urgency=medium
 
   * Merging upstream version 1.12.0.
diff -Naurp debian_1.12.0-1/control debian_1.12.2-2/control
--- debian_1.12.0-1/control	2019-06-25 20:27:42.597478366 +0200
+++ debian_1.12.2-2/control	2019-06-25 20:28:01.646098056 +0200
@@ -97,7 +97,6 @@ Section: net
 Architecture: all
 Multi-Arch: foreign
 Depends:
- bash,
  netdata-core (>= ${source:Version}) | netdata-core-no-sse (>= ${source:Version}),
  ${misc:Depends},
 Suggests:
@@ -120,8 +119,9 @@ Architecture: all
 Multi-Arch: foreign
 Depends:
  netdata-core (>= ${source:Version}) | netdata-core-no-sse (>= ${source:Version}),
- nodejs,
  ${misc:Depends},
+Recommends:
+ nodejs,
 Provides:
  netdata-plugins,
 Enhances:
diff -Naurp debian_1.12.0-1/copyright debian_1.12.2-2/copyright
--- debian_1.12.0-1/copyright	2019-06-25 20:27:42.597478366 +0200
+++ debian_1.12.2-2/copyright	2019-06-25 20:28:01.650098186 +0200
@@ -183,7 +183,7 @@ Files:
  collectors/python.d.plugin/python_modules/third_party/boinc_client.py
 Copyright: 2013 Rodrigo Silva (MestreLion) 
2017 Austin S. Hemmelgarn
-License: GPL-3.0
+License: GPL-3
 
 Files:
  collectors/python.d.plugin/python_modules/third_party/mcrcon.py
@@ -224,8 +224,8 @@ License: LGPL-3+
  You should have received a copy of the GNU Lesser General Public
  License along with this library;  If not, see .
  .
- On Debian systems, the complete text of the GNU Lesser General Public
- License version 3 can be found in /usr/share/common-licenses/LGPL-3.
+ The complete text of the GNU Lesser General Public License version 3
+ can be found in /usr/share/common-licenses/LGPL-3.
 
 License: LGPL-2.1
  This program is free software; you can redistribute it and/or modify
@@ -242,9 +242,23 @@ License: LGPL-2.1
  along with this program; if not, write to the Free Software
  Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA.
  .
- On Debian GNU/Linux systems, the complete text of the GNU Library
- General Public License, version 2, can be found in
- /usr/share/common-licenses/LGPL-2.
+ The complete text of the GNU Library General Public License, version 2,
+ can be found in /usr/share/common-licenses/LGPL

Bug#930664: ITP: libcamera/0~190601-1

2019-06-25 Thread Andrej Shadura
On Wed, 19 Jun 2019 10:38:39 -0300 "eamanu15 ."
 wrote:
> > hi.
> > i haven't looked into your packaging yet, but...
> >
> > - i'm interested in sponsoring the package
> >
> Great!

I am too interested in sponsoring :)

> - would you consider maintaining the package under the multimedia-team
> > umbrella?
> >
> 
> It would be great. I think I will need to ask for permission to
> multimedia-team. I will send a mail :-)

I have added you to the salsa project. I have create a repo and will
push a cleaned up version of your work for you to have a look at.

> > - last time i checked libcamera it wasn't really usable. do you know
> > anything about the timeframe for a first upstream release? (i haven't
> > really followed any discussion)

> I think is usable for test. Maybe we will be start with a experimental
> release for Debian? (Not unstable).
> 
> I open the discussion for a release, but the developers don't feel that
> libcamera is ready for a first release yet.  I will contact them for new
> news.

Probably uploading to experimental first is a good idea.

-- 
Cheers,
  Andrej



Bug#931085: mailavenger: drops TCP immediately after receiving 'QUIT', without sending the 221 response

2019-06-25 Thread Philip Hands
Package: mailavenger
Version: 0.8.5-1
Severity: normal

Hi Dererk,

It seems that mailavenger does not actually send the '221 {hostname}' message
that it is supposed to (despite showing it doing so in its debugging output).

This appears to make some SMTP clients decide that the email was not sent
(despite having received the '250 ok' after the data, resulting in them
sending the same mail repeatedly.

One can easily confirm this with swaks, thus:

  swaks --from h...@example.com --to th...@example.com --server=my.avenger.host

Which will give you a result which ends with something like this:

=-=-=-=-
...
 -> This is a test mailing
 -> 
 -> 
 -> .
<-  250 ok
 -> QUIT
*** Remote host closed connection unexpectedly.
=-=-=-=-

The thing that makes this "unexpected" is that the 221 response is missing.

This would seem to be because the IO is not being flushed when the socket
is closed.  This can be fixed by adding a flush, as you can see in this
git branch:

  https://salsa.debian.org/philh/mailavenger/tree/premature-close-bug-fixed

Specifically in this patch file:

  
https://salsa.debian.org/philh/mailavenger/blob/premature-close-bug-fixed/debian/patches/flush-aio-to-force-sending-of-farewell-p.patch

(I've attached that patch to this report, just for completeness)

It would not surprise me if there's a better way to do this, but this
does at least work.  The reason I suspect that there's a better way is
that presumably there are other places where the connection is being
dropped with unsent messages in the buffers, so it probably ought to be
fixed in the code responsible for bringing the connection down.

The result of building with this patch is currently running on my smtp
server, so one can demonstrate the correct behaviour that this results
in with telnet, thus:

=-=-=-=-
phil@whist  ~ % telnet mail.hands.com 25
Trying 78.129.164.123...
Connected to mail.hands.com.
Escape character is '^]'.
220 free.hands.com ESMTP
quit
221 free.hands.com
Connection closed by foreign host.
=-=-=-=-

Note the line "221 free.hands.com" -- this line is missing when running the 
0.8.5-1 version.

BTW also in that salsa repo, I've added a configuration to run salsa-CI,
as well as the beginnings of an autopkgtest test.  The autopkgtest does
work when run locally, but seems not to work within docker as in the
salsa-CI setup, presumably because networking is different within the
container -- I'll fix that if I can work out what's up.

The following system information is from my laptop, which exhibits the
same symptoms as the server, but may well have more recent packages.
Feel free to ask for the info from the server if you think it's important.

Cheers, Phil.

-- System Information:
Debian Release: 10.0
  APT prefers testing
  APT policy: (500, 'testing'), (500, 'stable'), (300, 'unstable')
Architecture: amd64 (x86_64)

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

Versions of packages mailavenger depends on:
ii  adduser 3.118
ii  dma [mail-transport-agent]  0.11-1+b1
ii  libc6   2.28-10
ii  libdb5.35.3.28+dfsg1-0.5
ii  libgcc1 1:8.3.0-6
ii  libpcap0.8  1.8.1-6
ii  libssl1.1   1.1.1c-1
ii  libstdc++6  8.3.0-6
ii  lsb-base10.2019051400

mailavenger recommends no packages.

mailavenger suggests no packages.

-- no debconf information
From: Philip Hands 
Date: Tue, 25 Jun 2019 12:32:00 +0200
X-Dgit-Generated: 0.8.5-1.1~hands1 aeafef4798f48117120eb6e9eef9d11c77ee2dfb
Subject: flush aio, to force sending of farewell packet

I suspect that there's a better way to do this, as it seems
to me that the library should know to flush all IO when the
socket is closed.  However this is a trivial change, and it
does work.

---

--- mailavenger-0.8.5.orig/asmtpd/smtpd.C
+++ mailavenger-0.8.5/asmtpd/smtpd.C
@@ -889,6 +889,7 @@ smtpd::getcmd (str line, int err)
   }
   else if (cmd == "quit") {
 aio << "221 " << opt->hostname << "\r\n";
+aio->flush ();
 delete this;
   }
   else if (cmd == "noop")


Bug#800518: ITA: 9base -- Plan 9 userland tools

2019-06-25 Thread Boyuan Yang
On Mon, 24 Jun 2019 05:19:02 + Elliott Pardee  wrote:
> I'd like to try my hand at this. Get my toes wet in maintaining packages. :)
> 
> Advice appreciated!


My advice: take a look at all the existing work at both the h
ttps://salsa.debian.org/debian/9base and the upstream development repo. Let me
know if you need write permission to the repository on Salsa or package upload
review/sponsorship.

Regards,
Boyuan Yang


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


Bug#929011: unblock: singularity-container/3.1.1+ds-1

2019-06-25 Thread Ansgar
Control: tag -1 - moreinfo

Paul Gevers writes:
> On Wed, 15 May 2019 03:47:28 -0400 Afif Elghraoui  wrote:
>> Please unblock package singularity-container/3.1.1+ds-1
>> 
>> This package is prone to security vulnerabilities. Upstream provides
>> long-term support for selected versions to their paid users, but also
>> releases all code changes (including backported security patches) to the
>> community.
>> 
>> Both 3.0.x and 3.1.x were released earlier this year and it was not
>> known at the time which of these would be the LTS version. 3.0.3 is what
>> I bet on and what is in Testing now, but it now turns out that I was
>> wrong and it's actually 3.1. Using it would greatly facilitate our
>> ability to provide support over the lifetime of Buster.
>> 
>> The benefits of doing this have also just been clearly demonstrated:
>> Upstream just released 3.2.0, adding new features as well as fixing
>> security issues affecting versions 3.1.0 and up, but because 3.1 is
>> under LTS support for their paid users, they also provided the security
>> patches backported to 3.1 (see the 3.2.0 release notes -
>> https://github.com/sylabs/singularity/releases/tag/v3.2.0 ).
>> 
>> So I apologize for the large diff, but I think we'd be in much better
>> shape having this upstream version in Buster. Especially because of the
>> large diff, backporting patches to 3.0 without the help from upstream
>> that we'd get by using 3.1 would be unnecessarily more burdensome.
>> 
>> many thanks for your time and consideration
>
> Your proposed changes very much do not align with the freeze policy, so
> you're asking for an exception for a new upstream release. This package
> is currently listed to be auto-removed due to docker.io, so I am not
> going to review it now. docker.io is a major concern for the
> security-team so that needs to be resolved first. If that gets resolved
> in a timely manner, i.e. before it is auto-removed, please ping this bug
> (e.g. by removing the moreinfo bug).

I've removed the moreinfo tag as docker.io was unblocked.

Ansgar



Bug#931086: bro/2.5.5-1+deb10u1 buster upload?

2019-06-25 Thread Hilko Bengen
Package: release.debian.org
Severity: normal

bro/2.5.5-1 (unstable, testing) is affected by CVE-2018-16807,
CVE-2018-17019 (#908614, #908779) and bro/2.6.1+ds1-1 is still sitting
in NEW.

May I upload bro/2.5.5-1+deb10u1 to buster?

I have attached a debdiff.

Cheers,
-Hilko

diff -Nru bro-2.5.5/debian/changelog bro-2.5.5/debian/changelog
--- bro-2.5.5/debian/changelog	2019-06-25 21:26:53.0 +0200
+++ bro-2.5.5/debian/changelog	2018-09-05 16:05:40.0 +0200
@@ -1,10 +1,3 @@
-bro (2.5.5-1+deb10u1) buster; urgency=medium
-
-  * Add patches for CVE-2018-16807, CVE-2018-17019 (Closes: #908614,
-#908779)
-
- -- Hilko Bengen   Tue, 25 Jun 2019 21:26:53 +0200
-
 bro (2.5.5-1) unstable; urgency=medium
 
   * New upstream version 2.5.5
diff -Nru bro-2.5.5/debian/patches/0006-Fix-potential-memory-leak-in-Kerberos-scripts.patch bro-2.5.5/debian/patches/0006-Fix-potential-memory-leak-in-Kerberos-scripts.patch
--- bro-2.5.5/debian/patches/0006-Fix-potential-memory-leak-in-Kerberos-scripts.patch	2019-06-25 21:26:53.0 +0200
+++ bro-2.5.5/debian/patches/0006-Fix-potential-memory-leak-in-Kerberos-scripts.patch	1970-01-01 01:00:00.0 +0100
@@ -1,38 +0,0 @@
-From: Jon Siwek 
-Date: Mon, 10 Sep 2018 18:06:07 -0500
-Subject: Fix potential memory leak in Kerberos scripts
-
-Reported by Maksim Shudrak.
-

-
-Stripped files:
- testing/btest/Traces/krb/optional-service-name.pcap
- testing/btest/core/leaks/krb-service-name.test
-

-
-diff --git a/scripts/base/protocols/krb/main.bro b/scripts/base/protocols/krb/main.bro
-index 02abced..9621378 100644
 a/scripts/base/protocols/krb/main.bro
-+++ b/scripts/base/protocols/krb/main.bro
-@@ -140,7 +140,8 @@ event krb_as_request(c: connection, msg: KDC_Request) &priority=5
- 
- 	c$krb$request_type = "AS";
- 	c$krb$client   = fmt("%s/%s", msg?$client_name ? msg$client_name : "", msg$service_realm);
--	c$krb$service  = msg$service_name;
-+	if ( msg?$service_name )
-+		c$krb$service  = msg$service_name;
- 
- 	if ( msg?$from )
- 		c$krb$from = msg$from;
-@@ -183,7 +184,8 @@ event krb_tgs_request(c: connection, msg: KDC_Request) &priority=5
- 		return;
- 
- 	c$krb$request_type = "TGS";
--	c$krb$service = msg$service_name;
-+	if ( msg?$service_name )
-+		c$krb$service = msg$service_name;
- 	if ( msg?$from ) 
- 		c$krb$from = msg$from;
- 	c$krb$till = msg$till;
diff -Nru bro-2.5.5/debian/patches/0007-Fix-IRC-names-command-parsing.patch bro-2.5.5/debian/patches/0007-Fix-IRC-names-command-parsing.patch
--- bro-2.5.5/debian/patches/0007-Fix-IRC-names-command-parsing.patch	2019-06-25 21:24:57.0 +0200
+++ bro-2.5.5/debian/patches/0007-Fix-IRC-names-command-parsing.patch	1970-01-01 01:00:00.0 +0100
@@ -1,35 +0,0 @@
-From: Jon Siwek 
-Date: Wed, 12 Sep 2018 19:47:57 -0500
-Subject: Fix IRC names command parsing
-

-
-Stripped files:
- testing/btest/Traces/irc-353.pcap
- testing/btest/scripts/base/protocols/irc/names-weird.bro
- testing/btest/Baseline/scripts.base.protocols.irc.names-weird/weird.log
-

-
-diff --git a/src/analyzer/protocol/irc/IRC.cc b/src/analyzer/protocol/irc/IRC.cc
-index a26045f..de8846c 100644
 a/src/analyzer/protocol/irc/IRC.cc
-+++ b/src/analyzer/protocol/irc/IRC.cc
-@@ -252,14 +252,15 @@ void IRC_Analyzer::DeliverStream(int length, const u_char* line, bool orig)
- 			{
- 			vector parts = SplitWords(params, ' ');
- 
--			// Remove nick name.
--			parts.erase(parts.begin());
--			if ( parts.size() < 2 )
-+			if ( parts.size() < 3 )
- {
- Weird("irc_invalid_names_line");
- return;
- }
- 
-+			// Remove nick name.
-+			parts.erase(parts.begin());
-+
- 			string type = parts[0];
- 			string channel = parts[1];
diff -Nru bro-2.5.5/debian/patches/series bro-2.5.5/debian/patches/series
--- bro-2.5.5/debian/patches/series	2019-05-11 00:56:50.0 +0200
+++ bro-2.5.5/debian/patches/series	2018-06-17 12:44:48.0 +0200
@@ -3,5 +3,3 @@
 0003-Fix-btest-paths.patch
 0004-Port-most-of-bro-to-OpenSSL-1.1.patch
 0005-Disable-OCSP-features-that-can-t-yet-be-ported-to-Op.patch
-0006-Fix-potential-memory-leak-in-Kerberos-scripts.patch
-0007-Fix-IRC-names-command-parsing.patch


Bug#929011: unblock: singularity-container/3.1.1+ds-1

2019-06-25 Thread Salvatore Bonaccorso
Hi Paul, hi Afif,

On Sat, Jun 08, 2019 at 09:26:06PM +0200, Paul Gevers wrote:
> Control: tags -1 moreinfo
> 
> Hi Afif,
> 
> On Wed, 15 May 2019 03:47:28 -0400 Afif Elghraoui  wrote:
> > Please unblock package singularity-container/3.1.1+ds-1
> > 
> > This package is prone to security vulnerabilities. Upstream provides
> > long-term support for selected versions to their paid users, but also
> > releases all code changes (including backported security patches) to the
> > community.
> > 
> > Both 3.0.x and 3.1.x were released earlier this year and it was not
> > known at the time which of these would be the LTS version. 3.0.3 is what
> > I bet on and what is in Testing now, but it now turns out that I was
> > wrong and it's actually 3.1. Using it would greatly facilitate our
> > ability to provide support over the lifetime of Buster.
> > 
> > The benefits of doing this have also just been clearly demonstrated:
> > Upstream just released 3.2.0, adding new features as well as fixing
> > security issues affecting versions 3.1.0 and up, but because 3.1 is
> > under LTS support for their paid users, they also provided the security
> > patches backported to 3.1 (see the 3.2.0 release notes -
> > https://github.com/sylabs/singularity/releases/tag/v3.2.0 ).
> > 
> > So I apologize for the large diff, but I think we'd be in much better
> > shape having this upstream version in Buster. Especially because of the
> > large diff, backporting patches to 3.0 without the help from upstream
> > that we'd get by using 3.1 would be unnecessarily more burdensome.
> > 
> > many thanks for your time and consideration
> 
> Your proposed changes very much do not align with the freeze policy, so
> you're asking for an exception for a new upstream release. This package
> is currently listed to be auto-removed due to docker.io, so I am not
> going to review it now. docker.io is a major concern for the
> security-team so that needs to be resolved first. If that gets resolved
> in a timely manner, i.e. before it is auto-removed, please ping this bug
> (e.g. by removing the moreinfo bug).

I do agree that the changes are not really reviewable given the size
of the diff. But with Afifs argument and now the package not beeing
marked as autoremoved: if we want to support singularity-container
security wise in buster we would need to bite into the apple and
accept this late new version bump for buster as the 3.1 version.

So I think the two options we have is (in order of preference): 1.
unblock singularity-container and let the 3.1 based version in to
buster, or 2. remove singularity-container from buster.

Cc'in team@s.d.o for further comments.

Regards,
Salvatore



Bug#931087: fdisk/sfdisk: creates scripts that don't work

2019-06-25 Thread Matthias Urlichs
Package: fdisk
Version: 2.33.1-0.1
Severity: important

I have created a GPT-partitioned image where the first partition
needs to start at block 64. The problem is that fdisk/sfdisk is unable to
replicate this partition layout using an sfdisk script, because the
generated script doesn't work when it's read back in.

This seems to be a problem with interpreting the "table-length" value.
It appears to be multiplied by 4 instead of divided by 4 when checking
sector limits.

# ls -l /tmp/bmb_root
-rw-r--r-- 1 smurf smurf 1170228224 Jun 25 22:16 /tmp/bmb_root
# bc
bc 1.07.1
Copyright 1991-1994, 1997, 1998, 2000, 2004, 2006, 2008, 2012-2017 Free 
Software Foundation, Inc.
This is free software with ABSOLUTELY NO WARRANTY.
For details type `warranty'. 
1170228224/512-34
2285568

# cat /tmp/lb  ### minimum/maximum working LBA values
label: gpt
label-id: 3C0E3DAC-3069-354E-BA0E-CB74029F5A5C
device: /tmp/bmb_root
unit: sectors
table-length: 8
first-lba: 34
last-lba: 2285568

# sfdisk /tmp/bmb_root 

Bug#931088: CVE-2019-12481 CVE-2019-12482 CVE-2019-12483

2019-06-25 Thread Moritz Muehlenhoff
Package: gpac
Version: 0.5.2-426-gc5ad4e4+dfsg5-5
Severity: important
Tags: security

Please see
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-12481
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-12482
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-12483

For all three of them:
https://github.com/gpac/gpac/issues/1249
https://github.com/gpac/gpac/commit/f40aaaf959d4d1f7fa0dcd04c0666592e615c8f1

Cheers,
Moritz



Bug#929363: enigmail: CVE-2019-12269

2019-06-25 Thread Moritz Mühlenhoff
On Fri, May 24, 2019 at 09:49:54AM +0200, Salvatore Bonaccorso wrote:
> Source: enigmail
> Source-Version: 2:2.0.11+ds1-1
> 
> On Wed, May 22, 2019 at 02:25:42PM +0200, Salvatore Bonaccorso wrote:
> > Source: enigmail
> > Version: 2:2.0.10+ds1-1
> > Severity: important
> > Tags: security upstream
> > Forwarded: https://sourceforge.net/p/enigmail/bugs/983/
> > 
> > Hi,
> > 
> > The following vulnerability was published for enigmail.
> > 
> > CVE-2019-12269[0]:
> > | Enigmail before 2.0.11 allows PGP signature spoofing: for an inline
> > | PGP message, an attacker can cause the product to display a "correctly
> > | signed" message indication, but display different unauthenticated
> > | text.
> 
> This issue was adressed 2.0.11 upstream, closing manually.

Buster still has 2.0.10, what's the plan for it (and for stretch),
should we fix this in older releases?

Cheers,
Moritz



Bug#929011: unblock: singularity-container/3.1.1+ds-1

2019-06-25 Thread Afif Elghraoui
Control: tag -1 - moreinfo

On June 25, 2019 4:16:17 PM EDT, Salvatore Bonaccorso  wrote:
>Hi Paul, hi Afif,
>
[...]
>> 
>> Your proposed changes very much do not align with the freeze policy,
>so
>> you're asking for an exception for a new upstream release. This
>package
>> is currently listed to be auto-removed due to docker.io, so I am not
>> going to review it now. docker.io is a major concern for the
>> security-team so that needs to be resolved first. If that gets
>resolved
>> in a timely manner, i.e. before it is auto-removed, please ping this
>bug
>> (e.g. by removing the moreinfo bug).
>
>I do agree that the changes are not really reviewable given the size
>of the diff. But with Afifs argument and now the package not beeing
>marked as autoremoved: if we want to support singularity-container
>security wise in buster we would need to bite into the apple and
>accept this late new version bump for buster as the 3.1 version.
>
>So I think the two options we have is (in order of preference): 1.
>unblock singularity-container and let the 3.1 based version in to
>buster, or 2. remove singularity-container from buster.
>
>Cc'in team@s.d.o for further comments.
>

Thanks, Salvatore. I'm removing the moreinfo tag as Paul said to do since the 
autoremoval warning has been lifted.

regards
Afif



  1   2   >