Bug#899403: Re : Bug#899403: pymodbus: Please provide a python3 package

[W. Martin Borgert]

On 2018-05-24 07:05, boudi...@gmail.com wrote:
> Sorry. I am using stretch and I forgot to give a look to unstable.

Not only unstable, but also testing and stretch-backports, just
an older version:
https://packages.debian.org/stretch-backports/python3-pymodbus

> Is it also possible to upgrade the package version?

I upgraded to 1.5.2 now. I will upgrade in stretch-backports,
as soon as this version goes to testing.

Bug#896134: seems fixed

[Russell Coker]

close 896134
thanks

After upgrading to 8.00~svn3725-2 this works.  It appears to be fixed.

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/

Bug#899403: Re : Bug#899403: pymodbus: Please provide a python3 package

[boudi...@gmail.com]

Sorry. I am using stretch and I forgot to give a look to unstable.

Is it also possible to upgrade the package version?

Regards
Cedric


- Reply message -
De : "W. Martin Borgert" 
Pour : "Cedric Boudinet" , <899...@bugs.debian.org>
Objet : Bug#899403: pymodbus: Please provide a python3 package
Date : mer., mai 23, 2018 22:14


On 2018-05-23 22:02, Cedric Boudinet wrote:
> The latest version (1.5.2) is compatible with python3.
> Is it possible to upgrade and create a python3-pymodbus package?

Done: https://packages.debian.org/unstable/python3-pymodbus :~)

Bug#899152: FTBFS: ipmi.h:85:2: error: unknown type name 'selector_t'

[Juhani Numminen]

On Sun, 20 May 2018 00:02:58 +0200 Adam Borowski  wrote:
> Source: openhpi
> Version: 3.6.1-3.1
> Severity: serious
> Justification: fails to build from source (but built successfully in the past)
> 
> Hi!
> I'm afraid that during a rolling archive rebuild, your package failed.
> Tried on armhf amd64; the error was:
> 
> In file included from ipmi.c:21:0:
> ipmi.h:85:2: error: unknown type name 'selector_t'

This seemed weird, because ipmi.h has #include  which
surely defines selector_t – except there's a new #ifdef in selector.h[2].
See upstream announcement[1].

Helmut, perhaps you can make the whole (cross-)build succeed with the flag
-DOPENIPMI_DEFINE_SELECTOR_T?


Cheers,
Juhani

[1] https://sourceforge.net/p/openipmi/mailman/message/35980029/
[2] 
https://sources.debian.org/src/openipmi/2.0.25-2/include/OpenIPMI/selector.h/#L44

Bug#899424: Cannot claim guest account

[Xavier Guimard]

Package: nm.debian.org
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hello,

I'm DM for a long time (before alioth). I recently tried to associate
my SSO account with my nm.debian.org identity:
 - find person returns only one entry
 - claim account says that this GPG key is already associated to someone
   (but who since "find" returns only one entry ?)

My SSO account is: xguimard-gu...@users.alioth.debian.org
My GPG Fingerprint is: 54E1 D219 982E 9675 58D5  7504 6ACE DAAE 40DD 2B46

Best regards,
Xavier

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

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

-BEGIN PGP SIGNATURE-

iQJGBAEBCgAwFiEEAN/li4tVV3nRAF7J9tdMp8mZ7ukFAlsGRbASHHguZ3VpbWFy
ZEBmcmVlLmZyAAoJEPbXTKfJme7pBFwP/3VlZIlaqhjv298LgMu9JiVSzxmPxaPv
adXGRDW+q06rVZBrCXSwM4XcBAhOzMNSga8+jHWWs2cQ6YiSsqUxBHLz8szPgloS
yN3irycGNiDb4bs11ffeIdoUiGZ9okSzT97Zoo6WZRLYh8IPyRfQnb6/aMBHnzZw
OfKyTNlPc5wDH1Gz0WQp9/mVrklsiaa+WFztrrVziSifA4JNrckWhePl+OUuUFUJ
lvAbW1h0qxr48+Z8uiPX6QlE0q2Qn7pDqzw7zi9JuhNVLEeJYojZHLRVCUpBbfWl
AuMen7f6T1qMnjG6e+vvB8Mati60vCytWo56iibU/tfD3C8B22o1HebmkWer6+Y5
wn0orM77S0mQ3wtexdT4fqq9zrDxlreOR17vHeV9QHTAdD5i3QM0sXfvjZaWp6Zf
XUP0yHYwU2y3qD4FZdORURfA0H0JgigYMe6abXcfbAkXWR5t7pHUxu2V8fiS5j5u
nJ1PBCk/s9rWqTqbBEoCCvKoQrXs+ZFohIrr9booO77oB1eTuDDoCH/1blw9F1nY
aGEmowk4Fpgfski+IWC22Q16Ul4Q/pCQY6v++A3AZExSAS2Z1pyqP7meMewrVzEs
+NELs0vxmEjnjcXseE8WMufFHTDEt7zkcCKNvG1+ooOCgktXVYSmHDUOiufeb4FE
8mmM6oQTXs0n
=eW0h
-END PGP SIGNATURE-

Bug#897802: linux: ftbfs with GCC-8

[Nobuhiro Iwamatsu]

Control: tag -1  fixed-upstream

Hi,

They are already fixed in upstream, commit
ad343a98e74e85aa91d844310e797f96fee6983b and
854e55ad289efe7991f0ada85d5846f5afb9.

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ad343a98e74e85aa91d844310e797f96fee6983b
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=854e55ad289efe7991f0ada85d5846f5afb9

Best regards,
  Nobuhiro

2018-05-10 8:35 GMT+09:00 Ben Hutchings :
> Control: tag -1 upstream
>
> These are the relevant error messages:
>
>   CC   
> /<>/debian/build/build_amd64_none_amd64/tools/objtool/pager.o
> pager.c: In function 'pager_preexec':
> pager.c:36:12: error: passing argument 2 to restrict-qualified parameter 
> aliases with argument 4 [-Werror=restrict]
>   select(1, , NULL, , NULL);
> ^~~~~~
> cc1: all warnings being treated as errors
>
>   CC   
> /<>/debian/build/build_amd64_none_amd64/tools/objtool/str_error_r.o
> ../lib/str_error_r.c: In function 'str_error_r':
> ../lib/str_error_r.c:25:3: error: passing argument 1 to restrict-qualified 
> parameter aliases with argument 5 [-Werror=restrict]
>snprintf(buf, buflen, "INTERNAL ERROR: strerror_r(%d, %p, %zd)=%d", 
> errnum, buf, buflen, err);
>^~~~
> cc1: all warnings being treated as errors
>
> These seem to be genuine bugs.
>
> Ben.
>
> --
> Ben Hutchings
> Humour is the best antidote to reality.



-- 
Nobuhiro Iwamatsu
   iwamatsu at {nigauri.org / debian.org}
   GPG ID: 40AD1FA6

Bug#898257: libclc-r600: problem is solved in 0.2.0+git20180518-1

[10dmar10]

Hi,

the problem is solved in  libclc-r600 version: 0.2.0+git20180518-1, thanks.

Bug#899423: xl2tpd FTCBFS: uses the build architecture compiler

[Helmut Grohne]

Source: xl2tpd
Version: 1.3.12-1
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

xl2tpd fails to cross build from source, because it uses the build
architecture compiler. The easiest way to pass cross compilers to make
is letting dh_auto_build do it. After doing so, xl2tpd cross builds
successfully. Please consider applying the attached patch.

Helmut
diff --minimal -Nru xl2tpd-1.3.12/debian/changelog 
xl2tpd-1.3.12/debian/changelog
--- xl2tpd-1.3.12/debian/changelog  2018-05-19 00:08:21.0 +0200
+++ xl2tpd-1.3.12/debian/changelog  2018-05-24 06:08:31.0 +0200
@@ -1,3 +1,10 @@
+xl2tpd (1.3.12-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCFBS: Let dh_auto_build pass cross compilers to make. (Closes: #-1)
+
+ -- Helmut Grohne   Thu, 24 May 2018 06:08:31 +0200
+
 xl2tpd (1.3.12-1) unstable; urgency=medium
 
   [ Samir Hussain ]
diff --minimal -Nru xl2tpd-1.3.12/debian/rules xl2tpd-1.3.12/debian/rules
--- xl2tpd-1.3.12/debian/rules  2017-10-22 19:40:48.0 +0200
+++ xl2tpd-1.3.12/debian/rules  2018-05-24 06:06:02.0 +0200
@@ -27,7 +27,7 @@
 build-indep: build-stamp
 build-stamp: configure-stamp 
dh_testdir
-   $(MAKE) CFLAGS=" -DDEBUG_PPPD -DTRUST_PPPD_TO_DIE -O2 -fno-builtin 
-Wall -DSANITY -DLINUX -I$(KERNELSRC)/include/ -DIP_ALLOCATION -DUSE_KERNEL 
$(shell dpkg-buildflags --get CFLAGS)" CPPFLAGS=" -DDEBUG_PPPD 
-DTRUST_PPPD_TO_DIE -O2 -fno-builtin -Wall -DSANITY -DLINUX 
-I$(KERNELSRC)/include/ -DIP_ALLOCATION $(shell dpkg-buildflags --get 
CPPFLAGS)" LDFLAGS=" $(shell dpkg-buildflags --get LDFLAGS)"
+   dh_auto_build -- CFLAGS=" -DDEBUG_PPPD -DTRUST_PPPD_TO_DIE -O2 
-fno-builtin -Wall -DSANITY -DLINUX -I$(KERNELSRC)/include/ -DIP_ALLOCATION 
-DUSE_KERNEL $(shell dpkg-buildflags --get CFLAGS)" CPPFLAGS=" -DDEBUG_PPPD 
-DTRUST_PPPD_TO_DIE -O2 -fno-builtin -Wall -DSANITY -DLINUX 
-I$(KERNELSRC)/include/ -DIP_ALLOCATION $(shell dpkg-buildflags --get 
CPPFLAGS)" LDFLAGS=" $(shell dpkg-buildflags --get LDFLAGS)"
touch $@
 
 clean:

Bug#899382: qt5-qmake: cross wrapper should supply PKG_CONFIG_EXECUTABLE

[Helmut Grohne]

On Thu, May 24, 2018 at 12:14:52AM +0300, Dmitry Shachnev wrote:
> On Wed, May 23, 2018 at 08:23:53PM +0200, Helmut Grohne wrote:
> > Thiago Macieira suggested an alternative approach to solving this.
> > Rather than telling qmake to use the "right" pkg-config at runtime, we
> > can tell it at build time.
> >
> > To that end we should build qtbase with a triplet-prefixed pkg-config.
> >
> > That actually works fairly well as the Debian packaging of pkg-config
> > ensures that -pkg-config is a symlink to pkg-config. So
> > just using the triplet-prefixed pkg-config always works (native and
> > cross). Where should we reassign this bug to?
> >
> > I think Thiago's approach is strictly better than mine, because it
> > ensures that qmake will always use the right pkg-config even without
> > passing PKG_CONFIG or PKG_CONFIG_EXECUTABLE to qmake. That should be
> > useful to people cross building with qmake without our cross wrapper.
> 
> I wonder how this approach will work.

Unlike the PKG_CONFIG_EXECUTABLE approach, I did not verify that it does
indeed work. So you might very well be correct about this.

> Our triplet-prefixed qmake is a wrapper that calls the native qmake with
> some arguments. If we configure qmake with prefixed pkg-config path, then
> the native qmake will call pkg-config corresponding to *its* (native)
> architecture, not the architecture we are building for.

If I understood the idea correctly, the value gets interpolated into
some .prf file. Those are installed into architecture-dependent
locations, so they can vary per architecture despite being text files.
During cross building, we use the build architecture qmake executable
and the host architecture .prf files, so this may actually work unless I
missing something.

Are the .prf files indeed interpolated at build time the way I am
picturing here? If not, we may need to ask Thiago for a clarification.

I suggest that you simply try building qtbase with the modified
PKG_CONFIG and search the qt5-qmake binary package (not qt5-qmake-bin)
for the value. If it doesn't show up, ask Thiago or fall back to setting
PKG_CONFIG_EXECUTABLE.

Helmut

Bug#898324: deal.ii: FTBFS against PETSc 3.9

[Drew Parsons]

On Thu, 10 May 2018 17:27:22 +0800 Drew Parsons 
wrote:
> 
> deal.ii no longer builds against PETSc (petsc 3.9).
...
> 
> This is because of changes in the PETSc API. 
> 


Update: PETSc upstream has reinstated the deprecated API in PETSc
3.9.2.  So deal.ii does build against petsc 3.9.2.

This bug can therefore be taken as an ordinary "upstream release
available" for upgrading to deal.ii 9.

Drew

Bug#899418: Reassign to source package

[zigifex]

Control: reassign -1 src:lvm2

Bug#899422: compiling with static linking results in linker errors

[zigifex]

Source: lvm2
Version: 2.02.168-2

I downloaded the package source files by running "apt-get source lvm2"
Then I ran "./configure --enable-static-link && make"

Configuration was successful but compilation throws up linker errors when it 
gets to dmsetup.c. Below is the last part of the compiler log:
gcc -c -I. -I../include -DHAVE_CONFIG_H -Wall -Wcast-align -Wfloat-equal 
-Wformat-security -Winline -Wmissing-format-attribute -Wmissing-include-dirs 
-Wmissing-noreturn -Wpointer-arith -Wredundant-decls -Wshadow -Wundef 
-Wwrite-strings -Wclobbered -Wempty-body -Wignored-qualifiers -Wlogical-op 
-Wtype-limits -Wsync-nand -Wmissing-declarations -Wmissing-prototypes 
-Wnested-externs -Wold-style-definition -Wstrict-prototypes -Wuninitialized 
-Wjump-misses-init -Wmissing-parameter-type -Wold-style-declaration 
-Woverride-init -O2 -fPIC dmsetup.c -o dmsetup.o
gcc -O2 -fPIC -O2 -L../libdm -L../lib -L../libdaemon/client -L../libdm 
-o dmsetup dmsetup.o -ldevmapper -lrt
gcc -O2 -fPIC -O2 -L../libdm -L../lib -L../libdaemon/client -static 
-L../libdm/ioctl 
-o dmsetup.static dmsetup.o -ldevmapper -lm -lpthread -lselinux -lsepol -lrt
/usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/libselinux.a(seusers.o):
 In function `getseuserbyname':
(.text+0x632): warning: Using 'getgrouplist' in statically linked applications 
requires at runtime the shared libraries from the glibc version used for linking
/usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/libselinux.a(seusers.o):
 In function `getseuserbyname':
(.text+0x5b0): warning: Using 'getgrnam_r' in statically linked applications 
requires at runtime the shared libraries from the glibc version used for linking
/usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/libselinux.a(seusers.o):
 In function `getseuserbyname':
(.text+0x499): warning: Using 'getpwnam_r' in statically linked applications 
requires at runtime the shared libraries from the glibc version used for linking
/usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/libselinux.a(regex.o):
 In function `regex_writef':
(.text+0x7b): undefined reference to `pcre_fullinfo'
/usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/libselinux.a(regex.o):
 In function `regex_writef':
(.text+0xef): undefined reference to `pcre_fullinfo'
/usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/libselinux.a(regex.o):
 In function `regex_data_free':
(.text+0x1ea): undefined reference to `pcre_free'
/usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/libselinux.a(regex.o):
 In function `regex_data_free':
(.text+0x1f8): undefined reference to `pcre_free_study'
/usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/libselinux.a(regex.o):
 In function `regex_prepare_data':
(.text+0x260): undefined reference to `pcre_compile'
/usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/libselinux.a(regex.o):
 In function `regex_prepare_data':
(.text+0x282): undefined reference to `pcre_study'
/usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/libselinux.a(regex.o):
 In function `regex_load_mmap':
(.text+0x38e): undefined reference to `pcre_fullinfo'
/usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/libselinux.a(regex.o):
 In function `regex_load_mmap':
(.text+0x414): undefined reference to `pcre_fullinfo'
/usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/libselinux.a(regex.o):
 In function `regex_match':
(.text+0x47f): undefined reference to `pcre_exec'
/usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/libselinux.a(regex.o):
 In function `regex_cmp':
(.text+0x4ed): undefined reference to `pcre_fullinfo'
/usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/libselinux.a(regex.o):
 In function `regex_cmp':
(.text+0x50a): undefined reference to `pcre_fullinfo'
/usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/libselinux.a(regex.o):
 In function `regex_version':
(.text+0x11): undefined reference to `pcre_version'
collect2: error: ld returned 1 exit status
Makefile:133: recipe for target 'dmsetup.static' failed
make[1]: *** [dmsetup.static] Error 1
make[1]: Leaving directory '/home/user/myapps/src/stretch/lvm2-2.02.168/tools'
make.tmpl:302: recipe for target 'tools.device-mapper' failed
make: *** [tools.device-mapper] Error 2

I was able to fix this by appending -lpcre to STATIC_LIBS in make.tmpl.in. 
After running configure and make, linker errors appeared when it came to 
creating lvm.static. Below is the last part of the compiler log:

gcc -O2 -fPIC -O2 -L../libdm -L../lib -L../libdaemon/client -static 
-L../libdm/ioctl -o lvm.static 
 dumpconfig.o formats.o lvchange.o lvconvert.o lvconvert_poll.o lvcreate.o 
lvdisplay.o lvextend.o lvmchange.o lvmcmdline.o lvmdiskscan.o lvreduce.o 
lvremove.o lvrename.o lvresize.o lvscan.o polldaemon.o pvchange.o pvck.o 
pvcreate.o pvdisplay.o pvmove.o pvmove_poll.o pvremove.o pvresize.o pvscan.o 
reporter.o segtypes.o tags.o toollib.o vgcfgbackup.o vgcfgrestore.o vgchange.o 
vgck.o vgcreate.o vgconvert.o vgdisplay.o 

Bug#899421: ITP: hangups -- hangups is the first third-party IM client for Google Hangouts

[Diane Trout]

Package: wnpp
Severity: wishlist
Owner: Diane Trout 

* Package name: hangups
  Version : 0.4.4
  Upstream Author : Tom Dryer 
* URL : https://github.com/tdryer/hangups/

* License : MIT
  Programming Lang: Python
  Description : hangups is the first third-party IM client for Google
Hangouts

 hangups is the first third-party instant messaging client for `Google
 Hangouts`_. It includes both a Python library and a reference client with a
 text-based user interface.


I was planning on maintaining this in the Debian Python modules team.

I also split the API into a seperate python3- modules seperate from the hangups
module that contains the client executable

Bug#899420: fmit: please upgrade to the latest version (1.2.x)

[Bob Bib]

Package: fmit
Version: 1.0.0-1+b1
Severity: wishlist

Dear Maintainer,

please upgrade FMIT to the latest upstream version;
currently, it's 1.2.4:
https://github.com/gillesdegottex/fmit/releases

--
Best wishes,
Bob

Bug#897436: owncloud-client: diff for NMU version 2.4.1+dfsg-1.1

[Pierre-Elliott Bécue]

Good evening,

Here is the nmudiff with a new patch. See
https://salsa.debian.org/owncloud-team/owncloud-client/merge_requests/1 for
a gitted version.

The second patch fixes other errors that may happen, and that were
mentionned in the forwarded bug on github.

The upload will probably occur in the coming day. :)

Cheers,

-- 
Pierre-Elliott Bécue
GPG: 9AE0 4D98 6400 E3B6 7528  F493 0D44 2664 1949 74E2
It's far easier to fight for one's principles than to live up to them.
diff -Nru owncloud-client-2.4.1+dfsg/debian/changelog owncloud-client-2.4.1+dfsg/debian/changelog
--- owncloud-client-2.4.1+dfsg/debian/changelog	2018-03-29 13:44:36.0 +0200
+++ owncloud-client-2.4.1+dfsg/debian/changelog	2018-05-24 03:40:48.0 +0200
@@ -1,3 +1,16 @@
+owncloud-client (2.4.1+dfsg-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add d/p/0010 to fix the nemo/nautilus shell integration encoding issues.
+(Closes: #897436)
+  * Add d/p/0011 to remove debug messages with nautilus integration that may
+also raise encoding errors.
+  * d/control:
+- Drop the X-Python3-Version that is obsolete
+- Bump Standards-Version to 4.1.4. No change required.
+
+ -- Pierre-Elliott Bécue   Thu, 24 May 2018 03:40:48 +0200
+
 owncloud-client (2.4.1+dfsg-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru owncloud-client-2.4.1+dfsg/debian/control owncloud-client-2.4.1+dfsg/debian/control
--- owncloud-client-2.4.1+dfsg/debian/control	2018-03-29 13:35:54.0 +0200
+++ owncloud-client-2.4.1+dfsg/debian/control	2018-05-24 03:40:15.0 +0200
@@ -31,10 +31,9 @@
  texlive-latex-extra,
  texlive-latex-recommended,
  xsltproc
-X-Python3-Version: >= 3.0
 Vcs-Git: https://salsa.debian.org/owncloud-team/owncloud-client.git
 Vcs-Browser: https://salsa.debian.org/owncloud-team/owncloud-client
-Standards-Version: 4.1.3
+Standards-Version: 4.1.4
 Homepage: https://owncloud.org/sync-clients/
 
 Package: owncloud-client
diff -Nru owncloud-client-2.4.1+dfsg/debian/patches/0010-Fix-nautilus-nemo-shell-integration-encoding-issues.patch owncloud-client-2.4.1+dfsg/debian/patches/0010-Fix-nautilus-nemo-shell-integration-encoding-issues.patch
--- owncloud-client-2.4.1+dfsg/debian/patches/0010-Fix-nautilus-nemo-shell-integration-encoding-issues.patch	1970-01-01 01:00:00.0 +0100
+++ owncloud-client-2.4.1+dfsg/debian/patches/0010-Fix-nautilus-nemo-shell-integration-encoding-issues.patch	2018-05-24 03:36:38.0 +0200
@@ -0,0 +1,70 @@
+From: =?utf-8?q?Pierre-Elliott_B=C3=A9cue?= 
+Date: Wed, 23 May 2018 19:18:04 +0200
+Subject: Fix nautilus/nemo shell integration encoding issues
+
+The problem was that plain encode()/decode() in python2 use ascii
+encoding, not utf8.
+
+Upstream git hash: 29557ea550a0baa6c223e87fdd54042944a5dd43
+
+---
+ shell_integration/nautilus/syncstate.py | 18 ++
+ 1 file changed, 10 insertions(+), 8 deletions(-)
+
+diff --git a/shell_integration/nautilus/syncstate.py b/shell_integration/nautilus/syncstate.py
+index 77a233d..4429588 100644
+--- a/shell_integration/nautilus/syncstate.py
 b/shell_integration/nautilus/syncstate.py
+@@ -38,8 +38,10 @@ print("Initializing "+appname+"-client-nautilus extension")
+ def get_local_path(url):
+ if url[0:7] == 'file://':
+ url = url[7:]
+-unquote = urllib.parse.unquote if python3 else urllib.unquote
+-return unquote(url)
++if python3:
++return urllib.parse.unquote(url)
++else:
++return urllib.unquote(url).decode('utf-8')
+ 
+ def get_runtime_dir():
+ """Returns the value of $XDG_RUNTIME_DIR, a directory path.
+@@ -61,7 +63,7 @@ class SocketConnect(GObject.GObject):
+ self._watch_id = 0
+ self._sock = None
+ self._listeners = [self._update_registered_paths]
+-self._remainder = ''.encode()
++self._remainder = ''.encode('utf-8')
+ self.nautilusVFSFile_table = {}  # not needed in this object actually but shared 
+  # all over the other objects.
+ 
+@@ -79,7 +81,7 @@ class SocketConnect(GObject.GObject):
+ # print("Server command: " + cmd)
+ if self.connected:
+ try:
+-self._sock.send(cmd.encode())
++self._sock.send(cmd.encode('utf-8'))
+ except:
+ print("Sending failed.")
+ self.reconnect()
+@@ -118,17 +120,17 @@ class SocketConnect(GObject.GObject):
+ # Prepend the remaining data from last call
+ if len(self._remainder) > 0:
+ data = self._remainder + data
+-self._remainder = ''.encode()
++self._remainder = ''.encode('utf-8')
+ 
+ if len(data) > 0:
+ # Remember the remainder for next round
+-lastNL = data.rfind('\n'.encode());
++lastNL = data.rfind('\n'.encode('utf-8'));
+ if 

Bug#894962: node-gulp: FTBFS and Debci failure with node-process-nextick-args 2.0.0-1

[Zebulon McCorkle]

On Thu, Apr 05, 2018 at 06:26:28PM +0300, Adrian Bunk wrote:
>  Uncaught TypeError: nextTick is not a function
>   at Cloneable.onData (/usr/lib/nodejs/cloneable-readable/index.js:32:5)

It looks like this is an issue with node-cloneable-readable, though I don't see
why nextTick wouldn't be a function. Maybe some other package is messing with
it?

-- 
Zebulon McCorkle
Email: zebmccor...@zeb.fun
IRC:
 - zebmccorkle@Freenode
 - zebmccorkle@OFTC
 - zeb@EsperNet
 - zeb@hackint
 - zeb@PdgnCo
 - zeb@EFNet
PGP: 803A 0F47 82AD DDEA 46BE  055F F8F9 DB8C 1A54 6398
 (Zebulon McCorkle )


signature.asc
Description: PGP signature

Bug#899335: CVE-2018-11364 CVE-2018-11365

[Dirk Eddelbuettel]

On 22 May 2018 at 23:38, Moritz Muehlenhoff wrote:
| Package: r-cran-haven
| Severity: normal
| Tags: security
| 
| r-cran-haven embeds a copy of ReadStat for which two security issues have been
| reported:
| 
| http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-11364
| http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-11365

Just to keep everybody in the loop, I contact upstream for the actual library
code (ie Evan, CC'ed, for ReadStat -- which is used in the R package haven
for which this CVE came in) and he was / is aware. This really came from a
set of Google auto-fuzzer reports.

Work is ongoing, but this may take a moment.

Cheers, Dirk

| 
| Cheers,
| Moritz

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#899419: NameError: name 'Async' is not defined

[James Valleroy]

Package: udiskie
Version: 1.7.4-1
Severity: important

Dear Maintainer,

   * What led up to the situation?

I installed udiskie (including recommends) in a VM running Debian
unstable. Note there is no desktop environment installed.

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

I tried to run udiskie from command line, as normal or root user.

   * What was the outcome of this action?

$ udiskie -v
DEBUG [2018-05-24 01:28:47,151] udiskie.config: Failed to read config file: 
[Errno 2] No such file or directory: '/home/vagrant/.config/udiskie/config.yml'
DEBUG [2018-05-24 01:28:47,155] udiskie.config: Failed to read config file: 
[Errno 2] No such file or directory: '/home/vagrant/.config/udiskie/config.json'
DEBUG [2018-05-24 01:28:47,162] udiskie.udisks2: Daemon version: 2.7.6
DEBUG [2018-05-24 01:28:47,163] udiskie.udisks2: Keyfile support: True
DEBUG [2018-05-24 01:28:47,174] udiskie.config: IgnoreDevice(match={'symlinks': 
'/dev/mapper/docker-*'}, value={'ignore': True}) created
DEBUG [2018-05-24 01:28:47,175] udiskie.config: IgnoreDevice(match={'symlinks': 
'/dev/disk/by-id/dm-name-docker-*'}, value={'ignore': True}) created
DEBUG [2018-05-24 01:28:47,175] udiskie.config: IgnoreDevice(match={'is_loop': 
True, 'loop_file': '/*'}, value={'ignore': False}) created
DEBUG [2018-05-24 01:28:47,176] udiskie.config: IgnoreDevice(match={'is_block': 
False}, value={'ignore': True}) created
DEBUG [2018-05-24 01:28:47,176] udiskie.config: 
IgnoreDevice(match={'is_external': False}, value={'ignore': True}) created
DEBUG [2018-05-24 01:28:47,177] udiskie.config: 
IgnoreDevice(match={'is_ignored': True}, value={'ignore': True}) created
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/udiskie/cli.py", line 307, in 
_start_async_tasks
results = yield self._init()
  File "/usr/lib/python3/dist-packages/udiskie/cli.py", line 495, in _init
tasks.append(Async())
NameError: name 'Async' is not defined

   * What outcome did you expect instead?

udiskie should start without this error.

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

Kernel: Linux 4.16.0-1-amd64 (SMP w/1 CPU core)
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 udiskie depends on:
ii  python33.6.5-3
ii  python3-docopt 0.6.2-1
ii  python3-gi 3.28.2-1
ii  python3-pkg-resources  39.1.0-1
ii  python3-yaml   3.12-1+b1
ii  udisks22.7.6-3

Versions of packages udiskie recommends:
ii  gir1.2-gtk-3.0 3.22.30-1
ii  gir1.2-notify-0.7  0.7.7-3
ii  gobject-introspection  1.56.1-1
ii  notification-daemon3.20.0-3
ii  python3-keyutils   0.5-1

udiskie suggests no packages.

-- no debconf information

Bug#899271: xfce4-terminal hangs in getrandom if crng not ready

[Ben Caradoc-Davies]

Here is a gdb session up to the first call of getrandom (syscall 318) 
with flags=0. This trace is on unstable but buster should be similar. 
gnutls_rnd is called when creating a VteFileStream:



$ gdb xfce4-terminal
GNU gdb (Debian 7.12-6+b2) 7.12.0.20161007-git
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 


This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from xfce4-terminal...Reading symbols from 
/usr/lib/debug/.build-id/91/f47fd1b6872303eef30a57d9e160f67e16720c.debug...done.

done.
(gdb) catch syscall 318
Catchpoint 1 (syscall 318)
(gdb) run
Starting program: /usr/bin/xfce4-terminal
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Catchpoint 1 (call to syscall 318), 0x751e9eb4 in getrandom 
(buffer=buffer@entry=0x7fffdf4f, length=length@entry=1, 
flags=flags@entry=1) at ../sysdeps/unix/sysv/linux/getrandom.c:30

30  ../sysdeps/unix/sysv/linux/getrandom.c: No such file or directory.
(gdb) c
Continuing.

Catchpoint 1 (returned from syscall 318), 0x751e9eb4 in 
getrandom (buffer=buffer@entry=0x7fffdf4f, length=length@entry=1, 
flags=flags@entry=1) at ../sysdeps/unix/sysv/linux/getrandom.c:30

30  in ../sysdeps/unix/sysv/linux/getrandom.c
(gdb) c
Continuing.
[New Thread 0x7fffeb2de700 (LWP 4151)]
[New Thread 0x7fffeaadd700 (LWP 4152)]
[New Thread 0x7fffe9e3a700 (LWP 4153)]

Thread 1 "xfce4-terminal" hit Catchpoint 1 (call to syscall 318), 
0x751e9ee9 in getrandom (buffer=buffer@entry=0x7fffcf00, 
length=length@entry=32, flags=flags@entry=0) at 
../sysdeps/unix/sysv/linux/getrandom.c:30

30  in ../sysdeps/unix/sysv/linux/getrandom.c
(gdb) bt
#0  0x751e9ee9 in getrandom (buffer=buffer@entry=0x7fffcf00, 
length=length@entry=32, flags=flags@entry=0) at 
../sysdeps/unix/sysv/linux/getrandom.c:30
#1  0x7425b7bd in force_getrandom (flags=0, buflen=out>, buf=0x7fffcf00) at sysrng-linux.c:84
#2  0x7425b7bd in _rnd_get_system_entropy_getrandom 
(_rnd=, size=) at sysrng-linux.c:102
#3  0x74258235 in do_device_source (init=init@entry=1, 
event=event@entry=0x7fffcf60, ctx=0x744b1900 ) at rnd.c:132
#4  0x742583e3 in wrap_nettle_rnd_init (ctx=) at 
rnd.c:228

#5  0x741a4294 in _gnutls_rnd_init () at random.c:48
#6  0x741a4294 in gnutls_rnd (level=level@entry=GNUTLS_RND_KEY, 
data=data@entry=0x7fffd0b0, len=len@entry=32) at random.c:142
#7  0x7787ab2f in _vte_boa_init(VteBoa*) (boa=0x55ab8620 
[VteBoa]) at ../../src/vtestream-file.h:832
#8  0x75ce26a5 in g_type_create_instance (type=) 
at ../../../../gobject/gtype.c:1866
#9  0x75cc35a8 in g_object_new_internal 
(class=class@entry=0x55adfc80, params=params@entry=0x0, 
n_params=n_params@entry=0) at ../../../../gobject/gobject.c:1799
#10 0x75cc4d45 in g_object_new_with_properties 
(object_type=93824998046352, n_properties=0, names=names@entry=0x0, 
values=values@entry=0x0) at ../../../../gobject/gobject.c:1967
#11 0x75cc57c1 in g_object_new (object_type=, 
first_property_name=first_property_name@entry=0x0) at 
../../../../gobject/gobject.c:1639
#12 0x7787a915 in _vte_file_stream_init(VteFileStream*) 
(stream=0x55ac0320 [VteFileStream]) at ../../src/vtestream-file.h:1069
#13 0x75ce26a5 in g_type_create_instance (type=) 
at ../../../../gobject/gtype.c:1866
#14 0x75cc35a8 in g_object_new_internal 
(class=class@entry=0x55adae50, params=params@entry=0x0, 
n_params=n_params@entry=0) at ../../../../gobject/gobject.c:1799
#15 0x75cc4d45 in g_object_new_with_properties 
(object_type=93824998078336, n_properties=0, names=names@entry=0x0, 
values=values@entry=0x0) at ../../../../gobject/gobject.c:1967
#16 0x75cc57c1 in g_object_new (object_type=, 
first_property_name=first_property_name@entry=0x0) at 
../../../../gobject/gobject.c:1639
#17 0x7787cbbe in _vte_file_stream_new() () at 
../../src/vtestream-file.h:1063
#18 0x77849f75 in _vte_ring_init(VteRing*, gulong, gboolean) 
(ring=ring@entry=0x55ae2e50, max_rows=max_rows@entry=512, 
has_streams=has_streams@entry=1) at ../../src/ring.cc:71
#19 0x77861e1a in 
VteTerminalPrivate::VteTerminalPrivate(_VteTerminal*) 
(this=0x55ae2d70, t=) at ../../src/vte.cc:8074
#20 0x77868757 in vte_terminal_init(VteTerminal*) 

Bug#899418: make install with DESTDIR option results in broken symlink

[zigifex]

Package: lvm2
Version: 2.02.168-2

I downloaded the package source files by running "apt-get source lvm2"
Then I ran "./configure && make && make install DESTDIR=$HOME/tempfolder"
The resulting libdevmapper.so is symbolically linked to /lib/libdevmapper.so 
instead of ../../lib/libdevmapper.so

This is unexpected. Since GNU coding standards strongly recommend that packages 
support DESTDIR, I hope this will be fixed soon.

The fix seems to be to reverse the patch made to USRLIB_RELPATH in make.tmpl.in

In the upstream source, its
USRLIB_RELPATH = $(shell echo $(abspath $(usrlibdir) $(libdir)) | 
 $(AWK) -f $(top_srcdir)/scripts/relpath.awk)

In the Debian source, its
USRLIB_RELPATH = @libdir@/

I can see that this change is present since v2.02.95-8 (Wheezy) and I am not 
sure why it was made. It might be necessary to also patch older versions and 
not just v2.02.168-2.

I am using Debian Stretch with all packages updated as of today.

Bug#899417: FTBFS on sid

[Zebulon McCorkle]

On Wed, May 23, 2018 at 07:07:59PM -0500, Zebulon McCorkle wrote:
> Package: node-source-map
> Version: 0.7.0+dfsg.really.0.6.1-1

So... this was supposed to be on node-debug and I guess I autopilot'd that
header. I've sent a message to control to move it there, but it's taking its
sweet time (or I cast my incantation wrong? Dunno. I said thanks!). Sorry,
node-source-map maintainer(s)! No issues with your package!

-- 
Zebulon McCorkle
Email: zebmccor...@zeb.fun
IRC:
 - zebmccorkle@Freenode
 - zebmccorkle@OFTC
 - zeb@EsperNet
 - zeb@hackint
 - zeb@PdgnCo
 - zeb@EFNet
PGP: 803A 0F47 82AD DDEA 46BE  055F F8F9 DB8C 1A54 6398
 (Zebulon McCorkle )


signature.asc
Description: PGP signature

Bug#899417: FTBFS on sid

[Zebulon McCorkle]

Package: node-source-map
Version: 0.7.0+dfsg.really.0.6.1-1

The following error occurs when built from source on sid:

uglifyjs -o dist/debug.min.js --source-map=dist/debug.min.js.map 
dist/debug.js
undefined:9483
var generator = new MOZ_SourceMap.SourceMapGenerator({
  ^

TypeError: Cannot read property 'SourceMapGenerator' of undefined
at Object.SourceMap (eval at  
(/usr/lib/nodejs/uglify-js/tools/node.js:33:1), :9483:39)
at done (/usr/lib/nodejs/uglify-js/bin/uglifyjs:398:77)
at cb (/usr/lib/nodejs/uglify-js/bin/uglifyjs:324:39)
at /usr/lib/nodejs/uglify-js/bin/uglifyjs:391:9
at FSReqWrap.readFileAfterClose [as oncomplete] (fs.js:511:3)
make[1]: *** [debian/rules:13: override_dh_auto_build] Error 1


This seems like a regression due to node-uglify's upgrade to version 2.8,
though I'm not sure why CI isn't showing a FTBFS in buster. A solution appears
to be to add node-source-map to the build dependencies, however in my opinion
it should be added as a dependency on node-uglify.

I've attached a git patch which would fix the issue on this package, though I'm
not sure as applying it here is the best idea. Any thoughts from anyone else?

-- 
Zebulon McCorkle
Email: zebmccor...@zeb.fun
IRC:
 - zebmccorkle@Freenode
 - zebmccorkle@OFTC
 - zeb@EsperNet
 - zeb@hackint
 - zeb@PdgnCo
 - zeb@EFNet
PGP: 803A 0F47 82AD DDEA 46BE  055F F8F9 DB8C 1A54 6398
 (Zebulon McCorkle )
From 2e5ce5897cdc6ac9982fb4388584e59727b9b87b Mon Sep 17 00:00:00 2001
From: Zebulon McCorkle 
Date: Wed, 23 May 2018 19:04:47 -0500
Subject: [PATCH] Fix FTBFS in sid

This adds node-source-map to the build dependencies to fix a regression with
node-uglify.
---
 debian/control | 1 +
 1 file changed, 1 insertion(+)

diff --git a/debian/control b/debian/control
index 04e520e..792ca22 100644
--- a/debian/control
+++ b/debian/control
@@ -16,6 +16,7 @@ Build-Depends: debhelper (>= 9)
  , node-sinon
  , node-sinon-chai
  , node-uglify
+ , node-source-map
  , nodejs
 Standards-Version: 4.1.1
 Homepage: https://github.com/visionmedia/debug
-- 
2.17.0



signature.asc
Description: PGP signature

Bug#899416: x11-common: several problems starting X server on fresh stretch netinstall

[Ernesto Alfonso]

Package: x11-common
Version: 1:7.7+19
Severity: important

Dear Maintainer,

I faced several problems when trying to start the x-server via either xinit or 
startx

1. first, clients could not connect to the x-server. when I tried starting via
service  x11-common start or via systemctl, I got "service has been masked".
   to work around this, I had to reinstall the server after deleting the 
   /lib/systemd/system/x11-common.service symlink pointing to /dev/null
   as suggested by the answer to question 804946 in askubuntu.com
2. Then, I was getting permission errors with /dev/tty0 and /dev/tty2.
   I worked around this with sudo chown $(whoami) /dev/tty[0-9], 
   but suspect a user shouldn't have to do this
3. Now, I am getting the error: xf86EnableIOPorts: failed to set IOPL for I/O 
(Operation not permitted). I've googled this error and there doesn't seem to be 
a consistent workaround to this problem

Additional notes: 
 - xinit, startx do work as root
 - I am running debian stretch 9.4 on VirtualBox

Questions:
- How do I resolve the current situation with problem #3?
- Why am I facing so many problems on a fresh debian netinstall?
- Is it possible to make the "xf86EnableIOPorts: failed to set IOPL for I/O 
(Operation 
  not permitted)" error message more meaningful?


 

-- 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/1 CPU core)
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 x11-common depends on:
ii  lsb-base  9.20161125

x11-common recommends no packages.

x11-common suggests no packages.

-- no debconf information

Bug#899176: mkdocs-bootstrap: Please update to version 0.2.0 that is compatible with mkdocs 0.17

[Brian May]

Dmitry Shachnev  writes:

> The fixed version won’t reach testing *first* because I have added
> Breaks: mkdocs-bootswatch (<< 0.5) to it.

What is the reason for this? Does mkdocs still try to use
mkdocs-bootswatch if it is availabe?
-- 
Brian May 

Bug#899413: texlive-latex-extra: beamerthemeAachen.sty is missing package tangocolors

[Norbert Preining]

> \RequirePackage{tangocolors}
> 
> but tangocolors.sty is nowhere to be found...

Nor is it on CTAN, so we (upstream TeX Live) cannot package it.

You might try to ask the author to upload it to CTAN, here is a link
to one of the files with an email of the author.

When it is on CTAN, it will enter into TeX Live, and via that finds it
way into Debian ;-)

http://legacydirs.umiacs.umd.edu/~jiarong/poster/icml12-inferning/styles/tangocolors.sty

Norbert

--
PREINING Norbert   http://www.preining.info
Accelia Inc. +JAIST +TeX Live +Debian Developer
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Bug#899415: zzzeeksphinx: Cherry-picked upstream patches required for zzzeeksphinx to work with sphinx >= 1.7.0

[Corey Bryant]

Package: zzzeeksphinx
Version: 1.0.20-1
Severity: important
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu cosmic ubuntu-patch

Dear Maintainer,

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

  * d/p/sphinx-has-deprecated-Directive.patch,
d/p/use-regular-python-tokenize.patch,
d/p/remove-find-the-docstring.patch,
d/p/more-updates-for-sphinx.patch: Cherry-picked patches from upstream
to handled code removed from sphinx as of 1.7.0.


Thanks for considering the patch.


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

Kernel: Linux 4.15.0-20-generic (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru zzzeeksphinx-1.0.20/debian/patches/more-updates-for-sphinx.patch 
zzzeeksphinx-1.0.20/debian/patches/more-updates-for-sphinx.patch
--- zzzeeksphinx-1.0.20/debian/patches/more-updates-for-sphinx.patch
1969-12-31 16:00:00.0 -0800
+++ zzzeeksphinx-1.0.20/debian/patches/more-updates-for-sphinx.patch
2018-05-23 10:36:34.0 -0700
@@ -0,0 +1,45 @@
+From d7a89f115fdb3ab1431161a446d636eaad3185c7 Mon Sep 17 00:00:00 2001
+From: Mike Bayer 
+Date: Fri, 16 Feb 2018 13:33:55 -0500
+Subject: [PATCH] - more updates for sphinx
+
+---
+ zzzeeksphinx/viewsource.py | 9 +
+ 1 file changed, 5 insertions(+), 4 deletions(-)
+
+diff --git a/zzzeeksphinx/viewsource.py b/zzzeeksphinx/viewsource.py
+index 7ee590b..8b20c43 100644
+--- a/zzzeeksphinx/viewsource.py
 b/zzzeeksphinx/viewsource.py
+@@ -100,7 +100,7 @@ def _view_source_node(env, text, state):
+ code = analyzer.code
+ 
+ if state is not None:
+-docstring = _find_mod_docstring(analyzer)
++docstring = _find_mod_docstring(pathname)
+ if docstring:
+ # get rid of "foo.py" at the top
+ docstring = re.sub(r"^[a-zA-Z_0-9]+\.py", "", docstring)
+@@ -155,15 +155,16 @@ def _view_source_node(env, text, state):
+ return return_node
+ 
+ 
+-def _find_mod_docstring(analyzer):
++def _find_mod_docstring(pathname):
+ """attempt to locate the module-level docstring.
+ 
+ Note that sphinx autodoc just uses ``__doc__``.  But we don't want
+ to import the module, so we need to parse for it.
+ 
+ """
+-analyzer.tokenize()
+-for type_, parsed_line, start_pos, end_pos, raw_line in analyzer.tokens:
++fhandle = open(pathname, 'rb')
++for type_, parsed_line, start_pos, end_pos, raw_line in \
++token.tokenize(fhandle.readline):
+ if type_ == token.COMMENT:
+ continue
+ elif type_ == token.STRING:
+-- 
+2.17.0
+
diff -Nru zzzeeksphinx-1.0.20/debian/patches/remove-find-the-docstring.patch 
zzzeeksphinx-1.0.20/debian/patches/remove-find-the-docstring.patch
--- zzzeeksphinx-1.0.20/debian/patches/remove-find-the-docstring.patch  
1969-12-31 16:00:00.0 -0800
+++ zzzeeksphinx-1.0.20/debian/patches/remove-find-the-docstring.patch  
2018-05-23 10:36:34.0 -0700
@@ -0,0 +1,113 @@
+From 0e2d505df24d4478030592d59c2abe07ccfc03cf Mon Sep 17 00:00:00 2001
+From: Mike Bayer 
+Date: Fri, 16 Feb 2018 16:40:33 -0500
+Subject: [PATCH] - remove the "find the docstring" aspect of this code that
+ doesn't seem to be doing anything and is breaking on old Pythons, new
+ sphinxes, too much.
+
+---
+ zzzeeksphinx/viewsource.py | 67 +++---
+ 1 file changed, 11 insertions(+), 56 deletions(-)
+
+diff --git a/zzzeeksphinx/viewsource.py b/zzzeeksphinx/viewsource.py
+index 8b20c43..9fc6e2c 100644
+--- a/zzzeeksphinx/viewsource.py
 b/zzzeeksphinx/viewsource.py
+@@ -5,9 +5,7 @@ import imp
+ import re
+ from docutils.parsers.rst import Directive
+ import os
+-from docutils.statemachine import StringList
+ from sphinx.environment import NoUri
+-import tokenize as token
+ import warnings
+ from . import util
+ 
+@@ -99,20 +97,6 @@ def _view_source_node(env, text, state):
+ else:
+ code = analyzer.code
+ 
+-if state is not None:
+-docstring = _find_mod_docstring(pathname)
+-if docstring:
+-# get rid of "foo.py" at the top
+-docstring = re.sub(r"^[a-zA-Z_0-9]+\.py", "", docstring)
+-
+-# strip
+-docstring = docstring.strip()
+-
+-# yank only first paragraph
+-docstring = docstring.split("\n\n")[0].strip()
+-else:
+-docstring = None
+-
+ pagename = '_modules/' + modname.replace('.', '/')
+ try:
+ refuri = urito(env.docname, pagename)
+@@ -127,52 +111,23 @@ def _view_source_node(env, text, state):
+ entry = code, analyzer.tags, {}
+ env._viewcode_modules[modname] = 

Bug#898379: pitivi: no longer responds as soon as I try to import an Ogg Vorbis audio file

[Francesco Poli]

On Sat, 19 May 2018 06:03:35 +0200 Alexandru Băluț wrote:

> A stacktrace would be useful.

OK, after adding the line

  deb http://debug.mirrors.debian.org/debian-debug/ testing-debug main

to my /etc/apt/sources.list, and after installing the following debug
symbol packages:

  # aptitude install pitivi-dbgsym \
 libglib2.0-0-dbgsym \
 libgstreamer1.0-0-dbg \
 gstreamer1.0-plugins-base-dbg \
 gstreamer1.0-plugins-good-dbg \
 gstreamer1.0-plugins-bad-dbg

I started pitivi inside gdb:

  $ gdb python3 -ex "run $(which pitivi)"

And I followed the steps described in my original bug report.

After seeing pitivi frozen, I hit [Ctrl+Z]:

  Thread 1 "pitivi" received signal SIGTSTP, Stopped (user).
  syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
  38  ../sysdeps/unix/sysv/linux/x86_64/syscall.S: No such file or 
directory.

Then I issued the following gdb command:

  (gdb) thread apply all bt
  Thread 33 (Thread 0x7fffac1ea700 (LWP 3020)):
  #0  0x77bcaa04 in __libc_read (fd=47, buf=0x7fffac1e9d40, nbytes=4)
  at ../sysdeps/unix/sysv/linux/read.c:27
  #1  0x7fffac8b39be in ?? () from /usr/lib/x86_64-linux-gnu/libjack.so.0
  #2  0x7fffac8b6fc1 in ?? () from /usr/lib/x86_64-linux-gnu/libjack.so.0
  #3  0x7fffac8b2756 in ?? () from /usr/lib/x86_64-linux-gnu/libjack.so.0
  #4  0x77bc15aa in start_thread (arg=0x7fffac1ea700)
  at pthread_create.c:463
  #5  0x76d0ccbf in clone ()
  at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
  
  Thread 31 (Thread 0x7fff8a7fc700 (LWP 3018)):
  #0  syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
  #1  0x75904e0f in g_cond_wait (cond=cond@entry=0x7fffb0048ad0, 
  mutex=mutex@entry=0x7fffb0048a88) at ../../../../glib/gthread-posix.c:1402
  #2  0x7fffee93b15b in gst_task_func (task=0x7fffb0048a70) at gsttask.c:317
  #3  0x758e77d0 in g_thread_pool_thread_proxy (data=)
  at ../../../../glib/gthreadpool.c:307
  #4  0x758e6e05 in g_thread_proxy (data=0x26678f0)
  at ../../../../glib/gthread.c:784
  #5  0x77bc15aa in start_thread (arg=0x7fff8a7fc700)
  at pthread_create.c:463
  #6  0x76d0ccbf in clone ()
  at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
  
  Thread 30 (Thread 0x7fff8affd700 (LWP 3017)):
  #0  syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
  #1  0x75904e0f in g_cond_wait (cond=cond@entry=0x269dac0, 
  mutex=mutex@entry=0x269da98) at ../../../../glib/gthread-posix.c:1402
  #2  0x7fffed9902b3 in gst_data_queue_push (queue=0x269daf0, 
  item=item@entry=0x7fff7c01e0f0) at gstdataqueue.c:521
  #3  0x7fffe9f4c398 in gst_multi_queue_chain (pad=, 
  parent=, buffer=) at gstmultiqueue.c:2152
  #4  0x7fffee9065fb in gst_pad_chain_data_unchecked (data=0x7fff70008930, 
  type=4112, pad=0x269a630) at gstpad.c:4320
  #5  gst_pad_push_data (pad=pad@entry=0x7fff7c008450, type=type@entry=4112, 
  data=data@entry=0x7fff70008930) at gstpad.c:4576
  #6  0x7fffee90e933 in gst_pad_push (pad=pad@entry=0x7fff7c008450, 
  buffer=buffer@entry=0x7fff70008930) at gstpad.c:4695
  #7  0x7fff98759ece in gst_ogg_demux_chain_peer (
  pad=pad@entry=0x7fff7c008450, packet=packet@entry=0x7fff8affca70, 
  push_headers=0) at gstoggdemux.c:833
  #8  0x7fff9875ced9 in gst_ogg_pad_submit_packet (packet=0x7fff8affca70, 
  pad=0x7fff7c008450) at gstoggdemux.c:1258
  #9  gst_ogg_pad_stream_out (pad=pad@entry=0x7fff7c008450, 
  npackets=npackets@entry=0) at gstoggdemux.c:1306
  #10 0x7fff9875e268 in gst_ogg_pad_submit_page (pad=0x7fff7c008450, 
  page=page@entry=0x7fff8affcd30) at gstoggdemux.c:2055
  #11 0x7fff987624c1 in gst_ogg_demux_handle_page (
  ogg=ogg@entry=0x7fff84032e20, page=page@entry=0x7fff8affcd30, 
  discont=discont@entry=0) at gstoggdemux.c:4578
  #12 0x7fff98762d6d in gst_ogg_demux_chain (pad=, 
  parent=parent@entry=0x7fff84032e20, buffer=)
  at gstoggdemux.c:4657
  #13 0x7fff987637bc in gst_ogg_demux_loop_forward (ogg=0x7fff84032e20)
  at gstoggdemux.c:4744
  #14 gst_ogg_demux_loop (pad=) at gstoggdemux.c:4868
  #15 0x7fffee93af79 in gst_task_func (task=0x7fff7000a050) at gsttask.c:332
  #16 0x758e77d0 in g_thread_pool_thread_proxy (data=)
  at ../../../../glib/gthreadpool.c:307
  #17 0x758e6e05 in g_thread_proxy (data=0x7fff78003720)
  at ../../../../glib/gthread.c:784
  #18 0x77bc15aa in start_thread (arg=0x7fff8affd700)
  at pthread_create.c:463
  #19 0x76d0ccbf in clone ()
  at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
  
  Thread 29 (Thread 0x7fff8b7fe700 (LWP 3016)):
  #0  syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
  #1  0x75904e0f in g_cond_wait (cond=cond@entry=0x7fff780523b0, 
  mutex=mutex@entry=0x7fff78052360) at 

Bug#899414: ITP: qb64 -- Quick Basic Programming Language

[Emmanuel Bourg]

Package: wnpp
Severity: wishlist
Owner: Emmanuel Bourg 

* Package name: qb64
  Version : 1.2
  Upstream Author : Galleon Dragon 
* URL : https://www.qb64.net
* License : LGPL-2.1
  Programming Lang: Basic, C++
  Description : Quick Basic Programming Language

QB64 is a modern version of the Basic programming language that allows
programs created using Quick Basic 4.5 or Qbasic to run on modern operating
systems. It works on 32 or 64 bit machines and has many new features such
as stereo sound, improved graphics and TCP/IP internet capabilities.

Bug#899176: mkdocs-bootstrap: Please update to version 0.2.0 that is compatible with mkdocs 0.17

[Dmitry Shachnev]

On Thu, May 24, 2018 at 07:36:49AM +1000, Brian May wrote:
> I note the python-mkdocs package in sid still build-depends on both
> these packages. So probably should wait until a fixed package reaches
> testing first.

I am (still) working on it. I hope I will upload the new version tomorrow.

The fixed version won’t reach testing *first* because I have added
Breaks: mkdocs-bootswatch (<< 0.5) to it.

Not sure how to resolve this best: maybe I should drop the Breaks temporarily
and add it in the next upload?

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#899413: texlive-latex-extra: beamerthemeAachen.sty is missing package tangocolors

[Tobias Gruetzmacher]

Package: texlive-latex-extra
Version: 2018.20180505-1
Severity: normal

The latex-beamer style "Aachen" isn't usable, since it does

\RequirePackage{tangocolors}

but tangocolors.sty is nowhere to be found...

Regards, Tobias


##
 List of ls-R files

-rw-rw-r-- 1 root staff 80 Jun 29  2012 /usr/local/share/texmf/ls-R
-rw-r--r-- 1 root root 1424 May 20 14:37 /var/lib/texmf/ls-R
lrwxrwxrwx 1 root root 29 Aug 17  2017 /usr/share/texmf/ls-R -> 
/var/lib/texmf/ls-R-TEXMFMAIN
lrwxrwxrwx 1 root root 31 May  5 08:52 /usr/share/texlive/texmf-dist/ls-R -> 
/var/lib/texmf/ls-R-TEXLIVEDIST
lrwxrwxrwx 1 root root 31 May  5 08:52 /usr/share/texlive/texmf-dist/ls-R -> 
/var/lib/texmf/ls-R-TEXLIVEDIST
##
 Config files
-rw-r--r-- 1 root root 475 Aug 19  2017 /etc/texmf/web2c/texmf.cnf
lrwxrwxrwx 1 root root 33 May  5 08:52 /usr/share/texmf/web2c/fmtutil.cnf -> 
/var/lib/texmf/fmtutil.cnf-DEBIAN
lrwxrwxrwx 1 root root 32 May  5 08:52 /usr/share/texmf/web2c/updmap.cfg -> 
/var/lib/texmf/updmap.cfg-DEBIAN
-rw-r--r-- 1 root root 2982 May 17 22:30 
/var/lib/texmf/tex/generic/config/language.dat
##
 Files in /etc/texmf/web2c/
total 8
-rw-r--r-- 1 root root 283 Apr 23  2012 mktex.cnf
-rw-r--r-- 1 root root 475 Aug 19  2017 texmf.cnf
##
 md5sums of texmf.d
ca40c66f144b4bafc3e59a2dd32ecb9c  /etc/texmf/texmf.d/00debian.cnf

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

Kernel: Linux 4.16.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (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 texlive-latex-extra depends on:
ii  preview-latex-style11.91-1
ii  python 2.7.15~rc1-1
ii  tex-common 6.09
ii  texlive-base   2018.20180505-1
ii  texlive-binaries   2018.20180416.47457-3+b1
ii  texlive-latex-recommended  2018.20180505-1
ii  texlive-pictures   2018.20180505-1

Versions of packages texlive-latex-extra recommends:
ii  texlive-fonts-recommended  2018.20180505-1
ii  texlive-plain-generic  2018.20180505-1

Versions of packages texlive-latex-extra suggests:
pn  icc-profiles
ii  libfile-which-perl  1.21-1
pn  libspreadsheet-parseexcel-perl  
ii  python-pygments 2.2.0+dfsg-1
pn  texlive-latex-extra-doc 

Versions of packages tex-common depends on:
ii  dpkg  1.19.0.5+b1
ii  ucf   3.0038

Versions of packages tex-common suggests:
ii  debhelper  11.3

Versions of packages texlive-latex-extra is related to:
ii  tex-common6.09
ii  texlive-binaries  2018.20180416.47457-3+b1

-- debconf information:
  tex-common/check_texmf_missing:
  tex-common/check_texmf_wrong:

Bug#736126: Please install haveged on physical machines

[Ben Hutchings]

On Wed, 2018-05-23 at 22:35 +0200, Nicolas Braud-Santoni wrote:
> Control: severity -1 wishlist
> Control: retitle -1 Please install haveged on physical machines
> COntrol: tag -1 + moreinfo
> 
> Hi,
> 
> On Mon, Jan 20, 2014 at 05:37:32PM +0100, Sven Hartge wrote:
> > On 20.01.2014 10:22, Jérémy Bobbio wrote:
> > > Jeffrey Walton:
> > > > It would probably be very beneficial to install an entropy gatherer by
> > > > default.
> > > 
> > > I am unconvinced that haveged is the answer here, but reassigning to the
> > > proper package.
> 
> Retitling and reducing severity.
> 
> 
> Do we have a reasonablish way of telling whether a system is “real”
> hardware or a virtual machine, and choose whether to install haveged or not
> accordingly?

systemd seems to have a reliable way of doing that (systemd-detect-virt 
command).

> Is it a thing we want to do?

I don't have an opinion either way.

Ben.

-- 
Ben Hutchings
It is easier to change the specification to fit the program
than vice versa.



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

Bug#899318: virtualbox: FTBFS: vboxssdt-standard.hex:16:23: error: expected initializer before '-' token

[Mattia Dongili]

On Wed, May 23, 2018 at 02:56:55PM +0200, Gianfranco Costamagna wrote:
> control: reassign -1 src:acpica-unix
> control: found -1 20180508-1
> control: affects -1 virtualbox
> 
> On Tue, 22 May 2018 19:12:32 +0200 Emilio Pozuelo Monfort  
> wrote:
> > Package: virtualbox
> > Version: 5.2.12-dfsg-1
> > Severity: serious
> > 
> > virtualbox fails to build on a clean sid chroot here:
> > 
> > In file included from 
> > /build/virtualbox-5.2.12-dfsg/src/VBox/Devices/PC/ACPI/VBoxAcpi.cpp:45:0:
> > /build/virtualbox-5.2.12-dfsg/out/obj/VBoxDD/vboxssdt-standard.hex:16:23: 
> > error: expected initializer before '-' token
> >  unsigned char vboxssdt-standard_aml_code[] =
> >^
> > /build/virtualbox-5.2.12-dfsg/src/VBox/Devices/PC/ACPI/VBoxAcpi.cpp: In 
> > function 'int acpiPrepareDsdt(PPDMDEVINS, void**, size_t*)':
> > /build/virtualbox-5.2.12-dfsg/src/VBox/Devices/PC/ACPI/VBoxAcpi.cpp:371:32: 
> > error: 'AmlCode' was not declared in this scope
> >  cbAmlCodeDsdt = sizeof(AmlCode);
> > ^~~
> > /build/virtualbox-5.2.12-dfsg/src/VBox/Devices/PC/ACPI/VBoxAcpi.cpp: In 
> > function 'int acpiPrepareSsdt(PPDMDEVINS, void**, size_t*)':
> > /build/virtualbox-5.2.12-dfsg/src/VBox/Devices/PC/ACPI/VBoxAcpi.cpp:423:30: 
> > error: 'AmlCodeSsdtCpuHotPlug' was not declared in this scope
> >  pabAmlCode = AmlCodeSsdtCpuHotPlug;
> >   ^
> > /build/virtualbox-5.2.12-dfsg/src/VBox/Devices/PC/ACPI/VBoxAcpi.cpp:428:30: 
> > error: 'AmlCodeSsdtStandard' was not declared in this scope
> >  pabAmlCode = AmlCodeSsdtStandard;
> >   ^~~
> > kmk: *** [/usr/share/kBuild/footer-pass2-compiling-targets.kmk:226: 
> > /build/virtualbox-5.2.12-dfsg/out/obj/VBoxDD/PC/ACPI/VBoxAcpi.o] Error 1

For the record, the DSL files are here:
https://salsa.debian.org/pkg-virtualbox-team/virtualbox/tree/master/src/VBox/Devices/PC

and are compiled and post-processed as:
https://salsa.debian.org/pkg-virtualbox-team/virtualbox/blob/master/src/VBox/Devices/Makefile.kmk#L829-857

-- 
mattia
:wq!

Bug#899411: backup2l: tar complains about order of positional arguments after upgrade to tar 1.30+dfsg-2

[Markus Treinen]

Package: backup2l
Version: 1.6-2
Severity: minor

Dear maintainer,

after upgrading tar to 1.30+dfsg-2 it complains about positional
parameters being incorrectly set when used by backup2l:


Creating archive using 'DRIVER_TAR_GZ'...
  tar: The following options were used after any non-optional arguments
  in archive create or update mode.  These options are positional and
  affect only arguments that follow them.  Please, rearrange them
  properly.
  tar: --no-recursion has no effect
  tar: Exiting with failure status due to previous errors


The archives seem to be created correctly, so there should be no
regression in functionality.

tar is being invoked as
  tar czf $3 -T $4 --no-recursion 2>&1

To fix the warning, the --no-recursion parameter should be placed in
front of -T
  tar czf $3 --no-recursion -T $4 2>&1

This affects the drivers DRIVER_TAR, DRIVER_TAR_GZ and DRIVER_TAR_BZ2,
including some other options.

Cheers,
Markus


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

Kernel: Linux 4.4.110 (SMP w/1 CPU core)
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)

backup2l depends on no packages.

Versions of packages backup2l recommends:
ii  bzip2  1.0.6-8.1

Versions of packages backup2l suggests:
ii  xz-utils  5.2.2-1.3

-- Configuration Files:
/etc/backup2l.conf changed:
FOR_VERSION=1.6
VOLNAME="guybrush"
SRCLIST=(
/boot
/etc
/root
/home
/srv
/opt
/var
/usr/local
)
SKIPCOND=(
-path "*.nobackup*"
-o -type s
-o -path "/var/cache" -prune
-o -path "/var/lock" -prune
-o -path "/var/run" -prune
-o -path "/var/tmp" -prune
-o -path "/var/lib/mysql" -prune
)
BACKUP_DEV="/mount/backup"
BACKUP_DIR="/mount/backup/guybrush/files"
MAX_LEVEL=3
MAX_PER_LEVEL=5
MAX_FULL=2
GENERATIONS=2
CREATE_CHECK_FILE=1
PRE_BACKUP ()
{
#echo "  pre-backup: nothing to do"
# e. g., shut down some mail/db servers if their files are to be backup'ed
# On a Debian system, the following statements dump a machine-readable list 
of
# all installed packages to a file.
#echo "  writing dpkg selections to /root/dpkg-selections.log..."
#dpkg --get-selections | diff - /root/dpkg-selections.log > /dev/null || 
dpkg --get-selections > /root/dpkg-selections.log
echo "  writing dpkg selections to /root/dpkg-selections.log..."
dpkg --get-selections | diff - /root/.dpkg-selections.log > /dev/null || 
dpkg --get-selections > /root/dpkg-selections.log
}
POST_BACKUP ()
{
# e. g., restart some mail/db server if its files are to be backup'ed
#echo "  post-backup: nothing to do"
# automysqlbackup
echo "  backing up MySQL Databases..."
/usr/sbin/automysqlbackup | sed 's/^//'
# Backup MySQL
# Purge old MySQL backups
}
AUTORUN=0
SIZE_UNITS="M"   # set to "B", "K", "M" or "G" to obtain unified units in 
summary list
TIME_ZONE="UTC" # if unset (= ""), the local time zone is used for backup meta 
data;
# For new archives, the value "UTC" is recommended. However, 
older versions (<= 1.5) used local time,
# and changing the value causes backup2l to consider ALL files 
as new. So, change this value with care!
DRIVER_MY_AFIOZ ()
{
case $1 in
-test)
# This function should check whether all prerequisites are met, 
especially if all
# required tools are installed. This prevents backup2l to fail in 
inconvenient
# situations, e. g. during a backup or restore operation. If 
everything is ok, the
# string "ok" should be returned. Everything else is interpreted as 
a failure.
require_tools afio
# The function 'require_tools' checks for the existence of all 
tools passed as
# arguments. If one of the tools is not found by which(1), an 
error message is
# displayed and the function does not return.
echo "ok"
;;
-suffix)
# This function should return the suffix of backup archive files. 
If the driver
# does not create a file (e. g. transfers the backup data 
immediately to a tape
# or network device), an empty string has to be returned. backup2l 
uses this suffix
# to select a driver for unpacking. If a user-configured driver 
supports the same
# suffix as a built-in driver, the user driver is preferred (as in 
this case).
echo "afioz"
;;
-create)# Arguments: $2 = BID, $3 = archive file name, $4 = 
file list file
# This function is called to create a backup file. The argument $3 
is the full file
# name of the archive 

Bug#899176: mkdocs-bootstrap: Please update to version 0.2.0 that is compatible with mkdocs 0.17

[Brian May]

Dmitry Shachnev  writes:

> Yes, this is no longer the case since mkdocs 0.16.0:
> https://github.com/mkdocs/mkdocs/commit/cc1c9a3adbcd8dde
>
> mkdocs-bootstrap is also no longer required, but it is used by two other
> packages in Debian so we have to keep it.
>
> Can you please file a removal bug yourself? As only you can file a RoM bug.

Will do so.

I note the python-mkdocs package in sid still build-depends on both
these packages. So probably should wait until a fixed package reaches
testing first.
-- 
Brian May 

Bug#852646: task-xfce-desktop: please recommend atril not evince

[Nicolas Braud-Santoni]

Control: clone -1
Control: reassign -1 atril
Control: retitle -1 Remove the dep of atril on mate-desktop-common

Hi,

Is the dependency of atril on mate-desktop-common necessary?

If not, could you please consider removing it?  This would let
the xfce maintainers ship atril instead of evince in task-xfce-desktop  :)


Best,

  nicoo

On Fri, Jan 27, 2017 at 11:44:02PM +0100, Yves-Alexis Perez wrote:
> On Fri, 2017-01-27 at 23:42 +0100, Yves-Alexis Perez wrote:
> > On Thu, 2017-01-26 at 05:41 +0100, Christian PERRIER wrote:
> > > As usual: what's the stance of Xfce packages maintainers about this?
> > 
> > I'm not completely against that, we already went back and forth with evince,
> > evince-gtk etc. for a long time. But while I do know and use evince, I don't
> > know atril yet. I can surely try it, but I won't make a decision soon.
> 
> Also, atril seems to bring mate-desktop-common package, which is not yet
> present in Xfce installations. I don't really like that (and yes, I don't
> really like having too much gnome packages either)

Bug#899350: [Pkg-utopia-maintainers] Bug#899350: network-manager-gnome: drops wireless connection sometimes, messes up connection display

[Michael Biebl]

Am 23.05.2018 um 22:44 schrieb Thomas Korimort:
> I would have also suspected, that it is this way, but network-manager
> took over at some point.

Can you provide log messages which would confirm that?


-- 
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#899382: qt5-qmake: cross wrapper should supply PKG_CONFIG_EXECUTABLE

[Dmitry Shachnev]

Hi Helmut!

On Wed, May 23, 2018 at 08:23:53PM +0200, Helmut Grohne wrote:
> Thiago Macieira suggested an alternative approach to solving this.
> Rather than telling qmake to use the "right" pkg-config at runtime, we
> can tell it at build time.
>
> To that end we should build qtbase with a triplet-prefixed pkg-config.
>
> That actually works fairly well as the Debian packaging of pkg-config
> ensures that -pkg-config is a symlink to pkg-config. So
> just using the triplet-prefixed pkg-config always works (native and
> cross). Where should we reassign this bug to?
>
> I think Thiago's approach is strictly better than mine, because it
> ensures that qmake will always use the right pkg-config even without
> passing PKG_CONFIG or PKG_CONFIG_EXECUTABLE to qmake. That should be
> useful to people cross building with qmake without our cross wrapper.

I wonder how this approach will work.

Our triplet-prefixed qmake is a wrapper that calls the native qmake with
some arguments. If we configure qmake with prefixed pkg-config path, then
the native qmake will call pkg-config corresponding to *its* (native)
architecture, not the architecture we are building for.

What am I missing here?

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#899410: procps: Upgrade to procps 2:3.3.9-9+deb8u1 fails on Jessie in linux-vserver VMs.

[Linux O'Beardly]

Package: procps
Version: 2:3.3.9-9+deb8u1
Severity: important

-- System Information:
Distributor ID: Debian
Description:Debian GNU/Linux
Codename:   jessie
Architecture: x86_64

Kernel: Linux 3.18.91-vs2.3.7.5-custom (SMP w/24 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages procps depends on:
ii  initscripts   2.88dsf-59.2+devuan2
ii  libc6 2.19-18+deb8u10

ii  libncurses5   5.9+20140913-1+deb8u2
ii  libncursesw5  5.9+20140913-1+deb8u2
ii  libprocps32:3.3.9-9+deb8u1
ii  libtinfo5 5.9+20140913-1+deb8u2
ii  lsb-base  4.1+devuan2

Versions of packages procps recommends:
ii  psmisc  22.21-2

procps suggests no packages.

-- no debconf information


When upgrading procps version 2:3.3.9-9 to 2:3.3.9-9+deb8u1 on Jessie via
apt, I incurred the following:

Setting up procps (2:3.3.9-9+deb8u1) ...
insserv: Service mountkernfs has to be enabled to start service procps
insserv: exiting now!
update-rc.d: error: insserv rejected the script header
dpkg: error processing package procps (--configure):
 subprocess installed post-installation script returned error exit status 1
Errors were encountered while processing:
 procps
E: Sub-process /usr/bin/dpkg returned an error code (1)


This can be remedied by doing the following:

 update-rc.d mountkernfs.sh defaults && apt-get -f install

This only occurs on my linux-vserver VMs. It may be an issue with the
custom vserver kernel I'm running.  However, to determine root cause may be
beyond my skill set. If it is not due to my customer vserver kernel, it
will most likely occur on other paravirtualized VMs and containers.

Thank you,

-- 
Linux O'Beardly
@LinuxOBeardly
http://o.beard.ly
linux.obear...@gmail.com

Bug#899376: gnome-terminal: Ctrl-Shift-Enter/Ctrl-Enter in MC isn't working on Wayland

[Egmont Koblinger]

Hi,

Terminal emulators don't send anything special on Ctrl-(Shift-)Enter, they
can only send the same newline they do on Enter.

MC has a hack called X11 support: Whenever it receives a newline from the
terminal emulator, it queries the X server whether any modifier is pressed
at that time. That's how Ctrl-(Shift-)Enter can have different actions.

Give it a try under X11: do an "unset DISPLAY" and then start up "mc",
these keys won't work specially anymore because mc can no longer find the X
server.

xterm still runs via the X compatibility layer called XWayland, that's why
this hack still works there. GNOME Terminal, on the other hand, is a native
Wayland app (if run under Wayland), there's no X server involved to connect
to and query.

I'm almost certain that Wayland's security model doesn't allow the same
hack; but even if it does, it's not (yet) implemented in mc.

Alt-Enter should still do the same as Ctrl-Enter used to do with the X11
hack, since in that case the terminal emulator sends a different sequence.
I think the best you can do now is get used to Alt-Enter.

I don't know off the top of my head how to bind some keypress to
Ctrl-Shift-Enter's action, and wherever it's possible at all; you should
consult mc's documentation. I guess mc should add some alternate keybinding
by default.

mc's manual mentions at C-Enter and C-Shift-Enter that "[m]ay not work on
remote systems and some terminals"

cheers,
egmont

Bug#758988: hdparm: Also present in buster

[Alex Mestiashvili]

On 05/18/2018 10:07 PM, Rainer Dorsch wrote:
> Package: hdparm
> Version: 9.56+ds-1
> Followup-For: Bug #758988
> 
> Dear Maintainer,
> 
> I see that behavior also in buster.
> 
> What I understand is that 
> 
> /usr/lib/pm-utils/power.d/95hdparm-apm resume
> 
> gets called during resume.
> 
> To make it work for me, I had to comment these two if conditions
> 
> #   if [ -b $dev ] && hdparm_try_apm $dev ; then  
>   
>
> # Check for APM support; discard errors since not all 
>   
>
> # drives support HDIO_GET_IDENTITY (-i).  
>   
>
> #   if hdparm -i $dev 2> /dev/null | grep -q 
> 'AdvancedPM=yes'  
> 
> #   then   
> 
> in resume_hdparm_spindown().
> 
> For reference the output of 
> 
> root@b370:~# hdparm -i /dev/sdb
> 
> /dev/sdb:
> 
>  Model=SAMSUNG HD501LJ, FwRev=CR100-12, SerialNo=S0MUJ1FPB79563
>  Config={ Fixed }
>  RawCHS=16383/16/63, TrkSize=34902, SectSize=554, ECCbytes=4
>  BuffType=DualPortCache, BuffSize=16384kB, MaxMultSect=16, MultSect=off
>  CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=976773168
>  IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
>  PIO modes:  pio0 pio1 pio2 pio3 pio4 
>  DMA modes:  mdma0 mdma1 mdma2 
>  UDMA modes: udma0 udma1 udma2 udma3 udma4 udma5 *udma6 
>  AdvancedPM=no WriteCache=enabled
>  Drive conforms to: unknown:  ATA/ATAPI-3,4,5,6,7
> 
>  * signifies the current active mode


Thanks for reporting.

The only solution I currently see is to add an option to hdparm.conf to
allow forcibly set spindown time regardless APM support.
/usr/lib/pm-utils/power.d/95hdparm-apm need to be modified to check for
this option in resume_hdparm_spindown().

Bug#899409: epiphany-browser: CVE-2018-11396

[Salvatore Bonaccorso]

Source: epiphany-browser
Version: 3.28.1-1
Severity: normal
Tags: security upstream
Forwarded: https://bugzilla.gnome.org/show_bug.cgi?id=795740

Hi,

The following vulnerability was published for epiphany-browser.

CVE-2018-11396[0]:
| ephy-session.c in libephymain.so in GNOME Web (aka Epiphany) through
| 3.28.2.1 allows remote attackers to cause a denial of service
| (application crash) via JavaScript code that triggers access to a NULL
| URL, as demonstrated by a crafted window.open call.

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2018-11396
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-11396
[1] https://bugzilla.gnome.org/show_bug.cgi?id=795740

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#849578: task-xfce-desktop: Why you use the vlc player in the task-xfce-desktop meta package?

[Nicolas Braud-Santoni]

Control: tag -1 + pending

On Mon, Feb 26, 2018 at 08:37:19AM +, Christian PERRIER wrote:
>
> Once again, I have strictly no advice about this. Formerly in the bug
> report, Yves-Alexis didn't really object but argued about VLC being
> kind of the reference player which "everybody" expects. On the ther
> hand he gave no advice *against* having Parole specifically in the
> Xfce task.
> 
> Finally, as we were late in the release process, the change didn't
> seem a good thing to do at that momentbut now is maybe a better
> moment.
> 
> Xfce developers in Debian (if some are left), do you have objections ?

As there were no objection, I will apply the change  :)

Bug#736126: Please install haveged on physical machines

[Nicolas Braud-Santoni]

Control: severity -1 wishlist
Control: retitle -1 Please install haveged on physical machines
COntrol: tag -1 + moreinfo

Hi,

On Mon, Jan 20, 2014 at 05:37:32PM +0100, Sven Hartge wrote:
> On 20.01.2014 10:22, Jérémy Bobbio wrote:
> > Jeffrey Walton:
> >> It would probably be very beneficial to install an entropy gatherer by
> >> default.
> > 
> > I am unconvinced that haveged is the answer here, but reassigning to the
> > proper package.

Retitling and reducing severity.


Do we have a reasonablish way of telling whether a system is “real”
hardware or a virtual machine, and choose whether to install haveged or not
accordingly?

Is it a thing we want to do?


Best,

  nicoo

Bug#899408: coffeescript: This package is deprecated and moved to coffeescript (no hyphen)

[Bastien Roucariès]

Package: coffeescript
Version: 1.12.7~dfsg-3
Severity: important

Hi

Upstream decided to break thing and create a new package
https://github.com/jashkenas/coffeescript

removing the hyphen in the lib path.

it could be possible to be backward compatible by creating a symlink and some
provide some compatibility on debian side.



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

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

Versions of packages coffeescript depends on:
ii  nodejs  8.11.1~dfsg-2

coffeescript recommends no packages.

Versions of packages coffeescript suggests:
pn  coffeescript-doc
ii  libjs-coffeescript  1.12.7~dfsg-3

-- debconf-show failed

Bug#899406: requests.Session doesn't properly handle closed keep-alive sessions

[Jonathan Lynch]

Package: python-requests
Version: 2.18.4

When a server reaps a keep-alive session it sends a FIN packet to the
client. Normally, requests handles this fine and rebuilds the session on
the next request. However, there is an edge case involving network latency
that is not properly handled:

If python sends a request at roughly the same time as the server closes the
session, then the server will send a RST (as the session is closed). Python
receives this RST on what it thought was a valid session and throws an
error:

requests.exceptions.ConnectionError: ('Connection aborted.',
RemoteDisconnected('Remote end closed connection without response',))

The reason I consider this a bug is because python received the FIN packet
before it received the RST. As a result, it shouldn't be surprised when the
connection is subsequently aborted. It is an edge case, but the client has
enough information available to it that it could have handled it correctly.

The workaround is to set max_retries on the Session via an HTTPAdaptor, but
I believe the correct behavior when the FIN is received is to rebuild the
session and re-send any requests that were in-flight (rather than throwing
an error). Requests correctly handles the FIN packet if there are no
in-flight requests, but if there are in-flight requests it ignores it and
instead throws an error.

Bug#899407: ITP: lief -- Library to Instrument Executable Formats

[Hilko Bengen]

Package: wnpp
Owner: Hilko Bengen 
Severity: wishlist

* Package name: lief
  Version : 0.8.3
  Upstream Author : Romain Thomas
* URL or Web page : https://lief-project.github.io/
* License : Apache
  Description : Library to Instrument Executable Formats
   LIEF is a library for parsing, modifying ELF, PE, and MachO formats.

Bug#898040: [Pkg-roundcube-maintainers] Bug#898040: roundcube-core installation configuration fails in lighttpd+sqlite3 scenario

[Stephan Gerth]

Hi,

> A workaround is to disable autoconfiguration of the HTTP daemon, for
> instance via debconf and/or adding DEBIAN_PRIORITY=low to the
> environment of the `apt-get install` command.

The workaround succeeded for me:

 * DEBIAN_PRIORITY=low apt-get install dbconfig-sqlite3 roundcube-core
roundcube-sqlite3 (did not select any https server to be configured when
being asked for)
 * ln -s /etc/roundcube/lighttpd.conf
/etc/lighttpd/conf-available/50-roundcube.conf
 * lighty-enable-mod roundcube fastcgi fastcgi-php

Best,
Stephan

Bug#899379: [Pkg-freeipa-devel] Bug#899379: Bug#899379: Bug#899379: bind9-dyndb-ldap: schema with errors

[Timo Aaltonen]

On 23.05.2018 20:32, paulo bruck wrote:
> Hy Tim]
> 
> Sorry, my bad. I'm not usualy to report bugs...80)
> 
> Do you think tha is  better to use backport of this  package?
> 
> diff atachead

Now it makes more sense. But I think you should file it upstream instead
to see what they think:

https://pagure.io/bind-dyndb-ldap/issues

you probably need an account there first

-- 
t

Bug#899261: Acknowledgement (ITP: qasm-simulator-cpp -- C++ quantum circuit simulator with realistic noise)

[Enrique de la Torre]

qasm-simulator-cpp is part of a bigger upstream called qiskit, an ITP should be 
bound to the latter not the former. I am closing this bug and renaming bug 
880994 for qiskit.

On 21 May, 2018, at 09:27 PM, Debian Bug Tracking System 
 wrote:

Thank you for filing a new Bug report with Debian.

You can follow progress on this Bug here: 899261: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=899261.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
w...@debian.org

If you wish to submit further information on this problem, please
send it to 899...@bugs.debian.org.

Please do not send mail to ow...@bugs.debian.org unless you wish
to report a problem with the Bug-tracking system.

--
899261: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=899261
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#879619: Autopkgtest for ncbi-tools6

[Liubov Chuprikova]

On Wed, 23 May 2018 at 20:36 Aaron M. Ucko  wrote:

> Liubov Chuprikova  writes:
>
> > Please, have a look at my two last commits (
> > https://salsa.debian.org/med-team/ncbi-tools6/commits/master). Actually,
> > the first one was made a month ago.
>
> All looks good except for one formality -- Lintian considers your
> additions to debian/copyright to be incomplete:
>
> W: ncbi-tools6 source: missing-field-in-dep5-copyright license (paragraph
> at line 16)
> W: ncbi-tools6 source: missing-field-in-dep5-copyright copyright
> (paragraph at line 16)
> W: ncbi-tools6 source: missing-field-in-dep5-copyright license (paragraph
> at line 24)
> W: ncbi-tools6 source: missing-field-in-dep5-copyright copyright
> (paragraph at line 24)
> W: ncbi-tools6 source: missing-field-in-dep5-copyright license (paragraph
> at line 30)
> W: ncbi-tools6 source: missing-field-in-dep5-copyright copyright
> (paragraph at line 30)
> W: ncbi-tools6 source: missing-field-in-dep5-copyright license (paragraph
> at line 35)
> W: ncbi-tools6 source: missing-field-in-dep5-copyright copyright
> (paragraph at line 35)
>
> (It also issues a few unrelated complaints, which I'll be happy to
> address myself.)
>

I cannot reproduce the same lintian output on my computer. I tried it like
this:
lintian -i -I --show-overrides
ncbi-tools6_6.1.20170106-3_amd64.changes
I mistakenly decided that if NCBI copyright had already mentioned I could
skip it
for test data files as they were also taken from NCBI, except one...
trnascan-se_sample.output
I generated that file by running *trnascan-se* (another Debian Med
package), so I have no
idea what the license and copyright should be written for it. Could you
help me with this
problem?

__
Liubov

Bug#899403: pymodbus: Please provide a python3 package

[W. Martin Borgert]

On 2018-05-23 22:02, Cedric Boudinet wrote:
> The latest version (1.5.2) is compatible with python3.
> Is it possible to upgrade and create a python3-pymodbus package?

Done: https://packages.debian.org/unstable/python3-pymodbus :~)

Bug#899405: tracker: Default documentation is not user-oriented

[Guillem Jover]

Package: tracker.debian.org
Severity: normal

Hi!

The tracker provides links to its documentation (at [T]), but that
looks rather developer oriented. If you want to get some user
documentation it seems that currently the main source is the
developer-reference (!? at [D]). I think either the information in
the second should be merged into the former, or the links changed to
point to the latter which would be more useful than information on
how to hack on or setup the tracker, TBH.

Thanks,
Guillem

[T] 
[D] 

Bug#897436: owncloud-client: diff for NMU version 2.4.1+dfsg-1.1

[Pierre-Elliott Bécue]

Le 23 mai 2018 20:58:01 GMT+02:00, "Sandro Knauß"  a écrit :
>Hey,
>
>> I've prepared an NMU for owncloud-client (versioned as
>2.4.1+dfsg-1.1) and
>> intend to have it uploaded to the archive as soon as you give me your
>> agreement, except if you wish to upload it yourself.
>> 
>> Should you not answer in the next ten days I'll upload the patch
>right away.
>
>Thanks for the patch - looks fine. Is this fix upstream already? Are
>they 
>aware of this patch? Please document the git hash if it comes from
>upstream. 
>Just go on uploading the NMU (and update the git repo). No need to
>DELAY the 
>package. Anyways owncloud-client is packaged as team. Feel free to
>join.
>
>sandro

Yes, it's a patch from upstream.

I'll do a MR on the repo on salsa and at the same time have one of my sponsors 
review and upload my changes according to this specific nmudiff plus the asked 
githash. 

Should I find some time to contribute on a regular basis to owncloud related 
sohtware packaging, I'd be glad to join the team !

Cheers, 
-- 
PEB

Bug#899352: Problematic commit reverted for stretch-backports

[W. Martin Borgert]

I uploaded a new backport 0.10.1-1~bpo9+2 with the problematic
commit reverted. HTH.

Bug#899404: Fix ORC on platforms without indirection support

[Christoph Berg]

Source: llvm-toolchain-6.0
Version: 1:6.0-3
Severity: normal

PostgreSQL 11 is optionally using llvm to jit query execution at
runtime. This works fine on amd64 and i386, but fails on all other
platforms.

https://buildd.debian.org/status/logs.php?pkg=postgresql-11=11~beta1-1=experimental

2018-05-22 22:23:21.218 UTC [23734] pg_regress/strings STATEMENT:  SELECT 
chr(0);
terminate called after throwing an instance of 'std::bad_function_call'
  what():  bad_function_call
2018-05-22 22:23:21.325 UTC [23614] LOG:  server process (PID 23738) was 
terminated by signal 6: Aborted
2018-05-22 22:23:21.325 UTC [23614] DETAIL:  Failed process was running: INSERT 
INTO TEMP_GROUP
  SELECT 1, (- i.f1), (- f.f1)
  FROM INT4_TBL i, FLOAT8_TBL f;
2018-05-22 22:23:21.325 UTC [23614] LOG:  terminating any other active server 
processes

The fix for this is r328687 in llvm upstream:
http://llvm.org/viewvc/llvm-project?view=revision=328687
(Andres is also the author of the llvm support in PostgreSQL)

https://www.postgresql.org/message-id/20180522151101.drsbh6p7ltxpm...@alap3.anarazel.de

It would be nice if the llvm package in Debian unstable would be
updated with this fix. I'm not totally sure about the status of the
6.0.1 release, but I think it doesn't have the patch yet.

Thanks,
Christoph

Bug#899403: pymodbus: Please provide a python3 package

[Cedric Boudinet]

Source: pymodbus
Severity: wishlist

Dear Maintainer,

The latest version (1.5.2) is compatible with python3.
Is it possible to upgrade and create a python3-pymodbus package?

Regards

Cedric



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

Kernel: Linux 4.9.0-6-686-pae (SMP w/2 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)

Bug#899386: Needs some documentation....

[Paul Gevers]

Hi Neil

On 23-05-18 21:45, Neil Williams wrote:
> tag 899386 - moreinfo
> severity 899386 minor
> thanks
> 
> Ah, ok, now I understand how the @ is relevant to this issue.
> 
> I've now got the tests passing. Would it be possible to add something
> to the manpage or the README files please? 
paul@testavoira ~ $ zcat
/usr/share/doc/autopkgtest/README.package-tests.rst.gz | grep -e
"^Depends: " -A25
Depends: dpkg dependency field syntax
Declares that the specified packages must be installed for the test
to go ahead. This supports all features of dpkg dependencies (see
https://www.debian.org/doc/debian-policy/ch-relationships.html),
plus the following extensions:

``@`` stands for the package(s) generated by the source package
containing the tests; each dependency (strictly, or-clause, which
may contain ``|``\ s but not commas) containing ``@`` is replicated
once for each such binary package, with the binary package name
substituted for each ``@`` (but normally ``@`` should occur only
once and without a version restriction).

``@builddeps@`` will be replaced by the package's
``Build-Depends:``, ``Build-Depends-Indep:``, and
``build-essential``. This is useful if you have many build
dependencies which are only necessary for running the test suite and
you don't want to replicate them in the test ``Depends:``. However,
please use this sparingly, as this can easily lead to missing binary
package dependencies being overlooked if they get pulled in via
build dependencies.

If no Depends field is present, ``Depends: @`` is assumed. Note that
the source tree's Build-Dependencies are *not* necessarily
installed, and if you specify any Depends, no binary packages from
the source are installed unless explicitly requested.

Anything missing from there?

Paul



signature.asc
Description: OpenPGP digital signature

Bug#899402: python-influxdb: Version 5.0.0 available

[Cedric Boudinet]

Package: python-influxdb
Severity: wishlist

Dear Maintainer,

Version 5.0.0 of python-influxdb has been released. Is it possible to integrate
it into the next Debian release?

Bests

Cedric



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

Kernel: Linux 4.9.0-6-686-pae (SMP w/2 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)

Bug#899386: Needs some documentation....

[Neil Williams]

tag 899386 - moreinfo
severity 899386 minor
thanks

Ah, ok, now I understand how the @ is relevant to this issue.

I've now got the tests passing. Would it be possible to add something
to the manpage or the README files please? 

Thanks.

-- 

Neil Williams
h...@codehelp.co.uk



pgpfLAVaEy7Hg.pgp
Description: OpenPGP digital signature

Bug#887542: [request-tracker-maintainers] Bug#887542: libemail-address-list-perl depends on libemail-address-perl

[gregor herrmann]

On Wed, 23 May 2018 19:38:22 +0100, Dominic Hargreaves wrote:

> On Wed, May 23, 2018 at 06:57:23PM +0200, gregor herrmann wrote:
> > On Sun, 20 May 2018 12:41:57 +0200, Pali Rohár wrote:
> > > Perl module Email::Address::List is probably not possible to fix. But
> > > perl module Email::Address::XS already provides methods for parsing
> > > list/groups of email addresses -- functionality which is provided by
> > > Email::Address::List. Therefore applications which depends on
> > > Email::Address::List can be rewritten to use Email::Address::XS.
> > 
> > libemail-address-list-perl has one reverse dependency:
> > request-tracker4.
> > 
> The bug about that is here:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=887551

That's about libemail-address-perl directly; I just checked the
possibility to remove libemail-address-list-perl (because of its
dependency on libemail-address-perl); but yeah, in the end it boils
down to the same topic.
 
> It looks like a lot of other rdep must have gone away since I wrote
> the last update on that mail. Then again, as long as it is marked
> deprecated, perhaps the cost of keeping it in Debian until that bug
> is fixed is not that high?

Ack, I'm in no specific hurry, just going through Pali's bug reports
and looking at the situation.


Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: Tony Joe White: Selena


signature.asc
Description: Digital Signature

Bug#899401: ITP: r-cran-metamix -- GNU R bayesian mixture analysis for metagenomic community profiling

[Dylan Aïssi]

Package: wnpp
Severity: wishlist
Owner: Debian R Packages Maintainers 

Package name: r-cran-metamix
URL: https://cran.r-project.org/package=metaMix
License: GPL-3
Description: GNU R bayesian mixture analysis for metagenomic community profiling
 Resolves complex metagenomic mixtures by analysing deep sequencing
 data, using a mixture model based approach. The use of parallel Monte
 Carlo Markov chains for the exploration of the species space enables
 the identification of the set of species more likely to contribute to
 the mixture.

This package will be maintained by the Debian R Packages Maintainers at:
https://salsa.debian.org/r-pkg-team/r-cran-metamix

Bug#899400: ITP: bolt-lmm -- Efficient large cohorts genome-wide Bayesian mixed-model association testing

[Dylan Aïssi]

Package: wnpp
Severity: wishlist
Owner: Debian Med Packaging Team 

Package name: bolt-lmm
URL: https://data.broadinstitute.org/alkesgroup/BOLT-LMM/
License: GPL-3+
Description: Efficient large cohorts genome-wide Bayesian mixed-model
association testing
 The BOLT-LMM software package currently consists of two main algorithms, the
 BOLT-LMM algorithm for mixed model association testing, and the BOLT-REML
 algorithm for variance components analysis (i.e., partitioning of
 SNP-heritability and estimation of genetic correlations).

This package will be maintained by the Debian Med Packaging Team at:
https://salsa.debian.org/med-team/bolt-lmm

Bug#899213: compiz: sistematically places new windows below existing ones

[Giacomo Boffi]

Dear Alex,
I've checked and my settings are exactly
- Placement Mode: Smart
- Multi Output Mode: Use active output device

To have a trace of the window placement, I have started my system with
the following ~/.xsession file

#!/bin/bash
xset m 5 3
# fbsetroot -gradient vertical -fg red4 -bg orangered3
xterm & sleep 0.2
xmodmap .compose
compiz &
# cairo-dock -w 3 -o > /dev/null 2>&1 &
exec my_sleep 365d

and, from the xterm that was started from .xsession I started a number
of xterminals of different background color, then I made a screen dump
of the current situation --- please find in attachment a compressed
version of the screen dump.

As you can see, the problem is (mostly?) the pre-existing window,
i.e., the original xterm that covers part of some of the new windows
(e.g., the black one is completely under the 1st xterm)

Thank you for your intervention ፨ g

On Wed, May 23, 2018 at 10:33 AM, Alex ARNAUD  wrote:
> Hello boffi,
>
> Thank you for helping us to make Compiz better.
>
> I'm using Debian Stretch with the latest Compiz version and my configuration
> of the place window module is as follow:
> - Placement Mode: Smart
> - Multi Output Mode: Use active output device
>
> On my system, the first one is opened on the top-left and the second-one on
> the bottom-left.
>
> Could you try with this configuration and restart your computer after that?
>
> Could you please tell me what applications are you trying to launch ? Maybe
> the behavior could be different between software.
>
> Best regards,
> Alex.
>
>
> Le 21/05/2018 à 00:30, boffi a écrit :
>>
>> Package: compiz-plugins
>> Version: 1:0.9.13.1+18.04.20180302-1
>> Severity: normal
>>
>> Dear Maintainer,
>>
>> * What led up to the situation?
>>
>> I activated the "Place Windows" plugin
>>
>> * What exactly did you do (or not do) that was effective (or
>>   ineffective)?
>>
>> n/a
>>
>> * What was the outcome of this action?
>>
>> irrispective of the algorithm chosen, the plugin insists on placing
>> new
>> windows BELOW existing windows (not always but most of the times)
>>
>> * What outcome did you expect instead?
>>
>> every WM I used (and that comprised compiz+place_windows, until
>> recently)
>> placed new windows above existing windows, because when a user
>> instantiates a new window, either using a shortcut and the "Commands"
>> plugin, a desktop launcher or a system menu, said user 99.3% wants to
>> use the new window immediately
>>
>> That said, I'm trying to use compiz standalone (no DE) with the support of
>> a dock/panel (either tint2 or cairo-dock).
>>
>> I'd like to help fixing this problem giving you any further additional
>> info.
>>
>> Thank you in advance, gb
>> -- System Information:
>> Debian Release: buster/sid
>>APT prefers unstable
>>APT policy: (500, 'unstable'), (500, 'stable')
>> Architecture: amd64 (x86_64)
>>
>> Kernel: Linux 4.16.0-1-amd64 (SMP w/4 CPU cores)
>> Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8
>> (charmap=UTF-8)
>> Shell: /bin/sh linked to /bin/dash
>> Init: systemd (via /run/systemd/system)
>> LSM: AppArmor: enabled
>>
>> Versions of packages compiz-plugins depends on:
>> ii  compiz-core   1:0.9.13.1+18.04.20180302-1
>> ii  compiz-plugins-default1:0.9.13.1+18.04.20180302-1
>> ii  libc6 2.27-3
>> ii  libcairo2 1.15.10-3
>> ii  libdbus-1-3   1.12.8-2
>> ii  libdecoration01:0.9.13.1+18.04.20180302-1
>> ii  libfribidi0   0.19.7-2
>> ii  libgcc1   1:8.1.0-3
>> ii  libgdk-pixbuf2.0-02.36.11-2
>> ii  libgl11.0.0+git20180308-2
>> ii  libglib2.0-0  2.56.1-2
>> ii  libglibmm-2.4-1v5 2.56.0-2
>> ii  libglu1-mesa [libglu1]9.0.0-2.1
>> ii  libice6   2:1.0.9-2
>> ii  libjpeg62-turbo   1:1.5.2-2+b1
>> ii  libnotify40.7.7-3
>> ii  libpango-1.0-01.42.1-1
>> ii  libpangocairo-1.0-0   1.42.1-1
>> ii  librsvg2-22.40.20-2
>> ii  libsigc++-2.0-0v5 2.10.0-2
>> ii  libsm62:1.2.2-1+b3
>> ii  libstartup-notification0  0.12-5
>> ii  libstdc++68.1.0-3
>> ii  libx11-6  2:1.6.5-1
>> ii  libx11-xcb1   2:1.6.5-1
>> ii  libxcb1   1.13-1
>> ii  libxcomposite11:0.4.4-2
>> ii  libxcursor1   1:1.1.15-1
>> ii  libxdamage1   1:1.1.4-3
>> ii  libxext6  2:1.3.3-1+b2
>> ii  libxfixes31:5.0.3-1
>> ii  libxi62:1.7.9-1
>> ii  libxinerama1  2:1.1.3-1+b3
>> ii  libxml2   2.9.4+dfsg1-6.1+b1
>> ii  libxrandr22:1.5.1-1
>> ii  libxrender1   1:0.9.10-1
>> ii  libxslt1.11.1.29-5
>>
>> compiz-plugins recommends no packages.
>>
>> compiz-plugins suggests no packages.
>>
>> -- no 

Bug#899380: libreoffice-common: AppArmor profile prohibits encrypting documents with GPG

[Rene Engelhard]

On Wed, May 23, 2018 at 01:50:08PM -0400, John Scott wrote:
> That happened to me too because I didn't use a trusted
> key the first time. When I encrypted to my own public
> key, then it froze.

Confirmed (Took the wrong key in LOs list, the list is not intuitive
enough.)

It looks like this is about .gnupg/random_seed. While it hangs it
constantly complains about this in kern.log:

May 23 21:04:07 frodo kernel: [277802.848361] audit: type=1400
audit(1527102247.170:1551): apparmor="DENIED" operation="file_lock"
profile="libreoffice-soffice//gpg" name="/home/rene/.gnupg/random_seed"
pid=20251 comm="gpg" requested_mask="k" denied_mask="k" fsuid=1000
ouid=1000

- as you pasted already. So it tries to get the lock and doesn't get it,
tries again, fails, waits, tries again, fails, ...

When I allow k ("locking") for random_seed with

owner @{HOME}/.gnupg/random_seed rk,

it doesn't hang anymore.

Regards,

Rene

Bug#897436: owncloud-client: diff for NMU version 2.4.1+dfsg-1.1

[Sandro Knauß]

Hey,

> I've prepared an NMU for owncloud-client (versioned as 2.4.1+dfsg-1.1) and
> intend to have it uploaded to the archive as soon as you give me your
> agreement, except if you wish to upload it yourself.
> 
> Should you not answer in the next ten days I'll upload the patch right away.

Thanks for the patch - looks fine. Is this fix upstream already? Are they 
aware of this patch? Please document the git hash if it comes from upstream. 
Just go on uploading the NMU (and update the git repo). No need to DELAY the 
package. Anyways owncloud-client is packaged as team. Feel free to join.

sandro



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

Bug#899399: ITP: reparser -- Simple regex-based lexer/parser for inline markup

[Diane Trout]

Package: wnpp
Severity: wishlist
Owner: Diane Trout 

* Package name: reparser
  Version : 1.4.3
  Upstream Author : Michal Krenek 
* URL : https://github.com/xmikos/reparser
* License : MIT
  Programming Lang: Python
  Description : Simple regex-based lexer/parser for inline markup

 This is a library with a Simple regex-based lexer/parser
 for inline markup. The example use shows writing a simple
 markdown parser.

I plan on managing within the Debian python module packaging team.

This is also a depency for hangups

Bug#899398: ITP: readlike -- GNU Readline-like line editing module

[Diane Trout]

Package: wnpp
Severity: wishlist
Owner: Diane Trout 

* Package name: readlike
  Version : 0.1.2
  Upstream Author : Brandon Mulcahy 
* URL : https://github.com/jangler/readlike
* License : MIT
  Programming Lang: Python
  Description : GNU Readline-like line editing module

 A Python module that provides `GNU Readline`_-like line editing functions (the
 default Emacs-style ones). If you just want to use Readline, use the readline_
 package in the standard library--but this package allows access to those
 capabilties in settings outside of a standard CLI.
 .
 Currently, all stateless Readline commands are implemented. This means that
 yanking and history are not supported.
 .
 This module is especially well-suited to interfacing with Urwid_ due to a
 shared syntax for describing key inputs.

I was planning on maintaining through the Debian modules packaging team.

This is a dependency of hangups, a console mode Google hangouts client.
https://github.com/tdryer/hangups

Bug#879619: Autopkgtest for ncbi-tools6

[Aaron M. Ucko]

Liubov Chuprikova  writes:

> Please, have a look at my two last commits (
> https://salsa.debian.org/med-team/ncbi-tools6/commits/master). Actually,
> the first one was made a month ago.

All looks good except for one formality -- Lintian considers your
additions to debian/copyright to be incomplete:

W: ncbi-tools6 source: missing-field-in-dep5-copyright license (paragraph at 
line 16)
W: ncbi-tools6 source: missing-field-in-dep5-copyright copyright (paragraph at 
line 16)
W: ncbi-tools6 source: missing-field-in-dep5-copyright license (paragraph at 
line 24)
W: ncbi-tools6 source: missing-field-in-dep5-copyright copyright (paragraph at 
line 24)
W: ncbi-tools6 source: missing-field-in-dep5-copyright license (paragraph at 
line 30)
W: ncbi-tools6 source: missing-field-in-dep5-copyright copyright (paragraph at 
line 30)
W: ncbi-tools6 source: missing-field-in-dep5-copyright license (paragraph at 
line 35)
W: ncbi-tools6 source: missing-field-in-dep5-copyright copyright (paragraph at 
line 35)

(It also issues a few unrelated complaints, which I'll be happy to
address myself.)

> I tried to run it in a similar way to *asn2asn*. It throws an error which
> starts with "The asn2ff flatfile generator is obsolete and unsupported.  
> Please
> switch to using asn2gb/SeqEntryToGnbk in the future."

Ah, got it.  No test needed here, then.

> Aaron, thank you for the explanations! They helped me a lot!

No problem; thanks for the tests!

> Your work looks very fine grained but for the decision of "completed"
> Aaron is the expert we both need to trust.  Aaron, let me know if you
> want me to upload or if you want to do it yourself.

I'll do it myself, thanks, adding a few other small changes along the way.

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

Bug#887551: [request-tracker-maintainers] Bug#887542: libemail-address-list-perl depends on libemail-address-perl

[Dominic Hargreaves]

On Wed, May 23, 2018 at 06:57:23PM +0200, gregor herrmann wrote:
> On Sun, 20 May 2018 12:41:57 +0200, Pali Rohár wrote:
> 
> > Perl module Email::Address::List is probably not possible to fix. But
> > perl module Email::Address::XS already provides methods for parsing
> > list/groups of email addresses -- functionality which is provided by
> > Email::Address::List. Therefore applications which depends on
> > Email::Address::List can be rewritten to use Email::Address::XS.
> 
> Thanks for this update.
> 
> libemail-address-list-perl has one reverse dependency:
> request-tracker4.
> 
> Cc'ing the maintainers.

The bug about that is here:

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

It looks like a lot of other rdep must have gone away since I wrote
the last update on that mail. Then again, as long as it is marked
deprecated, perhaps the cost of keeping it in Debian until that bug
is fixed is not that high?

Dominic.

Bug#899382: qt5-qmake: cross wrapper should supply PKG_CONFIG_EXECUTABLE

[Helmut Grohne]

On Wed, May 23, 2018 at 05:14:06PM +0200, Helmut Grohne wrote:
> qtmultimedia-opensource-src fails to cross build from source, because it
> fails finding gstreamer and pulseaudio. Looking at its configure.json, I
> see that the ones that are failing are discovered using a "type":
> "pkgConfig" check. This one is implemented in the function
> qtConfLibrary_pkgConfig in
> /usr/lib//qt5/mkspecs/features/qt_configure.prf. It discovers
> the pkg-config to use from the function qtConfPkgConfig in the same
> file. This function does not look at the PKG_CONFIG variable, but
> insists on using the PKG_CONFIG_EXECUTABLE variable. Thus the qmake
> cross wrapper should also supply PKG_CONFIG_EXECUTABLE in addition to
> PKG_CONFIG with the same value.

Thiago Macieira suggested an alternative approach to solving this.
Rather than telling qmake to use the "right" pkg-config at runtime, we
can tell it at build time.

To that end we should build qtbase with a triplet-prefixed pkg-config.

That actually works fairly well as the Debian packaging of pkg-config
ensures that -pkg-config is a symlink to pkg-config. So
just using the triplet-prefixed pkg-config always works (native and
cross). Where should we reassign this bug to?

I think Thiago's approach is strictly better than mine, because it
ensures that qmake will always use the right pkg-config even without
passing PKG_CONFIG or PKG_CONFIG_EXECUTABLE to qmake. That should be
useful to people cross building with qmake without our cross wrapper.

Helmut

Bug#899397: cron-apt: mail subject never indicates error on completion

[Sebastian Klamar]

Package: cron-apt
Version: 0.10.0
Severity: minor

Dear Ola,

/usr/share/cron-apt/functions contains an error (cf. code extract
below): The mail subject never will be "... error on ..." (line 103)
because the error file tested for existance gets deleted beforehand
(line 84ff.).  Thus one cannot trust mails like "completed on..."

I've solved the issue by moving the "if -f ... rm -f ..." clean-up below
the mail command (cf. patch below).

/usr/share/cron-apt/functions:
 84 if [ -f "$ERROR" ] ; then
 85 rm -f "$ERROR"
 86 fi
 87 if [ -f "$RUNSYSLOG" ] ; then
 88 rm -f "$RUNSYSLOG"
 89 fi
 90 if [ -f "$RUNERROR" ] ; then
 91 rm -f "$RUNERROR"
 92 fi
 93 if [ -f "$RUNMAIL" ] ; then
 94 rm -f "$RUNMAIL"
 95 fi
 96 if [ -f "$MAIL" ] && [ "$MAILON" != "never" ] && [ -n "$MAILON" ] ; then
 97 if command -v sendmail >/dev/null; then
 98 HDR="To: $MAILTO"
 99 if [ -z "$HOSTNAME" ]; then
100 HOSTNAME="$(uname -n)"
101 fi
102 if [ -f "$ERROR" ] ; then
103 HDR=$(printf "$HDR\nSubject: CRON-APT error on $HOSTNAME 
[$CONFIG]")
104 else
105 HDR=$(printf "$HDR\nSubject: CRON-APT completed on 
$HOSTNAME [$CONFIG]")
106 fi

--- /tmp/functions  2018-05-23 19:54:05.0 +0200
+++ /usr/share/cron-apt/functions   2018-05-23 19:56:36.875793315
+0200
@@ -81,9 +81,6 @@
 if [ -f "$RUNLOG" ] ; then
rm -f "$RUNLOG"
 fi
-if [ -f "$ERROR" ] ; then
-   rm -f "$ERROR"
-fi
 if [ -f "$RUNSYSLOG" ] ; then
rm -f "$RUNSYSLOG"
 fi
@@ -123,6 +120,9 @@
 if [ -f "$DIFF" ] ; then
rm -f "$DIFF"
 fi
+if [ -f "$ERROR" ] ; then
+   rm -f "$ERROR"
+fi
 if [ -d "$TMPDIR" ] ; then
rmdir "$TMPDIR"
 fi


BTW, one could move all clean-up code ("if -f ... rm -f ...") below the
mail function in order to prevent similar bugs when extending the mail
function with other variables in the future.

Thank you in advance for merging the patch into mainline version -- and
for spending your free time as debian developer.


Best regards -- Sebastian

-- System Information:
Debian Release: 9.4
Architecture: amd64 (x86_64)

Kernel: Linux 4.9.0-6-amd64 (SMP w/1 CPU core)
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 cron-apt depends on:
ii  apt  1.4.8

Versions of packages cron-apt recommends:
ii  cron [cron-daemon] 3.0pl1-128+deb9u1
ii  liblockfile1   1.14-1+b1
ii  nullmailer [mail-transport-agent]  1:1.13-1.2

cron-apt suggests no packages.

-- Configuration Files:
/etc/cron-apt/action.d/0-update [Errno 2] No such file or directory: 
'/etc/cron-apt/action.d/0-update'
/etc/cron-apt/action.d/3-download [Errno 2] No such file or directory: 
'/etc/cron-apt/action.d/3-download'
/etc/cron-apt/config changed [not included]
/etc/cron.d/cron-apt changed [not included]

-- no debconf information

Bug#897659: fix

[Br1z0n]

I found using this command when starting compton fixed everything, without 
having to change any config settings

allow_rgb10_configs=false compton

Might be an easier work around for now..

Bug#899395: mono: FTBFS on various architectures

[Jo Shields]

Probably issues w/ GCC being more strict than last time it was built.
Will investigate when I have time.


On 23/05/18 13:56, Sven Joachim wrote:
> Source: mono
> Version: 4.6.2.7+dfsg-2
> Severity: serious
>
> The new mono version FTBFS on four architectures where it has been built
> before, including two release architectures.
>
> On S390x, the error looks like this[1]:
>
> ,
> |   CC   mono-mmap.lo
> | libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../.. -I../.. -I../../mono
> |  -I../../libgc/include -I../../eglib/src -I../../eglib/src 
> -fvisibility=hidden
> |  -Wdate-time -D_FORTIFY_SOURCE=2 -DGC_LINUX_THREADS -D_GNU_SOURCE 
> -D_REENTRANT
> |  -DUSE_MMAP -DUSE_MUNMAP -g -Wall -Wunused -Wmissing-prototypes
> |  -Wmissing-declarations -Wstrict-prototypes -Wmissing-prototypes 
> -Wnested-externs
> |  -Wpointer-arith -Wno-cast-qual -Wwrite-strings -Wno-switch -Wno-switch-enum
> |  -Wno-unused-value -Wno-attributes -DUSE_COMPILER_TLS -g -O2
> |  -fdebug-prefix-map=/<>/mono-4.6.2.7+dfsg=. 
> -fstack-protector-strong
> |  -Wformat -Werror=format-security -std=gnu99 -fno-strict-aliasing -fwrapv
> |  -DMONO_DLL_EXPORT -Wno-unused-but-set-variable -g -Wall -Wunused
> |  -Wmissing-prototypes -Wmissing-declarations -Wstrict-prototypes
> |  -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wno-cast-qual
> |  -Wwrite-strings -Wno-switch -Wno-switch-enum -Wno-unused-value 
> -Wno-attributes
> |  -mbackchain -D__USE_STRING_INLINES -Werror-implicit-function-declaration 
> -MT
> |  mono-mmap.lo -MD -MP -MF .deps/mono-mmap.Tpo -c mono-mmap.c -fPIC -DPIC -o
> |  .libs/mono-mmap.o
> | In file included from ../../mono/utils/mono-threads.h:14:0,
> |   from mono-mmap.c:37:
> | ../../mono/utils/mono-stack-unwinding.h:96:14: error: field 'ctx' has 
> incomplete type
> |   MonoContext ctx;
> |^~~
> | make[3]: *** [Makefile:841: mono-mmap.lo] Error 1
> `
>
> On ppc64el, ppc64 and powerpc there is a different error[2]:
>
> ,
> |   CC   mono-context.lo
> | libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../.. -I../.. -I../../mono
> | -I../../libgc/include -I../../eglib/src -I../../eglib/src 
> -fvisibility=hidden
> | -Wdate-time -D_FORTIFY_SOURCE=2 -DGC_LINUX_THREADS -D_GNU_SOURCE 
> -D_REENTRANT
> | -DUSE_MMAP -DUSE_MUNMAP -g -Wall -Wunused -Wmissing-prototypes
> | -Wmissing-declarations -Wstrict-prototypes -Wmissing-prototypes 
> -Wnested-externs
> | -Wpointer-arith -Wno-cast-qual -Wwrite-strings -Wno-switch -Wno-switch-enum
> | -Wno-unused-value -Wno-attributes -D__mono_ppc__ -D__mono_ppc64__ -g -O2
> | -fdebug-prefix-map=/<>/mono-4.6.2.7+dfsg=. 
> -fstack-protector-strong
> | -Wformat -Werror=format-security -std=gnu99 -fno-strict-aliasing -fwrapv
> | -DMONO_DLL_EXPORT -Wno-unused-but-set-variable -g -Wall -Wunused
> | -Wmissing-prototypes -Wmissing-declarations -Wstrict-prototypes
> | -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wno-cast-qual
> | -Wwrite-strings -Wno-switch -Wno-switch-enum -Wno-unused-value 
> -Wno-attributes
> | -mminimal-toc -Werror-implicit-function-declaration -MT mono-context.lo -MD 
> -MP
> | -MF .deps/mono-context.Tpo -c mono-context.c -fPIC -DPIC -o 
> .libs/mono-context.o
> | In file included from mono-context.c:9:0:
> | 
> | mono-context.c: In function 'mono_sigctx_to_monoctx':
> | ../../mono/utils/mono-sigcontext.h:267:58: error: dereferencing pointer to 
> incomplete type 'os_ucontext {aka struct ucontext}'
> |   #define UCONTEXT_REG_NIP(ctx) 
> (((os_ucontext*)(ctx))->uc_mcontext.gp_regs [PT_NIP])
> |   ^
> | mono-context.c:407:16: note: in expansion of macro 'UCONTEXT_REG_NIP'
> |   mctx->sc_ir = UCONTEXT_REG_NIP(uc);
> | ^~~~
> | make[3]: *** [Makefile:841: mono-context.lo] Error 1
> `
>
>
> 1. 
> https://buildd.debian.org/status/fetch.php?pkg=mono=s390x=4.6.2.7%2Bdfsg-2=1526962622=0
> 2. 
> https://buildd.debian.org/status/fetch.php?pkg=mono=ppc64el=4.6.2.7%2Bdfsg-2=1526971899=0
>

Bug#899396: ITP: ghmm -- General Hidden Markov Model library

[Steffen Moeller]

Package: wnpp
Severity: wishlist
Owner: Steffen Moeller 

* Package name: ghmm
* URL : http://ghmm.org
* License : GPL
  Programming Lang: C
  Description : General Hidden Markov Model library

The packaging is about to surface on http://salsa.debian.org/med-team/ghmm

Bug#897436: owncloud-client: diff for NMU version 2.4.1+dfsg-1.1

[Pierre-Elliott Bécue]

Dear maintainer,

I've prepared an NMU for owncloud-client (versioned as 2.4.1+dfsg-1.1) and
intend to have it uploaded to the archive as soon as you give me your
agreement, except if you wish to upload it yourself.

Should you not answer in the next ten days I'll upload the patch right away.

Best regards.

-- 
Pierre-Elliott Bécue
GPG: 9AE0 4D98 6400 E3B6 7528  F493 0D44 2664 1949 74E2
It's far easier to fight for one's principles than to live up to them.
diff -Nru owncloud-client-2.4.1+dfsg/debian/changelog owncloud-client-2.4.1+dfsg/debian/changelog
--- owncloud-client-2.4.1+dfsg/debian/changelog	2018-03-29 13:44:36.0 +0200
+++ owncloud-client-2.4.1+dfsg/debian/changelog	2018-05-23 19:46:06.0 +0200
@@ -1,3 +1,14 @@
+owncloud-client (2.4.1+dfsg-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add d/p/0010 to fix the nemo/nautilus shell integration encoding issues.
+(Closes: #897436)
+  * d/control:
+- Drop the X-Python3-Version that is obsolete
+- Bump Standards-Version to 4.1.4. No change required.
+
+ -- Pierre-Elliott Bécue   Wed, 23 May 2018 19:46:06 +0200
+
 owncloud-client (2.4.1+dfsg-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru owncloud-client-2.4.1+dfsg/debian/control owncloud-client-2.4.1+dfsg/debian/control
--- owncloud-client-2.4.1+dfsg/debian/control	2018-03-29 13:35:54.0 +0200
+++ owncloud-client-2.4.1+dfsg/debian/control	2018-05-23 19:31:12.0 +0200
@@ -31,10 +31,9 @@
  texlive-latex-extra,
  texlive-latex-recommended,
  xsltproc
-X-Python3-Version: >= 3.0
 Vcs-Git: https://salsa.debian.org/owncloud-team/owncloud-client.git
 Vcs-Browser: https://salsa.debian.org/owncloud-team/owncloud-client
-Standards-Version: 4.1.3
+Standards-Version: 4.1.4
 Homepage: https://owncloud.org/sync-clients/
 
 Package: owncloud-client
diff -Nru owncloud-client-2.4.1+dfsg/debian/patches/0010-Fix-nautilus-nemo-shell-integration-encoding-issues.patch owncloud-client-2.4.1+dfsg/debian/patches/0010-Fix-nautilus-nemo-shell-integration-encoding-issues.patch
--- owncloud-client-2.4.1+dfsg/debian/patches/0010-Fix-nautilus-nemo-shell-integration-encoding-issues.patch	1970-01-01 01:00:00.0 +0100
+++ owncloud-client-2.4.1+dfsg/debian/patches/0010-Fix-nautilus-nemo-shell-integration-encoding-issues.patch	2018-05-23 19:18:52.0 +0200
@@ -0,0 +1,67 @@
+From: =?utf-8?q?Pierre-Elliott_B=C3=A9cue?= 
+Date: Wed, 23 May 2018 19:18:04 +0200
+Subject: Fix nautilus/nemo shell integration encoding issues
+
+The problem was that plain encode()/decode() in python2 use ascii
+encoding, not utf8.
+---
+ shell_integration/nautilus/syncstate.py | 18 ++
+ 1 file changed, 10 insertions(+), 8 deletions(-)
+
+diff --git a/shell_integration/nautilus/syncstate.py b/shell_integration/nautilus/syncstate.py
+index 77a233d..4429588 100644
+--- a/shell_integration/nautilus/syncstate.py
 b/shell_integration/nautilus/syncstate.py
+@@ -38,8 +38,10 @@ print("Initializing "+appname+"-client-nautilus extension")
+ def get_local_path(url):
+ if url[0:7] == 'file://':
+ url = url[7:]
+-unquote = urllib.parse.unquote if python3 else urllib.unquote
+-return unquote(url)
++if python3:
++return urllib.parse.unquote(url)
++else:
++return urllib.unquote(url).decode('utf-8')
+ 
+ def get_runtime_dir():
+ """Returns the value of $XDG_RUNTIME_DIR, a directory path.
+@@ -61,7 +63,7 @@ class SocketConnect(GObject.GObject):
+ self._watch_id = 0
+ self._sock = None
+ self._listeners = [self._update_registered_paths]
+-self._remainder = ''.encode()
++self._remainder = ''.encode('utf-8')
+ self.nautilusVFSFile_table = {}  # not needed in this object actually but shared 
+  # all over the other objects.
+ 
+@@ -79,7 +81,7 @@ class SocketConnect(GObject.GObject):
+ # print("Server command: " + cmd)
+ if self.connected:
+ try:
+-self._sock.send(cmd.encode())
++self._sock.send(cmd.encode('utf-8'))
+ except:
+ print("Sending failed.")
+ self.reconnect()
+@@ -118,17 +120,17 @@ class SocketConnect(GObject.GObject):
+ # Prepend the remaining data from last call
+ if len(self._remainder) > 0:
+ data = self._remainder + data
+-self._remainder = ''.encode()
++self._remainder = ''.encode('utf-8')
+ 
+ if len(data) > 0:
+ # Remember the remainder for next round
+-lastNL = data.rfind('\n'.encode());
++lastNL = data.rfind('\n'.encode('utf-8'));
+ if lastNL > -1 and lastNL < len(data):
+ self._remainder = data[lastNL+1:]
+ data = data[:lastNL]
+ 
+-for l in data.split('\n'.encode()):
+-   

Bug#899336: PDFPC Regression Bug

[Andreas Bilke]

Please see 
https://github.com/pdfpc/pdfpc/commit/21e4efb3afe325fe7e2f800d1c22fd1bc28bc3d7

(I saw that i referenced the wrong bug report id in the commit message.)


signature.asc
Description: PGP signature

Bug#899394: ncurses-base: Add Breaks on libmono-corlib4.5-cil (<< 4.6.2.7+dfsg-2)

[Sven Joachim]

Control: block 899394 by 899395

On 2018-05-23 19:27 +0200, Sven Joachim wrote:

> Package: ncurses-base
> Version: 6.1+20180210-4
> Severity: normal
>
> It has been noticed in #899112 and #899222 that Mono's
> System.TermInfoReader is incompatible with the new terminfo format.  The
> Debian mono maintainers kindly fixed that in version 4.6.2.7+dfsg-2, and
> so versioned Breaks should be added to ncurses-base and ncurses-term to
> ensure smooth partial upgrades, as has already been done for other
> libraries.
>
> Unfortunately the new mono version FTBFS on four architectures where it
> has been built before.  This needs to be fixed first before the Breaks
> can be added, as making libmono-corlib4.5-cil uninstallable is not
> acceptable.

Marking this FTBFS as a blocker accordingly.

Cheers,
   Sven

Bug#899395: mono: FTBFS on various architectures

[Sven Joachim]

Source: mono
Version: 4.6.2.7+dfsg-2
Severity: serious

The new mono version FTBFS on four architectures where it has been built
before, including two release architectures.

On S390x, the error looks like this[1]:

,
|   CC   mono-mmap.lo
| libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../.. -I../.. -I../../mono
|  -I../../libgc/include -I../../eglib/src -I../../eglib/src -fvisibility=hidden
|  -Wdate-time -D_FORTIFY_SOURCE=2 -DGC_LINUX_THREADS -D_GNU_SOURCE -D_REENTRANT
|  -DUSE_MMAP -DUSE_MUNMAP -g -Wall -Wunused -Wmissing-prototypes
|  -Wmissing-declarations -Wstrict-prototypes -Wmissing-prototypes 
-Wnested-externs
|  -Wpointer-arith -Wno-cast-qual -Wwrite-strings -Wno-switch -Wno-switch-enum
|  -Wno-unused-value -Wno-attributes -DUSE_COMPILER_TLS -g -O2
|  -fdebug-prefix-map=/<>/mono-4.6.2.7+dfsg=. -fstack-protector-strong
|  -Wformat -Werror=format-security -std=gnu99 -fno-strict-aliasing -fwrapv
|  -DMONO_DLL_EXPORT -Wno-unused-but-set-variable -g -Wall -Wunused
|  -Wmissing-prototypes -Wmissing-declarations -Wstrict-prototypes
|  -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wno-cast-qual
|  -Wwrite-strings -Wno-switch -Wno-switch-enum -Wno-unused-value 
-Wno-attributes
|  -mbackchain -D__USE_STRING_INLINES -Werror-implicit-function-declaration -MT
|  mono-mmap.lo -MD -MP -MF .deps/mono-mmap.Tpo -c mono-mmap.c -fPIC -DPIC -o
|  .libs/mono-mmap.o
| In file included from ../../mono/utils/mono-threads.h:14:0,
|   from mono-mmap.c:37:
| ../../mono/utils/mono-stack-unwinding.h:96:14: error: field 'ctx' has 
incomplete type
|   MonoContext ctx;
|^~~
| make[3]: *** [Makefile:841: mono-mmap.lo] Error 1
`

On ppc64el, ppc64 and powerpc there is a different error[2]:

,
|   CC   mono-context.lo
| libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../.. -I../.. -I../../mono
| -I../../libgc/include -I../../eglib/src -I../../eglib/src -fvisibility=hidden
| -Wdate-time -D_FORTIFY_SOURCE=2 -DGC_LINUX_THREADS -D_GNU_SOURCE -D_REENTRANT
| -DUSE_MMAP -DUSE_MUNMAP -g -Wall -Wunused -Wmissing-prototypes
| -Wmissing-declarations -Wstrict-prototypes -Wmissing-prototypes 
-Wnested-externs
| -Wpointer-arith -Wno-cast-qual -Wwrite-strings -Wno-switch -Wno-switch-enum
| -Wno-unused-value -Wno-attributes -D__mono_ppc__ -D__mono_ppc64__ -g -O2
| -fdebug-prefix-map=/<>/mono-4.6.2.7+dfsg=. -fstack-protector-strong
| -Wformat -Werror=format-security -std=gnu99 -fno-strict-aliasing -fwrapv
| -DMONO_DLL_EXPORT -Wno-unused-but-set-variable -g -Wall -Wunused
| -Wmissing-prototypes -Wmissing-declarations -Wstrict-prototypes
| -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wno-cast-qual
| -Wwrite-strings -Wno-switch -Wno-switch-enum -Wno-unused-value -Wno-attributes
| -mminimal-toc -Werror-implicit-function-declaration -MT mono-context.lo -MD 
-MP
| -MF .deps/mono-context.Tpo -c mono-context.c -fPIC -DPIC -o 
.libs/mono-context.o
| In file included from mono-context.c:9:0:
| 
| mono-context.c: In function 'mono_sigctx_to_monoctx':
| ../../mono/utils/mono-sigcontext.h:267:58: error: dereferencing pointer to 
incomplete type 'os_ucontext {aka struct ucontext}'
|   #define UCONTEXT_REG_NIP(ctx) 
(((os_ucontext*)(ctx))->uc_mcontext.gp_regs [PT_NIP])
|   ^
| mono-context.c:407:16: note: in expansion of macro 'UCONTEXT_REG_NIP'
|   mctx->sc_ir = UCONTEXT_REG_NIP(uc);
| ^~~~
| make[3]: *** [Makefile:841: mono-context.lo] Error 1
`


1. 
https://buildd.debian.org/status/fetch.php?pkg=mono=s390x=4.6.2.7%2Bdfsg-2=1526962622=0
2. 
https://buildd.debian.org/status/fetch.php?pkg=mono=ppc64el=4.6.2.7%2Bdfsg-2=1526971899=0

Bug#899380: libreoffice-common: AppArmor profile prohibits encrypting documents with GPG

[John Scott]

Package: libreoffice-common
Version: 1:6.0.4~rc1-4
Followup-For: Bug #899380

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

> OpenPGP key not trusted, damaged, or encryption failure. Please try again.

That happened to me too because I didn't use a trusted
key the first time. When I encrypted to my own public
key, then it froze.

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

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

Versions of packages libreoffice-common depends on:
ii  libreoffice-style-tango  1:6.0.4~rc1-4
ii  ure  6.0.4~rc1-4

Versions of packages libreoffice-common recommends:
ii  fonts-liberation2   2.00.1-6
ii  libexttextcat-data  3.4.5-1
ii  python3-uno 1:6.0.4~rc1-4
ii  xdg-utils   1.1.2-2

Versions of packages libreoffice-common suggests:
ii  libreoffice-style-galaxy [libreoffice-style]  1:6.0.4~rc1-4
ii  libreoffice-style-tango [libreoffice-style]   1:6.0.4~rc1-4

Versions of packages python3-uno depends on:
ii  libc6 2.27-3
ii  libgcc1   1:8.1.0-3
ii  libpython3.6  3.6.5~rc1-1
ii  libreoffice-core  1:6.0.4~rc1-4
ii  libstdc++68.1.0-3
ii  python3   3.6.4-1
ii  python3.6 3.6.5~rc1-1
ii  uno-libs3 6.0.4~rc1-4
ii  ure   6.0.4~rc1-4

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQEzBAEBCgAdFiEEJwCMxdBfG24Y2trvfWFEpid5MHIFAlsFqc8ACgkQfWFEpid5
MHKUAAgAgyU+kmEJUiGtL8ieFqqMZEdNJfP3tH2xWPpo4JcYHonhB2NeO2oYt/jg
lKiNUayfQlOMxvnA8QARtw3ZT0q00/lQJfyRdK6L9pPixDXhZHvH8G2wdX3PcHY7
qosXQNEvvEKVkWkkXsZydgUKTpKvO5FKLXEud/7bWP2P/ZloH+fWv44LDOjCA1O5
HdnfeDf4OjjBBqeyi7OSwVPmBhvuBYsNWdPzL9d3ELnAUSJm7vKu2gILani2MvJ4
1Mj2Mt4Pws2qODOKuAs8LAg70OV5h18V748bgLTRtHSUxNvXM6ag1rAaI1GE0J+n
aiMMm5B5R5hVx+bBD5ZOfOqr8K3unQ==
=cFMp
-END PGP SIGNATURE-

Bug#899380: libreoffice-common: AppArmor profile prohibits encrypting documents with GPG

[Rene Engelhard]

tag 899380 - moreinfo
tag 899380 - unreproducible
thanks

Hi,

On Wed, May 23, 2018 at 01:03:32PM -0400, John Scott wrote:
> I'm afraid there's a misunderstanding. I wasn't referring
> to signing: I had been checking the "Encrypt with GPG key"
> in the Save As dialog. Encrypting it to my own public key
> causes it to freeze. Signing works fine, though.

Ah, right, bad reading from my side, sorry.

I don't get a freeze but a

"OpenPGP key not trusted, damaged, or encryption failure. Please try
again."

but that incidentially also with the profile aa-complain'ed
(Then again my key is on a smartcard.)

Regards,

Rene

Bug#899379: [Pkg-freeipa-devel] Bug#899379: Bug#899379: bind9-dyndb-ldap: schema with errors

[paulo bruck]

Hy Tim]

Sorry, my bad. I'm not usualy to report bugs...80)

Do you think tha is  better to use backport of this  package?

diff atachead

2018-05-23 14:10 GMT-03:00 Timo Aaltonen :

> On 23.05.2018 20:01, paulo bruck wrote:
> > Hi Timo
> >
> > Nope I am using stretch with no backports.
> >
> > By the way I have to comment out some other lines because I 'm usng
> > cosine.schema
>
> What are you using it for? It's meant for freeipa, so I'm not going to
> change the schema to something which won't work with IPA.
>
> > atachead diff
> >
> > What do you mean about diff wold be readable??
>
> your diff is unreadable, use 'diff -u'
>
>
> --
> t
>



-- 
Paulo Ricardo Bruck consultor
tel 011 3596-4881/4882  011 98140-9184 (TIM)
http://www.contatogs.com.br
http://www.protejasuarede.com.br
gpg AAA59989 at wwwkeys.us.pgp.net
--- /usr/share/doc/bind9-dyndb-ldap/schema.ldif 2016-09-19 15:11:47.0 
-0300
+++ /etc/ldap/schema/dns.schema 2018-05-23 11:32:02.133105507 -0300
@@ -32,51 +32,51 @@
 #
 #
 # 389 DS requires following DN
-dn: cn=schema
+#dn: cn=schema
 #
 # OpenLDAP 2.4 requires following DN + objectClass + different attribute names
-# s/^attributeTypes:/olcAttributeTypes:/
-# s/^objectClasses:/olcObjectClasses:/
+# s/^attributeTypes:/attributeTypes/
+# s/^objectClass/olcObjectClasses:/
 #dn: cn=dns,cn=schema,cn=config
 #objectClass: olcSchemaConfig
 #
 #
 # COSINE schema
 # comment out if your server has COSINE schema installed
-attributeTypes: ( 0.9.2342.19200300.100.1.26 
- NAME 'aRecord' 
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 
- EQUALITY caseIgnoreIA5Match )
-#
-attributeTypes: ( 0.9.2342.19200300.100.1.27 
- NAME 'mDRecord' 
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 
- EQUALITY caseIgnoreIA5Match )
-#
-attributeTypes: ( 0.9.2342.19200300.100.1.28 
- NAME 'mXRecord' 
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 
- EQUALITY caseIgnoreIA5Match )
-#
-attributeTypes: ( 0.9.2342.19200300.100.1.29 
- NAME 'nSRecord' 
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 
- EQUALITY caseIgnoreIA5Match )
+#attributeTypes: ( 0.9.2342.19200300.100.1.26 
+# NAME 'aRecord' 
+# SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 
+# EQUALITY caseIgnoreIA5Match )
+#
+#attributeTypes ( 0.9.2342.19200300.100.1.27 
+# NAME 'mDRecord' 
+# SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 
+# EQUALITY caseIgnoreIA5Match )
+#
+#attributeTypes ( 0.9.2342.19200300.100.1.28 
+# NAME 'mXRecord' 
+# SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 
+# EQUALITY caseIgnoreIA5Match )
+#
+#attributeTypes ( 0.9.2342.19200300.100.1.29 
+# NAME 'nSRecord' 
+# SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 
+# EQUALITY caseIgnoreIA5Match )
 # CNAME record was originally defined as multi-value
 # but we redefined it as single-value to conform with RFC 2136, section 1.1.5.
-attributeTypes: ( 0.9.2342.19200300.100.1.31 
- NAME 'cNAMERecord' 
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 
- EQUALITY caseIgnoreIA5Match 
- SINGLE-VALUE )
+#attributeTypes ( 0.9.2342.19200300.100.1.31 
+# NAME 'cNAMERecord' 
+# SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 
+# EQUALITY caseIgnoreIA5Match 
+# SINGLE-VALUE )
 #
-attributeTypes: ( 1.3.6.1.4.1.2428.20.0.0 
+attributeTypes ( 1.3.6.1.4.1.2428.20.0.0 
  NAME 'dNSTTL' 
  DESC 'An integer denoting time to live' 
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 
  EQUALITY integerMatch )
 #
-attributeTypes: ( 1.3.6.1.4.1.2428.20.0.2 
+attributeTypes ( 1.3.6.1.4.1.2428.20.0.2 
  NAME 'dNSdefaultTTL' 
  DESC 'An integer denoting default time to live, RFC 2308' 
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 
@@ -86,104 +86,104 @@
 #
 # UNINETT and FreeIPA attributes
 # dnsClass attribute is in fact unsupported by bind-dyndb-ldap
-attributeTypes: ( 1.3.6.1.4.1.2428.20.0.1 
+attributeTypes ( 1.3.6.1.4.1.2428.20.0.1 
  NAME 'dNSClass' 
  DESC 'The class of a resource record' 
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 
  EQUALITY caseIgnoreIA5Match )
 #
-attributeTypes: ( 1.3.6.1.4.1.2428.20.1.12 
+attributeTypes ( 1.3.6.1.4.1.2428.20.1.12 
  NAME 'pTRRecord' 
  DESC 'domain name pointer, RFC 1035' 
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 
  EQUALITY caseIgnoreIA5Match 
  SUBSTR caseIgnoreIA5SubstringsMatch )
 #
-attributeTypes: ( 1.3.6.1.4.1.2428.20.1.13 
+attributeTypes ( 1.3.6.1.4.1.2428.20.1.13 
  NAME 'hInfoRecord' 
  DESC 'host information, RFC 1035' 
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 
  EQUALITY caseIgnoreIA5Match 
  SUBSTR caseIgnoreIA5SubstringsMatch )
 #
-attributeTypes: ( 1.3.6.1.4.1.2428.20.1.14 
+attributeTypes ( 1.3.6.1.4.1.2428.20.1.14 
  NAME 'mInfoRecord' 
  DESC 'mailbox or mail list information, RFC 1035' 
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 
  EQUALITY caseIgnoreIA5Match 
  SUBSTR caseIgnoreIA5SubstringsMatch )
 #
-attributeTypes: ( 1.3.6.1.4.1.2428.20.1.16 
+attributeTypes ( 1.3.6.1.4.1.2428.20.1.16 
  NAME 'tXTRecord' 
  DESC 'text string, RFC 1035' 
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 
  EQUALITY caseIgnoreIA5Match 
  SUBSTR caseIgnoreIA5SubstringsMatch )
 #
-attributeTypes: ( 1.3.6.1.4.1.2428.20.1.18 
+attributeTypes ( 1.3.6.1.4.1.2428.20.1.18 
  NAME 

Bug#899394: ncurses-base: Add Breaks on libmono-corlib4.5-cil (<< 4.6.2.7+dfsg-2)

[Sven Joachim]

Package: ncurses-base
Version: 6.1+20180210-4
Severity: normal

It has been noticed in #899112 and #899222 that Mono's
System.TermInfoReader is incompatible with the new terminfo format.  The
Debian mono maintainers kindly fixed that in version 4.6.2.7+dfsg-2, and
so versioned Breaks should be added to ncurses-base and ncurses-term to
ensure smooth partial upgrades, as has already been done for other
libraries.

Unfortunately the new mono version FTBFS on four architectures where it
has been built before.  This needs to be fixed first before the Breaks
can be added, as making libmono-corlib4.5-cil uninstallable is not
acceptable.

Bug#899353: dolphin-emu: Emulation freezes after 1-5 minutes

[Matt]

Done. Bug report is at https://bugs.dolphin-emu.org/issues/11159


On 5/23/2018 7:16 AM, James Cowgill wrote:

Control: tags -1 upstream

Hi,

On 23/05/18 08:56, Matt wrote:

Package: dolphin-emu
Version: 5.0+dfsg-3+b1
Severity: important

Dear Maintainer,

After Mesa upgrade to 18.0.3-1, emulation will freeze after 1-5 minutes of
play. The GUI is still responsive, however attempting to stop emulation will
lock up the GUI as well.
Problem appears consistently on every game tried. Possibly tiggered by # of
objects / effects being rendered, as it usually freezes during graphically
intense scenes. Gameplay stutters occasionally before freezing entirely.

Tried building current master branch (0e9255c469) of Dolphin from github. Same
issue - still freezes after a few minutes.

Downgrading Mesa to 17.3.9-1 resolves the issue.

I haven't checked this myself, but if you can reproduce the bug with
upstream git master, it would be good if you could submit a bug to their
bug tracker as well. They're more likely to know what the issue is.
https://bugs.dolphin-emu.org/issues/new

James

Bug#881135: [Pkg-mozext-maintainers] Bug#881135: marked as done (xul-ext-ublock-origin: Update ublock-origin to version 1.14.16 by next p-u)

[Sean Whitton]

control: reopen -1
control: retitle -1 Transition script for 
xul-ext-ublock-origin->webext-ublock-origin
control: severity -1 normal

Hello Michael,

On Wed, May 23 2018, Debian Bug Tracking System wrote:

> Forgot to close this report with the last upload.

I think it should remain open for the transition script work, which
David has started doing.

Without such a script (and NEWS.Debian entry telling people to run it),
users upgrading from stretch to buster will lose all their
customisations.

-- 
Sean Whitton

Bug#899393: monitoring-plugins-basic: check_dhcp command_line includes non-option argument

[paulgorman]

Package: monitoring-plugins-basic
Version: 2.2-3
Severity: normal

Dear Maintainer,

After upgrading to Stretch, and replacing Nagios with Icinga, Icinga
reported a problem with the DHCP check:

"Got unexpected non-option argument"

If I edit '/etc/nagios-plugins/config/dhcp.cfg', and change:

command_line/usr/lib/nagios/plugins/check_dhcp -s
'$HOSTADDRESS$' '$ARG1$'

...to:

command_line/usr/lib/nagios/plugins/check_dhcp -s '$HOSTADDRESS$'

...the problem goes away.

Icinga seems to invoke 'check_dhcp' with an extra, unwanted non-option
argument.


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

Kernel: Linux 4.9.0-6-686-pae (SMP w/2 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 monitoring-plugins-basic depends on:
ii  iputils-ping   3:20161105-1
ii  libc6  2.24-11+deb9u3
ii  libssl1.1  1.1.0f-3+deb9u2
ii  monitoring-plugins-common  2.2-3
ii  procps 2:3.3.12-3+deb9u1
ii  ucf3.0036

Versions of packages monitoring-plugins-basic recommends:
ii  libcap2-bin  1:2.25-1

Versions of packages monitoring-plugins-basic suggests:
ii  icinga  1.13.4-2

-- no debconf information

Bug#429577: #429577: ITP: emacs-snapshot -- The GNU Emacs editor (development snapshot)

[Sean Whitton]

Hello,

On Wed, May 23 2018, Arnaud Fontaine wrote:

> Anyhow, emacs-snapshot will only be available in sid/experimental

+1

> But I get your point and indeed there need to be a plan to check
> before each upload of emacs-snapshot whether it breaks add-ons. A
> shell script installing in a clean chroot emacs-snapshot to be
> uploaded and all available add-ons in the archive would probably be
> enough and fairly easy to write?

I'd suggest installing the old emacs-snapshot and all addons, and then
upgrading to the new emacs-snapshot.  And then also test installing all
addons without emacs-snapshot, and then installing the new
emacs-snapshot.  And perhaps installing the new emacs-snapshot and then
all addons, too.

I think you are aware, but just in case/for onlookers, the main issue is
that all addons will get bytecompiled against the new Emacs by
maintscripts, so if emacs-snapshot breaks addons, apt will be in a
"failed to configure" state which can be a pain to recover from.

I think there should be a warning in the package description that the
package is for fairly advanced users only -- I can see someone not
really familiar with apt/dpkg installing it, and then finding their
system in a state from which they don't know how to back out.  Unstable
has garnered a reputation for actually being quite stable...

-- 
Sean Whitton

Bug#899379: [Pkg-freeipa-devel] Bug#899379: Bug#899379: bind9-dyndb-ldap: schema with errors

[Timo Aaltonen]

On 23.05.2018 20:01, paulo bruck wrote:
> Hi Timo
> 
> Nope I am using stretch with no backports.
> 
> By the way I have to comment out some other lines because I 'm usng
> cosine.schema

What are you using it for? It's meant for freeipa, so I'm not going to
change the schema to something which won't work with IPA.

> atachead diff
> 
> What do you mean about diff wold be readable??

your diff is unreadable, use 'diff -u'


-- 
t

Bug#899392: darcs: FTBFS: unsatisfied build-deps: - libghc-graphviz-dev:amd64 (< 2999.19)

[Emilio Pozuelo Monfort]

Package: darcs
Version: 2.12.5-3
Severity: serious

darcs can't be built anymore on sid:

darcs build-depends on missing:
- libghc-graphviz-dev:amd64 (< 2999.19)

Emilio

Bug#899380: libreoffice-common: AppArmor profile prohibits encrypting documents with GPG

[John Scott]

Package: libreoffice-common
Version: 1:6.0.4~rc1-4
Followup-For: Bug #899380

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

> Did it really fail to sign?

I'm afraid there's a misunderstanding. I wasn't referring
to signing: I had been checking the "Encrypt with GPG key"
in the Save As dialog. Encrypting it to my own public key
causes it to freeze. Signing works fine, though.

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

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

Versions of packages libreoffice-common depends on:
ii  libreoffice-style-tango  1:6.0.4~rc1-4
ii  ure  6.0.4~rc1-4

Versions of packages libreoffice-common recommends:
ii  fonts-liberation2   2.00.1-6
ii  libexttextcat-data  3.4.5-1
ii  python3-uno 1:6.0.4~rc1-4
ii  xdg-utils   1.1.2-2

Versions of packages libreoffice-common suggests:
ii  libreoffice-style-galaxy [libreoffice-style]  1:6.0.4~rc1-4
ii  libreoffice-style-tango [libreoffice-style]   1:6.0.4~rc1-4

Versions of packages python3-uno depends on:
ii  libc6 2.27-3
ii  libgcc1   1:8.1.0-3
ii  libpython3.6  3.6.5~rc1-1
ii  libreoffice-core  1:6.0.4~rc1-4
ii  libstdc++68.1.0-3
ii  python3   3.6.4-1
ii  python3.6 3.6.5~rc1-1
ii  uno-libs3 6.0.4~rc1-4
ii  ure   6.0.4~rc1-4

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQEzBAEBCgAdFiEEJwCMxdBfG24Y2trvfWFEpid5MHIFAlsFnuMACgkQfWFEpid5
MHIbgwgAi4PqYkZ709Lj/mXILg2J7pGJZDBB+BT8AE1FwGBhBEecqcS4LBR+T1mz
LAb4ipm5a4QaMLpsKWokdC1Z6gx+kv3OvfB/byKK5xOxggOdeD9GnkNjAMuID86D
QERDKpB8jZvqpALzuYXUbYKxteijY7v1l+5BQ3C1llb8ji23oh/Yqt9T7IWo87Ks
UoeUUVp8iTkDZhVu9Uvr2EiPfkbhNCyv4jhgzNNgvSdh5XHBA5JZevEADPVOblee
TeGZuiHV1hBjFETTN41UzI2sTfgW4Ez5MtpV3Y0Q6XbT9i+dzQAQcmOm6bEqCPMT
8bK+7Alej6c+vdQNC/CDu8TtOgtQ9w==
=mW9a
-END PGP SIGNATURE-

Bug#899391: libopenmpi-dev: pkgconfig files contain rpath

[Drew Parsons]

Package: libopenmpi-dev
Version: 3.1.0-3
Severity: normal

openmpi3's pkgconfig files contain rpaths in the Libs entries, e.g.
ompi.pc contains "-Wl,-rpath -Wl,${libdir}"

Is this deliberate?  Debian best practice tells us that we shouldn't
use rpaths since they interfere with library search paths.

Client packages (e.g. petsc) pick up the openmpi configuration and add
the rpath to their libraries, e.g.
  RUNPATH  /usr/lib/x86_64-linux-gnu/openmpi/lib
This triggers the lintian warning "binary-or-shlib-defines-rpath",
referring to https://wiki.debian.org/RpathIssue

Should openmpi be patched for this, or is it an exception to the
general rule ?  (in which case perhaps lintian should be patched to
ignore a RUNPATH with /usr/lib/*/openmpi/lib)


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

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

Versions of packages libopenmpi-dev depends on:
ii  libc62.27-3
ii  libevent-2.1-6   2.1.8-stable-4
ii  libevent-pthreads-2.1-6  2.1.8-stable-4
ii  libhwloc-dev 1.11.10-1+b1
ii  libhwloc51.11.10-1+b1
ii  libibverbs-dev   18.0-1
ii  libopenmpi3  3.1.0-3
ii  openmpi-bin  3.1.0-3
ii  openmpi-common   3.1.0-3

libopenmpi-dev recommends no packages.

Versions of packages libopenmpi-dev suggests:
pn  openmpi-doc  

-- no debconf information

Bug#899379: [Pkg-freeipa-devel] Bug#899379: bind9-dyndb-ldap: schema with errors

[paulo bruck]

Hi Timo

Nope I am using stretch with no backports.

By the way I have to comment out some other lines because I 'm usng
cosine.schema

atachead diff

What do you mean about diff wold be readable??

best regards


2018-05-23 11:44 GMT-03:00 Timo Aaltonen :

> On 23.05.2018 17:20, paulo bruck wrote:
> > Package: bind9-dyndb-ldap
> > Version: 10.1-1
> > Severity: important
> > Tags: patch
> >
> > Dear Maintainer,
> >
> >* What led up to the situation?
> > Schema has errors.
> >* What exactly did you do (or not do) that was effective (or
> >  ineffective)?
> > apply patch
> > 1) comment line 35
> > 2) change objectclasses: by objectclass
> > 3) comment out objectclass idnsTemplateObject becasuse attribute
> > idnsTemplateAttribute does not exist
> >* What was the outcome of this action?
> >* What outcome did you expect instead?
>
> Are you using some backported packages? Looks like you're not using
> unstable.. not that freeipa would work there either.
>
> and a unified diff would be readable
>
> --
> t
>



-- 
Paulo Ricardo Bruck consultor
tel 011 3596-4881/4882  011 98140-9184 (TIM)
http://www.contatogs.com.br
http://www.protejasuarede.com.br
gpg AAA59989 at wwwkeys.us.pgp.net
35c35
< dn: cn=schema
---
> #dn: cn=schema
38,39c38,39
< # s/^attributeTypes:/olcAttributeTypes:/
< # s/^objectClasses:/olcObjectClasses:/
---
> # s/^attributeTypes:/attributeTypes/
> # s/^objectClass/olcObjectClasses:/
46,64c46,64
< attributeTypes: ( 0.9.2342.19200300.100.1.26 
<  NAME 'aRecord' 
<  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 
<  EQUALITY caseIgnoreIA5Match )
< #
< attributeTypes: ( 0.9.2342.19200300.100.1.27 
<  NAME 'mDRecord' 
<  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 
<  EQUALITY caseIgnoreIA5Match )
< #
< attributeTypes: ( 0.9.2342.19200300.100.1.28 
<  NAME 'mXRecord' 
<  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 
<  EQUALITY caseIgnoreIA5Match )
< #
< attributeTypes: ( 0.9.2342.19200300.100.1.29 
<  NAME 'nSRecord' 
<  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 
<  EQUALITY caseIgnoreIA5Match )
---
> #attributeTypes: ( 0.9.2342.19200300.100.1.26 
> # NAME 'aRecord' 
> # SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 
> # EQUALITY caseIgnoreIA5Match )
> #
> #attributeTypes ( 0.9.2342.19200300.100.1.27 
> # NAME 'mDRecord' 
> # SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 
> # EQUALITY caseIgnoreIA5Match )
> #
> #attributeTypes ( 0.9.2342.19200300.100.1.28 
> # NAME 'mXRecord' 
> # SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 
> # EQUALITY caseIgnoreIA5Match )
> #
> #attributeTypes ( 0.9.2342.19200300.100.1.29 
> # NAME 'nSRecord' 
> # SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 
> # EQUALITY caseIgnoreIA5Match )
67,71c67,71
< attributeTypes: ( 0.9.2342.19200300.100.1.31 
<  NAME 'cNAMERecord' 
<  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 
<  EQUALITY caseIgnoreIA5Match 
<  SINGLE-VALUE )
---
> #attributeTypes ( 0.9.2342.19200300.100.1.31 
> # NAME 'cNAMERecord' 
> # SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 
> # EQUALITY caseIgnoreIA5Match 
> # SINGLE-VALUE )
73c73
< attributeTypes: ( 1.3.6.1.4.1.2428.20.0.0 
---
> attributeTypes ( 1.3.6.1.4.1.2428.20.0.0 
79c79
< attributeTypes: ( 1.3.6.1.4.1.2428.20.0.2 
---
> attributeTypes ( 1.3.6.1.4.1.2428.20.0.2 
89c89
< attributeTypes: ( 1.3.6.1.4.1.2428.20.0.1 
---
> attributeTypes ( 1.3.6.1.4.1.2428.20.0.1 
95c95
< attributeTypes: ( 1.3.6.1.4.1.2428.20.1.12 
---
> attributeTypes ( 1.3.6.1.4.1.2428.20.1.12 
102c102
< attributeTypes: ( 1.3.6.1.4.1.2428.20.1.13 
---
> attributeTypes ( 1.3.6.1.4.1.2428.20.1.13 
109c109
< attributeTypes: ( 1.3.6.1.4.1.2428.20.1.14 
---
> attributeTypes ( 1.3.6.1.4.1.2428.20.1.14 
116c116
< attributeTypes: ( 1.3.6.1.4.1.2428.20.1.16 
---
> attributeTypes ( 1.3.6.1.4.1.2428.20.1.16 
123c123
< attributeTypes: ( 1.3.6.1.4.1.2428.20.1.18 
---
> attributeTypes ( 1.3.6.1.4.1.2428.20.1.18 
130c130
< attributeTypes: ( 1.3.6.1.4.1.2428.20.1.28 
---
> attributeTypes ( 1.3.6.1.4.1.2428.20.1.28 
137c137
< attributeTypes: ( 1.3.6.1.4.1.2428.20.1.29 
---
> attributeTypes ( 1.3.6.1.4.1.2428.20.1.29 
144c144
< attributeTypes: ( 1.3.6.1.4.1.2428.20.1.30 
---
> attributeTypes ( 1.3.6.1.4.1.2428.20.1.30 
151c151
< attributeTypes: ( 1.3.6.1.4.1.2428.20.1.33 
---
> attributeTypes ( 1.3.6.1.4.1.2428.20.1.33 
158c158
< attributeTypes: ( 1.3.6.1.4.1.2428.20.1.35 
---
> attributeTypes ( 1.3.6.1.4.1.2428.20.1.35 
165c165
< attributeTypes: ( 1.3.6.1.4.1.2428.20.1.36 
---
> attributeTypes ( 1.3.6.1.4.1.2428.20.1.36 
172c172
< attributeTypes: ( 1.3.6.1.4.1.2428.20.1.37 
---
> attributeTypes ( 1.3.6.1.4.1.2428.20.1.37 
179c179
< attributeTypes: ( 1.3.6.1.4.1.2428.20.1.38 
---
> attributeTypes ( 1.3.6.1.4.1.2428.20.1.38 
186c186
< attributeTypes: ( 1.3.6.1.4.1.2428.20.1.39 
---
> attributeTypes ( 1.3.6.1.4.1.2428.20.1.39 
194c194
< attributeTypes: ( 1.3.6.1.4.1.2428.20.1.43 
---
> attributeTypes ( 1.3.6.1.4.1.2428.20.1.43 
201c201
< attributeTypes: ( 1.3.6.1.4.1.2428.20.1.44 
---
> attributeTypes ( 1.3.6.1.4.1.2428.20.1.44 
208c208
< attributeTypes: ( 

Bug#899390: firefox-l10n-de: Language pack cannot be verified

[Thomas Renard]

Package: firefox-l10n-de
Version: 60.0.1-5
Severity: normal

Dear Maintainer,

- in firefox open about:addons and click to languages tab

expected:

- German language pack is shown without warnings

actual behavior:

- The pack is shown with a warning:

"Deutsch (DE) Language Pack konnt nicht für die Verwendung in Firefox
verifiziert werden. Fahren Sie mit Vorsicht fort"

"Germen (DE) language pack could not be verified for use in firefox.
Handle with care ;-)"

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

Versions of packages firefox-l10n-de depends on:
ii  firefox  60.0.1-5

Versions of packages firefox-l10n-de recommends:
ii  myspell-de-de  20161207-4

firefox-l10n-de suggests no packages.

-- no debconf information

Bug#887542: libemail-address-list-perl depends on libemail-address-perl

[gregor herrmann]

On Sun, 20 May 2018 12:41:57 +0200, Pali Rohár wrote:

> Perl module Email::Address::List is probably not possible to fix. But
> perl module Email::Address::XS already provides methods for parsing
> list/groups of email addresses -- functionality which is provided by
> Email::Address::List. Therefore applications which depends on
> Email::Address::List can be rewritten to use Email::Address::XS.

Thanks for this update.

libemail-address-list-perl has one reverse dependency:
request-tracker4.

Cc'ing the maintainers.


Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: Rolling Stones: Can't Believe


signature.asc
Description: Digital Signature

Bug#899389: RM: chezscheme [armel] -- ANAIS; crashes on armel

[Emilio Pozuelo Monfort]

Package: ftp.debian.org
Severity: normal

Hi,

chezscheme's maintainer dropped armel from the architecture list:

chezscheme (9.5+dfsg-3) unstable; urgency=medium
[...]
  * Drop the armel architecture because it crashes when floating point is
used (it never worked).

 -- Göran Weinholt   Sat, 19 May 2018 10:55:27 +0200

Please drop the binaries from armel. There are no rdeps (except for a couple
of arch:all ones) afaics.

Emilio

Bug#429577: #429577: ITP: emacs-snapshot -- The GNU Emacs editor (development snapshot)

[David Bremner]

Dima Kogan  writes:

> Arnaud Fontaine  writes:
>
 I have almost  finished preparing emacs-snapshot[0] and as  I said to
 Rob, my plan  is to keep emacs-snapshot package as  close as possible
 to emacsXY package.  I know that you've been  working on unversioning
 emacs package (BTW Where is that repository?).
>>>
>>> How many of  the existing add-on packages in sid  have you tested with
>>> your emacs-snapshot package?  Do you have some  plan to prevent/manage
>>> breakage of add-ons  by a new upload of emacs-snapshot?  It seems like
>>> every upload is potentially like a library transition, in that changes
>>> in emacs tend to break add-on packages.
>>
>> I use  it myself on a  daily basis for a  few months (and Dima  for much
>> longer so he may  know more than me about that)  with around 20 add-ons.
>> Except the fact that old-style backquotes  have been removed for which I
>> have a few  patches ready (and which  is something that will  have to be
>> deal for emacs26 anyway AFAIK), I have not had any problem so far.
>
> I have no automated testing in my out-of-archive emacs-snapshot builds.
> It would be great to have. Rob: how do you usually do this in your
> packages?

As far as I know checking is a manual process with the stable emacs
uploads. But there are many fewer such uploads.

d

Bug#896970: RFS: odp/1.19.0.0-1 [ITP]

[Dmitry Eremin-Solenikov]

Hello,

I have updated odp & odp-dpdk packages on mentors.d.n.

2018-05-06 3:56 GMT+03:00 Dmitry Eremin-Solenikov :
> I will make my next upload use alternatives, thank you.

This upload uses alternatives to select ODP library to be used.

>> * move all the executables to /usr/bin. Their name starts with odp_, so
>>   I don't expect them to pollute the public name space. Putting these
>>   test programs in a private directory just makes it hard to find and
>>   use them.
>
> This looks logical to me. I will move some (usefull) programs to /usr/bin
> and will drop the rest of them.

I have moved several executables to /usr/bin and removed the rest of them.

This upload does not have manpages for those binaries, I will fix that in
the next upload.

>>> > 11. Why is dh_auto_test overrode to empty?
>>>
>>> We had issues with make check before, they interacted strangely with
>>> build environment, that is why it is disabled for now. I plan to
>>> reenable it later.
>>
>> How strange is it? And what happend during the test?
>>
>> As per policy, network access during the build is not availble. If this
>> is the cause of test problem, we can omit the test part. However, we
>> should still write the tests in the override_dh_auto_test target, if our
>> user want to test it somehow.
>
> Some of the validation scripts are trying to create/remove network
> interfaces.
>
>>   override_dh_auto_test:
>>   -test_binary
>>
>> This should be ok.
>
> Ack

This is not fixed yet. Also will be fixed in the next upload.

Could you please review alternatives system, so that I can be sure that
I've used them correctly?

-- 
With best wishes
Dmitry

Bug#899388: libopenmpi-dev: strict dependency on arch:all openmpi-common causes uninstallability issues

[Emilio Pozuelo Monfort]

Package: libopenmpi-dev
Version: 3.1.0-3
Severity: normal

Hi,

libopenmpi-dev depends on openmpi-common (= ${source:Version}). This causes
uninstallability problems whenever openmpi is uploaded, since the arch:all
openmpi-common is usually available before the arch:any libopenmpi-dev, making
the latter uninstallable. This is specially a problem if openmpi fails to build
on some architecture (as it recently happened with #899169), with packages
unable to build with e.g.:

boost1.62 build-depends on:
- mpi-default-dev:armhf
mpi-default-dev depends on:
- libopenmpi-dev:armhf
libopenmpi-dev depends on missing:
- openmpi-common:armhf (= 3.1.0-1)

Ideally a new openmpi upload wouldn't cause any uninstallability problems, even
temporary ones. To achieve that, there are several options, but I don't know
openmpi well enough to determine if any of them would be correct:

- Change the dependency to: openmpi-common (>= ${source:Version}). This is what
  openmpi-bin has. I'm not sure if the strict dependency is needed here for some
  reason.

- Drop the dependency. Do the headers actually need it?

- Other possibilities, such as making openmpi-common arch:any, or dropping the
  package and merging its contents into openmpi-bin may be too much work if one
  of the other options is possible.

Let me know if you think we have any options to fix this.

Thanks,
Emilio

Bug#899386: autopkgtest: Assumes all binaries from a source are co-installable.

[Martin Pitt]

Control: tag -1 moreinfo

Hello Neil,

Neil Williams [2018-05-23 17:07 +0100]:
> I am unable to test my uploads because my debian/control file lists a binary 
> which conflicts with
> one of the dependencies of another package from the same source package. 
> autopkgtest seems to assume
> that all binaries built from a source package must all be co-installable with 
> each other.

I take it you use "Depends: @" or no Depends: line at all? This is just a
shortcut for simple packages, but not at all useful for large multi-binary
sources. For them it's much better to explicitly specify which packages a test
needs, and you can test alternative packages in different tests.

> However, autopkgtest is now failing to handle these dependencies

Please be more specific. If a package is uninstallable because its dependencies
conflict, then that its an RC bug in that package (and britney should already
spot that). If your test dependencies specify conflicting packages, then that
test just needs to be fixed. autopkgtest does not prescribe anything there,
aside from the optional "@" shortcut.

Martin

Bug#899387: mirror submission for ftp.linux.it

[Marco d'Itri]

On May 23, Marco d_Itri  wrote:

> Type: leaf
The mirror is push-secondary from ftp.ch.

As a pubblic comment please use "rsync access is available to other 
public mirrors".

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#899387: mirror submission for ftp.linux.it

[Marco d_Itri]

Package: mirrors
Severity: wishlist
User: mirr...@packages.debian.org
Usertags: mirror-submission

Submission-Type: new
Site: ftp.linux.it
Type: leaf
Archive-architecture: ALL amd64 arm64 armel armhf hurd-i386 i386 kfreebsd-amd64 
kfreebsd-i386 mips mips64el mipsel powerpc ppc64el s390x
Archive-http: /debian/
Maintainer: Marco d_Itri 
Country: IT Italy
Location: Milano
Sponsor: Seeweb https://www.seeweb.it/
Comment: After a long pause my mirror is back with new hardware and a new 
sponsor. I would like to start servicing again the ftp.it.debian.org CNAME.
 
 Also, this form is culturally insensitive and rejects my last name with "Bad 
data in maintainer name: Marco d'Itri".




Trace Url: http://ftp.linux.it/debian/project/trace/
Trace Url: http://ftp.linux.it/debian/project/trace/ftp-master.debian.org
Trace Url: http://ftp.linux.it/debian/project/trace/ftp.linux.it