Bug#557702: Typo in package description: "This packages"

[Christopher Hoskin]

Package: monodoc-taglib-manual
Followup-For: Bug #557702

Dear Maintainer,

This was fixed in 2.0.3.4+dfsg-1, commit 
6da6fe2af2346c657968a5d9519807998842346c.

Christopher


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

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

Versions of packages monodoc-taglib-manual depends on:
pn  monodoc-manual  

monodoc-taglib-manual recommends no packages.

monodoc-taglib-manual suggests no packages.

Bug#896253: visionegg is marked for autoremoval from testing

[Andreas Tille]

Control: tags -1 upstream
Control: tags -1 help
Control: forwarded -1 https://github.com/visionegg/visionegg/issues/7

There is an old issue opened upstream[1] which is not answered by
the authors.  Seems this project is dead and may be we need to
drop the package from Debian.

Kind regards

  Andreas.


[1] https://github.com/visionegg/visionegg/issues/7

-- 
http://fam-tille.de

Bug#898975: RFS: lua-moses/1.6.1+git20170613-2

[Lumin]

Package: sponsorship-requests
Severity: normal
X-Debbugs-CC: ti...@debian.org

Dear mentors,

I am looking for a sponsor for my package "lua-moses":

 * Package name: lua-moses
   Version : 1.6.1+git20170613-2
   Upstream Author :
 * URL :
 * License : MIT
   Section : interpreters

The package can be obtained here:

  https://salsa.debian.org/science-team/lua-moses

which has passed all the tests of debomatic-amd64:

  
http://debomatic-amd64.debian.net/distribution#unstable/lua-moses/1.6.1+git20170613-2/buildlog

Changes since the last upload:

  lua-moses (1.6.1+git20170613-2) unstable; urgency=medium
  
* Packaging repo was moved to Science Team (Salsa).
  + Update Vcs-* fields accordingly.
* Maintainer is now Science Team. Move myself to Uploaders.
  + Move myself to Uploaders.
* Install guide docs.
  + Register the docs in doc-base.
* Add support for lua 5.3
  + Also lua5.3 tests in autopkgtest control file.
* Bump Standards-Version to 4.1.4 (no changes).
* Mark the package as Multi-Arch: foreign because it contains no
  arch-dep file.



signature.asc
Description: PGP signature

Bug#896921: [Pkg-salt-team] Bug#896921: Salt 2017.7.5 has been released

[Dirk Heinrichs]

Am 15.05.2018 um 17:51 schrieb Dirk Heinrichs:
> Am 15.05.2018 um 10:23 schrieb Benjamin Drung:
>> It could, but fix was merged after the release of 2017.7.5. So I am
>> waiting for the release of of 2017.7.6/2018.3.1 that include the fix. 
> Ah, OK.

BTW: Which version are you planning to use, then? 2017 or 2018?

Bye...

    Dirk

-- 
Dirk Heinrichs 
GPG Public Key: D01B367761B0F7CE6E6D81AAD5A2E54246986015
Sichere Internetkommunikation: http://www.retroshare.org
Privacy Handbuch: https://www.privacy-handbuch.de




signature.asc
Description: OpenPGP digital signature

Bug#898974: RFS: ibus-keymagic/1.5.2 [ITP. NMU] -- friendly greeter

[Ko Ko Ye`]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

  I am looking for a sponsor for my package "ibus-keymagic"

Package name: ibus-keymagic
Version : 1.5.2
Upstream Author : kokoye2007 
URL :  keymagic.net
License : gpl2
Section : utils

  It builds those binary packages:

ibus-keymagic - keymagic engine for IBus

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

  https://mentors.debian.net/package/ibus-keymagic


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

dget -x
https://mentors.debian.net/debian/pool/main/i/ibus-keymagic/ibus-keymagic_1.5.2.dsc

  More information about hello can be obtained from keymagic.net


  Changes since the last upload:

https://code.launchpad.net/~kokoye2007/+junk/ibus-keymagic
https://code.launchpad.net/~kokoye2007/+recipe/ibus-keymagic


  Regards,
   kokoye2007



--

with regards Ko Ko Ye`

+95 97989 22022
+95 94500 22022
+95 9731 47907
kokoye2...@gmail.com
kokoye2...@ubuntu.com

skype: kokoye2007
jitsi: kokoye2007

http://ubuntu-mm.net
http://wiki.ubuntu.com/kokoye2007
http://wiki.ubuntu.com/MyanmarTeam http://loco.ubuntu.com/teams/ubuntu-mm

Bug#898973: RFS: fonts-myanmar/1.0-1 [ITP] -- we need approve upstream fonts

[kokoye2007]

Package: sponsorship-requests
Severity: wishlist

Dear Maintainer, Developer and Contributor

  I am looking for a sponsor for my package "fonts-myanmar"

 * Package name: fonts-myanmar
   Version : 1.0-1
   Upstream Author : kokoye2007 
 * URL : https://salsa.debian.org/kokoye2007-guest/font-myanmar
 * License : gpl2
   Section : fonts

  It builds those binary packages:

fonts-myanmar - ttf myanmar fonts:
 fonts-myanmar-angoun - myanmar fonts: angoun;
 fonts-myanmar-ayar - ttf myanmar fonts: ayar;
 fonts-myanmar-chatu - myanmar fonts: chatu;
 fonts-myanmar-chatulight - myanmar fonts: chatulight;
 fonts-myanmar-gantgaw - myanmar fonts: gantgaw;
 fonts-myanmar-khyay - myanmar fonts: khyay;
 fonts-myanmar-kuttar - myanmar fonts: kuttar;
 fonts-myanmar-mon - myanmar fonts: MON3 Anonta 1 ;
 fonts-myanmar-myanmar3 - ttf myanmar fonts: Myanmar3;
 fonts-myanmar-myanmarcensus - ttf myanmar fonts: MyanmarCensus;
 fonts-myanmar-myanmarsanspro - myanmar fonts: Myanmar Sans Pro;
 fonts-myanmar-namkhome - myanmar fonts: Namkhone;
 fonts-myanmar-nayone - myanmar fonts: nayone;
 fonts-myanmar-njaun - myanmar fonts: njaun;
 fonts-myanmar-pauklay - myanmar fonts: pauklay;
 fonts-myanmar-phetsot - myanmar fonts: phetsot;
 fonts-myanmar-phiksel - myanmar fonts: phiksel;
 fonts-myanmar-phikselsmooth - myanmar fonts: phikselsmooth;
 fonts-myanmar-ponenyet - myanmar fonts: ponenyet;
 fonts-myanmar-pyidaungsu - ttf myanmar fonts: Pyidaungsu;
 fonts-myanmar-sabae - myanmar fonts: sabae;
 fonts-myanmar-sagar - myanmar fonts: sagar;
 fonts-myanmar-sanpya - myanmar fonts: sanpya;
 fonts-myanmar-squarelight - myanmar fonts: squarelight;
 fonts-myanmar-tagu - myanmar fonts: tagu;
 fonts-myanmar-thuriya - myanmar fonts: thuriya;
 fonts-myanmar-unicode - ttf myanmar unicode fonts
 fonts-myanmar-waso - myanmar fonts: waso;
 fonts-myanmar-yinmar - myanmar fonts: yinmar;
 fonts-myanmar-zawgyi - ttf myanmar fonts: ZawgyiOne2008;

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

  https://mentors.debian.net/package/fonts-myanmar


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

dget -x 
https://mentors.debian.net/debian/pool/main/f/fonts-myanmar/fonts-myanmar_1.0-1.dsc
 
more info or old launchpad ppa at 
launchpad.net/ttf-myanmar-fonts
https://code.launchpad.net/~kokoye2007/ttf-burmese-fonts/font-myanmar

https://code.launchpad.net/~kokoye2007/+archive/ubuntu/ppa/+build/14848226

please check for me and our country and ethnics.
advices and allow to upstram with sponsor

with DFSG regards and respect

Ko Ko Ye
kokoye2007
wiki.ubuntu.com/kokoye2007

Bug#898972: ITP: multimc -- An unofficial program to manage Minecraft instances with ease

[Zebulon McCorkle]

Package: wnpp
Severity: wishlist
Owner: Zebulon McCorkle 

* Package name: multimc
  Version : 0.6.2
  Upstream Author : Petr Mrázek 
* URL : https://multimc.org/
* License : Apache-2.0
  Programming Lang: C++
  Description : An unofficial program to manage Minecraft instances
with ease

MultiMC is a free, open source launcher for Minecraft. It
allows you to have multiple, cleanly separated instances of
Minecraft (each with their own mods, texture packs, saves, etc)
and helps you manage them and their associated options with a
simple and powerful interface.

About a year ago, I submitted an ITP for MultiMC 0.5.1 (#861615),
but there were a few blocking issues. The main one, copyright,
has been fixed upstream, and I think I've fixed the smaller
ones. I'm submitting a new ITP under a new email which I
intend to use for further Linux-related development. If this
is an issue, I can close this issue and go back to the other
ITP.

Since this is my first package, I will be needing a sponsor.
I'm going to post the package to mentors very soon; it builds
and runs, I just need to do some finishing touches (fix some
lintian issues).

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

Bug#898971: tesseract: FTBFS on Debian stretch: tesseract-ocr-eng build-dep should be versioned

[Paul Wise]

Source: tesseract
Version: 4.00~git2439-c3ed6f03-1
Severity: normal

tesseract fails to build on Debian stretch because the
tesseract-ocr-eng build-dep needs to be versioned so that
the right version of it is installed.

...
make[1]: Entering directory '/build/tesseract-4.00~git2439-c3ed6f03'
./src/api/tesseract ./testing/phototest.tif - -
Error opening data file /usr/share/tesseract-ocr/4.00/tessdata/eng.traineddata
Please make sure the TESSDATA_PREFIX environment variable is set to your 
"tessdata" directory.
Failed loading language 'eng'
Tesseract couldn't load any languages!
Could not initialize tesseract.
debian/rules:34: recipe for target 'override_dh_auto_test' failed
make[1]: *** [override_dh_auto_test] Error 1
make[1]: Leaving directory '/build/tesseract-4.00~git2439-c3ed6f03'
debian/rules:19: recipe for target 'build' failed
make: *** [build] Error 2
dpkg-buildpackage: error: debian/rules build gave error exit status 2
...

$ dpkg -L tesseract-ocr-eng | grep eng.traineddata
/usr/share/tesseract-ocr/tessdata/eng.traineddata

$ grep ocr-eng debian/control 
   xsltproc, docbook-xsl, docbook-xml, tesseract-ocr-eng
 tesseract-ocr-eng (>= 4.00~), tesseract-ocr-osd (>= 4.00~), libtesseract4 (>= 
4.00~)
tesseract-ocr-deu, tesseract-ocr-ell, tesseract-ocr-eng, 
tesseract-ocr-fin,

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#814590: closed by Yangfl <mmyan...@gmail.com> ()

[Yangfl]

On Mon, 23 Apr 2018 13:48:58 +0200 Enrico Zini  wrote:
> On Mon, Apr 23, 2018 at 11:33:03AM +, Debian Bug Tracking System wrote:
>
> > Too old; incompleted.
>
> hello, thanks for looking after this bug.
>
> What do you mean with "Too old; incompleted." ?
>
>
> Enrico
>
> --
> GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini 
>
>

Maybe you've missed some messages; see
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=814590#10 .

Please let me know if you have any further information.

BR.

Bug#898969: dnssec-trigger: fails with OpenSSL in experimental due to too-small key

[Diane Trout]

Thank you for the detailed bug report.

I'll need to think a bit about the maintainer script...



On Fri, 2018-05-18 at 01:27 +, brian m. carlson wrote:
> Package: dnssec-trigger
> Version: 0.15+repack-1
> Severity: important
> 
> I have two existing installations of dnssec-trigger that have 1536-
> bit
> client and server keys.  I'm using the OpenSSL from experimental,
> which
> rejects keys of less than 2048 bits in size, as they are presently
> considered too weak.  Consequently, dnssec-trigger fails to start:
> 
> May 18 01:16:15 genre dnssec-triggerd[721856]: May 18 01:16:15
> dnssec-triggerd[721856] error: Error for server-cert-file:
> /etc/dnssec-trigger/dnssec_trigger_server.pem
> May 18 01:16:15 genre dnssec-triggerd[721856]: May 18 01:16:15
> dnssec-triggerd[721856] error: Error in SSL_CTX use_certificate_file
> crypto error:140AB18F:SSL routines:SSL_CTX_use_certificate:ee key too
> small
> May 18 01:16:15 genre dnssec-triggerd[721856]: May 18 01:16:15
> dnssec-triggerd[721856] error: cannot setup SSL context
> May 18 01:16:15 genre dnssec-triggerd[721856]: May 18 01:16:15
> dnssec-triggerd[721856] fatal error: could not init server
> 
> I noticed the current version of dnssec-trigger uses 3072 bit
> keys.  To
> ensure upgrades continue to work, dnssec-trigger probably needs to
> regenerate the keys if they are too small.
> 
> As a potentially relevant note, I noticed the
> dnssec-triggerd-keygen.service creates the keys in /etc, not
> /etc/dnssec-trigger.
> 
> -- System Information:
> Debian Release: buster/sid
>   APT prefers unstable-debug
>   APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500,
> 'stable'), (1, 'experimental-debug'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 4.15.0-3-amd64 (SMP w/4 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
> LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages dnssec-trigger depends on:
> ii  gir1.2-nm-1.0   1.10.8-1
> ii  libc6   2.27-3
> ii  libgdk-pixbuf2.0-0  2.36.11-2
> ii  libglib2.0-02.56.1-2
> ii  libgtk2.0-0 2.24.32-1
> ii  libldns21.7.0-3+b1
> ii  libssl1.1   1.1.1~~pre6-2
> ii  python3 3.6.5-3
> ii  python3-gi  3.28.2-1
> ii  python3-lockfile1:0.12.2-2
> ii  unbound 1.6.7-1
> 
> dnssec-trigger recommends no packages.
> 
> dnssec-trigger suggests no packages.
> 
> -- Configuration Files:
> /etc/dnssec-trigger/dnssec-trigger.conf changed:
> url: "http://fedoraproject.org/static/hotspot.txt OK"
> url: "http://ster.nlnetlabs.nl/hotspot.txt OK"
> tcp80: 185.49.140.67
> tcp80: 2a04:b900::10:0:0:67
> ssl443: 185.49.140.67
> 7E:CF:B4:BE:B9:9A:56:0D:F7:3B:40:51:A4:78:E6:A6:FD:66:0F:10:58:DC:A8:
> 2E:C0:43:D4:77:5A:71:8A:CF
> ssl443: 2a04:b900::10:0:0:67
> 7E:CF:B4:BE:B9:9A:56:0D:F7:3B:40:51:A4:78:E6:A6:FD:66:0F:10:58:DC:A8:
> 2E:C0:43:D4:77:5A:71:8A:CF
> 
> 
> -- no debconf information
> 

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

Bug#898970: rear should be Archiecture: all

[Francois Gouget]

Package: rear
Version: 2.3+dfsg-1
Severity: normal

Dear Maintainer,

I compared the files of the amd64, i386 and ppc64el binary packages and they 
are 
all strictly identical. Thus the rear package is architecture independent and 
should be marked as such.

That means:
* Setting Architecture: all
* Removing the Multi-Arch tag which becomes irrelevant.


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

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

Versions of packages rear depends on:
ii  attr 1:2.4.47-2+b2
ii  bc   1.07.1-2+b1
ii  binutils 2.30-15
ii  dosfstools   4.1-1
ii  e2fsprogs1.44.1-2
ii  ethtool  1:4.15-1
ii  fdisk2.32-0.1
ii  gawk 1:4.1.4+dfsg-1+b1
ii  iproute2 4.16.0-2
ii  iputils-ping 3:20161105-1
ii  isolinux 3:6.03+dfsg1-2
ii  lsb-release  9.20170808
ii  openssl  1.1.0h-2
ii  parted   3.2-21
ii  syslinux 3:6.03+dfsg1-2
ii  syslinux-common  3:6.03+dfsg1-2
ii  util-linux   2.32-0.1
ii  xorriso  1.4.8-3

Versions of packages rear recommends:
ii  extlinux 3:6.03+dfsg1-2
ii  nfs-common [nfs-client]  1:1.3.4-2.2
ii  rpcbind [portmap]0.2.3-0.6

rear suggests no packages.

-- Configuration Files:
/etc/rear/local.conf [Errno 13] Permission non accordée: '/etc/rear/local.conf'

-- no debconf information

Bug#898528: RFS: FVWM/1:2.6.7-49-gd84d4d4b-1 -- F? Virtual Window Manger

[Jaimos Skriletz]

Another Update:

Lintian spotted a few minor issues, in which I submitted patches to
upstream that have now been merged into the master branch. Rebased the
build of the current master to include these patches. The new git
describe --tags version is now 2.6.7-49-gd84d4d4b.

Since I made the original package a few months ago, there was another
update the standards version. Checked the changes then bumped the
standards version to be current, 4.1.4.

In addition I added debian/upstream/metadata with information about
the fvwm project.

The current package can be found at:

http://fvwmforums.org/fvwm-2.6.7/

I removed the older packages from the above link, as to not cause any confusion.

Thanks for your time,

jaimos

Bug#898969: dnssec-trigger: fails with OpenSSL in experimental due to too-small key

[brian m. carlson]

Package: dnssec-trigger
Version: 0.15+repack-1
Severity: important

I have two existing installations of dnssec-trigger that have 1536-bit
client and server keys.  I'm using the OpenSSL from experimental, which
rejects keys of less than 2048 bits in size, as they are presently
considered too weak.  Consequently, dnssec-trigger fails to start:

May 18 01:16:15 genre dnssec-triggerd[721856]: May 18 01:16:15 
dnssec-triggerd[721856] error: Error for server-cert-file: 
/etc/dnssec-trigger/dnssec_trigger_server.pem
May 18 01:16:15 genre dnssec-triggerd[721856]: May 18 01:16:15 
dnssec-triggerd[721856] error: Error in SSL_CTX use_certificate_file crypto 
error:140AB18F:SSL routines:SSL_CTX_use_certificate:ee key too small
May 18 01:16:15 genre dnssec-triggerd[721856]: May 18 01:16:15 
dnssec-triggerd[721856] error: cannot setup SSL context
May 18 01:16:15 genre dnssec-triggerd[721856]: May 18 01:16:15 
dnssec-triggerd[721856] fatal error: could not init server

I noticed the current version of dnssec-trigger uses 3072 bit keys.  To
ensure upgrades continue to work, dnssec-trigger probably needs to
regenerate the keys if they are too small.

As a potentially relevant note, I noticed the
dnssec-triggerd-keygen.service creates the keys in /etc, not
/etc/dnssec-trigger.

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

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

Versions of packages dnssec-trigger depends on:
ii  gir1.2-nm-1.0   1.10.8-1
ii  libc6   2.27-3
ii  libgdk-pixbuf2.0-0  2.36.11-2
ii  libglib2.0-02.56.1-2
ii  libgtk2.0-0 2.24.32-1
ii  libldns21.7.0-3+b1
ii  libssl1.1   1.1.1~~pre6-2
ii  python3 3.6.5-3
ii  python3-gi  3.28.2-1
ii  python3-lockfile1:0.12.2-2
ii  unbound 1.6.7-1

dnssec-trigger recommends no packages.

dnssec-trigger suggests no packages.

-- Configuration Files:
/etc/dnssec-trigger/dnssec-trigger.conf changed:
url: "http://fedoraproject.org/static/hotspot.txt OK"
url: "http://ster.nlnetlabs.nl/hotspot.txt OK"
tcp80: 185.49.140.67
tcp80: 2a04:b900::10:0:0:67
ssl443: 185.49.140.67 
7E:CF:B4:BE:B9:9A:56:0D:F7:3B:40:51:A4:78:E6:A6:FD:66:0F:10:58:DC:A8:2E:C0:43:D4:77:5A:71:8A:CF
ssl443: 2a04:b900::10:0:0:67 
7E:CF:B4:BE:B9:9A:56:0D:F7:3B:40:51:A4:78:E6:A6:FD:66:0F:10:58:DC:A8:2E:C0:43:D4:77:5A:71:8A:CF


-- no debconf information

-- 
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204


signature.asc
Description: PGP signature

Bug#898968: obuild: FTBFS on byte-code architectures

[Ralf Treinen]

Source: ocaml-obuild
Version: 0.1.10-1
Severity: wishlist

obuild fails [1] to build on architectures that do not have a native-code
compiler:

   dh_update_autotools_config -a
   dh_ocamlinit -a
   debian/rules override_dh_auto_build
make[1]: Entering directory '/<>'
./bootstrap
./bootstrap: line 10: ocamlopt: command not found

Since ocaml-obuild is new in the archive this is only a wishlist bug.
However, it seems reasonable to expect from a compilation tool to be
available on any architecture.

-Ralf.

[1] 
https://buildd.debian.org/status/fetch.php?pkg=ocaml-obuild=armel=0.1.10-1=1526588473=0

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

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

Bug#755185: consider update, or possibly replace with webapp

[Mario Frasca]

https://mentors.debian.net/package/bauble
now according to the rules, I trust.

Bug#898948: ncurses-base: include rxvt-unicode-256color terminfo entry

[Thomas Dickey]

On Thu, May 17, 2018 at 07:31:40PM +0200, Sven Joachim wrote:
> Package: ncurses-base
> Version: 6.1+20180210-3
> Severity: wishlist
> 
> The rxvt-unicode package in buster/sid defaults to
> TERM=rxvt-unicode-256color.  This has annoyed some users (see #886465),
> as this terminfo entry is not in ncurses-base.  Moreover, rxvt-unicode
> is the successor of some other once popular packages like rxvt and aterm
> (see #848284), so I think rxvt-unicode-256color should be added to
> ncurses-base.
> 
> Including rxvt-unicode-256color in ncurses-base has also been requested
> in Fedora: https://bugzilla.redhat.com/show_bug.cgi?id=1430935.  The
> only objection there is that Fedora's rxvt-unicode package ships the
> terminfo entry itself, but we do not have this file conflict in Debian.

You forgot to mention the basic problem:

https://invisible-island.net/ncurses/ncurses-urxvt.html

-- 
Thomas E. Dickey 
https://invisible-island.net
ftp://ftp.invisible-island.net


signature.asc
Description: Digital signature

Bug#898967: RFP: octave-scicosim -- Toolbox provides the functions for variable exchange between Octave and Scilab workspaces, and for the remote commands execution in Scilab, such as starting xcos si

[Alessandro Barbieri]

Package: wnpp
Severity: wishlist

* Package name: octave-scicosim
  Version : 0.1.3
  Upstream Author : Romanov Alexey roma...@mirea.ru
* URL : https://wiki.octave.org/Sci_cosim
* License : New BSD
  Programming Lang: Octave
  Description : Toolbox provides the functions for variable exchange 
between Octave and Scilab workspaces, and for the remote commands execution in 
Scilab, such as starting xcos simulation.

The main goal of this toolbox is to make an alternative for Simulink in Octave 
from Scilab xcos. But it can be also used to uses functions from Scilab 
toolboxes, that are unavailable for Octave. 

Bug#898165: Regression in [v2] nfs: Fix ugly referral attributes ?

[Moritz Schlarb]

Hi Chuck,

On 17.05.2018 16:15, Chuck Lever wrote:

> Just a shot in the dark: Wondering if v3.16 needs
> 
> commit ea96d1ecbe4fcb1df487d99309d3157b4ff5fc02
> Author: Anna Schumaker 
> AuthorDate: Fri Apr 3 14:35:59 2015 -0400
> Commit: Trond Myklebust 
> CommitDate: Thu Apr 23 14:43:54 2015 -0400
> 
> nfs: Fetch MOUNTED_ON_FILEID when updating an inode

Gosh, it seems you're right!
When I take that patch and apply it, the referrals are being followed again!

Thanks for your idea!
Now how do we make sure it gets applied soonish?

Regards,
Moritz

Bug#898966: RFS: bauble/1.0.56-1 (#755185)

[Mario Frasca]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I'm looking for a sponsor for my package 'bauble'.

'bauble' has one important bug report, 755185, and the package I have
just produces should solve that issue.

I have been in contact with the current/previous package maintainer,
Giacomo Catenazzi, and he agrees in handling packaging responsibility
over to me.  At the moment I'm both maintainer of the upstream and of the
Debian package.  

This, and `fibra` would be my first packages in Debian.  `bauble` needs `fibra`.

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

  https://mentors.debian.net/package/bauble
  https://mentors.debian.net/package/fibra

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

  dget -x 
https://mentors.debian.net/debian/pool/main/b/bauble/bauble_1.0.56-1.dsc

* More information about bauble can be obtained from https://bauble.io

* Changes since the last upload:
  (last upload, 0.9.7, was produced almost 10 years ago)

  updated dependecies 
  added dependencies

  Regards,
  Mario Frasca

I see from the report at https://mentors.debian.net/package/bauble that
your online system reports more problems than `lintian`.  I would be very
happy to remove those errors, with some help from some available mentor.


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

Kernel: Linux 4.9.0-6-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)

Bug#898891: firejail-profiles: firejail --name=... can no longer be used with the firefox profile

[Vincent Lefevre]

On 2018-05-17 22:46:05 +0200, Reiner Herrmann wrote:
> I've tried this as well. Started a firefox session with the script, then
> opened another tab by calling the script again with a URL as parameter.
> It opens the tab and the script immediately exits, but with exit status 0.

I've tried on a second machine, with a new Firefox profile.
Without using firejail or with firejail-profiles 0.9.52-3,
I get no errors, but with firejail-profiles 0.9.54-1, I can
still reproduce the failure of the second instance.

I can also reproduce the failure when using firefox 60.0-1
instead of firefox-esr 52.8.0esr-1.

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

Bug#898965: eperl: FTBFS with perl 5.27: Perl runtime error (interpreter rc=256)

[Dominic Hargreaves]

Source: eperl
Version: 2.2.14-22
Severity: important

In the process of test-building packages against the next version of
perl (5.27.11, to be released as 5.28.0) we found the following failure
in eperl:

make[3]: Entering directory '/<>/t'
ePerl:Error: Perl runtime error (interpreter rc=256)
cmp: EOF on tmp.01 which is empty
01-plain.t . 
Failed 2/2 subtests 
ePerl:Error: Perl runtime error (interpreter rc=256)
ePerl:Error: Perl runtime error (interpreter rc=256)
cmp: EOF on tmp.03 which is empty
02-empty.t . 
Failed 1/2 subtests 
ePerl:Error: Perl runtime error (interpreter rc=256)
cmp: EOF on tmp.03 which is empty
ePerl:Error: Perl runtime error (interpreter rc=256)
cmp: EOF on tmp.04 which is empty
ePerl:Error: Perl runtime error (interpreter rc=256)
cmp: EOF on tmp.05 which is empty
03-mode_filter.t ... 
Failed 5/6 subtests 
04-mode_cgi.t .. 
Failed 3/6 subtests 
05-mode_nphcgi.t ... 
Failed 3/6 subtests 
06-mode_shebang.t .. 
Failed 2/3 subtests 
ePerl:Error: Perl runtime error (interpreter rc=256)
cmp: EOF on tmp.02 which is empty
07_defines.t ... 
Failed 2/2 subtests 
ePerl:Error: Perl runtime error (interpreter rc=256)
cmp: EOF on tmp.01 which is empty
08_preprocessor.t .. 
Failed 2/2 subtests 
ePerl:Error: Perl runtime error (interpreter rc=256)
09_dynaloader.t  
Failed 1/1 subtests 

Test Summary Report
---
01-plain.t   (Wstat: 0 Tests: 2 Failed: 2)
  Failed tests:  1-2
02-empty.t   (Wstat: 0 Tests: 2 Failed: 1)
  Failed test:  2
03-mode_filter.t (Wstat: 0 Tests: 6 Failed: 5)
  Failed tests:  1-4, 6
04-mode_cgi.t(Wstat: 0 Tests: 6 Failed: 3)
  Failed tests:  2, 4, 6
05-mode_nphcgi.t (Wstat: 0 Tests: 6 Failed: 3)
  Failed tests:  2, 4, 6
06-mode_shebang.t (Wstat: 0 Tests: 3 Failed: 2)
  Failed tests:  2-3
07_defines.t (Wstat: 0 Tests: 2 Failed: 2)
  Failed tests:  1-2
08_preprocessor.t (Wstat: 0 Tests: 2 Failed: 2)
  Failed tests:  1-2
09_dynaloader.t  (Wstat: 0 Tests: 1 Failed: 1)
  Failed test:  1
Files=9, Tests=30,  2 wallclock secs ( 0.01 usr  0.01 sys +  0.06 cusr  0.00 
csys =  0.08 CPU)
Result: FAIL
Failed 9/9 test programs. 21/30 subtests failed.

The complete log, should it be of interest, is at



This bug will become RC nearer the time of the perl 5.28 transition
which is yet to be scheduled.

If you need to test on perl 5.27, please have a look at
 for a test repository.

Cheers,
Dominic.

Bug#898964: mrs: FTBFS: you don't seem to have log4cpp installed

[Dominic Hargreaves]

Source: mrs
Version: 6.0.5+dfsg-5
Severity: serious

Whilst test-rebuilding packages for the next perl release we found
an unrelated build failure:

Checking for liblog4cpp...

Cannot continue since you don't seem to have log4cpp installed
Please install the log4cpp-dev package and run configure again.
make[1]: *** [debian/rules:11: override_dh_auto_configure] Error 2

The full log is here:



This seems likely to be caused by the new release of log4cpp 1.1.3-1
last week.

Cheers,
Dominic.

Bug#898960: [libpangoft2-1.0-0] Crashes some Java applications in pango_fc_font_key_get_variations

[Jeremy Bicha]

Control: tags -1 moreinfo

On Thu, May 17, 2018 at 4:37 PM,   wrote:
> Some applications suddenly crash

Please list specific applications that crash so that we can try to
duplicate the issue here.

> Debian Release: buster/sid
>   500 unstablewww.deb-multimedia.org

I've seen several examples recently where installing packages from the
deb-multimedia repo breaks Debian. For instance,
https://bugs.debian.org/897226

Thanks,
Jeremy Bicha

Bug#898356: git-buildpackage: Multiple --git-pbuilder-options do not stack

[Guido Günther]

On Thu, May 17, 2018 at 10:34:30PM +0200, Matthijs Kooijman wrote:
> Hi Guido,
> 
> >   --git-pbuilder-options-append="option1" 
> > --git-pbuilder-options-append="option2"
> > 
> > so you can decide on a per option basis if you want to append to the
> > currently set value. Each "--git-pbuilder-options" would reset the whole
> > thing and start over so:
> > 
> >   --git-pbuilder-options="foo" --git-pbuilder-options-append="option1" 
> > --git-pbuilder-options-append="option2"
> Ah, that is *exactly* what I meant. I just named the options differently
> and apparently failed to express my intent. Thanks for providing some
> clarifying examples :-)

...now we need patches to make this reality ;)
 -- Guido

Bug#898963: osc: diff for NMU version 0.162.1-1.1

[Simon McVittie]

Package: osc
Version: 0.162.1-1
Severity: normal
Tags: patch pending
Control: tags 895035 + patch pending
Control: tags 898775 + patch pending

Hi,
I needed to build a working osc for $work, so I've prepared an NMU for
osc (versioned as 0.162.1-1.1) and uploaded it to DELAYED/7. Please feel
free to tell me if I should change the delay or cancel it.

The build tool I use is pedantic about Policy §7.7, so I had to fix
#898775 as well as #895035 to be able to NMU.

Regards,
smcv

diffstat for osc-0.162.1 osc-0.162.1

 changelog|   15 +++
 control  |   12 +--
 patches/Disable-ssl-session-resumption.patch |  105 +++
 patches/series   |1 
 4 files changed, 127 insertions(+), 6 deletions(-)

diff -Nru osc-0.162.1/debian/changelog osc-0.162.1/debian/changelog
--- osc-0.162.1/debian/changelog	2018-01-23 08:47:02.0 +
+++ osc-0.162.1/debian/changelog	2018-05-17 21:48:13.0 +0100
@@ -1,3 +1,18 @@
+osc (0.162.1-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Merge Build-Depends-Indep into Build-Depends. The python2 and
+bash-completion debhelper sequences are needed for the clean target
+when building a source package, but that target is only guaranteed to
+have the Build-Depends available; and python-urlgrabber turns out to
+also be needed during clean, because it's indirectly imported
+by setup.py. (Closes: #898775)
+  * d/p/Disable-ssl-session-resumption.patch:
+Add patch from upstream fixing a segfault when used with
+libssl1.1 (>= 1.1.0h) (Closes: #895035)
+
+ -- Simon McVittie   Thu, 17 May 2018 21:48:13 +0100
+
 osc (0.162.1-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru osc-0.162.1/debian/control osc-0.162.1/debian/control
--- osc-0.162.1/debian/control	2018-01-23 08:46:42.0 +
+++ osc-0.162.1/debian/control	2018-05-17 21:48:13.0 +0100
@@ -3,12 +3,12 @@
 Uploaders: Michal Čihař 
 Section: devel
 Priority: optional
-Build-Depends: debhelper (>= 9),
-   dh-exec
-Build-Depends-Indep: python,
- python-urlgrabber,
- dh-python,
- bash-completion
+Build-Depends: bash-completion,
+   debhelper (>= 9),
+   dh-exec,
+   dh-python,
+   python,
+   python-urlgrabber
 Standards-Version: 4.1.3
 Vcs-Browser: https://anonscm.debian.org/git/pkg-rpm/osc.git
 Vcs-Git: https://anonscm.debian.org/git/pkg-rpm/osc.git
diff -Nru osc-0.162.1/debian/patches/Disable-ssl-session-resumption.patch osc-0.162.1/debian/patches/Disable-ssl-session-resumption.patch
--- osc-0.162.1/debian/patches/Disable-ssl-session-resumption.patch	1970-01-01 01:00:00.0 +0100
+++ osc-0.162.1/debian/patches/Disable-ssl-session-resumption.patch	2018-05-17 21:48:13.0 +0100
@@ -0,0 +1,105 @@
+From: Marcus Huewe 
+Date: Tue, 8 May 2018 14:23:08 +0200
+Subject: Disable ssl session resumption
+
+The old code could potentially yield to a use-after-free situation,
+which results in UB. For this, consider the following scenario, where
+osc performs several HTTPS requests (assumption: the server supports
+ssl session resumption):
+
+- HTTPS Request 1:
+  * a new SSL *s connection is established, which also creates a new
+SSL_SESSION *ss => ss->references == 1
+  * once the handshake is done, the ss is put into the session cache
+(see ssl_update_cache) => ss->references == 2
+  - osc saves the session ss in a class variable
+  - s is SSL_free()d, which calls SSL_SESSION_free => ss->references == 1
+
+- HTTPS Request 2:
+  * setup a new SSL *s connection that reuses the saved session ss
+=> ss->references == 2
+  * once the handshake is done, ssl_update_cache is called, which is a
+NOP, because s->hit == 1 (that is, the session was resumed)
+  * osc saves the session ss in a class variable
+  * s is SSL_free()d, which calls SSL_SESSION_free => ss->references == 1
+
+...
+
+> 2 hours later (see tls1_default_timeout)
+
+...
+
+- HTTPS Request 256:
+  * setup a new SSL *s connection that reuses the saved session ss
+=> ss->references == 2
+  * once the handshake is done, ssl_update_cache is called, but is
+_no_ NOP anymore
+  * ssl_update_cache flushes the session cache (this is done every
+255/256 (depending on the way we count) connections) => ss is
+SSL_SESSION_free()d => ss->references == 1
+  * osc saves the session ss in a class variable
+  * s is SSL_free()d, which calls SSL_SESSION_free:
+since ss->references == 1, ss is eventually free()d
+
+- HTTPS Request 257:
+  * setup a new SSL *s connection that reuses the saved session ss
+
+Since ss does not exist anymore, the remaining program execution is UB.
+
+(Note: SSL_free(...) is _NOT_ called, if M2Crypto 0.29 is used.
+M2Crypto 0.30 calls SSL_free(...) 

Bug#898961: dscverify: accept .buildinfo from a build with unsigned .dsc which later was signed

[Thorsten Glaser]

Package: devscripts
Version: 2.18.2
Severity: minor

When I build a package for uploading into Debian (i.e. no --binary-arch)
a .buildinfo file gets generated which contains the checksum of the .dsc
file, which at that time is unsigned.

When I later debsign, the .dsc file is signed alongside with the .changes
file; however, the .buildinfo file contains the hashes of the .dsc file.
(I could omit the .buildinfo file or regenerate it, but since .changes
also includes .buildinfo signature this becomes annoying really fast.)

Please just check the .dsc checksum in a .buildinfo file, during verifi‐
cation of the latter, also against the .dsc file contents with the sig‐
nature stripped *IFF* the .dsc file itself is signed *and* passes signa‐
ture checking.

Thanks!


-- Package-specific info:

--- /etc/devscripts.conf ---

--- ~/.devscripts ---
DEBCHANGE_AUTO_NMU=no
DEBCHANGE_MAINTTRAILER=no
DEBCHANGE_MULTIMAINT_MERGE=yes
DEBCHANGE_RELEASE_HEURISTIC=log

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

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

Versions of packages devscripts depends on:
ii  dpkg-dev  1.19.0.5
ii  libc6 2.27-3
ii  libfile-homedir-perl  1.002-1
ii  perl  5.26.2-3
ii  python3   3.6.5-3
ii  sensible-utils0.0.12

Versions of packages devscripts recommends:
ii  apt 1.6.1
ii  at  3.1.20-5
ii  curl7.58.0-2
ii  dctrl-tools 2.24-2+b1
ii  debian-keyring  2018.03.24
ii  dput1.0.2
ii  equivs  2.1.0
ii  fakeroot1.22-2
ii  file1:5.33-2
ii  gnupg   2.2.5-1
ii  gnupg2  2.2.5-1
pn  libdistro-info-perl 
ii  libdpkg-perl1.19.0.5
ii  libencode-locale-perl   1.05-1
pn  libgit-wrapper-perl 
pn  liblist-compare-perl
ii  liblwp-protocol-https-perl  6.07-2
pn  libsoap-lite-perl   
pn  libstring-shellquote-perl   
ii  liburi-perl 1.74-1
ii  libwww-perl 6.33-1
pn  licensecheck
ii  lintian 2.5.86
ii  man-db  2.8.3-2
ii  patch   2.7.6-2
ii  patchutils  0.3.4-2
ii  python3-apt 1.6.0
ii  python3-debian  0.1.32
ii  python3-magic   2:0.4.15-1
ii  python3-requests2.18.4-2
pn  python3-unidiff 
pn  python3-xdg 
ii  strace  4.21-1
ii  unzip   6.0-21
ii  wdiff   1.2.2-2+b1
ii  wget1.19.5-1
ii  xz-utils5.2.2-1.3

Versions of packages devscripts suggests:
ii  adequate  0.15.1
pn  autopkgtest   
pn  bls-standalone
ii  bsd-mailx [mailx] 8.1.2-0.20160123cvs-4
ii  build-essential   12.5
pn  check-all-the-things  
pn  cvs-buildpackage  
pn  devscripts-el 
ii  diffoscope94
pn  disorderfs
pn  dose-extra
pn  duck  
pn  faketime  
pn  gnuplot   
ii  gpgv  2.2.5-1
pn  how-can-i-help
pn  libauthen-sasl-perl   
pn  libfile-desktopentry-perl 
pn  libnet-smtps-perl 
pn  libterm-size-perl 
ii  libtimedate-perl  2.3000-2
ii  libyaml-syck-perl 1.30-1
pn  mozilla-devscripts
pn  mutt  
ii  openssh-client [ssh-client]   1:7.7p1-2
pn  piuparts  
ii  postgresql-client-10 [postgresql-client]  10.4-2
ii  quilt 0.63-8.2
pn  ratt  
pn  reprotest 
pn  svn-buildpackage  
ii  w3m   0.5.3-36+b1

-- no debconf information

Bug#898891: firejail-profiles: firejail --name=... can no longer be used with the firefox profile

[Reiner Herrmann]

On Thu, May 17, 2018 at 10:35:31PM +0200, Vincent Lefevre wrote:
> On 2018-05-17 18:49:49 +0200, Reiner Herrmann wrote:
> > I'm currently not able to reproduce it.
> 
> You need to run the firefox script twice: The first one, typically
> with no argument (the goal is to restore and use the previous session).
> The second one with a URL in argument, the goal being to open this URL
> in the running Firefox. It is this second instance that now fails with
> firejail.

I've tried this as well. Started a firefox session with the script, then
opened another tab by calling the script again with a URL as parameter.
It opens the tab and the script immediately exits, but with exit status 0.

I'll ask on the upstream bug tracker if someone has the same issue.


signature.asc
Description: PGP signature

Bug#898960: [libpangoft2-1.0-0] Crashes some Java applications in pango_fc_font_key_get_variations

[gisl]

Package: libpangoft2-1.0-0
Version: 1.42.1-1
Severity: important

--- Please enter the report below this line. ---
Some applications suddenly crash, possibly due to a binary incompatibility?

Stack: [0x7f9388812000,0x7f9388912000],  sp=0x7f9388909488,  free 
space=989k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native 
code)
C  [libpangoft2-1.0.so.0+0xb1e0]  pango_fc_font_key_get_variations+0x0

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
J 13636  org.eclipse.swt.internal.gtk.OS._g_main_context_iteration(JZ)Z (0 
bytes) @ 0x7f937039fac4 [0x7f937039fa80+0x44]
J 69512 C2 org.eclipse.swt.widgets.Display.readAndDispatch()Z (71 bytes) @ 
0x7f9377b26960 [0x7f9377b266a0+0x2c0]
J 51367% C2 org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine
$5.run()V (703 bytes) @ 0x7f93754ee1f4 [0x7f93754edfe0+0x214]
j  org.eclipse.core.databinding.observable.Realm.runWithDefault(Lorg/eclipse/
core/databinding/observable/Realm;Ljava/lang/Runnable;)V+12
j  org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(Lorg/
eclipse/e4/ui/model/application/MApplicationElement;Lorg/eclipse/e4/core/
contexts/IEclipseContext;)Ljava/lang/Object;+57
j  org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(Lorg/
eclipse/e4/ui/model/application/MApplicationElement;)V+20
j  org.eclipse.ui.internal.Workbench.lambda$3(Lorg/eclipse/swt/widgets/
Display;Lorg/eclipse/ui/application/WorkbenchAdvisor;[I)V+451
j  org.eclipse.ui.internal.Workbench$$Lambda$15.run()V+12
j  org.eclipse.core.databinding.observable.Realm.runWithDefault(Lorg/eclipse/
core/databinding/observable/Realm;Ljava/lang/Runnable;)V+12
j  org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Lorg/eclipse/swt/
widgets/Display;Lorg/eclipse/ui/application/WorkbenchAdvisor;)I+16
j  org.eclipse.ui.PlatformUI.createAndRunWorkbench(Lorg/eclipse/swt/widgets/
Display;Lorg/eclipse/ui/application/WorkbenchAdvisor;)I+2
j  org.eclipse.ui.internal.ide.application.IDEApplication.start(Lorg/eclipse/
equinox/app/IApplicationContext;)Ljava/lang/Object;+113
j  org.eclipse.equinox.internal.app.EclipseAppHandle.run(Ljava/lang/
Object;)Ljava/lang/Object;+135
j  
org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(Ljava/
lang/Object;)Ljava/lang/Object;+85
j  org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(Ljava/
lang/Object;)Ljava/lang/Object;+82
j  org.eclipse.core.runtime.adaptor.EclipseStarter.run(Ljava/lang/
Object;)Ljava/lang/Object;+105
j  org.eclipse.core.runtime.adaptor.EclipseStarter.run([Ljava/lang/
String;Ljava/lang/Runnable;)Ljava/lang/Object;+132
v  ~StubRoutines::call_stub
j  sun.reflect.NativeMethodAccessorImpl.invoke0(Ljava/lang/reflect/
Method;Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+0
j  sun.reflect.NativeMethodAccessorImpl.invoke(Ljava/lang/Object;[Ljava/lang/
Object;)Ljava/lang/Object;+100
j  sun.reflect.DelegatingMethodAccessorImpl.invoke(Ljava/lang/Object;[Ljava/
lang/Object;)Ljava/lang/Object;+6
j  java.lang.reflect.Method.invoke(Ljava/lang/Object;[Ljava/lang/
Object;)Ljava/lang/Object;+56
j  org.eclipse.equinox.launcher.Main.invokeFramework([Ljava/lang/String;
[Ljava/net/URL;)V+205
j  org.eclipse.equinox.launcher.Main.basicRun([Ljava/lang/String;)V+160
j  org.eclipse.equinox.launcher.Main.run([Ljava/lang/String;)I+4
j  org.eclipse.equinox.launcher.Main.main([Ljava/lang/String;)V+10

Also see
https://forum.manjaro.org/t/solved-matlab-r2017b-add-ons-and-other-windows-no-effect/35505/5
https://forum.manjaro.org/t/rssowl-crashes-after-last-system-update/45043/16

--- System information. ---
Architecture: 
Kernel:   Linux 4.15.0-3-amd64

Debian Release: buster/sid
  500 unstablewww.deb-multimedia.org 
  500 unstableftp.de.debian.org 

--- Package information. ---
Depends  (Version) | Installed
==-+-
libc6 (>= 2.4) | 
libfontconfig1   (>= 2.12) | 
libfreetype6(>= 2.3.5) | 
libglib2.0-0   (>= 2.37.3) | 
libharfbuzz0b   (>= 1.4.2) | 
libpango-1.0-0 (>= 1.42.0) | 


Package's Recommends field is empty.

Package's Suggests field is empty.

Bug#898356: git-buildpackage: Multiple --git-pbuilder-options do not stack

[Matthijs Kooijman]

Hi Guido,

>   --git-pbuilder-options-append="option1" 
> --git-pbuilder-options-append="option2"
> 
> so you can decide on a per option basis if you want to append to the
> currently set value. Each "--git-pbuilder-options" would reset the whole
> thing and start over so:
> 
>   --git-pbuilder-options="foo" --git-pbuilder-options-append="option1" 
> --git-pbuilder-options-append="option2"
Ah, that is *exactly* what I meant. I just named the options differently
and apparently failed to express my intent. Thanks for providing some
clarifying examples :-)

Gr.

Matthijs


signature.asc
Description: PGP signature

Bug#898891: firejail-profiles: firejail --name=... can no longer be used with the firefox profile

[Vincent Lefevre]

On 2018-05-17 18:49:49 +0200, Reiner Herrmann wrote:
> I'm currently not able to reproduce it.

You need to run the firefox script twice: The first one, typically
with no argument (the goal is to restore and use the previous session).
The second one with a URL in argument, the goal being to open this URL
in the running Firefox. It is this second instance that now fails with
firejail.

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

Bug#898813: telegram-desktop: URI passed to the client via command line is ignored

[Alexander Kernozhitsky]

В письме от четверг, 17 мая 2018 г. 21:45:49 +03 Вы написали:
> Hello,
> 
> 16.05.2018 08:05, Alexander Kernozhitsky пишет:
> > According to `man telegram-desktop` output:
> > 
> > telegram-desktop [-startintray] [-many] [-debug] [-- URI]
> > 
> > we can pass an URI to open a specified chat or a channel inside the
> > application. But it seems that the passed URI is ignored. I looked into
> > the code and noticed that it is parsed by the command line options
> > parser, but is used nowhere else in the code.
> 
> Here it means a user can pass a URI within tg scheme. For example:
> 
> $ telegram-desktop -- tg://resolve?domain=mymedia
> 
> This is exactly the same links used on t.me site for instant open
> Telegram client.

I know this, and I tried to launch telegram using something like this. For 
some strange reason this didn't work for me. Now I checked and it works 
(though I typed the same command).

-- 
-
Alexander Kernozhitsky

Bug#898707: debian/rules build target attempts network access when git is installed

[Thadeu Lima de Souza Cascardo]

Package: crash
Version: 7.2.1-1+b1
Followup-For: Bug #898707

Attaching a debdiff for an NMU fixing the cloning and the cleanup that
still needs a small change in rules even after fixing the cloning
problem.


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

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

Versions of packages crash depends on:
ii  binutils  2.30-20
ii  libc6 2.27-3
ii  liblzo2-2 2.10-0.1
ii  libncurses6   6.1+20180210-3
ii  libsnappy1v5  1.1.7-1
ii  libtinfo6 6.1+20180210-3
ii  zlib1g1:1.2.11.dfsg-1

crash recommends no packages.

Versions of packages crash suggests:
ii  kexec-tools   1:2.0.16-1
ii  makedumpfile  1:1.6.3-2

-- no debconf information
diff -Nru crash-7.2.1/debian/changelog crash-7.2.1/debian/changelog
--- crash-7.2.1/debian/changelog2018-02-16 15:47:33.0 -0200
+++ crash-7.2.1/debian/changelog2018-05-17 16:36:02.0 -0300
@@ -1,3 +1,11 @@
+crash (7.2.1-1.1) unstable; urgency=medium
+
+  * NMU.
+  * Do not git clone eppic extension. (Closes: #898707)
+  * Remove generated files: CFLAGS.extra LDFLAGS.extra extensions/defs.h
+
+ -- Thadeu Lima de Souza Cascardo   Thu, 17 May 2018 
16:36:02 -0300
+
 crash (7.2.1-1) unstable; urgency=medium
 
   * New upstream (closes: #890394)
diff -Nru crash-7.2.1/debian/patches/0001-dont-git-clone-eppic-extension.patch 
crash-7.2.1/debian/patches/0001-dont-git-clone-eppic-extension.patch
--- crash-7.2.1/debian/patches/0001-dont-git-clone-eppic-extension.patch
1969-12-31 21:00:00.0 -0300
+++ crash-7.2.1/debian/patches/0001-dont-git-clone-eppic-extension.patch
2018-05-17 16:35:18.0 -0300
@@ -0,0 +1,25 @@
+From: Thadeu Lima de Souza Cascardo 
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=898707
+Origin: vendor, 
+Forwarded: not-needed
+Last-Update: 2018-05-17
+Description: Build targets shoult not attempt network access
+ When git is installed, the eppic extensions makefile will try to access
+ github.com to clone the extension code.
+
+ This patch simply fails to find the git binary by adding an extra
+ false condition to minimize the delta size.
+
+Index: crash-7.2.1/extensions/eppic.mk
+===
+--- crash-7.2.1.orig/extensions/eppic.mk
 crash-7.2.1/extensions/eppic.mk
+@@ -33,7 +33,7 @@ all:
+ then \
+ if  [ ! -f $(APPFILE) ]; \
+ then \
+-  if [ -f "$(GIT)" ]; \
++  if [ -f "$(GIT)" -a 0 -gt 1 ]; \
+   then \
+  if [ -n "$(EPPIC_GIT_URL)" ]; then \
+git clone "$(EPPIC_GIT_URL)" eppic; \
diff -Nru crash-7.2.1/debian/patches/series crash-7.2.1/debian/patches/series
--- crash-7.2.1/debian/patches/series   2018-02-16 15:47:18.0 -0200
+++ crash-7.2.1/debian/patches/series   2018-05-17 16:27:08.0 -0300
@@ -0,0 +1 @@
+0001-dont-git-clone-eppic-extension.patch
diff -Nru crash-7.2.1/debian/rules crash-7.2.1/debian/rules
--- crash-7.2.1/debian/rules2018-02-16 15:47:18.0 -0200
+++ crash-7.2.1/debian/rules2018-05-17 16:36:02.0 -0300
@@ -27,6 +27,9 @@
rm -Rf $(CURDIR)/gdb.files
rm -Rf $(CURDIR)/build_data.c
rm -Rf $(CURDIR)/extensions/*.so
+   rm -Rf $(CURDIR)/CFLAGS.extra
+   rm -Rf $(CURDIR)/LDFLAGS.extra
+   rm -Rf $(CURDIR)/extensions/defs.h
 
 override_dh_auto_install:
dh_auto_install

Bug#898959: libreoffice: "Edit>Track Changes" submenu "Record" and "Show" options don't indicate state

[Daniel Kahn Gillmor]

Package: libreoffice
Version: 1:6.0.4~rc1-4
Severity: normal

The Edit menu's "Track Changes" option shows a submenu with two entries
that allow toggling of state:

 * Record
 * Show

See the attached image:


However, from looking at the menu, i cannot tell which state the menu
items are in.

So for a document that doesn't have any changes recorded, i have to
guess at which items need to be clicked in order to get the changes to
be recorded and shown.  Perhaps these icons need some sort of stateful
indicator (a checkmark?) instead of their icons?

I note that these menu items are in some way related to "View¨ menu's
"Track Changes" option, but i don't know what the relationship is.

Thanks for maintaining LibreOffice in debian!

   --dkg

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

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

Versions of packages libreoffice depends on:
ii  libreoffice-avmedia-backend-gstreamer  1:6.0.4~rc1-4
ii  libreoffice-base   1:6.0.4~rc1-4
ii  libreoffice-calc   1:6.0.4~rc1-4
ii  libreoffice-core   1:6.0.4~rc1-4
ii  libreoffice-draw   1:6.0.4~rc1-4
ii  libreoffice-impress1:6.0.4~rc1-4
ii  libreoffice-math   1:6.0.4~rc1-4
ii  libreoffice-report-builder-bin 1:6.0.4~rc1-4
ii  libreoffice-writer 1:6.0.4~rc1-4
ii  python3-uno1:6.0.4~rc1-4

Versions of packages libreoffice recommends:
ii  fonts-crosextra-caladea 20130214-2
ii  fonts-crosextra-carlito 20130920-1
ii  fonts-dejavu2.37-1
ii  fonts-liberation1:1.07.4-6
pn  fonts-liberation2   
ii  fonts-linuxlibertine5.3.0-4
pn  fonts-noto-hinted   
pn  fonts-noto-mono 
ii  fonts-sil-gentium-basic 1.102-1
ii  libreoffice-java-common 1:6.0.4~rc1-4
pn  libreoffice-librelogo   
pn  libreoffice-nlpsolver   
pn  libreoffice-ogltrans
pn  libreoffice-report-builder  
pn  libreoffice-script-provider-bsh 
pn  libreoffice-script-provider-js  
pn  libreoffice-script-provider-python  
pn  libreoffice-sdbc-postgresql 
pn  libreoffice-wiki-publisher  

Versions of packages libreoffice suggests:
pn  cups-bsd
ii  default-jre [java6-runtime] 2:1.10-65
ii  firefox 60.0-1
ii  firefox-esr 52.8.0esr-1
ii  ghostscript 9.22~dfsg-2.1
ii  gnupg   2.2.5-1
ii  gpa 0.9.10-3
pn  gstreamer1.0-libav  
ii  gstreamer1.0-plugins-bad1.14.0-1+b1
ii  gstreamer1.0-plugins-base   1.14.0-2
ii  gstreamer1.0-plugins-good   1.14.0-4
pn  gstreamer1.0-plugins-ugly   
pn  hunspell-dictionary 
pn  hyphen-hyphenation-patterns 
ii  imagemagick 8:6.9.9.34+dfsg-3+b1
ii  imagemagick-6.q16 [imagemagick] 8:6.9.9.34+dfsg-3+b1
ii  libgl1  1.0.0+git20180308-2
pn  libreoffice-gnome   
pn  libreoffice-grammarcheck
pn  libreoffice-help
pn  libreoffice-l10n
pn  libreoffice-officebean  
ii  libsane 1.0.25-4.1
ii  libxrender1 1:0.9.10-1
pn  myspell-dictionary  
pn  mythes-thesaurus
pn  openclipart2-libreoffice | openclipart-libreoffice  
ii  openjdk-10-jre [java6-runtime]  10.0.1+10-4
pn  pstoedit
ii  thunderbird 1:52.7.0-1
ii  unixodbc2.3.4-1.1

Versions of packages libreoffice-core depends on:
ii  fontconfig2.13.0-4
ii  fonts-opensymbol  2:102.10+LibO6.0.4~rc1-4
ii  libboost-date-time1.62.0  1.62.0+dfsg-5+b1
ii  

Bug#898958: peruse: does not start

[Serge Kilimoff-Goriatchkine]

Package: peruse
Version: 1.2+dfsg-2
Severity: grave
Justification: renders package unusable

Dear Maintainer,

When I just run "peruse" command in my terminal (in fresh installation of 
peruse from apt), I get the following message that appears :

  Failed to load the component from disk. Reported error was: 
"file:///usr/share/peruse/qml/Main.qml:26 Type PeruseMain 
unavailable\nfile:///usr/share/peruse/qml/PeruseMain.qml:27 module 
\"org.kde.kirigami\" is not installed\n"

Thanks ! Et merci !



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

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

Versions of packages peruse depends on:
ii  kio 5.45.0-1
ii  libc6   2.27-3
ii  libgcc1 1:8.1.0-3
ii  libkf5archive5  5.45.0-1
ii  libkf5baloo55.45.0-1
ii  libkf5configcore5   5.45.0-1
ii  libkf5coreaddons5   5.45.0-1
ii  libkf5declarative5  5.45.0-1
ii  libkf5filemetadata3 5.45.0-1
ii  libkf5kiocore5  5.45.0-1
ii  libkf5kiowidgets5   5.45.0-1
ii  libqt5core5a5.10.1+dfsg-6+b1
ii  libqt5gui5  5.10.1+dfsg-6+b1
ii  libqt5qml5  5.10.1-4
ii  libqt5quick55.10.1-4
ii  libqt5widgets5  5.10.1+dfsg-6+b1
ii  libstdc++6  8.1.0-3
ii  peruse-common   1.2+dfsg-2
ii  qml-module-org-kde-kirigami25.45.0-1
ii  qml-module-org-kde-newstuff 5.45.0-1
ii  qml-module-qt-labs-folderlistmodel  5.10.1-4

peruse recommends no packages.

peruse suggests no packages.

-- no debconf information

Bug#898957: libquazip5-1 is marked Multi-Arch: same but is not coinstallable

[Francois Gouget]

Package: libquazip5-1
Version: 0.7.3-7
Severity: normal

Dear Maintainer,

Trying to install the amd64 and i386 versions of this package results in the 
following error:

# apt-get install libquazip5-1:i386 libquazip5-1:amd64
[...]
Unpacking libquazip5-1:amd64 (0.7.3-7) ...
dpkg: dependency problems prevent configuration of libquazip5-1:amd64:
 libquazip5-1:i386 (0.7.3-7) breaks libquazip-qt5-1 and is installed.
  libquazip5-1:amd64 (0.7.3-7) provides libquazip-qt5-1.
 libquazip5-1:i386 (0.7.3-7) breaks libquazip1-qt5 and is installed.
  libquazip5-1:amd64 (0.7.3-7) provides libquazip1-qt5.

dpkg: error processing package libquazip5-1:amd64 (--configure):
 dependency problems - leaving unconfigured


So the source of the issue seems to be that libquazip5-1:
* Provides the libquazip-qt5-1 and libquazip1-qt5 virtual packages
* Breaks + Replaces the libquazip-qt5-1 and libquazip1-qt5 virtual packages

Apt seems to consider that this means libquazip5-1:amd64 breaks 
libquazip5-1:i386 
through the libquazip-qt5-1 and libquazip1-qt5 virtual packages which prevents 
them from being coinstalled.

One strange thing is that, if I understand 7.6.1 of the Debian Policy Manual 
correctly, Breaks + Replaces is not supposed to be used on virtual packages:
http://www.chiark.greenend.org.uk/doc/debian-policy/policy.html/ch-relationships.html#s7.6.1

| For this usage of Replaces, virtual packages (see Virtual packages - 
Provides, 
| Section 7.5) are not considered when looking at a Replaces field. The 
packages 
| declared as being replaced must be mentioned by their real names.

Maybe that's why Apt is confused in this multi-arch configuration.


Note that, based on 7.6.2, the usual pattern for virtual packages would be 
Provides + Conflicts + Replaces:

|  In this situation, the package declared as being replaced can be a virtual 
|  package, so for example, all mail transport agents (MTAs) would have the 
|  following fields in their control files:
|
| Provides: mail-transport-agent
| Conflicts: mail-transport-agent
| Replaces: mail-transport-agent
|
| ensuring that only one MTA can be unpacked at any one time

Seems like something to try to see if it fixes the issue.


But libquazip-qt5-1 and libquazip1-qt5 may well have been real packages at some 
point. However currently their only existence is through the Provides of 
libquazip5-1. Still if the goal it to state that libquazip5-1 breaks these old 
packages (to ensure clean upgrades), then a Breaks + version number would 
probably 
be the right thing to do (see 7.5 of the policy):

http://www.chiark.greenend.org.uk/doc/debian-policy/policy.html/ch-relationships.html#s-virtual

| If a relationship field has a version number attached, only real packages 
will 
| be considered to see whether the relationship is satisfied (or the 
prohibition 
| violated, for a conflict or breakage). In other words, if a version number is 
| specified, this is a request to ignore all Provides for that package name and 
| consider only real packages. The package manager will assume that a package 
| providing that virtual package is not of the "right" version. A Provides 
field 
| may not contain version numbers, and the version number of the concrete 
package 
| which provides a particular virtual package will not be considered when 
| considering a dependency on or conflict with the virtual package name.



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

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

Versions of packages libquazip5-1 depends on:
ii  libc6 2.27-3
ii  libgcc1   1:8.1.0-1
ii  libqt5core5a  5.10.1+dfsg-6
ii  libstdc++68.1.0-1
ii  zlib1g1:1.2.11.dfsg-1

libquazip5-1 recommends no packages.

Versions of packages libquazip5-1 suggests:
pn  libquazip-doc  

-- no debconf information

Bug#898356: git-buildpackage: Multiple --git-pbuilder-options do not stack

[Guido Günther]

On Thu, May 17, 2018 at 07:47:58PM +0200, Matthijs Kooijman wrote:
> Hi Guido,
> 
> > > My suggestion of adding a --git-append-pbuilder-option could solve both
> > > usecases:
> > >  - you can use --git-pbuilder-options on the commandline to override all
> > >previously set options, including in gbp.conf
> > >  - you can use --git-append-pbuilder-option to extend any previously set
> > >options.
> > 
> > You would also need to define how option stack over the various gbp.conf
> > files. I don't think we want to go down that road.
> Hm? But isn't there some order defined already? Currently each time the
> option is given it overrides the previous value, so that is similarly
> dependent on the parse order (perhaps even more, since when you only use
> append, the order is irrelevant). Or am I misunderstanding what you mean
> by "stack"?

A --git-append-pbuilder-options would concatenate all options from all
config files and command line then? This would eliminate the usual
overriding of gbp.conf's. That IMHO makes not sense. What would make
sense is:

  --git-pbuilder-options-append="option1" 
--git-pbuilder-options-append="option2"

so you can decide on a per option basis if you want to append to the
currently set value. Each "--git-pbuilder-options" would reset the whole
thing and start over so:

  --git-pbuilder-options="foo" --git-pbuilder-options-append="option1" 
--git-pbuilder-options-append="option2"

would give

  "foo option1 option2"

where as

  --git-pbuilder-options="foo" --git-pbuilder-options-append="option1" 
--git-pbuilder-options-append="option2" \
  --git-pbuilder-options="bar" --git-pbuilder-options-append="option3"

would give

  "bar option3"

This would also work or gbp.conf. This would have clear overwrite
semantics on the command line and gbp.conf.
 -- Guido

Bug#898047: v2.3.1 is actually v2.2.0

[Marcel Dischinger]

Package: keepassxc
Followup-For: Bug #898047

I cannot reproduce your report. I am running the exact same version from buster 
and the cli reports correctly 2.3.1.

Bug#898951: RFS: ibus-kmfl/1.0.8-1 [ITP] -- Please help me for upstream

[Ko Ko Ye`]

please check for new upload.

https://mentors.debian.net/package/ibus-kmfl
https://mentors.debian.net/debian/pool/main/i/ibus-kmfl/ibus-kmfl_1.0.8-1.dsc

On Fri, May 18, 2018 at 12:45 AM, Brian Smith 
wrote:

> By the way, you should build with pbuilder to make sure all of your build
> dependencies are specified.
>
>
> On Thu, May 17, 2018 at 1:08 PM, Brian Smith  > wrote:
>
>> I'm not a DD or DM, but here are my comments.
>>
>> 1) d/README.source and d/README.Debian are not required and should have
>> something of consequence in them. The trivial versions that you have
>> provided should be removed or updated with useful information.
>> 2) uscan doesn't work, so d/watch needs to be fixed.
>> uscan warn: In debian/watch no matching files for watch line
>>   http://sf.net/p/kmfl/ ibus-kmfl-(.*)\.tar\.gz debian uupdate
>> 3) configure complains about a missing ibus package, so it looks like
>> d/control needs a Build-Depends update.
>> 4) d/control Description could use improvement. Does upstream provide a
>> description, possibly in .spec file? My advice is to use that, if available.
>>
>>
>>
>>
>>
>> On Thu, May 17, 2018 at 12:43 PM, kokoye2007 
>> wrote:
>>
>>> Package: sponsorship-requests
>>> Severity: normal
>>>
>>> Dear Maintainer, Mentor and Developer
>>>
>>>  I am looking for a sponsor for my package "ibus-kmfl"
>>>
>>>  please improve for my package and allow to upload upstream.
>>>  i am follow DFSG and SC, now i am waiting 4 software package.
>>>  when i become DD or DM, i will more support at mentor :'(
>>>
>>>  * Package name: ibus-kmfl
>>>Version : 1.0.8-1
>>>Upstream Author : kokoye2007 
>>>  * URL : https://kmfl.sf.net
>>>  * License : gpl2
>>>Section : utils
>>>
>>>   It builds those binary packages:
>>>
>>> ibus-kmfl  - ibus kmfl for linux its windows keyman
>>>
>>>   To access further information about this package, please visit the
>>> following URL:
>>>
>>>   https://mentors.debian.net/package/ibus-kmfl
>>>
>>>
>>>   Alternatively, one can download the package with dget using this
>>> command:
>>>
>>> dget -x https://mentors.debian.net/debian/pool/main/i/ibus-kmfl/ibus
>>> -kmfl_1.0.8-1.dsc
>>>
>>>
>>> -- System Information:
>>> Debian Release: buster/sid
>>>   APT prefers bionic-updates
>>>   APT policy: (500, 'bionic-updates'), (500, 'bionic-security'), (500,
>>> 'bionic-proposed'), (500, 'bionic')
>>> Architecture: amd64 (x86_64)
>>> Foreign Architectures: i386
>>>
>>> Kernel: Linux 4.15.0-21-generic (SMP w/4 CPU cores)
>>> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
>>> LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
>>> Shell: /bin/sh linked to /bin/dash
>>> Init: systemd (via /run/systemd/system)
>>> LSM: AppArmor: enabled
>>>
>>>
>>
>>
>> --
>> Brian T. Smith
>> System Fabric Works
>> Senior Technical Staff
>> bsm...@systemfabricworks.com
>> GPG Key: B3C2C7B73BA3CD7F
>>
>
>
>
> --
> Brian T. Smith
> System Fabric Works
> Senior Technical Staff
> bsm...@systemfabricworks.com
> GPG Key: B3C2C7B73BA3CD7F
>



-- 

with regards *Ko Ko Ye`*

+95 97989 22022
+95 94500 22022
+95 9731 47907
kokoye2...@gmail.com
kokoye2...@ubuntu.com

skype: kokoye2007
jitsi: kokoye2007

http://ubuntu-mm.net
http://wiki.ubuntu.com/kokoye2007
http://wiki.ubuntu.com/MyanmarTeam http://loco.ubuntu.com/teams/ubuntu-mm

Bug#898956: libmateweather1 is marked Multi-Arch: same but is not coinstallable

[Francois Gouget]

Package: libmateweather1
Version: 1.20.0-1
Severity: normal

Dear Maintainer,

Trying to install the amd64 and i386 versions of this package results in the 
following error:

# apt-get install libmateweather1:i386 libmateweather1:amd64
[...]
dpkg: dependency problems prevent configuration of libmateweather1:amd64:
 libmateweather1:i386 (1.20.0-1) breaks libmateweather and is installed.
  libmateweather1:amd64 (1.20.0-1) provides libmateweather.

dpkg: error processing package libmateweather1:amd64 (--configure):
 dependency problems - leaving unconfigured


So the source of the issue seems to be that libquazip5-1:
* Provides the libmateweather virtual package
* Breaks AND Conflicts with the libmateweather virtual package!
* Replaces the libmateweather virtual package

Apt seems to consider that this means libmateweather1:amd64 breaks 
libmateweather1:i386 through the libmateweather virtual package which prevents 
them from being coinstalled.

One strange thing is that, if I understand 7.6.1 of the Debian Policy Manual 
correctly, Breaks + Replaces is not supposed to be used on virtual packages:
http://www.chiark.greenend.org.uk/doc/debian-policy/policy.html/ch-relationships.html#s7.6.1

| For this usage of Replaces, virtual packages (see Virtual packages - 
Provides, 
| Section 7.5) are not considered when looking at a Replaces field. The 
packages 
| declared as being replaced must be mentioned by their real names.

Maybe that's why Apt is confused in this multi-arch configuration.


Note that, based on 7.6.2, the usual pattern for virtual packages would be 
Provides + Conflicts + Replaces:

|  In this situation, the package declared as being replaced can be a virtual 
|  package, so for example, all mail transport agents (MTAs) would have the 
|  following fields in their control files:
|
| Provides: mail-transport-agent
| Conflicts: mail-transport-agent
| Replaces: mail-transport-agent
|
| ensuring that only one MTA can be unpacked at any one time


Finally libmateweather may well have been a real package at some point. However 
currently its only existence is through the Provides of libmateweather1. Still 
if 
the goal it to state that libmateweather1 breaks this old package (to ensure 
clean 
upgrades), then a Breaks + version number would probably be the right thing to 
do 
(see 7.5 of the policy):

http://www.chiark.greenend.org.uk/doc/debian-policy/policy.html/ch-relationships.html#s-virtual

| If a relationship field has a version number attached, only real packages 
will 
| be considered to see whether the relationship is satisfied (or the 
prohibition 
| violated, for a conflict or breakage). In other words, if a version number is 
| specified, this is a request to ignore all Provides for that package name and 
| consider only real packages. The package manager will assume that a package 
| providing that virtual package is not of the "right" version. A Provides 
field 
| may not contain version numbers, and the version number of the concrete 
package 
| which provides a particular virtual package will not be considered when 
| considering a dependency on or conflict with the virtual package name.



In any case it does not seem like libmateweather1 should combine Breaks and 
Conflicts.


Note that libmate-panel-applet-4-1 has a similar issue with libmatepanelapplet.


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

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

Versions of packages libmateweather1 depends on:
ii  libatk1.0-02.28.1-1
ii  libc6  2.27-3
ii  libcairo-gobject2  1.15.10-3
ii  libcairo2  1.15.10-3
ii  libgdk-pixbuf2.0-0 2.36.11-2
ii  libglib2.0-0   2.56.1-2
ii  libgtk-3-0 3.22.29-3
ii  libmateweather-common  1.20.0-1
ii  libpango-1.0-0 1.42.0-1
ii  libpangocairo-1.0-01.42.0-1
ii  libsoup2.4-1   2.62.1-1
ii  libxml22.9.4+dfsg1-6.1

libmateweather1 recommends no packages.

libmateweather1 suggests no packages.

-- no debconf information

Bug#898955: dist: Please import new upstream snapshot for metaconfig -X support

[Dominic Hargreaves]

Source: dist
Version: 1:3.5-36.0001-3
Severity: wishlist
X-Debbugs-Cc: p...@packages.debian.org

In order to package the upcoming release of perl, we need support
for metaconfig's -X which was added a few months ago (we now use dist to
validate the contents of Configure supplied upstream),

I've prepared updated packages, which you can see at
. I created the
orig tarball using git archive, after first manually running svn-revision
to create revision.h (as upstream is not creating release tarballs as
far as I can see).

The diff looked fairly reasonable with mostly formatting changes, and 
I have verified that we can reproduce the perl Configure using this version.

This will be a blocker for updating perl to 5.28, so it would be great if
this could be fixed soon. As mentioned by email in October, we in the
perl team are happy to assist with maintenance of this package, or take
it over, as you prefer. We can also NMU it if needed.

Thanks for your consideration,
Dominic.

Bug#898813: telegram-desktop: URI passed to the client via command line is ignored

[Коля Гурьев]

Hello,

16.05.2018 08:05, Alexander Kernozhitsky пишет:
> According to `man telegram-desktop` output:
> 
> telegram-desktop [-startintray] [-many] [-debug] [-- URI]
> 
> we can pass an URI to open a specified chat or a channel inside the 
> application.
> But it seems that the passed URI is ignored. I looked into the code and
> noticed that it is parsed by the command line options parser, but is
> used nowhere else in the code.

Here it means a user can pass a URI within tg scheme. For example:

$ telegram-desktop -- tg://resolve?domain=mymedia

This is exactly the same links used on t.me site for instant open
Telegram client.

Bug#898757: musescore: Backtrace for crash on startup

[Giovanni Mascellani]

Hi,

Il 17/05/2018 17:36, Thorsten Glaser ha scritto:
> I removed all configuration and cache files, then started musescore
> with the default empty score, hit ‘P’ to display the piano, exited
> musescore, and started it again; this does indeed trigger the crash.
> 
> I’ll analyse it and/or give it for upstream to deal with.
> 
> In the meantime, you can start MuseScore again by editing the file
> ~/.config/MuseScore/MuseScore2.ini and setting the showPianoKeyboard
> entry in the [MainWindow] section to “false”. (Note that, when you
> start MuseScore again, the piano will be once again active, so after
> exiting it will set this back to “true” so you’ll have to disable the
> piano before exiting.)

I can confirm everything. Actually, probably I had not really deleted
the configuration file, because now if I delete it, musescore starts
properly.

Thanks, Giovanni.
-- 
Giovanni Mascellani 
Postdoc researcher - Université Libre de Bruxelles

Bug#898954: RFS: python-fibra/0.0.18-1 [ITP]

[Mario Frasca]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I'm looking for a sponsor for my package 'fibra'. 

 * Package name    : fibra
   Version : 0.0.18-1
   Upstream Author : Simon Wittber
 * URL : http://github.com/mfrasca/fibra
 * License : MIT
   Section : python

It is now marked as "no" in the column "needs a sponsor", in my page
"https://mentors.debian.net/packages/uploader/mario%40anche.no;, even if
I opened bug report 898773.

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

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


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

  dget -x
https://mentors.debian.net/debian/pool/main/f/fibra/fibra_0.0.18-1.dsc

Changes since the last upload:

I've removed all the warnings in the debuild/lintian process as far as I
could see from the machine where running debuild.

best regards, MF

Bug#875906: Hello, I am NMUing to DELAYED-15 to close this bug report

[Nicholas D Steeves]

Hi Sylvestre,

On Thu, May 17, 2018 at 10:19:01AM +0200, Sylvestre Ledru wrote:
> On 16/05/2018 22:06, Nicholas D Steeves wrote:
> > On Wed, May 16, 2018 at 08:55:51AM +0200, Sylvestre Ledru wrote:
> >> On 15/05/2018 18:31, Georges Khaznadar wrote:
> >>> The NMU shoud reach debian/unstable in two weeks. Feel free to cancel it
> >>> and make other modification as you want.
> >>>
> >>
> >> Uploaded! Many thanks!
> > 
> > Thank you Georges and Sylvestre :-)
> > 
> > WRT elpy, I've updated its packaging in git to use python3-autopep8
> > and will upload after python3-autopep8 clears NEW.
> Are you sure you push your changes? I don't see them.

I just double checked, and can confirm that I had pushed to
https://salsa.debian.org/emacsen-team/elpy.git :-)

Wow, python3-autopep8 passed through NEW really fast!  I had expected
it to take about a week, during which time I had hoped upstream
yasnippet-snippets would merge elpy's python-mode snippets, so that I
could unbundle them from elpy.  Elpy-1.20.0-1 is in the archive and as
it stands, I don't think there are yet enough changes to justify a
-2.  If you've found any bugs then please file reports; fixing them
would definitely justify a -2 ;-)

Kind regards,
Nicholas


signature.asc
Description: PGP signature

Bug#898951: RFS: ibus-kmfl/1.0.8-1 [ITP] -- Please help me for upstream

[Brian Smith]

By the way, you should build with pbuilder to make sure all of your build
dependencies are specified.


On Thu, May 17, 2018 at 1:08 PM, Brian Smith 
wrote:

> I'm not a DD or DM, but here are my comments.
>
> 1) d/README.source and d/README.Debian are not required and should have
> something of consequence in them. The trivial versions that you have
> provided should be removed or updated with useful information.
> 2) uscan doesn't work, so d/watch needs to be fixed.
> uscan warn: In debian/watch no matching files for watch line
>   http://sf.net/p/kmfl/ ibus-kmfl-(.*)\.tar\.gz debian uupdate
> 3) configure complains about a missing ibus package, so it looks like
> d/control needs a Build-Depends update.
> 4) d/control Description could use improvement. Does upstream provide a
> description, possibly in .spec file? My advice is to use that, if available.
>
>
>
>
>
> On Thu, May 17, 2018 at 12:43 PM, kokoye2007  wrote:
>
>> Package: sponsorship-requests
>> Severity: normal
>>
>> Dear Maintainer, Mentor and Developer
>>
>>  I am looking for a sponsor for my package "ibus-kmfl"
>>
>>  please improve for my package and allow to upload upstream.
>>  i am follow DFSG and SC, now i am waiting 4 software package.
>>  when i become DD or DM, i will more support at mentor :'(
>>
>>  * Package name: ibus-kmfl
>>Version : 1.0.8-1
>>Upstream Author : kokoye2007 
>>  * URL : https://kmfl.sf.net
>>  * License : gpl2
>>Section : utils
>>
>>   It builds those binary packages:
>>
>> ibus-kmfl  - ibus kmfl for linux its windows keyman
>>
>>   To access further information about this package, please visit the
>> following URL:
>>
>>   https://mentors.debian.net/package/ibus-kmfl
>>
>>
>>   Alternatively, one can download the package with dget using this
>> command:
>>
>> dget -x https://mentors.debian.net/debian/pool/main/i/ibus-kmfl/ibus
>> -kmfl_1.0.8-1.dsc
>>
>>
>> -- System Information:
>> Debian Release: buster/sid
>>   APT prefers bionic-updates
>>   APT policy: (500, 'bionic-updates'), (500, 'bionic-security'), (500,
>> 'bionic-proposed'), (500, 'bionic')
>> Architecture: amd64 (x86_64)
>> Foreign Architectures: i386
>>
>> Kernel: Linux 4.15.0-21-generic (SMP w/4 CPU cores)
>> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
>> LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
>> Shell: /bin/sh linked to /bin/dash
>> Init: systemd (via /run/systemd/system)
>> LSM: AppArmor: enabled
>>
>>
>
>
> --
> Brian T. Smith
> System Fabric Works
> Senior Technical Staff
> bsm...@systemfabricworks.com
> GPG Key: B3C2C7B73BA3CD7F
>



-- 
Brian T. Smith
System Fabric Works
Senior Technical Staff
bsm...@systemfabricworks.com
GPG Key: B3C2C7B73BA3CD7F

Bug#898883: libtf2-kdl-dev: pkgconfig and cmake files refer to non-existing liborocos-kdl.so.1.3.1

[Adrian Bunk]

Control: severity -1 serious
Control: affects -1 src:ros-robot-state-publisher

On Thu, May 17, 2018 at 07:46:40AM +0200, Johannes Schauer wrote:
> On Thu, 17 May 2018 07:08:37 +0200 Johannes Schauer  wrote:
> > Currently, it is not possible to compile a project with libtf2-kdl-dev with
> > either CMake or pkg-config because both files will attempt to link objects 
> > to
> > /usr/lib/liborocos-kdl.so.1.3.1 which does not exist in Debian unstable
> > anymore.
> > 
> > It seems orocos-kdl has been updated to 1.4, so this package should be
> > updated as well.
> 
> It seems that a simple rebuild fixes this issue.
> 
> For the future, I implemented a simple autopkgtest for ros-geometry2.  It
> currently only tries to build a project using tf2_kdl. Feel free to also add
> the other libraries.
> 
> With such a smoke test it should be easier to spot such breaks in the future.
> 
> I pushed my changes to the packaging repository.

Note that while a rebuild might make the bug temporarily harmless,
this bug still needs proper fixing - your new autopkgtest is not
supposed to ever fail.

Hardcoding this part of the filename that is not part of the soname in 
the cmake file is simply wrong, and after a rebuild it would be expected
that the same bug would hit again with 1.4.1.

Setting to RC since this bug makes ros-robot-state-publisher FTBFS.

> Thanks!
> 
> cheers, josch

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#898951: RFS: ibus-kmfl/1.0.8-1 [ITP] -- Please help me for upstream

[Brian Smith]

I'm not a DD or DM, but here are my comments.

1) d/README.source and d/README.Debian are not required and should have
something of consequence in them. The trivial versions that you have
provided should be removed or updated with useful information.
2) uscan doesn't work, so d/watch needs to be fixed.
uscan warn: In debian/watch no matching files for watch line
  http://sf.net/p/kmfl/ ibus-kmfl-(.*)\.tar\.gz debian uupdate
3) configure complains about a missing ibus package, so it looks like
d/control needs a Build-Depends update.
4) d/control Description could use improvement. Does upstream provide a
description, possibly in .spec file? My advice is to use that, if available.





On Thu, May 17, 2018 at 12:43 PM, kokoye2007  wrote:

> Package: sponsorship-requests
> Severity: normal
>
> Dear Maintainer, Mentor and Developer
>
>  I am looking for a sponsor for my package "ibus-kmfl"
>
>  please improve for my package and allow to upload upstream.
>  i am follow DFSG and SC, now i am waiting 4 software package.
>  when i become DD or DM, i will more support at mentor :'(
>
>  * Package name: ibus-kmfl
>Version : 1.0.8-1
>Upstream Author : kokoye2007 
>  * URL : https://kmfl.sf.net
>  * License : gpl2
>Section : utils
>
>   It builds those binary packages:
>
> ibus-kmfl  - ibus kmfl for linux its windows keyman
>
>   To access further information about this package, please visit the
> following URL:
>
>   https://mentors.debian.net/package/ibus-kmfl
>
>
>   Alternatively, one can download the package with dget using this command:
>
> dget -x https://mentors.debian.net/debian/pool/main/i/ibus-kmfl/
> ibus-kmfl_1.0.8-1.dsc
>
>
> -- System Information:
> Debian Release: buster/sid
>   APT prefers bionic-updates
>   APT policy: (500, 'bionic-updates'), (500, 'bionic-security'), (500,
> 'bionic-proposed'), (500, 'bionic')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 4.15.0-21-generic (SMP w/4 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
> LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
>


-- 
Brian T. Smith
System Fabric Works
Senior Technical Staff
bsm...@systemfabricworks.com
GPG Key: B3C2C7B73BA3CD7F

Bug#898666: ncurses-base: include screen.xterm-256color terminfo entry

[Sven Joachim]

On 2018-05-14 23:03 +0200, Axel Beckert wrote:

> Sven Joachim wrote:
>> Many terminal emulators default to TERM=xterm-256color these days, for
>> instance those based on libvte-2.91 as well as KDE's konsole.  For
>> better or worse, screen then by default sets TERM to
>> screen.xterm-256color if the latter is present in the terminfo database.
>> 
>> Since terminal emulators setting TERM to xterm-256color are popular and
>> screen is popular, it follows that screen.xterm-256color is also popular
>> and thus should be included in ncurses-base.
>
> Confirmed. Had reports about that combination recently, too, IIRC from
> someone working on MacOS X locally.
>
>> Opinions from the screen maintainers (in X-Debbugs-CC) would be
>> welcome.
>
> Sounds like a good idea to me, with the similar drawbacks in mind:
>
>> The only downside I see is that one of the suggested workarounds for
>> #854414 (installing ncurses-term locally) does no longer work,
>
> There are also some cases, where uninstalling ncurses-term is a
> proposed solution, which then wouldn't help respectively uninstalling
> the according termcap entries will no more be possible.

Unless you go to some length with a dpkg path-exclude, but then that's a
bit more difficult to undo as uninstalling a package.  It's also trivial
to install the terminfo entry on the remote system $REMOTE:

infocmp screen.xterm-256color | ssh $REMOTE tic -

>> but I think uninstalling ncurses-term is not a great idea anyway.
>
> Same here, but I know that there are people who think otherwise, see
> e.g. https://pkgs.org/download/ncurses-term-considered-harmful

By their logic, adding entries to ncurses-base could also be harmful,
since they will likely not be available on remote systems for some time,
as servers tend to have older software than desktops.

Anyway, I'll add screen.xterm-256color to ncurses-base in the next
upload.  The ncurses-base package is badly outdated, it includes cruft
like xterm-r5 which nobody has been using for 15+ years but misses
terminfo entries which are popular today.

Cheers,
   Sven

Bug#898356: git-buildpackage: Multiple --git-pbuilder-options do not stack

[Matthijs Kooijman]

Hi Guido,

> > My suggestion of adding a --git-append-pbuilder-option could solve both
> > usecases:
> >  - you can use --git-pbuilder-options on the commandline to override all
> >previously set options, including in gbp.conf
> >  - you can use --git-append-pbuilder-option to extend any previously set
> >options.
> 
> You would also need to define how option stack over the various gbp.conf
> files. I don't think we want to go down that road.
Hm? But isn't there some order defined already? Currently each time the
option is given it overrides the previous value, so that is similarly
dependent on the parse order (perhaps even more, since when you only use
append, the order is irrelevant). Or am I misunderstanding what you mean
by "stack"?

Gr.

Matthijs


signature.asc
Description: PGP signature

Bug#898526: h5py: FTBFS with HDF5 1.10.2

[Gilles Filippini]

Control: tags + patch

On Sun, 13 May 2018 16:01:31 +0200 Gilles Filippini  wrote:
> Control: severity -1 serious
> Control: retitle -1 h5py: FTBFS - FAIL: test_out_of_order_offsets
> 
> On Sun, 13 May 2018 02:49:12 +0200 Gilles Filippini  wrote:
> > Source: h5py
> > Version: 2.7.1-2
> > Severity: normal
> > 
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA512
> > 
> > Hi,
> > 
> > h5py FTBFS with HDF5 1.10.2 currently in experimental. The failure occurs
> > during the tests where two of them fail:
> > 
> > ==
> > FAIL: test_out_of_order_offsets (h5py.tests.hl.test_datatype.TestOffsets)
> > - --
> > Traceback (most recent call last):
> >   File "h5py/tests/hl/test_datatype.py", line 198, in 
> > test_out_of_order_offsets
> > self.assertArrayEqual(fd['data'], data)
> >   File "h5py/tests/common.py", line 124, in assertArrayEqual
> > "Dtype mismatch (%s vs %s)%s" % (dset.dtype, arr.dtype, message)
> > AssertionError: Dtype mismatch ({'names':['f1','f3','f2'], 
> > 'formats':[' > {'names':['f1','f2','f3'], 'formats':[' > 'offsets':[0,16,8], 'itemsize':20})
> > 
> > ==
> > FAIL: test_out_of_order_offsets (h5py.tests.old.test_h5t.TestCompound)
> > - --
> > Traceback (most recent call last):
> >   File "h5py/tests/old/test_h5t.py", line 61, in test_out_of_order_offsets
> > self.assertEqual(tid.dtype, expected_dtype)
> > AssertionError: dtype({'names':['f1','f3','f2'], 
> > 'formats':[' > dtype({'names':['f1','f2','f3'], 'formats':[' > 'offsets':[0,16,8], 'itemsize':20})
> > 
> > - --
> > Ran 447 tests in 1.206s
> > 
> > FAILED (failures=2, skipped=18, expected failures=6)
> 
> Actually it FTBFS with the very same failure on unstable as well. Then
> raising severity to serious.
> 
> This seems tied to the recent python-numpy upgrade to 1.14.3. It builds
> fine against python-numpy 1.13.3.

Upstream release 2.8.0 doesn't FTBFS. The upstream commit 5009e06 [1]
fixes the issue. Attached a patch proposal after this commit.

Thanks,
diff -Nru h5py-2.7.1/debian/changelog h5py-2.7.1/debian/changelog
--- h5py-2.7.1/debian/changelog 2017-09-11 11:15:49.0 +0200
+++ h5py-2.7.1/debian/changelog 2018-05-16 17:00:35.0 +0200
@@ -1,3 +1,10 @@
+h5py (2.7.1-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Backport upstream commit to support numpy 1.14
+
+ -- Gilles Filippini   Wed, 16 May 2018 17:00:35 +0200
+
 h5py (2.7.1-2) unstable; urgency=medium
 
   * Fixup the debug package description for Python 2.
diff -Nru h5py-2.7.1/debian/patches/series h5py-2.7.1/debian/patches/series
--- h5py-2.7.1/debian/patches/series2017-09-11 11:15:49.0 +0200
+++ h5py-2.7.1/debian/patches/series2018-05-16 17:00:35.0 +0200
@@ -1,3 +1,4 @@
 No-rpath.patch
 No-intersphinx.patch
 Fix-build-of-API-docs-with-Python-3.patch
+Support-numpy-1.14.patch
diff -Nru h5py-2.7.1/debian/patches/Support-numpy-1.14.patch 
h5py-2.7.1/debian/patches/Support-numpy-1.14.patch
--- h5py-2.7.1/debian/patches/Support-numpy-1.14.patch  1970-01-01 
01:00:00.0 +0100
+++ h5py-2.7.1/debian/patches/Support-numpy-1.14.patch  2018-05-16 
17:00:35.0 +0200
@@ -0,0 +1,84 @@
+Description: Backport of upstream commit 5009e06 stripped of setup related
+ changes
+
+From 5009e062a6f7d4e074cab0fcb42a780ac2b1d7d4 Mon Sep 17 00:00:00 2001
+From: James Tocknell 
+Date: Thu, 28 Dec 2017 20:55:55 +1100
+Subject: [PATCH] FIX: Don't reorder compound types, breaks on numpy 1.14
+
+---
+ h5py/h5t.pyx | 25 +++--
+ setup.py |  2 +-
+ tox.ini  |  4 ++--
+ 3 files changed, 10 insertions(+), 21 deletions(-)
+
+diff --git a/h5py/h5t.pyx b/h5py/h5t.pyx
+index cc2344e1..7445e9eb 100644
+--- a/h5py/h5t.pyx
 b/h5py/h5t.pyx
+@@ -1136,12 +1136,6 @@ cdef class TypeCompoundID(TypeCompositeID):
+ else:
+ if sys.version[0] == '3':
+ field_names = [x.decode('utf8') for x in field_names]
+-if len(field_names) > 0:
+-collated_fields = zip(field_names, field_types, field_offsets)
+-ordered_fields = sorted(
+-collated_fields, key=operator.itemgetter(2))
+-field_names, field_types, field_offsets = \
+-map(list, zip(*ordered_fields))
+ typeobj = dtype({
+ 'names': field_names,
+ 'formats': field_types,
+@@ -1458,8 +1452,7 @@ cdef TypeCompoundID _c_compound(dtype 

Bug#898952: libnative-platform-java FTBFS: javadoc error

[Adrian Bunk]

Source: libnative-platform-java
Version: 0.14-4
Severity: serious

https://buildd.debian.org/status/package.php?p=libnative-platform-java=sid

...
javadoc -d debian/out/javadoc -link file:///usr/share/doc/default-jdk/api 
src/main/java/net/rubygrapefruit/platform/package-info.java 
src/main/java/net/rubygrapefruit/platform/internal/Platform.java 
src/main/java/net/rubygrapefruit/platform/internal/NativeLibraryLocator.java 
src/main/java/net/rubygrapefruit/platform/internal/jni/WindowsRegistryFunctions.java
 
src/main/java/net/rubygrapefruit/platform/internal/jni/WindowsHandleFunctions.java
 
src/main/java/net/rubygrapefruit/platform/internal/jni/WindowsFileFunctions.java
 
src/main/java/net/rubygrapefruit/platform/internal/jni/WindowsConsoleFunctions.java
 src/main/java/net/rubygrapefruit/platform/internal/jni/TerminfoFunctions.java 
src/main/java/net/rubygrapefruit/platform/internal/jni/PosixTypeFunctions.java 
src/main/java/net/rubygrapefruit/platform/internal/jni/PosixTerminalFunctions.java
 
src/main/java/net/rubygrapefruit/platform/internal/jni/PosixProcessFunctions.java
 
src/main/java/net/rubygrapefruit/platform/internal/jni/PosixFileSystemFunctions.java
 src/main/java/net/rubygrapefruit/platform/internal/jni/PosixFileFunctions.java 
src/main/java/net/rubygrapefruit/platform/internal/jni/OsxMemoryFunctions.java 
src/main/java/net/rubygrapefruit/platform/internal/jni/NativeLibraryFunctions.java
 src/main/java/net/rubygrapefruit/platform/internal/jni/MemoryFunctions.java 
src/main/java/net/rubygrapefruit/platform/internal/jni/FileEventFunctions.java 
src/main/java/net/rubygrapefruit/platform/internal/WrapperTerminal.java 
src/main/java/net/rubygrapefruit/platform/internal/WrapperProcessLauncher.java 
src/main/java/net/rubygrapefruit/platform/internal/WrapperProcess.java 
src/main/java/net/rubygrapefruit/platform/internal/WindowsTerminals.java 
src/main/java/net/rubygrapefruit/platform/internal/WindowsTerminal.java 
src/main/java/net/rubygrapefruit/platform/internal/WindowsProcessLauncher.java 
src/main/java/net/rubygrapefruit/platform/internal/WindowsFileTime.java 
src/main/java/net/rubygrapefruit/platform/internal/WindowsFileStat.java 
src/main/java/net/rubygrapefruit/platform/internal/WindowsDirList.java 
src/main/java/net/rubygrapefruit/platform/internal/TerminfoTerminals.java 
src/main/java/net/rubygrapefruit/platform/internal/TerminfoTerminal.java 
src/main/java/net/rubygrapefruit/platform/internal/TerminalCapabilities.java 
src/main/java/net/rubygrapefruit/platform/internal/PosixFileSystems.java 
src/main/java/net/rubygrapefruit/platform/internal/NativeLibraryLoader.java 
src/main/java/net/rubygrapefruit/platform/internal/MutableTypeInfo.java 
src/main/java/net/rubygrapefruit/platform/internal/MutableTerminalSize.java 
src/main/java/net/rubygrapefruit/platform/internal/MutableSystemInfo.java 
src/main/java/net/rubygrapefruit/platform/internal/LibraryDef.java 
src/main/java/net/rubygrapefruit/platform/internal/FunctionResult.java 
src/main/java/net/rubygrapefruit/platform/internal/FileSystemList.java 
src/main/java/net/rubygrapefruit/platform/internal/FileStat.java 
src/main/java/net/rubygrapefruit/platform/internal/DirList.java 
src/main/java/net/rubygrapefruit/platform/internal/DefaultWindowsRegistry.java 
src/main/java/net/rubygrapefruit/platform/internal/DefaultWindowsFiles.java 
src/main/java/net/rubygrapefruit/platform/internal/DefaultSystemInfo.java 
src/main/java/net/rubygrapefruit/platform/internal/DefaultProcessLauncher.java 
src/main/java/net/rubygrapefruit/platform/internal/DefaultProcess.java 
src/main/java/net/rubygrapefruit/platform/internal/DefaultPosixFiles.java 
src/main/java/net/rubygrapefruit/platform/internal/DefaultOsxMemoryInfo.java 
src/main/java/net/rubygrapefruit/platform/internal/DefaultOsxMemory.java 
src/main/java/net/rubygrapefruit/platform/internal/DefaultMemoryInfo.java 
src/main/java/net/rubygrapefruit/platform/internal/DefaultMemory.java 
src/main/java/net/rubygrapefruit/platform/internal/DefaultFileSystemInfo.java 
src/main/java/net/rubygrapefruit/platform/internal/DefaultFileEvents.java 
src/main/java/net/rubygrapefruit/platform/internal/AnsiTerminal.java 
src/main/java/net/rubygrapefruit/platform/internal/AbstractTerminals.java 
src/main/java/net/rubygrapefruit/platform/internal/AbstractTerminal.java 
src/main/java/net/rubygrapefruit/platform/internal/AbstractFiles.java 
src/main/java/net/rubygrapefruit/platform/WindowsRegistry.java 
src/main/java/net/rubygrapefruit/platform/WindowsFiles.java 
src/main/java/net/rubygrapefruit/platform/WindowsFileInfo.java 
src/main/java/net/rubygrapefruit/platform/ThreadSafe.java 
src/main/java/net/rubygrapefruit/platform/Terminals.java 
src/main/java/net/rubygrapefruit/platform/TerminalSize.java 
src/main/java/net/rubygrapefruit/platform/Terminal.java 
src/main/java/net/rubygrapefruit/platform/SystemInfo.java 
src/main/java/net/rubygrapefruit/platform/ResourceClosedException.java 

Bug#898951: RFS: ibus-kmfl/1.0.8-1 [ITP] -- Please help me for upstream

[kokoye2007]

Package: sponsorship-requests
Severity: normal

Dear Maintainer, Mentor and Developer

 I am looking for a sponsor for my package "ibus-kmfl"

 please improve for my package and allow to upload upstream.
 i am follow DFSG and SC, now i am waiting 4 software package.
 when i become DD or DM, i will more support at mentor :'(

 * Package name: ibus-kmfl
   Version : 1.0.8-1
   Upstream Author : kokoye2007 
 * URL : https://kmfl.sf.net
 * License : gpl2
   Section : utils

  It builds those binary packages:

ibus-kmfl  - ibus kmfl for linux its windows keyman

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

  https://mentors.debian.net/package/ibus-kmfl


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

dget -x 
https://mentors.debian.net/debian/pool/main/i/ibus-kmfl/ibus-kmfl_1.0.8-1.dsc


-- System Information:
Debian Release: buster/sid
  APT prefers bionic-updates
  APT policy: (500, 'bionic-updates'), (500, 'bionic-security'), (500, 
'bionic-proposed'), (500, 'bionic')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Bug#898949: schroot: PAM config should use common-session-noninteractive

[Ansgar Burchardt]

Package: schroot
Version: 1.6.10-3
Severity: important

The /etc/pam.d/schroot included in the package uses

  @include common-session

Please use

  @include common-session-noninteractive

instead as cron, at, ... already do.

On systems with libpam-systemd installed using common-session will
create a logind session which schroot should not do.

Ansgar

Bug#898950: xfce4-verve-plugin: the essential `verve-focus` program is missing in this version, which makes it useless

[Gerhard Schaufelberger]

Package: xfce4-verve-plugin
Version: 2.0.0-1
Severity: important

Dear Maintainer,

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

   * What led up to the situation?
Tried to create a shortcut to `verve-focus`, running the shortcut caused the 
not-found error. I then realized, that verve-focus was missing from this 
version.
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
Tried to use older version (1.x) instead. This works, however xfce4-goodies has 
dependencies with xfce4-verve-plugin, so I have to either live without 
xfce4-goodies or without verve command line.
   * What was the outcome of this action?
Given up on new version of verve-plugin
   * What outcome did you expect instead?
Should be possible to go back to v. 1.x, which worked perfectly.
*** End of the template - remove these template lines ***


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

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

Versions of packages xfce4-verve-plugin depends on:
ii  exo-utils0.12.0-1
ii  libatk1.0-0  2.28.1-1
ii  libc62.27-3
ii  libcairo-gobject21.15.10-3
ii  libcairo21.15.10-3
ii  libfribidi0  0.19.7-2
ii  libgdk-pixbuf2.0-0   2.36.11-2
ii  libglib2.0-0 2.56.1-2
ii  libgtk-3-0   3.22.29-3
ii  libpango-1.0-0   1.42.0-1
ii  libpangocairo-1.0-0  1.42.0-1
ii  libpcre3 2:8.39-9
ii  libxfce4panel-2.0-4  4.12.2-1
ii  libxfce4ui-2-0   4.12.1-3
ii  libxfce4util74.12.1-3

xfce4-verve-plugin recommends no packages.

xfce4-verve-plugin suggests no packages.

Bug#898948: ncurses-base: include rxvt-unicode-256color terminfo entry

[Sven Joachim]

Package: ncurses-base
Version: 6.1+20180210-3
Severity: wishlist

The rxvt-unicode package in buster/sid defaults to
TERM=rxvt-unicode-256color.  This has annoyed some users (see #886465),
as this terminfo entry is not in ncurses-base.  Moreover, rxvt-unicode
is the successor of some other once popular packages like rxvt and aterm
(see #848284), so I think rxvt-unicode-256color should be added to
ncurses-base.

Including rxvt-unicode-256color in ncurses-base has also been requested
in Fedora: https://bugzilla.redhat.com/show_bug.cgi?id=1430935.  The
only objection there is that Fedora's rxvt-unicode package ships the
terminfo entry itself, but we do not have this file conflict in Debian.

Bug#898947: Please backport "Use grub-file to figure out whether multiboot2 should be used for Xen.gz"

[Ian Jackson]

Package: grub2
Version: 2.02+dfsg1-4

I'm told that "multiboot" does not work with UEFI and "multiboot2" is
needed.  (Not sure if this is true only for Xen, or more generally.)
I'm also told that buster's grub has enough to support booting Xen,
although I have not verified this myself.

Therefore, please could you cherry pick this
  
http://git.savannah.gnu.org/cgit/grub.git/commit/?id=b4d709b6ee789cdaf3fa7a80fd90c721a16f48c2
onto your next upload for buster ?

Thanks,
Ian.

Bug#898165: Regression in [v2] nfs: Fix ugly referral attributes ?

[Chuck Lever]

> On May 17, 2018, at 3:53 AM, Moritz Schlarb  wrote:
> 
> Hi everyone,
> 
> there might be a regression coming from this patch:
> Since it got included in 3.16.54, our clients running a recent 3.16
> kernel (like from Debian jessie-security) did not follow NFS 4.1
> referrals (issued by nfs-ganesha) anymore.
> I have built that exact Debian kernel package with just this patch
> reversed and it worked again, so I got pretty confident that this patch
> is at least strongly related to the problem.
> Pradeep also confirmed the problem happening in 3.16.54 but not in 3.16.51.
> Interestingly, this does *not* happen with 4.9 kernels, although the
> patch was part of 4.9.80...
> 
> I have attached a pcap file of a machine running 3.16.56-1+deb8u1 in
> which I try to login as a user where my home directory is
> /uni-mainz.de/homes/schlarbm (with nfsrefer.zdv.uni-mainz.de:/ on
> /uni-mainz.de) which is then referred to
> fs02.uni-mainz.de:/vol/ma17/homes/schlarbm but that referral is not
> followed by the client.
> 
> Please let me know if you need additional information to reproduce or
> have suggestions on what we could try.

Just a shot in the dark: Wondering if v3.16 needs

commit ea96d1ecbe4fcb1df487d99309d3157b4ff5fc02
Author: Anna Schumaker 
AuthorDate: Fri Apr 3 14:35:59 2015 -0400
Commit: Trond Myklebust 
CommitDate: Thu Apr 23 14:43:54 2015 -0400

nfs: Fetch MOUNTED_ON_FILEID when updating an inode


> Best regards,
> Moritz
> 
> On 05.11.2017 21:45, Chuck Lever wrote:
>> Before traversing a referral and performing a mount, the mounted-on
>> directory looks strange:
>> 
>> dr-xr-xr-x. 2 4294967294 4294967294 0 Dec 31  1969 dir.0
>> 
>> nfs4_get_referral is wiping out any cached attributes with what was
>> returned via GETATTR(fs_locations), but the bit mask for that
>> operation does not request any file attributes.
>> 
>> Retrieve owner and timestamp information so that the memcpy in
>> nfs4_get_referral fills in more attributes.
>> 
>> Changes since v1:
>> - Don't request attributes that the client unconditionally replaces
>> - Request only MOUNTED_ON_FILEID or FILEID attribute, not both
>> - encode_fs_locations() doesn't use the third bitmask word
>> 
>> Fixes: 6b97fd3da1ea ("NFSv4: Follow a referral")
>> Suggested-by: Pradeep Thomas 
>> Signed-off-by: Chuck Lever 
>> Cc: sta...@vger.kernel.org
>> ---
>> fs/nfs/nfs4proc.c |   18 --
>> 1 file changed, 8 insertions(+), 10 deletions(-)
>> 
>> I could send this as an incremental, but that just seems to piss
>> off distributors, who will just squash them all together anyway.
>> 
>> 
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> 
>> diff --git a/fs/nfs/nfs4proc.c b/fs/nfs/nfs4proc.c
>> index 6c61e2b..2662879 100644
>> --- a/fs/nfs/nfs4proc.c
>> +++ b/fs/nfs/nfs4proc.c
>> @@ -254,15 +254,12 @@ static int nfs4_map_errors(int err)
>> };
>> 
>> const u32 nfs4_fs_locations_bitmap[3] = {
>> -FATTR4_WORD0_TYPE
>> -| FATTR4_WORD0_CHANGE
>> +FATTR4_WORD0_CHANGE
>>  | FATTR4_WORD0_SIZE
>>  | FATTR4_WORD0_FSID
>>  | FATTR4_WORD0_FILEID
>>  | FATTR4_WORD0_FS_LOCATIONS,
>> -FATTR4_WORD1_MODE
>> -| FATTR4_WORD1_NUMLINKS
>> -| FATTR4_WORD1_OWNER
>> +FATTR4_WORD1_OWNER
>>  | FATTR4_WORD1_OWNER_GROUP
>>  | FATTR4_WORD1_RAWDEV
>>  | FATTR4_WORD1_SPACE_USED
>> @@ -6763,9 +6760,7 @@ static int _nfs4_proc_fs_locations(struct rpc_clnt 
>> *client, struct inode *dir,
>> struct page *page)
>> {
>>  struct nfs_server *server = NFS_SERVER(dir);
>> -u32 bitmask[3] = {
>> -[0] = FATTR4_WORD0_FSID | FATTR4_WORD0_FS_LOCATIONS,
>> -};
>> +u32 bitmask[3];
>>  struct nfs4_fs_locations_arg args = {
>>  .dir_fh = NFS_FH(dir),
>>  .name = name,
>> @@ -6784,12 +6779,15 @@ static int _nfs4_proc_fs_locations(struct rpc_clnt 
>> *client, struct inode *dir,
>> 
>>  dprintk("%s: start\n", __func__);
>> 
>> +bitmask[0] = nfs4_fattr_bitmap[0] | FATTR4_WORD0_FS_LOCATIONS;
>> +bitmask[1] = nfs4_fattr_bitmap[1];
>> +
>>  /* Ask for the fileid of the absent filesystem if mounted_on_fileid
>>   * is not supported */
>>  if (NFS_SERVER(dir)->attr_bitmask[1] & FATTR4_WORD1_MOUNTED_ON_FILEID)
>> -bitmask[1] |= FATTR4_WORD1_MOUNTED_ON_FILEID;
>> +bitmask[0] &= ~FATTR4_WORD0_FILEID;
>>  else
>> -bitmask[0] |= FATTR4_WORD0_FILEID;
>> +bitmask[1] &= ~FATTR4_WORD1_MOUNTED_ON_FILEID;
>> 
>>  nfs_fattr_init(_locations->fattr);
>>  fs_locations->server = server;
>> 
> 

--
Chuck Lever

Bug#898946: sbuild: --make-binNMU should imply --no-arch-all

[Niko Tyni]

Package: sbuild
Version: 0.76.0-1
User: debian-p...@lists.debian.org
Usertags: hh2018

When building a binNMU, it makes no sense to build architecture:all
packages.  So the default of $build_arch_all=1 should be overridden in
this case, as if --no-arch-all had been passed.
-- 
Niko Tyni   nt...@debian.org

Bug#898891: firejail-profiles: firejail --name=... can no longer be used with the firefox profile

[Reiner Herrmann]

Hi Vincent,

On Thu, May 17, 2018 at 09:32:20AM +0200, Vincent Lefevre wrote:
> With the previous profiles, I could use the following firefox script:
> 
> exec /usr/bin/firejail --name=firefox firefox-esr "$@"
> 
> and everything was fine. After starting firefox, I could open a
> new URL with it and didn't get any error. For instance:
> 
[...]
> 
> With the new profile, the URL is still opened, but firejail now
> terminates with an exit status 1. For instance:
> 
> cventin:~> firefox http://localhost/
> zsh: exit 1 firefox http://localhost/
> cventin:~[1]>

I'm currently not able to reproduce it.

% cat `which firefox`
#!/bin/sh
exec /usr/bin/firejail --name=firefox firefox-esr "$@"
% firefox --private http://debian.org
Reading profile /etc/firejail/firefox-esr.profile
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-devel.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
Parent pid 28995, child pid 28996
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
Warning fseccomp: syscall "ni_syscall" not available on this platform
Warning fseccomp: syscall "umount" not available on this platform
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 110.13 ms
[...]
Parent is shutting down, bye...
% echo $?
0
%

I assume you are also using the current Firefox ESR version 52 (52.8.0esr-1)?
Are you using any addons or so that could influence the exit code?

Regards,
   Reiner


signature.asc
Description: PGP signature

Bug#898945: grub-installer: Installing to a raid 1 set on NVMe devices does not work

[Hans van den Bogert]

Package: grub-installer
Version: 1.128
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu cosmic ubuntu-patch

Dear Maintainer,

What led up to the situation?
installing ubuntu
What exactly did you do (or not do) that was effective (or
 ineffective)?
installing ubuntu on raid1 on NVMe devices
What was the outcome of this action?
grub-installer fails with something like "cannot install to /dev/md0"
What outcome did you expect instead?
Grub-installer is successful




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

Description: Add support for installation on NVMe with RAID1
Author: Hans van den Bogert 
Bug: https://bugs.launchpad.net/ubuntu/+source/grub-installer/+bug/1771845
---
This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
Index: grub-installer-1.128ubuntu8/grub-installer
===
--- grub-installer-1.128ubuntu8.orig/grub-installer
+++ grub-installer-1.128ubuntu8/grub-installer
@@ -785,7 +785,7 @@ case $ARCH:$grub_package in
use_disks=
for frdisk_one in $frdisk_list; do
prefix=$(echo "$frdisk_one" | \
- sed 
's:\(/dev/\(cciss\|ida\|rs\)/c[0-9]d[0-9][0-9]*\|/dev/mmcblk[0-9]\|/dev/\(ad\|da\)[0-9]\+\|/dev/[a-z]\+\).*:\1:')
+ sed 
's:\(/dev/\(cciss\|ida\|rs\)/c[0-9]d[0-9][0-9]*\|/dev/mmcblk[0-9]\|/dev/\(ad\|da\)[0-9]\+\|/dev/nvme[0-9]n[0-9]\|/dev/[a-z]\+\).*:\1:')
disks="${disks:+$disks }$prefix"
case $prefix in

/dev/[hmsv]d[a-z]|/dev/xvd[a-z]|/dev/cciss/c[0-9]d[0-9]*|/dev/ida/c[0-9]d[0-9]*|/dev/rs/c[0-9]d[0-9]*|/dev/mmcblk[0-9]|/dev/ad[0-9]*|/dev/da[0-9]*|/dev/fio[a-z]|/dev/nvme[0-9]n[0-9])


Thanks for considering the patch.


-- System Information:
Debian Release: buster/sid
  APT prefers bionic-updates
  APT policy: (500, 'bionic-updates'), (500, 'bionic-security'), (500, 'bionic')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.15.0-20-generic (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru grub-installer-1.128ubuntu8/debian/control 
grub-installer-1.128ubuntu9/debian/control
--- grub-installer-1.128ubuntu8/debian/control  2017-01-16 02:31:58.0 
+0100
+++ grub-installer-1.128ubuntu9/debian/control  2018-05-17 18:16:35.0 
+0200
@@ -1,8 +1,7 @@
 Source: grub-installer
 Section: debian-installer
 Priority: standard
-Maintainer: Ubuntu Installer Team 
-XSBC-Original-Maintainer: Debian Install System Team 

+Maintainer: Debian Install System Team 
 Uploaders: Otavio Salvador , Felix Zielcke 
, Colin Watson , Christian Perrier 
, Steve McIntyre <93...@debian.org>
 Build-Depends: debhelper (>= 9), po-debconf (>= 0.5.0), libparted-dev
 XS-Debian-Vcs-Browser: 
http://anonscm.debian.org/gitweb/?p=d-i/grub-installer.git
diff -Nru grub-installer-1.128ubuntu8/debian/patches/pc-mdadm-nvme.diff 
grub-installer-1.128ubuntu9/debian/patches/pc-mdadm-nvme.diff
--- grub-installer-1.128ubuntu8/debian/patches/pc-mdadm-nvme.diff   
1970-01-01 01:00:00.0 +0100
+++ grub-installer-1.128ubuntu9/debian/patches/pc-mdadm-nvme.diff   
2018-05-17 18:16:18.0 +0200
@@ -0,0 +1,18 @@
+Description: Add support for installation on NVMe with RAID1
+Author: Hans van den Bogert 
+Bug: https://bugs.launchpad.net/ubuntu/+source/grub-installer/+bug/1771845
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+Index: grub-installer-1.128ubuntu8/grub-installer
+===
+--- grub-installer-1.128ubuntu8.orig/grub-installer
 grub-installer-1.128ubuntu8/grub-installer
+@@ -785,7 +785,7 @@ case $ARCH:$grub_package in
+   use_disks=
+   for frdisk_one in $frdisk_list; do
+   prefix=$(echo "$frdisk_one" | \
+-sed 
's:\(/dev/\(cciss\|ida\|rs\)/c[0-9]d[0-9][0-9]*\|/dev/mmcblk[0-9]\|/dev/\(ad\|da\)[0-9]\+\|/dev/[a-z]\+\).*:\1:')
++sed 
's:\(/dev/\(cciss\|ida\|rs\)/c[0-9]d[0-9][0-9]*\|/dev/mmcblk[0-9]\|/dev/\(ad\|da\)[0-9]\+\|/dev/nvme[0-9]n[0-9]\|/dev/[a-z]\+\).*:\1:')
+   disks="${disks:+$disks }$prefix"
+   case $prefix in
+   
/dev/[hmsv]d[a-z]|/dev/xvd[a-z]|/dev/cciss/c[0-9]d[0-9]*|/dev/ida/c[0-9]d[0-9]*|/dev/rs/c[0-9]d[0-9]*|/dev/mmcblk[0-9]|/dev/ad[0-9]*|/dev/da[0-9]*|/dev/fio[a-z]|/dev/nvme[0-9]n[0-9])
diff -Nru 

Bug#898944: CVE-2018-6561

[Moritz Muehlenhoff]

Source: dojo
Severity: grave
Tags: security

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-6561

Cheers,
Moritz

Bug#898943: Multiple vulnerabiliities in Mongoose

[Moritz Muehlenhoff]

Source: smplayer
Severity: grave
Tags: security

smplayer seems to embed Cesenta Mongoose:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-2891
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-2892
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-2893
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-2894
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-2895
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-2909
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-2921
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-2922

Cheers,
Moritz

Bug#898942: goaccess: can't run two instances simultaneously

[Ricardo Mones]

Package: goaccess
Severity: important
Tags: upstream

Dear maintainer,

When trying to view two different logs on the same machine at the
same time the first one works, but the second is stopped after log
format selection.

If you exit first one, the second one continues. After fiddling whith
strace seems the one which locks is trying to access a file which is
probably opened by the other:

lstat("/tmp", {st_mode=S_IFDIR|S_ISVTX|0777, st_size=16384, ...}) = 0
lstat("/tmp/-1mdb_agent_keys.tcb", {st_mode=S_IFREG|0644, st_size=266752, ...}) 
= 0
futex(0x7fcd274ec3b8, FUTEX_WAKE_PRIVATE, 2147483647) = 0
open("/tmp//-1mdb_agent_keys.tcb", O_RDWR|O_CREAT, 0644) = 4
fcntl(4, F_SETLKW, {l_type=F_WRLCK, l_whence=SEEK_SET, l_start=0, l_len=0}

At first glance seems goaccess should be generating different database
paths for different processes. Or maybe it already tries but some piece
of info failed here and is not checked, because the prepended '-1' looks
very much like a result from a failed call.

Note this doesn't happen on current stable version, which allowed me
to see both files without trouble. Note also this version I'm using is
an unmodified backport of current sid version to stretch. The only
difference with sid's package is the version of the Build-Depends used
to build it, which are the ones from stable, of course.

thanks in advance,

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

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

Versions of packages goaccess depends on:
ii  libc6 2.24-11+deb9u3
ii  libgeoip1 1.6.9-4
ii  libglib2.0-0  2.50.3-2
ii  libncurses5   6.0+20161126-1+deb9u2
ii  libtinfo5 6.0+20161126-1+deb9u2

goaccess recommends no packages.

goaccess suggests no packages.

Bug#896698: autopkgtest | add recommended packages to test dependencies when needs-recommends is defined (!12)

[Paul Gevers]

Control: tags -1 patch
Control: forwarded -1 
https://salsa.debian.org/ci-team/autopkgtest/merge_requests/12

Hi Martin,

On 17-05-18 11:20, Martin Pitt wrote:
> TBH I don't like this magic at all; it doesn't take into account virtual
> packages, version/architecture constraints, etc.

Hmm, indeed.

> It seems to only add
> this to the test dependencies if the package name actually exists (thus
> failing on unsatisfiable versions); how does this cause a failure if the
> package does /not/ exist (i. e. |apt-cache show| fails)?

It will typically fail during running the test and it will be unclear
why. What I try to get here is that it fails (most of the times) with a
clearer error message. See e.g.:
https://ci.debian.net/data/autopkgtest/testing/amd64/j/jupyter-sphinx-theme/248894/log.gz

> If a user installs a package with a non-available Recommends:, it will
> also not fail. Sure this is a packaging error, but one that britney
> should report and complain about, not autopkgtest.

The problem is that britney still triggers the test. Also, it may only
be a problem of the TEST dependencies. I don't think britney should
check those to be honest. So *if* we agree on that, it is up to
autopkgtest to try to create a error message that is as clear as possible.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#898941: caffe-cpu: Very different results for gpu and cpu calculations due to possibly problematic BLAS dependency

[Christoph Wiedemann]

Package: caffe-cpu
Severity: important

Dear Maintainer,

I'm getting very different results in cpu mode compared to gpu mode, when using 
the libblas3 (version 3.7.0-2) package. 
After installing the libopenblas-base package (version 0.2.19-3) the problems 
disappeared. I don't know whether
this is a dependency problem of the package or it is a known problem in 
libblas3. I was able to uninstall and install
libopenblas-base while libblas3 was still being installed, which is a little 
bit confusing to me.

Note that I reported the bug initially here: 
https://github.com/twhui/MSG-Net/issues/2

Note also that this bug has been found with a recompiled package with matlab 
support enabled. I used this howto
https://github.com/BVLC/caffe/blob/master/docs/install_apt_debian.md, and 
changed only the matlab options. However, 
I don't think that the behaviour is visible in matlab only, though I didn't try 
this.

Kind Regards
Christoph

-- System Information:
Debian Release: 9.4
  APT prefers stable
  APT policy: (1000, 'stable'), (900, 'stable'), (500, 'stable-updates')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages caffe-cpu depends on:
pn  caffe-tools-cpu  
ii  libblas3 [libblas.so.3]  3.7.0-2
pn  libcaffe-cpu1
ii  libopenblas-base [libblas.so.3]  0.2.19-3
pn  python3-caffe-cpu

caffe-cpu recommends no packages.

Versions of packages caffe-cpu suggests:
pn  caffe-doc 
pn  libcaffe-cpu-dev  

Bug#898940: lastpass-cli: error: Peer certificate cannot be authenticated with given CA certificates

[Chris Lamb]

Package: lastpass-cli
Version: 1.0.0-1.2
Severity: serious

Hi,

As of today, lpass is no longer working for me:

  $ lpass login f...@bar.com
  Error: Peer certificate cannot be authenticated with given CA certificates.

FYI the CHANGELOG.md mentions:

 # Version 0.8.1, 0.7.2, 0.6.1, 0.5.1
 * This update to all recent versions switches to the platform certificate
   store and adds pinning of LastPass public keys, in preparation for
   certificate changes at lastpass.com. Upgrade will be needed to avoid 
"Peer
   certificate cannot be authenticated with given CA certificates" errors
   when the cert changes are made.


Regards,

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

Bug#898021: linux-image-4.16.0-1-amd64: kernel 4.16 infinite wait after dm login on ivy bridge and bay trail

[Holger Schröder]

Any news to fix this behavior?


Greetings...

Bug#898937: ITP: hunspell-lv -- Latvian dictionary for hunspell spellchecker

[Agustin Martin]

On Thu, May 17, 2018 at 05:31:23PM +0200, Rene Engelhard wrote:
> On Thu, May 17, 2018 at 05:01:09PM +0200, Agustin Martin wrote:
> > This dictionary contains Latvian wordlists for the hunspell
> > spellchecker currently supported by Mozilla and OpenOffice,
> > plus a Latvian hyphenation pattern for OpenOffice.
> > 
> > These sources will create a hunspell-lv binary package that will replace
> > myspell-lv binary package. However, current myspell-lv sources will stay and
> > will still be used to create the Latvian aspell dictionary package.
> 
> And it should create a hyphen-lv.

Good point, thanks for reminding.

Regards,

-- 
Agustin

Bug#898875: ci.debian.net: Should produce valid NetBIOS names

[Paul Gevers]

Control: tags -1 moreinfo

Hi Mathieu,

Thanks for reporting issues you experience.

On 16-05-18 23:50, Mathieu Parent wrote:
> Since samba 2:4.8.1+dfsg-1, smb.conf is parsed and checked in
> samba-common-bin.postinst (See #816301 and [1]).
> 
> This makes samba failing on ci.debian.net with:
> Checking smb.conf
> WARNING: The "syslog" option is deprecated
> netbios name SAMBA-1526494156 is not a valid netbios name
> ERROR: Invalid smb.conf
> dpkg: error processing package samba-common-bin (--configure):
> 
> (https://ci.debian.net/data/autopkgtest/unstable/amd64/s/samba/309683/log.gz)
> 
> NB: A valid NetBIOS name at most 15 chars of alphanum or " !#$%&'()-.@^_{}~".

I don't see debci (or autopkgtest) set any netbios name anywhere (tell
me where to look if you think it does, I checked for "netbios" and
"samba" case insensitive).

Furthermore, I don't think it is up to debci or autopkgtest to actually
set this at all, so if you need a (valid) netbios name in your test, you
should generate one yourself.

Or is it a mandatory variable to set for any computer? And where should
it be set then?

Paul



signature.asc
Description: OpenPGP digital signature

Bug#898934: transition: libmygpo-qt

[Emilio Pozuelo Monfort]

Control: tags -1 confirmed

On 17/05/18 16:49, cont...@thomaspierson.fr wrote:
> Package: release.debian.org
> User: release.debian@packages.debian.org
> Usertags: transition
> Severity: normal
> 
> Hello,
> 
> I uploaded a new version of libmygpo-qt (1.1.0-1) to experimental rebuilt
> against Qt5 which introduces
> ABI changes. I need a transition slot.
> 
> The transition is already auto-tracked here:
> * https://release.debian.org/transitions/html/auto-libmygpo-qt.html
> 
> The following packages will be affected by the transition:
> 
> * clementine : 1.3.1+git426-gb8381321c+dfsg-1 version ready in experimental.
> * amarok : #896941

Go ahead.

Emilio

Bug#887861: Enable NetworkManager.wait-online.service on diskful workstations

[Mike Gabriel]

Hi Wolfgang,

On Thursday, May 17, 2018, Wolfgang Schweer wrote:
> On Thu, May 17, 2018 at 10:42:13AM +, Mike Gabriel wrote:
> > On  Di 15 Mai 2018 22:14:22 CEST, Wolfgang Schweer wrote:
> > 
> > > It works for me too (virtual network, no real world deployment
> > > available), if all entries except the loopback ones are commented.
> > > 
> > 
> > So, you are saying that all network entries except loopback are commented
> > out by defaut on workstation installations on buster? Also on stretch? I
> > don't fully get what you mean by the last mail.
> 
> Maybe some sort of misunderstanding.
> What I meant is: I tried with the loopback entries as only ones and can 
> confirm that it works as well. So the mostly empty interface file could 
> (should) be the default…
> 
> > Note: this is not about NIC names, but about the NIC being commented out or
> > not. On stretch, I have seen auto eth0 and inet eth0 ... being active and
> > thus being ignored by the NetworkManager-wait-online.service.
> 
> Same for Buster.
> 
> Wolfgang
>

I somehow feel, this is worth a stretch-pu...

Mike

-- 
Sent from my Fairphone (powered by SailfishOS)

Bug#898939: Framebuffer confusion in "Normal Install"

[EoflaOE ViceCity]

Package: debian-installer
Version: 9.4
Disk: Debian GNU/Linux 9.4.0 "Stretch" - Official i386 NETINST
20180310-11:55

I have made a USB which has the Debian Installer (NETINST) with the
required firmwares needed for my PC and my WiFi USB adapter (D-Link,
Realtek RTL8192CU or RTL8188CUS) and I have experienced a symptom:

A person who can write quickly can also confuse the framebuffer by pressing
 on the right hand and the  and then  as fast as he/she can.

As this happens, the screen updates slowly from framebuffer to console, and
then updates quickly from console to framebuffer. A user might have pressed
 at the time the computer is updating the screen from framebuffer to
console.

This causes the framebuffer to be confused by which TTY has to display, and
sometimes the framebuffer will display a half of TTY1 and a half of TTY4,
and sometimes the  key freezes and he/she has to write or press arrow
keys to make some input,but the screen isn't updating, then he/she has to
go to TTY4 to get the TTY1 screen.

After this issue manifests, he/she has to restart the computer to restart
the installation to restore the expected behavior.

The framebuffer TTY1 has the Unifont font while the others stay on their
own defined fonts (the default one).

Steps to Reproduce:

1. Reboot your computer to Debian Installer (Text)
2. Press  at the right hand and hold it
3. Don't release  and press on the left hand on the fourth finger the
 and on the smallest finger the  as fast as you can
4. When your timings is correct, you will experience confusions in
framebuffer.

System specs:

- KT4AV MS-6712
- AMD Athlon XP 1500+
- ATI Radeon 9200 Series
- 2GB RAM (512MB x2, 1GB x1)
- Acer V193W
- Wireless Mouse + PS/2 Keyboard

Kernel version: 4.9.0-6 4.9.82-1+deb9u3_i386

Bug#898938: ITP: reactphp-socket -- Asynchronous client and server socket connections for ReactPHP

[Dominik George]

Package: wnpp
Severity: wishlist
Owner: Dominik George 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

* Package name: reactphp-socket
  Version : 0.8.11
  Upstream Author : Igor Wiedler, Chris Boden
* URL : https://github.com/reactphp/socket
* License : MIT
  Programming Lang: PHP
  Description : Asynchronous client and server socket connections for 
ReactPHP

-BEGIN PGP SIGNATURE-

iQKJBAEBCABzFiEEPJ1UpHV1wCb7F/0mt5o8FqDE8pYFAlr9pk0xGmh0dHBzOi8v
d3d3LmRvbWluaWstZ2VvcmdlLmRlL2dwZy1wb2xpY3kudHh0LmFzYyMcZG9taW5p
ay5nZW9yZ2VAaXQucGlyYXRlbnBhcnRlaS5kZQAKCRC3mjwWoMTylsFeD/9qCOYP
rWLYG/OVv9iW5wHlygK8I/9BgEYopJ3AizNeqo/86+2jmtWLjcoSBaKS5//fVzwb
o4le2HOHv53qOktP8OzG+3VwpCqFevLkeV8Oj1qAWCcBFZTGUrj0B1F7DI4beQY3
/f8aeplIyw5NV5PrYr90aoglXmmDZJyGnBj/5QvMl86dKBx3yPkBmMsk74nPiynP
3H6i2PxeSp3Iq0yMSpv2ruvhOow8f7uZyt5VUqxy3bQlji/GZIrJv/ogoSfozi5X
1u503tSb3X81aAyDgGNT3X3cykQ6yAU3KvJYxcJ9bLtLZG4x0OJyFPvAVPM5xl/G
YkgdN2OEhmU7WTahwN+wT397g67nuaxsKcSfxS4UCQZe4m9jeypOaZdNUkg2/id4
ZLl2WNh83xaaSbXhPhRf+akticv1/SWPgXvULk+GHuk1rwl8ojleDVF5ELVjD8p2
soiENkgZ7uq9BrNNhI2CsuwOnAkx9ttRyUym9UnUEoDjNs2/lLKT+CVqFW0oYPc5
TGdNpwU/qOaCfa8OjgofrKLITkkg0RD7t0Vr05GcqX/wuysZz1d13H++1pO3keQH
1ITBLWTvDiNPKY/lbjh4ymqDv+BGPBRCqjq1oQDxs6lP+Oc01C3gF4Vk+GwcovOq
NusQy/BsmymP3sOHTXyooBcC+VLvCWA/XztD1A==
=ATJ3
-END PGP SIGNATURE-

Bug#876057: lists.debian.org: Request for new mailing list: debian-nvidia

[Luca Boccassi]

Control: close -1

On Thu, 2018-05-17 at 17:30 +0200, Alexander Wirt wrote:
> On Mon, 18 Sep 2017, Luca Boccassi wrote:
> 
> > Package: lists.debian.org
> > Severity: wishlist
> > 
> > Name: debian-nvidia
> > 
> > Rationale:
> > 
> > Currently we use pkg-nvidia-devel on Alioth to discuss development
> > related to the Nvidia drivers and their userspace stack (CUDA etc),
> > both among developers and engaged users.
> > For example, sometimes we have users who volunteer to test pre-
> > upload
> > new versions of the drivers and we use the mailing list to discuss
> > the
> > effort.
> > We also use it among developers to coordinate effort, which often
> > does
> > not map directly to a bug. There are 4 active developers, and other
> > less-active ones, at the moment.
> > With the deprecation of Alioth we'd be missing a public equivalent,
> > so
> > we would like to request the creation of a debian-nvidia list, if
> > possible.
> 
> I don't think it makes sense to create an nvidia specific
> mailinglist. If you
> want some generic mailinglist for packaging and discussion about all
> gpus,
> fine. 

The nvidia list got moved onto the Alioth lists replacement system, so
we're good - I'll close this.

-- 
Kind regards,
Luca Boccassi

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

Bug#898921: chown: please consider dropping the dot separator fallback

[Michael Stone]

On Thu, May 17, 2018 at 05:21:34PM +0200, Ferenc Wágner wrote:

Michael Stone  writes:

On Thu, May 17, 2018 at 04:15:44PM +0200, you wrote:


Michael Stone  writes:


It would not--POSIX does not disallow the . syntax.


(This is not my point, but in my reading
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/chown.html
does not allow it: "The BSD syntax user[. group] was changed to user[:
group] in this volume of POSIX.1-2017...")


The new syntax was introduced.


No new syntax was introduced, "the BSD syntax was *changed*".  But this
isn't from the normative section, so nevermind.


BSD != POSIX. At one point the standard mandated the original BSD 
syntax, then the standard changed to mandate a new syntax. In all cases 
POSIX specifies a *subset* of behavior of standard utilities, so 
anything that isn't expressly forbidden is simply undefined; 
POSIX-compliant implementations are required to support the new syntax, 
but nothing is said about supporting the old syntax. The lines you keep 
quoting are there to explain the rationale for why the new syntax was 
invented, nothing more.



It does not say anything like "MUST NOT accept . syntax".


Nor like MUST NOT accept ! syntax or % syntax or @ syntax or ..:)


Correct, those would all be valid (though unlikely to be implemented 
because there isn't a reason to do so).



Rather, I meant that adduser could be configured *by default* to not
require --force-badname for adding perfectly valid POSIX user names.


It can be, someone's simply decided not to. I think that's dumb, but
¯\_(ツ)_/¯


OK, I'll link our discussion into #604242 to see if anything can change
now.


FWIW, debian seems to be fairly unique in deciding that dot-names can't 
be supported. They work just fine by default on fedora, openbsd, etc., 
all of which support the legacy chown syntax without all this 
hand-wringing...


Mike Stone

Bug#898757: musescore: Backtrace for crash on startup

[Thorsten Glaser]

tags 898757 - moreinfo
tags 898757 + confirmed
severity 898757 important
thanks

Giovanni Mascellani dixit:

>Here you have a backtrace of the startup crash, which I guess is the
>same of the original poster.

It’s on amd64, but thanks anyway, this helps.

>Removing configuration and cache files does not seem to help.

I wasn’t able to reproduce this even *with* removing them, but I
found out the cause by looking at your stack trace.

I removed all configuration and cache files, then started musescore
with the default empty score, hit ‘P’ to display the piano, exited
musescore, and started it again; this does indeed trigger the crash.

I’ll analyse it and/or give it for upstream to deal with.

In the meantime, you can start MuseScore again by editing the file
~/.config/MuseScore/MuseScore2.ini and setting the showPianoKeyboard
entry in the [MainWindow] section to “false”. (Note that, when you
start MuseScore again, the piano will be once again active, so after
exiting it will set this back to “true” so you’ll have to disable the
piano before exiting.)

Thanks for the extra information,
//mirabilos
-- 
I believe no one can invent an algorithm. One just happens to hit upon it
when God enlightens him. Or only God invents algorithms, we merely copy them.
If you don't believe in God, just consider God as Nature if you won't deny
existence.  -- Coywolf Qi Hunt

Bug#898867: lintian: embedded-php-library libmarkdown-php vs. php-markdown confusion

[Thorsten Glaser]

Hi,

>> Now, the 1.0 version allegedly has a feature in that it can be
>> used as Wordpress plugin or something, so perhaps this situation
>> is deliberate, but even so, shouldn’t the warning point to the
>> newer package or even better both?
>
>Let's await input from the markdown maintainers themselves - I have
>not used these libraries.

indeed, just mind that Nik and I just took over php-markdown by request
of Florian, the former maintainer.

>> Considering apt-cache rdepends libmarkdown-php shows zero packages
>> depending on it, perhaps the older 1.0 version can even be RM’d?
>
>Same for this. :)

True.

>> Cc’ing GCS as libmarkdown-php maintainer.
>
>Did you skip this? I don't see an X-Debbugs-CC…

I told reportbug to add him (‘s’ after the editor), and it delivered
the initial message (according to the log on the web frontend to
debbugs); other than that, no idea… let’s just add an explicit Cc,
to make sure.

bye,
//mirabilos
-- 
> Hi, does anyone sell openbsd stickers by themselves and not packaged
> with other products?
No, the only way I've seen them sold is for $40 with a free OpenBSD CD.
-- Haroon Khalid and Steve Shockley in gmane.os.openbsd.misc

Bug#894081: dbgsym packages for packages in security archive

[Salvatore Bonaccorso]

Hi Kevin,

On Thu, May 10, 2018 at 02:26:28AM -0400, Kevin Easton wrote:
> Would it be possible to get a debian-debug archive added to security.d.o
> where the accompanying -dbgsym packages for packages in the debian-security
> archive get uploaded?
> 
> Eg. currently libssl1.1 version 1.1.0f-3+deb9u2 is present in the 
> debian-security archive, but this version of libssl1.1-dbgsym isn't
> available (I think this means if you had manually installed the -dbgsym
> package, you wouldn't get the security update with a plain
> "apt-get upgrade"?).
> 
> Apologies if this is already being worked on, I didn't see any
> discussion of it.

There is a tracking bug for this: https://bugs.debian.org/894081

In short: no unfortunately there is no dbgsym archive yet (although
the dbgsym packages are stored).

Regards,
Salvatore

Bug#898937: ITP: hunspell-lv -- Latvian dictionary for hunspell spellchecker

[Rene Engelhard]

On Thu, May 17, 2018 at 05:01:09PM +0200, Agustin Martin wrote:
> This dictionary contains Latvian wordlists for the hunspell
> spellchecker currently supported by Mozilla and OpenOffice,
> plus a Latvian hyphenation pattern for OpenOffice.
> 
> These sources will create a hunspell-lv binary package that will replace
> myspell-lv binary package. However, current myspell-lv sources will stay and
> will still be used to create the Latvian aspell dictionary package.

And it should create a hyphen-lv.

Regards,

Rene

Bug#876057: lists.debian.org: Request for new mailing list: debian-nvidia

[Alexander Wirt]

On Mon, 18 Sep 2017, Luca Boccassi wrote:

> Package: lists.debian.org
> Severity: wishlist
> 
> Name: debian-nvidia
> 
> Rationale:
> 
> Currently we use pkg-nvidia-devel on Alioth to discuss development
> related to the Nvidia drivers and their userspace stack (CUDA etc),
> both among developers and engaged users.
> For example, sometimes we have users who volunteer to test pre-upload
> new versions of the drivers and we use the mailing list to discuss the
> effort.
> We also use it among developers to coordinate effort, which often does
> not map directly to a bug. There are 4 active developers, and other
> less-active ones, at the moment.
> With the deprecation of Alioth we'd be missing a public equivalent, so
> we would like to request the creation of a debian-nvidia list, if
> possible.
I don't think it makes sense to create an nvidia specific mailinglist. If you
want some generic mailinglist for packaging and discussion about all gpus,
fine. 

Alex



signature.asc
Description: PGP signature

Bug#898921: chown: please consider dropping the dot separator fallback

[Ferenc Wágner]

Michael Stone  writes:

> On Thu, May 17, 2018 at 04:15:44PM +0200, you wrote:
>
>> Michael Stone  writes:
>>
>>> It would not--POSIX does not disallow the . syntax.
>>
>> (This is not my point, but in my reading
>> http://pubs.opengroup.org/onlinepubs/9699919799/utilities/chown.html
>> does not allow it: "The BSD syntax user[. group] was changed to user[:
>> group] in this volume of POSIX.1-2017...")
>
> The new syntax was introduced.

No new syntax was introduced, "the BSD syntax was *changed*".  But this
isn't from the normative section, so nevermind.

> It does not say anything like "MUST NOT accept . syntax".

Nor like MUST NOT accept ! syntax or % syntax or @ syntax or ..:)

>> Rather, I meant that adduser could be configured *by default* to not
>> require --force-badname for adding perfectly valid POSIX user names.
>
> It can be, someone's simply decided not to. I think that's dumb, but
> ¯\_(ツ)_/¯

OK, I'll link our discussion into #604242 to see if anything can change
now.
-- 
Thanks,
Feri

Bug#898937: ITP: hunspell-lv -- Latvian dictionary for hunspell spellchecker

[Agustin Martin]

Package: wnpp
Severity: wishlist
Owner: Agustin Martin Domingo 

* Package name: hunspell-lv
  Version : 1.3.0
  Upstream Author : Janis Eisaks 
* URL : http://openoffice-lv.sourceforge.net/openoffice.html
* License : LGPL 2.1+
  Description : Latvian dictionary for hunspell spellchecker

This dictionary contains Latvian wordlists for the hunspell
spellchecker currently supported by Mozilla and OpenOffice,
plus a Latvian hyphenation pattern for OpenOffice.

These sources will create a hunspell-lv binary package that will replace
myspell-lv binary package. However, current myspell-lv sources will stay and
will still be used to create the Latvian aspell dictionary package.

-- 
Agustin

Bug#898690: CELT PLC broken

[Ron]

Control: found -1 1.2~alpha2-1
Control: tags -1 + pending

Hi,

On Tue, May 15, 2018 at 09:24:05AM +0200, Steinar H. Gunderson wrote:
> PLC is all broken for CELT in 1.2.1 due a patch that optimized celt_fir() for 
> ARM;
> it mostly outputs just silent frames. (You can reproduce it by giving -loss to
> opus_demo.)

It looks like the patch which caused this regression was two commits
before the 1.2-alpha2 tag, which we shipped for Stretch, so I'm marking
this as found there too, in case someone else hits it there later.


> Until 1.3 comes out, which could be a while, would you be willing
> to carry this patch from upstream?
>
>   
> https://gitlab.xiph.org/xiph/opus/blob/072d133f7899c4783e67f90d07ab25b3b8414b8f/celt/celt_lpc.c
>
> There's one more patch that looks relevant 
> (92ffce621df6ace95267ac8c13aa0d862f6a476b),
> but I haven't tried it, and at least for my limited testing, the first one 
> seems
> sufficient.

I just missed catching you in #opus, which might have saved you
repeating what you found here, if I'd seen that before I saw this :)
But at least we have a report for anyone who might also hit it in
Stretch, and this is what we decided there after you'd gone:

The upstream plan is to tag at least a 1.3-rc "sometime soon", and at
present there are no known regressions in what's currently committed
to that branch - so since we've got some breathing space before the
next freeze, then rather than cherry-picking just that one patch,
I'll push out a snapshot from git head which contains it and all the
other fixes to date, including the new 'hardening' sanity checks and
the tuning improvements.

Then we can get some extra testing on those too, which will increase
the confidence for making a formal 1.3 release if nothing extra shakes
out of it.

Thanks for digging into this and reporting it.

  Cheers,
  Ron

Bug#898773: RFS: python-fibra/0.0.17-1 [ITP 898736]

[Mario Frasca]

good day here again

I have:
- accepted all debian patches from 0.0.17-1 into upstream 0.0.18,
- removed the warnings that were in the `debuild` report,
- uploaded a new 0.0.18-1, it is now free from warnings,

further:
- I built a new bauble-1.0.56-1, resolving issue 755185,
- bauble-1.0.56-1 still has `debuild` warnings I want to solve,
- bauble-1.0.56-1 depends on python-fibra.

best regards,
MF

On Tue, 15 May 2018 20:55:52 + Jeremy Stanley  wrote:
> On 2018-05-15 14:20:15 -0500 (-0500), Mario Frasca wrote:
> [...]
> > it was developed between 2008-11 (0.0.6) and 2009-8 (0.0.17)
> > [...]
>
> The dates made me strongly suspect, but skimming the upstream source
> confirms, this is very much not a Py3K-ready library. Are you
> becoming de facto upstream for this and planning to update it to
> support Python 3.x in preparation for 2.7 reaching end of life?
> --
> Jeremy Stanley
>
>

Bug#896674: Pam Auth Issues

[Christian Ehrhardt]

If you happened to find or block on pam auth in 2.3.1 here a few Details.
I ran into the same when testing.

Exhaustive debugging led me to enough data to find [1] and from there
[2][3].
With this applied until upstream settles how they want to resolve it
eventually things work much better for me.

Hope that helps on your >=2.3.1 efforts.

[1]: https://bugzilla.redhat.com/show_bug.cgi?id=1564348
[2]: https://github.com/dovecot/core/pull/71
[3]:
https://github.com/dovecot/core/pull/71/commits/3a3d9c77c243bc1097039cb70a0029e0c108efbb

-- 
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd

Bug#898731: myspell-lv: Convert into dummy transitional package and migrate content to hunspell-lv

[Agustin Martin]

On Tue, May 15, 2018 at 04:03:39PM +0200, Pander wrote:
> Package: myspell-lv
> Version: 0.9.6-5
> Severity: normal
> Tags: l10n

Hi,

> Convert myspell-lv into dummy transitional package and move its contents
> to hunspell-lv. hunspell-lv is now a virtual package. Gradually phase out the 
> transitional package myspell-lv that will need to get a dependency on 
> hunspell-lv.

This is a different case than ispell-fo, where dict was a myspell dict that
could be used by hunspell and there was no hunspell only dict equivalent.

In this case newer versions of the dict (above 1.0) are hunspell dicts using
hunspell specific features. They are created by the same author and are
indeed better than old ones.

There is no hunspell-lv in libreoffice dictionaries, but I was playing with
this hunspell-lv package a while ago. I will resume my work on it to prepare
a real hunspell-lv package. I will then make myspell-lv a transitional
package.

Note that this also needs some dependencies in the hunspell-lv side,
these transitions are not only a matter of myspell-xx package (and so if a
dict from libreoffice-dictionaries is involved, good coordination is
required).

> Myspell is no longer
> shipped and most other packages have migrated to the Hunspell package
> names. For example, see also
> https://packages.debian.org/stretch/myspell-af and
> https://packages.debian.org/stretch/myspell-ca 

> Note that the internal
> format of the files for Myspell and Hunspell is identical, so this
> concerns only the packaging

As said, this is not true. myspell dicts can be used by hunspell, but
hunspell-only dicts cannot be used by myspell.

Thanks for reminding me about the hunspell-lv package.

Regards,

-- 
Agustin

Bug#898936: ITP: reactphp-promise-stream -- Link between promises and streams in ReactPHP

[Dominik George]

Package: wnpp
Severity: wishlist
Owner: Dominik George 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

* Package name: reactphp-promise-stream
  Version : 1.1.1
  Upstream Author : Christian Lück 
* URL : https://github.com/reactphp/promise-stream
* License : MIT
  Programming Lang: PHP
  Description : Link between promises and streams in ReactPHP

-BEGIN PGP SIGNATURE-

iQKJBAEBCABzFiEEPJ1UpHV1wCb7F/0mt5o8FqDE8pYFAlr9mH0xGmh0dHBzOi8v
d3d3LmRvbWluaWstZ2VvcmdlLmRlL2dwZy1wb2xpY3kudHh0LmFzYyMcZG9taW5p
ay5nZW9yZ2VAaXQucGlyYXRlbnBhcnRlaS5kZQAKCRC3mjwWoMTylk+ZD/0eoPFy
8jkY21qKpmdpyuEdgBCiGKAMBfmNu0R+D9wV1L2cdr2MFEuWXnk2p2r6vgjK2E8E
5yP0UoKjGor6fiRkVRLg/TJch369tEuL54fJOCnF/UHPrJDzU4bqLDdeAZBMtQRq
pCSwhIThjbPmI9NB2ihFqBZTTpVyuoLS0DNlzBtVoYue+9BRKVqALj9it/1L/rHo
OmtlTgXxH9+8uYFPxRxzCNL+WKiwTQx8AAg0SAHX/tqXSRiv8H/P/P6oErrC+mIP
EUKFcHt1vPTZeGYhIInclsNa2UEKRV4fP+/XZ3kHa8XFzSXNnBT+oUQE7rTPhKPN
oXdHomCFbwbRjzW8uut+FEsnBQ2duoYVeTjRvxNJ3cpcP4jzCYcELudJgIzmR3OT
9Dcf2KFuK/+rf1/Cm2xeYWQAuNkEclzKa0Ussln+/FOucYbz3YUFP4UHE/gftZu/
5rmCH7ydtTDDzB9GwPpCguSk7Nr6hbxRdZEhBrTtrOJXLDgyCxD71YCDGtB4uB6n
5XPn1n4uau4vetiYMolEuquDXoUwogqt5ZQhgI9/Uu4jINc953Nt2KpBFfw2z06R
CC67Uw/0Bw1hgsFqsh5pu3+7UoGo+36X/thdsNhKB1JhJ/OpdAQSdJtfKtuGdDSn
lQ9WMAcRfFrKNiPJ7sBUk/UQEdK97fgAjXNlYA==
=eZSI
-END PGP SIGNATURE-

Bug#898853: gnuplot.lisp

[Gunter Königsmann]

Will reassign the bug to Maxima - and will see if I find a solution.

Kind regards,

   Gunter.

Am 17. Mai 2018 12:51:09 MESZ schrieb besoa...@gmail.com:
>Dear Gunther,
>
>The gnuplot.lisp file that I have (maxima 5.38.1-8) does not contain
>the lines 
>above but instead at lines 3393-3396:
>
>(when (and (not *multiplot-is-active*)
>  (not (member (get-option '$terminal) '($epslatex 
>$epslatex_standalone
>(format cmdstorage "set obj 1 rectangle behind from screen 
>~a,~a to screen ~a,~a~%" 
> origin1 origin2 (+ origin1 size1 ) (+ 
>origin2 size2)))  ))
>
>As far as I understand it, $epslatex and $epslatex_standalone have been
>
>singled out for gnuplot processing (for some reason). Either
>- the two lines should be activated
> "set obj 1 rectangle etc."
> "set obj 1 fc rgb etc."
>- or the two of them are removed from ~/maxout.gnuplot (in that
>case, no 
>background ), whereas on debian stretch only the second line is
>present.
>Both cases can generate .tex file.  (I only have gnuplot 5 too). The
>bug comes 
>from the first line missing.
>
>Best regards,
>
># locate gnuplot.lisp
>/usr/share/maxima/5.38.1/share/draw/gnuplot.lisp
>#apt-cache show maxima-share gnuplot
>Package: maxima-share
>Source: maxima
>Version: 5.38.1-8
>Package: gnuplot
>Version: 5.0.5+dfsg1-6+deb9u1

-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

Bug#898935: tomcat8: CVE-2018-8014: The defaults settings for the CORS filter provided in Apache Tomcat are insecure and enable 'supportsCredentials'

[Salvatore Bonaccorso]

Source: tomcat8
Version: 8.5.30-1
Severity: important
Tags: patch security upstream
Forwarded: https://bz.apache.org/bugzilla/show_bug.cgi?id=62343

Hi,

The following vulnerability was published for tomcat8.

CVE-2018-8014[0]:
| The defaults settings for the CORS filter provided in Apache Tomcat
| 9.0.0.M1 to 9.0.8, 8.5.0 to 8.5.31, 8.0.0.RC1 to 8.0.52, 7.0.41 to
| 7.0.88 are insecure and enable 'supportsCredentials' for all origins.
| It is expected that users of the CORS filter will have configured it
| appropriately for their environment rather than using it in the
| default configuration. Therefore, it is expected that most users will
| not be impacted by this issue.

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2018-8014
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-8014
[1] https://bz.apache.org/bugzilla/show_bug.cgi?id=62343

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#898928: halibut: crashes when generating chm or html (with a non-resolving cross-reference)

[Simon Tatham]

C. Masloch  wrote:
> A simple test file, in two variants, causes a segmentation fault either
> when outputting --chm (in both variants), or when outputting --html
> (only in the variant with a non-resolving cross-reference included).

This is already fixed upstream; I think you're seeing a combination of
the bugs fixed by commits e12d87eea (CHM output crashes if the document
contains no \title) and 4b457fd6f (the shared code between CHM and HTML
segfaults as a knock-on effect of a bogus cross-reference that previous
code had already reported as an error).

Cheers,
Simon

-- 
import hashlib; print((lambda p,q,g,y,r,s,m: (lambda w:(pow(g,int(hashlib.sha1(
m.encode('ascii')).hexdigest(),16)*w%q,p)*pow(y,r*w%q,p)%p)%q)(pow(s,q-2,q))==r
and m)(0xb80b5dacabab6145,0xf70027d345023,0x7643bc4018957897,0x11c2e5d9951130c9
,0xa54d9cbe4e8ab,0x746c50eaa1910,  "Simon Tatham " ))

Bug#898934: transition: libmygpo-qt

[contact]

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

Hello,

I uploaded a new version of libmygpo-qt (1.1.0-1) to experimental 
rebuilt against Qt5 which introduces

ABI changes. I need a transition slot.

The transition is already auto-tracked here:
* https://release.debian.org/transitions/html/auto-libmygpo-qt.html

The following packages will be affected by the transition:

* clementine : 1.3.1+git426-gb8381321c+dfsg-1 version ready in 
experimental.

* amarok : #896941

Thanks in advance,

Thomas Pierson

Bug#898923: halibut: doesn't properly handle file starting with an empty line

[Simon Tatham]

C. Masloch  wrote:
> A simple test file fails to properly parse a \cfg command as the first
> non-empty line of a file, if the first line is empty.

Wow, that bug must have been there a _very_ long time without anyone
noticing it. Well spotted! I've pushed commit 140d8f13a upstream which
fixes it.

Cheers,
Simon

-- 
import hashlib; print((lambda p,q,g,y,r,s,m: (lambda w:(pow(g,int(hashlib.sha1(
m.encode('ascii')).hexdigest(),16)*w%q,p)*pow(y,r*w%q,p)%p)%q)(pow(s,q-2,q))==r
and m)(0xb80b5dacabab6145,0xf70027d345023,0x7643bc4018957897,0x11c2e5d9951130c9
,0xa54d9cbe4e8ab,0x746c50eaa1910,  "Simon Tatham " ))

Bug#898850: ui-utilcpp: FTBFS: syntax error in configure script

[Stephan Sürken]

Hi Sven,

On Wed, 2018-05-16 at 17:26 +0200, Sven Joachim wrote:
> Source: ui-utilcpp
> Version: 1.8.5-2
> Severity: serious
> 
> Your package FTBFS everywhere[1], the reason being that the configure

Ups yes, thanks for the hint ;).

I did not thoroughly check on this after the hasty post-salsa upload...

Thx!

S

Bug#898921: chown: please consider dropping the dot separator fallback

[Michael Stone]

On Thu, May 17, 2018 at 04:15:44PM +0200, you wrote:

Michael Stone  writes:

It would not--POSIX does not disallow the . syntax.


(This is not my point, but in my reading
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/chown.html
does not allow it: "The BSD syntax user[. group] was changed to user[:
group] in this volume of POSIX.1-2017...")


The new syntax was introduced. It does not say anything like "MUST NOT 
accept . syntax".



Rather, I meant that adduser could be configured *by default* to not
require --force-badname for adding perfectly valid POSIX user names.


It can be, someone's simply decided not to. I think that's dumb, but 
¯\_(ツ)_/¯



Yes.  However, chown one.two.three can still behave unexpectedly if
the "three" group and the "one.two" and "one.two.three" users all exist.
(I understand that the behavior is well defined anyway.)


There are all kinds of things that can be unexpected on a linux system 
if you try hard enough. We don't stop you from creating filenames with 
shell special characters, either. 


Mike Stone

Bug#898933: vim empties file on full filesystem

[Alexander Pyhalov]

Package: vim-tiny
Version: 2:7.3.547-7

When file system is full, when we open file and save it (:w), vim gives 
an error that it cannot create file, but empties original file. (Think 
about 'editing' /etc/shadow in such way).

--
Best regards,
Alexander Pyhalov,
system administrator of Southern Federal University IT department

Bug#898932: ITP: libb-debug-perl -- module to print debug info about perl ops

[gregor herrmann]

Package: wnpp
Owner: gregor herrmann 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, debian-p...@lists.debian.org

* Package name: libb-debug-perl
  Version : 1.26
  Upstream Author : Reini Urban 
* URL : https://metacpan.org/release/B-Debug
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : module to print debug info about perl ops

The B::Debug module walks the Perl syntax tree, printing debug info about
ops.

The B module supplies classes which allow a Perl program to delve
into its own innards.  It is the module used to implement the
"backends" of the Perl compiler.

B::Debug in perl core is deprecated in 5.27.3 and will be removed in the
future.

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

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.


signature.asc
Description: Digital Signature

Bug#898931: ITP: looking-glass -- An extremely low latency KVM FrameRelay implementation for guests with VGA PCI Passthrough

[Lennart Weller]

Package: wnpp
Severity: wishlist
Owner: Lennart Weller 

* Package name: looking-glass
  Version : 0+a10
  Upstream Author : Geoffrey McRae 
* URL : https://github.com/gnif/LookingGlass/
* License : GPL2+ with OpenSSL Exception
  Programming Lang: C
  Description : An extremely low latency KVM FrameRelay implementation for 
guests with VGA PCI Passthrough

LookingGlass enables you to use shared memory to pass rendered frames from a
virtual machine back to the host system. This is exceptionally useful
for IOMMU/VFIO graphics card passthrough setups.

Bug#898921: chown: please consider dropping the dot separator fallback

[Ferenc Wágner]

Michael Stone  writes:

> On Thu, May 17, 2018 at 02:56:00PM +0200, Ferenc Wágner wrote:
>
>> When asked to enable user names containing dots, I encountered
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=604242#20.
>> When do you think chown could stop accepting the dot separator?
>
> No
>
>> While it could break old scripts 
>
> that's why
>
>> it would also enhance Debian's POSIX conformance.
>
> It would not--POSIX does not disallow the . syntax.

(This is not my point, but in my reading
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/chown.html
does not allow it: "The BSD syntax user[. group] was changed to user[:
group] in this volume of POSIX.1-2017...")

Rather, I meant that adduser could be configured *by default* to not
require --force-badname for adding perfectly valid POSIX user names.
I shouldn't have used the word "conformance" for this.

> Note that the discussion in 604242 is wrong: coreutils will only fall
> back to the . syntax *if there is a . which is not in a valid
> username*. Usernames with .'s will work perfectly well as-is.

Yes.  However, chown one.two.three can still behave unexpectedly if
the "three" group and the "one.two" and "one.two.three" users all exist.
(I understand that the behavior is well defined anyway.)
-- 
Regards,
Feri

Bug#898926: thunderbird: Keeps setting itself as default browser

[Carsten Schoenert]

Hello Matijs,

Am 17.05.2018 um 15:42 schrieb Matijs van Zuijlen:
> Thunderbird keeps setting itself as default browser, causing local html files
> to be opened as attachment to a new email message, and links to be
> opened no-where.
> 
> I'm using Gnome as my desktop environment, and want to have Firefox be
> its default browser.
> 
> Thunderbird is not a browser so shouldn't even try to make itself the
> default.

Thunderbird itself is using the settings
'network.protocol-handler.app.http(s)' for referencing the to be used
browser if one of http protocols is called.

The default is set to 'x-www-browser' (see
/etc/thunderbird/pref/thunderbird.js) which is linked to another link
handled by update-alternates.

> $ which x-www-browser 
> /usr/bin/x-www-browser
> $ ls -la /usr/bin/x-www-browser
> lrwxrwxrwx 1 root root 31 Jun 19  2017 /usr/bin/x-www-browser -> 
> /etc/alternatives/x-www-browser
> $ ls -la /etc/alternatives/x-www-browser
> lrwxrwxrwx 1 root root 16 Mär 30 18:47 /etc/alternatives/x-www-browser -> 
> /usr/bin/firefox

These settings shown above are the default case for a long time, so if
Thunderbird tries to open Thunderbird for html links you have some non
default settings.

The settings for network.protocol-handler.app.http(s) can be modified
within your preferences so first have a look into your profile and check
if there is something changed.

Another possibility to look at is the file
$HOME/.thunderbird/[your_profile]/mimeTypes.rdf

Here also some different browser can be declared. Look for something
like this especially on 'NC:path':

>  10 11NC:prettyName="iceweasel"
>  12NC:path="/usr/bin/x-www-browser" />

You can safely remove such a entry.

-- 
Regards
Carsten Schoenert

Bug#898930: gnupg: uses 100% CPU until killed

[Johannes Rohr]

Package: gnupg
Version: 2.2.5-1
Severity: important

Lately, when I leave my computer running, when I return I occasionally find 
that CPU usage is at 100%, CPU temperature is close to 100 centigrades, and 
that's because a gpg process seems to run wild.

This is what I get when I run strace on the process:

fcntl(7, F_SETLK, {l_type=F_RDLCK, l_whence=SEEK_SET, l_start=1073741824, 
l_len=1}) = -1 EACCES (Permission denied)
fcntl(7, F_SETLK, {l_type=F_RDLCK, l_whence=SEEK_SET, l_start=1073741824, 
l_len=1}) = -1 EACCES (Permission denied)
fcntl(7, F_SETLK, {l_type=F_RDLCK, l_whence=SEEK_SET, l_start=1073741824, 
l_len=1}) = -1 EACCES (Permission denied)
fcntl(7, F_SETLK, {l_type=F_RDLCK, l_whence=SEEK_SET, l_start=1073741824, 
l_len=1}) = -1 EACCES (Permission denied)
fcntl(7, F_SETLK, {l_type=F_RDLCK, l_whence=SEEK_SET, l_start=1073741824, 
l_len=1}) = -1 EACCES (Permission denied)
fcntl(7, F_SETLK, {l_type=F_RDLCK, l_whence=SEEK_SET, l_start=1073741824, 
l_len=1}) = -1 EACCES (Permission denied)


Or with strace -y

fcntl(7, F_SETLK, {l_type=F_RDLCK, l_whence=SEEK_SET, 
l_start=1073741824, l_len=1}) = -1 EACCES (Permission denied)
fcntl(7, F_SETLK, {l_type=F_RDLCK, l_whence=SEEK_SET, 
l_start=1073741824, l_len=1}) = -1 EACCES (Permission denied)
fcntl(7, F_SETLK, {l_type=F_RDLCK, l_whence=SEEK_SET, 
l_start=1073741824, l_len=1}) = -1 EACCES (Permission denied)
fcntl(7, F_SETLK, {l_type=F_RDLCK, l_whence=SEEK_SET, 
l_start=1073741824, l_len=1}) = -1 EACCES (Permission denied)
fcntl(7, F_SETLK, {l_type=F_RDLCK, l_whence=SEEK_SET, 
l_start=1073741824, l_len=1}) = -1 EACCES (Permission denied)
fcntl(7, F_SETLK, {l_type=F_RDLCK, l_whence=SEEK_SET, 
l_start=1073741824, l_len=1}) = -1 EACCES (Permission denied)
fcntl(7, F_SETLK, {l_type=F_RDLCK, l_whence=SEEK_SET, 
l_start=1073741824, l_len=1}) = -1 EACCES (Permission denied)
fcntl(7, F_SETLK, {l_type=F_RDLCK, l_whence=SEEK_SET, 
l_start=1073741824, l_len=1}^Cstrace: Process 28176 detached

I have no idea why permission is denied. I can't find that tofu.db is opened by 
any other process, with lsof, also I can't find anything with lslocks.


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

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

Versions of packages gnupg depends on:
ii  dirmngr 2.2.5-1
ii  gnupg-l10n  2.2.5-1
ii  gnupg-utils 2.2.5-1
ii  gpg 2.2.5-1
ii  gpg-agent   2.2.5-1
ii  gpg-wks-client  2.2.5-1
ii  gpg-wks-server  2.2.5-1
ii  gpgsm   2.2.5-1
ii  gpgv2.2.5-1

gnupg recommends no packages.

Versions of packages gnupg suggests:
pn  parcimonie  
pn  xloadimage  

-- no debconf information