Bug#880722: Segfault while using xrdp-sesman on Stretch

[Gilles MOREL]

Package: xrdp
Version: 0.9.1-9

I installed xrdp on one of my servers on Debian Stretch. Some users connect to 
these desktops.
When I have at least two connected users, when one of them close the session, 
this happens in the kernel log :
xrdp-sesman[1006]: segfault at 0 ip 7f1c4e6aa646 sp 7ffc0ce9f918 error 
4 in libc-2.24.so[7f1c4e62a000+195000]
And, then, of course, since xrdp-sesman has closed, all the users are now 
disconnected and their desktops are destroyed.

I attached the configuration, with / in names replaced by #.
Regards,
--
Gilles Émilien MOREL 
« I'm a banana, look at me move!! » -- Onision
[globals]
ini_version=1
bitmap_cache=yes
bitmap_compression=yes
port=3389
allow_channels=true
max_bpp=32
fork=yes
crypt_level=high
security_layer=rdp
certificate=
key_file=
tcp_nodelay=yes
tcp_keepalive=yes
blue=af
grey=dedede
autorun=xrdp1
bulk_compression=yes
new_cursors=yes
allow_multimon=true
use_fastpath=both
ls_title=Bureau ATI sur SRV035
ls_top_window_bg_color=66
ls_width=350
ls_height=350
ls_bg_color=dedede
ls_logo_filename=
ls_logo_x_pos=55
ls_logo_y_pos=50
ls_label_x_pos=30
ls_label_width=60
ls_input_x_pos=110
ls_input_width=210
ls_input_y_pos=220
ls_btn_ok_x_pos=5
ls_btn_ok_y_pos=300
ls_btn_ok_width=165
ls_btn_ok_height=45
ls_btn_cancel_x_pos=180
ls_btn_cancel_y_pos=300
ls_btn_cancel_width=165
ls_btn_cancel_height=45

[Logging]
LogFile=xrdp.log
LogLevel=DEBUG
EnableSyslog=1
SyslogLevel=DEBUG

[channels]
rdpdr=true
rdpsnd=false
drdynvc=true
cliprdr=false
rail=true
xrdpvr=true
tcutils=true

[xrdp1]
name=ATI33
lib=libxup.so
username=ask
password=ask
ip=127.0.0.1
port=-1
xserverbpp=24
code=20
delay_ms=2000[Globals]
ListenAddress=127.0.0.1
ListenPort=3350
EnableUserWindowManager=1
UserWindowManager=startwm.sh
DefaultWindowManager=startwm.sh

[Security]
AllowRootLogin=0
MaxLoginRetry=4
TerminalServerUsers=tsusers
TerminalServerAdmins=tsadmins
AlwaysGroupCheck = false

[Sessions]
X11DisplayOffset=10
MaxSessions=50
KillDisconnected=1
IdleTimeLimit=0
DisconnectedTimeLimit=0
Policy=Default

[Logging]
LogFile=xrdp-sesman.log
LogLevel=DEBUG
EnableSyslog=1
SyslogLevel=DEBUG

[X11rdp]
param0=X11rdp
param1=-bs
param2=-ac
param3=-nolisten
param4=tcp
param5=-uds

[Xvnc]
param0=Xvnc
param1=-bs
param2=-ac
param3=-nolisten
param4=tcp
param5=-localhost
param6=-dpi
param7=96

[Xorg]
param0=Xorg
param1=-config
param2=xrdp/xorg.conf
param3=-noreset
param4=-ac
param5=-nolisten
param6=tcp
param7=-retro

[Chansrv]
FuseMountName=.thinclient_drives

[SessionVariables]
PULSE_SCRIPT=/etc/xrdp/pulse/default.pa

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

Bug#880721: FTBFS: fatal error: doctest/doctest.h: No such file or directory

[Andreas Moog]

Source: argagg
Severity: serious
Justification: fails to build from source (but built successfully in the past)

Hello there,

argagg seems to FTBFS in a clean sid environment:

Generating XML output for the main page
lookup cache used 556/65536 hits=11073 misses=665
finished...
make[3]: Leaving directory '/<>/obj-x86_64-linux-gnu'
[ 57%] Built target docs
/<>/test/test.cpp:4:10: fatal error: doctest/doctest.h: No such 
file or directory
 #include "doctest/doctest.h"
  ^~~
compilation terminated.
CMakeFiles/argagg_test.dir/build.make:65: recipe for target 
'CMakeFiles/argagg_test.dir/test/test.cpp.o' failed

The full log is available at 
http://people.ubuntu.com/~ampelbein/argagg_0.4.6-3_amd64.build

Kind regards,

  Andreas

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

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

Bug#880720: updated xrdp: Failed at step RUNTIME_DIRECTORY spawning /bin/sh: File exists

[Gilles MOREL]

Package: xrdp
Version: 0.9.1-9~bpo8+1

I updated xrdp from version 0.9.1-4~bpo8+1 to 0.9.1-9~bpo8+1.

During the updated, I got an error:
Job for xrdp.service failed. See 'systemctl status xrdp.service' and 
'journalctl -xn' for details.
invoke-rc.d: initscript xrdp, action "restart" failed.
dpkg: erreur de traitement du paquet xrdp (--configure) :
 le sous-processus script post-installation installé a retourné une erreur de 
sortie d'état 1
Traitement des actions différées (« triggers ») pour libc-bin (2.19-18+deb8u10) 
...
Des erreurs ont été rencontrées pendant l'exécution :
 xrdp
E: Sub-process /usr/bin/dpkg returned an error code (1)

Retrying the configuration produces the same error.

When I try to start the xrdp service manually, I got this error:
Job for xrdp.service failed. See 'systemctl status xrdp.service' and 
'journalctl -xn' for details.

The status (systemctl status xrdp.service) gives me:
● xrdp.service - xrdp daemon
   Loaded: loaded (/lib/systemd/system/xrdp.service; enabled)
   Active: failed (Result: exit-code) since sam. 2017-11-04 14:12:43 CET; 16s 
ago
 Docs: man:xrdp(8)
   man:xrdp.ini(5)
  Process: 18625 ExecStartPre=/bin/sh /usr/share/xrdp/socksetup (code=exited, 
status=233/RUNTIME_DIRECTORY)

nov. 04 14:12:43 SRV033 systemd[1]: xrdp.service: control process exited, 
code=exited status=233
nov. 04 14:12:43 SRV033 systemd[1]: Failed to start xrdp daemon.
nov. 04 14:12:43 SRV033 systemd[1]: Unit xrdp.service entered failed state.

The journal (journalctl -xn) give me:
nov. 04 14:15:17 SRV033 systemd[1]: Starting xrdp session manager...
-- Subject: L'unité (unit) xrdp-sesman.service a commencé à démarrer
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- 
-- L'unité (unit) xrdp-sesman.service a commencé à démarrer.
nov. 04 14:15:17 SRV033 xrdp-sesman[20573]: (20573)(140385333458688)[DEBUG] 
libscp initialized
nov. 04 14:15:17 SRV033 xrdp-sesman[20574]: (20574)(140385333458688)[INFO ] 
starting xrdp-sesman with pid 20574
nov. 04 14:15:17 SRV033 systemd[1]: Started xrdp session manager.
-- Subject: L'unité (unit) xrdp-sesman.service a terminé son démarrage
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- 
-- L'unité (unit) xrdp-sesman.service a terminé son démarrage, avec le résultat 
done.
nov. 04 14:15:17 SRV033 systemd[1]: Starting xrdp daemon...
-- Subject: L'unité (unit) xrdp.service a commencé à démarrer
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- 
-- L'unité (unit) xrdp.service a commencé à démarrer.
nov. 04 14:15:17 SRV033 xrdp-sesman[20574]: (20574)(140385333458688)[INFO ] 
listening to port 3350 on 127.0.0.1
nov. 04 14:15:17 SRV033 systemd[20575]: Failed at step RUNTIME_DIRECTORY 
spawning /bin/sh: File exists
-- Subject: Le processus /bin/sh n'a pas pu être exécuté
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- 
-- Le processus /bin/sh n'a pas pu être exécuté, et a donc echoué.
-- 
-- Le code d'erreur renvoyé est 17.
nov. 04 14:15:17 SRV033 systemd[1]: xrdp.service: control process exited, 
code=exited status=233
nov. 04 14:15:17 SRV033 systemd[1]: Failed to start xrdp daemon.
-- Subject: L'unité (unit) xrdp.service a échoué
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- 
-- L'unité (unit) xrdp.service a échoué, avec le résultat failed.
nov. 04 14:15:17 SRV033 systemd[1]: Unit xrdp.service entered failed state.
nov. 04 14:15:17 SRV033 sudo[20570]: pam_unix(sudo:session): session closed for 
user root
nov. 04 14:15:17 SRV033 systemd[1]: Stopping xrdp session manager...
-- Subject: L'unité (unit) xrdp-sesman.service a commencé à s'arrêter
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- 
-- L'unité (unit) xrdp-sesman.service a commencé à s'arrêter.
nov. 04 14:15:17 SRV033 systemd[1]: xrdp-sesman.service: control process 
exited, code=exited status=1
nov. 04 14:15:17 SRV033 xrdp-sesman[20574]: (20574)(140385333458688)[INFO ] 
shutting down sesman 1
nov. 04 14:15:17 SRV033 xrdp-sesman[20574]: (20574)(140385333458688)[DEBUG] 
Closed socket 8 (AF_INET6 ::1 port 3350)
nov. 04 14:15:17 SRV033 systemd[1]: Stopped xrdp session manager.
-- Subject: L'unité (unit) xrdp-sesman.service a terminé son arrêt
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- 
-- L'unité (unit) xrdp-sesman.service a terminé son arrêt

As workabout, I reinstalled the 0.9.1-4~bpo8+1 version and held it to this 
version.

I attached the configuration, with # instead of / in files' names.
--
Gilles Émilien MOREL 
« Pavé César, ceux qui n'ont pas lu te saluent ! » -- Farod
[globals]
ini_version=1

bitmap_cache=yes
bitmap_compression=yes
port=3389
allow_channels=true
max_bpp=32
fork=yes
crypt_level=high
security_layer=rdp

Bug#880719: budgie-desktop: please fix a typo in budgie-panel

[Herbert Parentes Fortes Neto]

Package: budgie-desktop
Version: 10.4+git20171031.10.g9f71bb8-1
Severity: minor

Dear Maintainer,

please fix the typo:

I: budgie-core: spelling-error-in-binary usr/bin/budgie-panel overriden 
overridden



Regards,
Herbert

Bug#255572: ITP: cc65 -- Cross development suite for 65xxx processors, necesary for nesicide env

[PICCORO McKAY Lenz]

seems there's no upload? any update? i'm interesting too!

Lenz McKAY Gerardo (PICCORO)
http://qgqlochekone.blogspot.com

2017-11-04 6:59 GMT-04:00 Michael Stapelberg :

> Any update on this? :)
>
> On Sat, Oct 7, 2017 at 10:49 PM, PICCORO McKAY Lenz
>  wrote:
> > hi! please when upload also be sure once the ITP bug are closed remove
> the
> > entry here too:
> >
> > https://www.debian.org/devel/wnpp/prospective
> >
> >
> > Lenz McKAY Gerardo (PICCORO)
> > http://qgqlochekone.blogspot.com
> >
> > 2017-10-06 20:30 GMT-04:00 PICCORO McKAY Lenz :
> >>
> >> a bit late but great work! please upload to debian..
> >>
> >> Lenz McKAY Gerardo (PICCORO)
> >> http://qgqlochekone.blogspot.com
> >>
> >> 2017-10-06 17:46 GMT-04:00 Michael Stapelberg :
> >>>
> >>> Indeed, I can confirm that compilation works now. Can you upload the
> >>> package to Debian please? :)
> >>>
> >>> On Fri, Oct 6, 2017 at 11:26 PM, László Böszörményi (GCS)
> >>>  wrote:
> >>> > On Fri, Oct 6, 2017 at 10:26 PM, Michael Stapelberg
> >>> >  wrote:
> >>> >> Thanks for sharing! The Debian package builds fine. However, when
> >>> >> trying to use cc65 to compile a project of mine, compilation fails
> >>> >> with “include/general.h(4): Error: Include file `peekpoke.h' not
> >>> >> found”.
> >>> >  Please fetch and build again. Should be fixed.
> >>> >
> >>> > Laszlo/GCS
> >>>
> >>>
> >>>
> >>> --
> >>> Best regards,
> >>> Michael
> >>
> >>
> >
>
>
>
> --
> Best regards,
> Michael
>

Bug#849203: libasound2: ALSA_PCM_DEVICE environment variable is ignored

[Leszek Godlewski]

Hi Elimar,

Apologies for taking so many months to reply, this is unfortunately how
long it took for the use case to arise again.

Unfortunately, your fix to asound.conf didn't help. I'm on up-to-date
Debian testing, and with the contents of asound.conf you suggested (I
simply copy/pasted the contents of your last email), ALSA apps now report
this in the console:

ALSA lib conf.c:1385:(parse_def) device is not a compound
ALSA lib conf.c:1852:(snd_config_load1) _toplevel_:4:21:Zły argument
ALSA lib conf.c:3615:(config_file_open) /etc/asound.conf may be old or
corrupted: consider to remove or fix it
ALSA lib conf.c:3537:(snd_config_hooks_call) function snd_config_hook_load
returned error: Zły argument
ALSA lib conf.c:3986:(snd_config_update_r) hooks failed, removing
configuration

Which means I'm back to my old hack of symlinking /dev/snd/PCMC1D0p to
/dev/snd/pcmC1D3p again.

Regards,

Leszek

śr., 11 sty 2017 o 19:31 użytkownik Elimar Riesebieter 
napisał:

> * Leszek Godlewski  [2016-12-23 18:46 +]:
>
> > Hi Elimar,
> >
> > If that is the case, why does ALSA_PCM_CARD work without such
> preparation?
> > /usr/share/alsa/alsa.conf contains a similar block for the card, yet it
> > isn't needed in /etc/asound.conf.
> >
> > I will try it anyway and let you know if it worked, thanks!
>
> Any news?
>
> [...]
>
> > > As far as i understsnd the sources you must prepare your device to
> > > interpret ALSA_PCM_DEVICE. Try /etc/asound.conf as follows:
> > >
> > > defaults.pcm.card 0
> > > defaults.pcm.device 3
> > > defaults.pcm.device {
> > > @func igetenv
> > > vars [ ALSA_PCM_DEVICE ]
> > > default 0
> > > }
> > >
> > > Now it should be possible to run
> > > $ ALSA_PCM_CARD=1 ALSA_PCM_DEVICE=0 mplayer test.mp3
>
> Elimar
>
> --
> .~.
> /V\   L   I   N   U   X
>/( )\ >Phear the Penguin<
>^^-^^
>

Bug#788651: viking no longer segfaults at start

[Arturo Borrero Gonzalez]

Control: fixed -1 1.6.2-3

Hi, I confirm that viking no longer segfaults at start, at least this
version 1.6.2-3.

% sudo LANG=C aptitude show viking
Package: viking
Version: 1.6.2-3+b1
New: yes
State: installed
Automatically installed: no
Priority: optional
Section: utils
Maintainer: Bernd Zeimetz 
Architecture: amd64
Uncompressed Size: 4495 k
Depends: libatk1.0-0 (>= 1.12.4), libbz2-1.0, libc6 (>= 2.14),
libcairo2 (>= 1.2.4), libcurl3-gnutls (>= 7.16.2), libexpat1 (>=
2.0.1), libfontconfig1 (>= 2.12),
 libfreetype6 (>= 2.2.1), libgcc1 (>= 1:3.0),
libgdk-pixbuf2.0-0 (>= 2.22.0), libgexiv2-2 (>= 0.6.1), libglib2.0-0
(>= 2.39.91), libgps23 (>= 3.3), libgtk2.0-0
 (>= 2.24.0), libicu57 (>= 57.1-1~), libmagic1 (>= 5.12),
libmapnik3.0 (>= 3.0.15+ds), libpango-1.0-0 (>= 1.14.0),
libpangocairo-1.0-0 (>= 1.14.0),
 libpangoft2-1.0-0 (>= 1.14.0), libsqlite3-0 (>= 3.5.9),
libstdc++6 (>= 5.2), libx11-6, zlib1g (>= 1:1.1.4), gpsbabel
Recommends: expect-dev
Suggests: gpsd
[...]

Bug#880718: libnginx-mod-rtmp: MPEG-dash manifest files structure makes them unexploitable

[Cyril Mertens]

Package: libnginx-mod-rtmp
Version: 1.13.3-1~bpo9+1
Severity: normal

Dear Maintainer,

I am using libnginx-mod-rtmp for my own need of streaming without relying on 
proprietary platforms but it appears that the implementation of MPEG-dash leads 
to malformatted manifest files.
As far as I noticed, Debian is using the master tree from 
https://github.com/arut/nginx-rtmp-module as it was after 13/02/2017 but before 
10/07/2017.
Using this actual version of the module leads to malformatted manifest and 
maybe other errors.
As a quick & dirty workaround I rebuild the package using the dev tree of 
https://github.com/sergey-dryabzhinsky/nginx-rtmp-module/tree/dev which seems 
to contain interesting patchset like
https://github.com/sergey-dryabzhinsky/nginx-rtmp-module/commit/7db5ef0ea56a113c7579a408cf2c13ab9a7ffa22.patch
but sadly the devlopment of this fork seems to be stalled.
Nevertheless I was able to play the streaming with MPEG-dash capabilities

For your reference here is the useable manifest files (tested with flwoplayer 
and VLC nightlies 3.0.0) I get with the fork:

http://www.w3.org/2011/XMLSchema-instance;
xsi:schemaLocation="urn:mpeg:DASH:schema:MPD:2011 DASH-MPD.xsd">
  

  

  
 
 
 
  

  


  
  

  
 
 
 
  

  

  


and with the module provided with Debian package:

http://www.w3.org/2011/XMLSchema-instance;
xsi:schemaLocation="urn:mpeg:DASH:schema:MPD:2011 DASH-MPD.xsd">
  

  

  
 
  

  


  
  

  
 
  

  

  


You will notice some differences in the structure.
I tried to incorporate some patches from the fork into the tree used by Debian 
but it seems more work is needed which I am not able to do because I do not 
have the required level in C.

I read the discussion of bug #843777 and despite being a very useful module, I 
understand the point of needing a reliable upstream contact for package 
maintenance.

Let me know if you need further testing from my side.

Regards,
Cyril


-- System Information:
Debian Release: 9.2
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable'), (200, 'testing')
Architecture: arm64 (aarch64)

Kernel: Linux 4.9.58-mainline-rev1 (SMP w/6 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set 
to en_US.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libnginx-mod-rtmp depends on:
ii  libc6 2.24-11+deb9u1
ii  nginx-common  1.13.3-1~bpo9+1

libnginx-mod-rtmp recommends no packages.

libnginx-mod-rtmp suggests no packages.

-- no debconf information

Bug#780430: qtwebkit-opensource-src: port to m68k

[John Paul Adrian Glaubitz]

Source: qtwebkit-opensource-src
Version: 5.9.1+dfsg-5
Followup-For: Bug #780430
User: debian-...@lists.debian.org
Usertags: m68k

Hi!

Attaching an updated patch for 5.9.1+dfsg-5, please apply.

I will try to upstream everything next week.

Thanks,
Adrian

--
  .''`.  John Paul Adrian Glaubitz
 : :' :  Debian Developer - glaub...@debian.org
 `. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
   `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
Description: Add support for m68k
 This patch adds the necessary cmake and platform definitions
 for m68k as well as a missing patch from double-conversion
 upstream for m68k support.  Furthermore, several COMPILE_ASSERT()
 statements are relaxed such that they also allow smaller struct
 sizes which often occur on m68k to the native alignment there
 being 16-bit despite being a 32-bit platform.
 .
Author: John Paul Adrian Glaubitz 
Last-Update: 2017-11-04

--- qtwebkit-opensource-src-5.212.0~alpha2.orig/CMakeLists.txt
+++ qtwebkit-opensource-src-5.212.0~alpha2/CMakeLists.txt
@@ -69,6 +69,8 @@ elseif (LOWERCASE_CMAKE_SYSTEM_PROCESSOR
 set(WTF_CPU_X86_64 1)
 elseif (LOWERCASE_CMAKE_SYSTEM_PROCESSOR MATCHES "(i[3-6]86|x86)")
 set(WTF_CPU_X86 1)
+elseif (LOWERCASE_CMAKE_SYSTEM_PROCESSOR MATCHES "m68k")
+set(WTF_CPU_M68K 1)
 elseif (LOWERCASE_CMAKE_SYSTEM_PROCESSOR MATCHES "ppc")
 set(WTF_CPU_PPC 1)
 elseif (LOWERCASE_CMAKE_SYSTEM_PROCESSOR MATCHES "ppc64")
--- 
qtwebkit-opensource-src-5.212.0~alpha2.orig/Source/JavaScriptCore/CMakeLists.txt
+++ qtwebkit-opensource-src-5.212.0~alpha2/Source/JavaScriptCore/CMakeLists.txt
@@ -1280,6 +1280,7 @@ endif ()
 if (WTF_CPU_ARM)
 elseif (WTF_CPU_ARM64)
 elseif (WTF_CPU_HPPA)
+elseif (WTF_CPU_M68K)
 elseif (WTF_CPU_PPC)
 elseif (WTF_CPU_PPC64)
 elseif (WTF_CPU_PPC64LE)
--- qtwebkit-opensource-src-5.212.0~alpha2.orig/Source/WTF/wtf/Platform.h
+++ qtwebkit-opensource-src-5.212.0~alpha2/Source/WTF/wtf/Platform.h
@@ -80,6 +80,12 @@
 #endif
 #endif
 
+/* CPU(M68K) - Motorola M68k */
+#if defined(__m68k__)
+#define WTF_CPU_M68K 1
+#define WTF_CPU_BIG_ENDIAN 1
+#endif
+
 /* CPU(MIPS) - MIPS 32-bit and 64-bit */
 #if (defined(mips) || defined(__mips__) || defined(MIPS) || defined(_MIPS_) || 
defined(__mips64))
 #if defined(_ABI64) && (_MIPS_SIM == _ABI64)
--- qtwebkit-opensource-src-5.212.0~alpha2.orig/Source/WTF/wtf/dtoa/utils.h
+++ qtwebkit-opensource-src-5.212.0~alpha2/Source/WTF/wtf/dtoa/utils.h
@@ -58,6 +58,8 @@ defined(_MIPS_ARCH_MIPS32R2)
 #else
 #undef DOUBLE_CONVERSION_CORRECT_DOUBLE_OPERATIONS
 #endif  // _WIN32
+#elif defined(__m68k__)
+#undef DOUBLE_CONVERSION_CORRECT_DOUBLE_OPERATIONS
 #else
 #error Target architecture was not detected as supported by Double-Conversion.
 #endif
--- 
qtwebkit-opensource-src-5.212.0~alpha2.orig/Source/WebCore/css/CSSProperty.cpp
+++ qtwebkit-opensource-src-5.212.0~alpha2/Source/WebCore/css/CSSProperty.cpp
@@ -35,7 +35,7 @@ struct SameSizeAsCSSProperty {
 void* value;
 };
 
-COMPILE_ASSERT(sizeof(CSSProperty) == sizeof(SameSizeAsCSSProperty), 
CSSProperty_should_stay_small);
+COMPILE_ASSERT(sizeof(CSSProperty) <= sizeof(SameSizeAsCSSProperty), 
CSSProperty_should_stay_small);
 
 CSSPropertyID StylePropertyMetadata::shorthandID() const
 {
--- qtwebkit-opensource-src-5.212.0~alpha2.orig/Source/WebCore/css/RuleSet.h
+++ qtwebkit-opensource-src-5.212.0~alpha2/Source/WebCore/css/RuleSet.h
@@ -143,7 +143,7 @@ struct SameSizeAsRuleData {
 unsigned d[4];
 };
 
-COMPILE_ASSERT(sizeof(RuleData) == sizeof(SameSizeAsRuleData), 
RuleData_should_stay_small);
+COMPILE_ASSERT(sizeof(RuleData) <= sizeof(SameSizeAsRuleData), 
RuleData_should_stay_small);
 
 class RuleSet {
 WTF_MAKE_NONCOPYABLE(RuleSet); WTF_MAKE_FAST_ALLOCATED;
--- 
qtwebkit-opensource-src-5.212.0~alpha2.orig/Source/WebCore/dom/ElementRareData.cpp
+++ 
qtwebkit-opensource-src-5.212.0~alpha2/Source/WebCore/dom/ElementRareData.cpp
@@ -42,6 +42,6 @@ struct SameSizeAsElementRareData : NodeR
 void* pointers[7];
 };
 
-static_assert(sizeof(ElementRareData) == sizeof(SameSizeAsElementRareData), 
"ElementRareData should stay small");
+static_assert(sizeof(ElementRareData) <= sizeof(SameSizeAsElementRareData), 
"ElementRareData should stay small");
 
 } // namespace WebCore
--- 
qtwebkit-opensource-src-5.212.0~alpha2.orig/Source/WebCore/dom/NodeRareData.cpp
+++ qtwebkit-opensource-src-5.212.0~alpha2/Source/WebCore/dom/NodeRareData.cpp
@@ -38,6 +38,6 @@ struct SameSizeAsNodeRareData {
 void* m_pointer[3];
 };
 
-COMPILE_ASSERT(sizeof(NodeRareData) == sizeof(SameSizeAsNodeRareData), 
NodeRareDataShouldStaySmall);
+COMPILE_ASSERT(sizeof(NodeRareData) <= sizeof(SameSizeAsNodeRareData), 
NodeRareDataShouldStaySmall);
 
 } // namespace WebCore
--- 
qtwebkit-opensource-src-5.212.0~alpha2.orig/Source/WebCore/dom/ShadowRoot.cpp
+++ qtwebkit-opensource-src-5.212.0~alpha2/Source/WebCore/dom/ShadowRoot.cpp
@@ -49,7 +49,7 @@ struct SameSizeAsShadowRoot : public Doc
 #endif
 };
 

Bug#780430: qtwebkit-opensource-src: port to m68k

[John Paul Adrian Glaubitz]

Control: version 5.212.0~alpha2-5

On 11/04/2017 01:21 PM, John Paul Adrian Glaubitz wrote:
> Attaching an updated patch for 5.9.1+dfsg-5, please apply.

Oops, I mean 5.212.0~alpha2-5, of course.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#879958: [Python-modules-team] Bug#879958: marked as pending

[Scott Kitterman]

On November 4, 2017 7:18:58 AM EDT, deb...@activityworkshop.net wrote:
>I'm not sure if I'm the one supposed to close this bug or if the fixer 
>will do it.  Does "pending" mean it's going through the process or 
>waiting for me?
>
>If I understand correctly, the fix has already been done (thank you
>very 
>much!) and the packages are already being built for buster, but not 
>stretch.  And I guess it's not planned to build them for stretch
>either?
>
>Is there a way for me to test this using stretch, or do I have to 
>upgrade to buster?

Pending means that the fix is available, but not yet released.  You don't need 
to close the bug.  The fix that's pending is for Stretch.

Fixes for stable releases need to be approved by the stable release manager.  I 
believe that this is waiting for that approval.

Scott K

Bug#879674: /bin/ps:ps/display.c:66: please report this bug

[zoli]

Hi, Ehem... While writing this, I realized that ps is not even piped to mawk... 
Here is the code I was running with more detail: MAIN SCRIPT:#!/bin/bash
 ...
/bin/bash -c -- "
source SCRIPT_LIB monitor_pid || exit -1;
" 2>&1 \
| /usr/bin/gawk "/Rotated/ {next} {print \$0; fflush(\"\")}" 2>&1 \
| /usr/bin/mawk -W Interactive -v "MYNAME=$( /usr/bin/basename 
"$FALLBACK" )" -f "$FALLBACK" 2>&1 \
| /usr/bin/tee -a "$fallback" 1>&2 &
... SCRIPT_LIB:monitor_pid {while :
do
while [[ "$( /bin/ls -l --block-size=M "$logfile_basename" | 
/usr/bin/tr -s   | /usr/bin/cut -d  -f5 | /usr/bin/tr -d 
M )" -le $max_file_size_MB ]]
do# PS IS HERE
local line="$( /bin/ps aux | /bin/grep ^[^ ]\+ 
\+"$pid" \+ | /usr/bin/tr -s   | /usr/bin/cut -d 
 -f3,4,5,6,8,10,11- )"
if [[ -z "$line" ]]
then
return
else
echo "$( get_date_time ) $( echo "$line" | /bin/sed "s, 
${cmd_pattern}$,," )"

/bin/sleep "$interval_sec"
fi
done >>"$logfile_basename"

# logfile size is over the limit, rotate
/usr/bin/savelog -t -n -j -c $max_num_keep_file "$logfile_basename"
done
} NOTE1: There are other occurences of ps and mawk in may script, but their 
output is saved in separate logfiles, so I am sure that the error logs were 
produced these 2 processes. NOTE2: There were 2 instances of this code running 
parallel, and BOTH of them produced the same error log (into different 
logfiles). So there seems to be a real connection between memory issues, mawk 
and ps.  I have been running the script for a few months (there were patches 
and restarts on the way, though) and I had this problem only once so far. I 
have no idea, what causes it. Since the error log says "Cannot allocate memory" 
(for the mawk), I suppose, it is connected to the ps error.   Before realizing 
that ps is not piped to mawk, I had another idea for explanation. It is 
probably not a valid train of thoughts, anymore, but I leave it here, maybe it 
helps. My other guess was that since the ps output is piped to mawk (I 
thought), if mawk fails due to memory issues, ps may hold a freed virtual 
memory address, where ps is trying to write, which causes the segfault. I have 
observed similar behavior in another test, which more reliably produces the 
segfault, but without a call to ps:
https://stackoverflow.com/questions/47012675/bash-trap-and-process-substitution 
see: TEST SETUPS:TEST SETUP 1 (1 cat):
Results:... for the segfault. I think, this is all, what I have on this error. 
This error report should probably better be treated as a reference, if anyone 
else experiences this issue. I do keep track of this, but until it surfaces 
again, Im afraid, I cannot give more details... Best regards,Zoltan 
Craig Small  írta:
>Hi,  Are you sure its just a lack of memory causing this problem?Its 
>going to be a bit tricky to fix with just a crash message.  - Craig

>> 

>--Craig Small https://dropbear.xyz/ csmall at : 
>enc.com.auDebian GNU/Linuxhttps://www.debian.org/   csmall at : 
>debian.orgMastodon: @smalls...@social.dropbear.xyz Twitter: 
>@smallsees  GPG fingerprint:  5D2F B320 B825 D939 04D2  0519 3938 F96B 
>DF50 FEA5

Bug#826994: Apply Patch

[Chris Dos]

Patch does not apply to 0.7.3:

patch -p1 --dry-run < ../zfs-sysvinit_patch_1.diff
checking file debian/rules
Hunk #1 succeeded at 116 with fuzz 2 (offset 4 lines).
checking file debian/zfs-zed.install
Hunk #1 succeeded at 1 with fuzz 1.
checking file debian/zfsutils-linux.install
Hunk #1 FAILED at 9.
1 out of 1 hunk FAILED
checking file etc/init.d/zfs-zed.in

Bug#880581: Information received

[Tomasz Rybak]

Hello.
I received this report. I'm travelling and away from my main
machine right now so the next weekend (2017-11-11) will be
the earliest I'll be able to look into it - but most probably
it'll be the week after.

Best regards.

-- 
Tomasz Rybak, Debian Maintainer
GPG: A565 CE64 F866 A258 4DDC F9C7 ECB7 3E37 E887 AA8C

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

Bug#880559: Information received

[Tomasz Rybak]

Hello.
I received this report. I'm travelling and away from my main
machine right now so the next weekend (2017-11-11) will be
the earliest I'll be able to look into it - but most probably
it'll be the week after.

Best regards.

-- 
Tomasz Rybak, Debian Maintainer
GPG: A565 CE64 F866 A258 4DDC F9C7 ECB7 3E37 E887 AA8C

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

Bug#880583: Information received

[Tomasz Rybak]

Hello.
I received this report. I'm travelling and away from my main
machine right now so the next weekend (2017-11-11) will be
the earliest I'll be able to look into it - but most probably
it'll be the week after.

Best regards.
 
-- 
Tomasz Rybak, Debian Maintainer
GPG: A565 CE64 F866 A258 4DDC F9C7 ECB7 3E37 E887 AA8C

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

Bug#879958: marked as pending

[debian]

I'm not sure if I'm the one supposed to close this bug or if the fixer 
will do it.  Does "pending" mean it's going through the process or 
waiting for me?


If I understand correctly, the fix has already been done (thank you very 
much!) and the packages are already being built for buster, but not 
stretch.  And I guess it's not planned to build them for stretch either?


Is there a way for me to test this using stretch, or do I have to 
upgrade to buster?

Bug#880717: audacity: New upstream release

[Chris Lamb]

Source: audacity
Version: 2.1.2-2
Severity: wishlist

Hi,

New upstream 2.2.0 release is available at:

  http://www.audacityteam.org/audacity-2-2-0-released/


Regards,

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

Bug#872899: node-tap: autopkgtests fail with nodejs 6

[Graham Inggs]

Control: reopen -1

Hi

Autopkgtests are still failing.  Would you please keep the bug open
until they are fixed?
It currently shows up as resolved in our tagged bugs report [1].

Regards
Graham

[1] 
https://bugs.debian.org/cgi-bin/pkgreport.cgi?archive=both;tag=autopkgtest;users=ubuntu-de...@lists.ubuntu.com

Bug#880716: dino-im: should proabably depend on dino-im-common

[Jonas Smedegaard]

Source: dino-im
Version: 0.0.git20171023-1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

I notice that dino-im does not depend on dino-im-common.

I suspect (without having examined closely) that to be unintended.

 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAln9nrcACgkQLHwxRsGg
ASE/9A//bSHfWwAmsDHZU9D3Hi/OXi7yfIm2t/EJETEriBcUAq8NiEkiRXhvoHJc
4HaHOsvjMG8FWUxonBtCpb4AVBKUZowPyOiEGyiRDjikMw5BAIdES9gauxWAy7SQ
PBi6v0w+VfonCzFVzpkgVildmWXtPIa25b5onk796CM6SEro9EgZ263atz/vjarx
1w1Cc0lSewa6SXUt6yvEmodOlRY4shlRVtQpa0gIelxv45usciADwvDvM7e9gm6Y
+fzykeHiQrztRe8n5ON5Fl4CN49lR4v2V2c6iz2Cwk2PbdPr2XL4EGxVUF6CPdpZ
Pva83jalA83cUdE4YbrZaP3uPeEsZxZRd251LpbfKap1attdTKpbO/ww90yOzlVT
nUwtbNP0S8HYei3ohciD2wLfNLq+o4xgiMHWtBJ7s06GNJnRxUpJQTb7gHGBosvU
fEwM6x/0xpSUSyNCZgEr0npWVTK808q6E4tI9wLDawfTFnKKxN+zJ/iaUMqMNfZB
nqCQkUAfte3jSiUjJ3IKLmCNKgJYzBC6/kS009hX10Dwq/OfFqGKl3NhUHxDdhNQ
JaTb/TfqtXA1e5gSua6Gezs7ybRQoL6NF1NgZU0HUmioCktmiGmr2Mn+Xl8eD3Pr
neB2V3BnSsxMcnEfIwrJfccwG6V8tymbn050cxMkREE4H7spfXE=
=wcQ1
-END PGP SIGNATURE-

Bug#255572: ITP: cc65 -- Cross development suite for 65xxx processors, necesary for nesicide env

[Michael Stapelberg]

Any update on this? :)

On Sat, Oct 7, 2017 at 10:49 PM, PICCORO McKAY Lenz
 wrote:
> hi! please when upload also be sure once the ITP bug are closed remove the
> entry here too:
>
> https://www.debian.org/devel/wnpp/prospective
>
>
> Lenz McKAY Gerardo (PICCORO)
> http://qgqlochekone.blogspot.com
>
> 2017-10-06 20:30 GMT-04:00 PICCORO McKAY Lenz :
>>
>> a bit late but great work! please upload to debian..
>>
>> Lenz McKAY Gerardo (PICCORO)
>> http://qgqlochekone.blogspot.com
>>
>> 2017-10-06 17:46 GMT-04:00 Michael Stapelberg :
>>>
>>> Indeed, I can confirm that compilation works now. Can you upload the
>>> package to Debian please? :)
>>>
>>> On Fri, Oct 6, 2017 at 11:26 PM, László Böszörményi (GCS)
>>>  wrote:
>>> > On Fri, Oct 6, 2017 at 10:26 PM, Michael Stapelberg
>>> >  wrote:
>>> >> Thanks for sharing! The Debian package builds fine. However, when
>>> >> trying to use cc65 to compile a project of mine, compilation fails
>>> >> with “include/general.h(4): Error: Include file `peekpoke.h' not
>>> >> found”.
>>> >  Please fetch and build again. Should be fixed.
>>> >
>>> > Laszlo/GCS
>>>
>>>
>>>
>>> --
>>> Best regards,
>>> Michael
>>
>>
>



-- 
Best regards,
Michael

Bug#880355: transition: libva

[Sebastian Ramacher]

On 2017-10-31 14:06:06, Emilio Pozuelo Monfort wrote:
> Control: tags -1 confirmed
> 
> On 30/10/17 15:21, Sebastian Ramacher wrote:
> > Package: release.debian.org
> > Severity: normal
> > User: release.debian@packages.debian.org
> > Usertags: transition
> > Control: forwarded -1 
> > https://release.debian.org/transitions/html/auto-libva.html
> > Control: block -1 by 879064
> > 
> > libva 2.0 was released and it bumped its SONAME, so it needs a transition. 
> > Note
> > that somme reverse dependencies need sourceful uploads coordinated with the
> > start of the transition: libva-utils and intel-vaapi-driver.
> > 
> > mesa (#879064) needs to be fixed. A rebuild will correctly rebuild against 
> > libva
> > 2.0, but it has an hard-coded dependency on libva1 which could be avoided by
> > using dh_libva from libva-dev.
> > 
> > libyami currently fails to build (no bug, since I maintain that), but has a 
> > fix
> > available upstream. I'll upload a fixed version together with libva.
> > 
> > All other reverse dependencies build fine.
> 
> mesa is fixed now. Please go ahead.

Thanks. libva, libva-utils and intel-vaapi-driver uploaded. I'll handle libyami
on Monday.

Cheers
-- 
Sebastian Ramacher

Bug#880689: [Pkg-rust-maintainers] Bug#880689: dh-cargo: installs too much for libpkg

[Jonas Smedegaard]

Hi Josh,

Quoting Josh Triplett (2017-11-04 10:10:52)
> On Fri, Nov 03, 2017 at 10:00:03PM +0100, Jonas Smedegaard wrote:
>> dh-cargo installs into library packages everything in source package 
>> except directories .git and debian.
>>
>> That is too much: .gitignore files or .travis.yml files make no sense 
>> to install, and neither does .pc directory.
>
> Very intentional and not a bug. I discussed this with the Debian Rust 
> team when I was first creating dh-cargo, and the intent is for the 
> code in /usr/share/cargo/registry to *exactly* match the source as 
> shipped in crates.io, with no omissions. The directory registry 
> mechanism is intended for providing sources that substitute for the 
> upstream sources.
> 
> (Among other things, I *have* encountered packages before that 
> actually *used* .gitignore as part of a package build.)
> 
> That said, upstream crates should not be shipping .pc directories, and 
> if that happens, we should be reporting that upstream to get fixed.

Thanks for the clarification of intent.

I challenge your conclusion that this is not a bug, however: From 
looking at its code, it seems to me dh-cargo currently does _not_ 
install only "the source as shipped in crates,io".

Apparently it installs everything lying around in the source package at 
the time dh-cargo gets triggered, except root directories ".git" and 
"debian".

The ".pc" directory, created during build by a packaging helper tool, 
should certainly not be installed.

I believe that from your own rule, stuff generated during build by 
upstream build tools - typically but not necessarily listed in upstream 
.gitignore - should hot be installed either.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

Bug#822504: lintian: duplicate words

[Sandro Knauß]

Hey,

inside pysrs also "duplicate words" is triggered, because the spellchecker 
isn't aware of the copyright format:

spelling-error-in-copyright License License (duplicate word) License

Part of copyright file that triggers the issue:

License: PSF-2.4
 [...]
 .
 8. By copying, installing or otherwise using Python 2.4, Licensee
 agrees to be bound by the terms and conditions of this License

License: sendmail
 [...]


Best Regards,

sandro

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

Bug#880715: thunderbird: fails to lock gpg keyring for key import under apparmor

[Philipp Kern]

Package: thunderbird
Version: 1:52.4.0-1
X-Debbugs-Cc: intrig...@debian.org, si...@sdeziel.info

When trying to import a GPG key from the Enigmail per-message "Import
Key" button I get AppArmor denials and the operation just hangs (with a
pulsing progress bar - because it waits for the lock):

[172877.352188] audit: type=1400 audit(1509791941.615:303384):
apparmor="DENIED" operation="link" profile="thunderbird//gpg"
name="/home/pkern/.gnupg/pubring.kbx.lock" pid=14200 comm="gpg2"
requested_mask="l" denied_mask="l" fsuid=1000 ouid=1000
target="/home/pkern/.gnupg/.#lk0x559de00c2e10.desktop.kern.pm.14200"

Even after canceling the operation the denials continue until I kill the
gpg2 process in the background.

Kind regards and thanks
Philipp Kern



signature.asc
Description: OpenPGP digital signature

Bug#880714: cappuccino: Broken symlink in /usr/games

[Chris Lamb]

Source: cappuccino
Version: 0.5.1-7
Severity: serious
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: buildpath
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0], we noticed
that cappuccino installs a broken symlink in /usr/games:

 usr/games/cappuccino →
   /​build/​1st/​cappuccino-​0.​5.​1/​debian/​cappuccino/​usr/​bin/​cappuccino

It also cannot be built reproducibly as this depends on the absolute
build path.

Patch attached.

 [0] https://reproducible-builds.org/


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/debian/rules  2017-11-04 10:21:22.678221993 +
--- b/debian/rules  2017-11-04 10:29:52.905835250 +
@@ -46,7 +46,7 @@
 
# As it is considered a game, put a link at /usr/games
mkdir $(CURDIR)/debian/cappuccino/usr/games
-   ln -s $(CURDIR)/debian/cappuccino/usr/bin/cappuccino 
$(CURDIR)/debian/cappuccino/usr/games/cappuccino
+   ln -s /usr/bin/cappuccino 
$(CURDIR)/debian/cappuccino/usr/games/cappuccino
 
 # Build architecture-independent files here.
 binary-indep: build install

Bug#875233: [wpa] Future Qt4 removal from Buster

[Reiner Herrmann]

Control: tags -1 + fixed-upstream

Upstream has already ported wpa_gui to Qt5 [1], which has also been
released in 2.5.
Changing build dependencies and selecting Qt5 during build should be
sufficient to fix this bug.

[1] 
https://w1.fi/cgit/hostap/commit/wpa_supplicant/wpa_gui-qt4?id=8d2ed87d82dd76a8d32227c6b39e1e8e9db7efea


signature.asc
Description: PGP signature

Bug#880713: KeyError: 32019

[jean-christophe manciot]

Package: python-coverage
Version: 4.4.1+dfsg.1-1
Sources: sid

Building git-buildpackage debian/0.9.1 from
https://git.sigxcpu.org/cgit/git-buildpackage in a sid chroot with:
dpkg-buildpackage --no-sign --build=binary

leads to:
...
Traceback (most recent call last):
  File "setup.py", line 82, in 
'console_scripts': ['gbp=gbp.scripts.supercommand:supercommand'],
  File "/usr/lib/python3.6/distutils/core.py", line 148, in setup
dist.run_commands()
  File "/usr/lib/python3.6/distutils/dist.py", line 955, in run_commands
self.run_command(cmd)
  File "/usr/lib/python3.6/distutils/dist.py", line 974, in run_command
cmd_obj.run()
  File "/usr/local/lib/python3.6/dist-packages/nose/commands.py", line 158,
in run
TestProgram(argv=argv, config=self.__config)
  File "/usr/local/lib/python3.6/dist-packages/nose/core.py", line 121, in
__init__
**extra_args)
  File "/usr/lib/python3.6/unittest/main.py", line 95, in __init__
self.runTests()
  File "/usr/local/lib/python3.6/dist-packages/nose/core.py", line 207, in
runTests
result = self.testRunner.run(self.test)
  File "/usr/local/lib/python3.6/dist-packages/nose/core.py", line 66, in
run
result.printErrors()
  File "/usr/local/lib/python3.6/dist-packages/nose/result.py", line 110,
in printErrors
self.config.plugins.report(self.stream)
  File "/usr/local/lib/python3.6/dist-packages/nose/plugins/manager.py",
line 99, in __call__
return self.call(*arg, **kw)
  File "/usr/local/lib/python3.6/dist-packages/nose/plugins/manager.py",
line 167, in simple
result = meth(*arg, **kw)
  File "/usr/lib/python3/dist-packages/nosexcover/nosexcover.py", line 69,
in report
super(XCoverage, self).report(stream)
  File "/usr/local/lib/python3.6/dist-packages/coverage/control.py", line
694, in xml_report
return reporter.report(morfs, outfile=outfile)
  File "/usr/local/lib/python3.6/dist-packages/coverage/xmlreport.py", line
56, in report
self.report_files(self.xml_file, morfs)
  File "/usr/local/lib/python3.6/dist-packages/coverage/report.py", line
84, in report_files
report_fn(cu, self.coverage._analyze(cu))
  File "/usr/local/lib/python3.6/dist-packages/coverage/xmlreport.py", line
117, in xml_file
branch_stats = analysis.branch_stats()
  File "/usr/local/lib/python3.6/dist-packages/coverage/results.py", line
176, in branch_stats
exit_counts = self.parser.exit_counts()
  File "/usr/local/lib/python3.6/dist-packages/coverage/misc.py", line 75,
in _wrapped
setattr(self, attr, fn(self))
  File "/usr/local/lib/python3.6/dist-packages/coverage/parser.py", line
252, in exit_counts
for l1, l2 in self.arcs():
  File "/usr/local/lib/python3.6/dist-packages/coverage/misc.py", line 75,
in _wrapped
setattr(self, attr, fn(self))
  File "/usr/local/lib/python3.6/dist-packages/coverage/parser.py", line
236, in arcs
for l1, l2 in self.byte_parser._all_arcs():
  File "/usr/local/lib/python3.6/dist-packages/coverage/parser.py", line
632, in _all_arcs
arcs.update(bp._arcs())
  File "/usr/local/lib/python3.6/dist-packages/coverage/parser.py", line
598, in _arcs
next_chunk = byte_chunks[ex]
KeyError: 32019
Makefile:11: recipe for target 'test' failed
make[2]: *** [test] Error 1
make[2]: Leaving directory
'/home/actionmystique/src/Git/git-git-buildpackage'
debian/rules:22: recipe for target 'override_dh_auto_test' failed
make[1]: *** [override_dh_auto_test] Error 2
make[1]: Leaving directory
'/home/actionmystique/src/Git/git-git-buildpackage'
debian/rules:18: recipe for target 'build' failed
make: *** [build] Error 2
dpkg-buildpackage: error: debian/rules build subprocess returned exit
status 2

The whole build log is attached.

-- 
Jean-Christophe Manciot
-
Building git-buildpackage
-
dpkg-buildpackage: info: source package git-buildpackage
dpkg-buildpackage: info: source version 0.9.1
dpkg-buildpackage: info: source distribution stable
dpkg-buildpackage: info: host architecture amd64
 dpkg-source --before-build git-git-buildpackage
 fakeroot debian/rules clean
dh clean --with python3 --buildsystem=pybuild
   debian/rules override_dh_auto_clean
make[1]: Entering directory '/home/actionmystique/src/Git/git-git-buildpackage'
dh_auto_clean
I: pybuild base:184: python3.6 setup.py clean 
running clean
removing 
'/home/actionmystique/src/Git/git-git-buildpackage/.pybuild/pythonX.Y_3.6/build'
 (and everything under it)
'build/bdist.linux-amd64' does not exist -- can't clean it
'build/scripts-3.6' does not exist -- can't clean it
rm -rf build/
make -C docs/ clean
make[2]: Entering directory 
'/home/actionmystique/src/Git/git-git-buildpackage/docs'
rm -r manual-html
rm: cannot remove 'manual-html': No such file or directory
Makefile:79: recipe for target 'clean' failed
make[2]: [clean] Error 1 (ignored)
rm *.1 *.5 version.ent
rm: cannot remove '*.1': No such file or directory
rm: cannot remove '*.5': No such file or directory
rm: cannot remove 'version.ent': No such file or directory

Bug#880712: More info...

[Manuel Bilderbeek]

Hi,

OK, I recovered from the situation, thanks to assistance of BenNZ on 
#debian-next.


I'm normally using aptitude with apt-listbugs to maintain my system. A 
couple of months ago, apt-listbugs pinned binutils (as found in 
/etc/apt/preferences.d/apt-listbugs):


Explanation: Pinned by apt-listbugs at 2017-08-27 18:08:40 +0200
Explanation:   #852035: binutils: bfd stumbles over duplicated symbols 
generated by gold

Explanation:   #852671: libkf5kipi: FTBFS (linking error)
Explanation:   #852672: libqapt: FTBFS (linking error)
Explanation:   #852899: libkf5kipi: FTBFS: 
libQt5Gui.so.5.7.1:(*IND*+0x0): multiple definition of `__bss_start'
Explanation:   #852909: libqapt: FTBFS: libQt5Gui.so.5.7.1:(*IND*+0x0): 
multiple definition of `__bss_start'

Package: binutils
Pin: version 2.28-6
Pin-Priority: 3

This prevented upgrading to gcc-7, amongst others. No problem there, all 
was fine.


But last night, when the GNOME shutdown dialog offered me to upgrade the 
system before shutting down (as explained in the original report), this 
pin apparently caused the depending package to be removed (see the 
complete list in the original bug report). There was no interaction; it 
just did it. And that got me into this state. I couldn't install gcc, 
g++, etc. anymore because of the pinned binutils:



Reading package lists...
Building dependency tree...
Reading state information...
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 gcc-7 : Depends: binutils (>= 2.29.1) but 2.28-6 is to be installed
E: Unable to correct problems, you have held broken packages.

as:

binutils:
  Installed: 2.28-6
  Candidate: 2.28-6
  Version table:
 2.29.1-6 500
500 http://ftp.nl.debian.org/debian testing/main amd64 Packages
 -1 http://ftp.nl.debian.org/debian unstable/main amd64 Packages
 *** 2.28-6 3
100 /var/lib/dpkg/status

So, to recover, I unpinned binutils (despite that it contains some 
severe bugs apparently) and reinstalled the packages. This got me X and 
gcc back etc.


So, I'm now still wondering why via this path (which is packagekit, as 
far as I understand), all these packages got removed... That's the 
reason for this bug report.


--
Grtjs, Manuel

PS: MSX FOR EVER! (Questions? http://faq.msxnet.org/ )
PPS: Visit my homepage at http://manuel.msxnet.org/

Bug#871811: Bug#876521: FTBFS with CGAL 4.11

[Joachim Reichel]

Hi Sebastiaan,

any news here? SFCGAL is now the only remaining reverse dependency that affects
the upload of CGAL 4.11.

Unless you have information that changes the picture in the near-term future I
would like to go on and request a transition slot for CGAL 4.11.

Kind regards,
  Joachim

Bug#879624: Similar issue, also X1 carbon

[Michael Hanke]

Looking into possible known issues for at-spi or gnome-terminal-server
did not bring up anything useful for me.

FTR: Installing xfce4 or kde both gives me a working desktop. So this
might actually be a GNOME issue rather than an X issue, or an
interaction of the two.

On Sat, Nov 4, 2017 at 10:14 AM, Michael Hanke  wrote:
> Update:
>
> I stopped the gdm3 service and started a freshly installed slim login
> manager. I comes right up, no issues.
>
> Starting the GNOME session from slim, however, results in immediate
> failure. This is syslog from the last message of slim to the X server
> shutdown:
>
> Nov  4 09:49:56 meiner slim[8940]: /usr/bin/X11/xauth:  file
> /home/mih/.Xauthority does not exist
> Nov  4 09:49:56 meiner org.a11y.Bus[9347]: Activating service
> name='org.a11y.atspi.Registry'
> Nov  4 09:49:56 meiner org.a11y.Bus[9347]: Successfully activated
> service 'org.a11y.atspi.Registry'
> Nov  4 09:49:56 meiner org.a11y.atspi.Registry[9373]: SpiRegistry
> daemon is running with well-known name - org.a11y.atspi.Registry
> Nov  4 09:49:56 meiner gnome-terminal-[9379]: gnome-terminal-server:
> Fatal IO error 11 (Resource temporarily unavailable) on X server :0.0.
> Nov  4 09:49:56 meiner org.a11y.atspi.Registry[9373]: XIO:  fatal IO
> error 11 (Resource temporarily unavailable) on X server ":0.0"
> Nov  4 09:49:56 meiner org.a11y.atspi.Registry[9373]:   after 21
> requests (19 known processed) with 0 events remaining.
> Nov  4 09:49:56 meiner org.gtk.vfs.Daemon[9347]: A connection to the
> bus can't be made
> Nov  4 09:49:58 meiner kernel: [  249.268908] [drm] Reducing the
> compressed framebuffer size. This may lead to less power savings than
> a non-reduced-size. Try to increase stolen memory size if available in
> BIOS.
> Nov  4 09:49:58 meiner slim[8940]: (II) Server terminated successfully
> (0). Closing log file.
>
> On Fri, Nov 3, 2017 at 5:02 PM, Michael Hanke  wrote:
>> Hi,
>>
>> same here, after upgrade to buster no X anymore. Normal start works, but
>> ends at terminal login. Manual startx makes the screen flicker briefly, then
>> back to terminal. X log contain no errors (EE).
>>
>> Downgrade to stretch didn't change the situation in any way. Going back from
>> linux 4.13 to 4.8 had no effect either.
>>
>> During downgrade gconf2 choked (triggers hung and never completed). During
>> upgrade I think I saw some gconf error message too, but I cannot find a
>> trace of them anywhere.
>>
>> Any advice would be highly appreciated.
>>
>> Thanks in advance
>>
>> Michael
>>
>
>
>
> --
> Michael Hanke
> http://psychoinformatics.de



-- 
Michael Hanke
http://psychoinformatics.de

Bug#880712: packagekit: Offers to update system, but breaks it

[Manuel Bilderbeek]

Package: packagekit
Version: 1.1.7-1
Severity: important

Dear Maintainer,

   * What led up to the situation?

Before logging out of GNOME yesterday evening to shut down, I got a question
whether to install pending package updates. I choose YES. After logging out,
the system rebooted and quickly did a non-interactive update before shutting
down. (I run testing.)

After booting this morning, I got a GNOME error window that "something went 
wrong". It appears that the nVidia driver had been removed and several other 
important packages like gcc, g++ and whatnot.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?

I'm trying to reinstall the removed package, but it fails, see below.

   * What outcome did you expect instead?

I would expect that also packagekit updates keep my system OK.

This is what it did:

Start-Date: 2017-11-03  23:46:43
Commandline: packagekit role='update-packages'
Install: module-assistant:amd64 (0.11.9, automatic), kbuild:amd64 
(1:0.1.9998svn3110+dfsg-1, automatic)
Upgrade: cpp-6:amd64 (6.4.0-1, 6.4.0-9), libasan3:amd64 (6.4.0-1, 6.4.0-9), 
gcc-6-base:amd64 (6.4.0-1, 6.4.0-9), gcc-6-base:i386 (6.4.0-1, 6.4.0-9), 
libgcc-6-dev:amd64 (6.4.0-1, 6.4.0-9), libstdc++-6-dev:amd64 (6.4.0-1, 6.4.0-9)
Remove: linux-headers-4.12.0-2-amd64:amd64 (4.12.13-1), rustc:amd64 
(1.20.0+dfsg1-1), linux-headers-4.13.0-1-amd64:amd64 (4.13.4-2), g++:amd64 
(4:6.3.0-4d1), gcc:amd64 (4:6.3.0-4d1), virtualbox-dkms:amd64 (5.2.0-dfsg-2), 
linux-compiler-gcc-6-x86:amd64 (4.13.4-2), 
nvidia-legacy-340xx-kernel-dkms:amd64 (340.104-1), dkms:amd64 (2.3-3), 
virtualbox:amd64 (5.2.0-dfsg-2), build-essential:amd64 (12.3), g++-6:amd64 
(6.4.0-1), gcc-6:amd64 (6.4.0-1), cargo:amd64 (0.20.0-2), 
linux-headers-amd64:amd64 (4.13+86), virtualbox-qt:amd64 (5.2.0-dfsg-2), 
nvidia-legacy-340xx-driver:amd64 (340.104-1)
End-Date: 2017-11-03  23:47:02

I don't know why, but when I try to reinstall g++ or gcc or my nvidia packages,
or dkms, apt-get complains that the packages are not installabable...
For example:

Reading package lists...
Building dependency tree...
Reading state information...
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 g++ : Depends: gcc (>= 4:7.2.0-1d1) but it is not going to be installed
   Depends: g++-7 (>= 7.2.0-1~) but it is not going to be installed
   Depends: gcc-7 (>= 7.2.0-1~) but it is not going to be installed
E: Unable to correct problems, you have held broken packages.

So, can someone also please help me to get my system back in shape?

I apologize if I filed this against the wrong package. I noticed that
packagekit performed this update, that's why I used packagekit to file the bug
against. Please forward to the appropriate package if necessary. And also
please advise to resolve the situation.

Kind regards,
Manuel

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

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

Versions of packages packagekit depends on:
ii  libappstream4   0.11.7-1
ii  libapt-inst2.0  1.5
ii  libapt-pkg5.0   1.5
ii  libc6   2.24-17
ii  libgcc1 1:7.2.0-12
ii  libglib2.0-02.54.1-1
ii  libglib2.0-bin  2.54.1-1
ii  libgstreamer1.0-0   1.12.3-1
ii  libpackagekit-glib2-18  1.1.7-1
ii  libpolkit-gobject-1-0   0.105-18
ii  libsqlite3-03.20.1-2
ii  libstdc++6  7.2.0-12
ii  libsystemd0 235-2
ii  policykit-1 0.105-18

Versions of packages packagekit recommends:
ii  packagekit-tools  1.1.7-1

Versions of packages packagekit suggests:
ii  appstream  0.11.7-1

-- no debconf information

Bug#880711: supermin: guest cannot find init with linux 4.13

[Jorrit Fahlke]

Package: supermin
Version: 5.1.17-8
Severity: normal

Dear Maintainer,

this is pretty much a request to get supermin >=5.18 into stretch-backports.

Supermin (up to and including 5.1.17) takes some shortcuts with the symlinks
when generating the root filesystem.  Linux 4.13 made some changes to the way
it handles short symlinks, as a result the symlink targets in
supermin-generates images are garbled.  /init is usually a script with /bin/sh
as the interpreter, which is usually symlinked to /bin/dash or similar, so on
4.13 kernels the images fail to boot.

Linux 4.13 just made it into stretch-backports, so if you have those enabled
supermin, and by extension libguestfs, including guestfish, stop working.

The upstream commit that fixes that, right before 5.18:
https://github.com/libguestfs/supermin/commit/158854e3ba4be7f6b8d81f662ddad98358ede1de


For the record: there is, of course, a workaround: if you also have an older
kernel installed you can tell supermin to use that, even if the host actually
runs a newer one.  For libguestfs and the kernel from stretch that currently
looks like this:

  rm -rf /var/tmp/.guestfs-* # clean up cached appliances
  export SUPERMIN_KERNEL=/boot/vmlinuz-4.9.0-3-amd64
  export SUPERMIN_MODULES=/lib/modules/4.9.0-3-amd64
  libguestfs-test-tool

For other appliances, you'll have to find out yourself where they keep the
cache.


How to reproduce:

Use the example from the manpage with a host kernel >=4.13:
==
#!/bin/sh

set -ex
#export SUPERMIN_KERNEL=/boot/vmlinuz-4.9.0-3-amd64
#export SUPERMIN_MODULES=/lib/modules/4.9.0-3-amd64

uname -a

rm -rf /tmp/supermin.d /tmp/appliance.d

supermin --prepare bash -o /tmp/supermin.d

cat > init <+ uname -a
Linux scratches 4.13.0-0.bpo.1-amd64 #1 SMP Debian 4.13.4-2~bpo9+1 (2017-10-17) 
x86_64 GNU/Linux
+ rm -rf /tmp/supermin.d /tmp/appliance.d
+ supermin --prepare bash -o /tmp/supermin.d
+ cat
+ chmod +x init
+ tar zcf /tmp/supermin.d/init.tar.gz ./init
+ supermin --build /tmp/supermin.d -f ext2 -o /tmp/appliance.d
+ kvm -nodefaults -nographic -kernel /tmp/appliance.d/kernel -initrd 
/tmp/appliance.d/initrd -hda /tmp/appliance.d/root -serial stdio -append 
console=ttyS0
WARNING: Image format was not specified for '/tmp/appliance.d/root' and probing 
guessed raw.
 Automatically detecting the format is dangerous for raw images, write 
operations on block 0 will be restricted.
 Specify the 'raw' format explicitly to remove the restrictions.
[0.00] random: get_random_bytes called from start_kernel+0x3d/0x456 
with crng_init=0
[0.00] Linux version 4.13.0-0.bpo.1-amd64 
(debian-ker...@lists.debian.org) (gcc version 6.3.0 20170516 (Debian 6.3.0-18)) 
#1 SMP Debian 4.13.4-2~bpo9+1 (2017-10-17)
[0.00] Command line: console=ttyS0
[0.00] x86/fpu: x87 FPU will use FXSAVE
[0.00] e820: BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0009fbff] usable
[0.00] BIOS-e820: [mem 0x0009fc00-0x0009] reserved
[0.00] BIOS-e820: [mem 0x000f-0x000f] reserved
[0.00] BIOS-e820: [mem 0x0010-0x07fd] usable
[0.00] BIOS-e820: [mem 0x07fe-0x07ff] reserved
[0.00] BIOS-e820: [mem 0xfeffc000-0xfeff] reserved
[0.00] BIOS-e820: [mem 0xfffc-0x] reserved
[0.00] NX (Execute Disable) protection: active
[0.00] random: fast init done
[0.00] SMBIOS 2.8 present.
[0.00] DMI: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1 
04/01/2014
[0.00] Hypervisor detected: KVM
[0.00] tsc: Fast TSC calibration using PIT
[0.00] e820: last_pfn = 0x7fe0 max_arch_pfn = 0x4
[0.00] x86/PAT: PAT not supported by CPU.
[0.00] x86/PAT: Configuration [0-7]: WB  WT  UC- UC  WB  WT  UC- UC  
[0.00] found SMP MP-table at [mem 0x000f6aa0-0x000f6aaf] mapped at 
[9ddec00f6aa0]
[0.00] RAMDISK: [mem 0x07ce8000-0x07fd]
[0.00] ACPI: Early table checksum verification disabled
[0.00] ACPI: RSDP 0x000F68D0 14 (v00 BOCHS )
[0.00] ACPI: RSDT 0x07FE18B5 30 (v01 BOCHS  BXPCRSDT 
0001 BXPC 0001)
[0.00] ACPI: FACP 0x07FE1791 74 (v01 BOCHS  BXPCFACP 
0001 BXPC 0001)
[0.00] ACPI: DSDT 0x07FE0040 001751 (v01 BOCHS  BXPCDSDT 
0001 BXPC 0001)
[0.00] ACPI: FACS 0x07FE 40
[0.00] ACPI: APIC 0x07FE1805 78 (v01 BOCHS  BXPCAPIC 
0001 BXPC 0001)
[0.00] ACPI: HPET 0x07FE187D 38 (v01 BOCHS  BXPCHPET 
0001 BXPC 0001)
[0.00] No NUMA configuration found
[0.00] Faking a node at [mem 0x-0x07fd]
[0.00] NODE_DATA(0) allocated [mem 

Bug#880690: [Pkg-rust-maintainers] Bug#880690: dh-cargo: should build and test library

[Josh Triplett]

tags 880690 + confirmed
severity 880690 wishlist
thanks

On Fri, Nov 03, 2017 at 10:05:31PM +0100, Jonas Smedegaard wrote:
> Package: dh-cargo
> Version: 2
> Severity: important
> 
> dh-cargo registers as a _build_ system, yet does not build the library
> nor does it execute its testsuite.
> 
> I understand that Rust packaging policy mandates libraries should be
> _installed_ only as source, but that does not preclude ensuring that it
> properly builds and passes its testsuite.

This is something we should work towards, and may be able to do on a
case-by-case basis, but we cannot run crate testsuites by default.
*Many* crates are not capable of running their testsuites given only the
contents of the .crate file; some require the full contents of the
upstream git repository (including non-trivial test data), or
non-standard tools, or git submodules, or any number of other things.

Beyond that, even if the testsuite could be run with only those files,
neither "cargo test" nor "cargo build" can be reliably be run from the
unpacked .crate, because the unpacked crate may incorporate things like
workspaces. Only "cargo install cratename" (with a directory registry)
is expected to work from a .crate, and only from a binary package, not a
library package.

I'm tagging this as confirmed because we *do* want to do it at some
point, and marking it as wishlist for the feature of allowing a package
to opt in to running the testsuite in cases where it is known to work.

Bug#880689: [Pkg-rust-maintainers] Bug#880689: dh-cargo: installs too much for libpkg

[Josh Triplett]

On Fri, Nov 03, 2017 at 10:00:03PM +0100, Jonas Smedegaard wrote:
> Package: dh-cargo
> Version: 2
> Severity: normal
> 
> dh-cargo installs into library packages everything in source package
> except directories .git and debian.
> 
> That is too much: .gitignore files or .travis.yml files make no sense to
> install, and neither does .pc directory.

Very intentional and not a bug. I discussed this with the Debian Rust
team when I was first creating dh-cargo, and the intent is for the code
in /usr/share/cargo/registry to *exactly* match the source as shipped in
crates.io, with no omissions. The directory registry mechanism is
intended for providing sources that substitute for the upstream sources.

(Among other things, I *have* encountered packages before that actually
*used* .gitignore as part of a package build.)

That said, upstream crates should not be shipping .pc directories, and
if that happens, we should be reporting that upstream to get fixed.

- Josh Triplett

Bug#879624: Similar issue, also X1 carbon

[Michael Hanke]

Update:

I stopped the gdm3 service and started a freshly installed slim login
manager. I comes right up, no issues.

Starting the GNOME session from slim, however, results in immediate
failure. This is syslog from the last message of slim to the X server
shutdown:

Nov  4 09:49:56 meiner slim[8940]: /usr/bin/X11/xauth:  file
/home/mih/.Xauthority does not exist
Nov  4 09:49:56 meiner org.a11y.Bus[9347]: Activating service
name='org.a11y.atspi.Registry'
Nov  4 09:49:56 meiner org.a11y.Bus[9347]: Successfully activated
service 'org.a11y.atspi.Registry'
Nov  4 09:49:56 meiner org.a11y.atspi.Registry[9373]: SpiRegistry
daemon is running with well-known name - org.a11y.atspi.Registry
Nov  4 09:49:56 meiner gnome-terminal-[9379]: gnome-terminal-server:
Fatal IO error 11 (Resource temporarily unavailable) on X server :0.0.
Nov  4 09:49:56 meiner org.a11y.atspi.Registry[9373]: XIO:  fatal IO
error 11 (Resource temporarily unavailable) on X server ":0.0"
Nov  4 09:49:56 meiner org.a11y.atspi.Registry[9373]:   after 21
requests (19 known processed) with 0 events remaining.
Nov  4 09:49:56 meiner org.gtk.vfs.Daemon[9347]: A connection to the
bus can't be made
Nov  4 09:49:58 meiner kernel: [  249.268908] [drm] Reducing the
compressed framebuffer size. This may lead to less power savings than
a non-reduced-size. Try to increase stolen memory size if available in
BIOS.
Nov  4 09:49:58 meiner slim[8940]: (II) Server terminated successfully
(0). Closing log file.

On Fri, Nov 3, 2017 at 5:02 PM, Michael Hanke  wrote:
> Hi,
>
> same here, after upgrade to buster no X anymore. Normal start works, but
> ends at terminal login. Manual startx makes the screen flicker briefly, then
> back to terminal. X log contain no errors (EE).
>
> Downgrade to stretch didn't change the situation in any way. Going back from
> linux 4.13 to 4.8 had no effect either.
>
> During downgrade gconf2 choked (triggers hung and never completed). During
> upgrade I think I saw some gconf error message too, but I cannot find a
> trace of them anywhere.
>
> Any advice would be highly appreciated.
>
> Thanks in advance
>
> Michael
>



-- 
Michael Hanke
http://psychoinformatics.de

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

[Chris Lamb]

tags 880701 + pending
thanks

Thanks! Applied in Git:

  
https://anonscm.debian.org/git/lintian/lintian.git/commit/?id=a01ed6cd1520ad16d0c0cc3a47b8c264ca49f8b9


Regards,

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

Bug#880504: Fixed upstream

[Salvatore Bonaccorso]

Control: tags -1 + pending

Hi Andrew,

On Thu, Nov 02, 2017 at 11:11:09AM +, Andrew Chadwick wrote:
> Patching with Ronnie Sahlberg's f74bc7c[1] on top of the otherwise
> affected Debian linux-image-4.14.0-rc7-amd64 using the handbook
> test-patches instructions[2] fixes this bug for me. This was merged
> upstream in 89db69d yesterday, and should be included in the next -rc
> or 4.14.0 proper.
> 
> [1] 
> https://github.com/torvalds/linux/commit/f74bc7c6679200a4a83156bb89cbf6c229fe8ec0.patch
> [2] https://kernel-handbook.alioth.debian.org/ch-common-tasks.html#s4.2.2

Thanks for checking for the solution. I have cherry-picked the patch
and applied it to the sid branch
https://anonscm.debian.org/cgit/kernel/linux.git/commit/?h=sid=4b0df3bed780f36391d8fe0272b184d6b1c145b6
.

Regards,
Salvatore

Bug#880690: [Pkg-rust-maintainers] Bug#880690: dh-cargo: should build and test library

[Vasudev Kamath]

Jonas Smedegaard  writes:

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

Right it does so for only binary crates.

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

In a way you are right, it definitely makes sense from our side to make
sure we provide source for library that properly builds.

Again patch and suggestions from other team members is welcome.

Bug#880689: [Pkg-rust-maintainers] Bug#880689: dh-cargo: installs too much for libpkg

[Vasudev Kamath]

Jonas Smedegaard  writes:

> dh-cargo installs into library packages everything in source package
> except directories .git and debian.
>
> That is too much: .gitignore files or .travis.yml files make no sense to
> install, and neither does .pc directory.

Agreed. 

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

Agreed.

I'm no Perl guy and welcome a patch :-).

Cheers,
Vasudev

Bug#880638: release-notes: Document apt sandbox support [buster]

[Niels Thykier]

Joost van Baal-Ilić:
> Hi Niels,
> 
> Thanks for your bugreport!
> 

Hi, :)

> On Fri, Nov 03, 2017 at 07:37:12AM +0100, Niels Thykier wrote:
>> Package: release-notes
>> Severity: wishlist
>>
>> --- News for apt (libapt-pkg5.0 libapt-inst2.0) ---
>> apt (1.6~alpha1) unstable; urgency=medium
>>
>>   All methods provided by apt except for cdrom, gpgv, and rsh now
>>   use seccomp-BPF sandboxing to restrict the list of allowed system
>>   calls, and trap all others with a SIGSYS signal. Three options
>>   can be used to configure this further:
>>
>> APT::Sandbox::Seccomp is a boolean to turn it on/off
>> APT::Sandbox::Seccomp::Trap is a list of names of more syscalls to trap
>> APT::Sandbox::Seccomp::Allow is a list of names of more syscalls to allow
>>
>>   Also, sandboxing is now enabled for the mirror method.
>>
>>  -- Julian Andres Klode   Mon, 23 Oct 2017 01:58:18 +0200
>>
>> Seems like it would be prudent to mention that in the release-notes
>> for buster.
> 
> 
> Are https and debtorrent "methods provided by apt", or are these methods
> shipped in other optional packages and not yet sandboxed?
> 

The https method is (now) provided directly by apt and is covered by the
sandboxing (implementation-detail: It is in fact the same binary as the
"http" method).

As for debtorrent: I /think/ it is a "third-party" method (from apt's
PoV) and therefore not covered by the built-in rules.  CC'ing deity to
confirm that.

> Is the mirror method now using the same sandboxing implementation?
> 

That is my understanding.

> The text could be more clear; for some answers to these questions a proposed
> enhanced text is:
> 
>  All methods provided by apt (e.g. http, https, debtorrent, ...) except for
>  cdrom, gpgv, and rsh now use seccomp-BPF sandboxing as supplied by the Linux
>  kernel to restrict the list of allowed system calls, and trap all others 
> with a
>  SIGSYS signal.
>  [...]
> 
>  Also, this sandboxing is now enabled for the mirror method.
> 
> 
> Bye,
> 
> Joost
> 

As per above, I think it need a s/debtorrent, //.

I was also wondering whether we should document it in "whats-new" or
"issues".  The latter clearly makes sense as it can cause issues that
people need to know how to solve.  On the other side, I think it would
be nice to document that apt has been hardened even further (and that,
IMO, would fit "Whats new" better than "Issues").

Thanks,
~Niels

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

[Afif Elghraoui]

على الجمعـة  3 تشرين الثاني 2017 ‫17:52، كتب Diane Trout:
> There was also symbols removed between 1.4.1 to 1.5 but upstream didn't
> change their SOVERSION.
> 
> As an aside while I was looking at the missing symbols I found mfprintf
> was still listed in htslib 1.5's cram/mFILE.h, but the implementation
> had been removed from cram/mFILE.c
> 
> Should we be patching the SOVERSION? 
> File a bug upstream to have them update SOVERSION?

This was upstream's advice [1]:

> (When your symbols script comes up with MISSING it would be helpful
> if Debian would start by running "git log -S symbolname" which will
> usually provide an explanation, rather than assuming that something
> terrible has happened.


regards
Afif

1. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=822701#56

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