Bug#895641: ITP: ruby-tomlrb -- A racc based toml parser

[Pirate Praveen]

On April 14, 2018 2:18:20 AM GMT+05:30, Stefano Rivera  
wrote:
>Package: wnpp
>Severity: wishlist
>Owner: Stefano Rivera 
>
>* Package name: ruby-tomlrb
>  Version : 1.2.6
>  Upstream Author : Francois Bernier 
>* URL : https://github.com/fbernier/tomlrb
>* License : Expat
>  Programming Lang: Ruby
>  Description : A racc based toml parser
>
>A Racc based TOML Ruby parser supporting the 0.4.0 version of the spec.

There is already a ruby-toml package, 
https://tracker.debian.org/pkg/ruby-toml

Can this be used instead?

>This is a dependency of the Chef stack.
>
>I intend to package it within the ruby team.

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Bug#887107: https://i18n.debian.org/material/data/unstable.gz not updated since 2017-11-23

[Christian PERRIER]

Quoting Laura Arjona Reina (larj...@debian.org):
> Hello
> The material data has not been updated, there are more packages
> producing errors.
> I've added them as exceptions to the config file, to workaround the
> issue (as with my previous patch).
> Christian, do you mind to update again the repo in tye, to see if
> tomorrow the material data is produced?
> I wouldn't mind to join the debian-i18n unix group so I can do it
> myself, if that's ok with you too, but I'm not sure about the procedure.
> Thanks!

I just "git pulled" again.

And I launched thte
/srv/i18n.debian.org/etc/cron.d/10gen-material-unstable script
manually, just to see what happens. Indeed, we get a daily cron
message which I (sadly) ignored for ages.that's quite probably the
problem.

debian-i18n crontab on tye has:
MAILTO="brot...@debian.org,bubu...@debian.org,f...@debian.org,nek...@debian.org,taf...@debian.org"

but it seems that all of us are ignoring these mails nowadays.

I don't remember how one can be added to the right group on Debian
machines and be allowed to "sudo" to debian-i18n. I suspect this
should be done with a ticket to the Debian admin team.

At minimum, I can add your mail address to this crontab, Laura, tthat
may help



signature.asc
Description: PGP signature

Bug#895652: gnu-standards: New versions are not found

[Bjarni Ingi Gislason]

Package: gnu-standards
Version: 2010.03.11-1
Severity: important

Dear Maintainer,

  New versions are not found according to 
"tracker.debian.org/pkg/gnu-standards".

  The upstream sources are in "www.gnu.org/prep/standards"

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

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

Versions of packages gnu-standards depends on:
ii  dpkg  1.19.0.5
ii  install-info  6.5.0.dfsg.1-2

gnu-standards recommends no packages.

gnu-standards suggests no packages.

-- no debconf information

-- 
Bjarni I. Gislason

Bug#895651: djvubind dies when trying to encode "mixed mode images" from scantailor

[Rogério Brito]

Package: djvubind
Version: 1.2.1-3
Severity: important

Hi, Clint.

When trying to create a book with some tiff files that were (very
laboriously) generated by scantailor (with lots of fine-tuning by hand), I
get the following, very non-informative stack trace from djvubind, when I
have files that are "mixed mode":

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
(...)
msg: s-260_1L.tif: Bitonal image but with a depth greater than 1.  Modifying 
image depth.
msg: s-260_2R.tif: Bitonal image but with a depth greater than 1.  Modifying 
image depth.
* Performing optical character recognition.
  OCR is disabled and will be skipped.
* Encoding all information to /tmp/solutions/out/book.djvu.
Traceback (most recent call last):
  File "/usr/bin/djvubind", line 446, in 
proj.bind()
  File "/usr/bin/djvubind", line 171, in bind
self.enc.enc_book(self.book, self.out)
  File "/usr/lib/python3/dist-packages/djvubind/encode.py", line 281, in 
enc_book
self._csepdjvu(page.path, tempfile, page.dpi)
  File "/usr/lib/python3/dist-packages/djvubind/encode.py", line 137, in 
_csepdjvu
self._cjb2('temp_textual.tif', 'enc_bitonal_out.djvu', dpi)
  File "/usr/lib/python3/dist-packages/djvubind/encode.py", line 84, in _cjb2
utils.execute(cmd)
  File "/usr/lib/python3/dist-packages/djvubind/utils.py", line 193, in execute
print(utils.color("err: [utils.execute()] Command exited with bad status.", 
'red'), file=sys.stderr)
NameError: name 'utils' is not defined
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Digging through, I found that the problem is that the call to cjb2 above is
failing when it is fed the file temp_textual.tif which is supposed to be
only bilevel (that is only black and white).

I found (and tested successfully) that temp_textual.tif isn't being
generated as cjb2 expects because the call to convert that created it isn't
creating a bilevel image.

Adding the option -depth 1 to the line that precedes the call to cjb2 fixes
this.  I am including a patch that I tested here.

It would be super nice if you could upload a new version with this change
applied, since djvubind very frequently dies when I try to convert some
books.


Thanks for packaging djvubind,

Rogério Brito.


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

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

Versions of packages djvubind depends on:
ii  djvulibre-bin3.5.27.1-8
ii  imagemagick  8:6.9.9.34+dfsg-3+b1
ii  imagemagick-6.q16 [imagemagick]  8:6.9.9.34+dfsg-3+b1
ii  python3  3.6.4-1
ii  tesseract-ocr4.00~git2219-40f43111-1.2

Versions of packages djvubind recommends:
ii  minidjvu  0.8.svn.2010.05.06+dfsg-5+b4

djvubind suggests no packages.

-- no debconf information

-- 
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC
http://cynic.cc/blog/ : github.com/rbrito : profiles.google.com/rbrito
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
>From 99aa73b107a233c8306f157e7351fba8013adb5c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Rog=C3=A9rio=20Brito?= 
Date: Sat, 14 Apr 2018 01:29:17 -0300
Subject: [PATCH] djvubind/encode: Force file to cjb2 to be only black and
 white.
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Note above that convert (Debian's at least), even if asked to
create a monochrome tif will still generate one with 8 bits per
color and cj2b will barf, telling us (correctly) that it is not in
a format that it accepts.

The -depth 1 forces convert to generate a bilevel grayscale tif.

An alternative to using -depth 1 would be to specify the extension
as .pbm, but we would, then, need to modify the name of the file
in more places.

Signed-off-by: Rogério Theodoro de Brito 
---
 djvubind/encode.py | 13 -
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/djvubind/encode.py b/djvubind/encode.py
index b0ed70d..b6622d3 100644
--- a/djvubind/encode.py
+++ b/djvubind/encode.py
@@ -131,7 +131,18 @@ class Encoder:
 #utils.execute('convert -opaque black "{0}" "temp_graphics.tif"'.format(infile))
 #utils.execute('convert +opaque black "{0}" "temp_textual.tif"'.format(infile))
 utils.execute('convert "{0}" -opaque black "temp_graphics.tif"'.format(infile))
-utils.execute('convert "{0}" +opaque black -monochrome "temp_textual.tif"'.format(infile))
+utils.execute('convert "{0}" +opaque black -monochrome -depth 1 

Bug#895648: [gitlab] Add keyword that allows the inclusion of external YAML files

[Pirate Praveen]

On April 14, 2018 6:21:00 AM GMT+05:30, Agustin Henze  wrote:
>Package: gitlab
>Severity: normal
>
>Hi, this feature is not included in the CE version. Here
>https://gitlab.com/help/ci/yaml/README#include it says the following
>
>```
>Introduced in [GitLab Edition
>Premium](https://about.gitlab.com/gitlab-ee/) 10.5.
>Available for Starter, Premium and Ultimate
>[versions](https://about.gitlab.com/products/) since 10.6.
>```
>
>The MR that adds this feature is here
>https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/4262 and the
>related
>issue
>https://gitlab.com/gitlab-org/gitlab-ce/issues/20868#note_14082877. As
>you can see it says
>
>"Since this is targeting larger organizations, it will be `EE
>Premium`."
>
>Debian is a large organization... Can we ask for this feature as Debian
>Project
>to Gitlab? or we have to patch it and maintain a fork of gitlab
>forever? I
>understand that the policy is not patching gitlab if possible. But I
>think in
>this case, it would be really useful for us. Because we are going to
>have
>really similar pipelines between projects and I am sure we can unify
>this and
>maintain one generic pipeline for most of the packages or at least per
>maintainer. I already have two projects with the same CI pipeline at
>this
>moment. I'll be migrating the rest of my packages and they will share
>the same
>pipeline so I have to keep a copy updated on every project...
>
>PS: I've created an issue on salsa[0] for this. I think it applies as a
>feature
>request. Please let me know if here is the correct place to discuss
>this and
>I'll close the issue on salsa.

Salsa is the right place, as salsa.debian. org does not use the gitlab package.

>[0] https://salsa.debian.org/salsa/support/issues/64

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Bug#895650: [kernel] Suspend only works 1st time for Acer S7 392

[Ted To]

Package: kernel
Version: 4.14.0-0.bpo.3-amd64
Severity: important

--- Please enter the report below this line. ---
Suspend only works first time.  It worked fine on an ancient Acer Aspire
One.  Now on an Acer S7 392, suspend works on its first try but
afterwards fails.  Currently running the backports kernel but didn't
work with stable either.

--- System information. ---
Architecture: Kernel:   Linux 4.14.0-0.bpo.3-amd64

Debian Release: 9.4
  500 stable-updates  deb.debian.org   500 stable
repository.spotify.com   500 stable  deb.debian.org   100
stretch-backports deb.debian.org
--- Package information. ---
Package's Depends field is empty.

Package's Recommends field is empty.

Package's Suggests field is empty.

Bug#866353: rsync: wrong Architecture field in cross built binary package

[Boyuan Yang]

Hi Paul,

Five months have passed and this problem hasn't been fixed yet. Is there any 
progress on your side?


Thanks,
Boyuan Yang

在 2017年11月2日星期四 CST 上午4:45:41，您写道：
> 2017-11-01 10:02 GMT+01:00 Paul Slootman :
> > On Tue 31 Oct 2017, Manuel A. Fernandez Montecelo wrote:
> >> Many packages build-depend on rsync, and this patch seems like a net
> >> gain to apply even in the absence of more benefits.
> >> 
> >> What do you think about applying it, Paul?
> > 
> > Yes, you're right.
> > I have prepared a new package, however uploading may be delayed a couple
> > of days due to another issue. Please be patient.

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

Bug#895000: atril always shows a stacktrace/crash from webkit displaying pdf files

[Rogério Brito]

Hi.

On Fri, Apr 13, 2018 at 2:53 PM, Jeremy Bicha  wrote:
> Control: forwarded -1 https://bugs.webkit.org/show_bug.cgi?id=183348
> Control: severity -1 important
>
> Here's the upstream webkit2gtk bug report for the issue affecting
> xreader (a fork of atril not in Debian) and atril.

Oh, sure... I forgot to set the forwarded field. Thanks.

Regarding your latest email (I only saw it because I went to the BTS),
I can confirm that, on two computers, upgrading webkitgtk does fix the
issue at hand.

A bit off-topic here, but since we are talking about atril and you are
probably worried about Ubuntu 18.04 being a LTS release, you may want
to know about this bug that I filed before (just checked and bionic's
changelog doesn't seem to have it):

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



Thanks,

-- 
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC
http://cynic.cc/blog/ : github.com/rbrito : profiles.google.com/rbrito
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br

Bug#895649: inkscape: Segfault closing dialog after importing PDF

[Kevin Locke]

Package: inkscape
Version: 0.92.3-1
Severity: normal

Dear Maintainer,

I am able to reliably produce a crash due to SIGSEGV when closing the
Layers dialog using the following procedure:

1.  Open Inkscape.
2.  Open the Layers dialog (Shift+Ctrl+L or Layer->Layers).
3.  Open a PDF file (File->Open select .pdf file, press OK, then
press OK to default import settings.)
4.  Open a second, PDF file with a different name (can be same or
different file contents).
This should open a second window for second PDF, but the second
window will have no dialogs open while the first window has two
duplicate Layers dialogs open.
5.  Close both of the Layers dialog in window for the first PDF file.
6.  Switch to the Inkscape window for the second PDF file.

At this point Inkscape will crash with SIGSEGV and the following
backtrace:

#0  0x75cdbfea in g_type_get_qdata ()
at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#1  0x70574ccb in Glib::wrap_auto(_GObject*, bool) ()
at /usr/lib/x86_64-linux-gnu/libglibmm-2.4.so.1
#2  0x71b5292d in Glib::wrap(_GtkWidget*, bool) ()
at /usr/lib/x86_64-linux-gnu/libgtkmm-2.4.so.1
#3  0x77372200 in Inkscape::UI::Widget::DockItem::getWidget() 
(this=) at ./src/ui/widget/dock-item.cpp:109
#4  0x77372fa0 in Inkscape::UI::Widget::DockItem::getWindow() 
(this=) at ./src/ui/widget/dock-item.cpp:457
#5  0x771f1c3a in 
Inkscape::UI::Dialog::Behavior::DockBehavior::onDesktopActivated(SPDesktop*) 
(this=0x5a59fe30, desktop=0x564c9800)
at ./src/ui/dialog/dock-behavior.cpp:248
#6  0x774fab38 in sigc::internal::signal_emit1::emit(sigc::internal::signal_impl*, SPDesktop* const&) 
(_A_a1=@0x7fffd5b8: 0x564c9800, impl=0x56fe4ad0)
at /usr/include/sigc++-2.0/sigc++/signal.h:1045
#7  0x774fab38 in sigc::signal1::emit(SPDesktop* const&) const (this=0x5590fa50, 
_A_a1=@0x7fffd5b8: 0x564c9800) at 
/usr/include/sigc++-2.0/sigc++/signal.h:2955
#8  0x774fab38 in Inkscape::Application::activate_desktop(SPDesktop*) 
(this=0x5590fa00, desktop=) at ./src/inkscape.cpp:882
#9  0x774284b4 in SPDesktopWidget::onFocusInEvent(_GdkEventFocus*) 
(this=0x55866410) at ./src/widgets/desktop-widget.cpp:1919
#10 0x71b4f24b in  () at /usr/lib/x86_64-linux-gnu/libgtkmm-2.4.so.1
#11 0x710f62ab in  () at /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
#12 0x75cb7f6d in g_closure_invoke ()
at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#13 0x75cca8d1 in  () at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#14 0x75cd2d8f in g_signal_emit_valist ()
at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#15 0x75cd3e0f in g_signal_emit ()
at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#16 0x7120c26c in  () at /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
#17 0x710f4a23 in gtk_main_do_event ()
at /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
#18 0x7fffefe8504c in  () at /usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0
#19 0x74a2f287 in g_main_context_dispatch ()
at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#20 0x74a2f4c0 in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#21 0x74a2f7d2 in g_main_loop_run ()
at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#22 0x710f3977 in gtk_main ()
at /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
#23 0xce53 in sp_main_gui(int, char const**) (argc=, 
argv=) at ./src/main.cpp:1164
#24 0x7fffed7e0a87 in __libc_start_main (main=
0xa9c0 , argc=1, argv=0x7fffe008, 
init=, fini=, rtld_fini=, 
stack_end=0x7fffdff8) at ../csu/libc-start.c:310
#25 0xaf2a in _start ()

Note that after step 4 the following messages were printed:

** (inkscape:11143): WARNING **: 19:14:02.898: master 0x57795d80: unable to 
add object 0x5a5abad0[DialogFillStroke] to the hash.  There already is an 
item with that name (0x589e15b0).

** (inkscape:11143): WARNING **: 19:14:02.913: master 0x57795d80: unable to 
add object 0x5a5e62d0[DialogLayers] to the hash.  There already is an item 
with that name (0x589f8500).

If you need any more details or more symbols in the backtrace, let me
know.

Thanks,
Kevin


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

Kernel: Linux 4.16.1-kevinoid1 (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)

Versions of packages inkscape depends on:
ii  libaspell150.60.7~20110707-4
ii  libatk1.0-02.28.1-1
ii  libatkmm-1.6-1v5   

Bug#895648: [gitlab] Add keyword that allows the inclusion of external YAML files

[Agustin Henze]

Package: gitlab
Severity: normal

Hi, this feature is not included in the CE version. Here
https://gitlab.com/help/ci/yaml/README#include it says the following

```
Introduced in [GitLab Edition Premium](https://about.gitlab.com/gitlab-ee/) 
10.5.
Available for Starter, Premium and Ultimate
[versions](https://about.gitlab.com/products/) since 10.6.
```

The MR that adds this feature is here
https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/4262 and the related
issue https://gitlab.com/gitlab-org/gitlab-ce/issues/20868#note_14082877. As
you can see it says

"Since this is targeting larger organizations, it will be `EE Premium`."

Debian is a large organization... Can we ask for this feature as Debian Project
to Gitlab? or we have to patch it and maintain a fork of gitlab forever? I
understand that the policy is not patching gitlab if possible. But I think in
this case, it would be really useful for us. Because we are going to have
really similar pipelines between projects and I am sure we can unify this and
maintain one generic pipeline for most of the packages or at least per
maintainer. I already have two projects with the same CI pipeline at this
moment. I'll be migrating the rest of my packages and they will share the same
pipeline so I have to keep a copy updated on every project...

PS: I've created an issue on salsa[0] for this. I think it applies as a feature
request. Please let me know if here is the correct place to discuss this and
I'll close the issue on salsa.

[0] https://salsa.debian.org/salsa/support/issues/64

-- 
TiN

Bug#876921: python-pint FTBFS with python-numpy 1.13.1: test failures

[Carlos Pascual]

Hi, I fixed this in upstream:

https://github.com/hgrecco/pint/pull/630

Bug#895580: RFS: peek/1.3.1-1 [ITP] -- Simple animated GIF screen recorder with GUI

[Sergio Durigan Junior]

On Thursday, April 12 2018, Boyuan Yang wrote:

>   Dear mentors,
>
>   I am looking for a sponsor for my package "peek"
>
>  * Package name: peek
>Version : 1.3.1-1
>Upstream Author : Philipp Wolfer 
>  * URL : https://github.com/phw/peek
>  * License : GPL-3+
>Section : graphics

Hi, Boyuan,

I'm looking at the package right now.  So far, everything seems to be
OK.  I appreciated the way you took care of the licensing stuff, and how
d/copyright seems to cover all the bases.

I'll let you know if I have questions, or when I upload it.

Thanks for the work,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


signature.asc
Description: PGP signature

Bug#895374: openssh: autopkgtest fails with new release while succeeded in the past

[Colin Watson]

Control: reassign -1 twisted 17.9.0-1
Control: forwarded -1 https://twistedmatrix.com/trac/ticket/9422

On Tue, Apr 10, 2018 at 09:04:16PM +0200, Paul Gevers wrote:
> With the upload of version 1:7.7p1-1 of openssh, the autopkgtest¹
> started to fail.

While the proximate cause was a change in OpenSSH, it's in fact because
it tickled a long-standing bug in Twisted.  I've filed an upstream bug
about this with a patch, and assuming reviewers don't entirely hate it I
think we should cherry-pick the patch into Debian's twisted packages.

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

Bug#492210: Processed: [bts-link] source package texinfo

[Vincent Lefevre]

Control: tags -1 wontfix - fixed-upstream

It is marked as fixed in the upstream BTS, but they did not change
anything and don't seem to want to fix the Info reader to get a
proper fix of this bug.

Perhaps the bug should be reassigned to gmp-doc, as this means that
GMP misuses texinfo.

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

Bug#894441: dpkg-buildpackage: SOURCE_DATE_EPOCH must ignore bin-nmu changelog entries. Breaks M-A:same

[Guillem Jover]

On Fri, 2018-04-13 at 19:01:08 +0100, Ian Jackson wrote:
> > On Thu, Apr 05, 2018 at 05:43:58PM +0200, Jean-Michel Vourgère wrote:
> > > So, during compilation:
> > > SOURCE_DATE_EPOCH must ignore bin-nmu changelog entries
> > > because it breaks Multi-Arch:same on bin-nmu.
> > > 
> > > During dpkg-deb (:
> > > SOURCE_DATE_EPOCH must *not* ignore bin-nmu changelog entries
> > > because it would break software relying on files mtime.
> 
> I don't think we are as doomed as all that.  I analysed this in my
> message here:
> 
>  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=843773#75
> 
> That was in November 2016 and Guillem replied in January 2017 saying,
> essentially, that he still disagreed with the design of multiarch,

No. I think that refcounting in particular (not the entirety of
multiarch) was a misstep (even though it was me who proposed it on the
very early "design sprints"), trading apparent convenience and avoidance
of package increase for a correct and robust foundation. But as it was
also me, after having reverted the patch, the one accepting that path
forward given the rough consensus on debian-devel, I'm happy to share
the blame. I do take issue though, when people complain now that the
consequences of refcounting and binNMUs do not play well together,
because well, "I pretty much already told you so?".

> and that binNMUs are not coinstallable.

> AIUI binNMUs are now coinstallable ?  And that is why 

I think I might not have been explicit enough, but you might notice
there I'm talking about binNMUs with different binary versions (and
obviously same source version) not being in lockstep and not being
coinstallable. And no, they are still not coinstallable, and I'm not
planning on making them so.

> My solution is still applicable, I think.  There is no change to
> wanna-build needed.
> 
> There is a resulting small wrinkle that the on disk mtime of a
> multi-arch shared file may the mtime of any of the source packages.
> Guillem complains that it would make verification difficult, but I
> think that is a soluble problem.  Guillem also complains that the
> mtime may flap; but that is easily avoided by having the on-disk mtime
> only go forwards.

As I also mentioned on my reply, but probably also not explictly
enough, this does not work if you install and remove current instances
and then install another instance. I'm not sure how you'd want dpkg to
track files for removed packages.

In your backup scenario, that would still trip it.

> As for Guillem's complaints about the design of multiarch: these
> concerns were overruled by a decision of the Technical Committee.

No. They were most definitely not. There's never been such ruling.
(And the only related ruling was in vain anyway…)

> I don't think they are good reasons to divert from the
> straightforward, if not entirely neat, course I propose.

That course is not a solution, I'm afraid.

Thanks,
Guillem

Bug#893129: dita-ot FTBFS with openjdk-9

[Markus Koschany]

Dear maintainer,

I've uploaded a new revision of dita-ot versioned as 1.5.3-2.1 which
addresses the build failure with Java 9. Please find attached the debdiff.

Regards,

Markus
diff -Nru dita-ot-1.5.3/debian/changelog dita-ot-1.5.3/debian/changelog
--- dita-ot-1.5.3/debian/changelog  2016-08-29 08:18:47.0 +0200
+++ dita-ot-1.5.3/debian/changelog  2018-04-14 00:56:09.0 +0200
@@ -1,3 +1,10 @@
+dita-ot (1.5.3-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add encoding.patch and fix FTBFS with Java 9. (Closes: #893129)
+
+ -- Markus Koschany   Sat, 14 Apr 2018 00:56:09 +0200
+
 dita-ot (1.5.3-2) unstable; urgency=medium
 
   * Team upload.
diff -Nru dita-ot-1.5.3/debian/patches/encoding.patch 
dita-ot-1.5.3/debian/patches/encoding.patch
--- dita-ot-1.5.3/debian/patches/encoding.patch 1970-01-01 01:00:00.0 
+0100
+++ dita-ot-1.5.3/debian/patches/encoding.patch 2018-04-14 00:56:09.0 
+0200
@@ -0,0 +1,54 @@
+From: Markus Koschany 
+Date: Sat, 14 Apr 2018 00:55:08 +0200
+Subject: encoding
+
+Fix FTBFS with Java 9 by specifying the encoding.
+
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=893129
+---
+ buildPackage.xml | 4 ++--
+ demo/fo/buildPackage.xml | 4 ++--
+ 2 files changed, 4 insertions(+), 4 deletions(-)
+
+diff --git a/buildPackage.xml b/buildPackage.xml
+index 697ac21..969f94f 100644
+--- a/buildPackage.xml
 b/buildPackage.xml
+@@ -72,7 +72,7 @@
+   value="${version}"/>
+ 
++  source="1.5" target="1.5" encoding="iso-8859-1">
+   
+ 
+ 
+@@ -547,4 +547,4 @@
+ 
+   
+ 
+-
+\ No newline at end of file
++
+diff --git a/demo/fo/buildPackage.xml b/demo/fo/buildPackage.xml
+index d55da00..3102218 100644
+--- a/demo/fo/buildPackage.xml
 b/demo/fo/buildPackage.xml
+@@ -48,7 +48,7 @@
+   
+ 
++  source="1.5" target="1.5" encoding="iso-8859-1">
+   
+ 
+   
+@@ -57,7 +57,7 @@
+ 
++  debug="on" encoding="iso-8859-1">
+   
+ 
+   
diff -Nru dita-ot-1.5.3/debian/patches/series 
dita-ot-1.5.3/debian/patches/series
--- dita-ot-1.5.3/debian/patches/series 2012-05-03 10:58:33.0 +0200
+++ dita-ot-1.5.3/debian/patches/series 2018-04-14 00:56:09.0 +0200
@@ -1,3 +1,4 @@
 debian-custom-build.patch
 same-loader-for-tasks.patch
 distribution-saxon-compat.patch
+encoding.patch


signature.asc
Description: OpenPGP digital signature

Bug#895428: Port from libnm-glib/libnm-util to libnm

[Michael Biebl]

Control: severity -1 serious

Hi,

I intend to upload a new version of network-manager soonish which will
drop libnm-glib/libnm-util. I'm thus bumping this issue to RC in
preparation for that.

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#862883: Port from libnm-glib/libnm-util to libnm

[Michael Biebl]

Control: severity -1 serious

Hi,

I intend to upload a new version of network-manager soonish which will
drop libnm-glib/libnm-util. I'm thus bumping this issue to RC in
preparation for that.

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#895444: Uses deprecated NetworkManager.pc

[Michael Biebl]

Control: severity -1 serious

Hi,

I intend to upload a new version of network-manager soonish which will
drop libnm-glib/libnm-util. I'm thus bumping this issue to RC in
preparation for that.

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#862879: Port from libnm-util/libnm-glib to libnm (or GNetworkMonitor)

[Michael Biebl]

Control: severity -1 serious

Hi,

I intend to upload a new version of network-manager soonish which will
drop libnm-glib/libnm-util. I'm thus bumping this issue to RC in
preparation for that.

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#862778: Port from libnm-glib to libnm (or GNetworkMonitor)

[Michael Biebl]

Control: severity -1 serious

Hi,

I intend to upload a new version of network-manager soonish which will
drop libnm-glib/libnm-util. I'm thus bumping this issue to RC in
preparation for that.

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#862877: Port from libnm-glib/libnm-util to libnm

[Michael Biebl]

Control: severity -1 serious

Hi,

I intend to upload a new version of network-manager soonish which will
drop libnm-glib/libnm-util. I'm thus bumping this issue to RC in
preparation for that.

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#862884: Disable libnm-glib support

[Michael Biebl]

Control: severity -1 serious

Hi,

I intend to upload a new version of network-manager soonish which will
drop libnm-glib/libnm-util. I'm thus bumping this issue to RC in
preparation for that.

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#862766: Port from libnm-glib to libnm (or GNetworkMonitor)

[Michael Biebl]

Control: severity -1 serious

Hi,

I intend to upload a new version of network-manager soonish which will
drop libnm-glib/libnm-util. I'm thus bumping this issue to RC in
preparation for that.

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#862757: Should be ported from libnm-glib/libnm-util to libnm

[Michael Biebl]

Control: severity -1 serious

Hi,

I intend to upload a new version of network-manager soonish which will
drop libnm-glib/libnm-util. I'm thus bumping this issue to RC in
preparation for that.

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#862678: Drop leftover Build-Depends on network-manager-dev

[Michael Biebl]

Control: severity -1 serious

Hi,

I intend to upload a new version of network-manager soonish which will
drop libnm-glib/libnm-util. I'm thus bumping this issue to RC in
preparation for that.

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#895647: gnome: Mouse trails after resume from hibernate

[Nagy Attila]

Package: gnome
Version: 1:3.22+3
Severity: important

After resuming from hibernation the mouse on my laptop behaves really
strangely.
Sometimes it shows 2-3-4 mouse cursors, sometimes it show tens or even hundreds
(well, I didn't count them but the screen was covered with it) of mouse
cursors. Generally there is some animation/change in the cursors, so they are
appearing and disappearing on a rhytmical basis. This is what I call "trail" as
it somewhat resembles the "Mouse trail" function from Windows, where the mouse
leaves a trail of 10-20 mouse pointers behind it which shows the path traveled
with the mousein the last few seconds. Only in my case those multiple mouse
cursors aren't disappearing from themselves, I have to change the content of
the windows underneath which on redraw hides these extra pointers.
It is really annoying, because as a bonus the extra mouse pointers are showing
the previous content beneath them. Eg: if I check a checkbox, there is a
certain possibility that exactly that mouse pointer location get memorized, so
it will display the mouse pointer above the checkbox together with the checkbox
(checked or unchecked) and I can't really be sure about the value of the
checkbox unless I move the page or the window to invalidate and redraw that
part of the screen.
Sometimes the extra cursors disappear if I stop moving the mouse, but mostly it
just keeps animating.
A reboot solves the problem, but after another hibernation it starts again.

If the above description is not enough I can try to make a short video of the
problem (screenshot only shows the single mouse cursor on the proper position).

I can reproduce this bug with some 90% reliability.

I'm running Debian Stretch (fully updated) on a Lenovo X201 laptop. It has an
Intel HD Graphics integrated video card.
I installed the system in september 2017 and this bug is with me for a few
month (I can't really tell if it was there from the beginning or not).

# uname -a
Linux blackhole 4.9.0-6-amd64 #1 SMP Debian 4.9.82-1+deb9u3 (2018-03-02) x86_64
GNU/Linux

gnome-shell version 3.22.3-3

What other details should I provide?






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

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

Versions of packages gnome depends on:
ii  avahi-daemon 0.6.32-2
ii  cheese   3.22.1-1+b1
ii  cups-pk-helper   0.2.6-1+b1
ii  desktop-base 9.0.2+deb9u1
ii  evolution3.22.6-1+deb9u1
ii  evolution-plugins3.22.6-1+deb9u1
ii  file-roller  3.22.3-1
ii  gedit-plugins3.22.0-1
ii  gimp 2.8.18-1+deb9u1
ii  gnome-calendar   3.22.4-2
ii  gnome-clocks 3.22.1-1
ii  gnome-color-manager  3.22.2-1
ii  gnome-core   1:3.22+3
ii  gnome-dictionary 3.20.0-3+b1
ii  gnome-documents  3.22.1-1
ii  gnome-getting-started-docs   3.22.0-1
ii  gnome-maps   3.22.2-1
ii  gnome-music  3.22.2-1
ii  gnome-orca   3.22.2-3
ii  gnome-screenshot 3.22.0-1+b1
ii  gnome-sound-recorder 3.21.92-2
ii  gnome-tweak-tool 3.22.0-1
ii  gnome-weather3.20.2-1
ii  gstreamer1.0-libav   1.10.4-1
ii  gstreamer1.0-plugins-ugly1.10.4-1
ii  inkscape 0.92.1-1
ii  libgsf-bin   1.14.41-1
ii  libgtk2-perl 2:1.2499-1
ii  libproxy1-plugin-networkmanager  0.4.14-2
ii  libreoffice-calc 1:5.2.7-1+deb9u3
ii  libreoffice-evolution1:5.2.7-1+deb9u3
ii  libreoffice-gnome1:5.2.7-1+deb9u3
ii  libreoffice-impress  1:5.2.7-1+deb9u3
ii  libreoffice-writer   1:5.2.7-1+deb9u3
ii  nautilus-sendto  3.8.4-2+b1
ii  network-manager-gnome1.4.4-1
ii  rhythmbox3.4.1-2+b1
ii  rhythmbox-plugin-cdrecorder  3.4.1-2+b1
ii  rhythmbox-plugins3.4.1-2+b1
ii  rygel-playbin0.32.1-3
ii  rygel-tracker0.32.1-3
ii  seahorse 3.20.0-3.1
ii  shotwell 0.25.4+really0.24.5-0.1
ii  simple-scan  3.23.2-1
ii  totem-plugins3.22.1-1
ii  vinagre  3.22.0-1+b1
ii  xdg-user-dirs-gtk0.10-1+b1

Versions of packages gnome recommends:
ii  brasero   3.12.1-4
ii  gnome-games   1:3.22+3
ii  polari3.22.2-1
ii  

Bug#895646: gnupg: do not allow short key IDS in gpg.conf

[Georges Khaznadar]

Package: gnupg
Version: 2.2.5-1
Severity: important

Recent email exchanges show that GPG short ID collisions become
less uncommon nowadays. So every program dealing with GPG and
security must disregard the usage of short key IDs.

Here is my current status regarding this issue:
---8<---
$ grep default-key ~/.gnupg/gpg.conf
default-key 7136AE39
$ gpg --version
gpg (GnuPG) 2.2.5
...
---8<---

I was using a short key ID for a long time (my fault, I shall fix it)
However, gpg never complained.

For the sake of future security, gpg should at least issue a warning and
disregard the short key ID when it is part of
the configuration file.

I filed a merge request for the package gnupg2:
https://salsa.debian.org/debian/gnupg2/merge_requests/3

Thank you in advance for any comment.



-- System Information:
Debian Release: buster/sid
  APT prefers stable
  APT policy: (900, 'stable'), (499, 'testing'), (400, 'unstable')
Architecture: amd64 (x86_64)

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

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

gnupg recommends no packages.

Versions of packages gnupg suggests:
pn  parcimonie  
ii  xloadimage  4.1-24

-- no debconf information

Bug#887107: https://i18n.debian.org/material/data/unstable.gz not updated since 2017-11-23

[Laura Arjona Reina]

Hello
The material data has not been updated, there are more packages
producing errors.
I've added them as exceptions to the config file, to workaround the
issue (as with my previous patch).
Christian, do you mind to update again the repo in tye, to see if
tomorrow the material data is produced?
I wouldn't mind to join the debian-i18n unix group so I can do it
myself, if that's ok with you too, but I'm not sure about the procedure.
Thanks!


El 12/04/18 a las 18:52, Christian PERRIER escribió:
> Quoting Laura Arjona Reina (larj...@debian.org):
>> Hi again
>>
>> El 12/04/18 a las 07:12, Christian PERRIER escribió:
>>
>>> Doh, I'm now in the salsa mess:
>>> debian-i18n@tye:/srv/i18n.debian.org/dl10n/git$ git pull
>>> fatal: unable to access 'https://salsa.debian.org/l10n-team/dl10n.git/': 
>>> server certificate verification failed. CAfile: 
>>> /etc/ssl/certs/ca-certificates.crt CRLfile: none
>> Sorry, my fault, I gave incomplete directions.
>> There is also needed to do the following (in tye.debian.org):
>>
>> dir=/etc/ssl/ca-debian
>> test -d $dir && git config --local --add http.sslCAInfo 
>> $dir/ca-certificates.crt
>>
>> (This is documented in https://wiki.debian.org/ServicesSSL#git )
>
> Gracias!
>
> It just worked now and the local copy on tye is now synced again with
> the git repo on salsa.
>
>

-- 
Laura Arjona Reina
https://wiki.debian.org/LauraArjona

Bug#864402: lxde "No session for pid ...." on screen after login.

[Andriy Grytsenko]

control: reassign -1 lxpolkit

Thank you for reporting this.

Your issue seems as a lxpolkit configuration problem. Could you, please,
look if there aren't two lxpolkit processes running at the moment when
you are logged in?
Could you also check if there is a policy kit agent checked on in the
list of autostarted processes? You can see that in lxsession default apps
configuration program on tab 'Autostart'. If it's checked on then please,
check it off and then report if it fixes the issue. Thank you in advance.

Bug#865116: After a clean reboot user A logs ok to desktop (through xrdp) but user B gets: GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed: User of caller and user of subject differs

[Marco Di Pietro]

Wow,

I never thought someone was ever going to look into this one.

Am I the only one who reported this?

Thanks

Marco

On 22:37, Fri, 13 Apr 2018 Andriy Grytsenko,  wrote:

> control: reassign -1 lxpolkit
>
> Thank you for reporting this.
>
> This seems to be an issue with policy kit configuration, when it comes
> from xrdp it conflicts with one coming directly on desktop. Need a bit
> more of investigation.
>

Bug#865116: After a clean reboot user A logs ok to desktop (through xrdp) but user B gets: GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed: User of caller and user of subject differs

[Andriy Grytsenko]

control: reassign -1 lxpolkit

Thank you for reporting this.

This seems to be an issue with policy kit configuration, when it comes
from xrdp it conflicts with one coming directly on desktop. Need a bit
more of investigation.

Bug#895645: unable to load a web page fully related

[Jeffrin Thalakkottoor]

Package: chromium
Version: 66.0.3359.26-2


hello ,

while i was browsing a typical webpage did not load fully.

a sample link related to that is given below...

-weblink

https://www.hpe.com/us/en/pdfViewer.html?resource=/content/hpe/country/us/en/resources/solutions/article/the-arctic-university-norway=/us/en/solutions/hpc-high-performance-computing

weblink--


$sudo cat /var/log/syslog | grep query
Apr 14 00:31:33 debian chromium.desktop[4485]:
[869:905:0414/003133.619322:ERROR:adm_helpers.cc(73)] Failed to query
stereo recording.
$

$uname -a
Linux debian 4.8.0-2-amd64 #1 SMP Debian 4.8.11-1 (2016-12-02) x86_64
GNU/Linux
$



--
software engineer
rajagiri school of engineering and technology

Bug#873664: Missing dependency on python-xdg

[Andreas Seltenreich]

Hi,

I can confirm the missing dependency on python-xdg.  I guess the first
thing most people do after starting gladish for the first time is to
click the "configure jack" menuitem.  This didn't do anything for me
besides emitting a python backtrace until I installed python-xdg
manually.

regards,
Andreas

Bug#895644: freetts build depends on openjdk-8-jdk

[Adrian Bunk]

Source: freetts
Version: 1.2.2-5.1
Severity: serious

freetts build depends on openjdk-8-jdk, which is not
expected to be part of the buster release.

Bug#895643: jss build depends on openjdk-8-jdk

[Adrian Bunk]

Source: jss
Version: 4.4.2-5
Severity: serious

jss build depends on openjdk-8-jdk, which is not
expected to be part of the buster release.

Bug#893138: openjdk-8 is not expected to be part of the buster release

[Adrian Bunk]

Control: severity -1 serious

openjdk-8 is not expected to be part of the buster release.

cu
Adrian

-- 

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

Bug#895642: sqlite: snprintf wrongly used, path truncated

[Aurelien Jarno]

Source: sqlite
Version: 2.8.17-14
Severity: serious

Compiling lemon.c with -Wall, leads to the following warning (among many
others):

| cc -g -O2 -fdebug-prefix-map=/tmp/sqlite-2.8.17=. -fstack-protector-strong 
-Wformat -Werror=format-security -DTHREADSAFE=1 -Wall -o lemon ./tool/lemon.c
| ./tool/lemon.c: In function 'pathsearch':
| ./tool/lemon.c:2724:37: warning: argument to 'sizeof' in 'snprintf' call is 
the same expression as the destination; did you mean to provide an explicit 
length? [-Wsizeof-pointer-memaccess]
|  if( path ) snprintf(path,sizeof path,"%s/%s",argv0,name);
|  ^~~~
| ./tool/lemon.c:2737:30: warning: argument to 'sizeof' in 'snprintf' call is 
the same expression as the destination; did you mean to provide an explicit 
length? [-Wsizeof-pointer-memaccess]
|  snprintf(path,sizeof path,"%s/%s",pathlist,name);
|   ^~~~

Looking at the code, it comes from those lines:

|  char *path,*cp;
| ...
|path = (char *)malloc( strlen(argv0) + strlen(name) + 2 );
|if( path ) snprintf(path,sizeof path,"%s/%s",argv0,name);

and

|path = (char *)malloc( strlen(pathlist)+strlen(name)+2 );
| ... 
|snprintf(path,sizeof path,"%s/%s",pathlist,name);

The second argument of snprintf limits the number of byte written. While
the buffer path is allocated dynamically using malloc, the size passed
to snprintf is the size of the pointer, which is 4 or 8 bytes depending
on the architecture, resulting in a truncation of the path.

The issue is specific to the debian package and has been introduced by
debian/patches/02-lemon-snprintf.patch. The original code is correct
so the two corresponding hunk should be reverted.

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

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

Bug#895547: [Pkg-openssl-devel] Bug#895547: openssl: After symbol versioning, distributed pkgs are missing API symbols (e.g. EVP_PKEY_asn1_set_item)

[Nicola]

>> >> Package: openssl
>> >> Version: 1.0.2l-1~bpo8+1
>> >> Severity: important
>> >> Tags: patch
>> >
>> > backports?
>> >
>>
>> Yes, old-stable backports.
>
> I see this in the version. You are two versions behind and there were a
> few CVEs released. I couldn't upload earlier, I would need to check if
> it changed but I did not receive a message that it did.

>From https://packages.debian.org/jessie-backports/openssl it seems
that the listed version is the latest available version on backports.

I just redownloaded the source package, and `EVP_PKEY_asn1_set_item`
is definitely still missing from openssl.ld.

> If I am not mistaken the versioning is still in place but differently /
> with upstream support. So it should remain working.
> Can we consider this issue closed?

It might not affect stable, but it still affects oldstable-backports.

Bug#872535: sqlite FTBFS on arm* with gcc 7

[Aurelien Jarno]

control: tag -1 + patch
control: retitle -1: sqlite FTBFS with gcc-7/8 on architectures with unsigned 
char

On 2017-08-18 11:07, Adrian Bunk wrote:
> Source: sqlite
> Version: 2.8.17-14
> Severity: serious
> Tags: buster sid
> 
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/arm64/sqlite.html
> 
> ...
> cc -g -O2 -fstack-protector-strong -Wformat -Werror=format-security 
> -DTHREADSAFE=1 -o lemon ./tool/lemon.c
> ./tool/lemon.c: In function 'tplt_open':
> ./tool/lemon.c:2821:7: warning: implicit declaration of function 'access' 
> [-Wimplicit-function-declaration]
>if( access(buf,004)==0 ){
>^~
> ./tool/lemon.c:2713:14: note: previous declaration of 'access' was here
>extern int access();
>   ^~
> cp ./tool/lempar.c .
> cp ./src/parse.y .
> ./lemon parse.y
> Makefile:261: recipe for target 'parse.c' failed
> make[2]: *** [parse.c] Segmentation fault
> make[2]: *** Deleting file 'parse.c'
> make[2]: Leaving directory '/build/1st/sqlite-2.8.17'
> debian/rules:37: recipe for target 'override_dh_auto_build' failed
> make[1]: *** [override_dh_auto_build] Error 2

The crash happens in that part of the code (line 3073):

|hash = 0;
|for(j=0; stddt[j]; j++){
|  hash = hash*53 + stddt[j];
|}
|hash = (hash & 0x7fff)%arraysize;
|while( types[hash] ){
|  if( strcmp(types[hash],stddt)==0 ){

In some cases, hash ends up with a negative value, causing the crash.
Starting with gcc-7, the & 0x7fff is optimized out on architectures
which have an unsigned char. stddt is defined as a char, and hash as a
(signed) int. Integer wraparound (overflow) is not defined by the C
standard, so GCC is allowed to optimize out the bitwise operation if
sddt is unsigned.

The correct way to fix that is to define has as an unsigned type, like
in the patch below:

--- sqlite-2.8.17.orig/tool/lemon.c
+++ sqlite-2.8.17/tool/lemon.c
@@ -3018,7 +3018,7 @@ int mhflag; /* True if g
   int maxdtlength;  /* Maximum length of any ".datatype" field. */
   char *stddt;  /* Standardized name for a datatype */
   int i,j;  /* Loop counters */
-  int hash; /* For hashing the name of a type */
+  unsigned int hash;/* For hashing the name of a type */
   char *name;   /* Name of the parser */

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Bug#895640: openstack-trove FTBFS: test failures

[Adrian Bunk]

Source: openstack-trove
Version: 1:9.0.0-1
Severity: serious

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/openstack-trove.html

...
==
FAIL: trove.tests.unittests.backup.test_backup_models.BackupORMTest.test_delete
trove.tests.unittests.backup.test_backup_models.BackupORMTest.test_delete
--
_StringException: Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/sqlalchemy/engine/base.py", line 1193, 
in _execute_context
context)
  File "/usr/lib/python3/dist-packages/sqlalchemy/engine/default.py", line 507, 
in do_execute
cursor.execute(statement, parameters)
sqlite3.OperationalError: table agent_heartbeats already exists

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File 
"/build/1st/openstack-trove-9.0.0/trove/tests/unittests/backup/test_backup_models.py",
 line 275, in setUp
util.init_db()
  File "/build/1st/openstack-trove-9.0.0/trove/tests/unittests/util/util.py", 
line 31, in init_db
db_api.db_sync(CONF)
  File "/build/1st/openstack-trove-9.0.0/trove/db/sqlalchemy/api.py", line 108, 
in db_sync
migration.db_sync(options, version, repo_path)
  File "/build/1st/openstack-trove-9.0.0/trove/db/sqlalchemy/migration.py", 
line 106, in db_sync
upgrade(options, version=version, repo_path=repo_path)
  File "/build/1st/openstack-trove-9.0.0/trove/db/sqlalchemy/migration.py", 
line 64, in upgrade
return versioning_api.upgrade(sql_connection, repo_path, version)
  File "/usr/lib/python3/dist-packages/migrate/versioning/api.py", line 186, in 
upgrade
return _migrate(url, repository, version, upgrade=True, err=err, **opts)
  File "", line 2, in _migrate
  File "/usr/lib/python3/dist-packages/migrate/versioning/util/__init__.py", 
line 167, in with_engine
return f(*a, **kw)
  File "/usr/lib/python3/dist-packages/migrate/versioning/api.py", line 366, in 
_migrate
schema.runchange(ver, change, changeset.step)
  File "/usr/lib/python3/dist-packages/migrate/versioning/schema.py", line 93, 
in runchange
change.run(self.engine, step)
  File "/usr/lib/python3/dist-packages/migrate/versioning/script/py.py", line 
148, in run
script_func(engine)
  File 
"/build/1st/openstack-trove-9.0.0/trove/db/sqlalchemy/migrate_repo/versions/005_heartbeat.py",
 line 37, in upgrade
create_tables([agent_heartbeats])
  File 
"/build/1st/openstack-trove-9.0.0/trove/db/sqlalchemy/migrate_repo/schema.py", 
line 69, in create_tables
table.create()
  File "/usr/lib/python3/dist-packages/sqlalchemy/sql/schema.py", line 778, in 
create
checkfirst=checkfirst)
  File "/usr/lib/python3/dist-packages/sqlalchemy/engine/base.py", line 1940, 
in _run_visitor
conn._run_visitor(visitorcallable, element, **kwargs)
  File "/usr/lib/python3/dist-packages/sqlalchemy/engine/base.py", line 1549, 
in _run_visitor
**kwargs).traverse_single(element)
  File "/usr/lib/python3/dist-packages/sqlalchemy/sql/visitors.py", line 121, 
in traverse_single
return meth(obj, **kw)
  File "/usr/lib/python3/dist-packages/sqlalchemy/sql/ddl.py", line 791, in 
visit_table
include_foreign_key_constraints=include_foreign_key_constraints
  File "/usr/lib/python3/dist-packages/sqlalchemy/engine/base.py", line 948, in 
execute
return meth(self, multiparams, params)
  File "/usr/lib/python3/dist-packages/sqlalchemy/sql/ddl.py", line 68, in 
_execute_on_connection
return connection._execute_ddl(self, multiparams, params)
  File "/usr/lib/python3/dist-packages/sqlalchemy/engine/base.py", line 1009, 
in _execute_ddl
compiled
  File "/usr/lib/python3/dist-packages/sqlalchemy/engine/base.py", line 1200, 
in _execute_context
context)
  File "/usr/lib/python3/dist-packages/sqlalchemy/engine/base.py", line 1413, 
in _handle_dbapi_exception
exc_info
  File "/usr/lib/python3/dist-packages/sqlalchemy/util/compat.py", line 203, in 
raise_from_cause
reraise(type(exception), exception, tb=exc_tb, cause=cause)
  File "/usr/lib/python3/dist-packages/sqlalchemy/util/compat.py", line 186, in 
reraise
raise value.with_traceback(tb)
  File "/usr/lib/python3/dist-packages/sqlalchemy/engine/base.py", line 1193, 
in _execute_context
context)
  File "/usr/lib/python3/dist-packages/sqlalchemy/engine/default.py", line 507, 
in do_execute
cursor.execute(statement, parameters)
sqlalchemy.exc.OperationalError: (sqlite3.OperationalError) table 
agent_heartbeats already exists [SQL: '\nCREATE TABLE agent_heartbeats (\n\tid 
VARCHAR(36) NOT NULL, \n\tinstance_id VARCHAR(36) NOT NULL, \n\tupdated_at 
DATETIME, \n\tPRIMARY KEY (id)\n)\n\n'] (Background on this error at: 
http://sqlalche.me/e/e3q8)


==
FAIL: 
trove.tests.unittests.backup.test_backup_models.BackupORMTest.test_filename

Bug#895641: ITP: ruby-tomlrb -- A racc based toml parser

[Stefano Rivera]

Package: wnpp
Severity: wishlist
Owner: Stefano Rivera 

* Package name: ruby-tomlrb
  Version : 1.2.6
  Upstream Author : Francois Bernier 
* URL : https://github.com/fbernier/tomlrb
* License : Expat
  Programming Lang: Ruby
  Description : A racc based toml parser

A Racc based TOML Ruby parser supporting the 0.4.0 version of the spec.

This is a dependency of the Chef stack.

I intend to package it within the ruby team.

Bug#876010: LXDE session doesn't properly load - desktop is managed but no panel is loaded.

[Andriy Grytsenko]

Dear Jonathan,

could you clarify your issue a bit more, please?

For me it seemed as if display manager started a wrong session. It would
be pretty helpful to see list of running processes when the issue happens.
The best you can do is to use 'ps -fx' command and then quote its output.

Thank you in advance.

Bug#895547: [Pkg-openssl-devel] Bug#895547: openssl: After symbol versioning, distributed pkgs are missing API symbols (e.g. EVP_PKEY_asn1_set_item)

[Sebastian Andrzej Siewior]

On 2018-04-13 23:20:07 [+0300], Nicola wrote:
> On 13 April 2018 at 22:45, Sebastian Andrzej Siewior
>  wrote:
> > On 2018-04-12 13:08:57 [+], Nicola Tuveri wrote:
> >> Package: openssl
> >> Version: 1.0.2l-1~bpo8+1
> >> Severity: important
> >> Tags: patch
> >
> > backports?
> >
> 
> Yes, old-stable backports.

I see this in the version. You are two versions behind and there were a
few CVEs released. I couldn't upload earlier, I would need to check if
it changed but I did not receive a message that it did.

> >> I marked this bug as important, as it stops everyone using official
> >> debian packages from using third-party ENGINEs that require to use that
> >> function to set special handling of ASN.1 format, which basically
> >> includes every ENGINE that would add support for cryptosystems that
> >> upstream OpenSSL does not support (defying the purpose of using some
> >> ENGINEs).
> >
> > Not everyone. It should work in stable, doesn't it?
> 
> Yes, my application does work in stable. Has symbol versioning been
> completely disabled there?
> 
> Or am I just lucky that the function I need was whitelisted when the
> versioning script was created for the new release, but the same bug
> can still resurface for the symbol OPENSSL_foobar_magic in future
> OpenSSL 1.1.0x?

If I am not mistaken the versioning is still in place but differently /
with upstream support. So it should remain working.
Can we consider this issue closed?

> Thanks for your reply,
> 
> Nicola

Sebastian

Bug#895547: [Pkg-openssl-devel] Bug#895547: openssl: After symbol versioning, distributed pkgs are missing API symbols (e.g. EVP_PKEY_asn1_set_item)

[Nicola]

On 13 April 2018 at 22:45, Sebastian Andrzej Siewior
 wrote:
> On 2018-04-12 13:08:57 [+], Nicola Tuveri wrote:
>> Package: openssl
>> Version: 1.0.2l-1~bpo8+1
>> Severity: important
>> Tags: patch
>
> backports?
>

Yes, old-stable backports.

>> I marked this bug as important, as it stops everyone using official
>> debian packages from using third-party ENGINEs that require to use that
>> function to set special handling of ASN.1 format, which basically
>> includes every ENGINE that would add support for cryptosystems that
>> upstream OpenSSL does not support (defying the purpose of using some
>> ENGINEs).
>
> Not everyone. It should work in stable, doesn't it?

Yes, my application does work in stable. Has symbol versioning been
completely disabled there?

Or am I just lucky that the function I need was whitelisted when the
versioning script was created for the new release, but the same bug
can still resurface for the symbol OPENSSL_foobar_magic in future
OpenSSL 1.1.0x?



Thanks for your reply,

Nicola

Bug#858923: Proposing a new "try_authtok" option in pam password modules

[Mathieu Parent]

Dear PAM maintainers,

There are two similar bugs:
- in libpam-ldap: https://bugs.debian.org/858923 (and
https://bugs.launchpad.net/ubuntu/+source/libpam-ldap/+bug/329067).
- in libpam-winbind: https://bugs.debian.org/858923 (and
https://bugs.launchpad.net/ubuntu/+source/samba/+bug/570944).

Steve proposed to change pam_unix to always ask a password, another
solution would be a new "try_authtok" option which "Set the new
password to the one provided by the previously stacked password module
if available or ask the user for the new password".

See a work-in-progress patch (0001) for libpam-winbind attached (I'll
send it to samba-technical once tested).

What do you think?

-- 
Mathieu Parent
From 7808a17c18221d3fd95f09bcd3ab18f4a4011165 Mon Sep 17 00:00:00 2001
From: Mathieu Parent 
Date: Fri, 13 Apr 2018 20:50:20 +0200
Subject: [PATCH 3/3] pam_winbind: Use the new try_authtok option allowing
 password change while preserving current behavior with password strength
 modules (Closes: #858923, LP: #570944)

---
 debian/winbind.pam-config | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/winbind.pam-config b/debian/winbind.pam-config
index ccf03d7b63a..3079439d470 100644
--- a/debian/winbind.pam-config
+++ b/debian/winbind.pam-config
@@ -11,7 +11,7 @@ Account:
 	[success=end new_authtok_reqd=done default=ignore]	pam_winbind.so
 Password-Type: Primary
 Password:
-	[success=end default=ignore]	pam_winbind.so use_authtok try_first_pass
+	[success=end default=ignore]	pam_winbind.so try_authtok try_first_pass
 Password-Initial:
 	[success=end default=ignore]	pam_winbind.so
 Session-Type: Additional
-- 
2.17.0

From e749dc84af647225f244d9c93e7297e53018aa53 Mon Sep 17 00:00:00 2001
From: Mathieu Parent 
Date: Thu, 12 Apr 2018 11:58:21 +0200
Subject: [PATCH 2/3] nsswitch: Add try_authok option to pam_winbind

Same as the use_authtok option, except that if the new password is not
valid, PAM will prompt for a password.
---
 ...Add-try_authok-option-to-pam_winbind.patch | 75 +++
 debian/patches/series |  1 +
 2 files changed, 76 insertions(+)
 create mode 100644 debian/patches/nsswitch-Add-try_authok-option-to-pam_winbind.patch

diff --git a/debian/patches/nsswitch-Add-try_authok-option-to-pam_winbind.patch b/debian/patches/nsswitch-Add-try_authok-option-to-pam_winbind.patch
new file mode 100644
index 000..1c2139a4eb1
--- /dev/null
+++ b/debian/patches/nsswitch-Add-try_authok-option-to-pam_winbind.patch
@@ -0,0 +1,75 @@
+From 7dc13b8b6d15223121bceea8cfb9f85820eedfd6 Mon Sep 17 00:00:00 2001
+From: Mathieu Parent 
+Date: Thu, 12 Apr 2018 11:57:15 +0200
+Subject: [PATCH] nsswitch: Add try_authok option to pam_winbind
+
+Same as the use_authtok option, except that if the new password is not
+valid, PAM will prompt for a password.
+
+Bug-Debian: https://bugs.debian.org/858923
+Bug-Ubuntu: https://bugs.launchpad.net/ubuntu/+source/samba/+bug/570944
+
+Signed-off-by: Mathieu Parent 
+---
+ docs-xml/manpages/pam_winbind.8.xml | 8 
+ nsswitch/pam_winbind.c  | 5 +
+ nsswitch/pam_winbind.h  | 1 +
+ 3 files changed, 14 insertions(+)
+
+diff --git a/docs-xml/manpages/pam_winbind.8.xml b/docs-xml/manpages/pam_winbind.8.xml
+index f57a9286a6c..b8af5b54c58 100644
+--- a/docs-xml/manpages/pam_winbind.8.xml
 b/docs-xml/manpages/pam_winbind.8.xml
+@@ -122,6 +122,14 @@
+ 		
+ 		
+ 
++		
++		try_authtok
++		
++		Same as the use_authtok option (previous item), except that if the new password is not
++		valid, PAM will prompt for a password.
++		
++		
++
+ 		
+ 		krb5_auth
+ 		
+diff --git a/nsswitch/pam_winbind.c b/nsswitch/pam_winbind.c
+index e14fcfeb263..0a303202f21 100644
+--- a/nsswitch/pam_winbind.c
 b/nsswitch/pam_winbind.c
+@@ -492,6 +492,8 @@ config_from_pam:
+ 			ctrl |= WINBIND_SILENT;
+ 		else if (!strcasecmp(*v, "use_authtok"))
+ 			ctrl |= WINBIND_USE_AUTHTOK_ARG;
++		else if (!strcasecmp(*v, "try_authtok"))
++			ctrl |= WINBIND_TRY_AUTHTOK_ARG;
+ 		else if (!strcasecmp(*v, "use_first_pass"))
+ 			ctrl |= WINBIND_USE_FIRST_PASS_ARG;
+ 		else if (!strcasecmp(*v, "try_first_pass"))
+@@ -3180,6 +3182,9 @@ int pam_sm_chauthtok(pam_handle_t * pamh, int flags,
+ 		if (on(WINBIND_USE_AUTHTOK_ARG, lctrl)) {
+ 			lctrl |= WINBIND_USE_FIRST_PASS_ARG;
+ 		}
++		if (on(WINBIND_TRY_AUTHTOK_ARG, lctrl)) {
++			lctrl |= WINBIND_TRY_FIRST_PASS_ARG;
++		}
+ 		retry = 0;
+ 		ret = PAM_AUTHTOK_ERR;
+ 		while ((ret != PAM_SUCCESS) && (retry++ < MAX_PASSWD_TRIES)) {
+diff --git a/nsswitch/pam_winbind.h b/nsswitch/pam_winbind.h
+index d468efbb56a..c6786d65a4d 100644
+--- a/nsswitch/pam_winbind.h
 b/nsswitch/pam_winbind.h
+@@ -156,6 +156,7 @@ do { \
+ #define WINBIND_DEBUG_STATE		0x1000
+ #define WINBIND_WARN_PWD_EXPIRE		0x2000
+ #define WINBIND_MKHOMEDIR		0x4000
++#define WINBIND_TRY_AUTHTOK_ARG		

Bug#895639: golang-github-tdewolff-test: causes regression in autopkgtests of other packages

[Paul Gevers]

Source: golang-github-tdewolff-test
Version: 0.0~git20171106.2654270-1
Severity: normal
User: ci-t...@tracker.debian.org
Usertags: triggers
Control: affects golang-github-tdewolff-buffer
Control: affects golang-github-tdewolff-parse
Control: affects golang-github-tdewolff-minify

With the upload of version 0.0~git20171106.2654270-1 of
golang-github-tdewolff-test, autopkgtests of multiple packages started
to fail.

While the case for golang-github-tdewolff-parse and
golang-github-tdewolff-minify doesn't appear to happen in unstable
(hinting at some missing versions in Depends or Breaks somewhere), the
breakage of golang-github-tdewolff-buffer is in unstable. As
golang-github-tdewolff-test triggered regressions in three different
packages, I decided to file this bug. Could you please investigate, and
if the other packages also have issues, please reassign, clone or file
new bugs as appropriate.

Paul

¹
https://ci.debian.net/packages/g/golang-github-tdewolff-buffer/unstable/amd64/
&
https://ci.debian.net/packages/g/golang-github-tdewolff-buffer/testing/amd64/
²
https://ci.debian.net/packages/g/golang-github-tdewolff-parse/testing/amd64/
³
https://ci.debian.net/packages/g/golang-github-tdewolff-minify/testing/amd64/

=
* golang-github-tdewolff-buffer in unstable¹ and testing¹:
   dh_auto_build -O--buildsystem=golang
cd obj-x86_64-linux-gnu && go install
-gcflags=\"-trimpath=/tmp/autopkgtest-lxc.vt5oqn63/downtmp/autopkgtest_tmp/obj-x86_64-linux-gnu/src\"
-asmflags=\"-trimpath=/tmp/autopkgtest-lxc.vt5oqn63/downtmp/autopkgtest_tmp/obj-x86_64-linux-gnu/src\"
-v -p 8 github.com/tdewolff/buffer
github.com/tdewolff/buffer
   dh_auto_test -O--buildsystem=golang
cd obj-x86_64-linux-gnu && go test -vet=off -v -p 8
github.com/tdewolff/buffer
=== RUN   TestBufferPool
--- PASS: TestBufferPool (0.00s)
=== RUN   TestLexer
--- FAIL: TestLexer (0.00s)
test.go:68:

lexer_test.go:52: EOF buffer must be fully in memory: EOF
test.go:68:

lexer_test.go:78: EOF error must be EOF when past the buffer:
EOF
=== RUN   TestLexerShift
--- PASS: TestLexerShift (0.00s)
=== RUN   TestLexerSmall
--- PASS: TestLexerSmall (0.00s)
=== RUN   TestLexerSingle
--- PASS: TestLexerSingle (0.00s)
=== RUN   TestLexerRunes
--- PASS: TestLexerRunes (0.00s)
=== RUN   TestLexerZeroLen
--- PASS: TestLexerZeroLen (0.00s)
=== RUN   TestLexerEmptyReader
--- FAIL: TestLexerEmptyReader (0.00s)
test.go:68:

lexer_test.go:139: EOF error must be EOF: EOF
=== RUN   TestReader
--- FAIL: TestReader (0.00s)
test.go:68:

reader_test.go:29: EOF error must be io.EOF: EOF
=== RUN   TestShifter
--- FAIL: TestShifter (0.00s)
test.go:68:

shifter_test.go:41: EOF error must be EOF when past the buffer:
EOF
=== RUN   TestShifterSmall
--- PASS: TestShifterSmall (0.00s)
=== RUN   TestShifterRunes
--- PASS: TestShifterRunes (0.00s)
=== RUN   TestShifterZeroLen
--- PASS: TestShifterZeroLen (0.00s)
=== RUN   TestShifterEmptyReader
--- PASS: TestShifterEmptyReader (0.00s)
=== RUN   TestWriter
--- PASS: TestWriter (0.00s)
=== RUN   ExampleNewReader
--- PASS: ExampleNewReader (0.00s)
=== RUN   ExampleNewShifter
--- PASS: ExampleNewShifter (0.00s)
=== RUN   ExampleShifter_PeekRune
--- PASS: ExampleShifter_PeekRune (0.00s)
=== RUN   ExampleShifter_IsEOF
--- PASS: ExampleShifter_IsEOF (0.00s)
=== RUN   ExampleNewWriter
--- PASS: ExampleNewWriter (0.00s)
=== RUN   ExampleWriter_Reset
--- PASS: ExampleWriter_Reset (0.00s)
FAIL
FAILgithub.com/tdewolff/buffer  0.003s
dh_auto_test: cd obj-x86_64-linux-gnu && go test -vet=off -v -p 8
github.com/tdewolff/buffer returned exit code 1



=
* golang-github-tdewolff-parse in testing²
make[1]: Leaving directory
'/tmp/autopkgtest-lxc.gpl16fpt/downtmp/autopkgtest_tmp'
   dh_auto_build -O--buildsystem=golang
cd obj-x86_64-linux-gnu && go install
-gcflags=\"-trimpath=/tmp/autopkgtest-lxc.gpl16fpt/downtmp/autopkgtest_tmp/obj-x86_64-linux-gnu/src\"
-asmflags=\"-trimpath=/tmp/autopkgtest-lxc.gpl16fpt/downtmp/autopkgtest_tmp/obj-x86_64-linux-gnu/src\"
-v -p 2 github.com/tdewolff/parse github.com/tdewolff/parse/css
github.com/tdewolff/parse/html github.com/tdewolff/parse/js
github.com/tdewolff/parse/json github.com/tdewolff/parse/svg
github.com/tdewolff/parse/xml
github.com/tdewolff/parse/svg
github.com/tdewolff/buffer
github.com/tdewolff/parse
github.com/tdewolff/parse/css
github.com/tdewolff/parse/html
github.com/tdewolff/parse/js
github.com/tdewolff/parse/json
github.com/tdewolff/parse/xml
   dh_auto_test -O--buildsystem=golang
cd obj-x86_64-linux-gnu && go test -vet=off -v -p 2
github.com/tdewolff/parse github.com/tdewolff/parse/css
github.com/tdewolff/parse/html github.com/tdewolff/parse/js
github.com/tdewolff/parse/json 

Bug#895547: [Pkg-openssl-devel] Bug#895547: openssl: After symbol versioning, distributed pkgs are missing API symbols (e.g. EVP_PKEY_asn1_set_item)

[Sebastian Andrzej Siewior]

On 2018-04-12 13:08:57 [+], Nicola Tuveri wrote:
> Package: openssl
> Version: 1.0.2l-1~bpo8+1
> Severity: important
> Tags: patch

backports?

> Dear Maintainer,
> 
> I'm developing an ENGINE for OpenSSL, and close to release, I noticed
> that in Ubuntu and in Debian the build fails with the following output:
> 
> ```
> /usr/bin/cc  -fPIC -g  -shared -Wl,-soname,liblibsuola.so -o liblibsuola.so 
> CMakeFiles/suola.dir/suola.c.o CMakeFiles/suola.dir/suola_keypair.c.o 
> CMakeFiles/suola.dir/debug/debug.c.o 
> CMakeFiles/suola.dir/meths/X25519_meth.c.o 
> CMakeFiles/suola.dir/meths/ed25519_meth.c.o 
> CMakeFiles/suola.dir/meths/suola_asn1_meth.c.o 
> CMakeFiles/suola.dir/meths/suola_md_identity_meth.c.o 
> CMakeFiles/suola.dir/ossl/ossl_compat.c.o 
> CMakeFiles/suola.dir/ossl/suola_err.c.o 
> CMakeFiles/suola.dir/ossl/suola_objects.c.o 
> CMakeFiles/suola.dir/providers/libsodium/base.c.o 
> CMakeFiles/suola.dir/providers/libsodium/curve25519.c.o 
> CMakeFiles/suola.dir/providers/libsodium/ed25519.c.o -lssl -lcrypto 
> /opt/libsodium-stable/lib/libsodium.so -Wl,-z,defs 
> -Wl,-rpath,/opt/libsodium-stable/lib:
> CMakeFiles/suola.dir/meths/suola_asn1_meth.c.o: In function 
> `suola_register_asn1_meth':
> /usr/local/src/libsuola/meths/suola_asn1_meth.c:505: undefined reference to 
> `EVP_PKEY_asn1_set_item'
> collect2: error: ld returned 1 exit status
> make[2]: *** [liblibsuola.so] Error 1
> CMakeFiles/suola.dir/build.make:412: recipe for target 'liblibsuola.so' failed
> make[2]: Leaving directory '/usr/local/src/libsuola/build'
> make[1]: *** [CMakeFiles/suola.dir/all] Error 2
> make: *** [all] Error 2
> ```
> 
> This does not happen linking against the same exact release of openssl
> compiled from source on the same system.
> 
> I then learned that one of the patches applied by Debian (and included
> by derived distributions) has the goal of versioning library symbols to
> avoid conflicts.
> 
> Unfortunately said patch is not updated regularly with each release of
> OpenSSL, resulting, like in my case, in symbols available in the public
> header files but masked through versioning in the shared library binary.
> 
> The attached patch fixes my need by adding `EVP_PKEY_asn1_set_item` to
> the list, but you might consider an internal review of your release
> process to make sure that the list of symbols is updated whenever a new
> upstream releases makes new functions publicly available.
> 
> 
> I marked this bug as important, as it stops everyone using official
> debian packages from using third-party ENGINEs that require to use that
> function to set special handling of ASN.1 format, which basically
> includes every ENGINE that would add support for cryptosystems that
> upstream OpenSSL does not support (defying the purpose of using some
> ENGINEs).

Not everyone. It should work in stable, doesn't it?

> This covers my use case, but basically the package as is results
> unusable to any user of any application that may require functions
> available in the public headers but accidentally masked in the symbol
> versioning step.
> 
> 
> The ideal outcome of fixing this issue would consist in making the
> versioning patch dynamic, checking when symbols are added (or removed)
> in newer releases and updating the list accordingly.
> 
> The same versioning patch is applied in the other releases, so it's
> worth tagging this bug also for those to make the handling of the
> exposed symbols consistent.

I'm not yet sure what we should do about this.

Sebastian

Bug#895638: ITP: ruby-iso8601 -- Ruby parser to work with ISO 8601 dateTimes and durations

[Stefano Rivera]

Package: wnpp
Severity: wishlist
Owner: Stefano Rivera 

* Package name: ruby-iso8601
  Version : 0.10.1
  Upstream Author : Arnau Siches
* URL : https://github.com/arnau/ISO8601
* License : Expat
  Programming Lang: Ruby
  Description : Ruby parser to work with ISO 8601 dateTimes and durations

ISO8601 is a simple implementation in Ruby of the ISO 8601 (Data elements and
interchange formats - Information interchange - Representation of dates
and times) standard.

Bug#895637: O: p2c -- Pascal to C translator

[Bob Tennent]

Package: wnpp
Severity: normal

This package is still used.  Here are three sources for it:

https://github.com/FranklinChen/p2c
https://schneider.ncifcrf.gov/p2c/
https://fedora.pkgs.org/27/rpm-sphere/p2c-1.22-26.1.x86_64.rpm.html

My particular interest in p2c is that I use p2c to translate
upstream Pascal sources for M-Tx to C for inclusion in
TeXLive (as TeXLive only accepts C and lua code).

https://ctan.org/pkg/m-tx

Bob Tennent

Bug#895636: meson: more tools missing from debcrossgen

[Helmut Grohne]

Package: meson
User: helm...@debian.org
Usertags: rebootstrap
Control: affects -1 + src:systemd

systemd fails to cross build from source for uefi architectures (e.g.
arm64), because the generated cross file does not include all relevant
tools. In particular, systemd needs ld and objcopy, both of which are
presently missing from debcrossgen.

Rather than adding them, let me propose a more generic solution. Add a
new field to cross files. I'll call it "tool_prefix" for now, but you
can choose a better name of course. When tool_prefix is empty or not
set, meson behaves as before. When it is set however, find_program
behaves differently. When find_program is instructed to look for foo
(with native=False), it first looks whether foo is assigned in the cross
file (as before). If it isn't assigned, it searches $PATH for the
concatenation of tool_prefix and foo. If it finds something, that one is
used. In case nothing is found, it proceeds searching $PATH for simply
foo.

For Debian systems, most architecture-dependent tools carry the GNU
triplet as prefix. Thus we can assign "${DEB_HOST_GNU_TYPE}-" as the
tool_prefix and solve most of missing entries.

Please consider implementing the proposed tool_prefix rather than just
adding ld and objcopy to debcrossgen.

Helmut

Bug#893919: RFS: yasnippet-snippets/0~git20180324.79fc648-1

[Nicholas D Steeves]

Updated link to dsc:

  dget 
https://mentors.debian.net/debian/pool/main/y/yasnippet-snippets/yasnippet-snippets_0~git20180324.79fc648-1.dsc

I've tagged 74b8c69 as debian/0_git20180324.79fc648-1.

  git clone https://salsa.debian.org/emacsen-team/yasnippet-snippets.git

Updated changes since last version:

yasnippet-snippets (0~git20180324.79fc648-1) unstable; urgency=medium

  * Update upstream from git commit 79fc648.
  * Add elpa-yasnippet-snippets package:
- Add 0003-Synchronise-declared-version-with-MELPA.patch.
- d/control: Change section to lisp.
- d/control: Add elpa-yasnippet-snippets section.
- d/control: Rely on ${elpa:Depends} for dependency resolution.
- d/control: Add Breaks, Replaces, and Provides.
- d/control: yasnippet-snippets is now a dummy transitional package
 that depends on elpa-yasnippet-snippets.
  * Update maintscripts to accommodate elpafication.
  * Add 0004-Add-missing-keys-for-all-markdown-mode-snippets.patch.
0001-Rename-files-that-are-prohibited-in-Debian-packages.patch changed
the behaviour of markdown-mode snippets, because they defined their
keys based on file names.  This patch restores the expected behaviour.
  * Declare Standards-Version: 4.1.4. (No changes needed)

 -- Nicholas D Steeves   Thu, 12 Apr 2018 16:39:12 -0400

yasnippet-snippets (0~git20180307.2b4c4d7e-2) unstable; urgency=medium


Regards,
Nicholas


signature.asc
Description: PGP signature

Bug#892285: /usr/bin/fpcmake: fpcmake should find units in Debian without fiddling with FPCDIR

[Abou Al Montacir]

Hi All,
On Thu, 2018-03-08 at 09:34 +0100, Abou Al Montacir wrote:
> Hi Paul,
> 
> On Thu, 2018-03-08 at 08:44 +0100, Paul Gevers wrote:
> > > Probably none of them need to define FPCDIR.
> > Currently Lazarus FTBFS without it.¹
> I'll have a look at it and try to fix it this WE.
I could finally find time for this issue. There was an issue with fpcmake
looking for fpc executable using a wrong name on amd64 architecture.FPC
executable is ppcx64 while fpcmake was looking for ppcx86_64. I had a commit
fixing this issue: cff270e15f4d9342ea6918a4b69d038df5184af2
However this commit revealed another bug: currently we are shipping
Makefiles.fpc in fpc-source package, which install to /usr/share/fpc-
source/${FPCVER}.However fpcmake seems too look for them at units directories.
This seems more logical and make me remeber the lpk files  for Lazarus.Also by
shipping Makefile.fpc with binaries we get rid of the constraint of depending on
fpc-source to be able to build any fpc programe using fpcmake.
To be discussed more.
-- Cheers,
Abou Al Montacir

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

Bug#895635: possibly a broken link

[Jeffrin Thalakkottoor]

Package: libnuma-dev
Version: 2.0.11-2.1

hello ,

i found a possibly broken linkhttp://oss.sgi.com/projects/libnuma/

on using "apt-cache show libnuma-dev"

$apt-cache show libnuma-dev | grep Home
Homepage: http://oss.sgi.com/projects/libnuma/
$

--
software engineer
rajagiri school of engineering and technology

Bug#895604: php-symfony-polyfill: FTBFS and Debci failure with phpunit 7.0.3-1

[Paul Gevers]

On Fri, 13 Apr 2018 13:11:02 +0300 Adrian Bunk  wrote:
> https://ci.debian.net/packages/p/php-symfony-polyfill/unstable/amd64/
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/php-symfony-polyfill.html
> 
> ...
>debian/rules override_dh_auto_test
> make[1]: Entering directory '/build/1st/php-symfony-polyfill-1.7.0'
> phpunit --bootstrap debian/autoload.php
> PHP Fatal error:  Declaration of Symfony\Polyfill\Util\TestListener::setUp() 
> must be compatible with PHPUnit\Framework\TestSuite::setUp(): void in 
> /build/1st/php-symfony-polyfill-1.7.0/src/Util/TestListener.php on line 28
> make[1]: *** [debian/rules:61: override_dh_auto_test] Error 255

Interestingly, the explicit testing of phpunit 7.0.3-1 with all code
from testing on 1 April 2018¹ was successful. So I wonder (and no,
php-defaults 61 can't be the culprit)...

Paul

¹ https://ci.debian.net/packages/p/php-symfony-polyfill/testing/amd64/



signature.asc
Description: OpenPGP digital signature

Bug#895061: exclusions and dh_missing

[Niels Thykier]

Nicolas Boulenguez:
> My understanding (so far) is that there are three unselection
> mechanisms, and I have the feeling that only one is worth supporting.
> 

Ok, just to confirm, I understood you correct, those three are:

 1) --exclude for paths debhelper automatically work on (but not
--ignore)

 2) --exclude for paths provided by the maintainer either via arguments
or config file.

 3) --ignore

And 1) is the only one you want to preserve?

> 
> [...]
> 
> The --exclude option has a second, distinct, and arguable usage:
> to extend the expressivity of glob patterns, like in:
>   override_dh_installexamples:
> dh_installexamples --exclude=foo/bar foo
> 

I know of two common use-cases here for --exclude.  If we can find an
alternative for those, I am happy to consider deprecating --exclude for
these purposes.

  1)  Ignore files/paths from the config file that are conditionally
  built.  This is usually observed via the following pattern:

  IGNORE_FOO :=
  ifeq ...
  IGNORE_FOO := -X foo
  endif

  [...]
dh_install $(IGNORE_FOO)

  2) The case you described above where people want "all the files in
 foo except bar".

You later mention the executable config files as a possible solution.  I
disagree that executable config files /in their current form/ is ready
to replace these patterns.
  That said,  I know dh-exec is doing a good job at making executable
config files easier to work with.  It is sadly missing someone with
interest and motivation to maintain it and I have been hoping someone
picked it up (I do not have a vision for dh-exec, so I am not the right
one to pick it up).

Note that I am very happy to work with you (or anyone else) on improving
dh-exec and the debhelper <=> dh-exec integration.  If the changes are
useful and stable, we can look at merging some of them back eventually
(dh-exec has a much better interface for prototyping, while debhelper
effectively commits to 10-12 years of support the moment it is released
in a compat level).

> [...]
> 
> It forces debhelper to be less performant, as each existing path must
> be matched against two distinct kinds of patterns in the end.
> Also, --exclude prevents a simple 'chmod -a' for directories.
> 

While I loath the fact that --exclude makes things hard to optimize, I
am not entirely convinced the overhead of using --exclude is an issue in
itself at the moment.

Performance-wise, I suspect #866581 is a much lower hanging fruit.  Or
the fact that Dh_Lib takes 0.035s to load costing us 100ms per 3
debhelper command run during build on pure "do the same initialization
over and over again".

> It forces debhelper to contain code that is hard to write, maintain
> and test.

I admit that most --exclude is hard to test.  The notable exception
being "excludefile", which is rather easy to test (compared to things in
debhelper in general).

> Factorization like EXCLUDE_FIND is only a work-around, it
> does not change that a Perl script generates a Shell command
> describing a find request compiling regular expressions translated
> from command-line arguments usually transmited by a Shell launched by
> Make. Who would bet that all special characters are handled correctly
> in all corner cases ?
> 

EXCLUDE_FIND will correctly be passed to find, but every thing else is
indeed a hassle to quote correctly.  Related annoyances: #864182

I would indeed prefer less need for "complex_doit".

> [...]
> 
> To some extent, the same concern applies to --ignore.
> [...]
> Is it worth to slow down each call to pkgfile() to handle this?
> However, the performance and complexity costs are way smaller, so the
> balance with the burden of removing an option is probably different.
> 

I was going argue that it was not worth the removal. But there is only
one or two consumers (left?) of --ignore according to codesearch[1].
Even cdbs does not appear to use it at all.
  If you can convince the remaining consumers of --ignore to migrate
away, then I am happy to drop the option when we release debhelper 12.

Thanks,
~Niels

[1] https://codesearch.debian.net/search?q=dh.*.%5Cs--ignore

E.g. gutenprint

Bug#895199: /usr/games/antigrav: crash in start with segfault

[Markus Koschany]

Hello,

Am 08.04.2018 um 13:03 schrieb Ilari Halminen:
> Package: antigravitaattori
> Version: 0.0.3-6
> Severity: normal
> File: /usr/games/antigrav
> 
> Dear Maintainer,
> 
> When I try to run from console with command antigrav
> I mainly got Muistialueen ylitys
> that means segfault in my lang.

the game works for me in Debian unstable. I haven't tested the Jessie
version though. Jessie games are unsupported in Debian LTS, therefore I
suggest to upgrade to a newer version which will most likely address
your issue.

Regards,

Markus



signature.asc
Description: OpenPGP digital signature

Bug#483811: [fam] fam segfaults

[Alessandro Vesely]

On Fri, 30 Mar 2018 12:47:15 +0200 I wrote:
>  That suggests that Set.h doesn't work as expected.

No, that wasn't the case.  A couple of days ago I got a core dump with exactly
the same back trace (bt), even if using std::set.

Core was generated by `/usr/sbin/famd -v -f -T 0'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x in ?? ()
(gdb) bt
#0  0x in ?? ()
#1  0x00412aec in TCP_Client::unblock_handler (closure=0x1935d20) at 
TCP_Client.c++:270
#2  0x004105ac in Scheduler::handle_io (fds=0x1c028f0, 
fds@entry=0x7ffd7bd92ef0, iotype=::FDInfo::read, 
iotype@entry=::FDInfo::write) at Scheduler.c++:315
#3  0x004107e1 in Scheduler::select () at Scheduler.c++:342
#4  0x00402fa5 in loop () at Scheduler.h:89
#5  main (argc=, argv=0x7ffd7bd93168) at main.c++:306


Need to look more closely at ip.

(gdb) hd
Undefined command: "hd".  Try "help".
(gdb) define hd
Type commands for definition of "hd".
End with a line saying just "end".
>dump binary memory dump.tmp $arg0 $arg0+$arg1
>shell hd dump.tmp
>end

(gdb) p sizeof(Interest)
$11 = 200

(gdb) p sizeof(File)
$43 = 240

(gdb) hd (char*)ip 240
  30 c1 73 02 00 00 00 00  50 56 02 02 00 00 00 00  |0.s.PV..|
0010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ||
0020  e0 29 c0 01 00 00 00 00  36 30 30 30 36 38 31 31  |.)..60006811|
0030  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ||
*
00c0  7f 00 00 01 01 00 00 00  f0 44 91 01 00 00 00 00  |.D..|
00d0  10 2b c0 01 00 00 00 00  01 00 00 00 00 00 00 00  |.+..|
00e0  f0 00 00 00 00 00 00 00  60 00 00 00 00 00 00 00  |`...|

We have the following layout  (from Interest.h, ClientInterest.h and `p 
&((Interest*)0).'):

offset  Instance Variables  content found

_vtbl   bad (virtual functions)
0008Interest *hashlink; ??
0010dev_t dev;  0
0018ino_t ino;  0
0020char *const myname; mixed buffer (see MYNAME below)
0028ScanState scan_state: 1;"6000?6811I?"
ExecState cur_exec_state: 1;
ExecState old_exec_state: 1;
0029char ci_char;
002achar dir_char;
0030struct stat old_stat;
00c0in_addr myhost; 127.0.0.1
00c4bool mypath_exported_to_host;   1 (remaining 3 bytes could have 
been set before)

00c8Client *myclient;   bad, 0x19144f0 (see CLIENT below)
00d0Request request;
00d8const Cred mycred;
00e0FileSystem *myfilesystem;
00e8Request fs_request;

MYNAME:
(gdb) hd 0x1c029e0 80
  00 00 00 00 00 00 00 00  32 39 2e 4d 38 33 31 38  |29.M8318|
0010  34 37 50 32 37 31 36 38  56 30 30 30 30 30 30 30  |47P27168V000|
0020  30 30 30 30 30 36 38 31  31 49 30 30 30 30 30 30  |06811I00|
0030  30 30 30 30 34 45 35 33  37 32 5f 31 2e 6e 6f 72  |4E5372_1.nor|
0040  74 68 2c 53 3d 32 32 35  36 36 35 00 53 00 00 53  |th,S=225665.S..S|
0050


The same is true for other Interest pointers still in to_be_scanned, $tbs0, ...:


(gdb) hd $tbs0 200
  90 d6 73 02 00 00 00 00  c0 2c c0 01 00 00 00 00  |..s..,..|
0010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ||
0020  40 2a c0 01 00 00 00 00  36 30 30 30 36 38 31 31  |@*..60006811|
0030  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ||
*
00c0  7f 00 00 01 01 35 34 33   |.543|
00c8

(gdb) p ((Interest*)$tbs0)->myname
$13 = 0x1c02a40 ""
(gdb) hd 0x1c02a40 80
  00 00 00 00 00 00 00 00  32 39 2e 4d 38 34 33 38  |29.M8438|
0010  38 38 50 32 37 31 37 30  56 30 30 30 30 30 30 30  |88P27170V000|
0020  30 30 30 30 30 36 38 31  31 49 30 30 30 30 30 30  |06811I00|
0030  30 30 30 30 34 45 35 33  38 43 5f 31 2e 6e 6f 72  |4E538C_1.nor|
0040  74 68 2c 53 3d 32 32 35  36 36 35 00 00 00 00 00  |th,S=225665.|
0050  b0 01 00 00 00 00 00 00  30 00 00 00 00 00 00 00  |0...|


(gdb) hd $tbs1 200
  00 2b c0 01 00 00 00 00  80 2e c0 01 00 00 00 00  |.+..|
0010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ||
0020  00 2c c0 01 00 00 00 00  36 30 30 30 36 38 31 31  |.,..60006811|
0030  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ||
*
00c0  7f 00 00 01 01 35 34 33   |.543|
00c8

(gdb) p ((Interest*)$tbs1)->myname
$14 = 0x1c02c00 ""
(gdb) hd 0x1c02c00 80
  00 00 00 00 00 00 00 00  34 34 2e 4d 34 35 37 31  |44.M4571|
0010  36 50 32 37 32 30 35 56  30 30 30 30 30 30 30 30  |6P27205V|
0020  30 30 30 30 36 38 31 31  49 30 30 30 30 30 30 30  |6811I000|
0030  30 

Bug#895634: please package lftp 4.8.3

[Nico Golde]

Source:lftp
Severity:wishlist

Hey Noël,
Could you update lftp to 4.8.3? This brings some useful features such as 
the parallel option for mget.

Thanks!
Nico

-- 
Nico Golde - XMPP: n...@jabber.ccc.de - GPG: 0xA0A0


signature.asc
Description: PGP signature

Bug#895000: atril always shows a stacktrace/crash from webkit displaying pdf files

[Jeremy Bicha]

Version: 2.20.1-1

The webkit2gtk developers believe this is already fixed in webkit2gtk
2.20.1 which should reach Testing in a few days.

The upstream bug is still open because webkit2gtk cherry-picked a
patch that Apple has not yet applied to webkit trunk.

Thanks,
Jeremy Bicha

Bug#895630: pdf2djvu: FTBFS with poppler 0.63.0: tests fail: PDF syntax warning: EOF while reading header

[Emilio Pozuelo Monfort]

Control: reassign -1 poppler
Control: severity -1 normal
Control: retitle -1 poppler: don't fail on small files, breaks pdf2djvu test 
suite
Control: forwarded -1 
https://cgit.freedesktop.org/poppler/poppler/patch/?id=e491e935ea355d48519cf0a14e4b060655850675
Control: tags -1 upstream pending

On 13/04/18 19:55, Jakub Wilk wrote:
> Upstream speaking here!
> 
> * Emilio Pozuelo Monfort , 2018-04-13, 19:39:
>> AssertionError: 'PDF syntax warning: EOF while reading header (continuing
>> anyway)\nPDF syntax wa [truncated]... != ''
>> - PDF syntax warning: EOF while reading header (continuing anyway)
>> - PDF syntax warning: EOF while reading header (continuing anyway)
>> - PDF syntax warning: EOF while reading header (continuing anyway)
> 
> Ideally, this should be fixed in Poppler by cherry-picking this patch:
> https://cgit.freedesktop.org/poppler/poppler/patch/?id=e491e935ea355d48519cf0a14e4b060655850675

Cool, I will include that when uploading to unstable.

Thanks!
Emilio

Bug#894441: dpkg-buildpackage: SOURCE_DATE_EPOCH must ignore bin-nmu changelog entries. Breaks M-A:same

[Ian Jackson]

> On Thu, Apr 05, 2018 at 05:43:58PM +0200, Jean-Michel Vourgère wrote:
> > So, during compilation:
> > SOURCE_DATE_EPOCH must ignore bin-nmu changelog entries
> > because it breaks Multi-Arch:same on bin-nmu.
> > 
> > During dpkg-deb (:
> > SOURCE_DATE_EPOCH must *not* ignore bin-nmu changelog entries
> > because it would break software relying on files mtime.

I don't think we are as doomed as all that.  I analysed this in my
message here:

 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=843773#75

That was in November 2016 and Guillem replied in January 2017 saying,
essentially, that he still disagreed with the design of multiarch, and
that binNMUs are not coinstallable.

AIUI binNMUs are now coinstallable ?  And that is why 

My solution is still applicable, I think.  There is no change to
wanna-build needed.

There is a resulting small wrinkle that the on disk mtime of a
multi-arch shared file may the mtime of any of the source packages.
Guillem complains that it would make verification difficult, but I
think that is a soluble problem.  Guillem also complains that the
mtime may flap; but that is easily avoided by having the on-disk mtime
only go forwards.

As for Guillem's complaints about the design of multiarch: these
concerns were overruled by a decision of the Technical Committee.

I don't think they are good reasons to divert from the
straightforward, if not entirely neat, course I propose.

Thanks,
Ian.

-- 
Ian Jackson    These opinions are my own.

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

Bug#895633: transition: poppler

[Emilio Pozuelo Monfort]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
Control: block -1 with 894371

Time for another poppler transition. It's in experimental, and all
the rdepends build fine, except for

gdcm, due to an unrelated bug #894371.

Cheers,
Emilio

Bug#895600: [request-tracker-maintainers] Bug#895600: broken system configuration page

[Jim Brandt]

On 4/13/18 9:33 AM, Dominic Hargreaves wrote:
> Control: forwarded -1 
> https://issues.bestpractical.com/Ticket/Display.html?id=3301
> 
> On Fri, Apr 13, 2018 at 11:41:20AM +0200, Daniel Baumann wrote:
>> When upgrading from 4.4.1-5 to 4.4.2-1 (and subsequently to 4.4.2-2), we
>> noticed the follwowing regression:
>>
>>   * Logging in as root, going to Admin / Tools / System Configuration,
>> a page with the following message is shown instead of the
>> configuration page:
>>
>> "An internal RT error has occurred. Your administrator can find more
>>  details in RT's log files."
>>
>>   * The logfile shows:
>>
>> ---snip---
>> [2518] [Fri Apr 13 09:21:20 2018] [error]: Can't store REGEXP items at
>> /usr/share/request-tracker4/lib/RT/Config.pm line 1521.
> 
> Hi,
> 
> This means that some part of your configuration which is being obfuscated
> for display uses regexps. There is an issue in the upstream bugtracker
> about this[1] and a candidate fix in upstream's repo[2].
> 
> Shawn, can you say what the status of this is? Are there known
> issues which have lead to it not yet being merged?

Hi Dom,

We're looking at this branch as a potential fix since it covers both
REGEXP and CODE in configuration.

https://github.com/bestpractical/rt/tree/4.4/config-clone-error

Right now it just needs some testing and code review. We should be able
to merge it soon.

Jim

> 
> Cheers,
> Dominic.
> 
> [1] 
> [2] 
> 

-- 
Jim Brandt
Director, Product and Engineering
Best Practical Solutions

Bug#895630: pdf2djvu: FTBFS with poppler 0.63.0: tests fail: PDF syntax warning: EOF while reading header

[Jakub Wilk]

Upstream speaking here!

* Emilio Pozuelo Monfort , 2018-04-13, 19:39:

AssertionError: 'PDF syntax warning: EOF while reading header (continuing 
anyway)\nPDF syntax wa [truncated]... != ''
- PDF syntax warning: EOF while reading header (continuing anyway)
- PDF syntax warning: EOF while reading header (continuing anyway)
- PDF syntax warning: EOF while reading header (continuing anyway)


Ideally, this should be fixed in Poppler by cherry-picking this patch:
https://cgit.freedesktop.org/poppler/poppler/patch/?id=e491e935ea355d48519cf0a14e4b060655850675

--
Jakub Wilk

Bug#895632: kdav: autopkgtest fails with new release while succeeded in the past

[Paul Gevers]

Source: kdav
Version: 17.12.3-1
Severity: normal
User: ci-t...@tracker.debian.org
Usertags: regression

With the upload of version 17.12.3-1 of kdav, the
autopkgtest¹ started to fail with the following error:

Running tests...
/usr/bin/ctest --force-new-ctest-process -j1
Test project
/tmp/autopkgtest-lxc.m0yqmrr9/downtmp/build.7In/src/obj-x86_64-linux-gnu
Start 1: kdav-davcollection
1/5 Test #1: kdav-davcollection ...   Passed0.03 sec
Start 2: kdav-davitem
2/5 Test #2: kdav-davitem .   Passed0.01 sec
Start 3: kdav-davurl
3/5 Test #3: kdav-davurl ..   Passed0.01 sec
Start 4: kdav-davitemfetchjob
4/5 Test #4: kdav-davitemfetchjob .***Failed0.02 sec
* Start testing of DavItemFetchJobTest *
Config: Using QtTest library 5.9.2, Qt 5.9.2 (x86_64-little_endian-lp64
shared (dynamic) release build; by GCC 7.3.0)
PASS   : DavItemFetchJobTest::initTestCase()
QWARN  : DavItemFetchJobTest::runSuccessfullTest() kf5.kdbusaddons: Can
not find 'kdeinit5' executable at
"/usr/share/pkg-kde-tools/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games"
"/tmp/autopkgtest-lxc.m0yqmrr9/downtmp/build.7In/src/obj-x86_64-linux-gnu/bin,
/usr/lib/qt5/bin"
QWARN  : DavItemFetchJobTest::runSuccessfullTest() kf5.kio.core: KIO
Connection server not listening, could not connect
QWARN  : DavItemFetchJobTest::runSuccessfullTest() kf5.kio.core:
couldn't create slave: "Can not create socket for launching io-slave for
protocol 'http'."
FAIL!  : DavItemFetchJobTest::runSuccessfullTest()
'fakeServer.isAllScenarioDone()' returned FALSE. ()
   Loc:
[/tmp/autopkgtest-lxc.m0yqmrr9/downtmp/build.7In/src/autotests/davitemfetchjobtest.cpp(42)]
PASS   : DavItemFetchJobTest::cleanupTestCase()
Totals: 2 passed, 1 failed, 0 skipped, 0 blacklisted, 9ms
* Finished testing of DavItemFetchJobTest *

Start 5: kdav-davitemslistjob
5/5 Test #5: kdav-davitemslistjob .   Passed0.01 sec

80% tests passed, 1 tests failed out of 5

Total Test time (real) =   0.09 sec

The following tests FAILED:
  4 - kdav-davitemfetchjob (Failed)
Errors while running CTest
make[3]: *** [Makefile:99: test] Error 8


Paul

¹ https://ci.debian.net/packages/k/kdav/unstable/amd64/











signature.asc
Description: OpenPGP digital signature

Bug#895000: atril always shows a stacktrace/crash from webkit displaying pdf files

[Jeremy Bicha]

Control: forwarded -1 https://bugs.webkit.org/show_bug.cgi?id=183348
Control: severity -1 important

Here's the upstream webkit2gtk bug report for the issue affecting
xreader (a fork of atril not in Debian) and atril.

Thanks,
Jeremy Bicha

Bug#895631: libkf5libkdepim: autopkgtest fails with new release while succeeded in the past

[Paul Gevers]

Source: libkf5libkdepim
Version: 4:17.12.3-1
Severity: normal
User: ci-t...@tracker.debian.org
Usertags: regression

With the upload of version 17.12.3-1 of libkf5libkdepim, the
autopkgtest¹ started to fail with the following error:

autopkgtest [15:29:56]: test acc: [---
objdump: /usr/lib/x86_64-linux-gnu/libc++.so: File format not recognized
objdump: /usr/lib/x86_64-linux-gnu/libc.so: File format not recognized
objdump: /usr/lib/x86_64-linux-gnu/libm.so: File format not recognized
objdump: /usr/lib/x86_64-linux-gnu/libpthread.so: File format not recognized
cc1: warning: command line option ‘-std=c++11’ is valid for C++/ObjC++
but not for C
dh_acc: abi-compliance-checker -q -l libkf5libkdepim-dev -v1 4:17.12.3-1
-dump debian/libkf5libkdepim-dev.acc -dump-path
debian/libkf5libkdepim-dev/usr/lib/x86_64-linux-gnu/dh-acc/libkf5libkdepim-dev_4:17.12.3-1.abi.tar.gz
returned exit code 5

Paul

¹ https://ci.debian.net/packages/libk/libkf5libkdepim/unstable/amd64/









signature.asc
Description: OpenPGP digital signature

Bug#895624: (No Subject)

[Fjfj109]

And also I'm sorry for filing this as a normal bug instead of a wishlist, as it 
should have been

Bug#895630: pdf2djvu: FTBFS with poppler 0.63.0: tests fail: PDF syntax warning: EOF while reading header

[Emilio Pozuelo Monfort]

Package: pdf2djvu
Version: 0.9.8-1
Severity: important

Hi,

Another Poppler transition. pdf2djvu fails to build with it, see
the attached build log. Packages are available in experimental
in case you want to try it. I will bump this report to serious
once the transition starts.

Cheers,
Emilio

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

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

Versions of packages pdf2djvu depends on:
pn  djvulibre-bin   
ii  libc6   2.27-3
ii  libdjvulibre21  3.5.27.1-8
ii  libexiv2-14 0.25-3.1
ii  libgcc1 1:8-20180402-1
ii  libgomp18-20180402-1
pn  libgraphicsmagick++-q16-12  
pn  libgraphicsmagick-q16-3 
ii  libpoppler730.62.0-2
ii  libstdc++6  8-20180402-1
ii  libuuid12.31.1-0.5

pdf2djvu recommends no packages.

Versions of packages pdf2djvu suggests:
ii  poppler-data  0.4.8-2
I: Using pkgname logfile
I: Current time: Fri Apr 13 19:14:06 CEST 2018
I: pbuilder-time-stamp: 1523639646
I: Obtaining the cached apt archive contents
I: Copying source file
I: copying 
[/home/emilio/deb/pkg-freedesktop/rebuild/pdf2djvu/pdf2djvu_0.9.8-1.dsc]
I: copying 
[/home/emilio/deb/pkg-freedesktop/rebuild/pdf2djvu/pdf2djvu_0.9.8.orig.tar.xz]
I: copying 
[/home/emilio/deb/pkg-freedesktop/rebuild/pdf2djvu/pdf2djvu_0.9.8.orig.tar.xz.asc]
I: copying 
[/home/emilio/deb/pkg-freedesktop/rebuild/pdf2djvu/pdf2djvu_0.9.8-1.debian.tar.xz]
I: Extracting source
gpgv: unknown type of key resource 'trustedkeys.kbx'
gpgv: keyblock resource '/home/emilio/.gnupg/trustedkeys.kbx': General error
gpgv: Signature made Thu Mar  8 18:17:42 2018 CET
gpgv:using RSA key 46CB1CA89EA3B74376761DB915E09AF4DF5182C8
gpgv: Can't check signature: No public key
dpkg-source: warning: failed to verify signature on ./pdf2djvu_0.9.8-1.dsc
dpkg-source: info: extracting pdf2djvu in pdf2djvu-0.9.8
dpkg-source: info: unpacking pdf2djvu_0.9.8.orig.tar.xz
dpkg-source: info: unpacking pdf2djvu_0.9.8-1.debian.tar.xz
I: using fakeroot in build.
I: Installing the build-deps
I: user script /var/cache/pbuilder/build/cow.4132/tmp/hooks/D01experimental 
starting
$ENABLE_EXP not set, not adding experimental to sources.list
I: user script /var/cache/pbuilder/build/cow.4132/tmp/hooks/D01experimental 
finished
I: user script 
/var/cache/pbuilder/build/cow.4132/tmp/hooks/D02local-packages starting
Reading package lists...
Building dependency tree...
Reading state information...
apt-utils is already the newest version (1.6~beta1).
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
I: user script 
/var/cache/pbuilder/build/cow.4132/tmp/hooks/D02local-packages finished
W: execute priv not set on file D03ftp-debian-org, not executing.
I: user script 
/var/cache/pbuilder/build/cow.4132/tmp/hooks/D05apt-get-update starting
Get:1 file:/var/cache/pbuilder/mirror ./ InRelease
Ign:1 file:/var/cache/pbuilder/mirror ./ InRelease
Get:2 file:/var/cache/pbuilder/mirror ./ Release
Ign:2 file:/var/cache/pbuilder/mirror ./ Release
Get:3 file:/var/cache/pbuilder/mirror ./ Packages
Ign:3 file:/var/cache/pbuilder/mirror ./ Packages
Get:3 file:/var/cache/pbuilder/mirror ./ Packages
Ign:3 file:/var/cache/pbuilder/mirror ./ Packages
Get:3 file:/var/cache/pbuilder/mirror ./ Packages
Ign:3 file:/var/cache/pbuilder/mirror ./ Packages
Get:3 file:/var/cache/pbuilder/mirror ./ Packages
Ign:3 file:/var/cache/pbuilder/mirror ./ Packages
Get:3 file:/var/cache/pbuilder/mirror ./ Packages
Ign:3 file:/var/cache/pbuilder/mirror ./ Packages
Get:3 file:/var/cache/pbuilder/mirror ./ Packages [24.6 kB]
Get:4 http://ftp.es.debian.org/debian unstable InRelease [242 kB]
Get:5 http://incoming.debian.org/debian-buildd buildd-unstable InRelease [58.1 
kB]
Get:6 http://incoming.debian.org/debian-buildd buildd-unstable/main amd64 
Packages [313 kB]
Get:7 http://ftp.es.debian.org/debian unstable/main amd64 Packages.diff/Index 
[27.9 kB]
Get:8 http://ftp.es.debian.org/debian unstable/main amd64 Packages 
2018-04-13-0822.29.pdiff [2450 B]
Get:9 http://ftp.es.debian.org/debian unstable/main amd64 Packages 
2018-04-13-1422.54.pdiff [19.7 kB]
Get:9 http://ftp.es.debian.org/debian unstable/main amd64 Packages 
2018-04-13-1422.54.pdiff [19.7 kB]
Fetched 663 kB in 9s (75.9 kB/s)
Reading package lists...
I: user script 

Bug#895620: please ignore this for now

[George Roman]

Hi guys,

Please ignore this "bug" for now. I did further checks on the debian client
itself and it seem that somehow the DHCP client got an ip address that
comes out of the blue.
i did not manage to identify yet who allocated that IP yet cause it does
not exist in our network.



Thanks!

Bug#895629: vim-runtime: includeexpr for Scala files is wrong

[Jeremy Sowden]

Package: vim-runtime
Version: 2:8.0.1453-1
Severity: normal
Tags: patch upstream

Dear Maintainer,

While editing a Scala file, I entered "ctrl-w f" to open the source file for the
class name under the cursor.  Instead of opening another buffer and loading the
new file into it, Vim reported the following errors:

  E115: Missing quote: 'substitute(v:fname,
  E15: Invalid expression: 'substitute(v:fname,

I tracked it down to the includeexpr variable in
/usr/share/vim/vim80/ftplugin/scala.vim:

  setlocal includeexpr='substitute(v:fname,"\\.","/","g")'

The value should not be quoted.  Compare the equivalent from java.vim:

  setlocal includeexpr=substitute(v:fname,'\\.','/','g')

After changing the former to the latter, the errors went away and Vim opened the
new file as expected.

-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (990, 'testing'), (900, 'stable'), (500, 'oldoldstable-updates'), 
(99, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

vim-runtime depends on no packages.

Versions of packages vim-runtime recommends:
ii  vim-gtk [vim]  2:8.0.1453-1+b1
ii  vim-tiny   2:8.0.1453-1+b1

vim-runtime suggests no packages.

-- no debconf information
--- vim-8.0.1453/runtime/ftplugin/scala.vim.orig2018-04-13 
18:29:03.985204842 +0100
+++ vim-8.0.1453/runtime/ftplugin/scala.vim 2018-04-13 18:29:24.021359561 
+0100
@@ -27,7 +27,7 @@
 setlocal shiftwidth=2 softtabstop=2 expandtab
 
 setlocal include='^\s*import'
-setlocal includeexpr='substitute(v:fname,"\\.","/","g")'
+setlocal includeexpr=substitute(v:fname,"\\.","/","g")
 
 setlocal path+=src/main/scala,src/test/scala
 setlocal suffixesadd=.scala

Bug#895628: akonadi-search: autopkgtest fails with new release while succeeded in the past

[Paul Gevers]

Source: akonadi-search
Version: 4:17.12.3-1
Severity: normal
User: ci-t...@tracker.debian.org
Usertags: regression

With the upload of version 17.12.3-1 of akonadi-search, the
autopkgtest¹ started to fail with the following error:

autopkgtest [04:01:09]: test acc: [---
objdump: /usr/lib/x86_64-linux-gnu/libc++.so: File format not recognized
objdump: /usr/lib/x86_64-linux-gnu/libc.so: File format not recognized
objdump: /usr/lib/x86_64-linux-gnu/libm.so: File format not recognized
objdump: /usr/lib/x86_64-linux-gnu/libpthread.so: File format not recognized
cc1: warning: command line option ‘-std=c++11’ is valid for C++/ObjC++
but not for C
dh_acc: abi-compliance-checker -q -l libkf5akonadisearch-dev -v1
4:17.12.3-1 -dump debian/libkf5akonadisearch-dev.acc -dump-path
debian/libkf5akonadisearch-dev/usr/lib/x86_64-linux-gnu/dh-acc/libkf5akonadisearch-dev_4:17.12.3-1.abi.tar.gz
returned exit code 5

Paul

¹ https://ci.debian.net/packages/a/akonadi-search/unstable/amd64/







signature.asc
Description: OpenPGP digital signature

Bug#895627: intone: Dead upstream (last commit Feb 2012)

[Andreas Metzler]

Package: intone
Version: 0.77+git20120308-1
Severity: normal

Hello,

intone is dead upstream:
* last commit March 2012
* no homepage, just the archived copy on
  https://code.google.com/archive/p/intone/source
* Popcon 33
* Uses E_DBus, also dead upstream since 2014.

Could this be dropped from Debian?

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

Bug#893411: sat4j FTBFS with openjdk-9

[Markus Koschany]

Control: tags -1 pending

Dear maintainer,

I've uploaded a new revision of sat4j versioned as 2.3.5-0.3 to fix
Debian bug #893411. Please find attached the debdiff.

Regards,

Markus
diff -Nru sat4j-2.3.5/debian/changelog sat4j-2.3.5/debian/changelog
--- sat4j-2.3.5/debian/changelog2016-11-04 23:10:51.0 +0100
+++ sat4j-2.3.5/debian/changelog2018-04-13 18:54:47.0 +0200
@@ -1,3 +1,10 @@
+sat4j (2.3.5-0.3) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add encoding.patch and fix FTBFS with Java 9. (Closes: #893411)
+
+ -- Markus Koschany   Fri, 13 Apr 2018 18:54:47 +0200
+
 sat4j (2.3.5-0.2) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru sat4j-2.3.5/debian/patches/encoding.patch 
sat4j-2.3.5/debian/patches/encoding.patch
--- sat4j-2.3.5/debian/patches/encoding.patch   1970-01-01 01:00:00.0 
+0100
+++ sat4j-2.3.5/debian/patches/encoding.patch   2018-04-13 18:54:47.0 
+0200
@@ -0,0 +1,32 @@
+From: Markus Koschany 
+Date: Fri, 13 Apr 2018 18:53:35 +0200
+Subject: encoding
+
+Fix FTBFS with Java 9 by specifying the encoding everywhere.
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=893411
+---
+ build.xml | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+diff --git a/build.xml b/build.xml
+index 88f9620..e6016a5 100644
+--- a/build.xml
 b/build.xml
+@@ -326,6 +326,7 @@
+   destdir="${build}"
+   source="1.5"
+   target="${target}"
++  encoding="iso-8859-1"
+   debug="true"
+   includeantruntime="true">
+   
+@@ -430,7 +431,8 @@
+ 
+   Compiling test files
+-  
++  
+   
+   
+   Running JUNIT tests
diff -Nru sat4j-2.3.5/debian/patches/series sat4j-2.3.5/debian/patches/series
--- sat4j-2.3.5/debian/patches/series   2016-11-04 22:57:45.0 +0100
+++ sat4j-2.3.5/debian/patches/series   2018-04-13 18:54:47.0 +0200
@@ -1,2 +1,3 @@
 commmons-cli
 debian-build
+encoding.patch


signature.asc
Description: OpenPGP digital signature

Bug#895626: emacs25: In GUI mode, emacs-lisp fail to read some number

[Remi Vanicat]

Package: emacs25
Version: 25.2+1-6+b1
Severity: normal

In GUI mode, evaluating (read "2.6") give 2.0, when in text mode it give
2.6 correctly. Then others thing break, like (package-initialize). 

I tried to install emacs25-lucid, but it change nothing.

Thing was working correctly until recently, log tell me that
libfontconfig1 has been updated from 2.12.6-0.1 to 2.13.0-2, and
libglib2.0-0 from 2.56.1-1 to 2.56.1-2.

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

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

Versions of packages emacs25 depends on:
ii  emacs25-bin-common 25.2+1-6+b1
ii  libacl12.2.52-3+b1
ii  libasound2 1.1.3-5
ii  libatk1.0-02.28.1-1
ii  libc6  2.27-3
ii  libcairo-gobject2  1.15.10-2
ii  libcairo2  1.15.10-2
ii  libdbus-1-31.13.2-1
ii  libfontconfig1 2.13.0-2
ii  libfreetype6   2.8.1-2
ii  libgdk-pixbuf2.0-0 2.36.11-2
ii  libgif75.1.4-2
ii  libglib2.0-0   2.56.1-2
ii  libgnutls303.6.2-2
ii  libgomp1   8-20180402-1
ii  libgpm21.20.7-5
ii  libgtk-3-0 3.22.29-3
ii  libice62:1.0.9-2
ii  libjpeg62-turbo1:1.5.2-2+b1
ii  libm17n-0  1.7.0-3+b2
ii  libmagickcore-6.q16-5  8:6.9.9.39+dfsg-1
ii  libmagickwand-6.q16-5  8:6.9.9.39+dfsg-1
ii  libotf00.9.13-3+b1
ii  libpango-1.0-0 1.42.1-1
ii  libpangocairo-1.0-01.42.1-1
ii  libpng16-161.6.34-1
ii  librsvg2-2 2.40.20-2
ii  libselinux12.7-2+b2
ii  libsm6 2:1.2.2-1+b3
ii  libtiff5   4.0.9-4
ii  libtinfo5  6.1+20180210-1
ii  libx11-6   2:1.6.5-1
ii  libx11-xcb12:1.6.5-1
ii  libxcb11.13-1
ii  libxfixes3 1:5.0.3-1
ii  libxft22.3.2-1+b2
ii  libxinerama1   2:1.1.3-1+b3
ii  libxml22.9.7+dfsg-1
ii  libxpm41:3.5.12-1
ii  libxrandr2 2:1.5.1-1
ii  libxrender11:0.9.10-1
ii  zlib1g 1:1.2.8.dfsg-5

emacs25 recommends no packages.

Versions of packages emacs25 suggests:
ii  emacs25-common-non-dfsg  25.2+1-1

-- no debconf information

-- 
Rémi Vanicat

Bug#889968: RFS: inotify-tools/3.14-4

[Gianfranco Costamagna]

Hello,

>The next thing you might try is `git deborig`.  But I understand just
>asking Dmitry!


git deborig -f upstream/3.14

same effect, as well
as 
git deborig -f v3.14...

G.

Bug#895625: [node-node-uuid] please update to version 3.0.1 or higher

[Paolo Greppi]

Package: node-node-uuid
Version: 1.4.7-5
Severity: normal

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

According to npm registry:
https://www.npmjs.com/package/node-uuid "node-uuid DEPRECATED: Use the uuid 
package instead."
https://www.npmjs.com/package/uuid points to: 
https://github.com/kelektiv/node-uuid

It appears node-uuid was a fork, then it got merged back.
There are two github projects both confusingly called "node-uuid":
- current: https://github.com/kelektiv/node-uuid is at 3.1.0
- deprecated: https://github.com/broofa/node-uuid is at 3.0.0
whereas now the module in npm registry is called "uuid".

ATM the upstream for this package is the latter.
BTW there must be something wrong with debian/watch because the tracker says "a 
new upstream version is available: 1.4.7.4.7" whereas the most recent tag is 
3.0.0.

Anyway the most recent version of the current github repo is 3.2.1 but I need 
at least 3.0.1 for yarn.

Please set the upstream to https://github.com/kelektiv/node-uuid and update the 
package to 3.0.1 or later

Thanks !

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

Debian Release: buster/sid
  500 testing mi.mirror.garr.it 

--- Package information. ---
Depends  (Version) | Installed
==-+-===
nodejs | 8.9.3~dfsg-12
libjs-node-uuid| 1.4.7-5


Package's Recommends field is empty.

Package's Suggests field is empty.

Bug#895623: golang-github-juju-testing: dep8 test failure with mongodb 3.6

[Robie Basak]

Package: golang-github-juju-testing
Version: 0.0~git20170608.2fe0e88-3
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu bionic ubuntu-patch

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

I'm bumping up to mongodb 3.6, which isn't currently in Debian but I
expect will happen sooner or later. At this point, you'll need this
package updated to a new upstream, or you'll need to cherry-pick the
same patch, to fix dep8.

I will separately submit my mongodb 3.6 updates to Debian.

Thanks for considering the patch.

*** 
/tmp/tmpOdgl3i/golang-github-juju-testing_0.0~git20170608.2fe0e88-3ubuntu1.debdiff
diff -Nru 
golang-github-juju-testing-0.0~git20170608.2fe0e88/debian/patches/mongodb-3.6 
golang-github-juju-testing-0.0~git20170608.2fe0e88/debian/patches/mongodb-3.6
--- 
golang-github-juju-testing-0.0~git20170608.2fe0e88/debian/patches/mongodb-3.6   
1970-01-01 01:00:00.0 +0100
+++ 
golang-github-juju-testing-0.0~git20170608.2fe0e88/debian/patches/mongodb-3.6   
2018-04-13 16:47:11.0 +0100
@@ -0,0 +1,39 @@
+From 1f2396685494ccf2c5079936561a70652ef78111 Mon Sep 17 00:00:00 2001
+From: John Arbash Meinel 
+Date: Mon, 2 Apr 2018 15:18:23 +0400
+Subject: [PATCH] Changes to support Mongo 3.6.
+
+Don't drop the 'admin' database, and we don't actually need to pass
+`--nohttpinterface`.
+
+In 3.6, there is no '--httpinterface' that you could pass, so there is
+also not its negation. But since it isn't the default, we don't actually
+ever need to pass it.
+
+Origin: upstream, 
https://github.com/juju/testing/commit/1f2396685494ccf2c5079936561a70652ef78111
+Last-Update: 2018-04-13
+---
+ mgo.go | 3 +--
+ 1 file changed, 1 insertion(+), 2 deletions(-)
+
+diff --git a/mgo.go b/mgo.go
+index c128747..de668ca 100644
+--- a/mgo.go
 b/mgo.go
+@@ -230,7 +230,6 @@ func (inst *MgoInstance) run() error {
+   "--nssize", "1",
+   "--noprealloc",
+   "--smallfiles",
+-  "--nohttpinterface",
+   "--oplogSize", "10",
+   "--ipv6",
+   "--setParameter", "enableTestCommands=1",
+@@ -744,7 +743,7 @@ func (inst *MgoInstance) Reset() error {
+   logger.Infof("reset successfully reset admin password")
+   for _, name := range dbnames {
+   switch name {
+-  case "local", "config":
++  case "local", "config", "admin":
+   // don't delete these
+   continue
+   }
diff -Nru 
golang-github-juju-testing-0.0~git20170608.2fe0e88/debian/patches/series 
golang-github-juju-testing-0.0~git20170608.2fe0e88/debian/patches/series
--- golang-github-juju-testing-0.0~git20170608.2fe0e88/debian/patches/series
1970-01-01 01:00:00.0 +0100
+++ golang-github-juju-testing-0.0~git20170608.2fe0e88/debian/patches/series
2018-04-13 16:46:26.0 +0100
@@ -0,0 +1 @@
+mongodb-3.6


signature.asc
Description: PGP signature

Bug#895624: debian-www: https://www.debian.org/devel/debian-installer/ entreats users to install Testing incorrectly

[annadane]

Package: debian-www
Severity: normal

Dear Maintainer,

The page https://www.debian.org/devel/debian-installer/ says: "To install 
Debian testing, we recommend you use the Buster Alpha 2 release of the 
installer, after checking its errata."

The general recommended way as I understand it to install testing is just to 
upgrade the system from a minimal stable install; in my opinion consider 
removing that section from the website, even with the errata the installer can 
be broken in ways not listed. Which is fine, if the goal is to test the 
installer, but as I said, a more foolproof way is likely to just upgrade from a 
minimal stable. 

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

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

Bug#850756: cryptsetup: Please save password to kernel keyring

[Laurent Bigonville]

On Mon, 09 Jan 2017 23:58:11 +0100 Laurent Bigonville  
wrote:


> Hi,
>
> Since gdm 3.22, there is a new pam module that unlock the gnome-keyring
> using the keyring using the password of the luks partition.
>
> The idea is that on a single user laptop, the user uses the same
> password for his encrypted root and user in addition to autologin.
>
> Tje pam module read the kernel keyring to find that password with the
> followin code:
>
> serial = find_key_by_type_and_desc ("user", "cryptsetup", 0);
> if (serial == 0)
> return PAM_AUTHINFO_UNAVAIL;
>
> r = keyctl_read_alloc (serial, _password);
>
> So it would be nice if cryptsetup could store that password in the
> keyring after opening successfully the main luks partition.
>
> Regards,

OK, what could be done for this?

I guess that askpass could store the password in the keyring if a flag 
is passed to it asking for it?


Would that be a viable solution?

The difficult part would be to detect a wrong password and not store it 
I guess?

Bug#895622: php-crypt-chap: build-depends on php-mcrypt which is no more

[Emilio Pozuelo Monfort]

Package: php-crypt-chap
Version: 1.5.0-2
Severity: serious

Hi,

php-mcrypt is no longer built, so php-crypt-chap should stop build-depending
on it.

Emilio

Bug#895619: plexus-compiler: use --release instead of -source/-target for jdk9+ when setting defaults

[Emmanuel Bourg]

Thank you for the patch Tiago. "1.7" is repeated many time, that might
be nice to put it in a variable so we can update the patch easily in the
future.

Emmanuel

Bug#895601: [Android-tools-devel] Bug#895601: simg2img: Please build simg2img and img2simg for other architectures, specifically arm64

[殷啟聰 | Kai-Chung Yan]

I personally agree with enabling other architectures. You never know if there 
are arch-specific bugs if you don't build them. And now that we have LAVA to 
test them for us, which is a win-win.

Bug#895100: roundcube: Remove php-mcrypt dependent

[Emilio Pozuelo Monfort]

Control: severity -1 serious

On Sat, 07 Apr 2018 10:06:36 +0800 John Wong  wrote:
> Package: roundcube
> Version: 1.3.3+dfsg.1-2
> Severity: wishlist
> 
> Dear Maintainer,
> 
> *** Reporter, please consider answering these questions, where appropriate ***
> 
> Since php7.2 is the default debian's php's version, and php7.2 does not had 
> php-mcrypt,
> So, please remove php-mcrypt dependent.

php-mcrypt is no longer built, so this is RC.

Emilio

Bug#895619: plexus-compiler: use --release instead of -source/-target for jdk9+ when setting defaults

[Tiago Daitx]

Please consider the attached debdiff for review.

On why it is important to use --release instead of the usual -source/-target:
any package that is not build with it can run into those
incompatibilities at runtime when run with an older (but targeted)
release. As a lot of libraries are being build with only
-source/-target set any package that depend on those won't run on
older (but targeted) jdk. It can also affect builds in case the
compiled tool is run during build time with the same old targeted jdk
- see bug #895234 where it was impossible to build
libcommons-lang3-java with openjdk-8 because bnd would fail. In fact,
for the affected packages (ie. use of flip()Ljava/nio/ByteBuffer),
since the build works but runtime fails the current scenario is the
same as setting -target 1.9.

This is already happening with the transition from openjdk-8 to 9 and,
although there's no such indication, it could also affect the
transition from 9/10 to 11 if they do similar changes to the JDK.

Another alternative to using --release is fixing the code that uses
the incompatible API, such as was done for gradle [1], but that does
not scale as well and it is reactive since errors are only detected
during runtime.

Regards,
Tiago

References:
[1] 
https://sources.debian.org/src/gradle/3.4.1-7/debian/patches/java8-compatibility.patch

On Fri, Apr 13, 2018 at 12:14 PM, Tiago Stürmer Daitx
 wrote:
> Source: plexus-compiler
> Version: 2.8.2-5
> Severity: normal
>
> Dear Maintainer,
>
> plexus-compiler currently will default -source and/or -target to 1.7
> whenever the following occours:
> 1) whenever either has not being set
> 2) whenever either has been set to 1.6 or earlier
>
> This patch modifies the detection logic in order to be able to set the
> '--release' flag when (and only when):
> - the '--release' is *not* set
> - AND both -source and -target are being set to a default value
> - AND the running jvm is jdk9 or newer
>
> This prevents errors such as the infamous "Method
> flip()Ljava/nio/ByteBuffer; does not exist in class java.nio.ByteBuffer"
> that is caused by building with openjdk-9 with -source set without
> setting the proper bootclasspath [1,2]. JEP-247 [3] has provided the
> --release to prevent such issues and should be used instead of -source
> whenever the javac being used is jdk9 or higher.
>
>
> I have tested and I can confirm it works fine, but I would like some
> review to make sure it is sane and get opinions on other (better?) ways
> to do this - specially concerning the detection of the jvm being run.
>
> Also, fork and an alternative javac compiler might be set, thus I would
> like to discuss as to what behavior it should default it in that case.
>
> Regards,
> Tiago Daitx
>
> References:
> [1] https://bugs.launchpad.net/ubuntu/+source/gradle/+bug/1760359
> [2] https://github.com/plasma-umass/doppio/issues/497
> [3] http://openjdk.java.net/jeps/247
>
>
> -- System Information:
> Debian Release: buster/sid
>   APT prefers bionic
>   APT policy: (500, 'bionic'), (400, 'bionic-proposed')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 4.15.0-13-generic (SMP w/8 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
> LANGUAGE=en_US (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled



-- 
Tiago Stürmer Daitx
Software Engineer
tiago.da...@canonical.com

PGP Key: 4096R/F5B213BE (hkp://keyserver.ubuntu.com)
Fingerprint = 45D0 FE5A 8109 1E91 866E  8CA4 1931 8D5E F5B2 13BE
diff -Nru plexus-compiler-2.8.2/debian/changelog plexus-compiler-2.8.2/debian/changelog
--- plexus-compiler-2.8.2/debian/changelog	2017-09-18 10:31:35.0 -0300
+++ plexus-compiler-2.8.2/debian/changelog	2018-04-12 11:35:44.0 -0300
@@ -1,3 +1,10 @@
+plexus-compiler (2.8.2-6~01) UNRELEASED; urgency=medium
+
+  * Use a default --release instead of defaults -source/-target in order to
+have the right bootclasspath set as per JEP 247. (Closes: #895619)
+
+ -- Tiago Stürmer Daitx   Thu, 12 Apr 2018 14:35:44 +
+
 plexus-compiler (2.8.2-5) unstable; urgency=medium
 
   * Team upload.
diff -Nru plexus-compiler-2.8.2/debian/patches/auto-adjust-language-level.patch plexus-compiler-2.8.2/debian/patches/auto-adjust-language-level.patch
--- plexus-compiler-2.8.2/debian/patches/auto-adjust-language-level.patch	2017-07-04 03:58:08.0 -0300
+++ plexus-compiler-2.8.2/debian/patches/auto-adjust-language-level.patch	2018-04-12 11:35:44.0 -0300
@@ -3,40 +3,81 @@
 Forwarded: not-needed
 --- a/plexus-compilers/plexus-compiler-javac/src/main/java/org/codehaus/plexus/compiler/javac/JavacCompiler.java
 +++ b/plexus-compilers/plexus-compiler-javac/src/main/java/org/codehaus/plexus/compiler/javac/JavacCompiler.java
-@@ -339,12 +339,20 @@
+@@ -339,30 +339,64 @@ public class JavacCompiler
  }
  else
  {
+-// TODO: this 

Bug#895621: RM: enki-aseba/oldstable [armel armhf] -- RoQA; FTBFS for armel/armhf

[Georges Khaznadar]

Package: ftp.debian.org
Severity: normal

As Adrian Bunk reported in Bug#895499, the package enki-aseba cannot be built
for armel/armhf since those architectures use Qt5 libraries compiled with
OpenGL ES instead of OpenGL.

I uploaded a revision 1.6.0-6 which addresses this issue, but please can you
remove previous builds made for armel and armhf?

Thank you.

Bug#889968: RFS: inotify-tools/3.14-4

[Sean Whitton]

Hello,

On Fri, Apr 13 2018, Gianfranco Costamagna wrote:

>>Please try typing `origtargz`.
>
>
> it downloads the current one in the archive, without the patches, and
> then it fails with:

Ah, sorry, I thought it would invoke uscan.

The next thing you might try is `git deborig`.  But I understand just
asking Dmitry!

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#855091: fails 100% for me

[Adam Borowski]

On Fri, Apr 13, 2018 at 12:13:56PM -0300, Agustin Henze wrote:
> On 04/10/18 17:17, Adam Borowski wrote:
> > "sbuild aiocoap", on all my machines but one. :/
> > 
> > But, despite the error message being identical, the way Santiago triggers it
> > differs from me: he sees it randomly on 1-way machines, I see it
> > deterministically on multi-threaded.
> 
> Ok, I don't understand... I cannot reproduce it :(. I've tried with
> 
> gbp buildpackage --git-builder='sbuild -A -s --force-orig-source -d unstable 
> -j4'
> And it works well. Also I have tried with
> sbuild -d unstable aiocoap
> 
> And it works! Please find attached the result. So I can't reproduce it... If
> you can reproduce it and want trying to fix it, please go ahead and send me a
> patch.

Alas, I don't even know Python, much less aiocoap.  I'm running automated
archive rebuilds and reporting failures, without knowledge about individual
packages.  Thus, all I can assist with is "this reproduces for me on ten
different architecture combinations" but not make an actual patch.  Sorry...


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢰⠒⠀⣿⡁ 
⢿⡄⠘⠷⠚⠋⠀ ... what's the frequency of that 5V DC?
⠈⠳⣄

Bug#843021: 1.6.0 is out

[Paolo Greppi]

W.r.t. the previous time I looked (version 1.5.1) the dependencies have not 
changed much:
- Upgraded: 
  - bytes: 2.4.0 -> 3.0.0
  - debug: 2.2.0 -> 3.0.0
  - normalize-url: 1.9.1 -> 2.0.0

While for the build dependencies:
- New:
  - babel-plugin-transform-builtin-extend
- Upgraded:
  - eslint-config-fb-strict: 20.1.0-delta.3 -> 22.0.0
  - eslint-plugin-jest: 20.0.3 -> 21.0.0
  - eslint-plugin-relay: 0.0.8 -> 0.0.21
  - execa: 0.9.0 -> 0.10.0
  - flow-bin: 0.52.0 -> 0.66.0
  - gulp-watch: 4.3.5 -> 5.0.0
  - jest: 21.2.1 -> 22.4.3

Missing build deps:
- node-babel-plugin-array-includes
- node-babel-plugin-transform-builtin-extend
- node-jsinspect

Build-deps to update:
- node-execa 0.5.0 -> 0.10.0
- node-gulp-sourcemaps 1.9.1 -> 2.2.0
- node-temp 0.8.1 -> 0.8.3

Missing deps:
- deepequal
- dnscache https://bugs.debian.org/886866
- gunzip-maybe
- is-builtin-module
- node-normalize-url https://bugs.debian.org/886873
- puka https://bugs.debian.org/886849
- node-request-capture-har
- tar-fs
- v8-compile-cache
- yn (RFS)

Deps to update:
- node-emoji: 1.4.1 -> 1.6.1
- node-request: 2.26.1 -> 2.81.0
- node-node-uuid 1.4.7 -> 3.0.1, see this thread and replies:
https://lists.alioth.debian.org/pipermail/pkg-javascript-devel/2018-January/024067.html

Paolo

Bug#895619: plexus-compiler: use --release instead of -source/-target for jdk9+ when setting defaults

[Tiago Stürmer Daitx]

Source: plexus-compiler
Version: 2.8.2-5
Severity: normal

Dear Maintainer,

plexus-compiler currently will default -source and/or -target to 1.7
whenever the following occours:
1) whenever either has not being set
2) whenever either has been set to 1.6 or earlier

This patch modifies the detection logic in order to be able to set the
'--release' flag when (and only when):
- the '--release' is *not* set
- AND both -source and -target are being set to a default value
- AND the running jvm is jdk9 or newer

This prevents errors such as the infamous "Method
flip()Ljava/nio/ByteBuffer; does not exist in class java.nio.ByteBuffer"
that is caused by building with openjdk-9 with -source set without
setting the proper bootclasspath [1,2]. JEP-247 [3] has provided the
--release to prevent such issues and should be used instead of -source
whenever the javac being used is jdk9 or higher.


I have tested and I can confirm it works fine, but I would like some
review to make sure it is sane and get opinions on other (better?) ways
to do this - specially concerning the detection of the jvm being run.

Also, fork and an alternative javac compiler might be set, thus I would
like to discuss as to what behavior it should default it in that case.

Regards,
Tiago Daitx

References:
[1] https://bugs.launchpad.net/ubuntu/+source/gradle/+bug/1760359
[2] https://github.com/plasma-umass/doppio/issues/497
[3] http://openjdk.java.net/jeps/247


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

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

Bug#895224: pdfpc movie playback with gstreamer 1.14.0

[Barak A. Pearlmutter]

That dependency isn't being put in manually, it is automatic.
Basically, the system notices what the executable actually is linked
to:

$ ldd /usr/bin/pdf-presenter-console  | wc -l
88

$ ldd /usr/bin/pdf-presenter-console  | head -10
linux-vdso.so.1 (0x7ffee66e2000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f08f603c000)
libgobject-2.0.so.0 =>
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 (0x7f08f5de8000)
libglib-2.0.so.0 => /lib/x86_64-linux-gnu/libglib-2.0.so.0
(0x7f08f5ad2000)
libgio-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0
(0x7f08f5734000)
libgee-0.8.so.2 => /usr/lib/x86_64-linux-gnu/libgee-0.8.so.2
(0x7f08f546c000)
libpoppler-glib.so.8 =>
/usr/lib/x86_64-linux-gnu/libpoppler-glib.so.8 (0x7f08f520f000)
libcairo.so.2 => /usr/lib/x86_64-linux-gnu/libcairo.so.2
(0x7f08f4ef2000)
libgtk-3.so.0 => /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
(0x7f08f45ec000)
libgdk-3.so.0 => /usr/lib/x86_64-linux-gnu/libgdk-3.so.0
(0x7f08f42f8000)

$ ldd /usr/bin/pdf-presenter-console  | egrep -n gstream
17:libgstreamer-1.0.so.0 =>
/usr/lib/x86_64-linux-gnu/libgstreamer-1.0.so.0 (0x7f97c8313000)

But I guess even though it's not actually linked to gstreamer1.0-gtk3,
it must be dynamically loaded when appropriate or something like that.

So it isn't strictly necessary for the program to run, but it does
enhance its functionality.
I guess ... need to look into the details I suppose ...

Bug#895620: debian-installer fails due to DHCP issue

[George Roman]

Package: debian-installer

My setup:

Debian PXE server  ---severalL3 segments
-DHCP-ProxyDebian DHCP/PXE Client
Debian DHCP server
Debian TFTP server
Debian HTTP server



I am trying to use PXE boot by using debian stretch and i am trying to load
a preseed file.
After a successful pxe (client system got IP from dhcp server, i can see
the PXE options dialogue), I select  the debian auto installer which kicks
in but it fails at taking the preseed file. After looking into it it seem
to me that the problem is that the system does not wait for DHCP long
enough.

I monitored the activity on the network side and i see 2 strange things:

-Debian Installer says that it successfully configured the network but this
is false as i can see that there was no new request coming to the DHCP
server. Also on the L3 switch (DHCP proxy) side where the debian DHCP
client is directly connected  i do not see an arp entry anymore after the
installer kicks in nor do i see the client sending a DHCP DISCOVER hitting
it from client side.

-I have noticed that if i wait long enough (while blue screen is on) and i
get the failure message related to the preseed file GET failure. If at this
point i go back to the "configure network" menu and i relaunch it , i can
get an IP address fine now and subsequently then the preseed file is taken
successfully also.

Here are some things i tried to resolve the issue:
-I went into BOOT_DEBUG=2 and once i see the network issue. i can go right
back to "configure network", i get an IP. This works every time.

-I tried adjusting the link detect time to 10 instead of default 3 but this
did not help.


I can consistently reproduce this problem.

Thanks,
George

Bug#895618: FTBFS: the instrumentation does not seem to be behaving correctly

[Daniel Stender]

Source: afl
Version: 2.52b-2
Severity: serious
Justification: fails to build from source (but built successfully in the past)

AFL currently FTBFS:


cc -g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong 
-Wformat -Werror=format-security -Wall -D_FORTIFY_SOURCE=2 -g -Wno-pointer-sign 
-DAFL_PATH=\"/usr/lib/afl\" -DDOC_PATH=\"/usr/share/doc/afl-doc/docs\" 
-DBIN_PATH=\"/usr/bin\" afl-analyze.c -o afl-analyze -Wl,-z,relro -Wl,-z,now 
-ldl
cc -g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong 
-Wformat -Werror=format-security -Wall -D_FORTIFY_SOURCE=2 -g -Wno-pointer-sign 
-DAFL_PATH=\"/usr/lib/afl\" -DDOC_PATH=\"/usr/share/doc/afl-doc/docs\" 
-DBIN_PATH=\"/usr/bin\" afl-as.c -o afl-as -Wl,-z,relro -Wl,-z,now -ldl
ln -sf afl-as as
[*] Testing the CC wrapper and instrumentation output...
unset AFL_USE_ASAN AFL_USE_MSAN; AFL_QUIET=1 AFL_INST_RATIO=100 AFL_PATH=. 
./afl-gcc -g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong 
-Wformat -Werror=format-security -Wall -D_FORTIFY_SOURCE=2 -g -Wno-pointer-sign 
-DAFL_PATH=\"/usr/lib/afl\" -DDOC_PATH=\"/usr/share/doc/afl-doc/docs\" 
-DBIN_PATH=\"/usr/bin\" test-instr.c -o test-instr -Wl,-z,relro -Wl,-z,now -ldl
echo 0 | ./afl-showmap -m none -q -o .test-instr0 ./test-instr
echo 1 | ./afl-showmap -m none -q -o .test-instr1 ./test-instr

Oops, the instrumentation does not seem to be behaving correctly!

Please ping  to troubleshoot the issue.

make[2]: *** [Makefile:95: test_build] Error 1
make[2]: Leaving directory '/<>'
make[1]: *** [debian/rules:27: override_dh_auto_build] Error 2


DS

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

Kernel: Linux 4.9.0-6-amd64 (SMP w/4 CPU cores)
Locale: LANG=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)

Bug#895613: asciidoctor FTBFS: test failures

[Joseph Herlant]

Thanks a lot for the quick answer! :)

> I can reproduce in a chroot with "dpkg-buildpackage -B"
> (there's likely some way to do the same in sbuild).

I'm now able to reproduce it with the following flags: `--arch-any
--no-arch-all`
I'll try to fix it this morning.

Thanks for the help!
Joseph

Bug#895419: Acknowledgement (python3-dolfin: JIT compilation fails as python3-instant tries to includes petsc4py from python2)

[Nico Schlömer]

I've had that issue in the past, but never bothered looking into it. Me,
I'll hold out for 2018.1 (which kills Python 2 support) to fix these kind
of bugs.

Cheers,
Nico

On Fri, Apr 13, 2018 at 4:54 PM Fabrice Silva  wrote:

> Additional information from Johannes Ring (fenics dev) on
> https://groups.google.com/d/topic/fenics-support/mfJdWYwq0-w/discussion
>
>The problem is that the path to petsc4py is included in
>/usr/share/dolfin/cmake/DOLFINConfig.cmake and
>/usr/share/dolfin/cmake/DOLFINTargets.cmake, while it should only
>have been included in /usr/share/dolfin/cmake/DOLFINPython27.cmake
>and /usr/share/dolfin/cmake/DOLFINPython36.cmake.
>
>The quick fix would be to either install python-petsc4py (the
>petsc4py include files are the same for python2 and python3) or to
>remove the path to petsc4py from DOLFINConfig.cmake and
>DOLFINTargets.cmake.
>
> These recommendations solve the trouble (even if other errors are still
> raised in the overly-simplified script).
>
>

Bug#895616: gradle: fix support for openjdk-9 --release flag

[Tiago Daitx]

Please consider the attached debdiff for fixing this bug.

thanks

-- 
Tiago Stürmer Daitx
Software Engineer
tiago.da...@canonical.com

PGP Key: 4096R/F5B213BE (hkp://keyserver.ubuntu.com)
Fingerprint = 45D0 FE5A 8109 1E91 866E  8CA4 1931 8D5E F5B2 13BE
diff -Nru gradle-3.4.1/debian/changelog gradle-3.4.1/debian/changelog
--- gradle-3.4.1/debian/changelog	2018-04-11 18:19:46.0 -0300
+++ gradle-3.4.1/debian/changelog	2018-04-12 18:01:31.0 -0300
@@ -1,3 +1,10 @@
+gradle (3.4.1-8) UNRELEASED; urgency=medium
+
+  * d/p/gnu-style-release-flag-jdk9.patch: Use GNU-style release flag for
+Java 9 compiler.
+
+ -- Tiago Stürmer Daitx   Thu, 12 Apr 2018 21:01:31 +
+
 gradle (3.4.1-7) unstable; urgency=medium
 
   * Team upload.
diff -Nru gradle-3.4.1/debian/patches/gnu-style-release-flag-jdk9.patch gradle-3.4.1/debian/patches/gnu-style-release-flag-jdk9.patch
--- gradle-3.4.1/debian/patches/gnu-style-release-flag-jdk9.patch	1969-12-31 21:00:00.0 -0300
+++ gradle-3.4.1/debian/patches/gnu-style-release-flag-jdk9.patch	2018-04-12 18:01:22.0 -0300
@@ -0,0 +1,97 @@
+Description: Use GNU-style release flag for Java 9 compiler
+ Since JDK 9 b135, only the new GNU-style option with double-dashes is
+ supported for the "--release" flag (see
+ https://bugs.openjdk.java.net/browse/JDK-8160851).
+Author: Yannick Welsch 
+Origin: upstream, https://github.com/gradle/gradle/commit/142f2f5233e77ba33146efe3815cd3b4b1245993
+Bug-Debian: https://bugs.debian.org/895616
+Forwarded: not-needed
+Applied-Upstream: https://github.com/gradle/gradle/commit/142f2f5233e77ba33146efe3815cd3b4b1245993
+Reviewed-by: Tiago Stürmer Daitx 
+Last-Update: 2018-04-12
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+
+From 142f2f5233e77ba33146efe3815cd3b4b1245993 Mon Sep 17 00:00:00 2001
+From: Yannick Welsch 
+Date: Mon, 17 Jul 2017 15:53:17 +0200
+Subject: [PATCH] Use GNU-style release flag for Java 9 compiler (#2474)
+
+Since JDK 9 b135, only the new GNU-style option with double-dashes is supported for the "--release" flag
+(see https://bugs.openjdk.java.net/browse/JDK-8160851).
+---
+ design-docs/jdk9-support.md | 6 +++---
+ .../api/internal/tasks/compile/JavaCompilerArgumentsBuilder.java| 2 +-
+ .../src/main/java/org/gradle/api/tasks/compile/CompileOptions.java  | 6 +++---
+ .../internal/tasks/compile/JavaCompilerArgumentsBuilderTest.groovy  | 6 +++---
+ .../org/gradle/java/compile/BasicJavaCompilerIntegrationSpec.groovy | 4 ++--
+ 5 files changed, 12 insertions(+), 12 deletions(-)
+
+
+--- a/subprojects/language-java/src/main/java/org/gradle/api/internal/tasks/compile/JavaCompilerArgumentsBuilder.java
 b/subprojects/language-java/src/main/java/org/gradle/api/internal/tasks/compile/JavaCompilerArgumentsBuilder.java
+@@ -227,7 +227,7 @@ public class JavaCompilerArgumentsBuilde
+ }
+ 
+ private boolean releaseOptionIsSet(List compilerArgs) {
+-return compilerArgs != null && compilerArgs.contains("-release");
++return compilerArgs != null && compilerArgs.contains("--release");
+ }
+ 
+ private void addClasspath() {
+--- a/subprojects/language-java/src/main/java/org/gradle/api/tasks/compile/CompileOptions.java
 b/subprojects/language-java/src/main/java/org/gradle/api/tasks/compile/CompileOptions.java
+@@ -315,10 +315,10 @@ public class CompileOptions extends Abst
+  * Defaults to the empty list.
+  *
+  * Compiler arguments not supported by the DSL can be added here. For example, it is possible
+- * to pass the {@code -release} option of JDK 9:
+- * compilerArgs.addAll(['-release', '7'])
++ * to pass the {@code --release} option of JDK 9:
++ * compilerArgs.addAll(['--release', '7'])
+  *
+- * Note that if {@code -release} is added then {@code -target} and {@code -source}
++ * Note that if {@code --release} is added then {@code -target} and {@code -source}
+  * are ignored.
+  */
+ @Input
+--- a/subprojects/language-java/src/test/groovy/org/gradle/api/internal/tasks/compile/JavaCompilerArgumentsBuilderTest.groovy
 b/subprojects/language-java/src/test/groovy/org/gradle/api/internal/tasks/compile/JavaCompilerArgumentsBuilderTest.groovy
+@@ -79,14 +79,14 @@ class JavaCompilerArgumentsBuilderTest e
+ builder.build() == ["-target", "1.4"] + defaultOptions
+ }
+ 
+-def "removes -source and -target option if -release is present"() {
++def "removes -source and -target option if --release is present"() {
+ when:
+-spec.compileOptions.compilerArgs += ['-release', '7']
++spec.compileOptions.compilerArgs += ['--release', '7']
+ spec.sourceCompatibility = '1.7'
+ spec.targetCompatibility = '1.7'
+ 
+ then:
+-builder.build() == defaultOptions + ['-release', '7']
++builder.build() == defaultOptions + 

Bug#895617: Cinnamon (Nemo): Missing extensions/plugins

[Peter Mueller]

Package: cinnamon
Version: 3.6.7-8
Severity: normal
Tags: missing

Dear Maintainer,

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


   * What led up to the situation?
Installed Debian Buster with Cinnamon.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
Tried to install further Plugins/Extensions for Nemo.

   * What was the outcome of this action?
Unfortunately, only 2 plugins for Nemo where available in Debian, but 
Nemo comes with more plugins, e.g.:


nemo-compare: nice support for a compare tool, for example Meld (which 
is available in Debian).


 * What outcome did you expect instead?
Nemo Plugins/Extension available in Debian Cinnamon.



ii  cinnamon3.6.7-8amd64  Innovative and 
comfortable desktop
ii  nemo3.6.5-1amd64  File manager and 
graphical shell for Cinnamon



-- no debconf information

Bug#895419: Acknowledgement (python3-dolfin: JIT compilation fails as python3-instant tries to includes petsc4py from python2)

[Fabrice Silva]

Additional information from Johannes Ring (fenics dev) on 
https://groups.google.com/d/topic/fenics-support/mfJdWYwq0-w/discussion

   The problem is that the path to petsc4py is included in
   /usr/share/dolfin/cmake/DOLFINConfig.cmake and
   /usr/share/dolfin/cmake/DOLFINTargets.cmake, while it should only
   have been included in /usr/share/dolfin/cmake/DOLFINPython27.cmake
   and /usr/share/dolfin/cmake/DOLFINPython36.cmake.

   The quick fix would be to either install python-petsc4py (the
   petsc4py include files are the same for python2 and python3) or to
   remove the path to petsc4py from DOLFINConfig.cmake and
   DOLFINTargets.cmake.

These recommendations solve the trouble (even if other errors are still
raised in the overly-simplified script).

--- /tmp/DOLFINConfig.cmake	2018-04-13 16:27:57.189842279 +0200
+++ /usr/share/dolfin/cmake/DOLFINConfig.cmake	2018-04-13 16:28:29.169796349 +0200
@@ -40,7 +40,7 @@
 set(DOLFIN_INCLUDE_DIRS "/usr/include")
 
 # Third party include directories
-set(DOLFIN_3RD_PARTY_INCLUDE_DIRS "/usr/include;/usr/include/eigen3;/usr/include/hdf5/openmpi;/usr/lib/python2.7/dist-packages/petsc4py/include;/usr/lib/x86_64-linux-gnu/openmpi/include/openmpi;/usr/lib/x86_64-linux-gnu/openmpi/include/openmpi/opal/mca/event/libevent2022/libevent;/usr/lib/x86_64-linux-gnu/openmpi/include/openmpi/opal/mca/event/libevent2022/libevent/include;/usr/lib/x86_64-linux-gnu/openmpi/include;/usr/lib/petscdir/petsc3.8/x86_64-linux-gnu-real/include;/usr/include/superlu-dist;/usr/include/hypre;/usr/include/suitesparse;/usr/include/superlu;/usr/include/scotch;/usr/include/hdf5/openmpi;")
+set(DOLFIN_3RD_PARTY_INCLUDE_DIRS "/usr/include;/usr/include/eigen3;/usr/include/hdf5/openmpi;/usr/lib/x86_64-linux-gnu/openmpi/include/openmpi;/usr/lib/x86_64-linux-gnu/openmpi/include/openmpi/opal/mca/event/libevent2022/libevent;/usr/lib/x86_64-linux-gnu/openmpi/include/openmpi/opal/mca/event/libevent2022/libevent/include;/usr/lib/x86_64-linux-gnu/openmpi/include;/usr/lib/petscdir/petsc3.8/x86_64-linux-gnu-real/include;/usr/include/superlu-dist;/usr/include/hypre;/usr/include/suitesparse;/usr/include/superlu;/usr/include/scotch;/usr/include/hdf5/openmpi;")
 
 # Python variables
 if ("ON" AND "TRUE")
--- /tmp/DOLFINTargets.cmake	2018-04-13 16:40:19.260234464 +0200
+++ /usr/share/dolfin/cmake/DOLFINTargets.cmake	2018-04-13 16:37:52.096803585 +0200
@@ -55,9 +55,9 @@
 
 set_target_properties(dolfin PROPERTIES
   INTERFACE_COMPILE_DEFINITIONS "NDEBUG;DOLFIN_SIZE_T=8;DOLFIN_LA_INDEX_SIZE=4;HAS_HDF5;_FORTIFY_SOURCE=2;HAS_SLEPC;HAS_PETSC;HAS_PETSC4PY;HAS_UMFPACK;HAS_CHOLMOD;HAS_SCOTCH;HAS_ZLIB;HAS_MPI;DOLFIN_VERSION=\"2017.2.0\""
-  INTERFACE_INCLUDE_DIRECTORIES "/usr/include;/usr/include/eigen3;/usr/include/hdf5/openmpi;/usr/lib/python2.7/dist-packages/petsc4py/include;/usr/lib/x86_64-linux-gnu/openmpi/include/openmpi;/usr/lib/x86_64-linux-gnu/openmpi/include/openmpi/opal/mca/event/libevent2022/libevent;/usr/lib/x86_64-linux-gnu/openmpi/include/openmpi/opal/mca/event/libevent2022/libevent/include;/usr/lib/x86_64-linux-gnu/openmpi/include"
+  INTERFACE_INCLUDE_DIRECTORIES "/usr/include;/usr/include/eigen3;/usr/include/hdf5/openmpi;/usr/lib/x86_64-linux-gnu/openmpi/include/openmpi;/usr/lib/x86_64-linux-gnu/openmpi/include/openmpi/opal/mca/event/libevent2022/libevent;/usr/lib/x86_64-linux-gnu/openmpi/include/openmpi/opal/mca/event/libevent2022/libevent/include;/usr/lib/x86_64-linux-gnu/openmpi/include"
   INTERFACE_LINK_LIBRARIES "Boost::boost;Boost::timer;/usr/lib/x86_64-linux-gnu/hdf5/openmpi/libhdf5.so;/usr/lib/x86_64-linux-gnu/libsz.so;/usr/lib/x86_64-linux-gnu/libz.so;/usr/lib/x86_64-linux-gnu/libdl.so;/usr/lib/x86_64-linux-gnu/libm.so;SLEPC::slepc;PETSC::petsc;/usr/lib/x86_64-linux-gnu/openmpi/lib/libmpi_cxx.so;/usr/lib/x86_64-linux-gnu/openmpi/lib/libmpi.so"
-  INTERFACE_SYSTEM_INCLUDE_DIRECTORIES "/usr/include;/usr/include/eigen3;/usr/include/hdf5/openmpi;/usr/lib/python2.7/dist-packages/petsc4py/include;/usr/lib/x86_64-linux-gnu/openmpi/include/openmpi;/usr/lib/x86_64-linux-gnu/openmpi/include/openmpi/opal/mca/event/libevent2022/libevent;/usr/lib/x86_64-linux-gnu/openmpi/include/openmpi/opal/mca/event/libevent2022/libevent/include;/usr/lib/x86_64-linux-gnu/openmpi/include"
+  INTERFACE_SYSTEM_INCLUDE_DIRECTORIES "/usr/include;/usr/include/eigen3;/usr/include/hdf5/openmpi;/usr/lib/x86_64-linux-gnu/openmpi/include/openmpi;/usr/lib/x86_64-linux-gnu/openmpi/include/openmpi/opal/mca/event/libevent2022/libevent;/usr/lib/x86_64-linux-gnu/openmpi/include/openmpi/opal/mca/event/libevent2022/libevent/include;/usr/lib/x86_64-linux-gnu/openmpi/include"
 )
 
 if(CMAKE_VERSION VERSION_LESS 2.8.12)

Bug#895193: transition: openmpi

[Emilio Pozuelo Monfort]

Control: tags -1 confirmed

On 11/04/18 11:12, Alastair McKinstry wrote:
> 
> 
> On 11/04/2018 10:07, John Paul Adrian Glaubitz wrote:
>> On 04/11/2018 10:53 AM, Alastair McKinstry wrote:
>>> As of 3.0.1, openmpi now works on Big-Endian powerpc (which was to be a
>>> problem; it had been dropped upstream because of an unknown bug, now
>>> fixed).
>>
>> Oh, really, they fixed that? I already had given up hopes and
>> therefore ignored
>> the thread on github out of frustration.
>>
>>From the thread (and related PRs it references) its fixed and works as
> long as -O3 is used.
> I've implemented and tested this in ./rules.
> 
>>> The other non-release archs were failing due to missing dependencies: in
>>> particular java support (not used by any package in stable/testing) and
>>> pmix (new; not used in testing/stable; pmix enables scaling to ~100,000+
>>> nodes, which is unlikely to be needed).
>>
>> I am working on fixing the remaining OpenJDK issues. I'm an upstream
>> committer in the OpenJDK project, so I can commit all changes myself.
>>
> Ok. I've just disabled support as necessary for archs with openjdk issues.
> While a riscv64 build has not yet occurred (awaiting in queue to see),
> all issues on all other archs should now be resolved,
> making the transition possible.

Great. Please go ahead.

Cheers,
Emilio