date:20190526

Bug#929587: rsh-redone FTCBFS: does not pass cross tools to make

2019-05-26 Thread Guus Sliepen

On Sun, May 26, 2019 at 07:33:41PM +0200, Helmut Grohne wrote:

> rsh-redone fails to cross build from source, because it does not pass
> cross tools to make. The easiest way of doing so - using dh_auto_build -
> makes rsh-redone cross buildable. Please consider applying the attached
> patch.

Thanks for the patch! But that makes me realize that I should go a step
further and convert it completely to dh.

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen 


signature.asc
Description: PGP signature

Bug#929215: unblock: systemd/241-4

2019-05-26 Thread Niels Thykier

Michael Biebl:
> Am 20.05.19 um 14:06 schrieb Michael Biebl:
>> Am 19.05.19 um 12:47 schrieb Niels Thykier:
>>
   * Add check to switch VTs only between K_XLATE or K_UNICODE.
 Switching to K_UNICODE from other than L_XLATE can make the keyboard
 unusable and possibly leak keypresses from X.
 (CVE-2018-20839, Closes: #929116)

 https://salsa.debian.org/systemd-team/systemd/commit/5a564c6ef3906c0f3885a3a2aafce772393f760a
>>
>> In the mean time a regression was reported caused by this patch.
>> I marked the bug as RC. Given how long it takes to find a solution
>> upstream, I will either upload a fix for that or revert/drop the patch
>> again.
> 
> I've reverted this patch in 241-5, as no fix is available yet.
> No other changes were made in 241-5.
> 
> Regards,
> Michael
> 

Ack, thanks for handling this. The changes in 241-5 lgtm. :)

Thanks,
~Niels

Bug#929607: unblock: qemu/1:3.1+dfsg-8 (pre-upload)

2019-05-26 Thread Michael Tokarev

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

Hi!
I've prepared next release of the qemu debian package, with
a few bugfixes, and am asking if it's okay to upload these
changes to unstable (targetting buster). The change includes
3 security fixes which should go anyway, and 2 "other" fixes
which are questionable, hence the pre-approval bugreport/question.

All changes are "easy" ones, and are mostly one-liners and are
easy for review. All bugfixes has been appied upstream too.

Is it okay for the changes to go to buster?

Thanks,

/mjt

diff -Nru qemu-3.1+dfsg/debian/changelog qemu-3.1+dfsg/debian/changelog
--- qemu-3.1+dfsg/debian/changelog  2019-03-27 14:24:06.0 +0300
+++ qemu-3.1+dfsg/debian/changelog  2019-05-27 07:49:25.0 +0300
@@ -1,3 +1,23 @@
+qemu (1:3.1+dfsg-8) unstable; urgency=high
+
+  * sun4u-add-power_mem_read-routine-CVE-2019-5008.patch
+fixes a null-pointer dereference in sparc/sun4u emulated hw
+Closes: #927439, CVE-2019-5008
+  * enable-md-no.patch & enable-md-clear.patch
+mitigation for MDS (Microarchitectural Data Sampling) issues
+Closes: #929067,
+CVE-2018-12126, CVE-2018-12127, CVE-2018-12130, CVE-2019-11091
+  * qxl-check-release-info-object-CVE-2019-12155.patch
+fixes null-pointer deref in qxl cleanup code
+Closes: #929353, CVE-2019-12155
+  * aarch32-exception-return-to-switch-from-hyp-mon.patch
+fixes booting U-Boot in UEFI mode on aarch32
+Closes: #927763
+  * stop qemu-system-common pre-depending on adduser
+Closes: #929261
+
+ -- Michael Tokarev   Mon, 27 May 2019 07:49:25 +0300
+
 qemu (1:3.1+dfsg-7) unstable; urgency=high
 
   [ Michael Tokarev ]
diff -Nru qemu-3.1+dfsg/debian/control qemu-3.1+dfsg/debian/control
--- qemu-3.1+dfsg/debian/control2019-03-11 14:35:35.0 +0300
+++ qemu-3.1+dfsg/debian/control2019-05-27 07:49:25.0 +0300
@@ -191,7 +191,6 @@
 Package: qemu-system-common
 Architecture: amd64 arm arm64 armel armhf i386 ia64 kfreebsd-amd64 
kfreebsd-i386 mips mipsel mips64 mips64el powerpc powerpcspe ppc64 ppc64el 
s390x sparc sparc64 x32
 Multi-Arch: foreign
-Pre-Depends: adduser
 Replaces: qemu-system-data (<< 1:3.1+dfsg-1~), qemu-utils (<< 1:3.1+dfsg-3~)
 Breaks:   qemu-system-data (<< 1:3.1+dfsg-1~), qemu-utils (<< 1:3.1+dfsg-3~)
 Depends: ${misc:Depends}, ${shlibs:Depends},
diff -Nru qemu-3.1+dfsg/debian/control-in qemu-3.1+dfsg/debian/control-in
--- qemu-3.1+dfsg/debian/control-in 2019-03-11 14:19:34.0 +0300
+++ qemu-3.1+dfsg/debian/control-in 2019-05-27 07:49:25.0 +0300
@@ -196,7 +196,6 @@
 Package: qemu-system-common
 Architecture: amd64 arm arm64 armel armhf i386 ia64 kfreebsd-amd64 
kfreebsd-i386 mips mipsel mips64 mips64el powerpc powerpcspe ppc64 ppc64el 
s390x sparc sparc64 x32
 Multi-Arch: foreign
-Pre-Depends: adduser
 Replaces: qemu-system-data (<< 1:3.1+dfsg-1~), qemu-utils (<< 1:3.1+dfsg-3~)
 Breaks:   qemu-system-data (<< 1:3.1+dfsg-1~), qemu-utils (<< 1:3.1+dfsg-3~)
 Depends: ${misc:Depends}, ${shlibs:Depends},
diff -Nru 
qemu-3.1+dfsg/debian/patches/aarch32-exception-return-to-switch-from-hyp-mon.patch
 
qemu-3.1+dfsg/debian/patches/aarch32-exception-return-to-switch-from-hyp-mon.patch
--- 
qemu-3.1+dfsg/debian/patches/aarch32-exception-return-to-switch-from-hyp-mon.patch
  1970-01-01 03:00:00.0 +0300
+++ 
qemu-3.1+dfsg/debian/patches/aarch32-exception-return-to-switch-from-hyp-mon.patch
  2019-05-27 07:46:35.0 +0300
@@ -0,0 +1,56 @@
+From: Alexander Graf 
+Date: Mon, 21 Jan 2019 10:23:11 +
+Subject: target/arm: Allow Aarch32 exception return to switch from Mon->Hyp
+Commit-Id: 2d2a4549cc29850aab891495685a7b31f5254b12
+Bug-Debian: http://bugs.debian.org/927763
+
+In U-boot, we switch from S-SVC -> Mon -> Hyp mode when we want to
+enter Hyp mode. The change into Hyp mode is done by doing an
+exception return from Mon. This doesn't work with current QEMU.
+
+The problem is that in bad_mode_switch() we refuse to allow
+the change of mode.
+
+Note that bad_mode_switch() is used to do validation for two situations:
+
+ (1) changes to mode by instructions writing to CPSR.M
+ (ie not exception take/return) -- this corresponds to the
+ Armv8 Arm ARM pseudocode Arch32.WriteModeByInstr
+ (2) changes to mode by exception return
+
+Attempting to enter or leave Hyp mode via case (1) is forbidden in
+v8 and UNPREDICTABLE in v7, and QEMU is correct to disallow it
+there. However, we're already doing that check at the top of the
+bad_mode_switch() function, so if that passes then we should allow
+the case (2) exception return mode changes to switch into Hyp mode.
+
+We want to test whether we're trying to return to the nonexistent
+"secure Hyp" mode, so we need to look at arm_is_secure_below_el3()
+rather than arm_is_secure(), since the latter is always true if
+we're in Mon (EL3).
+
+Signed-off-by: Alexander Graf 
+Reviewed-by: Peter Maydell 
+Message-id:

Bug#929606: ITP: dataset-fashion-mnist -- (DL-Policy) A MNIST-like fashion product database.

2019-05-26 Thread Mo Zhou

Package: wnpp
Severity: wishlist
Owner: Mo Zhou 

* Package name: dataset-fashion-mnist
* URL : https://github.com/zalandoresearch/fashion-mnist
* License : MIT
  Description : A MNIST-like fashion product database.

This is a part of DL-Policy[1]'s experiments.

The first, typical dataset used by everyone who started to learn machine
learning and deep learning is very possibly MNIST[2].  MNIST had been
used for over 30 years by researchers and engineers to valiate their
algorithms and learning frameworks, etc. However, The original MNIST
dataset doesn't have (I didn't find it) an explict license. And I have
to use an alternative -- the modern replacement of that MNIST dataset,
i.e. fashion-mnist. It has an explicit MIT license.

Packaging this dataset is to some extent meaningful:

  1. Dataset size: ~30MiB. Very friendly to any modern storage devices.
  2. A "UnitTest" dataset for virtually any deep learning framework.
 Developers can use this dataset to validate any machine learning
 or deep learning frameworks.
  3. Very easy to train and validate. This is a tiny "toy" dataset.
 A weak CPU can train models on this dataset in a reasonable timeframe.
  4. As an DL-Policy-compliant dataset package example.
  5. The dataset it self is frozen. Subsequent maintainance burden after
 the initial upload is nearly zero ...

See also:
https://github.com/zalandoresearch/fashion-mnist#why-we-made-fashion-mnist

[1] https://salsa.debian.org/lumin/deeplearning-policy
[2] http://yann.lecun.com/exdb/mnist/

Bug#929365: qemu: CVE-2019-12247: qemu-guest-agent: integer overflow while running guest-exec command

2019-05-26 Thread Michael Tokarev


22.05.2019 15:40, Salvatore Bonaccorso wrote:

Source: qemu
Version: 1:3.1+dfsg-7
Severity: important
Tags: security upstream
Forwarded: https://lists.gnu.org/archive/html/qemu-devel/2019-05/msg04596.html

Hi,

The following vulnerability was published for qemu.

CVE-2019-12247[0]:
qemu-guest-agent: integer overflow while running guest-exec command


As explained at
https://lists.gnu.org/archive/html/qemu-devel/2019-05/msg05457.html
this is a non-issue really, since it can't be exploited due to other
constraints. JFYI, but it seems this is a non-issue currently.

Thanks,

/mjt

Bug#912185: mkfs.ext4 spanish translation incomplete cause problems

2019-05-26 Thread Theodore Ts'o

Control: tag -1 +pending

On Sun, Oct 28, 2018 at 06:42:47PM -0300, H. Gabriel Máculus wrote:
> Package: e2fsprogs
> Version: 1.43.4-2
> 
> When I run mkfs.ext4 to overwrite existing filesystem it prompt in
> english  (last line) and you need reply in spanish (S, n)

This has been fixed in the latest es.po from the Translation Project.  
It will be included in e2fsprogs 1.45.2.

- Ted

Bug#903635: docker.io: use of iptables-legacy is incompatible with nftables-based iptables

2019-05-26 Thread Arnaud Rebillout

On 5/24/19 4:33 PM, Jonathan Dowland wrote:
> Hi Arnaud - sorry I missed your messages until now.

No problem :)

>
> On Fri, May 10, 2019 at 09:03:41AM +0700, Arnaud Rebillout wrote:
>> As I mentioned above, there's a discussion with a work in progress to
>> fix that upstream: https://github.com/docker/libnetwork/pull/2339
>>
>> I don't think it will be ready in time for buster though. So I see two
>> solutions going forward:
>>
>> - 1 Jonathan lower the severity of the bug so that it's not RC.
>
> I'd rather not do that, because I think RC is the right classification;
> *but* I don't feel necessarily (given the circumstances) that docker.io
> should be removed from Buster, so can I instead suggest we request that
> this bug is ignored for Buster? I think we need to ask the release team
> to do that (and tag accordingly) but I'll double-check the procedure.
>
>> - 2 I import the patch from github, even though it's work in progress. I
>> will follow up and update the patch as soon as upstream release a proper
>> fix, and it will be included in a point release of buster.
>
>> If I don't get any feedback from you Jonathan in the following days,
>> I'll go for solution number 2 then.
>
> I bow to your judgement as maintainer as to whether the partial fix is
> worth applying on its own. Will the patch in #2339 address the specific
> issue of what happens on package install?

The thing is, I don't know for sure. After reading all the conversation,
it seems that it does fix the particular bug reported here. But upstream
also points out that it's just a partial solution, that's why the patch
is sitting there without anyone really merging it. It's not sure if an
improved version of the patch will appear. The bug has been opened for a
long time already (1.5 years), and upstream doesn't seem to care much.

Myself, I don't have a test setup to reproduce the bug and then validate
that the patch fixes it. And these days I can't afford the time to work
on that. That's why I'm also reluctant to blindly import this patch
(even though after looking at the diff itself, it looks rather trivial).

Hence I think it would be safer to go for option 1 and request that the
bug is ignored? Unless the reporter of the bug has the time and means to
actually test the patch in #2339?

For sure I will follow up on that during Buster lifecycle, hopefully
upstream will fix this for real, and in any case I'll find the time at
some point to properly test this patch.

Regards,

  Arnaud

Bug#929128: fonts-noto-cjk: not recognized by lualatex until mktexlsr

2019-05-26 Thread Ryutaroh Matsumoto

Hi Hilmar,
thanks for your interest and comment.
It is (in my opinion) a well-known issue among
Japanese LuaLaTeX users, and I can show a even worse
example (for your fun), which needs 6 GB of real RAM
and 10 minutes to compile three lines, in the first time
you process a CJK tex source as below :-)
Please process it by "lualatex" after "rm -rf ~/.texlive201?"
and installing texlive-full and fonts-noto-cjk
and fonts-noto-cjk-extra.
It should produce a PDF document with 7 CJK typefaces.

Once lualatex complies it, the same file is compiled
in much shorter time and much smaller memory.
(So one needs "rm -rf ~/.texlive201?" to see long compilation time.)

I was told that luajitlatex (on Windows) needed even longer
time to compile it :-)

\documentclass[a4paper,12pt]{ltjsarticle}
\usepackage[noto-otf,deluxe]{luatexja-preset}

\begin{document}
\Large\noindent
{\mcfamily \ltseries 細明朝体\\ \mdseries 明朝体\\ \bfseries 太明朝体}\\
{\gtfamily ゴシック体\\ \bfseries 太ゴシック体\\ \ebseries 極太ゴシック体}\\
{\mgfamily 丸ゴシック体}\\
\end{document}

I am a bit reluctant to file the above issue to
texlive-lang-japanese (or texlive-luatex??) because
it does not seem a packaging problem by the Debian TeX team and
they tell us in "reportbug" that

> -- Package-specific info:
> IMPORTANT INFORMATION: We will only consider bug reports concerning
> the packaging of TeX Live as relevant. If you have problems with
> combination of packages in a LaTeX document, please consult your
> local TeX User Group, the comp.text.tex user group, the author of
> the original .sty file, or any other help resource. 
> 
> In particular, bugs that are related to up-upstream, i.e., neither
> Debian nor TeX Live (upstream), but the original package authors,
> will be closed immediately.
> 
>*** The Debian TeX Team is *not* a LaTeX Help Desk ***

Best regards,
Ryutaroh


From: Hilmar Preuße 
Subject: Re: Bug#929128: fonts-noto-cjk: not recognized by lualatex until 
mktexlsr
Date: Sun, 26 May 2019 17:45:14 +0200

> Am 26.05.2019 um 03:52 teilte Ryutaroh Matsumoto mit:
> 
> Matsumoto-san,
> 
> I followed your instructions and tried to reproduce some kind of
> issue.
> I compiled your document using TL from experimental; it triggered some
> kind of memory leak in luatex. At least I would not expect that luatex
> needs 1,5 GB of RAM to compile your document:
> 
> %Cpu(s):  1.3 us, 47.8 sy,  0.3 ni,  0.0 id, 50.5 wa,  0.0 hi,  0.0 si,
> 0.0 st
> MiB Mem : 938.3 total, 59.5 free, 860.5 used, 18.3 buff/cache
> MiB Swap: 1376.6 total, 295.4 free, 1081.2 used.  21.0 avail Mem
> 
>   PID USER  PR  NIVIRTRESSHR S  %CPU  %MEM TIME+
> COMMAND
>   137 root   0 -20   0  0  0 I  32.2   0.0   0:11.56
> kworker/0+
>  5014 root  20   0 1533540 669688168 D   8.3  69.7   1:13.58
> lualatex
> 
> Please file a bug against our package texlive-binaries, version
> 2019.20190507.51032-1 .
> 
> Many thanks!
> 
> Hilmar
> 
>>> Matsumoto-san, I am actually surprised that mktexlsr call fixed it,
>>> since luatex doesn't use ls-R files.
>>> Do you have a way to reproduce this behaviour?
>>
>> You are right. The way to reproduce this issue (not related to
>> mktexlsr)
>> is
>> (1) Install texlive-full and fonts-noto-cjk from experimental.
>> (2) Run lualatex with the below LaTeX source and have error
>> "Package fontspec Error: The font "NotoSerifCJKJPLight" cannot be
>> found."
>> (3) Installation of fonts-noto-cjk-extra fixes the issue even though
>> no font from
>> fonts-noto-cjk-extra is used. XeLaTeX (with
>> \usepackage[noto]{zxjafont}) and
>> uplatex (with \usepackage[unicode,noto-otc]{pxchfon}) produce the
>> desired
>> PDF without fonts-noto-cjk-extra.
>>
>> \documentclass[a4paper,12pt]{ltjsarticle}
>> \usepackage[noto-otf]{luatexja-preset}
>>
>> \begin{document}
>> 日本語
>> \end{document}
>>
>> This seems a feature or a bug in TeXLive 2019 upstream, which should
>> not have
>> been filed in BTS. So I close this issue.
>>
> 
> 
> --
> #206401 http://counter.li.org

Bug#929128: fonts-noto-cjk: not recognized by lualatex until mktexlsr

2019-05-26 Thread Ryutaroh Matsumoto

Hi Hideki,
thanks for your kind comment.

My understanding is that it is related to luatexja-preset.sty
(or Japanese localization of LuaLaTeX).
When we run the "report-bug" against a tex package, it tells us that

> -- Package-specific info:
> IMPORTANT INFORMATION: We will only consider bug reports concerning
> the packaging of TeX Live as relevant. If you have problems with
> combination of packages in a LaTeX document, please consult your
> local TeX User Group, the comp.text.tex user group, the author of
> the original .sty file, or any other help resource. 
> 
> In particular, bugs that are related to up-upstream, i.e., neither
> Debian nor TeX Live (upstream), but the original package authors,
> will be closed immediately.
> 
>*** The Debian TeX Team is *not* a LaTeX Help Desk ***

So, provided that the issue is in luatexja-preset.sty,
the Debian TeX team may unwelcome it...
Is it OK to reopen it (and maybe reassign it to texlive-lang-japanese)?

If I understand the issue correctly,
the problem is that

* lualatex + luatexja-preset.sty requires "NotoSerifCJKJPLight"
  even when "NotoSerifCJKJPLight" font is not used in a document,
  while uplatex or xelatex (with their localizations files) does
  not require "NotoSerifCJKJPLight" unless it is used.

But the above behavior seems a kind of "design"...
And a solution can be inclusion of all CJK font files into
"fonts-noto-cjk", which suggests that this issue should be filed
against "fonts-noto-cjk".

Your feedbacks are welcome.

Ryutaroh

From: Hideki Yamane 
Subject: Re: Bug#929128: fonts-noto-cjk: not recognized by lualatex until 
mktexlsr
Date: Sun, 26 May 2019 16:08:15 +0900

> Hi,
> 
> On Sun, 26 May 2019 10:52:36 +0900
> Ryutaroh Matsumoto  wrote:
>> Sorry again for bothering all of you
> 
>  To be clear, it's _nothing_ wrong with you, IMHO.
>  Maybe it's better to reopen and reassign to appropriate texlive package
>  with "upstream" tag.
> 
> -- 
> Regards,
> 
>  Hideki Yamane henrich @ debian.org/iijmio-mail.jp

Bug#929567: libgtk-3-0:amd64: Emacs constantly crashes on startup with "X protocol error: BadLength..."

2019-05-26 Thread Vincent Lefevre

Testcase:

$ printf '\u26D4\n' > test
$ emacs -Q test

It is U+26D4 NO ENTRY that triggers the crash.

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

Bug#929605: courier-imap-ssl: courier-imap-ssl zombies

2019-05-26 Thread Dean Hamstead

Package: courier-imap
Version: 4.17.2+0.76.3-5+deb9u1
Severity: normal
File: courier-imap-ssl

Dear Maintainer,

   * What led up to the situation?

I recently upgraded from Jessie (4.15-1.6) to stretch. This was a clean
rebuild on a new VM, with mail data copied over and config changes
cherry-picked over to suit the new version.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

courier-imap-ssl seems to not be reaping processes properly, and zombies are
floating around. I dont have non-ssl imap running exposed to the
internet (its boound to localhost for webmail to use), but in its
limited use it isnt generating zombie processes.

Courier is being monitored by monit, it doesnt have any restarts in its
logs.

   * What was the outcome of this action?

Zombies.

   * What outcome did you expect instead?

No Zombies.



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

Kernel: Linux 4.19.0-0.bpo.4-cloud-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: sysvinit (via /sbin/init)

Versions of packages courier-imap depends on:
ii  courier-authlib0.66.4-9
ii  courier-base   0.76.3-5+deb9u1
ii  debconf [debconf-2.0]  1.5.61
ii  exim4-daemon-heavy [mail-transport-agent]  4.92-2~bpo9+1
ii  init-system-helpers1.48
ii  libc6  2.24-11+deb9u4
ii  libcourier-unicode11.4-3+b1
ii  libgamin0 [libfam0]0.1.10-5+b1
ii  libgdbm3   1.8.3-14
ii  libidn11   1.33-1
ii  sysvinit-utils 2.88dsf-59.9

courier-imap recommends no packages.

Versions of packages courier-imap suggests:
pn  courier-doc   
ii  mutt [imap-client]1.7.2-1+deb9u1
ii  s-nail [imap-client]  14.8.16-1

-- Configuration Files:
/etc/courier/imapd-ssl changed:
SSLPORT=993
SSLADDRESS=0
SSLPIDFILE=/run/courier/imapd-ssl.pid
SSLLOGGEROPTS="-name=imapd-ssl"
IMAPDSSLSTART=YES
IMAPDSTARTTLS=YES
IMAP_TLS_REQUIRED=0
COURIERTLS=/usr/bin/couriertls
TLS_CERTFILE=/etc/courier/imapd.pem
TLS_DHPARAMS=/etc/courier/dhparams.pem
TLS_TRUSTCERTS=/etc/ssl/certs
TLS_VERIFYPEER=NONE
TLS_CACHEFILE=/var/lib/courier/couriersslcache
TLS_CACHESIZE=524288
MAILDIRPATH=Maildir

/etc/courier/imapd changed:
ADDRESS=::1
PORT=143
MAXDAEMONS=40
MAXPERIP=20
PIDFILE=/run/courier/imapd.pid
TCPDOPTS="-nodnslookup -noidentlookup"
IMAPACCESSFILE=/etc/courier/imapaccess
LOGGEROPTS="-name=imapd"
IMAP_CAPABILITY="IMAP4rev1 UIDPLUS CHILDREN NAMESPACE THREAD=ORDEREDSUBJECT 
THREAD=REFERENCES SORT QUOTA IDLE"
IMAP_KEYWORDS=1
IMAP_ACL=1
IMAP_CAPABILITY_ORIG="IMAP4rev1 UIDPLUS CHILDREN NAMESPACE 
THREAD=ORDEREDSUBJECT THREAD=REFERENCES SORT QUOTA AUTH=CRAM-MD5 AUTH=CRAM-SHA1 
AUTH=CRAM-SHA256 IDLE"
IMAP_PROXY=0
IMAP_PROXY_FOREIGN=0
IMAP_IDLE_TIMEOUT=60
IMAP_MAILBOX_SANITY_CHECK=1
IMAP_CAPABILITY_TLS="$IMAP_CAPABILITY AUTH=PLAIN"
IMAP_CAPABILITY_TLS_ORIG="$IMAP_CAPABILITY_ORIG AUTH=PLAIN"
IMAP_DISABLETHREADSORT=0
IMAP_CHECK_ALL_FOLDERS=0
IMAP_OBSOLETE_CLIENT=0
IMAP_UMASK=022
IMAP_ULIMITD=131072
IMAP_USELOCKS=1
IMAP_SHAREDINDEXFILE=/etc/courier/shared/index
IMAP_ENHANCEDIDLE=0
IMAP_TRASHFOLDERNAME=Trash
IMAP_EMPTYTRASH=Trash:7
IMAP_MOVE_EXPUNGE_TO_TRASH=0
SENDMAIL=/usr/sbin/sendmail
HEADERFROM=X-IMAP-Sender
IMAPDSTART=YES
MAILDIRPATH=Maildir


-- no debconf information

Bug#929571: unblock: dgit/8.5

2019-05-26 Thread Ian Jackson

Control: tag -1 - moreinfo

Jonathan Wiltshire writes ("Re: Bug#929571: unblock: dgit/8.5"):
> On Sun, May 26, 2019 at 11:12:28AM +0100, Ian Jackson wrote:
> > I attach the git commit which explains the details.  Assuming you give
> > the go-ahead, I will upload this with an appropriate changelog update.
> 
> Please go ahead and remove the moreinfo tag from this bug when it is ready
> to unblock.

Thanks, done.

Ian.

-- 
Ian JacksonThese 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#929583: linux-image-5.0.0-trunk-amd64: Please build with CONFIG_ALLOW_LOCKDOWN_LIFT_BY_SYSRQ

2019-05-26 Thread Darsey Litzenberger


On Sun, May 26, 2019 at 06:07:35PM +0100, Ben Hutchings wrote:

There's no such severity as "severe", so I'll mark this "important".

[...]

I agree this should be enabled; in fact I thought it already was.


Oh... *blink* Oh, I meant to use 'serious' (the lowest available RC 
severity), to ensure it wouldn't be overlooked.  Apparently, that wasn't 
even necessary, heh.  %-)


Thanks for the quick reply!

- Darsey

Bug#929604: /usr/bin/xfdesktop-settings: Right click option 'set as wallpaper' on a image file doesn't work

2019-05-26 Thread Paulo Marcos de Souza Arruda do Nascimento

Package: xfdesktop4
Version: 4.12.4-2
Severity: normal
File: /usr/bin/xfdesktop-settings

Dear Maintainer,

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

   * What led up to the situation?
I wanted to set a image as a wallpaper of the desktop enviropment
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
I right clicked a image file and clicked to 'set as wallpaper'
   * What was the outcome of this action?
Nothing happened
   * What outcome did you expect instead?
Set the image I wanted as wallpaper of the xfce4 desktop enviropment.

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

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

Versions of packages xfdesktop4 depends on:
ii  exo-utils0.12.4-1
ii  libc62.28-10
ii  libcairo21.16.0-4
ii  libdbus-1-3  1.12.12-1
ii  libdbus-glib-1-2 0.110-4
ii  libexo-1-0   0.12.4-1
ii  libgarcon-1-00.6.2-1
ii  libgdk-pixbuf2.0-0   2.38.1+dfsg-1
ii  libglib2.0-0 2.58.3-1
ii  libgtk2.0-0  2.24.32-3
ii  libnotify4   0.7.7-4
ii  libpango-1.0-0   1.42.4-6
ii  libpangocairo-1.0-0  1.42.4-6
ii  libwnck222.30.7-6
ii  libx11-6 2:1.6.7-1
ii  libxfce4ui-1-0   4.12.1-3
ii  libxfce4util74.12.1-3
ii  libxfconf-0-24.12.1-1
ii  xfdesktop4-data  4.12.4-2

Versions of packages xfdesktop4 recommends:
ii  dbus-user-session [default-dbus-session-bus]  1.12.12-1
ii  dbus-x11 [dbus-session-bus]   1.12.12-1
ii  librsvg2-common   2.44.10-2.1
ii  tumbler   0.2.3-1
ii  xdg-user-dirs 0.17-2

Versions of packages xfdesktop4 suggests:
pn  menu  

-- no debconf information

Bug#926182: Patch: Use alternatives system for guile-2.2-dev binaries

2019-05-26 Thread Rob Browning

Vagrant Cascadian  writes:

> It seems like simply providing the binaries with the versioned links
> would be sufficient, since guile-2.2-dev conflicts/provides
> libguile-dev, guile-2.0-dev and guile-2.2-dev can't be installed at the
> same time.
>
> I guess it's possible the alternative for "guile" could be out of sync
> with the installed guile-2.2-dev binaries, although the newer versions
> have higher alternative default priority...
>
> The configure scripts seem to prefer the versioned binaries anyways...

Yep -- I'm not sure yet, but I may lean toward providing:

  bin/guile -> ./guile-2.2  # or whatever the selected alternative is
  bin/guild -> ./guild-2.2  # or whatever the selected alternative is
  ...

And then make sure that guild-X.Y, etc. refer specifically to guile-X.Y
(in, for example their #! lines), which I don't think they do right now.

In the longer run, I'd like to match as much as possible what upstream
does.  We've supported multiple versions for longer, but I suspect
upstream's approach is probably better (and more complete) than ours.
(That and of course it's always better not to differ unless we need to.)

Right now I'm poking around to see how where we might be headed
eventually compares to what's feasible to do at the moment (given
guile-2.0 and given the freeze).

Thanks
-- 
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

Bug#929601: dpkg-dev: README in dpkg-dev git repo incomplete (?)

2019-05-26 Thread Guillem Jover

Control: tags -1 moreinfo

Hi!

On Sun, 2019-05-26 at 16:37:01 -0400, Gerard Weatherby wrote:
> Package: dpkg-dev
> Version: 1.18.4ubuntu1.5
> Severity: minor
> Tags: newcomer

> I cloned https://git.dpkg.org/git/dpkg/dpkg.git. When I went to build it I
> found I had to install autopoint along with the dependencies list in the
> README.

I'm not quite sure I understand this report. What's the actual problem
here, were the dependencies list in the README not enough, were the
versions too low, etc? autopoint is already listed there.

Thanks,
Guillem

Bug#929521: Conficts in upgrade to 418.74-1 with optimus setup

2019-05-26 Thread Luca Boccassi

On Sun, 26 May 2019 at 22:45,  wrote:
>
> Le dimanche 26 mai 2019 à 19:44 +0100, Luca Boccassi a écrit :
> > Control: reassign 929525 src:nvidia-graphics-drivers 418.74-1
> > Control: forcemerge 929521 929525
> >
> > On Sat, 2019-05-25 at 15:54 +0200, ghisv...@gmail.com wrote:
> > > Package: src:nvidia-graphics-drivers
> > > Version: 418.74-1
> > > Severity: important
> > >
> > > Dear Debian NVIDIA maintainers,
> > >
> > > I attempted to upgrade my laptop (a Dell Inspiron 7580 with a
> > > GeForce
> > > MX150) running Debian Buster and configured with nvidia-driver,
> > > bumblebee-nvidia and primus, plus the necessary 32-bit libs to run
> > > Steam. So far, upgrades have been smooth until version 418.56-2.
> > >
> > > Sadly, version 418.74-1 is a different story. Running `apt upgrade`
> > > shows the following output:
> > >
> > > ```
> > > Les paquets suivants contiennent des dépendances non satisfaites :
> > >  nvidia-nonglvnd-vulkan-common : Est en conflit avec: libgl1-
> > > nvidia-
> > > legacy-390xx-glvnd-glx mais 390.116-1 devra être installé
> > >  Est en conflit avec: libgl1-
> > > nvidia-
> > > legacy-390xx-glvnd-glx:i386 mais 390.116-1 devra être installé
> > >  primus : Casse: libgl1-nvidia-legacy-390xx-glvnd-glx (>= 0) mais
> > > 390.116-1 devra être installé
> > >   Casse: libgl1-nvidia-legacy-390xx-glvnd-glx:i386 (>= 0)
> > > mais
> > > 390.116-1 devra être installé
> > > ```
> > >
> > > Which indicates conflicts for nvidia-nonglvnd-vulkan-common and
> > > breakage
> > > for Primus. What surprises me is the upgrade wishing to pull part
> > > of
> > > the
> > > legacy nvidia driver, whilst I am definitely using the current one.
> > >
> > > I have also tried to just remove the whole NVIDIA stack and start
> > > over
> > > as when I initially setup the machine. Running `apt get install
> > > bumblebee-nvidia` shows the following output :
> > >
> > > ```
> > > Les paquets suivants ont été installés automatiquement et ne sont
> > > plus
> > > nécessaires :
> > >   libegl-mesa0:i386 libegl1:i386 libgbm1:i386 libopengl0
> > > libopengl0:i386 libwayland-server0:i386 libxcb-xfixes0:i386 nvidia-
> > > egl-
> > > common nvidia-egl-icd nvidia-egl-icd:i386
> > > Veuillez utiliser « sudo apt autoremove » pour les supprimer.
> > > Les paquets supplémentaires suivants seront installés :
> > >   bbswitch-dkms bumblebee libegl-nvidia-legacy-390xx0:i386 libegl1-
> > > nvidia libegl1-nvidia:i386 libegl1-nvidia-legacy-390xx:i386 libgl1-
> > > nvidia-glx libgl1-nvidia-glx:i386 libgl1-nvidia-legacy-390xx-
> > > glx:i386
> > >   libgles-nvidia-legacy-390xx1:i386 libgles-nvidia-legacy-
> > > 390xx2:i386
> > > libglx-nvidia-legacy-390xx0:i386 libnvidia-legacy-390xx-cfg1
> > > libnvidia-
> > > legacy-390xx-cfg1:i386 libnvidia-legacy-390xx-eglcore:i386
> > >   libnvidia-legacy-390xx-glcore libnvidia-legacy-390xx-glcore:i386
> > > libnvidia-legacy-390xx-ml1 nvidia-driver-libs-nonglvnd nvidia-
> > > driver-
> > > libs-nonglvnd:i386 nvidia-driver-libs-nonglvnd-i386:i386
> > >   nvidia-legacy-390xx-alternative nvidia-legacy-390xx-driver-libs-
> > > nonglvnd:i386 nvidia-legacy-390xx-kernel-dkms nvidia-legacy-390xx-
> > > kernel-support nvidia-legacy-390xx-nonglvnd-vulkan-icd:i386
> > >   nvidia-legacy-390xx-vdpau-driver nvidia-nonglvnd-vulkan-common
> > > nvidia-nonglvnd-vulkan-icd nvidia-nonglvnd-vulkan-icd:i386 nvidia-
> > > settings-legacy-390xx primus primus-libs primus-libs-ia32:i386
> > > socat
> > >   xserver-xorg-video-nvidia-legacy-390xx
> > > Paquets suggérés :
> > >   vulkan-utils:i386 vulkan-utils
> > > Paquets recommandés :
> > >   nvidia-legacy-390xx-driver | libnvidia-legacy-390xx-cuda1 libgl1-
> > > nvidia-legacy-390xx-glvnd-glx | libgl1-nvidia-legacy-390xx-glx
> > > nvidia-
> > > legacy-390xx-driver
> > > Les paquets suivants seront ENLEVÉS :
> > >   libgl1-nvidia-glvnd-glx libgl1-nvidia-glvnd-glx:i386 nvidia-
> > > driver-
> > > libs nvidia-driver-libs:i386 nvidia-driver-libs-i386:i386 nvidia-
> > > vulkan-common nvidia-vulkan-icd nvidia-vulkan-icd:i386
> > > Les NOUVEAUX paquets suivants seront installés :
> > >   bbswitch-dkms bumblebee bumblebee-nvidia libegl-nvidia-legacy-
> > > 390xx0:i386 libegl1-nvidia libegl1-nvidia:i386 libegl1-nvidia-
> > > legacy-
> > > 390xx:i386 libgl1-nvidia-glx libgl1-nvidia-glx:i386
> > >   libgl1-nvidia-legacy-390xx-glx:i386 libgles-nvidia-legacy-
> > > 390xx1:i386
> > > libgles-nvidia-legacy-390xx2:i386 libglx-nvidia-legacy-390xx0:i386
> > > libnvidia-legacy-390xx-cfg1 libnvidia-legacy-390xx-cfg1:i386
> > >   libnvidia-legacy-390xx-eglcore:i386 libnvidia-legacy-390xx-glcore
> > > libnvidia-legacy-390xx-glcore:i386 libnvidia-legacy-390xx-ml1
> > > nvidia-
> > > driver-libs-nonglvnd nvidia-driver-libs-nonglvnd:i386
> > >   nvidia-driver-libs-nonglvnd-i386:i386 nvidia-legacy-390xx-
> > > alternative
> > > nvidia-legacy-390xx-driver-libs-nonglvnd:i386 nvidia-legacy-390xx-
> > > kernel-dkms nvidia-legacy-390xx-kernel-support
> > >

Bug#928444: fixed in jetty9 9.4.18-1

2019-05-26 Thread tony mancill

On Sun, May 26, 2019 at 09:24:30PM +0200, Moritz Mühlenhoff wrote:
> On Mon, May 06, 2019 at 04:19:33AM +, tony mancill wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA512
> > 
> > Format: 1.8
> > Date: Sun, 05 May 2019 19:57:45 -0700
> > Source: jetty9
> > Architecture: source
> > Version: 9.4.18-1
> > Distribution: experimental
> > Urgency: medium
> > Maintainer: Debian Java Maintainers 
> > 
> > Changed-By: tony mancill 
> > Closes: 928444
> > Changes:
> >  jetty9 (9.4.18-1) experimental; urgency=medium
> >  .
> >* Team upload.
> >* New upstream release
> >  - Addresses CVE-2019-10241, CVE-2019-10247 (Closes: #928444)
> 
> What's the plan for unstable/buster?

Hi Moritz,

Good question!  I uploaded the new version to experimental so users had
at least one option within Debian for addressing those CVEs, but I
haven't looked into what it would take to backport just the CVE patches
to 9.4.15.

Are we deep enough into the freeze that it is reasonable to go ahead and
upload to unstable?  (I'm never sure how to judge these things.)

For buster, t-p-u would have a quick turn around, but there are a number
of upstream changes between 9.4.15 and 9.4.18 [1], and I don't have a
good sense for the risk trade-off between the new version and the
backport.  Since I haven't handled any of the jetty9 uploads, I would
like to defer to Emmanuel to see if he has a preference.

Thank you,
tony

[1] 
https://salsa.debian.org/java-team/jetty9/blob/be3f955ab42b5612e1022667216f8453812f5277/VERSION.txt#L1-43

signature.asc
Description: PGP signature

Bug#929521: Conficts in upgrade to 418.74-1 with optimus setup

2019-05-26 Thread ghisvail

Le dimanche 26 mai 2019 à 19:44 +0100, Luca Boccassi a écrit :
> Control: reassign 929525 src:nvidia-graphics-drivers 418.74-1
> Control: forcemerge 929521 929525
> 
> On Sat, 2019-05-25 at 15:54 +0200, ghisv...@gmail.com wrote:
> > Package: src:nvidia-graphics-drivers
> > Version: 418.74-1
> > Severity: important
> > 
> > Dear Debian NVIDIA maintainers,
> > 
> > I attempted to upgrade my laptop (a Dell Inspiron 7580 with a
> > GeForce
> > MX150) running Debian Buster and configured with nvidia-driver,
> > bumblebee-nvidia and primus, plus the necessary 32-bit libs to run
> > Steam. So far, upgrades have been smooth until version 418.56-2.
> > 
> > Sadly, version 418.74-1 is a different story. Running `apt upgrade`
> > shows the following output:
> > 
> > ```
> > Les paquets suivants contiennent des dépendances non satisfaites :
> >  nvidia-nonglvnd-vulkan-common : Est en conflit avec: libgl1-
> > nvidia-
> > legacy-390xx-glvnd-glx mais 390.116-1 devra être installé
> >  Est en conflit avec: libgl1-
> > nvidia-
> > legacy-390xx-glvnd-glx:i386 mais 390.116-1 devra être installé
> >  primus : Casse: libgl1-nvidia-legacy-390xx-glvnd-glx (>= 0) mais
> > 390.116-1 devra être installé
> >   Casse: libgl1-nvidia-legacy-390xx-glvnd-glx:i386 (>= 0)
> > mais
> > 390.116-1 devra être installé
> > ```
> > 
> > Which indicates conflicts for nvidia-nonglvnd-vulkan-common and
> > breakage
> > for Primus. What surprises me is the upgrade wishing to pull part
> > of
> > the
> > legacy nvidia driver, whilst I am definitely using the current one.
> > 
> > I have also tried to just remove the whole NVIDIA stack and start
> > over
> > as when I initially setup the machine. Running `apt get install
> > bumblebee-nvidia` shows the following output :
> > 
> > ```
> > Les paquets suivants ont été installés automatiquement et ne sont
> > plus
> > nécessaires :
> >   libegl-mesa0:i386 libegl1:i386 libgbm1:i386 libopengl0
> > libopengl0:i386 libwayland-server0:i386 libxcb-xfixes0:i386 nvidia-
> > egl-
> > common nvidia-egl-icd nvidia-egl-icd:i386
> > Veuillez utiliser « sudo apt autoremove » pour les supprimer.
> > Les paquets supplémentaires suivants seront installés :
> >   bbswitch-dkms bumblebee libegl-nvidia-legacy-390xx0:i386 libegl1-
> > nvidia libegl1-nvidia:i386 libegl1-nvidia-legacy-390xx:i386 libgl1-
> > nvidia-glx libgl1-nvidia-glx:i386 libgl1-nvidia-legacy-390xx-
> > glx:i386
> >   libgles-nvidia-legacy-390xx1:i386 libgles-nvidia-legacy-
> > 390xx2:i386
> > libglx-nvidia-legacy-390xx0:i386 libnvidia-legacy-390xx-cfg1
> > libnvidia-
> > legacy-390xx-cfg1:i386 libnvidia-legacy-390xx-eglcore:i386
> >   libnvidia-legacy-390xx-glcore libnvidia-legacy-390xx-glcore:i386
> > libnvidia-legacy-390xx-ml1 nvidia-driver-libs-nonglvnd nvidia-
> > driver-
> > libs-nonglvnd:i386 nvidia-driver-libs-nonglvnd-i386:i386
> >   nvidia-legacy-390xx-alternative nvidia-legacy-390xx-driver-libs-
> > nonglvnd:i386 nvidia-legacy-390xx-kernel-dkms nvidia-legacy-390xx-
> > kernel-support nvidia-legacy-390xx-nonglvnd-vulkan-icd:i386
> >   nvidia-legacy-390xx-vdpau-driver nvidia-nonglvnd-vulkan-common
> > nvidia-nonglvnd-vulkan-icd nvidia-nonglvnd-vulkan-icd:i386 nvidia-
> > settings-legacy-390xx primus primus-libs primus-libs-ia32:i386
> > socat
> >   xserver-xorg-video-nvidia-legacy-390xx
> > Paquets suggérés :
> >   vulkan-utils:i386 vulkan-utils
> > Paquets recommandés :
> >   nvidia-legacy-390xx-driver | libnvidia-legacy-390xx-cuda1 libgl1-
> > nvidia-legacy-390xx-glvnd-glx | libgl1-nvidia-legacy-390xx-glx
> > nvidia-
> > legacy-390xx-driver
> > Les paquets suivants seront ENLEVÉS :
> >   libgl1-nvidia-glvnd-glx libgl1-nvidia-glvnd-glx:i386 nvidia-
> > driver-
> > libs nvidia-driver-libs:i386 nvidia-driver-libs-i386:i386 nvidia-
> > vulkan-common nvidia-vulkan-icd nvidia-vulkan-icd:i386
> > Les NOUVEAUX paquets suivants seront installés :
> >   bbswitch-dkms bumblebee bumblebee-nvidia libegl-nvidia-legacy-
> > 390xx0:i386 libegl1-nvidia libegl1-nvidia:i386 libegl1-nvidia-
> > legacy-
> > 390xx:i386 libgl1-nvidia-glx libgl1-nvidia-glx:i386
> >   libgl1-nvidia-legacy-390xx-glx:i386 libgles-nvidia-legacy-
> > 390xx1:i386 
> > libgles-nvidia-legacy-390xx2:i386 libglx-nvidia-legacy-390xx0:i386
> > libnvidia-legacy-390xx-cfg1 libnvidia-legacy-390xx-cfg1:i386
> >   libnvidia-legacy-390xx-eglcore:i386 libnvidia-legacy-390xx-glcore
> > libnvidia-legacy-390xx-glcore:i386 libnvidia-legacy-390xx-ml1
> > nvidia-
> > driver-libs-nonglvnd nvidia-driver-libs-nonglvnd:i386
> >   nvidia-driver-libs-nonglvnd-i386:i386 nvidia-legacy-390xx-
> > alternative 
> > nvidia-legacy-390xx-driver-libs-nonglvnd:i386 nvidia-legacy-390xx-
> > kernel-dkms nvidia-legacy-390xx-kernel-support
> >   nvidia-legacy-390xx-nonglvnd-vulkan-icd:i386 nvidia-legacy-390xx-
> > vdpau-driver nvidia-nonglvnd-vulkan-common nvidia-nonglvnd-vulkan-
> > icd
> > nvidia-nonglvnd-vulkan-icd:i386 nvidia-settings-legacy-390xx primus
> >   primus-libs

Bug#925173: ltsp: codename detection code not useful for stable

2019-05-26 Thread Vagrant Cascadian

Control: severity 925173 serious

On 2019-03-20, Wolfgang Schweer wrote:
> while testing Debian Edu offline installation I noticed that the code I 
> proposed
> a while ago to determine the DIST value is working ok in testing, but will be
> totally useless once Buster is stable.

Thanks for the patch!

Apparently, it's already impacting buster:

$ sudo ltsp-build-client
NOTE: adding default dist and components to security mirror:
http://security.debian.org/ 10.0/updates main
ERROR: invalid distribution: 10.0
you may need to specify the distribution with the --dist argument:
  /usr/sbin/ltsp-build-client --dist etch
error: LTSP client installation ended abnormally


Yeah, that's not going to work at all...


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#929552: g++-x86-64-linux-gnu: broken symlink: /usr/share/doc/g++-x86_64-linux-gnu -> cpp-x86_64-linux-gnu

2019-05-26 Thread Matthias Klose

Control: notfound -1 4:9-20181127-1

On 26.05.19 02:21, Andreas Beckmann wrote:
> Package: g++-x86-64-linux-gnu
> Version: 4:8.3.0-1
> Severity: normal
> User: debian...@lists.debian.org
> Usertags: piuparts
> Control: found -1 g++-x86-64-linux-gnu/4:8.3.0-1
> 
> Hi,
> 
> during a test with piuparts I noticed your package ships (or creates)
> a broken symlink.
> 
>>From the attached log (scroll to the bottom...):
> 
> 0m30.7s ERROR: FAIL: Broken symlinks:
>   /usr/share/doc/g++-x86_64-linux-gnu -> cpp-x86_64-linux-gnu 
> (g++-x86-64-linux-gnu)
> 
> 
> Note that the incorrect link uses '_' instead of '-' in source and target.
> 
> There were similar bugs in other packages in the past,
> e.g. #915678 in gcc-x86-64-linux-gnux32

apparently only fixed in the package in experimental.  However the correct
symlink seems to be there as well:

$ dpkg -L g++-x86-64-linux-gnu
/.
/usr
/usr/bin
/usr/share
/usr/share/doc
/usr/share/lintian
/usr/share/lintian/overrides
/usr/share/lintian/overrides/g++-x86-64-linux-gnu
/usr/bin/x86_64-linux-gnu-g++
/usr/share/doc/g++-x86-64-linux-gnu
/usr/share/doc/g++-x86_64-linux-gnu

Bug#929603: unblock: webkit2gtk/2.24.2-1

2019-05-26 Thread Alberto Garcia

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

Please unblock package webkit2gtk

The new upstream stable release contains (among others) fixes
for these three security bugs: CVE-2019-8595, CVE-2019-8607 and
CVE-2019-8615.

unblock webkit2gtk/2.24.2-1

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

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

Bug#929297: minissdpd: CVE-2019-12106

2019-05-26 Thread Moritz Mühlenhoff

On Sat, May 25, 2019 at 09:08:32AM +0100, Chris Lamb wrote:
> Hey,
> 
> > > The following vulnerability was published for minissdpd.
> > > 
> > > CVE-2019-12106[0]:
> > > | The updateDevice function in minissdpd.c in MiniUPnP MiniSSDPd 1.4 and
> > > | 1.5 allows a remote attacker to crash the process due to a Use After
 > > > | Free vulnerability.
> […]
> > Chris, thanks for your proposal to update Stretch, I very much
> > appreciate it.
> 
> Another gentle ping, security team?

This doesn't warrant a DSA, feel free to fix it via a point release instead.

Cheers,
Moritz

Bug#929601: dpkg-dev: README in dpkg-dev git repo incomplete (?)

2019-05-26 Thread Gerard Weatherby

Package: dpkg-dev
Version: 1.18.4ubuntu1.5
Severity: minor
Tags: newcomer

Dear Maintainer,

I cloned https://git.dpkg.org/git/dpkg/dpkg.git. When I went to build it I
found I had to install autopoint along with the dependencies list in the
README.

Using Ubuntu 16.04.6 LTS



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

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

Versions of packages dpkg-dev depends on:
ii  base-files9.4ubuntu4.8
ii  binutils  2.26.1-1ubuntu1~16.04.8
ii  bzip2 1.0.6-8
ii  libdpkg-perl  1.18.4ubuntu1.5
ii  make  4.1-6
ii  patch 2.7.5-1ubuntu0.16.04.1
ii  xz-utils  5.1.1alpha+20120614-2ubuntu2

Versions of packages dpkg-dev recommends:
ii  build-essential  12.1ubuntu2
ii  fakeroot 1.20.2-1ubuntu1
ii  gcc [c-compiler] 4:5.3.1-1ubuntu1
ii  gcc-5 [c-compiler]   5.4.0-6ubuntu1~16.04.11
ii  gnupg1.4.20-1ubuntu3.3
ii  gnupg2   2.1.11-6ubuntu2.1
ii  gpgv 1.4.20-1ubuntu3.3
ii  libalgorithm-merge-perl  0.08-3

Versions of packages dpkg-dev suggests:
ii  debian-keyring  2016.01.20

-- no debconf information

Bug#929602: unblock: libhmsbeagle/3.1.2+dfsg-6

2019-05-26 Thread Andreas Tille

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

Please unblock package libhmsbeagle



diff -Nru libhmsbeagle-3.1.2+dfsg/debian/changelog 
libhmsbeagle-3.1.2+dfsg/debian/changelog
--- libhmsbeagle-3.1.2+dfsg/debian/changelog2019-02-22 15:31:02.0 
+0100
+++ libhmsbeagle-3.1.2+dfsg/debian/changelog2019-05-26 22:06:37.0 
+0200
@@ -1,3 +1,11 @@
+libhmsbeagle (3.1.2+dfsg-6) unstable; urgency=medium
+
+  * Team upload.
+  * Replace DEB_HOST_GNU_TYPE by DEB_HOST_MULTIARCH
+Closes: #929560
+
+ -- Dylan Aïssi   Sun, 26 May 2019 22:06:37 +0200
+
 libhmsbeagle (3.1.2+dfsg-5) unstable; urgency=medium
 
   * Re-add libhmsbeagle1v5.dirs
diff -Nru libhmsbeagle-3.1.2+dfsg/debian/libhmsbeagle1v5.links 
libhmsbeagle-3.1.2+dfsg/debian/libhmsbeagle1v5.links
--- libhmsbeagle-3.1.2+dfsg/debian/libhmsbeagle1v5.links2019-02-22 
15:31:02.0 +0100
+++ libhmsbeagle-3.1.2+dfsg/debian/libhmsbeagle1v5.links2019-05-26 
22:06:37.0 +0200
@@ -1,2 +1,2 @@
 #!/usr/bin/dh-exec
-/usr/lib/${DEB_HOST_GNU_TYPE}/libhmsbeagle-jni.so 
/usr/lib/${DEB_HOST_GNU_TYPE}/jni/libhmsbeagle-jni.so
+/usr/lib/${DEB_HOST_MULTIARCH}/libhmsbeagle-jni.so 
/usr/lib/${DEB_HOST_MULTIARCH}/jni/libhmsbeagle-jni.so


unblock libhmsbeagle/3.1.2+dfsg-6

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

Kernel: Linux 4.9.0-6-amd64 (SMP w/1 CPU core)
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#929600: slurm-llnl: FTBFS on 32-bit architectures

2019-05-26 Thread Andreas Beckmann

Package: slurm-llnl
Version: 16.05.9-1+deb9u3
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
User: debian...@lists.debian.org
Usertags: piuparts
Control: affects -1 + slurm-wlm-torque

Hi,

the stretch update of slurm-llnl FTBFS on the 32-bit architectures:

https://buildd.debian.org/status/package.php?p=slurm-llnl=stretch

from the i386 log:

gcc -c  -I. -I../../../../.. -I../../../../../contribs/perlapi/common 
-I../../../.. -g -static -DNUMA_VERSION1_COMPATIBILITY -g -O2 
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -pthread -Wdate-time -D_FORTIFY_SOURCE=2 -O2 -g   
-DVERSION=\"0.02\" -DXS_VERSION=\"0.02\" -fPIC 
"-I/usr/lib/i386-linux-gnu/perl/5.24/CORE"   job.c
In file included from job.c:14:0:
slurm-perl.h:20:14: error: conflicting types for 'slurm_xmalloc'
 extern void *slurm_xmalloc(size_t, bool, const char *, int, const char *);
  ^
In file included from ../../../../../src/common/io_hdr.h:57:0,
 from ../../../../../src/slurmd/slurmstepd/slurmstepd_job.h:56,
 from ../../../../../src/common/switch.h:53,
 from ../../../../../src/slurmctld/slurmctld.h:81,
 from ../../../../../src/common/job_resources.h:55,
 from job.c:11:
../../../../../src/common/xmalloc.h:114:7: note: previous declaration of 
'slurm_xmalloc' was here
 void *slurm_xmalloc(uint64_t, bool, const char *, int, const char *);
   ^
Makefile:389: recipe for target 'job.o' failed
make[4]: *** [job.o] Error 1


Andreas

Bug#929599: calendarserver: missing dependency on libpython-dev

2019-05-26 Thread Giuseppe Sacco

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

Hello Rahul,
I just installed the package, changed the configuration file in order
to start it, then start it.
The server did not start because of this error (shown by journalctl):

mag 26 21:28:01 mantide systemd[1]: Starting LSB: Calendar and Contacts 
Server...
mag 26 21:28:02 mantide calendarserver[18826]: 
usr/lib/python2.7/dist-packages/twext/python/__pycache__/_cffi_twext_python_sacl_xe128630fxbbd600c.c:2:20:
 fatal error: Python.h: File o directory non esistente
mag 26 21:28:02 mantide calendarserver[18826]:  #include 
mag 26 21:28:02 mantide calendarserver[18826]: ^
mag 26 21:28:02 mantide calendarserver[18826]: compilation terminated.
mag 26 21:28:02 mantide systemd[1]: Started LSB: Calendar and Contacts Server.

Installing package libpython-dev solved the problem.

Bye,
Giuseppe

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

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

Versions of packages calendarserver depends on:
ii  adduser  3.115
ii  lsb-base 9.20161125
ii  memcached1.4.33-1+deb9u1
ii  python   2.7.13-2
ii  python-crypto2.6.1-7
ii  python-dateutil  2.7.3-3
ii  python-kerberos  1.1.14-2
ii  python-openssl   16.2.0-1
ii  python-pg80001.10.6-1
ii  python-psutil5.5.1-1
ii  python-pycalendar1:2.1~git20161130.0.e68e150-1
ii  python-service-identity  16.0.0-2
ii  python-setproctitle  1.1.10-1+b2
ii  python-sqlparse  0.2.4-1
ii  python-twext 1:0.1~git20161216.0.b90293c-2
ii  python-twisted   18.9.0-3
ii  python-twisted-core  18.9.0-3
ii  python-tz2019.1-1
ii  python-xattr 0.9.6-1
ii  python-zope.interface4.3.2-1+b2
ii  ssl-cert 1.0.39

Versions of packages calendarserver recommends:
pn  python-pam  

calendarserver suggests no packages.

-- Configuration Files:
/etc/caldavd/resources.xml changed:

/etc/default/calendarserver changed:
start_calendarserver=yes


-- no debconf information

Bug#929598: simple-cdd dies when building jessie/oldstable

2019-05-26 Thread Tomas Benda

Package: simple-cdd
Version: 0.6.5 also 0.6.6

simple-cdd dies when downloading source with 404 not found.

and yes, the path doesnt exist, there is no CURRENT folder in

/dists/oldstable/main/installer-amd64/ on the debian mirrors.



./build-simple-cdd --dist oldstable --debug

2019-05-26 21:31:38,864 DEBUG downloading: 
/home/ansbl/tmp/simple-cdd-0.6.6/tmp/mirror/dists/oldstable/main/installer-amd64/current/images/SHA256SUMS

Traceback (most recent call last):
  File "./build-simple-cdd", line 678, in 
scdd.build_mirror()
  File "./build-simple-cdd", line 290, in build_mirror
self.run_tool("mirror", tool)
  File "./build-simple-cdd", line 387, in run_tool
tool.run()
  File "/home/ansbl/tmp/simple-cdd-0.6.6/simple_cdd/tools/mirror_download.py", 
line 131, in run
_download(url, absname, checksums=sums, relname=relname)
  File "/home/ansbl/tmp/simple-cdd-0.6.6/simple_cdd/tools/mirror_download.py", 
line 55, in _download
request.urlretrieve(url, filename=output)
  File "/usr/lib/python3.5/urllib/request.py", line 188, in urlretrieve
with contextlib.closing(urlopen(url, data)) as fp:
  File "/usr/lib/python3.5/urllib/request.py", line 163, in urlopen
return opener.open(url, data, timeout)
  File "/usr/lib/python3.5/urllib/request.py", line 472, in open
response = meth(req, response)
  File "/usr/lib/python3.5/urllib/request.py", line 582, in http_response
'http', request, response, code, msg, hdrs)
  File "/usr/lib/python3.5/urllib/request.py", line 504, in error
result = self._call_chain(*args)
  File "/usr/lib/python3.5/urllib/request.py", line 444, in _call_chain
result = func(*args)
  File "/usr/lib/python3.5/urllib/request.py", line 696, in http_error_302
return self.parent.open(new, timeout=req.timeout)
  File "/usr/lib/python3.5/urllib/request.py", line 472, in open
response = meth(req, response)
  File "/usr/lib/python3.5/urllib/request.py", line 582, in http_response
'http', request, response, code, msg, hdrs)
  File "/usr/lib/python3.5/urllib/request.py", line 510, in error
return self._call_chain(*args)
  File "/usr/lib/python3.5/urllib/request.py", line 444, in _call_chain
result = func(*args)
  File "/usr/lib/python3.5/urllib/request.py", line 590, in http_error_default
raise HTTPError(req.full_url, code, msg, hdrs, fp)
urllib.error.HTTPError: HTTP Error 404: Not Found


I suggest there should be symlink to the latest folder

20150422+deb8u5/



Linux  4.9.0-9-amd64 #1 SMP Debian 4.9.168-1 (2019-04-12) x86_64 GNU/Linux




--


[Mikenopa]




Tomas Benda
Research and Development

M: +420 724 619 013 | E: 
tomas.be...@mikenopa.com
Rohanske nabrezi 671/15 | 186 00 | Prague 8 | Czech Republic
www.mikenopa.com

Athens - Berlin - Brussels - Budapest - Copenhagen - Istanbul - London - Moscow 
- Oslo - Paris - Prague - Stockholm - Singapore

Bug#929597: CVE-2019-12211 CVE-2019-12212 CVE-2019-12213 CVE-2019-12214

2019-05-26 Thread Anton Gladky

Hi Moritz,

thanks for the reporting. As far as I see, there is still
no available fix from upstream.

Cheers

Anton

Am So., 26. Mai 2019 um 21:27 Uhr schrieb Moritz Muehlenhoff :
>
> Source: freeimage
> Severity: grave
> Tags: security
>
> Please see
> http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-12211
> http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-12212
> http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-12213
> http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-12214
>
> Cheers,
> Moritz
>
> --
> debian-science-maintainers mailing list
> debian-science-maintain...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#929577: lintian: Please keep the version in buster up to date

2019-05-26 Thread Mattia Rizzolo

On Sun, May 26, 2019 at 08:40:29PM +0100, Chris Lamb wrote:
> Beyond using the version number mathematics
> work, were you thinking of anything else here?

nope, just the usual lower-than/greathr-than relationship.

-- 
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  `-

Bug#929410: [Pkg-tigervnc-devel] Bug#929410: RANDR extension not present

2019-05-26 Thread Ola Lundqvist

Hi

Thank you for the report. I cannot reproduce the problem on Debian stable
with version 1.7.0.

I do not have a system running sid right now.

// Ola

On Thu, 23 May 2019 at 00:51, Floris Bos  wrote:

> Package: tigervnc-scraping-server
>
> Version: 1.9.0+dfsg-3
>
>
> Seems the tigervnc package is missing randr support.
>
>
> ==
>
> $ x0tigervncserver -SecurityTypes none
>
> Wed May 22 22:20:30 2019
>   Geometry:Desktop geometry is set to 1024x768+0+0
>   XDesktop:Using evdev codemap
>
>   XDesktop:XTest extension present - version 2.2
>   XDesktop:RANDR extension not present
>   XDesktop:Will not be able to handle session resize
>   Main:Listening on port 5900
> ^C
>
> ==
>
>
> While my system/X server certainly has the RANDR extension:
>
>
> ==
>
> $ xrandr
> Screen 0: minimum 320 x 200, current 1024 x 768, maximum 7680 x 7680
> HDMI-1 connected primary 1024x768+0+0 (normal left inverted right x axis
> y axis) 0mm x 0mm
> 1024x768  60.00*
> 800x600   60.3256.25
> 848x480   60.00
> 640x480   59.94
>
> ==
>
>
> Think you are missing a build dependeny on the libxrandr2 library.
>
> If HAVE_XRANDR is not set at compile time, it always prints the message
> (
>
> https://github.com/TigerVNC/tigervnc/blob/master/unix/x0vncserver/XDesktop.cxx#L182
> )
>
> ___
> Pkg-tigervnc-devel mailing list
> pkg-tigervnc-de...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-tigervnc-devel



-- 
 - Ola Lundqvist ---
/  o...@debian.org o...@inguza.com  \
|  http://inguza.com/  +46 (0)70-332 1551   |
 ---

Bug#929215: unblock: systemd/241-4

2019-05-26 Thread Michael Biebl

Am 20.05.19 um 14:06 schrieb Michael Biebl:
> Am 19.05.19 um 12:47 schrieb Niels Thykier:
> 
>>>   * Add check to switch VTs only between K_XLATE or K_UNICODE.
>>> Switching to K_UNICODE from other than L_XLATE can make the keyboard
>>> unusable and possibly leak keypresses from X.
>>> (CVE-2018-20839, Closes: #929116)
>>>
>>> https://salsa.debian.org/systemd-team/systemd/commit/5a564c6ef3906c0f3885a3a2aafce772393f760a
> 
> In the mean time a regression was reported caused by this patch.
> I marked the bug as RC. Given how long it takes to find a solution
> upstream, I will either upload a fix for that or revert/drop the patch
> again.

I've reverted this patch in 241-5, as no fix is available yet.
No other changes were made in 241-5.

Regards,
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#929577: lintian: Please keep the version in buster up to date

2019-05-26 Thread Chris Lamb

tags 929577 + wishlist
retitle 929577 lintian: Please keep the version in buster up to date
thanks

Hi Mattia,

> I know that most of your changes don't respect the freeze policy, but
> given that on February the release team granted an exception, maybe they
> will again.

(Just for clarity, I personally didn't file/request these.)(

> Also, regardless of whatever the backports master grant, please do try
> to end up with a proper upgrade path from stretch-bpo to the final
> buster.

ACK, will file an unblock for the 2.15.0 in a few days assuming it
doesn't blow up horribly. Beyond using the version number mathematics
work, were you thinking of anything else here?


Regards,

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

Bug#929495: libpam-tmpdir: too strict permissions on /tmp/user may lead to errors in other programs

2019-05-26 Thread Tollef Fog Heen

]] Andrey Bondarenko 

> pam_tmpdir creates /tmp/user with strict permissions (drwx--x--x root:root)
> Some programs report unwanted permission denied errors while walking from 
> temporary file in $TMP to /. For example error appears in gwenview.

That sounds like a bug in gwenview; why would it try to walk the tree?

> Is there are good reason for removing world readable permissions from 
> /tmp/user
> by default? If defaults cannot be changed, is it possible to make it 
> configurable
> option so local administrator can decide what permissions use for /tmp/user?

If you precreate the directory before pam_tmpdir is invoked, the
permissions aren't changed.  Note that  o+r is fine, but o+w is not and
will lead to PAM failures, so you probably want to make pam_tmpdir as
optional while playing around.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#929597: CVE-2019-12211 CVE-2019-12212 CVE-2019-12213 CVE-2019-12214

2019-05-26 Thread Moritz Muehlenhoff

Source: freeimage
Severity: grave
Tags: security

Please see
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-12211
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-12212
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-12213
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-12214

Cheers,
Moritz

Bug#928444: fixed in jetty9 9.4.18-1

2019-05-26 Thread Moritz Mühlenhoff

On Mon, May 06, 2019 at 04:19:33AM +, tony mancill wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> Format: 1.8
> Date: Sun, 05 May 2019 19:57:45 -0700
> Source: jetty9
> Architecture: source
> Version: 9.4.18-1
> Distribution: experimental
> Urgency: medium
> Maintainer: Debian Java Maintainers 
> 
> Changed-By: tony mancill 
> Closes: 928444
> Changes:
>  jetty9 (9.4.18-1) experimental; urgency=medium
>  .
>* Team upload.
>* New upstream release
>  - Addresses CVE-2019-10241, CVE-2019-10247 (Closes: #928444)

What's the plan for unstable/buster?

Cheers,
Moritz

Bug#928054: CVE-2019-11461

2019-05-26 Thread Moritz Mühlenhoff

On Fri, Apr 26, 2019 at 11:14:28PM +0200, Moritz Muehlenhoff wrote:
> Source: nautilus
> Severity: important
> Tags: security
> 
> http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-11461

This is fixed in 
https://gitlab.gnome.org/GNOME/nautilus/commit/2ddba428ef2b13d0620bd599c3635b9c11044659
Can we please get that fixed for buster?

Cheers,
Moritz

Bug#927674: CVE-2019-3902

2019-05-26 Thread Moritz Mühlenhoff

On Sun, Apr 21, 2019 at 12:32:13AM +0200, Moritz Muehlenhoff wrote:
> Source: mercurial
> Version: 4.8.2-1
> Severity: grave
> Tags: security
> 
> See https://www.mercurial-scm.org/wiki/WhatsNew from 4.9:
> 
> This was assigned CVE-2019-3902:
> It was possible to use symlinks and subrepositories to defeat Mercurial's 
> path-checking
> logic and write files outside a repository. This has been fixed. Users on 
> older versions
> can either disable subrepositories with [subrepos] allowed=false in their 
> configuration
> or by ensuring any cloned repositories don't contain malicious symlinks.
> 
> This is fixed in sid, but buster still has 4.8.2.

A month later this is still unfixed in buster. Does anyone care about having 
this
in a stable release? Probably not, because noone cared about stretch already 
either:
https://security-tracker.debian.org/tracker/source-package/mercurial

If that's the case, let's drop it from buster?

Cheers,
 Moritz

Bug#929595: kconfigwidgets FTCBFS: missing Build-Depends: qttools5-dev

2019-05-26 Thread Helmut Grohne

Source: kconfigwidgets
Version: 5.54.0-1
Tags: pending

kconfigwidgets fails to cross build from source. This is fixed in git:
https://salsa.debian.org/qt-kde-team/kde/kconfigwidgets/commit/af281c075dc102ac758ff5faac9abe57a795527e
Please close this bug with the next upload to trigger a qa rebuild.

Helmut

Bug#929596: unblock: firefox-esr/60.7.0esr-1

2019-05-26 Thread Moritz Muehlenhoff

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

Please unblock package firefox-esr. It's the latest ESR security release.

unblock firefox-esr/60.7.0esr-1

Cheers,
Moritz

Bug#929283: zookeeper: CVE-2019-0201: information disclosure vulnerability

2019-05-26 Thread Moritz Mühlenhoff

On Fri, May 24, 2019 at 09:19:00AM +0100, Chris Lamb wrote:
> tags 929283 + patch
> thanks
> 
> Hi Moritz,
> 
> > > > zookeeper: CVE-2019-0201: information disclosure vulnerability
> > > 
> > > Happy to prepare an update for stretch; I plan to do one for jessie
> > > LTS (which, helpfully, has the same version...)
> > 
> > Sounds good, we should fix that in Stretch. I've just added the reference
> > to the upstream commit in the 3.4 branch to the Security Tracker.
> 
> Thanks. Here is my diff:

Looks fine, but can you please also include the test case upstream added?
Given that it's quite complex to reconstruct the specific affected ZK setup,
we should at least ship/run the test case.

Cheers,
Moritz

Bug#929594: kcrash FTCBFS: missing Build-Depends: qttools5-dev

2019-05-26 Thread Helmut Grohne

Package: kcrash
Version: 5.54.0-1
Tags: pending

kcrash fails to cross build from source. This is fixed in git:
https://salsa.debian.org/qt-kde-team/kde/kcrash/commit/00c0d14bd14c5e71b35118fcda4043fda1d9d7b9
Please close this bug with the next upload to trigger a qa rebuild.

Helmut

Bug#929521: Conficts in upgrade to 418.74-1 with optimus setup

2019-05-26 Thread Luca Boccassi

Control: reassign 929525 src:nvidia-graphics-drivers 418.74-1
Control: forcemerge 929521 929525

On Sat, 2019-05-25 at 15:54 +0200, ghisv...@gmail.com wrote:
> Package: src:nvidia-graphics-drivers
> Version: 418.74-1
> Severity: important
> 
> Dear Debian NVIDIA maintainers,
> 
> I attempted to upgrade my laptop (a Dell Inspiron 7580 with a GeForce
> MX150) running Debian Buster and configured with nvidia-driver,
> bumblebee-nvidia and primus, plus the necessary 32-bit libs to run
> Steam. So far, upgrades have been smooth until version 418.56-2.
> 
> Sadly, version 418.74-1 is a different story. Running `apt upgrade`
> shows the following output:
> 
> ```
> Les paquets suivants contiennent des dépendances non satisfaites :
>  nvidia-nonglvnd-vulkan-common : Est en conflit avec: libgl1-nvidia-
> legacy-390xx-glvnd-glx mais 390.116-1 devra être installé
>  Est en conflit avec: libgl1-nvidia-
> legacy-390xx-glvnd-glx:i386 mais 390.116-1 devra être installé
>  primus : Casse: libgl1-nvidia-legacy-390xx-glvnd-glx (>= 0) mais
> 390.116-1 devra être installé
>   Casse: libgl1-nvidia-legacy-390xx-glvnd-glx:i386 (>= 0)
> mais
> 390.116-1 devra être installé
> ```
> 
> Which indicates conflicts for nvidia-nonglvnd-vulkan-common and
> breakage
> for Primus. What surprises me is the upgrade wishing to pull part of
> the
> legacy nvidia driver, whilst I am definitely using the current one.
> 
> I have also tried to just remove the whole NVIDIA stack and start
> over
> as when I initially setup the machine. Running `apt get install
> bumblebee-nvidia` shows the following output :
> 
> ```
> Les paquets suivants ont été installés automatiquement et ne sont
> plus
> nécessaires :
>   libegl-mesa0:i386 libegl1:i386 libgbm1:i386 libopengl0
> libopengl0:i386 libwayland-server0:i386 libxcb-xfixes0:i386 nvidia-
> egl-
> common nvidia-egl-icd nvidia-egl-icd:i386
> Veuillez utiliser « sudo apt autoremove » pour les supprimer.
> Les paquets supplémentaires suivants seront installés :
>   bbswitch-dkms bumblebee libegl-nvidia-legacy-390xx0:i386 libegl1-
> nvidia libegl1-nvidia:i386 libegl1-nvidia-legacy-390xx:i386 libgl1-
> nvidia-glx libgl1-nvidia-glx:i386 libgl1-nvidia-legacy-390xx-glx:i386
>   libgles-nvidia-legacy-390xx1:i386 libgles-nvidia-legacy-390xx2:i386
> libglx-nvidia-legacy-390xx0:i386 libnvidia-legacy-390xx-cfg1
> libnvidia-
> legacy-390xx-cfg1:i386 libnvidia-legacy-390xx-eglcore:i386
>   libnvidia-legacy-390xx-glcore libnvidia-legacy-390xx-glcore:i386
> libnvidia-legacy-390xx-ml1 nvidia-driver-libs-nonglvnd nvidia-driver-
> libs-nonglvnd:i386 nvidia-driver-libs-nonglvnd-i386:i386
>   nvidia-legacy-390xx-alternative nvidia-legacy-390xx-driver-libs-
> nonglvnd:i386 nvidia-legacy-390xx-kernel-dkms nvidia-legacy-390xx-
> kernel-support nvidia-legacy-390xx-nonglvnd-vulkan-icd:i386
>   nvidia-legacy-390xx-vdpau-driver nvidia-nonglvnd-vulkan-common
> nvidia-nonglvnd-vulkan-icd nvidia-nonglvnd-vulkan-icd:i386 nvidia-
> settings-legacy-390xx primus primus-libs primus-libs-ia32:i386 socat
>   xserver-xorg-video-nvidia-legacy-390xx
> Paquets suggérés :
>   vulkan-utils:i386 vulkan-utils
> Paquets recommandés :
>   nvidia-legacy-390xx-driver | libnvidia-legacy-390xx-cuda1 libgl1-
> nvidia-legacy-390xx-glvnd-glx | libgl1-nvidia-legacy-390xx-glx
> nvidia-
> legacy-390xx-driver
> Les paquets suivants seront ENLEVÉS :
>   libgl1-nvidia-glvnd-glx libgl1-nvidia-glvnd-glx:i386 nvidia-driver-
> libs nvidia-driver-libs:i386 nvidia-driver-libs-i386:i386 nvidia-
> vulkan-common nvidia-vulkan-icd nvidia-vulkan-icd:i386
> Les NOUVEAUX paquets suivants seront installés :
>   bbswitch-dkms bumblebee bumblebee-nvidia libegl-nvidia-legacy-
> 390xx0:i386 libegl1-nvidia libegl1-nvidia:i386 libegl1-nvidia-legacy-
> 390xx:i386 libgl1-nvidia-glx libgl1-nvidia-glx:i386
>   libgl1-nvidia-legacy-390xx-glx:i386 libgles-nvidia-legacy-
> 390xx1:i386 
> libgles-nvidia-legacy-390xx2:i386 libglx-nvidia-legacy-390xx0:i386
> libnvidia-legacy-390xx-cfg1 libnvidia-legacy-390xx-cfg1:i386
>   libnvidia-legacy-390xx-eglcore:i386 libnvidia-legacy-390xx-glcore
> libnvidia-legacy-390xx-glcore:i386 libnvidia-legacy-390xx-ml1 nvidia-
> driver-libs-nonglvnd nvidia-driver-libs-nonglvnd:i386
>   nvidia-driver-libs-nonglvnd-i386:i386 nvidia-legacy-390xx-
> alternative 
> nvidia-legacy-390xx-driver-libs-nonglvnd:i386 nvidia-legacy-390xx-
> kernel-dkms nvidia-legacy-390xx-kernel-support
>   nvidia-legacy-390xx-nonglvnd-vulkan-icd:i386 nvidia-legacy-390xx-
> vdpau-driver nvidia-nonglvnd-vulkan-common nvidia-nonglvnd-vulkan-icd
> nvidia-nonglvnd-vulkan-icd:i386 nvidia-settings-legacy-390xx primus
>   primus-libs primus-libs-ia32:i386 socat xserver-xorg-video-nvidia-
> legacy-390xx
> 0 mis à jour, 37 nouvellement installés, 8 à enlever et 0 non mis à
> jour.
> ```
> 
> Once again, it is very suprising that apt now wants to install all
> these
> legacy nvidia driver packages, yet even remove `nvidia-driver-libs`.
> 
> Looking at the change

Bug#929593: RFP: pistache -- elegant C++ REST framework

2019-05-26 Thread Kip Warner

Package: wnpp
Severity: wishlist

* Package name: pistache
  Version : 0.0.001
  Upstream Author : Dennis Jenkins 
* URL : https://www.github.com/oktal/pistache
* License : Apache-2.0
  Programming Lang: (C++)
  Description : elegant C++ REST framework

Pistache is a C++ REST framework originally written by Mathieu Stefani at
Datacratic, since maintained by other volunteers. It is written in pure C++11
with no external dependency and provides a low-level HTTP abstraction. Pistache
provides both an HTTP client and server that can be used to create and query
complex web and REST APIs.

It is free as in freedom and released under the Apache 2.0 license.

It should build the following packages:

libpistache0 - runtime library
libpistache-dev - C++ development headers

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



Upstream has already provided partial Debianization for user convenience via a
stable and unstable PPA, but we are not DPM subject matter experts and would
like to see the project enter the official Debian repositories so everyone can
use it.

Our current users increase daily and vary from hobbyist router firmware hackers
to large fintech firms and the commercial music space.

Bug#855198: Fwd: Bug#855198: Adding i386 support

2019-05-26 Thread David Bremner

Ignacio Losiggio  writes:

>>Why is an i386 package only usable if compiled with sse2 instructions?
>>If you are targeting post-2003 computers, why aren't you using an amd64
>>build anyway?
>
> Lots of x86_64 machines run x86 systems due to low RAM availability, they
> are 2010 Atom netbooks, etc.
>
> For the low RAM ones i think that currently debian x32 it's not an option
> if you aren't a power user.

I stumbled across this bug because of an (unrelated) question about
obs-studio on #debian. It might be ok to use sse2 instructions if you
also also depend on the package sse2-support (although this is a bit
unsettled at the moment). It's definitely not OK if the resulting
package installs and crashes (or malfunctions) on i386 w/o SSE2.

d

Bug#929592: RFA: qelectrotech -- Electric schematic editor

2019-05-26 Thread Denis Briand

Package: wnpp
Severity: normal

Hello,
I'm no longer interested to maintain this package.
I'm more involved in Debian France Organization now and I haven't enought free 
time to maintain it correctly.
Qeletrotech needs a maintainer with Qt5 and C++ knowledges.

QElectroTech is a Qt5 application written in C++ to design electric diagrams.
It includes a diagram editor and a symbol editor. It uses XML files to store 
the produced contents.
Homepage: http://qelectrotech.org


Denis Briand


signature.asc
Description: PGP signature

Bug#929216: RM: algotutor/0.8.6-2

2019-05-26 Thread pk

Hi,

I am using algotutor on Buster with my home as working directory and
do not experience the reported issue. algotutor is 0.8.6-2. Here is
the terminal output:

$ algotutor
Use of uninitialized value $opts{"a"} in string eq at
/usr/share/algotutor/algotutor line 34.
Use of uninitialized value $opts{"a"} in string eq at
/usr/share/algotutor/algotutor line 34.
Use of uninitialized value $opts{"a"} in string eq at
/usr/share/algotutor/algotutor line 34.
need exactly one data file. Example:
algotutor -a bst /usr/share/algotutor/data/countries.gr
$ algotutor -a bst /usr/share/algotutor/data/countries.gr
total marks: 184
seeking to step 0...

Bug#929591: unblock: golang-github-seccomp-libseccomp-golang/0.9.0-2

2019-05-26 Thread Shengjing Zhu

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
 X-Debbugs-CC: Michael Vogt 

Please unblock package golang-github-seccomp-libseccomp-golang

unblock golang-github-seccomp-libseccomp-golang/0.9.0-2

When I look the diff of unstable and testing of Go packages, I think
this could not be reverted. The changes are small and only contain bug
fix.

diff -Nru golang-github-seccomp-libseccomp-golang-0.9.0/debian/changelog 
golang-github-seccomp-libseccomp-golang-0.9.0/debian/changelog
--- golang-github-seccomp-libseccomp-golang-0.9.0/debian/changelog  
2017-08-09 06:22:22.0 +0800
+++ golang-github-seccomp-libseccomp-golang-0.9.0/debian/changelog  
2019-04-30 15:29:24.0 +0800
@@ -1,3 +1,15 @@
+golang-github-seccomp-libseccomp-golang (0.9.0-2) unstable; urgency=medium
+
+  [ Alexandre Viau ]
+  * Point Vcs-* urls to salsa.debian.org.
+
+  [ Michael Vogt ]
+  * debian/patches/06e7a2-fix-multi-args.patch:
+- Cherry pick 06e7a29 to fix incorrect argument filtering when
+  using multiple arguments
+
+ -- Michael Vogt   Tue, 30 Apr 2019 09:29:24 +0200
+
 golang-github-seccomp-libseccomp-golang (0.9.0-1) unstable; urgency=medium
 
   [ Team upload ]
diff -Nru golang-github-seccomp-libseccomp-golang-0.9.0/debian/control 
golang-github-seccomp-libseccomp-golang-0.9.0/debian/control
--- golang-github-seccomp-libseccomp-golang-0.9.0/debian/control
2017-08-09 06:22:22.0 +0800
+++ golang-github-seccomp-libseccomp-golang-0.9.0/debian/control
2019-04-30 15:29:24.0 +0800
@@ -6,8 +6,8 @@
 Build-Depends: debhelper (>= 9), dh-golang, golang-any, libseccomp-dev, 
pkg-config
 Standards-Version: 3.9.8
 Homepage: https://github.com/seccomp/libseccomp-golang
-Vcs-Browser: 
https://anonscm.debian.org/cgit/pkg-go/packages/golang-github-seccomp-libseccomp-golang.git
-Vcs-Git: 
https://anonscm.debian.org/git/pkg-go/packages/golang-github-seccomp-libseccomp-golang.git
+Vcs-Browser: 
https://salsa.debian.org/go-team/packages/golang-github-seccomp-libseccomp-golang
+Vcs-Git: 
https://salsa.debian.org/go-team/packages/golang-github-seccomp-libseccomp-golang.git
 XS-Go-Import-Path: github.com/seccomp/libseccomp-golang
 
 Package: golang-github-seccomp-libseccomp-golang-dev
diff -Nru golang-github-seccomp-libseccomp-golang-0.9.0/debian/gitlab-ci.yml 
golang-github-seccomp-libseccomp-golang-0.9.0/debian/gitlab-ci.yml
--- golang-github-seccomp-libseccomp-golang-0.9.0/debian/gitlab-ci.yml  
1970-01-01 08:00:00.0 +0800
+++ golang-github-seccomp-libseccomp-golang-0.9.0/debian/gitlab-ci.yml  
2019-04-30 15:29:24.0 +0800
[omitted]
diff -Nru 
golang-github-seccomp-libseccomp-golang-0.9.0/debian/patches/06e7a2-fix-multi-args.patch
 
golang-github-seccomp-libseccomp-golang-0.9.0/debian/patches/06e7a2-fix-multi-args.patch
--- 
golang-github-seccomp-libseccomp-golang-0.9.0/debian/patches/06e7a2-fix-multi-args.patch
1970-01-01 08:00:00.0 +0800
+++ 
golang-github-seccomp-libseccomp-golang-0.9.0/debian/patches/06e7a2-fix-multi-args.patch
2019-04-30 15:29:24.0 +0800
@@ -0,0 +1,123 @@
+commit 06e7a29f36a34b8cf419aeb87b979ee508e58f9e
+Author: Matthew Heon 
+Date:   Wed Apr 19 16:28:29 2017 -0400
+
+golang: Resolve bug with handling of multiple argument rules
+
+In the upstream library, when added with a single API call,
+multiple syscall argument rules should be matched with AND
+logic - if all of them match, the rule matches.
+
+At present, the Golang bindings apply OR logic to this case.
+This commit resolves this and reverts to the behavior of the
+main library.
+
+Signed-off-by: Matthew Heon 
+
+diff --git a/seccomp_internal.go b/seccomp_internal.go
+index c9fd616..369f194 100644
+--- a/seccomp_internal.go
 b/seccomp_internal.go
+@@ -120,23 +120,27 @@ unsigned int get_micro_version()
+ 
+ typedef struct scmp_arg_cmp* scmp_cast_t;
+ 
+-// Wrapper to create an scmp_arg_cmp struct
+-void*
+-make_struct_arg_cmp(
+-unsigned int arg,
+-int compare,
+-uint64_t a,
+-uint64_t b
+-   )
++void* make_arg_cmp_array(unsigned int length)
+ {
+-  struct scmp_arg_cmp *s = malloc(sizeof(struct scmp_arg_cmp));
++return calloc(length, sizeof(struct scmp_arg_cmp));
++}
+ 
+-  s->arg = arg;
+-  s->op = compare;
+-  s->datum_a = a;
+-  s->datum_b = b;
++// Wrapper to add an scmp_arg_cmp struct to an existing arg_cmp array
++void add_struct_arg_cmp(
++struct scmp_arg_cmp* arr,
++unsigned int pos,
++unsigned int arg,
++int compare,
++uint64_t a,
++uint64_t b
++   )
++{
++arr[pos].arg = arg;
++arr[pos].op = compare;
++arr[pos].datum_a = a;
++arr[pos].datum_b = b;
+

Bug#929590: lagan FTCBFS: insane upstream build system

2019-05-26 Thread Helmut Grohne

Source: lagan
Version: 2.0-3
Tags: patch upstream
User: helm...@debian.org
Usertags: rebootstrap

lagan fails to cross build from source. The upstream build system is
quite strange. It stuffs CFLAGS into variables such as CC and CXX, which
dh_auto_build overrides. Thus CFLAGS go missing. It also stores a C++
compiler in CC. The attached patch makes these variables behave as one
would expect. Please consider applying the attached patch.

Helmut
--- lagan-2.0.orig/src/Makefile
+++ lagan-2.0/src/Makefile
@@ -1,5 +1,5 @@
-CC = gcc $(CFLAGS)
-CPP = g++ $(CFLAGS)
+CC = gcc
+CXX = g++
 CFLAGS += -O3 # -Wall -W
 TRGT_DIR = ..
 
@@ -9,46 +9,46 @@
 	rm -f *.o *~ utils/*~ mlagan.purify core
 	(cd glocal; $(MAKE) clean)
 ../anchors: anchors.c skiplist.c
-	$(CC) -o $(TRGT_DIR)/anchors anchors.c skiplist.c $(LDFLAGS)
+	$(CC) $(CFLAGS) -o $(TRGT_DIR)/anchors anchors.c skiplist.c $(LDFLAGS)
 ../chaos: fchaos.c thrtrie.c skiplist.c global.c translate.c mempage.c filebuffer.c
-	$(CC) -o $(TRGT_DIR)/chaos fchaos.c thrtrie.c skiplist.c global.c translate.c filebuffer.c -lm -DCHAOS__FLAG $(LDFLAGS)
+	$(CC) $(CFLAGS) -o $(TRGT_DIR)/chaos fchaos.c thrtrie.c skiplist.c global.c translate.c filebuffer.c -lm -DCHAOS__FLAG $(LDFLAGS)
 ../order: order.c diagmatrix.c filebuffer.c
-	$(CC) -o $(TRGT_DIR)/order order.c diagmatrix.c filebuffer.c $(LDFLAGS)
+	$(CC) $(CFLAGS) -o $(TRGT_DIR)/order order.c diagmatrix.c filebuffer.c $(LDFLAGS)
 ../mlagan: mlagan.c diagmatrix.c multial.c skiplist.c filebuffer.c
-	$(CC) -o $(TRGT_DIR)/mlagan mlagan.c multial.c diagmatrix.c skiplist.c filebuffer.c -lm -DMULTIAL__FLAG $(LDFLAGS)
+	$(CC) $(CFLAGS) -o $(TRGT_DIR)/mlagan mlagan.c multial.c diagmatrix.c skiplist.c filebuffer.c -lm -DMULTIAL__FLAG $(LDFLAGS)
 ../prolagan: prolagan.c diagmatrix.c multial.c skiplist.c filebuffer.c
-	$(CC) -o $(TRGT_DIR)/prolagan prolagan.c multial.c diagmatrix.c skiplist.c filebuffer.c -lm -DMULTIAL__FLAG $(LDFLAGS)
+	$(CC) $(CFLAGS) -o $(TRGT_DIR)/prolagan prolagan.c multial.c diagmatrix.c skiplist.c filebuffer.c -lm -DMULTIAL__FLAG $(LDFLAGS)
 ../utils/bin2mf: utils/bin2mf.c
-	$(CC) -o $(TRGT_DIR)/utils/bin2mf utils/bin2mf.c $(LDFLAGS)
+	$(CC) $(CFLAGS) -o $(TRGT_DIR)/utils/bin2mf utils/bin2mf.c $(LDFLAGS)
 ../utils/bin2bl: utils/bin2bl.c
-	$(CC) -o $(TRGT_DIR)/utils/bin2bl utils/bin2bl.c $(LDFLAGS)
+	$(CC) $(CFLAGS) -o $(TRGT_DIR)/utils/bin2bl utils/bin2bl.c $(LDFLAGS)
 ../utils/cextract: utils/cextract.c
-	$(CC) -o $(TRGT_DIR)/utils/cextract utils/cextract.c $(LDFLAGS)
+	$(CC) $(CFLAGS) -o $(TRGT_DIR)/utils/cextract utils/cextract.c $(LDFLAGS)
 ../utils/cstat: utils/cstat.c
-	$(CC) -o $(TRGT_DIR)/utils/cstat utils/cstat.c $(LDFLAGS)
+	$(CC) $(CFLAGS) -o $(TRGT_DIR)/utils/cstat utils/cstat.c $(LDFLAGS)
 ../utils/contigorder: utils/contigorder.c
-	$(CC) -o $(TRGT_DIR)/utils/contigorder utils/contigorder.c $(LDFLAGS)
+	$(CC) $(CFLAGS) -o $(TRGT_DIR)/utils/contigorder utils/contigorder.c $(LDFLAGS)
 ../utils/getbounds: utils/getbounds.c
-	$(CC) -o $(TRGT_DIR)/utils/getbounds utils/getbounds.c $(LDFLAGS)
+	$(CC) $(CFLAGS) -o $(TRGT_DIR)/utils/getbounds utils/getbounds.c $(LDFLAGS)
 ../utils/getcontigpos: utils/getcontigpos.c
-	$(CC) -o $(TRGT_DIR)/utils/getcontigpos utils/getcontigpos.c $(LDFLAGS)
+	$(CC) $(CFLAGS) -o $(TRGT_DIR)/utils/getcontigpos utils/getcontigpos.c $(LDFLAGS)
 ../utils/getlength: utils/getlength.c
-	$(CC) -o $(TRGT_DIR)/utils/getlength utils/getlength.c $(LDFLAGS)
+	$(CC) $(CFLAGS) -o $(TRGT_DIR)/utils/getlength utils/getlength.c $(LDFLAGS)
 ../utils/getoverlap: utils/getoverlap.c
-	$(CC) -o $(TRGT_DIR)/utils/getoverlap utils/getoverlap.c $(LDFLAGS)
+	$(CC) $(CFLAGS) -o $(TRGT_DIR)/utils/getoverlap utils/getoverlap.c $(LDFLAGS)
 ../utils/rc: utils/rc.c
-	$(CC) -o $(TRGT_DIR)/utils/rc utils/rc.c $(LDFLAGS)
+	$(CC) $(CFLAGS) -o $(TRGT_DIR)/utils/rc utils/rc.c $(LDFLAGS)
 ../utils/seqmerge: utils/seqmerge.c
-	$(CC) -o $(TRGT_DIR)/utils/seqmerge utils/seqmerge.c $(LDFLAGS)
+	$(CC) $(CFLAGS) -o $(TRGT_DIR)/utils/seqmerge utils/seqmerge.c $(LDFLAGS)
 ../utils/scorealign: utils/scorealign.c
-	$(CC) -o $(TRGT_DIR)/utils/scorealign utils/scorealign.c -lm $(LDFLAGS)
+	$(CC) $(CFLAGS) -o $(TRGT_DIR)/utils/scorealign utils/scorealign.c -lm $(LDFLAGS)
 ../utils/scorecontigs: utils/scorecontigs.c
-	$(CC) -o $(TRGT_DIR)/utils/scorecontigs utils/scorecontigs.c -lm $(LDFLAGS)
+	$(CC) $(CFLAGS) -o $(TRGT_DIR)/utils/scorecontigs utils/scorecontigs.c -lm $(LDFLAGS)
 ../utils/fa2xfa: utils/fa2xfa.c
-	$(CC) -o $(TRGT_DIR)/utils/fa2xfa utils/fa2xfa.c $(LDFLAGS)
+	$(CC) $(CFLAGS) -o $(TRGT_DIR)/utils/fa2xfa utils/fa2xfa.c $(LDFLAGS)
 ../utils/overlay: utils/overlay.c
-	$(CC) -o $(TRGT_DIR)/utils/overlay utils/overlay.c $(LDFLAGS)
+	$(CC) $(CFLAGS) -o $(TRGT_DIR)/utils/overlay utils/overlay.c $(LDFLAGS)
 ../utils/Glue: utils/Glue.cpp
-	$(CPP) -o $(TRGT_DIR)/utils/Glue utils/Glue.cpp $(LDFLAGS)
+	$(CXX) $(CFLAGS) -o $(TRGT_DIR)/utils/Glue utils/Glue.cpp $(LDFLAGS)
 ../utils/dotplot: utils/dotplot.cpp
-	$(CPP) -o

Bug#929589: twofish FTCBFS: builds for the build architecture

2019-05-26 Thread Helmut Grohne

Source: twofish
Version: 0.3-5
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

twofish fails to cross build from source, because debian/rules hard
codes the build architecture compiler. The host compiler is best
obtained from dpkg's buildtools.mk. After doing so, twofish fails
running its tests despite DEB_BUILD_OPTIONS=nocheck. The attached patch
fixes both. Please consider applying it.

Helmut
diff --minimal -Nru twofish-0.3/debian/changelog twofish-0.3/debian/changelog
--- twofish-0.3/debian/changelog2016-05-07 12:27:19.0 +0200
+++ twofish-0.3/debian/changelog2019-05-26 17:16:32.0 +0200
@@ -1,3 +1,12 @@
+twofish (0.3-5.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: (Closes: #-1)
++ Use $(CC) from dpkg's buildtools.mk.
++ Support DEB_BUILD_OPTIONS=nocheck.
+
+ -- Helmut Grohne   Sun, 26 May 2019 17:16:32 +0200
+
 twofish (0.3-5) unstable; urgency=low
 
   * Step Standards-Version to 3.9.8, no changes.
diff --minimal -Nru twofish-0.3/debian/rules twofish-0.3/debian/rules
--- twofish-0.3/debian/rules2016-05-07 10:44:38.0 +0200
+++ twofish-0.3/debian/rules2019-05-26 17:16:32.0 +0200
@@ -1,6 +1,7 @@
 #!/usr/bin/make -f
 # Debian package build rules file for twofish
 
+-include /usr/share/dpkg/buildtools.mk
 CFLAGS  = $(shell dpkg-buildflags --get CFLAGS) -Wall -Wextra
 CPPFLAGS = $(shell dpkg-buildflags --get CPPFLAGS)
 LDFLAGS = $(shell dpkg-buildflags --get LDFLAGS) -Wl,-z,now
@@ -26,17 +27,19 @@
 build-arch-stamp:
dh_testdir
#
-   gcc -c -o twofish.o $(CPPFLAGS) $(CFLAGS) twofish.c
+   $(CC) -c -o twofish.o $(CPPFLAGS) $(CFLAGS) twofish.c
ar clq $(ANAME) twofish.o
ranlib $(ANAME)
# Shared library
-rm twofish.o
-   gcc $(CPPFLAGS) $(CFLAGS) -fPIC -shared -Wl,-soname,$(SONAME) \
+   $(CC) $(CPPFLAGS) $(CFLAGS) -fPIC -shared -Wl,-soname,$(SONAME) \
$(LDFLAGS) -Wl,-z,defs -lc -o $(SONAME) twofish.c
#
# test suite
-   gcc -o twofishtest $(CPPFLAGS) $(CFLAGS) main.c $(LDFLAGS) -L. 
$(ALINKING)
+ifeq (,$(filter nocheck,$(DEB_BUILD_OPTIONS)))
+   $(CC) -o twofishtest $(CPPFLAGS) $(CFLAGS) main.c $(LDFLAGS) -L. 
$(ALINKING)
./twofishtest
+endif
touch build-arch-stamp
 
 clean:

Bug#929588: lsat missing source for configure

2019-05-26 Thread Helmut Grohne

Source: lsat
Version: 0.9.7.1-2.2
Severity: serious
Justification: DFSG #2

The lsat source package is missing the source code for the file
./configure. That file identifies itself as being generated using
autoconf. The source tarball does not contain any corresponding source.
This is a DFSG #2 violation and thus justifies severity serious.

Helmut

Bug#929586: critterding FTCBFS: does not pass --host to ./configure

2019-05-26 Thread Helmut Grohne

Source: critterding
Version: 1.0-beta12.1-1.3
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

critterding fails to cross build from source, because it does not pass
--host to ./configure. The easiest way of doing so - using
dh_auto_configure - makes critterding cross buildable. Please consider
applying the attached patch.

Helmut
diff --minimal -Nru critterding-1.0-beta12.1/debian/changelog 
critterding-1.0-beta12.1/debian/changelog
--- critterding-1.0-beta12.1/debian/changelog   2016-07-17 23:11:02.0 
+0200
+++ critterding-1.0-beta12.1/debian/changelog   2019-05-26 20:03:26.0 
+0200
@@ -1,3 +1,10 @@
+critterding (1.0-beta12.1-1.4) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Let dh_auto_configure pass --host to ./configure. (Closes: #-1)
+
+ -- Helmut Grohne   Sun, 26 May 2019 20:03:26 +0200
+
 critterding (1.0-beta12.1-1.3) unstable; urgency=medium
 
   * Non-maintainer upload.
diff --minimal -Nru critterding-1.0-beta12.1/debian/rules 
critterding-1.0-beta12.1/debian/rules
--- critterding-1.0-beta12.1/debian/rules   2010-03-16 23:09:02.0 
+0100
+++ critterding-1.0-beta12.1/debian/rules   2019-05-26 20:03:22.0 
+0200
@@ -7,7 +7,7 @@
 
 override_dh_auto_build:
autoreconf -fi
-   ./configure --prefix=/usr
+   dh_auto_configure
 
 override_dh_auto_install:
dh_auto_install

Bug#929587: rsh-redone FTCBFS: does not pass cross tools to make

2019-05-26 Thread Helmut Grohne

Source: rsh-redone
Version: 85-2
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

rsh-redone fails to cross build from source, because it does not pass
cross tools to make. The easiest way of doing so - using dh_auto_build -
makes rsh-redone cross buildable. Please consider applying the attached
patch.

Helmut
diff -u rsh-redone-85/debian/changelog rsh-redone-85/debian/changelog
--- rsh-redone-85/debian/changelog
+++ rsh-redone-85/debian/changelog
@@ -1,3 +1,10 @@
+rsh-redone (85-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Let dh_auto_build pass cross tools to make. (Closes: #-1)
+
+ -- Helmut Grohne   Sun, 26 May 2019 19:30:43 +0200
+
 rsh-redone (85-2) unstable; urgency=low
 
   * Bump Standards-Version.
diff -u rsh-redone-85/debian/rules rsh-redone-85/debian/rules
--- rsh-redone-85/debian/rules
+++ rsh-redone-85/debian/rules
@@ -27,9 +27,7 @@
 
 build-arch: build-arch-stamp
 build-arch-stamp: configure-stamp 
-   
-   # Add here commands to compile the arch part of the package.
-   $(MAKE) 
+   dh_auto_build
 
 build-indep: build-indep-stamp
 build-indep-stamp: configure-stamp

Bug#929511: qtcreator: Segfault on start

2019-05-26 Thread Alexander Kernozhitsky

IMHO the problem here can be using a very outdated libLLVM version (which is 
even not in unstable). The things I don't understand are:

1) Why Qt Creator is still using this old version? According to the stack 
trace, 
libLLVM 7 is triggered, but then it starts calling functions from an older 
library
2) Why this version is still in use and cannot be automatically removed?

> For some reason unknown to me there are several packages still depending on 
this special version of libLLVM. When I try to remove it, qtcreator is listed 
among 
them. As is xorg - which prevents me from performing the `apt-get remove`.

What is the output of `apt rdepends libllvm3.7`?

-- 
Alexander Kernozhitsky

Bug#929584: Not suitable for buster

2019-05-26 Thread Shengjing Zhu

Source: golang-github-rackspace-gophercloud
Version: 1.0.0+git20160603.920.934dbf8-1
Severity: serious

Please don't ship this package in buster.

There's no {build-,}rdepends in buster, and it's suppressed by
golang-github-gophercloud-gophercloud.

-- 
Shengjing Zhu


signature.asc
Description: PGP signature

Bug#929583: linux-image-5.0.0-trunk-amd64: Please build with CONFIG_ALLOW_LOCKDOWN_LIFT_BY_SYSRQ

2019-05-26 Thread Ben Hutchings

Control: severity -1 important
Control: found -1 4.19.37-3

On Sun, 2019-05-26 at 09:41 -0700, Darsey Litzenberger wrote:
> Package: src:linux
> Version: 5.0.2-1~exp1
> Severity: severe

There's no such severity as "severe", so I'll mark this "important".

> Please build Debian kernels with CONFIG_ALLOW_LOCKDOWN_LIFT_BY_SYSRQ 
> enabled.
[...]

I agree this should be enabled; in fact I thought it already was.

Ben.

-- 
Ben Hutchings
73.46% of all statistics are made up.




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

Bug#929580: lld-7 cannot link large binaries on ppc64le. Please make lld-8 default on ppc64le.

2019-05-26 Thread Shawn Landden

On Sun, May 26, 2019 at 11:53 AM Sylvestre Ledru  wrote:
>
> Hello
>
> Le 26/05/2019 à 18:18, Shawn Landden a écrit :
> > Package: lld
> > Version: 1:7.0-47.1
> > Severity: important
> >
> > Dear Maintainer,
> >
> > If you try to link a largish program with lld-7 on ppc64le you get errors:
> >
> > relocation R_PPC64_REL24 out of range: -15683216 is not in [-8388608, 
> > 8388607]
> >
> > This feature is added in lld-8 and is essential to make the package useful 
> > on this platform.
> >
> > Thus, please make lld-8 default on ppc64el now, insteading of waiting until 
> > it is appropiate for
> > more mature architectures.
> >
> lld-8 won't ship in buster, so, not really a workaround.
>
> A fix could be to disable lld-7 on ppc64el.
If that is the only possibility, then yes that would be preferable to
shipping something that will only cause frustration. ld.gold and
ld.bfd both work.

Bug#929580: lld-7 cannot link large binaries on ppc64le. Please make lld-8 default on ppc64le.

2019-05-26 Thread Sylvestre Ledru


Hello

Le 26/05/2019 à 18:18, Shawn Landden a écrit :

Package: lld
Version: 1:7.0-47.1
Severity: important

Dear Maintainer,

If you try to link a largish program with lld-7 on ppc64le you get errors:

relocation R_PPC64_REL24 out of range: -15683216 is not in [-8388608, 8388607]

This feature is added in lld-8 and is essential to make the package useful on 
this platform.

Thus, please make lld-8 default on ppc64el now, insteading of waiting until it 
is appropiate for
more mature architectures.


lld-8 won't ship in buster, so, not really a workaround.

A fix could be to disable lld-7 on ppc64el.

S

Bug#929557: linux: restore __kernel_fpu needed for zfs for AES-NI/AVX support [mainline not in debian yet]

2019-05-26 Thread Ben Hutchings

Control: tag -1 wontfix

On Sun, 2019-05-26 at 14:00 +0200, Bastian Blank wrote:
> Hi Chris
> 
> On Sat, May 25, 2019 at 10:03:07PM -0400, Chris Zubrzycki wrote:
> > GKH has been purging __kernel_fpu_{begin,end}() from all kernels
> > including LTS (4.19/5) and it's needed for AES-NI/AVX support in the zfs
> > package.
> 
> The commit also tells you why this was done.  Please bring this up to
> upstream and Greg, not to us.
> 
> >Arch Linux has already reverted the offending commit in their
> > distro. Patch available at
> > https://raw.githubusercontent.com/Mic92/nixpkgs/7b77c27caa8617c82df5c5af6b9ce6ae010d7f9a/pkgs/os-specific/linux/kernel/export_kernel_fpu_functions.patch
> 
> How is this change not a copyright violation?

It's reverting an upstream commit that doesn't mention anything about
copyright, but I can see that there was an odd inconsistency of GPL-
only status with the preempt-disabling versions.

If the upstream developers consider a feature to be so low-level that
modules shouldn't need it at all, it implies that "the function is
considered an internal implementation issue", which is the main reason
documented for using EXPORT_SYMBOL_GPL.

Debian tries to avoid breaking changes during a stable release or pre-
release freeze, and I would certainly considering restoring exports in
order to do that.  We even have long-standing patches that add exports
to support modular builds of aufs and some Android drivers.  However,
we defer to the upstream developers by only using EXPORT_SYMBOL_GPL
when we do that - which would not help ZoL.

So I agree with Bastian that you will need to persuade upstream to
change this.

Ben.

-- 
Ben Hutchings
73.46% of all statistics are made up.

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

Bug#929583: linux-image-5.0.0-trunk-amd64: Please build with CONFIG_ALLOW_LOCKDOWN_LIFT_BY_SYSRQ

2019-05-26 Thread Darsey Litzenberger

Package: src:linux
Version: 5.0.2-1~exp1
Severity: severe

Please build Debian kernels with CONFIG_ALLOW_LOCKDOWN_LIFT_BY_SYSRQ 
enabled.

I have a laptop with UEFI Secure Boot support.  I dual-boot Windows and 
I also want to use Secure Boot to make sure that Debian kernels are 
running.  Beyond that, I'd like no restrictions on my own ability to 
develop kernel modules without having to reboot to disable Secure Boot, 
or having to build my own kernels with my own keys and also having to 
figure out how to sign and load kernel modules just to fix bugs.  (It 
also seems dubious to be signing half-finished modules, which haven't 
been vetted for security, during the development process.)

Currently, on systems with Secure Boot enabled, it is difficult or 
impossible to build and load custom kernel modules without disabling 
UEFI Secure Boot entirely.

The ostensible purpose of UEFI Secure boot is to prevent unsigned, 
malicious bootloaders from subverting the operating system without the 
end-user's awareness.  It can also be used by hardware manufacturers to 
lock down machines against users who wish to load their own kernel 
modules, but that purpose is not compatible with Debian's Social 
Contract ("4. Our priorities are our users and free software"), and 
Debian should not be complicit in this.

IMO if Debian is shipping Secure Boot-compatibled signed kernels at all, 
Debian must also provide end-users with the ability to load their own 
kernel-mode code with Secure Boot enabled.  shim, which is signed by 
Microsoft, already allows users to load keys (and thus execute arbitrary 
kernel-mode code) once the user has given their affirmative consent to 
do so.  Nothing should stop Debian from doing likewise, and that's what 
the ALLOW_LOCKDOWN_LIFT_BY_SYSRQ config option does.

The upstream kernel maintainers have expressed opposition to tying UEFI 
Secure Boot to lockdown mode in the first place, and much of the the 
justification for supporting Secure Boot -> Lockdown in a FOSS kernel at 
all has been that this sysrq key combination would be available to 
users.  Currently, this is not the case in Debian signed kernels.

Since buster reportedly will ship signed kernels, and since I believe 
the status quo violates the Social Contract (and that it would be a 
shame if buster shipped in a form that allowed Debian-signed kernels to 
be used to help hardware manufacturers assert control over end-users 
restrict users on their own hardware), I have marked this bug with a 
release-critical severity.

-- Package-specific info:
** Version:
Linux version 5.0.0-trunk-amd64 (debian-ker...@lists.debian.org) (gcc version 
8.3.0 (Debian 8.3.0-3)) #1 SMP Debian 5.0.2-1~exp1 (2019-03-18)

** Model information
sys_vendor: LENOVO
product_name: 20MUCTO1WW
product_version: ThinkPad A485
chassis_vendor: LENOVO
chassis_version: None
bios_vendor: LENOVO
bios_version: R0WET48W (1.16 )
board_vendor: LENOVO
board_name: 20MUCTO1WW
board_version: SDK0J40697 WIN

** Loaded modules:
cpuid
ufs
qnx4
hfsplus
hfs
minix
ntfs
msdos
jfs
xfs
dm_snapshot
dm_bufio
cmac
rfcomm
bnep
vmw_vsock_vmci_transport
vsock
vmw_vmci
pci_stub
vboxpci(OE)
vboxnetadp(OE)
vboxnetflt(OE)
vboxdrv(OE)
ctr
ccm
devlink
nf_tables
nfnetlink
squashfs
overlay
cpufreq_userspace
cpufreq_powersave
cpufreq_conservative
edac_mce_amd
kvm_amd
ccp
kvm
binfmt_misc
btusb
btrtl
btbcm
uvcvideo
hid_multitouch
nls_ascii
btintel
nls_cp437
vfat
fat
bluetooth
videobuf2_vmalloc
videobuf2_memops
videobuf2_v4l2
videobuf2_common
videodev
media
drbg
ansi_cprng
ecdh_generic
irqbypass
joydev
efi_pstore
snd_hda_codec_realtek
snd_hda_codec_generic
arc4
snd_hda_codec_hdmi
bfq
efivars
serio_raw
r8822be(C)
snd_hda_intel
tpm_crb
sg
wmi_bmof
snd_hda_codec
k10temp
snd_hda_core
mac80211
snd_hwdep
sp5100_tco
thinkpad_acpi
snd_pcm
nvram
tpm_tis
snd_timer
ledtrig_audio
snd
ipmi_devintf
rtsx_pci_ms
tpm_tis_core
cfg80211
ipmi_msghandler
ucsi_acpi
typec_ucsi
soundcore
memstick
tpm
typec
rfkill
rng_core
ext4
ac
battery
crc16
mbcache
jbd2
crc32c_generic
fscrypto
pcc_cpufreq
evdev
ecb
acpi_cpufreq
loop
cuse
vmwgfx
fuse
parport_pc
ppdev
lp
parport
efivarfs
ip_tables
x_tables
autofs4
btrfs
zstd_decompress
zstd_compress
algif_skcipher
af_alg
hid_generic
usbhid
hid
dm_crypt
dm_mod
raid10
raid456
async_raid6_recov
async_memcpy
async_pq
async_xor
async_tx
xor
raid6_pq
libcrc32c
raid1
raid0
multipath
linear
md_mod
sd_mod
crct10dif_pclmul
crc32_pclmul
crc32c_intel
rtsx_pci_sdmmc
ghash_clmulni_intel
mmc_core
amdgpu
aesni_intel
chash
gpu_sched
i2c_algo_bit
ahci
ttm
libahci
aes_x86_64
crypto_simd
cryptd
xhci_pci
drm_kms_helper
libata
glue_helper
ehci_pci
xhci_hcd
psmouse
ehci_hcd
drm
scsi_mod
usbcore
i2c_piix4
r8169
realtek
libphy
usb_common
rtsx_pci
wmi
video
i2c_scmi
button


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

Kernel: Linux 5.0.0-trunk-amd64

Bug#929582: lightdm: PATH is set to a hardcoded value

2019-05-26 Thread Manolo Díaz

Package: lightdm
Version: 1.26.0-4
Severity: normal

Dear Maintainer,

lightdm doesn't honour the PATH environment variable, it's always set to
a hardcoded value.

# strings `which lightdm` | grep PATH 
XDG_SEAT_PATH
XDG_SESSION_PATH
Running inside an X server requires Xephyr to be installed but it cannot be 
found.  Please install it or update your PATH environment variable.
LD_LIBRARY_PATH
GI_TYPELIB_PATH
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games

Best Regards,
Manolo Díaz



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

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

Versions of packages lightdm depends on:
ii  adduser3.118
ii  dbus   1.12.12-1
ii  debconf [debconf-2.0]  1.5.71
ii  libaudit1  1:2.8.4-3
ii  libc6  2.28-10
ii  libgcrypt201.8.4-5
ii  libglib2.0-0   2.58.3-1
ii  libpam0g   1.3.1-5
ii  libxcb11.13.1-2
ii  libxdmcp6  1:1.1.2-3
ii  lightdm-gtk-greeter [lightdm-greeter]  2.0.6-1
pn  logind | consolekit
ii  lsb-base   10.2019031300

Versions of packages lightdm recommends:
pn  xserver-xorg  

Versions of packages lightdm suggests:
pn  accountsservice  
pn  upower   
pn  xserver-xephyr   

-- debconf information:
  lightdm/daemon_name: /usr/sbin/lightdm
* shared/default-x-display-manager: lightdm

Bug#929581: zfs-dkms: fails to build module for 4.19.0-5-686-pae

2019-05-26 Thread Andreas Beckmann

Package: zfs-dkms
Version: 0.8.0~rc4-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

zfs-dkms fails to build a module for the i386 kernel from sid:

  Setting up zfs-dkms (0.8.0~rc4-1) ...
  Loading new zfs-0.8.0~rc4 DKMS files...
  It is likely that 4.9.0-9-amd64 belongs to a chroot's host
  Building for 4.19.0-5-686-pae
  Building initial module for 4.19.0-5-686-pae
  configure: error: in `/var/lib/dkms/zfs/0.8.0~rc4/build':
  configure: error: C compiler cannot create executables
  See `config.log' for more details
  Error! Bad return status for module build on kernel: 4.19.0-5-686-pae (i686)
  Consult /var/lib/dkms/zfs/0.8.0~rc4/build/make.log for more information.
  dpkg: error processing package zfs-dkms (--configure):
   installed zfs-dkms package post-installation script subprocess returned 
error exit status 10
  Processing triggers for libc-bin (2.28-10) ...
  Errors were encountered while processing:
   zfs-dkms
  E: Sub-process /usr/bin/dpkg returned an error code (1)


/var/lib/dkms/zfs/0.8.0~rc4/build/make.log contains:

DKMS make.log for zfs-0.8.0~rc4 for kernel 4.19.0-5-686-pae (i686)
Sun May 26 16:37:50 UTC 2019
make: *** No targets specified and no makefile found.  Stop.


Andreas

Bug#929476: Debian 9 installation.

2019-05-26 Thread Cyril Brulebois

Hi Mauro,

mb  (2019-05-24):
> The installation in Graphic mode after the language, country and locales 
> stops because cannot find the CD.
> It is not clear what is such "CD"? All installation software isn't in 
> thedebian-9.9.0-amd64-DVD-1.iso  
> 
>   file loaded on the USB pen drive?

The ISO image is indeed what you copied onto your USB device. I'm not
sure why there's an issue detecting it here, and I'm cc-ing the
debian-cd folks who are responsible for producing installation images,
and know a lot about this specific area.

Did you verify the checksum of what you downloaded? Wondering whether it
could be corrupted in some way, which could maybe explain why all copy
methods you tried gave the same results.


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


signature.asc
Description: PGP signature

Bug#929565: gap-smallgrp: broken symlink: /usr/share/gap/pkg/SmallGrp/doc/mathjax -> ../../../../javascript/mathjax

2019-05-26 Thread Andreas Beckmann

Hi Bill,

On 2019-05-26 15:18, Bill Allombert wrote:
> I think it also needs fonts-mathjax, fonts-mathjax-extras
> 
> Would Suggests: gap-gapdoc be enough ? 

Package: gap-gapdoc
Provides: gap-pkg-gapdoc
Recommends: gap, libjs-mathjax, fonts-mathjax, fonts-mathjax-extras
Suggests: gap-pkg-io

Yep, that Suggests would work for me. (I still have to ensure the
package gets installed (like all other Suggests they only get
"cherry-picked", not enabled globally), but the Suggests documents
what to get :-)

It's probably the same for gap-atlasrep?
/usr/share/gap/pkg/AtlasRep/doc/mathjax -> ../../../../javascript/mathjax

Andreas

Bug#929532: mtd: spi-nor: Add support for N25Q256A11

2019-05-26 Thread Ben Hutchings

Control: reassign -1 src:linux 4.9.168-1
Control: severity -1 important

On Sat, 2019-05-25 at 20:19 +, Matt Sickler wrote:
> Hello Debian Kernel Team,
> 
> I just submitted this bug to Debian via reportbug.  It looks like the
> linux-4.9 package doesn't have a maintainer, so I'm forwarding the
> bug in the hope that someone will see it.

The Bug Tracking System only knows about packages that exist in the
main Debian archive.  During regular security support, all security
uploads are copied to the main archive to be included in the next point
release, but during the LTS extended support period this no longer
happens.  The unfortunate result of this is that the BTS doesn't know
anything about linux-4.9.

Since linux-4.9 is backported from stretch's linux package and any bug
fixes should go into that first, I'm reassigning the bug.

Ben.

-- 
Ben Hutchings
73.46% of all statistics are made up.

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

Bug#929580: lld-7 cannot link large binaries on ppc64le. Please make lld-8 default on ppc64le.

2019-05-26 Thread Shawn Landden

Package: lld
Version: 1:7.0-47.1
Severity: important

Dear Maintainer,

If you try to link a largish program with lld-7 on ppc64le you get errors:

relocation R_PPC64_REL24 out of range: -15683216 is not in [-8388608, 8388607]

This feature is added in lld-8 and is essential to make the package useful on 
this platform.

Thus, please make lld-8 default on ppc64el now, insteading of waiting until it 
is appropiate for
more mature architectures.

-Shawn Landden

-- System Information:
Debian Release: 10.0
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 
'experimental-debug'), (1, 'experimental')
Architecture: ppc64el (ppc64le)

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

Versions of packages lld depends on:
ii  lld-7  1:7.0.1-8

lld recommends no packages.

lld suggests no packages.

-- no debconf information

Bug#929241: RFS: xmltoman/0.6-1 - simple XML to man converter

2019-05-26 Thread Adam Borowski

On Tue, May 21, 2019 at 05:59:45AM +0200, Adam Bilbrough wrote:
> Hi Adam, I have re-uploaded it to mentors.  Tested on multiple
> systems, should be no problems now.

> On Mon, 20 May 2019 at 06:29, Adam Bilbrough  wrote:
> > > Fails to build for me:

Hi!
I'm afraid I only now noticed that this is an upload to unstable for a
package that has a version in Buster.  It's generally a pretty bad idea to
do so during the freeze, other than to fix important bugs.

Thus, it'd be good to either:
* wait until Buster is out, or
* put the new version into experimental instead


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ Latin:   meow 4 characters, 4 columns,  4 bytes
⣾⠁⢠⠒⠀⣿⡁ Greek:   μεου 4 characters, 4 columns,  8 bytes
⢿⡄⠘⠷⠚⠋  Runes:   ᛗᛖᛟᚹ 4 characters, 4 columns, 12 bytes
⠈⠳⣄ Chinese: 喵   1 character,  2 columns,  3 bytes <-- best!

Bug#929128: fonts-noto-cjk: not recognized by lualatex until mktexlsr

2019-05-26 Thread Hilmar Preuße


Am 26.05.2019 um 03:52 teilte Ryutaroh Matsumoto mit:

Matsumoto-san,

I followed your instructions and tried to reproduce some kind of issue.
I compiled your document using TL from experimental; it triggered some
kind of memory leak in luatex. At least I would not expect that luatex
needs 1,5 GB of RAM to compile your document:

%Cpu(s):  1.3 us, 47.8 sy,  0.3 ni,  0.0 id, 50.5 wa,  0.0 hi,  0.0 si,
0.0 st
MiB Mem :938.3 total, 59.5 free,860.5 used, 18.3 buff/cache
MiB Swap:   1376.6 total,295.4 free,   1081.2 used. 21.0 avail Mem

  PID USER  PR  NIVIRTRESSHR S  %CPU  %MEM TIME+
COMMAND
  137 root   0 -20   0  0  0 I  32.2   0.0   0:11.56
kworker/0+
 5014 root  20   0 1533540 669688168 D   8.3  69.7   1:13.58
lualatex

Please file a bug against our package texlive-binaries, version
2019.20190507.51032-1 .

Many thanks!

Hilmar


Matsumoto-san, I am actually surprised that mktexlsr call fixed it,
since luatex doesn't use ls-R files.
Do you have a way to reproduce this behaviour?


You are right. The way to reproduce this issue (not related to mktexlsr)
is
(1) Install texlive-full and fonts-noto-cjk from experimental.
(2) Run lualatex with the below LaTeX source and have error
"Package fontspec Error: The font "NotoSerifCJKJPLight" cannot be found."
(3) Installation of fonts-noto-cjk-extra fixes the issue even though
no font from
fonts-noto-cjk-extra is used. XeLaTeX (with \usepackage[noto]{zxjafont}) and
uplatex (with \usepackage[unicode,noto-otc]{pxchfon}) produce the desired
PDF without fonts-noto-cjk-extra.

\documentclass[a4paper,12pt]{ltjsarticle}
\usepackage[noto-otf]{luatexja-preset}

\begin{document}
日本語
\end{document}

This seems a feature or a bug in TeXLive 2019 upstream, which should not have
been filed in BTS. So I close this issue.




--
#206401 http://counter.li.org

Bug#929579: fio FTCBFS: builds for the build architecture

2019-05-26 Thread Helmut Grohne

Source: fio
Version: 3.12-2
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

fio fails to cross build from source, because it configures for the
build architecture. fio's configure is very different from autotools and
requires the user to export a variable called CROSS_COMPILE. Even then,
it uses the wrong pkg-config and runs compiled executables. The attached
patch makes fio cross buildable. Please consider applying it.

Helmut
diff --minimal -Nru fio-3.12/debian/changelog fio-3.12/debian/changelog
--- fio-3.12/debian/changelog   2019-01-21 09:29:38.0 +0100
+++ fio-3.12/debian/changelog   2019-05-25 14:14:03.0 +0200
@@ -1,3 +1,13 @@
+fio (3.12-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: (Closes: #-1)
++ Export CROSS_COMPILE.
++ cross.patch: Apply $CROSS_COMPILE to pkg-config and avoid running
+  compiled code.
+
+ -- Helmut Grohne   Sat, 25 May 2019 14:14:03 +0200
+
 fio (3.12-2) unstable; urgency=medium
 
   * control: Depend on libglusterfs-dev instead of glusterfs-common
diff --minimal -Nru fio-3.12/debian/patches/cross.patch 
fio-3.12/debian/patches/cross.patch
--- fio-3.12/debian/patches/cross.patch 1970-01-01 01:00:00.0 +0100
+++ fio-3.12/debian/patches/cross.patch 2019-05-25 14:14:03.0 +0200
@@ -0,0 +1,42 @@
+--- fio-3.12.orig/configure
 fio-3.12/configure
+@@ -1336,31 +1336,30 @@
+   return GTK_CHECK_VERSION(2, 18, 0) ? 0 : 1; /* 0 on success */
+ }
+ EOF
+-GTK_CFLAGS=$(pkg-config --cflags gtk+-2.0 gthread-2.0)
++GTK_CFLAGS=$(${cross_prefix}pkg-config --cflags gtk+-2.0 gthread-2.0)
+ ORG_LDFLAGS=$LDFLAGS
+ LDFLAGS=$(echo $LDFLAGS | sed s/"-static"//g)
+ if test "$?" != "0" ; then
+   echo "configure: gtk and gthread not found"
+   exit 1
+ fi
+-GTK_LIBS=$(pkg-config --libs gtk+-2.0 gthread-2.0)
++GTK_LIBS=$(${cross_prefix}pkg-config --libs gtk+-2.0 gthread-2.0)
+ if test "$?" != "0" ; then
+   echo "configure: gtk and gthread not found"
+   exit 1
+ fi
+-if compile_prog "$GTK_CFLAGS" "$GTK_LIBS" "gfio" ; then
+-  $TMPE
+-  if test "$?" = "0" ; then
++if ! ${cross_prefix}pkg-config --atleast-version 2.18.0 gtk+-2.0; then
++  echo "GTK found, but need version 2.18 or higher"
++  gfio="no"
++else
++  if compile_prog "$GTK_CFLAGS" "$GTK_LIBS" "gfio" ; then
+ gfio="yes"
+ GFIO_LIBS="$LIBS $GTK_LIBS"
+ CFLAGS="$CFLAGS $GTK_CFLAGS"
+   else
+-echo "GTK found, but need version 2.18 or higher"
++echo "Please install gtk and gdk libraries"
+ gfio="no"
+   fi
+-else
+-  echo "Please install gtk and gdk libraries"
+-  gfio="no"
+ fi
+ LDFLAGS=$ORG_LDFLAGS
+ fi
diff --minimal -Nru fio-3.12/debian/patches/series 
fio-3.12/debian/patches/series
--- fio-3.12/debian/patches/series  2018-11-28 18:09:19.0 +0100
+++ fio-3.12/debian/patches/series  2019-05-25 14:14:03.0 +0200
@@ -3,3 +3,4 @@
 fio2gnuplot-manpage
 configure-no-configlog
 genfio-interpreter
+cross.patch
diff --minimal -Nru fio-3.12/debian/rules fio-3.12/debian/rules
--- fio-3.12/debian/rules   2018-11-28 18:09:19.0 +0100
+++ fio-3.12/debian/rules   2019-05-25 14:14:03.0 +0200
@@ -9,12 +9,18 @@
 # Uncomment this to turn on verbose mode.
 #export DH_VERBOSE=1
 
+include /usr/share/dpkg/architecture.mk
+
 export DEB_LDFLAGS_MAINT_PREPEND := -Wl,-z,defs -Wl,--as-needed
 
 export DEB_BUILD_MAINT_OPTIONS = hardening=+all
 
 export V = 1
 
+ifneq ($(DEB_BUILD_ARCH),$(DEB_HOST_ARCH))
+export CROSS_COMPILE=$(DEB_HOST_GNU_TYPE)-
+endif
+
 %:
dh $@

Bug#929578: ldns FTCBFS: python Build-Depends not installable

2019-05-26 Thread Helmut Grohne

Source: ldns
Version: 1.7.0-4
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability

ldns fails to cross build from source, because its python Build-Depends
are not installable. The usual pattern is that you need a native python
and the relevant lib*-dev package for the host architecture. The
attached patch fixes the Build-Depends and that's sufficient to make
ldns cross buildable. Please consider applying it.

Helmut
diff --minimal -Nru ldns-1.7.0/debian/changelog ldns-1.7.0/debian/changelog
--- ldns-1.7.0/debian/changelog 2019-03-10 22:56:02.0 +0100
+++ ldns-1.7.0/debian/changelog 2019-05-26 16:23:52.0 +0200
@@ -1,3 +1,10 @@
+ldns (1.7.0-4.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Multiarchify python Build-Depends. (Closes: #-1)
+
+ -- Helmut Grohne   Sun, 26 May 2019 16:23:52 +0200
+
 ldns (1.7.0-4) unstable; urgency=medium
 
   * Fix invalid maintainer (Closes: #899938)
diff --minimal -Nru ldns-1.7.0/debian/control ldns-1.7.0/debian/control
--- ldns-1.7.0/debian/control   2019-03-10 22:56:02.0 +0100
+++ ldns-1.7.0/debian/control   2019-05-26 16:23:51.0 +0200
@@ -7,10 +7,12 @@
dh-python,
doxygen,
libpcap-dev,
+   libpython-dev,
+   libpython3-dev,
libssl-dev (>= 1.1.0),
pkg-config,
-   python-dev,
-   python3-dev,
+   python-dev:any,
+   python3-dev:any,
swig
 Standards-Version: 4.3.0.3
 Section: net

Bug#929269: coturn: overwrites database file /var/lib/turn/turndb on upgrade or reinstall

2019-05-26 Thread Chris Lamb

tags 929269 + pending patch
thanks

I've uploaded coturn 4.5.1.1-1.1 to DELAYED/5:
  
  coturn (4.5.1.1-1.1) unstable; urgency=medium
  
* Non-maintainer upload.
* Don't ship the (empty) /var/lib/turn/turndb SQLite database and generate 
it
  on-demand in the postinst instead, avoiding overwriting it on
  upgrade/reinstall. (Closes: #929269)

The full debdiff is attached.


Regards,

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

 changelog   |9 +
 control |1 +
 coturn.install  |1 -
 coturn.postinst |9 +
 coturn.postrm   |2 ++
 5 files changed, 21 insertions(+), 1 deletion(-)

diff -Nru coturn-4.5.1.1/debian/changelog coturn-4.5.1.1/debian/changelog
--- coturn-4.5.1.1/debian/changelog 2019-03-02 23:38:30.0 +
+++ coturn-4.5.1.1/debian/changelog 2019-05-26 15:11:04.0 +0100
@@ -1,3 +1,12 @@
+coturn (4.5.1.1-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Don't ship the (empty) /var/lib/turn/turndb SQLite database and generate it
+on-demand in the postinst instead, avoiding overwriting it on
+upgrade/reinstall. (Closes: #929269)
+
+ -- Chris Lamb   Sun, 26 May 2019 15:11:04 +0100
+
 coturn (4.5.1.1-1) unstable; urgency=medium
 
   * [a13ba45] Fix: missing /etc/turnserver.conf
diff -Nru coturn-4.5.1.1/debian/control coturn-4.5.1.1/debian/control
--- coturn-4.5.1.1/debian/control   2019-03-02 23:38:30.0 +
+++ coturn-4.5.1.1/debian/control   2019-05-26 15:11:04.0 +0100
@@ -24,6 +24,7 @@
 Package: coturn
 Architecture: any
 Depends: adduser,
+ sqlite3,
  lsb-base (>= 3.0-6),
  telnet | telnet-client,
  ${misc:Depends},
diff -Nru coturn-4.5.1.1/debian/coturn.install 
coturn-4.5.1.1/debian/coturn.install
--- coturn-4.5.1.1/debian/coturn.install2019-03-02 23:07:47.0 
+
+++ coturn-4.5.1.1/debian/coturn.install2019-05-26 15:11:04.0 
+0100
@@ -15,7 +15,6 @@
 include/turn/client/ns_turn_msg_defs_experimental.h usr/include/turn
 include/turn/ns_turn_defs.h usr/include/turn
 lib/libturnclient.a usr/lib
-sqlite/turndb var/lib/turn
 turndb/schema.mongo.sh usr/share/coturn
 turndb/schema.mongo.sh usr/share/doc/coturn
 turndb/schema.sql usr/share/coturn
diff -Nru coturn-4.5.1.1/debian/coturn.postinst 
coturn-4.5.1.1/debian/coturn.postinst
--- coturn-4.5.1.1/debian/coturn.postinst   2019-03-02 23:07:47.0 
+
+++ coturn-4.5.1.1/debian/coturn.postinst   2019-05-26 15:11:04.0 
+0100
@@ -35,6 +35,15 @@
"$TURNSERVER_USER" || exit 1
 fi
 
+# Don't ship the empty database; generate it on-demand. (#929269)
+TURNDB_SQLITE=/var/lib/turn/turndb
+TURNDB_SCHEMA=/usr/share/doc/coturn/schema.sql
+
+if [ ! -e "$TURNDB_SQLITE" ] && [ -e "$TURNDB_SCHEMA" ]; then
+echo "I: Creating $TURNDB_SQLITE from $TURNDB_SCHEMA" >&2
+mkdir -p "$(dirname "$TURNDB_SQLITE")"
+sqlite3 "$TURNDB_SQLITE" < "$TURNDB_SCHEMA"
+fi
 }
 
 case "$1" in
diff -Nru coturn-4.5.1.1/debian/coturn.postrm 
coturn-4.5.1.1/debian/coturn.postrm
--- coturn-4.5.1.1/debian/coturn.postrm 2019-03-02 23:07:47.0 +
+++ coturn-4.5.1.1/debian/coturn.postrm 2019-05-26 15:11:04.0 +0100
@@ -12,6 +12,8 @@
 if getent group $TURNSERVER_GROUP >/dev/null; then
 groupdel $TURNSERVER_GROUP
 fi
+
+rm -f /var/lib/turn/turndb
 fi

Bug#929577: lintian: please keep buster up2date

2019-05-26 Thread Mattia Rizzolo

Source: lintian
Version: 2.9.1

Hi,

I'm not sure what happened, but the backports master decided to grant an
exception to lintian so the version in stretch-bpo is higher than the
version in buster.  I don't really buy their reasoning, but even so, I'd
appreciate if you lintian maintainers could properly file unblock
requests and get the version in buster updated as well.
I know that most of your changes don't respect the freeze policy, but
given that on February the release team granted an exception, maybe they
will again.

My position here comes mainly as a mentors.debian.net maintainer, where
we are now running buster, and apparently we now have a 3-months old
lintian due to this, whereas stretch-bpo would have been more updated…


Also, regardless of whatever the backports master grant, please do try
to end up with a proper upgrade path from stretch-bpo to the final
buster.

-- 
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#928227: unblock: golang-golang-x-net-dev/1:0.0+git20181201.351d144+dfsg-3

2019-05-26 Thread Shengjing Zhu

On Sun, May 26, 2019 at 10:18 PM Paul Gevers  wrote:
>
> Hi,
>
> On 21-05-2019 20:35, Paul Gevers wrote:
> > Hi Shengjing,
> >
> > I have decided that I'll let golang-golang-x-net-dev migrate to testing
> > do the binNMUs in buster. I'll leave the bug open until the rebuilds
> > have succeeded to keep track of the issue.
> >
> > Let's hope for the best.
>
> Which isn't great. So golang-golang-x-net-dev migrated to testing. I
> binNMU'd abci as a first package in unstable with +b32 and in buster
> with +b23. However, the buster binNMU got lost although the logs say it
> was processed. ftp-master don't know where the issue is and advice to
> binNMU in unstable even if that means reverting other packages.
>
> At this moment I don't have a better solution than to proceed with
> reverting packages that are used for building the reverse dependencies
> of golang-golang-x-net-dev and make sure we get a sane set of packages
> to migrate to buster together.
>
> This whole mess shows the value of the advice to not upload packages to
> unstable during the freeze that are not intended for the next stable
> release. It seems this is even much more relevant for the golang ecosystem.
>

Ack, I'll start writing email to the Go team, and work out how many
packages need revert.

-- 
Shengjing Zhu

Bug#929576: unblock: hexchat/2.14.2-4

2019-05-26 Thread Mattia Rizzolo

Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: unblock

Hi,

please consider unblocking this new release of hexchat.

It fixes a crash on exit in the python plugin, caused by something that
python 3.7 did.

From my side it went unnoticed till now because nothing notifies me of
crashes, and clearly my window manager hid it from me... I never though
of running it off a terminal…  also I'm sorry I misinterpreted/ignored
the relevant bug, only a recent bug in ubuntu triggered me to act on it.

While on it I also renamed (really, just renumbered) the other two
patches… sorry for the littel noise in the debdiff, but it really is not
doing anything extra apart the renaming (git is more clear).

-- 
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  `-
diffstat for hexchat-2.14.2 hexchat-2.14.2

 changelog   |7 
 patches/0001-Build-for-both-python2-and-python3-by-default.patch|  100 ++
 patches/0002-Build-for-both-python2-and-python3-by-default.patch|  100 --
 patches/0002-Fix-FTBFS-on-non-linux.patch   |   29 ++
 patches/0003-Fix-FTBFS-on-non-linux.patch   |   29 --
 patches/0003-Python-plugin-Call-EndInterpreter-when-deinit-ing-th.patch |   35 +++
 patches/series  |5 
 7 files changed, 174 insertions(+), 131 deletions(-)

diff -Nru hexchat-2.14.2/debian/changelog hexchat-2.14.2/debian/changelog
--- hexchat-2.14.2/debian/changelog	2018-12-03 14:17:35.0 +0100
+++ hexchat-2.14.2/debian/changelog	2019-05-25 11:48:26.0 +0200
@@ -1,3 +1,10 @@
+hexchat (2.14.2-4) unstable; urgency=medium
+
+  * Add a patch to fix a probable crash while unloading the Python plugin
+when using Python 3.7.  LP: #1830246; Closes: #921208
+
+ -- Mattia Rizzolo   Sat, 25 May 2019 11:48:26 +0200
+
 hexchat (2.14.2-3) unstable; urgency=medium
 
   [ Ondřej Nový ]
diff -Nru hexchat-2.14.2/debian/patches/0001-Build-for-both-python2-and-python3-by-default.patch hexchat-2.14.2/debian/patches/0001-Build-for-both-python2-and-python3-by-default.patch
--- hexchat-2.14.2/debian/patches/0001-Build-for-both-python2-and-python3-by-default.patch	1970-01-01 01:00:00.0 +0100
+++ hexchat-2.14.2/debian/patches/0001-Build-for-both-python2-and-python3-by-default.patch	2019-05-25 11:48:26.0 +0200
@@ -0,0 +1,100 @@
+From: Mattia Rizzolo 
+Date: Tue, 13 Mar 2018 23:41:47 +0100
+Subject: Build for both python2 and python3 by default
+
+Forwarded: not-needed
+---
+ data/misc/meson.build  | 11 ---
+ meson_options.txt  |  7 +--
+ plugins/meson.build|  2 +-
+ plugins/python/meson.build | 20 
+ 4 files changed, 26 insertions(+), 14 deletions(-)
+
+diff --git a/data/misc/meson.build b/data/misc/meson.build
+index f7f1c27..ca091e8 100644
+--- a/data/misc/meson.build
 b/data/misc/meson.build
+@@ -98,9 +98,14 @@ if get_option('with-plugin') and get_option('with-appdata')
+ ]
+   endif
+ 
+-  if get_option('with-python') != 'false'
++  if get_option('with-python2') != 'false'
+ plugin_metainfo += [
+-  ['Python', 'Provides a scripting interface in Python', 'GPL-2.0+']
++  ['Python2', 'Provides a scripting interface in Python2', 'GPL-2.0+']
++]
++  endif
++  if get_option('with-python3') != 'false'
++plugin_metainfo += [
++  ['Python3', 'Provides a scripting interface in Python3', 'GPL-2.0+']
+ ]
+   endif
+ 
+@@ -124,4 +129,4 @@ if get_option('with-plugin') and get_option('with-appdata')
+   install_dir: get_option('install-plugin-metainfo') ? metainfodir : '',
+ )
+   endforeach
+-endif
+\ No newline at end of file
++endif
+diff --git a/meson_options.txt b/meson_options.txt
+index 100a5ee..083da91 100644
+--- a/meson_options.txt
 b/meson_options.txt
+@@ -48,8 +48,11 @@ option('with-lua', type: 'string', value: 'luajit',
+ option('with-perl', type: 'string', value: 'perl',
+   description: 'Perl scripting plugin, value is path to perl executable or "false"'
+ )
+-option('with-python', type: 'string', value: 'python3',
+-  description: 'Python scripting plugin. value is pkg-config name to use or "false"'
++option('with-python2', type: 'string', value: 'python2',
++  description: 'Python 2 scripting plugin. value is pkg-config name to use or "false"'
++)
++option('with-python3', type: 'string', value: 'python3',
++  description: 'Python 3 scripting plugin. value is pkg-config name to use or "false"'
+ )
+ option('with-sysinfo', type: 'boolean',
+   description: 'System information plugin, requires libpci on Unix'
+diff --git

Bug#928227: unblock: golang-golang-x-net-dev/1:0.0+git20181201.351d144+dfsg-3

2019-05-26 Thread Paul Gevers

Hi,

On 21-05-2019 20:35, Paul Gevers wrote:
> Hi Shengjing,
> 
> I have decided that I'll let golang-golang-x-net-dev migrate to testing
> do the binNMUs in buster. I'll leave the bug open until the rebuilds
> have succeeded to keep track of the issue.
> 
> Let's hope for the best.

Which isn't great. So golang-golang-x-net-dev migrated to testing. I
binNMU'd abci as a first package in unstable with +b32 and in buster
with +b23. However, the buster binNMU got lost although the logs say it
was processed. ftp-master don't know where the issue is and advice to
binNMU in unstable even if that means reverting other packages.

At this moment I don't have a better solution than to proceed with
reverting packages that are used for building the reverse dependencies
of golang-golang-x-net-dev and make sure we get a sane set of packages
to migrate to buster together.

This whole mess shows the value of the advice to not upload packages to
unstable during the freeze that are not intended for the next stable
release. It seems this is even much more relevant for the golang ecosystem.

Paul

signature.asc
Description: OpenPGP digital signature

Bug#929575: simpleid: Not compatible with PHP 7

2019-05-26 Thread Stuart Prescott

Source: simpleid
Version: 0.8.1-15
Severity: serious
Justification: Does not work with PHP 7 in buster

Dear Maintainer,

According to the upstrem bug tracker, simpleid is not compatible with PHP7,
which would mean that it does not work in buster. Upstream also seems to
indicate that the project is no longer developed.

  https://github.com/simpleid/simpleid/issues/30

  https://github.com/simpleid/simpleid/issues/34

It would seem that this package should not be in buster.

Stuart

Bug#858294: Probably fixed in Qt 5.12

2019-05-26 Thread Lisandro Damián Nicanor Pérez Meyer

Control: tag -1 moreinfo

Hi! According to the upstream bug report this bug *might* be fixed in
Qt 512. This version is still in experimental at least until Buster is
released, but whenever you can give it a try, the better.

Thanks!

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

Bug#929574: squid: After running "squid -k rotate", it is not possible to obtain operation statistics on "squidclient mgr: info"

2019-05-26 Thread Soukaku TATARA

Package: squid
Version: 4.6-2
Severity: minor

Dear Maintainer,

Immediately after performing log rotation by executing "squid -k rotate", 
acquisition of operation statistics information by squidclient (squidclient 
mgr: info) fails.
Restarting squid has confirmed that the event will recover.


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

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

Versions of packages squid depends on:
ii  adduser  3.118
ii  libc62.28-10
ii  libcap2  1:2.25-2
ii  libcom-err2  1.45.1-3
ii  libdb5.3 5.3.28+dfsg1-0.6
ii  libdbi-perl  1.642-1+b1
ii  libecap3 1.0.1-3.2
ii  libexpat12.2.6-1
ii  libgcc1  1:9-20190402-1
ii  libgnutls30  3.6.7-3
ii  libgssapi-krb5-2 1.17-2
ii  libkrb5-31.17-2
ii  libldap-2.4-22.4.47+dfsg-3
ii  libltdl7 2.4.6-10
ii  libnetfilter-conntrack3  1.0.7-1
ii  libnettle6   3.4.1-1
ii  libpam0g 1.3.1-5
ii  libsasl2-2   2.1.27+dfsg-1
ii  libstdc++6   8.3.0-7
ii  libxml2  2.9.4+dfsg1-7+b3
ii  logrotate3.14.0-4
ii  lsb-base 10.2019051400
ii  netbase  5.6
ii  squid-common 4.6-2

Versions of packages squid recommends:
ii  ca-certificates  20190110
ii  libcap2-bin  1:2.25-2

Versions of packages squid suggests:
ii  apparmor 2.13.2-10
pn  resolvconf   
pn  smbclient
pn  squid-cgi
ii  squid-purge  4.6-2
ii  squidclient  4.6-2
pn  ufw  
pn  winbind  

-- Configuration Files:
/etc/logrotate.d/squid changed:
/var/log/squid/cache.log
/var/log/squid/sarg_access.log{
missingok
nocreate
sharedscripts
prerotate
test ! -x /usr/sbin/sarg-reports || /usr/sbin/sarg-reports daily
endscript
postrotate
test ! -e /var/run/squid.pid || test ! -x /usr/sbin/squid || 
/usr/sbin/squid -k rotate
endscript
}

/etc/squid/squid.conf changed:
include /etc/squid/conf.d/*
pid_filename/run/squid.pid
acl localnetsrc 0.0.0.1-0.255.255.255   # RFC 1122 "this" 
network (LAN)
acl localnetsrc 10.0.0.0/8  # RFC 1918 local 
private network (LAN)
acl localnetsrc 100.64.0.0/10   # RFC 6598 shared 
address space (CGN)
acl localnetsrc 169.254.0.0/16  # RFC 3927 link-local 
(directly plugged) machines
acl localnetsrc 172.16.0.0/12   # RFC 1918 local 
private network (LAN)
acl localnetsrc 192.168.0.0/16  # RFC 1918 local 
private network (LAN)
acl localnetsrc fc00::/7# RFC 4193 local 
private network range
acl localnetsrc fe80::/10   # RFC 4291 link-local 
(directly plugged) machines
acl localnetsrc 2001:470:24:94::/64
acl SSL_ports   port443
acl Safe_ports  port80  # http
acl Safe_ports  port21  # ftp
acl Safe_ports  port443 # https
acl Safe_ports  port70  # gopher
acl Safe_ports  port210 # wais
acl Safe_ports  port1025-65535  # unregistered ports
acl Safe_ports  port280 # http-mgmt
acl Safe_ports  port488 # gss-http
acl Safe_ports  port591 # filemaker
acl Safe_ports  port777 # multiling http
acl CONNECT method  CONNECT
http_access deny!Safe_ports
http_access denyCONNECT !SSL_ports
http_access allow   localhost manager
http_access denymanager
http_access allow   localhost
http_access allow   localnet
http_access denyall
http_port   3128
cache_peer  172.16.0.1  parent 3128 7   no-netdb-exchange 
no-digest
never_directallow   all
forwarded_for   on
shutdown_lifetime   5 seconds
refresh_pattern ^ftp:   144020% 10080
refresh_pattern ^gopher:14400%  1440
refresh_pattern -i (/cgi-bin/|\?)   0   0%  0
refresh_pattern .   0   20% 4320
logformat combined   %>a %[ui %[un [%tl] "%rm %ru HTTP/%rv" %>Hs %h" "%{User-Agent}>h" %Ss:%Sh
access_log  syslog:local7.info  combined
access_log

Bug#926242: jenkins.debian.org: Please test reproducibility status of Debian Installer images

2019-05-26 Thread Colin Watson

On Sun, May 26, 2019 at 11:05:40AM +0100, Chris Lamb wrote:
> Dear Colin,
> > It would be worth somebody trying out a d-i build on a system with this
> > kind of configuration to see if it still breaks
>   ^
> 
> Just to clarify, building d-i on a system with [arch=...] foo in its
> /etc/apt/sources.list?

This is all from dubious memory, but I suspect my setup at the time was
roughly an amd64 system with:

  deb [arch=amd64] 
  deb 

... on the grounds that my local partial mirror didn't have space for
both amd64 and i386.

-- 
Colin Watson   [cjwat...@debian.org]

Bug#929565: gap-smallgrp: broken symlink: /usr/share/gap/pkg/SmallGrp/doc/mathjax -> ../../../../javascript/mathjax

2019-05-26 Thread Bill Allombert

On Sun, May 26, 2019 at 10:55:21AM +0200, Andreas Beckmann wrote:
> Package: gap-smallgrp
> Version: 1.3-1
> Severity: normal
> User: debian...@lists.debian.org
> Usertags: piuparts
> 
> Hi,
> 
> during a test with piuparts I noticed your package ships (or creates)
> a broken symlink.
> 
> >From the attached log (scroll to the bottom...):
> 
> 0m20.9s ERROR: FAIL: Broken symlinks:
>   /usr/share/gap/pkg/SmallGrp/doc/mathjax -> ../../../../javascript/mathjax 
> (gap-smallgrp)
> 
> Is gap-smallgrp missing a Depends/Recommends/Suggests: libjs-mathjax ?

Hello Andreas,
I think it also needs fonts-mathjax, fonts-mathjax-extras

Would Suggests: gap-gapdoc be enough ? 

Thanks for your bug report,
-- 
Bill. 

Imagine a large red swirl here.

Bug#929571: unblock: dgit/8.5

2019-05-26 Thread Jonathan Wiltshire

Control: tag -1 confirmed moreinfo

On Sun, May 26, 2019 at 11:12:28AM +0100, Ian Jackson wrote:
> I attach the git commit which explains the details.  Assuming you give
> the go-ahead, I will upload this with an appropriate changelog update.

Please go ahead and remove the moreinfo tag from this bug when it is ready
to unblock.

Thanks,


-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51

Bug#826425: deborphan: reports package as unused whereas it's used

2019-05-26 Thread nodiscc

Confirming this bug on Debian Stretch, deborphan 1.7.28.8-0.3+b1

$ deborphan --guess-all |grep cffi
python3-cffi-backend:amd64
python-cffi-backend:amd64

$ aptitude why python3-cffi-backend:amd64
i   python3-cryptography Depends  python3-cffi-backend-api-min (<= 9729)
i A python3-cffi-backend Provides python3-cffi-backend-api-min

$ aptitude why python-cffi-backend:amd64
i   ansible Depends  python-cryptography
i A python-cryptography Depends  python-cffi-backend-api-min (<= 9729)
i A python-cffi-backend Provides python-cffi-backend-api-min

Bug#928902: spectrwm FTCBFS: uses build architecture build tools

2019-05-26 Thread Helmut Grohne

On Sun, May 26, 2019 at 10:00:46AM +0200, Andrea Bolognani wrote:
> Can you please provide instructions I can use to reproduce the build
> failure? The way you tackled it looks sensible enough, but I'd like
> to play around a bit myself :)

sbuild¹: Pass --host=somearch.
pbuilder: Pass --host-arch somearch
dpkg-buildpackage: DEB_BUILD_OPTIONS=nocheck dpkg-buildpackage --build=any 
--host-arch somearch --profiles cross,nocheck

Helmut

¹ Assumes that your sbuild is from buster or sid.

Bug#925406: Plasma web browser widget

2019-05-26 Thread John Scott

This affects the Web browser widget too.

Bug#929511: qtcreator: Segfault on start

2019-05-26 Thread Lisandro Damián Nicanor Pérez Meyer

Hi!

On Sun, 26 May 2019 at 00:06, subhuman  wrote:
>
> Hi Lisandro,
>
> thank you for your reply.

My pleasure!

> I will answer your questions in two parts, because I haven't got much time 
> right now - I'm to help with the European elections. What I can give you here 
> is the output from:
>
> ~$ qtcreator -profile
> Profiling started
[snip]
>  >loadLibrary   ClangTools  747ms (   0ms)
> Segmentation fault

I compared the output to mine and it looks mostly the same (different
order of loading stuff, but nomal)... up to ClangTools. So this is
clearly LLVM related.

> All plugins have been installed via apt and from official Debian mirrors.

OK; then let's wait for the rest of the info then.

Bug#924554: Bug#928108: unblock: unattended-upgrades/1.12 ?

2019-05-26 Thread Paul Gevers

Hi Bálint,

On 23-05-2019 08:59, Paul Gevers wrote:
> Unblocked, thanks. However, can you explain why the autopkgtests started
> failing and do you expect it to keep failing? If the fix is obvious and
> easily and only in the debian/tests/ directory, I'd like to have it,
> such that the unattended-upgrades autopkgtest remains working during the
> stable release time.

Apparently the test doesn't fail reproducible. The latest
migration-reference run was successful, so your package is now blocked
due to autopkgtest regression.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#929557: linux: restore __kernel_fpu needed for zfs for AES-NI/AVX support [mainline not in debian yet]

2019-05-26 Thread Bastian Blank

Hi Chris

On Sat, May 25, 2019 at 10:03:07PM -0400, Chris Zubrzycki wrote:
> GKH has been purging __kernel_fpu_{begin,end}() from all kernels
> including LTS (4.19/5) and it's needed for AES-NI/AVX support in the zfs
> package.

The commit also tells you why this was done.  Please bring this up to
upstream and Greg, not to us.

>Arch Linux has already reverted the offending commit in their
> distro. Patch available at
> https://raw.githubusercontent.com/Mic92/nixpkgs/7b77c27caa8617c82df5c5af6b9ce6ae010d7f9a/pkgs/os-specific/linux/kernel/export_kernel_fpu_functions.patch

How is this change not a copyright violation?

Regards,
Bastian

-- 
Punishment becomes ineffective after a certain point.  Men become insensitive.
-- Eneg, "Patterns of Force", stardate 2534.7

Bug#756954: subscription by uploaders

2019-05-26 Thread Afif Elghraoui

Hello,

على ٧‏/٧‏/١٤٤٠ هـ ‫٥:٢٢ م، كتب Raphael Hertzog:
> Hello Afif,
> 
> sorry for the delay.

I read your reply before and put it aside for later, but reading it
again now, I have a comment--

> 
> On Sun, 03 Feb 2019, Afif Elghraoui wrote:
>> The way I was hoping this could work is that Uploaders are automatically
>> subscribed. I don't know of any reason why an Uploader should not be
>> following their packages. I think it would also motivate people who
>> really don't co-maintain a package to get themelves removed from the
>> Uploaders list, thereby correcting the package metadata.
> 
> Uploaders should be following their packages but they might already be
> following their packages in some other way: through a (tracker-)team
> subscription. Or through a mailing list that is referenced in the
> Maintainer field.
> 

Yes, but this would be addressed by the mechanism you described in the
requirement below [1]

> So maintainers should be able to opt-out from this automatic subscription
> or at least blacklist some packages (so that a manual unsubscription is
> not followed by an automatic subscription because of the Uploaders field).
> 

One of the main points of this feature as I see it is that it helps to
keep the Uploaders field accurate. If co-maintainers want to completely
unsubscribe, why shouldn't they achieve this by just removing themselves
from Uploaders altogether?


>> I think this would also be simpler to implement than subscription
>> keywords in d/control (as mentioned in the OP). If it's still too far
>> out of you way, I'd be willing to implement a patch, but would
>> appreciate a tip about where to look in the code-base. I looked around
>> it and couldn't find a good starting point in the file hierarchy.
> 
> I believe this feature is important and it would be nice to have it
> working in the not too distant future but I'm unfortunately not actively
> working on the tracker lately (just look at how much time it took me to
> respond to your mail!).
> 
> A good start would be to modify the database so that we can record the
> origin of each subscription. I imagine it would be a simple text value
> associated to the subscription: "manual:web" or "manual:email" for a
> manual subscription from the web interface or from the email interface. Or
> "auto:uploaders" for this new feature.
> 
> You will have to modify the Subscription model in
> distro_tracker/core/models.py and you probably want to create a new
> task in distro_tracker/core/retrieve_data.py (or modify an existing one?)
> to create/delete the subscriptions as appropriate.
> 
> You will have to review the places where the subscriptions are created
> and add the required origin value.
> 
> The task should be smart enough to detect when the given email already
> gets the package notifications through a tracker team or through a 
> pre-existing
> (manual) subscription or through an alternate email associated to the same
> user.

1. ^ here

Thanks for the tips! Not sure when I'll get to it, but it'll probably be
before I package anything golang-* because I really do not want to
subscribe to the Go team mailing list nor manage my PTS subscriptions
manually.

Thanks and regards
Afif


-- 
Afif Elghraoui | عفيف الغراوي
https://afif.ghraoui.name

Bug#926556: unblock: yubikey-personalization/1.19.3-3

2019-05-26 Thread Afif Elghraoui

Control: tag -1 - moreinfo

Hello,

On Sat, 25 May 2019 13:06:36 -0400 Bill Blough  wrote:
> It appears that the needed changes are located in Salsa [1], and that the
> release was prepared but not uploaded (since it's nowhere to be found).
> 

Indeed. It also looks like he prepared the package and debdiff before
pushing to salsa, because he merged in a pre-existing commit by a
co-maintainer removing his name from the Uploaders list. I've uploaded
the state of salsa as is, so I hope that extra change of dropping an
Uploader isn't an issue.

> This package is team maintained, and since it's not clear to me if the
> rest of the team is aware of this issue, I'm CC'ing the team address in
> this message.
> 
> If there's no response from nicoo or the rest of the team, I would like to go
> ahead with an NMU, assuming that's permissible under these circumstances.
> 

Thanks for following up.

regards
Afif

-- 
Afif Elghraoui | عفيف الغراوي
https://afif.ghraoui.name

Bug#915094: Not limited to EXT4.

2019-05-26 Thread Gong S.

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Now the problem happens in JFS as well.
It is a kernel bug, and it looks like that it is not fixed in 5.0.
Because of that, I have lost nearly one month of work. How sad.
Here is what "dmesg" said:
-BEGIN OUTPUT-
[287480.751455] sysrq: SysRq : Show Blocked State
[287480.751462]   taskPC stack   pid father
[287480.751496] zpaqD0 33088  1 0x0004
[287480.751500] Call Trace:
[287480.751510]  ? __schedule+0x2d4/0x870
[287480.751515]  ? wake_up_q+0x70/0x70
[287480.751517]  schedule+0x28/0x70
[287480.751521]  io_schedule+0x12/0x40
[287480.751530]  txBeginAnon+0x16c/0x1c0 [jfs]
[287480.751534]  ? wake_up_q+0x70/0x70
[287480.751541]  extAlloc+0x4b/0x460 [jfs]
[287480.751547]  ? extHint+0x7c/0x110 [jfs]
[287480.751552]  jfs_get_block+0xa1/0x2b0 [jfs]
[287480.751557]  ? pagecache_get_page+0xf2/0x2c0
[287480.751561]  nobh_write_begin+0x161/0x4c0
[287480.751567]  jfs_write_begin+0x32/0x70 [jfs]
[287480.751572]  ? jfs_release+0x60/0x60 [jfs]
[287480.751575]  generic_perform_write+0xf4/0x1b0
[287480.751579]  __generic_file_write_iter+0xfe/0x1c0
[287480.751582]  generic_file_write_iter+0xab/0x150
[287480.751585]  new_sync_write+0x112/0x180
[287480.751588]  vfs_write+0xa5/0x1a0
[287480.751590]  ksys_write+0x4f/0xb0
[287480.751594]  do_syscall_64+0x53/0x100
[287480.751598]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[287480.751601] RIP: 0033:0x482c67
[287480.751606] Code: Bad RIP value.
[287480.751607] RSP: 002b:7f3a5b132bd0 EFLAGS: 0293 ORIG_RAX: 
0001
[287480.751609] RAX: ffda RBX: 0003 RCX: 
00482c67
[287480.751610] RDX: f000 RSI: 7fff8a22a55c RDI: 
0003
[287480.751611] RBP: 7fff8a22a55c R08:  R09: 
7fff8a229058
[287480.751612] R10:  R11: 0293 R12: 
f000
[287480.751613] R13: f000 R14: 7fff8a22a55c R15: 
f000
[287480.751626] kworker/u8:1D0 65623  2 0x8000
[287480.751631] Workqueue: writeback wb_workfn (flush-8:32)
[287480.751633] Call Trace:
[287480.751637]  ? __schedule+0x2d4/0x870
[287480.751640]  schedule+0x28/0x70
[287480.751642]  rwsem_down_write_failed+0x17c/0x3a0
[287480.751645]  call_rwsem_down_write_failed+0x13/0x20
[287480.751648]  down_write+0x29/0x40
[287480.751652]  jfs_get_block+0x59/0x2b0 [jfs]
[287480.751657]  __mpage_writepage+0x2b8/0x790
[287480.751661]  ? page_mkclean+0x6e/0xc0
[287480.751663]  ? invalid_page_referenced_vma+0x80/0x80
[287480.751666]  ? clear_page_dirty_for_io+0x230/0x2a0
[287480.751669]  write_cache_pages+0x1aa/0x440
[287480.751671]  ? clean_buffers+0x60/0x60
[287480.751677]  ? jfs_release+0x60/0x60 [jfs]
[287480.751680]  mpage_writepages+0x75/0x100
[287480.751684]  ? jfs_release+0x60/0x60 [jfs]
[287480.751687]  do_writepages+0x41/0xd0
[287480.751692]  ? jfs_commit_inode+0x89/0x100 [jfs]
[287480.751695]  __writeback_single_inode+0x3d/0x350
[287480.751697]  writeback_sb_inodes+0x1e5/0x480
[287480.751701]  __writeback_inodes_wb+0x5d/0xb0
[287480.751703]  wb_writeback+0x25f/0x2f0
[287480.751706]  wb_workfn+0x30d/0x400
[287480.751709]  ? __switch_to+0x8c/0x440
[287480.751714]  process_one_work+0x1a7/0x3b0
[287480.751717]  worker_thread+0x30/0x390
[287480.751720]  ? create_worker+0x1a0/0x1a0
[287480.751722]  kthread+0x112/0x130
[287480.751724]  ? __kthread_parkme+0x70/0x70
[287480.751726]  ret_from_fork+0x1f/0x40
[287480.751732] syncD0 67361  67333 0x
[287480.751734] Call Trace:
[287480.751737]  ? __schedule+0x2d4/0x870
[287480.751741]  ? default_file_splice_write+0x20/0x20
[287480.751743]  schedule+0x28/0x70
[287480.751745]  wb_wait_for_completion+0x5e/0x90
[287480.751749]  ? finish_wait+0x80/0x80
[287480.751751]  sync_inodes_sb+0xd8/0x2c0
[287480.751754]  ? default_file_splice_write+0x20/0x20
[287480.751757]  iterate_supers+0x98/0x100
[287480.751760]  ksys_sync+0x40/0xb0
[287480.751763]  __ia32_sys_sync+0xa/0x10
[287480.751765]  do_syscall_64+0x53/0x100
[287480.751768]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[287480.751769] RIP: 0033:0x7f8cd49bf287
[287480.751772] Code: Bad RIP value.
[287480.751773] RSP: 002b:7ffc3ac18868 EFLAGS: 0202 ORIG_RAX: 
00a2
[287480.751775] RAX: ffda RBX: 7ffc3ac18998 RCX: 
7f8cd49bf287
[287480.751776] RDX: 7f8cd4a8c001 RSI:  RDI: 
7f8cd4a50b3a
[287480.751777] RBP: 0001 R08:  R09: 

[287480.751778] R10: fb34 R11: 0202 R12: 

[287480.751779] R13:  R14:  R15: 

-END OUTPUT-
-
Please limit your reply to 7-bit ASCII.
I refuse to see your idiotic emoji in a TTY.
-BEGIN PGP SIGNATURE-
Version: ProtonMail
Comment: https://protonmail.com

wsBcBAEBCAAGBQJc6naeAAoJENi1YDlFXXQf+XkH/RO/ifsa3vdcOzFrHQYq

Bug#929573: x2go server openGL errors are printed in high volume at less than a, millisecond time-scale to the log file

2019-05-26 Thread Piotr Balwierz


Package: x2goserver
Version: 4.1.0.3-4

Debian Buster
CC: sub...@bugs.x2go.org


OpenGL error messages from gl_surface_qt.cpp (qtwebengine likely) are printed 
on 0.01 of a millisecond time scale (i.e. 10^5 messages per second) to a log 
file.
Currently my log file is 16 TB in size. This is a error log file from a single 
session, because https://bugs.x2go.org/cgi-bin/bugreport.cgi?bug=923 is 
resolved.

$ls -la ~/.xsession-x2go*
-rw--- 1 user users 17557623775232 May  2 23:40 .xsession-x2go-mamut-errors
-rw--- 1 user users  38176 Jun 18  2018 
.xsession-x2go-mamut-errors.old


The content of the file is extremely boring:
[...]
[51916:52005:0422/215628.936583:ERROR:gl_surface_qt.cpp(296)] 
eglCreatePbufferSurface failed and surfaceless context not available
[51916:52005:0422/215628.936597:ERROR:gl_surface_qt.cpp(303)] Requested OpenGL 
implementation is not supported. Implementation: 0
[51916:52005:0422/215628.936612:ERROR:gl_surface_qt.cpp(296)] 
eglCreatePbufferSurface failed and surfaceless context not available
[51916:52005:0422/215628.936627:ERROR:gl_surface_qt.cpp(303)] Requested OpenGL 
implementation is not supported. Implementation: 0
[51916:52005:0422/215628.936642:ERROR:gl_surface_qt.cpp(296)] 
eglCreatePbufferSurface failed and surfaceless context not available
[51916:52005:0422/215628.936656:ERROR:gl_surface_qt.cpp(303)] Requested OpenGL 
implementation is not supported. Implementation: 0
[...]

(ad infinitum)

I was definitely running Rstudio desktop in x2go session, but don't know if it 
was generating these messages.


Expected behaviour: Too quickly appearing messages from the same process should 
not end up in the log file. systemd-journald if I am correct has such a feature.
I am not reporting it to qtwebengine or Rstudio right now. Will do if 
encouraged in your comments.



Regards,
Piotr

Bug#929567: libgtk-3-0:amd64: Emacs constantly crashes on startup with "X protocol error: BadLength..."

2019-05-26 Thread Vincent Lefevre

Control: forwarded -1 https://gitlab.gnome.org/GNOME/gtk/issues/221

(This is the new upstream bug URL.)

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

Bug#929572: unblock: dpkg-cross/2.6.15-2.1

2019-05-26 Thread Neil Williams

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

Please unblock package dpkg-cross

I've applied the patch supplied by Helmut in bug #868483
and I've left further optimisations to be done during the
bullseye cycle.

dpkg-cross-868483.diff is attached.

I've uploaded this small change with --delayed 1

Thanks.

unblock dpkg-cross/2.6.15-2.1

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

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

 config/cross-config.alpha|1 +
 config/cross-config.amd64|1 +
 config/cross-config.hppa |1 +
 config/cross-config.m68k |1 +
 config/cross-config.mips64el |1 +
 config/cross-config.ppc64el  |1 +
 config/cross-config.s390x|1 +
 debian/changelog |9 +
 8 files changed, 16 insertions(+)

diff -Nru dpkg-cross-2.6.15/config/cross-config.alpha 
dpkg-cross-2.6.15/config/cross-config.alpha
--- dpkg-cross-2.6.15/config/cross-config.alpha 2015-01-22 19:16:37.0 
+
+++ dpkg-cross-2.6.15/config/cross-config.alpha 2019-05-26 11:54:08.0 
+0100
@@ -1,3 +1,4 @@
+. `dirname $ac_site_file`/cross-config.cache
 #
 # alpha specific configure variables
 #
diff -Nru dpkg-cross-2.6.15/config/cross-config.amd64 
dpkg-cross-2.6.15/config/cross-config.amd64
--- dpkg-cross-2.6.15/config/cross-config.amd64 2011-03-27 07:14:10.0 
+0100
+++ dpkg-cross-2.6.15/config/cross-config.amd64 2019-05-26 11:54:08.0 
+0100
@@ -1,3 +1,4 @@
+. `dirname $ac_site_file`/cross-config.cache
 #
 # amd64-specific configuration variables
 #
diff -Nru dpkg-cross-2.6.15/config/cross-config.hppa 
dpkg-cross-2.6.15/config/cross-config.hppa
--- dpkg-cross-2.6.15/config/cross-config.hppa  2011-03-27 07:14:10.0 
+0100
+++ dpkg-cross-2.6.15/config/cross-config.hppa  2019-05-26 11:54:08.0 
+0100
@@ -1,3 +1,4 @@
+. `dirname $ac_site_file`/cross-config.cache
 #
 # hppa specific configure variables
 #
diff -Nru dpkg-cross-2.6.15/config/cross-config.m68k 
dpkg-cross-2.6.15/config/cross-config.m68k
--- dpkg-cross-2.6.15/config/cross-config.m68k  2011-03-27 07:14:10.0 
+0100
+++ dpkg-cross-2.6.15/config/cross-config.m68k  2019-05-26 11:54:08.0 
+0100
@@ -1,3 +1,4 @@
+. `dirname $ac_site_file`/cross-config.cache
 #
 # m68k specific configure variables
 #
diff -Nru dpkg-cross-2.6.15/config/cross-config.mips64el 
dpkg-cross-2.6.15/config/cross-config.mips64el
--- dpkg-cross-2.6.15/config/cross-config.mips64el  1970-01-01 
01:00:00.0 +0100
+++ dpkg-cross-2.6.15/config/cross-config.mips64el  2019-05-26 
11:54:08.0 +0100
@@ -0,0 +1 @@
+. `dirname $ac_site_file`/cross-config.cache
diff -Nru dpkg-cross-2.6.15/config/cross-config.ppc64el 
dpkg-cross-2.6.15/config/cross-config.ppc64el
--- dpkg-cross-2.6.15/config/cross-config.ppc64el   1970-01-01 
01:00:00.0 +0100
+++ dpkg-cross-2.6.15/config/cross-config.ppc64el   2019-05-26 
11:54:08.0 +0100
@@ -0,0 +1 @@
+. `dirname $ac_site_file`/cross-config.cache
diff -Nru dpkg-cross-2.6.15/config/cross-config.s390x 
dpkg-cross-2.6.15/config/cross-config.s390x
--- dpkg-cross-2.6.15/config/cross-config.s390x 1970-01-01 01:00:00.0 
+0100
+++ dpkg-cross-2.6.15/config/cross-config.s390x 2019-05-26 11:54:08.0 
+0100
@@ -0,0 +1 @@
+. `dirname $ac_site_file`/cross-config.cache
diff -Nru dpkg-cross-2.6.15/debian/changelog dpkg-cross-2.6.15/debian/changelog
--- dpkg-cross-2.6.15/debian/changelog  2017-07-24 17:09:56.0 +0100
+++ dpkg-cross-2.6.15/debian/changelog  2019-05-26 11:54:15.0 +0100
@@ -1,3 +1,12 @@
+dpkg-cross (2.6.15-2.1) unstable; urgency=medium
+
+  [ Helmut Grohne ]
+  * Non-maintainer upload.
+  * cross-config: Ensure that every release arch uses the common file.
+(Closes: #868483)
+
+ -- Neil Williams   Sun, 26 May 2019 11:54:15 +0100
+
 dpkg-cross (2.6.15-2) unstable; urgency=medium
 
   * Make code perl 5.26-compatible (escape left braces in regexps).

Bug#868483: cross-config: cross-config files missing for multiple architectures

2019-05-26 Thread Neil Williams

On Sat, 25 May 2019 07:21:19 +0200 Helmut Grohne 
wrote:
> Control: severity -1 serious
> 
> On Sat, May 25, 2019 at 02:13:39AM +0100, Wookey wrote:
> > > I think this should be fixed asap, ideally in buster. Do you
> > > agree with bumping this bug to rcness?
> > 
> > Yes
> 
> Bumped.
> 
> > > Do you also agree with removing all ac_cv_sizeof_*? (At a later
> > > time)
> > 
> > If they are no longer needed by builds, yes. Do packages actually
> > get these from the compiler now or does something else populate
> > these variables when crossing?
> 
> "Recent" autotools gained an AC_COMPUTE_INT to determine the value of
> a compile time integral expression. During native compilation it is
> essentially printf("%d", ...). For cross compilation autotools
> implements it using bisection on char "somearray[integral_expression <
> test_value ? 1 : -1];". Repeatedly compiling such programs allows
> deducing the value as negatively sized arrays yield a compilation
> failure. AC_CHECK_SIZEOF is not implemented using AC_COMPUTE_INT.
> 
> Very old configure scripts may still need ac_cv_sizeof_*. The last
> one I knew was blt #772590. I don't think we have an old-enough
> autoconf in the archive, so any package that fails now is missing
> source.
> 
> For these reasons, I think that continuing to maintain ac_cv_sizeof_*
> is not reasonable. And if we do so, we should generate them using
> AC_CHECK_SIZEOF at build time. Or just remove them.

I think it's definitely reasonable to retain ac_cv_sizeof_* for buster.
The list can be optimised and improved for bullseye.

I've prepared a package based on the debdiff from the previous reply
and I'll upload today.


-- 


Neil Williams
=
http://www.linux.codehelp.co.uk/



pgp56i43zLFrC.pgp
Description: OpenPGP digital signature

Bug#922346: Fix for this issue still not available in testing

2019-05-26 Thread Michel Le Bihan

Hello,

I saw that Mesa 18.3.6-2 was accepted into unstable on 2019-05-11. That
version still hasn't migrated to testing because of the freeze. Could
you please contact the release team to get this release in testing ASAP
as I (and probably other users) am still experiencing this issue and it
is very critical because opening a media file can cause my DE to crash
causing the loss of any unsaved work.

Michel Le Bihan

Bug#929397: ftp.d.o: please upload LTS .buildinfo files to ftp-master

2019-05-26 Thread Chris Lamb

Holger Levsen wrote:

> > > | for ftp.d.o there's a cronjob running as my user on 
> > > coccia.d.o,
> > >   which surely is a hack, but works for now. […]
> >
> > Would a "clean" dak-based solution…
> >
> > > Also please note that this bug will only become relevant when Stretch
> > > becomes LTS as only dpkg from stretch (and newer) produces .buildinfo
> > > files.
> >
> > … mean this is easily implemented for LTS too by "simply" updating the
> > version of dak to this hypothetical version?
> 
> I don't think so, but I really don't know that much about dak and how
> it's set up.

Can you clarify your "don't think so"? Note that I was talking about a
hypothetical improved/patched version of dak that had native support
for publishing .buildinfo files, not the current one.


Regards,

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

Bug#929571: unblock: dgit/8.5

2019-05-26 Thread Ian Jackson

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

Please unblock package dgit

I have discovered an annoying bug in a common error handling pattern
in dgit, which results in it not printing errno when it is crashing
for an unexpected reason.

I would like to fix it in buster for two reasons:

 * It makes some kinds of failure much harder to diagnose.

 * The fix, while conceptually extremely simple, and extremely
   formulaic, is textually very large.  I would like to avoid such a
   big textual divergence between buster and future development;
   primarily to avoid textual conflicts when back-porting /
   forward-porting any future bugfixes to the stable branch.

I attach the git commit which explains the details.  Assuming you give
the go-ahead, I will upload this with an appropriate changelog update.

unblock dgit/8.5

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

Kernel: Linux 4.19.0-0.bpo.2-amd64 (SMP w/4 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
>From d28467db161d0590469b5f8e1115f84858d66e06 Mon Sep 17 00:00:00 2001
From: Ian Jackson 
Date: Sun, 26 May 2019 10:50:23 +0100
Subject: [PATCH] Replace `confess $!' with `confess "$!"', to actually print
 errno

  $ perl -e 'use Carp; open X, ">/dev/eacces" or die $!'
  Permission denied at -e line 1.
  $ perl -e 'use Carp; open X, ">/dev/eacces" or confess $!'
   at -e line 1.
  $ perl -e 'use Carp; open X, ">/dev/eacces" or confess "$!"'
  Permission denied at -e line 1.
  $

confess will get references to its arguments in @_.  Its documentation
says it saves/restores $!.  I conjecture that these interact as we see
here:
  $ perl -e '$!=1; sub x { print ">@_<\n"; }  x $!;'
  >Operation not permitted<
  $ perl -e '$!=1; sub x { local $!; print ">@_<\n"; }  x $!;'
  ><

Quoting "$!" averts the reference (and it will also ensure that we
get the string value of $!, in case confess were to do anything in the
future which would mess that up).

This commit was made like this:

  perl -i -pe 's/confess \$!/confess "\$!"/g' dgit
  perl -i -pe 's/confess \$!/confess "\$!"/g' git-debrebase
  perl -i -pe 's/confess \$!/confess "\$!"/g' Debian/Dgit.pm

I have manually reviewed each hunk and it all looks good to me.

Closes: #929549
Signed-off-by: Ian Jackson 
---
 Debian/Dgit.pm |  56 +++---
 dgit   | 240 -
 git-debrebase  |  42 +-
 3 files changed, 169 insertions(+), 169 deletions(-)

diff --git a/Debian/Dgit.pm b/Debian/Dgit.pm
index 2ef32f32..61476d9f 100644
--- a/Debian/Dgit.pm
+++ b/Debian/Dgit.pm
@@ -148,11 +148,11 @@ sub setup_sigwarn () {
 
 sub initdebug ($) { 
 ($debugprefix) = @_;
-open DEBUG, ">/dev/null" or confess $!;
+open DEBUG, ">/dev/null" or confess "$!";
 }
 
 sub enabledebug () {
-open DEBUG, ">" or confess $!;
+open DEBUG, ">" or confess "$!";
 DEBUG->autoflush(1);
 $debuglevel ||= 1;
 }
@@ -181,7 +181,7 @@ sub printdebug {
 print DEBUG $debugprefix unless $printdebug_noprefix;
 pop @_ while @_ and !length $_[-1];
 return unless @_;
-print DEBUG @_ or confess $!;
+print DEBUG @_ or confess "$!";
 $printdebug_noprefix = $_[-1] !~ m{\n$};
 }
 
@@ -214,9 +214,9 @@ sub shellquote {
 sub printcmd {
 my $fh = shift @_;
 my $intro = shift @_;
-print $fh $intro," " or confess $!;
-print $fh shellquote @_ or confess $!;
-print $fh "\n" or confess $!;
+print $fh $intro," " or confess "$!";
+print $fh shellquote @_ or confess "$!";
+print $fh "\n" or confess "$!";
 }
 
 sub debugcmd {
@@ -347,7 +347,7 @@ sub waitstatusmsg () {
 sub failedcmd_report_cmd {
 my $intro = shift @_;
 $intro //= __ "failed command";
-{ local ($!); printcmd \*STDERR, _us().": $intro:", @_ or confess $!; };
+{ local ($!); printcmd \*STDERR, _us().": $intro:", @_ or confess "$!"; };
 }
 
 sub failedcmd_waitstatus {
@@ -395,7 +395,7 @@ sub cmdoutput_errok {
 my $d;
 $!=0; $?=0;
 { local $/ = undef; $d = ; }
-confess $! if P->error;
+confess "$!" if P->error;
 if (!close P) { printdebug "=>!$?\n"; return undef; }
 chomp $d;
 if ($debuglevel > 0) {
@@ -528,10 +528,10 @@ sub git_cat_file ($;$) {
 if (!$gcf_pid) {
my @cmd = qw(git cat-file --batch);
debugcmd "GCF|", @cmd;
-   $gcf_pid = open2 $gcf_o, $gcf_i, @cmd or confess $!;
+   $gcf_pid = open2 $gcf_o, $gcf_i, @cmd or confess "$!";
 }
 printdebug "GCF>| $objname\n";
-print $gcf_i $objname, "\n" or confess $!;
+print $gcf_i $objname, "\n" or confess "$!";
 my $x = <$gcf_o>;
 printdebug "GCF<| ", $x;
 if ($x =~ m/ (missing)$/) { return $chk->($1, undef); }
@@

Bug#926242: jenkins.debian.org: Please test reproducibility status of Debian Installer images

2019-05-26 Thread Chris Lamb

Dear Colin,

> >   
> > https://salsa.debian.org/installer-team/debian-installer/commit/fa965c32ca8bfa2ff14886c6f0dca131532815c7
[…]
> I'm not certain even after going through my IRC and email logs around
> that time, but given the timing I suspect that it was a workaround for
> multiarch systems where sources.list contained some lines with
> [arch=...] options to limit them to only some architectures.

Thank for looking into this.

> It would be worth somebody trying out a d-i build on a system with this
> kind of configuration to see if it still breaks
  ^

Just to clarify, building d-i on a system with [arch=...] foo in its
/etc/apt/sources.list?


Best wishes,

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

Bug#929567: libgtk-3-0:amd64: Emacs constantly crashes on startup with "X protocol error: BadLength..."

2019-05-26 Thread Vincent Lefevre

On 2019-05-26 11:05:01 +0200, Vincent Lefevre wrote:
> Package: libgtk-3-0
> Version: 3.24.5-1
> Severity: grave
> Tags: upstream
> Justification: renders package unusable
> 
> When starting Emacs on a large file, I always get the following error.
> This makes Emacs impossible to use.
[...]

I've tried a dozen of times, and it's 100% reproducible.

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

Bug#836609: nostalgy: please make the build reproducible

2019-05-26 Thread Chris Lamb

reopen 836609
found 836609 0.2.36-1.2
tags 836609 + patch
thanks

Hi Pollo,

Thanks for applying my reproducibility patch in your nostalgy
0.2.36-1.2 upload. However, it seems like it was incomplete:

│ │ │ ├── ./usr/share/xul-ext/nostalgy/chrome/nostalgy.jar
│ │ │ │ ├── bsdtar -tvf {}
│ │ │ │ │ @@ -1,20 +1,20 @@
│ │ │ │ │ --rw-r--r--  0    11787 Jan 20 17:40 content/about.xhtml
│ │ │ │ │ --rw-r--r--  0      518 Jan 20 17:40 content/about.xul
│ │ │ │ │ --rw-r--r--  0     1611 Jan 20 17:40 content/composer.js
│ │ │ │ │ +-rw-r--r--  0    11787 Jan 20 17:40 content/about.xhtml
│ │ │ │ │ +-rw-r--r--  0      518 Jan 20 17:40 content/about.xul
│ │ │ │ │ +-rw-r--r--  0     1611 Jan 20 17:40 content/composer.js

I think we need:

--- a/debian/patches/0003-Reproducible-build.patch
+++ b/debian/patches/0003-Reproducible-build.patch
 @@ -72,7 +72,10 @@ find content -path '*.svn*' -prune -o -t
  find locale -path '*.svn*' -prune -o -type f -print | grep -v \~ >> files

-+LC_ALL=C sort files | zip -0 $JAR_FILE -@
++LC_ALL=C sort files | zip --no-extra -0 $JAR_FILE -@
  # The following statement should be used instead if you don't wish to use the 
JAR file


Regards,

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

1 2 >

1 - 100 of 114 matches

Mail list logo