Bug#880710: pepperflashplugin-nonfree: Please use `install` instead of `cp` in update scripts

2017-11-03 Thread Zhang Jingqiang
Package: pepperflashplugin-nonfree
Version: 1.8.3+nmu1
Severity: normal

Dear Maintainer,

sed -i 's/cp/install -m 644/' /usr/sbin/update-pepperflashplugin-nonfree

So it will not crash running chromium.

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

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

Versions of packages pepperflashplugin-nonfree depends on:
ii  binutils   2.29.1-6
ii  ca-certificates20170717
ii  debconf [debconf-2.0]  1.5.64
ii  gnupg  2.2.1-5
ii  libatk1.0-02.26.1-1
ii  libcairo2  1.15.8-2
ii  libcurl3-gnutls7.56.1-1
ii  libfontconfig1 2.12.3-0.2
ii  libfreetype6   2.8.1-0.1
ii  libgcc11:7.2.0-12
ii  libglib2.0-0   2.54.2-1
ii  libgtk2.0-02.24.31-2
ii  libnspr4   2:4.16-1
ii  libnss32:3.33-1
ii  libpango-1.0-0 1.40.13-1
ii  libstdc++6 7.2.0-12
ii  libx11-6   2:1.6.4-3
ii  libxext6   2:1.3.3-1+b2
ii  libxt6 1:1.1.5-1
ii  wget   1.19.2-1

pepperflashplugin-nonfree recommends no packages.

Versions of packages pepperflashplugin-nonfree suggests:
ii  chromium   61.0.3163.100-2
pn  hal
pn  ttf-dejavu 
ii  ttf-mscorefonts-installer  3.6
pn  ttf-xfree86-nonfree

-- no debconf information



Bug#880709: zfsutils-linux 0.7.3 has an unlisted dependency on libuutil1linux >= 0.7.3

2017-11-03 Thread Rich Ercolani
Package: zfsutils-linux
Version: 0.7.3-1
Severity: important

Dear Maintainer,

As the subject says, if you just install 
{zfsutils-linux,spl-dkms,zfs-dkms}/unstable, you can end up with libuutil1linux 
from stable or testing, and get back:
zpool: symbol lookup error: /lib/libzpool.so.2: undefined symbol: spl_pagesize
Explicitly installing libuutil1linux >= 0.7.3 resolves this, so the package 
should probably have an explicit version dependency listed.

(As you can see, I commonly configure stable > testing > unstable pinning 
preferences, so booting a new stretch machine and installing the above with 
those pinnings will result in this.)

- Rich

-- System Information:
Debian Release: 9.2
  APT prefers stable
  APT policy: (1000, 'stable'), (900, 'testing'), (800, 'unstable'), (500, 
'stable-updates')
Architecture: amd64 (x86_64)

Kernel: Linux 4.9.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)

Versions of packages zfsutils-linux depends on:
ii  libblkid12.29.2-1
ii  libc62.24-11+deb9u1
ii  libnvpair1linux  0.7.3-1
ii  libuuid1 2.29.2-1
ii  libuutil1linux   0.6.5.9-5
ii  libzfs2linux 0.7.3-1
ii  libzpool2linux   0.7.3-1
ii  python3  3.5.3-1
ii  zlib1g   1:1.2.8.dfsg-5

Versions of packages zfsutils-linux recommends:
ii  lsb-base9.20161125
ii  zfs-dkms [zfs-modules]  0.7.3-1
ii  zfs-zed 0.7.3-1

Versions of packages zfsutils-linux suggests:
pn  nfs-kernel-server   
pn  samba-common-bin
pn  zfs-initramfs | zfs-dracut  

-- no debconf information



Bug#824827: mixmaster: hold on..

2017-11-03 Thread Anonymous
Package: mixmaster
Version: 3.0.0-8.1
Followup-For: Bug #824827

Dear Maintainer,

> Mixmaster does not support 4k keys.
> 
> It is not designed to support 4k keys.
> 
> Closing the bug.

Hold on.. even if the project has decided that 1k keys is the way
forward, 2 bugs still remain:

bug 1: mixmaster autonomously chooses to use a (so-called) unsupported
   chain.  If 4k keys are not supported, the tool shouldn't
   attempt to chain through unusable nodes in the first place.

bug 2: the error message "encryption failed" is absurdly vague.  In
the absence of a fix for bug 1, the tool should say something
meaningful like:

  "cannot route through dizum because its keys are too large"

Please reopen.

Note this is my *6th* attempt to send this reply -- I am sending it
using mixmaster.

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

Kernel: Linux 4.9.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=1508766057 WARNING 
torsocks[12002]: [syscall] Unsupported syscall number 217. Denying the call (in 
tsocks_syscall() at syscall.c:488)
UTF-8), LANGUAGE=en_US.UTF-8 (charmap=1508766057 WARNING torsocks[12004]: 
[syscall] Unsupported syscall number 217. Denying the call (in tsocks_syscall() 
at syscall.c:488)
UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages mixmaster depends on:
ii  adduser3.115
ii  debconf [debconf-2.0]  1.5.61
ii  libc6  2.24-11+deb9u1
ii  libmailtools-perl  2.18-1
ii  libncurses56.0+20161126-1+deb9u1
ii  libpcre3   2:8.39-3
ii  libssl1.0.21.0.2l-2
ii  libtinfo5  6.0+20161126-1+deb9u1
ii  libwww-perl6.15-1
ii  zlib1g 1:1.2.8.dfsg-5

Versions of packages mixmaster recommends:
ii  postfix [mail-transport-agent]  3.1.6-0+deb9u1

Versions of packages mixmaster suggests:
ii  mutt  1.7.2-1

-- Configuration Files:
/etc/mixmaster/allpingers.txt changed:
[austria]
base= https://www.tahina.priv.at/~cm/stats/
rlist   = https://www.tahina.priv.at/~cm/stats/rlist.txt
mlist   = https://www.tahina.priv.at/~cm/stats/mlist.txt
rlist2  = https://www.tahina.priv.at/~cm/stats/rlist2.txt
mlist2  = https://www.tahina.priv.at/~cm/stats/mlist2.txt
rlist_html  = https://www.tahina.priv.at/~cm/stats/rlist.html
mlist_html  = https://www.tahina.priv.at/~cm/stats/mlist.html
rlist2_html = https://www.tahina.priv.at/~cm/stats/rlist2.html
mlist2_html = https://www.tahina.priv.at/~cm/stats/mlist2.html
pgpring = https://www.tahina.priv.at/~cm/stats/pgp-all.asc
pgpring_rsa = https://www.tahina.priv.at/~cm/stats/pgp-rsa.asc
mixring = https://www.tahina.priv.at/~cm/stats/pubring.mix
type2list   = https://www.tahina.priv.at/~cm/stats/type2.list
[deuxpi]
base= http://www.deuxpi.ca/echolot/
rlist   = http://www.deuxpi.ca/echolot/rlist.txt
mlist   = http://www.deuxpi.ca/echolot/mlist.txt
rlist2  = http://www.deuxpi.ca/echolot/rlist2.txt
mlist2  = http://www.deuxpi.ca/echolot/mlist2.txt
rlist_html  = http://www.deuxpi.ca/echolot/rlist.html
mlist_html  = http://www.deuxpi.ca/echolot/mlist.html
rlist2_html = http://www.deuxpi.ca/echolot/rlist2.html
mlist2_html = http://www.deuxpi.ca/echolot/mlist2.html
pgpring = http://www.deuxpi.ca/echolot/pgp-all.asc
pgpring_rsa = http://www.deuxpi.ca/echolot/pgp-rsa.asc
mixring = http://www.deuxpi.ca/echolot/pubring.mix
type2list   = http://www.deuxpi.ca/echolot/type2.list
[frell]
base= http://echolot.theremailer.net/
rlist   = http://echolot.theremailer.net/rlist.txt
mlist   = http://echolot.theremailer.net/mlist.txt
rlist2  = http://echolot.theremailer.net/rlist2.txt
mlist2  = http://echolot.theremailer.net/mlist2.txt
rlist_html  = http://echolot.theremailer.net/rlist.html
mlist_html  = http://echolot.theremailer.net/mlist.html
rlist2_html = http://echolot.theremailer.net/rlist2.html
mlist2_html = http://echolot.theremailer.net/mlist2.html
pgpring = http://echolot.theremailer.net/pgp-all.asc
pgpring_rsa = http://echolot.theremailer.net/pgp-rsa.asc
mixring = http://echolot.theremailer.net/pubring.mix
type2list   = http://echolot.theremailer.net/type2.list
[hermetix]
base= http://www.hermetix.org/echolot/
rlist   = http://www.hermetix.org/echolot/rlist.txt
mlist   = http://www.hermetix.org/echolot/mlist.txt
rlist2  = http://www.hermetix.org/echolot/rlist2.txt
mlist2  = http://www.hermetix.org/echolot/mlist2.txt
rlist_html  = http://www.hermetix.org/echolot/rlist.html
mlist_html  = http://www.hermetix.org/echolot/mlist.html
rlist2_html = http://www.hermetix.org/echolot/rlist2.html
mlist2_html = http://www.hermetix.org/echolot/mlist2.html
pgpring = http://www.hermetix.org/echolot/pgp-all.asc
pgpring_rsa = http://www.hermetix.org/echolot/pgp-rsa.asc
mixring = 

Bug#880708: [qbittorrent] debian built wrong according to upstream.

2017-11-03 Thread macarthur

Package: qbittorrent
Version: 3.3.7-3
Severity: important

--- Please enter the report below this line. ---
according to
https://github.com/qbittorrent/qBittorrent/issues/7671#issuecomment-341681209

qbittorrent isn't fully comaptible w/ libtorrent 1.1 so debian's build 
for stable is built wrong and way more prone to crashes.
here's the qbittorrent printout already repoted uptstream said it's a 
debian specific issue due to improper building.


--console output---

Catching signal: SIGSEGV
Please file a bug report at http://bug.qbittorrent.org and provide the 
following information:


qBittorrent version: v3.3.7
stack trace:
/usr/lib/x86_64-linux-gnu/libtorrent-rasterbar.so.9 : ()+0x16026b 
[0x7f876353926b]
/usr/lib/x86_64-linux-gnu/libtorrent-rasterbar.so.9 : ()+0x16221a 
[0x7f876353b21a]
/usr/lib/x86_64-linux-gnu/libtorrent-rasterbar.so.9 : ()+0xa20a3 
[0x7f876347b0a3]
/usr/lib/x86_64-linux-gnu/libtorrent-rasterbar.so.9 : ()+0xa565a 
[0x7f876347e65a]
/usr/lib/x86_64-linux-gnu/libtorrent-rasterbar.so.9 : ()+0xa9b1c 
[0x7f8763482b1c]
/usr/lib/x86_64-linux-gnu/libtorrent-rasterbar.so.9 : ()+0xabd4d 
[0x7f8763484d4d]
/usr/lib/x86_64-linux-gnu/libtorrent-rasterbar.so.9 : ()+0x16a10c 
[0x7f876354310c]
/usr/lib/x86_64-linux-gnu/libtorrent-rasterbar.so.9 : ()+0x16a567 
[0x7f8763543567]
/usr/lib/x86_64-linux-gnu/libtorrent-rasterbar.so.9 : ()+0x305844 
[0x7f87636de844]
/usr/lib/x86_64-linux-gnu/libtorrent-rasterbar.so.9 : ()+0x1c5d38 
[0x7f876359ed38]
/usr/lib/x86_64-linux-gnu/libtorrent-rasterbar.so.9 : ()+0xc6b5f 
[0x7f876349fb5f]

/lib/x86_64-linux-gnu/libpthread.so.0 : ()+0x7494 [0x7f8761de4494]
/lib/x86_64-linux-gnu/libc.so.6 : clone()+0x3f [0x7f8761289aff]
Segmentation fault

--console debug info--

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

Debian Release: 9.1
500 stable-updates ftp.us.debian.org
500 stable security.debian.org
500 stable ftp.us.debian.org
500 stable download.videolan.org
100 stretch-backports repozytorium.mati75.eu
100 stretch-backports ftp.debian.org

--- Package information. ---
Depends (Version) | Installed
==-+-=
libboost-system1.62.0 | 1.62.0+dfsg-4
libc6 (>= 2.14) |
libgcc1 (>= 1:3.0) |
libqt5core5a (>= 5.7.0) |
libqt5dbus5 (>= 5.2.0) |
libqt5gui5 (>= 5.7.0) |
libqt5network5 (>= 5.2.0) |
libqt5widgets5 (>= 5.7.0) |
libqt5xml5 (>= 5.2.0) |
libstdc++6 (>= 5.2) |
libtorrent-rasterbar9 (>= 1.1.1) |
zlib1g (>= 1:1.1.4) |
python (>= 2.5) |
geoip-database |


Package's Recommends field is empty.

Suggests (Version) | Installed
==-+-===
qbittorrent-dbg |



Bug#880706: Warnings about statements that might fall through

2017-11-03 Thread Bjarni Ingi Gislason
Package: bison++
Version: 1.21.11-4+b1
Severity: minor

Dear Maintainer,

   * What led up to the situation?

Compilation of "groff"

   * What was the outcome of this action?

Some warnings from the compiler.

  This should be fixed, or if correct, an explanation should be added to the
corresponding code.

###

  When "groff" (from git repository) was compiled, the compiler (gcc-7) issued 
the
following diagnostics:

/usr/share/bison++/bison.cc: In function 'int yyparse()':
/usr/share/bison++/bison.cc:616:9: warning: this statement may fall through 
[-Wimplicit-fallthrough=]
   yyvsp = yyvs;
   ~~^~
/usr/share/bison++/bison.cc:377:23: note: here
 #define YYLABEL(lb) } case lb: {
   ^
/usr/share/bison++/bison.cc:624:1: note: in expansion of macro 'YYLABEL'
 YYLABEL(yynewstate)
 ^~~
/usr/share/bison++/bison.cc:815:3: warning: this statement may fall through 
[-Wimplicit-fallthrough=]
   if (yyn == 0)
   ^~
/usr/share/bison++/bison.cc:377:23: note: here
 #define YYLABEL(lb) } case lb: {
   ^
/usr/share/bison++/bison.cc:819:1: note: in expansion of macro 'YYLABEL'
 YYLABEL(yyreduce)
 ^~~
/usr/share/bison++/bison.cc:981:11: warning: this statement may fall through 
[-Wimplicit-fallthrough=]
   yystate = *--yyssp;
   ^~
/usr/share/bison++/bison.cc:377:23: note: here
 #define YYLABEL(lb) } case lb: {
   ^
/usr/share/bison++/bison.cc:997:1: note: in expansion of macro 'YYLABEL'
 YYLABEL(yyerrhandle)

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

Kernel: Linux 4.9.51-2u3 (SMP w/2 CPU cores)
Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 (charmap=ISO-8859-1), 
LANGUAGE=is_IS.iso88591 (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages bison++ depends on:
ii  libc6   2.24-17
ii  libgcc1 1:7.2.0-12
ii  libstdc++6  7.2.0-12

Versions of packages bison++ recommends:
pn  flex-old  
ii  gcc [c-compiler]  4:7.2.0-1d1
ii  gcc-4.8 [c-compiler]  4.8.5-4
ii  gcc-4.9 [c-compiler]  4.9.3-14
ii  gcc-5 [c-compiler]5.4.1-4
ii  gcc-6 [c-compiler]6.4.0-9
ii  gcc-7 [c-compiler]7.2.0-12

bison++ suggests no packages.

-- no debconf information

-- 
Bjarni I. Gislason



Bug#880707: libjs-extjs: please add dependency “Suggests: libjs-extjs-doc”

2017-11-03 Thread Ben Finney
Source: libjs-extjs
Version: 3.4.0+dfsg1-1
Severity: minor

Dear Maintainer,

Working with the ‘libjs-extjs’ packages requires understanding how it
works and what it does.

Please set a “Suggests: libjs-extjs-doc” dependency to the binary
package ‘libjs-extjs’, and other binary packages for which it is
appropriate.

This will present the suggestion to administrators choosing which
packages to install.

-- 
 \   “Selfish, adj. Devoid of consideration for the selfishness of |
  `\  others.” —Ambrose Bierce, _The Devil's Dictionary_, 1906 |
_o__)  |
Ben Finney 


signature.asc
Description: PGP signature


Bug#880705: libjs-extjs-doc: Section should be “doc”

2017-11-03 Thread Ben Finney
Package: libjs-extjs-doc
Version: 3.4.0+dfsg1-1
Severity: minor

Dear Maintainer,

The section “javascript” is for packages that install implementations
of JavaScript or libraries.

The package ‘libjs-extjs-doc’ installs primarily documentation, not
executable programs or libraries. It should not be in the “javascript”
section.

Please set the field “Section: doc” on this package.


Then, since the package is already in Debian with a different
section, you need to submit a request to override the existing section
.

Mark that new bug report as blocked by this one, to indicate the
reliance between them.

-- 
 \“If we ruin the Earth, there is no place else to go. This is |
  `\not a disposable world, and we are not yet able to re-engineer |
_o__)  other planets.” —Carl Sagan, _Cosmos_, 1980 |
Ben Finney 


signature.asc
Description: PGP signature


Bug#850741: python-docker 2.x in Sid

2017-11-03 Thread Felipe Sateler
On Fri, Nov 3, 2017 at 2:28 PM, Thomas Goirand  wrote:
>
> On 11/03/2017 01:04 AM, Felipe Sateler wrote:
> >
> >
> > On Thu, Nov 2, 2017 at 8:25 PM, Thomas Goirand  > > wrote:
> >
> > On 11/02/2017 08:02 PM, Felipe Sateler wrote:
> > > On Wed, Nov 1, 2017 at 11:44 PM, Jason Pleau  > > wrote:
> > >> Hi Thomas
> > >>
> > >> On 11/01/2017 08:51 PM, Thomas Goirand wrote:
> > >>> Hi,
> > >>>
> > >>> Could you please upload the 2.x version of python-docker into Sid? 
> > I've
> > >>> uploaded python-zunclient that needs it.
> > >>>
> > >>
> > >> It's been a while, I think what we (still) have to do is get the
> > >> rdepends updated to work with the latest python-docker. I don't think
> > >> anyone looked at that yet.
> > >
> > > Yes, this work was pending. I never filed the bugs (sorry!), but my
> > > earlier investigations showed that all rdeps had been fixed upstream,
> > > but not released yet.
> > >
> > > I see now that you have already fixed all of them! (magnum 5.0 and
> > > senlin 4 both work with python-docker 2.x, and you mention zunclient).
> > >
> > >>
> > >> We welcome help of course, I will take some time this weekend to see
> > >> what exactly needs to be done and start doing some work.
> > >
> > > I think all that needs to be done is to:
> > >
> > > 1. Declare Breaks: python-magnum (<< 5.0), python-senlin (<< 4.0),
> > > docker-compose (<< 1.10).
> > > 2. Same for python3 versions
> > > 3. Prepare docker-compose >= 1.10
> > > 4. Upload python-docker to unstable
> > > 5. Upload docker-compose to unstable
> > >
> > > I don't have much time this week though to work on this.
> > >
> > > @zigo: if you want to move faster with 1, 2, and 4, please go ahead
> > > (repo is at collab-maint), but make sure to file a (serious) bug to
> > > docker-compose so that we don't forget to do 3 and 5.
> > >
> > >> (sorry for the delays on this (I honestly just forgot to follow up..)
> > >
> > > I had forgotten about this too. Oops!
> >
> > I don't think there's the need to declare such a break, since I uploaded
> > senlin 4 and magnum 5 to Sid.
> >
> >
> > It is still necessary because old senlin (and magnum) can't work with
> > new python-docker. So partial upgrades from stretch could break if they
> > are not added.
>
> This issues may happen in Sid and/or testing, that you're right. I've
> added the Breaks: as you suggested.

Thanks.

>
> > I'm not sure how docker-compose is involved here...
> >
> >
> > Because it also depends on python-docker, and also needs a new version
> > to handle python-docker 2.x...
>
> Should it be an updated to the latest 1.17.0 version?

Anything post 1.10 should do for these purposes, but of course the
newer the better.

> Can I do it? I'm a
> bit scared to break anything by upgrading to the wrong version here.
> Otherwise I don't mind doing the work.

I would be very grateful if you did it (the repo is in collab-maint).
Sometimes other dependencies need to be updated too, though. I have
not investiaged the amount of work necessary yet.

I usually just try starting, stopping, rm'ing a couple of
docker-compose projects before uploading. Compose also has a pretty
extensive test suite, but it can't be run during build because it
requires network (and root-equivalent access to docker).

-- 

Saludos,
Felipe Sateler



Bug#877585: uim-common is gone, should detect with uim package

2017-11-03 Thread YOSHINO Yoshihito
Control: severity -1 important

Hi,

Most im-config & uim users should be affected by this bug.

On Tue, 3 Oct 2017 20:46:35 +0900 d...@debian.org wrote:
> fixed in git.debian.org at devel branch.

Still not fixed in sid yet ...

Thanks,

-- 
YOSHINO Yoshihito 



Bug#880703: test-suite failure on s390x

2017-11-03 Thread Michael Biebl
Source: json-glib
Version: 1.4.2-1
Severity: serious
Forwarded: https://gitlab.gnome.org/GNOME/json-glib/issues/28

The test-suite fails on s390x:

 1/14 array   OK   0.01 s
 2/14 boxed   OK   0.01 s
 3/14 builder OK   0.01 s
 4/14 generator   OK   0.01 s
 5/14 gvariantOK   0.01 s
 6/14 invalid OK   0.00 s
 7/14 nodeFAIL 0.01 s
 8/14 object  OK   0.00 s
 9/14 parser  OK   0.01 s
10/14 pathOK   0.01 s
11/14 reader  OK   0.00 s
12/14 serialize-simpleOK   0.00 s
13/14 serialize-complex   OK   0.00 s
14/14 serialize-full  OK   0.00 s

OK:13
FAIL:   1
SKIP:   0
TIMEOUT:0


The output from the failed tests:

 7/14 nodeFAIL 0.01 s

--- command ---
G_TEST_SRCDIR='/<>/json-glib/tests' 
G_TEST_BUILDDIR='/<>/obj-s390x-linux-gnu/json-glib/tests' 
/<>/obj-s390x-linux-gnu/json-glib/tests/node --tap -k
--- stdout ---
# random seed: R02Scd9cf85c8a3182658ed0f0a8ffed8b47
1..27
# Start of nodes tests
ok 1 /nodes/gvalue
# Start of init tests
ok 2 /nodes/init/int
ok 3 /nodes/init/double
ok 4 /nodes/init/boolean
ok 5 /nodes/init/string
ok 6 /nodes/init/null
# End of init tests
# Start of copy tests
ok 7 /nodes/copy/null
ok 8 /nodes/copy/value
ok 9 /nodes/copy/object
# End of copy tests
# Start of get tests
ok 10 /nodes/get/int
ok 11 /nodes/get/double
# End of get tests
# Start of gvalue tests
# Json:ERROR:../json-glib/tests/node.c:235:test_gvalue_autopromotion: assertion 
failed ((float) g_value_get_double () == 3.14159f): (3.14159012 == 
3.14159)
--- stderr ---
**
Json:ERROR:../json-glib/tests/node.c:235:test_gvalue_autopromotion: assertion 
failed ((float) g_value_get_double () == 3.14159f): (3.14159012 == 
3.14159)
---

The full build log is available at 
https://buildd.debian.org/status/fetch.php?pkg=json-glib=s390x=1.4.2-1=1509747369=0


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

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



Bug#880704: bumblebee-nvidia: Upgrading mesa and nvidia drivers with bumblebee-nvidia installed breaks the desktop

2017-11-03 Thread JWM
Package: bumblebee-nvidia
Version: 3.2.1-16
Severity: grave
Justification: renders package unusable

Dear Maintainer,

My system is a Thinkpad T440p, with both an Intel and an NVIDIA Optimus cards.
On Wednesday, upgrading both the Mesa libraries and the NVIDIA driver broke the
desktop ---i.e., after reboot, the GDM target never showed up due to a Clutter
error.

Synaptic's history shows the following as installed/upgraded/removed on that
day:


Commit Log for Wed Nov  1 08:23:33 2017


Removed the following packages:
libegl1-glvnd-nvidia
libegl1-mesa-dev
libgl1-mesa-glx:i386
libgtk-3-dev
primus
primus-libs-ia32:i386
primus-libs:i386

Upgraded the following packages:
debconf (1.5.63) to 1.5.64
debconf-i18n (1.5.63) to 1.5.64
eog-plugin-map (3.25.92-1) to 3.26.1-1
epiphany-browser (3.24.3-1) to 3.26.1-1
epiphany-browser-data (3.24.3-1) to 3.26.1-1
giada (0.14.1~dfsg1-1) to 0.14.3~dfsg1-1
gir1.2-javascriptcoregtk-4.0 (2.16.6-1) to 2.18.1-1
gir1.2-webkit2-4.0 (2.16.6-1) to 2.18.1-1
gnome-maps (3.25.91-1) to 3.26.1-1
gnome-session (3.24.1-2) to 3.26.1-1
gnome-session-bin (3.24.1-2) to 3.26.1-1
gnome-session-common (3.24.1-2) to 3.26.1-1
gnome-software (3.22.5-1) to 3.26.1-2
gnome-software-common (3.22.5-1) to 3.26.1-2
gnome-software-plugin-flatpak (3.22.5-1) to 3.26.1-2
gstreamer1.0-plugins-bad (1.12.2-1+b1) to 1.12.3-2
libegl-nvidia0 (375.82-5) to 375.82-7
libegl1-mesa (13.0.6-1+b2) to 17.2.3-1
libgbm1 (13.0.6-1+b2) to 17.2.3-1
libgl1-glvnd-nvidia-glx (375.82-5) to 375.82-7
libgl1-mesa-dri (13.0.6-1+b2) to 17.2.3-1
libgl1-mesa-dri:i386 (13.0.6-1+b2) to 17.2.3-1
libgl1-mesa-glx (13.0.6-1+b2) to 17.2.3-1
libgl1-nvidia-glvnd-glx (375.82-5) to 375.82-7
libglapi-mesa (13.0.6-1+b2) to 17.2.3-1
libglapi-mesa:i386 (13.0.6-1+b2) to 17.2.3-1
libgles-nvidia1 (375.82-5) to 375.82-7
libgles-nvidia2 (375.82-5) to 375.82-7
libgles1-glvnd-nvidia (375.82-5) to 375.82-7
libgles1-nvidia (375.82-5) to 375.82-7
libgles2-glvnd-nvidia (375.82-5) to 375.82-7
libgles2-mesa (13.0.6-1+b2) to 17.2.3-1
libgles2-nvidia (375.82-5) to 375.82-7
libglx-nvidia0 (375.82-5) to 375.82-7
libglx0-glvnd-nvidia (375.82-5) to 375.82-7
libgstreamer-plugins-bad1.0-0 (1.12.2-1+b1) to 1.12.3-2
libharfbuzz-dev (1.5.1-1) to 1.6.2-1
libharfbuzz-gobject0 (1.5.1-1) to 1.6.2-1
libharfbuzz-icu0 (1.5.1-1) to 1.6.2-1
libharfbuzz0b (1.5.1-1) to 1.6.2-1
libjavascriptcoregtk-4.0-18 (2.16.6-1) to 2.18.1-1
libnetcdf-c++4 (4.2-7) to 4.2-7+b1
libnvidia-cfg1 (375.82-5) to 375.82-7
libnvidia-eglcore (375.82-5) to 375.82-7
libnvidia-glcore (375.82-5) to 375.82-7
libnvidia-ml1 (375.82-5) to 375.82-7
libosmesa6 (13.0.6-1+b2) to 17.2.3-1
libwayland-egl1-mesa (13.0.6-1+b2) to 17.2.3-1
libwebkit2gtk-4.0-37 (2.16.6-1) to 2.18.1-1
libwebkit2gtk-4.0-37-gtk2 (2.16.6-1) to 2.18.1-1
libxatracker2 (13.0.6-1+b2) to 17.2.3-1
mesa-vdpau-drivers (13.0.6-1+b2) to 17.2.3-1
netcdf-bin (1:4.4.1.1-2) to 1:4.5.0-1
nvidia-alternative (375.82-5) to 375.82-7
nvidia-driver (375.82-5) to 375.82-7
nvidia-driver-bin (375.82-5) to 375.82-7
nvidia-driver-libs (375.82-5) to 375.82-7
nvidia-egl-icd (375.82-5) to 375.82-7
nvidia-kernel-support (375.82-5) to 375.82-7
nvidia-smi (375.82-5) to 375.82-7
nvidia-vdpau-driver (375.82-5) to 375.82-7
nvidia-vulkan-icd (375.82-5) to 375.82-7
primus-libs (0~20150328-4) to 0~20150328-5
xserver-xorg-video-nvidia (375.82-5) to 375.82-7
xwayland (2:1.19.3-2) to 2:1.19.5-1

Installed the following packages:
gir1.2-harfbuzz-0.0 (1.6.2-1)
libegl1 (0.2.999+git20170802-5)
libfwupd2 (1.0.0-4)
libglvnd-core-dev (0.2.999+git20170802-5)
libglvnd0:i386 (0.2.999+git20170802-5)
libglx-mesa0 (17.2.3-1)
libglx-mesa0:i386 (17.2.3-1)
libllvm5.0 (1:5.0~+rc2-1)
libllvm5.0:i386 (1:5.0~+rc2-1)
libnetcdf13 (1:4.5.0-1)
librtmidi4 (3.0.0~ds1-2)
libxcb-xfixes0:i386 (1.12-1)
python3-debconf (1.5.64)




In order to solved the issue, I uninstalled all the NVIDIA-related packages,
reinstalled GDM and blacklisted nouveau.

After that, I tried installing bumblebee-nvidia again, which effectively broke
the system once again.

So it seems the bumblebee-nvidia package is not compatible with the newest mesa
and NVIDIA drivers.




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

Kernel: Linux 4.13.0-1-amd64 (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)

Versions of packages bumblebee-nvidia depends on:
pn  bumblebee
ii  glx-alternative-nvidia   0.8.0
pn  nvidia-driver | nvidia-legacy-340xx-driver | nvidia-legacy-304xx-dr  

bumblebee-nvidia recommends no packages.


Bug#880702: test-suite failures on i386

2017-11-03 Thread Michael Biebl
Source: json-glib
Version: 1.4.2-1
Severity: serious
Forwarded: https://gitlab.gnome.org/GNOME/json-glib/issues/27

The test-suite fails on i386:

 1/14 array   FAIL 0.01 s
 2/14 boxed   OK   0.01 s
 3/14 builder OK   0.01 s
 4/14 generator   OK   0.01 s
 5/14 gvariantOK   0.01 s
 6/14 invalid OK   0.01 s
 7/14 nodeFAIL 0.00 s
 8/14 object  OK   0.00 s
 9/14 parser  FAIL 0.00 s
10/14 pathOK   0.01 s
11/14 reader  FAIL 0.00 s
12/14 serialize-simpleOK   0.00 s
13/14 serialize-complex   OK   0.00 s
14/14 serialize-full  OK   0.00 s

OK:10
FAIL:   4
SKIP:   0
TIMEOUT:0


The output from the failed tests:

 1/14 array   FAIL 0.01 s

--- command ---
G_TEST_SRCDIR='/<>/json-glib/tests' 
G_TEST_BUILDDIR='/<>/obj-i686-linux-gnu/json-glib/tests' 
/<>/obj-i686-linux-gnu/json-glib/tests/array --tap -k
--- stdout ---
# random seed: R02S5e6d53faa488d2a4b87a417cf49ed92b
1..4
# Start of array tests
ok 1 /array/empty-array
# Json:ERROR:../json-glib/tests/array.c:40:test_add_element: assertion failed 
(json_array_get_double_element (array, 2) == 3.14): (3.14 == 3.14)
--- stderr ---
**
Json:ERROR:../json-glib/tests/array.c:40:test_add_element: assertion failed 
(json_array_get_double_element (array, 2) == 3.14): (3.14 == 3.14)
---

 7/14 nodeFAIL 0.00 s

--- command ---
G_TEST_SRCDIR='/<>/json-glib/tests' 
G_TEST_BUILDDIR='/<>/obj-i686-linux-gnu/json-glib/tests' 
/<>/obj-i686-linux-gnu/json-glib/tests/node --tap -k
--- stdout ---
# random seed: R02S52f04c643cbae08bdba2de4c7274d1f4
1..27
# Start of nodes tests
ok 1 /nodes/gvalue
# Start of init tests
ok 2 /nodes/init/int
# Json:ERROR:../json-glib/tests/node.c:22:test_init_double: assertion failed 
(json_node_get_double (node) == 3.14159): (3.14159 == 3.14159)
--- stderr ---
**
Json:ERROR:../json-glib/tests/node.c:22:test_init_double: assertion failed 
(json_node_get_double (node) == 3.14159): (3.14159 == 3.14159)
---

 9/14 parser  FAIL 0.00 s

--- command ---
G_TEST_SRCDIR='/<>/json-glib/tests' 
G_TEST_BUILDDIR='/<>/obj-i686-linux-gnu/json-glib/tests' 
/<>/obj-i686-linux-gnu/json-glib/tests/parser --tap -k
--- stdout ---
# random seed: R02Scedda0d35f14df8a2ae97df7062aa61c
1..12
# Start of parser tests
ok 1 /parser/empty-string
# Json:ERROR:../json-glib/tests/parser.c:47:verify_negative_double_value: 
assertion failed (-3.14 == json_node_get_double (node)): (-3.14 == -3.14)
--- stderr ---
**
Json:ERROR:../json-glib/tests/parser.c:47:verify_negative_double_value: 
assertion failed (-3.14 == json_node_get_double (node)): (-3.14 == -3.14)
---

11/14 reader  FAIL 0.00 s

--- command ---
G_TEST_SRCDIR='/<>/json-glib/tests' 
G_TEST_BUILDDIR='/<>/obj-i686-linux-gnu/json-glib/tests' 
/<>/obj-i686-linux-gnu/json-glib/tests/reader --tap -k
--- stdout ---
# random seed: R02Sb9558b796993f6397530a2d5d259b007
1..4
# Start of reader tests
ok 1 /reader/base-array
# Json:ERROR:../json-glib/tests/reader.c:81:test_base_object: assertion failed 
(json_reader_get_double_value (reader) == 42.47): (42.47 == 42.47)
--- stderr ---
**
Json:ERROR:../json-glib/tests/reader.c:81:test_base_object: assertion failed 
(json_reader_get_double_value (reader) == 42.47): (42.47 == 42.47)
---



Full build log at 
https://buildd.debian.org/status/fetch.php?pkg=json-glib=i386=1.4.2-1=1509747453=0



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

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



Bug#880701: lintian: Please update the Debian archive sections

2017-11-03 Thread Guillem Jover
Package: lintian
Version: 2.5.58
Severity: wishlist
Tags: patch
User: guardi...@namespace.hadrons.org
Usertags: sectionspace-expansion
Control: block 847520 by -1

Hi!

Here's a patch updating the Debian archive sections, which includes the
new golang section, which was approved by ftp-masters.

Thanks,
Guillem
From ca51028553e9fab0cced2adfc67e4d2514d5998a Mon Sep 17 00:00:00 2001
From: Guillem Jover 
Date: Sat, 4 Nov 2017 01:23:11 +0100
Subject: [PATCH] c/fields, d/fields: Add golang section

---
 checks/fields.desc| 2 +-
 data/fields/archive-sections  | 1 +
 data/fields/name_section_mappings | 1 +
 3 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/checks/fields.desc b/checks/fields.desc
index ad2221161..91bfe5aa9 100644
--- a/checks/fields.desc
+++ b/checks/fields.desc
@@ -331,7 +331,7 @@ Info: The "Section:" field in this package's control file is not one of
  the sections in use on the ftp archive.  Valid sections are currently
  admin, comm, cli-mono, database, debug, devel, doc,
  editors, electronics, embedded, fonts, games, gnome, gnu-r,
- gnustep, graphics, hamradio, haskell, httpd, interpreters,
+ gnustep, golang, graphics, hamradio, haskell, httpd, interpreters,
  java, javascript, kde, libdevel, libs, lisp, localization, kernel, mail,
  math, misc, net, news, ocaml, oldlibs, otherosfs, perl,
  php, python, ruby, rust, science, shells, sound, tex, text,
diff --git a/data/fields/archive-sections b/data/fields/archive-sections
index 56c1bdf92..0a1f6441a 100644
--- a/data/fields/archive-sections
+++ b/data/fields/archive-sections
@@ -17,6 +17,7 @@ games
 gnome
 gnu-r
 gnustep
+golang
 graphics
 hamradio
 haskell
diff --git a/data/fields/name_section_mappings b/data/fields/name_section_mappings
index 1fdc1cfd7..d4fe50c8b 100644
--- a/data/fields/name_section_mappings
+++ b/data/fields/name_section_mappings
@@ -17,6 +17,7 @@
 -elisp(?:-.*)$  => lisp
 ^lib.*-guile$   => lisp
 ^guile- => lisp
+^golang-=> golang
 ^lib.*-perl$ => perl
 lib.*-cil(?:-dev)?$  => cli-mono
 ^lib.*-(?:java|gcj|jni)$=> java
-- 
2.15.0



Bug#880700: zsh: Please update the Debian archive sections

2017-11-03 Thread Guillem Jover
Package: zsh
Version: 5.4.2-2
Severity: wishlist
Tags: patch
User: guardi...@namespace.hadrons.org
Usertags: sectionspace-expansion
Control: block 847520 by -1

Hi!

Here's a patch updating the Debian archive sections, which includes the
new golang section, which was approved by ftp-masters.

Thanks,
Guillem
From 13bfd4237013d1160dec65bed80057364caf5c59 Mon Sep 17 00:00:00 2001
From: Guillem Jover 
Date: Sat, 4 Nov 2017 01:16:52 +0100
Subject: [PATCH] Update Debian archive sections

Add new goland section.
---
 debian/patches/update-debian-sections.patch | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/debian/patches/update-debian-sections.patch b/debian/patches/update-debian-sections.patch
index 390f5c701..f7e61b494 100644
--- a/debian/patches/update-debian-sections.patch
+++ b/debian/patches/update-debian-sections.patch
@@ -21,7 +21,7 @@ index 086196c4a..d06f55d23 100644
'(-s --suite)'{-s,--suite=}':suite:_values -s , "suite list" oldstable stable testing unstable experimental'
':package:_deb_packages avail'
 -  ':section:(admin base comm contrib/admin contrib/comm contrib/devel contrib/doc contrib/games contrib/graphics contrib/interpreters contrib/kde contrib/libdevel contrib/libs contrib/mail contrib/math contrib/misc contrib/net contrib/otherosfs contrib/perl contrib/python contrib/science contrib/sound contrib/tex contrib/text contrib/utils contrib/web contrib/x11 devel doc editors electronics embedded games gnome graphics hamradio interpreters kde libdevel libs mail math misc net news non-free/admin non-free/base non-free/comm non-free/devel non-free/doc non-free/editors non-free/electronics non-free/games non-free/graphics non-free/hamradio non-free/libdevel non-free/libs non-free/mail non-free/math non-free/misc non-free/net non-free/news non-free/otherosfs non-free/python non-free/science non-free/sound non-free/tex non-free/text non-free/utils non-free/web non-free/x11 oldlibs otherosfs perl python science shells sound tex text utils web x11)'
-+  ':section:({,contrib/,non-free/}{admin,cli-mono,comm,database,debug,devel,doc,editors,education,electronics,embedded,fonts,games,gnome,gnu-r,gnustep,graphics,hamradio,haskell,httpd,interpreters,introspection,java,javascript,kde,kernel,libdevel,libs,lisp,localization,mail,math,metapackages,misc,net,news,ocaml,oldlibs,otherosfs,perl,php,python,ruby,rust,science,shells,sound,tex,text,utils,vcs,video,web,x11,xfce,zope})'
++  ':section:({,contrib/,non-free/}{admin,cli-mono,comm,database,debug,devel,doc,editors,education,electronics,embedded,fonts,games,gnome,gnu-r,gnustep,golang,graphics,hamradio,haskell,httpd,interpreters,introspection,java,javascript,kde,kernel,libdevel,libs,lisp,localization,mail,math,metapackages,misc,net,news,ocaml,oldlibs,otherosfs,perl,php,python,ruby,rust,science,shells,sound,tex,text,utils,vcs,video,web,x11,xfce,zope})'
':priority:(extra important optional required standard)'
  )
  ;;
@@ -41,7 +41,7 @@ index 08a1078e2..4c041bc36 100644
 +	  science rust ruby python php perl otherosfs oldlibs ocaml \
 +	  news net misc metapackages math mail localization lisp libs \
 +	  libdevel kernel kde javascript java introspection \
-+	  interpreters httpd haskell hamradio graphics gnustep gnu-r \
++	  interpreters httpd haskell hamradio graphics golang gnustep gnu-r \
 +	  gnome games fonts embedded electronics education editors doc \
 +	  devel debug database comm cli-mono admin && ret=0
;;
-- 
2.15.0



Bug#880699: neovim: Please update the Debian archive sections

2017-11-03 Thread Guillem Jover
Package: neovim
Version: 0.2.0-4
Severity: wishlist
Tags: patch
User: guardi...@namespace.hadrons.org
Usertags: sectionspace-expansion
Control: block 847520 by -1

Hi!

Here's a patch updating the Debian archive sections, which includes the
new golang section, which was approved by ftp-masters.

Thanks,
Guillem
From 195868b5a8b2c75400023fa4dd35d76d4461d55d Mon Sep 17 00:00:00 2001
From: Guillem Jover 
Date: Sat, 4 Nov 2017 01:12:53 +0100
Subject: [PATCH] debcontrol: Update Debian archive sections

---
 runtime/syntax/debcontrol.vim | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/runtime/syntax/debcontrol.vim b/runtime/syntax/debcontrol.vim
index b1bc9f8b..886411e1 100644
--- a/runtime/syntax/debcontrol.vim
+++ b/runtime/syntax/debcontrol.vim
@@ -38,7 +38,7 @@ unlet s:kernels s:archs s:pairs
 syn match debcontrolMultiArch contained "\%(no\|foreign\|allowed\|same\)"
 syn match debcontrolName contained "[a-z0-9][a-z0-9+.-]\+"
 syn match debcontrolPriority contained "\(extra\|important\|optional\|required\|standard\)"
-syn match debcontrolSection contained "\v((contrib|non-free|non-US/main|non-US/contrib|non-US/non-free|restricted|universe|multiverse)/)?(admin|cli-mono|comm|database|debian-installer|debug|devel|doc|editors|education|electronics|embedded|fonts|games|gnome|gnustep|gnu-r|graphics|hamradio|haskell|httpd|interpreters|introspection|java|javascript|kde|kernel|libs|libdevel|lisp|localization|mail|math|metapackages|misc|net|news|ocaml|oldlibs|otherosfs|perl|php|python|ruby|rust|science|shells|sound|text|tex|utils|vcs|video|web|x11|xfce|zope)"
+syn match debcontrolSection contained "\v((contrib|non-free|non-US/main|non-US/contrib|non-US/non-free|restricted|universe|multiverse)/)?(admin|cli-mono|comm|database|debian-installer|debug|devel|doc|editors|education|electronics|embedded|fonts|games|gnome|gnustep|gnu-r|golang|graphics|hamradio|haskell|httpd|interpreters|introspection|java|javascript|kde|kernel|libs|libdevel|lisp|localization|mail|math|metapackages|misc|net|news|ocaml|oldlibs|otherosfs|perl|php|python|ruby|rust|science|shells|sound|text|tex|utils|vcs|video|web|x11|xfce|zope)"
 syn match debcontrolPackageType contained "u\?deb"
 syn match debcontrolVariable contained "\${.\{-}}"
 syn match debcontrolDmUpload contained "\cyes"
-- 
2.15.0



Bug#880698: vim: Please update the Debian archive sections

2017-11-03 Thread Guillem Jover
Package: vim
Version: 2:8.0.1257-1
Severity: wishlist
Tags: patch
User: guardi...@namespace.hadrons.org
Usertags: sectionspace-expansion
Control: block 847520 by -1

Hi!

Here's a patch updating the Debian archive sections, which includes the
new golang section, which was approved by ftp-masters.

Thanks,
Guillem
From 876e2fb9eb23da75a3ca2c15f87645b23a7ecc16 Mon Sep 17 00:00:00 2001
From: Guillem Jover 
Date: Sat, 4 Nov 2017 00:01:08 +0100
Subject: [PATCH] debcontrol: Update Debian archive sections

---
 runtime/syntax/debcontrol.vim | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/runtime/syntax/debcontrol.vim b/runtime/syntax/debcontrol.vim
index 1131c9e12..2adaa295f 100644
--- a/runtime/syntax/debcontrol.vim
+++ b/runtime/syntax/debcontrol.vim
@@ -38,7 +38,7 @@ unlet s:kernels s:archs s:pairs
 syn match debcontrolMultiArch contained "\%(no\|foreign\|allowed\|same\)"
 syn match debcontrolName contained "[a-z0-9][a-z0-9+.-]\+"
 syn match debcontrolPriority contained "\(extra\|important\|optional\|required\|standard\)"
-syn match debcontrolSection contained "\v((contrib|non-free|non-US/main|non-US/contrib|non-US/non-free|restricted|universe|multiverse)/)?(admin|cli-mono|comm|database|debian-installer|debug|devel|doc|editors|education|electronics|embedded|fonts|games|gnome|gnustep|gnu-r|graphics|hamradio|haskell|httpd|interpreters|introspection|java%(script)=|kde|kernel|libs|libdevel|lisp|localization|mail|math|metapackages|misc|net|news|ocaml|oldlibs|otherosfs|perl|php|python|ruby|rust|science|shells|sound|text|tex|utils|vcs|video|web|x11|xfce|zope)"
+syn match debcontrolSection contained "\v((contrib|non-free|non-US/main|non-US/contrib|non-US/non-free|restricted|universe|multiverse)/)?(admin|cli-mono|comm|database|debian-installer|debug|devel|doc|editors|education|electronics|embedded|fonts|games|gnome|gnustep|gnu-r|golang|graphics|hamradio|haskell|httpd|interpreters|introspection|java%(script)=|kde|kernel|libs|libdevel|lisp|localization|mail|math|metapackages|misc|net|news|ocaml|oldlibs|otherosfs|perl|php|python|ruby|rust|science|shells|sound|text|tex|utils|vcs|video|web|x11|xfce|zope)"
 syn match debcontrolPackageType contained "u\?deb"
 syn match debcontrolVariable contained "\${.\{-}}"
 syn match debcontrolDmUpload contained "\cyes"
-- 
2.15.0



Bug#855123: mutt: terrible default setting in /etc

2017-11-03 Thread Anonymous
Package: mutt
Version: 1.7.2-1
Followup-For: Bug #855123

Dear Maintainer,

It's a bad idea to enable GPGME by default.  GPGME introduces serious
limitations that make it unnacceptible as a default setting.  Mutt
users cannot even send messages to protonmail or hushmail users when
GPGME is on.  The man page is correct, and the default should be off.

This bug was unfortunately reported upstream:

  https://github.com/neomutt/neomutt/issues/904

-- Package-specific info:
NeoMutt 20170113 (1.7.2)
Copyright (C) 1996-2016 Michael R. Elkins and others.
Mutt comes with ABSOLUTELY NO WARRANTY; for details type `mutt -vv'.
Mutt is free software, and you are welcome to redistribute it
under certain conditions; type `mutt -vv' for details.

System: Linux 4.9.0-4-amd64 (x86_64)
libidn: 1.33 (compiled with 1.33)
hcache backends: tokyocabinet

Compiler:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/6/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 6.3.0-2' 
--with-bugurl=file:///usr/share/doc/gcc-6/README.Bugs 
--enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr 
--program-suffix=-6 --program-prefix=x86_64-linux-gnu- --enable-shared 
--enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext 
--enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ 
--enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes 
--with-default-libstdcxx-abi=new --enable-gnu-unique-object 
--disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie 
--with-system-zlib --disable-browser-plugin --enable-java-awt=gtk 
--enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-6-amd64/jre 
--enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-6-amd64 
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-6-amd64 
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar 
--with-target-sy
 stem-zlib --enable-objc-gc=auto --enable-multiarch --with-arch-32=i686 
--with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib 
--with-tune=generic --enable-checking=release --build=x86_64-linux-gnu 
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 6.3.0 20161229 (Debian 6.3.0-2) 

Configure options: '--build=x86_64-linux-gnu' '--prefix=/usr' 
'--includedir=\${prefix}/include' '--mandir=\${prefix}/share/man' 
'--infodir=\${prefix}/share/info' '--sysconfdir=/etc' '--localstatedir=/var' 
'--disable-silent-rules' '--libdir=\${prefix}/lib/x86_64-linux-gnu' 
'--libexecdir=\${prefix}/lib/x86_64-linux-gnu' '--disable-maintainer-mode' 
'--disable-dependency-tracking' '--with-mailpath=/var/mail' 
'--enable-compressed' '--enable-debug' '--enable-fcntl' '--enable-hcache' 
'--enable-gpgme' '--enable-imap' '--enable-smtp' '--enable-pop' 
'--enable-sidebar' '--enable-nntp' '--enable-notmuch' '--disable-fmemopen' 
'--with-curses' '--with-gnutls' '--with-gss' '--with-idn' '--with-mixmaster' 
'--with-sasl' '--without-gdbm' '--without-bdb' '--without-qdbm' 
'--with-tokyocabinet' 'build_alias=x86_64-linux-gnu' 'CFLAGS=-g -O2 
-fdebug-prefix-map=/build/mutt-K2ak0h/mutt-1.7.2=. -fstack-protector-strong 
-Wformat -Werror=format-security' 'LDFLAGS=-Wl,-z,relro -Wl,-z,now' 
'CPPFLAGS=-Wdate-time -D
 _FORTIFY_SOURCE=2'

Compilation CFLAGS: -Wall -pedantic -Wno-long-long -g -O2 
-fdebug-prefix-map=/build/mutt-K2ak0h/mutt-1.7.2=. -fstack-protector-strong 
-Wformat -Werror=format-security -fno-delete-null-pointer-checks

Compile options:
+CRYPT_BACKEND_CLASSIC_PGP +CRYPT_BACKEND_CLASSIC_SMIME +CRYPT_BACKEND_GPGME 
+DEBUG +DL_STANDALONE +ENABLE_NLS -EXACT_ADDRESS -HOMESPOOL -LOCALES_HACK 
-SUN_ATTACHMENT +HAVE_BKGDSET +HAVE_COLOR +HAVE_CURS_SET +HAVE_FUTIMENS 
+HAVE_GETADDRINFO +HAVE_GETSID +HAVE_ICONV +HAVE_LANGINFO_CODESET 
+HAVE_LANGINFO_YESEXPR +HAVE_LIBIDN +HAVE_META +HAVE_REGCOMP +HAVE_RESIZETERM 
+HAVE_START_COLOR +HAVE_TYPEAHEAD +HAVE_WC_FUNCS +ICONV_NONTRANS 
+USE_COMPRESSED +USE_DOTLOCK +USE_FCNTL -USE_FLOCK -USE_FMEMOPEN -USE_GNU_REGEX 
+USE_GSS +USE_HCACHE +USE_IMAP +USE_NOTMUCH +USE_NNTP +USE_POP +USE_SASL 
+USE_SETGID +USE_SIDEBAR +USE_SMTP +USE_SSL_GNUTLS -USE_SSL_OPENSSL 
-DOMAIN
MIXMASTER="mixmaster"
-ISPELL
SENDMAIL="/usr/sbin/sendmail"
MAILPATH="/var/mail"
PKGDATADIR="/usr/share/mutt"
SYSCONFDIR="/etc"
EXECSHELL="/bin/sh"

patch-attach-headers-color-neomutt
patch-compose-to-sender-neomutt
patch-compress-neomutt
patch-cond-date-neomutt
patch-encrypt-to-self-neomutt
patch-fmemopen-neomutt
patch-forgotten-attachments-neomutt
patch-forwref-neomutt
patch-ifdef-neomutt
patch-index-color-neomutt
patch-initials-neomutt
patch-keywords-neomutt
patch-kyoto-neomutt
patch-limit-current-thread-neomutt
patch-lmdb-neomutt
patch-multiple-fcc-neomutt
patch-nested-if-neomutt
patch-new-mail-neomutt
patch-nntp-neomutt
patch-notmuch-neomutt
patch-progress-neomutt
patch-quasi-delete-neomutt
patch-reply-with-xorig-neomutt

Bug#880697: libwebkit2gtk-4.0: ICC not applied on this jpeg image

2017-11-03 Thread Jérémy Lal
Package: libwebkit2gtk-4.0-37
Version: 2.18.2-1
Severity: normal
File: libwebkit2gtk-4.0

Hi,

this image:
http://okgo.net/build/wp-content/uploads/2016/11/Email-Blast-Photo.jpg
clearly does not have its color profile correctly applied.

See also screenshot for comparison with chromium. Firefox also shows correct 
colors.

Regards,
Jérémy

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

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

Versions of packages libwebkit2gtk-4.0-37:amd64 depends on:
ii  libatk1.0-0 2.26.1-1
ii  libc6   2.24-17
ii  libcairo2   1.15.8-2
ii  libegl1 0.2.999+git20170802-5
ii  libenchant1c2a  1.6.0-11.1
ii  libfontconfig1  2.12.3-0.2
ii  libfreetype62.8.1-0.1
ii  libgcc1 1:7.2.0-12
ii  libgcrypt20 1.7.9-1
ii  libgdk-pixbuf2.0-0  2.36.11-1
ii  libgl1  0.2.999+git20170802-5
ii  libglib2.0-02.54.2-1
ii  libgstreamer-plugins-bad1.0-0   1.12.3-2
ii  libgstreamer-plugins-base1.0-0  1.12.3-1
ii  libgstreamer1.0-0   1.12.3-1
ii  libgtk-3-0  3.22.25-1
ii  libharfbuzz-icu01.6.2-1
ii  libharfbuzz0b   1.6.2-1
ii  libhyphen0  2.8.8-5
ii  libicu5757.1-8
ii  libjavascriptcoregtk-4.0-18 2.18.2-1
ii  libjpeg62-turbo 1:1.5.2-2
ii  libnotify4  0.7.7-2
ii  libpango-1.0-0  1.40.13-1
ii  libpng16-16 1.6.34-1
ii  libsecret-1-0   0.18.5-4
ii  libsoup2.4-12.60.2-1
ii  libsqlite3-03.20.1-2
ii  libstdc++6  7.2.0-12
ii  libtasn1-6  4.12-2.1
ii  libwayland-client0  1.14.0-1
ii  libwayland-egl1-mesa [libwayland-egl1]  17.2.4-1
ii  libwayland-server0  1.14.0-1
ii  libwebp60.6.0-3
ii  libx11-62:1.6.4-3
ii  libxcomposite1  1:0.4.4-2
ii  libxdamage1 1:1.1.4-3
ii  libxml2 2.9.4+dfsg1-5+b1
ii  libxslt1.1  1.1.29-2.2
ii  zlib1g  1:1.2.8.dfsg-5

Versions of packages libwebkit2gtk-4.0-37:amd64 recommends:
ii  gstreamer1.0-plugins-base  1.12.3-1
ii  gstreamer1.0-plugins-good  1.12.3-1
ii  gstreamer1.0-pulseaudio1.12.3-1
ii  libgl1-mesa-dri17.2.4-1

Versions of packages libwebkit2gtk-4.0-37:amd64 suggests:
ii  libwebkit2gtk-4.0-37-gtk2  2.18.2-1

-- no debconf information


Bug#880635: rmadison does not look in provides

2017-11-03 Thread Mattia Rizzolo
On Fri, Nov 03, 2017 at 01:53:58PM +0530, Pirate Praveen wrote:
> > I'm not sure how you expect the devscripts team to change anything
> > there.
> 
> rmadison command is provided by devscripts so I thought it was the right
> place.

Besides, Adam reassigned it to qa.d.o, but qa.d.o only provides *one*
implementation of madison, which is not even used anymore.  Nowadays
devscripts' `rmadison` queries ftp-masters API which basically just
exposes `dak ls` over HTTP.

So it's really all for ftp.d.o people.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature


Bug#880696: debian-refcard: Debian Reference Card translation to russian contains errors in command definitions

2017-11-03 Thread Alex
Package: debian-refcard
Version: 10.0:all
Severity: minor
Tags: l10n

I have found 2 errors in russian translation of Debian Reference Card.
https://www.debian.org/doc/manuals/refcard/refcard.ru.pdf

They are not actually translation errors but they were introduced in the
commands during translation.

Firstly, in "Daemons and System" section (ru: "Службы и система") the first
command, the one to restart a service, is missing sevice name:
- english version - systemctl restart name.service
- russian version - systemctl restart
It's not actually missing, but it's invisible due to being out of cell bounds.

Secondly, in "Important Shell Commands" (ru: "Важные команды оболочки командной
строки"), move command is spelled "mv file1file2" (ru: "mv файл1файл2") - no
whitespace between "file1" and "file2".



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

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

debian-refcard depends on no packages.

Versions of packages debian-refcard recommends:
ii  zathura-pdf-poppler [pdf-viewer]  0.2.7-1

Versions of packages debian-refcard suggests:
pn  doc-base  


Bug#879886: [Debian-med-packaging] libhts2: libhts2 needs to handle ABI changes

2017-11-03 Thread Mattia Rizzolo
On Fri, Nov 03, 2017 at 02:52:11PM -0700, Diane Trout wrote:
> I restored it with git-revert and rebuilt 1.4.1 and 1.5 and discovered
> there were #MISSING# symbols in each rebuild

That's at most to be expected, there was a SONAME bump in the meantime.

> 1.2 -> 1.4.1 had missing symbols but there was a package name &
> soversion bump from libhts1 to libhts2

Exactly.

> There was also symbols removed between 1.4.1 to 1.5 but upstream didn't
> change their SOVERSION.

This is one of the real problem.  So if those symbols that were removed
were actually supposed to be part of a private API and not exported, and
nobody were supposed to try to reach them, then perahps they might be
marked as optional.  But it needs to be evaluated accurately on a
symbol-by-symbols basis.
Personally, from the very quick look I had at them the other day, they
didn't look like some "private API".

> As an aside while I was looking at the missing symbols I found mfprintf
> was still listed in htslib 1.5's cram/mFILE.h, but the implementation
> had been removed from cram/mFILE.c

mh what the..

> Should we be patching the SOVERSION?
> File a bug upstream to have them update SOVERSION?

Depending on the kind of upstream, I'd either try to reach out to them
and see what are their plan for the next release where they could bump
the version, or rename the binary package to get things rebuilt
appropriately (unless we decide to declare those symbols as optional…).



Diane: thank you for dealing with this bug.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature


Bug#879453: wine32: Unmet dependencies in Stretch

2017-11-03 Thread Jens Reyer
On 11/04/2017 12:07 AM, Omar Jair Purata Funes wrote:
> Apt policy reveals:
> 
> apt policy libsystemd0
> libsystemd0:
>   Installed: 234-3~bpo9+1
>   Candidate:  234-3~bpo9+1
>   Version table:
>  *** 234-3~bpo9+1 100
> 100 http://deb.debian.org/debian stretch-backports/main amd64
> Packages
> 100 /var/lib/dpkg/status
>  232-25+deb9u1 500
> 500 http://deb.debian.org/debian stretch/main amd64 Packages
> 
> And:
> 
> apt policy libsystemd0:i386
> libsystemd0:i386:
>   Installed: (none)
>   Candidate:  232-25+deb9u1
>   Version table:
>  234-3~bpo9+1 100
> 100 http://deb.debian.org/debian stretch-backports/main i386
> Packages
>  232-25+deb9u1 500
> 500 http://deb.debian.org/debian stretch/main i386 Packages
> 
> second triggers a lot of packages removal (system is up to date).
> 

Ah, so for whatever reason you have libsystemd0 installed from
stretch-backports on amd64.

If this was not intended and is not required by some other package you
might try to downgrade it (and eventually other packages) by installing
the regular stretch version again.  (Downgrades are not officially
supported but usually work.  I recommend to keep as many packages as
possible in their pure stretch version.)  Something like:

sudo apt install libsystemd0/stretch


Alternatively you might just start with installing libsystemd0:i386 from
stretch backports:

sudo apt install libsystemd0/stretch-backports


As soon as you have libsystemd0 (and all other problematic packages)
installed on both amd64 and i386 you can try wine again.


Greets
jre



Bug#847531: dl10n: Update for new programming language sections

2017-11-03 Thread Guillem Jover
Control: user guardi...@namespace.hadrons.org
Control: usertags -1 sectionspace-expansion
Control: block 847520 by -1

Hi!

Here's a new patch updating the Debian archive sections, which includes
among others the new golang section, which was approved by ftp-masters.

Thanks,
Guillem
diff -Nru dl10n-3.00/debian/changelog dl10n-3.00+nmu1/debian/changelog
--- dl10n-3.00/debian/changelog 2012-01-28 08:13:11.0 +0100
+++ dl10n-3.00+nmu1/debian/changelog2017-11-03 19:41:07.0 +0100
@@ -1,3 +1,10 @@
+dl10n (3.00+nmu1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Update Debian archive sections.
+
+ -- Guillem Jover   Fri, 03 Nov 2017 19:41:07 +0100
+
 dl10n (3.00) unstable; urgency=low
 
   * First public release after more than 13 years of lawful services for the
diff -Nru dl10n-3.00/dl10n-check dl10n-3.00+nmu1/dl10n-check
--- dl10n-3.00/dl10n-check  2011-03-30 19:41:08.0 +0200
+++ dl10n-3.00+nmu1/dl10n-check 2017-10-26 11:35:45.0 +0200
@@ -1127,12 +1127,14 @@
 gnome
 gnu-r
 gnustep
+golang
 graphics
 hamradio
 haskell
 httpd
 interpreters
 java
+javascript
 kde
 kernel
 libdevel
@@ -1151,6 +1153,7 @@
 php
 python
 ruby
+rust
 science
 shells
 sound
@@ -1181,12 +1184,14 @@
 contrib/gnome
 contrib/gnu-r
 contrib/gnustep
+contrib/golang
 contrib/graphics
 contrib/hamradio
 contrib/haskell
 contrib/httpd
 contrib/interpreters
 contrib/java
+contrib/javascript
 contrib/kde
 contrib/kernel
 contrib/libdevel
@@ -1205,6 +1210,7 @@
 contrib/php
 contrib/python
 contrib/ruby
+contrib/rust
 contrib/science
 contrib/shells
 contrib/sound
@@ -1235,12 +1241,14 @@
 non-free/gnome
 non-free/gnu-r
 non-free/gnustep
+non-free/golang
 non-free/graphics
 non-free/hamradio
 non-free/haskell
 non-free/httpd
 non-free/interpreters
 non-free/java
+non-free/javascript
 non-free/kde
 non-free/kernel
 non-free/libdevel
@@ -1259,6 +1267,7 @@
 non-free/php
 non-free/python
 non-free/ruby
+non-free/rust
 non-free/science
 non-free/shells
 non-free/sound


Bug#880695: gambas3: Please update the Debian and Ubuntu sections

2017-11-03 Thread Guillem Jover
Package: gambas3
Version: 3.9.2-2
Severity: wishlist
Tags: patch
User: guardi...@namespace.hadrons.org
Usertags: sectionspace-expansion
Control: block 847520 by -1

Hi!

Here's a patch updating the Debian and Ubuntu sections, which includes
among others the new golang section, which was approved by ftp-masters.

Thanks,
Guillem
From b881a1e9f3b5a29960dfb6e5c9b90a6b0f9821ab Mon Sep 17 00:00:00 2001
From: Guillem Jover 
Date: Fri, 3 Nov 2017 23:52:17 +0100
Subject: [PATCH] Update Debian and Ubuntu archive sections

---
 app/src/gambas3/install/group/debian | 5 +
 app/src/gambas3/install/group/ubuntu | 5 +
 2 files changed, 10 insertions(+)

diff --git a/app/src/gambas3/install/group/debian b/app/src/gambas3/install/group/debian
index 80f35715..e052d3fc 100644
--- a/app/src/gambas3/install/group/debian
+++ b/app/src/gambas3/install/group/debian
@@ -6,6 +6,7 @@ devel
 debug
 doc
 editors
+education
 electronics
 embedded
 fonts
@@ -14,11 +15,13 @@ gnome
 graphics
 gnu-r
 gnustep
+golang
 hamradio
 haskell
 httpd
 interpreters
 java
+javascript
 kde
 kernel
 libs
@@ -27,6 +30,7 @@ lisp
 localization
 mail
 math
+metapackages
 misc
 net
 news
@@ -37,6 +41,7 @@ perl
 php
 python
 ruby
+rust
 science
 shells
 sound
diff --git a/app/src/gambas3/install/group/ubuntu b/app/src/gambas3/install/group/ubuntu
index 80f35715..e052d3fc 100644
--- a/app/src/gambas3/install/group/ubuntu
+++ b/app/src/gambas3/install/group/ubuntu
@@ -6,6 +6,7 @@ devel
 debug
 doc
 editors
+education
 electronics
 embedded
 fonts
@@ -14,11 +15,13 @@ gnome
 graphics
 gnu-r
 gnustep
+golang
 hamradio
 haskell
 httpd
 interpreters
 java
+javascript
 kde
 kernel
 libs
@@ -27,6 +30,7 @@ lisp
 localization
 mail
 math
+metapackages
 misc
 net
 news
@@ -37,6 +41,7 @@ perl
 php
 python
 ruby
+rust
 science
 shells
 sound
-- 
2.15.0



Bug#880694: myspell-de-de: package is not installable

2017-11-03 Thread Sven Joachim
Package: myspell-de-de
Version: 20161207-2
Severity: grave

The transitional package myspell-de-de is not installable because its
dependency hunspell-de-de has an unversioned Conflicts with it.  This
very much defeats the purpose of a transitional package. 


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

Kernel: Linux 4.14.0-rc7-nouveau (SMP w/2 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)



Bug#879886: [Debian-med-packaging] libhts2: libhts2 needs to handle ABI changes

2017-11-03 Thread Diane Trout

> I believe that adding the symbols file back in is the correct
solution.
>  It should allow dpkg-shlibdeps to generate the correct libhst2
> dependencies version.
> 
> Diane
> 
> 

Graham pointed out there was a symbols file from 1.2 that was removed.

I restored it with git-revert and rebuilt 1.4.1 and 1.5 and discovered
there were #MISSING# symbols in each rebuild

1.2 -> 1.4.1 had missing symbols but there was a package name &
soversion bump from libhts1 to libhts2

There was also symbols removed between 1.4.1 to 1.5 but upstream didn't
change their SOVERSION.

As an aside while I was looking at the missing symbols I found mfprintf
was still listed in htslib 1.5's cram/mFILE.h, but the implementation
had been removed from cram/mFILE.c

Should we be patching the SOVERSION? 
File a bug upstream to have them update SOVERSION?

Diane



Bug#878483: task-gnome-desktop: Drop extra Recommends

2017-11-03 Thread Jeremy Bicha
I redid my patch to not try to change too much. I left
network-manager-gnome alone and kept LibreOffice ­– at least the part
of LibreOffice that the 'gnome' metapackage depends on.

Thanks,
Jeremy Bicha
From 8b4e46360f38f00ad4063c8ed17f57470d609406 Mon Sep 17 00:00:00 2001
From: Jeremy Bicha 
Date: Fri, 3 Nov 2017 16:42:54 -0400
Subject: [PATCH] gnome: Don't recommend Synaptic, Gimp or full LibreOffice

Drop Synaptic since it doesn't work in Wayland. See bug 8183366.
(Alternatives are gnome-software which is already installed, or
gnome-packagekit, or switch to the GNOME on Xorg session.)

The 'gnome' metapackage intentionally installs specific
LibreOffice packages instead of the 'libreoffice' metapackage.

Drop gimp since it's not important enough to install for everyone.
The Debian GNOME team is discussing dropping it from the 'gnome'
metapackage.

Closes: #878483
---
 debian/control | 8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/debian/control b/debian/control
index ef6a0a48..59cbf628 100644
--- a/debian/control
+++ b/debian/control
@@ -76,15 +76,13 @@ Recommends:
 # GNOME support in LibreOffice
 	libreoffice-gnome,
 	libreoffice-evolution,
-# temporarily moved from task-desktop due to #525077
-	gimp,
-# Package management.
-	synaptic,
 # firefox is the most popular web browser at the moment,
 # although both gnome and kde offer their own too
 	firefox-esr | firefox,
 # libreoffice is the best word processor / office suite at the moment
-	libreoffice,
+	libreoffice-writer,
+	libreoffice-calc,
+	libreoffice-impress,
 # make help menu work
 	libreoffice-help-en-us,
 # make thesaurus work
-- 
2.14.1



Bug#880693: mozjs52: Please add support for m68k

2017-11-03 Thread John Paul Adrian Glaubitz
Source: mozjs52
Version: 52.3.1-7
Severity: normal
Tags: patch
User: debian-...@lists.debian.org
Usertags: m68k

Hi!

The attached patch adds support for m68k. It is based on
a number of patches that I submitted to Firefox upstream
but that unfortunately were never merged due to some
disagreement on how to resolve the alignment issues in a
compiler-agnostic way.

Since Debian uses either gcc or clang and not Microsoft's
C/C++ compiler, the patch shouldn't cause any issues since
the "__attribute__ ((aligned(4)))" is understood by both.

Note: This patch needs to be added on top of the patch for
  sh4 support in #880692 [2].

Additional patches for the remaining architectures will
follow shortly.

Thanks for consideration!

Adrian

> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1325771
> [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=880692

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
Description: Add support for m68k
 Based on the patches sent to Firefox upstream.
 See: https://bugzilla.mozilla.org/show_bug.cgi?id=1325771
 .
Author: John Paul Adrian Glaubitz 
Last-Update: 2017-11-03

Index: mozjs52-52.3.1/js/src/gc/Heap.h
===
--- mozjs52-52.3.1.orig/js/src/gc/Heap.h
+++ mozjs52-52.3.1/js/src/gc/Heap.h
@@ -282,7 +282,7 @@ struct Cell
   protected:
 inline uintptr_t address() const;
 inline Chunk* chunk() const;
-} JS_HAZ_GC_THING;
+} JS_HAZ_GC_THING __attribute__ ((aligned(4)));
 
 // A GC TenuredCell gets behaviors that are valid for things in the Tenured
 // heap, such as access to the arena and mark bits.
Index: mozjs52-52.3.1/js/src/jit/AtomicOperations.h
===
--- mozjs52-52.3.1.orig/js/src/jit/AtomicOperations.h
+++ mozjs52-52.3.1/js/src/jit/AtomicOperations.h
@@ -326,6 +326,8 @@ AtomicOperations::isLockfree(int32_t siz
 # include "jit/arm64/AtomicOperations-arm64.h"
 #elif defined(JS_CODEGEN_MIPS32) || defined(JS_CODEGEN_MIPS64)
 # include "jit/mips-shared/AtomicOperations-mips-shared.h"
+#elif defined(__m68k__)
+# include "jit/none/AtomicOperations-ppc.h"
 #elif defined(__ppc__) || defined(__PPC__)
 # include "jit/none/AtomicOperations-ppc.h"
 #elif defined(__sh__)
Index: mozjs52-52.3.1/js/src/jsfriendapi.h
===
--- mozjs52-52.3.1.orig/js/src/jsfriendapi.h
+++ mozjs52-52.3.1/js/src/jsfriendapi.h
@@ -571,7 +571,7 @@ public:
 uint32_t  slotInfo;
 
 static const uint32_t FIXED_SLOTS_SHIFT = 27;
-};
+} __attribute__ ((aligned(4)));
 
 /**
  * This layout is shared by all native objects. For non-native objects, the
Index: mozjs52-52.3.1/mfbt/double-conversion/utils.h
===
--- mozjs52-52.3.1.orig/mfbt/double-conversion/utils.h
+++ mozjs52-52.3.1/mfbt/double-conversion/utils.h
@@ -69,6 +69,8 @@
 #else
 #undef DOUBLE_CONVERSION_CORRECT_DOUBLE_OPERATIONS
 #endif  // _WIN32
+#elif defined(__m68k__)
+#undef DOUBLE_CONVERSION_CORRECT_DOUBLE_OPERATIONS
 #else
 #error Target architecture was not detected as supported by Double-Conversion.
 #endif
Index: mozjs52-52.3.1/mfbt/tests/TestPoisonArea.cpp
===
--- mozjs52-52.3.1.orig/mfbt/tests/TestPoisonArea.cpp
+++ mozjs52-52.3.1/mfbt/tests/TestPoisonArea.cpp
@@ -133,6 +133,9 @@
 #elif defined _ARCH_PPC || defined _ARCH_PWR || defined _ARCH_PWR2
 #define RETURN_INSTR 0x4E800020 /* blr */
 
+#elif defined __m68k__
+#define RETURN_INSTR 0x4E754E75 /* rts; rts */
+
 #elif defined __sparc || defined __sparcv9
 #define RETURN_INSTR 0x81c3e008 /* retl */
 
Index: mozjs52-52.3.1/python/mozbuild/mozbuild/configure/constants.py
===
--- mozjs52-52.3.1.orig/python/mozbuild/mozbuild/configure/constants.py
+++ mozjs52-52.3.1/python/mozbuild/mozbuild/configure/constants.py
@@ -44,6 +44,7 @@ CPU_bitness = {
 'arm': 32,
 'hppa': 32,
 'ia64': 64,
+'m68k': 32,
 'mips32': 32,
 'mips64': 64,
 'ppc': 32,
@@ -87,6 +88,7 @@ CPU_preprocessor_checks = OrderedDict((
 ('mips64', '__mips64'),
 ('mips32', '__mips__'),
 ('sh4', '__sh__'),
+('m68k', '__m68k__'),
 ))
 
 assert sorted(CPU_preprocessor_checks.keys()) == sorted(CPU.POSSIBLE_VALUES)
Index: 
mozjs52-52.3.1/python/mozbuild/mozbuild/test/configure/test_toolchain_configure.py
===
--- 
mozjs52-52.3.1.orig/python/mozbuild/mozbuild/test/configure/test_toolchain_configure.py
+++ 
mozjs52-52.3.1/python/mozbuild/mozbuild/test/configure/test_toolchain_configure.py
@@ -1039,6 +1039,8 @@ class LinuxCrossCompileToolchainTest(Bas
 },

Bug#846042: VTK 8

2017-11-03 Thread 128
Hi,

VTK 8 is available now. Hopefully this wishlist item is fulfilled when 
upgrading to the new version.

thanks



Bug#880692: mozjs52: Please add support for sh4

2017-11-03 Thread John Paul Adrian Glaubitz
Source: mozjs52
Version: 52.3.1-7
Severity: normal
User: debian-sup...@lists.debian.org
Usertags: sh4

Hi!

The attached patch adds support for the sh4 architecture.

The patch is based on my upstream patches which were merged in
Firefox 53 [1].

On top of that, it is necessary to build mozjs52 on sh4 with
PIE disabled as we have currently PIE disabled in gcc on sh4
due to some applications crashing with it enabled:

--- debian/rules.orig   2017-10-20 19:12:58.0 +0200
+++ debian/rules2017-11-03 22:32:18.630130502 +0100
@@ -29,6 +29,12 @@
 CONFIGURE_FLAGS += --disable-ion
 endif
 
+ifeq ($(DEB_HOST_ARCH),sh4)
+CONFIGURE_FLAGS += --disable-pie
+else
+CONFIGURE_FLAGS += --enable-pie
+endif
+
 ifeq ($(DEB_HOST_ARCH_ENDIAN),little)
 ICU_DATA_FILE = icudt58l.dat
 else
@@ -75,7 +81,6 @@
--enable-shared-js \
--enable-gcgenerational \
--disable-optimize \
-   --enable-pie \
$(CONFIGURE_FLAGS)
 
 override_dh_install:

Thanks for consdideration!

Adrian

> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1329194

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
Description: Add support for sh4
 Based on upstreamed patches in Firefox.
 See: https://bugzilla.mozilla.org/show_bug.cgi?id=1329194
 .
Author: John Paul Adrian Glaubitz 
Last-Update: 2017-11-03

--- mozjs52-52.3.1.orig/build/moz.configure/init.configure
+++ mozjs52-52.3.1/build/moz.configure/init.configure
@@ -380,6 +380,9 @@ def split_triplet(triplet):
 elif cpu.startswith('aarch64'):
 canonical_cpu = 'aarch64'
 endianness = 'little'
+elif cpu == 'sh4':
+canonical_cpu = 'sh4'
+endianness = 'little'
 else:
 die('Unknown CPU type: %s' % cpu)
 
--- mozjs52-52.3.1.orig/js/src/jit/AtomicOperations.h
+++ mozjs52-52.3.1/js/src/jit/AtomicOperations.h
@@ -328,6 +328,8 @@ AtomicOperations::isLockfree(int32_t siz
 # include "jit/mips-shared/AtomicOperations-mips-shared.h"
 #elif defined(__ppc__) || defined(__PPC__)
 # include "jit/none/AtomicOperations-ppc.h"
+#elif defined(__sh__)
+# include "jit/none/AtomicOperations-ppc.h"
 #elif defined(__sparc__)
 # include "jit/none/AtomicOperations-sparc.h"
 #elif defined(JS_CODEGEN_NONE)
--- mozjs52-52.3.1.orig/mfbt/tests/TestPoisonArea.cpp
+++ mozjs52-52.3.1/mfbt/tests/TestPoisonArea.cpp
@@ -154,6 +154,9 @@
 #elif defined __s390__
 #define RETURN_INSTR 0x07fe /* br %r14 */
 
+#elif defined __sh__
+#define RETURN_INSTR 0x0b000b00 /* rts; rts */
+
 #elif defined __aarch64__
 #define RETURN_INSTR 0xd65f03c0 /* ret */
 
--- mozjs52-52.3.1.orig/python/mozbuild/mozbuild/configure/constants.py
+++ mozjs52-52.3.1/python/mozbuild/mozbuild/configure/constants.py
@@ -50,6 +50,7 @@ CPU_bitness = {
 'ppc64': 64,
 's390': 32,
 's390x': 64,
+'sh4': 32,
 'sparc': 32,
 'sparc64': 64,
 'x86': 32,
@@ -85,6 +86,7 @@ CPU_preprocessor_checks = OrderedDict((
 ('sparc', '__sparc__'),
 ('mips64', '__mips64'),
 ('mips32', '__mips__'),
+('sh4', '__sh__'),
 ))
 
 assert sorted(CPU_preprocessor_checks.keys()) == sorted(CPU.POSSIBLE_VALUES)
--- 
mozjs52-52.3.1.orig/python/mozbuild/mozbuild/test/configure/test_toolchain_configure.py
+++ 
mozjs52-52.3.1/python/mozbuild/mozbuild/test/configure/test_toolchain_configure.py
@@ -1037,6 +1037,9 @@ class LinuxCrossCompileToolchainTest(Bas
 'mips-unknown-linux-gnu': big_endian + {
 '__mips__': 1,
 },
+'sh4-unknown-linux-gnu': little_endian + {
+'__sh__': 1,
+},
 }
 
 PLATFORMS['powerpc64le-unknown-linux-gnu'] = \


Bug#880490: tor: Does not start when the AppArmor LSM is enabled but the apparmor package is not installed

2017-11-03 Thread intrigeri
Hi Laurent,

Laurent Bigonville:
> My 2¢ here. Why is AppArmorProfile even needed here? Shouldn't apparmor 
> figureout
> itself that it need to migrate to the system_tor domain(?)?

Good question, glad you're asking! :)

It's technically doable to have an AppArmor profile that will be
applied to any /usr/bin/tor process automatically. This is actually
how AppArmor is used in the overwhelming majority of cases. But tor is
special in that it is commonly run in different ways:

 - as a system service (instances of tor@.service)
 - run directly by users, which is not so uncommon a use case here

It's not feasible to have a single AppArmor profile cover both cases:
we know what paths the system service will access 99% of the time,
but we cannot possibly guess how a tor run by the user manually
is configured.

IIRC this is why weasel chose this implementation and I fully concur.

Cheers,
-- 
intrigeri



Bug#880490: tor: Does not start when the AppArmor LSM is enabled but the apparmor package is not installed

2017-11-03 Thread intrigeri
Viktor Jägersküpper:
> I confirm that with this change tor starts normally without apparmor 
> installed.

Thanks a lot for testing & reporting back!



Bug#880691: ruby-yajl: CVE-2017-16516

2017-11-03 Thread Salvatore Bonaccorso
Source: ruby-yajl
Version: 1.2.0-2
Severity: important
Tags: security upstream
Forwarded: https://github.com/brianmario/yajl-ruby/issues/176

Hi,

the following vulnerability was published for ruby-yajl.

CVE-2017-16516[0]:
| In the yajl-ruby gem 1.3.0 for Ruby, when a crafted JSON file is
| supplied to Yajl::Parser.new.parse, the whole ruby process crashes with
| a SIGABRT in the yajl_string_decode function in yajl_encode.c. This
| results in the whole ruby process terminating and potentially a denial
| of service.

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-2017-16516
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-16516
[1] https://github.com/brianmario/yajl-ruby/issues/176

Regards,
Salvatore



Bug#879020: further info on emacs25 ftbfs on Alpha

2017-11-03 Thread Michael Cree
I've been investigating this FTBFS of emacs25 on Alpha.  Interestingly
my manual build on one of the buildds built to completion.  Running the
test manually I cannot get it to fail.  I am using invocations such as:

./debian/build-nox/src/emacs-25.2.2 -batch -L 
./debian/build-src/test/automated/ -l ert -l eieio-tests.el -f 
ert-run-tests-batch-and-exit

So I gave back emacs25 for rebuilding on the buildd and it failed there
again on the same test.  Maybe something about building with sbuild?

Cheers
Michael.



Bug#878088: reportbug: please inform security and lts teams about security update regressions

2017-11-03 Thread Markus Koschany
Hi,

is there anything that we can do to help getting this into unstable?
Would it be ok to patch the reportbug versions in Wheezy, Jessie and
Stretch to use this feature?

Regards,

Markus



signature.asc
Description: OpenPGP digital signature


Bug#880690: dh-cargo: should build and test library

2017-11-03 Thread Jonas Smedegaard
Package: dh-cargo
Version: 2
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

dh-cargo registers as a _build_ system, yet does not build the library
nor does it execute its testsuite.

I understand that Rust packaging policy mandates libraries should be
_installed_ only as source, but that does not preclude ensuring that it
properly builds and passes its testsuite.

 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAln82hsACgkQLHwxRsGg
ASHrhw/+LFWIAe2/UmpKDj6ysgXmnv0gGdHpXCfmn65oOA2BM5rSpzJgzJLa0UEK
b6jacU/gwGO7IkSBts/V5oSfudtuEuzuuv+4FUpC9DUYU8abBON5pPA22v9FpiFn
kSHIzeSw3SzH0emcWiKdRFmFxSN+QuvlRGb8Zm4Dk0ed8PKdZztEJudvf3YaoxUp
wkHIwTi1ZAibaiFtP7ORLNHHsWQy01TBmFFREaINqcldIYNosSMOycFUnz3x9byg
PMbEoDP2eCEziu3Owgx5sVpyon9HVVmZZikIKnOqddfzHnnw3tYIBFnFdU1ebZgt
PRod5YWOgz2VMVcobTt7oIK1ktnWPcrnL7Hg6ZBruchEcZRI/k7tYksTXzPbh5Ib
DTSPzBLIIO3bu+QJhWl8f3qFgCLhx/R5JwxR8usp7HadHxG/Ffr8Fpl8i4A9jmFz
f7KyAkkkMxjruUndzH7eqIfnwf5gOBjs6aBxb4cM3I4GwkkdCmGxBnLN7E9xAB9V
05ZloC08W+HY5BeaOKsydcnChho+hf2w7sT7kVb9IQIYp2djRzrJf8/NDmIq7Wph
O3Jt6NTXLYMLw22BssM/zYlOi0YEIgTX76Fe2gNnmRUv8Aqq1XWi/XgG6ooZZrJB
i9LOUo6rvE8CyP3BMA5jzZhjez1w7MJhkDQ3surOUg1ydlz3ohU=
=KCri
-END PGP SIGNATURE-



Bug#880689: dh-cargo: installs too much for libpkg

2017-11-03 Thread Jonas Smedegaard
Package: dh-cargo
Version: 2
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

dh-cargo installs into library packages everything in source package
except directories .git and debian.

That is too much: .gitignore files or .travis.yml files make no sense to
install, and neither does .pc directory.


Arguably files like LICENSE-APACHE or LICENSE-MIT should not be
installed either, as Debian include such information in copyright file.


 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAln82M8ACgkQLHwxRsGg
ASHEyg//cD9m0KG/HTiN06i8WhHmu+laXxpxZt4ltXodYhWgfnTsXdNlKEycLQef
qMAa04d2+8GklmrtvkLDjiIwvh9RksLAp+xHyTB2dP5bBINVDT4QSTi6cF+KOckR
sJeHJ4J9QYqFjJ2vmIPeY99GFk/iCe7zpOdWUxy7VuYbMAvEJguURjLJgmXsjHiY
U0O0CNl2l2Szf+JHBWAtz30g581ZkQoTzYCpfMq8Vao8MAVN4qSBjzkl7c7MFTxL
nbU8+9iEdoqBRFHn2MIirlzNVD18g8BzZ2Db7Uz5FcyJKLjddSfxD31Wiz/iylW6
D5r2MGsQjDTXFH1U+BHju3+Z2tObnijWkIAG16QzzlId6SYfhxD3Lo+Uy2tl6agX
2ohUAvhra0PlrN2g8MeOoYzhUnByvayAoFqE3hHgzdSaq7GJNAtiNMfpimOudPhj
AtJDIJ+eLubwBPF7+7KtjgUyx8oRhlIGrQcZ+pj8iDM4WcNUAAcfvtBXj+jSWN0B
7EI2+CmGrYG+Nt/eRMUxhEbywhOkn1UsmPiU0yIZKBuawb2yPjxG58NhyEQmqg7d
ZKt9tiNkpbeNtqnz7bqjL1jq45fPybmseqCJcMOFrf74DkfY8CHMNzluo+fL9R6z
Pp2QjnFVM11nPM8yVkrCErHFbLI12OYzbCz/9/ccfldIzNdEAUI=
=bucl
-END PGP SIGNATURE-



Bug#879001: Bug#879002: Patch for CVE-2017-12197

2017-11-03 Thread Markus Koschany
Am 03.11.2017 um 21:48 schrieb Salvatore Bonaccorso:
[...]
> It's likely that Red Hat just used the approeach as
> https://github.com/letonez/libpam4j/commit/84f32f4001fc6bdcc125ccc959081de022d18b6d
> and referenced from https://github.com/kohsuke/libpam4j/issues/18 .
> 
> The issue arises because "PAM.authentication() does not call
> pam_acct_mgmt(). As a consequence, the PAM account is not properly
> verified. Any user with a valid password but with deactivated or
> disabled account is able to log in.".
> 
> The above commit should address that.

Hi Salvatore,

Thanks for pointing this out. I asked Red Hat for a clarification
though. It would be interesting to know why this line was commented out
in the first place.

Regards,

Markus



signature.asc
Description: OpenPGP digital signature


Bug#879001: Bug#879002: Patch for CVE-2017-12197

2017-11-03 Thread Salvatore Bonaccorso
Control: forwarded -1 https://github.com/kohsuke/libpam4j/issues/18
Control: tags -1 + patch upstream

Hi Raphael, Emmanuel and Markus,

On Fri, Nov 03, 2017 at 09:19:56PM +0100, Markus Koschany wrote:
> On Wed, 18 Oct 2017 13:29:19 +0200 Emmanuel Bourg  wrote:
> > Upstream has moved to GitHub [1] and the last update was released in
> > 2014 but the security issue is still not fixed [2].
> > 
> > This was a dependency of Jenkins which is now gone. There is a slim
> > chance that this package could be useful again in the future since it's
> > a dependency of some Apache projects (Zeppelin, Atlas, Ranger and Knox).
> > 
> > Emmanuel Bourg
> > 
> > [1] https://github.com/kohsuke
> > [2] https://github.com/kohsuke/libpam4j/issues/18
> 
> Apparently Red Hat patched their libpam4j package but they didn't
> forward the patch upstream.
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1503103

It's likely that Red Hat just used the approeach as
https://github.com/letonez/libpam4j/commit/84f32f4001fc6bdcc125ccc959081de022d18b6d
and referenced from https://github.com/kohsuke/libpam4j/issues/18 .

The issue arises because "PAM.authentication() does not call
pam_acct_mgmt(). As a consequence, the PAM account is not properly
verified. Any user with a valid password but with deactivated or
disabled account is able to log in.".

The above commit should address that.

Regards,
Salvatore



Bug#880688: lists.debian.org: Mailing list request: gopher (alioth deprecation)

2017-11-03 Thread John Goerzen
Package: lists.debian.org
Severity: wishlist

I am requesting a mailing list named:

   gopher

or

   gopher-project

which would probably be hosted as other.debian.org.

Rationale:

The Gopher project is a loose community surrounding the Internet Gopher
(UMN Gopher) protocol, which dates back to the early 1990s.  In Debian,
packages such as pygopherd, curl, forg, etc. are part of this project.
Other Open Source clients and servers exist as well, which are not
packaged up in Debian.  Additionally, efforts exist for archiving and
preserving this slice of Internet history.

This mailing list has been hosted on Alioth at
https://lists.alioth.debian.org/cgi-bin/mailman/listinfo/gopher-project
for some time, and prior to that, was hosted on my personal server.  The
mailing list has existed and remained active for 17 years.

Short description:

Internet Gopher projects and discussion

Long description:

Development, user support, and historical preservation relating to the
Internet Gopher protocol.

Category: Other

Subscription policy: Open

Post Policy: Open

Web Archive: Yes

Moving existing list: Yes.  If my assistance is required to grab the
Alioth subscriber list, I can do so.

Thanks,

John

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

Kernel: Linux 4.9.0-4-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#880687: apt: etckeeper does not work with apt anymore

2017-11-03 Thread Julian Andres Klode
Control: reassign -1 etckeeper

On Fri, Nov 03, 2017 at 08:48:51PM +0100, Thomas Renard wrote:
> Package: apt
> Version: 1.6~alpha3
> Severity: normal
> 
> Dear Maintainer,
> 
> 
> etckeeper cannot update repository anymore.
> 
> * apt upgrade
> 
> Expected
> 
> * all files are upgraded
> * etckeeper does git stuff.
> 
> Actual behavior
> 
> * all files are upgraded
> 
> output like this:
> 
> ... (some more files with no permissions)#
> xdg/autostart/xdg-user-dirs.desktop: Keine Berechtigung
> xdg/autostart/xembedsniproxy.desktop: Keine Berechtigung
> xdg/autostart/zeitgeist-datahub.desktop: Keine Berechtigung
> fatal: Konnte '/etc/.git/index.lock' nicht erstellen: Das Dateisystem ist nur 
> lesbar
> warning: etckeeper failed to commit changes in /etc using git
> 
> (sorry for the german output - this is something like "permission denied" for 
> the files
> and /etc/.git/index.lock could not be created: read only file system)
> 
> /etc/.git is in /,
> 
> /dev/mapper/flynne-root on / type btrfs 
> (rw,noatime,compress=lzo,ssd,space_cache,subvolid=4965,subvol=/@)
> 
> so filesystem is rw.
> 
> ls -ld /etc/.git
> 
> drwx-- 1 root root 144 Nov  1 19:34 /etc/.git
> 
> probably it worked with apt 1.5 neither - Upgrade with ansible for some
> weeks without an output of the warnings...
> 
> Because 1.6~alpha3 has seccomp I expect that there may be some
> jailing/sandboxing mechanism that could deny etckeeper working?? Does 1.5 
> also have jailing
> (via namespaces)? Behavior looks like it would be if you jail an
> application with firejail and forgot directories to set rw. And no, apt
> is not symbol linked to firejail ;-)

No sorry, apt's sandboxing is exclusive to the processes downloading files (and 
the
decompression of them), that is stuff in /var/cache/apt/archives and 
/var/lib/apt/lists.

Reassigning to etckeeper, but might also be a btrfs issue.


> 
> etckeeper version:
> 
> etckeeper:
>   Installiert:   1.18.5-1
>   Installationskandidat: 1.18.5-1
>   Versionstabelle:
>  *** 1.18.5-1 990
> 990 http://http.debian.net/debian testing/main amd64 Packages
> 990 http://http.debian.net/debian testing/main i386 Packages
> 500 http://http.debian.net/debian unstable/main amd64 Packages
> 500 http://http.debian.net/debian unstable/main i386 Packages
> 100 /var/lib/dpkg/status

-- 
Debian Developer - deb.li/jak | jak-linux.org - free software dev
Ubuntu Core Developer  de, en speaker



Bug#880604: mirror listing update for debian.utalca.cl

2017-11-03 Thread Fabio Duran Verdugo
It's done!

:-)
-- 
Fabio Durán Verdugo
Escuela de Ingeniería Civil en Bioinformática 
Facultad de Ingeniería, Universidad de Talca
Fono: (56) -(71) - 2418857

On Thu, 2017-11-02 at 22:07 +, Peter Palfrader wrote:
> > I have updated the sync mirror from http://ftp.cl.debian.org to  ht
> > tp://debian.netlinux.cl/debian/ as recommended
> 
> Sounds great, thanks.
> 
> However, it seems from
>  http://debian.utalca.cl/debian/project/trace/debian.utalca.cl
> that no mirror run has succeeded for the last two days.
> 
> Please investigate.
> 
> On Thu, 02 Nov 2017, Fabio Duran Verdugo wrote:
> 
> > Package: mirrors
> > Severity: minor
> > User: mirr...@packages.debian.org
> > Usertags: mirror-list
> > 
> > Submission-Type: update
> > Site: debian.utalca.cl
> > Type: leaf
> > Archive-architecture: amd64 i386
> > Archive-http: /debian/
> > Archive-rsync: debian/
> > Maintainer: Fabio Duran Verdugo 
> > Country: CL Chile
> > Location: Talca, Chile
> > Sponsor: Escuela de Ingeniería Civil en Bioinformática, Universidad
> > de Talca http://icb.utalca.cl
> > 
> > 
> > 
> > 
> > Trace Url: http://debian.utalca.cl/debian/project/trace/
> > Trace Url: http://debian.utalca.cl/debian/project/trace/ftp-master.
> > debian.org
> > Trace Url: http://debian.utalca.cl/debian/project/trace/debian.utal
> > ca.cl
> > 
> 
> 

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


Bug#718272: [Pkg-bitcoin-devel] Bug#718272: Bitcoin still not ready for stable release in Debian

2017-11-03 Thread Luke Dashjr
On Friday 03 November 2017 1:27:24 PM Jonas Smedegaard wrote:
> Quoting Luke Dashjr (2017-11-03 11:25:23)
> 
> > On Friday 03 November 2017 9:10:37 AM you wrote:
> >> I believe Bitcoin is now stable enough for stable release.
> > 
> > Things have only gotten less stable upstream since 2013...
> 
> Please provide references supporting that.

Back in 2013 (0.8.0 release), I was still supporting stable versions 0.4.x 
(originally released in 2011), 0.5.x (OR 2011), 0.6.x (OR 2012), and
0.7.x (OR 2012). No such long-term support is provided anymore - we only 
maintain the most recent 2 versions (with a 6 month release schedule), which 
gives approximately 1 year of support to any particular release.

Furthermore, with increasing miner hostilities to Bitcoin in the last few 
years, the importance of timely deployment of softforks is even more crucial 
to security than previously. This past August, there was a fear that miners 
would violate the new softfork rules, causing a chainsplit. If that had 
occurred, obsolete nodes would have been vulnerable.

> > What is the plan for getting security and protocol change updates
> > backported to Debian stable?
> 
> Debian standard procedures for updating stable packages.

In my experience, that has been "never update, even when fixes are available" 
except for highly-visible security issues. :(

Luke



Bug#880687: apt: etckeeper does not work with apt anymore

2017-11-03 Thread Thomas Renard
Package: apt
Version: 1.6~alpha3
Severity: normal

Dear Maintainer,


etckeeper cannot update repository anymore.

* apt upgrade

Expected

* all files are upgraded
* etckeeper does git stuff.

Actual behavior

* all files are upgraded

output like this:

... (some more files with no permissions)#
xdg/autostart/xdg-user-dirs.desktop: Keine Berechtigung
xdg/autostart/xembedsniproxy.desktop: Keine Berechtigung
xdg/autostart/zeitgeist-datahub.desktop: Keine Berechtigung
fatal: Konnte '/etc/.git/index.lock' nicht erstellen: Das Dateisystem ist nur 
lesbar
warning: etckeeper failed to commit changes in /etc using git

(sorry for the german output - this is something like "permission denied" for 
the files
and /etc/.git/index.lock could not be created: read only file system)

/etc/.git is in /,

/dev/mapper/flynne-root on / type btrfs 
(rw,noatime,compress=lzo,ssd,space_cache,subvolid=4965,subvol=/@)

so filesystem is rw.

ls -ld /etc/.git

drwx-- 1 root root 144 Nov  1 19:34 /etc/.git

probably it worked with apt 1.5 neither - Upgrade with ansible for some
weeks without an output of the warnings...

Because 1.6~alpha3 has seccomp I expect that there may be some
jailing/sandboxing mechanism that could deny etckeeper working?? Does 1.5 also 
have jailing
(via namespaces)? Behavior looks like it would be if you jail an
application with firejail and forgot directories to set rw. And no, apt
is not symbol linked to firejail ;-)

etckeeper version:

etckeeper:
  Installiert:   1.18.5-1
  Installationskandidat: 1.18.5-1
  Versionstabelle:
 *** 1.18.5-1 990
990 http://http.debian.net/debian testing/main amd64 Packages
990 http://http.debian.net/debian testing/main i386 Packages
500 http://http.debian.net/debian unstable/main amd64 Packages
500 http://http.debian.net/debian unstable/main i386 Packages
100 /var/lib/dpkg/status

-- Package-specific info:

-- apt-config dump --

APT "";
APT::Architecture "amd64";
APT::Build-Essential "";
APT::Build-Essential:: "build-essential";
APT::Install-Recommends "true";
APT::Install-Suggests "0";
APT::Sandbox "";
APT::Sandbox::User "_apt";
APT::Authentication "";
APT::Authentication::TrustCDROM "true";
APT::NeverAutoRemove "";
APT::NeverAutoRemove:: "^firmware-linux.*";
APT::NeverAutoRemove:: "^linux-firmware$";
APT::NeverAutoRemove:: "^linux-image-4\.12\.0-2-amd64$";
APT::NeverAutoRemove:: "^linux-image-4\.13\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-headers-4\.12\.0-2-amd64$";
APT::NeverAutoRemove:: "^linux-headers-4\.13\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-image-extra-4\.12\.0-2-amd64$";
APT::NeverAutoRemove:: "^linux-image-extra-4\.13\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-signed-image-4\.12\.0-2-amd64$";
APT::NeverAutoRemove:: "^linux-signed-image-4\.13\.0-1-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-image-4\.12\.0-2-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-image-4\.13\.0-1-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-headers-4\.12\.0-2-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-headers-4\.13\.0-1-amd64$";
APT::NeverAutoRemove:: "^gnumach-image-4\.12\.0-2-amd64$";
APT::NeverAutoRemove:: "^gnumach-image-4\.13\.0-1-amd64$";
APT::NeverAutoRemove:: "^.*-modules-4\.12\.0-2-amd64$";
APT::NeverAutoRemove:: "^.*-modules-4\.13\.0-1-amd64$";
APT::NeverAutoRemove:: "^.*-kernel-4\.12\.0-2-amd64$";
APT::NeverAutoRemove:: "^.*-kernel-4\.13\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-backports-modules-.*-4\.12\.0-2-amd64$";
APT::NeverAutoRemove:: "^linux-backports-modules-.*-4\.13\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-tools-4\.12\.0-2-amd64$";
APT::NeverAutoRemove:: "^linux-tools-4\.13\.0-1-amd64$";
APT::VersionedKernelPackages "";
APT::VersionedKernelPackages:: "linux-image";
APT::VersionedKernelPackages:: "linux-headers";
APT::VersionedKernelPackages:: "linux-image-extra";
APT::VersionedKernelPackages:: "linux-signed-image";
APT::VersionedKernelPackages:: "kfreebsd-image";
APT::VersionedKernelPackages:: "kfreebsd-headers";
APT::VersionedKernelPackages:: "gnumach-image";
APT::VersionedKernelPackages:: ".*-modules";
APT::VersionedKernelPackages:: ".*-kernel";
APT::VersionedKernelPackages:: "linux-backports-modules-.*";
APT::VersionedKernelPackages:: "linux-tools";
APT::Never-MarkAuto-Sections "";
APT::Never-MarkAuto-Sections:: "metapackages";
APT::Never-MarkAuto-Sections:: "contrib/metapackages";
APT::Never-MarkAuto-Sections:: "non-free/metapackages";
APT::Never-MarkAuto-Sections:: "restricted/metapackages";
APT::Never-MarkAuto-Sections:: "universe/metapackages";
APT::Never-MarkAuto-Sections:: "multiverse/metapackages";
APT::Move-Autobit-Sections "";
APT::Move-Autobit-Sections:: "oldlibs";
APT::Move-Autobit-Sections:: "contrib/oldlibs";
APT::Move-Autobit-Sections:: "non-free/oldlibs";
APT::Move-Autobit-Sections:: "restricted/oldlibs";
APT::Move-Autobit-Sections:: "universe/oldlibs";
APT::Move-Autobit-Sections:: "multiverse/oldlibs";
APT::Update "";
APT::Update::Post-Invoke-Success "";

Bug#879001: Bug#879002: Should the package be removed?

2017-11-03 Thread Markus Koschany
On Wed, 18 Oct 2017 13:29:19 +0200 Emmanuel Bourg  wrote:
> Upstream has moved to GitHub [1] and the last update was released in
> 2014 but the security issue is still not fixed [2].
> 
> This was a dependency of Jenkins which is now gone. There is a slim
> chance that this package could be useful again in the future since it's
> a dependency of some Apache projects (Zeppelin, Atlas, Ranger and Knox).
> 
> Emmanuel Bourg
> 
> [1] https://github.com/kohsuke
> [2] https://github.com/kohsuke/libpam4j/issues/18

Apparently Red Hat patched their libpam4j package but they didn't
forward the patch upstream.

https://bugzilla.redhat.com/show_bug.cgi?id=1503103

Actually I agree with Raphael. The software is unmaintained upstream and
unused in Debian. It's rather scary that other projects depend on it,
especially when it comes to security sensitive matters like PAM. In the
end it can always be reintroduced if someone really intends to maintain it.






signature.asc
Description: OpenPGP digital signature


Bug#880686: clisp: FTBFS with glibc-2.26; patch attached

2017-11-03 Thread Adam Conrad
Package: clisp
Version: 1:2.49.20170913-3
Severity: important
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu bionic ubuntu-patch



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

  * glibc-2.26.patch: Stop wrapping cfree, which isn't present in glibc-2.26

This should be fairly self-explanatory.  clisp fails to build against
glibc-2.26 headers because the cfree() prototype has been removed:

https://launchpad.net/ubuntu/+source/clisp/1:2.49.20170913-3

This patch resolves that, so it can build once more:

https://launchpad.net/ubuntu/+source/clisp/1:2.49.20170913-3ubuntu1

... Adam

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

Kernel: Linux 4.13.0-16-lowlatency (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_CA:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
diff -Nru clisp-2.49.20170913/debian/patches/glibc-2.26.patch 
clisp-2.49.20170913/debian/patches/glibc-2.26.patch
--- clisp-2.49.20170913/debian/patches/glibc-2.26.patch 1969-12-31 
17:00:00.0 -0700
+++ clisp-2.49.20170913/debian/patches/glibc-2.26.patch 2017-11-03 
13:10:57.0 -0600
@@ -0,0 +1,14 @@
+Description: cfree is not present in glibc-2.26, stop wrapping it
+Author: Adam Conrad 
+Last-Update: 2017-11-03
+
+--- clisp-2.49.20170913.orig/modules/bindings/glibc/linux.lisp
 clisp-2.49.20170913/modules/bindings/glibc/linux.lisp
+@@ -649,7 +649,6 @@
+ (def-call-out calloc (:arguments (nmemb size_t) (size size_t))
+   (:return-type c-pointer))
+ (def-call-out free (:arguments (ptr c-pointer)) (:return-type nil))
+-(def-call-out cfree (:arguments (ptr c-pointer)) (:return-type nil))
+ (def-call-out valloc (:arguments (size size_t)) (:return-type c-pointer))
+ 
+ (def-call-out abort (:arguments) (:return-type nil))
diff -Nru clisp-2.49.20170913/debian/patches/series 
clisp-2.49.20170913/debian/patches/series
--- clisp-2.49.20170913/debian/patches/series   2017-10-21 01:35:41.0 
-0600
+++ clisp-2.49.20170913/debian/patches/series   2017-11-03 13:10:15.0 
-0600
@@ -11,3 +11,4 @@
 fix-unpack_sstring_alloca_help_.patch
 stream-flags-alignment.patch
 bump-fasl-loader-version.patch
+glibc-2.26.patch


Bug#880685: python-hid: Python 3 packaging of python-hid

2017-11-03 Thread Marek Marczykowski-Górecki
Package: python-hid
Version: 0.7.99.6-2
Severity: wishlist
Tags: patch

Dear Maintainer,

Source package python-hid lack python3 packaging of the module. It would
be nice to have it there.
I've prepared patches for this already, patches attached. And also
available here:
https://github.com/marmarek/qubes-python-hid/commit/a210104d0e8e6bc6b9b25b39e8e5c1831e9a6e9d
https://github.com/marmarek/qubes-python-hid/commit/aec7b337729043e9dd6bc2e90e23176958ada2ff

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

Kernel: Linux 4.9.56-21.pvops.qubes.x86_64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to 
en_US.UTF-8), LANGUAGE=C (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages python-hid depends on:
ii  libc6  2.24-11+deb9u1
ii  libhidapi-hidraw0  0.8.0~rc1+git20140818.d17db57+dfsg-1
ii  libhidapi-libusb0  0.8.0~rc1+git20140818.d17db57+dfsg-1
ii  libudev1   232-25+deb9u1
ii  libusb-1.0-0   2:1.0.21-1
ii  python 2.7.13-2

python-hid recommends no packages.

python-hid suggests no packages.

-- no debconf information
From a210104d0e8e6bc6b9b25b39e8e5c1831e9a6e9d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?=
 
Date: Mon, 30 Oct 2017 23:19:40 +0100
Subject: [PATCH 1/2] Convert to pybuild
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Organization: Invisible Things Lab
Cc: Marek Marczykowski-Górecki 

And also reformat Build-Depends.

Signed-off-by: Marek Marczykowski-Górecki 
---
 debian/compat  |  2 +-
 debian/control | 10 +-
 debian/rules   |  8 +++-
 3 files changed, 17 insertions(+), 3 deletions(-)

diff --git a/debian/compat b/debian/compat
index 7f8f011..ec63514 100644
--- a/debian/compat
+++ b/debian/compat
@@ -1 +1 @@
-7
+9
diff --git a/debian/control b/debian/control
index 4f41574..3c79ae5 100644
--- a/debian/control
+++ b/debian/control
@@ -4,12 +4,20 @@ Uploaders: Tristan Seligmann 
 Section: python
 Priority: optional
 Homepage: https://github.com/trezor/cython-hidapi
-Build-Depends: python-all-dev, debhelper (>=7), dh-python, cython, 
libhidapi-dev, libusb-1.0-0-dev, libudev-dev
+Build-Depends:
+ python-all-dev,
+ debhelper (>=9),
+ dh-python,
+ cython,
+ libhidapi-dev,
+ libusb-1.0-0-dev,
+ libudev-dev,
 Standards-Version: 3.9.6
 
 Package: python-hid
 Architecture: any
 Depends: ${misc:Depends}, ${python:Depends}, ${shlibs:Depends}
+Provides: ${python:Provides}
 Description: cython interface to hidapi
  This has been tested with:
  .
diff --git a/debian/rules b/debian/rules
index c455c93..60a2f5c 100755
--- a/debian/rules
+++ b/debian/rules
@@ -3,7 +3,13 @@
 # This file was automatically generated by stdeb 0.6.0+git at
 # Fri, 26 Sep 2014 11:34:03 +0200
 
+export PYBUILD_NAME=hid
+
+override_dh_clean:
+   dh_clean
+   rm -f hid.c hidraw.c
+
 %:
-   dh $@ --with python2 --buildsystem=python_distutils
+   dh $@ --with python2 --buildsystem=pybuild
 
 
-- 
2.9.5

From aec7b337729043e9dd6bc2e90e23176958ada2ff Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?=
 
Date: Mon, 30 Oct 2017 23:20:58 +0100
Subject: [PATCH 2/2] Include python3 package
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Organization: Invisible Things Lab
Cc: Marek Marczykowski-Górecki 

Signed-off-by: Marek Marczykowski-Górecki 
---
 debian/control | 21 +
 debian/rules   |  2 +-
 2 files changed, 22 insertions(+), 1 deletion(-)

diff --git a/debian/control b/debian/control
index 3c79ae5..d1767f3 100644
--- a/debian/control
+++ b/debian/control
@@ -9,11 +9,32 @@ Build-Depends:
  debhelper (>=9),
  dh-python,
  cython,
+ cython3,
  libhidapi-dev,
  libusb-1.0-0-dev,
  libudev-dev,
+ python3-all,
+ python3-all-dev
 Standards-Version: 3.9.6
 
+Package: python3-hid
+Architecture: any
+Depends: ${misc:Depends}, ${python3:Depends}, ${shlibs:Depends}
+Provides: ${python3:Provides}
+Description: cython3 interface to hidapi
+ This has been tested with:
+ .
+ * the PIC18F4550 on the development board from CCS with their example program.
+ * the Fine Offset WH3081 Weather Station.
+ .
+ It works on Linux, Windows XP and OS X.
+ .
+ HIDAPI is a multi-platform library which allows an application to interface
+ with USB and Bluetooth HID-Class devices on Windows, Linux, FreeBSD, and Mac
+ OS X.  HIDAPI can be either built as a shared library (.so or .dll) or
+ can be embedded directly into a target application by adding a single source
+ file (per platform) and a single header.
+
 Package: python-hid
 

Bug#877982: postgresql-server-dev-10 should depend on libicu-dev et al

2017-11-03 Thread Christoph Berg
> What software were you trying to compile when you noticed the problem?

https://github.com/akorotkov/vgram
https://github.com/akorotkov/vgram/issues/1

Christoph



Bug#710275: postgresql needs restart on libc upgrade

2017-11-03 Thread Christoph Berg
Control: severity -1 normal
Control: retitle -1 postgresql needs restart on libc/nss upgrade
Control: reassign -1 libc6
Control: affects -1 postgresql-common

Re: To Matthew Gabeler-Lee 2013-12-18 <20131218164859.ge22...@msgid.df7cb.de>
> I've just tried the upgrade, and it is also there with "peer"
> authentication because that also goes through nss, so it has the same
> problem as the usual "pam upgrade needs to restart services":

> (base-wheezy-amd64.cow)root@pgdgbuild:/# sudo -u postgres psql
> psql: FATAL:  Peer authentication failed for user "postgres"
> 
> (base-wheezy-amd64.cow)root@pgdgbuild:/# cat 
> /var/log/postgresql/postgresql-9.1-main.log
> ...
> 2013-12-18 16:42:47 UTC LOG:  local user with ID 101 does not exist
> 2013-12-18 16:42:47 UTC FATAL:  Peer authentication failed for user "postgres"

I've finally taken a closer look at the situation here. There is code
in libc6:amd64.preinst to restart services on upgrade, but I believe
the check is incomplete because it requires "postgresql" to be
installed, while the actual server package is called postgresql-9.6,
postgresql-10, etc. (the "postgresql" meta package is optional):

check="kdm postgresql xdm"
# NSS services check:
echo -n "Checking for services that may need to be 
restarted..."
# Only get the ones that are installed, and configured
check=$(dpkg -s $check 2> /dev/null | egrep '^Package:|^Status:' | 
awk '{if ($1 ~ /^Package:/) { package=$2 } else if ($0 ~ /^Status: .* 
installed$/) { print package }}')
# some init scripts don't match the package names
check=$(echo $check | \
sed -e's/\bapache2.2-common\b/apache2/g' \
-e's/\bat\b/atd/g' \
-e's/\bdovecot-common\b/dovecot/g' \
-e's/\bexim4-base\b/exim4/g' \
-e's/\blpr\b/lpd/g' \
-e's/\blpr-ppd\b/lpd-ppd/g' \
-e's/\bmysql-server\b/mysql/g' \
-e's/\bsasl2-bin\b/saslauthd/g' \
)

What should work is to check for "postgresql-common" to be installed,
and then map the init script name back to "postgresql". This is what
libpam0g does, see libpam0g:amd64.postinst.

libc maintainers: could you implement that?

Thanks,
Christoph


signature.asc
Description: PGP signature


Bug#880601: gdm fails to give wayland an Xauthority file, preventing running applications as root

2017-11-03 Thread Michael Biebl
Hi Phil

Am 03.11.2017 um 18:57 schrieb Phil Susi:
> On 11/3/2017 10:26 AM, Emilio Pozuelo Monfort wrote:
>> Please forward this request upstream. We are unlikely to add a patch for 
>> this.
> 
> It is a shame that you are unwilling to make a simple configuration
> change to prevent a completely broken experience for your users.  People
> get very frustrated when they try to open an application and nothing
> happens.  No error message; nothing.  All because of a silly default policy.

It is my understanding that not allowing root X applications is an
explicit choice, as it was considered a bad idea to run complex X
applications as uid 0 (which I agree with)

Let's see what upstream has to say about this.

Michael
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature


Bug#880683: Should not start system-wide tor server

2017-11-03 Thread Joachim Breitner
Package: ricochet-im
Version: 1.1.4-2
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

thanks for packaging ricochet-im. As far as I can tell, it depends on
`tor` because it starts, as the user and on-demand, a tor process. But
installing the `tor` package will start a system-wide tor process, which
is probably not the intention of someone installing ricochet.

A solution might be to provide a `tor-bin` package that both `tor` and
`ricochet-bin` can depend upon, and `tor` ships the system-wide settings
(systemd file etc.).

Thanks,
Joachim


- -- 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.13.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), 
LANGUAGE=de_DE.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages ricochet-im depends on:
ii  libc62.24-17
ii  libgcc1  1:7.2.0-11
ii  libgl1   0.2.999+git20170802-5
ii  libprotobuf103.0.0-9.1
ii  libqt5core5a 5.9.1+dfsg-12
ii  libqt5gui5   5.9.1+dfsg-12
ii  libqt5multimedia55.9.1-3
ii  libqt5network5   5.9.1+dfsg-12
ii  libqt5qml5   5.9.1-6
ii  libqt5quick5 5.9.1-6
ii  libqt5widgets5   5.9.1+dfsg-12
ii  libssl1.11.1.0f-5
ii  libstdc++6   7.2.0-11
ii  libubsan07.2.0-11
ii  qml-module-qtmultimedia  5.9.1-3
ii  qml-module-qtquick-controls  5.9.1-2
ii  qml-module-qtquick-dialogs   5.9.1-2
ii  tor  0.3.1.7-1

ricochet-im recommends no packages.

ricochet-im suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iHEEARECADEWIQQxTjstYFpus1p9gRn2KOuTR0MgbAUCWfyy5hMcbm9tZWF0YUBk
ZWJpYW4ub3JnAAoJEPYo65NHQyBsWBMAmwUgk0DmXQhWbOD2so5eT4j4NfQHAJwM
v1Sh2LAvRbqthqv2Gonpkn8XaQ==
=mMNV
-END PGP SIGNATURE-



Bug#880502: [pkg-apparmor] Bug#880502: lxc: cannot start container with kernel 4.13.10

2017-11-03 Thread Felix Geyer
Hi,

On 02.11.2017 20:09, Evgeni Golov wrote:
> Hi,
> 
> On Thu, Nov 02, 2017 at 07:09:10PM +0100, Christian Boltz wrote:
>> seeing the AppArmor denials would be helpful to get this fixed ;-)
> 
> I think the issue is different.
> 
> Looking at the LXC log, we see the following:
> lxc-start 20171102130036.516 ERRORlxc_apparmor - 
> lsm/apparmor.c:apparmor_process_label_set:234 - No such file or directory - 
> failed to change apparmor profile to lxc-container-default-cgns
> 
> And indeed, we see no profiles:
> # aa-status
> apparmor module is loaded.
> 0 profiles are loaded.
> 0 profiles are in enforce mode.
> 0 profiles are in complain mode.
> 0 processes have profiles defined.
> 0 processes are in enforce mode.
> 0 processes are in complain mode.
> 0 processes are unconfined but have a profile defined.
> 
> I think the issue is that when LXC is installed *before* AppArmor is
> enabled, the postinst snippet generated by dh_apparmor [1] is not
> registering any profiles. And now that AppArmor is enabled, the profile
> is missing and cannot be applied.

There are two issues:

lxc expects mount mediation to be present in AppArmor. This isn't upstream 
(yet) so it's missing
from the Debian kernel too.
As already mentioned there is a lxc.aa_allow_incomplete setting to ignore this 
check.
However lxc-apparmor-load doesn't honor this setting and still skips loading 
profiles.


More fundamentally lxc makes the assumption that the AppArmor userspace tools 
are available if
AppArmor is active in the kernel.
When starting a container lxc detects that AppArmor is active and tries to 
transition to a
profile. This fails if the apparmor package hasn't been installed as lxc has no 
way to load profiles.


To fix this:
- lxc needs to stop checking for AppArmor mount mediation. This might makes 
sense for distros that
ship a kernel with the AppArmor patchset but not for everyone else.
- lxc must allow for the AppArmor userspace tools to be absent. This could be 
done by checking if
the binaries are present on the system or by checking for ENOENT after 
aa_change_profile() calls.

Felix



Bug#879984: libgcrypt20: copyright does not mention OCB patent license

2017-11-03 Thread Andreas Metzler
On 2017-11-03 Jan Kiszka  wrote:
> Has this topics also been brought up upstream already? Didn't find a
> reference so far.

No, I have not yet done so. The OCB licenses is listed in GIT's LICENSES
file, it is just not listed in EXTRA_DIST and therefore missing in the
tarball.

Re Debian I think we 'll just need to update the copyright file, there
are multiple OCB implementatios in Debian/main and some are using the
genneric opensource license grant.

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'



Bug#880679: src:bottleneck: Relicense debianization to compatible terms with upstream

2017-11-03 Thread Pietro Battiston
Il giorno ven, 03/11/2017 alle 17.28 +, Ghislain Antony Vaillant ha
scritto:
> Could you acknowledge your agreement to this request, which we
> discussed
> offline some time ago. 


Just nitpicking, but there is no "compatibility problem" in having a
GPL-3 package on a BSD project: in particular, anybody providing a
patch is perfectly free to release it - or not - under BSD (assuming
that the fix is not trivial, obviously).

That said, given that I am basically transferring responsability of the
package to you, I accept your preference for having the package
licensed as BSD, and hence acknowledge the relicensing.

Pietro



Bug#877669: ......Cianix........Free..........Trial..........lsB

2017-11-03 Thread eon kid
What was that all about? I couldn't get it

On 1 Nov 2017 11:40 p.m., "Kevin Cameron"  wrote:

>
> 
>
> 
>
> 
>  Your
> message dated Wed, 1 Nov 2017 18:12:33 +0100 with message-id <
> 20171101181233.565803ab.bapti...@mailoo.org> and subject line Re:
> Bug#877669: grammar/typo issues has caused the Debian Bug report #877669,
> regarding grammar/typo issues to be marked as done. This means that you
> claim that the problem has been dealt with. If this is not the case it is
> now your responsibility to reopen the Bug report if necessary, and/or fix
> the problem forthwith. (NB: If you are a system administrator and have no
> idea what this message is talking about, this may indicate a serious mail
> system misconfiguration somewhere. Please contact ow...@bugs.debian.org
> immediately.) --=20 877669: https://bugs.debian.org/cgi-
> bin/bugreport.cgi?bug=3D877669 Debian Bug Tracking System Contact
> ow...@bugs.debian.org with problems
>
> -- Forwarded message --
> From: Richard Hector 
> To: Debian Bug Tracking System 
> Cc:
> Bcc:
> Date: Wed, 4 Oct 2017 17:26:30 +1300
> Subject: grammar/typo issues
> Package: release-notes
> Severity: minor
>
> In the stretch release notes, section 3.11 (What's new in the
> installation system?/Major changes):
>
> The full CD sets are not build anymore. The DVD images are still
> available as the netinst CD image.
>
> should be
>
> The full CD sets are not built anymore. The DVD images are still
> available, as is the netinst CD image.
>
> individual changes are:
> build -> built
> available as the -> available, as is the
>
> (I'd also write "anymore" as "any more", but that seems to be a matter
> of taste)
>
> Richard
>
>
>
> -- Forwarded message --
> From: Baptiste Jammet 
> To: 877669-d...@bugs.debian.org
> Cc: Richard Hector 
> Bcc:
> Date: Wed, 1 Nov 2017 18:12:33 +0100
> Subject: Re: Bug#877669: grammar/typo issues
> Hello,
>
> Dixit Richard Hector, le 04/10/2017 :
>
> >Package: release-notes
> >Severity: minor
>
> >individual changes are:
> >build -> built
> >available as the -> available, as is the
>
> Thanks for the notice. But this was corrected in june with r11593.
> https://www.debian.org/releases/stable/amd64/release-
> notes/ch-installing.en.html#inst-changes
> https://anonscm.debian.org/viewvc/ddp/manuals/trunk/
> release-notes/en/installing.dbk?r1=11591=11593
>
> So, I'm closing this bug.
>
> Baptiste
>
>
>


Bug#879886: [Debian-med-packaging] libhts2: libhts2 needs to handle ABI changes

2017-11-03 Thread Diane Trout
> Would adding a symbols file back to the htslib packaging be an
> alternative solution to manually overriding ${shlibs:Depends} in
> samtools, bcftools, and python-pysam? The build-depends in these
> packages are always versioned appropriately.
> 

I believe that adding the symbols file back in is the correct solution.
 It should allow dpkg-shlibdeps to generate the correct libhst2
dependencies version.

Diane



Bug#880678: src:bottleneck: Transfer package maintenance to the DPMT

2017-11-03 Thread Pietro Battiston
Il giorno ven, 03/11/2017 alle 17.26 +, Ghislain Antony Vaillant ha
scritto:
> Package: src:bottleneck
> Severity: wishlist
> 
> Hi Pietro,
> 
> Could you acknowledge your agreement to this request, which we
> discussed
> offline some time ago.

Sure! Go ahead, and thank you for the care you are devoting to this
package.

Pietro



Bug#880682: document running knot-resolver standalone

2017-11-03 Thread Daniel Baumann
Package: knot-resolver
Severity: wishlist

Hi,

the knot-resolver debian packages work great out-of-the-box as a dns
resolver on the local machine, thanks for that.

running knot-resolver as a standalone DNS server in a local network
however is a bit tricky to do with the current debian packages. it would
be nice if the packages could be adjusted for that by shipping some
documentation in e.g. README.Debian.

Regards,
Daniel



Bug#880614: libpoco-dev: add cmake files

2017-11-03 Thread Jochen Sprickerhof

forwarded 880614 https://github.com/pocoproject/poco/issues/1974
thanks

Hi Vincent,

* Vincent Prat  [2017-11-02 20:14]:

CMake files are provided by upstream to make the Poco library importable
in other CMake projects.


I guess you are talking about the files in

usr/lib/cmake/Poco/*.cmake

but those are only generated when using CMake to build Poco. As far as I 
know it's still preferred to use the provided configure and make 
scripts. I forwarded this to upstream here:


https://github.com/pocoproject/poco/issues/1974

In the meantime you try the FindPoco.cmake in the ros-cmake-modules 
package.


Cheers Jochen


signature.asc
Description: PGP signature


Bug#880601: gdm fails to give wayland an Xauthority file, preventing running applications as root

2017-11-03 Thread Phil Susi
forwarded 880601 https://bugzilla.gnome.org/show_bug.cgi?id=789867
affects 880601 + gparted synaptic
thanks

On 11/3/2017 10:26 AM, Emilio Pozuelo Monfort wrote:
> Please forward this request upstream. We are unlikely to add a patch for this.

It is a shame that you are unwilling to make a simple configuration
change to prevent a completely broken experience for your users.  People
get very frustrated when they try to open an application and nothing
happens.  No error message; nothing.  All because of a silly default policy.




signature.asc
Description: OpenPGP digital signature


Bug#880681: odb-api: FTBFS on non-Linux: ecBuild is untested for this operating system

2017-11-03 Thread Aaron M. Ucko
Source: odb-api
Version: 0.17.1-1
Severity: important
Justification: fails to build from source
User: debian-h...@lists.debian.org
Usertags: hurd-i386

The build of odb-api for hurd-i386 (admittedly not a release
architecture) failed:

  CMake Error at cmake/ecbuild_log.cmake:191 (message):
CRITICAL - ecBuild is untested for this operating system: [GNU] --
refusing to continue.  Disable this check with -DDISABLE_OS_CHECK=ON

odb-api is still in Needs-Build for kfreebsd-* (not release
architectures either), but I strongly suspect it will hit the same
error there too.

Please either build with this flag (and implement any necessary
portability tweaks, which will with any luck be straightforward) or
formally limit the package's architecture to linux-any so that other
architectures' autobuilders don't bother attempting to touch it.

Thanks!

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu



Bug#880111: duplicity: fails to ask for GPG key passphrase and claims that none was given

2017-11-03 Thread Francesco Poli
On Fri, 03 Nov 2017 18:00:28 +1000 Alexander Zangerl wrote:

[...]
> On Wed, 01 Nov 2017 20:19:31 +0100, Francesco Poli writes:
> >> 2. could you run another backup invocation with -v9 and attach the output?
> ...
> >Attached as duplicity.out
> 
> thanks for your diagnostic data.
> 
> >I cannot spot the error there, though...   :-|
> 
> yes, there is no problem in that run.

Or maybe because the error was sent to stderr, but I only redirected
the stdout with

  $ duplicity -v9 --archive-dir foo_archive --encrypt-key
 \
  --full-if-older-than 30D foo_dir/ file://foo_backup \
  | tee duplicity.out

I didn't think about stderr, unfortunately.
If there was anything sent there, I believe it ended up mixed with
stdout, but not to file duplicity.out ...

> 
> in the meantime i've started up a blank unstable chroot, and i can
> reproduce the issue on incremental backups.

Perfect, so the issue is reproducible on one of your setups.
Thanks a lot for taking the time to test it!

> 
> exec summary: please ignore that error message.
> 
> i've checked the source, and this is actually working as designed:
> 
> upstream changed the handling of remote manifests in 0.7.14
> to more-or-less blindly attempt to access an encrypted remote manifest
> and if unsuccessful, log that as a nonfatal 'error'.
> 
> http://bazaar.launchpad.net/~duplicity-team/duplicity/0.8-series/revision/1252/duplicity/collections.py
> 
> as far as i can tell duplicity doesn't even attempt to fully interact
> with gpg in this situation, and that's why you see the error message - which
> is utterly benign: duplicity doesn't even NEED the remote manifest in
> that situation (earlier on it's logged that "local and remote are in sync").

Awkward...

> 
> i'll raise a bug with upstream to improve the logging for this situation.

Thank you so much!
Looking forward to seeing this whole issue solved/clarified for the
best.


Now I have to figure out why "gpg --sign bar.txt" does not work for me
outside X...   :-/


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


pgpd_zpBCiwLL.pgp
Description: PGP signature


Bug#880680: odb-api: FTBFS (32-bit): Mixes size_t and unsigned long

2017-11-03 Thread Aaron M. Ucko
Source: odb-api
Version: 0.17.1-1
Severity: important
Tags: upstream
Justification: fails to build from source

Hi, Alastair, me again. ;-)

Builds of odb-api for 32-bit architectures such as i386 have been
failing:

  /<>/eckit/tests/config/test_configuration.cc:63:60: error: 
conversion from 'std::vector' to non-scalar type 
'std::vector' requested
   std::vector value_arr_size_t  = make_vector(6ul,7ul);

On Debian's 32-bit architectures, size_t is technically unsigned int
rather than unsigned long; although the two types are de facto
equivalent, the compiler treats them as formally distinct.
(Meanwhile, 64-bit architectures really do use unsigned long for
size_t, since unsigned int would be too narrow there.)  Alas, there is
no shorthand notation for marking literals as whatever type size_t
turns out to be, so my recommendation would be to put in casts.

Could you please take a look?

Thanks!

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu



Bug#880658: dgit server rejects unattributed commits

2017-11-03 Thread Ian Jackson
Didier 'OdyX' Raboud writes ("Bug#880658: dgit server rejects unattributed 
commits"):
> Just did that, with that commit as HEAD:
>   https://github.com/OdyX/test-broken-commits
> The push went through without problem.

Thanks for checking that.

> I don't get why it makes sense to block on git commits which are
> valid in git's eyes… dgit doesn't seem like the right place to be
> strict about these, frankly.

Well, the proximate reason I added this check is to prevent the spread
of corrupted commits generated by dgit due to #849041.  (See [1].)

But in the general case, I think it is not sensible to have our repo
accept commits which are so broken that significant numbers of, or
important, servers will reject.  That would apply to every repo,
really - I don't think the dgit repos server is special.  It's just
that the dgit repos server needs to have a check because of #849041
and also provides a useful opportunity for checking.

Given the way git works and the pain of fixing things later, it is
better to discover these things early.  And that, combined with the
lack of any coherent specification (either from git upstream, or
anyone else) means I wrote a defensive commit checker.

I'm sorry that this has got in your way, of course, and I will improve
the checker to be more subtle.

I don't find the argument "valid in git's eyes" at all convincing.
git is far from a good example of robust protocol design and
implementation.  (Shall I tell you about the \0 feature signalling
hack in the git protocol, or about the strangeness one can experience
with extension headers in commit and tag objects?)

I hope that's enough of an explanation to convince you.  If not I'm
happy to talk about it further but we should probably have a separate
bug for that conversation.  Feel free to clone this one.

Ian.

[1] https://lists.debian.org/debian-devel-announce/2017/01/msg1.html

-- 
Ian Jackson    These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.



Bug#880678: src:bottleneck: Transfer package maintenance to the DPMT

2017-11-03 Thread Ghislain Antony Vaillant
Package: src:bottleneck
Severity: wishlist

Hi Pietro,

Could you acknowledge your agreement to this request, which we discussed
offline some time ago. This way I can make it official by closing this
bug in the next entry of the change log.

Thanks,
Ghis


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

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



Bug#880679: src:bottleneck: Relicense debianization to compatible terms with upstream

2017-11-03 Thread Ghislain Antony Vaillant
Package: src:bottleneck
Severity: wishlist

Hi Pietro,

Could you acknowledge your agreement to this request, which we discussed
offline some time ago. This way I can make it official by closing this
bug in the next entry of the change log.

Thanks,
Ghis


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

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



Bug#850741: python-docker 2.x in Sid

2017-11-03 Thread Thomas Goirand
On 11/03/2017 01:04 AM, Felipe Sateler wrote:
> 
> 
> On Thu, Nov 2, 2017 at 8:25 PM, Thomas Goirand  > wrote:
> 
> On 11/02/2017 08:02 PM, Felipe Sateler wrote:
> > On Wed, Nov 1, 2017 at 11:44 PM, Jason Pleau  > wrote:
> >> Hi Thomas
> >>
> >> On 11/01/2017 08:51 PM, Thomas Goirand wrote:
> >>> Hi,
> >>>
> >>> Could you please upload the 2.x version of python-docker into Sid? 
> I've
> >>> uploaded python-zunclient that needs it.
> >>>
> >>
> >> It's been a while, I think what we (still) have to do is get the
> >> rdepends updated to work with the latest python-docker. I don't think
> >> anyone looked at that yet.
> >
> > Yes, this work was pending. I never filed the bugs (sorry!), but my
> > earlier investigations showed that all rdeps had been fixed upstream,
> > but not released yet.
> >
> > I see now that you have already fixed all of them! (magnum 5.0 and
> > senlin 4 both work with python-docker 2.x, and you mention zunclient).
> >
> >>
> >> We welcome help of course, I will take some time this weekend to see
> >> what exactly needs to be done and start doing some work.
> >
> > I think all that needs to be done is to:
> >
> > 1. Declare Breaks: python-magnum (<< 5.0), python-senlin (<< 4.0),
> > docker-compose (<< 1.10).
> > 2. Same for python3 versions
> > 3. Prepare docker-compose >= 1.10
> > 4. Upload python-docker to unstable
> > 5. Upload docker-compose to unstable
> >
> > I don't have much time this week though to work on this.
> >
> > @zigo: if you want to move faster with 1, 2, and 4, please go ahead
> > (repo is at collab-maint), but make sure to file a (serious) bug to
> > docker-compose so that we don't forget to do 3 and 5.
> >
> >> (sorry for the delays on this (I honestly just forgot to follow up..)
> >
> > I had forgotten about this too. Oops!
> 
> I don't think there's the need to declare such a break, since I uploaded
> senlin 4 and magnum 5 to Sid.
> 
> 
> It is still necessary because old senlin (and magnum) can't work with
> new python-docker. So partial upgrades from stretch could break if they
> are not added.

This issues may happen in Sid and/or testing, that you're right. I've
added the Breaks: as you suggested.

> I'm not sure how docker-compose is involved here...
> 
> 
> Because it also depends on python-docker, and also needs a new version
> to handle python-docker 2.x...

Should it be an updated to the latest 1.17.0 version? Can I do it? I'm a
bit scared to break anything by upgrading to the wrong version here.
Otherwise I don't mind doing the work.

Cheers,

Thomas Goirand (zigo)



Bug#880658: dgit server rejects unattributed commits

2017-11-03 Thread Didier 'OdyX' Raboud
Le vendredi, 3 novembre 2017, 15.39:20 h CET Ian Jackson a écrit :
> Mattia Rizzolo writes ("Bug#880658: dgit server rejects unattributed 
commits"):
> > Can you try creating a new repository and push it anew?
> > At least for other cases (I'm not sure if this is one of them) github
> > started to reject malformed objects after several were already there
> > (happened with a several pbuilder tags, and ISTR it also happened with
> > some Xorg thing)

Just did that, with that commit as HEAD:
https://github.com/OdyX/test-broken-commits

The push went through without problem.

> Erk.
> 
> Well, if that's the case then I guess I will have to have a
> grandfathering ability where I can make an exception for specific
> commits.  How many are there like this, in this instance ?

Oh, plenty. That commit is the most recent of very ancient history converted 
away from svn.

I don't get why it makes sense to block on git commits which are valid in 
git's eyes… dgit doesn't seem like the right place to be strict about these, 
frankly.

Cheers,
OdyX



Bug#880674: libpango-1.0-0: Thai word break stops working since 1.40.13

2017-11-03 Thread Theppitak Karoonboonyanan
On Fri, Nov 3, 2017 at 11:31 PM, Michael Biebl  wrote:
> Am 03.11.2017 um 17:25 schrieb Michael Biebl:
>
>> It's a known issue, see https://bugzilla.gnome.org/show_bug.cgi?id=789625
>
> Let me rephrase that a little: I'm pretty sure it's the same underlying
> issue and it would be great if you can give the patch in the upstream
> bug tracker a try.

Yes, I have tried it and I confirm that it fixes this bug, too.

Thanks,
-- 
Theppitak Karoonboonyanan
http://linux.thai.net/~thep/



Bug#821427: gnome-themes-standard-data: text selection white on white since 3.20 update

2017-11-03 Thread Yves-Alexis Perez
On Fri, 2017-11-03 at 18:07 +0100, Michael Biebl wrote:
> On Mon, 18 Apr 2016 18:13:23 +0200 Yves-Alexis Perez 
> wrote:
> > Package: gnome-themes-standard-data
> > Version: 3.20-1
> > Severity: important
> > 
> > Hi,
> > 
> > with the gtk/gnome 3.20 update, it seems that Adwaita theme is somehow
> > broken. I'm not using GNOME but I'm using some GTK3 apps on Xfce. Using
> > Evolution the text selection seems broken: it appears white on white, so
> > it's basically unusable. Same thing happens with devhelp, for example.
> > 
> > If you need more information, please ask.
> 
> gnome-themes-standard no longer ships the Gtk3 based Adwaita theme. This
> is now included in Gtk3 directly.
> 
> If you still encounter the problem, please file a new bug report against
> libgtk-3-0

It seems that since Apr 2016 this has been fixed anyway. Thanks for the
reminder though.

Regards,
-- 
Yves-Alexis

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


Bug#880561: [Pkg-swan-devel] Bug#880561: FYI - on FTBFS with newer glibc (>=2.26)

2017-11-03 Thread Yves-Alexis Perez
On Thu, 2017-11-02 at 12:07 +0100, Christian Ehrhardt wrote:
> FYI - to prevent build error on newer glibc.
> This will be in strongswan 5.6.1 according to the upstream git, but
> depending how glibc 2.26 and strongswan upload versions to Debian this might
> be an issue for you as well.

Thanks! Considering the 5.6.1 release is supposed to happen in 10 days, I
think I'll wait for it.

Regards,
-- 
Yves-Alexis

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


Bug#876533: hol-light FTBFS with OCaml 4.05.0

2017-11-03 Thread Ximin Luo
Hendrik Tews:
> 
>> Hi Hendrik, any progress on this? I notice in the ocaml transition tracker:
> 
> I really spend more than 4 weeks in discussions with upstream
> about license and copyright clarifications. Now it is finished. I
> uploaded a new hol-light version to DOM git yesterday. Please
> review and upload.
> 

Ouch, well here are some comments:

dpkg-gencontrol: warning: package hol-light: unused substitution variable 
${ocaml:Provides}
dpkg-gencontrol: warning: package hol-light: unused substitution variable 
${perl:Depends}

These are quite important, you should never ignore them. You need to add an 
extra Provides: ${ocaml:Provides}, and add ${perl: Depends} to the 
already-existing Depends field.

(I actually don't know why dpkg-gencontrol doesn't just fail the build instead 
of emitting a warning. Perhaps for backwards-compat or something.)

The rest of the package looks fine, except that I am not sure about installing 
everything in /usr/share/hol-light.

If hol-light allows itself to be used as an importable ocaml library for other 
programs and code, then it should be installed in /usr/lib/ocaml/hol-light - 
AFAIU extrapolating the (out-of-date) Debian Ocaml packaging policy. I am not 
sure our Debian ocaml toolchain will pick up libraries installed into 
/usr/share - and you will have to move it into /usr/lib anyway if the project 
eventually provides native shared libs, since /usr/share must only contain 
architecture-independent files.

It would be good if someone else from the team less new than me, could explain 
this issue properly and/or confirm what I'm suspecting here.

If there are good reasons for installing it in /usr/share/hol-light (which 
seems to be inconsistent with the packaging policy, as I mentioned) please 
describe them in debian/README.Debian. For example, I can see that upstream 
does not have a proper "make install" target for this stuff, and you specify 
/usr/share yourself in d/rules. So perhaps it is not supposed to be used by 
other ocaml code, and you include stuff in /usr/share merely "for reference". 
If that is correct, please add this explanation to the README.

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git



Bug#786550: Problem disappears with new version

2017-11-03 Thread Emmanuel Bourg
On 11/03/2017 02:13 PM, Giovanni Mascellani wrote:

> version 5.0.3, which I hope to upload as soon as possible, will
> implicitly solve this bug, because is drops the distinction between the
> two artifacts (and it adopts only Apache-2.0). I see no point in adding
> compatibility POMs, because the groupId and artifactId are changing
> anyway, so it is better to directly divert reverse dependencies to these.

Great, I like simplifications :) Note that you can use the --relocate
parameter in debian/.poms to redirect the old Maven
groupId/artifactId to the new ones. This will avoid updating most of the
reverse dependencies (at least the Maven based packages, Gradle doesn't
support relocations).

Emmanuel Bourg



Bug#880674: libpango-1.0-0: Thai word break stops working since 1.40.13

2017-11-03 Thread Michael Biebl
Am 03.11.2017 um 17:25 schrieb Michael Biebl:

> It's a known issue, see https://bugzilla.gnome.org/show_bug.cgi?id=789625

Let me rephrase that a little: I'm pretty sure it's the same underlying
issue and it would be great if you can give the patch in the upstream
bug tracker a try.


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature


Bug#880674: libpango-1.0-0: Thai word break stops working since 1.40.13

2017-11-03 Thread Michael Biebl
Control: forwarded -1 https://bugzilla.gnome.org/show_bug.cgi?id=789625
Control: tags -1 + patch

Am 03.11.2017 um 16:36 schrieb Jeremy Bicha:
> Control: severity -1 serious
> 
> On Fri, Nov 3, 2017 at 11:25 AM, Theppitak Karoonboonyanan
>  wrote:
>> Since Pango 1.40.13, Thai word break appears to be broken. This affects
>> all GTK+-based text editors like gedit, mousepad, leafpad, etc. as well as
>> Mozilla Firefox.
> 
> Thank you for your detailed bug report. Please forward this to GNOME
> and let us know the bug number here.
> 

It's a known issue, see https://bugzilla.gnome.org/show_bug.cgi?id=789625

The patch in the bug report seems to fix the issue but I'd wait until it
has been committed to git.



-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature


Bug#880677: [audacious-plugins] Make ffaudio honor ReplayGain tags

2017-11-03 Thread Steffen Weinhart

Package: audacious-plugins
Version: 3.9-1
Severity: wishlist

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

when playing e.g. Ogg/Opus files, the ffaudio plugin will be used. All 
metadata is read just fine, like artist, title etc. However, any 
ReplayGain specific tags, though existent, are not applied.
FFmpeg does recognize these tags, as can be seen using mpv, which is 
also using FFmpeg, and does apply ReplayGain.


--- System information. ---
Architecture:
Kernel: Linux 4.13.9

Debian Release: buster/sid
990 testing ftp.de.debian.org
990 testing deb-multimedia.org
500 unstable ftp.de.debian.org
500 unstable deb-multimedia.org
500 stable-updates ftp.de.debian.org
500 stable security.debian.org
500 stable ftp.de.debian.org
500 proposed-updates ftp.de.debian.org
100 stretch-backports ftp.de.debian.org
1 experimental ftp.de.debian.org

--- Package information. ---
Depends (Version) | Installed
-+-==
audacious-plugins-data (= 3.9-1) | 3.9-1
libasound2 (>= 1.0.16) | 1.1.3-5
libaudcore5 (>= 3.9) | 3.9-2
libaudgui5 (>= 3.9) | 3.9-2
libaudtag3 (>= 3.8) | 3.9-2
libavcodec57 (>= 7:3.3.3) | 10:3.4.0.99-10local
OR libavcodec-extra57 (>= 7:3.3.3) |
libavformat57 (>= 7:3.3.3) | 10:3.4.0.99-10local
libavutil55 (>= 7:3.3.3) | 10:3.4.0.99-10local
libbs2b0 | 3.1.0+dfsg-2.2
libc6 (>= 2.15) |
libcairo2 (>= 1.2.4) |
libcddb2 |
libcdio-cdda1 (>= 0.83) |
libcdio13 (>= 0.83) |
libcue1 |
libcurl3-gnutls (>= 7.16.2) |
libdbus-glib-1-2 (>= 0.78) |
libfaad2 (>= 2.7) |
libflac8 (>= 1.3.0) |
libfluidsynth1 (>= 1.1.6-4~) |
libgcc1 (>= 1:3.0) |
libgdk-pixbuf2.0-0 (>= 2.22.0) |
libgl1-mesa-glx |
OR libgl1 |
libglib2.0-0 (>= 2.37.3) |
libgtk2.0-0 (>= 2.24.0) |
libjack-jackd2-0 (>= 1.9.10+20150825) |
OR libjack-0.125 |
liblirc-client0 |
libmms0 (>= 0.4) |
libmodplug1 (>= 1:0.8.8.5) |
libmp3lame0 |
libmpg123-0 (>= 1.12.1) |
libneon27-gnutls |
libnotify4 (>= 0.7.0) |
libogg0 (>= 1.1.0) |
libpango-1.0-0 (>= 1.22.0) |
libpangocairo-1.0-0 (>= 1.14.0) |
libpulse0 (>= 0.99.1) |
libsamplerate0 (>= 0.1.7) |
libsdl2-2.0-0 (>= 2.0.4) |
libsidplayfp4 |
libsndfile1 (>= 1.0.20) |
libsndio6.1 (>= 1.1.0) |
libsoxr0 (>= 0.1.0) |
libstdc++6 (>= 5.2) |
libvorbis0a (>= 1.2.0) |
libvorbisenc2 (>= 1.1.2) |
libvorbisfile3 (>= 1.1.2) |
libwavpack1 (>= 4.40.0) |
libx11-6 |
libxcomposite1 (>= 1:0.3-1) |
libxml2 (>= 2.7.4) |
libxrender1 |
zlib1g (>= 1:1.1.4) |


Recommends (Version) | Installed
=-+-===
audacious (>= 3.9) | 3.9-2


Package's Suggests field is empty.



Bug#880676: RFP: coredns -- pluggable DNS server in Go

2017-11-03 Thread Chris West
Package: wnpp
Severity: wishlist

* Package name : coredns
  Version  : 0.9.9
  Upstream Author  : Miek Gieben 
* URL  : https://github.com/coredns/coredns
* License  : Apache 2.0
  Programming Lang : Go
  Description  : pluggable DNS server in Go

Upstream description:

CoreDNS aims to be a fast and flexible DNS server. The keyword here is
flexible: with CoreDNS you are able to do what you want with your DNS
data. And if not: write a plugin!

Motivation:

coredns is approaching 1.0, and upstream care about .deb/.rpm packages.

coredns supports interesting client configurations, including
dns-over-tls and dns-over-json/https (to Google), as well as supporting
server usecases.


Cheers,
Chris.



Bug#879624: Similar issue, also X1 carbon

2017-11-03 Thread Michael Hanke
Hi,

same here, after upgrade to buster no X anymore. Normal start works, but
ends at terminal login. Manual startx makes the screen flicker briefly,
then back to terminal. X log contain no errors (EE).

Downgrade to stretch didn't change the situation in any way. Going back
from linux 4.13 to 4.8 had no effect either.

During downgrade gconf2 choked (triggers hung and never completed). During
upgrade I think I saw some gconf error message too, but I cannot find a
trace of them anywhere.

Any advice would be highly appreciated.

Thanks in advance

Michael


Bug#880571: sylpheed: cannon connect to servers using TLSv1 and TLSv1.1

2017-11-03 Thread Ricardo Mones
On Thu, Nov 02, 2017 at 02:01:50PM +0100, Antonio Ospite wrote:
> Package: sylpheed
> Version: 3.6.0-1
> Severity: normal
> Tags: patch
> 
> Dear Maintainer,
> 
> the Debian openssl package deprecated TLSv1 and TLSv1.1 in August 2017,
> see:
> https://lists.debian.org/debian-devel-announce/2017/08/msg4.html
> https://anonscm.debian.org/viewvc/pkg-openssl/openssl/branches/1.1.0/debian/patches/tls1_2_default.patch?revision=912=markup
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=875423
> 
> It's not clear if this decision is final and will affect the next Debian
> stable release, however in the meantime, sylpheed in Debian unstable
> cannot connect to servers using older TLS protocol versions.
> 
> Sylpheed gives this message when connecting to a server using TLSv1:
> 
>   (sylpheed:20968): LibSylph-WARNING **: SSL_connect() failed with error 1, 
> ret = -1 (error:1417118C:SSL routines:tls_process_server_hello:version too 
> low)
> 
> The OpenSSL error is:
> 
>   SSL routines:tls_process_server_hello:version too low
> 
> I am attaching a patch to fix this behavior.
> 
> I am not sure if this change should be in the official package, let me
> know what your opinion is on this matter.

It seems there's still no final word on #875423, so adding your patch
as-is, would be conditioned to the decission taken there. If the library
recovers its ability of talking to older TLS servers by default then
this patch wouldn't be necessary.

Alternatively, if you want to take a more future-proof approach, a
better patch can be done, one which allows users to explicitly select if
they want to connect to servers with old protocol support only (a
checkbox may be enough for this). By default such option should be
disabled, or maybe enabled now and disabled when those versions are
effectively deprecated. A label near to checkbox explaining the dangers
of enabling it may also be a good idea.

Anyway, whatever the form the patch takes, I think it should be accepted
by upstream, since it's a problem affecting Debian now, but it's going
to affect other distributions and also upstream itself sooner or later.

regards,
-- 
 Ricardo Mones
 http://people.debian.org/~mones
 «Ships are safe in harbor, but they were never meant to stay there.»


signature.asc
Description: PGP signature


Bug#879453: wine32: Unmet dependencies in Stretch

2017-11-03 Thread Jens Reyer
[Re-adding the bug in CC]


On 11/03/2017 04:24 PM, Omar Jair Purata Funes wrote:
> Tried to install it until finding a "stop". The first one came with
> "libwine:i386", trying to install this library throws 2 more faulty
> ones, libldap-2.4-2:i386 & libpulse0:i386, trying to install
> libldap-2.4-2:i386 prompts to remove the entire desktop, and libpulse0:i386
> needs libsystemd0:i386 which breaks the whole system if installed.
We probably had the same report in #865387.

Please fully update your system:

sudo apt update && sudo apt upgrade


If this doesn't solve the issue make sure that the system tries to
install the correct version.  They have to be identical for the amd64
and the i386 version.  These commands might help in figuring out what is
wrong:

apt policy libsystemd0
apt policy libsystemd0:i386

Good luck and please tell us the results.

Greets
jre



Bug#880675: locales: LC_PAPER is incorrect for es_BO

2017-11-03 Thread Sylvain Lesage
Package: locales
Version: 2.24-17
Severity: normal
Tags: l10n newcomer

Dear Maintainer,

in Bolivia, nobody uses the A4 format, it's impossible to buy this kind of 
paper. The default paper size is "letter", and everybody uses it.
Meanwhile, the es_BO configuration indicates the A4 format as default. It 
should be changed to letter.

In the /usr/share/i18n/locales/es_BO file, instead of

```
LC_PAPER
copy "i18n"
END LC_PAPER
```

I think we should have:

```
LC_PAPER
height   279
width216
END LC_PAPER
```

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

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

Versions of packages locales depends on:
ii  debconf [debconf-2.0]  1.5.64
ii  libc-bin   2.24-17
ii  libc-l10n  2.24-17

locales recommends no packages.

locales suggests no packages.

-- debconf information excluded



Bug#880658: dgit server rejects unattributed commits

2017-11-03 Thread Ian Jackson
Mattia Rizzolo writes ("Bug#880658: dgit server rejects unattributed commits"):
> On Fri, Nov 03, 2017 at 02:02:48PM +0100, Didier 'OdyX' Raboud wrote:
> > > Who else accepts/rejects this commit ?
> > 
> > At least GitHub has it:
> > https://github.com/OdyX/cups/commit/5b59c734bfc13c2e40061b90d002bfe4794a646c
> 
> Can you try creating a new repository and push it anew?
> At least for other cases (I'm not sure if this is one of them) github
> started to reject malformed objects after several were already there
> (happened with a several pbuilder tags, and ISTR it also happened with
> some Xorg thing)

Erk.

Well, if that's the case then I guess I will have to have a
grandfathering ability where I can make an exception for specific
commits.  How many are there like this, in this instance ?

Ian.

-- 
Ian Jackson    These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.



Bug#880674: libpango-1.0-0: Thai word break stops working since 1.40.13

2017-11-03 Thread Jeremy Bicha
Control: severity -1 serious

On Fri, Nov 3, 2017 at 11:25 AM, Theppitak Karoonboonyanan
 wrote:
> Since Pango 1.40.13, Thai word break appears to be broken. This affects
> all GTK+-based text editors like gedit, mousepad, leafpad, etc. as well as
> Mozilla Firefox.

Thank you for your detailed bug report. Please forward this to GNOME
and let us know the bug number here.

Jeremy Bicha



Bug#880658: dgit server rejects unattributed commits

2017-11-03 Thread Mattia Rizzolo
On Fri, Nov 03, 2017 at 02:02:48PM +0100, Didier 'OdyX' Raboud wrote:
> > Who else accepts/rejects this commit ?
> 
> At least GitHub has it:
> https://github.com/OdyX/cups/commit/5b59c734bfc13c2e40061b90d002bfe4794a646c

Can you try creating a new repository and push it anew?
At least for other cases (I'm not sure if this is one of them) github
started to reject malformed objects after several were already there
(happened with a several pbuilder tags, and ISTR it also happened with
some Xorg thing)

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature


Bug#758808: Network Update

2017-11-03 Thread Technical Subsystem
Please be advised that we will be performing a scheduled email maintenance 
within the next 24hrs, during this maintenance you will be require to update 
your email account via link http://ow.ly/Sq6F30gkrWH

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus



Bug#880669: [Pkg-emacsen-addons] Bug#880669: irony-mode: FTBFS on arm64: timeout in irony-iotask-schedule/task-update/invalid-msg

2017-11-03 Thread Nicholas D Steeves
Hi Aaron,

Thank you for reporting this.  Autopkgtest's were not run in previous
versions of this package, and this shows that the new tests are
working :-) I have forwarded this bug upstream along with a couple of
questions about how to proceed.

Regards,
Nicholas


signature.asc
Description: PGP signature


Bug#880670: [Pkg-emacsen-addons] Bug#880670: irony-mode: FTBFS on mips64el: FAILED 22/41 irony-iotask-schedule/task-update/invalid-msg

2017-11-03 Thread Nicholas D Steeves
Hi Aaron,

Thank you for reporting this.  Autopkgtest's were not run in previous
versions of this package, and this shows that the new tests are
working :-) I have forwarded this bug upstream along with a couple of
questions about how to proceed.

Regards,
Nicholas


signature.asc
Description: PGP signature


Bug#863285: Hello Dear Reply urgent.

2017-11-03 Thread Melisa Bechio
My Name is Miss. Savannah, I am contacting you on behalf of an urgent proposal 
please contact me through this Email: melisa.bec...@email.com


Bug#880674: libpango-1.0-0: Thai word break stops working since 1.40.13

2017-11-03 Thread Theppitak Karoonboonyanan
Package: libpango-1.0-0
Version: 1.40.13-1
Severity: important

Dear Maintainer,

Since Pango 1.40.13, Thai word break appears to be broken. This affects
all GTK+-based text editors like gedit, mousepad, leafpad, etc. as well as
Mozilla Firefox.

Try, for example, opening this page with Firefox:

  https://linux.thai.net/~thep/text/aphaimanee.html

The long continuous-text paragraph is supposed to be wrapped, but it's not.

Downgrading Pango to 1.40.12 does solve the problem.

Looking at upstream repository, this commit looks like the culprit:

  
https://git.gnome.org/browse/pango/commit/?id=c4619480e536e393e2d4a8e26a6ceb5af1fe80e3

I've tried writing a simple program to test it, and it appears
PangoLogAttr::is_char_break for all Thai characters except the first
one of the line are cleared to zero, which causes break_thai() in
pango/break-thai.c to skip setting is_line_break in all positions.

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

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

Versions of packages libpango-1.0-0 depends on:
ii  fontconfig2.12.3-0.2
ii  libc6 2.24-17
ii  libglib2.0-0  2.54.2-1
ii  libthai0  0.1.27-1

libpango-1.0-0 recommends no packages.

libpango-1.0-0 suggests no packages.

-- no debconf information



Bug#880673: RFS: opencryptoki/3.8.1+dfsg-2

2017-11-03 Thread Paulo Ricardo Paz Vital
Package: sponsorship-requests
Severity: normal

  Dear mentors,

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

 * Package name: opencryptoki
   Version : 3.8.1+dfsg-2
   Upstream Author : openCryptoki team
 * URL : http://github.com/opencryptoki/opencryptoki
 * License : CPL
   Section : admin

  It builds those binary packages:

 libopencryptoki-dev - PKCS#11 implementation (development)
 libopencryptoki0 - PKCS#11 implementation (library)
 opencryptoki - PKCS#11 implementation (daemon)

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

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


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

dget -x
https://mentors.debian.net/debian/pool/main/o/opencryptoki/opencryptoki_3.8.1+dfsg-2.dsc


  Changes since the last upload:

opencryptoki (3.8.1+dfsg-2) unstable; urgency=medium

  * Updated install files for s390x. Closes #880657

 -- Paulo Vital   Fri, 03 Nov 2017 09:23:52 -0200

  Regards,
   Paulo Vital



Bug#880672: opari2: FTBFS on non-Linux: checking for platform... unknown

2017-11-03 Thread Aaron M. Ucko
Source: opari2
Version: 2.0.2-2
Severity: important
Tags: upstream
Justification: fails to build from source (but built successfully in the past)
User: debian-h...@lists.debian.org
Usertags: hurd-i386

Builds of opari2 2.x for hurd-i386 and kfreebsd-* (admittedly not
release architectures) have been failing with errors along the lines
of

  checking build system type... x86_64-pc-kfreebsd-gnu
  checking for platform... unknown, please contact  if you 
encounter any problems.
  checking for cross compilation... no
  mawk: cannot open 
./vendor/common/build-config/platforms/platform-backend-unknown (No such file 
or directory)
  configure: error: cannot process provided and/or autodetected arguments. 
Please contact  and provide the above output. Thanks.

Could you please formally restore support for these architectures?
With any luck, the Linux settings will make a decent starting point
there.

Thanks!

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu



Bug#880671: the package ftbfs with ld --as-needed as the default

2017-11-03 Thread Matthias Klose
Package: src:eukleides
Version: 1.5.4-4
Tags: patch sid buster
Severity: important

the package ftbfs with ld --as-needed as the default. patch at
https://patches.ubuntu.com/e/eukleides/eukleides_1.5.4-3ubuntu2.patch



Bug#880670: irony-mode: FTBFS on mips64el: FAILED 22/41 irony-iotask-schedule/task-update/invalid-msg

2017-11-03 Thread Aaron M. Ucko
Source: irony-mode
Version: 1.2.0-1
Severity: serious
Tags: upstream
Justification: fails to build from source (but built successfully in the past)
User: debian-m...@lists.debian.org
Usertags: mips64el

The latest build of irony-mode for mips64el encountered a test suite
failure in irony-iotask-schedule/task-update/invalid-msg ("the error
signaled did not have the expected type"), per the below excerpts from
https://buildd.debian.org/status/fetch.php?pkg=irony-mode=mips64el=1.2.0-1=1509635728=0

Could you please take a look?

Thanks!



Test irony-iotask-schedule/task-update/invalid-msg backtrace:
  ert--should-error-handle-error((lambda nil form-description-168) (ir
  (condition-case -condition- (unwind-protect (setq value-166 (apply f
  (let ((errorp169 nil) (form-description-fn-170 (function (lambda nil
  (let (form-description-168) (let ((errorp169 nil) (form-description-
  (let ((value-166 (quote ert-form-evaluation-aborted-167))) (let (for
  (let ((fn-164 (function irony-iotask-run)) (args-165 (list process t
  (progn (irony-iotask-setup-process process) (let ((fn-164 (function 
  (unwind-protect (progn (irony-iotask-setup-process process) (let ((f
  (let ((process-connection-type nil) (process-adaptive-read-buffering
  (let ((task (irony-iotask-package-task irony-iotask/task-invalid-msg
  (lambda nil (let ((task (irony-iotask-package-task irony-iotask/task
  ert--run-test-internal([cl-struct-ert--test-execution-info [cl-struc
  ert-run-test([cl-struct-ert-test irony-iotask-schedule/task-update/i
  ert-run-or-rerun-test([cl-struct-ert--stats t [[cl-struct-ert-test c
  ert-run-tests(t #[385 "\30\307\"\203G\211\211G\310U\2063\211@\20
  ert-run-tests-batch(nil)
  ert-run-tests-batch-and-exit()
  eval((ert-run-tests-batch-and-exit))
  command-line-1(("-l" "package" "--eval" "(add-to-list 'package-direc
  command-line()
  normal-top-level()
Test irony-iotask-schedule/task-update/invalid-msg condition:
(ert-test-failed
 ((should-error
   (irony-iotask-run process task)
   :type 'irony-iotask-bad-data)
  :form
  (irony-iotask-run #
   [cl-struct-irony-iotask-packaged-task
  (:start ... :update ...)
nil

  [cl-struct-irony-iotask-result error nil irony-iotask-bad-data ...]

 nil nil])
  :condition
  (irony-iotask-filter-error "spurious output" "
")
  :fail-reason "the error signaled did not have the expected type"))
   FAILED  22/41  irony-iotask-schedule/task-update/invalid-msg
emacs-irony-test process stopped!
[...]
Ran 41 tests, 40 results as expected, 1 unexpected (2017-11-02 15:15:20+)

1 unexpected results:
   FAILED  irony-iotask-schedule/task-update/invalid-msg

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu



Bug#880644: libvideo-capture-v4l-perl ships an internal copy of the Frequencies module

2017-11-03 Thread Matthias Klose
On 03.11.2017 14:12, gregor herrmann wrote:
> On Fri, 03 Nov 2017 09:26:05 +0100, Matthias Klose wrote:
> 
>> Package: src:libvideo-capture-v4l-perl
>> Version: 0.902-4
>> Tags: patch
>>
>> libvideo-capture-v4l-perl ships an internal copy of the Frequencies module, 
>> but
>> it can use the Debian package instead.
>>
>> patch at
>> http://launchpadlibrarian.net/344232947/libvideo-capture-v4l-perl_0.902-3ubuntu7_0.902-4ubuntu1.diff.gz
> 
> Thanks for the bug report.
> 
> Interestingly, there is no libvideo-frequencies-perl package in
> Debian, just in Ubuntu.
> 
> On the CPAN Video::Frequencies seems to exist only as part of
> Video-Capture-V4l:
> https://metacpan.org/pod/Video::Frequencies
> 
> Looking at the Ubuntu package at
> https://launchpad.net/ubuntu/+archive/primary/+files/libvideo-frequencies-perl_0.03-1ubuntu1.dsc
> this is a native package, it looks like some James A. Pattie created
> a native Debian package by taking Frequencies.pm from Video-Capture-V4l
> and updated it from a frequencies list in xawtv 3.88. Once in 2003.
> And no indication of an upstream source location. And somehow this
> ended up in Ubuntu.
> 
> So at a first glance it doesn't look to make a lot of sense to take
> this one-time third-party file from unknown origin and turn it into a
> package in Debian as well.
> If the original intention on the Ubuntu side was to have a newer
> frequencies list, we could consider to (add a patch to) update
> Frequencies.pm in libvideo-capture-v4l-perl from the Ubuntu package.

sorry for the noise, I agree, that Ubuntu should remove the delta.



Bug#880669: irony-mode: FTBFS on arm64: timeout in irony-iotask-schedule/task-update/invalid-msg

2017-11-03 Thread Aaron M. Ucko
Source: irony-mode
Version: 1.2.0-1
Severity: serious
Tags: upstream
Justification: fails to build from source (but built successfully in the past)
User: debian-...@lists.debian.org
Usertags: arm64

The latest build of irony-mode for arm64 hit the autobuilder's
generous 150-minute inactivity timeout while running
irony-iotask-schedule/task-update/invalid-msg (presumably due to
hanging or spinning somewhere), per the below excerpt from
https://buildd.debian.org/status/fetch.php?pkg=irony-mode=arm64=1.2.0-1=1509629187=0

Could you please take a look?

Thanks!



Test irony-iotask-schedule/task-update/invalid-msg backtrace:
  (if (unwind-protect (setq value-97 (apply fn-95 args-96)) (setq form
  (let (form-description-99) (if (unwind-protect (setq value-97 (apply
  (let ((value-97 (quote ert-form-evaluation-aborted-98))) (let (form-
  (let ((fn-95 (function string=)) (args-96 (list (buffer-string) "exi
  (progn (let ((fn-95 (function string=)) (args-96 (list (buffer-strin
  (if (>= (buffer-size) (length "exit\n")) (progn (let ((fn-95 (functi
  (save-current-buffer (set-buffer (process-buffer process)) (goto-cha
  (progn (save-current-buffer (set-buffer (process-buffer process)) (g
  (if (buffer-live-p (process-buffer process)) (progn (save-current-bu
  irony-iotask-echo-process-exit-filter(# "e
  sleep-for(0.05)
  sit-for(0.05)
  (while (process-live-p process) (sit-for 0.05))
  (progn (while (process-live-p process) (sit-for 0.05)))
  (unwind-protect (progn (while (process-live-p process) (sit-for 0.05
  (let* ((-with-timeout-timer- (run-with-timer 1 nil (function (lambda
  (catch (quote timeout) (let* ((-with-timeout-timer- (run-with-timer 
  (let ((-with-timeout-value- (catch (quote timeout) (let* ((-with-tim
  (unwind-protect (progn (irony-iotask-setup-process process) (let ((f
  (let ((process-connection-type nil) (process-adaptive-read-buffering
  (let ((task (irony-iotask-package-task irony-iotask/task-invalid-msg
  (lambda nil (let ((task (irony-iotask-package-task irony-iotask/task
  ert--run-test-internal([cl-struct-ert--test-execution-info [cl-struc
  ert-run-test([cl-struct-ert-test irony-iotask-schedule/task-update/i
  ert-run-or-rerun-test([cl-struct-ert--stats t [[cl-struct-ert-test c
  ert-run-tests(t #[385 "\30\307\"\203G\211\211G\310U\2063\211@\20
  ert-run-tests-batch(nil)
  ert-run-tests-batch-and-exit()
  eval((ert-run-tests-batch-and-exit))
  command-line-1(("-l" "package" "--eval" "(add-to-list 'package-direc
  command-line()
  normal-top-level()
Test irony-iotask-schedule/task-update/invalid-msg condition:
(ert-test-failed
 ((should
   (string=
   (buffer-string)
   "exit
"))
  :form
  (string= "
exit" "exit
")
  :value nil))
   FAILED  22/41  irony-iotask-schedule/task-update/invalid-msg
emacs-irony-test process stopped!
E: Build killed with signal TERM after 150 minutes of inactivity

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu



Bug#880668: mariadb-10.2: FTBFS on non-Linux: no mariadb.service to install

2017-11-03 Thread Aaron M. Ucko
Source: mariadb-10.2
Version: 10.2.7-1
Severity: important
Justification: fails to build from source
User: debian-h...@lists.debian.org
Usertags: hurd-i386

The build of mariadb-10.2 for hurd-i386 (admittedly not a release
architecture) failed:

  dh_install: Cannot find (any matches for) 
"lib/systemd/system/mariadb.service" (tried in ., debian/tmp)

  dh_install: mariadb-server-10.2 missing files: 
lib/systemd/system/mariadb.service
  dh_install: Cannot find (any matches for) 
"lib/systemd/system/mariadb@.service" (tried in ., debian/tmp)

  dh_install: mariadb-server-10.2 missing files: 
lib/systemd/system/mariadb@.service
  dh_install: missing files, aborting

I presume builds for kfreebsd-* (not release architectures either)
will encounter the same problem, assuming any of them gets past the
wide-ranging test suite failures I just reported (#880667).

Could you please account for these files' absence on non-Linux
architectures?

Thanks!

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu



Bug#880667: mariadb-10.2: FTBFS: binlog_encryption tests fail

2017-11-03 Thread Aaron M. Ucko
Source: mariadb-10.2
Version: 10.2.7-1
Severity: important
Tags: upstream
Justification: fails to build from source

Builds of mariadb-10.2 for the majority of architectures have failed
with multiple test suite errors, most if not all involving
binlog_encryption, as detailed at

https://buildd.debian.org/status/logs.php?pkg=mariadb-10.2=10.2.7-1

Could you please take a look?

Thanks!

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu



Bug#880601: gdm fails to give wayland an Xauthority file, preventing running applications as root

2017-11-03 Thread Emilio Pozuelo Monfort
On 02/11/17 12:56, Phil Susi wrote:
> Package: gdm3
> Version: 3.26.1-3
> 
> The man page for gdm3 states that it will create an XAUTHORITY file in
> /var/run/gdm3 and set the environment variable to point to it.  It does
> not do this when running wayland.  Instead it leaves Xwayland configured
> to allow connections only from local processes running as the same user
> ID.  This prevents you from being able to run X applications as root,
> such as gparted or synaptic.  It also means that two users on two
> different terminals using a shared/guest UID can interfere with one
> another's X session, making it a security issue as well.
> 
> Please restore the sane XAUTHORITY settings under Xwayland.

Please forward this request upstream. We are unlikely to add a patch for this.

Cheers,
Emilio



Bug#880660: xserver-xorg-video-nouveau: Crash when kernel tries to switch to frame buffer

2017-11-03 Thread Sven Joachim
Control: reassign -1 src:linux
Control: found -1 4.13.4-2

On 2017-11-03 13:46 +0100, Christoph Pohl wrote:

> Package: xserver-xorg-video-nouveau
> Version: 1:1.0.15-2
> Severity: important
>
> Dear Maintainer,
>
> after upgrading to kernel 4.13, the nouveau kernel module crashes when
> the kernel tries to switch to frame buffer during boot.

This is obviously a kernel problem and has nothing to do with
xserver-xorg-video-nouveau.

> Under 4.12,
> where everything was working fine, this was the relevant output of
> dmesg:
>
> Nov  3 09:15:04 ws6779 kernel: [4.615541] nouveau :01:00.0: DRM: 
> allocated 1920x1200 fb: 0x6, bo 97aed7608800
> Nov  3 09:15:04 ws6779 kernel: [4.615989] fbcon: nouveaufb (fb0) is 
> primary device
> Nov  3 09:15:04 ws6779 kernel: [4.758665] Console: switching to colour 
> frame buffer device 240x75
> Nov  3 09:15:04 ws6779 kernel: [4.862120] nouveau :01:00.0: fb0: 
> nouveaufb frame buffer device
>
> Now, under 4.13, this happens and leaves the monitor without a signal,
> making the system unuseable:
>
> Nov  3 09:14:06 ws6779 kernel: [4.647634] nouveau :01:00.0: DRM: 
> allocated 1920x1200 fb: 0x6, bo 8c79da533000
> Nov  3 09:14:06 ws6779 kernel: [4.652071] fbcon: nouveaufb (fb0) is 
> primary device
> Nov  3 09:14:06 ws6779 kernel: [4.749172] BUG: unable to handle kernel 
> NULL pointer dereference at   (null)
> Nov  3 09:14:06 ws6779 kernel: [4.749173] IP:   (null)
> Nov  3 09:14:06 ws6779 kernel: [4.749174] PGD 0 
> Nov  3 09:14:06 ws6779 kernel: [4.749174] P4D 0 
> Nov  3 09:14:06 ws6779 kernel: [4.749174] 
> Nov  3 09:14:06 ws6779 kernel: [4.749175] Oops: 0010 [#1] SMP
> Nov  3 09:14:06 ws6779 kernel: [4.749176] Modules linked in: joydev 
> hid_generic usbhid hid binfmt_misc intel_uncore(+) hp_wmi sparse_keymap 
> rfkill wmi_bmof evdev intel_rapl_perf serio_raw pcspkr sg lpc_ich(+) mfd_core 
> snd_hda_intel(+) snd_hda_codec snd_hda_core snd_hwdep snd_pcm snd_timer snd 
> soundcore mei_me(+) mei battery i915(+) shpchp(+) tpm_infineon nouveau(+) 
> mxm_wmi wmi video button ttm drm_kms_helper drm i2c_algo_bit parport_pc ppdev 
> lp sunrpc parport ip_tables x_tables autofs4 ext4 crc16 mbcache jbd2 
> crc32c_generic fscrypto ecb sr_mod cdrom sd_mod crc32c_intel ahci libahci 
> aesni_intel aes_x86_64 crypto_simd cryptd glue_helper libata xhci_pci 
> ehci_pci e1000e xhci_hcd ehci_hcd psmouse scsi_mod i2c_i801 ptp usbcore 
> pps_core usb_common fan thermal
> Nov  3 09:14:06 ws6779 kernel: [4.749204] CPU: 4 PID: 199 Comm: 
> kworker/u16:4 Not tainted 4.13.0-1-amd64 #1 Debian 4.13.4-2
> Nov  3 09:14:06 ws6779 kernel: [4.749205] Hardware name: Hewlett-Packard 
> HP EliteDesk 800 G1 TWR/18E4, BIOS L01 v02.65 07/13/2015
> Nov  3 09:14:06 ws6779 kernel: [4.749241] Workqueue: nvkm-disp 
> gf119_disp_super [nouveau]
> Nov  3 09:14:06 ws6779 kernel: [4.749241] task: 8c79d753d040 
> task.stack: b4f2821c4000
> Nov  3 09:14:06 ws6779 kernel: [4.749242] RIP: 0010:  (null)
> Nov  3 09:14:06 ws6779 kernel: [4.749242] RSP: 0018:b4f2821c7c40 
> EFLAGS: 00010206
> Nov  3 09:14:06 ws6779 kernel: [4.749243] RAX: c081fec0 RBX: 
>  RCX: 0016
> Nov  3 09:14:06 ws6779 kernel: [4.749244] RDX:  RSI: 
>  RDI: 8c79dbe9a000
> Nov  3 09:14:06 ws6779 kernel: [4.749244] RBP:  R08: 
>  R09: 
> Nov  3 09:14:06 ws6779 kernel: [4.749244] R10: 1000 R11: 
> 10624dd3 R12: 
> Nov  3 09:14:06 ws6779 kernel: [4.749245] R13: b4f2821c7d6e R14: 
> b4f2821c7d60 R15: 8c79dce92c00
> Nov  3 09:14:06 ws6779 kernel: [4.749245] FS:  () 
> GS:8c79efb0() knlGS:
> Nov  3 09:14:06 ws6779 kernel: [4.749246] CS:  0010 DS:  ES:  
> CR0: 80050033
> Nov  3 09:14:06 ws6779 kernel: [4.749247] CR2:  CR3: 
> 000214009000 CR4: 001406e0
> Nov  3 09:14:06 ws6779 kernel: [4.749247] Call Trace:
> Nov  3 09:14:06 ws6779 kernel: [4.749272]  ? 
> nvkm_dp_train_drive+0x210/0x2f0 [nouveau]
> Nov  3 09:14:06 ws6779 kernel: [4.749294]  ? nvkm_dp_acquire+0x89c/0xca0 
> [nouveau]
> Nov  3 09:14:06 ws6779 kernel: [4.749317]  ? 
> nv50_disp_super_2_2+0x69/0x430 [nouveau]
> Nov  3 09:14:06 ws6779 kernel: [4.749337]  ? gf119_disp_super+0x1a5/0x2f0 
> [nouveau]
> Nov  3 09:14:06 ws6779 kernel: [4.749340]  ? process_one_work+0x181/0x370
> Nov  3 09:14:06 ws6779 kernel: [4.749341]  ? worker_thread+0x4d/0x3a0
> Nov  3 09:14:06 ws6779 kernel: [4.749342]  ? kthread+0xfc/0x130
> Nov  3 09:14:06 ws6779 kernel: [4.749343]  ? process_one_work+0x370/0x370
> Nov  3 09:14:06 ws6779 kernel: [4.749344]  ? 
> kthread_create_on_node+0x70/0x70
> Nov  3 09:14:06 ws6779 kernel: [4.749346]  ? ret_from_fork+0x25/0x30

Bug#880582: apt: apt update hangs under qemu-user when host and target architecture are 64-bit

2017-11-03 Thread James Cowgill
Control: reassign -1 qemu-user 1:2.10.0+dfsg-2
Control: forwarded -1 https://bugs.launchpad.net/qemu/+bug/1726394
Control: severity -1 normal
Control: retitle -1 qemu-user: should not passthrough prctl(PR_SET_SECCOMP)
Control: affects -1 src:apt
Control: tags -1 patch

Hi,

On 02/11/17 15:04, Julian Andres Klode wrote:
> On Thu, Nov 02, 2017 at 02:49:07PM +, James Cowgill wrote:
>> Package: apt
>> Version: 1.6~alpha3
>> Severity: important
>>
>> Hi,
>>
>> I noticed that with apt 1.6, running apt-get update hangs in a mips64el
>> chroot running on an amd64 host using qemu-user-static. I can also
>> reproduce this with an arm64 target so I suspect this affects all 64-bit
>> architectures running on amd64.
>>
>> It outputs this before hanging (on mips64el):
>>> # apt-get update
>>> 0% [Working]qemu: Unsupported syscall: 5312
>>> 0% [Working]
>>
>> Syscall 5312 is "seccomp".
>>
>> If I run qemu-user with the -strace option, I see that the http method
>> calls the seccomp syscall which fails with ENOSYS (since it's not
>> supported in qemu). Then, libseccomp calls the old prctl(PR_SET_SECCOMP)
>> syscall which succeeds. I think in this case a valid seccomp filter is
>> installed, but for the wrong architecture. This results in the calling
>> thread being immediately killed when a syscall is later executed.
>>
>> The apt changelog mentions checking for EFAULT in case apt is started
>> inside QEMU. I think this only works by chance on 32-bit targets because
>> they would pass a truncated pointer to the real prctl which the kernel
>> would usually reject as an invalid address.
> 
> Sure, and there's nothing I can do about it. QEMU needs to be fixed in
> 
>https://bugs.launchpad.net/qemu/+bug/1726394
> 
> Nobody is reacting there.

OK. I didn't realize you already knew about this bug. I sent a patch
upstream to fix it (attached). 

> Unless you know how to reliably detect qemu-user, then that's easy
> - we could even just install filters for the host architecture.
> 
>>
>> I think the hanging is caused by the http method having two threads.
>> When an invalid syscall is executed under seccomp, only the calling
>> thread is killed. Since the http method is running two threads, the
>> other is left running and hangs. In turn this causes the parent apt
>> process to wait for the http method to exit which will never happen.
> 
> Are there two threads? I only know one. Anyway, this is supposed to
> call a signal handler which calls _exit, but apparently the signal
> handler was not called, or rather, presumably write(2) and _exit(2)
> were blocked by the invalid seccomp filter.

I ran strace on the method both inside and outside QEMU and the thread
only appears when run in qemu-user so it must be a QEMU thing. In that
case, if the original bug is fixed, this doesn't matter too much.

Thanks,
James
From 4d7ff6dc854fe7d24ee2aeff39b2973f87012fdd Mon Sep 17 00:00:00 2001
From: James Cowgill 
Date: Fri, 3 Nov 2017 11:06:19 +
Subject: [PATCH] linux-user: return EINVAL from prctl(PR_*_SECCOMP)

If an application tries to install a seccomp filter using
prctl(PR_SET_SECCOMP), the filter is likely for the target instead of the host
architecture. This will probably cause qemu to be immediately killed when it
executes another syscall.

Prevent this from happening by returning EINVAL from both seccomp prctl
calls. This is the error returned by the kernel when seccomp support is
disabled.

Fixes: https://bugs.launchpad.net/qemu/+bug/1726394
Signed-off-by: James Cowgill 
---
 linux-user/syscall.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/linux-user/syscall.c b/linux-user/syscall.c
index d4497dec5d..43cd5fb2bb 100644
--- a/linux-user/syscall.c
+++ b/linux-user/syscall.c
@@ -10482,6 +10482,10 @@ abi_long do_syscall(void *cpu_env, int num, abi_long arg1,
 break;
 }
 #endif
+case PR_GET_SECCOMP:
+case PR_SET_SECCOMP:
+ret = -TARGET_EINVAL;
+break;
 default:
 /* Most prctl options have no pointer arguments */
 ret = get_errno(prctl(arg1, arg2, arg3, arg4, arg5));
-- 
2.15.0



signature.asc
Description: OpenPGP digital signature


  1   2   >